From 265d8ccdd8d387b41f71d401f6c2287ea9636dc8 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 8 Jan 2025 14:52:48 -0600
Subject: [PATCH 01/16] [FR] Generate investigation guides

---
 detection_rules/rule_formatter.py             |  8 +++
 rules/apm/apm_403_response_to_a_post.toml     | 49 ++++++++++++++++-
 .../apm_405_response_method_not_allowed.toml  | 45 +++++++++++++++-
 rules/apm/apm_sqlmap_user_agent.toml          | 48 ++++++++++++++++-
 ..._google_drive_malicious_file_download.toml | 48 ++++++++++++++++-
 ...and_and_control_non_standard_ssh_port.toml | 45 +++++++++++++++-
 ...s_cookies_chromium_browsers_debugging.toml | 45 +++++++++++++++-
 ...al_access_forced_authentication_pipes.toml | 44 ++++++++++++++-
 ..._evasion_agent_spoofing_mismatched_id.toml | 45 +++++++++++++++-
 ...evasion_agent_spoofing_multiple_hosts.toml | 45 +++++++++++++++-
 ...e_evasion_deleting_websvr_access_logs.toml | 46 +++++++++++++++-
 ...deletion_of_bash_command_line_history.toml | 45 +++++++++++++++-
 ...sion_elastic_agent_service_terminated.toml | 45 +++++++++++++++-
 ..._evasion_encoding_rot13_python_script.toml | 50 ++++++++++++++++-
 ...ion_masquerading_space_after_filename.toml | 45 +++++++++++++++-
 .../defense_evasion_timestomp_touch.toml      | 44 ++++++++++++++-
 ...y_virtual_machine_fingerprinting_grep.toml | 45 +++++++++++++++-
 ...m_sendcommand_with_command_parameters.toml | 49 ++++++++++++++++-
 ...on_pentest_eggshell_remote_admin_tool.toml | 50 ++++++++++++++++-
 ...otential_widespread_malware_infection.toml | 44 ++++++++++++++-
 ...tion_suspicious_java_netcon_childproc.toml | 45 +++++++++++++++-
 .../guided_onboarding_sample_rule.toml        | 47 ++++++++++++++--
 ..._access_zoom_meeting_with_no_passcode.toml | 46 +++++++++++++++-
 ...ultiple_alerts_different_tactics_host.toml | 45 +++++++++++++++-
 .../multiple_alerts_involving_user.toml       | 44 ++++++++++++++-
 ...l_access_modify_auth_module_or_config.toml | 45 +++++++++++++++-
 ...ersistence_shell_profile_modification.toml | 46 +++++++++++++++-
 ...ence_ssh_authorized_keys_modification.toml | 45 +++++++++++++++-
 ...lege_escalation_echo_nopasswd_sudoers.toml | 44 ++++++++++++++-
 ...ation_setuid_setgid_bit_set_via_chmod.toml | 45 +++++++++++++++-
 ...ilege_escalation_sudo_buffer_overflow.toml | 47 +++++++++++++++-
 ...privilege_escalation_sudoers_file_mod.toml | 43 ++++++++++++++-
 ...collection_cloudtrail_logging_created.toml | 48 ++++++++++++++++-
 ...cess_root_console_failure_brute_force.toml | 48 ++++++++++++++++-
 ...vasion_configuration_recorder_stopped.toml | 48 ++++++++++++++++-
 ...ense_evasion_ec2_network_acl_deletion.toml | 49 ++++++++++++++++-
 ...n_elasticache_security_group_creation.toml | 47 +++++++++++++++-
 ...he_security_group_modified_or_deleted.toml | 48 ++++++++++++++++-
 ...e_evasion_guardduty_detector_deletion.toml | 47 +++++++++++++++-
 ...defense_evasion_rds_instance_restored.toml | 46 +++++++++++++++-
 ...sion_s3_bucket_configuration_deletion.toml | 47 +++++++++++++++-
 ...ense_evasion_sts_get_federation_token.toml | 45 +++++++++++++++-
 .../aws/defense_evasion_waf_acl_deletion.toml | 48 ++++++++++++++++-
 ...asion_waf_rule_or_rule_group_deletion.toml | 49 ++++++++++++++++-
 ...s_multi_region_service_quota_requests.toml | 46 +++++++++++++++-
 ..._new_terms_cloudformation_createstack.toml | 44 ++++++++++++++-
 ..._full_network_packet_capture_detected.toml | 47 +++++++++++++++-
 .../exfiltration_ec2_vm_export_failure.toml   | 47 +++++++++++++++-
 .../aws/exfiltration_rds_snapshot_export.toml | 49 ++++++++++++++++-
 ..._eventbridge_rule_disabled_or_deleted.toml | 47 +++++++++++++++-
 .../impact_ec2_disable_ebs_encryption.toml    | 48 ++++++++++++++++-
 ...mpact_efs_filesystem_or_mount_deleted.toml | 47 +++++++++++++++-
 .../aws/impact_iam_group_deletion.toml        | 47 +++++++++++++++-
 ...mk_disabled_or_scheduled_for_deletion.toml | 47 +++++++++++++++-
 .../aws/impact_rds_group_deletion.toml        | 51 +++++++++++++++++-
 .../impact_rds_instance_cluster_deletion.toml | 49 ++++++++++++++++-
 .../impact_rds_instance_cluster_stoppage.toml | 48 ++++++++++++++++-
 .../aws/impact_rds_snapshot_deleted.toml      | 44 ++++++++++++++-
 .../aws/initial_access_password_recovery.toml | 47 +++++++++++++++-
 ...al_access_signin_console_login_no_mfa.toml | 45 +++++++++++++++-
 ...l_movement_ec2_instance_console_login.toml | 45 +++++++++++++++-
 .../persistence_ec2_network_acl_creation.toml | 50 ++++++++++++++++-
 ..._group_configuration_change_detection.toml | 46 +++++++++++++++-
 ...nce_iam_create_login_profile_for_root.toml | 46 +++++++++++++++-
 .../aws/persistence_iam_group_creation.toml   | 47 +++++++++++++++-
 .../aws/persistence_rds_cluster_creation.toml | 47 +++++++++++++++-
 .../aws/persistence_rds_group_creation.toml   | 48 ++++++++++++++++-
 .../persistence_rds_instance_creation.toml    | 47 +++++++++++++++-
 ...ersistence_redshift_instance_creation.toml | 48 ++++++++++++++++-
 ...oute_53_domain_transfer_lock_disabled.toml | 47 +++++++++++++++-
 ...domain_transferred_to_another_account.toml | 48 ++++++++++++++++-
 ..._53_hosted_zone_associated_with_a_vpc.toml | 48 ++++++++++++++++-
 .../aws/persistence_route_table_created.toml  | 48 ++++++++++++++++-
 ...tence_route_table_modified_or_deleted.toml | 44 ++++++++++++++-
 ...sistence_sts_assume_role_with_new_mfa.toml | 47 +++++++++++++++-
 ..._escalation_iam_saml_provider_updated.toml | 47 +++++++++++++++-
 ..._escalation_sts_getsessiontoken_abuse.toml | 48 ++++++++++++++++-
 ...rivilege_escalation_sts_role_chaining.toml | 47 +++++++++++++++-
 ...collection_update_event_hub_auth_rule.toml | 48 ++++++++++++++++-
 ..._full_network_packet_capture_detected.toml | 47 +++++++++++++++-
 ...d_device_code_auth_with_broker_client.toml | 45 +++++++++++++++-
 ...ntra_signin_brute_force_microsoft_365.toml | 48 ++++++++++++++++-
 ...ute_force_microsoft_365_repeat_source.toml | 48 ++++++++++++++++-
 ...cess_first_time_seen_device_code_auth.toml | 44 ++++++++++++++-
 .../credential_access_key_vault_modified.toml | 47 +++++++++++++++-
 ...ccess_storage_account_key_regenerated.toml | 47 +++++++++++++++-
 ...e_application_credential_modification.toml | 48 ++++++++++++++++-
 ...sion_azure_automation_runbook_deleted.toml | 48 ++++++++++++++++-
 ...asion_azure_blob_permissions_modified.toml | 48 ++++++++++++++++-
 ...on_azure_diagnostic_settings_deletion.toml | 47 +++++++++++++++-
 .../defense_evasion_event_hub_deletion.toml   | 48 ++++++++++++++++-
 ...ense_evasion_firewall_policy_deletion.toml | 47 +++++++++++++++-
 ...on_frontdoor_firewall_policy_deletion.toml | 47 +++++++++++++++-
 ...nse_evasion_kubernetes_events_deleted.toml | 48 ++++++++++++++++-
 ...ense_evasion_network_watcher_deletion.toml | 48 ++++++++++++++++-
 ...ense_evasion_suppression_rule_created.toml | 48 ++++++++++++++++-
 .../discovery_blob_container_access_mod.toml  | 47 +++++++++++++++-
 .../execution_command_virtual_machine.toml    | 47 +++++++++++++++-
 ...e_service_principal_credentials_added.toml | 49 ++++++++++++++++-
 .../azure/impact_kubernetes_pod_deleted.toml  | 48 ++++++++++++++++-
 .../azure/impact_resource_group_deletion.toml | 48 ++++++++++++++++-
 ...mpact_virtual_network_device_modified.toml | 47 +++++++++++++++-
 ...ial_access_external_guest_user_invite.toml | 48 ++++++++++++++++-
 ...ence_azure_automation_account_created.toml | 47 +++++++++++++++-
 ...utomation_runbook_created_or_modified.toml | 47 +++++++++++++++-
 ...ence_azure_automation_webhook_created.toml | 49 ++++++++++++++++-
 ...re_conditional_access_policy_modified.toml | 47 +++++++++++++++-
 ...re_global_administrator_role_assigned.toml | 49 ++++++++++++++++-
 ...nce_azure_pim_user_added_global_admin.toml | 47 +++++++++++++++-
 ..._added_as_owner_for_azure_application.toml | 47 +++++++++++++++-
 ..._as_owner_for_azure_service_principal.toml | 47 +++++++++++++++-
 ..._azure_kubernetes_rolebinding_created.toml | 48 ++++++++++++++++-
 .../command_and_control_beaconing.toml        | 45 +++++++++++++++-
 ...and_control_beaconing_high_confidence.toml | 45 +++++++++++++++-
 .../container_workload_protection.toml        | 45 +++++++++++++++-
 ...s_aws_creds_search_inside_a_container.toml | 44 ++++++++++++++-
 ..._files_compression_inside_a_container.toml | 45 +++++++++++++++-
 ...r_passwords_search_inside_a_container.toml | 45 +++++++++++++++-
 ...ed_object_modified_inside_a_container.toml | 45 +++++++++++++++-
 ...work_tool_launched_inside_a_container.toml | 45 +++++++++++++++-
 ...nt_binary_launched_inside_a_container.toml | 45 +++++++++++++++-
 ...ecutable_via_chmod_inside_a_container.toml | 44 ++++++++++++++-
 ...ecution_interactive_exec_to_container.toml | 44 ++++++++++++++-
 ...shell_spawned_from_inside_a_container.toml | 44 ++++++++++++++-
 ...stener_established_inside_a_container.toml | 44 ++++++++++++++-
 ...ection_established_inside_a_container.toml | 44 ++++++++++++++-
 ...h_process_launched_inside_a_container.toml | 45 +++++++++++++++-
 ..._keys_modification_inside_a_container.toml | 44 ++++++++++++++-
 ...aunched_inside_a_privileged_container.toml | 46 +++++++++++++++-
 ...aunched_inside_a_privileged_container.toml | 45 +++++++++++++++-
 ...e_via_modified_notify_on_release_file.toml | 44 ++++++++++++++-
 ...scape_via_modified_release_agent_file.toml | 44 ++++++++++++++-
 ...ytes_destination_geo_country_iso_code.toml | 47 +++++++++++++++-
 ...ltration_ml_high_bytes_destination_ip.toml | 45 +++++++++++++++-
 ...ration_ml_high_bytes_destination_port.toml | 48 ++++++++++++++++-
 ...ml_high_bytes_destination_region_name.toml | 44 ++++++++++++++-
 ...high_bytes_written_to_external_device.toml | 45 +++++++++++++++-
 ...es_written_to_external_device_airdrop.toml | 45 +++++++++++++++-
 ...re_process_writing_to_external_device.toml | 45 +++++++++++++++-
 ...ml_dga_activity_using_sunburst_domain.toml | 45 +++++++++++++++-
 ...d_control_ml_dga_high_sum_probability.toml | 44 ++++++++++++++-
 ...l_ml_dns_request_high_dga_probability.toml | 44 ++++++++++++++-
 ..._request_predicted_to_be_a_dga_domain.toml | 45 +++++++++++++++-
 .../endpoint/elastic_endpoint_security.toml   | 45 +++++++++++++++-
 ...istence_suspicious_file_modifications.toml | 44 ++++++++++++++-
 ...ion_gcp_pub_sub_subscription_creation.toml | 49 ++++++++++++++++-
 ...collection_gcp_pub_sub_topic_creation.toml | 47 +++++++++++++++-
 ...nse_evasion_gcp_firewall_rule_created.toml | 46 +++++++++++++++-
 ...nse_evasion_gcp_firewall_rule_deleted.toml | 47 +++++++++++++++-
 ...se_evasion_gcp_firewall_rule_modified.toml | 47 +++++++++++++++-
 ...e_evasion_gcp_logging_bucket_deletion.toml | 48 ++++++++++++++++-
 ...nse_evasion_gcp_logging_sink_deletion.toml | 47 +++++++++++++++-
 ...ion_gcp_pub_sub_subscription_deletion.toml | 47 +++++++++++++++-
 ...se_evasion_gcp_pub_sub_topic_deletion.toml | 49 ++++++++++++++++-
 ...storage_bucket_configuration_modified.toml | 47 +++++++++++++++-
 ...p_storage_bucket_permissions_modified.toml | 47 +++++++++++++++-
 ...virtual_private_cloud_network_deleted.toml | 47 +++++++++++++++-
 ...p_virtual_private_cloud_route_created.toml | 48 ++++++++++++++++-
 ...p_virtual_private_cloud_route_deleted.toml | 48 ++++++++++++++++-
 ...tration_gcp_logging_sink_modification.toml | 47 +++++++++++++++-
 .../gcp/impact_gcp_iam_role_deletion.toml     | 47 +++++++++++++++-
 .../impact_gcp_service_account_deleted.toml   | 49 ++++++++++++++++-
 .../impact_gcp_service_account_disabled.toml  | 47 +++++++++++++++-
 .../impact_gcp_storage_bucket_deleted.toml    | 47 +++++++++++++++-
 ...l_access_gcp_iam_custom_role_creation.toml | 51 +++++++++++++++++-
 ..._gcp_iam_service_account_key_deletion.toml | 47 +++++++++++++++-
 ...e_gcp_key_created_for_service_account.toml | 47 +++++++++++++++-
 ...rsistence_gcp_service_account_created.toml | 48 ++++++++++++++++-
 ...hub_protected_branch_settings_changed.toml | 45 +++++++++++++++-
 .../github/execution_github_app_deleted.toml  | 45 +++++++++++++++-
 ..._high_number_of_cloned_repos_from_pat.toml | 45 +++++++++++++++-
 ...multiple_behavior_alerts_from_account.toml | 44 ++++++++++++++-
 .../execution_new_github_app_installed.toml   | 45 +++++++++++++++-
 .../impact_github_repository_deleted.toml     | 44 ++++++++++++++-
 .../persistence_github_org_owner_added.toml   | 44 ++++++++++++++-
 ...tence_organization_owner_role_granted.toml | 46 +++++++++++++++-
 ...yption_key_accessed_by_anonymous_user.toml | 48 ++++++++++++++++-
 ...th_login_from_third_party_application.toml | 49 ++++++++++++++++-
 ...ogle_workspace_suspended_user_renewed.toml | 47 +++++++++++++++-
 ...covery_denied_service_account_request.toml | 50 ++++++++++++++++-
 ...covery_suspicious_self_subject_review.toml | 47 +++++++++++++++-
 .../execution_user_exec_to_pod.toml           | 47 +++++++++++++++-
 ...l_access_anonymous_request_authorized.toml | 47 +++++++++++++++-
 ...ed_service_created_with_type_nodeport.toml | 48 ++++++++++++++++-
 ...e_escalation_pod_created_with_hostipc.toml | 47 +++++++++++++++-
 ...calation_pod_created_with_hostnetwork.toml | 47 +++++++++++++++-
 ...e_escalation_pod_created_with_hostpid.toml | 47 +++++++++++++++-
 ...reated_with_sensitive_hostpath_volume.toml | 48 ++++++++++++++++-
 ...ege_escalation_privileged_pod_created.toml | 48 ++++++++++++++++-
 ...ignment_of_controller_service_account.toml | 47 +++++++++++++++-
 ...ovement_ml_high_mean_rdp_process_args.toml | 47 +++++++++++++++-
 ...ent_ml_high_mean_rdp_session_duration.toml | 45 +++++++++++++++-
 ...ral_movement_ml_high_remote_file_size.toml | 45 +++++++++++++++-
 ...ml_high_variance_rdp_session_duration.toml | 48 ++++++++++++++++-
 ...ovement_ml_rare_remote_file_directory.toml | 45 +++++++++++++++-
 ...ovement_ml_rare_remote_file_extension.toml | 45 +++++++++++++++-
 ...spike_in_connections_from_a_source_ip.toml | 45 +++++++++++++++-
 ...ke_in_connections_to_a_destination_ip.toml | 44 ++++++++++++++-
 ...al_movement_ml_spike_in_rdp_processes.toml | 45 +++++++++++++++-
 ...ent_ml_spike_in_remote_file_transfers.toml | 45 +++++++++++++++-
 ...nt_ml_unusual_time_for_an_rdp_session.toml | 45 +++++++++++++++-
 ...llection_microsoft_365_new_inbox_rule.toml | 48 ++++++++++++++++-
 ..._365_brute_force_user_account_attempt.toml | 48 ++++++++++++++++-
 ...65_potential_password_spraying_attack.toml | 49 ++++++++++++++++-
 ...ccess_user_excessive_sso_logon_errors.toml | 48 ++++++++++++++++-
 ...osoft_365_exchange_dlp_policy_removed.toml | 47 +++++++++++++++-
 ...change_malware_filter_policy_deletion.toml | 47 +++++++++++++++-
 ..._365_exchange_malware_filter_rule_mod.toml | 49 ++++++++++++++++-
 ...65_exchange_safe_attach_rule_disabled.toml | 47 +++++++++++++++-
 ...oft_365_mailboxauditbypassassociation.toml | 47 +++++++++++++++-
 ..._365_exchange_transport_rule_creation.toml | 48 ++++++++++++++++-
 ...osoft_365_exchange_transport_rule_mod.toml | 47 +++++++++++++++-
 ...ft_365_mass_download_by_a_single_user.toml | 48 ++++++++++++++++-
 ...oft_365_potential_ransomware_activity.toml | 48 ++++++++++++++++-
 ...t_365_unusual_volume_of_file_deletion.toml | 48 ++++++++++++++++-
 ...5_exchange_anti_phish_policy_deletion.toml | 47 +++++++++++++++-
 ...soft_365_exchange_anti_phish_rule_mod.toml | 47 +++++++++++++++-
 ...osoft_365_exchange_safelinks_disabled.toml | 47 +++++++++++++++-
 ...rosoft_365_impossible_travel_activity.toml | 46 +++++++++++++++-
 ...t_365_impossible_travel_portal_logins.toml | 46 +++++++++++++++-
 ...t_365_portal_login_from_rare_location.toml | 45 +++++++++++++++-
 ...65_user_restricted_from_sending_email.toml | 49 ++++++++++++++++-
 ...cess_o365_user_reported_phish_malware.toml | 49 ++++++++++++++++-
 ...al_movement_malware_uploaded_onedrive.toml | 48 ++++++++++++++++-
 ..._movement_malware_uploaded_sharepoint.toml | 48 ++++++++++++++++-
 ...e_suspicious_mailbox_right_delegation.toml | 48 ++++++++++++++++-
 ...exchange_dkim_signing_config_disabled.toml | 47 +++++++++++++++-
 ...5_exchange_management_role_assignment.toml | 47 +++++++++++++++-
 ..._365_global_administrator_role_assign.toml | 47 +++++++++++++++-
 ..._teams_custom_app_interaction_allowed.toml | 49 ++++++++++++++++-
 ...oft_365_teams_external_access_enabled.toml | 48 ++++++++++++++++-
 ...rosoft_365_teams_guest_access_enabled.toml | 47 +++++++++++++++-
 ...ion_new_or_modified_federation_domain.toml | 47 +++++++++++++++-
 ..._app_client_credential_token_exchange.toml | 45 +++++++++++++++-
 ...ta_attempt_to_delete_okta_application.toml | 47 +++++++++++++++-
 ...ta_attempt_to_modify_okta_application.toml | 47 +++++++++++++++-
 .../okta/impact_possible_okta_dos_attack.toml | 47 +++++++++++++++-
 ...initial_access_okta_fastpass_phishing.toml | 51 +++++++++++++++++-
 ...ta_user_attempted_unauthorized_access.toml | 51 +++++++++++++++++-
 ...cation_sso_from_unknown_client_device.toml | 47 +++++++++++++++-
 ...icious_activity_reported_by_okta_user.toml | 51 +++++++++++++++++-
 ...ent_multiple_sessions_for_single_user.toml | 48 ++++++++++++++++-
 ...tor_privileges_assigned_to_okta_group.toml | 47 +++++++++++++++-
 ...inistrator_role_assigned_to_okta_user.toml | 46 +++++++++++++++-
 ...ence_attempt_to_create_okta_api_token.toml | 47 +++++++++++++++-
 ...set_mfa_factors_for_okta_user_account.toml | 47 +++++++++++++++-
 ..._or_delete_application_sign_on_policy.toml | 50 ++++++++++++++++-
 ...se_evasion_ml_rare_process_for_a_host.toml | 44 ++++++++++++++-
 ..._ml_rare_process_for_a_parent_process.toml | 45 +++++++++++++++-
 ...se_evasion_ml_rare_process_for_a_user.toml | 44 ++++++++++++++-
 ...icious_windows_event_high_probability.toml | 45 +++++++++++++++-
 ...picious_windows_event_low_probability.toml | 49 ++++++++++++++++-
 ...ous_windows_process_cluster_from_host.toml | 45 +++++++++++++++-
 ...s_process_cluster_from_parent_process.toml | 48 ++++++++++++++++-
 ...ous_windows_process_cluster_from_user.toml | 44 ++++++++++++++-
 .../collection_linux_clipboard_activity.toml  | 44 ++++++++++++++-
 ...and_control_aws_cli_endpoint_url_used.toml | 45 +++++++++++++++-
 ...and_control_curl_socks_proxy_detected.toml | 45 +++++++++++++++-
 ...nd_and_control_ip_forwarding_activity.toml | 47 +++++++++++++++-
 ...mand_and_control_linux_kworker_netcon.toml | 44 ++++++++++++++-
 ...ial_access_collection_sensitive_files.toml | 45 +++++++++++++++-
 .../credential_access_credential_dumping.toml | 44 ++++++++++++++-
 ...ntial_access_gdb_init_process_hooking.toml | 45 +++++++++++++++-
 ...credential_access_gdb_process_hooking.toml | 45 +++++++++++++++-
 ...ential_linux_local_account_bruteforce.toml | 45 +++++++++++++++-
 ...ntial_successful_linux_ftp_bruteforce.toml | 44 ++++++++++++++-
 ...ntial_successful_linux_rdp_bruteforce.toml | 45 +++++++++++++++-
 ...ential_access_proc_credential_dumping.toml | 46 +++++++++++++++-
 .../credential_access_ssh_backdoor_log.toml   | 46 +++++++++++++++-
 ...instance_metadata_service_api_request.toml | 48 ++++++++++++++++-
 ..._evasion_acl_modification_via_setfacl.toml | 44 ++++++++++++++-
 ...ion_attempt_to_disable_auditd_service.toml | 46 +++++++++++++++-
 ...tempt_to_disable_iptables_or_firewall.toml | 44 ++++++++++++++-
 ...ion_attempt_to_disable_syslog_service.toml | 44 ++++++++++++++-
 ..._base32_encoding_or_decoding_activity.toml | 44 ++++++++++++++-
 ...binary_copied_to_suspicious_directory.toml | 45 +++++++++++++++-
 ...defense_evasion_chattr_immutable_file.toml | 45 +++++++++++++++-
 ...ense_evasion_clear_kernel_ring_buffer.toml | 46 +++++++++++++++-
 ..._creation_of_hidden_files_directories.toml | 45 +++++++++++++++-
 ...nse_evasion_directory_creation_in_bin.toml | 44 ++++++++++++++-
 ...ense_evasion_disable_apparmor_attempt.toml | 45 +++++++++++++++-
 ...fense_evasion_disable_selinux_attempt.toml | 46 +++++++++++++++-
 ...doas_configuration_creation_or_rename.toml | 44 ++++++++++++++-
 ..._evasion_dynamic_linker_file_creation.toml | 46 +++++++++++++++-
 ...asion_esxi_suspicious_timestomp_touch.toml | 44 ++++++++++++++-
 ...fense_evasion_file_deletion_via_shred.toml | 45 +++++++++++++++-
 ...defense_evasion_file_mod_writable_dir.toml | 45 +++++++++++++++-
 ...defense_evasion_hex_payload_execution.toml | 45 +++++++++++++++-
 ...nse_evasion_hidden_directory_creation.toml | 45 +++++++++++++++-
 .../defense_evasion_hidden_file_dir_tmp.toml  | 45 +++++++++++++++-
 .../defense_evasion_hidden_shared_object.toml | 45 +++++++++++++++-
 ...on_interactive_shell_from_system_user.toml | 45 +++++++++++++++-
 ...defense_evasion_kernel_module_removal.toml | 44 ++++++++++++++-
 ...defense_evasion_kthreadd_masquerading.toml | 45 +++++++++++++++-
 .../linux/defense_evasion_ld_so_creation.toml | 45 +++++++++++++++-
 .../defense_evasion_log_files_deleted.toml    | 45 +++++++++++++++-
 .../defense_evasion_mount_execution.toml      | 45 +++++++++++++++-
 ...ense_evasion_potential_proot_exploits.toml | 45 +++++++++++++++-
 .../defense_evasion_rename_esxi_files.toml    | 48 ++++++++++++++++-
 ...efense_evasion_rename_esxi_index_file.toml | 47 +++++++++++++++-
 ...evasion_root_certificate_installation.toml | 44 ++++++++++++++-
 ...ux_configuration_creation_or_renaming.toml | 46 +++++++++++++++-
 ...ense_evasion_ssl_certificate_deletion.toml | 44 ++++++++++++++-
 ...s_utility_executed_via_tmux_or_screen.toml | 45 +++++++++++++++-
 ...ense_evasion_unusual_preload_env_vars.toml | 48 ++++++++++++++++-
 .../discovery_dynamic_linker_via_od.toml      | 46 +++++++++++++++-
 .../discovery_esxi_software_via_find.toml     | 45 +++++++++++++++-
 .../discovery_esxi_software_via_grep.toml     | 46 +++++++++++++++-
 .../discovery_kernel_module_enumeration.toml  | 48 ++++++++++++++++-
 .../linux/discovery_linux_hping_activity.toml | 45 +++++++++++++++-
 .../linux/discovery_linux_nping_activity.toml | 43 ++++++++++++++-
 .../discovery_pam_version_discovery.toml      | 46 +++++++++++++++-
 .../linux/discovery_ping_sweep_detected.toml  | 45 +++++++++++++++-
 ...ivate_key_password_searching_activity.toml | 46 +++++++++++++++-
 rules/linux/discovery_proc_maps_read.toml     | 45 +++++++++++++++-
 .../linux/discovery_process_capabilities.toml | 46 +++++++++++++++-
 ...very_pspy_process_monitoring_detected.toml | 43 ++++++++++++++-
 ...curity_file_access_via_common_utility.toml | 44 ++++++++++++++-
 ...very_sudo_allowed_command_enumeration.toml | 45 +++++++++++++++-
 .../discovery_suid_sguid_enumeration.toml     | 44 ++++++++++++++-
 ...overy_suspicious_memory_grep_activity.toml | 44 ++++++++++++++-
 ...ry_suspicious_which_command_execution.toml | 47 +++++++++++++++-
 ...overy_unusual_user_enumeration_via_id.toml | 45 +++++++++++++++-
 ...covery_virtual_machine_fingerprinting.toml | 46 +++++++++++++++-
 .../discovery_yum_dnf_plugin_detection.toml   | 45 +++++++++++++++-
 ...ion_curl_cve_2023_38545_heap_overflow.toml | 45 +++++++++++++++-
 ...nnection_from_entrypoint_in_container.toml | 45 +++++++++++++++-
 ...n_file_execution_followed_by_deletion.toml | 45 +++++++++++++++-
 .../execution_interpreter_tty_upgrade.toml    | 44 ++++++++++++++-
 .../execution_nc_listener_via_rlwrap.toml     | 44 ++++++++++++++-
 ...ion_netcon_from_rwx_mem_region_binary.toml | 48 ++++++++++++++++-
 ...cution_network_event_post_compilation.toml | 44 ++++++++++++++-
 rules/linux/execution_perl_tty_shell.toml     | 46 +++++++++++++++-
 ...xecution_potential_hack_tool_executed.toml | 48 ++++++++++++++++-
 ..._overly_permissive_container_creation.toml | 44 ++++++++++++++-
 ...ss_started_in_shared_memory_directory.toml | 44 ++++++++++++++-
 rules/linux/execution_python_tty_shell.toml   | 49 ++++++++++++++++-
 .../execution_python_webserver_spawned.toml   | 49 ++++++++++++++++-
 ..._remote_code_execution_via_postgresql.toml | 45 +++++++++++++++-
 ...cution_shell_openssl_client_or_server.toml | 44 ++++++++++++++-
 ...xecution_shell_via_background_process.toml | 45 +++++++++++++++-
 ...ion_shell_via_child_tcp_utility_linux.toml | 45 +++++++++++++++-
 ...ecution_shell_via_java_revshell_linux.toml | 45 +++++++++++++++-
 ...on_shell_via_lolbin_interpreter_linux.toml | 44 ++++++++++++++-
 ...execution_shell_via_meterpreter_linux.toml | 45 +++++++++++++++-
 ...execution_shell_via_suspicious_binary.toml | 45 +++++++++++++++-
 ...ution_shell_via_tcp_cli_utility_linux.toml | 45 +++++++++++++++-
 ...ution_shell_via_udp_cli_utility_linux.toml | 48 ++++++++++++++++-
 ...traction_or_decrompression_via_funzip.toml | 44 ++++++++++++++-
 ...us_executable_running_system_commands.toml | 46 +++++++++++++++-
 ...icious_mining_process_creation_events.toml | 44 ++++++++++++++-
 rules/linux/execution_tc_bpf_filter.toml      | 45 +++++++++++++++-
 .../execution_unix_socket_communication.toml  | 45 +++++++++++++++-
 ...nknown_rwx_mem_region_binary_executed.toml | 45 +++++++++++++++-
 ...ntial_data_splitting_for_exfiltration.toml | 45 +++++++++++++++-
 .../impact_data_encrypted_via_openssl.toml    | 45 +++++++++++++++-
 rules/linux/impact_esxi_process_kill.toml     | 45 +++++++++++++++-
 .../impact_memory_swap_modification.toml      | 45 +++++++++++++++-
 ...ential_linux_ransomware_note_detected.toml | 45 +++++++++++++++-
 ...lateral_movement_ssh_it_worm_download.toml | 48 ++++++++++++++++-
 ...ment_telnet_network_activity_external.toml | 45 +++++++++++++++-
 ...ment_telnet_network_activity_internal.toml | 44 ++++++++++++++-
 ...istence_apt_package_manager_execution.toml | 44 ++++++++++++++-
 ...nce_apt_package_manager_file_creation.toml | 46 +++++++++++++++-
 ...ersistence_apt_package_manager_netcon.toml | 46 +++++++++++++++-
 rules/linux/persistence_at_job_creation.toml  | 46 +++++++++++++++-
 ..._package_manager_plugin_file_creation.toml | 46 +++++++++++++++-
 ...kage_installation_from_unusual_parent.toml | 44 ++++++++++++++-
 .../persistence_dpkg_unusual_execution.toml   | 45 +++++++++++++++-
 .../linux/persistence_git_hook_execution.toml | 45 +++++++++++++++-
 .../persistence_git_hook_file_creation.toml   | 45 +++++++++++++++-
 rules/linux/persistence_git_hook_netcon.toml  | 44 ++++++++++++++-
 ...ersistence_git_hook_process_execution.toml | 45 +++++++++++++++-
 .../linux/persistence_kernel_driver_load.toml | 45 +++++++++++++++-
 ...stence_kernel_driver_load_by_non_root.toml | 45 +++++++++++++++-
 ...rsistence_kernel_object_file_creation.toml | 45 +++++++++++++++-
 ...tence_lkm_configuration_file_creation.toml | 53 ++++++++++++++++++-
 ...ggable_authentication_module_creation.toml | 46 +++++++++++++++-
 ...cation_module_creation_in_unusual_dir.toml | 48 ++++++++++++++++-
 ...authentication_module_source_download.toml | 48 ++++++++++++++++-
 ...persistence_script_executable_bit_set.toml | 45 +++++++++++++++-
 ...nce_process_capability_set_via_setcap.toml | 48 ++++++++++++++++-
 ...persistence_rc_local_error_via_syslog.toml | 43 ++++++++++++++-
 ...ence_rc_local_service_already_running.toml | 45 +++++++++++++++-
 ...kage_installation_from_unusual_parent.toml | 45 +++++++++++++++-
 .../persistence_shadow_file_modification.toml | 45 +++++++++++++++-
 ...ence_shell_configuration_modification.toml | 47 +++++++++++++++-
 ...simple_web_server_connection_accepted.toml | 45 +++++++++++++++-
 ...ersistence_simple_web_server_creation.toml | 44 ++++++++++++++-
 .../linux/persistence_ssh_key_generation.toml | 45 +++++++++++++++-
 rules/linux/persistence_ssh_netcon.toml       | 45 +++++++++++++++-
 ...stence_ssh_via_backdoored_system_user.toml | 45 +++++++++++++++-
 ...suspicious_file_opened_through_editor.toml | 45 +++++++++++++++-
 ...e_suspicious_ssh_execution_xzbackdoor.toml | 45 +++++++++++++++-
 ...ersistence_systemd_generator_creation.toml | 45 +++++++++++++++-
 rules/linux/persistence_systemd_netcon.toml   | 48 ++++++++++++++++-
 ...ersistence_tainted_kernel_module_load.toml | 48 ++++++++++++++++-
 ...ainted_kernel_module_out_of_tree_load.toml | 44 ++++++++++++++-
 .../linux/persistence_udev_rule_creation.toml | 45 +++++++++++++++-
 .../persistence_unusual_pam_grantor.toml      | 45 +++++++++++++++-
 ...ersistence_unusual_sshd_child_process.toml | 44 ++++++++++++++-
 ...ser_or_group_creation_or_modification.toml | 44 ++++++++++++++-
 .../persistence_xdg_autostart_netcon.toml     | 49 ++++++++++++++++-
 ..._package_manager_plugin_file_creation.toml | 45 +++++++++++++++-
 ...on_chown_chmod_unauthorized_file_read.toml | 44 ++++++++++++++-
 ...ation_container_util_misconfiguration.toml | 45 +++++++++++++++-
 .../privilege_escalation_dac_permissions.toml | 46 +++++++++++++++-
 ..._escalation_docker_escape_via_nsenter.toml | 44 ++++++++++++++-
 ..._docker_mount_chroot_container_escape.toml | 46 +++++++++++++++-
 ...calation_enlightenment_window_manager.toml | 44 ++++++++++++++-
 ...e_escalation_gdb_sys_ptrace_elevation.toml | 44 ++++++++++++++-
 ...lege_escalation_gdb_sys_ptrace_netcon.toml | 48 ++++++++++++++++-
 ...lege_escalation_kworker_uid_elevation.toml | 47 +++++++++++++++-
 ...lation_ld_preload_shared_object_modif.toml | 47 +++++++++++++++-
 ...lation_linux_suspicious_symbolic_link.toml | 45 +++++++++++++++-
 ...lege_escalation_linux_uid_int_max_bug.toml | 44 ++++++++++++++-
 ...n_load_and_unload_of_kernel_via_kexec.toml | 44 ++++++++++++++-
 ...alation_looney_tunables_cve_2023_4911.toml | 44 ++++++++++++++-
 ...ege_escalation_netcon_via_sudo_binary.toml | 45 +++++++++++++++-
 ...ge_escalation_overlayfs_local_privesc.toml | 44 ++++++++++++++-
 ...vilege_escalation_pkexec_envar_hijack.toml | 45 +++++++++++++++-
 ...ation_potential_bufferoverflow_attack.toml | 45 +++++++++++++++-
 ...tion_potential_suid_sgid_exploitation.toml | 45 +++++++++++++++-
 ...lation_potential_wildcard_shell_spawn.toml | 46 +++++++++++++++-
 ...ge_escalation_sda_disk_mount_non_root.toml | 45 +++++++++++++++-
 ...privilege_escalation_shadow_file_read.toml | 45 +++++++++++++++-
 ...vilege_escalation_sudo_cve_2019_14287.toml | 44 ++++++++++++++-
 .../privilege_escalation_sudo_hijacking.toml  | 46 +++++++++++++++-
 ...tion_sudo_token_via_process_injection.toml | 44 ++++++++++++++-
 ...uspicious_cap_setuid_python_execution.toml | 44 ++++++++++++++-
 ...ion_suspicious_chown_fowner_elevation.toml | 47 +++++++++++++++-
 ...calation_suspicious_passwd_file_write.toml | 44 ++++++++++++++-
 ...alation_suspicious_uid_guid_elevation.toml | 45 +++++++++++++++-
 ...scalation_uid_change_post_compilation.toml | 44 ++++++++++++++-
 ...uid_elevation_from_unknown_executable.toml | 48 ++++++++++++++++-
 ...lation_unshare_namespace_manipulation.toml | 45 +++++++++++++++-
 ...ege_escalation_writable_docker_socket.toml | 44 ++++++++++++++-
 ...edential_access_credentials_keychains.toml | 45 +++++++++++++++-
 ...dential_access_dumping_hashes_bi_cmds.toml | 44 ++++++++++++++-
 ...tial_access_dumping_keychain_security.toml | 45 +++++++++++++++-
 .../credential_access_kerberosdump_kcc.toml   | 44 ++++++++++++++-
 ...s_keychain_pwd_retrieval_security_cmd.toml | 48 ++++++++++++++++-
 ...ential_access_mitm_localhost_webproxy.toml | 44 ++++++++++++++-
 ...access_potential_macos_ssh_bruteforce.toml | 44 ++++++++++++++-
 ...al_access_promt_for_pwd_via_osascript.toml | 44 ++++++++++++++-
 ...ous_web_browser_sensitive_file_access.toml | 44 ++++++++++++++-
 .../credential_access_systemkey_dumping.toml  | 44 ++++++++++++++-
 ...vasion_apple_softupdates_modification.toml | 44 ++++++++++++++-
 ...evasion_attempt_del_quarantine_attrib.toml | 49 ++++++++++++++++-
 ...evasion_attempt_to_disable_gatekeeper.toml | 44 ++++++++++++++-
 ...ense_evasion_install_root_certificate.toml | 45 +++++++++++++++-
 ..._evasion_modify_environment_launchctl.toml | 45 +++++++++++++++-
 ...cy_controls_tcc_database_modification.toml | 44 ++++++++++++++-
 ...tion_privacy_pref_sshd_fulldiskaccess.toml | 45 +++++++++++++++-
 .../defense_evasion_safari_config_change.toml | 45 +++++++++++++++-
 ...dboxed_office_app_suspicious_zip_file.toml | 45 +++++++++++++++-
 ...vasion_tcc_bypass_mounted_apfs_access.toml | 45 +++++++++++++++-
 ..._evasion_unload_endpointsecurity_kext.toml | 49 ++++++++++++++++-
 ...covery_users_domain_built_in_commands.toml | 45 +++++++++++++++-
 ...vasion_electron_app_childproc_node_js.toml | 49 ++++++++++++++++-
 ...l_access_suspicious_browser_childproc.toml | 45 +++++++++++++++-
 ...staller_package_spawned_network_event.toml | 45 +++++++++++++++-
 ...cution_script_via_automator_workflows.toml | 46 +++++++++++++++-
 ...ing_osascript_exec_followed_by_netcon.toml | 44 ++++++++++++++-
 ...n_shell_execution_via_apple_scripting.toml | 44 ++++++++++++++-
 ...uspicious_mac_ms_office_child_process.toml | 47 +++++++++++++++-
 ...ential_access_kerberos_bifrostconsole.toml | 44 ++++++++++++++-
 .../lateral_movement_mounting_smb_share.toml  | 45 +++++++++++++++-
 ...ral_movement_remote_ssh_login_enabled.toml | 45 +++++++++++++++-
 ...teral_movement_vpn_connection_attempt.toml | 44 ++++++++++++++-
 ...stence_account_creation_hide_at_logon.toml | 44 ++++++++++++++-
 ...ce_creation_change_launch_agents_file.toml | 45 +++++++++++++++-
 ..._creation_hidden_login_item_osascript.toml | 44 ++++++++++++++-
 ...creation_modif_launch_deamon_sequence.toml | 45 +++++++++++++++-
 ..._access_authorization_plugin_creation.toml | 46 +++++++++++++++-
 rules/macos/persistence_crontab_creation.toml | 45 +++++++++++++++-
 ...launch_agent_deamon_logonitem_process.toml | 51 +++++++++++++++++-
 ...rectory_services_plugins_modification.toml | 45 +++++++++++++++-
 ...e_docker_shortcuts_plist_modification.toml | 45 +++++++++++++++-
 ...persistence_emond_rules_file_creation.toml | 44 ++++++++++++++-
 ...istence_emond_rules_process_execution.toml | 44 ++++++++++++++-
 .../persistence_enable_root_account.toml      | 44 ++++++++++++++-
 ...n_hidden_launch_agent_deamon_creation.toml | 48 ++++++++++++++++-
 ...sistence_finder_sync_plugin_pluginkit.toml | 49 ++++++++++++++++-
 ...istence_folder_action_scripts_runtime.toml | 45 +++++++++++++++-
 ...rsistence_login_logout_hooks_defaults.toml | 45 +++++++++++++++-
 ...fication_sublime_app_plugin_or_script.toml | 45 +++++++++++++++-
 ...ersistence_periodic_tasks_file_mdofiy.toml | 45 +++++++++++++++-
 ...ence_suspicious_calendar_modification.toml | 45 +++++++++++++++-
 ...tence_via_atom_init_file_modification.toml | 44 ++++++++++++++-
 ...calation_applescript_with_admin_privs.toml | 43 ++++++++++++++-
 ...calation_explicit_creds_via_scripting.toml | 45 +++++++++++++++-
 ...alation_exploit_adobe_acrobat_updater.toml | 47 +++++++++++++++-
 ..._escalation_local_user_added_to_admin.toml | 44 ++++++++++++++-
 ...ilege_escalation_root_crontab_filemod.toml | 44 ++++++++++++++-
 ...d_control_ml_packetbeat_dns_tunneling.toml | 46 +++++++++++++++-
 ...ntrol_ml_packetbeat_rare_dns_question.toml | 44 ++++++++++++++-
 ...d_and_control_ml_packetbeat_rare_urls.toml | 45 +++++++++++++++-
 ...control_ml_packetbeat_rare_user_agent.toml | 44 ++++++++++++++-
 ..._access_ml_auth_spike_in_logon_events.toml | 45 +++++++++++++++-
 ...s_ml_linux_anomalous_metadata_process.toml | 45 +++++++++++++++-
 ...cess_ml_linux_anomalous_metadata_user.toml | 44 ++++++++++++++-
 ...l_access_ml_suspicious_login_activity.toml | 47 +++++++++++++++-
 ...ml_windows_anomalous_metadata_process.toml | 44 ++++++++++++++-
 ...ss_ml_windows_anomalous_metadata_user.toml | 45 +++++++++++++++-
 ...ml_linux_system_information_discovery.toml | 44 ++++++++++++++-
 ...ystem_network_configuration_discovery.toml | 45 +++++++++++++++-
 ...x_system_network_connection_discovery.toml | 45 +++++++++++++++-
 ...ery_ml_linux_system_process_discovery.toml | 45 +++++++++++++++-
 ...covery_ml_linux_system_user_discovery.toml | 45 +++++++++++++++-
 ...execution_ml_windows_anomalous_script.toml | 44 ++++++++++++++-
 ...ess_ml_auth_rare_source_ip_for_a_user.toml | 46 +++++++++++++++-
 rules/ml/ml_high_count_network_denies.toml    | 50 ++++++++++++++++-
 rules/ml/ml_high_count_network_events.toml    | 46 +++++++++++++++-
 ...linux_anomalous_network_port_activity.toml | 49 ++++++++++++++++-
 .../ml/ml_packetbeat_rare_server_domain.toml  | 45 +++++++++++++++-
 rules/ml/ml_rare_destination_country.toml     | 46 +++++++++++++++-
 ...ce_ml_windows_anomalous_path_activity.toml | 46 +++++++++++++++-
 ...sistence_ml_windows_anomalous_service.toml | 43 ++++++++++++++-
 ...tion_ml_linux_anomalous_sudo_activity.toml | 48 ++++++++++++++++-
 ...tion_ml_windows_rare_user_runas_event.toml | 45 +++++++++++++++-
 ..._ml_linux_anomalous_compiler_activity.toml | 45 +++++++++++++++-
 ...cepted_default_telnet_port_connection.toml | 45 +++++++++++++++-
 ...mand_and_control_cobalt_strike_beacon.toml | 49 ++++++++++++++++-
 ...cobalt_strike_default_teamserver_cert.toml | 47 +++++++++++++++-
 ...download_rar_powershell_from_internet.toml | 51 +++++++++++++++++-
 .../command_and_control_halfbaked_beacon.toml | 48 ++++++++++++++++-
 ...d_control_nat_traversal_port_activity.toml | 45 +++++++++++++++-
 .../command_and_control_port_26_activity.toml | 45 +++++++++++++++-
 ...te_desktop_protocol_from_the_internet.toml | 45 +++++++++++++++-
 ...l_network_computing_from_the_internet.toml | 48 ++++++++++++++++-
 ...ual_network_computing_to_the_internet.toml | 46 +++++++++++++++-
 ...very_potential_network_sweep_detected.toml | 44 ++++++++++++++-
 ...iscovery_potential_port_scan_detected.toml | 43 ++++++++++++++-
 ...very_potential_syn_port_scan_detected.toml | 45 +++++++++++++++-
 ...mote_procedure_call_from_the_internet.toml | 49 ++++++++++++++++-
 ...remote_procedure_call_to_the_internet.toml | 45 +++++++++++++++-
 ...file_sharing_activity_to_the_internet.toml | 46 +++++++++++++++-
 ...al_access_unsecure_elasticsearch_node.toml | 48 ++++++++++++++++-
 ..._access_endgame_cred_dumping_detected.toml | 48 ++++++++++++++++-
 ...access_endgame_cred_dumping_prevented.toml | 45 +++++++++++++++-
 .../endgame_adversary_behavior_detected.toml  | 44 ++++++++++++++-
 .../promotions/endgame_malware_detected.toml  | 45 +++++++++++++++-
 .../promotions/endgame_malware_prevented.toml | 45 +++++++++++++++-
 .../endgame_ransomware_detected.toml          | 48 ++++++++++++++++-
 .../endgame_ransomware_prevented.toml         | 44 ++++++++++++++-
 .../execution_endgame_exploit_detected.toml   | 46 +++++++++++++++-
 .../execution_endgame_exploit_prevented.toml  | 45 +++++++++++++++-
 rules/promotions/external_alerts.toml         | 44 ++++++++++++++-
 ...on_endgame_cred_manipulation_detected.toml | 44 ++++++++++++++-
 ...n_endgame_cred_manipulation_prevented.toml | 48 ++++++++++++++++-
 ...ion_endgame_permission_theft_detected.toml | 45 +++++++++++++++-
 ...on_endgame_permission_theft_prevented.toml | 44 ++++++++++++++-
 ...on_endgame_process_injection_detected.toml | 44 ++++++++++++++-
 ...n_endgame_process_injection_prevented.toml | 42 ++++++++++++++-
 ...lection_email_outlook_mailbox_via_com.toml | 44 ++++++++++++++-
 .../collection_posh_webcam_video_capture.toml | 49 ++++++++++++++++-
 ...control_encrypted_channel_freesslcert.toml | 46 +++++++++++++++-
 .../command_and_control_iexplore_via_com.toml | 48 ++++++++++++++++-
 ...command_and_control_outlook_home_page.toml | 44 ++++++++++++++-
 ...d_and_control_screenconnect_childproc.toml | 45 +++++++++++++++-
 .../command_and_control_tunnel_vscode.toml    | 44 ++++++++++++++-
 .../credential_access_adidns_wildcard.toml    | 45 +++++++++++++++-
 .../credential_access_adidns_wpad_record.toml | 45 +++++++++++++++-
 ...redential_access_dcsync_user_backdoor.toml | 47 +++++++++++++++-
 .../credential_access_dnsnode_creation.toml   | 45 +++++++++++++++-
 ...redential_access_dollar_account_relay.toml | 45 +++++++++++++++-
 .../credential_access_generic_localdumps.toml | 44 ++++++++++++++-
 ..._access_iis_connectionstrings_dumping.toml | 48 ++++++++++++++++-
 ...ccess_imageload_azureadconnectauthsvc.toml | 46 +++++++++++++++-
 .../windows/credential_access_kirbi_file.toml | 45 +++++++++++++++-
 .../credential_access_ldap_attributes.toml    | 48 ++++++++++++++++-
 ...l_access_lsass_handle_via_malseclogon.toml | 45 +++++++++++++++-
 ...edential_access_lsass_loaded_susp_dll.toml | 46 +++++++++++++++-
 .../credential_access_posh_relay_tools.toml   | 44 ++++++++++++++-
 .../credential_access_posh_veeam_sql.toml     | 44 ++++++++++++++-
 ..._potential_lsa_memdump_via_mirrordump.toml | 45 +++++++++++++++-
 ...cess_relay_ntlm_auth_via_http_spoolss.toml | 48 ++++++++++++++++-
 ...ntial_access_saved_creds_vault_winlog.toml | 45 +++++++++++++++-
 ...redential_access_saved_creds_vaultcmd.toml | 45 +++++++++++++++-
 ...ccess_suspicious_lsass_access_generic.toml | 50 ++++++++++++++++-
 ...ccess_suspicious_lsass_access_memdump.toml | 45 +++++++++++++++-
 ..._suspicious_lsass_access_via_snapshot.toml | 45 +++++++++++++++-
 ...ial_access_veeam_backup_dll_imageload.toml | 44 ++++++++++++++-
 .../credential_access_veeam_commands.toml     | 44 ++++++++++++++-
 ...ess_via_snapshot_lsass_clone_creation.toml | 45 +++++++++++++++-
 .../credential_access_wbadmin_ntds.toml       | 44 ++++++++++++++-
 .../defense_evasion_cve_2020_0601.toml        | 44 ++++++++++++++-
 .../windows/defense_evasion_disable_nla.toml  | 44 ++++++++++++++-
 ...efense_evasion_dns_over_https_enabled.toml | 44 ++++++++++++++-
 ...vasion_dotnet_compiler_parent_process.toml | 44 ++++++++++++++-
 ...ecution_control_panel_suspicious_args.toml | 45 +++++++++++++++-
 ...n_execution_msbuild_started_by_script.toml | 46 +++++++++++++++-
 ...ion_msbuild_started_by_system_process.toml | 44 ++++++++++++++-
 ...cution_msbuild_started_unusal_process.toml | 45 +++++++++++++++-
 ...execution_suspicious_explorer_winword.toml | 44 ++++++++++++++-
 ...sion_execution_windefend_unusual_path.toml | 44 ++++++++++++++-
 ..._evasion_file_creation_mult_extension.toml | 45 +++++++++++++++-
 ...sion_hide_encoded_executable_registry.toml | 44 ++++++++++++++-
 .../defense_evasion_injection_msbuild.toml    | 44 ++++++++++++++-
 .../defense_evasion_installutil_beacon.toml   | 45 +++++++++++++++-
 ...efense_evasion_lolbas_win_cdb_utility.toml | 47 +++++++++++++++-
 ...querading_as_elastic_endpoint_process.toml | 44 ++++++++++++++-
 ..._masquerading_business_apps_installer.toml | 45 +++++++++++++++-
 ...asion_masquerading_communication_apps.toml | 48 ++++++++++++++++-
 ...erading_suspicious_werfault_childproc.toml | 45 +++++++++++++++-
 ...vasion_masquerading_trusted_directory.toml | 45 +++++++++++++++-
 .../windows/defense_evasion_mshta_beacon.toml | 47 +++++++++++++++-
 ...nse_evasion_msiexec_child_proc_netcon.toml | 45 +++++++++++++++-
 .../defense_evasion_msxsl_network.toml        | 44 ++++++++++++++-
 ...e_evasion_parent_process_pid_spoofing.toml | 48 ++++++++++++++++-
 ...persistence_account_tokenfilterpolicy.toml | 46 +++++++++++++++-
 .../defense_evasion_posh_obfuscation.toml     | 45 +++++++++++++++-
 ...ense_evasion_proxy_execution_via_msdt.toml | 47 +++++++++++++++-
 ...eg_disable_enableglobalqueryblocklist.toml | 46 +++++++++++++++-
 ...defense_evasion_root_dir_ads_creation.toml | 45 +++++++++++++++-
 rules/windows/defense_evasion_sc_sdset.toml   | 44 ++++++++++++++-
 ...fense_evasion_sccm_scnotification_dll.toml | 48 ++++++++++++++++-
 ...ion_scheduledjobs_at_protocol_enabled.toml | 46 +++++++++++++++-
 .../defense_evasion_script_via_html_app.toml  | 48 ++++++++++++++++-
 .../defense_evasion_sip_provider_mod.toml     | 44 ++++++++++++++-
 ...ackdoor_service_disabled_via_registry.toml | 48 ++++++++++++++++-
 ...picious_execution_from_mounted_device.toml | 45 +++++++++++++++-
 ...n_suspicious_managedcode_host_process.toml | 45 +++++++++++++++-
 ...efense_evasion_suspicious_scrobj_load.toml | 45 +++++++++++++++-
 ...defense_evasion_suspicious_wmi_script.toml | 44 ++++++++++++++-
 .../defense_evasion_timestomp_sysmon.toml     | 45 +++++++++++++++-
 ...sion_unsigned_dll_loaded_from_suspdir.toml | 46 +++++++++++++++-
 .../defense_evasion_unusual_dir_ads.toml      | 45 +++++++++++++++-
 ...nusual_network_connection_via_dllhost.toml | 45 +++++++++++++++-
 ...asion_unusual_system_vp_child_program.toml | 44 ++++++++++++++-
 ...se_evasion_windows_filtering_platform.toml | 45 +++++++++++++++-
 .../defense_evasion_wsl_bash_exec.toml        | 48 ++++++++++++++++-
 .../defense_evasion_wsl_child_process.toml    | 46 +++++++++++++++-
 .../defense_evasion_wsl_filesystem.toml       | 48 ++++++++++++++++-
 .../defense_evasion_wsl_kalilinux.toml        | 46 +++++++++++++++-
 ...discovery_active_directory_webservice.toml | 45 +++++++++++++++-
 .../discovery_high_number_ad_properties.toml  | 44 ++++++++++++++-
 ...unusual_discovery_signal_proc_cmdline.toml | 44 ++++++++++++++-
 ...sual_discovery_signal_proc_executable.toml | 44 ++++++++++++++-
 ...arwinds_backdoor_child_cmd_powershell.toml | 44 ++++++++++++++-
 ...inds_backdoor_unusual_child_processes.toml | 45 +++++++++++++++-
 .../windows/execution_com_object_xwizard.toml | 45 +++++++++++++++-
 ...mand_shell_started_by_unusual_process.toml | 44 ++++++++++++++-
 .../execution_command_shell_via_rundll32.toml | 46 +++++++++++++++-
 ...tion_delayed_via_ping_lolbas_unsigned.toml | 45 +++++++++++++++-
 .../execution_downloaded_shortcut_files.toml  | 45 +++++++++++++++-
 .../execution_downloaded_url_file.toml        | 44 ++++++++++++++-
 .../execution_enumeration_via_wmiprvse.toml   | 52 +++++++++++++++++-
 ...cution_initial_access_foxmail_exploit.toml | 44 ++++++++++++++-
 ...cution_initial_access_wps_dll_exploit.toml | 45 +++++++++++++++-
 rules/windows/execution_mofcomp.toml          | 44 ++++++++++++++-
 .../execution_posh_hacktool_authors.toml      | 46 +++++++++++++++-
 ...on_powershell_susp_args_via_winscript.toml | 46 +++++++++++++++-
 ...tion_scheduled_task_powershell_source.toml | 45 +++++++++++++++-
 .../windows/execution_suspicious_cmd_wmi.toml | 50 ++++++++++++++++-
 ...n_suspicious_image_load_wmi_ms_office.toml | 44 ++++++++++++++-
 ...ion_via_mmc_console_file_unusual_path.toml | 45 +++++++++++++++-
 ...execution_windows_cmd_shell_susp_args.toml | 45 +++++++++++++++-
 ...xecution_windows_powershell_susp_args.toml | 45 +++++++++++++++-
 .../exfiltration_smb_rare_destination.toml    | 46 +++++++++++++++-
 ..._evasion_suspicious_htm_file_creation.toml | 48 ++++++++++++++++-
 ...itial_access_execution_from_inetcache.toml | 45 +++++++++++++++-
 ...access_execution_from_removable_media.toml | 45 +++++++++++++++-
 ...l_access_execution_remote_via_msiexec.toml | 49 ++++++++++++++++-
 ...al_access_execution_via_office_addins.toml | 48 ++++++++++++++++-
 ...cess_exfiltration_first_time_seen_usb.toml | 42 ++++++++++++++-
 ...ial_access_exploit_jetbrains_teamcity.toml | 45 +++++++++++++++-
 ...itial_access_rdp_file_mail_attachment.toml | 45 +++++++++++++++-
 ...ccess_scripts_process_started_via_wmi.toml | 46 +++++++++++++++-
 ...access_suspicious_ms_exchange_process.toml | 49 ++++++++++++++++-
 ...ious_ms_exchange_worker_child_process.toml | 47 +++++++++++++++-
 ...explorer_suspicious_child_parent_args.toml | 46 +++++++++++++++-
 ..._access_webshell_screenconnect_server.toml | 44 ++++++++++++++-
 ...l_access_xsl_script_execution_via_com.toml | 44 ++++++++++++++-
 .../lateral_movement_alternate_creds_pth.toml | 45 +++++++++++++++-
 .../windows/lateral_movement_cmd_service.toml | 45 +++++++++++++++-
 rules/windows/lateral_movement_dcom_hta.toml  | 45 +++++++++++++++-
 .../windows/lateral_movement_dcom_mmc20.toml  | 47 +++++++++++++++-
 ...t_dcom_shellwindow_shellbrowserwindow.toml | 48 ++++++++++++++++-
 ...n_lanman_nullsessionpipe_modification.toml | 45 +++++++++++++++-
 ...ateral_movement_evasion_rdp_shadowing.toml | 49 ++++++++++++++++-
 ..._movement_execution_from_tsclient_mup.toml | 44 ++++++++++++++-
 ...vement_incoming_winrm_shell_execution.toml | 45 +++++++++++++++-
 .../lateral_movement_incoming_wmi.toml        | 46 +++++++++++++++-
 ...ment_mount_hidden_or_webdav_share_net.toml | 45 +++++++++++++++-
 ...l_movement_powershell_remoting_target.toml | 48 ++++++++++++++++-
 .../lateral_movement_rdp_sharprdp_target.toml | 44 ++++++++++++++-
 ...ovement_remote_file_copy_hidden_share.toml | 45 +++++++++++++++-
 ...ement_remote_service_installed_winlog.toml | 46 +++++++++++++++-
 ...ement_suspicious_rdp_client_imageload.toml | 44 ++++++++++++++-
 ...l_movement_via_startup_folder_rdp_smb.toml | 45 +++++++++++++++-
 .../lateral_movement_via_wsus_update.toml     | 44 ++++++++++++++-
 .../windows/persistence_ad_adminsdholder.toml | 46 +++++++++++++++-
 .../windows/persistence_app_compat_shim.toml  | 44 ++++++++++++++-
 .../persistence_appcertdlls_registry.toml     | 45 +++++++++++++++-
 ...persistence_browser_extension_install.toml | 45 +++++++++++++++-
 ...tence_evasion_registry_ifeo_injection.toml | 47 +++++++++++++++-
 ...sistence_group_modification_by_system.toml | 44 ++++++++++++++-
 ...sistence_local_scheduled_job_creation.toml | 47 +++++++++++++++-
 ...istence_local_scheduled_task_creation.toml | 46 +++++++++++++++-
 .../persistence_ms_office_addins_file.toml    | 44 ++++++++++++++-
 .../persistence_ms_outlook_vba_template.toml  | 44 ++++++++++++++-
 ...istence_msds_alloweddelegateto_krbtgt.toml | 45 +++++++++++++++-
 ...ersistence_msi_installer_task_startup.toml | 48 ++++++++++++++++-
 ...persistence_msoffice_startup_registry.toml | 44 ++++++++++++++-
 .../windows/persistence_netsh_helper_dll.toml | 44 ++++++++++++++-
 ...ll_exch_mailbox_activesync_add_device.toml | 44 ++++++++++++++-
 .../persistence_registry_uncommon.toml        | 45 +++++++++++++++-
 .../persistence_remote_password_reset.toml    | 47 +++++++++++++++-
 ...ce_runtime_run_key_startup_susp_procs.toml | 45 +++++++++++++++-
 ...stence_scheduled_task_creation_winlog.toml | 44 ++++++++++++++-
 .../persistence_scheduled_task_updated.toml   | 45 +++++++++++++++-
 .../persistence_service_dll_unsigned.toml     | 45 +++++++++++++++-
 .../persistence_services_registry.toml        | 45 +++++++++++++++-
 ...nce_suspicious_scheduled_task_runtime.toml | 48 ++++++++++++++++-
 ...e_suspicious_service_created_registry.toml | 45 +++++++++++++++-
 ...istence_sysmon_wmi_event_subscription.toml | 45 +++++++++++++++-
 .../persistence_temp_scheduled_task.toml      | 45 +++++++++++++++-
 ...ence_user_account_creation_event_logs.toml | 44 ++++++++++++++-
 .../persistence_via_application_shimming.toml | 45 +++++++++++++++-
 ...rsistence_via_bits_job_notify_command.toml | 48 ++++++++++++++++-
 ...sistence_via_hidden_run_key_valuename.toml | 45 +++++++++++++++-
 ...sa_security_support_provider_registry.toml | 44 ++++++++++++++-
 ...emetrycontroller_scheduledtask_hijack.toml | 45 +++++++++++++++-
 ...nt_instrumentation_event_subscription.toml | 45 +++++++++++++++-
 .../persistence_werfault_reflectdebugger.toml | 44 ++++++++++++++-
 ...tion_create_process_as_different_user.toml | 45 +++++++++++++++-
 ...tion_create_process_with_token_unpriv.toml | 45 +++++++++++++++-
 ...privilege_escalation_credroaming_ldap.toml | 45 +++++++++++++++-
 ...e_escalation_dns_serverlevelplugindll.toml | 46 +++++++++++++++-
 ...lege_escalation_expired_driver_loaded.toml | 45 +++++++++++++++-
 ...lege_escalation_exploit_cve_202238028.toml | 44 ++++++++++++++-
 ...calation_gpo_schtask_service_creation.toml | 44 ++++++++++++++-
 ...scalation_krbrelayup_service_creation.toml | 45 +++++++++++++++-
 ...privilege_escalation_lsa_auth_package.toml | 45 +++++++++++++++-
 ...privilege_escalation_make_token_local.toml | 45 +++++++++++++++-
 ...escalation_msi_repair_via_mshelp_link.toml | 48 ++++++++++++++++-
 ...scalation_newcreds_logon_rare_process.toml | 45 +++++++++++++++-
 ...ion_port_monitor_print_pocessor_abuse.toml | 45 +++++++++++++++-
 ...ation_printspooler_registry_copyfiles.toml | 48 ++++++++++++++++-
 ..._printspooler_service_suspicious_file.toml | 44 ++++++++++++++-
 ...printspooler_suspicious_file_deletion.toml | 45 +++++++++++++++-
 ..._escalation_reg_service_imagepath_mod.toml | 45 +++++++++++++++-
 ...calation_rogue_windir_environment_var.toml | 45 +++++++++++++++-
 ...lation_samaccountname_spoofing_attack.toml | 48 ++++++++++++++++-
 ...alation_suspicious_dnshostname_update.toml | 46 +++++++++++++++-
 ...lation_tokenmanip_sedebugpriv_enabled.toml | 48 ++++++++++++++++-
 ...lege_escalation_uac_bypass_com_clipup.toml | 44 ++++++++++++++-
 ...ge_escalation_uac_bypass_com_ieinstal.toml | 47 +++++++++++++++-
 ...n_uac_bypass_com_interface_icmluautil.toml | 44 ++++++++++++++-
 ...alation_uac_bypass_diskcleanup_hijack.toml | 45 +++++++++++++++-
 ...escalation_uac_bypass_dll_sideloading.toml | 46 +++++++++++++++-
 ...lege_escalation_unquoted_service_path.toml | 45 +++++++++++++++-
 ...ion_unusual_printspooler_childprocess.toml | 48 ++++++++++++++++-
 ...n_unusual_svchost_childproc_childless.toml | 44 ++++++++++++++-
 ...rivilege_escalation_via_ppid_spoofing.toml | 49 ++++++++++++++++-
 ...ilege_escalation_via_rogue_named_pipe.toml | 48 ++++++++++++++++-
 .../privilege_escalation_via_token_theft.toml | 49 ++++++++++++++++-
 ...on_windows_service_via_unusual_client.toml | 45 +++++++++++++++-
 ...rivilege_escalation_wpad_exploitation.toml | 45 +++++++++++++++-
 ...collection_archive_data_zip_imageload.toml | 48 ++++++++++++++++-
 ...ction_common_compressed_archived_file.toml | 47 +++++++++++++++-
 ...tion_files_staged_in_recycle_bin_root.toml | 45 +++++++++++++++-
 .../collection_outlook_email_archive.toml     | 45 +++++++++++++++-
 .../collection_posh_compression.toml          | 44 ++++++++++++++-
 ...ommand_and_control_bitsadmin_activity.toml | 44 ++++++++++++++-
 ...ntial_access_iis_apppoolsa_pwd_appcmd.toml | 44 ++++++++++++++-
 .../credential_access_mdmp_file_creation.toml | 46 +++++++++++++++-
 ...al_access_mdmp_file_unusual_extension.toml | 48 ++++++++++++++++-
 ...dential_access_win_private_key_access.toml | 46 +++++++++++++++-
 ...ense_evasion_aws_rds_snapshot_created.toml | 44 ++++++++++++++-
 ...ense_evasion_cmd_copy_binary_contents.toml | 45 +++++++++++++++-
 .../defense_evasion_cmstp_execution.toml      | 45 +++++++++++++++-
 ...rading_unusual_archive_file_extension.toml | 47 +++++++++++++++-
 ...ication_apps_suspicious_child_process.toml | 46 +++++++++++++++-
 .../defense_evasion_dll_hijack.toml           | 45 +++++++++++++++-
 ...evasion_dotnet_clickonce_dfsvc_netcon.toml | 48 ++++++++++++++++-
 ...fense_evasion_download_susp_extension.toml | 44 ++++++++++++++-
 ...cution_via_visualstudio_prebuildevent.toml | 49 ++++++++++++++++-
 ..._evasion_file_permission_modification.toml | 45 +++++++++++++++-
 .../defense_evasion_generic_deletion.toml     | 44 ++++++++++++++-
 ...indirect_command_exec_pcalua_forfiles.toml | 47 +++++++++++++++-
 ...fense_evasion_injection_from_msoffice.toml | 45 +++++++++++++++-
 ..._evasion_installutil_command_activity.toml | 45 +++++++++++++++-
 ...se_evasion_invalid_codesign_imageload.toml | 46 +++++++++++++++-
 ...defense_evasion_masquerading_browsers.toml | 48 ++++++++++++++++-
 ...squerading_unusual_exe_file_extension.toml | 45 +++++++++++++++-
 .../defense_evasion_masquerading_vlc_dll.toml | 45 +++++++++++++++-
 ...ense_evasion_masquerading_windows_dll.toml | 51 +++++++++++++++++-
 ...ion_masquerading_windows_system32_exe.toml | 49 ++++++++++++++++-
 ...fense_evasion_msdt_suspicious_diagcab.toml | 45 +++++++++++++++-
 ...on_msiexec_installsource_archive_file.toml | 45 +++++++++++++++-
 ...fense_evasion_posh_defender_tampering.toml | 44 ++++++++++++++-
 ..._evasion_powershell_clear_logs_script.toml | 44 ++++++++++++++-
 ...vasion_processes_with_trailing_spaces.toml | 45 +++++++++++++++-
 ...nse_evasion_service_disabled_registry.toml | 45 +++++++++++++++-
 ...defense_evasion_service_path_registry.toml | 45 +++++++++++++++-
 .../defense_evasion_services_exe_path.toml    | 44 ++++++++++++++-
 ..._evasion_suspicious_msiexec_execution.toml | 45 +++++++++++++++-
 .../defense_evasion_unsigned_bits_client.toml | 45 +++++++++++++++-
 ...nse_evasion_unusual_process_extension.toml | 44 ++++++++++++++-
 ...nse_evasion_unusual_process_path_wbem.toml | 44 ++++++++++++++-
 .../defense_evasion_write_dac_access.toml     | 45 +++++++++++++++-
 .../discovery_capnetraw_capability.toml       | 44 ++++++++++++++-
 .../discovery_generic_account_groups.toml     | 44 ++++++++++++++-
 .../discovery_generic_process_discovery.toml  | 44 ++++++++++++++-
 .../discovery_generic_registry_query.toml     | 45 +++++++++++++++-
 .../discovery_hosts_file_access.toml          | 48 ++++++++++++++++-
 .../discovery_internet_capabilities.toml      | 45 +++++++++++++++-
 ...ry_kernel_module_enumeration_via_proc.toml | 45 +++++++++++++++-
 .../discovery_linux_modprobe_enumeration.toml | 44 ++++++++++++++-
 .../discovery_linux_sysctl_enumeration.toml   | 45 +++++++++++++++-
 ...ry_linux_system_information_discovery.toml | 46 +++++++++++++++-
 ...ery_linux_system_owner_user_discovery.toml | 45 +++++++++++++++-
 .../discovery_net_share_discovery_winlog.toml | 45 +++++++++++++++-
 ..._accounts_or_groups_via_builtin_tools.toml | 46 +++++++++++++++-
 .../discovery_of_domain_groups.toml           | 44 ++++++++++++++-
 .../discovery_posh_generic.toml               | 45 +++++++++++++++-
 .../discovery_posh_password_policy.toml       | 46 +++++++++++++++-
 ...ery_potential_memory_seeking_activity.toml | 45 +++++++++++++++-
 ...y_process_discovery_via_builtin_tools.toml | 45 +++++++++++++++-
 .../discovery_signal_unusual_user_host.toml   | 44 ++++++++++++++-
 ...discovery_suspicious_proc_enumeration.toml | 45 +++++++++++++++-
 .../discovery_system_network_connections.toml | 45 +++++++++++++++-
 .../discovery_system_service_discovery.toml   | 44 ++++++++++++++-
 .../discovery_system_time_discovery.toml      | 43 ++++++++++++++-
 ...ry_userdata_request_from_ec2_instance.toml | 44 ++++++++++++++-
 .../discovery_win_network_connections.toml    | 45 +++++++++++++++-
 ..._windows_system_information_discovery.toml | 45 +++++++++++++++-
 ...execution_aws_lambda_function_updated.toml | 46 +++++++++++++++-
 ...ution_github_new_event_action_for_pat.toml | 45 +++++++++++++++-
 ...n_github_new_repo_interaction_for_pat.toml | 44 ++++++++++++++-
 ..._github_new_repo_interaction_for_user.toml | 44 ++++++++++++++-
 .../execution_github_repo_created.toml        | 45 +++++++++++++++-
 ...n_github_repo_interaction_from_new_ip.toml | 47 +++++++++++++++-
 .../execution_linux_segfault.toml             | 44 ++++++++++++++-
 ...ution_settingcontent_ms_file_creation.toml | 44 ++++++++++++++-
 ...execution_unsigned_service_executable.toml | 45 +++++++++++++++-
 .../execution_wmi_wbemtest.toml               | 45 +++++++++++++++-
 ...thub_member_removed_from_organization.toml | 45 +++++++++++++++-
 .../impact_github_pat_access_revoked.toml     | 45 +++++++++++++++-
 ...github_user_blocked_from_organization.toml | 46 +++++++++++++++-
 .../initial_access_cross_site_scripting.toml  | 48 ++++++++++++++++-
 ..._access_github_new_ip_address_for_pat.toml | 45 +++++++++++++++-
 ...access_github_new_ip_address_for_user.toml | 45 +++++++++++++++-
 ..._access_github_new_user_agent_for_pat.toml | 44 ++++++++++++++-
 ...access_github_new_user_agent_for_user.toml | 45 +++++++++++++++-
 rules_building_block/lateral_movement_at.toml | 45 +++++++++++++++-
 .../lateral_movement_posh_winrm_activity.toml | 44 ++++++++++++++-
 ...ral_movement_rdp_conn_unusual_process.toml | 45 +++++++++++++++-
 ...movement_unusual_process_sql_accounts.toml | 45 +++++++++++++++-
 .../lateral_movement_wmic_remote.toml         | 45 +++++++++++++++-
 ...e_aws_iam_login_profile_added_to_user.toml | 44 ++++++++++++++-
 ...nce_cap_sys_admin_added_to_new_binary.toml | 44 ++++++++++++++-
 ...persistence_creation_of_kernel_module.toml | 44 ++++++++++++++-
 .../persistence_github_new_pat_for_user.toml  | 48 ++++++++++++++++-
 ...github_new_user_added_to_organization.toml | 44 ++++++++++++++-
 ...e_iam_instance_request_to_iam_service.toml | 45 +++++++++++++++-
 .../persistence_startup_folder_lnk.toml       | 46 +++++++++++++++-
 .../persistence_transport_agent_exchange.toml | 44 ++++++++++++++-
 .../privilege_escalation_trap_execution.toml  | 44 ++++++++++++++-
 tests/test_all_rules.py                       | 18 +++++++
 863 files changed, 38386 insertions(+), 1022 deletions(-)

diff --git a/detection_rules/rule_formatter.py b/detection_rules/rule_formatter.py
index e4b4d704b60..f080ed0bf55 100644
--- a/detection_rules/rule_formatter.py
+++ b/detection_rules/rule_formatter.py
@@ -249,6 +249,14 @@ def _do_write(_data, _contents):
                 # This will ensure that the output file has the correct number of backslashes.
                 v = v.replace("\\", "\\\\")
 
+            if k == 'osquery' and isinstance(v, list):
+                # Specifically handle transform.osquery queries
+                for osquery_item in v:
+                    if 'query' in osquery_item and isinstance(osquery_item['query'], str):
+                        # Transform instances of \ to \\ as calling write will convert \\ to \.
+                        # This will ensure that the output file has the correct number of backslashes.
+                        osquery_item['query'] = osquery_item['query'].replace("\\", "\\\\")
+
             if isinstance(v, dict):
                 bottom[k] = OrderedDict(sorted(v.items()))
             elif isinstance(v, list):
diff --git a/rules/apm/apm_403_response_to_a_post.toml b/rules/apm/apm_403_response_to_a_post.toml
index d8010b71afc..1792cc910fd 100644
--- a/rules/apm/apm_403_response_to_a_post.toml
+++ b/rules/apm/apm_403_response_to_a_post.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -32,4 +32,51 @@ type = "query"
 query = '''
 http.response.status_code:403 and http.request.method:post
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Web Application Suspicious Activity: POST Request Declined
+
+Web applications often use POST requests to handle data submissions securely. However, adversaries may exploit this by attempting unauthorized actions, triggering a 403 error when access is denied. The detection rule identifies such anomalies by flagging POST requests that receive a 403 response, indicating potential misuse or probing by attackers.
+
+### Possible investigation steps
+
+- Review the specific POST request details, including the URL and parameters, to understand what action was attempted and why it might have been denied.
+- Examine the source IP address of the POST request to determine if it is associated with known malicious activity or if it is an unusual source for your application.
+- Check the user-agent string in the request headers to identify if the request was made by a legitimate browser or a suspicious tool or script.
+- Analyze the frequency and pattern of 403 responses from the same IP or user-agent to identify potential probing or brute force attempts.
+- Investigate the timing of the POST request in relation to other suspicious activities in the logs to identify any correlation with other alerts or incidents.
+- Use Osquery to gather additional context from the server hosting the web application. For example, run the following query to check for recent changes in web server configuration files that might affect POST request handling:
+  ```sql
+  SELECT * FROM file WHERE path LIKE '/etc/httpd/conf/httpd.conf' OR path LIKE '/etc/nginx/nginx.conf' ORDER BY mtime DESC LIMIT 5;
+  ```
+- Review application logs for any error messages or warnings around the time of the POST request to identify potential misconfigurations or application errors.
+- Check for any recent updates or changes to the web application code that might have inadvertently introduced stricter access controls or bugs.
+- Investigate whether the POST request was part of a legitimate user's session by correlating it with authentication logs and session data.
+- Consult threat intelligence sources to determine if there are any known vulnerabilities or attack patterns associated with the specific endpoint or application version targeted by the POST request.
+
+### False positive analysis
+
+- Legitimate users may trigger a 403 response when they attempt to access restricted areas of a web application without proper permissions, such as administrative sections or user-specific content.
+- Automated scripts or bots used for web scraping or data collection might inadvertently cause 403 errors if they attempt to access protected resources, leading to false positives.
+- Security tools or plugins that perform vulnerability scanning on web applications can generate POST requests that result in 403 responses, which are not necessarily malicious.
+- Users can manage these false positives by creating exceptions for known IP addresses or user agents that frequently cause 403 errors but are verified as non-threatening.
+- Implementing a whitelist for specific endpoints or user roles that are known to trigger 403 responses during normal operations can help reduce unnecessary alerts.
+- Regularly reviewing and updating the list of exceptions based on the analysis of web application logs and user behavior patterns can help maintain the accuracy of the detection rule.
+
+### Response and remediation
+
+- Immediately review the logs to identify the source IP address of the suspicious POST requests and block it at the firewall or web application firewall (WAF) to prevent further unauthorized attempts.
+- Analyze the request payloads to determine if there are any patterns or specific data being targeted, which could indicate the attacker's intent or the vulnerability being exploited.
+- Conduct a thorough review of the web application's access control policies to ensure that permissions are correctly configured and that sensitive endpoints are adequately protected.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity appears to be part of a larger attack campaign or if multiple systems are affected.
+- Implement enhanced logging for POST requests, including capturing request headers and payloads, to improve visibility and aid in future investigations.
+- Integrate threat intelligence feeds to correlate the detected activity with known attack patterns or threat actors, providing additional context for the investigation.
+- Restore any affected systems or services to their operational state by rolling back unauthorized changes and applying necessary patches or updates to address any identified vulnerabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement security hardening measures such as input validation, rate limiting, and multi-factor authentication to reduce the risk of similar incidents in the future.
+- Educate development and operations teams on secure coding practices and the importance of regular security assessments to prevent exploitation of web application vulnerabilities."""
 
diff --git a/rules/apm/apm_405_response_method_not_allowed.toml b/rules/apm/apm_405_response_method_not_allowed.toml
index bedc96ade16..4021b259177 100644
--- a/rules/apm/apm_405_response_method_not_allowed.toml
+++ b/rules/apm/apm_405_response_method_not_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -32,4 +32,47 @@ type = "query"
 query = '''
 http.response.status_code:405
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Web Application Suspicious Activity: Unauthorized Method
+
+Web applications use HTTP methods to define actions on resources. A 405 status code signals a method is not allowed, often due to misconfigurations or probing by attackers. Adversaries may exploit this by testing various methods to find vulnerabilities. The detection rule identifies such attempts by flagging responses with a 405 status, indicating potential unauthorized method usage.
+
+### Possible investigation steps
+
+- Review the logs for the specific time frame when the 405 status code was triggered to identify any patterns or anomalies in the requests.
+- Examine the source IP addresses associated with the 405 responses to determine if they are known or potentially malicious.
+- Analyze the user-agent strings in the requests to identify if they are associated with known malicious tools or scripts.
+- Check the HTTP methods used in the requests that resulted in a 405 response to understand which methods were attempted.
+- Investigate the requested URLs or endpoints to determine if they are legitimate resources or if they appear to be probing for vulnerabilities.
+- Correlate the 405 response events with other security events or alerts to identify any related suspicious activity.
+- Use Osquery to gather additional context from the web server, such as running processes or open network connections. Example query: `SELECT * FROM processes WHERE name LIKE '%httpd%' OR name LIKE '%nginx%';`
+- Review the web application configuration files to ensure that the HTTP methods are correctly configured and that there are no misconfigurations.
+- Check for any recent changes or updates to the web application or server that might have affected the allowed HTTP methods.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar activity.
+
+### False positive analysis
+
+- Legitimate applications or services may trigger a 405 response when they are misconfigured or when certain HTTP methods are intentionally disabled for security reasons. 
+- Automated tools or scripts used for testing or monitoring web applications might inadvertently use unsupported HTTP methods, resulting in 405 responses.
+- Web crawlers or bots that are not malicious but are poorly configured can also cause 405 status codes by attempting to access resources with incorrect methods.
+- To manage these false positives, users can create exceptions for known and trusted IP addresses or user agents that frequently trigger 405 responses without malicious intent.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately review the web server logs to identify the source IP addresses and user agents associated with the 405 status code responses to determine if they are part of a legitimate request or a potential attack.
+- Block or rate-limit the identified suspicious IP addresses at the firewall or web application firewall (WAF) to prevent further unauthorized method attempts.
+- Conduct a thorough investigation to determine if the unauthorized method attempts were successful in exploiting any vulnerabilities, and assess the potential impact on the system.
+- Review and update the web application's configuration to ensure that only necessary HTTP methods are allowed for each resource, reducing the attack surface.
+- Escalate the incident to the security operations team if there is evidence of a coordinated attack or if sensitive data may have been exposed.
+- Implement enhanced logging policies to capture detailed information about HTTP requests, including headers and payloads, to aid in future investigations.
+- Integrate security information and event management (SIEM) systems with web server logs to enable real-time monitoring and alerting of suspicious activities.
+- Restore the system to its operational state by applying patches or updates to address any identified vulnerabilities and ensure the web application is functioning correctly.
+- Conduct a post-incident review to analyze the attack vectors and improve the incident response plan, incorporating lessons learned from the investigation.
+- Implement hardening measures such as disabling unused HTTP methods, enforcing strong authentication and authorization controls, and regularly testing the web application for vulnerabilities."""
 
diff --git a/rules/apm/apm_sqlmap_user_agent.toml b/rules/apm/apm_sqlmap_user_agent.toml
index c8ba5b28669..9c6d0d1111f 100644
--- a/rules/apm/apm_sqlmap_user_agent.toml
+++ b/rules/apm/apm_sqlmap_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -32,4 +32,50 @@ type = "query"
 query = '''
 user_agent.original:"sqlmap/1.3.11#stable (http://sqlmap.org)"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Web Application Suspicious Activity: sqlmap User Agent
+
+Sqlmap is a widely-used open-source tool designed to automate the detection and exploitation of SQL injection vulnerabilities in web applications. While beneficial for security testing, adversaries can exploit it to gain unauthorized access to databases. The detection rule identifies suspicious activity by flagging the specific user agent string associated with sqlmap, helping security analysts pinpoint potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the sqlmap user agent string: `sqlmap/1.3.11#stable (http://sqlmap.org)` in the `user_agent.original` field.
+- Correlate the timestamp of the alert with web server logs to identify the source IP address and any associated requests.
+- Investigate the source IP address to determine if it is known for malicious activity or if it belongs to a legitimate user or organization.
+- Examine the request URL and parameters in the web server logs to identify any potential SQL injection attempts or unusual patterns.
+- Check for any other user agents or unusual activity from the same IP address around the time of the alert to identify patterns of behavior.
+- Use Osquery to gather additional context on the system that received the request. For example, run the following Osquery query to list recent web server access logs:
+  ```sql
+  SELECT * FROM apache_access WHERE user_agent = 'sqlmap/1.3.11#stable (http://sqlmap.org)';
+  ```
+- Investigate any database logs or alerts for suspicious queries or access patterns that coincide with the time of the alert.
+- Review any recent changes or updates to the web application that might have introduced vulnerabilities or altered security configurations.
+- Check for any other alerts or incidents involving the same user agent or IP address across different systems or applications.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently using sqlmap for malicious purposes.
+
+### False positive analysis
+
+- Legitimate security teams or developers may use sqlmap for authorized penetration testing, leading to false positives when the tool is used in a controlled environment.
+- Automated security scans or vulnerability assessments conducted by third-party services might trigger the rule if sqlmap is part of their testing suite.
+- To manage these false positives, organizations can create exceptions for known IP addresses or user agents associated with authorized security testing activities.
+- Implementing a whitelist of IP addresses or user agents for trusted security tools can help reduce noise and focus on genuine threats.
+- Regularly review and update the list of exceptions to ensure that only current and authorized activities are excluded from alerts.
+
+### Response and remediation
+
+- Immediately block the IP address associated with the suspicious sqlmap user agent activity to prevent further unauthorized access attempts.
+- Conduct a thorough investigation of the affected web application logs to identify any successful SQL injection attempts and assess the extent of potential data exposure.
+- Review and update web application firewall (WAF) rules to detect and block SQL injection attempts more effectively.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed user agent strings and other relevant HTTP request headers for future analysis.
+- Integrate threat intelligence feeds to correlate detected sqlmap activity with known malicious IP addresses and attack patterns.
+- Restore any compromised databases from the most recent clean backup and ensure that all patches and updates are applied to the database management system.
+- Conduct a security review of the web application code to identify and remediate any SQL injection vulnerabilities.
+- Educate development and operations teams on secure coding practices and the importance of input validation to prevent SQL injection attacks.
+- Consider deploying additional security measures such as intrusion detection systems (IDS) and regular vulnerability assessments to strengthen the overall security posture."""
 
diff --git a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
index cde6a30ffa4..9e13383d8df 100644
--- a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
+++ b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/19"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2024/08/09"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,52 @@ process where
     /* Look for Google Drive download URL with AV flag skipping */
     (process.command_line : "*drive.google.com*" and process.command_line : "*export=download*" and process.command_line : "*confirm=no_antivirus*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious File Downloaded from Google Drive
+
+Google Drive is a widely used cloud storage service that allows users to store and share files. Adversaries may exploit its trusted nature to deliver malicious payloads by crafting URLs that bypass antivirus checks. The detection rule identifies unusual download activities from Google Drive by monitoring browser processes and specific URL patterns, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the suspicious Google Drive URL pattern, specifically checking for the `*drive.google.com*`, `*export=download*`, and `*confirm=no_antivirus*` strings in the `process.command_line`.
+- Identify the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior.
+- Examine the process tree to understand the parent and child processes of the suspicious download activity, which can provide context on how the download was initiated.
+- Check the timestamp of the event to correlate with other security events or logs that might indicate related suspicious activities.
+- Investigate the network connections made by the process using the suspicious URL to identify any unusual or unauthorized data transfers.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with command lines containing the suspicious Google Drive URL pattern:
+  ```sql
+  SELECT pid, name, path, cmdline, start_time FROM processes WHERE cmdline LIKE '%drive.google.com%' AND cmdline LIKE '%export=download%' AND cmdline LIKE '%confirm=no_antivirus%';
+  ```
+- Analyze browser history and cache files to determine if the user visited any other suspicious or related URLs around the time of the alert.
+- Review any downloaded files for malicious content using a sandbox environment or antivirus tools to assess potential threats.
+- Check for any recent changes in browser extensions or plugins that might have facilitated the download of the suspicious file.
+- Consult threat intelligence sources to see if the specific Google Drive URL or file hash has been reported in any known phishing or malware campaigns.
+
+### False positive analysis
+
+- Legitimate business operations may involve downloading files from Google Drive using automated scripts or tools like curl or wget, which could trigger the rule. Users can create exceptions for specific IP addresses or user accounts known to perform these tasks regularly.
+- Educational institutions often share large volumes of files via Google Drive for academic purposes. If these activities are flagged, users can whitelist domains or email addresses associated with the institution to prevent false positives.
+- Software developers and IT teams might use Google Drive to distribute software updates or patches. To manage these, users can exclude specific file types or known update URLs from triggering the rule.
+- Marketing teams frequently share media files and assets through Google Drive links. Users can handle these by setting up exceptions for recognized marketing team members or specific project-related URLs.
+- Collaborative projects often involve sharing documents and resources via Google Drive. Users can mitigate false positives by excluding known project-related Google Drive URLs or user accounts from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the downloaded file to determine its nature and potential impact, using sandboxing and static analysis tools.
+- Review browser and system logs to identify any other suspicious activities or downloads that may have occurred around the same time.
+- Remove the malicious file and any associated processes or registry entries from the affected system.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Update antivirus and endpoint protection solutions to ensure they can detect and block similar threats in the future.
+- Implement enhanced logging policies to capture detailed information on file downloads and process executions for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Educate users on the risks of downloading files from untrusted sources and the importance of verifying URLs before clicking.
+- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further assistance."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
index 7e90f0a3dc5..4558c62759b 100644
--- a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
+++ b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,49 @@ sequence by process.entity_id with maxspan=1m
    )
   ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Non-Standard Port SSH connection
+
+SSH is a protocol used for secure remote access and data transfer. Adversaries may exploit non-standard ports to evade detection and bypass network filters. The detection rule identifies unusual SSH activity by monitoring processes and network connections on ports other than the default 22, excluding common legitimate uses, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the process.entity_id and the specific non-standard port being used for the SSH connection.
+- Verify the process name and parent process name to ensure it is not part of a legitimate application or service, as listed in the exclusion list (e.g., "rsync", "git").
+- Check the destination IP address to determine if it falls outside the excluded IP ranges and assess if it is a known or trusted entity.
+- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` to obtain details like the command line, user, and start time.
+- Investigate the network activity associated with the process by examining logs or using network monitoring tools to identify any unusual patterns or data transfers.
+- Correlate the process start time with user login events to determine if the SSH connection aligns with expected user activity.
+- Analyze historical data to see if the same non-standard port has been used previously and if it correlates with any known malicious activity.
+- Check for any recent changes in the system configuration or firewall rules that might explain the use of a non-standard port for SSH.
+- Investigate any related alerts or incidents that might provide additional context or indicate a broader attack campaign.
+- Consult threat intelligence sources to see if the destination IP or non-standard port is associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate applications or services that use SSH on non-standard ports for operational purposes, such as custom backup solutions or internal tools, may trigger false positives. Users should identify these applications and add them to the exclusion list in the detection rule.
+- Development environments or testing scenarios where SSH is configured to use non-standard ports for convenience or isolation can also result in false positives. Users can manage these by documenting and excluding these specific environments from the rule.
+- Automated scripts or deployment tools that utilize SSH on non-standard ports for configuration management or software deployment might be flagged. Users should ensure these tools are recognized and excluded by adding their parent process names to the exception list.
+- In some network architectures, non-standard ports might be used for SSH to avoid conflicts or due to specific firewall configurations. Users should review their network policies and adjust the detection rule to accommodate these legitimate configurations.
+- Users can handle false positives by regularly reviewing the logs and identifying patterns of benign activity, then updating the rule to exclude these patterns while ensuring that security is not compromised.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the process and network logs to identify the source and scope of the unauthorized SSH connection.
+- Verify the integrity of critical system files and configurations to ensure no unauthorized changes have been made.
+- Change all credentials associated with the compromised system and any other systems that may have been accessed using the same credentials.
+- Apply patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Implement network segmentation to limit the ability of adversaries to move laterally within the network.
+- Enhance logging policies to include detailed SSH connection attempts and process execution logs for better future detection.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
index 3a940510079..c00bdf87d7e 100644
--- a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
+++ b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/05/28"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ process where event.type in ("start", "process_started", "info") and
                    "--remote-debugging-pipe=*") and
    process.args : "--user-data-dir=*" and not process.args:"--remote-debugging-port=0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Cookies Theft via Browser Debugging
+
+Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate attempts to hijack cookies, by monitoring specific process names and arguments indicative of debugging activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious process arguments, specifically checking for `--remote-debugging-port=*`, `--remote-debugging-targets=*`, and `--remote-debugging-pipe=*` in conjunction with `--user-data-dir=*`.
+- Verify the process name involved in the alert to ensure it matches one of the targeted Chromium-based browsers such as "chrome.exe", "Google Chrome", "msedge.exe", or "Microsoft Edge".
+- Check the process start time and correlate it with user activity logs to determine if the browser was launched during normal working hours or if it coincides with unusual activity.
+- Investigate the user account associated with the process to determine if the account has a history of legitimate debugging activities or if it is potentially compromised.
+- Use Osquery to gather additional context about the process by running a query like: `SELECT pid, name, path, cmdline FROM processes WHERE name IN ('chrome.exe', 'msedge.exe') AND cmdline LIKE '%--remote-debugging-port=%';` to identify the full command line and path of the suspicious process.
+- Examine network logs to identify any unusual outbound connections from the host that may indicate data exfiltration or communication with a command and control server.
+- Review browser history and cache files for any evidence of unauthorized access to sensitive web applications or services.
+- Check for any recent changes to browser extensions or plugins that could have been used to facilitate cookie theft.
+- Analyze system logs for any other suspicious activities or anomalies around the time the alert was triggered, such as unexpected file modifications or new user accounts.
+- Consult with the user or system owner to verify if they were conducting legitimate debugging activities and gather any additional context that may explain the alert.
+
+### False positive analysis
+
+- Developers and IT professionals often use debugging features in Chromium-based browsers for legitimate purposes, such as testing and troubleshooting web applications, which can trigger this detection rule.
+- Automated testing frameworks and tools that rely on browser automation may use debugging arguments to control browser instances, leading to false positives.
+- Users can manage these false positives by creating exceptions for known and trusted processes or users who regularly engage in legitimate debugging activities.
+- Implementing a whitelist of IP addresses or user accounts associated with development and testing environments can help reduce false positives.
+- Regularly review and update the list of exceptions to ensure that only authorized debugging activities are excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Investigate the process logs to confirm the presence of suspicious debugging arguments and identify any unauthorized access to session cookies.
+- Terminate any suspicious browser processes that are running with debugging arguments to stop potential cookie theft.
+- Change passwords and invalidate session tokens for any accounts that may have been compromised to prevent unauthorized access.
+- Escalate the incident to the security operations team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and network connections.
+- Integrate security tools with SIEM systems to automate the detection of suspicious debugging activities and alert security teams in real-time.
+- Restore the system to its operational state by applying security patches, updating software, and ensuring all security configurations are correctly set.
+- Conduct a security review to identify and address any vulnerabilities that allowed the attack, such as weak browser configurations or insufficient monitoring.
+- Educate users on the risks of session hijacking and the importance of secure browsing practices to reduce the likelihood of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/credential_access_forced_authentication_pipes.toml b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
index db0ec420cba..e65ec69b629 100644
--- a/rules/cross-platform/credential_access_forced_authentication_pipes.toml
+++ b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/23"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2024/10/01"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,48 @@ sequence with maxspan=15s
 [network where host.os.type == "linux" and event.action == "connection_attempted" and destination.port == 445 and not startswith~(string(destination.ip), string(host.ip))] by host.ip, data_stream.namespace
 [file where host.os.type == "windows" and event.code == "5145" and file.name : ("Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc")] by source.ip, data_stream.namespace
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Active Directory Forced Authentication from Linux Host - SMB Named Pipes
+
+Active Directory (AD) and SMB named pipes facilitate communication and resource sharing in networks. Adversaries exploit these by forcing authentication from a Linux host to capture credentials or perform relay attacks. The detection rule identifies suspicious connection attempts to SMB ports from Linux hosts and monitors specific named pipes on Windows, indicating potential forced authentication attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the source and destination IP addresses involved in the suspicious connection attempt, focusing on the `host.ip` and `destination.ip` fields.
+- Verify the Linux host's activity by checking recent network logs for any unusual or unauthorized connection attempts to SMB port 445, using the `event.action` and `destination.port` fields.
+- Cross-reference the `source.ip` from the Windows event logs with known IP addresses to determine if the connection originated from a trusted or suspicious source.
+- Investigate the specific named pipes accessed on the Windows host by examining the `file.name` field in the event logs to identify any unusual or unauthorized access attempts.
+- Use Osquery to gather additional context on the Linux host by running a query to list all active network connections: `SELECT * FROM process_open_sockets WHERE remote_port = 445;`
+- Check for any recent changes or anomalies in the Linux host's configuration or installed software that could indicate compromise or unauthorized access.
+- Analyze the Windows event logs for any other related events around the same timestamp as the alert to identify potential patterns or additional suspicious activity.
+- Investigate the user accounts involved in the connection attempt by reviewing authentication logs on both the Linux and Windows hosts to identify any unauthorized access attempts.
+- Correlate the alert with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to gather additional context and evidence.
+- Document all findings and observations during the investigation to build a comprehensive understanding of the incident and support further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Routine administrative tasks: Linux hosts performing legitimate administrative tasks on Windows servers may trigger the rule. These tasks often involve connecting to SMB ports for file sharing or management purposes. Users can manage this by creating exceptions for known administrative IP addresses or specific time windows when these tasks are scheduled.
+- Backup operations: Automated backup processes from Linux systems to Windows servers might generate connection attempts to SMB ports. To handle this, users can exclude IP addresses of backup servers or specific data streams associated with backup operations.
+- Monitoring and security tools: Security or monitoring tools running on Linux hosts may attempt to connect to Windows systems for log collection or system checks, leading to false positives. Users should identify and whitelist these tools by their IP addresses or data stream namespaces.
+- Development and testing environments: In environments where Linux hosts are used for testing or development, frequent connections to Windows systems might occur as part of normal operations. Users can exclude these environments by defining exceptions for specific subnets or hostnames associated with development and testing activities.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or credential capture.
+- Conduct a thorough investigation of the Linux host to identify any malicious scripts or tools used for forced authentication attempts.
+- Review and analyze logs from both the Linux and Windows systems to trace the source and scope of the attack, focusing on the specific named pipes and network connections involved.
+- Change passwords for any accounts that may have been exposed or compromised during the attack to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed authentication events and network traffic, ensuring that future suspicious activities are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Restore the affected systems to their operational state by removing any malicious software and applying necessary security patches and updates.
+- Harden the security posture of the network by disabling unnecessary SMB services and enforcing strong authentication mechanisms, such as multi-factor authentication (MFA).
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans to address similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
index 0387b769dc3..bee9815b398 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,49 @@ type = "query"
 query = '''
 event.agent_id_status:(agent_id_mismatch or mismatch)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Agent Spoofing - Mismatched Agent ID
+
+In security environments, agent IDs are crucial for authenticating and tracking events from various sources. Adversaries may exploit this by spoofing agent IDs to disguise malicious activities as legitimate, thereby evading detection. The detection rule identifies discrepancies between expected and actual agent IDs, signaling potential spoofing attempts and helping analysts pinpoint suspicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the specific event and agent IDs involved in the mismatch.
+- Verify the legitimacy of the API key associated with the expected agent ID to ensure it hasn't been compromised or misused.
+- Cross-reference the actual agent ID with known legitimate agents in your environment to determine if it is recognized or expected.
+- Analyze the event logs surrounding the alert for any unusual or suspicious activities that might indicate malicious intent.
+- Use Osquery to gather additional information about the system associated with the actual agent ID. Example query: `SELECT * FROM osquery_info WHERE uuid = '<actual_agent_id>';`
+- Check for any recent changes or updates in the system configurations or software that might explain the agent ID mismatch.
+- Investigate the network traffic from the source IP address associated with the actual agent ID to identify any anomalies or unauthorized access attempts.
+- Correlate the alert with other security events or alerts to identify patterns or related incidents that might indicate a broader attack.
+- Consult with system administrators or relevant personnel to verify if there have been any legitimate changes or deployments that could account for the mismatch.
+- Document all findings and observations during the investigation to maintain a comprehensive record for future reference and analysis.
+
+### False positive analysis
+
+- Legitimate software updates or configuration changes can cause agent ID mismatches if the agent ID is regenerated or altered during the process. Users should verify if recent updates or changes align with the timing of the mismatched events.
+- Network issues or temporary disconnections might lead to agent ID mismatches when agents reconnect with a new ID. Users can monitor network stability and correlate with the timing of mismatches to identify such cases.
+- Virtual machine snapshots or clones can result in agent ID mismatches if the agent ID is not updated or synchronized properly. Users should ensure that virtual environments are configured to handle agent ID updates correctly.
+- Testing environments where agent IDs are frequently changed or reused can trigger false positives. Users can create exceptions for known testing environments to prevent unnecessary alerts.
+- In environments with shared API keys, mismatches may occur if multiple agents use the same key but have different IDs. Users should consider assigning unique API keys to each agent to reduce the likelihood of mismatches.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further malicious activity and contain the threat.
+- Verify the legitimacy of the agent ID by cross-referencing with known good configurations and records.
+- Conduct a thorough investigation to identify the source and scope of the spoofing attempt, utilizing logs and network traffic analysis.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
+- Revoke and reissue API keys associated with the compromised agent IDs to prevent unauthorized access.
+- Implement enhanced logging policies to capture detailed information on agent ID usage and anomalies for future investigations.
+- Integrate threat intelligence feeds to correlate detected spoofing attempts with known threat actor tactics and techniques.
+- Restore affected systems by reimaging or applying clean backups, ensuring all malicious artifacts are removed.
+- Apply system hardening measures, such as enforcing strict authentication mechanisms and regular agent ID audits.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
index 0a5ee5c15a7..3e0f053382b 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2024/06/14"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,49 @@ type = "threshold"
 query = '''
 event.agent_id_status:* and not tags:forwarded
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Agent Spoofing - Multiple Hosts Using Same Agent
+
+In network environments, agents are deployed on hosts to monitor and report activities. Each agent has a unique ID to ensure accurate tracking. Adversaries may exploit this by using a single agent ID across multiple hosts to inject false data, masking their actions. The detection rule identifies such anomalies by flagging instances where the same agent ID appears on different hosts, indicating potential spoofing attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific agent ID that has been flagged for appearing on multiple hosts.
+- Cross-reference the `event.agent_id_status` field in the alert to determine the status and any additional context provided by the event.
+- Check the network logs to identify all hosts associated with the flagged agent ID and note any unusual patterns or discrepancies in their activities.
+- Use Osquery to gather more information about the hosts involved. For example, run the following query to list all processes associated with the agent ID on each host: `SELECT pid, name, path FROM processes WHERE name = 'agent_name';`
+- Investigate the timeline of events to determine when the agent ID first appeared on each host and identify any correlating events or changes in the network environment.
+- Examine the `tags` field in the alert to ensure that the events are not legitimate forwarded events, which could explain the presence of the same agent ID on multiple hosts.
+- Analyze the configuration and deployment logs of the agent to check for any unauthorized changes or anomalies that could indicate tampering.
+- Review user access logs and permissions to identify any unauthorized access or privilege escalation that might have facilitated the spoofing.
+- Correlate the findings with other security alerts or incidents to identify any patterns or connections that could indicate a broader attack campaign.
+- Document all findings and observations to build a comprehensive understanding of the incident, which will aid in further investigation and eventual remediation.
+
+### False positive analysis
+
+- Legitimate load balancing or failover scenarios where an agent ID is intentionally used across multiple hosts for redundancy can trigger false positives. Users can handle this by creating exceptions for known load-balanced systems.
+- Virtualized environments where snapshots or clones of a host are created might result in the same agent ID appearing on multiple hosts. Users should identify and exclude these virtualized instances from the rule.
+- During system migrations or upgrades, an agent ID might temporarily appear on multiple hosts. Users can manage this by setting temporary exceptions during the migration period.
+- In environments with shared or pooled resources, such as VDI (Virtual Desktop Infrastructure), the same agent ID might be used across different sessions. Users should configure the rule to recognize and exclude these shared resource scenarios.
+- Testing or development environments where agents are duplicated for testing purposes can also lead to false positives. Users should ensure these environments are excluded from the rule or tagged appropriately to prevent alerts.
+
+### Response and remediation
+
+- Immediately isolate affected hosts to prevent further spread of the spoofed agent ID across the network.
+- Conduct a thorough investigation to identify all hosts using the compromised agent ID and assess the scope of the intrusion.
+- Validate the integrity of the agent software on affected hosts and reinstall or update agents as necessary to ensure they are not compromised.
+- Review and analyze logs to identify any unauthorized activities or data injections associated with the spoofed agent ID.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement stricter access controls and authentication mechanisms for agent deployment and management to prevent unauthorized use.
+- Enhance logging policies to capture detailed agent activity and host interactions for improved monitoring and future investigations.
+- Integrate threat intelligence feeds to correlate detected spoofing attempts with known adversary tactics, techniques, and procedures (TTPs).
+- Restore affected systems to their operational state by applying necessary patches, updates, and configuration changes.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as network segmentation and endpoint protection, to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
index 27c9ce51e5b..4b95989382a 100644
--- a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
+++ b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,50 @@ file where event.type == "deletion" and
                "/var/log/httpd/access_log",
                "/var/www/*/logs/access.log")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WebServer Access Logs Deleted
+
+Web server access logs are crucial for monitoring and analyzing web traffic, providing insights into user activity and potential security incidents. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies log deletions across common web server paths, signaling potential attempts at evasion or evidence destruction, thus alerting analysts to investigate further.
+
+### Possible investigation steps
+
+- Verify the alert by checking the specific file paths mentioned in the query to confirm if the deletion event is legitimate and not a false positive.
+- Review recent access logs, if available, to identify any suspicious activity or patterns leading up to the deletion event.
+- Use Osquery to list all recent file modifications in the web server directories to identify any unauthorized changes. Example query: `SELECT * FROM file WHERE path LIKE '/var/log/apache%/access.log' OR path LIKE '/etc/httpd/logs/access_log' OR path LIKE '/var/log/httpd/access_log' OR path LIKE '/var/www/%/logs/access.log';`
+- Check for any recent user account activity or privilege escalations that could indicate unauthorized access to the server.
+- Investigate any recent changes in user permissions or roles that might have allowed the deletion of log files.
+- Correlate the deletion event with other security alerts or logs from the same timeframe to identify potential related incidents.
+- Examine system logs for any signs of tampering or anomalies that could suggest an attempt to cover tracks.
+- Review network traffic logs for unusual outbound connections or data exfiltration attempts around the time of the log deletion.
+- Check for any scheduled tasks or scripts that might have been used to automate the deletion of log files.
+- Consult with the web server administrator to determine if there were any legitimate maintenance activities or updates that could have resulted in the log deletion.
+
+### False positive analysis
+
+- Routine maintenance tasks or automated scripts may delete old web server access logs to free up disk space, which can trigger false positives. 
+- Log rotation processes, which are standard in many server environments, might also result in log deletions that are benign and expected.
+- Scheduled cleanup jobs configured by system administrators to manage log file sizes can lead to false alerts.
+- To manage these false positives, users can create exceptions for known maintenance scripts or log rotation processes by excluding specific file paths or event sources from the detection rule.
+- Implementing a whitelist of trusted processes or users responsible for legitimate log deletions can help reduce unnecessary alerts.
+- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity to go undetected.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the log deletion, identifying any other compromised systems or services.
+- Review recent user activity and access logs from other sources to identify potential unauthorized access or malicious behavior.
+- Restore deleted logs from backups if available, and analyze them for any indicators of compromise or suspicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement stricter access controls and permissions on log files to prevent unauthorized deletion or modification.
+- Enhance logging policies by ensuring logs are sent to a centralized, secure logging server that is less susceptible to tampering.
+- Integrate additional security tools such as file integrity monitoring and endpoint detection and response (EDR) solutions to detect and alert on suspicious activities.
+- Apply system and application patches to address any vulnerabilities that may have been exploited by the adversary.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
index d741251924d..0852d7d7344 100644
--- a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
+++ b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,49 @@ process where event.action in ("exec", "exec_event", "executed", "process_starte
   (process.args : "set" and process.args : "history" and process.args : "+o")
  )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Tampering of Shell Command-Line History
+
+Shell command-line history is a crucial feature that logs user commands, aiding in troubleshooting and audits. Adversaries may manipulate this history to hide their tracks, using commands to delete or redirect history files, or alter environment variables to disable logging. The detection rule identifies such tampering by monitoring for suspicious command patterns and arguments indicative of history manipulation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and user involved in the tampering attempt, focusing on the `process.args` and `process.user` fields.
+- Check the process execution timeline to determine if there are any preceding or subsequent suspicious activities, using the `event.action` and `event.type` fields.
+- Investigate the command history of the user associated with the alert to identify any other potentially malicious commands executed around the same time.
+- Use Osquery to list all recent modifications to shell history files. Example query: `SELECT path, size, mtime FROM file WHERE path LIKE '/home/%/.bash_history' OR path LIKE '/root/.bash_history';`
+- Examine the system logs for any anomalies or errors that coincide with the time of the alert, which might indicate tampering or other malicious activities.
+- Verify the integrity of the shell history files by comparing them with backups or snapshots, if available, to identify any unauthorized changes.
+- Investigate any changes to environment variables related to shell history, such as `HISTFILE` and `HISTFILESIZE`, by reviewing the user's shell configuration files (e.g., `.bashrc`, `.bash_profile`).
+- Check for the presence of symbolic links or redirections of history files to `/dev/null` using the `ln` command, as indicated in the alert.
+- Analyze the system for any other indicators of compromise or persistence mechanisms that might suggest a broader attack campaign.
+- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or threat actor behaviors.
+
+### False positive analysis
+
+- System administrators or developers may intentionally clear command-line history for privacy or security reasons, leading to false positives. To manage this, users can create exceptions for specific user accounts or roles known to perform these actions regularly.
+- Automated scripts or maintenance tasks might include commands that manipulate shell history as part of their normal operation. Users can handle these by excluding processes or scripts with known benign behavior from triggering alerts.
+- Some security tools or compliance checks may execute commands that resemble history tampering to verify system configurations. Users should identify these tools and add them to an allowlist to prevent false positives.
+- Developers working in shared environments might redirect history files to avoid conflicts, which could be mistaken for tampering. Users can exclude specific directories or environments where this practice is common.
+- In environments where disk space is a concern, users might truncate history files to save space, which could trigger alerts. Users can set exceptions for these actions when performed by authorized personnel or scripts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further tampering or data exfiltration.
+- Conduct a thorough investigation to identify the scope of the tampering, including reviewing logs and correlating with other security events.
+- Restore the shell command-line history from backups if available, to aid in understanding the adversary's actions.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed command-line activity, ensuring that logs are stored securely and are tamper-proof.
+- Integrate with a centralized logging solution or SIEM to aggregate and analyze shell command-line history across the organization.
+- Review and update security policies to include regular audits of shell history files and environment variables related to command logging.
+- Apply system hardening measures, such as restricting access to history files and enforcing the use of secure shell configurations.
+- Educate users on the importance of shell history for security and encourage reporting of any suspicious activity.
+- Leverage MITRE ATT&CK framework to understand potential adversary techniques and improve detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
index 655695f3cae..a51d23d6c42 100644
--- a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
+++ b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,49 @@ or
     process.args : "com.apple.iokit.EndpointSecurity" and
     event.action : "end"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Elastic Agent Service Terminated
+
+The Elastic Agent is a critical component for monitoring and securing systems across various environments, including Windows, Linux, and MacOS. It collects and sends data to the Elastic Stack for analysis. Adversaries may attempt to stop or disable this service to evade detection, impairing defense mechanisms. The detection rule identifies suspicious processes and commands that attempt to terminate or disable the Elastic Agent, signaling potential malicious activity. By monitoring these actions, security analysts can quickly respond to threats and ensure continuous protection.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on the `process.name` and `process.args` fields.
+- Check the event type (`event.type`) to determine if the process was starting or ending, which can provide context on whether the service was being stopped or disabled.
+- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised.
+- Examine the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the Elastic Agent service was terminated.
+- Use Osquery to gather additional context on the host. For example, run the following query to check for recent process executions: `SELECT * FROM processes WHERE name IN ('net.exe', 'sc.exe', 'wmic.exe', 'powershell.exe', 'taskkill.exe', 'PsKill.exe', 'ProcessHacker.exe');`
+- Verify the integrity and configuration of the Elastic Agent on the affected host to ensure it has not been tampered with or misconfigured.
+- Cross-reference the alert with any recent changes or updates to the system that might have inadvertently caused the service to stop.
+- Check for any network connections or communications from the host that might indicate data exfiltration or command-and-control activity.
+- Review any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or correlations with other malicious activities.
+- Consult threat intelligence sources to determine if there are any known campaigns or adversaries that use similar tactics to disable security services.
+
+### False positive analysis
+
+- Routine maintenance or updates: Scheduled system maintenance or software updates may involve stopping services, including the Elastic Agent, leading to false positives. To manage this, create exceptions for known maintenance windows or update processes.
+- System administrators' actions: Legitimate actions by system administrators, such as troubleshooting or reconfiguring systems, might trigger the rule. To handle this, whitelist specific administrator accounts or processes that are known to perform these actions regularly.
+- Automated scripts: Some automated scripts or deployment tools may stop the Elastic Agent as part of their workflow. Identify these scripts and exclude them from triggering alerts by specifying their process names or arguments in the exception list.
+- Testing environments: In testing or development environments, the Elastic Agent might be stopped frequently for testing purposes. Consider excluding these environments from monitoring or creating specific rules that account for their unique behavior.
+- Non-malicious software conflicts: Certain non-malicious software might inadvertently stop the Elastic Agent due to conflicts or misconfigurations. Investigate and resolve these conflicts, and if necessary, exclude the specific software from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further spread or communication with potential threat actors.
+- Verify the termination of the Elastic Agent service by checking system logs and process status to confirm unauthorized stoppage.
+- Conduct a thorough investigation to identify any unauthorized access or changes made to the system, focusing on the processes and commands listed in the detection query.
+- Review user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
+- Re-enable and restart the Elastic Agent service to restore monitoring capabilities, ensuring it is configured to start automatically on boot.
+- Apply patches and updates to the Elastic Agent and related software to mitigate any known vulnerabilities that could be exploited.
+- Implement enhanced logging policies to capture detailed process execution and service management activities for future analysis.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team if evidence of a broader intrusion or advanced threat is detected.
+- Conduct a post-incident review to identify gaps in security controls and update hardening measures, such as disabling unnecessary services and enforcing strict access controls."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
index 81c67c2d202..26d5d0815ac 100644
--- a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
+++ b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,54 @@ sequence by process.entity_id with maxspan=1m
  [file where host.os.type in ("windows", "macos") and
   event.action != "deletion" and process.name : "python*" and file.name : "rot_??.cpython-*.pyc*"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 ROT Encoded Python Script Execution
+
+ROT encoding, a simple letter substitution cipher, is often used to obfuscate Python scripts, making them harder to analyze. Adversaries exploit this by embedding ROT-encoded scripts within legitimate Python packages to evade detection. The detection rule identifies such activities by monitoring the execution of Python scripts and the presence of ROT-encoded compiled files, signaling potential malicious obfuscation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process.entity_id associated with the suspicious activity to understand which process triggered the alert.
+- Examine the process.name field to confirm the execution of a Python interpreter, ensuring it matches the expected pattern "python*".
+- Investigate the file.name field to identify the presence of ROT-encoded compiled files, specifically looking for patterns like "rot_??.cpython-*.pyc*".
+- Check the event timestamps to determine the sequence and timing of the process start and file creation events, ensuring they fall within the maxspan=1m window.
+- Use Osquery to list all Python processes running on the host to identify any other potentially suspicious Python scripts:
+  ```sql
+  SELECT pid, name, path FROM processes WHERE name LIKE 'python%';
+  ```
+- Query the file system using Osquery to locate all files matching the ROT-encoded pattern to identify other potentially obfuscated scripts:
+  ```sql
+  SELECT path FROM file WHERE path LIKE '%rot_??.cpython-*.pyc%';
+  ```
+- Analyze the parent process of the suspicious Python execution to determine if it was launched by a legitimate application or a potentially malicious one.
+- Review the command-line arguments of the Python process to identify any additional scripts or modules being executed that may not be ROT-encoded but are still suspicious.
+- Investigate the user account associated with the process execution to determine if the activity aligns with expected behavior for that user.
+- Cross-reference the host.os.type field to ensure the investigation is tailored to the specific operating system, considering differences in file paths and process management between Windows and macOS.
+
+### False positive analysis
+
+- Legitimate software development activities: Developers may use ROT encoding during the development process for testing or educational purposes, leading to false positives. Users can manage this by creating exceptions for known development environments or specific developer machines.
+- Security research and educational tools: Security researchers and educators might use ROT encoding to demonstrate obfuscation techniques, which could trigger the detection rule. To handle this, users can whitelist specific research tools or educational scripts that are known to be non-malicious.
+- Automated code analysis tools: Some automated tools might use ROT encoding as part of their analysis or transformation processes, resulting in false positives. Users should identify and exclude these tools from the detection rule to prevent unnecessary alerts.
+- Custom scripts with ROT encoding: Organizations might have internal scripts that use ROT encoding for legitimate purposes, such as data transformation or encoding. Users should document these scripts and exclude them from the detection rule to avoid false alarms.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious activity.
+- Conduct a thorough investigation to identify the source and scope of the ROT-encoded script execution, focusing on recent installations or updates of Python packages.
+- Analyze the ROT-encoded scripts to determine their functionality and potential impact, using deobfuscation techniques if necessary.
+- Remove any identified malicious scripts or packages from the system and ensure they are not present in any other systems within the network.
+- Restore the system from a known good backup prior to the execution of the ROT-encoded script to ensure no residual malicious code remains.
+- Implement enhanced logging policies to capture detailed execution logs of Python scripts, including command-line arguments and script contents.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of obfuscation techniques like ROT encoding.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Educate users and developers on the risks of using obfuscated code and the importance of verifying the integrity of third-party packages.
+- Apply system hardening measures, such as restricting the execution of scripts from untrusted sources and enforcing strict access controls on sensitive systems."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
index 4b46332364f..c28faa0283d 100644
--- a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
+++ b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,49 @@ process.executable regex~ """/[a-z0-9\s_\-\\./]+\s""" and not (
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Masquerading Space After Filename
+
+In Linux and macOS environments, appending a space to a filename can trick the OS into executing a file based on its true type rather than its extension. Adversaries exploit this by disguising malicious files with benign extensions, adding a space to ensure execution. The detection rule identifies such anomalies by monitoring process creation events, filtering out known benign processes, and flagging suspicious executable patterns.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process executable path that triggered the rule, focusing on the presence of a space at the end of the filename.
+- Verify the legitimacy of the process by checking the process name and executable path against known benign processes and paths listed in the query's exceptions.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT pid, name, path, cmdline, cwd, uid, gid, start_time FROM processes WHERE path LIKE '% ' AND path = '<triggered_executable_path>';` to retrieve detailed information about the suspicious process.
+- Investigate the parent process of the suspicious executable to understand the process hierarchy and determine if the parent process is known or expected.
+- Check the file metadata of the suspicious executable, including creation and modification times, to identify any anomalies or recent changes that could indicate tampering.
+- Examine the file type of the executable using the `file` command to confirm if the actual file type matches the expected type based on the file extension.
+- Search for any network connections or communications initiated by the suspicious process to identify potential command and control activity or data exfiltration.
+- Review system logs and other security tools for any additional indicators of compromise or related suspicious activity around the time the process was executed.
+- Investigate the user account associated with the process execution to determine if the account has been compromised or is exhibiting unusual behavior.
+- Correlate the findings with threat intelligence sources to check for known indicators of compromise or patterns associated with the detected behavior.
+
+### False positive analysis
+
+- Known false positives for the Masquerading Space After Filename rule include legitimate processes that may have a space appended to their filenames due to user error or specific application behavior. These can include scripts or executables that are mistakenly renamed with a trailing space.
+- Users can manage these false positives by creating exceptions for known benign processes. This can be done by adding specific process names or executable paths to the exclusion list within the detection rule.
+- For instance, if a legitimate script in a custom directory frequently triggers the rule, users can modify the rule to exclude that specific path or process name.
+- It's important to regularly review and update the exclusion list to ensure that new legitimate processes are not mistakenly flagged, while still maintaining the integrity of the detection for potential threats.
+- Users should also consider the context of the flagged process, such as its parent process and command-line arguments, to determine if it aligns with expected behavior or if it warrants further investigation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to identify the source and scope of the masquerading file, examining logs and process creation events.
+- Terminate any suspicious processes identified as being executed with a space after the filename to halt any ongoing malicious activity.
+- Remove or quarantine the identified malicious files from the system to prevent re-execution.
+- Review and update endpoint protection and antivirus signatures to detect similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process creation events and file modifications for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar masquerading techniques.
+- Restore the system from a known good backup to ensure the integrity and security of the operating environment.
+- Apply system hardening measures, such as restricting file execution permissions and educating users on recognizing suspicious file behaviors, to reduce the risk of future attacks."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_timestomp_touch.toml b/rules/cross-platform/defense_evasion_timestomp_touch.toml
index 36d4a8ca911..aeea69f9e48 100644
--- a/rules/cross-platform/defense_evasion_timestomp_touch.toml
+++ b/rules/cross-platform/defense_evasion_timestomp_touch.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,48 @@ process where event.type == "start" and
    "/usr/lib/go-*/bin/go", "/usr/lib/dracut/dracut-functions.sh", "/tmp/KSInstallAction.*/m/.patch/*"
 ) and not process.parent.name in ("pmlogger_daily", "pmlogger_janitor", "systemd")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Timestomping using Touch Command
+
+Timestomping involves altering file timestamps to evade detection, often using the 'touch' command in Unix-like systems. Adversaries exploit this to blend malicious files with legitimate ones by mimicking their timestamps. The detection rule identifies suspicious 'touch' command executions by non-root users, focusing on specific arguments that modify access and modification times, while excluding benign processes and known legitimate paths.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'touch' command execution by a non-root user, focusing on the specific arguments used, such as "-r", "-t", "-a", and "-m".
+- Identify the user account associated with the alert by examining the 'user.id' field to determine if the account is known or potentially compromised.
+- Investigate the parent process of the 'touch' command using the 'process.parent.name' field to understand the context in which the command was executed and check for any unusual or suspicious parent processes.
+- Cross-reference the file paths involved in the 'touch' command with known legitimate paths to ensure they are not part of the excluded paths, such as "/usr/lib/go-*/bin/go" or "/tmp/KSInstallAction.*/m/.patch/*".
+- Use Osquery to list recent file modifications in the directory where the 'touch' command was executed. Example query: `SELECT path, atime, mtime, ctime FROM file WHERE directory = '/path/to/suspicious/directory' ORDER BY mtime DESC LIMIT 10;`
+- Check system logs for any other suspicious activities or anomalies around the time of the 'touch' command execution to identify potential related events.
+- Analyze the command history of the user account involved to determine if there are any other suspicious commands executed around the same time.
+- Investigate any network connections or external communications initiated by the user account or the system around the time of the alert to identify potential data exfiltration or command-and-control activities.
+- Review any recent changes to user permissions or group memberships that might have allowed the execution of the 'touch' command by a non-root user.
+- Correlate the alert with other security events or alerts in the environment to identify if this is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate administrative scripts or maintenance tasks that use the 'touch' command with timestamp modification arguments. These scripts might be scheduled to run regularly and are not indicative of malicious activity.
+- Developers and system administrators might use the 'touch' command with specific arguments during software development or system configuration processes, which can trigger the detection rule.
+- To manage these false positives, users can create exceptions for specific scripts or processes by adding them to the exclusion list in the detection rule. This can be done by identifying the benign processes and paths that frequently trigger the rule and updating the exclusion criteria accordingly.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify all files and processes that have been timestomped, using forensic tools to analyze file metadata and system logs.
+- Review user activity logs to determine if the non-root user executing the 'touch' command was authorized and if their account has been compromised.
+- Restore affected files from a known good backup to ensure integrity and correct timestamps, and verify the system's operational state.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed command execution and file modification events, ensuring that future timestomping attempts are detected promptly.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and correlate alerts with known threat actors.
+- Apply system hardening measures, such as restricting the use of the 'touch' command to authorized users only and implementing strict access controls.
+- Educate users on security best practices and the risks associated with unauthorized command execution to prevent future incidents.
+- Review and update incident response plans to incorporate lessons learned from the investigation and ensure readiness for similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
index 2ef727a4d0a..c5c9653f16f 100644
--- a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
+++ b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,49 @@ process where event.type == "start" and
  process.args : ("parallels*", "vmware*", "virtualbox*") and process.args : "Manufacturer*" and
  not process.parent.executable in ("/Applications/Docker.app/Contents/MacOS/Docker", "/usr/libexec/kcare/virt-what")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Virtual Machine Fingerprinting via Grep
+
+Virtual machine fingerprinting involves identifying virtualized environments by querying system details. Adversaries exploit tools like `grep` to extract information about virtual machine hardware, aiding in evasion or targeted attacks. The detection rule identifies non-root users executing `grep` with arguments related to virtual machine identifiers, flagging potential reconnaissance activities while excluding benign processes like Docker.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is either "grep" or "egrep" and verify the user ID is not "0" to ensure the alert is triggered by a non-root user.
+- Examine the specific arguments used with the grep command to identify if they include terms like "parallels*", "vmware*", "virtualbox*", or "Manufacturer*". This helps determine if the command was likely used for virtual machine fingerprinting.
+- Check the parent process of the grep command to ensure it is not a benign process such as Docker or kcare/virt-what, as these are excluded in the detection rule.
+- Investigate the user account associated with the alert to determine if the account has a history of suspicious activity or if it is a legitimate user who might have a valid reason for running such commands.
+- Use Osquery to gather more context about the system and user activity. For example, run the following Osquery query to list recent processes executed by the user: `SELECT * FROM processes WHERE uid = '<user_id>' ORDER BY start_time DESC LIMIT 10;`.
+- Analyze system logs to identify any other unusual activities or patterns that coincide with the time of the alert, such as failed login attempts or other reconnaissance commands.
+- Check for any recent changes in the system environment or configurations that might explain the use of virtual machine-related grep commands.
+- Review network logs to identify any outbound connections that might suggest data exfiltration or communication with a command and control server.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack campaign.
+- Consult threat intelligence sources to see if there are any known campaigns or malware that use similar techniques, such as the Pupy RAT, to understand the potential threat actor's tactics and objectives.
+
+### False positive analysis
+
+- Non-root users running legitimate scripts or applications that query virtual machine identifiers for maintenance or monitoring purposes may trigger false positives. 
+- Developers or IT personnel using `grep` to check virtual machine configurations during routine checks or system audits can be mistakenly flagged.
+- Automated scripts or tools that include virtual machine identifier checks as part of their functionality, such as inventory management or compliance tools, might be incorrectly identified as threats.
+- To manage these false positives, users can create exceptions for known benign processes by adding them to the exclusion list in the detection rule, ensuring that routine operations are not disrupted.
+- Regularly review and update the exclusion list to accommodate new legitimate processes that may arise, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the intrusion, focusing on identifying any additional compromised systems or accounts.
+- Review system logs and security alerts to gather information on the adversary's activities and potential entry points.
+- Remove any unauthorized software or malware identified during the investigation, ensuring that all malicious processes are terminated.
+- Change all passwords and credentials associated with the affected system and any potentially compromised accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging and monitoring policies to capture detailed information on system and network activities, aiding in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context on similar threats.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly updating security configurations to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
index ee87869d33c..bc2a628fb03 100644
--- a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
+++ b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/03"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -86,6 +86,53 @@ and process.args: (
     and ("AWS-RunShellScript" or "AWS-RunPowerShellScript")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS SSM `SendCommand` with Run Shell Command Parameters
+
+AWS Systems Manager (SSM) `SendCommand` allows remote command execution on EC2 instances, bypassing traditional access methods like SSH. Adversaries exploit this to execute unauthorized commands, potentially leading to data breaches or system compromise. The detection rule identifies unusual `SendCommand` usage, flagging first-time occurrences of shell script execution on hosts, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific EC2 instance and the time when the `SendCommand` was executed. Pay attention to the `process.args` field to understand the exact command and parameters used.
+- Verify the identity of the user or role that initiated the `SendCommand` by examining the AWS CloudTrail logs. Look for the `userIdentity` field to determine if the action was performed by an expected user or service.
+- Check the AWS CloudTrail logs for any other unusual activities around the same time, such as changes in IAM policies or unusual API calls, which might indicate a broader attack.
+- Investigate the EC2 instance's recent activity by reviewing its system logs. Look for any unexpected processes or network connections that could suggest malicious behavior.
+- Use Osquery to gather more information about the processes running on the affected EC2 instance. For example, run the following query to list all processes that have been started recently:
+  ```sql
+  SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));
+  ```
+- Examine the `host.os.type` field to determine the operating system of the affected instance and tailor your investigation steps accordingly, such as checking for specific OS-related logs or configurations.
+- Analyze the `event.category` and `event.type` fields to confirm that the event is indeed a process start event, ensuring that the alert is not a false positive.
+- Cross-reference the `process.name` field with known legitimate AWS CLI usage patterns within your organization to determine if the command execution is expected or anomalous.
+- Investigate any other alerts or incidents involving the same EC2 instance or AWS account to identify potential patterns or correlations with other suspicious activities.
+- Consult with the instance owner or relevant stakeholders to verify if the `SendCommand` execution was authorized and part of a legitimate operation, or if it requires further investigation.
+
+### False positive analysis
+
+- Routine administrative tasks: Organizations often use AWS SSM `SendCommand` with `AWS-RunShellScript` or `AWS-RunPowerShellScript` for legitimate administrative purposes, such as patch management or software installation. These activities can trigger the rule as false positives.
+- Automated scripts: Scheduled or automated scripts that perform regular maintenance or monitoring tasks on EC2 instances may also use these parameters, leading to false positives.
+- DevOps processes: Continuous integration and deployment pipelines might leverage AWS SSM `SendCommand` for deploying applications or configurations, which can be mistakenly flagged as suspicious.
+- To manage these false positives, users can create exceptions for known, non-threatening behaviors by identifying and excluding specific hosts or processes that regularly use these commands for legitimate purposes.
+- Implementing a baseline of normal activity for each host can help distinguish between expected and anomalous command executions, reducing the likelihood of false positives.
+- Regularly review and update the list of exceptions to ensure that only verified and safe activities are excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized access or data exfiltration.
+- Review AWS CloudTrail logs to identify the source of the `SendCommand` API call and determine if it was authorized or if credentials were compromised.
+- Verify the integrity of the affected instance by checking for unauthorized changes or installed software, focusing on the execution of shell scripts.
+- Revoke any compromised AWS IAM credentials and rotate keys to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the incident, including identifying other potentially affected instances or services.
+- Escalate the incident to the security operations team for further analysis and to determine if additional resources are needed.
+- Implement enhanced logging and monitoring for AWS SSM and related services to detect similar activities in the future.
+- Restore the affected EC2 instance from a known good backup or AMI to ensure it is free from malicious modifications.
+- Apply security hardening measures, such as restricting SSM command execution permissions to only trusted users and roles.
+- Update security policies and provide training to relevant personnel to prevent similar incidents, leveraging MITRE ATT&CK framework insights on cloud administration command threats."""
 
 [rule.investigation_fields]
 field_names = [
diff --git a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
index f97739824da..32da36c246f 100644
--- a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
+++ b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,54 @@ type = "query"
 query = '''
 event.category:process and event.type:(process_started or start) and process.name:espl and process.args:eyJkZWJ1ZyI6*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 EggShell Backdoor Execution
+
+EggShell is a post-exploitation tool used on macOS and Linux systems, allowing adversaries to execute commands remotely, capture keystrokes, and access system data. Attackers exploit this tool to maintain persistence and control over compromised systems. The detection rule identifies suspicious process activities by monitoring specific process names and arguments, signaling potential EggShell execution, thus enabling timely threat response.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the EggShell Backdoor Execution by verifying the process name `espl` and the process arguments starting with `eyJkZWJ1ZyI6`.
+- Correlate the alert with other events in the same timeframe to identify any additional suspicious activities or related alerts.
+- Use Osquery to list all running processes and check for any instances of the `espl` process to confirm its execution:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE name = 'espl';
+  ```
+- Investigate the parent process of the `espl` process to determine how it was initiated and identify any potential initial access vectors.
+- Examine the user account associated with the `espl` process to determine if it is a legitimate user or if the account may have been compromised.
+- Check for any network connections established by the `espl` process to identify potential command and control communication:
+  ```sql
+  SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'espl');
+  ```
+- Analyze the process arguments and any encoded data within `eyJkZWJ1ZyI6` to understand the commands or payloads being executed.
+- Review system logs for any signs of privilege escalation or lateral movement attempts following the execution of the `espl` process.
+- Investigate any file modifications or new files created around the time of the alert to identify potential payloads or data exfiltration attempts.
+- Cross-reference the alert with threat intelligence sources to determine if the observed behavior matches known EggShell Backdoor campaigns or tactics.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that use similar process names or arguments as EggShell may trigger false positives. For instance, custom scripts or applications that include 'espl' in their process name or use encoded arguments starting with 'eyJkZWJ1ZyI6' could be mistakenly flagged.
+- Developers or IT personnel testing security tools or conducting penetration tests might inadvertently execute processes that resemble EggShell activity, leading to false alerts.
+- To manage these false positives, users can create exceptions for known benign processes by whitelisting specific process names or arguments that are regularly used in their environment but are confirmed to be non-threatening.
+- Regularly review and update the list of exceptions to ensure that only verified non-malicious activities are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation to confirm the presence of the EggShell backdoor by analyzing process execution logs and correlating with known indicators of compromise.
+- Terminate any suspicious processes associated with EggShell and remove any unauthorized user accounts or credentials that may have been created.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
+- Educate users on recognizing phishing attempts and other common attack vectors to reduce the risk of future compromises.
+- Implement hardening measures such as disabling unnecessary services, enforcing strong password policies, and using multi-factor authentication to enhance overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_potential_widespread_malware_infection.toml b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
index 99d34658172..2cbdcfe2008 100644
--- a/rules/cross-platform/execution_potential_widespread_malware_infection.toml
+++ b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/08"
 maturity = "production"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
 
@@ -38,6 +38,48 @@ from logs-endpoint.alerts-*
 | stats hosts = count_distinct(host.id) by rule.name, event.code
 | where hosts >= 3
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Widespread Malware Infection Across Multiple Hosts
+
+Endpoint detection technologies monitor systems for signs of malicious activity, such as malware signatures or suspicious behavior. Adversaries exploit these systems by deploying malware across multiple hosts to maximize impact. The detection rule identifies potential widespread infections by flagging when malware indicators appear on three or more hosts, enabling analysts to prioritize and respond swiftly to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which `rule.name` and `event.code` triggered the alert, focusing on the specific malware signatures or behaviors detected.
+- Identify the affected hosts by examining the `host.id` field in the alert data to determine the scope of the potential infection.
+- Cross-reference the `host.id` with asset management systems to gather additional context about the affected hosts, such as their role, operating system, and criticality.
+- Use endpoint detection and response (EDR) tools to collect and analyze recent activity on the affected hosts, looking for unusual processes, network connections, or file modifications.
+- Execute an Osquery to gather detailed information about running processes on the affected hosts. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE host_id IN ('<affected_host_ids>');`
+- Investigate any suspicious files or processes identified in the previous step by checking their hashes against threat intelligence databases to determine if they are known malware.
+- Analyze network traffic logs for the affected hosts to identify any unusual outbound connections that may indicate command and control (C2) communication.
+- Review user activity on the affected hosts to determine if any unauthorized or unexpected user actions occurred around the time of the alert.
+- Check for any recent changes in system configurations or installed software on the affected hosts that could have introduced vulnerabilities.
+- Document all findings and gather evidence to support further analysis or escalation, ensuring that all relevant data points, such as `rule.name`, `event.code`, and `host.id`, are included for context.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger malware signatures, especially if they involve changes to system files or memory, leading to false positives. Users can manage these by creating exceptions for known update processes or trusted software vendors.
+- Security tools or system management software that perform regular scans or updates might mimic suspicious behavior, such as executing shellcode or modifying memory, which could be flagged incorrectly. To handle this, users should whitelist these tools in the detection system.
+- Custom scripts or administrative tools used for system maintenance might be misidentified as malicious if they perform actions similar to malware. Users can reduce false positives by excluding these scripts or tools from monitoring, provided they are verified as safe.
+- Testing environments or sandboxed applications that simulate malware behavior for research or development purposes can trigger alerts. Users should ensure these environments are isolated and excluded from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Isolate affected hosts from the network to prevent further spread of the malware and contain the infection.
+- Conduct a thorough investigation on the isolated hosts to identify the malware variant and entry point, leveraging forensic tools and endpoint detection logs.
+- Remove the identified malware from the affected systems using antivirus or specialized malware removal tools, ensuring all traces are eradicated.
+- Apply security patches and updates to all systems to close vulnerabilities exploited by the malware, focusing on those related to the MITRE ATT&CK technique T1204: User Execution.
+- Restore systems from clean backups if malware removal is unsuccessful, ensuring backups are free from infection before restoration.
+- Escalate the incident to the security operations center (SOC) or incident response team if the infection is severe or cannot be contained, providing detailed findings from the investigation.
+- Implement enhanced logging policies to capture detailed endpoint activity, including process execution and network connections, to improve future detection and analysis.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance visibility and correlation of suspicious activities across the network.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement hardening measures such as application whitelisting, user education on phishing, and least privilege access controls to reduce the risk of future infections."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
index 877e4ced8fd..53a8c788c44 100644
--- a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
+++ b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ sequence by host.id with maxspan=1m
                    "php*",
                    "wget")] by process.parent.pid
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential JAVA/JNDI Exploitation Attempt
+
+Java Naming and Directory Interface (JNDI) is a Java API that provides naming and directory functionality, allowing Java applications to discover and look up data and resources via a directory service. Adversaries can exploit JNDI by injecting malicious payloads that trigger outbound connections to attacker-controlled servers, potentially leading to remote code execution. The detection rule identifies such exploitation attempts by monitoring Java processes making outbound connections to specific ports associated with directory services, followed by the execution of suspicious child processes, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `process.pid` associated with the suspicious activity.
+- Examine the network logs to confirm the outbound connection attempt by the Java process to the specified ports (1389, 389, 1099, 53, 5353) and verify if the destination IP addresses are known or suspicious.
+- Check the process tree to identify the parent Java process and any child processes that were spawned, focusing on those listed in the query (e.g., "sh", "bash", "curl").
+- Use Osquery to gather additional context about the Java process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <process.pid>;` to retrieve command-line arguments and the executable path.
+- Investigate the child processes further by querying their command-line arguments and execution paths to determine if they were used to download or execute additional payloads.
+- Analyze the timing of the events to see if the suspicious child processes were executed immediately after the network connection attempt, which could indicate a successful exploitation.
+- Cross-reference the destination IP addresses with threat intelligence sources to determine if they are associated with known malicious activity or command-and-control servers.
+- Review historical logs for the same `host.id` to identify any previous similar activities or patterns that might indicate ongoing exploitation attempts.
+- Check for any other alerts or anomalies related to the same Java process or host within the same timeframe to gather more context about the potential attack.
+- If available, use endpoint detection and response (EDR) tools to perform a deeper analysis of the affected host, focusing on file modifications, registry changes, and other indicators of compromise that may have occurred around the time of the alert.
+
+### False positive analysis
+
+- Legitimate enterprise applications may use JNDI for valid purposes, such as connecting to LDAP directories for authentication or configuration management, which could trigger the rule. Users should identify and whitelist these applications by excluding their specific process names or network behaviors.
+- Automated scripts or tools that perform regular maintenance or monitoring tasks might initiate outbound connections to directory service ports and spawn child processes like shell scripts or command-line tools. Users can create exceptions for these known scripts by specifying their process hashes or command-line arguments.
+- Development environments often use JNDI for testing purposes, which may involve connections to local or remote directory services and execution of various scripts. Developers should document these activities and exclude them from the rule by defining specific hostnames or IP addresses used in the development environment.
+- Security tools or network monitoring solutions might simulate JNDI exploitation attempts as part of their testing or alerting mechanisms. Users should coordinate with their security teams to identify these tools and exclude their activities from triggering the rule by using process or network identifiers.
+- In some cases, cloud-based services or microservices architectures might use JNDI for service discovery or configuration, leading to benign outbound connections and child process executions. Users should review their cloud configurations and exclude known service patterns by specifying relevant service accounts or container IDs.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to identify the scope of the attack, including checking for other systems that may have been compromised.
+- Analyze logs and network traffic to determine the source of the malicious payload and any outbound connections to attacker-controlled servers.
+- Terminate any suspicious processes identified in the alert, particularly those involving shell or scripting interpreters spawned by Java.
+- Apply security patches and updates to the Java environment and any other vulnerable software to mitigate the exploitation vector.
+- Restore the system from a known good backup if the integrity of the system is in question.
+- Implement enhanced logging policies to capture detailed process execution and network connection attempts for future analysis.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of timely patch management and monitoring."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/guided_onboarding_sample_rule.toml b/rules/cross-platform/guided_onboarding_sample_rule.toml
index 90163be7f7e..98dd2afd90a 100644
--- a/rules/cross-platform/guided_onboarding_sample_rule.toml
+++ b/rules/cross-platform/guided_onboarding_sample_rule.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/09/22"
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,13 +20,50 @@ language = "kuery"
 license = "Elastic License v2"
 max_signals = 1
 name = "My First Rule"
-note = """This is a test alert.
+note = """## Triage and analysis
 
-This alert does not show threat activity. Elastic created this alert to help you understand how alerts work.
+### Disclaimer
 
-For normal rules, the Investigation Guide will help analysts investigate alerts.
+This investigation guide was generated 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 My First Rule
+
+Elastic Security leverages event data to monitor system activities. Adversaries often exploit event logs to cover tracks or execute unauthorized actions. The 'My First Rule' is a foundational query that captures all event types, serving as a baseline for understanding normal versus suspicious activities. While it doesn't target specific threats, it aids in familiarizing analysts with alert mechanisms. This is a test alert. This alert does not show threat activity. Elastic created this alert to help you understand how alerts work. For normal rules, the Investigation Guide will help analysts investigate alerts. This alert will show once every 24 hours for each host. It is safe to disable this rule.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context and specific event that triggered the alert, focusing on the `event.kind:event` field.
+- Examine the timestamp of the event to determine when the activity occurred and correlate it with other events around the same time.
+- Identify the source and destination IP addresses involved in the event to assess if they are internal or external to the organization.
+- Check the user account associated with the event to verify if the activity aligns with the user's normal behavior or role.
+- Investigate the host or system where the event originated to gather more context about its current state and recent activities.
+- Utilize Osquery to gather additional information about the system. For example, run the query `SELECT * FROM processes WHERE pid = <suspicious_pid>;` to investigate any suspicious processes.
+- Analyze related logs from other security tools or systems to identify any patterns or anomalies that could indicate suspicious behavior.
+- Look for any recent changes in system configurations or installed software that might explain the event.
+- Cross-reference the event with known threat intelligence sources to determine if it matches any known indicators of compromise.
+- Document findings and any hypotheses about the nature of the event to facilitate further investigation or handoff to other analysts.
+
+### False positive analysis
+
+- The 'My First Rule' captures all event types, which means it can generate alerts for routine system activities that are not indicative of malicious behavior, such as regular user logins, system updates, or scheduled tasks.
+- To manage these false positives, users can create exceptions for known benign activities by identifying patterns in the event data that consistently trigger alerts but are verified as non-threatening.
+- Analysts should regularly review and update exception lists to ensure that new benign activities are accounted for, reducing unnecessary alerts and focusing on potential threats.
+- It's important to collaborate with IT and security teams to understand the context of frequent events and determine which can be safely excluded from triggering alerts.
+- Users can leverage Elastic Security's filtering capabilities to refine the rule's query, excluding specific event types or sources that are known to generate false positives without compromising security monitoring.
+
+### Response and remediation
+
+- Review the alert details to understand the context and determine if it aligns with normal activity or indicates a potential issue.
+- Contain the affected system by isolating it from the network to prevent further unauthorized access or damage.
+- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities in the system logs.
+- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system.
+- Restore the system to its last known good state using backups or system restore points.
+- Escalate the incident to the appropriate security team or management if the activity suggests a broader threat or breach.
+- Implement enhanced logging policies to capture more detailed event data for future analysis and detection.
+- Integrate additional security tools, such as intrusion detection systems or endpoint protection, to improve monitoring capabilities.
+- Review and update security policies and procedures to address any gaps identified during the investigation.
+- Conduct a post-incident review to learn from the event and strengthen the organization's security posture.
 
-This alert will show once every 24 hours for each host. It is safe to disable this rule.
 """
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-rules.html"]
 risk_score = 21
diff --git a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
index c335de8be23..918dc8ff87a 100644
--- a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
+++ b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/09/14"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,50 @@ query = '''
 event.type:creation and event.module:zoom and event.dataset:zoom.webhook and
   event.action:meeting.created and not zoom.meeting.password:*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Zoom Meeting with no Passcode
+
+Zoom meetings without passcodes are vulnerable to unauthorized access, known as Zoombombing, where intruders disrupt sessions with inappropriate content. Adversaries exploit this by targeting unprotected meetings, leading to potential data breaches or session shutdowns. The detection rule identifies such meetings by monitoring Zoom event logs for creation events lacking a passcode, helping to mitigate these security risks.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `event.type:creation` and `event.action:meeting.created` fields, ensuring the alert is triggered by a meeting creation event.
+- Check the `event.module:zoom` and `event.dataset:zoom.webhook` fields to verify the event source and ensure it is related to Zoom's webhook data.
+- Investigate the `zoom.meeting.password` field to confirm the absence of a passcode, which is the primary trigger for this alert.
+- Identify the user or account associated with the meeting creation by examining the user-related fields in the event logs.
+- Cross-reference the meeting ID with other logs to determine if there were any unauthorized access attempts or unusual activities associated with the meeting.
+- Use Osquery to gather additional context on the host machine from which the meeting was created. Example query: `SELECT * FROM processes WHERE name LIKE '%zoom%' AND start_time > (SELECT datetime('now', '-1 hour'));` to identify recent Zoom processes.
+- Analyze network logs to detect any suspicious IP addresses or connections that may have interacted with the meeting link.
+- Review historical data for patterns of meetings created without passcodes by the same user or account to identify potential negligence or malicious intent.
+- Check for any related alerts or incidents involving the same user or meeting ID to assess if this is part of a larger security issue.
+- Document findings and gather evidence from the investigation to support further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Internal meetings intentionally set without passcodes for ease of access can trigger false positives. These are often non-threatening if the meeting links are shared only within a trusted network.
+- Educational institutions may host open sessions for public webinars or lectures, which might be flagged by the rule. These sessions are typically non-threatening if they are monitored and managed by the host.
+- Organizations conducting public events or community outreach programs might create meetings without passcodes to encourage participation. These should be reviewed to ensure they are not mistakenly flagged as threats.
+- To manage these false positives, users can create exceptions for specific meeting hosts or recurring meeting IDs that are known to be safe and intentionally set without passcodes.
+- Implementing a whitelist of trusted domains or email addresses that frequently create meetings without passcodes can help reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure it aligns with current organizational practices and security policies.
+
+### Response and remediation
+
+- Immediately terminate any ongoing Zoom meetings identified without a passcode to prevent further unauthorized access or disruption.
+- Notify the meeting host and relevant stakeholders about the security incident and advise them to reschedule the meeting with appropriate security measures, such as enabling a passcode or waiting room.
+- Review Zoom account settings to ensure that passcodes are required for all future meetings by default and consider enabling additional security features like waiting rooms or authentication.
+- Conduct a thorough investigation of the event logs to identify any unauthorized access or data breaches that may have occurred during the unprotected meeting.
+- Escalate the incident to the IT security team for further analysis and to determine if any sensitive information was compromised, leveraging the MITRE ATT&CK framework to understand potential exploitation methods.
+- Implement enhanced logging policies to capture detailed Zoom meeting events, including participant join and leave times, to aid in future investigations.
+- Integrate Zoom with security information and event management (SIEM) systems to automate the detection and alerting of meetings created without passcodes.
+- Educate users on the importance of securing virtual meetings and provide training on how to configure Zoom settings to prevent Zoombombing.
+- Restore any affected systems or services to their operational state by applying necessary security patches and updates to prevent similar incidents.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as enforcing multi-factor authentication for all Zoom accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/multiple_alerts_different_tactics_host.toml b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
index 676a9a892e7..3f5a63f224a 100644
--- a/rules/cross-platform/multiple_alerts_different_tactics_host.toml
+++ b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,49 @@ type = "threshold"
 query = '''
 signal.rule.name:* and kibana.alert.rule.threat.tactic.id:*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Multiple Alerts in Different ATT&CK Tactics on a Single Host
+
+In cybersecurity, detecting multiple alerts across different ATT&CK tactics on a single host is crucial for identifying potential compromises. Adversaries often exploit various tactics to infiltrate and persist within a network, such as initial access, execution, and exfiltration. The detection rule leverages alert data to identify hosts triggering alerts in multiple attack phases, indicating a higher likelihood of compromise. This prioritizes these hosts for triage, enabling analysts to respond swiftly to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific ATT&CK tactics and techniques were triggered, focusing on the `kibana.alert.rule.threat.tactic.id` field for context.
+- Correlate the alert timestamps to identify the sequence of events and determine if there is a pattern or timeline of activities on the host.
+- Examine the host's network traffic logs to identify any unusual outbound connections that may indicate data exfiltration or command and control communication.
+- Check for any recent changes in user accounts or privileges on the host that could suggest lateral movement or privilege escalation.
+- Use Osquery to gather detailed information about the host's current state. For example, run the following query to list all running processes: `SELECT pid, name, path, cmdline FROM processes;`.
+- Investigate any newly installed or modified software on the host that could be related to the alerts, using file integrity monitoring logs or software inventory records.
+- Analyze the host's event logs for any failed login attempts, unusual login times, or logins from unexpected locations.
+- Review any recent email activity associated with the host's user account to identify potential phishing attempts or suspicious attachments.
+- Check for any scheduled tasks or cron jobs on the host that could be used for persistence or automated malicious activities.
+- Cross-reference the host's alert data with threat intelligence feeds to identify any known indicators of compromise (IOCs) that match the observed activities.
+
+### False positive analysis
+
+- Routine administrative tasks or software updates can trigger alerts across multiple ATT&CK tactics, leading to false positives. For example, legitimate software installations might involve execution and persistence tactics.
+- Security tools or scripts running on a host for monitoring or maintenance purposes may generate alerts in different tactics, such as execution and discovery, without indicating a compromise.
+- Users can manage these false positives by creating exceptions for known benign activities, such as scheduled software updates or specific administrative scripts, ensuring these do not trigger unnecessary alerts.
+- Implementing a baseline of normal behavior for hosts can help distinguish between legitimate activities and potential threats, reducing the likelihood of false positives.
+- Regularly reviewing and updating the list of exceptions based on changes in the network environment or operational procedures can help maintain the accuracy of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to identify the specific ATT&CK tactics and techniques involved, using available threat intelligence and alert data.
+- Analyze logs and network traffic to determine the scope of the compromise and identify any additional affected systems.
+- Remove any identified malicious software or unauthorized access tools from the host.
+- Apply security patches and updates to the affected host to address any exploited vulnerabilities.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Implement enhanced logging and monitoring policies to capture detailed activity on critical systems for future investigations.
+- Integrate additional security tools and threat intelligence feeds to improve detection capabilities and reduce response times.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and staff on security best practices and the specific tactics used in the attack to prevent future incidents."""
 
 
 
diff --git a/rules/cross-platform/multiple_alerts_involving_user.toml b/rules/cross-platform/multiple_alerts_involving_user.toml
index 076a1096ea5..b8d97bade69 100644
--- a/rules/cross-platform/multiple_alerts_involving_user.toml
+++ b/rules/cross-platform/multiple_alerts_involving_user.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -33,6 +33,48 @@ type = "threshold"
 query = '''
 signal.rule.name:* and user.name:* and not user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Multiple Alerts Involving a User
+The detection rule leverages alert data to identify users triggering multiple distinct alerts, which may indicate potential compromise. Adversaries often exploit user accounts to escalate privileges or exfiltrate data. By filtering out system accounts, the rule focuses on genuine user activity, helping analysts prioritize investigations and respond to potential threats effectively.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific alerts triggered for the user, focusing on the `signal.rule.name` field to identify the types of alerts involved.
+- Verify the user's identity and role within the organization using the `user.name` field to assess the potential impact of a compromise.
+- Check the user's recent activity logs to identify any unusual behavior patterns or deviations from their normal activity.
+- Investigate the user's login history, including timestamps and IP addresses, to detect any suspicious access attempts or locations.
+- Examine any recent changes to the user's account, such as password resets or privilege escalations, that could indicate unauthorized access.
+- Use Osquery to gather additional context on the user's machine. For example, run the following query to list recent processes executed by the user: `SELECT * FROM processes WHERE user = '<user.name>';`.
+- Correlate the alerts with other security events or logs to identify any related incidents or broader attack patterns.
+- Check for any recent changes in the user's network activity, such as unusual data transfers or connections to known malicious IPs.
+- Investigate any associated alerts or incidents involving other users or systems that may indicate a coordinated attack.
+- Document all findings and observations to provide a comprehensive overview of the investigation for further analysis and decision-making.
+
+### False positive analysis
+
+- Known false positives for the Multiple Alerts Involving a User rule may include users with roles that inherently trigger multiple alerts due to their job functions, such as system administrators or security personnel who regularly access sensitive systems or data.
+- Users involved in automated processes or scripts that interact with various systems might also trigger multiple alerts without any malicious intent.
+- To manage these false positives, users can create exceptions for specific user accounts that are known to generate frequent alerts as part of their normal operations, ensuring these are documented and reviewed regularly.
+- Implementing a baseline of normal user behavior can help distinguish between legitimate and suspicious activities, allowing for more accurate identification of potential threats.
+- Regularly updating the list of system accounts and roles that are excluded from the rule can help reduce the number of false positives and improve the efficiency of threat detection.
+
+### Response and remediation
+
+- Isolate the affected user account by disabling it temporarily to prevent further unauthorized access.
+- Conduct a thorough investigation of the alerts to determine the nature and scope of the compromise, focusing on any unusual activities or access patterns.
+- Review and analyze logs from relevant systems and applications to identify any additional indicators of compromise or lateral movement.
+- Reset the credentials of the compromised user account and any other accounts that may have been affected.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a significant threat or widespread impact.
+- Implement additional logging and monitoring to capture detailed user activity and detect similar threats in the future.
+- Integrate threat intelligence feeds to enhance detection capabilities and provide context for future alerts.
+- Restore affected systems to their operational state by applying necessary patches and updates, and ensure data integrity is maintained.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Implement hardening measures such as multi-factor authentication, least privilege access, and regular security awareness training for users."""
 
 
 
diff --git a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
index 85d4432c091..811a13321e3 100644
--- a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
+++ b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,49 @@ event.category:file and event.type:change and
            systemd or containerd or pacman
          )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Standard Authentication Module or Configuration
+
+Authentication modules, such as PAM (Pluggable Authentication Modules), are crucial for managing user authentication in systems. Adversaries may exploit these by altering modules or configurations to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to authentication files and processes, excluding legitimate system updates, to flag potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file and process involved in the modification, focusing on `file.name` and `file.path` fields to determine which authentication module was altered.
+- Check the `process.executable` field to identify the process that made the change and verify if it is listed as an excluded legitimate process.
+- Investigate the `event.category` and `event.type` fields to confirm the nature of the change and ensure it aligns with unauthorized modifications.
+- Use Osquery to list all PAM modules and their current configurations to identify any discrepancies or unauthorized changes. Example query: `SELECT * FROM file WHERE path LIKE '/etc/pam.d/%' OR path LIKE '/usr/lib64/security/%';`
+- Cross-reference the timestamp of the alert with system logs to identify any concurrent suspicious activities or user logins that could indicate unauthorized access.
+- Examine the system's package management logs (e.g., yum, dnf, apt) to rule out legitimate updates or installations that might have triggered the alert.
+- Check for any recent user account changes or additions that could be associated with the modification, using commands like `getent passwd` or `cat /etc/passwd`.
+- Investigate the system's cron jobs and startup scripts for any unauthorized entries that could indicate persistence mechanisms.
+- Review the system's audit logs for any anomalies or patterns of access that coincide with the time of the modification.
+- Conduct a historical search for similar alerts or modifications on the same system or across the network to identify potential patterns or repeated attempts.
+
+### False positive analysis
+
+- System updates and package installations can trigger false positives as they often involve legitimate changes to authentication modules or configurations. Users should monitor and exclude processes related to package management tools like `yum`, `dnf`, `apt`, and `rpm` to reduce noise.
+- Administrative tasks such as system configuration changes or maintenance activities performed by authorized personnel may also result in false positives. It's advisable to create exceptions for known administrative processes and users during these periods.
+- Automated scripts or tools that manage system configurations, such as configuration management software (e.g., Ansible, Puppet, Chef), can cause false positives. Users should identify and exclude these tools from triggering alerts.
+- Temporary files or directories used during legitimate software installations or updates, such as those in `/tmp` or `/private/var/folders`, may be flagged. Excluding these paths from monitoring can help minimize false positives.
+- Development or testing environments where frequent changes to authentication modules are expected might generate false positives. Users should consider applying more lenient rules or exclusions in these environments to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the scope of the modification, including reviewing logs and identifying any unauthorized changes to authentication modules or configurations.
+- Verify the integrity of the authentication modules by comparing them against known good versions or using a trusted source to restore them.
+- Remove any unauthorized users or credentials that may have been added as a result of the modification.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for authentication-related activities to detect future unauthorized changes promptly.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify authentication modules or configurations.
+- Apply security patches and updates to the system to address any vulnerabilities that may have been exploited.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to prevent similar incidents in the future.
+- Consider deploying additional security measures such as multi-factor authentication (MFA) and intrusion detection systems (IDS) to enhance the overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/persistence_shell_profile_modification.toml b/rules/cross-platform/persistence_shell_profile_modification.toml
index 60a1afc60aa..a5c39525b8b 100644
--- a/rules/cross-platform/persistence_shell_profile_modification.toml
+++ b/rules/cross-platform/persistence_shell_profile_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,50 @@ event.category:file and event.type:change and
              /Users/*/.bash_profile or
              /Users/*/.zshenv)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Bash Shell Profile Modification
+
+Bash shell profiles, such as `.bash_profile` and `.bashrc`, are scripts that configure user environments upon login. Adversaries exploit these files to maintain persistence by embedding malicious commands that execute automatically. The detection rule identifies unauthorized changes to these profiles by monitoring file modifications and filtering out benign processes, thus highlighting potential security threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path that was modified, focusing on paths like `/home/*/.bash_profile` or `/home/*/.bashrc`.
+- Examine the `process.name` field in the alert to determine which process was responsible for the modification, ensuring it is not one of the benign processes filtered out in the query.
+- Check the `process.executable` field to verify the location of the executable that made the change, ensuring it is not from a known safe directory like `/Applications/*` or `/usr/local/*`.
+- Use Osquery to list recent modifications to the user's shell profile files with a query like: `SELECT path, mtime FROM file WHERE path IN ('/home/*/.bash_profile', '/home/*/.bashrc') ORDER BY mtime DESC LIMIT 5;`.
+- Investigate the user account associated with the modified file to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Review the contents of the modified shell profile file to identify any unusual or malicious commands that may have been added.
+- Cross-reference the timestamp of the file modification with other logs, such as authentication or network logs, to identify any correlated suspicious activity.
+- Check for any recent installations or updates on the system that might have legitimately modified the shell profile files.
+- Investigate any other alerts or anomalies associated with the same user or system to determine if this is part of a broader attack pattern.
+- Consult threat intelligence sources to see if the identified modification or process is associated with known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Frequent legitimate modifications to Bash shell profiles by system administrators or automated scripts can trigger false positives. These include updates made by package managers or configuration management tools.
+- Users often customize their shell environment by adding aliases, functions, or environment variables, which can be mistakenly flagged as suspicious.
+- Development tools and IDEs might modify these profiles to set up necessary environment variables or paths, leading to benign alerts.
+- To manage these false positives, users can create exceptions for known benign processes or specific file paths that are regularly modified for legitimate reasons.
+- Implementing a whitelist of trusted processes or directories can help reduce noise by excluding routine modifications from triggering alerts.
+- Regularly review and update the detection rule to accommodate new legitimate processes or tools that interact with Bash shell profiles.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify unauthorized changes by comparing the current Bash shell profile files with known good backups or baselines.
+- Review recent user activity and process execution logs to identify the source of the unauthorized modifications and any associated malicious processes.
+- Remove any malicious entries from the Bash shell profile files and restore them to their original state using verified backups.
+- Scan the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any identified threats.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger attack campaign or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed file modification events and process execution data for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Educate users on the importance of secure shell practices and the risks associated with unauthorized profile modifications.
+- Apply system hardening measures, such as restricting write permissions to critical configuration files and using multi-factor authentication (MFA) for user logins, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
index 71edbff424d..ba6b53aff50 100644
--- a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
+++ b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,49 @@ event.category:file and event.type:(change or creation) and
               /usr/bin/chef-client
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SSH Authorized Keys File Modification
+
+SSH authorized_keys files are crucial for secure, password-less authentication, allowing specified users to access systems via public keys. Adversaries exploit this by adding their keys, ensuring persistent access. The detection rule identifies unauthorized changes to these files, excluding benign processes, to flag potential malicious activity, aligning with MITRE ATT&CK's persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file that was modified, focusing on `file.name` to determine if it was "authorized_keys", "authorized_keys2", or another critical SSH configuration file.
+- Examine the `event.category` and `event.type` fields to confirm the nature of the change, whether it was a file creation or modification.
+- Check the `process.executable` field to identify the process responsible for the modification and verify if it is listed in the exclusion list of benign processes.
+- Investigate the user account associated with the modification event to determine if it aligns with expected administrative activity or if it appears suspicious.
+- Use Osquery to list all current entries in the authorized_keys file for the affected user account. Example query: `SELECT * FROM authorized_keys WHERE path = '/home/username/.ssh/authorized_keys';`
+- Cross-reference the public keys found in the authorized_keys file with known legitimate keys to identify any unauthorized additions.
+- Review recent login events for the affected user account to identify any unusual access patterns or times that could indicate unauthorized access.
+- Analyze system logs around the time of the modification event to identify any other suspicious activities or related events.
+- Investigate any network connections or data transfers initiated by the process responsible for the modification to assess potential data exfiltration or lateral movement.
+- Correlate the findings with other security alerts or incidents to determine if this event is part of a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often modify SSH authorized_keys files during regular maintenance or when adding new users. These legitimate changes can trigger false positives.
+- Automated configuration management: Tools like Puppet, Chef, or Ansible may update authorized_keys files as part of their configuration management processes, leading to benign alerts.
+- Software updates: Some software installations or updates might modify SSH configuration files, including authorized_keys, as part of their setup process.
+- Development tools: Developers using tools like Git or Maven might inadvertently trigger alerts when these tools interact with SSH keys during development activities.
+- To manage false positives, users can refine the detection rule by adding exceptions for known benign processes or specific user actions that are regularly audited and verified. This can be done by updating the exclusion list in the detection rule to include additional trusted processes or paths that are identified during routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Verify the integrity of the SSH authorized_keys file by comparing it with a known good backup or baseline.
+- Remove any unauthorized keys found in the authorized_keys file and reset SSH configurations to default settings.
+- Conduct a thorough investigation to identify how the adversary gained access and whether other systems are affected.
+- Review system logs and security alerts to trace the adversary's activities and identify any additional compromised accounts or systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed SSH access logs and file modification events for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore the system to its operational state by applying security patches, updating software, and ensuring all configurations are secure.
+- Harden the system by enforcing strong authentication mechanisms, such as multi-factor authentication, and regularly auditing user access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
index d6509cbfe32..d323deb87b3 100644
--- a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
+++ b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -33,6 +33,48 @@ type = "query"
 query = '''
 event.category:process and event.type:start and process.args:(echo and *NOPASSWD*ALL*)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via Sudoers File Modification
+
+The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by modifying the file to allow unauthorized privilege escalation, often using the NOPASSWD directive to bypass password prompts. The detection rule identifies suspicious process activities, such as attempts to alter sudoers configurations, by monitoring specific command patterns indicative of such abuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the specific process and command line arguments that triggered the alert, focusing on `process.args` containing `echo` and `*NOPASSWD*ALL*`.
+- Verify the user account associated with the process by examining the `user.name` field to determine if the account has a history of administrative actions or if it is a potential target for compromise.
+- Check the `process.executable` field to identify the binary used to execute the command and ensure it is a legitimate system binary.
+- Investigate the parent process using `process.parent.executable` and `process.parent.args` to understand the origin of the suspicious process and assess if it was initiated by a legitimate or suspicious activity.
+- Use Osquery to list recent modifications to the sudoers file by running: `SELECT * FROM file WHERE path = '/etc/sudoers' OR path LIKE '/etc/sudoers.d/%' ORDER BY atime DESC LIMIT 5;` to identify any unauthorized changes.
+- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any entries related to sudo or authentication attempts around the time of the alert to gather additional context.
+- Cross-reference the alert timestamp with other security events or alerts to identify any correlated activities that might indicate a broader attack campaign.
+- Investigate the network activity of the involved host around the time of the alert to identify any suspicious outbound connections that might suggest data exfiltration or command-and-control communication.
+- Review the history of sudoers file modifications by checking version control systems or backup logs, if available, to identify when and by whom the changes were made.
+- Assess the system for other indicators of compromise, such as unusual user accounts, unauthorized software installations, or unexpected system configurations, to determine if the privilege escalation attempt is part of a larger intrusion.
+
+### False positive analysis
+
+- System administrators or automated scripts may legitimately modify the sudoers file to update permissions, which can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or scripts by excluding their process identifiers or command patterns from the rule.
+- Configuration management tools like Ansible, Puppet, or Chef might alter the sudoers file as part of routine system updates or deployments. Users can handle these by identifying the specific processes or tools involved and excluding them from the detection criteria.
+- During system setup or maintenance, temporary changes to the sudoers file might be necessary and benign. Users should document these activities and adjust the detection rule to ignore changes made during scheduled maintenance windows.
+- Some software installations require modifications to the sudoers file to function correctly. Users can whitelist these specific installation processes by excluding their associated command patterns or process names from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Review the sudoers file for unauthorized modifications, specifically looking for entries with the NOPASSWD directive, and revert any changes to their original state.
+- Conduct a thorough investigation of system logs to identify any unauthorized access or command execution attempts, focusing on the timeframe of the detected modification.
+- Utilize MITRE ATT&CK framework details to understand the potential impact and methods used by the adversary, specifically focusing on T1548: Abuse Elevation Control Mechanism.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate with a security information and event management (SIEM) system to correlate events and detect similar threats across the network.
+- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are applied.
+- Conduct a security audit of user permissions and sudoers configurations to ensure adherence to the principle of least privilege.
+- Implement hardening measures such as multi-factor authentication for administrative access and regular reviews of privileged access configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
index d23c490865c..3f1ae9992d9 100644
--- a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
+++ b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SUID/SGID Bit Set
+
+The SUID/SGID bits in Unix-like systems allow files to execute with the privileges of the file's owner or group, rather than the executing user. Adversaries exploit this by setting these bits on files to gain elevated privileges, potentially executing malicious code with higher access rights. The detection rule identifies such abuses by monitoring processes that attempt to set these bits, excluding known legitimate paths and arguments.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args`.
+- Check the `process.parent.executable` field to determine the parent process and assess whether it is a known legitimate path or potentially malicious.
+- Investigate the user account associated with the process by examining the `user.name` field to determine if the account has a history of suspicious activity or if it is a privileged account.
+- Use Osquery to list all files with the SUID/SGID bit set on the system to identify any unexpected or unauthorized files. Example query: `SELECT path, mode FROM file WHERE mode & 4000 OR mode & 2000;`
+- Cross-reference the file paths identified in the alert with known system binaries and applications to determine if the SUID/SGID bit setting is expected or unusual.
+- Analyze the `event.type` and `event.action` fields to confirm the nature of the event and ensure it aligns with the expected behavior of the process.
+- Review system logs and audit logs around the time of the alert to gather additional context on the process execution and any related activities.
+- Investigate any network connections or external communications initiated by the process using network monitoring tools to identify potential data exfiltration or command-and-control activity.
+- Check for any recent changes or installations on the system that might explain the SUID/SGID bit setting, such as software updates or new application installations.
+- Consult threat intelligence sources to determine if the process or file path is associated with known malware or adversary techniques, leveraging the MITRE ATT&CK framework for context on potential privilege escalation tactics.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule when setting SUID/SGID bits as part of their normal operation. Users can handle these by adding exceptions for known software paths or processes, such as package managers or system update tools.
+- System maintenance scripts or administrative tasks that require elevated privileges might also set these bits temporarily. Users should review and potentially exclude these scripts if they are verified as safe and necessary for system operations.
+- Docker or container-related processes might set SUID/SGID bits within their environments, which can be non-threatening. Users can exclude paths related to Docker or container management to reduce false positives.
+- Some security tools or monitoring agents may use SUID/SGID bits to perform their functions. Users should verify these tools and exclude their processes or paths if they are confirmed to be legitimate and secure.
+- Custom scripts or applications developed in-house that require elevated privileges might also trigger the rule. Users should ensure these scripts are secure and then exclude them from monitoring to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes to file permissions and any unauthorized setuid/setgid bit modifications.
+- Review system logs and security alerts to trace the adversary's actions and identify any additional compromised accounts or systems.
+- Remove the setuid/setgid bits from unauthorized files and restore original permissions to prevent further privilege escalation.
+- Scan the system for malware and other indicators of compromise, removing any malicious files or processes discovered.
+- Reset passwords and review user accounts for unauthorized access, ensuring that only legitimate users have access to the system.
+- Escalate the incident to the security team or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring to detect future attempts to exploit setuid/setgid bits, including integrating with SIEM solutions for real-time alerting.
+- Apply system and application patches to address any vulnerabilities that may have been exploited by the adversary.
+- Review and update security policies and hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface and prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
index 0fa03093486..163002abfdb 100644
--- a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
+++ b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,51 @@ event.category:process and event.type:start and
   process.name:(sudo or sudoedit) and
   process.args:(*\\ and ("-i" or "-s"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Sudo Heap-Based Buffer Overflow Attempt
+
+Sudo is a critical utility in Unix-like systems, allowing users to execute commands with elevated privileges. A heap-based buffer overflow vulnerability (CVE-2021-3156) in Sudo can be exploited by attackers to gain root access. Adversaries may craft specific command arguments to trigger this overflow. The detection rule identifies suspicious Sudo or Sudoedit process starts with particular argument patterns, signaling potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious Sudo or Sudoedit process starts with arguments matching the pattern `*\\\\` and either `"-i"` or `"-s"`.
+- Examine the process execution context by checking the `event.category:process` and `event.type:start` fields to understand the timing and frequency of the suspicious activity.
+- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Analyze the command line arguments (`process.args`) used in the suspicious Sudo or Sudoedit process to identify any unusual or unexpected patterns.
+- Check the system logs for any other related activities around the same timestamp to identify potential lateral movement or further exploitation attempts.
+- Use Osquery to gather additional context about the system state and running processes. For example, run the following Osquery query to list recent Sudo command executions:
+  ```sql
+  SELECT * FROM sudo_log WHERE time > (SELECT MAX(time) - 3600 FROM sudo_log);
+  ```
+- Correlate the findings with any known indicators of compromise (IOCs) related to CVE-2021-3156 to assess the likelihood of a successful exploitation attempt.
+- Investigate any network connections initiated by the affected system around the time of the alert to identify potential data exfiltration or command-and-control communication.
+- Review historical data for similar patterns of Sudo or Sudoedit process starts to determine if this is an isolated incident or part of a broader attack campaign.
+- Document all findings and observations to support further analysis and potential escalation to the incident response team.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often use `sudo` or `sudoedit` with arguments like `-i` or `-s` for legitimate purposes, such as performing routine maintenance or executing scripts that require elevated privileges. These actions can trigger the detection rule, leading to false positives.
+- Automated scripts: Some automated scripts or cron jobs may use `sudo` with specific arguments to perform scheduled tasks. These scripts, if not properly documented or excluded, can cause repeated false positives.
+- Development and testing environments: In environments where developers or testers frequently use `sudo` to simulate production scenarios or test new configurations, the detection rule might flag these activities as suspicious.
+- To manage false positives, users can create exceptions for known benign processes by whitelisting specific command patterns or user accounts that are verified to perform legitimate actions. Additionally, monitoring and logging can be adjusted to focus on unusual patterns or deviations from normal behavior, reducing noise from expected activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Verify the alert by checking process logs and command history for suspicious Sudo or Sudoedit usage patterns that match the detection rule.
+- Conduct a thorough investigation to determine if the vulnerability was successfully exploited and assess the extent of any unauthorized access or changes.
+- If exploitation is confirmed, reset all potentially compromised credentials, especially those with elevated privileges.
+- Apply the latest security patches and updates to the Sudo utility to mitigate the CVE-2021-3156 vulnerability.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Enhance logging policies to capture detailed process execution data, including command-line arguments, to improve future detection capabilities.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to identify and respond to similar threats more effectively.
+- Restore the system to its operational state by verifying the integrity of critical system files and configurations, and ensure all security patches are applied.
+- Implement system hardening measures, such as restricting Sudo access to only necessary users and regularly reviewing user permissions, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
index b0d2ae7d57e..4fa584d7cb6 100644
--- a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
+++ b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,47 @@ event.category:file and event.type:change and file.path:(/etc/sudoers* or /priva
 not process.name:(dpkg or platform-python or puppet or yum or dnf) and 
 not process.executable:(/opt/chef/embedded/bin/ruby or /opt/puppetlabs/puppet/bin/ruby or /usr/bin/dockerd)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Sudoers File Modification
+The sudoers file is crucial in Unix-like systems, defining which users can execute commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is indeed `/etc/sudoers` or `/private/etc/sudoers*`, as specified in the query.
+- Check the `event.category` and `event.type` fields to ensure the event is categorized as a file change, confirming the nature of the alert.
+- Identify the `process.name` and `process.executable` fields to determine which process attempted to modify the sudoers file, ensuring it is not one of the excluded legitimate processes.
+- Investigate the user account associated with the process by examining the `user.name` field to determine if the account has a history of suspicious activity or if it is a known administrative account.
+- Use Osquery to list recent changes to the sudoers file with a query like: `SELECT * FROM file WHERE path = '/etc/sudoers' OR path LIKE '/private/etc/sudoers%' ORDER BY atime DESC LIMIT 5;` to gather more context on recent access times.
+- Cross-reference the timestamp of the alert with system logs to identify any concurrent suspicious activities or anomalies that might correlate with the sudoers file modification.
+- Examine the `host.name` or `host.ip` fields to determine if the alert originated from a critical or high-risk system within the network.
+- Review historical alerts or logs for similar sudoers file modification attempts to identify patterns or repeated unauthorized access attempts.
+- Check for any recent privilege escalation attempts or successful escalations on the system by reviewing related security logs or alerts.
+- Investigate any network connections or external communications initiated by the process that modified the sudoers file to identify potential data exfiltration or command-and-control activities.
+
+### False positive analysis
+
+- System updates or package installations may trigger changes to the sudoers file, especially when using package managers like dpkg, yum, or dnf, which are typically legitimate and non-threatening.
+- Configuration management tools such as Puppet or Chef might modify the sudoers file as part of their routine operations, which can be safely excluded if these tools are known to be in use.
+- Docker daemon processes might also interact with the sudoers file during container operations, which can be considered benign if Docker is part of the system's infrastructure.
+- To manage these false positives, users can create exceptions in the detection rule by excluding known legitimate processes and executables, such as those associated with system updates or configuration management tools, ensuring that only suspicious modifications are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Conduct a thorough investigation to identify the source of the modification, reviewing logs for any unauthorized access or changes to the sudoers file.
+- Verify the integrity of the sudoers file by comparing it with a known good backup and restore it if necessary.
+- Check for any unauthorized accounts or changes in user privileges and revert them to their original state.
+- Escalate the incident to the security team if the modification appears to be part of a broader attack or if multiple systems are affected.
+- Implement enhanced logging for sudoers file changes and monitor for any future unauthorized modifications.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate events and improve detection capabilities.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify the sudoers file.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Apply hardening measures such as using sudoers.d for granular control and regularly auditing user privileges to minimize the risk of privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/collection_cloudtrail_logging_created.toml b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
index f4c31b3d257..d6de2ccc1cb 100644
--- a/rules/integrations/aws/collection_cloudtrail_logging_created.toml
+++ b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS CloudTrail Log Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS CloudTrail Log Created
+
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs and monitors account activity across your AWS infrastructure. Adversaries may create new trails to capture sensitive data or cover their tracks. The detection rule identifies successful creation events of log trails, which could indicate unauthorized activity or configuration changes, helping analysts to quickly investigate potential security incidents.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `cloudtrail.amazonaws.com`, ensuring the alert is relevant to AWS CloudTrail activity.
+- Verify the event action is `CreateTrail` and the event outcome is `success` to confirm that a new log trail was successfully created.
+- Identify the AWS account and region where the trail was created to understand the scope and potential impact of the activity.
+- Check the IAM user or role associated with the `CreateTrail` action to determine if the activity was performed by an authorized entity.
+- Investigate the time and date of the trail creation to correlate with other suspicious activities or known incidents.
+- Use AWS CloudTrail logs to review recent activities by the identified IAM user or role to detect any other unauthorized or unusual actions.
+- Examine the configuration of the newly created trail, including the S3 bucket and SNS topic settings, to ensure they align with organizational policies and do not expose sensitive data.
+- Utilize Osquery to gather additional context on the AWS environment. For example, run the following Osquery query to list all CloudTrail trails and their configurations: `SELECT * FROM aws_cloudtrail_trails;`
+- Cross-reference the trail creation event with other security tools and logs, such as AWS Config or GuardDuty, to identify any related alerts or configuration changes.
+- Document findings and gather evidence, including logs and screenshots, to support further analysis and potential escalation if unauthorized activity is confirmed.
+
+### False positive analysis
+
+- Routine administrative actions: Regular maintenance or configuration changes by authorized personnel can trigger the AWS CloudTrail Log Created rule. These actions are typically non-threatening and can be excluded by creating exceptions for known administrative accounts or specific time windows when maintenance is scheduled.
+- Automated deployment tools: Organizations using automated tools for infrastructure deployment may frequently create and delete log trails as part of their processes. To manage these false positives, users can identify and exclude specific IAM roles or services associated with these tools.
+- Testing environments: In environments where AWS services are frequently tested, the creation of log trails might be a common occurrence. Users can handle these by excluding specific AWS accounts or regions dedicated to testing.
+- Third-party integrations: Some third-party security or monitoring tools may create log trails as part of their integration with AWS. Users should review and whitelist these tools to prevent unnecessary alerts.
+- Policy updates: Changes in organizational policies might require the creation of new log trails. Users can document and exclude these changes by correlating them with policy update records.
+
+### Response and remediation
+
+- Verify the legitimacy of the newly created AWS CloudTrail log by checking with the responsible team or individual to confirm if the action was authorized.
+- If unauthorized, immediately disable or delete the suspicious CloudTrail log to prevent further data collection or misuse.
+- Review AWS CloudTrail logs and other relevant logs to identify any unauthorized access or suspicious activities that may have occurred before or after the trail creation.
+- Conduct a thorough investigation to determine the scope of the incident, including identifying any compromised accounts or credentials.
+- Reset passwords and rotate access keys for any accounts that may have been compromised to prevent further unauthorized access.
+- Escalate the incident to the security operations team or incident response team for further analysis and to determine if additional actions are required.
+- Implement stricter IAM policies and multi-factor authentication to enhance account security and prevent unauthorized changes to CloudTrail configurations.
+- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
+- Review and update AWS logging policies to ensure all critical actions and changes are logged and monitored effectively.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as least privilege access and regular security training for staff.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
index e8cfdda99fe..36ab25906c9 100644
--- a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
+++ b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,51 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Management Console Brute Force of Root User Identity"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Management Console Brute Force of Root User Identity
+
+The AWS Management Console is a web-based interface for managing AWS resources. The root user has unrestricted access, making it a prime target for attackers. Adversaries may attempt brute force attacks to gain unauthorized access. The detection rule monitors failed login attempts by the root user, identifying potential brute force activity by analyzing specific event patterns in AWS CloudTrail logs.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the high number of failed login attempts by filtering for `event.dataset:aws.cloudtrail`, `event.provider:signin.amazonaws.com`, `event.action:ConsoleLogin`, `aws.cloudtrail.user_identity.type:Root`, and `event.outcome:failure`.
+- Analyze the timestamps of the failed login attempts to determine if they occurred in a short period, indicating a potential brute force attack.
+- Identify the source IP addresses associated with the failed login attempts to check for any patterns or anomalies, such as multiple attempts from a single IP or a range of IPs.
+- Cross-reference the source IP addresses with known malicious IP databases or threat intelligence feeds to assess if they are associated with previous malicious activities.
+- Investigate the geographical locations of the source IP addresses to determine if they are consistent with the expected locations of legitimate users.
+- Check for any successful login attempts by the root user around the same time as the failed attempts to assess if the brute force attack was successful.
+- Review the AWS CloudTrail logs for any unusual activities or changes made by the root user following the failed login attempts.
+- Use Osquery to gather additional context on the AWS environment. For example, run a query to list all recent login attempts: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'ConsoleLogin' AND userIdentity.type = 'Root';`
+- Examine the AWS account's security settings, such as multi-factor authentication (MFA) status for the root user, to evaluate the account's resilience against brute force attacks.
+- Collaborate with other security teams or stakeholders to gather additional context or insights regarding the alert and any related activities within the AWS environment.
+
+### False positive analysis
+
+- **Frequent failed logins by legitimate users:** Users may occasionally forget their passwords or mistype them, leading to multiple failed login attempts. To manage this, consider setting a threshold for the number of failed attempts within a specific time frame before triggering an alert.
+- **Automated scripts or tools:** Some organizations use automated scripts for testing or monitoring purposes that may inadvertently cause failed login attempts. Identify and whitelist these scripts or tools to prevent false positives.
+- **IP address changes:** Users accessing the AWS Management Console from different locations or through VPNs may trigger failed login attempts due to IP address changes. Implement IP whitelisting or geolocation checks to reduce false positives.
+- **Time zone differences:** Users in different time zones may log in at unusual hours, leading to suspicion of brute force attempts. Adjust alerting rules to account for legitimate access patterns based on user time zones.
+- **Password policy changes:** Recent changes in password policies may lead to an increase in failed login attempts as users adjust. Monitor for a temporary spike in failed logins following policy updates and adjust thresholds accordingly.
+
+### Response and remediation
+
+- Immediately disable the root user account to prevent further unauthorized access attempts.
+- Review AWS CloudTrail logs to identify the source IP addresses of the failed login attempts and block these IPs using AWS security groups or network ACLs.
+- Conduct a thorough investigation to determine if any successful logins occurred and assess any potential unauthorized changes or data access.
+- Reset the root account password and ensure it is strong and unique, following best practices for password security.
+- Enable multi-factor authentication (MFA) for the root user to add an additional layer of security.
+- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger threat campaign.
+- Implement AWS GuardDuty to enhance threat detection capabilities and receive alerts on suspicious activities.
+- Review and update IAM policies to ensure the principle of least privilege is enforced across all user accounts.
+- Conduct a security awareness training session for all users to reinforce the importance of secure password practices and recognizing phishing attempts.
+- Regularly audit and monitor AWS account activity using CloudTrail and other logging services to quickly identify and respond to future threats.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
diff --git a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
index c0cd38ab247..c1883ad5e71 100644
--- a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
+++ b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Configuration Recorder Stopped"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Configuration Recorder Stopped
+
+AWS Config is a service that tracks AWS resource configurations, enabling compliance auditing and security analysis. Adversaries may stop the configuration recorder to evade detection and impair defenses, aligning with MITRE ATT&CK's Defense Evasion tactics. The detection rule identifies successful attempts to halt this recording, signaling potential malicious activity by monitoring specific AWS CloudTrail events.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the user or role associated with the `StopConfigurationRecorder` event by examining the `userIdentity` field.
+- Check the `sourceIPAddress` field in the CloudTrail logs to determine the origin of the request and assess if it aligns with known IP addresses or locations.
+- Investigate the `eventTime` field to establish a timeline and correlate with other events or activities that occurred around the same time.
+- Analyze the `userAgent` field to understand the tool or method used to stop the configuration recorder, which may provide insights into whether it was a scripted or manual action.
+- Examine the AWS IAM policies and permissions associated with the user or role to determine if they have legitimate access to stop the configuration recorder.
+- Utilize Osquery to gather additional context on the AWS environment by running a query such as: `SELECT * FROM aws_config_recorders WHERE status = 'STOPPED';` to verify the current state of configuration recorders.
+- Cross-reference the `eventID` field with other CloudTrail events to identify any related or sequential actions that might indicate a broader attack pattern.
+- Review any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could have facilitated the stopping of the configuration recorder.
+- Investigate any alerts or logs from other security tools that might indicate concurrent suspicious activities or anomalies in the AWS environment.
+- Consult with relevant stakeholders or teams to verify if the action was authorized or part of a planned maintenance activity, ensuring alignment with organizational policies.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may trigger the AWS Configuration Recorder Stopped rule, as administrators might stop the recorder temporarily for configuration updates or troubleshooting.
+- Automated scripts or third-party tools used for AWS resource management might stop the configuration recorder as part of their normal operation, leading to false positives.
+- To manage these false positives, users can create exceptions for known administrative actions by excluding specific IAM roles or user accounts frequently involved in legitimate configuration changes.
+- Implement tagging or naming conventions for resources and actions that are part of regular maintenance, allowing for easier identification and exclusion from alerts.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the integrity of the detection rule.
+
+### Response and remediation
+
+- Immediately re-enable the AWS Configuration Recorder to ensure continuous monitoring of AWS resource configurations.
+- Conduct a thorough investigation to identify the IAM user or role responsible for stopping the configuration recorder and review their recent activities for any other suspicious actions.
+- Isolate the affected AWS account or resources if malicious activity is confirmed to prevent further unauthorized changes.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can stop the configuration recorder.
+- Implement AWS CloudTrail logging and enable AWS Config rules to monitor and alert on changes to critical configurations in real-time.
+- Escalate the incident to the security operations team for a detailed analysis and to determine if the incident is part of a larger attack pattern.
+- Restore any altered configurations to their last known good state using AWS Config's configuration history and snapshots.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Enhance security monitoring by integrating AWS Config with a Security Information and Event Management (SIEM) system for centralized alerting and analysis.
+- Educate and train staff on security best practices and the importance of maintaining AWS Config to prevent future incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
index fb2e47ad909..a83bf579818 100644
--- a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/26"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,52 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Network Access Control List Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 Network Access Control List Deletion
+
+Network Access Control Lists (ACLs) in AWS EC2 are essential for managing inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors successful deletion events of ACLs or their entries, signaling potential defense evasion attempts by identifying specific actions and outcomes in AWS CloudTrail logs.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail`, `event.provider:ec2.amazonaws.com`, `event.action:(DeleteNetworkAcl or DeleteNetworkAclEntry)`, and `event.outcome:success` fields to ensure the alert is valid.
+- Identify the IAM user or role associated with the deletion event by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by an authorized entity.
+- Check the `sourceIPAddress` field in the CloudTrail logs to identify the IP address from which the deletion request originated, and assess if it aligns with known and trusted IP addresses.
+- Investigate the `eventTime` field to establish a timeline of events and correlate it with other activities in the AWS environment to identify any suspicious patterns or anomalies.
+- Use Osquery to gather additional context about the affected EC2 instances and subnets. For example, run the following Osquery query to list all current network ACLs and their entries: `SELECT * FROM aws_ec2_network_acls;`.
+- Examine the AWS CloudTrail logs for any preceding or subsequent events related to the same IAM user or role to identify any other potentially malicious activities.
+- Review the AWS Config history for changes to the network ACLs and associated resources to understand the broader impact of the deletion event.
+- Analyze the `userAgent` field in the CloudTrail logs to determine the tool or service used to perform the deletion, which may provide insights into the method of access.
+- Check for any recent changes in IAM policies or roles that might have inadvertently granted excessive permissions, allowing unauthorized users to delete network ACLs.
+- Investigate any alerts or logs from other security tools or services that might indicate concurrent or related suspicious activities in the AWS environment.
+
+### False positive analysis
+
+- Routine maintenance or infrastructure changes by authorized personnel can trigger false positives when ACLs are intentionally deleted as part of network reconfiguration or updates. 
+- Automated scripts or tools used for infrastructure management might delete and recreate ACLs as part of their normal operation, leading to benign deletion events.
+- Scheduled decommissioning of resources, where ACLs are removed as part of the cleanup process, can also result in false positives.
+- To manage these false positives, users can create exceptions for known maintenance windows or specific IAM roles that are authorized to perform such actions.
+- Implementing tagging strategies for resources can help identify and exclude ACL deletions associated with legitimate operational activities.
+- Regularly reviewing and updating the list of trusted IP addresses and IAM roles involved in network management can help refine detection rules and reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration.
+- Review AWS CloudTrail logs to identify the source and user responsible for the deletion of the Network ACL.
+- Verify if the deletion was authorized by cross-referencing with change management records or contacting the responsible team.
+- Restore the deleted Network ACL or its entries from backups or recreate them based on documented configurations.
+- Implement AWS Identity and Access Management (IAM) policies to restrict permissions for deleting Network ACLs to only necessary personnel.
+- Enable AWS Config to continuously monitor and record configuration changes to Network ACLs for future audits.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
+- Conduct a root cause analysis to determine how the deletion was executed and identify any security gaps.
+- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other AWS resources.
+- Review and update the incident response plan to include specific procedures for handling Network ACL deletions and similar defense evasion tactics.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
index d39dcc0b035..e39d3700b0d 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS ElastiCache Security Group Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS ElastiCache Security Group Created
+
+AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential misuse aligned with defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `elasticache.amazonaws.com` to ensure the alert is relevant to ElastiCache security group creation.
+- Verify the event action is "Create Cache Security Group" and the event outcome is "success" to confirm the security group was successfully created.
+- Identify the AWS account and user or role that initiated the creation of the security group by examining the `user.identity.arn` and `aws.account.id` fields.
+- Check the time of the event to determine if the creation occurred during normal business hours or if it was an unusual time, which might indicate suspicious activity.
+- Investigate the IP addresses and locations associated with the request using the `source.ip` field to identify any anomalies or unexpected geolocations.
+- Review the CloudTrail logs for any preceding or subsequent actions by the same user or role to identify potential patterns of suspicious behavior.
+- Examine the configuration of the newly created security group, including any inbound or outbound rules, to assess if it allows overly permissive access.
+- Use Osquery to query the AWS environment for additional context on the security group. Example query: `SELECT * FROM aws_elasticache_security_groups WHERE name = '<security_group_name>';`
+- Cross-reference the security group creation with any recent changes in IAM policies or roles that might have granted new permissions to the user or role involved.
+- Consult with the relevant team or individual responsible for AWS ElastiCache management to verify if the security group creation was authorized and aligns with expected changes or deployments.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular maintenance or configuration changes by authorized personnel can trigger the creation of new ElastiCache security groups. These actions are typically non-threatening and can be verified by cross-referencing with change management logs or authorized user activity.
+- Automated deployment scripts: Organizations using infrastructure as code (IaC) tools like Terraform or AWS CloudFormation may automatically create security groups as part of their deployment processes. These should be reviewed and, if deemed non-threatening, can be excluded by identifying specific user agents or IAM roles associated with these tools.
+- Testing environments: Development or testing environments often mimic production setups, including the creation of security groups. These environments can be excluded by tagging resources appropriately and filtering alerts based on these tags.
+- Third-party integrations: Some third-party services or applications may require the creation of security groups for integration purposes. It's important to verify these integrations and, if legitimate, exclude them by identifying specific service accounts or API calls associated with these services.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to identify the source and context of the ElastiCache security group creation event.
+- Verify the identity and access management (IAM) permissions of the user or role that created the security group to ensure it aligns with expected behavior.
+- Temporarily revoke or restrict permissions for the identified user or role to prevent further unauthorized actions.
+- Assess the configuration of the newly created security group to determine if it allows overly permissive access and adjust the rules to align with the principle of least privilege.
+- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration has occurred using the new security group.
+- Escalate the incident to the security operations center (SOC) or incident response team if malicious intent is suspected, providing them with all relevant logs and findings.
+- Implement enhanced logging and monitoring for ElastiCache and related AWS services to detect similar activities in the future.
+- Integrate AWS CloudTrail with a security information and event management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Restore any affected systems or data to their last known good state if unauthorized changes or access were detected.
+- Review and update security group policies and IAM roles to harden the environment against similar threats, ensuring alignment with best practices and compliance requirements.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
index a496a341a8c..0dc82db5441 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS ElastiCache Security Group Modified or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS ElastiCache Security Group Modified or Deleted
+
+AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, identifying successful modifications or deletions that could indicate potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific event.action that triggered the alert, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress."
+- Examine the event.outcome field to confirm the success of the action, ensuring that the modification or deletion was indeed successful.
+- Check the event.dataset and event.provider fields to verify that the event originated from AWS CloudTrail and is related to ElastiCache, confirming the context of the alert.
+- Investigate the user identity associated with the event by reviewing the user identity fields in the CloudTrail logs to determine if the action was performed by an authorized user or an unexpected account.
+- Analyze the event time to correlate the action with other activities in the environment, identifying any unusual patterns or sequences of events.
+- Use Osquery to gather additional context on the AWS environment. For example, run a query to list recent changes to ElastiCache security groups: `SELECT * FROM aws_cloudtrail_events WHERE eventSource='elasticache.amazonaws.com' AND (eventName='DeleteCacheSecurityGroup' OR eventName='AuthorizeCacheSecurityGroupIngress' OR eventName='RevokeCacheSecurityGroupIngress') AND eventTime > date('now', '-1 day');`
+- Review the IP addresses and locations associated with the event to identify any anomalies or unexpected access patterns.
+- Investigate any related alerts or logs from other AWS services or security tools that might provide additional context or indicate a broader security incident.
+- Check for any recent changes in IAM policies or roles that might have inadvertently allowed unauthorized access to modify ElastiCache security groups.
+- Document all findings and observations to build a comprehensive understanding of the event, which will aid in determining the legitimacy of the action and any potential security implications.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel can trigger alerts when they modify or delete ElastiCache security groups as part of their regular duties. To manage these, users can create exceptions for specific IAM roles or users known to perform these tasks regularly.
+- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Users should identify these scripts and exclude their actions from triggering alerts by using tags or specific identifiers.
+- Changes made during scheduled updates or deployments can also result in false positives. Users can mitigate these by setting up maintenance windows and excluding activities within these time frames from alerting.
+- Testing environments often undergo frequent changes, including security group modifications. Users can exclude specific environments or accounts dedicated to testing from the detection rule to reduce noise.
+- Integration with third-party services that require security group modifications might lead to false positives. Users should document these integrations and create exceptions for known service accounts or API calls associated with these services.
+
+### Response and remediation
+
+- Immediately isolate the affected ElastiCache instance by modifying the security group to restrict all inbound and outbound traffic.
+- Review CloudTrail logs to identify unauthorized API calls related to the security group changes and determine the source and identity of the actor.
+- Conduct a thorough investigation to assess the extent of unauthorized access or data exfiltration, focusing on the time window around the detected changes.
+- Revert any unauthorized modifications to the security group by restoring it to its previous state using backups or documented configurations.
+- Escalate the incident to the security operations team and notify relevant stakeholders, including data owners and compliance officers, if sensitive data is involved.
+- Implement additional monitoring and alerting for changes to ElastiCache security groups to detect similar activities in the future.
+- Enhance logging policies to ensure comprehensive coverage of all security group modifications and deletions, including detailed user activity logs.
+- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities related to ElastiCache.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can modify security groups.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as multi-factor authentication and regular security audits.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html"]
diff --git a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
index d0f4ad05d7d..09422ea01e8 100644
--- a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS GuardDuty Detector Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS GuardDuty Detector Deletion
+
+AWS GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior. Deleting a GuardDuty detector halts this monitoring, potentially concealing malicious actions. Adversaries may exploit this by deleting detectors to evade detection. The detection rule identifies successful deletion events, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail`, the event provider is `guardduty.amazonaws.com`, and the event action is `DeleteDetector` with an outcome of `success`.
+- Identify the AWS account and region where the detector deletion occurred to understand the scope of the potential impact.
+- Check the CloudTrail logs for the user identity or role that performed the `DeleteDetector` action to determine if it was an authorized user or a potential compromise.
+- Investigate the timing of the deletion event to see if it coincides with any other suspicious activities or alerts in the environment.
+- Examine the IAM policies and permissions associated with the user or role to assess if they have legitimate access to delete GuardDuty detectors.
+- Use Osquery to query the AWS environment for any recent changes in IAM roles or policies that might have allowed unauthorized access. Example query: `SELECT * FROM aws_iam_roles WHERE role_name = 'SuspiciousRole';`
+- Review any recent GuardDuty findings prior to the deletion to identify potential threats that might have prompted the deletion.
+- Analyze network traffic and logs around the time of the deletion for any unusual patterns or connections that could indicate malicious activity.
+- Cross-reference the deletion event with other security tools and logs to gather additional context and corroborate findings.
+- Document all findings and observations to build a comprehensive timeline and context for the deletion event, aiding in further analysis and potential escalation.
+
+### False positive analysis
+
+- Routine maintenance or administrative actions by authorized personnel can trigger false positives when a GuardDuty detector is intentionally deleted for legitimate reasons, such as reconfiguring the service or migrating to a different AWS account.
+- Automated scripts or cloud management tools that manage AWS resources might delete detectors as part of their normal operation, leading to false positives if these actions are not properly documented or communicated.
+- To manage these false positives, users can create exceptions for known and documented maintenance windows or authorized personnel actions by using tags or specific IAM roles associated with legitimate detector deletions.
+- Implementing a review process for detector deletion events can help distinguish between legitimate administrative actions and potential malicious activities, reducing the likelihood of false positives impacting security operations.
+
+### Response and remediation
+
+- Immediately verify the deletion event by cross-referencing with CloudTrail logs to confirm the identity and location of the user or service account responsible for the action.
+- Contain the potential threat by temporarily revoking access for the identified user or service account and reviewing their recent activity for any other suspicious actions.
+- Initiate a comprehensive investigation to determine if the deletion was authorized and assess the potential impact on the environment, including any missed detections during the downtime.
+- Restore the GuardDuty detector by re-enabling it and ensuring that all configurations are correctly set to resume monitoring and threat detection.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can delete or modify GuardDuty detectors.
+- Implement enhanced logging and monitoring policies to capture detailed audit trails of all security-related actions, including detector deletions.
+- Integrate GuardDuty with a Security Information and Event Management (SIEM) system to centralize alerts and facilitate real-time monitoring and response.
+- Escalate the incident to the security operations team if unauthorized activity is confirmed, and consider involving legal or compliance teams if sensitive data may have been compromised.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply hardening measures by enabling multi-factor authentication (MFA) for all accounts with permissions to modify security settings and regularly review and update security configurations.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
index 4a584d3a37c..9d68311c766 100644
--- a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
+++ b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/06/20"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer", "Elastic"]
@@ -46,6 +46,50 @@ any where event.dataset == "aws.cloudtrail"
     and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3") 
     and event.outcome == "success"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS DB Instance Restored
+
+Amazon RDS (Relational Database Service) allows users to set up, operate, and scale databases in the cloud. Adversaries may exploit this by restoring databases from snapshots or S3 to access sensitive data or bypass security controls. The detection rule identifies successful restoration attempts, flagging potential unauthorized activities by monitoring specific API calls and outcomes, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is "aws.cloudtrail" and the event provider is "rds.amazonaws.com" to ensure the alert is relevant to AWS RDS activities.
+- Verify the event action is either "RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3" and the event outcome is "success" to confirm the restoration activity was completed successfully.
+- Identify the user or role associated with the API call by examining the user identity fields in the event data to determine if the credentials used were legitimate or potentially compromised.
+- Check the source IP address and user agent string in the event data to identify any unusual access patterns or locations that could indicate unauthorized access.
+- Investigate the timing of the restoration event to see if it coincides with any other suspicious activities or alerts in the environment.
+- Review CloudTrail logs for any preceding or subsequent API calls made by the same user or role to identify any additional suspicious activities or patterns.
+- Examine the specific DB instance details, such as the DB instance identifier and snapshot or S3 bucket used, to understand what data may have been accessed or restored.
+- Use Osquery to further investigate the AWS environment. For example, run the following Osquery query to list recent RDS restoration activities: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('RestoreDBInstanceFromDBSnapshot', 'RestoreDBInstanceFromS3') AND eventSource = 'rds.amazonaws.com' AND responseElements IS NOT NULL;`
+- Cross-reference the restored DB instance details with known business operations or maintenance activities to determine if the restoration was authorized or expected.
+- Collaborate with the database administration team to verify if the restoration aligns with any scheduled tasks or if it was an unexpected event requiring further investigation.
+
+### False positive analysis
+
+- Routine database maintenance or recovery operations by authorized personnel can trigger this rule, leading to false positives. These activities might include regular backups or disaster recovery tests.
+- Development or testing environments often involve frequent restoration of databases from snapshots or S3 for testing purposes, which can be mistaken for unauthorized activities.
+- Automated processes or scripts that restore databases as part of their workflow can also generate alerts. These should be reviewed and, if deemed non-threatening, excluded from triggering the rule.
+- To manage these false positives, users can create exceptions for known IP addresses or IAM roles associated with legitimate restoration activities.
+- Implement tagging or naming conventions for databases restored as part of regular operations, allowing for easy identification and exclusion from alerts.
+- Regularly review and update the list of exceptions to ensure that only non-threatening activities are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected RDS instance to prevent further unauthorized access or data exfiltration.
+- Review CloudTrail logs to identify the source of the compromised credentials and assess the scope of the incident.
+- Revoke any compromised credentials and rotate keys or passwords associated with the affected AWS account.
+- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated during the unauthorized restoration.
+- Escalate the incident to the security operations team and notify relevant stakeholders, including data protection officers if sensitive data is involved.
+- Implement additional logging and monitoring for RDS activities, ensuring that all API calls related to database restoration are captured and reviewed.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance real-time threat detection and response capabilities.
+- Restore the RDS instance to its last known good state using backups or snapshots, ensuring data integrity and availability.
+- Apply security hardening measures such as enabling multi-factor authentication (MFA), enforcing least privilege access, and regularly reviewing IAM policies.
+- Educate users on security best practices and conduct regular security awareness training to prevent credential compromise in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
index ceb62849c0d..58226f3abab 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Configuration Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS S3 Bucket Configuration Deletion
+
+Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. Adversaries may delete these configurations to evade defenses, remove traces, or disrupt operations. The detection rule monitors successful deletions of these configurations, signaling potential malicious activity by correlating specific actions and outcomes in AWS CloudTrail logs.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle` actions.
+- Check the `event.outcome` field to confirm the success of the deletion actions and correlate with the time of the alert.
+- Investigate the `event.provider` field to ensure the actions were performed on `s3.amazonaws.com`, confirming the target service.
+- Analyze the `event.dataset` field to verify the logs are from `aws.cloudtrail`, ensuring the source of the data is accurate.
+- Examine the IP address and location from which the actions were initiated to identify any anomalies or unauthorized access patterns.
+- Review the IAM policies and permissions of the user or role involved to determine if they had legitimate access to perform the deletions.
+- Cross-reference the actions with recent changes in the AWS environment to identify if these deletions were part of a planned change or an unexpected event.
+- Utilize Osquery to gather additional context on the AWS environment. For example, run an Osquery query to list recent S3 bucket configuration changes: `SELECT * FROM aws_s3_bucket WHERE action IN ('DeleteBucketPolicy', 'DeleteBucketReplication', 'DeleteBucketCors', 'DeleteBucketEncryption', 'DeleteBucketLifecycle') AND outcome = 'success';`
+- Check for any other suspicious activities in the AWS account around the same timeframe, such as unusual login attempts or changes to other critical resources.
+- Consult with the team responsible for AWS operations to verify if the deletions were authorized and documented as part of routine maintenance or updates.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular maintenance or updates by authorized personnel may involve deleting and reconfiguring S3 bucket settings, which can trigger this rule. To manage this, users can create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or tools: Some organizations use automated processes to manage S3 configurations, which might include deleting and recreating configurations as part of their workflow. Users should identify these scripts and exclude their activity from triggering alerts by whitelisting specific IAM roles or user accounts associated with these processes.
+- Third-party integrations: Certain third-party services or applications may require temporary deletion of S3 configurations to function correctly. Users should review and document these integrations, then adjust the detection rule to exclude actions performed by these trusted services.
+- Testing environments: In development or testing environments, frequent changes to S3 configurations, including deletions, are common. Users can exclude these environments from the rule by filtering out specific AWS accounts or tags associated with non-production resources.
+
+### Response and remediation
+
+- Immediately isolate the affected S3 bucket to prevent further unauthorized changes or data loss.
+- Review AWS CloudTrail logs to identify the source and user responsible for the configuration deletion, correlating with other suspicious activities.
+- Restore the deleted configurations from backups or previous versions to ensure the bucket's security and compliance settings are reinstated.
+- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the period of misconfiguration.
+- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack pattern.
+- Implement additional logging and monitoring for S3 buckets to detect future unauthorized configuration changes promptly.
+- Review and update IAM policies to ensure that only authorized users have permissions to modify S3 bucket configurations.
+- Integrate AWS GuardDuty and other threat detection services to enhance visibility and automated alerting for suspicious activities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate and train staff on security best practices and the importance of maintaining secure configurations to prevent similar incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
index 5d042038e21..140c2ac28f1 100644
--- a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
+++ b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/08/19"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,49 @@ event.dataset: "aws.cloudtrail"
     and event.provider: sts.amazonaws.com
     and event.action: GetFederationToken
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of STS GetFederationToken Request by User
+
+AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user within a 10-day window, helping to uncover potential misuse.
+
+### Possible investigation steps
+
+- Review the `event.dataset` field to confirm the event source is "aws.cloudtrail" and ensure the event is related to AWS CloudTrail logs.
+- Verify the `event.provider` field to ensure the event is associated with "sts.amazonaws.com", confirming it involves the AWS Security Token Service.
+- Check the `event.action` field to confirm the action is "GetFederationToken", indicating a request for temporary credentials.
+- Identify the user who initiated the `GetFederationToken` request by examining the `user.identity.arn` or `user.identity.userName` fields to determine if the user is legitimate and authorized.
+- Investigate the `sourceIPAddress` field to determine the origin of the request and assess if the IP address is expected or unusual for the user.
+- Analyze the `userAgent` field to understand the context of the request, such as the application or service used, and determine if it aligns with typical user behavior.
+- Review the `event.time` field to establish the timing of the request and correlate it with other activities or events that may indicate suspicious behavior.
+- Examine the `requestParameters` field to understand the specifics of the `GetFederationToken` request, such as the duration and permissions requested, to assess if they are appropriate.
+- Utilize Osquery to gather additional context on the user's activity on the host. For example, run the following Osquery query to list recent AWS CLI commands executed by the user: `SELECT * FROM shell_history WHERE command LIKE '%aws%' AND user = '<username>';`
+- Cross-reference the `GetFederationToken` request with other logs and alerts to identify any patterns or anomalies that could indicate a broader security incident.
+
+### False positive analysis
+
+- **Routine Administrative Tasks**: Regular administrative operations may involve the use of `GetFederationToken` for legitimate purposes, such as accessing AWS resources for maintenance or monitoring. Users can manage these by creating exceptions for known administrative accounts or roles that frequently perform these tasks.
+- **Automated Scripts and Tools**: Automated processes or third-party tools that integrate with AWS services might use `GetFederationToken` to function correctly. To handle these, identify and whitelist the specific scripts or tools that are known to use this API call regularly.
+- **New Service Integrations**: When integrating new services or applications with AWS, initial `GetFederationToken` requests might be flagged. Users should document and exclude these occurrences by updating the detection rule to recognize these integrations as non-threatening.
+- **User Onboarding**: During the onboarding of new users or roles, initial `GetFederationToken` requests may be expected. To prevent false positives, establish a process to temporarily exclude these users or roles from the detection rule during their onboarding period.
+- **Testing and Development Environments**: In testing or development environments, `GetFederationToken` requests might be used frequently for testing purposes. Users can manage these by setting up separate monitoring rules or exclusions for these environments to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials obtained through the GetFederationToken request to prevent unauthorized access to AWS resources.
+- Investigate the user account that made the GetFederationToken request to determine if the activity was legitimate or indicative of compromise.
+- Review CloudTrail logs for any other unusual or unauthorized activities associated with the user account or related AWS resources.
+- If compromise is suspected, reset the credentials for the affected user account and any other accounts that may have been accessed using the temporary credentials.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or resources are affected.
+- Implement enhanced logging and monitoring for AWS STS activities, focusing on GetFederationToken requests, to detect similar activities in the future.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Educate users on the risks associated with the misuse of AWS STS and the importance of reporting suspicious activities.
+- Review and update AWS IAM policies to ensure that only authorized users have the necessary permissions to request temporary credentials.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as multi-factor authentication and least privilege access controls, to prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
index 33ddcf3751a..9a54de6c9d9 100644
--- a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS WAF Access Control List Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS WAF Access Control List Deletion
+
+AWS WAF protects web applications by filtering and monitoring HTTP requests. Access Control Lists (ACLs) define rules to block or allow traffic. Adversaries may delete ACLs to disable protections, facilitating attacks. The detection rule monitors successful deletion events in AWS CloudTrail, signaling potential defense evasion attempts by identifying unauthorized or suspicious ACL deletions.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the `event.action:DeleteWebACL` and `event.outcome:success` to ensure the alert is valid and not a false positive.
+- Identify the `user.identity.arn` field in the CloudTrail logs to determine which IAM user or role initiated the deletion of the WAF ACL.
+- Check the `sourceIPAddress` field to identify the IP address from which the deletion request was made, and verify if it aligns with known or expected IP addresses for your organization.
+- Investigate the `userAgent` field to understand the application or service used to perform the deletion, which might provide additional context about the source of the request.
+- Examine the `eventTime` field to establish a timeline of events and correlate it with other activities in the AWS environment around the same time.
+- Use Osquery to query AWS API logs for any other suspicious activities around the same time. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'DeleteWebACL' AND eventTime BETWEEN 'start_time' AND 'end_time';`
+- Cross-reference the IAM user or role identified with recent IAM activity logs to check for any unusual permission changes or access patterns.
+- Investigate any recent changes to IAM policies or roles that might have inadvertently allowed unauthorized users to delete WAF ACLs.
+- Review the AWS WAF configuration history to determine if there were any recent changes to the ACLs that could have been a precursor to the deletion.
+- Check for any other security alerts or incidents in the AWS environment that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may trigger the AWS WAF Access Control List Deletion rule, especially if performed by authorized personnel. These actions are typically non-threatening and can be considered false positives.
+- Automated scripts or tools used for infrastructure management might delete and recreate ACLs as part of their normal operation, leading to false positives. Users should identify these scripts and consider excluding their activity from alerts.
+- Changes in security policies or compliance requirements might necessitate the deletion of certain ACLs, which could be misinterpreted as suspicious activity. Users should document these changes and adjust the detection rule to account for them.
+- To manage false positives, users can create exceptions for specific IAM roles or users known to perform legitimate ACL deletions regularly. This can be done by adding conditions to the detection rule to exclude these entities.
+- Implementing a review process for deletion events can help differentiate between legitimate and suspicious activities, allowing for more accurate threat detection while minimizing false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account to prevent further unauthorized actions and assess the scope of the incident.
+- Review AWS CloudTrail logs to identify the source and user responsible for the deletion of the WAF ACL, focusing on any anomalies or unauthorized access patterns.
+- Verify the integrity of other security configurations and access controls within the AWS environment to ensure no additional tampering has occurred.
+- Restore the deleted WAF ACL from backups or recreate it using predefined templates to re-establish web application protections.
+- Implement multi-factor authentication (MFA) for all AWS accounts to enhance security and prevent unauthorized access.
+- Conduct a thorough review of IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized actions.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were compromised.
+- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and analysis.
+- Develop and implement a comprehensive incident response plan that includes regular drills and updates based on lessons learned from the incident.
+- Educate and train staff on security best practices and the importance of maintaining robust access controls to prevent future incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
index 1206af84945..4f99551a51e 100644
--- a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/09"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,52 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS WAF Rule or Rule Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS WAF Rule or Rule Group Deletion
+
+AWS Web Application Firewall (WAF) protects web applications by filtering and monitoring HTTP requests. Adversaries may delete WAF rules or groups to disable security measures, facilitating attacks like data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion actions, identifying potential defense evasion attempts by tracking specific API calls related to rule deletions.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to confirm the deletion event by filtering for `event.dataset:aws.cloudtrail` and `event.action:(DeleteRule or DeleteRuleGroup)` to ensure the alert is not a false positive.
+- Identify the `event.provider` field to determine which AWS WAF service (waf.amazonaws.com, waf-regional.amazonaws.com, or wafv2.amazonaws.com) was involved in the deletion.
+- Examine the `userIdentity` field in the CloudTrail logs to identify the IAM user or role that performed the deletion action.
+- Check the `sourceIPAddress` field to determine the IP address from which the deletion request originated, which can help identify if the action was performed from an unusual location.
+- Investigate the `eventTime` field to establish a timeline of events and correlate with other activities in the AWS environment around the same time.
+- Use the `requestParameters` field to identify which specific WAF rule or rule group was deleted, providing context on what protections were removed.
+- Cross-reference the `userAgent` field to understand the tool or service used to perform the deletion, which might indicate if it was done through the AWS Management Console, CLI, or another method.
+- Utilize Osquery to gather additional context on the AWS environment by running a query such as: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('DeleteRule', 'DeleteRuleGroup') AND eventSource IN ('waf.amazonaws.com', 'waf-regional.amazonaws.com', 'wafv2.amazonaws.com') AND outcome = 'success';`
+- Review IAM policies and permissions associated with the identified user or role to determine if they have legitimate access to delete WAF rules or groups.
+- Investigate any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions, potentially leading to unauthorized deletions.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger false positives when legitimate changes are made to AWS WAF rules or rule groups. 
+- Automated scripts or tools used for infrastructure management might delete and recreate rules as part of their normal operation, leading to false positives.
+- Scheduled policy updates or deployments that involve rule deletions can also be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for known maintenance windows or specific IAM roles that are authorized to perform such actions.
+- Implementing tagging or naming conventions for rules and rule groups can help in identifying legitimate deletions and excluding them from alerts.
+- Regularly review and update the list of trusted IP addresses or user agents that are allowed to perform these actions to minimize unnecessary alerts.
+
+### Response and remediation
+
+- Immediately review AWS CloudTrail logs to confirm the deletion of the WAF rule or rule group and identify the user or service account responsible for the action.
+- Contain the potential threat by temporarily revoking access for the identified user or service account and reviewing their recent activity for any other suspicious actions.
+- Investigate the context of the deletion by checking for any related alerts or anomalies in network traffic or application logs that might indicate an ongoing attack.
+- Restore the deleted WAF rule or rule group from backups or recreate them based on documented configurations to ensure continued protection of web applications.
+- Escalate the incident to the security operations team if the deletion appears to be part of a larger attack or if unauthorized access is suspected.
+- Implement stricter access controls and multi-factor authentication for accounts with permissions to modify WAF configurations to prevent unauthorized changes.
+- Enhance logging and monitoring by ensuring that all AWS WAF-related actions are logged in CloudTrail and integrated with a Security Information and Event Management (SIEM) system for real-time analysis.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future.
+- Educate relevant personnel on the importance of WAF configurations and the potential impact of unauthorized deletions to raise awareness and prevent recurrence.
+- Consider implementing additional AWS security services, such as AWS Config, to continuously monitor and enforce compliance with security policies related to WAF configurations.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
index e0fa48aacb1..2a30806c376 100644
--- a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
+++ b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/08/26"
 maturity = "production"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,50 @@ from logs-aws.cloudtrail-*
 // sort the results by time windows in descending order
 | sort target_time_window desc
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Service Quotas Multi-Region `GetServiceQuota` Requests
+
+AWS Service Quotas manage resource limits, crucial for maintaining cloud efficiency. Adversaries exploit `GetServiceQuota` API calls to probe EC2 limits, potentially using compromised credentials to map infrastructure across regions. The detection rule identifies unusual multi-region queries within a short timeframe, signaling possible reconnaissance activities by counting distinct regions and API calls, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific `aws.cloudtrail.user_identity.arn` involved in the suspicious activity, as this will help identify the potentially compromised user or service account.
+- Examine the `target_time_window` to determine the exact 30-second period during which the unusual activity occurred, providing a precise timeframe for further investigation.
+- Analyze the `cloud.region` field to identify all regions where the `GetServiceQuota` API calls were made, which can help in understanding the scope of the potential reconnaissance.
+- Check the `window_count` to assess the total number of API calls made within the 30-second window, which can indicate the intensity of the activity.
+- Investigate the `aws.cloudtrail.user_identity.arn` in the AWS IAM console to verify the permissions and recent activity of the user or service account, looking for any anomalies or unauthorized changes.
+- Use AWS CloudTrail logs to trace back the source IP addresses associated with the `GetServiceQuota` API calls, which can help identify the origin of the requests.
+- Cross-reference the `aws.cloudtrail.user_identity.arn` with other recent CloudTrail logs to detect any other suspicious activities or patterns involving the same user or service account.
+- Utilize Osquery to gather additional context on the involved AWS resources. For example, run an Osquery query to list recent AWS API calls made by the same user or service account: `SELECT * FROM aws_cloudtrail_events WHERE user_identity_arn = '<aws.cloudtrail.user_identity.arn>' AND event_time BETWEEN '<start_time>' AND '<end_time>';`.
+- Investigate any recent changes to the AWS environment, such as new instance launches or configuration changes, that coincide with the timeframe of the alert, as these could be related to the suspicious activity.
+- Collaborate with the security team to correlate this alert with other security events or alerts, which may provide a broader context of a potential attack campaign or ongoing threat.
+
+### False positive analysis
+
+- Automated scripts or tools used by legitimate AWS administrators for infrastructure monitoring or management across multiple regions can trigger this rule. These tools might perform `GetServiceQuota` API calls as part of their routine checks.
+- Multi-region deployments by large organizations that frequently check service quotas to ensure compliance with internal policies or to optimize resource allocation can also result in false positives.
+- Scheduled tasks or cron jobs that run at specific intervals to gather quota information for reporting or auditing purposes might inadvertently match the rule's criteria.
+- To manage these false positives, users can create exceptions for known benign sources by excluding specific AWS Identity and Access Management (IAM) roles or user ARNs that are responsible for legitimate multi-region queries.
+- Implementing a whitelist of IP addresses or regions associated with trusted operations can help reduce noise from expected activities.
+- Regularly reviewing and updating the list of exceptions based on changes in organizational processes or infrastructure can help maintain the accuracy of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account or instance to prevent further unauthorized access and limit potential damage.
+- Review CloudTrail logs to identify the source of the `GetServiceQuota` requests and determine if any other suspicious activities are associated with the same credentials or instance.
+- Revoke any compromised credentials and rotate access keys for the affected AWS account to prevent further unauthorized access.
+- Conduct a thorough investigation to determine if any malware or unauthorized software has been deployed on the affected instances, and remove any malicious components found.
+- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging and monitoring policies to capture detailed API activity, focusing on unusual patterns or access from unexpected regions.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Review and update AWS IAM policies to enforce the principle of least privilege, ensuring that users and services have only the permissions necessary for their roles.
+- Restore affected systems to their operational state by redeploying clean instances from known-good backups or images, ensuring that all security patches are applied.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as enabling multi-factor authentication (MFA) and using AWS Config to enforce compliance with security best practices."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
index 6dcc33f9728..d2445998710 100644
--- a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
+++ b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,48 @@ query = '''
 event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and
     event.action: (CreateStack or CreateStackSet) and event.outcome:success
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Time AWS Cloudformation Stack Creation by User
+
+AWS CloudFormation automates the setup of cloud resources using templates, streamlining infrastructure management. Adversaries with access can exploit this to deploy malicious resources, escalating their control. The detection rule identifies unusual activity by flagging the initial use of stack creation APIs by a user, helping to spot potential unauthorized actions early.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific IAM user or role that triggered the alert by calling the `CreateStack` or `CreateStackSet` API.
+- Check the AWS CloudTrail logs for additional context around the event, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:cloudformation.amazonaws.com` fields to confirm the legitimacy of the action.
+- Investigate the `event.outcome:success` field to ensure the stack creation was successful and determine if any errors or anomalies were logged during the process.
+- Analyze the IAM policies and permissions associated with the user or role to verify if they have the necessary privileges to perform stack creation and assess if these permissions are excessive.
+- Examine the stack template used in the `CreateStack` or `CreateStackSet` action to identify the resources being provisioned and assess if they align with expected or authorized configurations.
+- Cross-reference the timing of the stack creation event with other logs and alerts to identify any correlated suspicious activities, such as unusual login attempts or privilege escalations.
+- Utilize Osquery to gather additional system-level information. For example, run an Osquery query to list recent AWS API calls made by the user: `SELECT * FROM aws_cloudtrail_events WHERE user_identity_arn = '<user_arn>' AND event_name IN ('CreateStack', 'CreateStackSet') ORDER BY event_time DESC LIMIT 10;`.
+- Investigate the geographical location and IP address from which the API call was made to determine if it aligns with known user activity patterns.
+- Review any recent changes to the AWS environment, such as modifications to security groups or network configurations, that could be related to the stack creation.
+- Consult with the user or team responsible for the account to verify if the stack creation was an expected action and gather any additional context or documentation related to the event.
+
+### False positive analysis
+
+- New legitimate projects or services: When a new project or service is initiated, legitimate users may create CloudFormation stacks for the first time, triggering the rule. To manage this, users can create exceptions for known projects or services by tagging these activities and excluding them from the rule.
+- Onboarding of new team members: New team members with appropriate permissions may trigger the rule when they first use CloudFormation. To handle this, maintain a list of new users and temporarily exclude their activities from the rule until their behavior is established as non-threatening.
+- Automated deployment tools: Some automated tools or scripts may use CloudFormation to deploy resources, appearing as a first-time use by a user. Users can identify these tools and exclude their activities by recognizing specific patterns or tags associated with the tool.
+- Testing and development environments: Activities in testing or development environments may trigger the rule. Users can exclude these environments by filtering based on environment-specific tags or account IDs to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account to prevent further unauthorized access or resource creation.
+- Review CloudTrail logs to identify the source and scope of the unauthorized stack creation, focusing on the user or role involved.
+- Revoke or adjust IAM permissions for the user or role that initiated the stack creation to prevent further misuse.
+- Investigate the created resources for any malicious configurations or data exfiltration mechanisms and remove them if necessary.
+- Escalate the incident to the security operations team for a deeper investigation and to assess potential impacts on other systems.
+- Implement enhanced logging and monitoring for AWS CloudFormation and related services to detect similar activities in the future.
+- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities.
+- Conduct a post-incident review to identify gaps in security controls and update IAM policies to enforce the principle of least privilege.
+- Restore any affected systems or data from backups, ensuring that the restored state is free from unauthorized changes.
+- Educate users and administrators on secure AWS practices and the importance of monitoring for unusual activities, leveraging MITRE ATT&CK framework insights for threat awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
index e809fcaf22f..07b73c9da4d 100644
--- a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
+++ b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -24,7 +24,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Full Network Packet Capture Detected"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 Full Network Packet Capture Detected
+
+Traffic Mirroring in AWS EC2 allows the duplication of network traffic from an Elastic Network Interface for monitoring and analysis. While beneficial for diagnostics, adversaries can exploit this to siphon off unencrypted data. The detection rule identifies successful creation events of traffic mirroring components, signaling potential misuse for data exfiltration.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the user or role associated with the creation of traffic mirroring components by examining the `user.identity.arn` field.
+- Check the `sourceIPAddress` field in the CloudTrail logs to determine the origin of the request, which can help identify if the request was made from an unusual or unauthorized location.
+- Analyze the `event.time` field to establish a timeline of when the traffic mirroring components were created, which can help correlate with other suspicious activities.
+- Investigate the `eventName` field to confirm which specific traffic mirroring component was created (e.g., `CreateTrafficMirrorFilter`, `CreateTrafficMirrorFilterRule`, `CreateTrafficMirrorSession`, or `CreateTrafficMirrorTarget`).
+- Use Osquery to query the AWS EC2 instance metadata and configuration for any unusual changes or configurations. Example query: `SELECT * FROM ec2_instance_metadata WHERE key = 'instance-id';`
+- Examine the `event.outcome` field to ensure the creation event was successful, confirming that the traffic mirroring components are active.
+- Cross-reference the `awsRegion` field to verify if the traffic mirroring activity is occurring in an expected region or if it is happening in a region that is not typically used by your organization.
+- Investigate the `requestParameters` field to gather more details about the configuration of the traffic mirroring components, such as the target and session settings.
+- Check for any other related CloudTrail events around the same timeframe that might indicate additional suspicious activities, such as changes to security groups or IAM policies.
+- Review network traffic logs and flow logs for the mirrored traffic to identify any unusual data patterns or potential data exfiltration attempts.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate network monitoring activities by security teams can trigger this detection. Regularly scheduled traffic mirroring for performance analysis or troubleshooting may appear as suspicious but are benign.
+- Automated infrastructure management: Automated scripts or tools that manage AWS resources might create traffic mirroring components as part of their operations. These should be reviewed to ensure they align with expected behavior.
+- Development and testing environments: In non-production environments, developers might use traffic mirroring to test network configurations or application performance, leading to false positives.
+- To manage these false positives, users can create exceptions for known IP addresses or AWS accounts that regularly perform legitimate traffic mirroring. Additionally, tagging resources with specific identifiers for approved activities can help in filtering out non-threatening events.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance to prevent further data exfiltration by disabling the traffic mirroring session.
+- Review CloudTrail logs to identify the source and scope of the traffic mirroring creation events, focusing on the user or service account responsible.
+- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated during the traffic mirroring session.
+- Change credentials and access keys for any compromised accounts and review IAM policies to ensure least privilege access is enforced.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement network segmentation to limit the exposure of sensitive data and reduce the risk of unauthorized traffic mirroring.
+- Enable encryption for all sensitive data in transit to mitigate the risk of data exfiltration through unencrypted traffic.
+- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and analysis.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply hardening measures such as disabling unused services, regularly updating software, and conducting security awareness training for users.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
index 6b99a4eed46..c501710147d 100644
--- a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
+++ b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,7 +23,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 VM Export Failure"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 VM Export Failure
+
+AWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, aligning with MITRE ATT&CK's exfiltration tactics.
+
+### Possible investigation steps
+
+- Review the specific CloudTrail event details associated with the failed export attempt, focusing on the `event.dataset`, `event.provider`, `event.action`, and `event.outcome` fields to confirm the nature of the failure.
+- Identify the IAM user or role (`userIdentity.arn`) that initiated the failed export task to determine if the action was performed by an authorized entity.
+- Check the source IP address (`sourceIPAddress`) and user agent (`userAgent`) associated with the failed export attempt to identify any unusual access patterns or locations.
+- Investigate the EC2 instance details (`requestParameters.instanceId`) involved in the export attempt to understand the potential sensitivity of the data within the instance.
+- Examine the AWS account activity logs for any other suspicious actions or patterns around the time of the failed export attempt to identify potential coordinated activities.
+- Use Osquery to gather additional context on the EC2 instance by running a query such as: `SELECT * FROM ec2_instance_metadata WHERE instance_id = '<instance_id>';` to retrieve metadata and assess the instance's configuration and network settings.
+- Analyze the CloudTrail logs for any successful export attempts or other related actions by the same IAM user or role to identify potential previous exfiltration activities.
+- Review the permissions and policies associated with the IAM user or role to ensure they align with the principle of least privilege and do not allow unauthorized export actions.
+- Correlate the failed export attempt with any recent changes in the AWS environment, such as new IAM policies or changes in network configurations, to identify potential misconfigurations.
+- Consult with relevant stakeholders or system owners to verify the legitimacy of the export attempt and gather additional context on the business need or lack thereof for such an action.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate export attempts by system administrators for backup or migration purposes may trigger the rule. Users can handle these by creating exceptions for known administrator accounts or specific time windows when such tasks are scheduled.
+- Testing and development activities: Developers or IT staff may export VMs as part of testing or development processes. To manage these, users can exclude specific development accounts or tags associated with test environments.
+- Automated backup solutions: Some organizations use automated tools that periodically export VMs for backup. Users should identify and exclude these tools by their associated IAM roles or service accounts to prevent false positives.
+- Misconfigured export tasks: Failed export attempts due to misconfigurations or permission issues might be flagged. Users can review and adjust IAM policies or export configurations to ensure legitimate tasks are not mistakenly identified as threats.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account to prevent further unauthorized export attempts by restricting permissions and access.
+- Review AWS CloudTrail logs to identify the source of the failed export attempt, including the user or service account involved, and assess if there are any other suspicious activities.
+- Verify the integrity of the EC2 instances involved in the export attempt to ensure no data has been altered or exfiltrated.
+- Change credentials and access keys for any compromised accounts to prevent further unauthorized access.
+- Escalate the incident to the security operations team for a thorough investigation and to determine if the attempt is part of a larger attack.
+- Implement stricter IAM policies to limit export permissions to only trusted and necessary accounts, reducing the risk of unauthorized export attempts.
+- Enhance logging and monitoring by enabling detailed CloudTrail logging and integrating with a SIEM solution for real-time alerting and analysis.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Restore any affected systems to their operational state by verifying configurations and ensuring all security patches are applied.
+- Implement hardening measures such as multi-factor authentication, regular audits of access permissions, and continuous security training for users to prevent future incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance"]
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
index 3acc55c151f..d6c4526f36e 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,7 +20,52 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Snapshot Export"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS Snapshot Export
+
+Amazon RDS allows users to create snapshots of their databases, which can be exported for backup or migration. Adversaries may exploit this feature to exfiltrate sensitive data by exporting snapshots to external locations. The detection rule monitors successful initiation of snapshot export tasks, flagging potential unauthorized data transfers by correlating specific CloudTrail events related to RDS operations.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to confirm the `event.action:StartExportTask` and `event.outcome:success` to ensure the snapshot export task was successfully initiated.
+- Identify the `userIdentity` field in the CloudTrail event to determine which IAM user or role initiated the snapshot export.
+- Check the `sourceIPAddress` field to verify the IP address from which the export task was initiated, and assess if it aligns with known and expected IP addresses.
+- Examine the `eventTime` field to establish the timeline of the export task and correlate it with other activities in the environment.
+- Investigate the `requestParameters` field to gather details about the specific RDS snapshot being exported, including the database identifier and snapshot name.
+- Analyze the `responseElements` field to confirm the destination of the exported snapshot and ensure it aligns with authorized S3 buckets or external locations.
+- Use Osquery to query AWS RDS configurations and permissions, for example: `SELECT * FROM aws_rds_instances WHERE instance_id = '<instance_id>'` to verify the instance details and associated permissions.
+- Cross-reference the IAM user or role with AWS IAM policies to ensure that the permissions granted are appropriate and do not allow unauthorized export actions.
+- Review recent changes in IAM policies or roles that might have inadvertently allowed the snapshot export, focusing on the `eventName:PutRolePolicy` or `eventName:AttachRolePolicy` in CloudTrail logs.
+- Investigate any other related CloudTrail events around the same `eventTime` to identify potential lateral movement or other suspicious activities that could indicate a broader security incident.
+
+### False positive analysis
+
+- Routine database maintenance or migration activities by authorized personnel can trigger the AWS RDS Snapshot Export rule, leading to false positives. 
+- Scheduled exports for backup purposes, especially in organizations with automated backup policies, may also be flagged as suspicious.
+- Development and testing environments often involve frequent snapshot exports, which can be mistaken for unauthorized activities.
+- To manage these false positives, users can create exceptions for known and scheduled export tasks by whitelisting specific IAM roles or user accounts responsible for legitimate exports.
+- Implementing tagging strategies for RDS instances and snapshots can help differentiate between routine operations and potential threats, allowing for more precise filtering in detection rules.
+- Regularly review and update the list of approved export tasks and associated personnel to ensure that only legitimate activities are excluded from alerts.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the snapshot export by contacting the database owner or relevant stakeholders to confirm if the action was authorized.
+- If unauthorized, revoke any temporary credentials or access keys that may have been used to initiate the export task.
+- Isolate the affected RDS instance by restricting network access and applying security groups to prevent further unauthorized actions.
+- Review CloudTrail logs and other relevant logs to identify any suspicious activities or patterns leading up to the export task.
+- Conduct a thorough investigation to determine the scope of the data exfiltration, including identifying any other compromised resources or accounts.
+- Escalate the incident to the security operations team and, if necessary, involve legal and compliance teams to assess potential data breach implications.
+- Restore the database from a known good snapshot or backup if data integrity is suspected to be compromised.
+- Implement enhanced logging and monitoring policies, such as enabling AWS Config and GuardDuty, to detect and alert on similar activities in the future.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export snapshots.
+- Conduct a post-incident review to identify gaps in the current security posture and apply hardening measures, such as multi-factor authentication and regular security training for users.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartExportTask.html"]
diff --git a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
index 4dced14d748..0c4ca32eb59 100644
--- a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
+++ b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EventBridge Rule Disabled or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EventBridge Rule Disabled or Deleted
+
+AWS EventBridge is a serverless event bus service that enables applications to respond to changes in data. Disabling or deleting rules can disrupt event-driven workflows, potentially masking malicious activities. Adversaries might exploit this by halting critical alerts or data flows. The detection rule monitors for successful disablement or deletion actions, signaling potential misuse or configuration tampering.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the user or role associated with the `DeleteRule` or `DisableRule` actions by examining the `user.identity.arn` field.
+- Check the `event.time` field in the CloudTrail logs to determine the exact time the rule was disabled or deleted, and correlate this with other activities in the AWS account around the same time.
+- Investigate the `event.sourceIPAddress` field to identify the source IP address from which the action was initiated, and determine if it is a known or expected address.
+- Examine the `event.requestParameters` field to identify the specific EventBridge rule that was disabled or deleted, and assess its importance in the event-driven architecture.
+- Use AWS CloudTrail insights to detect any unusual activity patterns or anomalies associated with the user or role that performed the action.
+- Cross-reference the `event.userAgent` field to understand the tool or service used to perform the action, which might provide additional context about the method of access.
+- Utilize Osquery to query AWS API logs for any other suspicious activities related to EventBridge. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('DeleteRule', 'DisableRule') AND eventSource = 'eventbridge.amazonaws.com';`
+- Investigate any recent IAM policy changes that might have granted new permissions to the user or role involved, which could indicate privilege escalation.
+- Review the AWS Config history for the EventBridge rule to understand its previous state and any recent changes that might have led to its disablement or deletion.
+- Check for any associated CloudWatch alarms or logs that might have been affected by the rule's disablement or deletion, to assess the potential impact on monitoring and alerting.
+
+### False positive analysis
+
+- Routine maintenance or updates: Scheduled maintenance activities or updates by authorized personnel may involve disabling or deleting EventBridge rules temporarily. These actions, while legitimate, can trigger alerts. Users can manage these by creating exceptions for known maintenance windows or by whitelisting actions performed by specific IAM roles or users responsible for maintenance.
+- Development and testing environments: In non-production environments, developers might frequently disable or delete rules as part of testing new features or configurations. To reduce noise, users can exclude events originating from specific AWS accounts or regions designated for development and testing.
+- Automated workflows: Some automated processes or third-party tools might disable or delete rules as part of their normal operation. Users should identify these tools and create exceptions for their actions, ensuring that only expected and documented automated changes are excluded.
+- Organizational policy changes: Changes in organizational policies might require temporary suspension of certain rules. Users should document these policy-driven changes and adjust detection rules to account for them, possibly by excluding actions taken by specific policy enforcement tools or teams.
+
+### Response and remediation
+
+- Immediately review CloudTrail logs to identify the user or service account responsible for disabling or deleting the EventBridge rule and verify if the action was authorized.
+- Contain the potential threat by temporarily revoking permissions for the identified user or service account to prevent further unauthorized actions.
+- Investigate the context and intent behind the rule modification by checking related activities in CloudTrail and other AWS services to determine if it is part of a larger attack pattern.
+- Restore the disabled or deleted EventBridge rule from backups or recreate it based on the last known good configuration to resume normal operations.
+- Escalate the incident to the security operations team if unauthorized activity is confirmed, and involve relevant stakeholders for a coordinated response.
+- Implement AWS CloudWatch alarms to monitor for future disablement or deletion of critical EventBridge rules to ensure timely detection of similar incidents.
+- Enhance logging policies by enabling detailed logging for EventBridge and related AWS services to improve visibility and facilitate future investigations.
+- Integrate AWS Security Hub or a similar security information and event management (SIEM) tool to centralize alerts and streamline incident response processes.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address identified weaknesses.
+- Apply hardening measures by enforcing least privilege access, using AWS Identity and Access Management (IAM) roles with strict permissions, and regularly reviewing access policies to minimize the risk of unauthorized actions.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
index 06305eb8968..8ae09533df0 100644
--- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
+++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Encryption Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 Encryption Disabled
+
+Amazon EC2's EBS encryption ensures data at rest is secure by default. Disabling this feature can expose sensitive data, making it vulnerable to unauthorized access. Adversaries might exploit this by disabling encryption to manipulate or exfiltrate data without detection. The detection rule monitors CloudTrail logs for successful attempts to disable EBS encryption, alerting analysts to potential security breaches.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to confirm the event by filtering for `event.dataset:aws.cloudtrail` and `event.provider:ec2.amazonaws.com` to ensure the event is related to EC2 actions.
+- Verify the specific action by checking `event.action:DisableEbsEncryptionByDefault` to confirm that the alert was triggered by an attempt to disable EBS encryption by default.
+- Check the `event.outcome:success` field to ensure that the action was successfully executed, indicating a potential security concern.
+- Identify the IAM user or role responsible for the action by examining the `user.identity.arn` field in the CloudTrail logs to determine if the action was authorized or potentially malicious.
+- Investigate the source IP address and location by reviewing the `sourceIPAddress` field to identify any unusual or unauthorized access patterns.
+- Cross-reference the timestamp of the event with other logs and alerts to identify any correlated activities or anomalies around the same time.
+- Use Osquery to gather additional context on the instance involved. For example, run the following Osquery query to list all EC2 instances and their encryption status: `SELECT instance_id, block_device_mapping FROM ec2_instance WHERE region = 'your-region';`
+- Analyze the historical activity of the IAM user or role involved by reviewing past CloudTrail logs to identify any patterns of suspicious behavior or previous attempts to disable encryption.
+- Check for any recent changes in IAM policies or permissions that might have allowed the user or role to disable EBS encryption by default.
+- Collaborate with the AWS account management team to verify if the action was part of a legitimate change request or if it requires further investigation.
+
+### False positive analysis
+
+- Routine administrative actions: In some cases, disabling EBS encryption by default may be part of regular maintenance or configuration changes performed by authorized personnel. Users should verify if the action aligns with scheduled tasks or approved change requests.
+- Testing and development environments: Developers might disable encryption in non-production environments for testing purposes. It's important to differentiate between production and non-production activities to avoid unnecessary alerts.
+- Automated scripts or tools: Some automation tools or scripts might disable encryption as part of their setup process. Users should review and whitelist these tools if they are deemed non-threatening.
+- Regional configuration changes: Changes in regional settings might trigger this alert. Users should ensure that such changes are intentional and documented, and consider excluding these events if they are part of a known process.
+- To manage false positives, users can create exceptions or filters in their monitoring systems to exclude known non-threatening behaviors, ensuring that alerts are only generated for unexpected or unauthorized actions.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instances to prevent further unauthorized access or data manipulation.
+- Review CloudTrail logs to identify the user or service account responsible for disabling EBS encryption and assess their activity for any other suspicious actions.
+- Re-enable EBS encryption by default in the affected region to ensure future volumes are encrypted.
+- Conduct a thorough investigation of the affected volumes to determine if any data manipulation or exfiltration has occurred.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are needed.
+- Implement AWS Config rules to continuously monitor and alert on changes to EBS encryption settings.
+- Enhance logging policies by ensuring that all relevant AWS services are logging to CloudTrail and that logs are retained for an appropriate period.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
+- Restore any manipulated data from backups, ensuring that restored data is encrypted and secure.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized users can modify encryption settings.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
index 289a125097f..fe60165fc75 100644
--- a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
+++ b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,7 +24,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EFS File System or Mount Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EFS File System or Mount Deleted
+
+Amazon Elastic File System (EFS) provides scalable file storage for use with AWS cloud services and on-premises resources. Adversaries may exploit EFS by deleting file systems or mount targets, disrupting applications reliant on these resources. The detection rule identifies successful deletion events, signaling potential malicious activity by monitoring specific AWS CloudTrail logs for actions like DeleteMountTarget or DeleteFileSystem.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:elasticfilesystem.amazonaws.com` fields to ensure the alert is valid and not a false positive.
+- Examine the `event.action` field to determine whether the action was `DeleteMountTarget` or `DeleteFileSystem`, as this will help identify the specific resource affected.
+- Check the `event.outcome:success` field to verify that the deletion action was completed successfully, confirming the potential impact on resources.
+- Identify the AWS account and user or role responsible for the deletion by reviewing the `userIdentity` field in the CloudTrail logs to determine if the action was authorized or potentially malicious.
+- Investigate the `sourceIPAddress` field to trace the origin of the request, which can help identify if the action was performed from a known or suspicious location.
+- Use Osquery to gather additional context on the affected EFS resources by running a query such as: `SELECT * FROM aws_efs_file_systems WHERE file_system_id = '<affected_file_system_id>';` to retrieve details about the deleted file system.
+- Cross-reference the deletion event with recent IAM policy changes or access logs to identify any unusual modifications that might have enabled unauthorized access.
+- Review recent activity logs for the affected EFS resources to identify any preceding actions or patterns that could indicate a broader attack or misconfiguration.
+- Check for any associated alerts or incidents in your security information and event management (SIEM) system that might correlate with the EFS deletion event, providing additional context or evidence of malicious activity.
+- Consult with relevant stakeholders or application owners to assess the impact of the deletion on business operations and gather any additional insights or suspicions they might have regarding the event.
+
+### False positive analysis
+
+- Routine maintenance activities: Scheduled maintenance or updates by system administrators may involve deleting and recreating EFS file systems or mount targets. Users can handle these by creating exceptions for known maintenance windows or specific administrator actions.
+- Automated scaling operations: In environments with automated scaling, EFS resources might be programmatically deleted and recreated to optimize resource usage. Users should identify and exclude these automated processes from triggering alerts by using tags or specific identifiers.
+- Development and testing environments: In non-production environments, frequent creation and deletion of EFS resources for testing purposes can trigger false positives. Users can manage this by excluding specific accounts or environments dedicated to development and testing.
+- CloudFormation or other infrastructure as code tools: When using tools like AWS CloudFormation, EFS resources might be deleted as part of stack updates or deletions. Users should consider excluding actions initiated by these tools by filtering based on user agents or specific IAM roles associated with these operations.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further damage or data loss.
+- Verify the deletion event by cross-referencing with AWS CloudTrail logs to confirm unauthorized activity.
+- Conduct a thorough investigation to identify the source and method of the attack, focusing on compromised credentials or misconfigurations.
+- Restore the deleted EFS file system or mount from the most recent backup to minimize downtime and data loss.
+- Implement AWS Identity and Access Management (IAM) policies to restrict permissions, ensuring only authorized users can delete EFS resources.
+- Enable detailed logging and monitoring for AWS EFS and related services to detect and respond to future unauthorized activities promptly.
+- Integrate AWS CloudTrail logs with a Security Information and Event Management (SIEM) system for enhanced threat detection and analysis.
+- Escalate the incident to the security team and relevant stakeholders, providing them with detailed findings and impact assessments.
+- Review and update the incident response plan to incorporate lessons learned and improve future response efforts.
+- Apply hardening measures such as multi-factor authentication (MFA) and regular security audits to reduce the risk of similar incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml
index 97463e97775..92a11153d77 100644
--- a/rules/integrations/aws/impact_iam_group_deletion.toml
+++ b/rules/integrations/aws/impact_iam_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS IAM Group Deletion
+
+AWS IAM groups facilitate efficient management of user permissions by organizing users with similar access needs. Adversaries may exploit group deletion to disrupt access controls, potentially hindering legitimate user activities. The detection rule monitors successful group deletions via AWS CloudTrail logs, flagging potential unauthorized access removal activities aligned with MITRE ATT&CK's impact tactics.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail`, `event.provider:iam.amazonaws.com`, and `event.action:DeleteGroup` fields to ensure the alert is valid.
+- Identify the IAM user or role responsible for the group deletion by examining the `userIdentity` field in the CloudTrail logs.
+- Check the `event.time` field to determine when the group deletion occurred and correlate this with any other suspicious activities around the same time.
+- Investigate the `sourceIPAddress` field to identify the origin of the request and determine if it aligns with known IP addresses or locations for legitimate users.
+- Review the `userAgent` field to understand the method used for deletion (e.g., AWS Management Console, AWS CLI) and assess if it matches typical usage patterns.
+- Examine the IAM policies and permissions associated with the user or role that performed the deletion to determine if they had the necessary permissions and if those permissions are appropriate.
+- Use Osquery to gather additional context on the IAM group deletion by running a query such as: `SELECT * FROM aws_iam_groups WHERE group_name = 'DeletedGroupName';` to verify if the group was recreated or if there are any related changes.
+- Check for any recent changes to IAM policies or roles that might have inadvertently allowed unauthorized group deletions.
+- Investigate other IAM activities by the same user or role around the time of the deletion to identify any patterns or additional unauthorized actions.
+- Review any recent security alerts or incidents involving the affected AWS account to determine if the group deletion is part of a larger security event.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IAM group deletions may occur during regular maintenance or restructuring of AWS resources, where administrators remove outdated or unnecessary groups. 
+- Automated scripts or tools: Organizations may use automated processes to manage IAM groups, leading to frequent deletions that are non-threatening.
+- Testing environments: In development or testing environments, IAM groups may be created and deleted frequently as part of testing procedures.
+- To manage these false positives, users can create exceptions for known administrative accounts or scripts that regularly perform these actions, ensuring that alerts are only triggered for unexpected deletions.
+
+### Response and remediation
+
+- Immediately review AWS CloudTrail logs to confirm the deletion of the IAM group and identify the user or service responsible for the action.
+- Verify if the group deletion was authorized by checking with the IAM administrators or reviewing change management records.
+- If unauthorized, disable the IAM user or role responsible for the deletion to prevent further unauthorized actions.
+- Restore the deleted IAM group by recreating it and reassigning the necessary permissions and users based on the last known configuration.
+- Conduct a thorough investigation to determine if any other IAM resources or permissions were altered or deleted.
+- Escalate the incident to the security operations team for further analysis and to determine if there is a broader security breach.
+- Implement enhanced logging and monitoring for IAM activities, ensuring that all critical actions are captured and reviewed regularly.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have permissions to delete IAM groups.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
index 11c2d13335e..6965a5b2d0c 100644
--- a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
+++ b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Xavier Pich"]
@@ -25,7 +25,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS KMS Customer Managed Key Disabled or Scheduled for Deletion
+
+AWS KMS Customer Managed Keys (CMKs) are crucial for encrypting sensitive data. Disabling or scheduling their deletion can lead to irreversible data loss, as encrypted data becomes inaccessible. Adversaries may exploit this to destroy data or disrupt operations. The detection rule monitors successful disablement or deletion attempts, alerting security teams to potential malicious activities targeting data integrity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `kms.amazonaws.com`, ensuring the alert is related to AWS KMS activities.
+- Verify the event action is either `DisableKey` or `ScheduleKeyDeletion` and that the event outcome is `success` to confirm the key was successfully disabled or scheduled for deletion.
+- Identify the specific AWS KMS Customer Managed Key (CMK) involved by examining the key ID or ARN in the event details.
+- Check the CloudTrail logs for the user identity or role that initiated the action to determine if it was an authorized user or a potential compromise.
+- Investigate the time and date of the event to correlate with any other suspicious activities or changes in the AWS environment.
+- Use AWS CloudTrail to review the history of actions taken on the affected CMK to identify any previous suspicious or unauthorized activities.
+- Examine IAM policies and permissions associated with the user or role to ensure they have the appropriate level of access and no excessive permissions.
+- Utilize Osquery to gather additional context on the AWS environment. For example, run a query to list all KMS keys and their current status: `SELECT * FROM aws_kms_keys WHERE key_state IN ('Disabled', 'PendingDeletion');`
+- Check for any recent changes in IAM roles, policies, or configurations that could have allowed unauthorized access to the KMS key.
+- Collaborate with the AWS account owner or security team to verify if the action was part of a planned operation or if it indicates a potential security incident.
+
+### False positive analysis
+
+- Routine maintenance activities: Organizations may have scheduled tasks or maintenance activities that involve disabling or scheduling the deletion of KMS keys as part of their lifecycle management. These actions, while legitimate, can trigger alerts. To manage this, users can create exceptions for specific keys or timeframes when these activities are expected.
+- Automated processes: Some automated systems or scripts might disable or schedule the deletion of KMS keys as part of their normal operation, such as rotating keys or decommissioning resources. Users should identify these processes and exclude them from alerts by specifying the associated user or service accounts.
+- Testing environments: In testing or development environments, disabling or scheduling the deletion of KMS keys might be a common practice to simulate scenarios or test recovery processes. Users can exclude these environments from alerts by filtering based on environment tags or resource identifiers.
+- Misconfigured alerts: Sometimes, alerts may be triggered due to misconfigured monitoring rules or incorrect tagging of resources. Users should review and adjust their alert configurations to ensure they accurately reflect the organization's security policies and operational practices.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account or resources to prevent further unauthorized actions.
+- Review CloudTrail logs to identify the source and scope of the disablement or deletion attempt, focusing on user identity, IP address, and time of the event.
+- Verify if the disablement or deletion was authorized by cross-referencing with change management records or contacting the responsible team.
+- If unauthorized, revoke any compromised credentials and enforce a password reset for affected accounts.
+- Restore any disabled keys by re-enabling them if within the allowed recovery period, or initiate data recovery procedures if keys were deleted.
+- Escalate the incident to the security operations center (SOC) for further investigation and potential legal action if malicious intent is confirmed.
+- Implement AWS CloudTrail and AWS Config rules to continuously monitor and alert on key management activities.
+- Enhance logging policies to include detailed audit trails and integrate with a Security Information and Event Management (SIEM) system for real-time analysis.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply hardening measures such as enforcing multi-factor authentication (MFA) for all users and restricting key management permissions to a minimal set of trusted administrators.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_group_deletion.toml b/rules/integrations/aws/impact_rds_group_deletion.toml
index 989081659af..1b510ba00e4 100644
--- a/rules/integrations/aws/impact_rds_group_deletion.toml
+++ b/rules/integrations/aws/impact_rds_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,54 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Security Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS Security Group Deletion
+
+Amazon RDS Security Groups control access to RDS instances, acting as a firewall to manage inbound traffic. Adversaries may delete these groups to disrupt database security, potentially leading to unauthorized access or data breaches. The detection rule monitors successful deletion events in AWS CloudTrail logs, identifying potential misuse by correlating specific actions and outcomes, thus alerting analysts to investigate further.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the `event.action:DeleteDBSecurityGroup` and `event.outcome:success` fields to ensure the alert is valid and corresponds to a successful deletion event.
+- Identify the `userIdentity` field in the CloudTrail logs to determine which IAM user or role performed the deletion action.
+- Check the `sourceIPAddress` field to verify the IP address from which the deletion request originated, and assess if it aligns with known or expected IP addresses.
+- Investigate the `eventTime` field to establish the exact time of the deletion and correlate it with any other suspicious activities or alerts around the same timeframe.
+- Examine the `requestParameters` field to identify which specific RDS Security Group was deleted and assess its importance and impact on the environment.
+- Utilize Osquery to gather additional context on the AWS environment. For example, run a query to list all current RDS instances and their associated security groups to understand the current security posture:
+  ```sql
+  SELECT * FROM aws_rds_instances;
+  ```
+- Cross-reference the IAM user or role identified with recent IAM activity logs to check for any unusual or unauthorized access patterns or privilege escalations.
+- Review AWS CloudTrail logs for any recent `CreateDBSecurityGroup` or `ModifyDBSecurityGroup` actions to determine if there were any recent changes or creations that might relate to the deletion.
+- Investigate any recent changes to IAM policies or roles that might have inadvertently granted permissions to delete RDS Security Groups.
+- Check for any other alerts or anomalies in the AWS environment that might indicate a broader security incident or compromise.
+
+### False positive analysis
+
+- Routine maintenance or infrastructure changes by authorized personnel can trigger the AWS RDS Security Group Deletion rule, leading to false positives. 
+- Automated scripts or tools used for managing RDS instances might delete security groups as part of their normal operation, which could be misinterpreted as malicious activity.
+- To manage these false positives, users can create exceptions for specific IAM roles or users known to perform regular maintenance tasks, ensuring that alerts are only generated for unexpected deletions.
+- Implementing a whitelist of known, non-threatening actions or users can help reduce noise and focus on genuine threats.
+- Regularly review and update the list of exceptions to ensure it reflects current operational practices and does not inadvertently exclude suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected RDS instance by modifying its security group to restrict all inbound and outbound traffic.
+- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess if it was authorized.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected accounts to prevent further unauthorized actions.
+- Restore the deleted RDS security group from a backup or recreate it with the same rules to ensure continued protection of the database.
+- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration occurred during the period of exposure.
+- Escalate the incident to the security operations team and notify relevant stakeholders, including data protection officers, if sensitive data is involved.
+- Implement enhanced logging and monitoring policies to capture detailed access and modification events for RDS security groups.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can modify RDS security groups.
+- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as enabling multi-factor authentication (MFA) for all administrative access.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html"]
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
index 8648fe43465..2b9330dd5fc 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,52 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Deletion of RDS Instance or Cluster"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Deletion of RDS Instance or Cluster
+
+Amazon RDS is a managed service that simplifies database setup, operation, and scaling. Adversaries may exploit this by deleting RDS instances or clusters to disrupt services or destroy data, aligning with data destruction tactics. The detection rule monitors AWS CloudTrail logs for successful deletion actions, alerting security teams to potential malicious activity targeting RDS resources.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset`, `event.provider`, `event.action`, and `event.outcome` fields to ensure the alert is valid and corresponds to a successful deletion action.
+- Identify the user or role responsible for the deletion by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by an authorized entity or potentially compromised credentials.
+- Check the `sourceIPAddress` and `userAgent` fields in the CloudTrail logs to gather information about the origin of the request, which can help identify if the action was performed from an unusual location or device.
+- Investigate the `requestParameters` field to understand the specific RDS instance or cluster that was deleted, including its name and any associated tags, to assess the impact of the deletion.
+- Cross-reference the deletion event with recent IAM activity logs to identify any unusual permission changes or role assignments that could have facilitated unauthorized access.
+- Utilize Osquery to query the AWS environment for recent changes in IAM policies or roles that might have allowed the deletion. Example query: `SELECT * FROM aws_iam_policies WHERE action = 'rds:DeleteDBInstance' OR action = 'rds:DeleteDBCluster';`
+- Examine the AWS Config history for the deleted RDS instance or cluster to gather information on its configuration and any recent changes that might indicate a precursor to the deletion.
+- Review any recent AWS CloudWatch alarms or logs for anomalies or alerts related to the RDS instance or cluster prior to its deletion, which might provide context or indicate a broader attack.
+- Check for any correlated events in the AWS environment, such as EC2 instance terminations or S3 bucket deletions, that might suggest a coordinated attack or broader impact.
+- Consult with the database and application teams to verify if the deletion was part of a planned maintenance or decommissioning activity, ensuring alignment with organizational processes and avoiding false positives.
+
+### False positive analysis
+
+- Routine maintenance or infrastructure updates by authorized personnel can trigger alerts when RDS instances or clusters are intentionally deleted as part of scheduled tasks. 
+- Automated scripts or cloud management tools that manage database lifecycles might delete RDS resources as part of their normal operation, leading to false positives.
+- Development or testing environments often involve frequent creation and deletion of RDS instances, which can be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for specific IAM roles or users known to perform regular maintenance or development tasks.
+- Implementing tagging policies for RDS resources can help differentiate between production and non-production environments, allowing for more precise alerting and exclusion rules.
+- Regularly review and update the list of known benign activities and authorized personnel to ensure that the detection rule remains effective without generating unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further unauthorized access or data loss.
+- Verify the deletion event by cross-referencing with internal change management records to confirm if it was authorized.
+- Conduct a thorough investigation using AWS CloudTrail logs to identify the source and method of the deletion action.
+- Restore the deleted RDS instance or cluster from the latest backup to minimize data loss and service disruption.
+- Review and update IAM policies to ensure least privilege access, reducing the risk of unauthorized deletions.
+- Implement enhanced logging and monitoring for RDS activities, ensuring all actions are captured and reviewed regularly.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and analysis.
+- Escalate the incident to the security team and relevant stakeholders if malicious intent is suspected, following the organization's incident response plan.
+- Conduct a post-incident review to identify gaps in security controls and update incident response procedures accordingly.
+- Apply hardening measures such as enabling Multi-Factor Authentication (MFA) for all users with access to RDS resources and regularly reviewing access logs for suspicious activities.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
index ecdf99bd422..47a734fbc99 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Instance/Cluster Stoppage"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS Instance/Cluster Stoppage
+
+Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, aligning with the MITRE ATT&CK tactic of service stop. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS, alerting analysts to potential malicious activity aimed at impacting database availability.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `rds.amazonaws.com`, ensuring the alert is relevant to an RDS stoppage.
+- Verify the event action is either `StopDBCluster` or `StopDBInstance` and the event outcome is `success` to confirm the stoppage was successful.
+- Identify the user or role that initiated the stop action by examining the `userIdentity` field in the CloudTrail logs.
+- Check the `sourceIPAddress` field to determine the IP address from which the stop action was initiated, which may provide clues about the origin of the request.
+- Investigate the `eventTime` field to establish a timeline and correlate with other events or activities that occurred around the same time.
+- Use Osquery to gather additional context on the AWS environment. For example, run a query to list all recent changes to RDS instances: `SELECT * FROM aws_rds_instances WHERE last_modified > date('now', '-1 day');`
+- Examine the `requestParameters` field to understand the specific parameters used in the stop request, which might indicate whether it was a planned action or an anomaly.
+- Cross-reference the stopped RDS instance or cluster with any scheduled maintenance or deployment activities to rule out legitimate administrative actions.
+- Review IAM policies and permissions associated with the user or role to determine if they have the necessary permissions to stop RDS instances or clusters, and if those permissions are appropriate.
+- Check for any other alerts or anomalies in the AWS environment that might indicate a broader attack or misconfiguration, such as unauthorized access attempts or changes to security groups.
+
+### False positive analysis
+
+- Routine maintenance activities: Scheduled maintenance or updates by authorized personnel may trigger the rule. Users can handle this by creating exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scaling operations: Some environments may have automated scripts or tools that stop RDS instances as part of scaling operations. Users should identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.
+- Cost-saving measures: Organizations may stop RDS instances during off-peak hours to save costs. Users can manage this by setting up time-based exceptions for these known cost-saving schedules.
+- Testing and development environments: Instances in non-production environments may be stopped frequently for testing purposes. Users can exclude these environments by filtering based on instance identifiers or environment tags.
+- Disaster recovery drills: Regularly scheduled disaster recovery tests may involve stopping RDS instances. Users should document these drills and exclude them from alerts by using specific event identifiers or user accounts involved in the drills.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the stop action by checking the user identity and source IP address in the CloudTrail logs to determine if the action was authorized.
+- If unauthorized, isolate the affected RDS instance or cluster by restricting access through security groups and network ACLs to prevent further unauthorized actions.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Conduct a root cause analysis to understand how the unauthorized stop action was executed, focusing on compromised credentials or misconfigurations.
+- Restore the RDS instance or cluster to its operational state by starting the service and verifying data integrity and availability.
+- Review and update IAM policies to ensure the principle of least privilege is enforced, limiting who can stop RDS instances or clusters.
+- Implement enhanced logging and monitoring by enabling AWS CloudTrail and Amazon CloudWatch to capture detailed activity logs and set up alerts for critical actions.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect potential threats proactively.
+- Conduct regular security awareness training for users to recognize phishing attempts and other tactics that could lead to credential compromise.
+- Consider implementing additional security measures such as multi-factor authentication (MFA) and automated incident response playbooks to improve resilience against similar threats.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_snapshot_deleted.toml b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
index ff2c665c4c9..eb23cec9373 100644
--- a/rules/integrations/aws/impact_rds_snapshot_deleted.toml
+++ b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,48 @@ any where event.dataset == "aws.cloudtrail"
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS Snapshot Deleted
+
+AWS RDS snapshots are critical for data recovery, capturing full backups of database instances. Adversaries may delete these snapshots to prevent data restoration, effectively causing data loss. The detection rule monitors AWS CloudTrail logs for successful deletion actions or modifications that disable automated backups, signaling potential malicious activity aimed at data destruction.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.action` field to verify if it matches "DeleteDBSnapshot", "DeleteDBClusterSnapshot", or "ModifyDBInstance" with `backupRetentionPeriod=0`.
+- Check the `event.provider` field to ensure the event is associated with "rds.amazonaws.com", confirming it pertains to RDS operations.
+- Analyze the `event.outcome` field to ensure the action was successful, indicating the snapshot was indeed deleted or the backup retention was modified.
+- Investigate the `aws.cloudtrail.user_identity` field to identify the user or role that performed the deletion or modification, which can help determine if the action was authorized.
+- Examine the `aws.cloudtrail.source_ip_address` field to identify the source IP address from which the request originated, which may provide clues about the actor's location or network.
+- Review the `aws.cloudtrail.request_parameters` field for additional context on the request, such as the specific snapshot or DB instance affected.
+- Utilize Osquery to gather further information on the AWS environment by running a query like: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('DeleteDBSnapshot', 'DeleteDBClusterSnapshot', 'ModifyDBInstance') AND requestParameters LIKE '%backupRetentionPeriod=0%';` to cross-reference and validate the CloudTrail logs.
+- Check for any recent IAM policy changes or unusual activity in the AWS account that could indicate compromised credentials or privilege escalation.
+- Investigate other related AWS services and logs for any concurrent suspicious activities, such as unauthorized access attempts or changes in security group configurations.
+- Correlate the event with any known threat intelligence or past incidents to determine if this activity aligns with known attack patterns or adversary tactics.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel can trigger the rule, such as scheduled deletions of outdated snapshots to manage storage costs. Users can handle these by creating exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or tools used for database management might delete snapshots as part of their normal operation. Users should identify these scripts and exclude their actions from triggering alerts by specifying the associated IAM roles or user accounts.
+- Changes in backup policies by the database administration team, such as temporarily setting the backupRetentionPeriod to 0 for testing purposes, can be mistaken for malicious activity. Users can manage this by documenting and excluding these policy changes when performed by trusted personnel.
+- Development or testing environments where snapshots are frequently created and deleted as part of the workflow may generate false positives. Users can exclude these environments by filtering out events associated with specific database instance identifiers or tags.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account to prevent further unauthorized actions and assess the scope of the incident.
+- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and verify if it was authorized.
+- If unauthorized access is confirmed, rotate credentials and access keys for compromised accounts and implement multi-factor authentication (MFA) for all users.
+- Restore the deleted RDS snapshot from a backup if available, or contact AWS Support for potential recovery options.
+- Increase the backup frequency and retention period for critical databases to minimize data loss in future incidents.
+- Implement AWS Config rules to monitor and alert on changes to RDS snapshot configurations and backup settings.
+- Conduct a thorough investigation to determine if other AWS resources have been compromised and take necessary actions to secure them.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess regulatory impacts.
+- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
+- Review and update the organization's incident response plan to incorporate lessons learned from the incident and improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/initial_access_password_recovery.toml b/rules/integrations/aws/initial_access_password_recovery.toml
index 76273e283f6..49f66d041e7 100644
--- a/rules/integrations/aws/initial_access_password_recovery.toml
+++ b/rules/integrations/aws/initial_access_password_recovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Password Recovery Requested"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS IAM Password Recovery Requested
+
+AWS IAM manages user access and permissions in AWS environments. Password recovery requests are legitimate processes for users to regain access. However, adversaries may exploit this by initiating unauthorized recovery attempts to gain access. The detection rule monitors AWS CloudTrail logs for successful password recovery requests, flagging potential unauthorized access attempts by correlating specific event attributes.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the details of the password recovery request, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:signin.amazonaws.com` fields to ensure the event is related to AWS IAM.
+- Verify the `event.action:PasswordRecoveryRequested` field to confirm that the alert was triggered by a password recovery request.
+- Check the `event.outcome:success` field to ensure the password recovery request was successful, indicating a potential unauthorized access attempt.
+- Identify the IAM user associated with the password recovery request and review their recent activity for any anomalies or unauthorized actions.
+- Investigate the source IP address and geolocation from which the password recovery request was initiated to determine if it aligns with the user's typical access patterns.
+- Examine the AWS account's login history to identify any unusual login attempts or patterns that could indicate compromised credentials.
+- Use Osquery to gather additional context on the IAM user's activity. For example, run the following Osquery query to list recent actions by the user: `SELECT * FROM aws_cloudtrail_events WHERE userIdentity.arn = 'arn:aws:iam::<account-id>:user/<username>' ORDER BY eventTime DESC LIMIT 10;`
+- Review any recent changes to IAM policies or permissions associated with the user to identify potential privilege escalation attempts.
+- Check for any other security alerts or incidents related to the same user or account to assess if this is part of a broader attack.
+- Collaborate with the user or account owner to verify if the password recovery request was legitimate and authorized, ensuring that the user is aware of the request and its implications.
+
+### False positive analysis
+
+- Legitimate user activity: Regular users may frequently request password recovery due to forgotten passwords or account lockouts. These actions can be considered false positives if they originate from known and trusted users.
+- Automated processes: Some organizations may have automated systems or scripts that periodically test password recovery mechanisms for security audits. These should be identified and excluded from alerts.
+- Third-party integrations: Applications or services integrated with AWS IAM might trigger password recovery requests as part of their normal operation. Identifying these integrations and excluding them can reduce false positives.
+- Handling false positives: Implement user and entity behavior analytics (UEBA) to establish a baseline of normal password recovery activities. Create exceptions for users or systems that regularly perform legitimate password recovery requests by adding them to an allowlist or using conditional logic in detection rules.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the password recovery request by contacting the user associated with the request to confirm if they initiated it.
+- Temporarily disable the affected IAM user account to prevent any unauthorized access until the investigation is complete.
+- Review AWS CloudTrail logs for any suspicious activities associated with the IAM user account, focusing on any unusual login attempts or changes in permissions.
+- Check for any other recent password recovery requests or account changes that may indicate a broader attack.
+- If unauthorized access is confirmed, reset the IAM user's password and enforce multi-factor authentication (MFA) to enhance account security.
+- Escalate the incident to the security operations team for a deeper investigation and to assess the potential impact on the AWS environment.
+- Implement logging policies to ensure comprehensive monitoring of IAM activities, including password recovery requests and login attempts.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance real-time detection and alerting capabilities.
+- Conduct a security review of IAM policies and permissions to ensure the principle of least privilege is enforced across all user accounts.
+- Educate users on recognizing phishing attempts and the importance of reporting suspicious activities to prevent future unauthorized access attempts.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"]
diff --git a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
index 7b3b75e46ad..34a83d7090f 100644
--- a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
+++ b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ['aws']
 maturity = "production"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
 
@@ -46,6 +46,49 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index
 | where mfa_used == "No"
 | keep @timestamp, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Signin Single Factor Console Login with Federated User
+
+Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent IAM user. This setup is convenient but can be risky if MFA is not enforced, as it leaves the door open for adversaries to exploit these credentials, potentially bypassing security measures. The detection rule identifies instances where federated users access the AWS console without MFA, signaling potential misuse of temporary credentials or STS tokens, which could indicate an attempt to gain unauthorized access. By monitoring these events, security teams can quickly respond to suspicious activities and mitigate risks associated with single-factor authentication.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.provider is "signin.amazonaws.com" and the event.action is "GetSigninToken" to ensure the alert is relevant to the AWS console login.
+- Verify the aws.cloudtrail.user_identity.type is "FederatedUser" to confirm that the login attempt was made by a federated user.
+- Check the aws.cloudtrail.event_type to ensure it is "AwsConsoleSignIn" to validate that the event pertains to a console login.
+- Examine the mfa_used field in the dissected aws.cloudtrail.additional_eventdata to confirm that MFA was not used during the login attempt.
+- Investigate the @timestamp field to determine the exact time of the login attempt and correlate it with other security events or logs around the same time.
+- Identify the source IP address of the login attempt from the CloudTrail logs to assess if it originates from a known or suspicious location.
+- Cross-reference the federated user's identity with IAM roles and policies to understand the level of access granted and potential impact.
+- Use Osquery to gather additional context on the federated user's activity by running a query such as: `SELECT * FROM aws_cloudtrail_events WHERE user_identity_type = 'FederatedUser' AND event_name = 'ConsoleLogin' AND mfa_used = 'No';`
+- Analyze historical login patterns for the federated user to identify any anomalies or deviations from typical behavior.
+- Check for any recent changes in IAM roles, policies, or federated user configurations that might have inadvertently allowed single-factor authentication.
+
+### False positive analysis
+
+- Federated users accessing the AWS Management Console from trusted networks or IP addresses without MFA may trigger false positives. These instances can be managed by creating exceptions for known IP ranges or trusted network locations.
+- Automated processes or scripts that use federated credentials for legitimate purposes without MFA can also result in false positives. To handle these, security teams can whitelist specific user agents or service accounts that are known to operate without MFA.
+- Temporary credentials used by third-party services or integrations that do not support MFA might be flagged. In such cases, exceptions can be made for specific service accounts or roles that are verified to be secure and necessary for business operations.
+- Regularly scheduled tasks or maintenance activities performed by federated users without MFA could be misidentified as threats. These can be excluded by documenting and approving such activities, then updating the detection rule to ignore these specific events.
+- Users who are part of a pilot program or testing environment where MFA is temporarily disabled might cause false positives. Security teams can manage this by setting up temporary exceptions for these users until the testing phase is complete.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the federated user to prevent further unauthorized access.
+- Investigate the source of the login attempt by reviewing the IP address, user agent, and any associated CloudTrail logs to determine if the access was legitimate or malicious.
+- Verify the identity of the federated user by contacting the user or the identity provider to confirm if the login attempt was authorized.
+- Implement or enforce multi-factor authentication (MFA) for all federated user logins to enhance security and prevent similar incidents in the future.
+- Review and update IAM policies to ensure that federated users have the least privilege necessary to perform their tasks.
+- Escalate the incident to the security operations team if there is evidence of malicious intent or if the scope of the incident is beyond initial containment measures.
+- Conduct a thorough audit of all recent federated user activities to identify any other suspicious actions or potential security breaches.
+- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
+- Develop and implement a security awareness program to educate users about the importance of MFA and secure credential handling.
+- Review and update the incident response plan to incorporate lessons learned from the incident and improve future response efforts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
index 153db90dc33..239db47d9aa 100644
--- a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
+++ b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,49 @@ any where event.dataset == "aws.cloudtrail"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
    and stringContains (user.id, ":i-")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 Instance Console Login via Assumed Role
+
+AWS EC2 instances can assume roles to access resources securely, using temporary credentials. Adversaries may exploit this by using compromised instance credentials to assume roles and gain unauthorized access. The detection rule identifies unusual console login activities by checking for EC2 instance IDs in session names and successful login events, signaling potential misuse of assumed roles.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the "i-" pattern in the session name, indicating an EC2 instance assumed role.
+- Verify the `event.dataset` field to ensure the event is sourced from "aws.cloudtrail" and the `event.provider` is "signin.amazonaws.com" to confirm the context of the alert.
+- Check the `event.action` field for "ConsoleLogin" or "GetSigninToken" to validate the type of login activity that occurred.
+- Examine the `event.outcome` field to confirm the login was successful, which is critical for identifying potential unauthorized access.
+- Investigate the `aws.cloudtrail.user_identity.type` field to ensure it is "AssumedRole", indicating the use of temporary credentials.
+- Identify the specific EC2 instance by extracting the instance ID from the `user.id` field, which contains the "i-" pattern.
+- Cross-reference the instance ID with AWS EC2 inventory to gather details about the instance, such as its purpose, owner, and associated security groups.
+- Use AWS CloudTrail logs to trace back the assumed role session to identify the source IP address and any preceding API calls that might indicate how the credentials were compromised.
+- If using Osquery, run a query to list all active sessions on the EC2 instance to identify any unusual or unauthorized users: `SELECT user, host, time FROM logged_in_users WHERE host = '<instance_id>';`
+- Analyze the AWS IAM role associated with the instance to review its permissions and determine if they are overly permissive or if there are any recent changes to the role's policy.
+
+### False positive analysis
+
+- **Automated Processes**: Some legitimate automated processes may use EC2 instance profiles to assume roles for routine tasks, leading to successful console login events. Users should identify and document these processes to differentiate them from potential threats.
+- **Frequent Role Assumptions**: In environments where EC2 instances frequently assume roles for legitimate purposes, such as accessing shared resources or services, these activities might trigger the rule. Users can create exceptions for known instance IDs or specific roles that are regularly assumed.
+- **Testing and Development Environments**: In testing or development environments, developers might frequently assume roles using EC2 instances for testing purposes. Users should consider excluding these environments from the rule or creating specific exceptions for known testing activities.
+- **Third-party Integrations**: Some third-party services or integrations might require EC2 instances to assume roles for legitimate operations. Users should verify these integrations and exclude them from the rule if they are deemed non-threatening.
+- **Handling False Positives**: To manage false positives, users can implement tagging or naming conventions for EC2 instances and roles that are known to perform legitimate activities. Additionally, users can adjust the rule to exclude specific instance IDs, roles, or environments that are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance to prevent further unauthorized access and lateral movement within the network.
+- Review CloudTrail logs to identify the source of the compromised credentials and any other potentially affected resources or accounts.
+- Revoke the temporary credentials associated with the assumed role to prevent further misuse.
+- Conduct a thorough investigation to determine how the credentials were compromised, focusing on recent changes or anomalies in the instance's environment.
+- Reset credentials and rotate keys for the affected instance and any other potentially compromised accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed.
+- Implement enhanced logging and monitoring policies to capture detailed access and activity logs for all EC2 instances and associated roles.
+- Integrate AWS GuardDuty and other threat detection services to provide real-time alerts and insights into suspicious activities.
+- Restore the affected EC2 instance from a known good backup or snapshot to ensure it is free from any unauthorized changes or malware.
+- Apply security hardening measures, such as enforcing least privilege access, enabling multi-factor authentication, and regularly reviewing IAM policies and roles."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
index 0ec4ba8c4a3..63f05e31011 100644
--- a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
+++ b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,53 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Network Access Control List Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 Network Access Control List Creation
+
+AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or enable unauthorized access by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential misuse by identifying unusual or unauthorized configurations.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `ec2.amazonaws.com`, ensuring the alert is relevant to AWS EC2 Network ACL creation.
+- Verify the event action is either `CreateNetworkAcl` or `CreateNetworkAclEntry` and the event outcome is `success` to confirm the alert is triggered by a successful creation event.
+- Identify the AWS account and user or role that initiated the ACL creation by examining the `user.identity.arn` and `user.identity.accountId` fields.
+- Check the `sourceIPAddress` field to determine the IP address from which the request originated, which can help identify potential unauthorized access.
+- Investigate the `aws.region` field to understand the geographical location of the resource creation and assess if it aligns with expected operations.
+- Examine the `requestParameters` field to gather details about the specific ACL rules created, such as rule number, protocol, and port range, to identify any overly permissive configurations.
+- Cross-reference the `userAgent` field to determine the tool or service used to create the ACL, which may provide insights into whether the action was automated or manual.
+- Utilize AWS CloudTrail logs to search for any preceding or subsequent suspicious activities associated with the same user or IP address.
+- If using Osquery, execute a query to list all current network ACLs and their entries for the affected AWS account to compare against known configurations:
+  ```sql
+  SELECT * FROM aws_ec2_network_acls WHERE account_id = '<affected_account_id>';
+  ```
+- Review IAM policies and permissions associated with the user or role that created the ACL to ensure they align with the principle of least privilege.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or changes to network configurations by authorized personnel can trigger alerts. To manage this, users can create exceptions for known IP addresses or user accounts that frequently perform these tasks.
+- Automated scripts or tools: Organizations may use automated processes to manage network ACLs, which can result in multiple creation events. Users should identify and whitelist these scripts or tools to prevent unnecessary alerts.
+- Infrastructure as Code (IaC) deployments: Deployments using IaC tools like Terraform or CloudFormation can generate numerous ACL creation events. Users can exclude these events by filtering based on the source of the deployment or tagging conventions.
+- Testing and development environments: Frequent changes in non-production environments can lead to false positives. Users can exclude these environments by using environment-specific tags or identifiers in their monitoring rules.
+
+### Response and remediation
+
+- Immediately review the newly created Network ACLs and entries to verify if they align with the organization's security policies and intended configurations.
+- Contain potential threats by temporarily restricting or removing overly permissive ACL rules that could allow unauthorized access.
+- Investigate the source of the ACL creation by reviewing CloudTrail logs to identify the user or service account responsible for the action.
+- If unauthorized access is suspected, rotate credentials and access keys for affected accounts and services to prevent further exploitation.
+- Escalate the incident to the security operations team if the ACL creation is determined to be malicious or part of a larger attack pattern.
+- Implement additional logging and monitoring for Network ACL changes to ensure real-time detection of suspicious activities.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance threat detection and response capabilities.
+- Restore the system to its operational state by reapplying the correct ACL configurations and ensuring all security policies are enforced.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Harden the environment by applying the principle of least privilege to IAM roles and ensuring that only authorized personnel can modify network configurations.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
index c01a4fe6b96..748f81ea33f 100644
--- a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
+++ b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,7 +23,49 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Security Group Configuration Change"
-note = """
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 Security Group Configuration Change
+
+AWS EC2 Security Groups act as virtual firewalls, controlling inbound and outbound traffic to instances. Adversaries may exploit changes in these configurations to gain unauthorized access, maintain persistence, or move laterally within an AWS environment. The detection rule monitors successful changes to security group settings, such as rule modifications or group creation, to identify potential misuse by threat actors.
+
+### Possible investigation steps
+
+- Review the specific `event.action` that triggered the alert to understand the type of change made to the security group configuration.
+- Examine the `event.dataset` and `event.provider` fields to confirm the event source and ensure it is related to AWS EC2.
+- Check the `event.outcome` field to verify that the change was successful, as unsuccessful attempts may indicate probing or testing by an adversary.
+- Identify the `user.identity` or `user.name` associated with the event to determine who made the change and assess if this user has legitimate access and reasons for the modification.
+- Investigate the `source.ip` or `source.address` to determine the origin of the request and assess if it is from a known or expected location.
+- Review the `aws.region` field to ensure the change was made in an expected region, as unexpected regions may indicate unauthorized activity.
+- Analyze the `event.time` to correlate the timing of the change with other suspicious activities or known incidents.
+- Use Osquery to gather additional context on the affected instances. For example, run the following query to list all security groups and their rules: `SELECT * FROM ec2_security_groups WHERE group_id = '<affected_group_id>';`
+- Cross-reference the security group changes with recent IAM policy changes or user activity logs to identify potential privilege escalation or misuse.
+- Investigate any other related CloudTrail logs around the same timeframe to identify additional suspicious activities or patterns that may indicate a broader attack.
+
+### False positive analysis
+
+- Routine administrative tasks: Changes made by authorized personnel during regular maintenance or updates can trigger alerts. To manage this, users can create exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or tools: Security group modifications by automated processes or tools used for infrastructure management may be flagged. Users should identify these tools and exclude their actions from triggering alerts by specifying their associated IAM roles or user accounts.
+- CloudFormation or other infrastructure as code deployments: Deployments that involve security group changes as part of infrastructure updates can result in false positives. Users can handle these by excluding changes initiated by specific CloudFormation stacks or deployment tools.
+- Third-party integrations: Some third-party services may require security group modifications for functionality. Users should review and whitelist these services if they are deemed non-threatening, ensuring that their actions do not trigger unnecessary alerts.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to identify the source and nature of the security group changes, focusing on the user or service account responsible for the modifications.
+- Contain the potential threat by reverting unauthorized security group changes to their previous state and temporarily restricting access to critical resources.
+- Investigate the IAM roles and permissions associated with the user or service account that made the changes to ensure they are appropriate and not overly permissive.
+- If unauthorized access is confirmed, rotate credentials and access keys for affected accounts and services to prevent further unauthorized actions.
+- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms used by the threat actor.
+- Implement enhanced logging and monitoring policies to capture detailed information on security group changes and other critical AWS activities.
+- Integrate AWS GuardDuty and other threat detection services to provide real-time alerts on suspicious activities and potential security breaches.
+- Restore the system to its operational state by ensuring all security group configurations are aligned with the organization's security policies and best practices.
+- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
+- Apply hardening measures such as implementing least privilege access, enabling multi-factor authentication, and regularly reviewing security group rules to minimize the risk of future incidents.
+
 ### Investigating AWS EC2 Security Group Configuration Change
 
 This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.
diff --git a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
index 447c69c9399..5f9eb975308 100644
--- a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
+++ b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL available in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/12/02"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,49 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS IAM Login Profile Added for Root"
-note = """
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS IAM Login Profile Added for Root
+
+AWS IAM allows management of user access and permissions within AWS environments. A login profile enables console access, typically not used by root accounts. Adversaries may exploit temporary root access to create a login profile, ensuring persistent access. The detection rule identifies this by monitoring specific API calls and conditions, such as successful profile creation without explicit user assignment, indicating potential self-assignment by a root user.
+
+### Possible investigation steps
+
+- Review the `@timestamp` field to determine when the login profile was created and correlate it with any known activities or changes in the environment around that time.
+- Examine the `aws.cloudtrail.user_identity.arn` to confirm the identity of the root user and verify if this action aligns with expected behavior or known activities.
+- Analyze the `source.address` to identify the IP address from which the CreateLoginProfile API call was made, and check if it matches known IP addresses associated with legitimate users or if it appears suspicious.
+- Investigate the `aws.cloudtrail.request_parameters` to understand the specifics of the request, ensuring no unexpected parameters were included that could indicate malicious intent.
+- Check the `aws.cloudtrail.response_elements` for any additional information or anomalies that might provide context or indicate a misconfiguration or security issue.
+- Use the `cloud.account.id` to identify the specific AWS account involved and verify if there have been any recent changes or incidents reported for this account.
+- Cross-reference the `aws.cloudtrail.user_identity.access_key_id` with known access keys to determine if the key used is legitimate or potentially compromised.
+- Utilize Osquery to further investigate the environment. For example, run an Osquery query to list all IAM users and their associated login profiles: `SELECT user_name, create_date FROM aws_iam_login_profiles;` to verify if any unexpected profiles exist.
+- Review historical CloudTrail logs for any other unusual or unauthorized activities associated with the root account, focusing on actions that could indicate privilege escalation or persistence attempts.
+- Collaborate with the account owner or security team to verify if the login profile creation was authorized and to gather any additional context or evidence that could aid in the investigation.
+
+### False positive analysis
+
+- **Automated Account Management Tools**: Some organizations use automated tools for account management that might inadvertently trigger the rule by creating login profiles for root accounts as part of their routine operations. To handle this, users can create exceptions for specific tools or scripts by identifying their unique access patterns or source IP addresses.
+- **Internal Security Audits**: During internal security audits, administrators might temporarily create login profiles for root accounts to test security configurations. These activities can be excluded by setting time-based exceptions during known audit periods or by excluding specific user identities associated with the audit team.
+- **Misconfigured Automation Scripts**: Scripts intended to manage IAM users might be misconfigured to include root account operations. Users should review and correct these scripts, and in the meantime, exclude known script-related activities by identifying their access keys or source IPs.
+- **Testing Environments**: In testing environments, developers might create login profiles for root accounts to simulate real-world scenarios. Users can manage these false positives by excluding specific testing environments based on account IDs or by tagging activities with identifiable metadata.
+
+### Response and remediation
+
+- Immediately revoke the login profile for the root account to prevent unauthorized access.
+- Rotate the root account's access keys and passwords to ensure no further unauthorized access can occur.
+- Review CloudTrail logs to identify any other suspicious activities or API calls made by the root account during the timeframe of the incident.
+- Implement multi-factor authentication (MFA) for the root account to add an additional layer of security.
+- Conduct a thorough investigation to determine how the adversary gained temporary access to the root account and address any identified vulnerabilities.
+- Escalate the incident to the security operations team for further analysis and to determine if any other accounts or resources have been compromised.
+- Enhance logging policies to ensure all critical actions, especially those involving root account activities, are logged and monitored in real-time.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for improved threat detection and response capabilities.
+- Restore the system to its operational state by verifying the integrity of all AWS resources and ensuring no unauthorized changes have been made.
+- Implement hardening measures such as least privilege access, regular security audits, and continuous monitoring to prevent future incidents.
+
 ## Investigating AWS IAM Login Profile Added for Root
 
 This rule detects when a login profile is added to the AWS root account. Adding a login profile to the root account, especially if self-assigned, is highly suspicious as it might indicate an adversary trying to establish persistence in the environment.
diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml
index 5d678c72d7c..fbf567bd93e 100644
--- a/rules/integrations/aws/persistence_iam_group_creation.toml
+++ b/rules/integrations/aws/persistence_iam_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS IAM Group Creation
+
+AWS IAM groups streamline permission management by allowing multiple users to inherit group-assigned permissions. Adversaries may exploit this by creating unauthorized groups to escalate privileges or maintain persistence. The detection rule monitors successful group creation events in AWS CloudTrail, flagging potential misuse by correlating specific IAM actions with known threat tactics.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to confirm the `event.action:CreateGroup` and `event.outcome:success` to ensure the alert is valid and not a false positive.
+- Identify the `userIdentity` field in the CloudTrail logs to determine which IAM user or role initiated the group creation.
+- Check the `event.time` field to establish the exact time of the group creation and correlate it with any other suspicious activities around the same timeframe.
+- Investigate the `requestParameters.groupName` to understand the naming convention and assess if it aligns with the organization's standard naming practices.
+- Examine the `sourceIPAddress` and `userAgent` fields to identify the origin of the request and determine if it was made from an unusual location or device.
+- Use AWS IAM console or CLI to list the members of the newly created group and verify if any unauthorized users have been added.
+- Review the permissions and policies attached to the new group to assess if they grant excessive or sensitive permissions that could be exploited.
+- Cross-reference the `userIdentity` with recent IAM activity logs to check for any other unusual or unauthorized actions performed by the same user or role.
+- Utilize Osquery to further investigate by running a query such as `SELECT * FROM aws_iam_groups WHERE group_name = '<group_name>';` to gather more details about the group and its configurations.
+- Check for any recent changes in IAM policies or configurations that might indicate an attempt to cover tracks or escalate privileges.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IAM group creation by system administrators for organizational purposes can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time frames when such activities are expected.
+- Automated processes: Some organizations use automated scripts or tools to manage IAM groups, which may lead to frequent group creation events. Users can exclude these processes by identifying and filtering out the specific IAM roles or user accounts associated with these automated tasks.
+- Third-party integrations: Certain third-party services or applications may require the creation of IAM groups as part of their setup or operation. Users should review and whitelist these services by correlating the group creation events with known application behavior and excluding them from alerts.
+- Testing environments: In environments where IAM group creation is part of regular testing or development activities, users can exclude specific AWS accounts or regions dedicated to testing to reduce noise from non-threatening group creation events.
+
+### Response and remediation
+
+- Immediately review the IAM group creation event in AWS CloudTrail to verify if it was authorized or potentially malicious.
+- Identify the user or service that initiated the group creation and assess their activity for any other suspicious actions.
+- If unauthorized, disable the newly created IAM group and revoke any permissions associated with it to prevent privilege escalation.
+- Conduct a thorough investigation of the IAM policies attached to the group to ensure no sensitive permissions were granted.
+- Escalate the incident to the security operations team if the group creation is linked to known threat actors or tactics, such as those outlined in MITRE ATT&CK T1136.
+- Implement additional logging and monitoring for IAM activities to detect similar unauthorized actions in the future.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring users and groups have only the permissions necessary for their roles.
+- Integrate AWS CloudTrail logs with a Security Information and Event Management (SIEM) system for enhanced threat detection and correlation.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate and train staff on recognizing and reporting suspicious IAM activities to improve organizational awareness and response capabilities.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_rds_cluster_creation.toml b/rules/integrations/aws/persistence_rds_cluster_creation.toml
index 352fd7c484b..6f5591d1d8e 100644
--- a/rules/integrations/aws/persistence_rds_cluster_creation.toml
+++ b/rules/integrations/aws/persistence_rds_cluster_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Cluster Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS Cluster Creation
+
+Amazon RDS facilitates database management by automating tasks like scaling and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes within AWS CloudTrail logs.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:rds.amazonaws.com` fields to ensure the event is related to RDS cluster creation.
+- Verify the `event.action` field to determine whether the action was `CreateDBCluster` or `CreateGlobalCluster`, as these are the specific actions of interest.
+- Check the `event.outcome:success` field to confirm that the cluster creation was successful, which is crucial for identifying potential unauthorized activities.
+- Identify the AWS account and user associated with the event by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by a legitimate user or an adversary.
+- Investigate the source IP address and location from which the request originated using the `sourceIPAddress` field to identify any unusual or suspicious access patterns.
+- Analyze the `requestParameters` field to gather details about the configuration of the newly created RDS cluster, such as the database engine, instance type, and region, to assess if they align with expected configurations.
+- Cross-reference the `userAgent` field to understand the tool or service used to perform the action, which can provide insights into whether the action was automated or manually executed.
+- Utilize Osquery to further investigate the AWS environment by running a query such as `SELECT * FROM aws_rds_clusters WHERE name = '<cluster_name>';` to gather additional details about the cluster, including its status and configuration.
+- Review recent IAM policy changes or role assignments that might have granted the necessary permissions for RDS cluster creation, focusing on any anomalies or deviations from standard practices.
+- Correlate the event with other recent AWS activity logs to identify any patterns or sequences of actions that could indicate a broader attack or unauthorized access attempt.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular database management activities by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or IP addresses.
+- Automated deployment scripts: Organizations using infrastructure as code (IaC) tools like Terraform or CloudFormation may inadvertently trigger the rule during legitimate deployments. Users should consider excluding specific IAM roles or tags associated with these tools.
+- Testing and development environments: Frequent creation of RDS clusters in non-production environments for testing purposes can lead to false positives. Users can exclude specific AWS accounts or regions dedicated to development and testing.
+- Scheduled maintenance: Automated processes for scaling or updating databases during scheduled maintenance windows might be flagged. Users can set time-based exceptions to ignore events during these periods.
+
+### Response and remediation
+
+- Immediately isolate the newly created RDS cluster to prevent any potential data exfiltration or unauthorized access.
+- Review AWS CloudTrail logs to identify the source of the cluster creation, including the IAM user or role responsible for the action.
+- Verify the legitimacy of the cluster creation with the relevant team or individual; if unauthorized, proceed with further investigation.
+- Revoke any suspicious or unauthorized IAM roles or user permissions that may have been used to create the RDS cluster.
+- Conduct a thorough review of network traffic and access logs to identify any data exfiltration attempts or unusual activity associated with the cluster.
+- If data exfiltration is confirmed, follow your organization's incident response plan to notify affected parties and regulatory bodies as required.
+- Implement enhanced logging and monitoring policies to capture detailed events related to RDS activities, ensuring future unauthorized actions are detected promptly.
+- Integrate AWS GuardDuty and other security tools to provide additional layers of threat detection and response capabilities.
+- Restore the system to its operational state by deleting unauthorized clusters and ensuring all legitimate clusters are configured securely with appropriate access controls.
+- Harden the environment by enforcing least privilege access, regularly reviewing IAM policies, and applying security patches to all related services.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_rds_group_creation.toml b/rules/integrations/aws/persistence_rds_group_creation.toml
index 1140f4e4ef5..43a0e8c8179 100644
--- a/rules/integrations/aws/persistence_rds_group_creation.toml
+++ b/rules/integrations/aws/persistence_rds_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,7 +20,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Security Group Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS Security Group Creation
+
+Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors AWS CloudTrail logs for successful creation events of RDS security groups, signaling potential misuse by identifying unexpected or suspicious activity.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to confirm the `event.action:CreateDBSecurityGroup` and `event.outcome:success` to ensure the alert is valid and not a false positive.
+- Identify the `userIdentity` field in the CloudTrail logs to determine which IAM user or role initiated the creation of the RDS security group.
+- Check the `sourceIPAddress` field to identify the IP address from which the request originated, and assess if it aligns with known or expected IP addresses.
+- Examine the `eventTime` field to understand when the security group was created and correlate it with other activities or alerts around the same time.
+- Investigate the `requestParameters` field to gather details about the security group, such as its name and description, to assess if it matches known naming conventions or appears suspicious.
+- Use Osquery to query AWS API logs for additional context on the IAM user or role involved. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'CreateDBSecurityGroup' AND userIdentity.arn = '<IAM User ARN>';`
+- Cross-reference the IAM user or role with recent changes in IAM policies or permissions to determine if there have been any unauthorized modifications.
+- Analyze the `responseElements` field to verify the configuration of the newly created security group, including any inbound or outbound rules that may pose a security risk.
+- Check for any other recent `CreateDBSecurityGroup` events in the logs to identify patterns or repeated unauthorized activities.
+- Review the organization's change management records or ticketing system to verify if the creation of the security group was part of an approved change request.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular maintenance or configuration changes by authorized personnel can trigger the creation of RDS security groups. Users should review the context of the event, such as the user identity and associated project, to determine if the activity is expected.
+- Automated deployment tools: Continuous integration and deployment pipelines may automatically create RDS security groups as part of their operations. Users can manage these by identifying and excluding specific IAM roles or user accounts associated with these tools from the detection rule.
+- Infrastructure as Code (IaC) practices: Tools like Terraform or AWS CloudFormation might create security groups as part of infrastructure provisioning. Users should document and exclude these known IaC processes to reduce noise in alerts.
+- Testing environments: Security groups created in non-production environments for testing purposes can be mistaken for suspicious activity. Users should differentiate between production and non-production environments and apply exceptions accordingly.
+- Frequent changes in dynamic environments: In environments where resources are frequently scaled or modified, security group creation might be a common occurrence. Users should establish a baseline of normal activity and adjust the detection rule to focus on deviations from this baseline.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved.
+- Contain the threat by revoking access for the identified user account and removing the unauthorized RDS security group.
+- Investigate the extent of the compromise by checking for any other unauthorized changes or access patterns in the AWS environment.
+- Escalate the incident to the security operations team for a deeper investigation and to determine if any data exfiltration occurred.
+- Remediate by rotating credentials and implementing multi-factor authentication for all AWS accounts to prevent further unauthorized access.
+- Restore the system by ensuring all security groups are configured according to the organization's security policies and best practices.
+- Enhance future investigations by enabling detailed logging for all AWS services and integrating with a Security Information and Event Management (SIEM) system for real-time monitoring.
+- Implement a policy to regularly review and audit security group configurations and access logs to detect any anomalies promptly.
+- Educate and train staff on recognizing and reporting suspicious activities to improve the organization's security posture.
+- Apply hardening measures by restricting security group creation permissions to a limited number of trusted administrators and using AWS Identity and Access Management (IAM) roles with the principle of least privilege.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html"]
diff --git a/rules/integrations/aws/persistence_rds_instance_creation.toml b/rules/integrations/aws/persistence_rds_instance_creation.toml
index ba167a1cb93..ed891dad756 100644
--- a/rules/integrations/aws/persistence_rds_instance_creation.toml
+++ b/rules/integrations/aws/persistence_rds_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,7 +20,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Instance Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS Instance Creation
+
+Amazon RDS simplifies database management, offering scalable and cost-effective solutions. However, adversaries may exploit RDS by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creation events, flagging potential misuse by correlating specific AWS CloudTrail logs, thus enabling timely investigation and response.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:rds.amazonaws.com` fields to ensure the event is related to RDS instance creation.
+- Verify the `event.action:CreateDBInstance` and `event.outcome:success` fields to confirm that the instance creation was successful and intended.
+- Identify the AWS account and user associated with the instance creation by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by an authorized user.
+- Check the `sourceIPAddress` field to identify the IP address from which the request originated, and assess if it aligns with known and trusted IP addresses.
+- Investigate the `requestParameters` field to gather details about the RDS instance configuration, such as instance type, database engine, and allocated storage, to understand the potential impact.
+- Cross-reference the `awsRegion` field to ensure the instance was created in an expected and authorized region.
+- Utilize Osquery to further investigate the AWS environment by running a query such as: `SELECT * FROM aws_rds_instances WHERE instance_id = '<instance_id>'` to gather more details about the newly created RDS instance.
+- Review IAM policies and roles associated with the user or service that created the instance to ensure they have appropriate permissions and are not overly permissive.
+- Check for any related alerts or anomalies in the same timeframe that might indicate a broader security incident or unauthorized activity.
+- Document all findings and observations in a centralized investigation log to maintain a clear record of the investigation process and support any further analysis or escalation.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular database maintenance or scaling activities by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
+- Automated processes: Scheduled scripts or automated workflows that create RDS instances for testing or development purposes may be flagged. Users should identify these processes and exclude them by tagging instances or using specific IAM roles associated with these tasks.
+- Third-party integrations: Some third-party services may create RDS instances as part of their functionality. Users should verify these integrations and whitelist the associated actions or service accounts to prevent false positives.
+- Testing environments: Instances created in non-production environments for testing purposes might be detected. Users can exclude these environments by filtering based on tags, VPC IDs, or other identifiable attributes specific to test setups.
+
+### Response and remediation
+
+- Verify the legitimacy of the RDS instance creation by checking with the relevant stakeholders or database administrators.
+- Contain the potential threat by immediately revoking access to the unauthorized RDS instance and isolating it from the network.
+- Investigate the source of the instance creation by reviewing AWS CloudTrail logs for unusual activity or unauthorized access patterns.
+- Remediate by terminating the unauthorized RDS instance and ensuring no data has been exfiltrated or compromised.
+- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or persistent threat.
+- Implement enhanced logging policies to capture detailed access and activity logs for all RDS instances and related AWS services.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
+- Restore the system to its operational state by ensuring all legitimate RDS instances are functioning correctly and securely.
+- Harden the environment by enforcing strict IAM policies, using multi-factor authentication, and regularly reviewing access permissions.
+- Educate and train staff on recognizing and responding to potential security incidents, emphasizing the importance of vigilance and prompt reporting.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html"]
diff --git a/rules/integrations/aws/persistence_redshift_instance_creation.toml b/rules/integrations/aws/persistence_redshift_instance_creation.toml
index ee4a8e87d42..29d11691e98 100644
--- a/rules/integrations/aws/persistence_redshift_instance_creation.toml
+++ b/rules/integrations/aws/persistence_redshift_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Redshift Cluster Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Redshift Cluster Creation
+
+Amazon Redshift is a data warehousing service that allows for scalable data storage and analysis. Adversaries might exploit Redshift by creating unauthorized clusters to exfiltrate data or conduct unauthorized data analysis. The detection rule monitors for successful cluster creation events, especially by non-admin users, to identify potential misuse or misconfigurations that could lead to security vulnerabilities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `redshift.amazonaws.com` to ensure the alert is related to Redshift cluster creation.
+- Verify the `event.action` field is `CreateCluster` and the `event.outcome` is `success` to confirm a successful cluster creation event.
+- Identify the user who initiated the cluster creation by examining the `user.name` field in the event logs.
+- Check the `user.role` or `user.group` fields to determine if the user has administrative privileges or if they are a non-admin user.
+- Investigate the `source.ip` field to identify the IP address from which the cluster creation request originated and determine if it is a known or trusted source.
+- Review the `aws.region` field to verify if the cluster was created in an expected region or if it was created in an unusual or unauthorized region.
+- Use AWS CloudTrail logs to gather additional context around the time of the cluster creation event, looking for any other suspicious activities or related events.
+- If available, use Osquery to query AWS Redshift configurations and gather more details about the newly created cluster. Example Osquery query: `SELECT * FROM aws_redshift_clusters WHERE cluster_identifier = '<cluster_id>';`
+- Check for any recent changes in IAM policies or roles that might have inadvertently granted the user permissions to create Redshift clusters.
+- Review the organization's policy on Redshift cluster creation to determine if the creation aligns with expected usage patterns and business needs.
+
+### False positive analysis
+
+- Routine administrative tasks: Regularly scheduled maintenance or updates by authorized personnel might trigger cluster creation events. Users can manage these by creating exceptions for known maintenance windows or specific user accounts.
+- Automated processes: Some organizations use automated scripts or third-party tools to manage Redshift clusters, which could lead to false positives. Identifying and excluding these processes from alerts can reduce noise.
+- Development and testing environments: Non-admin users might create clusters for legitimate development or testing purposes. Establishing a list of approved users or environments can help in filtering out these benign activities.
+- Training and onboarding: New employees or teams might create clusters as part of their training or onboarding process. Monitoring and documenting these activities can help distinguish them from potential threats.
+- Temporary projects: Short-term projects might require the creation of Redshift clusters by non-admin users. Implementing a review process for temporary projects can help in identifying and excluding these from alerts.
+
+### Response and remediation
+
+- Verify the identity and permissions of the user who created the Redshift cluster to ensure they have the appropriate authorization.
+- Immediately isolate the newly created Redshift cluster to prevent any potential data exfiltration or unauthorized access.
+- Review CloudTrail logs to identify any suspicious activities or patterns associated with the cluster creation event.
+- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated using the unauthorized cluster.
+- Revoke any unnecessary permissions or roles from the user involved in the cluster creation to prevent further unauthorized actions.
+- Escalate the incident to the security operations team if the investigation reveals malicious intent or data compromise.
+- Implement enhanced logging and monitoring policies to capture detailed events related to Redshift cluster activities for future investigations.
+- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities within the AWS environment.
+- Restore the system to its operational state by deleting the unauthorized Redshift cluster and ensuring no residual configurations remain.
+- Apply hardening measures such as enforcing least privilege access, enabling multi-factor authentication, and regularly reviewing IAM policies to prevent similar incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateCluster.html"]
diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
index 3adaff849fd..14d611b2f55 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,7 +23,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route 53 Domain Transfer Lock Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Route 53 Domain Transfer Lock Disabled
+
+AWS Route 53's domain transfer lock is a security feature that prevents unauthorized domain transfers by locking the domain at the registrar level. Adversaries may disable this lock to transfer domains illicitly, potentially redirecting traffic or disrupting services. The detection rule monitors successful events where this lock is disabled, signaling potential unauthorized activity and enabling timely investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `route53.amazonaws.com` to ensure the alert is relevant to AWS Route 53.
+- Verify the event action is `DisableDomainTransferLock` and the event outcome is `success` to confirm that the transfer lock was indeed disabled successfully.
+- Identify the user or role that performed the action by examining the `user.identity.arn` field in the event logs to determine if the action was performed by an authorized entity.
+- Check the `sourceIPAddress` field to identify the IP address from which the request originated and assess if it is a known or trusted source.
+- Investigate the `userAgent` field to understand the application or service used to perform the action, which might provide additional context about the method of access.
+- Review the `eventTime` field to establish a timeline and correlate with other events or activities that occurred around the same time.
+- Use Osquery to gather additional context by querying AWS CloudTrail logs for any other suspicious activities related to the same user or IP address. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'DisableDomainTransferLock' AND userIdentity.arn = '<user_arn>' AND sourceIPAddress = '<source_ip>'`.
+- Examine any recent changes in IAM policies or roles that might have inadvertently granted permissions to disable the domain transfer lock.
+- Cross-reference with other security tools or logs to identify any concurrent alerts or anomalies that might indicate a broader security incident.
+- Document all findings and observations to build a comprehensive understanding of the event and prepare for potential escalation or further analysis.
+
+### False positive analysis
+
+- Routine administrative actions: Domain administrators may intentionally disable the transfer lock as part of legitimate domain management tasks, such as preparing for a planned transfer to another registrar. Users should verify the intent behind such actions by cross-referencing with change management records or direct communication with the domain management team.
+- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage domain settings, which might include disabling the transfer lock as part of their operations. Users can handle these by identifying and excluding known scripts or tools from triggering alerts, ensuring they are documented and approved.
+- Testing and development environments: In non-production environments, disabling the transfer lock might be part of testing procedures. Users should maintain a list of test domains and exclude them from monitoring to avoid unnecessary alerts.
+- Known trusted users: If certain users or roles are frequently involved in legitimate domain transfer activities, consider creating exceptions for these users after verifying their actions are authorized and documented.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the domain transfer lock removal by contacting the domain's registered owner or administrator.
+- Temporarily re-enable the domain transfer lock to prevent any unauthorized transfers while the investigation is ongoing.
+- Review AWS CloudTrail logs for any suspicious activity related to the domain, focusing on the user or service account that performed the action.
+- Check for any recent changes in IAM policies or roles that might have allowed unauthorized access to Route 53 settings.
+- If unauthorized activity is confirmed, rotate credentials and update access controls for affected accounts to prevent further unauthorized actions.
+- Escalate the incident to the security operations team for a deeper investigation and to assess potential impacts on other domains or services.
+- Implement enhanced logging and monitoring for Route 53 activities, ensuring that alerts are generated for any future changes to domain transfer locks.
+- Integrate AWS CloudTrail logs with a SIEM solution to improve detection and response capabilities for similar incidents.
+- Conduct a post-incident review to identify gaps in security controls and update policies or procedures to prevent recurrence.
+- Educate relevant personnel on the importance of domain security and the risks associated with unauthorized domain transfers, incorporating lessons learned from the incident.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
index 758c5f25b39..ad6f63592ec 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route 53 Domain Transferred to Another Account"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Route 53 Domain Transferred to Another Account
+
+AWS Route 53 is a scalable DNS web service designed to route end-user requests to internet applications. Adversaries may exploit domain transfer capabilities to hijack domains, redirecting traffic or disrupting services. The detection rule monitors successful domain transfer requests, flagging potential unauthorized account manipulations, aligning with MITRE ATT&CK's persistence and account manipulation tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `route53.amazonaws.com`, ensuring the alert is relevant to a Route 53 domain transfer.
+- Verify the `event.action` field to ensure it is `TransferDomainToAnotherAwsAccount` and the `event.outcome` is `success`, confirming a successful domain transfer request.
+- Identify the AWS account ID and user or role that initiated the transfer by examining the `user.identity.arn` and `aws.account.id` fields in the event logs.
+- Check the `sourceIPAddress` field to determine the IP address from which the transfer request was made, and assess if it aligns with known or expected IP addresses for the account.
+- Investigate the `userAgent` field to understand the application or service used to initiate the transfer, looking for anomalies or unexpected user agents.
+- Use Osquery to gather additional context on the AWS environment by running a query such as: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'TransferDomainToAnotherAwsAccount' AND recipientAccountId = '<target_account_id>';` to identify other related events.
+- Review recent AWS CloudTrail logs for any unusual activity or patterns around the time of the domain transfer, focusing on changes to IAM policies or roles.
+- Examine the AWS Route 53 configuration and domain settings to ensure no unauthorized changes were made post-transfer, such as DNS record modifications.
+- Cross-reference the domain transfer event with any recent support tickets or change requests to validate if the transfer was authorized and documented.
+- Consult with the domain's business owner or relevant stakeholders to confirm the legitimacy of the transfer and gather any additional context or concerns they may have.
+
+### False positive analysis
+
+- Legitimate domain transfers between accounts within the same organization can trigger this rule as a false positive. These transfers might occur during organizational restructuring or when consolidating domains under a single account for management purposes.
+- Routine domain management activities by authorized personnel, such as IT administrators or domain management teams, may also result in false positives if they frequently transfer domains for operational reasons.
+- To manage these false positives, users can create exceptions for known and trusted account IDs involved in regular domain transfers. This can be done by maintaining a whitelist of account IDs that are authorized to perform domain transfers.
+- Implementing a review process for domain transfer requests can help distinguish between legitimate and suspicious activities. This process should involve verifying the intent and authorization of the transfer with the involved parties.
+- Regularly updating and auditing the list of authorized personnel and accounts can help minimize false positives by ensuring only current and necessary accounts are included in exception lists.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized access to the AWS account by changing credentials and implementing multi-factor authentication (MFA) for all users.
+- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized actions or anomalies associated with the domain transfer.
+- Verify the integrity of DNS records and ensure that they have not been altered to redirect traffic maliciously.
+- Contact AWS Support to report the unauthorized domain transfer and seek assistance in reversing the transfer if necessary.
+- Notify relevant stakeholders, including IT security teams and management, about the incident and potential impacts on services.
+- Implement network monitoring to detect any unusual traffic patterns that may indicate further exploitation attempts.
+- Review and update IAM policies to ensure that only authorized personnel have permissions to transfer domains.
+- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on security best practices and the importance of safeguarding credentials to prevent future account manipulation attempts.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html"]
diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
index 50c7b0fa2ed..7638b2aa8bb 100644
--- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
+++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -20,7 +20,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route53 private hosted zone associated with a VPC"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Route53 private hosted zone associated with a VPC
+
+AWS Route53 private hosted zones allow for DNS management within a Virtual Private Cloud (VPC), ensuring internal resources are accessible only within the VPC. Adversaries may exploit this by associating unauthorized VPCs to intercept or reroute traffic. The detection rule monitors successful associations of VPCs with hosted zones, flagging potential unauthorized access or configuration changes indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `route53.amazonaws.com`, ensuring the alert is relevant to AWS Route53 activities.
+- Verify the event action is `AssociateVPCWithHostedZone` and the event outcome is `success` to confirm that a VPC was successfully associated with a private hosted zone.
+- Identify the AWS account and user or role that performed the action by examining the `userIdentity` field in the CloudTrail logs to determine if the action was authorized.
+- Check the `sourceIPAddress` field to identify the IP address from which the request originated, and assess if it aligns with known or expected IP addresses for your organization.
+- Investigate the `requestParameters` field to gather details about the VPC and hosted zone involved, including VPC ID and hosted zone ID, to understand the scope of the association.
+- Cross-reference the VPC ID with your organization's inventory to determine if the VPC is recognized and authorized to be associated with the hosted zone.
+- Use Osquery to query AWS metadata and configuration for further context. For example, run the following Osquery query to list all VPCs associated with a specific hosted zone: `SELECT * FROM aws_route53_vpc_associations WHERE hosted_zone_id = '<hosted_zone_id>';`.
+- Review recent changes in IAM policies or roles that might have granted new permissions related to Route53 or VPC associations, focusing on any modifications around the time of the event.
+- Analyze historical CloudTrail logs for any previous `AssociateVPCWithHostedZone` events to identify patterns or repeated unauthorized associations.
+- Consult with relevant stakeholders or teams to verify if the association was part of a planned change or deployment, ensuring alignment with organizational processes and approvals.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular operations by network administrators to associate VPCs with private hosted zones for legitimate purposes can trigger this rule. To manage this, create exceptions for known administrative accounts or specific time windows when these tasks are expected.
+- Automated infrastructure changes: Infrastructure as Code (IaC) tools like Terraform or AWS CloudFormation may automatically associate VPCs with hosted zones as part of deployment processes. Users can handle these by identifying and excluding specific automation accounts or tags associated with these tools.
+- Development and testing environments: Frequent changes in development or testing environments might lead to multiple VPC associations with hosted zones. Consider excluding specific environments or using tags to differentiate between production and non-production activities.
+- Multi-account setups: In organizations with multiple AWS accounts, cross-account VPC associations might be legitimate. Users should maintain a list of authorized accounts and exclude these from triggering alerts.
+- Scheduled maintenance: Planned maintenance activities might involve associating VPCs with hosted zones. Users can manage this by setting up maintenance windows and excluding activities during these periods from being flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC to prevent further unauthorized access or traffic interception.
+- Review AWS CloudTrail logs to identify the source and time of the unauthorized VPC association and gather evidence for further investigation.
+- Verify the IAM roles and permissions to ensure that only authorized users have the ability to associate VPCs with Route53 private hosted zones.
+- Revoke any unauthorized access or credentials that may have been used to perform the VPC association.
+- Conduct a thorough review of all VPC associations with Route53 private hosted zones to ensure no other unauthorized associations exist.
+- Escalate the incident to the security operations team for a deeper investigation into potential persistence mechanisms or account manipulation tactics used by the adversary.
+- Implement enhanced logging and monitoring policies to detect future unauthorized changes to Route53 configurations, leveraging AWS CloudTrail and AWS Config.
+- Integrate AWS GuardDuty and other threat detection services to provide real-time alerts on suspicious activities related to DNS and VPC configurations.
+- Restore the system to its operational state by reconfiguring the Route53 private hosted zone associations to only include authorized VPCs.
+- Apply hardening measures such as multi-factor authentication (MFA) for all IAM users and regular audits of access permissions to prevent future unauthorized access.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html"]
diff --git a/rules/integrations/aws/persistence_route_table_created.toml b/rules/integrations/aws/persistence_route_table_created.toml
index c254309c058..c8f43c8b2c1 100644
--- a/rules/integrations/aws/persistence_route_table_created.toml
+++ b/rules/integrations/aws/persistence_route_table_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,51 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route Table Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Route Table Created
+
+AWS Route Tables are crucial for directing network traffic within AWS environments, defining how packets are routed between subnets and external networks. Adversaries may exploit this by creating unauthorized routes to intercept or redirect traffic, potentially leading to data exfiltration or service disruption. The detection rule monitors successful creation events of route tables, flagging potential misuse by identifying unexpected or suspicious activity patterns.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `ec2.amazonaws.com`, ensuring the alert is relevant to AWS Route Table creation.
+- Verify the event action is either `CreateRoute` or `CreateRouteTable` and the event outcome is `success` to confirm the alert is triggered by a successful route table creation.
+- Identify the AWS account and region where the route table was created to understand the scope and potential impact of the event.
+- Check the identity information (user or role) associated with the event to determine if the action was performed by an expected or authorized entity.
+- Investigate the source IP address and user agent from which the request originated to identify any unusual access patterns or locations.
+- Review CloudTrail logs for additional context around the time of the event to identify any related or suspicious activities.
+- Use Osquery to gather more information about the AWS environment. For example, run the following query to list all route tables in the account: `SELECT * FROM aws_ec2_route_tables;`
+- Analyze the route table configuration to identify any unauthorized or suspicious routes that could indicate malicious intent.
+- Cross-reference the route table creation event with IAM policies and permissions to ensure the user or role had legitimate access to perform the action.
+- Consult with the relevant AWS account owner or administrator to verify if the route table creation was part of an expected change or deployment.
+
+### False positive analysis
+
+- Routine infrastructure changes: Regular updates or expansions in AWS environments may involve creating new route tables, which can trigger the detection rule. Users should review change management logs to verify if the route table creation aligns with planned activities.
+- Automated deployment tools: Tools like AWS CloudFormation, Terraform, or other infrastructure-as-code solutions may automatically create route tables as part of their deployment processes. Users can create exceptions for specific IAM roles or user accounts associated with these tools to reduce noise.
+- Testing and development environments: Route tables created in non-production environments for testing purposes might be flagged. Users can exclude specific AWS accounts or regions dedicated to development and testing to minimize false positives.
+- Third-party integrations: Some third-party services or applications may require the creation of route tables for integration purposes. Users should identify and whitelist these services to prevent unnecessary alerts.
+- Temporary configurations: Short-term projects or experiments might necessitate the creation of route tables. Users can implement time-based exceptions to account for these temporary changes, ensuring they are automatically removed after a set period.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to verify the source and context of the route table creation event, ensuring it aligns with expected administrative actions.
+- Identify and isolate any unauthorized route tables by removing or disabling them to prevent potential data exfiltration or service disruption.
+- Conduct a thorough investigation to determine if any unauthorized access or changes have been made to other network configurations or resources.
+- Escalate the incident to the security operations team if the activity is confirmed to be malicious or if there is evidence of a broader compromise.
+- Implement AWS Identity and Access Management (IAM) policies to restrict route table creation permissions to only necessary personnel or roles.
+- Enable detailed logging and monitoring for AWS network activities, including route table changes, to enhance visibility and facilitate future investigations.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious network configuration changes.
+- Review and update the incident response plan to include specific procedures for handling unauthorized network configuration changes.
+- Restore the system to its operational state by verifying that all network routes are correctly configured and that no unauthorized routes remain.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as network segmentation and enhanced access controls, to prevent future incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
index 8829dc1659b..77cc617cb1e 100644
--- a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
+++ b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,47 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route Table Modified or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Route Table Modified or Deleted
+
+AWS Route Tables direct network traffic within a VPC, crucial for maintaining secure and efficient communication. Adversaries may alter or delete route tables to reroute traffic, disrupt services, or exfiltrate data. The detection rule monitors successful modifications or deletions of route tables, identifying potential unauthorized changes by analyzing specific AWS CloudTrail events related to EC2 actions.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the specific `event.action` that triggered the alert, focusing on actions like `ReplaceRoute`, `ReplaceRouteTableAssociation`, `DeleteRouteTable`, `DeleteRoute`, or `DisassociateRouteTable`.
+- Examine the `event.outcome` field to confirm the success of the action and ensure that the alert is not a false positive.
+- Identify the `user.identity` field in the CloudTrail logs to determine which IAM user or role performed the action, and verify if this user is authorized to make such changes.
+- Check the `sourceIPAddress` field to see where the request originated from, and assess if this IP address is expected or known within your network.
+- Investigate the `event.time` to understand when the modification or deletion occurred and correlate it with any other suspicious activities or alerts around the same time.
+- Use the `aws.region` field to determine the region where the change was made, and verify if this aligns with your organization's standard operations.
+- Query the AWS Config service to review the historical configuration of the affected route table and identify any previous changes or patterns.
+- Utilize Osquery to gather additional context by running a query such as: `SELECT * FROM aws_vpc_route_tables WHERE route_table_id = '<affected_route_table_id>';` to retrieve current route table configurations and compare them with expected settings.
+- Cross-reference the affected route table with any associated VPCs, subnets, or network interfaces to assess the potential impact on your network architecture.
+- Review any recent IAM policy changes or access key usage for the identified user to ensure there are no signs of credential compromise or privilege escalation.
+
+### False positive analysis
+
+- Routine infrastructure changes by authorized personnel can trigger alerts, such as scheduled updates or maintenance activities, which are not malicious. - Automated processes or scripts that modify route tables for scaling or failover purposes may also result in false positives. - To manage these, users can create exceptions for known IP addresses or IAM roles that regularly perform these actions. - Implementing a change management process and documenting expected modifications can help differentiate between legitimate and suspicious activities. - Regularly review and update the list of exceptions to ensure they align with current operational practices and security policies.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC to prevent further unauthorized access or data exfiltration.
+- Review AWS CloudTrail logs to identify the source and scope of the unauthorized changes to the route tables.
+- Verify the integrity of other network configurations within the VPC to ensure no additional unauthorized modifications have been made.
+- Restore the route tables to their last known good configuration using backups or documented configurations.
+- Implement AWS Identity and Access Management (IAM) policies to restrict permissions for modifying route tables to only essential personnel.
+- Enable detailed logging and monitoring for all VPC and route table changes to ensure real-time detection of unauthorized activities.
+- Conduct a security review of the affected AWS account to identify and remediate any other potential vulnerabilities or misconfigurations.
+- Escalate the incident to the security operations team for further investigation and to determine if the incident is part of a larger attack.
+- Update incident response plans and playbooks to include lessons learned from the incident and improve future response efforts.
+- Consider implementing additional security measures such as AWS Config rules and GuardDuty to enhance detection and prevention of unauthorized network changes.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
index c4dcc60e1a5..6b80a7fbe29 100644
--- a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
+++ b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/10/25"
+updated_date = "2025/01/08"
 
 
 [rule]
@@ -18,7 +18,50 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS AssumeRole with New MFA Device"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS STS AssumeRole with New MFA Device
+
+AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse by monitoring specific AWS CloudTrail events and parameters.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user and role involved in the AssumeRole event, focusing on the `user.id` and `aws.cloudtrail.flattened.request_parameters.serialNumber` fields.
+- Verify the legitimacy of the new MFA device by checking the AWS IAM console for recent changes or additions to MFA devices associated with the user.
+- Cross-reference the `event.provider` and `event.action` fields to confirm the type of AssumeRole action taken and ensure it aligns with expected user behavior.
+- Analyze the `event.outcome` field to ensure the role assumption was successful and not part of a failed attempt pattern.
+- Investigate the source IP address and geolocation from which the AssumeRole request originated to identify any anomalies or unexpected locations.
+- Check the AWS CloudTrail logs for any preceding or subsequent suspicious activities related to the same user or role, such as changes in permissions or unusual API calls.
+- Use Osquery to gather additional context on the user's activity on their local machine. For example, run a query to list recent AWS CLI commands executed: `SELECT * FROM shell_history WHERE command LIKE '%aws%' AND user = '<username>';`.
+- Review the user's recent login history and access patterns to determine if there are any deviations from their normal behavior.
+- Consult with the user or their manager to verify if the new MFA device was legitimately added and if the role assumption was expected as part of their duties.
+- Document all findings and observations in the investigation report, highlighting any indicators of compromise or benign explanations for the alert.
+
+### False positive analysis
+
+- Users frequently adding new MFA devices for legitimate reasons, such as device upgrades or replacements, can trigger false positives. To manage this, maintain a list of known device changes and exclude these from alerts.
+- Organizational policy changes that require users to update or rotate MFA devices can result in multiple role assumptions with new devices. Implement a temporary exception during the policy change period to reduce noise.
+- Automated processes or scripts that involve role assumptions with new MFA devices for testing or deployment purposes may be flagged. Identify and whitelist these processes to prevent unnecessary alerts.
+- Shared accounts or roles used by multiple team members might show new MFA devices as different users authenticate. Consider monitoring these accounts separately and establish a baseline of expected behavior to differentiate between legitimate and suspicious activity.
+
+### Response and remediation
+
+- Verify the legitimacy of the new MFA device by contacting the user or reviewing the change request logs to ensure it was an authorized action.
+- Temporarily disable the assumed role or the associated user account if the new MFA device is deemed suspicious or unauthorized.
+- Review AWS CloudTrail logs for any unusual activity associated with the user or role, focusing on actions taken after the role assumption.
+- Conduct a thorough investigation to determine if any unauthorized changes or data access occurred during the session with the temporary credentials.
+- Escalate the incident to the security operations team if unauthorized access or malicious activity is confirmed, following the organization's incident response plan.
+- Implement additional logging and monitoring for AWS STS and MFA-related activities to detect similar incidents in the future.
+- Review and update IAM policies to ensure that only necessary permissions are granted and consider implementing least privilege principles.
+- Educate users on the importance of securing MFA devices and recognizing phishing attempts that could lead to unauthorized MFA registration.
+- Restore any unauthorized changes made during the incident to return the system to its operational state, ensuring data integrity and security.
+- Consider implementing additional security measures such as conditional access policies or more frequent reviews of MFA device registrations to enhance overall security posture.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
index 7d54a01401c..77e834aea16 100644
--- a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/16"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -19,7 +19,50 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM SAML Provider Updated"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS IAM SAML Provider Updated
+
+AWS IAM SAML providers facilitate federated access, allowing users to authenticate via external identity providers. Adversaries may exploit this by updating SAML providers to gain unauthorized access or escalate privileges. The detection rule monitors successful updates to SAML providers, flagging potential privilege escalation attempts by correlating specific AWS CloudTrail events.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the user or role that performed the `UpdateSAMLProvider` action by examining the `userIdentity` field.
+- Check the `eventTime` field in the CloudTrail logs to determine when the update occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the `sourceIPAddress` field to identify the IP address from which the update was made and determine if it is a known or trusted source.
+- Examine the `userAgent` field to understand the application or service used to perform the update, which might provide additional context about the activity.
+- Verify the `requestParameters` field to see what specific changes were made to the SAML provider, such as metadata updates or certificate changes.
+- Cross-reference the `awsRegion` field to ensure the activity aligns with expected geographic locations for your AWS operations.
+- Use Osquery to gather additional context on the AWS environment by running a query like: `SELECT * FROM aws_iam_saml_providers WHERE name = '<SAML Provider Name>'` to retrieve details about the current configuration of the SAML provider.
+- Check for any recent IAM policy changes or role modifications that might be related to the SAML provider update, which could indicate a broader privilege escalation attempt.
+- Review any recent login attempts or access patterns for the user or role identified in the `userIdentity` field to detect any anomalies or unauthorized access.
+- Consult with the team responsible for identity and access management to confirm whether the SAML provider update was expected and authorized, and gather any additional context they might have.
+
+### False positive analysis
+
+- Routine administrative updates: Regular updates to SAML providers by authorized personnel for maintenance or configuration changes can trigger this rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or tools: Organizations may use automated tools to update SAML providers as part of their identity management processes. Identify these tools and exclude their activity from triggering alerts by whitelisting their associated accounts or IP addresses.
+- Third-party integrations: Some third-party services may require updates to SAML providers for integration purposes. Document these services and exclude their known update patterns to prevent false positives.
+- Frequent legitimate changes: In dynamic environments where SAML provider updates are common, establish a baseline of normal activity and adjust the detection thresholds or alerting criteria to reduce noise from expected changes.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account to prevent further unauthorized access by disabling the updated SAML provider.
+- Review AWS CloudTrail logs to identify any unauthorized changes or suspicious activities associated with the SAML provider update.
+- Verify the identity and permissions of the user who performed the update to ensure it aligns with expected behavior and access policies.
+- Revert any unauthorized changes to the SAML provider configuration to restore the system to its previous operational state.
+- Conduct a thorough investigation to determine if any other AWS resources or accounts have been compromised.
+- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization.
+- Implement enhanced logging and monitoring for AWS IAM activities, focusing on SAML provider updates and other critical changes.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to improve real-time detection and alerting capabilities.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized users can modify SAML providers.
+- Conduct regular security awareness training for users on the risks associated with federated access and the importance of maintaining secure configurations.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
index 7bde75f679e..3a4afc7a1ea 100644
--- a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,51 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS GetSessionToken Abuse"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS STS GetSessionToken Abuse
+
+AWS Security Token Service (STS) provides temporary credentials for AWS resources. Adversaries may exploit the GetSessionToken API to generate tokens, enabling lateral movement and privilege escalation within an environment. The detection rule identifies successful GetSessionToken requests by IAM users, signaling potential misuse by attackers to gain unauthorized access or elevate privileges.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `event.dataset:aws.cloudtrail`, `event.provider:sts.amazonaws.com`, `event.action:GetSessionToken`, `aws.cloudtrail.user_identity.type:IAMUser`, and `event.outcome:success` to ensure the alert is valid and matches the detection rule criteria.
+- Identify the IAM user associated with the GetSessionToken request by examining the `aws.cloudtrail.user_identity.arn` field to determine if the user is expected to perform such actions.
+- Check the `aws.cloudtrail.sourceIPAddress` field to verify the source IP address of the request and determine if it is from a known or expected location.
+- Investigate the `aws.cloudtrail.user_agent` field to identify the client or tool used to make the request, which may provide insights into whether the request was automated or manual.
+- Analyze the `aws.cloudtrail.recipientAccountId` field to confirm the account targeted by the GetSessionToken request and assess if it aligns with normal operations.
+- Review historical CloudTrail logs for the identified IAM user to detect any unusual patterns or deviations in behavior leading up to the GetSessionToken request.
+- Use Osquery to gather additional context on the system from which the request originated. For example, run the following query to list recent AWS CLI commands executed on the host: `SELECT * FROM shell_history WHERE command LIKE '%aws%' ORDER BY time DESC LIMIT 10;`.
+- Cross-reference the GetSessionToken request with other AWS CloudTrail events to identify any subsequent actions taken using the temporary credentials, such as accessing sensitive resources or modifying configurations.
+- Investigate any recent changes to IAM policies or roles associated with the IAM user to determine if permissions were altered to facilitate the GetSessionToken request.
+- Collaborate with the account owner or relevant stakeholders to verify if the GetSessionToken request was authorized and part of legitimate activities, or if it indicates potential misuse.
+
+### False positive analysis
+
+- Routine administrative tasks: IAM users may frequently use GetSessionToken for legitimate purposes such as accessing AWS resources temporarily. These actions can be mistaken for malicious activity. To manage this, identify and document regular patterns of GetSessionToken usage by trusted users and exclude these from alerts.
+- Automated scripts and applications: Some applications or scripts might be configured to use GetSessionToken for temporary access. These should be reviewed and, if deemed non-threatening, added to an exception list to prevent false alerts.
+- Third-party integrations: External services integrated with AWS may use GetSessionToken as part of their normal operation. Verify these integrations and exclude their activity from detection rules if they are legitimate and secure.
+- Development and testing environments: Developers might use GetSessionToken during testing or development phases. Monitor these environments separately and consider excluding known development accounts from alerts to reduce noise.
+- Cross-account access: In environments with multiple AWS accounts, GetSessionToken might be used for cross-account access. Ensure that these actions are part of approved workflows and exclude them if they are verified as non-malicious.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the suspicious GetSessionToken request to prevent further unauthorized access.
+- Isolate the affected IAM user account by disabling it or applying a restrictive policy to limit its permissions until the investigation is complete.
+- Conduct a thorough review of CloudTrail logs to identify any anomalous activities or patterns associated with the compromised credentials, focusing on lateral movement and privilege escalation attempts.
+- Cross-reference the IAM user's activities with known MITRE ATT&CK techniques, such as T1548, to understand the potential impact and scope of the attack.
+- Notify the security operations team and relevant stakeholders about the incident and escalate to higher management if the threat level is deemed critical.
+- Implement enhanced logging and monitoring for AWS STS and IAM activities to detect similar suspicious behavior in the future, ensuring that logs are retained for an adequate period.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious GetSessionToken activities.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring that users have only the permissions necessary for their roles.
+- Conduct a security awareness session for the team to highlight the risks associated with AWS STS and the importance of monitoring and securing temporary credentials.
+- After confirming the environment is secure, restore normal operations by re-enabling the IAM user account with appropriate permissions and continue to monitor for any further suspicious activities.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html"]
diff --git a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
index 8fad43bd2ff..e4531d2ab37 100644
--- a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/23"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/10/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ from = "now-6m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS STS Role Chaining"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS STS Role Chaining
+
+AWS STS (Security Token Service) allows temporary, limited-privilege credentials for AWS resources. Role chaining involves using one temporary role to assume another, potentially escalating privileges if the second role has more access. Adversaries exploit this for privilege escalation or persistence. The detection rule identifies such activity by monitoring specific API calls and access patterns within a single account, focusing on temporary credentials to spot potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `aws.cloudtrail.user_identity.arn` to identify the user or service that initiated the role chaining.
+- Examine the `aws.cloudtrail.user_identity.access_key_id` to confirm it begins with "ASIA", indicating the use of temporary credentials.
+- Check the `cloud.region` field to determine the geographical location of the activity and assess if it aligns with expected operations.
+- Analyze the `aws.cloudtrail.resources.account_id` and `aws.cloudtrail.recipient_account_id` to ensure the activity is confined within a single account, ruling out cross-account role assumptions.
+- Investigate the history of the `aws.cloudtrail.user_identity.arn` to identify any unusual patterns or recent changes in behavior.
+- Use Osquery to gather additional context on the system where the role chaining was initiated. Example query: `SELECT * FROM aws_sts WHERE access_key_id LIKE 'ASIA%' AND arn = '<user_arn>';`
+- Correlate the `AssumeRole` events with other logs to identify any subsequent actions taken using the assumed role, focusing on sensitive operations.
+- Review IAM policies associated with the roles involved to determine if the permissions granted could lead to privilege escalation.
+- Check for any recent changes to IAM roles or policies that might have inadvertently allowed for increased privileges.
+- Consult with relevant stakeholders or system owners to verify if the role chaining activity was expected or authorized as part of normal operations.
+
+### False positive analysis
+
+- Role chaining within a single account for legitimate operational purposes can trigger false positives. This often occurs in environments where automated processes or scripts frequently assume roles for routine tasks.
+- Cross-account role assumptions are common in multi-account AWS environments, but this rule specifically filters them out to reduce false positives. However, similar patterns within a single account can still be flagged.
+- Users can manage these false positives by creating exceptions for known, benign role chaining activities. This can be done by maintaining a list of trusted role ARNs or access key IDs that are known to perform legitimate role chaining.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, and monitor for any changes in access patterns that might indicate misuse.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the suspicious AssumeRole activity to prevent further unauthorized access.
+- Conduct a thorough investigation of the AWS CloudTrail logs to identify the source and scope of the role chaining activity, focusing on the user identity and access patterns.
+- Verify the permissions of the roles involved in the chaining to ensure they do not exceed the intended access levels and adjust policies to adhere to the principle of least privilege.
+- Escalate the incident to the security operations team if the role chaining activity is linked to a known threat actor or if it involves sensitive resources.
+- Implement enhanced logging and monitoring for AWS STS and IAM activities to detect similar patterns in the future, ensuring that all AssumeRole actions are logged and reviewed.
+- Integrate AWS CloudTrail logs with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious role chaining activities.
+- Review and update the AWS IAM policies and roles to include multi-factor authentication (MFA) for sensitive operations to reduce the risk of unauthorized access.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Restore any affected systems or services to their operational state by rolling back unauthorized changes and verifying the integrity of critical resources.
+- Educate and train staff on the risks associated with role chaining and the importance of adhering to security best practices to prevent future incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
index b3ffe646b7d..3c846f3c55d 100644
--- a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
+++ b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Event Hub Authorization Rule Created or Updated"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Event Hub Authorization Rule Created or Updated
+
+Azure Event Hub Authorization Rules manage access to Event Hubs, using cryptographic keys to define permissions. Adversaries may exploit these rules to gain unauthorized access, potentially extracting sensitive data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `azure.activitylogs` and the operation name is `MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE` with a successful outcome.
+- Identify the user or service principal that performed the operation by examining the `azure.activitylogs.caller` field.
+- Check the timestamp of the event to determine when the authorization rule was created or updated.
+- Investigate the specific Event Hub namespace affected by reviewing the `azure.activitylogs.resource_id` field to understand the scope of the change.
+- Correlate the event with other recent activities by the same user or service principal to identify any suspicious patterns or anomalies.
+- Examine the `azure.activitylogs.correlation_id` to trace related operations and understand the broader context of the activity.
+- Use Osquery to query Azure logs for additional context, such as: `SELECT * FROM azure_activitylogs WHERE operation_name = 'MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE' AND outcome = 'Success';`
+- Review any associated network or application logs to identify potential data exfiltration or unauthorized access attempts following the rule change.
+- Check for any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to the user or service principal involved.
+- Consult with the relevant application or infrastructure teams to verify if the change was expected and authorized, and gather any additional context or documentation related to the change.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or creations of authorization rules by system administrators or automated scripts can trigger alerts. To manage these, users can create exceptions for known administrative accounts or scheduled tasks that frequently perform these operations.
+- Deployment and configuration changes: During the deployment of new applications or updates to existing ones, authorization rules may be created or modified as part of the setup process. Users can exclude these events by identifying and filtering out activities associated with specific deployment tools or processes.
+- Testing and development environments: In non-production environments, developers may frequently create or update authorization rules for testing purposes. Users can handle these by setting up separate monitoring rules or excluding specific environments from triggering alerts.
+- Third-party integrations: Some third-party services or integrations may require the creation or modification of authorization rules. Users should document and exclude these known integrations to prevent false positives.
+- Service health checks: Automated health checks or monitoring services might create or update authorization rules as part of their operation. Users can identify these services and exclude their activities from alerting.
+
+### Response and remediation
+
+- Immediately review the Azure Activity Logs to confirm the creation or modification of the Event Hub Authorization Rule and identify the user or service principal responsible for the change.
+- Contain the potential threat by revoking the modified or newly created authorization rule if it is deemed unauthorized or suspicious.
+- Investigate the source of the change by checking the associated IP addresses, user agents, and timestamps to determine if the activity aligns with expected behavior.
+- Escalate the incident to the security operations team if the activity is confirmed to be unauthorized or if there is evidence of data exfiltration.
+- Implement additional logging and monitoring for Azure Event Hubs to capture detailed access and modification events, ensuring that all changes are auditable.
+- Review and update access policies to ensure that only necessary permissions are granted, and consider using Azure Managed Identities to reduce reliance on cryptographic keys.
+- Conduct a security review of all Event Hub Authorization Rules to ensure compliance with the principle of least privilege.
+- Restore the system to its operational state by reapplying any necessary authorization rules that were revoked during containment, ensuring they are configured securely.
+- Enhance future investigations by integrating Azure Security Center and Azure Sentinel for advanced threat detection and response capabilities.
+- Implement hardening measures such as regular audits of authorization rules, enforcing multi-factor authentication, and using Azure Policy to enforce security best practices across the environment.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-shared-access-signature"]
diff --git a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
index 92c23e47a2b..fe681292190 100644
--- a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
+++ b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,7 +24,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Full Network Packet Capture Detected"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Full Network Packet Capture Detected
+
+Azure Network Watcher's packet capture feature allows for detailed inspection of network traffic, aiding in diagnostics and performance monitoring. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to intercept credentials or other confidential information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure operations and successful outcomes, alerting analysts to potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific operation name and outcome, focusing on `azure.activitylogs.operation_name` and `event.outcome` fields to confirm the type of packet capture activity detected.
+- Check the timestamp of the alert to determine when the packet capture was initiated and correlate it with any other suspicious activities in the same timeframe.
+- Identify the user or service principal associated with the packet capture operation by examining the `azure.activitylogs.caller` field to determine if the activity aligns with expected behavior.
+- Investigate the source IP address and location from which the packet capture was initiated using the `azure.activitylogs.callerIpAddress` field to identify any anomalies or unauthorized access.
+- Analyze the resource group and network interface involved in the packet capture by reviewing the `azure.activitylogs.resource` field to understand the scope and potential impact of the capture.
+- Cross-reference the packet capture activity with any recent changes in network configurations or deployments to identify if the capture was part of a legitimate change or deployment process.
+- Utilize Osquery to gather additional context on the systems involved. For example, run an Osquery query to list recent network connections on the affected virtual machines: `SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious IP>';`.
+- Check for any other alerts or logs related to network sniffing or credential access attempts in the same environment to identify potential patterns or coordinated attacks.
+- Review access logs and permissions for the Azure Network Watcher to ensure that only authorized personnel have the ability to initiate packet captures.
+- Consult with the network and security teams to verify if the packet capture aligns with any ongoing troubleshooting or monitoring activities, ensuring that it was not a sanctioned operation.
+
+### False positive analysis
+
+- Routine network diagnostics: Regularly scheduled packet captures for legitimate network diagnostics or performance monitoring can trigger this detection. Users can manage these by creating exceptions for known diagnostic operations or specific time windows when these activities are expected.
+- Security audits: Organizations conducting security audits may intentionally perform packet captures to assess network security. To handle these, users can whitelist specific audit-related operations or IP addresses involved in the audit process.
+- Automated monitoring tools: Some automated tools may initiate packet captures as part of their monitoring processes. Users should identify these tools and exclude their activities from triggering alerts by specifying their operation names or associated user accounts.
+- Testing environments: In testing or development environments, packet captures might be used frequently for troubleshooting. Users can exclude these environments by filtering based on resource groups or tags associated with non-production environments.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure resources to prevent further data exposure or unauthorized access.
+- Review Azure activity logs to identify the source and scope of the packet capture activity, focusing on the specific operations flagged by the detection rule.
+- Verify the legitimacy of the packet capture request by contacting the resource owner or administrator to confirm if the activity was authorized.
+- If unauthorized, revoke any compromised credentials and enforce a password reset for affected accounts.
+- Escalate the incident to the security operations team for further investigation and to determine if any data was exfiltrated.
+- Implement network segmentation to limit the exposure of sensitive data and reduce the risk of unauthorized packet capture.
+- Enhance logging and monitoring by enabling Azure Security Center and integrating with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
+- Conduct a thorough review of access controls and permissions to ensure that only authorized personnel can initiate packet captures.
+- Restore affected systems to their operational state by applying any necessary patches or updates and verifying system integrity.
+- Implement hardening measures such as encrypting internal traffic and using secure protocols to mitigate the risk of network sniffing in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"]
diff --git a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
index 65b062f0ebf..02211441084 100644
--- a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
+++ b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/06/26"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,49 @@ query = '''
         azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e
         and azure.activitylogs.properties.authentication_protocol:deviceCode)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Entra ID Device Code Auth with Broker Client
+
+Entra ID Device Code Authentication facilitates seamless access to Azure resources by leveraging device-based controls and Primary Refresh Tokens (PRTs). Adversaries exploit PRTs to bypass multi-factor authentication, gaining unauthorized access. The detection rule identifies suspicious sign-ins by monitoring device code authentications linked to a specific broker client application, flagging potential misuse of PRTs.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e) in the sign-in logs, focusing on the `azure.signinlogs.properties.conditional_access_audiences.application_id` field.
+- Examine the `event.dataset` field to determine whether the alert originated from `azure.activitylogs` or `azure.signinlogs`, as this will guide the context of the investigation.
+- Analyze the `azure.signinlogs.properties.authentication_protocol` field to verify that the authentication protocol used was `deviceCode`, confirming the method of access.
+- Check the `event.outcome` field to ensure the sign-in attempt was successful, which is crucial for identifying unauthorized access.
+- Investigate the user account associated with the alert to determine if there are any known security incidents or unusual activities linked to this account.
+- Use Osquery to gather additional context on the device involved in the authentication attempt. For example, run a query to list all recent logins on the device: `SELECT * FROM logins WHERE user = '<username>';`.
+- Review the `azure.activitylogs.properties.appId` field in the activity logs to identify any other applications accessed using the same broker client application ID.
+- Correlate the sign-in event with other security logs to identify any concurrent suspicious activities, such as changes in user permissions or unusual data access patterns.
+- Investigate the IP address and location associated with the sign-in attempt to determine if it aligns with the user's typical access patterns or if it appears suspicious.
+- Check for any recent changes in Conditional Access policies that might have inadvertently allowed the bypass of multi-factor authentication, focusing on policies related to device-based controls.
+
+### False positive analysis
+
+- Legitimate device code authentications by trusted applications or services may trigger the rule if they use the same broker client application ID. Users should verify the source of the authentication and assess whether it aligns with expected behavior.
+- Frequent sign-ins from known and secure devices using device code authentication might be flagged. To manage this, users can create exceptions for specific device IDs or IP addresses that are consistently verified as non-threatening.
+- Automated processes or scripts that utilize device code authentication for legitimate purposes could be misidentified as suspicious. Users should document and exclude these processes by adding them to an allowlist based on their application ID or other identifying attributes.
+- Organizations with a high volume of device code authentications due to legitimate business operations may experience numerous alerts. Implementing a baseline of normal activity and adjusting the rule's sensitivity can help reduce false positives.
+- Collaboration tools or third-party applications integrated with Azure that use device code authentication might be mistakenly flagged. Users should review these integrations and, if deemed safe, exclude them from the rule by specifying their application IDs.
+
+### Response and remediation
+
+- Immediately isolate the affected device from the network to prevent further unauthorized access.
+- Revoke all active Primary Refresh Tokens (PRTs) associated with the compromised account to disrupt the adversary's access.
+- Conduct a thorough investigation of the sign-in logs and activity logs to identify any unauthorized access or actions taken by the adversary.
+- Reset passwords and enforce multi-factor authentication (MFA) for all accounts involved in the incident to enhance security.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems or accounts have been compromised.
+- Implement enhanced logging policies to capture detailed authentication and access events, ensuring comprehensive monitoring of device code authentications.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities in real-time.
+- Restore the affected systems to their operational state by applying the latest security patches and updates, and verifying the integrity of critical files and configurations.
+- Conduct a post-incident review to identify gaps in security controls and update the incident response plan accordingly.
+- Implement hardening measures such as restricting device code authentication to trusted devices and applications, and regularly reviewing and updating Conditional Access policies."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
index 32a179c5ecd..e57c6cdc716 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,51 @@ language = "esql"
 interval = "10m"
 license = "Elastic License v2"
 name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts"
-note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
+
+Azure Entra, part of Microsoft's identity and access management suite, secures Microsoft 365 accounts by managing sign-ins and authentication. Adversaries may exploit this by attempting numerous failed logins to guess passwords, aiming to gain unauthorized access to services like Exchange or Teams. The detection rule identifies such brute-force attempts by analyzing sign-in logs for high volumes of failed logins or diverse login sources within a short timeframe, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the `target_time_window` to determine the specific 30-minute period during which the brute-force attempts occurred, providing a focused timeframe for further analysis.
+- Examine the `azure.signinlogs.properties.user_principal_name` to identify the specific user accounts targeted by the brute-force attempts, allowing for a user-centric investigation.
+- Analyze the `source.ip` field to identify the IP addresses involved in the failed login attempts, which can help in determining if the attempts are coming from known malicious sources or unusual locations.
+- Check the `azure.signinlogs.properties.resource_display_name` to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted, providing insight into the attacker's potential objectives.
+- Investigate the `event.outcome` to confirm the nature of the failed attempts and cross-reference with known error codes from the Azure documentation to understand the specific reasons for failure.
+- Utilize Osquery to gather additional context on the affected systems. For example, run a query to list recent login attempts on the endpoint: `SELECT * FROM users WHERE username = '<target_user>' AND last_login > '<target_time_window_start>' AND last_login < '<target_time_window_end>';`
+- Correlate the `login_source_count` and `failed_login_count` with historical data to determine if this is an isolated incident or part of a larger pattern of attacks against the organization.
+- Investigate any unusual patterns or anomalies in the `event.dataset` and `event.category` fields to identify if the attack is leveraging specific authentication methods or protocols.
+- Cross-reference the identified `source.ip` addresses with threat intelligence feeds to check for any known associations with malicious activity.
+- Review any additional logs or alerts from other security tools that may provide context or corroborate the findings from the Azure Entra sign-in logs, such as firewall logs or endpoint detection and response (EDR) alerts.
+
+### False positive analysis
+
+- High-volume legitimate access: Users with roles that require frequent access to multiple Microsoft 365 services, such as IT administrators or support staff, may trigger false positives due to their high number of login attempts. To manage this, create exceptions for known user accounts or IP addresses associated with these roles.
+- Automated scripts or applications: Some organizations use automated scripts or applications that perform regular sign-ins to Microsoft 365 services for maintenance or data retrieval. These can be mistaken for brute-force attempts. Identify and whitelist these scripts or applications by their user agent or IP address.
+- Shared IP addresses: Users accessing Microsoft 365 services from shared networks, such as corporate VPNs or educational institutions, may appear to have multiple login sources. To handle this, exclude known shared IP ranges from the rule.
+- Frequent password changes: Organizations with policies that enforce regular password changes may see an increase in failed login attempts as users adjust to new credentials. Consider extending the monitoring window or adjusting the threshold for failed attempts during these periods.
+- Third-party integrations: Integrations with third-party services that require frequent authentication to Microsoft 365 can generate numerous failed attempts if not configured correctly. Review and adjust the settings of these integrations to ensure they are not flagged as threats.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.
+- Conduct a thorough investigation of the sign-in logs to identify the source IP addresses and determine if they are associated with known malicious activity.
+- Reset passwords for the compromised accounts and enforce multi-factor authentication (MFA) to enhance security.
+- Notify the affected users and relevant stakeholders about the incident and provide guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other accounts or systems are affected.
+- Implement conditional access policies to restrict access based on location, device compliance, and risk level to prevent future brute-force attempts.
+- Review and update logging policies to ensure comprehensive capture of authentication events and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply security patches and updates to all systems and applications to mitigate vulnerabilities that could be exploited in similar attacks.
+- Educate users on best practices for password management and the importance of using unique, strong passwords for different accounts.
+
+This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
 references = [
     "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
     "https://github.com/0xZDH/o365spray"
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
index 0517b3b14f8..35e490274d8 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,51 @@ language = "esql"
 interval = "10m"
 license = "Elastic License v2"
 name = "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source"
-note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source
+
+Azure Entra, part of Microsoft's identity and access management suite, secures access to Microsoft 365 services. Adversaries may exploit this by attempting numerous failed logins to guess user credentials, aiming to breach accounts. The detection rule identifies such brute-force attempts by flagging multiple failed logins from a single IP within a short timeframe, focusing on patterns indicative of unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand the source IP and the number of distinct failed login attempts, focusing on the `source.ip` and `target_count` fields.
+- Cross-reference the `source.ip` with known threat intelligence feeds to determine if the IP is associated with any known malicious activity.
+- Analyze the `azure.signinlogs.properties.user_principal_name` field to identify which user accounts were targeted and assess if these accounts have any commonalities or are high-value targets.
+- Check the `azure.signinlogs.properties.resource_display_name` to determine which Microsoft 365 services were targeted, such as Exchange, SharePoint, or Teams, to understand the potential impact.
+- Investigate the `azure.signinlogs.properties.status.error_code` to identify specific error codes associated with the failed login attempts, which may provide insights into the attack method.
+- Use Osquery to gather additional context on the affected user accounts. For example, run a query to list recent login activities for the targeted user accounts: `SELECT * FROM azure_signin_logs WHERE user_principal_name IN ('user1@example.com', 'user2@example.com') AND outcome != 'success';`
+- Examine historical login patterns for the affected user accounts to determine if the failed attempts are anomalous compared to typical behavior.
+- Check for any successful logins from the same `source.ip` around the time of the failed attempts to assess if the attacker eventually gained access.
+- Review any recent changes to the user accounts or permissions that might have been made prior to the alert, which could indicate preparatory actions by the attacker.
+- Collaborate with the network team to analyze network traffic logs for the `source.ip` to identify any other suspicious activities or connections related to the brute-force attempts.
+
+### False positive analysis
+
+- Legitimate high-volume automated processes: Some organizations may have automated scripts or services that perform numerous login attempts in a short period, such as system health checks or batch processing tasks. These can trigger the rule as false positives.
+- Shared IP addresses: Users accessing Microsoft 365 services from shared IP addresses, such as those in corporate networks or VPNs, may result in multiple failed login attempts from a single source, leading to false positives.
+- Frequent password changes: Users who frequently change their passwords and subsequently enter incorrect credentials multiple times may inadvertently trigger the rule.
+- Testing and development environments: In environments where developers or IT staff are testing authentication processes, multiple failed logins may occur, which can be mistaken for brute-force attempts.
+- To manage these false positives, users can create exceptions for known IP addresses associated with legitimate automated processes or shared networks. Additionally, monitoring and adjusting the threshold for failed login attempts based on organizational behavior can help reduce false positives.
+
+### Response and remediation
+
+- Immediately block the source IP address identified in the alert to prevent further unauthorized access attempts.
+- Investigate the affected user accounts for any signs of compromise or unauthorized access, and reset passwords as a precautionary measure.
+- Review the sign-in logs for additional suspicious activity from the same IP or related IP addresses to identify potential patterns or coordinated attacks.
+- Escalate the incident to the security operations team if there is evidence of a broader attack or if multiple accounts are targeted.
+- Implement multi-factor authentication (MFA) for all user accounts to add an additional layer of security against brute-force attacks.
+- Enhance logging policies to ensure comprehensive capture of authentication events, including both successful and failed login attempts, for better future analysis.
+- Integrate Azure Entra logs with a Security Information and Event Management (SIEM) system to enable real-time monitoring and automated alerting for similar threats.
+- Conduct a security awareness training session for users to educate them on recognizing phishing attempts and the importance of strong, unique passwords.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to detect and block similar brute-force attempts in the future.
+- Apply security patches and updates to all systems and applications to mitigate vulnerabilities that could be exploited in conjunction with brute-force attacks.
+
+This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
 references = [
     "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
     "https://github.com/0xZDH/o365spray"
diff --git a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
index 76341ee2959..eafec4e7395 100644
--- a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
+++ b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/10/14"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Matteo Potito Giorgio"]
@@ -38,6 +38,48 @@ query = '''
  event.dataset:(azure.activitylogs or azure.signinlogs) and 
      (azure.signinlogs.properties.authentication_protocol:deviceCode or azure.activitylogs.properties.authentication_protocol:deviceCode) and event.outcome:success
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of Entra ID Auth via DeviceCode Protocol
+
+The device code authentication flow is designed for devices lacking keyboards, facilitating user login without direct input of credentials. However, attackers can exploit this by phishing users to capture access tokens, enabling unauthorized access. The detection rule identifies new instances of this protocol use, flagging potential misuse by monitoring successful authentications within a specified timeframe.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account involved in the first occurrence of the deviceCode protocol authentication.
+- Verify the timestamp of the authentication event to understand when the activity took place and correlate it with any known user activities or scheduled tasks.
+- Examine the `event.dataset` field to determine whether the event originated from `azure.activitylogs` or `azure.signinlogs`, providing context on the type of log and its source.
+- Analyze the `event.outcome` field to confirm the success of the authentication attempt, ensuring that the alert is based on a successful login.
+- Investigate the `azure.signinlogs.properties.authentication_protocol` or `azure.activitylogs.properties.authentication_protocol` fields to confirm the use of the deviceCode protocol.
+- Check the IP address and location associated with the authentication event to identify any anomalies or unexpected geolocations.
+- Use Osquery to gather additional context on the device involved in the authentication. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_ADDRESS_FROM_ALERT>';`
+- Review the user's recent activity logs to identify any unusual patterns or deviations from their typical behavior, such as logins from new devices or locations.
+- Cross-reference the user's activity with any recent phishing campaigns or security incidents that might have targeted the organization.
+- Consult with the user to verify whether they initiated the authentication and to gather any additional context or insights into the event.
+
+### False positive analysis
+
+- Legitimate use of the device code protocol by users accessing applications on devices without keyboards, such as smart TVs or IoT devices, can trigger false positives. These instances should be reviewed to confirm the legitimacy of the device and user.
+- Automated scripts or applications that use the device code protocol for authentication as part of their normal operation may also be flagged. Identifying these scripts and adding them to an exception list can prevent unnecessary alerts.
+- Users who frequently travel or work remotely might use the device code protocol on new devices, leading to repeated alerts. Monitoring user behavior and establishing a baseline for normal activity can help differentiate between legitimate and suspicious use.
+- Organizations can create exceptions for known and trusted devices or applications that regularly use the device code protocol, reducing the likelihood of false positives while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further unauthorized access and token misuse.
+- Conduct a thorough investigation to determine the source of the device code request and verify if it aligns with legitimate user activity.
+- Revoke any access tokens associated with the compromised account to prevent further unauthorized access.
+- Notify the user and relevant stakeholders about the potential compromise and advise them to change their passwords and review their account activity.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems are affected.
+- Implement enhanced logging and monitoring for device code authentication attempts to detect and respond to future misuse promptly.
+- Integrate threat intelligence feeds to correlate device code authentication attempts with known malicious IP addresses or threat actors.
+- Review and update security policies to restrict the use of device code authentication to only necessary scenarios and enforce multi-factor authentication.
+- Restore the affected system to its operational state by ensuring all compromised tokens are revoked and user credentials are reset.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as user training on phishing awareness and regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/azure/credential_access_key_vault_modified.toml b/rules/integrations/azure/credential_access_key_vault_modified.toml
index b58c6dfac3f..391f753cec9 100644
--- a/rules/integrations/azure/credential_access_key_vault_modified.toml
+++ b/rules/integrations/azure/credential_access_key_vault_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Key Vault Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Key Vault Modified
+
+Azure Key Vault is a critical service for managing sensitive information like encryption keys and secrets. It ensures that only authorized users and applications can access this data. However, adversaries may attempt to modify Key Vault settings to gain unauthorized access to credentials. The detection rule monitors for successful write operations to Key Vaults, signaling potential unauthorized modifications that could lead to credential exposure.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.dataset:azure.activitylogs and ensure the operation_name is "MICROSOFT.KEYVAULT/VAULTS/WRITE" with a successful outcome.
+- Identify the user or application that performed the write operation by examining the user or service principal details in the activity logs.
+- Check the timestamp of the modification to determine when the change occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the IP address and location from which the write operation was performed to identify any anomalies or unauthorized access patterns.
+- Review the change history of the specific Key Vault to understand what modifications were made and assess if they align with expected changes.
+- Analyze the access policies of the Key Vault to verify if any unauthorized users or applications have been granted access.
+- Use Osquery to gather additional context on the system from which the modification was made. Example query: `SELECT * FROM azure_key_vault WHERE operation_name = 'MICROSOFT.KEYVAULT/VAULTS/WRITE' AND outcome = 'Success';`
+- Cross-reference the activity with any recent changes in user permissions or roles that might explain the modification.
+- Check for any related alerts or incidents in the security monitoring system that might indicate a broader attack or compromise.
+- Consult with the relevant teams or stakeholders to verify if the modification was part of a legitimate change request or deployment.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular maintenance or updates by authorized personnel can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when maintenance is scheduled.
+- Automated deployment processes: Continuous integration and deployment pipelines may modify Key Vault settings as part of their normal operation. Users should identify and exclude these automated processes by whitelisting specific service accounts or IP addresses.
+- Third-party integrations: Some third-party applications may require write access to Key Vaults for legitimate reasons. Users should verify these integrations and exclude them from the detection rule by adding them to an allowlist.
+- Policy updates: Changes in organizational security policies might necessitate updates to Key Vault configurations. Users can handle these by documenting policy changes and temporarily excluding related activities during the transition period.
+
+### Response and remediation
+
+- Immediately isolate the affected Key Vault to prevent further unauthorized access by restricting network access and disabling any suspicious accounts or applications.
+- Review Azure Activity Logs to identify unauthorized changes and determine the scope of the compromise, focusing on the specific write operations detected.
+- Revoke any potentially compromised credentials and secrets stored in the Key Vault and rotate them to new, secure values.
+- Conduct a thorough investigation to identify the source of the unauthorized access, leveraging threat intelligence and MITRE ATT&CK framework to understand potential adversary techniques.
+- Escalate the incident to the security operations team and, if necessary, involve legal and compliance teams to assess potential impacts and regulatory obligations.
+- Implement enhanced logging and monitoring policies for Azure Key Vault, ensuring that all access and modification attempts are logged and reviewed regularly.
+- Integrate Azure Key Vault with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Restore the Key Vault to its operational state by verifying the integrity of its contents and ensuring that only authorized users and applications have access.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent future incidents.
+- Implement hardening measures such as enabling Azure Key Vault firewall, using private endpoints, and enforcing strict access controls and multi-factor authentication for all users and applications accessing the Key Vault.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
index 5f1e83dabbf..ba885d1a6ce 100644
--- a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
+++ b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Storage Account Key Regenerated"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Storage Account Key Regenerated
+
+Azure Storage Account keys are critical credentials that grant access to storage resources. They are often used by applications and services to authenticate and interact with Azure Storage. Adversaries may regenerate these keys to gain unauthorized access, potentially disrupting services or exfiltrating data. The detection rule monitors for successful key regeneration events, signaling potential credential misuse, and aligns with known threat tactics to alert security teams.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `azure.activitylogs` and the operation name is `MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION` with a successful outcome.
+- Identify the user or service principal associated with the key regeneration event by examining the `azure.activitylogs.caller` field.
+- Check the timestamp of the key regeneration event to determine when the action occurred and correlate it with other security events or anomalies around the same time.
+- Investigate the storage account involved by reviewing the `azure.activitylogs.resource_id` field to understand which resources might be affected.
+- Analyze the `azure.activitylogs.correlation_id` to trace related activities and identify any other suspicious operations performed by the same user or service principal.
+- Use Osquery to gather additional context on the system where the key regeneration was initiated. For example, run the following query to list recent Azure CLI commands executed: `SELECT * FROM shell_history WHERE command LIKE '%az storage%' ORDER BY time DESC LIMIT 10;`.
+- Review the access patterns and usage of the storage account before and after the key regeneration event to identify any unusual data access or exfiltration attempts.
+- Check for any recent changes in permissions or roles assigned to the user or service principal involved in the key regeneration to assess if there was a privilege escalation.
+- Investigate any other alerts or incidents involving the same storage account or user to determine if this event is part of a broader attack campaign.
+- Consult with the application or service owners using the storage account to verify if the key regeneration was authorized and necessary for operational purposes.
+
+### False positive analysis
+
+- Routine administrative tasks: Regularly scheduled key rotations by IT administrators for security best practices can trigger this alert. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools: Some organizations use automated processes to periodically regenerate keys for compliance or security reasons. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses.
+- Third-party integrations: Certain third-party services may require key regeneration as part of their normal operation. Review and document these integrations, then configure exceptions for their expected behavior to prevent false positives.
+- Testing environments: In development or testing environments, frequent key regenerations may occur as part of testing procedures. Exclude these environments from alerting by using tags or specific resource group identifiers to differentiate them from production systems.
+
+### Response and remediation
+
+- Immediately revoke the regenerated storage account keys to prevent unauthorized access and assess the impact on dependent applications and services.
+- Conduct a thorough investigation to determine the source and intent of the key regeneration, reviewing logs and correlating with other security events.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement Azure Key Vault to manage and rotate storage account keys securely, reducing the risk of unauthorized key regeneration.
+- Enable and configure Azure Monitor and Azure Security Center to enhance logging and alerting capabilities for storage account activities.
+- Review and update access controls and permissions for Azure Storage Accounts to ensure the principle of least privilege is enforced.
+- Conduct a security awareness session for administrators and developers on the importance of key management and the risks associated with key regeneration.
+- Restore affected applications and services by updating them with new, secure access keys and verifying their operational status.
+- Implement multi-factor authentication (MFA) and conditional access policies for accessing Azure resources to add an additional layer of security.
+- Regularly review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
index e6d6c3ef2b1..5941010698b 100644
--- a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
+++ b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Application Credential Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Application Credential Modification
+
+Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. The detection rule monitors audit logs for successful modifications in application credentials, signaling potential misuse by identifying unauthorized credential additions.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to confirm the alert by checking for entries with `event.dataset:azure.auditlogs` and `azure.auditlogs.operation_name:"Update application - Certificates and secrets management"` with a successful outcome.
+- Identify the application involved in the credential modification by examining the specific application ID or name in the audit log entry.
+- Determine the user or service principal that performed the modification by reviewing the `initiatedBy` field in the audit log.
+- Check the timestamp of the modification to understand when the change occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the new credential added by identifying its type (certificate or secret) and any associated metadata, such as expiration date or permissions.
+- Review the application's activity logs for any unusual or unauthorized access patterns following the credential modification.
+- Cross-reference the user or service principal involved with other logs or alerts to identify any patterns of suspicious behavior or previous incidents.
+- Use Osquery to gather additional context on the system where the modification was initiated. For example, run a query to list recent Azure CLI commands executed: `SELECT * FROM shell_history WHERE command LIKE '%az ad app credential%'`.
+- Verify if the new credential has been used by checking for any token requests or authentications involving the application post-modification.
+- Consult with the application owner or relevant stakeholders to confirm if the credential modification was authorized and aligns with expected changes or maintenance activities.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or maintenance by IT staff may involve adding new credentials to applications, which can trigger the detection rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated processes: Some applications may automatically rotate their credentials as part of a security policy. Identify these applications and exclude their credential updates from triggering alerts by using specific application IDs or tags.
+- Third-party integrations: Integrations with external services might require adding new credentials. Document and whitelist these integrations to prevent false positives.
+- Development and testing environments: Frequent changes in non-production environments can lead to numerous alerts. Consider excluding these environments from the rule or applying a different threshold for alerts.
+- Organizational changes: Mergers, acquisitions, or restructuring may necessitate credential updates. During such periods, increase monitoring of changes but adjust the rule to reduce noise by temporarily excluding certain user groups or departments.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized credentials added to the Azure application to prevent further unauthorized access.
+- Conduct a thorough investigation to identify how the unauthorized credential was added, including reviewing audit logs and identifying any compromised accounts or systems.
+- Reset passwords and rotate keys for any accounts or applications that may have been compromised to ensure no further unauthorized access.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential impacts and obligations.
+- Implement additional monitoring and alerting for changes to application credentials to detect similar activities in the future.
+- Review and update access controls and permissions for Azure applications to ensure the principle of least privilege is enforced.
+- Enhance logging policies to ensure comprehensive coverage of credential modifications and other critical security events.
+- Integrate Azure security logs with a Security Information and Event Management (SIEM) system for centralized monitoring and analysis.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement improvements to prevent recurrence.
+- Apply hardening measures such as enabling multi-factor authentication (MFA) for administrative access and using managed identities for Azure resources to reduce reliance on static credentials.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
index 50ea493d443..20ff0558b43 100644
--- a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Runbook Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Automation Runbook Deleted
+
+Azure Automation Runbooks automate repetitive tasks in cloud environments, enhancing operational efficiency. Adversaries may delete these runbooks to disrupt operations or conceal malicious activities. The detection rule monitors Azure activity logs for successful deletion events, signaling potential defense evasion attempts by identifying unauthorized or suspicious runbook deletions.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE"`.
+- Verify the `event.outcome` field to ensure the deletion was successful, as indicated by values "Success" or "success".
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
+- Check the timestamp of the deletion event to determine when the runbook was deleted and correlate it with other suspicious activities around the same time.
+- Investigate the `azure.activitylogs.resource_id` field to identify the specific runbook and automation account affected.
+- Review the Azure AD sign-in logs for the identified user or service principal to detect any unusual login patterns or locations.
+- Examine the Azure activity logs for any preceding or subsequent operations by the same user or service principal to identify potential malicious activities.
+- Use Osquery to query the local system for any related Azure credentials or configurations that might have been used in the deletion. Example query: `SELECT * FROM azure_credentials WHERE user = '<identified_user>';`.
+- Cross-reference the deletion event with any recent changes in Azure policies or permissions that might have allowed unauthorized access.
+- Consult with the team responsible for Azure Automation to verify if the deletion was planned or authorized, and gather any additional context or documentation related to the runbook.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may lead to legitimate runbook deletions, which can trigger false positives. These activities are often scheduled and documented, making them identifiable.
+- Automated scripts or third-party tools used for managing Azure resources might delete runbooks as part of their normal operation, leading to false alerts.
+- Users can manage false positives by creating exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
+- Implementing a review process for deletion events can help distinguish between legitimate and suspicious activities, reducing the likelihood of false positives.
+- Monitoring for additional context, such as associated user accounts or IP addresses, can help in identifying benign deletions and refining detection rules accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Automation account to prevent further unauthorized deletions or modifications.
+- Review Azure activity logs to identify the source of the deletion request, including user accounts and IP addresses involved.
+- Verify if the deletion was authorized by cross-referencing with change management records or contacting the responsible team.
+- Restore the deleted runbook from backups or version history to ensure continuity of automated operations.
+- Conduct a thorough investigation to determine if any other runbooks or resources were tampered with or deleted.
+- Escalate the incident to the security operations team if unauthorized access or malicious intent is confirmed.
+- Implement stricter access controls and multi-factor authentication for Azure Automation accounts to prevent unauthorized actions.
+- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system for real-time alerts on suspicious activities.
+- Review and update incident response plans to include specific procedures for handling Azure Automation-related incidents.
+- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as regular audits and least privilege access policies.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
index 7802a541aa0..272a9d212c5 100644
--- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
+++ b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Blob Permissions Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Blob Permissions Modification
+
+Azure Blob Storage is a service for storing large amounts of unstructured data, such as text or binary data. It uses Azure RBAC to manage access permissions. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt data integrity. The detection rule monitors specific Azure activity logs for successful operations that change blob permissions, signaling potential security threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific operation that triggered the alert, focusing on the `azure.activitylogs.operation_name` field to determine if it was a "MANAGEOWNERSHIP/ACTION" or "MODIFYPERMISSIONS/ACTION".
+- Check the `event.outcome` field to confirm the operation was successful, as this indicates a confirmed change in permissions.
+- Identify the user or service principal responsible for the change by examining the `azure.activitylogs.caller` field to determine if the action was performed by an authorized entity.
+- Investigate the `azure.activitylogs.resource_id` field to pinpoint the specific Azure Blob or container affected by the permission change.
+- Correlate the timestamp of the alert with other logs to identify any concurrent suspicious activities, such as unusual login attempts or data access patterns.
+- Use Osquery to gather additional context on the affected Azure Blob by running a query like: `SELECT * FROM azure_blob_permissions WHERE blob_name = '<affected_blob_name>' AND account_name = '<storage_account_name>';` to verify current permissions and compare with expected configurations.
+- Review recent changes in Azure Active Directory (AAD) logs to check for any modifications to roles or group memberships that could have influenced the permission change.
+- Analyze historical activity logs for the same `azure.activitylogs.caller` to identify any patterns of behavior that might suggest malicious intent or previous unauthorized access attempts.
+- Consult with the data owner or relevant stakeholders to verify if the permission change was expected or authorized, providing context from the alert details.
+- Document findings and gather evidence, including screenshots and log extracts, to support further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular maintenance or updates by administrators may trigger the rule when they modify blob permissions as part of their duties. Users can handle these by identifying and excluding specific administrative accounts or operations from the rule.
+- Automated processes: Scheduled scripts or automated tools that manage blob permissions for operational purposes might cause false positives. Users should document these processes and create exceptions for known benign operations.
+- Third-party integrations: Some third-party applications may require permission changes to function correctly, leading to false positives. Users should review and whitelist these applications if they are verified as non-threatening.
+- Testing environments: Changes in permissions within testing or development environments can trigger alerts. Users can exclude these environments from monitoring or adjust the rule to focus on production environments only.
+- Temporary access changes: Short-term permission modifications for troubleshooting or temporary projects might be flagged. Users should track these changes and set up temporary exceptions with expiration dates to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Blob Storage account to prevent further unauthorized access or data manipulation.
+- Review Azure Activity Logs to identify the source and scope of the permission changes, focusing on the user or service principal responsible for the modification.
+- Verify the current permissions on the affected blobs and compare them with the baseline or expected permissions to assess the extent of unauthorized changes.
+- Revert any unauthorized permission changes to their original state to restore security controls and prevent data exposure.
+- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the period of unauthorized access.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential data breach implications.
+- Implement enhanced logging and monitoring policies to capture detailed access and modification events for Azure Blob Storage, ensuring future incidents are detected promptly.
+- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities related to blob permissions.
+- Educate administrators and users on the importance of maintaining strict access controls and regularly reviewing permissions to prevent inadvertent exposure.
+- Apply hardening measures such as enabling Azure AD Conditional Access policies and using Azure Key Vault to manage and rotate access keys securely.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles"]
diff --git a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
index 3d1aed02314..206483a7d6c 100644
--- a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Diagnostic Settings Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Diagnostic Settings Deletion
+
+Azure Diagnostic Settings are crucial for monitoring and logging, directing platform logs and metrics to various destinations for analysis. Adversaries may delete these settings to obscure their tracks and evade detection. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful operations related to the removal of diagnostic settings, aligning with defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"`.
+- Verify the `event.outcome` field to ensure the operation was successful, indicating that the diagnostic settings were indeed deleted.
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
+- Check the `azure.activitylogs.resource_id` field to determine which specific diagnostic settings were deleted and assess the potential impact on monitoring and logging.
+- Investigate the `azure.activitylogs.correlation_id` to trace related activities and identify any other suspicious operations that occurred around the same time.
+- Analyze the `azure.activitylogs.timestamp` to establish a timeline of events and correlate with other security alerts or anomalies in the environment.
+- Use Osquery to gather additional context on the affected resources by running a query such as: `SELECT * FROM azure_diagnostic_settings WHERE resource_id = '<resource_id_from_logs>';` to retrieve current settings and compare with historical data.
+- Cross-reference the deletion event with any recent changes in user permissions or roles that might have allowed unauthorized access to delete diagnostic settings.
+- Investigate any other alerts or logs from the same user or service principal to identify patterns of suspicious behavior or potential lateral movement.
+- Review the organization's change management records to determine if the deletion was part of an approved change or if it was unauthorized.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may lead to the deletion of diagnostic settings, which can trigger false positives. These activities are often performed by authorized personnel and should be reviewed to confirm legitimacy.
+- Automated scripts or tools used for infrastructure management might delete and recreate diagnostic settings as part of their normal operation. Identifying these scripts and excluding their activity from alerts can reduce false positives.
+- Changes in organizational policies or compliance requirements might necessitate the removal of certain diagnostic settings. Documenting these changes and updating monitoring rules accordingly can help in managing false positives.
+- To handle false positives, users can create exceptions for known and verified activities by excluding specific user accounts or service principals that are responsible for legitimate deletions. This can be done by adjusting the detection rule to ignore operations performed by these trusted entities.
+
+### Response and remediation
+
+- Immediately isolate affected Azure resources to prevent further unauthorized actions and assess the scope of the deletion.
+- Review Azure activity logs to identify the source and timeline of the deletion event, focusing on user accounts and IP addresses involved.
+- Verify if any other critical settings or configurations have been altered or deleted, indicating a broader compromise.
+- Restore deleted diagnostic settings from backups or reconfigure them manually to ensure continued logging and monitoring.
+- Implement Azure Role-Based Access Control (RBAC) to restrict permissions for deleting diagnostic settings to only essential personnel.
+- Escalate the incident to the security operations team for a detailed investigation and to determine if further actions are required.
+- Conduct a root cause analysis to understand how the adversary gained access and deleted the settings, leveraging MITRE ATT&CK framework for threat context.
+- Enhance logging policies to include alerts for any changes to diagnostic settings and other critical configurations.
+- Integrate Azure Security Center and other security tools to provide comprehensive monitoring and alerting capabilities.
+- Review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings"]
diff --git a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
index b94eb74a53b..4281bbbcce4 100644
--- a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Event Hub Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Event Hub Deletion
+
+Azure Event Hubs is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may delete Event Hubs to disrupt monitoring and evade detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific deletion operations, flagging successful attempts to impair defenses.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking the `event.dataset` and `azure.activitylogs.operation_name` fields for "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE".
+- Verify the `event.outcome` field to ensure the deletion was successful, as indicated by "Success" or "success".
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
+- Check the `azure.activitylogs.correlation_id` to trace related activities and understand the sequence of events leading to the deletion.
+- Investigate the `azure.activitylogs.resource_id` to determine which specific Event Hub was deleted and assess its importance and impact on operations.
+- Analyze the `azure.activitylogs.timestamp` to establish the exact time of the deletion and correlate it with other security events or anomalies.
+- Use Osquery to gather additional context on the system from which the deletion was initiated. Example query: `SELECT * FROM azure_event_hubs WHERE operation_name = 'MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE' AND outcome = 'Success';`
+- Review any recent changes in Azure IAM roles and permissions that might have allowed unauthorized users to delete Event Hubs.
+- Cross-reference the deletion event with network logs to identify any unusual access patterns or connections from suspicious IP addresses around the time of the event.
+- Consult with relevant stakeholders or teams to verify if the deletion was part of a planned activity or if it was unauthorized, gathering any additional context or documentation.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may trigger the Azure Event Hub Deletion rule, as legitimate users might delete Event Hubs during regular operations or resource management activities.
+- Automated scripts or deployment tools that manage Azure resources could also lead to false positives if they include Event Hub deletion as part of their workflow.
+- To manage these false positives, users can create exceptions for known maintenance windows or specific user accounts that regularly perform these operations.
+- Implementing a whitelist of trusted IP addresses or service accounts that are authorized to delete Event Hubs can help reduce false positives.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the integrity of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further unauthorized access or data loss.
+- Conduct a thorough investigation to confirm the deletion was unauthorized, reviewing Azure activity logs and correlating with other security events.
+- Restore the deleted Event Hub from backups or snapshots to resume normal operations and minimize data loss.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response coordination.
+- Implement enhanced logging and monitoring policies to capture detailed activity logs for all critical Azure resources, including Event Hubs.
+- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities.
+- Review and update access controls and permissions for Azure resources to ensure the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
+- Educate and train staff on recognizing and responding to potential security incidents, emphasizing the importance of timely reporting.
+- Regularly test and update incident response plans to ensure readiness for future threats, incorporating lessons learned from the current incident.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
index f0c701c2cb6..e24c97ab8e4 100644
--- a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Firewall Policy Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Firewall Policy Deletion
+
+Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE"` with `event.outcome:Success`.
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
+- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events around the same time.
+- Investigate the IP address and location associated with the deletion event using the `azure.activitylogs.callerIpAddress` field to identify any anomalies or suspicious access patterns.
+- Review the Azure AD sign-in logs for the identified user or service principal to check for any unusual login activities or failed login attempts.
+- Examine the change history of the deleted firewall policy to understand its previous configuration and assess the potential impact of its deletion.
+- Use Osquery to query the Azure environment for any recent changes to network security configurations. Example query: `SELECT * FROM azure_firewall_policies WHERE operation_name = 'DELETE' AND outcome = 'Success';`
+- Investigate any other related Azure resources that might have been affected by the deletion, such as virtual networks or subnets, to assess the broader impact.
+- Check for any other recent deletions or modifications of security policies in the Azure environment to identify potential patterns or coordinated attacks.
+- Collaborate with the incident response team to gather additional context from other security tools and logs, such as SIEM or endpoint detection systems, to build a comprehensive picture of the incident.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT operations may involve the deletion of Azure Firewall policies as part of regular maintenance or updates. These actions can be identified by correlating the deletion event with scheduled maintenance windows or change management records.
+- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage Azure resources, including the deletion of firewall policies. These can be identified by reviewing the source of the operation and verifying if it aligns with known automation processes.
+- Testing environments: In development or testing environments, frequent creation and deletion of firewall policies may occur as part of testing procedures. These can be excluded by filtering events from specific resource groups or subscriptions designated for testing.
+- To manage false positives, users can create exceptions by excluding specific user accounts, service principals, or IP addresses associated with known non-threatening activities. Additionally, integrating with change management systems can help validate whether a deletion event is authorized.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further unauthorized access or data exfiltration.
+- Review Azure activity logs to confirm the deletion of the firewall policy and identify any associated suspicious activities or accounts.
+- Recreate the deleted firewall policy using backup configurations or documented rules to restore network security controls.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying compromised accounts and systems.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
+- Implement enhanced logging and monitoring for Azure activity logs to detect similar unauthorized actions in the future.
+- Integrate Azure Security Center and other security tools to provide comprehensive visibility and automated alerts for policy changes.
+- Review and update access controls and permissions to ensure only authorized personnel can modify or delete firewall policies.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate and train staff on security best practices and the importance of maintaining robust firewall policies to prevent future incidents.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/firewall-manager/policy-overview"]
diff --git a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
index acea8b019f8..e5ca3f91913 100644
--- a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,7 +24,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Frontdoor Web Application Firewall (WAF) Policy Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Frontdoor Web Application Firewall (WAF) Policy Deleted
+
+Azure Frontdoor WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific operations, alerting security teams to potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE"` with `event.outcome:(Success or success)`.
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the activity logs.
+- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events or alerts around the same time.
+- Investigate the IP address and location associated with the deletion event using the `azure.activitylogs.callerIpAddress` field to identify any anomalies or suspicious access patterns.
+- Review the audit logs for any recent changes to user permissions or roles that might have allowed unauthorized deletion of the WAF policy.
+- Examine other Azure resources and configurations for any additional unauthorized changes or suspicious activities that might indicate a broader attack.
+- Use Osquery to gather more information about the system from which the deletion was initiated. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_ADDRESS_FROM_LOGS>';`.
+- Check for any recent failed login attempts or unusual login activities in Azure Active Directory that could suggest compromised credentials.
+- Investigate any recent alerts or incidents related to the affected Azure Frontdoor instance to identify potential precursors or related activities.
+- Collaborate with the application and network teams to understand the potential impact of the WAF policy deletion on the security posture and application availability.
+
+### False positive analysis
+
+- Routine maintenance or administrative actions: Legitimate deletions of Azure Frontdoor WAF policies may occur during scheduled maintenance or when administrators are updating or replacing policies. These actions can be mistaken for malicious activity.
+- Policy migration: During a migration process, old WAF policies might be deleted as new ones are implemented. This can trigger alerts even though the activity is part of a planned upgrade or restructuring.
+- Testing and development environments: In non-production environments, frequent policy deletions may occur as part of testing or development processes. These should be distinguished from production environment alerts.
+- To manage these false positives, users can create exceptions for known administrative accounts or IP addresses that regularly perform these actions. Additionally, implementing a change management process that logs and approves legitimate deletions can help differentiate between authorized and unauthorized activities.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further unauthorized access or data exfiltration.
+- Review Azure activity logs to confirm the deletion of the WAF policy and identify any unauthorized access or suspicious activities around the time of deletion.
+- Restore the deleted Azure Frontdoor WAF policy from backups or recreate it using predefined templates to re-establish security controls.
+- Conduct a thorough investigation to determine the root cause of the policy deletion, including identifying any compromised accounts or insider threats.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response coordination.
+- Implement enhanced logging and monitoring for Azure activity logs to detect similar unauthorized actions in the future.
+- Integrate Azure Security Center and other security tools to provide comprehensive visibility and automated alerts for suspicious activities.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify or delete WAF policies.
+- Conduct a post-incident review to identify gaps in security posture and update incident response plans accordingly.
+- Educate and train staff on security best practices and the importance of maintaining robust security configurations to prevent future incidents.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
index 12782cf9cb0..d4692276400 100644
--- a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Events Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Kubernetes Events Deleted
+
+Azure Kubernetes Service (AKS) logs events to track state changes like container creation or pod scheduling. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these events to hide their tracks and evade detection. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful event deletion operations, signaling potential malicious activity.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE"`.
+- Verify the `event.outcome` field to ensure the deletion operation was successful, as indicated by values "Success" or "success".
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
+- Check the timestamp of the deletion event to determine when the activity occurred and correlate it with other suspicious activities.
+- Investigate the source IP address and location associated with the deletion event to identify any anomalies or unauthorized access.
+- Review the Kubernetes audit logs for any related activities around the same time to identify potential unauthorized actions or patterns.
+- Use Osquery to gather additional context on the affected Kubernetes cluster. For example, run the query: `SELECT * FROM kubernetes_events WHERE event_name = 'delete' AND cluster_name = '<cluster_name>';` to list all deletion events in the cluster.
+- Analyze the Kubernetes RBAC (Role-Based Access Control) settings to ensure that permissions are appropriately configured and no excessive privileges are granted.
+- Cross-reference the deletion event with any recent changes in the cluster configuration or deployments to identify potential causes or related activities.
+- Consult with the team responsible for the Kubernetes environment to verify if the deletion was part of a legitimate maintenance activity or if it requires further investigation.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may trigger event deletions, such as clearing old or irrelevant logs to manage storage space. These actions are typically benign and can be identified by correlating with scheduled maintenance windows or known administrative activities.
+- Automated scripts or tools used for log management might delete events as part of their normal operation. Users should review the source and purpose of these scripts to determine if they are legitimate.
+- Certain third-party applications integrated with Azure Kubernetes might perform event deletions as part of their functionality. Users should verify the application's behavior and consider excluding these operations if they are confirmed to be non-threatening.
+- To manage false positives, users can create exceptions for specific user accounts or service principals known to perform legitimate event deletions. This can be done by adding conditions to the detection rule to exclude these entities.
+- Regularly review and update the list of exceptions to ensure that only verified non-malicious activities are excluded, maintaining the balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or changes.
+- Conduct a thorough investigation to identify the source and scope of the event deletions, focusing on recent access logs and user activities.
+- Review Azure activity logs to determine if any other suspicious activities occurred around the time of the event deletions.
+- Restore deleted Kubernetes events from backups if available, to ensure continuity in monitoring and troubleshooting.
+- Escalate the incident to the security operations team for a deeper analysis and to determine if the attack is part of a larger campaign.
+- Implement stricter access controls and audit policies on Kubernetes clusters to limit who can delete events and perform other critical operations.
+- Enhance logging and monitoring by integrating Azure Security Center and other security tools to provide real-time alerts on suspicious activities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply security patches and updates to the Kubernetes environment to mitigate any known vulnerabilities that could have been exploited.
+- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining robust security practices.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
index 4bf9be6b02e..ce651bd4988 100644
--- a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Network Watcher Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Network Watcher Deletion
+
+Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments, providing insights and enabling logging for virtual network resources. Adversaries may delete Network Watchers to evade detection and impair defenses. The detection rule identifies such deletions by monitoring Azure activity logs for specific deletion operations, flagging successful attempts to ensure timely investigation and response.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE"` with `event.outcome:Success`.
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the logs.
+- Check the timestamp of the deletion event to determine when the Network Watcher was deleted and correlate it with other security events around the same time.
+- Investigate the source IP address and location from which the deletion request was made using the `azure.activitylogs.caller_ip_address` field.
+- Analyze the context of the deletion by reviewing any preceding or subsequent operations in the Azure activity logs that involve the same user or resource group.
+- Use Osquery to query the Azure environment for any recent changes to network configurations or security settings that might indicate further malicious activity. Example query: `SELECT * FROM azure_network_watcher WHERE operation_name = 'MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE';`
+- Check for any alerts or anomalies in other security tools that might correlate with the deletion event, such as unusual login attempts or privilege escalations.
+- Review the audit logs for any changes to user roles or permissions that could have allowed unauthorized deletion of the Network Watcher.
+- Investigate whether there are any other Network Watchers in the environment and assess their current status and configuration for signs of tampering.
+- Consult with the team responsible for network security to verify if the deletion was authorized and documented as part of a legitimate change management process.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may lead to the deletion of Network Watchers, which can trigger false positives. These tasks are often scheduled and documented, making them identifiable.
+- Automated scripts or deployment tools that manage Azure resources might delete and recreate Network Watchers as part of their normal operation, leading to benign alerts.
+- Users can manage these false positives by creating exceptions for known maintenance windows or specific administrative accounts that perform these tasks regularly.
+- Implementing a tagging system for resources involved in routine operations can help in distinguishing between legitimate and suspicious deletions.
+- Regularly reviewing and updating the list of exceptions based on changes in administrative practices or automation scripts can minimize unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure environment to prevent further unauthorized actions and assess the scope of the deletion.
+- Review Azure activity logs to identify the source of the deletion request, including user accounts, IP addresses, and timestamps.
+- Verify if the deletion was authorized by cross-referencing with change management records and contacting relevant personnel.
+- Restore the deleted Network Watcher by redeploying it from a known good configuration or backup to resume monitoring and diagnostics.
+- Implement Azure Role-Based Access Control (RBAC) to restrict permissions for deleting critical resources like Network Watchers to only essential personnel.
+- Enable and configure Azure Security Center and Azure Monitor to enhance visibility and alerting on suspicious activities related to network resources.
+- Conduct a thorough investigation to determine if other resources were affected or if there are signs of further compromise.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments for potential breaches.
+- Update incident response plans and playbooks to include specific procedures for handling Network Watcher deletions and similar threats.
+- Review and enhance logging policies to ensure comprehensive coverage and retention of activity logs, integrating with SIEM solutions for improved threat detection and analysis.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview"]
diff --git a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
index 5adfd45abdd..8886a0e9fca 100644
--- a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
+++ b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Alert Suppression Rule Created or Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Alert Suppression Rule Created or Modified
+
+Azure Alert Suppression Rules help manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to evade detection by suppressing legitimate security alerts. The detection rule monitors for successful creation or modification of these rules, flagging potential misuse that aligns with defense evasion tactics, ensuring security teams maintain visibility over critical alerts.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the timestamp, user, and source IP address associated with the creation or modification of the suppression rule.
+- Verify the identity of the user who created or modified the suppression rule by checking their role and permissions in Azure Active Directory to ensure they have legitimate access.
+- Examine the `azure.activitylogs.operation_name` field to confirm the specific operation, "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE," was performed successfully.
+- Investigate the `event.outcome` field to ensure the operation was indeed successful and not a failed attempt, which might indicate a misconfiguration or unauthorized access attempt.
+- Cross-reference the `event.dataset:azure.activitylogs` with other logs to identify any unusual or suspicious activities around the same time, such as failed login attempts or changes to other security settings.
+- Use Osquery to gather additional context on the system where the rule was created or modified. For example, run a query to list recent changes to Azure configurations: `SELECT * FROM azure_activity_logs WHERE operation_name = 'MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE' AND outcome = 'success';`
+- Check for any recent changes in the environment that might have necessitated the creation or modification of the suppression rule, such as new deployments or updates.
+- Analyze historical data to determine if there is a pattern of suppression rule modifications that could indicate a broader attempt to evade detection.
+- Consult with the security team or the user who made the change to understand the rationale behind the creation or modification of the suppression rule.
+- Document all findings and observations to maintain a comprehensive record of the investigation, which can be useful for future reference or audits.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate changes made by security administrators to manage alert noise can trigger this rule. These changes are often necessary to maintain operational efficiency and should be reviewed to ensure they align with security policies.
+- Automated processes: Some organizations use automated scripts or tools to manage alert suppression rules, which can result in frequent rule modifications. These should be documented and monitored to distinguish between expected and unexpected changes.
+- Testing and development environments: In non-production environments, suppression rules may be frequently created or modified as part of testing processes. These environments should be clearly identified, and alerts from them can be excluded from triggering false positives.
+- Known maintenance windows: During scheduled maintenance, suppression rules might be adjusted to prevent alert fatigue. Establishing exceptions for these periods can help reduce unnecessary alerts.
+- To manage these false positives, users can implement exception lists for known benign activities, use tagging to differentiate between environments, and establish baselines for expected behavior to quickly identify deviations.
+
+### Response and remediation
+
+- Immediately review the Azure activity logs to identify the user or service principal responsible for creating or modifying the alert suppression rule.
+- Verify the legitimacy of the change by contacting the responsible user or team to confirm if the action was authorized and necessary.
+- If unauthorized, disable or delete the suspicious suppression rule to restore visibility to critical alerts.
+- Conduct a thorough investigation to determine if any other security configurations have been altered or if there are additional unauthorized changes.
+- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture.
+- Implement enhanced logging and monitoring for Azure activity logs to detect similar unauthorized changes in the future.
+- Integrate Azure activity logs with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Review and update access controls and permissions for users and service principals to ensure that only authorized personnel can modify alert suppression rules.
+- Conduct a post-incident review to identify gaps in the current security processes and implement measures to prevent recurrence.
+- Consider implementing additional security measures such as multi-factor authentication (MFA) and conditional access policies to strengthen the security of Azure resources.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/discovery_blob_container_access_mod.toml b/rules/integrations/azure/discovery_blob_container_access_mod.toml
index 61d9adf1f1c..5103ce53027 100644
--- a/rules/integrations/azure/discovery_blob_container_access_mod.toml
+++ b/rules/integrations/azure/discovery_blob_container_access_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Blob Container Access Level Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Blob Container Access Level Modification
+
+Azure Blob Storage allows for scalable data storage, where access levels can be set to control data visibility. Adversaries may exploit this by altering access levels to expose sensitive data publicly. The detection rule monitors for changes in container access settings, focusing on successful operations, to identify potential unauthorized modifications that could lead to data exposure.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `azure.activitylogs` and the operation name is `MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE` with a successful outcome.
+- Identify the specific storage account and container involved in the access level modification by examining the relevant fields in the alert.
+- Check the timestamp of the modification to determine when the change occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the identity of the user or service principal that performed the modification by reviewing the `azure.activitylogs.caller` field.
+- Verify if the user or service principal has a legitimate reason to modify the container access level by checking their role and permissions in Azure Active Directory.
+- Examine the previous access level settings of the container to understand the extent of the change and potential exposure.
+- Use Osquery to gather additional context on the system from which the modification was made, for example: `SELECT * FROM azure_blob_containers WHERE account_name = 'your_storage_account' AND container_name = 'your_container';`
+- Review any related logs or alerts that might indicate lateral movement or privilege escalation attempts leading up to the modification.
+- Check for any recent changes in the organization's policies or configurations that might have inadvertently allowed the modification.
+- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the access level change.
+
+### False positive analysis
+
+- Routine administrative tasks: Changes to container access levels may be part of regular maintenance or configuration updates by authorized personnel. To manage these, users can create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated processes: Some organizations use automated scripts or tools to manage storage configurations, which might trigger the detection rule. Users can exclude these processes by identifying and whitelisting the specific service accounts or automation tools involved.
+- Development and testing environments: Access level modifications in non-production environments might be frequent and benign. Users can exclude these environments by filtering out specific storage accounts or resource groups associated with development and testing.
+- Third-party integrations: Certain third-party applications or services may require changes to access levels for functionality. Users should review and whitelist these integrations after ensuring they do not pose a security risk.
+
+### Response and remediation
+
+- Immediately revoke public access to the affected Azure Blob container to prevent further unauthorized data exposure.
+- Conduct a thorough investigation to identify the source and intent of the access level modification, reviewing logs and access patterns.
+- Verify the integrity and confidentiality of the data within the container to assess any potential data breach.
+- Escalate the incident to the security operations team if malicious intent is suspected, providing them with detailed logs and findings.
+- Implement Azure Monitor and Azure Security Center to enhance logging and alerting for future unauthorized access level changes.
+- Review and update access control policies to ensure that only authorized personnel can modify container access levels.
+- Conduct a security audit of all Azure Blob containers to identify and rectify any other instances of misconfigured access levels.
+- Restore the container's access level to its original state, ensuring compliance with organizational security policies.
+- Educate relevant staff on the importance of secure access configurations and the risks associated with public data exposure.
+- Consider implementing Azure Policy to enforce compliance with access level configurations and prevent unauthorized changes.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent"]
diff --git a/rules/integrations/azure/execution_command_virtual_machine.toml b/rules/integrations/azure/execution_command_virtual_machine.toml
index 6913c697a2e..b98400db730 100644
--- a/rules/integrations/azure/execution_command_virtual_machine.toml
+++ b/rules/integrations/azure/execution_command_virtual_machine.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Command Execution on Virtual Machine"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Command Execution on Virtual Machine
+
+Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they can't directly access them. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute malicious scripts. The detection rule monitors Azure activity logs for successful command executions, identifying potential misuse by correlating specific operation names and outcomes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the details of the command execution event, focusing on the `azure.activitylogs.operation_name` field to ensure it matches "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION".
+- Verify the `event.outcome` field to ensure the command execution was successful, as this indicates the command was executed on the VM.
+- Identify the user or service principal that initiated the command execution by examining the `azure.activitylogs.caller` field.
+- Check the timestamp of the event to determine when the command execution occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the specific command or script executed on the VM by reviewing any available command logs or script content, if accessible.
+- Cross-reference the VM's activity with other logs, such as network logs or application logs, to identify any unusual behavior or data exfiltration attempts following the command execution.
+- Use Osquery to gather more information about the VM's current state. For example, run the following Osquery query to list all running processes on the VM: `SELECT pid, name, path FROM processes;`.
+- Analyze the roles and permissions of the user or service principal involved in the command execution to determine if they have legitimate access or if there are any privilege escalation concerns.
+- Investigate any recent changes to the VM's configuration or security settings that could have facilitated unauthorized command execution.
+- Review the history of command executions on the VM to identify any patterns or repeated attempts that could indicate ongoing malicious activity.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular maintenance or updates performed by IT staff using PowerShell commands on VMs may trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when these tasks are scheduled.
+- Automated scripts: Scheduled scripts or automation tools that execute commands on VMs for legitimate purposes, such as backups or performance monitoring, can be mistaken for malicious activity. Users should document these scripts and exclude their associated accounts or operations from the detection rule.
+- Third-party integrations: Some third-party services or applications may require command execution on VMs as part of their normal operation. Identifying these services and excluding their activity from the rule can help reduce false positives.
+- Testing environments: Commands executed in test or development environments may not pose a threat. Users can exclude these environments by filtering out specific resource groups or VM names associated with non-production use.
+
+### Response and remediation
+
+- Immediately isolate the affected virtual machine from the network to prevent further malicious activity.
+- Review Azure activity logs to identify the source and scope of the command execution, focusing on the user or service principal involved.
+- Verify the integrity of the system by checking for unauthorized changes or the presence of malicious scripts or software.
+- Revoke or adjust permissions for the user or role that executed the command, ensuring least privilege access is enforced.
+- Conduct a thorough investigation to determine if any data exfiltration or lateral movement occurred as a result of the command execution.
+- Escalate the incident to the security operations team for further analysis and to determine if additional resources are needed.
+- Implement enhanced logging and monitoring policies to capture detailed activity on virtual machines, including command execution and network traffic.
+- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities.
+- Restore the virtual machine to a known good state using backups or snapshots, ensuring all malicious artifacts are removed.
+- Apply hardening measures such as enabling Just-In-Time VM access, using Azure Bastion for secure RDP/SSH, and regularly updating security patches.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
index d66662ddb29..5c749ce3905 100644
--- a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
+++ b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -25,7 +25,52 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Service Principal Credentials Added"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Service Principal Credentials Added
+
+Azure Service Principals are identities used by applications or services to access Azure resources securely. They typically have specific permissions and are less frequently updated. Adversaries may exploit this by adding unauthorized credentials, bypassing MFA, and accessing sensitive data. The detection rule monitors audit logs for successful additions of credentials, signaling potential misuse or hijacking attempts.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event details, focusing on the `event.dataset:azure.auditlogs` and `azure.auditlogs.operation_name:"Add service principal credentials"` fields to ensure the alert is valid.
+- Check the `event.outcome` field to verify the success of the credential addition and determine if it aligns with expected behavior.
+- Identify the service principal involved by examining the relevant fields in the audit logs, such as the service principal's name or ID.
+- Investigate the user or application that performed the credential addition by reviewing the `user.name` or `user.id` fields in the logs.
+- Cross-reference the time of the credential addition with other security events or logs to identify any suspicious activity or patterns.
+- Analyze the permissions and roles assigned to the service principal to assess the potential impact of unauthorized access.
+- Use Osquery to gather additional context on the affected service principal. For example, run a query to list all credentials associated with the service principal: `SELECT * FROM azure_service_principal_credentials WHERE service_principal_id = '<service_principal_id>';`.
+- Review recent changes or updates to the service principal's configuration or permissions to identify any unauthorized modifications.
+- Check for any recent or unusual login attempts or access patterns associated with the service principal to detect potential misuse.
+- Collaborate with the application or service owner to verify if the credential addition was authorized and aligns with expected operational procedures.
+
+### False positive analysis
+
+- Routine administrative tasks: In some organizations, service principal credentials may be updated as part of regular maintenance or automated processes. These updates can trigger the detection rule, leading to false positives.
+- DevOps and CI/CD pipelines: Automated systems that manage deployments and infrastructure might add or update service principal credentials frequently, which can be mistaken for unauthorized activity.
+- Third-party integrations: Some third-party applications or services may require periodic updates to service principal credentials, which could be misinterpreted as suspicious behavior.
+- To manage these false positives, users can create exceptions for known and trusted sources or processes that regularly update service principal credentials. This can be done by identifying specific patterns or attributes in the audit logs that are associated with legitimate activities and excluding them from triggering alerts.
+- Implementing a whitelist of service principals that are expected to have frequent credential updates can help reduce noise and focus on truly suspicious activities.
+- Regularly reviewing and updating the list of exceptions is crucial to ensure that new legitimate behaviors are accounted for and that the detection rule remains effective against potential threats.
+
+### Response and remediation
+
+- Immediately revoke the newly added credentials to prevent unauthorized access to Azure resources.
+- Conduct a thorough investigation to determine the source and method of the unauthorized credential addition, focusing on recent changes and access logs.
+- Review and audit all permissions associated with the affected service principal to identify any potential misuse or over-permissioning.
+- Escalate the incident to the security operations team and relevant stakeholders for further analysis and response coordination.
+- Implement additional monitoring and alerting for any further unauthorized changes to service principal credentials.
+- Enhance logging policies to ensure comprehensive capture of all authentication and authorization events related to service principals.
+- Integrate Azure Security Center and other security tools to provide a unified view of security alerts and incidents.
+- Restore the system to its operational state by ensuring all legitimate credentials are intact and functioning as expected.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update policies accordingly.
+- Implement hardening measures such as enforcing stricter access controls, regular credential rotation, and multi-factor authentication for all service principals.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://www.fireeye.com/content/dam/collateral/en/wp-m-unc2452.pdf"]
diff --git a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
index 791f2c8c25a..b69cd7b9d37 100644
--- a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
+++ b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -22,7 +22,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Pods Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Kubernetes Pods Deleted
+
+Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, orchestrating tasks like deployment and scaling. Pods, the smallest deployable units, can be targeted by adversaries to disrupt services by deletion. The detection rule monitors Azure activity logs for successful pod deletion operations, signaling potential malicious activity aimed at impacting service availability.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE"` with `event.outcome:(Success or success)`.
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the logs.
+- Check the timestamp of the deletion event to determine when the activity occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the specific pod(s) deleted by looking at the `azure.activitylogs.resource_id` field to understand which applications or services were impacted.
+- Analyze the context of the deletion by reviewing any related events in the activity logs, such as preceding or subsequent operations by the same user or on the same resources.
+- Verify if the deletion was part of a legitimate maintenance or deployment activity by cross-referencing with change management records or deployment logs.
+- Use Osquery to gather additional context on the affected Kubernetes cluster. For example, run a query to list all current pods and their statuses: `SELECT name, namespace, status FROM kubernetes_pods WHERE cluster_name = 'your_cluster_name';`.
+- Check for any recent alerts or incidents related to the same cluster or namespace to identify potential patterns or ongoing threats.
+- Investigate the network activity around the time of the deletion to detect any unusual access patterns or connections to the Kubernetes API server.
+- Consult with the application or service owners to verify if they were aware of or authorized the pod deletion, and gather any additional context they might have.
+
+### False positive analysis
+
+- Routine maintenance or updates: Regular updates or maintenance activities may involve the deletion and recreation of pods, which can trigger the detection rule. Users can manage this by creating exceptions for known maintenance windows or specific operations teams.
+- Automated scaling operations: Kubernetes may automatically delete pods as part of scaling operations, either up or down, which are benign activities. Users should consider excluding these operations by identifying and filtering out specific scaling-related events.
+- Deployment rollouts: During application deployment rollouts, old pods may be deleted to make way for new versions. Users can handle these by setting up exceptions for deployment-related activities, possibly by correlating with deployment logs.
+- Testing environments: In testing or development environments, frequent pod deletions may occur as part of normal testing procedures. Users can exclude these environments from monitoring or adjust the rule to focus on production environments only.
+- Known service accounts: If certain service accounts are responsible for legitimate pod deletions, users can exclude these accounts from triggering alerts by adding them to an allowlist.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or damage.
+- Review Azure activity logs to confirm the deletion event and identify any unauthorized access patterns or suspicious IP addresses.
+- Recreate the deleted pods using the latest known good configuration to restore service availability.
+- Conduct a root cause analysis to determine how the deletion was initiated and identify any security gaps.
+- Escalate the incident to the security operations team if malicious intent is suspected, providing them with all relevant logs and findings.
+- Implement stricter access controls and role-based access management to limit who can delete pods in the future.
+- Enhance logging policies to ensure all Kubernetes API actions are logged and monitored for anomalies.
+- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities.
+- Regularly update and patch Kubernetes clusters and associated components to mitigate vulnerabilities.
+- Conduct a security review and harden the Kubernetes environment by following best practices, such as network segmentation and using pod security policies.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_resource_group_deletion.toml b/rules/integrations/azure/impact_resource_group_deletion.toml
index 6ccdd075ad5..e6c58cc1146 100644
--- a/rules/integrations/azure/impact_resource_group_deletion.toml
+++ b/rules/integrations/azure/impact_resource_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Resource Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Resource Group Deletion
+
+Azure Resource Groups are containers that hold related resources for an Azure solution, enabling streamlined management and organization. Adversaries may exploit this by deleting entire groups to disrupt services or erase data, causing significant impact. The detection rule monitors Azure activity logs for successful deletion operations, alerting analysts to potential malicious actions aimed at data destruction.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking the `event.dataset` and `azure.activitylogs.operation_name` fields for "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and ensure the `event.outcome` is marked as Success.
+- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the logs.
+- Check the timestamp of the deletion event to determine when the resource group was deleted and correlate it with any other suspicious activities around the same time.
+- Investigate the IP address and location from which the deletion request was made using the `azure.activitylogs.caller_ip_address` field to identify any anomalies or unauthorized access.
+- Review the audit logs for any preceding activities by the same user or IP address to identify potential reconnaissance or privilege escalation attempts.
+- Examine the `azure.activitylogs.correlation_id` to trace related operations and understand the broader context of the deletion event.
+- Use Osquery to query the Azure environment for any recent changes in user roles or permissions that could have facilitated the deletion. Example query: `SELECT * FROM azure_role_assignments WHERE principal_id = '<user_id>' AND timestamp > '<deletion_time>';`
+- Check for any alerts or incidents in the security information and event management (SIEM) system that might be related to the same user or resource group.
+- Investigate any recent changes to the Azure subscription or resource group policies that might have allowed the deletion to occur without proper authorization.
+- Collaborate with the affected teams to gather additional context about the resource group, such as its importance, the data it contained, and any potential impact of its deletion.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks can trigger the Azure Resource Group Deletion alert, especially during scheduled clean-up operations or when decommissioning resources. 
+- Automated scripts or tools used for resource management might also delete resource groups as part of their normal operation, leading to false positives.
+- To manage these false positives, users can create exceptions for known maintenance windows or specific administrative accounts that regularly perform these tasks.
+- Implementing a whitelist of trusted IP addresses or service accounts that are authorized to delete resource groups can help reduce unnecessary alerts.
+- Regularly reviewing and updating the list of exceptions based on changes in administrative practices or personnel can further minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate affected Azure subscriptions to prevent further unauthorized actions and assess the scope of the deletion.
+- Review Azure activity logs to identify the source of the deletion request, including user accounts, IP addresses, and timestamps.
+- Verify if the deletion was authorized by contacting the responsible team or individual; if unauthorized, escalate to the security incident response team.
+- Restore deleted resources from backups if available, prioritizing critical services to minimize downtime and operational impact.
+- Implement Azure Role-Based Access Control (RBAC) to restrict permissions, ensuring only authorized personnel can delete resource groups.
+- Enable Azure Multi-Factor Authentication (MFA) for all accounts with permissions to delete resources to add an additional layer of security.
+- Configure Azure Monitor and Security Center to alert on suspicious activities, such as unexpected deletions or changes in resource configurations.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Integrate Azure activity logs with a Security Information and Event Management (SIEM) system for enhanced monitoring and correlation with other security events.
+- Educate and train staff on security best practices and the importance of monitoring and protecting critical resources against data destruction threats.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_virtual_network_device_modified.toml b/rules/integrations/azure/impact_virtual_network_device_modified.toml
index f1e9e003e68..634f2ff1118 100644
--- a/rules/integrations/azure/impact_virtual_network_device_modified.toml
+++ b/rules/integrations/azure/impact_virtual_network_device_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Virtual Network Device Modified or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Virtual Network Device Modified or Deleted
+
+Azure virtual network devices, such as network interfaces, virtual hubs, and routers, are crucial for managing network traffic and connectivity in cloud environments. Adversaries may target these devices to disrupt services or reroute traffic for data exfiltration. The detection rule monitors specific Azure activity logs for operations indicating modifications or deletions, helping identify unauthorized changes that could signify malicious activity.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the specific operation that triggered the alert, focusing on the `azure.activitylogs.operation_name` field to identify whether it was a modification or deletion.
+- Check the `event.outcome` field to ensure the operation was successful, as this indicates the change was applied.
+- Identify the user or service principal responsible for the operation by examining the `azure.activitylogs.caller` field to determine if the action was authorized.
+- Investigate the timestamp of the event to correlate with any other suspicious activities or changes in the environment.
+- Cross-reference the affected virtual network device with recent changes in network traffic patterns or connectivity issues to assess potential impact.
+- Use Osquery to gather additional context about the affected virtual network device. For example, run a query to list all network interfaces and their configurations: `SELECT * FROM azure_network_interfaces WHERE name = '<affected_device_name>';`.
+- Review any associated Azure Resource Manager (ARM) templates or scripts that might have been used to deploy or modify the network device to ensure they have not been tampered with.
+- Check for any recent changes in Azure policies or role assignments that might have inadvertently allowed unauthorized modifications.
+- Investigate any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or coordinated attacks.
+- Consult with the network and cloud infrastructure teams to verify if the change was part of a planned maintenance or deployment activity.
+
+### False positive analysis
+
+- Routine maintenance activities by network administrators can trigger this rule, such as scheduled updates or configuration changes to network interfaces, virtual hubs, or routers. These actions are typically non-threatening and can be excluded by creating exceptions for known maintenance windows or specific user accounts.
+- Automated scripts or tools used for network management might also cause false positives if they perform frequent write or delete operations on virtual network devices. Users can handle these by identifying and excluding operations from trusted automation tools or service accounts.
+- Changes made by authorized third-party services or integrations that manage network configurations could be mistakenly flagged. To manage this, users should whitelist operations from these services by specifying their unique identifiers or IP addresses in the exclusion criteria.
+- In environments with dynamic scaling, automated processes that modify or delete network interfaces as part of scaling operations may be misinterpreted as malicious. Users can mitigate this by setting up exceptions for operations linked to known scaling activities or specific resource groups.
+
+### Response and remediation
+
+- Immediately isolate the affected virtual network device to prevent further unauthorized access or changes.
+- Review Azure activity logs to identify the source and scope of the modification or deletion, focusing on user accounts and IP addresses involved.
+- Verify the integrity of other network devices and configurations to ensure no additional unauthorized changes have occurred.
+- Restore the modified or deleted virtual network device from a known good backup to return the system to its operational state.
+- Implement stricter access controls and multi-factor authentication for accounts with permissions to modify network devices.
+- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack.
+- Conduct a root cause analysis to understand how the unauthorized change occurred and identify any security gaps.
+- Enhance logging policies to ensure comprehensive monitoring of all critical network device operations and integrate with a SIEM for real-time alerts.
+- Update and patch all network devices and related software to mitigate vulnerabilities that could be exploited by adversaries.
+- Educate and train staff on recognizing and responding to suspicious activities related to network device management, leveraging MITRE ATT&CK framework for threat context.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"]
diff --git a/rules/integrations/azure/initial_access_external_guest_user_invite.toml b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
index ec46d414b1e..bc31030ecb0 100644
--- a/rules/integrations/azure/initial_access_external_guest_user_invite.toml
+++ b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure External Guest User Invitation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure External Guest User Invitation
+
+Azure Active Directory (AD) facilitates collaboration by allowing external users to be invited as guests, enhancing flexibility but also introducing security risks. Adversaries might exploit this by creating guest accounts to gain unauthorized access. The detection rule monitors audit logs for successful external user invitations, flagging potential misuse by identifying operations linked to guest account creation.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the details of the invitation event by checking the `azure.auditlogs.operation_name` field for "Invite external user" and ensure the `event.outcome` is marked as "Success".
+- Identify the inviter by examining the `azure.auditlogs.properties.initiated_by.user.display_name` and `azure.auditlogs.properties.initiated_by.user.user_principal_name` fields to determine who initiated the guest invitation.
+- Verify the legitimacy of the invited guest by checking the `azure.auditlogs.properties.target_resources.*.display_name` field for the guest's display name and cross-referencing it with known business contacts or partners.
+- Investigate the inviter's recent activities by querying additional audit logs for any unusual or unauthorized actions performed by the inviter's account.
+- Check the `azure.auditlogs.properties.target_resources.*.user_principal_name` field to gather more information about the guest account and verify if it aligns with any known external collaborators.
+- Use Osquery to further investigate the inviter's machine for any signs of compromise. Example query: `SELECT * FROM processes WHERE user = '<inviter_user_principal_name>';` to list running processes under the inviter's account.
+- Assess the frequency and pattern of guest invitations by the same inviter to identify any anomalies or patterns that deviate from normal business operations.
+- Review the organization's guest user policy and compare it with the current invitation to ensure compliance and identify any deviations.
+- Investigate any recent changes to the Azure AD configuration or permissions that might have facilitated unauthorized guest invitations.
+- Collaborate with the IT or security team to gather additional context on the business need for the guest invitation and verify if it aligns with ongoing projects or partnerships.
+
+### False positive analysis
+
+- Invitations sent to external partners or vendors for legitimate business collaborations can trigger false positives. These are often necessary for project-based work or temporary access needs.
+- Automated systems or applications that require guest access for integration purposes might also be flagged. These systems often have predictable patterns and can be whitelisted.
+- Regular audits of guest accounts can help identify and exclude known, non-threatening guest users from triggering alerts. This involves maintaining an updated list of approved external collaborators.
+- Implementing a review process for guest invitations can help distinguish between legitimate and suspicious activities. This process can include verifying the inviter's identity and the business justification for the invitation.
+- Use Azure AD's built-in features to set up conditional access policies that can help reduce false positives by allowing only specific domains or email addresses to be invited as guests.
+
+### Response and remediation
+
+- Verify the legitimacy of the guest user invitation by contacting the inviter and confirming the business need for the guest account.
+- Temporarily disable the guest account to prevent unauthorized access while the investigation is ongoing.
+- Review the audit logs to identify any suspicious activities associated with the guest account, such as unusual login attempts or access to sensitive resources.
+- Cross-reference the guest account details with known threat intelligence sources to determine if the account is linked to any known adversaries or malicious activities.
+- If the guest account is deemed unauthorized, remove the account from Azure Active Directory and revoke any permissions or access granted.
+- Escalate the incident to the security operations team if the investigation reveals potential compromise or if the guest account is linked to a broader attack campaign.
+- Implement stricter guest user invitation policies, such as requiring multi-factor authentication and approval from a higher-level authority before creating guest accounts.
+- Enhance logging and monitoring by integrating Azure AD logs with a Security Information and Event Management (SIEM) system to detect and alert on suspicious activities in real-time.
+- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
+- Educate employees on the risks associated with guest user invitations and provide training on secure collaboration practices to prevent future incidents.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/governance/policy/samples/cis-azure-1-1-0"]
diff --git a/rules/integrations/azure/persistence_azure_automation_account_created.toml b/rules/integrations/azure/persistence_azure_automation_account_created.toml
index 114f1210d26..cac9f142857 100644
--- a/rules/integrations/azure/persistence_azure_automation_account_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Account Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Automation Account Created
+
+Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud and on-premises environments. Adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule identifies the creation of such accounts by monitoring specific Azure activity logs, focusing on successful operations that could indicate unauthorized account creation.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the creation of the Automation account by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE"`.
+- Verify the `event.outcome` field to ensure the operation was successful, indicating the account was indeed created.
+- Identify the user or service principal responsible for the account creation by examining the `azure.activitylogs.caller` field.
+- Check the timestamp of the account creation event to determine when the activity occurred and correlate it with other suspicious activities.
+- Investigate the IP address and location associated with the `azure.activitylogs.callerIpAddress` field to assess if the activity originated from an expected or unusual source.
+- Review the `azure.activitylogs.correlationId` to trace related activities and operations that might provide additional context or indicate a broader attack.
+- Use Osquery to gather more information about the environment by running a query such as: `SELECT * FROM azure_automation_accounts WHERE account_name = '<AccountName>'` to retrieve details about the newly created account.
+- Examine the permissions and roles assigned to the new Automation account to determine if they are excessive or deviate from the norm.
+- Cross-reference the creation event with any recent changes in Azure policies or configurations that might have allowed unauthorized account creation.
+- Investigate any subsequent activities performed by the Automation account to identify potential malicious actions or scripts executed post-creation.
+
+### False positive analysis
+
+- Routine administrative tasks: Organizations often create Azure Automation accounts for legitimate purposes such as automating routine administrative tasks, patch management, or resource scaling. These activities can trigger the detection rule, leading to false positives.
+- Development and testing environments: In environments where developers frequently create and delete resources for testing purposes, the creation of Azure Automation accounts may be a common occurrence and not indicative of malicious activity.
+- Third-party integrations: Some third-party services and tools may automatically create Azure Automation accounts as part of their integration process, which can be mistaken for unauthorized activity.
+- To manage false positives, users can create exceptions for known and trusted sources by whitelisting specific user accounts or service principals that are authorized to create Azure Automation accounts. Additionally, users can implement tagging or naming conventions for automation accounts to easily identify legitimate accounts and exclude them from alerts. Regularly reviewing and updating these exceptions based on changes in the environment can help maintain the accuracy of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the Azure Automation account to prevent further unauthorized activities by disabling the account or restricting its permissions.
+- Conduct a thorough investigation to determine the origin of the account creation, including reviewing the activity logs for the user or service principal responsible for the action.
+- Verify the legitimacy of the account creation with relevant stakeholders or system owners to confirm whether it was authorized or not.
+- If unauthorized, remove the Automation account and any associated resources or scripts that may have been deployed by the adversary.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised.
+- Implement enhanced logging and monitoring for Azure Automation activities, ensuring that all account creations and modifications are logged and reviewed regularly.
+- Integrate Azure Security Center or other security information and event management (SIEM) solutions to provide real-time alerts and automated responses to suspicious activities.
+- Review and update access controls and permissions for Azure resources to ensure the principle of least privilege is enforced, reducing the risk of unauthorized account creation.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements to prevent future incidents.
+- Educate and train staff on recognizing and responding to suspicious activities related to Azure Automation accounts and other cloud resources, enhancing overall security awareness.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
index 94aa992de20..c297b574ece 100644
--- a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
+++ b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Runbook Created or Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Automation Runbook Created or Modified
+
+Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code, ensuring persistence and control. The detection rule monitors specific operations indicating runbook creation or modification, flagging successful events to identify potential misuse and safeguard against malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific operation that triggered the alert, focusing on the `azure.activitylogs.operation_name` field to determine if it was a draft write, a write, or a publish action.
+- Examine the `event.outcome` field to confirm the success of the operation, ensuring that the alert is based on a successful event.
+- Identify the user or service principal that performed the operation by reviewing the relevant fields in the activity logs, such as `azure.activitylogs.caller`.
+- Check the timestamp of the event to determine when the runbook was created or modified, which can help correlate with other activities in the environment.
+- Investigate the runbook's content and changes by accessing the Azure Automation account and reviewing the runbook's version history and code.
+- Cross-reference the user or service principal with recent login activities and other actions in Azure AD logs to identify any unusual or unauthorized access patterns.
+- Use Osquery to gather additional context on the system where the runbook might be executed. For example, run an Osquery query to list all scheduled tasks or cron jobs that might be related to the runbook execution.
+- Query Azure Resource Graph or Azure Monitor logs to identify any other recent changes or deployments in the same Azure Automation account or resource group.
+- Investigate any network or system logs for unusual outbound connections or data transfers that might be associated with the runbook's execution.
+- Collaborate with the application or system owner to verify the legitimacy of the runbook changes and gather additional context on its intended use and any recent operational changes.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or maintenance activities by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when these tasks are expected.
+- Automated deployment processes: Continuous integration and deployment pipelines might create or modify runbooks as part of their normal operation. Users should identify and exclude these processes by filtering based on the service accounts or automation tools involved.
+- Third-party integrations: Some third-party services may interact with Azure Automation to enhance functionality, leading to benign runbook modifications. Users can handle these by whitelisting specific application IDs or service principals associated with trusted integrations.
+- Testing and development activities: Developers may frequently create or modify runbooks in non-production environments. Users can reduce false positives by excluding specific environments or resource groups dedicated to development and testing.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions.
+- Review the activity logs to identify the source and scope of the unauthorized runbook creation or modification.
+- Verify the integrity of all runbooks within the affected Automation account to ensure no other scripts have been tampered with.
+- Revoke any suspicious or unauthorized access permissions to the Azure Automation account and associated resources.
+- Restore any modified or deleted runbooks from backups to ensure the system returns to its intended operational state.
+- Implement Azure Monitor alerts for any future runbook creation or modification activities to ensure timely detection of unauthorized changes.
+- Conduct a thorough investigation to determine if the unauthorized runbook activity is part of a larger attack, leveraging MITRE ATT&CK framework for threat context.
+- Escalate the incident to the security operations team if the activity is linked to known threat actors or if the scope of the attack is beyond initial containment.
+- Enhance logging policies to include detailed audit logs for all Azure Automation activities and integrate with a Security Information and Event Management (SIEM) system for continuous monitoring.
+- Review and update security policies and access controls for Azure Automation accounts to adhere to the principle of least privilege, reducing the risk of future unauthorized access.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
index 370c2d78c7c..456327599a5 100644
--- a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,52 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Webhook Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Automation Webhook Created
+
+Azure Automation webhooks enable automated task execution via HTTP requests, integrating external systems with Azure runbooks. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts. The detection rule monitors Azure activity logs for webhook creation events, identifying potential misuse by flagging successful operations related to webhook actions.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the details of the webhook creation event, focusing on the `azure.activitylogs.operation_name` field to verify if it matches "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/ACTION" or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/WRITE".
+- Check the `event.outcome` field to ensure the operation was successful, as this indicates the webhook was indeed created.
+- Identify the user or service principal that initiated the webhook creation by examining the `azure.activitylogs.caller` field to determine if the action was authorized or suspicious.
+- Investigate the source IP address and location from which the webhook creation request originated to identify any anomalies or unexpected geolocations.
+- Review the associated runbook that the webhook is configured to trigger, ensuring it does not contain any unauthorized or malicious scripts.
+- Cross-reference the webhook creation event with other recent Azure activity logs to identify any related suspicious activities, such as changes to runbooks or automation accounts.
+- Utilize Osquery to gather additional context on the system where the webhook was created. For example, run the following Osquery query to list recent Azure Automation activities: `SELECT * FROM azure_activity WHERE operation_name LIKE '%WEBHOOKS%' AND outcome = 'Success';`
+- Check for any recent changes in permissions or roles assigned to the user or service principal involved in the webhook creation to ensure they have not been escalated improperly.
+- Analyze any alerts or logs from security monitoring tools that might indicate attempts to exploit the webhook or the associated runbook.
+- Consult with the team responsible for Azure Automation to verify if the webhook creation was part of a legitimate change or deployment process.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT operations may involve creating webhooks for automation purposes, such as regular system maintenance or data processing tasks. These actions can trigger the detection rule, leading to false positives.
+- Development and testing activities: Developers and IT teams often create and test webhooks during the development of new automation processes. These activities can be mistaken for malicious actions.
+- Third-party integrations: Some third-party applications and services integrate with Azure Automation using webhooks to perform authorized tasks, which might be flagged by the rule.
+- To manage false positives, users can create exceptions for known and trusted sources by whitelisting specific IP addresses or user accounts associated with legitimate webhook creation activities.
+- Implementing a review process for webhook creation logs can help differentiate between authorized and unauthorized activities, allowing for more accurate threat detection.
+- Regularly updating and refining the detection rule criteria based on organizational needs and known benign activities can reduce the occurrence of false positives.
+
+### Response and remediation
+
+- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks.
+- Review the Azure activity logs to identify the source and context of the webhook creation, including the user account and IP address involved.
+- Conduct a thorough investigation of the runbook associated with the webhook to determine if it contains malicious code or unauthorized changes.
+- If malicious activity is confirmed, isolate affected systems and runbooks to prevent further compromise.
+- Escalate the incident to the security operations team for a detailed analysis and to determine the scope of the breach.
+- Implement Azure Monitor alerts to notify security teams of any future webhook creation events for proactive monitoring.
+- Enhance logging policies to ensure comprehensive capture of Azure activity logs, focusing on automation accounts and webhook activities.
+- Integrate Azure Security Center and other security tools to provide a unified view of security alerts and streamline incident response.
+- Restore any affected systems or runbooks to their last known good state, ensuring that all malicious code is removed.
+- Apply hardening measures such as restricting webhook creation permissions to only trusted administrators and regularly reviewing access controls.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
index fda5b5dbbe4..d340bd832ba 100644
--- a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
+++ b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Conditional Access Policy Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Conditional Access Policy Modified
+
+Azure Conditional Access policies are critical for securing access to resources by enforcing specific conditions, such as requiring multi-factor authentication. Adversaries may exploit this by altering policies to reduce security, thereby gaining unauthorized access. The detection rule monitors logs for successful updates to these policies, signaling potential tampering attempts that could compromise security.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Conditional Access policy that was modified, focusing on the `event.action` and `event.outcome` fields to confirm the successful update.
+- Check the `event.dataset` field to determine whether the modification was logged in `azure.activitylogs` or `azure.auditlogs`, as this can provide context on the type of activity.
+- Identify the user or service principal responsible for the modification by examining the `user.name` or `user.id` fields in the logs.
+- Investigate the user's recent activities and login history to determine if there are any anomalies or signs of compromise, such as unusual login locations or times.
+- Review the changes made to the Conditional Access policy, including any alterations to conditions or controls like multi-factor authentication requirements.
+- Cross-reference the modification time with other security events or alerts to identify any correlated suspicious activities.
+- Use Osquery to gather additional context on the system or user involved. For example, run a query to list recent Azure AD sign-ins: `SELECT * FROM azure_ad_signins WHERE user_principal_name = 'user@example.com' AND timestamp > 'YYYY-MM-DD'`.
+- Check for any recent changes in user permissions or roles that might indicate privilege escalation attempts.
+- Analyze the IP addresses and devices associated with the modification event to identify any unfamiliar or suspicious sources.
+- Consult with the policy owner or relevant stakeholders to verify if the modification was authorized and aligns with current security policies.
+
+### False positive analysis
+
+- Routine administrative updates: Regular updates or changes made by authorized IT personnel to improve or maintain security policies can trigger the detection rule. To manage this, organizations can create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated policy updates: Some organizations use automated scripts or tools to update Conditional Access policies as part of their security management processes. These actions can be excluded by identifying and whitelisting the specific scripts or service accounts involved.
+- Third-party integrations: Integrations with third-party security tools or services that modify Conditional Access policies as part of their functionality may cause false positives. Users can handle these by reviewing and approving the integration processes and excluding them from the detection rule.
+- Policy testing and validation: Security teams may modify policies temporarily for testing or validation purposes. To prevent these from being flagged, organizations can document and exclude these activities by correlating them with change management records.
+
+### Response and remediation
+
+- Immediately review the modified Conditional Access policy to understand the changes and assess the potential impact on security.
+- Revert any unauthorized changes to the Conditional Access policy to restore the original security posture.
+- Conduct a thorough investigation to identify the source of the modification, including reviewing audit logs for unusual activity or unauthorized access attempts.
+- Isolate any compromised accounts or systems identified during the investigation to prevent further unauthorized access.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments to assess potential regulatory impacts.
+- Implement additional logging and monitoring for Conditional Access policy changes to detect future unauthorized modifications promptly.
+- Integrate security information and event management (SIEM) solutions to correlate events and enhance threat detection capabilities.
+- Educate and train staff on the importance of Conditional Access policies and the risks associated with unauthorized modifications.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify Conditional Access policies.
+- Consider implementing additional security measures, such as just-in-time access or privileged access management, to further protect critical configurations.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview"]
diff --git a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
index d3509a4a043..abccd352026 100644
--- a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
+++ b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,52 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure AD Global Administrator Role Assigned"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure AD Global Administrator Role Assigned
+
+Azure AD's Global Administrator role grants comprehensive access to manage Azure AD and associated services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit logs for role changes, focusing on the addition of members to the Global Administrator role.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement fields, ensuring the alert is related to role management activities.
+- Examine the azure.auditlogs.operation_name field to verify that the operation was indeed "Add member to role," confirming the nature of the role assignment.
+- Check the azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value field to ensure the new value is "\\"Global Administrator\\"", indicating the specific role assigned.
+- Identify the user account that was added to the Global Administrator role by reviewing the azure.auditlogs.properties.target_resources.0.display_name field.
+- Investigate the initiator of the role assignment by examining the azure.auditlogs.properties.initiated_by.user.display_name and azure.auditlogs.properties.initiated_by.user.user_principal_name fields to determine if the action was performed by a legitimate administrator.
+- Correlate the timestamp of the event with other security logs to identify any suspicious activities or patterns around the time of the role assignment.
+- Use Osquery to gather additional context on the involved user accounts. For example, run a query to list all current Global Administrators: `SELECT * FROM azure_ad_users WHERE role = 'Global Administrator';`
+- Review the sign-in logs for the user account added to the Global Administrator role to identify any unusual login locations or times that could indicate unauthorized access.
+- Check for any recent changes to the organization's Azure AD configuration or policies that might have allowed unauthorized role assignments.
+- Investigate any other alerts or incidents involving the same user accounts or IP addresses to assess if this role assignment is part of a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may frequently assign users to the Global Administrator role as part of their regular duties, such as onboarding new IT staff or managing temporary access for troubleshooting. 
+- Automated processes: Some organizations use automated scripts or third-party tools to manage role assignments, which can trigger alerts if not properly documented or excluded.
+- Role assignment during migrations: During migrations or system upgrades, temporary role assignments might be necessary, leading to potential false positives.
+- To manage these false positives, organizations can create exceptions for known administrative accounts or processes by using filters or exclusion lists in their monitoring tools.
+- Implementing a review process for role assignments can help distinguish between legitimate and suspicious activities, reducing the likelihood of false positives.
+- Regularly updating and reviewing the list of exceptions ensures that only current and necessary exclusions are in place, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately remove unauthorized users from the Global Administrator role to contain the threat and prevent further unauthorized access.
+- Conduct a thorough investigation to identify how the unauthorized assignment occurred, reviewing audit logs and any related security alerts.
+- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were added to the Global Administrator role to prevent further unauthorized access.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential impacts and obligations.
+- Review and update Azure AD role assignment policies to ensure that only authorized personnel can assign or modify Global Administrator roles.
+- Implement enhanced logging and monitoring for Azure AD role changes, ensuring that alerts are generated for any future unauthorized role assignments.
+- Integrate Azure AD logs with a Security Information and Event Management (SIEM) system to improve detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
+- Restore any affected systems or services to their operational state, ensuring that all security patches and updates are applied.
+- Harden Azure AD security by implementing least privilege access, regular role reviews, and continuous security awareness training for administrators.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
index c27d826a2e9..f7798c1b942 100644
--- a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
+++ b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Global Administrator Role Addition to PIM User"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Global Administrator Role Addition to PIM User
+
+Azure AD's Global Administrator role grants extensive access, allowing users to modify any administrative setting. Privileged Identity Management (PIM) helps manage and monitor such roles. Adversaries may exploit this by adding themselves or others to this role to maintain persistent access. The detection rule identifies suspicious role additions by monitoring specific audit logs, focusing on successful role assignments to detect potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the timestamp, user involved, and the specific operation name from the query: "Add eligible member to role in PIM completed (permanent)" or "Add member to role in PIM completed (timebound)".
+- Verify the identity of the user who was added to the Global Administrator role by checking the `azure.auditlogs.properties.target_resources.*.display_name` field for "Global Administrator".
+- Examine the `event.dataset` and `azure.auditlogs.properties.category` fields to confirm the event is related to Role Management and originated from Azure audit logs.
+- Check the `event.outcome` field to ensure the operation was successful, as the query filters for "Success" or "success".
+- Investigate the user account that performed the role addition by reviewing their recent activities and login history in Azure AD logs to identify any unusual behavior or patterns.
+- Use Osquery to gather additional context on the system from which the role addition was performed. Example query: `SELECT * FROM users WHERE username = '<username_of_actor>';` to gather information about the user account on the system.
+- Cross-reference the timestamp of the role addition with other security logs and alerts to identify any correlated suspicious activities or anomalies.
+- Review the organization's change management records or tickets to determine if the role addition was authorized or part of a legitimate administrative task.
+- Investigate any recent changes to Privileged Identity Management (PIM) settings or configurations that could have facilitated unauthorized role additions.
+- Consult with the user or their manager to verify if the role addition was expected and authorized, and gather any additional context or explanations for the activity.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may frequently add users to the Global Administrator role for maintenance or operational purposes. To manage this, organizations can create exceptions for known administrative accounts or specific timeframes when such activities are expected.
+- Automated processes: Some organizations use automated scripts or tools to manage role assignments in Azure AD. These processes might trigger the detection rule. To handle this, users can whitelist specific service accounts or scripts that are known to perform these actions regularly.
+- Temporary role assignments: In some cases, users may be temporarily assigned the Global Administrator role for specific projects or tasks. These assignments can be excluded by setting up alerts only for permanent role additions or by monitoring the duration of the role assignment.
+- Training and testing environments: Activities in non-production environments might mimic suspicious behavior. Users can exclude these environments from monitoring or adjust the sensitivity of alerts to reduce noise from test scenarios.
+
+### Response and remediation
+
+- Immediately revoke the Global Administrator role from any unauthorized users identified in the alert to contain potential misuse.
+- Conduct a thorough investigation to determine how the unauthorized role assignment occurred, reviewing audit logs and any related security alerts.
+- Verify the identity and intent of the user who performed the role assignment to assess if it was a legitimate action or a potential compromise.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems have been compromised.
+- Implement conditional access policies to enforce multi-factor authentication (MFA) for all privileged role assignments to enhance security.
+- Review and update Privileged Identity Management (PIM) settings to ensure that only authorized personnel can assign or approve Global Administrator roles.
+- Enable and configure Azure AD logging to capture detailed audit logs for all role assignments and changes, ensuring logs are retained for an appropriate period.
+- Integrate Azure AD logs with a Security Information and Event Management (SIEM) system to enhance monitoring and alerting capabilities.
+- Restore any affected systems or configurations to their original state prior to the unauthorized role assignment, ensuring no residual access remains.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as least privilege access and regular role review processes.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
index 1da8d4b0099..7b19c11ef1d 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "User Added as Owner for Azure Application"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 User Added as Owner for Azure Application
+
+Azure applications often require specific permissions to function, managed through ownership roles. Adversaries may exploit this by adding themselves or compromised accounts as owners, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to confirm the event details, focusing on the `azure.auditlogs.operation_name` field to ensure it matches "Add owner to application" and the `event.outcome` field to verify it indicates a success.
+- Identify the user account that was added as an owner by examining the relevant fields in the audit log entry, such as `azure.auditlogs.target_user`.
+- Determine the identity of the actor who performed the operation by checking the `azure.auditlogs.initiated_by` field to understand if it was an expected administrator or a potentially compromised account.
+- Cross-reference the timestamp of the event with other security logs to identify any unusual activities or patterns around the same time, such as failed login attempts or changes in user permissions.
+- Investigate the application in question by reviewing its configuration and permissions to assess the potential impact of the new owner addition.
+- Check the history of changes to the application to see if there have been any recent modifications that could indicate malicious intent.
+- Use Osquery to gather additional context on the user account added as an owner. For example, run a query to list recent logins or changes to the account: `SELECT * FROM users WHERE username = 'added_user';`
+- Analyze the network traffic logs for any suspicious connections or data transfers involving the application or the newly added owner account.
+- Review the organization's change management records to verify if the addition of the owner was part of an approved change request.
+- Consult with the application owner or relevant stakeholders to confirm if the addition of the new owner was expected and authorized.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may frequently add users as owners to manage application settings, leading to false positives. To handle this, create exceptions for known administrative accounts or specific time frames when these tasks are expected.  
+- Automated processes: Some organizations use automated scripts or tools to manage application ownership, which can trigger alerts. Identify and exclude these processes by filtering based on known service accounts or automation tools.  
+- Organizational changes: During mergers, acquisitions, or restructuring, there may be a legitimate need to update application ownership. Document these changes and temporarily adjust the detection rule to accommodate the expected increase in ownership changes.  
+- Training and onboarding: New employees or teams may require ownership access as part of their onboarding process. Coordinate with HR or team leads to anticipate these changes and exclude them from triggering alerts.
+
+### Response and remediation
+
+- Immediately revoke the added user's owner permissions from the Azure application to contain potential unauthorized access.
+- Conduct a thorough investigation to determine how the user was added as an owner, reviewing audit logs and identifying any suspicious activities or compromised accounts.
+- Verify the integrity of the Azure application configurations and data to ensure no unauthorized changes were made during the period of elevated access.
+- Reset credentials and enforce multi-factor authentication (MFA) for any accounts involved in the incident to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems were affected.
+- Implement enhanced logging policies to capture detailed audit logs of all administrative actions within Azure applications for future investigations.
+- Integrate security information and event management (SIEM) solutions to correlate Azure audit logs with other security events for comprehensive threat detection.
+- Restore the Azure application to its last known good configuration if any unauthorized changes were detected during the investigation.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
+- Apply hardening measures such as least privilege access, regular review of application owners, and continuous monitoring to reduce the risk of unauthorized privilege escalation.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 21
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
index cdb7081845a..84cf1217c45 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,50 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "User Added as Owner for Azure Service Principal"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 User Added as Owner for Azure Service Principal
+
+Azure service principals are crucial for managing application permissions within a tenant, dictating access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over app permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific service principal and user account involved in the owner addition event.
+- Verify the event timestamp to determine when the owner addition occurred and correlate it with other activities in the audit logs.
+- Check the event.dataset field to ensure it matches azure.auditlogs, confirming the source of the log data.
+- Investigate the azure.auditlogs.operation_name field to confirm the operation was "Add owner to service principal" and the event.outcome field to ensure it was a success.
+- Examine the Azure AD sign-in logs for the user account to identify any unusual login patterns or locations around the time of the event.
+- Use Osquery to gather additional context on the user account by running a query such as: `SELECT * FROM users WHERE username = '<username>';` to retrieve user details and recent activity.
+- Review the permissions and roles assigned to the service principal to assess the potential impact of the new owner addition.
+- Check for any recent changes to the application associated with the service principal, including modifications to permissions or configurations.
+- Investigate any other recent audit log entries related to the service principal or user account to identify potential patterns or additional suspicious activities.
+- Consult with the application owner or relevant stakeholders to verify if the owner addition was authorized and aligns with expected changes or maintenance activities.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may frequently add users as owners to service principals as part of regular maintenance or updates. To manage this, create exceptions for known administrative accounts or specific service principals that are regularly updated.
+- Automated processes: Some organizations use automated scripts or tools to manage service principal ownership, which can trigger false positives. Identify and exclude these automated processes by filtering based on known script or tool identifiers.
+- Third-party integrations: Certain third-party applications may require ownership changes to function correctly. Review and whitelist these applications by their service principal IDs to prevent unnecessary alerts.
+- Organizational changes: During periods of organizational restructuring, ownership changes may occur more frequently. Temporarily adjust the rule sensitivity or add exceptions for specific departments undergoing changes to reduce false positives.
+
+### Response and remediation
+
+- Immediately revoke the newly added owner's permissions to prevent further unauthorized access or changes to the service principal.
+- Conduct a thorough investigation to determine how the unauthorized addition occurred, including reviewing audit logs and identifying the source of the change.
+- Verify the integrity of the service principal and associated applications to ensure no malicious configurations or permissions have been set.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or service principals have been compromised.
+- Implement conditional access policies to restrict who can modify service principal ownership and enforce multi-factor authentication for privileged actions.
+- Enhance logging and monitoring by integrating Azure Security Center and Azure Sentinel to provide real-time alerts and deeper insights into suspicious activities.
+- Review and update access control policies to ensure the principle of least privilege is enforced across all service principals and associated resources.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Restore the system to its operational state by ensuring all service principals and applications are configured correctly and securely.
+- Implement hardening measures such as regular audits of service principal permissions and continuous security training for administrators to prevent future incidents.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
index c57337e5f17..ea5691caa57 100644
--- a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
+++ b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -17,7 +17,51 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Rolebindings Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Azure Kubernetes Rolebindings Created
+
+Azure Kubernetes role bindings are crucial for managing access control by linking users or service accounts to specific roles within a cluster. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others to high-privilege roles like cluster-admin. The detection rule monitors activity logs for role binding creation events, flagging successful operations that could indicate unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the activity logs to confirm the presence of the role binding creation event by checking the `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name` fields for the specific operations related to role bindings and cluster role bindings.
+- Verify the `event.outcome` field to ensure the operation was successful, as this indicates the role binding was indeed created.
+- Identify the user or service account responsible for the role binding creation by examining the `azure.activitylogs.caller` field to determine if the action was performed by an authorized entity.
+- Check the `azure.activitylogs.resource` field to understand which specific role or cluster role was assigned and to whom, providing insight into potential privilege escalation.
+- Investigate the historical activity of the identified user or service account to determine if there are any patterns of suspicious behavior or previous unauthorized access attempts.
+- Use Osquery to gather additional context on the Kubernetes cluster by running a query such as: `SELECT * FROM kubernetes_rolebindings WHERE name = '<rolebinding_name>';` to retrieve detailed information about the role binding.
+- Cross-reference the role binding creation event with other security logs and alerts to identify any correlated activities that might indicate a broader attack or compromise.
+- Assess the current permissions and roles assigned to the user or service account involved in the role binding creation to evaluate if they have been granted excessive privileges.
+- Review any recent changes to the cluster's RBAC policies or configurations that might have inadvertently allowed unauthorized role binding creation.
+- Consult with the cluster administrators or security team to verify if the role binding creation was part of a legitimate change or deployment process, ensuring alignment with organizational policies.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular operations by authorized personnel, such as creating role bindings for legitimate service accounts or users, can trigger alerts. To manage these, identify and document routine administrative activities and create exceptions for these specific actions in the detection rule.
+- Automated deployment tools: Continuous integration and deployment pipelines often create role bindings as part of their normal operation. Review and whitelist these tools by identifying their specific service accounts or user identities to prevent unnecessary alerts.
+- Third-party integrations: Some third-party applications or services may require role bindings to function correctly. Evaluate these integrations and, if deemed non-threatening, add them to an exception list based on their unique identifiers or operation patterns.
+- Testing environments: Development and testing environments may frequently create and modify role bindings as part of testing processes. Consider excluding these environments from monitoring or adjusting the sensitivity of alerts for these specific clusters to reduce noise.
+- Scheduled maintenance: During scheduled maintenance windows, role bindings might be created or modified as part of system updates or configuration changes. Document these maintenance activities and temporarily adjust alerting rules to avoid false positives during these periods.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation.
+- Review the activity logs to identify the source of the role binding creation and determine if it was authorized or part of a malicious activity.
+- Revoke any unauthorized role bindings or cluster role bindings that have been created, especially those granting high privileges like cluster-admin.
+- Conduct a thorough investigation to identify any other potential security breaches or compromised accounts within the cluster.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data have been affected.
+- Implement enhanced logging and monitoring for Kubernetes role binding activities to detect future unauthorized changes promptly.
+- Integrate security information and event management (SIEM) tools to correlate Kubernetes activity logs with other security events for comprehensive threat detection.
+- Restore the system to its operational state by reapplying legitimate role bindings and ensuring all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
+- Implement hardening measures such as role-based access control (RBAC) policies, network segmentation, and regular security audits to reduce the attack surface.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/beaconing/command_and_control_beaconing.toml b/rules/integrations/beaconing/command_and_control_beaconing.toml
index 9d4a5ba44d8..cedf60cd009 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,49 @@ not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "
                    "agentbeat" or "dnf" or "yum" or "apt"
                   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity
+
+Statistical models analyze network traffic patterns to identify anomalies indicative of command-and-control (C2) beaconing, a technique used by attackers to maintain covert communication with compromised systems. Adversaries exploit this by sending periodic signals to C2 servers, often mimicking legitimate traffic. The detection rule filters out known benign processes, focusing on unusual beaconing patterns to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the timestamp, source IP, destination IP, and any associated user accounts.
+- Verify the process name involved in the alert to ensure it is not one of the known benign processes listed in the query filter.
+- Analyze network traffic logs to identify patterns or anomalies in the communication frequency, size, and timing that may indicate beaconing behavior.
+- Cross-reference the destination IP address with threat intelligence databases to check for any known malicious activity or associations with C2 infrastructure.
+- Use Osquery to gather additional context on the process involved in the alert. For example, run the following query to list network connections for the suspicious process: `SELECT pid, local_address, local_port, remote_address, remote_port, state FROM process_open_sockets WHERE pid = <suspicious_process_id>;`
+- Investigate the parent process of the suspicious activity to determine if it was spawned by a legitimate application or another potentially malicious process.
+- Check the system's event logs for any unusual activity or errors around the time of the alert that could provide additional context or indicators of compromise.
+- Examine the file system for any new or modified files associated with the suspicious process, which may indicate payload delivery or data exfiltration.
+- Review user activity logs to determine if the user associated with the alert was performing any unusual actions or accessing sensitive data.
+- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Known false positives for the Statistical Model Detected C2 Beaconing Activity rule include legitimate applications that exhibit periodic network communication patterns similar to C2 beaconing. These applications often include system monitoring tools, cloud service agents, and software update services.
+- Users can manage these false positives by creating exceptions for processes that are known to generate benign beaconing patterns. This can be done by adding these processes to the exclusion list within the detection rule, ensuring that legitimate traffic is not flagged as suspicious.
+- Regularly review and update the exclusion list to accommodate new software or updates to existing applications that may alter their network communication behavior.
+- Consider the context of the network environment and the typical behavior of applications in use. For instance, if a new application is introduced that mimics beaconing patterns, assess its legitimacy before adding it to the exclusion list.
+- Collaborate with IT and security teams to identify and document legitimate processes that may trigger false positives, ensuring that the detection rule remains effective without compromising security.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with the C2 server and limit potential data exfiltration.
+- Conduct a thorough investigation of the affected system to identify any malicious processes or files, leveraging endpoint detection and response (EDR) tools.
+- Analyze network traffic logs to identify any other systems that may be communicating with the same C2 server, expanding the scope of the investigation if necessary.
+- Remove any identified malicious software or files from the affected system and apply security patches to address any vulnerabilities exploited by the attacker.
+- Change passwords and credentials that may have been compromised, focusing on accounts with elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring policies to capture detailed network and endpoint activity, aiding in future detection and investigation efforts.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of known C2 infrastructure and tactics.
+- Restore the system to its operational state by reinstalling the operating system if necessary and ensuring all security measures are in place.
+- Apply hardening measures such as disabling unnecessary services, enforcing least privilege access, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
index aaef19e8d11..713b0cd09d4 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,49 @@ type = "query"
 query = '''
 beacon_stats.beaconing_score: 3
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity with High Confidence
+
+Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic where attackers maintain covert communication with their servers. Adversaries exploit this to issue commands, exfiltrate data, and sustain network presence. The detection rule flags high-confidence beaconing activity by scoring traffic patterns, aligning with known C2 tactics and techniques.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the timestamp, source and destination IP addresses, and any associated user accounts.
+- Examine the `beacon_stats.beaconing_score` field to assess the severity and confidence level of the detected activity.
+- Correlate the detected IP addresses with known threat intelligence feeds to check for any matches with known malicious C2 servers.
+- Use network traffic analysis tools to inspect the traffic patterns associated with the flagged IP addresses, focusing on regular intervals or unusual data transfer patterns.
+- Investigate the processes and applications on the affected host(s) using Osquery to identify any suspicious or unauthorized software. Example Osquery query: `SELECT name, path, pid FROM processes WHERE pid IN (SELECT pid FROM listening_ports WHERE address = '<flagged IP address>');`
+- Check for any recent changes or anomalies in the system logs of the affected host(s) that might indicate compromise or unauthorized access.
+- Analyze DNS query logs to identify any unusual or frequent DNS requests to domains associated with the flagged IP addresses.
+- Review user activity logs to determine if any unauthorized or unusual actions were performed by the user accounts associated with the alert.
+- Investigate any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or correlations with other suspicious activities.
+- Consult with threat intelligence teams or resources to gather additional context or insights into the potential threat actor's tactics, techniques, and procedures (TTPs) associated with the detected C2 activity.
+
+### False positive analysis
+
+- Known false positives for the Statistical Model Detected C2 Beaconing Activity with High Confidence rule may include legitimate applications or services that regularly communicate with external servers, such as software updates, cloud services, or telemetry data transmissions. These activities can mimic C2 beaconing patterns due to their periodic nature.
+- To manage these false positives, users can create exceptions for specific IP addresses or domains known to be associated with legitimate services. This can be done by maintaining a whitelist of trusted sources and updating it regularly to ensure that benign traffic is not flagged as malicious.
+- Users should also consider analyzing the frequency and timing of the detected beaconing activity. If the pattern aligns with known update schedules or business operations, it may be a candidate for exclusion.
+- Implementing network segmentation and monitoring can help differentiate between legitimate and suspicious traffic, allowing for more accurate identification of false positives.
+- Regularly reviewing and updating the statistical model's parameters and thresholds can help reduce the occurrence of false positives by better aligning the detection criteria with the organization's specific network environment and traffic patterns.
+
+### Response and remediation
+
+- Isolate the affected systems from the network to prevent further communication with the C2 server and contain the threat.
+- Conduct a thorough investigation of the affected systems to identify the scope of the compromise, focusing on network traffic logs and endpoint activity.
+- Utilize MITRE ATT&CK framework details to understand the adversary's tactics, techniques, and procedures, specifically focusing on TA0011 and T1102, to anticipate potential attacker actions.
+- Remove any identified malicious software or scripts from the affected systems and ensure all unauthorized access points are closed.
+- Change all credentials and authentication tokens that may have been exposed or compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Implement enhanced logging policies to capture detailed network traffic and endpoint activity for future investigations, ensuring logs are stored securely and are easily accessible.
+- Integrate threat intelligence feeds and anomaly detection tools to improve the detection of similar threats in the future.
+- Restore the affected systems from clean backups, ensuring that all security patches and updates are applied before reconnecting to the network.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and stricter access controls, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/container_workload_protection.toml b/rules/integrations/cloud_defend/container_workload_protection.toml
index af8cc879b82..2e99a1d4fce 100644
--- a/rules/integrations/cloud_defend/container_workload_protection.toml
+++ b/rules/integrations/cloud_defend/container_workload_protection.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/05"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,4 +37,47 @@ type = "query"
 query = '''
 event.kind:alert and event.module:cloud_defend
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Container Workload Protection
+
+Container Workload Protection is crucial for securing containerized environments by monitoring and defending against threats. Adversaries may exploit vulnerabilities in container orchestration or misconfigurations to gain unauthorized access or execute malicious code. The detection rule identifies suspicious activities by generating alerts when specific cloud defense events are triggered, enabling swift investigation and response.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `event.kind:alert` and `event.module:cloud_defend` fields to confirm the alert's origin and type.
+- Check the timestamp of the alert to determine when the suspicious activity occurred and correlate it with any known changes or events in the environment.
+- Identify the container and host involved in the alert by examining metadata such as container ID, image name, and host IP address.
+- Investigate recent changes or deployments in the container orchestration platform that might have introduced vulnerabilities or misconfigurations.
+- Use Osquery to gather additional information about the container environment. For example, run the following query to list all running containers and their associated images: `SELECT id, name, image FROM docker_containers;`
+- Analyze logs from the container orchestration system (e.g., Kubernetes, Docker) to identify any unusual activities or errors around the time of the alert.
+- Cross-reference the alert with other security tools and logs to identify any related alerts or indicators of compromise.
+- Investigate the user accounts and roles involved in the alert to ensure they have appropriate permissions and have not been compromised.
+- Examine network traffic logs to detect any unusual or unauthorized connections to or from the container.
+- Review historical data for similar alerts to identify patterns or recurring issues that might indicate a broader security concern.
+
+### False positive analysis
+
+- Alerts may be triggered by routine administrative tasks or benign activities within the container environment, such as regular updates or maintenance operations, which are not indicative of malicious behavior.
+- Automated deployment processes or continuous integration/continuous deployment (CI/CD) pipelines might generate alerts due to frequent changes and updates, which can be mistaken for suspicious activity.
+- Misconfigured security tools or overly sensitive alert thresholds can lead to false positives by flagging normal container orchestration activities as threats.
+- To manage these false positives, users can create exceptions for known non-threatening behaviors by adjusting alert thresholds or excluding specific event types that are consistently identified as benign.
+- Regularly review and update the list of exceptions to ensure that new legitimate activities are not mistakenly flagged as threats, while maintaining vigilance against potential new attack vectors.
+
+### Response and remediation
+
+- Immediately isolate the affected container or node to prevent further unauthorized access or execution of malicious code.
+- Conduct a thorough investigation of the alert by reviewing logs and events associated with the container workload to identify the source and nature of the threat.
+- Remediate identified vulnerabilities or misconfigurations in the container orchestration environment to prevent similar incidents in the future.
+- Escalate the incident to the security operations team if the threat is determined to be part of a larger attack or if it involves sensitive data.
+- Implement enhanced logging policies to capture detailed information about container activities and network communications for future investigations.
+- Integrate additional security tools and services, such as intrusion detection systems or threat intelligence platforms, to improve threat detection capabilities.
+- Restore the affected container or node to its operational state by redeploying from a known good image and verifying the integrity of the application and data.
+- Apply security patches and updates to the container orchestration platform and underlying infrastructure to address known vulnerabilities.
+- Conduct a post-incident review to analyze the response process and identify areas for improvement in detection and response strategies.
+- Implement hardening measures, such as network segmentation and least privilege access controls, to reduce the attack surface of the containerized environment."""
 
diff --git a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
index da057f623e1..ec85708e77b 100644
--- a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/28"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,48 @@ process where event.module == "cloud_defend" and
 (process.name : ("grep", "egrep", "fgrep", "find", "locate", "mlocate") or process.args : ("grep", "egrep", "fgrep", "find", "locate", "mlocate")) and 
 process.args : ("*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", "*access_key*", "*.aws/credentials*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Credentials Searched For Inside A Container
+
+Containers often house applications that interact with AWS services, necessitating the storage of AWS credentials. Adversaries may exploit this by using search utilities to locate these credentials, potentially leading to unauthorized access. The detection rule identifies suspicious use of search tools within containers, focusing on attempts to locate AWS credential files, thus helping to thwart credential theft and subsequent attacks.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific container and process that triggered the rule, focusing on the `process.name` and `process.args` fields to understand which search utility was used and what specific AWS credential patterns were targeted.
+- Examine the `event.module` and `event.type` fields to confirm the context of the event, ensuring it aligns with the expected behavior of a container environment.
+- Check the container's metadata and logs to gather information about the container's purpose, owner, and any recent changes or deployments that might explain the search activity.
+- Investigate the user or service account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Use Osquery to list all running processes within the container to identify any other potentially malicious or unexpected processes. Example query: `SELECT pid, name, cmdline FROM processes WHERE name IN ('grep', 'find', 'locate');`
+- Analyze the container's file system to check for the presence of AWS credential files and verify their integrity and access permissions.
+- Review network logs to identify any outbound connections from the container that might indicate data exfiltration or communication with unauthorized external services.
+- Correlate the event with other security alerts or logs from the same timeframe to identify any patterns or related suspicious activities within the container or across the environment.
+- Investigate the history of the container image to ensure it has not been tampered with or contains embedded malicious scripts or tools.
+- Consult with the development or operations team responsible for the container to verify if the search activity was part of legitimate troubleshooting or maintenance tasks.
+
+### False positive analysis
+
+- Developers or system administrators may legitimately use search utilities like grep or find to locate AWS credentials for debugging or configuration purposes within a container. These actions, while benign, can trigger the detection rule.
+- Automated scripts or configuration management tools that verify the presence of AWS credentials as part of routine checks may also be flagged as suspicious activity.
+- To manage these false positives, users can create exceptions for specific containers or processes known to perform legitimate searches for AWS credentials. This can be done by whitelisting certain process names or arguments that are part of routine operations.
+- Users should regularly review and update their exception lists to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any unauthorized access to AWS resources.
+- Review container logs and AWS CloudTrail logs to trace any suspicious activities or access patterns related to the compromised credentials.
+- Revoke and rotate the compromised AWS credentials to prevent further unauthorized access.
+- Escalate the incident to the security operations team and relevant stakeholders, providing them with detailed findings and potential impacts.
+- Implement enhanced logging and monitoring for container environments, ensuring that all access to sensitive files and credentials is logged and reviewed regularly.
+- Integrate security tools that provide real-time alerts for suspicious activities within containers, such as unauthorized searches for credentials.
+- Restore the container to its operational state by redeploying it from a known good image, ensuring that all security patches and configurations are up to date.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
+- Apply hardening measures to container environments, such as using environment variables for credentials, implementing least privilege access, and regularly scanning for vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
index ad37dcc18f5..7b7524bb177 100644
--- a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ and process.args: (
 "/etc/shadow",
 "/etc/gshadow")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Sensitive Files Compression Inside A Container
+
+Containers encapsulate applications and their dependencies, often containing sensitive files like credentials and configurations. Adversaries exploit compression utilities within containers to exfiltrate these files, bypassing security controls. The detection rule identifies suspicious compression activities by monitoring process executions and arguments for known utilities and sensitive file paths, alerting analysts to potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific container ID (`container.id`) where the suspicious activity was detected.
+- Examine the `process.name` and `process.args` fields to determine which compression utility was used and what specific files were targeted.
+- Check the `event.type` field to confirm the process start event and gather additional context about the timing and frequency of the activity.
+- Use Osquery to list all running processes within the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE container_id = '<container.id>');`
+- Investigate the container's history and logs to identify any recent changes or deployments that might have introduced vulnerabilities.
+- Analyze the container's network activity to detect any unusual outbound connections that could indicate data exfiltration.
+- Review the container's file system for any newly created or modified files that could be related to the compression activity.
+- Check for any other alerts or anomalies associated with the same container or host to identify potential patterns or related incidents.
+- Verify the integrity and permissions of the sensitive files listed in the `process.args` to ensure they have not been altered or accessed inappropriately.
+- Consult with the development or operations team to understand the expected behavior of the container and confirm whether the detected activity aligns with legitimate use cases.
+
+### False positive analysis
+
+- Routine backup processes: Automated scripts or scheduled tasks that compress sensitive files for backup purposes may trigger alerts. Users can handle these by identifying and excluding specific backup processes or scripts from the rule.
+- Development and testing activities: Developers or system administrators might compress sensitive files during testing or development within containers. To manage this, users can create exceptions for known development environments or user accounts.
+- Configuration management tools: Tools like Ansible, Puppet, or Chef might compress configuration files as part of their operations. Users should identify these tools and exclude their activities from the rule to prevent false positives.
+- Container orchestration tasks: Orchestration platforms like Kubernetes might perform legitimate compression tasks for configuration management. Users can exclude specific container IDs or orchestration-related processes to reduce false positives.
+- Security audits and compliance checks: Security teams might intentionally compress sensitive files for audit purposes. Users should coordinate with security teams to whitelist these activities and avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further data exfiltration and unauthorized access.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on logs and process execution details related to the detected compression activity.
+- Review and analyze the container's file system to identify any additional unauthorized changes or access to sensitive files.
+- Remove any unauthorized compression utilities or scripts found within the container to prevent further exploitation.
+- Rotate and update all credentials and keys that may have been exposed, including SSH keys, AWS credentials, and Docker configurations.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat actor has accessed other parts of the network.
+- Implement enhanced logging and monitoring within the container environment to detect similar activities in the future, focusing on process execution and file access patterns.
+- Integrate security tools with container orchestration platforms to automate the detection and response to suspicious activities.
+- Restore the container from a known good backup to ensure the system is free from any malicious modifications.
+- Apply hardening measures such as restricting access to sensitive files, using least privilege principles, and regularly updating container images to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
index dc8fd0b0b06..e87cec7ada7 100644
--- a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,49 @@ or
     and process.args : ("*id_rsa*", "*id_dsa*")
 ))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Sensitive Keys Or Passwords Searched For Inside A Container
+
+Containers encapsulate applications, isolating them from the host system, but they can still be vulnerable to attacks. Adversaries may exploit search utilities like grep and find to locate sensitive keys or passwords within a container, potentially leading to unauthorized access or container escape. The detection rule identifies suspicious use of these utilities by monitoring process activities and arguments, flagging attempts to search for private keys or password patterns, thus helping to prevent credential theft and maintain container security.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific container ID (`container.id`) where the suspicious activity was detected. This will help in focusing the investigation on the affected container.
+- Examine the process name (`process.name`) and arguments (`process.args`) to determine which utility (e.g., grep, find) was used and what specific patterns or files were being searched for. This can provide insight into the intent of the search.
+- Check the event type (`event.type`) to confirm that the process was indeed started, which indicates active execution of the search command.
+- Investigate the user context under which the process was executed to determine if it was initiated by a legitimate user or a potential adversary. This can be done by reviewing user-related logs or metadata.
+- Use Osquery to gather more information about the container environment. For example, run the following query to list all running processes within the container: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_events WHERE container_id = '<container.id>');`
+- Analyze the command history within the container, if available, to identify any previous commands that might indicate reconnaissance or preparatory actions leading up to the alert.
+- Review network activity logs associated with the container to identify any unusual outbound connections that might suggest data exfiltration attempts.
+- Check for any recent changes to the container's filesystem, especially in directories where sensitive keys or passwords are typically stored, to identify potential tampering or unauthorized access.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns that could indicate a broader attack.
+- Consult threat intelligence sources to determine if there are any known campaigns or adversaries that use similar tactics, techniques, and procedures (TTPs) as those detected in the alert.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use grep or find to search for configuration files or logs that contain keywords like "pass" or "user" as part of regular maintenance or troubleshooting, which can trigger false positives.
+- Automated scripts: Some automated scripts or monitoring tools might use these utilities to check for the presence of certain files or strings as part of their normal operation, leading to benign alerts.
+- Development and testing: Developers working within containers might search for test keys or placeholder passwords during development, which are not indicative of malicious activity.
+- Excluding known safe processes: Users can handle these false positives by creating exceptions for specific processes or scripts that are known to perform these searches as part of their legitimate function, ensuring that only unexpected or unauthorized searches are flagged.
+- Contextual analysis: Reviewing the context in which the search utilities are used, such as the user account executing the command or the time of execution, can help differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential container breakout.
+- Conduct a thorough investigation to identify the source of the suspicious activity, including reviewing logs and process histories within the container.
+- Verify if any sensitive keys or passwords have been accessed or exfiltrated, and rotate any compromised credentials promptly.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other containers or the host system.
+- Implement enhanced logging within the container environment to capture detailed process activities and access patterns for future investigations.
+- Integrate security monitoring tools with centralized logging solutions to ensure real-time alerting and correlation of suspicious activities.
+- Review and update container security policies to enforce least privilege access and restrict the use of search utilities to trusted users only.
+- Apply security patches and updates to the container image and underlying host system to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and develop a plan to address these weaknesses.
+- Educate development and operations teams on secure coding practices and the importance of safeguarding sensitive information within containers."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
index 14581165c8e..022d5792c85 100644
--- a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/06"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,49 @@ type = "eql"
 query = '''
 file where event.module== "cloud_defend" and event.type != "deletion" and file.path== "/etc/ld.so.preload"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Dynamic Linker Preload Shared Object Inside A Container
+
+The dynamic linker in Linux loads necessary libraries for programs at runtime, with the `ld.so.preload` file specifying libraries to load first. Adversaries exploit this by redirecting it to malicious libraries, gaining unauthorized access and evading detection. The detection rule identifies suspicious modifications to this file within containers, signaling potential hijacking attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.module is "cloud_defend" and the event.type is not "deletion" to ensure the alert is relevant to the modification of the ld.so.preload file.
+- Verify the file path in the alert to confirm it is "/etc/ld.so.preload" to ensure the correct file is being investigated.
+- Check the timestamp of the modification event to determine when the suspicious activity occurred.
+- Identify the container ID or name where the modification took place to focus the investigation on the specific container environment.
+- Investigate the user or process that initiated the modification by examining the user.id and process.name fields in the alert data.
+- Use Osquery to list all processes running in the container at the time of the modification with a query like: `SELECT pid, name, path FROM processes WHERE container_id = '<container_id>';`
+- Examine the contents of the modified /etc/ld.so.preload file to identify any suspicious or unauthorized libraries being loaded.
+- Cross-reference the libraries listed in the modified ld.so.preload file with known malicious libraries or hashes to assess potential threats.
+- Review recent logs and events from the container for any other suspicious activities or anomalies around the time of the modification.
+- Investigate any network connections or data transfers initiated by the container around the time of the modification to identify potential data exfiltration or command and control activities.
+
+### False positive analysis
+
+- Routine updates or legitimate software installations within a container might modify the `ld.so.preload` file as part of their normal operation, leading to false positives. Users should verify if the modification aligns with known update or installation activities.
+- Some containerized applications may intentionally use the `ld.so.preload` mechanism for performance optimization or compatibility reasons. Users can create exceptions for these specific applications by identifying their typical behavior patterns and excluding them from the rule.
+- Automated configuration management tools or scripts that manage library paths might inadvertently trigger this rule. Users should review these tools' activities and whitelist them if they are confirmed to be non-malicious.
+- In development environments, developers might modify the `ld.so.preload` file for testing purposes. Users can exclude these environments from the rule or set up alerts to be less sensitive during known development periods.
+- To manage false positives, users can implement a monitoring period to establish a baseline of normal behavior, then adjust the rule to exclude these patterns while maintaining vigilance for truly suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or execution of malicious code.
+- Conduct a thorough investigation to identify any malicious libraries specified in the /etc/ld.so.preload file and assess the extent of the compromise.
+- Remove any unauthorized or malicious entries from the /etc/ld.so.preload file and replace them with legitimate libraries if necessary.
+- Review container logs and system logs to trace the source of the modification and identify any other potentially compromised containers or systems.
+- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a broader campaign.
+- Restore the container from a known good backup or image to ensure the system is free from any malicious modifications.
+- Implement stricter access controls and monitoring on critical files like /etc/ld.so.preload to prevent unauthorized modifications in the future.
+- Enhance logging policies to capture detailed events related to file modifications and access within containers, integrating with SIEM solutions for real-time alerting.
+- Conduct a security review of container configurations and apply hardening measures, such as using read-only file systems and minimizing privileges.
+- Educate and train staff on recognizing and responding to similar threats, leveraging MITRE ATT&CK framework details to understand adversary techniques and tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
index bb9fab55b3f..725db83c43a 100644
--- a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,49 @@ process where container.id: "*" and event.type== "start" and
 (process.args: ("nc", "ncat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab"))
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Network Tool Launched Inside A Container
+
+Containers are lightweight, portable environments that encapsulate applications and their dependencies. Adversaries exploit network tools within containers for reconnaissance or data exfiltration. The detection rule identifies the initiation of known network utilities, either as primary processes or subprocess arguments, signaling potential misuse for malicious network activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific network utility that triggered the rule, using the `process.name` and `process.args` fields to understand which tool was executed.
+- Check the `container.id` field to determine which container the suspicious process was running in, and gather additional context about the container's purpose and the application it hosts.
+- Investigate the `event.type` field to confirm the process start event and ensure that the alert corresponds to a new process initiation.
+- Use Osquery to list all running processes within the container to identify any other potentially suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE container_id = '<container.id>');`
+- Examine the container's creation and start times to determine if the suspicious activity aligns with any recent changes or deployments.
+- Review the container's network connections using Osquery to identify any unusual or unauthorized external communications. Example query: `SELECT * FROM process_open_sockets WHERE container_id = '<container.id>';`
+- Analyze the container's logs for any anomalies or errors around the time the suspicious process was executed, which might provide additional context or indicators of compromise.
+- Check for any recent changes to the container's configuration or image that could have introduced the network tool, such as updates or new deployments.
+- Investigate the user context under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential privilege misuse.
+- Correlate the alert with other security events or alerts in the environment to identify if this activity is part of a broader attack pattern or campaign.
+
+### False positive analysis
+
+- Legitimate administrative tasks: Network utilities like `nmap` or `tcpdump` may be used by system administrators for legitimate network diagnostics or monitoring within containers. Users can handle these by creating exceptions for specific user accounts or container IDs known to perform regular maintenance.
+- Automated testing environments: Continuous integration/continuous deployment (CI/CD) pipelines might use tools like `nc` or `telnet` for testing network connectivity or service availability. Users should consider excluding these processes when they originate from known testing containers or environments.
+- Development and debugging: Developers might use network tools such as `dig` or `nslookup` for debugging DNS issues within development containers. To manage these, users can exclude processes initiated by specific development containers or during known development timeframes.
+- Security tools: Security teams might deploy tools like `masscan` or `zmap` for vulnerability assessments or penetration testing. Users can exclude these activities by whitelisting processes executed by security team accounts or during scheduled security assessments.
+- Monitoring solutions: Some monitoring solutions might use utilities like `tshark` or `ngrep` to capture and analyze network traffic. Users should identify and exclude these processes when they are part of recognized monitoring solutions or services.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further network activity and potential lateral movement within the environment.
+- Conduct a thorough investigation of the container's logs and network traffic to identify any unauthorized access or data exfiltration attempts.
+- Review the process tree and command-line arguments to understand the context in which the suspicious network tool was executed.
+- If malicious activity is confirmed, remove the compromised container and redeploy a clean version from a trusted image.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat extends beyond the container.
+- Implement enhanced logging policies to capture detailed process execution and network activity within containers for future investigations.
+- Integrate container security solutions that provide real-time monitoring and alerting for suspicious activities.
+- Apply security patches and updates to the container images and underlying host systems to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate development and operations teams on secure container practices, emphasizing the importance of using minimal and verified images."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
index 24a7ee25a08..bc8f4306140 100644
--- a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,49 @@ query = '''
 process where container.id: "*" and event.type== "start" 
   and process.name: ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "runc", "systemd", "crictl")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Container Management Utility Run Inside A Container
+
+Container management utilities like Docker and Kubernetes are essential for orchestrating and managing containerized applications. They facilitate deployment, scaling, and operations of application containers. However, adversaries can exploit these utilities to execute unauthorized commands or deploy malicious containers. The detection rule identifies suspicious activity by monitoring for the execution of key container management binaries within a container, which may indicate a security breach or misconfiguration.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific container ID (`container.id`) and process name (`process.name`) that triggered the alert.
+- Verify the legitimacy of the container by checking its origin, such as the image source and the deployment method, to ensure it aligns with expected configurations.
+- Use Osquery to gather more information about the container environment. For example, run the query: `SELECT * FROM docker_containers WHERE id = '<container_id>';` to retrieve details about the container.
+- Investigate the command line arguments and environment variables of the suspicious process to understand its intended actions and context.
+- Check the container's creation and start times to determine if the timing aligns with expected operational activities or if it coincides with any known suspicious events.
+- Examine the user and permissions under which the container management utility was executed to assess if there are any privilege escalation concerns.
+- Review the container's network activity to identify any unusual connections or data transfers that could indicate malicious behavior.
+- Analyze logs from the host system and container runtime to identify any anomalies or patterns that could suggest unauthorized access or actions.
+- Cross-reference the container's activity with other security alerts or incidents to determine if it is part of a broader attack or compromise.
+- Consult with relevant teams or stakeholders to verify if the execution of the container management utility was part of a legitimate operation or if further investigation is warranted.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may run container management utilities inside containers for troubleshooting or maintenance purposes. To handle these, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
+- Automated scripts and CI/CD pipelines: Some automated processes might execute container management commands within containers as part of their normal operation. Users can exclude these by identifying and whitelisting specific scripts or pipeline jobs that are known to perform these actions.
+- Development and testing environments: In development or testing environments, developers might frequently run container management commands inside containers for testing purposes. Users can manage these false positives by excluding specific environments or namespaces where such activities are common.
+- Monitoring and security tools: Certain monitoring or security tools might execute container management commands to gather information or enforce policies. Users should identify these tools and exclude their activities from triggering alerts.
+- Containerized management utilities: In some cases, container management utilities themselves might be containerized for operational reasons. Users can handle these by excluding specific container images or labels associated with these utilities.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or execution of malicious commands.
+- Investigate the container's logs and process history to identify the source and scope of the unauthorized execution.
+- Verify the integrity of the container image and check for any unauthorized modifications or additions.
+- Review access logs and permissions to determine if there was unauthorized access or privilege escalation.
+- Escalate the incident to the security operations team if evidence of compromise is found, following the organization's incident response plan.
+- Implement enhanced logging and monitoring for container management utilities to detect future unauthorized executions.
+- Integrate security tools with container orchestration platforms to automate detection and response to suspicious activities.
+- Restore the container from a known good backup or rebuild it using a verified clean image.
+- Apply security patches and updates to the container management utilities and underlying infrastructure.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
index 64fb497ec44..75c60ee703b 100644
--- a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,48 @@ file where container.id: "*" and event.type in ("change", "creation") and
 (process.name : "chmod" or process.args : "chmod") and 
 process.args : ("*x*", "777", "755", "754", "700") and not process.args: "-x"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File Made Executable via Chmod Inside A Container
+
+Containers isolate applications, ensuring consistent environments. However, adversaries may exploit this by using `chmod` to make files executable, potentially running unauthorized code. The detection rule identifies such actions by monitoring for `chmod` usage that alters file permissions to executable states, flagging suspicious changes that could indicate malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific container ID (`container.id`) where the `chmod` command was executed. This will help in narrowing down the scope of the investigation to the affected container.
+- Examine the `process.name` and `process.args` fields to confirm that the `chmod` command was indeed used and to understand the exact permissions that were set. Look for patterns such as `777`, `755`, `754`, or `700` that indicate executable permissions.
+- Check the `event.type` field to determine whether the file was newly created or if its permissions were changed. This can provide context on whether the file is new or if an existing file was modified.
+- Investigate the parent process of the `chmod` command to understand the context in which it was executed. This can be done by examining the process tree to see if there are any suspicious parent processes.
+- Use Osquery to gather more information about the file that was made executable. For example, run the following Osquery query to list details about the file: `SELECT * FROM file WHERE path = '/path/to/suspicious/file';` Replace `/path/to/suspicious/file` with the actual file path.
+- Check the container's logs for any other suspicious activities around the time the `chmod` command was executed. Look for unusual commands or access patterns that might indicate malicious behavior.
+- Investigate the user account associated with the `chmod` command execution. Determine if the user has a legitimate reason to modify file permissions within the container.
+- Review network activity logs for the container to identify any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
+- Analyze the file that was made executable for any signs of malicious code or scripts. This can involve using static analysis tools or sandboxing the file in a controlled environment.
+- Correlate this event with other security alerts or logs from the same container or user to identify any patterns or repeated attempts to execute unauthorized code.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators or automated scripts may use `chmod` to modify file permissions as part of regular maintenance or deployment processes. These actions, while legitimate, can trigger the rule. To manage this, users can create exceptions for known scripts or administrative accounts that frequently perform these tasks.
+- Software installations and updates: During the installation or update of software within a container, `chmod` may be used to set executable permissions on necessary files. Users can handle these false positives by excluding specific installation or update processes from the rule.
+- Development and testing activities: Developers working within containers might use `chmod` to test scripts or applications, leading to false positives. To address this, users can exclude specific development environments or user accounts from the rule.
+- Container orchestration tools: Tools like Kubernetes or Docker Compose might use `chmod` as part of their operations to ensure proper file permissions. Users can manage these false positives by identifying and excluding the specific processes or tools involved in these operations.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized execution and potential lateral movement within the environment.
+- Conduct a thorough investigation to identify the source and scope of the unauthorized `chmod` command, reviewing logs and process trees for suspicious activity.
+- Verify the integrity of the files that were made executable and check for any unauthorized or malicious code that may have been introduced.
+- Revert any unauthorized changes to file permissions and remove any malicious files or processes identified during the investigation.
+- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if the attack vector is unclear.
+- Implement enhanced logging policies to capture detailed process execution and file permission changes within containers for future investigations.
+- Integrate container security tools that provide real-time monitoring and alerting for suspicious activities, such as unauthorized permission changes.
+- Restore the container to its operational state by redeploying from a known good image and ensuring all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply hardening measures such as restricting the use of `chmod` within containers, implementing least privilege access controls, and using container runtime security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
index 16de26f880e..43cbae17fc8 100644
--- a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,48 @@ process.entry_leader.same_as_process== true and
 /* interactive process */
 process.interactive == true
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Interactive Exec Command Launched Against A Running Container
+
+Containers often use the 'exec' command to run processes within a running container, providing a shell for real-time interaction. Adversaries exploit this to gain unauthorized access, potentially leading to further compromise or escape from the container. The detection rule identifies such threats by monitoring for interactive 'exec' events, focusing on initial processes in containers that indicate potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'exec' command in the container, focusing on the `process.entry_leader.entry_meta.type` field to ensure it is a container process.
+- Verify the `process.interactive` field to confirm that the process was indeed interactive, indicating a real-time shell session was established.
+- Check the `process.entry_leader.same_as_process` field to ensure the process is the initial one run in the container, which could indicate unauthorized access.
+- Investigate the user account associated with the `exec` command to determine if it is a known and authorized user.
+- Examine the command history within the container to identify any suspicious or unauthorized commands executed during the session.
+- Use Osquery to gather additional context about the container environment. For example, run the following query to list all processes running in the container: `SELECT pid, name, path FROM processes WHERE container_id = '<container_id>';`.
+- Analyze network activity from the container during the time of the alert to identify any unusual outbound connections or data exfiltration attempts.
+- Review logs from the container orchestration platform (e.g., Kubernetes) to identify any recent changes or deployments that might explain the interactive session.
+- Cross-reference the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
+- Consult with the application or development team to verify if the interactive session was part of a legitimate maintenance or troubleshooting activity.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use the 'exec' command for legitimate purposes such as debugging, monitoring, or performing maintenance tasks within containers. These activities can trigger the rule but are not malicious. Users can handle these by creating exceptions for known administrative accounts or specific maintenance windows.
+- Automated scripts and tools: Some automated deployment or monitoring tools may use the 'exec' command to perform health checks or updates within containers. These actions can be mistaken for threats. To manage this, users can whitelist specific scripts or tools that are known to perform these actions regularly.
+- Development and testing activities: Developers might use the 'exec' command during the development or testing phases to interact with containers. These actions are typically benign. Users can exclude these activities by setting exceptions for development environments or specific user roles associated with development tasks.
+- Container orchestration platforms: Certain container orchestration platforms might use the 'exec' command as part of their normal operations to manage container lifecycles. Users can address this by identifying and excluding specific processes or commands associated with these platforms.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the environment.
+- Investigate the source of the 'exec' command to determine if it was initiated by a legitimate user or an adversary, checking for any anomalies in user behavior or access patterns.
+- Review container logs and audit trails to identify any suspicious activities or commands executed during the interactive session.
+- If unauthorized access is confirmed, revoke any compromised credentials and review access controls to ensure least privilege principles are enforced.
+- Escalate the incident to the security operations team for further analysis and to determine if the breach extends beyond the container.
+- Implement enhanced logging and monitoring for container environments, focusing on 'exec' commands and other high-risk activities.
+- Integrate security tools with SIEM systems to improve real-time detection and response capabilities for container-related threats.
+- Restore the container to its last known good state from a secure backup, ensuring that any malicious changes are removed.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Apply hardening measures such as disabling unnecessary interactive access, enforcing network segmentation, and using container security solutions to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
index 55c5ccec6c3..2ad6423c76b 100644
--- a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,48 @@ event.action in ("fork", "exec") and event.action != "end"
 process.args: "*/*sh"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Interactive Shell Spawned From Inside A Container
+
+Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries may exploit interactive shells within containers to execute unauthorized commands, potentially leading to container breakout and host compromise. The detection rule identifies such threats by monitoring for shell processes initiated with interactive flags, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of an interactive shell spawned inside a container by checking the `process.executable` and `process.args` fields for shell indicators like `*/*sh` and flags `-i` or `-it`.
+- Verify the `container.id` to identify the specific container involved and gather context about its purpose and the application it is running.
+- Check the `event.type` and `event.action` fields to ensure the process is indeed in a "start" state and initiated by "fork" or "exec" actions, confirming it is an ongoing process.
+- Investigate the `process.entry_leader.same_as_process` field to determine if the shell process is a new entry point, which could indicate an unauthorized access attempt.
+- Use Osquery to list all running processes within the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE container_id = '<container.id>' AND name LIKE '%sh%';`
+- Examine the container's logs for any unusual activities or commands executed around the time the shell was spawned.
+- Check the user context under which the shell was spawned to determine if it aligns with expected user behavior or if it indicates a potential compromise.
+- Investigate network connections from the container using Osquery to identify any suspicious outbound connections. Example query: `SELECT * FROM socket_events WHERE container_id = '<container.id>';`
+- Review the container's image and configuration to ensure it has not been tampered with or altered to allow unauthorized shell access.
+- Correlate the findings with other security alerts or logs from the host system to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Developers or system administrators may intentionally spawn interactive shells within containers for debugging or maintenance purposes, which can trigger the rule. To manage this, users can create exceptions for specific user accounts or container IDs known to perform these actions regularly.
+- Automated scripts or orchestration tools might initiate interactive shells as part of their normal operation, leading to false positives. Users can handle these by identifying and excluding specific process names or arguments associated with these tools.
+- Some containerized applications might inherently require interactive shell access for legitimate functionality, such as certain development environments. Users should document these cases and configure the rule to exclude these specific applications or container images.
+- Continuous integration/continuous deployment (CI/CD) pipelines may execute interactive shells during build or deployment processes. Users can mitigate false positives by setting exceptions for known pipeline processes or by scheduling rule suppression during expected pipeline activity times.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential breakout to the host system.
+- Investigate the container's logs and process history to identify the source and nature of the unauthorized shell access.
+- Terminate any suspicious processes running within the container that are not part of the expected application workflow.
+- Review and update access controls and permissions for the container to ensure only authorized users and processes can initiate interactive shells.
+- Escalate the incident to the security operations team if evidence of a container breakout or host compromise is found.
+- Implement enhanced logging policies to capture detailed process execution and network activity within containers for future investigations.
+- Integrate container security tools with SIEM systems to improve real-time monitoring and alerting capabilities.
+- Restore the container from a known good backup or image to ensure the system is free from any unauthorized modifications.
+- Conduct a post-incident review to identify gaps in security controls and update container hardening measures, such as disabling unnecessary interactive shell access.
+- Educate development and operations teams on secure container practices and the importance of monitoring for suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
index c739bdcdcbf..fd888ad8d71 100644
--- a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,48 @@ process.args: ("nc","ncat","netcat","netcat.openbsd","netcat.traditional")
           or process.args:("-*l*", "--listen", "-*p*", "--source-port")
           )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Netcat Listener Established Inside A Container
+
+Netcat is a versatile networking tool often used for debugging and network exploration. Within container environments, it can be exploited by adversaries to establish unauthorized network connections, acting as a backdoor or facilitating data exfiltration. The detection rule identifies suspicious Netcat activity by monitoring process starts within containers, focusing on specific command-line arguments indicative of a listening service, which may signal malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of Netcat-related process names or arguments, such as "nc", "ncat", "netcat", "netcat.openbsd", or "netcat.traditional", in the process.name or process.args fields.
+- Examine the container ID (container.id) associated with the alert to identify the specific container where the Netcat listener was established.
+- Check the event.type and event.action fields to verify that the process start event corresponds to a "fork" or "exec" action, indicating a new process creation.
+- Investigate the command-line arguments (process.args) for any suspicious flags like "-l", "--listen", "-p", "--source-port", "-c", "--sh-exec", "-e", or "--exec" that suggest a listening service or command execution.
+- Use Osquery to gather additional context about the container environment by running a query such as: `SELECT * FROM processes WHERE name IN ('nc', 'ncat', 'netcat', 'netcat.openbsd', 'netcat.traditional') AND cmdline LIKE '%-l%' AND cmdline LIKE '%-p%';`
+- Analyze the parent process of the Netcat listener to determine how it was initiated and whether it was spawned by a legitimate or suspicious process.
+- Review the network connections associated with the container to identify any unusual or unauthorized connections that may indicate data exfiltration or a backdoor.
+- Check the container's image and configuration to ensure it aligns with expected baselines and does not include unauthorized modifications or additional tools.
+- Investigate the user context under which the Netcat process is running to determine if it aligns with expected user activity or if it indicates potential privilege escalation.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns that could provide further context.
+
+### False positive analysis
+
+- Development and testing environments may frequently use Netcat for legitimate purposes such as debugging or network testing, leading to false positives. Users can handle these by creating exceptions for specific container IDs or process names known to be used in these environments.
+- Automated scripts or tools that utilize Netcat for routine network checks or data transfers might trigger the rule. To manage this, users can exclude specific command-line arguments or process arguments that are consistently associated with these benign activities.
+- Some containerized applications might use Netcat as part of their normal operation for inter-container communication. In such cases, users should identify and whitelist these applications by excluding their specific process names or container IDs from the detection rule.
+- Security tools or monitoring solutions that incorporate Netcat for legitimate network monitoring or penetration testing could also be flagged. Users should document and exclude these tools by adding exceptions for their known process arguments or container environments.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration.
+- Investigate the container's logs and network activity to identify the source and scope of the compromise.
+- Terminate the netcat process and any other unauthorized processes running within the container.
+- Conduct a thorough review of the container's configuration and deployed applications to identify vulnerabilities or misconfigurations that may have been exploited.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other parts of the network.
+- Implement enhanced logging policies to capture detailed process and network activity within containers for future investigations.
+- Integrate threat intelligence feeds and security tools to improve detection capabilities and correlate alerts with known threat actors and tactics.
+- Restore the container from a known good backup or rebuild it using secure configurations and updated software versions.
+- Apply hardening measures such as disabling unnecessary services, enforcing least privilege access, and using network segmentation to limit exposure.
+- Review and update security policies and incident response plans to incorporate lessons learned from the incident and improve readiness for future threats."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
index d4cdae3dcc6..de2a7d81f22 100644
--- a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,48 @@ process.entry_leader.entry_meta.type: "sshd"  and
 /* interactive process*/
 process.interactive== true
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SSH Connection Established Inside A Running Container
+
+SSH (Secure Shell) is a protocol used to securely access and manage systems remotely. Within containerized environments, running an SSH daemon is generally discouraged due to security risks. Adversaries may exploit SSH to gain unauthorized access or maintain persistence by leveraging stolen credentials. The detection rule identifies SSH sessions initiated within containers by monitoring for SSH daemon processes that start new interactive sessions, indicating potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `container.id` and ensure the event type is "start" to verify the context of the SSH connection.
+- Check the `process.entry_leader.entry_meta.type` field to confirm that the process is indeed "sshd", indicating an SSH daemon is involved.
+- Investigate the `process.entry_leader.same_as_process` and `process.session_leader.same_as_process` fields to determine if the SSH session is the initial process or a new session within the container.
+- Verify the `process.interactive` field to ensure the process is interactive, which could indicate an active user session.
+- Use Osquery to list all running processes within the container to identify any suspicious or unexpected processes. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address IS NOT NULL);`
+- Examine the container's logs for any unusual activity or errors around the time the SSH connection was established.
+- Check for any recent changes to the container's configuration or image that might have introduced vulnerabilities or unauthorized access points.
+- Investigate the source IP address of the SSH connection to determine if it is from a known or trusted network.
+- Review user access logs and authentication attempts to identify any unauthorized or failed login attempts that could indicate credential theft.
+- Correlate the event with other security alerts or logs to identify any patterns or related activities that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- **Development and Testing Environments**: In some development or testing scenarios, SSH might be intentionally used within containers for debugging or administrative purposes. Users can handle these by creating exceptions for specific containers or environments where SSH usage is expected and authorized.
+- **Automated Maintenance Tasks**: Certain automated scripts or maintenance tasks might use SSH to perform updates or configurations within containers. To manage these, users can whitelist specific processes or scripts known to perform legitimate maintenance activities.
+- **Containerized SSH Services**: Some organizations might run legitimate SSH services within containers as part of their infrastructure. In such cases, users should document and exclude these specific containers or services from triggering alerts, ensuring that only unauthorized SSH activities are flagged.
+- **Monitoring and Security Tools**: Security or monitoring tools that use SSH to gather data from containers might trigger false positives. Users should identify these tools and configure the detection rule to exclude their activities, ensuring that only unexpected SSH connections are detected.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
+- Investigate the source of the SSH connection by reviewing logs to identify the IP address and user credentials used for the connection.
+- Verify the integrity of the container by checking for any unauthorized changes or additional processes that may have been initiated.
+- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent further unauthorized access.
+- Escalate the incident to the security operations team for a thorough investigation and to determine if other containers or systems have been compromised.
+- Implement network segmentation to limit access to critical containers and reduce the attack surface.
+- Enhance logging policies to ensure comprehensive monitoring of SSH connections and container activities, including detailed audit logs.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the container to its operational state by redeploying it from a known good image and ensuring all security patches are applied.
+- Apply hardening measures such as disabling SSH daemon in containers, using non-root users, and implementing multi-factor authentication for remote access."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
index 5ed644ebed5..22493e7eda9 100644
--- a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,49 @@ process where container.id: "*" and event.type== "start" and
 event.action in ("fork", "exec") and event.action != "end" and 
 process.name: ("sshd", "ssh", "autossh")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SSH Process Launched From Inside A Container
+
+SSH, a protocol for secure remote access, is crucial in managing systems but poses risks when used inside containers. Adversaries exploit SSH to move laterally or establish persistence. The detection rule identifies SSH processes initiated within containers, signaling potential misuse. It monitors process starts, focusing on SSH-related binaries, to alert on unauthorized or suspicious activity.
+
+### Possible investigation steps
+
+- Verify the container ID by examining the `container.id` field to identify which container initiated the SSH process.
+- Check the `process.name` field to determine whether the process is `ssh`, `sshd`, or `autossh`, and assess the potential risk based on the specific binary used.
+- Review the `event.type` and `event.action` fields to confirm the process start and ensure it aligns with the expected behavior of the container.
+- Investigate the parent process of the SSH process to understand how it was initiated and whether it was expected or authorized.
+- Use Osquery to gather more information about the container environment. For example, run the query: `SELECT * FROM processes WHERE name IN ('ssh', 'sshd', 'autossh') AND pid = <PID>;` to get details about the SSH process.
+- Examine the container's network connections to identify any unusual or unauthorized connections that may have been established using SSH.
+- Check the container's logs for any signs of unauthorized access or suspicious activity around the time the SSH process was started.
+- Investigate the user context under which the SSH process was initiated to determine if it was executed by a legitimate user or potentially compromised credentials.
+- Review the history of the container's image and configuration to ensure there are no vulnerabilities or misconfigurations that could have been exploited.
+- Correlate the event with other security alerts or logs to identify any patterns or related activities that could indicate a broader attack or compromise.
+
+### False positive analysis
+
+- **Development and Testing Environments**: In some development or testing environments, SSH might be used legitimately for debugging or administrative tasks within containers. Users can handle these by creating exceptions for specific container IDs or environments where SSH usage is expected and authorized.
+- **Automated Maintenance Tasks**: Automated scripts or maintenance tasks might use SSH to perform updates or backups within containers. To manage these, users can exclude processes initiated by known maintenance scripts or from specific source IPs associated with trusted automation tools.
+- **Containerized SSH Services**: Some applications might intentionally run SSH services within containers for specific use cases, such as providing secure access to containerized applications. Users should document and exclude these known services by specifying the container names or image IDs that are expected to run SSH processes.
+- **Monitoring and Security Tools**: Security or monitoring tools might use SSH to gather data or perform security checks within containers. Users can manage these false positives by identifying and excluding processes started by these tools, often identifiable by specific user accounts or process arguments.
+- **Legacy Systems**: In environments with legacy systems, SSH might be used as a workaround for certain functionalities. Users should assess the necessity of these practices and, if deemed non-threatening, exclude them by defining exceptions based on process arguments or container labels.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further lateral movement or potential breakout to the host system.
+- Investigate the source of the SSH process by reviewing container logs and identifying any unauthorized access or suspicious activity.
+- Verify the integrity of the container image and check for any unauthorized modifications or additional binaries.
+- Revoke any compromised SSH credentials and enforce the use of strong, unique passwords or SSH keys for access.
+- Escalate the incident to the security operations team if there is evidence of a container breakout or if multiple containers are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity within containers for future investigations.
+- Integrate with security information and event management (SIEM) systems to correlate container activity with other security events across the environment.
+- Restore the container from a known good backup or rebuild it using a verified secure image to ensure no persistence mechanisms remain.
+- Apply container hardening measures, such as disabling SSH access within containers and using network policies to restrict inter-container communication.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
index 30220e18f92..f0a5a4410a8 100644
--- a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,48 @@ query = '''
 file where container.id:"*" and
   event.type in ("change", "creation") and file.name: ("authorized_keys", "authorized_keys2", "sshd_config")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SSH Authorized Keys File Modified Inside a Container
+
+SSH authorized_keys files are crucial for managing access to systems via public key authentication, ensuring secure, password-less logins. In containerized environments, adversaries may exploit these files to gain unauthorized access or maintain persistence by adding their own keys. The detection rule identifies suspicious modifications to these files within containers, signaling potential compromise and warranting further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific container where the modification occurred, using the `container.id` field for context.
+- Verify the event type by checking the `event.type` field to confirm whether it was a "change" or "creation" event, which can help determine the nature of the modification.
+- Examine the `file.name` field to identify which file was modified: `authorized_keys`, `authorized_keys2`, or `sshd_config`, as this can indicate the method of potential unauthorized access.
+- Use Osquery to list all current SSH keys in the container by running: `SELECT * FROM authorized_keys WHERE path LIKE '/path/to/container/%';` to identify any unauthorized keys.
+- Check the container's creation and start time to determine if the modification aligns with expected operational activities or if it occurred at an unusual time.
+- Investigate the user context under which the modification was made by reviewing logs or using Osquery: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM file_events WHERE path LIKE '/path/to/container/%');` to identify the process responsible for the change.
+- Correlate the container's network activity around the time of the modification to identify any suspicious connections or data transfers.
+- Review the container's history and any associated images to determine if the modification could have originated from a compromised image or during the build process.
+- Check for any other alerts or anomalies related to the same container or host to identify potential patterns or broader compromise.
+- Consult with the team responsible for the container to verify if the modification was authorized or part of a legitimate update or maintenance activity.
+
+### False positive analysis
+
+- Routine updates or maintenance tasks: In some environments, automated processes or configuration management tools may update SSH authorized_keys or sshd_config files as part of regular maintenance. These changes, while legitimate, can trigger the detection rule. Users can handle these by creating exceptions for known maintenance windows or specific automation tools.
+- Developer or administrator actions: Developers or system administrators might modify these files within containers for legitimate reasons, such as adding keys for new team members or updating configurations. To manage these, users can maintain a list of authorized personnel and their expected activities, creating exceptions for their actions.
+- Container orchestration tools: Some container orchestration platforms might modify SSH configurations as part of their operations, especially in environments where SSH access is used for debugging or management. Users should identify these tools and processes, and exclude their activities from triggering alerts.
+- Testing and development environments: In non-production environments, frequent changes to SSH configurations might occur as part of testing or development processes. Users can reduce false positives by applying the rule more strictly in production environments and less so in development settings.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
+- Conduct a thorough investigation to identify any unauthorized keys added to the authorized_keys file and determine the source of the modification.
+- Review container logs and access records to trace any suspicious activities or unauthorized access attempts.
+- Remove any unauthorized keys from the authorized_keys file and verify the integrity of the sshd_config file to ensure no malicious configurations are present.
+- Rotate SSH keys for all legitimate users who had access to the compromised container to prevent further unauthorized access.
+- Escalate the incident to the security operations team for a comprehensive analysis and to determine if other containers or systems have been affected.
+- Implement enhanced logging and monitoring for SSH activities within containers to detect future unauthorized access attempts promptly.
+- Integrate security tools with SIEM solutions to automate the detection and alerting of suspicious modifications to SSH-related files.
+- Restore the container to its operational state by redeploying it from a known good image and ensuring all security patches are applied.
+- Apply hardening measures such as disabling SSH access to containers unless absolutely necessary and using network policies to restrict access to SSH services."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
index 84a94f11ed9..f73a6b4a5ff 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,50 @@ process where event.module == "cloud_defend" and
   process.args : "/dev/sd*" and not process.args == "-R" and
   container.security_context.privileged == true
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File System Debugger Launched Inside a Privileged Container
+
+DebugFS is a Linux utility that allows direct interaction with file systems, typically used for debugging purposes. When executed within a privileged container, it can access host-level files, posing a security risk. Adversaries may exploit this to escalate privileges or escape the container. The detection rule identifies such misuse by monitoring DebugFS processes initiated in privileged containers, focusing on specific arguments that indicate potential malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "debugfs" and verify the presence of the specific arguments "/dev/sd*" to ensure the alert is not a false positive.
+- Check the container's security context to confirm it is indeed privileged by examining the `container.security_context.privileged` field.
+- Investigate the origin of the container by identifying the image and container ID to understand its purpose and whether it should have privileged access.
+- Use Osquery to list all running processes within the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address != '');`
+- Examine the container's logs for any unusual activities or errors around the time the DebugFS process was started.
+- Review the user account and credentials used to launch the container to determine if they have been compromised or misused.
+- Investigate the host system for any signs of compromise or unauthorized access, focusing on the time frame when the DebugFS process was initiated.
+- Check for any recent changes to the container's configuration or deployment scripts that might have inadvertently allowed privileged access.
+- Correlate the event with other security alerts or logs from the same host or container to identify potential patterns or related incidents.
+- Consult with the development or operations team to verify if there was a legitimate need for using DebugFS within a privileged container and gather context on any recent changes or deployments.
+
+### False positive analysis
+
+- DebugFS may be legitimately used by system administrators for troubleshooting or maintenance tasks within a privileged container, especially in environments where direct disk access is necessary for diagnostics. 
+- Automated scripts or monitoring tools that perform regular checks on disk health or integrity might trigger this rule if they utilize DebugFS within a privileged container context.
+- Development or testing environments where privileged containers are used to simulate production-like conditions might see DebugFS usage as part of routine operations, leading to false positives.
+- To manage these false positives, users can create exceptions for known benign processes or scripts by specifying their unique identifiers or command patterns in the detection rule.
+- Implementing a whitelist of trusted users or processes that are allowed to execute DebugFS within privileged containers can help reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational needs.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further access to host-level files and potential privilege escalation.
+- Conduct a thorough investigation to determine the extent of the compromise, focusing on logs and process activity related to DebugFS usage.
+- Review container deployment configurations to ensure that privileged containers are only used when absolutely necessary and with strict access controls.
+- Remove any unauthorized or suspicious processes and files identified during the investigation from the container and host system.
+- Apply security patches and updates to the container runtime and host operating system to mitigate known vulnerabilities.
+- Implement strict logging policies to capture detailed process execution and container activity, ensuring that logs are stored securely and monitored regularly.
+- Integrate security tools with SIEM systems to enhance real-time detection and alerting capabilities for suspicious container activities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Restore the container and host system to a known good state from backups, ensuring that the restored environment is free from any malicious modifications.
+- Harden container security by minimizing the use of privileged containers, employing least privilege principles, and using security features like AppArmor or SELinux for additional protection."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
index b8ce04a318a..22ef505e0cb 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,49 @@ query = '''
 process where event.module == "cloud_defend" and  event.type== "start" and 
 (process.name== "mount" or process.args== "mount") and container.security_context.privileged == true
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Mount Launched Inside a Privileged Container
+
+In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When used in privileged containers, which have extensive host capabilities, it can expose sensitive host files. Adversaries exploit this to escalate privileges or escape to the host. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `mount` command execution within a privileged container by checking the `process.name` and `process.args` fields.
+- Verify the `container.security_context.privileged` field to ensure the container was indeed running with privileged access.
+- Identify the container ID and image name associated with the alert to understand which application or service might be involved.
+- Check the `event.module` and `event.type` fields to confirm the event source and type, ensuring it aligns with the expected behavior of the detection rule.
+- Use Osquery to list all processes running inside the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = 'container_ip');`
+- Investigate the container's logs for any unusual or unauthorized access patterns around the time of the alert.
+- Examine the host system's logs for any signs of privilege escalation or attempts to access sensitive files from the container.
+- Review the container's configuration and deployment scripts to ensure no unintended privileged access was granted.
+- Check for any recent changes or deployments that might have introduced the privileged container or altered its behavior.
+- Collaborate with the development or DevOps team to understand the intended use of the `mount` command within the container and verify if it aligns with expected operations.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use the `mount` command within privileged containers for legitimate purposes such as attaching storage volumes or performing maintenance. These actions, while benign, can trigger the detection rule.
+- Backup operations: Automated backup processes might involve mounting file systems within privileged containers to access data, leading to false positives.
+- Monitoring and logging tools: Some security or monitoring tools may use the `mount` command to access file systems for scanning or logging purposes, which can be mistakenly flagged.
+- To manage these false positives, users can create exceptions for known benign processes by specifying trusted process names or arguments in the detection rule. This can be done by updating the query to exclude certain process names or arguments that are identified as non-threatening.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
+- Investigate the container's logs and process history to identify any unauthorized or suspicious activities, focusing on the use of the mount command.
+- Verify the container's security context and configuration to ensure it was not inadvertently deployed with privileged access.
+- Conduct a thorough review of the container's filesystem to identify any unauthorized changes or access to sensitive host files.
+- Escalate the incident to the security operations team if evidence of privilege escalation or host escape is found, providing detailed findings and context.
+- Implement enhanced logging policies to capture detailed process execution and container activity, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate security monitoring tools with SIEM systems to automate the detection of privileged container activities and generate alerts for suspicious behavior.
+- Restore the container to a known good state from a secure backup, ensuring any unauthorized changes are reverted.
+- Apply container hardening measures, such as using the principle of least privilege, to minimize the capabilities of containers and reduce the attack surface.
+- Review and update security policies and procedures to prevent similar incidents, incorporating lessons learned from the investigation and remediation process."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
index e02c4778a14..335ea835d6e 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,48 @@ query = '''
 file where event.module == "cloud_defend" and event.action == "open" and 
 event.type == "change" and file.name : "notify_on_release"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Container Escape via Modified notify_on_release File
+
+Containers use cgroups to manage resources, with the `notify_on_release` file triggering host-level commands when a cgroup is released. Adversaries exploit this by modifying the file from privileged containers to execute unauthorized commands on the host, leading to potential escapes. The detection rule monitors changes to `notify_on_release` files, flagging suspicious modifications indicative of such exploits.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.module is "cloud_defend" and the event.action is "open" with event.type as "change" for the file named "notify_on_release".
+- Identify the container from which the modification originated by examining the source IP, container ID, and associated metadata.
+- Check the user and process that initiated the change by reviewing the user ID and process ID associated with the event.
+- Investigate the history of the container to determine if it has been granted SYS_ADMIN capabilities, which are necessary for modifying cgroup settings.
+- Use Osquery to list all processes running within the container to identify any suspicious or unauthorized processes. Example query: `SELECT pid, name, path FROM processes WHERE cgroup LIKE '%<container_id>%';`
+- Examine the release_agent file associated with the cgroup to determine if it has been modified or contains suspicious commands.
+- Review recent logs and events from the host system to identify any execution of commands that could be linked to the release_agent.
+- Analyze network activity from the container to detect any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
+- Cross-reference the alert with other security events or alerts to identify potential patterns or coordinated activities.
+- Consult threat intelligence sources to determine if there are known exploits or attack patterns related to the modification of the notify_on_release file.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may modify the `notify_on_release` file during legitimate maintenance or configuration activities. To handle this, users can create exceptions for known administrative actions by whitelisting specific user accounts or processes that are authorized to perform these changes.
+- Automated container management tools: Some container orchestration or management tools might modify the `notify_on_release` file as part of their normal operations. Users should identify these tools and exclude their actions from triggering alerts by specifying the tool's process names or IDs in the exception list.
+- Testing and development environments: In environments where containers are frequently created and destroyed for testing purposes, modifications to the `notify_on_release` file might be common and benign. Users can reduce noise by setting up separate monitoring rules or thresholds for these environments, ensuring that only unexpected changes trigger alerts.
+- Custom scripts or applications: Organizations may have custom scripts or applications that interact with cgroups and modify the `notify_on_release` file. Users should document these scripts and create exceptions based on their unique identifiers or execution paths to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
+- Conduct a thorough investigation to identify any unauthorized changes made to the notify_on_release file and determine the extent of the compromise.
+- Review container logs and host system logs to trace the actions of the adversary and identify any additional indicators of compromise.
+- Revoke any unnecessary privileged access and capabilities from containers, especially SYS_ADMIN, to minimize the risk of exploitation.
+- Restore the affected container and host system from a known good backup to ensure the integrity of the environment.
+- Update and patch the container runtime and host operating system to address any known vulnerabilities that could be exploited for container escapes.
+- Implement enhanced logging and monitoring for cgroup modifications and other critical system files to detect similar activities in the future.
+- Integrate security tools with SIEM solutions to correlate alerts and improve threat detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Educate and train staff on container security best practices and the specific risks associated with cgroup modifications and container escapes."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
index 8c44e8b3c60..fd3c2bda6a5 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,48 @@ query = '''
 file where event.module == "cloud_defend" and event.action == "open" and 
 event.type == "change" and file.name : "release_agent"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Container Escape via Modified release_agent File
+
+In containerized environments, the release_agent file in CGroup directories can execute scripts upon process termination. Adversaries exploit this by modifying the file from privileged containers, potentially escalating privileges or escaping to the host. The detection rule monitors changes to the release_agent file, signaling possible malicious activity by identifying unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file involved is indeed the `release_agent` file and verify the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
+- Identify the container from which the modification originated by examining the source IP, container ID, and any associated user or process information.
+- Check the privileges of the container, specifically looking for SYS_ADMIN capabilities, to assess if it has the necessary permissions to modify the release_agent file.
+- Use Osquery to list all processes running in the container to identify any suspicious or unauthorized processes. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/proc/%/exe';`
+- Investigate the history of the release_agent file to determine when it was last modified and by which process or user.
+- Examine the contents of the modified release_agent file to understand what script or command is being executed upon process termination.
+- Correlate the modification event with any other suspicious activities or alerts in the same timeframe to identify potential lateral movement or privilege escalation attempts.
+- Check for any recent changes in the CGroup directory permissions or configurations that could have facilitated the modification.
+- Review system logs and audit logs for any anomalies or unauthorized access attempts around the time of the modification.
+- Investigate any network connections from the container to external IPs that could indicate data exfiltration or command and control communication.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may legitimately modify the release_agent file during maintenance or configuration changes. Users can handle these by creating exceptions for known administrative activities or specific time windows when such tasks are expected.
+- Automated scripts or tools: Some container management tools or scripts might modify the release_agent file as part of their normal operation. Users should identify these tools and whitelist their activities to prevent false alerts.
+- Testing environments: In development or testing environments, developers might intentionally modify the release_agent file to test container behaviors. Users can exclude these environments from monitoring or set up specific rules that differentiate between production and non-production environments.
+- Legitimate software updates: Certain software updates might involve changes to the release_agent file. Users should maintain an updated list of software that is allowed to perform such updates and configure exceptions accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
+- Investigate the container's logs and any associated network traffic to identify the source and scope of the compromise.
+- Verify the integrity of the release_agent file and any scripts it may execute, ensuring they have not been tampered with or replaced by malicious versions.
+- Check for any unauthorized changes to the container's configuration, particularly those related to CGroup settings and SYS_ADMIN capabilities.
+- Escalate the incident to the security operations team if the investigation reveals a potential breach or if the threat actor's identity and methods are unclear.
+- Restore the container from a known good backup if available, ensuring that any vulnerabilities exploited by the attacker are patched.
+- Implement enhanced logging and monitoring for CGroup directories and privileged container activities to detect similar threats in the future.
+- Review and update access controls and permissions for containers, ensuring that only necessary privileges are granted to minimize the risk of exploitation.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate relevant personnel on the risks associated with container escapes and the importance of maintaining strict security practices in containerized environments."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
index fc951b330cb..a80ab44b70a 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,51 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual ISO Code
+
+Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to unexpected geo-locations. Adversaries may exploit command and control channels to exfiltrate data to these unusual regions. The detection rule leverages these models to flag deviations from normal traffic, indicating potential exfiltration activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unusual ISO code and the associated geo-location flagged by the machine learning model.
+- Cross-reference the unusual ISO code with known business operations to determine if there is a legitimate reason for data transfer to this location.
+- Analyze historical network traffic logs to identify patterns or previous instances of data transfers to the flagged geo-location.
+- Examine the source IP addresses involved in the data transfer to determine if they belong to known or trusted entities within the organization.
+- Utilize Osquery to gather additional context on the systems involved in the data transfer. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<flagged IP address>';`
+- Investigate the destination IP addresses and domains to assess their reputation and check for any known associations with malicious activities.
+- Check for any recent changes or anomalies in the network configuration or firewall rules that could have facilitated the data transfer.
+- Review user activity logs to identify any unusual or unauthorized access patterns that coincide with the data transfer event.
+- Correlate the alert with other security events or alerts to identify potential patterns or coordinated activities indicative of a larger threat.
+- Consult threat intelligence sources to gather additional information on the flagged geo-location and any associated threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate business operations may involve data transfers to new or infrequent geo-locations, such as expanding into new markets or collaborating with international partners, which could trigger false positives.
+- Automated systems or third-party services that route data through different regions for optimization or redundancy purposes might be flagged as unusual traffic.
+- Employees working remotely or traveling may connect from unexpected locations, causing their data transfers to appear suspicious.
+- To manage these false positives, users can create exceptions for known and verified business operations that involve data transfers to specific regions.
+- Implementing a whitelist of trusted IP addresses or domains associated with legitimate services can help reduce unnecessary alerts.
+- Regularly updating the list of approved geo-locations based on business needs and employee travel patterns can minimize false positives.
+- Users should review flagged activities in the context of their organization's normal operations to determine if they are indeed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
+- Analyze network logs and endpoint data to trace the source of the command and control channel used for exfiltration.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for awareness and further action.
+- Implement or enhance logging policies to ensure comprehensive monitoring of outbound traffic, focusing on unusual geo-locations.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of suspicious activities.
+- Restore affected systems from clean backups, ensuring that any compromised credentials or configurations are reset.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that may have been exploited.
+- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
+- Educate employees on recognizing phishing attempts and other social engineering tactics that could lead to data exfiltration."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
index 350448b6a9b..bbd50923e4b 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,49 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual IP Address
+
+Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical geo-locations. Adversaries exploit command and control (C2) channels to exfiltrate data to these unusual IP addresses. The detection rule leverages this analysis to flag potential exfiltration activities, aligning with MITRE ATT&CK's exfiltration tactics and techniques.
+
+### Possible investigation steps
+
+- Review the alert details to identify the unusual IP address and geo-location involved in the potential exfiltration activity.
+- Cross-reference the unusual IP address with threat intelligence databases to determine if it is associated with known malicious activities or threat actors.
+- Analyze historical network traffic logs to identify any previous communications with the unusual IP address, noting the frequency and volume of data transferred.
+- Examine the specific machine or endpoint involved in the alert to gather information on recent activities, user logins, and running processes.
+- Use Osquery to investigate the endpoint further. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<unusual_ip_address>';`
+- Check for any recent changes or anomalies in the system configurations or installed software on the affected endpoint.
+- Investigate user activity logs to determine if any unauthorized access or unusual user behavior occurred around the time of the alert.
+- Correlate the alert with other security events or alerts to identify potential patterns or related incidents.
+- Review data transfer logs to assess the type and sensitivity of the data that may have been exfiltrated to the unusual IP address.
+- Consult with relevant stakeholders or departments to verify if the data transfer to the unusual IP address was authorized or part of legitimate business operations.
+
+### False positive analysis
+
+- Legitimate business operations may involve data transfers to geo-locations that are atypical but necessary, such as international offices or third-party service providers. These should be reviewed and, if verified as non-threatening, added to an exception list.
+- Automated system updates or cloud service interactions might trigger alerts if they involve IP addresses outside the usual geographic range. Users can manage these by identifying and excluding known update servers or cloud service IPs.
+- Remote work scenarios where employees connect from various global locations can result in false positives. Organizations should maintain an updated list of employee travel plans or remote work locations to adjust the detection parameters accordingly.
+- Partner or vendor integrations that require data exchange with external IPs might be flagged. Establishing a whitelist of trusted partner IP addresses can help mitigate these false positives.
+- Temporary projects or collaborations with international teams may necessitate data transfers to unusual IP addresses. Users should document these activities and adjust the detection rules to accommodate such temporary changes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
+- Analyze network logs and endpoint data to trace the source of the command and control channel and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders, providing them with detailed findings and potential impacts.
+- Implement enhanced logging policies to capture detailed network traffic and endpoint activities for future investigations.
+- Integrate threat intelligence feeds and anomaly detection tools to improve the detection of unusual network patterns and potential C2 channels.
+- Restore the affected system by removing any malicious software, applying security patches, and verifying the integrity of critical files.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement network segmentation and access controls to limit the potential impact of future exfiltration attempts.
+- Educate employees on recognizing phishing attempts and other social engineering tactics that adversaries might use to establish C2 channels."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
index 119651afe53..2b3d71a7c5c 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -51,6 +51,52 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual Destination Port
+
+Machine learning models analyze network traffic to identify anomalies, such as data transfers to uncommon ports, which may suggest exfiltration via command and control channels. Adversaries exploit these channels to stealthily siphon data. The detection rule leverages these models to flag deviations from typical traffic patterns, aiding in the identification of potential exfiltration activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the unusual destination port and the source IP address involved in the potential exfiltration activity.
+- Analyze historical network traffic logs to determine if the identified destination port has been used previously and assess the frequency and volume of data transferred.
+- Cross-reference the source IP address with asset management databases to identify the device and user associated with the activity.
+- Examine the destination IP address to determine if it is associated with known malicious activity or if it belongs to an unfamiliar or suspicious domain.
+- Utilize threat intelligence feeds to check if the destination IP or domain is linked to any known command and control infrastructure.
+- Conduct a deeper inspection of the network traffic associated with the alert using packet capture tools to identify the nature of the data being transferred.
+- Use Osquery to gather additional context from the source machine. For example, run the following query to list active network connections and identify any unusual or persistent connections:
+  ```sql
+  SELECT * FROM process_open_sockets WHERE remote_port = <unusual_port>;
+  ```
+- Investigate any processes on the source machine that are associated with the unusual network activity to determine if they are legitimate or potentially malicious.
+- Check for any recent changes or anomalies in the system logs of the source machine that could indicate compromise or unauthorized access.
+- Collaborate with other security teams to correlate this alert with any other suspicious activities or alerts that may have been triggered around the same time frame.
+
+### False positive analysis
+
+- Routine administrative tasks or legitimate software updates may trigger alerts if they involve data transfers to uncommon ports, as these activities can mimic exfiltration patterns.
+- Internal testing or development environments might use non-standard ports for data transfer, leading to false positives if these activities are not accounted for in the baseline traffic patterns.
+- Certain legitimate applications or services may inherently use unusual ports for communication, which could be misinterpreted as exfiltration attempts.
+- To manage these false positives, users can create exceptions for known benign activities by updating the detection rule to exclude specific IP addresses, ports, or applications that are verified as non-threatening.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the effectiveness of the detection rule against genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
+- Analyze network logs and endpoint data to trace the source of the anomaly and identify any compromised accounts or systems.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and decision-making.
+- Implement enhanced logging and monitoring on network traffic, focusing on unusual destination ports and data transfer patterns.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block traffic to and from the identified unusual ports.
+- Apply patches and updates to all affected systems to close any vulnerabilities exploited during the exfiltration.
+- Conduct a security awareness training session for employees to recognize and report suspicious activities.
+- Restore systems to their operational state by reimaging affected machines and verifying the integrity of data backups.
+- Implement hardening measures such as network segmentation, least privilege access, and multi-factor authentication to reduce the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
index b66d2fcbc9f..2641095e8b0 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,48 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual Region
+
+Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical regions. Adversaries exploit command and control (C2) channels to exfiltrate data to these unusual locations, bypassing traditional security measures. The detection rule leverages these models to flag suspicious geo-location activities, aligning with MITRE ATT&CK's exfiltration tactics, thus aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific geo-location flagged as unusual and the volume of data transferred.
+- Cross-reference the geo-location with the organization's known business operations to determine if the location is indeed atypical.
+- Analyze historical network traffic logs to identify patterns and determine if similar data transfers have occurred in the past.
+- Examine the source IP address and destination IP address involved in the data transfer to identify any known malicious activity or anomalies.
+- Utilize Osquery to gather additional context on the involved endpoints. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<destination_ip>';`
+- Investigate the user accounts associated with the data transfer to check for any signs of compromise or unusual activity.
+- Check for any recent changes in firewall or proxy configurations that might have allowed the data transfer to bypass security controls.
+- Correlate the alert with other security events or alerts to identify potential patterns or coordinated attacks.
+- Review endpoint logs for any signs of malware or unauthorized software that could facilitate data exfiltration.
+- Consult threat intelligence sources to determine if the destination IP or geo-location is associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate business operations involving international data transfers can trigger false positives. Organizations with global operations may frequently transfer data to regions that are atypical for other businesses but normal for them.
+- Cloud service providers often have data centers in various regions. Routine data synchronization or backup activities to these locations might be misidentified as exfiltration attempts.
+- Remote work scenarios where employees connect from different geographical locations can lead to false positives, especially if employees are traveling or using VPNs that exit in unusual regions.
+- To manage these false positives, users can create exceptions for known and verified data transfer activities that align with business operations. This involves maintaining an updated list of trusted geo-locations and regularly reviewing and adjusting the detection rule's sensitivity to accommodate legitimate traffic patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
+- Analyze network logs and endpoint data to trace the source of the command and control (C2) channel used for exfiltration.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for awareness and further action.
+- Implement enhanced logging policies to capture detailed network traffic and endpoint activities for future investigations.
+- Integrate threat intelligence feeds to update detection rules and improve anomaly detection capabilities.
+- Restore affected systems from clean backups to ensure no malicious code remains.
+- Apply security patches and updates to all systems to mitigate vulnerabilities exploited during the attack.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement network segmentation and data loss prevention (DLP) measures to harden the environment against future exfiltration attempts."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
index 39917340b0a..cde76e7fc8c 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -51,6 +51,49 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Bytes Sent to an External Device
+
+In modern environments, data transfer to external devices is common, yet it follows predictable patterns. Adversaries exploit this by transferring large volumes of data to external media, bypassing network defenses. The detection rule leverages machine learning to identify anomalies in data transfer volumes, flagging potential exfiltration attempts that deviate from normal operational behavior.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the timestamp, user, and device involved in the data transfer.
+- Verify the volume of data transferred against historical data transfer patterns for the specific user and device to confirm the anomaly.
+- Check the user activity logs around the time of the alert to identify any unusual behavior or access patterns.
+- Investigate the external device's details, such as the device ID and connection history, to determine if it is a known or trusted device.
+- Use Osquery to gather more information about the external device connection. Example query: `SELECT * FROM usb_devices WHERE serial = '<device_serial_number>';`
+- Examine file access logs to identify which files were accessed and potentially transferred to the external device.
+- Correlate the alert with other security events or alerts to identify if this is part of a larger pattern of suspicious activity.
+- Interview the user associated with the alert to gather context on the data transfer and verify if it was a legitimate business need.
+- Check for any recent changes in user permissions or roles that might explain the increased data transfer.
+- Review the organization's data transfer policies and compare them with the user's activity to assess compliance and identify any policy violations.
+
+### False positive analysis
+
+- Routine data backups to external devices can trigger false positives, especially if they involve large volumes of data. Users can manage this by creating exceptions for scheduled backup activities.
+- Software updates or installations that require transferring substantial data to external media may be flagged. To handle this, users should whitelist known update processes or installation activities.
+- Data transfers related to legitimate business operations, such as transferring large datasets for analysis or reporting, can be mistaken for exfiltration attempts. Users should document and exclude these regular business processes from triggering alerts.
+- Employee use of external storage for legitimate purposes, like presentations or offsite work, might cause false positives. Implementing a policy to register and approve such devices can help in excluding these activities.
+- Automated system processes that involve data archiving or migration to external devices can be misinterpreted as suspicious. Users should identify and exclude these automated tasks from the anomaly detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected device from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the data transfer, including reviewing logs and any available forensic data.
+- Verify the legitimacy of the data transfer by contacting the user or department responsible for the device.
+- If malicious activity is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
+- Implement additional logging and monitoring on external device connections and data transfers to detect future anomalies.
+- Review and update data transfer policies to ensure they align with current security standards and practices.
+- Restore the system to its operational state by removing any unauthorized software or malware and applying necessary patches or updates.
+- Conduct a security awareness training session for employees to reinforce the importance of data security and the risks associated with unauthorized data transfers.
+- Implement hardening measures such as disabling unused ports, enforcing strict access controls, and using data loss prevention (DLP) tools.
+- Document the incident and response actions taken to improve future incident handling and refine detection capabilities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
index 9236fbdd189..47deab331a2 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,49 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Bytes Sent to an External Device via Airdrop
+
+Airdrop facilitates seamless file sharing between Apple devices, leveraging Bluetooth and Wi-Fi. While convenient, adversaries can exploit it to exfiltrate data stealthily. The detection rule identifies anomalies by monitoring data transfer volumes, flagging unusually high data spikes as potential illicit activities, thus alerting analysts to investigate possible data breaches.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the timestamp, source device, and volume of data transferred.
+- Verify the identity of the external device receiving the data to determine if it is a known and trusted device.
+- Cross-reference the user account associated with the data transfer to check for any unusual or unauthorized access patterns.
+- Analyze historical data transfer patterns for the source device to identify deviations from normal behavior.
+- Use Osquery to gather additional context on the source device. For example, run the following query to list recent Airdrop activities: `SELECT * FROM process_events WHERE path LIKE '%AirDrop%' AND datetime > (SELECT datetime('now', '-1 day'));`
+- Check for any recent changes in user permissions or configurations on the source device that might have facilitated the data transfer.
+- Investigate any concurrent network activities or connections from the source device that could indicate coordinated data exfiltration efforts.
+- Examine system logs for any signs of malware or unauthorized software that could be facilitating the data transfer.
+- Correlate the alert with other security events or alerts to identify potential patterns or coordinated attacks.
+- Consult with the user or device owner to verify if the data transfer was legitimate and authorized, and gather any additional context or explanations.
+
+### False positive analysis
+
+- High data transfer volumes via Airdrop can occur during legitimate activities such as software updates, large media file transfers, or backups, which may trigger false positives.
+- Users frequently sharing large files for collaborative projects or educational purposes might also cause spikes that are non-threatening.
+- To manage these false positives, analysts can create exceptions for known devices or users who regularly transfer large amounts of data as part of their normal workflow.
+- Implementing a baseline of typical data transfer patterns for specific departments or roles can help distinguish between legitimate and suspicious activities.
+- Regularly updating the detection model with feedback from investigations can improve its accuracy in differentiating between false positives and genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected device from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the data transfer, including reviewing logs and any associated user activity.
+- Verify the legitimacy of the data transfer by contacting the user involved and cross-referencing with business operations.
+- If malicious activity is confirmed, escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
+- Implement additional logging and monitoring for Airdrop activities to capture detailed information on future data transfers.
+- Review and update security policies to restrict Airdrop usage to only authorized personnel and devices.
+- Restore the system to its operational state by ensuring all unauthorized changes are reverted and any malicious software is removed.
+- Conduct a post-incident review to identify gaps in the current security posture and improve detection capabilities.
+- Educate employees on the risks associated with Airdrop and best practices for secure data sharing.
+- Consider integrating advanced threat detection tools that leverage machine learning to enhance anomaly detection and response capabilities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
index ea9d9ea5633..e35fa6e5686 100644
--- a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -51,6 +51,49 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process Writing Data to an External Device
+
+In modern environments, processes writing data to external devices are common for legitimate tasks like backups. However, adversaries exploit this by using innocuous processes to exfiltrate data. The detection rule leverages machine learning to identify rare processes performing such actions, flagging potential exfiltration attempts by correlating with MITRE ATT&CK's exfiltration tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name, process ID, and the external device involved in the data writing activity.
+- Check the historical activity of the identified process to determine if it has previously interacted with external devices or if this behavior is anomalous.
+- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or job responsibilities.
+- Use Osquery to gather additional context about the process. For example, run the following query to retrieve details about the process and its parent process: `SELECT pid, name, path, parent, cmdline FROM processes WHERE pid = <process_id>;`
+- Examine the command line arguments and execution path of the process to identify any suspicious or unexpected parameters that could indicate malicious intent.
+- Analyze the external device's connection history to determine if it has been used frequently or if it is a new or rarely used device.
+- Cross-reference the process and device activity with network logs to identify any concurrent data transfer events that could suggest exfiltration.
+- Check for any recent changes or updates to the system that might have introduced new software or scripts capable of writing data to external devices.
+- Review any related security alerts or logs from other security tools that might provide additional context or corroborate the suspicious activity.
+- Consult with the user or system owner to verify if the process activity was authorized or if they are aware of any legitimate reason for the data transfer to the external device.
+
+### False positive analysis
+
+- Backup software: Legitimate backup processes may frequently write data to external devices, triggering false positives. Users can handle this by creating exceptions for known backup applications.
+- System updates: Operating system or application updates might involve writing data to external devices, which can be mistaken for exfiltration. Users should whitelist update processes to prevent unnecessary alerts.
+- Data synchronization tools: Applications like cloud storage sync tools may write data to external devices as part of their normal operation. Users can exclude these tools from monitoring to reduce false positives.
+- IT administrative tasks: IT personnel might use scripts or tools to transfer data to external devices for maintenance or troubleshooting. Users should document and exclude these routine tasks from detection rules.
+- Media creation software: Software used for creating media content may write large amounts of data to external devices, which could be misinterpreted as exfiltration. Users can add exceptions for these specific applications.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the process responsible for writing data to the external device, including reviewing logs and process histories.
+- Verify the legitimacy of the process by cross-referencing with known software and legitimate use cases; if malicious, terminate the process.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process activities and external device interactions for future monitoring.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by removing any malicious software and applying necessary patches or updates.
+- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
+- Educate employees on recognizing and reporting suspicious activities, emphasizing the importance of data security and device usage policies.
+- Review and update security policies and procedures to include specific measures against data exfiltration tactics, leveraging MITRE ATT&CK framework insights."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
index 8fd4b2d3054..906a62255ca 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ type = "query"
 query = '''
 ml_is_dga.malicious_prediction:1 and dns.question.registered_domain:avsvmcloud.com
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Machine Learning Detected DGA activity using a known SUNBURST DNS domain
+
+Machine learning models can identify patterns in DNS queries indicative of Domain Generation Algorithms (DGAs), often used by malware like SUNBURST for command and control. Adversaries exploit DGAs to dynamically generate domain names, evading static blocklists. This detection rule leverages machine learning to flag DNS queries linked to SUNBURST, focusing on domains like avsvmcloud.com, thus identifying potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `ml_is_dga.malicious_prediction:1` field, indicating a high-confidence prediction of DGA activity.
+- Verify the DNS query details, specifically focusing on the `dns.question.registered_domain:avsvmcloud.com`, to confirm the domain associated with SUNBURST activity.
+- Cross-reference the detected domain with known threat intelligence sources to gather additional context on its association with SUNBURST or other malicious activities.
+- Analyze historical DNS logs to identify any patterns or frequency of queries to `avsvmcloud.com` from the same host or network segment.
+- Use Osquery to investigate the host that generated the DNS query. For example, run the following query to list recent DNS queries made by the host: `SELECT name, time, count FROM dns_cache WHERE name LIKE '%avsvmcloud.com%';`
+- Examine network traffic logs to identify any additional suspicious domains or IP addresses that the host may have communicated with around the time of the alert.
+- Check endpoint security logs for any signs of suspicious processes or anomalies on the host that could indicate compromise or malware activity.
+- Investigate user activity on the affected host to determine if any unauthorized or unusual actions were performed around the time of the alert.
+- Review system and application logs on the host for any errors or warnings that could be related to the detected DGA activity.
+- Collaborate with other security teams to correlate this alert with any other ongoing investigations or incidents that might be related to SUNBURST or similar threats.
+
+### False positive analysis
+
+- Legitimate software or services that use dynamic DNS for load balancing or failover purposes may trigger false positives, as they can exhibit similar domain generation patterns to those used by DGAs.
+- Security researchers or network administrators conducting tests or simulations involving SUNBURST-related domains might inadvertently generate traffic that resembles malicious activity.
+- Organizations using security tools that perform DNS lookups on known malicious domains for threat intelligence purposes could also be flagged by this rule.
+- To manage these false positives, users can create exceptions for known legitimate services or internal testing environments by whitelisting specific IP addresses or domain names.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with potentially malicious domains.
+- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise, such as unusual processes or unauthorized access attempts.
+- Utilize endpoint detection and response (EDR) tools to scan for and remove any malicious software associated with the SUNBURST malware.
+- Review DNS logs and network traffic to identify other systems that may have communicated with the SUNBURST-related domains, expanding the scope of the investigation as needed.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are required.
+- Implement or update DNS filtering policies to block known malicious domains and prevent future connections to SUNBURST-related domains.
+- Restore the affected system from a known good backup, ensuring that all security patches and updates are applied before reconnecting to the network.
+- Enhance logging and monitoring capabilities to capture detailed DNS query logs and network traffic for future investigations.
+- Integrate threat intelligence feeds to stay informed about emerging threats and update detection rules accordingly.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and least privilege access controls, to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
index 5f43ccebc1a..2c33e452467 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -60,6 +60,48 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential DGA Activity
+Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. Adversaries exploit this by frequently changing domains to evade detection. The 'Potential DGA Activity' detection rule leverages machine learning to analyze DNS requests from source IPs, identifying patterns indicative of DGA usage, thus flagging potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the source IP address associated with the potential DGA activity.
+- Analyze DNS logs to identify the specific domains queried by the source IP and check for patterns or anomalies in the domain names.
+- Cross-reference the identified domains with threat intelligence feeds to determine if they are known malicious or suspicious domains.
+- Use Osquery to gather additional context on the source IP's host by running a query to list recent DNS queries: `SELECT name, count FROM dns_cache WHERE name LIKE '%.%' ORDER BY count DESC LIMIT 10;`
+- Investigate the network traffic from the source IP to identify any unusual or unexpected outbound connections, focusing on the frequency and timing of the connections.
+- Check for any other alerts or logs related to the source IP to determine if there is a broader pattern of suspicious activity.
+- Examine endpoint logs for the source IP to identify any processes or applications that may be responsible for generating the DNS requests.
+- Review user activity associated with the source IP to determine if there is any legitimate reason for the observed DNS behavior.
+- Consult with other teams or departments to gather additional context or insights about the source IP or the domains in question.
+- Document findings and observations to build a comprehensive picture of the potential threat, which can be used for further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Legitimate applications or services that frequently update or communicate with multiple domains may trigger false positives. Examples include content delivery networks (CDNs), cloud services, or software update mechanisms that use dynamic domain resolution.
+- Internal company services that use dynamic DNS for load balancing or failover purposes might be mistakenly flagged as DGA activity.
+- Users can manage these false positives by creating exceptions for known benign domains or IP addresses associated with trusted services, ensuring they are not flagged in future analyses.
+- Regularly review and update the list of exceptions to accommodate changes in legitimate service behaviors, reducing the likelihood of overlooking genuine threats.
+- Collaborate with IT and network teams to identify and document legitimate dynamic domain usage within the organization, aiding in the refinement of detection rules.
+
+### Response and remediation
+
+- Isolate the affected systems from the network to prevent further communication with potentially malicious domains.
+- Conduct a thorough investigation of DNS logs to identify all domains queried by the affected source IPs and cross-reference them with known malicious DGA patterns.
+- Utilize endpoint detection and response (EDR) tools to scan the affected systems for malware and remove any identified threats.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger campaign.
+- Implement network-level blocking of identified malicious domains and IP addresses to prevent future communication attempts.
+- Review and enhance DNS logging policies to ensure comprehensive visibility into DNS queries and responses for future investigations.
+- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection of DGA-related activities.
+- Restore affected systems from clean backups and ensure all security patches and updates are applied to prevent exploitation of known vulnerabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement network segmentation and least privilege access controls to limit the potential impact of future DGA-related threats."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
index c144bd2ddb0..235f4b807fd 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,48 @@ type = "query"
 query = '''
 ml_is_dga.malicious_probability > 0.98
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Machine Learning Detected a DNS Request With a High DGA Probability Score
+
+Machine learning models can identify DNS requests likely generated by Domain Generation Algorithms (DGAs), which adversaries use to dynamically change domain names for command and control servers, evading detection. This detection rule flags DNS queries with a high DGA probability, indicating potential malicious activity by correlating with known threat tactics and techniques.
+
+### Possible investigation steps
+
+- Review the DNS query logs to identify the specific domain name associated with the high DGA probability score and note the timestamp of the query.
+- Cross-reference the identified domain name with threat intelligence databases to check for any known associations with malicious activity or threat actors.
+- Analyze the source IP address of the DNS request to determine the originating device within the network and assess its role and importance.
+- Use Osquery to gather additional context on the originating device by running a query such as: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM dns_resolvers WHERE domain = '<suspicious_domain>');` to identify processes that may have initiated the DNS request.
+- Investigate the network traffic logs for the source IP address around the time of the DNS request to identify any unusual or suspicious outbound connections.
+- Check for any other DNS requests from the same source IP address that have high DGA probability scores to determine if there is a pattern of suspicious behavior.
+- Examine endpoint security logs for the originating device to identify any recent alerts or anomalies that could correlate with the suspicious DNS activity.
+- Review user activity logs for the user associated with the originating device to identify any unusual behavior or access patterns.
+- Consult with the network team to verify if there have been any recent changes or anomalies in network configurations that could explain the DNS request.
+- Document all findings and correlations in a centralized investigation report to facilitate further analysis and decision-making.
+
+### False positive analysis
+
+- Known false positives for the Machine Learning Detected a DNS Request With a High DGA Probability Score rule can include legitimate services that frequently change domain names, such as content delivery networks (CDNs) or cloud service providers, which may use dynamic DNS techniques similar to DGAs.
+- Users can manage these false positives by creating exceptions for known benign domains or IP addresses that are frequently flagged. This can be done by maintaining a whitelist of trusted domains that are known to use dynamic resolution but are not associated with malicious activity.
+- Regularly updating the whitelist and reviewing flagged domains against threat intelligence feeds can help ensure that legitimate services are not mistakenly blocked, while still maintaining robust security against actual threats.
+- Implementing a feedback loop where security analysts can mark certain detections as false positives can help refine the machine learning model over time, reducing the likelihood of similar false positives in the future.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with potential command and control servers.
+- Conduct a thorough investigation of the DNS logs to identify all domains queried by the affected system and cross-reference with known malicious DGA patterns.
+- Utilize endpoint detection and response (EDR) tools to perform a deep scan of the affected system for any signs of malware or unauthorized software.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block identified malicious domains and IP addresses.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced DNS logging and monitoring to capture detailed query data for future analysis and threat hunting.
+- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection of DGA-related activities.
+- Restore the affected system from a known good backup to ensure it is free from compromise and verify the integrity of critical files and configurations.
+- Apply security patches and updates to the operating system and all installed software to mitigate vulnerabilities that could be exploited by attackers.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures such as network segmentation and least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
index 9bdf80ef78a..839d71b1056 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ type = "query"
 query = '''
 ml_is_dga.malicious_prediction:1 and not dns.question.registered_domain:avsvmcloud.com
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Machine Learning Detected a DNS Request Predicted to be a DGA Domain
+
+Machine learning models can identify patterns in DNS requests that suggest the use of Domain Generation Algorithms (DGAs), often employed by adversaries to dynamically generate domain names for command and control servers, evading static blocklists. This detection rule leverages such models to flag DNS queries likely generated by DGAs, excluding known benign domains, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `ml_is_dga.malicious_prediction` field to confirm the prediction of a DGA domain.
+- Examine the `dns.question.registered_domain` field to identify the specific domain flagged by the machine learning model.
+- Cross-reference the flagged domain against known threat intelligence sources to determine if it has been previously associated with malicious activity.
+- Investigate the source IP address of the DNS request to identify the device or user responsible for the query.
+- Use network logs to trace the DNS request's path and identify any other suspicious domains queried by the same source.
+- Analyze historical DNS logs to check for patterns or repeated queries to similar domains, which might indicate ongoing DGA activity.
+- Utilize Osquery to gather additional context from the endpoint. For example, run the following query to list recent DNS queries from the device: `SELECT name, time FROM dns_resolvers WHERE name LIKE '%<suspicious_domain>%' ORDER BY time DESC;`
+- Check for any associated processes or applications on the endpoint that might be generating the suspicious DNS requests, using endpoint detection and response (EDR) tools.
+- Investigate any outbound connections from the source IP to external IPs that might correlate with the flagged domain, using firewall or proxy logs.
+- Collaborate with other teams to gather additional context, such as user activity logs or recent changes to the network environment, to better understand the potential threat.
+
+### False positive analysis
+
+- Known false positives for the Machine Learning Detected a DNS Request Predicted to be a DGA Domain rule can include legitimate services that frequently change their domain names, such as content delivery networks (CDNs) or cloud service providers, which may use dynamic domain generation for load balancing or redundancy.
+- Users can manage these false positives by creating exceptions for domains that are verified to be part of legitimate services. This can be done by maintaining a whitelist of known benign domains that are frequently flagged, ensuring that these are excluded from the machine learning model's predictions.
+- Another potential false positive source is internal applications that use dynamic domain generation for legitimate purposes, such as testing environments or internal load balancing. Users should identify these applications and add their domains to an exception list to prevent unnecessary alerts.
+- Regularly reviewing and updating the list of exceptions is crucial, as legitimate services may change their domain generation patterns over time. This ensures that the detection rule remains effective without being overwhelmed by false positives.
+- Collaboration with network and security teams can help in identifying patterns of legitimate dynamic domain usage, allowing for more accurate tuning of the detection rule and reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with potential command and control servers.
+- Conduct a thorough investigation of the DNS logs to identify other potentially malicious domains and assess the scope of the compromise.
+- Utilize endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise (IOCs) and remove any identified malware.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement a temporary block on the identified malicious domains across the network to prevent further access.
+- Review and enhance DNS logging policies to ensure comprehensive monitoring and detection of suspicious activities in the future.
+- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection capabilities for DGA-related threats.
+- Restore the affected system from a known good backup to ensure it is free from compromise and return it to operational status.
+- Apply security patches and updates to the affected system and other vulnerable systems to mitigate exploitation risks.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and enhanced access controls, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/endpoint/elastic_endpoint_security.toml b/rules/integrations/endpoint/elastic_endpoint_security.toml
index 37be3ddc9b9..74c72bfeba3 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "New fields added: required_fields, related_integrations, setup"
 min_stack_version = "8.3.0"
 promotion = true
-updated_date = "2024/11/27"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ type = "query"
 query = '''
 event.kind:alert and event.module:(endpoint and not endgame)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Endpoint Security
+
+Endpoint Security plays a crucial role in safeguarding devices by monitoring and responding to threats. It leverages alerts from Elastic Endpoint Security to detect suspicious activities. Adversaries may exploit endpoints to execute unauthorized actions or exfiltrate data. The detection rule identifies potential threats by filtering alerts related to endpoint activities, excluding non-relevant modules, thus enabling swift investigation and response.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `event.kind:alert` and `event.module:endpoint` fields to confirm the alert's origin and type.
+- Check the alert timestamp to determine when the suspicious activity occurred and correlate it with other events around the same time.
+- Investigate the affected endpoint by identifying the device's hostname or IP address from the alert details.
+- Examine user activity on the affected endpoint to identify any unauthorized access or actions, using logs that capture user logins and executed commands.
+- Utilize Osquery to gather more information about the endpoint. For example, run the following query to list all running processes: `SELECT pid, name, path, cmdline FROM processes;`.
+- Analyze network connections from the affected endpoint to identify any unusual or unauthorized external communications.
+- Cross-reference the alert with other security tools and logs to gather additional context, such as firewall logs or intrusion detection system alerts.
+- Investigate any file modifications or creations on the endpoint around the alert time to detect potential malicious files or scripts.
+- Check for any recent changes in system configurations or installed software that could indicate tampering or exploitation.
+- Review historical alerts and incidents related to the same endpoint or user to identify patterns or repeated attack attempts.
+
+### False positive analysis
+
+- Known false positives for the Endpoint Security rule may include benign activities that resemble threat patterns, such as routine software updates or legitimate administrative tasks that trigger alerts.
+- Users can manage these false positives by creating exceptions for specific processes or activities that are consistently identified as non-threatening, ensuring these are well-documented and reviewed regularly.
+- It's important to analyze the context of each alert to determine if it aligns with expected behavior, such as scheduled maintenance or known software behavior, before categorizing it as a false positive.
+- Implementing a feedback loop with security teams can help refine detection rules and reduce the frequency of false positives by adjusting the criteria for alerts.
+- Regularly updating the list of exceptions and reviewing them against current threat intelligence can help maintain a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected endpoint from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the alert by analyzing logs and endpoint data to determine the scope and impact of the threat.
+- Identify and terminate any malicious processes or unauthorized access points on the affected endpoint.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is beyond the current team's capability to handle.
+- Apply patches or updates to the affected systems to address any vulnerabilities exploited by the adversary.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup if necessary.
+- Implement enhanced logging policies to capture detailed endpoint activity for future investigations.
+- Integrate additional security tools, such as intrusion detection systems or threat intelligence platforms, to improve threat detection capabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update security policies accordingly.
+- Apply hardening measures, such as disabling unnecessary services and enforcing strong authentication mechanisms, to reduce the attack surface of endpoints."""
 
 
 [[rule.exceptions_list]]
diff --git a/rules/integrations/fim/persistence_suspicious_file_modifications.toml b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
index 3d4d2b5e806..a4201fe00fb 100644
--- a/rules/integrations/fim/persistence_suspicious_file_modifications.toml
+++ b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["fim"]
 maturity = "production"
-updated_date = "2024/12/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -133,6 +133,48 @@ file.path : (
   file.extension in ("dpkg-new", "dpkg-remove", "SEQ")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Persistence via File Modification
+
+File Integrity Monitoring (FIM) is crucial for detecting unauthorized changes to critical files, often targeted by adversaries for persistence. Attackers may modify cron jobs, systemd services, or shell configurations to maintain access. The detection rule identifies suspicious updates to these files, excluding benign changes, to alert analysts to potential persistence mechanisms.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path that triggered the alert, focusing on the `file.path` field to understand which critical file was modified.
+- Check the `event.action` field to confirm that the action was indeed an "updated" event, indicating a modification rather than a creation or deletion.
+- Investigate the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is specifically designed for Linux environments.
+- Examine the `event.dataset` field to verify that the event originated from the "fim.event" dataset, confirming it was captured by File Integrity Monitoring.
+- Use Osquery to gather additional context about the modified file. For example, run the following query to check the file's current permissions and ownership: `SELECT path, mode, uid, gid FROM file WHERE path = '<file_path>';` Replace `<file_path>` with the actual path from the alert.
+- Investigate recent user activity on the system by reviewing authentication logs (e.g., `/var/log/auth.log`) to identify any suspicious logins or user actions around the time of the file modification.
+- Check for any recent changes to systemd services or cron jobs by listing all active services and scheduled tasks, which might provide clues about persistence mechanisms.
+- Review the system's bash history or other shell history files for commands executed by users that might have led to the file modification.
+- Use Osquery to list all currently loaded kernel modules and running processes to identify any unusual or unauthorized modules or processes that could be related to persistence: `SELECT name, path FROM kernel_modules;` and `SELECT pid, name, path FROM processes;`.
+- Investigate the system for any additional indicators of compromise, such as unexpected network connections or unusual system behavior, which might correlate with the file modification event.
+
+### False positive analysis
+
+- Routine system updates or package installations may modify files monitored by the rule, leading to false positives. Users can manage this by excluding file extensions like "dpkg-new" or "dpkg-remove" from triggering alerts.
+- Temporary files created during system operations, such as those in "/var/spool/cron/crontabs/tmp.*" or "/run/udev/rules.d/*rules.*", can cause false positives. These can be excluded from monitoring to reduce noise.
+- Known hosts files in SSH directories, such as "/home/*/.ssh/known_hosts.*" and "/root/.ssh/known_hosts.*", are often updated during normal SSH operations and can be safely excluded to prevent false alerts.
+- Users should regularly review and update the exclusion list to reflect any new benign patterns observed in their environment, ensuring that legitimate changes do not trigger unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the scope of the modification, including reviewing logs and correlating with other security events.
+- Verify the integrity of the modified files against known good configurations or backups to determine unauthorized changes.
+- Restore the affected files from a clean backup if unauthorized modifications are confirmed.
+- Change all credentials and keys that may have been exposed or compromised due to the persistence mechanism.
+- Escalate the incident to the security operations center (SOC) or incident response team if the modification is part of a broader attack campaign.
+- Implement enhanced logging and monitoring for critical files and directories to detect future unauthorized changes promptly.
+- Review and update file integrity monitoring policies to ensure comprehensive coverage of critical system files.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
index 3d33d2ee993..00027696cb0 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,52 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Subscription Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Pub/Sub Subscription Creation
+
+Google Cloud Platform's Pub/Sub service facilitates asynchronous messaging, allowing services to communicate without direct interaction. Adversaries might exploit this by creating unauthorized subscriptions to intercept or exfiltrate data. The detection rule monitors audit logs for successful subscription creation events, helping identify potential misuse by flagging unexpected or suspicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `gcp.audit` and the action is `google.pubsub.v*.Subscriber.CreateSubscription` with a successful outcome.
+- Identify the user or service account associated with the subscription creation event to determine if it aligns with expected activity.
+- Check the timestamp of the event to see if it coincides with any known maintenance windows or scheduled tasks.
+- Investigate the project and resource names involved in the subscription creation to verify if they are legitimate and expected.
+- Examine the IP address and location from which the subscription creation request originated to identify any anomalies or unexpected access patterns.
+- Use Osquery to gather additional context on the GCP environment. For example, run a query to list all subscriptions in the project: `SELECT * FROM gcp_pubsub_subscriptions WHERE project_id = '<project_id>';`.
+- Cross-reference the subscription creation event with other logs, such as IAM activity logs, to identify any preceding or subsequent suspicious actions.
+- Analyze the permissions and roles assigned to the user or service account to ensure they are appropriate and have not been escalated recently.
+- Review historical data to determine if there have been any similar subscription creation events in the past and their outcomes.
+- Consult with relevant stakeholders or teams to confirm if the subscription creation was part of a legitimate business process or project initiative.
+
+### False positive analysis
+
+- Routine subscription creations by automated processes or scheduled jobs can trigger false positives. These are often part of normal operations and not indicative of malicious activity.
+- Development and testing environments may frequently create and delete subscriptions as part of their workflow, leading to benign alerts.
+- Internal monitoring or logging services might create subscriptions to capture application metrics or logs, which are legitimate and expected activities.
+- To manage these false positives, users can create exceptions for known service accounts or projects that regularly perform these actions.
+- Implementing a baseline of normal subscription creation activity can help differentiate between expected and suspicious behavior.
+- Regularly review and update the list of exceptions to ensure they align with current operational practices and do not inadvertently exclude genuine threats.
+
+### Response and remediation
+
+- Verify the legitimacy of the subscription creation by checking the associated user or service account and their permissions.
+- Contain the potential threat by temporarily disabling the suspicious subscription and any associated service accounts.
+- Investigate the source of the subscription creation by reviewing audit logs for unusual activity or unauthorized access patterns.
+- Remediate by revoking any unauthorized access and resetting credentials for compromised accounts.
+- Escalate the incident to the security operations team if the activity is confirmed as malicious or if there is evidence of data exfiltration.
+- Implement enhanced logging policies to capture detailed access and modification events for Pub/Sub resources.
+- Integrate with a Security Information and Event Management (SIEM) system to automate the detection of suspicious subscription activities.
+- Restore the system to its operational state by re-enabling legitimate subscriptions and ensuring all security measures are in place.
+- Harden the environment by applying the principle of least privilege to all service accounts and regularly reviewing permissions.
+- Educate users and administrators on recognizing and reporting suspicious activities related to Pub/Sub services.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
index 701fd52c77f..f48f9365a3e 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Topic Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Pub/Sub Topic Creation
+
+Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between services by decoupling event producers and consumers. Adversaries might exploit this by creating topics to exfiltrate data or orchestrate malicious activities. The detection rule monitors audit logs for successful topic creation events, helping identify unauthorized or suspicious activities that could indicate abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.pubsub.v*.Publisher.CreateTopic`, and `event.outcome:success` to ensure the alert is based on a successful topic creation event.
+- Identify the user or service account associated with the topic creation by examining the `user.name` or `user.email` fields in the audit log.
+- Check the `source.ip` field to determine the origin of the request and assess if it aligns with known and expected IP addresses for your organization.
+- Investigate the `gcp.project_id` field to understand which project the topic was created in and verify if the project is legitimate and expected to have new topics created.
+- Examine the `gcp.resource.name` field to identify the specific topic name and assess if it follows the naming conventions and patterns used within your organization.
+- Review historical logs for the identified user or service account to determine if there have been any other unusual or unauthorized activities.
+- Use Osquery to gather additional context on the GCP environment. For example, run the following query to list all topics in the project: `SELECT * FROM gcp_pubsub_topics WHERE project_id = '<project_id>';`.
+- Check for any recent changes in IAM policies or permissions related to Pub/Sub within the project to identify potential privilege escalations or misconfigurations.
+- Correlate the topic creation event with other logs or alerts to identify any related suspicious activities, such as data exfiltration attempts or unusual data processing patterns.
+- Consult with the project owner or relevant stakeholders to verify if the topic creation was authorized and aligns with current business needs or projects.
+
+### False positive analysis
+
+- Routine operations by development teams: Developers often create Pub/Sub topics during application development and testing. These activities are typically benign and can be excluded by identifying and whitelisting specific user accounts or service accounts associated with development environments.
+- Automated infrastructure provisioning: Tools like Terraform or Cloud Deployment Manager may automatically create Pub/Sub topics as part of infrastructure setup. To manage these, users can exclude events originating from known automation tools or specific project IDs used for infrastructure management.
+- Scheduled maintenance or updates: Regular maintenance tasks or updates might involve creating new topics temporarily. Users can handle these by setting time-based exceptions during known maintenance windows.
+- Internal data processing workflows: Some internal workflows may require the creation of new topics for data processing. Users should document these workflows and exclude related events by identifying specific patterns or labels associated with these processes.
+
+### Response and remediation
+
+- Verify the legitimacy of the topic creation by checking the associated user or service account and their permissions.
+- Contain potential threats by temporarily disabling the topic or restricting access to it until further investigation is completed.
+- Investigate the source of the topic creation by reviewing audit logs and identifying any unusual patterns or unauthorized access attempts.
+- Remediate unauthorized access by revoking permissions or credentials of compromised accounts and enforcing multi-factor authentication.
+- Escalate the incident to the security operations team if the topic creation is determined to be part of a larger attack or data exfiltration attempt.
+- Implement logging policies to ensure comprehensive monitoring of Pub/Sub activities, including topic creation, modification, and deletion.
+- Integrate with security information and event management (SIEM) systems to enhance real-time detection and correlation of suspicious activities.
+- Restore the system to its operational state by re-enabling legitimate topics and ensuring all security measures are in place.
+- Harden the environment by applying the principle of least privilege to all accounts and regularly reviewing access controls.
+- Educate users and administrators on recognizing and reporting suspicious activities related to Pub/Sub services to prevent future incidents.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/admin"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
index bf65a769bb5..98434b70a9e 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,49 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Firewall Rule Creation
+In GCP, firewall rules manage network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may exploit this by creating rules that allow unauthorized access, bypassing security measures. The detection rule monitors audit logs for specific actions indicating new rule creation, helping identify potential security breaches by flagging suspicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `event.action` that triggered the alert, focusing on `*.compute.firewalls.insert` or `google.appengine.*.Firewall.Create*Rule`.
+- Examine the `event.dataset` field to confirm the event source is `gcp.audit`, ensuring the alert is based on audit logs.
+- Check the `user` or `serviceAccount` associated with the firewall rule creation to determine if the action was performed by a legitimate user or service.
+- Investigate the `sourceIP` and `userAgent` fields to identify the origin of the request and assess if it aligns with expected behavior or known IP addresses.
+- Analyze the `resource.name` field to determine which specific VPC or App Engine application the firewall rule was created for, and assess its criticality.
+- Review the `request` field to understand the parameters of the firewall rule, such as allowed IP ranges, protocols, and ports, to evaluate the potential impact on security.
+- Cross-reference the `timestamp` of the event with other security events or logs to identify any correlated suspicious activities around the same time.
+- Utilize Osquery to gather additional context from affected systems. For example, run the following Osquery query to list recent firewall rule changes: `SELECT * FROM gcp_firewall_rules WHERE action = 'insert' AND timestamp > date('now', '-1 day');`
+- Check for any recent changes in IAM roles or permissions that might have allowed unauthorized users to create firewall rules.
+- Consult with the relevant teams or stakeholders to verify if the firewall rule creation was part of a legitimate change request or deployment process.
+
+### False positive analysis
+
+- Routine administrative actions: Legitimate changes made by network administrators or automated processes can trigger the rule. To manage this, users can create exceptions for known IP addresses or service accounts frequently involved in authorized rule creation.
+- Automated deployment tools: Tools like Terraform or Deployment Manager that automate infrastructure changes may create firewall rules as part of their normal operation. Users should identify and exclude these tools' actions by filtering based on service accounts or specific project IDs.
+- Scheduled maintenance: Regularly scheduled updates or maintenance tasks might involve creating or modifying firewall rules. Users can handle these by setting up time-based exceptions or correlating with maintenance schedules to differentiate between expected and suspicious activities.
+- Development and testing environments: Firewall rules created in non-production environments for testing purposes can be mistaken for malicious activity. Users should tag or label these environments and exclude them from alerts to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC or application to prevent further unauthorized access while maintaining essential services.
+- Review the audit logs to identify the source and context of the unauthorized firewall rule creation, focusing on user accounts and IP addresses involved.
+- Revoke any suspicious or unauthorized firewall rules and revert to the last known good configuration to restore security posture.
+- Conduct a thorough investigation to determine if any other security controls have been impaired or if additional unauthorized changes have been made.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments to assess potential impacts and obligations.
+- Implement enhanced logging policies to capture detailed information on firewall rule changes and other critical security events for future analysis.
+- Integrate with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious firewall rule activities.
+- Educate and train staff on the importance of secure firewall configurations and the risks associated with unauthorized changes.
+- Apply hardening measures such as least privilege access, multi-factor authentication, and regular audits of firewall rules and configurations.
+- Review and update incident response plans to incorporate lessons learned from the incident, ensuring a more robust response to future threats.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
index 2bd5d930541..11ab2691670 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Firewall Rule Deletion
+
+In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, exposing systems to unauthorized access. The detection rule monitors audit logs for deletion actions in VPC and App Engine environments, identifying potential security evasion attempts by tracking specific delete operations.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the deletion event by filtering logs with `event.dataset:gcp.audit` and `event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule)`.
+- Identify the user or service account responsible for the deletion by examining the `principalEmail` field in the audit log entry.
+- Check the `resourceName` field to determine which specific firewall rule was deleted and assess its importance to the network security posture.
+- Investigate the `timestamp` field to establish the exact time of the deletion and correlate it with other security events or anomalies in the environment.
+- Analyze the `sourceIP` field to identify the origin of the request and determine if it matches known or expected IP addresses.
+- Review the `userAgent` field to understand the tool or method used to perform the deletion, which might indicate whether it was a manual action or automated script.
+- Cross-reference the deletion event with recent changes in IAM roles or permissions to see if there were any unauthorized privilege escalations.
+- Use Osquery to gather additional context on the affected VM instances or applications. For example, run a query to list all current firewall rules: `SELECT * FROM gcp_firewall_rules WHERE project_id = 'your_project_id';`.
+- Investigate any recent changes in the network configuration or architecture that might have preceded the firewall rule deletion.
+- Check for any other suspicious activities or alerts in the same timeframe that could indicate a coordinated attack or broader security incident.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks can lead to legitimate firewall rule deletions, such as when network configurations are updated or deprecated rules are removed. Users should verify if the deletion aligns with scheduled maintenance activities.
+- Automated processes or scripts that manage firewall rules might trigger false positives if they are designed to periodically clean up or update rules. Users can create exceptions for these processes by identifying and excluding their specific identifiers or service accounts.
+- Changes in project ownership or restructuring within an organization might result in the deletion of firewall rules as part of resource reallocation. Users should ensure that such changes are documented and authorized to differentiate them from malicious activities.
+- Development and testing environments often have dynamic rule changes, including deletions, as part of normal operations. Users can manage false positives by excluding specific environments or using tags to differentiate between production and non-production resources.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further unauthorized access or damage.
+- Review audit logs to confirm the deletion of firewall rules and identify the source of the action.
+- Recreate the deleted firewall rules based on the last known good configuration to restore security controls.
+- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration occurred following the rule deletion.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed information on firewall rule changes and other critical security events.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate events and detect similar threats in the future.
+- Review and update access controls to ensure only authorized personnel can modify firewall rules.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate and train staff on the importance of firewall rules and the potential impact of their unauthorized deletion, leveraging MITRE ATT&CK framework insights on defense evasion and impair defenses.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
index ae5126fc5fb..37ec443a9c3 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Firewall Rule Modification
+In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential security breaches by tracking specific actions indicative of such changes.
+
+### Possible investigation steps
+
+- Review the audit logs to identify the specific firewall rule that was modified by filtering logs with `event.dataset:gcp.audit` and `event.action:(*.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule)`.
+- Examine the `user.email` field in the audit logs to determine who made the modification and verify if the user is authorized to make such changes.
+- Check the `resource.name` field to identify the specific firewall rule and associated VPC or App Engine application that was altered.
+- Analyze the `protoPayload.request` field to understand the nature of the changes made to the firewall rule, such as new IP ranges or protocols allowed.
+- Investigate the `protoPayload.serviceData.policyDelta` field to see the before and after states of the firewall rule to assess the impact of the modification.
+- Use Osquery to query the GCP environment for additional context on the affected resources. Example query: `SELECT * FROM gcp_firewall_rules WHERE name = '<firewall_rule_name>';`.
+- Correlate the time of the firewall rule modification with other security events or alerts to identify any suspicious activity that might have occurred concurrently.
+- Review the `protoPayload.authenticationInfo.principalEmail` field to confirm the identity of the user and cross-reference with HR or identity management systems for any anomalies.
+- Investigate any recent changes in IAM roles or permissions for the user identified in the audit logs to ensure there are no unauthorized privilege escalations.
+- Check for any other recent modifications to firewall rules or security settings in the GCP environment to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Routine administrative changes: Regular updates or maintenance by network administrators can trigger the rule. To manage this, users can create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated deployment tools: Tools that automatically adjust firewall settings during deployments may cause false positives. Users should identify and exclude these tools' actions from the rule.
+- Internal security audits: Security teams may intentionally modify firewall rules for testing purposes. Users can whitelist these activities by correlating them with audit schedules or specific user accounts.
+- Application updates: Updates to App Engine applications might require temporary firewall rule changes. Users can track these updates and exclude related actions from triggering alerts.
+- Cloud infrastructure changes: Changes in cloud infrastructure, such as scaling operations, might necessitate firewall rule modifications. Users should document these changes and adjust the rule to ignore them when they align with expected patterns.
+
+### Response and remediation
+
+- Immediately isolate affected systems or networks to prevent further unauthorized access or data exfiltration.
+- Review the audit logs to identify the source and scope of the firewall rule modification, including the user account and IP address involved.
+- Revert the modified firewall rules to their previous state to restore intended security controls and prevent unauthorized traffic.
+- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration occurred during the period of altered firewall rules.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement additional logging and monitoring for firewall rule changes to detect and respond to future unauthorized modifications promptly.
+- Integrate with security information and event management (SIEM) systems to correlate firewall rule changes with other security events for comprehensive threat detection.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify firewall rules.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to address these vulnerabilities.
+- Enhance security awareness training for staff to recognize and report suspicious activities related to firewall rule modifications.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
index a9e9ba23557..0446f0ced5d 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,51 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Bucket Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Logging Bucket Deletion
+
+In GCP, log buckets are crucial for storing and managing log data, ensuring visibility into system activities. Adversaries may delete these buckets to obscure their tracks and evade detection. The detection rule identifies successful deletion actions by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.logging.v*.ConfigServiceV*.DeleteBucket`, and `event.outcome:success` to ensure the alert is triggered by a successful bucket deletion.
+- Check the timestamp of the deletion event to determine when the bucket was deleted and correlate it with other security events or anomalies around the same time.
+- Identify the user or service account associated with the deletion action by examining the `actor` field in the audit log to determine if the action was authorized or potentially malicious.
+- Investigate the source IP address and location from which the deletion request was made to identify any unusual access patterns or locations.
+- Review the project and resource details in the audit log to understand the scope and impact of the deletion, including which logs were being stored in the deleted bucket.
+- Examine the `request` and `response` fields in the audit log for additional context on the deletion request, such as any parameters or configurations that were specified.
+- Use Osquery to gather more information about the GCP environment. For example, run the following query to list all current log sinks and their destinations: `SELECT * FROM gcp_logging_sinks;`
+- Check for any recent changes to IAM policies or permissions that might have allowed unauthorized users to delete the log bucket.
+- Investigate any other recent audit logs for suspicious activities involving the same user or service account to identify potential patterns of malicious behavior.
+- Collaborate with the GCP admin team to verify if the deletion was part of a legitimate maintenance activity or if it requires further investigation.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may trigger the GCP Logging Bucket Deletion rule, as legitimate users might delete log buckets for reorganization or storage management purposes.
+- Automated scripts or tools used for managing GCP resources could inadvertently delete log buckets as part of their operations, leading to false positives.
+- To manage these false positives, users can create exceptions for known maintenance activities by excluding specific user accounts or service accounts from the detection rule.
+- Implementing a whitelist of IP addresses or user roles associated with regular administrative tasks can help reduce noise from non-threatening deletions.
+- Regularly review and update the detection rule's filters to exclude actions from trusted sources or during scheduled maintenance windows, ensuring that only suspicious deletions are flagged.
+
+### Response and remediation
+
+- Immediately verify the deletion event by cross-referencing with other logs and alerts to confirm unauthorized activity.
+- Contain the incident by disabling any compromised accounts or credentials that may have been used to delete the log bucket.
+- Investigate the scope of the incident by reviewing access logs and identifying any other suspicious activities or changes in the environment.
+- Remediate by restoring the deleted log bucket from backup if available, or reconfigure log sinks to redirect logs to an alternative bucket.
+- Escalate the incident to the security operations team and relevant stakeholders for further analysis and response.
+- Implement enhanced logging policies to ensure all critical actions are logged and monitored, including changes to logging configurations.
+- Integrate additional security tools and services, such as SIEM or cloud-native security solutions, to improve detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Harden the environment by applying the principle of least privilege to all accounts and regularly reviewing permissions and access controls.
+- Educate and train staff on security best practices and the importance of monitoring and protecting log data to prevent future incidents.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/buckets", "https://cloud.google.com/logging/docs/storage"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
index 3b91941b1cc..7443b7a558b 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Sink Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Logging Sink Deletion
+
+In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and monitoring. Adversaries may delete these sinks to prevent logs from being exported, thus evading detection. The detection rule identifies successful deletion events of logging sinks, signaling potential defense evasion attempts by matching specific audit log actions and outcomes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.logging.v*.ConfigServiceV*.DeleteSink`, and `event.outcome:success` to ensure the alert is valid and corresponds to a successful sink deletion.
+- Identify the user or service account associated with the deletion event by examining the `user.name` or `principalEmail` fields in the audit log entry.
+- Check the timestamp of the deletion event to determine when the sink was deleted and correlate this with any other suspicious activities around the same time.
+- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or unauthorized access patterns.
+- Review the permissions and roles assigned to the user or service account involved in the deletion to assess if they had legitimate access to perform this action.
+- Examine the specific logging sink that was deleted, including its previous configuration and destination, to understand the potential impact on log monitoring and analysis.
+- Cross-reference other logs and alerts from the same time period to identify any related or preceding suspicious activities that might indicate a broader attack or compromise.
+- Utilize Osquery to gather additional context on the affected GCP environment. For example, run a query to list all current logging sinks and their configurations: `SELECT * FROM gcp_logging_sinks;` to verify if other sinks have been tampered with.
+- Investigate any recent changes to IAM policies or service accounts that might have inadvertently or maliciously granted excessive permissions related to logging sink management.
+- Consult with relevant stakeholders or teams to verify if the sink deletion was part of a legitimate change or maintenance activity, and document any findings for future reference.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks: Regular updates or reconfigurations by authorized personnel may involve the deletion and recreation of logging sinks, which can trigger the detection rule. To manage this, users can create exceptions for known maintenance windows or specific user accounts that perform these tasks.
+- Automated scripts or tools: Some organizations use automated processes to manage logging configurations, which might include deleting and recreating sinks as part of their operation. Users should identify these scripts and exclude their actions from triggering alerts by specifying the service accounts or IP addresses associated with these tools.
+- Testing environments: In development or testing environments, logging sinks may be frequently deleted and recreated as part of testing procedures. Users can exclude these environments from the detection rule by filtering based on project IDs or labels associated with non-production environments.
+- Misconfigured alerts: Sometimes, alerts may be triggered due to misconfigured logging sinks that are intentionally deleted to correct errors. Users should review and adjust the configurations to ensure that only relevant deletions are monitored, possibly by refining the query to exclude specific error codes or conditions.
+
+### Response and remediation
+
+- Immediately isolate the affected GCP project to prevent further unauthorized changes and assess the scope of the incident.
+- Review audit logs to identify the user or service account responsible for the sink deletion and determine if any other suspicious activities have been performed.
+- Recreate the deleted logging sink with the appropriate filters and export destinations to restore logging capabilities.
+- Implement additional logging and monitoring to capture any further unauthorized changes, focusing on high-value resources and critical operations.
+- Conduct a thorough investigation to determine if any other security controls have been impaired or if there are signs of lateral movement or data exfiltration.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if law enforcement or external parties need to be notified.
+- Review and update IAM policies to ensure that only authorized users have permissions to modify or delete logging sinks and other critical resources.
+- Implement automated alerts for any future logging sink deletions or modifications to enable rapid response to similar incidents.
+- Consider integrating with a Security Information and Event Management (SIEM) system to enhance log analysis and correlation capabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as enabling multi-factor authentication and regular security training for users.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/export"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
index d81d4f1c70e..97c219fa573 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Subscription Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Pub/Sub Subscription Deletion
+
+Google Cloud Platform's Pub/Sub service facilitates asynchronous communication by decoupling event producers and consumers. Subscriptions are critical as they define message delivery to applications. Adversaries may delete subscriptions to disrupt services or evade detection. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the deletion event by checking the `event.dataset:gcp.audit` and `event.action:google.pubsub.v*.Subscriber.DeleteSubscription` fields to ensure the alert is valid.
+- Identify the user or service account responsible for the deletion by examining the `user.email` or `authenticationInfo.principalEmail` fields in the audit log entry.
+- Determine the time and date of the deletion event using the `event.start` or `timestamp` fields to understand the context and timeline of the activity.
+- Investigate the IP address and location from which the deletion request was made by reviewing the `requestMetadata.callerIp` field to identify any unusual access patterns.
+- Check for any other related activities by the same user or service account around the same time, such as other deletions or modifications, to assess if this is part of a broader attack.
+- Analyze the `resource.labels.subscription_id` field to identify which specific subscription was deleted and assess its importance and impact on the system.
+- Use Osquery to gather additional context on the system where the deletion was initiated. For example, run a query like `SELECT * FROM gcp_pubsub_subscriptions WHERE subscription_id = 'deleted_subscription_id';` to retrieve details about the subscription.
+- Review IAM policies and permissions associated with the user or service account to determine if the deletion was authorized or if there are excessive permissions that need to be addressed.
+- Cross-reference the deletion event with any recent changes in the environment, such as deployments or configuration changes, to identify potential causes or correlations.
+- Consult with relevant stakeholders or teams to gather additional context about the subscription's role and any potential business impact due to its deletion.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may lead to legitimate subscription deletions, which could be flagged as false positives. Users should verify if the deletion aligns with scheduled maintenance activities.
+- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Users can create exceptions for known scripts or service accounts responsible for these actions.
+- Development and testing environments often involve frequent creation and deletion of subscriptions. Users should consider excluding these environments from monitoring or setting up specific rules to differentiate between production and non-production activities.
+- Subscription deletions by authorized personnel for resource optimization or cost management purposes can also trigger alerts. Users should maintain a list of authorized personnel and cross-reference deletion events with their activities to confirm legitimacy.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the subscription deletion by checking with the responsible team or individual.
+- Contain the potential threat by temporarily suspending any related service accounts or credentials that may have been compromised.
+- Investigate the audit logs to identify any unauthorized access patterns or anomalies leading up to the deletion event.
+- Restore the deleted subscription from backups or recreate it using documented configurations to resume normal operations.
+- Escalate the incident to the security operations team if unauthorized access is confirmed, and initiate a full security incident response.
+- Implement enhanced logging policies to capture detailed access and modification events for Pub/Sub resources.
+- Integrate with a Security Information and Event Management (SIEM) system to automate alerting and correlation of suspicious activities.
+- Review and update access controls and permissions for Pub/Sub resources to ensure the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate and train relevant personnel on recognizing and responding to similar threats, leveraging MITRE ATT&CK framework insights for defense evasion tactics.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
index b0c2ba3b66a..ef6307a582e 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,52 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Topic Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Pub/Sub Topic Deletion
+
+Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between applications by decoupling event producers and consumers. Adversaries may delete topics to disrupt communication, impair defenses, or evade detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping to uncover potential malicious activity.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the deletion event by checking the `event.dataset:gcp.audit` and `event.action:google.pubsub.v*.Publisher.DeleteTopic` fields to ensure the alert is not a false positive.
+- Verify the `event.outcome:success` field to confirm that the deletion was successful and not an attempted action.
+- Identify the user or service account responsible for the deletion by examining the `user.name` or `serviceAccount` fields in the audit logs.
+- Check the `source.ip` field to determine the origin of the request and assess if it aligns with expected network activity.
+- Investigate the `timestamp` of the deletion event to understand the timing and correlate it with other activities in the environment.
+- Review the `resource.name` field to identify the specific topic that was deleted and assess its importance and impact on the system.
+- Use Osquery to gather additional context about the GCP environment. For example, run a query to list all remaining Pub/Sub topics: `SELECT * FROM gcp_pubsub_topics;` to understand the current state of the messaging service.
+- Examine related logs and events around the same timeframe to identify any suspicious activities or patterns that might indicate a broader attack.
+- Check for any recent changes in IAM policies or permissions that could have allowed unauthorized users to delete topics.
+- Collaborate with the application or service owners to understand the potential impact of the topic deletion and gather any additional context or insights they might have.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may lead to legitimate topic deletions, which can be mistaken for malicious activity. 
+- Automated scripts or tools used for managing Pub/Sub topics might delete topics as part of their normal operation, triggering false positives.
+- Development and testing environments often involve frequent creation and deletion of topics, which can generate noise in the detection system.
+- To manage these false positives, users can create exceptions for known maintenance periods or specific service accounts that perform regular topic deletions.
+- Implementing a whitelist of topics or service accounts that are expected to be deleted regularly can help reduce unnecessary alerts.
+- Monitoring the context of the deletion, such as the source IP or user agent, can help differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately verify the deletion event by cross-referencing with change management records to confirm if it was authorized.
+- Contain the incident by temporarily disabling any service accounts or credentials that were used to perform the deletion, if unauthorized.
+- Investigate the source of the deletion by reviewing audit logs for any unusual activity or access patterns leading up to the event.
+- Restore the deleted Pub/Sub topic from backups or recreate it using documented configurations to resume normal operations.
+- Escalate the incident to the security operations team if unauthorized access is confirmed, providing them with all relevant logs and findings.
+- Implement enhanced logging policies to ensure all Pub/Sub activities are captured with sufficient detail for future investigations.
+- Integrate Pub/Sub monitoring with a Security Information and Event Management (SIEM) system to enable real-time alerting and analysis.
+- Review and update access controls and permissions for Pub/Sub resources to ensure the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in detection and response processes, and update incident response plans accordingly.
+- Educate relevant teams on the importance of monitoring and securing Pub/Sub resources, emphasizing the potential impact of unauthorized deletions.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
index 58c3e161484..f5f8ff375e6 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Configuration Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Storage Bucket Configuration Modification
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data. They can be configured to control access and security settings. Adversaries may alter these configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful bucket configuration changes, signaling potential security threats by identifying unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the details of the event, focusing on the `event.dataset:gcp.audit` and `event.action:"storage.buckets.update"` fields to verify the specific configuration changes made.
+- Check the `event.outcome:success` field to ensure the modification was successful and not a failed attempt, which might indicate a different type of issue.
+- Identify the user or service account responsible for the change by examining the `user.name` or `user.email` fields in the audit logs.
+- Investigate the source IP address and location from which the change was made to determine if it aligns with expected activity patterns.
+- Review the timing of the configuration change to see if it coincides with any other suspicious activities or known attack patterns.
+- Examine the specific changes made to the bucket configuration, such as changes to access controls or permissions, to assess the potential impact on security.
+- Cross-reference the bucket name and project ID with known assets to determine the criticality and sensitivity of the data stored in the affected bucket.
+- Utilize Osquery to gather additional context on the environment. For example, run the following Osquery query to list all recent bucket configuration changes: `SELECT * FROM gcp_storage_buckets WHERE action = 'update' AND outcome = 'success';`
+- Check for any other recent alerts or anomalies in the environment that might indicate a coordinated attack or broader security incident.
+- Consult with relevant stakeholders or teams to verify if the change was authorized and documented as part of a legitimate business process or project.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or maintenance by authorized personnel can trigger this rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated processes: Some organizations use automated scripts or tools to update bucket configurations as part of their workflow. Identify these processes and exclude them from triggering alerts by whitelisting specific service accounts or automation tools.
+- Third-party integrations: External services or applications with legitimate access may modify bucket settings as part of their operation. Review and document these integrations, then configure exceptions for their actions to prevent false positives.
+- Policy updates: Changes in organizational security policies may require updates to bucket configurations. Ensure that these policy-driven changes are documented and excluded from alerts by correlating them with change management records.
+
+### Response and remediation
+
+- Immediately isolate the affected storage bucket to prevent further unauthorized access or data exfiltration.
+- Review the audit logs to identify the source and nature of the configuration change, focusing on the user or service account responsible for the modification.
+- Verify the integrity of the data within the bucket to ensure no unauthorized changes or deletions have occurred.
+- Revert the storage bucket configuration to its last known secure state using backup configurations or documented settings.
+- Conduct a thorough investigation to determine if the configuration change is part of a larger attack, correlating with other suspicious activities in the environment.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments to assess potential data breach implications.
+- Implement additional logging and monitoring policies to capture detailed access and modification events for storage buckets, enhancing future detection capabilities.
+- Integrate with security information and event management (SIEM) systems to automate alerting and response processes for similar incidents.
+- Apply hardening measures such as enforcing least privilege access, enabling bucket versioning, and implementing strong authentication mechanisms for accessing storage resources.
+- Educate and train staff on security best practices and the importance of maintaining secure configurations to prevent similar incidents in the future.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
index 5aa2543b2d8..1df8709608b 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Permissions Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Storage Bucket Permissions Modification
+
+Google Cloud Platform (GCP) storage buckets are used to store and manage data. Permissions are controlled via IAM policies, which define who can access or modify resources. Adversaries may exploit these permissions to gain unauthorized access or expose sensitive data. The detection rule monitors audit logs for successful changes to bucket permissions, signaling potential security risks or misconfigurations.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event details, focusing on the `event.dataset:gcp.audit` and `event.action:"storage.setIamPermissions"` fields to ensure the alert is valid and corresponds to a permissions change.
+- Identify the user or service account responsible for the permissions modification by examining the `user.name` or `user.email` fields in the audit logs.
+- Determine the specific changes made to the IAM policy by reviewing the `event.outcome:success` field and any associated details about the new permissions granted or removed.
+- Cross-reference the user or service account with known authorized personnel or services to assess if the change was expected or potentially malicious.
+- Investigate the timing of the permissions change to see if it coincides with any other suspicious activities or known incidents.
+- Check the history of permissions changes for the affected storage bucket to identify any patterns or repeated unauthorized modifications.
+- Use Osquery to gather additional context about the environment. For example, run a query to list all current IAM policies for the storage bucket: `SELECT * FROM gcp_iam_policies WHERE resource_name = 'projects/<project-id>/buckets/<bucket-name>';`.
+- Analyze any related network activity or access logs to determine if there was any unauthorized data access following the permissions change.
+- Review any recent changes in the organization's GCP environment or configurations that might explain the permissions modification.
+- Consult with the bucket owner or relevant stakeholders to verify if the permissions change was part of a legitimate business process or project.
+
+### False positive analysis
+
+- Routine administrative tasks: Changes made by authorized personnel during regular maintenance or updates can trigger the rule. To manage this, users can create exceptions for known maintenance windows or specific admin accounts.
+- Automated processes: Scheduled scripts or automated tools that modify bucket permissions as part of their operation may cause false positives. Users should identify these processes and exclude them from the rule by specifying their service accounts.
+- Third-party integrations: Some third-party services require permission changes to function correctly. Users should review and whitelist these services if they are deemed non-threatening.
+- Organizational policy updates: Changes in organizational policies that necessitate permission updates across multiple buckets can be mistaken for suspicious activity. Users can document and exclude these policy-driven changes by correlating them with internal change management records.
+
+### Response and remediation
+
+- Immediately review the IAM policy change to identify the user or service account responsible for the modification and verify if the change was authorized.
+- Revert any unauthorized or suspicious IAM permission changes to their previous state to prevent further unauthorized access.
+- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the period of unauthorized access.
+- Implement additional logging and monitoring for IAM changes on storage buckets to detect and alert on future unauthorized modifications.
+- Escalate the incident to the security operations team for further analysis and to determine if the incident is part of a larger attack campaign.
+- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of future unauthorized changes.
+- Conduct a security awareness session with administrators to reinforce the importance of careful IAM policy management and the potential risks of misconfigurations.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate IAM changes with other security events for enhanced threat detection.
+- Restore any affected systems or data to their last known good state if data integrity was compromised during the incident.
+- Implement additional security controls such as multi-factor authentication and conditional access policies to strengthen the security posture of GCP resources.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/access-control/iam-permissions"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
index ae837651b9c..386e69d90f5 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Network Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Virtual Private Cloud Network Deletion
+
+Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, identifying potential malicious activities by correlating specific event actions and outcomes.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event by filtering for `event.dataset:gcp.audit` and `event.action:v*.compute.networks.delete` with `event.outcome:success` to ensure the alert is not a false positive.
+- Identify the user or service account responsible for the deletion by examining the `user.name` and `user.email` fields in the audit logs.
+- Check the timestamp of the deletion event to determine when the VPC network was deleted and correlate it with other activities in the environment.
+- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or suspicious access patterns.
+- Review the project and organization context by examining the `project.id` and `project.name` fields to understand the scope and potential impact of the deletion.
+- Analyze related events in the audit logs around the same timeframe to identify any preceding or subsequent suspicious activities, such as changes to IAM roles or permissions.
+- Use Osquery to gather additional context on the affected GCP environment. For example, run the following Osquery query to list recent changes in the GCP project: `SELECT * FROM gcp_audit_logs WHERE action = 'v*.compute.networks.delete' AND outcome = 'success';`
+- Check for any recent changes to IAM policies or roles that might have granted the necessary permissions for the VPC deletion.
+- Investigate whether there were any alerts or incidents reported by other security tools around the same time, which might indicate a broader attack campaign.
+- Consult with the project owner or relevant stakeholders to verify if the VPC deletion was authorized and gather any additional context or insights they might have.
+
+### False positive analysis
+
+- Routine maintenance or infrastructure changes: Organizations may regularly delete and recreate VPC networks as part of their infrastructure management or during scheduled maintenance. These actions, while legitimate, can trigger the detection rule. To manage this, users can create exceptions for specific projects or time frames where such activities are expected.
+- Automated deployment tools: Tools like Terraform or Google Cloud Deployment Manager might delete and recreate VPC networks as part of their automated workflows. Users should identify these tools and exclude their actions from triggering alerts by filtering based on service accounts or specific project IDs associated with these tools.
+- Testing environments: In development or testing environments, VPC networks may be frequently created and deleted as part of testing processes. Users can exclude these environments from the detection rule by using tags or labels that identify non-production environments.
+- User error: Accidental deletions by authorized users can occur, especially in environments with less stringent access controls. Implementing role-based access controls and monitoring for patterns of behavior can help distinguish between malicious and non-malicious deletions.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further unauthorized access or damage.
+- Review audit logs to confirm the deletion event and identify any associated suspicious activities or accounts.
+- Verify the identity and access permissions of users involved in the deletion to ensure they are legitimate and authorized.
+- Restore the deleted VPC network from backups or recreate it using documented configurations to resume normal operations.
+- Implement additional logging and monitoring for VPC network changes to detect and respond to future unauthorized deletions.
+- Escalate the incident to the security operations team for further investigation and to determine the full scope of the breach.
+- Conduct a root cause analysis to understand how the adversary gained access and deleted the VPC network.
+- Update access controls and permissions to follow the principle of least privilege, reducing the risk of unauthorized deletions.
+- Integrate threat intelligence feeds to enhance detection capabilities and stay informed about emerging threats related to VPC deletions.
+- Educate and train staff on security best practices and the importance of reporting suspicious activities promptly.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/vpc"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
index 14e579912ce..57e88af4595 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,51 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Route Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Virtual Private Cloud Route Creation
+
+In GCP, VPC routes dictate network traffic paths between VM instances and other destinations, both internal and external. Adversaries may exploit this by creating routes to reroute or intercept traffic, potentially evading defenses. The detection rule monitors audit logs for route creation actions, identifying suspicious activities that could indicate such abuse.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event dataset is `gcp.audit` and the event action is either `v1.compute.routes.insert` or `beta.compute.routes.insert` to ensure the alert is valid.
+- Identify the user or service account associated with the route creation by examining the `principalEmail` field in the audit log entry.
+- Check the `resourceName` field to determine the specific VPC and route that was created, and assess whether it aligns with expected network configurations.
+- Investigate the `request` field in the audit log to gather details about the route parameters, such as destination range and next hop, to understand the potential impact on network traffic.
+- Cross-reference the `sourceIP` field to identify the origin of the request and determine if it matches known IP addresses or locations associated with legitimate administrative activity.
+- Use Osquery to query the GCP environment for recent changes in network configurations. Example query: `SELECT * FROM gcp_vpc_routes WHERE creation_time > datetime('now', '-1 day');` to find any recent route creations.
+- Analyze historical audit logs for patterns of similar route creation activities by the same user or service account to identify potential malicious behavior.
+- Check for any recent changes in IAM policies or permissions that might have allowed unauthorized users to create routes.
+- Correlate the route creation event with other security alerts or anomalies in the environment to identify potential coordinated attack patterns.
+- Consult with the network or cloud infrastructure team to verify if the route creation was part of a planned change or if it deviates from standard operating procedures.
+
+### False positive analysis
+
+- Routine network configuration changes by authorized personnel can trigger the rule, as legitimate route creation is a common administrative task in managing cloud environments.
+- Automated deployment tools or scripts that create or modify routes as part of infrastructure provisioning or scaling activities may also generate alerts.
+- Scheduled maintenance activities that involve network reconfiguration might lead to false positives if not properly documented or communicated.
+- To manage these false positives, users can create exceptions for known and trusted sources of route creation, such as specific service accounts or IP addresses associated with legitimate administrative activities.
+- Implementing a review process for flagged events can help distinguish between benign and suspicious activities, ensuring that only genuine threats are escalated for further investigation.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC to prevent further unauthorized traffic routing and potential data exfiltration.
+- Review the audit logs to identify the source and context of the route creation, focusing on user accounts and IP addresses involved.
+- Verify the legitimacy of the route by consulting with the network and security teams to determine if it aligns with expected network configurations.
+- Revoke any unauthorized access or permissions that allowed the route creation, and reset credentials for compromised accounts.
+- Remove the unauthorized route and restore the network configuration to its previous state to ensure normal traffic flow.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed network and user activity, ensuring future incidents can be detected more efficiently.
+- Integrate threat intelligence feeds and anomaly detection tools to identify similar tactics, techniques, and procedures (TTPs) associated with MITRE ATT&CK T1562.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply network hardening measures, such as least privilege access controls and regular audits of network configurations, to prevent future unauthorized route creations.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
index b0b775a5f06..0a0dc22a3fd 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,51 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Route Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Virtual Private Cloud Route Deletion
+
+In GCP, VPC routes dictate network traffic paths between VM instances and other destinations. Adversaries may delete these routes to disrupt network traffic, potentially evading defenses or impairing system operations. The detection rule monitors audit logs for successful route deletions, flagging potential malicious activity by identifying unusual or unauthorized changes in network configurations.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event by checking the `event.dataset:gcp.audit` and `event.action:v*.compute.routes.delete` fields to ensure the deletion was successful, as indicated by `event.outcome:success`.
+- Identify the user or service account responsible for the route deletion by examining the `user.name` or `user.email` fields in the audit logs.
+- Check the timestamp of the deletion event to determine when the route was deleted and correlate it with any other suspicious activities around the same time.
+- Investigate the source IP address from which the deletion request was made to determine if it aligns with known and authorized IP addresses.
+- Review the specific route details that were deleted, including the destination and next hop, to assess the potential impact on network traffic.
+- Examine the project and VPC network associated with the deleted route to understand the broader context and potential impact on the cloud environment.
+- Use Osquery to gather additional context by running a query to list all current routes in the affected VPC network: `SELECT * FROM gcp_vpc_routes WHERE network = '<affected-network-name>';`.
+- Check for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete routes.
+- Look for any other recent audit log entries related to network configuration changes to identify patterns or additional unauthorized activities.
+- Consult with the network or cloud infrastructure team to verify if the route deletion was part of a planned change or if it was unexpected.
+
+### False positive analysis
+
+- Routine maintenance or network reconfiguration activities by authorized personnel can trigger false positives. These activities often involve legitimate route deletions as part of network optimization or updates.
+- Automated scripts or tools used for infrastructure management may delete routes as part of their normal operation, leading to false alerts. Monitoring for patterns or schedules of such activities can help differentiate between benign and suspicious deletions.
+- Changes in network architecture, such as the decommissioning of certain VPCs or the migration of services, may necessitate route deletions. These should be documented and communicated to the security team to prevent unnecessary alerts.
+- To manage false positives, users can create exceptions for known and approved activities by maintaining a whitelist of authorized users or service accounts that regularly perform route deletions.
+- Implementing a change management process where all network changes, including route deletions, are logged and reviewed can help in distinguishing between legitimate and unauthorized actions.
+
+### Response and remediation
+
+- Immediately isolate affected systems to prevent further unauthorized access or disruption of network traffic.
+- Review audit logs to identify the source of the route deletion and determine if it was authorized or part of a larger attack.
+- Restore deleted routes using backup configurations or manually recreate them based on documented network architecture.
+- Conduct a thorough investigation to identify any additional unauthorized changes or suspicious activities in the network.
+- Escalate the incident to the security operations team and relevant stakeholders for further analysis and response.
+- Implement stricter access controls and permissions for managing VPC routes to prevent unauthorized deletions.
+- Enhance logging and monitoring policies to ensure comprehensive visibility into network configuration changes and access attempts.
+- Integrate threat intelligence feeds and anomaly detection tools to identify potential indicators of compromise related to route deletions.
+- Regularly review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
+- Apply network hardening measures, such as enabling multi-factor authentication and using service accounts with the least privilege, to reduce the risk of similar incidents.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
diff --git a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
index c1b0254c4f0..d1b4f8841e6 100644
--- a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
+++ b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Sink Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Logging Sink Modification
+
+In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule monitors audit logs for successful sink updates, flagging potential unauthorized modifications indicative of such malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `event.action` and `event.outcome` fields, confirming that the action was a successful `UpdateSink`.
+- Examine the `event.dataset` field to ensure the log entry is from `gcp.audit`, verifying the source of the alert.
+- Identify the user or service account associated with the `UpdateSink` action by reviewing the `user.name` or `user.email` fields in the audit log.
+- Check the `source.ip` or `source.location` fields to determine the origin of the request, which may provide insights into whether the action was performed from an unusual location.
+- Investigate the `destination` field in the log entry to identify the new export destination for the logging sink, assessing whether it is an authorized and expected location.
+- Review historical logs for the same `user.name` or `user.email` to identify any other suspicious activities or patterns of behavior.
+- Use Osquery to query the GCP environment for recent changes to logging sinks with a command like: `SELECT * FROM gcp_logging_sinks WHERE last_modified > date('now', '-1 day');` to identify any other recent modifications.
+- Cross-reference the `UpdateSink` action with any recent IAM policy changes to determine if there were any permissions granted that could facilitate unauthorized sink modifications.
+- Analyze the timeline of events leading up to the `UpdateSink` action to identify any preceding suspicious activities or anomalies.
+- Consult with the relevant GCP project owners or administrators to verify if the sink modification was authorized and aligns with expected changes or business needs.
+
+### False positive analysis
+
+- Routine administrative changes: Regular updates or maintenance by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time frames when maintenance is scheduled.
+- Automated processes: Some organizations use automated scripts or tools to update logging sinks as part of their cloud management strategy. Users should identify these processes and exclude them from triggering alerts by whitelisting the associated service accounts or IP addresses.
+- Integration with third-party services: When integrating GCP with third-party logging or monitoring services, sink modifications may occur. Users can handle these by verifying the legitimacy of the third-party service and excluding its associated actions from the rule.
+- Testing and development environments: Changes in non-production environments might be frequent and benign. Users can exclude specific projects or environments from the rule to reduce noise while ensuring production environments remain monitored.
+
+### Response and remediation
+
+- Immediately isolate the affected GCP project to prevent further unauthorized access or data exfiltration.
+- Review the audit logs to identify the source and scope of the sink modification, including the user account and IP address involved.
+- Revert the logging sink configuration to its original state to ensure logs are routed to the intended destinations.
+- Conduct a thorough investigation to determine if any data was exfiltrated and assess the impact on the organization.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
+- Implement stricter access controls and permissions for modifying logging sinks, ensuring only authorized personnel have access.
+- Enhance logging and monitoring policies to include alerts for any future modifications to logging sinks.
+- Integrate with a security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply hardening measures such as enabling multi-factor authentication (MFA) and regular audits of logging configurations to prevent similar incidents.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/export#how_sinks_work"]
diff --git a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
index c999c7eebe1..ec13ab4b6fd 100644
--- a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
+++ b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Role Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP IAM Role Deletion
+
+Google Cloud Platform's Identity and Access Management (IAM) system is crucial for defining permissions and access controls across cloud resources. Adversaries may exploit this by deleting IAM roles, thereby disrupting legitimate user access and potentially masking unauthorized activities. The detection rule monitors audit logs for successful role deletions, signaling potential misuse and enabling timely investigation.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event by checking the `event.dataset:gcp.audit` and `event.action:google.iam.admin.v*.DeleteRole` fields to ensure the deletion was successful, as indicated by `event.outcome:success`.
+- Identify the user or service account responsible for the deletion by examining the `user.name` or `principalEmail` fields in the audit logs.
+- Determine the time and date of the role deletion to establish a timeline of events by reviewing the `@timestamp` field.
+- Investigate the specific IAM role that was deleted by looking at the `resource.name` field to understand the permissions that were removed.
+- Check for any recent changes in IAM policies or permissions associated with the affected resources to identify potential unauthorized modifications.
+- Correlate the role deletion event with other logs or alerts around the same timeframe to identify any suspicious activities or patterns.
+- Use Osquery to gather additional context on the affected resources or accounts. For example, run the following Osquery command to list recent IAM role changes: `SELECT * FROM gcp_iam_policy WHERE action = 'DeleteRole' AND timestamp > 'YYYY-MM-DDTHH:MM:SSZ';`.
+- Investigate the network activity of the user or service account involved in the deletion to identify any unusual access patterns or connections.
+- Review the organization's change management records or communication logs to verify if the role deletion was authorized or part of a planned change.
+- Consult with relevant stakeholders or team members to gather additional context or insights regarding the role deletion and its potential impact on operations.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate role deletions may occur during regular maintenance or restructuring of IAM roles by authorized personnel. To manage these, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
+- Automated role management tools: Some organizations use automated tools or scripts to manage IAM roles, which might include role deletions as part of their normal operation. Users should identify these tools and exclude their activities from triggering alerts by whitelisting their service accounts or specific actions.
+- Role lifecycle management: In environments where roles are frequently created and deleted as part of a lifecycle management process, users can reduce false positives by setting up alerts only for roles that are critical or have been flagged for monitoring.
+- Testing and development environments: Role deletions in non-production environments might not indicate malicious activity. Users can exclude these environments from monitoring or adjust the sensitivity of alerts to focus on production environments where the impact of role deletion is more significant.
+
+### Response and remediation
+
+- Immediately contain the incident by revoking any active sessions and access tokens associated with the affected IAM role to prevent further unauthorized access.
+- Investigate the audit logs to identify the source of the role deletion, including the user or service account responsible, and assess whether it was a legitimate action or part of a malicious activity.
+- Restore the deleted IAM role by recreating it with the original permissions, ensuring that legitimate users regain access to necessary resources.
+- Escalate the incident to the security operations team if the deletion is determined to be unauthorized or part of a broader attack, providing them with all relevant logs and findings.
+- Implement enhanced logging policies to capture detailed IAM activity, including role creation, modification, and deletion events, to improve future detection and investigation capabilities.
+- Integrate with a Security Information and Event Management (SIEM) system to automate the monitoring and alerting of suspicious IAM activities, ensuring timely response to potential threats.
+- Conduct a thorough review of IAM policies and permissions to identify and remediate any overly permissive roles that could be exploited by adversaries.
+- Educate users and administrators on the importance of IAM security and the potential impact of unauthorized role deletions, promoting awareness and adherence to best practices.
+- Regularly audit IAM roles and permissions to ensure they align with the principle of least privilege, reducing the risk of misuse or accidental deletions.
+- Consider implementing multi-factor authentication (MFA) and conditional access policies to add an additional layer of security for accessing and managing IAM roles.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/understanding-roles"]
diff --git a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
index 7f30b45a128..0332fcd7d36 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,52 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Service Account Deletion
+
+Service accounts in GCP are crucial for applications and VMs to perform authorized operations without user intervention. Adversaries may delete these accounts to disrupt services or remove access, impacting business operations. The detection rule monitors audit logs for successful service account deletions, identifying potential malicious activity by correlating specific actions and outcomes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.iam.admin.v*.DeleteServiceAccount`, and `event.outcome:success` to ensure the alert is valid and corresponds to a successful service account deletion.
+- Identify the specific service account that was deleted by examining the relevant fields in the audit log, such as `serviceAccountId` or `serviceAccountName`.
+- Determine the timestamp of the deletion event to establish a timeline and correlate it with other activities in the environment.
+- Investigate the user or service that initiated the deletion by reviewing the `actor` field in the audit log to understand if it was an expected or authorized action.
+- Check for any recent changes in IAM policies or permissions related to the deleted service account to identify potential misconfigurations or unauthorized access.
+- Analyze other audit logs around the same timeframe for any unusual or suspicious activities, such as failed login attempts or changes to other critical resources.
+- Use Osquery to gather additional context on the affected systems or applications. For example, run a query to list all service accounts and their current status: `SELECT * FROM gcp_service_accounts WHERE status = 'ACTIVE';` to verify if other accounts are impacted.
+- Investigate any recent deployments or changes in the environment that might have triggered the deletion, such as automated scripts or CI/CD pipeline activities.
+- Review communication channels and change management records to verify if the deletion was part of a planned maintenance or update.
+- Collaborate with the application or system owners to understand the potential impact of the service account deletion and gather insights into any ongoing issues or disruptions.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may lead to legitimate service account deletions, such as when accounts are no longer needed or are being rotated for security purposes.
+- Automated scripts or tools used for infrastructure management might delete service accounts as part of their normal operation, especially in environments with dynamic resource provisioning.
+- Service account deletions during organizational restructuring or project decommissioning can trigger alerts, even though these actions are planned and authorized.
+- To manage these false positives, users can create exceptions for known maintenance windows or specific projects where frequent deletions are expected.
+- Implementing a whitelist of service accounts that are regularly deleted as part of automated processes can help reduce noise in the detection system.
+- Users should regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately contain the incident by revoking any remaining access that the deleted service account had to critical resources.
+- Investigate the audit logs to identify the source of the deletion request, including the user or system that initiated the action and the IP address used.
+- Verify if the deletion was authorized by checking with the relevant team or personnel responsible for managing service accounts.
+- Restore the deleted service account from a backup or recreate it with the same permissions to ensure continuity of operations.
+- Escalate the incident to the security operations team if unauthorized deletion is confirmed, and involve legal or compliance teams if necessary.
+- Implement additional logging policies to capture detailed actions related to service account management, including creation, modification, and deletion events.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate service account activities with other security events for enhanced monitoring.
+- Conduct a review of current IAM policies and permissions to ensure the principle of least privilege is enforced for service account management.
+- Educate and train staff on the importance of service account security and the potential impact of unauthorized deletions.
+- Consider implementing automated alerts for critical service account changes to enable rapid response to potential security incidents.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
index 034f249af9b..05fb74405c4 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Service Account Disabled
+
+In GCP, service accounts facilitate secure application interactions by authorizing API calls. Disabling these accounts can disrupt services, a tactic adversaries might use to impair operations. The detection rule monitors audit logs for successful disablement actions, signaling potential malicious interference by identifying when a service account is intentionally deactivated.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event details, focusing on `event.dataset:gcp.audit` to ensure the event source is accurate.
+- Verify the `event.action:google.iam.admin.v*.DisableServiceAccount` to confirm that the action taken was indeed a service account disablement.
+- Check the `event.outcome:success` field to ensure the disablement action was successful, indicating the account is currently disabled.
+- Identify the service account that was disabled by examining the specific service account ID or name in the audit logs.
+- Investigate the user or process that initiated the disablement by reviewing the actor's identity in the audit logs.
+- Correlate the timestamp of the disablement event with other logs to identify any preceding or subsequent suspicious activities.
+- Use Osquery to gather additional context on the affected service account by running a query such as: `SELECT * FROM gcp_service_accounts WHERE account_id = '<service_account_id>';` to retrieve details about the service account.
+- Assess the impact of the disabled service account by identifying the applications or services that rely on it for API calls.
+- Review IAM policies and permissions associated with the disabled service account to understand its access scope and potential impact.
+- Investigate any recent changes to IAM roles or permissions that might have facilitated the disablement action, looking for anomalies or unauthorized modifications.
+
+### False positive analysis
+
+- Routine maintenance activities: Service accounts may be disabled during scheduled maintenance or updates by administrators. To manage this, users can create exceptions for known maintenance periods or specific accounts frequently involved in such activities.
+- Decommissioning of services: When services or applications are retired, associated service accounts might be intentionally disabled. Users should document and exclude these decommissioning events from alerts to avoid false positives.
+- Security policy enforcement: Organizations may have policies that require periodic disabling of service accounts for security audits or compliance checks. Users can handle these by maintaining a list of accounts subject to such policies and excluding them from the detection rule.
+- Automated scripts or tools: Some automated processes might disable service accounts as part of their operation. Users should identify these scripts or tools and configure exceptions for their actions to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the service account disablement by checking with the account owner or relevant team.
+- Contain the potential threat by temporarily restricting access to critical resources that the disabled service account was associated with.
+- Investigate audit logs to identify any unauthorized access or suspicious activities leading up to the disablement event.
+- If malicious activity is confirmed, escalate the incident to the security operations team for further analysis and response.
+- Restore the disabled service account by re-enabling it and ensuring that its permissions are correctly configured to prevent unauthorized access.
+- Implement additional logging policies to capture detailed information on service account activities and access patterns.
+- Integrate with a Security Information and Event Management (SIEM) system to enhance real-time monitoring and alerting capabilities.
+- Conduct a review of all service accounts to ensure they follow the principle of least privilege and are necessary for current operations.
+- Educate relevant personnel on the importance of monitoring service account activities and recognizing signs of potential compromise.
+- Apply hardening measures such as enabling multi-factor authentication (MFA) for administrative actions and regularly rotating service account keys.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
index cfc19dbb136..2f7a1676ef8 100644
--- a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Storage Bucket Deletion
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in cloud environments. Adversaries may target these buckets to delete critical data, causing operational disruptions. The detection rule monitors audit logs for deletion actions, identifying potential malicious activity by flagging unauthorized or suspicious bucket deletions, thus enabling timely incident response.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the deletion event by filtering for `event.dataset:gcp.audit` and `event.action:"storage.buckets.delete"`.
+- Identify the user or service account associated with the deletion by examining the `principalEmail` field in the audit logs.
+- Check the `resourceName` field to determine the specific storage bucket that was deleted.
+- Investigate the `requestMetadata.callerIp` field to identify the source IP address from which the deletion request originated.
+- Analyze the `timestamp` field to establish the exact time of the deletion and correlate it with other events or activities in the environment.
+- Verify if there are any other suspicious activities associated with the same user or service account around the time of the deletion.
+- Use Osquery to gather additional context on the system from which the deletion was initiated. Example query: `SELECT * FROM process_events WHERE cmdline LIKE '%gcloud%' AND time >= 'timestamp_of_deletion'`.
+- Check for any recent changes in IAM policies or permissions that might have allowed unauthorized access to the storage bucket.
+- Review any alerts or logs from other security tools that might indicate a broader attack or compromise.
+- Consult with relevant stakeholders or teams to gather additional context or insights regarding the deleted storage bucket and its importance to business operations.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may lead to legitimate bucket deletions, such as when a project is being decommissioned or data is being migrated to a different storage solution. Users should verify if the deletion aligns with scheduled maintenance activities.
+- Automated scripts or tools that manage cloud resources might delete buckets as part of their normal operation. Users can create exceptions for these actions by identifying and excluding specific service accounts or automation tools from the detection rule.
+- Development and testing environments often involve frequent creation and deletion of storage buckets. Users should consider excluding these environments from the detection rule to avoid unnecessary alerts.
+- Temporary buckets used for data processing or analysis might be deleted once the task is completed. Users can manage these false positives by tagging such buckets and configuring the detection rule to ignore deletions of tagged resources.
+
+### Response and remediation
+
+- Immediately isolate affected systems and accounts to prevent further unauthorized access or data loss.
+- Verify the deletion event by cross-referencing with internal change management records to confirm if it was authorized.
+- Conduct a thorough investigation to identify the source of the deletion, including reviewing access logs and identifying any compromised credentials.
+- Restore the deleted storage bucket from the most recent backup to minimize operational disruption.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
+- Implement enhanced logging and monitoring policies to capture detailed access and modification events for storage buckets.
+- Integrate with a security information and event management (SIEM) system to correlate events and detect similar threats in the future.
+- Review and update access controls and permissions for storage buckets to ensure the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to potential security threats, emphasizing the importance of reporting suspicious activities.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
diff --git a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
index fbf52054537..dd91cafabd1 100644
--- a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
+++ b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,54 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Custom Role Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP IAM Custom Role Creation
+
+Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, enhancing security by adhering to the principle of least privilege. However, adversaries may exploit these roles to gain unauthorized access or escalate privileges. The detection rule monitors audit logs for successful custom role creation events, helping identify potential misuse by correlating them with known threat tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `gcp.audit` and the event action is `google.iam.admin.v*.CreateRole` with a successful outcome.
+- Examine the timestamp of the custom role creation event to determine when the activity occurred.
+- Identify the user or service account associated with the role creation by reviewing the `actor` field in the audit log.
+- Check the `request` field in the audit log to understand the permissions included in the newly created custom role.
+- Investigate the `resource` field to determine the project or organization where the custom role was created.
+- Correlate the custom role creation event with other recent IAM activities, such as role assignments or permission changes, to identify potential privilege escalation attempts.
+- Use Osquery to gather additional context on the involved user or service account. For example, run the following query to list recent IAM activities for the account:
+  ```sql
+  SELECT * FROM gcp_iam_policy_audit WHERE actor_email = '<user_email>' ORDER BY timestamp DESC LIMIT 10;
+  ```
+- Review the organization's IAM policy change history to identify any unusual patterns or unauthorized modifications.
+- Investigate any associated network or system logs for suspicious activities around the time of the custom role creation.
+- Consult with relevant stakeholders or the user involved to verify the legitimacy of the custom role creation and understand its intended purpose.
+
+### False positive analysis
+
+- Routine administrative tasks: Custom roles may be created as part of regular administrative activities to tailor permissions for new projects or teams. These actions are typically non-threatening and can be identified by correlating the role creation with authorized change management records.
+- Automated processes: Some organizations use automation tools to manage IAM roles, which may include the creation of custom roles. These processes should be documented and can be excluded from alerts by identifying the service accounts or automation tools involved.
+- Development and testing environments: Custom roles are often created in non-production environments for testing purposes. These environments can be excluded from monitoring by filtering based on project or environment tags.
+- Known service accounts: If certain service accounts are regularly involved in creating custom roles as part of their legitimate function, these can be added to an exception list to reduce noise.
+- Frequent role updates: In dynamic environments where roles are frequently updated to accommodate changing needs, it may be beneficial to establish a baseline of expected behavior and exclude these from alerts unless they deviate significantly from the norm.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action.
+- Contain the potential threat by temporarily disabling the custom role to prevent any unauthorized access or privilege escalation.
+- Verify the permissions assigned to the custom role and assess whether they align with the principle of least privilege.
+- Investigate the context of the role creation by checking for any recent changes in IAM policies or unusual activities associated with the involved accounts.
+- If unauthorized access is confirmed, revoke any sessions or tokens associated with the compromised accounts and reset their credentials.
+- Escalate the incident to the security operations team for a thorough investigation and to determine if further actions are needed.
+- Implement enhanced logging policies to capture detailed IAM activities and integrate with a Security Information and Event Management (SIEM) system for real-time monitoring.
+- Conduct a review of all custom roles in the environment to ensure they are necessary and properly scoped, removing any that are redundant or overly permissive.
+- Develop and enforce a policy for regular audits of IAM roles and permissions to prevent privilege creep and ensure compliance with security best practices.
+- Consider implementing additional security measures such as multi-factor authentication (MFA) and automated alerts for critical IAM changes to strengthen the security posture.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/understanding-custom-roles"]
diff --git a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
index 18048b305d9..ade127102ba 100644
--- a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
+++ b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Service Account Key Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP IAM Service Account Key Deletion
+
+In GCP, service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries may delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aligning with MITRE ATT&CK's account manipulation techniques.
+
+### Possible investigation steps
+
+- Review the audit log entry details for the event.dataset:gcp.audit to confirm the deletion event and gather additional context such as timestamp, user identity, and source IP address.
+- Examine the event.action field to ensure it matches google.iam.admin.v*.DeleteServiceAccountKey, confirming the specific action of key deletion.
+- Check the event.outcome field to verify the success of the key deletion, ensuring the alert is not a false positive due to a failed attempt.
+- Identify the service account associated with the deleted key and determine its role and permissions within the GCP environment to assess potential impact.
+- Investigate the user or service account responsible for the deletion by reviewing the actor identity in the audit logs, focusing on any anomalies or unauthorized access patterns.
+- Cross-reference the timestamp of the key deletion with other security events or logs to identify any correlated suspicious activities or access attempts.
+- Utilize Osquery to query the GCP environment for recent changes to IAM policies or roles that might indicate broader account manipulation. Example query: `SELECT * FROM gcp_iam_policies WHERE action = 'DeleteServiceAccountKey' AND outcome = 'success';`
+- Analyze historical audit logs for patterns of key deletions or other IAM changes that could suggest a recurring issue or targeted attack.
+- Review the service account's usage history to determine if the deleted key was actively in use and identify any services or applications that may be affected.
+- Consult with relevant stakeholders or application owners to verify if the key deletion was authorized and part of a scheduled key rotation or if it was unexpected.
+
+### False positive analysis
+
+- Routine key rotation: Regularly scheduled key rotations by administrators or automated processes can trigger this detection rule. To manage this, users can create exceptions for known maintenance windows or specific service accounts involved in routine rotations.
+- Testing and development activities: In development environments, service account keys may be frequently created and deleted as part of testing processes. Users can exclude these environments from the detection rule or set up alerts with lower priority.
+- Decommissioning of services: When services are intentionally decommissioned, associated service account keys may be deleted. Users should document and verify these activities to differentiate them from malicious actions.
+- Automated security tools: Some security tools may automatically delete and recreate service account keys as part of their operations. Users should identify these tools and configure the detection rule to recognize and exclude their legitimate actions.
+
+### Response and remediation
+
+- Immediately contain the incident by revoking access for the compromised service account and disabling any associated applications to prevent further unauthorized access.
+- Investigate the audit logs to identify the source of the key deletion, including the user or service account responsible, and any associated IP addresses or locations.
+- Verify if any unauthorized changes or access occurred using the deleted key and assess the impact on the affected services and data.
+- Restore the service by creating a new service account key, updating the application configuration with the new key, and ensuring the application regains access to necessary resources.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems have been compromised.
+- Implement enhanced logging policies to capture detailed audit logs for all IAM activities, ensuring that key deletions and other critical actions are monitored in real-time.
+- Integrate with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious IAM activities, including key deletions.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply hardening measures by enforcing strict IAM policies, such as least privilege access, regular key rotation, and multi-factor authentication for sensitive operations.
+- Educate and train staff on security best practices and the importance of monitoring and responding to IAM-related alerts to prevent future incidents.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
index 07b969e6a80..352d205f731 100644
--- a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
+++ b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,50 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Key Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Service Account Key Creation
+
+In GCP, service accounts enable applications to interact with Google APIs securely. They use keys for authentication, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. Malicious actors might create new keys to leverage existing permissions stealthily. The detection rule identifies successful key creation events, signaling potential misuse by monitoring specific audit logs.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.iam.admin.v*.CreateServiceAccountKey`, and `event.outcome:success` to ensure the alert is valid and corresponds to a successful key creation event.
+- Identify the service account associated with the key creation by examining the audit log entry for details such as `serviceAccountId` and `serviceAccountEmail`.
+- Check the `principalEmail` field in the audit log to determine which user or service account initiated the key creation event.
+- Investigate the context of the key creation by reviewing the `timestamp` field to understand when the event occurred and correlate it with any other suspicious activities around the same time.
+- Analyze the `resourceName` field to identify the specific resource or project associated with the service account key creation.
+- Use Osquery to gather additional information about the service account and its permissions. For example, run the following Osquery query to list all service accounts and their associated keys: `SELECT * FROM gcp_service_account_keys WHERE service_account_email = '<serviceAccountEmail>';`.
+- Review the IAM policy for the project or resource to understand the permissions granted to the service account and assess if they align with expected usage.
+- Check for any recent changes in IAM roles or permissions for the service account by reviewing the audit logs for `event.action:google.iam.admin.v*.SetIamPolicy`.
+- Investigate any other recent key creation events for the same service account to determine if there is a pattern or repeated unauthorized activity.
+- Collaborate with the account owner or relevant stakeholders to verify if the key creation was authorized and necessary, and gather any additional context or explanations for the activity.
+
+### False positive analysis
+
+- Routine administrative tasks: Service account keys may be created as part of regular maintenance or deployment processes by authorized personnel. To manage these, users can create exceptions for known administrative activities by correlating key creation events with change management records or deployment logs.
+- Automated processes: Some automated systems or CI/CD pipelines might generate service account keys as part of their normal operation. Users can handle these by identifying and excluding key creation events associated with specific automated workflows or service accounts dedicated to these processes.
+- Testing environments: In development or testing environments, service account keys might be frequently created and deleted. Users can reduce false positives by excluding events from specific projects or environments that are designated for testing purposes.
+- Third-party integrations: Certain third-party tools or integrations may require the creation of service account keys to function correctly. Users should document and exclude these known integrations by maintaining an inventory of approved third-party services and their associated service accounts.
+
+### Response and remediation
+
+- Immediately revoke the newly created service account key to prevent unauthorized access and potential misuse.
+- Investigate the IAM audit logs to identify the user or service that created the key and assess if it was an authorized action.
+- Review the permissions associated with the affected service account to ensure they are aligned with the principle of least privilege.
+- Conduct a thorough review of recent activities performed by the service account to detect any suspicious or unauthorized actions.
+- Escalate the incident to the security operations team if the key creation is deemed unauthorized or malicious, and initiate an incident response process.
+- Implement logging policies to ensure all service account key creation events are logged and monitored in real-time for future detection.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate service account key creation events with other security events for enhanced threat detection.
+- Restore the system to its operational state by ensuring all unauthorized keys are revoked and legitimate keys are securely managed.
+- Harden the environment by enforcing key rotation policies and using Cloud Identity-Aware Proxy (IAP) to limit access to applications.
+- Educate and train relevant personnel on the risks associated with service account key management and the importance of adhering to security best practices.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/persistence_gcp_service_account_created.toml b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
index b929f9b69a2..1cf9858cb6a 100644
--- a/rules/integrations/gcp/persistence_gcp_service_account_created.toml
+++ b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,51 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 GCP Service Account Creation
+
+In GCP, service accounts enable applications and VMs to authenticate and interact with Google services securely. However, adversaries may exploit this by creating unauthorized service accounts to maintain persistence and evade detection. The detection rule monitors audit logs for successful service account creation events, helping identify potential misuse by correlating specific actions and outcomes.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event details, focusing on `event.dataset:gcp.audit` to ensure the event is related to GCP audit logs.
+- Verify the `event.action:google.iam.admin.v*.CreateServiceAccount` to confirm that the action was indeed a service account creation.
+- Check the `event.outcome:success` field to ensure the service account creation was successful.
+- Identify the user or service that initiated the service account creation by examining the `actor` field in the audit logs.
+- Investigate the context of the service account creation by reviewing the `request` and `response` fields in the audit logs for any unusual parameters or configurations.
+- Cross-reference the service account details with known legitimate service accounts to determine if the creation aligns with expected patterns or projects.
+- Use Osquery to gather additional context on the service account creation. For example, run the following query to list recent service account creations: `SELECT * FROM gcp_service_accounts WHERE creation_time > (NOW() - INTERVAL 1 DAY);`
+- Check for any associated IAM policy changes around the time of the service account creation to identify if the new account was granted elevated permissions.
+- Investigate any recent activity associated with the new service account, such as API calls or resource access, to identify potential misuse.
+- Collaborate with the relevant project or application owners to verify if the service account creation was authorized and aligns with current operational needs.
+
+### False positive analysis
+
+- Routine administrative tasks: Service accounts may be created as part of regular administrative operations, such as setting up new applications or services. To manage these, users can create exceptions for known administrative actions by correlating them with change management records or approved workflows.
+- Automated deployment processes: Continuous integration and deployment pipelines might automatically create service accounts. Users can handle these by identifying and excluding service account creation events linked to specific deployment tools or scripts.
+- Third-party integrations: Some third-party services require the creation of service accounts for integration purposes. Users should maintain a list of approved third-party services and exclude related service account creation events from alerts.
+- Testing and development environments: Service accounts are often created in non-production environments for testing purposes. Users can exclude these environments from monitoring or create specific rules that differentiate between production and non-production service account creation events.
+- Frequent legitimate service account creation: In environments with high service account turnover, such as those using microservices architectures, users can establish baseline patterns and exclude events that match these patterns from triggering alerts.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the unauthorized creation of the service account and identify the source of the request.
+- Disable the suspicious service account to prevent further unauthorized access and actions.
+- Investigate the permissions and roles assigned to the service account to assess potential access and impact.
+- Check for any API calls or actions performed by the service account to identify any malicious activities.
+- Escalate the incident to the security operations team for further analysis and to determine if other systems or accounts have been compromised.
+- Implement additional logging and monitoring for service account activities to detect future unauthorized creations or actions.
+- Review and update IAM policies to ensure that only authorized personnel can create and manage service accounts.
+- Conduct a security review of the affected environment to identify and remediate any vulnerabilities that may have been exploited.
+- Restore the system to its operational state by re-enabling legitimate service accounts and ensuring all unauthorized changes are reverted.
+- Educate and train staff on the importance of monitoring and managing service accounts to prevent similar incidents in the future.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
index 9b43b940301..b6dcf20c21c 100644
--- a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
+++ b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -30,6 +30,49 @@ query = '''
 configuration where event.dataset == "github.audit"
   and github.category == "protected_branch" and event.type == "change"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Protected Branch Settings Changed
+
+GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the audit log entry details to identify the user who made the changes to the protected branch settings, focusing on fields like `event.dataset`, `github.category`, and `event.type`.
+- Verify the user's recent activity on GitHub to determine if there are any other suspicious actions or patterns, such as multiple changes to security settings or unusual commit activity.
+- Check the timestamp of the change to see if it aligns with any known maintenance windows or authorized change periods.
+- Cross-reference the user's GitHub activity with internal logs to see if there are any corresponding access logs or anomalies, such as unusual login locations or times.
+- Investigate the specific changes made to the branch protection settings to understand the potential impact on the repository's security posture.
+- Consult with the repository owner or relevant team members to confirm if the changes were authorized and align with current security policies.
+- Use Osquery to gather additional context on the user's machine, such as recent processes or network connections, with a query like: `SELECT * FROM processes WHERE user = 'username' AND start_time > 'timestamp';`
+- Analyze any related pull requests or commits to the affected branch to identify if any unauthorized code changes were made following the settings modification.
+- Review any recent communications or tickets that might provide context or justification for the changes, such as planned feature releases or security audits.
+- Document all findings and observations in a centralized investigation report to facilitate further analysis or handoff to incident response teams if necessary.
+
+### False positive analysis
+
+- Changes made by authorized personnel during routine maintenance or updates can trigger false positives. To manage this, maintain a list of trusted users whose actions are expected and can be excluded from alerts.
+- Automated processes or scripts that update branch protection settings as part of a continuous integration/continuous deployment (CI/CD) pipeline may also cause false positives. Consider creating exceptions for these automated actions by identifying and excluding specific service accounts or IP addresses.
+- Organizational policy changes that require updates to branch protection settings might be flagged. Document these policy changes and adjust the detection rule to recognize them as legitimate.
+- Temporary adjustments to branch protection settings for specific projects or deadlines can be mistaken for unauthorized changes. Implement a process to log and approve these temporary changes, allowing them to be excluded from alerts.
+- Frequent changes by specific teams or projects that have a higher rate of legitimate modifications can be excluded by setting up tailored rules or thresholds for those specific contexts.
+
+### Response and remediation
+
+- Immediately review the audit logs to identify the user who made the changes to the protected branch settings and verify if the change was authorized.
+- Revert any unauthorized changes to the branch protection settings to restore the original security posture.
+- Temporarily restrict access to branch protection settings to a limited number of trusted administrators until the investigation is complete.
+- Conduct a thorough review of recent commits and merges to the affected branches to ensure no unauthorized code changes were introduced.
+- Notify the security team and relevant stakeholders about the incident and provide them with details of the unauthorized changes.
+- If malicious activity is confirmed, initiate a security incident response plan, including isolating affected systems if necessary.
+- Enhance logging and monitoring by integrating GitHub audit logs with a centralized security information and event management (SIEM) system for real-time alerts.
+- Implement additional security measures such as two-factor authentication and stricter access controls for repository settings.
+- Conduct a post-incident review to identify gaps in the current security posture and update policies and procedures accordingly.
+- Educate developers and administrators on the importance of branch protection settings and the potential risks of unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_app_deleted.toml b/rules/integrations/github/execution_github_app_deleted.toml
index 7bced445fa9..54271a2fac6 100644
--- a/rules/integrations/github/execution_github_app_deleted.toml
+++ b/rules/integrations/github/execution_github_app_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -24,6 +24,49 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 App Deleted
+
+GitHub Apps enhance automation and integration within repositories and organizations, facilitating seamless workflows. However, adversaries may exploit this by deleting apps to disrupt services or erase audit trails, potentially executing unauthorized actions. The detection rule monitors audit logs for app deletions, identifying suspicious activities linked to serverless execution tactics, thus safeguarding against such malicious interventions.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the deletion event by checking the `event.dataset` field for "github.audit" and `event.type` for "deletion".
+- Identify the specific GitHub app that was deleted by examining the `github.category` field for "integration_installation".
+- Determine the user or account responsible for the deletion by reviewing the `user.name` and `user.id` fields in the audit logs.
+- Check the timestamp of the deletion event to understand when the action took place and correlate it with other activities in the logs.
+- Investigate the IP address and location associated with the deletion event using the `source.ip` field to identify any unusual access patterns.
+- Review recent changes or activities in the affected repository or organization to assess any potential impact or unauthorized actions.
+- Cross-reference the deletion event with other security alerts or incidents around the same time to identify any related suspicious activities.
+- Use Osquery to gather additional context on the system where the deletion was initiated. Example query: `SELECT * FROM processes WHERE name LIKE '%git%' AND start_time > 'timestamp_of_deletion';`
+- Analyze the permissions and roles of the user who deleted the app to determine if they had the necessary authorization and if any privilege escalation occurred.
+- Consult with the repository or organization owners to verify if the deletion was authorized and gather any additional context or concerns they might have.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may trigger the GitHub App Deleted rule, as legitimate app deletions can occur during these processes.
+- Organizational policy changes or restructuring might lead to the removal of certain GitHub apps, which could be mistakenly flagged as suspicious activity.
+- Users can manage these false positives by creating exceptions for known maintenance periods or authorized personnel actions, ensuring that only unexpected deletions are flagged.
+- Implementing a whitelist of trusted apps and users can help reduce false positives by allowing deletions from these sources without triggering alerts.
+- Regularly reviewing and updating the list of exceptions based on organizational changes can help maintain the accuracy of the detection rule.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the deletion of the GitHub app and identify the user or process responsible for the action.
+- Contain the incident by revoking access tokens and permissions associated with the deleted app to prevent further unauthorized actions.
+- Investigate the scope of the incident by checking for any unauthorized changes or actions performed by the app prior to its deletion.
+- Restore the deleted GitHub app from a backup or reconfigure it to ensure continuity of services and workflows.
+- Escalate the incident to the security team if malicious intent is suspected, providing them with all relevant logs and findings.
+- Implement enhanced logging policies to capture detailed events related to app installations, deletions, and modifications for future investigations.
+- Integrate with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious activities related to GitHub apps.
+- Review and update access controls and permissions for GitHub apps to ensure they follow the principle of least privilege.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate and train users on recognizing and reporting suspicious activities related to GitHub apps to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
index 1d14e096df7..f9c94aee1b3 100644
--- a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
+++ b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,49 @@ event.dataset:"github.audit" and event.category:"configuration" and event.action
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and
 github.repository_public:false
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 High Number of Cloned GitHub Repos From PAT
+
+Personal Access Tokens (PATs) facilitate programmatic access to GitHub repositories, enabling automation and integration. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive data. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific personal access token (PAT) involved in the unusual cloning activity.
+- Cross-reference the PAT with internal records to determine the owner and intended use of the token.
+- Analyze the `event.dataset`, `event.category`, and `event.action` fields to confirm the activity is related to `git.clone` operations on private repositories.
+- Check the `github.programmatic_access_type` field to verify if the access was through an "OAuth access token" or "Fine-grained personal access token" and assess the associated permissions.
+- Investigate the `github.repository_public` field to ensure the cloned repositories are indeed private, confirming the potential sensitivity of the data.
+- Examine the time frame of the cloning activity to understand the duration and frequency of the events, identifying any patterns or anomalies.
+- Use GitHub audit logs to trace back the IP addresses and locations from which the cloning requests originated, looking for any unusual or unauthorized access points.
+- Conduct a review of recent changes or updates to the repositories involved to identify any potential triggers or reasons for the cloning activity.
+- Utilize Osquery to gather additional context from the systems involved. For example, run an Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_of_interest>';` to identify any suspicious connections.
+- Collaborate with the repository owners and relevant stakeholders to gather insights into any recent activities or changes that might explain the cloning events, ensuring a comprehensive understanding of the situation.
+
+### False positive analysis
+
+- **Automated Backup Processes**: Organizations may have automated systems that regularly clone private repositories for backup purposes. These processes can trigger the detection rule due to the high volume of clone events. To manage this, users can create exceptions for known backup systems by identifying their associated PATs and excluding them from the rule.
+- **Continuous Integration/Continuous Deployment (CI/CD) Pipelines**: CI/CD tools often clone repositories to build and test code. If these tools use PATs, they might cause false positives. Users should identify PATs used by trusted CI/CD systems and exclude them from the detection rule to prevent unnecessary alerts.
+- **Development and Testing Activities**: During development sprints or testing phases, developers might clone repositories frequently. This can be mistaken for malicious activity. Users can mitigate this by setting time-based exceptions during known development periods or by excluding PATs associated with specific development teams.
+- **Third-party Integrations**: Some third-party services require access to repositories and may clone them as part of their functionality. Users should review and whitelist PATs used by trusted third-party services to avoid false positives.
+- **High-Volume User Activity**: In large organizations, certain users may have legitimate reasons to clone multiple repositories in a short time. Identifying these users and their associated PATs can help in creating exceptions to reduce false alerts.
+
+### Response and remediation
+
+- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access.
+- Notify the affected repository owners and stakeholders about the potential breach and advise them to review recent changes and access logs.
+- Conduct a thorough investigation to identify the source of the compromise, including reviewing access logs and identifying any unauthorized changes or data exfiltration.
+- Escalate the incident to the security team and, if necessary, involve legal and compliance teams to assess the impact and regulatory obligations.
+- Implement additional monitoring and alerting for unusual access patterns or cloning activities across all repositories.
+- Review and update access controls, ensuring that PATs are issued with the least privilege necessary and have expiration dates.
+- Educate users on secure handling of PATs, including avoiding hardcoding them in scripts and using environment variables instead.
+- Enhance logging policies to capture detailed access and activity logs, integrating them with a centralized security information and event management (SIEM) system for better analysis.
+- Consider implementing multi-factor authentication (MFA) for accessing sensitive repositories to add an additional layer of security.
+- Restore any affected systems or repositories to their last known good state, ensuring that any unauthorized changes are reverted and data integrity is maintained."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
index aeefde947c4..463e2f42185 100644
--- a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
+++ b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/14"
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,48 @@ type = "threshold"
 query = '''
 signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 UEBA - Multiple Alerts from a GitHub Account
+
+User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify unusual patterns that may indicate compromised accounts. Adversaries might exploit GitHub by executing multiple unauthorized actions within a short period, such as using stolen credentials or personal access tokens (PATs). The detection rule flags accounts with multiple alerts in an hour, signaling potential misuse and enabling analysts to prioritize investigation and response.
+
+### Possible investigation steps
+
+- Review the alert details in the security information and event management (SIEM) system, focusing on the `signal.rule.tags` field to confirm the alert is related to GitHub UEBA and involves multiple alerts from the same account.
+- Check the `kibana.alert.workflow_status` field to ensure the alert is still open and requires investigation.
+- Identify the specific GitHub account associated with the alert and gather historical activity logs for this account to establish a baseline of normal behavior.
+- Analyze the timestamps of the alerts to determine the exact time window of the suspicious activity and correlate it with any known events or changes in the environment.
+- Investigate the types of actions or events that triggered the alerts to understand the nature of the potential compromise, such as unauthorized repository access or unusual API calls.
+- Use Osquery to gather additional context on the system or environment where the suspicious activity originated. For example, run an Osquery query to list recent GitHub API calls made from the system: `SELECT * FROM curl WHERE url LIKE '%github.com%' AND time > strftime('%s', 'now', '-1 hour');`
+- Cross-reference the GitHub account activity with other security logs, such as network or endpoint logs, to identify any related suspicious behavior or anomalies.
+- Check for any recent changes to the account's permissions or settings that could indicate unauthorized access or privilege escalation.
+- Investigate any associated IP addresses or geolocations involved in the alerts to determine if they are consistent with the user's typical access patterns or if they suggest a potential threat actor.
+- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation and facilitate further analysis if needed.
+
+### False positive analysis
+
+- Frequent legitimate activities by automated scripts or CI/CD pipelines can trigger multiple alerts within a short period, leading to false positives. Users should identify and document these scripts or pipelines to differentiate them from potential threats.
+- Developers or teams working on high-intensity projects may generate numerous alerts due to rapid code pushes or repository interactions. Establishing a baseline of normal activity for these users can help in distinguishing between expected behavior and potential threats.
+- Scheduled tasks or maintenance activities that involve multiple repository interactions can also result in false positives. Users can create exceptions for these known activities by setting specific time windows or user accounts that are exempt from triggering alerts.
+- Collaborations with external partners or contributors who have legitimate access to repositories might cause multiple alerts if their activity patterns differ from internal users. Regularly reviewing and updating access permissions and documenting expected behaviors can help manage these false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected GitHub account by revoking access tokens and changing passwords to prevent further unauthorized actions.
+- Conduct a thorough investigation to identify the scope of the compromise, including reviewing recent activity logs and identifying any unauthorized changes or data exfiltration.
+- Utilize GitHub's audit logs and integrate with SIEM tools to enhance visibility and trace the adversary's actions within the environment.
+- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if sensitive data has been accessed or modified.
+- Remediate any unauthorized changes by reverting code or configuration changes and ensuring that no malicious code remains in the repositories.
+- Implement additional security measures such as enabling two-factor authentication (2FA) for all users and enforcing strong password policies.
+- Enhance logging and monitoring by integrating GitHub with centralized logging solutions to ensure comprehensive visibility of user activities and potential threats.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent future incidents.
+- Consider implementing automated alerting and response mechanisms to quickly detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_new_github_app_installed.toml b/rules/integrations/github/execution_new_github_app_installed.toml
index 10754ac939c..5512b4145ee 100644
--- a/rules/integrations/github/execution_new_github_app_installed.toml
+++ b/rules/integrations/github/execution_new_github_app_installed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -30,6 +30,49 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "integration_installation.create"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 New GitHub App Installed
+
+GitHub Apps enhance functionality by integrating with repositories and organizations, often requiring permissions to access or modify data. Adversaries may exploit this by installing malicious apps to gain unauthorized access or control. The detection rule monitors audit logs for new app installations, flagging potential threats by identifying unauthorized or suspicious integrations.
+
+### Possible investigation steps
+
+- Review the audit logs to identify the specific GitHub App that was installed by examining the `event.action` field for "integration_installation.create".
+- Check the `user.name` field in the audit logs to determine who installed the app and verify if they have the appropriate permissions and role to do so.
+- Investigate the `github.app.name` field to gather more information about the app, including its purpose and the permissions it requests.
+- Cross-reference the app's permissions with your organization's security policies to ensure they align and do not pose a risk.
+- Look into the app's developer or vendor by researching the `github.app.owner` field to assess their reputation and trustworthiness.
+- Use Osquery to query the local system for any related processes or network connections initiated by the app. Example query: `SELECT * FROM processes WHERE name LIKE '%github%' OR path LIKE '%github%'`.
+- Check for any recent changes in the repositories or organization settings that could be linked to the app installation by reviewing the `event.dataset` field for related activities.
+- Analyze the `event.created` timestamp to determine if the app installation coincides with any other suspicious activities or alerts.
+- Consult with the team or individual who installed the app to understand the rationale behind its installation and verify its necessity.
+- Document all findings and context gathered during the investigation to aid in future reference and potential incident response activities.
+
+### False positive analysis
+
+- Known false positives for the New GitHub App Installed rule may include legitimate apps installed by trusted team members or automated processes that are part of regular operations. These installations might be flagged if they occur frequently or during unusual hours.
+- To manage these false positives, users can create exceptions for specific apps that are regularly installed and verified as safe. This can be done by maintaining a whitelist of trusted apps and updating it as necessary.
+- Another approach is to monitor the installation patterns and identify any recurring non-threatening behaviors, such as installations by specific users or teams, and exclude these from triggering alerts.
+- Users should also consider the context of the installation, such as whether it aligns with ongoing projects or initiatives, to determine if an alert is a false positive.
+- Implementing a review process for app installations can help in quickly identifying and excluding false positives, ensuring that only genuine threats are flagged for further investigation.
+
+### Response and remediation
+
+- Immediately review the permissions requested by the newly installed GitHub App to assess potential risks and determine if they align with organizational policies.
+- Verify the legitimacy of the app by checking its developer's reputation, user reviews, and any available security assessments.
+- Temporarily disable or uninstall the app if it is deemed suspicious or unauthorized to prevent further access or data modification.
+- Conduct a thorough audit of recent activities in the affected repositories and organization to identify any unauthorized changes or data access.
+- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Escalate the issue to GitHub support if the app is confirmed to be malicious or if there is a need for further assistance in handling the incident.
+- Implement logging policies to capture detailed audit logs of app installations and other critical actions for future investigations.
+- Integrate security tools that can automatically monitor and alert on suspicious activities related to GitHub Apps and other integrations.
+- Restore any affected systems or repositories to their last known good state if unauthorized changes were detected.
+- Review and update organizational policies on app installations, ensuring only trusted and verified apps are allowed, and educate team members on the importance of scrutinizing app permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/impact_github_repository_deleted.toml b/rules/integrations/github/impact_github_repository_deleted.toml
index da383c6b1d6..1bcb8ec593e 100644
--- a/rules/integrations/github/impact_github_repository_deleted.toml
+++ b/rules/integrations/github/impact_github_repository_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,48 @@ type = "eql"
 query = '''
 configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Repository Deleted
+
+GitHub repositories are vital for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase evidence of unauthorized access, leading to data loss. The detection rule monitors GitHub audit logs for repository deletion events, flagging potential unauthorized actions for further investigation.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to confirm the repository deletion event by checking the `event.action` field for "repo.destroy".
+- Identify the user associated with the deletion by examining the `actor` field in the audit logs to determine if the action was performed by an authorized individual.
+- Check the `repository.name` field to understand which repository was deleted and assess its importance and sensitivity to the organization.
+- Investigate the `event.created` timestamp to establish the exact time of the deletion and correlate it with other activities or anomalies in the system.
+- Analyze the `actor.ip` field to verify the IP address from which the deletion was initiated and determine if it matches known IP addresses associated with the user.
+- Use Osquery to gather additional context on the user's recent activities. For example, run the following query to list recent GitHub actions by the same user: `SELECT * FROM github_events WHERE actor = '<actor_name>' ORDER BY created_at DESC LIMIT 10;`.
+- Cross-reference the deletion event with recent access logs to see if there were any unusual login attempts or access patterns around the time of the deletion.
+- Check for any recent changes in user permissions or roles that might have inadvertently allowed unauthorized access to delete the repository.
+- Review any recent communications or tickets related to the repository to determine if there was a legitimate reason for its deletion.
+- Consult with the repository's owner or key stakeholders to verify if the deletion was planned or if they have any insights into the event.
+
+### False positive analysis
+
+- Routine maintenance or cleanup activities by authorized personnel can trigger false positives when repositories are intentionally deleted as part of organizational housekeeping. Users can manage these by creating exceptions for known maintenance periods or specific user accounts responsible for such tasks.
+- Automated scripts or bots that manage repository lifecycles might delete repositories as part of their normal operation. To handle these, users can exclude actions performed by these scripts by identifying their unique user agents or tokens in the audit logs.
+- Deletion of test or temporary repositories that are frequently created and removed during development cycles can also result in false positives. Users can mitigate this by setting up filters to ignore deletions of repositories with specific naming conventions or tags that indicate their temporary nature.
+- Organizational restructuring or project completion may lead to legitimate repository deletions. Users should ensure that such actions are documented and communicated within the team, allowing for the creation of temporary exceptions during these periods.
+
+### Response and remediation
+
+- Immediately contain the incident by revoking access to the affected GitHub account and any associated API tokens to prevent further unauthorized actions.
+- Investigate the audit logs to identify the user or process responsible for the deletion and determine if it was an authorized action or a potential compromise.
+- If unauthorized access is confirmed, conduct a thorough review of all access logs and permissions to identify other potential security breaches or compromised accounts.
+- Restore the deleted repository from backups, if available, to minimize operational disruption and data loss.
+- Escalate the incident to the security team and relevant stakeholders, providing them with detailed findings and any indicators of compromise.
+- Implement enhanced logging and monitoring policies to capture detailed audit trails of all repository actions, ensuring future incidents can be detected and investigated promptly.
+- Integrate GitHub with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious activities.
+- Review and update access controls and permissions for all GitHub repositories to ensure the principle of least privilege is enforced.
+- Conduct a security awareness training session for all users to reinforce the importance of secure practices and recognizing potential phishing or social engineering attacks.
+- Regularly test and update the incident response plan to ensure readiness for future incidents, incorporating lessons learned from this event."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/persistence_github_org_owner_added.toml b/rules/integrations/github/persistence_github_org_owner_added.toml
index 3046b5e72be..68721c60a9b 100644
--- a/rules/integrations/github/persistence_github_org_owner_added.toml
+++ b/rules/integrations/github/persistence_github_org_owner_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,48 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 New GitHub Owner Added
+
+GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the audit log entry details to confirm the event action is "org.add_member" and the permission level is "admin" to ensure the alert is valid.
+- Identify the user account that was added as an owner by examining the relevant fields in the audit log, such as `github.actor` and `github.target_user`.
+- Verify the identity and role of the user added as an owner by cross-referencing with internal HR or user management systems to determine if the addition was authorized.
+- Check the timestamp of the event to understand when the new owner was added and correlate this with any other suspicious activities around the same time.
+- Investigate the IP address and location from which the action was performed using the `source.ip` field to identify any anomalies or unexpected access patterns.
+- Review recent activity by the new owner account in the GitHub organization to identify any unauthorized changes or access to sensitive repositories.
+- Use Osquery to gather additional context on the system from which the action was performed. For example, run the following query to check for recent logins: `SELECT * FROM last WHERE username = '<new_owner_username>';`
+- Examine any recent changes to the organization's settings or repositories that could indicate malicious intent or unauthorized access.
+- Check for any other recent additions or changes to the organization's membership, especially those with elevated permissions, to identify potential patterns of compromise.
+- Collaborate with the organization's security team to gather additional context or insights from other security tools and logs that might indicate a broader security incident.
+
+### False positive analysis
+
+- Routine administrative actions: In some organizations, adding new owners may be a regular part of onboarding or restructuring processes. To manage this, users can create exceptions for specific accounts or time periods when these actions are expected.
+- Automated processes: Some organizations use automation tools that may add or modify owner roles as part of their workflow. Users should identify these tools and exclude their actions from triggering alerts by filtering based on known service accounts or automation identifiers.
+- Internal audits or security reviews: During internal audits or security reviews, additional owner roles might be temporarily assigned. Users can handle these by coordinating with the audit team and setting temporary exceptions for the duration of the review.
+- Organizational changes: Mergers, acquisitions, or departmental changes might necessitate the addition of new owners. Users should document these changes and adjust the detection rule to exclude known, legitimate changes during these periods.
+
+### Response and remediation
+
+- Immediately revoke the newly added owner's permissions to prevent further unauthorized access.
+- Conduct a thorough investigation to determine how the unauthorized addition occurred, reviewing audit logs and access patterns.
+- Verify the legitimacy of the new owner with the organization's management and confirm if the addition was intentional.
+- If a compromise is confirmed, reset credentials and review access permissions for all critical accounts within the organization.
+- Escalate the incident to the security team and relevant stakeholders to ensure awareness and coordinated response efforts.
+- Implement enhanced logging policies to capture detailed audit trails of administrative actions within the GitHub organization.
+- Integrate GitHub audit logs with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
+- Educate team members on security best practices and the importance of monitoring for unauthorized access attempts.
+- Review and update the organization's incident response plan to include specific procedures for handling GitHub-related security incidents.
+- Apply hardening measures such as enabling two-factor authentication for all users and regularly reviewing and updating access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/persistence_organization_owner_role_granted.toml b/rules/integrations/github/persistence_organization_owner_role_granted.toml
index fae3507ce48..0e36f6948e0 100644
--- a/rules/integrations/github/persistence_organization_owner_role_granted.toml
+++ b/rules/integrations/github/persistence_organization_owner_role_granted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,50 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Owner Role Granted To User
+
+In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating their privileges to maintain persistence or exfiltrate sensitive information. The detection rule identifies suspicious privilege escalations by monitoring audit logs for changes in member roles to 'admin', signaling potential unauthorized access.
+
+### Possible investigation steps
+
+- Review the audit log entry to confirm the event details, focusing on the `event.dataset`, `event.action`, and `github.permission` fields to ensure the alert is valid and corresponds to a role change to 'admin'.
+- Identify the user who was granted the owner role by examining the `user.name` and `user.id` fields in the audit log entry.
+- Determine the initiator of the role change by checking the `actor.name` and `actor.id` fields to see if the change was made by an authorized individual.
+- Cross-reference the timestamp of the event with other logs to identify any concurrent suspicious activities, such as failed login attempts or unusual repository access.
+- Check the user's recent activity in the organization to identify any anomalies or actions that could indicate malicious intent.
+- Investigate the user's account history for any previous suspicious activities or privilege escalations.
+- Use Osquery to gather additional context on the user's machine, such as running the query: `SELECT * FROM processes WHERE user = '<user.name>';` to identify any unusual processes or connections.
+- Review the organization's member list and permissions to ensure no other unauthorized changes have been made.
+- Consult with the organization's administrators to verify if the role change was expected or authorized.
+- Document all findings and observations to provide a comprehensive overview of the investigation for further analysis or escalation if needed.
+
+### False positive analysis
+
+- Legitimate role changes: In some organizations, it is common for certain users to be granted the owner role temporarily for administrative tasks. These changes can be considered false positives if they are part of regular operations.
+- Automated processes: Some organizations use automated scripts or bots to manage user roles, which might trigger the detection rule. These should be reviewed to ensure they are authorized and documented.
+- Organizational restructuring: During periods of restructuring or mergers, role changes might occur frequently and could be mistaken for unauthorized access.
+- To manage these false positives, users can create exceptions for known and documented role changes by maintaining a list of authorized personnel who can be granted the owner role.
+- Implementing a review process for role changes can help in quickly identifying and excluding non-threatening behaviors from triggering alerts.
+- Regularly update and audit the list of exceptions to ensure it reflects current organizational policies and personnel changes.
+
+### Response and remediation
+
+- Immediately revoke the unauthorized owner role to prevent further access and potential damage.
+- Conduct a thorough investigation to determine how the privilege escalation occurred, reviewing audit logs and access patterns.
+- Verify the integrity of critical repositories and settings to ensure no unauthorized changes have been made.
+- Notify the security team and relevant stakeholders about the incident for awareness and further action.
+- Escalate the incident to higher management if the breach is confirmed to be part of a larger attack or if sensitive data has been compromised.
+- Implement additional logging and monitoring to capture detailed access and modification events for future investigations.
+- Integrate with security information and event management (SIEM) systems to enhance real-time detection and response capabilities.
+- Review and update access control policies to enforce the principle of least privilege and reduce the risk of future privilege escalations.
+- Conduct a security awareness session for organization members to educate them on recognizing and reporting suspicious activities.
+- Apply hardening measures such as enabling two-factor authentication for all users and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
index 5af838db9fc..1b31a35f4b7 100644
--- a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
+++ b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/21"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,51 @@ interval = "10m"
 language = "eql"
 license = "Elastic License v2"
 name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
+
+Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If these keys are shared via links without proper restrictions, they can be accessed by unauthorized users. Adversaries exploit this by using rogue links to obtain keys, potentially compromising data security. The detection rule identifies suspicious activities by monitoring anonymous access to key files, focusing on actions like viewing or downloading, and flags files with specific extensions indicative of encryption keys.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file extension matches those indicative of encryption keys, as specified in the query (e.g., "pem", "key", "pfx").
+- Verify the event.action field to determine the specific action taken (e.g., "view", "copy", "download") and assess the potential impact of the action.
+- Check the google_workspace.drive.visibility field to confirm that the file was shared with "people_with_link", indicating it was accessible to anyone with the link.
+- Investigate the source.user.email field to ensure it is empty, confirming the access was anonymous.
+- Cross-reference the file name and path with internal records to identify the owner and intended access permissions of the file.
+- Use Google Workspace audit logs to trace any recent changes to the file's sharing settings or access permissions.
+- Conduct a search for other files with similar extensions in the same Google Workspace Drive to assess if there are additional files at risk.
+- Utilize Osquery to gather more context on the file access. Example query: `SELECT * FROM google_drive_files WHERE visibility = 'people_with_link' AND extension IN ('pem', 'key', 'pfx') AND user_email = '';`
+- Analyze historical access patterns to the file to identify any previous unauthorized access attempts or changes in access patterns.
+- Collaborate with the file owner to understand the necessity of the current sharing settings and gather insights into any recent activities that might have led to the exposure.
+
+### False positive analysis
+
+- **Shared Team Resources**: Files containing encryption keys might be shared among team members using links for collaborative purposes. If these links are accessed by team members who are not logged into their Google accounts, it could trigger a false positive. To manage this, ensure that team members are logged in when accessing shared resources or create exceptions for specific shared links known to be safe.
+- **Automated System Access**: Some systems or scripts may access encryption key files using anonymous links for automated processes. These accesses can be mistaken for unauthorized activity. To handle this, document and whitelist known automated processes that require such access.
+- **Third-party Integrations**: Certain third-party applications may require access to encryption keys stored in Google Workspace Drive. If these applications use anonymous links, they might be flagged as suspicious. Users should verify and whitelist trusted third-party applications that need access to these files.
+- **Testing and Development**: During testing or development phases, encryption keys might be shared via links for convenience. These activities can be misinterpreted as malicious. To mitigate this, establish a separate environment for testing and development with its own set of rules or exceptions.
+- **Expired Employee Access**: Former employees might still have access to shared links if not properly revoked. This can lead to false positives if they access files anonymously. Regularly audit and update access permissions to prevent this issue.
+
+### Response and remediation
+
+- Immediately revoke access to the shared link for the identified encryption key file to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the extent of the exposure, including identifying any other files accessed by the anonymous user and reviewing access logs for suspicious activities.
+- Notify the affected parties and stakeholders about the potential data breach and the steps being taken to mitigate the risk.
+- Change the encryption keys that were accessed and update any systems or services that rely on these keys to prevent unauthorized access.
+- Implement access controls to ensure that sensitive files, such as encryption keys, are only shared with specific users and not via public links.
+- Enable detailed logging and monitoring for Google Workspace activities to detect and respond to similar incidents in the future.
+- Integrate Google Workspace with a Security Information and Event Management (SIEM) system to enhance threat detection and response capabilities.
+- Review and update the organization's data sharing policies to include guidelines on securely sharing sensitive information.
+- Conduct a security awareness training session for employees to educate them on the risks of sharing sensitive files via public links and best practices for data protection.
+- Consider implementing additional security measures such as Data Loss Prevention (DLP) tools to automatically detect and prevent the sharing of sensitive information.
+
+## Setup
 
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
index 35730889fc6..b601bd9acf5 100644
--- a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
+++ b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/30"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,52 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "First Time Seen Google Workspace OAuth Login from Third-Party Application"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Time Seen Google Workspace OAuth Login from Third-Party Application
+
+OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access and privileges. The detection rule identifies unusual OAuth logins by monitoring first-time authorizations from third-party apps, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific third-party application involved by examining the `google_workspace.token.client.id` field.
+- Verify the legitimacy of the third-party application by researching the client ID and checking if it is a known or trusted application.
+- Check the `google_workspace.token.scope.data` field to understand the permissions and data access requested by the application, assessing if they align with expected usage.
+- Investigate the user account associated with the OAuth login to determine if the login aligns with their typical behavior or if it appears suspicious.
+- Examine historical login patterns for the user to identify any anomalies or deviations from their normal activity.
+- Use Osquery to gather additional context on the user's device, such as running processes or network connections, with a query like: `SELECT * FROM processes WHERE user = '<username>';`.
+- Cross-reference the event timestamp with other security logs to identify any concurrent suspicious activities or anomalies.
+- Check for any recent changes in user permissions or roles that might have been exploited by the third-party application.
+- Investigate if there have been any recent phishing attempts or credential leaks that could have compromised the user's credentials.
+- Collaborate with the user to confirm whether they authorized the application and if they recognize the activity as legitimate.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate third-party applications are authorized for the first time by users, such as productivity tools or integrations that enhance Google Workspace functionality.
+- Users can handle these false positives by creating exceptions for applications that are frequently used and verified as safe, ensuring they do not trigger alerts in the future.
+- Regularly review and update the list of trusted applications to include new tools that are widely adopted within the organization, reducing unnecessary alerts.
+- Implement a process for users to report and verify new applications they intend to use, allowing security teams to pre-approve these applications and prevent false positives.
+- Consider the context of the OAuth login, such as the time, location, and user behavior, to differentiate between legitimate and potentially malicious activities.
+- Use historical data to identify patterns of legitimate OAuth logins, which can help refine detection rules and minimize false positives.
+
+### Response and remediation
+
+- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access.
+- Conduct a thorough investigation to determine if any sensitive data was accessed or modified by the third-party application.
+- Review the permissions granted to the third-party application and assess whether they align with the principle of least privilege.
+- Notify affected users and relevant stakeholders about the potential security incident and provide guidance on monitoring for unusual activity.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems are compromised.
+- Implement enhanced logging and monitoring for OAuth activities in Google Workspace to detect similar incidents in the future.
+- Integrate threat intelligence feeds to correlate OAuth activity with known malicious indicators and improve detection capabilities.
+- Restore any affected systems or data to their last known good state, ensuring that any unauthorized changes are reversed.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Educate users on the risks associated with third-party applications and the importance of scrutinizing permissions before granting access.
+
+## Setup
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 ### Important Information Regarding Google Workspace Event Lag Times
 - As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
diff --git a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
index a1022b5fa15..30372f2c3e2 100644
--- a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
+++ b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,50 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Google Workspace Suspended User Account Renewed"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Google Workspace Suspended User Account Renewed
+
+Google Workspace allows administrators to manage user accounts, including suspending and unsuspending them. Adversaries may exploit this by unsuspending accounts to regain access to an organization. The detection rule monitors for unsuspension actions within the IAM category, alerting analysts to potential unauthorized access attempts by identifying when a suspended account is reactivated.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.dataset is "google_workspace.admin" and the event.category is "iam" with the event.action "UNSUSPEND_USER" to ensure the alert is valid.
+- Identify the user account that was unsuspended by examining the specific user details in the alert, such as user.email or user.name.
+- Check the timestamp of the unsuspension event to determine when the action occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the actor responsible for the unsuspension by reviewing the admin.email or admin.name fields to determine if the action was performed by an authorized administrator.
+- Analyze the user's account history to identify any previous suspicious activities or patterns that might indicate compromise.
+- Use Google Workspace audit logs to search for any other recent administrative actions performed by the same actor to identify potential patterns of unauthorized access.
+- Cross-reference the unsuspended user account with recent login activity to determine if there have been any successful logins post-unsuspension, especially from unusual locations or devices.
+- Utilize Osquery to gather additional context on the unsuspended account by running a query such as: `SELECT * FROM google_workspace_users WHERE email = 'user@example.com';` to retrieve detailed user information and status.
+- Investigate any recent changes to the organization's IAM policies or permissions that might have allowed unauthorized unsuspension actions.
+- Collaborate with the IT or security team to review any recent changes in administrative roles or permissions that could have inadvertently allowed unauthorized access to user management functions.
+
+### False positive analysis
+
+- Routine administrative actions: Legitimate IT administrators may unsuspend user accounts as part of regular account management tasks, such as when an employee returns from leave. To manage these, organizations can create exceptions for known administrative actions by whitelisting specific administrator accounts or IP addresses.
+- Automated processes: Some organizations may have automated workflows that unsuspend accounts based on predefined criteria, such as a scheduled return date for employees. These processes can be excluded from alerts by identifying and excluding the specific automated system accounts or scripts involved.
+- User error: Occasionally, an account may be unsuspended by mistake due to human error. To handle these, organizations can implement a review process for unsuspension actions, ensuring that any unsuspension is verified by a second administrator before being excluded from alerts.
+- Third-party integrations: Certain third-party applications integrated with Google Workspace may have permissions to unsuspend accounts as part of their functionality. To address this, organizations should review and document all third-party applications with such permissions and exclude their actions from alerts if deemed non-threatening.
+
+### Response and remediation
+
+- Immediately suspend the reactivated user account to prevent further unauthorized access.
+- Review audit logs to identify who performed the unsuspension action and assess if it was authorized.
+- Investigate any recent activities associated with the reactivated account to determine if any sensitive data was accessed or modified.
+- Change passwords and enforce multi-factor authentication for the affected account and any other accounts accessed by the adversary.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems were compromised.
+- Implement stricter access controls and review permissions for user accounts to minimize the risk of unauthorized actions.
+- Enhance logging policies to ensure detailed tracking of account management activities, including suspensions and unsuspensions.
+- Integrate Google Workspace with a Security Information and Event Management (SIEM) system to improve real-time monitoring and alerting capabilities.
+- Conduct a security awareness training session for administrators to reinforce the importance of account management best practices.
+- Review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
+
+## Setup
 
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
index 50e54311ef7..40bdc6e19c0 100644
--- a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
+++ b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,53 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Denied Service Account Request"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Denied Service Account Request
+
+Kubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow a consistent access pattern. However, adversaries can exploit compromised credentials to make unauthorized API requests, aiming to discover or manipulate resources. The detection rule identifies such anomalies by flagging denied requests from service accounts, indicating potential misuse or compromise.
+
+### Possible investigation steps
+
+- Review the specific audit log entry that triggered the alert, focusing on the `event.dataset` field to confirm it is from "kubernetes.audit_logs".
+- Identify the service account involved by examining the `kubernetes.audit.user.username` field to determine which service account made the unauthorized request.
+- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm the request was indeed "forbid" and not a false positive.
+- Investigate the source IP and user agent from the audit logs to determine where the request originated from and what tool or application was used.
+- Cross-reference the service account with known deployments and pods to understand its typical usage and permissions.
+- Use Osquery to list all pods and their associated service accounts to verify if the service account is being used by unexpected or unauthorized pods:
+  ```sql
+  SELECT name, namespace, service_account_name FROM kubernetes_pods WHERE service_account_name = '<compromised_service_account>';
+  ```
+- Examine recent changes or deployments in the cluster that might have affected the service account's permissions or behavior.
+- Review the cluster's RoleBindings and ClusterRoleBindings to ensure the service account's permissions have not been altered unexpectedly.
+- Check for any recent access or modification to the service account's secrets or tokens that could indicate credential compromise.
+- Analyze historical audit logs for any patterns of similar unauthorized requests from the same or different service accounts to identify potential broader issues.
+
+### False positive analysis
+
+- Service accounts used in automated testing or development environments may generate denied requests as part of their normal operation, leading to false positives. Users can handle these by creating exceptions for specific service accounts known to exhibit this behavior.
+- Misconfigured service accounts that lack necessary permissions might trigger the rule. Regular audits and proper configuration management can help identify and rectify these issues, reducing false positives.
+- Service accounts involved in legitimate but unusual operations, such as temporary maintenance tasks, might be flagged. Users should document these operations and adjust the detection rule to exclude these specific activities.
+- In some cases, service accounts might be involved in legitimate access attempts that are denied due to temporary network issues or API server misconfigurations. Monitoring network stability and ensuring API server configurations are correct can help mitigate these occurrences.
+
+### Response and remediation
+
+- Immediately isolate the affected service account by revoking its credentials or tokens to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the compromise, including reviewing audit logs for any other suspicious activities associated with the service account.
+- Identify and analyze the source of the unauthorized request to understand how the adversary gained access, focusing on potential vulnerabilities or misconfigurations in the cluster.
+- Escalate the incident to the security operations team and relevant stakeholders to ensure awareness and coordinated response efforts.
+- Implement enhanced logging policies to capture detailed audit logs for all service account activities, ensuring that future unauthorized access attempts are detected promptly.
+- Integrate security tools and platforms, such as SIEM systems, to automate the detection and alerting of anomalous service account behaviors.
+- Restore the system to its operational state by reissuing new credentials or tokens for the affected service account and ensuring all unauthorized changes are reverted.
+- Apply hardening measures by enforcing the principle of least privilege for service accounts, ensuring they have only the necessary permissions to perform their functions.
+- Conduct a post-incident review to identify lessons learned and update incident response plans and security policies accordingly.
+- Leverage MITRE ATT&CK framework to understand potential adversary tactics and techniques, enhancing threat detection and response capabilities for future incidents.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
index d0589a903d9..c2ef47bed53 100644
--- a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
+++ b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/30"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Suspicious Self-Subject Review"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Suspicious Self-Subject Review
+
+Kubernetes uses Self-Subject Access Review APIs to allow entities to check their own permissions, a feature typically unnecessary for service accounts or nodes. Adversaries exploiting compromised credentials might use these APIs to assess their access rights, aiding lateral movement or privilege escalation. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific service account or node involved by examining the `kubernetes.audit.user.username` or `kubernetes.audit.impersonatedUser.username` fields.
+- Check the `kubernetes.audit.objectRef.resource` field to confirm whether the API call was for `selfsubjectaccessreviews` or `selfsubjectrulesreviews`.
+- Investigate the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the request was indeed allowed, indicating a successful permission check.
+- Analyze the `kubernetes.audit.verb` field to verify that the action was a `create` operation, which is necessary for initiating a self-subject review.
+- Correlate the timestamp of the alert with other logs to identify any preceding or subsequent suspicious activities involving the same service account or node.
+- Use Osquery to gather additional context about the node or pod from which the request originated. Example query: `SELECT * FROM kubernetes_pods WHERE name = '<pod_name>' AND namespace = '<namespace>';`
+- Examine the Kubernetes RBAC (Role-Based Access Control) settings to determine the permissions associated with the service account or node in question.
+- Investigate any recent changes to the service account or node's permissions or roles that might explain the unusual behavior.
+- Check for any known vulnerabilities or security advisories related to Kubernetes that might be relevant to the observed behavior.
+- Review historical logs to determine if similar self-subject review requests have been made by the same or other service accounts or nodes, indicating a pattern of behavior.
+
+### False positive analysis
+
+- Service accounts or nodes that are part of automated processes or CI/CD pipelines might legitimately use self-subject access review APIs to verify permissions before executing tasks. These should be reviewed and, if deemed non-threatening, can be excluded from the rule by adding exceptions for specific service accounts or node identities.
+- Monitoring or security tools that integrate with Kubernetes may perform self-subject access reviews as part of their normal operation to ensure they have the necessary permissions to function correctly. Identifying these tools and excluding their service accounts from the rule can reduce false positives.
+- During cluster setup or maintenance, administrators might temporarily use service accounts or nodes to verify permissions, which could trigger the rule. Documenting these activities and excluding the relevant accounts during these periods can help manage false positives.
+- In environments where role-based access control (RBAC) policies are frequently updated, service accounts might perform self-subject access reviews to adapt to new permissions. Regularly reviewing and updating the list of exceptions to include these accounts can help maintain the balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected service account or node to prevent further unauthorized access or lateral movement within the cluster.
+- Review Kubernetes audit logs to identify any other suspicious activities or API calls made by the compromised identity.
+- Revoke and rotate credentials or tokens associated with the compromised service account or node to prevent further misuse.
+- Conduct a thorough investigation to determine how the credentials were compromised and assess the extent of the breach.
+- Escalate the incident to the security operations team and involve relevant stakeholders to ensure a coordinated response.
+- Implement enhanced logging and monitoring for Kubernetes audit logs to detect similar suspicious activities in the future.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate Kubernetes events with other security data for comprehensive threat detection.
+- Apply Kubernetes Role-Based Access Control (RBAC) policies to limit permissions for service accounts and nodes, adhering to the principle of least privilege.
+- Restore the system to its operational state by verifying the integrity of the cluster and ensuring no unauthorized changes were made.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future resilience against similar threats.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
index 1c134a8e0b8..76b83a7372f 100644
--- a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
+++ b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/17"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,50 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes User Exec into Pod"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes User Exec into Pod
+
+Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating debugging and management. However, adversaries can exploit this to gain unauthorized shell access, potentially exposing sensitive data. The detection rule identifies such attempts by monitoring audit logs for specific actions, ensuring any unauthorized access is promptly flagged for investigation.
+
+### Possible investigation steps
+
+- Review the audit log entry to confirm the 'exec' command was used by checking the `kubernetes.audit.objectRef.subresource` field for "exec".
+- Verify the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was indeed allowed, indicating a successful execution attempt.
+- Identify the user or service account responsible for the action by examining the `kubernetes.audit.user.username` field.
+- Determine the source IP address of the request using the `kubernetes.audit.sourceIPs` field to assess if it originates from a known or suspicious location.
+- Check the `kubernetes.audit.objectRef.name` field to identify the specific pod targeted by the exec command.
+- Investigate the `kubernetes.audit.verb` field to confirm the action was a "create" operation, indicating a new exec session was initiated.
+- Use Osquery to gather more context about the pod by running a query such as: `SELECT * FROM kubernetes_pods WHERE name = '<pod_name>';` replacing `<pod_name>` with the value from `kubernetes.audit.objectRef.name`.
+- Examine the `kubernetes.audit.metadata.creationTimestamp` to establish a timeline and correlate with other events or alerts.
+- Review the pod's role and permissions to understand the potential impact of unauthorized access, focusing on any secrets or sensitive data it may have access to.
+- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular maintenance or debugging activities by authorized personnel can trigger this rule. To manage this, create exceptions for known administrative accounts or specific namespaces where such activities are expected.
+- Automated scripts: Some automated processes or CI/CD pipelines may use the 'exec' command for legitimate purposes. Identify these scripts and exclude their associated service accounts or IP addresses from triggering alerts.
+- Monitoring and logging tools: Certain monitoring or logging solutions may use 'exec' to gather metrics or logs from pods. Whitelist these tools by their service accounts or specific pod labels to prevent false positives.
+- Development environments: In development or testing environments, developers may frequently use 'exec' for testing purposes. Consider excluding these environments by namespace or label to reduce noise in alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further unauthorized access and data exposure.
+- Review Kubernetes audit logs to identify the source of the unauthorized 'exec' command and determine the scope of the breach.
+- Revoke any compromised credentials and access tokens associated with the affected pod and user accounts.
+- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated, and document findings for further analysis.
+- Escalate the incident to the security operations team and relevant stakeholders for awareness and additional support.
+- Implement stricter role-based access controls (RBAC) to limit the use of the 'exec' command to only trusted administrators.
+- Enhance logging policies to ensure comprehensive monitoring of all 'exec' command attempts and integrate with a SIEM for real-time alerting.
+- Apply security patches and updates to the Kubernetes environment to address any known vulnerabilities that may have been exploited.
+- Restore the affected pod from a known good backup to ensure system integrity and continuity of operations.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future resilience.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
index 2fd9df0a9e0..e4c358d7d19 100644
--- a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
+++ b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Anonymous Request Authorized"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Anonymous Request Authorized
+
+Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. However, anonymous requests can occur, often for health checks. Adversaries might exploit this by using anonymous access to infiltrate clusters undetected. The detection rule identifies unauthorized anonymous access by monitoring audit logs for allowed requests from unauthenticated users, excluding common health endpoints.
+
+### Possible investigation steps
+
+- Review the audit logs to identify the specific unauthenticated user request that was authorized, focusing on the `kubernetes.audit.user.username` field to confirm if it matches "system:anonymous" or "system:unauthenticated".
+- Examine the `kubernetes.audit.requestURI` field to determine the exact resource or endpoint accessed, ensuring it is not one of the excluded health check endpoints like `/healthz`, `/livez`, or `/readyz`.
+- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to verify that the decision was indeed "allow", confirming unauthorized access.
+- Investigate the source IP address and user agent from the audit logs to identify the origin of the request and gather more context about the client making the request.
+- Cross-reference the timestamp of the unauthorized access with other logs and events to identify any correlated activities or anomalies in the cluster around the same time.
+- Use Osquery to gather more information about the nodes in the cluster. For example, run the following Osquery query to list all running pods and their associated namespaces: `SELECT name, namespace FROM kubernetes_pods;`.
+- Check for any recent changes in the cluster's RBAC (Role-Based Access Control) policies that might have inadvertently allowed anonymous access.
+- Review the cluster's network policies to ensure there are no misconfigurations that could allow unauthorized access from external sources.
+- Investigate any recent deployments or changes in the cluster that might have introduced vulnerabilities or misconfigurations.
+- Consult with the team responsible for the cluster to verify if there were any legitimate reasons for the anonymous access, such as testing or maintenance activities.
+
+### False positive analysis
+
+- Health checks and monitoring tools: Although the rule excludes common health endpoints like /healthz, /livez, and /readyz, other monitoring tools might access different endpoints anonymously, leading to false positives. Users should identify and exclude these specific endpoints in their environment.
+- Internal services or applications: Some internal services might be configured to use anonymous access for specific operations. Users should review these services and consider adding exceptions for known benign activities.
+- Misconfigured applications: Applications that are not properly configured might inadvertently make anonymous requests. Users should audit application configurations and adjust the rule to exclude these known benign requests.
+- Development and testing environments: In non-production environments, developers might use anonymous access for testing purposes. Users should differentiate between production and non-production environments and apply the rule accordingly to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by adversaries.
+- Review audit logs to identify the source and scope of the unauthorized anonymous access, focusing on any unusual patterns or repeated access attempts.
+- Revoke any unauthorized access tokens or credentials that may have been compromised during the incident.
+- Escalate the incident to the security operations team and, if necessary, involve incident response specialists to assist with a thorough investigation.
+- Implement stricter authentication and authorization policies, ensuring that anonymous access is limited to only necessary endpoints like /healthz, /livez, and /readyz.
+- Enhance logging policies to capture detailed audit logs, including user activities and access attempts, and integrate with a Security Information and Event Management (SIEM) system for real-time monitoring.
+- Conduct a thorough review of the cluster's security configurations, ensuring that Role-Based Access Control (RBAC) is properly configured to minimize permissions for anonymous users.
+- Restore the system to its operational state by applying patches and updates to the Kubernetes environment and any affected applications.
+- Implement network segmentation and micro-segmentation to limit the potential impact of unauthorized access within the cluster.
+- Educate and train the development and operations teams on security best practices and the importance of monitoring for unauthorized access attempts, leveraging MITRE ATT&CK framework insights for threat-specific context.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
index 84e57ae7e00..2d7aa15a652 100644
--- a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
+++ b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,51 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Exposed Service Created With Type NodePort"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Exposed Service Created With Type NodePort
+
+Kubernetes NodePort services enable external access to pods by opening a port on each node, facilitating direct communication with the cluster. Adversaries may exploit this by configuring NodePort services to intercept or redirect traffic, bypassing security controls. The detection rule identifies such activities by monitoring audit logs for service creation or modification events with NodePort specifications, ensuring any unauthorized exposure is flagged for investigation.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the source of the NodePort service creation or modification by examining the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields.
+- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and not denied, ensuring the alert is valid.
+- Identify the user or service account responsible for the action by analyzing the `kubernetes.audit.user.username` field in the audit logs.
+- Investigate the context of the service creation or modification by reviewing the `kubernetes.audit.requestObject.spec.type` field to confirm it is set to "NodePort".
+- Use Osquery to gather additional context about the nodes involved. For example, run the following query to list all services of type NodePort: `SELECT * FROM kubernetes_services WHERE type = 'NodePort';`
+- Examine the network policies in place to determine if there are any existing rules that could have been bypassed due to the NodePort configuration.
+- Review the cluster's role-based access control (RBAC) settings to ensure that only authorized users have permissions to create or modify services.
+- Analyze the logs for any unusual or unexpected traffic patterns directed towards the NodePort, which could indicate potential misuse or exploitation.
+- Cross-reference the NodePort service details with known legitimate services to determine if the creation or modification aligns with expected behavior.
+- Investigate any associated pods or applications that are exposed via the NodePort service to assess their security posture and potential vulnerabilities.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate administrative actions may involve creating or updating NodePort services for maintenance or deployment purposes. To manage these, users can create exceptions for specific user accounts or service accounts known to perform these tasks regularly.
+- Development and testing environments: In non-production environments, NodePort services might be frequently created for testing purposes. Users can exclude these environments from alerts by filtering based on namespace or labels associated with development and testing.
+- Automated deployment tools: Continuous integration and deployment tools might automatically create or modify NodePort services as part of their workflows. Users should identify these tools and exclude their activities by recognizing specific user agents or service accounts.
+- Internal services with external dependencies: Some internal services may require NodePort configurations to interact with external systems. Users can whitelist these services by specifying known IP ranges or service names that are expected to use NodePort.
+- Monitoring and logging tools: Certain monitoring or logging solutions might use NodePort services to collect data from the cluster. Users can manage these by identifying and excluding the specific tools or services involved in these activities.
+
+### Response and remediation
+
+- Immediately isolate the affected NodePort service to prevent further unauthorized access by removing or disabling the service.
+- Review Kubernetes audit logs to identify any unauthorized changes or suspicious activities related to NodePort services.
+- Verify the identity and permissions of the user or service account that created or modified the NodePort service to ensure it aligns with expected behavior.
+- Conduct a thorough investigation to determine if any data was accessed or exfiltrated through the exposed NodePort service.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or services were compromised.
+- Implement network segmentation and firewall rules to restrict NodePort access to only trusted IP addresses and services.
+- Enhance logging policies to ensure comprehensive monitoring of Kubernetes audit logs, focusing on service creation and modification events.
+- Integrate security tools with Kubernetes to automate the detection and alerting of suspicious NodePort activities.
+- Restore the system to its operational state by reconfiguring services to use more secure access methods, such as LoadBalancer or Ingress, instead of NodePort.
+- Apply hardening measures by regularly reviewing and updating Kubernetes RBAC policies to minimize permissions and reduce the attack surface.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
index 6b67122e530..4c74c8b6cd7 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,50 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostIPC"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Pod Created With HostIPC
+
+Kubernetes allows pods to share the host's IPC namespace, enabling access to shared memory and other IPC resources. While useful for certain applications, this can be exploited by attackers to access sensitive data or interfere with host processes. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the `event.dataset` field to ensure it matches "kubernetes.audit_logs".
+- Verify the authorization decision by checking the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed.
+- Examine the `kubernetes.audit.objectRef.resource` field to ensure the resource involved is a pod, and check the `kubernetes.audit.verb` field to determine if the action was a "create", "update", or "patch".
+- Investigate the `kubernetes.audit.requestObject.spec.hostIPC` field to confirm that host IPC was indeed enabled for the pod.
+- Cross-reference the `kubernetes.audit.requestObject.spec.containers.image` field to ensure the image used is not part of the known benign images, such as "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Identify the user or service account responsible for the action by examining the `kubernetes.audit.user.username` field to determine if the action was performed by a legitimate user or service.
+- Use Osquery to gather more information about the pod and its containers. For example, run the following Osquery query to list all pods with host IPC enabled: `SELECT name, namespace, host_ipc FROM kubernetes_pods WHERE host_ipc = 1;`.
+- Check for any unusual or unauthorized processes running within the pod by querying the process table using Osquery: `SELECT pid, name, cmdline FROM processes WHERE pid IN (SELECT pid FROM process_namespaces WHERE ipc_namespace_id = (SELECT ipc_namespace_id FROM process_namespaces WHERE pid = <PID of the suspicious pod>));`.
+- Investigate the `/dev/shm` directory on the host and within the pod for any suspicious files or data that could indicate unauthorized access or data exfiltration.
+- Review the network activity associated with the pod to identify any unusual or unauthorized connections that could suggest lateral movement or data exfiltration attempts.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate applications require the use of the host IPC namespace for valid operational reasons, such as performance optimization or specific inter-process communication needs. These applications might include database systems or distributed computing frameworks that rely on shared memory for efficiency.
+- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to require host IPC access. This can be done by updating the detection rule to exclude additional trusted images or namespaces beyond the already excluded "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Regularly review and update the list of exceptions to ensure that only verified and necessary applications are excluded, minimizing the risk of overlooking potential threats.
+- Consider implementing additional monitoring and logging for pods using host IPC to ensure that any unexpected behavior is quickly identified and addressed, even if the pod is part of an exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further access to the host's IPC namespace and limit potential data exposure.
+- Review Kubernetes audit logs to identify the source of the pod creation or modification request and determine if it was authorized.
+- Investigate the container image used in the pod to ensure it is not malicious or compromised, focusing on images not excluded by the detection rule.
+- Check for any unauthorized access or modifications to shared memory, semaphore arrays, or message queues on the host.
+- Escalate the incident to the security team if unauthorized access or malicious activity is confirmed, providing them with detailed findings and logs.
+- Implement stricter access controls and policies to prevent unauthorized use of the host IPC namespace in future deployments.
+- Enhance logging and monitoring by integrating with security information and event management (SIEM) systems to detect similar threats more effectively.
+- Conduct a thorough review of all pods using the host IPC namespace and ensure they are necessary and secure.
+- Restore affected systems by redeploying pods with secure configurations and verified container images.
+- Apply hardening measures such as network segmentation, least privilege access, and regular security audits to reduce the risk of privilege escalation and host escape attempts.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
index e1e7005a68c..0c140639e20 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,50 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostNetwork"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Pod Created With HostNetwork
+
+Kubernetes allows pods to connect to the host's network namespace, granting them access to services on the host's localhost. This can be exploited by attackers to monitor network traffic or bypass network restrictions. The detection rule identifies suspicious pod creation or modification events by monitoring audit logs for pods using the host network, excluding known benign images, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the audit log entry that triggered the alert to confirm the presence of `hostNetwork:true` in the `kubernetes.audit.requestObject.spec` field, ensuring the pod is indeed using the host network.
+- Verify the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was allowed, indicating a potential security concern.
+- Check the `kubernetes.audit.objectRef.resource` field to confirm the resource type is "pods" and the action in `kubernetes.audit.verb` is "create", "update", or "patch" to validate the context of the alert.
+- Investigate the image used by the pod by examining the `kubernetes.audit.requestObject.spec.containers.image` field to identify if it is a known or unknown image, focusing on those not explicitly excluded by the rule.
+- Cross-reference the pod's namespace and node information to determine if the pod is running in a sensitive or critical environment, which might increase the risk level.
+- Use Osquery to gather additional context about the node where the pod is running. For example, execute the following query to list all pods using the host network on the node: `SELECT name, namespace, hostNetwork FROM kubernetes_pods WHERE hostNetwork = 1;`
+- Analyze network traffic logs from the node to identify any unusual or unauthorized access patterns that might indicate malicious activity originating from the pod.
+- Review recent changes or deployments in the Kubernetes environment to identify if the pod creation or modification aligns with expected operational activities or if it was unexpected.
+- Check for any other alerts or anomalies related to the same pod or node to identify potential patterns or coordinated activities.
+- Consult with the team responsible for the Kubernetes environment to verify if the use of host networking was intentional and authorized, and gather any additional context or documentation related to the deployment.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate applications or services require access to the host network for valid operational reasons, such as monitoring tools or network utilities that need to interact with the host's network stack.
+- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to require host network access. This can be done by updating the detection rule to exclude additional trusted images or namespaces beyond the default exclusion of "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Regularly review and update the list of exceptions to ensure that only necessary and trusted applications are allowed to use the host network, minimizing the risk of overlooking potential threats.
+- Consider implementing additional context-based checks, such as verifying the source of the pod creation request or correlating with other security events, to further reduce the likelihood of false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected pod by removing it from the host network to prevent further unauthorized access to the host's network services.
+- Conduct a thorough investigation of the pod's configuration and logs to identify any unauthorized access or data exfiltration attempts.
+- Review Kubernetes audit logs to trace the origin of the pod creation or modification request and identify any compromised user accounts or credentials.
+- Revoke access and rotate credentials for any accounts suspected of being compromised to prevent further unauthorized actions.
+- Escalate the incident to the security operations team if evidence of privilege escalation or lateral movement is found, following the organization's incident response plan.
+- Implement stricter network policies and role-based access controls (RBAC) to limit the use of host networking to only essential and trusted pods.
+- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities in the future.
+- Conduct a security review of all pods and containers running in the environment to ensure compliance with security best practices and identify any other potential vulnerabilities.
+- Restore the system to its operational state by redeploying affected services with secure configurations and ensuring no unauthorized changes remain.
+- Educate the development and operations teams on the risks associated with host networking and the importance of adhering to security policies and procedures.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
index 49a1dec6249..ca7c965102c 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,50 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostPID"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Pod Created With HostPID
+
+Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges or execute unauthorized actions. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation threats.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to confirm the alert details, focusing on the `event.dataset` field to ensure it matches "kubernetes.audit_logs".
+- Verify the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was allowed, indicating a potential security concern.
+- Examine the `kubernetes.audit.objectRef.resource` field to confirm the resource type is "pods", ensuring the alert pertains to pod creation or modification.
+- Check the `kubernetes.audit.verb` field to determine the action taken, whether it was "create", "update", or "patch", to understand the nature of the change.
+- Investigate the `kubernetes.audit.requestObject.spec.hostPID` field to confirm it is set to true, indicating the pod is sharing the host's PID namespace.
+- Cross-reference the `kubernetes.audit.requestObject.spec.containers.image` field to ensure the image is not part of the known safe list, such as "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Identify the user or service account responsible for the action by examining the `kubernetes.audit.user.username` field to assess if it aligns with expected behavior.
+- Use Osquery to gather additional context on the host by running a query like `SELECT * FROM processes WHERE pid IN (SELECT pid FROM processes WHERE name = 'kubelet');` to identify processes that might be interacting with the Kubernetes API.
+- Investigate the pod's configuration and deployment history to determine if the use of HostPID was intentional or a potential misconfiguration.
+- Review any recent changes in the cluster's configuration or deployments that might have introduced the use of HostPID, correlating with the alert's timestamp.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate administrative tasks require the use of HostPID for debugging or monitoring purposes. These tasks might involve trusted images or tools that are essential for system maintenance.
+- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to be safe and frequently use HostPID for legitimate reasons. This can be done by updating the detection rule to exclude additional trusted images or namespaces.
+- Another potential false positive scenario involves automated processes or CI/CD pipelines that temporarily require HostPID access for testing or deployment purposes. Users should identify these processes and adjust the rule to exclude them from triggering alerts.
+- It is important to regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further interaction with the host processes and potential privilege escalation.
+- Review Kubernetes audit logs to identify any unauthorized access or modifications to pods with HostPID enabled, focusing on the specific time frame of the alert.
+- Verify the integrity of the host system by checking for any unauthorized processes or changes, especially those related to privilege escalation attempts.
+- Revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled, and ensure that only trusted users have the ability to create such pods.
+- Escalate the incident to the security team if evidence of privilege escalation or host compromise is found, providing them with detailed logs and findings.
+- Implement stricter pod security policies to prevent the use of HostPID unless absolutely necessary, and ensure that all containers are running with the least privilege.
+- Enhance logging and monitoring by integrating with security information and event management (SIEM) systems to detect similar threats in the future.
+- Conduct a thorough review of container images and ensure that only approved and secure images are used in the environment.
+- Restore the system to its operational state by redeploying affected services with secure configurations and verified images.
+- Educate the development and operations teams on the risks associated with HostPID and the importance of adhering to security best practices.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
index 20c8c18652f..d6f7b8883fa 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/11"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,51 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod created with a Sensitive hostPath Volume"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Pod created with a Sensitive hostPath Volume
+
+Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to confirm the alert by checking the `event.dataset` field for "kubernetes.audit_logs" and ensure the `kubernetes.audit.annotations.authorization_k8s_io/decision` is "allow".
+- Identify the specific pod involved by examining the `kubernetes.audit.objectRef.resource` field for "pods" and note the `kubernetes.audit.verb` to determine if it was a "create", "update", or "patch" action.
+- Investigate the `kubernetes.audit.requestObject.spec.volumes.hostPath.path` field to determine which sensitive directory was mounted and assess the potential risk associated with this path.
+- Check the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container image used and verify if it is a known or trusted image, excluding "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Use Osquery to gather more information about the node where the pod is running. For example, run the query: `SELECT * FROM kubernetes_pods WHERE name = '<pod_name>';` to get details about the pod's configuration and status.
+- Examine the Kubernetes cluster's RBAC policies to determine if the service account associated with the pod has excessive permissions that could be exploited.
+- Review the pod's logs and any associated application logs for suspicious activity or errors that might indicate a compromise.
+- Check for any recent changes in the cluster configuration or deployments that could have introduced vulnerabilities or misconfigurations.
+- Investigate network activity from the pod to identify any unusual outbound connections or data exfiltration attempts.
+- Correlate the findings with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to identify any related alerts or incidents.
+
+### False positive analysis
+
+- Certain monitoring or logging agents may require access to hostPath volumes for legitimate purposes, such as collecting system metrics or logs. These agents might trigger the rule if they mount sensitive directories.
+- Backup or disaster recovery solutions might use hostPath volumes to access and back up critical data, which could be flagged by the rule.
+- Development or testing environments often use hostPath volumes to simulate production-like conditions, which might not pose a security risk in these controlled settings.
+- Users can handle these false positives by creating exceptions for known benign applications or agents that require hostPath access. This can be done by excluding specific container images or namespaces from the rule.
+- Regularly review and update the list of exceptions to ensure that only trusted applications are excluded, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further access to sensitive host data and potential privilege escalation.
+- Investigate the pod's configuration and logs to determine if there has been unauthorized access or malicious activity.
+- Review Kubernetes audit logs to identify any suspicious activities or patterns related to the creation or modification of pods with sensitive hostPath volumes.
+- Revoke any unnecessary permissions or access rights that may have been granted to the compromised pod or its associated service account.
+- Patch and update the Kubernetes cluster and any affected applications to address known vulnerabilities that could be exploited.
+- Escalate the incident to the security team if evidence of a breach or compromise is found, and consider involving incident response experts if necessary.
+- Implement logging policies to ensure comprehensive monitoring of Kubernetes audit logs and container activities for future incidents.
+- Integrate security tools such as intrusion detection systems and anomaly detection to enhance monitoring and alerting capabilities.
+- Restore the system to its operational state by redeploying the affected pod with secure configurations and without sensitive hostPath volumes.
+- Harden the Kubernetes environment by enforcing security best practices, such as using network policies, role-based access control (RBAC), and regular security audits.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
index f1f93659d1d..53a9502652c 100644
--- a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,51 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Privileged Pod Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Privileged Pod Created
+
+Kubernetes allows for the creation of privileged pods, which can access the host's resources, bypassing container isolation. Adversaries exploit this to escalate privileges, potentially compromising the host. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to confirm the creation of the privileged pod by checking the `event.dataset` field for "kubernetes.audit_logs" and the `kubernetes.audit.verb` field for "create".
+- Verify the authorization decision by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure it was set to "allow".
+- Identify the specific pod and container involved by reviewing the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.requestObject.spec.containers.securityContext.privileged` fields to confirm the pod was created with privileged settings.
+- Cross-reference the image used for the pod against known safe images by checking the `kubernetes.audit.requestObject.spec.containers.image` field to ensure it is not part of the excluded list, such as "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Investigate the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.user.username` field to determine if the action was authorized or suspicious.
+- Check the source IP address and user agent from the audit logs to identify where the request originated, which can provide context on whether the action was internal or external.
+- Use Osquery to gather additional context on the node where the privileged pod was created. For example, run the following Osquery query to list all running containers and their privileges: `SELECT * FROM kubernetes_pods WHERE privileged = 1;`.
+- Analyze the timeline of events leading up to the creation of the privileged pod by reviewing related audit logs to identify any preceding suspicious activities or patterns.
+- Investigate any lateral movement or persistence mechanisms by examining network logs and other security tools for connections or changes initiated from the node hosting the privileged pod.
+- Collaborate with the Kubernetes administrators to verify if the creation of the privileged pod aligns with any recent changes or deployments, ensuring it was not part of a legitimate operation.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate administrative tasks require the creation of privileged pods, such as during system maintenance or when deploying certain monitoring tools that need elevated permissions.
+- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to be safe and necessary for operational purposes, such as internal monitoring tools or trusted third-party applications.
+- It's important to regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+- Consider implementing additional context checks, such as verifying the source of the request or the identity of the user, to further reduce false positives and ensure that only authorized personnel can create privileged pods.
+- Regular audits and reviews of privileged pod usage can help identify patterns that may indicate false positives, allowing for more accurate tuning of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected node to prevent further access or lateral movement by the adversary.
+- Review Kubernetes audit logs to identify the source of the privileged pod creation and any associated user accounts or IP addresses.
+- Revoke access for any compromised user accounts and reset credentials to prevent unauthorized access.
+- Terminate the privileged pod and any other suspicious pods that may have been created by the adversary.
+- Conduct a thorough investigation of the host for signs of compromise, including unauthorized processes, files, or network connections.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed audit logs for all Kubernetes API activities, focusing on pod creation and privilege escalation attempts.
+- Integrate security tools with Kubernetes, such as intrusion detection systems or runtime security solutions, to monitor for and alert on suspicious activities.
+- Restore the system to its operational state by redeploying affected applications and ensuring all security patches and configurations are up to date.
+- Harden the Kubernetes environment by enforcing strict RBAC policies, disabling unnecessary privileges, and regularly reviewing and updating security configurations.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
index 051c4b214e9..b0348369f28 100644
--- a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,50 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Suspicious Assignment of Controller Service Account"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kubernetes Suspicious Assignment of Controller Service Account
+
+Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these powerful accounts to pods, gaining admin-level access. The detection rule identifies such suspicious activity by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, signaling potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the audit log entry that triggered the alert, focusing on the `kubernetes.audit.verb`, `kubernetes.audit.objectRef.resource`, and `kubernetes.audit.objectRef.namespace` fields to confirm the creation of a pod in the `kube-system` namespace.
+- Verify the `kubernetes.audit.requestObject.spec.serviceAccountName` field to identify the specific controller service account assigned to the pod and assess if it is typically used in your environment.
+- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was indeed allowed and not a false positive.
+- Investigate the source of the request by examining the `kubernetes.audit.user.username` field to identify the user or service account that initiated the pod creation.
+- Analyze the `kubernetes.audit.sourceIPs` field to determine the origin IP address of the request, which can help identify if it was made from a known or suspicious location.
+- Use Osquery to gather more information about the pod by running a query such as: `SELECT * FROM kubernetes_pods WHERE namespace = 'kube-system' AND service_account_name LIKE '%controller%';` to list all pods with controller service accounts in the `kube-system` namespace.
+- Cross-reference the pod's creation time with other logs and events to identify any correlated suspicious activities or anomalies around the same timeframe.
+- Review the pod's configuration and associated resources, such as ConfigMaps and Secrets, to identify any unauthorized or unexpected configurations.
+- Investigate the history of the service account in question to determine if it has been used in any other suspicious activities or if there have been recent changes to its permissions.
+- Consult with the team responsible for the Kubernetes environment to verify if the pod creation and service account assignment were part of any legitimate maintenance or deployment activities.
+
+### False positive analysis
+
+- Legitimate administrative actions: In some cases, cluster administrators may intentionally assign controller service accounts to pods for maintenance or testing purposes. These actions, while legitimate, can trigger the detection rule. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform these tasks regularly.
+- Automated deployment tools: Certain automated deployment or orchestration tools might temporarily assign controller service accounts to pods as part of their operation. Users should identify these tools and exclude their activities from triggering alerts by specifying the tool's service account or namespace in the exception list.
+- System updates or upgrades: During system updates or upgrades, Kubernetes might temporarily assign controller service accounts to pods as part of the process. Users can handle these by setting time-based exceptions during known maintenance windows to prevent false positives.
+- Testing environments: In testing or development environments, developers might assign controller service accounts to pods to simulate production scenarios. Users can exclude these environments from monitoring or create specific rules that differentiate between production and non-production environments to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further unauthorized access or actions within the cluster.
+- Review Kubernetes audit logs to identify the source of the suspicious activity and determine if other pods or resources have been compromised.
+- Revoke any unauthorized service account tokens and reset credentials for affected accounts to prevent further misuse.
+- Conduct a thorough investigation to determine how the adversary gained the ability to assign the controller service account, focusing on potential vulnerabilities or misconfigurations.
+- Escalate the incident to the security operations team and relevant stakeholders to ensure awareness and coordinated response efforts.
+- Implement stricter role-based access control (RBAC) policies to limit permissions and prevent unauthorized service account assignments in the kube-system namespace.
+- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities in the future.
+- Apply security patches and updates to Kubernetes components and related infrastructure to mitigate known vulnerabilities.
+- Restore affected systems and services to their operational state by redeploying clean versions of compromised pods and verifying their integrity.
+- Conduct a post-incident review to identify lessons learned and update incident response plans, incorporating additional hardening measures such as network segmentation and regular security audits.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
index 34ee5a28519..c6c6005acfb 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,51 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 High Mean of Process Arguments in an RDP Session
+
+Remote Desktop Protocol (RDP) allows users to connect to systems remotely, often used for administrative tasks. Adversaries exploit RDP for lateral movement by executing complex commands with numerous arguments, often to obfuscate their actions. The detection rule identifies anomalies in the number of process arguments during RDP sessions, signaling potential misuse or sophisticated attack attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific RDP session and the associated user account that triggered the high mean of process arguments.
+- Examine the timestamp of the alert to correlate it with any known scheduled tasks or legitimate administrative activities.
+- Analyze the process command line arguments captured in the alert to identify any suspicious patterns, such as excessive length, obfuscation, or unusual command structures.
+- Check the source and destination IP addresses involved in the RDP session to determine if they are part of the organization's network or if they are external and potentially malicious.
+- Investigate the historical activity of the user account involved in the alert to identify any previous suspicious behavior or anomalies.
+- Utilize Osquery to gather additional context on the processes executed during the RDP session. For example, run the following Osquery query to list processes with a high number of arguments:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE length(cmdline) > 1000;
+  ```
+- Cross-reference the processes identified with known malicious software or tools commonly used for lateral movement and exploitation.
+- Review the system logs for any failed login attempts or unusual authentication patterns around the time of the alert.
+- Check for any recent changes in user privileges or group memberships that could indicate privilege escalation attempts.
+- Investigate any network connections initiated by the processes with high argument counts to identify potential data exfiltration or communication with command and control servers.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often execute complex scripts or commands with numerous arguments during maintenance or configuration tasks, which can trigger false positives. To manage this, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
+- Automated scripts and software updates: Scheduled tasks or automated scripts that run during RDP sessions may involve commands with a high number of arguments. Users can whitelist these scripts or processes by identifying their unique characteristics, such as specific command patterns or originating IP addresses.
+- Development and testing environments: Developers and testers might use RDP sessions to run scripts with multiple arguments for testing purposes. Organizations can exclude these environments from monitoring or set up specific rules that account for the high argument count typical in these scenarios.
+- Third-party software: Some legitimate third-party applications may inherently use complex commands with many arguments during their operation. Users should identify these applications and create exceptions based on their known behavior and usage patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation of the RDP session logs to identify the source IP address and any associated user accounts involved in the suspicious activity.
+- Analyze the process arguments and commands executed during the RDP session to determine the intent and scope of the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are compromised.
+- Implement enhanced logging policies to capture detailed RDP session activities, including command-line arguments and user actions, for future investigations.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework into the security information and event management (SIEM) system to improve detection capabilities.
+- Restore the affected system to its operational state by removing any malicious software, resetting compromised credentials, and applying necessary security patches.
+- Conduct a security audit of RDP configurations and apply hardening measures such as enforcing strong authentication, using network-level authentication, and limiting RDP access to trusted IP addresses.
+- Provide security awareness training to users on the risks associated with RDP and best practices for secure remote access.
+- Review and update the incident response plan to incorporate lessons learned from the incident and improve response strategies for future threats."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
index 0b13d9e762e..8a8c783f708 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 High Mean of RDP Session Duration
+
+Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks and support. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific parameters of the anomaly, including the mean session duration and the threshold that triggered the alert.
+- Correlate the alert with user activity logs to identify the user accounts involved in the prolonged RDP sessions and verify if these accounts are expected to have extended access.
+- Examine the source and destination IP addresses associated with the RDP sessions to determine if they are from known or trusted networks.
+- Check for any concurrent alerts or anomalies related to the same user accounts or IP addresses, such as failed login attempts or unusual login times, to identify potential patterns of malicious behavior.
+- Investigate the session start and end times to determine if the prolonged duration aligns with legitimate business activities or if it occurred during off-hours, which might indicate suspicious activity.
+- Utilize Osquery to gather additional context on the systems involved. For example, run the following Osquery query to list active RDP sessions and their durations: `SELECT user, remote_address, start_time, (strftime('%s','now') - strftime('%s',start_time)) AS session_duration FROM rdp_sessions WHERE session_duration > <threshold>;`
+- Analyze system logs for any signs of lateral movement or exploitation of remote services, such as unusual process executions or network connections initiated during the RDP sessions.
+- Review any recent changes or updates to the systems involved that might explain the prolonged sessions, such as software installations or configuration changes.
+- Check for any known vulnerabilities or exploits related to RDP on the affected systems and ensure they are patched and up-to-date.
+- Consult with the system owners or users involved to verify if the extended RDP sessions were authorized and necessary for legitimate tasks.
+
+### False positive analysis
+
+- Legitimate administrative tasks: Extended RDP sessions may occur during routine system maintenance or software updates by IT staff. These sessions can be excluded by identifying and whitelisting known IP addresses or user accounts associated with IT personnel.
+- Remote support activities: Support teams might require prolonged access to troubleshoot and resolve complex issues. To manage this, create exceptions for support team accounts or specific time frames when support activities are expected.
+- Automated processes: Some automated scripts or processes might use RDP for legitimate purposes, leading to longer session durations. Identify these processes and exclude them by recognizing their unique session patterns or associated user accounts.
+- Training sessions or demonstrations: Extended RDP sessions may be used for training or demonstration purposes. These can be managed by setting exceptions for specific user accounts or during scheduled training periods.
+- Unusual work hours: Employees working outside regular hours might have longer RDP sessions. Consider implementing a policy to monitor and verify these sessions, allowing exceptions for verified after-hours work.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation of the RDP session logs to identify the source IP address and user account involved in the prolonged session.
+- Review and analyze any other network activity from the identified source IP to detect additional signs of compromise or lateral movement.
+- Reset credentials for any user accounts involved in the suspicious RDP sessions to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed RDP session activity, including session start and end times, user accounts, and source IP addresses.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate RDP session anomalies with known threat indicators.
+- Restore the affected system from a known good backup to ensure it is free from any malicious modifications or persistence mechanisms.
+- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation of remote services.
+- Harden RDP access by enforcing multi-factor authentication, using strong password policies, and restricting RDP access to only necessary users and IP addresses."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
index 910d0e198f5..ee4899c5e3f 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -53,6 +53,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Remote File Size
+
+Machine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule flags these anomalies, leveraging MITRE ATT&CK frameworks to pinpoint potential exploitation of remote services.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific remote host and file size that triggered the alert. Pay attention to fields such as source IP, destination IP, file path, and file size.
+- Correlate the alert with recent network activity logs to determine if there are any other unusual patterns or connections involving the same remote host.
+- Check historical data to see if the remote host has previously transferred files of similar sizes or if this is an anomaly.
+- Use Osquery to gather more information about the file in question. For example, run the following query to list files in the directory where the unusual file was detected: `SELECT path, size, atime, mtime FROM file WHERE directory = '/path/to/suspicious/directory';`
+- Investigate the user account associated with the file transfer to determine if there are any signs of compromise or unusual activity, such as failed login attempts or changes in user privileges.
+- Examine the processes running on the remote host at the time of the file transfer to identify any suspicious or unauthorized applications that could be involved in data aggregation or exfiltration.
+- Analyze the file metadata to understand its origin, creation date, and any modifications that might indicate tampering or aggregation of data.
+- Cross-reference the alert with threat intelligence feeds to check if the remote host IP or domain is associated with known malicious activity or threat actors.
+- Review any recent changes in network configurations or security policies that might have inadvertently allowed or facilitated the unusual file transfer.
+- Consult with other security team members or departments to gather additional context or insights that might aid in understanding the nature and intent of the file transfer.
+
+### False positive analysis
+
+- Large file transfers related to legitimate business operations, such as regular backups or data migrations, can trigger false positives. Users should identify these routine activities and create exceptions to prevent unnecessary alerts.
+- Software updates or patches distributed across the network may also be flagged. To manage this, users can whitelist known update servers or processes.
+- Data transfers involving multimedia files, such as video or high-resolution images, might be mistakenly identified as threats. Users should assess the context of these transfers and exclude them if they are part of normal business functions.
+- Remote file sharing services used for collaboration, like cloud storage solutions, can generate large file transfers. Users should monitor these services and exclude them if they are verified as secure and necessary for operations.
+- Automated data processing tasks that involve large datasets can be misinterpreted as suspicious activity. Users should document these processes and configure the system to recognize them as non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the anomaly, focusing on recent file transfer activities and user access logs.
+- Analyze the large file for any malicious content or sensitive data that may have been aggregated by the adversary.
+- Review and update access controls and permissions to ensure that only authorized users have access to sensitive data and remote services.
+- Implement enhanced logging and monitoring policies to capture detailed file transfer activities and user actions for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual file size alerts with other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response if the threat persists or is part of a larger attack.
+- Restore the affected system to its operational state by removing any malicious files, patching vulnerabilities, and verifying system integrity.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement hardening measures such as network segmentation, multi-factor authentication, and regular security training to reduce the risk of future exploitation of remote services."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
index 9002606a3a3..cd8918fe1fd 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,52 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 High Variance in RDP Session Duration
+Remote Desktop Protocol (RDP) enables remote access to systems, facilitating legitimate administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, often for lateral movement within networks. The detection rule leverages machine learning to identify anomalies in session duration, flagging potential misuse by highlighting sessions with unusually high variance, indicative of suspicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific RDP session(s) with high variance in duration, noting the user accounts and source IP addresses involved.
+- Correlate the session details with historical data to determine if the user or IP address has a pattern of unusual activity or if this is an isolated incident.
+- Check the login times and durations of the flagged RDP sessions to see if they align with typical working hours or if they occur at unusual times.
+- Investigate the user account(s) involved in the sessions for any recent changes, such as password resets or privilege escalations, that could indicate compromise.
+- Use Osquery to gather additional context on the affected systems. For example, run the following query to list active RDP sessions and their durations:
+  ```sql
+  SELECT user, remote_address, start_time, end_time, (julianday(end_time) - julianday(start_time)) * 24 * 60 AS duration_minutes 
+  FROM rdp_sessions 
+  WHERE duration_minutes > <threshold>;
+  ```
+- Examine the network traffic logs for the source IP addresses to identify any other suspicious connections or data transfers that coincide with the RDP sessions.
+- Analyze system logs on the affected machines for any unusual processes or commands executed during the flagged RDP sessions.
+- Check for any recent changes in firewall or security group configurations that might have allowed unauthorized RDP access.
+- Review any recent alerts or incidents involving the same user accounts or IP addresses to identify potential patterns of malicious activity.
+- Consult with the user(s) associated with the flagged sessions to verify if the activity was legitimate and authorized, documenting their responses for further analysis.
+
+### False positive analysis
+
+- Legitimate administrative tasks: Extended RDP sessions by IT staff for system maintenance or software updates can trigger false positives. Users can manage this by creating exceptions for known administrative accounts or IP addresses.
+- Remote support sessions: Third-party vendors providing remote support might have prolonged RDP sessions. To handle this, users can whitelist specific vendor IPs or user accounts.
+- Training sessions: RDP sessions used for training purposes may last longer than usual. Users should consider excluding training-related accounts or session times from the detection rule.
+- Automated processes: Some automated scripts or processes might require long RDP sessions. Users can exclude these by identifying and listing the specific scripts or processes that are known to be non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation of the RDP session logs to identify the source IP address and any associated user accounts involved in the suspicious activity.
+- Review and analyze other network logs and security alerts to determine if there are additional compromised systems or accounts.
+- Reset passwords for any user accounts that were involved in the suspicious RDP sessions and enforce multi-factor authentication (MFA) for all remote access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed RDP session data, including session duration, source IP addresses, and user activity.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate RDP session anomalies with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the affected system to its operational state by reimaging the machine and applying the latest security patches and updates.
+- Conduct a post-incident review to identify gaps in security controls and update the incident response plan accordingly.
+- Implement hardening measures such as restricting RDP access to specific IP addresses, using network segmentation, and regularly auditing RDP usage to prevent future exploitation."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
index 95486b7b141..2159b1e97ed 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Remote File Directory
+
+In enterprise environments, remote file transfers are common for legitimate operations. However, adversaries exploit this by targeting less monitored directories to evade detection. The 'Unusual Remote File Directory' detection rule identifies anomalies in file transfers to atypical directories, signaling potential lateral movement. By focusing on uncommon paths, it helps uncover stealthy exploitation attempts, aligning with MITRE ATT&CK's lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unusual directory involved in the remote file transfer.
+- Check the source and destination IP addresses associated with the file transfer to determine if they are known or expected within the network.
+- Analyze the user account involved in the transfer to verify if the activity aligns with their typical behavior or job role.
+- Investigate the timestamp of the file transfer to see if it coincides with any other suspicious activities or known attack patterns.
+- Use Osquery to list recent file modifications in the unusual directory with a query like: `SELECT path, size, atime, mtime FROM file WHERE directory = '/path/to/unusual/directory';`
+- Examine the file types and names transferred to assess if they are commonly used in legitimate operations or if they appear suspicious.
+- Cross-reference the unusual directory with known directories used in previous incidents or documented attack techniques.
+- Check for any recent changes in permissions or ownership of the unusual directory that could indicate unauthorized access.
+- Look for any related alerts or logs that might provide additional context or corroborate the suspicious activity.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors that use similar tactics or target similar directories.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may perform legitimate file transfers to less common directories for maintenance or configuration purposes. These activities can be excluded by identifying and whitelisting known administrative accounts and their typical operations.
+- Software updates and deployments: Automated processes for software updates or deployments might use non-standard directories temporarily. Users can manage these by creating exceptions for specific update tools or deployment scripts.
+- Backup operations: Backup solutions might store data in unusual directories to avoid interference with regular operations. To handle this, users should identify and exclude directories used by verified backup solutions.
+- Development and testing environments: Developers may transfer files to atypical directories during testing phases. Organizations can mitigate false positives by excluding directories associated with development and testing environments.
+- Third-party integrations: Some third-party applications may require file transfers to non-standard directories as part of their functionality. Users should document and exclude these directories after verifying the application's legitimacy.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement and contain the threat.
+- Conduct a thorough investigation of the unusual directory to identify any unauthorized files or scripts that may have been transferred.
+- Analyze logs and network traffic to trace the source of the remote file transfer and identify any other potentially compromised systems.
+- Remove any malicious files or scripts found in the unusual directory and restore any altered system files from a known good backup.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to monitor file transfers to and from less common directories, ensuring comprehensive coverage of potential attack vectors.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate employees on recognizing and reporting suspicious activities to enhance the organization's overall security awareness and readiness."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
index e652d49aef9..bc0f79de5ec 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -51,6 +51,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Remote File Extension
+In enterprise environments, remote file transfers are common for legitimate operations. However, adversaries may exploit this by transferring files with rare or unusual extensions to facilitate lateral movement, often bypassing standard security measures. The 'Unusual Remote File Extension' detection rule identifies anomalies in file extensions during remote transfers, flagging potential exploitation of remote services, aligning with MITRE ATT&CK's lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file extension and the source and destination of the remote file transfer.
+- Check the historical data for the identified file extension to determine if it has been used previously in legitimate operations.
+- Analyze the user account associated with the file transfer to verify if the activity aligns with their typical behavior and access patterns.
+- Investigate the source and destination IP addresses to determine if they are known and trusted within the organization.
+- Use Osquery to gather additional context on the host involved in the transfer. For example, run the following query to list recent file modifications: `SELECT path, size, atime, mtime FROM file WHERE path LIKE '/path/to/directory/%' ORDER BY mtime DESC LIMIT 10;`
+- Examine the process tree on the source host to identify any unusual or unexpected processes that may have initiated the file transfer.
+- Cross-reference the file hash with threat intelligence databases to check for any known malicious indicators.
+- Review network logs to identify any other unusual or suspicious activities associated with the source or destination IP addresses.
+- Check for any recent changes in user permissions or configurations that could have facilitated the unusual file transfer.
+- Consult with the user or department associated with the file transfer to verify if the activity was authorized and legitimate.
+
+### False positive analysis
+
+- Known false positives for the Unusual Remote File Extension rule often include legitimate software updates or patches that use uncommon file extensions during remote transfers. These can be mistakenly flagged as suspicious.
+- Internal development teams may transfer files with custom extensions for testing or deployment purposes, which can trigger the rule despite being non-threatening.
+- Automated backup systems might use unique file extensions to differentiate between versions or types of data, leading to false positives.
+- To manage these false positives, users can create exceptions for specific file extensions that are regularly used in legitimate operations by trusted applications or systems.
+- Implementing a whitelist of known and verified file extensions associated with routine business processes can help reduce unnecessary alerts.
+- Regularly reviewing and updating the list of exceptions based on changes in business operations or software updates can ensure that the detection rule remains effective without generating excessive false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation of the unusual file extension to determine its origin, purpose, and any associated processes or network connections.
+- Review recent remote file transfer logs to identify any other instances of unusual file extensions or suspicious activity.
+- Utilize endpoint detection and response (EDR) tools to scan the affected host for known indicators of compromise (IOCs) related to the identified threat.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of compromise or if the threat level is beyond initial containment capabilities.
+- Remove any malicious files or software identified during the investigation and apply security patches to address any exploited vulnerabilities.
+- Restore the system to its operational state by ensuring all malicious artifacts are removed and verifying system integrity.
+- Implement enhanced logging policies to capture detailed information on remote file transfers and unusual file extensions for future investigations.
+- Integrate threat intelligence feeds and automated alerting systems to improve detection of similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting remote file transfer capabilities to trusted sources and implementing strict access controls."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
index f2f1c672314..4ab09e203d9 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Number of Connections Made from a Source IP
+
+Remote Desktop Protocol (RDP) is a common technology used for remote management and access. Adversaries exploit RDP to move laterally within networks, seeking valuable data or further access. The detection rule identifies unusual spikes in RDP connections from a single source IP, signaling potential lateral movement attempts, aligning with MITRE ATT&CK's lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the source IP address and the list of destination IPs involved in the spike of RDP connections.
+- Verify the legitimacy of the source IP by checking if it belongs to a known and trusted device within the organization.
+- Analyze historical logs to determine if the source IP has exhibited similar behavior in the past or if this is an anomaly.
+- Cross-reference the source IP with threat intelligence feeds to check for any known malicious activity associated with it.
+- Use Osquery to gather more information about the source system. For example, run the following query to list active RDP sessions: `SELECT * FROM rdp_connections WHERE local_address = '<source_ip>';`
+- Investigate the destination IPs to determine if they are critical assets or if they have any known vulnerabilities that could be exploited.
+- Check for any recent changes or updates on the source system that might explain the spike in connections, such as new software installations or configuration changes.
+- Review user activity logs to identify any unusual login patterns or failed login attempts associated with the source IP.
+- Examine network traffic logs for any signs of data exfiltration or other suspicious activities originating from the source IP.
+- Collaborate with the IT team to verify if there were any legitimate administrative tasks or maintenance activities that could account for the increased RDP connections.
+
+### False positive analysis
+
+- Routine administrative tasks: Regularly scheduled maintenance or updates by IT staff can result in a spike in RDP connections from a single source IP. These activities are typically non-threatening and can be excluded by identifying and whitelisting the IP addresses of known administrative machines.
+- Automated scripts or tools: Some organizations use automated scripts or management tools that initiate multiple RDP connections for monitoring or configuration purposes. These should be reviewed and, if deemed safe, excluded from triggering alerts by adding them to an exception list.
+- Load balancers or proxy servers: In environments where RDP connections are routed through load balancers or proxy servers, a single source IP may appear to make numerous connections. Identifying these devices and excluding their IPs can prevent false positives.
+- Remote work scenarios: Employees working remotely might connect to multiple systems via RDP for legitimate business purposes. Recognizing these patterns and excluding the associated IPs can help reduce unnecessary alerts.
+- Testing and development environments: In testing or development environments, frequent RDP connections might occur as part of normal operations. These environments can be excluded from monitoring or have specific rules applied to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
+- Conduct a thorough investigation to identify the source of the RDP connection spike, including reviewing logs and network traffic for any signs of unauthorized access or exploitation.
+- Reset credentials for any accounts that may have been compromised, especially those with administrative privileges, to prevent further unauthorized access.
+- Apply security patches and updates to all systems, focusing on vulnerabilities related to RDP and remote services, to mitigate exploitation risks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for RDP connections and other remote access protocols to detect future anomalies and potential threats.
+- Review and update firewall rules and access controls to restrict RDP access to only trusted IP addresses and necessary users.
+- Conduct a post-incident review to identify gaps in security controls and processes, and develop an action plan to address these weaknesses.
+- Restore the affected system to its operational state by reimaging or rebuilding it from a known good backup, ensuring all security measures are in place.
+- Implement hardening measures such as enabling network-level authentication for RDP, using multi-factor authentication, and disabling unused services to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
index b155d1cd313..89c33260bb6 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,48 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Number of Connections Made to a Destination IP
+
+Remote Desktop Protocol (RDP) facilitates remote access to systems, crucial for IT management. However, adversaries exploit RDP for lateral movement within networks, often using multiple compromised IPs to avoid detection. The detection rule identifies unusual spikes in RDP connections to a single IP, signaling potential coordinated attacks, thus enabling timely threat mitigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the destination IP and the time frame of the spike in RDP connections.
+- Cross-reference the destination IP with internal asset inventories to determine the role and importance of the system within the network.
+- Analyze historical connection patterns to the destination IP to establish a baseline and confirm the anomaly.
+- Identify the source IPs involved in the spike and check for any known malicious activity or reputation using threat intelligence sources.
+- Use network logs to trace the origin of the source IPs and determine if they belong to internal or external networks.
+- Investigate user accounts associated with the source IPs to check for any unauthorized access or unusual activity.
+- Utilize Osquery to gather more information about the processes and users on the destination system. Example query: `SELECT * FROM processes WHERE name LIKE '%rdp%' OR name LIKE '%mstsc%';`
+- Check for any recent changes or updates on the destination system that might have triggered the spike in connections.
+- Review any recent security alerts or incidents that might be related to the destination IP or the source IPs.
+- Collaborate with IT and security teams to gather additional context, such as recent network changes or ongoing projects, that might explain the spike in connections.
+
+### False positive analysis
+
+- High-volume legitimate administrative activities: Organizations with centralized IT management might see spikes in RDP connections due to routine maintenance or software updates. These activities can be excluded by identifying and whitelisting known administrative IPs.
+- Automated backup or monitoring systems: Systems that regularly connect to multiple endpoints for backups or monitoring can trigger false positives. Users should configure exceptions for these systems by recognizing their IP addresses and connection patterns.
+- Load balancing or failover mechanisms: In environments using load balancers or failover systems, multiple connections to a single IP might occur as part of normal operations. Users can manage these by excluding IPs associated with these mechanisms from the detection rule.
+- Training or testing environments: In scenarios where multiple users are accessing a single system for training or testing purposes, spikes in RDP connections can be expected. Users should consider excluding these environments by setting up specific rules or exceptions for known training IPs.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further lateral movement by the attacker.
+- Conduct a thorough investigation to identify all compromised source IPs and assess the extent of the breach.
+- Block the identified malicious IPs at the firewall and update intrusion detection/prevention systems to recognize similar patterns.
+- Reset credentials for all accounts that were accessed via RDP during the time of the spike to prevent unauthorized access.
+- Review and enhance logging policies to ensure detailed RDP connection logs are maintained for future analysis and detection.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore affected systems from known good backups and ensure all systems are updated with the latest security patches.
+- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users and administrators on secure RDP practices and the importance of using multi-factor authentication to enhance security."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
index 6da8b35fb4b..1454bd87bcd 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -51,6 +51,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Number of Processes in an RDP Session
+
+Remote Desktop Protocol (RDP) allows users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement by executing numerous processes on a target machine, indicating potential exploitation of remote services. The detection rule leverages machine learning to identify anomalies in process activity within RDP sessions, flagging unusual spikes that may suggest malicious behavior.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific RDP session and the user account involved in the spike of processes.
+- Examine the timestamp of the alert to correlate with any known scheduled tasks or legitimate administrative activities.
+- Check the source and destination IP addresses of the RDP session to determine if they are within expected ranges or if they are unusual for the user or organization.
+- Analyze the list of processes that were started during the RDP session to identify any known malicious or suspicious executables.
+- Investigate the parent-child relationship of the processes to understand the execution flow and identify any anomalies.
+- Use Osquery to gather additional context on the processes. For example, run the following query to list processes started by the user during the session: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>' AND start_time BETWEEN '<start_time>' AND '<end_time>';`
+- Check for any recent changes in user permissions or group memberships that might have facilitated the execution of multiple processes.
+- Review the event logs on the target machine for any additional indicators of compromise or related suspicious activities.
+- Investigate any network connections initiated by the processes to identify potential data exfiltration or communication with command and control servers.
+- Correlate the findings with other security alerts or logs to determine if this activity is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- Routine administrative tasks: High process activity can occur during legitimate administrative operations, such as software updates or system maintenance, which may trigger false positives. Users can manage these by creating exceptions for known maintenance windows or specific administrative accounts.
+- Automated scripts: Scheduled tasks or automated scripts that execute multiple processes in a short time frame can also lead to false positives. To handle this, users can whitelist specific scripts or processes that are known to be safe and frequently executed.
+- Software installations: Installing or updating software often involves starting numerous processes, which might be flagged as suspicious. Users should consider excluding these activities by identifying and allowing specific installation processes or packages.
+- Testing environments: In environments where testing and development occur, there may be legitimate reasons for high process activity. Users can exclude these environments from monitoring or adjust the sensitivity of the detection rule for these specific contexts.
+- High user activity: During periods of high user activity, such as training sessions or workshops, there may be a legitimate increase in process activity. Users can temporarily adjust thresholds or create exceptions for these events to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation of the processes executed during the RDP session to identify any malicious or unauthorized activities.
+- Review user account activity and permissions associated with the RDP session to ensure no unauthorized access or privilege escalation has occurred.
+- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed RDP session activities, including process creation, user logins, and network connections.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the affected system from a known good backup to ensure it is free from any malicious modifications.
+- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation of known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
index 793014dff2b..a8ac3535dbc 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -53,6 +53,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Remote File Transfers
+
+Remote file transfer technologies facilitate seamless data sharing across networks, essential for collaboration and operations. However, adversaries exploit these technologies to move laterally within a network, often transferring data in small, inconspicuous batches to avoid detection. The 'Spike in Remote File Transfers' detection rule leverages machine learning to identify unusual transfer volumes, signaling potential malicious activity and aligning with MITRE ATT&CK's lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and user account involved in the unusual remote file transfer activity.
+- Examine the timestamp of the detected spike to correlate with any known scheduled tasks or legitimate business operations.
+- Analyze network logs to identify the source and destination IP addresses involved in the file transfers, checking for any known malicious IPs.
+- Investigate the file types and sizes transferred to determine if they align with typical business operations or if they contain sensitive data.
+- Use Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name LIKE '%scp%' OR name LIKE '%rsync%' OR name LIKE '%ftp%';` to identify any suspicious file transfer processes.
+- Check user activity logs to verify if the user account involved in the transfer has a history of similar activities or if this is an anomaly.
+- Review authentication logs to determine if there were any unusual login attempts or successful logins around the time of the file transfer spike.
+- Investigate any recent changes in user permissions or roles that might have facilitated the file transfers.
+- Correlate the detected activity with any other alerts or incidents in the same timeframe to identify potential patterns or coordinated attacks.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors using similar tactics, techniques, and procedures (TTPs) that match the observed activity.
+
+### False positive analysis
+
+- Known false positives for the Spike in Remote File Transfers rule often include legitimate business operations such as regular data backups, software updates, or large file transfers related to business processes. These activities can mimic the patterns of small, frequent data transfers that the rule is designed to detect.
+- To manage these false positives, users can create exceptions for specific hosts or IP addresses known to perform regular, non-threatening file transfers. This can be done by analyzing historical data to identify consistent patterns and then configuring the detection system to exclude these patterns from triggering alerts.
+- Another method to handle false positives is to adjust the sensitivity of the machine learning model. By fine-tuning the model parameters, users can reduce the likelihood of false positives while still maintaining the ability to detect genuine threats.
+- Users should also consider implementing a whitelist of trusted applications and services that are known to perform legitimate remote file transfers. This can help in distinguishing between benign and potentially malicious activities.
+- Regularly reviewing and updating the list of exceptions and whitelisted entities is crucial, as network environments and business processes evolve over time, potentially altering the baseline of normal activity.
+
+### Response and remediation
+
+- Isolate the affected systems from the network to prevent further lateral movement and data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on logs and alerts related to remote file transfers.
+- Analyze the detected abnormal file transfer patterns to determine if they align with known MITRE ATT&CK techniques, specifically T1210 Exploitation of Remote Services.
+- Review and enhance logging policies to ensure comprehensive monitoring of remote file transfer activities, including the implementation of centralized logging solutions.
+- Implement additional security controls such as network segmentation and access controls to limit the potential for lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Remove any identified malicious software or tools used by the adversary to facilitate remote file transfers.
+- Restore affected systems from clean backups and ensure all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate employees on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security policies and procedures."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
index 91706bb4f63..dbd105d1fd3 100644
--- a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,49 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Time or Day for an RDP Session
+
+Remote Desktop Protocol (RDP) enables remote access to systems, crucial for IT management but also a target for adversaries seeking unauthorized access. Attackers exploit RDP by initiating sessions at odd hours to avoid detection. The detection rule leverages machine learning to identify RDP sessions occurring at atypical times, flagging potential lateral movement or exploitation attempts, thus aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and source IP address involved in the unusual RDP session.
+- Check the timestamp of the RDP session to determine the exact time and day it occurred, comparing it with the user's typical access patterns.
+- Correlate the unusual RDP session with other security events around the same time, such as failed login attempts or changes in user permissions, to identify potential indicators of compromise.
+- Investigate the source IP address to determine if it is associated with known malicious activity or if it originates from an unexpected location for the user.
+- Use Osquery to gather additional context on the system accessed via RDP. For example, run the following query to list recent RDP sessions: `SELECT * FROM rdp_connections WHERE timestamp > (SELECT MAX(timestamp) - 86400 FROM rdp_connections);`
+- Examine the system's security logs for any anomalies or suspicious activities that occurred before or after the RDP session, such as new software installations or changes to system configurations.
+- Verify the legitimacy of the user account involved by checking recent account activity and any changes to account settings or privileges.
+- Consult with the user or their manager to confirm whether the RDP session was authorized and if there were any legitimate reasons for accessing the system at that time.
+- Investigate any other systems accessed by the same user account or from the same source IP address to identify potential lateral movement within the network.
+- Document all findings and observations during the investigation to provide a comprehensive overview of the incident and support further analysis if needed.
+
+### False positive analysis
+
+- Known false positives for the Unusual Time or Day for an RDP Session rule may include legitimate administrative tasks performed by IT staff during off-hours or scheduled maintenance activities that occur outside of typical business hours.
+- Users can manage these false positives by creating exceptions for specific user accounts or IP addresses that are known to perform legitimate RDP sessions at unusual times, ensuring these are documented and reviewed regularly.
+- Another method to handle false positives is to analyze historical data to identify patterns of legitimate access during atypical hours, allowing for the adjustment of the machine learning model's sensitivity or thresholds.
+- It's important to consider the context of the organization, such as global operations or remote work policies, which may naturally lead to RDP sessions at odd hours, and adjust the detection criteria accordingly.
+- Regularly updating the list of known exceptions and reviewing them in the context of any changes in the organization's operations or IT policies can help minimize false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the RDP session by contacting the user or system owner to confirm if the session was authorized.
+- Conduct a thorough investigation of the system for any signs of compromise, such as unusual processes, unauthorized user accounts, or unexpected network connections.
+- Review system and security logs to identify any other suspicious activities that may have occurred before or after the unusual RDP session.
+- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team if evidence of compromise is found, providing them with all relevant logs and findings.
+- Implement enhanced logging policies to capture detailed RDP session information, including timestamps, user accounts, and source IP addresses.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate RDP session data with known threat indicators.
+- Restore the system to its operational state by applying necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
+- Harden the system by enforcing strong authentication mechanisms, such as multi-factor authentication (MFA), and restricting RDP access to only trusted IP addresses."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
index 9cd9d0b4429..f0b7da11273 100644
--- a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
+++ b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/29"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Gary Blackwell", "Austin Songer"]
@@ -23,7 +23,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Inbox Forwarding Rule Created"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Inbox Forwarding Rule Created
+
+Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to covertly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation or modification of such rules, specifically targeting actions that forward or redirect emails, thereby identifying potential unauthorized email collection activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account associated with the creation or modification of the inbox forwarding rule by examining the `o365.audit.Parameters` fields.
+- Verify the `event.action` field to determine whether the rule was newly created or modified, which can provide context on whether this is a new behavior or a change to existing configurations.
+- Check the `o365.audit.Parameters.ForwardTo`, `o365.audit.Parameters.ForwardAsAttachmentTo`, and `o365.audit.Parameters.RedirectTo` fields to identify the destination email addresses to which emails are being forwarded or redirected.
+- Investigate the `event.outcome` field to confirm the success of the rule creation or modification, ensuring that the alert is not a false positive due to a failed attempt.
+- Correlate the user account activity with recent login events to determine if there are any unusual login patterns or locations, using the `event.dataset:o365.audit` and `event.provider:Exchange` fields.
+- Examine the user's recent activity logs for any other suspicious actions or anomalies that might indicate account compromise, such as changes in user settings or permissions.
+- Utilize Osquery to gather additional context on the user's device and activity. For example, run a query to list recent processes executed by the user: `SELECT * FROM processes WHERE user = '<username>';`.
+- Check for any recent changes in the user's permissions or roles within Microsoft 365 that might indicate privilege escalation attempts.
+- Investigate whether similar forwarding rules have been created for other users within the organization, which could suggest a broader attack campaign.
+- Review any recent security alerts or incidents related to the user or the destination email addresses to identify potential links to known threats or ongoing investigations.
+
+### False positive analysis
+
+- Legitimate forwarding rules set by users for business purposes can trigger false positives. Users should review the context of the rule creation, such as the involved email addresses and the user's role, to determine if the action is expected.
+- Automated systems or third-party applications that integrate with Microsoft 365 and require email forwarding for functionality might also cause false positives. Identifying these systems and excluding their actions from the rule can help reduce noise.
+- Temporary forwarding rules set during employee transitions or for out-of-office scenarios can be mistaken for malicious activity. Organizations can manage this by maintaining a list of approved temporary rules and excluding them from detection.
+- Regular audits of forwarding rules can help distinguish between legitimate and suspicious activities. Implementing a process to document and approve forwarding rules can aid in quickly identifying false positives.
+- Users can create exceptions in the detection rule for specific users or departments known to frequently use forwarding rules for legitimate reasons, reducing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately disable the suspicious inbox forwarding rule to prevent further unauthorized email redirection.
+- Conduct a thorough investigation to determine the scope of the compromise, including identifying any other potentially malicious rules or configurations.
+- Review the affected user's account activity for any signs of compromise, such as unusual login locations or times, and reset the account password.
+- Notify the affected user and relevant stakeholders about the incident and provide guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems are affected.
+- Implement enhanced logging and monitoring for email rule changes and user account activities to detect similar threats in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze related security events.
+- Restore any affected systems or accounts to their operational state by removing unauthorized changes and verifying system integrity.
+- Apply security hardening measures, such as enabling multi-factor authentication (MFA) for all users and restricting the ability to create forwarding rules to trusted users.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
index ceb1b377150..4261c630c4e 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
@@ -4,7 +4,7 @@ integration = ["o365"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Willem D'Haese", "Austin Songer"]
@@ -86,6 +86,52 @@ from logs-o365.audit-*
 // filter for users with more than 20 login sources or failed login attempts
 | where (login_source_count >= 20 or failed_login_count >= 20)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Attempts to Brute Force a Microsoft 365 User Account
+
+Microsoft 365 is a cloud-based suite offering productivity and collaboration tools. Adversaries may exploit its authentication mechanisms by attempting brute-force attacks, trying numerous password combinations to gain unauthorized access. The detection rule identifies such attempts by analyzing audit logs for unusual patterns, such as a high number of failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity.
+
+### Possible investigation steps
+
+- Review the `o365.audit.UserId` field to identify the specific user account targeted by the brute-force attempt and check for any unusual activity associated with this account.
+- Examine the `source.ip` field to identify the IP addresses involved in the failed login attempts. Cross-reference these IPs with threat intelligence sources to determine if they are known for malicious activity.
+- Analyze the `target_time_window` to understand the timeframe of the brute-force attempt and correlate it with other security events or alerts that occurred during the same period.
+- Investigate the `event.provider` field to determine whether the brute-force attempts were made against Azure Active Directory or Exchange, which may provide insights into the attacker's target.
+- Check the `o365.audit.LogonError` field to identify the specific errors encountered during the login attempts, which may indicate the attacker's method or level of access.
+- Utilize the `event.action` field to confirm the nature of the failed login attempts, ensuring they align with the expected actions for a brute-force attack.
+- Use Osquery to gather additional context on the affected user account. For example, run the following query to check recent login activities on the user's device:
+  ```sql
+  SELECT * FROM logins WHERE user = '<o365.audit.UserId>';
+  ```
+- Investigate the `o365.audit.ExtendedProperties.RequestType` field to determine the type of login request, which may help identify if the attacker is using a specific method or tool.
+- Review the `o365.audit.Target.Type` field to understand the type of target involved in the login attempts, which can help differentiate between user and application logins.
+- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather a comprehensive view of the attack and its potential impact.
+
+### False positive analysis
+
+- High volume of legitimate login attempts: Users or applications that frequently log in from multiple locations or devices may trigger the rule. To manage this, create exceptions for known IP addresses or user accounts that are verified as non-threatening.
+- Automated scripts or services: Some organizations use automated scripts or services that log in to Microsoft 365 accounts for legitimate purposes, which may appear as brute-force attempts. Identify these scripts and whitelist their IP addresses or user accounts to prevent false positives.
+- Shared accounts: Accounts used by multiple users across different locations can generate numerous login attempts from various sources. Consider implementing stricter access controls or monitoring these accounts separately to reduce false positives.
+- Frequent password changes: Users who frequently change their passwords may inadvertently cause multiple failed login attempts. Educate users on best practices for password management and consider excluding these accounts from the rule if they are known to follow security protocols.
+- Security testing: Internal security teams conducting penetration tests or security assessments may trigger the rule. Coordinate with these teams to whitelist their activities during testing periods to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Conduct a thorough investigation of the audit logs to identify the source IP addresses involved in the brute-force attempts and block these IPs at the firewall or network level.
+- Reset the password for the compromised user account and enforce a strong password policy to prevent easy guessing.
+- Enable multi-factor authentication (MFA) for the affected account and other high-risk accounts to add an additional layer of security.
+- Review and update conditional access policies to restrict access based on location, device compliance, and other risk factors.
+- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been targeted.
+- Implement enhanced logging and monitoring policies to capture detailed authentication events and integrate with a Security Information and Event Management (SIEM) system for real-time analysis.
+- Conduct a security awareness training session for users to educate them on recognizing phishing attempts and the importance of using strong, unique passwords.
+- Restore the system to its operational state by verifying that no unauthorized changes were made during the attack and ensuring all security patches are up to date.
+- Harden the environment by reviewing and applying security best practices, such as disabling legacy authentication protocols and regularly reviewing access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
index 7b2baeefe60..3e85ad70a16 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/01"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/09/05"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,52 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Deprecated - Potential Password Spraying of Microsoft 365 User Accounts"
-note = """This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Deprecated - Potential Password Spraying of Microsoft 365 User Accounts
+
+Microsoft 365 is a cloud-based suite offering productivity and collaboration tools, which relies on robust authentication mechanisms to secure user access. Adversaries may exploit these mechanisms through password spraying, a technique involving numerous login attempts with common passwords across many accounts. The detection rule identifies such attempts by monitoring failed logins from a single IP, flagging potential unauthorized access efforts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the number of failed login attempts from the specific IP address and verify if it meets the threshold of 25 failed attempts within 30 minutes.
+- Identify the IP address involved in the alert and perform a reverse DNS lookup to gather more information about its origin and whether it is associated with known malicious activity.
+- Cross-reference the IP address with threat intelligence sources to determine if it has been previously reported for suspicious or malicious activities.
+- Examine the list of user accounts targeted by the failed login attempts to identify any patterns, such as common roles or departments, which might indicate a targeted attack.
+- Check the event logs for successful logins from the same IP address to determine if any unauthorized access was achieved.
+- Analyze the timestamps of the failed login attempts to identify any unusual patterns or timing that could provide additional context about the attack.
+- Use Osquery to investigate the affected systems for any signs of compromise or unusual activity. For example, run the following Osquery query to check for recent login attempts on a specific system: `SELECT * FROM last WHERE username IN ('user1', 'user2', 'user3') AND time > (SELECT strftime('%s', 'now') - 1800);`
+- Investigate any other authentication-related events from the same IP address or involving the same user accounts to identify potential lateral movement or further attack attempts.
+- Review the organization's security policies and configurations for Microsoft 365 to ensure that they align with best practices for preventing password spraying attacks.
+- Collaborate with other teams, such as network or security operations, to gather additional context or logs that might assist in the investigation, such as firewall logs or network traffic analysis.
+
+### False positive analysis
+
+- High volume of failed login attempts from a single IP may occur due to legitimate reasons such as users mistyping passwords or using outdated credentials, especially after a password change policy is enforced.
+- Automated scripts or applications that use outdated credentials for authentication can trigger false positives if they repeatedly attempt to log in.
+- Shared IP addresses, such as those from corporate networks or VPNs, can result in multiple failed login attempts being logged from the same IP, even if they originate from different users.
+- To manage these false positives, users can create exceptions for known IP addresses associated with trusted networks or services.
+- Implementing a monitoring system to track and whitelist IP addresses that consistently show non-threatening behavior can help reduce false positives.
+- Regularly updating and maintaining a list of known applications or scripts that may cause failed login attempts can assist in excluding these from triggering alerts.
+
+### Response and remediation
+
+- Immediately block the IP address from which the failed login attempts originated to prevent further unauthorized access attempts.
+- Review the affected user accounts for any signs of successful unauthorized access or suspicious activity and reset passwords as necessary.
+- Enable multi-factor authentication (MFA) for all user accounts to add an additional layer of security against password spraying attacks.
+- Conduct a thorough investigation of the logs to identify any other IP addresses or accounts that may be involved in similar activities.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further analysis and response.
+- Implement or enhance logging policies to ensure comprehensive capture of authentication events, including both successful and failed login attempts.
+- Integrate threat intelligence feeds to identify known malicious IP addresses and enhance detection capabilities.
+- Educate users on the importance of using strong, unique passwords and the risks associated with password spraying attacks.
+- Restore any affected systems or accounts to their operational state by ensuring all security patches are applied and configurations are secure.
+- Review and update security policies and procedures to incorporate lessons learned from the incident and improve future response efforts.
+
+This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
 risk_score = 73
 rule_id = "3efee4f0-182a-40a8-a835-102c68a4175d"
 severity = "high"
diff --git a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
index f74a123e361..8771996d827 100644
--- a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
+++ b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Excessive Single Sign-On Logon Errors"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 O365 Excessive Single Sign-On Logon Errors
+
+Single Sign-On (SSO) streamlines user access across multiple applications using one set of credentials, enhancing user experience and security. However, adversaries may exploit SSO by attempting brute force attacks to gain unauthorized access. The detection rule monitors for unusual spikes in SSO logon errors, specifically targeting invalid or expired tokens, to identify potential brute force attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific account(s) associated with the excessive SSO logon errors, focusing on the `o365.audit.LogonError` field for "SsoArtifactInvalidOrExpired".
+- Check the timestamp of the logon errors to determine if there is a pattern or specific time frame when the errors occurred.
+- Investigate the source IP addresses associated with the logon attempts to identify any unusual or suspicious locations, using the `event.dataset` and `event.provider` fields for context.
+- Correlate the identified IP addresses with known threat intelligence sources to check for any malicious activity or reputation.
+- Examine the user account's recent activity logs for any other anomalies or unusual behavior, such as logins from different geographic locations or changes in user settings.
+- Use Osquery to gather additional context on the affected systems. For example, run a query to list recent login attempts: `SELECT * FROM logon_sessions WHERE logon_type = 'SSO' AND status = 'failed';`
+- Analyze the frequency and volume of the logon errors to determine if they align with typical brute force attack patterns.
+- Check for any recent changes in the user's account settings or permissions that could have triggered the errors.
+- Investigate if there are any other accounts experiencing similar logon errors, which could indicate a broader attack.
+- Review any recent security updates or changes in the SSO configuration that might have inadvertently caused the logon errors.
+
+### False positive analysis
+
+- Users with expired passwords or tokens may trigger excessive SSO logon errors, leading to false positives. Regularly updating credentials and tokens can help mitigate this issue.
+- Automated scripts or applications using outdated credentials can cause repeated logon errors. Ensure that all automated processes are updated with current credentials to prevent unnecessary alerts.
+- Users frequently accessing multiple applications simultaneously might experience token expiration, resulting in logon errors. Consider extending token expiration times for specific users or applications to reduce false positives.
+- Network latency or connectivity issues can lead to repeated logon attempts and errors. Monitoring network performance and addressing connectivity issues can help minimize these occurrences.
+- Implement exception rules for known non-threatening behaviors, such as specific users or IP addresses that consistently generate logon errors due to legitimate reasons, to prevent them from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected accounts to prevent further unauthorized access and reset their passwords.
+- Review the logs for the affected accounts to identify any successful logins or suspicious activities following the logon errors.
+- Conduct a thorough investigation to determine if the logon errors are part of a broader brute force attack or if they are isolated incidents.
+- Escalate the incident to the security operations center (SOC) or incident response team if there is evidence of a coordinated attack or if sensitive data may have been accessed.
+- Implement multi-factor authentication (MFA) for all users to add an additional layer of security against brute force attacks.
+- Enhance logging policies to ensure detailed records of authentication attempts and errors are captured for future analysis.
+- Integrate threat intelligence feeds to correlate logon errors with known malicious IP addresses or threat actors.
+- Educate users on recognizing phishing attempts and the importance of using strong, unique passwords to reduce the risk of credential compromise.
+- Restore affected systems and accounts to their operational state by ensuring all security patches are applied and configurations are hardened.
+- Regularly review and update security policies and procedures to address any gaps identified during the investigation and to improve the organization's overall security posture.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 73
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
index 77bc6a6dfa9..9c0d0481195 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange DLP Policy Removed"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange DLP Policy Removed
+
+Microsoft 365 Exchange DLP policies are crucial for preventing unauthorized data sharing by monitoring and controlling sensitive information flow. Adversaries may remove these policies to bypass data protection measures, facilitating data exfiltration. The detection rule identifies successful removal actions by analyzing specific audit events, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `o365.audit`, the event provider is `Exchange`, and the event action is `Remove-DlpPolicy` with a successful outcome.
+- Correlate the timestamp of the alert with other logs to identify any concurrent suspicious activities or anomalies in the environment.
+- Identify the user account associated with the `Remove-DlpPolicy` action and verify if the account has legitimate reasons or permissions to perform such actions.
+- Check the user's recent activity logs for any unusual or unauthorized actions, such as changes in permissions or access to sensitive data.
+- Investigate the IP address and location from which the `Remove-DlpPolicy` action was initiated to determine if it aligns with the user's typical access patterns.
+- Examine the audit logs for any preceding failed attempts to remove DLP policies, which might indicate persistent attempts to bypass security controls.
+- Utilize Osquery to gather additional context on the user's device by running a query such as: `SELECT * FROM users WHERE username = '<suspicious_user>';` to check for any anomalies or unauthorized software.
+- Review the organization's change management records to verify if the DLP policy removal was part of an approved change request.
+- Analyze any recent changes to the organization's security policies or configurations that might have inadvertently allowed the DLP policy removal.
+- Consult with the security team to determine if there are any ongoing investigations or incidents that might be related to the DLP policy removal event.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may remove DLP policies as part of regular maintenance or updates, which can trigger false positives. To manage this, organizations can create exceptions for known administrative accounts or schedule maintenance windows where such actions are expected.  
+- Policy updates and migrations: During policy updates or migrations, DLP policies might be temporarily removed and reconfigured, leading to false positives. Users can handle this by documenting and excluding these activities during planned update periods.  
+- Testing and development environments: In testing or development environments, DLP policies may be frequently added and removed for testing purposes. To reduce false positives, these environments can be excluded from monitoring or flagged as low-risk.  
+- Automated scripts or tools: Automated processes that manage DLP policies might inadvertently trigger the rule. Identifying and excluding these scripts or tools from monitoring can help minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further unauthorized actions and assess if any other accounts have been compromised.
+- Review audit logs to identify the scope of the policy removal, including the user who performed the action and any associated IP addresses or devices.
+- Reapply the removed DLP policy and verify that all other DLP policies are intact and functioning as expected.
+- Conduct a thorough investigation to determine if any sensitive data was exfiltrated during the period the DLP policy was inactive.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this action is part of a larger attack.
+- Implement enhanced logging and monitoring for DLP policy changes, ensuring that alerts are generated for any future modifications.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate this event with other suspicious activities across the network.
+- Educate users on the importance of DLP policies and the risks associated with unauthorized changes to these policies.
+- Restore any affected systems to their operational state by ensuring all security configurations are correctly applied and verified.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify DLP policies, reducing the risk of future unauthorized changes.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
index ec5a1d9bbc5..2c98367720f 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Malware Filter Policy Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Malware Filter Policy Deletion
+
+Microsoft 365 Exchange uses malware filter policies to detect and alert administrators about emails containing malware, which helps in identifying potential account or machine compromises. Adversaries may delete these policies to bypass detection mechanisms, facilitating undetected malicious activities. The detection rule monitors audit logs for successful deletions of these policies, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:"Remove-MalwareFilterPolicy" to confirm the deletion event and gather details such as the timestamp, user account involved, and the IP address from which the action was performed.
+- Cross-reference the user account identified in the deletion event with recent login activity to determine if there are any unusual or suspicious login patterns, such as logins from unfamiliar locations or IP addresses.
+- Investigate the event.outcome:success field to ensure that the deletion was indeed successful and not a failed attempt, which might indicate a different type of issue or misconfiguration.
+- Examine the event.provider:Exchange and event.category:web fields to verify that the event is correctly categorized and associated with the Exchange service, ensuring the alert is not a false positive.
+- Utilize Osquery to gather additional context on the user account involved in the deletion. For example, run a query to list recent activities by the user: `SELECT * FROM users WHERE username = 'suspected_user';`
+- Check for any recent changes to permissions or roles associated with the user account to determine if they were granted elevated privileges that could have allowed the policy deletion.
+- Investigate other security logs and alerts around the same timeframe to identify any correlated events or activities that might indicate a broader attack or compromise.
+- Review the organization's change management records to verify if the deletion was part of an authorized change or maintenance activity, potentially ruling out malicious intent.
+- Analyze email logs to identify any recent emails sent by the user account that might have contained malware, which could suggest a motive for deleting the malware filter policy.
+- Consult with other security team members or stakeholders to gather additional insights or context that might aid in understanding the significance of the policy deletion and any potential impact on the organization.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may delete malware filter policies as part of regular maintenance or policy updates. To manage this, organizations can create exceptions for known administrative accounts or schedule maintenance windows where such activities are expected.
+- Policy reconfiguration: During reconfiguration or migration of policies, deletions might occur as part of the process. Users can handle these by documenting and approving such changes in advance, allowing for temporary exceptions during the reconfiguration period.
+- Testing and development environments: In environments where policies are frequently created and deleted for testing purposes, these actions might trigger false positives. To mitigate this, users can exclude specific test accounts or environments from the detection rule.
+- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage their Microsoft 365 environment, which might include policy deletions. Identifying and excluding these scripts or tools from the detection rule can help reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate affected accounts or systems to prevent further malicious activity and contain the threat.
+- Review audit logs and email logs to identify any other suspicious activities or policy deletions that may indicate a broader compromise.
+- Conduct a thorough investigation to determine the scope of the compromise, including identifying any other compromised accounts or systems.
+- Restore the deleted malware filter policy from a backup or recreate it to ensure continued protection against malware threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for Microsoft 365 Exchange to detect similar activities in the future, ensuring audit logs are retained for an appropriate duration.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Educate users and administrators on recognizing phishing attempts and the importance of maintaining security policies.
+- Apply security patches and updates to all systems and applications to mitigate vulnerabilities that could be exploited by adversaries.
+- Review and strengthen access controls and permissions to ensure that only authorized personnel can modify or delete security policies.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
index 3a8e0b5063c..12743ce2a87 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,52 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Malware Filter Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Malware Filter Rule Modification
+
+Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to delete or disable these rules to bypass security measures, facilitating the delivery of harmful payloads. The detection rule monitors audit logs for successful actions that remove or disable malware filter rules, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific `event.action` values "Remove-MalwareFilterRule" or "Disable-MalwareFilterRule" to confirm the alert's validity and gather initial context.
+- Examine the `event.outcome` field to ensure the action was successful, as unsuccessful attempts may indicate a different type of issue or misconfiguration.
+- Identify the `event.provider` and `event.category` fields to confirm that the event is related to Exchange and web activities, ensuring the alert is relevant to the Microsoft 365 environment.
+- Investigate the user account associated with the action by reviewing the `user.name` and `user.id` fields to determine if the account is legitimate or potentially compromised.
+- Check the `source.ip` and `source.geo.location` fields to identify the origin of the action, looking for unusual or unexpected locations that might indicate unauthorized access.
+- Analyze the `event.time` field to establish a timeline of events, correlating with other security events or anomalies that occurred around the same time.
+- Use Osquery to further investigate the user account and device involved. For example, run a query to list recent logins: `SELECT * FROM users WHERE username = 'suspicious_user';`
+- Review any recent changes to permissions or roles associated with the user account to determine if they have been granted elevated privileges that could facilitate such actions.
+- Cross-reference the alert with other security tools and logs, such as endpoint protection or network monitoring, to identify any related suspicious activities or patterns.
+- Consult with the IT or security team to verify if the action was part of a legitimate administrative task or change management process, potentially ruling out malicious intent.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may occasionally remove or disable malware filter rules as part of regular maintenance or updates, which can trigger false positives. 
+- Policy updates: Changes in organizational security policies might necessitate the modification of malware filter rules, leading to alerts that are not indicative of malicious activity.
+- Testing and troubleshooting: Security teams may disable or remove rules temporarily for testing or troubleshooting purposes, which can be mistaken for suspicious behavior.
+- To manage these false positives, organizations can implement exception lists that include known and trusted administrative accounts or IP addresses involved in regular maintenance activities.
+- Regularly review and update the exception lists to ensure they reflect current administrative practices and personnel changes, minimizing unnecessary alerts.
+- Implement a change management process that logs and approves legitimate rule modifications, providing context for alerts and reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately isolate affected accounts or systems to prevent further unauthorized changes to malware filter rules.
+- Conduct a thorough investigation to identify the source of the modification, including reviewing audit logs and correlating with other security events.
+- Verify the integrity of other security configurations and rules within Microsoft 365 to ensure no additional unauthorized changes have been made.
+- Restore the deleted or disabled malware filter rules from backups or recreate them based on documented configurations.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for Microsoft 365, focusing on changes to security configurations and rules.
+- Integrate threat intelligence feeds to correlate with observed activities and identify potential indicators of compromise.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify security rules.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
+- Educate and train staff on recognizing and reporting suspicious activities related to security rule modifications.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
index 9d9933ff325..6decdea9f6a 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Safe Attachment Rule Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Safe Attachment Rule Disabled
+
+Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect malware. Disabling this rule can expose organizations to threats, as it allows potentially harmful attachments to bypass scrutiny. Adversaries may exploit this by disabling the rule to facilitate data exfiltration or evade detection. The detection rule monitors audit logs for successful attempts to disable this feature, alerting security teams to potential misuse.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "Disable-SafeAttachmentRule" to confirm the alert's validity and gather initial context.
+- Identify the user account associated with the event by examining the user information in the audit logs, focusing on the event.dataset:o365.audit and event.provider:Exchange fields.
+- Check the event.outcome field to ensure the action was successful, confirming that the rule was indeed disabled.
+- Investigate the timing of the event by analyzing the timestamp to determine if it coincides with any other suspicious activities or known incidents.
+- Correlate the event with other logs or alerts around the same timeframe to identify any patterns or additional suspicious activities.
+- Examine the user's recent activity history in Microsoft 365 to identify any unusual behavior or deviations from their normal activity patterns.
+- Use Osquery to gather more information about the user's device and recent activities. For example, run a query to list recent logins: `SELECT * FROM users WHERE username = 'suspected_user';`
+- Investigate any recent changes to security settings or configurations in Microsoft 365 that might indicate a broader attempt to impair defenses.
+- Check for any other recent successful or failed attempts to disable security features in Microsoft 365, which could indicate a larger attack strategy.
+- Collaborate with other security team members to cross-reference findings with threat intelligence sources to determine if the activity aligns with known threat actor behaviors or tactics.
+
+### False positive analysis
+
+- Routine administrative actions: Sometimes, IT administrators may disable the Safe Attachment Rule temporarily for maintenance or troubleshooting purposes. These actions, while legitimate, can trigger alerts. To manage this, organizations can create exceptions for specific user accounts or IP addresses known to perform these tasks regularly.
+- Automated scripts or tools: Certain automated processes or third-party tools might disable the rule as part of their operation. Identifying these tools and excluding their actions from alerts can reduce false positives.
+- Policy updates or changes: During policy updates or configuration changes, the rule might be disabled as part of the process. Documenting these changes and excluding them from alerts can help in managing false positives.
+- Testing environments: In testing or development environments, the rule might be disabled to simulate scenarios or test new configurations. Excluding these environments from monitoring can prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately re-enable the Safe Attachment Rule in Microsoft 365 to restore protection against malicious attachments.
+- Conduct a thorough investigation to identify the user or account responsible for disabling the rule and assess their access privileges.
+- Review audit logs to determine the scope of potential exposure and identify any suspicious activities or data exfiltration attempts.
+- Isolate any systems or accounts that may have been compromised to prevent further unauthorized access or data loss.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement additional logging and monitoring to capture detailed events related to email security settings and rule changes.
+- Integrate threat intelligence feeds to enhance detection capabilities and correlate with known threat actor behaviors.
+- Educate employees on the importance of email security and the risks associated with disabling security features.
+- Restore any affected systems to a known good state and apply security patches and updates to mitigate vulnerabilities.
+- Review and update security policies and procedures to include regular audits of security configurations and rule settings.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
index c702bee9a9c..e0945e59b03 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/13"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Mailbox Audit Logging Bypass"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 O365 Mailbox Audit Logging Bypass
+
+O365 Mailbox Audit Logging is crucial for tracking mailbox activities, ensuring transparency and security. However, bypass associations can be configured to exclude certain accounts from logging, often for operational efficiency. Adversaries exploit this by adding malicious accounts to the bypass list, concealing their actions. The detection rule identifies successful bypass configurations, signaling potential abuse by monitoring specific audit events.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific account associated with the `Set-MailboxAuditBypassAssociation` event and verify the `event.outcome:success` field to confirm the bypass was successfully configured.
+- Cross-reference the account in question with known authorized accounts that may have legitimate reasons for bypassing audit logging, such as service accounts or accounts used by third-party tools.
+- Examine the `event.dataset:o365.audit` and `event.provider:Exchange` fields to gather additional context about the environment and the specific actions taken.
+- Investigate recent activities associated with the account by querying O365 audit logs for any unusual or unauthorized actions that might have been performed by the account.
+- Utilize Osquery to gather additional information about the system and user activities. For example, run a query to list recent login events: `SELECT * FROM users WHERE username = 'suspicious_account';`.
+- Check for any recent changes in permissions or roles for the account in question that might indicate privilege escalation or unauthorized access.
+- Analyze the timeline of events leading up to the bypass configuration to identify any preceding suspicious activities or anomalies.
+- Investigate any other accounts that have been added to the bypass list recently to determine if there is a pattern or coordinated effort to conceal malicious activities.
+- Review the organization's policy and documentation regarding audit logging bypass to ensure the configuration aligns with operational requirements and security policies.
+- Consult with the IT or security team to verify if there were any legitimate operational needs or changes that could justify the bypass configuration for the account.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate administrative actions where certain accounts are intentionally added to the bypass list for operational efficiency, such as service accounts used by third-party applications or monitoring tools that generate excessive log entries.
+- To manage these false positives, organizations can create exceptions by maintaining a documented list of approved accounts that are allowed to bypass audit logging. This list should be regularly reviewed and updated to ensure it only includes accounts necessary for business operations.
+- Implementing a review process for any changes to the bypass list can help distinguish between legitimate and potentially malicious modifications, reducing the risk of overlooking unauthorized actions.
+- Users should consider correlating bypass events with other security logs and alerts to verify the legitimacy of the bypass configuration, ensuring that it aligns with expected behavior and does not coincide with other suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected accounts by removing them from the bypass list to prevent further unauthorized actions.
+- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities associated with the affected accounts.
+- Review and validate the list of accounts with bypass associations to ensure only legitimate accounts are included.
+- Escalate the incident to the security operations team for a deeper analysis of potential compromise and to assess the scope of the breach.
+- Implement enhanced logging policies to capture detailed audit logs for all accounts, including those with bypass associations, to improve visibility.
+- Integrate security information and event management (SIEM) tools to correlate audit logs with other security events for comprehensive threat detection.
+- Restore any altered or deleted mailbox data from backups to ensure data integrity and continuity of operations.
+- Apply security patches and updates to the O365 environment to mitigate any known vulnerabilities that could be exploited.
+- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
+- Educate and train administrators on the risks associated with audit logging bypass and the importance of maintaining strict access controls.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://twitter.com/misconfig/status/1476144066807140355"]
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
index b000de68c75..6700bf68169 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Transport Rule Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Transport Rule Creation
+
+Microsoft 365 Exchange transport rules manage email flow and apply specific actions to messages. Adversaries may exploit these rules to redirect emails to external domains, facilitating data exfiltration. The detection rule monitors successful creation of new transport rules, focusing on web-based actions within Exchange, to identify potential misuse indicative of such malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.action field with the value "New-TransportRule" and ensure the event.outcome is marked as success.
+- Examine the event.dataset field to verify it is set to o365.audit and the event.provider field is Exchange, confirming the source of the alert.
+- Check the event.category field for the value web to ensure the rule creation was performed through a web-based interface, which might indicate unauthorized access.
+- Identify the user account associated with the transport rule creation by reviewing the user.name or user.id fields in the alert details.
+- Investigate the IP address from which the transport rule was created using the source.ip field to determine if it is from a known or suspicious location.
+- Analyze the transport rule's configuration, focusing on any actions that forward emails to external domains, which could indicate data exfiltration attempts.
+- Review recent login activities for the user account involved, looking for unusual patterns or locations, using Microsoft 365 audit logs.
+- Use Osquery to gather additional context on the user account and recent activities. Example query: `SELECT * FROM users WHERE username = '<user.name from alert>';`
+- Check for any other recent changes in the Microsoft 365 environment, such as modifications to user permissions or other transport rules, that could be related to the alert.
+- Correlate this alert with other security events or alerts in your environment to identify potential patterns or coordinated activities that might indicate a broader attack.
+
+### False positive analysis
+
+- Legitimate administrative activities: IT administrators may create transport rules for valid business purposes, such as managing email flow or applying compliance policies. Regular audits and communication with the IT team can help distinguish between legitimate and suspicious rule creations.
+- Automated system processes: Some automated systems or third-party applications integrated with Microsoft 365 might create transport rules as part of their normal operation. Identifying these systems and documenting their expected behavior can help in excluding them from alerts.
+- Testing and development environments: Transport rules might be created frequently in testing or development environments as part of routine testing procedures. Excluding these environments from monitoring or setting up specific alerts for production environments only can reduce false positives.
+- Organizational changes: During mergers, acquisitions, or organizational restructuring, transport rules may be created to facilitate email redirection and communication. Understanding the context of these changes and temporarily adjusting monitoring criteria can help manage false positives.
+- To handle these false positives, users can create exceptions for known non-threatening behaviors by maintaining an allowlist of trusted administrators, systems, and environments. Regularly updating this list and reviewing transport rule creation logs can ensure that only suspicious activities trigger alerts.
+
+### Response and remediation
+
+- Immediately disable the newly created transport rule to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the source of the rule creation, including reviewing audit logs for suspicious activities around the time of the rule creation.
+- Verify if any data was exfiltrated by analyzing email logs and any external communications initiated by the transport rule.
+- Escalate the incident to the security operations team for a deeper analysis and to determine if other systems or accounts have been compromised.
+- Reset credentials and enforce multi-factor authentication for any accounts involved in the incident to prevent unauthorized access.
+- Implement stricter transport rule policies to prevent the creation of rules that forward emails to external domains without proper authorization.
+- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities in the future.
+- Conduct a security awareness training session for administrators to recognize and respond to suspicious activities related to transport rules.
+- Restore the system to its operational state by ensuring all unauthorized changes are reverted and verifying the integrity of the email system.
+- Apply hardening measures such as restricting administrative access to the Exchange management interface and regularly reviewing transport rule configurations.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
index 1d3f8d6595f..1ae057908ae 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Transport Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Transport Rule Modification
+
+Microsoft 365 Exchange transport rules manage email flow by applying specific actions to messages. Adversaries may exploit these rules to disable or delete them, facilitating data exfiltration or bypassing security measures. The detection rule monitors successful actions of rule removal or disabling, signaling potential misuse by tracking specific event categories and actions within the audit logs.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.dataset is "o365.audit" and the event.provider is "Exchange" to ensure the alert is related to Microsoft 365 Exchange.
+- Verify the event.category is "web" and the event.action is either "Remove-TransportRule" or "Disable-TransportRule" to confirm the specific actions that triggered the alert.
+- Check the event.outcome field to ensure the action was successful, indicating that a transport rule was indeed removed or disabled.
+- Identify the user account associated with the action by examining the user.name or user.id fields in the audit logs to determine if the action was performed by an authorized user or a potential adversary.
+- Investigate the timestamp of the event to establish a timeline and correlate it with other suspicious activities or anomalies in the environment.
+- Examine the source IP address and location from which the action was performed to identify any unusual or unauthorized access patterns.
+- Review the history of changes to transport rules in the audit logs to identify any patterns or repeated attempts to modify rules by the same user or IP address.
+- Utilize Osquery to gather additional context on the user account involved. For example, run a query to list recent login activities: `SELECT * FROM users WHERE username = '<user.name>'`.
+- Cross-reference the identified user account and IP address with known threat intelligence sources to check for any associations with malicious activity.
+- Investigate any related email flow logs to determine if there was any data exfiltration or unauthorized email forwarding that coincided with the transport rule modification.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may regularly disable or remove transport rules as part of routine maintenance or updates. To manage these, organizations can create exceptions for specific user accounts or roles known to perform these tasks frequently.
+- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage transport rules, which might trigger the detection rule. Users can handle these by identifying and excluding the specific scripts or tools from the monitoring process.
+- Testing and development environments: Changes in transport rules might occur frequently in testing or development environments. To reduce false positives, users can exclude these environments from the detection scope or adjust the rule to focus on production environments only.
+- Scheduled policy updates: Organizations may have scheduled updates to transport rules that coincide with policy changes or compliance requirements. Users can manage these by documenting the schedule and creating temporary exceptions during these periods.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts and systems to prevent further unauthorized actions.
+- Conduct a thorough investigation to determine the scope of the rule modification, identifying any data exfiltration or security bypass attempts.
+- Review audit logs to trace the origin of the modification, focusing on user activity and access patterns around the time of the event.
+- Re-enable or recreate the disabled or deleted transport rules to restore email flow security measures.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed user actions and changes to transport rules for future monitoring.
+- Integrate additional security tools, such as SIEM solutions, to correlate events and improve detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update policies or procedures as necessary.
+- Educate users on security best practices and the importance of maintaining transport rule integrity.
+- Apply hardening measures, such as multi-factor authentication and least privilege access, to reduce the risk of unauthorized modifications.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
index ad5ac070602..014db96c20b 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2023/06/22"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -13,7 +13,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Mass download by a single user"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Mass download by a single user
+
+Microsoft 365's cloud services facilitate seamless data access and collaboration. However, adversaries may exploit these capabilities to exfiltrate data by downloading large volumes rapidly. The detection rule identifies suspicious activity by flagging instances where a user downloads over 50 files in a minute, leveraging audit logs to pinpoint potential data exfiltration attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `SecurityComplianceCenter`, ensuring the alert is genuine and not a false positive.
+- Verify the event category is `web` and the event action is "Mass download by a single user" to confirm the nature of the activity.
+- Check the event outcome to ensure it is marked as `success`, indicating the downloads were completed.
+- Identify the user account involved in the mass download and gather additional context about the user's role and typical behavior within the organization.
+- Analyze the time and date of the downloads to determine if they coincide with any known business activities or if they occurred during unusual hours.
+- Investigate the IP address and location from which the downloads were initiated to assess if they align with the user's normal access patterns.
+- Examine the types and sensitivity of the files downloaded to evaluate the potential impact of the data exfiltration.
+- Use Osquery to gather more information about the user's device, such as running processes or recent network connections, with a query like: `SELECT * FROM processes WHERE user = '<username>';`
+- Review recent login activity for the user in Microsoft 365 to identify any anomalies or unauthorized access attempts.
+- Cross-reference the user's activity with other security logs and alerts to identify any correlated suspicious behavior or potential indicators of compromise.
+
+### False positive analysis
+
+- Legitimate business activities: Users involved in data-intensive roles, such as data analysts or IT administrators, may legitimately download large volumes of files for business purposes. These activities can be mistaken for suspicious behavior.
+- Automated processes: Scheduled scripts or automated tools that download files for backup or synchronization purposes can trigger the rule. These processes are typically non-threatening and should be reviewed for legitimacy.
+- Software updates: IT departments may download software updates or patches in bulk, which can result in a high number of downloads within a short period.
+- Training or onboarding sessions: New employees or users undergoing training may download numerous files as part of their onboarding process or training materials.
+- To manage false positives, organizations can create exceptions for known users or processes that regularly perform high-volume downloads. This can be done by maintaining a whitelist of users or IP addresses associated with legitimate activities. Additionally, reviewing and updating the detection rule parameters to better align with the organization's typical usage patterns can help reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further data exfiltration.
+- Review the audit logs to confirm the scope of the downloads and identify any other potentially compromised accounts.
+- Conduct a thorough investigation to determine if the downloads were authorized or if they indicate malicious activity.
+- If malicious activity is confirmed, reset the affected user's password and enforce multi-factor authentication (MFA) for all users.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed user activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Review and update data access policies to ensure that only necessary permissions are granted to users.
+- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials.
+- Restore any affected systems or data from backups if data integrity is compromised.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
index d249e245d1a..96619440cb4 100644
--- a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
+++ b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Potential ransomware activity"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Potential ransomware activity
+
+Microsoft 365's Cloud App Security monitors user activities to identify potential ransomware threats, such as suspicious file uploads. Adversaries may exploit cloud storage to distribute or store ransomware, encrypting data for impact. The detection rule leverages audit logs to flag successful web actions linked to ransomware, aligning with MITRE ATT&CK's impact tactics, ensuring timely threat identification and response.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.dataset is "o365.audit" and the event.provider is "SecurityComplianceCenter" to ensure the alert is from a legitimate source.
+- Verify the event.category is "web" and the event.action is "Potential ransomware activity" to confirm the nature of the alert.
+- Check the event.outcome field to ensure it is marked as "success," indicating the action was completed and potentially harmful.
+- Identify the user account involved in the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the timestamp of the alert to correlate with other security events or anomalies that may have occurred around the same time.
+- Investigate the specific files uploaded by the user by reviewing file names, types, and sizes to identify any unusual or suspicious characteristics.
+- Utilize Osquery to gather additional context on the user's activity. For example, run a query to list recent file modifications: `SELECT * FROM file WHERE path LIKE '/path/to/suspected/files/%';`
+- Cross-reference the user's IP address and location with known locations for the user to identify any discrepancies or unusual access patterns.
+- Analyze audit logs for any other recent activities by the same user that may indicate a broader pattern of suspicious behavior.
+- Collaborate with other security teams to gather additional intelligence or context on the potential ransomware activity, leveraging threat intelligence feeds if available.
+
+### False positive analysis
+
+- Legitimate file uploads by users, such as regular backups or large data transfers, may trigger the rule as potential ransomware activity due to the volume or nature of the files.
+- Automated processes or scripts that upload files to the cloud as part of routine operations can be mistakenly flagged as ransomware activity.
+- Users can manage these false positives by creating exceptions for known safe activities, such as whitelisting specific users or processes that regularly perform large uploads.
+- Implementing a review process for flagged activities can help distinguish between genuine threats and benign actions, allowing for more accurate threat detection.
+- Regularly updating the list of exceptions based on user feedback and activity patterns can reduce the occurrence of false positives over time.
+
+### Response and remediation
+
+- Immediately isolate the affected user account and device from the network to prevent further spread of the ransomware.
+- Conduct a thorough investigation of the audit logs to identify the scope of the ransomware activity and determine if other accounts or systems are compromised.
+- Remove any identified malicious files from the cloud storage and ensure they are quarantined for further analysis.
+- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional resources are needed.
+- Restore any encrypted or compromised files from the most recent clean backup to ensure data integrity and availability.
+- Implement or review existing logging policies to ensure comprehensive monitoring of user activities and cloud interactions for early detection of similar threats.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to enhance visibility and response capabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users on recognizing phishing attempts and suspicious activities to reduce the risk of future ransomware infections.
+- Apply security hardening measures, such as enabling multi-factor authentication (MFA) and ensuring all systems are patched and up-to-date, to mitigate potential vulnerabilities.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
index 91ff9f58844..0f874db7647 100644
--- a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
+++ b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -13,7 +13,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Unusual Volume of File Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Unusual Volume of File Deletion
+
+Microsoft 365's cloud services facilitate collaboration and data management, but adversaries can exploit these features to delete large volumes of files, causing data loss. This detection rule leverages Microsoft Cloud App Security to identify and alert on such unusual file deletion activities, which may indicate malicious intent, aligning with MITRE ATT&CK's data destruction techniques.
+
+### Possible investigation steps
+
+- Review the alert details in Microsoft Cloud App Security to understand the scope and context of the unusual file deletion event.
+- Verify the user account involved in the deletion by examining the `event.dataset` and `event.provider` fields to ensure the activity is associated with Microsoft 365 and the Security Compliance Center.
+- Check the `event.category` and `event.action` fields to confirm that the activity is categorized as web-based and specifically flagged as "Unusual volume of file deletion."
+- Analyze the `event.outcome` field to ensure the deletion activity was successful, which may indicate a higher risk of data loss.
+- Investigate the user's recent activity logs in Microsoft 365 to identify any other suspicious actions or patterns that could suggest malicious intent.
+- Correlate the user's activity with any recent changes in permissions or access levels that might have facilitated the unusual file deletion.
+- Use Osquery to gather additional context on the user's device, such as running processes or network connections, to identify any signs of compromise. Example query: `SELECT * FROM processes WHERE user = 'username';`
+- Examine the user's login history and IP addresses to detect any anomalies or unauthorized access attempts that could be related to the file deletion.
+- Cross-reference the alert with other security tools and logs to identify any concurrent alerts or incidents that might be linked to the same user or activity.
+- Consult with the user or their manager to verify if the file deletion was intentional and authorized, or if it was unexpected and potentially malicious.
+
+### False positive analysis
+
+- Routine administrative tasks: Large file deletions may occur during regular maintenance or data management activities by IT administrators. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- User-initiated cleanups: Users may delete large volumes of files as part of personal data organization or cleanup efforts. Implement user education and awareness programs to ensure such activities are reported or logged appropriately.
+- Automated processes: Some automated workflows or third-party applications may perform bulk deletions as part of their normal operation. Identify and whitelist these processes to prevent unnecessary alerts.
+- Migration activities: During data migration projects, significant file deletions might occur as data is moved or reorganized. Coordinate with project teams to anticipate these events and adjust monitoring rules accordingly.
+- Shared drive management: In environments with shared drives, users may delete large numbers of files to manage storage space. Establish policies for shared drive management and incorporate them into exception handling procedures.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further unauthorized deletions and assess if the account has been compromised.
+- Conduct a thorough investigation to determine the scope of the deletion, including identifying the files deleted, the time frame, and any associated user activities.
+- Review audit logs and Microsoft Cloud App Security alerts to identify any other suspicious activities or patterns that may indicate a broader compromise.
+- Restore deleted files from backups or version history, ensuring data integrity and availability are maintained.
+- Escalate the incident to the security operations team if the deletion is determined to be part of a larger attack or if sensitive data is involved.
+- Implement stricter access controls and multi-factor authentication for users with permissions to delete large volumes of files.
+- Enhance logging and monitoring policies to ensure detailed tracking of file operations and user activities within Microsoft 365.
+- Integrate Microsoft 365 with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on recognizing phishing attempts and secure handling of credentials to prevent account compromise.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
index 19722674349..bbfbeb76dfe 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Anti-Phish Policy Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Anti-Phish Policy Deletion
+
+Microsoft 365's anti-phishing policies are crucial for enhancing email security by identifying and blocking phishing attempts. Adversaries may delete these policies to weaken defenses, facilitating phishing attacks. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity aimed at compromising email security.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the deletion event by filtering for `event.dataset:o365.audit` and `event.provider:Exchange` to ensure the event is related to Microsoft 365 Exchange.
+- Verify the `event.action:"Remove-AntiPhishPolicy"` to confirm that the action taken was indeed the removal of an anti-phishing policy.
+- Check the `event.outcome:success` field to ensure the deletion was successful, indicating a potential security concern.
+- Identify the user account associated with the deletion by examining the `user.name` field in the audit logs to determine if the action was performed by an authorized user.
+- Investigate the `source.ip` field to trace the IP address from which the deletion request originated, helping to identify if it was an internal or external source.
+- Cross-reference the `user.name` and `source.ip` with known user activity and location to detect any anomalies or unauthorized access patterns.
+- Utilize Osquery to gather additional context on the user account and device involved. For example, run a query like `SELECT * FROM users WHERE username = '<user.name>'` to gather more information about the user.
+- Check for any recent changes in user permissions or roles that might have allowed the deletion by reviewing the `event.category:web` logs for any privilege escalation activities.
+- Analyze other related security events around the same timestamp to identify any correlated activities, such as failed login attempts or unusual email forwarding rules.
+- Review the organization's change management records to verify if the deletion was part of a planned change or if it was unauthorized, providing further context to the investigation.
+
+### False positive analysis
+
+- Routine administrative actions: Legitimate IT administrators may delete anti-phishing policies as part of regular maintenance or policy updates. These actions can be mistaken for malicious activity.
+- Policy reconfiguration: Organizations may periodically review and reconfigure their security policies, including anti-phishing settings, which could involve deleting and recreating policies.
+- Testing and audits: Security teams might delete policies temporarily during testing phases or audits to evaluate system responses and ensure compliance.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific time frames when policy changes are expected. This can be done by setting up filters or rules in the monitoring system to exclude these non-threatening activities from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate affected accounts and systems to prevent further unauthorized access or damage.
+- Review audit logs to identify the source and scope of the policy deletion, focusing on user accounts and IP addresses involved.
+- Recreate and apply the deleted anti-phishing policy to restore email security defenses.
+- Conduct a thorough investigation to determine if any phishing attacks were successful during the period the policy was absent.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for Microsoft 365 activities, ensuring that all policy changes are tracked and alerted.
+- Integrate threat intelligence feeds to correlate the incident with known phishing campaigns or threat actors.
+- Educate users on recognizing phishing attempts and the importance of reporting suspicious emails.
+- Review and update access controls and permissions to ensure only authorized personnel can modify security policies.
+- Consider deploying additional security measures such as multi-factor authentication (MFA) and advanced threat protection (ATP) to harden the environment against future attacks.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
index 71db20bf46d..b816965742e 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Anti-Phish Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Anti-Phish Rule Modification
+
+Microsoft 365's anti-phishing rules are crucial for enhancing email security by fine-tuning detection settings to thwart phishing attempts. Adversaries may exploit this by disabling or removing these rules, thus weakening defenses and facilitating phishing attacks. The detection rule monitors for successful actions that alter these rules, such as disabling or removing them, to identify potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.action field indicating "Remove-AntiPhishRule" or "Disable-AntiPhishRule" and ensure the event.outcome is marked as success.
+- Check the event.dataset field to verify it is set to o365.audit and the event.provider is Exchange, confirming the source of the alert.
+- Identify the user account associated with the modification by examining the user.name or user.id fields in the alert details.
+- Investigate the user's recent activity in Microsoft 365 to determine if there are any other suspicious actions or anomalies, such as unusual login times or locations.
+- Correlate the alert with other security events or logs, such as sign-in logs, to identify any potential compromise of the user's account.
+- Use Osquery to gather additional context on the user's device. For example, run a query to list recent processes executed by the user: `SELECT * FROM processes WHERE user = '<user_name>';`.
+- Examine the timestamp of the rule modification to determine if it coincides with any known phishing campaigns or other security incidents.
+- Review the organization's change management records to verify if the rule modification was authorized or part of a scheduled change.
+- Analyze email logs to identify any phishing emails that may have bypassed security controls following the rule modification.
+- Consult with the user or their manager to confirm whether the rule modification was intentional and authorized, and gather any additional context or insights.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may occasionally modify anti-phishing rules as part of regular maintenance or updates. These actions can trigger alerts but are not necessarily malicious.
+- Automated scripts: Some organizations use automated scripts to manage and update security settings, including anti-phishing rules. These scripts can generate alerts if they perform actions like disabling or removing rules.
+- Testing and audits: Security teams might intentionally modify anti-phishing rules to test system responses or during security audits, leading to false positives.
+- To manage these false positives, organizations can create exceptions for known administrative accounts or specific IP addresses associated with trusted IT personnel. Additionally, monitoring the context of the action, such as the time of day or associated user activity, can help differentiate between legitimate and suspicious modifications.
+
+### Response and remediation
+
+- Immediately isolate affected accounts or systems to prevent further unauthorized access or changes.
+- Review audit logs and identify any unauthorized modifications to anti-phishing rules, focusing on the "Remove-AntiPhishRule" or "Disable-AntiPhishRule" actions.
+- Verify the integrity of other security configurations and rules within Microsoft 365 to ensure no additional unauthorized changes have been made.
+- Restore any modified or removed anti-phishing rules to their original state using backup configurations or documented settings.
+- Conduct a thorough investigation to determine the source of the modification, including reviewing user activity and access permissions.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring policies to capture detailed information on future changes to security settings and rules.
+- Integrate additional security tools and services, such as Security Information and Event Management (SIEM) systems, to improve detection and response capabilities.
+- Educate users and administrators on the importance of maintaining security configurations and the risks associated with phishing attacks.
+- Apply hardening measures by enforcing multi-factor authentication (MFA) and least privilege access to reduce the risk of unauthorized modifications.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
index c0734782b56..1ec4d9a4fad 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Safe Link Policy Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Safe Link Policy Disabled
+
+Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats. Disabling these policies can expose users to malicious links, often used in phishing attacks to gain unauthorized access. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches by monitoring specific audit events in the Exchange environment.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.action:"Disable-SafeLinksRule" and event.outcome:success fields, ensuring the alert is valid and corresponds to a successful policy disablement.
+- Check the event.dataset:o365.audit and event.provider:Exchange fields to verify the source and context of the event, confirming it originated from the Microsoft 365 Exchange environment.
+- Identify the user or account associated with the action by examining the user information in the audit logs, focusing on any unusual or unauthorized accounts.
+- Investigate the timestamp of the event to determine when the policy was disabled and correlate it with other security events or anomalies around the same time.
+- Analyze the IP address and location data associated with the event to identify any suspicious or unexpected access patterns.
+- Review recent changes in the Microsoft 365 environment, including any new or modified user accounts, to identify potential unauthorized access or privilege escalation.
+- Utilize Osquery to gather additional context on the system where the action was initiated. Example query: `SELECT * FROM users WHERE username = 'suspicious_user';` to check for any unusual user accounts or activity.
+- Examine email logs and communication patterns of the involved user to identify any phishing attempts or suspicious emails that may have led to the policy being disabled.
+- Cross-reference the event with other security tools and logs, such as endpoint protection or network monitoring systems, to gather a comprehensive view of the incident.
+- Document all findings and maintain a timeline of events to assist in understanding the scope and potential impact of the policy disablement.
+
+### False positive analysis
+
+- Routine administrative tasks: IT administrators may disable Safe Link policies temporarily for testing or troubleshooting purposes, which can trigger false positives. To manage this, organizations can create exceptions for known administrative accounts or specific time frames when such activities are expected.
+- Policy updates or changes: During policy updates or configuration changes, Safe Link policies might be disabled as part of the process. To handle these, organizations can document and schedule these changes, allowing for temporary exclusions during maintenance windows.
+- Third-party integrations: Some third-party applications or services may require Safe Link policies to be disabled for compatibility reasons. In such cases, organizations should assess the risk and, if deemed safe, create exceptions for these specific applications or services.
+- User training sessions: Training sessions that involve demonstrating the disabling of Safe Link policies can also result in false positives. Organizations can mitigate this by scheduling these sessions and excluding them from monitoring during the training period.
+
+### Response and remediation
+
+- Immediately re-enable the Safe Link policy to restore phishing protection for users and prevent further exposure to malicious links.
+- Conduct a thorough investigation to identify the user or system account responsible for disabling the Safe Link policy by reviewing audit logs and correlating with other security events.
+- Isolate any affected systems or accounts to prevent further unauthorized access or potential spread of malicious activity.
+- Notify the security team and relevant stakeholders about the incident and provide them with details of the investigation and current status.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify security policies such as Safe Links.
+- Implement enhanced logging and monitoring for Microsoft 365 and Exchange environments to detect similar activities in the future, ensuring that audit logs are retained for an appropriate duration.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities for phishing and other related threats.
+- Conduct a security awareness training session for users to reinforce the importance of recognizing phishing attempts and reporting suspicious activities.
+- Restore any affected systems to their operational state by applying necessary patches, updates, and security configurations.
+- Implement hardening measures such as multi-factor authentication (MFA) and conditional access policies to reduce the risk of unauthorized access and enhance overall security posture.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
index 50b93ea0d00..0395688d557 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2024/09/05"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -16,7 +16,49 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Impossible travel activity"
-note = """
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Impossible travel activity
+
+Microsoft 365's security features monitor user sign-ins to detect anomalies like impossible travel, where logins occur from geographically distant locations in a short time. Adversaries may exploit compromised credentials to access accounts from various locations. The detection rule identifies such suspicious activities by analyzing audit logs for successful logins flagged as impossible travel, helping to pinpoint potential unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the "Impossible travel activity" event action and ensure the event outcome is marked as success.
+- Verify the user's recent login history to identify any patterns or anomalies in login locations and times, focusing on the event.dataset:o365.audit field.
+- Check the event.provider:SecurityComplianceCenter field to ensure the alert originated from a trusted source and is not a false positive.
+- Analyze the event.category:web field to understand the context of the login attempt, such as the application or service accessed.
+- Cross-reference the IP addresses involved in the login attempts with known malicious IP databases to identify any potential threats.
+- Use Osquery to gather additional context on the user's device by running a query like: `SELECT * FROM users WHERE username = '<username>';` to verify if the user account has been accessed from multiple devices.
+- Investigate any recent changes to the user's account settings or permissions that could indicate unauthorized access.
+- Review the user's activity logs for any unusual behavior or actions that could suggest account compromise.
+- Collaborate with the network team to trace the network path of the login attempt and identify any anomalies in network traffic.
+- Consult with the user to verify if they were traveling or using a VPN that could explain the impossible travel alert, ensuring the legitimacy of the login attempt.
+
+### False positive analysis
+
+- Known false positives for the Microsoft 365 Impossible travel activity rule often arise from legitimate users who travel frequently or use VPN services that route traffic through different geographic locations. These scenarios can trigger alerts as they mimic the behavior of compromised accounts accessing from various locations.
+- To manage these false positives, users can create exceptions for specific users or IP addresses that are known to frequently travel or use VPNs. This can be done by configuring conditional access policies or adjusting the sensitivity of the detection rule to better align with the organization's typical user behavior.
+- Another method to handle false positives is to integrate user behavior analytics (UBA) to establish a baseline of normal activity for each user. This allows the system to differentiate between legitimate and suspicious activities more accurately.
+- Organizations should regularly review and update their exception lists and detection rules to ensure they reflect current user behavior and network configurations, minimizing the risk of overlooking genuine threats while reducing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) for additional security.
+- Conduct a thorough investigation of the audit logs to identify any other suspicious activities or compromised accounts.
+- Review and analyze the sign-in history and patterns to determine if any other accounts exhibit similar impossible travel activities.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if there is a broader security breach.
+- Implement enhanced logging policies to capture detailed sign-in activities and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Educate users on recognizing phishing attempts and the importance of using strong, unique passwords to prevent credential compromise.
+- Restore the system to its operational state by ensuring all affected accounts are secured and any unauthorized changes are reverted.
+- Apply hardening measures such as restricting access based on geographic location and implementing conditional access policies.
+- Utilize MITRE ATT&CK framework to understand the adversary's tactics and techniques, and update security measures to mitigate similar threats in the future.
+
 ## Important
 
 This rule is no longer applicable based on changes to Microsoft Defender for Office 365. Please refer to the following rules for similar detections:
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
index 2f593839be0..fc0ab8aaa8f 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/09/25"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,50 @@ event.dataset: "o365.audit"
     and not o365.audit.UserId: "Not Available"
     and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Portal Logins from Impossible Travel Locations
+
+Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries who log in from disparate locations within short timeframes, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for successful access from different countries, flagging suspicious activity that aligns with known threat tactics like using valid accounts for unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account involved by examining the `o365.audit.UserId` field.
+- Verify the login locations by checking the IP addresses associated with the login events and cross-reference them with known locations for the user.
+- Analyze the timestamps of the login events to determine the time difference between the logins from different countries.
+- Check for any recent changes in the user's account settings or permissions that could indicate unauthorized access.
+- Investigate the `event.provider` and `event.action` fields to confirm the source and nature of the login events.
+- Use Osquery to gather additional context on the user's activity. For example, run a query to list recent login events: `SELECT * FROM o365_audit WHERE event_action = 'UserLoggedIn' AND user_id = '<UserId>' ORDER BY timestamp DESC LIMIT 10;`
+- Examine the `event.outcome` field to ensure that the logins were indeed successful and not failed attempts.
+- Look for any other suspicious activities associated with the user account, such as unusual file access or email forwarding rules.
+- Cross-reference the login events with known threat intelligence sources to identify any IP addresses or locations associated with malicious activity.
+- Collaborate with the user to verify if they were traveling or using a VPN service that could explain the login from an unexpected location.
+
+### False positive analysis
+
+- Frequent travelers or employees using VPNs may trigger false positives as they can appear to log in from different countries within a short timeframe. 
+- Users accessing Microsoft 365 services through corporate VPNs that route traffic through different countries can also be flagged as impossible travel.
+- To manage these false positives, organizations can create exceptions for known frequent travelers by maintaining a list of users who regularly travel and excluding their login events from the rule.
+- Implementing geolocation-based VPN detection can help differentiate between legitimate VPN use and suspicious activity.
+- Regularly updating the list of trusted IP addresses and locations can reduce false positives by allowing logins from these sources without triggering alerts.
+- Monitoring and correlating login events with travel itineraries or VPN usage logs can provide additional context to determine if an alert is a false positive.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) for additional security.
+- Conduct a thorough investigation of the login events to identify the source IP addresses and geolocations involved in the suspicious activity.
+- Review audit logs for any unauthorized changes or access to sensitive data during the period of compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement conditional access policies to restrict access based on geographic location and risk level.
+- Enhance logging policies to ensure comprehensive capture of authentication events and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Educate users on recognizing phishing attempts and the importance of using strong, unique passwords.
+- Restore any affected systems or data to their last known good state, ensuring no malicious artifacts remain.
+- Regularly review and update security policies and configurations to align with best practices and mitigate similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
index 7edab168de5..852b0982731 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/09/25"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,49 @@ event.dataset: "o365.audit"
     and not o365.audit.UserId: "Not Available"
     and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Portal Login from Rare Location
+
+Microsoft 365 is a cloud-based suite that facilitates collaboration and productivity. Adversaries may exploit it by logging in from uncommon locations, potentially using stolen credentials or VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access by analyzing login events and user location patterns.
+
+### Possible investigation steps
+
+- Review the login event details in the security logs to confirm the event dataset is "o365.audit" and the event provider is "AzureActiveDirectory" to ensure the alert is based on accurate data.
+- Verify the user account involved by checking the "o365.audit.UserId" field to determine if the account is legitimate and active.
+- Analyze the "event.outcome" field to confirm the login was successful, indicating potential unauthorized access.
+- Investigate the "event.action" field to ensure it matches "UserLoggedIn," confirming the nature of the event.
+- Examine the "o365.audit.Target.Type" field to understand the type of resource accessed, which can provide context on the potential impact.
+- Cross-reference the login location with known user travel patterns or VPN usage to determine if the location is indeed rare or expected.
+- Check historical login patterns for the user to identify any previous logins from the same location or similar unusual locations.
+- Use Osquery to gather additional context on the user's device, such as recent network connections or VPN usage, with a query like: `SELECT * FROM users WHERE username = '<UserId>';`
+- Investigate any recent changes to the user's account settings or permissions that could indicate account compromise.
+- Collaborate with the user or their manager to verify if the login was legitimate, potentially involving direct communication to confirm the user's activities.
+
+### False positive analysis
+
+- Users traveling for business or personal reasons may trigger false positives if they log in from locations not typically associated with their account. To manage this, organizations can create exceptions for known travel patterns or pre-approved travel destinations.
+- Employees using VPNs for legitimate purposes might appear to be logging in from rare locations. To handle this, IT teams can maintain a list of approved VPN IP addresses and exclude them from triggering alerts.
+- Remote workers who frequently change their physical location, such as digital nomads, may also cause false positives. Organizations can address this by identifying and documenting these users' typical movement patterns and adjusting the detection rule accordingly.
+- Temporary relocations, such as employees working from a different office or location for a short period, can be managed by setting temporary exceptions for these users during the specified timeframe.
+- Users accessing Microsoft 365 services through shared or public networks, like cafes or coworking spaces, might be flagged. To mitigate this, organizations can educate users on secure access practices and adjust the rule to account for these common access points.
+
+### Response and remediation
+
+- Verify the login attempt by contacting the user to confirm if the login was legitimate or unauthorized.
+- Temporarily suspend the user's account to prevent further unauthorized access if the login is confirmed to be suspicious.
+- Review the user's recent activity logs in Microsoft 365 to identify any other unusual or unauthorized actions.
+- Reset the user's password and enforce multi-factor authentication (MFA) to enhance account security.
+- Investigate the source IP address and location of the login attempt to determine if it correlates with known threat actors or VPN services.
+- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems are compromised.
+- Implement logging policies to ensure comprehensive capture of login events and user activities for future investigations.
+- Integrate threat intelligence feeds to enhance detection capabilities and correlate with known threat indicators.
+- Restore the user's account access once it is confirmed secure and provide guidance on recognizing phishing attempts and securing credentials.
+- Conduct a security awareness training session for users to reinforce the importance of account security and recognizing suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
index 9eb423152f7..a3ca1d0d20a 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -16,7 +16,52 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 User Restricted from Sending Email"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 User Restricted from Sending Email
+
+Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions on email sending, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "User restricted from sending email" to confirm the alert's validity and gather initial context.
+- Check the event.outcome field to ensure the restriction was successfully applied, indicating a potential misuse of the account.
+- Investigate the event.provider field to verify that the alert originated from the Security Compliance Center, ensuring the source's reliability.
+- Analyze the event.dataset field to confirm the data source is o365.audit, which provides relevant Microsoft 365 audit logs.
+- Examine the user's recent email activity to identify any unusual patterns or spikes in email sending that could have triggered the restriction.
+- Cross-reference the user's account details with known compromised accounts or recent security incidents to assess potential account compromise.
+- Utilize Osquery to gather additional context on the user's device and activity. For example, run the following query to check for recent login activities: `SELECT * FROM users WHERE username = 'affected_user';`
+- Investigate any recent changes to the user's account settings or permissions that could indicate unauthorized access or configuration changes.
+- Review the user's recent login history and IP addresses to identify any suspicious or unfamiliar access patterns.
+- Collaborate with other security tools and logs to correlate the user's activity with other potential indicators of compromise, such as phishing attempts or malware alerts.
+
+### False positive analysis
+
+- Legitimate high-volume senders such as marketing or customer service teams may trigger sending limits due to their normal operational activities. 
+- Automated systems or applications that send bulk emails for notifications or alerts might also be restricted, even though they are performing expected tasks.
+- Users who are part of email campaigns or newsletters might exceed limits if not properly configured or if there is a sudden increase in email volume.
+- To manage these false positives, organizations can create exceptions for known high-volume senders by adjusting their sending limits within Microsoft 365 settings.
+- Implementing monitoring and alerting for unusual spikes in email activity can help differentiate between legitimate high-volume sending and potential misuse.
+- Regularly reviewing and updating the list of users or systems with exceptions can ensure that only authorized entities are allowed higher sending limits, reducing the risk of abuse.
+
+### Response and remediation
+
+- Verify the legitimacy of the account activity by contacting the user to confirm if they were aware of the email sending activity.
+- Temporarily disable the compromised account to prevent further unauthorized access and email sending.
+- Conduct a thorough investigation of the account's recent activities, including login locations and times, to identify any suspicious behavior or unauthorized access.
+- Reset the password of the compromised account and enforce multi-factor authentication (MFA) to enhance security.
+- Review and analyze email logs to identify any recipients of potentially malicious emails sent from the compromised account and notify them to prevent further spread.
+- Escalate the incident to the security operations team for a deeper analysis of potential lateral movement or additional compromised accounts.
+- Implement enhanced logging and monitoring policies to capture detailed audit logs for email activities and account access.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the account to operational status only after confirming that it is secure and no longer compromised.
+- Educate users on recognizing phishing attempts and the importance of reporting suspicious emails to prevent future incidents.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
index 0b96dcaff21..53860d357cc 100644
--- a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
+++ b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/12"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,52 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Email Reported by User as Malware or Phish"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 O365 Email Reported by User as Malware or Phish
+
+Office 365 (O365) provides email services that are crucial for business communication but can be exploited by adversaries through phishing attacks to gain unauthorized access. Users reporting suspicious emails help identify potential threats that bypass security measures. The detection rule leverages audit logs from the Security Compliance Center to flag emails reported as malicious, enabling swift investigation and response to phishing attempts.
+
+### Possible investigation steps
+
+- Review the alert details in the Security Compliance Center to gather initial information, focusing on the `event.dataset:o365.audit`, `event.provider:SecurityComplianceCenter`, and `event.action:AlertTriggered` fields to confirm the alert's legitimacy.
+- Identify the user who reported the email and gather context on their role and typical email activity to assess the potential impact of the threat.
+- Examine the reported email's metadata, including sender address, subject line, and timestamp, to identify any patterns or anomalies that could indicate a phishing attempt.
+- Cross-reference the sender's email address and domain against known threat intelligence sources to determine if they are associated with previous phishing campaigns.
+- Analyze the email headers and body for suspicious links or attachments, using tools to safely extract and inspect these elements for malicious content.
+- Utilize Osquery to investigate the user's device for any signs of compromise or unusual activity. Example query: `SELECT * FROM processes WHERE name LIKE '%outlook%' AND user = '<username>';` to check for any suspicious processes related to email activity.
+- Check the organization's email gateway logs for any other instances of emails from the same sender or domain to determine if this is an isolated incident or part of a broader campaign.
+- Investigate any other alerts or incidents involving the same user or email address to identify potential patterns or repeated targeting.
+- Review the organization's security awareness training records to verify if the user has completed recent training, which could provide insight into their ability to recognize phishing attempts.
+- Document all findings and observations in a centralized incident management system to maintain a comprehensive record for future reference and analysis.
+
+### False positive analysis
+
+- Users may report legitimate marketing emails or newsletters as phishing due to unfamiliarity with the sender or content, leading to false positives.
+- Internal company emails with unusual formatting or language might be flagged by users as suspicious, especially if they deviate from typical communication patterns.
+- Automated system notifications or alerts from trusted services can be mistakenly reported as phishing if users are not aware of their purpose or origin.
+- To manage these false positives, organizations can create exceptions for known and verified senders by adding them to an allowlist, reducing unnecessary alerts.
+- Regularly updating user training to include examples of legitimate emails can help reduce the number of false reports by improving user discernment.
+- Implementing a feedback loop where users are informed about the outcome of their reports can enhance their understanding and accuracy in identifying true threats.
+
+### Response and remediation
+
+- Immediately isolate the affected email account to prevent further unauthorized access or spread of malicious content.
+- Conduct a thorough investigation of the reported email, including headers and links, to confirm the phishing attempt and identify any compromised accounts.
+- Remove the malicious email from all user inboxes and quarantine it to prevent further interaction.
+- Escalate the incident to the security operations team if the phishing attempt is part of a larger campaign or if multiple users are affected.
+- Review and update email filtering rules and security policies to block similar threats in the future.
+- Implement enhanced logging policies to capture detailed email activity and user actions for better future analysis.
+- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging phishing tactics.
+- Educate users on recognizing phishing attempts and reinforce the importance of reporting suspicious emails promptly.
+- Restore any affected systems or accounts to their operational state by resetting passwords and verifying system integrity.
+- Apply security hardening measures, such as multi-factor authentication and regular security awareness training, to reduce the risk of future incidents.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
index 1e179228799..d9486c4284e 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "OneDrive Malware File Upload"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 OneDrive Malware File Upload
+
+OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement. The detection rule monitors OneDrive audit logs for malware detection events, identifying potential threats when malicious files are uploaded, thus helping to prevent unauthorized access and propagation.
+
+### Possible investigation steps
+
+- Review the OneDrive audit logs to confirm the event details, focusing on fields such as `event.dataset`, `event.provider`, `event.code`, and `event.action` to ensure the alert is valid and corresponds to a malware detection.
+- Identify the user account associated with the file upload by examining the `user.name` and `user.id` fields in the audit logs to determine if the account is compromised or if the upload was accidental.
+- Investigate the file details, including the file name, size, and hash, by checking the `file.name`, `file.size`, and `file.hash` fields to gather more context about the nature of the file.
+- Check the file's origin by reviewing the `source.ip` and `source.geo.location` fields to understand where the file was uploaded from and if it matches the user's typical behavior.
+- Analyze the file's sharing permissions and access history using the `file.permissions` and `file.accessed` fields to determine if the file has been shared with other users or accessed by unauthorized parties.
+- Use Osquery to gather additional context on the endpoint from which the file was uploaded. For example, run the following Osquery query to list recent file modifications in the OneDrive directory: `SELECT * FROM file WHERE directory LIKE '%OneDrive%' AND mtime > (SELECT strftime('%s', 'now') - 86400);`
+- Correlate the OneDrive event with other security logs, such as endpoint detection and response (EDR) or intrusion detection system (IDS) logs, to identify any related suspicious activities or alerts.
+- Investigate the user's recent activity by reviewing additional OneDrive and Office 365 audit logs to identify any other unusual or unauthorized actions performed by the user.
+- Check for any other malware detection events in the OneDrive environment by searching for similar `event.action:FileMalwareDetected` events to assess if this is an isolated incident or part of a larger campaign.
+- Document all findings and evidence collected during the investigation to support further analysis and potential escalation to the incident response team.
+
+### False positive analysis
+
+- Legitimate software updates or patches may be flagged as malware if they contain code patterns similar to known threats. Users should verify the source and integrity of these files before excluding them from detection.
+- Files with macros or scripts used in business operations might trigger false positives due to their executable nature. It's important to assess the necessity and origin of these files and whitelist them if they are deemed safe.
+- Internal security tools or penetration testing files could be misidentified as malicious. Ensure these tools are recognized and documented within the organization to prevent unnecessary alerts.
+- Large files or compressed archives might be flagged due to heuristic scanning limitations. Users should review these files for any suspicious content and create exceptions for trusted sources.
+- Frequent collaboration documents that undergo regular changes might be mistakenly detected as threats. Implementing a review process for these documents can help in identifying genuine threats while allowing safe files to be excluded from alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected OneDrive account to prevent further spread of the malware within the organization.
+- Notify the user associated with the account about the detected malware and provide guidance on avoiding similar incidents in the future.
+- Conduct a thorough investigation of the uploaded file to determine its origin and potential impact on the organization.
+- Remove the malicious file from all shared locations and ensure it is quarantined for further analysis.
+- Review OneDrive audit logs and other relevant logs to identify any lateral movement or additional compromised accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement or update logging policies to ensure comprehensive monitoring of file uploads and sharing activities in OneDrive.
+- Integrate threat intelligence feeds and security solutions to enhance detection capabilities for similar threats in the future.
+- Restore affected systems and accounts to their operational state by removing any residual malware and applying necessary security patches.
+- Strengthen security measures by enforcing multi-factor authentication, regular security awareness training, and least privilege access controls.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
index 4ba15633da1..fddadca5a97 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "SharePoint Malware File Upload"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SharePoint Malware File Upload
+
+SharePoint serves as a collaborative platform for file sharing within organizations, but its openness can be exploited by adversaries. Attackers may upload malicious files to SharePoint, leveraging it to spread malware laterally across the network. The detection rule identifies such threats by monitoring specific SharePoint events where files are flagged as malware, helping to mitigate potential breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `event.dataset:o365.audit`, `event.provider:SharePoint`, `event.code:SharePointFileOperation`, and `event.action:FileMalwareDetected` to ensure the alert is valid and triggered by the correct conditions.
+- Identify the user account associated with the file upload by examining the event logs for user identifiers, such as user ID or email address, to determine if the account is compromised or if the user was unaware of the file's malicious nature.
+- Investigate the file's origin by checking the file name, size, and hash values in the event logs to see if it matches known malware signatures or if it has been flagged in other security tools.
+- Cross-reference the file hash with threat intelligence databases to gather additional context on the file's reputation and any known associated threat actors or campaigns.
+- Analyze the SharePoint site and document library where the file was uploaded to understand the potential impact and scope of exposure within the organization.
+- Check for any other recent file uploads by the same user or to the same SharePoint site to identify patterns or additional suspicious activities.
+- Use Osquery to gather more information about the affected endpoints. For example, run a query to list all files recently accessed or modified by the user: `SELECT * FROM file WHERE path LIKE '/path/to/sharepoint/directory/%' AND mtime > (SELECT strftime('%s', 'now') - 86400);`
+- Review access logs and permissions for the SharePoint site to identify any unauthorized access or privilege escalation attempts that may have facilitated the malware upload.
+- Investigate any lateral movement attempts by checking for subsequent access to other network resources or systems by the user or associated accounts.
+- Document all findings and evidence collected during the investigation to support further analysis and potential escalation to the incident response team.
+
+### False positive analysis
+
+- Files flagged as malware may include legitimate software or scripts that are incorrectly identified by the scanning engine due to heuristic or signature-based detection methods. This can occur with custom-developed applications or scripts that are not widely recognized.
+- Frequent uploads of large datasets or files from trusted internal sources might trigger false positives if the scanning engine misinterprets the data patterns as malicious.
+- Users can manage these false positives by creating exceptions for specific files or file types that are consistently flagged but verified as safe. This can be done by adjusting the scanning engine's sensitivity settings or by whitelisting certain file hashes or sources.
+- Regularly updating the scanning engine's malware definitions and maintaining a list of known safe files can help reduce the occurrence of false positives.
+- Implementing a review process for flagged files, where security teams can manually verify the legitimacy of the files before taking action, can also help in managing false positives effectively.
+
+### Response and remediation
+
+- Immediately isolate the affected SharePoint site or document library to prevent further access and potential spread of the malware.
+- Notify the IT security team and relevant stakeholders about the detected malware to initiate a coordinated response.
+- Conduct a thorough investigation to identify the source and scope of the malware upload, including reviewing user activity logs and file access history.
+- Remove the malicious file from SharePoint and perform a comprehensive scan of the environment to ensure no other instances of the malware exist.
+- Reset credentials and enforce multi-factor authentication for users involved in the incident to prevent unauthorized access.
+- Escalate the incident to higher-level security teams if the malware is part of a broader attack campaign or if multiple systems are affected.
+- Implement enhanced logging and monitoring policies to capture detailed SharePoint activity, focusing on file uploads and access patterns.
+- Integrate advanced threat detection tools with SharePoint to improve real-time monitoring and automated response capabilities.
+- Restore affected systems and SharePoint sites to their operational state from clean backups, ensuring no remnants of the malware remain.
+- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting file types allowed for upload and educating users on safe file-sharing practices.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
index 348964efd89..e41ce6f41f0 100644
--- a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
+++ b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -16,7 +16,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Exchange Suspicious Mailbox Right Delegation"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 O365 Exchange Suspicious Mailbox Right Delegation
+
+Microsoft 365 Exchange allows users to delegate mailbox access, enabling collaboration by granting permissions like FullAccess, SendAs, or SendOnBehalf. However, adversaries can exploit this by assigning these rights to compromised accounts, facilitating unauthorized access and communication. The detection rule identifies such suspicious delegations by monitoring successful permission assignments, excluding legitimate system processes, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and mailbox involved in the suspicious delegation event using the `user.id` and `o365.audit.Parameters.AccessRights` fields.
+- Verify the legitimacy of the mailbox permission change by contacting the mailbox owner or relevant department to confirm if the delegation was authorized.
+- Examine the `event.provider` and `event.action` fields to ensure the event is related to Exchange and involves the addition of mailbox permissions.
+- Check the `event.outcome` field to confirm the permission assignment was successful, indicating a potential unauthorized access.
+- Investigate the `event.dataset` field to ensure the event is part of the O365 audit logs, confirming the source of the data.
+- Analyze the historical activity of the involved user account to identify any unusual patterns or recent changes in behavior that could indicate compromise.
+- Use Osquery to gather additional context on the involved user account and mailbox. For example, run a query to list recent login activities: `SELECT * FROM o365_login WHERE user_id = '<user.id>' ORDER BY timestamp DESC LIMIT 10;`.
+- Review any recent changes to inbox rules for the affected mailbox to identify potential attempts to evade detection mechanisms.
+- Cross-reference the event with other security logs and alerts to identify any correlated activities or indicators of compromise.
+- Document all findings and observations during the investigation to maintain a comprehensive record for further analysis or escalation if needed.
+
+### False positive analysis
+
+- Delegations made by IT administrators for legitimate business purposes can trigger false positives. These should be reviewed and, if deemed non-threatening, added to an exception list to prevent future alerts.
+- Automated processes or third-party applications that require mailbox access for functionality might be flagged. Identifying these applications and excluding their associated accounts can reduce false positives.
+- Temporary delegations for projects or team collaborations may appear suspicious. Documenting these activities and setting time-bound exceptions can help manage alerts.
+- Changes made during organizational restructuring, such as department mergers, can result in multiple legitimate delegations. Monitoring these changes and updating the exception list accordingly can mitigate unnecessary alerts.
+- Regular audits of the exception list are recommended to ensure that only valid and current exceptions are maintained, reducing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately revoke the suspicious mailbox permissions to prevent further unauthorized access.
+- Isolate the compromised account by disabling it or resetting its password to contain the threat.
+- Conduct a thorough investigation to determine the extent of the compromise, including reviewing mailbox access logs and identifying any unauthorized activities.
+- Notify the affected users and relevant stakeholders about the incident and potential data exposure.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for mailbox permission changes to detect future unauthorized delegations.
+- Integrate threat intelligence feeds to correlate suspicious activities with known threat actors and tactics.
+- Restore the affected mailboxes to their last known good state, ensuring no malicious rules or forwarding settings remain.
+- Educate users on recognizing phishing attempts and the importance of reporting suspicious activities to prevent account compromise.
+- Apply security hardening measures, such as enabling multi-factor authentication (MFA) and regularly reviewing mailbox permissions, to reduce the risk of future incidents.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 21
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
index 90ef1163536..7a624cd749f 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange DKIM Signing Configuration Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange DKIM Signing Configuration Disabled
+
+DomainKeys Identified Mail (DKIM) is a security protocol that ensures email authenticity by allowing receiving servers to verify that emails are sent from authorized domains. Disabling DKIM can expose organizations to email spoofing attacks. Adversaries might exploit this by disabling DKIM to send fraudulent emails that appear legitimate. The detection rule identifies successful attempts to disable DKIM, signaling potential misuse or configuration errors.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `Exchange`, ensuring the alert is relevant to Microsoft 365 Exchange DKIM configuration.
+- Verify the event category is `web` and the event action is `Set-DkimSigningConfig` to confirm the specific action of disabling DKIM signing configuration.
+- Check the `o365.audit.Parameters.Enabled` field to ensure it is set to `False`, indicating that DKIM signing was indeed disabled.
+- Examine the `event.outcome` field to confirm it shows `success`, indicating the action to disable DKIM was successfully executed.
+- Identify the user or service account associated with the action by reviewing the `user.name` or `user.id` fields to determine if the action was performed by an authorized individual.
+- Investigate the `source.ip` field to identify the IP address from which the DKIM configuration change was made, and assess if it is a known or trusted source.
+- Review recent activity logs for the identified user or service account to detect any unusual or unauthorized actions around the time of the DKIM configuration change.
+- Utilize Osquery to gather additional context on the system or user involved. For example, run a query to list recent login activities: `SELECT * FROM users WHERE username = '<identified_user>' AND last_login > date('now', '-1 day');`
+- Check for any recent changes in administrative roles or permissions that might have allowed the DKIM configuration to be disabled.
+- Correlate this event with other security alerts or incidents in the same timeframe to identify potential patterns or coordinated actions that could indicate a broader security issue.
+
+### False positive analysis
+
+- Routine administrative changes: Organizations may intentionally disable DKIM temporarily for maintenance or configuration updates. To manage this, create exceptions for known maintenance periods or authorized personnel performing these actions.
+- Testing and troubleshooting: IT teams might disable DKIM as part of testing or troubleshooting email configurations. Implement a process to log and approve such activities, allowing you to exclude these events from triggering alerts.
+- Misconfigured automation scripts: Automated scripts or tools used for managing email settings might inadvertently disable DKIM. Review and update scripts to ensure they align with security policies, and exclude known scripts from alerting.
+- Third-party integrations: Some third-party email services or integrations might require DKIM to be disabled temporarily. Document and approve these integrations, and set up exceptions for recognized third-party actions.
+
+### Response and remediation
+
+- Verify the alert by checking the audit logs to confirm that the DKIM signing configuration was indeed disabled and identify the user or system account responsible for the change.
+- Contain the potential threat by immediately re-enabling DKIM signing for the affected domain to prevent further spoofing attempts.
+- Investigate the source of the change by reviewing user activity logs and correlating with other security events to determine if the action was authorized or part of a malicious activity.
+- If unauthorized, reset the credentials of the compromised account and review access permissions to ensure least privilege principles are enforced.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised.
+- Implement enhanced logging and monitoring for DKIM configuration changes and other critical security settings within Microsoft 365 to detect similar incidents in the future.
+- Integrate with a Security Information and Event Management (SIEM) system to centralize alerts and improve threat detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the importance of DKIM and other email security protocols to prevent accidental or malicious misconfigurations.
+- Apply hardening measures by enabling multi-factor authentication (MFA) for all administrative accounts and regularly reviewing security configurations in Microsoft 365.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
index d445e6723d7..f8f1a99ce05 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Management Group Role Assignment"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Exchange Management Group Role Assignment
+
+Microsoft 365 Exchange Management roles define permissions for managing Exchange environments. Adversaries may exploit this by assigning roles to unauthorized users, ensuring persistent access. The detection rule monitors successful role assignments within Exchange, flagging potential unauthorized changes that align with persistence tactics, thus aiding in identifying and mitigating account manipulation threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `Exchange`, ensuring the alert is relevant to Exchange role assignments.
+- Verify the `event.category` is `web` and the `event.action` is `New-ManagementRoleAssignment` to confirm the specific action that triggered the alert.
+- Check the `event.outcome` field to ensure it indicates a `success`, confirming that the role assignment was completed.
+- Identify the user account associated with the role assignment by examining the relevant fields in the alert, such as `user.name` or `user.id`.
+- Investigate the assigned role by reviewing the `management.role` field to understand the permissions granted and assess the potential impact.
+- Cross-reference the user account with known authorized personnel to determine if the role assignment aligns with expected administrative activities.
+- Utilize Osquery to gather additional context on the user account by running a query such as: `SELECT * FROM users WHERE username = '<user.name from alert>';` to check for any anomalies or recent changes.
+- Examine the `source.ip` field to identify the originating IP address of the role assignment action and assess if it matches known or expected locations.
+- Review historical logs for any previous role assignments or suspicious activities associated with the same user or IP address to identify patterns or repeated unauthorized actions.
+- Collaborate with the IT or security team to gather additional context on recent administrative changes or projects that might explain the role assignment, ensuring it was not part of a legitimate operation.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular role assignments by authorized IT personnel for maintenance or updates can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or tools: Some organizations use automated processes for role assignments, which may be flagged. Identify and exclude these scripts or tools by their unique identifiers or execution patterns.
+- Organizational changes: During mergers, acquisitions, or restructuring, role assignments may increase. Monitor these periods closely and temporarily adjust thresholds or exclusions to accommodate expected changes.
+- Training or onboarding: New employee onboarding or training sessions might involve temporary role assignments. Implement a process to log and verify these activities, allowing for temporary exclusions during these periods.
+
+### Response and remediation
+
+- Immediately isolate the affected account to prevent further unauthorized access and assess the scope of the role assignment.
+- Review audit logs to identify any additional unauthorized role assignments or suspicious activities linked to the compromised account.
+- Revoke any unauthorized role assignments and reset credentials for affected accounts to prevent adversary persistence.
+- Conduct a thorough investigation to determine how the adversary gained access and whether other accounts or systems are compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring policies to capture detailed audit logs of role assignments and other critical actions within Microsoft 365.
+- Integrate security information and event management (SIEM) solutions to correlate events and detect similar threats in the future.
+- Restore the system to its operational state by verifying that all unauthorized changes have been reverted and that security controls are in place.
+- Apply hardening measures such as multi-factor authentication (MFA) for administrative accounts and regular review of role assignments.
+- Educate users and administrators on recognizing phishing attempts and other common tactics used to gain unauthorized access.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
index 821b0bf2f8c..67a8655cd83 100644
--- a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Global Administrator Role Assigned"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Global Administrator Role Assigned
+
+The Global Administrator role in Microsoft 365 grants comprehensive access to manage Azure AD and related services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit events, focusing on role changes to "Global Administrator," thus alerting to potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is "o365.audit" and the event code is "AzureActiveDirectory" to ensure the alert is relevant to Azure AD role changes.
+- Verify the event action is "Add member to role" and check if the "o365.audit.ModifiedProperties.Role_DisplayName.NewValue" is "Global Administrator" to confirm the specific role assignment.
+- Identify the user account that was added to the Global Administrator role by examining the event logs for the user ID or email address associated with the role change.
+- Investigate the user account that performed the role assignment to determine if it was an authorized action or potentially malicious.
+- Check the timestamp of the event to understand when the role assignment occurred and correlate it with other security events or anomalies around the same time.
+- Use Osquery to gather additional context on the user account involved in the role assignment. Example query: `SELECT * FROM users WHERE username = 'suspected_user';`
+- Review the audit logs for any other recent changes or suspicious activities involving the same user account or related accounts.
+- Examine the IP address and location from which the role assignment was made to determine if it aligns with expected user behavior or if it appears suspicious.
+- Investigate any recent changes to the organization's Azure AD configuration or security settings that might have facilitated unauthorized role assignments.
+- Collaborate with the IT or security team to gather additional context on the user accounts involved, such as recent password changes, MFA status, or any reported incidents.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may frequently assign the Global Administrator role during regular maintenance or onboarding processes. To manage these, organizations can create exceptions for known administrative accounts or specific time frames when such activities are expected.
+- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage user roles, which might trigger the detection rule. Users can exclude these scripts or tools by identifying their unique identifiers or IP addresses and adding them to an exception list.
+- Temporary role assignments: In some cases, users may be temporarily assigned the Global Administrator role for specific projects or tasks. To handle these, organizations can implement a process to document and approve temporary assignments, then exclude these documented cases from triggering alerts.
+- Delegated administration: Organizations that use delegated administration might see frequent role changes as part of their operational model. To reduce false positives, they can exclude changes made by specific delegated admin accounts or within certain organizational units.
+
+### Response and remediation
+
+- Immediately revoke the Global Administrator role from any unauthorized users to contain the threat and prevent further misuse.
+- Conduct a thorough investigation to identify how the unauthorized assignment occurred, reviewing audit logs and any related security alerts.
+- Reset passwords and enforce multi-factor authentication (MFA) for all affected accounts to prevent further unauthorized access.
+- Escalate the incident to the security operations team for a deeper analysis and to determine if any other systems or accounts have been compromised.
+- Review and update role assignment policies to ensure that only authorized personnel can assign or modify Global Administrator roles.
+- Implement enhanced logging and monitoring for Azure AD role changes, ensuring that all role assignments and modifications are captured and reviewed regularly.
+- Integrate security information and event management (SIEM) systems with Azure AD to automate alerting and improve incident response times.
+- Restore any affected systems or services to their operational state by verifying configurations and ensuring no unauthorized changes remain.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate and train staff on the importance of role-based access control and the risks associated with improper role assignments to prevent future incidents.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
index a8da34138b9..9b6d4c89b3d 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,52 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams Custom Application Interaction Allowed"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Teams Custom Application Interaction Allowed
+
+Microsoft Teams allows organizations to enhance functionality by integrating custom applications, which can be developed and uploaded if the default app store offerings are insufficient. However, this flexibility can be exploited by adversaries to maintain persistence within a network. The detection rule monitors changes in tenant settings that permit custom app interactions, flagging successful modifications as potential security threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `MicrosoftTeams`, ensuring the alert is relevant to Microsoft Teams settings.
+- Verify the event category is `web` and the action is `TeamsTenantSettingChanged` to confirm that the alert pertains to a change in tenant settings.
+- Check the `o365.audit.Name` field for "Allow sideloading and interaction of custom apps" to ensure the alert is specifically about enabling custom app interactions.
+- Confirm the `o365.audit.NewValue` is `True` and the `event.outcome` is `success` to validate that the change was successfully applied.
+- Investigate the user account associated with the change to determine if the account has a history of making administrative changes or if it appears suspicious.
+- Review recent activity logs for the user account to identify any unusual behavior or patterns that could indicate compromise or misuse.
+- Examine the IP address and location associated with the change to assess if it aligns with expected user activity or if it appears anomalous.
+- Use Osquery to gather additional context on the system from which the change was made. For example, run the following query to list recent administrative actions: `SELECT * FROM osquery_events WHERE event_type = 'admin_action' AND user = '<user_account>' ORDER BY timestamp DESC LIMIT 10;`
+- Check for any recent uploads or installations of custom applications in Microsoft Teams to identify potential unauthorized or malicious apps.
+- Collaborate with the IT or security team to gather more context on the organization's policy regarding custom applications and verify if the change aligns with any recent business needs or projects.
+
+### False positive analysis
+
+- Organizations frequently enabling custom applications for legitimate business needs may trigger this rule, leading to false positives.
+- Regular updates or changes in tenant settings by IT administrators for maintenance or feature enhancements can be mistaken for suspicious activity.
+- To manage these false positives, users can create exceptions for known and trusted administrative actions by whitelisting specific user accounts or IP addresses.
+- Implementing a review process for changes in tenant settings can help differentiate between legitimate and suspicious modifications.
+- Monitoring the context of changes, such as correlating with scheduled maintenance windows or approved change requests, can reduce false positives.
+- Regularly updating the list of approved custom applications and their developers can help in distinguishing between legitimate and potentially malicious activities.
+
+### Response and remediation
+
+- Immediately disable the setting that allows sideloading and interaction of custom apps in Microsoft Teams to prevent further unauthorized access.
+- Conduct a thorough investigation to identify any custom applications that have been uploaded recently and verify their legitimacy.
+- Review audit logs and user activity to identify any suspicious behavior or unauthorized access attempts related to the custom applications.
+- Isolate any compromised accounts or systems identified during the investigation to prevent lateral movement within the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for Microsoft Teams and related services to detect similar activities in the future.
+- Review and update security policies to restrict permissions for uploading and interacting with custom applications to only trusted users.
+- Educate users on the risks associated with custom applications and provide training on recognizing potential security threats.
+- Restore any affected systems to a known good state by removing unauthorized applications and applying necessary security patches.
+- Consider implementing additional security measures such as multi-factor authentication and conditional access policies to harden the environment against future threats.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/deploy-and-publish/apps-upload"]
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
index a47f63526f6..bcfe158fd0c 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,51 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams External Access Enabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Teams External Access Enabled
+
+Microsoft Teams allows external access to facilitate communication with users outside an organization, enhancing collaboration. However, adversaries can exploit this feature to exfiltrate data or maintain persistence by enabling external access or adding trusted domains. The detection rule monitors audit logs for successful configuration changes that permit external communication, flagging potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.action "Set-CsTenantFederationConfiguration" and ensure the event.outcome is marked as success.
+- Verify the event.dataset is o365.audit and the event.provider is either SkypeForBusiness or MicrosoftTeams to confirm the source of the alert.
+- Check the o365.audit.Parameters.AllowFederatedUsers field to ensure it is set to True, indicating that external access was enabled.
+- Investigate the user account associated with the configuration change to determine if the action was performed by a legitimate administrator or a potentially compromised account.
+- Examine the timestamp of the event to correlate with any other suspicious activities or anomalies in the environment around the same time.
+- Review the audit logs for any recent changes to the list of allowed domains for external access to identify any unauthorized additions.
+- Utilize Osquery to gather additional context on the user account involved. Example query: `SELECT * FROM users WHERE username = 'suspected_user';`
+- Check for any recent login activities from unusual locations or IP addresses associated with the user account involved in the configuration change.
+- Investigate any other recent configuration changes in Microsoft Teams or Skype for Business that might indicate further unauthorized access attempts.
+- Collaborate with the IT team to verify if the configuration change aligns with any recent legitimate business needs or projects that required enabling external access.
+
+### False positive analysis
+
+- Routine administrative changes: Legitimate IT administrators may enable external access as part of regular configuration updates or to facilitate business operations. To manage these, organizations can maintain a list of authorized personnel and cross-reference changes with approved change requests.
+- Partner or vendor communication: External access might be enabled to allow communication with trusted partners or vendors. Users can handle these by creating exceptions for known and verified domains, ensuring they are documented and regularly reviewed.
+- Temporary project requirements: Teams working on joint projects with external entities may require temporary external access. Implementing a process to log and approve such temporary access can help differentiate between legitimate and suspicious activities.
+- Misconfigured alerts: Sometimes, alerts may trigger due to misconfigured settings or testing environments. Regularly reviewing and updating alert configurations can help minimize these false positives.
+- Automated scripts or tools: Automated processes that modify configurations for maintenance or updates might trigger alerts. Identifying and documenting these scripts can help in excluding them from triggering false positives.
+
+### Response and remediation
+
+- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains.
+- Conduct a thorough investigation of audit logs to identify any unauthorized configuration changes and determine the scope of potential data exfiltration.
+- Verify the list of allowed domains and remove any that are not recognized or authorized by the organization.
+- Reset credentials and review account permissions for any accounts involved in the suspicious activity to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed audit logs of configuration changes and access attempts in Microsoft Teams.
+- Integrate Microsoft 365 security logs with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
+- Conduct a review of current security policies and update them to include stricter controls on external access and domain whitelisting.
+- Restore the system to its operational state by ensuring all unauthorized changes are reverted and verifying the integrity of the Teams environment.
+- Apply hardening measures such as multi-factor authentication (MFA) for administrative accounts and regular security awareness training for users.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/microsoftteams/manage-external-access"]
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
index cad302f3660..5ddaff067f6 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams Guest Access Enabled"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft 365 Teams Guest Access Enabled
+
+Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access by enabling guest access without authorization. The detection rule identifies such unauthorized actions by monitoring specific audit events and configurations, ensuring any suspicious enabling of guest access is promptly flagged for investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.action "Set-CsTeamsClientConfiguration" and ensure the event.outcome is marked as success.
+- Verify the identity of the user or account that performed the action by examining the user information in the event logs, focusing on any anomalies or unfamiliar accounts.
+- Check the timestamp of the event to determine when the guest access was enabled and correlate it with other security events or logs around the same time for additional context.
+- Investigate the o365.audit.Parameters.AllowGuestUser field to confirm that it is set to True, indicating that guest access was indeed enabled.
+- Examine the event.provider field to determine whether the action was performed through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used.
+- Utilize Osquery to gather more information about the user account involved. For example, run the following query to list recent logins and activities for the user: `SELECT * FROM users WHERE username = '<username>';`
+- Review the organization's Microsoft 365 audit logs for any other suspicious activities or changes made by the same user or account around the same time.
+- Investigate any recent changes to the Teams configuration settings to identify if there were any unauthorized modifications or patterns of suspicious behavior.
+- Cross-reference the alert with known threat intelligence sources to determine if the activity matches any known adversary tactics or techniques.
+- Consult with team members or stakeholders to gather additional context or insights regarding the legitimacy of the guest access enablement, especially if the user is unfamiliar or the action is unexpected.
+
+### False positive analysis
+
+- Routine administrative actions: Legitimate IT administrators may enable guest access as part of their regular duties to facilitate collaboration with external partners or clients. These actions can be considered false positives if they align with documented business processes.
+- Automated scripts or tools: Organizations may use automated scripts or third-party tools to manage Microsoft Teams configurations, including enabling guest access. These actions should be reviewed to ensure they are authorized and align with organizational policies.
+- Policy updates: Changes in organizational policies or compliance requirements may necessitate enabling guest access. Such changes should be documented and communicated to avoid being flagged as suspicious.
+- Exception handling: To manage false positives, organizations can create exceptions for known and authorized activities by maintaining a list of approved users or scripts that are allowed to enable guest access. Regularly review and update this list to ensure it reflects current business needs and security policies.
+
+### Response and remediation
+
+- Immediately disable guest access in Microsoft Teams to prevent unauthorized external access.
+- Review audit logs to identify any unauthorized changes to guest access settings and determine the scope of the incident.
+- Verify the identity and permissions of any external users who were granted guest access to ensure they are legitimate and authorized.
+- Conduct a thorough investigation to identify any potential data exfiltration or malicious activities performed by the adversary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement stricter access controls and review the organization's guest access policies to prevent unauthorized changes in the future.
+- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities promptly.
+- Educate employees on the risks associated with guest access and provide training on identifying suspicious activities.
+- Restore any affected systems or configurations to their original state, ensuring no backdoors or unauthorized changes remain.
+- Apply hardening measures such as multi-factor authentication (MFA) and regular audits of access permissions to reduce the risk of persistence tactics like account manipulation.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
index 273f81c599d..d5be6beb5ad 100644
--- a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
+++ b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Austin Songer"]
@@ -14,7 +14,50 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "New or Modified Federation Domain"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 New or Modified Federation Domain
+Federation domains enable trust relationships between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions within Exchange logs, identifying successful modifications to federation domains, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific action that triggered the alert, focusing on the `event.action` field to determine whether it was a domain addition, modification, or removal.
+- Examine the `event.outcome` field to confirm the success of the action, ensuring that the alert is not a false positive due to a failed attempt.
+- Check the `event.provider` and `event.dataset` fields to verify that the event originated from the expected source, ensuring the integrity of the alert.
+- Investigate the user account associated with the action by reviewing the `user.name` field to determine if the account has a history of suspicious activity or if it is a known administrative account.
+- Analyze the `event.time` field to establish a timeline of events, identifying any unusual patterns or times that could indicate malicious intent.
+- Correlate the event with other logs or alerts from the same time period to identify any related suspicious activities, such as unauthorized access attempts or privilege escalations.
+- Use Osquery to gather additional context on the system where the action was performed. For example, run the following query to list recent changes to federation settings: `SELECT * FROM federated_domains WHERE action IN ('Set-AcceptedDomain', 'Set-MsolDomainFederationSettings', 'Add-FederatedDomain', 'New-AcceptedDomain', 'Remove-AcceptedDomain', 'Remove-FederatedDomain');`
+- Investigate any recent changes to administrative roles or permissions that could have facilitated the unauthorized modification of federation domains.
+- Review the organization's change management records to verify if the action was part of a planned and approved change, potentially ruling out malicious activity.
+- Consult with the identity and access management team to confirm whether the federation domain changes align with current business needs and security policies.
+
+### False positive analysis
+
+- Routine administrative changes: Legitimate IT administrators may frequently update federation domains as part of regular maintenance or configuration changes. These actions can trigger the detection rule, leading to false positives.
+- Scheduled domain updates: Organizations may have scheduled updates or migrations that involve modifying federation domains, which can be mistaken for malicious activity.
+- Integration with new identity providers: When an organization integrates a new external identity provider, it may involve adding or modifying federation domains, which could be flagged by the rule.
+- To manage these false positives, users can create exceptions for known administrative accounts or scheduled maintenance windows, ensuring that only unexpected or unauthorized changes trigger alerts.
+- Implementing a review process for flagged events can help distinguish between legitimate administrative actions and potential threats, reducing the number of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected accounts or systems to prevent further unauthorized access.
+- Review the audit logs to identify the scope of the changes made to federation domains and determine if any unauthorized domains were added or modified.
+- Revert any unauthorized changes to federation settings by restoring the original configuration from backups or documented settings.
+- Conduct a thorough investigation to identify the source of the unauthorized changes, including reviewing user activity and access logs.
+- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential impacts.
+- Implement additional monitoring and alerting for changes to federation domains to detect future unauthorized modifications promptly.
+- Enhance logging policies to ensure comprehensive capture of authentication and federation-related activities, integrating with SIEM solutions for real-time analysis.
+- Educate users and administrators on the importance of secure federation settings and the risks associated with unauthorized modifications.
+- Apply security hardening measures such as multi-factor authentication (MFA) for administrative accounts and regular reviews of federation trust relationships.
+- Review and update incident response plans to incorporate lessons learned from the investigation and ensure readiness for similar future incidents.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
index 7feaeba1c62..532b4ab7e4a 100644
--- a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
+++ b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/11"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -51,6 +51,49 @@ event.dataset: okta.system
     and not okta.debug_context.debug_data.flattened.requestedScopes: ("okta.logs.read" or "okta.eventHooks.read" or "okta.inlineHooks.read")
     and okta.outcome.reason: "no_matching_scope"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials
+
+OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of a user. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token requests due to scope mismatches, signaling potential misuse by unfamiliar actors.
+
+### Possible investigation steps
+
+- Review the `okta.actor.display_name` field to identify the actor involved in the failed token grant attempt and determine if this actor is known or expected to request such scopes.
+- Examine the `okta.debug_context.debug_data.flattened.requestedScopes` field to understand which unauthorized scopes were requested and assess their potential impact if accessed.
+- Analyze the `okta.actor.type` field to confirm that the actor is indeed a "PublicClientApp" and verify if this aligns with the expected behavior of the application.
+- Investigate the `okta.outcome.reason` field, specifically looking for "no_matching_scope," to confirm that the failure was due to unauthorized scope requests.
+- Check the `okta.client.user_agent.raw_user_agent` field to ensure the request did not originate from known integrations like "Okta-Integrations," which are excluded from the rule.
+- Utilize Osquery to gather additional context on the system from which the request originated. For example, run an Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_of_interest>';`.
+- Correlate the event with other logs in the `event.dataset: okta.system` to identify any patterns or repeated attempts from the same actor or IP address.
+- Investigate the `okta.outcome.result` field to confirm the failure status and cross-reference with other successful attempts to identify any anomalies.
+- Review historical data for the `okta.actor.display_name` to determine if this is the first occurrence of such behavior or if there is a pattern of similar unauthorized attempts.
+- Consult with application owners or developers to verify if there have been any recent changes or updates to the application that might explain the unexpected scope request.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate public client apps are misconfigured or updated, leading to failed token requests due to scope mismatches. These apps might not pose a threat but trigger the rule due to their unfamiliar behavior.
+- Frequent legitimate actors, such as internal development teams testing new integrations or updates, might inadvertently cause false positives. Monitoring these actors over time can help identify patterns that are non-threatening.
+- To manage false positives, users can create exceptions for specific `okta.actor.display_name` values that are known to be safe and frequently involved in legitimate activities. This can be done by adding these values to the exclusion list in the detection rule.
+- Regularly review and update the list of excluded scopes and actors to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the rule in detecting genuine threats.
+- Consider implementing additional logging and monitoring for actors that are excluded to ensure that their behavior remains consistent with expected patterns and does not evolve into a potential threat.
+
+### Response and remediation
+
+- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts.
+- Investigate the source of the unauthorized scope request by reviewing logs and identifying the actor's IP address and user agent.
+- Conduct a thorough review of recent access logs to identify any other suspicious activities or anomalies associated with the compromised credentials.
+- Notify the security team and relevant stakeholders about the incident and provide them with details of the unauthorized access attempt.
+- Implement additional logging and monitoring for OAuth 2.0 token requests to detect similar unauthorized attempts in the future.
+- Update and enforce strong authentication policies for public client apps, including the use of multi-factor authentication where possible.
+- Review and restrict the scopes available to public client apps to minimize the risk of unauthorized access.
+- Educate developers and users about secure credential management practices to prevent future credential compromises.
+- Consider integrating with a Security Information and Event Management (SIEM) system to enhance threat detection and response capabilities.
+- Restore the system to its operational state by ensuring all security patches are applied and conducting a security audit to identify and address any vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
index 816c943f532..39b0b451063 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Delete an Okta Application"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Delete an Okta Application
+
+Okta is a widely used identity and access management service that helps organizations manage user authentication and application access. Adversaries may target Okta applications to disrupt operations or weaken security by attempting deletions. The detection rule monitors system events for deletion actions, identifying potential threats by flagging unauthorized attempts to remove applications, thus safeguarding organizational integrity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `okta.system` and the event action is `application.lifecycle.delete` to ensure the alert is valid.
+- Check the timestamp of the event to determine when the deletion attempt occurred and correlate it with any other suspicious activities around the same time.
+- Identify the user account associated with the deletion attempt by examining the event data, and verify if the account has legitimate access and permissions to perform such actions.
+- Investigate the IP address and location from which the deletion attempt was made to determine if it aligns with the user's typical access patterns.
+- Review recent login activities for the user account involved to identify any unusual or unauthorized access attempts.
+- Examine the application targeted for deletion to understand its role within the organization and assess the potential impact of its removal.
+- Utilize Osquery to gather additional context on the system from which the attempt was made. For example, run the query: `SELECT * FROM processes WHERE name LIKE '%okta%'` to identify any related processes running on the system.
+- Check for any recent changes in user permissions or roles that might have inadvertently allowed the deletion attempt.
+- Look for any other alerts or logs related to Okta applications or user accounts that might indicate a broader attack or compromise.
+- Document all findings and observations to build a comprehensive understanding of the incident and facilitate further analysis if needed.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may trigger the detection rule if legitimate users with appropriate permissions delete or modify Okta applications as part of their job responsibilities.
+- Automated scripts or third-party integrations that manage application lifecycles could also generate false positives if they perform deletion actions as part of their normal operation.
+- To manage these false positives, organizations can create exceptions for specific user accounts or service accounts known to perform regular maintenance tasks, ensuring these actions are not flagged as threats.
+- Implementing a review process for flagged events can help distinguish between legitimate administrative actions and potential security threats, allowing for more accurate threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected Okta application to prevent further unauthorized actions and assess the scope of the incident.
+- Verify the identity and access permissions of the user or system that attempted the deletion to determine if it was a legitimate action or a compromised account.
+- Review Okta system logs and event history to gather detailed information about the deletion attempt, including timestamps, IP addresses, and user agents.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems or applications are at risk.
+- Restore the deleted application from backups or snapshots, ensuring that all configurations and settings are intact and operational.
+- Implement additional logging and monitoring policies to capture detailed events related to application lifecycle changes in Okta.
+- Integrate Okta with a Security Information and Event Management (SIEM) system to enhance real-time monitoring and alerting capabilities.
+- Conduct a thorough review of access controls and permissions within Okta to ensure that only authorized personnel have the ability to modify or delete applications.
+- Educate users and administrators on the importance of strong authentication practices and the risks associated with unauthorized application modifications.
+- Consider implementing multi-factor authentication (MFA) and other security hardening measures to reduce the risk of unauthorized access and actions in the future.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
index 79b5c489099..007b366adac 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,7 +22,50 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Modify an Okta Application"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Modify an Okta Application
+
+Okta is a widely used identity and access management service that helps organizations manage user authentication and application access. Adversaries may target Okta applications to alter configurations, disable security features, or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to safeguard against potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.dataset is "okta.system" and the event.action is "application.lifecycle.update" to ensure the alert is valid and relevant.
+- Check the timestamp of the event to determine when the modification attempt occurred and correlate it with any other suspicious activities around the same time.
+- Identify the user or service account associated with the modification attempt by examining the user.id and user.name fields in the event data.
+- Investigate the IP address and geolocation from which the modification attempt was made to determine if it aligns with expected user behavior or if it appears suspicious.
+- Examine the specific application targeted for modification by reviewing the app.id and app.name fields to assess its criticality and potential impact on the organization.
+- Analyze the change details to understand what specific modifications were attempted, such as configuration changes or security feature deactivation.
+- Cross-reference the user or service account activity with recent login events to verify if there were any unusual login patterns or failed login attempts.
+- Utilize Osquery to gather additional context on the system from which the modification attempt originated. For example, run the following Osquery query to list recent processes executed on the system: `SELECT * FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
+- Check for any recent changes in user permissions or roles that might have inadvertently allowed unauthorized modification attempts.
+- Review audit logs and historical data for any previous similar modification attempts or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or maintenance activities performed by authorized personnel may trigger the rule. To manage this, users can create exceptions for specific user accounts or roles known to perform these tasks frequently.
+- Scheduled application updates: Automated processes that update application configurations as part of scheduled maintenance can be mistaken for unauthorized modifications. Users should identify and exclude these processes from triggering alerts.
+- Integration with third-party services: Some integrations may require periodic updates to application settings, which could be flagged as modification attempts. Users can whitelist these integrations to prevent false positives.
+- Testing and development environments: Changes made in non-production environments for testing purposes might be detected by the rule. Users should consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these contexts.
+
+### Response and remediation
+
+- Immediately isolate the affected Okta application to prevent further unauthorized modifications.
+- Review the Okta system logs to identify the source and scope of the modification attempt, focusing on the event.dataset:okta.system and event.action:application.lifecycle.update.
+- Verify the integrity of the Okta application configurations and restore them to their last known good state if any unauthorized changes are detected.
+- Conduct a thorough investigation to determine if any user accounts have been compromised, and reset credentials for affected accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed audit trails of application lifecycle events and user activities within Okta.
+- Integrate Okta with a security information and event management (SIEM) system to enable real-time monitoring and alerting of suspicious activities.
+- Review and update access controls and permissions for Okta applications to ensure the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users and administrators on security best practices and the importance of reporting suspicious activities to prevent future incidents.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/impact_possible_okta_dos_attack.toml b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
index 6300d7e24df..1f1749a802e 100644
--- a/rules/integrations/okta/impact_possible_okta_dos_attack.toml
+++ b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -16,7 +16,50 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Possible Okta DoS Attack"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Possible Okta DoS Attack
+
+Okta is a widely used identity and access management service that facilitates secure user authentication and application integration. Adversaries may exploit Okta by overwhelming it with excessive requests, leading to a Denial of Service (DoS) that disrupts business operations. The detection rule identifies potential DoS attacks by monitoring for specific rate limit violations and warnings, indicating abnormal activity that could signify an attack.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of rate limit violations by checking the `event.action` field for values like `application.integration.rate_limit_exceeded`, `system.org.rate_limit.warning`, `system.org.rate_limit.violation`, or `core.concurrency.org.limit.violation`.
+- Examine the `event.dataset` field to ensure it is set to `okta.system`, confirming the alert is related to Okta system events.
+- Correlate the timestamps of the alerts to identify patterns or spikes in activity that may indicate a coordinated attack.
+- Investigate the source IP addresses associated with the suspicious activity to determine if they are known or have been flagged in past incidents.
+- Check the user accounts involved in the events to see if they are legitimate users or potentially compromised accounts.
+- Analyze the frequency and volume of requests to identify if the activity is consistent with a DoS attack or if it could be a result of legitimate high usage.
+- Use Osquery to gather additional context on the systems involved. For example, run a query to list all active network connections: `SELECT * FROM listening_ports WHERE port = 443;` to check for unusual connections to Okta services.
+- Review historical logs to identify any previous occurrences of similar rate limit violations and determine if there is a recurring pattern.
+- Investigate any recent changes in the organization's Okta configuration or integrations that might have inadvertently caused increased load or rate limit issues.
+- Collaborate with the network team to analyze network traffic patterns during the time of the alert to identify any anomalies or potential sources of the excessive requests.
+
+### False positive analysis
+
+- High-volume legitimate traffic: Organizations with high user activity may naturally exceed rate limits without malicious intent. This can occur during peak business hours or when deploying new applications that require extensive authentication requests.
+- Automated processes: Scheduled tasks or automated scripts that interact with Okta services might trigger rate limit warnings if they perform numerous requests in a short period.
+- Integration testing: During the development or testing of new integrations, developers may inadvertently generate excessive requests, leading to false positives.
+- To manage these false positives, users can create exceptions for known high-traffic periods or specific IP addresses associated with trusted automated processes. Additionally, monitoring and adjusting rate limits based on typical organizational activity can help reduce unnecessary alerts.
+
+### Response and remediation
+
+- Immediately assess the scope of the attack by reviewing logs for the specific rate limit violations and warnings identified in the detection query.
+- Contain the attack by implementing IP blocking or rate limiting on the source of excessive requests, if identifiable.
+- Notify the security operations team and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response.
+- Investigate the origin of the attack to determine if it is part of a larger threat campaign or a targeted attack against the organization.
+- Remediate by working with Okta support to ensure that any affected services are restored to normal operation and that any temporary measures are lifted once the threat is mitigated.
+- Escalate the incident to higher management and legal teams if the attack results in significant business disruption or data compromise.
+- Enhance logging policies to ensure comprehensive capture of authentication and access events, enabling better detection and analysis of future incidents.
+- Integrate additional security tools, such as intrusion detection systems or SIEM solutions, to improve monitoring and response capabilities.
+- Restore the system to its operational state by verifying that all services are functioning correctly and that no unauthorized changes have been made.
+- Implement hardening measures, such as multi-factor authentication and stricter access controls, to reduce the risk of future DoS attacks and improve overall security posture.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
index 7b3bfb33839..f8e9e870fd4 100644
--- a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
+++ b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -13,7 +13,54 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Okta FastPass Phishing Detection"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Okta FastPass Phishing Detection
+
+Okta FastPass is a security feature that enhances user authentication by preventing access to phishing sites. Adversaries may attempt to exploit this by redirecting users to malicious sites to capture credentials. The detection rule identifies failed authentication attempts where FastPass blocks phishing, signaling potential phishing activity. This helps security analysts quickly respond to and mitigate phishing threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `event.dataset:okta.system` and `event.category:authentication` fields, ensuring the alert is related to an authentication event.
+- Verify the `okta.event_type:user.authentication.auth_via_mfa` field to confirm that the authentication attempt involved multi-factor authentication, which adds context to the security posture.
+- Check the `event.outcome:failure` field to ensure the authentication attempt was unsuccessful, indicating a potential phishing attempt blocked by FastPass.
+- Investigate the `okta.outcome.reason:"FastPass declined phishing attempt"` field to confirm that the failure was due to FastPass identifying a phishing attempt.
+- Identify the user involved in the alert by examining the user-related fields in the event data to determine if they have a history of similar alerts or suspicious activity.
+- Analyze the timestamp of the event to correlate with other security events or logs that might provide additional context or evidence of a broader attack.
+- Use Osquery to gather additional information about the user's device at the time of the alert. For example, run the following Osquery query to check for recent network connections that might indicate communication with suspicious domains:
+  ```sql
+  SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL AND remote_port != 0;
+  ```
+- Investigate any associated IP addresses or domains from the alert to determine if they are known for malicious activity by cross-referencing threat intelligence sources.
+- Review the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior that might suggest compromised credentials.
+- Collaborate with other security tools and logs, such as firewall or proxy logs, to trace the origin of the phishing attempt and gather more context about the potential threat actor.
+
+### False positive analysis
+
+- Legitimate third-party applications or services that use authentication methods similar to phishing sites may trigger false positives. Security teams should review these instances to determine if they are benign.
+- Users accessing unfamiliar but legitimate websites for the first time might be flagged. Analysts should verify the legitimacy of these sites and consider adding them to an allowlist if they are deemed safe.
+- Internal testing environments that mimic phishing scenarios for training purposes can also be mistakenly identified. These should be documented and excluded from detection rules to prevent unnecessary alerts.
+- Frequent false positives from specific users or departments may indicate a need for additional user education or adjustments to the detection parameters. Security teams can create exceptions for known safe behaviors to reduce noise.
+- Collaboration with IT and security teams to regularly update and refine the list of exceptions can help maintain the balance between security and usability, ensuring that legitimate activities are not hindered by the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further unauthorized access and notify the user of the potential phishing attempt.
+- Conduct a thorough investigation of the phishing attempt by analyzing logs and identifying the source of the phishing URL to understand the scope of the attack.
+- Review and update email filtering and web proxy settings to block the identified phishing domain and similar malicious domains.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if other users or systems have been targeted.
+- Implement additional logging policies to capture detailed authentication events and user activity for enhanced monitoring and future investigations.
+- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection of phishing attempts and related threats.
+- Restore the affected user account by resetting credentials and ensuring no unauthorized changes were made to the account or associated systems.
+- Educate the user and potentially affected employees on recognizing phishing attempts and best practices for maintaining account security.
+- Review and update security policies and procedures to incorporate lessons learned from the incident and improve organizational resilience against phishing attacks.
+- Apply hardening measures such as enabling multi-factor authentication (MFA) for all users and regularly updating security software to protect against similar threats in the future.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
index 1dcfb9ddfb6..6de4d09f5ac 100644
--- a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
+++ b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/14"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -13,7 +13,54 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Unauthorized Access to an Okta Application"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unauthorized Access to an Okta Application
+
+Okta is a widely used identity management service that facilitates secure user authentication across applications. Adversaries may exploit valid credentials to gain unauthorized access, bypassing security controls. The detection rule monitors specific Okta system events, flagging attempts to access applications without proper authorization, thus helping identify potential breaches early.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.dataset is "okta.system" and the event.action is "app.generic.unauth_app_access_attempt" to ensure the alert is valid.
+- Check the timestamp of the unauthorized access attempt to determine when the event occurred.
+- Identify the user account involved in the unauthorized access attempt by examining the user.id and user.name fields in the event data.
+- Investigate the source IP address from which the unauthorized access attempt originated to determine if it is known or suspicious.
+- Cross-reference the source IP address with threat intelligence feeds to check for any known malicious activity associated with it.
+- Review the application details, such as app.id and app.name, to understand which application was targeted in the unauthorized access attempt.
+- Analyze the user's recent activity logs in Okta to identify any unusual behavior or patterns that could indicate compromised credentials.
+- Use Osquery to gather additional context on the endpoint associated with the user account. For example, run the following query to check for recent login activities:
+  ```sql
+  SELECT * FROM last WHERE username = '<user.name>';
+  ```
+- Check for any recent changes to the user's account settings or permissions that could have facilitated the unauthorized access attempt.
+- Collaborate with the IT or security team to gather additional logs or data from network devices, firewalls, or other security tools to correlate with the Okta event and build a comprehensive timeline of the incident.
+
+### False positive analysis
+
+- Employees using new devices or networks may trigger unauthorized access alerts if their login attempts are flagged as unusual. To manage this, consider creating exceptions for known employee devices or IP addresses.
+- Automated scripts or applications that interact with Okta using service accounts might be misidentified as unauthorized access attempts. Regularly review and whitelist these service accounts to prevent false positives.
+- Third-party integrations or applications that require frequent authentication checks can generate alerts. Ensure these integrations are documented and create exceptions for their expected behavior.
+- Users who frequently travel or work remotely might access Okta from various locations, leading to false positives. Implement geolocation-based exceptions for these users to reduce unnecessary alerts.
+- Temporary access granted to contractors or partners can be mistaken for unauthorized access. Maintain an updated list of authorized external users and adjust the detection rule to accommodate their access patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying any other compromised accounts or systems.
+- Review Okta logs and other relevant security logs to trace the adversary's actions and identify any additional unauthorized access attempts.
+- Reset passwords for the affected account and any other accounts that may have been compromised, ensuring the use of strong, unique passwords.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement multi-factor authentication (MFA) for all user accounts to enhance security and prevent future unauthorized access.
+- Review and update logging policies to ensure comprehensive monitoring of all authentication and access events in Okta.
+- Integrate Okta with a security information and event management (SIEM) system to enable real-time monitoring and alerting of suspicious activities.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
+- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent credential theft.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
index 2da36ae59b4..408b58d2b6b 100644
--- a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
+++ b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -40,6 +40,51 @@ event.dataset: "okta.system"
     and event.outcome: "success"
     and okta.client.device: ("Unknown" or "unknown")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Successful Application SSO from Rare Unknown Client Device
+
+Single sign-on (SSO) streamlines user access across applications by using a single set of credentials. However, if compromised, it can be exploited by attackers to bypass security policies. Adversaries may leverage vulnerabilities to gain unauthorized access using stolen credentials. The detection rule identifies unusual SSO events from unknown devices, signaling potential misuse of valid accounts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a successful SSO event from an unknown client device by checking the `event.dataset`, `event.action`, `event.outcome`, and `okta.client.device` fields.
+- Verify the user account involved in the SSO event by examining the user details in the alert and cross-referencing with known user activity and access patterns.
+- Check the user-agent string associated with the SSO event to identify any anomalies or inconsistencies that could indicate spoofing or the use of unauthorized devices.
+- Investigate the IP address associated with the SSO event to determine its geolocation and assess whether it aligns with the user's typical access locations.
+- Review recent login history for the user account to identify any other unusual or suspicious login attempts, especially from unknown devices or locations.
+- Utilize Osquery to gather additional context on the device involved in the SSO event. For example, run the following Osquery query to check for recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_ADDRESS_FROM_ALERT>';`
+- Examine Okta logs for any recent changes to the user's account settings or permissions that could indicate account compromise or unauthorized access.
+- Check for any other security alerts or incidents involving the same user account or IP address to identify potential patterns of malicious activity.
+- Collaborate with the user to verify whether they recognize the device and the SSO event, and gather any additional context they can provide about their recent activities.
+- Review the organization's security policies and configurations related to SSO and Okta to ensure they are properly enforced and have not been bypassed or misconfigured.
+
+### False positive analysis
+
+- Employees using new or updated devices may trigger false positives if the device is not yet recognized by the system. This can occur when users upgrade their hardware or use a different browser that alters the user-agent string.
+- Remote workers accessing applications from different locations or networks, such as public Wi-Fi or VPNs, might appear as unknown devices, leading to false positives.
+- IT personnel conducting legitimate testing or troubleshooting activities on unregistered devices can also trigger this rule.
+- To manage these false positives, organizations can create exceptions for known and trusted devices by maintaining an updated inventory of user devices and their corresponding user-agent strings.
+- Implementing a process to quickly verify and whitelist new devices for regular users can help reduce unnecessary alerts.
+- Regularly reviewing and updating network and device policies to reflect changes in user behavior and technology can minimize false positives.
+- Encourage users to report new devices or changes in their access patterns to IT, allowing for proactive adjustments to the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the breach, focusing on identifying any other accounts accessed from the same unknown device.
+- Review Okta logs and cross-reference with other security logs to identify any lateral movement or additional suspicious activities.
+- Reset passwords for compromised accounts and enforce multi-factor authentication (MFA) for all users to mitigate the risk of future unauthorized access.
+- Escalate the incident to the security operations center (SOC) and inform relevant stakeholders, including IT and management, to ensure coordinated response efforts.
+- Apply patches or updates to Okta's Classic Engine to address any known vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed user-agent strings and device information for future investigations.
+- Integrate Okta with a security information and event management (SIEM) system to enable real-time monitoring and alerting of suspicious SSO activities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent credential theft."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
index 12c7bfaf265..17b4d76a13b 100644
--- a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
+++ b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -17,7 +17,54 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Suspicious Activity Reported by Okta User"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Activity Reported by Okta User
+
+Okta is an identity management service that enables secure user authentication and access control. Adversaries may exploit valid user accounts to gain unauthorized access, bypassing security measures. The detection rule monitors for user-reported suspicious activity, signaling potential account compromise. By analyzing these alerts, security teams can identify and mitigate unauthorized access attempts, aligning with MITRE ATT&CK's Initial Access tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is `okta.system` and the event action is `user.account.report_suspicious_activity_by_enduser`.
+- Verify the identity of the user who reported the suspicious activity by checking their user profile and recent login history in Okta.
+- Analyze the user's login history for any unusual patterns, such as logins from unfamiliar IP addresses or locations.
+- Check for any recent changes to the user's account settings, such as password changes or multi-factor authentication (MFA) modifications.
+- Investigate any other alerts or logs related to the same user account within the same timeframe to identify potential correlations.
+- Use Osquery to gather additional context on the user's device. For example, run the following query to check for recent login attempts on the user's machine:
+  ```sql
+  SELECT * FROM last WHERE username = '<username>';
+  ```
+- Examine network logs for any suspicious activity originating from the IP addresses associated with the reported suspicious activity.
+- Cross-reference the reported suspicious activity with known threat intelligence sources to identify any indicators of compromise (IOCs).
+- Review any recent changes in user permissions or access levels that could indicate unauthorized privilege escalation.
+- Document all findings and observations in a centralized investigation report to facilitate further analysis and decision-making.
+
+### False positive analysis
+
+- Known false positives for the Suspicious Activity Reported by Okta User rule may include legitimate users mistakenly reporting their own activity as suspicious, such as logging in from a new device or location that they forgot to whitelist.
+- Users may also report suspicious activity when they receive unexpected but legitimate security alerts or notifications from Okta, leading to unnecessary investigations.
+- To manage these false positives, security teams can implement exception lists for users who frequently report non-threatening activities, ensuring that their reports are reviewed with context.
+- Establishing a baseline of normal user behavior can help differentiate between genuine threats and benign activities, reducing the number of false positives.
+- Educating users on recognizing legitimate security alerts and understanding their own activity patterns can minimize incorrect reports and improve the accuracy of threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further unauthorized access and limit potential damage.
+- Conduct a thorough investigation of the reported suspicious activity, reviewing logs and user actions to determine the scope and impact of the incident.
+- Reset the compromised user's password and enforce multi-factor authentication (MFA) to enhance account security.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader threat or multiple compromised accounts.
+- Implement enhanced logging and monitoring for Okta and related systems to detect similar activities in the future, ensuring logs are retained for an appropriate period.
+- Integrate Okta with a security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
+- Review and update access control policies to ensure the principle of least privilege is enforced across the organization.
+- Conduct a post-incident review to identify gaps in the current security posture and develop an action plan to address them.
+- Educate users on security best practices and the importance of reporting suspicious activities promptly to prevent future incidents.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
index 9d015d679b8..c4606ed7e3d 100644
--- a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
+++ b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -20,7 +20,51 @@ interval = "30m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Multiple Okta Sessions Detected for a Single User"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Multiple Okta Sessions Detected for a Single User
+
+Okta is a widely used identity management service that facilitates secure user authentication across various applications. Adversaries may exploit session cookies to hijack user accounts, initiating unauthorized sessions from different locations. The detection rule identifies anomalies by flagging multiple active sessions with distinct IDs for a single user, excluding legitimate Okta system actors, thus highlighting potential session hijacking attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the user account involved and the specific session IDs that triggered the alert.
+- Verify the legitimacy of the user by checking recent login activities and patterns for any anomalies or deviations from the norm.
+- Use the `okta.authentication_context.external_session_id` field to correlate and identify all active sessions associated with the user account.
+- Investigate the `okta.actor.id` and `okta.actor.display_name` fields to ensure that the sessions are not initiated by legitimate Okta system actors.
+- Examine the geographical locations and IP addresses associated with each session to identify any unusual or unexpected access points.
+- Check for any recent changes in the user's account settings or permissions that could indicate unauthorized access.
+- Utilize Osquery to gather additional context on the user's device by running a query such as: `SELECT * FROM logged_in_users WHERE user = '<username>';` to identify any suspicious logins or processes.
+- Review any recent Okta system logs for failed login attempts or other suspicious activities that could be related to the session hijacking.
+- Cross-reference the session data with other security logs (e.g., firewall, VPN) to identify any correlated suspicious activities or access patterns.
+- Engage with the user to confirm whether they recognize the sessions and if they have recently accessed their account from multiple devices or locations.
+
+### False positive analysis
+
+- Legitimate use of multiple devices: Users may legitimately access their accounts from multiple devices, such as a laptop and a smartphone, leading to multiple session IDs. To manage this, organizations can create exceptions for users who frequently use multiple devices.
+- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing their accounts from various locations. Implementing geolocation-based exceptions for known travel patterns can help reduce false positives.
+- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Organizations should consider policy adjustments or exceptions for shared accounts to prevent unnecessary alerts.
+- Use of VPNs or proxy services: Users employing VPNs or proxy services may appear to have sessions from different locations. Identifying and excluding known VPN or proxy IP addresses can help mitigate these false positives.
+- Automated scripts or integrations: Some users may have automated scripts or integrations that initiate multiple sessions. Reviewing and excluding these known scripts or integrations can prevent false alerts.
+
+### Response and remediation
+
+- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access.
+- Notify the user of the suspicious activity and instruct them to change their password and review their account activity for any unauthorized actions.
+- Conduct a thorough investigation to determine the source of the session hijacking, including reviewing logs for unusual IP addresses or user-agent strings.
+- Escalate the incident to the security operations team if evidence of a broader compromise or lateral movement is detected.
+- Implement multi-factor authentication (MFA) for all user accounts to add an additional layer of security against session hijacking.
+- Review and enhance logging policies to ensure comprehensive capture of authentication events and session activities for future investigations.
+- Integrate Okta logs with a Security Information and Event Management (SIEM) system to enable real-time monitoring and alerting of suspicious activities.
+- Apply network segmentation and access controls to limit the potential impact of compromised accounts and restrict lateral movement.
+- Educate users on recognizing phishing attempts and the importance of safeguarding session cookies and credentials.
+- Regularly review and update security policies and procedures to incorporate lessons learned from the incident and align with best practices.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
index 0260f558495..6a2316ddabe 100644
--- a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
+++ b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Administrator Privileges Assigned to an Okta Group"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Administrator Privileges Assigned to an Okta Group
+
+Okta is a widely used identity management service that facilitates secure user authentication and authorization. Administrator roles in Okta grant elevated permissions, allowing significant control over user accounts and settings. Adversaries may exploit this by assigning admin roles to groups, thereby escalating privileges and maintaining unauthorized access. The detection rule monitors system events for privilege grants to groups, identifying potential misuse by flagging suspicious role assignments.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Okta group and the administrator role that was assigned, using the `event.dataset:okta.system` and `event.action:group.privilege.grant` fields for context.
+- Check the Okta system logs for any recent changes or unusual activities related to the group in question, focusing on the timeframe around the alert.
+- Identify the user account that performed the privilege assignment by examining the `actor.id` and `actor.alternateId` fields in the event logs.
+- Investigate the history of the user account that made the change to determine if there are any signs of compromise or unusual behavior, such as logins from unfamiliar locations or devices.
+- Cross-reference the group membership to identify all users who are now granted elevated privileges and assess if any of these accounts show signs of compromise.
+- Use Osquery to gather additional context on the systems used by the user account that made the change. For example, run the following Osquery query to list recent logins on the user's machine: `SELECT * FROM last WHERE username = '<username>';`.
+- Analyze any recent changes to the Okta configuration or policies that might have facilitated the unauthorized privilege assignment.
+- Review any associated alerts or incidents that might provide additional context or indicate a broader attack pattern.
+- Check for any other privilege assignments to groups within the same timeframe to identify potential patterns or coordinated actions.
+- Collaborate with the IT or security team to gather additional context on the business justification for the role assignment, if any, and verify its legitimacy.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may assign administrator roles to groups as part of regular maintenance or onboarding processes. To manage these, users can create exceptions for known administrative actions by whitelisting specific user accounts or groups involved in these tasks.
+- Organizational changes: During mergers, acquisitions, or restructuring, there may be a legitimate need to reassign roles and privileges. Users can handle these by temporarily adjusting the detection thresholds or excluding specific events during the transition period.
+- Automated processes: Some organizations use automated scripts or tools to manage user roles and permissions. These processes might trigger the detection rule. Users can exclude these automated actions by identifying and whitelisting the associated service accounts or scripts.
+- Testing and development: In environments where testing or development occurs, admin roles might be assigned to groups for testing purposes. Users can manage these by creating exceptions for specific test environments or by using separate detection rules for production and non-production environments.
+
+### Response and remediation
+
+- Immediately revoke the administrator privileges assigned to the Okta group to contain potential unauthorized access.
+- Conduct a thorough investigation to identify any compromised accounts within the group and assess the extent of unauthorized access or changes made.
+- Review recent Okta system logs for any suspicious activities or anomalies that coincide with the privilege assignment event.
+- Reset passwords and enforce multi-factor authentication (MFA) for all accounts within the affected group to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive analysis and response.
+- Implement enhanced logging and monitoring policies to capture detailed events related to privilege changes and group assignments in Okta.
+- Integrate Okta with a security information and event management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Conduct a post-incident review to identify gaps in security controls and update policies to prevent similar incidents in the future.
+- Apply hardening measures by limiting the number of users with the ability to assign administrator roles and regularly auditing group memberships.
+- Educate users and administrators on the risks associated with privilege escalation and the importance of adhering to the principle of least privilege.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
index 65649731dde..3da7365ca5c 100644
--- a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
+++ b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,49 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Administrator Role Assigned to an Okta User"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Administrator Role Assigned to an Okta User
+Okta is a widely used identity management service that facilitates secure user authentication and authorization. Administrator roles in Okta grant elevated permissions, allowing users to manage settings and access controls. Adversaries may exploit this by assigning admin roles to themselves or compromised accounts to gain persistent access. The detection rule monitors system events for privilege grants, flagging suspicious admin role assignments to mitigate unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.dataset is "okta.system" and the event.action is "user.account.privilege.grant" to ensure the alert is valid and triggered by the correct rule.
+- Identify the user account that was assigned the administrator role by examining the relevant fields in the alert, such as user.name and user.id.
+- Check the timestamp of the event to determine when the administrator role was assigned and correlate it with any other suspicious activities around that time.
+- Investigate the source IP address and geolocation associated with the event to determine if the access was from an unusual or unexpected location.
+- Review the user's recent login history and activity logs in Okta to identify any anomalies or patterns that could indicate compromise.
+- Examine the change history for the user account to see if there were any recent modifications or unusual activities prior to the role assignment.
+- Use Osquery to gather additional context on the system where the role assignment was made. For example, run the following query to list recent Okta-related processes: `SELECT * FROM processes WHERE name LIKE '%okta%';`
+- Check for any other privilege escalation events or role assignments in the same timeframe to identify potential coordinated attacks or multiple compromised accounts.
+- Review the list of users with administrative roles in Okta to ensure no other unauthorized assignments have occurred.
+- Cross-reference the event with any other security alerts or incidents in your environment to determine if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT staff may frequently assign administrator roles as part of their job responsibilities. To manage this, organizations can create exceptions for known IT personnel or specific time frames when such activities are expected.
+- Automated provisioning systems: Some organizations use automated systems to manage user roles, which might trigger the rule. Users can exclude events originating from these systems by identifying their unique identifiers or IP addresses.
+- Role-based access control updates: Regular updates to role-based access controls might involve temporary admin role assignments. Users can handle these by setting up alerts only for unexpected changes outside of scheduled maintenance windows.
+- Training and onboarding: New administrators might be assigned roles during training or onboarding processes. Organizations can mitigate false positives by excluding events related to new employee onboarding sessions or specific training periods.
+
+### Response and remediation
+
+- Immediately revoke the newly assigned administrator role from the affected Okta user account to prevent further unauthorized access.
+- Conduct a thorough investigation to determine if the role assignment was legitimate or if it indicates a compromise, reviewing recent activity logs for suspicious behavior.
+- Isolate the affected user account by temporarily disabling it until the investigation is complete to prevent potential lateral movement or further privilege escalation.
+- Notify the security team and relevant stakeholders about the incident for awareness and to initiate a coordinated response.
+- Review and enhance logging policies to ensure comprehensive capture of privilege changes and other critical events in Okta for future investigations.
+- Integrate Okta logs with a Security Information and Event Management (SIEM) system to enable real-time monitoring and alerting on suspicious activities.
+- Conduct a root cause analysis to identify how the adversary gained access and assigned the administrator role, addressing any identified vulnerabilities or misconfigurations.
+- Restore the system to its operational state by re-enabling legitimate user accounts and ensuring all security controls are functioning as intended.
+- Implement hardening measures such as multi-factor authentication (MFA) for all administrative accounts and regular audits of user permissions to reduce the risk of future incidents.
+- Escalate the incident to higher management and, if necessary, involve legal or law enforcement agencies if the breach is significant or involves sensitive data.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
index babed655d21..5dea673d71c 100644
--- a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
+++ b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Create Okta API Token"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Create Okta API Token
+
+Okta API tokens are crucial for automating and managing access within an organization's network. They allow seamless integration and interaction with Okta's identity management services. However, adversaries can exploit these tokens to gain persistent access, manipulate user accounts, or disable security measures. The detection rule identifies suspicious token creation activities by monitoring specific Okta system events, helping to thwart unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `event.dataset:okta.system` and `event.action:system.api_token.create` fields, ensuring the alert is valid and corresponds to an API token creation attempt.
+- Identify the user account associated with the token creation attempt by examining the `actor.id` and `actor.alternateId` fields in the event logs.
+- Check the timestamp of the event to determine when the token creation attempt occurred and correlate it with other suspicious activities around the same time.
+- Investigate the IP address and geolocation from which the token creation request originated to identify any anomalies or unexpected locations.
+- Examine the `client.userAgent` field to understand the device and browser used during the token creation attempt, looking for any unusual or unauthorized devices.
+- Review recent login activities for the identified user account to detect any unauthorized access or unusual login patterns.
+- Use Osquery to gather additional context on the system from which the request originated. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious IP address>';`.
+- Check for any recent changes to user permissions or roles associated with the account in question, which might indicate privilege escalation attempts.
+- Analyze other Okta system events around the same timeframe to identify any related suspicious activities, such as failed login attempts or changes to security settings.
+- Collaborate with the IT or security team to verify if the token creation was part of a legitimate administrative task or if it requires further investigation.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may frequently create Okta API tokens for maintenance or integration purposes. To manage these, users can create exceptions for specific administrator accounts or IP addresses known to perform these tasks regularly.
+- Automated processes: Some automated systems or applications might generate Okta API tokens as part of their normal operation. Users should identify these systems and exclude their activities from triggering alerts by whitelisting their associated service accounts or application identifiers.
+- Third-party integrations: Organizations often use third-party services that require Okta API tokens for integration. Users can handle these by maintaining a list of approved third-party services and excluding their token creation activities from detection.
+- Testing environments: In development or testing environments, API tokens might be created frequently for testing purposes. Users can exclude these environments from monitoring by setting up environment-specific exceptions or filters.
+
+### Response and remediation
+
+- Immediately revoke the suspicious Okta API token to prevent further unauthorized access.
+- Conduct a thorough investigation to identify any unauthorized changes made using the token, such as new user accounts or altered security policies.
+- Review Okta system logs to trace the origin of the token creation attempt and identify any associated user accounts or IP addresses.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed API activity and monitor for unusual patterns or behaviors.
+- Integrate Okta with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Restore any unauthorized changes to user accounts or security settings to their original state.
+- Conduct a security review of Okta configurations and permissions to ensure least privilege access is enforced.
+- Educate users and administrators on the importance of API security and the risks associated with token misuse.
+- Regularly review and update security policies and procedures to incorporate lessons learned from the incident and improve future response efforts.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
index a615d4a5740..fbdbac4542a 100644
--- a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
+++ b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,50 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Reset MFA Factors for an Okta User Account"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Reset MFA Factors for an Okta User Account
+
+Okta's MFA system enhances security by requiring multiple verification methods. Adversaries may exploit this by resetting MFA factors, allowing them to register their own and gain unauthorized access. The detection rule identifies such attempts by monitoring specific system events, alerting analysts to potential account manipulation threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `event.dataset:okta.system` and `event.action:user.mfa.factor.reset_all` fields, which indicate an attempt to reset MFA factors.
+- Identify the user account associated with the alert by examining the `user.name` or `user.id` fields in the event data.
+- Check the timestamp of the event to determine when the MFA reset attempt occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the source IP address and geolocation from which the MFA reset attempt was made to assess if it aligns with the user's typical access patterns.
+- Review the user's recent login history and activity logs in Okta to identify any unusual behavior or unauthorized access attempts.
+- Examine any changes to the user's account settings or permissions around the time of the MFA reset attempt to detect potential account manipulation.
+- Utilize Osquery to gather additional context on the user's device, such as running processes or network connections, to identify any signs of compromise. Example Osquery: `SELECT * FROM processes WHERE user = '<username>';`
+- Check for any other alerts or incidents involving the same user account or IP address to identify potential patterns or coordinated attacks.
+- Review the organization's change management and access request logs to verify if the MFA reset was authorized or part of a legitimate request.
+- Collaborate with the user or their manager to confirm whether the MFA reset attempt was expected or if it indicates unauthorized activity.
+
+### False positive analysis
+
+- Routine administrative actions: IT administrators may legitimately reset MFA factors for maintenance or user support, which can trigger the detection rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- User-initiated resets: Users might reset their own MFA factors due to lost devices or personal preference changes. Implement a verification process to confirm user-initiated actions and exclude these from alerts.
+- Automated processes: Some organizations use automated scripts or tools to manage MFA settings, which could be mistaken for malicious activity. Identify and whitelist these processes to prevent false positives.
+- Third-party integrations: Integrations with other security or identity management systems might reset MFA factors as part of their normal operation. Document and exclude these integrations from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Verify the identity of the legitimate user through an out-of-band communication method to ensure they are not compromised.
+- Review recent login and activity logs for the affected account to identify any suspicious behavior or unauthorized access attempts.
+- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices.
+- Conduct a thorough investigation to determine how the adversary gained access to reset the MFA factors, focusing on potential phishing attacks or credential compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other accounts or systems are affected.
+- Implement enhanced logging and monitoring for Okta events, specifically focusing on MFA-related actions, to improve detection of similar threats in the future.
+- Integrate Okta logs with a security information and event management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials and MFA devices.
+- Review and update security policies and procedures related to account management and MFA to incorporate lessons learned from the incident and strengthen defenses against account manipulation.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
index 7373dae2b31..494e1b73a5b 100644
--- a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
+++ b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/01"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,7 +22,53 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Modification or Removal of an Okta Application Sign-On Policy"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 or Removal of an Okta Application Sign-On Policy
+
+Okta's sign-on policies are crucial for enforcing authentication controls within applications, ensuring secure access. Adversaries may target these policies to weaken security, potentially allowing unauthorized access. The detection rule monitors system events for policy updates or deletions, identifying suspicious activities that could indicate attempts to bypass or compromise authentication processes.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `event.action` that triggered the alert, focusing on `application.policy.sign_on.update` or `application.policy.sign_on.rule.delete`.
+- Examine the `event.dataset` field to confirm that the event is from `okta.system`, ensuring the alert is relevant to Okta system events.
+- Identify the user account associated with the event by reviewing the `user.name` or `actor.id` fields to determine if the action was performed by a legitimate user or a potential adversary.
+- Check the `event.time` field to establish a timeline of when the modification or deletion occurred, which can help correlate with other suspicious activities.
+- Investigate the `source.ip` field to determine the origin of the request, identifying if it came from a known or suspicious IP address.
+- Use Osquery to gather additional context on the system from which the modification was made. For example, run the following query to check for recent changes in Okta policies:
+  ```sql
+  SELECT * FROM okta_system_events WHERE action IN ('application.policy.sign_on.update', 'application.policy.sign_on.rule.delete') AND time > (SELECT MAX(time) - INTERVAL '1 DAY' FROM okta_system_events);
+  ```
+- Review recent login activities for the identified user account to check for any unusual patterns or anomalies, such as logins from unfamiliar locations or devices.
+- Analyze the `application.id` or `application.name` fields to determine which specific application’s sign-on policy was modified or deleted, assessing the potential impact on the organization.
+- Cross-reference the event with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack.
+- Consult with the application owner or relevant stakeholders to verify if the policy change was authorized and documented, providing additional context for the investigation.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate updates or deletions of sign-on policies by IT administrators during regular maintenance or policy updates can trigger this rule. To manage this, organizations can create exceptions for known administrative accounts or schedule maintenance windows where such activities are expected.
+- Policy testing and development: During the development or testing of new security policies, changes to sign-on policies may occur frequently. To handle these, organizations can exclude events from test environments or specific development accounts from triggering alerts.
+- Automated policy management tools: Some organizations use automated tools to manage and update security policies, which might result in frequent policy changes. Users can whitelist these tools or their associated accounts to prevent false positives.
+- Mergers or acquisitions: During organizational changes like mergers or acquisitions, policy modifications might be necessary to integrate systems. In such cases, temporary exceptions can be applied to accounts involved in the integration process to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate affected systems or accounts to prevent further unauthorized access.
+- Review Okta system logs to identify the source and scope of the policy modification or deletion.
+- Verify the integrity of other sign-on policies to ensure no additional unauthorized changes have been made.
+- Restore the original sign-on policy from backups or recreate it based on documented security requirements.
+- Conduct a thorough investigation to determine if any unauthorized access occurred during the policy modification period.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for Okta policy changes to detect future unauthorized modifications promptly.
+- Integrate Okta with a Security Information and Event Management (SIEM) system for centralized monitoring and alerting.
+- Educate users and administrators on the importance of maintaining strong authentication policies and recognizing potential security threats.
+- Review and update security policies and procedures to incorporate lessons learned from the incident and improve overall security posture.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
index d3ae5ec27f7..ca1ef972651 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/19"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,48 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process Spawned by a Host
+
+The detection of unusual processes on a host leverages machine learning to identify anomalies in process behavior, particularly on systems not typically associated with malicious activity. Adversaries may exploit legitimate system binaries, known as LOLbins, to evade detection. The detection rule utilizes the ProblemChild ML model to flag processes that deviate from normal patterns, focusing on tactics like System Binary Proxy Execution to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process flagged as unusual, including the process name, path, and the host on which it was detected.
+- Check the process's parent process to understand the context of how it was spawned and whether it aligns with typical behavior for that host.
+- Investigate the user account associated with the process to determine if it is a legitimate user and if the activity aligns with their normal behavior.
+- Examine the process's command line arguments for any suspicious or unexpected parameters that could indicate malicious intent.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process and command line details: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<suspicious_process_name>';`
+- Cross-reference the process with known LOLbins to determine if it is a legitimate system binary being used in an unusual manner.
+- Analyze recent system logs and security events on the host to identify any other anomalies or related activities that occurred around the same time as the process execution.
+- Check for any network connections initiated by the process to external IP addresses, which could indicate data exfiltration or command and control communication.
+- Review any recent changes or updates to the host that could have introduced the unusual process, such as software installations or configuration changes.
+- Consult threat intelligence sources to see if the process or its behavior has been associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Known false positives for the Unusual Process Spawned by a Host rule often involve legitimate administrative tools or scripts that are used in non-standard ways, which may be flagged by the ProblemChild ML model. These can include system maintenance scripts or software updates that utilize system binaries in a manner similar to LOLbins.
+- Users can manage these false positives by creating exceptions for processes that are identified as non-threatening through consistent monitoring and verification. This involves analyzing the context in which the process is executed, such as the user account initiating the process and the frequency of its occurrence.
+- To handle frequent non-threatening behaviors, users can implement allowlists for specific processes or paths that are known to be safe, ensuring that these are regularly reviewed and updated to reflect any changes in the environment.
+- It is important to maintain a balance between reducing false positives and ensuring that potential threats are not overlooked, which can be achieved by continuously refining the detection rules and incorporating feedback from security teams.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further malicious activity and lateral movement.
+- Analyze the suspicious process and its parent processes to understand the scope and potential impact of the activity.
+- Terminate the suspicious process if it is confirmed to be malicious or unauthorized.
+- Review system logs and security alerts to identify any additional indicators of compromise or related activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and threat intelligence correlation.
+- Implement enhanced logging policies to capture detailed process execution data and network activity for future analysis.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities against similar threats.
+- Restore the system to its operational state by applying necessary patches, updates, and security configurations.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement system hardening measures, such as restricting the use of LOLbins and enforcing application whitelisting, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
index 479bddbead7..03c093fa95b 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,49 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process Spawned by a Parent Process
+
+In modern security environments, machine learning models are pivotal in identifying anomalies. The detection rule leverages both supervised and unsupervised ML to flag processes that deviate from normal behavior, indicating potential misuse of legitimate tools (LOLBins) by adversaries. By correlating unusual child processes with known malicious patterns, it effectively uncovers stealthy tactics like masquerading, enhancing defense against evasion techniques.
+
+### Possible investigation steps
+
+- Review the alert details to identify the parent and child process names, process IDs, and the timestamp of the event.
+- Cross-reference the parent and child process names against known legitimate and malicious process lists to assess their typical behavior and reputation.
+- Use Osquery to gather additional context about the processes. For example, run the following query to retrieve details about the child process: `SELECT * FROM processes WHERE pid = <child_process_id>;`.
+- Investigate the command line arguments used by the child process to identify any suspicious or unusual parameters that may indicate malicious activity.
+- Check the parent process's historical behavior to determine if spawning the flagged child process is typical or anomalous for this parent.
+- Analyze the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Examine the network connections established by the child process using Osquery: `SELECT * FROM process_open_sockets WHERE pid = <child_process_id>;` to identify any unusual or unauthorized external communications.
+- Review recent system logs and security events around the time of the alert to identify any correlated activities or anomalies.
+- Investigate any file modifications or registry changes made by the child process to assess potential persistence mechanisms or system alterations.
+- Consult threat intelligence sources to determine if the process behavior or associated indicators of compromise (IOCs) match known attack patterns or campaigns.
+
+### False positive analysis
+
+- Known false positives for the Unusual Process Spawned by a Parent Process rule often involve legitimate administrative tools or scripts that are frequently used in enterprise environments. These tools may be flagged due to their unusual execution patterns or names that resemble known malicious processes.
+- Users can manage these false positives by creating exceptions for processes that are regularly used and verified as safe within their organization. This can be done by maintaining a whitelist of known benign processes or by configuring the detection system to ignore specific parent-child process relationships that are deemed non-threatening.
+- It's important to regularly review and update these exceptions to ensure they reflect current operational practices and do not inadvertently allow new threats to go undetected.
+- In environments where certain processes are known to exhibit behavior similar to LOLBins but are part of routine operations, users should document these cases and adjust the detection thresholds or rules accordingly to minimize unnecessary alerts.
+- Collaboration with IT and security teams is crucial to accurately identify and exclude these benign processes without compromising the overall security posture.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the unusual process and its parent process to determine the scope and impact of the activity.
+- Terminate the suspicious process and any associated processes that are confirmed to be malicious.
+- Review and analyze logs to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
+- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected anomalies with known threat patterns and adversary tactics.
+- Restore the system to its operational state by applying necessary patches, updates, and security configurations.
+- Conduct a post-incident review to identify gaps in detection and response capabilities and update security policies accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
index 14b9364879e..b1611718cce 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,48 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process Spawned by a User
+
+The detection of unusual processes spawned by users leverages machine learning to identify anomalies in user behavior and process execution. Adversaries may exploit legitimate tools, known as LOLbins, to evade detection by masquerading malicious activities as benign processes. This detection rule employs both supervised and unsupervised ML models to flag processes that deviate from typical user patterns, indicating potential misuse or malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name, user context, and timestamp of the unusual process execution.
+- Cross-reference the process name with known legitimate tools and LOLbins to determine if it is commonly used for legitimate purposes or known for malicious activity.
+- Analyze the user context to understand if the user typically runs such processes. Check historical data for any previous instances of this process being executed by the same user.
+- Investigate the parent process that spawned the unusual process to determine if it is a legitimate process or potentially compromised.
+- Use Osquery to gather additional context about the process. For example, run the following query to retrieve details about the process and its parent: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name = '<process_name>';`
+- Check for any recent changes in the user's behavior or system configuration that might explain the unusual process execution.
+- Examine network connections initiated by the process to identify any suspicious or unexpected external communications.
+- Review system logs and security events around the time of the process execution for any related anomalies or indicators of compromise.
+- Correlate the findings with other security alerts or incidents to determine if this is part of a broader attack campaign.
+- Document all findings and observations to provide a comprehensive overview of the investigation, which can be used for further analysis or reporting.
+
+### False positive analysis
+
+- Known false positives for the Unusual Process Spawned by a User rule may include legitimate administrative tools or scripts that are infrequently used but necessary for specific tasks, such as system updates or maintenance activities, which may be flagged due to their atypical execution patterns.
+- Users can manage these false positives by creating exceptions for processes that are verified as non-threatening. This can be done by analyzing the context in which these processes are executed, such as the time, user, and system involved, and then configuring the ML models to recognize these patterns as benign.
+- Another common false positive scenario involves software updates or installations that temporarily alter user behavior or process execution patterns. Users should document these occurrences and adjust the detection parameters to accommodate such changes without compromising security.
+- To handle false positives effectively, users should regularly review flagged processes and update the exception list to include any new legitimate processes that are consistently misclassified, ensuring that the detection system remains accurate and efficient.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the flagged process, including reviewing process execution details, parent processes, and associated user activity.
+- Utilize endpoint detection and response (EDR) tools to analyze the system for additional indicators of compromise (IOCs) and identify any persistence mechanisms.
+- Terminate the suspicious process and remove any associated files or artifacts identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team if the process is confirmed to be malicious or if there is evidence of broader compromise.
+- Implement enhanced logging policies to capture detailed process execution and user activity for future analysis and detection.
+- Integrate threat intelligence feeds to enrich alerts with context and improve detection capabilities against known LOLbins and masquerading techniques.
+- Restore the system to its operational state by applying necessary patches, updates, and verifying system integrity.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly.
+- Implement hardening measures such as application whitelisting, user behavior analytics, and least privilege access controls to reduce the risk of similar incidents in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
index 6e6e84e73d4..c9465a4e9e9 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,49 @@ query = '''
 process where ((problemchild.prediction == 1 and problemchild.prediction_probability > 0.98) or
 blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
+
+The detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit this by masquerading legitimate processes to evade detection. The rule flags processes with high malicious scores or those on a blocklist, excluding known benign activities, to pinpoint potential threats effectively.
+
+### Possible investigation steps
+
+- Review the process details flagged by the alert, focusing on the `process.args` field to understand the command line arguments used, which may provide insights into the process's intent.
+- Check the `problemchild.prediction_probability` score to assess the confidence level of the machine learning model in classifying the process as malicious.
+- Investigate the parent process of the flagged event to determine if it is a legitimate process or if it has been compromised, using the `process.parent` field.
+- Cross-reference the process name and path against known legitimate software and common masquerading techniques to identify potential false positives.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with similar names or paths: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%<suspicious_process_name>%' OR path LIKE '%<suspicious_process_path>%';`
+- Examine the process's network activity to identify any suspicious connections or data exfiltration attempts, using network monitoring tools or logs.
+- Check for any recent changes or anomalies in the system's file integrity, focusing on the directories and files associated with the flagged process.
+- Review the system's event logs for any related security events or anomalies that occurred around the same time as the suspicious process execution.
+- Investigate the user account associated with the process execution to determine if it has been compromised or is exhibiting unusual behavior.
+- Correlate the findings with threat intelligence sources to identify if the process or its behavior matches any known threat actor techniques or campaigns.
+
+### False positive analysis
+
+- Known false positives for the Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score rule may include legitimate processes that mimic suspicious patterns, such as system updates or software installations that temporarily exhibit unusual behavior.
+- Users can manage these false positives by creating exceptions for processes that are verified as non-threatening, such as those related to trusted software updates or internal IT scripts.
+- Regularly review and update the blocklist and exception list to ensure that legitimate processes are not inadvertently flagged, especially after system updates or changes in software configurations.
+- Consider implementing additional context checks, such as verifying the digital signature of flagged processes, to differentiate between legitimate and malicious activities.
+- Engage with security teams to analyze flagged events and refine the machine learning model's parameters to reduce the likelihood of false positives while maintaining effective threat detection.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the flagged process to confirm its malicious nature, using forensic tools to analyze process behavior and associated files.
+- Review and cross-reference the process with known threat intelligence sources to identify any indicators of compromise (IOCs) related to the detected activity.
+- If confirmed malicious, terminate the process and remove any associated files or registry entries to prevent persistence.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and reduce false positives.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are correctly set.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement hardening measures such as application whitelisting, disabling unnecessary services, and enforcing least privilege access to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
index 12ba9cd1c50..153c2e86a99 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint"]
 maturity = "production"
-updated_date = "2024/08/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,53 @@ query = '''
 process where ((problemchild.prediction == 1 and problemchild.prediction_probability <= 0.98) or
 blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a Low Malicious Probability Score
+
+The detection leverages a machine learning model, ProblemChild, to identify potentially suspicious Windows processes. It flags events with a low probability of being malicious, focusing on defense evasion tactics like masquerading. Adversaries may exploit this by disguising malicious processes as legitimate ones. The rule detects such anomalies by analyzing process predictions and blocklist matches, excluding known benign patterns.
+
+### Possible investigation steps
+
+- Review the process details flagged by the ProblemChild model, focusing on the `process.args` field to understand the command line arguments used during execution.
+- Check the `problemchild.prediction_probability` to assess how close the event is to being considered benign, and prioritize investigation based on lower probabilities.
+- Investigate the `blocklist_label` to determine if the process is explicitly marked as malicious by the blocklist, which may indicate a higher risk.
+- Examine the parent process of the flagged event to identify if it was spawned by a known legitimate process or a potentially suspicious one.
+- Use Osquery to gather additional context about the process. For example, run the following query to get details about the process and its parent: 
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE pid = <flagged_process_pid>;
+  ```
+- Cross-reference the process path and name with known legitimate software to rule out false positives due to masquerading.
+- Analyze recent system logs and events around the time of the flagged process execution to identify any correlated suspicious activities.
+- Check for any recent changes or anomalies in the system's file system, registry, or network connections that could be related to the flagged process.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it shows signs of compromise.
+- Review historical data to see if the flagged process or similar processes have been detected previously, which might indicate a recurring issue or false positive pattern.
+
+### False positive analysis
+
+- Known false positives for this rule often include legitimate system processes or third-party applications that mimic common Windows processes for compatibility or performance reasons. These can be mistakenly flagged due to their resemblance to malicious activities.
+- Users may encounter false positives from software updates or installations that temporarily alter process names or paths, triggering the masquerading detection.
+- To manage these false positives, users can create exceptions for specific processes or paths that are consistently flagged but verified as non-threatening. This can be done by updating the rule to exclude these known benign patterns.
+- Regularly review and update the blocklist and exception list to ensure that new legitimate processes are not mistakenly flagged as threats.
+- Collaborate with IT and security teams to maintain a list of approved software and processes, which can be referenced when analyzing flagged events to quickly identify false positives.
+- Consider implementing additional context checks, such as verifying the digital signature of a process, to reduce the likelihood of false positives related to legitimate software masquerading as system processes.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the flagged process to determine if it is indeed masquerading as a legitimate process.
+- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
+- Utilize the MITRE ATT&CK framework to understand the adversary's tactics, techniques, and procedures, focusing on Defense Evasion and Masquerading.
+- If confirmed malicious, remove or quarantine the identified process and any associated files from the system.
+- Update antivirus and endpoint detection and response (EDR) solutions to block similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and machine learning models with existing security information and event management (SIEM) systems for improved detection capabilities.
+- Restore the system to its operational state by applying necessary patches, updates, and security configurations to prevent reoccurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
index 0b7e329bef3..40fba83f661 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,49 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Host
+
+The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries may exploit legitimate binaries, known as LOLbins, to evade detection by masquerading them as benign processes. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific processes flagged as suspicious, including their names, paths, and associated host names.
+- Cross-reference the flagged processes with known legitimate binaries (LOLbins) to determine if they are being used in an unusual context.
+- Analyze the process tree to understand the parent-child relationships and identify any unusual process spawning patterns.
+- Check the process execution times and compare them with normal activity patterns for the host to identify anomalies.
+- Use Osquery to gather additional context on the suspicious processes. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name IN ('<suspicious_process_name>');`
+- Investigate the network connections initiated by the suspicious processes to identify any unusual or unauthorized external communications.
+- Examine the file hashes of the suspicious binaries and compare them against threat intelligence databases to check for known malicious signatures.
+- Review the user accounts associated with the execution of the suspicious processes to determine if there are signs of compromised credentials or privilege escalation.
+- Analyze the system logs for any additional indicators of compromise or related suspicious activities around the time the processes were executed.
+- Correlate the findings with other security alerts or incidents to determine if the suspicious processes are part of a larger attack campaign.
+
+### False positive analysis
+
+- Known false positives for the Suspicious Windows Process Cluster Spawned by a Host rule may include legitimate administrative tools or scripts that are frequently used in the environment but are flagged due to their resemblance to LOLbins or unusual execution patterns.
+- Users can handle these false positives by creating exceptions for specific processes or process clusters that are regularly observed and verified as non-threatening. This can be done by whitelisting certain process names or paths that are known to be safe.
+- It is important to regularly review and update these exceptions to ensure that they do not inadvertently allow malicious activity to go undetected. This involves monitoring the environment for changes in legitimate process behavior and adjusting the exceptions accordingly.
+- In environments where certain processes are known to execute with high frequency, users can adjust the sensitivity of the ML models or set thresholds to reduce the likelihood of these processes being flagged as suspicious.
+- Collaboration with IT and security teams to understand the context of flagged processes can help in distinguishing between false positives and genuine threats, ensuring that only benign activities are excluded from alerts.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation of the flagged processes to confirm malicious activity, focusing on identifying any LOLbins or masquerading techniques used.
+- Terminate any identified malicious processes and remove any associated files or artifacts from the system.
+- Review and analyze system logs and security alerts to understand the scope of the attack and identify any additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are in place.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement hardening measures such as application whitelisting, disabling unnecessary services, and enforcing strict access controls to reduce the risk of future attacks."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
index 7e06990450b..abbf3125613 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,52 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Parent Process
+
+The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores, often linked to a common parent process. Adversaries exploit this by using legitimate binaries (LOLBins) to evade detection. The rule combines supervised and unsupervised ML models to flag anomalies, focusing on clusters with unusually high aggregate scores, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the parent process name and the associated child processes that triggered the alert. Focus on the aggregate score and individual malicious probability scores.
+- Cross-reference the parent process name with known legitimate binaries (LOLBins) to determine if it is commonly used for evasion techniques.
+- Use endpoint detection and response (EDR) tools to gather additional context on the parent process, including its command line arguments, execution path, and any associated network activity.
+- Investigate the timeline of the parent process and its child processes to identify any unusual patterns or sequences of execution that deviate from normal behavior.
+- Check the parent process and child processes against threat intelligence databases to see if they are associated with known malicious activity or threat actors.
+- Utilize Osquery to gather more information about the suspicious processes. For example, run the following query to list all processes spawned by the parent process:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = '<parent_process_name>');
+  ```
+- Analyze the file hashes of the suspicious processes using a threat intelligence platform to determine if they are known malware.
+- Examine the user account context under which the parent process and its child processes were executed to assess if there is any indication of compromised credentials.
+- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the process cluster.
+- If applicable, check for any recent changes or updates to the system or software that could explain the unusual process behavior, ensuring to rule out false positives.
+
+### False positive analysis
+
+- Known false positives for the Suspicious Windows Process Cluster Spawned by a Parent Process rule often involve legitimate administrative tools or scripts that are frequently used in enterprise environments. These tools may include PowerShell scripts, system management software, or other automation tools that mimic the behavior of malicious processes.
+- Users can handle these false positives by creating exceptions for specific parent processes that are known to spawn legitimate clusters of processes. This can be done by maintaining a whitelist of trusted parent process names or paths that are regularly reviewed and updated.
+- Another method to manage false positives is to analyze the context of the detected processes, such as the time of execution, user account involved, and network activity. This can help differentiate between benign and potentially malicious activities.
+- It is also recommended to monitor the frequency and pattern of these process clusters. If a particular cluster is consistently flagged but is known to be part of routine operations, it can be excluded from future alerts.
+- Collaboration with IT and security teams to understand the normal behavior of systems and applications can aid in refining the detection rules and reducing false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the parent process and its spawned processes to identify any malicious behavior or indicators of compromise.
+- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activity.
+- Review and analyze logs from the affected system to gather additional context and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected anomalies with known threat actors and tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by applying the latest security patches and updates, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in detection and response capabilities, and update security policies and procedures accordingly.
+- Implement system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
index a010cb7e723..84fdb9304ba 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,48 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a User
+The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries may exploit legitimate binaries (LOLBins) to evade detection, masquerading as benign processes. This rule uses both supervised and unsupervised ML models to flag anomalies, focusing on clusters with shared user names and high aggregate scores, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific processes flagged as suspicious, focusing on the user name and the aggregate malicious probability score.
+- Cross-reference the flagged processes with known legitimate binaries (LOLBins) to determine if they are being used in an unusual context or manner.
+- Use process lineage analysis to trace the parent and child processes of the flagged processes, identifying any unusual or unexpected process relationships.
+- Investigate the user account associated with the suspicious processes to determine if there have been any recent changes in behavior or access patterns.
+- Check for any recent logins or access attempts from unusual locations or devices for the user associated with the suspicious processes.
+- Utilize Osquery to gather additional context on the suspicious processes. For example, run the following query to list all processes started by the user in question: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
+- Examine network connections initiated by the suspicious processes to identify any unusual or unauthorized external communications.
+- Review recent file modifications or creations by the suspicious processes to detect any potential data exfiltration or tampering activities.
+- Analyze system logs for any other anomalies or errors that coincide with the time frame of the suspicious process activity.
+- Correlate the findings with other security tools and logs to build a comprehensive picture of the potential threat and its scope.
+
+### False positive analysis
+
+- Legitimate administrative tools: Some legitimate administrative tools and scripts may trigger false positives due to their similarity to known malicious patterns. Users should review these alerts and consider adding exceptions for trusted tools frequently used in their environment.
+- Software updates and installations: During software updates or installations, processes may exhibit behaviors that resemble malicious activity. Users can mitigate these false positives by creating exceptions for known update processes or installation scripts.
+- Custom scripts and automation: Custom scripts or automated tasks that perform system-level operations might be flagged as suspicious. Users should evaluate these scripts and, if deemed safe, exclude them from detection to prevent unnecessary alerts.
+- Frequent use of LOLBins: In environments where legitimate use of LOLBins is common, such as in development or testing, these processes might be incorrectly classified as malicious. Users should identify and exclude these benign uses to reduce false positives.
+- Shared user accounts: Environments with shared user accounts may see higher false positive rates due to the aggregation of process scores. Users should consider monitoring these accounts separately or implementing more granular user tracking to better assess the context of alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the flagged processes to confirm malicious activity, focusing on the use of LOLBins and masquerading techniques.
+- Terminate any identified malicious processes and remove any associated files or executables from the system.
+- Review and analyze user account activity to identify any unauthorized access or privilege escalation attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and user activity, aiding in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and verifying system integrity.
+- Conduct a security awareness session for users to educate them on recognizing and reporting suspicious activities.
+- Implement system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/linux/collection_linux_clipboard_activity.toml b/rules/linux/collection_linux_clipboard_activity.toml
index ab497282884..4134ee47e56 100644
--- a/rules/linux/collection_linux_clipboard_activity.toml
+++ b/rules/linux/collection_linux_clipboard_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,48 @@ event.action:("exec" or "exec_event" or "executed" or "process_started") and
 process.name:("xclip" or "xsel" or "wl-clipboard" or "clipman" or "copyq") and
 not process.parent.name:("bwrap" or "micro")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Linux Clipboard Activity Detected
+
+Clipboard utilities on Linux facilitate data transfer between applications, enhancing user productivity. However, adversaries can exploit these tools to capture sensitive information copied by users. The detection rule identifies unusual clipboard activity by monitoring specific utilities initiated by uncommon process leaders, flagging potential unauthorized data collection attempts. This approach helps in identifying and mitigating clipboard-based data exfiltration threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which clipboard utility was triggered and the associated process leader by examining the `process.name` and `process.parent.name` fields.
+- Verify the legitimacy of the parent process by checking its usual behavior and purpose on the system, focusing on the `process.parent.name` field.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior by examining the `user.name` field.
+- Check the process command line arguments for any unusual or suspicious parameters using the `process.command_line` field.
+- Correlate the event with other recent process start events on the host to identify any patterns or anomalies using the `event.category:process` and `event.type:start` fields.
+- Use Osquery to list recent clipboard-related processes and their parent processes with a query like: `SELECT pid, name, parent, path FROM processes WHERE name IN ('xclip', 'xsel', 'wl-clipboard', 'clipman', 'copyq');`
+- Investigate the network activity of the host around the time of the alert to identify any potential data exfiltration attempts.
+- Review system logs for any other suspicious activities or errors that occurred around the same time as the clipboard event.
+- Check for any recent changes in user permissions or group memberships that might explain the unusual process initiation.
+- Consult with the user or system owner to verify if the clipboard activity was expected or authorized, providing context from the gathered data.
+
+### False positive analysis
+
+- Known false positives for the Linux Clipboard Activity Detected rule may include legitimate applications or scripts that frequently use clipboard utilities for automation or data processing tasks. These can be triggered by system administrators or developers who use scripts to automate data transfer between applications.
+- Users can handle these false positives by creating exceptions for specific process parent names or user accounts that are known to perform legitimate clipboard operations. This can be done by updating the detection rule to exclude these known benign activities.
+- Another common false positive scenario involves desktop environments or window managers that use clipboard utilities as part of their normal operation. Users should identify these environments and exclude their process parent names from the detection rule.
+- To manage false positives effectively, users should regularly review and update the list of excluded process parent names and user accounts based on observed activity patterns and organizational needs. This ensures that only non-threatening behaviors are excluded while maintaining the integrity of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the clipboard activity, focusing on the uncommon process leaders identified in the alert.
+- Review system logs and process execution history to determine if any unauthorized data access or transfer occurred.
+- If malicious activity is confirmed, remove any unauthorized software or scripts that may have been used to capture clipboard data.
+- Change passwords and credentials that may have been exposed through clipboard activity to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and clipboard activity for future investigations.
+- Integrate threat intelligence feeds to correlate clipboard activity with known threat actors or campaigns.
+- Restore the system to its operational state by applying security patches and updates, and ensure all security configurations are properly set.
+- Harden the system by restricting clipboard access to trusted applications and users, and consider using application whitelisting to prevent unauthorized process execution."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
index 67bd077656d..d17f37ac6ed 100644
--- a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
+++ b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,49 @@ timestamp_override = "event.ingested"
 query = '''
 host.os.type: "linux" and event.category: "process" and process.name: "aws" and process.args:  "--endpoint-url"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS CLI Command with Custom Endpoint URL
+
+The AWS CLI allows users to interact with AWS services via command-line, offering flexibility in managing cloud resources. The `--endpoint-url` option lets users specify alternative endpoints, which can be exploited by adversaries to reroute requests to malicious servers, bypassing security measures. The detection rule identifies such misuse by monitoring Linux processes for AWS CLI commands using this option, flagging potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `--endpoint-url` argument in the AWS CLI command and identify the specific custom endpoint URL used.
+- Examine the process execution context by checking the `host.os.type`, `event.category`, and `process.name` fields to ensure the alert is relevant and correctly triggered.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Check the command history for the user to identify any other unusual or unauthorized AWS CLI commands executed around the same time.
+- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE name = 'aws' AND cmdline LIKE '%--endpoint-url%'`.
+- Analyze network logs to trace any outbound connections to the custom endpoint URL and determine if the destination is known or potentially malicious.
+- Review AWS CloudTrail logs for any corresponding API calls made using the custom endpoint to assess the scope and impact of the activity.
+- Investigate any related IAM roles or credentials used in the AWS CLI command to ensure they have not been compromised or misused.
+- Correlate the alert with other security events or anomalies on the host to identify any patterns or indicators of a broader attack.
+- Consult threat intelligence sources to check if the custom endpoint URL or associated IP addresses are linked to known malicious activities or actors.
+
+### False positive analysis
+
+- Legitimate use of the `--endpoint-url` option may occur in development or testing environments where developers use local or custom endpoints to simulate AWS services, which can trigger false positives.
+- Organizations using AWS-compatible services from third-party providers might configure the AWS CLI with custom endpoints, leading to benign alerts.
+- Automated scripts or CI/CD pipelines that interact with mock services for testing purposes may also use custom endpoints, resulting in false positives.
+- To manage these false positives, users can create exceptions or whitelist specific processes or environments known to use custom endpoints legitimately, ensuring that only unexpected or unauthorized uses are flagged.
+- Regularly review and update the list of approved custom endpoints and associated processes to minimize false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Review AWS CloudTrail logs and other relevant logs to identify any unauthorized API calls or data access attempts associated with the custom endpoint URL.
+- Conduct a thorough investigation to determine the scope of the compromise, including identifying any other systems or accounts that may have been affected.
+- Revoke any potentially compromised AWS credentials and rotate access keys and passwords for affected accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for AWS CLI usage, focusing on the detection of the `--endpoint-url` argument in future commands.
+- Integrate threat intelligence feeds to identify known malicious endpoints and update security controls to block them.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
+- Educate users on the risks associated with using custom endpoint URLs and provide training on secure AWS CLI usage practices."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/command_and_control_curl_socks_proxy_detected.toml b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
index 24109e074a5..11055191e04 100644
--- a/rules/linux/command_and_control_curl_socks_proxy_detected.toml
+++ b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,49 @@ process.name == "curl" and (
   process.env_vars like ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Activity from Unusual Parent
+
+Curl is a versatile command-line tool used for transferring data with URLs, often employed for legitimate data retrieval. However, adversaries can exploit it to establish SOCKS proxy connections, bypassing network restrictions for data exfiltration or C2 communication. The detection rule identifies suspicious curl usage by monitoring its execution from atypical parent processes and specific proxy-related arguments, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `curl` process execution with SOCKS proxy options and identify the unusual parent process from which it was launched.
+- Examine the parent process's executable path and name to determine if it is located in a suspicious directory such as `/dev/shm/`, `/tmp/`, or `/var/tmp/`, which are commonly used for temporary or potentially malicious activities.
+- Investigate the command-line arguments used with the `curl` process to verify the presence of SOCKS proxy options like `--socks5-hostname`, `--proxy`, or `-x`, which may indicate an attempt to bypass network restrictions.
+- Check the environment variables associated with the `curl` process for any proxy settings such as `http_proxy=socks5h://*`, which could suggest the use of a proxy for data exfiltration or C2 communication.
+- Use Osquery to gather additional context about the `curl` process and its parent. For example, run the following query to list processes with their parent details: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name = 'curl';`
+- Investigate the parent process's history and behavior by reviewing shell history files (e.g., `.bash_history`) to identify any commands that may have led to the execution of the `curl` process.
+- Analyze network logs to identify any unusual outbound connections made by the `curl` process, focusing on connections to external IP addresses or domains that are not part of normal business operations.
+- Correlate the alert with other security events or logs to identify any related activities or patterns that may indicate a broader attack campaign or compromise.
+- Review user activity and access logs to determine if the user associated with the `curl` process execution has a history of suspicious behavior or if their credentials may have been compromised.
+- Consult threat intelligence sources to check if the IP addresses or domains contacted by the `curl` process are associated with known malicious activities or threat actors.
+
+### False positive analysis
+
+- **System Administrators and Developers**: Legitimate use of curl with SOCKS proxy options by system administrators or developers for testing or maintenance purposes can trigger false positives. To manage this, consider creating exceptions for specific user accounts or known maintenance scripts.
+- **Automated Scripts and Tools**: Some automated scripts or tools may use curl with SOCKS proxy options for legitimate data retrieval or network testing. Identify these scripts and exclude them by specifying their parent process paths or names in the detection rule.
+- **Security Tools and Monitoring Solutions**: Security tools that perform network diagnostics or monitoring might use curl with SOCKS proxy options. Verify the source of these processes and exclude them if they are part of trusted security solutions.
+- **Custom Applications**: Custom applications developed in-house might use curl for legitimate purposes, including through SOCKS proxies. Document these applications and adjust the detection rule to exclude their specific parent processes or execution paths.
+- **Frequent Network Testing**: Organizations that frequently conduct network testing or audits might see false positives from legitimate curl usage. Establish a list of known testing activities and exclude them from the rule to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration or communication with C2 servers.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on unusual parent processes and the use of SOCKS proxy options with curl.
+- Review system logs and network traffic to trace the origin of the malicious activity and identify any other potentially compromised systems.
+- Remove any unauthorized or suspicious scripts and files found in directories like /dev/shm, /tmp, /var/tmp, and others specified in the detection rule.
+- Change credentials and keys that may have been exposed or used during the compromise, especially those related to network access and system administration.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all patches and updates are applied.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
+- Educate users and administrators on the risks associated with command-line tools and the importance of monitoring for unusual activity.
+- Apply system hardening measures, such as restricting the execution of scripts from writable directories and enforcing the principle of least privilege for user accounts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_ip_forwarding_activity.toml b/rules/linux/command_and_control_ip_forwarding_activity.toml
index f58b0be9b11..c7bc87d22f3 100644
--- a/rules/linux/command_and_control_ip_forwarding_activity.toml
+++ b/rules/linux/command_and_control_ip_forwarding_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,51 @@ process.parent.executable != null and process.command_line like (
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 IPv4/IPv6 Forwarding Activity
+
+IPv4/IPv6 forwarding allows a system to route traffic between networks, a legitimate function in network management. However, attackers can exploit this to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on processes like `sysctl` and shell commands that modify forwarding settings, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command and process that triggered the rule, focusing on the `process.command_line` and `process.name` fields to understand the exact action taken.
+- Check the `process.parent.executable` field to determine the parent process that initiated the command, which can provide context on whether the action was part of a legitimate script or user activity.
+- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity aligns with the user's typical behavior or role.
+- Analyze the timing of the event by reviewing the `event.start` timestamp to correlate with other network or system activities that might indicate a broader attack pattern.
+- Use Osquery to gather additional context on the system's network configuration. For example, run the following query to check the current IP forwarding settings:
+  ```sql
+  SELECT * FROM osquery_flags WHERE name IN ('net.ipv4.ip_forward', 'net.ipv6.conf.all.forwarding');
+  ```
+- Examine recent login events on the host to identify any unusual or unauthorized access attempts that could be related to the suspicious activity.
+- Review network logs or use network monitoring tools to identify any unusual traffic patterns or connections that might suggest data exfiltration or lateral movement.
+- Check for any recent changes to network configurations or firewall settings on the host that could indicate an attempt to facilitate unauthorized network routing.
+- Investigate other processes running on the host around the same time as the alert to identify any additional suspicious activities or processes that might be part of a coordinated attack.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that use similar techniques, which could provide additional context or indicators of compromise.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may legitimately enable IP forwarding during network configuration or troubleshooting, leading to false positives. To manage this, users can create exceptions for known administrative scripts or specific user accounts that regularly perform these tasks.
+- Automated scripts and tools: Some network management tools or automated scripts might enable IP forwarding as part of their normal operation. Users should identify these tools and exclude their processes from triggering alerts by specifying their process names or command patterns in the exception list.
+- Containerized environments: In environments using containers, certain orchestration tools might enable IP forwarding to manage network traffic between containers. Users can handle these false positives by excluding processes associated with these tools or by monitoring only specific hosts where such behavior is unexpected.
+- Testing and development environments: Developers might enable IP forwarding during testing phases to simulate network conditions. Users can reduce false positives by excluding specific development environments or by setting up temporary exceptions during known testing periods.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify any unauthorized changes to IP forwarding settings and determine the scope of the compromise.
+- Review system logs and network traffic to identify any suspicious activities or connections that may indicate lateral movement or data exfiltration.
+- Revert any unauthorized changes to the system's IP forwarding settings to restore normal network configuration.
+- Apply patches and updates to the operating system and any relevant software to mitigate known vulnerabilities.
+- Implement strict access controls and ensure that only authorized personnel can modify network settings.
+- Enhance logging policies to capture detailed information on command executions and network configuration changes for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and response.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as disabling IP forwarding by default and using network segmentation to limit potential attack vectors."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_linux_kworker_netcon.toml b/rules/linux/command_and_control_linux_kworker_netcon.toml
index cebba118b0b..dfa722d3a7f 100644
--- a/rules/linux/command_and_control_linux_kworker_netcon.toml
+++ b/rules/linux/command_and_control_linux_kworker_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,48 @@ process.name:kworker* and not destination.ip:(
   "FF00::/8"
 ) and not destination.port:("2049" or "111" or "892" or "597")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Activity Detected via Kworker
+
+Kworker processes are integral to Linux systems, handling tasks like interrupts and background activities within the kernel. However, attackers can exploit these processes to disguise malicious network activities, evading detection. The detection rule identifies suspicious network connections initiated by kworker processes, excluding legitimate internal and reserved IP ranges, to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a kworker process initiating a network connection, focusing on the `process.name:kworker*` field.
+- Verify the destination IP address to ensure it is not within the excluded internal and reserved IP ranges specified in the query.
+- Check the destination port to confirm it is not one of the excluded ports (2049, 111, 892, 597) and assess if the port is commonly used for legitimate services.
+- Use Osquery to list all active network connections on the host to identify any other unusual connections. Example query: `SELECT * FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name LIKE 'kworker%');`
+- Investigate the parent process of the kworker instance to determine if it was spawned by a legitimate process or if there are signs of process injection or tampering.
+- Examine the command line arguments and environment variables of the kworker process to identify any anomalies or suspicious parameters.
+- Review recent system logs and security events on the host for any signs of compromise or unusual activity preceding the alert.
+- Analyze the network traffic associated with the kworker process using packet capture tools to identify any suspicious patterns or data exfiltration attempts.
+- Cross-reference the alert with other security tools and logs to identify if there are correlated events or indicators of compromise.
+- Consult threat intelligence sources to determine if the destination IP or any related indicators are associated with known malicious activity.
+
+### False positive analysis
+
+- **Legitimate System Tasks**: Kworker processes are designed to handle legitimate system tasks such as managing hardware interrupts and executing scheduled kernel tasks. These activities might occasionally trigger the detection rule if they involve network connections, especially if they are directed to external IP addresses. Users can manage these by monitoring the frequency and context of such connections to determine if they align with expected system behavior.
+- **Network Monitoring Tools**: Some network monitoring or management tools might use kworker processes to perform legitimate network checks or diagnostics. If these tools are known and trusted, users can create exceptions for specific IP addresses or ports associated with these tools to prevent false positives.
+- **Custom Kernel Modules**: In environments where custom kernel modules are used, they might leverage kworker processes for network communication. Users should document and review these modules to ensure they are not inadvertently flagged by the rule. Exceptions can be made for specific modules or their associated network activities.
+- **Development and Testing Environments**: In development or testing environments, kworker processes might be used in unconventional ways that involve network communication. Users should assess whether these activities are part of normal operations and, if so, exclude them from the rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement.
+- Conduct a thorough investigation to confirm the legitimacy of the kworker process initiating the network connection, using tools like ps, netstat, or lsof to gather process details and network activity.
+- Analyze system logs and network traffic to identify any unusual patterns or connections that could indicate compromise, focusing on the time frame around the detected activity.
+- If malicious activity is confirmed, terminate the suspicious kworker process and any associated processes to stop ongoing threats.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Restore the system by applying the latest security patches and updates, and ensure that the system is free from any backdoors or persistent threats.
+- Implement enhanced logging policies to capture detailed process and network activity, ensuring that future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events with known threat indicators.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block unauthorized network connections and alert on suspicious activities.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as disabling unnecessary services and enforcing strict access controls, to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/credential_access_collection_sensitive_files.toml b/rules/linux/credential_access_collection_sensitive_files.toml
index b4def3d777d..1e54759482e 100644
--- a/rules/linux/credential_access_collection_sensitive_files.toml
+++ b/rules/linux/credential_access_collection_sensitive_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -106,6 +106,49 @@ event.category:process and host.os.type:linux and event.type:start and
       /etc/gshadow
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Sensitive Files Compression
+
+Compression utilities like zip, tar, and gzip are commonly used to reduce file sizes for storage or transfer. Adversaries exploit these tools to bundle sensitive files, such as SSH keys or configuration files, for exfiltration. The detection rule identifies suspicious compression activities by monitoring process executions involving these utilities and targeting known sensitive file paths, thus alerting analysts to potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on the compression utility used (e.g., zip, tar, gzip).
+- Check the timestamp of the event to determine when the suspicious compression activity occurred and correlate it with other events around the same time.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the command line arguments to identify the specific sensitive files targeted for compression and verify if these files are indeed present on the system.
+- Use Osquery to list recent process executions involving compression utilities with the following query: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name IN ('zip', 'tar', 'gzip', 'hdiutil', '7z');`
+- Analyze system logs for any signs of unauthorized access or privilege escalation that might have preceded the compression activity.
+- Check for any network connections or data transfer activities initiated by the user or process around the time of the alert to identify potential exfiltration attempts.
+- Investigate the file system for any newly created or modified compressed files that match the suspicious activity, focusing on their location and contents.
+- Review the system's audit logs to track any file access or modification events related to the sensitive files listed in the alert.
+- Cross-reference the alert with other security tools and logs to gather additional context and determine if this activity is part of a broader attack pattern.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may regularly compress sensitive files for legitimate backup or transfer purposes. To manage this, users can create exceptions for known administrative accounts or specific time windows when these tasks are expected.
+- Automated backup processes: Some systems may have scheduled jobs that compress sensitive files for backup. Users should identify and whitelist these processes by their specific command patterns or associated service accounts.
+- Development and testing activities: Developers might compress configuration files or credentials during testing or development. Users can exclude these activities by specifying development environments or user accounts involved in these tasks.
+- Security audits and compliance checks: Security teams may compress sensitive files as part of audits or compliance checks. Users should document and exclude these activities by recognizing the tools and accounts used during such operations.
+- Custom scripts or tools: Organizations might use custom scripts that compress sensitive files for internal processes. Users should review these scripts and exclude them by their unique signatures or execution paths.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on the processes and files involved in the suspicious compression activity.
+- Review system logs and process execution history to determine if any sensitive files were successfully exfiltrated.
+- Change all potentially compromised credentials, including SSH keys and AWS credentials, and update any related configurations.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring future suspicious activities are detected promptly.
+- Integrate security tools with threat intelligence platforms to correlate alerts with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Harden the system by implementing least privilege access controls, disabling unused services, and enforcing strong authentication mechanisms.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_credential_dumping.toml b/rules/linux/credential_access_credential_dumping.toml
index 1b57dacdf04..5426b725923 100644
--- a/rules/linux/credential_access_credential_dumping.toml
+++ b/rules/linux/credential_access_credential_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/02/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,48 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
 process.name == "unshadow" and process.args_count >= 3
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Linux Credential Dumping via Unshadow
+
+Unshadow is a utility within the John the Ripper suite, used to merge '/etc/shadow' and '/etc/passwd' files, creating a format suitable for password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of 'unshadow' by monitoring process initiation events with specific arguments, flagging potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "unshadow" and verify the process arguments count is greater than or equal to 3, as these are key indicators of the rule trigger.
+- Check the user account associated with the process execution to determine if it is a privileged account or if the account has a history of suspicious activity.
+- Investigate the parent process of "unshadow" to understand how it was initiated and whether it was executed by a legitimate process or script.
+- Examine the command line arguments used with "unshadow" to identify the specific files targeted, such as '/etc/shadow' and '/etc/passwd', and assess if they align with typical usage patterns.
+- Utilize Osquery to gather additional context about the process execution. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'unshadow' LIMIT 1);`
+- Analyze system logs for any other suspicious activities or anomalies around the time of the "unshadow" execution, such as unauthorized access attempts or changes to user accounts.
+- Check for any recent file modifications or access to '/etc/shadow' and '/etc/passwd' using file integrity monitoring tools or logs to identify unauthorized access.
+- Investigate network activity from the host to detect any potential exfiltration of the combined credential files or communication with known malicious IP addresses.
+- Review historical data to determine if there have been previous instances of "unshadow" execution on the host, which could indicate a recurring threat or misconfiguration.
+- Correlate the findings with threat intelligence sources to identify if the activity matches known attack patterns or threat actor behaviors associated with credential dumping.
+
+### False positive analysis
+
+- System administrators or security teams may use the unshadow utility legitimately during security audits or password recovery operations. These activities can trigger the detection rule, leading to false positives.
+- Automated scripts or maintenance tasks that involve password management or system integrity checks might execute unshadow as part of their routine operations, causing benign alerts.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that are authorized to use unshadow. This can be done by whitelisting certain process execution contexts or by excluding specific user accounts from triggering the alert.
+- Regularly review and update the list of exceptions to ensure that only legitimate and necessary uses of unshadow are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the use of the unshadow utility and identify any unauthorized access or data extraction.
+- Review system logs and process execution history to determine the scope of the compromise and identify any additional affected systems.
+- Change all user passwords on the affected system and any other systems where the same credentials might have been used.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for critical files such as '/etc/shadow' and '/etc/passwd' to detect future unauthorized access attempts.
+- Integrate threat intelligence feeds to identify known indicators of compromise (IOCs) related to credential dumping and similar tactics.
+- Restore the system from a known good backup to ensure the integrity of the operating environment.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Conduct a security awareness training session for users to educate them on the importance of strong passwords and recognizing phishing attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_gdb_init_process_hooking.toml b/rules/linux/credential_access_gdb_init_process_hooking.toml
index 23bf71fefd2..5700d1bb6ca 100644
--- a/rules/linux/credential_access_gdb_init_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_init_process_hooking.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,49 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
 process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Linux init (PID 1) Secret Dump via GDB
+
+In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of GDB execution targeting PID 1, focusing on the `process.name` and `process.args` fields to ensure they match the rule criteria.
+- Check the user context under which the GDB process was executed to determine if it was initiated by a legitimate user or an unauthorized account.
+- Investigate the parent process of the GDB execution to understand how it was initiated, using the `parent_process.name` and `parent_process.args` fields.
+- Examine the command history of the user who executed GDB to identify any suspicious commands or patterns leading up to the event.
+- Use Osquery to gather additional context about the GDB process and its parent process. Example query: `SELECT * FROM processes WHERE pid = (SELECT parent FROM processes WHERE name = 'gdb' AND pid = 1);`
+- Analyze system logs around the time of the event to identify any other suspicious activities or anomalies that may correlate with the GDB execution.
+- Check for any recent changes to system binaries or configuration files that could indicate tampering or preparation for the attack.
+- Review network logs to identify any unusual outbound connections that may suggest data exfiltration attempts following the memory dump.
+- Investigate any other alerts or indicators of compromise on the host that may suggest a broader attack campaign.
+- Consult threat intelligence sources to determine if there are any known campaigns or adversaries using similar techniques, focusing on the MITRE ATT&CK technique T1003 for context.
+
+### False positive analysis
+
+- System administrators or developers may use GDB to debug legitimate issues with the init process, leading to false positives. In such cases, verify the identity and intent of the user executing GDB and consider adding exceptions for known maintenance activities.
+- Automated scripts or monitoring tools might inadvertently trigger this rule if they include debugging or diagnostic routines involving PID 1. Review these scripts to ensure they are authorized and adjust the rule to exclude these specific processes or users.
+- Security or forensic tools that perform regular system checks might mimic the behavior flagged by this rule. Confirm the legitimacy of these tools and, if necessary, whitelist them to prevent repeated alerts.
+- In development environments, testing of new system initialization scripts or processes might involve debugging the init process. Ensure that these activities are documented and authorized, and create exceptions for these environments to reduce noise.
+- If a known and trusted application requires debugging access to the init process for functionality, document this requirement and configure the rule to exclude this application's specific execution context.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Verify the legitimacy of the GDB process targeting PID 1 by checking user permissions and the context of execution.
+- Conduct a thorough investigation to identify any unauthorized access or data extraction attempts, focusing on logs and system changes.
+- Terminate any unauthorized GDB processes and any other suspicious processes identified during the investigation.
+- Review and analyze system logs, including authentication logs, to identify any other potential indicators of compromise or lateral movement.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Restore the system to a known good state using backups, ensuring that any compromised credentials are reset and access controls are reviewed.
+- Implement enhanced logging policies to capture detailed process execution and memory access events for future investigations.
+- Integrate security tools with SIEM solutions to improve detection capabilities and automate alerting for similar threats.
+- Apply system hardening measures, such as restricting debugging tools to authorized users only and implementing strict access controls on critical processes."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_gdb_process_hooking.toml b/rules/linux/credential_access_gdb_process_hooking.toml
index 622a54dba55..2d18c8a602d 100644
--- a/rules/linux/credential_access_gdb_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_process_hooking.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 /* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
 process.args != "1"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Linux Process Hooking via GDB
+
+GDB, the GNU Debugger, is a powerful tool used for debugging applications on Linux systems. It allows users to inspect the memory and state of running processes. Adversaries can exploit GDB to dump memory from privileged processes, potentially extracting sensitive information like credentials. The detection rule identifies suspicious GDB usage by monitoring process initiation events with specific arguments, flagging potential unauthorized memory access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "gdb" and check if the process arguments include "--pid" or "-p", which indicate an attempt to attach to a running process.
+- Verify the user account associated with the gdb process initiation to determine if it is a privileged account or an account that should not typically use gdb.
+- Check the parent process of the gdb instance to understand how it was initiated and if it was spawned by a legitimate process or script.
+- Investigate the process ID (PID) specified in the gdb arguments to identify the target process and assess its sensitivity, such as whether it handles credentials or other sensitive data.
+- Use Osquery to gather additional context about the gdb process and its parent process. Example query: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'gdb';`
+- Examine system logs and audit logs around the time of the gdb process start event to identify any related suspicious activities or anomalies.
+- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized access to gdb or the target process.
+- Look for other instances of gdb usage on the system to determine if this is an isolated event or part of a broader pattern of behavior.
+- Analyze network activity from the host to detect any potential data exfiltration attempts following the gdb process execution.
+- Correlate this event with other security alerts or incidents to identify if it is part of a coordinated attack or a larger security incident.
+
+### False positive analysis
+
+- Developers and system administrators may use GDB for legitimate debugging purposes, which can trigger the rule. To manage this, users can create exceptions for specific user accounts or processes that are known to perform authorized debugging.
+- Automated testing environments might utilize GDB to test software under development. In such cases, users can exclude these environments by identifying and whitelisting the associated process IDs or hostnames.
+- Some monitoring or security tools may use GDB-like functionality to inspect processes for security assessments. Users should verify the legitimacy of these tools and exclude them from the rule if they are deemed safe.
+- In educational or research settings, GDB might be used for learning purposes. Users can handle these false positives by setting up exceptions for specific educational user groups or lab environments.
+- To ensure that exceptions do not introduce security risks, users should regularly review and update the list of exceptions, ensuring that only trusted entities are excluded from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Verify the legitimacy of the GDB process by checking the user who initiated it and the context in which it was executed.
+- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or unexpected network connections.
+- Review system logs and GDB usage history to determine the scope of the attack and identify any other potentially affected systems.
+- If unauthorized memory access is confirmed, change all credentials that may have been exposed, focusing on privileged accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to a known good state by reinstalling the operating system and applications, ensuring all security patches are applied.
+- Harden the system by disabling unnecessary debugging tools on production servers and enforcing strict access controls and monitoring for privileged operations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
index c53f414129c..136ef280e44 100644
--- a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
+++ b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ sequence by host.id, process.parent.executable, user.id with maxspan=1s
    )
   ] with runs=10
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Linux Local Account Brute Force Detected
+
+In Linux environments, the 'su' command is used to switch user accounts, often requiring a password. Adversaries may exploit this by attempting numerous logins in quick succession, using either default or custom password lists, to gain unauthorized access. The detection rule identifies such brute force attempts by monitoring for multiple rapid 'su' executions from a single process, excluding common legitimate parent processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the `host.id`, `process.parent.executable`, and `user.id` involved in the potential brute force attempt to understand the scope and context of the activity.
+- Check the process execution history on the affected host to determine if there are any unusual patterns or anomalies associated with the `su` command, focusing on the `process.parent.executable` to identify any uncommon parent processes.
+- Investigate the user account (`user.id`) targeted by the brute force attempt to determine if it is a high-value account or if it has been involved in previous suspicious activities.
+- Examine the system logs, such as `/var/log/auth.log` or `/var/log/secure`, for additional context around the time of the alert to identify any other suspicious login attempts or related activities.
+- Use Osquery to gather more information about the processes running on the host. For example, execute the following query to list all processes with their parent processes: `SELECT pid, name, path, parent FROM processes WHERE name = 'su';`
+- Analyze network activity from the host to identify any unusual outbound or inbound connections that may correlate with the timing of the brute force attempts.
+- Check for any recent changes in user account configurations or permissions that could indicate unauthorized modifications or preparations for further attacks.
+- Review the system's security settings and configurations to ensure that they are aligned with best practices, particularly focusing on password policies and account lockout settings.
+- Correlate the alert with other security events or alerts from the same host or user account to identify potential patterns or coordinated attack attempts.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that match the tactics, techniques, and procedures (TTPs) observed in the alert, specifically focusing on the MITRE ATT&CK technique T1110 (Brute Force).
+
+### False positive analysis
+
+- Scheduled scripts or automated tasks that require frequent user switching might trigger false positives. These can be managed by identifying the specific scripts or tasks and adding their parent processes to the exclusion list.
+- System maintenance activities, such as updates or backups, often involve multiple 'su' commands in a short period. To handle these, ensure that maintenance scripts are run by known and trusted parent processes, which can then be excluded.
+- Development environments where developers frequently switch between user accounts for testing purposes may also cause false positives. In such cases, consider excluding the development tools or environments from the detection rule.
+- Continuous integration/continuous deployment (CI/CD) pipelines that use 'su' for various tasks might be flagged. To prevent this, identify the CI/CD tools and add them to the list of legitimate parent processes.
+- Custom administrative scripts that perform user account checks or management tasks could be mistaken for brute force attempts. Review these scripts and, if they are legitimate, add their parent processes to the exclusion list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Review the logs to identify the source of the brute force attempts and determine if any accounts were compromised.
+- Reset passwords for any accounts that were targeted, ensuring they are strong and unique.
+- Conduct a thorough investigation to determine if the adversary gained access to sensitive data or systems.
+- Escalate the incident to the security team and, if necessary, involve legal or law enforcement agencies.
+- Implement additional logging and monitoring to detect similar activities in the future, such as enabling detailed audit logs for user authentication attempts.
+- Integrate threat intelligence feeds to enhance detection capabilities and stay informed about emerging threats.
+- Restore the system to its operational state by applying any necessary patches and updates, and verifying system integrity.
+- Harden the system by disabling unnecessary services, enforcing the principle of least privilege, and implementing multi-factor authentication.
+- Educate users on security best practices, including recognizing phishing attempts and the importance of using strong passwords."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
index 936f72da6b4..88dacaf4595 100644
--- a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,48 @@ sequence by host.id, auditd.data.addr, related.user with maxspan=5s
    auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and
    auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Successful Linux FTP Brute Force Attack Detected
+
+FTP is a protocol used for transferring files between systems, often requiring authentication. Adversaries exploit this by attempting numerous username-password combinations to gain unauthorized access. The detection rule identifies a pattern of repeated failed login attempts from a single source, followed by a successful login, indicating a potential brute force attack.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id`, `auditd.data.addr`, and `related.user` involved in the potential brute force attack.
+- Check the logs for the specified `host.id` to gather more information about the failed and successful login attempts, focusing on the `auditd.data.terminal` field to confirm they were FTP-related.
+- Analyze the source IP address (`auditd.data.addr`) to determine if it is known for malicious activity or if it belongs to a legitimate user or partner.
+- Investigate the `related.user` account to verify if it has been compromised or if there are any unusual activities associated with it.
+- Use Osquery to gather additional context on the affected host. For example, run the following query to list recent login attempts: `SELECT * FROM last WHERE tty = 'ftp';`
+- Examine the time interval between the failed and successful login attempts to assess the likelihood of a brute force attack, considering the `maxspan=5s` parameter in the detection rule.
+- Cross-reference the `host.id` with other security alerts or logs to identify any correlated suspicious activities or patterns.
+- Check for any recent changes in the FTP server configuration or user account settings that might have facilitated the attack.
+- Review network traffic logs to identify any unusual data transfers or connections from the source IP address during or after the successful login.
+- Consult threat intelligence sources to determine if the attack pattern or source IP address matches any known threat actors or campaigns.
+
+### False positive analysis
+
+- Automated scripts or applications that frequently attempt to connect to an FTP server with incorrect credentials due to misconfigurations can trigger false positives. Users should identify and correct these configurations or whitelist the IP addresses of trusted scripts.
+- Legitimate users who frequently mistype their passwords or use password managers that incorrectly autofill credentials may cause false positives. Implementing user education on proper password management and verifying user behavior patterns can help mitigate this.
+- Security testing tools or vulnerability scanners that perform credential testing as part of their operations might be mistaken for brute force attacks. Users should ensure these tools are configured to exclude FTP services or whitelist their IP addresses in the detection rule.
+- Frequent legitimate access attempts from a single source, such as a shared corporate IP address, can be misinterpreted as a brute force attack. Users can adjust the detection rule to account for known safe IP ranges or implement additional context checks, such as user behavior analysis, to differentiate between legitimate and malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access and data exfiltration.
+- Review and analyze the logs of the FTP server and related systems to identify the source of the attack and any compromised accounts.
+- Reset passwords for all affected accounts and consider implementing multi-factor authentication (MFA) to enhance security.
+- Conduct a thorough investigation to determine if any data was accessed or exfiltrated and assess the extent of the compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement additional logging and monitoring to detect similar brute force attempts in the future, ensuring logs are retained for an adequate period.
+- Integrate threat intelligence feeds to enhance detection capabilities and correlate with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by applying patches, updating software, and ensuring all security configurations are correctly set.
+- Harden the FTP server by disabling anonymous access, limiting login attempts, and using secure protocols like SFTP or FTPS.
+- Conduct a post-incident review to identify gaps in the security posture and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
index f4c9c353808..8c7698de40b 100644
--- a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,49 @@ sequence by host.id, related.user with maxspan=5s
   [authentication where host.os.type == "linux" and event.action  == "authenticated" and
    auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Successful Linux RDP Brute Force Attack Detected
+
+Remote Desktop Protocol (RDP) allows users to connect to and control remote systems, often used for administrative tasks. Adversaries exploit RDP by attempting numerous login attempts to gain unauthorized access, potentially leading to data breaches or further network attacks. The detection rule identifies a pattern of multiple failed login attempts followed by a successful one, indicating a possible brute force attack, by monitoring authentication events on Linux systems.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `related.user` involved in the potential brute force attack.
+- Examine the authentication logs on the identified Linux host to verify the sequence of failed and successful login attempts, focusing on entries with `event.action` as "authenticated" and `auditd.data.terminal` containing "*rdp*".
+- Check the time interval between the failed and successful login attempts to confirm if they occurred within the `maxspan=5s` window, indicating a rapid succession of attempts.
+- Investigate the source IP addresses associated with the failed and successful login attempts to determine if they originate from suspicious or known malicious sources.
+- Use Osquery to gather additional context on the user account involved. For example, run the query: `SELECT * FROM users WHERE username = '<related.user>';` to check for anomalies in user account settings or recent changes.
+- Analyze the system's audit logs for any unusual activity or changes around the time of the successful login, such as new processes or network connections initiated by the compromised account.
+- Correlate the findings with other security events or alerts in the network to identify if this incident is part of a larger attack campaign.
+- Review historical login patterns for the `related.user` to determine if the login behavior is consistent with past activity or if it deviates significantly.
+- Check for any recent vulnerabilities or patches related to RDP on Linux systems that might have been exploited in this attack.
+- Document all findings and evidence collected during the investigation to support further analysis and potential escalation.
+
+### False positive analysis
+
+- Frequent legitimate administrative access: Regular administrative tasks may involve multiple failed login attempts due to mistyped credentials or password changes, followed by a successful login. Users can handle this by creating exceptions for known administrative accounts or IP addresses.
+- Automated scripts or tools: Some automated maintenance scripts or tools might attempt multiple logins in a short period, leading to false positives. Users should identify and whitelist these scripts or tools to prevent unnecessary alerts.
+- User error: Users may accidentally enter incorrect credentials multiple times before succeeding, especially if they are using complex passwords. Implementing user-specific exceptions or increasing the threshold for failed attempts can help reduce false positives.
+- Testing environments: In testing or development environments, frequent login attempts might be part of normal operations. Users can exclude these environments from monitoring or adjust the detection parameters to better fit the expected behavior.
+- Shared accounts: If multiple users share an account, failed login attempts may occur more frequently. Consider monitoring shared accounts separately and adjusting the detection criteria to account for this behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Review authentication logs to confirm the brute force attack and identify the source IP address of the attacker.
+- Block the attacker's IP address at the network firewall to prevent further attempts.
+- Reset passwords for the compromised account and any other accounts that may have been targeted during the attack.
+- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement multi-factor authentication (MFA) for RDP access to enhance security and prevent future brute force attacks.
+- Review and update logging policies to ensure comprehensive monitoring of authentication events and potential security incidents.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to enhance detection capabilities.
+- Apply system hardening measures, such as disabling RDP if not needed, using strong password policies, and regularly updating and patching systems."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_proc_credential_dumping.toml b/rules/linux/credential_access_proc_credential_dumping.toml
index 9da10c339f0..a4f2f87b74a 100644
--- a/rules/linux/credential_access_proc_credential_dumping.toml
+++ b/rules/linux/credential_access_proc_credential_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,50 @@ sequence by host.id, process.parent.name with maxspan=1m
   [process where host.os.type == "linux" and process.name == "strings" and event.action == "exec"
    and process.args : "/tmp/*"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Linux Credential Dumping via Proc Filesystem
+
+The /proc filesystem in Linux provides a mechanism to access process information, which is crucial for system diagnostics. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences of commands, like 'ps' and 'strings', executed in a short span, indicating potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and process.parent.name involved in the suspicious activity.
+- Verify the execution of the 'ps' command by checking the process.args field for the presence of "-eo", "pid", "command" to ensure it matches the alert criteria.
+- Examine the execution of the 'strings' command by confirming the process.args field includes paths like "/tmp/*", which may indicate temporary storage of dumped credentials.
+- Use Osquery to list all processes running on the affected host to identify any unusual or unauthorized processes. Example query: `SELECT pid, name, path FROM processes WHERE name IN ('ps', 'strings');`
+- Investigate the parent process of the suspicious 'ps' and 'strings' commands to determine if they were spawned by a legitimate or malicious process.
+- Check the process execution timeline to see if the 'ps' and 'strings' commands were executed within a short span (maxspan=1m) to confirm the sequence of events.
+- Analyze the command history on the affected host to identify any manual execution of similar commands that could indicate an insider threat or misconfiguration.
+- Review system logs for any additional context around the time of the alert, focusing on authentication logs and any anomalies in user activity.
+- Investigate any files in the /tmp directory that may have been created or modified around the time of the alert to identify potential credential dumps.
+- Correlate the findings with other security tools and logs to determine if there are any related alerts or indicators of compromise on the same host or network.
+
+### False positive analysis
+
+- System administrators or automated scripts may frequently use the 'ps' and 'strings' commands for legitimate monitoring and diagnostic purposes, leading to false positives. 
+- Security tools or monitoring solutions might execute similar command sequences as part of their regular operations, which could be mistaken for malicious activity.
+- Developers and testers might use these commands during software development or testing phases, especially when debugging or analyzing application behavior.
+- To manage these false positives, users can create exceptions for known benign processes or scripts by whitelisting specific process names or paths that are regularly used in their environment.
+- Implementing a baseline of normal system behavior can help differentiate between legitimate and suspicious activities, allowing for more accurate detection and fewer false positives.
+- Regularly updating and reviewing the list of exceptions is crucial to ensure that new legitimate processes are not flagged as threats while maintaining security against actual credential dumping attempts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential exposure and lateral movement.
+- Conduct a thorough investigation to confirm the presence of mimipenguin or similar tools by reviewing process execution logs and file system changes.
+- Terminate any suspicious processes identified during the investigation, particularly those related to 'ps' and 'strings' commands executed in sequence.
+- Change all passwords for accounts that were logged in on the affected system to prevent unauthorized access using potentially compromised credentials.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system from a known good backup to ensure no residual malicious artifacts remain.
+- Apply security patches and updates to address vulnerabilities like CVE-2018-20781 and ensure all systems are up to date.
+- Conduct a security awareness training session for users to recognize and report suspicious activities, emphasizing the importance of credential security."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_ssh_backdoor_log.toml b/rules/linux/credential_access_ssh_backdoor_log.toml
index bbd78ee7232..98a4923ae3a 100644
--- a/rules/linux/credential_access_ssh_backdoor_log.toml
+++ b/rules/linux/credential_access_ssh_backdoor_log.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -111,6 +111,50 @@ file where host.os.type == "linux" and event.type == "change" and process.execut
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential OpenSSH Backdoor Logging Activity
+
+OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to create backdoors, allowing unauthorized access or logging credentials. The detection rule identifies suspicious file changes by monitoring SSH processes and unusual file activities, such as writing to atypical directories or using uncommon file extensions, which may indicate backdoor logging attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file change event, including the file name, file path, and process executable involved, to understand the context of the suspicious activity.
+- Verify the legitimacy of the process executable by checking the hash of the binary at the path "/usr/sbin/sshd" or "/usr/bin/ssh" against known good hashes to detect any unauthorized modifications.
+- Examine the file name and extension involved in the alert to determine if it matches any known patterns of backdoor logging files, such as unusual extensions like "in", "out", "ini", or temporary file patterns like "*~".
+- Investigate the file path to determine if it matches any of the suspicious directories listed in the query, such as "/private/etc/ssh/.sshd_auth" or "/usr/lib/*.so.*", which may indicate unauthorized file placement.
+- Use Osquery to list all files in the suspicious directories identified in the alert to check for other potentially malicious files. Example query: `SELECT * FROM file WHERE directory IN ('/private/etc', '/usr/lib') AND (name LIKE '%.so%' OR name LIKE '%~%');`
+- Check the system logs for any recent SSH login attempts or connections around the time of the file change event to identify any unauthorized access attempts.
+- Analyze the process tree and parent-child relationships of the SSH process involved in the alert to identify any unusual or unexpected process behavior.
+- Review the system's user accounts and SSH configuration files to ensure no unauthorized changes have been made that could facilitate backdoor access.
+- Investigate any network connections made by the SSH process to external IP addresses to identify potential data exfiltration or command-and-control activity.
+- Correlate the alert with other security events or alerts from the same host or network segment to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Routine administrative tasks or legitimate software updates may trigger file changes in monitored directories or with uncommon file extensions, leading to false positives. 
+- System maintenance scripts or automated processes that modify files in directories like `/usr/share/` or `/usr/local/share/` could be misinterpreted as suspicious activity.
+- Temporary files created by text editors or development tools, such as those with extensions like `.so` or `.sock`, might be flagged incorrectly.
+- Users can manage these false positives by creating exceptions for known benign processes or file paths that frequently trigger alerts, ensuring that legitimate activities are not continuously flagged.
+- Implementing a whitelist for specific file names or extensions that are known to be safe in the context of your environment can help reduce unnecessary alerts.
+- Regularly review and update the exclusion list to adapt to changes in legitimate system behavior, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify any unauthorized changes to SSH binaries or configuration files, focusing on the paths and file types specified in the detection rule.
+- Review system logs and SSH logs for any unusual login attempts or file access patterns that could indicate backdoor activity.
+- Revert any unauthorized changes to SSH binaries and configuration files by restoring them from a known good backup.
+- Change all SSH-related credentials and keys that may have been compromised, and ensure that new keys are distributed securely.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed SSH activity, including command execution and file access, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of similar threats in the future.
+- Apply security patches and updates to the SSH service and related components to mitigate known vulnerabilities.
+- Harden the SSH configuration by disabling unused authentication methods, enforcing strong password policies, and using multi-factor authentication (MFA) where possible."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
index f333f48428b..bdc755eedaa 100644
--- a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
+++ b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,52 @@ sequence by host.id,  process.parent.entity_id with maxspan=1s
   and event.action == "connection_attempted"
   and destination.ip == "169.254.169.254"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Instance Metadata Service (IMDS) API Request
+
+The Instance Metadata Service (IMDS) API provides essential instance-specific data, including credentials, to applications running on cloud instances. Adversaries exploit this by using scripts or tools to access sensitive data, potentially leading to unauthorized access. The detection rule identifies suspicious access attempts by monitoring specific processes and network connections to the IMDS endpoint, filtering out known legitimate activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and command line that triggered the alert, focusing on the `process.name`, `process.executable`, and `process.command_line` fields.
+- Check the `process.parent.entity_id` to understand the parent process and its relationship to the suspicious process, which might provide context on how the process was initiated.
+- Investigate the `process.working_directory` to determine if the process was executed from a suspicious or unusual directory, which could indicate malicious activity.
+- Examine the `network` event details, particularly the `destination.ip`, to confirm if there was an attempted connection to the IMDS endpoint at `169.254.169.254`.
+- Use Osquery to gather more information about the suspicious process. For example, run the following query to list all processes with network connections to the IMDS endpoint:
+  ```sql
+  SELECT pid, name, path, cmdline, cwd FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = '169.254.169.254');
+  ```
+- Cross-reference the `host.id` with other security logs to identify any other suspicious activities or alerts associated with the same host.
+- Investigate the `event.type` and `event.action` fields to confirm the nature of the process execution and network connection attempt, ensuring they align with the alert's context.
+- Review historical data for the same `host.id` to identify any patterns or repeated attempts to access the IMDS API, which could indicate persistent malicious activity.
+- Check for any legitimate software or scripts that might have been recently installed or updated on the host, which could explain the alert as a false positive.
+- Collaborate with the cloud infrastructure team to verify if there are any known legitimate processes or maintenance activities that could have triggered the alert, ensuring alignment with operational changes.
+
+### False positive analysis
+
+- Security and monitoring tools such as Rapid7, Nessus, and Amazon SSM Agent may trigger false positives due to their legitimate access to the IMDS API for vulnerability assessments and system management. Users can handle these by adding exceptions for processes running from directories like `/opt/rapid7*`, `/opt/nessus*`, and `/snap/amazon-ssm-agent*`.
+- Automated scripts or services that require instance metadata for configuration or management purposes might also be flagged. These can be excluded by specifying known safe process executables or parent executables, such as `/opt/rumble/bin/rumble-agent*` or `/usr/bin/setup-policy-routes`.
+- Cloud-native services like EC2 Instance Connect, which use the IMDS API for legitimate operations, may appear suspicious. Users should consider excluding processes with parent executables located in `/usr/share/ec2-instance-connect/*`.
+- Regular system updates or maintenance scripts that temporarily access the IMDS API could be misidentified as threats. To manage these, users can create exceptions for processes with specific working directories or command lines that are known to be safe.
+- Network monitoring tools that check connectivity to the IMDS endpoint for health checks might be mistakenly flagged. Users should ensure that these tools are recognized and excluded by specifying their network activity as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected instance from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and method of the unauthorized IMDS API access attempt, focusing on the processes and network connections flagged by the detection rule.
+- Review and analyze logs from the affected instance and any associated cloud services to gather more context on the incident, including timestamps, IP addresses, and user accounts involved.
+- Revoke any temporary security credentials that may have been accessed and rotate all potentially compromised credentials, including API keys and passwords.
+- Escalate the incident to the security operations team and, if necessary, involve cloud service provider support for further assistance and investigation.
+- Implement enhanced logging and monitoring for IMDS API access attempts, ensuring that all access is logged and alerts are configured for suspicious activities.
+- Deploy additional security controls such as network segmentation and firewall rules to restrict access to the IMDS endpoint to only trusted processes and users.
+- Restore the affected instance to its operational state by applying security patches, updating configurations, and verifying the integrity of system files and applications.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train staff on the risks associated with IMDS API access and the importance of adhering to security best practices, leveraging MITRE ATT&CK framework details for threat context."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
index 639960586e4..5d9e2b91a54 100644
--- a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
+++ b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/23"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,48 @@ process.name == "setfacl" and not (
   process.args == "/var/log/journal/"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Access Control List Modification via setfacl
+
+Access Control Lists (ACLs) in Linux enhance file permissions by allowing more granular control over who can access or modify files. The `setfacl` command is used to set these permissions. Adversaries may exploit `setfacl` to stealthily alter permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential unauthorized ACL modifications.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `setfacl` command execution, focusing on the `process.name` and `event.type` fields to ensure the event is a process start.
+- Examine the `process.command_line` field to understand the exact command executed and identify any unusual or suspicious arguments that deviate from typical usage patterns.
+- Check the `process.args` field to determine the specific files or directories targeted by the `setfacl` command, paying attention to any sensitive or critical system files.
+- Investigate the user account associated with the `setfacl` execution to determine if the action aligns with their typical behavior or role within the organization.
+- Correlate the event with other recent activities from the same user or process to identify any patterns or sequences that suggest malicious intent.
+- Use Osquery to gather additional context on the file or directory affected by the ACL modification. For example, run the following query to list current ACLs for a specific file: `SELECT * FROM file WHERE path = '/path/to/suspicious/file';`
+- Review system logs around the time of the `setfacl` execution to identify any related events or anomalies that could provide further context or indicate a broader attack.
+- Investigate the parent process of the `setfacl` execution to determine if it was initiated by a legitimate application or script, or if it was potentially spawned by malicious software.
+- Assess the system for any signs of compromise or unauthorized access that could explain the unexpected ACL modification, such as unusual network connections or new user accounts.
+- Consult with the system owner or relevant personnel to verify if the `setfacl` execution was authorized and necessary, and gather any additional context that could aid in the investigation.
+
+### False positive analysis
+
+- Routine administrative tasks often involve the use of `setfacl` to manage file permissions, which can trigger false positives. System administrators frequently use `setfacl` to configure permissions for shared directories or to restore permissions from backups.
+- Automated scripts or configuration management tools like Ansible, Puppet, or Chef may execute `setfacl` as part of their normal operations, leading to benign alerts.
+- To manage these false positives, users can create exceptions for specific command-line patterns or arguments that are known to be safe, such as excluding processes with command lines that match regular maintenance tasks.
+- Users should regularly review and update the exclusion list to ensure it reflects current operational practices, minimizing the risk of overlooking genuine threats while reducing noise from legitimate activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the scope of the ACL modifications, including which files or directories were affected and the specific changes made.
+- Review system logs and security alerts to determine if the `setfacl` command was executed by a legitimate user or if credentials may have been compromised.
+- Revert unauthorized ACL changes by restoring permissions to their original state using backups or predefined security baselines.
+- Escalate the incident to the security operations center (SOC) or incident response team if unauthorized access or potential compromise is confirmed.
+- Implement enhanced logging for ACL changes and `setfacl` command executions to improve detection of future unauthorized modifications.
+- Integrate with a security information and event management (SIEM) system to correlate ACL modification events with other suspicious activities.
+- Educate users on the importance of secure credential management and the risks associated with unauthorized permission changes.
+- Apply system hardening measures, such as restricting the use of `setfacl` to authorized administrators only and using role-based access controls.
+- Regularly review and update access control policies to ensure they align with the principle of least privilege and are resilient against evasion techniques."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
index 017bc7b89fa..553054753f4 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/28"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,50 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and
 process.args in ("auditd", "auditd.service")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Disable Auditd Service
+
+Auditd is a crucial Linux service for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by stopping or disabling it, thus impairing the system's ability to log malicious activities. The detection rule identifies such attempts by monitoring processes that execute commands to stop or disable Auditd, flagging potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
+- Check the user context under which the suspicious command was executed to determine if it was run by an unauthorized or unexpected user.
+- Investigate the parent process of the flagged process to understand how the command was initiated, using the `process.parent.name` and `process.parent.args` fields.
+- Examine the command execution history for the user involved to identify any other suspicious activities or patterns.
+- Use Osquery to list all recent changes to system services, including Auditd, with a query like: `SELECT * FROM osquery_schedule WHERE name = 'auditd';`
+- Review system logs around the time of the alert for any other suspicious activities or anomalies that might correlate with the attempt to disable Auditd.
+- Check for any recent modifications to the Auditd configuration files to ensure they have not been tampered with.
+- Investigate network connections from the host to identify any unusual outbound connections that might indicate data exfiltration or command-and-control activity.
+- Look for any other alerts or indicators of compromise on the same host that might suggest a broader attack campaign.
+- Verify the integrity of the Auditd service by checking its current status and configuration to ensure it is running as expected.
+
+### False positive analysis
+
+- Routine system maintenance or administrative tasks may trigger this rule if administrators legitimately stop or disable the Auditd service for updates or configuration changes. 
+- Automated scripts or configuration management tools like Ansible, Puppet, or Chef might execute commands that match the rule criteria during system provisioning or updates.
+- Testing environments where services are frequently started and stopped for development purposes can also lead to false positives.
+- To manage these false positives, users can create exceptions for known maintenance windows or specific administrative accounts that regularly perform these actions.
+- Implementing a whitelist of trusted scripts or tools that are known to perform legitimate service management can help reduce noise.
+- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Investigate the alert by reviewing the process execution logs to identify the user and source of the command attempting to disable Auditd.
+- Check for any unauthorized changes to system configurations or additional suspicious activities that may have occurred around the time of the alert.
+- Restore the Auditd service to its operational state by restarting it and ensuring it is enabled to start on boot.
+- Review and update access controls to ensure only authorized personnel can modify or stop critical services like Auditd.
+- Escalate the incident to the security operations team for further analysis and to determine if this is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed audit logs and ensure they are securely stored and monitored for anomalies.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and applying security patches, to reduce the attack surface and prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
index b9f2ca63ffa..228b7d7d268 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/02/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Disable IPTables or Firewall
+
+Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these defenses to facilitate malicious activities, such as data exfiltration or lateral movement. The detection rule identifies suspicious processes that aim to disable or stop firewall services, signaling potential defense evasion attempts by monitoring specific command executions and arguments.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on fields like `process.name` and `process.args`.
+- Check the `event.type` and `event.action` fields to confirm the nature of the process execution and ensure it aligns with the suspicious activity described in the rule.
+- Investigate the parent process using `process.parent.args` to understand the context in which the suspicious process was executed, which might reveal if it was part of a larger script or command sequence.
+- Examine the user account associated with the process execution to determine if it was initiated by a legitimate user or potentially compromised account.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <suspicious_pid>);`
+- Check system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication events or anomalies around the time of the alert to identify potential unauthorized access.
+- Investigate any recent changes to firewall configurations by reviewing the history of commands executed by the user, which can be found in shell history files like `.bash_history`.
+- Correlate the alert with other security events or alerts from the same host to identify if this is part of a broader attack pattern, such as lateral movement or privilege escalation attempts.
+- Analyze network traffic logs to detect any unusual outbound connections or data exfiltration attempts that might have occurred after the firewall was disabled.
+- Review any recent system updates or patches applied to the host to rule out the possibility of legitimate maintenance activities that might have triggered the alert.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may frequently execute commands to disable or stop firewall services during maintenance or troubleshooting. These actions, while legitimate, can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific maintenance windows.
+- Automated scripts: Some automated scripts or configuration management tools may include commands to disable or modify firewall settings as part of their normal operation. Users should review these scripts and, if deemed non-threatening, exclude them from triggering alerts by specifying the script names or paths in the exception list.
+- Testing environments: In testing or development environments, firewall services might be intentionally disabled to facilitate testing. Users can handle these false positives by excluding specific hosts or environments from the detection rule.
+- Legacy systems: Older systems might use different methods or commands to manage firewall settings, which could be flagged by the rule. Users should identify these systems and adjust the detection criteria or add exceptions accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities on the host, focusing on recent process executions and network connections.
+- Review system logs and security alerts to determine the scope of the incident and identify any other potentially compromised systems.
+- Restore the firewall settings to their original state using backup configurations or by manually re-enabling the firewall services.
+- Apply patches and updates to the operating system and firewall software to address any known vulnerabilities.
+- Implement enhanced logging policies to capture detailed information on process executions and network activities, ensuring that logs are stored securely and monitored regularly.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection and response capabilities.
+- Conduct a post-incident review to analyze the attack vector and update security policies and procedures to prevent similar incidents in the future.
+- Educate and train staff on recognizing and responding to potential security threats, emphasizing the importance of maintaining firewall integrity.
+- Consider implementing additional hardening measures, such as disabling unnecessary services, enforcing strong access controls, and using multi-factor authentication to enhance system security."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
index a93d4c199cd..f768b84ba2e 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,48 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event")
    (process.name == "systemctl" and process.args in ("disable", "stop", "kill"))
  ) and process.args in ("syslog", "rsyslog", "syslog-ng")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Disable Syslog Service
+
+Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disrupt logging, thereby evading detection by security systems. They might use commands like `service stop`, `chkconfig off`, or `systemctl disable` to halt syslog services. The detection rule identifies such attempts by monitoring process executions that match these patterns, ensuring any disruption attempts are flagged for investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields to ensure they match the suspicious patterns.
+- Check the `event.action` field to verify if the action was an execution event, which is critical for confirming the attempt to disable the syslog service.
+- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised, using the `user.name` field.
+- Examine the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is specifically designed for Linux environments.
+- Use Osquery to gather additional context about the process execution. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
+- Analyze the process tree to understand the parent process and any child processes spawned by the suspicious process, which can provide insights into how the command was executed.
+- Review system logs around the time of the alert to identify any other suspicious activities or anomalies that might correlate with the attempt to disable syslog.
+- Check for any recent changes to system configurations or services that might indicate tampering or preparation for disabling syslog.
+- Investigate network connections from the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
+- Correlate the alert with other security events or alerts from the same host or user to identify patterns or repeated attempts to disable logging services.
+
+### False positive analysis
+
+- Routine maintenance activities by system administrators may trigger this rule when they intentionally stop or disable syslog services for updates or configuration changes. To manage this, users can create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or configuration management tools that manage service states might also cause false positives if they include commands to stop or disable syslog services as part of their operations. Users should review these scripts and, if deemed non-threatening, exclude them from triggering the rule by specifying the script names or paths.
+- Testing environments where syslog services are intentionally stopped for testing purposes can also lead to false positives. Users can handle this by excluding specific test environment hosts or IP addresses from the rule.
+- Some legitimate software installations or updates might require stopping syslog services temporarily, which could be flagged by this rule. Users should identify such software and create exceptions based on the software's process names or installation paths.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
+- Investigate the process execution logs to confirm the attempt to disable the syslog service and identify any associated processes or users involved.
+- Review user access logs to determine if unauthorized access was gained and identify any compromised accounts.
+- Re-enable the syslog service using the appropriate command for your system (e.g., `systemctl enable syslog` and `systemctl start syslog`) to restore logging functionality.
+- Conduct a thorough review of system logs to identify any other suspicious activities or anomalies that occurred around the time of the syslog service disruption attempt.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attempt is part of a larger attack campaign.
+- Implement stricter access controls and monitoring on critical services like syslog to prevent unauthorized modifications, including using role-based access controls and multi-factor authentication.
+- Enhance logging policies by ensuring that all critical system events are logged and that logs are securely stored and regularly reviewed for signs of tampering or suspicious activity.
+- Integrate additional security tools and threat intelligence feeds to improve detection capabilities and provide context for future investigations, such as endpoint detection and response (EDR) solutions.
+- Apply system hardening measures by regularly updating and patching software, disabling unnecessary services, and configuring security settings according to best practices to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
index 544c7ce58e0..82d6f1c8927 100644
--- a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
+++ b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/17"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
  and process.name in ("base16", "base32", "base32plain", "base32hex") and
 not process.args in ("--help", "--version")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Base16 or Base32 Encoding/Decoding Activity
+
+Base16 and Base32 are encoding schemes that convert binary data into text, making it easier to transmit over text-based protocols. Adversaries exploit these encodings to obfuscate data, evading detection by security systems. The detection rule identifies suspicious encoding activities by monitoring specific processes on Linux systems, excluding benign actions like help or version checks, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name involved is one of the specified encoding tools: "base16", "base32", "base32plain", or "base32hex".
+- Examine the process arguments to ensure they do not include benign actions like "--help" or "--version", which are excluded in the detection rule.
+- Check the user account associated with the process to determine if it is a known and trusted user or if it might be compromised.
+- Investigate the parent process of the encoding activity to understand the context in which the encoding tool was executed.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('base16', 'base32', 'base32plain', 'base32hex');`
+- Analyze recent command history for the user associated with the process to identify any suspicious commands or patterns leading up to the encoding activity.
+- Review system logs for any related events or anomalies around the time the encoding process was executed, such as unusual login attempts or file access patterns.
+- Check for any network connections initiated by the process to determine if data might be exfiltrated or communicated to an external host.
+- Investigate any file modifications or creations by the process to identify if encoded data was written to disk or if there are any suspicious files.
+- Correlate the encoding activity with other security alerts or indicators of compromise to assess if it is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use Base16 or Base32 encoding/decoding for legitimate purposes such as data integrity checks or configuration management. These activities can be mistaken for malicious behavior.
+- Automated scripts: Some automated scripts or applications may use Base16 or Base32 encoding as part of their normal operation, leading to false positives if these processes are not excluded.
+- Development and testing: Developers might use encoding/decoding tools during software development or testing phases, which can trigger alerts if not properly accounted for.
+- To manage false positives, users can create exceptions for known benign processes by adding specific process names or arguments to an exclusion list. This can be done by updating the detection rule to ignore certain command-line arguments or by whitelisting processes that are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration or lateral movement by the adversary.
+- Conduct a thorough investigation of the process execution logs to identify the source and scope of the encoding/decoding activity.
+- Analyze the command-line arguments and any associated scripts or files to determine if sensitive data was encoded or if malicious payloads were delivered.
+- Review user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar encoding/decoding activities.
+- Restore the system to its operational state by removing any malicious files, applying security patches, and verifying the integrity of critical system files.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface and prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
index b2a6a079cf5..57b9ecdaca4 100644
--- a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
+++ b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,49 @@ file.Ext.original.path : (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 System Binary Moved or Copied
+
+System binaries are essential executables in Linux environments, responsible for core system functions. Adversaries may exploit these by moving or copying them to evade detection, often renaming them to mask malicious activities. The detection rule identifies unusual movements of these binaries, excluding legitimate processes and paths, to flag potential threats. This helps in identifying masquerading attempts, aligning with defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific system binary that was moved or copied, focusing on the `file.Ext.original.path` and `event.action` fields.
+- Check the `process.name` and `process.executable` fields to determine which process initiated the action and assess if it is a known legitimate process or potentially malicious.
+- Investigate the `host.os.type` to confirm the operating system environment and ensure the alert pertains to a Linux system.
+- Examine the `event.type` field to verify that the event is indeed a "change" event, indicating a modification to the file system.
+- Use Osquery to gather additional context about the process that triggered the alert. For example, run the following query to get more details about the process: `SELECT * FROM processes WHERE name = '<process.name from alert>';`
+- Check the system logs for any related entries around the time of the alert to identify any other suspicious activities or anomalies.
+- Investigate the user account associated with the process by checking the `process.user` field, if available, to determine if the action was performed by a legitimate user.
+- Look for any recent changes in the system's package management logs (e.g., dpkg, rpm) that might explain the movement or copying of the binary.
+- Assess the file's new location and permissions to determine if it aligns with typical system configurations or if it appears suspicious.
+- Cross-reference the alert with any other recent alerts or incidents involving the same host or process to identify potential patterns or ongoing threats.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate system updates or package management activities, where system binaries are moved or copied as part of routine operations. These include processes like `dpkg`, `rpm`, `yum`, `apt`, and `snapd`, which are commonly used for installing or updating software packages.
+- System maintenance tasks performed by administrators or automated scripts might also trigger this rule. For example, using `ln` to create symbolic links or `sed` for in-place file editing can result in file movements that are benign.
+- Development and testing environments often involve frequent changes to system binaries, especially when using tools like `pip`, `node`, or `platform-python` for package management and script execution.
+- To manage these false positives, users can create exceptions for known benign processes and paths by adding them to the exclusion list in the detection rule. This involves specifying trusted process names, executables, or file paths that are known to perform legitimate operations.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the binary movement, examining logs and system changes.
+- Verify the integrity of the moved or copied binaries by comparing them with known good versions or using a trusted source.
+- Remove or quarantine any unauthorized or suspicious binaries and restore legitimate versions from backups or trusted repositories.
+- Escalate the incident to the security operations team if the activity is confirmed as malicious, providing detailed findings and context.
+- Implement enhanced logging policies to capture detailed file and process activity, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Review and update access controls and permissions to limit the ability of unauthorized users to move or copy system binaries.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly.
+- Apply system hardening measures, such as enabling file integrity monitoring and restricting execution of binaries from non-standard directories, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_chattr_immutable_file.toml b/rules/linux/defense_evasion_chattr_immutable_file.toml
index 6d5ba1837fd..1757e477670 100644
--- a/rules/linux/defense_evasion_chattr_immutable_file.toml
+++ b/rules/linux/defense_evasion_chattr_immutable_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,49 @@ process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and n
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File made Immutable by Chattr
+
+The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, excluding known legitimate parent processes, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file that was made immutable and the exact time the `chattr` command was executed.
+- Examine the `process.parent.executable` and `process.parent.name` fields to determine the parent process that initiated the `chattr` command, ensuring it is not a known legitimate process.
+- Use Osquery to list all immutable files on the system to identify any other files that may have been altered. Example query: `SELECT path FROM file WHERE attributes LIKE '%i%';`
+- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Check the system logs around the time of the alert for any other suspicious activities or related events that might provide additional context.
+- Analyze the command-line arguments (`process.args`) used with `chattr` to understand the specific changes made to the file attributes.
+- Review recent changes to critical system files (e.g., `.ssh`, `/etc/passwd`) to identify any unauthorized modifications.
+- Correlate the alert with other security events or alerts from the same host to identify potential patterns or related incidents.
+- Investigate the network activity of the host around the time of the alert to detect any suspicious outbound or inbound connections.
+- Consult threat intelligence sources to determine if the file or process involved in the alert is associated with known malicious activity or threat actors.
+
+### False positive analysis
+
+- System maintenance scripts or administrative tasks may use `chattr` to protect critical system files, leading to false positives. Users can handle these by identifying and excluding specific scripts or processes that are known to perform legitimate file attribute changes.
+- Backup or security software might use `chattr` to safeguard files during operations, which could trigger the rule. Users should review and whitelist these applications if they are verified as non-threatening.
+- Automated configuration management tools like Ansible or Puppet may employ `chattr` to enforce file states, resulting in false positives. Users can exclude these tools by adding their process names or paths to the exception list.
+- Some system updates or package installations might temporarily use `chattr` to lock files, causing false alerts. Users should monitor update processes and exclude them if they are confirmed to be safe.
+- To manage false positives, users can refine the detection rule by adding specific parent process names or executable paths to the exclusion criteria, ensuring that only suspicious or unknown uses of `chattr` are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Investigate the process tree to identify the parent process of the `chattr` command and determine if it is associated with known malicious activity.
+- Review recent file changes and access logs to identify any unauthorized modifications to critical system files such as `.ssh` or `/etc/passwd`.
+- Remove the immutable attribute from any files identified as malicious or suspicious using `chattr -i` and conduct a thorough malware scan on these files.
+- Restore any altered system files from a known good backup to ensure system integrity and functionality.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and file modification events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Apply system hardening measures, such as restricting the use of `chattr` to authorized users only and regularly auditing file permissions and attributes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
index 989283a3641..0c8749b81d0 100644
--- a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
+++ b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,50 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
  and process.name == "dmesg" and process.args == "-c"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Clear Kernel Ring Buffer
+
+The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may exploit the `dmesg -c` command to clear these logs, concealing traces of malicious activities like installing unauthorized kernel modules. The detection rule identifies this by monitoring the execution of `dmesg` with specific arguments, flagging potential attempts to erase evidence from the kernel ring buffer.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `dmesg -c` command execution, focusing on the `process.name` and `process.args` fields to ensure the command was executed with the `-c` argument.
+- Check the `event.type` and `event.action` fields to verify that the process was indeed started and executed, confirming the legitimacy of the alert.
+- Investigate the user account associated with the `dmesg` command execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.
+- Examine the process tree to identify any parent processes that may have initiated the `dmesg` command, which could provide context on how the command was executed.
+- Utilize Osquery to gather additional context on the system state at the time of the alert. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
+- Analyze system logs around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the execution of the `dmesg -c` command.
+- Check for any recent changes to kernel modules or system configurations that could indicate an attempt to install unauthorized software.
+- Investigate network activity from the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
+- Review historical alerts and logs for similar `dmesg -c` executions to determine if this is part of a recurring pattern or a one-time event.
+- Correlate the findings with threat intelligence sources to assess if the activity matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or campaigns.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the `dmesg -c` command as part of routine maintenance or troubleshooting, leading to false positives. 
+- Regularly scheduled tasks or cron jobs that clear the kernel ring buffer for log management purposes can trigger the detection rule.
+- Developers or IT personnel might execute `dmesg -c` during testing or debugging processes, which are non-malicious activities.
+- To manage these false positives, users can create exceptions for specific users or processes known to perform legitimate `dmesg -c` operations.
+- Implementing a whitelist for trusted scripts or administrative accounts that frequently use `dmesg -c` can help reduce unnecessary alerts.
+- Monitoring the context of the `dmesg -c` execution, such as the user account and associated processes, can aid in distinguishing between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to determine the scope of the incident, focusing on identifying any unauthorized kernel modules or other suspicious activities.
+- Review system logs and other security telemetry to identify any additional indicators of compromise or related malicious activities.
+- Remove any unauthorized kernel modules and restore the kernel to its original state using trusted sources or backups.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to ensure comprehensive monitoring of kernel activities and system changes, including the use of tools like auditd for detailed process tracking.
+- Integrate security solutions such as endpoint detection and response (EDR) tools to improve visibility and detection capabilities for similar threats in the future.
+- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities that could be exploited by attackers.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining system integrity and security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
index ca6700c78de..abbdaa5efd9 100644
--- a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
+++ b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,49 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Hidden Files and Directories via Hidden Flag
+
+In Linux environments, the 'chflags' command can set file attributes, including the 'hidden' flag, to conceal files from standard directory listings. Adversaries exploit this to obscure malicious files, evading detection. The detection rule monitors file creation events where 'chflags' is used, identifying potential misuse by correlating these actions with known evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file creation event, focusing on the 'host.os.type', 'event.type', and 'process.name' fields to confirm the use of 'chflags' on a Linux system.
+- Examine the file path and name associated with the alert to determine if it matches known malicious patterns or locations commonly used for hiding files.
+- Check the user account associated with the 'chflags' process to assess if the activity aligns with expected behavior for that user or if it indicates potential compromise.
+- Investigate the parent process of 'chflags' to understand the context of how and why the hidden flag was applied, which may reveal additional suspicious activity.
+- Utilize Osquery to list all files with the hidden flag set on the system to identify any other potentially malicious files. Example query: `SELECT path FROM file WHERE flags LIKE '%hidden%';`
+- Cross-reference the timestamp of the file creation event with other logs, such as authentication or network activity, to identify any correlated suspicious behavior.
+- Analyze recent command history for the user associated with the 'chflags' process to uncover any manual commands that may indicate malicious intent.
+- Review system logs for any recent privilege escalation attempts that could have allowed an adversary to execute 'chflags' with elevated permissions.
+- Investigate any recent changes to system configurations or security settings that could facilitate the use of hidden files for evasion.
+- Consult threat intelligence sources to determine if the file path, name, or associated user account has been linked to known threat actors or campaigns.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the 'chflags' command for legitimate purposes, such as managing system files or organizing directories, which can trigger false positives.
+- Backup or maintenance scripts that regularly modify file attributes to protect or hide system-critical files might also be flagged by this rule.
+- To manage these false positives, users can create exceptions for specific processes or scripts known to use 'chflags' legitimately by adding them to an allowlist.
+- Regularly review and update the allowlist to ensure it includes only trusted sources, minimizing the risk of overlooking genuine threats.
+- Consider implementing additional context checks, such as verifying the user or process context, to differentiate between benign and potentially malicious use of the 'chflags' command.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Conduct a thorough investigation to identify all files and directories with the 'hidden' flag set using 'chflags', and determine if they are associated with known malicious activity.
+- Review system logs and security alerts to trace the origin of the 'chflags' command usage and identify any unauthorized access or suspicious user accounts.
+- Remove or quarantine any identified malicious files and directories, ensuring that legitimate files are not affected.
+- Restore any altered or deleted legitimate files from backups, ensuring that the backup is clean and free from any malicious modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed file attribute changes and process execution events for future monitoring and investigation.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar evasion tactics.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Apply system hardening measures, such as restricting the use of 'chflags' to authorized users only and regularly auditing file permissions and attributes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_directory_creation_in_bin.toml b/rules/linux/defense_evasion_directory_creation_in_bin.toml
index dc6eb9300ff..0c1ff2b25b2 100644
--- a/rules/linux/defense_evasion_directory_creation_in_bin.toml
+++ b/rules/linux/defense_evasion_directory_creation_in_bin.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/01"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
 not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Directory Creation in /bin directory
+
+The /bin directory is crucial for system operations, housing essential binaries. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule monitors for directory creation commands targeting /bin and similar paths, excluding legitimate uses, to identify potential threats linked to defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the directory creation event, focusing on the `process.name` and `process.args` fields to verify the use of the `mkdir` command in sensitive directories.
+- Check the `host.os.type` field to ensure the event occurred on a Linux system, as the rule is designed for Linux environments.
+- Investigate the `event.type` and `event.action` fields to confirm the event was a process start and execution, indicating an active directory creation attempt.
+- Examine the `process.args` field to identify the exact directory path targeted for creation, ensuring it matches the monitored paths like `/bin/*`, `/usr/bin/*`, etc.
+- Cross-reference the `process.args` with known legitimate directory creation commands to rule out false positives, as specified in the exclusion list (e.g., `/bin/mkdir`).
+- Use Osquery to gather additional context about the process that triggered the alert. For example, run the query: `SELECT * FROM processes WHERE name = 'mkdir' AND path LIKE '/bin/%';` to identify any suspicious `mkdir` processes.
+- Investigate the parent process of the `mkdir` command to determine if it was initiated by a legitimate user or process, which can provide insights into potential compromise.
+- Check system logs and user activity around the time of the alert to identify any unusual behavior or unauthorized access attempts that could correlate with the directory creation.
+- Review recent changes to the system's environment, such as software installations or updates, that might explain the directory creation in a legitimate context.
+- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize directory creation in the `/bin` directory as part of their tactics, techniques, and procedures (TTPs).
+
+### False positive analysis
+
+- System administrators or automated scripts may create directories in the /bin directory for legitimate purposes, such as organizing custom scripts or binaries that are not part of the default system installation. These actions can trigger false positives.
+- Software installations or updates might temporarily create directories in these paths as part of their setup or configuration processes, leading to benign alerts.
+- To manage these false positives, users can create exceptions for known and trusted processes or scripts that regularly perform directory creation in these paths. This can be done by adding specific process names or command patterns to an exclusion list.
+- Regularly review and update the exclusion list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats while reducing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized directories and files within the /bin and similar directories, using forensic tools if necessary.
+- Review system logs and process execution history to determine the origin and timeline of the directory creation, identifying any associated malicious processes or users.
+- Remove any unauthorized directories and files identified during the investigation, ensuring that no malicious binaries remain in the system.
+- Restore any affected binaries or system files from a known good backup to ensure system integrity and functionality.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed process execution and file system changes, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide real-time alerts for suspicious activities.
+- Apply system hardening measures, such as restricting write permissions in critical directories and implementing application whitelisting to prevent unauthorized software execution.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans, incorporating lessons learned to improve future response efforts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_disable_apparmor_attempt.toml b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
index 9fb904d39f3..13b269e5c58 100644
--- a/rules/linux/defense_evasion_disable_apparmor_attempt.toml
+++ b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/08/08"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Disabling of AppArmor
+
+AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do and access. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes that attempt to stop or disable AppArmor services, such as using commands like `systemctl`, `service`, or `chkconfig` with specific arguments, indicating potential tampering with security defenses.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time.
+- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Examine the parent process of the suspicious activity to understand how the process was initiated and if it was part of a larger chain of events.
+- Use Osquery to list all processes related to AppArmor to verify if any have been stopped or disabled. Example query: `SELECT name, path, pid FROM processes WHERE name IN ('systemctl', 'service', 'chkconfig', 'ln');`
+- Review system logs, such as `/var/log/syslog` or `/var/log/auth.log`, for any additional context or anomalies around the time of the alert.
+- Check for any recent changes to AppArmor profiles or configurations in `/etc/apparmor.d/` to identify unauthorized modifications.
+- Investigate network connections from the host to determine if there are any suspicious outbound connections that could indicate data exfiltration or command and control activity.
+- Verify the integrity of AppArmor-related files and directories to ensure they have not been tampered with, using tools like `sha256sum` to compare against known good hashes.
+- Cross-reference the alert with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to gather additional context and corroborate findings.
+
+### False positive analysis
+
+- Routine system maintenance or administrative tasks may trigger this rule, such as legitimate updates or configuration changes that require temporarily stopping AppArmor.
+- Automated scripts or configuration management tools like Ansible, Puppet, or Chef might execute commands that match the rule criteria during system provisioning or updates.
+- Users can handle these false positives by creating exceptions for known maintenance windows or trusted administrative scripts, ensuring that these activities are logged and reviewed to confirm their legitimacy.
+- Exclude specific user accounts or process paths associated with trusted administrative tasks from triggering the rule, while maintaining a log of these exclusions for audit purposes.
+- Regularly review and update the list of exceptions to adapt to changes in system administration practices or infrastructure updates, ensuring that only non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Investigate the process logs to identify the source and scope of the attempt to disable AppArmor, focusing on the user accounts and IP addresses involved.
+- Review recent changes to AppArmor profiles and configurations to ensure no unauthorized modifications have been made.
+- Restore AppArmor to its operational state by re-enabling the service using `systemctl start apparmor` or `service apparmor start`.
+- Conduct a thorough malware scan on the affected system to detect and remove any malicious software that may have been introduced.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a broader attack.
+- Implement enhanced logging policies to capture detailed process execution and system changes, ensuring that future attempts to disable security tools are detected promptly.
+- Integrate security information and event management (SIEM) solutions to correlate events and improve detection capabilities across the network.
+- Apply system hardening measures, such as restricting administrative privileges and implementing strict access controls, to reduce the risk of future attacks.
+- Review and update security policies and procedures to incorporate lessons learned from the incident, ensuring a more robust defense against similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_disable_selinux_attempt.toml b/rules/linux/defense_evasion_disable_selinux_attempt.toml
index 3de937008a8..24b00198b2b 100644
--- a/rules/linux/defense_evasion_disable_selinux_attempt.toml
+++ b/rules/linux/defense_evasion_disable_selinux_attempt.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/22"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,50 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
  and process.name == "setenforce" and process.args == "0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Disabling of SELinux
+
+SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for processes that execute the command to set SELinux to permissive mode, indicating a potential security compromise.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "setenforce" and the process arguments are "0", indicating an attempt to set SELinux to permissive mode.
+- Check the timestamp of the event to determine when the attempt to disable SELinux occurred.
+- Identify the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
+- Investigate the parent process of "setenforce" to understand the context in which it was executed and identify any related suspicious activity.
+- Examine the command history of the user account involved to see if there are other suspicious commands executed around the same time.
+- Use Osquery to gather additional context about the system state and user activity. For example, run the following Osquery query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY time DESC LIMIT 20;`
+- Analyze system logs, such as /var/log/audit/audit.log, for any related entries that might provide more context on the SELinux status change and other security events.
+- Check for any recent changes to SELinux configuration files, such as /etc/selinux/config, to see if there have been unauthorized modifications.
+- Investigate network activity from the host around the time of the event to identify any potential data exfiltration or communication with known malicious IP addresses.
+- Correlate this event with other security alerts or anomalies in the environment to determine if it is part of a larger attack campaign.
+
+### False positive analysis
+
+- System administrators or automated scripts may legitimately set SELinux to permissive mode during system maintenance or troubleshooting, leading to false positives. 
+- Development environments might temporarily disable SELinux to facilitate software testing, which can trigger the detection rule.
+- Some legacy applications may require SELinux to be set to permissive mode for compatibility reasons, resulting in non-malicious alerts.
+- To manage these false positives, users can create exceptions for known maintenance windows or specific user accounts that are authorized to modify SELinux settings.
+- Implementing a whitelist of processes or scripts that are allowed to change SELinux modes can help reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the current SELinux status using the command `sestatus` to confirm if it has been set to permissive or disabled.
+- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities on the system, focusing on recent process executions and file modifications.
+- Review system logs and security alerts to determine the timeline and scope of the compromise, correlating with the MITRE ATT&CK technique T1562 for impair defenses.
+- Restore SELinux to enforcing mode using the command `setenforce 1` and ensure that the SELinux configuration is set to enforcing in the `/etc/selinux/config` file.
+- Perform a comprehensive malware scan and integrity check on the system to identify and remove any malicious software or unauthorized changes.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and system changes, integrating with SIEM solutions for real-time alerting.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future occurrences.
+- Apply system hardening measures, such as regular patching, disabling unnecessary services, and enforcing strict access controls, to reduce the attack surface and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
index 1b325e4f75f..b16f05110fb 100644
--- a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
+++ b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and event.type != "deletion" and file.path == "/etc/doas.conf"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Defense Evasion via Doas
+
+Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or execute commands stealthily. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion" to ensure the alert is relevant.
+- Check the timestamp of the alert to determine when the suspicious activity occurred and correlate it with other events in the system logs around the same time.
+- Identify the user account associated with the event to determine if the activity was performed by a legitimate user or a potential adversary.
+- Examine the process that made changes to the Doas configuration file by reviewing process creation logs or using process monitoring tools.
+- Use Osquery to list recent modifications to the Doas configuration file with the query: `SELECT * FROM file WHERE path = '/etc/doas.conf' ORDER BY mtime DESC LIMIT 5;` to gather more context on the changes.
+- Investigate the command history of the user involved in the alert to identify any suspicious commands executed around the time of the alert.
+- Check for any recent changes in user privileges or group memberships that might indicate privilege escalation attempts.
+- Review system authentication logs to identify any unusual login attempts or patterns that coincide with the alert.
+- Analyze network logs for any suspicious outbound connections or data exfiltration attempts following the alert.
+- Cross-reference the alert with other security tools and logs to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may regularly update or modify the Doas configuration file as part of legitimate system maintenance or configuration changes. These activities can trigger the detection rule but are not indicative of malicious behavior.
+- Software updates: Certain software installations or updates might modify the Doas configuration file to ensure compatibility or to set specific permissions, leading to false positives.
+- Configuration management tools: Automated tools like Ansible, Puppet, or Chef might alter the Doas configuration file as part of their normal operation, which can be mistaken for suspicious activity.
+- To manage these false positives, users can create exceptions for known administrative activities or trusted software processes by whitelisting specific users or processes that are authorized to modify the Doas configuration file. Additionally, maintaining a log of legitimate changes and correlating them with detected events can help differentiate between benign and suspicious modifications.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the integrity of the Doas configuration file by comparing it with a known good backup or baseline configuration.
+- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities in the system logs, focusing on user access and command execution patterns.
+- Revert any unauthorized changes to the Doas configuration file and restore it from a trusted backup if necessary.
+- Change all potentially compromised user credentials, especially those with elevated privileges, to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for critical configuration files and privileged command executions to detect future unauthorized changes.
+- Integrate security information and event management (SIEM) solutions to correlate events and improve threat detection capabilities.
+- Apply system hardening measures, such as restricting access to configuration files and enforcing the principle of least privilege for user accounts.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
index 2e7b12d950d..2d12d6c931f 100644
--- a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
+++ b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -80,6 +80,50 @@ not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Dynamic Linker Creation or Modification
+
+The dynamic linker in Linux systems is crucial for loading shared libraries needed by programs at runtime. Adversaries may exploit this by altering linker configuration files to hijack program execution, redirecting it to malicious libraries. The detection rule identifies suspicious creation or modification of these files, excluding legitimate processes and temporary files, to flag potential hijacking attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path involved in the creation or modification event, focusing on paths like "/etc/ld.so.preload", "/etc/ld.so.conf.d/*", and "/etc/ld.so.conf".
+- Check the process executable that triggered the alert to determine if it is listed in the exclusion list, which includes common package managers and system processes.
+- Investigate the user account associated with the process that made the change to assess if it has legitimate access or if it might be compromised.
+- Use Osquery to gather more information about the process that triggered the alert. For example, run the following query to get details about the process: `SELECT * FROM processes WHERE pid = <process_id>;`.
+- Examine the process tree to understand the parent-child relationship and identify if the process was spawned by a legitimate or suspicious parent process.
+- Check the file's modification history and access times to determine if there have been any recent unauthorized changes or access patterns.
+- Investigate any network connections or external communications initiated by the process to identify potential command and control activity.
+- Review system logs for any other suspicious activities or anomalies around the time of the alert, such as failed login attempts or unusual user behavior.
+- Correlate the alert with other security events or alerts in the environment to identify if this is part of a broader attack campaign.
+- Verify the integrity of the dynamic linker configuration files by comparing them against known good baselines or backups to identify unauthorized changes.
+
+### False positive analysis
+
+- Package management operations: Legitimate package managers such as dpkg, rpm, yum, and others may modify dynamic linker configuration files during software installation or updates. These actions are typically benign and can be excluded by adding the package manager executables to the exception list.
+- System updates and maintenance: Automated system updates or maintenance scripts might trigger the rule. Exclude known update processes or scripts by specifying their executables in the exception criteria.
+- Temporary files: Editors like vim may create temporary swap files (e.g., with extensions like .swp, .swpx) during editing sessions. These can be safely ignored by excluding files with these extensions.
+- Virtualization and containerization tools: Tools such as Docker, Podman, and VMware may modify linker configurations as part of their normal operations. Exclude these processes by adding their executables to the exception list.
+- Monitoring and security tools: Some monitoring or security tools, like Dynatrace OneAgent, may interact with linker files. Exclude these tools by specifying their installation paths in the exception criteria.
+- Custom scripts or applications: If custom scripts or applications are known to modify linker configurations as part of their functionality, consider excluding these by adding their process names or paths to the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the modification, including reviewing recent changes to dynamic linker configuration files and correlating with process execution logs.
+- Verify the integrity of the dynamic linker configuration files by comparing them with known good backups or baselines.
+- Restore any altered dynamic linker configuration files from a trusted backup to ensure the system's execution flow is not hijacked.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and file modification events, focusing on critical system directories and configuration files.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Review and update access controls and permissions for critical system files to minimize the risk of unauthorized modifications.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements to prevent recurrence.
+- Educate users and administrators on the importance of maintaining system integrity and recognizing signs of potential compromise."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
index e51936b4a4f..7d13bf34482 100644
--- a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
+++ b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
  and process.name == "touch" and process.args == "-r" and
 process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 ESXI Timestomping using Touch Command
+
+VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring for the 'touch' command targeting specific VMware paths, signaling potential timestamp tampering for evasion.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'touch' command with the "-r" flag in the process arguments, specifically targeting paths like "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*".
+- Verify the user account associated with the process execution to determine if it aligns with expected administrative activity or if it might be indicative of unauthorized access.
+- Check the process execution timeline to identify any preceding or subsequent suspicious activities that might correlate with the timestamp modification attempt.
+- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any potential script or application that might have triggered it.
+- Utilize Osquery to list recent file modifications in the targeted directories to identify any unauthorized changes. Example query: `SELECT path, mtime FROM file WHERE path LIKE '/etc/vmware/%' OR path LIKE '/usr/lib/vmware/%' OR path LIKE '/vmfs/%' ORDER BY mtime DESC LIMIT 10;`
+- Examine system logs for any login attempts or access patterns around the time of the alert to identify potential unauthorized access.
+- Cross-reference the alert with any other security events or alerts from the same host to identify patterns or correlations that might indicate a broader attack.
+- Review network logs for any unusual outbound connections from the host that might suggest data exfiltration or communication with a command and control server.
+- Check for any recent changes in user privileges or group memberships that might have facilitated the execution of the 'touch' command with elevated permissions.
+- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the potential security incident.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use the 'touch' command with the "-r" flag during legitimate maintenance activities, such as synchronizing timestamps across files for backup or archival purposes. To manage these, users can create exceptions for known administrative scripts or processes that regularly perform these actions.
+- Automated scripts: Some automated scripts or system management tools might use the 'touch' command with the "-r" flag as part of their normal operations. Users should identify these scripts and exclude them from the detection rule by specifying their process names or paths.
+- Software updates: During software updates or installations, legitimate processes might modify timestamps in VMware-related directories. Users can handle these by temporarily disabling the rule during scheduled updates or by creating exceptions for update processes.
+- Backup operations: Backup software might use the 'touch' command to ensure file metadata consistency. Users should identify and exclude these backup processes from the rule to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or changes.
+- Conduct a thorough investigation to identify any unauthorized changes or access, focusing on the specific VMware paths mentioned in the alert.
+- Review system logs and command history to determine the extent of the compromise and identify any additional malicious activities.
+- Restore any altered files from known good backups to ensure the integrity of the VMware environment.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed command execution and file access events, particularly for critical directories like VMware paths.
+- Integrate with a security information and event management (SIEM) system to correlate events and detect similar activities across the network.
+- Apply security patches and updates to the ESXi host and associated systems to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting access to critical directories, enforcing least privilege, and using file integrity monitoring tools."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_file_deletion_via_shred.toml b/rules/linux/defense_evasion_file_deletion_via_shred.toml
index e942a964e63..95d66a7cac4 100644
--- a/rules/linux/defense_evasion_file_deletion_via_shred.toml
+++ b/rules/linux/defense_evasion_file_deletion_via_shred.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ process where host.os.type == "linux" and event.type == "start" and process.name
   "-u", "--remove", "-z", "--zero"
 ) and not process.parent.name == "logrotate"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File Deletion via Shred
+
+The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential misuse for stealthy file removal.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the execution of the `shred` command, focusing on the `process.name` and `process.args` fields to verify the suspicious arguments used.
+- Check the `process.parent.name` field to ensure the parent process is not a benign process like `logrotate`, which is excluded in the detection rule.
+- Investigate the user account associated with the `shred` process by examining the `user.name` field to determine if the activity aligns with expected behavior for that user.
+- Analyze the `host.os.type` and `host.name` fields to identify the specific system where the `shred` command was executed, and assess if this system is a common target for such activities.
+- Use Osquery to gather additional context about the file system activity around the time of the alert. For example, run the following Osquery query to list recent file modifications: `SELECT * FROM file WHERE path LIKE '/path/to/suspicious/directory/%' AND mtime > (SELECT strftime('%s', 'now') - 3600);`
+- Examine the `event.type` field to confirm the event type is "start," indicating the initiation of the `shred` process, and correlate with other process events to understand the sequence of actions.
+- Review system logs and other security tools for any related alerts or anomalies around the time of the `shred` execution to identify potential precursor or follow-up activities.
+- Investigate network activity from the host using network monitoring tools to check for any suspicious outbound connections that might indicate data exfiltration or command-and-control communication.
+- Cross-reference the alert with known threat intelligence sources to determine if the observed behavior matches any known adversary tactics, techniques, or procedures (TTPs).
+- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation and facilitate further analysis if needed.
+
+### False positive analysis
+
+- The `shred` command may be used by legitimate system maintenance processes, such as automated scripts for secure file deletion, which can trigger false positives. 
+- System administrators might use `shred` for routine secure deletion of sensitive files, which should be considered when analyzing alerts.
+- To manage these false positives, users can create exceptions for known benign processes or scripts that frequently use `shred` with the specified arguments.
+- Implementing a whitelist for specific users or processes that are authorized to use `shred` can help reduce noise in the detection system.
+- Regularly review and update the list of exceptions to ensure that only legitimate uses of `shred` are excluded from alerts, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
+- Conduct a thorough investigation to identify the scope of the intrusion, focusing on logs and other forensic evidence to determine the extent of file deletion and any other malicious actions.
+- Utilize file recovery tools to attempt restoration of any critical files that may have been deleted using the `shred` command.
+- Review and analyze the process tree to identify the parent process of `shred` and any associated processes that may indicate the presence of malware or unauthorized scripts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships, to aid in future investigations.
+- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious file deletion activities and other potential indicators of compromise.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future.
+- Implement hardening measures such as restricting the use of the `shred` command to authorized users only and employing file integrity monitoring to detect unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_file_mod_writable_dir.toml b/rules/linux/defense_evasion_file_mod_writable_dir.toml
index 7c4265bf95b..cbc636c7321 100644
--- a/rules/linux/defense_evasion_file_mod_writable_dir.toml
+++ b/rules/linux/defense_evasion_file_mod_writable_dir.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,49 @@ host.os.type:linux and event.category:process and event.type:start and
 process.name:(chattr or chgrp or chmod or chown) and process.working_directory:(/dev/shm or /tmp or /var/tmp) and
 not process.parent.name:(apt-key or update-motd-updates-available or apt-get)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File Permission Modification in Writable Directory
+
+In Linux environments, file permissions control access to files and directories. Writable directories like /tmp are often targeted by adversaries to drop and execute malicious payloads. By modifying file permissions, attackers can ensure their payloads execute with the necessary privileges. The detection rule identifies suspicious permission changes by non-root users in these directories, excluding benign processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (chattr, chgrp, chmod, or chown) that triggered the alert and the associated user account.
+- Examine the process.working_directory field to confirm the directory involved (/dev/shm, /tmp, or /var/tmp) and assess if the directory is commonly used for legitimate purposes by the user.
+- Check the process.parent.name field to ensure the process was not initiated by a benign parent process like apt-key, update-motd-updates-available, or apt-get.
+- Investigate the history of the user account involved in the alert to determine if there have been any previous suspicious activities or alerts associated with this user.
+- Use Osquery to list recent file permission changes in the specified directory. Example query: `SELECT path, mode, uid, gid, atime, mtime FROM file WHERE directory IN ('/dev/shm', '/tmp', '/var/tmp') AND mode != '0755';`
+- Correlate the timestamp of the alert with other logs, such as authentication logs, to identify any unusual login activities or patterns around the time of the permission change.
+- Analyze the command-line arguments of the process to understand the specific permission changes made and assess if they align with typical user behavior.
+- Review any associated network activity from the host around the time of the alert to identify potential data exfiltration or communication with known malicious IP addresses.
+- Investigate other processes running on the host to identify any additional suspicious activities or processes that may have been spawned as a result of the permission change.
+- Check for any recent file modifications or new file creations in the involved directory to identify potential payloads or scripts that may have been dropped by the adversary.
+
+### False positive analysis
+
+- Routine administrative tasks by non-root users, such as developers or system administrators, may trigger the rule when they modify file permissions in writable directories for legitimate purposes. 
+- Automated scripts or applications that require temporary file permission changes in directories like /tmp for functionality or performance reasons can also result in false positives.
+- Development environments where non-root users frequently compile or test software may involve permission changes that are benign.
+- To manage these false positives, users can create exceptions for specific processes or users known to perform legitimate permission modifications by updating the detection rule to exclude these entities.
+- Regularly review and update the list of excluded processes or users to ensure that only non-threatening behaviors are ignored, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the process that modified file permissions by checking the process owner, command line arguments, and parent process.
+- If the process is deemed malicious, terminate it and any associated processes to stop further execution.
+- Conduct a thorough investigation to identify any additional files or payloads dropped by the adversary in writable directories.
+- Restore file permissions to their original state and remove any unauthorized files or payloads identified during the investigation.
+- Review and analyze system logs to trace the origin of the attack and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed information on file permission changes and process executions in writable directories.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities.
+- Apply system hardening measures, such as restricting write access to critical directories and implementing least privilege principles, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_hex_payload_execution.toml b/rules/linux/defense_evasion_hex_payload_execution.toml
index 1ddc1204235..9e23e1d8ce8 100644
--- a/rules/linux/defense_evasion_hex_payload_execution.toml
+++ b/rules/linux/defense_evasion_hex_payload_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Hex Payload Execution
+
+Hex encoding is often used to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding payloads in hex to bypass defenses. The detection rule identifies suspicious execution patterns on Linux, such as using tools like `xxd`, or scripting languages like Python and PHP, to decode hex-encoded data, signaling potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and command line arguments that triggered the rule, focusing on fields like `process.name` and `process.command_line`.
+- Check the `host.os.type` and `event.type` fields to confirm the alert pertains to a Linux system and involves a process start event.
+- Investigate the parent process of the suspicious execution using the `process.parent.name` and `process.parent.command_line` fields to understand the context in which the hex decoding was initiated.
+- Examine the user account associated with the process execution by reviewing the `user.name` field to determine if the activity aligns with expected behavior for that user.
+- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<process_name>' AND cmdline LIKE '%<suspicious_command_line>%';` to verify the process details and any related activity.
+- Analyze the network activity of the host during the time of the alert to identify any suspicious connections or data transfers that may correlate with the hex payload execution.
+- Review recent file modifications or creations on the host using file integrity monitoring tools or logs to detect any changes that coincide with the alert.
+- Check for any other alerts or logs related to the same host or user around the time of the alert to identify potential patterns or additional suspicious activities.
+- Investigate the system's history for any previous instances of similar alerts or processes to determine if this is part of a recurring pattern.
+- Consult threat intelligence sources to see if the specific command line patterns or process names have been associated with known malicious campaigns or tools.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use tools like `xxd`, Python, PHP, Ruby, Perl, or Lua for legitimate purposes such as data conversion or debugging, which can trigger this rule. To manage these, users can create exceptions for known administrative scripts or processes that frequently use these tools in a non-threatening manner.
+- Development and testing activities: Developers often use hex encoding and decoding during software development and testing phases. To handle these false positives, users can exclude specific development environments or user accounts from the rule.
+- Automated scripts and cron jobs: Automated scripts or scheduled tasks that perform regular data processing might use hex encoding for legitimate reasons. Users can whitelist these scripts by identifying their unique command-line patterns or process names.
+- Security tools and monitoring software: Some security tools may use hex encoding as part of their normal operations. Users should identify these tools and exclude them from the rule to prevent unnecessary alerts.
+- Data analysis and research: Researchers and data analysts might use hex encoding for data analysis purposes. Users can manage these false positives by excluding specific user accounts or processes associated with research activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the process execution logs to identify the source and scope of the hex payload execution.
+- Analyze the decoded payload to determine its intent and potential impact on the system.
+- Remove any identified malicious files or processes from the system to prevent further execution.
+- Apply patches and updates to the operating system and applications to mitigate vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics.
+- Restore the system from a known good backup to ensure the integrity and security of the operational environment.
+- Review and update security policies and configurations to harden the system against similar obfuscation and execution techniques in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_directory_creation.toml b/rules/linux/defense_evasion_hidden_directory_creation.toml
index 079b1f1292e..e14a291c242 100644
--- a/rules/linux/defense_evasion_hidden_directory_creation.toml
+++ b/rules/linux/defense_evasion_hidden_directory_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/01"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,49 @@ process.name == "mkdir" and process.parent.executable like (
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Hidden Directory Creation via Unusual Parent
+
+In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files. Adversaries exploit this feature to conceal malicious files by creating hidden directories using uncommon parent processes. The detection rule identifies such activities by monitoring directory creation commands executed by unexpected parent executables in sensitive directories, filtering out known benign patterns to reduce false positives.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific parent executable and the directory path where the hidden directory was created. Pay attention to the `process.parent.executable` and `process.args` fields.
+- Check the process tree to understand the context of the `mkdir` command execution. Determine if the parent process is part of a known application or script.
+- Use Osquery to list all processes running under the parent executable identified in the alert. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE path LIKE '/dev/shm/%' OR path LIKE '/tmp/%' OR path LIKE '/var/tmp/%' OR path LIKE '/var/run/%' OR path LIKE '/root/%' OR path LIKE '/boot/%' OR path LIKE '/var/www/html/%' OR path LIKE '/opt/%';`
+- Investigate the parent executable's origin and integrity. Check if it matches known hashes or if it has been modified recently.
+- Examine the contents of the newly created hidden directory to identify any suspicious files or scripts. Look for known malicious file signatures or unusual file types.
+- Cross-reference the timestamp of the directory creation with other logs (e.g., authentication, network, or application logs) to identify any correlated suspicious activities.
+- Check for any recent changes in user accounts or permissions that could have facilitated the creation of the hidden directory.
+- Investigate the user account associated with the process execution to determine if it has been compromised or is behaving unusually.
+- Review historical data to see if similar hidden directory creation events have occurred in the past, indicating a potential pattern or ongoing campaign.
+- Consult threat intelligence sources to determine if the parent executable or directory path is associated with known attack techniques or threat actors.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate administrative scripts or applications that create hidden directories for configuration or temporary storage purposes. These can include package managers, build systems, or development tools that operate in directories like `/tmp` or `/var/tmp`.
+- Users can handle these false positives by creating exceptions for specific parent executables or command patterns that are known to be benign. For instance, adding exceptions for processes like `/tmp/newroot/*` or `/run/containerd/*` can help reduce noise.
+- Another method to manage false positives is to refine the rule by excluding command lines that match known safe patterns, such as `mkdir -p .` or `mkdir ./*`, which are commonly used in legitimate operations.
+- Regularly reviewing and updating the list of exceptions based on the environment's typical behavior can help maintain the balance between detection accuracy and minimizing false positives.
+- It's important to consider the context of the environment and the typical behavior of applications and scripts to ensure that legitimate activities are not inadvertently flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on the unusual parent process and any associated hidden directories.
+- Review and analyze logs from the system and network to trace the origin and timeline of the attack, leveraging MITRE ATT&CK T1564 for context on hiding artifacts.
+- Remove any identified malicious files or directories and terminate any suspicious processes related to the alert.
+- Restore the system from a known good backup if the integrity of the system is in question.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process creation events and file system changes for future investigations.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
+- Conduct a security review and harden the system by disabling unnecessary services, enforcing least privilege access, and implementing strong authentication mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
index f013e542b90..659ef922c75 100644
--- a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
+++ b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,49 @@ not process.name in (
   "command-not-found"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation of Hidden Files and Directories via CommandLine
+
+In Linux environments, files and directories prefixed with a dot (.) are hidden by default, a feature often exploited by adversaries to conceal malicious activities. Attackers may create hidden files in writable directories like /tmp or /var/tmp to evade detection. The detection rule identifies suspicious processes creating such hidden files, excluding benign commands like 'ls' or 'git', thus highlighting potential threats while minimizing false positives.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process that triggered the rule, focusing on the `process.name` and `process.args` fields to understand what command was executed.
+- Examine the `process.working_directory` field to determine the directory where the hidden file or directory was created, ensuring it matches one of the common writable directories like `/tmp`, `/var/tmp`, or `/dev/shm`.
+- Check the `host.os.type` field to confirm the operating system is Linux, as the rule is specifically designed for Linux environments.
+- Investigate the parent process of the suspicious process using the `process.parent.name` and `process.parent.args` fields to understand the context in which the hidden file creation was initiated.
+- Use Osquery to list all hidden files in the directory where the alert was triggered. Example query: `SELECT * FROM file WHERE directory = '/tmp' AND filename LIKE '.%'`.
+- Analyze the contents of the hidden file or directory, if accessible, to determine if it contains malicious code or scripts.
+- Review recent system logs and command history for the user associated with the process to identify any unusual or unauthorized activities leading up to the alert.
+- Check for any network connections or data exfiltration attempts associated with the process using network monitoring tools or logs.
+- Investigate other processes executed by the same user or from the same working directory to identify any additional suspicious activities.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack or campaign.
+
+### False positive analysis
+
+- Known false positives for the Creation of Hidden Files and Directories via CommandLine rule include legitimate system and user activities that create hidden files for configuration or temporary purposes. Common examples are software installations or updates that generate hidden files in directories like /tmp or /var/tmp.
+- Users can manage these false positives by adding exceptions for specific processes or commands that are known to create hidden files as part of their normal operation. This can be done by updating the exclusion list in the detection rule to include additional benign processes that are identified during routine monitoring.
+- Regularly review and update the exclusion list to reflect changes in system behavior or new software deployments that may introduce new benign processes creating hidden files.
+- Consider the context of the process creating the hidden file, such as the user account under which the process is running and the typical behavior of that account, to determine if an activity is likely to be a false positive.
+- Implement logging and alerting mechanisms to track the frequency and context of hidden file creation events, which can help in distinguishing between legitimate and suspicious activities over time.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the hidden files and directories created, analyzing their contents and associated processes for malicious indicators.
+- Terminate any suspicious processes identified during the investigation that are associated with the creation of hidden files.
+- Remove or quarantine the hidden files and directories after confirming they are not legitimate or required for system operations.
+- Review and analyze system logs, including process execution and file access logs, to trace the origin and timeline of the malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a broader attack campaign or if advanced persistent threat (APT) involvement is suspected.
+- Implement enhanced logging policies to capture detailed process execution and file creation events, ensuring future incidents can be detected and investigated more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying necessary patches, updating security configurations, and ensuring all malicious artifacts are removed.
+- Harden the system by implementing least privilege access controls, disabling unnecessary services, and regularly auditing writable directories for unauthorized changes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_shared_object.toml b/rules/linux/defense_evasion_hidden_shared_object.toml
index 3f6201d9255..63a6b75a4f3 100644
--- a/rules/linux/defense_evasion_hidden_shared_object.toml
+++ b/rules/linux/defense_evasion_hidden_shared_object.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,49 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and file.extension == "so" and file.name : ".*.so" and
 not process.name == "dockerd"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation of Hidden Shared Object File
+
+Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file creation event, focusing on the file name and path to determine if it matches the pattern of a hidden shared object file (e.g., `.hiddenfile.so`).
+- Examine the process that created the file by checking the `process.name` and `process.pid` fields to identify any suspicious or unexpected processes involved in the file creation.
+- Investigate the user account associated with the file creation event using the `user.name` field to determine if the action was performed by a legitimate user or a potentially compromised account.
+- Use Osquery to list all hidden shared object files on the system with a query like: `SELECT path FROM file WHERE path LIKE '/%.so';` to identify any other hidden .so files that may have been created.
+- Check the file metadata, such as creation and modification timestamps, to understand the timeline of the file's existence and correlate it with other system events.
+- Analyze the file's contents or hash it and compare it against known malicious signatures using a threat intelligence database to determine if it is a known threat.
+- Investigate the parent process of the file creation event to understand the origin of the process chain and identify any potential exploitation or lateral movement activities.
+- Review system logs around the time of the file creation for any unusual activity or errors that might indicate exploitation attempts or other malicious behavior.
+- Check for any network connections initiated by the process that created the file to identify potential command and control communication or data exfiltration attempts.
+- Correlate the event with other alerts or incidents in the environment to determine if this is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- Development and testing environments may generate hidden .so files as part of normal operations, especially when developers are working on shared libraries and use hidden files for version control or temporary storage.
+- System maintenance scripts or automated backup processes might create hidden .so files to temporarily store or manage shared libraries, which can be mistaken for malicious activity.
+- Some legitimate applications or services may use hidden .so files for configuration or internal operations, particularly those that manage plugins or extensions, leading to false positives.
+- Users can manage these false positives by creating exceptions for known benign processes or directories where hidden .so files are expected, such as specific development directories or application-specific paths.
+- Regularly review and update the list of exceptions to ensure that new legitimate processes or directories are accounted for, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to identify the source and scope of the hidden .so file creation, examining process trees and user activity.
+- Remove the malicious hidden .so file and any associated files or processes identified during the investigation.
+- Review and update access controls and permissions to prevent unauthorized file creation and execution.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Implement enhanced logging policies to capture detailed file creation events and process activities, ensuring visibility into similar future activities.
+- Integrate with threat intelligence platforms to enrich alerts with context and improve detection capabilities.
+- Restore the system from a known good backup to ensure the integrity and security of the operating environment.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing strict file permissions, to reduce the attack surface.
+- Conduct a post-incident review to identify gaps in detection and response, updating security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
index caeffc29de3..75b6802fbbb 100644
--- a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
+++ b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,49 @@ event.category:process and host.os.type:linux and event.type:start and event.act
   (user.name:daemon and process.name:at)
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Interactive Shell Launched from System User
+
+In Linux environments, system users are typically non-interactive and serve specific system functions. Adversaries may exploit these accounts to launch interactive shells, bypassing security measures and evading detection. The detection rule identifies such anomalies by monitoring process activities linked to system users, excluding legitimate processes, to flag potential misuse indicative of malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific system user and process involved in launching the interactive shell. Pay attention to the `user.name` and `process.name` fields.
+- Check the `process.parent.executable` and `process.parent.name` fields to understand the parent process that initiated the shell. This can provide context on how the shell was launched.
+- Use Osquery to list all active processes for the identified system user to determine if there are other suspicious activities. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'system_user');`
+- Investigate the command-line arguments of the suspicious process using the `process.args` field to identify any potentially malicious commands or scripts being executed.
+- Examine the system logs around the time of the alert to identify any related events or anomalies that could provide additional context.
+- Check for any recent changes to user accounts or permissions that might have allowed the system user to launch an interactive shell.
+- Investigate network connections initiated by the suspicious process using tools like `netstat` or `ss` to identify any unusual outbound connections.
+- Review the system's authentication logs (e.g., `/var/log/auth.log`) to identify any unauthorized access attempts or successful logins around the time of the alert.
+- Use Osquery to check for any recent file modifications or creations in critical directories that might indicate tampering or preparation for further attacks. Example query: `SELECT * FROM file WHERE path LIKE '/etc/%' AND mtime > (SELECT strftime('%s', 'now') - 3600);`
+- Correlate the findings with other security tools and logs to determine if this activity is part of a broader attack pattern or isolated incident.
+
+### False positive analysis
+
+- System maintenance tasks: Some system maintenance scripts or automated tasks may inadvertently trigger interactive shells under system user accounts. These tasks are typically scheduled and can be identified by their regular occurrence and specific command patterns.
+- Software updates: During software updates, certain processes might temporarily launch interactive shells as part of their installation or configuration routines. Monitoring the timing and context of these updates can help differentiate between legitimate and suspicious activities.
+- Backup operations: Backup software might use system accounts to perform data integrity checks or other operations that could involve launching interactive shells. Identifying the specific backup software and its behavior can help in creating exceptions.
+- Custom scripts: Organizations may have custom scripts that run under system user accounts for specific operational needs. These should be documented, and their behavior should be analyzed to ensure they are not flagged as false positives.
+- To manage false positives, users can create exceptions by adding specific process names, arguments, or user names to the exclusion list in the detection rule. Regularly reviewing and updating these exceptions based on observed legitimate activities will help maintain the accuracy of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the processes and user accounts involved.
+- Terminate any unauthorized interactive shell sessions and processes initiated by system users.
+- Review and analyze system logs, including authentication logs and process execution logs, to gather evidence and understand the attack vector.
+- Change passwords and review permissions for all system user accounts to prevent further exploitation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and user activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore the system to a known good state using backups, ensuring that all malicious artifacts are removed.
+- Apply system hardening measures, such as disabling unnecessary system user accounts and services, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
diff --git a/rules/linux/defense_evasion_kernel_module_removal.toml b/rules/linux/defense_evasion_kernel_module_removal.toml
index 4e4bc435648..f72081cf85a 100644
--- a/rules/linux/defense_evasion_kernel_module_removal.toml
+++ b/rules/linux/defense_evasion_kernel_module_removal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/24"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name == "modprobe" and process.args in ("--remove", "-r"))
 ) and process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kernel Module Removal
+
+Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring specific processes and commands, such as `rmmod` and `modprobe`, especially when executed from common shell environments, indicating potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (`rmmod` or `modprobe`) and the parent process name that triggered the alert, as these can provide initial context on how the module removal was attempted.
+- Check the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
+- Investigate the command-line arguments used with `modprobe` to confirm if the `--remove` or `-r` flags were used, indicating an attempt to remove a module.
+- Examine the process execution timeline to identify any preceding or subsequent suspicious activities, such as privilege escalation attempts or other defense evasion tactics.
+- Use Osquery to list currently loaded kernel modules and compare them with historical data to identify any discrepancies or missing modules. Example query: `SELECT * FROM kernel_modules;`
+- Correlate the alert with other security events or logs from the same host to identify any patterns or related activities that could indicate a broader attack.
+- Analyze the parent process (`sudo`, `bash`, etc.) to determine if it was used legitimately or if it shows signs of compromise, such as unusual execution paths or unexpected arguments.
+- Review system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication anomalies or unauthorized access attempts around the time of the alert.
+- Investigate the network activity of the host to identify any suspicious outbound connections that could suggest data exfiltration or command-and-control communication.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or if there are any active campaigns targeting similar vulnerabilities.
+
+### False positive analysis
+
+- System administrators or automated scripts may legitimately remove kernel modules during routine maintenance or updates, leading to false positives. Users can handle these by creating exceptions for known maintenance scripts or trusted administrator accounts.
+- Some security tools or monitoring solutions might remove kernel modules as part of their normal operation, which could trigger the rule. To manage this, users should identify and whitelist these specific tools or processes.
+- Development environments where kernel modules are frequently loaded and unloaded for testing purposes might also trigger false positives. Users can exclude these environments or specific user accounts from the rule to reduce noise.
+- In environments where custom scripts are used to manage kernel modules, these scripts might inadvertently trigger the rule. Users should review and, if necessary, modify the rule to exclude these scripts by adding them to an exception list based on their process names or paths.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the kernel module removal by checking user permissions and correlating with recent administrative activities.
+- Conduct a thorough investigation of the system logs to identify any unauthorized access or suspicious activities leading up to the module removal.
+- Utilize forensic tools to capture a snapshot of the current system state, including memory and disk images, for further analysis.
+- If unauthorized removal is confirmed, restore the affected kernel modules from a trusted backup or reinstall them using verified sources.
+- Review and update access controls and permissions to ensure only authorized personnel can modify kernel modules.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future monitoring.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.
+- Apply system hardening measures, such as disabling unnecessary kernel modules and enforcing strict module signing, to reduce the attack surface and prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_kthreadd_masquerading.toml b/rules/linux/defense_evasion_kthreadd_masquerading.toml
index 01b696e0dac..967852d22fb 100644
--- a/rules/linux/defense_evasion_kthreadd_masquerading.toml
+++ b/rules/linux/defense_evasion_kthreadd_masquerading.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,49 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
 process.name : ("kworker*", "kthread*") and process.executable != null
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Executable Masquerading as Kernel Process
+
+In Linux environments, kernel processes like kthreadd and kworker are integral to system operations and typically lack associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes that have non-empty executable fields, indicating potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and executable path, focusing on the `process.name` and `process.executable` fields to verify if they match known kernel process names like "kworker" or "kthreadd".
+- Check the process start time and correlate it with any known legitimate system activities or updates that might have occurred around the same time.
+- Use Osquery to gather more information about the suspicious process. Execute a query such as: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name LIKE 'kworker%' OR name LIKE 'kthreadd%' AND path IS NOT NULL;` to list processes with kernel-like names and non-empty paths.
+- Investigate the parent process of the suspicious executable by examining the `process.parent` field to determine if it was spawned by a legitimate process or another suspicious one.
+- Analyze the command line arguments (`process.cmdline`) used to start the process to identify any unusual or unexpected parameters that could indicate malicious activity.
+- Check the file hash of the executable using a tool like `sha256sum` and compare it against known malware databases or threat intelligence feeds to identify any known malicious signatures.
+- Review system logs around the time of the process start event for any additional context or related suspicious activities, such as unauthorized access attempts or privilege escalation.
+- Investigate the user account (`process.user`) under which the process is running to determine if it has the necessary permissions and if the account has been involved in any suspicious activities.
+- Examine network connections initiated by the process using tools like `netstat` or `ss` to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
+- Cross-reference the findings with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to gather additional context and corroborate the suspicious activity.
+
+### False positive analysis
+
+- Some legitimate software or system updates may create processes with names similar to kernel processes, leading to false positives. Users should verify the source and legitimacy of such processes before taking action.
+- Custom scripts or administrative tools that mimic kernel process names for legitimate purposes can trigger alerts. Users can create exceptions for these known scripts by whitelisting their executable paths.
+- Certain monitoring or security tools may use kernel-like process names for internal operations. Users should consult with their IT or security teams to identify these tools and exclude them from the detection rule.
+- In environments with custom kernel modules or patches, legitimate processes might be named similarly to kernel processes. Users should document these customizations and adjust the detection rule to prevent unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening processes are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to confirm the masquerading attempt by analyzing the process tree and associated executable paths.
+- Terminate any suspicious processes that are masquerading as kernel processes to halt malicious activity.
+- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Restore the system by removing any malicious executables and ensuring all system files are intact and unaltered.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_ld_so_creation.toml b/rules/linux/defense_evasion_ld_so_creation.toml
index e7cda7b8898..95957a6245d 100644
--- a/rules/linux/defense_evasion_ld_so_creation.toml
+++ b/rules/linux/defense_evasion_ld_so_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ file where host.os.type == "linux" and event.type == "creation" and process.exec
 file.path like~ ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and
 not process.name in ("dockerd", "yum", "dnf", "microdnf", "pacman")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Dynamic Linker (ld.so) Creation
+
+The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, bypassing security measures. The detection rule identifies suspicious creation of ld.so files, excluding legitimate processes, to flag potential threats and prevent system binary proxy execution abuses.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path matches the suspicious patterns ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and verify the event type is "creation".
+- Check the process that created the file by examining the `process.executable` field to determine if it is a known legitimate process or potentially malicious.
+- Investigate the `process.name` to ensure it is not one of the excluded legitimate processes such as "dockerd", "yum", "dnf", "microdnf", or "pacman".
+- Use Osquery to gather more information about the process that created the file. Example query: `SELECT * FROM processes WHERE pid = <process_id>;` where `<process_id>` is the ID of the process that triggered the alert.
+- Examine the parent process of the suspicious process to understand the process hierarchy and identify any potential anomalies or unexpected parent-child relationships.
+- Check the file metadata, including creation and modification timestamps, to determine if the timing aligns with any known legitimate activities or scheduled tasks.
+- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity is consistent with the user's typical behavior.
+- Review recent system logs and audit logs for any other suspicious activities or anomalies around the time of the file creation event.
+- Analyze network activity from the host to identify any unusual outbound connections or data transfers that may indicate malicious behavior.
+- Correlate the alert with other security events or alerts from the same host or network segment to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Routine system updates or package installations may trigger the rule as package managers like `apt`, `yum`, or `dnf` could create or update the dynamic linker as part of their operations. These processes are generally safe and can be excluded by adding them to the exception list if they are not already included.
+- Custom scripts or administrative tasks that involve rebuilding or updating system libraries might also lead to the creation of ld.so files. If these scripts are verified as safe, their associated processes can be added to the exclusion list to prevent false positives.
+- Automated configuration management tools such as Ansible, Puppet, or Chef might deploy or update ld.so files as part of their configuration tasks. Users should verify these actions and consider excluding these tools from the detection rule if they are part of regular, secure operations.
+- Development environments where developers frequently compile and test new versions of system libraries may inadvertently trigger the rule. In such cases, it is advisable to exclude specific development processes or paths that are known to be safe.
+- To manage these false positives, users can regularly review and update the exclusion list in the detection rule to include any new legitimate processes that are identified during routine operations. This helps in maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the integrity of the dynamic linker (ld.so) by comparing it with a known good version from a trusted source or backup.
+- Conduct a thorough investigation to identify the source of the malicious ld.so creation, including reviewing logs and process execution history.
+- Remove the malicious ld.so file and replace it with a legitimate version from a trusted source.
+- Perform a comprehensive scan of the system for additional signs of compromise, such as unauthorized user accounts or other modified binaries.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and file creation events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying security patches, updating software, and ensuring all security configurations are hardened.
+- Educate users and administrators on the importance of monitoring system binaries and the risks associated with unauthorized modifications."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_log_files_deleted.toml b/rules/linux/defense_evasion_log_files_deleted.toml
index 4004647cc05..6fd3f8eeed8 100644
--- a/rules/linux/defense_evasion_log_files_deleted.toml
+++ b/rules/linux/defense_evasion_log_files_deleted.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,49 @@ file where host.os.type == "linux" and event.type == "deletion" and
     ) and
     not process.name in ("gzip", "executor", "dockerd")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 System Log File Deletion
+
+System logs in Linux environments are crucial for monitoring and forensic analysis, capturing events like user logins and system errors. Adversaries may delete these logs to hide their tracks and evade detection. The detection rule identifies such deletions by monitoring specific log file paths and filtering out benign processes, thus alerting analysts to potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the specific log file path that was deleted and the timestamp of the event.
+- Check the process information associated with the deletion event, including the process ID, name, and user context, to identify any suspicious activity.
+- Use Osquery to list recent processes executed on the system that could be related to the deletion event. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
+- Investigate the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was compromised.
+- Examine other system logs for unusual activity around the time of the deletion, such as failed login attempts or unauthorized access.
+- Correlate the deletion event with any recent changes in system configuration or software installations that could explain the log file removal.
+- Check for any other alerts or indicators of compromise on the system that might suggest a broader attack or compromise.
+- Investigate network activity from the host around the time of the log deletion to identify any potential data exfiltration or command-and-control communication.
+- Review file integrity monitoring logs to determine if any other critical files were modified or deleted around the same time.
+- Consult threat intelligence sources to see if the observed behavior matches any known attack patterns or threat actor tactics.
+
+### False positive analysis
+
+- Routine system maintenance tasks or log rotation processes may trigger false positives, as these operations can involve the deletion of log files to manage disk space and ensure system performance.
+- Automated backup solutions might delete logs after archiving them, which could be misinterpreted as malicious activity.
+- Certain system updates or administrative scripts may also delete or rotate logs as part of their normal operation, leading to false alerts.
+- To manage these false positives, users can create exceptions for known benign processes involved in log management, such as logrotate or backup scripts, by adding them to the exclusion list in the detection rule.
+- Regularly review and update the exclusion list to include any new legitimate processes that are identified as part of routine system operations, ensuring that only genuine threats trigger alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
+- Conduct a thorough investigation to determine the scope of the log deletion, identifying any other compromised systems or accounts.
+- Review user activity and process execution logs to identify unauthorized access or suspicious behavior leading up to the log deletion.
+- Restore deleted log files from backups if available, to aid in the forensic investigation and maintain historical data integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to ensure critical logs are backed up regularly and stored securely, reducing the risk of future deletions.
+- Integrate additional security tools such as file integrity monitoring and endpoint detection and response (EDR) solutions to detect and alert on unauthorized file deletions.
+- Apply system hardening measures, including disabling unnecessary services, applying security patches, and enforcing least privilege access controls.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the importance of system logs and the potential impact of their deletion, promoting a culture of security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_mount_execution.toml b/rules/linux/defense_evasion_mount_execution.toml
index a4581ac9f04..8f267a1e94d 100644
--- a/rules/linux/defense_evasion_mount_execution.toml
+++ b/rules/linux/defense_evasion_mount_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,49 @@ event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and
 not process.parent.command_line like "/opt/cloudlinux/*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Hidden Process via Mount Hidepid
+
+The hidepid mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with hidepid=2, concealing their processes from system monitoring tools. The detection rule identifies such activity by monitoring for specific mount commands, excluding benign uses, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `mount` command with the `hidepid=2` option in the process arguments, as specified in the query.
+- Verify the user account associated with the `mount` command execution to determine if it aligns with expected administrative activity or if it appears suspicious.
+- Check the parent process of the `mount` command to understand the context of its execution and identify any potentially malicious parent processes.
+- Investigate the command history of the user who executed the `mount` command to identify any other suspicious activities or commands executed around the same time.
+- Use Osquery to list all current mounts and their options to verify if `/proc` is currently mounted with `hidepid=2`. Example query: `SELECT * FROM mounts WHERE path = '/proc' AND options LIKE '%hidepid=2%';`
+- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual login attempts or privilege escalation activities around the time of the alert.
+- Cross-reference the alert with any other security alerts or anomalies on the host to identify potential patterns or coordinated activities.
+- Check for any recent changes to user accounts or group memberships that might indicate unauthorized privilege escalation.
+- Review network activity logs for the host to identify any suspicious outbound connections or data exfiltration attempts that might correlate with the timing of the alert.
+- Consult with system administrators or the user associated with the alert to verify if the `hidepid=2` mount was part of a legitimate maintenance or configuration task.
+
+### False positive analysis
+
+- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons, such as enhancing user data protection on multi-user systems.
+- Cloud service providers or hosting environments might use hidepid=2 to prevent users from viewing other tenants' processes, which is a standard practice in shared environments.
+- Security tools or compliance frameworks could implement hidepid=2 as part of their hardening guidelines, leading to benign occurrences of this behavior.
+- To manage these false positives, users can create exceptions for known benign sources by excluding specific parent command lines or paths, such as "/opt/cloudlinux/*", or by whitelisting trusted administrative scripts and processes.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the presence of the hidepid=2 mount option by checking the current mount options for the /proc filesystem using the command `mount | grep /proc`.
+- If unauthorized use of hidepid=2 is confirmed, identify and terminate any suspicious processes that may be running under the hidden context.
+- Review system logs and process execution history to identify the source and timeline of the unauthorized mount command.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Restore the /proc filesystem to its default mount options by remounting it without the hidepid parameter using `mount -o remount,defaults /proc`.
+- Implement enhanced logging policies to capture detailed process execution and mount command activities for future investigations.
+- Integrate with security information and event management (SIEM) systems to automate detection and alerting of similar activities.
+- Apply system hardening measures, such as restricting mount command usage to authorized users and implementing least privilege access controls.
+- Conduct a post-incident review to update incident response plans and improve detection capabilities based on the findings from this incident."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_potential_proot_exploits.toml b/rules/linux/defense_evasion_potential_proot_exploits.toml
index d02281ab704..897f16a364a 100644
--- a/rules/linux/defense_evasion_potential_proot_exploits.toml
+++ b/rules/linux/defense_evasion_potential_proot_exploits.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,49 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
 process.parent.name == "proot"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Defense Evasion via PRoot
+
+PRoot is a tool that emulates a chroot-like environment, allowing users to run applications in a consistent environment across different Linux distributions. Adversaries exploit PRoot to bypass system defenses by running malicious payloads in a controlled environment. The detection rule identifies suspicious activity by monitoring processes initiated by PRoot, flagging potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the PRoot process by checking the `process.parent.name` field for "proot" and ensure the `event.type` is "start" with `event.action` as "exec" or "exec_event".
+- Identify the user account associated with the PRoot process by examining the `user.name` field to determine if the activity is linked to a legitimate user or a potential adversary.
+- Investigate the command line arguments used with the PRoot process by analyzing the `process.command_line` field to understand the context and purpose of the execution.
+- Check the parent process of PRoot using the `process.parent.executable` field to identify how PRoot was initiated and assess if it was launched by a legitimate or suspicious process.
+- Use Osquery to list all processes running under the PRoot environment to identify any unusual or unauthorized applications. Example query: `SELECT pid, name, path FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'proot');`
+- Examine network connections established by processes running under PRoot using Osquery to detect any suspicious outbound connections. Example query: `SELECT pid, local_address, remote_address, remote_port FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'proot'));`
+- Analyze file system changes or access patterns by processes under PRoot to identify any unauthorized data access or modifications.
+- Review system logs for any additional context or anomalies around the time the PRoot process was initiated, focusing on authentication logs and system events.
+- Correlate the PRoot activity with other security alerts or incidents to determine if it is part of a larger attack campaign or isolated event.
+- Investigate the presence of any unusual or unauthorized binaries or scripts within the PRoot environment that could indicate malicious intent.
+
+### False positive analysis
+
+- Legitimate use of PRoot by developers or system administrators for testing or development purposes can trigger false positives. Users should identify and document these activities to differentiate them from malicious use.
+- Automated scripts or tools that utilize PRoot for legitimate cross-distribution compatibility testing may also be flagged. Implementing exceptions for known scripts or tools can help reduce unnecessary alerts.
+- Security researchers or penetration testers might use PRoot in controlled environments to simulate attacks or test defenses, which could be mistaken for malicious activity. Establishing a whitelist for these activities can prevent false alarms.
+- Some containerization or virtualization solutions might employ PRoot-like functionality for legitimate purposes. Users should verify the context of such processes and consider excluding them if they are part of approved software solutions.
+- Regular audits and reviews of flagged PRoot activities can help refine detection rules and improve the accuracy of alerts by excluding benign use cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any malicious payloads or processes running within the PRoot environment and terminate them.
+- Review system logs and PRoot usage history to determine the scope of the attack and identify any additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds to correlate PRoot activity with known threat actor tactics, techniques, and procedures (TTPs) for improved detection and response.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a known good backup, ensuring all malicious artifacts are removed.
+- Apply system hardening measures, such as disabling unnecessary services, applying security patches, and enforcing least privilege access controls.
+- Educate users and administrators on the risks associated with tools like PRoot and the importance of monitoring for unusual activity.
+- Regularly review and update security policies and procedures to address emerging threats and incorporate lessons learned from the incident."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_rename_esxi_files.toml b/rules/linux/defense_evasion_rename_esxi_files.toml
index 114e0492005..599d279d028 100644
--- a/rules/linux/defense_evasion_rename_esxi_files.toml
+++ b/rules/linux/defense_evasion_rename_esxi_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,52 @@ file where host.os.type == "linux" and event.action == "rename" and
 file.Ext.original.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
 and not file.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Renaming of ESXI Files
+
+VMware ESXi files, crucial for virtual machine operations, can be targeted by adversaries aiming to disguise malicious activities. By renaming files like ".vmdk" or ".vmx", attackers may evade detection tools. The detection rule identifies such renaming events on Linux systems, flagging potential masquerading attempts by monitoring changes in file extensions, thus aiding in defense evasion detection.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file extensions involved in the renaming event, ensuring they match the specified VMware-related extensions such as ".vmdk", ".vmx", etc.
+- Verify the source and destination file names to understand the nature of the renaming and assess if the new file name appears suspicious or attempts to masquerade as a legitimate file.
+- Check the timestamp of the renaming event to determine if it coincides with any other suspicious activities or known attack timelines.
+- Investigate the user account associated with the renaming event to determine if it is a legitimate user or potentially compromised.
+- Examine the host where the renaming occurred to identify any other unusual activities or anomalies, such as unexpected processes or network connections.
+- Utilize Osquery to gather additional context about the file and system state. For example, run the following Osquery query to list recent file modifications on the host:
+  ```sql
+  SELECT * FROM file_events WHERE action = 'RENAME' AND path LIKE '%.vmdk' OR path LIKE '%.vmx' OR path LIKE '%.vmxf' OR path LIKE '%.vmsd' OR path LIKE '%.vmsn' OR path LIKE '%.vswp' OR path LIKE '%.vmss' OR path LIKE '%.nvram' OR path LIKE '%.vmem';
+  ```
+- Cross-reference the event with system logs to identify any correlated events, such as login attempts, privilege escalations, or other file operations around the same time.
+- Analyze network traffic logs from the host to detect any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
+- Check for any recent changes in system configurations or installed software that could indicate a broader compromise or persistence mechanism.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise (IOCs) related to VMware ESXi environments.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may rename VMware ESXi files during maintenance or migration activities, which can trigger the rule. To manage this, users can create exceptions for known administrative actions or specific time frames when such tasks are performed.
+- Backup operations: Automated backup processes might rename files as part of their operation, leading to false positives. Users can exclude backup-related processes or directories from the rule to reduce noise.
+- Software updates: Updates to VMware or related software might involve renaming files, which could be flagged by the rule. Users should consider excluding update processes or specific update directories to prevent unnecessary alerts.
+- Testing environments: In environments where frequent testing and development occur, file renaming might be a common practice. Users can create exceptions for specific test environments or user accounts to minimize false positives.
+- Custom scripts: Organizations may use custom scripts that rename VMware files for legitimate purposes. Identifying and excluding these scripts from the rule can help in reducing false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm the renaming event's legitimacy by reviewing logs and correlating with recent administrative activities.
+- If malicious activity is confirmed, identify and terminate any suspicious processes associated with the renamed files.
+- Restore any renamed VMware ESXi files to their original state using verified backups to ensure virtual machine integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed file operation events, including renaming actions, to improve future detection capabilities.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to identify and respond to similar threats more effectively.
+- Review and update access controls and permissions on VMware ESXi files to limit the ability to rename or modify them without proper authorization.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate and train staff on recognizing and reporting suspicious activities related to VMware ESXi files to enhance organizational awareness and readiness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_rename_esxi_index_file.toml b/rules/linux/defense_evasion_rename_esxi_index_file.toml
index c9061d947da..8e6b924a9cd 100644
--- a/rules/linux/defense_evasion_rename_esxi_index_file.toml
+++ b/rules/linux/defense_evasion_rename_esxi_index_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,51 @@ query = '''
 file where host.os.type == "linux" and event.action == "rename" and file.name : "index.html" and
 file.Ext.original.path : "/usr/lib/vmware/*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Renaming of ESXI index.html File
+
+In VMware ESXi environments, the `index.html` file is crucial for web-based management interfaces. Adversaries may rename this file to evade detection or to replace it with a malicious version, facilitating unauthorized access or data exfiltration. The detection rule identifies such renaming events by monitoring Linux systems for specific file operations within the VMware directory, flagging potential masquerading attempts.
+
+### Possible investigation steps
+
+- Verify the alert details, including the timestamp, to understand when the renaming event occurred.
+- Check the user account associated with the event to determine if it was an authorized user or a potential adversary.
+- Review the system logs around the time of the event for any additional suspicious activities or anomalies.
+- Use Osquery to list recent file modifications in the `/usr/lib/vmware/` directory to identify any other unauthorized changes:
+  ```sql
+  SELECT * FROM file WHERE path LIKE '/usr/lib/vmware/%' AND mtime > (SELECT strftime('%s', 'now') - 86400);
+  ```
+- Investigate the process that performed the renaming by correlating the event with process execution logs to identify the parent process and command line used.
+- Examine network logs for any unusual outbound connections from the host around the time of the event, which might indicate data exfiltration attempts.
+- Check for any recent privilege escalation events on the host that could have allowed an adversary to perform the renaming.
+- Review the file integrity monitoring logs to see if there are any other changes to critical files in the VMware directory.
+- Analyze the system for any signs of malware or rootkits that could have facilitated unauthorized access or file manipulation.
+- Cross-reference the event with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Routine maintenance or updates: During regular system updates or maintenance, the `index.html` file may be temporarily renamed as part of the update process. Users can handle this by creating exceptions for known maintenance windows or update scripts.
+- Customization by administrators: System administrators might rename the `index.html` file for legitimate customization purposes, such as implementing a custom login page. To manage this, users can whitelist specific administrator actions or paths where such customizations are expected.
+- Backup operations: Automated backup processes might rename the `index.html` file as part of their operation to prevent overwriting or to create versioned backups. Users can exclude these operations by identifying and allowing known backup scripts or tools.
+- Testing and development: In environments where testing or development occurs, the `index.html` file might be renamed frequently for testing purposes. Users can manage this by setting exceptions for specific development environments or user accounts involved in testing.
+
+### Response and remediation
+
+- Immediately isolate the affected ESXi host from the network to prevent further unauthorized access or data exfiltration.
+- Verify the integrity of the renamed index.html file by comparing it with a known good version to determine if it has been tampered with or replaced.
+- Conduct a thorough investigation to identify any unauthorized access or changes made to the system, focusing on recent user activities and file modifications.
+- Restore the original index.html file from a secure backup if it has been altered or replaced with a malicious version.
+- Review and update access controls and permissions for the VMware directory to ensure only authorized personnel have the ability to modify critical files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems have been compromised.
+- Implement enhanced logging and monitoring for file operations within the VMware directory to detect similar activities in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and identify potential indicators of compromise.
+- Apply security patches and updates to the ESXi host and associated management interfaces to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans, incorporating lessons learned to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_root_certificate_installation.toml b/rules/linux/defense_evasion_root_certificate_installation.toml
index 1651ad885c6..2e6c7737c52 100644
--- a/rules/linux/defense_evasion_root_certificate_installation.toml
+++ b/rules/linux/defense_evasion_root_certificate_installation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,48 @@ process.name in ("update-ca-trust", "update-ca-certificates") and not (
   (process.parent.name in ("sh", "bash", "zsh") and process.args == "-e")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Root Certificate Installation
+
+Root certificates are pivotal in establishing trust in digital communications, as they validate the authenticity of other certificates in a chain. Adversaries may exploit this by installing rogue root certificates on Linux systems, thus bypassing security warnings and facilitating undetected communication with malicious servers. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and parent process name involved in the root certificate installation attempt.
+- Verify the legitimacy of the process by checking the command line arguments and execution context, focusing on the `process.name` and `process.parent.name` fields.
+- Investigate the parent process to determine if it is a known and trusted application or script, using the `process.parent.args` field for additional context.
+- Check the user account associated with the process execution to determine if it aligns with expected behavior for root certificate installations.
+- Use Osquery to list all installed root certificates and their details to identify any recent or suspicious additions. Example query: `SELECT * FROM certificates WHERE common_name LIKE '%<suspicious_common_name>%' OR issuer LIKE '%<suspicious_issuer>%';`
+- Examine system logs for any related activities or anomalies around the time of the alert to gather more context on the event.
+- Cross-reference the alert with any recent changes or updates to the system that might explain the certificate installation.
+- Investigate network connections from the host to identify any unusual or unauthorized communication with external servers.
+- Review any recent user activity or access logs to determine if there were any unauthorized access attempts or privilege escalations.
+- Consult threat intelligence sources to check if the certificate or associated processes are linked to known malicious activities or threat actors.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve updating root certificates, such as during system updates or package installations. These processes often use "update-ca-trust" or "update-ca-certificates" but are typically initiated by trusted parent processes.
+- System administrators or automated scripts performing routine maintenance or configuration changes might also cause false positives. These activities are generally benign and can be identified by their consistent patterns or known parent processes.
+- To manage these false positives, users can create exceptions for specific parent processes or command-line arguments that are known to be safe. This can be done by adding these processes to the exclusion list in the detection rule, ensuring that only truly suspicious activities are flagged.
+- Monitoring the frequency and context of the alerts can help in distinguishing between legitimate and malicious activities. If a particular process frequently triggers the rule but is verified as safe, it can be added to the exclusion criteria to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further communication with potential malicious servers.
+- Conduct a thorough investigation to identify any unauthorized root certificates installed on the system and remove them.
+- Review system logs and process execution history to trace the origin of the unauthorized certificate installation and identify any other compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future unauthorized certificate installations are detected promptly.
+- Integrate threat intelligence feeds to correlate the incident with known threat actors or campaigns, leveraging MITRE ATT&CK framework details for context.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all unauthorized changes are removed.
+- Apply system hardening measures, such as restricting certificate installation permissions and implementing application whitelisting to prevent unauthorized software execution.
+- Conduct a security awareness training session for users and administrators to recognize and report suspicious activities related to certificate management.
+- Regularly review and update security policies and procedures to address gaps identified during the incident response and ensure robust defenses against similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
index 46d5a10dc28..cf48ddcf05f 100644
--- a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
+++ b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.16.2 for the SentinelOne Integration."
 min_stack_version = "8.16.2"
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,50 @@ query = '''
 file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event")
 and file.path : "/etc/selinux/config"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SELinux Configuration Creation or Renaming
+
+SELinux is a Linux kernel security module that enforces access control policies to protect systems from unauthorized access. Adversaries may attempt to modify or rename the SELinux configuration file to weaken these defenses, facilitating unauthorized actions. The detection rule identifies such suspicious activities by monitoring file creation or renaming events specifically targeting the SELinux configuration path, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event action is either "creation", "file_create_event", "rename", or "file_rename_event" and the file path is "/etc/selinux/config".
+- Check the timestamp of the event to determine when the SELinux configuration file was created or renamed.
+- Identify the user account and process responsible for the file creation or renaming by examining the event's user and process fields.
+- Investigate the command history of the identified user around the time of the event to find any suspicious commands using `history` or `bash_history`.
+- Use Osquery to gather more context about the process that triggered the event with a query like: `SELECT * FROM processes WHERE pid = <process_id>;`.
+- Examine the system logs, such as `/var/log/audit/audit.log` or `/var/log/secure`, for any related entries that might provide additional context or corroborate the event.
+- Check for any recent changes in user privileges or group memberships that might have allowed unauthorized access to modify SELinux configurations.
+- Investigate other recent file modifications in the `/etc/selinux/` directory to identify any additional unauthorized changes.
+- Review network logs for any unusual outbound connections from the host around the time of the event, which might indicate data exfiltration or command-and-control activity.
+- Correlate this event with other security alerts or anomalies on the same host to determine if it is part of a broader attack campaign.
+
+### False positive analysis
+
+- Routine system updates or administrative tasks may trigger the rule if SELinux configurations are updated or modified as part of legitimate maintenance activities. 
+- Automated configuration management tools like Ansible, Puppet, or Chef might modify the SELinux configuration file as part of their normal operations, leading to false positives.
+- System administrators may intentionally rename or create SELinux configuration files during troubleshooting or system hardening processes, which could be misinterpreted as suspicious activity.
+- To manage these false positives, users can create exceptions for known and trusted processes or users that regularly interact with the SELinux configuration file.
+- Implementing a whitelist of approved scripts or tools that are allowed to modify the SELinux configuration can help reduce noise from legitimate activities.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the integrity of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
+- Verify the integrity of the SELinux configuration file by comparing it with a known good backup or baseline to identify unauthorized changes.
+- Conduct a thorough investigation to determine the source and method of the modification, checking for any signs of compromise or unauthorized access.
+- Review system logs and security alerts to identify any related suspicious activities or indicators of compromise.
+- Restore the SELinux configuration file from a trusted backup if unauthorized changes are detected, and ensure SELinux is re-enabled and configured correctly.
+- Escalate the incident to the security operations team or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for SELinux-related activities to detect future unauthorized modifications promptly.
+- Integrate security tools with SIEM solutions to improve visibility and correlation of security events related to SELinux and other critical configurations.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Apply system hardening measures, such as restricting access to configuration files and enforcing least privilege principles, to reduce the risk of future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_ssl_certificate_deletion.toml b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
index 861b9a5dd90..32c0e464493 100644
--- a/rules/linux/defense_evasion_ssl_certificate_deletion.toml
+++ b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ query = '''
 file where host.os.type == "linux" and event.type == "deletion" and file.path : "/etc/ssl/certs/*" and
 file.extension in ("pem", "crt") and not process.name in ("dockerd", "pacman")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SSL Certificate Deletion
+
+SSL certificates are crucial for establishing secure communications in Linux environments, ensuring data integrity and trust. Adversaries may delete these certificates to bypass security controls, leading to potential data breaches or system compromise. The detection rule identifies suspicious deletions by monitoring specific directories and file types, excluding benign processes, thus highlighting potential malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path and extension involved in the deletion, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt".
+- Check the process name that triggered the deletion event to verify it is not one of the excluded benign processes like "dockerd" or "pacman".
+- Investigate the user account associated with the deletion event to determine if it is a legitimate user or potentially compromised.
+- Examine the process execution history on the host to identify any unusual or unauthorized processes that may have led to the certificate deletion.
+- Use Osquery to list all current SSL certificates in the "/etc/ssl/certs/" directory to assess the extent of the deletion. Example query: `SELECT * FROM file WHERE directory = '/etc/ssl/certs' AND (path LIKE '%.pem' OR path LIKE '%.crt');`
+- Analyze recent system logs for any signs of unauthorized access or other suspicious activities around the time of the certificate deletion.
+- Correlate the deletion event with any recent changes or updates in the system that might explain the certificate removal.
+- Investigate network logs to identify any unusual outbound connections that might suggest data exfiltration or communication with a command and control server.
+- Review any recent alerts or incidents on the same host to identify patterns or related activities that could indicate a broader attack.
+- Consult with system administrators or relevant personnel to verify if the certificate deletion was part of a planned maintenance or update activity.
+
+### False positive analysis
+
+- Routine system updates or maintenance tasks may trigger false positives, especially if they involve the removal or replacement of SSL certificates. Users can manage these by identifying and excluding specific update processes or maintenance scripts from the detection rule.
+- Automated certificate renewal processes, such as those used by Let's Encrypt, might delete old certificates as part of their renewal cycle. To handle this, users should identify the renewal process and add it to the list of excluded processes.
+- Custom scripts or applications that manage SSL certificates for legitimate purposes could also be flagged. Users should review these scripts and, if deemed safe, add them to the exclusion list to prevent unnecessary alerts.
+- In environments where containers are frequently created and destroyed, SSL certificates might be deleted as part of container lifecycle management. Users can exclude specific container management processes, like those related to Kubernetes or Docker, to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Verify the deletion of SSL certificates by checking the system logs and correlating with the detection rule to confirm malicious activity.
+- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls.
+- Conduct a thorough investigation to identify the source of the deletion, focusing on unauthorized access or compromised accounts.
+- Review and update access controls and permissions to ensure only authorized users and processes can modify SSL certificates.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed file access and modification events, including process and user information.
+- Integrate with security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing strong authentication mechanisms.
+- Educate users and administrators on the importance of SSL certificates and the potential impact of their unauthorized deletion."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
index 29ca78f1354..744d058aeed 100644
--- a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
+++ b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,49 @@ process.parent.name in ("screen", "tmux") and process.name like (
   "openssl", "telnet", "wget", "curl", "id"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potentially Suspicious Process Started via tmux or screen
+
+Tmux and screen are terminal multiplexers that allow users to manage multiple terminal sessions from a single window, enhancing productivity in Linux environments. However, adversaries can exploit these tools to execute commands stealthily, detaching sessions to run processes in the background. The detection rule identifies suspicious activity by monitoring for specific command executions initiated by tmux or screen, focusing on processes often associated with malicious behavior.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and parent process involved, focusing on the `process.name` and `process.parent.name` fields.
+- Check the timestamp of the event to determine when the suspicious process was started, using the `event.start` field.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior, using the `user.name` field.
+- Examine the command line arguments used in the process execution to identify any potentially malicious or unusual commands, using the `process.command_line` field.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'nmap' OR name = 'nc' OR name = 'curl';` to identify any related processes running on the system.
+- Check the network connections established by the suspicious process to identify any unusual or unauthorized connections, using the `process.network` field.
+- Review the process's parent-child relationship to understand the process hierarchy and identify any other potentially suspicious processes, using the `process.parent_pid` and `process.pid` fields.
+- Investigate the system logs for any other suspicious activities or anomalies around the time of the alert to gather additional context.
+- Analyze the file system for any new or modified files that may be associated with the suspicious process, using file integrity monitoring tools.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign.
+
+### False positive analysis
+
+- System administrators and developers often use tmux or screen to run legitimate processes in the background for maintenance or development purposes, such as running scripts or monitoring tools, which may trigger the rule.
+- Automated scripts or cron jobs that utilize tmux or screen to execute routine tasks like backups, updates, or network monitoring can be mistakenly flagged as suspicious.
+- Security tools or network diagnostic utilities that are legitimately used for troubleshooting or performance testing, such as nmap or curl, may be executed via tmux or screen, leading to false positives.
+- To manage these false positives, users can create exceptions for known benign processes by adding specific command patterns or user accounts to an allowlist, ensuring that routine administrative tasks are not flagged.
+- Implementing a review process for flagged events can help differentiate between legitimate and suspicious activities, allowing security teams to refine detection rules and reduce false positives over time.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on the processes initiated by tmux or screen and any associated suspicious commands.
+- Terminate any malicious processes identified during the investigation to stop ongoing threats.
+- Review system logs and command histories to gather evidence and understand the attack vector and timeline.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed command execution and process creation events, ensuring future suspicious activities are detected promptly.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and correlate alerts with known threat actors or tactics.
+- Restore the system to its operational state by applying patches, updating software, and ensuring all security configurations are in place.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting the use of terminal multiplexers to authorized users only and employing least privilege principles to minimize potential attack surfaces."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_unusual_preload_env_vars.toml b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
index 06cc415ae7d..2230a1f7f32 100644
--- a/rules/linux/defense_evasion_unusual_preload_env_vars.toml
+++ b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,52 @@ type = "new_terms"
 query = '''
 event.category:process and host.os.type:linux and event.type:start and event.action:exec and process.env_vars:*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Preload Environment Variable Process Execution
+
+In Linux environments, preload environment variables like `LD_PRELOAD` allow users to load shared libraries before others, altering process behavior. Adversaries exploit this by injecting malicious libraries to hijack execution flow. The detection rule identifies processes with uncommon environment variables, signaling potential misuse for defense evasion and execution hijacking.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and environment variables involved, focusing on `process.env_vars` to understand which variables are uncommon.
+- Examine the process command line (`process.command_line`) to gather more context about the executed process and its intended function.
+- Check the parent process (`process.parent.name`) to determine if the process was spawned by a legitimate or suspicious parent, which might indicate a compromise.
+- Investigate the user account (`user.name`) associated with the process execution to assess if the account is legitimate and if it has been involved in any other suspicious activities.
+- Use Osquery to list all processes with their environment variables to identify any other processes with unusual preload variables:
+  ```sql
+  SELECT pid, name, path, cmdline, environ FROM processes WHERE environ LIKE '%LD_PRELOAD%';
+  ```
+- Analyze the loaded libraries (`process.loaded_libraries`) to identify any unfamiliar or suspicious libraries that could be injected for malicious purposes.
+- Cross-reference the hash of the suspicious libraries or binaries with threat intelligence databases to check for known malicious signatures.
+- Review recent login events and user activity (`event.category:authentication`) to identify any unauthorized access attempts that might correlate with the process execution.
+- Check for any recent changes to the system's shared libraries or binaries that could indicate tampering or unauthorized modifications.
+- Investigate network connections (`network.connection`) initiated by the process to identify any suspicious outbound connections that could suggest data exfiltration or command-and-control communication.
+
+### False positive analysis
+
+- Some legitimate applications may use uncommon environment variables for performance optimization or debugging purposes, which could trigger this rule. Users should identify these applications and consider them for exclusion if they are verified as non-threatening.
+- Development environments often set unique environment variables for testing and debugging, which might be flagged by this rule. Developers should document these variables and create exceptions for known safe processes.
+- System administrators might use custom scripts that set unusual environment variables for system maintenance tasks. These should be reviewed and, if deemed safe, added to an exception list to prevent false alerts.
+- Security tools and monitoring solutions sometimes use specific environment variables to function correctly. It's important to verify these tools and exclude their processes from the rule to avoid unnecessary alerts.
+- Users can manage false positives by maintaining a whitelist of known safe environment variables and associated processes, regularly updating this list as new legitimate use cases are identified.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the malicious library or binary loaded via the `LD_PRELOAD` or other unusual environment variables.
+- Review process execution logs and environment variables to determine the scope of the compromise and identify any other affected systems.
+- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
+- Remove or quarantine the identified malicious libraries or binaries from the system to prevent re-execution.
+- Restore the system from a known good backup if the integrity of the system is in question and ensure all patches and updates are applied.
+- Implement enhanced logging policies to capture detailed process execution and environment variable changes for future investigations.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to monitor and alert on unusual process behaviors and environment variable usage.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Review and update security policies and hardening measures, such as restricting the use of environment variables like `LD_PRELOAD` to trusted users and applications only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml
index 16c7da4dec3..52a4692553b 100644
--- a/rules/linux/discovery_dynamic_linker_via_od.toml
+++ b/rules/linux/discovery_dynamic_linker_via_od.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,50 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Dynamic Linker Discovery via od
+
+The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Adversaries may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker paths, flagging potential reconnaissance activities aimed at exploiting dynamic linker mechanisms.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "od" and verify the specific arguments used, such as "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2" or other linker paths listed in the query.
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time.
+- Identify the user account associated with the process execution to determine if it aligns with expected behavior or if it might be a compromised account.
+- Investigate the parent process of "od" to understand how it was initiated and whether it was part of a legitimate workflow or a potential attack chain.
+- Use Osquery to gather additional context about the process. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'od' LIMIT 1);`
+- Examine system logs for any unusual activity or errors around the time of the alert that might indicate tampering or exploitation attempts.
+- Check for any recent changes to the dynamic linker files or related configuration files, such as "/etc/ld.so.preload", to identify unauthorized modifications.
+- Review network activity logs to detect any outbound connections or data exfiltration attempts that might coincide with the suspicious process execution.
+- Investigate other alerts or anomalies involving the same host to determine if this is part of a broader attack pattern or isolated incident.
+- Consult threat intelligence sources to see if there are any known campaigns or adversaries that use similar techniques, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- System administrators or developers may use the `od` utility to legitimately inspect dynamic linker files for debugging or system maintenance purposes, leading to false positives. 
+- Automated scripts or monitoring tools that perform regular checks on system files, including dynamic linkers, might trigger the rule unintentionally.
+- Security audits or compliance checks that involve examining system binaries and linkers could also result in false positives.
+- To manage these false positives, users can create exceptions for known benign activities by whitelisting specific user accounts or processes that regularly perform these actions.
+- Implementing a baseline of normal system behavior can help differentiate between legitimate use and potential threats, allowing for more accurate filtering of alerts.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening activities are excluded from triggering the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing logs and correlating with other security events.
+- Analyze the process tree and command-line arguments to understand the scope and intent of the suspicious `od` usage.
+- If confirmed malicious, terminate any unauthorized processes and remove any malicious files or scripts identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging for process execution and file access, focusing on critical system paths and binaries.
+- Integrate threat intelligence feeds to correlate with known indicators of compromise related to dynamic linker exploitation.
+- Restore the system to a known good state using backups or system snapshots, ensuring all patches and updates are applied.
+- Conduct a post-incident review to identify gaps in detection and response, updating security policies and procedures accordingly.
+- Implement hardening measures such as restricting access to critical system files, enforcing least privilege, and using application whitelisting."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml
index 36c72745af1..fef13f050c7 100644
--- a/rules/linux/discovery_esxi_software_via_find.toml
+++ b/rules/linux/discovery_esxi_software_via_find.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,49 @@ event.action in ("exec", "exec_event", "executed", "process_started") and proces
 process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and 
 not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 ESXI Discovery via Find
+
+VMware ESXi is a hypervisor used to manage virtual machines (VMs) on physical servers. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather intelligence or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the 'find' command was executed on a Linux system, focusing on the 'process.name' and 'process.args' fields to verify the targeted VMware paths.
+- Check the 'process.parent.executable' field to ensure the command was not initiated by a legitimate process like "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh".
+- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks.
+- Examine the 'host.os.type' and 'event.type' fields to confirm the environment and context in which the command was executed.
+- Use Osquery to list all running processes related to VMware to identify any unusual or unauthorized activities. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/usr/lib/vmware/%' OR path LIKE '/etc/vmware/%';`
+- Analyze system logs around the time of the alert to identify any other suspicious activities or commands executed by the same user or process.
+- Check for any recent changes or anomalies in the VMware configuration files located in the targeted paths to assess potential tampering or reconnaissance.
+- Investigate network logs for any unusual outbound connections from the host that might indicate data exfiltration or communication with a command and control server.
+- Review historical data to determine if similar 'find' command executions have occurred in the past, indicating a pattern or ongoing reconnaissance activity.
+- Correlate the alert with other security events or alerts from the same host or user to build a comprehensive picture of the potential threat actor's activities.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the 'find' command to perform legitimate maintenance tasks, such as searching for configuration files or performing backups, which could trigger the rule.
+- Regular updates or installations of VMware software might involve the 'find' command to verify file integrity or locate specific files, leading to false positives.
+- Monitoring or security tools that scan directories for compliance or security checks might execute the 'find' command on VMware paths as part of their routine operations.
+- To manage these false positives, users can create exceptions for known benign processes or scripts by adding their parent executable paths to the exclusion list, similar to the existing exclusion for "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh".
+- Users should regularly review and update the exclusion list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats while reducing noise from false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the activity, including reviewing logs and identifying any other systems that may have been targeted.
+- Analyze the 'find' command usage to confirm whether it was executed by a legitimate user or process, or if it indicates malicious activity.
+- If malicious activity is confirmed, remove any unauthorized accounts or processes identified during the investigation.
+- Restore the system from a known good backup to ensure that any potential malicious changes are reverted.
+- Implement enhanced logging policies to capture detailed process execution data, focusing on command-line arguments and parent-child process relationships.
+- Integrate security solutions such as SIEM or EDR to improve detection capabilities and automate alerting for suspicious activities.
+- Review and update access controls and permissions on VMware-related directories to limit exposure to unauthorized users.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of maintaining security hygiene."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml
index 515c72de4f1..6863405a28a 100644
--- a/rules/linux/discovery_esxi_software_via_grep.toml
+++ b/rules/linux/discovery_esxi_software_via_grep.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,50 @@ process.name in ("grep", "egrep", "pgrep") and
 process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and
 not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 ESXI Discovery via Grep
+
+In virtualized environments, ESXi hosts manage VM files with specific extensions. Adversaries may exploit tools like grep to locate these files, aiming to gather intelligence or manipulate VMs. The detection rule identifies suspicious grep usage targeting VM file extensions, excluding legitimate processes, to flag potential threats. This helps in early detection of unauthorized VM file access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is one of "grep", "egrep", or "pgrep" and verify the presence of VM-related file extensions in the process arguments.
+- Check the process's parent executable to ensure it is not "/usr/share/qemu/init/qemu-kvm-init", which is excluded from the rule, to rule out false positives.
+- Investigate the user account associated with the process to determine if it is a known and authorized user for accessing VM files.
+- Examine the command line history for the user to identify any other suspicious commands executed around the same time as the alert.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with VM-related arguments: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%vmdk%' OR cmdline LIKE '%vmx%' OR cmdline LIKE '%vmxf%' OR cmdline LIKE '%vmsd%' OR cmdline LIKE '%vmsn%' OR cmdline LIKE '%vswp%' OR cmdline LIKE '%vmss%' OR cmdline LIKE '%nvram%' OR cmdline LIKE '%vmem%';`
+- Analyze network activity from the host to identify any unusual connections or data transfers that may indicate exfiltration or further reconnaissance.
+- Review system logs for any other anomalies or related events that occurred before or after the alert to build a timeline of activities.
+- Check for any recent changes to VM files on the system, such as modifications or deletions, that could indicate tampering.
+- Investigate any other alerts or incidents involving the same host or user to determine if this is part of a broader attack pattern.
+- Consult with the system owner or administrator to verify if the activity was authorized or part of a legitimate maintenance task.
+
+### False positive analysis
+
+- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. These legitimate activities can trigger the detection rule, leading to false positives.
+- Backup or snapshot management processes might involve searching for VM file extensions to ensure data integrity or to verify backup completion, which can also be mistakenly flagged.
+- Developers or IT personnel conducting audits or inventory checks on virtual environments may use grep to locate VM files, resulting in non-malicious alerts.
+- To manage these false positives, users can create exceptions for known legitimate processes by excluding specific parent processes or scripts that regularly perform these actions.
+- Implementing a whitelist of trusted users or service accounts that frequently interact with VM files can help reduce unnecessary alerts.
+- Regularly review and update the exclusion list to accommodate changes in legitimate operational procedures, ensuring that only genuine threats are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the presence of unauthorized grep usage by reviewing process execution logs and correlating with other security events.
+- If unauthorized access is confirmed, identify and terminate any malicious processes running on the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Review and enhance logging policies to ensure comprehensive monitoring of process execution and file access activities, focusing on VM-related files.
+- Implement additional security controls, such as file integrity monitoring and access controls, to protect VM files from unauthorized access.
+- Restore the system to its operational state by applying the latest security patches and updates, and verifying the integrity of VM files.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate system administrators and users on recognizing and reporting suspicious activities related to VM file access.
+- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to enhance detection and response capabilities for similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_kernel_module_enumeration.toml b/rules/linux/discovery_kernel_module_enumeration.toml
index e57a6d27d55..7949a743899 100644
--- a/rules/linux/discovery_kernel_module_enumeration.toml
+++ b/rules/linux/discovery_kernel_module_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,52 @@ not (
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Enumeration of Kernel Modules
+
+Loadable Kernel Modules (LKMs) enhance a Linux kernel's capabilities dynamically, without requiring a system reboot. Adversaries may exploit this by enumerating kernel modules to gather system information or identify vulnerabilities. The detection rule identifies suspicious enumeration activities by monitoring specific processes and arguments associated with module listing, while excluding legitimate system processes to reduce false positives.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
+- Check the `event.category` and `event.type` fields to confirm the nature of the event and ensure it aligns with a process start event.
+- Investigate the `process.parent.name` to determine if the parent process is one of the excluded legitimate system processes, which might indicate a false positive.
+- Examine the user account associated with the process execution to determine if it is a privileged or unprivileged account, which can provide context on the potential risk.
+- Use Osquery to list currently loaded kernel modules and compare them with the modules listed in the alert to identify any discrepancies or unusual modules:
+  ```sql
+  SELECT * FROM kernel_modules;
+  ```
+- Analyze the system logs around the time of the alert to identify any other suspicious activities or related events that might provide additional context.
+- Check for any recent changes or updates to the system that might have triggered legitimate module enumeration, such as system updates or configuration changes.
+- Investigate the network activity of the host to identify any potential data exfiltration or communication with known malicious IP addresses.
+- Review historical data to determine if similar enumeration activities have been observed on the host or across the network, which might indicate a pattern or ongoing reconnaissance.
+- Consult threat intelligence sources to check if the specific process names or arguments used in the alert are associated with known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Legitimate system processes or administrative scripts may trigger the rule if they perform kernel module enumeration as part of routine operations, such as system updates or hardware checks.
+- Automated maintenance tasks, like those executed by configuration management tools (e.g., Ansible, Puppet, Chef), might also cause false positives if they include module listing commands.
+- Security monitoring or auditing tools that check system configurations and module statuses could inadvertently match the rule's criteria.
+- Users can manage these false positives by creating exceptions for known benign processes or scripts that frequently trigger the rule, ensuring they are added to the exclusion list in the detection logic.
+- Regularly review and update the exclusion list to accommodate new legitimate processes that may arise from system updates or changes in administrative practices.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the source and intent of the kernel module enumeration, checking for any unauthorized access or privilege escalation attempts.
+- Review system logs and security alerts to identify any other suspicious activities or anomalies that may indicate a broader compromise.
+- If malicious activity is confirmed, remove any unauthorized kernel modules and restore the system to a known good state using backups or system snapshots.
+- Update and patch the system to address any identified vulnerabilities that may have been exploited during the attack.
+- Implement enhanced logging policies to capture detailed process execution and module loading activities for future investigations.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining system security and vigilance.
+- Consider hardening measures such as disabling unnecessary kernel modules, implementing strict access controls, and using security-enhanced Linux (SELinux) or AppArmor to enforce security policies."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_linux_hping_activity.toml b/rules/linux/discovery_linux_hping_activity.toml
index ac1d28f7af0..d46985c63ec 100644
--- a/rules/linux/discovery_linux_hping_activity.toml
+++ b/rules/linux/discovery_linux_hping_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,49 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
  and process.name in ("hping", "hping2", "hping3")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Hping Process Activity
+
+Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies the initiation of Hping processes on Linux systems, flagging potential misuse by monitoring specific process events and names associated with Hping.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name matches "hping", "hping2", or "hping3" and verify the event type is "start" with actions like "exec", "exec_event", "executed", or "process_started".
+- Check the timestamp of the event to determine when the Hping process was initiated and correlate it with any other suspicious activities around the same time.
+- Identify the user account under which the Hping process was executed to assess if it aligns with expected behavior or if it indicates potential misuse.
+- Investigate the parent process of the Hping activity to understand how it was initiated and if it was spawned by a legitimate or suspicious process.
+- Examine the command-line arguments used with the Hping process to determine the specific actions it was attempting to perform, such as network scanning or probing.
+- Utilize Osquery to gather additional context about the Hping process by running a query like: `SELECT * FROM processes WHERE name IN ('hping', 'hping2', 'hping3');` to retrieve detailed process information.
+- Analyze network logs to identify any unusual outbound or inbound traffic patterns that coincide with the Hping process execution, indicating potential reconnaissance activity.
+- Cross-reference the host's recent login history and user activity to identify any unauthorized access attempts or anomalies that could be related to the Hping execution.
+- Review system logs for any error messages or warnings that occurred around the time of the Hping process start, which might provide additional context or indicators of compromise.
+- Investigate any other alerts or detections from the same host or user account to determine if the Hping activity is part of a broader attack pattern or isolated incident.
+
+### False positive analysis
+
+- Legitimate network administrators and security professionals may use Hping for authorized network testing and diagnostics, leading to false positives when these activities are part of routine security assessments or troubleshooting.
+- Automated scripts or scheduled tasks that include Hping for regular network health checks or performance monitoring can trigger alerts, even though they are non-malicious in nature.
+- To manage these false positives, users can create exceptions or exclusions in the detection rule for specific users, IP addresses, or time frames that are known to perform legitimate Hping activities.
+- Implementing a whitelist of trusted processes or users who are authorized to use Hping can help reduce unnecessary alerts while maintaining security oversight.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary activities are excluded from triggering alerts, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary.
+- Conduct a thorough investigation to determine the scope of the activity, including reviewing logs and process trees to identify any additional suspicious behavior or related processes.
+- Terminate any unauthorized Hping processes running on the system to halt any ongoing reconnaissance activities.
+- Analyze network traffic logs to identify any unusual outbound connections or data exfiltration attempts that may have occurred during the Hping activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future Hping or similar activities are detected promptly.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to improve detection capabilities for reconnaissance and discovery tactics.
+- Restore the system to its operational state by applying any necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address any deficiencies discovered during the investigation.
+- Implement system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface and mitigate the risk of future misuse of tools like Hping."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_linux_nping_activity.toml b/rules/linux/discovery_linux_nping_activity.toml
index 9e48fc76e96..df3fb9a26d9 100644
--- a/rules/linux/discovery_linux_nping_activity.toml
+++ b/rules/linux/discovery_linux_nping_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,47 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
  and process.name == "nping"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Nping Process Activity
+Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by probing network services. The detection rule identifies Nping execution on Linux systems by monitoring process initiation events, helping to flag potential misuse aligned with network discovery tactics.
+
+### Possible investigation steps
+
+- Verify the alert by checking the process initiation event details, focusing on the `process.name` field to confirm it is indeed "nping".
+- Examine the `host.os.type` field to ensure the alert pertains to a Linux system, as expected.
+- Review the `event.type` and `event.action` fields to confirm the process was started and executed, ensuring the alert is not a false positive.
+- Investigate the user account associated with the `process` to determine if the execution was authorized or expected.
+- Check the parent process of the Nping execution to understand how it was initiated and if it was part of a larger script or automated task.
+- Use Osquery to gather more context on the Nping process by running a query such as: `SELECT * FROM processes WHERE name = 'nping';` to retrieve details like process ID, user, and command line arguments.
+- Analyze the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or options that indicate reconnaissance or denial-of-service activities.
+- Review network logs and traffic patterns around the time of the Nping execution to identify any unusual or suspicious network activity that correlates with the alert.
+- Cross-reference the alert with other security events or logs to identify if there are any related activities or patterns, such as multiple reconnaissance attempts or other suspicious processes.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that commonly use Nping in their operations, providing additional context to the alert.
+
+### False positive analysis
+
+- Routine network diagnostics: System administrators may use Nping for legitimate network diagnostics and performance testing, which can trigger the detection rule. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform regular diagnostics.
+- Security testing by authorized personnel: Security teams might employ Nping as part of scheduled vulnerability assessments or penetration testing. Users can handle these false positives by excluding processes initiated by designated security team accounts or during predefined testing windows.
+- Automated scripts or tools: Some automated network management scripts or tools might incorporate Nping for monitoring purposes. Users should identify these scripts and exclude their execution paths or associated service accounts from triggering alerts.
+- Development and testing environments: In environments where network tools are frequently tested, Nping might be executed as part of development activities. Users can exclude specific development servers or environments from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks.
+- Verify the legitimacy of the Nping process by checking the user account that initiated it and cross-referencing with authorized network testing activities.
+- Conduct a thorough investigation of the system logs to identify any unauthorized access or suspicious activities preceding the Nping execution.
+- Review network traffic logs to determine if there were any unusual patterns or connections initiated by the Nping process.
+- If unauthorized use is confirmed, terminate the Nping process and any other suspicious processes running on the host.
+- Escalate the incident to the security operations team for further analysis and to determine if other systems may be affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more efficiently.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate Nping activity with known threat actor behaviors.
+- Restore the system to its operational state by applying any necessary patches, updating security configurations, and conducting a full system scan for malware.
+- Harden the system by disabling unnecessary network services, enforcing strict access controls, and regularly updating security policies to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml
index d1a1ecdcae3..1716494d177 100644
--- a/rules/linux/discovery_pam_version_discovery.toml
+++ b/rules/linux/discovery_pam_version_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,50 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name == "rpm" and process.args == "pam")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 (PAM) Version Discovery
+
+Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious activities by monitoring processes like `dpkg` or `rpm` that query PAM-related packages, indicating potential reconnaissance or tampering attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the triggering process name and arguments, specifically checking if `dpkg`, `dpkg-query`, or `rpm` were used with arguments `libpam-modules` or `pam`.
+- Verify the user account associated with the process execution to determine if it aligns with expected administrative activity or if it appears suspicious.
+- Check the process execution timeline to identify any unusual patterns or sequences of commands that might indicate reconnaissance or tampering.
+- Investigate the parent process of the alert-triggering process to understand the context of how the command was initiated.
+- Examine the command history of the user associated with the process to identify any other potentially suspicious activities or commands executed around the same time.
+- Utilize Osquery to gather more information about PAM-related files and configurations. For example, run the query: `SELECT * FROM rpm_packages WHERE name LIKE 'pam%' OR name LIKE 'libpam%';` to list installed PAM packages and their versions.
+- Cross-reference the PAM version information obtained with known vulnerabilities or advisories to assess potential risks.
+- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual authentication attempts or errors that might correlate with the alert.
+- Investigate network activity from the host to identify any connections to known malicious IPs or domains that could suggest external reconnaissance or data exfiltration.
+- Review recent changes to PAM configuration files, such as `/etc/pam.d/`, to detect unauthorized modifications or the presence of suspicious modules.
+
+### False positive analysis
+
+- Routine system updates or package management activities can trigger the rule, as legitimate processes like `dpkg` or `rpm` may query PAM-related packages during normal operations.
+- System administrators performing audits or checks on installed packages might inadvertently cause alerts when using package management tools to verify PAM versions.
+- Automated scripts or configuration management tools that regularly check for package updates or system configurations could also lead to false positives if they include commands querying PAM packages.
+- To manage these false positives, users can create exceptions for known benign activities by excluding specific user accounts or processes that are regularly involved in legitimate package management tasks.
+- Implementing a whitelist for certain scripts or automation tools that are verified and trusted can help reduce unnecessary alerts while maintaining security monitoring.
+- Regularly reviewing and updating the list of exceptions based on observed patterns and system changes can help maintain the balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the presence of malicious PAM modules by reviewing system logs and checking for unauthorized changes in PAM configuration files.
+- Use forensic tools to capture and analyze memory and disk images to identify any additional indicators of compromise or persistence mechanisms.
+- Remove any unauthorized or suspicious PAM modules and restore the original configuration from a known good backup.
+- Apply security patches and updates to the PAM software and other system components to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed authentication and process execution events for future analysis.
+- Integrate security information and event management (SIEM) systems to correlate PAM-related events with other security alerts for comprehensive threat detection.
+- Conduct a review of user accounts and authentication policies to ensure they adhere to the principle of least privilege and enforce strong password policies.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts if advanced persistent threats or sophisticated attack techniques are suspected.
+- Develop and implement a system hardening guide that includes disabling unused PAM modules, restricting access to PAM configuration files, and regularly auditing PAM-related activities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_ping_sweep_detected.toml b/rules/linux/discovery_ping_sweep_detected.toml
index 0fa247325c9..746f221f252 100644
--- a/rules/linux/discovery_ping_sweep_detected.toml
+++ b/rules/linux/discovery_ping_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,49 @@ query = '''
 event.category:process and host.os.type:linux and event.action:(exec or exec_event or executed or process_started) and
 event.type:start and process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Network Scan Executed From Host
+
+Network scanning utilities like ping, netcat, and socat are essential for diagnosing connectivity and network issues in Linux environments. However, adversaries exploit these tools to map networks stealthily, often using rapid execution to avoid detection. The detection rule identifies suspicious activity by monitoring the initiation of these processes, flagging potential misuse indicative of network reconnaissance efforts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the specific process name that triggered the alert, focusing on `process.name` to identify if it was ping, netcat, socat, or another utility.
+- Check the `event.category` and `event.action` fields to ensure the alert corresponds to a process execution event on a Linux host.
+- Investigate the `host.os.type` to confirm the operating system is Linux, as this rule is specific to Linux environments.
+- Examine the `event.type` field to verify that the process was indeed started, which aligns with the rule's focus on process initiation.
+- Use Osquery to gather more context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('ping', 'nping', 'hping', 'hping2', 'hping3', 'nc', 'ncat', 'netcat', 'socat');` to retrieve detailed information about the suspicious process.
+- Analyze the command line arguments of the process to understand the scope and intent of the network scan, which can be done by checking the `process.command_line` field.
+- Review the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
+- Check the process's parent process to identify if it was spawned by another suspicious or unauthorized process.
+- Investigate network connections established by the host around the time of the alert to identify any unusual or unauthorized network activity.
+- Correlate this event with other logs and alerts from the same host or network segment to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use tools like ping, netcat, and socat for legitimate network diagnostics and troubleshooting, which can trigger false positives. To manage this, create exceptions for known administrative activities by whitelisting specific user accounts or IP addresses associated with these tasks.
+- Automated monitoring scripts: Some environments deploy automated scripts that regularly execute network scanning utilities to ensure network health and connectivity. These scripts can be excluded by identifying their unique process names or execution patterns and adding them to an exception list.
+- Scheduled maintenance activities: During scheduled network maintenance, network scanning tools may be used to verify network configurations and connectivity. To prevent false positives, schedule exceptions during known maintenance windows or for specific maintenance-related processes.
+- Security tools: Certain security tools and intrusion detection systems may use similar utilities for legitimate network scanning and monitoring purposes. Identify these tools and exclude their processes from triggering alerts by adding them to a trusted list.
+- Development and testing environments: In environments where network scanning is part of development or testing processes, frequent execution of these utilities may occur. Implement exceptions for specific environments or subnets where such activities are expected and non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Conduct a thorough investigation of the host to identify any unauthorized access or additional malicious activities, focusing on the processes and network connections initiated by the flagged utilities.
+- Review system and network logs to trace the origin and scope of the network scan, identifying any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Remediate the affected host by removing any unauthorized tools or scripts and applying security patches to address known vulnerabilities.
+- Restore the host to its operational state by verifying the integrity of system files and configurations, and ensuring that all security controls are re-enabled.
+- Implement enhanced logging policies to capture detailed process execution and network activity, enabling better detection of similar threats in the future.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve the detection and response capabilities for network reconnaissance activities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply hardening measures such as disabling unnecessary services, enforcing least privilege access, and regularly updating security configurations to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml
index 67b82e3fda4..09a17d26acc 100644
--- a/rules/linux/discovery_private_key_password_searching_activity.toml
+++ b/rules/linux/discovery_private_key_password_searching_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,50 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
 process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Private Key Searching Activity
+
+In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key file patterns in sensitive directories, signaling potential malicious intent to locate and misuse private keys.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'find' command execution, focusing on the `process.command_line` field to identify the specific patterns and directories targeted.
+- Examine the `process.name` and `process.command_line` fields to verify if the command was executed by a legitimate user or process, or if it appears suspicious.
+- Check the `host.os.type` and `event.type` fields to ensure the alert pertains to a Linux system and corresponds to a process start event.
+- Investigate the user account associated with the `event.action` field to determine if the account has a history of legitimate access to private keys or if it might be compromised.
+- Use Osquery to list recent 'find' command executions on the host for further context. Example query: `SELECT * FROM processes WHERE name = 'find' AND cmdline LIKE '%id_%' ORDER BY start_time DESC LIMIT 10;`
+- Analyze the `process.parent` field to identify the parent process of the 'find' command, which may provide insights into how the command was initiated.
+- Review system logs and user activity around the time of the alert to identify any other suspicious behavior or commands executed by the same user.
+- Check for any recent changes or anomalies in the directories specified in the `process.command_line` field, such as `/home/`, `/etc/ssh`, and `/root/`.
+- Investigate network activity from the host to detect any potential exfiltration attempts, especially if the 'find' command was executed by an unauthorized user.
+- Correlate this alert with other security events or alerts from the same host or user to identify patterns or a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or automated scripts may legitimately use the 'find' command to locate private keys for backup or migration purposes, leading to false positives.
+- Developers working on applications that require key management might execute searches to verify key locations, which can trigger the rule.
+- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place, potentially causing false alerts.
+- To manage these false positives, users can create exceptions for known benign activities by excluding specific user accounts or scripts from triggering the rule.
+- Implementing a whitelist of trusted processes or directories can help reduce noise from legitimate key searches.
+- Regularly review and update the detection rule to align with organizational changes and reduce unnecessary alerts from routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or changes to private keys.
+- Review system logs and command history to trace the actions of the adversary and identify any additional compromised accounts or systems.
+- Change all potentially compromised private keys and associated passwords, and update any systems or services that rely on these keys for authentication.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed command-line activity and process execution, ensuring future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents.
+- Implement hardening measures such as disabling unused services, enforcing least privilege access, and regularly auditing key directories for unauthorized access attempts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_proc_maps_read.toml b/rules/linux/discovery_proc_maps_read.toml
index fa5cc29d2ef..ee7e61d8757 100644
--- a/rules/linux/discovery_proc_maps_read.toml
+++ b/rules/linux/discovery_proc_maps_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ process.name in ("cat", "grep") and process.args : "/proc/*/maps" and process.en
   "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious /proc/maps Discovery
+
+In Linux environments, the `/proc/*/maps` file reveals a process's memory layout, including segment permissions and file mappings. Adversaries exploit this to locate memory addresses for injecting malicious code or hijacking processes. The detection rule identifies suspicious reads of this file by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, signaling potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments, ensuring they match the suspicious pattern of reading `/proc/*/maps` using `cat` or `grep`.
+- Check the `process.entry_leader.name` to identify the shell environment from which the command was executed, as this can provide context on the user's activity.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Examine the parent process of the suspicious command to understand the sequence of events leading to the execution of the `/proc/*/maps` read.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;` to retrieve detailed information about the process.
+- Analyze the command history of the user associated with the shell session to identify any preceding commands that might indicate reconnaissance or preparatory actions.
+- Check for any recent logins or session initiations by the user to determine if the activity coincides with a new or unexpected session.
+- Review system logs for any other suspicious activities or anomalies around the time of the alert to identify potential related events.
+- Investigate network connections established by the process or user to detect any unusual outbound connections that might suggest data exfiltration or command-and-control activity.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack pattern or campaign.
+
+### False positive analysis
+
+- System administrators or developers may legitimately access `/proc/*/maps` for debugging or performance monitoring purposes, leading to false positives. Users can handle these by creating exceptions for known administrative scripts or tools that require such access.
+- Automated monitoring tools or security software might read `/proc/*/maps` as part of their regular operations. To manage these, users should identify and whitelist these tools to prevent unnecessary alerts.
+- Some legitimate applications may access their own memory maps for optimization or self-checking routines. Users can exclude these applications by adding them to an exception list based on their process names or specific command patterns.
+- During software development, developers might use commands like `cat` or `grep` on `/proc/*/maps` to troubleshoot or test applications. Users should consider excluding development environments or specific user accounts from triggering alerts.
+- Security audits or compliance checks might involve reading `/proc/*/maps` to verify system integrity. Users can manage these by scheduling such activities during known maintenance windows and temporarily disabling the rule or by excluding specific audit tools.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to determine the source and intent of the suspicious /proc/maps access, including reviewing logs and correlating with other security events.
+- Capture and preserve relevant forensic data, such as memory dumps and disk images, to support a detailed analysis and potential legal actions.
+- Identify and terminate any unauthorized processes or sessions that may have been initiated by the adversary.
+- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for similar attacks.
+- Review and enhance logging policies to ensure comprehensive monitoring of process executions and file access, particularly for sensitive files like /proc/maps.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of suspicious activities.
+- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for advanced threat analysis and response.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security configurations are applied.
+- Implement hardening measures, such as disabling unnecessary services, enforcing least privilege access, and using security tools like intrusion detection systems (IDS) to prevent future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_process_capabilities.toml b/rules/linux/discovery_process_capabilities.toml
index eed13b1eb86..ffb191998f8 100644
--- a/rules/linux/discovery_process_capabilities.toml
+++ b/rules/linux/discovery_process_capabilities.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,50 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name == "getcap" and process.args == "-r" and process.args == "/" and process.args_count == 3 and
 user.id != "0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Capability Enumeration
+
+In Linux environments, the `getcap` command is used to list file capabilities, which define specific privileges for executables. Adversaries may exploit this by recursively scanning the filesystem to identify and manipulate capabilities, potentially escalating privileges to root. The detection rule identifies suspicious use of `getcap` by monitoring for non-root users executing it with specific arguments, indicating potential malicious enumeration activities.
+
+### Possible investigation steps
+
+- Verify the alert details by checking the user ID associated with the `getcap` command execution to ensure it is indeed a non-root user (user.id != "0").
+- Review the process execution context by examining the parent process of `getcap` to understand how it was initiated and if it was part of a larger script or command chain.
+- Investigate the command line arguments used with `getcap` to confirm the recursive scan of the entire filesystem (`-r /`) and ensure the args_count is exactly 3.
+- Check the user's login history and session details to determine if the user was logged in at the time of the alert and if there were any unusual login patterns.
+- Use Osquery to list all capabilities set on files in the system to identify any unusual or suspicious capabilities that might have been manipulated. Example query: `SELECT * FROM file WHERE capabilities IS NOT NULL;`
+- Examine the user's shell history files (e.g., `.bash_history`) to identify any other potentially suspicious commands executed around the time of the alert.
+- Review system logs for any other unusual activities or errors that occurred around the time of the `getcap` execution, focusing on authentication logs and sudo usage.
+- Investigate any recent changes to the system's capabilities database or related configuration files to identify unauthorized modifications.
+- Cross-reference the alert with other security tools or logs to identify if there are any correlated alerts or indicators of compromise involving the same user or system.
+- Assess the user's role and permissions within the organization to determine if they have a legitimate reason to perform such enumeration and if their access level is appropriate.
+
+### False positive analysis
+
+- System administrators or security teams may intentionally use the `getcap` command with recursive options during routine audits or security assessments, leading to false positives.
+- Automated scripts or configuration management tools that verify file capabilities across the filesystem for compliance or security hardening purposes might trigger the rule.
+- Developers or DevOps personnel might execute `getcap` as part of testing or debugging processes in development environments, which could be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for specific user accounts or groups known to perform legitimate capability checks, ensuring these are well-documented and reviewed regularly.
+- Implementing a whitelist of known safe scripts or tools that use `getcap` can help reduce noise while maintaining security oversight.
+- Regularly review and update the detection rule to accommodate changes in legitimate use cases, ensuring that only suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
+- Verify the identity and permissions of the user who executed the `getcap` command to determine if the action was authorized or malicious.
+- Conduct a thorough review of the system's audit logs and process execution history to identify any unauthorized changes or suspicious activities following the `getcap` execution.
+- Check for any modifications to file capabilities and revert any unauthorized changes to prevent privilege escalation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for the `getcap` command and other capability-modifying commands to detect future unauthorized use.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection and response capabilities for similar threats.
+- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
+- Implement system hardening measures, such as restricting the use of capability-modifying commands to authorized users only and employing the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_pspy_process_monitoring_detected.toml b/rules/linux/discovery_pspy_process_monitoring_detected.toml
index a61e6a1a297..469e8de33db 100644
--- a/rules/linux/discovery_pspy_process_monitoring_detected.toml
+++ b/rules/linux/discovery_pspy_process_monitoring_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,47 @@ sequence by process.pid, host.id with maxspan=5s
    not process.name == "agentbeat"
   ] with runs=10
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Pspy Process Monitoring Detected
+
+Auditd is a powerful tool used in Linux environments to track system calls, providing insights into process activities. Adversaries exploit utilities like pspy to monitor processes without elevated privileges, seeking opportunities for privilege escalation. The detection rule identifies suspicious activity by tracking the 'openat' syscall within the /proc directory, flagging repeated access patterns indicative of pspy usage.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'openat' syscall within the /proc directory, focusing on the specific auditd data fields: `auditd.data.syscall`, `auditd.data.a0`, and `auditd.data.a2`.
+- Verify the frequency and pattern of the 'openat' syscall by examining the sequence of events for the same `process.pid` and `host.id` within the specified `maxspan=5s` to ensure it aligns with the rule's conditions.
+- Check the process name associated with the alert to confirm it is not a legitimate process like "agentbeat" that might be excluded from the rule.
+- Use Osquery to gather more information about the suspicious process. Execute a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <suspicious_pid>;` to retrieve details about the process.
+- Investigate the parent process of the suspicious process to understand its origin and whether it was spawned by a legitimate or malicious process.
+- Examine the command line arguments (`cmdline`) of the suspicious process to identify any unusual or unexpected parameters that might indicate malicious intent.
+- Review the user account associated with the process to determine if it is a standard user or a service account, which might provide insights into potential misuse or compromise.
+- Check the process's file path and hash against known good or malicious software databases to identify if it matches any known utilities or malware.
+- Analyze the network activity of the host during the time of the alert to identify any suspicious outbound connections that might correlate with the process activity.
+- Correlate the findings with other security events or logs from the same host or network segment to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Known false positives for the Potential Pspy Process Monitoring Detected rule may include legitimate system monitoring tools or scripts that frequently access the /proc directory using the openat syscall. These tools might be part of regular system administration tasks or monitoring solutions that do not pose a security threat.
+- To manage these false positives, users can create exceptions for specific processes or scripts that are known to perform benign activities. This can be done by modifying the detection rule to exclude certain process names or paths that are identified as non-threatening. For example, adding exceptions for known monitoring tools or system processes that are verified to be safe can reduce noise in the detection system.
+- Users should regularly review and update the list of exceptions to ensure that only legitimate processes are excluded, maintaining a balance between reducing false positives and not missing actual threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the presence of pspy or similar unauthorized monitoring tools by analyzing audit logs and process activity.
+- Terminate any suspicious processes identified during the investigation to halt potential malicious activities.
+- Review user accounts and permissions on the affected system to identify and remove any unauthorized access or privilege escalation paths.
+- Escalate the incident to the security operations team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process activity and syscall usage, focusing on the /proc directory and openat syscall.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by reinstalling affected software and applying the latest security patches and updates.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface and prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_security_file_access_via_common_utility.toml b/rules/linux/discovery_security_file_access_via_common_utility.toml
index 80be9768110..40e8872f9af 100644
--- a/rules/linux/discovery_security_file_access_via_common_utility.toml
+++ b/rules/linux/discovery_security_file_access_via_common_utility.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,48 @@ process.args like (
   "/home/*/.azure/azureProfile.json"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Security File Access via Common Utilities
+
+In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to extract system configuration details. The detection rule identifies such unauthorized access attempts by monitoring the execution of these utilities when they target specific security-related file paths, thus helping to thwart potential information-gathering activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific utility (e.g., `cat`, `grep`, `less`) that was executed and the exact file path targeted, as indicated by the `process.name` and `process.args` fields.
+- Check the `host.os.type` and `event.type` fields to confirm the alert pertains to a Linux system and that the event type is a process start, ensuring the context aligns with the rule's intent.
+- Investigate the user account associated with the process execution by examining the `user.name` field to determine if the access attempt was made by a legitimate user or a potential adversary.
+- Analyze the `process.parent.name` field to understand the parent process that initiated the utility, which may provide insights into whether the access was part of a larger script or automated task.
+- Use Osquery to gather additional context about the process and its execution environment. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
+- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, to identify any unusual login activities or privilege escalations around the time of the alert.
+- Check for any recent changes to the targeted files by reviewing file modification timestamps and comparing them with the alert timestamp to identify unauthorized modifications.
+- Investigate network activity from the host during the time of the alert to detect any potential data exfiltration attempts or connections to suspicious external IP addresses.
+- Correlate the alert with other security events or alerts from the same host or user to identify patterns or repeated access attempts to sensitive files.
+- Review the system's security configuration and access controls to ensure that sensitive files are adequately protected and that only authorized users have access to them.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use utilities like `cat`, `grep`, and `less` to review security configurations and logs as part of regular maintenance. These legitimate activities can trigger the rule. To manage this, users can create exceptions for specific user accounts or processes that are known to perform these tasks regularly.
+- Automated scripts: Scheduled scripts or cron jobs that perform system checks or backups might access security files using these utilities. Users should identify such scripts and exclude them from triggering alerts by specifying their process IDs or command patterns in the rule configuration.
+- Security audits: During security audits, tools may be employed to verify system configurations, which could involve accessing sensitive files. Users can temporarily disable the rule or whitelist the audit tools during the audit period to prevent false positives.
+- Development and testing environments: Developers or testers might access security files to simulate or test configurations. In such cases, users can exclude specific environments or IP ranges from the rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the unauthorized access, focusing on the processes and users involved.
+- Review system logs and security alerts to determine if any sensitive data was accessed or exfiltrated, and document findings for further analysis.
+- Change credentials and access tokens for any compromised accounts, especially those related to cloud services like AWS, GCP, and Azure.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and file access events, ensuring future unauthorized access attempts are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts with known threat actors and tactics.
+- Restore the system to its operational state by applying patches, updating security configurations, and ensuring all unauthorized changes are reverted.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting access to sensitive files, enforcing least privilege principles, and using file integrity monitoring to detect unauthorized changes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_sudo_allowed_command_enumeration.toml b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
index 29945248214..6c40f9d467f 100644
--- a/rules/linux/discovery_sudo_allowed_command_enumeration.toml
+++ b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ process.name == "sudo" and process.args == "-l" and process.args_count == 2 and
 process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
 not process.args == "dpkg"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Sudo Command Enumeration Detected
+
+The sudo command in Linux environments allows users to execute commands with elevated privileges. Attackers may exploit this by using `sudo -l` to list permissible commands, seeking privilege escalation opportunities. The detection rule identifies this activity by monitoring for the execution of `sudo -l` from common shell environments, excluding benign cases like package management, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `sudo -l` execution, focusing on the `process.name`, `process.args`, and `process.parent.name` fields to ensure the command was executed from a common shell environment.
+- Check the `host.os.type` and `event.type` fields to verify that the event occurred on a Linux system and was a process start event.
+- Investigate the user account associated with the `sudo -l` command execution to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the `process.parent.name` to understand the context in which the `sudo -l` command was executed, identifying if it was part of a script or an interactive session.
+- Use Osquery to gather additional context about the user and process. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
+- Analyze the `process.args_count` field to ensure that the command was executed with the expected number of arguments, which can help identify any anomalies or deviations from typical usage.
+- Cross-reference the `process.args` field with known benign cases, such as package management activities, to rule out false positives.
+- Investigate any other processes or network connections initiated by the same user around the time of the `sudo -l` execution to identify potential lateral movement or data exfiltration attempts.
+- Review system logs and audit logs for any additional suspicious activity or failed login attempts that may correlate with the `sudo -l` execution.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that commonly use `sudo -l` enumeration as part of their attack techniques.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may frequently use `sudo -l` to verify their own permissions or to troubleshoot user access issues. These legitimate uses can be excluded by creating exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts: Some automated scripts or monitoring tools might use `sudo -l` to check permissions as part of their normal operation. Identifying these scripts and excluding their execution paths or parent processes can help reduce false positives.
+- Package management: Although the rule already excludes `dpkg`, other package management tools or scripts might invoke `sudo -l` as part of their operations. Users can extend the exclusion list to include these specific cases by analyzing the context in which `sudo -l` is executed.
+- Development environments: Developers might use `sudo -l` in development or testing environments to ensure their applications have the necessary permissions. Excluding specific development environments or user accounts can help manage these false positives.
+- User training: Educating users about the implications of using `sudo -l` and encouraging them to limit its use to necessary situations can help reduce unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
+- Review the sudoers file to identify any unauthorized or suspicious entries that may have been added or modified.
+- Conduct a thorough investigation of the user's activity logs to determine if any unauthorized commands were executed using elevated privileges.
+- Check for any additional signs of compromise, such as unexpected new user accounts, changes in system configurations, or unusual network traffic.
+- If unauthorized changes are detected, revert the system to a known good state using backups or system snapshots.
+- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed command execution and user activity, ensuring that logs are securely stored and regularly reviewed.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze data for early detection of similar threats.
+- Apply system hardening measures, such as restricting sudo access to only necessary users, using multi-factor authentication, and regularly updating and patching the system.
+- Educate users on security best practices and the importance of reporting suspicious activities to help prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_suid_sguid_enumeration.toml b/rules/linux/discovery_suid_sguid_enumeration.toml
index 131a1e897c6..efbe1dc0e00 100644
--- a/rules/linux/discovery_suid_sguid_enumeration.toml
+++ b/rules/linux/discovery_suid_sguid_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/24"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,48 @@ process.name == "find" and process.args : "-perm" and process.args : (
   (process.args : "/usr/bin/pkexec" and process.args : "-xdev" and process.args_count == 7)
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SUID/SGUID Enumeration Detected
+
+SUID and SGID are Linux permissions that allow programs to run with elevated privileges, potentially enabling users to perform tasks they otherwise couldn't. Adversaries exploit misconfigured binaries with these permissions to escalate privileges. The detection rule identifies suspicious use of the "find" command to locate such binaries, filtering out benign cases to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the specific `process.name` and `process.args` that triggered the alert.
+- Verify the user context by checking the `user.Ext.real.id` and `group.Ext.real.id` fields to determine if the command was executed by a privileged user or group.
+- Examine the `process.args` field to identify the exact permissions being searched for, such as "/6000", "-6000", "/4000", "-4000", "/2000", "-2000", "/u=s", "-u=s", "/g=s", "-g=s", "/u=s,g=s", or "/g=s,u=s".
+- Check the `process.args_count` to see if the command includes an unusually high number of arguments, which might indicate a complex or automated script.
+- Investigate the parent process of the "find" command to determine if it was initiated by a legitimate process or a potentially malicious one.
+- Use Osquery to list all files with SUID/SGID permissions on the system for further analysis. Example query: `SELECT path, mode FROM file WHERE mode & 4000 OR mode & 2000;`
+- Cross-reference the list of SUID/SGID files with known vulnerable binaries or those that should not have elevated permissions.
+- Analyze recent system logs for any other suspicious activities or anomalies around the time the "find" command was executed.
+- Investigate the network activity of the host to identify any potential data exfiltration or communication with known malicious IPs.
+- Review historical data to determine if similar "find" command executions have occurred in the past, indicating a pattern or ongoing reconnaissance activity.
+
+### False positive analysis
+
+- System administrators or security teams may use the "find" command with SUID/SGID arguments during routine audits or security assessments, which can trigger false positives. To manage this, consider excluding these activities by identifying the specific user accounts or groups performing these tasks and adding them to an exception list.
+- Automated scripts or security tools that regularly scan for SUID/SGID binaries as part of compliance checks can also generate false positives. Users can handle these by creating exceptions for known scripts or processes, ensuring they are documented and verified as non-threatening.
+- Some legitimate software installations or updates might use the "find" command with SUID/SGID arguments to verify permissions, leading to false positives. To address this, users can exclude these processes by identifying the specific software and its associated process arguments, then adding them to an exception list.
+- In environments where custom applications are developed, developers might use the "find" command with SUID/SGID arguments during testing or debugging, resulting in false positives. Users can mitigate this by excluding known development environments or user accounts from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Conduct a thorough investigation to identify any misconfigured SUID/SGID binaries and assess if they have been exploited. Use forensic tools to analyze system logs and process execution history.
+- Remove or correct the permissions of any misconfigured SUID/SGID binaries to prevent unauthorized privilege escalation.
+- Review user accounts and privileges on the affected system to ensure no unauthorized changes have been made. Revoke any suspicious or unnecessary elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has compromised other systems.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and permission changes, ensuring future incidents can be detected more effectively.
+- Integrate security tools with SIEM solutions to automate the detection of suspicious SUID/SGID enumeration activities and alert security teams in real-time.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files and configurations.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future.
+- Educate system administrators and users on the risks associated with SUID/SGID permissions and best practices for maintaining secure configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml
index fb6c9090f08..cbce0a51505 100644
--- a/rules/linux/discovery_suspicious_memory_grep_activity.toml
+++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,48 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
 process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Memory grep Activity
+
+In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for understanding memory segments and permissions. Adversaries exploit this by using tools like `grep` to scan for specific memory areas, aiding in code injection or hijacking. The detection rule identifies such misuse by monitoring the execution of `grep` variants targeting memory-related arguments, signaling potential reconnaissance or preparatory actions for an attack.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments, ensuring they match the suspicious criteria: `grep`, `egrep`, `fgrep`, or `rgrep` with arguments like `[stack]`, `[vdso]`, or `[heap]`.
+- Check the process execution context by examining the parent process and any child processes spawned by the suspicious `grep` activity to understand the broader context of the execution.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Use Osquery to gather additional details about the process. For example, run the following query to list processes accessing `/proc/*/maps`: `SELECT pid, name, path FROM processes WHERE path LIKE '/proc/%/maps';`
+- Analyze the command history of the user associated with the suspicious process to identify any preceding commands that might indicate reconnaissance or preparatory actions.
+- Review system logs for any other unusual activities or errors around the time of the alert to identify potential correlations or patterns.
+- Check for any recent changes in system configurations or installed software that might explain the unusual `grep` activity.
+- Investigate network activity from the host to identify any suspicious outbound connections that could indicate data exfiltration or communication with a command and control server.
+- Correlate the alert with other security events or alerts from the same host or user to identify if this is part of a larger attack pattern.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar tactics, techniques, and procedures (TTPs).
+
+### False positive analysis
+
+- System administrators or developers may use `grep` to inspect memory maps for legitimate debugging or performance tuning purposes, which can trigger false positives. To manage this, users can create exceptions for specific user accounts or processes known to perform these activities regularly.
+- Automated monitoring tools or scripts that perform regular checks on system memory for health or performance metrics might also cause false positives. Users can handle these by identifying and excluding these tools from the detection rule.
+- Security software or forensic tools that analyze memory maps as part of their routine operations may be flagged. Users should whitelist these trusted applications to prevent unnecessary alerts.
+- In environments where custom applications frequently interact with memory maps for legitimate reasons, users should document these behaviors and adjust the detection rule to exclude these specific cases, ensuring that only suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the suspicious activity by reviewing logs and correlating with other security events.
+- Capture a memory dump and relevant logs for forensic analysis to understand the extent of the compromise and identify any injected code or malicious processes.
+- Terminate any unauthorized or suspicious processes identified during the investigation to prevent further malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to a known good state using backups or reinstallation, ensuring that all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_suspicious_which_command_execution.toml b/rules/linux/discovery_suspicious_which_command_execution.toml
index a85e4f32a79..dfcc1fc71b4 100644
--- a/rules/linux/discovery_suspicious_which_command_execution.toml
+++ b/rules/linux/discovery_suspicious_which_command_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,51 @@ and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g+
 process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 */
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious which Enumeration
+
+The 'which' command in Linux environments is typically used to locate the executable path of a command. Adversaries may exploit this utility to identify installed software that can aid in privilege escalation or lateral movement. The detection rule identifies unusual usage patterns, such as an excessive number of arguments, which may indicate malicious intent. It filters out benign scenarios, like specific parent processes or known safe paths, to reduce false positives.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "which" and the process.args_count is 10 or more, indicating an unusual number of arguments.
+- Check the parent process name and executable path to ensure it is not "jem" or within the specified benign paths ("/vz/root/*", "/var/lib/docker/*").
+- Examine the full command line (process.command_line) used in the suspicious "which" execution to understand the context and intent of the command.
+- Investigate the user account (user.name) associated with the process to determine if the activity aligns with their typical behavior or role.
+- Analyze the process start time (event.start) to correlate with other suspicious activities or known attack timelines.
+- Use Osquery to list all processes started by the same user around the time of the alert to identify any other potentially malicious activities:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<user.name>');
+  ```
+- Check for any network connections or file modifications made by the user or process around the time of the alert to identify lateral movement or data exfiltration attempts.
+- Review system logs for any failed or successful authentication attempts that could indicate privilege escalation efforts.
+- Investigate any recent changes to user permissions or group memberships that could facilitate unauthorized access or privilege escalation.
+- Correlate the alert with other security events or alerts from the same host or network segment to identify potential coordinated attack patterns.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate scripts or applications use the 'which' command with a high number of arguments for system checks or configuration validation. Users can handle these by identifying and excluding specific parent processes or paths that are known to be safe.
+- Frequent non-threatening behaviors can be managed by adding exceptions for specific parent processes like 'jem' or known safe paths such as those under '/vz/root/*' or '/var/lib/docker/*'.
+- If the rule is noisy, consider tuning it by excluding common command-line utilities like 'nmap', 'nc', 'ncat', 'netcat', 'nc.traditional', 'gcc', 'g++', and 'socat' when executed from standard shell environments like 'bash', 'dash', 'ash', 'sh', 'tcsh', 'csh', 'zsh', 'ksh', and 'fish'.
+- Users should regularly review and update the list of exceptions to ensure that new legitimate use cases are not flagged as suspicious, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough investigation of the process tree to identify the parent process and any child processes spawned by the suspicious 'which' command execution.
+- Review system logs and command history to determine the scope of the enumeration and identify any other suspicious activities or commands executed around the same time.
+- If malicious activity is confirmed, perform a full malware scan and remove any identified threats from the system.
+- Change all passwords and credentials that may have been exposed or compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed command execution and process creation events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all security patches and updates are applied.
+- Harden the system by disabling unnecessary services, enforcing the principle of least privilege, and regularly auditing installed software and user permissions."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_unusual_user_enumeration_via_id.toml b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
index 860c3e226b4..1c404621d83 100644
--- a/rules/linux/discovery_unusual_user_enumeration_via_id.toml
+++ b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ sequence by host.id, process.parent.entity_id with maxspan=1s
    process.name == "id" and process.args_count == 2 and 
    not (process.parent.name == "rpm" or process.parent.args : "/var/tmp/rpm-tmp*")] with runs=20
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual User Privilege Enumeration via id
+
+In Linux environments, the `id` command is used to display user identity and group memberships, crucial for privilege assessment. Adversaries exploit this by executing scripts like LinPEAS to rapidly enumerate user privileges, potentially revealing sensitive information. The detection rule identifies suspicious activity by flagging rapid, repeated `id` executions, suggesting automated enumeration attempts, thus alerting analysts to potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and process.parent.entity_id associated with the suspicious activity.
+- Check the process execution timeline to verify if the 20 "id" command executions occurred within the specified 1-second window.
+- Investigate the parent process of the "id" command using the process.parent.entity_id to determine if it is a known or legitimate process.
+- Examine the process.parent.name and process.parent.args fields to identify any unusual or unexpected parent processes that might have triggered the "id" command.
+- Use Osquery to list all processes running on the host at the time of the alert to identify any other suspicious activities. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE start_time > (SELECT datetime('now', '-1 minute'));`
+- Analyze the command-line arguments (process.args) used with the "id" command to check for any specific patterns or anomalies.
+- Review system logs and audit logs for any other unusual activities or errors around the time of the alert.
+- Investigate the user account associated with the process to determine if it has been compromised or is being misused.
+- Check for any recent changes in user privileges or group memberships on the system that could indicate privilege escalation attempts.
+- Correlate this activity with other alerts or incidents on the same host or network to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- System administration scripts or automated maintenance tasks that frequently execute the `id` command as part of their routine checks can trigger false positives. These scripts may be scheduled to run at regular intervals and are not indicative of malicious activity.
+- Monitoring tools or security solutions that perform regular checks on user privileges for compliance or auditing purposes might also execute the `id` command multiple times in quick succession, leading to false alerts.
+- Developers or system administrators testing scripts that involve user privilege checks could inadvertently cause the rule to trigger during development or debugging sessions.
+- To manage these false positives, users can create exceptions for known benign processes by excluding specific parent process names or paths that are identified as non-threatening. This can be done by updating the detection rule to ignore executions originating from trusted scripts or applications.
+- Another approach is to adjust the threshold of the rule to better fit the environment's normal behavior, such as increasing the number of allowed `id` executions or extending the time window, while ensuring it still effectively detects genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the presence of enumeration scripts like LinPEAS or LinEnum by reviewing process execution logs and command history.
+- Analyze the parent process and its origin to determine if the activity was initiated by a legitimate user or an adversary.
+- Escalate the incident to the security operations center (SOC) for further analysis and to assess the potential impact on other systems within the network.
+- Review and enhance logging policies to ensure comprehensive monitoring of command executions and user activities, focusing on privilege escalation attempts.
+- Implement additional security measures such as multi-factor authentication and least privilege access to reduce the risk of unauthorized privilege enumeration.
+- Restore the system to its operational state by removing any unauthorized scripts or tools and applying necessary security patches.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on recognizing and reporting suspicious activities to improve overall security awareness within the organization.
+- Leverage MITRE ATT&CK framework to understand the adversary's tactics and techniques, and apply relevant threat intelligence to enhance detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_virtual_machine_fingerprinting.toml b/rules/linux/discovery_virtual_machine_fingerprinting.toml
index 62990271aa5..e9c51eeaf7e 100644
--- a/rules/linux/discovery_virtual_machine_fingerprinting.toml
+++ b/rules/linux/discovery_virtual_machine_fingerprinting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -82,6 +82,50 @@ event.category:process and host.os.type:linux and event.type:(start or process_s
                 "/proc/ide/hd0/model") and
   not user.name:root
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Virtual Machine Fingerprinting
+
+Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to evade detection or tailor attacks. Adversaries exploit this by querying system files for hardware details, which can reveal if a system is virtualized. The detection rule targets non-root users accessing specific system paths indicative of VM environments, flagging potential reconnaissance activities by malware like Pupy RAT.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event category is 'process' and the host operating system type is 'linux', as specified in the query.
+- Verify the event type to ensure it matches 'start' or 'process_started', indicating a new process initiation.
+- Check the process arguments to identify which specific system path was accessed, such as "/sys/class/dmi/id/bios_version" or "/proc/scsi/scsi", to understand the nature of the fingerprinting attempt.
+- Investigate the user context by confirming the user name is not 'root', which could indicate unauthorized access attempts by a non-privileged user.
+- Correlate the alert with other recent alerts or logs to identify patterns or repeated access attempts to the same or similar system paths.
+- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE path IN ('/sys/class/dmi/id/bios_version', '/sys/class/dmi/id/product_name', '/sys/class/dmi/id/chassis_vendor', '/proc/scsi/scsi', '/proc/ide/hd0/model');`
+- Examine the parent process of the flagged process to determine if it was spawned by a known legitimate application or a suspicious one.
+- Check the process execution history for the non-root user to identify any other unusual or unauthorized activities.
+- Investigate the network activity associated with the process to detect any potential data exfiltration or communication with known malicious IP addresses.
+- Review system logs for any recent changes or anomalies that could indicate a compromise or unauthorized configuration changes related to virtualization detection.
+
+### False positive analysis
+
+- Non-malicious software or legitimate administrative scripts may access the same system paths for inventory or monitoring purposes, leading to false positives.
+- Developers or IT personnel using scripts to gather system information for troubleshooting or system management might trigger the rule.
+- Automated system management tools that check hardware details for compliance or inventory purposes could be flagged.
+- To manage these false positives, users can create exceptions for known benign processes or users by adding them to an allowlist.
+- Regularly review and update the allowlist to ensure it includes only trusted sources, minimizing the risk of overlooking genuine threats.
+- Consider implementing additional context checks, such as verifying the frequency and timing of access, to differentiate between routine operations and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the intrusion, focusing on identifying any additional compromised systems or accounts.
+- Review system logs and process execution details to understand the adversary's actions and identify any persistence mechanisms.
+- Remove any unauthorized software or malware identified during the investigation, such as Pupy RAT, and ensure all malicious processes are terminated.
+- Change passwords and credentials for any accounts that may have been compromised, especially those with elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if law enforcement notification is necessary.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and user activity, aiding in future detection and investigation efforts.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml
index 364f6df1e2d..073367e8177 100644
--- a/rules/linux/discovery_yum_dnf_plugin_detection.toml
+++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,49 @@ process.name == "grep" and process.args : "plugins*" and process.args : (
   "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Yum/DNF Plugin Status Discovery
+
+Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands like `grep` to identify active plugins, indicating potential tampering. The detection rule identifies such suspicious activity by monitoring for specific command executions that query plugin configurations, signaling possible malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `grep` command execution with arguments related to Yum/DNF plugin configurations, as specified in the detection rule.
+- Examine the process execution context, including the `process.name` and `process.args` fields, to verify if the command was executed with the intent to discover plugin status.
+- Check the `host.os.type` field to ensure the alert is relevant to a Linux system, as the rule is designed for Linux environments.
+- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Analyze the command's parent process to understand the origin of the execution and identify any suspicious parent-child process relationships.
+- Utilize Osquery to gather additional context on Yum/DNF configurations by running a query such as: `SELECT * FROM file WHERE path IN ('/etc/yum.conf', '/etc/dnf/dnf.conf');` to check for any unauthorized modifications.
+- Review system logs around the time of the alert to identify any other suspicious activities or related events that could indicate a broader attack.
+- Check for any recent changes in the `/etc/yum/pluginconf.d/` and `/etc/dnf/plugins/` directories to identify potential unauthorized plugin installations or modifications.
+- Investigate network connections from the host to determine if there are any unusual outbound connections that could suggest data exfiltration or command-and-control activity.
+- Correlate this alert with other security events or alerts from the same host to identify patterns or indicators of a larger compromise.
+
+### False positive analysis
+
+- System administrators or automated scripts may regularly use the `grep` command to check the status of Yum/DNF plugins as part of routine maintenance or compliance checks, leading to false positives.
+- Developers or IT personnel might execute similar commands during debugging or when developing custom plugins, which can trigger the detection rule.
+- To manage these false positives, users can create exceptions for specific user accounts or scripts known to perform these actions regularly, ensuring that only unexpected or unauthorized executions are flagged.
+- Implementing a whitelist of trusted processes or users that frequently interact with Yum/DNF configurations can help reduce noise from legitimate activities.
+- Monitoring the context of the command execution, such as the user account and the associated process tree, can provide additional insights to differentiate between benign and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or persistence.
+- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing system logs, particularly focusing on the execution of the `grep` command with plugin-related arguments.
+- Identify and document any unauthorized changes to YUM/DNF plugin configurations and revert them to their original state.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed command execution and configuration changes, ensuring future detection of similar activities.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities across the network.
+- Restore the system to its operational state by reinstalling or updating affected packages and ensuring all configurations are secure and verified.
+- Apply hardening measures such as restricting access to configuration files, disabling unnecessary plugins, and enforcing the principle of least privilege.
+- Conduct a post-incident review to identify gaps in detection and response capabilities, and update security policies and procedures accordingly.
+- Educate users and administrators on recognizing signs of compromise and the importance of reporting suspicious activities promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
index e07e6d73e79..6e2d7a17024 100644
--- a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
+++ b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -86,6 +86,49 @@ and (
   process.parent.executable like ("/vz/root/*", "/var/rudder/*")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential curl CVE-2023-38545 Exploitation
+
+Curl is a command-line tool used for transferring data with URLs, often employed in scripts and automation. The CVE-2023-38545 vulnerability in curl versions up to 8.3 can be exploited via a buffer overflow during SOCKS5 proxy handshakes, potentially allowing remote code execution. Adversaries might exploit this by crafting specific command-line arguments or environment variables. The detection rule identifies suspicious curl executions by monitoring for unusual command-line lengths and specific SOCKS5-related arguments, excluding known benign processes, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious curl executions, focusing on the command line arguments and environment variables related to SOCKS5 proxy usage.
+- Verify the version of curl installed on the affected system to determine if it is vulnerable (version <= 8.3). Use the command `curl --version` to check.
+- Examine the `process.command_line` field to understand the full context of the curl command executed, paying attention to any unusual or unexpected arguments.
+- Investigate the `process.parent.name` and `process.parent.executable` fields to identify the parent process that initiated the curl command, ensuring it is not a known benign process.
+- Check the `process.env_vars` field for any suspicious proxy settings, such as `http_proxy`, `HTTPS_PROXY`, or `ALL_PROXY`, that might indicate an attempt to exploit the vulnerability.
+- Use Osquery to gather additional context about the process and its environment. For example, run the following Osquery query to list all processes with their environment variables: `SELECT pid, name, path, cmdline, environ FROM processes WHERE name = 'curl';`
+- Analyze network logs to identify any unusual outbound connections or data transfers that coincide with the time of the suspicious curl execution.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
+- Review user activity logs to determine if the curl execution aligns with legitimate user actions or if it appears to be unauthorized or unexpected.
+- Consult threat intelligence sources to check for any known indicators of compromise or attack patterns associated with CVE-2023-38545 that might match the observed activity.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate administrative scripts or automation tools that use curl with SOCKS5 proxies for valid purposes, such as network testing or configuration management.
+- Processes like "cf-agent", "agent-run", "agent-check", "rudder", "agent-inventory", and "cf-execd" are already excluded as they are known to use curl in a non-threatening manner.
+- Users can handle additional false positives by identifying and excluding other benign parent processes or specific command-line patterns that are frequently observed in their environment.
+- Consider adding exceptions for specific directories or executable paths, such as "/opt/rudder/*" or "/vz/root/*", if they are known to host non-malicious curl operations.
+- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that legitimate activities are not flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities, focusing on processes involving curl and SOCKS5 proxy usage.
+- Upgrade curl to version 8.4 or later on all systems to patch the CVE-2023-38545 vulnerability and prevent future exploitation.
+- Review and update firewall and proxy configurations to restrict unauthorized SOCKS5 proxy connections.
+- Implement enhanced logging for curl executions, including capturing command-line arguments and environment variables, to improve detection capabilities.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious patterns related to curl usage.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Restore the system to its operational state by verifying the integrity of critical files and applications, and ensure all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unused services, enforcing least privilege access, and conducting regular security audits to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
index 63d52d93d78..c78c4821cbd 100644
--- a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
+++ b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/10"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,49 @@ sequence by host.id with maxspan=3s
        )
     )] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Egress Connection from Entrypoint in Container
+
+Containers use entrypoints to execute initial commands or scripts upon startup, often defined in Dockerfiles. Adversaries may exploit this by embedding malicious scripts to initiate unauthorized outbound connections, potentially breaching network boundaries. The detection rule identifies such threats by monitoring for the execution of `entrypoint.sh` followed by suspicious network activity, flagging attempts to connect to non-local IPs, which may indicate an attacker's effort to establish external communication or persistence.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name `entrypoint.sh` and verify it is associated with a container by checking `process.entry_leader.entry_meta.type`.
+- Examine the `host.id` and `process.entity_id` to identify the specific container and host involved in the alert.
+- Check the `destination.ip` in the network event to determine the external IP address the container attempted to connect to, ensuring it is not within the specified local or reserved IP ranges.
+- Investigate the `process.parent.entity_id` to trace the parent process of `entrypoint.sh` and understand the process hierarchy and potential origin of the script.
+- Use Osquery to gather more information about the container environment. For example, run the following query to list all running processes within the container: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = '<destination.ip>');`
+- Analyze the Dockerfile or container image used to deploy the container to identify any embedded scripts or commands that could be malicious.
+- Review the container's logs and any associated application logs for additional context around the time of the alert to identify any anomalous behavior or errors.
+- Check for any recent changes or deployments to the container or host that could have introduced the suspicious behavior.
+- Investigate the network traffic patterns from the host to determine if there are other unusual outbound connections or if this is an isolated incident.
+- Correlate the alert with other security events or alerts from the same host or container to identify potential patterns or related incidents.
+
+### False positive analysis
+
+- **Legitimate Software Updates**: Containers may initiate outbound connections for legitimate software updates or to download necessary dependencies. Users can handle these by identifying and excluding known update servers or IP ranges from the detection rule.
+- **Cloud Service Integrations**: Containers often connect to cloud services for integrations or data processing tasks. Users should identify these regular connections and create exceptions for specific IP addresses or domains associated with trusted cloud services.
+- **Monitoring and Logging Tools**: Some containers are designed to send logs or monitoring data to external systems. Users can manage these by excluding IPs or domains related to known logging and monitoring services.
+- **Internal Microservices Communication**: In environments where microservices communicate across different subnets, some connections might be flagged. Users should map out their internal network architecture and exclude IP ranges that are part of legitimate internal communications.
+- **Development and Testing Environments**: Containers in development or testing environments might exhibit behaviors that mimic suspicious activity. Users can exclude these environments by tagging them appropriately and adjusting the detection rule to ignore these tags.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized egress connections and potential lateral movement.
+- Conduct a thorough investigation of the container's entrypoint script to identify any malicious code or unauthorized modifications.
+- Review network logs to trace the destination of the egress connection and assess if any data exfiltration occurred.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
+- Remove any identified malicious scripts or files from the container and ensure the entrypoint script is restored to its original, secure state.
+- Apply security patches and updates to the container image and underlying host to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process and network activity within containers for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics, techniques, and procedures (TTPs).
+- Restore the container to its operational state by redeploying it from a clean, verified image.
+- Harden the container environment by enforcing least privilege access, using network segmentation, and regularly scanning for vulnerabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_file_execution_followed_by_deletion.toml b/rules/linux/execution_file_execution_followed_by_deletion.toml
index 4547501ded4..85bd242c0fa 100644
--- a/rules/linux/execution_file_execution_followed_by_deletion.toml
+++ b/rules/linux/execution_file_execution_followed_by_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,49 @@ sequence by host.id, user.id with maxspan=1m
    file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*",
      "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File Creation, Execution and Self-Deletion in Suspicious Directory
+
+In Linux environments, temporary directories like `/tmp` and `/dev/shm` are often used for legitimate file storage and execution. However, adversaries exploit these directories to create, execute, and delete malicious files quickly, evading detection. The detection rule identifies this pattern by monitoring file creation, execution, and deletion within a short timeframe, focusing on directories frequently targeted by threat actors. This approach helps in identifying and mitigating potential malware activities that attempt to conceal their presence by self-deleting after execution.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file name and path involved in the creation, execution, and deletion sequence. Pay attention to the `file.name` and `file.path` fields.
+- Check the `host.id` and `user.id` fields to determine which host and user account were involved in the suspicious activity. This can help in understanding the context and potential impact.
+- Investigate the process that executed the file by examining the `process.name` and `process.parent.name` fields. Determine if the parent process is a known shell or script interpreter.
+- Use Osquery to list recent file activities in the suspicious directories. Example query: `SELECT * FROM file_events WHERE action IN ('CREATED', 'DELETED') AND path LIKE '/tmp/%' OR path LIKE '/dev/shm/%';`
+- Correlate the timestamps of file creation, execution, and deletion to confirm the short timespan and sequence of events. This can help validate the alert.
+- Examine the network activity on the host around the time of the alert to identify any potential data exfiltration or command and control communication.
+- Check for any other alerts or logs related to the same `host.id` or `user.id` to identify if this is part of a larger attack pattern.
+- Investigate the origin of the file by checking if it was downloaded using tools like `curl`, `wget`, or similar, as indicated in the query.
+- Review the system's process tree to understand the relationship between the processes involved and identify any anomalies.
+- Analyze the system's bash history or other shell histories for the `user.id` involved to uncover any manual commands that might have led to the file's creation and execution.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger this rule, as package managers or scripts often download, execute, and clean up files in temporary directories. Users can handle these by creating exceptions for known update processes or package manager activities.
+- Automated scripts or cron jobs that perform regular maintenance tasks might also match the rule's criteria. To manage this, users can exclude specific scripts or processes that are verified as non-malicious.
+- Development or testing environments where files are frequently created, executed, and deleted as part of normal operations can lead to false positives. Users should consider excluding these environments or specific directories from monitoring if they are known to be secure.
+- Backup or synchronization tools that temporarily store files in monitored directories before moving or deleting them can be mistaken for malicious activity. Users can add exceptions for these tools by identifying their specific process names or file paths.
+- Security tools or monitoring agents that perform integrity checks or other operations in temporary directories might inadvertently trigger the rule. Users should whitelist these tools by their process names or executable paths to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the files and processes involved in the alert.
+- Capture and preserve relevant logs and artifacts for forensic analysis, including file creation, execution, and deletion events.
+- Terminate any malicious processes identified during the investigation to halt ongoing malicious activities.
+- Remove any malicious files or scripts found in the suspicious directories to prevent re-execution.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed file and process activities, especially in temporary directories.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches are up to date.
+- Harden the system by restricting write and execute permissions in temporary directories and implementing application whitelisting."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml
index 791a62e3941..aee02066a4a 100644
--- a/rules/linux/execution_interpreter_tty_upgrade.toml
+++ b/rules/linux/execution_interpreter_tty_upgrade.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
    process.args_count == 4)
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Upgrade of Non-interactive Shell
+
+In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging attempts to upgrade non-interactive sessions to interactive ones, thus alerting security teams to potential intrusions.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments match those specified in the detection rule, focusing on `stty` or `script` with the relevant arguments.
+- Check the `process.args_count` to ensure it aligns with the expected number of arguments for the detected process execution.
+- Investigate the parent process of the flagged process to understand how the shell was initiated and identify any potential malicious scripts or commands.
+- Use Osquery to list all active processes and their command-line arguments to identify any other suspicious activities. Example query: `SELECT pid, name, cmdline FROM processes WHERE name IN ('stty', 'script');`
+- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Review recent login events and authentication logs to identify any unusual or unauthorized access attempts around the time of the alert.
+- Analyze network connections from the host to identify any suspicious outbound connections that may indicate a reverse shell.
+- Check for any recent file modifications or new files in common directories used for persistence or staging, such as `/tmp` or `/var/tmp`.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
+- Investigate any other alerts or anomalies from the same timeframe to determine if this activity is part of a larger attack campaign.
+
+### False positive analysis
+
+- System administrators or legitimate users may use `stty` or `script` commands for valid purposes such as configuring terminal settings or logging terminal sessions, which can trigger the rule. 
+- Automated scripts or maintenance tasks that involve terminal manipulation might also match the rule's criteria, leading to false positives.
+- To manage these false positives, users can create exceptions for known benign processes or users by adding specific conditions to the detection rule, such as excluding certain user accounts or process paths.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the balance between security and operational needs.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on logs and alerts related to the execution of `stty` and `script` commands.
+- Terminate any unauthorized processes or sessions that have been identified as part of the attack.
+- Review and analyze system logs, including shell history and process execution logs, to understand the attacker's actions and objectives.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed command execution and process creation events for future detection and analysis.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection capabilities and contextual understanding of similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
+- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining vigilance and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml
index d629fd28e01..6fa05201c84 100644
--- a/rules/linux/execution_nc_listener_via_rlwrap.toml
+++ b/rules/linux/execution_nc_listener_via_rlwrap.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and
 process.args : "*l*" and process.args_count >= 4
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Netcat Listener Established via rlwrap
+
+Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring for rlwrap executing netcat with specific arguments, indicating a potential reverse shell setup.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of rlwrap executing netcat with the specified arguments, focusing on the process name and arguments fields.
+- Verify the user account associated with the process execution to determine if it aligns with expected behavior or if it is potentially compromised.
+- Check the parent process of rlwrap to understand how it was initiated and if it was part of a legitimate workflow or script.
+- Investigate the command-line arguments used with netcat to identify the intended target and port, which can provide insight into the potential reverse shell setup.
+- Use Osquery to list all active network connections and identify any unusual or unauthorized connections that may correlate with the netcat listener. Example query: `SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name = 'nc' OR name = 'ncat' OR name = 'netcat' OR name = 'nc.openbsd' OR name = 'socat');`
+- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that may indicate a broader attack chain.
+- Check system logs for any failed login attempts or other anomalies around the time of the alert to assess if there was an attempt to gain unauthorized access.
+- Review the system's bash history or other shell histories for the user to identify any manual commands that may have been executed leading up to the alert.
+- Investigate any file modifications or new file creations in the user's home directory or other sensitive directories that could indicate malicious activity.
+- Correlate the alert with other security events or alerts from the same host or user to determine if this is part of a larger attack pattern or isolated incident.
+
+### False positive analysis
+
+- Development and testing environments: In environments where developers or system administrators frequently use rlwrap with netcat for legitimate testing or debugging purposes, this rule may trigger false positives. Users can manage these by creating exceptions for specific user accounts or IP addresses known to be involved in such activities.
+- Automated scripts and tools: Some automated scripts or tools may use rlwrap and netcat for legitimate purposes, such as network diagnostics or performance testing. To handle these, users can exclude specific scripts or processes by identifying their unique command-line arguments or execution paths.
+- Security training exercises: In scenarios where security teams conduct training exercises or penetration testing, rlwrap and netcat might be used intentionally. Users should coordinate with security teams to whitelist these activities during specific time frames or for particular user groups.
+- System maintenance tasks: Certain system maintenance tasks might involve the use of rlwrap and netcat for remote management or troubleshooting. Users can address these false positives by setting up exceptions for maintenance windows or specific maintenance scripts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on logs and network traffic related to the execution of rlwrap and netcat.
+- Terminate any unauthorized processes associated with rlwrap and netcat to disrupt the adversary's access.
+- Review user accounts and privileges on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
+- Apply patches and updates to the operating system and any vulnerable applications to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more effectively.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to monitor for similar activities.
+- Restore the system from a known good backup to ensure the integrity of the operating environment.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks associated with tools like netcat and rlwrap, emphasizing the importance of secure configurations and monitoring."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
index 4caaf8cd36e..2c77d19224f 100644
--- a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
+++ b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,52 @@ sample by host.id, process.pid, process.name
   [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
    not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Connection from Binary with RWX Memory Region
+
+In Linux environments, the `mprotect()` system call adjusts memory permissions, potentially enabling read, write, and execute (RWX) access. Adversaries exploit this to execute malicious code in memory, often followed by network activity. The detection rule identifies such behavior by monitoring for RWX memory changes and subsequent network connections, excluding benign processes like `httpd`.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id`, `process.pid`, and `process.name` involved in the suspicious activity.
+- Verify the legitimacy of the process by checking its path and hash against known good software or malware databases.
+- Use `ps` or `top` commands to gather more information about the process, such as its parent process, command-line arguments, and current status.
+- Investigate the network connection details, including `destination.ip` and `destination.port`, to determine if the connection is to a known malicious or suspicious IP address.
+- Check the process's history of network connections to see if it has made similar connections in the past.
+- Use Osquery to gather more context about the process and its network activity. For example, run the following query to list all network connections made by the process:
+  ```sql
+  SELECT pid, local_address, local_port, remote_address, remote_port, state FROM process_open_sockets WHERE pid = <process.pid>;
+  ```
+- Examine the system logs for any other suspicious activities or anomalies around the time of the alert, such as unusual login attempts or file modifications.
+- Investigate the memory region changes by reviewing the `mprotect` syscall logs to understand why the process required RWX permissions.
+- Check for any recent changes to the system, such as software installations or updates, that might explain the behavior.
+- Consult threat intelligence sources to see if there are any known campaigns or malware that match the observed behavior.
+
+### False positive analysis
+
+- Certain legitimate applications may use `mprotect()` to change memory permissions for performance optimization or legitimate functionality, leading to false positives. Users should identify these applications and consider excluding them from the rule.
+- Development tools and environments, such as compilers or interpreters, might exhibit this behavior during normal operation. Users can create exceptions for these processes if they are verified as non-malicious.
+- Security software or monitoring tools may also trigger this rule due to their nature of scanning and analyzing memory. Users should verify these tools and exclude them if they are confirmed to be safe.
+- Some system utilities or services might temporarily use RWX memory regions for legitimate purposes. Users should monitor these utilities and exclude them if they consistently trigger false positives without any associated threat.
+- To manage false positives, users can refine the rule by adding specific process names or paths to an exclusion list, ensuring that only verified non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the process that initiated the RWX memory change and network connection, focusing on the process name, PID, and associated binaries.
+- Analyze the network traffic logs to determine the destination of the network connection and assess if any data exfiltration occurred.
+- Terminate any suspicious processes identified during the investigation to halt potential malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Restore the system to a known good state using backups or system snapshots, ensuring that any malicious changes are removed.
+- Implement enhanced logging policies to capture detailed process execution and network activity, aiding in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing strict memory protection policies, to reduce the attack surface.
+- Review and update security policies and procedures to incorporate lessons learned from the incident, ensuring better preparedness for future threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_network_event_post_compilation.toml b/rules/linux/execution_network_event_post_compilation.toml
index 366caed4d72..f81bb4c0480 100644
--- a/rules/linux/execution_network_event_post_compilation.toml
+++ b/rules/linux/execution_network_event_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,48 @@ sequence by host.id with maxspan=1m
      process.name in ("simpleX", "conftest", "ssh", "python", "ispnull", "pvtui")
    )] by process.name
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Connection via Recently Compiled Executable
+
+In Linux environments, compiling and executing programs is routine, but adversaries can exploit this by compiling malicious code to establish unauthorized network connections, such as reverse shells, to control systems remotely. The detection rule identifies this threat by monitoring a sequence of events: program compilation, file creation, execution, and suspicious network activity, flagging potential command-and-control setups.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and process.args associated with the compilation event to understand the context of the executable creation.
+- Examine the file.name of the recently created executable to determine if it matches known malicious binaries or if it appears suspicious based on naming conventions.
+- Investigate the process.name of the executed file to verify if it aligns with legitimate software or if it is an unexpected or unauthorized application.
+- Analyze the network connection details, focusing on the destination.ip to identify if the connection was attempted to a known malicious IP or an unusual external address.
+- Use Osquery to gather additional context on the host by running a query to list all processes executed by the user who initiated the compilation, such as: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');`
+- Check the process tree for the executed file to trace its parent processes and understand the sequence of events leading to its execution.
+- Correlate the timing of the compilation, file creation, and network connection events to determine if they occurred in quick succession, indicating potential malicious activity.
+- Investigate any other network connections from the same host around the time of the alert to identify additional suspicious activity or patterns.
+- Review system logs and audit logs on the host for any other anomalies or indicators of compromise that coincide with the alert.
+- Consult threat intelligence sources to check if the destination IP or any other indicators from the alert are associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Developers frequently compile and test new code, which can trigger this rule. To manage this, users can create exceptions for specific user accounts or directories commonly used for development activities.
+- Automated build systems or continuous integration pipelines may compile and execute code as part of their normal operation. Users can exclude these systems by identifying and whitelisting their specific process names or host identifiers.
+- Some legitimate applications may compile code at runtime for performance optimization or other reasons. Users should identify these applications and add them to an exception list to prevent false alerts.
+- Network monitoring tools or security applications might establish connections that appear suspicious but are benign. Users can exclude these processes by adding their names to the exception list, ensuring they are not flagged by the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the malicious executable, including reviewing recent file changes and user activity logs.
+- Terminate any suspicious processes identified during the investigation, especially those related to the compiled executable and unauthorized network connections.
+- Remove the malicious executable and any associated files from the system to prevent re-execution.
+- Review and update firewall rules to block outbound connections to known malicious IP addresses and domains.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network connection events for future investigations.
+- Integrate threat intelligence feeds to automatically update detection rules with known indicators of compromise (IOCs) related to command-and-control activities.
+- Restore the system from a known good backup to ensure all traces of the compromise are removed and the system is returned to a secure operational state.
+- Apply system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and regularly updating software to mitigate future risks."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_perl_tty_shell.toml b/rules/linux/execution_perl_tty_shell.toml
index e8399decc4a..f2e19045ca1 100644
--- a/rules/linux/execution_perl_tty_shell.toml
+++ b/rules/linux/execution_perl_tty_shell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,50 @@ query = '''
 event.category:process and host.os.type:linux and event.type:(start or process_started) and process.name:perl and
   process.args:("exec \"/bin/sh\";" or "exec \"/bin/dash\";" or "exec \"/bin/bash\";")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Interactive Terminal Spawned via Perl
+
+Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, upgrading basic shells to fully interactive ones. The detection rule identifies such activity by monitoring process events where Perl executes shell commands, signaling potential misuse for unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the specific process arguments indicating an interactive terminal spawn via Perl, such as "exec \\"/bin/sh\\";", "exec \\"/bin/dash\\";", or "exec \\"/bin/bash\\";".
+- Examine the process tree to identify the parent process of the Perl execution, which may provide insights into how the Perl script was initiated.
+- Check the user account associated with the Perl process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Investigate the source IP address and network connections associated with the host to identify any suspicious or unauthorized access attempts.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'perl' AND cmdline LIKE '%exec%';` to list all Perl processes with execution commands.
+- Analyze recent login events on the host to identify any unusual or unauthorized access that may correlate with the timing of the Perl process execution.
+- Review file modification and creation events around the time of the alert to detect any scripts or files that may have been used to execute the Perl command.
+- Check for any other alerts or anomalies on the host that may indicate a broader attack or compromise, such as other scripting or command execution alerts.
+- Investigate the environment for any signs of privilege escalation attempts or lateral movement that may have been facilitated by the interactive terminal.
+- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Routine administrative scripts: System administrators may use Perl scripts to automate tasks that involve spawning shells for legitimate purposes, such as maintenance or configuration changes. These activities can trigger the detection rule but are not malicious.
+- Development and testing environments: Developers might use Perl to test scripts that require shell access, leading to false positives. These environments often have frequent, non-threatening shell spawns.
+- Monitoring and automation tools: Some monitoring or automation tools may use Perl to execute shell commands as part of their normal operation, which can be mistaken for malicious activity.
+- To manage false positives, users can create exceptions for known benign scripts or processes by whitelisting specific script paths or process arguments that are regularly used in legitimate operations.
+- Implementing a baseline of normal activity for specific hosts or environments can help differentiate between expected and suspicious behavior, reducing the likelihood of false positives.
+- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Investigate the process tree to identify the parent process and any child processes spawned by the Perl script to understand the scope of the compromise.
+- Terminate any malicious processes identified during the investigation to halt ongoing unauthorized activities.
+- Review system logs and security alerts to determine the initial access vector and any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the affected system from a known good backup to ensure the removal of any persistent threats or backdoors.
+- Apply security patches and updates to the operating system and installed applications to mitigate known vulnerabilities.
+- Conduct a security review and harden the system by disabling unnecessary services, enforcing least privilege access, and implementing multi-factor authentication (MFA) where possible."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_potential_hack_tool_executed.toml b/rules/linux/execution_potential_hack_tool_executed.toml
index 3a34967695e..95ed4f051d6 100644
--- a/rules/linux/execution_potential_hack_tool_executed.toml
+++ b/rules/linux/execution_potential_hack_tool_executed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/22"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,52 @@ process.name in~ (
   "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Linux Hack Tool Launched
+
+In Linux environments, various tools are used for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies the execution of known hacking tools by monitoring process start events. It flags tools often used in exploitation, scanning, and enumeration, enabling analysts to investigate potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name that triggered the alert, using the `process.name` field to understand which tool was executed.
+- Check the `host.os.type` and `event.type` fields to confirm the environment and event type, ensuring the alert pertains to a Linux system and a process start event.
+- Investigate the `event.action` field to determine the exact action that was performed, such as "exec" or "process_started," to understand the context of the execution.
+- Examine the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with the same name and their parent processes:
+  ```sql
+  SELECT pid, name, path, parent, user FROM processes WHERE name = '<process_name>';
+  ```
+- Analyze the parent process of the suspicious execution to identify if it was spawned by a legitimate application or script.
+- Review system logs and audit logs around the time of the alert to identify any other suspicious activities or related events.
+- Check for any network connections initiated by the process using network monitoring tools or logs to identify potential data exfiltration or communication with command and control servers.
+- Investigate the file system for any new or modified files that could be related to the execution of the tool, focusing on directories commonly used for temporary or unauthorized files.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack or isolated incident.
+
+### False positive analysis
+
+- System administrators and security teams often use the flagged tools for legitimate purposes such as network diagnostics, vulnerability assessments, and system audits, which can trigger false positives.
+- Blue team exercises and penetration testing activities may involve the use of these tools, leading to alerts that are not indicative of malicious activity.
+- To manage these false positives, users can create exceptions for specific hosts or user accounts known to regularly use these tools for authorized activities.
+- Implementing a whitelist for certain processes or users can help reduce noise from expected and non-threatening tool usage.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the flagged process to determine if it was executed with malicious intent or as part of legitimate administrative tasks.
+- Review system logs and process execution history to identify any additional suspicious activities or related processes.
+- If malicious activity is confirmed, remove any unauthorized tools or scripts and change all potentially compromised credentials.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for alerts.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_potentially_overly_permissive_container_creation.toml b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
index d70d112d89b..0c05f74de08 100644
--- a/rules/linux/execution_potentially_overly_permissive_container_creation.toml
+++ b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,48 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:docker and
 process.args:(run and --privileged)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privileged Docker Container Creation
+
+Docker containers are lightweight, portable units that package applications and their dependencies. The `--privileged` flag grants containers extensive host access, posing security risks. Adversaries exploit this to escalate privileges or escape containers. The detection rule identifies unusual privileged container creation by monitoring specific process actions and arguments, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `--privileged` flag in the `process.args` field, indicating a privileged container creation attempt.
+- Examine the `process.name` field to ensure the process involved is indeed `docker`, confirming the context of the alert.
+- Investigate the `event.category` and `event.type` fields to verify that the event is categorized as a process start, which aligns with the creation of a new container.
+- Analyze the `event.action` field to ensure it reflects an execution action, which is critical for understanding the nature of the process activity.
+- Identify the parent process of the Docker command using the `process.parent.name` field to determine if it originates from an unusual or suspicious source.
+- Use Osquery to gather additional context about the Docker process. For example, run the query: `SELECT * FROM processes WHERE name = 'docker';` to retrieve detailed information about the Docker process and its attributes.
+- Check the user context under which the Docker process was executed by examining the `user.name` field to assess if it aligns with expected administrative activities.
+- Investigate the timeline of events leading up to the alert by reviewing related logs and events to identify any preceding suspicious activities.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack pattern or isolated incident.
+- Document findings and gather evidence, including logs and process details, to support further analysis and potential escalation to the incident response team.
+
+### False positive analysis
+
+- Known false positives for the Privileged Docker Container Creation rule may include legitimate administrative tasks where privileged containers are intentionally created for maintenance or testing purposes. These activities might be performed by system administrators or developers who require elevated access for specific operations.
+- To manage these false positives, users can create exceptions for known and trusted parent processes or specific user accounts that regularly perform these actions. This can be done by updating the detection rule to exclude certain process parent names or user identifiers that are recognized as non-threatening.
+- Another approach is to implement a whitelist of specific container images or commands that are known to be safe and necessary for regular operations. This helps in reducing noise from expected and benign privileged container creations.
+- Regularly reviewing and updating the list of exceptions is crucial to ensure that new legitimate use cases are accounted for while maintaining security against potential threats.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the network.
+- Investigate the parent process that initiated the privileged container creation to determine if it was a legitimate action or part of a malicious activity.
+- Review logs and process histories to identify any other suspicious activities or commands executed around the time of the alert.
+- If malicious activity is confirmed, terminate the unauthorized container and any associated processes to halt the attack.
+- Escalate the incident to the security operations team for a deeper forensic analysis and to assess the scope of the compromise.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate with SIEM solutions to correlate events and improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by redeploying clean container images and ensuring no residual malicious artifacts remain.
+- Apply security hardening measures such as restricting the use of the --privileged flag and enforcing least privilege principles for container operations.
+- Educate and train staff on secure container management practices and the risks associated with privileged container operations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_process_started_in_shared_memory_directory.toml b/rules/linux/execution_process_started_in_shared_memory_directory.toml
index f3f896a29d3..9069976d6bb 100644
--- a/rules/linux/execution_process_started_in_shared_memory_directory.toml
+++ b/rules/linux/execution_process_started_in_shared_memory_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,48 @@ user.id == "0" and process.executable : ("/dev/shm/*", "/run/shm/*", "/var/run/*
 not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", 
 "/var/run/argo/argoexec") and not process.parent.command_line : "/usr/bin/runc init"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Binary Executed from Shared Memory Directory
+
+Shared memory directories in Linux, such as /dev/shm and /run/shm, are used for inter-process communication, allowing processes to exchange data efficiently. Adversaries exploit these directories by placing executables there, leveraging their high uptime for persistence. The detection rule identifies abnormal execution by the root user in these directories, excluding known benign processes, to flag potential backdoor activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the execution of a binary from a shared memory directory by the root user, focusing on the `process.executable` field to identify the exact path and binary executed.
+- Check the `event.timestamp` to determine when the execution occurred and correlate it with any other suspicious activities or alerts around the same time.
+- Investigate the `process.parent.command_line` to understand the parent process that initiated the execution, which might provide insights into how the binary was executed.
+- Use Osquery to list all files in the shared memory directories to identify any other suspicious binaries or scripts: `SELECT * FROM file WHERE path LIKE '/dev/shm/%' OR path LIKE '/run/shm/%' OR path LIKE '/var/run/%' OR path LIKE '/var/lock/%';`
+- Examine the `user.id` field to confirm the execution was indeed by the root user and check for any unauthorized privilege escalation activities.
+- Analyze the `process.command_line` to gather more context about the executed command and its arguments, which might reveal the intent or functionality of the binary.
+- Cross-reference the `host.os.type` and `event.type` fields to ensure the alert pertains to a Linux system and involves a process start event, confirming the relevance of the alert.
+- Investigate the system logs around the time of the alert for any anomalies or related events, such as unauthorized access attempts or configuration changes.
+- Check for any network connections initiated by the suspicious process using Osquery: `SELECT * FROM process_open_sockets WHERE pid = <suspicious_process_id>;`
+- Review historical data for any previous alerts or activities involving the same `process.executable` or similar patterns to identify potential persistence mechanisms or repeated attack attempts.
+
+### False positive analysis
+
+- Known false positives for the Binary Executed from Shared Memory Directory rule include legitimate processes that are executed by root in shared memory directories for operational purposes. These can include container management tools like Docker, which may use these directories for temporary storage and execution.
+- To manage these false positives, users can create exceptions for specific processes that are known to be benign. This can be done by adding exclusions for process executables that are frequently observed and verified as non-threatening, such as those related to Docker or other container orchestration tools.
+- Users should regularly review and update the list of excluded processes to ensure that only legitimate activities are excluded, minimizing the risk of overlooking potential threats.
+- It is important to maintain a balance between reducing noise from false positives and ensuring that potentially malicious activities are not ignored. This can be achieved by closely monitoring the behavior of excluded processes and adjusting the detection rule as necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the executed binary and its origin, examining logs and process trees for any related suspicious activity.
+- Terminate any malicious processes identified during the investigation to halt ongoing threats.
+- Remove the malicious binary from the shared memory directory and any other locations it may have been copied to.
+- Review and analyze system logs, including authentication and access logs, to identify potential unauthorized access or privilege escalation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
+- Harden the system by implementing least privilege access controls, disabling unnecessary services, and regularly auditing shared memory directories for unauthorized executables."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml
index 04af725fae9..65d37b76682 100644
--- a/rules/linux/execution_python_tty_shell.toml
+++ b/rules/linux/execution_python_tty_shell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,53 @@ process where host.os.type == "linux" and event.type == "start" and event.action
    "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1)
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Interactive Terminal Spawned via Python
+
+Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns shell environments, focusing on specific patterns in process arguments and parent-child relationships indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a Python process spawning a shell, focusing on the `process.parent.name` and `process.name` fields to verify the parent-child relationship.
+- Examine the `process.parent.args` field to identify the specific command used, looking for patterns like `*pty.spawn*` and `-c` that indicate an attempt to spawn an interactive terminal.
+- Check the `process.args` field for any suspicious shell commands that might have been executed, especially if the `args_count` is minimal, suggesting a direct shell invocation.
+- Investigate the `host.os.type` to ensure the alert is relevant to a Linux environment, as the rule is specifically designed for Linux systems.
+- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes spawned by Python that match the suspicious criteria:
+  ```sql
+  SELECT pid, name, cmdline, parent FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name LIKE 'python%') AND name IN ('bash', 'dash', 'ash', 'sh', 'tcsh', 'csh', 'zsh', 'ksh', 'fish');
+  ```
+- Analyze the `event.type` and `event.action` fields to confirm that the process was indeed started and executed, which aligns with the rule's focus on process initiation.
+- Correlate the alert with any recent network activity logs to identify potential reverse shell connections or data exfiltration attempts.
+- Review user activity logs to determine if the Python process was initiated by a legitimate user or if it might be indicative of compromised credentials.
+- Check for any recent changes in user privileges or group memberships that could have facilitated the execution of such commands.
+- Investigate any other alerts or anomalies on the host around the same timeframe to identify potential lateral movement or further exploitation attempts.
+
+### False positive analysis
+
+- System administrators and developers often use Python scripts to automate tasks that require spawning shell environments, which can trigger this detection rule. These activities are typically benign and part of routine operations.
+- Automated deployment tools and configuration management systems like Ansible or Puppet may execute Python scripts that spawn shells as part of their normal operation, leading to false positives.
+- Security tools and monitoring solutions might use Python scripts to perform checks or gather system information, inadvertently matching the detection criteria.
+- To manage these false positives, users can create exceptions for known scripts or processes by whitelisting specific parent process names or arguments that are verified as non-threatening.
+- Implementing a baseline of normal behavior for Python processes in the environment can help distinguish between legitimate and suspicious activity, allowing for more accurate tuning of the detection rule.
+- Regularly reviewing and updating the list of exceptions based on changes in administrative practices or tool usage can help maintain the effectiveness of the detection rule while minimizing false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm the presence of a reverse shell and identify any additional compromised systems or accounts.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving Python spawning shell environments.
+- Review and analyze logs from the affected system and network devices to trace the attacker's actions and entry point.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on command and scripting interpreter usage.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Harden the environment by implementing least privilege access controls, disabling unnecessary services, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml
index afa9c6bdc47..77c579f97b6 100644
--- a/rules/linux/execution_python_webserver_spawned.toml
+++ b/rules/linux/execution_python_webserver_spawned.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,53 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Web Server Spawned via Python
+
+Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this by launching servers to exfiltrate data or facilitate lateral movement. The detection rule identifies such activity by monitoring process executions on Linux systems, specifically looking for Python or shell commands initiating HTTP servers, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments, ensuring they match the criteria for spawning a web server via Python.
+- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Investigate the parent process of the Python or shell command to understand how the web server was initiated and if it was part of a larger script or command sequence.
+- Examine the network connections on the host to identify any unusual outbound connections that could indicate data exfiltration.
+- Use Osquery to list all active network listeners on the host to verify if the Python web server is currently running:
+  ```sql
+  SELECT pid, name, port, address FROM listening_ports WHERE pid IN (SELECT pid FROM processes WHERE name LIKE 'python%');
+  ```
+- Analyze the command line arguments of the process to determine the specific directory being served, which could provide insight into the data being accessed or shared.
+- Review system logs for any recent login attempts or changes in user permissions that could suggest unauthorized access.
+- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or related activities.
+- Investigate any recent file modifications or creations in the directory being served by the web server to identify potential data staging or tampering.
+- Check for any scheduled tasks or cron jobs that might have been set up to automate the execution of the Python web server, indicating a persistent threat.
+
+### False positive analysis
+
+- Development and testing environments often use Python's built-in HTTP server for legitimate purposes, such as serving static files or testing web applications, which can trigger false positives.
+- System administrators or developers may use Python's HTTP server for quick file sharing within a secure network, leading to benign alerts.
+- Automated scripts or CI/CD pipelines might spawn temporary web servers for testing purposes, which could be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for known development or testing environments by excluding specific hostnames or IP addresses from the detection rule.
+- Users can also whitelist certain user accounts or process execution paths that are known to frequently and legitimately use Python's HTTP server.
+- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration or lateral movement.
+- Investigate the process execution details, including the user account that initiated the server, to determine if it was authorized or malicious.
+- Review system logs and network traffic to identify any data that may have been exfiltrated or any other systems that may have been accessed.
+- Terminate the unauthorized Python web server process to stop any ongoing malicious activity.
+- Conduct a thorough scan of the system for any additional malicious scripts or tools that may have been deployed by the attacker.
+- Reset credentials and review permissions for the user account involved to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_remote_code_execution_via_postgresql.toml b/rules/linux/execution_remote_code_execution_via_postgresql.toml
index 67ad46d0a1e..a1e129687a5 100644
--- a/rules/linux/execution_remote_code_execution_via_postgresql.toml
+++ b/rules/linux/execution_remote_code_execution_via_postgresql.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,49 @@ event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "p
   process.parent.command_line like "*BECOME-SUCCESS-*"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Code Execution via Postgresql
+
+PostgreSQL, a robust open-source database system, is often targeted by attackers seeking to execute arbitrary code. Adversaries exploit vulnerabilities like SQL injection or gain unauthorized access to execute shell commands, potentially leading to system compromise. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions with specific patterns, while excluding legitimate operations, to flag potential malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the triggering conditions, focusing on the `user.name` field to ensure the process was initiated by the "postgres" user.
+- Examine the `process.parent.args` and `process.args` fields to identify the specific shell commands executed, looking for patterns that match "*sh" and "echo*".
+- Check the `process.parent.name` and `process.command_line` fields to rule out any false positives by verifying that the process is not associated with known legitimate operations like "puppet" or commands containing "BECOME-SUCCESS".
+- Investigate the `event.type` and `event.action` fields to understand the nature of the process start event, ensuring it aligns with suspicious activities such as "exec" or "fork".
+- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE name = 'sh' AND uid = (SELECT uid FROM users WHERE username = 'postgres');` to identify any other related processes initiated by the postgres user.
+- Analyze the network activity associated with the PostgreSQL server during the time of the alert to identify any unusual connections or data transfers.
+- Review the PostgreSQL logs for any signs of unauthorized access or SQL injection attempts that could have led to the execution of arbitrary code.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns.
+- Investigate the system's history for any recent changes or updates that could have introduced vulnerabilities or been exploited by attackers.
+- Consult threat intelligence sources to determine if there are any known exploits or attack patterns targeting PostgreSQL that match the observed behavior.
+
+### False positive analysis
+
+- Legitimate administrative scripts: Routine maintenance or administrative scripts executed by the PostgreSQL user might match the rule's criteria, especially if they involve shell commands for database management or system updates. Users can handle these by identifying and excluding specific scripts or command patterns that are known to be safe.
+- Automation tools: Tools like Puppet, Ansible, or other configuration management systems may execute shell commands as part of their normal operations. These can be excluded by adding exceptions for known automation tool processes or command lines.
+- Backup and monitoring processes: Scheduled backup scripts or monitoring tools that interact with the PostgreSQL database might trigger the rule. Users should review these processes and exclude them if they are verified to be non-threatening.
+- Custom user scripts: Organizations may have custom scripts developed for specific tasks that inadvertently match the rule's criteria. These should be reviewed, and if deemed safe, added to the exclusion list to prevent false positives.
+- Development and testing environments: In environments where developers frequently test new scripts or commands, the rule might generate false positives. Users can manage this by creating separate rules or exceptions for development and testing environments to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and method of the attack, focusing on logs and any suspicious activity around the time of the alert.
+- Review PostgreSQL logs and system logs for any unauthorized access attempts or anomalies that align with the MITRE ATT&CK T1059 technique.
+- If unauthorized access is confirmed, reset credentials for the PostgreSQL user and any other potentially compromised accounts.
+- Apply the latest security patches and updates to PostgreSQL and the underlying operating system to mitigate known vulnerabilities.
+- Implement enhanced logging and monitoring for PostgreSQL activities, ensuring that all command executions and access attempts are logged and reviewed regularly.
+- Integrate security tools such as intrusion detection systems (IDS) and security information and event management (SIEM) solutions to improve threat detection capabilities.
+- Develop and enforce a strict access control policy, limiting PostgreSQL access to only necessary users and services.
+- Conduct a post-incident review to identify gaps in security posture and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to potential security threats, emphasizing the importance of maintaining a secure database environment."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml
index 4052b35ac31..ff7c420b270 100644
--- a/rules/linux/execution_shell_openssl_client_or_server.toml
+++ b/rules/linux/execution_shell_openssl_client_or_server.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,48 @@ process.name == "openssl" and (
 ) and
 not process.parent.executable in ("/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Openssl Client or Server Activity
+
+OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to establish encrypted connections. Adversaries may exploit OpenSSL to create secure channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting client or server activities that deviate from typical operations, while excluding known benign processes.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific process execution that triggered the rule, focusing on the `process.name`, `process.args`, and `process.parent.executable` fields.
+- Verify the legitimacy of the `openssl` process by checking the `process.parent.executable` to determine if it originates from a known benign source or a suspicious one.
+- Examine the `process.args` to identify whether the `openssl` command is being used as a client (`s_client`) or server (`s_server`) and note any unusual arguments or patterns.
+- Investigate the network connections associated with the `openssl` process using tools like `netstat` or `ss` to identify any suspicious remote IP addresses or ports.
+- Use Osquery to gather additional context about the `openssl` process. For example, run the following query to list all processes with their network connections: `SELECT pid, name, path, cmdline, remote_address, remote_port FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE name = 'openssl';`
+- Check system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any related authentication attempts or anomalies around the time the `openssl` process was executed.
+- Review user activity logs to determine if the `openssl` process was initiated by a legitimate user or if there are signs of compromised credentials.
+- Investigate any file transfers or data exfiltration attempts by examining file access logs and monitoring tools for unusual data movement.
+- Correlate the `openssl` activity with other security alerts or logs to identify potential patterns or coordinated actions indicative of a larger attack.
+- Consult threat intelligence sources to determine if the IP addresses or domains associated with the `openssl` connections are known to be malicious or part of a threat actor's infrastructure.
+
+### False positive analysis
+
+- Known false positives for the Openssl Client or Server Activity rule may include legitimate administrative tasks where OpenSSL is used for secure communications, such as system administrators testing SSL/TLS connections or setting up secure servers for internal use.
+- Automated scripts or monitoring tools that use OpenSSL for regular checks, such as certificate validation or network diagnostics, can trigger this rule. These processes often have predictable patterns and can be excluded by identifying their parent processes or specific command-line arguments.
+- To manage these false positives, users can create exceptions by adding known benign parent processes to the exclusion list, as seen with "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" in the rule. This helps in reducing noise and focusing on truly suspicious activities.
+- Regularly review and update the exclusion list to accommodate new legitimate processes that may arise in the environment, ensuring that the detection rule remains effective without generating excessive false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized connections established using OpenSSL.
+- Review system logs and network traffic to identify any additional indicators of compromise or related suspicious activities.
+- Terminate any unauthorized OpenSSL processes and remove any malicious scripts or binaries found on the system.
+- Change all credentials and keys that may have been exposed during the incident to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are hardened.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address any deficiencies."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml
index 2c768bc4152..c79a78fdd30 100644
--- a/rules/linux/execution_shell_via_background_process.toml
+++ b/rules/linux/execution_shell_via_background_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and 
 process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Reverse Shell via Background Process
+
+In Linux environments, adversaries may exploit shell capabilities to establish reverse shells, allowing remote control over a compromised system. By leveraging background processes like `setsid` or `nohup` with socket connections via `/dev/tcp`, attackers can create persistent backdoors. The detection rule identifies such activities by monitoring specific process executions and arguments, signaling potential reverse shell attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious process executions involving `setsid` or `nohup` with `/dev/tcp` in the arguments, as these are key indicators of potential reverse shell activity.
+- Examine the `process.parent.name` field to identify the shell used to execute the command, which can provide insights into the attacker's preferred environment or tools.
+- Check the `process.args` field for any additional suspicious patterns or commands that might indicate further malicious intent or context.
+- Investigate the `process.parent.pid` to trace back to the parent process and understand the origin of the suspicious activity.
+- Use Osquery to gather more information about the process tree and environment variables by running a query like: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;`.
+- Analyze the network connections on the host to identify any unusual outbound connections that might correlate with the reverse shell attempt, using tools like `netstat` or `ss`.
+- Review the user's command history files (e.g., `.bash_history`) for any evidence of manual execution or testing of reverse shell commands.
+- Check for any recent changes in user accounts or permissions that might have facilitated the execution of the reverse shell.
+- Investigate any related logs, such as authentication logs, to identify potential unauthorized access or privilege escalation attempts.
+- Correlate the findings with other security alerts or logs to determine if this activity is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- Legitimate administrative scripts or maintenance tasks may use `setsid` or `nohup` with `/dev/tcp` for network communication, leading to false positives. Users should review such scripts and, if verified as non-threatening, create exceptions for these specific processes.
+- Automated monitoring or logging tools might employ similar techniques to establish network connections for data collection or alerting purposes. Identifying these tools and excluding their process signatures can reduce false alerts.
+- Developers or system administrators testing network applications might use `/dev/tcp` in shell scripts for debugging or connectivity checks. These activities should be documented, and exceptions should be configured for known testing environments.
+- Backup or synchronization scripts that use shell commands to transfer data between systems could trigger the rule. Users should ensure these scripts are secure and add them to an allowlist if they are deemed safe.
+- Custom user scripts that are part of routine operations might inadvertently match the rule's criteria. Regular audits and documentation of such scripts can help in distinguishing between benign and malicious activities, allowing for appropriate exclusions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the process tree and network connections to identify any additional compromised systems or lateral movement.
+- Terminate any suspicious processes identified as part of the reverse shell activity to halt the attacker's access.
+- Review and analyze logs from the affected system and any connected systems to gather evidence and understand the scope of the compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Restore the system from a known good backup to ensure that no malicious code remains on the system.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Implement enhanced logging and monitoring policies to detect similar activities in the future, focusing on process execution and network connections.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
index dcbcb5da900..cdf26300557 100644
--- a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
+++ b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,49 @@ sequence by host.id, process.entity_id with maxspan=5s
        (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*")
    )]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Reverse Shell via Child
+
+Reverse shells are a common technique used by attackers to gain remote access to a system by initiating a connection from the target back to the attacker's machine. This detection rule identifies such activity by monitoring for network events followed by suspicious shell process creation. It flags unusual command-line arguments or parent processes, indicating potential exploitation of shell interpreters for unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process entity IDs involved in the suspicious activity.
+- Examine the network event details, focusing on the destination IP address to determine if it is known or associated with malicious activity. Check if the IP is external and not within the specified internal ranges.
+- Analyze the process creation event, paying close attention to the command-line arguments used, such as "-i" or "-l", which may indicate interactive shell usage.
+- Investigate the parent process of the shell, especially if it is "socat" with arguments containing "exec", to understand the context of the shell execution.
+- Use Osquery to gather additional context on the process by running a query like: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve detailed information about the process, including its parent process and command-line arguments.
+- Check the process execution timeline to see if there are any other related processes or network connections that occurred around the same time.
+- Review the user's activity associated with the process to determine if the actions align with their typical behavior or if they appear suspicious.
+- Investigate any other network connections from the host around the time of the alert to identify potential lateral movement or data exfiltration attempts.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
+- Consult threat intelligence sources to see if the destination IP or any other indicators from the alert are associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools may trigger this rule if they establish network connections and spawn shell processes with similar command-line arguments. Users should review the context of these scripts and consider excluding them if they are verified as non-threatening.
+- System maintenance tasks or monitoring tools that use shell scripts to perform network diagnostics or configuration changes might be flagged. Users can create exceptions for these processes by identifying their unique command-line patterns or parent processes.
+- Development or testing environments where developers frequently use shell scripts to connect to remote systems for debugging or deployment purposes may generate false positives. Users should document these activities and exclude them from detection if they are part of regular operations.
+- Security tools or network utilities like 'socat' that are used for legitimate purposes, such as port forwarding or network testing, can mimic reverse shell behavior. Users should ensure these tools are configured securely and exclude them based on their typical usage patterns.
+- To manage false positives, users can implement a whitelist of known safe IP addresses or process names that are commonly involved in legitimate activities, ensuring these are not flagged by the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the network events and processes flagged by the detection rule.
+- Terminate any suspicious processes identified as part of the reverse shell activity to stop the attacker's access.
+- Review and analyze logs from network devices and the affected system to gather evidence and understand the attack vector.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Apply patches and updates to the affected system and any other vulnerable systems to mitigate the exploited vulnerabilities.
+- Implement enhanced logging and monitoring policies to capture detailed process and network activity, aiding in future detection and investigation.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all data is clean.
+- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and applying least privilege principles to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_java_revshell_linux.toml b/rules/linux/execution_shell_via_java_revshell_linux.toml
index 8294a0bd405..ccb4b85a3f1 100644
--- a/rules/linux/execution_shell_via_java_revshell_linux.toml
+++ b/rules/linux/execution_shell_via_java_revshell_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,49 @@ sequence by host.id with maxspan=5s
      "/usr/lib64/NetExtender.jar", "/usr/lib/jenkins/jenkins.war"
    )] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Reverse Shell via Java
+
+Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `process.entity_id` involved in the suspicious activity.
+- Examine the network connection details, focusing on the `destination.ip` to determine if it is an external or potentially malicious IP address.
+- Check the `process.executable` path to confirm if the Java process is running from a legitimate location or if it appears suspicious.
+- Investigate the `process.parent.args` to verify if the Java application was executed with the `-jar` argument, which could indicate the execution of a JAR file.
+- Cross-reference the `process.name` with known shell processes (e.g., bash, sh, zsh) to confirm if a shell was indeed spawned by the Java process.
+- Utilize Osquery to gather more information about the Java process and its parent process. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <process.entity_id>;`
+- Analyze the process tree to understand the parent-child relationship and identify any other processes spawned by the suspicious Java process.
+- Check for any recent modifications or unusual files in the directories associated with the Java process using file integrity monitoring tools or Osquery.
+- Review system logs and network logs for any additional indicators of compromise or related suspicious activities around the time of the alert.
+- Correlate the findings with threat intelligence sources to determine if the IP addresses, file hashes, or other indicators are associated with known threats or campaigns.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate Java applications that execute shell processes as part of their normal operation, such as Jenkins or remote IoT services.
+- Users can handle these false positives by adding exceptions for specific Java applications that are known to execute shell commands, such as excluding processes with parent arguments like "/usr/share/java/jenkins.war" or "/etc/remote-iot/services/remoteiot.jar".
+- Regularly review and update the list of excluded processes to ensure that only trusted applications are exempted, minimizing the risk of overlooking genuine threats.
+- Consider monitoring the frequency and context of these events to distinguish between benign and potentially malicious activities, focusing on unusual patterns or deviations from normal behavior.
+- Collaborate with application owners to understand the expected behavior of Java applications within the environment, ensuring that legitimate activities are not mistakenly flagged as threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the presence of a reverse shell by analyzing network logs, process execution details, and any suspicious Java activity.
+- Terminate any malicious Java processes and associated shell processes to stop the attacker's access.
+- Review and analyze the system's security logs to identify the initial access vector and any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Restore the system from a known good backup to ensure all malicious changes are removed, and verify the integrity of the restored system.
+- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate suspicious activities.
+- Apply system hardening measures, such as disabling unnecessary Java features, applying security patches, and enforcing least privilege access controls.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
index 4d5cb20854a..5bcacbe4846 100644
--- a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
+++ b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,48 @@ sequence by host.id, process.entity_id with maxspan=1s
     process.name : ("python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk") and 
     destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Reverse Shell via Suspicious Child Process
+
+Reverse shells are a common technique used by attackers to gain remote access to a compromised system. They exploit scripting languages and utilities like Python, Perl, and Netcat to execute commands remotely. The detection rule identifies suspicious process chains and network activities, such as shell processes initiating unexpected network connections, to flag potential reverse shell attempts. This helps in identifying and mitigating unauthorized access and persistence mechanisms used by adversaries.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process chain and network activity that triggered the rule, focusing on `process.name`, `process.args`, and `destination.ip`.
+- Verify the parent process by examining `process.parent.name` to understand the context in which the suspicious process was spawned.
+- Check the `process.entity_id` and `host.id` to correlate this event with other activities on the same host, looking for patterns or repeated behavior.
+- Use Osquery to list all processes running on the host at the time of the alert. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <suspicious_pid>;`.
+- Investigate the network connections initiated by the suspicious process using the `destination.ip` and `destination.port` fields to determine if they are known or expected.
+- Examine the command-line arguments (`process.args`) for any encoded or obfuscated commands that might indicate malicious intent.
+- Cross-reference the `destination.ip` with threat intelligence sources to check if it is associated with known malicious activity.
+- Review system logs and other security tools for any additional indicators of compromise or related alerts around the same timeframe.
+- Analyze the user account associated with the process to determine if it has been compromised or is being used in an unusual manner.
+- Investigate any file modifications or new files created by the suspicious process to identify potential payloads or scripts used in the attack.
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators may use scripts that match the detection criteria for legitimate purposes, such as automating tasks or managing remote systems. These scripts might use utilities like Python, Perl, or Netcat to establish network connections, which could trigger the rule.
+- Development and testing environments: Developers often use scripting languages and network utilities to test applications or network configurations. These activities can mimic the behavior of a reverse shell, leading to false positives.
+- Security tools and penetration testing: Security teams might use penetration testing tools that simulate reverse shell behavior to assess system vulnerabilities. These tools can trigger the detection rule during authorized security assessments.
+- Excluding known safe processes: Users can manage false positives by creating exceptions for specific processes or scripts that are known to be safe. This can be done by adding these processes to an allowlist or by modifying the detection rule to exclude certain process names or arguments that are frequently used in non-threatening contexts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the suspicious process chain and network activity to confirm the presence of a reverse shell and identify the entry point.
+- Terminate any malicious processes identified during the investigation to stop the attacker's access.
+- Review and analyze system logs, including process execution and network connection logs, to understand the scope and impact of the compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement or enhance logging policies to capture detailed process execution and network activity for future detection and analysis.
+- Restore the system from a known good backup to ensure all traces of the compromise are removed.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the attacker.
+- Implement network segmentation and access controls to limit the ability of attackers to move laterally within the network.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans and security measures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_meterpreter_linux.toml b/rules/linux/execution_shell_via_meterpreter_linux.toml
index c279ac88981..397b8716261 100644
--- a/rules/linux/execution_shell_via_meterpreter_linux.toml
+++ b/rules/linux/execution_shell_via_meterpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,49 @@ sample by host.id, process.pid, user.id
   [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"]
   [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Meterpreter Reverse Shell
+
+Meterpreter is a powerful payload within the Metasploit framework, often used by attackers to gain control over a compromised system. It operates by executing commands and gathering system information stealthily. Adversaries exploit it to fingerprint systems by reading specific files like `/etc/passwd` and network routes. The detection rule identifies these suspicious file access patterns, signaling a potential Meterpreter shell presence by monitoring system calls related to file reads on Linux systems.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id`, `process.pid`, and `user.id` associated with the suspicious file access.
+- Verify the legitimacy of the process by checking the `process.pid` against known legitimate processes on the system.
+- Use Osquery to gather more information about the process by running: `SELECT * FROM processes WHERE pid = <process.pid>;` to check the command line, parent process, and other attributes.
+- Investigate the `user.id` to determine if the user account is legitimate and if it has been compromised or misused.
+- Check the system logs for any unusual login activities or privilege escalations related to the `user.id`.
+- Examine the network connections of the host using Osquery: `SELECT * FROM socket_events WHERE pid = <process.pid>;` to identify any suspicious outbound connections.
+- Analyze the file access patterns on the host to see if other sensitive files have been accessed using: `SELECT * FROM file_events WHERE path IN ('/etc/passwd', '/etc/machine-id', '/proc/net/route', '/proc/net/ipv6_route', '/proc/net/if_inet6');`
+- Correlate the timestamps of the suspicious file accesses with other system events to identify any related activities or anomalies.
+- Investigate any recent changes to the system configuration or installed software that could have introduced vulnerabilities.
+- Consult threat intelligence sources to determine if there are any known campaigns or indicators of compromise associated with the observed behavior.
+
+### False positive analysis
+
+- Legitimate system administration tools or scripts may access files like `/etc/passwd` and network routes for configuration or monitoring purposes, leading to false positives. 
+- Automated backup or inventory management software might read these files to gather system information, which can trigger the detection rule.
+- Security monitoring tools that perform regular checks on system files and network configurations could also mimic the behavior of a Meterpreter shell.
+- To manage these false positives, users can create exceptions for known benign processes or users by excluding specific process IDs or user IDs from the detection rule.
+- Regularly review and update the list of exceptions to ensure that only trusted activities are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation to confirm the presence of a Meterpreter shell by analyzing system logs, network traffic, and any suspicious processes or connections.
+- Terminate any malicious processes identified during the investigation to stop ongoing malicious activities.
+- Change all passwords and credentials that may have been compromised, especially those with elevated privileges.
+- Restore the system from a known good backup to ensure all malicious changes are removed, and verify the integrity of the restored system.
+- Implement enhanced logging and monitoring policies to capture detailed system and network activity, focusing on file access and process execution.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate alerts with known threat patterns.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on recognizing phishing attempts and other common attack vectors to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_suspicious_binary.toml b/rules/linux/execution_shell_via_suspicious_binary.toml
index 3e79f5cfac4..4f896e16d09 100644
--- a/rules/linux/execution_shell_via_suspicious_binary.toml
+++ b/rules/linux/execution_shell_via_suspicious_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,49 @@ sequence by host.id, process.entity_id with maxspan=1s
   process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
   process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Reverse Shell via Suspicious Binary
+
+Reverse shells are a common technique used by attackers to gain persistent access to a compromised system. They exploit legitimate shell environments to execute commands remotely. Adversaries often use binaries in unusual directories to initiate these shells, followed by network connections to external IPs. The detection rule identifies this behavior by monitoring for suspicious binary executions, network activities, and shell spawns, flagging potential reverse shell activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `process.entity_id` involved in the suspicious activity.
+- Examine the `process.executable` path to determine if it is located in a commonly abused directory, such as `/tmp/*` or `/var/tmp/*`, which may indicate malicious intent.
+- Check the `process.parent.name` to verify if the parent process is a shell, such as `bash` or `sh`, which could suggest a shell was spawned by the suspicious binary.
+- Investigate the `destination.ip` in the network event to identify if the connection was made to an external or suspicious IP address, excluding local addresses like `127.0.0.1` or `::1`.
+- Use Osquery to gather more information about the suspicious binary. For example, run the following query to list details about the executable: `SELECT * FROM processes WHERE path = '/path/to/suspicious/binary';`
+- Analyze the process tree to understand the sequence of events leading to the shell spawn, focusing on the relationship between the suspicious binary and the spawned shell.
+- Check for any recent file modifications or creations in the directories where the suspicious binary was executed, which might indicate additional malicious activity.
+- Review system logs for any other unusual activities or errors around the time of the alert to gather more context about the potential compromise.
+- Investigate the user account associated with the process execution to determine if it has been compromised or is being used maliciously.
+- Correlate the findings with other alerts or incidents involving the same `host.id` or `destination.ip` to identify patterns or repeated attempts of reverse shell activities.
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators may use scripts located in directories like `/tmp` or `/var/tmp` for maintenance tasks, which could trigger the rule. Users can create exceptions for known scripts by specifying their exact paths or hashes.
+- Automated deployment tools: Tools that deploy applications or updates might execute binaries from non-standard directories. Users should identify these tools and exclude their processes from the rule.
+- Development and testing activities: Developers might run binaries from temporary directories during testing phases. Users can exclude specific user accounts or processes associated with development activities.
+- Backup and recovery operations: Some backup solutions might use temporary directories for storing scripts or binaries. Users should identify these operations and exclude them based on process names or paths.
+- Custom monitoring scripts: Organizations may have custom scripts for monitoring or logging that execute from unusual directories. Users can whitelist these scripts by adding exceptions for their specific paths or process names.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the suspicious binary and network connections.
+- Terminate any malicious processes identified during the investigation to stop ongoing threats.
+- Review and analyze logs from the affected system and network devices to gather evidence and understand the attack vector.
+- Remove any unauthorized binaries and scripts from the system, especially those located in commonly abused directories.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Restore the system from a known good backup if the integrity of the system is in question.
+- Implement enhanced logging and monitoring policies to detect similar threats in the future, including network traffic analysis and process execution monitoring.
+- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and response.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing network segmentation to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
index 56c51e0f506..e1deb7bfe4c 100644
--- a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,49 @@ sequence by host.id with maxspan=5s
        (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*")
    )] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Reverse Shell
+
+Reverse shells are tools that adversaries use to gain remote access to a system by initiating a connection from the target back to the attacker's machine. This is often achieved by exploiting vulnerabilities or misconfigurations. The detection rule identifies suspicious activity by monitoring for network events followed by shell process creation, focusing on unusual parent-child process relationships and specific command-line arguments, which are indicative of reverse shell attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and process.entity_id involved in the suspicious activity, ensuring you have the correct context for the investigation.
+- Examine the network event details, focusing on the destination.ip to identify if the connection was made to an external or potentially malicious IP address. Cross-reference this IP with threat intelligence sources.
+- Investigate the process.name and process.args fields to determine the shell type and any arguments used, which may indicate the nature of the reverse shell attempt.
+- Check the process.parent.name and process.parent.args to understand the parent process that initiated the shell, especially if it involves socat, which is commonly used in reverse shell scenarios.
+- Use Osquery to gather additional context on the involved processes. For example, run the following query to list all processes with their parent processes on the affected host: `SELECT pid, name, path, parent, cmdline FROM processes WHERE pid = <process.entity_id>;`
+- Analyze the timeline of events by correlating the network event and process creation timestamps to understand the sequence and duration of the activity.
+- Investigate any other network connections from the same host around the time of the alert to identify additional suspicious activity or patterns.
+- Review system logs on the affected host for any anomalies or related events that coincide with the alert, such as unusual login attempts or privilege escalation.
+- Check for any recent changes or anomalies in user accounts or permissions on the host that could indicate compromise or unauthorized access.
+- Assess the host's security posture by reviewing installed software and configurations to identify potential vulnerabilities or misconfigurations that could have been exploited.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools that initiate network connections followed by shell processes can trigger false positives. These might include backup scripts, configuration management tools, or system monitoring agents that use shells for executing commands remotely.
+- Developers or system administrators using secure shell (SSH) or other remote management tools might inadvertently match the rule's criteria, especially if they use non-standard ports or configurations that mimic reverse shell behavior.
+- Network scanning or security testing tools that simulate attack patterns for vulnerability assessments can also be mistaken for reverse shell attempts.
+- To manage these false positives, users can create exceptions by identifying and excluding specific process names, parent-child process relationships, or network patterns that are known to be benign in their environment. This can be done by adjusting the detection rule to whitelist certain IP addresses, process names, or command-line arguments that are part of regular operations.
+- Regularly review and update the exclusion list to ensure it reflects the current operational environment and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the reverse shell activity by analyzing network logs, process creation events, and command-line arguments.
+- Terminate any suspicious processes identified as part of the reverse shell activity to stop the attacker's access.
+- Review and analyze the system's security logs to identify any additional indicators of compromise or lateral movement attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Restore the system to a known good state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Implement enhanced logging policies to capture detailed network and process activity, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
+- Apply system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and using application whitelisting to prevent unauthorized software execution.
+- Educate users and administrators on recognizing phishing attempts and other common attack vectors used to establish reverse shells, reinforcing the importance of security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
index e4c42a2a178..031ec1573cc 100644
--- a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -87,6 +87,52 @@ sample by host.id, process.pid, process.parent.pid
     ) and network.direction == "egress" and destination.ip != null and
    not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Reverse Shell via UDP
+
+Reverse shells over UDP exploit the stateless nature of UDP to bypass firewalls, allowing attackers to execute commands remotely. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies such activity by monitoring for specific process executions, UDP socket creation, and unusual outbound connections, flagging potential misuse of these technologies.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process involved using `host.id`, `process.pid`, and `process.parent.pid`.
+- Verify the process name and command line arguments to confirm if it matches known reverse shell patterns, focusing on `process.name` and `event.action`.
+- Check the `auditd.data.syscall` for the "socket" call and ensure `auditd.data.a1` indicates a UDP connection (value "2").
+- Analyze the network connection details, particularly `network.direction` and `destination.ip`, to identify unusual or unauthorized egress connections.
+- Use Osquery to list all active network connections on the host to identify any other suspicious UDP connections:
+  ```sql
+  SELECT pid, local_address, local_port, remote_address, remote_port, protocol FROM process_open_sockets WHERE protocol = 'udp';
+  ```
+- Investigate the parent process (`process.parent.pid`) to determine if it was spawned by a legitimate or suspicious process.
+- Cross-reference the destination IP address with threat intelligence sources to check for known malicious indicators.
+- Examine historical logs for the host to identify any previous similar activities or patterns that might indicate a persistent threat.
+- Review user activity on the host around the time of the alert to identify any unauthorized access or actions.
+- Check for any recent changes to the system's firewall or security configurations that might have allowed the reverse shell to bypass protections.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools that use UDP for network diagnostics or configuration may trigger this rule. Users can handle these by identifying and excluding specific scripts or processes that are known to be safe.
+- Automated backup or monitoring systems that utilize UDP for communication might be flagged. To manage this, users should create exceptions for these systems by specifying their process names or network patterns.
+- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes may cause false positives. Users can mitigate this by excluding specific user accounts or IP ranges associated with these environments.
+- Custom applications that use UDP for legitimate data transfer could be mistakenly identified as reverse shells. Users should document and exclude these applications by their process names or network behavior.
+- Security tools that perform network scans or penetration testing using UDP might be detected. Users can address this by excluding known security tools and their associated processes from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the processes and network connections flagged by the detection rule.
+- Terminate any suspicious processes identified as part of the reverse shell activity to halt ongoing malicious actions.
+- Review and analyze system logs, including auditd and network logs, to gather evidence and understand the attack vector and timeline.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Apply patches and updates to the operating system and any vulnerable applications to mitigate known vulnerabilities exploited by the attacker.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and network activity, aiding in future detection and investigation efforts.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system from a known good backup to ensure the removal of any persistent threats or backdoors installed by the attacker.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as restricting outbound UDP traffic and enforcing least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
index 95c59d6022f..5075425aa35 100644
--- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
+++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,48 @@ not process.args : "/var/log/messages" and
 not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and
 not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Content Extracted or Decompressed via Funzip
+
+Funzip is a utility used to decompress files directly from a stream, often used in conjunction with other command-line tools. Adversaries exploit this by using commands like `tail` to read file ends and pipe the output to `funzip`, decompressing potentially malicious content for execution. The detection rule identifies this pattern by monitoring specific command sequences and excluding benign processes, thus flagging suspicious decompression activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `tail` and `funzip` command sequence in the process arguments, as this is the primary indicator of suspicious activity.
+- Check the process tree to identify the parent process of the suspicious command execution. This can provide context on how the command was initiated and whether it was part of a larger script or process.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if the account may have been compromised.
+- Examine the command line arguments used with `tail` and `funzip` to identify the specific file being accessed and decompressed. This can help determine if the file is known or potentially malicious.
+- Use Osquery to gather additional context on the file being decompressed. For example, run the following query to check the file's metadata and hash: `SELECT path, size, md5, sha256 FROM file WHERE path = '/path/to/suspicious/file';`
+- Analyze the file's contents, if accessible, to determine if it contains malicious code or scripts. This may involve using static analysis tools or sandboxing the file in a controlled environment.
+- Cross-reference the file's hash with threat intelligence databases to see if it matches known malware signatures or has been reported in previous incidents.
+- Review system logs around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the decompression event.
+- Investigate network activity from the host to determine if there were any outbound connections or data exfiltration attempts following the decompression event.
+- Check for any other alerts or indicators of compromise on the host that may suggest a broader attack or compromise, such as unusual login attempts or privilege escalation activities.
+
+### False positive analysis
+
+- Known false positives for this rule may include legitimate administrative or maintenance activities where system administrators use `tail` and `funzip` in combination for routine file management tasks. These activities might involve decompressing log files or other non-malicious data for analysis.
+- Another potential false positive scenario involves automated scripts or cron jobs that utilize `tail` and `funzip` for legitimate data processing or backup operations. These scripts might be part of system maintenance or data archiving processes.
+- To manage these false positives, users can create exceptions by excluding specific command sequences or parent processes that are known to be benign. For instance, if a particular script or administrative tool frequently triggers this rule but is verified as safe, users can add its process name or command line pattern to the exclusion list.
+- Users should regularly review and update their exclusion lists to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between reducing false positives and ensuring effective threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential malware.
+- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing logs and identifying any unauthorized processes or files.
+- Terminate any suspicious processes related to the funzip and tail command sequence to halt any ongoing malicious activity.
+- Remove any identified malicious files or software from the system to prevent re-execution.
+- Restore the system from a known good backup if available, ensuring that the backup is free from any compromise.
+- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed command-line activity and process execution for future investigations.
+- Integrate threat intelligence feeds and security solutions to improve detection capabilities and correlate alerts with known threat actors or techniques.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Review and update security policies and user training to reinforce awareness of suspicious activities and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_suspicious_executable_running_system_commands.toml b/rules/linux/execution_suspicious_executable_running_system_commands.toml
index 799dfcc7778..731aa663d32 100644
--- a/rules/linux/execution_suspicious_executable_running_system_commands.toml
+++ b/rules/linux/execution_suspicious_executable_running_system_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,50 @@ process.parent.executable:(
   process.executable:(/run/containerd/* or /srv/snp/docker/* or /tmp/.criu*)
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious System Commands Executed by Previously Unknown Executable
+
+In Linux environments, system commands are essential for managing processes and configurations. Adversaries exploit this by executing commands via unknown executables in vulnerable directories, aiming to run unauthorized code. The detection rule identifies such anomalies by monitoring command executions from unfamiliar sources, excluding known safe processes, thus highlighting potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unknown executable and the directory from which it was executed. Pay close attention to the `process.executable` field to determine the exact path.
+- Examine the `process.args` field to understand the specific system commands that were executed. This can provide insight into the potential intent of the executable.
+- Check the `process.parent.executable` field to identify the parent process that initiated the suspicious executable. This can help determine if the parent process is legitimate or potentially compromised.
+- Use Osquery to list all processes running from the directory of the suspicious executable. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/tmp/%';` to identify other potentially malicious processes.
+- Investigate the file attributes and metadata of the unknown executable using Osquery. Example query: `SELECT * FROM file WHERE path = '/path/to/suspicious/executable';` to gather information such as file size, creation time, and modification time.
+- Check the system logs for any recent changes or anomalies around the time the suspicious executable was first observed. This can help identify how the executable was introduced to the system.
+- Analyze network activity associated with the suspicious process using network monitoring tools or logs. Look for unusual outbound connections or data transfers.
+- Review user activity logs to determine if any legitimate user accounts were involved in executing or creating the suspicious executable. This can help identify potential insider threats or compromised accounts.
+- Cross-reference the suspicious executable and its hash against threat intelligence databases to check for known malware signatures or related threat actor activity.
+- Investigate other systems within the network for similar suspicious activity, focusing on the same directories and system commands, to assess if the threat is isolated or part of a broader attack.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate administrative scripts or tools that are executed from directories typically associated with suspicious activity, such as `/tmp` or `/var/tmp`. These scripts might be part of routine maintenance or monitoring tasks.
+- Developers or system administrators might run custom scripts from their home directories, which could trigger alerts if these scripts execute common system commands.
+- Automated deployment tools or configuration management systems might temporarily place executables in monitored directories during updates or installations, leading to false positives.
+- To manage these false positives, users can create exceptions for specific scripts or executables by adding them to the exclusion list in the detection rule. This can be done by specifying the full path of the known safe executable or script.
+- Users should regularly review and update the exclusion list to ensure that only verified and non-threatening processes are excluded, maintaining a balance between security and operational efficiency.
+- It is important to document any exceptions made to the rule to ensure that all team members are aware of the changes and the rationale behind them, which helps in maintaining a secure environment.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation of the alert by reviewing the process execution details, including the executable path, arguments, and parent process, to confirm malicious activity.
+- Terminate any suspicious processes identified during the investigation to halt potential malicious actions.
+- Analyze system logs and network traffic to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations team if the investigation confirms a breach or if the scope of the attack is beyond initial containment efforts.
+- Restore the system to its operational state by removing any unauthorized executables and ensuring all system files are intact and unaltered.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds and security tools to improve detection capabilities and correlate alerts with known threat actors and tactics.
+- Apply system hardening measures, such as restricting executable permissions in commonly abused directories and implementing application whitelisting.
+- Review and update security policies and procedures to address any gaps identified during the incident response and ensure better preparedness for future threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml
index 98437b758b5..978a95f9e27 100644
--- a/rules/linux/execution_suspicious_mining_process_creation_events.toml
+++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,48 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and 
 file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Mining Process Creation Event
+
+Cryptominers exploit system resources to mine cryptocurrency without user consent, often leveraging Linux services for persistence. Adversaries create or modify service files to execute mining software, disguising them as legitimate processes. The detection rule identifies unusual service creation events linked to known mining services, flagging potential unauthorized cryptomining activities by monitoring specific file names and creation actions.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file name involved in the event matches one of the known suspicious service names: "aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", or "xvf.service".
+- Check the timestamp of the event to determine when the suspicious service was created and correlate it with other system activities around the same time.
+- Identify the user account or process that initiated the service creation event to assess if it was an authorized action or potentially compromised.
+- Use Osquery to list all services on the affected host and verify the presence of the suspicious service. Example query: `SELECT name, path, pid FROM services WHERE name IN ('aliyun.service', 'moneroocean_miner.service', 'c3pool_miner.service', 'pnsd.service', 'apache4.service', 'pastebin.service', 'xvf.service');`
+- Investigate the parent process of the service creation event to understand the origin and context of the execution.
+- Examine the file path and permissions of the suspicious service file to determine if it has been altered or if it resides in an unusual location.
+- Analyze system logs for any additional indicators of compromise or related suspicious activities, such as unusual network connections or high CPU usage.
+- Check for any recent changes to the system's scheduled tasks or cron jobs that might indicate persistence mechanisms related to cryptomining.
+- Investigate any outbound network connections from the host to known mining pools or suspicious IP addresses.
+- Gather and review any available threat intelligence or previous incidents related to the identified service names to understand potential adversary tactics and techniques.
+
+### False positive analysis
+
+- Legitimate administrative actions: System administrators may create or modify service files for legitimate purposes, such as deploying new applications or updating existing services. These actions can trigger the detection rule, resulting in false positives.
+- Custom scripts or services: Organizations may use custom scripts or services that have similar naming conventions to those flagged by the rule. These can be mistaken for mining services if they share file names with known cryptominer services.
+- Automated deployment tools: Tools like Ansible, Puppet, or Chef might create or modify service files as part of automated deployment processes, which could be incorrectly identified as suspicious activity.
+- To manage false positives, users can create exceptions for known legitimate service creation events by whitelisting specific file names or paths that are frequently used in non-threatening administrative tasks. Additionally, users can refine the detection rule to exclude certain hosts or directories that are known to be safe, reducing unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the cryptominer and potential data exfiltration.
+- Conduct a thorough investigation to confirm the presence of unauthorized mining software by examining the identified service files and correlating them with known cryptomining signatures.
+- Terminate any suspicious processes associated with the identified service files to halt the mining activity.
+- Remove or disable the unauthorized service files to prevent them from being executed again.
+- Review and update the system's security patches and configurations to close any vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed information on service creation and modification events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system from a known good backup to ensure the removal of any persistent threats and verify the integrity of critical system files.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on recognizing signs of cryptomining infections and the importance of maintaining security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml
index 1422ba8d48e..3b2c15ba8b1 100644
--- a/rules/linux/execution_tc_bpf_filter.toml
+++ b/rules/linux/execution_tc_bpf_filter.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,49 @@ process where host.os.type == "linux" and event.type != "end" and process.execut
 process.args == "filter" and process.args == "add" and process.args == "bpf" and
 not process.parent.executable == "/usr/sbin/libvirtd"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 BPF filter applied using TC
+
+BPF (Berkeley Packet Filter) is a powerful tool for packet filtering and analysis, often used in conjunction with the `tc` command to manage network traffic on Linux systems. Adversaries may exploit this by applying BPF filters to manipulate or monitor traffic covertly. The detection rule identifies suspicious use of `tc` to add BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `tc` command with arguments `filter`, `add`, and `bpf`, ensuring the process executable is `/usr/sbin/tc`.
+- Verify the parent process of the `tc` command to ensure it is not `/usr/sbin/libvirtd`, as this is excluded from the detection rule.
+- Check the user account associated with the process to determine if it is a known or privileged account, which might indicate a higher risk if compromised.
+- Investigate the network interface on which the BPF filter was applied to understand the potential impact on network traffic.
+- Use Osquery to list all active BPF programs on the system to identify any other suspicious filters. Example query: `SELECT * FROM bpf_programs;`
+- Examine system logs for any other unusual activities or errors around the time the `tc` command was executed to gather more context.
+- Review recent command history for the user associated with the `tc` process to identify any other suspicious commands or patterns.
+- Analyze network traffic logs to detect any anomalies or unexpected patterns that might correlate with the time the BPF filter was applied.
+- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized use of the `tc` command.
+- Investigate any other alerts or incidents involving the same host or user to determine if this is part of a broader attack pattern.
+
+### False positive analysis
+
+- Legitimate use of `tc` by system administrators for network performance tuning or traffic management can trigger the rule. This is common in environments where network optimization is a priority.
+- Automated scripts or configuration management tools that deploy network configurations using `tc` may also be flagged. These scripts often run as part of routine maintenance or deployment processes.
+- Network monitoring or security tools that utilize BPF filters for legitimate traffic analysis might inadvertently match the rule's criteria.
+- To manage these false positives, users can create exceptions for known benign processes by excluding specific parent processes or command patterns that are verified as non-threatening.
+- Regularly review and update the exclusion list to ensure it reflects the current network management practices and tools in use, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic.
+- Conduct a thorough investigation to identify any unauthorized BPF filters applied using the `tc` command by reviewing system logs and process execution history.
+- Verify the legitimacy of the `tc` command usage by checking for known legitimate processes, such as `/usr/sbin/libvirtd`, and ensure no other unauthorized processes are involved.
+- Remove any unauthorized BPF filters and restore the network interface configuration to its original state.
+- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on the use of `tc` and BPF filters.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate similar events and detect potential threats proactively.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to detect and block suspicious `tc` command usage.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply system hardening measures, such as restricting the use of the `tc` command to authorized users and processes, to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml
index 7bb76b69397..96834e4c576 100644
--- a/rules/linux/execution_unix_socket_communication.toml
+++ b/rules/linux/execution_unix_socket_communication.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and
 not process.args == "/var/run/libvirt/libvirt-sock"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unix Socket Connection
+
+Unix sockets facilitate efficient inter-process communication (IPC) on the same host, enabling data exchange between applications. Adversaries exploit this by connecting to local sockets to gather application data, identify vulnerabilities, or establish covert channels. The detection rule identifies suspicious processes like 'nc' or 'socat' using specific arguments, signaling potential misuse while excluding legitimate operations like those involving libvirt.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on processes like 'nc', 'ncat', 'netcat', or 'socat' with suspicious arguments.
+- Check the process execution timeline to determine when the suspicious process started and if there are any patterns or anomalies in its execution frequency.
+- Investigate the parent process of the suspicious process to understand the context of its execution and identify if it was initiated by a legitimate application or a potentially malicious script.
+- Examine the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
+- Use Osquery to list all active Unix socket connections on the host to identify any unusual or unauthorized connections. Example query: `SELECT * FROM socket_events WHERE family = 'unix';`
+- Correlate the suspicious process activity with other system logs, such as authentication logs, to identify any concurrent suspicious activities or failed login attempts.
+- Analyze the command-line arguments of the process to understand the intended target of the Unix socket connection and assess if it aligns with known legitimate services or applications.
+- Investigate the file paths specified in the process arguments (e.g., "/usr/local/*", "/run/*", "/var/run/*") to verify if they are associated with known applications or if they have been recently modified.
+- Check for any recent changes or anomalies in the system's configuration files or application settings that could indicate tampering or misconfiguration.
+- Review historical data to determine if similar alerts have been triggered in the past and if they were associated with any confirmed security incidents or false positives.
+
+### False positive analysis
+
+- Legitimate administrative tools and services may trigger the rule, such as system management scripts or monitoring tools that use 'nc' or 'socat' for valid purposes. Users should review the context of these processes to determine if they are part of routine operations.
+- Automated backup or synchronization processes might use Unix sockets for data transfer, appearing suspicious but being part of regular maintenance tasks. Users can create exceptions for these processes by identifying their unique command-line arguments or execution patterns.
+- Development and testing environments often use Unix sockets for application testing and debugging, which can lead to false positives. Users should consider excluding known development tools or specific user accounts associated with these activities.
+- Some containerized applications may use Unix sockets for internal communication, which could be misinterpreted as malicious. Users can whitelist specific container IDs or paths that are known to be safe.
+- To manage false positives, users can refine the detection rule by adding exceptions for specific process arguments or paths that are consistently identified as non-threatening, ensuring that legitimate activities are not disrupted.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on processes using Unix sockets with suspicious arguments.
+- Terminate any unauthorized or suspicious processes identified during the investigation to halt potential malicious activities.
+- Review system logs and Unix socket connections to gather evidence and understand the adversary's actions and objectives.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed process execution and Unix socket activity for future monitoring and investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
+- Restore the system to its operational state by applying patches, updating configurations, and ensuring all unauthorized changes are reverted.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting Unix socket access, using application whitelisting, and regularly auditing system configurations to prevent similar incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
index 72ddcdf21c0..08071861d5f 100644
--- a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
+++ b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,49 @@ event.category:process and host.os.type:linux and auditd.data.syscall:mprotect a
   process.name:httpd
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unknown Execution of Binary with RWX Memory Region
+
+In Unix systems, the `mprotect()` syscall alters memory permissions, potentially enabling read, write, and execute (RWX) access. While necessary for legitimate processes, adversaries exploit this to execute malicious code stealthily. The detection rule identifies suspicious RWX memory changes by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on fields such as `event.category`, `host.os.type`, `auditd.data.syscall`, and `auditd.data.a2` to confirm the presence of an `mprotect()` call with RWX permissions.
+- Verify the process executable path and name using `process.executable` and `process.name` fields to ensure it is not part of the known safe binaries list.
+- Gather additional context about the process by checking its parent process using `process.parent.executable` and `process.parent.name` to identify potential sources of the suspicious activity.
+- Use Osquery to list all processes with RWX memory regions by executing: `SELECT pid, name, path FROM processes WHERE on_disk = 0 AND (path NOT LIKE '/usr/share/kibana/node/bin/node' AND path NOT LIKE '/usr/share/elasticsearch/jdk/bin/java' AND path NOT LIKE '/usr/sbin/apache2' AND name NOT LIKE 'httpd');`
+- Investigate the command line arguments of the suspicious process using `process.command_line` to identify any unusual or unexpected commands that might indicate malicious intent.
+- Check the process's network activity using `network.connection` fields to identify any suspicious outbound connections that could suggest data exfiltration or command and control communication.
+- Examine the file hashes of the binary using `file.hash.md5`, `file.hash.sha1`, and `file.hash.sha256` to determine if it matches any known malicious signatures in threat intelligence databases.
+- Review recent system logs and audit logs for any other suspicious activities or anomalies around the time of the alert to identify potential lateral movement or privilege escalation attempts.
+- Investigate the user account associated with the process using `user.name` and `user.id` to determine if the account has been compromised or is exhibiting unusual behavior.
+- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to build a comprehensive picture of the potential threat and its impact on the system.
+
+### False positive analysis
+
+- Known false positives for the Unknown Execution of Binary with RWX Memory Region rule often include legitimate applications that require RWX permissions for normal operations, such as just-in-time (JIT) compilers or certain database management systems. These applications may use `mprotect()` to optimize performance by dynamically generating and executing code.
+- Users can manage these false positives by creating exceptions for specific binaries or processes that are known to exhibit this behavior regularly. This can be done by adding these binaries to the exclusion list in the detection rule, ensuring that only truly suspicious activities are flagged.
+- It is important to regularly review and update the list of excluded binaries to ensure that new legitimate applications are not mistakenly flagged as threats. This can be achieved by maintaining a whitelist of trusted applications and processes that are known to use RWX memory regions safely.
+- In environments where custom or in-house applications are used, it is advisable to conduct a thorough analysis of these applications to understand their memory usage patterns. If they are identified as false positives, they should be documented and excluded from the detection rule to prevent unnecessary alerts.
+- Users should also consider the context of the system and its typical usage patterns. For instance, development environments may have more frequent legitimate use of RWX memory regions compared to production environments, and this context should guide the configuration of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the process that triggered the `mprotect()` syscall with RWX permissions.
+- Review and analyze logs from the affected system and any related systems to trace the execution path and identify any additional compromised binaries or processes.
+- Remove or quarantine any identified malicious binaries or scripts, and terminate any suspicious processes that are running with RWX memory permissions.
+- Restore the affected system from a known good backup to ensure that no remnants of the malicious activity remain.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities that could be exploited.
+- Implement enhanced logging policies to capture detailed syscall activity and process execution, ensuring that future suspicious activities are logged and can be analyzed.
+- Integrate security solutions such as endpoint detection and response (EDR) tools to provide real-time monitoring and alerting for suspicious activities, including unauthorized memory permission changes.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of monitoring for unusual memory permission changes and other indicators of compromise."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
index 91e72fedb1a..7239c5ccb4c 100644
--- a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
+++ b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Data Splitting Detected
+
+Data splitting utilities on Linux, like `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit this by splitting data to evade detection systems during exfiltration. The detection rule identifies suspicious use of these utilities by monitoring specific arguments and excluding benign processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on `process.name` and `process.args`.
+- Check the parent process using `process.parent.name` to determine if the process was spawned by a known benign application or a potentially malicious one.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Examine the command line arguments (`process.args`) for any unusual patterns or destinations, especially focusing on the `if=` and `of=` parameters to identify source and destination files.
+- Use Osquery to list recent processes executed by the same user to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
+- Analyze the file paths involved in the process arguments to determine if they are legitimate or if they point to sensitive or unusual locations.
+- Check system logs for any related events around the same timestamp to gather additional context on the system's state and activities.
+- Investigate network connections from the host to identify any unusual outbound connections that might indicate data exfiltration.
+- Review historical data for similar alerts on the same host or user to identify patterns or repeated attempts at data splitting.
+- Correlate the alert with other security events or alerts in the environment to determine if it is part of a larger attack campaign.
+
+### False positive analysis
+
+- Known false positives may include legitimate system processes or administrative tasks that use data splitting utilities for non-malicious purposes, such as system backups or log management.
+- Processes like `apport` and `overlayroot` are excluded as they are known to use these utilities in benign contexts.
+- Users can handle false positives by adding exceptions for specific parent processes or argument patterns that are frequently observed in non-threatening activities.
+- Consider excluding processes that operate on files within directories like `/tmp`, `/boot`, or `/proc/sys/kernel`, as these are often involved in routine system operations.
+- Regularly review and update the exclusion list to adapt to changes in system behavior and reduce unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the data splitting activity, focusing on the processes and users involved.
+- Review system logs and network traffic to trace any data exfiltration attempts and determine if any sensitive data was compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities.
+- Restore the system to its operational state by removing any unauthorized processes or files and applying necessary security patches.
+- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
+- Educate users and administrators on the risks of data splitting and exfiltration techniques, emphasizing the importance of monitoring and reporting suspicious activities.
+- Implement hardening measures such as restricting the use of data splitting utilities to authorized personnel and employing data loss prevention (DLP) solutions to monitor and control data transfers."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/impact_data_encrypted_via_openssl.toml b/rules/linux/impact_data_encrypted_via_openssl.toml
index 2e7a762d6bc..cc417ddb3dc 100644
--- a/rules/linux/impact_data_encrypted_via_openssl.toml
+++ b/rules/linux/impact_data_encrypted_via_openssl.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,49 @@ sequence by host.id, user.name, process.parent.entity_id with maxspan=5s
     /* excluding base64 encoding options and including encryption password or key params */
     not process.args in ("-d", "-a", "-A", "-base64", "-none", "-nosalt") ] with runs=10
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Data Encryption via OpenSSL Utility
+
+OpenSSL is a robust tool for secure data encryption, widely used to protect sensitive information. However, adversaries can exploit it to encrypt files maliciously, disrupting data availability and demanding ransom. The detection rule identifies rapid, repeated encryption attempts using OpenSSL, focusing on specific command patterns and arguments, signaling potential misuse for data impact.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and user.name associated with the suspicious OpenSSL activity to understand which system and user account are involved.
+- Examine the process.parent.entity_id to identify the parent process that initiated the OpenSSL command, which can provide context on how the encryption was triggered.
+- Check the process.args used in the OpenSSL command to verify the presence of encryption-specific arguments like "-k", "-K", "-kfile", "-pass", "-iv", and "-md", and ensure that no base64 encoding options were used.
+- Analyze the sequence of events within the maxspan=5s to determine if there are multiple rapid encryption attempts, indicating potential malicious activity.
+- Investigate the process.parent.name to see if the OpenSSL command was executed from a common shell or scripting language, which might suggest automated or scripted execution.
+- Use Osquery to gather additional context on the processes running on the host. For example, run the following query to list recent OpenSSL processes: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name = 'openssl';`
+- Check system logs and audit logs for any unusual login attempts or privilege escalations around the time of the OpenSSL activity to identify potential unauthorized access.
+- Review file access logs to determine which files were targeted for encryption and assess the potential impact on data availability.
+- Correlate the OpenSSL activity with network logs to identify any outbound connections that might indicate data exfiltration or communication with a command and control server.
+- Investigate the user account associated with the activity for any signs of compromise, such as changes in user behavior, unexpected privilege changes, or recent password resets.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use OpenSSL for legitimate encryption tasks, such as securing backups or transferring sensitive files, which could trigger the rule. To manage this, users can create exceptions for specific user accounts or scripts known to perform these tasks regularly.
+- Automated scripts: Some automated processes or cron jobs might use OpenSSL to encrypt data as part of their normal operation. Users should identify these scripts and exclude them from the rule by specifying the script names or paths.
+- Development and testing environments: Developers might frequently use OpenSSL for testing encryption functionalities, leading to false positives. Users can exclude specific development environments or user accounts from the rule to prevent unnecessary alerts.
+- Backup operations: Backup software or scripts that utilize OpenSSL for encrypting data during backup processes can be mistaken for malicious activity. Users should whitelist these operations by identifying the associated processes or user accounts.
+- Data transfer processes: Organizations that regularly encrypt data for secure transfer might trigger the rule. Users can handle this by excluding known data transfer processes or specific network paths associated with these operations.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further encryption or lateral movement.
+- Identify and terminate the malicious OpenSSL processes to stop ongoing encryption activities.
+- Conduct a thorough investigation to determine the scope of the attack, including identifying all affected files and systems.
+- Preserve forensic evidence by collecting relevant logs and snapshots of the system for further analysis.
+- Restore encrypted files from the most recent clean backups to ensure data availability and integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for OpenSSL usage and other encryption tools to detect similar activities in the future.
+- Review and update access controls and permissions to limit the use of encryption tools to authorized personnel only.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate employees on recognizing phishing attempts and other common attack vectors to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/impact_esxi_process_kill.toml b/rules/linux/impact_esxi_process_kill.toml
index bc58c8a9c8c..b174cb4ef1c 100644
--- a/rules/linux/impact_esxi_process_kill.toml
+++ b/rules/linux/impact_esxi_process_kill.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,49 @@ query = '''
 process where host.os.type == "linux" and event.type == "end" and process.name in ("vmware-vmx", "vmx")
 and process.parent.name == "kill"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Termination of ESXI Process
+
+VMware ESXi is a hypervisor used to run virtual machines on physical servers, crucial for data center operations. Adversaries may disrupt these environments by terminating key processes like "vmware-vmx" using commands such as "kill," potentially leading to service outages. The detection rule identifies such terminations by monitoring for specific process events, signaling possible malicious interference.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and parent process name, ensuring they match "vmware-vmx" or "vmx" and "kill" respectively.
+- Check the timestamp of the event to determine when the termination occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the user account associated with the "kill" command to determine if it is a legitimate user or potentially compromised.
+- Examine the command line history of the user who executed the "kill" command to identify any other suspicious commands or activities.
+- Use Osquery to gather additional context about the terminated process by running: `SELECT * FROM processes WHERE name IN ('vmware-vmx', 'vmx') AND pid = <terminated_process_pid>;`
+- Analyze system logs for any unauthorized access attempts or anomalies around the time of the process termination.
+- Check for any recent changes in user permissions or roles that might have allowed the execution of the "kill" command on critical processes.
+- Investigate network logs to identify any unusual connections or data transfers that coincide with the process termination event.
+- Review any recent patches or updates applied to the ESXi host that might have inadvertently affected the process stability.
+- Consult with the system administrator responsible for the ESXi environment to verify if the termination was part of any scheduled maintenance or known issue.
+
+### False positive analysis
+
+- Routine maintenance activities: System administrators may intentionally terminate VMware processes during scheduled maintenance or updates, which can trigger the detection rule. To manage this, users can create exceptions for known maintenance windows or specific administrator actions.
+- Automated scripts: Some environments may use automated scripts to manage or restart VMware processes, leading to false positives. Users should identify and exclude these scripts by specifying their process names or execution contexts in the detection rule.
+- Testing and development environments: In non-production environments, developers or testers might frequently start and stop VMware processes as part of their workflow. Users can exclude these environments by filtering based on hostnames or IP addresses associated with testing and development.
+- Backup and recovery operations: Certain backup solutions may temporarily stop VMware processes to ensure data consistency, which could be misinterpreted as malicious activity. Users should identify these backup operations and exclude them by recognizing the associated process names or parent processes.
+- Misconfigured monitoring tools: Some monitoring tools might inadvertently terminate processes as part of their error-handling routines. Users should review and adjust the configurations of these tools to prevent unnecessary terminations and exclude them from the detection rule if needed.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further malicious activity and potential spread to other systems.
+- Investigate the source of the "kill" command by reviewing user activity logs and identifying any unauthorized access or anomalies.
+- Terminate any unauthorized or suspicious sessions and change credentials for accounts that may have been compromised.
+- Restore terminated VMware processes by restarting the affected virtual machines and ensuring all services are operational.
+- Review and update firewall rules and access controls to limit the ability of unauthorized users to execute commands on the host.
+- Implement enhanced logging policies to capture detailed process creation and termination events, including parent-child process relationships.
+- Integrate security information and event management (SIEM) systems to correlate and analyze logs for early detection of similar threats.
+- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and coordination with relevant stakeholders.
+- Apply hardening measures such as disabling unnecessary services, applying security patches, and enforcing least privilege access to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/impact_memory_swap_modification.toml b/rules/linux/impact_memory_swap_modification.toml
index bccbdca4a5a..d8f3791dae0 100644
--- a/rules/linux/impact_memory_swap_modification.toml
+++ b/rules/linux/impact_memory_swap_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,49 @@ process.name in ("swapon", "swapoff") or (
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Memory Swap Modification
+
+Memory swapping in Linux involves moving data between RAM and disk storage to manage system memory efficiently. Adversaries exploit this by altering swap settings to degrade performance or facilitate resource hijacking, often for cryptomining. The detection rule identifies suspicious processes like `swapon` or `swapoff`, and commands modifying swappiness settings, signaling potential misuse by malware such as XMRig.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and command line that triggered the alert, focusing on `process.name` and `process.command_line` fields.
+- Check the `process.parent.executable` field to determine the parent process of the suspicious activity, which can provide context on how the process was initiated.
+- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity was initiated by a legitimate user or a compromised account.
+- Use Osquery to list all current swap devices and their usage with the query: `SELECT * FROM memory_info WHERE name LIKE 'Swap%';` to assess if there are any unusual swap activities.
+- Examine the system logs, such as `/var/log/syslog` or `/var/log/messages`, for any related entries around the time of the alert to gather additional context.
+- Check for any recent changes to the system's swappiness setting by reviewing the `/etc/sysctl.conf` file or using the command `sysctl vm.swappiness` to see if it matches expected configurations.
+- Investigate any recent modifications to the `/proc/sys/vm/swappiness` file by checking the file's metadata, such as modification time, using `stat /proc/sys/vm/swappiness`.
+- Use Osquery to identify any other processes that have been executed by the same user or parent process recently with the query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'swapon' OR name = 'swapoff');`.
+- Analyze network activity for the host to identify any unusual outbound connections that could indicate resource hijacking, using tools like `netstat` or `ss`.
+- Review any other security alerts or logs from the same host or user account to identify patterns or additional indicators of compromise that may correlate with the memory swap modification activity.
+
+### False positive analysis
+
+- Routine system administration tasks can trigger this rule, such as when system administrators manually adjust swap settings for performance tuning or during system maintenance. These actions are typically benign and not indicative of malicious activity.
+- Automated scripts or configuration management tools like Ansible, Puppet, or Chef that manage system settings might execute commands that match the rule's criteria, leading to false positives.
+- Some Linux distributions or custom setups may include startup scripts that adjust swappiness settings as part of their normal boot process, which could be mistakenly flagged by this rule.
+- To manage these false positives, users can create exceptions for known administrative scripts or processes by excluding specific command lines or process names that are verified as non-threatening.
+- Implementing a whitelist of trusted users or processes that are allowed to modify swap settings can help reduce false positives while maintaining security monitoring for unauthorized changes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further resource hijacking and potential lateral movement.
+- Investigate the process tree to identify the parent process and any related processes that may have initiated the swap modification.
+- Terminate any suspicious processes, especially those related to cryptomining software like XMRig, to halt malicious activity.
+- Review system logs and command history to determine the extent of the compromise and identify any unauthorized changes to swap settings.
+- Restore swap settings to their default values and ensure that no unauthorized modifications persist.
+- Conduct a thorough scan of the system using updated antivirus or anti-malware tools to detect and remove any remaining threats.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and command-line activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Apply system hardening measures, such as restricting access to swap configuration files and limiting the execution of swap-related commands to authorized users only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/impact_potential_linux_ransomware_note_detected.toml b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
index 73956314421..6b0a3c524a8 100644
--- a/rules/linux/impact_potential_linux_ransomware_note_detected.toml
+++ b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,49 @@ sequence by process.entity_id, host.id with maxspan=1s
    file.name : ("*restore*", "*lock*", "*recovery*", "*read*", "*instruction*", "*how_to*", "*ransom*")
   ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Linux Ransomware Note Creation Detected
+
+Ransomware exploits file encryption to extort victims, often leaving a note with payment instructions. This detection rule identifies suspicious mass file renaming and the creation of text files with keywords like "ransom" or "recovery" within a second. By monitoring these patterns, it helps detect ransomware activity, focusing on unusual file operations in critical directories while excluding benign processes.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process.entity_id and host.id involved in the suspicious activity.
+- Examine the process.executable path to determine if it is located in unusual directories such as /tmp, /var/tmp, or /dev/shm, which are often used by malicious actors.
+- Check the file paths involved in the renaming and creation events to see if they are in critical directories like /home/*/Documents, /root, or /var/www, which could indicate a targeted attack.
+- Investigate the process.name to ensure it is not one of the benign processes listed in the exclusion criteria, such as dpkg, yum, or python*.
+- Use Osquery to gather more information about the process by running a query like: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve details about the process, including its parent process and command line arguments.
+- Analyze the timing of the events to confirm that the mass file renaming and text file creation occurred within the 1-second timespan, as specified in the detection rule.
+- Look for additional file creation events on the host with names containing keywords like "restore", "lock", or "ransom" to identify other potential ransom notes.
+- Check the system logs for any unusual activity or errors around the time of the alert to gather more context about the system's state.
+- Investigate any network connections made by the suspicious process to external IP addresses, which could indicate communication with a command and control server.
+- Review any recent changes or installations on the host that could have introduced the suspicious process, such as new software installations or updates.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule due to mass file renaming or creation of temporary files with suspicious keywords. Users can handle this by excluding known update processes like "dpkg", "yum", "dnf", and "rpm" from the detection rule.
+- Development environments or scripts that frequently create or rename files in monitored directories might be flagged. Excluding processes such as "go", "java", "python*", and "node" can reduce false positives in these scenarios.
+- Backup or recovery operations that generate files with names containing keywords like "restore" or "recovery" could be mistakenly identified as ransomware activity. Users should consider excluding backup software processes from the rule.
+- Automated system maintenance tasks that involve file renaming or creation in critical directories may also be misinterpreted. Adding exceptions for known maintenance processes can help mitigate these false positives.
+- Users can refine the detection rule by adjusting the monitored directories or file name patterns to better align with their specific environment and reduce unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further spread of the ransomware.
+- Identify and terminate the malicious process responsible for the mass file encryption and note creation using process monitoring tools.
+- Conduct a thorough investigation to determine the scope of the attack, including identifying all affected files and systems.
+- Restore encrypted files from the most recent clean backup to ensure data integrity and minimize data loss.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Implement enhanced logging policies to capture detailed file and process activity, focusing on critical directories and suspicious file operations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide real-time alerts.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known ransomware indicators and prevent future attacks.
+- Educate employees on recognizing phishing attempts and other common ransomware delivery methods to reduce the risk of initial infection.
+- Apply system hardening measures, such as disabling unnecessary services, applying security patches, and enforcing least privilege access controls, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/lateral_movement_ssh_it_worm_download.toml b/rules/linux/lateral_movement_ssh_it_worm_download.toml
index a09d873ebb1..a433439b817 100644
--- a/rules/linux/lateral_movement_ssh_it_worm_download.toml
+++ b/rules/linux/lateral_movement_ssh_it_worm_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/21"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,52 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential SSH-IT SSH Worm Downloaded
+
+SSH is a protocol used for secure remote access and management of systems. Adversaries exploit this by deploying worms like SSH-IT, which hijack SSH sessions to spread laterally across networks. The detection rule identifies suspicious file downloads via common tools like curl and wget, targeting specific URLs associated with the SSH-IT worm, thus flagging potential threats early in the infection chain.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious file downloads using `curl` or `wget` with URLs associated with the SSH-IT worm.
+- Examine the process arguments (`process.args`) to verify if they match any of the known malicious URLs listed in the detection rule.
+- Identify the user account under which the suspicious process was executed to determine if it was initiated by a legitimate user or a compromised account.
+- Check the process execution time (`event.type == "start"`) to correlate with any unusual user activity or other suspicious events in the network.
+- Investigate the source IP address and hostname (`host.os.type == "linux"`) to determine if the affected system is part of a larger pattern of compromise.
+- Use Osquery to list all active SSH sessions on the affected host to identify any unauthorized or unusual connections:
+  ```sql
+  SELECT user, remote_address, remote_port, start_time FROM process_open_sockets WHERE local_port = 22;
+  ```
+- Analyze the system's SSH configuration files and logs to identify any unauthorized changes or anomalies that could indicate worm activity.
+- Review network traffic logs for the affected host to detect any lateral movement attempts or connections to known malicious IP addresses.
+- Cross-reference the alert with other security tools and logs to gather additional context and identify any related alerts or incidents.
+- Document all findings and observations to build a comprehensive timeline of events leading up to and following the alert.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often use tools like curl and wget for routine maintenance and updates, which may involve downloading scripts or files from URLs that are not malicious. To manage this, users can create exceptions for known and trusted URLs or specific administrative accounts that frequently perform these tasks.
+- Automated scripts and cron jobs: Some automated processes may use curl or wget to fetch updates or data from external sources. Users should review these scripts to ensure they are benign and consider excluding them from the detection rule by specifying the script names or paths.
+- Development and testing environments: Developers might use curl and wget to test connectivity or download resources during development. In such cases, users can exclude specific development machines or user accounts from the rule to prevent false positives.
+- Security tools and monitoring solutions: Some security tools may use these commands to verify the availability of resources or to perform security checks. Users should identify these tools and exclude their processes from triggering the detection rule.
+- Educational and research activities: In academic or research settings, users might download various resources for study purposes. Users can manage these false positives by excluding specific user groups or IP ranges associated with educational activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the SSH-IT worm.
+- Conduct a thorough investigation of the affected system to identify any unauthorized SSH connections or additional malware.
+- Terminate any suspicious processes related to the worm, such as those initiated by curl or wget with the identified malicious URLs.
+- Remove any downloaded malicious files and scripts associated with the SSH-IT worm from the system.
+- Reset credentials for any compromised accounts and ensure SSH keys are rotated to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the infection.
+- Implement enhanced logging policies to capture detailed SSH session activities and command executions for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
+- Harden the system by configuring SSH to use key-based authentication, disabling root login, and enforcing strong password policies."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/lateral_movement_telnet_network_activity_external.toml b/rules/linux/lateral_movement_telnet_network_activity_external.toml
index 4e1372c9e34..756687b2e87 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_external.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_external.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -88,6 +88,49 @@ sequence by process.entity_id
     )
   ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Connection to External Network via Telnet
+
+Telnet is a protocol offering command-line access to remote systems, often used for network device management. Adversaries exploit Telnet to gain unauthorized access to external networks, bypassing security controls. The detection rule identifies Telnet connections to non-private IPs, flagging potential lateral movement or remote service abuse, aligning with MITRE ATT&CK's T1021 technique.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process.entity_id and destination.ip involved in the Telnet connection to a non-private IP address.
+- Verify the legitimacy of the destination IP by checking if it belongs to known external services or if it is associated with any suspicious or malicious activity.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve details about the Telnet process, including its parent process and command-line arguments.
+- Investigate the user account associated with the Telnet process by checking the process's user ID and correlating it with recent login activities to determine if the account has been compromised.
+- Examine network logs to identify any other unusual or unauthorized connections originating from the same host, focusing on connections to external IPs.
+- Check for any recent changes or anomalies in the system's configuration files or network settings that could indicate tampering or unauthorized access.
+- Analyze historical data to determine if there have been previous Telnet connections from the same host to external networks, which could indicate a pattern of suspicious behavior.
+- Correlate the Telnet activity with other security alerts or logs to identify potential lateral movement or coordinated attacks within the network.
+- Investigate the host's security posture by reviewing installed software, open ports, and running services to identify any vulnerabilities or misconfigurations that could have been exploited.
+- Consult threat intelligence sources to determine if the destination IP or any related indicators of compromise are associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Telnet connections to external IPs that are part of legitimate business operations, such as remote management of company-owned devices, can trigger false positives. Users can handle these by creating exceptions for known IP addresses that are part of regular business activities.
+- Automated scripts or monitoring tools that use Telnet for legitimate network management tasks may be flagged. To manage this, users can whitelist specific process names or scripts that are verified as non-threatening.
+- Connections to cloud service providers or third-party vendors that use public IP addresses for legitimate services might be incorrectly flagged. Users should identify and exclude these IP ranges from the detection rule to prevent unnecessary alerts.
+- Testing environments or labs that simulate external connections for development purposes can cause false positives. Users can exclude these environments by specifying their IP ranges or hostnames in the rule exceptions.
+- Legacy systems that rely on Telnet for communication with external partners may be mistakenly identified as threats. Users should document and exclude these systems from the rule to ensure they are not flagged during routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying any other systems that may have been accessed using Telnet.
+- Review system logs and Telnet session records to gather evidence and understand the adversary's actions and objectives.
+- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions.
+- Remove any unauthorized accounts or backdoors that may have been created by the adversary.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network segmentation to limit the ability of adversaries to move laterally within the network.
+- Enhance logging and monitoring policies to include detailed Telnet session logs and alerts for connections to non-private IPs.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/lateral_movement_telnet_network_activity_internal.toml b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
index 2f57dba3856..fb8dd422f01 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_internal.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -88,6 +88,48 @@ sequence by process.entity_id
     )
   ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Connection to Internal Network via Telnet
+
+Telnet is a protocol offering command-line access to remote systems, often used for network device management. However, its lack of encryption makes it vulnerable to interception and misuse by adversaries for lateral movement within a network. The detection rule identifies Telnet connections to private IP ranges, signaling potential unauthorized access attempts, aligning with MITRE ATT&CK's lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a Telnet connection to a private IP address, focusing on the `process.entity_id`, `destination.ip`, and `event.type` fields.
+- Verify the legitimacy of the Telnet process by checking the `process.name` and `host.os.type` fields to ensure it matches expected behavior for the system.
+- Use Osquery to gather additional context about the Telnet process by running a query such as: `SELECT * FROM processes WHERE name = 'telnet';` to retrieve details like the process ID, user, and command line arguments.
+- Investigate the source and destination IP addresses involved in the connection to determine if they belong to known or trusted devices within the network.
+- Check historical logs for previous Telnet connections from the same source IP to identify patterns or repeated unauthorized access attempts.
+- Analyze user activity associated with the Telnet process by reviewing login records and user sessions to identify any anomalies or unauthorized access.
+- Correlate the Telnet activity with other network traffic logs to identify any concurrent suspicious activities or lateral movement attempts.
+- Examine the system's security configuration and patch levels to assess if vulnerabilities could have been exploited to initiate the Telnet connection.
+- Review firewall and network access control logs to determine if there were any changes or anomalies that could have facilitated the Telnet connection.
+- Consult with system administrators or network engineers to verify if the Telnet connection was part of any scheduled maintenance or legitimate administrative task.
+
+### False positive analysis
+
+- Telnet connections initiated by network administrators for legitimate device management tasks can trigger false positives. Users can handle these by creating exceptions for known administrator IP addresses or specific devices frequently accessed for maintenance.
+- Automated scripts or monitoring tools that use Telnet for routine checks on network devices may also be flagged. To manage this, users can whitelist the IP addresses or process names associated with these scripts.
+- Internal testing environments that simulate network conditions using Telnet might be mistakenly identified as threats. Users should consider excluding IP ranges or hostnames associated with these testing environments.
+- Legacy systems that rely on Telnet for communication within a secure network segment could generate false positives. Users can mitigate this by defining exceptions for these systems, ensuring they are monitored through other security measures.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the Telnet connection, including reviewing logs and network traffic for any suspicious activity.
+- Terminate any unauthorized Telnet sessions and disable Telnet services on the affected system to prevent future misuse.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement network segmentation to limit access to critical systems and reduce the risk of lateral movement.
+- Enhance logging and monitoring by enabling detailed logging for Telnet and other remote access protocols, and integrate with a security information and event management (SIEM) system for real-time analysis.
+- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate known vulnerabilities.
+- Conduct a security audit of the affected system to identify and remediate any additional security weaknesses.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure that all security measures are in place.
+- Implement hardening measures such as disabling unused services, enforcing strong authentication mechanisms, and using encrypted protocols for remote access to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_execution.toml b/rules/linux/persistence_apt_package_manager_execution.toml
index 129eef327c6..ad7844829cc 100644
--- a/rules/linux/persistence_apt_package_manager_execution.toml
+++ b/rules/linux/persistence_apt_package_manager_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,48 @@ sequence by host.id with maxspan=5s
    )
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious APT Package Manager Execution
+
+APT, a tool for managing software on Debian-based Linux systems, can be exploited by attackers to maintain persistence. By injecting malicious code into scripts executed by APT, adversaries can ensure unauthorized access whenever APT is used. The detection rule identifies suspicious executions by monitoring for shell or scripting language processes initiated by APT, indicating potential backdoor activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process entity IDs involved in the suspicious execution.
+- Examine the process tree to understand the parent-child relationship, focusing on the parent process named "apt" and its child processes, especially those involving shell or scripting languages.
+- Check the command-line arguments of the suspicious processes, particularly looking for the "-c" flag, which may indicate execution of a command string.
+- Investigate the timing of the suspicious process events to determine if they align with legitimate package management activities or if they appear anomalous.
+- Use Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name IN ('bash', 'dash', 'sh', 'tcsh', 'csh', 'zsh', 'ksh', 'fish', 'python', 'php', 'perl', 'ruby', 'lua', 'openssl', 'nc', 'netcat', 'ncat', 'telnet', 'awk') AND parent = (SELECT pid FROM processes WHERE name = 'apt');`
+- Analyze the environment variables and working directory of the suspicious processes to identify any unusual settings or paths that could indicate tampering.
+- Review the system logs for any additional context around the time of the alert, such as user logins, cron jobs, or other scheduled tasks that might correlate with the suspicious activity.
+- Check for any recent changes to APT configuration files or scripts that could have been modified to include malicious code.
+- Investigate the network activity of the host around the time of the alert to identify any suspicious outbound connections that could suggest data exfiltration or command-and-control communication.
+- Correlate the findings with other security alerts or incidents involving the same host or user account to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use APT to perform legitimate package management tasks that may trigger the detection rule. These tasks can include running scripts for configuration or maintenance purposes, which might involve shell or scripting language processes.
+- Custom scripts: Organizations may have custom scripts that are executed during package installations or updates. These scripts could be mistakenly flagged as suspicious if they involve shell or scripting language processes.
+- Automated deployment tools: Tools like Ansible, Puppet, or Chef might use APT as part of their automated deployment processes, leading to benign script executions that could be misinterpreted as suspicious.
+- To manage false positives, users can create exceptions for known benign processes or scripts by whitelisting specific process names or command-line arguments that are frequently used in legitimate operations. This can be done by adjusting the detection rule to exclude these known non-threatening behaviors.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify any malicious scripts or code injected into APT-related scripts or processes.
+- Review and analyze logs from the affected system to trace the origin and timeline of the suspicious APT execution.
+- Remove any identified malicious scripts or code and restore original APT scripts from a trusted source or backup.
+- Update all system packages and apply security patches to mitigate any known vulnerabilities that could be exploited.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to monitor for similar threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence sharing.
+- Restore the system to its operational state by verifying the integrity of critical system files and configurations.
+- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and regularly reviewing user permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_file_creation.toml b/rules/linux/persistence_apt_package_manager_file_creation.toml
index a9d7f872d29..ea7c9a53d31 100644
--- a/rules/linux/persistence_apt_package_manager_file_creation.toml
+++ b/rules/linux/persistence_apt_package_manager_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -88,6 +88,50 @@ file.path : "/etc/apt/apt.conf.d/*" and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 APT Package Manager Configuration File Creation
+
+APT, a key utility in Debian-based Linux systems, manages software packages and repositories. Adversaries may exploit APT by inserting malicious scripts into its configuration files, ensuring persistent unauthorized access. The detection rule identifies suspicious file creation or renaming in APT's configuration directory, excluding legitimate processes, to flag potential backdoor attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and name involved in the creation or renaming event within the `/etc/apt/apt.conf.d/` directory.
+- Check the `process.executable` field to determine which process was responsible for the file creation or renaming. Verify if it matches any known legitimate processes or if it appears suspicious.
+- Investigate the `process.name` field to identify the process name associated with the event. Cross-reference this with known benign processes to rule out false positives.
+- Examine the `file.extension` and `file.Ext.original.extension` fields to ensure the file does not have extensions commonly associated with temporary or transitional files, such as "swp", "swpx", "swx", or "dpkg-new".
+- Use Osquery to gather more context about the file and process. For example, run the following query to list details about the file and its associated process: `SELECT * FROM file WHERE path = '/etc/apt/apt.conf.d/<file_name>';`.
+- Investigate the parent process of the suspicious process using the `process.parent` field to understand the process hierarchy and identify potential sources of the unauthorized action.
+- Check system logs, such as `/var/log/auth.log` or `/var/log/syslog`, for any related entries around the time of the event to identify any unusual activity or unauthorized access attempts.
+- Review recent user activity on the system to determine if any user accounts were active during the time of the event and if they have a history of legitimate administrative actions.
+- Analyze network logs to identify any outbound connections from the host that may indicate data exfiltration or communication with a command and control server.
+- Correlate the event with other security alerts or incidents in the environment to determine if this is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- Legitimate package management operations: System administrators or automated processes may create or rename files in the APT configuration directory during routine package management tasks. These actions are typically performed by trusted package management tools like `dpkg`, `apt-get`, or `snapd`, which are already excluded in the detection rule.
+- Temporary files: Editors like `vim` or `nano` may create temporary files with extensions such as `.swp` or `.swx` while editing configuration files. These are non-threatening and are excluded by checking for specific file extensions.
+- System updates and maintenance scripts: Automated scripts or system maintenance tools may modify APT configuration files as part of their normal operation. Users can handle these by adding exceptions for known maintenance scripts or processes.
+- Custom scripts or tools: Organizations may use custom scripts or third-party tools for managing APT configurations. Users should identify these scripts and add their paths or process names to the exclusion list to prevent false positives.
+- Exclude specific directories: If certain directories within `/etc/apt/apt.conf.d/` are known to be used for legitimate purposes, users can modify the rule to exclude these paths from monitoring.
+- Monitor process context: Ensure that the process context of file creation or renaming events is analyzed. If a known and trusted process is responsible, consider adding it to the exclusion list to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the malicious file creation, examining logs and process histories to trace the attack vector.
+- Remove any unauthorized or suspicious files from the APT configuration directory and restore original configuration files from a known good backup.
+- Review and update the system's APT package manager and related software to the latest versions to patch any vulnerabilities.
+- Implement enhanced logging for file creation and modification events in critical directories, ensuring logs are sent to a centralized logging solution for continuous monitoring.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
+- Conduct a comprehensive security audit of the system to identify and remediate any additional vulnerabilities or misconfigurations.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the attack appears to be part of a larger campaign or if advanced persistent threat (APT) actors are suspected.
+- Restore the system to its operational state by verifying the integrity of all system files and configurations, ensuring no backdoors or malicious scripts remain.
+- Implement hardening measures such as restricting write permissions to critical directories, enforcing the principle of least privilege, and regularly reviewing user access rights."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_netcon.toml b/rules/linux/persistence_apt_package_manager_netcon.toml
index 4fbac8005de..415647ccaa0 100644
--- a/rules/linux/persistence_apt_package_manager_netcon.toml
+++ b/rules/linux/persistence_apt_package_manager_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,50 @@ sequence by host.id with maxspan=5s
    ) and not process.executable == "/usr/bin/apt-listbugs"
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious APT Package Manager Network Connection
+
+The APT package manager is crucial for managing software on Debian-based Linux systems, handling installations and updates. Adversaries may exploit APT by embedding malicious scripts to maintain unauthorized access. The detection rule identifies unusual network connections initiated by APT, excluding known safe IP ranges, to spot potential backdoor activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process entity IDs involved in the suspicious activity.
+- Examine the process execution details, focusing on the parent process name "apt" and the child process names such as "bash", "dash", "sh", etc., to understand the context of the script execution.
+- Check the command-line arguments used with the APT process, especially the presence of the "-c" flag, which indicates a custom configuration file, to identify any unusual or unauthorized configurations.
+- Investigate the network connection details, particularly the destination IP address, to determine if it falls outside the known safe IP ranges and assess its legitimacy.
+- Use Osquery to gather additional context on the suspicious process by running a query like: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve detailed information about the process, including its command line, parent process, and execution path.
+- Analyze the network traffic logs for the host to identify any other unusual or unauthorized connections that may correlate with the suspicious APT activity.
+- Review the system logs on the affected host for any related entries that might provide additional context or evidence of compromise, such as authentication logs or system events.
+- Check for any recent changes to the APT configuration files or scripts on the host that could indicate tampering or unauthorized modifications.
+- Investigate the history of package installations and updates on the host to identify any recent or suspicious package activities that could be linked to the alert.
+- Correlate the findings with other security alerts or incidents involving the same host or network to determine if this activity is part of a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives may include legitimate scripts executed by APT that initiate network connections for valid package management tasks, such as fetching updates or accessing external repositories.
+- Network connections to newly added or less common repositories might be flagged as suspicious if they fall outside the predefined safe IP ranges, even if they are legitimate.
+- Users can handle these false positives by creating exceptions for specific IP addresses or ranges that are known to be safe and frequently accessed by APT during normal operations.
+- It is advisable to maintain an updated list of trusted repositories and their associated IP addresses to minimize false positives while ensuring security.
+- Regularly review and update the exclusion list to accommodate changes in network infrastructure or repository configurations, ensuring that legitimate activities are not mistakenly flagged.
+- Consider implementing additional context checks, such as verifying the digital signatures of packages, to differentiate between legitimate and potentially malicious activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the APT package manager logs and any associated scripts to identify and analyze the malicious code or backdoor.
+- Terminate any suspicious processes initiated by the APT package manager that are not part of legitimate package management activities.
+- Remove or replace any compromised scripts or packages identified during the investigation to eliminate the backdoor.
+- Restore the system from a known good backup if the integrity of the system is in question and ensure all software is up to date.
+- Implement enhanced logging policies to capture detailed information on APT package manager activities and network connections for future analysis.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known malicious IP addresses and unusual outbound connections.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface and prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_at_job_creation.toml b/rules/linux/persistence_at_job_creation.toml
index cebef39e692..cac28b8ae71 100644
--- a/rules/linux/persistence_at_job_creation.toml
+++ b/rules/linux/persistence_at_job_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,50 @@ event.action in ("rename", "creation") and file.path : "/var/spool/cron/atjobs/*
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 At Job Created or Modified
+
+The 'at' command in Linux schedules tasks for future execution, aiding system administrators in automating routine jobs. However, attackers can exploit this by creating or altering 'at' jobs to maintain persistence, escalate privileges, or execute unauthorized commands. The detection rule identifies suspicious 'at' job activities by monitoring file changes in specific directories, excluding benign processes and extensions, thus highlighting potential malicious actions.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process executable involved in the 'at' job creation or modification, focusing on the `file.path` and `process.executable` fields.
+- Verify the legitimacy of the process executable by checking its hash against known good hashes or using threat intelligence sources to determine if it is associated with known malicious activity.
+- Use Osquery to list all scheduled 'at' jobs on the system to identify any unexpected or unauthorized entries. Example query: `SELECT * FROM at_jobs;`
+- Investigate the user account associated with the process that created or modified the 'at' job to determine if it has been compromised or is being misused.
+- Check the process tree to understand the parent process and any child processes spawned by the suspicious executable, which can provide context on how the 'at' job was created or modified.
+- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual login attempts or privilege escalation activities around the time the 'at' job was created or modified.
+- Analyze the contents of the 'at' job script or command to determine its purpose and whether it contains any malicious or unauthorized actions.
+- Cross-reference the timing of the 'at' job creation or modification with other security alerts or incidents to identify potential correlations or patterns of attack.
+- Investigate any network connections initiated by the process executable to external IP addresses, which may indicate data exfiltration or command-and-control communication.
+- Review the system's history of software installations and updates to ensure that the process executable is not part of a legitimate software update or installation process.
+
+### False positive analysis
+
+- System updates and package management activities can trigger false positives as they often involve creating or modifying files in the `/var/spool/cron/atjobs/` directory. Processes like `dpkg`, `rpm`, `yum`, and `dnf` are commonly involved in these activities and should be excluded to prevent unnecessary alerts.
+- Container management tools such as `dockerd` and `podman` may also modify files in the monitored directory during normal operations. Excluding these processes can help reduce false positives.
+- Automated system maintenance scripts, such as those run by `puppet` or `chef-client`, might create or modify at jobs as part of their configuration management tasks. These should be considered for exclusion if they are part of regular, authorized operations.
+- Temporary files created by text editors (e.g., with extensions like `.swp`, `.swpx`, `.swx`) can be mistaken for suspicious activity. Excluding these file extensions can help in minimizing false alerts.
+- Processes running from specific directories like `/nix/store/`, `/var/lib/dpkg/`, or `/snap/` are often part of legitimate system operations and can be safely excluded if verified as non-threatening.
+- Users can manage false positives by regularly reviewing and updating the exclusion list to include any new benign processes or file patterns that are identified during routine system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks.
+- Review the 'at' job entries in the /var/spool/cron/atjobs/ directory to identify any unauthorized or suspicious jobs and remove them.
+- Investigate the process that created or modified the 'at' job by examining logs and process details to determine if it was a legitimate action or part of a malicious activity.
+- Check for other signs of compromise on the system, such as unexpected user accounts, unauthorized software installations, or unusual network activity.
+- Restore the system from a known good backup if the investigation confirms a compromise, ensuring that all malicious changes are removed.
+- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed information about process executions and file modifications, aiding in future investigations.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to monitor for similar activities in the future.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate users and administrators about the risks associated with scheduled tasks and the importance of monitoring and securing these configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
index 00531a50ec6..bfecd73a95d 100644
--- a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,50 @@ file.path : ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 DNF Package Manager Plugin File Creation
+
+DNF, a package manager for Fedora-based systems, manages software installations and updates. Adversaries may exploit DNF by inserting malicious code into its plugins, ensuring persistent access whenever DNF is used. The detection rule identifies suspicious file creation or renaming in plugin directories, excluding benign processes and temporary files, to flag potential backdoor attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and event action (creation or rename) that triggered the alert. Focus on paths like `/usr/lib/python*/site-packages/dnf-plugins/*` and `/etc/dnf/plugins/*`.
+- Check the process executable that initiated the file creation or rename event. Ensure it is not one of the benign processes listed in the exclusion criteria, such as `/bin/dnf` or `/usr/bin/yum`.
+- Investigate the file extension of the newly created or renamed file to ensure it is not a temporary file with extensions like `swp`, `swpx`, or `swx`.
+- Use Osquery to gather more information about the file. For example, run the query: `SELECT * FROM file WHERE path = '/usr/lib/python*/site-packages/dnf-plugins/*' OR path = '/etc/dnf/plugins/*';` to get details about the file's metadata and attributes.
+- Examine the file's contents to identify any suspicious or unauthorized code that may have been injected. Look for unusual scripts or commands that do not align with typical plugin functionality.
+- Cross-reference the file creation or rename event with recent system logs to identify any correlated activities or anomalies around the time of the event.
+- Verify the integrity of the DNF package manager and its plugins by comparing the current state with known good baselines or checksums, if available.
+- Investigate the user account associated with the process that created or renamed the file to determine if it has the necessary permissions and if the activity aligns with expected behavior.
+- Check for any recent changes in user privileges or group memberships that could have facilitated unauthorized access to the plugin directories.
+- Review historical data to identify any previous similar alerts or patterns that could indicate a persistent threat or ongoing attack campaign targeting the DNF package manager.
+
+### False positive analysis
+
+- Routine system updates or administrative tasks may trigger file creation or renaming events in the DNF plugin directories, especially when legitimate software updates or configurations are applied. Users should verify if these events coincide with scheduled maintenance or updates.
+- Automated scripts or configuration management tools like Puppet or Chef might create or modify files in these directories as part of their normal operations. Users can exclude these processes by adding them to the exception list if they are verified as non-malicious.
+- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be mistakenly flagged. Users should ensure these extensions are included in the exclusion criteria to prevent false alerts.
+- Processes running from specific directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users can add these paths to the exclusion list if they are confirmed to be safe.
+- If the process executable is null, it might indicate a transient or incomplete event capture. Users should investigate these cases further to determine if they are benign or require additional context for exclusion.
+- Specific processes like "sed" or "perl" might create temporary files during their operations. Users can exclude these processes when they match known benign patterns, such as "sed*" or "e2scrub_all.tmp*", to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify any malicious code within the DNF plugin directories and determine the extent of the compromise.
+- Review recent file creation and modification events in the DNF plugin directories to identify unauthorized changes and potential backdoor installations.
+- Remove any identified malicious files or code from the DNF plugin directories and restore legitimate files from a known good backup.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging for DNF-related activities and file system changes to improve detection of future unauthorized modifications.
+- Integrate security tools with threat intelligence feeds to identify known malicious indicators related to DNF plugin tampering.
+- Apply security patches and updates to the DNF package manager and related software to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
+- Educate system administrators and users on recognizing signs of compromise and the importance of maintaining secure configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
index b55731cca6e..4e3be9a2060 100644
--- a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,48 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:dpkg and
 process.args:("-i" or "--install")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 DPKG Package Installed by Unusual Parent Process
+
+DPKG is a core utility for managing Debian packages on Linux, crucial for software installation and maintenance. Adversaries may exploit DPKG to install harmful packages, leveraging unusual parent processes to evade detection. The detection rule identifies such anomalies by monitoring DPKG executions initiated by atypical parent processes, focusing on installation actions, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `dpkg` command execution with the `-i` or `--install` argument, as these indicate package installation attempts.
+- Identify and document the unusual parent process that initiated the `dpkg` command. This can provide insights into potential misuse or compromise of legitimate processes.
+- Cross-reference the parent process with known benign processes or scheduled tasks to rule out false positives.
+- Use Osquery to gather additional context about the parent process. For example, run the following query to list processes with their parent process IDs and command lines: `SELECT pid, name, cmdline, parent FROM processes WHERE name = 'dpkg';`
+- Investigate the user account associated with the `dpkg` execution to determine if it aligns with expected administrative activity or if it suggests unauthorized access.
+- Check system logs for any preceding or subsequent suspicious activities around the time of the `dpkg` execution, such as unusual login attempts or privilege escalation.
+- Examine the installed package details, including the package name, version, and source, to assess whether it is a known or potentially malicious package.
+- Review network logs for any outbound connections made by the system around the time of the package installation, which might indicate data exfiltration or command-and-control communication.
+- Investigate any file modifications or new files created in system directories that could be associated with the installed package, using file integrity monitoring tools or manual inspection.
+- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- System administrators or automated scripts may trigger the DPKG installation process for legitimate software updates or installations, leading to false positives. To manage this, users can create exceptions for known administrative scripts or processes that regularly perform package installations.
+- Some system management tools or configuration management software, such as Ansible or Puppet, might use DPKG to install packages as part of their normal operations. Users can exclude these tools by identifying their typical parent processes and adding them to an allowlist.
+- During system provisioning or automated deployment processes, DPKG might be invoked by non-standard parent processes. Users should review these processes and, if deemed safe, configure exceptions to prevent unnecessary alerts.
+- Developers or testing environments might use custom scripts to install packages for testing purposes, which could be flagged as unusual. Users can handle these by documenting and excluding these specific scripts or environments from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity.
+- Conduct a thorough investigation to identify the unusual parent process that initiated the DPKG command and determine if it is associated with known malicious activity.
+- Review system logs and process execution history to trace the origin and impact of the installed package, ensuring no other systems are compromised.
+- Remove any suspicious or unauthorized packages installed by the DPKG command to mitigate potential threats.
+- Restore the system to a known good state using backups or system snapshots, ensuring all critical data is preserved.
+- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if the threat cannot be contained.
+- Implement enhanced logging policies to capture detailed process execution and parent-child relationships for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Apply system hardening measures, such as restricting the execution of administrative commands to authorized users and processes only.
+- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness and response times."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dpkg_unusual_execution.toml b/rules/linux/persistence_dpkg_unusual_execution.toml
index 63beaf41029..57fb71013ea 100644
--- a/rules/linux/persistence_dpkg_unusual_execution.toml
+++ b/rules/linux/persistence_dpkg_unusual_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ process.group_leader.name != null and not (
   process.parent.executable in ("/usr/share/debconf/frontend", "/usr/bin/unattended-upgrade")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual DPKG Execution
+
+DPKG is a core utility in Debian-based Linux systems for managing software packages. While essential for legitimate package management, adversaries can exploit DPKG to install malicious software, gaining persistence or executing unauthorized actions. The detection rule identifies anomalies by flagging DPKG executions from unexpected processes, excluding known legitimate sources, thus highlighting potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process triggered the Unusual DPKG Execution rule, focusing on the `process.executable` and `process.parent.name` fields.
+- Verify the legitimacy of the process by checking the `process.session_leader.name` and `process.group_leader.name` to ensure they are not associated with known legitimate DPKG operations.
+- Investigate the parent process by examining the `process.parent.executable` to determine if it is a known and trusted application.
+- Use Osquery to gather more information about the suspicious process. For example, run the following query to list all processes related to the suspicious executable: `SELECT * FROM processes WHERE path = '/var/lib/dpkg/info/*';`
+- Check the system logs for any recent package installations or removals that coincide with the alert timestamp to identify any unauthorized package management activities.
+- Investigate the network activity of the host around the time of the alert to identify any suspicious outbound connections that might indicate data exfiltration or command-and-control communication.
+- Examine the file system for any newly created or modified files in the `/var/lib/dpkg/info/` directory that could be associated with the suspicious DPKG execution.
+- Review user activity logs to determine if any unauthorized users were logged in or if there were any unusual login attempts around the time of the alert.
+- Cross-reference the alert with other security tools and logs to identify any correlated events or indicators of compromise that might provide additional context.
+- Document all findings and observations to build a comprehensive understanding of the incident, which will aid in determining the next steps for response and remediation.
+
+### False positive analysis
+
+- Automated system maintenance tasks: Some automated scripts or system maintenance tools might invoke DPKG for legitimate purposes, such as system updates or configuration changes, which could be flagged as unusual. Users can handle these by identifying the specific scripts or tools and adding them to the exclusion list.
+- Custom administrative scripts: Administrators may use custom scripts to manage packages across multiple systems. These scripts, if not recognized by the rule, could trigger false positives. Users should review these scripts and, if deemed safe, exclude them from the rule.
+- Non-standard package management tools: Some organizations might use alternative package management tools that interact with DPKG in unconventional ways. These tools should be identified and excluded if they are verified to be non-threatening.
+- Development and testing environments: In environments where software is frequently installed and removed for testing purposes, DPKG executions might be more common and benign. Users can create exceptions for these environments to reduce noise.
+- Legacy systems or configurations: Older systems or unique configurations might have different processes interacting with DPKG. Users should assess these systems and consider excluding them if they consistently generate false positives without indicating a threat.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious software.
+- Conduct a thorough investigation to identify the source of the unusual DPKG execution, examining process trees and related logs for any unauthorized changes or installations.
+- Verify the integrity of installed packages using checksums or package verification tools to identify any tampered or malicious packages.
+- Remove any unauthorized or malicious packages identified during the investigation to mitigate the threat.
+- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
+- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds to correlate unusual DPKG executions with known threat actor tactics, techniques, and procedures (TTPs).
+- Apply system hardening measures, such as restricting DPKG execution to trusted users and processes, and implementing application whitelisting.
+- Conduct a post-incident review to update incident response plans and improve detection rules based on lessons learned from the investigation."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_git_hook_execution.toml b/rules/linux/persistence_git_hook_execution.toml
index 74aeb658187..66f1b25a248 100644
--- a/rules/linux/persistence_git_hook_execution.toml
+++ b/rules/linux/persistence_git_hook_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,49 @@ sequence by host.id with maxspan=3s
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Git Hook Command Execution
+
+Git hooks are scripts that automate tasks during Git operations like commits or pushes. While useful for developers, adversaries can exploit them to run unauthorized commands, gaining persistence on a system. The detection rule identifies suspicious activity by monitoring for shell processes initiated by Git hooks, flagging potential misuse when these processes execute commands, indicating possible malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Git hook script that triggered the alert by examining the `process.args` field for the path pattern ".git/hooks/*".
+- Verify the parent process by checking the `process.parent.name` field to confirm it is a Git process, ensuring the alert is related to Git hook execution.
+- Investigate the child process initiated by the Git hook by examining the `process.name` field to determine which shell was used (e.g., bash, zsh).
+- Check the `process.entity_id` and `process.parent.entity_id` fields to trace the process lineage and understand the sequence of execution.
+- Use Osquery to list all Git hooks present in the repository by running: `SELECT path, content FROM file WHERE directory LIKE '%.git/hooks%' AND type = 'file';` to identify any unauthorized or suspicious scripts.
+- Examine the content of the suspicious Git hook script identified in the alert to understand its purpose and any commands it executes.
+- Cross-reference the execution time of the suspicious process with user activity logs to determine if the execution aligns with legitimate user actions.
+- Review system logs for any additional context around the time of the alert, focusing on any unusual or unexpected system changes or network activity.
+- Investigate the user account associated with the process execution to determine if it has been compromised or is exhibiting unusual behavior.
+- Check for any recent changes to the Git repository, including new commits or branches, that might indicate tampering or unauthorized access.
+
+### False positive analysis
+
+- Developers often use Git hooks for legitimate automation tasks, such as running tests or formatting code before commits, which can trigger the detection rule. These activities, while benign, may appear suspicious if they involve shell processes.
+- Continuous Integration/Continuous Deployment (CI/CD) systems might execute Git hooks as part of their automated workflows, leading to false positives. These systems often use shell scripts to manage build and deployment processes.
+- To manage these false positives, users can create exceptions for known and trusted scripts or processes by whitelisting specific Git hook paths or process names that are frequently used in their development environment.
+- Users should regularly review and update their exception lists to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
+- It's important to monitor the context of the detected activity, such as the timing and frequency of the hook execution, to differentiate between normal development operations and potential malicious behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Investigate the Git repository and its hooks to identify any unauthorized modifications or scripts that may have been added by an attacker.
+- Review recent commits and changes in the repository to trace back any suspicious activities or unauthorized access.
+- Terminate any suspicious processes identified as being executed from Git hooks to stop potential malicious activities.
+- Restore the affected system from a known good backup to ensure that any malicious changes are removed.
+- Implement strict access controls and permissions for Git repositories to limit who can modify hooks and other critical files.
+- Enhance logging and monitoring by enabling detailed audit logs for Git operations and shell command executions to detect future anomalies.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities.
+- Conduct a thorough review of user accounts and credentials to ensure no unauthorized access has been granted, and reset passwords if necessary.
+- Educate developers and system administrators on secure coding practices and the risks associated with Git hooks to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_git_hook_file_creation.toml b/rules/linux/persistence_git_hook_file_creation.toml
index 240262b8807..429f12e9a1f 100644
--- a/rules/linux/persistence_git_hook_file_creation.toml
+++ b/rules/linux/persistence_git_hook_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,49 @@ file.extension == null and process.executable != null and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Git Hook Created or Modified
+
+Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for workflow customization, adversaries can exploit them to maintain persistence by embedding malicious scripts. The detection rule identifies suspicious hook file changes on Linux systems, excluding benign processes, to flag potential unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Git hook file path that was created or modified, as indicated by the `file.path` field.
+- Verify the `process.executable` field to determine which process was responsible for the creation or modification of the Git hook file, and assess whether it is a known and trusted application.
+- Check the `event.type` field to confirm whether the event was a creation or modification, as this can provide context on whether a new hook was added or an existing one was altered.
+- Investigate the user account associated with the process by examining the process owner and any related user activity around the time of the event.
+- Use Osquery to gather additional context about the file and process. For example, run the following query to list all files in the `.git/hooks` directory and their metadata: `SELECT * FROM file WHERE path LIKE '/path/to/repo/.git/hooks/%';`
+- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious or unexpected scripts or commands.
+- Cross-reference the `process.name` field with known benign processes to ensure that the process responsible for the change is not typically associated with legitimate Git operations.
+- Review system logs and other security tools for any related suspicious activity or anomalies around the time of the Git hook modification.
+- Investigate any recent changes to the repository or system configuration that might explain the legitimate creation or modification of the Git hook.
+- Consult with the development or operations team to verify if the change was authorized and aligns with any recent updates or deployments.
+
+### False positive analysis
+
+- System package managers like `dpkg`, `rpm`, `yum`, and `dnf` may trigger false positives when they update or install packages that include Git hooks. These processes are typically benign and can be excluded by adding them to the exception list in the detection rule.
+- Container management tools such as `dockerd`, `podman`, and `microdnf` might modify Git hooks during container operations. These are generally safe and can be excluded by specifying their executables in the rule's exception criteria.
+- Automated system maintenance scripts or tools like `puppet`, `chef-client`, and `autossl_check` may create or modify Git hooks as part of their routine operations. Users can handle these by adding the specific process names or paths to the exclusion list.
+- Development tools and scripts, including `git`, `gitea`, and `git-lfs`, may modify hooks during normal development activities. These should be considered for exclusion if they are part of the regular development workflow.
+- Custom scripts or processes that are known and trusted within the organization might also trigger this rule. Users should review these cases and, if deemed safe, add them to the exception list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the unauthorized Git hook modification, examining recent changes and user activity logs.
+- Review the contents of the modified or newly created Git hook files to determine if malicious code is present and assess the potential impact.
+- Remove any unauthorized or malicious scripts found in the Git hook files and restore them to their original state if possible.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging for Git operations and file modifications on critical systems to improve future detection capabilities.
+- Integrate security tools with version control systems to monitor and alert on suspicious activities related to Git hooks.
+- Apply system hardening measures, such as restricting write permissions to the .git/hooks directory to trusted users only.
+- Educate developers and system administrators on the risks associated with Git hooks and best practices for securing them.
+- Review and update incident response plans to include specific procedures for handling Git hook-related security incidents, leveraging MITRE ATT&CK framework details for persistence and system process modification."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_git_hook_netcon.toml b/rules/linux/persistence_git_hook_netcon.toml
index 9e7e71207fd..2aea6cd0d19 100644
--- a/rules/linux/persistence_git_hook_netcon.toml
+++ b/rules/linux/persistence_git_hook_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,48 @@ sequence by host.id with maxspan=3s
    )
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Git Hook Egress Network Connection
+
+Git hooks are scripts triggered by Git events like commits or pushes, allowing automation of tasks. Adversaries can exploit these hooks to execute unauthorized commands, maintain persistence, or initiate network connections for data exfiltration. The detection rule identifies suspicious network activities by monitoring script executions from Git hooks and subsequent external network connections, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Git hook script involved by examining the `process.args` field for the path and name of the script.
+- Check the `process.name` field to determine which shell was used to execute the Git hook script, as this might provide insight into the attacker's familiarity with the environment.
+- Investigate the `destination.ip` field in the network event to identify the external IP address the connection was attempted to, and perform a reputation check on this IP address to assess its potential maliciousness.
+- Use the `process.entity_id` and `process.parent.entity_id` fields to correlate the process execution and network connection events, confirming the sequence of actions.
+- Examine the `host.id` field to identify the affected host and gather additional context about its role and importance within the network.
+- Utilize Osquery to gather more information about the Git configuration and hooks on the affected system. For example, run the following Osquery query to list all Git hooks present on the system: `SELECT path, content FROM file WHERE path LIKE '/path/to/repo/.git/hooks/%';`
+- Check the system's process execution history around the time of the alert to identify any other suspicious activities or processes that might be related.
+- Review the system logs for any unusual or unauthorized access attempts or changes around the time of the alert to identify potential indicators of compromise.
+- Investigate the user account associated with the process execution to determine if it has been compromised or if there are any signs of unauthorized access.
+- Analyze any additional network traffic from the affected host to identify other potential connections to suspicious or unauthorized external IP addresses.
+
+### False positive analysis
+
+- Legitimate automation scripts: Developers often use Git hooks for automation tasks such as triggering CI/CD pipelines or deploying applications. These scripts might initiate network connections to internal servers or cloud services, which could be flagged as suspicious. Users can handle these by creating exceptions for known and trusted scripts or IP addresses.
+- Internal network connections: Git hooks might connect to internal resources for tasks like fetching dependencies or updating configurations. These connections could be mistakenly identified as egress attempts. To manage this, users can exclude specific internal IP ranges or domains from the detection rule.
+- Development tools and integrations: Some development tools or integrations might use Git hooks to communicate with external services for legitimate purposes, such as code quality checks or notifications. Users should identify these tools and add them to an allowlist to prevent false positives.
+- Testing environments: In testing or staging environments, developers might intentionally use Git hooks to simulate network activities for testing purposes. Users can exclude these environments from monitoring or adjust the rule to account for known testing activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the specific Git hook script responsible for the suspicious activity and review its contents for malicious code.
+- Terminate any unauthorized processes initiated by the Git hook to halt ongoing malicious activities.
+- Analyze network logs to identify any external IP addresses contacted during the incident and block these addresses at the firewall level.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Restore the affected system from a known good backup to ensure the removal of any persistent threats.
+- Implement enhanced logging policies to capture detailed process execution and network connection attempts for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics, techniques, and procedures (TTPs).
+- Review and update Git hook permissions and configurations to limit execution to trusted scripts and users only.
+- Conduct a security awareness session for developers and system administrators on the risks associated with Git hooks and best practices for secure coding and configuration."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_git_hook_process_execution.toml b/rules/linux/persistence_git_hook_process_execution.toml
index 106d3ee1d5a..5f9d86f0d90 100644
--- a/rules/linux/persistence_git_hook_process_execution.toml
+++ b/rules/linux/persistence_git_hook_process_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 ) and not process.name in ("git", "dirname")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Git Hook Child Process
+
+Git hooks are scripts that automate tasks during Git operations like commits and pushes. While they enhance workflow efficiency, adversaries can exploit them to execute unauthorized commands by embedding malicious scripts. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts and executables, thus flagging potential misuse and aiding in threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Git hook that triggered the alert by examining the `process.parent.name` field.
+- Check the `process.name` and `process.executable` fields to determine the nature of the child process spawned by the Git hook and assess if it aligns with typical usage patterns.
+- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity is expected or if the account may have been compromised.
+- Use Osquery to list all Git hooks present in the repository to identify any unauthorized or suspicious scripts. Example query: `SELECT * FROM file WHERE path LIKE '/path/to/repo/.git/hooks/%';`
+- Examine the contents of the Git hook script that triggered the alert to identify any embedded malicious commands or unusual modifications.
+- Review recent commit history and changes in the repository to identify any unauthorized modifications that could indicate tampering with Git hooks.
+- Analyze the process tree to understand the sequence of events leading to the execution of the suspicious child process, focusing on the `process.parent.name` and `process.name` fields.
+- Check system logs for any additional context around the time of the alert, such as login events or other process executions, to correlate with the suspicious activity.
+- Investigate the network activity associated with the process by reviewing network logs or using network monitoring tools to identify any suspicious outbound connections.
+- Consult with the repository owner or development team to verify if the detected activity aligns with any recent changes or deployments, ensuring it is not a false positive.
+
+### False positive analysis
+
+- Developers often use custom scripts in Git hooks for legitimate purposes, such as automating testing or deployment processes, which may trigger the rule. To handle this, users can create exceptions for specific scripts or processes that are known to be safe and frequently used in their development environment.
+- Continuous Integration/Continuous Deployment (CI/CD) systems might execute scripts as part of their workflow, leading to false positives. Users should identify and whitelist these processes to prevent unnecessary alerts.
+- Some development environments or tools might use shell scripts or other scripting languages that match the rule's criteria. Users can exclude these known benign processes by adding them to an exception list, ensuring they are not flagged as suspicious.
+- In environments where developers frequently use temporary directories for legitimate purposes, processes executed from these locations might be flagged. Users should review and whitelist specific directories or processes that are consistently used for non-malicious activities.
+- If certain processes are consistently flagged but are known to be part of regular operations, users can adjust the rule to exclude these processes by adding them to the list of exceptions, ensuring that only truly suspicious activities are highlighted.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on the specific Git hooks and child processes flagged by the detection rule.
+- Review the contents of the Git hooks to identify any unauthorized or malicious scripts and remove them.
+- Analyze system logs and process execution history to trace the origin of the malicious activity and identify any additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Restore the system to a known good state by reinstalling the operating system and applications from trusted sources, ensuring all patches and updates are applied.
+- Implement enhanced logging policies to capture detailed process execution and network activity, aiding in future investigations.
+- Integrate security tools such as endpoint detection and response (EDR) solutions to monitor for similar threats and provide real-time alerts.
+- Educate development and operations teams on secure Git practices, emphasizing the importance of monitoring and controlling Git hook scripts.
+- Apply hardening measures by restricting write permissions to Git hook directories and implementing strict access controls to minimize the risk of unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_driver_load.toml b/rules/linux/persistence_kernel_driver_load.toml
index 97ba74fa43d..d6ddf5426a1 100644
--- a/rules/linux/persistence_kernel_driver_load.toml
+++ b/rules/linux/persistence_kernel_driver_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,49 @@ query = '''
 driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and
 auditd.data.syscall in ("init_module", "finit_module")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kernel Driver Load
+
+Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers and other components. Adversaries exploit this by loading malicious modules, or rootkits, to gain stealthy control over systems. The detection rule monitors system calls related to module loading, identifying suspicious activity by tracking specific actions indicative of unauthorized kernel modifications.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event action is "loaded-kernel-module" and verify the syscall involved is either "init_module" or "finit_module" as these are indicative of module loading.
+- Identify the specific kernel module that was loaded by examining the associated metadata in the alert, such as the module name or path, if available.
+- Check the timestamp of the event to determine when the module was loaded and correlate this with other system activities or logs around the same time for additional context.
+- Investigate the user or process that initiated the module load by examining the user ID and process ID fields in the alert to determine if it aligns with expected behavior or known legitimate processes.
+- Use Osquery to list all currently loaded kernel modules and their details to identify any unfamiliar or suspicious modules. Example query: `SELECT name, size, refcount, srcversion FROM kernel_modules;`
+- Cross-reference the loaded module with known good or bad modules by consulting threat intelligence sources or internal documentation to assess its legitimacy.
+- Analyze system logs, such as syslog or dmesg, for any additional messages or errors related to the module load event that could provide further insights.
+- Investigate the system's audit logs for any preceding or subsequent suspicious activities that might be related to the module load, such as unauthorized access attempts or privilege escalation.
+- Check for any recent changes to the system's configuration or installed software that could explain the module load, ensuring these changes are authorized and documented.
+- If the module is determined to be suspicious, consider conducting a deeper forensic analysis of the system to uncover any potential rootkits or other malicious activities that may have been facilitated by the module load.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the loading of kernel modules, leading to false positives. Users can manage this by creating exceptions for known and trusted software update processes.
+- Certain hardware drivers, such as those for graphics cards or network adapters, may load kernel modules during normal operation. To handle these, users can whitelist specific drivers or hardware-related processes that are known to be safe.
+- System administrators performing routine maintenance or configuration changes might load kernel modules, which could be flagged as suspicious. Users should document and exclude these activities from monitoring when performed by authorized personnel.
+- Security software or monitoring tools that interact with the kernel might also load modules as part of their normal function. Users can create exceptions for these tools by verifying their legitimacy and adding them to an exclusion list.
+- Custom or in-house developed applications that require kernel module loading for functionality might be misidentified as threats. Users should ensure these applications are properly documented and excluded from detection rules if they are verified as safe.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Use forensic tools to capture a memory dump and disk image of the affected system for further analysis.
+- Investigate the loaded kernel module by checking its origin, signature, and any associated files or processes to determine if it is malicious.
+- Cross-reference the module's details with known threat intelligence databases to identify any known rootkits or malicious actors.
+- If a rootkit is confirmed, remove the malicious module using safe methods such as rebooting into a clean environment and using trusted tools to unload the module.
+- Restore the system from a known good backup if the integrity of the system cannot be assured after module removal.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Implement enhanced logging policies to monitor for future unauthorized kernel module loads, including detailed audit logs of system calls and module activities.
+- Integrate with security information and event management (SIEM) systems to correlate module loading events with other suspicious activities across the network.
+- Apply system hardening measures such as disabling unnecessary kernel module loading, enforcing strict access controls, and regularly updating the system to patch vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_driver_load_by_non_root.toml b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
index 216b6be53ed..adab039beab 100644
--- a/rules/linux/persistence_kernel_driver_load_by_non_root.toml
+++ b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ query = '''
 driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and
 auditd.data.syscall in ("init_module", "finit_module") and user.id != "0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kernel Driver Load by non-root User
+
+Kernel modules extend the functionality of the Linux kernel, often requiring root privileges to load. Adversaries exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies non-root users attempting to load kernel modules via specific system calls, signaling potential unauthorized access or privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the non-root user involved in the kernel module loading attempt, focusing on the `user.id` field to determine the user account.
+- Examine the `auditd.data.syscall` field to confirm which system call was used (`init_module` or `finit_module`) and gather context on the specific action taken.
+- Check the timestamp of the event to correlate it with other system activities or logs that might provide additional context or indicate a pattern of suspicious behavior.
+- Investigate the source of the kernel module by reviewing the module's file path and name, if available, to determine if it is a known or legitimate module.
+- Use Osquery to list all currently loaded kernel modules and their details to identify any unfamiliar or suspicious modules. Example query: `SELECT name, size, used_by FROM kernel_modules;`
+- Cross-reference the non-root user's recent activities by reviewing system logs, such as `/var/log/auth.log` or `/var/log/secure`, to identify any unauthorized access or privilege escalation attempts.
+- Analyze the user's command history, if available, to check for any commands related to module loading or system modification that might indicate malicious intent.
+- Investigate the user's group memberships and permissions to assess whether they have been granted elevated privileges that could facilitate unauthorized module loading.
+- Review any recent changes to user accounts or group memberships in system logs to identify potential privilege escalation or account compromise.
+- Check for any related alerts or anomalies in the security monitoring system that might indicate a broader attack campaign or coordinated activity involving the same user or system.
+
+### False positive analysis
+
+- Non-root users with legitimate administrative privileges may load kernel modules as part of routine system maintenance or software installations, leading to false positives. 
+- Development environments where non-root users are testing kernel modules can trigger alerts; consider excluding specific users or processes associated with development activities.
+- Automated scripts or configuration management tools running under non-root accounts might load modules for legitimate purposes; identify and whitelist these processes to reduce noise.
+- Some security or monitoring tools may operate under non-root accounts and load kernel modules as part of their functionality; verify and exclude these tools to prevent unnecessary alerts.
+- To manage false positives, implement exceptions by creating a list of trusted users or processes that are known to load kernel modules for legitimate reasons, and adjust the detection rule to exclude these from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the identity and privileges of the non-root user attempting to load the kernel module to assess if the action was legitimate or malicious.
+- Conduct a thorough investigation of the loaded kernel module to determine its origin and functionality, focusing on identifying any rootkit characteristics.
+- Utilize forensic tools to capture and analyze memory and disk images from the affected system to identify any additional malicious activities or artifacts.
+- Review system logs and audit trails to trace the sequence of events leading to the module loading, identifying any potential privilege escalation or exploitation attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor is part of a larger campaign.
+- Remove the malicious kernel module and any associated files or processes from the system, ensuring that all backdoors or persistence mechanisms are eradicated.
+- Restore the system to a known good state using verified backups, ensuring that all security patches and updates are applied to prevent future exploitation.
+- Implement enhanced logging and monitoring policies, such as enabling auditd with specific rules to track kernel module loading and other critical system activities.
+- Strengthen system hardening measures by enforcing the principle of least privilege, disabling unnecessary services, and regularly reviewing user access rights to minimize the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_object_file_creation.toml b/rules/linux/persistence_kernel_object_file_creation.toml
index 4d95f4e8f37..939bda0303f 100644
--- a/rules/linux/persistence_kernel_object_file_creation.toml
+++ b/rules/linux/persistence_kernel_object_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ event.category:file and host.os.type:linux and event.type:creation and file.exte
   file.path:/var/tmp/mkinitramfs_* or process.executable:/snap/* or process.name:cpio
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kernel Object File Creation
+
+Kernel object files (.ko) are loadable modules that extend the functionality of the Linux kernel. Adversaries exploit these to deploy rootkits, granting them stealthy control over a system. The detection rule identifies suspicious .ko file creation, excluding benign paths like system updates, to flag potential threats aligned with persistence tactics, ensuring early detection of malicious kernel modifications.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a .ko file creation event, focusing on the `event.category:file`, `host.os.type:linux`, `event.type:creation`, and `file.extension:ko` fields.
+- Examine the file path of the .ko file to determine if it resides in a suspicious or unusual directory, excluding known benign paths like `/var/tmp/mkinitramfs_*`.
+- Investigate the process that created the .ko file by analyzing the `process.executable` and `process.name` fields to identify any unusual or unauthorized processes.
+- Check the file creation timestamp to correlate with any other suspicious activities or anomalies on the system around the same time.
+- Use Osquery to list all loaded kernel modules and identify any that are not part of the standard or expected set. Example query: `SELECT * FROM kernel_modules WHERE name = '<suspicious_module_name>';`
+- Cross-reference the .ko file's hash with known malware databases to check for any matches with known malicious kernel modules.
+- Investigate the user account under which the .ko file was created to determine if it has the necessary privileges and if the activity aligns with typical user behavior.
+- Review system logs for any additional context or anomalies around the time of the .ko file creation, such as login attempts, privilege escalations, or other file modifications.
+- Analyze network activity from the host around the time of the .ko file creation to identify any suspicious outbound connections or data exfiltration attempts.
+- Consult with system administrators or other relevant personnel to verify if the .ko file creation was part of a legitimate update or maintenance activity.
+
+### False positive analysis
+
+- System updates and kernel upgrades often involve the creation of legitimate .ko files, which can trigger false positives. Users can manage this by excluding paths associated with these updates, such as `/lib/modules/` or specific update processes.
+- Custom kernel module development and testing environments may also generate .ko files as part of normal operations. Developers should consider excluding directories or processes related to their development activities to prevent unnecessary alerts.
+- Some legitimate software installations or updates might temporarily create .ko files in non-standard locations. Users should monitor and identify these patterns, then create exceptions for known benign software to reduce false positives.
+- Automated backup or recovery processes might involve the creation of .ko files, especially if they involve system snapshots or similar operations. Identifying these processes and excluding them can help in minimizing false alerts.
+- Users should regularly review and update their exclusion lists to ensure they reflect the current environment and operational needs, thus maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the .ko file creation, examining recent system changes, user activity, and any unauthorized access.
+- Utilize forensic tools to analyze the .ko file for malicious code or rootkit characteristics, and determine the extent of the compromise.
+- Remove the malicious .ko file and any associated malware or unauthorized kernel modules from the system.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring that the backup is free from compromise.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed file creation events, process executions, and network activity for future investigations.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.
+- Review and update security policies and hardening measures, such as disabling unnecessary kernel module loading and enforcing strict access controls, to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_lkm_configuration_file_creation.toml b/rules/linux/persistence_lkm_configuration_file_creation.toml
index ba7808de531..64f58edf954 100644
--- a/rules/linux/persistence_lkm_configuration_file_creation.toml
+++ b/rules/linux/persistence_lkm_configuration_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,57 @@ file.path like~ (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Loadable Kernel Module Configuration File Creation
+
+Loadable Kernel Modules (LKMs) allow dynamic loading of code into the Linux kernel, enhancing functionality without rebooting. Adversaries exploit this by creating or altering LKM configuration files to ensure malicious modules load at startup, achieving persistence. The detection rule identifies suspicious file creation or renaming in key directories, excluding benign processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process executable involved in the suspicious file creation or renaming event.
+- Verify the legitimacy of the process executable by checking its hash against known good hashes or using a threat intelligence database to identify any known malicious signatures.
+- Use Osquery to list all currently loaded kernel modules and check for any unfamiliar or suspicious modules:
+  ```sql
+  SELECT name, size, used_by FROM kernel_modules;
+  ```
+- Investigate the file path where the LKM configuration file was created or renamed to determine if it aligns with typical system behavior or if it appears out of place.
+- Examine the process tree to understand the parent process and any child processes associated with the suspicious executable, which may provide context on how the file creation was initiated.
+- Check system logs, such as `/var/log/syslog` or `/var/log/messages`, for any related entries around the time of the alert to gather additional context on the event.
+- Use Osquery to identify any recent changes to the system's module directories that might indicate tampering:
+  ```sql
+  SELECT path, size, atime, mtime, ctime FROM file WHERE path LIKE '/etc/modules%' OR path LIKE '/etc/modprobe.d/%';
+  ```
+- Investigate the user account under which the process was executed to determine if it has the necessary privileges to modify LKM configuration files and if the activity aligns with the user's typical behavior.
+- Cross-reference the alert with any other recent alerts or incidents involving the same host or process to identify potential patterns or correlations.
+- Consult with system administrators or the asset owner to verify if the file creation or modification was part of a legitimate change or update to the system.
+
+### False positive analysis
+
+- System package managers such as `dpkg`, `rpm`, `yum`, and `dnf` may create or modify LKM configuration files during routine updates or installations, which are benign activities. Users can handle these by ensuring these processes are included in the exclusion list of the detection rule.
+- Container management tools like `dockerd` and `podman` might also trigger false positives when managing containerized environments. Excluding these executables from the rule can prevent unnecessary alerts.
+- Automation and configuration management tools such as `puppet`, `chef-client`, and `ansible` may modify LKM configuration files as part of their normal operations. Users should verify these processes and add them to the exclusion list if they are part of legitimate activities.
+- Temporary files created by text editors (e.g., files with extensions like `.swp`, `.swpx`, `.swx`) during editing sessions can be mistakenly flagged. Excluding these file extensions can reduce false positives.
+- Processes running from specific directories like `/nix/store/*` or `/snap/*` may be part of legitimate software installations or updates. Users should review these paths and consider excluding them if they are known to be safe.
+- Scheduled tasks or cron jobs executed by processes like `crond` or `anacron` might modify LKM configuration files as part of system maintenance. Users should assess these activities and exclude them if they are verified as non-threatening.
+- Users can manage false positives by regularly reviewing and updating the exclusion list to reflect changes in their environment, ensuring that only verified benign processes and paths are excluded from the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the malicious loadable kernel module.
+- Conduct a thorough investigation to identify the source of the LKM configuration file creation or modification, focusing on the process and user account involved.
+- Review system logs and security alerts to gather additional context and determine if other systems are affected.
+- Remove the malicious LKM and any associated configuration files from the system to eliminate persistence mechanisms.
+- Restore the system to a known good state using backups or system snapshots, ensuring that the restored state is free from compromise.
+- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed information on file creation and modification events, especially in critical directories.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on security best practices and the importance of monitoring for unauthorized changes to system configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation.toml b/rules/linux/persistence_pluggable_authentication_module_creation.toml
index fd3e0bb6fd6..606ff3d6dca 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,50 @@ process.executable != null and (
   (process.name == "perl" and file.name like~ "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation or Modification of Pluggable Authentication Module or Configuration
+
+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 key PAM directories, excluding benign processes, to flag unauthorized changes indicative of potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process executable involved in the creation or modification event. Pay special attention to the `file.path` and `process.executable` fields.
+- Verify the legitimacy of the process executable by checking its hash against known good hashes or using a threat intelligence platform to determine if it is associated with known malicious activity.
+- Use Osquery to list all PAM modules and their metadata to identify any recent changes or anomalies. Example query: `SELECT * FROM file WHERE path LIKE '/lib/security/%' OR path LIKE '/etc/pam.d/%';`
+- Investigate the user account associated with the process that triggered the alert to determine if it has been compromised or is being used maliciously.
+- Check the system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any suspicious authentication attempts or errors around the time of the alert.
+- Examine the process tree to understand the parent and child processes of the executable involved in the alert. This can help identify if the process was spawned by a legitimate service or a malicious script.
+- Review recent system changes or package installations that might have legitimately modified PAM configurations, using package management logs or history commands.
+- Analyze network activity from the host to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
+- Cross-reference the alert with other security events or alerts from the same host to identify patterns or correlations that might indicate a broader attack campaign.
+- Consult with system administrators or application owners to verify if the changes were authorized or part of a scheduled update or maintenance activity.
+
+### False positive analysis
+
+- Routine system updates or package installations can trigger this rule, as legitimate package managers like `dpkg`, `rpm`, `yum`, and `apt` may modify PAM-related files. Users can handle these by ensuring that the processes associated with these package managers are included in the exclusion list.
+- Automated system management tools such as Puppet, Chef, or Ansible might also modify PAM configurations as part of their normal operations. Users should verify these activities and add the relevant process executables to the exclusion list if deemed non-threatening.
+- Temporary files created during legitimate software installations or updates, such as those with extensions like `swp`, `swpx`, or `dpkg-remove`, can be mistaken for suspicious activity. Users can exclude these extensions to reduce false positives.
+- Certain system maintenance scripts or tools, like `sed` or `perl`, may create temporary files that match the rule's criteria. Users should review these activities and consider excluding specific file names or patterns associated with these tools.
+- Snap package installations or updates may involve temporary paths like `/tmp/snap.rootfs_*`, which could be flagged by the rule. Users can exclude these paths if they are confident in the benign nature of the activities.
+- In environments using the Nix package manager, paths under `/nix/store/*` may be involved in legitimate PAM file modifications. Users should assess these activities and exclude the relevant paths if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify any unauthorized PAM module or configuration changes, using forensic tools to analyze file integrity and system logs.
+- Review recent user account activity and authentication logs to identify any suspicious login attempts or credential harvesting.
+- Restore any modified or unauthorized PAM files from a known good backup to ensure system integrity.
+- Update all system and application software to the latest versions to patch any known vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed authentication and file modification events, ensuring logs are stored securely and monitored regularly.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting access to PAM directories, enforcing strong authentication policies, and conducting regular security audits."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
index 34f323e749b..637b0272c95 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,52 @@ file where host.os.type == "linux" and event.type == "creation" and file.name li
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 (PAM) Creation in Unusual Directory
+
+Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and name of the PAM shared object file created, focusing on the `file.name` and `file.path` fields.
+- Verify the process responsible for creating the file by examining the `process.name` field to determine if it matches any known benign processes or if it appears suspicious.
+- Check the timestamp of the file creation event to correlate it with other system activities or anomalies that occurred around the same time.
+- Investigate the parent process of the file creation event to understand the context and origin of the action, using process lineage information if available.
+- Use Osquery to list all PAM modules on the system and their locations to identify any other unusual or unauthorized modules:
+  ```sql
+  SELECT * FROM file WHERE path LIKE '/%/pam_*.so';
+  ```
+- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication-related anomalies or errors that coincide with the file creation event.
+- Check for any recent user account changes or privilege escalations that might indicate unauthorized access or manipulation.
+- Investigate the network activity of the host around the time of the alert to identify any suspicious connections or data exfiltration attempts.
+- Review the system's history of software installations and updates to rule out legitimate software that might have created the PAM module.
+- Assess the integrity of other critical system files and configurations to ensure no further unauthorized modifications have been made.
+
+### False positive analysis
+
+- **Development and Testing Environments**: In environments where developers or system administrators are testing PAM modules, files may be created in non-standard directories temporarily. Users can handle these by excluding specific directories used for development and testing from the detection rule.
+- **Containerized Applications**: Applications running in containers might create PAM modules in unusual directories as part of their normal operation. Users can exclude paths related to container environments, such as those under `/var/lib/containerd` or `/home/*/.local/share/containers`, to reduce false positives.
+- **Package Management and System Updates**: Some package managers or system update processes might temporarily create PAM modules in non-standard directories before moving them to the correct location. Users can exclude processes like `pacman` or paths related to package management, such as `/nix/store/*`, to prevent these from triggering alerts.
+- **Custom Security Solutions**: Organizations with custom security solutions might have legitimate PAM modules in non-standard directories. Users should identify and exclude these specific paths or processes to avoid false positives.
+- **Temporary File Creation**: Some legitimate processes might create temporary PAM files in directories like `/tmp` or `/var/tmp` during their operation. Users can exclude these directories or specific processes known to create temporary files to minimize false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the malicious PAM module creation, including reviewing recent user activity and process logs.
+- Remove any unauthorized PAM modules found in unusual directories and verify the integrity of legitimate PAM modules in standard directories.
+- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed file creation events and process activities, ensuring that logs are stored securely and monitored regularly.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
+- Harden the system by implementing least privilege access controls, disabling unused services, and regularly auditing PAM configurations and modules."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_source_download.toml b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
index c80244fef6e..674787295d3 100644
--- a/rules/linux/persistence_pluggable_authentication_module_source_download.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,52 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name in ("curl", "wget") and
 process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 (PAM) Source Download
+
+Pluggable Authentication Modules (PAM) are integral to Linux systems, providing a flexible mechanism for authenticating users. Adversaries may exploit PAM by downloading its source code to modify authentication processes, potentially creating backdoors. The detection rule identifies suspicious downloads of PAM source files using tools like `curl` or `wget`, signaling potential attempts to tamper with authentication mechanisms.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `curl` or `wget` in the `process.name` field and verify the URL pattern in `process.args` to ensure it matches the known PAM source download URL.
+- Check the `host.os.type` field to confirm the operating system is Linux, as this rule is specific to Linux environments.
+- Investigate the `event.type` and `event.action` fields to ensure the process was indeed started and executed, indicating an actual download attempt.
+- Examine the user account associated with the process to determine if the activity aligns with expected behavior or if it is potentially malicious.
+- Use Osquery to list all PAM modules currently installed on the system to identify any unauthorized or suspicious modules:
+  ```sql
+  SELECT * FROM pam_modules;
+  ```
+- Analyze the network logs to identify any other suspicious outbound connections from the host around the time of the alert.
+- Review the system's process execution history to identify any subsequent actions taken by the same user or process that downloaded the PAM source.
+- Check for any recent changes to PAM configuration files, such as `/etc/pam.d/`, to detect unauthorized modifications.
+- Investigate the file system for any downloaded PAM source files or extracted contents, focusing on directories typically used for temporary storage or user downloads.
+- Correlate this event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- System administrators or developers may legitimately download PAM source files for testing, development, or educational purposes, which could trigger the detection rule. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform these activities regularly.
+- Automated scripts or configuration management tools that update or install software packages might download PAM source files as part of their routine operations. Users can handle these by excluding specific processes or scripts from triggering the rule.
+- Security researchers or auditors conducting vulnerability assessments might download PAM source files to analyze potential security issues. Organizations can whitelist these activities by identifying and excluding the researchers' user accounts or IP addresses.
+- Some Linux distributions or custom setups might include scripts that download PAM source files for building or updating packages. Users should identify these scripts and add them to an exception list to prevent false positives.
+- In educational environments, students might download PAM source files as part of their coursework. Institutions can manage this by excluding specific user groups or network segments associated with educational activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the download of the PAM source code and identify any modifications made to the authentication modules.
+- Review system logs and process execution history to trace the origin of the suspicious activity and identify any other potentially compromised systems.
+- Remove any unauthorized or malicious PAM modules and restore the original, verified versions from trusted sources.
+- Change all passwords and authentication credentials that may have been exposed or compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for PAM-related activities, including downloads and modifications, to detect future attempts at unauthorized access.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities related to PAM.
+- Restore the system to its operational state by applying security patches, updating software, and ensuring all configurations adhere to security best practices.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
index bdc886bc4f7..9f9e90302a0 100644
--- a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
+++ b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -82,6 +82,49 @@ process.args : (
   (process.name == "install" and process.args : "-m*" and process.args : ("7*", "5*", "3*", "1*"))
 ) and not process.parent.executable : "/var/lib/dpkg/*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Executable Bit Set for Potential Persistence Script
+
+In Linux environments, scripts can be set to execute automatically by setting the executable bit, a feature often exploited by adversaries to maintain persistence. Attackers may place scripts in directories typically used for startup processes, ensuring their code runs at boot or scheduled intervals. The detection rule identifies suspicious use of commands like `chmod` or `install` to set executable permissions on scripts in these sensitive directories, flagging potential persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific script path and the command used to set the executable bit, focusing on the `process.args` field to understand the exact operation performed.
+- Check the `process.parent.executable` field to determine the parent process that initiated the command, which can provide context on whether the action was part of a legitimate process or potentially malicious.
+- Use Osquery to list all files in the directory where the script is located to identify any other suspicious files or scripts. Example query: `SELECT * FROM file WHERE directory = '/path/to/suspicious/directory';`
+- Investigate the user account associated with the process by examining the `process.user.name` field to determine if the account has a history of suspicious activity or if it has been compromised.
+- Analyze the script content by accessing the file directly to understand its purpose and whether it contains any malicious code or commands.
+- Cross-reference the script's hash with known malware databases to check if it matches any known malicious scripts.
+- Review system logs around the time of the alert to identify any other unusual activities or related events that could provide additional context.
+- Check for any recent changes in the system's startup configuration files or directories, as these could indicate attempts to establish persistence.
+- Use Osquery to query the system's cron jobs and scheduled tasks to identify any unauthorized or suspicious entries. Example query: `SELECT * FROM crontab WHERE command LIKE '%/path/to/suspicious/script%';`
+- Investigate network connections initiated by the host around the time of the alert to identify any potential communication with known malicious IP addresses or domains.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use `chmod` or `install` commands to set executable permissions on scripts for legitimate purposes, such as system maintenance or software updates. These actions can trigger alerts if they occur in directories monitored by the rule.
+- Automated software updates: Some software packages may automatically update themselves by modifying scripts in startup directories, which can be mistaken for persistence attempts.
+- Custom user scripts: Users may create personal scripts in their home directories for convenience, which could be flagged if they are set to execute at startup.
+- To manage these false positives, users can create exceptions for known benign processes or directories by updating the detection rule to exclude specific paths or parent processes that are verified as non-threatening.
+- Regularly review and update the list of exceptions to ensure that legitimate activities are not inadvertently flagged while maintaining the integrity of the detection system.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Conduct a thorough investigation to identify the script's origin, purpose, and any associated processes or files. Use forensic tools to analyze the script and its execution history.
+- Review system logs and security alerts to determine if there are any other indicators of compromise or related activities on the system.
+- Remove the malicious script and any associated files or processes. Ensure that the executable bit is removed from any unauthorized scripts.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring that the backup is free from any malicious modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a larger attack campaign.
+- Implement enhanced logging and monitoring policies to capture detailed information on file permission changes and script executions, aiding in future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
+- Apply system hardening measures, such as restricting write permissions to sensitive directories and using access control lists (ACLs) to limit script execution.
+- Educate users and administrators on the risks of unauthorized script execution and the importance of maintaining secure configurations and practices."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_process_capability_set_via_setcap.toml b/rules/linux/persistence_process_capability_set_via_setcap.toml
index 8da24d32de4..91bb8998ea6 100644
--- a/rules/linux/persistence_process_capability_set_via_setcap.toml
+++ b/rules/linux/persistence_process_capability_set_via_setcap.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/06/03"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,52 @@ process.name == "setcap" and not (
   process.parent.name in ("jem", "vzctl")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Capability Set via setcap Utility
+
+The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit `setcap` to maintain persistence or escalate privileges by misconfiguring binaries. The detection rule identifies suspicious `setcap` usage by monitoring process execution, excluding benign parent processes, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "setcap" and the event type is "start" with actions "exec" or "exec_event".
+- Verify the parent process executable path and name to ensure it is not in the excluded list (e.g., "/var/lib/dpkg/*", "/var/lib/docker/*", "/tmp/newroot/*", "/var/tmp/newroot/*", "jem", "vzctl").
+- Check the user context under which the "setcap" command was executed to determine if it aligns with expected administrative activities.
+- Investigate the specific capabilities that were set by the "setcap" command to assess if they are necessary and appropriate for the binary.
+- Use Osquery to list all files with capabilities set on the system to identify any other potentially suspicious binaries:
+  ```sql
+  SELECT path, capabilities FROM file WHERE capabilities IS NOT NULL;
+  ```
+- Examine the command-line arguments used with "setcap" to understand the intent and scope of the capability changes.
+- Cross-reference the timestamp of the "setcap" execution with other system logs to identify any correlated suspicious activities.
+- Investigate the history of the binary on which capabilities were set to determine if it has been recently modified or replaced.
+- Review user activity logs around the time of the "setcap" execution to identify any anomalous behavior or unauthorized access.
+- Assess the system for any signs of persistence mechanisms or privilege escalation attempts that may have been established using the modified binary.
+
+### False positive analysis
+
+- Known false positives for the Process Capability Set via setcap Utility rule often arise from legitimate administrative tasks where system administrators use `setcap` to configure capabilities for system binaries or custom applications. These actions are typically benign and part of routine system maintenance.
+- Another source of false positives can be automated scripts or configuration management tools that use `setcap` as part of their deployment or configuration processes. These tools might run regularly and trigger the detection rule.
+- To manage these false positives, users can create exceptions for specific parent processes or paths that are known to be safe. For instance, if a particular script or tool frequently uses `setcap` and is verified to be non-malicious, its parent process name or executable path can be added to the exclusion list.
+- Users should regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity. This involves monitoring for any changes in legitimate processes that use `setcap` and adjusting the rule accordingly.
+- It's important to maintain a balance between reducing false positives and ensuring that potential threats are not overlooked. Regular audits and reviews of the exceptions can help maintain this balance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on any binaries with altered capabilities and reviewing recent `setcap` command executions.
+- Remove any unauthorized capabilities set on binaries by using the `setcap` command to reset them to their default state.
+- Review and update user permissions and access controls to ensure that only authorized personnel can modify capabilities on executables.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging for process execution and `setcap` usage to improve detection of similar activities in the future.
+- Integrate security information and event management (SIEM) solutions to correlate events and provide better visibility into potential threats.
+- Restore the system to its operational state by verifying the integrity of critical system files and reinstalling any compromised software from trusted sources.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface.
+- Educate users and administrators on the risks associated with misconfigured capabilities and the importance of maintaining secure configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_rc_local_error_via_syslog.toml b/rules/linux/persistence_rc_local_error_via_syslog.toml
index 6a62b00b786..a449c6a256f 100644
--- a/rules/linux/persistence_rc_local_error_via_syslog.toml
+++ b/rules/linux/persistence_rc_local_error_via_syslog.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,47 @@ query = '''
 host.os.type:linux and event.dataset:system.syslog and process.name:rc.local and
 message:("Connection refused" or "No such file or directory" or "command not found")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious rc.local Error Message
+
+The rc.local script is crucial in Linux systems, executing commands at boot. Adversaries may exploit this by inserting malicious scripts to gain persistence. The detection rule monitors syslog for specific error messages linked to rc.local, such as "Connection refused," indicating potential tampering. This helps identify unauthorized modifications, aligning with MITRE ATT&CK's persistence tactics.
+
+### Possible investigation steps
+
+- Review the syslog entries around the time of the alert to gather more context about the suspicious error message and identify any other related log entries.
+- Verify the integrity of the rc.local file by comparing its current state with a known good backup or using a file integrity monitoring tool to check for unauthorized changes.
+- Use Osquery to list the current contents of the rc.local file with the query: `SELECT * FROM file WHERE path='/etc/rc.local';` to identify any suspicious or unexpected entries.
+- Investigate the process tree to identify any parent or child processes related to rc.local using the query fields `process.name:rc.local` and `host.os.type:linux` to trace the execution flow.
+- Check for recent modifications to the rc.local file by examining the file's metadata, such as the last modified timestamp, using `ls -l /etc/rc.local` or an equivalent command.
+- Search for any recent user account activity or privilege escalations around the time of the alert that could indicate unauthorized access or changes to the rc.local file.
+- Analyze network logs for any unusual outbound connections or failed connection attempts that coincide with the "Connection refused" error message.
+- Review the system's boot logs to identify any anomalies or errors during the startup process that could be related to the rc.local script execution.
+- Investigate other system logs for any additional error messages like "No such file or directory" or "command not found" that might provide further context on the issue.
+- Correlate the findings with known MITRE ATT&CK techniques, specifically focusing on persistence tactics, to determine if the activity aligns with known adversary behaviors.
+
+### False positive analysis
+
+- Routine administrative tasks or legitimate software updates may trigger error messages like "No such file or directory" if certain expected files are temporarily unavailable during the update process. Users can handle these by creating exceptions for known maintenance windows or specific update processes.
+- Custom scripts or applications that are intentionally executed at boot but occasionally fail due to misconfigurations might generate "command not found" errors. Users should review these scripts and, if deemed non-threatening, exclude them from triggering alerts by specifying the script names or paths in the exception list.
+- Network-related services that are not yet fully initialized during the boot process might cause "Connection refused" errors. Users can mitigate these false positives by adjusting the timing of service startups or excluding specific network services from the rule if they are known to cause such errors without security implications.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of malicious activity.
+- Conduct a thorough investigation of the rc.local file to identify any unauthorized modifications or suspicious entries.
+- Review system logs, particularly syslog, to trace the origin of the suspicious activity and identify any other affected systems or files.
+- Restore the rc.local file from a known good backup if available, ensuring that it is free from any unauthorized changes.
+- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could have been exploited.
+- Implement strict access controls and permissions for critical system files like rc.local to prevent unauthorized modifications.
+- Enhance logging policies to ensure comprehensive monitoring of system changes and potential security incidents, integrating with SIEM solutions for real-time alerts.
+- Conduct a security audit of the system to identify and address any other potential security weaknesses or misconfigurations.
+- Escalate the incident to the security operations team or relevant authorities if the investigation reveals a broader threat or compliance breach.
+- Educate and train staff on recognizing and responding to security incidents, emphasizing the importance of maintaining system integrity and vigilance against persistence tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_rc_local_service_already_running.toml b/rules/linux/persistence_rc_local_service_already_running.toml
index 0027fc21226..b9a69a22a4f 100644
--- a/rules/linux/persistence_rc_local_service_already_running.toml
+++ b/rules/linux/persistence_rc_local_service_already_running.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,49 @@ query = '''
 process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and 
 process.parent.args == "/etc/rc.local" and process.parent.args == "start"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Execution of rc.local Script
+
+The `/etc/rc.local` script is a legacy Linux initialization script executed at the end of the boot process. While not enabled by default, attackers can exploit it to run malicious commands persistently at startup. The detection rule identifies potential misuse by monitoring for the `already_running` event action linked to `rc-local.service`, indicating the script's execution, thus alerting to possible unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `already_running` event action associated with the `rc-local.service` systemd service, indicating potential execution of the `/etc/rc.local` script.
+- Verify the system's configuration to determine if the `/etc/rc.local` script is enabled and check for any recent modifications to the file by examining its last modified timestamp.
+- Use Osquery to list the contents of the `/etc/rc.local` file to identify any suspicious or unauthorized commands or scripts. Example query: `SELECT * FROM file WHERE path = '/etc/rc.local';`
+- Investigate the parent process details captured in the alert, specifically focusing on `process.parent.args` to understand the context in which the `/etc/rc.local` script was executed.
+- Check system logs, such as `/var/log/syslog` or `/var/log/messages`, for any entries around the time of the alert that might provide additional context or indicate other suspicious activities.
+- Examine the system's boot logs, such as `journalctl -b`, to identify any anomalies or errors during the boot process that could be related to the execution of the `/etc/rc.local` script.
+- Investigate user accounts and permissions to determine if unauthorized users have access to modify or execute the `/etc/rc.local` script.
+- Review recent changes to system services and startup scripts to identify any unauthorized modifications that could indicate persistence mechanisms.
+- Use Osquery to check for other persistence mechanisms on the system, such as cron jobs or other startup scripts, that might be used in conjunction with the `/etc/rc.local` script. Example query: `SELECT * FROM crontab;`
+- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- The execution of legitimate administrative scripts or maintenance tasks via `/etc/rc.local` can trigger false positives. System administrators may use this script for benign purposes, such as configuring network settings or starting essential services at boot.
+- Some Linux distributions or custom configurations might still rely on `/etc/rc.local` for legitimate startup processes, leading to alerts that are not indicative of malicious activity.
+- To manage these false positives, users can create exceptions for known and verified scripts or commands within `/etc/rc.local` by specifying them in the detection rule's exclusion list.
+- Regularly review and update the exclusion list to ensure that only trusted and necessary scripts are allowed, minimizing the risk of overlooking potential threats.
+- Consider implementing additional monitoring or logging for `/etc/rc.local` modifications to quickly identify unauthorized changes that could indicate malicious intent.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious scripts.
+- Conduct a thorough investigation to identify any unauthorized changes to the `/etc/rc.local` script and review the script's contents for malicious commands.
+- Check system logs and use forensic tools to trace the origin of the unauthorized changes and identify any other compromised systems.
+- Remove any malicious entries from the `/etc/rc.local` script and restore it to its default state if necessary.
+- Apply patches and updates to the operating system and installed software to mitigate known vulnerabilities that could have been exploited.
+- Implement strict access controls and permissions for critical system files, including `/etc/rc.local`, to prevent unauthorized modifications.
+- Enhance logging and monitoring by enabling detailed audit logs for system changes and integrating with a centralized logging solution for real-time alerts.
+- Consider deploying additional security tools, such as host-based intrusion detection systems (HIDS), to detect and prevent similar threats in the future.
+- Escalate the incident to the security team or relevant authorities if the investigation reveals a broader compromise or if sensitive data has been accessed.
+- Educate users and administrators on security best practices and the importance of monitoring for unusual system behavior to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
index ae85b369470..317ee7db8ad 100644
--- a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,49 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:rpm and
 process.args:("-i" or "--install")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 RPM Package Installed by Unusual Parent Process
+
+RPM is a crucial package management tool in Linux systems like Red Hat and CentOS, facilitating software installation and updates. Adversaries may exploit RPM by installing backdoored or malicious packages to gain persistence or initial access. The detection rule identifies anomalies by flagging RPM installations initiated by atypical parent processes, signaling potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and timestamp of the RPM installation event.
+- Examine the parent process of the RPM installation using the `process.parent.name` and `process.parent.pid` fields to determine if it is indeed unusual or suspicious.
+- Check the command-line arguments used during the RPM installation by reviewing the `process.args` field to understand what package was being installed.
+- Investigate the user account associated with the RPM installation event using the `user.name` field to determine if the action was authorized or expected.
+- Use Osquery to list all RPM packages installed on the host and identify any recent additions or modifications. Example query: `SELECT name, version, release, install_time FROM rpm_packages WHERE install_time > strftime('%s', '2023-10-01');`
+- Cross-reference the installed package name and version with known repositories or package signatures to verify its legitimacy.
+- Analyze the network activity around the time of the RPM installation to identify any unusual outbound or inbound connections that could indicate data exfiltration or command-and-control activity.
+- Review system logs for any other suspicious activities or errors around the time of the RPM installation to gather additional context.
+- Check for any recent privilege escalation events on the host that could have allowed an adversary to perform the RPM installation.
+- Consult threat intelligence sources to determine if the package or the parent process is associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- System administrators or automated scripts may frequently install or update RPM packages as part of routine maintenance, which could trigger the rule if these actions are initiated by non-standard parent processes like custom scripts or management tools.
+- Development environments often use containerization or virtualization tools that might execute RPM installations through atypical parent processes, leading to false positives.
+- Security or monitoring tools that perform regular checks or updates on system packages might also appear as unusual parent processes when executing RPM commands.
+- To manage these false positives, users can create exceptions for known benign parent processes by adding them to an allowlist, ensuring that routine administrative tasks or automated processes do not trigger alerts.
+- Regularly review and update the list of excluded parent processes to adapt to changes in system management practices or toolsets, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the parent process that initiated the RPM installation by reviewing process logs and correlating with known benign activities.
+- Conduct a thorough investigation to identify any malicious RPM packages installed, using file integrity monitoring and package verification tools.
+- Remove any identified malicious or unauthorized RPM packages and replace them with verified, clean versions from trusted repositories.
+- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if the threat actor's identity and intent are unclear.
+- Implement enhanced logging policies to capture detailed process execution data, including parent-child process relationships, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all software is up-to-date.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_shadow_file_modification.toml b/rules/linux/persistence_shadow_file_modification.toml
index ae90763ce34..a8389910b6c 100644
--- a/rules/linux/persistence_shadow_file_modification.toml
+++ b/rules/linux/persistence_shadow_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,49 @@ query = '''
 file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and
 file.path == "/etc/shadow" and file.Ext.original.path != null
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Shadow File Modification
+
+The shadow file in Linux systems securely stores hashed user passwords, crucial for system authentication. Adversaries may exploit this by altering the file to add users or change passwords, ensuring persistent access. The detection rule identifies suspicious modifications by monitoring changes and renames of the shadow file, signaling potential unauthorized account manipulation activities.
+
+### Possible investigation steps
+
+- Verify the alert details, including the timestamp and the host where the modification was detected, to understand the context of the event.
+- Check the user account associated with the event to determine if it is a legitimate system administrator or a potential threat actor.
+- Review recent login activity on the affected host to identify any unusual or unauthorized access attempts around the time of the shadow file modification.
+- Use Osquery to list all users on the system and check for any newly added or suspicious accounts. Example query: `SELECT * FROM users WHERE uid >= 1000;`
+- Investigate the process tree to identify any processes that were running at the time of the modification, which might indicate the tool or method used for the change.
+- Examine the system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any entries that correlate with the time of the shadow file modification.
+- Check for any recent changes to the `/etc/passwd` file, as modifications here might accompany changes to the shadow file.
+- Review the file integrity monitoring logs to see if there are any other unauthorized changes to critical system files.
+- Investigate any network connections from the host around the time of the event to identify potential command and control activity.
+- Correlate the event with other security alerts or incidents in the environment to determine if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- Routine system updates or administrative tasks may trigger legitimate changes to the shadow file, such as when a system administrator updates user passwords or adds new users as part of regular maintenance.
+- Automated scripts or configuration management tools like Ansible, Puppet, or Chef that manage user accounts and passwords can also cause expected modifications to the shadow file.
+- To manage these false positives, users can create exceptions for known administrative activities or trusted scripts by correlating the changes with scheduled maintenance windows or specific user actions.
+- Implementing a whitelist of trusted processes or users that are allowed to modify the shadow file can help reduce noise from expected changes.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the integrity of the shadow file by comparing it with a known good backup, if available, to identify unauthorized changes.
+- Conduct a thorough investigation to identify any unauthorized user accounts or password changes and remove or reset them as necessary.
+- Review system logs and security alerts to trace the source of the modification and determine if other systems may be compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Restore the shadow file from a secure backup if unauthorized changes are confirmed and ensure all legitimate user accounts are intact.
+- Implement enhanced logging and monitoring for critical system files, including the shadow file, to detect future unauthorized modifications.
+- Integrate with security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Apply system hardening measures, such as enforcing strong password policies and disabling unnecessary services, to reduce the attack surface.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans and procedures accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_shell_configuration_modification.toml b/rules/linux/persistence_shell_configuration_modification.toml
index 95de3e6a32b..07212e3a970 100644
--- a/rules/linux/persistence_shell_configuration_modification.toml
+++ b/rules/linux/persistence_shell_configuration_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -98,6 +98,51 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Shell Configuration Creation or Modification
+
+Shell configuration files in Unix systems are crucial for setting up user environments, including environment variables and command aliases. Adversaries exploit these files to execute malicious scripts and maintain persistence. The detection rule identifies suspicious creation or modification of these files, excluding legitimate processes and temporary files, to flag potential unauthorized changes indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific shell configuration file that was created or modified, using the `file.path` field from the query.
+- Check the `event.action` field to determine whether the file was newly created or renamed, which can provide context on the nature of the change.
+- Investigate the `process.executable` field to identify the process responsible for the file modification, ensuring it is not part of the excluded legitimate processes.
+- Examine the `process.name` field to gather more information about the process that triggered the alert, especially if it is not part of the known exclusions.
+- Use Osquery to list recent modifications to shell configuration files with a query like: `SELECT path, mtime FROM file WHERE path IN ('/etc/profile', '/etc/bash.bashrc', '/home/*/.bashrc', '/root/.bashrc') ORDER BY mtime DESC LIMIT 10;` to verify the alert and gather additional context.
+- Cross-reference the `process.executable` and `process.name` with known malicious binaries or scripts to assess potential threats.
+- Check the `file.extension` and `file.Ext.original.extension` fields to ensure the file is not a temporary or transitional file, which might be benign.
+- Investigate the user account associated with the file modification to determine if the activity aligns with expected behavior for that user.
+- Review system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader compromise.
+- Analyze the contents of the modified shell configuration file to identify any unauthorized or suspicious entries, such as unexpected scripts or commands that could indicate persistence mechanisms.
+
+### False positive analysis
+
+- **Package Management Tools**: Actions by package managers like `dpkg`, `rpm`, `yum`, and `apt` can trigger the rule when they update or install software, as they may modify shell configuration files. Users can handle these by excluding the executables of these package managers from the rule.
+- **Container and Virtualization Software**: Tools such as `dockerd`, `podman`, and `snapd` may modify shell configurations during container or virtual environment setups. Excluding these specific executables can prevent false positives.
+- **User Account Management**: Commands like `adduser` and `useradd` might modify shell configuration files when creating new user accounts. Excluding these processes can help reduce false alerts.
+- **System Maintenance Scripts**: Automated scripts or system maintenance tasks, such as those run by `cron` or `systemd`, might alter shell configurations. Users can exclude these processes or specific script names to avoid false positives.
+- **Text Editors and Temporary Files**: Editors like `vim` create temporary files (e.g., with extensions like `.swp`) that might be flagged. Excluding these file extensions can prevent unnecessary alerts.
+- **Development and Scripting Tools**: Tools like `perl` and `sed` might be used in scripts that modify shell configurations. Users can exclude these processes when they are known to be part of legitimate scripts.
+- **Custom Exclusions**: Users can create custom exclusions for specific paths or processes that are known to be safe in their environment, ensuring that legitimate activities do not trigger false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of malicious activity.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on recent changes to shell configuration files and correlating with known indicators of compromise related to the Kaiji malware family.
+- Review and analyze logs from the system and any connected systems to trace the origin of the unauthorized changes and identify any additional compromised systems.
+- Remove any unauthorized or malicious entries from the shell configuration files and restore them to their last known good state using backups if available.
+- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed information on file modifications and process executions, ensuring that future unauthorized changes are detected promptly.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to provide real-time monitoring and alerting for suspicious activities.
+- Conduct a security audit of user accounts and permissions to ensure that only authorized users have access to modify shell configuration files.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the compromise is severe or if additional expertise is required.
+- Educate users on security best practices, including recognizing phishing attempts and maintaining strong, unique passwords, to reduce the risk of future compromises."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_simple_web_server_connection_accepted.toml b/rules/linux/persistence_simple_web_server_connection_accepted.toml
index 47c99c850ca..3577788b8ee 100644
--- a/rules/linux/persistence_simple_web_server_connection_accepted.toml
+++ b/rules/linux/persistence_simple_web_server_connection_accepted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ network where host.os.type == "linux" and event.type == "start" and event.action
   (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*"))
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Simple HTTP Web Server Connection
+
+Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain persistence on compromised systems by deploying malicious payloads, such as reverse shells. The detection rule identifies suspicious server activity by monitoring for specific process names and command-line patterns indicative of these lightweight servers being used inappropriately.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and command-line arguments match the patterns specified in the detection rule, focusing on `process.name` and `process.command_line`.
+- Check the source IP address and port associated with the `connection_accepted` event to identify potential external connections.
+- Investigate the parent process of the detected Python or PHP process to determine how the server was initiated and if it was spawned by a legitimate application or script.
+- Use Osquery to list all active network connections on the host to identify any other suspicious connections: `SELECT * FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name LIKE 'python%' OR name REGEXP 'php?[0-9]?\\.?[0-9]{0,2}');`
+- Examine the file system for any newly created or modified files in the web server's root directory that could indicate the presence of malicious payloads.
+- Review system logs for any recent user logins or privilege escalations that could correlate with the initiation of the HTTP server.
+- Analyze the command history of the user account associated with the process to identify any manual commands that may have started the server.
+- Check for any scheduled tasks or cron jobs that might be configured to restart the server automatically, indicating persistence mechanisms.
+- Investigate any other alerts or anomalies on the host around the same timeframe to identify potential lateral movement or additional compromise indicators.
+- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or threat actor behaviors.
+
+### False positive analysis
+
+- Development and testing environments: Simple HTTP servers are often used by developers for testing purposes. These environments may frequently trigger the rule due to legitimate use of Python or PHP servers. Users can handle this by creating exceptions for known development machines or specific user accounts that regularly perform these activities.
+- Automated scripts and tools: Some automated scripts or tools may use lightweight HTTP servers for legitimate tasks such as data collection or internal communication. Users should identify these scripts and exclude them from the rule by specifying their process names or command-line patterns.
+- Educational or training sessions: In educational settings, instructors or students might use simple HTTP servers to demonstrate web server concepts. Users can manage these false positives by excluding specific IP ranges or user accounts associated with educational activities.
+- Internal testing of web applications: Organizations may conduct internal testing of web applications using simple HTTP servers. To prevent false positives, users can whitelist specific IP addresses or hostnames where these tests are conducted.
+- Continuous integration/continuous deployment (CI/CD) pipelines: CI/CD processes might involve spinning up temporary HTTP servers for testing purposes. Users should identify these processes and exclude them by defining exceptions based on process names or command-line arguments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on logs and network traffic related to the detected simple HTTP server activity.
+- Terminate any unauthorized processes related to the simple HTTP server, such as those running Python or PHP with suspicious command-line arguments.
+- Remove any malicious payloads or scripts uploaded to the server web root, ensuring no backdoors remain on the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all software is up to date with the latest security patches.
+- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and applying least privilege principles.
+- Review and update security policies and procedures to address gaps identified during the incident response process, leveraging MITRE ATT&CK framework insights for persistence and server software component threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_simple_web_server_creation.toml b/rules/linux/persistence_simple_web_server_creation.toml
index dcf1ddd1312..d0d9cb90565 100644
--- a/rules/linux/persistence_simple_web_server_creation.toml
+++ b/rules/linux/persistence_simple_web_server_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name like "python*" and process.args in ("--cgi", "CGIHTTPServer"))
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Simple HTTP Web Server Creation
+
+Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised systems by hosting malicious payloads. The detection rule identifies suspicious server creation by monitoring process executions that match patterns indicative of PHP or Python web server initiation, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments match the patterns specified in the detection rule, focusing on `process.name` and `process.args`.
+- Check the timestamp of the event to determine when the suspicious server was initiated and correlate it with other events around the same time.
+- Investigate the parent process of the suspicious server creation to understand how the process was initiated and identify any potential malicious scripts or commands.
+- Examine the user account under which the process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Use Osquery to list all active network connections and identify any unusual or unauthorized connections that may be related to the web server. Example query: `SELECT * FROM listening_ports WHERE port = 80 OR port = 8000;`
+- Investigate the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads.
+- Review system logs for any additional context or anomalies around the time of the server creation, such as failed login attempts or privilege escalation activities.
+- Check for any scheduled tasks or cron jobs that might be used to restart the web server or maintain persistence.
+- Analyze network traffic logs to identify any external IP addresses communicating with the server, which could indicate an adversary's control server.
+- Cross-reference the detected activity with threat intelligence sources to determine if the observed behavior matches known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Development and testing environments: In many organizations, developers and testers frequently use simple HTTP web servers for legitimate purposes such as testing web applications or sharing files temporarily. These activities can trigger the detection rule, leading to false positives.
+- Automated scripts and tools: Some automated scripts or tools may use PHP or Python to start simple HTTP servers for tasks like data collection or internal service hosting, which are benign but may be flagged by the rule.
+- Educational and training sessions: In educational settings, instructors or students might use simple HTTP servers as part of learning exercises, which can be mistakenly identified as suspicious activity.
+- To manage these false positives, users can create exceptions for known and trusted processes or users by whitelisting specific command patterns or user accounts that frequently initiate these servers for legitimate purposes. Additionally, monitoring the context of server creation, such as the associated user or network activity, can help differentiate between benign and malicious use.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any malicious payloads or scripts hosted on the simple HTTP web server and remove them.
+- Review system logs and process execution history to determine the initial access vector and scope of the compromise.
+- Utilize MITRE ATT&CK framework details to understand the adversary's tactics, techniques, and procedures (TTPs) and assess potential persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and network activity for future detection and analysis.
+- Restore the system to a known good state by reinstalling the operating system and applications, ensuring all security patches are applied.
+- Change all credentials and keys that may have been exposed or compromised during the incident.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and deploying endpoint protection solutions to prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_ssh_key_generation.toml b/rules/linux/persistence_ssh_key_generation.toml
index 39724968b1a..051fc639d5d 100644
--- a/rules/linux/persistence_ssh_key_generation.toml
+++ b/rules/linux/persistence_ssh_key_generation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,49 @@ file where host.os.type == "linux" and event.action in ("creation", "file_create
 process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and
 not file.name : "known_hosts.*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SSH Key Generated via ssh-keygen
+
+SSH keys, created using the ssh-keygen tool, are essential for secure authentication in Linux environments. While typically used for legitimate access to remote systems, adversaries can exploit this by generating unauthorized keys, enabling lateral movement or persistence. The detection rule monitors key creation events in critical directories, flagging potential misuse by excluding known benign files.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event action is either "creation" or "file_create_event" and verify the process executable is "/usr/bin/ssh-keygen" to ensure the alert is valid.
+- Check the file path where the SSH key was created, ensuring it matches one of the critical directories: "/home/*/.ssh/*", "/root/.ssh/*", or "/etc/ssh/*".
+- Investigate the user account associated with the SSH key creation event to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the timestamp of the SSH key creation to identify if it occurred during unusual hours or coincides with other suspicious activities.
+- Use Osquery to list all SSH keys in the system and identify any unauthorized or unexpected keys. Example query: `SELECT * FROM file WHERE path LIKE '/home/%/.ssh/id_%' OR path LIKE '/root/.ssh/id_%' OR path LIKE '/etc/ssh/ssh_host_%';`
+- Cross-reference the SSH key creation event with recent login attempts or successful logins to determine if the key has been used for unauthorized access.
+- Analyze system logs for any other unusual activities or errors around the time of the SSH key creation to gather additional context.
+- Check for any recent changes to the SSH configuration files in "/etc/ssh/" that might indicate tampering or preparation for unauthorized access.
+- Investigate any other processes or commands executed by the same user around the time of the SSH key creation to identify potential malicious behavior.
+- Review network logs for any outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often generate SSH keys for legitimate purposes, such as setting up automated scripts or configuring new servers. These activities can trigger the rule but are non-threatening. Users can manage these by creating exceptions for specific user accounts or directories known to be used by administrators.
+- Automated deployment tools: Tools like Ansible, Puppet, or Chef may generate SSH keys as part of their deployment processes. These are typically benign and can be excluded by identifying the specific processes or service accounts involved in these operations.
+- Backup and recovery operations: Some backup solutions may create SSH keys to facilitate secure data transfer between systems. Users should identify these operations and exclude them from the rule by specifying the associated file paths or process names.
+- Development and testing environments: Developers may frequently generate SSH keys for testing purposes. To handle these, users can exclude specific development environments or user accounts from the rule.
+- Known benign scripts: If there are scripts or applications that are known to generate SSH keys as part of their normal operation, users can create exceptions for these by specifying the script names or paths in the exclusion list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the SSH key creation by checking the user account associated with the key and confirming with the account owner.
+- Review system logs and SSH access logs to identify any unauthorized access attempts or successful logins using the newly created SSH key.
+- Remove any unauthorized SSH keys from the affected directories and change passwords for any compromised accounts.
+- Conduct a thorough scan of the system for any additional signs of compromise, such as unexpected processes or network connections.
+- Escalate the incident to the security operations team if unauthorized access is confirmed, providing them with all relevant logs and findings.
+- Implement enhanced logging policies to capture detailed SSH key creation events and monitor for any future unauthorized key generation.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate SSH key creation events with other suspicious activities across the network.
+- Restore the system to its operational state by ensuring all unauthorized changes are reverted and applying any necessary security patches.
+- Harden the system by enforcing strict SSH key management policies, such as using key expiration and limiting key usage to specific IP addresses."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_ssh_netcon.toml b/rules/linux/persistence_ssh_netcon.toml
index 44b2a2d4a20..76d885a5e68 100644
--- a/rules/linux/persistence_ssh_netcon.toml
+++ b/rules/linux/persistence_ssh_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,49 @@ sequence by host.id with maxspan=1s
     )
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Connection Initiated by SSHD Child Process
+
+The SSH Daemon (SSHD) is crucial for secure remote access on Linux systems, managing user logins and executing commands. Adversaries may exploit SSHD by altering shell configurations or backdooring the daemon to establish unauthorized connections, often for persistence or data exfiltration. The detection rule identifies suspicious outbound connections initiated by SSHD child processes, excluding benign processes and internal IP ranges, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `process.entity_id` associated with the suspicious activity.
+- Examine the `process.parent.executable` field to confirm that the parent process is indeed `/usr/sbin/sshd`, indicating the connection was initiated by an SSHD child process.
+- Check the `destination.ip` field to determine the external IP address the connection was attempted to, and assess its reputation using threat intelligence sources.
+- Investigate the `process.executable` and `process.name` fields to identify the specific process that initiated the network connection, ensuring it is not a benign process like `/bin/yum` or `login_duo`.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` where `<process_id>` is the ID of the suspicious process.
+- Analyze the SSHD configuration files and shell configuration files for any unauthorized modifications or scripts that could trigger the process execution upon SSH login.
+- Review recent login attempts and user activity on the affected host to identify any unusual patterns or unauthorized access.
+- Correlate the event with other logs, such as authentication logs, to determine if there are any related suspicious activities or failed login attempts.
+- Investigate the network traffic logs for the specified `host.id` to identify any other unusual outbound connections or patterns that coincide with the alert.
+- Consult with the network team to verify if the destination IP is part of any known or legitimate business operations, or if it is associated with any known malicious infrastructure.
+
+### False positive analysis
+
+- **Automated System Updates**: Processes like `/bin/yum` or `/usr/bin/yum` may initiate network connections as part of routine system updates. These should be considered for exclusion if they are part of regular maintenance activities.
+- **Legitimate SSH Sessions**: Tools such as `login_duo`, `ssh`, `sshd`, and `sshd-session` might trigger alerts when they establish connections as part of normal SSH operations. Users can exclude these processes if they are verified as part of legitimate administrative tasks.
+- **Internal Network Scans**: Network connections to internal IP ranges might be flagged if the rule is not correctly excluding them. Ensure that the rule's IP exclusions cover all internal ranges used by the organization.
+- **Custom Scripts**: Custom scripts executed upon SSH login that initiate network connections for legitimate purposes, such as logging or monitoring, may trigger this rule. Users should identify and exclude these scripts if they are verified as non-threatening.
+- **Handling False Positives**: Users can manage false positives by updating the rule to include exceptions for known benign processes and IP ranges. Regularly review and adjust the exclusion list to align with the organization's network behavior and security policies.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and method of the compromise, focusing on SSHD configuration files and recent changes to shell scripts.
+- Review and analyze logs from the SSHD and network traffic to identify any unauthorized access or data transfer attempts.
+- Terminate any suspicious processes initiated by SSHD child processes and remove any unauthorized or malicious files or scripts found on the system.
+- Change all credentials associated with the compromised system, especially those used for SSH access, to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed SSHD activity and network connections for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Harden the system by configuring SSHD with strong authentication methods, disabling root login, and using firewalls to restrict access to trusted IP addresses only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_ssh_via_backdoored_system_user.toml b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
index 9be325eed2b..d4933505483 100644
--- a/rules/linux/persistence_ssh_via_backdoored_system_user.toml
+++ b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,49 @@ user.name in (
   "avahi", "sshd", "dnsmasq"
 ) and event.outcome == "success"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Login via Unusual System User
+
+In Linux environments, system users typically have restricted login capabilities to prevent unauthorized access. These accounts, often set with `nologin`, are not meant for interactive sessions. Adversaries may exploit these accounts by altering their configurations to enable SSH access, thus bypassing standard security measures. The detection rule identifies successful logins by these uncommon system users, signaling potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific system user involved in the login attempt and the host where the login occurred.
+- Verify the login time and correlate it with known maintenance windows or authorized activities to rule out false positives.
+- Check the user's shell configuration to confirm if it was altered from `nologin` to a valid shell, indicating potential tampering.
+- Investigate the source IP address of the login attempt to determine if it is from a known or trusted network.
+- Use Osquery to gather additional context on the system user by running: `SELECT * FROM etc_passwd WHERE username = '<system_user>';` to verify user details and shell configuration.
+- Examine the SSH configuration files (e.g., `/etc/ssh/sshd_config`) for any unauthorized changes that might allow system users to log in.
+- Review recent authentication logs (e.g., `/var/log/auth.log`) for any unusual patterns or repeated login attempts involving the system user.
+- Check for any recent changes to user accounts or group memberships that might indicate account manipulation.
+- Investigate any related processes or services running under the system user account to identify potential malicious activity.
+- Correlate the event with other security alerts or logs to identify if this login attempt is part of a broader attack pattern.
+
+### False positive analysis
+
+- System maintenance tasks: Some automated scripts or maintenance tasks may require temporary login access using system accounts. These should be reviewed and, if deemed non-threatening, can be excluded by adding exceptions for specific scripts or IP addresses.
+- Backup operations: Backup software might use system accounts like "backup" to perform regular data backups. Verify the legitimacy of these operations and exclude them if they are part of routine, authorized processes.
+- Monitoring and management tools: Certain monitoring or management tools may use system accounts for health checks or updates. Confirm these activities with your IT team and exclude them if they are recognized as safe and necessary.
+- Custom applications: In some environments, custom applications might be configured to use system accounts for specific functions. Ensure these applications are secure and exclude their activities if they are essential and authorized.
+- Scheduled tasks: Cron jobs or other scheduled tasks might inadvertently trigger logins using system accounts. Review these tasks and exclude them if they are part of expected and secure operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Review authentication logs to confirm the unusual login activity and identify any other potentially compromised accounts.
+- Change passwords for all system users and ensure that default system accounts are set back to 'nologin' where applicable.
+- Conduct a thorough investigation to determine how the adversary gained access and whether any other systems are affected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed authentication events and system changes for future investigations.
+- Integrate threat intelligence feeds to correlate unusual login activities with known threat actor tactics and techniques.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Apply system hardening measures, such as disabling unused services and enforcing least privilege access controls.
+- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_suspicious_file_opened_through_editor.toml b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
index 21922814d76..133ce16a907 100644
--- a/rules/linux/persistence_suspicious_file_opened_through_editor.toml
+++ b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,49 @@ file.path : (
   "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Suspicious File Edit
+
+In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert. Pay attention to the `file.path` field to understand which sensitive directory was involved.
+- Check the `event.action` field to confirm whether the action was a "creation" or "file_create_event" to ensure the alert is relevant to a new file creation.
+- Use Osquery to list recent file modifications in the directory where the .swp file was detected. Example query: `SELECT path, mtime FROM file WHERE directory = '/etc/' ORDER BY mtime DESC LIMIT 10;`
+- Investigate the user account associated with the file creation event. Look into the `user.name` field to determine if the action was performed by a legitimate user or a potential adversary.
+- Examine system logs around the time of the alert to identify any unusual login attempts or other suspicious activities. Focus on logs such as `/var/log/auth.log` or `/var/log/secure`.
+- Use Osquery to check for any running processes that might be related to text editors or suspicious activities. Example query: `SELECT name, pid, path FROM processes WHERE name IN ('vim', 'nano', 'emacs');`
+- Verify the integrity of the original file that the .swp file corresponds to by comparing it with a known good backup or using a file integrity monitoring tool.
+- Investigate any recent changes to user permissions or group memberships that could indicate privilege escalation attempts. Use Osquery: `SELECT * FROM user_groups WHERE user = 'suspicious_user';`
+- Check for any other .swp files in the system that might indicate a broader pattern of suspicious file edits. Use a command like `find / -name "*.swp"`.
+- Correlate the alert with other security events or alerts in your SIEM to identify if this is part of a larger attack pattern or campaign.
+
+### False positive analysis
+
+- Opening a file in a text editor without making any changes can trigger the creation of a .swp file, leading to a false positive. Users can handle this by monitoring the frequency and context of such events to distinguish between benign and suspicious activities.
+- System administrators or automated scripts that regularly open and review configuration files for maintenance purposes may inadvertently create .swp files. To manage this, users can create exceptions for known maintenance windows or specific user accounts that perform these tasks.
+- Development environments where users frequently edit configuration files in sensitive directories might generate numerous .swp files. Users can exclude specific directories or user accounts from triggering alerts if they are part of a controlled development process.
+- Backup or synchronization tools that temporarily open files for copying or syncing purposes might also create .swp files. Users can identify these tools and exclude their activities from the rule to prevent false positives.
+- In environments where multiple users have access to the same system, legitimate users might open files in sensitive directories for legitimate reasons. Users can implement user-based exceptions or monitor user behavior patterns to differentiate between normal and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
+- Conduct a thorough investigation to identify the source of the suspicious file edit, including reviewing recent user activity and system logs.
+- Verify the integrity of the affected files by comparing them with known good backups or using file integrity monitoring tools.
+- If unauthorized changes are confirmed, restore the affected files from a clean backup to ensure system integrity.
+- Escalate the incident to the security operations team if evidence of privilege escalation or persistence mechanisms is found.
+- Implement enhanced logging policies to capture detailed file access and modification events, focusing on sensitive directories and files.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate events and improve detection capabilities.
+- Apply system hardening measures, such as restricting access to critical files and directories and enforcing the principle of least privilege.
+- Regularly update and patch the system to mitigate vulnerabilities that could be exploited for unauthorized file edits.
+- Educate users on secure file handling practices and the risks associated with editing sensitive files in critical directories."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
index 5590ed91078..be87a383efc 100644
--- a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
+++ b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,49 @@ sequence by host.id, user.id with maxspan=1s
  [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.pid, process.entity_id
  [network where host.os.type == "linux" and event.type == "end" and event.action == "disconnect_received" and process.name == "sshd"] by process.pid, process.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Execution via XZBackdoor
+
+The XZBackdoor leverages SSH, a secure protocol for remote system access, to execute malicious commands. Adversaries exploit SSH by initiating sessions that appear legitimate but execute unauthorized processes, often terminating abruptly to avoid detection. The detection rule identifies such anomalies by monitoring SSH processes for unexpected terminations and unusual child process executions, signaling potential backdoor activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand which host and user IDs are involved, as these are key identifiers in the query.
+- Examine the process tree for the SSHD process using the `process.pid` and `process.entity_id` fields to identify any unusual child processes that were spawned.
+- Check the command-line arguments of the SSHD process using `process.args` to verify if the `-D` and `-R` flags were used, which may indicate a persistent SSH session.
+- Investigate the parent process of any suspicious child processes using `process.parent.name` and `process.parent.entity_id` to determine if they were initiated by SSHD.
+- Analyze the exit codes of the SSHD process using `process.exit_code` to identify any non-zero values that could indicate abnormal termination.
+- Look into the network activity associated with the SSHD process using `event.action` and `event.type` to confirm if there was a disconnect event, which might suggest abrupt session termination.
+- Use Osquery to gather more context on the SSHD process and its child processes. For example, run the following query to list all processes with their parent-child relationships: `SELECT pid, name, path, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'sshd');`
+- Cross-reference the executable paths of suspicious processes with known legitimate paths using `process.executable` to identify any anomalies.
+- Review the system logs for any additional context around the time of the alert, focusing on authentication logs and any other relevant security logs.
+- Correlate the findings with any other alerts or incidents involving the same host or user to identify patterns or repeated suspicious behavior.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use SSH to perform routine maintenance or execute scripts that could match the rule's criteria, such as starting and stopping services or running diagnostic commands. To manage this, users can create exceptions for known administrative accounts or specific command patterns that are regularly used in maintenance activities.
+- Automated scripts and cron jobs: Scheduled tasks or automated scripts that use SSH for remote execution might trigger the rule if they terminate unexpectedly due to errors or network issues. Users can handle these by identifying and excluding specific scripts or cron jobs that are known to cause such behavior.
+- Security tools and monitoring software: Some security tools or monitoring solutions might use SSH to perform checks or gather data, which could mimic the behavior detected by the rule. Users should review and whitelist these tools by their executable paths or command-line arguments to prevent false positives.
+- Testing and development environments: In environments where frequent testing or development occurs, SSH sessions may be started and stopped rapidly, leading to false positives. Users can exclude specific hosts or user accounts associated with testing and development to reduce noise.
+- Network instability: Temporary network issues might cause SSH sessions to disconnect unexpectedly, triggering the rule. Users can monitor network stability and exclude known periods of instability or specific network segments that are prone to such issues.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the SSH logs and process execution history to identify any unauthorized access or commands executed.
+- Terminate any suspicious or unauthorized SSH sessions and processes identified during the investigation.
+- Change all credentials associated with the compromised system, especially SSH keys and passwords, to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging and monitoring for SSH activities, including logging of all SSH sessions and command executions, to detect future anomalies.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system from a known good backup to ensure that no malicious code remains on the system.
+- Apply system hardening measures, such as disabling root login via SSH, using key-based authentication, and implementing two-factor authentication (2FA) for SSH access.
+- Review and update security policies and procedures to address any gaps identified during the incident response process, ensuring alignment with MITRE ATT&CK framework techniques for persistence and system process modification."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_systemd_generator_creation.toml b/rules/linux/persistence_systemd_generator_creation.toml
index ac5ff2677bd..3e0de9c3b34 100644
--- a/rules/linux/persistence_systemd_generator_creation.toml
+++ b/rules/linux/persistence_systemd_generator_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -83,6 +83,49 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
   process.executable == null
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Systemd Generator Created
+
+Systemd generators are scripts that systemd runs at boot or during configuration reloads to convert non-native configurations into unit files. While they streamline service management, adversaries can exploit them to execute unauthorized code, ensuring persistence. The detection rule identifies suspicious generator file activities, excluding benign processes and file types, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path where the systemd generator was created or renamed, focusing on paths like `/run/systemd/system-generators/*` and `/etc/systemd/system-generators/*`.
+- Check the process that triggered the alert by examining the `process.executable` field to determine if it is a known benign process or potentially malicious.
+- Investigate the user account associated with the process that created or renamed the generator file to assess if it has legitimate access or if it might be compromised.
+- Use Osquery to list all systemd generator files and their metadata to identify any unexpected or unauthorized files. Example query: `SELECT * FROM file WHERE path LIKE '/run/systemd/system-generators/%' OR path LIKE '/etc/systemd/system-generators/%';`
+- Examine the file creation or modification timestamps to determine if the activity aligns with expected system changes or updates.
+- Cross-reference the alert with recent system updates or package installations to rule out legitimate changes that might have triggered the alert.
+- Analyze the contents of the suspicious generator file to identify any embedded scripts or commands that could indicate malicious intent.
+- Check system logs for any related entries around the time of the alert to gather additional context on the activity.
+- Investigate any network connections or external communications initiated by the process that created or modified the generator file to identify potential command and control activity.
+- Review historical alerts and incidents involving the same host or user account to identify patterns or repeated suspicious behavior that might indicate a broader compromise.
+
+### False positive analysis
+
+- Known false positives for the Systemd Generator Created rule often arise from legitimate software installations or updates, where package managers like dpkg, rpm, or snapd create or modify generator files as part of their normal operations.
+- To manage these false positives, users can exclude specific processes known to perform legitimate generator file operations by adding them to the exception list in the detection rule. This includes processes like dpkg, rpm, and snapd, which are already accounted for in the rule.
+- Another source of false positives can be temporary files created by text editors or system processes, which may have extensions like "swp" or "dpkg-remove". These can be excluded by adding their extensions to the exception list.
+- Users should regularly review and update the exception list to include any new legitimate processes or file types that are identified as causing false positives, ensuring that the detection rule remains effective without generating unnecessary alerts.
+- It's important to maintain a balance between excluding known benign activities and ensuring that potentially malicious activities are still detected, so users should carefully evaluate each exception added to the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the unauthorized systemd generator file creation, examining logs and process histories.
+- Review the contents of the suspicious generator file to understand the potential impact and any malicious code it may contain.
+- Remove or disable the unauthorized systemd generator file to prevent it from executing during future boot processes.
+- Restore any modified or deleted legitimate systemd generator files from a known good backup to ensure system integrity.
+- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if the threat actor's identity is unknown.
+- Implement enhanced logging policies to capture detailed information on file creation and modification events, focusing on systemd generator directories.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Apply system hardening measures, such as restricting write permissions to systemd generator directories and ensuring only trusted processes can create or modify files in these locations.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address any deficiencies discovered during the investigation."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_systemd_netcon.toml b/rules/linux/persistence_systemd_netcon.toml
index ca08b619167..0e33b7d8024 100644
--- a/rules/linux/persistence_systemd_netcon.toml
+++ b/rules/linux/persistence_systemd_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,52 @@ sequence by host.id with maxspan=5s
   [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
    not process.executable == "/tmp/newroot/bin/curl"] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Network Connection via systemd
+
+Systemd is integral to Linux, managing system processes and services. Adversaries exploit it by altering unit files or replacing binaries, ensuring malicious scripts run at startup. The detection rule identifies suspicious network activities initiated by systemd, focusing on unusual processes like scripting languages or network tools, which may indicate a backdoor or persistence mechanism.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `process.entity_id` and `process.parent.entity_id` involved in the suspicious activity.
+- Examine the process command line and arguments for the suspicious process using the `process.name` field to understand what script or command was executed.
+- Check the parent process details using the `process.parent.name` field to confirm that the process was indeed initiated by systemd.
+- Investigate the network connection details, including the destination IP and port, using the `network` event data to determine if the connection is to a known malicious or unusual destination.
+- Use Osquery to list all systemd unit files and check for any unusual or recently modified files:
+  ```sql
+  SELECT * FROM systemd_units WHERE path LIKE '/etc/systemd/system/%' OR path LIKE '/lib/systemd/system/%';
+  ```
+- Cross-reference the `process.executable` path with known legitimate binaries to ensure it hasn't been replaced or tampered with.
+- Investigate the `/tmp/newroot/bin/curl` path to ensure it is not being used as a legitimate bypass for the detection rule.
+- Review system logs around the time of the alert to identify any other suspicious activities or related events.
+- Check for any recent changes to systemd configuration files or binaries using file integrity monitoring tools or by reviewing file modification timestamps.
+- Correlate the alert with other security events or alerts from the same host to identify potential patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- System administrators or automated scripts may use scripting languages like Python, PHP, or Perl for legitimate maintenance tasks, leading to false positives. Users can create exceptions for known maintenance scripts by whitelisting specific script paths or process names.
+- Network tools such as netcat or telnet might be used for legitimate troubleshooting or monitoring purposes. To handle these, users can exclude specific network activities by defining exceptions for known IP addresses or ports associated with routine operations.
+- Development environments often use scripting languages and network tools for testing and debugging, which can trigger alerts. Users can manage these by excluding processes executed within designated development directories or by specific user accounts.
+- Some legitimate applications may use systemd to manage their network connections, appearing suspicious. Users should identify and whitelist these applications by their process names or executable paths to prevent false positives.
+- Regularly scheduled tasks or cron jobs that involve network communication might be flagged. Users can mitigate this by excluding processes associated with known cron jobs or by specifying time-based exceptions for expected network activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any modified or newly created systemd unit files and verify their legitimacy.
+- Review and analyze the process tree to understand the scope of the compromise and identify any additional malicious processes or scripts.
+- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
+- Restore any modified or replaced systemd binaries from a trusted backup or reinstall the affected packages to ensure system integrity.
+- Implement enhanced logging for systemd activities and network connections to improve detection of similar threats in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited.
+- Review and update system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_tainted_kernel_module_load.toml b/rules/linux/persistence_tainted_kernel_module_load.toml
index 6cabc894a4d..3ecc3a8754a 100644
--- a/rules/linux/persistence_tainted_kernel_module_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/23"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,52 @@ query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
 message:"module verification failed: signature and/or required key missing - tainting kernel"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Tainted Kernel Module Load
+
+Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of code. Adversaries exploit this by loading malicious modules to evade detection and maintain persistence. The detection rule identifies suspicious module loads by monitoring syslog for messages indicating failed module verification, signaling potential unauthorized kernel modifications. This helps in identifying and mitigating rootkit threats.
+
+### Possible investigation steps
+
+- Review the syslog entries around the time of the alert to gather more context about the module load attempt, focusing on the `message` field for any additional error messages or anomalies.
+- Check the `host.os.type` and `event.dataset` fields to confirm the alert pertains to a Linux system and is sourced from the syslog, ensuring the data is relevant to the investigation.
+- Identify the specific kernel module that triggered the alert by examining the `process.name` field and any associated module names or paths in the syslog message.
+- Use Osquery to list all currently loaded kernel modules and their details to identify any unfamiliar or suspicious modules:
+  ```sql
+  SELECT name, size, used_by FROM kernel_modules;
+  ```
+- Investigate the origin of the suspicious module by checking the file system for the module's file path and examining its metadata, such as creation and modification times.
+- Cross-reference the module's file path with known good or bad module lists to determine if it is a legitimate or potentially malicious module.
+- Analyze the system's boot logs and startup scripts to check for any unauthorized modifications that might load the suspicious module at boot time.
+- Review user and process activity logs around the time of the alert to identify any unusual behavior or processes that might have attempted to load the module.
+- Check for any recent changes in user privileges or new user accounts that could indicate unauthorized access or privilege escalation attempts.
+- Investigate network activity logs for any signs of communication with known malicious IP addresses or domains that could be associated with the suspicious module.
+
+### False positive analysis
+
+- Some legitimate kernel modules may not be signed or may lack the required keys, leading to false positives. This can occur with custom-built modules or those from trusted third-party vendors that do not follow the standard signing process.
+- Kernel modules used in development or testing environments might trigger alerts due to missing signatures, even though they are not malicious.
+- Users can manage these false positives by creating exceptions for specific modules known to be safe. This can be done by maintaining a whitelist of trusted module names or paths that are frequently loaded without signatures.
+- Regularly review and update the whitelist to ensure it only includes modules that are verified as non-threatening, reducing the risk of overlooking a genuine threat.
+- Consider implementing additional checks or monitoring for other indicators of compromise to complement the detection rule and provide a more comprehensive security posture.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Conduct a thorough investigation to identify the loaded kernel module and verify its legitimacy by checking against known good modules and signatures.
+- If the module is confirmed malicious, remove it from the system and check for any additional unauthorized changes or files.
+- Review system logs and use forensic tools to trace the origin of the tainted module load and identify any potential entry points or vulnerabilities exploited by the adversary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Restore the system to a known good state using backups or system snapshots, ensuring that all malicious artifacts are removed.
+- Apply security patches and updates to the operating system and all software to close any vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed information on kernel module loads and other critical system events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context on similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update hardening measures, such as enforcing strict module signing policies and using secure boot mechanisms."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
index 57ff1986c23..5bc2effccdf 100644
--- a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,48 @@ query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
 message:"loading out-of-tree module taints kernel."
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Tainted Out-Of-Tree Kernel Module Load
+
+Kernel modules extend the functionality of the Linux kernel without rebooting the system. While beneficial, out-of-tree modules, not included in the official kernel source, can taint the kernel, posing security risks. Adversaries exploit this by loading malicious modules to maintain persistence or evade detection. The detection rule monitors syslog for specific messages indicating such module loads, helping identify potential rootkit activity.
+
+### Possible investigation steps
+
+- Review the syslog entries around the time of the alert to gather more context about the module load event, focusing on the `event.dataset:"system.syslog"` and `process.name:kernel` fields.
+- Identify the specific out-of-tree module that was loaded by examining the `message` field for details about the module name and path.
+- Check the system's kernel module directory (e.g., `/lib/modules/$(uname -r)/extra/`) to verify the presence and legitimacy of the module file.
+- Use Osquery to list all currently loaded kernel modules and their details with the query: `SELECT name, size, used_by FROM kernel_modules WHERE name = '<module_name>';` to confirm the module's presence and usage.
+- Investigate the source and integrity of the module file by checking its creation and modification timestamps, and compare its hash against known good values if available.
+- Examine the system's package manager logs or configuration management tools to determine if the module was installed or updated recently as part of a legitimate package or update.
+- Review user and process activity logs around the time of the module load to identify any suspicious behavior or unauthorized access attempts.
+- Check for any recent changes to system configurations or scripts that could have led to the loading of the module, focusing on boot or startup scripts.
+- Investigate any other alerts or anomalies in the system logs that coincide with the module load event to identify potential related malicious activity.
+- Consult threat intelligence sources to determine if the module or its characteristics match any known malicious signatures or behaviors.
+
+### False positive analysis
+
+- Legitimate third-party drivers: Some out-of-tree kernel modules are legitimate third-party drivers necessary for specific hardware functionality. These can trigger the rule but do not pose a security threat. Users can create exceptions for these known drivers by identifying their specific module names and excluding them from the detection rule.
+- Custom kernel modules: Organizations may develop custom kernel modules for internal use, which can also taint the kernel. These should be documented and whitelisted to prevent false positives. Users should maintain a list of approved custom modules and adjust the detection rule to exclude these from alerts.
+- Development and testing environments: In environments where kernel development or testing occurs, frequent loading of out-of-tree modules is expected. Users can configure the rule to ignore these environments by excluding specific hostnames or IP addresses associated with development and testing.
+- Vendor-specific modules: Some vendors provide out-of-tree modules for enhanced functionality or performance. Users should verify the legitimacy of these modules and, if deemed safe, add them to an exception list to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Conduct a thorough investigation to identify the loaded out-of-tree kernel module, including its origin, purpose, and any associated processes or files.
+- Utilize forensic tools to capture memory and disk images for further analysis, ensuring evidence preservation for potential legal or compliance requirements.
+- Cross-reference the identified module with known malicious signatures or behaviors using threat intelligence databases and resources.
+- Remove the unauthorized or malicious kernel module and any associated files or processes from the system.
+- Apply patches and updates to the kernel and all installed software to mitigate vulnerabilities that could be exploited by similar threats.
+- Implement enhanced logging policies to capture detailed system and network activity, focusing on kernel module loads and other critical events.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve monitoring and detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining system integrity and security."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_udev_rule_creation.toml b/rules/linux/persistence_udev_rule_creation.toml
index aa3b26fe2c2..9fb9aa63ee4 100644
--- a/rules/linux/persistence_udev_rule_creation.toml
+++ b/rules/linux/persistence_udev_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -83,6 +83,49 @@ file.path : (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Systemd-udevd Rule File Creation
+
+Systemd-udevd manages device nodes and handles kernel device events in Linux, using rule files to automate responses to hardware changes. Adversaries can exploit this by creating malicious rules that execute commands when specific devices are connected. The detection rule monitors the creation or renaming of these rule files, excluding legitimate processes, to identify potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and name of the rule file that was created or renamed, focusing on paths like "/lib/udev/*" and "/etc/udev/rules.d/*".
+- Check the process executable that triggered the alert to ensure it is not one of the legitimate processes listed in the exclusion criteria, such as "/bin/dpkg" or "/usr/bin/rpm".
+- Investigate the parent process of the executable to understand the context in which the rule file was created, using process lineage to identify any suspicious activity.
+- Use Osquery to list all udev rule files and their metadata, including creation and modification times, to identify any recent changes: `SELECT * FROM file WHERE path LIKE '/etc/udev/rules.d/%' OR path LIKE '/lib/udev/rules.d/%';`
+- Examine the contents of the suspicious rule file to identify any potentially malicious commands or scripts that could be executed when a device is connected.
+- Cross-reference the file creation or modification time with other system logs to identify any correlated events or activities that occurred around the same time.
+- Check for any recent connections of new or unusual devices to the system that might have triggered the rule file execution.
+- Investigate the user account associated with the process that created or modified the rule file to determine if it has been compromised or is acting suspiciously.
+- Review historical data to determine if similar rule file creation or modification events have occurred in the past, indicating a pattern of behavior.
+- Analyze network logs for any outbound connections or data exfiltration attempts following the rule file creation, which might suggest malicious intent.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the creation or modification of udev rule files, especially when using package managers like dpkg, rpm, or yum. These processes are typically excluded in the detection rule to prevent false positives.
+- System management tools such as Puppet, Chef, or Ansible might create or modify udev rules as part of their configuration management tasks. These tools are often run by trusted processes and can be excluded by adding their executables to the exception list.
+- Custom scripts or administrative tasks performed by system administrators might involve creating or modifying udev rules. If these actions are routine and verified as non-malicious, the specific scripts or processes can be added to the exclusion list.
+- Automated system updates or maintenance tasks, such as those performed by systemd or netplan, may also result in rule file changes. These processes are generally safe and can be excluded by specifying their names or paths in the detection rule.
+- Users can manage false positives by regularly reviewing and updating the exclusion list to include any new legitimate processes or paths that are identified as part of normal system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the malicious udev rule file creation, examining recent user activity and process execution logs.
+- Remove any unauthorized or suspicious udev rule files from the system directories, ensuring that only legitimate rules remain.
+- Review and restore any system configurations or files that may have been altered by the malicious rule execution.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging for udev rule file changes and process executions to improve detection of similar threats in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze related security events.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
+- Educate users and administrators on the risks associated with unauthorized device connections and the importance of reporting suspicious activity."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_unusual_pam_grantor.toml b/rules/linux/persistence_unusual_pam_grantor.toml
index 2fee0dc96ad..2d57f0ccb2a 100644
--- a/rules/linux/persistence_unusual_pam_grantor.toml
+++ b/rules/linux/persistence_unusual_pam_grantor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,49 @@ query = '''
 event.category:authentication and host.os.type:linux and event.action:authenticated and event.outcome:success and
 auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Authentication via Unusual PAM Grantor
+
+Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit uncommon PAM grantors to escalate privileges or maintain persistence by altering default configurations. The detection rule identifies successful authentications using atypical PAM grantors, signaling potential unauthorized modifications and aligning with MITRE ATT&CK's persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific PAM grantor involved in the authentication event and cross-reference it with known legitimate PAM modules.
+- Examine the `event.category`, `host.os.type`, `event.action`, and `event.outcome` fields to confirm the context of the authentication event and ensure it aligns with the alert criteria.
+- Check the `auditd.data.grantors` field to identify the exact grantor used and determine if it is part of any known or expected configurations.
+- Investigate the user account associated with the authentication event to determine if it is a legitimate user or potentially compromised.
+- Use Osquery to list all PAM modules and configurations on the affected host to identify any unauthorized or unusual entries. Example query: `SELECT * FROM pam_modules;`
+- Review recent changes to PAM configuration files, such as `/etc/pam.d/`, to identify any unauthorized modifications or additions.
+- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any other suspicious authentication attempts or related activities around the time of the alert.
+- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise.
+- Investigate the source IP address and geolocation associated with the authentication event to determine if it originates from a known or suspicious location.
+- Consult with system administrators or users to verify if any legitimate changes were made to the PAM configuration that could explain the unusual grantor usage.
+
+### False positive analysis
+
+- Certain legitimate applications or services may use custom PAM modules for authentication, which could trigger this rule. For example, specialized software that requires unique authentication methods might not use standard PAM grantors.
+- System administrators might intentionally configure non-standard PAM modules for enhanced security or specific operational needs, leading to false positives.
+- To manage these false positives, users can create exceptions for known and trusted PAM grantors by updating the detection rule to exclude these specific modules.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the integrity of the detection process.
+- Collaborate with IT and security teams to document and understand the use of any non-standard PAM modules within the organization to accurately adjust the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes to PAM configurations and unusual user activity.
+- Review and analyze authentication logs to identify any unauthorized access attempts or successful authentications using unusual PAM grantors.
+- Revert any unauthorized changes to the PAM configuration files to their default state to ensure only legitimate authentication methods are used.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed authentication events and PAM module usage for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual PAM activity with known threat actor tactics.
+- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Harden the system by implementing least privilege access controls, regular audits of PAM configurations, and continuous monitoring for unusual authentication patterns."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_unusual_sshd_child_process.toml b/rules/linux/persistence_unusual_sshd_child_process.toml
index 83eae707d3b..faa84e146d1 100644
--- a/rules/linux/persistence_unusual_sshd_child_process.toml
+++ b/rules/linux/persistence_unusual_sshd_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,48 @@ event.category:process and host.os.type:linux and event.type:start and event.act
 process.parent.name:(ssh or sshd) and process.args_count:2 and
 not process.command_line:(-bash or -zsh or -sh)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual SSHD Child Process
+
+Secure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, filtering out typical shell invocations, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific process that was spawned, including the `process.command_line` and `process.args_count` fields, to identify any unusual or suspicious command-line arguments.
+- Check the `process.parent.name` field to confirm whether the parent process is indeed `ssh` or `sshd`, and verify the legitimacy of the parent process by cross-referencing with known user activity or scheduled tasks.
+- Investigate the user account associated with the SSH session by examining the `user.name` field to determine if the account is known and authorized to perform such actions.
+- Use Osquery to gather more context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;` to retrieve detailed information about the process, including its path, arguments, and environment variables.
+- Examine the `host.os.type` field to ensure the alert pertains to a Linux system, as expected, and correlate with any other alerts or logs from the same host for additional context.
+- Analyze the `event.category` and `event.type` fields to confirm that the event is indeed a process start event, and correlate with other process events to identify any related or subsequent suspicious activity.
+- Check for any recent changes in the system's SSH configuration files, such as `/etc/ssh/sshd_config`, to identify potential unauthorized modifications that could facilitate persistence or backdoor creation.
+- Review historical logs and alerts for the same host or user to identify any patterns of unusual SSH activity or previous instances of similar alerts.
+- Investigate network logs to identify any unusual or unauthorized remote connections associated with the SSH session, focusing on the source IP address and geolocation.
+- Consult threat intelligence sources to determine if the command-line arguments or process names observed are associated with known malicious activity or threat actor tactics.
+
+### False positive analysis
+
+- Known false positives for the Unusual SSHD Child Process rule may include legitimate administrative scripts or automated tasks that are executed via SSH but do not follow typical shell invocation patterns. These can be routine maintenance scripts or monitoring tools that use SSH for remote execution.
+- Users can handle these false positives by creating exceptions for specific processes or command lines that are known to be safe. This can be done by adding these processes to an allowlist or by modifying the detection rule to exclude certain command patterns that are verified as non-threatening.
+- It is important to regularly review and update these exceptions to ensure that they do not inadvertently allow malicious activity. This involves monitoring the frequency and context of the flagged processes to distinguish between benign and potentially harmful activities.
+- Collaboration with system administrators and security teams can help in identifying and documenting legitimate use cases that may trigger the rule, ensuring that the detection remains effective while minimizing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on SSH logs and process creation events.
+- Terminate any suspicious or unauthorized SSHD child processes identified during the investigation.
+- Review user accounts and SSH keys on the affected system to ensure no unauthorized accounts or keys have been added.
+- Change passwords and regenerate SSH keys for all legitimate users on the compromised system.
+- Apply security patches and updates to the operating system and SSH service to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process creation and network activity, ensuring future anomalies are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze security events more effectively.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring all security measures are in place before reconnecting to the network.
+- Harden the system by disabling unused services, enforcing strong authentication mechanisms, and regularly reviewing security configurations to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_user_or_group_creation_or_modification.toml b/rules/linux/persistence_user_or_group_creation_or_modification.toml
index 3c1f2b7696b..2259864ffe0 100644
--- a/rules/linux/persistence_user_or_group_creation_or_modification.toml
+++ b/rules/linux/persistence_user_or_group_creation_or_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,48 @@ query = '''
 iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and 
 event.action in ("changed-password", "added-user-account", "added-group-account-to")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 User or Group Creation/Modification
+
+In Linux environments, user and group management is crucial for access control. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes `auditd_manager` to monitor successful user or group changes, focusing on actions like password changes or account additions, aligning with MITRE ATT&CK's persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `event.type` and `event.action` that triggered the alert, focusing on whether it was a "creation" or "change" event.
+- Check the `auditd.result` field to confirm the success of the user or group modification, ensuring that the action was completed successfully.
+- Identify the user account or group involved in the event by examining the relevant fields in the alert, such as the username or group name.
+- Investigate the source of the event by reviewing the `host.os.type` and any associated IP addresses or hostnames to determine where the change originated.
+- Use Osquery to gather additional context about the user or group modification. For example, run the following query to list recent user additions or modifications: `SELECT * FROM users WHERE username = '<username>'`.
+- Cross-reference the identified user or group with known legitimate accounts to determine if the change aligns with expected administrative activities.
+- Review system logs and audit logs around the time of the event to identify any related activities or anomalies that could indicate malicious intent.
+- Check for any other recent alerts or events involving the same user or group to assess if this is part of a broader pattern of suspicious behavior.
+- Investigate the account that performed the modification to determine if it has been compromised or if it is being used by an unauthorized user.
+- Consult with system administrators or other relevant personnel to verify if the user or group modification was authorized and aligns with current operational needs.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often create or modify user and group accounts as part of regular maintenance or onboarding processes. These legitimate actions can trigger the rule, leading to false positives.
+- Automated scripts or tools: Some organizations use automated scripts or configuration management tools (e.g., Ansible, Puppet) to manage user accounts, which can result in frequent non-threatening account changes being flagged.
+- Software installations: Certain software installations may create or modify user accounts as part of their setup process, which can be mistakenly identified as suspicious activity.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts/tools by filtering out events associated with these trusted sources. This can be done by adding conditions to the detection rule to exclude actions performed by specific user accounts or processes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Review the audit logs to identify the specific user or group changes and determine if they were authorized or suspicious.
+- Verify the legitimacy of the newly created or modified accounts by cross-referencing with recent administrative activities and user requests.
+- If unauthorized changes are confirmed, disable or remove the suspicious accounts and reset passwords for any affected legitimate accounts.
+- Conduct a thorough investigation to identify any additional compromised systems or accounts, leveraging threat intelligence and MITRE ATT&CK details for context.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Implement enhanced logging policies to capture detailed user and group management activities, ensuring audit logs are securely stored and regularly reviewed.
+- Integrate additional security tools, such as intrusion detection systems (IDS) or endpoint detection and response (EDR) solutions, to improve monitoring and detection capabilities.
+- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all security controls are active and functioning.
+- Harden the system by enforcing least privilege access, implementing multi-factor authentication, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_xdg_autostart_netcon.toml b/rules/linux/persistence_xdg_autostart_netcon.toml
index f9a8948444a..dba55e65de1 100644
--- a/rules/linux/persistence_xdg_autostart_netcon.toml
+++ b/rules/linux/persistence_xdg_autostart_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -97,6 +97,53 @@ sequence by host.id, process.entity_id with maxspan=1s
      )
   ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Connections Initiated Through XDG Autostart Entry
+
+XDG Autostart entries are used in Linux environments like GNOME and XFCE to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign applications and local IP ranges.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `process.entity_id` associated with the suspicious activity.
+- Examine the `process.executable` and `process.args` fields to determine the exact command or script executed through the XDG autostart entry.
+- Check the `process.parent.executable` to confirm if the process was initiated by a legitimate session manager like `/usr/bin/xfce4-session`.
+- Investigate the `destination.ip` field in the network event to identify the external IP address the system attempted to connect to, ensuring it is not within the excluded local IP ranges.
+- Cross-reference the `destination.ip` with threat intelligence sources to determine if it is associated with known malicious activity.
+- Use Osquery to list all XDG autostart entries on the affected host to identify any unauthorized or suspicious entries:
+  ```sql
+  SELECT * FROM xdg_autostart WHERE path LIKE '/etc/xdg/autostart/%' OR path LIKE '~/.config/autostart/%';
+  ```
+- Analyze the contents of any suspicious XDG autostart files identified in the previous step to understand their purpose and potential impact.
+- Review system logs around the time of the alert to identify any other unusual activities or related events that might provide additional context.
+- Check for any recent changes to the XDG autostart files by reviewing file modification timestamps and comparing them with known good baselines.
+- Investigate the user account associated with the login session to determine if it has been compromised or if there are any signs of unauthorized access.
+
+### False positive analysis
+
+- Known false positives may include legitimate applications that initiate network connections upon user login, such as desktop environments or productivity tools that check for updates or sync data.
+- Applications like web browsers or VPN clients that are not included in the exclusion list may trigger alerts if they are set to start automatically and establish network connections.
+- Users can manage these false positives by updating the exclusion list to include additional known benign applications that frequently initiate network connections upon startup.
+- Consider monitoring the frequency and context of the alerts to identify patterns that suggest non-malicious behavior, allowing for more informed decisions on exclusions.
+- Regularly review and update the list of excluded IP ranges and applications to ensure it reflects the current network environment and application usage.
+- Collaborate with IT and security teams to identify any new applications or services that should be added to the exclusion list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify any unauthorized modifications to XDG autostart entries and associated scripts.
+- Review and analyze network logs to trace the origin and destination of suspicious network connections.
+- Remove or revert any unauthorized changes to XDG autostart entries and scripts to eliminate persistence mechanisms.
+- Update and patch the system to the latest security standards to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Restore the system to its operational state by verifying the integrity of critical system files and configurations.
+- Apply hardening measures such as restricting user permissions, disabling unnecessary services, and implementing application whitelisting."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
index d382a433ebc..395d7480cea 100644
--- a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,49 @@ file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Yum Package Manager Plugin File Creation
+
+Yum, a package manager for Fedora-based systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence by executing unauthorized actions whenever Yum is used. The detection rule identifies suspicious file creations in Yum's plugin directories, excluding legitimate processes and temporary files, to flag potential backdoor attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path where the creation or rename event occurred, focusing on paths like `/usr/lib/yum-plugins/*` and `/etc/yum/pluginconf.d/*`.
+- Check the process that triggered the file creation event by examining the `process.executable` field to determine if it matches any known legitimate processes or if it appears suspicious.
+- Investigate the `process.name` field to identify the process responsible for the file creation, ensuring it is not a known benign process like `yumBackend.py`.
+- Verify the file extension using the `file.extension` field to ensure it is not a temporary or swap file (e.g., `.swp`, `.swpx`, `.swx`).
+- Use Osquery to list all files in the Yum plugin directories and check for recent modifications or unusual file names. Example query: `SELECT path, filename, mtime FROM file WHERE path LIKE '/usr/lib/yum-plugins/%' OR path LIKE '/etc/yum/pluginconf.d/%';`
+- Cross-reference the `process.executable` path with known system paths to identify if it originates from unusual locations such as `/nix/store/*` or `/var/lib/dpkg/*`.
+- Examine the file metadata, including creation and modification timestamps, to determine if the timing aligns with any known system changes or updates.
+- Analyze system logs for any related events around the time of the file creation to identify potential unauthorized access or changes.
+- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with typical user behavior.
+- Review any recent changes to Yum configurations or updates that might explain the file creation, ensuring no unauthorized modifications have been made.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger file creation events in Yum's plugin directories, especially when performed by system administrators or automated scripts. Users can manage these by adding exceptions for known safe processes or scripts that regularly perform such actions.
+- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be mistakenly flagged. Users should ensure these extensions are included in the exclusion list to prevent unnecessary alerts.
+- Automation tools like Ansible may create temporary files in these directories, which can be mistaken for suspicious activity. Users can exclude file names starting with ".ansible" or ".ansible_tmp" to reduce false positives.
+- Processes running from specific directories, such as "/nix/store/*" or "/var/lib/dpkg/*", might be part of legitimate package management activities. Users should consider excluding these paths if they are part of regular system operations.
+- Certain system utilities like "sed" or "perl" might create temporary files during normal operations. Users can exclude these processes when they match specific patterns, such as "sed*" or "e2scrub_all.tmp*", to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the suspicious file creation, focusing on recent changes in the Yum plugin directories.
+- Review system logs and use forensic tools to trace the origin of the unauthorized file creation, paying attention to any unusual processes or user activities.
+- Remove any unauthorized or suspicious files from the Yum plugin directories and restore them from a known good backup if available.
+- Update all system packages and plugins to the latest versions to patch any known vulnerabilities that could have been exploited.
+- Implement strict access controls and permissions for the Yum plugin directories to limit who can create or modify files.
+- Enhance logging policies to include detailed monitoring of file creation and modification events in critical system directories.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if the attack is part of a larger campaign.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to prevent future occurrences."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
index 6582e466312..5e2b3b41415 100644
--- a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
+++ b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/28"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,48 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
  and process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Unauthorized Access via Wildcard Injection Detected
+
+In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse for privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `chown` or `chmod` command execution with the `-R` flag and wildcard references in the `process.args` field.
+- Examine the `process.name` field to verify which command (`chown` or `chmod`) was executed and assess the potential impact based on the command's function.
+- Check the `host.os.type` field to ensure the alert is relevant to a Linux environment, as the rule is designed for Linux systems.
+- Investigate the `event.type` and `event.action` fields to confirm the process was indeed started and executed, indicating the command was run.
+- Analyze the `process.args` field further to identify any specific patterns or anomalies in the arguments that could suggest malicious intent or misuse.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('chown', 'chmod') AND cmdline LIKE '%-R%' AND cmdline LIKE '%--reference=%';` to identify other instances of similar command executions.
+- Review system logs and audit logs for any additional context around the time of the alert to identify any preceding or subsequent suspicious activities.
+- Investigate the user account associated with the process execution to determine if the account has a history of suspicious activity or if it has been compromised.
+- Check for any recent changes in file ownership or permissions on critical files or directories that could indicate successful exploitation.
+- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use `chown` and `chmod` with recursive flags and wildcards for legitimate purposes, such as updating permissions across multiple files or directories. These actions can trigger the rule, leading to false positives.
+- Automated scripts: Scheduled scripts or cron jobs that perform regular maintenance tasks using these commands might also be flagged. These scripts are typically non-threatening if verified as part of standard operations.
+- Software installations or updates: Some software packages or updates may use these commands with wildcards during installation or configuration processes, which can be mistakenly identified as suspicious activity.
+- To manage false positives, users can create exceptions for known safe operations by whitelisting specific scripts, users, or directories that frequently trigger the rule. This can be done by adjusting the detection rule to exclude certain command patterns or by using a monitoring tool's built-in exception handling features.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the wildcard injection attack, reviewing logs and process execution details.
+- Terminate any suspicious processes that are running with elevated privileges or accessing sensitive data.
+- Review and update user permissions and access controls to ensure the principle of least privilege is enforced, reducing the risk of privilege escalation.
+- Apply patches and updates to the operating system and any vulnerable applications to mitigate known exploits, including those related to wildcard injection.
+- Implement enhanced logging policies to capture detailed command execution and process activity, aiding in future investigations.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to monitor for similar threats.
+- Restore the system to its operational state by verifying the integrity of critical files and configurations, and re-establishing network connectivity once secure.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks of wildcard injection and best practices for secure command execution to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_container_util_misconfiguration.toml b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
index b5167a53e88..c299e757a9f 100644
--- a/rules/linux/privilege_escalation_container_util_misconfiguration.toml
+++ b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and 
 process.interactive == true and process.parent.interactive == true
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via Container Misconfiguration
+
+Containers, managed by tools like runc and ctr, isolate applications for security and efficiency. Misconfigurations can allow non-root users to exploit these tools, creating privileged containers or mounting sensitive directories, potentially leading to host system access. The detection rule identifies such misuse by monitoring non-root interactive shell executions of these utilities, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
+- Verify the user context by examining `user.Ext.real.id` and `group.Ext.real.id` to confirm that the process was executed by a non-root user.
+- Check the `process.interactive` and `process.parent.interactive` fields to ensure the process was initiated through an interactive shell, which might indicate direct user involvement.
+- Investigate the parent process to understand the context of execution by examining `process.parent.name` and `process.parent.args`.
+- Use Osquery to list all running containers and their configurations to identify any suspicious or misconfigured containers. Example query: `SELECT * FROM docker_containers WHERE privileged = 1 OR mount_label LIKE '%root%';`
+- Examine the system logs for any recent changes to container configurations or permissions that might have led to the misconfiguration.
+- Review the user's command history, if available, to identify any previous commands that might indicate attempts to exploit container misconfigurations.
+- Check for any recent user account changes or privilege escalations that could have facilitated unauthorized access to container management utilities.
+- Investigate network activity from the host to identify any unusual outbound connections that might suggest data exfiltration or communication with a command and control server.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Non-root users with legitimate administrative tasks may trigger the rule if they are required to run container management commands interactively. This can occur in development environments where developers have elevated permissions to manage containers without root access.
+- Automated scripts or CI/CD pipelines that execute container commands as non-root users might be flagged if they are designed to run interactively for debugging purposes.
+- Security tools or monitoring solutions that simulate container operations to test system defenses could inadvertently match the rule's criteria if they operate under non-root accounts.
+- To manage these false positives, users can create exceptions by identifying specific user accounts or groups that are known to perform legitimate container operations. This can be done by modifying the detection rule to exclude these users or groups from triggering alerts.
+- Another approach is to refine the rule by adding conditions that check for additional context, such as specific working directories or command-line arguments that are typical of benign operations, to reduce unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
+- Conduct a thorough investigation of the container's configuration and logs to identify the misconfiguration that allowed privilege escalation.
+- Review and analyze the command history and process execution logs to determine the extent of the attack and identify any additional compromised components.
+- Revoke any unauthorized access and reset credentials for any accounts that may have been compromised during the incident.
+- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if sensitive data may have been accessed.
+- Implement enhanced logging policies to capture detailed container activity, including process execution, network connections, and file access, to aid in future investigations.
+- Integrate security monitoring tools with container orchestration platforms to provide real-time alerts on suspicious activities and potential misconfigurations.
+- Restore the affected container to its operational state by redeploying it from a known good image and ensuring all security patches and configurations are up to date.
+- Harden container security by enforcing the principle of least privilege, ensuring that containers run with the minimum necessary permissions and that sensitive directories are not mounted.
+- Regularly review and update container security policies and configurations to align with best practices and mitigate the risk of privilege escalation and container escape attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_dac_permissions.toml b/rules/linux/privilege_escalation_dac_permissions.toml
index 3cf2729319a..84836cc63c2 100644
--- a/rules/linux/privilege_escalation_dac_permissions.toml
+++ b/rules/linux/privilege_escalation_dac_permissions.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,50 @@ process.command_line:(*sudoers* or *passwd* or *shadow* or */root/*) and not (
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via Linux DAC permissions
+
+Linux Discretionary Access Control (DAC) allows file owners to set permissions, potentially leading to privilege escalation if misconfigured. Adversaries exploit DAC by using processes with capabilities like CAP_DAC_OVERRIDE to bypass permission checks. The detection rule identifies suspicious processes accessing sensitive files, excluding benign activities, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process triggered the rule, focusing on the `process.command_line` field to identify the specific command executed.
+- Check the `process.thread.capabilities.permitted` and `process.thread.capabilities.effective` fields to confirm if the process had CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH capabilities.
+- Investigate the `user.id` field to determine the user context under which the suspicious process was executed, especially if it is not the root user (ID 0).
+- Examine the `process.name` and `process.executable` fields to identify the binary responsible for the execution and verify its legitimacy.
+- Analyze the `process.parent.name` to trace the parent process and understand the process hierarchy, which might provide insights into how the process was initiated.
+- Use Osquery to gather more information about the suspicious process. For example, run the following query to list processes with DAC capabilities: `SELECT pid, name, path, uid, gid, on_disk FROM processes WHERE capabilities LIKE '%CAP_DAC_%';`
+- Investigate the file paths accessed by the process, especially those related to `*sudoers*`, `*passwd*`, `*shadow*`, or `*/root/*`, to determine if any unauthorized changes were made.
+- Cross-reference the timestamps of the alert with system logs to identify any concurrent suspicious activities or anomalies.
+- Check for any recent changes in user permissions or group memberships that might have facilitated the privilege escalation attempt.
+- Review historical data for similar alerts or patterns involving the same user, process, or file paths to assess if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives may include legitimate administrative tasks performed by system administrators or automated scripts that require elevated permissions, such as backup operations or system updates.
+- Processes like "tar", "getent", "su", "stat", "dirname", "chown", "sudo", "dpkg-split", "dpkg-deb", "dpkg", "podman", "awk", "passwd", "dpkg-maintscript-helper", "mutt_dotlock", "nscd", "logger", and "gpasswd" are often used in routine maintenance and can trigger alerts if not excluded.
+- Exclude processes with a user ID of "0" (root) as these are typically expected to have elevated permissions and are less likely to represent a threat.
+- Exclude processes with executables located in paths like /usr/lib/*/lxc/rootfs/*, which are commonly associated with containerized environments and may not pose a risk.
+- Parent processes such as "dpkg", "java", scripts ending in *postinst, "dpkg-preconfigure", and "gnome-shell" can be part of legitimate software installations or updates and should be considered for exclusion.
+- Users can manage false positives by creating exceptions for known benign processes and paths, ensuring that only truly suspicious activities are flagged for further investigation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the privilege escalation attempt, focusing on the processes flagged by the detection rule.
+- Review and analyze logs from the affected system to determine the extent of the compromise and identify any additional suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Revoke any unauthorized access and reset credentials for compromised accounts, ensuring that all passwords are strong and unique.
+- Restore the system from a known good backup to ensure that any malicious changes are removed.
+- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and detection capabilities.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for privilege escalation.
+- Conduct a security review and harden system configurations by enforcing the principle of least privilege and regularly auditing file permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
index ea2de502b4b..9d856420012 100644
--- a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
+++ b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/10"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,48 @@ process where host.os.type == "linux" and event.type == "change" and event.actio
 process.entry_leader.entry_meta.type == "container" and process.args == "nsenter" and
 process.args in ("-t", "--target") and process.args_count >= 4
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Docker Escape via Nsenter
+
+Docker containers use namespaces to isolate processes, ensuring they operate independently from the host. The `nsenter` command allows entry into these namespaces, which attackers can exploit to break out of a container and access the host system, potentially escalating privileges. The detection rule identifies suspicious UID changes involving `nsenter` within containers, signaling possible escape attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a UID change event involving `nsenter` within a container, as indicated by the query fields `event.type == "change"` and `event.action == "uid_change"`.
+- Verify the process context by examining `process.entry_leader.entry_meta.type` to ensure the event originated from a containerized environment.
+- Check the command-line arguments of the process using `process.args` to confirm the use of `nsenter` with the `-t` or `--target` options, which are indicative of namespace entry attempts.
+- Analyze the `process.args_count` to ensure it meets or exceeds 4, suggesting a potentially complex command that might be used for container escape.
+- Investigate the parent process and its command-line arguments to understand the context in which `nsenter` was executed, which might provide insights into the attacker's intentions.
+- Use Osquery to gather additional context about the container and host environment. For example, run the following query to list all running containers and their associated namespaces: `SELECT * FROM docker_containers JOIN docker_namespace ON docker_containers.id = docker_namespace.id;`
+- Examine the user and group context of the process by reviewing the UID and GID before and after the change to assess the potential impact of the privilege escalation.
+- Correlate the event with other logs and alerts from the same timeframe to identify any related suspicious activities or patterns that might indicate a broader attack.
+- Investigate the network activity associated with the container and host during the time of the alert to detect any unauthorized data exfiltration or lateral movement attempts.
+- Review historical data for similar events involving `nsenter` to determine if this is an isolated incident or part of a recurring pattern, which could indicate a persistent threat.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use `nsenter` for legitimate purposes, such as debugging or managing containers. These actions can trigger the rule, leading to false positives. To manage this, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
+- Monitoring and logging tools: Some monitoring or logging tools might use `nsenter` to gather metrics or logs from containers. These tools can be identified and excluded by specifying their process names or paths in the rule exceptions.
+- Automated scripts: Automated scripts or orchestration tools that manage container lifecycles might use `nsenter` as part of their operations. Users should identify these scripts and exclude their specific command patterns or execution contexts to reduce false positives.
+- Development and testing environments: In development or testing environments, developers might frequently use `nsenter` for testing purposes. Users can exclude specific environments or IP ranges from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the network.
+- Conduct a thorough investigation to determine the extent of the breach, focusing on identifying any unauthorized access to the host system and any changes made.
+- Review logs and audit trails to trace the attacker's actions and identify any other potentially compromised containers or systems.
+- Escalate the incident to the security operations team and, if necessary, involve legal and compliance teams to assess any regulatory implications.
+- Remediate the affected systems by removing any unauthorized changes, patching vulnerabilities, and restoring systems from clean backups if necessary.
+- Implement enhanced logging and monitoring for container activities, specifically focusing on namespace entry attempts and UID changes.
+- Integrate security tools with SIEM systems to improve detection capabilities and automate alerting for similar incidents in the future.
+- Review and update container security policies, ensuring that least privilege principles are enforced and unnecessary capabilities are removed.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate and train staff on the latest container security best practices and threat detection techniques to prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
index f3fc23dbe44..49a2f1e3c6c 100644
--- a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
+++ b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,50 @@ sequence by host.id, process.parent.entity_id with maxspan=5m
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.name == "chroot"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Chroot Container Escape via Mount
+
+Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for a mount command followed by a chroot execution, indicating a potential escape attempt.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the sequence of events, focusing on the `host.id` and `process.parent.entity_id` to ensure the events are related and occurred within the specified `maxspan=5m`.
+- Examine the `process.args` field of the mount command to identify the specific device or file system being mounted, especially looking for `/dev/sd*` patterns that suggest host file system access.
+- Check the `process.parent.name` to determine the shell used to execute the mount command, which can provide context on how the command was initiated.
+- Investigate the user account associated with the processes to determine if the user had legitimate reasons to perform these actions and if they have the necessary permissions.
+- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes executed by the same user within a short time frame: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <chroot_process_id>);`
+- Analyze the system logs around the time of the alert to identify any other suspicious activities or anomalies that might correlate with the escape attempt.
+- Check for any recent changes in user permissions or group memberships that might have inadvertently granted the necessary privileges for such an escape attempt.
+- Review the container's configuration and security settings to assess if there are any misconfigurations that could have facilitated the escape attempt.
+- Investigate any network connections initiated by the container around the time of the alert to identify potential data exfiltration or communication with external systems.
+- Correlate the findings with other security tools and logs to determine if this is an isolated incident or part of a broader attack pattern.
+
+### False positive analysis
+
+- System administrators or automated scripts may perform legitimate maintenance tasks that involve mounting file systems and using chroot, such as during system recovery or software installation, which could trigger this rule.
+- Backup or recovery operations that require mounting and chrooting into different file systems for data retrieval or restoration purposes might be flagged as false positives.
+- Developers or DevOps engineers working on containerized applications might use mount and chroot commands during testing or debugging processes, leading to benign alerts.
+- To manage these false positives, users can create exceptions for known maintenance scripts or processes by excluding specific parent process names or command arguments that are regularly used in non-threatening operations.
+- Implementing a whitelist of trusted users or processes that are known to perform these actions as part of their routine tasks can help reduce unnecessary alerts.
+- Regularly reviewing and updating the detection rule to align with the organization's operational patterns and known safe behaviors can help minimize false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the network.
+- Investigate the container's logs and process history to identify the source and method of the escape attempt, focusing on the sequence of mount and chroot commands.
+- Verify the permissions and roles assigned to the user or process that attempted the escape to ensure they are appropriate and not overly permissive.
+- Escalate the incident to the security operations team if unauthorized access to the host system is confirmed, as this may indicate a broader security breach.
+- Remediate by removing any unauthorized changes made to the host system and restoring the container to a known good state from a secure backup.
+- Implement enhanced logging policies to capture detailed command execution and file system changes within containers for future investigations.
+- Integrate security monitoring tools with SIEM systems to correlate events and detect similar escape attempts across the environment.
+- Review and update container security policies to enforce stricter isolation and limit the use of potentially dangerous commands like mount and chroot.
+- Conduct a post-incident review to identify gaps in the current security posture and develop a plan to address them, including user training and awareness.
+- Apply hardening measures such as using read-only file systems for containers, employing namespaces, and leveraging security modules like SELinux or AppArmor to restrict container capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_enlightenment_window_manager.toml b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
index facebb25242..87c58530cb6 100644
--- a/rules/linux/privilege_escalation_enlightenment_window_manager.toml
+++ b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,48 @@ sequence by host.id, process.parent.entity_id with maxspan=5s
     process.name == "enlightenment_sys" and process.args in ("/bin/mount/", "-o","noexec","nosuid","nodev","uid=*") ]
   [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via Enlightenment
+
+Enlightenment, a Linux window manager, can be exploited for privilege escalation due to a flaw in its setuid root binary, enlightenment_sys. Attackers exploit this by manipulating pathnames, gaining unauthorized root access. The detection rule identifies this by monitoring specific process executions and subsequent unauthorized user ID changes, flagging potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and process.parent.entity_id associated with the suspicious activity, ensuring you have the correct context for the investigation.
+- Verify the process execution by checking the process.name and process.args fields to confirm that the process "enlightenment_sys" was executed with the specific arguments ("/bin/mount/", "-o", "noexec", "nosuid", "nodev", "uid=*").
+- Investigate the timeline of events by examining the sequence of process executions and user ID changes within the maxspan of 5 seconds to identify any anomalies or patterns.
+- Check the user.id field to confirm if there was an unauthorized change to user ID "0", indicating a potential privilege escalation attempt.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'enlightenment_sys';` to retrieve details about the process, including its parent process, user, and execution path.
+- Investigate the parent process of "enlightenment_sys" using the process.parent.entity_id to understand the origin of the execution and whether it was initiated by a legitimate or suspicious process.
+- Examine system logs for any additional context around the time of the alert, focusing on authentication logs and any other security-related logs that might indicate unauthorized access attempts.
+- Review the system's history of privilege escalation attempts by searching for similar patterns or alerts in the past, which might indicate a recurring issue or targeted attack.
+- Analyze the host's environment for any recent changes or anomalies, such as new software installations or configuration changes, that could have facilitated the exploitation attempt.
+- Cross-reference the alert with known threat intelligence sources to determine if the activity matches any known attack patterns or threat actor behaviors associated with CVE-2022-37706.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may execute the `enlightenment_sys` binary with specific arguments for maintenance or configuration purposes, which could trigger the detection rule. To manage this, users can create exceptions for known administrative scripts or processes that regularly perform these tasks.
+- Automated scripts: Some automated scripts or system management tools might use `enlightenment_sys` for legitimate operations, leading to false positives. Users should identify these scripts and whitelist them to prevent unnecessary alerts.
+- Testing environments: In environments where security testing or development is conducted, the execution of `enlightenment_sys` with root privileges might be part of routine testing. Users can exclude specific testing environments or IP ranges from the rule to reduce false positives.
+- System updates: During system updates, certain processes might temporarily mimic the behavior flagged by the rule. Users should monitor update schedules and consider temporary exceptions during these periods to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the exploitation by reviewing logs and correlating events with the detection rule, focusing on unauthorized user ID changes and suspicious process executions.
+- If exploitation is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Remove or disable the vulnerable version of Enlightenment (before 0.25.4) and replace it with the latest patched version to mitigate the vulnerability.
+- Review and update system and application logging policies to ensure comprehensive coverage of process executions, user ID changes, and other relevant security events.
+- Implement additional security monitoring and alerting for similar privilege escalation attempts, leveraging MITRE ATT&CK framework techniques such as T1068 for context.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure no unauthorized changes persist.
+- Conduct a post-incident review to identify gaps in detection and response, and update incident response plans accordingly.
+- Enhance system hardening by applying the principle of least privilege, ensuring that only necessary permissions are granted to users and processes.
+- Consider integrating additional security tools and technologies, such as endpoint detection and response (EDR) solutions, to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
index 10697c46f3a..6ef74ffde34 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,48 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=1m
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.name != null and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privilege Escalation via GDB CAP_SYS_PTRACE
+
+The CAP_SYS_PTRACE capability in Linux allows processes to trace and control other processes, a feature primarily used for debugging. Adversaries can exploit this by using GDB with this capability to inject code into processes running as root, thereby escalating privileges. The detection rule identifies such abuse by monitoring sequences where GDB is executed with CAP_SYS_PTRACE, followed by a process running as root, indicating potential privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of GDB execution with CAP_SYS_PTRACE capability by checking the `process.name` and `process.thread.capabilities.effective` or `process.thread.capabilities.permitted` fields.
+- Verify the sequence of events by examining the `host.id` and `process.entry_leader.entity_id` to ensure the alert is not a false positive due to unrelated processes.
+- Check the `user.id` field to confirm that the process was executed by a non-root user before the privilege escalation attempt.
+- Investigate the parent process of GDB using the `process.parent.name` and `process.parent.pid` fields to understand the context in which GDB was executed.
+- Use Osquery to list all processes with CAP_SYS_PTRACE capability by running: `SELECT pid, name, uid, gid, capabilities FROM processes WHERE capabilities LIKE '%CAP_SYS_PTRACE%';`
+- Examine the command line arguments of the GDB process using the `process.args` field to identify any suspicious or unusual parameters that might indicate malicious intent.
+- Review the timeline of events around the alert using the `@timestamp` field to identify any other suspicious activities or anomalies occurring concurrently.
+- Check the system logs for any unauthorized access attempts or anomalies around the time of the alert to gather additional context.
+- Investigate the user account associated with the alert by reviewing the `user.id` and `user.name` fields to determine if the account has been compromised or is behaving unusually.
+- Correlate the findings with other security tools and logs to identify any patterns or indicators of compromise that align with the privilege escalation attempt.
+
+### False positive analysis
+
+- Development and debugging activities: Developers and system administrators may use GDB with CAP_SYS_PTRACE for legitimate debugging purposes, which can trigger the detection rule. To manage this, users can create exceptions for specific user accounts or processes that are known to perform regular debugging tasks.
+- Automated testing environments: In environments where automated testing frameworks utilize GDB for testing applications, the rule may generate false positives. Users can handle these by excluding specific testing processes or environments from the rule.
+- Security tools and monitoring software: Some security tools may use GDB with CAP_SYS_PTRACE as part of their monitoring or analysis functions. Users should identify and whitelist these tools to prevent false positives.
+- System maintenance scripts: Scheduled maintenance scripts that require debugging capabilities might inadvertently trigger the rule. Users can exclude these scripts by specifying their process names or execution times in the rule exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the presence of unauthorized processes or code injections by reviewing process trees and system logs for anomalies.
+- Terminate any suspicious processes that are running with elevated privileges and were not initiated by legitimate users or administrators.
+- Conduct a thorough investigation to identify the source of the privilege escalation attempt, including reviewing user activity logs and access records.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Restore the system to a known good state by reverting to a clean backup or reinstalling the operating system if necessary.
+- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that CAP_SYS_PTRACE usage is monitored.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve visibility and detection capabilities.
+- Apply system hardening measures, such as removing unnecessary capabilities from processes, enforcing the principle of least privilege, and regularly updating software to patch vulnerabilities.
+- Educate users and administrators on the risks associated with debugging tools and the importance of maintaining secure configurations to prevent privilege escalation attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
index 68dcaefd123..d3ae3ba7112 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,52 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=30s
   [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
    process.name != null and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Root Network Connection via GDB CAP_SYS_PTRACE
+
+GDB, a debugger, can be granted the CAP_SYS_PTRACE capability, allowing it to trace and control processes, a feature often exploited by attackers. By injecting code into root processes, adversaries can execute malicious payloads, such as reverse shells. The detection rule identifies this by monitoring GDB executions with CAP_SYS_PTRACE followed by root-initiated network connections, signaling potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of GDB execution with CAP_SYS_PTRACE capability and subsequent root-initiated network connection.
+- Verify the process entry leader entity ID and host ID to ensure the sequence of events occurred on the same host and process context.
+- Check the timestamp of the GDB execution and the network connection attempt to confirm they fall within the 30-second maxspan window.
+- Investigate the user context by examining the user ID associated with the GDB process to ensure it is not root (user.id != "0").
+- Use Osquery to list all processes with CAP_SYS_PTRACE capability on the host to identify any other potentially suspicious processes:
+  ```sql
+  SELECT pid, name, uid, gid, path FROM processes WHERE capabilities LIKE '%CAP_SYS_PTRACE%';
+  ```
+- Analyze the network connection details, including destination IP and port, to determine if the connection is to a known malicious or suspicious address.
+- Review the process tree to identify the parent process of GDB and any child processes spawned, which may provide insight into how GDB was executed.
+- Check system logs for any unusual activity or errors around the time of the alert to gather additional context.
+- Investigate the binary and hash of the GDB executable to ensure it has not been tampered with or replaced by a malicious version.
+- Correlate with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Development and debugging activities: Developers often use GDB with CAP_SYS_PTRACE for legitimate debugging purposes, which may trigger the rule when a root process initiates a network connection as part of normal operations. Users can handle these by creating exceptions for known development environments or specific user accounts frequently involved in debugging.
+- Automated system maintenance scripts: Some automated scripts running with root privileges might use GDB for monitoring or maintenance tasks, leading to false positives. Identifying and excluding these scripts from monitoring can reduce unnecessary alerts.
+- Security tools and monitoring software: Certain security tools may use GDB with CAP_SYS_PTRACE to monitor processes for security purposes, which could be misinterpreted as malicious activity. Users should whitelist these tools to prevent false positives.
+- Testing environments: In testing environments, GDB might be used extensively to simulate various scenarios, including network connections by root processes. Users can exclude specific testing environments or IP ranges to minimize false alerts.
+- Custom applications: Organizations may have custom applications that legitimately use GDB with CAP_SYS_PTRACE for process management or debugging. Users should document and exclude these applications from the rule to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement.
+- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing logs and identifying any unauthorized use of GDB with CAP_SYS_PTRACE.
+- Terminate any suspicious processes initiated by GDB and any unauthorized network connections to mitigate ongoing threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Review and analyze system logs, including process execution and network connection logs, to identify any additional indicators of compromise (IOCs) or related malicious activities.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that CAP_SYS_PTRACE usage is monitored closely.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Restore the system to a known good state by reinstalling the operating system and applications, ensuring all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting the use of CAP_SYS_PTRACE to trusted users and processes, and regularly auditing system capabilities and permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_kworker_uid_elevation.toml b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
index f17fb467fd1..75b9e3b6812 100644
--- a/rules/linux/privilege_escalation_kworker_uid_elevation.toml
+++ b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,51 @@ query = '''
 process where host.os.type == "linux" and event.action == "session_id_change" and process.name : "kworker*" and
 user.id == "0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Kworker UID Elevation
+
+Kworker processes are integral to Linux, handling tasks like interrupts and background activities in kernel space. Adversaries may exploit these by masquerading as kworker processes to gain root access, often using rootkits to hijack execution flow. The detection rule identifies such abuse by monitoring for kworker processes that change session IDs and elevate user permissions to root, signaling potential privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name matches "kworker*" and the user ID is "0", indicating a potential privilege escalation.
+- Check the session ID change event to determine the previous and new session IDs, which can provide context on the session transition.
+- Investigate the parent process of the kworker process to identify if it was spawned by a legitimate kernel process or an unexpected user-space process.
+- Use Osquery to list all running kworker processes and their associated user IDs to identify any discrepancies or anomalies:
+  ```sql
+  SELECT pid, name, uid, parent FROM processes WHERE name LIKE 'kworker%';
+  ```
+- Examine the process tree to trace the lineage of the suspicious kworker process and identify any unusual parent-child relationships.
+- Analyze recent system logs for any unusual activities or errors around the time of the session ID change event to gather additional context.
+- Check for any recent modifications to kernel modules or system binaries that could indicate the presence of a rootkit.
+- Review user login and authentication logs to identify any unauthorized access attempts or successful logins around the time of the alert.
+- Investigate network activity from the host to detect any suspicious outbound connections that could indicate data exfiltration or command-and-control communication.
+- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Legitimate system maintenance tasks or updates may trigger session ID changes in kworker processes, leading to false positives. Users can monitor the timing of these alerts to correlate with scheduled maintenance activities and create exceptions for these periods.
+- Custom kernel modules or drivers that interact with kworker processes might inadvertently cause session ID changes. Users should review and whitelist known safe modules or drivers that are part of their standard operating environment.
+- Certain security tools or monitoring solutions may interact with kworker processes for legitimate reasons, causing session ID changes. Users should identify these tools and configure the detection rule to exclude their activity by specifying process names or user IDs associated with these tools.
+- In environments with automated scripts or cron jobs that require elevated permissions, kworker processes might be used as part of the execution flow. Users should document these scripts and create exceptions for their associated kworker activities to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the presence of a rootkit by analyzing system logs, process trees, and any anomalous behavior associated with kworker processes.
+- Utilize forensic tools to capture memory and disk images for detailed analysis and evidence preservation.
+- If a rootkit is confirmed, perform a full system scan using updated antivirus and anti-malware tools to identify and remove malicious components.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Restore the system from a known good backup to ensure all malicious modifications are removed, and verify the integrity of the restored system.
+- Implement enhanced logging policies to capture detailed process execution and user activity, focusing on session ID changes and privilege escalations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Review and update access controls and user permissions to minimize the risk of privilege escalation, ensuring the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in the current security posture and apply hardening measures, such as kernel module signing and regular integrity checks, to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
index c1188e26d75..3f2fb6fa356 100644
--- a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
+++ b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,51 @@ query = '''
 host.os.type:linux and event.category:file and event.action:(updated or renamed or rename or file_rename_event) and 
 not event.type:deletion and file.path:/etc/ld.so.preload and not process.name:(wine or oneagentinstallaction)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Dynamic Linker Preload Shared Object
+
+The dynamic linker preload mechanism in Linux, controlled via `/etc/ld.so.preload`, allows preloading of shared libraries before others. Adversaries exploit this by inserting malicious libraries, hijacking execution flow for privilege escalation. The detection rule monitors changes to this file, excluding benign processes, to identify unauthorized modifications indicative of such abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is `/etc/ld.so.preload` and verify the event action is either `updated`, `renamed`, or `file_rename_event`.
+- Check the `process.name` field to ensure the process responsible for the modification is not `wine` or `oneagentinstallaction`, as these are excluded from the rule.
+- Investigate the `host.os.type` field to confirm the operating system is Linux, as this rule is specific to Linux environments.
+- Use Osquery to list the current contents of `/etc/ld.so.preload` to identify any suspicious or unexpected libraries being preloaded:
+  ```sql
+  SELECT * FROM file WHERE path = '/etc/ld.so.preload';
+  ```
+- Examine the `event.category` field to ensure it is categorized as a `file` event, confirming the nature of the alert.
+- Investigate the process that made the modification by checking the process ID and command line arguments to understand the context of the change.
+- Review recent system logs and audit logs around the time of the modification for any additional suspicious activity or related events.
+- Check the user account associated with the process that modified the file to determine if it has the necessary privileges and if the activity aligns with normal behavior for that account.
+- Investigate any recent changes in user permissions or group memberships that could have allowed unauthorized access to modify `/etc/ld.so.preload`.
+- Correlate this event with other alerts or anomalies in the environment to identify potential patterns or coordinated activities that could indicate a broader attack.
+
+### False positive analysis
+
+- Routine system updates or legitimate software installations may modify `/etc/ld.so.preload`, triggering the detection rule. Users can handle these by creating exceptions for known update processes or installation scripts.
+- Security tools or monitoring agents, such as OneAgent, may interact with the preload file as part of their normal operations. Exclude these processes by adding them to the exception list in the detection rule.
+- Custom scripts or administrative tasks performed by system administrators might also lead to modifications. Ensure these activities are documented and consider excluding specific scripts or user actions if they are verified as non-threatening.
+- In environments using Wine, the process may interact with the preload file, leading to false positives. Exclude the Wine process from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the unauthorized modification, focusing on recent changes and user activity logs.
+- Verify the integrity of the `/etc/ld.so.preload` file by comparing it with a known good backup or baseline configuration.
+- Remove any unauthorized or suspicious entries from the `/etc/ld.so.preload` file and restore it to its original state.
+- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious payloads.
+- Review user accounts and privileges on the system to ensure no unauthorized access or privilege escalation has occurred.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging and monitoring for critical system files and processes, including `/etc/ld.so.preload`, to detect future unauthorized modifications.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate events across the network.
+- Apply system hardening measures, such as restricting write access to critical files and directories, and regularly update and patch the system to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
index f1192e1a86d..f1d89da9a2f 100644
--- a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
+++ b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/30"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,49 @@ process.name == "ln" and process.args in ("-s", "-sf") and
   process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
   not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Symbolic Link Created
+Symbolic links in Linux are shortcuts that point to files or directories, facilitating easy access. Adversaries exploit them to redirect privileged processes to sensitive files, potentially escalating privileges. The detection rule identifies such abuse by monitoring the creation of symbolic links to critical files or directories, especially when executed by non-root users, indicating possible malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific symbolic link creation event, focusing on the `process.name`, `process.args`, and `process.working_directory` fields to understand the context of the command executed.
+- Verify the user context by examining the `user.Ext.real.id` and `group.Ext.real.id` fields to confirm that the action was performed by a non-root user, which could indicate potential privilege escalation attempts.
+- Check the parent process information using the `process.parent.name` field to determine if the symbolic link creation was initiated from a shell, which might suggest a script or manual command execution.
+- Investigate the target of the symbolic link by reviewing the `process.args` field to identify if it points to any critical files or directories, such as `/etc/shadow` or `/bin/bash`.
+- Use Osquery to list all symbolic links in the system and their targets to identify any other potentially malicious links. Example query: `SELECT * FROM file WHERE type = 'symlink';`
+- Examine the user's command history, if available, to identify any preceding commands that might provide context or indicate malicious intent.
+- Review system logs around the time of the event for any other suspicious activities or related events that could provide additional context.
+- Check for any recent changes to the files or directories targeted by the symbolic link to assess if any unauthorized modifications have occurred.
+- Investigate the user's recent login activity and source IP addresses to determine if there are any anomalies or indications of unauthorized access.
+- Correlate this event with other alerts or incidents involving the same user or system to identify patterns or ongoing attack campaigns.
+
+### False positive analysis
+
+- System administrators or automated scripts may create symbolic links to critical files for legitimate purposes, such as backups or system maintenance, which can trigger false positives.
+- Development environments might use symbolic links to manage dependencies or configurations, especially in shared directories, leading to benign alerts.
+- Some software installations or updates might create symbolic links to binaries or configuration files as part of their setup process, which could be misinterpreted as suspicious activity.
+- To manage these false positives, users can create exceptions for known benign processes or users by excluding specific user IDs or process names that are verified as non-threatening.
+- Implementing a whitelist of trusted directories or files that are frequently linked in a non-malicious context can help reduce unnecessary alerts.
+- Regularly review and update the detection rule to accommodate changes in legitimate system behavior, ensuring that only truly suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Investigate the symbolic link creation event by reviewing logs and process details to identify the source and intent of the action.
+- Verify the integrity of critical files and directories, such as /etc/shadow and /etc/sudoers, to ensure they have not been tampered with.
+- Remove any unauthorized symbolic links and restore any altered files from a known good backup.
+- Conduct a thorough review of user accounts and permissions, focusing on non-root users who executed the suspicious command, to identify potential privilege escalation paths.
+- Escalate the incident to the security operations team if evidence of privilege escalation or further compromise is found.
+- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate security tools with SIEM solutions to automate the detection of suspicious symbolic link creation and other privilege escalation attempts.
+- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all security controls are active and functioning.
+- Harden the system by implementing least privilege principles, restricting the use of symbolic links, and regularly auditing critical system files and directories."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
index 3cef1b9dacb..2661bbe3cc6 100644
--- a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
+++ b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,48 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
 process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via UID INT_MAX Bug Detected
+
+In certain Linux environments, a bug in older versions allows users with a UID exceeding INT_MAX to gain elevated privileges by executing commands via systemd-run. Adversaries exploit this by spawning privileged shells, bypassing standard security controls. The detection rule identifies such exploitation attempts by monitoring systemd-run executions with unusually high UIDs, signaling potential privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a UID greater than INT_MAX, specifically checking the `user.id` field to ensure it meets the threshold of "1000000000" or higher.
+- Examine the `process.name` and `process.args` fields to verify that the command executed was indeed `systemd-run` with the `-t` argument, indicating an attempt to spawn a shell.
+- Check the `event.type` and `event.action` fields to confirm that the event was a process start and involved execution, aligning with the conditions specified in the detection rule.
+- Investigate the user account associated with the high UID by querying the `/etc/passwd` file to gather more information about the account, such as its creation date and any associated comments.
+- Use Osquery to list all processes started by the suspicious UID to identify any other potentially malicious activities. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE uid = <suspicious_uid>;`
+- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual login attempts or authentication failures associated with the high UID.
+- Review the systemd service logs using `journalctl` to trace the execution history of `systemd-run` commands and identify any patterns or anomalies.
+- Check for any recent changes to user accounts or group memberships that might indicate unauthorized modifications, using commands like `getent passwd` and `getent group`.
+- Investigate network activity from the host to identify any suspicious outbound connections or data exfiltration attempts that might correlate with the privilege escalation attempt.
+- Correlate the findings with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign or an isolated incident.
+
+### False positive analysis
+
+- Users with legitimate high UIDs: In some organizations, system administrators may assign high UIDs for specific service accounts or applications, which could trigger the rule. To manage this, create exceptions for known service accounts by adding their UIDs to an exclusion list.
+- Testing environments: Developers or security teams might intentionally use high UIDs in testing environments to simulate attacks or test system responses. These activities can be excluded by filtering out events from designated testing servers or environments.
+- Legacy systems: Some older systems might have configurations that inadvertently assign high UIDs to certain users. Review and update these configurations to prevent unnecessary alerts, or exclude these systems from the rule if they are known to be non-threatening.
+- Automated scripts: Scripts that require elevated privileges might be configured to use high UIDs for execution. Identify and document these scripts, then exclude their associated UIDs from the detection rule to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Verify the UID of the user executing the systemd-run command and confirm if it exceeds INT_MAX, indicating potential exploitation.
+- Conduct a thorough investigation of the affected system to identify any unauthorized changes or additional malicious activities, focusing on processes and files accessed by the high UID user.
+- Review system logs and security alerts to trace the origin of the attack and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a broader campaign.
+- Apply patches or updates to the affected system to address the UID INT_MAX bug, ensuring all systems are running supported and secure versions of Linux.
+- Implement enhanced logging policies to capture detailed information on process executions, user activities, and system changes, aiding future investigations.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
+- Restore the system to its operational state by removing any unauthorized changes, verifying system integrity, and re-enabling network connectivity once secure.
+- Harden the system by enforcing least privilege access controls, regularly reviewing user accounts and permissions, and conducting security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
index 37df7e1b9b4..f225536eb41 100644
--- a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
+++ b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/09"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
  and process.name == "kexec" and process.args in ("--exec", "-e", "--load", "-l", "--unload", "-u") and not
  process.parent.name in ("kdumpctl", "unload.sh")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kernel Load or Unload via Kexec Detected
+
+Kexec is a Linux utility that allows a new kernel to be loaded and executed without rebooting, facilitating quick kernel updates. However, attackers can exploit kexec to load malicious kernels, bypassing security controls and gaining unauthorized access or persistence. The detection rule identifies suspicious kexec usage by monitoring process execution patterns, focusing on specific arguments and excluding legitimate parent processes, thus highlighting potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the kexec process execution with suspicious arguments such as "--exec", "-e", "--load", "-l", "--unload", or "-u".
+- Verify the parent process of the kexec execution to ensure it is not a legitimate process like "kdumpctl" or "unload.sh", which are excluded in the detection rule.
+- Check the user account associated with the kexec process execution to determine if it has the necessary privileges and if the activity aligns with their typical behavior.
+- Investigate the command line arguments used with the kexec process to understand the intent and scope of the kernel load or unload operation.
+- Use Osquery to gather additional context about the kexec process by running a query such as: `SELECT * FROM processes WHERE name = 'kexec';` to retrieve details like process ID, parent process ID, and execution path.
+- Examine system logs and audit logs for any related entries around the time of the kexec execution to identify any preceding or subsequent suspicious activities.
+- Analyze network traffic logs to detect any unusual outbound connections or data exfiltration attempts that might coincide with the kexec activity.
+- Check for any recent changes to kernel modules or system configurations that could indicate tampering or unauthorized modifications.
+- Investigate other processes running on the system that might have been initiated by the same user or parent process to identify potential lateral movement or further compromise.
+- Correlate the kexec activity with other security alerts or incidents in the environment to determine if it is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate system maintenance activities: System administrators may use kexec for legitimate kernel updates or system maintenance tasks. These activities can trigger the detection rule if they involve the specified arguments. To manage this, users can create exceptions for known maintenance scripts or processes by adding them to the exclusion list of parent processes.
+- Automated backup or recovery processes: Some automated scripts or tools, such as kdumpctl, may use kexec as part of their normal operation for system recovery or backup purposes. These should be excluded by verifying the parent process and adding it to the exclusion list if deemed non-threatening.
+- Custom scripts for performance testing: Developers or system engineers might use custom scripts that leverage kexec for performance testing or system optimization. Users should review these scripts and, if they are verified as safe, add them to the list of exceptions to prevent false positives.
+- Security tools or monitoring solutions: Certain security tools might use kexec to test system resilience or for other security-related tasks. Users should identify these tools and exclude them from the detection rule by specifying their parent processes in the exclusion criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the presence of a malicious kernel by analyzing system logs, process trees, and any anomalies in kernel behavior.
+- Utilize forensic tools to capture memory and disk images for further analysis and evidence preservation.
+- If a malicious kernel is confirmed, initiate a system recovery process by restoring from a known good backup or reinstalling the operating system.
+- Review and update security policies to restrict the use of kexec to authorized personnel only, potentially disabling it if not required for operational purposes.
+- Implement enhanced logging and monitoring for kexec usage and other critical system processes to detect future unauthorized activities.
+- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat visibility and response capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply system hardening measures, such as enabling secure boot, applying the latest security patches, and configuring kernel parameters to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
index 75d12aa5a97..a971b99b697 100644
--- a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
+++ b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,48 @@ sequence by host.id, process.parent.entity_id, process.executable with maxspan=5
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
   process.env_vars : "*GLIBC_TUNABLES=glibc.*=glibc.*=*"] with runs=5
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via CVE-2023-4911
+
+CVE-2023-4911 exploits a buffer overflow in the GNU C Library's dynamic loader, specifically targeting the GLIBC_TUNABLES environment variable. This vulnerability allows attackers to manipulate memory, potentially escalating privileges. The detection rule identifies suspicious activity by monitoring Linux processes for specific environment variable patterns, flagging rapid, repeated execution attempts indicative of exploitation efforts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the GLIBC_TUNABLES environment variable pattern in the process execution, as indicated by the query.
+- Identify the host and process information from the alert, focusing on `host.id`, `process.parent.entity_id`, and `process.executable` fields to understand which system and application are involved.
+- Check the frequency and timing of the alert by examining the `maxspan=5s` and `runs=5` parameters to determine if the execution attempts are rapid and repeated, suggesting exploitation.
+- Use Osquery to list all processes on the affected host that have the GLIBC_TUNABLES environment variable set. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%GLIBC_TUNABLES=glibc%'`.
+- Investigate the parent process (`process.parent.entity_id`) to determine if it is a legitimate process or potentially compromised, which could indicate how the exploit was initiated.
+- Analyze the `process.executable` path to verify if it is a known and trusted application or if it has been tampered with or replaced.
+- Cross-reference the alert with any recent changes or updates on the affected host that might have introduced the vulnerability or been exploited.
+- Check system logs and audit logs on the affected host for any unusual activity or errors related to the dynamic loader or GLIBC_TUNABLES environment variable.
+- Investigate network activity from the affected host around the time of the alert to identify any suspicious outbound connections or data exfiltration attempts.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack campaign or isolated incident.
+
+### False positive analysis
+
+- Known false positives for the CVE-2023-4911 detection rule may arise from legitimate applications or scripts that frequently set the GLIBC_TUNABLES environment variable for performance tuning or compatibility reasons. These applications might trigger the rule due to their rapid execution patterns, which mimic exploitation attempts.
+- System administrators can manage these false positives by identifying and documenting legitimate processes that use GLIBC_TUNABLES. Once identified, these processes can be excluded from the detection rule by creating exceptions based on specific process names, paths, or other unique identifiers.
+- Another approach to handle false positives is to adjust the detection rule's sensitivity by increasing the threshold for the number of rapid executions or extending the time window (maxspan) to better differentiate between benign and malicious activities.
+- Regularly reviewing and updating the list of exceptions is crucial, as software updates or changes in system configurations might alter the behavior of legitimate applications, potentially leading to new false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to confirm the presence of CVE-2023-4911 exploitation by reviewing logs and correlating with the detection rule's findings.
+- Terminate any suspicious processes identified as exploiting the GLIBC_TUNABLES environment variable to halt ongoing attacks.
+- Apply the latest security patches and updates to the GNU C Library to mitigate the vulnerability.
+- Restore the system from a known good backup taken before the exploitation occurred to ensure system integrity.
+- Implement enhanced logging policies to capture detailed process execution and environment variable changes for future analysis.
+- Integrate security solutions with SIEM systems to improve detection capabilities and automate alerting for similar threats.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly auditing environment variables for anomalies."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
index 19d9e7e5aa4..54785d68578 100644
--- a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
+++ b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,49 @@ event.action in ("connection_attempted", "ipv4_connection_attempt_event") and pr
   )
 ) 
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Connection via Sudo Binary
+
+The 'sudo' command in Linux allows users to execute commands with elevated privileges, typically as the root user. Adversaries may exploit this by injecting malicious code into processes running with these privileges, potentially establishing unauthorized network connections. The detection rule identifies unusual network activity initiated by 'sudo', excluding common internal IP ranges, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "sudo" and verify the event type is "start" with actions "connection_attempted" or "ipv4_connection_attempt_event".
+- Check the destination IP address to ensure it is not within the excluded internal IP ranges, indicating a potential external connection.
+- Investigate the command line arguments used with the "sudo" process to identify any suspicious or unexpected commands that may have been executed.
+- Examine the user account associated with the "sudo" command to determine if the account has a history of legitimate use or if it might be compromised.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'sudo';` to retrieve details about the process, including its parent process and command line.
+- Analyze the parent process of the "sudo" command to understand the context in which it was executed and identify any potential anomalies.
+- Review recent authentication logs to check for unusual login attempts or successful logins around the time the "sudo" command was executed.
+- Investigate network logs to identify any other unusual or unauthorized network connections from the host around the same time as the alert.
+- Check for any recent changes to the system's sudoers file that might allow unauthorized users to execute commands with elevated privileges.
+- Correlate the alert with other security events or alerts from the same host to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- **Administrative Scripts**: Some legitimate administrative scripts or tools may use 'sudo' to initiate network connections for system updates or configuration management. Users can handle these by identifying and excluding specific scripts or processes that are known to perform these actions regularly.
+- **Monitoring and Management Tools**: Network monitoring or management tools that require elevated privileges might trigger this rule. Users should review and whitelist these tools if they are verified to be safe and necessary for operations.
+- **Backup and Synchronization Services**: Services that perform backups or data synchronization might use 'sudo' to access network resources. Users can create exceptions for these services by specifying their process names or network destinations.
+- **Custom Internal Applications**: In some environments, custom applications may be designed to run with elevated privileges and initiate network connections. Users should document these applications and exclude them from the rule to prevent false positives.
+- **Testing and Development Environments**: Developers or testers might use 'sudo' to simulate network connections for testing purposes. Users can manage these by setting up separate rules or exceptions for known testing environments or IP ranges.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on logs related to the 'sudo' command and network connections.
+- Terminate any suspicious processes that were initiated by 'sudo' and verify the integrity of system binaries and configurations.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Review and enhance logging policies to ensure comprehensive monitoring of privileged command executions and network activities.
+- Implement additional security measures such as multi-factor authentication for privileged accounts and regular audits of sudoers files.
+- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of maintaining secure practices.
+- Consider deploying endpoint detection and response (EDR) solutions to improve visibility and response capabilities for future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
index a62129ec619..65d15832383 100644
--- a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
+++ b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,48 @@ sequence by process.parent.entity_id, host.id with maxspan=5s
   [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
     user.id == "0"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via OverlayFS
+
+OverlayFS is a union filesystem used in Linux environments to overlay one filesystem on top of another, allowing for efficient file management and updates. Adversaries exploit vulnerabilities in Ubuntu's OverlayFS modifications to execute crafted executables that elevate privileges to root. The detection rule identifies suspicious sequences involving the 'unshare' command with specific arguments and subsequent UID changes to root, indicating potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'unshare' command with suspicious arguments such as "-r", "-rm", "m", and "*cap_setuid*". Verify that the user ID is not "0" in the initial process execution.
+- Check the sequence of events to ensure that a UID change to "0" (root) occurred within 5 seconds of the 'unshare' command execution, as indicated by the query.
+- Investigate the parent process of the 'unshare' command by examining the `process.parent.entity_id` to understand the context and origin of the suspicious activity.
+- Use Osquery to gather more information about the processes involved. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, uid FROM processes WHERE uid = <user_id> ORDER BY start_time DESC LIMIT 10;`.
+- Examine the `host.id` field to identify the specific host involved in the alert and gather additional context about its role and importance within the network.
+- Check system logs on the affected host for any additional suspicious activity or errors around the time of the alert, focusing on authentication logs and system logs.
+- Investigate any recent changes or updates to the OverlayFS configuration or related packages on the affected host to identify potential sources of the vulnerability.
+- Review user activity and permissions for the user account involved in the alert to determine if there are any anomalies or unauthorized privilege assignments.
+- Analyze network traffic logs from the affected host to detect any unusual outbound connections or data exfiltration attempts that might correlate with the privilege escalation attempt.
+- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks involving OverlayFS exploitation.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use the 'unshare' command with similar arguments for legitimate purposes, such as container management or system maintenance, which could trigger the rule. To manage this, users can create exceptions for known administrative scripts or processes that frequently execute these commands.
+- Development and testing environments: Developers might use the 'unshare' command with the specified arguments during software testing or development, especially in environments that mimic production settings. Users can exclude specific development environments or user accounts from triggering alerts by setting up exceptions based on user roles or environment identifiers.
+- Automated scripts and tools: Some automated tools or scripts designed for system configuration or monitoring might inadvertently match the rule's criteria. Users should review these tools and, if deemed safe, add them to an allowlist to prevent false positives.
+- Custom security solutions: Organizations with custom security solutions that involve UID changes might see false positives. In such cases, users should document these solutions and configure the detection rule to exclude these specific processes or actions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Conduct a thorough investigation to confirm the exploitation of CVE-2023-2640 or CVE-2023-32629 by reviewing logs and identifying any unauthorized privilege escalations.
+- Terminate any suspicious processes identified in the detection rule, particularly those involving the 'unshare' command with the specified arguments.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Apply available patches or updates from Ubuntu to address the vulnerabilities in OverlayFS and prevent future exploitation.
+- Review and enhance logging policies to ensure comprehensive monitoring of privilege escalation attempts, focusing on command execution and UID changes.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
+- Restore the system to its operational state by verifying the integrity of critical files and configurations, and ensure no backdoors or malicious modifications remain.
+- Implement hardening measures, such as restricting the use of the 'unshare' command to trusted users and processes, and enforcing the principle of least privilege.
+- Document the incident and response actions taken, and update incident response plans and security policies to incorporate lessons learned and improve future readiness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
index ca808d17266..7e9183dbe4c 100644
--- a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
+++ b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and file.path : "/*GCONV_PATH*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via PKEXEC
+
+Polkit's pkexec is a command-line tool used in Linux environments to execute commands as another user, typically root, by leveraging policies. Adversaries exploit vulnerabilities like CVE-2021-4034 by injecting unsecure environment variables, allowing unauthorized privilege escalation. The detection rule identifies suspicious file paths indicative of such exploitation attempts, focusing on patterns linked to environment variable manipulation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the suspicious file path pattern `/*GCONV_PATH*` on a Linux host, as this is indicative of potential exploitation attempts.
+- Verify the host's operating system type to ensure it matches "linux," as the rule is specifically designed for Linux environments.
+- Check the file creation and modification timestamps to determine when the suspicious file path was accessed or altered, which can help establish a timeline of events.
+- Use Osquery to list all environment variables set for processes running on the affected host to identify any unsecure or unusual entries. Example query: `SELECT pid, name, path, cmdline, environ FROM processes WHERE path LIKE '%pkexec%';`
+- Investigate the user account associated with the suspicious activity to determine if it has a history of privilege escalation attempts or other suspicious behavior.
+- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any entries related to pkexec usage or unauthorized access attempts around the time of the alert.
+- Analyze the process tree to identify parent and child processes of pkexec, which may reveal the origin of the exploitation attempt and any subsequent actions taken by the adversary.
+- Check for any recent changes to polkit configurations or policies that could have been exploited to facilitate the privilege escalation.
+- Review network activity logs to identify any external connections or data exfiltration attempts that may have occurred following the privilege escalation.
+- Correlate the findings with other security alerts or incidents to determine if this is part of a larger attack campaign targeting the organization.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the detection rule if they temporarily use environment variables that match the suspicious patterns, such as those involving GCONV_PATH. Users should verify the source and context of these activities to determine if they are benign.
+- Custom scripts or administrative tools that manipulate environment variables for configuration purposes might also match the detection criteria. Users can create exceptions for these known scripts by specifying their file paths or process names in the detection rule.
+- Development environments where developers frequently test or debug applications using environment variables may inadvertently trigger the rule. In such cases, users can whitelist specific development directories or user accounts to reduce noise.
+- Automated system management tools that perform legitimate privilege escalation tasks might be flagged. Users should review these tools and, if deemed safe, add them to an exception list to prevent false positives.
+- To manage false positives effectively, users can implement a logging and review process to regularly assess flagged activities, ensuring that only non-threatening behaviors are excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Conduct a thorough investigation to confirm the exploitation of CVE-2021-4034 by reviewing logs and identifying any unauthorized changes or suspicious activities.
+- If exploitation is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Apply the latest security patches and updates for polkit and pkexec to mitigate the vulnerability and prevent future exploitation.
+- Review and enhance logging policies to ensure comprehensive monitoring of environment variable manipulations and pkexec usage.
+- Implement additional security controls such as application whitelisting and least privilege access to reduce the attack surface.
+- Restore the system to its operational state by removing any unauthorized changes and verifying the integrity of critical system files.
+- Conduct a post-incident review to identify gaps in security controls and improve incident response procedures.
+- Educate users and administrators on the importance of applying security patches promptly and recognizing signs of potential exploitation.
+- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to enhance detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
index d0bdbf799f4..822c9a0e586 100644
--- a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
+++ b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/11"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,49 @@ type = "threshold"
 query = '''
 kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.type:linux and event.kind:signal
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Buffer Overflow Attack Detected
+
+Buffer overflow attacks exploit vulnerabilities in software to execute arbitrary code, often leading to privilege escalation. Adversaries may trigger numerous segmentation faults (segfaults) on Linux systems as they attempt to exploit these vulnerabilities. The detection rule identifies potential attacks by monitoring for a surge in segfault alerts, indicating possible exploitation attempts, and correlates them with known privilege escalation tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the rule ID "5c81fc9d-1eae-437f-ba07-268472967013" and ensure it matches the Potential Buffer Overflow Attack Detected rule.
+- Examine the host information, specifically focusing on `host.os.type:linux`, to identify the affected systems and prioritize them based on criticality and exposure.
+- Analyze the timeline of the segfault alerts to determine if they occurred in a short timespan, indicating a potential exploitation attempt.
+- Correlate the segfault alerts with any recent changes or deployments on the affected systems that might have introduced vulnerabilities.
+- Investigate the processes associated with the segfaults by reviewing logs and identifying any unusual or unauthorized applications running on the system.
+- Use Osquery to gather more context on the affected system. For example, run the following query to list processes that have recently crashed: `SELECT pid, name, path, cmdline FROM processes WHERE state = 'Z';`
+- Check for any known vulnerabilities or exploits related to the applications or services that triggered the segfaults, using CVE databases or security advisories.
+- Look for any additional indicators of compromise (IOCs) on the affected systems, such as unexpected network connections or file modifications, that might suggest further malicious activity.
+- Review user and system logs for any signs of privilege escalation attempts, focusing on the timeframe of the segfault alerts.
+- Cross-reference the detected activity with MITRE ATT&CK framework, specifically tactic TA0004 and technique T1068, to identify potential adversary behavior patterns and refine the investigation focus.
+
+### False positive analysis
+
+- Known false positives for the Potential Buffer Overflow Attack Detected rule may include legitimate applications or processes that inherently generate a high number of segmentation faults during normal operation, such as software under development or testing environments where debugging and crash testing are frequent.
+- System administrators can manage these false positives by creating exceptions for specific applications or processes known to cause frequent segfaults without malicious intent. This can be done by adjusting the detection rule to exclude certain process names or paths that are identified as non-threatening.
+- Another approach is to refine the threshold settings to better align with the typical behavior of the monitored environment, ensuring that only unusual spikes in segfaults trigger alerts.
+- Users should regularly review and update the list of exceptions to ensure that new legitimate applications are accounted for and that any changes in application behavior are reflected in the rule configuration.
+- It is also advisable to correlate segfault alerts with other indicators of compromise or suspicious activity to differentiate between benign and potentially malicious behavior more effectively.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to confirm the buffer overflow attack by analyzing logs and correlating segfault alerts with other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Apply patches and updates to the affected software and operating system to close the vulnerability exploited by the attacker.
+- Restore the system from a known good backup to ensure no malicious code remains on the system.
+- Implement enhanced logging policies to capture detailed information on system calls and application behavior for future investigations.
+- Integrate additional security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Harden the system by disabling unnecessary services, applying the principle of least privilege, and enabling security features such as stack canaries and address space layout randomization (ASLR).
+- Educate and train staff on recognizing and responding to buffer overflow attacks and other privilege escalation techniques to improve overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
index c5e85063fdc..a6e6d323328 100644
--- a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
+++ b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 ) and not process.parent.name == "spine"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privilege Escalation via SUID/SGID
+
+SUID/SGID are Unix permissions that allow users to execute files with the file owner's privileges, often root. Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access. The detection rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions for privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert. Pay special attention to the `process.name` and `process.args` fields.
+- Verify the user context by checking the `process.user.id` and `process.real_user.id` fields to confirm the discrepancy in user IDs, indicating potential misuse of SUID/SGID permissions.
+- Examine the `process.group.id` and `process.real_group.id` fields to identify any group ID discrepancies that might suggest SGID exploitation.
+- Investigate the parent process by reviewing the `process.parent.name` field to understand the process hierarchy and determine if the execution chain is suspicious.
+- Use Osquery to list all SUID/SGID binaries on the system with the following query: `SELECT path, mode FROM file WHERE mode & 4000 OR mode & 2000;` to identify potential misconfigurations.
+- Cross-reference the list of SUID/SGID binaries with the process name from the alert to determine if the binary is expected to have these permissions.
+- Check system logs for any recent changes to SUID/SGID binaries or user accounts that might indicate tampering or privilege escalation attempts.
+- Investigate the command-line arguments used by the process to determine if they are typical for the binary in question or if they suggest malicious intent.
+- Review the system's user and group configurations to ensure there are no unauthorized changes or additions that could facilitate privilege escalation.
+- Analyze network activity associated with the process to identify any external connections or data exfiltration attempts that might be related to the privilege escalation.
+
+### False positive analysis
+
+- Some legitimate administrative tasks may trigger the detection rule, such as system maintenance scripts or software updates that require elevated privileges. These tasks often run with SUID/SGID permissions but are not malicious.
+- Automated backup processes or monitoring tools that require root access might also be flagged. These processes are typically scheduled and can be verified by checking their source and purpose.
+- Developers or system administrators using certain tools for legitimate purposes, like debugging or performance monitoring, may inadvertently trigger the rule. Tools like `gdb`, `strace`, or `perf` are common in such scenarios.
+- To manage these false positives, users can create exceptions for known benign processes by adding them to an exclusion list. This can be done by identifying the specific process names and arguments that are frequently flagged but are part of routine operations.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker.
+- Investigate the process and user account involved in the alert to determine if the SUID/SGID permissions were intentionally set or misconfigured.
+- Review system logs and audit trails to identify any unauthorized access or changes made by the process, focusing on the time frame around the alert.
+- Remove or correct the SUID/SGID permissions on the identified binary if they are not required for legitimate operations.
+- Conduct a thorough scan of the system for any additional signs of compromise, such as unexpected user accounts, scheduled tasks, or backdoors.
+- Restore the system from a known good backup if unauthorized changes or malware are detected, ensuring that the backup is free from compromise.
+- Implement stricter access controls and permissions management to prevent unauthorized changes to SUID/SGID binaries in the future.
+- Enhance logging and monitoring to include detailed process execution and privilege escalation attempts, integrating with a SIEM for real-time alerting.
+- Educate users and administrators on the risks associated with SUID/SGID binaries and the importance of maintaining secure configurations.
+- Report the incident to relevant internal teams and, if necessary, external authorities or partners, following organizational policies and legal requirements."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
index d1010dffe3f..6f71f341214 100644
--- a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
+++ b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,50 @@ sequence by host.id with maxspan=1s
      process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Shell via Wildcard Injection Detected
+
+Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries may leverage this to escalate privileges or access sensitive data. The detection rule identifies suspicious executions of vulnerable binaries like `tar`, `rsync`, and `zip`, followed by shell spawns, indicating potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific binary (e.g., `tar`, `rsync`, `zip`) and the suspicious command line flags that triggered the alert.
+- Examine the `process.entity_id` and `process.parent.entity_id` fields to trace the process lineage and understand the parent-child relationship of the processes involved.
+- Check the `host.id` and `host.os.type` fields to confirm the affected host and ensure it is running a Linux operating system.
+- Investigate the `process.args` field to analyze the exact command line arguments used, looking for any unusual or unexpected patterns that could indicate manipulation.
+- Use Osquery to gather additional context about the processes involved. For example, run the following query to list recent processes executed by the same user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <suspicious_process_id>);`
+- Review the `event.type` and `event.action` fields to confirm the nature of the process execution events and ensure they align with the expected behavior of the binaries.
+- Check for any recent changes or anomalies in the `/tmp/newroot/` directory, as the query excludes processes executed from this path, which might indicate an attempt to bypass detection.
+- Investigate the `process.parent.name` field to determine if the shell spawn was legitimate or if it indicates an unauthorized shell access attempt.
+- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns.
+- Consult threat intelligence sources or internal knowledge bases to determine if there are known vulnerabilities or exploits associated with the specific binaries and command line flags observed.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate administrative scripts or automated processes use the `tar`, `rsync`, or `zip` commands with wildcard characters for routine operations, such as backups or file synchronization, which may inadvertently match the detection criteria.
+- System administrators often use `tar` with `--checkpoint` and `--checkpoint-action` flags for monitoring purposes during large file operations, which can trigger the rule without malicious intent.
+- The `rsync` command with `-e` options is commonly used in secure file transfer scripts, which might be flagged if the script spawns a shell for legitimate reasons.
+- The `zip` command with `--unzip-command` is sometimes used in custom scripts to handle specific file extraction tasks, potentially leading to false positives if a shell is invoked as part of the process.
+- To manage these false positives, users can create exceptions by excluding specific scripts or processes known to perform these operations safely. This can be done by adding the paths or process names to an exclusion list within the detection rule configuration.
+- Regularly review and update the exclusion list to ensure it reflects current legitimate usage patterns, minimizing the risk of overlooking genuine threats while reducing noise from benign activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the scope of the intrusion, focusing on logs and process trees related to the detected binaries (tar, rsync, zip) and subsequent shell spawns.
+- Terminate any unauthorized processes that were spawned as a result of the wildcard injection to halt any ongoing malicious activities.
+- Review and analyze system logs to determine if any sensitive data was accessed or exfiltrated during the exploitation attempt.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Apply patches or updates to the affected binaries and the operating system to mitigate the vulnerability and prevent future exploitation.
+- Implement enhanced logging policies to capture detailed command-line arguments and process execution details for better visibility in future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to detect similar patterns of behavior and improve threat detection capabilities.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Harden the system by disabling unnecessary services, enforcing the principle of least privilege, and implementing application whitelisting to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
index 1ed28663043..e2af3a85c23 100644
--- a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
+++ b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/30"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name == "debugfs" and process.args : "/dev/sd*" and not process.args == "-R" and 
 not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Suspicious DebugFS Root Device Access
+
+DebugFS is a Linux utility that provides low-level access to file systems, often used for debugging. Users in the "disk" group can exploit DebugFS to access sensitive files without root privileges, potentially leading to privilege escalation. The detection rule identifies non-root users executing DebugFS on disk devices, flagging potential unauthorized access attempts by monitoring specific process arguments and user group IDs.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of non-root user activity involving the DebugFS utility, focusing on the `process.name`, `process.args`, `user.Ext.real.id`, and `group.Ext.real.id` fields.
+- Verify the identity of the user by checking the `user.Ext.real.id` and cross-reference with the organization's user directory to determine if the user should have access to disk devices.
+- Investigate the user's group memberships, particularly the "disk" group, to understand if the user has legitimate reasons to be part of this group.
+- Examine the specific `process.args` used in the alert to identify which disk device was accessed and assess the potential impact of this access.
+- Use Osquery to gather more context about the process execution. For example, run the following query to list recent processes executed by the user: `SELECT * FROM processes WHERE uid = <user_id> AND name = 'debugfs';`
+- Check the system logs for any other suspicious activities or anomalies around the time of the alert, focusing on the same user and device.
+- Investigate any recent changes to the user's account or group memberships that might explain the activity.
+- Review the user's command history, if available, to identify any other potentially suspicious commands executed around the same time.
+- Analyze network logs to determine if there was any unusual outbound traffic from the host that might indicate data exfiltration.
+- Correlate this alert with any other security alerts or incidents involving the same user or host to identify patterns or repeated suspicious behavior.
+
+### False positive analysis
+
+- Users performing legitimate maintenance tasks: System administrators or maintenance scripts may use DebugFS for legitimate purposes, such as file system checks or repairs. To handle these, identify the specific users or scripts and create exceptions for their activities.
+- Automated backup processes: Some backup solutions might use DebugFS to access disk devices for data integrity checks. Review the backup processes and exclude these known benign activities by specifying the associated user accounts or process arguments.
+- Development and testing environments: Developers or testers might use DebugFS in non-production environments for debugging purposes. To prevent these from being flagged, consider excluding specific environments or user groups from the rule.
+- Educational or training sessions: In educational settings, DebugFS might be used as part of training exercises. Identify these sessions and exclude the relevant user accounts or time frames to avoid false positives.
+- Custom scripts or tools: Organizations may have custom scripts that utilize DebugFS for specific operational needs. Review these scripts and exclude their execution by defining exceptions based on process names or arguments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Verify the identity and permissions of the user who executed DebugFS to determine if the access was legitimate or malicious.
+- Review system logs and DebugFS usage history to identify any sensitive files accessed or modified during the incident.
+- Change passwords and revoke any potentially compromised credentials, especially for accounts with elevated privileges.
+- Remove the user from the "disk" group if they do not require access to disk devices for their role.
+- Implement stricter access controls and audit policies for the "disk" group to prevent unauthorized use of DebugFS.
+- Escalate the incident to the security team for further investigation and to assess the potential impact on the organization.
+- Enhance logging and monitoring to include detailed tracking of file access and user activities, integrating with SIEM solutions for real-time alerts.
+- Restore the system from a known good backup if any unauthorized changes or data corruption are detected.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_shadow_file_read.toml b/rules/linux/privilege_escalation_shadow_file_read.toml
index 327e52480d6..8b56f4fd49f 100644
--- a/rules/linux/privilege_escalation_shadow_file_read.toml
+++ b/rules/linux/privilege_escalation_shadow_file_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,49 @@ host.os.type : "linux" and event.category : "process" and event.action : ("exec"
   process.parent.name:(gen_passwd_sets or scc_* or wazuh-modulesd)
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Shadow File Read via Command Line Utilities
+
+In Linux environments, the `/etc/shadow` file stores hashed passwords and is crucial for system security. Adversaries with elevated privileges may attempt to access this file to extract credentials, facilitating lateral movement and unauthorized access. The detection rule identifies suspicious command-line attempts to read this file, excluding legitimate processes, by monitoring process execution patterns and arguments, thus helping to thwart potential credential theft.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious command-line attempts to access the `/etc/shadow` file, focusing on the `process.args` and `process.executable` fields.
+- Verify the user account associated with the process by examining the `user.name` field to determine if the access was performed by a legitimate user or an unexpected account.
+- Check the `host.os.type` and `event.category` fields to ensure the alert pertains to a Linux system and involves a process execution event.
+- Investigate the `process.parent.name` field to identify the parent process and assess whether it is a known legitimate process or potentially malicious.
+- Examine the `process.working_directory` field to confirm if the process was executed from the `/etc` directory, which might indicate an attempt to access the shadow file directly.
+- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve detailed information about the process, including its command line, parent process, and user.
+- Cross-reference the `process.executable` field with known legitimate utilities and paths to rule out false positives, focusing on paths not excluded in the query.
+- Analyze recent login events and privilege escalation activities on the host to identify any unauthorized access attempts that might correlate with the alert.
+- Review system logs for any other suspicious activities or anomalies around the time of the alert to gather more context on potential malicious behavior.
+- Investigate any network connections initiated by the suspicious process to determine if there was any data exfiltration or communication with external hosts.
+
+### False positive analysis
+
+- System maintenance tasks: Legitimate system administrators may access the `/etc/shadow` file during routine maintenance or configuration changes. To handle these, users can create exceptions for known maintenance scripts or processes by adding them to the exclusion list in the detection rule.
+- Backup operations: Automated backup processes might access the `/etc/shadow` file as part of a comprehensive system backup. Users should identify and exclude these backup processes by specifying their executable paths or parent process names in the rule.
+- Security software: Some security tools, such as vulnerability scanners or compliance checkers, may read the `/etc/shadow` file to verify system security settings. Users can manage these false positives by excluding the specific security software processes from the detection rule.
+- Containerized environments: In environments using containers, certain processes might access the `/etc/shadow` file as part of container management tasks. Users should exclude paths related to container runtimes, such as Docker or containerd, to prevent false positives.
+- Custom scripts: Organizations may have custom scripts that legitimately access the `/etc/shadow` file for specific operational needs. Users should review these scripts and add them to the exclusion criteria based on their executable paths or parent process names.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the process attempting to access the /etc/shadow file by reviewing the process tree and associated user accounts.
+- Conduct a thorough investigation to determine if any credentials have been compromised and reset passwords for affected accounts.
+- Review system logs and security alerts to identify any additional suspicious activities or related incidents.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for critical files and directories, including /etc/shadow, to detect future unauthorized access attempts.
+- Apply security patches and updates to address any vulnerabilities that may have been exploited for privilege escalation.
+- Restore the system to a known good state from backups if necessary, ensuring that all compromised accounts and processes are remediated.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Implement hardening measures such as enforcing the principle of least privilege, using multi-factor authentication, and regularly auditing user access rights."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
index 757994326b9..41ca86ede4c 100644
--- a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
+++ b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,48 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
  and process.name == "sudo" and process.args == "-u#-1"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Sudo Privilege Escalation via CVE-2019-14287
+
+Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. CVE-2019-14287 exploits a flaw where specifying a user ID of -1 bypasses user validation, granting root access. Adversaries can leverage this to escalate privileges. The detection rule identifies suspicious sudo commands with specific arguments indicative of this exploit, helping to flag unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the suspicious sudo command with the arguments `-u#-1` as indicated in the query.
+- Verify the version of sudo installed on the affected system to determine if it is prior to v1.28, which is vulnerable to CVE-2019-14287.
+- Check the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Investigate the user account associated with the process execution to determine if it has a history of legitimate sudo usage or if it appears compromised.
+- Examine the command history of the user involved to identify any other potentially malicious commands executed around the same time.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes executed by the user in question: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');`
+- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, to identify any unauthorized access attempts or anomalies around the time of the alert.
+- Correlate the alert with network logs to check for any unusual outbound connections that might suggest data exfiltration or communication with a command-and-control server.
+- Investigate any file modifications or new file creations in critical directories that could indicate post-exploitation activities.
+- Cross-reference the alert with other security tools and logs to identify if this is part of a larger attack campaign targeting multiple systems.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools that use the "sudo -u#-1" command for testing or maintenance purposes may trigger this rule. Users should review such scripts and, if verified as non-threatening, create exceptions for these specific processes.
+- Development environments where developers have intentionally used the "sudo -u#-1" command for testing privilege escalation scenarios might cause false positives. In such cases, ensure that these activities are documented and consider excluding these environments from the rule.
+- Security testing or penetration testing activities that simulate the CVE-2019-14287 exploit could be flagged. Coordinate with security teams to whitelist these activities during scheduled testing periods.
+- Custom user applications that inadvertently use similar command patterns for legitimate reasons may also be flagged. Conduct a thorough review of these applications and, if deemed safe, add them to an exception list to prevent future alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the version of sudo installed on the system and upgrade to a version later than v1.28 to mitigate the vulnerability.
+- Conduct a thorough investigation of the system to identify any unauthorized changes or additional malicious activity, focusing on logs and recent changes.
+- Review and analyze logs for any other instances of the exploit attempt, particularly looking for the "sudo -u#-1" command.
+- Reset passwords and review user accounts to ensure no unauthorized accounts have been created or existing accounts have been compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed sudo command usage and integrate with a centralized logging solution for real-time monitoring.
+- Develop and deploy a security patch management process to ensure all systems are regularly updated with the latest security patches.
+- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily remediated.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_sudo_hijacking.toml b/rules/linux/privilege_escalation_sudo_hijacking.toml
index c188f2396b4..b7b9d1a2599 100644
--- a/rules/linux/privilege_escalation_sudo_hijacking.toml
+++ b/rules/linux/privilege_escalation_sudo_hijacking.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,50 @@ file.path in ("/usr/bin/sudo", "/bin/sudo") and not (
   (process.name == "sed" and file.name : "sed*")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Sudo Hijacking
+
+Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the legitimate sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event action is either "creation" or "rename" for the file path "/usr/bin/sudo" or "/bin/sudo".
+- Check the process executable that triggered the alert to ensure it is not part of the legitimate package management processes listed in the exclusion criteria.
+- Investigate the file.Ext.original.path to determine if the original file path was "/usr/bin/sudo" or "/bin/sudo", which might indicate a legitimate update or replacement.
+- Examine the process name and executable path to identify any unusual or unauthorized processes that might have created or renamed the sudo binary.
+- Use Osquery to list recent changes to the sudo binary with a query like: `SELECT * FROM file WHERE path IN ('/usr/bin/sudo', '/bin/sudo') ORDER BY atime DESC LIMIT 5;` to gather more context on recent access times.
+- Check system logs for any related entries around the time of the alert to identify any suspicious activities or patterns.
+- Verify the integrity of the current sudo binary using checksums or hashes to compare against known good versions.
+- Investigate the user account associated with the process that triggered the alert to determine if it has a history of suspicious activity or if it has been compromised.
+- Review any recent changes in user permissions or sudoers file that might correlate with the alert.
+- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Legitimate package management operations can trigger false positives. These include processes like updates or installations using package managers such as dpkg, rpm, yum, dnf, and apt. These processes are typically responsible for creating or renaming the sudo binary as part of their normal operations.
+- Exclude these package management processes by adding their executables to the exception list in the detection rule. This includes paths like "/bin/dpkg", "/usr/bin/rpm", "/usr/bin/apt-get", and others specified in the rule.
+- Temporary files created during legitimate operations, such as those with the extension "dpkg-new", can also cause false positives. Ensure these are excluded by checking the file extension in the rule.
+- Processes running from specific directories like "/nix/store/*", "/var/lib/dpkg/*", or "/snap/*" are often part of legitimate system operations and should be excluded to prevent false alerts.
+- If a process executable is null, it might indicate a legitimate system process that should not be flagged. Consider adding checks to handle such cases appropriately.
+- The use of the "sed" command in scripts that modify the sudo binary name temporarily can also lead to false positives. Exclude these by checking for the process name "sed" and file names starting with "sed".
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source or repository.
+- Review system logs and security alerts to identify any unauthorized access or suspicious activity around the time of the sudo binary modification.
+- Conduct a thorough investigation to determine the source of the compromise, including reviewing user accounts and processes that initiated the change.
+- Restore the original sudo binary from a trusted backup or reinstall the sudo package using a secure package manager.
+- Escalate the incident to the security operations team if evidence of a broader compromise or advanced persistent threat is detected.
+- Implement enhanced logging policies to capture detailed audit logs of file modifications and process executions, focusing on critical system binaries.
+- Integrate with a centralized security information and event management (SIEM) system to correlate and analyze security events across the network.
+- Apply system hardening measures, such as restricting sudo access to only necessary users and implementing multi-factor authentication for privileged accounts.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
index ce6f74cdf9b..3184797ca78 100644
--- a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
+++ b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,48 @@ sequence by host.id, process.session_leader.entity_id with maxspan=15s
 [ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
   process.name == "sudo" and process.user.id == "0" and process.group.id == "0" ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Sudo Token Manipulation via Process Injection
+
+In Linux environments, process injection can be exploited by adversaries to manipulate sudo tokens, allowing unauthorized privilege escalation. Attackers may use debugging tools like gdb to inject code into processes with valid sudo tokens, leveraging ptrace capabilities. The detection rule identifies this threat by monitoring for gdb execution followed by a uid change in the sudo process, indicating potential token manipulation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and process.session_leader.entity_id involved in the sequence to ensure the correct context is being investigated.
+- Verify the execution of the gdb process by checking the process.name field and ensure it matches "gdb" with a non-root user and group id, as indicated by process.user.id != "0" and process.group.id != "0".
+- Investigate the timing and sequence of events by examining the maxspan=15s condition to determine if the gdb execution and sudo uid change occurred within this short timeframe.
+- Check the process tree and parent-child relationships for the gdb process to identify any suspicious parent processes or anomalies in the process hierarchy.
+- Analyze the sudo process event where the uid_change occurred, ensuring the process.name is "sudo" and the user and group ids are root (process.user.id == "0" and process.group.id == "0").
+- Use Osquery to gather additional context on the processes involved. For example, run the following query to list processes with their parent processes and command lines: `SELECT pid, parent, name, path, cmdline FROM processes WHERE pid IN (SELECT pid FROM processes WHERE name = 'gdb' OR name = 'sudo');`
+- Investigate the ptrace settings on the host to determine if ptrace is enabled, which is necessary for process injection. This can be done by checking the value of `/proc/sys/kernel/yama/ptrace_scope`.
+- Review system logs and audit logs for any additional context or anomalies around the time of the alert, focusing on user activity and any other privilege escalation attempts.
+- Examine the user account associated with the gdb process to determine if there are any signs of compromise or unusual activity, such as recent logins from unexpected locations or times.
+- Correlate the findings with any other alerts or incidents involving the same host or user to identify potential patterns or broader attack campaigns.
+
+### False positive analysis
+
+- Debugging activities by developers or system administrators using gdb on processes with valid sudo tokens can trigger false positives. To manage this, users can create exceptions for specific user IDs or process names that are known to be involved in legitimate debugging activities.
+- Automated scripts or maintenance tasks that involve gdb and result in uid changes in the sudo process may also cause false positives. Users can handle these by identifying and excluding specific scripts or cron jobs from the detection rule.
+- Security tools or monitoring solutions that utilize gdb for legitimate process analysis might be mistakenly flagged. Users should whitelist these tools by specifying their process names or user IDs in the exception list.
+- Training or testing environments where gdb is frequently used for educational purposes can lead to false positives. Users can exclude these environments by filtering based on host identifiers or specific session leader entity IDs.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Use forensic tools to capture memory and disk images of the affected system for further analysis and evidence preservation.
+- Investigate the process tree and logs to identify the source of the gdb execution and any associated processes that may have been injected.
+- Check for unauthorized changes in user privileges and revert any unauthorized uid changes detected in the sudo process.
+- Review and update ptrace settings to restrict debugging capabilities to trusted users only, reducing the risk of process injection.
+- Implement enhanced logging for sudo and gdb activities, ensuring that all execution and privilege changes are recorded and monitored.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious activities related to process injection.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and threat intelligence correlation.
+- Restore the system to its operational state by applying clean backups and verifying the integrity of critical system files and configurations.
+- Conduct a security review and harden the system by applying the principle of least privilege, ensuring that only necessary users have sudo access, and regularly updating all software and security patches."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
index 099c3d7462e..244ad47e105 100644
--- a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
+++ b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,48 @@ sequence by host.id, process.entity_id with maxspan=1s
   [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and 
    (user.id == "0" or group.id == "0")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via Python cap_setuid
+
+In Unix-like systems, setuid and setgid allow processes to execute with elevated privileges, typically those of the file owner or group. Adversaries may exploit these features using Python scripts to gain unauthorized root access by executing commands with root privileges. The detection rule identifies such attempts by monitoring Python processes that invoke system commands with setuid or setgid, followed by a user or group ID change to root, indicating potential privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process entity ID involved in the potential privilege escalation attempt.
+- Examine the process arguments captured in the alert to confirm the presence of the suspicious Python command pattern: `import os;os.set?id(0);os.system(*)`.
+- Verify the user ID associated with the process to ensure it is not root (`user.id != "0"`), as this is a key indicator of a potential privilege escalation attempt.
+- Check the sequence of events to confirm that a UID or GID change to root (`user.id == "0"` or `group.id == "0"`) occurred immediately after the suspicious Python command execution.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT pid, name, path, cmdline, uid, gid FROM processes WHERE pid = <process_id>;` to retrieve detailed information about the process.
+- Investigate the parent process of the suspicious Python process to understand how it was initiated and whether it was spawned by a legitimate or suspicious parent.
+- Review the system logs on the affected host for any additional context or anomalies around the time of the alert, focusing on authentication logs and any other privilege-related events.
+- Check for any recent changes to the file permissions or ownership of the Python script or any related files that could have facilitated the privilege escalation attempt.
+- Analyze network activity from the host around the time of the alert to identify any potential command and control communication or data exfiltration attempts.
+- Correlate this alert with any other recent alerts or incidents involving the same host or user account to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators may use Python scripts with setuid or setgid capabilities for legitimate purposes, such as system maintenance or automation tasks. These scripts might trigger the detection rule if they change user or group IDs to root. To handle this, users can create exceptions for known scripts by whitelisting specific script paths or hashes.
+- Development and testing environments: Developers might execute Python scripts with elevated privileges during testing or development phases, which could be mistaken for malicious activity. Users can exclude specific development environments or user accounts from the detection rule to reduce false positives.
+- Security tools and monitoring software: Some security tools or monitoring software may use Python scripts with setuid or setgid capabilities as part of their normal operation. Users should identify and exclude these tools from the detection rule by specifying their process names or paths.
+- Automated deployment processes: Automated deployment or configuration management systems might use Python scripts to perform tasks requiring elevated privileges. Users can manage these false positives by excluding known deployment processes or by setting up specific rules for these systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the privilege escalation attempt, including reviewing logs and process histories.
+- Terminate any suspicious processes that are running with elevated privileges and verify the integrity of critical system files.
+- Change all passwords for accounts that may have been compromised, especially those with elevated privileges.
+- Restore the system from a known good backup if unauthorized changes or malware are detected.
+- Implement enhanced logging policies to capture detailed process execution and user activity, focusing on setuid and setgid operations.
+- Integrate security monitoring tools with SIEM solutions to improve detection capabilities for similar threats in the future.
+- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
+- Conduct a security audit to identify and remediate any misconfigurations or weaknesses in user permissions and access controls.
+- Educate users and administrators on the risks of privilege escalation and the importance of adhering to the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
index 438d47ec204..5a1b73d4a6d 100644
--- a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,51 @@ sequence by host.id, process.pid with maxspan=1s
    ) and user.id != "0"
   ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privilege Escalation via CAP_CHOWN/CAP_FOWNER Capabilities
+
+In Linux, CAP_CHOWN and CAP_FOWNER capabilities allow processes to change file ownership and bypass permission checks, respectively. Adversaries exploit these to gain unauthorized file access, potentially altering sensitive files like `/etc/passwd`. The detection rule identifies processes with these capabilities targeting critical files, flagging suspicious ownership changes by non-root users, thus highlighting potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and file involved, focusing on `process.pid`, `process.name`, and `file.path` fields.
+- Verify the user context by checking the `user.id` field to confirm that the action was performed by a non-root user.
+- Examine the command line used to execute the process by reviewing the `process.command_line` field to understand the intent and scope of the action.
+- Investigate the process's parent process to determine if it was spawned by a legitimate or suspicious parent using the `process.parent.name` and `process.parent.pid` fields.
+- Check the system logs for any related entries around the time of the event to gather additional context on the process execution and file ownership change.
+- Use Osquery to list all processes with CAP_CHOWN or CAP_FOWNER capabilities to identify any other potentially suspicious processes:
+  ```sql
+  SELECT pid, name, path, uid, gid, on_disk FROM processes WHERE capabilities LIKE '%CAP_CHOWN%' OR capabilities LIKE '%CAP_FOWNER%';
+  ```
+- Investigate the history of changes to the targeted file (e.g., `/etc/passwd`) to identify any unauthorized modifications or patterns of access.
+- Review user activity logs for the non-root user involved to identify any unusual behavior or access patterns leading up to the event.
+- Analyze network activity from the host to detect any potential exfiltration or communication with known malicious IPs or domains.
+- Correlate the event with other security alerts or incidents to determine if it is part of a broader attack campaign or isolated incident.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may perform legitimate file ownership changes as part of regular maintenance or configuration updates. These actions can trigger the detection rule if they involve files like `/etc/passwd` or `/etc/shadow`. To manage this, users can create exceptions for known administrative scripts or processes that are regularly executed by trusted users.
+- Automated system updates: Some automated update processes or configuration management tools may change file ownership as part of their operations. These processes might be flagged if they have the necessary capabilities. Users can handle these by identifying and excluding specific update processes or tools that are verified as safe.
+- Backup and restore operations: Backup software might change file ownership during the backup or restore process, especially if it needs to ensure files are restored with the correct permissions. Users should identify and whitelist these backup processes to prevent false positives.
+- Development and testing environments: In environments where developers or testers frequently change file permissions or ownership for testing purposes, these actions might be flagged. Users can manage this by excluding specific development or testing processes or by setting up separate monitoring rules for these environments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the capability abuse, including reviewing logs for any suspicious process executions or file ownership changes.
+- Revert any unauthorized file ownership changes, especially for critical files like /etc/passwd, /etc/shadow, and /etc/sudoers, to their original state.
+- Reset passwords and review user accounts for any unauthorized changes or additions, focusing on accounts with elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and file modification events, ensuring that CAP_CHOWN and CAP_FOWNER usage is monitored.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve visibility and detection capabilities.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for privilege escalation.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting the use of capabilities to only necessary processes and users, and regularly auditing capability assignments."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
index 0b8d920fccf..86e97c6c81d 100644
--- a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
+++ b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/22"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,48 @@ sequence by host.id, process.parent.pid with maxspan=1m
   [file where host.os.type == "linux" and file.path == "/etc/passwd" and process.parent.pid != 1 and
    not auditd.data.a2 == "80000" and event.outcome == "success" and user.id != "0"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Passwd File Event Action
+
+In Linux environments, the `/etc/passwd` file is crucial for managing user accounts. Adversaries may exploit vulnerabilities or misconfigurations to insert unauthorized entries, potentially gaining root access. The detection rule identifies suspicious activity by monitoring for the use of `openssl` to generate password entries, followed by unauthorized modifications to the `/etc/passwd` file, indicating potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and process.parent.pid involved in the suspicious activity to ensure accurate context.
+- Verify the user.id associated with the openssl process execution to determine if a non-root user attempted to generate a password entry.
+- Check the process.args field to confirm the use of "openssl passwd" and gather any additional arguments that might indicate the password generation method.
+- Investigate the file write activity on the /etc/passwd file by examining the file.path and event.outcome fields to confirm unauthorized modifications.
+- Use Osquery to list recent processes executed by the user.id in question to identify any other suspicious activities: `SELECT pid, name, path, cmdline FROM processes WHERE uid = <user_id>;`
+- Examine the process.parent.pid to trace the parent process and understand the context of how the openssl command was executed.
+- Review system logs for any login attempts or successful logins by the newly created user account, focusing on the time frame around the alert.
+- Check for any recent changes in file permissions or ownership of the /etc/passwd file that could have facilitated unauthorized access.
+- Investigate other security alerts or anomalies on the same host.id to identify potential lateral movement or additional compromise indicators.
+- Correlate the activity with known MITRE ATT&CK techniques, specifically T1068, to assess if this is part of a broader privilege escalation attempt.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use `openssl` to generate password entries for valid user account management. To handle this, users can create exceptions for specific user IDs or processes known to perform these tasks regularly.
+- Automated scripts: Some automated maintenance scripts might use `openssl` for password management and modify the `/etc/passwd` file as part of their routine operations. Users should identify these scripts and exclude them from triggering alerts by specifying their process names or paths.
+- Non-root user activities: Developers or non-root users might use `openssl` for testing purposes, leading to false positives. Users can exclude specific user IDs or groups from the detection rule to prevent unnecessary alerts.
+- System updates or installations: During system updates or software installations, legitimate processes might modify the `/etc/passwd` file. Users should monitor these activities and temporarily disable the rule or whitelist known update processes to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify any unauthorized entries in the `/etc/passwd` file and remove them. Verify the integrity of the file against a known good backup.
+- Review system logs and process execution history to trace the source of the unauthorized `openssl` command and any subsequent actions taken by the adversary.
+- Change all passwords for user accounts on the affected system, especially those with elevated privileges, to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging and monitoring for critical files like `/etc/passwd` and processes involving `openssl` to detect similar activities in the future.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for privilege escalation.
+- Conduct a security audit of user account permissions and file access controls to ensure they adhere to the principle of least privilege.
+- Restore the system from a clean backup if necessary, ensuring that all unauthorized changes are removed and the system is returned to a secure operational state.
+- Educate users and administrators on secure password practices and the importance of monitoring for suspicious activities to enhance overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
index 81d2c3ef6c1..a2fbd15f721 100644
--- a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,49 @@ sequence by host.id, process.entity_id with maxspan=1s
    (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID")
    and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privilege Escalation via CAP_SETUID/SETGID Capabilities
+
+In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and host involved, focusing on `process.entity_id`, `process.name`, and `host.id`.
+- Verify the process's capabilities by checking `process.thread.capabilities.effective` and `process.thread.capabilities.permitted` to confirm the presence of CAP_SETUID or CAP_SETGID.
+- Examine the process's parent information using `process.parent.executable` and `process.parent.name` to determine if the parent process is known or expected.
+- Investigate the command line used to start the process with `process.command_line` to identify any suspicious or unexpected commands.
+- Check the user context before and after the process execution by reviewing `user.id` to confirm if there was an unauthorized change to UID 0 (root).
+- Use Osquery to gather additional context about the process and its capabilities. Example query: `SELECT pid, name, uid, gid, on_disk, path FROM processes WHERE pid = <process_id>;`
+- Analyze the process's executable path with `process.executable` to ensure it is not located in a suspicious directory or matches known benign paths.
+- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns.
+- Review the system's recent changes or configurations that might have inadvertently granted the process these capabilities.
+- Consult threat intelligence sources to determine if the process or its behavior is associated with known privilege escalation techniques or campaigns.
+
+### False positive analysis
+
+- Processes related to system management tools like VMware, SolarWinds, and Dynatrace may trigger false positives due to their legitimate use of CAP_SETUID/SETGID capabilities for operational purposes. Users can handle these by adding exceptions for specific executables or paths such as "/usr/bin/vmware-toolbox-cmd" and "/opt/SolarWinds/Agent/*".
+- System update and notification processes, including "update-notifier" and "language-options", might be flagged as they sometimes require elevated privileges. Exclude these by specifying their parent names or command lines in the detection rule.
+- Security and monitoring tools like osquery and saposcol may also be flagged due to their need to access various system resources. Users should consider excluding these processes by their names or executable paths to prevent false alerts.
+- Common administrative commands like "sudo" and "pkexec" are often used in legitimate scenarios to change user IDs. To manage these, users can exclude specific command lines or process names that are known to be safe in their environment.
+- Automation tools such as Ansible, which may execute scripts with elevated privileges, can be excluded by identifying their command lines, such as those starting with "/usr/bin/python*ansible*".
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the privilege escalation, focusing on recent changes to system configurations and user permissions.
+- Review system logs and security alerts to determine if any other systems have been compromised or if there are signs of lateral movement.
+- Revoke any unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users to minimize the risk of future privilege escalation.
+- Apply patches and updates to the operating system and any vulnerable applications to mitigate known exploits.
+- Restore the system to a known good state using backups, ensuring that the backup is free from any malicious modifications.
+- Implement enhanced logging policies to capture detailed information on process executions and user activities, aiding in future investigations.
+- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate users and administrators on security best practices and the importance of maintaining least privilege access to reduce the risk of privilege escalation attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_uid_change_post_compilation.toml b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
index 64e954706a1..c5247e31261 100644
--- a/rules/linux/privilege_escalation_uid_change_post_compilation.toml
+++ b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,48 @@ sequence by host.id with maxspan=1m
   [process where host.os.type == "linux" and event.action in ("uid_change", "guid_change") and event.type == "change" and 
    user.id == "0"] by process.name
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via Recently Compiled Executable
+
+In Linux environments, compiling and executing programs is routine, but adversaries can exploit this by compiling malicious code to escalate privileges. They may compile a program that, when executed, alters user permissions to gain root access. The detection rule identifies this threat by monitoring sequences of compilation, execution, and unauthorized UID changes, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id where the potential privilege escalation was detected.
+- Examine the process.args field from the initial compilation event to determine the source code or script being compiled, which may provide insight into the intent of the executable.
+- Investigate the file.name field from the file creation event to identify the newly created executable file and verify its legitimacy.
+- Analyze the process.name field from the execution event to understand which program was executed and assess if it aligns with typical user behavior.
+- Check the process.name field from the UID change event to identify the process responsible for altering user permissions and determine if it is a known privilege escalation tool or exploit.
+- Use Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve detailed information about the suspicious process, including its parent process and command line arguments.
+- Investigate the user.id field across all events to confirm whether the actions were performed by a non-root user initially and escalated to root privileges.
+- Correlate the timeline of events to verify if the sequence of compilation, execution, and UID change occurred within the specified maxspan of 1 minute, indicating a rapid privilege escalation attempt.
+- Review system logs and audit logs on the affected host for any additional suspicious activity or anomalies around the time of the alert.
+- Consult threat intelligence sources to check if the identified process names or file names are associated with known privilege escalation exploits or malware.
+
+### False positive analysis
+
+- Developers and system administrators frequently compile and execute programs as part of their routine tasks, which can trigger this rule. These activities are typically benign and not indicative of malicious behavior.
+- Automated build systems or continuous integration pipelines may compile and execute code, leading to false positives. These systems often run under specific user accounts that can be excluded from monitoring.
+- Educational environments where students compile and execute code as part of their learning process can also generate false positives. Identifying and excluding these user accounts or specific directories can help reduce noise.
+- To manage these false positives, users can create exceptions for known non-threatening behaviors by excluding specific user IDs, process names, or directories from the rule. This can be done by updating the detection rule to ignore certain patterns or by maintaining a whitelist of trusted users and processes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the malicious executable and determine if other systems are affected.
+- Review system logs and security alerts to gather evidence of the privilege escalation attempt and any subsequent actions taken by the adversary.
+- Revoke any unauthorized changes to user permissions and reset credentials for affected accounts to prevent further exploitation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring future incidents can be detected more effectively.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
+- Apply system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
index 6d8b2ad4a2c..3ae139ff32c 100644
--- a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
+++ b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,52 @@ and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or
   process.args:/usr/bin/python*
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 UID Elevation from Previously Unknown Executable
+
+In Linux environments, user ID (UID) elevation is a critical function allowing users to gain root privileges. Adversaries exploit this by using unknown executables to hijack execution flows, often via rootkits, to stealthily gain root access. The detection rule identifies such anomalies by monitoring UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unknown executable that triggered the UID elevation event.
+- Cross-reference the process executable path with known safe paths to confirm it is indeed unknown or suspicious.
+- Examine the parent process name and its command-line arguments to understand the context in which the executable was run.
+- Use Osquery to list all processes running on the host and identify any other instances of the suspicious executable:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE path = '<suspicious_executable_path>';
+  ```
+- Investigate the file attributes and metadata of the unknown executable, such as creation and modification times, to determine if it was recently introduced.
+- Check the system logs for any recent changes or installations that might correlate with the appearance of the unknown executable.
+- Analyze the network activity from the host to identify any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
+- Review user activity logs to determine if any legitimate user actions could have inadvertently triggered the UID elevation.
+- Investigate other security alerts or anomalies on the host that might be related to the same timeframe as the UID elevation event.
+- Consult threat intelligence sources to see if the unknown executable or its hash is associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate software updates or installations introduce new executables that are not yet recognized by the detection rule. These can include software from trusted vendors that temporarily reside in non-standard directories.
+- System administrators might execute scripts or binaries from custom paths for maintenance or monitoring purposes, which could trigger the rule if these paths are not included in the exceptions.
+- Developers and IT staff often compile and run custom applications or scripts in development environments, which may not be accounted for in the predefined safe paths.
+- To manage these false positives, users can update the detection rule to include exceptions for specific paths or executables that are verified as safe. This can be done by adding these paths to the `process.executable` exclusion list or by specifying known safe process names in the `process.name` exclusion list.
+- Regularly review and update the list of exceptions to ensure that new legitimate software and processes are accounted for, reducing unnecessary alerts while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the unknown executable and determine how it was introduced into the system.
+- Review system logs and use forensic tools to trace the execution flow and identify any rootkits or malicious modifications.
+- Remove any identified malicious executables and rootkits from the system, ensuring all traces are eradicated.
+- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and UID changes for future monitoring.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Conduct a security review and harden the system by implementing least privilege access, disabling unnecessary services, and using security tools like SELinux or AppArmor."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
index bf460f0459c..1469adc5c9b 100644
--- a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
+++ b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,49 @@ process.executable: "/usr/bin/unshare" and
 not process.parent.executable: ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") and
 not process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Namespace Manipulation Using Unshare
+
+Unshare is a Linux utility that allows processes to run with a new set of namespaces, effectively isolating them from the rest of the system. While useful for containerization and sandboxing, adversaries can exploit unshare to bypass security boundaries, escalate privileges, or access unauthorized resources. The detection rule identifies suspicious unshare executions by filtering out benign parent processes and specific arguments, focusing on potential misuse indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process executable is "/usr/bin/unshare" and verify the absence of benign parent processes such as "/usr/bin/udevadm" or "*/lib/systemd/systemd-udevd".
+- Check the process arguments to ensure they do not match "/usr/bin/snap", which is considered benign in this context.
+- Investigate the parent process name to ensure it is not "zz-proxmox-boot" or "java", as these are excluded from the rule.
+- Use process lineage analysis to trace the ancestry of the unshare process and identify any potentially malicious parent processes.
+- Examine the user account associated with the unshare process to determine if it has a history of suspicious activity or if it is a privileged account.
+- Utilize Osquery to gather additional context about the process. For example, run the query: `SELECT * FROM processes WHERE name = 'unshare';` to gather details about the process state and associated metadata.
+- Investigate any network connections or file system changes initiated by the unshare process to identify potential lateral movement or data exfiltration.
+- Review system logs for any other suspicious activities or anomalies around the time the unshare process was executed.
+- Correlate the unshare activity with other security alerts or incidents to determine if it is part of a larger attack campaign.
+- Consult threat intelligence sources to check for any known threat actors or campaigns that utilize unshare for privilege escalation or container escape techniques.
+
+### False positive analysis
+
+- System management tools: Certain system management tools and scripts may legitimately use unshare for routine operations, such as system updates or configuration changes. Users can handle these by identifying the specific tools and adding their parent processes to the exclusion list.
+- Development environments: Developers might use unshare during software development and testing to create isolated environments. To manage these, users can exclude processes initiated by known development tools or scripts.
+- Container orchestration: Some container orchestration platforms may use unshare as part of their normal operations. Users should identify these platforms and exclude their associated processes to prevent false positives.
+- Automated scripts: Automated scripts that perform system maintenance or monitoring might invoke unshare. Users can manage these by reviewing the scripts and excluding their parent processes if they are deemed non-threatening.
+- Custom administrative tasks: Administrators may use unshare for custom tasks that require namespace isolation. Users should document these tasks and exclude the relevant processes to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on process trees and any unauthorized use of the unshare command.
+- Review system logs and security alerts to determine if privilege escalation or container escape attempts were successful.
+- Terminate any suspicious processes that were initiated using the unshare command and assess the integrity of the system.
+- Escalate the incident to the security operations team if evidence of privilege escalation or data exfiltration is found.
+- Restore the system from a known good backup if unauthorized changes or persistent threats are detected.
+- Implement enhanced logging policies to capture detailed process execution and namespace changes for future investigations.
+- Integrate security tools with SIEM solutions to improve detection capabilities for namespace manipulation and privilege escalation attempts.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Educate users and administrators on the risks associated with namespace manipulation and enforce the principle of least privilege to reduce attack surfaces."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_writable_docker_socket.toml b/rules/linux/privilege_escalation_writable_docker_socket.toml
index be6a9360a51..434624b436a 100644
--- a/rules/linux/privilege_escalation_writable_docker_socket.toml
+++ b/rules/linux/privilege_escalation_writable_docker_socket.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock"))
 ) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation through Writable Docker Socket
+
+Docker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. If misconfigured to be writable by unauthorized users, adversaries can exploit this to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious processes attempting to interact with Docker sockets without root or group privileges, signaling possible privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on `process.name` and `process.args` fields.
+- Verify the user and group IDs associated with the process using `user.Ext.real.id` and `group.Ext.real.id` fields to confirm they are not root or part of the docker group.
+- Check the system logs for any recent changes to Docker socket permissions that might have allowed unauthorized write access.
+- Use Osquery to list all processes interacting with Docker sockets by running: `SELECT pid, name, path FROM processes WHERE path LIKE '/var/run/docker.sock' OR path LIKE '/var/run/dockershim.sock';`
+- Investigate the user account associated with the process to determine if it has a history of legitimate Docker usage or if it might be compromised.
+- Examine the command history of the user to identify any recent commands that could indicate an attempt to exploit Docker socket permissions.
+- Analyze network logs to detect any unusual outbound connections from the host that might suggest data exfiltration or communication with a command and control server.
+- Review Docker daemon logs for any suspicious container creation or execution events that align with the alert timestamp.
+- Check for any newly created or modified containers on the host that could have been used to escalate privileges.
+- Investigate the system for any additional indicators of compromise, such as unauthorized file modifications or new user accounts, that might correlate with the alert.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators or authorized users may perform legitimate tasks that involve interacting with Docker sockets, such as maintenance or configuration changes. These actions can trigger the rule if they are not executed with root or group privileges. To manage this, users can create exceptions for specific user IDs or groups known to perform these tasks regularly.
+- Automated scripts or tools: Some automated scripts or monitoring tools might interact with Docker sockets as part of their normal operation. If these tools are known and trusted, users can exclude their process names or specific arguments from triggering the rule.
+- Development environments: In development environments, developers might frequently use Docker commands to test applications. If these actions are non-threatening and part of regular development workflows, users can exclude specific user IDs or process arguments associated with these activities.
+- Container orchestration systems: Systems like Kubernetes might interact with Docker sockets as part of their orchestration tasks. If these interactions are expected and secure, users can create exceptions for the specific processes or arguments used by these systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Investigate the source of the unauthorized access by reviewing logs and identifying any suspicious user accounts or processes that interacted with the Docker socket.
+- Terminate any unauthorized containers or processes that were started using the writable Docker socket to prevent further exploitation.
+- Change permissions on the Docker socket to restrict write access to only the root user and the docker group, ensuring no unauthorized users can access it.
+- Conduct a thorough review of user accounts and group memberships to ensure only authorized personnel have access to Docker-related privileges.
+- Implement enhanced logging for Docker daemon activities and socket interactions to capture detailed information for future investigations.
+- Integrate security monitoring tools with SIEM solutions to detect and alert on suspicious Docker socket activities in real-time.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, ensuring no backdoors or malicious modifications remain.
+- Apply security patches and updates to the Docker daemon and related components to mitigate known vulnerabilities.
+- Educate and train system administrators and users on secure Docker practices and the importance of maintaining strict access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_credentials_keychains.toml b/rules/macos/credential_access_credentials_keychains.toml
index 10a16206576..2acc0d53ffc 100644
--- a/rules/macos/credential_access_credentials_keychains.toml
+++ b/rules/macos/credential_access_credentials_keychains.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -94,6 +94,49 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                    "/usr/local/jamf/bin/jamf",
                                                    "/Applications/Microsoft Defender.app/Contents/MacOS/wdavdaemon")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Access to Keychain Credentials Directories
+
+macOS keychains securely store user credentials, such as passwords and certificates, essential for system and application authentication. Adversaries may target these directories to extract sensitive information, bypassing security measures. The detection rule identifies suspicious access attempts by monitoring process activities related to keychain directories, excluding legitimate operations and known safe executables, thus highlighting potential credential theft activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and arguments that triggered the rule, focusing on the `process.args` field to understand which keychain directory was accessed.
+- Examine the `process.parent.executable` and `process.executable` fields to determine the origin of the process and assess whether it is a known or unknown application.
+- Check the `process.Ext.effective_parent.executable` field to identify the effective parent process and evaluate if it is a legitimate application or potentially malicious.
+- Use Osquery to list all processes currently accessing keychain directories with a query like: `SELECT pid, name, path FROM processes WHERE path LIKE '/Users/%/Library/Keychains/%' OR path LIKE '/Library/Keychains/%';`
+- Investigate the user account associated with the process by examining the `process.user.name` field to determine if the activity aligns with the user's typical behavior.
+- Correlate the timestamp of the alert with other system logs to identify any concurrent suspicious activities or anomalies.
+- Review recent login events and user activity to determine if there were any unauthorized access attempts around the time of the alert.
+- Analyze network connections initiated by the process using network monitoring tools to identify any suspicious outbound connections that may indicate data exfiltration.
+- Check for any recent changes or installations of software on the system that could explain the process's behavior, focusing on software that interacts with keychain data.
+- Consult threat intelligence sources to determine if the process or its parent is associated with known malicious activity or campaigns targeting macOS keychain data.
+
+### False positive analysis
+
+- Legitimate applications accessing keychain directories for routine operations may trigger false positives. For example, security software like Microsoft Defender or management tools like JAMF may access keychain data as part of their normal functionality.
+- Users can manage these false positives by adding exceptions for known safe executables and processes. This can be done by updating the detection rule to exclude specific process arguments or executables that are verified as non-threatening.
+- Regularly review and update the list of excluded processes and executables to ensure that only trusted applications are allowed access without triggering alerts.
+- Consider the context of the access attempt, such as the time of day or the user account involved, to further refine the detection rule and reduce false positives.
+- Collaborate with IT and security teams to identify and document legitimate use cases for keychain access, ensuring these are accounted for in the detection rule exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the process and user account involved in the suspicious access attempt, using available logs and forensic tools.
+- Review the process tree and command-line arguments to understand the context of the access attempt and determine if it was malicious.
+- If malicious activity is confirmed, reset passwords and revoke any compromised credentials associated with the affected keychain.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging for keychain access attempts and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Review and update security policies to ensure that only authorized applications and users have access to keychain directories.
+- Restore the system to its operational state by removing any malicious software and applying security patches and updates.
+- Conduct a post-incident review to identify gaps in security controls and improve detection and response capabilities.
+- Implement hardening measures such as enabling two-factor authentication and using strong, unique passwords for keychain-protected services."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
index 4eea3dcd5ff..28c97257961 100644
--- a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
+++ b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,48 @@ query = '''
 event.category:process and host.os.type:macos and event.type:start and
  process.name:(defaults or mkpassdb) and process.args:(ShadowHashData or "-dump")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Dumping Account Hashes via Built-In Commands
+
+On macOS, built-in commands like `defaults` and `mkpassdb` can be exploited by adversaries to extract user account hashes, which are crucial for credential access. These hashes, once obtained, can be cracked or used for unauthorized access and lateral movement within a network. The detection rule identifies suspicious process activities involving these commands and specific arguments, signaling potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `defaults` or `mkpassdb` commands in the process execution logs, focusing on the `process.name` and `process.args` fields.
+- Examine the `event.category`, `host.os.type`, and `event.type` fields to ensure the alert is specific to macOS and involves a process start event.
+- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it is an unusual account for such activity.
+- Investigate the parent process of the suspicious command execution to understand the context and origin of the command.
+- Use Osquery to list recent processes executed by the user in question to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE user = '<suspicious_user>' ORDER BY start_time DESC LIMIT 10;`
+- Analyze system logs for any other unusual activities or errors around the time of the alert to gather additional context.
+- Verify if there are any recent changes or updates to the system that might explain the use of these commands legitimately.
+- Check for any network connections initiated by the system around the time of the alert to identify potential data exfiltration attempts.
+- Review historical data to determine if there have been previous instances of similar command executions on the host.
+- Correlate the findings with other security tools and logs to identify if this activity is part of a broader attack pattern or isolated incident.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use the `defaults` or `mkpassdb` commands for legitimate purposes, such as managing user settings or performing system maintenance. These activities can trigger the detection rule, leading to false positives.
+- Software installations or updates: Certain software installations or updates might invoke these commands as part of their setup or configuration processes, which can be mistaken for malicious activity.
+- Automated scripts: Scripts designed for system management or user account maintenance might include these commands, causing alerts even though they are part of regular operations.
+- To manage false positives, users can create exceptions for known benign processes or scripts by whitelisting specific command executions that are verified as non-threatening. This can be done by identifying the process IDs or command patterns associated with legitimate activities and excluding them from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the presence of unauthorized access by reviewing logs and identifying any suspicious activities related to the `defaults` or `mkpassdb` commands.
+- Capture and preserve forensic evidence, including process execution details and any associated files, to support further analysis and potential legal actions.
+- Reset passwords for all affected accounts and consider implementing multi-factor authentication to enhance security.
+- Review and update security policies to ensure that only authorized personnel have access to sensitive commands and data.
+- Implement enhanced logging and monitoring for macOS systems to detect similar activities in the future, focusing on process execution and command-line arguments.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze potential threats more effectively.
+- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for further investigation and response.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are properly set.
+- Conduct a post-incident review to identify gaps in the security posture and implement hardening measures, such as disabling unnecessary services and restricting the use of built-in commands."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_dumping_keychain_security.toml b/rules/macos/credential_access_dumping_keychain_security.toml
index e9e879c94a9..010132600ff 100644
--- a/rules/macos/credential_access_dumping_keychain_security.toml
+++ b/rules/macos/credential_access_dumping_keychain_security.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,49 @@ type = "eql"
 query = '''
 process where host.os.type == "macos" and event.type in ("start", "process_started") and process.args : "dump-keychain" and process.args : "-d"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Dumping of Keychain Content via Security Command
+
+Keychains in macOS securely store user credentials, including passwords and certificates. Adversaries exploit this by using commands to extract keychain data, potentially gaining unauthorized access to sensitive information. The detection rule identifies suspicious activity by monitoring for specific command-line arguments associated with keychain dumping, alerting analysts to potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the "dump-keychain" and "-d" arguments in the process arguments, as these are indicative of keychain dumping attempts.
+- Identify the user account associated with the process to determine if the activity aligns with expected behavior or if it is potentially malicious.
+- Examine the parent process of the suspicious activity to understand how the keychain dumping command was initiated and if it was part of a larger chain of suspicious events.
+- Check the timestamp of the event to correlate with other security events or logs that might provide additional context or indicate a broader attack pattern.
+- Investigate the source IP address and geolocation, if available, to assess whether the activity originated from a trusted network or an unusual location.
+- Use Osquery to gather more information about the process. For example, run the following query to list all processes with similar command-line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%dump-keychain%' AND cmdline LIKE '%-d%';`
+- Analyze recent login events for the user account to determine if there were any unauthorized access attempts or anomalies around the time of the alert.
+- Review system logs for any other unusual activities or errors that occurred around the same time as the keychain dumping attempt.
+- Check for any recent changes to user permissions or system configurations that might have facilitated the keychain dumping attempt.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors currently exploiting keychain dumping techniques, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Routine administrative tasks or legitimate software updates may trigger the rule if they involve accessing or managing keychain data, as these processes might use similar command-line arguments.
+- Security or IT personnel conducting authorized audits or system checks might inadvertently match the rule criteria when verifying keychain integrity or performing backups.
+- Developers or advanced users using scripts or automation tools to manage their keychain entries for legitimate purposes could also be flagged.
+- To manage these false positives, users can create exceptions for known and trusted processes or users by whitelisting specific command invocations or user accounts that regularly perform these actions.
+- Implementing a baseline of normal keychain access patterns can help differentiate between legitimate and suspicious activities, allowing for more accurate filtering of alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the presence of unauthorized keychain access by reviewing system logs and correlating with the detected command-line arguments.
+- Identify and terminate any suspicious processes related to the keychain dumping activity to halt ongoing credential theft attempts.
+- Change all potentially compromised credentials stored in the keychain, including passwords for Wi-Fi, websites, and any other services.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed command-line activity and process execution on macOS systems for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all security patches are applied.
+- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
+- Educate users on security best practices, including recognizing phishing attempts and the importance of using strong, unique passwords for different services."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_kerberosdump_kcc.toml b/rules/macos/credential_access_kerberosdump_kcc.toml
index ef37c8198c4..6f422efeb4d 100644
--- a/rules/macos/credential_access_kerberosdump_kcc.toml
+++ b/rules/macos/credential_access_kerberosdump_kcc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,48 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   process.name:kcc and
   process.args:copy_cred_cache
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kerberos Cached Credentials Dumping
+
+Kerberos is a network authentication protocol that uses tickets to allow nodes to prove their identity securely. In macOS environments, the `kcc` utility manages these tickets. Adversaries may exploit `kcc` to extract cached credentials, facilitating unauthorized access and lateral movement. The detection rule identifies suspicious `kcc` activity by monitoring process initiation and specific arguments, signaling potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `kcc` process activity with the `copy_cred_cache` argument, as indicated by the query fields `process.name:kcc` and `process.args:copy_cred_cache`.
+- Correlate the timestamp of the suspicious `kcc` activity with other logs to identify any concurrent or subsequent suspicious activities, such as unusual network connections or file access.
+- Investigate the user account associated with the `kcc` process initiation to determine if the account has a history of legitimate use of Kerberos utilities or if it shows signs of compromise.
+- Examine the parent process of the `kcc` activity to understand how the process was initiated and whether it was triggered by a legitimate application or a potentially malicious script.
+- Use Osquery to gather additional context about the system state and running processes. For example, execute the following Osquery query to list all processes related to Kerberos activities: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%kcc%' OR cmdline LIKE '%kcc%';`
+- Check for any recent changes in user privileges or group memberships that could indicate an attempt to escalate privileges or gain unauthorized access to Kerberos tickets.
+- Analyze network logs to identify any unusual outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
+- Review historical logs for any previous instances of `kcc` usage on the host to determine if this is a recurring pattern or an isolated incident.
+- Investigate any other processes or scripts executed around the same time as the `kcc` activity to identify potential lateral movement or further credential access attempts.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar Kerberos credential dumping techniques.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use the `kcc` utility for legitimate purposes, such as managing Kerberos tickets during maintenance or troubleshooting, which could trigger the detection rule.
+- Automated scripts: Some automated scripts or management tools might invoke `kcc` with similar arguments for regular operations, leading to false positives.
+- Testing environments: In environments where security tools or protocols are being tested, `kcc` might be used frequently, causing benign alerts.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that regularly use `kcc` for legitimate purposes. This can be done by excluding certain user accounts or process arguments from triggering the alert, ensuring that only truly suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation to confirm the presence of unauthorized `kcc` activity by reviewing process logs and correlating with other security events.
+- Identify and terminate any suspicious processes related to `kcc` and any other unauthorized access attempts.
+- Change passwords for any accounts that may have been compromised, focusing on those with elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the affected system from a known good backup to ensure no malicious artifacts remain.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
index fc4b71083a3..370d673c43c 100644
--- a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
+++ b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,52 @@ process where host.os.type == "macos" and event.action == "exec" and
  process.command_line : ("*Chrome*", "*Chromium*", "*Opera*", "*Safari*", "*Brave*", "*Microsoft Edge*", "*Firefox*") and
  not process.parent.executable : "/Applications/Keeper Password Manager.app/Contents/Frameworks/Keeper Password Manager Helper*/Contents/MacOS/Keeper Password Manager Helper*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Keychain Password Retrieval via Command Line
+
+macOS Keychain securely stores user credentials, including passwords and certificates. Adversaries exploit command-line tools to extract these credentials, targeting applications like browsers. The detection rule identifies suspicious command executions involving keychain access commands and browser references, excluding legitimate password manager activities, to flag potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious command executions involving the `security` process with arguments `-wa` or `-ga` and `find-generic-password` or `find-internet-password`.
+- Verify the command line details to check for references to browsers such as Chrome, Chromium, Opera, Safari, Brave, Microsoft Edge, or Firefox, which may indicate an attempt to access stored credentials.
+- Cross-reference the process parent executable to ensure it is not originating from a legitimate password manager, specifically checking against the Keeper Password Manager.
+- Use Osquery to gather additional context on the process execution. For example, run the following query to list recent executions of the `security` command:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'security' AND cmdline LIKE '%find-generic-password%' OR cmdline LIKE '%find-internet-password%';
+  ```
+- Investigate the user account associated with the suspicious process to determine if it aligns with expected behavior or if it might be compromised.
+- Check system logs for any other unusual activities or errors around the time of the alert to identify potential correlations or additional indicators of compromise.
+- Analyze network activity from the host to detect any suspicious outbound connections that might suggest data exfiltration.
+- Review recent login events on the system to identify any unauthorized access attempts that could be related to the alert.
+- Examine the file system for any newly created or modified files that could be associated with credential theft tools or scripts.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors using similar techniques, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate applications or scripts that access the keychain for routine operations may trigger false positives. For example, automated scripts that manage browser settings or credentials for enterprise environments might use similar command-line arguments.
+- Developers or IT administrators using command-line tools for debugging or managing browser settings could inadvertently match the detection criteria.
+- Users can manage these false positives by creating exceptions for known, trusted applications or scripts that frequently access the keychain. This can be done by adding specific process names or command-line patterns to an exclusion list.
+- Regularly review and update the exclusion list to ensure it reflects current legitimate activities, especially after software updates or changes in IT policies.
+- Consider implementing additional context checks, such as verifying the user account executing the command or the network location, to differentiate between benign and malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the alert by reviewing the command execution logs and identifying any unauthorized access to keychain data.
+- If unauthorized access is confirmed, reset all potentially compromised credentials stored in the keychain, including Wi-Fi, website passwords, and any other sensitive information.
+- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed command-line activity and process execution on macOS systems for future investigations.
+- Integrate security tools with SIEM solutions to correlate events and improve detection capabilities for similar threats.
+- Restore the system to its operational state by ensuring all security patches and updates are applied, and conduct a full malware scan to remove any persistent threats.
+- Educate users on the importance of using strong, unique passwords and the risks associated with storing sensitive information in easily accessible locations.
+- Review and update security policies to include regular audits of keychain access and implement multi-factor authentication for accessing sensitive applications and data.
+- Utilize MITRE ATT&CK framework to continuously assess and improve defenses against credential access techniques, focusing on T1555 (Credentials from Password Stores)."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_mitm_localhost_webproxy.toml b/rules/macos/credential_access_mitm_localhost_webproxy.toml
index 6e915a16c92..00c7c6d787f 100644
--- a/rules/macos/credential_access_mitm_localhost_webproxy.toml
+++ b/rules/macos/credential_access_mitm_localhost_webproxy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,48 @@ event.category:process and host.os.type:macos and event.type:start and
                                   "/usr/libexec/xpcproxy") and
  not process.Ext.effective_parent.executable : ("/Applications/Proxyman.app/Contents/MacOS/Proxyman" or "/Applications/Incoggo.app/Contents/MacOS/Incoggo.app")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WebProxy Settings Modification
+
+WebProxy settings in macOS manage how web traffic is routed, often used to enhance security or performance. Adversaries may exploit these settings to intercept or redirect traffic, potentially capturing sensitive data like credentials. The detection rule identifies suspicious use of the `networksetup` command to alter proxy settings, excluding known legitimate applications, thus highlighting potential unauthorized modifications indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `networksetup` command with arguments like `-setwebproxy`, `-setsecurewebproxy`, or `-setautoproxyurl` in the process arguments.
+- Verify the process parent executable to ensure it is not one of the known legitimate applications such as `/Library/PrivilegedHelperTools/com.80pct.FreedomHelper`, `/Applications/Fiddler Everywhere.app/Contents/Resources/app/out/WebServer/Fiddler.WebUi`, or `/usr/libexec/xpcproxy`.
+- Check the effective parent executable to confirm it is not `/Applications/Proxyman.app/Contents/MacOS/Proxyman` or `/Applications/Incoggo.app/Contents/MacOS/Incoggo.app`.
+- Use Osquery to list all current proxy settings on the affected macOS system to identify any unauthorized changes. Example query: `SELECT * FROM preferences WHERE domain = 'com.apple.networkservices' AND key LIKE '%Proxy%';`
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that might correlate with the proxy settings modification.
+- Cross-reference the event with network logs to identify any unusual outbound connections or data exfiltration attempts following the proxy change.
+- Analyze other processes running on the host at the time of the alert to detect any additional suspicious activities or malware presence.
+- Review system logs for any failed or successful authentication attempts around the time of the alert to identify potential unauthorized access.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns targeting macOS systems.
+
+### False positive analysis
+
+- Known false positives for the WebProxy Settings Modification rule include legitimate applications that modify proxy settings for valid reasons, such as network management tools or security applications. These applications may use the `networksetup` command as part of their normal operation.
+- Users can manage these false positives by creating exceptions for known legitimate applications. This can be done by adding the application's executable path to the exclusion list in the detection rule, ensuring that routine and non-threatening behaviors are not flagged as suspicious.
+- Specific applications that may trigger false positives include network diagnostic tools, VPN clients, and security software that require proxy configuration to function correctly. Users should verify the legitimacy of these applications and update the exclusion list accordingly.
+- Regularly review and update the exclusion list to accommodate new legitimate applications or updates to existing ones, ensuring that the detection rule remains effective without generating unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Review the process execution details and command-line arguments to confirm unauthorized changes to WebProxy settings.
+- Check for any suspicious network traffic or connections that may indicate data interception or redirection.
+- Investigate the user account associated with the process execution to determine if it has been compromised.
+- Revert any unauthorized changes to the WebProxy settings using the `networksetup` command to restore normal network configuration.
+- Conduct a thorough scan of the system for malware or other indicators of compromise using updated security tools.
+- Escalate the incident to the security operations team if evidence of credential theft or broader compromise is found.
+- Implement enhanced logging for network configuration changes and monitor for any future unauthorized modifications.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures.
+- Apply security hardening measures, such as restricting access to network configuration commands and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
index 40b3b2d181e..2a80fe56946 100644
--- a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
+++ b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,48 @@ type = "threshold"
 query = '''
 event.category:process and host.os.type:macos and event.type:start and process.name:"sshd-keygen-wrapper" and process.parent.name:launchd
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential macOS SSH Brute Force Detected
+
+SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-keygen-wrapper` process is involved in SSH key generation. Adversaries may exploit this by repeatedly attempting to generate keys to gain unauthorized access, a technique known as brute force. The detection rule identifies unusual activity by monitoring for excessive SSH key generation attempts, signaling potential brute force attacks.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the number of `sshd-keygen-wrapper` process executions and verify if it meets or exceeds the threshold of 20 executions from the same host.
+- Check the `host.os.type` field to ensure the operating system is macOS, as the rule is specific to this OS.
+- Investigate the `process.parent.name` field to confirm that the parent process is `launchd`, which is expected for legitimate SSH key generation activities.
+- Use Osquery to list all recent processes executed on the host to identify any unusual or unauthorized activities. Example query: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name = 'sshd-keygen-wrapper';`
+- Examine the `event.category` and `event.type` fields to ensure the event is categorized as a process start, which aligns with the rule's focus on process execution.
+- Correlate the timestamps of the `sshd-keygen-wrapper` executions with user login attempts or other authentication logs to identify any patterns or anomalies.
+- Investigate the user accounts associated with the `sshd-keygen-wrapper` executions to determine if they are legitimate users or potentially compromised accounts.
+- Check for any recent changes in SSH configuration files on the host that might indicate tampering or misconfiguration that could facilitate brute force attempts.
+- Review network logs for any unusual inbound SSH traffic to the host, which might indicate external brute force attempts.
+- Analyze historical data to determine if this host has a pattern of similar alerts or if this is an isolated incident, which can help assess the severity and potential impact.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may perform legitimate tasks that involve generating multiple SSH keys, such as setting up new user accounts or configuring automated processes. These activities can trigger the detection rule as false positives.
+- Automated scripts or tools: Some automated scripts or tools used for system management or deployment may execute the `sshd-keygen-wrapper` process multiple times, leading to false positives.
+- Development environments: In development environments, developers might frequently generate SSH keys for testing purposes, which can be mistaken for brute force attempts.
+- To manage these false positives, users can create exceptions for known administrative activities or trusted scripts by excluding specific user accounts or processes from the detection rule. This can be done by refining the query to exclude certain conditions or by using allowlists for recognized non-threatening behaviors.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS host from the network to prevent further unauthorized access.
+- Review the system logs to identify the source IP addresses and user accounts involved in the excessive SSH key generation attempts.
+- Change passwords for all user accounts on the affected system and enforce strong password policies.
+- Investigate the source IP addresses for any known malicious activity or previous incidents.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Implement additional logging and monitoring for SSH activities, including successful and failed login attempts, to enhance future detection capabilities.
+- Integrate threat intelligence feeds to identify and block known malicious IP addresses attempting SSH brute force attacks.
+- Restore the system to its operational state by ensuring all unauthorized keys are removed and legitimate keys are verified.
+- Apply security patches and updates to the macOS system to mitigate any known vulnerabilities that could be exploited.
+- Harden the system by disabling SSH access for root accounts, using SSH key-based authentication, and configuring fail2ban or similar tools to block repeated failed login attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
index ac83ec10af5..7b07d7ec14b 100644
--- a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
+++ b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,48 @@ process where event.action == "exec" and host.os.type == "macos" and
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon",
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Prompt for Credentials with OSASCRIPT
+
+OSASCRIPT is a command-line utility in macOS used to execute AppleScript and other OSA language scripts. Adversaries may exploit it to display deceptive dialogs prompting users for credentials, mimicking legitimate requests. The detection rule identifies suspicious OSASCRIPT usage by monitoring specific command patterns and excluding known legitimate processes, thus highlighting potential credential phishing attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious `osascript` usage, focusing on the `process.command_line` field to identify if it includes patterns like `*display*dialog*password*` or `*display*dialog*passphrase*`.
+- Check the `process.parent.executable` field to determine the parent process of the `osascript` execution, ensuring it is not a known legitimate process such as `/usr/bin/sudo` or `/bin/bash` with specific command lines.
+- Investigate the `user.id` associated with the process to determine if the execution was performed by a privileged user, which might indicate a higher risk.
+- Examine the `process.Ext.effective_parent.executable` field to verify if the parent process is part of known legitimate applications like Jamf or Karabiner-Elements, which could explain the `osascript` usage.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list recent processes executed by the same user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'osascript' AND cmdline LIKE '%display dialog%');`
+- Analyze the timing of the `osascript` execution by reviewing the event timestamp to correlate with any user-reported suspicious activity or other security events.
+- Check system logs for any additional context or anomalies around the time of the `osascript` execution, such as login attempts or other process executions.
+- Investigate the network activity of the affected host around the time of the alert to identify any unusual outbound connections that might suggest data exfiltration.
+- Review any recent changes or updates to the system that might have introduced new scripts or applications capable of executing `osascript`.
+- Consult with the user of the affected system to determine if they recall any unexpected prompts or dialogs, which could provide insight into whether the alert was a false positive or a genuine phishing attempt.
+
+### False positive analysis
+
+- Legitimate administrative scripts: Some organizations use osascript in administrative scripts for legitimate purposes, such as automating system configurations or user notifications. These scripts might inadvertently match the detection criteria. To handle this, users can create exceptions for specific scripts by excluding their parent executable paths or command-line patterns.
+- Software management tools: Applications like JAMF or Karabiner-Elements may use osascript for legitimate functions, such as managing system settings or user preferences. These tools are often whitelisted in enterprise environments. Users can manage these false positives by adding exceptions for known software management tools, as indicated in the detection rule.
+- Terminal-based automation: Users or administrators might use Terminal to run osascript commands for automation tasks. If these tasks are routine and verified as non-threatening, users can exclude the Terminal executable path from the detection rule to prevent false positives.
+- System maintenance tasks: Some system maintenance tasks might involve osascript to prompt users for input or confirmation. If these tasks are part of regular system operations, users can exclude specific command-line patterns or parent processes associated with these tasks to reduce false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further credential theft or lateral movement.
+- Investigate the process tree to identify the source of the osascript execution and any associated scripts or files.
+- Terminate any suspicious processes related to the osascript activity to stop ongoing credential phishing attempts.
+- Review user accounts and credentials for any unauthorized access or changes, and reset passwords as necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Implement enhanced logging for osascript executions and other scripting activities on macOS systems to improve future detection capabilities.
+- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious script executions and process behaviors.
+- Restore the system to its operational state by removing any malicious scripts or files and applying security patches and updates.
+- Conduct a security awareness training session for users to recognize and report phishing attempts and suspicious dialogs.
+- Harden macOS systems by restricting script execution permissions and implementing application whitelisting to prevent unauthorized script usage."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
index 6bbf5dbfbe9..f48ef4293c4 100644
--- a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
+++ b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,48 @@ file where event.action == "open" and host.os.type == "macos" and process.execut
  not process.code_signature.signing_id : "org.mozilla.firefox" and
  not Effective_process.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Web Browser Sensitive File Access
+
+Web browsers store sensitive data like cookies and login credentials in specific files. Adversaries exploit this by accessing these files using untrusted or unsigned processes, potentially stealing credentials. The detection rule identifies such unauthorized access on macOS by monitoring file access events, focusing on untrusted processes or scripts, and excluding known legitimate applications. This helps in identifying potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file accessed and the untrusted process involved, focusing on the `file.name` and `process.executable` fields.
+- Verify the legitimacy of the process by checking the `process.code_signature.trusted` and `process.code_signature.exists` fields to confirm if the process is unsigned or untrusted.
+- Investigate the process's parent process using the `process.parent.executable` field to determine if it was spawned by a legitimate application or script.
+- Check the `process.name` field to see if the process is `osascript`, which could indicate a script-based attempt to access sensitive files.
+- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE name = '<process_name>';` to retrieve details like process path, arguments, and parent process.
+- Examine recent system logs for any unusual activity around the time of the alert, focusing on login events or other process executions that might correlate with the suspicious access.
+- Cross-reference the `host.os.type` field to ensure the alert pertains to a macOS system, confirming the environment context for the investigation.
+- Investigate the user account associated with the process by checking the `user.name` field to determine if the activity aligns with the user's typical behavior.
+- Review any recent changes or installations on the system that might have introduced the untrusted process, focusing on software updates or new applications.
+- Consult threat intelligence sources to check if the process or file access pattern matches known malicious activity or indicators of compromise.
+
+### False positive analysis
+
+- Legitimate applications or scripts that access browser files for non-malicious purposes, such as backup utilities or browser extensions, may trigger this rule. Users should verify the legitimacy of these applications and consider adding them to an exclusion list if they are frequently flagged.
+- System maintenance or security software that scans or interacts with browser files might be mistakenly identified as suspicious. Users can create exceptions for these trusted processes by adding their code signatures or executable paths to the exclusion criteria.
+- Developers or IT personnel using automation scripts that interact with browser data for testing or configuration purposes may also cause false positives. It is advisable to review these scripts and, if deemed safe, exclude them from the detection rule.
+- Updates or new installations of legitimate software that temporarily lack a recognized code signature might be flagged. Users should monitor these events and update the exclusion list once the software is verified and trusted.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the untrusted process or script that accessed the sensitive files, using endpoint detection and response (EDR) tools.
+- Review system and application logs to trace the origin and timeline of the suspicious activity, focusing on any anomalies around the time of the alert.
+- Verify the integrity of the accessed files and check for any unauthorized changes or data exfiltration.
+- If credentials are suspected to be compromised, initiate a password reset for affected accounts and review access logs for any unauthorized logins.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
+- Integrate threat intelligence feeds to correlate the activity with known threat actors or campaigns, leveraging MITRE ATT&CK framework for context.
+- Restore the system to its operational state by removing any malicious processes or scripts and applying security patches and updates.
+- Harden the system by implementing application whitelisting, ensuring all software is signed and trusted, and educating users on recognizing phishing attempts and suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_systemkey_dumping.toml b/rules/macos/credential_access_systemkey_dumping.toml
index 01434aa4c83..9a744c4d047 100644
--- a/rules/macos/credential_access_systemkey_dumping.toml
+++ b/rules/macos/credential_access_systemkey_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,48 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   process.args:("/private/var/db/SystemKey" or "/var/db/SystemKey") and
   not process.Ext.effective_parent.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SystemKey Access via Command Line
+
+In macOS, keychains securely store user credentials, including passwords and certificates. Adversaries may exploit command-line access to extract keychain data, gaining unauthorized credentials. The detection rule identifies suspicious process activities targeting SystemKey paths, excluding legitimate security processes, to flag potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious process activities targeting SystemKey paths, specifically checking the `process.args` field for "/private/var/db/SystemKey" or "/var/db/SystemKey".
+- Verify the `event.category` and `event.type` fields to ensure the event is related to a process start or initiation on a macOS host.
+- Examine the `process.Ext.effective_parent.executable` field to confirm that the process is not a legitimate security process, such as the Elastic Endpoint.
+- Use Osquery to list all processes that have accessed the SystemKey paths recently with a query like: `SELECT pid, name, path FROM processes WHERE path LIKE '/private/var/db/SystemKey%' OR path LIKE '/var/db/SystemKey%';`
+- Investigate the parent process of the suspicious activity by checking the `process.parent.name` and `process.parent.executable` fields to understand the origin of the process.
+- Check the `host.name` and `host.ip` fields to identify the affected system and correlate with any other suspicious activities on the same host.
+- Review user activity on the affected host by examining the `user.name` field to determine if the activity aligns with expected user behavior.
+- Analyze historical data for similar process activities on the same host or across the environment to identify patterns or repeated attempts.
+- Cross-reference the `process.name` and `process.executable` fields with known malicious or suspicious binaries to assess the threat level.
+- Consult threat intelligence sources to determine if the observed behavior or process is associated with known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Legitimate security software or system maintenance tools may access SystemKey paths as part of routine operations, leading to false positives. Users should identify these processes and consider excluding them from the detection rule.
+- macOS updates or system diagnostics might trigger access to SystemKey paths. Users can monitor update schedules and correlate them with alerts to determine if they are false positives.
+- Custom scripts or administrative tools developed in-house that require access to keychain data for legitimate purposes may also be flagged. Users should document these scripts and create exceptions for them in the detection rule.
+- Security audits or compliance checks performed by authorized personnel might involve accessing SystemKey paths. Users should ensure these activities are logged and recognized as non-threatening, adjusting the rule to exclude them if necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify any unauthorized processes or users accessing the SystemKey paths, focusing on the process arguments and parent processes.
+- Review system logs and security alerts to determine the scope of the breach and identify any other potentially compromised systems.
+- Terminate any suspicious processes identified during the investigation that are accessing the SystemKey paths without legitimate reasons.
+- Change all passwords and credentials stored in the keychain on the affected system and any other systems where the same credentials are used.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution data and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by reinstalling the operating system and applications, ensuring all security patches and updates are applied.
+- Harden the system by disabling unnecessary services, enforcing strong password policies, and implementing multi-factor authentication to reduce the risk of future credential theft."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_apple_softupdates_modification.toml b/rules/macos/defense_evasion_apple_softupdates_modification.toml
index 44a47192117..4ac545ec56e 100644
--- a/rules/macos/defense_evasion_apple_softupdates_modification.toml
+++ b/rules/macos/defense_evasion_apple_softupdates_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,48 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.name:defaults and
  process.args:(write and "-bool" and (com.apple.SoftwareUpdate or /Library/Preferences/com.apple.SoftwareUpdate.plist) and not (TRUE or true))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SoftwareUpdate Preferences Modification
+
+In macOS environments, the 'defaults' command is used to modify system and application preferences, including SoftwareUpdate settings. Adversaries may exploit this to disable security updates, weakening system defenses. The detection rule identifies suspicious 'defaults' command executions that attempt to alter SoftwareUpdate preferences, focusing on disabling updates without setting them to true, thus flagging potential defense evasion activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'defaults' command execution with arguments targeting SoftwareUpdate preferences, specifically looking for the absence of 'TRUE' or 'true' in the command.
+- Cross-reference the timestamp of the alert with user activity logs to identify which user account executed the command.
+- Examine the process lineage to determine the parent process of the 'defaults' command, which may provide context on how the command was initiated.
+- Check for any recent login events or changes in user permissions around the time of the alert to identify potential unauthorized access.
+- Use Osquery to inspect the current state of the SoftwareUpdate preferences by running: `SELECT * FROM plist WHERE path = '/Library/Preferences/com.apple.SoftwareUpdate.plist';` to verify if updates have been disabled.
+- Investigate other process executions around the same time to identify any additional suspicious activities or commands that may indicate a broader attack.
+- Analyze network logs for any unusual outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
+- Review system logs for any error messages or warnings related to SoftwareUpdate services that might indicate tampering or misconfiguration.
+- Check for any recent installations or modifications of software that could have introduced malicious scripts or tools used to execute the 'defaults' command.
+- Correlate the alert with other security events or alerts from the same host or user to identify patterns or repeated attempts to modify system settings.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators or IT personnel may use the 'defaults' command to configure SoftwareUpdate settings for maintenance or compliance purposes. These actions, while benign, can trigger the detection rule.
+- Automated scripts: Some management tools or scripts may programmatically adjust SoftwareUpdate preferences as part of routine system configuration, leading to false positives.
+- User customization: Advanced users might modify SoftwareUpdate settings to manage updates manually, which could be flagged by the rule.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that are verified as non-threatening. This can be done by excluding certain user accounts or process hashes from the detection rule. Additionally, monitoring the frequency and context of the 'defaults' command usage can help differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further potential compromise or spread.
+- Review the process execution logs to confirm the unauthorized use of the 'defaults' command targeting SoftwareUpdate preferences.
+- Investigate the source of the command execution to determine if it was initiated by a legitimate user or an adversary.
+- Restore the SoftwareUpdate preferences to their default state to ensure security updates are re-enabled.
+- Conduct a full system scan using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate with a centralized logging solution, such as a Security Information and Event Management (SIEM) system, to monitor for similar suspicious activities.
+- Apply hardening measures by restricting the use of the 'defaults' command to authorized users only and consider using configuration management tools to enforce security settings.
+- Review and update security awareness training for users to recognize and report suspicious activities related to system preferences and updates."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
index 651cb2eae28..03a695d6c57 100644
--- a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
+++ b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,53 @@ process.executable : ("/usr/bin/xattr",
                       "/Applications/.com.bomgar.scc.*/Remote Support Customer Client.app/Contents/MacOS/sdcust") and not
 file.path : "/private/var/folders/*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Quarantine Attrib Removed by Unsigned or Untrusted Process
+
+In macOS, files downloaded from the internet are tagged with a quarantine attribute, which is checked by Gatekeeper to ensure safety before execution. Adversaries may remove this attribute to bypass security checks. The detection rule identifies such actions by monitoring for the deletion of this attribute by untrusted or unsigned processes, excluding known safe executables and paths, thus highlighting potential evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process executable involved in the quarantine attribute removal. Pay attention to the `file.path` and `process.executable` fields.
+- Verify the legitimacy of the process executable by checking its code signature status. Use the `process.code_signature.trusted` and `process.code_signature.exists` fields to determine if the process is unsigned or untrusted.
+- Cross-reference the process executable path against known safe executables and paths to ensure it is not mistakenly flagged. Refer to the exclusion list in the detection rule.
+- Investigate the parent process of the flagged executable to understand the process hierarchy and determine if the parent process is legitimate or suspicious.
+- Use Osquery to gather additional context about the process and file involved. For example, run the following Osquery command to check for recent file modifications and process details:
+  ```sql
+  SELECT * FROM file WHERE path = '<file_path>';
+  SELECT * FROM processes WHERE pid = <process_id>;
+  ```
+- Check system logs for any related events or anomalies around the time the quarantine attribute was removed. Look for unusual activity that might correlate with the alert.
+- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential compromise.
+- Examine network activity from the host to identify any suspicious outbound connections that might suggest data exfiltration or command-and-control communication.
+- Review recent downloads or installations on the system to identify any potentially malicious software that could have triggered the alert.
+- Consult threat intelligence sources to determine if the process or file path is associated with known malware or adversary techniques, providing additional context for the investigation.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate applications or system processes that are not signed or trusted remove the quarantine attribute. This can include custom scripts or third-party applications that are not widely recognized or signed by Apple.
+- Users can handle these false positives by creating exceptions for specific processes or paths that are known to be safe. This can be done by adding these processes or paths to the exclusion list in the detection rule.
+- Frequent non-threatening behaviors, such as updates or installations from trusted sources that are not signed, can be excluded by specifying their executable paths in the exclusion criteria.
+- It is important to regularly review and update the exclusion list to ensure that only legitimate processes are excluded, maintaining a balance between security and usability.
+- Users should monitor the behavior of excluded processes to ensure they do not become vectors for malicious activity, as threat actors may attempt to exploit these exceptions.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further potential malicious activity and lateral movement.
+- Verify the process responsible for removing the quarantine attribute by checking its executable path and signature status.
+- Conduct a thorough investigation of the process's origin and behavior, including reviewing recent downloads and installations on the system.
+- If the process is confirmed malicious, remove the associated files and any other suspicious files or applications installed around the same time.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and file attribute changes for future investigations.
+- Integrate with threat intelligence platforms to correlate the activity with known threat actors or campaigns.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited.
+- Educate users on safe downloading practices and the importance of verifying the source of applications to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
index 9cf185bb72a..16269af0209 100644
--- a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
+++ b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
   process.args:(spctl and "--master-disable")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Disable Gatekeeper
+
+Gatekeeper is a macOS security feature that ensures only trusted software is executed by verifying app signatures. Adversaries may attempt to disable Gatekeeper to bypass these checks and run malicious code. The detection rule identifies such attempts by monitoring process activities for specific commands that indicate an effort to disable Gatekeeper, thus alerting analysts to potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the specific command `spctl --master-disable` in the `process.args` field, which indicates an attempt to disable Gatekeeper.
+- Check the `event.category` and `event.type` fields to ensure the event is related to a process start on a macOS host, confirming the context of the alert.
+- Identify the user account associated with the process by examining the `user.name` field to determine if the action was initiated by a legitimate user or a potential adversary.
+- Investigate the `process.name` and `process.executable` fields to gather more information about the process attempting to disable Gatekeeper, including its origin and legitimacy.
+- Use Osquery to list all processes running on the affected host to identify any other suspicious activities. Example query: `SELECT pid, name, path FROM processes WHERE name LIKE '%spctl%';`
+- Examine the `host.name` and `host.ip` fields to identify the affected machine and assess if it is part of a larger pattern or isolated incident.
+- Review recent login events on the affected host to identify any unauthorized access attempts that could correlate with the Gatekeeper disable attempt.
+- Analyze the `process.parent.name` and `process.parent.executable` fields to trace the parent process that initiated the Gatekeeper disable command, which may provide insights into the attack vector.
+- Check for any recent changes in system settings or configurations on the affected host that could indicate further tampering or preparation for executing malicious code.
+- Correlate the alert with other security events or logs from the same timeframe to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Legitimate administrative actions: System administrators or IT personnel may intentionally disable Gatekeeper for troubleshooting or software testing purposes. These actions can trigger the detection rule, leading to false positives.
+- Software development activities: Developers working on macOS applications might disable Gatekeeper to test unsigned apps during the development process, which can be mistakenly flagged as malicious behavior.
+- Custom scripts or automation tools: Some organizations use scripts or automation tools that include commands to disable Gatekeeper as part of their workflow, potentially causing false alerts.
+- To manage these false positives, users can create exceptions for known and trusted administrative accounts or specific processes that are regularly involved in legitimate Gatekeeper disabling activities. This can be done by refining the detection rule to exclude certain user accounts or process paths that are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration.
+- Verify the presence of unauthorized changes by reviewing system logs and Gatekeeper settings to confirm if it has been disabled.
+- Conduct a thorough investigation to identify any malicious processes or files that may have been executed following the Gatekeeper disablement attempt.
+- Restore Gatekeeper to its default state by re-enabling it using the command `sudo spctl --master-enable` and ensure that system integrity is maintained.
+- Escalate the incident to the security operations team for further analysis and to determine if this attempt is part of a broader attack campaign.
+- Implement enhanced logging policies to capture detailed process execution data and command-line arguments for future monitoring and analysis.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context on similar threats.
+- Review and update security policies to include regular audits of security settings and configurations, ensuring compliance with best practices.
+- Educate users on the importance of security features like Gatekeeper and the risks associated with disabling them, reinforcing the organization's security culture.
+- Conduct a post-incident review to identify gaps in the current security posture and develop a plan to address these vulnerabilities, including potential system hardening measures such as application whitelisting and regular software updates."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_install_root_certificate.toml b/rules/macos/defense_evasion_install_root_certificate.toml
index c4d2d688080..61354a85f92 100644
--- a/rules/macos/defense_evasion_install_root_certificate.toml
+++ b/rules/macos/defense_evasion_install_root_certificate.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,49 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   not process.parent.executable:("/Library/Bitdefender/AVP/product/bin/BDCoreIssues" or "/Applications/Bitdefender/SecurityNetworkInstallerApp.app/Contents/MacOS/SecurityNetworkInstallerApp"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Install Root Certificate
+
+Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by validating identities. Adversaries exploit this by installing rogue root certificates on compromised macOS systems, bypassing security warnings to stealthily connect to malicious servers. The detection rule identifies such attempts by monitoring specific process activities related to certificate installation, excluding known legitimate processes, thus highlighting potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `process.name:security` and `process.args:"add-trusted-cert"` fields, which indicate an attempt to add a trusted certificate.
+- Verify the `event.category:process` and `event.type:(start or process_started)` fields to ensure the alert is related to a process initiation event on a macOS system.
+- Check the `host.os.type:macos` field to confirm the operating system is macOS, as the rule is specifically designed for this environment.
+- Investigate the `process.parent.executable` field to determine if the parent process is one of the known legitimate processes excluded in the rule, such as Bitdefender applications.
+- Use Osquery to list all installed root certificates on the system to identify any recent or suspicious additions. Example query: `SELECT * FROM certificates WHERE common_name LIKE '%root%' AND issuer LIKE '%root%';`
+- Examine system logs for any other unusual activities or errors around the time of the alert to gather additional context.
+- Cross-reference the process execution details with known threat intelligence sources to identify if the certificate or process is associated with known malicious activity.
+- Analyze network logs to identify any connections made by the system to external servers around the time of the alert, focusing on any untrusted or suspicious IP addresses.
+- Review user activity logs to determine if the certificate installation was initiated by a legitimate user or if it was potentially automated or unauthorized.
+- Check for any recent changes in system configurations or installed applications that might explain the certificate installation, ensuring to rule out legitimate administrative actions.
+
+### False positive analysis
+
+- Known false positives for the Attempt to Install Root Certificate rule may include legitimate software installations or updates that require adding trusted certificates, such as security software or enterprise applications.
+- Users can manage these false positives by creating exceptions for known legitimate processes that frequently trigger the rule, such as those associated with trusted security software like Bitdefender.
+- To handle these exceptions, users should identify the parent executable paths of legitimate processes and add them to the exclusion list in the detection rule, ensuring that only non-threatening behaviors are excluded.
+- Regularly review and update the list of exceptions to accommodate new legitimate software that may require root certificate installation, maintaining a balance between security and operational efficiency.
+- It's crucial to monitor the environment for any changes in software behavior that could indicate a shift from legitimate to potentially malicious activity, adjusting the exceptions as necessary to maintain robust security controls.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further communication with potential malicious servers.
+- Verify the presence of unauthorized root certificates by checking the system's keychain and remove any suspicious certificates that are not recognized or expected.
+- Conduct a thorough investigation of the process activity logs to identify the source and timeline of the root certificate installation attempt.
+- Cross-reference the process parent executable with known legitimate applications to ensure no false positives are present.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all unauthorized changes are reverted.
+- Apply security hardening measures such as disabling unnecessary services, enforcing strong authentication mechanisms, and regularly updating software and security patches.
+- Educate users on the risks of unauthorized certificate installations and the importance of reporting suspicious activities to the IT department promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_modify_environment_launchctl.toml b/rules/macos/defense_evasion_modify_environment_launchctl.toml
index 4cd4dfee4f8..a8691ee53a4 100644
--- a/rules/macos/defense_evasion_modify_environment_launchctl.toml
+++ b/rules/macos/defense_evasion_modify_environment_launchctl.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,49 @@ event.category:process and host.os.type:macos and event.type:start and
                                   /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or 
                                   /usr/local/bin/kr)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Environment Variable via Unsigned or Untrusted Parent
+
+Environment variables in macOS can influence application behavior by specifying settings or paths. Adversaries exploit this by using the `launchctl` command to alter these variables, potentially loading malicious libraries or bypassing security measures. The detection rule identifies such modifications initiated by untrusted or unsigned parent processes, focusing on suspicious `launchctl` usage and excluding known safe applications, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which environment variable was modified and the specific `launchctl` command used.
+- Examine the `process.parent.code_signature` field to determine if the parent process is unsigned or untrusted, which could indicate a potential threat.
+- Investigate the parent process by checking its `process.parent.executable` path to identify the application or script that initiated the `launchctl` command.
+- Use Osquery to gather more information about the parent process. For example, run the following query to get details about the parent process: `SELECT * FROM processes WHERE pid = <parent_process_id>;`.
+- Check the `process.args` field to identify the specific environment variable being set and assess whether it is commonly used or potentially malicious.
+- Cross-reference the `process.parent.executable` with known safe applications to ensure it is not mistakenly flagged, as indicated in the exclusion list of the detection rule.
+- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Review recent system logs and user activity to identify any unusual behavior or patterns that coincide with the time of the alert.
+- Analyze network activity from the host to detect any suspicious outbound connections that may indicate data exfiltration or command-and-control communication.
+- If applicable, use Osquery to list all environment variables for the affected process to understand the full context of the environment: `SELECT * FROM environment WHERE pid = <affected_process_id>;`.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate applications or scripts that are unsigned or lack a trusted code signature but are not malicious. These can include custom scripts or third-party applications that modify environment variables for legitimate purposes.
+- Users can handle these false positives by creating exceptions for specific parent processes that are known to be safe. This can be done by adding the executable paths of these trusted applications to the exclusion list in the detection rule.
+- Frequent non-threatening behaviors, such as development tools or automation scripts that use `launchctl` to set environment variables, can be excluded by identifying their parent process paths and ensuring they are added to the exclusion criteria.
+- It is important to regularly review and update the list of exclusions to ensure that new legitimate applications are not flagged as threats, while maintaining vigilance against potential adversarial activities.
+- Users should also verify the legitimacy of unsigned applications by checking their source and purpose, ensuring they are not inadvertently allowing malicious activities through overly broad exclusions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the untrusted or unsigned parent process that modified the environment variable using `launchctl`.
+- Review system logs and process execution history to determine if any malicious payloads were executed or if any unauthorized libraries were loaded.
+- Remove any identified malicious files or libraries and restore any altered environment variables to their original state.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has a broader presence in the network.
+- Implement enhanced logging policies to capture detailed process execution and environment variable changes, ensuring future incidents can be detected more effectively.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
+- Apply system and application patches to address any vulnerabilities that may have been exploited by the adversary.
+- Educate users on recognizing and reporting suspicious activities, emphasizing the importance of running only trusted applications.
+- Review and update security policies and procedures to include specific measures against environment variable hijacking and unauthorized use of `launchctl`."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
index 044d6b27ab3..3b7c695be15 100644
--- a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
+++ b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,48 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
  process.args : "/*/Application Support/com.apple.TCC/TCC.db" and
  not process.parent.executable : "/Library/Bitdefender/AVP/product/bin/*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privacy Control Bypass via TCCDB Modification
+
+The Transparency, Consent, and Control (TCC) database in macOS manages app permissions for accessing sensitive resources. Adversaries may exploit this by using tools like sqlite3 to alter the TCC database, bypassing privacy controls to access resources like the camera or microphone. The detection rule identifies such attempts by monitoring for suspicious sqlite3 activity targeting the TCC database, excluding legitimate processes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of sqlite3 activity targeting the TCC database, specifically checking the process name and arguments for "sqlite*" and "/*/Application Support/com.apple.TCC/TCC.db".
+- Verify the parent process of the sqlite3 activity to ensure it is not a legitimate process, such as those from "/Library/Bitdefender/AVP/product/bin/*".
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities on the system.
+- Investigate the user account associated with the process to determine if it is a legitimate user or if the account may have been compromised.
+- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE name LIKE 'sqlite%' AND path LIKE '%/Application Support/com.apple.TCC/TCC.db%';`
+- Examine system logs around the time of the event for any other anomalies or related activities that could provide further context.
+- Investigate any recent changes to the TCC database by querying for recent modifications: `SELECT * FROM file WHERE path = '/Application Support/com.apple.TCC/TCC.db' AND mtime > (SELECT datetime('now', '-1 day'));`
+- Check for any other processes or scripts that may have been executed around the same time as the sqlite3 activity to identify potential automation or scripts used by an adversary.
+- Review network activity logs to identify any outbound connections that may indicate data exfiltration or communication with a command and control server.
+- Consult with the user or system owner to verify if any legitimate maintenance or software updates were performed that could explain the sqlite3 activity.
+
+### False positive analysis
+
+- Legitimate software updates or system maintenance tasks may trigger the rule if they involve sqlite3 operations on the TCC database. Users can handle these by identifying the specific update or maintenance process and adding it to an exclusion list.
+- Security software or system monitoring tools that perform regular checks on the TCC database might also be flagged. To manage this, users should verify the legitimacy of these tools and exclude their processes from the detection rule.
+- Developers or IT administrators conducting authorized testing or debugging on macOS systems may inadvertently trigger the rule. In such cases, users should document these activities and create exceptions for the specific processes involved.
+- Automated backup or synchronization applications that access the TCC database for legitimate reasons could be misidentified as threats. Users should confirm the application's purpose and add it to the exclusion list if deemed safe.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the unauthorized modification of the TCC database by reviewing system logs and identifying any suspicious sqlite3 activity.
+- Terminate any unauthorized processes that are currently accessing or modifying the TCC database.
+- Restore the TCC database from a known good backup to ensure that all privacy settings are reverted to their original state.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to monitor for future unauthorized access attempts, focusing on sqlite3 activity and changes to the TCC database.
+- Integrate with security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Apply macOS security updates and patches to address any vulnerabilities that may have been exploited.
+- Educate users on the importance of maintaining application permissions and the risks associated with unauthorized modifications.
+- Review and update security policies to include specific measures for protecting the TCC database and other critical system components."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
index 0e9e1000b8e..ad79f7aed53 100644
--- a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
+++ b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,49 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
  process.command_line:("scp *localhost:/*", "scp *127.0.0.1:/*") and
  not process.args:"vagrant@*127.0.0.1*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privacy Control Bypass via Localhost Secure Copy
+
+Secure Copy Protocol (SCP) is used for secure file transfers over SSH. On macOS, SSHD can gain Full Disk Access, potentially allowing unauthorized file access. Adversaries might exploit this by copying files locally, bypassing privacy controls. The detection rule identifies such activity by monitoring SCP commands targeting localhost, excluding benign uses like Vagrant, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of SCP commands targeting localhost or 127.0.0.1, as indicated by the `process.command_line` field.
+- Verify the `process.args` field to ensure that the SCP command includes `StrictHostKeyChecking=no`, which might indicate an attempt to bypass SSH security checks.
+- Check the `process.name` field to confirm that the process involved is indeed `scp`, ensuring the alert is not a false positive.
+- Investigate the user account associated with the SCP command to determine if it is a legitimate user or potentially compromised.
+- Examine the timing and frequency of the SCP commands to identify patterns or anomalies that could suggest malicious activity.
+- Use Osquery to gather additional context about the process. For example, run the following query to list recent SCP processes: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name = 'scp';`
+- Cross-reference the SCP activity with other logs, such as SSH authentication logs, to identify any unauthorized access attempts or anomalies.
+- Investigate the source and destination paths involved in the SCP command to determine if sensitive files were targeted.
+- Check for any other suspicious activities on the host around the same time, such as unusual network connections or file modifications.
+- Review the system's Full Disk Access settings to ensure that only authorized applications have the necessary permissions, and verify if SSHD has been improperly added.
+
+### False positive analysis
+
+- **Vagrant Usage**: The rule excludes SCP commands involving Vagrant, as it commonly uses localhost for virtual machine management. Users should ensure that any Vagrant-related SCP activity is correctly excluded by verifying the exclusion pattern matches their specific Vagrant configurations.
+- **Local Development and Testing**: Developers may use SCP to transfer files between local environments for testing purposes. Users can manage these false positives by identifying and excluding specific user accounts or directories frequently involved in legitimate development activities.
+- **Automated Backup Scripts**: Some backup solutions might use SCP to copy files locally as part of their routine operations. Users should review and whitelist known backup scripts or processes to prevent them from being flagged.
+- **System Maintenance Tasks**: IT administrators might perform maintenance tasks that involve SCP commands targeting localhost. Users can handle these by creating exceptions for specific maintenance scripts or by scheduling these tasks during known maintenance windows to reduce false alerts.
+- **Custom Applications**: Organizations may have custom applications that use SCP for legitimate local file transfers. Users should document these applications and create specific exclusions based on process names or command-line patterns to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify any unauthorized SCP activities by reviewing system logs and correlating them with the detection rule triggers.
+- Verify the integrity of sensitive files and check for any unauthorized modifications or access, focusing on files that may have been targeted by the SCP command.
+- Remove SSHD from the Full Disk Access list if it was added without proper authorization, and review the list for any other unauthorized applications.
+- Escalate the incident to the security operations team if evidence of data exfiltration or further compromise is found, and consider involving legal or compliance teams if sensitive data is involved.
+- Implement enhanced logging policies to capture detailed command-line activities and file access events, ensuring that future incidents can be detected and investigated more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying any necessary patches, updating security configurations, and ensuring that all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing strict access controls.
+- Educate users and administrators on the risks associated with improper use of SCP and SSH, and provide training on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_safari_config_change.toml b/rules/macos/defense_evasion_safari_config_change.toml
index 599eef17f93..71561afd43d 100644
--- a/rules/macos/defense_evasion_safari_config_change.toml
+++ b/rules/macos/defense_evasion_safari_config_change.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,49 @@ event.category:process and host.os.type:macos and event.type:start and
       )
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Safari Settings via Defaults Command
+
+The 'defaults' command in macOS is a powerful utility for modifying application settings, including Safari's configuration. Adversaries may exploit this to alter Safari settings, potentially enabling harmful features like JavaScript from Apple Events, which can facilitate browser hijacking. The detection rule identifies suspicious 'defaults' command usage targeting Safari settings, excluding benign modifications, to flag potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific Safari setting was modified using the 'defaults' command, focusing on the process.args field to identify the exact change.
+- Check the event.timestamp to determine when the modification occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the user account associated with the process.user.name field to determine if the account has a history of making unauthorized changes or if it has been compromised.
+- Examine the process.parent.name and process.parent.args fields to identify the parent process that initiated the 'defaults' command, which might provide context on how the command was executed.
+- Use Osquery to list recent processes executed by the user to identify any other potentially malicious activities. Example query: `SELECT * FROM processes WHERE user = '<user_name>' ORDER BY start_time DESC LIMIT 10;`
+- Check system logs for any other unusual activities or errors around the time of the modification, which might indicate a broader attack or compromise.
+- Investigate network connections from the host using Osquery to identify any suspicious outbound connections that could suggest data exfiltration or command and control activity. Example query: `SELECT * FROM process_open_sockets WHERE pid = <suspicious_pid>;`
+- Review any recent changes to the system's configuration or installed applications that could have facilitated the unauthorized modification of Safari settings.
+- Analyze the host's security software logs to check for any alerts or blocked activities that coincide with the time of the Safari settings modification.
+- Consult with the user or system owner to verify if the change was authorized or if they noticed any unusual behavior on their system, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Users may frequently modify Safari settings for legitimate reasons, such as personalizing their browsing experience or enhancing privacy. These benign changes can trigger false positives if they involve settings not explicitly excluded in the detection rule.
+- System administrators might use scripts to configure Safari settings across multiple devices for compliance or standardization purposes. These automated processes can be mistaken for malicious activity.
+- Developers and testers might adjust Safari settings to test web applications or browser features, leading to false positives if these changes are not part of the excluded settings.
+- To manage these false positives, users can create exceptions for known benign processes or scripts by adding specific process arguments to the exclusion list in the detection rule.
+- Regularly review and update the exclusion list to include new non-threatening behaviors as they are identified, ensuring that legitimate activities are not flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity or data exfiltration.
+- Review the process execution logs to confirm the unauthorized use of the 'defaults' command targeting Safari settings and identify any other suspicious activities.
+- Terminate any suspicious processes that may have been initiated as a result of the altered Safari settings.
+- Restore Safari settings to their default state using a known good configuration or by manually resetting the settings through the Safari preferences.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
+- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate with a centralized security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
+- Apply security patches and updates to the macOS system and Safari browser to mitigate known vulnerabilities.
+- Educate users on the risks of unauthorized configuration changes and reinforce the importance of reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
index 0c821e217e4..6486d19dd41 100644
--- a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
+++ b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ type = "query"
 query = '''
 event.category:file and host.os.type:(macos and macos) and not event.type:deletion and file.name:~$*.zip
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Microsoft Office Sandbox Evasion
+
+Microsoft Office applications on macOS operate within a sandbox to limit potential damage from malicious files. However, adversaries can exploit this by creating zip files with special character prefixes, allowing them to bypass sandbox restrictions and execute unauthorized actions. The detection rule identifies such suspicious zip file creations, focusing on non-deletion events with specific naming patterns, to flag potential evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a zip file with a name starting with special characters, as indicated by the `file.name:~$*.zip` pattern.
+- Verify the `event.category:file` and `host.os.type:macos` fields to ensure the event pertains to a file operation on a macOS system.
+- Check the `event.type` field to confirm that the event is not a deletion, which aligns with the rule's focus on non-deletion events.
+- Investigate the source of the zip file creation by identifying the user account and process responsible for the action.
+- Use Osquery to list recent file creations in the suspected directory. Example query: `SELECT path, filename, uid, gid, atime, mtime FROM file WHERE path LIKE '/path/to/suspected/directory/%' AND filename LIKE '~$%.zip';`
+- Examine the process tree to identify any parent processes that may have initiated the suspicious file creation, focusing on Microsoft Office applications.
+- Analyze system logs for any related events or anomalies around the time of the zip file creation to gather additional context.
+- Check for any AutoStart locations that may have been modified or targeted by the suspicious zip file to facilitate sandbox evasion.
+- Investigate any network connections or external communications initiated by the system around the time of the event to identify potential data exfiltration or command-and-control activity.
+- Correlate the findings with other security alerts or incidents to determine if this event is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate applications or processes that create zip files with special character prefixes for valid reasons, such as temporary file storage or backup processes, may trigger false positives.
+- Automated scripts or system processes that generate zip files with special characters as part of their normal operation can be mistakenly flagged.
+- Users can manage these false positives by identifying and documenting known benign processes that exhibit this behavior and creating exceptions for them in the detection rule.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening activities are excluded, maintaining the integrity of the detection system.
+- Consider implementing additional context checks, such as verifying the source application or process, to differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized actions or data exfiltration.
+- Conduct a thorough investigation to identify the source of the suspicious zip file and any associated processes or files that may have been executed.
+- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) related to the sandbox evasion technique.
+- Review system and application logs to trace the origin of the zip file and any user accounts involved in its creation or execution.
+- Remove any unauthorized files or applications identified during the investigation and ensure that the system is free from malicious software.
+- Restore the system to a known good state using backups or system restore points, ensuring that all security patches and updates are applied.
+- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on files with special character prefixes.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar evasion techniques.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Apply hardening measures such as restricting the execution of files with special character prefixes and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
index 8accc83b579..46c912d7be6 100644
--- a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
+++ b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,49 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:mount_apfs and
   process.args:(/System/Volumes/Data and noowners)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 TCC Bypass via Mounted APFS Snapshot Access
+
+Apple's TCC framework safeguards user data by controlling app access to sensitive files. Adversaries exploit APFS snapshots, mounting them with specific flags to bypass these controls, gaining unauthorized access to protected data. The detection rule identifies suspicious use of the `mount_apfs` command, focusing on arguments that indicate attempts to access the file system without ownership restrictions, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `mount_apfs` command with the `noowners` flag in the process arguments, as this is a key indicator of potential misuse.
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time for additional context.
+- Identify the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates a compromised account.
+- Investigate the parent process of `mount_apfs` to understand how it was initiated and whether it was part of a legitimate workflow or a suspicious chain of processes.
+- Use Osquery to list all mounted file systems and verify if any APFS snapshots are currently mounted with the `noowners` flag. Example query: `SELECT * FROM mounts WHERE device LIKE '%snapshot%' AND options LIKE '%noowners%';`
+- Examine system logs for any other unusual activities or errors around the time of the alert that might indicate tampering or exploitation attempts.
+- Cross-reference the event with any recent changes or updates to the system that might have inadvertently triggered the alert, such as software installations or system updates.
+- Analyze network activity from the host to identify any potential data exfiltration attempts or connections to known malicious IP addresses.
+- Review historical data for similar alerts or patterns of behavior from the same host or user account to assess if this is an isolated incident or part of a recurring issue.
+- Consult threat intelligence sources to determine if there are any known campaigns or adversaries currently exploiting APFS snapshot access for TCC bypass, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate system maintenance or backup processes may trigger the rule if they involve mounting APFS snapshots with the `noowners` flag, as these operations can mimic the behavior of an adversary attempting to bypass TCC protections.
+- Security or IT administrators performing routine checks or data recovery might use the `mount_apfs` command with similar arguments, leading to false positives.
+- Users can manage these false positives by creating exceptions for known maintenance scripts or backup applications that regularly perform these actions, ensuring they are documented and verified as non-threatening.
+- Implementing a whitelist for specific processes or users that are authorized to perform such operations can help reduce noise from legitimate activities.
+- Regularly review and update the list of exceptions to ensure that only trusted processes are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the use of the mount_apfs command with the noowners flag and identify any unauthorized access to sensitive files.
+- Review system logs and process execution history to determine the scope of the compromise and identify any additional affected systems.
+- Remove any unauthorized APFS snapshots and ensure that no malicious processes are running on the system.
+- Restore the system from a known good backup prior to the unauthorized access, ensuring that all security patches and updates are applied.
+- Implement enhanced logging policies to monitor for suspicious use of the mount_apfs command and other potential indicators of compromise.
+- Integrate security tools with SIEM solutions to improve detection capabilities and automate alerting for similar threats in the future.
+- Conduct a security audit of the TCC framework settings and permissions to ensure that only authorized applications have access to sensitive data.
+- Educate users and administrators on the risks associated with APFS snapshot access and the importance of maintaining strict access controls.
+- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further investigation and guidance."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
index 332860d1f4b..f8a34db6516 100644
--- a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
+++ b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,53 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:kextunload and process.args:("/System/Library/Extensions/EndpointSecurity.kext" or "EndpointSecurity.kext")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 uses kernel extensions on macOS to monitor and protect system activities at a low level. Adversaries may attempt to disable these extensions using the `kextunload` command to evade detection and impair defenses. The detection rule identifies such attempts by monitoring process events for the execution of `kextunload` targeting the specific security extension, signaling potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `kextunload` command targeting `EndpointSecurity.kext` in the process arguments.
+- Check the timestamp of the event to determine when the attempt occurred and correlate it with other security events around the same time.
+- Identify the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
+- Investigate the parent process of `kextunload` to understand the context of how it was executed and if it was part of a larger chain of suspicious activities.
+- Examine the host's recent login history to identify any unusual or unauthorized access attempts that could be related to the event.
+- Use Osquery to gather additional context about the process and user activity on the host. For example, run the following query to list recent processes executed by the same user:
+  ```sql
+  SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');
+  ```
+- Check for any recent changes to system configurations or security settings that might indicate tampering or preparation for the unload attempt.
+- Analyze network activity from the host around the time of the event to identify any potential command and control communications or data exfiltration attempts.
+- Review system logs for any error messages or warnings related to kernel extensions that might provide additional context or indicate other attempts to impair defenses.
+- Cross-reference the event with threat intelligence sources to determine if the activity matches known tactics, techniques, and procedures (TTPs) of specific threat actors.
+
+### False positive analysis
+
+- System administrators or IT personnel may intentionally unload the Elastic Endpoint Security kernel extension during maintenance or troubleshooting activities, which can trigger the detection rule. 
+- Software updates or system upgrades might require unloading kernel extensions temporarily, leading to benign alerts.
+- Developers working on macOS kernel extensions might use `kextunload` as part of their development and testing processes, resulting in non-malicious detections.
+- To manage these false positives, users can create exceptions for specific user accounts or processes known to perform legitimate `kextunload` operations regularly.
+- Implementing a whitelist of trusted scripts or applications that require unloading the kernel extension can help reduce unnecessary alerts.
+- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further potential malicious activity.
+- Verify the legitimacy of the `kextunload` command execution by checking user activity logs and correlating with authorized change management records.
+- Conduct a thorough investigation to determine if the attempt was part of a broader attack, using endpoint detection and response (EDR) tools to analyze related processes and network connections.
+- If unauthorized, remove any malicious software or scripts that may have initiated the `kextunload` command and restore the Elastic Endpoint Security kernel extension.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Review and enhance logging policies to ensure comprehensive monitoring of kernel extension activities and unauthorized command executions.
+- Implement additional security measures, such as application whitelisting and stricter user permissions, to prevent unauthorized unloading of kernel extensions.
+- Update and patch the macOS system and security software to the latest versions to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on the importance of security practices and the risks associated with unauthorized system modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/discovery_users_domain_built_in_commands.toml b/rules/macos/discovery_users_domain_built_in_commands.toml
index bc38d1d3874..b9bb23d2770 100644
--- a/rules/macos/discovery_users_domain_built_in_commands.toml
+++ b/rules/macos/discovery_users_domain_built_in_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,49 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                  "/Applications/NoMAD.app/Contents/MacOS/NoMAD",
                                                  "/Applications/ESET Management Agent.app/Contents/MacOS/ERAAgent")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Enumeration of Users or Groups via Built-in Commands
+
+Built-in commands on macOS, such as `ldapsearch`, `dsmemberutil`, and `dscl`, are essential for managing and querying user and group information. Adversaries exploit these to gather insights into user accounts and group memberships, aiding in privilege escalation or lateral movement. The detection rule identifies suspicious use of these commands by monitoring their execution patterns and excluding known legitimate applications, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command executed, focusing on `process.name` and `process.args` fields to understand the nature of the enumeration attempt.
+- Examine the `process.parent.executable` and `process.Ext.effective_parent.executable` fields to determine the parent process that initiated the command, which can provide context on whether the execution was part of a legitimate application or potentially malicious activity.
+- Check the `process.parent.name` and `process.Ext.effective_parent.name` fields to identify any unusual or suspicious parent process names that might indicate unauthorized use.
+- Investigate the user account associated with the process execution to determine if the account has a history of similar activities or if it has been compromised.
+- Utilize Osquery to gather additional context on the system. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
+- Cross-reference the execution time of the command with other security events or logs to identify any correlated activities that might suggest a broader attack pattern.
+- Analyze network logs to check for any outbound connections made by the system around the time of the command execution, which could indicate data exfiltration attempts.
+- Review system logs for any recent changes to user accounts or group memberships that could be related to the enumeration activity.
+- Check for any other alerts or incidents involving the same host or user account to assess if this is part of a larger attack campaign.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that use similar enumeration techniques, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate applications such as security tools, system management software, or network monitoring solutions may trigger this rule due to their need to query user and group information for legitimate purposes. Examples include QualysCloudAgent, Kaspersky Anti-Virus, and ESET Endpoint Security.
+- System administrators or IT support personnel may use these commands during routine maintenance or troubleshooting, leading to benign alerts.
+- To manage these false positives, users can create exceptions for known legitimate applications by excluding their executable paths from the detection rule. This can be done by adding the application's executable path to the exclusion list in the detection query.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate applications that may trigger the rule.
+- Consider implementing additional context-based checks, such as verifying the user account executing the command or correlating with other suspicious activities, to reduce false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the activity, including reviewing logs for any unauthorized access or changes to user accounts and groups.
+- Utilize endpoint detection and response (EDR) tools to analyze the execution patterns of the identified commands and correlate them with known malicious behaviors.
+- If unauthorized enumeration is confirmed, reset passwords for affected accounts and review group memberships to ensure no unauthorized changes have been made.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed command execution and user activity, ensuring that logs are stored securely and retained for an appropriate period.
+- Integrate threat intelligence feeds to identify known indicators of compromise (IOCs) related to the detected activity and update detection rules accordingly.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are in line with best practices.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to prevent similar incidents in the future.
+- Educate users on security best practices and the importance of reporting suspicious activity to help prevent social engineering attacks that could lead to unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
index 37396801ec4..25d118b498c 100644
--- a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
+++ b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,53 @@ type = "query"
 query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and process.args:("-e" and const*require*child_process*)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution via Electron Child Process Node.js Module
+
+Electron applications, built on Node.js, can execute system commands using the child_process module, inheriting parent process permissions. Adversaries exploit this to run unauthorized commands, leveraging elevated privileges. The detection rule identifies such activities on macOS by monitoring process events and specific command patterns, flagging potential misuse of the child_process module.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the specific process arguments that triggered the alert, focusing on the presence of "-e" and "require('child_process')".
+- Examine the parent process of the flagged process to determine if it is a legitimate Electron application, using the `process.parent.name` and `process.parent.executable` fields.
+- Check the user account associated with the process using `user.name` to assess if it aligns with expected usage patterns or if it might be compromised.
+- Investigate the command line arguments (`process.args`) further to identify any suspicious or unexpected commands being executed.
+- Use Osquery to list all running Electron applications and their associated processes to identify any anomalies:
+  ```sql
+  SELECT name, path, pid, parent, cmdline FROM processes WHERE name LIKE '%Electron%';
+  ```
+- Correlate the process start time (`event.start`) with any known user activity or scheduled tasks to determine if the execution was expected.
+- Analyze the network activity of the process using `network.traffic` logs to identify any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
+- Review recent file modifications or creations in directories commonly used by Electron applications to detect any unauthorized changes or script injections.
+- Check for any recent changes in the Electron application's source code or configuration files that might indicate tampering or the introduction of malicious code.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise related to Electron applications.
+
+### False positive analysis
+
+- Legitimate Electron applications often use the child_process module for valid operations such as spawning subprocesses for performance optimization or handling asynchronous tasks, which can trigger the detection rule.
+- Developers may use the child_process module during the development and testing phases of Electron applications, leading to benign process events being flagged.
+- Automated scripts or tools that rely on Electron applications for system management tasks might also generate alerts, as they frequently execute system commands.
+- To manage these false positives, users can create exceptions for known and trusted Electron applications by whitelisting specific process names or paths associated with legitimate use cases.
+- Implementing a baseline of normal behavior for Electron applications within the environment can help distinguish between expected and anomalous activities, reducing unnecessary alerts.
+- Regularly updating the list of trusted applications and processes can ensure that new legitimate use cases are not mistakenly flagged as threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes or installations of Electron applications.
+- Review process execution logs and command history to determine the specific commands executed via the child_process module.
+- Terminate any unauthorized or suspicious processes identified during the investigation to halt further malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to a known good state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting the use of the child_process module in Electron applications and enforcing the principle of least privilege for application permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
index a0c384dc8ef..e4c66a85907 100644
--- a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
+++ b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -82,6 +82,49 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
       "/usr/local/*brew*"
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Browser Child Process
+
+Web browsers often spawn child processes to handle tasks like rendering content or executing scripts. Adversaries exploit this by injecting malicious scripts or commands, leveraging browsers as entry points for attacks. The detection rule identifies unusual child processes spawned by browsers on macOS, focusing on shell scripts and command-line tools often used in attacks, while excluding known benign processes. This helps in pinpointing potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific browser and child process involved, focusing on the `process.parent.name` and `process.name` fields.
+- Examine the `process.command_line` field to understand the exact command executed by the child process, looking for any unusual or unexpected arguments.
+- Check the `process.args` field to identify any arguments that might indicate malicious activity, ensuring they are not part of the known benign exclusions.
+- Use Osquery to list all processes spawned by the identified browser during the time of the alert. Example query: `SELECT * FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'Google Chrome' OR name = 'firefox' OR name = 'Safari');`
+- Investigate the parent process's history to determine if it has been involved in any other suspicious activities or alerts.
+- Correlate the alert with any recent network activity logs to identify potential data exfiltration or communication with known malicious IPs.
+- Check the system's browser history to identify the websites visited around the time of the alert, looking for any known malicious or suspicious domains.
+- Review any recent downloads or file modifications on the system that might be related to the suspicious process execution.
+- Analyze the user account associated with the process to determine if there have been any unusual login attempts or privilege escalations.
+- Consult threat intelligence sources to see if the command line or process name matches any known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Known false positives may include legitimate scripts or command-line tools executed by browser extensions or plugins, which are not inherently malicious but match the detection criteria.
+- System updates or software installations that use shell scripts or command-line tools can trigger the rule, especially if they are initiated through a browser download or update process.
+- Users can manage these false positives by creating exceptions for specific command-line patterns or arguments that are known to be safe, such as those related to software updates or trusted applications.
+- Regularly review and update the exclusion list to include new benign processes or command-line patterns that are identified over time, ensuring that the detection rule remains effective without generating excessive noise.
+- Consider the context of the process execution, such as the parent process and the command-line arguments, to differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential threats.
+- Conduct a thorough investigation of the suspicious process, including reviewing the command line and parent process details to understand the scope of the compromise.
+- Terminate any malicious processes identified during the investigation to halt ongoing malicious activity.
+- Review browser and system logs to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations team if the threat appears to be part of a larger attack campaign or if sensitive data may have been accessed.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all patches and updates are applied.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Educate users on safe browsing practices and the risks of executing unknown scripts or commands from web browsers.
+- Apply security hardening measures such as disabling unnecessary browser plugins, enforcing strict content security policies, and using browser isolation techniques to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_installer_package_spawned_network_event.toml b/rules/macos/execution_installer_package_spawned_network_event.toml
index 2e53cc22289..234cf30723c 100644
--- a/rules/macos/execution_installer_package_spawned_network_event.toml
+++ b/rules/macos/execution_installer_package_spawned_network_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,49 @@ sequence by host.id with maxspan=15s
 [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and process.parent.name : ("installer", "package_script_service") and process.name : ("bash", "sh", "zsh", "python", "osascript", "tclsh*")] by process.entity_id
 [network where host.os.type == "macos" and event.type == "start" and process.name : ("curl", "osascript", "wget", "python", "java", "ruby", "node")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 MacOS Installer Package Spawns Network Event
+
+MacOS installer packages, often with a .pkg extension, are used to distribute software. Adversaries exploit this by embedding scripts that execute upon installation, potentially launching network connections to download further malicious payloads. The detection rule identifies suspicious behavior by monitoring for installer-related processes spawning shell commands, followed by network activity, indicating possible malicious package execution.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `process.entity_id` involved in the suspicious activity.
+- Examine the parent process name (`installer` or `package_script_service`) to confirm it is associated with a MacOS installer package.
+- Investigate the child process spawned (e.g., `bash`, `sh`, `zsh`, `python`) to determine if it executed any unusual or unexpected commands.
+- Check the network activity details, focusing on the process name (`curl`, `osascript`, `wget`, `python`, `java`, `ruby`, `node`) to identify any suspicious external connections.
+- Use Osquery to gather additional context on the processes involved. For example, run the following query to list recent processes executed by the installer: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'installer');`
+- Investigate the command line arguments of the suspicious processes to identify any potentially malicious scripts or commands.
+- Review the file paths and hashes of the installer package and any downloaded files to check for known malicious signatures or anomalies.
+- Analyze the timing and sequence of events to determine if the network activity directly followed the process execution, indicating a potential download of additional payloads.
+- Check system logs for any other related events or anomalies around the time of the alert to gather more context on the system's state.
+- Correlate the findings with threat intelligence sources to determine if the behavior matches any known attack patterns or campaigns.
+
+### False positive analysis
+
+- Legitimate software installations: Some legitimate software packages may use scripts to perform necessary setup tasks, including network connections to download updates or additional components. Users should verify the source and integrity of the software to determine if the behavior is expected.
+- System updates: MacOS system updates or software updates from trusted vendors might trigger this rule due to their use of scripts and network connections during the installation process. Users can create exceptions for known update processes to prevent false positives.
+- Development tools: Developers using scripting languages and network tools for legitimate purposes, such as testing or deploying applications, may inadvertently trigger this rule. Users can exclude specific development environments or tools from monitoring to reduce false positives.
+- Automated scripts: Automated maintenance or configuration scripts that use network connections might be flagged. Users should review these scripts and, if deemed safe, add them to an exclusion list to avoid repeated alerts.
+- Custom software deployments: Organizations deploying custom software internally may use installer packages with embedded scripts that access the network. Users should ensure these packages are signed and trusted, then configure exceptions for these known processes.
+
+### Response and remediation
+
+- Immediately isolate the affected MacOS system from the network to prevent further malicious activity and data exfiltration.
+- Conduct a thorough investigation to identify the malicious package by reviewing recent installations and correlating them with the alert timestamp.
+- Terminate any suspicious processes identified in the alert, such as those initiated by the installer package, to halt ongoing malicious activities.
+- Remove the identified malicious package and any additional payloads it may have downloaded to ensure the system is free from threats.
+- Review and analyze system logs, including process execution and network activity, to understand the scope of the compromise and identify any lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity, aiding in future investigations and threat detection.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all security patches are applied.
+- Harden the system by implementing security best practices, such as disabling unnecessary services, enforcing application whitelisting, and educating users on recognizing phishing attempts and suspicious software."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_script_via_automator_workflows.toml b/rules/macos/execution_script_via_automator_workflows.toml
index 55faccc4136..4be83af433e 100644
--- a/rules/macos/execution_script_via_automator_workflows.toml
+++ b/rules/macos/execution_script_via_automator_workflows.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,50 @@ sequence by host.id with maxspan=30s
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "automator"]
  [network where host.os.type == "macos" and process.name:"com.apple.automator.runner"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Automator Workflows Execution
+Automator is a macOS utility that automates repetitive tasks through workflows. Adversaries may exploit this by embedding malicious JavaScript for Automation (JXA) in custom workflows, bypassing traditional script execution methods. The detection rule identifies this threat by monitoring the Automator process initiation followed by network activity from its XPC service, indicating potential malicious use.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and timestamp of the suspicious Automator process initiation.
+- Check the process lineage to determine the parent process of the Automator execution, which may provide insight into how it was launched.
+- Investigate the user account associated with the Automator process to determine if it aligns with expected behavior or if it appears compromised.
+- Examine recent file modifications or creations in directories commonly used for Automator workflows, such as ~/Library/Services or ~/Library/Automator, to identify any newly added or modified workflows.
+- Use Osquery to list all Automator workflows on the system and check for any unusual or unauthorized entries:
+  ```sql
+  SELECT * FROM file WHERE directory LIKE '/Users/%/Library/Services' OR directory LIKE '/Users/%/Library/Automator';
+  ```
+- Analyze the contents of any suspicious Automator workflows to identify embedded JavaScript for Automation (JXA) code that may indicate malicious intent.
+- Correlate the network activity from the com.apple.automator.runner process with known malicious IP addresses or domains to assess potential exfiltration or command-and-control communication.
+- Review system logs for any additional context around the time of the Automator process execution, focusing on security and application logs for anomalies.
+- Investigate other processes or network connections initiated by the same user or host around the same timeframe to identify potential lateral movement or further malicious activity.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns involving Automator or JXA.
+
+### False positive analysis
+
+- Legitimate use of Automator workflows by users or system processes can trigger false positives, especially if they involve network activity. Users should identify and document regular workflows that are known to be safe.
+- System updates or third-party applications that utilize Automator for legitimate automation tasks may also cause alerts. Monitoring and documenting these activities can help differentiate between benign and suspicious behavior.
+- Users can manage false positives by creating exceptions for specific workflows or processes that are verified as non-threatening. This can be done by whitelisting known safe process names or network activities associated with trusted applications.
+- Regularly review and update the list of exceptions to ensure that new legitimate workflows are accounted for, while also being cautious not to overlook potential threats.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity and potential lateral movement.
+- Conduct a thorough investigation of the Automator workflows on the affected system to identify any unauthorized or suspicious scripts, particularly those containing JavaScript for Automation (JXA).
+- Review recent file modifications and system logs to trace the origin of the malicious workflow and determine if any other systems are affected.
+- Remove any identified malicious workflows and associated files from the system to prevent re-execution.
+- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on Automator and related services.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Educate users on the risks of executing untrusted workflows and scripts, emphasizing the importance of verifying the source of any automation tools.
+- Apply system hardening measures, such as restricting the execution of scripts and workflows to trusted sources and regularly updating macOS and security software to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
index d643bd904f1..e5db388d4be 100644
--- a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
+++ b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,48 @@ sequence by host.id, process.entity_id with maxspan=30s
     "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")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Apple Script Execution followed by Network Connection
+
+AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries exploit it to execute scripts that initiate network connections, potentially for command and control activities. The detection rule identifies such behavior by monitoring the osascript process for network activity shortly after script execution, excluding local and reserved IP addresses to focus on suspicious external connections.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the osascript process was involved, noting the `host.id` and `process.entity_id` for correlation.
+- Check the timestamp of the osascript process start event to establish a timeline and determine if the network connection occurred within the 30-second window.
+- Identify the destination IP address from the network event and verify if it is external and potentially malicious by cross-referencing threat intelligence sources.
+- Use Osquery to gather additional context on the osascript process by running a query such as: `SELECT * FROM processes WHERE name = 'osascript' AND pid = <process_id>;` to retrieve details like parent process, command line arguments, and execution path.
+- Investigate the parent process of osascript to determine if it was spawned by a legitimate application or a suspicious process.
+- Examine recent system logs and user activity around the time of the alert to identify any unusual behavior or script execution attempts.
+- Analyze the command line arguments used with osascript to understand the script's purpose and whether it aligns with known malicious patterns.
+- Check for any additional network connections made by the osascript process to other external IPs that might indicate further command and control activity.
+- Review historical data for the same `host.id` to identify any previous similar alerts or patterns of suspicious behavior involving osascript.
+- If available, use endpoint detection and response (EDR) tools to perform a deeper analysis of the affected host, focusing on file modifications, registry changes, and other indicators of compromise related to the osascript execution.
+
+### False positive analysis
+
+- Legitimate automation scripts: Users may have legitimate AppleScripts that automate tasks and require network access, such as scripts for data synchronization or cloud service interactions. To handle these, users can create exceptions for known scripts by whitelisting specific script names or paths.
+- Software updates and system processes: Some macOS system processes or third-party applications might use AppleScript for updates or network communications. Users should monitor and identify these processes, then exclude them from the detection rule by adding their process identifiers or network patterns to an exception list.
+- Development and testing environments: Developers often use AppleScript for testing network-related functionalities. In such environments, users can reduce false positives by excluding specific host IDs or IP ranges associated with development machines.
+- Remote management tools: IT departments might use AppleScript for remote management tasks that involve network connections. Users can manage these false positives by identifying and excluding the IP addresses or hostnames of known management servers from the detection criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity and potential data exfiltration.
+- Conduct a thorough investigation of the osascript process to determine the script's origin and intent, checking for any unauthorized or suspicious scripts.
+- Review network logs to identify any external IP addresses the osascript process attempted to connect to, and block these IPs at the network perimeter.
+- Analyze the system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations.
+- Remove any identified malicious scripts or files from the system and ensure that the osascript process is not running unauthorized tasks.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring that the backup is free from compromise.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on scripting and network connection events.
+- Integrate threat intelligence feeds to update detection rules with known malicious IP addresses and script signatures.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Apply system hardening measures, such as disabling unnecessary scripting capabilities and enforcing strict application control policies, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_shell_execution_via_apple_scripting.toml b/rules/macos/execution_shell_execution_via_apple_scripting.toml
index c0c517e9ea0..fd997015f15 100644
--- a/rules/macos/execution_shell_execution_via_apple_scripting.toml
+++ b/rules/macos/execution_shell_execution_via_apple_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ sequence by host.id with maxspan=5s
  [process where host.os.type == "macos" and event.type in ("start", "process_started", "info") and process.name == "osascript" and process.args : "-e"] by process.entity_id
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : ("sh", "bash", "zsh") and process.args == "-c" and process.args : ("*curl*", "*pbcopy*", "*http*", "*chmod*")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Shell Execution via Apple Scripting
+
+AppleScript and JXA are scripting languages used in macOS to automate tasks by executing system commands. Adversaries exploit these by using functions like `doShellScript` to run shell commands, potentially for malicious activities. The detection rule identifies such abuse by monitoring for shell processes initiated by `osascript` with specific arguments, indicating possible unauthorized command execution.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `osascript` execution with the `-e` argument, indicating potential AppleScript or JXA usage.
+- Examine the parent process of `osascript` to determine if it was initiated by a legitimate application or user action.
+- Investigate the specific shell command executed by `sh`, `bash`, or `zsh` with the `-c` argument, focusing on suspicious patterns like `curl`, `pbcopy`, `http`, or `chmod`.
+- Correlate the process entity IDs between `osascript` and the shell process to confirm the sequence of execution and identify any anomalies.
+- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Utilize Osquery to gather additional context on the processes involved. For example, run the following query to list recent `osascript` executions: `SELECT * FROM processes WHERE name = 'osascript' AND cmdline LIKE '%-e%';`
+- Investigate network connections made by the system around the time of the alert to identify any suspicious outbound traffic, especially related to `curl` or `http`.
+- Review system logs for any additional indicators of compromise or related suspicious activity around the time of the alert.
+- Analyze any files or scripts referenced in the command arguments for malicious content or unexpected modifications.
+- Cross-reference the alert with other security tools or logs to identify if this activity is part of a broader attack pattern or isolated incident.
+
+### False positive analysis
+
+- Legitimate automation scripts: Users may have legitimate AppleScripts or JXA scripts that automate tasks using `doShellScript` or `do shell script` to execute shell commands. These scripts might trigger the detection rule if they include commands like `curl`, `pbcopy`, `http`, or `chmod`. To manage this, users can create exceptions for known scripts by whitelisting specific script paths or process hashes.
+- System maintenance tools: Some system maintenance or monitoring tools might use AppleScript to execute shell commands for legitimate purposes. These tools can be identified and excluded from the detection rule by specifying their process names or command patterns in the exception list.
+- Developer environments: Developers often use scripting to automate build processes or other development tasks, which might involve shell command execution. Users can handle these false positives by excluding processes associated with known development environments or by setting up alerts only for non-development systems.
+- User-initiated scripts: Users might manually run scripts that include shell commands for personal productivity or customization. To reduce false positives, users can configure the detection rule to ignore scripts executed from specific user directories or by certain user accounts known to perform such activities.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the scope of the compromise by reviewing logs and identifying any additional systems that may have been affected.
+- Terminate any suspicious processes initiated by 'osascript' and any associated shell processes to stop ongoing malicious activities.
+- Analyze the command history and scripts executed via 'osascript' to understand the adversary's actions and objectives.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying the latest security patches, removing any unauthorized software, and ensuring all security configurations are up to date.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary scripting capabilities, enforcing least privilege access, and using application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
index c6fe7a360a3..92ff97a3da0 100644
--- a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
+++ b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -124,6 +124,51 @@ process where event.action == "exec" and host.os.type == "macos" and
         "/usr/sbin/networksetup"
       )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious macOS MS Office Child Process
+
+Microsoft Office applications on macOS, like Word and Excel, can execute child processes, a feature often exploited by adversaries through malicious macros or document exploits. Attackers may launch scripts or utilities to gain unauthorized access or execute malicious payloads. The detection rule identifies unusual child processes spawned by Office apps, filtering out benign activities and known false positives, to pinpoint potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Microsoft Office application and child process involved, focusing on the `process.parent.name` and `process.name` fields.
+- Examine the `process.command_line` to understand the exact command executed by the child process, which may provide insights into the intent and potential malicious activity.
+- Check the `process.args` field to identify any arguments passed to the child process that could indicate suspicious behavior or attempts to evade detection.
+- Investigate the `process.parent.executable` and `process.Ext.effective_parent.executable` fields to verify the legitimacy of the parent process and ensure it is not a known false positive.
+- Use Osquery to gather additional context about the parent and child processes. For example, run the following Osquery query to list recent processes executed by Microsoft Office applications:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name IN ('Microsoft Word', 'Microsoft Excel', 'Microsoft PowerPoint', 'Microsoft Outlook', 'Microsoft OneNote'));
+  ```
+- Analyze the network activity associated with the suspicious process using network monitoring tools or logs to identify any unusual outbound connections or data exfiltration attempts.
+- Cross-reference the `process.name` with known malicious scripts or utilities to determine if the child process is commonly associated with malware or exploitation techniques.
+- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the alert.
+- Investigate the user account associated with the process execution to determine if there are any signs of account compromise or unauthorized access.
+- Consult threat intelligence sources to check if the observed behavior or process names are linked to known threat actors or campaigns targeting macOS systems.
+
+### False positive analysis
+
+- Known false positives include processes related to product version discovery and Office error reporting behavior, such as commands involving "ProductVersion", "hw.model", "ioreg", and paths like "/Library/Application Support/Microsoft/MERP*/Microsoft Error Reporting.app/Contents/MacOS/Microsoft Error Reporting".
+- False positives may also arise from legitimate applications and services like ToDesk, Privacy-i, Addigy, Elastic Agent, and JumpCloud Agent, which are filtered out by excluding their executables from detection.
+- Users can manage these false positives by adding exceptions for specific process arguments and parent executables that are known to be benign, ensuring that frequent non-threatening behaviors do not trigger alerts.
+- It is important to regularly review and update the list of exceptions to adapt to changes in legitimate software behavior and maintain effective threat detection.
+
+### Response and remediation
+
+- Isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the suspicious child process to determine the scope and impact of the potential compromise.
+- Review the parent Office document for any embedded macros or scripts that may have triggered the malicious activity.
+- Remove any identified malicious files or scripts from the system and ensure that all Office applications are updated to the latest security patches.
+- Escalate the incident to the security operations team if the investigation reveals a broader threat or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors and techniques.
+- Restore the system to its operational state by reinstalling affected applications and verifying system integrity.
+- Educate users on recognizing phishing attempts and the risks associated with enabling macros in Office documents.
+- Apply hardening measures such as disabling macros by default and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
index 9013d41a7ab..0ac29de3aab 100644
--- a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
+++ b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,48 @@ query = '''
 event.category:process and host.os.type:macos and event.type:start and
  process.args:("-action" and ("-kerberoast" or askhash or asktgs or asktgt or s4u or ("-ticket" and ptt) or (dump and (tickets or keytab))))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Kerberos Attack via Bifrost
+
+Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. Adversaries exploit tools like Bifrost on macOS to manipulate Kerberos tickets, enabling unauthorized access through techniques like pass-the-ticket or kerberoasting. The detection rule identifies suspicious process activities linked to Bifrost's known attack methods, focusing on specific command-line arguments indicative of such exploits.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious command-line arguments such as "-action", "-kerberoast", "askhash", "asktgs", "asktgt", "s4u", "-ticket ptt", or "dump tickets/keytab" in the process arguments.
+- Correlate the process start event with the user account associated with the process to determine if the account is legitimate and authorized to perform such actions.
+- Examine the parent process of the suspicious activity to identify if it was initiated by a legitimate application or script, which might indicate a false positive.
+- Check the process execution history on the affected host to identify any other unusual or unauthorized activities that might be related to the alert.
+- Utilize Osquery to gather additional context on the suspicious process. For example, run the following query to list all processes with similar arguments: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%-action%' AND (cmdline LIKE '%-kerberoast%' OR cmdline LIKE '%askhash%' OR cmdline LIKE '%asktgs%' OR cmdline LIKE '%asktgt%' OR cmdline LIKE '%s4u%' OR (cmdline LIKE '%-ticket%' AND cmdline LIKE '%ptt%') OR (cmdline LIKE '%dump%' AND (cmdline LIKE '%tickets%' OR cmdline LIKE '%keytab%')));`
+- Investigate the network connections established by the suspicious process to identify any unusual or unauthorized communication with external or internal systems.
+- Analyze the system logs for any Kerberos-related events that coincide with the time of the alert to identify potential unauthorized authentication attempts.
+- Review recent changes to the system, such as software installations or updates, that might have introduced the Bifrost tool or similar utilities.
+- Check for any other alerts or indicators of compromise on the same host or within the same network segment that might suggest a broader attack campaign.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently exploiting Bifrost or similar tools, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate administrative activities: System administrators may use Bifrost or similar tools for legitimate purposes such as testing Kerberos configurations or performing security audits. These activities can trigger the detection rule, leading to false positives.
+- Automated scripts: Some organizations may have automated scripts that interact with Kerberos tickets for maintenance or monitoring purposes. These scripts might use command-line arguments similar to those flagged by the detection rule.
+- Security testing: Security teams conducting penetration tests or red team exercises might intentionally use Bifrost to simulate attacks, which could be misidentified as genuine threats.
+- To manage false positives, users can create exceptions for known benign activities by whitelisting specific processes or users that are verified to perform legitimate tasks. Additionally, organizations can refine the detection rule to exclude certain command-line arguments or process paths that are consistently associated with non-threatening behavior.
+
+### Response and remediation
+
+- Isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the presence of Bifrost or any unauthorized Kerberos ticket manipulation by reviewing process logs and command-line arguments.
+- Revoke any compromised Kerberos tickets and reset credentials for affected accounts to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the attack.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments on macOS systems for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates to macOS and related software.
+- Conduct a security audit of Kerberos configurations and policies to ensure they adhere to best practices and reduce the risk of exploitation.
+- Educate users and administrators on recognizing and reporting suspicious activities related to Kerberos authentication and ticket usage.
+- Review and update access controls and permissions to ensure the principle of least privilege is enforced across the network."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_mounting_smb_share.toml b/rules/macos/lateral_movement_mounting_smb_share.toml
index 567c47b2457..e2b8bda188d 100644
--- a/rules/macos/lateral_movement_mounting_smb_share.toml
+++ b/rules/macos/lateral_movement_mounting_smb_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
   ) and
   not process.parent.executable : "/Applications/Google Drive.app/Contents/MacOS/Google Drive"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Mount SMB Share via Command Line
+
+SMB (Server Message Block) is a protocol used for network file sharing, allowing users to access files on remote servers. On macOS, commands like `mount_smbfs` facilitate this interaction. Adversaries exploit SMB to move laterally within networks by accessing shared resources using stolen credentials. The detection rule identifies suspicious command executions related to SMB mounting, excluding benign processes like Google Drive, to flag potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific command triggered the alert, focusing on the `process.name` and `process.args` fields to identify the exact method used for the SMB mount attempt.
+- Examine the `process.parent.executable` field to determine the parent process that initiated the SMB mount command, which can provide context on whether the action was user-initiated or potentially automated by a script or application.
+- Check the user account associated with the process execution to verify if it is a legitimate user and if the account has a history of accessing SMB shares.
+- Investigate the timestamp of the event to correlate with any other suspicious activities or alerts that occurred around the same time, which might indicate a coordinated attack or lateral movement attempt.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following Osquery query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
+- Analyze network logs to identify any unusual SMB traffic patterns or connections to unfamiliar or suspicious IP addresses, which might indicate unauthorized access attempts.
+- Review system logs for any failed authentication attempts or unusual login activities that could suggest credential theft or misuse.
+- Investigate any recent changes to the system or user account, such as password changes or new software installations, that could be related to the alert.
+- Check for any other alerts or indicators of compromise on the same host that might suggest a broader security incident.
+- Consult with the user or system owner to verify if the SMB mount attempt was legitimate and authorized, and gather any additional context or explanations they might provide.
+
+### False positive analysis
+
+- Known false positives for the Attempt to Mount SMB Share via Command Line rule include legitimate applications or scripts that mount SMB shares as part of their normal operation, such as backup software or file synchronization tools.
+- Users can handle these false positives by creating exceptions for specific processes or parent executables that are known to perform legitimate SMB mounting, such as excluding specific backup software paths.
+- Frequent non-threatening behaviors can be excluded by refining the detection rule to ignore processes with specific command-line arguments or parent processes that are verified as safe.
+- It is important to regularly review and update the list of exceptions to ensure that new legitimate applications are not mistakenly flagged as threats.
+- Users should also consider the context of the network environment, such as known trusted devices or users, to further refine the detection criteria and reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Verify the credentials used in the SMB mounting attempt and reset passwords for any compromised accounts.
+- Conduct a thorough investigation of the system to identify any additional unauthorized access or malicious activity, focusing on lateral movement patterns.
+- Review and analyze logs from the affected system and network devices to trace the source and scope of the intrusion.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed information on SMB-related activities and other remote service interactions.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Restore the system to its operational state by removing any malicious software, applying security patches, and verifying system integrity.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as disabling unnecessary SMB services, enforcing strong password policies, and using multi-factor authentication to reduce the risk of future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
index c312d9699ad..ba79256083c 100644
--- a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
+++ b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,49 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.args:("-setremotelogin" and on) and
  not process.parent.executable : /usr/local/jamf/bin/jamf
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Remote SSH Login Enabled via systemsetup Command
+
+The `systemsetup` command in macOS is a utility that allows administrators to configure system settings, including enabling remote SSH login. While useful for legitimate remote management, adversaries can exploit this to gain unauthorized access. The detection rule identifies suspicious use of `systemsetup` to enable SSH, excluding known legitimate processes, thus highlighting potential lateral movement attempts by attackers.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `systemsetup` command with arguments `-setremotelogin on` and verify the process name as `systemsetup`.
+- Check the parent process of the `systemsetup` command to ensure it is not `/usr/local/jamf/bin/jamf`, as this is a known legitimate process.
+- Identify the user account associated with the process execution to determine if it is a known administrator or a potentially compromised account.
+- Examine the timestamp of the event to correlate with any other suspicious activities or anomalies in the system logs around the same time.
+- Use Osquery to list all current SSH configurations and check if remote login is enabled with the following query: `SELECT * FROM plist WHERE path = '/etc/ssh/sshd_config' AND key = 'PermitRootLogin';`
+- Investigate the system's SSH access logs to identify any recent or unusual login attempts, especially around the time the `systemsetup` command was executed.
+- Cross-reference the host IP address with known assets to determine if the system is part of a critical network segment or if it has any history of security incidents.
+- Analyze any network traffic logs to identify potential lateral movement or data exfiltration attempts following the enabling of remote SSH login.
+- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
+- Review any other security alerts or incidents involving the same host or user account to assess if this event is part of a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives for the Remote SSH Login Enabled via systemsetup Command rule often arise from legitimate administrative tools and scripts that manage macOS systems, such as configuration management software or custom scripts used by IT departments.
+- One common source of false positives is the use of the `systemsetup` command by authorized IT personnel or automated scripts to enable SSH for legitimate remote management tasks.
+- To manage these false positives, users can create exceptions for specific parent processes or scripts that are known to perform legitimate SSH enabling actions. This can be done by adding these processes to the exclusion list in the detection rule.
+- Another method to handle false positives is to monitor the frequency and context of the `systemsetup` command usage. If a particular process or script frequently triggers the rule but is verified as non-threatening, it can be safely excluded.
+- It's important to regularly review and update the list of exceptions to ensure that new legitimate processes are accounted for while maintaining the integrity of the detection rule against potential threats.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the process by checking the user account that executed the `systemsetup` command and cross-reference with known administrative activities.
+- Review system logs and security alerts to identify any other suspicious activities or unauthorized access attempts around the time the SSH was enabled.
+- If unauthorized access is confirmed, reset credentials for affected accounts and any other accounts that may have been compromised.
+- Disable remote SSH login if it was enabled without authorization and ensure that only authorized users can enable it in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future unauthorized changes are detected promptly.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying any necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
+- Harden the system by enforcing strong authentication mechanisms, such as multi-factor authentication, and regularly auditing user permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_vpn_connection_attempt.toml b/rules/macos/lateral_movement_vpn_connection_attempt.toml
index 6388074a40d..74ebc8983d5 100644
--- a/rules/macos/lateral_movement_vpn_connection_attempt.toml
+++ b/rules/macos/lateral_movement_vpn_connection_attempt.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,48 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
     (process.name : "osascript" and process.command_line : "osascript*set VPN to service*")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Virtual Private Network Connection Attempt
+
+Virtual Private Networks (VPNs) are crucial for secure remote access, encrypting data between a user and the network. However, adversaries can exploit VPNs to move laterally within a network, gaining unauthorized access to remote systems. The detection rule identifies suspicious VPN connection attempts on macOS by monitoring specific command executions, helping to flag potential misuse by adversaries.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments that triggered the rule, focusing on `process.name` and `process.args` fields.
+- Check the `process.command_line` field for any unusual or unexpected command executions that might indicate malicious intent.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the timestamp of the event to correlate with any other suspicious activities or alerts that occurred around the same time.
+- Use Osquery to list all active VPN connections on the system with a query like: `SELECT * FROM vpn_connections;` to identify any unauthorized or unexpected connections.
+- Cross-reference the IP addresses associated with the VPN connections against known malicious IP databases or threat intelligence feeds.
+- Analyze the parent process of the suspicious VPN connection attempt to understand how the process was initiated and if it was part of a larger attack chain.
+- Review system logs for any failed VPN connection attempts that might indicate brute force or unauthorized access attempts.
+- Investigate any recent changes to VPN configurations or settings on the system that could have been altered to facilitate unauthorized access.
+- Check for any other alerts or indicators of compromise on the same host that might suggest a broader compromise or lateral movement attempt.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate network administrators may frequently use macOS built-in commands like `networksetup`, `scutil`, or `osascript` to manage VPN connections as part of their regular duties. These actions, while flagged by the detection rule, are not necessarily malicious.
+- Automated scripts: Organizations may deploy scripts that automate VPN connections for users, especially in environments where remote work is common. These scripts can trigger the detection rule but are typically benign.
+- User-initiated connections: Employees might manually connect to VPNs using the same commands for legitimate purposes, such as accessing company resources remotely, which can result in false positives.
+- To manage these false positives, users can create exceptions for known, non-threatening behaviors by whitelisting specific processes or command patterns that are verified as safe. This can be done by maintaining a list of trusted scripts or administrative actions and excluding them from triggering alerts. Regularly reviewing and updating this list ensures that only genuine threats are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further lateral movement by the adversary.
+- Review the VPN connection logs and process execution details to identify unauthorized access attempts and determine the scope of the intrusion.
+- Terminate any suspicious VPN sessions and change credentials associated with the compromised VPN accounts to prevent further unauthorized access.
+- Conduct a thorough investigation to identify any additional compromised systems or accounts within the network, leveraging MITRE ATT&CK framework for guidance on potential lateral movement techniques.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed VPN connection attempts and process execution data for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the affected system to its operational state by reimaging the device and applying the latest security patches and updates.
+- Conduct a security review to identify and address any vulnerabilities or misconfigurations that may have facilitated the attack, such as weak VPN configurations or insufficient access controls.
+- Educate users on secure VPN usage practices and the importance of reporting suspicious activities to help prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_account_creation_hide_at_logon.toml b/rules/macos/persistence_account_creation_hide_at_logon.toml
index 88551bdc5f7..b7265c05198 100644
--- a/rules/macos/persistence_account_creation_hide_at_logon.toml
+++ b/rules/macos/persistence_account_creation_hide_at_logon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,48 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:dscl and process.args:(IsHidden and create and (true or 1 or yes))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Hidden Local User Account Creation
+
+In macOS environments, the `dscl` command-line utility is used for directory service management, including user account creation. Adversaries may exploit this to create hidden accounts, evading detection and maintaining persistence. The detection rule identifies suspicious `dscl` usage patterns, such as attempts to set accounts as hidden, signaling potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `dscl` command with arguments indicating account creation and hidden status (`IsHidden`, `create`, `true`, `1`, or `yes`).
+- Cross-reference the timestamp of the alert with other logs to identify any correlated activities or anomalies around the same time.
+- Use Osquery to list all user accounts and check for any discrepancies or unexpected hidden accounts with the query: `SELECT * FROM users WHERE uid >= 500 AND NOT hidden = 0;`.
+- Investigate the parent process of the `dscl` command to determine if it was executed by a legitimate user or process.
+- Check for any recent changes in user permissions or group memberships that might indicate privilege escalation.
+- Analyze the command history of the user who executed the `dscl` command to identify any other suspicious activities.
+- Review system logs for any failed login attempts or unusual login patterns that might suggest unauthorized access attempts.
+- Examine network logs for any outbound connections from the host that could indicate data exfiltration or communication with a command and control server.
+- Verify the integrity of critical system files and configurations to ensure they have not been tampered with.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar tactics.
+
+### False positive analysis
+
+- System administrators or IT personnel may use the `dscl` command to create hidden accounts for legitimate purposes, such as managing system processes or services that require a separate account. These actions can trigger the detection rule but are not malicious.
+- Some applications or scripts may automate the creation of hidden accounts for functionality or security reasons, such as sandboxing or running background tasks. These automated processes can be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for known and trusted processes or accounts by whitelisting specific `dscl` command patterns or arguments that are regularly used in their environment.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, and monitor for any changes in behavior that might indicate a new threat.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
+- Review the process execution logs to confirm the creation of a hidden user account using the `dscl` command with suspicious arguments.
+- Identify and document the hidden user account details, including username and UID, for further investigation.
+- Remove the unauthorized hidden user account using the `dscl` command to prevent further unauthorized access.
+- Conduct a thorough review of system logs and user activity to identify any additional unauthorized changes or suspicious behavior.
+- Escalate the incident to the security operations team for further analysis and to determine if other systems may be affected.
+- Implement enhanced logging policies to capture detailed process execution and user account changes for future investigations.
+- Integrate with a centralized security information and event management (SIEM) system to correlate events and improve detection capabilities.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, ensuring no backdoors or persistence mechanisms remain.
+- Apply hardening measures such as disabling unnecessary services, enforcing strong password policies, and regularly auditing user accounts to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_change_launch_agents_file.toml b/rules/macos/persistence_creation_change_launch_agents_file.toml
index 043c9618c04..3e0b1abea92 100644
--- a/rules/macos/persistence_creation_change_launch_agents_file.toml
+++ b/rules/macos/persistence_creation_change_launch_agents_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,49 @@ sequence by host.id with maxspan=1m
  ]
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Launch Agent Creation or Modification and Immediate Loading
+
+Launch Agents in macOS are used to run scripts or applications automatically at user login, providing a mechanism for persistence. Adversaries exploit this by creating or modifying Launch Agents to execute malicious code. The detection rule identifies such abuse by monitoring for new or altered Launch Agent files and their immediate loading via `launchctl`, indicating potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path of the Launch Agent that was created or modified, focusing on paths like `/System/Library/LaunchAgents/*`, `/Library/LaunchAgents/*`, and `/Users/*/Library/LaunchAgents/*`.
+- Check the timestamp of the file creation or modification event to correlate it with any known user activity or scheduled tasks.
+- Investigate the user account associated with the creation or modification of the Launch Agent to determine if the activity aligns with expected behavior.
+- Examine the contents of the Launch Agent plist file to identify any suspicious or unexpected scripts or executables being launched.
+- Use Osquery to list all Launch Agents on the system and compare them against known good configurations. Example query: `SELECT * FROM launchd WHERE path LIKE '/Users/%/Library/LaunchAgents/%';`
+- Analyze the process execution details of `launchctl` to verify the arguments used and ensure they match legitimate use cases.
+- Cross-reference the process start time of `launchctl` with the file modification time to confirm immediate loading, which may indicate malicious intent.
+- Investigate any network connections or external communications initiated by the processes or scripts specified in the Launch Agent.
+- Review system logs around the time of the event for any additional indicators of compromise or related suspicious activity.
+- Check for any other recent alerts or anomalies on the host that might suggest a broader compromise or coordinated attack.
+
+### False positive analysis
+
+- Routine software updates or legitimate application installations may create or modify Launch Agents, triggering the detection rule. Users can manage these by maintaining a list of trusted applications and their expected behaviors.
+- System maintenance tools or user-installed utilities that automate tasks at login might also create or modify Launch Agents. Users should verify the legitimacy of these tools and consider excluding them from monitoring if they are deemed safe.
+- Developers or power users who frequently create or modify Launch Agents for testing or automation purposes may inadvertently trigger the rule. These users can be excluded from monitoring by creating exceptions based on user accounts or specific directories.
+- Some enterprise management tools may deploy configuration profiles that include Launch Agents, which could be mistaken for malicious activity. Organizations should document and whitelist these tools to prevent false positives.
+- Users can implement a baseline of known good Launch Agents and compare new or modified entries against this baseline to identify legitimate changes, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
+- Investigate the newly created or modified Launch Agent file to determine its origin and purpose, checking for any known malicious signatures or unusual behavior.
+- Use endpoint detection and response (EDR) tools to analyze the process tree and identify any additional malicious processes or files associated with the Launch Agent.
+- Remove the unauthorized Launch Agent file and any associated malicious files or processes from the system.
+- Review user accounts and permissions to ensure no unauthorized changes have been made, and reset passwords if necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed information on file creation, modification, and process execution, focusing on Launch Agents and launchctl activities.
+- Integrate threat intelligence feeds to correlate the detected activity with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, and applying any necessary security patches or updates.
+- Harden the system by restricting write access to Launch Agent directories, implementing application whitelisting, and educating users on recognizing phishing attempts and other common attack vectors."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_hidden_login_item_osascript.toml b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
index 1b48ca3d708..4d4424be0aa 100644
--- a/rules/macos/persistence_creation_hidden_login_item_osascript.toml
+++ b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,48 @@ query = '''
 process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : "osascript" and
  process.command_line : "osascript*login item*hidden:true*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation of Hidden Login Item via Apple Script
+
+AppleScript is a scripting language used to automate tasks on macOS. Adversaries may exploit it to create hidden login items, ensuring malicious programs start automatically while remaining concealed. The detection rule identifies such abuse by monitoring the execution of AppleScript commands that create hidden login items, focusing on specific command patterns indicative of this stealthy persistence technique.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `osascript` process execution with the command line pattern `osascript*login item*hidden:true*`.
+- Verify the timestamp of the event to understand when the suspicious activity occurred.
+- Identify the user account under which the `osascript` process was executed to determine if it aligns with expected user behavior.
+- Check the parent process of `osascript` to identify how the script was initiated and if it was triggered by another suspicious process.
+- Use Osquery to list all login items for the affected user to identify any hidden items. Example query: `SELECT * FROM login_items WHERE hidden = 1;`
+- Investigate the script content if accessible, to understand its purpose and any potential malicious actions it might perform.
+- Correlate the event with other logs, such as system logs or application logs, to gather additional context around the time of execution.
+- Examine recent file modifications in common script directories (e.g., `/Library/Scripts`, `~/Library/Scripts`) to identify any unauthorized changes.
+- Check for any recent changes in user permissions or system settings that could facilitate the execution of unauthorized scripts.
+- Review network activity logs around the time of the event to detect any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
+
+### False positive analysis
+
+- Legitimate applications or scripts that use AppleScript to automate tasks may inadvertently trigger this detection rule if they create login items with hidden attributes. For example, productivity tools or system management scripts that use hidden login items for legitimate purposes could be flagged.
+- Users can manage these false positives by creating exceptions for known and trusted applications or scripts. This can be done by identifying the specific command patterns or process names associated with these legitimate activities and excluding them from the detection rule.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule against actual threats.
+- Consider implementing additional context checks, such as verifying the source or signature of the script, to differentiate between benign and potentially malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further spread or communication with potential command and control servers.
+- Investigate the process tree and command line arguments of the osascript execution to identify any associated malicious scripts or payloads.
+- Terminate any suspicious processes that were initiated by the osascript command to halt any ongoing malicious activity.
+- Review and remove any unauthorized login items or startup scripts to eliminate persistence mechanisms.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and command line arguments for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured.
+- Apply security hardening measures such as disabling unnecessary scripting capabilities and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
index 0c3009d0cc4..6ba07078f04 100644
--- a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
+++ b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,49 @@ sequence by host.id with maxspan=1m
  [file where host.os.type == "macos" and event.type != "deletion" and file.path : ("/System/Library/LaunchDaemons/*", "/Library/LaunchDaemons/*")]
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 LaunchDaemon Creation or Modification and Immediate Loading
+
+LaunchDaemons in macOS are system-level services that start at boot and run in the background, often used for legitimate system tasks. Adversaries exploit this by creating or altering LaunchDaemons to ensure malicious payloads persistently execute. The detection rule identifies such abuse by monitoring for new or modified LaunchDaemons followed by their immediate loading, signaling potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `host.id` and `file.path` involved in the LaunchDaemon creation or modification event.
+- Verify the legitimacy of the LaunchDaemon by checking the `file.path` against known system and third-party LaunchDaemons. Look for any unusual or unexpected entries.
+- Use Osquery to list all LaunchDaemons on the affected host and compare them with the baseline of known good configurations. Example query: `SELECT * FROM launchd WHERE path LIKE '/Library/LaunchDaemons/%' OR path LIKE '/System/Library/LaunchDaemons/%';`
+- Investigate the `process.name` and `process.args` fields to confirm the use of `launchctl` for loading the LaunchDaemon. Check for any anomalies in the arguments used.
+- Examine the `process.parent` and `process.executable` fields to determine the parent process that initiated the `launchctl` command, which may provide insight into how the LaunchDaemon was loaded.
+- Check the file metadata, such as creation and modification timestamps, to identify any discrepancies or unusual patterns that could indicate tampering.
+- Review recent system logs and security logs on the affected host for any related events or errors that coincide with the LaunchDaemon creation or modification.
+- Investigate the user account context under which the LaunchDaemon was created or modified to determine if it aligns with expected administrative activity.
+- Correlate the event with other alerts or suspicious activities on the same host to identify potential patterns or related incidents.
+- Consult threat intelligence sources to determine if the LaunchDaemon's name or characteristics match known malicious indicators or tactics.
+
+### False positive analysis
+
+- System updates or legitimate software installations may create or modify LaunchDaemons, triggering the detection rule. Users should verify if the changes coincide with known updates or installations.
+- Administrative tasks performed by IT personnel, such as configuring new services or updating existing ones, can also result in false positives. Users can manage these by maintaining a log of authorized changes and cross-referencing them with alerts.
+- Some third-party applications may use LaunchDaemons for legitimate background processes. Users can create exceptions for these applications by identifying their specific LaunchDaemon paths and excluding them from monitoring.
+- Regular maintenance scripts or system management tools might load LaunchDaemons as part of their operation. Users should document these tools and consider excluding their associated processes from the detection rule.
+- To handle frequent non-threatening behaviors, users can implement a whitelist of known safe LaunchDaemons and processes, ensuring that only unauthorized or unexpected changes trigger alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes to LaunchDaemons and correlating with other suspicious activities.
+- Review and analyze system logs, including file creation and modification times, to determine the timeline of the unauthorized LaunchDaemon creation or modification.
+- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) and ensure no other persistence mechanisms are in place.
+- Remove or disable the malicious LaunchDaemon by deleting the associated files and unloading them using the 'launchctl' command.
+- Restore the system to a known good state using backups or system snapshots, ensuring that all malicious changes are reverted.
+- Implement enhanced logging policies to capture detailed file and process activity, focusing on LaunchDaemon directories and 'launchctl' usage.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate alerts with known threat actor tactics.
+- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for further analysis and response.
+- Apply hardening measures such as restricting write access to LaunchDaemon directories, enforcing strict user permissions, and regularly auditing system configurations to prevent future persistence attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
index 86b2ab22a1b..09eec4330c9 100644
--- a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
+++ b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,50 @@ event.category:file and host.os.type:macos and not event.type:deletion and
   not (/Library/Security/SecurityAgentPlugins/KandjiPassport.bundle/* or /Library/Security/SecurityAgentPlugins/TeamViewerAuthPlugin.bundle/*)) and
   not (process.name:shove and process.code_signature.trusted:true)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Authorization Plugin Modification
+
+Authorization plugins in macOS extend the system's authentication capabilities, enabling features like third-party multi-factor authentication. Adversaries may exploit these plugins to maintain persistence or capture credentials by modifying or adding unauthorized plugins. The detection rule identifies suspicious modifications by monitoring changes in specific plugin directories, excluding known trusted plugins and processes, to flag potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process name involved in the modification, focusing on the `file.path` and `process.name` fields.
+- Verify the legitimacy of the modified or added plugin by checking the file path against known authorized plugins, ensuring it is not a false positive.
+- Use Osquery to list all plugins in the `/Library/Security/SecurityAgentPlugins/` directory to identify any unauthorized or suspicious plugins. Example query: `SELECT path, mode, uid, gid, size, atime, mtime, ctime FROM file WHERE directory = '/Library/Security/SecurityAgentPlugins/';`
+- Investigate the process that made the modification by examining the `process.name` and `process.code_signature.trusted` fields to determine if it is a trusted process.
+- Check the modification timestamps (`mtime` and `ctime`) of the suspicious plugin files to correlate with any known user activity or scheduled tasks.
+- Review system logs around the time of the modification for any unusual activity or errors that might provide additional context.
+- Cross-reference the involved process with known software installations or updates to determine if the modification was part of a legitimate update.
+- Investigate the user account associated with the modification to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Examine network logs for any unusual outbound connections from the host around the time of the modification, which might suggest data exfiltration or command and control activity.
+- Consult threat intelligence sources to check if the identified plugin or process is associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Known false positives may include legitimate software updates or installations that modify authorization plugins, such as updates to security software or new installations of trusted third-party authentication tools.
+- Users can handle these false positives by creating exceptions for known trusted plugins and processes, ensuring that updates from verified vendors are not flagged.
+- Regularly review and update the list of trusted plugins and processes to include new legitimate software that may be installed in the monitored directories.
+- Implement a process to verify the digital signatures of plugins and processes, allowing those with valid and trusted signatures to be excluded from alerts.
+- Consider the context of the detected changes, such as recent software installations or updates, to determine if the activity is expected and non-threatening.
+- Collaborate with IT and security teams to maintain an updated inventory of authorized plugins and processes, which can be used to refine detection rules and reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough investigation to identify any unauthorized plugins in the /Library/Security/SecurityAgentPlugins/ directory and verify their legitimacy.
+- Review system logs and security events to trace the origin of the unauthorized plugin modification and identify any associated suspicious activities or processes.
+- Remove any unauthorized or suspicious plugins and restore any modified legitimate plugins to their original state using trusted backups.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed file and process activities, focusing on the SecurityAgentPlugins directory and related processes.
+- Integrate with threat intelligence platforms to correlate the incident with known threat actor tactics, techniques, and procedures (TTPs) as per MITRE ATT&CK framework.
+- Apply security patches and updates to the macOS system to mitigate any known vulnerabilities that could be exploited by similar threats.
+- Educate users on recognizing phishing attempts and other social engineering tactics that could lead to unauthorized plugin installations.
+- Consider deploying additional security controls, such as application whitelisting and endpoint detection and response (EDR) solutions, to prevent future unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_crontab_creation.toml b/rules/macos/persistence_crontab_creation.toml
index b8396765b58..988dd6e5213 100644
--- a/rules/macos/persistence_crontab_creation.toml
+++ b/rules/macos/persistence_crontab_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,49 @@ query = '''
 file where host.os.type == "macos" and event.type != "deletion" and process.name != null and
   file.path : "/private/var/at/tabs/*" and not process.executable == "/usr/bin/crontab"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious CronTab Creation or Modification
+
+Cron jobs are scheduled tasks in Unix-like systems, including macOS, used for automating repetitive tasks. Adversaries may exploit cron to maintain persistence by creating or altering cron jobs using unconventional processes like Python scripts. The detection rule identifies such anomalies by flagging non-standard processes modifying cron files, which could indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and executable path that triggered the alert, focusing on the `process.name` and `process.executable` fields.
+- Verify the legitimacy of the process by checking the process's parent and child processes to understand its context and origin.
+- Use Osquery to list all cron jobs on the system and identify any recent changes. Example query: `SELECT * FROM crontab WHERE path LIKE '/private/var/at/tabs/%';`
+- Investigate the user account associated with the process to determine if it has a history of creating or modifying cron jobs.
+- Check the file modification timestamps in `/private/var/at/tabs/` to correlate with the alert time and identify any unauthorized changes.
+- Examine system logs around the time of the alert for any additional suspicious activity or related events.
+- Investigate the network activity of the process to identify any external connections that might indicate command and control communication.
+- Review the process's binary or script for any signs of tampering or malicious code, especially if it is a non-standard executable for cron modifications.
+- Cross-reference the process and file path with threat intelligence sources to identify any known malicious indicators.
+- Assess the system for other signs of compromise, such as unauthorized user accounts or unusual system behavior, to determine if the cron modification is part of a larger attack.
+
+### False positive analysis
+
+- System administrators or legitimate software may use scripts or automation tools to manage cron jobs, leading to false positives when these processes modify cron files. 
+- Development environments or testing scenarios might involve the use of scripts to automate task scheduling, which could trigger the rule.
+- Users can handle these false positives by creating exceptions for known and trusted processes that regularly modify cron files, such as specific automation scripts or administrative tools.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening processes are excluded from detection.
+- Consider the context of the environment, such as development or production, to better assess whether a detected modification is likely to be benign.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Investigate the process that modified the crontab by reviewing process execution details, including the parent process, command-line arguments, and user context.
+- Check for other signs of compromise on the system, such as unusual network connections, unexpected user accounts, or additional unauthorized scheduled tasks.
+- Remove or disable the suspicious cron job and any other unauthorized persistence mechanisms identified during the investigation.
+- Restore the crontab to its original state using backups or by manually recreating legitimate scheduled tasks.
+- Escalate the incident to the security operations team if the investigation reveals evidence of a broader compromise or if the threat actor's identity or intent is unclear.
+- Implement enhanced logging and monitoring for cron job modifications and process execution to detect similar activities in the future.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and contextualize alerts with known threat actor behaviors.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
+- Apply system hardening measures, such as restricting cron job creation to authorized users and processes, and regularly review and audit scheduled tasks for anomalies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
index 66941650995..803ba06956f 100644
--- a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
+++ b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,55 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:.* and process.parent.executable:/sbin/launchd
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Hidden Child Process of Launchd
+
+Launchd is a key macOS system process responsible for managing system and user services. Adversaries may exploit it to gain persistence by creating hidden processes that execute at login. The detection rule identifies such hidden child processes initiated by launchd, focusing on process start events and their parent executable paths, thus highlighting potential unauthorized modifications to system processes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a hidden child process initiated by launchd, focusing on the `process.name` and `process.parent.executable` fields.
+- Verify the legitimacy of the child process by checking its file path and hash against known good files and threat intelligence databases.
+- Use Osquery to list all current processes and their parent processes to identify any other suspicious child processes of launchd:
+  ```sql
+  SELECT pid, name, path, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE path = '/sbin/launchd');
+  ```
+- Investigate the file attributes of the suspicious process using Osquery to check for hidden or unusual file properties:
+  ```sql
+  SELECT * FROM file WHERE path = '<path_to_suspicious_process>';
+  ```
+- Examine the creation and modification timestamps of the suspicious process file to determine if it aligns with known legitimate updates or installations.
+- Check the system logs for any unusual activity or errors around the time the suspicious process was started, focusing on `event.category:process` and `event.type:start`.
+- Investigate the user account context under which the suspicious process was executed to determine if it aligns with expected user behavior.
+- Review recent changes to launch agents and daemons by listing files in `/Library/LaunchAgents`, `/Library/LaunchDaemons`, and `~/Library/LaunchAgents` for any unauthorized modifications.
+- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack campaign.
+
+### False positive analysis
+
+- Some legitimate applications may create hidden child processes of launchd as part of their normal operation, such as system utilities or software updates. These processes might be flagged as suspicious but are benign.
+- Developers and advanced users might run scripts or applications that intentionally create hidden processes for testing or automation purposes, which could trigger the detection rule.
+- Security software or system management tools may also generate hidden processes to perform background tasks, leading to false positives.
+- To manage these false positives, users can create exceptions for known and trusted applications by specifying their process names or paths in the detection rule.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the integrity of the detection system.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Use endpoint detection and response (EDR) tools to perform a detailed analysis of the suspicious process and its parent-child relationship to confirm malicious activity.
+- Terminate the hidden child process and any other suspicious processes spawned by launchd to stop potential malicious actions.
+- Review and remove any unauthorized launch agents, daemons, or logon items that may have been installed to ensure persistence.
+- Conduct a thorough audit of user accounts and permissions to identify any unauthorized changes or accounts that may have been created by the adversary.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation.
+- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships, to improve future detection capabilities.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to enhance detection and response strategies.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Apply system hardening measures, such as disabling unnecessary services, enforcing strong authentication mechanisms, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_directory_services_plugins_modification.toml b/rules/macos/persistence_directory_services_plugins_modification.toml
index 6212dfc742d..18b4f5d9ab8 100644
--- a/rules/macos/persistence_directory_services_plugins_modification.toml
+++ b/rules/macos/persistence_directory_services_plugins_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:deletion and
   file.path:/Library/DirectoryServices/PlugIns/*.dsplug
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via DirectoryService Plugin Modification
+
+DirectoryService PlugIns on macOS are integral for managing directory-based services, automatically executing on boot. Adversaries exploit this by modifying or creating malicious plugins to ensure their code runs persistently. The detection rule monitors for non-deletion events involving dsplug files in the PlugIns directory, flagging potential unauthorized changes indicative of persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.category is 'file' and host.os.type is 'macos', ensuring the alert is relevant to the DirectoryService Plugin Modification.
+- Verify the file path in the alert matches the pattern /Library/DirectoryServices/PlugIns/*.dsplug to confirm the location of the suspicious file.
+- Check the timestamp of the event to determine when the modification or creation occurred, which can help correlate with other system activities.
+- Investigate the file metadata, such as the file size, creation date, and modification date, to identify any anomalies or recent changes.
+- Use Osquery to list all files in the /Library/DirectoryServices/PlugIns/ directory and gather additional details. Example query: `SELECT path, size, atime, mtime, ctime FROM file WHERE directory = '/Library/DirectoryServices/PlugIns/' AND path LIKE '%.dsplug';`
+- Examine the file's contents or hash to determine if it matches known malicious signatures or if it has been altered from a known good state.
+- Review system logs around the time of the event for any unusual activities or errors that might indicate tampering or unauthorized access.
+- Check for any recent user logins or privilege escalations that could be related to the modification of the DirectoryService Plugin.
+- Investigate any other alerts or events from the same host around the same time to identify potential patterns or related activities.
+- Consult threat intelligence sources to see if the file or its characteristics match any known threats or indicators of compromise.
+
+### False positive analysis
+
+- Routine system updates or legitimate software installations may trigger the rule by creating or modifying dsplug files, as these processes often involve updating or adding new plugins to the DirectoryServices PlugIns folder.
+- Administrative actions by IT personnel, such as troubleshooting or configuring directory services, can also result in legitimate modifications to dsplug files, leading to false positives.
+- Users can manage these false positives by creating exceptions for known and trusted software update processes or specific administrative actions, ensuring that these are documented and reviewed regularly to maintain security integrity.
+- Implementing a whitelist of approved dsplug files or directories can help reduce noise from expected changes, allowing security teams to focus on truly suspicious activities.
+- Regularly reviewing and updating the list of exceptions is crucial to adapt to changes in software and system configurations, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough investigation to identify any unauthorized dsplug files in the /Library/DirectoryServices/PlugIns/ directory and verify their legitimacy.
+- Review system logs and security alerts to determine the timeline and method of the unauthorized modification or creation of the dsplug file.
+- Remove any unauthorized or malicious dsplug files and restore any legitimate files from a known good backup.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on the DirectoryServices PlugIns directory.
+- Integrate with endpoint detection and response (EDR) tools to monitor for similar persistence techniques and improve detection capabilities.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that the DirectoryService daemon is functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and update security policies to prevent future occurrences.
+- Implement hardening measures such as restricting write permissions to critical directories and employing application whitelisting to prevent unauthorized code execution."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_docker_shortcuts_plist_modification.toml b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
index 25ac05e33e9..db6ae252b5a 100644
--- a/rules/macos/persistence_docker_shortcuts_plist_modification.toml
+++ b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ event.category:file and host.os.type:macos and event.action:modification and
  not process.name:(xpcproxy or cfprefsd or plutil or jamf or PlistBuddy or InstallerRemotePluginService) and
  not process.executable:(/Library/Addigy/download-cache/* or "/Library/Kandji/Kandji Agent.app/Contents/MacOS/kandji-library-manager")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via Docker Shortcut Modification
+
+In macOS environments, the Dock is a user interface feature that provides quick access to applications. It relies on property list files to manage its configuration. Adversaries may exploit this by altering these files to redirect shortcuts to malicious applications, thus achieving persistence. The detection rule identifies unauthorized modifications to these property lists, excluding legitimate processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process name involved in the modification of the `com.apple.dock.plist` file.
+- Verify the legitimacy of the process that triggered the alert by checking its hash and comparing it against known malicious or benign hashes.
+- Use Osquery to list recent modifications to the `com.apple.dock.plist` file with a query like: `SELECT * FROM file WHERE path = '/Users/*/Library/Preferences/com.apple.dock.plist' ORDER BY atime DESC LIMIT 5;` to gather context on recent changes.
+- Investigate the user account associated with the modification by checking the file path for the specific user directory and correlating it with recent login activities.
+- Examine the process tree to understand the parent process and any child processes spawned by the suspicious process to identify potential lateral movement or further persistence mechanisms.
+- Check system logs for any unusual activity around the time of the modification, focusing on `event.category:file` and `event.action:modification` to correlate with other suspicious events.
+- Investigate the network activity of the process involved in the modification to identify any suspicious outbound connections that could indicate data exfiltration or command and control communication.
+- Review the system's installed applications and recent installations to identify any unauthorized or suspicious software that could be related to the persistence mechanism.
+- Cross-reference the process executable path against known legitimate paths to ensure it is not masquerading as a legitimate application.
+- Consult threat intelligence sources to determine if the process name or executable path has been associated with known threats or campaigns, providing additional context for the investigation.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate applications or system processes that modify the Dock property list for valid reasons, such as user preference changes or application updates.
+- Common non-threatening processes that could trigger false positives include system utilities or management tools that adjust Dock settings as part of their normal operation.
+- Users can manage these false positives by creating exceptions for specific processes or executable paths that are known to be safe, ensuring they are excluded from triggering alerts.
+- Regularly review and update the list of excluded processes to adapt to changes in legitimate software behavior and minimize unnecessary alerts.
+- Consider monitoring the frequency and context of modifications to the Dock property list to distinguish between routine changes and potential threats, allowing for more informed decision-making regarding exclusions.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to confirm unauthorized modifications by reviewing the specific changes in the com.apple.dock.plist file.
+- Identify and terminate any malicious processes that may have been initiated as a result of the dock modification.
+- Restore the original com.apple.dock.plist file from a known good backup to ensure the Dock shortcuts are pointing to legitimate applications.
+- Review system logs and security alerts to identify any other signs of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has established other persistence mechanisms.
+- Implement enhanced logging policies to capture detailed file modification events and process execution details for future investigations.
+- Integrate with endpoint detection and response (EDR) tools to improve visibility and automate detection of similar threats.
+- Educate users on recognizing suspicious activities and the importance of reporting unexpected behavior in their applications.
+- Apply security hardening measures such as restricting write permissions to critical configuration files and regularly updating macOS and installed applications to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_emond_rules_file_creation.toml b/rules/macos/persistence_emond_rules_file_creation.toml
index e6bbcdc0bd2..65c2a6cd650 100644
--- a/rules/macos/persistence_emond_rules_file_creation.toml
+++ b/rules/macos/persistence_emond_rules_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ query = '''
 file where host.os.type == "macos" and event.type != "deletion" and
  file.path : ("/private/etc/emond.d/rules/*.plist", "/etc/emon.d/rules/*.plist", "/private/var/db/emondClients/*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Emond Rules Creation or Modification
+
+The Event Monitor Daemon (emond) on macOS is a service that executes commands based on specific events, such as system startup or user login. Adversaries can exploit emond by creating or altering rules to trigger malicious actions during these events. The detection rule monitors for non-deletion events involving emond rule files, identifying potential unauthorized modifications that could indicate abuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path involved in the rule creation or modification, focusing on paths like "/private/etc/emond.d/rules/*.plist" and "/private/var/db/emondClients/*".
+- Check the timestamp of the event to determine when the rule was created or modified, which can help correlate with other system activities or user actions.
+- Identify the user account associated with the event to determine if the action was performed by an authorized user or potentially compromised account.
+- Use Osquery to list all current emond rules and their contents to understand what actions are being triggered. Example query: `SELECT * FROM file WHERE path LIKE '/private/etc/emond.d/rules/%.plist' OR path LIKE '/private/var/db/emondClients/%';`
+- Investigate the contents of the modified or newly created plist file to identify any suspicious commands or scripts that may be executed.
+- Cross-reference the event with system logs to identify any related activities, such as user logins, system startups, or other event triggers around the same time.
+- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized access to modify emond rules.
+- Look for other signs of compromise on the system, such as unusual network connections, unexpected processes, or other file modifications.
+- Review historical data to determine if similar emond rule modifications have occurred in the past, which could indicate a recurring pattern or persistent threat.
+- Consult threat intelligence sources to see if the identified modifications or commands match known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Routine system updates or legitimate software installations may modify emond rule files, leading to false positives. Users should verify if the changes coincide with known update schedules or software installations.
+- Administrative tasks performed by IT personnel, such as configuring new system policies or security settings, might also trigger alerts. Organizations can maintain a whitelist of authorized personnel and their expected activities to reduce unnecessary alerts.
+- Automated scripts or management tools used for system maintenance could inadvertently modify emond rules. Users should document and review these tools' activities to distinguish between legitimate and suspicious modifications.
+- To manage these false positives, users can create exceptions for known benign activities by specifying trusted file paths or processes in their monitoring tools, ensuring that only unexpected changes trigger alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough investigation to identify any unauthorized emond rule files by comparing them against a known-good baseline of emond rules.
+- Review system logs and emond logs to trace any suspicious activities or commands executed as a result of the modified or newly created rules.
+- Remove any unauthorized or malicious emond rule files and restore the original rules from a secure backup.
+- Scan the system for additional signs of compromise, such as unauthorized user accounts or unexpected network connections.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed information about file modifications and system events related to emond.
+- Integrate with a security information and event management (SIEM) system to correlate emond rule changes with other security events for comprehensive threat detection.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are hardened.
+- Educate users and administrators about the risks associated with emond rule modifications and provide training on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_emond_rules_process_execution.toml b/rules/macos/persistence_emond_rules_process_execution.toml
index ba4a84be2bd..d201e8574dd 100644
--- a/rules/macos/persistence_emond_rules_process_execution.toml
+++ b/rules/macos/persistence_emond_rules_process_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,48 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
    "base64",
    "launchctl")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Emond Child Process
+
+The Event Monitor Daemon (emond) on macOS is a service that executes predefined actions when specific system events occur. Adversaries exploit emond by crafting rules that trigger malicious processes during events like startup or login. The detection rule identifies unusual child processes spawned by emond, such as shells or scripting languages, which are indicative of potential abuse for persistence or unauthorized command execution.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and parent process name, ensuring they match the suspicious criteria outlined in the detection rule.
+- Check the timestamp of the event to determine when the suspicious child process was initiated and correlate it with any known user activities or scheduled tasks.
+- Investigate the command line arguments of the suspicious process to understand its intended actions and identify any potentially malicious commands or scripts.
+- Examine the user account associated with the process to determine if it aligns with expected user behavior or if it indicates potential compromise.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all child processes of emond: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'emond');`
+- Check system logs for any related events around the time of the alert, such as login attempts, system reboots, or other process executions that might provide context.
+- Investigate the origin of the emond rule that triggered the process execution by reviewing configuration files or system settings that define event actions.
+- Analyze network activity associated with the process to identify any suspicious outbound connections or data exfiltration attempts.
+- Cross-reference the process hash with threat intelligence databases to determine if it is associated with known malware or adversary techniques.
+- Review historical data to identify any previous occurrences of similar suspicious child processes spawned by emond, which could indicate a persistent threat.
+
+### False positive analysis
+
+- System administrators or legitimate software may use scripting languages or command-line tools for routine maintenance tasks, which could trigger the rule. For example, automated scripts executed during system startup or user login might be flagged as suspicious.
+- Developers and IT professionals often use shells and scripting languages for testing and development purposes, which could result in false positives if these activities are performed on systems monitored by the rule.
+- Users can manage false positives by creating exceptions for known, benign processes that are frequently executed by emond. This can be done by maintaining a whitelist of trusted scripts or applications that are expected to run as child processes of emond.
+- Regularly review and update the list of exceptions to ensure that only legitimate processes are excluded, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized emond rules by reviewing the configuration files located in /etc/emond.d/rules/.
+- Terminate any suspicious child processes spawned by emond to halt potential malicious activities.
+- Review system logs and security alerts to gather additional context on the suspicious activity and identify any other affected systems.
+- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a broader campaign.
+- Remove any unauthorized emond rules and restore legitimate configurations from a known good backup.
+- Implement enhanced logging policies to monitor emond activity and child processes, ensuring detailed logs are collected for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Apply security patches and updates to the macOS system to mitigate vulnerabilities that could be exploited by adversaries.
+- Educate users on recognizing and reporting suspicious activities, and consider implementing additional security measures such as application whitelisting and endpoint detection and response (EDR) solutions."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_enable_root_account.toml b/rules/macos/persistence_enable_root_account.toml
index 47a4bdcfee6..32b45bbca82 100644
--- a/rules/macos/persistence_enable_root_account.toml
+++ b/rules/macos/persistence_enable_root_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,48 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:dsenableroot and not process.args:"-d"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Enable the Root Account
+
+In macOS environments, the root account is typically disabled to enhance security. However, adversaries may attempt to enable it using the `dsenableroot` command to gain persistent, privileged access. The detection rule identifies such attempts by monitoring process events for the execution of this command without the disable flag, signaling potential misuse for unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `dsenableroot` command execution without the `-d` flag, as indicated by the query fields `process.name:dsenableroot` and `not process.args:"-d"`.
+- Check the `event.category:process` and `event.type:(start or process_started)` fields to verify the process initiation and gather the exact timestamp of the event.
+- Identify the user account associated with the process execution by examining the `user.name` field to determine if it aligns with expected administrative activity.
+- Investigate the parent process of `dsenableroot` using the `process.parent.name` field to understand the context in which the command was executed.
+- Use Osquery to list all recent processes executed by the user identified in the alert. Example query: `SELECT * FROM processes WHERE user = '<username>' ORDER BY start_time DESC LIMIT 10;`.
+- Examine the system logs around the time of the event for any additional suspicious activity or related events that might indicate a broader attack pattern.
+- Check for any recent changes to user accounts or permissions on the system that could suggest unauthorized access attempts.
+- Investigate network connections from the host around the time of the event to identify any potential exfiltration or command-and-control activity.
+- Review any recent software installations or updates on the host that could have introduced vulnerabilities or been used as a vector for the attack.
+- Correlate this event with other alerts or logs from the same host or user to identify patterns or repeated attempts to enable the root account.
+
+### False positive analysis
+
+- System administrators or IT personnel may legitimately enable the root account for maintenance or troubleshooting purposes, leading to false positives. To manage this, users can create exceptions for known administrator accounts or specific maintenance windows.
+- Automated scripts or management tools that require root access for legitimate tasks might trigger the detection rule. Users should identify these scripts and whitelist them by process hash or specific command-line arguments.
+- In educational or testing environments, enabling the root account might be part of a controlled exercise. Users can exclude these environments from monitoring or adjust the rule to account for specific IP ranges or hostnames.
+- Some third-party applications may require root access for installation or updates, potentially causing false positives. Users should verify the legitimacy of these applications and consider excluding their associated processes from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the `dsenableroot` command execution by checking user activity logs and correlating with authorized change requests.
+- If unauthorized, terminate any suspicious processes and sessions associated with the root account to contain potential threats.
+- Conduct a thorough investigation to identify any additional compromised accounts or systems, focusing on persistence mechanisms and unauthorized access patterns.
+- Reset passwords for all accounts with elevated privileges, including the root account, and enforce strong password policies.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that all critical events are monitored and retained for future investigations.
+- Integrate with security information and event management (SIEM) systems to automate alerting and correlation of suspicious activities related to account misuse.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files and configurations.
+- Harden the system by disabling the root account if not needed, and implement multi-factor authentication for all administrative access to reduce the risk of unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
index 0b84f1c374e..8f83dfb8538 100644
--- a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
+++ b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,52 @@ file where host.os.type == "macos" and event.type != "deletion" and
     "/Library/LaunchDaemons/.*.plist"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation of Hidden Launch Agent or Daemon
+
+Launch agents and daemons in macOS are background services that start at login or system boot, respectively. Adversaries exploit these to maintain persistence by creating hidden or unauthorized entries in system directories. The detection rule identifies suspicious creation events in key directories, flagging potential unauthorized persistence mechanisms by monitoring file creation activities in specific system paths.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path where the suspicious launch agent or daemon was created, focusing on the directories specified in the query.
+- Check the file creation timestamp to determine when the suspicious file was created and correlate this with any known user activity or system events.
+- Use Osquery to list all launch agents and daemons on the system to identify any other potentially unauthorized entries:
+  ```sql
+  SELECT * FROM launchd WHERE path LIKE '/Library/LaunchAgents/%' OR path LIKE '/Library/LaunchDaemons/%' OR path LIKE '/System/Library/LaunchAgents/%' OR path LIKE '/System/Library/LaunchDaemons/%' OR path LIKE '/Users/%/Library/LaunchAgents/%';
+  ```
+- Investigate the file owner and permissions of the suspicious file to determine if it was created by a legitimate user or process.
+- Examine the contents of the .plist file to understand what executable or script it is configured to run and assess its legitimacy.
+- Cross-reference the executable or script specified in the .plist file with known malicious signatures or behaviors.
+- Check system logs around the time of file creation for any unusual activity or errors that might provide additional context.
+- Investigate any network connections or external communications initiated by the system around the time of the file creation to identify potential command and control activity.
+- Review user accounts and recent logins on the system to identify any unauthorized access that might have led to the creation of the launch agent or daemon.
+- Consult threat intelligence sources to determine if the identified behavior or file matches any known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- System or application updates: During legitimate system or application updates, new launch agents or daemons may be created in the monitored directories. These updates are typically signed by trusted developers and can be verified through digital signatures.
+- User-installed applications: Some user-installed applications may create launch agents or daemons to provide background services or functionalities. Users should verify the legitimacy of these applications and consider excluding them if they are deemed safe.
+- Development tools: Developers may create launch agents or daemons as part of their development process. These can be excluded by identifying the developer's environment and ensuring it aligns with expected behavior.
+- Administrative scripts: IT administrators might deploy scripts that create or modify launch agents or daemons for system management purposes. These should be documented and excluded if they are part of routine administrative tasks.
+- To manage false positives, users can create exceptions for known and verified applications or processes by using digital signatures, file hashes, or specific file paths to exclude them from triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or persistence.
+- Investigate the creation event by reviewing the file path, timestamp, and associated user account to determine if the creation was authorized.
+- Check for other signs of compromise, such as unusual network activity or unauthorized user accounts, to assess the scope of the intrusion.
+- Remove the unauthorized launch agent or daemon by deleting the suspicious plist file and any associated scripts or binaries.
+- Restore the system to a known good state using backups or system restore points if available and necessary.
+- Update macOS and all installed applications to the latest versions to patch any known vulnerabilities.
+- Implement logging policies to monitor file creation and modification events in critical directories, ensuring logs are retained for an appropriate period.
+- Integrate security solutions such as endpoint detection and response (EDR) tools to enhance visibility and detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent future incidents.
+- Escalate the incident to the appropriate internal or external teams if the scope of the attack is beyond initial containment efforts, or if it involves sensitive data or critical systems."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
index 9d39f3a9d97..de1c824e1db 100644
--- a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
+++ b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,53 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                  "/Library/Application Support/Checkpoint/Endpoint Security/AMFinderExtensions.app/Contents/MacOS/AMFinderExtensions",
                                                  "/Applications/pCloud Drive.app/Contents/MacOS/pCloud Drive")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Finder Sync Plugin Registered and Enabled
+
+Finder Sync plugins enhance macOS Finder by allowing third-party applications to modify its interface, providing additional functionality. However, adversaries can exploit this by registering malicious plugins to maintain persistence on a system. The detection rule identifies suspicious plugin registrations by monitoring the `pluginkit` process for unusual arguments and excluding known legitimate plugins and parent processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific Finder Sync plugin registration triggered the alert, focusing on the `process.args` field to identify the suspicious plugin.
+- Verify the legitimacy of the plugin by researching the plugin identifier found in the `process.args` field against known legitimate plugins and any available threat intelligence sources.
+- Examine the `process.parent.executable` and `process.Ext.effective_parent.executable` fields to identify the parent process that initiated the plugin registration, checking for any unusual or unexpected parent processes.
+- Use Osquery to list all currently registered Finder Sync plugins on the system to identify any other potentially malicious plugins:
+  ```sql
+  SELECT * FROM plist WHERE path = '/Library/Preferences/com.apple.finder.plist' AND key = 'NSExtension' AND value LIKE '%FinderSync%';
+  ```
+- Investigate the system for any recent changes or installations that could have introduced the suspicious plugin, focusing on recent application installations or updates.
+- Check system logs for any other unusual activity around the time the plugin was registered, such as other process executions or network connections.
+- Review user activity on the system to determine if any user actions could have inadvertently led to the plugin registration, such as downloading and installing new software.
+- Investigate the file path and contents of the suspicious plugin to determine its purpose and whether it contains any malicious code or payloads.
+- Cross-reference the system's installed applications and extensions with known software inventory to identify any unauthorized or unexpected software.
+- Consult with other security tools or logs, such as endpoint detection and response (EDR) solutions, to gather additional context on the system's activity and any potential indicators of compromise.
+
+### False positive analysis
+
+- Known false positives for the Finder Sync Plugin Registered and Enabled rule include legitimate applications that register Finder Sync plugins for enhancing their functionality, such as cloud storage services and productivity tools.
+- Applications like Google Drive, Microsoft OneDrive, Adobe Creative Cloud, and Box are known to register Finder Sync plugins, which can trigger the detection rule if not properly excluded.
+- Users can manage these false positives by adding exceptions for known legitimate plugins and their parent processes in the detection rule, ensuring that these applications do not trigger alerts.
+- Regularly update the list of excluded plugins and parent processes to include any new legitimate applications that may register Finder Sync plugins, reducing unnecessary alerts.
+- Monitor updates from trusted software vendors for any changes in their plugin registration processes, which may require adjustments to the exclusion list.
+- Consider the context of the detected activity, such as the source and behavior of the parent process, to differentiate between benign and potentially malicious plugin registrations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Review the Finder Sync plugin registration logs to identify any unauthorized or suspicious plugins.
+- Terminate any suspicious processes related to the unauthorized Finder Sync plugins.
+- Remove any identified malicious Finder Sync plugins from the system.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
+- Restore any affected system files from a known good backup to ensure system integrity.
+- Implement logging policies to monitor pluginkit process activities and other critical system processes for future detection of similar threats.
+- Integrate security solutions with SIEM tools to enhance real-time monitoring and alerting capabilities.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Apply system hardening measures, such as restricting Finder Sync plugin installations to trusted applications only, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_folder_action_scripts_runtime.toml b/rules/macos/persistence_folder_action_scripts_runtime.toml
index 18b114cfaf4..1e79a7bf7c7 100644
--- a/rules/macos/persistence_folder_action_scripts_runtime.toml
+++ b/rules/macos/persistence_folder_action_scripts_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,49 @@ query = '''
 process where host.os.type == "macos" and event.type : "start" and process.name in ("osascript", "python", "tcl", "node", "perl", "ruby", "php", "bash", "csh", "zsh", "sh") and
   process.parent.name == "com.apple.foundation.UserScriptService" and not process.args : ("/Users/*/Library/Application Support/iTerm2/Scripts/AutoLaunch/*.scpt", "/Users/*/Library/Application Scripts/com.microsoft.*/FoxitUtils.applescript")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via Folder Action Script
+
+Folder Action scripts on macOS automate tasks when folder contents change. Adversaries exploit this by attaching malicious scripts to folders, ensuring execution upon folder events, thus achieving persistence. The detection rule identifies suspicious script executions by monitoring specific processes initiated by the UserScriptService, excluding known benign scripts, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the detection, focusing on the `process.name` and `process.args` fields.
+- Verify the parent process by examining the `process.parent.name` field to confirm it is `com.apple.foundation.UserScriptService`, which indicates a Folder Action script execution.
+- Check the user account associated with the process to determine if it aligns with expected user behavior or if it appears suspicious.
+- Investigate the script path and content by accessing the folder specified in the `process.args` to identify any unauthorized or malicious modifications.
+- Use Osquery to list all Folder Action scripts currently configured on the system with the following query: `SELECT * FROM file WHERE path LIKE '/Users/%/Library/Scripts/Folder Action Scripts/%';`
+- Cross-reference the detected script with known benign scripts to ensure it is not mistakenly flagged, using the exclusion paths provided in the detection rule.
+- Analyze recent changes to the folder associated with the script to identify any unusual activity or unauthorized access.
+- Review system logs for any additional context or related events around the time of the alert to identify potential patterns or repeated attempts.
+- Check for any other processes or network connections initiated by the suspicious script to assess further malicious activity.
+- Consult threat intelligence sources to determine if the script or its behavior matches known malicious patterns or campaigns.
+
+### False positive analysis
+
+- Known false positives for the Persistence via Folder Action Script rule include legitimate automation scripts that users have intentionally attached to folders for productivity purposes, such as scripts for organizing files or triggering backups.
+- Users may frequently encounter false positives from development environments where scripts are executed as part of the software development process, especially if using scripting languages like Python, Ruby, or Node.js.
+- To manage these false positives, users can create exceptions for specific scripts or folders by modifying the detection rule to exclude known benign scripts or directories, similar to the existing exclusions for iTerm2 and Microsoft-related scripts.
+- Users should regularly review and update their exclusion list to ensure that only trusted scripts are excluded, maintaining a balance between reducing false positives and ensuring security.
+- It is advisable to document any exclusions made for auditing purposes and to reassess them periodically to confirm they remain non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Investigate the specific Folder Action script that triggered the alert to determine if it is indeed malicious by analyzing its contents and behavior.
+- Review recent changes to the folder and associated scripts to identify unauthorized modifications or additions.
+- Remove or disable the malicious script from the Folder Action configuration to prevent further execution.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Restore any modified or deleted legitimate scripts from a known good backup to ensure system functionality.
+- Escalate the incident to the security operations team if the script is part of a broader attack campaign or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed script execution events and folder modifications for future investigations.
+- Integrate with a centralized security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
+- Apply hardening measures such as restricting script execution permissions, disabling unnecessary scripting languages, and educating users on the risks of unauthorized script usage."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_login_logout_hooks_defaults.toml b/rules/macos/persistence_login_logout_hooks_defaults.toml
index b0ef9cdda7d..7f1b0604854 100644
--- a/rules/macos/persistence_login_logout_hooks_defaults.toml
+++ b/rules/macos/persistence_login_logout_hooks_defaults.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,49 @@ process where host.os.type == "macos" and event.type == "start" and
          "/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh"
        )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via Login or Logout Hook
+
+In macOS environments, login and logout hooks are scripts that execute automatically during user login or logout, respectively. Adversaries exploit this by inserting malicious scripts to maintain persistence. The detection rule identifies suspicious use of the 'defaults' command to set these hooks, excluding known legitimate scripts, thus highlighting potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'defaults' command with 'write' arguments targeting 'LoginHook' or 'LogoutHook', ensuring it matches the query criteria.
+- Check the process execution context, including the user account under which the 'defaults' command was executed, to determine if it aligns with expected administrative activity.
+- Investigate the parent process of the 'defaults' command to understand how it was initiated and whether it was part of a legitimate workflow or a suspicious chain of processes.
+- Examine the command line arguments used with the 'defaults' command to identify the specific script or executable being set as a login or logout hook.
+- Cross-reference the script paths against known legitimate scripts to verify if they are indeed unauthorized or potentially malicious.
+- Utilize Osquery to list all current login and logout hooks on the system with a query like: `SELECT * FROM preferences WHERE domain = 'com.apple.loginwindow' AND key IN ('LoginHook', 'LogoutHook');` to gather more context.
+- Analyze the content of the identified scripts or executables to determine their purpose and whether they contain any malicious or unexpected code.
+- Review system logs around the time of the 'defaults' command execution for any additional suspicious activity or related events that could provide further context.
+- Check for any recent changes to user accounts or permissions that might indicate an adversary's attempt to gain or maintain access.
+- Correlate this activity with other alerts or indicators of compromise within the environment to assess if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives for the Persistence via Login or Logout Hook rule primarily involve legitimate scripts used by system management tools like JAMF, which utilize login and logout hooks for administrative tasks.
+- Users can manage these false positives by creating exceptions for known legitimate scripts, such as those located in "/Library/Application Support/JAMF/ManagementFrameworkScripts/".
+- To handle frequent non-threatening behaviors, users should maintain an updated list of trusted scripts and directories that are commonly used in their environment, ensuring these are excluded from detection.
+- Regularly review and update the exclusion list to accommodate any changes in legitimate administrative scripts or tools, minimizing the risk of overlooking genuine threats while reducing false positives.
+- Collaborate with IT and security teams to identify and document any new legitimate scripts that may trigger the rule, ensuring they are promptly added to the exclusion list.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
+- Review the process execution logs to confirm the unauthorized use of the 'defaults' command and identify any associated scripts or payloads.
+- Terminate any suspicious processes that are linked to the unauthorized login or logout hooks to halt potential malicious actions.
+- Remove the unauthorized login or logout hooks by resetting them to their default state or replacing them with legitimate scripts if necessary.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Review user accounts and privileges on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to improve detection of similar threats.
+- Apply system hardening measures, such as disabling unused services and enforcing strong authentication mechanisms, to reduce the attack surface and prevent future persistence attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
index 4023d557e1d..8189274e07f 100644
--- a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
+++ b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,49 @@ file where host.os.type == "macos" and event.type in ("change", "creation") and
       "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper"
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Sublime Plugin or Application Script Modification
+
+Sublime Text, a popular text editor, supports plugins and scripts written in Python to enhance functionality. Adversaries may exploit this by altering or creating scripts to execute malicious code whenever Sublime is launched, achieving persistence. The detection rule identifies suspicious modifications to Python files in specific Sublime directories on macOS, excluding legitimate processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and event type (change or creation) that triggered the alert. Focus on the `file.path` and `event.type` fields for context.
+- Verify the legitimacy of the process that modified or created the Python file by checking the `process.executable` field against known benign executables.
+- Use Osquery to list all Python files in the specified Sublime directories to identify any unexpected or recently modified files. Example query: `SELECT path, mtime FROM file WHERE path LIKE '/Users/%/Library/Application Support/Sublime Text%/Packages/%.py' OR path = '/Applications/Sublime Text.app/Contents/MacOS/sublime.py';`
+- Check the modification timestamps of the identified files to correlate with the alert time and determine if the changes are recent and potentially suspicious.
+- Investigate the content of the modified or newly created Python files for any signs of obfuscation, unusual imports, or suspicious code that could indicate malicious intent.
+- Cross-reference the user account associated with the file modification to determine if the activity aligns with expected user behavior or if it could be indicative of compromised credentials.
+- Review system logs and other security alerts around the time of the file modification to identify any related suspicious activities or anomalies.
+- Check for any recent installations or updates of Sublime Text or its plugins that could explain the file changes as legitimate.
+- Investigate the network activity of the host around the time of the alert to identify any potential command and control communication or data exfiltration attempts.
+- Consult threat intelligence sources to determine if there are any known threats or campaigns targeting Sublime Text plugins or scripts that match the observed behavior.
+
+### False positive analysis
+
+- Frequent updates or installations of Sublime Text plugins by developers can trigger false positives, as these actions involve legitimate changes to Python files in the monitored directories.
+- Automated scripts or tools used by developers to manage Sublime Text configurations may also cause false positives by creating or modifying Python files as part of their normal operation.
+- Users can manage these false positives by creating exceptions for specific processes or paths known to be safe, such as trusted plugin management tools or scripts.
+- Excluding specific user accounts or directories that are known to frequently update or modify Sublime Text plugins can help reduce noise from legitimate activities.
+- Monitoring the frequency and context of file changes can help distinguish between normal development activities and potential threats, allowing for more informed decisions on exclusions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to identify any unauthorized modifications to Sublime Text plugins or scripts, focusing on the specified directories.
+- Review recent changes to the system, including new user accounts, scheduled tasks, or other persistence mechanisms that may have been established.
+- Restore any modified or malicious Python scripts to their original state using known good backups or reinstall the Sublime Text application if necessary.
+- Implement logging policies to capture detailed file modification events, especially in directories where Sublime Text plugins and scripts are stored.
+- Integrate security solutions with threat intelligence feeds to enhance detection capabilities for similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Review and update security policies to restrict unauthorized access to application directories and enforce the principle of least privilege.
+- Conduct a post-incident review to identify gaps in detection and response processes and implement improvements.
+- Educate users on the risks of downloading and installing unverified plugins or scripts to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
index fda11158c76..fcfb541e95b 100644
--- a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
+++ b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:"deletion" and
  file.path:(/private/etc/periodic/* or /private/etc/defaults/periodic.conf or /private/etc/periodic.conf)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Persistence via Periodic Tasks
+
+Periodic tasks in macOS are scheduled operations that automate system maintenance and other routine activities. Adversaries may exploit these tasks to execute unauthorized code or maintain persistence by altering task configurations. The detection rule identifies suspicious file events related to periodic task configurations, excluding deletions, to spot potential tampering indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path that triggered the alert, focusing on paths like `/private/etc/periodic/*`, `/private/etc/defaults/periodic.conf`, or `/private/etc/periodic.conf`.
+- Check the timestamp of the event to determine when the suspicious modification or creation occurred.
+- Investigate the user account associated with the event to determine if the activity aligns with expected behavior or if it might be indicative of unauthorized access.
+- Use Osquery to list all periodic tasks and their configurations to identify any unexpected or unauthorized entries. Example query: `SELECT * FROM file WHERE path LIKE '/private/etc/periodic/%' OR path = '/private/etc/defaults/periodic.conf' OR path = '/private/etc/periodic.conf';`
+- Examine the contents of the modified or newly created configuration files to identify any suspicious scripts or commands that could indicate malicious intent.
+- Cross-reference the event with other logs, such as authentication logs, to identify any unusual login activities around the time of the event.
+- Check for any recent changes in user privileges or group memberships that could have allowed unauthorized modifications to periodic task configurations.
+- Investigate any network connections or external communications initiated by the host around the time of the event to identify potential data exfiltration or command-and-control activity.
+- Review historical data to determine if similar modifications have occurred in the past, which could indicate a pattern of persistence attempts.
+- Consult threat intelligence sources to see if the identified modifications or scripts match known malicious activity or indicators of compromise.
+
+### False positive analysis
+
+- Routine system updates or legitimate software installations may modify periodic task configurations, leading to false positives. Users should verify if the changes coincide with known update schedules or software installations.
+- Administrative scripts or maintenance tools used by IT departments might alter periodic task settings as part of their normal operations. Users can create exceptions for these known scripts or tools to reduce noise.
+- Configuration management systems like Puppet or Chef may update periodic task configurations as part of their automated processes. Users should ensure these systems are accounted for in their monitoring rules.
+- Developers or system administrators might manually adjust periodic task settings for testing or optimization purposes. Users can maintain a whitelist of authorized personnel or processes that are allowed to make such changes.
+- Some third-party applications may legitimately modify periodic task configurations to schedule their own maintenance tasks. Users should review and approve these applications to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or execution of malicious code.
+- Conduct a thorough investigation of the modified or newly created periodic task configurations to identify any unauthorized changes or scripts.
+- Review system logs and use endpoint detection and response (EDR) tools to trace the origin of the changes and identify any associated malicious activity.
+- Restore the original periodic task configurations from a known good backup to ensure system integrity.
+- Scan the system for additional indicators of compromise (IOCs) and remove any detected malware or unauthorized files.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if assistance is needed.
+- Implement enhanced logging policies to capture detailed file modification events and periodic task executions for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
+- Apply security patches and updates to the macOS system to mitigate vulnerabilities that could be exploited by adversaries.
+- Harden the system by restricting access to configuration files, enforcing least privilege principles, and regularly auditing scheduled tasks for unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_suspicious_calendar_modification.toml b/rules/macos/persistence_suspicious_calendar_modification.toml
index d9e648f11f1..c0a5d0bd774 100644
--- a/rules/macos/persistence_suspicious_calendar_modification.toml
+++ b/rules/macos/persistence_suspicious_calendar_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,49 @@ event.category:file and host.os.type:macos and event.action:modification and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Calendar File Modification
+
+Calendar files on macOS can be manipulated to trigger events, potentially allowing adversaries to execute malicious programs at set intervals, thus maintaining persistence. By monitoring file modifications in calendar directories, especially by non-standard processes, the detection rule identifies unusual activity. It excludes legitimate system processes, focusing on unexpected executables, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific calendar file was modified and by which process, focusing on the `file.path` and `process.executable` fields.
+- Verify the legitimacy of the process executable by checking its location and signature. Use the `process.executable` field to determine if the process is expected or potentially malicious.
+- Cross-reference the process executable with known good applications and system processes to rule out false positives.
+- Use Osquery to list all processes that have recently interacted with calendar files. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/Users/%/Library/Calendars/%.calendar/Events/%.ics';`
+- Investigate the parent process of the suspicious executable to understand how it was launched. This can provide insights into whether it was user-initiated or automated.
+- Check the modification timestamps of the calendar file to determine if the timing aligns with any known user activity or scheduled tasks.
+- Review system logs around the time of the modification for any additional context or related events, such as user logins or other file modifications.
+- Examine the contents of the modified calendar file to identify any unusual or unexpected entries that could indicate malicious intent.
+- Investigate the user account associated with the modified calendar file to determine if there are any signs of compromise or unusual activity.
+- Correlate the event with other alerts or logs from the same host to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Known false positives may include legitimate third-party applications that interact with calendar files for synchronization or notification purposes, such as productivity tools or calendar management apps.
+- Users can handle these false positives by identifying and documenting the legitimate applications that modify calendar files regularly, then creating exceptions for these applications in the detection rule.
+- Another potential false positive source could be user-initiated scripts or automation tools that modify calendar events for personal scheduling needs. Users should verify the legitimacy of these scripts and exclude them if they are deemed non-threatening.
+- Regularly review and update the list of excluded processes to ensure that only trusted applications are allowed, minimizing the risk of overlooking a genuine threat.
+- Consider implementing a logging mechanism to track excluded processes, allowing for periodic audits and ensuring that no malicious activity is being inadvertently ignored.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the process responsible for the calendar file modification, using endpoint detection and response (EDR) tools to trace the process lineage and identify any associated malicious files or processes.
+- Terminate any suspicious processes identified during the investigation and remove any unauthorized calendar events or scripts that have been added to the system.
+- Restore any modified calendar files from a known good backup to ensure the integrity of the calendar data.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of a broader compromise or if the threat actor's identity and intent are unclear.
+- Implement enhanced logging policies to capture detailed process execution and file modification events, ensuring that future suspicious activities are detected promptly.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to improve detection capabilities for similar persistence techniques.
+- Apply security patches and updates to the macOS system and all installed applications to mitigate vulnerabilities that could be exploited by adversaries.
+- Educate users on the risks of calendar file modifications and the importance of reporting unusual system behavior to IT security personnel.
+- Review and update security policies and hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and improve overall system resilience."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_via_atom_init_file_modification.toml b/rules/macos/persistence_via_atom_init_file_modification.toml
index f281678818e..3939d5988e5 100644
--- a/rules/macos/persistence_via_atom_init_file_modification.toml
+++ b/rules/macos/persistence_via_atom_init_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:"deletion" and
  file.path:/Users/*/.atom/init.coffee and not process.name:(Atom or xpcproxy) and not user.name:root
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Persistence via Atom Init Script Modification
+
+Atom, a popular text editor, allows customization via the init.coffee script, which executes JavaScript upon startup. Adversaries exploit this by embedding malicious code, ensuring persistence each time Atom launches. The detection rule identifies suspicious modifications to this script on macOS, excluding legitimate processes and root user actions, to flag potential unauthorized changes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is `/Users/*/.atom/init.coffee` and verify the user account associated with the modification.
+- Check the process that made the modification by examining the `process.name` field to ensure it is not `Atom` or `xpcproxy`.
+- Verify the user account involved in the modification by reviewing the `user.name` field to ensure it is not `root`.
+- Use Osquery to list recent modifications to the `init.coffee` file with a query like: `SELECT * FROM file WHERE path = '/Users/*/.atom/init.coffee' ORDER BY atime DESC LIMIT 5;`.
+- Investigate the contents of the `init.coffee` file to identify any suspicious or unfamiliar JavaScript code.
+- Cross-reference the modification timestamp with user activity logs to determine if the modification aligns with legitimate user actions.
+- Check for any other suspicious file modifications or creations in the `.atom` directory that may indicate further persistence mechanisms.
+- Review system logs for any unusual activity or errors around the time of the modification to gather additional context.
+- Investigate the network activity of the user account and the host around the time of the modification for any signs of data exfiltration or command and control communication.
+- Correlate the findings with other security alerts or incidents involving the same user or host to identify potential patterns or related threats.
+
+### False positive analysis
+
+- Legitimate user customizations: Users often modify the init.coffee script to personalize their Atom experience, such as adding plugins or custom functions. These changes can trigger the detection rule. To manage this, users can create exceptions for known user accounts or specific script changes that are verified as safe.
+- Development and testing activities: Developers may frequently update the init.coffee file during testing or development of Atom packages. These activities can be excluded by setting exceptions for specific development environments or user accounts involved in these tasks.
+- Automated configuration management: Some organizations use automated tools to manage and update configuration files, including init.coffee. If these tools are known and trusted, their processes can be whitelisted to prevent false positives.
+- System updates or software installations: Occasionally, system updates or new software installations might modify the init.coffee file as part of their setup process. Users can monitor these events and exclude them if they are confirmed to be part of legitimate update or installation procedures.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized changes in the init.coffee file and determine the scope of the compromise.
+- Review recent modifications to the init.coffee file and cross-reference with known malicious JavaScript patterns or signatures.
+- Restore the init.coffee file from a known good backup if available, or manually remove any unauthorized code to ensure the system's integrity.
+- Scan the system for additional indicators of compromise, such as other modified configuration files or unexpected processes, to ensure no other persistence mechanisms are in place.
+- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if the malicious code is part of a known threat campaign.
+- Implement enhanced logging policies to capture detailed file modification events and process execution details for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar persistence techniques.
+- Educate users on the risks of unauthorized script modifications and encourage reporting of suspicious activity to prevent future incidents.
+- Apply security hardening measures, such as restricting write permissions to critical configuration files and using application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
index b47455ab7a1..8ab2b0dd0d3 100644
--- a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
+++ b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,47 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
   not process.Ext.effective_parent.executable : ("/Applications/Visual Studio Code.app/Contents/MacOS/Electron",
                                                  "/Applications/OpenVPN Connect/Uninstall OpenVPN Connect.app/Contents/MacOS/uninstaller")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Apple Scripting Execution with Administrator Privileges
+
+AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries may exploit it to execute scripts with elevated privileges, bypassing password prompts. The detection rule identifies such misuse by monitoring the execution of the Apple script interpreter, excluding benign parent processes like Electron, to flag unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `osascript` process execution with administrator privileges and without a password prompt.
+- Verify the `process.command_line` field to understand the exact command executed and assess if it aligns with known malicious patterns or scripts.
+- Check the `process.parent.name` field to identify the parent process of `osascript` and ensure it is not a benign process like Electron.
+- Investigate the `process.Ext.effective_parent.executable` field to confirm the parent executable is not a known safe application such as Visual Studio Code or OpenVPN Connect.
+- Use Osquery to list recent processes executed by the same user to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE user = (SELECT user FROM processes WHERE name = 'osascript' LIMIT 1);`
+- Examine system logs for any other unusual activities or errors around the time of the `osascript` execution to gather additional context.
+- Check for any recent changes in user accounts or permissions that could indicate unauthorized privilege escalation attempts.
+- Investigate network connections initiated by the system around the time of the alert to identify any potential data exfiltration or command and control activities.
+- Review the system's installed applications and scripts to identify any unauthorized or suspicious software that could have triggered the `osascript` execution.
+- Correlate the findings with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives for the Apple Scripting Execution with Administrator Privileges rule may include legitimate applications that use AppleScript for automation purposes without malicious intent. Applications like Visual Studio Code and OpenVPN Connect have been identified as benign processes that may trigger this rule due to their use of Electron as a parent process.
+- Users can manage these false positives by creating exceptions for specific applications that are known to use AppleScript legitimately. This can be done by excluding the parent processes or executables of these applications in the detection rule, as demonstrated with the exclusion of Electron and specific paths for Visual Studio Code and OpenVPN Connect.
+- It is important to regularly review and update the list of exceptions to ensure that only trusted applications are excluded, minimizing the risk of overlooking genuine threats while reducing noise from false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the osascript execution by checking user activity logs and correlating with known user behavior.
+- Terminate any suspicious processes related to osascript that are running with elevated privileges without a password prompt.
+- Conduct a thorough investigation to identify how the script was executed with elevated privileges, focusing on potential vulnerabilities or misconfigurations.
+- Review and update user account permissions to ensure that only authorized personnel have the ability to execute scripts with administrator privileges.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to monitor and alert on suspicious script executions in real-time.
+- Restore the system to its operational state by applying necessary patches, updating software, and ensuring all security configurations are correctly set.
+- Educate users on the risks associated with script execution and the importance of adhering to security policies.
+- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further analysis and support."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
index b05b7f04238..227b1445fa9 100644
--- a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
+++ b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,49 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.name:"security_authtrampoline" and
  process.parent.name:(osascript or com.apple.automator.runner or sh or bash or dash or zsh or python* or Python or perl* or php* or ruby or pwsh)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution with Explicit Credentials via Scripting
+
+In macOS environments, the `security_authtrampoline` process is used to execute programs with elevated privileges via the Security framework. Adversaries may exploit this by using scripting interpreters to run unauthorized commands with root access, bypassing standard security measures. The detection rule identifies such abuse by monitoring the initiation of `security_authtrampoline` through common scripting languages, flagging potential misuse of explicit credentials for privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `security_authtrampoline` process execution and identify the parent scripting interpreter from the `process.parent.name` field.
+- Cross-reference the `event.category:process` and `event.type:(start or process_started)` fields to verify the timing and frequency of the suspicious process execution.
+- Examine the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential misuse of credentials.
+- Investigate the command line arguments used in the process execution to identify any unusual or unauthorized commands being executed with elevated privileges.
+- Utilize Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'security_authtrampoline';` to retrieve detailed information about the process, including its PID, parent PID, and execution path.
+- Check system logs for any related authentication events or anomalies around the time of the alert to identify potential unauthorized access attempts.
+- Analyze the network activity associated with the process to detect any suspicious outbound connections or data exfiltration attempts.
+- Review recent changes to the system, such as new software installations or script modifications, that could explain the unexpected use of `security_authtrampoline`.
+- Correlate the alert with other security events or alerts in the environment to identify patterns or coordinated activities that may indicate a broader attack.
+- Consult threat intelligence sources to determine if there are known campaigns or threat actors that commonly exploit `security_authtrampoline` for privilege escalation on macOS systems.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use scripting languages to perform routine maintenance or configuration tasks that require elevated privileges, leading to benign instances of `security_authtrampoline` execution. Users can create exceptions for known scripts or processes that are part of regular administrative workflows.
+- Automated scripts and tools: Some automated tools or scripts, such as those used for software deployment or system monitoring, might invoke `security_authtrampoline` as part of their normal operation. Users should identify these tools and whitelist them to prevent unnecessary alerts.
+- Development and testing environments: Developers might execute scripts that trigger `security_authtrampoline` during the development or testing of applications that require elevated privileges. In such cases, users can exclude specific development environments or user accounts from monitoring to reduce false positives.
+- Security software: Certain security applications may use scripting interpreters to perform legitimate security checks or updates that involve `security_authtrampoline`. Users should verify the legitimacy of these applications and consider excluding them from detection rules.
+- User-initiated actions: Advanced users or IT personnel might manually run scripts for troubleshooting or system management purposes. Organizations can implement a process to log and review these actions, allowing for the exclusion of verified user-initiated scripts from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the unauthorized script execution, focusing on recent changes or suspicious activities in user accounts and installed applications.
+- Terminate any unauthorized processes associated with the `security_authtrampoline` and any parent scripting interpreters identified in the alert.
+- Review and revoke any compromised credentials or accounts, ensuring that all passwords are reset and multi-factor authentication is enforced.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships, to aid in future investigations.
+- Integrate endpoint detection and response (EDR) solutions to monitor for similar suspicious activities and provide real-time alerts.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a known good backup, ensuring all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as disabling unnecessary scripting interpreters, restricting the use of `AuthorizationExecuteWithPrivileges`, and enforcing least privilege principles across all user accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
index 2fbd033a24f..15886ce475a 100644
--- a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
+++ b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,51 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
                            /usr/sbin/installer or
                            /usr/bin/csrutil)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Child Process of Adobe Acrobat Reader Update Service
+
+Adobe Acrobat Reader's update service uses a privileged helper tool to manage updates on macOS, running with elevated permissions. Adversaries may exploit vulnerabilities in this service to escalate privileges by executing unauthorized processes as the root user. The detection rule identifies unusual child processes spawned by the update service, excluding known legitimate executables, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and executable path that triggered the alert, ensuring it matches the criteria specified in the detection rule.
+- Verify the parent process name is `com.adobe.ARMDC.SMJobBlessHelper` and the user context is `root` to confirm the alert's legitimacy.
+- Check the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Use Osquery to list all child processes spawned by `com.adobe.ARMDC.SMJobBlessHelper` to identify any other potentially unauthorized processes:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'com.adobe.ARMDC.SMJobBlessHelper');
+  ```
+- Investigate the command line arguments of the suspicious process to understand its intended actions and potential impact.
+- Cross-reference the suspicious process's executable path with known legitimate software paths to rule out false positives.
+- Examine system logs for any unusual activity around the time the suspicious process was executed, focusing on authentication and system modification logs.
+- Check for any recent installations or updates of Adobe Acrobat Reader that might have introduced vulnerabilities or been exploited.
+- Investigate the network activity of the suspicious process to identify any external communications that could indicate data exfiltration or command-and-control activity.
+- Review the system's patch status to ensure it is up-to-date with security patches, particularly those addressing CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613.
+
+### False positive analysis
+
+- Known false positives may include legitimate administrative scripts or tools that are executed by the root user but are not part of the predefined list of allowed executables. These could be custom scripts or third-party management tools that are not typically associated with malicious activity.
+- Users can handle these false positives by reviewing the flagged processes to determine if they are part of regular administrative tasks or maintenance activities. If confirmed as non-threatening, these processes can be added to an exclusion list to prevent future alerts.
+- Another potential false positive scenario involves software updates or installations that utilize temporary or dynamically generated paths not covered by the existing exclusion list. Users should verify the legitimacy of these processes and consider updating the exclusion list to include these paths if they are deemed safe.
+- It is important to regularly review and update the exclusion list to reflect changes in legitimate software behavior or new administrative tools that may be introduced into the environment, ensuring that only genuine threats are flagged by the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the alert by reviewing process execution logs and identifying any unauthorized child processes spawned by the Adobe Acrobat Reader update service.
+- Verify the system's patch status and ensure that it is updated with the latest security patches, specifically addressing CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613.
+- Terminate any suspicious processes identified during the investigation that are not part of the legitimate update service operations.
+- Restore the system to a known good state using backups or system restore points if available and ensure that all security patches are applied.
+- Implement enhanced logging policies to capture detailed process execution data and user activity, focusing on privileged operations and service executions.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to provide real-time monitoring and automated response capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future exploitation attempts.
+- Implement hardening measures such as restricting the execution of unnecessary privileged services, enforcing the principle of least privilege, and regularly auditing privileged accounts and services."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_local_user_added_to_admin.toml b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
index 8e00d539268..460a6377fb3 100644
--- a/rules/macos/privilege_escalation_local_user_added_to_admin.toml
+++ b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,48 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
                                                 "/opt/jc/bin/jumpcloud-agent" or
                                                 "/Library/Addigy/go-agent")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Admin Group Account Addition
+
+In macOS environments, tools like `dscl` and `dseditgroup` manage user group memberships, including admin groups. Adversaries may exploit these tools to escalate privileges by adding accounts to admin groups via command-line operations. The detection rule identifies such attempts by monitoring process activities related to these tools, excluding legitimate management services, to flag unauthorized privilege escalation efforts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `dscl` or `dseditgroup` in the `process.name` field and verify the command-line arguments in `process.args` to ensure they include "/Groups/admin" and "-a" or "-append".
+- Check the `event.category` and `event.type` fields to confirm the event is related to a process start on a macOS host.
+- Examine the `process.Ext.effective_parent.executable` field to ensure the process was not initiated by a legitimate management service like JAMF or JumpCloud.
+- Investigate the user account associated with the process to determine if it has a history of administrative actions or if it is a new or unexpected account.
+- Use Osquery to list current admin group members and identify any recent changes. Example query: `SELECT * FROM groups WHERE groupname = 'admin';`
+- Cross-reference the timestamp of the alert with system logs to identify any concurrent suspicious activities or anomalies.
+- Analyze the parent process of the flagged activity to understand the context in which the `dscl` or `dseditgroup` command was executed.
+- Review recent login events on the host to identify any unusual or unauthorized access attempts around the time of the alert.
+- Check for any other alerts or indicators of compromise on the same host that might suggest a broader attack or compromise.
+- Consult with the user or system owner to verify if the action was legitimate or if they have any knowledge of the activity.
+
+### False positive analysis
+
+- Legitimate administrative tools and services, such as JAMF and JumpCloud, may trigger this rule when performing authorized group management tasks. These tools are often used by IT departments for device management and may add accounts to admin groups as part of their normal operations.
+- To manage these false positives, users can create exceptions for known legitimate processes by excluding their executable paths in the detection rule. This can be done by adding the paths of trusted management services to the exclusion list, ensuring that only unauthorized attempts are flagged.
+- Regularly review and update the exclusion list to include any new legitimate management tools that may be introduced into the environment, ensuring that the detection rule remains effective without generating unnecessary alerts.
+- Consider implementing additional context checks, such as verifying the user context or correlating with other security events, to further reduce false positives and enhance the accuracy of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Verify the account added to the admin group and determine if it is legitimate or unauthorized by cross-referencing with user management records.
+- Review system logs and security alerts to identify any other suspicious activities or related incidents that may indicate a broader compromise.
+- Remove the unauthorized account from the admin group and reset its credentials to prevent further misuse.
+- Conduct a thorough investigation to determine how the unauthorized account addition occurred, focusing on potential vulnerabilities or misconfigurations.
+- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization.
+- Implement enhanced logging and monitoring policies to capture detailed process activities and user actions, ensuring better visibility for future investigations.
+- Integrate security tools and solutions, such as SIEM and EDR, to automate detection and response to similar threats in the future.
+- Restore the system to its operational state by applying necessary patches, updates, and security configurations to prevent recurrence.
+- Harden the system by enforcing least privilege principles, regularly reviewing user group memberships, and conducting security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_root_crontab_filemod.toml b/rules/macos/privilege_escalation_root_crontab_filemod.toml
index 3e51714cdd2..34e3b36ef7f 100644
--- a/rules/macos/privilege_escalation_root_crontab_filemod.toml
+++ b/rules/macos/privilege_escalation_root_crontab_filemod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:deletion and
  file.path:/private/var/at/tabs/root and not process.executable:/usr/bin/crontab
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privilege Escalation via Root Crontab File Modification
+
+Crontab files in macOS are used to schedule tasks, often requiring elevated privileges for execution. Adversaries may exploit this by modifying the root crontab file to execute malicious code with root privileges. The detection rule identifies unauthorized changes to this file, excluding legitimate crontab processes, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event category is 'file' and the host operating system type is 'macos', ensuring the alert is relevant to the environment.
+- Verify the file path involved in the alert is '/private/var/at/tabs/root', which indicates a modification to the root crontab file.
+- Check the process executable path to ensure it is not '/usr/bin/crontab', as legitimate crontab modifications should originate from this executable.
+- Use Osquery to list all current scheduled tasks and jobs on the affected macOS system to identify any unauthorized or suspicious entries. Example query: `SELECT * FROM crontab WHERE path = '/private/var/at/tabs/root';`
+- Investigate the user account associated with the process that modified the root crontab file to determine if it has legitimate access or if it might be compromised.
+- Examine the timestamp of the modification event to correlate with other system activities or alerts that occurred around the same time.
+- Review system logs for any unusual or unauthorized login attempts or privilege escalation activities preceding the crontab modification.
+- Analyze the contents of the modified root crontab file to identify any suspicious or unexpected scheduled tasks that could indicate malicious intent.
+- Cross-reference the modification event with known MITRE ATT&CK techniques, specifically focusing on Privilege Escalation (TA0004) and Scheduled Task/Job (T1053), to understand potential adversary behavior.
+- Consult threat intelligence sources to determine if there are any known campaigns or malware that exploit root crontab modifications on macOS systems.
+
+### False positive analysis
+
+- System administrators may legitimately modify the root crontab file for maintenance tasks or scheduled updates, which could trigger the detection rule. To manage this, users can create exceptions for known administrator accounts or specific maintenance scripts.
+- Automated system management tools or software updates might alter the root crontab file as part of their normal operation. Users should identify these tools and add them to an exclusion list to prevent false alerts.
+- Backup or monitoring software that checks or modifies crontab entries for integrity purposes could also be flagged. Users can exclude these processes by specifying their executable paths in the detection rule.
+- In development environments, developers might test scheduled tasks using the root crontab, leading to false positives. Users can handle this by setting up a separate detection rule for development environments with relaxed criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the integrity of the root crontab file by comparing it with a known good backup or baseline configuration.
+- Investigate the source of the modification by reviewing logs for any suspicious activity around the time of the change, focusing on unauthorized access attempts or unusual process executions.
+- Identify and terminate any malicious processes that may have been initiated through the modified crontab entry.
+- Restore the root crontab file to its original state using a backup or by manually removing unauthorized entries.
+- Conduct a thorough scan of the system for additional signs of compromise, such as unauthorized user accounts or unexpected changes to critical system files.
+- Escalate the incident to the security operations team for further analysis and to determine if other systems may be affected.
+- Implement enhanced logging policies to capture detailed information on file modifications and process executions, particularly for privileged files and directories.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate events and improve detection capabilities for similar threats in the future.
+- Apply system hardening measures, such as restricting write permissions to critical files and directories, and regularly auditing user privileges to minimize the risk of privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
index debaac79b06..65f85640ebe 100644
--- a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -79,6 +79,50 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 DNS Tunneling
+DNS tunneling exploits the DNS protocol to covertly transmit data between a compromised system and an attacker-controlled server. Adversaries may use it for stealthy command-and-control or data exfiltration by embedding data within DNS queries. The 'DNS Tunneling' detection rule leverages machine learning to identify anomalies, such as an unusually high volume of DNS queries to a single domain, indicative of potential tunneling activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific domain involved in the unusually high volume of DNS queries. Note the domain name and the number of queries.
+- Check the source IP address or host that generated the DNS queries to determine if it is a known or trusted device within the network.
+- Analyze historical DNS logs to identify patterns or trends in DNS query activity from the source IP address. Look for any other unusual or repetitive query patterns.
+- Use network traffic analysis tools to capture and inspect DNS traffic from the source IP address. Look for any encoded data or unusual payloads within the DNS queries.
+- Investigate the domain involved in the alert using threat intelligence sources to determine if it is associated with known malicious activity or DNS tunneling tools.
+- Utilize Osquery to gather additional context from the affected host. For example, run the following Osquery query to list recent DNS queries made by the host:
+  ```sql
+  SELECT name, count FROM dns_cache WHERE name LIKE '%.<suspicious_domain>';
+  ```
+- Check for any running processes on the affected host that may be associated with DNS tunneling tools, such as dnscat or Iodine.
+- Review system logs and security events on the affected host for any signs of compromise or unusual activity around the time of the DNS queries.
+- Correlate the DNS tunneling alert with other security alerts or incidents to determine if it is part of a larger attack campaign or if other systems are affected.
+- Consult with other teams, such as threat intelligence or incident response, to gather additional insights or context about the potential threat and its implications.
+
+### False positive analysis
+
+- High volumes of DNS queries to legitimate content delivery networks (CDNs) or cloud service providers can trigger false positives, as these services often use DNS for load balancing and redundancy. Users can mitigate this by creating exceptions for known CDN or cloud service domains.
+- Internal applications that rely heavily on DNS for service discovery or configuration management might generate a large number of DNS queries, which could be mistaken for tunneling activity. Users should identify and whitelist these internal domains to prevent false alerts.
+- Automated security tools or network monitoring solutions that perform frequent DNS lookups for threat intelligence or domain reputation checks may also cause false positives. Users can exclude these tools' DNS queries from the detection rule to reduce noise.
+- Some legitimate software updates or patch management systems may use DNS queries to check for updates, leading to a high volume of DNS traffic. Users should identify these systems and add them to an exception list to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration or command-and-control communication.
+- Conduct a thorough investigation of DNS logs to identify the scope of the tunneling activity and determine which domains were queried excessively.
+- Analyze network traffic to identify any additional compromised systems or unusual patterns that may indicate further tunneling or malicious activity.
+- Remove any malicious software or scripts identified during the investigation from the affected system.
+- Change all credentials and access tokens that may have been exposed or compromised during the tunneling activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are at risk.
+- Implement enhanced DNS logging and monitoring to detect future tunneling attempts, including setting up alerts for high volumes of DNS queries to single domains.
+- Integrate threat intelligence feeds to enrich DNS query data and improve detection of known malicious domains.
+- Restore the affected system to its operational state by applying necessary patches and updates, and ensure all security controls are re-enabled.
+- Harden the network by implementing DNS filtering, restricting outbound DNS traffic to known and trusted servers, and regularly reviewing firewall and proxy configurations."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
index 57cef36eac2..012480dc85e 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -82,6 +82,48 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual DNS Activity
+DNS, a cornerstone of internet functionality, translates domain names into IP addresses. Adversaries exploit DNS by using rare domains for malicious activities like command-and-control or data exfiltration. The 'Unusual DNS Activity' detection rule leverages machine learning to identify atypical DNS queries, signaling potential threats such as phishing or malware communication, by flagging uncommon domain interactions.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific uncommon domain that triggered the alert and the associated timestamp.
+- Cross-reference the uncommon domain with threat intelligence sources to determine if it is associated with known malicious activity.
+- Analyze DNS logs to identify the source IP address of the device making the unusual DNS query and any other domains it has queried recently.
+- Investigate the user or system associated with the source IP address to determine if there are any signs of compromise or unusual behavior.
+- Use Osquery to gather additional context from the affected system. For example, run the following query to list recent DNS queries made by the system: `SELECT name, time FROM dns_resolvers WHERE time > strftime('%s', 'now', '-1 day');`
+- Check network traffic logs for any outbound connections to the uncommon domain and assess the volume and frequency of these connections.
+- Examine endpoint security logs for any alerts or detections that coincide with the timestamp of the unusual DNS activity.
+- Investigate any recent changes or installations on the affected system that could be related to the unusual DNS activity.
+- Review email logs for any phishing attempts or suspicious emails received by the user associated with the alert.
+- Consult with other security team members or departments to gather additional insights or context regarding the unusual DNS activity.
+
+### False positive analysis
+
+- Legitimate software updates or cloud services may trigger the Unusual DNS Activity rule if they use uncommon domains for content delivery or API calls. Users can manage these by identifying and whitelisting known update servers or cloud service domains.
+- Internal development or testing environments might use non-standard domains that appear unusual. To handle these, users should document and exclude these domains from the detection rule to prevent false alerts.
+- Third-party applications or services that rely on dynamic or ephemeral domains for functionality can be mistaken for malicious activity. Users should maintain a list of trusted applications and their associated domains to exclude them from triggering the rule.
+- Some organizations use custom DNS configurations or private domains that may not be widely recognized. Users should ensure these are accounted for in the detection rule settings to avoid false positives.
+- Temporary spikes in DNS queries due to legitimate business activities, such as marketing campaigns or product launches, can be misinterpreted as unusual activity. Users should monitor and adjust the rule thresholds during such events to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with the malicious domain.
+- Conduct a thorough investigation to identify the scope of the compromise, including checking for other systems that may have communicated with the same domain.
+- Analyze DNS logs and network traffic to identify any additional indicators of compromise (IOCs) related to the unusual DNS activity.
+- Remove any identified malware or unauthorized software from the affected system using antivirus or endpoint detection and response (EDR) tools.
+- Change passwords and credentials that may have been exposed or used on the compromised system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Implement or enhance DNS logging and monitoring to detect future unusual DNS activities more effectively.
+- Integrate threat intelligence feeds to enrich DNS data and improve detection capabilities for known malicious domains.
+- Restore the system to its operational state by applying necessary patches and updates, and verify that all security controls are functioning correctly.
+- Harden the system by implementing security best practices, such as disabling unnecessary services, applying least privilege principles, and ensuring regular security training for users."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
index 7e7f50eccfe..3ef1ae396c5 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -85,6 +85,49 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Web Request
+The 'Unusual Web Request' detection leverages machine learning to identify rare URLs that deviate from normal web activity, potentially signaling malicious actions like initial access or data exfiltration. Adversaries exploit trusted sites by embedding uncommon URLs to deliver payloads or establish command-and-control channels. This rule detects anomalies by flagging atypical URL requests, aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unusual URL and the associated host or IP address that made the request.
+- Check historical logs to determine if the unusual URL has been accessed previously and identify any patterns or trends in access times.
+- Correlate the unusual URL with known threat intelligence sources to determine if it is associated with any known malicious activity or campaigns.
+- Analyze the user agent string and other HTTP headers in the request to identify any anomalies or indicators of automated tools or scripts.
+- Investigate the source IP address to determine its geolocation and check if it is associated with any known malicious activity or blacklists.
+- Use Osquery to gather additional context from the affected host. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<source IP>';`
+- Examine DNS logs to see if there are any other unusual domain resolutions around the same time as the alert.
+- Check for any related alerts or events in the same timeframe that might indicate a broader attack or compromise.
+- Review endpoint security logs on the affected host to identify any suspicious processes or file modifications that coincide with the unusual web request.
+- Consult with the user or system owner to verify if the unusual URL request was legitimate or if they noticed any unusual behavior on their system.
+
+### False positive analysis
+
+- Known false positives for the Unusual Web Request rule can include legitimate business applications or services that use uncommon URLs for regular operations, such as software updates or API calls.
+- Web crawlers and bots that are part of normal internet traffic may trigger alerts due to their access patterns, which can appear as unusual but are non-threatening.
+- Internal development or testing environments might generate rare URL requests that are benign but flagged by the detection system.
+- To manage these false positives, users can create exceptions for specific URLs or domains that are verified as safe and part of routine operations.
+- Implementing a whitelist for known and trusted services that frequently generate uncommon URLs can help reduce unnecessary alerts.
+- Regularly reviewing and updating the list of exceptions based on changes in business processes or new legitimate services can maintain the effectiveness of the detection system while minimizing false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further communication with potentially malicious URLs.
+- Conduct a thorough investigation of the unusual URL request to determine if it is part of a known attack pattern, referencing MITRE ATT&CK techniques such as T1071 for context.
+- Analyze network traffic logs and web server logs to identify any additional suspicious activity or related requests.
+- Remove any identified malware or unauthorized software from the affected system using updated antivirus or endpoint detection and response tools.
+- Restore the system from a clean backup if malware removal is not feasible or if the system's integrity is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a targeted attack or data exfiltration attempt.
+- Implement enhanced logging policies to capture detailed web request data, including URL parameters and referrer information, for future investigations.
+- Integrate threat intelligence feeds and anomaly detection systems to improve the detection of unusual web requests and related threats.
+- Conduct a security review of web server configurations and apply hardening measures, such as disabling unnecessary services and applying the latest security patches.
+- Educate users on recognizing phishing attempts and suspicious URLs to reduce the risk of initial access through social engineering tactics."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
index 92fe092fe32..d80646fb4e6 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -83,6 +83,48 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Web User Agent
+User agents identify applications making web requests, typically browsers. However, adversaries may exploit this by using non-standard user agents for malicious activities like persistence or data exfiltration. The 'Unusual Web User Agent' detection rule leverages machine learning to identify rare user agents, flagging potential threats from unexpected processes, thus aiding in uncovering malicious web activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unusual user agent string and the process associated with it.
+- Check the source and destination IP addresses involved in the alert to determine if the traffic is internal or external.
+- Investigate the process that generated the unusual user agent by examining process creation logs and command-line arguments.
+- Use Osquery to gather more information about the process. Example query: `SELECT name, path, cmdline, pid FROM processes WHERE name = '<process_name>';`
+- Analyze network traffic logs to identify any patterns or anomalies associated with the unusual user agent, such as repeated access to specific domains or IPs.
+- Cross-reference the unusual user agent with known malicious user agents or those associated with legitimate applications to assess potential threats.
+- Check for any recent changes or updates on the system that might have introduced new software or scripts using the unusual user agent.
+- Investigate any related alerts or logs that might provide additional context, such as failed login attempts or other suspicious activities around the same time.
+- Consult threat intelligence sources to determine if the unusual user agent has been reported in recent attacks or campaigns.
+- Document findings and gather evidence to support further analysis or escalation if the unusual user agent is deemed suspicious or malicious.
+
+### False positive analysis
+
+- Uncommon user agents from legitimate applications such as weather monitoring or stock-trading programs can trigger false positives. Users should identify these applications and create exceptions to prevent unnecessary alerts.
+- Automated tools like web scrapers, bots, or scanners that are part of regular internet traffic may be flagged. Regularly review and whitelist known benign sources to reduce noise.
+- Internal network monitoring tools or scripts that use custom user agents for legitimate purposes might be detected. Ensure these are documented and excluded from the detection rule.
+- Software updates or patches that temporarily use unusual user agents can cause alerts. Monitor update schedules and adjust detection parameters accordingly.
+- Development or testing environments where custom user agents are used for simulation purposes may trigger false positives. Implement environment-specific exceptions to manage these alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration or command-and-control communication.
+- Conduct a thorough investigation to identify the process using the unusual user agent and determine if it is malicious or benign.
+- Review system and network logs to trace the origin and scope of the activity, focusing on any connections to known malicious IP addresses or domains.
+- If malware is detected, remove it using updated antivirus or anti-malware tools and ensure the system is clean.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed as malicious or if it involves sensitive data.
+- Implement enhanced logging policies to capture detailed user agent strings and associated process information for future analysis.
+- Integrate threat intelligence feeds to correlate unusual user agents with known threat actor tools and techniques.
+- Restore the system to its operational state by applying necessary patches, updates, and verifying system integrity.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring all software is up to date."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
index 7c9569ca0b5..a28de000b37 100644
--- a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
+++ b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -98,6 +98,49 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Logon Events
+
+The detection of a spike in logon events leverages machine learning to identify anomalies in authentication patterns, which may indicate malicious activities like password spraying or brute force attacks. Adversaries exploit these methods to gain unauthorized access by overwhelming systems with login attempts. The detection rule monitors for unusual surges in successful logins, aligning with MITRE ATT&CK's Credential Access tactics, to alert analysts of potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the scope of the spike, including the time frame and the number of logon events compared to the baseline.
+- Identify the user accounts involved in the spike and check for any patterns, such as repeated attempts from the same account or a group of accounts.
+- Analyze the source IP addresses associated with the logon events to determine if they originate from unusual or suspicious locations.
+- Cross-reference the source IP addresses with threat intelligence feeds to check for any known malicious activity.
+- Use Osquery to gather additional context on the affected systems. For example, run the following query to list recent logon events on a specific host: `SELECT * FROM users WHERE last_login > (SELECT MAX(last_login) - 86400 FROM users);`
+- Check for any recent changes in user account permissions or group memberships that could indicate unauthorized access.
+- Investigate any failed logon attempts that occurred around the same time as the spike in successful logons to identify potential brute force activity.
+- Review system and application logs for any other suspicious activities or anomalies that coincide with the spike in logon events.
+- Examine any recent changes in network configurations or security policies that might have inadvertently allowed the spike in logon events.
+- Collaborate with other teams, such as network or application security, to gather additional insights or context that might explain the spike in logon events.
+
+### False positive analysis
+
+- High-volume legitimate logins from automated processes or scripts can trigger false positives. These should be identified and excluded by creating exceptions for known IP addresses or service accounts.
+- Scheduled tasks or batch jobs that require frequent authentication may cause spikes in logon events. Analysts can manage these by setting up rules to ignore logins from specific systems or during certain time windows.
+- User behavior during events like company-wide password resets or system maintenance can lead to increased logon activity. To handle this, temporary exceptions can be applied during these periods to prevent false alerts.
+- Integration with third-party applications that authenticate using the same credentials might result in a surge of logon events. Users should whitelist these applications to avoid unnecessary alerts.
+- Employees accessing systems from multiple devices or locations, especially in remote work scenarios, can cause spikes. Implementing geolocation-based exclusions or device recognition can help mitigate these false positives.
+
+### Response and remediation
+
+- Immediately isolate affected accounts by disabling them to prevent further unauthorized access.
+- Conduct a thorough investigation of the spike in logon events to identify the source and scope of the attack, focusing on logs and authentication attempts.
+- Reset passwords for compromised accounts and enforce strong password policies to mitigate the risk of future brute force attacks.
+- Review and enhance logging policies to ensure comprehensive capture of authentication events, including failed login attempts and account lockouts.
+- Implement multi-factor authentication (MFA) for all users to add an additional layer of security against unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Integrate threat intelligence feeds to correlate detected anomalies with known threat actors and tactics, techniques, and procedures (TTPs).
+- Restore affected systems to their operational state by applying necessary patches and updates, and verify system integrity.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users on recognizing phishing attempts and the importance of secure password practices to reduce the likelihood of credential compromise."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
index 25165dddda5..f0d079bcdc7 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -84,6 +84,49 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux Process Calling the Metadata Service
+
+In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries exploit this by using atypical processes to access metadata, aiming to extract sensitive information like credentials. The detection rule identifies anomalies by monitoring unexpected process interactions with the metadata service, flagging potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and user account involved in the unusual access to the metadata service.
+- Check the process command line and arguments to understand the intent and context of the process execution.
+- Investigate the parent process to determine if the process was spawned by a legitimate or suspicious application.
+- Use Osquery to gather additional context about the process. Example query: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<suspicious_process_name>';`
+- Examine the process execution history on the host to identify any patterns or anomalies in its behavior.
+- Analyze the network connections established by the process to verify if it accessed the metadata service endpoint.
+- Review system logs for any related authentication attempts or access logs that might indicate unauthorized access.
+- Correlate the process activity with other security events or alerts to identify potential lateral movement or privilege escalation.
+- Investigate the user account associated with the process for any signs of compromise or unusual activity.
+- Check for any recent changes or deployments on the host that might explain the presence of the unusual process.
+
+### False positive analysis
+
+- Scheduled maintenance scripts or automated backup processes may access the metadata service for legitimate reasons, leading to false positives. Users can handle these by identifying and whitelisting such processes.
+- Custom monitoring tools or configuration management systems might interact with the metadata service to gather instance information, which could be misinterpreted as suspicious activity. Users should document these tools and create exceptions for them.
+- Cloud-native applications that dynamically adjust configurations based on metadata service information might trigger alerts. Users should ensure these applications are recognized and excluded from the rule.
+- Developers or system administrators performing manual checks or updates might access the metadata service, which could be flagged as unusual. Users can mitigate this by logging and reviewing such activities to differentiate between legitimate and suspicious access.
+- In environments with frequent deployment changes, new or updated processes might temporarily appear unusual. Users should establish a baseline of normal behavior and update it regularly to accommodate these changes.
+
+### Response and remediation
+
+- Immediately isolate the affected instance to prevent further unauthorized access to the metadata service.
+- Conduct a thorough investigation to identify the unusual process and determine if any credentials or sensitive data were accessed or exfiltrated.
+- Revoke and rotate any credentials that may have been exposed to prevent unauthorized access to other systems.
+- Review and update security group rules and IAM policies to ensure least privilege access to the metadata service.
+- Implement enhanced logging and monitoring for metadata service access, including logging all API calls and process interactions.
+- Integrate threat intelligence feeds and anomaly detection tools to improve detection of unusual activities related to metadata access.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
+- Restore the affected system to its operational state by applying patches, updating configurations, and ensuring all security controls are in place.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary services, applying security patches, and enforcing strong authentication mechanisms to protect against future attacks."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
index 1e960dc1f49..abd7961e89d 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -84,6 +84,48 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux User Calling the Metadata Service
+
+Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using unauthorized users to query the service, aiming to extract sensitive information. The detection rule identifies atypical access patterns by monitoring for unexpected user interactions with the metadata service, flagging potential credential harvesting attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and instance involved in the unusual metadata service access.
+- Check the timestamp of the alert to determine when the access occurred and correlate it with any known scheduled tasks or maintenance activities.
+- Examine the command history of the identified user on the instance to look for any commands that might have been used to access the metadata service.
+- Use Osquery to gather more information about the user and their recent activities. For example, run the following query to list recent processes executed by the user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'unusual_user');`
+- Investigate the network logs to identify any other unusual outbound connections from the instance around the time of the alert.
+- Check for any recent changes in user permissions or roles that might have inadvertently granted access to the metadata service.
+- Review the instance's system logs for any signs of compromise or unauthorized access attempts.
+- Analyze the metadata service access logs to determine if there were multiple access attempts or if other users have also accessed it unexpectedly.
+- Cross-reference the instance's IP address with threat intelligence sources to check for any known malicious activity associated with it.
+- Consult with the team responsible for the instance to verify if the access was legitimate and if any recent changes or deployments could explain the unusual behavior.
+
+### False positive analysis
+
+- Scheduled maintenance scripts or automated processes may trigger the rule if they access the metadata service regularly. These should be reviewed and, if deemed non-threatening, added to an exception list to prevent future alerts.
+- Backup or monitoring tools that require metadata access for legitimate purposes might be flagged. Identifying these tools and excluding their access patterns can reduce false positives.
+- Developers or system administrators performing legitimate testing or configuration tasks may inadvertently access the metadata service. Regularly review and update the list of authorized users to ensure their activities are not mistakenly flagged.
+- Instances of newly deployed applications or services that access the metadata service as part of their initialization process can be mistaken for suspicious activity. Documenting and excluding these known behaviors can help in minimizing false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected instance to prevent further unauthorized access to the metadata service.
+- Conduct a thorough investigation to identify the unusual user and determine how they gained access to the system.
+- Review access logs and metadata service queries to assess the extent of the compromise and identify any data exfiltration.
+- Revoke any credentials that may have been exposed and rotate keys or tokens associated with the affected instance.
+- Escalate the incident to the security operations team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed access logs for the metadata service and monitor for future anomalies.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all credentials are secure.
+- Harden the system by enforcing least privilege access, using role-based access controls, and regularly auditing user permissions.
+- Educate users and administrators on the importance of securing credentials and recognizing signs of unauthorized access attempts."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_suspicious_login_activity.toml b/rules/ml/credential_access_ml_suspicious_login_activity.toml
index ee7a91db756..cb7b64df9d9 100644
--- a/rules/ml/credential_access_ml_suspicious_login_activity.toml
+++ b/rules/ml/credential_access_ml_suspicious_login_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -95,6 +95,51 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Login Activity
+In modern environments, authentication systems are crucial for verifying user identities. Adversaries often exploit these systems through brute force attacks, attempting numerous login attempts to gain unauthorized access. The 'Unusual Login Activity' detection rule monitors for spikes in authentication attempts, signaling potential credential access threats. By identifying these anomalies, security teams can swiftly respond to and mitigate unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user accounts and IP addresses involved in the unusual login activity.
+- Check the timestamp of the alert to determine the time window of the suspicious activity.
+- Analyze the source IP addresses to identify if they are from known malicious sources or unusual locations for the user.
+- Examine the number of failed versus successful login attempts to assess the likelihood of a brute force attack.
+- Investigate the user accounts involved to determine if they have been targeted in past incidents or have elevated privileges.
+- Use Osquery to gather additional context on the affected systems. For example, run the following query to list recent login attempts on a specific host:
+  ```sql
+  SELECT username, time, host, address FROM last WHERE host = 'affected_host_name';
+  ```
+- Correlate the unusual login activity with other security events, such as changes in user permissions or modifications to critical files.
+- Check for any recent changes in the authentication system configuration that might have triggered false positives.
+- Review logs from other security tools, such as firewalls or intrusion detection systems, for related suspicious activity.
+- Consult with the user(s) involved to verify if the login attempts were legitimate or if their credentials may have been compromised.
+
+### False positive analysis
+
+- High-volume automated processes: Systems or applications that perform regular, automated login attempts, such as scheduled tasks or health checks, can trigger false positives. To manage this, identify and whitelist these processes by creating exceptions for known IP addresses or service accounts.
+- User behavior during password resets: Users may attempt multiple logins during password reset processes, leading to a spike in authentication attempts. Security teams can mitigate this by monitoring for password reset activities and correlating them with login attempts to distinguish between legitimate and suspicious behavior.
+- Load testing activities: During performance testing, systems may simulate numerous login attempts to evaluate authentication service capacity. Exclude these activities by coordinating with development and testing teams to schedule and document load tests, allowing for temporary rule adjustments.
+- Shared workstations or kiosks: Environments where multiple users log in from the same device can result in a high number of authentication attempts. Implement user behavior baselines and exclude these devices from triggering alerts by recognizing their unique usage patterns.
+- VPN or remote access fluctuations: Users connecting from different locations or through VPNs may cause a surge in login attempts. To handle this, establish a baseline for remote access patterns and adjust detection thresholds accordingly, ensuring legitimate remote work does not trigger false positives.
+
+### Response and remediation
+
+- Immediately isolate affected accounts to prevent further unauthorized access and reset passwords for compromised accounts.
+- Conduct a thorough investigation of the login attempts to identify the source IP addresses and correlate them with known threat intelligence feeds.
+- Review and analyze logs from authentication systems to determine the scope of the attack and identify any additional compromised accounts.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
+- Implement multi-factor authentication (MFA) for all user accounts to enhance security and reduce the risk of future brute force attacks.
+- Update and enforce strong password policies, ensuring that passwords are complex and changed regularly.
+- Integrate additional security tools such as intrusion detection systems (IDS) and security information and event management (SIEM) solutions to improve monitoring and detection capabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Restore affected systems to their operational state by applying necessary patches and updates, and ensure all security controls are functioning correctly.
+- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
index 33d8ed7590e..eb38666dd18 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,48 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Windows Process Calling the Metadata Service
+
+In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries exploit this by using atypical Windows processes to access the service, aiming to extract sensitive data. The detection rule identifies anomalies by monitoring unexpected process interactions with the metadata service, aligning with MITRE ATT&CK's focus on credential access and unsecured credentials.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Windows process that accessed the metadata service, noting the process name, process ID, and the user account under which it was running.
+- Check the timestamp of the alert to determine when the unusual access occurred and correlate it with any other suspicious activities in the logs around the same time.
+- Investigate the parent process of the identified Windows process to understand how it was initiated and whether it was spawned by a legitimate application or script.
+- Use Osquery to gather more information about the process. For example, run the following query to get details about the process and its parent: `SELECT pid, name, path, parent, cmdline FROM processes WHERE pid = <process_id>;`
+- Examine the network connections established by the process using Osquery: `SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid = <process_id>;` to identify any unusual or unauthorized connections.
+- Analyze the command line arguments used by the process to determine if there are any indications of malicious intent or attempts to access sensitive data.
+- Check the Windows Event Logs for any related security events, such as logon events or privilege escalation attempts, that might provide additional context about the process's activity.
+- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access or privilege escalation.
+- Review any recent changes or updates to the system or applications that might have introduced the unusual process behavior, including software installations or script deployments.
+- Consult threat intelligence sources to see if the process or its behavior matches any known indicators of compromise or attack patterns related to credential access or metadata service exploitation.
+
+### False positive analysis
+
+- Known false positives may include legitimate administrative tools or scripts that access the metadata service for configuration management or system monitoring purposes. These tools might be scheduled to run at regular intervals, leading to repeated alerts.
+- Automated backup or deployment processes that interact with the metadata service to retrieve instance-specific information can also trigger false positives. These processes are typically part of routine operations and not indicative of malicious activity.
+- Users can manage these false positives by creating exceptions for known and trusted processes that regularly access the metadata service. This can be done by whitelisting specific process names or paths that are verified to be part of legitimate operations.
+- It is important to regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule against genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the unusual process and determine how it accessed the metadata service, focusing on process execution logs and network traffic.
+- Terminate the suspicious process and any associated processes to stop ongoing malicious activity.
+- Review and revoke any credentials or tokens that may have been exposed or compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging and monitoring for metadata service access, ensuring that all access attempts are logged and reviewed for anomalies.
+- Integrate threat intelligence feeds to correlate the incident with known threat actors or tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
+- Restore the system to its operational state by applying patches, updating security configurations, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as restricting metadata service access to only trusted processes.
+- Provide training and awareness to relevant personnel on the risks associated with metadata service access and the importance of securing credentials."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
index 2e6b058293f..4147284c43f 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,49 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Windows User Calling the Metadata Service
+
+Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using compromised Windows accounts to query the service, aiming to extract sensitive information. The detection rule identifies atypical access patterns by monitoring for unexpected user interactions with the metadata service, flagging potential credential harvesting attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Windows user account involved and the timestamp of the metadata service access.
+- Check the source IP address and geolocation associated with the access to determine if it aligns with expected user behavior or known locations.
+- Analyze the user's recent login history and patterns to identify any anomalies or deviations from their typical activity.
+- Investigate the user's group memberships and permissions to assess if they have legitimate access to the metadata service.
+- Examine the process and command-line arguments used during the metadata service access to identify any suspicious or unauthorized tools.
+- Utilize Osquery to gather additional context on the system. For example, run the following query to list recent processes executed by the user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
+- Cross-reference the metadata service access with other security logs, such as firewall or intrusion detection system logs, to identify any correlated suspicious activities.
+- Review any recent changes to the user's account, such as password resets or privilege escalations, that could indicate account compromise.
+- Check for any other alerts or incidents involving the same user or system to determine if this is part of a broader attack pattern.
+- Consult threat intelligence sources to see if there are any known campaigns or tactics that match the observed behavior, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may occasionally access the metadata service for legitimate purposes, such as configuration checks or updates. These actions can be mistaken for suspicious activity.
+- Automated scripts: Some automated processes or scripts might be configured to interact with the metadata service regularly for maintenance or monitoring purposes, leading to false alerts.
+- Third-party tools: Certain third-party management or monitoring tools may access the metadata service as part of their normal operation, which could trigger the detection rule.
+- To manage these false positives, users can create exceptions for known administrative accounts or service accounts that regularly interact with the metadata service. This can be done by maintaining a whitelist of trusted users or processes.
+- Regularly review and update the list of exceptions to ensure it reflects current operational needs and does not inadvertently exclude genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the compromised user account and determine the scope of the breach, including any other systems or data accessed.
+- Reset passwords for the compromised account and any other accounts that may have been affected, ensuring the use of strong, unique passwords.
+- Review and analyze logs from the metadata service and other relevant systems to identify any unusual patterns or indicators of compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Implement enhanced logging and monitoring policies to capture detailed access logs for the metadata service and other critical systems.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the affected system to its operational state by applying necessary patches, updates, and security configurations.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to address these vulnerabilities.
+- Educate users on security best practices and the importance of safeguarding credentials to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_information_discovery.toml b/rules/ml/discovery_ml_linux_system_information_discovery.toml
index 2e06a27dba8..9fcfd8261cd 100644
--- a/rules/ml/discovery_ml_linux_system_information_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_information_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -86,6 +86,48 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux System Information Discovery Activity
+
+Linux systems often use commands like `uname`, `lscpu`, or `lsb_release` for legitimate system information discovery, aiding in troubleshooting and system management. However, adversaries can exploit these commands to gather critical system details, potentially leading to privilege escalation or persistence. The detection rule identifies atypical usage patterns by monitoring command execution from unexpected user contexts, signaling possible account compromise or malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command executed, the user account involved, and the timestamp of the activity.
+- Check the user account's login history and recent activity using `last` and `lastlog` commands to determine if the account has been accessed from unusual locations or at odd times.
+- Examine the user's shell history files (e.g., `.bash_history`) to identify any other suspicious commands executed around the same time.
+- Use Osquery to gather additional context about the system and user activity. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
+- Investigate the parent process of the suspicious command execution to determine if it was initiated by a legitimate process or a potentially malicious one.
+- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication anomalies or failed login attempts around the time of the alert.
+- Check for any recent changes to user permissions or group memberships that could indicate privilege escalation attempts.
+- Review network activity logs to identify any unusual outbound connections or data exfiltration attempts following the suspicious command execution.
+- Correlate the alert with other security events or alerts in the environment to identify potential patterns or related incidents.
+- Consult threat intelligence sources to determine if the observed activity matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware.
+
+### False positive analysis
+
+- System administrators or IT personnel may execute system information discovery commands during routine maintenance or troubleshooting, which could trigger the rule. To manage this, users can create exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or monitoring tools that run system information commands as part of their normal operation might also be flagged. Users should identify these scripts and whitelist them by their execution paths or associated service accounts to prevent false positives.
+- Developers or engineers working on performance testing or system optimization might use these commands in non-production environments. Users can exclude specific environments or IP ranges from monitoring to reduce unnecessary alerts.
+- In educational or research institutions, students or researchers might execute these commands as part of their learning or experimentation processes. Users can implement exceptions for specific user groups or departments to accommodate these activities without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying the user account involved and any other systems that may have been accessed.
+- Review system logs and command history to identify unusual patterns or unauthorized commands executed, correlating with MITRE ATT&CK technique T1082 for system information discovery.
+- Reset passwords for the compromised account and any other accounts that may have been accessed, ensuring the use of strong, unique passwords.
+- Remove any unauthorized users or processes identified during the investigation and ensure that all system software is up to date with the latest security patches.
+- Restore the system from a known good backup if necessary, ensuring that the backup is free from any malicious modifications.
+- Implement enhanced logging and monitoring policies to capture detailed command execution and user activity, integrating with SIEM solutions for real-time alerting.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Provide security awareness training to users, emphasizing the importance of recognizing and reporting suspicious activity.
+- Consider deploying additional security measures such as multi-factor authentication and endpoint detection and response (EDR) solutions to enhance system hardening and threat detection capabilities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
index eae2bbef640..56ff2f61985 100644
--- a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 25
@@ -86,6 +86,49 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux Network Configuration Discovery
+
+Linux systems often use commands like `ifconfig`, `ip`, and `netstat` for network configuration discovery, essential for troubleshooting and network management. Adversaries exploit these commands to map network structures, aiding in lateral movement or further reconnaissance. The detection rule identifies atypical usage patterns by monitoring command execution from unexpected user accounts, signaling potential account compromise or malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command executed, the user account involved, and the timestamp of the activity.
+- Check the user account's login history and recent activity to determine if the account has been used in an unusual manner or from unexpected locations.
+- Analyze the command execution context, including the terminal or process that initiated the command, to identify any anomalies or suspicious patterns.
+- Investigate the source IP address and hostname associated with the command execution to verify if they are known and trusted within the network.
+- Use Osquery to gather additional context about the system and user activity. For example, run the following query to list recent network-related commands executed by the user: `SELECT * FROM shell_history WHERE command LIKE '%ifconfig%' OR command LIKE '%ip%' OR command LIKE '%netstat%' AND uid = <user_id>;`
+- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any signs of unauthorized access or privilege escalation attempts around the time of the alert.
+- Cross-reference the alert with other security events or alerts to identify any correlated activities that might indicate a broader attack campaign.
+- Review the system's network configuration and recent changes to identify any unauthorized modifications or suspicious network connections.
+- Check for any recent file modifications or new files in the user's home directory or other sensitive directories that might indicate malicious activity.
+- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with specific threat actors or campaigns.
+
+### False positive analysis
+
+- System administrators or network engineers performing routine network diagnostics may trigger the rule if they use unexpected accounts or workstations. To manage this, create exceptions for known user accounts or IP addresses that regularly perform these tasks.
+- Automated scripts or monitoring tools that execute network configuration commands for legitimate purposes might be flagged. Users can whitelist these scripts or processes by identifying their signatures or execution patterns.
+- Temporary or new user accounts created for specific projects or troubleshooting can cause alerts. Ensure these accounts are documented and added to an exception list if their activities are verified as non-threatening.
+- Changes in user roles or responsibilities might lead to legitimate network configuration commands being run by users who previously did not perform such tasks. Regularly update the exception list to reflect these role changes.
+- In environments with frequent network changes or testing, legitimate users might execute network discovery commands more often. Implement a review process to periodically assess and update the list of exceptions based on current network activity patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the user account that executed the unusual network configuration commands and reset its credentials if compromised.
+- Conduct a thorough investigation of the system logs to identify any additional suspicious activities or unauthorized access attempts.
+- Review and analyze the command history to understand the scope of the adversary's reconnaissance and any potential data exfiltration.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed command execution and user activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are intact.
+- Conduct a security audit of the network to identify and remediate any vulnerabilities that could be exploited for similar attacks.
+- Implement hardening measures such as least privilege access, multi-factor authentication, and regular user activity reviews to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
index 83d47f0cbe2..6b1c0595af4 100644
--- a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 25
@@ -86,6 +86,49 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux Network Connection Discovery
+
+In Linux environments, network connection discovery tools help administrators understand system connectivity. Adversaries exploit these tools to map networks, aiding in lateral movement or further reconnaissance. The detection rule identifies atypical usage patterns by monitoring commands executed from unexpected user contexts, signaling potential account compromise or unauthorized network probing.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command executed and the user context from which it was run. Pay attention to fields such as `user`, `command`, and `timestamp`.
+- Check the user's login history and session details using `last` and `who` commands to determine if the user context is legitimate or if there are signs of unauthorized access.
+- Analyze the command history for the user in question by reviewing the `.bash_history` or equivalent shell history files to identify any other suspicious activities.
+- Use Osquery to gather more context about the network connections on the system. For example, run the query: `SELECT * FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'netstat' OR name = 'ss');` to identify processes that have opened network connections.
+- Investigate the source IP addresses and destinations involved in the network connections to determine if they are known and trusted or if they are unusual or malicious.
+- Cross-reference the alert with any recent changes in user permissions or group memberships that might explain the unusual activity.
+- Check for any recent file modifications or new files in the user's home directory that could indicate the presence of malicious scripts or tools.
+- Review system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any anomalies or failed login attempts around the time of the alert.
+- Correlate the alert with other security events or alerts in the environment to identify if this is part of a larger attack pattern or campaign.
+- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with specific threat actors.
+
+### False positive analysis
+
+- System administrators or network engineers may execute network discovery commands during routine maintenance or troubleshooting, which could trigger the rule. To manage this, create exceptions for known user accounts or specific time windows when such activities are expected.
+- Automated scripts or monitoring tools that perform regular network checks might be flagged as unusual. Identify these scripts and whitelist their execution paths or associated user accounts to prevent false alerts.
+- New employees or contractors who are unfamiliar with standard procedures might inadvertently run network discovery commands. Educate these users on proper protocols and consider temporary exceptions while they are onboarded.
+- Changes in network infrastructure or security policies might necessitate increased network discovery activities. During these periods, adjust the rule's sensitivity or temporarily disable it to accommodate the expected increase in legitimate network probing.
+- In environments with frequent role changes, users might inherit permissions that allow them to execute network discovery commands. Regularly review and update user permissions to ensure they align with current job responsibilities, and adjust the rule to account for these transitions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying the user account and commands involved in the unusual network connection discovery.
+- Reset passwords and review permissions for the compromised account to prevent further unauthorized access.
+- Analyze system logs and network traffic to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has accessed other systems.
+- Implement enhanced logging policies to capture detailed command execution and network activity, ensuring future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual activities with known threat actor behaviors.
+- Restore the system to its operational state by applying necessary patches, updates, and verifying the integrity of critical system files.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unused network services, enforcing least privilege access, and regularly auditing user accounts and permissions."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_process_discovery.toml b/rules/ml/discovery_ml_linux_system_process_discovery.toml
index 9eadd5f1c4b..9006b24e919 100644
--- a/rules/ml/discovery_ml_linux_system_process_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_process_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -86,6 +86,49 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux Process Discovery Activity
+In Linux environments, process discovery commands help users and administrators understand active processes, aiding in system management and troubleshooting. However, adversaries can exploit these commands to map out running applications, potentially identifying vulnerabilities for privilege escalation or persistence. The detection rule identifies atypical usage patterns of these commands, especially from unexpected user accounts, signaling possible account compromise or malicious reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and process discovery command that triggered the alert.
+- Check the timestamp of the alert to determine when the unusual activity occurred and correlate it with any other suspicious activities in the same timeframe.
+- Investigate the user account's recent activity history to identify any anomalies or signs of compromise, such as unusual login times or IP addresses.
+- Examine the command execution context, including the parent process and any associated child processes, to understand the broader activity chain.
+- Use Osquery to gather additional context on the system. For example, run the following query to list all processes executed by the suspicious user in the last 24 hours: `SELECT * FROM processes WHERE user = '<suspicious_user>' AND datetime(start_time, 'unixepoch') > datetime('now', '-1 day');`
+- Analyze system logs, such as auth logs and bash history, to identify any unauthorized access or command execution patterns.
+- Cross-reference the process discovery command with known legitimate administrative activities to rule out false positives.
+- Investigate any network connections initiated by the suspicious process to identify potential data exfiltration or lateral movement attempts.
+- Check for any recent changes to system files or configurations that could indicate an attempt to establish persistence or escalate privileges.
+- Consult threat intelligence sources to determine if the observed activity matches any known tactics, techniques, or procedures (TTPs) associated with specific threat actors.
+
+### False positive analysis
+
+- System administrators or IT personnel performing routine maintenance or troubleshooting may trigger the rule if they use process discovery commands from accounts not typically associated with such activities. 
+- Automated scripts or monitoring tools that regularly execute process discovery commands for legitimate system health checks can also be flagged as unusual activity.
+- Developers or engineers conducting performance testing or debugging on production systems might inadvertently cause alerts if their accounts are not recognized as standard for such operations.
+- To manage these false positives, users can create exceptions for specific user accounts or groups known to perform legitimate process discovery tasks regularly.
+- Implementing a whitelist of IP addresses or hostnames from which legitimate process discovery commands are expected can help reduce unnecessary alerts.
+- Regularly review and update the list of known benign activities and user accounts to ensure that legitimate actions are not mistakenly flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Review the user account activity logs to identify any unauthorized access or anomalies, focusing on the account that executed the unusual process discovery commands.
+- Terminate any suspicious processes identified during the investigation to halt potential malicious activities.
+- Change passwords for compromised accounts and enforce multi-factor authentication to enhance account security.
+- Conduct a thorough forensic analysis of the system to identify any additional indicators of compromise or persistence mechanisms.
+- Restore the system from a known good backup if malicious activity is confirmed and ensure all security patches are applied.
+- Implement enhanced logging policies to capture detailed process execution and user activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Review and update security policies and hardening measures, such as disabling unnecessary services and enforcing least privilege principles, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_user_discovery.toml b/rules/ml/discovery_ml_linux_system_user_discovery.toml
index c7ce566570c..d7e05941a19 100644
--- a/rules/ml/discovery_ml_linux_system_user_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_user_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -86,6 +86,49 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux User Discovery Activity
+
+In Linux environments, user discovery commands help administrators identify active users and system owners, crucial for system management. However, adversaries exploit these commands to gather intelligence on user accounts, potentially leading to further attacks like credential theft or privilege escalation. The detection rule identifies atypical execution of these commands by unexpected users, signaling possible account compromise or malicious reconnaissance.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and the command executed that triggered the alert.
+- Check the timestamp of the alert to determine when the unusual activity occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the source IP address and hostname from which the command was executed to verify if it aligns with the user's typical access patterns.
+- Examine the user's login history and session details to identify any anomalies or unauthorized access attempts.
+- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM logged_in_users WHERE user = '<suspicious_user>';` to check for any active sessions of the suspicious user.
+- Analyze the command history of the user account to identify any other potentially malicious or unusual commands executed around the time of the alert.
+- Review system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any failed login attempts or other suspicious authentication events related to the user.
+- Check for any recent changes to user account permissions or group memberships that could indicate privilege escalation attempts.
+- Investigate any recent file modifications or access patterns that could suggest data exfiltration or preparation for further attacks.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign.
+
+### False positive analysis
+
+- System administrators or support staff may execute user discovery commands during routine maintenance or troubleshooting, which can trigger false positives. To manage this, create exceptions for known administrator accounts or specific maintenance windows.
+- Automated scripts or monitoring tools that perform regular checks on user accounts might be flagged as unusual activity. Exclude these scripts or tools by identifying their execution patterns and adding them to an allowlist.
+- Developers or engineers with legitimate reasons to access user information for debugging purposes may also cause alerts. Document these use cases and establish exceptions for specific user roles or groups.
+- Temporary contractors or new employees performing legitimate user discovery as part of their onboarding process might be mistakenly flagged. Implement a review process to quickly assess and approve such activities when they occur.
+- In environments with frequent user account changes, such as educational institutions or large enterprises, regular user discovery might be necessary. Adjust the detection thresholds or create dynamic exceptions based on the frequency of these changes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying the commands executed and the user accounts involved.
+- Review system logs and user activity to identify any unauthorized access or suspicious behavior, leveraging enhanced logging policies if available.
+- Reset passwords for all potentially compromised accounts and enforce multi-factor authentication to prevent unauthorized access.
+- Remove any unauthorized users or accounts created by the adversary and ensure all legitimate accounts have appropriate permissions.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
+- Implement additional security measures such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to enhance monitoring and detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate users on security best practices and the importance of reporting suspicious activity to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/execution_ml_windows_anomalous_script.toml b/rules/ml/execution_ml_windows_anomalous_script.toml
index 43a98b856eb..68dc84ee722 100644
--- a/rules/ml/execution_ml_windows_anomalous_script.toml
+++ b/rules/ml/execution_ml_windows_anomalous_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -84,6 +84,48 @@ tags = [
     "Tactic: Execution",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Powershell Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities to execute malicious scripts, often employing obfuscation to evade detection. The 'Suspicious Powershell Script' detection rule leverages machine learning to identify anomalies in script characteristics, such as obfuscation, indicative of potential threats, aligning with MITRE ATT&CK's execution tactics.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific characteristics of the detected PowerShell script, focusing on fields such as script content, execution time, and user context.
+- Examine the script content for signs of obfuscation, such as encoded commands, unusual variable names, or excessive use of special characters.
+- Check the execution context by identifying the user account and machine involved, using fields like `user.name` and `host.name`.
+- Correlate the script execution with recent user activity logs to determine if the execution aligns with expected behavior or if it appears anomalous.
+- Investigate the parent process that initiated the PowerShell script using fields like `process.parent.name` and `process.parent.id` to identify potential malicious chains.
+- Utilize Osquery to gather additional context on the host. For example, run the following query to list recent PowerShell executions: `SELECT * FROM processes WHERE name = 'powershell.exe' ORDER BY start_time DESC LIMIT 10;`
+- Analyze network connections established by the host around the time of the script execution to identify any suspicious outbound connections.
+- Review any file modifications or registry changes made by the script using endpoint detection logs or file integrity monitoring tools.
+- Check for any related alerts or incidents involving the same user or host to identify patterns or repeated suspicious behavior.
+- Consult threat intelligence sources to determine if the script or its components match known malicious indicators or tactics.
+
+### False positive analysis
+
+- Legitimate administrative scripts: PowerShell is commonly used for legitimate administrative tasks, which may include obfuscation for efficiency or to protect sensitive information. Users should review scripts flagged by the detection rule to determine if they are part of routine administrative operations.
+- Automated deployment tools: Some deployment tools use PowerShell scripts that might appear suspicious due to their automated nature and obfuscation techniques. Users can create exceptions for these tools by identifying their unique characteristics and excluding them from the detection rule.
+- Security software: Certain security solutions use PowerShell scripts for scanning and remediation purposes. These scripts might be flagged as suspicious due to their complexity and obfuscation. Users should verify the source of these scripts and whitelist them if they are from trusted security vendors.
+- Development and testing environments: Developers often use PowerShell scripts for testing and development purposes, which might include obfuscation to simulate real-world scenarios. Users can exclude specific development environments or known developer accounts from the detection rule to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Analyze the detected PowerShell script to understand its behavior and intent, focusing on obfuscation techniques and any external connections it attempts to make.
+- Terminate any malicious processes associated with the script to halt its execution.
+- Review and collect relevant logs, such as PowerShell logs, Windows Event logs, and network traffic logs, to gather evidence and understand the scope of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team if the script is part of a larger attack campaign or if multiple systems are affected.
+- Remove any malicious files or registry entries created by the script to remediate the system.
+- Apply security patches and updates to the affected system to address any vulnerabilities exploited by the script.
+- Implement enhanced logging and monitoring policies for PowerShell activities to improve detection of similar threats in the future.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance visibility and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
index f6b95127b55..0ec1cb7f50f 100644
--- a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
+++ b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -95,6 +95,50 @@ tags = [
     "Tactic: Initial Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Source IP for a User to Logon from
+
+Machine learning models analyze login patterns to identify atypical IP addresses for users, flagging potential threats like compromised accounts or lateral movement. Adversaries exploit valid credentials to access systems from unexpected locations. This detection rule leverages these models to alert analysts to suspicious logins, aiding in early threat identification and response.
+
+### Possible investigation steps
+
+- Review the alert details to identify the unusual source IP address and the associated user account.
+- Check the login history for the user to determine if the IP address has been used previously and assess the frequency of its occurrence.
+- Correlate the unusual IP address with known threat intelligence sources to check if it has been associated with malicious activity.
+- Analyze the geolocation of the unusual IP address to determine if it aligns with the user's typical login locations or if it is from a high-risk region.
+- Investigate the time of the login event to see if it coincides with the user's normal working hours or if it is an anomaly.
+- Use Osquery to gather additional context on the endpoint from which the login was attempted. Example query: `SELECT * FROM logged_in_users WHERE user = '<username>';`
+- Examine any recent changes in the user's account permissions or group memberships that could indicate unauthorized access.
+- Review any concurrent login attempts from different locations for the same user, which could suggest account compromise.
+- Check for any recent password changes or failed login attempts for the user account that could indicate a brute force attack.
+- Investigate any other security alerts or logs related to the user or the unusual IP address to identify potential patterns or related incidents.
+
+### False positive analysis
+
+- Known false positives for the "Unusual Source IP for a User to Logon from" rule can occur when users travel or work remotely, leading to logins from legitimate but previously unseen IP addresses. 
+- Another common false positive scenario is when users access systems through VPNs or proxy services, which can result in logins from IP addresses that differ from their usual patterns.
+- To manage these false positives, users can create exceptions for known and verified IP addresses associated with frequent travel destinations or remote work locations.
+- Implementing a whitelist for IP addresses associated with trusted VPN or proxy services can help reduce unnecessary alerts.
+- Regularly updating the list of approved IP addresses based on user travel patterns and organizational changes can further minimize false positives.
+- Analysts should review and validate the context of flagged logins, considering factors like time of access and user activity, to distinguish between legitimate and suspicious behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying any other compromised accounts or systems.
+- Analyze the unusual IP address to gather intelligence on its origin and any associated malicious activity.
+- Review recent login activity for the affected user and other users to identify any patterns or additional suspicious logins.
+- Reset passwords for the compromised account and any other accounts that may have been affected, ensuring the use of strong, unique passwords.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring policies to capture detailed login events and network activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore the system to its operational state by ensuring all compromised accounts are secured and any malicious software is removed.
+- Apply hardening measures such as multi-factor authentication (MFA) and least privilege access to reduce the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/ml_high_count_network_denies.toml b/rules/ml/ml_high_count_network_denies.toml
index c0f5fc17b56..63be4372e58 100644
--- a/rules/ml/ml_high_count_network_denies.toml
+++ b/rules/ml/ml_high_count_network_denies.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -76,4 +76,52 @@ rule_id = "eaa77d63-9679-4ce3-be25-3ba8b795e5fa"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Firewall Denies
+
+Firewalls and ACLs are critical in regulating network traffic, blocking unauthorized access while allowing legitimate communication. Adversaries may exploit misconfigurations or launch attacks like reconnaissance or denial-of-service to generate a surge in denied traffic. The 'Spike in Firewall Denies' detection rule leverages machine learning to identify unusual spikes, signaling potential misconfigurations or malicious activities.
+
+### Possible investigation steps
+
+- Review the timestamp of the spike to determine the exact time window of the unusual activity.
+- Analyze the source IP addresses involved in the denied traffic to identify any patterns or anomalies, such as repeated attempts from a single IP or a range of IPs.
+- Examine the destination IP addresses and ports to understand which services or applications were targeted during the spike.
+- Check the firewall and ACL configuration logs for recent changes that might have led to misconfigurations, causing legitimate traffic to be denied.
+- Correlate the denied traffic with any known threat intelligence feeds to identify if the source IPs are associated with known malicious actors or activities.
+- Use Osquery to gather additional context on the affected systems. For example, run the following query to list recent network connections on a potentially affected host:
+  ```sql
+  SELECT datetime(start_time, 'unixepoch') AS start_time, local_address, local_port, remote_address, remote_port, protocol
+  FROM process_open_sockets
+  WHERE remote_address IN ('<suspicious_ip_1>', '<suspicious_ip_2>');
+  ```
+- Investigate any related alerts or logs from intrusion detection systems (IDS) or intrusion prevention systems (IPS) that might provide additional context on the nature of the denied traffic.
+- Check for any concurrent spikes in other network activities, such as successful connections or unusual data transfer volumes, which might indicate a broader attack pattern.
+- Review user activity logs to identify any unusual login attempts or access patterns that coincide with the spike in denied traffic.
+- Consult with application owners or network administrators to verify if any legitimate applications or services were impacted by the spike, which could indicate a misconfiguration rather than a malicious attempt.
+
+### False positive analysis
+
+- Routine network scans by security tools or vulnerability assessment software can trigger false positives, as these activities may generate a high volume of denied traffic. Users can handle this by creating exceptions for known IP addresses or ranges associated with these tools.
+- Legitimate applications with misconfigured network settings might cause a spike in denied traffic. Regularly auditing and updating application configurations can help minimize these occurrences.
+- Automated backup or synchronization processes that attempt to connect to restricted network segments may result in false positives. Identifying and whitelisting these processes can prevent unnecessary alerts.
+- Internal network changes, such as updates to firewall rules or ACLs, might temporarily increase denied traffic. Documenting and scheduling these changes can help correlate and exclude them from analysis.
+- High-volume legitimate business operations, like data migrations or large file transfers, could be mistaken for suspicious activity. Monitoring and adjusting thresholds during these operations can reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and nature of the spike in denied traffic, focusing on recent changes in firewall or ACL configurations.
+- Review firewall and ACL logs to pinpoint any misconfigurations or unauthorized changes that may have led to the spike.
+- If malicious activity is suspected, analyze the traffic patterns to identify potential command-and-control (C2) communication attempts or reconnaissance activities.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of a targeted attack or advanced persistent threat (APT).
+- Implement enhanced logging and monitoring to capture detailed information on denied traffic, ensuring future spikes can be quickly analyzed and addressed.
+- Integrate threat intelligence feeds to correlate denied traffic with known malicious IP addresses or domains, enhancing detection capabilities.
+- Restore affected systems to their operational state by applying necessary patches, reconfiguring firewalls, and ensuring all security controls are properly implemented.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement hardening measures such as regular audits of firewall rules, continuous monitoring for anomalies, and employee training on recognizing and reporting suspicious activities."""
 
diff --git a/rules/ml/ml_high_count_network_events.toml b/rules/ml/ml_high_count_network_events.toml
index edc03f65057..df9e3952ad6 100644
--- a/rules/ml/ml_high_count_network_events.toml
+++ b/rules/ml/ml_high_count_network_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -75,4 +75,48 @@ rule_id = "b240bfb8-26b7-4e5e-924e-218144a3fa71"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Spike in Network Traffic
+
+Machine learning models monitor network traffic patterns to identify anomalies, such as unexpected spikes. These spikes may indicate malicious activities like data exfiltration, reconnaissance, or denial-of-service attacks. Adversaries exploit network vulnerabilities to flood traffic or extract data. The detection rule leverages these models to flag unusual traffic surges, prompting further investigation into potential threats.
+
+### Possible investigation steps
+
+- Review the timestamp of the spike to correlate with any scheduled business activities or known events that could justify the increase in traffic.
+- Analyze the source and destination IP addresses involved in the spike to identify any known malicious actors or unusual patterns.
+- Examine the network protocols and ports used during the spike to determine if they align with typical business operations or if they suggest suspicious activity.
+- Check for any recent changes in network configurations or firewall rules that could have inadvertently caused the spike.
+- Utilize Osquery to gather additional context on the systems involved. For example, run the following query to list active network connections: `SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL;`
+- Investigate the volume and type of data being transferred during the spike to assess if it aligns with potential data exfiltration activities.
+- Cross-reference the spike with any other security alerts or logs from intrusion detection systems to identify potential correlations.
+- Review user activity logs to determine if any unauthorized access or unusual user behavior coincides with the spike.
+- Check for any recent vulnerabilities or exploits that could have been leveraged to cause the spike in traffic.
+- Consult threat intelligence sources to see if there are any reports of similar traffic patterns or attacks targeting your industry or organization.
+
+### False positive analysis
+
+- Legitimate business activities such as scheduled data backups or software updates can cause spikes in network traffic, which may be mistakenly flagged as suspicious. 
+- High-volume data transfers during peak business hours or due to seasonal business demands can also trigger false positives.
+- Network performance testing or stress testing activities might generate traffic patterns similar to those of a denial-of-service attack.
+- Users can manage these false positives by creating exceptions for known, recurring activities that are verified as non-threatening.
+- Implementing a whitelist for IP addresses or domains associated with trusted business operations can help reduce false alerts.
+- Regularly updating the machine learning model with feedback on false positives can improve its accuracy over time.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further data exfiltration or damage.
+- Conduct a thorough investigation to identify the source and nature of the traffic spike, using network logs and monitoring tools.
+- Analyze the traffic patterns to determine if the spike correlates with known malicious activities, referencing MITRE ATT&CK for potential tactics and techniques.
+- If malicious activity is confirmed, remove any identified malware or unauthorized access points from the affected systems.
+- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for further analysis and response.
+- Implement enhanced logging policies to capture detailed network traffic data for future analysis and early detection of anomalies.
+- Integrate additional security tools, such as intrusion detection systems (IDS) or endpoint detection and response (EDR) solutions, to improve monitoring capabilities.
+- Restore affected systems to their operational state by applying necessary patches, updates, and configurations to close any exploited vulnerabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement network hardening measures, such as segmenting the network, applying strict access controls, and regularly updating firewall rules, to prevent future incidents."""
 
diff --git a/rules/ml/ml_linux_anomalous_network_port_activity.toml b/rules/ml/ml_linux_anomalous_network_port_activity.toml
index 140a8bc735f..fa5b3410b31 100644
--- a/rules/ml/ml_linux_anomalous_network_port_activity.toml
+++ b/rules/ml/ml_linux_anomalous_network_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -80,4 +80,51 @@ tags = [
     "Rule Type: Machine Learning",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Linux Network Port Activity
+
+In Linux environments, network ports facilitate communication between applications and services. Adversaries may exploit rarely used ports for malicious activities like command-and-control or data exfiltration, bypassing standard monitoring. The 'Unusual Linux Network Port Activity' detection rule identifies anomalies in port usage, flagging potential unauthorized access or threat actor presence by focusing on atypical destination port activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific destination port and source IP address involved in the unusual activity.
+- Check historical logs to determine if the destination port has been used previously and if so, assess the frequency and context of its usage.
+- Correlate the source IP address with known assets or users within the organization to determine if the activity aligns with expected behavior.
+- Use Osquery to gather additional context on the host involved. For example, run the following query to list active network connections and identify processes using the unusual port:
+  ```sql
+  SELECT pid, name, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE local_port = <unusual_port>;
+  ```
+- Investigate the process identified in the previous step to determine its legitimacy by checking its executable path, hash, and associated user.
+- Analyze network traffic logs to identify any patterns or anomalies associated with the unusual port, such as repeated connections or data transfers.
+- Cross-reference the unusual port activity with threat intelligence feeds to check for known malicious indicators or patterns.
+- Examine system logs for any signs of compromise or suspicious activity around the time the unusual port activity was detected.
+- Verify if there are any recent changes or deployments on the host that could explain the unusual port activity, such as new software installations or updates.
+- Consult with relevant teams or personnel to gather additional context or insights regarding the unusual port activity, ensuring a comprehensive understanding of the situation.
+
+### False positive analysis
+
+- Known false positives may include legitimate applications or services that use non-standard ports for communication, such as custom internal tools or legacy systems that have not been updated to use standard ports.
+- Automated backup or monitoring solutions might use unusual ports for data transfer, which can trigger alerts if not properly documented or excluded.
+- Development and testing environments often experiment with different port configurations, leading to benign anomalies in port usage.
+- To manage these false positives, users can create exceptions for known and verified applications or services that consistently use specific non-standard ports.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the effectiveness of the detection rule.
+- Collaborate with network and system administrators to document and understand the purpose of unusual port usage within the organization, reducing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the unusual port activity by reviewing network logs and identifying the source and destination of the traffic.
+- Verify the legitimacy of the process or application using the unusual port by cross-referencing with known software and services.
+- If malicious activity is confirmed, terminate any suspicious processes and remove any unauthorized software or scripts.
+- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed network traffic and system events for future analysis and detection.
+- Integrate threat intelligence feeds and anomaly detection tools to improve the identification of unusual network activities.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are correctly set.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement network segmentation and access controls to limit the exposure of critical systems and reduce the risk of similar incidents in the future."""
 
diff --git a/rules/ml/ml_packetbeat_rare_server_domain.toml b/rules/ml/ml_packetbeat_rare_server_domain.toml
index 653e4cc3226..ff8e5dfc6c7 100644
--- a/rules/ml/ml_packetbeat_rare_server_domain.toml
+++ b/rules/ml/ml_packetbeat_rare_server_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -83,4 +83,47 @@ rule_id = "17e68559-b274-4948-ad0b-f8415bb31126"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Network Destination Domain Name
+
+Machine learning models analyze network traffic to identify domain names that deviate from typical patterns, flagging potential threats. Adversaries exploit this by using rare domains for malicious activities like phishing or command-and-control. The detection rule identifies these anomalies, alerting analysts to investigate potential security incidents.
+
+### Possible investigation steps
+
+- Review the alert details to identify the unusual domain name and the associated network activity, including timestamps and source IP addresses.
+- Cross-reference the unusual domain name with threat intelligence databases to check for any known associations with malicious activities.
+- Analyze the network traffic logs to determine the volume and frequency of requests to the unusual domain, looking for patterns that may indicate automated or scripted activity.
+- Investigate the source IP address to identify the device or user responsible for the network request, using asset management systems or endpoint detection and response (EDR) tools.
+- Use Osquery to gather additional context from the affected endpoint. For example, run the following query to list recent DNS queries made by the device: `SELECT name, COUNT(name) AS query_count FROM dns_queries GROUP BY name ORDER BY query_count DESC LIMIT 10;`
+- Check the endpoint's process execution logs to identify any suspicious processes that may have initiated the network request to the unusual domain.
+- Examine user activity logs to determine if the user associated with the source IP address engaged in any unusual behavior, such as clicking on phishing links or downloading suspicious files.
+- Review email logs for the user to identify any recent phishing attempts that may have led to the network request to the unusual domain.
+- Analyze any related alerts or incidents in the security information and event management (SIEM) system to identify potential correlations or patterns with other suspicious activities.
+- Consult with other analysts or teams to gather additional insights or context that may aid in understanding the significance of the unusual domain name and its potential impact.
+
+### False positive analysis
+
+- Legitimate business applications or services may use uncommon domain names for updates or communication, leading to false positives. Users should verify the domain's legitimacy and consider adding it to an allowlist if it is deemed safe.
+- Newly registered domains for legitimate purposes, such as marketing campaigns or new product launches, might trigger alerts. Users can monitor these domains for a period to ensure they are not associated with malicious activity before excluding them.
+- Internal development or testing environments often use unique domain names that could be flagged. Users should document these environments and exclude their domains from the detection rule to prevent unnecessary alerts.
+- Third-party services or APIs that are not widely recognized might be misidentified as threats. Users should confirm the service's authenticity and functionality, then create exceptions for these domains if they are verified as non-threatening.
+- Temporary or one-time use domains for legitimate purposes, such as event registrations or surveys, may cause false positives. Users should assess the context and frequency of access to these domains and exclude them if they are determined to be safe.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with the suspicious domain.
+- Conduct a thorough investigation of the system to identify any malicious processes or files, focusing on indicators of initial access, persistence, command-and-control, or exfiltration activities.
+- Analyze network logs and DNS queries to determine the scope of the incident and identify any other systems that may have communicated with the unusual domain.
+- Remove any identified malware or unauthorized software from the affected system and ensure all security patches are up to date.
+- Change passwords and credentials that may have been compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger attack campaign.
+- Implement enhanced logging and monitoring policies to capture detailed network and DNS activity for future investigations.
+- Integrate threat intelligence feeds to improve detection of rare or suspicious domains in real-time.
+- Restore the system to its operational state by verifying the integrity of critical files and applications, and ensure all security measures are re-enabled.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and prevent future incidents."""
 
diff --git a/rules/ml/ml_rare_destination_country.toml b/rules/ml/ml_rare_destination_country.toml
index 3f293cd15f6..2bb9293d248 100644
--- a/rules/ml/ml_rare_destination_country.toml
+++ b/rules/ml/ml_rare_destination_country.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -79,4 +79,48 @@ rule_id = "35f86980-1fb1-4dff-b311-3be941549c8d"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Traffic to Rare Destination Country
+
+The detection of network traffic to uncommon destination countries leverages machine learning to identify anomalies in network logs. Adversaries exploit this by directing traffic to servers in atypical locations for activities like data exfiltration or command-and-control communication. This detection rule flags such anomalies, helping analysts investigate potential threats that deviate from normal business operations.
+
+### Possible investigation steps
+
+- Review the alert details to identify the rare destination country and the associated network traffic logs.
+- Examine the source IP address and user account involved in the alert to determine if they are legitimate and expected within the network.
+- Check historical network logs to see if there have been previous connections to the same destination country from the same source IP or user account.
+- Analyze the time and frequency of the connections to the rare destination country to identify any patterns or anomalies.
+- Investigate the domain or IP address of the destination server to determine if it is associated with known malicious activity or threat actors.
+- Use Osquery to gather additional context on the source machine. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<destination IP>';`
+- Correlate the network traffic with other security events, such as endpoint detection alerts, to identify any related suspicious activities.
+- Check for any recent changes or unusual behavior in the user account or device associated with the alert, such as new software installations or configuration changes.
+- Consult threat intelligence sources to gather information on the rare destination country and any known threats or campaigns targeting that region.
+- Document all findings and observations to build a comprehensive understanding of the potential threat and to assist in further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Legitimate business operations may occasionally involve communication with servers in rare destination countries, such as when a company expands its operations internationally or engages with new global partners. These activities can trigger false positives.
+- Automated software updates or cloud services might route traffic through servers located in uncommon countries, leading to benign alerts.
+- Employees traveling internationally and accessing company resources from unusual locations can also result in false positives.
+- To manage these false positives, users can create exceptions for known and verified business activities that involve rare destination countries, ensuring these are documented and regularly reviewed.
+- Implementing a whitelist of trusted IP addresses or domains associated with legitimate services and partners can help reduce unnecessary alerts.
+- Regularly updating the list of known business-related destinations and incorporating feedback from network analysts can further refine the detection rule and minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further data exfiltration or communication with command-and-control servers.
+- Conduct a thorough investigation of the network logs to identify the scope of the anomaly and determine if other systems are affected.
+- Analyze the network traffic to the rare destination country to understand the nature of the communication and identify any malicious payloads or commands.
+- Review user activity and access logs to identify any unauthorized access or suspicious behavior that may have led to the anomaly.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
+- Implement enhanced logging policies to capture detailed network traffic data, including destination IP addresses and geolocation information, for future investigations.
+- Integrate threat intelligence feeds to correlate the detected anomaly with known threat actors or campaigns targeting similar organizations.
+- Restore affected systems to their operational state by removing any malicious software and applying necessary security patches.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and stricter access controls.
+- Update security awareness training for employees to recognize phishing attempts and other social engineering tactics that could lead to similar incidents."""
 
diff --git a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
index cc7adf6f4f9..1cc41bb91f9 100644
--- a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -85,6 +85,50 @@ tags = [
     "Tactic: Execution",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Windows Path Activity
+
+In corporate Windows environments, software is typically installed in standard directories, and deviations can signal potential threats. Adversaries exploit this by executing malware from non-standard paths like user or temporary directories, bypassing traditional security measures. The 'Unusual Windows Path Activity' rule detects such anomalies, flagging processes initiated from these atypical locations, thus aiding in identifying unauthorized or malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name, path, and user account associated with the unusual activity.
+- Check the process's parent process to understand how it was initiated, using fields like `parent_process_name` and `parent_process_id`.
+- Investigate the file path from which the process was executed to determine if it is a known or expected location for legitimate software.
+- Use Osquery to gather more information about the file, such as its hash, size, and creation date, with a query like: `SELECT path, md5, sha256, size, ctime FROM file WHERE path = '<unusual_path>';`.
+- Examine the file's metadata and digital signature to verify its authenticity and origin.
+- Cross-reference the process and file details with threat intelligence sources to check for known malicious indicators.
+- Analyze recent user activity on the system to identify any downloads or installations that coincide with the alert.
+- Review system logs for any network connections initiated by the process to external IP addresses or domains.
+- Check for any persistence mechanisms that may have been established by the process, such as registry modifications or scheduled tasks.
+- Consult with the user associated with the alert to gather additional context about their recent activities and any software installations they may have performed.
+
+### False positive analysis
+
+- Legitimate software updates: Some legitimate software may update themselves by downloading new versions to temporary directories before installation. Users can create exceptions for known update processes to prevent false positives.
+- Development environments: Developers often compile and test software in user directories, which can trigger alerts. Excluding specific development tools or directories used by developers can reduce unnecessary alerts.
+- Portable applications: These applications run from user directories without installation. Users should whitelist trusted portable applications to avoid false positives.
+- User-installed software: In some environments, users may have permission to install software in their own directories. Identifying and excluding these known applications can help manage alerts.
+- Automated scripts: Scheduled tasks or scripts that run from user directories for legitimate purposes can be flagged. Users should document and exclude these scripts to prevent false positives.
+- Security tools: Some security tools may execute from non-standard paths for scanning or remediation purposes. Whitelisting these tools can prevent them from being flagged as threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation to identify the process and its origin, using endpoint detection and response (EDR) tools to trace the execution path and any associated files.
+- Terminate any suspicious processes identified as originating from atypical directories, such as user or temporary folders.
+- Remove or quarantine any malicious files or scripts found during the investigation to prevent re-execution.
+- Review and analyze system logs to determine if there are any other indicators of compromise or related activities, leveraging MITRE ATT&CK framework for threat context.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is determined to be part of a larger attack campaign or if additional expertise is required.
+- Restore the system to its operational state by reinstalling affected software from trusted sources and applying the latest security patches.
+- Implement or enhance logging policies to capture detailed process execution data, focusing on atypical directories to improve future detection capabilities.
+- Integrate threat intelligence feeds and automated alerting systems to enhance the detection of similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting execution permissions in user and temporary directories."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/persistence_ml_windows_anomalous_service.toml b/rules/ml/persistence_ml_windows_anomalous_service.toml
index 63938309c94..f655f236beb 100644
--- a/rules/ml/persistence_ml_windows_anomalous_service.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,6 +82,47 @@ tags = [
     "Tactic: Persistence",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Windows Service
+Windows services are crucial for running background processes and applications. Adversaries exploit this by creating or modifying services to maintain persistence or execute unauthorized actions. The 'Unusual Windows Service' detection rule leverages machine learning to identify atypical services, flagging potential threats by comparing against known service baselines, thus aiding in early detection of malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific service name, service path, and the host where the unusual service was detected.
+- Check the service's creation or modification timestamp to determine when the service was installed or altered.
+- Investigate the service's executable path to verify its legitimacy and check for any known malicious file signatures or hashes.
+- Use Osquery to gather additional information about the service with a query like: `SELECT name, display_name, path, start_type, status FROM services WHERE name = '<service_name>';` to confirm its current state and configuration.
+- Cross-reference the service name and executable path against known good baselines or whitelists to identify any deviations.
+- Examine the parent process that created or modified the service to understand the context of its creation.
+- Analyze the user account under which the service is running to determine if it has the necessary privileges and if the account has been compromised.
+- Review recent system and security logs on the affected host for any related suspicious activities or anomalies around the time the service was created or modified.
+- Check for any network connections initiated by the service to identify potential command and control communication or data exfiltration.
+- Consult threat intelligence sources to see if the service name, path, or associated file hashes have been reported in any recent threat campaigns or advisories.
+
+### False positive analysis
+
+- Known false positives for the Unusual Windows Service rule often include legitimate software updates or installations that create temporary services, as well as custom in-house applications that are not widely recognized by the machine learning model.
+- To manage these false positives, users can create exceptions for specific services that are known to be safe and frequently appear in their environment. This can be done by maintaining a whitelist of approved services or by configuring the detection rule to ignore certain service names or patterns.
+- It's important to regularly review and update the list of exceptions to ensure that new legitimate services are not mistakenly flagged as threats, while also ensuring that the list does not become overly permissive, which could allow actual threats to go undetected.
+- Users should also consider the context of the flagged service, such as the time of day it was created or modified, the user account associated with the change, and any related network activity, to better assess whether it is a false positive or a potential threat.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized services.
+- Conduct a thorough investigation of the unusual service, including its origin, purpose, and any associated files or processes.
+- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
+- Remove or disable the unauthorized service and any associated files or registry entries to eliminate the threat.
+- Restore the system from a known good backup if the integrity of the system is in question.
+- Escalate the incident to the security operations team or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed information on service creation and modification activities for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for unusual service activities.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
index 6d718fc767f..fc6945554be 100644
--- a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
+++ b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 75
@@ -84,6 +84,52 @@ tags = [
     "Tactic: Privilege Escalation",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Sudo Activity
+
+Sudo allows users to execute commands with elevated privileges, essential for system administration. However, adversaries may exploit this by using compromised credentials to gain unauthorized access. The 'Unusual Sudo Activity' detection rule identifies anomalies in sudo usage patterns, flagging potential misuse by comparing current activity against typical user behavior, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to identify the user account involved in the unusual sudo activity and the specific command executed.
+- Check the timestamp of the activity to determine if it aligns with the user's typical working hours or if it occurred at an unusual time.
+- Analyze the user's historical sudo usage patterns to assess whether this activity deviates from their normal behavior.
+- Verify the source IP address and hostname from which the sudo command was executed to ensure it matches the user's known devices and locations.
+- Cross-reference the user's recent login history to identify any suspicious logins or anomalies around the time of the sudo activity.
+- Use Osquery to gather additional context on the system where the sudo command was executed. For example, run the following query to list recent sudo commands:
+  ```sql
+  SELECT uid, user, command, time FROM sudo_log WHERE user = '<username>';
+  ```
+- Investigate any recent changes to the user's account, such as password resets or modifications to group memberships, that could indicate account compromise.
+- Check for any other security alerts or logs related to the user or system around the same timeframe to identify potential correlated activities.
+- Review the system's audit logs for any unauthorized changes or suspicious activities that occurred before or after the unusual sudo command.
+- Consult with the user, if possible, to verify whether they performed the action and to gather additional context about the necessity and legitimacy of the command.
+
+### False positive analysis
+
+- Known false positives for the Unusual Sudo Activity rule often arise from legitimate administrative tasks performed by users who do not typically require elevated privileges, such as developers or support staff temporarily granted sudo access for troubleshooting.
+- Another common false positive occurs when system updates or maintenance scripts are executed by service accounts that do not usually perform such actions, leading to flagged activity.
+- To manage these false positives, users can create exceptions for specific user accounts or groups that are known to perform these tasks regularly, ensuring that their activity is not flagged as unusual.
+- Implementing a baseline of normal sudo activity for each user or role can help in distinguishing between legitimate and suspicious actions, reducing the likelihood of false positives.
+- Regularly reviewing and updating the list of exceptions and baselines is crucial, as user roles and responsibilities may change over time, potentially altering what constitutes normal sudo activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the sudo activity by contacting the user involved and reviewing their recent activities and access needs.
+- Conduct a thorough investigation of the system logs to identify any unauthorized changes or additional suspicious activities, focusing on the time frame of the unusual sudo activity.
+- Reset passwords for the affected user account and any other accounts that may have been compromised, ensuring the use of strong, unique passwords.
+- Escalate the incident to the security operations team if evidence of a broader compromise is found, such as multiple accounts affected or signs of data exfiltration.
+- Implement enhanced logging policies to capture detailed sudo command usage and user activity, ensuring logs are stored securely and retained for an appropriate period.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual sudo activity with known threat indicators and patterns.
+- Restore the system to its operational state by verifying the integrity of critical system files and configurations, and applying any necessary patches or updates.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Implement hardening measures such as enforcing the principle of least privilege, using multi-factor authentication, and regularly reviewing user access rights to minimize the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
index e996d8761c8..a48655d3f6f 100644
--- a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
+++ b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,6 +82,49 @@ tags = [
     "Tactic: Privilege Escalation",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Windows User Privilege Elevation Activity
+
+In Windows environments, privilege elevation is often achieved using tools like 'runas', typically by administrators. Adversaries exploit this by hijacking accounts to gain elevated access, posing risks of data breaches or system compromise. The detection rule leverages machine learning to identify atypical user context switches, flagging potential misuse indicative of account takeover or unauthorized privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account involved in the unusual privilege elevation activity.
+- Check the timestamp of the activity to correlate it with any known scheduled tasks or administrative activities.
+- Examine the source and destination IP addresses associated with the activity to determine if they are part of the organization's network or if they are external.
+- Investigate the command line used in the privilege elevation attempt, focusing on any unusual or suspicious parameters.
+- Analyze the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior.
+- Use Osquery to gather additional context on the system where the activity was detected. For example, run the following query to list recent processes executed by the user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
+- Check for any recent changes to the user's account, such as password resets or changes in group memberships, that could indicate account compromise.
+- Review system and security event logs for any additional suspicious activities around the time of the alert, such as failed login attempts or changes to security settings.
+- Investigate any other alerts or incidents involving the same user or system to identify potential patterns or related activities.
+- Consult with the user or their manager to verify if the activity was legitimate and authorized, ensuring to document any findings or explanations provided.
+
+### False positive analysis
+
+- Regular administrative tasks: Frequent use of the 'runas' command by legitimate domain or network administrators for routine maintenance can trigger false positives. Users can manage this by creating exceptions for known administrator accounts or specific tasks that are regularly performed.
+- Scheduled tasks or scripts: Automated scripts or scheduled tasks that require privilege elevation might be flagged. To handle this, users can whitelist these scripts or tasks by identifying their unique signatures or execution patterns.
+- Software updates or installations: Legitimate software updates or installations that require elevated privileges can be mistaken for suspicious activity. Users should consider excluding known update processes or installation paths from the detection rule.
+- Development and testing environments: Developers or testers might frequently switch user contexts to simulate different user roles, leading to false positives. In such cases, users can exclude specific development or testing environments from monitoring.
+- Third-party management tools: Some third-party tools that manage user accounts or perform administrative tasks might mimic privilege elevation activities. Users can address this by identifying and excluding these tools from the detection scope.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the privilege escalation, focusing on recent account activity and any anomalies in user behavior.
+- Reset passwords for compromised accounts and enforce multi-factor authentication (MFA) to prevent future unauthorized access.
+- Review and update user access controls, ensuring that only necessary privileges are granted to users based on their roles.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed user activity, including command execution and privilege changes, to aid in future investigations.
+- Integrate security information and event management (SIEM) tools with endpoint detection and response (EDR) solutions to improve threat detection and response capabilities.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary services, applying the principle of least privilege, and conducting regular security audits to reduce the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
diff --git a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
index e3878144a51..62da98d8b9b 100644
--- a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
+++ b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/08"
 
 [rule]
 anomaly_threshold = 50
@@ -85,6 +85,49 @@ tags = [
     "Tactic: Resource Development",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Anomalous Linux Compiler Activity
+
+Compilers transform source code into executable programs, a routine task in development environments. However, in atypical user contexts, such activity may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit compilers to deploy malware or execute exploits. The detection rule identifies unusual compiler usage patterns, flagging potential threats by monitoring deviations from normal user behavior.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user and host involved in the anomalous compiler activity.
+- Check the historical activity of the user to determine if compiler usage is indeed unusual for this user context.
+- Analyze the specific compiler command executed, including any flags or options, to understand the nature of the compilation.
+- Investigate the source code or files being compiled to assess if they are legitimate or potentially malicious.
+- Use Osquery to gather additional context on the host. For example, run the following query to list recent processes executed by the user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
+- Examine the file system for any newly created or modified executable files that may have resulted from the compilation.
+- Check for any recent privilege escalation attempts or suspicious activities in system logs that coincide with the compiler activity.
+- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern.
+- Verify the integrity and origin of the compiler binary used to ensure it has not been tampered with or replaced.
+- Consult threat intelligence sources to determine if the observed activity matches known tactics, techniques, or procedures (TTPs) associated with adversaries.
+
+### False positive analysis
+
+- Development environments or users who occasionally compile software for legitimate purposes may trigger false positives. To manage this, users can create exceptions for specific user accounts or directories known for regular development activities.
+- Automated build systems or continuous integration pipelines that compile code as part of their routine operations might be flagged. Exclude these systems by identifying their unique user accounts or IP addresses and adding them to an allowlist.
+- System updates or package installations that involve compiling components can also be mistaken for anomalous activity. Users should monitor and document regular update schedules and exclude these activities during known maintenance windows.
+- Educational or research environments where users compile code for learning or experimentation may generate alerts. Implement user-specific exceptions based on the context of their activities and the educational tools they use.
+- Temporary projects or one-time tasks that require compilation might be misinterpreted as threats. Users can temporarily disable the rule or add time-bound exceptions for these specific tasks to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
+- Conduct a thorough investigation to identify the source and scope of the anomalous compiler activity, reviewing logs and user activity to determine if it aligns with known threat patterns such as those described in MITRE ATT&CK T1588.
+- Verify the integrity of critical system files and executables to ensure they have not been altered or replaced by malicious versions.
+- Remove any unauthorized software or malware identified during the investigation, using trusted antivirus or anti-malware tools.
+- Reset credentials and review user permissions to ensure no unauthorized privilege escalations have occurred.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is linked to a broader attack campaign or if sensitive data may have been compromised.
+- Implement enhanced logging policies to capture detailed information on compiler usage and other potentially suspicious activities for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities against similar threats.
+- Restore the system to its operational state by applying verified backups and patches, ensuring all security updates are current.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and stricter access controls, to prevent recurrence."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
index d30f431fda5..e0344f36c68 100644
--- a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
+++ b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,49 @@ query = '''
         flow_terminated or timeout or Reject or network_flow)
     and destination.port:23
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Accepted Default Telnet Port Connection
+
+Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing adversaries to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that aren't blocked or terminated, which may indicate unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of Telnet traffic on port 23, focusing on the `destination.port` field to ensure it matches the expected port for Telnet.
+- Examine the `event.dataset` and `event.category` fields to understand the context of the network traffic and confirm it is related to network flow or traffic.
+- Check the `event.type` field to verify that the event is categorized as a connection, indicating an active Telnet session attempt.
+- Investigate the `event.action` field to ensure that the connection was not blocked or terminated, which could suggest a successful unauthorized access attempt.
+- Identify the source and destination IP addresses involved in the connection to determine if they are known or expected within the network environment.
+- Use Osquery to gather more information about the systems involved. For example, run the following query to list active network connections on the potentially compromised host: `SELECT * FROM process_open_sockets WHERE remote_port = 23;`
+- Analyze historical network traffic logs to identify any patterns or repeated attempts to connect via Telnet from the same source IP address.
+- Correlate the Telnet connection event with other security events or logs to identify any related suspicious activities, such as failed login attempts or unusual user account behavior.
+- Investigate the user accounts involved in the Telnet session to determine if they have been compromised or are being used in an unauthorized manner.
+- Review the configuration and patch status of the systems involved to assess their vulnerability to exploitation via Telnet and ensure they are not inadvertently exposed to the internet.
+
+### False positive analysis
+
+- **Legacy Systems and Devices**: Some organizations may still use legacy systems or network devices that rely on Telnet for management purposes. These systems can generate legitimate Telnet traffic that is mistakenly flagged as suspicious. Users should identify these systems and create exceptions for their IP addresses or hostnames to prevent false positives.
+- **Internal Network Management**: In certain environments, Telnet might be used internally for network management tasks. If these activities are verified as secure and necessary, users can exclude specific internal IP ranges from the detection rule to reduce false alerts.
+- **Testing and Development Environments**: Telnet might be used in controlled testing or development environments where security risks are mitigated. Users should document these environments and apply exceptions to avoid unnecessary alerts.
+- **Automated Scripts and Tools**: Some automated scripts or network management tools might use Telnet for legitimate purposes. Users should review these tools and, if deemed safe, whitelist their traffic to minimize false positives.
+- **Vendor-Specific Implementations**: Certain vendors may implement Telnet in a way that is secure within a closed network. Users should assess these implementations and, if they meet security standards, exclude them from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the Telnet connection, including reviewing logs and network traffic for any suspicious activity.
+- Change all passwords associated with the affected system and any other systems that may have been accessed using the same credentials.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement network segmentation to limit the exposure of legacy systems and ensure Telnet is not accessible from the internet.
+- Disable Telnet services on all systems where it is not absolutely necessary, and replace it with secure alternatives like SSH.
+- Enhance logging policies to ensure all network traffic, especially on critical ports like 23, is monitored and logged for future analysis.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the affected system from a known good backup to ensure no malicious code remains.
+- Apply system hardening measures, such as disabling unnecessary services and applying the latest security patches, to reduce the risk of future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_cobalt_strike_beacon.toml b/rules/network/command_and_control_cobalt_strike_beacon.toml
index be14096630a..b6628c96e38 100644
--- a/rules/network/command_and_control_cobalt_strike_beacon.toml
+++ b/rules/network/command_and_control_cobalt_strike_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,52 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Cobalt Strike Command and Control Beacon"
-note = """## Threat intel
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Cobalt Strike Command and Control Beacon
+
+Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using obfuscated network traffic. The detection rule identifies suspicious domain patterns typical of Cobalt Strike beacons, focusing on specific network events and domain structures indicative of C2 activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific network event and domain pattern that triggered the rule, focusing on the `destination.domain` field for suspicious domain structures.
+- Examine the network traffic logs associated with the alert, particularly those categorized under `event.category: network` or `network_traffic`, and `type: tls` or `http`, to identify any unusual patterns or anomalies.
+- Cross-reference the `destination.domain` with known malicious domains or threat intelligence feeds to determine if it has been previously associated with Cobalt Strike or other malicious activities.
+- Use Osquery to gather additional context on the affected host. For example, run the following query to list all network connections on the host: `SELECT * FROM process_open_sockets WHERE remote_address LIKE '%stage.%';`
+- Investigate the process responsible for the network connection by correlating the `process.pid` from the Osquery results with process execution logs to identify the parent process and any associated command-line arguments.
+- Analyze historical network traffic to determine if the suspicious domain has been contacted previously, indicating a potential ongoing C2 communication.
+- Check for any other alerts or logs related to the same `destination.domain` or IP address to assess the scope and potential impact of the activity.
+- Review endpoint security logs for any signs of suspicious activity or indicators of compromise on the affected host, such as unusual process executions or file modifications.
+- Investigate user activity on the affected host around the time of the alert to identify any unauthorized access or actions that may have facilitated the C2 communication.
+- Consult with threat intelligence teams or resources to gather additional insights or context about the specific Cobalt Strike variant or campaign potentially involved in the alert.
+
+### False positive analysis
+
+- Legitimate software updates or patch management systems may generate network traffic patterns similar to Cobalt Strike beacons, especially if they use automated scripts or tools that follow a predictable domain structure.
+- Content delivery networks (CDNs) and cloud services often use domain names that match the pattern detected by the rule, leading to potential false positives when these services are accessed frequently.
+- Internal development or testing environments might use domain naming conventions that inadvertently match the suspicious pattern, particularly if they employ automated deployment or staging processes.
+- To manage these false positives, users can create exceptions for known benign domains or IP addresses that consistently trigger the rule but are verified as non-threatening.
+- Implementing a whitelist of trusted domains or services can help reduce noise from false positives, allowing security teams to focus on genuine threats.
+- Regularly reviewing and updating the list of exceptions is crucial to ensure that new legitimate services are not mistakenly flagged as malicious.
+
+### Response and remediation
+
+- Isolate the affected systems from the network to prevent further communication with the command and control server.
+- Conduct a thorough investigation to identify the scope of the compromise, including all affected systems and data.
+- Utilize endpoint detection and response (EDR) tools to analyze and remove Cobalt Strike beacons and any associated malware.
+- Review and analyze network traffic logs to identify any additional indicators of compromise (IOCs) and ensure no other systems are affected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed network and endpoint activity for future investigations.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
+- Restore affected systems from clean backups and ensure all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement network segmentation and hardening measures to reduce the attack surface and prevent similar incidents.
+
+## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
index 6086b36e1b0..de596cf9df8 100644
--- a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
+++ b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/05"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,50 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Default Cobalt Strike Team Server Certificate"
-note = """## Threat intel
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Default Cobalt Strike Team Server Certificate
+
+Cobalt Strike is a tool used for simulating advanced cyber threats, often employed in security testing. However, adversaries can exploit its default server certificate to establish covert command and control channels. The detection rule identifies this misuse by monitoring network traffic for specific cryptographic hashes associated with the default certificate, flagging potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the default Cobalt Strike Team Server Certificate by checking the cryptographic hashes: MD5, SHA1, and SHA256.
+- Correlate the alert with other network traffic logs to identify the source and destination IP addresses involved in the communication.
+- Use Packetbeat or a similar tool to capture and analyze the network packets associated with the alert to understand the context of the communication.
+- Investigate the source IP address to determine if it belongs to a known or trusted entity within the organization or if it is an external or suspicious address.
+- Check historical logs to see if the same cryptographic hashes have been detected previously, indicating a persistent or recurring issue.
+- Utilize Osquery to gather more information about the systems involved. For example, run the following query to check for any suspicious processes or network connections on the host: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%cobalt%' OR cmdline LIKE '%cobalt%';`
+- Examine the destination IP address for any known associations with malicious activities or threat actor infrastructure.
+- Investigate any related user accounts or credentials that may have been used in the communication to assess potential compromise.
+- Review any associated DNS queries or domain names to identify if they are linked to known malicious domains or C2 infrastructure.
+- Cross-reference the alert with threat intelligence feeds to determine if the detected activity aligns with known threat actor tactics, techniques, and procedures (TTPs).
+
+### False positive analysis
+
+- Legitimate security testing activities: Organizations conducting authorized penetration tests or red team exercises may use Cobalt Strike with its default server certificate, triggering the detection rule. Users should verify the legitimacy of such activities and consider excluding known testing IP addresses or domains from the rule to prevent false positives.
+- Misconfigured security tools: Some security tools or network monitoring solutions might inadvertently use the default Cobalt Strike certificate for testing or demonstration purposes. Users should ensure these tools are correctly configured and exclude their traffic from the rule if necessary.
+- Internal training environments: Training environments that simulate cyber threats for educational purposes might use the default certificate. Users can manage this by creating exceptions for specific training network segments or IP ranges.
+- Legacy systems or software: Older systems or software that have not been updated might still use the default certificate for compatibility reasons. Users should identify these systems and either update them or exclude their traffic from the detection rule to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further command and control communication.
+- Conduct a thorough investigation to confirm the presence of Cobalt Strike by analyzing network traffic and system logs for the identified cryptographic hashes.
+- Remove any unauthorized Cobalt Strike installations and associated malicious files from the affected systems.
+- Change all credentials and access tokens that may have been compromised during the incident.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response coordination.
+- Implement enhanced logging policies to capture detailed network traffic and system events, focusing on TLS connections and certificate usage.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
+- Restore affected systems from clean backups and ensure all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement network segmentation and application whitelisting to reduce the attack surface and prevent unauthorized software execution.
+
+## Threat intel
 
 While Cobalt Strike is intended to be used for penetration tests and IR training, it is frequently used by actual threat actors (TA) such as APT19, APT29, APT32, APT41, FIN6, DarkHydrus, CopyKittens, Cobalt Group, Leviathan, and many other unnamed criminal TAs. This rule uses high-confidence atomic indicators, so alerts should be investigated rapidly."""
 references = [
diff --git a/rules/network/command_and_control_download_rar_powershell_from_internet.toml b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
index 353a1460eec..8a4d24846e8 100644
--- a/rules/network/command_and_control_download_rar_powershell_from_internet.toml
+++ b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,54 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*",
 language = "kuery"
 license = "Elastic License v2"
 name = "Roshal Archive (RAR) or PowerShell File Downloaded from the Internet"
-note = """## Threat intel
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet
+
+RAR files and PowerShell scripts are powerful tools in IT environments, used for compression and automation, respectively. However, adversaries exploit these by downloading them from the internet to deploy malicious payloads or scripts. The detection rule identifies such downloads by monitoring network traffic for specific file extensions and filtering out internal IP addresses, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the source IP address and destination IP address involved in the download event. Verify if the source IP is within the internal network ranges specified in the query.
+- Check the URL extension or path to confirm whether the downloaded file is a RAR or PowerShell script, as indicated by the extensions `.ps1` or `.rar`.
+- Analyze network traffic logs to determine the volume and frequency of similar download events from the same source IP. This can help identify patterns or repeated behavior.
+- Investigate the destination IP address to determine if it is associated with known malicious activity or if it is an unusual destination for the internal network.
+- Use Osquery to gather more information about the host that initiated the download. For example, run the following query to list recent files downloaded to the system:
+  ```sql
+  SELECT * FROM file WHERE path LIKE '/path/to/downloads/%' AND (path LIKE '%.ps1' OR path LIKE '%.rar');
+  ```
+- Examine the process tree on the source host to identify the parent process that initiated the download. This can provide context on whether the download was user-initiated or automated by a script or application.
+- Check for any recent changes in the system's scheduled tasks or startup items that might indicate persistence mechanisms related to the downloaded file.
+- Review endpoint security logs for any alerts or detections related to the downloaded file, such as antivirus or EDR alerts, which might provide additional context or confirm malicious intent.
+- Correlate the event with other security alerts or incidents in the same timeframe to identify potential lateral movement or coordinated attacks.
+- Consult threat intelligence sources to gather information on the file hash or URL, if available, to determine if it is associated with known threats or campaigns.
+
+### False positive analysis
+
+- Legitimate software updates: Many software applications use RAR files or PowerShell scripts for updates or installations, which can trigger false positives. Users can create exceptions for known software update servers or domains to reduce these alerts.
+- Internal IT automation: IT departments often use PowerShell scripts for legitimate automation tasks. Monitoring and documenting these scripts can help differentiate between benign and malicious activity, allowing for specific exceptions to be made.
+- Backup and archival processes: Organizations may use RAR files for backup or archival purposes. Identifying and excluding these routine operations from the detection rule can help minimize false positives.
+- Development and testing environments: Developers might download RAR files or use PowerShell scripts for testing purposes. Establishing a list of trusted IP addresses or domains associated with development activities can help in excluding these from alerts.
+- Security tools and penetration testing: Security teams may use RAR files or PowerShell scripts as part of penetration testing or security assessments. Whitelisting known security tools and their associated IP addresses can prevent these activities from being flagged as threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Conduct a thorough investigation of the downloaded RAR or PowerShell file to determine its origin and intent, using sandboxing or static analysis tools.
+- Review network logs and endpoint security alerts to identify any lateral movement or additional compromised systems.
+- Remove any malicious files or scripts identified during the investigation from the affected system.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Restore the system from a clean backup if the integrity of the system is compromised beyond repair.
+- Implement enhanced logging policies to capture detailed network traffic and endpoint activity for future incidents.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Educate users on the risks of downloading files from untrusted sources and enforce stricter download policies.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign, referencing MITRE ATT&CK T1105 for context on ingress tool transfer tactics.
+
+## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_halfbaked_beacon.toml b/rules/network/command_and_control_halfbaked_beacon.toml
index db956efc006..62acaa8e6ed 100644
--- a/rules/network/command_and_control_halfbaked_beacon.toml
+++ b/rules/network/command_and_control_halfbaked_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,51 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Halfbaked Command and Control Beacon"
-note = """## Threat intel
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Halfbaked Command and Control Beacon
+
+Halfbaked malware exploits common network protocols like HTTP and TLS to maintain persistence and facilitate command and control (C2) communication within compromised networks. Adversaries leverage these protocols to blend malicious traffic with legitimate network activity, evading detection. The detection rule identifies suspicious TCP traffic patterns, specifically targeting HTTP requests to numeric IP addresses on common ports, indicative of Halfbaked C2 beacons.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious TCP traffic patterns, focusing on HTTP requests to numeric IP addresses on ports 53, 80, 8080, or 443.
+- Analyze the network traffic logs to identify the source and destination IP addresses involved in the suspicious activity, paying close attention to the `url.full` field for patterns matching `/http:\\/\\/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}\\/cd/`.
+- Correlate the identified IP addresses with known threat intelligence sources to determine if they are associated with malicious activity or known Halfbaked C2 infrastructure.
+- Examine the `event.dataset` and `event.category` fields to verify if the traffic is categorized under `network_traffic.tls` or `network_traffic.http`, which may indicate the use of common protocols for C2 communication.
+- Use Osquery to gather additional context on the affected host. For example, run the following query to list all network connections on the host: `SELECT * FROM process_open_sockets WHERE remote_address IN ('<suspicious_ip>');`.
+- Investigate the processes associated with the suspicious network connections by examining the process IDs and command lines to identify any unusual or unauthorized applications.
+- Check for any persistence mechanisms on the host that may be related to the Halfbaked malware, such as scheduled tasks or startup items, using Osquery: `SELECT * FROM scheduled_tasks WHERE name LIKE '%Halfbaked%';`.
+- Review historical network traffic data to determine if similar patterns of communication have occurred in the past, indicating a potential ongoing compromise.
+- Analyze any related alerts or logs from other security tools to gather additional context and corroborate the findings from the Halfbaked alert.
+- Document all findings and observations in a detailed report to support further analysis and decision-making by the security team.
+
+### False positive analysis
+
+- Legitimate applications or services that use numeric IP addresses in their HTTP requests can trigger false positives. For example, internal tools or monitoring systems that communicate with devices using IP addresses instead of domain names may be flagged.
+- Automated scripts or legacy systems that rely on numeric IP addresses for communication over common ports (53, 80, 8080, 443) might also be mistakenly identified as malicious.
+- To manage these false positives, users can create exceptions for known benign IP addresses or specific applications that are verified to use numeric IP addresses for legitimate purposes.
+- Regularly review and update the list of exceptions to ensure that only trusted sources are excluded, minimizing the risk of overlooking genuine threats.
+- Implement network segmentation and monitoring to distinguish between expected and unexpected traffic patterns, helping to refine detection rules and reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected systems from the network to prevent further communication with the command and control server.
+- Conduct a thorough investigation of the affected systems to identify the extent of the compromise and any additional indicators of compromise (IOCs).
+- Remove the Halfbaked malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools.
+- Apply patches and updates to all systems to address any vulnerabilities that may have been exploited by the malware.
+- Review and enhance firewall rules to block outbound traffic to known malicious IP addresses and domains associated with Halfbaked C2 activity.
+- Implement network segmentation to limit lateral movement within the network and protect critical assets.
+- Enable detailed logging of network traffic, especially for HTTP and TLS protocols, to improve detection of similar threats in the future.
+- Integrate threat intelligence feeds into security information and event management (SIEM) systems to stay informed about emerging threats and IOCs.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate employees on recognizing phishing attempts and other common attack vectors used to deliver malware like Halfbaked.
+
+## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_nat_traversal_port_activity.toml b/rules/network/command_and_control_nat_traversal_port_activity.toml
index f61786952a2..360e700f00a 100644
--- a/rules/network/command_and_control_nat_traversal_port_activity.toml
+++ b/rules/network/command_and_control_nat_traversal_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,49 @@ type = "query"
 query = '''
 (event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and network.transport:udp and destination.port:4500
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 IPSEC NAT Traversal Port Activity
+
+IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC traffic in UDP packets, typically using port 4500. While essential for legitimate encrypted connections, adversaries exploit this to mask malicious traffic, evading detection. The detection rule identifies unusual UDP traffic on port 4500, flagging potential misuse of this technology for covert command and control activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the source and destination IP addresses, timestamps, and any associated user or device information.
+- Verify the legitimacy of the source and destination IP addresses by cross-referencing them with known internal assets or external threat intelligence sources.
+- Analyze historical network traffic logs to identify any patterns or anomalies associated with the source or destination IP addresses, focusing on previous instances of UDP traffic on port 4500.
+- Use Osquery to gather additional context on the involved systems. For example, run the following query to check for active IPSEC connections: `SELECT * FROM ipsec_status;`
+- Investigate the user or device associated with the alert to determine if there are any signs of compromise or unusual behavior, such as recent changes in user activity or system configurations.
+- Check for any other alerts or incidents related to the same source or destination IP addresses to identify potential correlations or patterns of malicious activity.
+- Examine the network flow data to determine the volume and frequency of the UDP traffic on port 4500, assessing whether it aligns with typical IPSEC NAT Traversal usage or suggests potential misuse.
+- Review firewall and intrusion detection/prevention system logs to identify any blocked or flagged traffic related to the source or destination IP addresses, which may provide additional context on the nature of the traffic.
+- Consult with network administrators to confirm whether the observed IPSEC NAT Traversal traffic is expected and authorized, particularly if the involved systems are part of known VPN configurations.
+- Document all findings and observations, including any identified anomalies or suspicious activities, to support further analysis and potential escalation if necessary.
+
+### False positive analysis
+
+- Legitimate VPN traffic: Many organizations use IPSEC NAT Traversal for secure VPN connections, which can generate expected UDP traffic on port 4500. This is a common false positive and should be considered when analyzing alerts.
+- Frequent remote access: Employees working remotely may frequently use VPNs that rely on IPSEC NAT Traversal, leading to regular traffic on port 4500. Monitoring patterns and establishing a baseline can help differentiate between normal and suspicious activity.
+- Automated network services: Some automated services or applications may use IPSEC NAT Traversal for legitimate purposes, resulting in consistent traffic that could be misinterpreted as malicious.
+- To manage false positives, users can create exceptions for known IP addresses or subnets associated with legitimate VPN endpoints. This can be done by updating the detection rule to exclude these trusted sources.
+- Regularly review and update the list of exceptions to ensure it reflects current network configurations and legitimate use cases, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further malicious activity and data exfiltration.
+- Conduct a thorough investigation of the flagged traffic to determine if it is legitimate or indicative of a compromise, using packet analysis tools to inspect the contents of the UDP traffic on port 4500.
+- Review and analyze logs from firewalls, intrusion detection systems, and VPN gateways to identify any patterns or anomalies associated with the suspicious IPSEC NAT Traversal traffic.
+- If malicious activity is confirmed, identify and remove any malware or unauthorized software from the affected systems using updated antivirus and anti-malware tools.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed network traffic data, focusing on VPN and NAT traversal activities, to improve future detection capabilities.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and enrich data for more effective threat detection and response.
+- Restore affected systems from clean backups, ensuring that all security patches and updates are applied to prevent exploitation of known vulnerabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement network segmentation and access controls to limit the potential impact of future incidents and reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_port_26_activity.toml b/rules/network/command_and_control_port_26_activity.toml
index 2a01401278b..b19d886482c 100644
--- a/rules/network/command_and_control_port_26_activity.toml
+++ b/rules/network/command_and_control_port_26_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,49 @@ type = "query"
 query = '''
 (event.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:26
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SMTP on Port 26/TCP
+
+SMTP, typically operating on port 25, is crucial for email transmission. However, port 26 is often used to avoid conflicts or restrictions on port 25. Adversaries exploit this by using port 26 for covert command and control, as seen with the BadPatch malware. The detection rule identifies suspicious activity by monitoring TCP traffic on port 26, focusing on network flow and SMTP-related events, thus helping to uncover potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of SMTP traffic on TCP port 26 by examining the `destination.port` field.
+- Analyze the `event.dataset` field to determine if the traffic is associated with `network_traffic.flow` or `zeek.smtp`, which can provide insights into the nature of the traffic.
+- Check the `event.category` field for values like `network` or `network_traffic` to understand the context of the event.
+- Investigate the source and destination IP addresses involved in the alert to identify any known malicious actors or unusual communication patterns.
+- Use network flow data to assess the volume and frequency of SMTP traffic on port 26, looking for anomalies or spikes in activity.
+- Correlate the alert with other security events or logs to identify any related suspicious activities or patterns.
+- Examine historical data to determine if this behavior is new or part of a recurring pattern, which might indicate a persistent threat.
+- Utilize Osquery to gather additional context from the affected systems. For example, run the following Osquery query to check for processes listening on port 26: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM listening_ports WHERE port = 26 AND protocol = 'tcp');`
+- Investigate any associated user accounts or credentials that may have been used in the communication to identify potential compromise or misuse.
+- Consult threat intelligence sources to check for any known indicators of compromise (IOCs) related to the IP addresses, domains, or other artifacts observed in the alert.
+
+### False positive analysis
+
+- Legitimate mail transfer agents: Some organizations use port 26 for legitimate email traffic to avoid conflicts with port 25. This can result in false positives when these agents are detected by the rule.
+- Internal testing environments: Development or testing environments may use port 26 for SMTP traffic, leading to benign alerts.
+- Network misconfigurations: Misconfigured network devices or services might inadvertently use port 26, triggering the rule without malicious intent.
+- To manage these false positives, users can create exceptions for known IP addresses or domains associated with legitimate mail transfer agents or internal environments.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further command and control communication.
+- Conduct a thorough investigation of the network traffic logs to identify any other systems that may be communicating over port 26.
+- Utilize endpoint detection and response (EDR) tools to scan the affected system for the presence of BadPatch malware or any other suspicious activity.
+- Remove any identified malware from the affected system using updated antivirus or anti-malware tools.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed network traffic and SMTP-related events for future investigations.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are properly set.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement network segmentation and access controls to limit the use of non-standard ports and reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
index e9e59ab3aeb..da8e8be7a19 100644
--- a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
+++ b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,49 @@ query = '''
     192.168.0.0/16
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 RDP (Remote Desktop Protocol) from the Internet
+
+RDP enables remote access to systems, facilitating administrative tasks and resource sharing. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit RDP for initial access or persistence. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from non-private IPs, flagging potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the source IP address is indeed from a non-private range, as specified in the query, and verify if it is known or expected to access the network.
+- Check historical logs for any previous connections from the same source IP to determine if this is a recurring event or a new occurrence.
+- Analyze the destination IP address within the private range to identify the specific system being accessed and determine its role and importance within the network.
+- Investigate the user accounts associated with the RDP session to ensure they are legitimate and authorized to access the system remotely.
+- Utilize Osquery to gather more information about the RDP service on the destination machine. For example, run the following query to list active RDP sessions: `SELECT * FROM logged_in_users WHERE tty = 'rdp-tcp';`
+- Examine the network traffic logs for any unusual patterns or anomalies around the time of the alert, such as large data transfers or connections to other suspicious IP addresses.
+- Cross-reference the alert with any recent changes or updates to the system or network configuration that might explain the RDP exposure.
+- Check for any other security alerts or incidents involving the same source or destination IP addresses to identify potential patterns or coordinated attacks.
+- Review the system's security settings and logs for any signs of compromise, such as unauthorized changes to firewall rules or user account settings.
+- Consult threat intelligence sources to determine if the source IP address or any related indicators are associated with known malicious activity or threat actors.
+
+### False positive analysis
+
+- **Internal Testing and Monitoring**: Organizations may conduct legitimate RDP sessions from external IPs for testing or monitoring purposes. To manage this, users can create exceptions for known IP addresses used by their IT or security teams.
+- **Third-Party Vendors**: Some businesses rely on third-party vendors for remote support or maintenance, which may involve RDP access from external IPs. Users should whitelist the IP addresses of trusted vendors to prevent false positives.
+- **Remote Workforce**: Employees working remotely might use RDP to access internal resources. If these connections are from known and secure locations, their IPs can be added to an exception list.
+- **Cloud Services**: Connections from cloud service providers might be flagged if they are not part of the internal network. Users should identify and exclude IP ranges associated with their cloud services to avoid false alerts.
+- **VPN Misconfigurations**: If a VPN is not properly configured, RDP traffic might appear to originate from an external IP. Ensuring correct VPN setup and excluding known VPN IPs can help mitigate this issue.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Verify the alert by checking logs and network traffic to confirm the presence of unauthorized RDP connections.
+- Change all passwords associated with the affected system and any accounts that may have been compromised.
+- Conduct a thorough investigation to identify the source of the unauthorized access and any potential lateral movement within the network.
+- Remove any unauthorized users or backdoors that may have been installed by the attacker.
+- Restore the system from a known good backup to ensure no malicious software remains.
+- Implement network segmentation to limit RDP access to only necessary internal IP addresses.
+- Enable and configure logging for RDP access attempts and integrate with a Security Information and Event Management (SIEM) system for real-time monitoring.
+- Apply security patches and updates to the affected system and ensure all systems are regularly updated.
+- Review and update firewall rules to block RDP traffic from the internet and consider using a VPN for secure remote access."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
index db915e0a059..ec782d37792 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,52 @@ query = '''
     192.168.0.0/16
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 VNC (Virtual Network Computing) from the Internet
+
+VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC to establish backdoors or gain initial access. The detection rule identifies suspicious VNC traffic by monitoring TCP connections on specific ports, filtering out trusted internal IPs, and flagging external sources attempting to connect to internal networks.
+
+### Possible investigation steps
+
+- Review the alert details to identify the source IP address attempting to connect to the internal network. Verify if the source IP is external and not part of the trusted internal IP ranges specified in the detection rule.
+- Check the destination IP address within the internal network to determine which system is being targeted. Confirm if this system is expected to have VNC services running.
+- Analyze the destination port (between 5800 and 5810) to verify if it corresponds to a known VNC service. Cross-reference with internal documentation to ensure this port is intended for VNC use.
+- Investigate the network traffic flow by examining the event dataset and category fields to understand the context of the connection attempt. Determine if there are any patterns or anomalies in the traffic.
+- Use Osquery to gather more information about the targeted system. Execute the following query to check for active VNC processes:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%vnc%';
+  ```
+- Review historical logs to identify any previous connection attempts from the same source IP address. Determine if this is part of a larger pattern of suspicious activity.
+- Correlate the alert with other security events or alerts to identify potential coordinated attacks or related incidents.
+- Check for any recent changes in firewall or network configurations that might have inadvertently exposed VNC services to the Internet.
+- Investigate user activity on the targeted system around the time of the alert to identify any unauthorized access or suspicious behavior.
+- Consult threat intelligence sources to gather information about known threat actors or campaigns that exploit VNC services, and assess if the observed activity matches any known patterns.
+
+### False positive analysis
+
+- **Internal Testing and Maintenance**: Organizations may conduct legitimate VNC testing or maintenance from external IPs, which can trigger the rule. To manage this, users can create exceptions for known testing IP addresses or timeframes.
+- **Third-Party Vendors**: External vendors may require VNC access for support or maintenance. Users should whitelist these vendor IPs after verifying their legitimacy and ensuring proper security measures are in place.
+- **Remote Workforce**: Employees working remotely might use VNC to access internal resources. To handle this, organizations can establish VPNs or secure gateways, and exclude these connections from the rule.
+- **Cloud Services**: Connections from cloud service providers might be flagged if they are used for legitimate purposes. Users should identify and exclude trusted cloud IP ranges to prevent false positives.
+- **Dynamic IP Addresses**: Some legitimate users may have dynamic IP addresses that change frequently, causing repeated false positives. Implementing a dynamic IP management strategy or using a secure access solution can help mitigate this issue.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any unauthorized access or changes made to the system.
+- Review and analyze network logs to trace the source of the VNC traffic and identify any other systems that may have been targeted or compromised.
+- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials.
+- Apply security patches and updates to the VNC software and any other vulnerable applications on the affected system.
+- Implement network segmentation to limit the exposure of critical systems to the Internet and restrict VNC access to trusted internal networks only.
+- Enhance logging and monitoring policies to capture detailed network traffic and system events, enabling quicker detection of similar threats in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve the detection and response capabilities for VNC-related threats.
+- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all security patches are applied before reconnecting to the network.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans, incorporating lessons learned to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
index f7f629214dd..04e52b37511 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,50 @@ query = '''
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 VNC (Virtual Network Computing) to the Internet
+
+VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC for initial access or as a backdoor. The detection rule identifies suspicious VNC traffic by monitoring TCP connections on specific ports from private to public IPs, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the source and destination IP addresses involved in the suspicious VNC traffic. Pay special attention to the source IP to determine if it belongs to a known internal system.
+- Verify the destination IP address to ascertain if it is a known or trusted external entity, or if it appears suspicious or unknown.
+- Check the destination port (between 5800 and 5810) to confirm it aligns with typical VNC usage, as these ports are commonly used for VNC services.
+- Investigate the source IP address within internal network logs to determine if there are any other unusual or unauthorized activities associated with this IP.
+- Use Osquery to check for VNC server processes running on the source machine. Example query: `SELECT name, path, pid FROM processes WHERE name LIKE '%vnc%';`
+- Examine historical network traffic logs to identify any previous instances of VNC traffic from the same source IP to external destinations, which might indicate a pattern of unauthorized access attempts.
+- Correlate the alert with any recent changes or updates in the network or system configurations that might have inadvertently exposed VNC services to the Internet.
+- Investigate user activity on the source machine to determine if any legitimate user actions could have triggered the VNC traffic, such as remote work or maintenance tasks.
+- Check for any known vulnerabilities or exploits related to the VNC software version running on the source machine, which could have been targeted by attackers.
+- Consult threat intelligence sources to see if the destination IP or similar VNC traffic patterns have been associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate remote work scenarios: Employees working remotely may use VNC to access their office computers. This can be a false positive if the access is authorized and secure. To manage this, create exceptions for known employee IP addresses or VPN ranges.
+- Third-party vendor access: Vendors may require VNC access for system maintenance or support. If this access is pre-approved and monitored, it can be excluded by whitelisting the vendor's IP addresses.
+- Internal testing and development: IT teams might use VNC for testing purposes, which could trigger alerts. Document and exclude these activities by specifying the IP ranges used for testing environments.
+- Misconfigured network devices: Devices that are incorrectly configured to expose VNC to the Internet might generate false positives. Regularly audit and correct device configurations to prevent unnecessary alerts.
+- Cloud-based services: Some cloud services might use VNC for legitimate purposes. Identify and whitelist these services' IP addresses to avoid false positives.
+- Temporary remote access setups: Occasionally, temporary VNC access might be set up for specific projects. Ensure these are documented and create temporary exceptions for the duration of the project.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the affected system to identify any unauthorized changes or installed backdoors, leveraging forensic tools and techniques.
+- Review and analyze network logs to trace the source of the VNC traffic and identify any other potentially compromised systems.
+- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials.
+- Apply security patches and updates to the affected system and ensure that VNC services are configured securely, including disabling direct Internet exposure.
+- Implement network segmentation to limit the exposure of critical systems and services to the Internet.
+- Enhance logging and monitoring policies to include detailed logging of remote access attempts and integrate with a Security Information and Event Management (SIEM) system for real-time analysis.
+- Escalate the incident to the security team or incident response team for further analysis and to determine if additional systems are affected.
+- Restore the system to its operational state from a known good backup, ensuring that all security measures are in place before reconnecting to the network.
+- Conduct a post-incident review to identify gaps in security controls and update the incident response plan, incorporating lessons learned and hardening measures such as disabling unused services and enforcing strong authentication mechanisms."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_network_sweep_detected.toml b/rules/network/discovery_potential_network_sweep_detected.toml
index 1f4a3572f07..6c72287f691 100644
--- a/rules/network/discovery_potential_network_sweep_detected.toml
+++ b/rules/network/discovery_potential_network_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,48 @@ query = '''
 destination.port : (21 or 22 or 23 or 25 or 139 or 445 or 3389 or 5985 or 5986) and
 source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Network Sweep Detected
+
+Network sweeps are reconnaissance techniques where attackers scan networks to identify active hosts and services, often targeting common ports. This activity helps adversaries map out network vulnerabilities for future exploitation. The detection rule identifies suspicious behavior by monitoring connection attempts from a single source to multiple destinations on key ports, flagging potential reconnaissance efforts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the source IP address and the list of destination IP addresses involved in the network sweep, focusing on the `source.ip` and `destination.port` fields.
+- Verify the legitimacy of the source IP address by checking if it belongs to a known internal system or a potentially compromised device within the network.
+- Cross-reference the destination IP addresses with internal asset inventories to determine if they are critical systems or contain sensitive data.
+- Analyze historical logs to identify any previous suspicious activities associated with the source IP address, such as repeated failed login attempts or unusual data transfers.
+- Use network traffic analysis tools to inspect the packet data for the flagged connections, looking for any anomalies or patterns that suggest reconnaissance behavior.
+- Investigate the timing and frequency of the connection attempts to determine if they align with typical network usage patterns or if they indicate a deliberate scanning effort.
+- Utilize Osquery to gather additional context on the source host. For example, run the following Osquery query to check for recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address IN ('<destination_ip_1>', '<destination_ip_2>', ...);`
+- Check for any correlated alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader attack campaign.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) of specific threat actors or malware.
+- Document all findings and observations in a detailed report to facilitate further analysis and decision-making by the security team.
+
+### False positive analysis
+
+- Routine network management tasks: Network administrators often perform scans to monitor network health and identify issues. These legitimate activities can trigger the rule, leading to false positives.
+- Automated security tools: Security software and vulnerability scanners may conduct regular sweeps to ensure network security, which can be mistaken for malicious reconnaissance.
+- Internal application behavior: Some applications may communicate across multiple hosts and ports as part of their normal operation, potentially triggering the rule.
+- To manage false positives, users can create exceptions for known IP addresses or subnets associated with trusted network management tools and internal applications. This can be done by updating the detection rule to exclude these sources from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the network sweep, including reviewing logs and network traffic for any anomalies or patterns.
+- Verify the integrity of the systems involved by checking for any unauthorized changes or installations that may indicate a compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack.
+- Implement enhanced logging policies to capture detailed network traffic and connection attempts, focusing on the ports and IP ranges identified in the detection rule.
+- Integrate threat intelligence feeds to correlate the detected activity with known threat actors or campaigns, leveraging MITRE ATT&CK framework for context.
+- Restore affected systems to a known good state using backups or system images, ensuring that any potential backdoors or malware are removed.
+- Apply network segmentation and access controls to limit the exposure of critical systems and services to unauthorized scanning or access.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate staff on recognizing and reporting suspicious network activity to improve early detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_port_scan_detected.toml b/rules/network/discovery_potential_port_scan_detected.toml
index 718b4ef6da1..411505251d8 100644
--- a/rules/network/discovery_potential_port_scan_detected.toml
+++ b/rules/network/discovery_potential_port_scan_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,47 @@ type = "threshold"
 query = '''
 destination.port : * and event.action : "network_flow" and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Network Scan Detected
+Network scanning is a technique used to identify open ports and services on a network, often as a precursor to an attack. Adversaries exploit this by mapping network vulnerabilities to plan intrusions. The detection rule identifies suspicious activity by monitoring for numerous connection attempts from a single source to multiple ports, indicating a potential scan. This helps in early detection and mitigation of unauthorized network probing.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the source IP address involved in the potential network scan, focusing on the private IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
+- Check the event logs for the specific event.action "network_flow" to gather more context about the network activity and verify the number of destination ports targeted.
+- Correlate the source IP address with internal asset inventories to identify the device or user associated with the IP address.
+- Analyze historical network traffic data to determine if the source IP has exhibited similar scanning behavior in the past.
+- Use Osquery to investigate the source host for any suspicious processes or network connections. Example query: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address IN ('<list of destination IPs>'));`
+- Investigate the destination ports that were targeted to identify if they correspond to critical services or known vulnerabilities.
+- Check for any other alerts or incidents involving the same source IP address to assess if this is part of a larger pattern of suspicious activity.
+- Review firewall and intrusion detection/prevention system logs to see if any blocks or alerts were triggered by the same source IP.
+- Consult threat intelligence sources to determine if the source IP or similar scanning patterns have been associated with known threat actors or campaigns.
+- Document findings and gather evidence to support further analysis or escalation if the activity is deemed malicious or part of a coordinated attack.
+
+### False positive analysis
+
+- Legitimate network monitoring tools or vulnerability scanners used by IT departments can trigger this rule as they often perform network scans to assess security posture. Users can handle these by creating exceptions for known IP addresses of authorized tools.
+- Automated backup systems or network management software that routinely check network connectivity and service availability might be flagged. To manage this, users should identify and whitelist these systems to prevent false alerts.
+- Internal network devices, such as printers or IoT devices, that periodically scan for available services or updates can also cause false positives. Users should document and exclude these devices from triggering the rule.
+- Security testing or penetration testing activities conducted by authorized personnel may mimic malicious scanning behavior. Users should coordinate with security teams to schedule these activities and temporarily adjust the rule or add exceptions for the duration of the tests.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the nature of the network scan and identify any potential breaches or compromised systems.
+- Review firewall and intrusion detection/prevention system (IDS/IPS) logs to identify the source of the scan and any other suspicious activities.
+- Block the source IP address of the scan at the network perimeter to prevent further scanning attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed network traffic and connection attempts for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics, techniques, and procedures (TTPs).
+- Restore affected systems to a known good state by applying patches, updating configurations, and ensuring all security controls are active.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement network hardening measures, such as disabling unused ports and services, to reduce the attack surface and prevent future scans."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_syn_port_scan_detected.toml b/rules/network/discovery_potential_syn_port_scan_detected.toml
index a7360800045..019cf793704 100644
--- a/rules/network/discovery_potential_syn_port_scan_detected.toml
+++ b/rules/network/discovery_potential_syn_port_scan_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,49 @@ type = "threshold"
 query = '''
 destination.port : * and network.packets <= 2 and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential SYN-Based Network Scan Detected
+
+SYN-based network scans exploit the TCP handshake process to identify open ports on a target system, which adversaries can use to find vulnerable services. By sending SYN packets to multiple ports and analyzing responses, attackers map network services without completing connections. The detection rule identifies such scans by flagging connection attempts from internal IPs to numerous ports with minimal packets, indicating potential reconnaissance activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the source IP address involved in the potential SYN-based network scan and verify if it falls within the internal IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16).
+- Check historical logs to determine if the source IP has been involved in similar scanning activities or other suspicious behavior in the past.
+- Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker.
+- Correlate the source IP with known user accounts or devices to determine if the activity is expected or if it could be indicative of a compromised system.
+- Use network flow data to assess the volume and frequency of SYN packets sent from the source IP to the destination ports, confirming the threshold logic of 2 or fewer packets per port.
+- Investigate any recent changes or anomalies in the network environment that could explain the scanning activity, such as new devices or software installations.
+- Utilize Osquery to gather additional context on the source system. For example, run the following Osquery query to list active network connections and identify any unusual or unauthorized connections: `SELECT * FROM process_open_sockets WHERE remote_address != '' AND local_address = '<source_ip>';`
+- Check for any related alerts or incidents that might provide additional context or indicate a broader attack campaign.
+- Review endpoint security logs and alerts from the source system to identify any signs of compromise or malicious software that could be responsible for the scanning activity.
+- Consult threat intelligence sources to determine if the observed scanning behavior matches any known attack patterns or threat actor tactics.
+
+### False positive analysis
+
+- **Automated Network Monitoring Tools**: Some network monitoring or management tools may periodically send SYN packets to check the status of network services. These legitimate activities can trigger the rule as false positives. Users can handle this by identifying the IP addresses of these tools and creating exceptions for them in the detection rule.
+- **Load Balancers and Health Checks**: Load balancers and health check services often perform SYN scans to ensure that backend services are operational. These scans are benign and necessary for maintaining service availability. Users should identify the IP addresses of these devices and exclude them from triggering the rule.
+- **Internal Security Scans**: Organizations may conduct regular security assessments or vulnerability scans that mimic SYN-based scanning techniques. These scans are typically scheduled and known to the IT department. Users can manage these false positives by scheduling exceptions during known scan windows or excluding the IP addresses of internal scanning tools.
+- **Network Troubleshooting Activities**: IT personnel may perform network troubleshooting that involves sending SYN packets to diagnose connectivity issues. These activities can be mistaken for malicious scans. Users should document and exclude the IP addresses of devices used for troubleshooting from the detection rule.
+- **Dynamic IP Addressing**: In environments with dynamic IP addressing, legitimate devices may occasionally trigger the rule due to IP address changes. Users should monitor and adjust exceptions as needed to account for these changes, ensuring that legitimate devices are not flagged as threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further reconnaissance or potential exploitation by the attacker.
+- Conduct a thorough investigation of the source IP to determine if the activity is legitimate or malicious, checking for any known vulnerabilities or misconfigurations.
+- Review firewall and intrusion detection/prevention system (IDS/IPS) logs to identify any other suspicious activities or patterns associated with the source IP.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed to be malicious, providing them with all relevant logs and findings.
+- Implement network segmentation to limit the exposure of critical systems and services, reducing the attack surface available to potential adversaries.
+- Enhance logging policies to ensure comprehensive monitoring of network traffic, focusing on unusual patterns or behaviors that may indicate reconnaissance activities.
+- Integrate threat intelligence feeds to improve detection capabilities and provide context on known malicious IPs or scanning techniques.
+- Apply security patches and updates to all systems and services to mitigate vulnerabilities that could be exploited by attackers.
+- Conduct a post-incident review to identify gaps in detection and response processes, using insights to improve future incident handling and prevention strategies.
+- Educate employees on recognizing and reporting suspicious network activities, reinforcing the importance of security awareness in preventing potential threats."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
index ddaf50fd579..fe04253ad21 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,53 @@ query = '''
     192.168.0.0/16
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 RPC (Remote Procedure Call) from the Internet
+
+RPC allows systems to execute code on remote machines, facilitating administrative tasks and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, focusing on potential threats from external sources.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the source IP address is external and not part of the excluded internal IP ranges specified in the detection rule.
+- Verify the destination IP address to ensure it belongs to your internal network, as specified in the detection rule.
+- Check historical logs for any previous RPC traffic from the same external IP address to identify patterns or repeated attempts.
+- Analyze the network traffic flow data to determine the volume and frequency of RPC requests from the external source.
+- Use packet capture tools to inspect the payload of the suspicious RPC traffic for any signs of malicious activity or anomalies.
+- Cross-reference the external IP address with threat intelligence databases to check for any known malicious activity associated with it.
+- Investigate the destination host to determine if it has any vulnerabilities or misconfigurations that could be exploited via RPC.
+- Utilize Osquery to gather more information about the destination host. For example, run the following Osquery query to list active network connections and identify any unusual or unauthorized connections:
+  ```sql
+  SELECT * FROM process_open_sockets WHERE remote_address = '<external_ip>';
+  ```
+- Check for any recent changes or updates on the destination host that might have inadvertently exposed RPC services to the Internet.
+- Collaborate with the system administrators to verify if there is a legitimate reason for RPC traffic from the Internet and document any findings or anomalies for further analysis.
+
+### False positive analysis
+
+- **Internal Misconfigurations**: Sometimes, internal systems may be misconfigured to route traffic through external IPs, triggering false positives. Ensure network configurations are correct and internal traffic is not mistakenly flagged as external.
+- **Third-Party Services**: Certain legitimate third-party services might use RPC over the Internet for valid reasons, such as remote management or monitoring. Identify these services and create exceptions for their IP addresses to prevent false alerts.
+- **VPN and Proxy Usage**: Users connecting through VPNs or proxies might appear as external sources. Verify if the flagged IPs belong to known VPN or proxy services and consider excluding them if they are part of regular operations.
+- **Cloud-Based Resources**: Cloud environments might have public-facing IPs that are used for internal communications. Review cloud configurations and whitelist known IP ranges that are part of your cloud infrastructure.
+- **Testing and Development Environments**: Traffic from testing or development environments might mimic suspicious patterns. Document these environments and exclude their IPs from the rule to avoid unnecessary alerts.
+- **Regular Audits**: Conduct regular audits of the exceptions list to ensure that only legitimate and necessary exclusions are maintained, reducing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the intrusion, focusing on identifying any unauthorized access or changes made to the system.
+- Review logs and network traffic to identify the source of the RPC traffic and any other potentially malicious activity.
+- Apply patches and updates to the affected system and any other vulnerable systems to mitigate the exploited vulnerability.
+- Change all passwords and credentials that may have been compromised during the incident.
+- Restore the system from a known good backup if unauthorized changes or malware are detected.
+- Implement network segmentation to limit exposure of critical systems and services to the Internet.
+- Enhance logging and monitoring to include detailed records of RPC traffic and other critical services for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
index 765d3d433c4..0e5a02d1fc1 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,49 @@ query = '''
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 RPC (Remote Procedure Call) to the Internet
+
+RPC enables remote management and resource sharing, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, flagging potential threats from external sources.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of RPC traffic on TCP port 135 originating from internal IP addresses and destined for external IP addresses.
+- Verify the source IP address against known internal assets to determine if the traffic is originating from a legitimate system.
+- Check the destination IP address to identify if it belongs to a known or suspicious external entity, using threat intelligence sources if available.
+- Analyze historical network traffic logs to identify any previous instances of similar RPC traffic patterns from the same source or to the same destination.
+- Use Osquery to inspect the source system for any signs of compromise or unauthorized software that might be initiating the RPC traffic. Example query: `SELECT * FROM processes WHERE name LIKE '%rpc%' OR path LIKE '%rpc%'`.
+- Investigate the user accounts and processes on the source system to determine if any unauthorized access or execution has occurred.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns.
+- Examine firewall and intrusion detection/prevention system logs to see if there were any blocked or flagged attempts related to the RPC traffic.
+- Consult with system administrators to verify if there were any legitimate remote management activities scheduled or performed that could explain the RPC traffic.
+- Document all findings and gather evidence to support further analysis or escalation if the activity is deemed suspicious or malicious.
+
+### False positive analysis
+
+- **Internal Testing and Monitoring Tools**: Organizations may have legitimate internal tools or testing environments that simulate external RPC traffic for monitoring or testing purposes. These can trigger false positives. Users can handle this by creating exceptions for known IP addresses or subnets associated with these tools.
+- **Cloud Services and VPNs**: Some cloud services or VPNs might route traffic in a way that appears as external RPC traffic. This can be managed by identifying and excluding the IP ranges of trusted cloud services or VPN endpoints from the detection rule.
+- **Misconfigured Network Devices**: Occasionally, network devices might be misconfigured to route internal RPC traffic through external IPs, leading to false positives. Regular audits and configuration checks can help identify and rectify these issues, and exceptions can be made for known devices during the interim.
+- **Third-party Software**: Certain third-party software solutions might use RPC over the internet for legitimate purposes, such as remote support or management. Users should verify the legitimacy of such software and exclude its traffic by specifying the associated IP addresses or domains.
+- **Legacy Systems**: Older systems might still rely on outdated configurations that expose RPC traffic externally. While these should ideally be updated, temporary exceptions can be made for these systems while a long-term solution is implemented.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the affected system to identify any unauthorized changes or installed backdoors, focusing on RPC-related processes and services.
+- Review network logs and firewall configurations to identify any other systems that may have been targeted or compromised using similar RPC traffic patterns.
+- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate known vulnerabilities exploited via RPC.
+- Change all passwords and credentials associated with the affected system and any potentially compromised accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging and monitoring for RPC traffic and other critical services to detect and respond to future threats more effectively.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection capabilities and understand the tactics, techniques, and procedures (TTPs) used by attackers.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security configurations are applied.
+- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and ensuring RPC services are not exposed to the Internet."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
index ec784917be1..32597e353c7 100644
--- a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
+++ b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,50 @@ query = '''
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SMB (Windows File Sharing) Activity to the Internet
+
+SMB, or Server Message Block, is a protocol used for sharing files and resources within trusted networks. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access or data theft. Adversaries exploit SMB by scanning for open ports and using vulnerabilities to gain entry. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges.
+
+### Possible investigation steps
+
+- Review the alert details to identify the internal source IP address involved in the suspicious SMB traffic. Cross-reference this IP with asset management systems to determine the device owner and its role within the network.
+- Examine the destination IP address to ascertain if it belongs to a known or trusted external entity. Use threat intelligence sources to check if the IP is associated with malicious activity.
+- Analyze network logs to identify the volume and frequency of SMB traffic from the source IP to the destination IP. Look for patterns that might indicate automated or scripted activity.
+- Check for any recent changes or updates on the source device that might have inadvertently exposed SMB services to the internet.
+- Use Osquery to gather more information about the SMB service running on the source device. Example query: `SELECT * FROM listening_ports WHERE port IN (139, 445);` to verify if the SMB service is actively listening on these ports.
+- Investigate any recent user activity on the source device that might have initiated the SMB connection. Look for unusual login times or access from unexpected locations.
+- Review firewall and security appliance logs to determine if there were any attempts to block or alert on this SMB traffic before the alert was triggered.
+- Check for any other alerts or incidents related to the same source or destination IPs to identify if this is part of a larger pattern of suspicious activity.
+- Analyze the payload of the SMB traffic, if available, to identify any potential data exfiltration or unauthorized access attempts.
+- Collaborate with the IT team to verify if there are legitimate business needs for SMB traffic to the internet from the identified source device, and document any findings for future reference.
+
+### False positive analysis
+
+- **Internal Services with External IPs**: Some organizations may have legitimate services hosted on external IPs that require SMB access. These should be identified and whitelisted to prevent false positives.
+- **VPN or Remote Access Scenarios**: Users accessing internal resources via VPNs or remote access solutions might trigger alerts if their traffic appears to originate from external IPs. Ensure these IP ranges are accounted for in exceptions.
+- **Cloud Services**: If cloud services are used for file sharing or backup, they might use SMB over the internet. Verify these services and exclude their IP ranges if they are deemed safe.
+- **Misconfigured Network Devices**: Devices that are incorrectly configured to route internal SMB traffic through external networks can cause false positives. Regularly audit network configurations to prevent this.
+- **Testing and Development Environments**: Test environments that simulate external access for development purposes might trigger alerts. Document and exclude these environments if they are secure and monitored.
+- **Handling False Positives**: Regularly review and update the list of excluded IPs and services to ensure they reflect current network architecture and business needs. Use network monitoring tools to validate the legitimacy of flagged traffic before adding exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the SMB traffic, including reviewing logs and network traffic data.
+- Verify if any unauthorized access or data exfiltration has occurred and document all findings for further analysis.
+- Apply patches and updates to the SMB service and any other vulnerable applications to mitigate known vulnerabilities.
+- Change all passwords and credentials that may have been exposed or compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for SMB traffic and other critical services to detect future anomalies.
+- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging threats.
+- Restore the affected system to its operational state by reinstalling the operating system and applications from trusted sources.
+- Harden the network by disabling SMB access to the internet, configuring firewalls, and applying least privilege principles to reduce attack surfaces."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_unsecure_elasticsearch_node.toml b/rules/network/initial_access_unsecure_elasticsearch_node.toml
index 8f51cb76b9c..c623772284b 100644
--- a/rules/network/initial_access_unsecure_elasticsearch_node.toml
+++ b/rules/network/initial_access_unsecure_elasticsearch_node.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/11"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,51 @@ index = ["packetbeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Inbound Connection to an Unsecure Elasticsearch Node"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Inbound Connection to an Unsecure Elasticsearch Node
+
+Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access or manipulate data. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the destination port is 9200, indicating the default Elasticsearch port, and verify the network direction is inbound.
+- Check the absence of the `http.request.headers.authorization` field to confirm that the connection lacks authentication.
+- Analyze the source IP address of the inbound connection to determine if it is from a known or trusted entity, or if it appears suspicious or unexpected.
+- Investigate the `event.dataset` and `event.category` fields to ensure the traffic is categorized as HTTP and aligns with the expected network traffic patterns.
+- Examine historical data for similar inbound connections to the Elasticsearch node to identify any patterns or repeated access attempts from the same source.
+- Use Osquery to gather additional context on the Elasticsearch node by running a query such as: `SELECT * FROM listening_ports WHERE port = 9200;` to verify if the node is actively listening on the default port.
+- Check for any recent changes in the Elasticsearch configuration files that might have disabled TLS or authentication inadvertently.
+- Review the `http.response.headers.content-type` field to ensure the traffic is not related to benign requests, such as favicon requests, which are filtered out by the rule.
+- Correlate the alert with other security events or logs to identify any concurrent suspicious activities or anomalies in the network.
+- Consult with the system administrators or the team responsible for the Elasticsearch deployment to verify if the node should be publicly accessible and if proper security measures are in place.
+
+### False positive analysis
+
+- Internal monitoring tools or services that regularly check the health of Elasticsearch nodes might trigger this rule if they do not use authentication headers. Users can create exceptions for known IP addresses or services that perform these checks.
+- Automated scripts or applications that interact with Elasticsearch for legitimate purposes without using authentication might be flagged. To manage this, users should ensure these scripts are updated to include authentication or whitelist their IP addresses.
+- Development or testing environments where security configurations are intentionally relaxed might generate alerts. Users can exclude these environments by filtering based on IP ranges or hostnames.
+- Security scanners or vulnerability assessment tools that probe Elasticsearch nodes could be mistaken for malicious activity. Users should identify and exclude these tools from triggering alerts by adding them to an exception list.
+- Certain legitimate third-party integrations that do not support authentication might cause false positives. Users should verify the necessity of these integrations and, if safe, exclude them from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data manipulation.
+- Conduct a thorough investigation to determine the extent of unauthorized access, focusing on logs and network traffic to identify any data exfiltration or manipulation.
+- Review and update the Elasticsearch configuration to enable Transport Layer Security (TLS) and implement strong authentication mechanisms to prevent future unauthorized access.
+- Apply security patches and updates to the Elasticsearch software to mitigate any known vulnerabilities that could be exploited.
+- Restore any altered or deleted data from backups, ensuring that the backup data is clean and uncompromised.
+- Implement network segmentation to limit access to Elasticsearch nodes, allowing only trusted IP addresses and services to connect.
+- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect and alert on suspicious activities in real-time.
+- Conduct a security audit of the entire environment to identify and remediate other potential vulnerabilities or misconfigurations.
+- Educate and train the IT and security teams on secure configuration practices and the importance of regular security assessments.
+- Escalate the incident to the appropriate internal teams and, if necessary, report to external authorities or partners, especially if sensitive data was accessed or exfiltrated.
+
+## Setup
 
 This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation."""
 references = [
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
index a438cc58550..b650203e2f0 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,52 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Credential Dumping - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that identifies suspicious activities like credential dumping, where attackers extract sensitive authentication data to gain unauthorized access. Adversaries exploit system vulnerabilities to perform such actions, often targeting OS credentials. The detection rule leverages specific event types and actions to flag these malicious attempts, aligning with MITRE ATT&CK's framework for identifying credential access threats.
+
+### Possible investigation steps
+
+- Review the alert details in Elastic Endgame to understand the context, including the event.kind, event.module, and endgame.metadata.type fields to confirm the detection type and source.
+- Examine the event.action and endgame.event_subtype_full fields to identify the specific credential theft event that triggered the alert.
+- Check the timestamp of the alert to determine when the suspicious activity occurred and correlate it with other events in the same timeframe.
+- Investigate the affected host by reviewing its recent activity logs to identify any unusual behavior or unauthorized access attempts.
+- Use Osquery to gather more information about the processes running on the affected host. For example, run the following query to list processes that might be involved in credential dumping:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE name IN ('lsass.exe', 'mimikatz.exe', 'procdump.exe');
+  ```
+- Analyze user account activity on the affected host to identify any unauthorized access or privilege escalation attempts.
+- Review network logs to detect any suspicious outbound connections that might indicate data exfiltration following the credential dumping.
+- Cross-reference the alert with other security tools and logs to identify any related alerts or indicators of compromise (IOCs) that might suggest a broader attack campaign.
+- Investigate any recent changes to system configurations or installed software that could have introduced vulnerabilities exploited for credential dumping.
+- Document all findings and observations to build a comprehensive timeline of events and support further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Known false positives for the Credential Dumping - Detected - Elastic Endgame rule may include legitimate administrative tools or scripts that access credential stores for authorized purposes, such as system backups or password management software.
+- Security teams can manage these false positives by creating exceptions for specific processes or applications that are known to perform credential access in a non-malicious context, ensuring these are well-documented and regularly reviewed.
+- Users should also consider the context of the detected event, such as the time of day or the user account involved, to determine if the activity aligns with expected behavior.
+- Implementing a whitelist of trusted applications and processes that are allowed to access credentials can help reduce false positives while maintaining security.
+- Regularly updating the detection rules and maintaining communication with IT and security teams can help in identifying and excluding benign activities that trigger alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the credential dumping activity, utilizing logs and forensic tools.
+- Reset passwords for compromised accounts and implement multi-factor authentication to enhance security.
+- Review and update security patches and configurations to address vulnerabilities exploited during the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed authentication and access events for future investigations.
+- Integrate additional security solutions, such as endpoint detection and response (EDR) tools, to improve threat detection capabilities.
+- Restore the system to its operational state by reimaging affected machines and verifying the integrity of critical files and applications.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
index 54622033143..fa94b5ed89d 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,49 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Credential Dumping - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent unauthorized access by detecting and blocking credential dumping attempts, a common tactic used by adversaries to extract sensitive authentication data. Attackers exploit this by accessing stored credentials to escalate privileges or move laterally within a network. The detection rule identifies such threats by monitoring for specific alert types and actions indicative of credential theft, leveraging event data to preemptively thwart these malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `event.kind:alert`, `event.module:endgame`, and `endgame.metadata.type:prevention` fields to confirm the alert type and source.
+- Examine the `event.action:cred_theft_event` and `endgame.event_subtype_full:cred_theft_event` fields to identify the specific actions that triggered the alert, providing insight into the attempted credential dumping method.
+- Check the timestamp of the alert to determine when the credential dumping attempt occurred and correlate it with other events in the network around the same time.
+- Investigate the source IP address and hostname associated with the alert to identify the potentially compromised system and assess its role within the network.
+- Analyze user account information involved in the alert to determine if the account is legitimate and if it has been used in any suspicious activities recently.
+- Utilize Osquery to gather additional context from the affected system. For example, run the following Osquery query to check for suspicious processes related to credential dumping: `SELECT pid, name, path, cmdline FROM processes WHERE name IN ('lsass.exe', 'mimikatz.exe', 'procdump.exe');`
+- Review recent login attempts and authentication logs on the affected system to identify any unauthorized access or failed login attempts that may indicate credential theft.
+- Cross-reference the alert with other security tools and logs, such as firewall logs or intrusion detection systems, to gather more evidence of the attack vector and potential lateral movement.
+- Investigate any recent changes to system configurations or installed software on the affected machine that could have facilitated the credential dumping attempt.
+- Document all findings and evidence collected during the investigation to build a comprehensive timeline and understanding of the incident, which will aid in further analysis and reporting.
+
+### False positive analysis
+
+- Known false positives for the Credential Dumping - Prevented - Elastic Endgame rule may include legitimate administrative tools or scripts that access credential stores for authorized purposes, such as system management or software updates.
+- Security software or backup solutions that scan or access credential files as part of their routine operations can also trigger false positives.
+- Users can manage these false positives by creating exceptions for specific processes or applications that are known to perform legitimate credential access, ensuring these are well-documented and regularly reviewed.
+- Implementing a whitelist of trusted applications and processes that are allowed to access credential stores can help reduce false positives while maintaining security.
+- Regularly updating the list of exceptions and monitoring for any changes in behavior of these applications can help maintain a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
+- Conduct a thorough investigation to identify the source and scope of the credential dumping attempt, utilizing Elastic Endgame logs and any other available security information.
+- Reset passwords for all compromised accounts and consider implementing multi-factor authentication to enhance security.
+- Review and update access controls and permissions to ensure the principle of least privilege is enforced across the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed authentication and access events, aiding in future investigations.
+- Integrate Elastic Endgame with other security tools such as SIEMs to improve threat detection and response capabilities.
+- Restore the affected system to its operational state by reimaging it and applying the latest security patches and updates.
+- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary services, applying security baselines, and conducting regular security audits to reduce the risk of future credential dumping attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/endgame_adversary_behavior_detected.toml b/rules/promotions/endgame_adversary_behavior_detected.toml
index 37dae90c425..0a4551a4efa 100644
--- a/rules/promotions/endgame_adversary_behavior_detected.toml
+++ b/rules/promotions/endgame_adversary_behavior_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,46 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and (event.action:behavior_protection_event or endgame.event_subtype_full:behavior_protection_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Adversary Behavior - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution designed to detect and prevent adversarial actions by monitoring system behaviors. Adversaries often exploit system vulnerabilities or misuse legitimate tools to execute malicious activities. This detection rule identifies suspicious behavior by analyzing alerts and specific event actions related to behavior protection, helping security analysts pinpoint potential threats and mitigate risks effectively.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected behavior.
+- Examine the event.kind field to confirm that the alert is indeed an 'alert' type, ensuring that it requires immediate attention.
+- Analyze the event.module field to verify that the alert originated from the 'endgame' module, confirming the source of the detection.
+- Investigate the event.action and endgame.event_subtype_full fields to understand the specific behavior protection event that triggered the alert, identifying the nature of the suspicious activity.
+- Cross-reference the alert with other recent alerts or logs to identify any patterns or correlations that might indicate a broader attack campaign.
+- Use Osquery to gather additional system information related to the alert. For example, run the following query to list all running processes and their network connections: `SELECT pid, name, path, listening_ports FROM processes WHERE on_disk = 1;`
+- Check the affected system's recent login history and user activity to identify any unauthorized access attempts or unusual user behavior.
+- Review the system's installed software and running services to detect any unauthorized or suspicious applications that might have been used by the adversary.
+- Analyze network traffic logs to identify any unusual outbound connections or data exfiltration attempts that might be associated with the detected behavior.
+- Consult threat intelligence sources to determine if the detected behavior matches any known adversary tactics, techniques, or procedures, even though the MITRE ATT&CK tactic and technique fields are marked as 'None'.
+
+### False positive analysis
+
+- Known false positives for the Adversary Behavior - Detected - Elastic Endgame rule often arise from legitimate software or administrative tools that exhibit behavior similar to adversarial actions. For example, system administration scripts or automated maintenance tasks may trigger alerts due to their access patterns or execution methods.
+- Users can manage these false positives by creating exceptions for specific processes or actions that are known to be safe. This involves identifying the benign behavior patterns that frequently trigger alerts and configuring the security solution to exclude these from future detections.
+- It is important to regularly review and update these exceptions to ensure that they do not inadvertently allow new or modified threats to bypass detection. Security teams should document the rationale for each exception and periodically reassess their validity in the context of evolving threat landscapes.
+- Collaboration with IT and development teams can help in understanding the normal operational behaviors of systems and applications, which aids in distinguishing between legitimate activities and potential threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential threats.
+- Conduct a thorough investigation of the alert by reviewing related logs and events to understand the scope and impact.
+- Identify and terminate any malicious processes or unauthorized access points detected on the system.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is beyond initial containment capabilities.
+- Apply patches and updates to address any exploited vulnerabilities and prevent future exploitation.
+- Restore the system from a known good backup to ensure the removal of any persistent threats.
+- Implement enhanced logging policies to capture detailed system and network activity for future investigations.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve threat visibility and response capabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users on security best practices and awareness to reduce the risk of similar incidents occurring in the future."""
 
diff --git a/rules/promotions/endgame_malware_detected.toml b/rules/promotions/endgame_malware_detected.toml
index cbf07ce6b21..64b893e5343 100644
--- a/rules/promotions/endgame_malware_detected.toml
+++ b/rules/promotions/endgame_malware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,47 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Malware - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that leverages advanced detection capabilities to identify malware threats within an environment. It monitors file classification events to detect suspicious activities. Adversaries may exploit file systems to execute or hide malware. The detection rule identifies alerts from the Endgame module, focusing on file classification events, to pinpoint potential malware activities, enabling timely threat response.
+
+### Possible investigation steps
+
+- Review the alert details in the security dashboard to understand the context and specifics of the detection, focusing on the `event.kind:alert` and `event.module:endgame` fields.
+- Examine the `endgame.metadata.type:detection` field to confirm the type of detection and ensure it aligns with the expected behavior of the Elastic Endgame module.
+- Investigate the `event.action:file_classification_event` or `endgame.event_subtype_full:file_classification_event` fields to identify the specific file classification event that triggered the alert.
+- Cross-reference the file path and hash values of the suspicious file with known malware databases to determine if it is a known threat.
+- Utilize Osquery to gather additional context about the file and its behavior on the system. For example, run the following Osquery query to list processes associated with the suspicious file: `SELECT * FROM processes WHERE path = '/path/to/suspicious/file';`
+- Check the system's recent file modification and creation events to identify any unusual activities around the time of the alert.
+- Analyze the parent process of the suspicious file to understand how it was executed and whether it was initiated by a legitimate application or process.
+- Review network connections established by the system around the time of the alert to identify any suspicious outbound connections that may indicate data exfiltration or command-and-control communication.
+- Investigate user activity on the affected system to determine if any unauthorized actions were performed that could have led to the execution of the malware.
+- Correlate the alert with other security events and logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives for the Malware - Detected - Elastic Endgame rule may include legitimate software updates or installations that mimic malware behavior, such as file classification events triggered by trusted applications.
+- Users can manage these false positives by creating exceptions for specific applications or processes that are known to generate benign file classification events, ensuring these are well-documented and regularly reviewed to maintain security integrity.
+- Another common false positive scenario involves automated scripts or system maintenance tasks that access or modify files in a manner similar to malware; these can be excluded by identifying and whitelisting the specific scripts or tasks involved.
+- To handle frequent non-threatening behaviors, users should leverage the exclusion capabilities within Elastic Endgame to filter out alerts from known safe sources, reducing noise and focusing on genuine threats.
+- Regularly updating the list of exceptions and exclusions based on the latest threat intelligence and organizational changes can help maintain an effective balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the malware.
+- Conduct a thorough investigation of the alert by reviewing the file classification events and any related logs to understand the scope and impact.
+- Utilize Elastic Endgame's detailed event data to identify the malware's entry point and any lateral movement within the network.
+- Remove the detected malware by using updated antivirus or anti-malware tools, ensuring that the system is clean.
+- Apply security patches and updates to the operating system and all installed software to close any vulnerabilities exploited by the malware.
+- Escalate the incident to the security operations center (SOC) or incident response team if the malware is part of a larger attack campaign or if it involves sensitive data.
+- Implement enhanced logging policies to capture detailed file system activities and network traffic for future investigations.
+- Integrate Elastic Endgame with other security tools such as SIEMs for improved threat detection and response capabilities.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure that backups are clean before restoring any data.
+- Strengthen system defenses by applying security hardening measures, such as disabling unnecessary services, enforcing strong password policies, and conducting regular security audits."""
 
diff --git a/rules/promotions/endgame_malware_prevented.toml b/rules/promotions/endgame_malware_prevented.toml
index d00be854558..9b6a8c9169f 100644
--- a/rules/promotions/endgame_malware_prevented.toml
+++ b/rules/promotions/endgame_malware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,47 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Malware - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent malware by leveraging advanced threat detection and prevention techniques. It monitors system activities and classifies files to identify and block malicious actions. Adversaries may attempt to bypass these defenses by disguising malware as legitimate files. The detection rule identifies such threats by focusing on alerts where file classification events indicate prevention actions, ensuring that any attempt to execute or propagate malware is promptly detected and mitigated.
+
+### Possible investigation steps
+
+- Review the alert details in the security dashboard to understand the context and specifics of the prevention event, focusing on the `event.kind:alert` and `event.module:endgame` fields.
+- Examine the `endgame.metadata.type:prevention` field to confirm that the alert is related to a prevention action, ensuring that the threat was blocked before execution.
+- Analyze the `event.action:file_classification_event` or `endgame.event_subtype_full:file_classification_event` fields to identify the type of file classification event that triggered the alert.
+- Investigate the file path and hash of the suspected malicious file to determine its origin and whether it matches known malware signatures.
+- Use Osquery to gather additional context about the file and its behavior on the system. For example, run the following Osquery query to check for any related processes: `SELECT * FROM processes WHERE path = '/path/to/suspected/file';`
+- Check the system's recent file modification and creation events to identify any suspicious activities that occurred around the time of the alert.
+- Review user activity logs to determine if any user actions could have inadvertently triggered the alert, focusing on any recent downloads or executed files.
+- Correlate the alert with other security events in the environment to identify potential patterns or related incidents that could indicate a broader attack campaign.
+- Consult threat intelligence sources to see if the file hash or any related indicators of compromise (IOCs) are associated with known threat actors or malware campaigns.
+- Document all findings and observations in the investigation report, ensuring that all relevant details from the alert and subsequent analysis are captured for future reference.
+
+### False positive analysis
+
+- Known false positives for the Malware - Prevented - Elastic Endgame rule may include legitimate software that mimics malware behavior, such as software updates or installers that modify system files in a manner similar to malware.
+- Users can handle these false positives by creating exceptions for specific file paths or processes that are known to be safe, ensuring that these legitimate activities are not flagged as threats.
+- It is important to regularly review and update these exceptions to accommodate new software versions or changes in system behavior, minimizing the risk of overlooking genuine threats.
+- Users should also consider the context of the alert, such as the source and destination of the file or process, to determine if the behavior is expected and non-threatening.
+- Implementing a feedback loop with security teams can help refine detection rules and reduce the occurrence of false positives by incorporating insights from past incidents.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the malware.
+- Verify the alert by cross-referencing with other security logs and alerts to confirm the presence of malware.
+- Conduct a thorough investigation to identify the source and entry point of the malware, using available forensic tools and techniques.
+- Remove the identified malware from the system using trusted antivirus or anti-malware solutions.
+- Restore the system from a clean backup if the malware has caused significant damage or if removal is not feasible.
+- Update all security software and apply the latest patches to the operating system and applications to close any vulnerabilities.
+- Implement enhanced logging policies to capture detailed system and network activities for future investigations.
+- Integrate additional security solutions, such as endpoint detection and response (EDR) tools, to improve threat visibility and response capabilities.
+- Escalate the incident to the appropriate internal or external teams if the malware is part of a larger attack campaign or if sensitive data has been compromised.
+- Conduct a post-incident review to identify gaps in the security posture and apply hardening measures, such as disabling unnecessary services and enforcing least privilege access controls."""
 
diff --git a/rules/promotions/endgame_ransomware_detected.toml b/rules/promotions/endgame_ransomware_detected.toml
index 917f0ab088b..2f44801a055 100644
--- a/rules/promotions/endgame_ransomware_detected.toml
+++ b/rules/promotions/endgame_ransomware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,50 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Ransomware - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution designed to detect and respond to ransomware threats by monitoring system events and identifying suspicious activities. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activity by analyzing alerts and specific event actions, enabling timely intervention to mitigate damage.
+
+### Possible investigation steps
+
+- Review the alert details in Elastic Endgame by clicking the icon in the event.module column or the link in the rule.reference column to gather initial context about the detected ransomware event.
+- Examine the event.kind field to confirm that the alert is indeed an alert type and not a benign event.
+- Check the event.module field to ensure the alert is generated by the endgame module, confirming the source of detection.
+- Analyze the endgame.metadata.type field to verify that the alert is categorized as a detection, indicating a potential threat.
+- Investigate the event.action and endgame.event_subtype_full fields to identify the specific ransomware event or subtype that triggered the alert.
+- Correlate the alert with other related alerts or events in the system to determine if this is part of a larger attack pattern or isolated incident.
+- Use Osquery to gather additional system information. For example, run the following query to list processes that have been started recently, which might indicate ransomware activity:
+  ```sql
+  SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));
+  ```
+- Check for any recent file modifications or encryptions on the system by reviewing file access logs or using file integrity monitoring tools.
+- Investigate user activity around the time of the alert to identify any suspicious logins or actions that could be related to the ransomware execution.
+- Review network traffic logs for any unusual outbound connections that might indicate communication with a command and control server or data exfiltration attempts.
+
+### False positive analysis
+
+- Known false positives for the Ransomware - Detected - Elastic Endgame rule may include legitimate software updates or backup processes that mimic ransomware behavior by encrypting files temporarily. 
+- Users can manage these false positives by creating exceptions for specific processes or applications that are known to perform legitimate encryption activities, ensuring they are not flagged as threats.
+- Regularly review and update the list of exceptions to accommodate new software updates or changes in legitimate processes that could trigger alerts.
+- Implement a monitoring strategy to differentiate between benign and malicious encryption activities by analyzing the context and frequency of the detected events.
+- Collaborate with IT and security teams to identify and document legitimate processes that may trigger false positives, ensuring these are accounted for in the security policy.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent the spread of ransomware to other devices.
+- Conduct a thorough investigation to identify the ransomware variant and entry point by analyzing logs and alerts from Elastic Endgame.
+- Use endpoint detection and response tools to terminate malicious processes and remove ransomware executables from the affected systems.
+- Restore encrypted files from the most recent clean backups to ensure data integrity and minimize downtime.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed system and network activity, aiding in future investigations and threat hunting.
+- Integrate Elastic Endgame with other security solutions, such as SIEM and threat intelligence platforms, to improve detection and response capabilities.
+- Apply security patches and updates to all systems to close vulnerabilities exploited by the ransomware.
+- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
+- Educate employees on recognizing phishing attempts and other common ransomware delivery methods to reduce the risk of future incidents."""
 
diff --git a/rules/promotions/endgame_ransomware_prevented.toml b/rules/promotions/endgame_ransomware_prevented.toml
index d6e5e4b7667..75d5d92fed0 100644
--- a/rules/promotions/endgame_ransomware_prevented.toml
+++ b/rules/promotions/endgame_ransomware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,46 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Ransomware - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent ransomware by monitoring and analyzing system events. Adversaries often exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activities by focusing on alerts from the Endgame module, specifically targeting prevention events linked to ransomware actions, thus enabling early intervention and mitigation.
+
+### Possible investigation steps
+
+- Review the alert details in the security dashboard to understand the context and specifics of the prevention event, focusing on the `event.kind`, `event.module`, and `endgame.metadata.type` fields.
+- Examine the `event.action` and `endgame.event_subtype_full` fields to confirm the type of ransomware event that was prevented and gather more context about the specific actions that triggered the alert.
+- Check the timestamp of the alert to determine when the ransomware activity was detected and correlate it with other events in the system logs around the same time.
+- Investigate the source and destination IP addresses involved in the alert to identify potentially compromised systems or external connections.
+- Use Osquery to gather additional information about the affected system. For example, run the following query to list recent processes that might be related to the ransomware activity: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
+- Analyze the user account activity associated with the alert to determine if any unauthorized access or privilege escalation occurred.
+- Review file system changes on the affected system to identify any encrypted files or suspicious modifications that might indicate ransomware behavior.
+- Check for any related alerts or events in the security solution that might provide additional context or indicate a broader attack campaign.
+- Investigate any known vulnerabilities or exploits that might have been used to deploy the ransomware, focusing on recent patches or security advisories.
+- Document all findings and observations in a detailed report to support further analysis and potential response actions.
+
+### False positive analysis
+
+- Known false positives for the Ransomware - Prevented - Elastic Endgame rule may include legitimate software that performs file encryption as part of its normal operations, such as backup solutions or disk encryption tools. These applications can trigger alerts due to their behavior resembling ransomware activities.
+- Users can manage these false positives by creating exceptions for trusted applications. This involves identifying the legitimate software that triggers the alerts and adding them to an allowlist within the Elastic Endgame settings, ensuring that their activities are not flagged as malicious.
+- Regularly review and update the list of exceptions to accommodate any changes in software behavior or new legitimate applications that may be introduced into the environment.
+- It is crucial to maintain a balance between reducing false positives and ensuring that genuine threats are not overlooked. Therefore, any exceptions should be carefully evaluated and monitored to prevent potential security gaps.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the ransomware.
+- Conduct a thorough investigation to identify the entry point and the scope of the attack, utilizing logs and alerts from Elastic Endgame.
+- Remove the ransomware by using trusted antivirus or anti-malware tools, ensuring the system is clean before reconnecting to the network.
+- Restore encrypted files from the most recent clean backup to ensure data integrity and minimize data loss.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed system events and network traffic for future investigations.
+- Integrate Elastic Endgame with other security tools such as SIEMs for comprehensive threat detection and response capabilities.
+- Review and update security patches and configurations to close vulnerabilities exploited by the ransomware.
+- Educate employees on recognizing phishing attempts and other common ransomware delivery methods to reduce the risk of future incidents.
+- Conduct a post-incident review to assess the effectiveness of the response and update the incident response plan accordingly."""
 
diff --git a/rules/promotions/execution_endgame_exploit_detected.toml b/rules/promotions/execution_endgame_exploit_detected.toml
index 891c48a3e07..ad4573624d1 100644
--- a/rules/promotions/execution_endgame_exploit_detected.toml
+++ b/rules/promotions/execution_endgame_exploit_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,50 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:exploit_event or endgame.event_subtype_full:exploit_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Exploit - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution designed to detect and prevent exploits by monitoring system activities and identifying suspicious behaviors. Adversaries exploit vulnerabilities to execute unauthorized code, often leading to system compromise. The detection rule identifies alerts from the Endgame module, focusing on exploit-related events, thus enabling timely identification and response to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional context.
+- Examine the event.kind field to confirm that the alert is indeed an 'alert' type, ensuring it is not a false positive or misclassification.
+- Check the event.module field to verify that the alert originated from the 'endgame' module, confirming the source of the detection.
+- Analyze the endgame.metadata.type field to ensure it is marked as 'detection', indicating that the alert is based on a detection rule rather than a simple log entry.
+- Investigate the event.action and endgame.event_subtype_full fields to determine the specific exploit event that triggered the alert, providing insight into the nature of the potential exploit.
+- Correlate the alert with other related events in the system to identify any patterns or sequences that may indicate a broader attack or compromise.
+- Use Osquery to gather additional system information related to the alert. For example, run the following query to list all running processes and their network connections: `SELECT pid, name, path, address, port FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid;`
+- Check for any recent changes or anomalies in system configurations or user accounts that could be related to the exploit attempt.
+- Review historical data and logs to identify any previous similar alerts or activities that might suggest a persistent threat or recurring vulnerability.
+- Consult threat intelligence sources to determine if the detected exploit is part of a known campaign or associated with specific threat actors, enhancing the context of the investigation.
+
+### False positive analysis
+
+- Known false positives for the Exploit - Detected - Elastic Endgame rule may include legitimate software updates or patches that mimic exploit-like behavior, triggering alerts. 
+- Certain administrative tools or scripts used for system maintenance might also be flagged as exploit events due to their nature of executing code.
+- Users can manage these false positives by creating exceptions for specific processes or applications that are known to exhibit such behaviors but are verified as non-threatening.
+- Implementing a whitelist of trusted software and regularly updating it can help reduce the occurrence of false positives.
+- Monitoring the frequency and context of alerts can assist in identifying patterns that are consistently non-malicious, allowing for more informed decisions on exclusions.
+- Collaboration with IT and security teams to review and validate alerts can ensure that only genuine threats are acted upon, minimizing disruptions from false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to identify the exploited vulnerability and determine the scope of the compromise using forensic tools and logs.
+- Apply available patches or updates to remediate the identified vulnerability and prevent re-exploitation.
+- Review and analyze the alert details in Elastic Endgame to understand the exploit's behavior and entry point.
+- Escalate the incident to the security operations center (SOC) or incident response team if the exploit is part of a larger attack campaign or if sensitive data is at risk.
+- Implement enhanced logging and monitoring policies to capture detailed system activities and potential exploit attempts for future investigations.
+- Integrate Elastic Endgame with other security tools such as SIEMs and threat intelligence platforms to improve detection and response capabilities.
+- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement system hardening measures, such as disabling unnecessary services, enforcing strong authentication, and applying least privilege principles, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/execution_endgame_exploit_prevented.toml b/rules/promotions/execution_endgame_exploit_prevented.toml
index 8d924b7e725..08b0c1ae7d1 100644
--- a/rules/promotions/execution_endgame_exploit_prevented.toml
+++ b/rules/promotions/execution_endgame_exploit_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,49 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:exploit_event or endgame.event_subtype_full:exploit_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Exploit - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent exploits by monitoring and analyzing system behaviors. Adversaries often exploit vulnerabilities to execute unauthorized code, gaining control over systems. The detection rule identifies alerts where Elastic Endgame has preemptively blocked such exploit attempts, focusing on prevention events and specific exploit-related actions, thus safeguarding against potential execution threats.
+
+### Possible investigation steps
+
+- Review the alert details in the security dashboard to understand the context and specifics of the exploit attempt, focusing on the `event.kind`, `event.module`, and `endgame.metadata.type` fields.
+- Examine the `event.action` and `endgame.event_subtype_full` fields to determine the nature of the exploit event and identify any patterns or specific exploit techniques used.
+- Check the `rule.reference` column for additional documentation or guidance related to the specific exploit attempt to gain further insights.
+- Investigate the affected system by identifying the host and user involved in the alert to assess potential exposure and impact.
+- Use Osquery to gather more information about the affected system. For example, run the following query to list all running processes and their associated network connections: `SELECT pid, name, path, listening_ports FROM processes JOIN listening_ports USING (pid);`
+- Analyze recent system logs and security events on the affected host to identify any unusual activities or anomalies that occurred around the time of the alert.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack campaign or isolated incident.
+- Review the system's patch and update status to ensure that all known vulnerabilities are addressed, focusing on those related to the exploit attempt.
+- Investigate any recent changes or deployments on the affected system that might have introduced vulnerabilities or altered security configurations.
+- Consult threat intelligence sources to check for any known exploits or attack patterns that match the characteristics of the alert, which could provide additional context or indicators of compromise.
+
+### False positive analysis
+
+- Known false positives for the Exploit - Prevented - Elastic Endgame rule may include legitimate software behaviors that mimic exploit-like activities, such as certain software updates or debugging tools that modify system processes in a way that resembles exploit attempts.
+- Users can manage these false positives by creating exceptions for specific processes or applications that are known to trigger alerts but are verified as non-threatening. This can be done by adding these processes to an allowlist within the Elastic Endgame settings.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+- Consider implementing a monitoring period where alerts are closely observed to distinguish between true threats and benign activities, allowing for more informed decisions on which behaviors to exclude.
+- Engage with the security community or Elastic support to stay informed about common false positives and recommended practices for handling them, ensuring that the security posture remains robust while minimizing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Conduct a thorough investigation to identify the vulnerability exploited and gather forensic evidence, including logs and memory dumps.
+- Verify the alert by cross-referencing with other security tools and logs to confirm the exploit attempt and assess the scope of the incident.
+- Apply patches or updates to remediate the identified vulnerability and prevent future exploitation.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Implement enhanced logging policies to capture detailed system and network activity for future investigations.
+- Integrate Elastic Endgame with other security solutions, such as SIEM or EDR, to improve detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/external_alerts.toml b/rules/promotions/external_alerts.toml
index 1eb2d1a0d7d..3ac06c7b079 100644
--- a/rules/promotions/external_alerts.toml
+++ b/rules/promotions/external_alerts.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/08"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,48 @@ type = "query"
 query = '''
 event.kind:alert and not event.module:(endgame or endpoint or cloud_defend)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 External Alerts
+
+External alerts are crucial for identifying potential threats from outside sources, leveraging logs and signals from various security tools. Adversaries may exploit these technologies by triggering false alerts or bypassing detection systems. The 'External Alerts' rule filters alerts, excluding specific modules, to focus on genuine threats, enabling analysts to swiftly investigate and mitigate risks.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `event.kind:alert` field to confirm the nature of the alert.
+- Check the `event.module` field to ensure the alert is not from excluded modules such as endgame, endpoint, or cloud_defend, which are filtered out by the rule.
+- Correlate the alert with other logs and alerts from the same timeframe to identify any patterns or related activities.
+- Investigate the source IP address or domain associated with the alert to determine if it is known for malicious activity.
+- Use threat intelligence sources to gather additional context on the external alert, such as known indicators of compromise (IOCs) or threat actor profiles.
+- Examine user activity logs to identify any unusual behavior or access patterns that coincide with the alert.
+- Utilize Osquery to gather more information from affected systems. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious IP>';`
+- Analyze any file hashes or URLs associated with the alert using online malware analysis tools to assess their threat level.
+- Check for any recent changes in system configurations or security settings that could have contributed to the alert.
+- Document all findings and observations in a centralized investigation report to maintain a clear record of the investigation process.
+
+### False positive analysis
+
+- Known false positives for the External Alerts rule may include benign activities from trusted sources that inadvertently trigger alerts, such as routine network scans by authorized security tools or regular updates from trusted software vendors.
+- Users can manage these false positives by creating exceptions for specific event sources or modules that are consistently identified as non-threatening, ensuring that these are well-documented and reviewed regularly to maintain security integrity.
+- It is important to analyze the context of each alert to determine if it aligns with known benign behaviors or if it requires further investigation, thereby reducing unnecessary alert fatigue and focusing on genuine threats.
+- Implementing a feedback loop where analysts can flag and document false positives will help refine the rule over time, improving its accuracy and reducing the likelihood of overlooking real threats due to alert desensitization.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further spread of the threat.
+- Conduct a thorough investigation of the alert to determine the scope and impact, utilizing available logs and security tools.
+- Validate the alert to confirm it is not a false positive by cross-referencing with other security data sources.
+- If malicious activity is confirmed, remove any identified malware or unauthorized access points from the affected systems.
+- Escalate the incident to the appropriate internal teams or external partners if the threat level is beyond current handling capabilities.
+- Implement additional logging and monitoring policies to capture more detailed information for future investigations.
+- Integrate threat intelligence feeds to enhance detection capabilities and provide context for similar threats.
+- Restore affected systems to their operational state by applying clean backups and ensuring all security patches are up to date.
+- Conduct a post-incident review to identify gaps in the current security posture and update response plans accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing strong authentication mechanisms, to reduce the risk of future incidents."""
 
 
 [[rule.risk_score_mapping]]
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
index 8155bb2f92e..499a756db25 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,48 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Credential Manipulation - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution designed to detect and respond to threats in real-time. Credential manipulation involves adversaries altering authentication tokens to escalate privileges or maintain access. This detection rule identifies suspicious token activities by monitoring specific alert types and event actions, aligning with MITRE ATT&CK's Access Token Manipulation technique, thus helping to thwart unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather initial context.
+- Examine the event.kind field to confirm that the alert is indeed an alert type and not a false positive or benign event.
+- Check the event.module field to ensure the alert originated from the endgame module, confirming the source of detection.
+- Investigate the endgame.metadata.type field to verify that the alert is categorized as a detection, which indicates a potential threat.
+- Analyze the event.action and endgame.event_subtype_full fields to identify the specific type of token manipulation event that triggered the alert.
+- Correlate the alert with other related events in the same timeframe to identify any patterns or additional suspicious activities.
+- Use Osquery to gather more information about the processes and users involved in the alert. For example, run the following query to list processes with suspicious token privileges: `SELECT pid, name, path, uid, gid FROM processes WHERE on_disk = 1 AND (name LIKE '%token%' OR path LIKE '%token%');`
+- Investigate the user account associated with the alert to determine if there have been any recent changes in privileges or unusual login activities.
+- Review system logs and security logs for any additional signs of credential manipulation or unauthorized access attempts around the time of the alert.
+- Cross-reference the alert with known MITRE ATT&CK techniques, specifically T1134, to understand the potential methods used by the adversary and gather insights into their tactics.
+
+### False positive analysis
+
+- Known false positives for the Credential Manipulation - Detected - Elastic Endgame rule may include legitimate administrative actions where tokens are altered as part of routine maintenance or software updates. These activities can trigger alerts due to their similarity to malicious token manipulation.
+- To manage these false positives, users can create exceptions for specific processes or user accounts that are known to perform legitimate token manipulations regularly. This can be done by identifying the event.action or endgame.event_subtype_full values associated with these benign activities and excluding them from triggering alerts.
+- Another approach is to monitor the frequency and context of the alerts. If certain alerts consistently correlate with non-threatening behaviors, users can adjust the detection rule to ignore these specific patterns while maintaining vigilance for truly suspicious activities.
+- It is also advisable to review and update the list of exceptions periodically to ensure that new legitimate activities are accounted for and that no malicious activities are inadvertently excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the scope of the credential manipulation, including reviewing logs and correlating events to determine the source and method of attack.
+- Reset passwords and authentication tokens for affected accounts and any accounts that may have been accessed using manipulated credentials.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging and monitoring policies to capture detailed authentication and access events, ensuring future incidents can be detected more efficiently.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
+- Restore the affected system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate users on recognizing phishing attempts and other social engineering tactics that could lead to credential manipulation.
+- Apply hardening measures such as enforcing multi-factor authentication (MFA) and implementing least privilege access controls to reduce the risk of future credential manipulation."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
index 3d28513a582..ba4a8fb6b19 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,52 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Credential Manipulation - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent unauthorized credential manipulation, a common tactic used by adversaries to escalate privileges within a system. Attackers often exploit access token manipulation to impersonate legitimate users and gain elevated access. The detection rule leverages event alerts from the Endgame module, specifically targeting prevention events related to token manipulation. By monitoring these events, the rule effectively identifies and thwarts attempts at credential abuse, aligning with the MITRE ATT&CK framework's focus on privilege escalation techniques.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `event.kind`, `event.module`, and `endgame.metadata.type` fields to confirm it is a prevention event related to token manipulation.
+- Examine the `event.action` and `endgame.event_subtype_full` fields to identify the specific type of token manipulation event that was prevented.
+- Check the timestamp of the alert to determine when the credential manipulation attempt occurred and correlate it with other events in the same timeframe.
+- Investigate the source and destination IP addresses associated with the alert to identify the origin of the attack and any potential targets within the network.
+- Analyze the user account involved in the alert to determine if it is a legitimate user or a potential compromised account by reviewing recent login activities and changes.
+- Utilize Osquery to gather additional context on the affected system. For example, run the following query to list recent processes that might have been involved in token manipulation:
+  ```sql
+  SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));
+  ```
+- Review the system logs and security logs on the affected host for any suspicious activities or anomalies around the time of the alert.
+- Investigate any related alerts or events in the security information and event management (SIEM) system that might indicate a broader attack pattern or campaign.
+- Check for any recent changes in user privileges or group memberships that could be related to the attempted credential manipulation.
+- Collaborate with other security teams to gather intelligence on similar incidents or known threats that might be targeting the organization.
+
+### False positive analysis
+
+- Known false positives for the Credential Manipulation - Prevented - Elastic Endgame rule may include legitimate administrative actions where authorized users perform token manipulation as part of routine system maintenance or software updates. 
+- Another potential false positive scenario could involve automated scripts or security tools that perform token manipulation for legitimate security testing or monitoring purposes.
+- To manage these false positives, users can create exceptions for specific user accounts or processes that are known to perform legitimate token manipulation. This can be done by adding these accounts or processes to an allowlist within the Elastic Endgame configuration.
+- Users should regularly review and update the allowlist to ensure that only verified and non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+- It is also recommended to conduct periodic audits of the exceptions to confirm that no unauthorized or suspicious activities are being inadvertently allowed.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Conduct a thorough investigation to determine the scope of the attack, focusing on identifying compromised accounts and any unauthorized changes made to the system.
+- Reset passwords for all affected accounts and implement multi-factor authentication to enhance security and prevent future unauthorized access.
+- Review and analyze logs from Elastic Endgame and other security tools to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to ensure comprehensive remediation efforts.
+- Restore the system to its operational state by removing any malicious artifacts, applying necessary patches, and verifying the integrity of critical system files.
+- Implement enhanced logging policies to capture detailed information on access token usage and other relevant security events for future investigations.
+- Integrate additional security solutions, such as endpoint detection and response (EDR) tools, to improve visibility and detection capabilities for similar threats.
+- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
+- Educate users on recognizing phishing attempts and other common attack vectors to reduce the risk of credential manipulation in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
index 2e8870a4bed..adfeb2d8df6 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,49 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Permission Theft - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that monitors and detects suspicious activities, such as permission theft, within an environment. Adversaries may exploit access token manipulation to escalate privileges, gaining unauthorized access to resources. The detection rule identifies such threats by analyzing alert events related to token protection, leveraging specific event actions and metadata to pinpoint malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather initial context about the alert.
+- Examine the event.kind field to confirm that the alert is indeed an alert type and not a false positive or benign event.
+- Check the event.module field to ensure the alert is generated by the endgame module, confirming the source of the detection.
+- Analyze the endgame.metadata.type field to verify that the alert is categorized as a detection, indicating a potential security threat.
+- Investigate the event.action and endgame.event_subtype_full fields to determine if the alert is related to token_protection_event, which is indicative of potential access token manipulation.
+- Correlate the alert with other related events in the same timeframe to identify any patterns or additional suspicious activities that might be associated with the permission theft.
+- Use Osquery to gather more information about the processes and tokens involved. For example, run the following Osquery query to list processes with suspicious token privileges: `SELECT pid, name, path, uid, gid FROM processes WHERE on_disk = 1 AND (name LIKE '%token%' OR path LIKE '%token%');`
+- Investigate the user account associated with the alert to determine if there are any signs of compromise or unauthorized access attempts.
+- Review system logs and security logs for any anomalies or unusual activities around the time of the alert to gather additional context.
+- Cross-reference the alert with known MITRE ATT&CK techniques, specifically Privilege Escalation (TA0004) and Access Token Manipulation (T1134), to understand the potential tactics and techniques used by the adversary.
+
+### False positive analysis
+
+- Known false positives for the Permission Theft - Detected - Elastic Endgame rule may include legitimate administrative actions where access tokens are manipulated as part of routine system maintenance or software updates. 
+- Security tools or scripts that automate token management for legitimate purposes might trigger alerts, as they can mimic the behavior of malicious token manipulation.
+- To manage these false positives, users can create exceptions for specific processes or scripts that are known to perform legitimate token manipulation. This can be done by identifying the process names or hashes and excluding them from triggering alerts.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+- Implementing a baseline of normal token manipulation activities within the environment can help in distinguishing between legitimate and suspicious actions, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Conduct a thorough investigation to identify the source and scope of the permission theft, focusing on the compromised access tokens and any associated user accounts.
+- Revoke and reset credentials for any compromised accounts and invalidate any active sessions to prevent further exploitation.
+- Review and analyze security logs and alerts to identify any additional suspicious activities or indicators of compromise related to access token manipulation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources or expertise are required.
+- Implement enhanced logging and monitoring policies to capture detailed information on access token usage and privilege escalation attempts for future investigations.
+- Integrate additional security tools and solutions, such as endpoint detection and response (EDR) and security information and event management (SIEM) systems, to improve detection and response capabilities.
+- Restore the affected system to its operational state by applying security patches, updating software, and ensuring all security configurations are properly set.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as enforcing least privilege access and multi-factor authentication.
+- Educate and train employees on recognizing and reporting suspicious activities, emphasizing the importance of maintaining strong, unique passwords and adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
index 24e914d7863..90427a56d12 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,48 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Permission Theft - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution that prevents unauthorized access by monitoring and blocking attempts to manipulate access tokens, a common method for privilege escalation. Adversaries exploit token manipulation to gain elevated permissions illicitly. The detection rule identifies and alerts on such attempts by focusing on specific event types and actions related to token protection, ensuring swift response to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `event.kind:alert`, `event.module:endgame`, and `endgame.metadata.type:prevention` fields to confirm the alert is related to a prevention event.
+- Examine the `event.action:token_protection_event` or `endgame.event_subtype_full:token_protection_event` fields to identify the specific type of token manipulation attempt that was prevented.
+- Check the timestamp of the alert to determine when the unauthorized access attempt occurred and correlate it with other events in the same timeframe.
+- Investigate the source and destination IP addresses associated with the alert to identify potential malicious actors or compromised systems.
+- Analyze the user account involved in the alert to determine if it has been used in other suspicious activities or if it has been compromised.
+- Use Osquery to gather additional context about the system involved. For example, run the following query to list recent processes that might have been involved in token manipulation: `SELECT pid, name, path, cmdline FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
+- Review system logs and security logs for any other unusual activities or anomalies around the time of the alert to identify potential patterns or related incidents.
+- Investigate any recent changes to user permissions or access rights that could have facilitated the token manipulation attempt.
+- Check for any known vulnerabilities or exploits that might have been used in conjunction with the token manipulation attempt to gain unauthorized access.
+- Collaborate with other security teams or stakeholders to gather additional insights or context that might aid in understanding the scope and impact of the attempted permission theft.
+
+### False positive analysis
+
+- Known false positives for the Permission Theft - Prevented - Elastic Endgame rule may include legitimate administrative actions where access tokens are manipulated as part of routine system maintenance or software updates. These actions can trigger alerts if they mimic the behavior of token manipulation used in privilege escalation.
+- To manage these false positives, users can create exceptions for specific processes or users that are known to perform legitimate token manipulations. This can be done by identifying the event.action or endgame.event_subtype_full values associated with these benign activities and excluding them from triggering alerts.
+- Another approach is to monitor the frequency and context of the alerts. If certain actions consistently trigger alerts but are verified as non-threatening, users can adjust the detection rule to exclude these specific scenarios, ensuring that only genuine threats are flagged.
+- It is important to regularly review and update the list of exceptions to ensure that new legitimate behaviors are accounted for while maintaining the integrity of the security monitoring system.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and method of the token manipulation attempt, utilizing logs and alerts from Elastic Endgame.
+- Review user accounts and permissions to ensure no unauthorized changes have been made; reset credentials if necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed information on access token usage and manipulation attempts for future investigations.
+- Integrate Elastic Endgame with other security tools such as SIEMs to improve threat detection and response capabilities.
+- Restore the system to its operational state by applying patches, updates, and verifying the integrity of critical system files.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate users on the importance of secure credential management and the risks associated with token manipulation.
+- Implement hardening measures such as enforcing multi-factor authentication and least privilege access to reduce the risk of future privilege escalation attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
index 1eea20d6f70..3144f896d85 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,48 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Injection - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that identifies malicious activities like process injection, a technique where adversaries inject code into legitimate processes to evade detection and escalate privileges. This detection rule leverages alerts from the Endgame module, focusing on kernel shellcode events, to identify suspicious process injection attempts, aligning with MITRE ATT&CK's T1055 technique for privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather initial context about the detected process injection.
+- Examine the event.kind, event.module, and endgame.metadata.type fields to confirm the alert is a detection type and is related to the Endgame module, ensuring the alert is relevant to process injection.
+- Analyze the event.action and endgame.event_subtype_full fields to verify the presence of kernel_shellcode_event, which indicates a potential process injection attempt.
+- Investigate the parent and child processes involved in the alert by reviewing process lineage data to identify any unusual or unexpected process relationships.
+- Use Osquery to gather additional information about the processes involved. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, ppid, name, path, cmdline FROM processes WHERE pid = <suspicious_process_id>;`
+- Check for any recent changes or anomalies in the system's process tree around the time of the alert to identify any suspicious activities or patterns.
+- Review the system's security logs and any other relevant logs for additional indicators of compromise or related suspicious activities around the time of the alert.
+- Investigate the user account context under which the suspicious process was executed to determine if there are any signs of account compromise or misuse.
+- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
+- Document all findings and observations during the investigation to maintain a comprehensive record for further analysis or escalation if needed.
+
+### False positive analysis
+
+- Known false positives for the Process Injection - Detected - Elastic Endgame rule may include legitimate software that uses process injection techniques for benign purposes, such as security tools, performance monitoring software, or certain types of debugging applications. These applications might trigger alerts due to their use of kernel shellcode events, which are also used by malicious actors.
+- To manage these false positives, users can create exceptions for specific processes or applications that are known to use process injection legitimately. This can be done by identifying the process names or hashes of the trusted applications and adding them to an exclusion list within the Elastic Endgame configuration. This approach helps in reducing noise and focusing on truly suspicious activities.
+- Regularly review and update the exception list to ensure that only verified and trusted applications are excluded. This helps maintain a balance between minimizing false positives and ensuring that new threats are not overlooked.
+- Collaborate with IT and security teams to understand the context of the detected process injection events, ensuring that any exclusions made do not inadvertently allow malicious activities to go undetected.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the threat and to contain the malicious activity.
+- Conduct a thorough investigation to identify the source and scope of the process injection, utilizing forensic tools to analyze memory dumps and process trees.
+- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has established persistence mechanisms.
+- Review and update endpoint detection and response (EDR) policies to ensure comprehensive logging of process creation, network connections, and code injection attempts.
+- Implement additional security measures such as application whitelisting and enhanced monitoring of high-risk processes to prevent future process injection attempts.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users on recognizing signs of potential compromise and encourage reporting of suspicious activities to improve early detection.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework into security operations to enhance detection capabilities and contextual understanding of threats."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
index 8b96514519b..79c2c31346f 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,46 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Injection - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution that prevents malicious activities like process injection, a technique where adversaries insert code into legitimate processes to evade detection and escalate privileges. Attackers exploit this to execute arbitrary code stealthily. The detection rule identifies such threats by monitoring alerts for specific kernel shellcode events, indicating a prevention action against process injection attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on fields like `event.kind`, `event.module`, `endgame.metadata.type`, and `event.action` to confirm the nature of the prevention.
+- Examine the `endgame.event_subtype_full` field to verify if the alert is related to a `kernel_shellcode_event`, which indicates a process injection attempt.
+- Check the timestamp of the alert to determine when the process injection attempt occurred and correlate it with other events in the system around the same time.
+- Identify the process targeted by the injection attempt by reviewing process-related fields such as `process.name`, `process.pid`, and `process.executable`.
+- Investigate the parent process using `process.parent.name` and `process.parent.pid` to understand the process hierarchy and identify potential sources of the injection attempt.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list open network connections for the process: `SELECT * FROM process_open_sockets WHERE pid = <process.pid>;`.
+- Analyze the user context under which the process was running by examining fields like `user.name` and `user.id` to assess if the user account might have been compromised.
+- Review recent login events and user activity logs to identify any suspicious behavior or unauthorized access attempts that could be related to the process injection.
+- Cross-reference the alert with other security tools and logs, such as firewall logs or intrusion detection systems, to identify any related suspicious activities or patterns.
+- Document all findings and observations, including any anomalies or patterns, to build a comprehensive understanding of the incident and facilitate further investigation if needed.
+
+### False positive analysis
+
+- Known false positives for the Process Injection - Prevented - Elastic Endgame rule may include legitimate software that uses process injection techniques for benign purposes, such as certain security tools, software debuggers, or performance monitoring applications. These applications might trigger alerts due to their behavior, which resembles malicious process injection.
+- To manage these false positives, users can create exceptions for specific applications or processes that are known to use process injection legitimately. This can be done by identifying the process names or hashes of the trusted applications and adding them to an exclusion list within the Elastic Endgame configuration. This approach helps in reducing noise and focusing on genuine threats while maintaining security efficacy.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the threat.
+- Conduct a thorough investigation to identify the source and scope of the process injection attempt, using available logs and alerts.
+- Analyze the process and code involved in the injection attempt to understand the attacker's objectives and methods.
+- Remove any malicious code or unauthorized changes identified during the investigation from the affected system.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the attacker.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response if necessary.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve threat detection and response capabilities.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure all security measures are in place.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/collection_email_outlook_mailbox_via_com.toml b/rules/windows/collection_email_outlook_mailbox_via_com.toml
index feb34e149a7..5f904f083f1 100644
--- a/rules/windows/collection_email_outlook_mailbox_via_com.toml
+++ b/rules/windows/collection_email_outlook_mailbox_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/06/20"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,48 @@ sequence with maxspan=1m
 [process where host.os.type == "windows" and event.action == "start" and process.name : "OUTLOOK.EXE" and
   process.Ext.effective_parent.name != null] by process.Ext.effective_parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Inter-Process Communication via Outlook
+
+Outlook's Component Object Model (COM) allows inter-process communication, enabling applications to automate tasks like email management. Adversaries exploit this by using unusual processes to interact with Outlook, potentially accessing sensitive emails or sending messages without user consent. The detection rule identifies such anomalies by monitoring unexpected processes initiating communication with Outlook, focusing on untrusted or newly created executables, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process that initiated communication with Outlook, focusing on the `process.name` and `process.entity_id` fields.
+- Check the `process.code_signature.trusted` and `process.code_signature.exists` fields to determine if the initiating process is signed and trusted. Investigate any unsigned or untrusted processes further.
+- Analyze the `process.Ext.relative_file_creation_time` and `process.Ext.relative_file_name_modify_time` fields to assess if the process is newly created or recently modified, which could indicate suspicious activity.
+- Examine the `process.Ext.effective_parent.name` and `process.Ext.effective_parent.entity_id` fields to identify the parent process of Outlook and determine if it is expected or unusual.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes and their parent processes: `SELECT pid, name, path, parent FROM processes WHERE name = '<suspicious_process_name>';`.
+- Investigate the network activity of the suspicious process using network monitoring tools to check for any unusual outbound connections that could indicate data exfiltration.
+- Review recent email activity in Outlook to identify any unauthorized access or email sending that aligns with the timeline of the suspicious process execution.
+- Check the system's event logs for any additional indicators of compromise or related suspicious activities around the time the alert was triggered.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack campaign.
+- Document all findings and observations in a detailed report to provide context for further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools may trigger the rule if they interact with Outlook using COM, especially if they are newly created or lack a trusted code signature. Users should review these scripts and, if deemed safe, add them to an exception list to prevent future alerts.
+- Software updates or installations might temporarily create new executables that interact with Outlook, leading to false positives. Monitoring the frequency and context of these alerts can help determine if they are benign, and trusted software can be whitelisted.
+- Custom business applications that automate email tasks via Outlook may be flagged if they are not widely recognized or lack a valid code signature. Users should verify the legitimacy of these applications and consider excluding them from the rule if they are part of regular business operations.
+- In environments where developers frequently test new applications or scripts that interact with Outlook, these activities might be mistakenly identified as threats. Establishing a process to review and approve these activities can help in creating appropriate exceptions.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the suspicious process and determine if any sensitive information was accessed or exfiltrated.
+- Terminate any malicious or suspicious processes identified during the investigation to prevent further malicious activity.
+- Review email logs and Outlook activity to identify any unauthorized access or email transmissions.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and inter-process communication events for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by applying necessary patches, updates, and security configurations.
+- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities or misconfigurations.
+- Implement hardening measures such as application whitelisting, endpoint detection and response (EDR) solutions, and user training to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/collection_posh_webcam_video_capture.toml b/rules/windows/collection_posh_webcam_video_capture.toml
index a0006542832..f723df35eaf 100644
--- a/rules/windows/collection_posh_webcam_video_capture.toml
+++ b/rules/windows/collection_posh_webcam_video_capture.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/18"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -67,6 +67,53 @@ event.category:process and host.os.type:windows and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Webcam Video Capture Capabilities
+
+PowerShell, a powerful scripting language in Windows, can interface with system components like webcams. Adversaries exploit this by scripting webcam access to capture video, potentially for espionage or extortion. The detection rule identifies scripts using specific webcam-related functions and libraries, flagging suspicious activity indicative of video capture attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific PowerShell script block text that triggered the detection, focusing on keywords like "NewFrameEventHandler" or "VideoCaptureDevice".
+- Examine the process execution details, including the parent process, to understand the context in which the PowerShell script was executed.
+- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Investigate the source and integrity of the PowerShell script by reviewing its file path and hash values, if available, to identify any known malicious scripts.
+- Use Osquery to list all running PowerShell processes and their command-line arguments to identify any other suspicious activity:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE name = 'powershell.exe';
+  ```
+- Analyze recent login events and user activity on the host to identify any unauthorized access attempts that could correlate with the script execution.
+- Review network connections initiated by the host around the time of the alert to detect any suspicious outbound traffic that might indicate data exfiltration.
+- Check for any recent changes to webcam-related system settings or drivers that could suggest tampering or unauthorized access attempts.
+- Investigate any other alerts or logs from the same host or user account to identify patterns or additional indicators of compromise.
+- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or threat actor behaviors.
+
+### False positive analysis
+
+- Legitimate software or administrative scripts that utilize webcam functionalities for valid purposes, such as video conferencing applications or security monitoring tools, may trigger this detection rule. 
+- Developers or IT administrators testing webcam integration or functionality in a controlled environment might inadvertently match the rule's criteria.
+- Automated system health checks or diagnostics that access webcam components to verify hardware status could be flagged as suspicious.
+- To manage these false positives, users can create exceptions for known and trusted scripts or applications by whitelisting specific script hashes or paths.
+- Regularly review and update the exclusion list to ensure that only verified non-threatening activities are exempted, maintaining a balance between security and operational needs.
+- Implement logging and monitoring to track the behavior of excluded scripts, ensuring they do not deviate from expected patterns or access unauthorized resources.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the presence of malicious PowerShell scripts by reviewing script block logs and process execution details.
+- Terminate any suspicious PowerShell processes identified during the investigation to halt ongoing malicious activities.
+- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.
+- Reset credentials and review user account permissions on the affected system to ensure no unauthorized access persists.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed PowerShell activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Restore the system from a known good backup to ensure the removal of any persistent threats and return the system to its operational state.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
+- Educate users on recognizing phishing attempts and suspicious activities to reduce the risk of future incidents involving unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
index 915c09f4456..bbb27bd1ba1 100644
--- a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
+++ b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,50 @@ network where host.os.type == "windows" and network.protocol == "dns" and
   /* Insert noisy false positives here */
   not process.name : ("svchost.exe", "MicrosoftEdge*.exe", "msedge.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Connection to Commonly Abused Free SSL Certificate Providers
+
+Free SSL certificates, like those from Let's Encrypt, enable secure web traffic by encrypting data. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process executable path and domain name involved in the connection attempt. Focus on the `process.executable` and `dns.question.name` fields.
+- Verify the legitimacy of the domain by checking if it is associated with known malicious activities or if it is a legitimate service using free SSL certificates.
+- Investigate the process executable path to determine if it is a legitimate Windows process or if it has been tampered with. Pay attention to the paths specified in the query, such as `C:\\Windows\\System32\\*.exe`.
+- Use Osquery to gather additional context about the process. For example, run the following query to get details about the process and its parent process:
+  ```sql
+  SELECT pid, name, path, parent, cmdline FROM processes WHERE path = 'C:\\\\Windows\\\\System32\\\\<specific_process>.exe';
+  ```
+- Check the process's parent process to understand how it was spawned and if it aligns with expected behavior.
+- Examine the network traffic associated with the process to identify any unusual patterns or additional connections to suspicious domains.
+- Cross-reference the process and domain information with threat intelligence sources to identify any known indicators of compromise (IOCs).
+- Review system logs and event logs for any additional suspicious activities or anomalies around the time of the alert.
+- Investigate the user account associated with the process to determine if there are any signs of compromise or unauthorized access.
+- Consider running a full antivirus or endpoint detection and response (EDR) scan on the affected system to identify any additional threats or malware.
+
+### False positive analysis
+
+- **Common System Processes**: Some native Windows processes, such as `svchost.exe`, `MicrosoftEdge*.exe`, and `msedge.exe`, are known to generate network traffic that may appear suspicious but are typically benign. These processes are often involved in legitimate system operations and updates, which can include accessing domains secured with free SSL certificates.
+- **Web Browsers and Updates**: Web browsers and system update services frequently connect to a variety of domains, including those using free SSL certificates, for legitimate purposes such as downloading updates or accessing web content. These activities can trigger false positives if not properly excluded.
+- **Handling False Positives**: Users can manage false positives by creating exceptions for known benign processes and domains. This involves updating the detection rule to exclude specific process names or paths that are frequently involved in non-threatening activities. Regularly reviewing and updating these exceptions based on observed network behavior can help maintain the accuracy of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement.
+- Conduct a thorough investigation of the flagged process and domain connections to determine if they are indeed malicious or false positives.
+- Review and analyze network traffic logs to identify any additional suspicious activities or connections related to the alert.
+- If malicious activity is confirmed, terminate the suspicious processes and remove any associated malicious files or software from the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
+- Integrate threat intelligence feeds to update and refine detection rules with the latest indicators of compromise (IOCs) related to free SSL certificate abuse.
+- Restore the system to its operational state by applying necessary patches, updates, and verifying the integrity of system files.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as application whitelisting, network segmentation, and regular security audits to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_iexplore_via_com.toml b/rules/windows/command_and_control_iexplore_via_com.toml
index 79424244132..099539a7ed3 100644
--- a/rules/windows/command_and_control_iexplore_via_com.toml
+++ b/rules/windows/command_and_control_iexplore_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,52 @@ sequence by host.id, user.name with maxspan = 5s
     )
   ] /* with runs=5 */
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Command and Control via Internet Explorer
+
+Internet Explorer can be manipulated through the Component Object Model (COM) to initiate network connections, potentially bypassing security measures. Adversaries exploit this by embedding IE in processes like rundll32.exe, making unusual DNS requests. The detection rule identifies such anomalies by monitoring for IE's unexpected network activity, excluding legitimate Microsoft-related domains, to flag potential command and control activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of Internet Explorer (iexplore.exe) being started via the Component Object Model (COM) with unusual network activity.
+- Verify the parent process of Internet Explorer by checking if it was started by processes like rundll32.exe or regsvr32.exe, as indicated in the query.
+- Examine the command-line arguments of the parent process to ensure it includes the "-Embedding" argument, which suggests COM usage.
+- Investigate the DNS requests made by Internet Explorer to identify any suspicious or non-whitelisted domains, as specified in the query.
+- Use Osquery to gather additional context on the processes involved. For example, run the following query to list processes with their parent process IDs and command-line arguments:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'iexplore.exe' OR name = 'rundll32.exe' OR name = 'regsvr32.exe';
+  ```
+- Check the network connections established by Internet Explorer using network monitoring tools or logs to identify any unusual or unexpected connections.
+- Correlate the timeline of the alert with other security events or logs to identify any related suspicious activities or anomalies on the host.
+- Investigate the user context (user.name) under which the suspicious processes were executed to determine if it aligns with expected user behavior.
+- Review the host's security posture and configuration to identify any potential vulnerabilities or misconfigurations that could have been exploited.
+- Consult threat intelligence sources to determine if the identified domains or IP addresses are associated with known malicious activities or command and control infrastructure.
+
+### False positive analysis
+
+- Legitimate enterprise applications may use Internet Explorer via COM for internal processes, leading to false positives if these applications frequently access non-Microsoft domains.
+- Automated scripts or administrative tools that leverage Internet Explorer for network tasks could trigger alerts if they connect to internal or third-party services not listed in the exclusion list.
+- Users can manage false positives by identifying and documenting regular network patterns of known safe applications and adding these domains to the exclusion list in the detection rule.
+- Regularly review and update the exclusion list to include any new legitimate domains that are frequently accessed by Internet Explorer in the organization’s environment.
+- Consider implementing a whitelist approach for specific processes or network activities that are known to be safe, reducing the likelihood of false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further command and control communication.
+- Conduct a thorough investigation to identify any additional compromised systems by reviewing network logs and endpoint detection data.
+- Terminate any suspicious processes associated with Internet Explorer and COM objects, such as rundll32.exe or regsvr32.exe, that are not part of legitimate operations.
+- Remove any unauthorized or malicious COM objects and DLLs, such as IEProxy.dll, from the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
+- Implement enhanced logging policies to capture detailed process creation, network connections, and DNS queries for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Apply security patches and updates to Internet Explorer and the operating system to mitigate known vulnerabilities.
+- Educate users on the risks of using outdated browsers and encourage the use of more secure alternatives to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_outlook_home_page.toml b/rules/windows/command_and_control_outlook_home_page.toml
index e91e82eb0d6..9a3c4225444 100644
--- a/rules/windows/command_and_control_outlook_home_page.toml
+++ b/rules/windows/command_and_control_outlook_home_page.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/01"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,48 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
         "USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL"
     ) and registry.data.strings : "*http*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Outlook Home Page Registry Modification
+
+The Outlook Home Page feature allows users to set a webpage as the default view for folders, enhancing productivity. However, adversaries can exploit this by modifying registry keys to redirect to malicious URLs, enabling command and control or persistence. The detection rule identifies suspicious registry changes by monitoring specific paths and URL patterns, alerting analysts to potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path and URL involved in the modification, focusing on the `registry.path` and `registry.data.strings` fields.
+- Verify the legitimacy of the URL by checking if it is a known or trusted domain, and assess its reputation using threat intelligence sources.
+- Examine the user account associated with the registry modification to determine if it aligns with expected behavior or if it appears suspicious.
+- Check the modification timestamp to correlate with any known user activity or scheduled tasks that might explain the change.
+- Investigate the host machine for any other signs of compromise, such as unusual network connections or processes, using endpoint detection tools.
+- Utilize Osquery to further inspect the registry changes with a query like: `SELECT * FROM registry WHERE path LIKE 'HKCU\\\\%\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\%\\\\Outlook\\\\Webview\\\\Inbox\\\\URL';` to gather more context on the modification.
+- Cross-reference the registry modification with recent email activity in Outlook to identify any potential phishing attempts or malicious emails that could have led to the change.
+- Analyze system logs for any other registry changes or suspicious activities around the same time frame to identify potential patterns or related incidents.
+- Investigate any recent software installations or updates on the host that might have inadvertently caused the registry modification.
+- Consult with the user or IT support to verify if the change was intentional or part of a legitimate configuration change.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify the Outlook Home Page registry keys, leading to false positives. Users should verify if recent updates or installations correspond with the detected changes.
+- Custom organizational policies or scripts that configure Outlook settings for productivity purposes might trigger alerts. Analysts should review these policies and consider excluding known safe configurations.
+- Users who frequently change their Outlook Home Page settings for personalization might inadvertently cause alerts. Monitoring user behavior patterns can help distinguish between benign and suspicious activities.
+- To manage false positives, users can create exceptions for known safe registry paths or URL patterns that are frequently modified by trusted applications or processes. This can be done by updating the detection rule to exclude these specific cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further command and control communication.
+- Conduct a thorough investigation to identify any additional compromised systems by reviewing logs and alerts related to the registry modification.
+- Verify the legitimacy of the URL set in the registry and remove or correct any unauthorized or malicious entries.
+- Restore the registry settings to their default state using a known good backup or by manually resetting the affected keys.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed registry changes and network traffic for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Apply security patches and updates to the operating system and Outlook to mitigate known vulnerabilities.
+- Educate users on recognizing phishing attempts and suspicious activities that could lead to registry modifications.
+- Consider deploying application whitelisting and endpoint detection and response (EDR) solutions to prevent unauthorized changes and enhance system hardening."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_screenconnect_childproc.toml b/rules/windows/command_and_control_screenconnect_childproc.toml
index 890ac2e7d0f..1ae6e98f4ff 100644
--- a/rules/windows/command_and_control_screenconnect_childproc.toml
+++ b/rules/windows/command_and_control_screenconnect_childproc.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,49 @@ process where host.os.type == "windows" and event.type == "start" and
                    "ssh.exe", "scp.exe", "wevtutil.exe", "wget.exe", "wmic.exe")
    )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious ScreenConnect Client Child Process
+
+ScreenConnect, a remote access tool, facilitates legitimate remote support by allowing users to control systems remotely. However, adversaries can exploit it to execute unauthorized commands, leveraging its access capabilities. The detection rule identifies unusual child processes spawned by ScreenConnect, such as PowerShell or cmd.exe, which may indicate malicious activity, by monitoring specific process names and arguments that are commonly used in attacks.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific child process and arguments that triggered the rule, focusing on the `process.name` and `process.args` fields.
+- Check the parent process details, specifically the `process.parent.name`, to confirm it is one of the ScreenConnect client processes listed in the query.
+- Investigate the user account associated with the process execution to determine if it aligns with expected usage patterns or if it appears suspicious.
+- Examine the network activity around the time of the alert to identify any unusual connections or data transfers, especially those involving external IP addresses.
+- Use Osquery to gather additional context on the suspicious process. For example, run the following query to list all processes spawned by ScreenConnect clients: `SELECT pid, name, path, cmdline FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name IN ('ScreenConnect.ClientService.exe', 'ScreenConnect.WindowsClient.exe', 'ScreenConnect.WindowsBackstageShell.exe', 'ScreenConnect.WindowsFileManager.exe'));`
+- Analyze the command-line arguments (`process.args`) for any encoded or obfuscated content, particularly if PowerShell is involved, to understand the intent of the command.
+- Check for any recent changes to scheduled tasks or services on the host, especially if `schtasks.exe` or `sc.exe` were involved, to identify potential persistence mechanisms.
+- Review the system's event logs for any additional context or anomalies around the time of the alert, focusing on security and application logs.
+- Investigate any file modifications or creations that occurred around the time of the alert, especially if `msiexec.exe` or `rundll32.exe` were involved, to identify potential payloads or malicious files.
+- Correlate the alert with other security events or alerts in your environment to determine if this is part of a broader attack campaign or isolated incident.
+
+### False positive analysis
+
+- Legitimate IT support activities: ScreenConnect is often used by IT support teams to perform legitimate tasks that may involve running scripts or commands, such as PowerShell or cmd.exe, which can trigger the detection rule. Users can handle these by creating exceptions for known IT support activities or specific user accounts that regularly perform these tasks.
+- Automated maintenance scripts: Organizations may have automated scripts that run through ScreenConnect for system maintenance or updates, which could be flagged as suspicious. To manage this, users can exclude specific scripts or processes that are verified as part of routine maintenance.
+- Software installations and updates: ScreenConnect might be used to deploy software updates or installations that involve processes like msiexec.exe, which could be misidentified as malicious. Users should document and exclude these known software deployment activities from the detection rule.
+- Remote troubleshooting: During remote troubleshooting sessions, support staff might use tools like net.exe or schtasks.exe to diagnose and fix issues, which could be mistaken for malicious activity. Users can create exceptions for these processes when executed by trusted support personnel.
+- Custom scripts or tools: Organizations may use custom scripts or third-party tools that are executed via ScreenConnect for specific business needs. Users should review and whitelist these custom tools to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the legitimacy of the ScreenConnect activity by reviewing logs and correlating with authorized access requests.
+- Terminate any suspicious processes identified in the alert, such as PowerShell or cmd.exe, that were spawned by ScreenConnect.
+- Analyze the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts.
+- Reset credentials for any accounts that may have been compromised, focusing on those with administrative privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing multi-factor authentication for remote access tools like ScreenConnect."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_tunnel_vscode.toml b/rules/windows/command_and_control_tunnel_vscode.toml
index d40001f8bc6..ada93724c9d 100644
--- a/rules/windows/command_and_control_tunnel_vscode.toml
+++ b/rules/windows/command_and_control_tunnel_vscode.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,48 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and 
   not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Establish VScode Remote Tunnel
+
+Visual Studio Code (VSCode) offers a feature to establish remote tunnels, enabling developers to connect to remote environments seamlessly. This functionality, while beneficial for legitimate remote development, can be exploited by adversaries to gain unauthorized access or control over systems. The detection rule identifies suspicious attempts by monitoring the execution of VSCode binaries with specific command-line arguments indicative of tunnel creation, excluding benign processes, thus helping to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the "tunnel" command-line argument in the process execution, as this is a key indicator of a potential remote tunnel attempt.
+- Verify the process name to ensure it matches "code*.exe" and check if the process arguments include "--accept-server-license-terms," which could indicate an attempt to establish a remote connection.
+- Examine the parent process name to determine if it is "Code.exe," as this could help differentiate between legitimate and suspicious activity.
+- Check the process execution time and correlate it with user activity logs to determine if the execution aligns with expected user behavior or work hours.
+- Investigate the user account associated with the process execution to verify if the user has a legitimate reason to establish a remote tunnel.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with the "tunnel" argument: `SELECT pid, name, path, cmdline, parent FROM processes WHERE cmdline LIKE '%tunnel%';`
+- Analyze network logs to identify any unusual outbound connections initiated by the process, focusing on connections to known VSCode or GitHub endpoints.
+- Review system logs for any recent changes or installations that might explain the presence of the VSCode remote tunnel feature.
+- Check for any recent alerts or incidents involving the same user or system to identify patterns or repeated suspicious behavior.
+- Consult with the user or system owner to gather additional context about the necessity and legitimacy of the remote tunnel attempt, if possible.
+
+### False positive analysis
+
+- Developers frequently using VSCode for legitimate remote development may trigger this rule when establishing remote tunnels for valid purposes, such as connecting to a remote development environment or a GitHub Codespace.
+- Automated scripts or CI/CD pipelines that utilize VSCode's remote capabilities for deployment or testing can also generate false positives if they include the tunnel command-line arguments.
+- To manage these false positives, users can create exceptions for specific processes or users known to regularly perform legitimate remote development activities. This can be done by excluding certain process names or command-line arguments that are consistently associated with non-threatening behavior.
+- Monitoring the frequency and context of alerts can help distinguish between legitimate use and potential threats. Users can adjust the detection rule to ignore processes initiated by trusted users or systems, reducing unnecessary alerts while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the intrusion, including identifying any other systems that may have been compromised.
+- Review system logs and VSCode activity to trace the origin of the tunnel creation attempt and gather evidence for further analysis.
+- Terminate any unauthorized VSCode remote tunnel sessions and remove any malicious binaries or scripts found on the system.
+- Change all credentials and access tokens that may have been exposed or compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
+- Implement enhanced logging policies to capture detailed process execution and network activity related to VSCode and other remote access tools.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by reinstalling affected software and applying the latest security patches and updates.
+- Harden the system by disabling unnecessary remote access features, enforcing strong authentication mechanisms, and conducting regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_adidns_wildcard.toml b/rules/windows/credential_access_adidns_wildcard.toml
index 7b42d66d267..7dec77c586d 100644
--- a/rules/windows/credential_access_adidns_wildcard.toml
+++ b/rules/windows/credential_access_adidns_wildcard.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,49 @@ query = '''
 any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and
     event.code == "5137" and startsWith(winlog.event_data.ObjectDN, "DC=*,")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential ADIDNS Poisoning via Wildcard Record Creation
+
+Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create wildcard DNS records, redirecting traffic and enabling man-in-the-middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes, focusing on suspicious wildcard record creation activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event code "5137" and ensure the event action is either "Directory Service Changes" or "directory-service-object-modified".
+- Examine the `winlog.event_data.ObjectDN` field to identify the specific DNS object that was modified, ensuring it starts with "DC=*," which indicates a wildcard record.
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time for additional context.
+- Identify the user account associated with the event to determine if it is a legitimate account or potentially compromised. Look for anomalies in the account's recent activities.
+- Investigate the source IP address and hostname from which the change was made to verify if it is a known and trusted system within the network.
+- Use Osquery to gather additional information about the system involved. For example, run the following query to list recent DNS changes on the system: `SELECT * FROM dns_cache WHERE name LIKE '%';`
+- Analyze network traffic logs to identify any unusual DNS queries or redirections that might indicate exploitation of the wildcard record.
+- Cross-reference the event with other security logs, such as authentication logs, to identify any suspicious login attempts or lateral movement activities.
+- Check for any other recent changes in the DNS zone that might indicate a broader attack or misconfiguration.
+- Consult with the system administrators to verify if the DNS change was authorized and part of a legitimate configuration update.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or changes made by IT administrators to DNS records can trigger this rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated system processes: Some automated processes or scripts that modify DNS records as part of their normal operation may be flagged. Identify these processes and exclude them by their specific attributes, such as the account or system name.
+- Legitimate software installations: Certain software installations or updates may modify DNS settings, leading to false positives. Monitor installation logs and exclude these events if they align with known software changes.
+- Internal network changes: Changes in network infrastructure, such as the addition of new subdomains or services, might be misinterpreted as suspicious. Document these changes and adjust the rule to recognize them as non-threatening.
+- Testing environments: Activities in testing or development environments can mimic suspicious behavior. Clearly separate these environments in monitoring tools and apply different rules or exceptions to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further exploitation of the wildcard DNS records.
+- Conduct a thorough investigation to identify the source of the unauthorized DNS record creation, focusing on recent changes and user activities.
+- Review and audit Active Directory permissions, specifically for DNS record creation, to ensure that only authorized personnel have the necessary access.
+- Remove any unauthorized wildcard DNS records and verify the integrity of existing DNS records to ensure they have not been tampered with.
+- Implement enhanced logging and monitoring for DNS changes, including enabling detailed auditing of directory service changes to capture future unauthorized modifications.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
+- Escalate the incident to the security operations center (SOC) and, if necessary, involve incident response teams to handle potential data breaches.
+- Restore affected systems to their operational state by applying clean backups and verifying system integrity.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting DNS zone transfers, applying least privilege principles, and regularly reviewing and updating security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_adidns_wpad_record.toml b/rules/windows/credential_access_adidns_wpad_record.toml
index 94388242ee5..ba11a1ce67e 100644
--- a/rules/windows/credential_access_adidns_wpad_record.toml
+++ b/rules/windows/credential_access_adidns_wpad_record.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -63,6 +63,49 @@ query = '''
 any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and
     event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential WPAD Spoofing via DNS Record Creation
+
+Web Proxy Auto-Discovery (WPAD) helps devices automatically locate proxy configuration files, streamlining network management. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule monitors Windows environments for suspicious DNS record changes, specifically targeting modifications that suggest WPAD spoofing attempts, thereby identifying potential security threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event code "5137" and the modification of the "DC=wpad,*" object in the event data, which indicates a DNS record change related to WPAD.
+- Verify the identity of the user or process that initiated the DNS record change by examining the associated user account details in the event logs.
+- Check the timestamp of the event to determine when the DNS record change occurred and correlate it with other suspicious activities in the network around the same time.
+- Investigate the source IP address and hostname of the system where the DNS record change was initiated to assess if it is a known and trusted device within the network.
+- Utilize Osquery to gather additional context on the system involved. For example, run the following Osquery query to list recent DNS changes: `SELECT * FROM dns_resolvers WHERE domain = 'wpad';`
+- Examine the system's network configuration and proxy settings to identify any unauthorized or unexpected changes that could indicate WPAD exploitation.
+- Cross-reference the event with other security logs, such as firewall or intrusion detection system logs, to identify any related network traffic anomalies or potential lateral movement attempts.
+- Investigate any recent changes to the Global Query Block List (GQBL) settings on the affected system to determine if it was disabled or altered to facilitate WPAD spoofing.
+- Review historical logs for similar DNS record changes or patterns that might suggest a broader or ongoing attack campaign targeting WPAD.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently exploiting WPAD vulnerabilities, and assess if the observed activity aligns with these threats.
+
+### False positive analysis
+
+- Legitimate network changes: Organizations may intentionally create or modify DNS records for WPAD as part of legitimate network configuration or updates. These changes can trigger the detection rule, leading to false positives. To manage this, users can maintain a list of authorized changes and compare them against detected events.
+- Testing and development environments: In environments where network configurations are frequently tested or modified, such as development or testing labs, DNS record changes related to WPAD might be common and benign. Users can create exceptions for these environments to reduce noise.
+- Third-party software: Some network management or security tools might automatically modify DNS records, including WPAD, as part of their operations. Identifying these tools and excluding their actions from the detection rule can help minimize false positives.
+- Temporary network setups: During events like conferences or temporary setups, network administrators might create WPAD records to facilitate proxy configurations. Users should document these temporary changes and exclude them from triggering alerts.
+- Regular audits and reviews: Conducting regular audits of DNS records and reviewing the detection rule's alerts can help distinguish between legitimate changes and potential threats, allowing users to refine exceptions over time.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and data interception.
+- Verify the presence of unauthorized "wpad" DNS records and remove them to mitigate the spoofing attempt.
+- Conduct a thorough investigation to identify the source of the DNS record change, focusing on recent administrative activities and user accounts with elevated privileges.
+- Review and re-enable the Global Query Block List (GQBL) if it has been disabled, ensuring that "wpad" is included to prevent future exploitation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for DNS changes and directory service modifications to detect similar threats in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Restore the system to its operational state by applying security patches, updating configurations, and conducting a full system scan to ensure no malware remains.
+- Educate users and administrators on the risks associated with WPAD and the importance of maintaining secure DNS configurations.
+- Review and update security policies and procedures to include specific measures against WPAD spoofing and related adversary-in-the-middle tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_dcsync_user_backdoor.toml b/rules/windows/credential_access_dcsync_user_backdoor.toml
index 409b70d352e..4d0bf6b3c5d 100644
--- a/rules/windows/credential_access_dcsync_user_backdoor.toml
+++ b/rules/windows/credential_access_dcsync_user_backdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -17,7 +17,50 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Potential Active Directory Replication Account Backdoor"
-note = """## Setup
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Active Directory Replication Account Backdoor
+
+Active Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to grant replication rights to unauthorized accounts, enabling them to extract sensitive credential data. The detection rule identifies suspicious changes to the nTSecurityDescriptor attribute, which could indicate an attempt to establish a backdoor for credential access. By monitoring specific event codes and attribute modifications, the rule helps detect unauthorized replication rights assignments, potentially thwarting credential dumping activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event code 5136, which indicates a directory service object modification, and verify that the modification involves the nTSecurityDescriptor attribute.
+- Examine the specific user or computer account mentioned in the alert to determine if it has been granted unauthorized replication rights, focusing on the presence of the GUIDs: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, and 89e95b76-444d-4c62-991a-0facbeda640c.
+- Check the security logs for any recent logins or activities associated with the suspicious account to identify any unusual patterns or behaviors.
+- Use Osquery to gather additional context about the suspicious account by running a query such as: `SELECT * FROM users WHERE uid = '<suspicious_account_uid>';` to retrieve detailed information about the account.
+- Investigate the history of changes to the nTSecurityDescriptor attribute for the affected domain object to identify any other unauthorized modifications or patterns.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack campaign or isolated incident.
+- Review the Active Directory audit logs to identify any other accounts that may have been granted similar unauthorized replication rights.
+- Analyze network traffic logs to detect any unusual data exfiltration activities that may be associated with the compromised account.
+- Consult with the Active Directory administrators to verify if the changes were authorized or part of a legitimate administrative task.
+- Document all findings and gather evidence to support further investigation or escalation to the appropriate security team.
+
+### False positive analysis
+
+- Routine administrative tasks: Changes to the nTSecurityDescriptor attribute may occur during legitimate administrative activities, such as when IT personnel update permissions for maintenance or configuration purposes. Users can handle these by identifying and excluding known administrative accounts or activities from the detection rule.
+- Software updates and installations: Certain software updates or installations might modify security descriptors as part of their setup process. Users should maintain a list of trusted software and exclude these events when they coincide with known update schedules.
+- Automated scripts and tools: Organizations often use automated scripts or tools for managing AD environments, which might trigger the rule. Users can create exceptions for these scripts by verifying their legitimacy and ensuring they are executed by authorized accounts.
+- Third-party applications: Some third-party applications with legitimate access to AD might modify security descriptors as part of their functionality. Users should review and whitelist these applications after confirming their necessity and security compliance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the unauthorized modification of the nTSecurityDescriptor attribute and identify the compromised account.
+- Review recent changes in Active Directory, focusing on accounts with elevated privileges and any unusual modifications to security descriptors.
+- Revoke any unauthorized replication rights and reset passwords for affected accounts, ensuring they are strong and unique.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging and monitoring for Active Directory changes, specifically targeting event code 5136 and modifications to the nTSecurityDescriptor attribute.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in the future.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Implement hardening measures such as least privilege access, regular audits of privileged accounts, and continuous security awareness training for administrators.
+
+## Setup
 
 The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
 Steps to implement the logging policy with Advanced Audit Configuration:
diff --git a/rules/windows/credential_access_dnsnode_creation.toml b/rules/windows/credential_access_dnsnode_creation.toml
index 912a7da74cc..50914d376d6 100644
--- a/rules/windows/credential_access_dnsnode_creation.toml
+++ b/rules/windows/credential_access_dnsnode_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -67,6 +67,49 @@ any where host.os.type == "windows" and event.action in ("Directory Service Chan
     event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
     not winlog.event_data.SubjectUserName : "*$"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation of a DNS-Named Record
+
+Active Directory Integrated DNS (ADIDNS) leverages Active Directory for DNS zone storage, enhancing domain consistency but posing security risks due to default permissions allowing any authenticated user to create DNS records. Adversaries exploit this by crafting malicious DNS entries for spoofing attacks. The detection rule identifies suspicious DNS record creation by monitoring specific Windows events, filtering out legitimate system accounts to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `event.action`, `event.code`, and `winlog.event_data.ObjectClass` fields to confirm the alert is related to DNS record creation.
+- Verify the `winlog.event_data.SubjectUserName` to identify the user account that initiated the DNS record creation. Investigate if this account is known and authorized to perform such actions.
+- Check the timestamp of the event to determine when the DNS record was created and correlate it with other security events or logs around the same time for additional context.
+- Use Osquery to list all DNS records created recently on the affected system with a query like: `SELECT * FROM dns_resolvers WHERE name = '<suspicious_dns_record>';` to gather more information about the DNS record.
+- Investigate the source IP address associated with the DNS record creation event to determine if it is from a known and trusted network or device.
+- Examine the `winlog.event_data.ObjectClass` field to confirm that the object class is indeed `dnsNode`, ensuring the alert is not a false positive.
+- Cross-reference the DNS record name with known malicious domains or internal blacklists to assess if it is associated with any known threats.
+- Analyze network traffic logs to identify any unusual or unauthorized DNS queries or responses related to the newly created DNS record.
+- Review historical logs for any previous DNS record creation events by the same user or from the same IP address to identify patterns or repeated suspicious activities.
+- Consult with the IT or network team to verify if there were any legitimate changes or updates to DNS records that could explain the alert, ensuring the activity is not part of a planned or authorized operation.
+
+### False positive analysis
+
+- Legitimate system processes or applications that frequently update DNS records may trigger false positives. These can include automated scripts or services that dynamically register DNS entries as part of their normal operation.
+- Regular updates from IT management tools or software deployment systems that modify DNS records for configuration management purposes might be mistakenly flagged as suspicious.
+- Exclude known and trusted system accounts or service accounts that are responsible for legitimate DNS record creation by adding them to an exception list. This can be done by identifying the specific SubjectUserName values associated with these accounts and modifying the detection rule to ignore these entries.
+- Monitor and document routine DNS record changes within the organization to establish a baseline of expected behavior, which can help in distinguishing between legitimate and potentially malicious activities.
+- Collaborate with network and system administrators to identify and whitelist specific DNS record changes that are part of regular maintenance or deployment activities, ensuring these do not trigger unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
+- Conduct a thorough investigation to identify the source of the malicious DNS record creation, focusing on recent changes and the user accounts involved.
+- Review and audit Active Directory permissions to ensure that only authorized users have the ability to create or modify DNS records, reducing the risk of unauthorized changes.
+- Remove any unauthorized or suspicious DNS records identified during the investigation to mitigate the risk of spoofing attacks.
+- Implement enhanced logging and monitoring for DNS record changes, ensuring that all modifications are logged and reviewed regularly for suspicious activity.
+- Integrate security information and event management (SIEM) solutions to correlate DNS activity with other security events, improving detection capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Restore the system to its operational state by applying necessary patches and updates, and ensure that all security configurations are properly set.
+- Educate users on the risks of DNS spoofing and the importance of reporting suspicious activity, enhancing overall security awareness.
+- Implement network segmentation and access controls to limit the impact of potential future attacks, reducing the attack surface available to adversaries."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_dollar_account_relay.toml b/rules/windows/credential_access_dollar_account_relay.toml
index 38245c9dbb2..5aa07fa355f 100644
--- a/rules/windows/credential_access_dollar_account_relay.toml
+++ b/rules/windows/credential_access_dollar_account_relay.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,49 @@ authentication where host.os.type == "windows" and event.code in ("4624", "4625"
     not endswith(string(source.ip), string(host.ip)) and
     source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Relay Attack against a Domain Controller
+
+Domain Controllers (DCs) are critical in managing authentication within Windows environments. Adversaries exploit this by capturing and relaying authentication hashes, particularly using NTLM, to gain unauthorized access. The detection rule identifies suspicious authentication attempts by checking for machine account logins from unexpected sources, indicating potential relay attacks. It focuses on network logon events and mismatched source IPs to flag anomalies.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event codes (4624 or 4625) and ensure they align with the suspicious authentication attempts.
+- Verify the user.name field to confirm it ends with a "$", indicating a machine account, and check if it matches the host.name to ensure it is a legitimate account.
+- Examine the winlog.event_data.AuthenticationPackageName field to confirm the use of NTLM, which is commonly exploited in relay attacks.
+- Analyze the winlog.logon.type field to ensure the logon type is "network", as this is indicative of remote authentication attempts.
+- Investigate the source.ip field to identify the origin of the authentication attempt and determine if it is unexpected or unauthorized.
+- Cross-reference the source.ip with known IP addresses within the organization to identify any anomalies or unauthorized access points.
+- Use Osquery to gather additional context on the source host by running a query such as: `SELECT * FROM logged_in_users WHERE host = '<source.ip>';` to identify any active sessions or unusual user activity.
+- Check for any recent changes or anomalies in the domain controller's security logs that might correlate with the suspicious authentication attempt.
+- Investigate any other recent alerts or incidents involving the same source.ip or user.name to identify potential patterns or repeated attack attempts.
+- Collaborate with network and system administrators to gather additional network traffic logs or endpoint data that might provide further insights into the suspicious activity.
+
+### False positive analysis
+
+- Scheduled tasks or automated processes: Some environments may have scheduled tasks or automated processes that authenticate using machine accounts, which could trigger the rule. Users can handle these by identifying the specific tasks and excluding their source IPs from the detection rule.
+- Backup or monitoring software: Certain backup or monitoring solutions may use machine accounts to authenticate with domain controllers, leading to false positives. Users should identify these software solutions and create exceptions for their known IP addresses.
+- Load balancers or proxy servers: In environments where load balancers or proxy servers are used, the source IP may not match the expected host IP, causing false positives. Users can exclude the IPs of these devices from the rule to prevent unnecessary alerts.
+- Legitimate cross-domain authentication: In some cases, legitimate cross-domain authentication might appear suspicious if machine accounts are used. Users should verify such activities and whitelist the involved IPs if they are deemed non-threatening.
+- Testing or development environments: Activities in testing or development environments might mimic suspicious behavior. Users should consider excluding these environments from the rule or adjusting the rule parameters to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected domain controller from the network to prevent further unauthorized access.
+- Conduct a thorough investigation to identify the source of the relay attack, focusing on the mismatched source IPs and machine account logins.
+- Reset the passwords for all potentially compromised accounts, especially those associated with the domain controller.
+- Review and analyze logs from the domain controller and other relevant systems to trace the attack path and identify any additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed authentication events and network traffic, ensuring that NTLM authentication attempts are closely monitored.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
+- Restore the domain controller to its operational state by applying the latest security patches and updates, and verify the integrity of system files and configurations.
+- Harden the domain controller by disabling NTLM where possible, enforcing strong password policies, and implementing multi-factor authentication (MFA) for administrative access.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans to improve readiness for future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_generic_localdumps.toml b/rules/windows/credential_access_generic_localdumps.toml
index ec951d94d75..48f3cdd79ae 100644
--- a/rules/windows/credential_access_generic_localdumps.toml
+++ b/rules/windows/credential_access_generic_localdumps.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/28"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,48 @@ registry where host.os.type == "windows" and
     registry.data.strings : ("2", "0x00000002") and
     not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Full User-Mode Dumps Enabled System-Wide
+
+Full user-mode dumps are a diagnostic feature in Windows that captures detailed information about application crashes, aiding in troubleshooting. However, attackers can exploit this by enabling dumps system-wide to capture sensitive data, such as credentials, from processes like LSASS. The detection rule identifies unauthorized registry changes that enable this feature, excluding legitimate system processes, to flag potential credential dumping activities.
+
+### Possible investigation steps
+
+- Verify the registry path and data values by checking if the registry key `HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType` is set to "2" or "0x00000002", which indicates full user-mode dumps are enabled.
+- Identify the process that made the registry change by reviewing recent logs for any process activity related to registry modifications at the specified path.
+- Check for any recent application crashes or error reports that might have triggered the creation of a dump file, focusing on processes that handle sensitive data like LSASS.
+- Investigate the user account associated with the registry change by examining the `user.id` field to determine if it matches any known administrative or service accounts.
+- Review the process executable path to ensure it is not a legitimate system process like `?:\\Windows\\system32\\svchost.exe` running under system accounts (S-1-5-18, S-1-5-19, S-1-5-20).
+- Use Osquery to gather more information about the system's registry settings with a query like: `SELECT * FROM registry WHERE path = 'HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType';` to confirm the current state and any recent changes.
+- Analyze network activity logs for any unusual outbound connections that might indicate data exfiltration attempts following the registry change.
+- Cross-reference the alert with other security events or alerts in the same timeframe to identify any correlated suspicious activities or patterns.
+- Check for the presence of any unauthorized or suspicious software installations that might have been used to enable full user-mode dumps.
+- Review system and security logs for any signs of privilege escalation or lateral movement that could be related to the registry change and potential credential dumping activities.
+
+### False positive analysis
+
+- Legitimate software installations or updates may enable full user-mode dumps temporarily for debugging purposes, leading to false positives. Users can handle this by monitoring the installation or update process and temporarily excluding these activities from detection.
+- System administrators or IT support teams might enable full user-mode dumps for troubleshooting application crashes, which can be mistaken for malicious activity. To manage this, organizations can maintain a list of authorized personnel and processes that are allowed to make such changes and exclude them from the detection rule.
+- Some enterprise applications may require full user-mode dumps for regular operation or diagnostics, which could trigger the rule. Users should identify these applications and create exceptions for their specific registry changes to prevent false alerts.
+- Automated system management tools might modify registry settings as part of routine maintenance or configuration tasks. Users can address this by verifying the legitimacy of these tools and excluding their known benign activities from the detection criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Verify the registry changes by checking the specified registry path for unauthorized modifications and revert any changes to their default state.
+- Conduct a thorough investigation to identify any unauthorized access or suspicious activity, focusing on processes interacting with LSASS.
+- Review system logs and security events to trace the origin of the registry change and identify potential threat actors or compromised accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed information on registry changes and process executions, particularly those involving LSASS.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security configurations are set to best practices.
+- Conduct a security audit of the affected system and network to identify and remediate any other vulnerabilities or misconfigurations.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and using multi-factor authentication to reduce the risk of credential dumping attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_iis_connectionstrings_dumping.toml b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
index 127e86d766f..88a4b763d51 100644
--- a/rules/windows/credential_access_iis_connectionstrings_dumping.toml
+++ b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,52 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : "aspnet_regiis.exe" or ?process.pe.original_file_name == "aspnet_regiis.exe") and
   process.args : "connectionStrings" and process.args : "-pdf"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft IIS Connection Strings Decryption
+
+Microsoft IIS often stores sensitive data like database credentials in encrypted connection strings. The `aspnet_regiis` tool is used to manage these encryptions. Adversaries with access to the IIS server can exploit this tool to decrypt and extract credentials, potentially leading to unauthorized database access. The detection rule identifies suspicious use of `aspnet_regiis` by monitoring process execution with specific arguments, flagging potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `aspnet_regiis.exe` execution with the arguments `connectionStrings` and `-pdf`, as these are indicative of potential credential dumping activities.
+- Verify the legitimacy of the process by checking the user account under which `aspnet_regiis.exe` was executed. Determine if this account should have the necessary permissions to perform such actions.
+- Investigate the parent process of `aspnet_regiis.exe` to understand how it was initiated. This can help identify if it was triggered by a legitimate application or a malicious script.
+- Examine the process execution timeline to identify any other suspicious activities occurring around the same time, such as the creation or modification of webshells or unauthorized access attempts.
+- Use Osquery to gather additional context about the process execution. For example, run the following query to list recent executions of `aspnet_regiis.exe`:
+  ```sql
+  SELECT pid, path, cmdline, time FROM processes WHERE name = 'aspnet_regiis.exe' ORDER BY time DESC LIMIT 5;
+  ```
+- Check the IIS server logs for any unusual access patterns or errors that might correlate with the time of the `aspnet_regiis.exe` execution.
+- Investigate any network connections established by the IIS server around the time of the alert to identify potential data exfiltration attempts.
+- Review the system's security event logs for any signs of privilege escalation or unauthorized access that could have facilitated the execution of `aspnet_regiis.exe`.
+- Analyze any recent changes to the IIS configuration files or application code that might indicate tampering or the introduction of malicious scripts.
+- Correlate the findings with other security alerts or incidents in the environment to determine if this activity is part of a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use `aspnet_regiis` for legitimate purposes such as updating or managing connection strings during regular maintenance. These activities can trigger the detection rule but are not malicious.
+- Automated deployment scripts: Some deployment processes might include scripts that use `aspnet_regiis` to configure or update application settings, including connection strings, as part of a continuous integration/continuous deployment (CI/CD) pipeline.
+- Development and testing environments: Developers might frequently use `aspnet_regiis` in non-production environments to test configurations or troubleshoot issues, leading to benign alerts.
+- To manage false positives, users can create exceptions for known administrative accounts or specific scripts that are verified as non-threatening. This can be done by excluding certain user accounts or process hashes from triggering the alert.
+- Implementing a baseline of normal behavior for `aspnet_regiis` usage in the environment can help distinguish between legitimate and suspicious activities, allowing for more accurate alerting.
+
+### Response and remediation
+
+- Immediately isolate the affected IIS server from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any unauthorized access to the server and potential data breaches.
+- Review IIS server logs and Windows Event Logs for any suspicious activity, particularly around the time the `aspnet_regiis` command was executed.
+- Change all credentials that may have been exposed, including database credentials and any other sensitive information stored in connection strings.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems may be affected.
+- Implement enhanced logging and monitoring on the IIS server to detect future unauthorized use of `aspnet_regiis` or similar tools.
+- Apply security patches and updates to the IIS server and related software to mitigate known vulnerabilities.
+- Conduct a security review of the IIS server configuration and apply hardening measures, such as restricting access to the `aspnet_regiis` tool and ensuring least privilege access controls.
+- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities.
+- Restore the IIS server to its operational state by verifying the integrity of the system and ensuring all security measures are in place before reconnecting to the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
index b1bcc5351d1..77e420808f6 100644
--- a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
+++ b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,50 @@ not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid
           "?:\\Windows\\System32\\DriverStore\\FileRepository\\*")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Untrusted DLL Loaded by Azure AD Sync Service
+
+Azure AD Sync Service facilitates identity synchronization between on-premises directories and Azure AD. Adversaries may exploit this by loading untrusted DLLs to capture credentials. The detection rule identifies such activities by monitoring DLL loads lacking valid signatures, excluding known safe paths, thus highlighting potential unauthorized persistence or credential access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "AzureADConnectAuthenticationAgentService.exe" and verify the event category and action to ensure it matches either "library" with "load" or "process" with "Image loaded*".
+- Check the DLL path and file path against the exclusion list to confirm it is not a known safe path, such as those under "?:\\Windows\\assembly\\NativeImages*", "?:\\Windows\\Microsoft.NET\\*", "?:\\Windows\\WinSxS\\*", or "?:\\Windows\\System32\\DriverStore\\FileRepository\\*".
+- Investigate the DLL's code signature status to determine if it is indeed untrusted or invalid, and gather details about the publisher if available.
+- Use Osquery to list all loaded DLLs by the Azure AD Sync Service process to identify any other potentially suspicious or untrusted DLLs. Example query: `SELECT path, pid, name FROM processes JOIN process_open_sockets USING (pid) WHERE name = 'AzureADConnectAuthenticationAgentService.exe';`
+- Cross-reference the untrusted DLL's hash with threat intelligence databases to check for known malicious activity or associations.
+- Analyze the creation and modification timestamps of the untrusted DLL to determine when it was introduced to the system and correlate with other system events or changes.
+- Review recent system and security logs for any unusual activities or errors around the time the untrusted DLL was loaded, focusing on user logins, privilege escalations, or other process executions.
+- Investigate the parent process of the Azure AD Sync Service to determine if it was started by an unexpected or unauthorized user or process.
+- Check for any network connections initiated by the Azure AD Sync Service process that could indicate data exfiltration or communication with a command and control server.
+- Gather context on the system's role and any recent changes or deployments that could explain the presence of the untrusted DLL, such as software updates or configuration changes.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate software updates or installations that temporarily load unsigned DLLs, especially during system or application updates.
+- Some third-party applications may use custom DLLs that are not signed but are necessary for their operation, leading to false alerts.
+- In environments with custom-developed software, unsigned DLLs might be loaded as part of normal operations, which could trigger this rule.
+- To manage these false positives, users can create exceptions for specific DLL paths or hashes that are known to be safe and frequently used in their environment.
+- Regularly review and update the list of excluded paths or hashes to ensure that only legitimate and necessary exceptions are maintained.
+- Collaborate with IT and security teams to verify the legitimacy of unsigned DLLs and adjust the detection rule accordingly to minimize false positives while maintaining security.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the untrusted DLL and determine if any credentials have been compromised.
+- Review recent changes to the Azure AD Sync Service configuration and check for unauthorized modifications.
+- Remove the untrusted DLL and any associated malicious files from the system.
+- Reset credentials for any accounts that may have been exposed or compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for the Azure AD Sync Service to detect similar activities in the future, including enabling detailed process and DLL load logging.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate and analyze suspicious activities.
+- Restore the system to its operational state by verifying the integrity of the Azure AD Sync Service and ensuring all security patches and updates are applied.
+- Harden the system by applying security best practices, such as enforcing strict access controls, using application whitelisting, and regularly reviewing and updating security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_kirbi_file.toml b/rules/windows/credential_access_kirbi_file.toml
index 15cc4ea836a..a4f33532ba5 100644
--- a/rules/windows/credential_access_kirbi_file.toml
+++ b/rules/windows/credential_access_kirbi_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,49 @@ type = "eql"
 query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Kirbi File Creation
+
+Kirbi files are associated with Kerberos, a network authentication protocol used to verify user identities. Attackers exploit this by using tools like Mimikatz to extract Kerberos tickets, enabling unauthorized access through techniques like Pass-The-Ticket. The detection rule identifies the creation of these files on Windows systems, signaling potential credential dumping activities.
+
+### Possible investigation steps
+
+- Verify the alert by checking the file creation event details, focusing on the `host.os.type`, `event.type`, and `file.extension` fields to confirm the presence of a `.kirbi` file on a Windows system.
+- Identify the user account associated with the file creation event to determine if it aligns with expected behavior or if it might be compromised.
+- Review recent login activities for the identified user account to detect any unusual or unauthorized access patterns.
+- Examine the process that created the `.kirbi` file by correlating with process creation logs to identify the parent process and command line arguments used.
+- Use Osquery to gather more context about the system by running a query such as: `SELECT * FROM processes WHERE name = 'mimikatz.exe';` to check for the presence of known Kerberos ticket dumping tools.
+- Investigate the timeline of events leading up to the file creation by reviewing other security logs and alerts from the same host for any signs of suspicious activity.
+- Check for any network connections initiated by the host around the time of the file creation to identify potential lateral movement or data exfiltration attempts.
+- Analyze the file path and directory where the `.kirbi` file was created to determine if it is a common location for legitimate Kerberos tickets or if it appears suspicious.
+- Review any recent changes to user privileges or group memberships on the host to identify potential privilege escalation activities.
+- Correlate the alert with other security incidents or alerts in the environment to assess if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that manage Kerberos tickets might create .kirbi files as part of their normal operations. These tools are often used by IT departments for troubleshooting or managing authentication processes.
+- Scheduled tasks or automated processes that involve Kerberos ticket management could also result in the creation of .kirbi files. These tasks might be part of regular system maintenance or security monitoring activities.
+- Security software or endpoint detection and response (EDR) solutions that simulate attacks for testing purposes might generate .kirbi files to evaluate system defenses.
+- To manage these false positives, users can create exceptions for specific processes or directories known to generate .kirbi files as part of legitimate activities. This can be done by updating the detection rule to exclude certain file paths or process names associated with trusted applications.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation to identify the source of the .kirbi file creation, including reviewing recent user activity and system logs.
+- Use forensic tools to analyze the system for additional signs of compromise, such as unauthorized user accounts or suspicious processes.
+- Reset passwords for all potentially compromised accounts, focusing on those with elevated privileges.
+- Remove any unauthorized Kerberos tickets and terminate any suspicious sessions or processes identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed authentication events and file creation activities, ensuring future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze security events in real-time.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security configurations are in place.
+- Harden the environment by implementing least privilege access controls, enabling multi-factor authentication, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_ldap_attributes.toml b/rules/windows/credential_access_ldap_attributes.toml
index 0715a53733a..741340c2c4e 100644
--- a/rules/windows/credential_access_ldap_attributes.toml
+++ b/rules/windows/credential_access_ldap_attributes.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,52 @@ any where event.action in ("Directory Service Access", "object-operation-perform
    */
   not winlog.event_data.AccessMask in ("0x0", "0x100")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Access to a Sensitive LDAP Attribute
+
+LDAP (Lightweight Directory Access Protocol) is crucial for managing and accessing directory services in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, potentially leading to credential theft. The detection rule identifies suspicious access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce false positives.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event code is "4662" and the event action is either "Directory Service Access" or "object-operation-performed" to ensure it matches the detection criteria.
+- Verify the SubjectUserSid to ensure it is not "S-1-5-18", which is the SID for the Local System account, to rule out false positives from system processes.
+- Examine the winlog.event_data.Properties field to identify which specific sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, ms-PKI-DPAPIMasterKeys, or msPKI-CredentialRoamingTokens.
+- Check the winlog.event_data.AccessMask to ensure it is not "0x0" or "0x100", which are considered noisy and less indicative of malicious activity.
+- Investigate the user account associated with the access attempt to determine if it has a legitimate reason to access the sensitive attribute.
+- Use Osquery to gather additional context about the system from which the access attempt originated. For example, run the following query to list recent processes executed by the user:
+  ```sql
+  SELECT * FROM processes WHERE user = '<username>';
+  ```
+- Analyze the network traffic logs to identify any unusual connections or data transfers associated with the system or user involved in the alert.
+- Review recent changes in the Active Directory environment to identify any modifications that could have facilitated unauthorized access to sensitive attributes.
+- Correlate the alert with other security events or logs to identify patterns or additional indicators of compromise that may suggest a broader attack.
+- Consult with relevant stakeholders or system owners to verify if the access attempt was part of a legitimate administrative task or if further investigation is warranted.
+
+### False positive analysis
+
+- Access by legitimate administrative accounts: Routine operations by system administrators may trigger the rule due to their need to access sensitive attributes. Users can handle this by creating exceptions for known administrative accounts or service accounts that regularly perform these actions.
+- Scheduled tasks or automated scripts: Automated processes that require access to sensitive attributes for maintenance or updates might be flagged. To manage this, users should identify and exclude these tasks or scripts from the detection rule.
+- Backup and recovery operations: Backup solutions that interact with directory services to secure sensitive data may cause false positives. Users should whitelist these operations by excluding the associated service accounts or processes.
+- Security audits and compliance checks: Regular security assessments that involve accessing sensitive attributes can be mistaken for malicious activity. Users can mitigate this by excluding the accounts or tools used for these audits from the detection rule.
+- Third-party applications: Some third-party applications may require access to sensitive LDAP attributes for functionality. Users should verify the legitimacy of these applications and exclude them if they are deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the breach, focusing on logs related to event code 4662 and the specific LDAP attributes accessed.
+- Change passwords and revoke any potentially compromised credentials associated with the affected accounts, especially those with elevated privileges.
+- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for LDAP access, focusing on sensitive attributes and unusual access patterns, to improve detection of future attempts.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and identify potential indicators of compromise.
+- Restore the affected system to its operational state by applying necessary patches, updates, and security configurations to prevent similar incidents.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train staff on security best practices and the importance of safeguarding sensitive information to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
index d2b3ebffb78..77c394ba9d7 100644
--- a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
+++ b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/29"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,49 @@ process where host.os.type == "windows" and event.code == "10" and
    /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION */
   winlog.event_data.GrantedAccess == "0x14c0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious LSASS Access via MalSecLogon
+
+The Secondary Logon service, or seclogon, allows users to run processes with different credentials, often used for administrative tasks. Adversaries exploit this by accessing the LSASS process to extract credentials. The detection rule identifies such abuse by monitoring for specific access rights and call traces linked to seclogon.dll, indicating potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the specific event code "10" and verify that the target image is "?:\\\\WINDOWS\\\\system32\\\\lsass.exe".
+- Check the call trace for the presence of "seclogon.dll" to confirm the involvement of the Secondary Logon service in accessing LSASS.
+- Verify the process name is "svchost.exe" to ensure the alert is triggered by the expected service host process.
+- Examine the granted access value "0x14c0" to confirm it includes PROCESS_CREATE_PROCESS, PROCESS_DUP_HANDLE, and PROCESS_QUERY_INFORMATION, which are indicative of potential credential dumping attempts.
+- Use Osquery to list all processes with open handles to LSASS to identify any other suspicious processes: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = 'lsass.exe');`
+- Investigate the parent process of the suspicious svchost.exe instance to determine if it was spawned by a legitimate process or if it shows signs of compromise.
+- Review recent login events and user activity to identify any unusual or unauthorized access patterns that might correlate with the alert.
+- Check for any recent changes or anomalies in the system's security settings or configurations that could have facilitated the suspicious access.
+- Analyze network traffic from the host for any signs of data exfiltration or communication with known malicious IP addresses.
+- Correlate the alert with other security events or logs from the same timeframe to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that utilize the Secondary Logon service for credential management tasks may trigger this rule. These tools often access LSASS for valid reasons, such as password management or system maintenance.
+- Scheduled tasks or automated processes that require elevated privileges and use seclogon.dll might also be flagged. These processes typically have predictable patterns and can be identified through regular monitoring.
+- Security software or endpoint management solutions that perform regular system checks or updates might access LSASS as part of their operations. These should be verified with the vendor to ensure they are benign.
+- To manage these false positives, users can create exceptions for known legitimate processes by whitelisting specific process names or paths that are verified to be safe.
+- Regularly review and update the list of exceptions to ensure that only trusted processes are excluded, and conduct periodic audits to confirm that no malicious activity is being overlooked.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential access and lateral movement.
+- Conduct a thorough investigation to confirm the presence of malicious activity by analyzing the event logs and correlating with other security alerts.
+- Terminate any suspicious processes associated with the Secondary Logon service and LSASS access to stop ongoing credential dumping attempts.
+- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process creation and access events, focusing on LSASS and seclogon.dll interactions.
+- Integrate endpoint detection and response (EDR) solutions to monitor for similar suspicious activities and improve threat visibility.
+- Restore the system to a known good state by reimaging the affected machine and applying the latest security patches and updates.
+- Conduct a post-incident review to identify gaps in security controls and update the incident response plan accordingly.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and using multi-factor authentication to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_lsass_loaded_susp_dll.toml b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
index 8516179dd5a..5df55154992 100644
--- a/rules/windows/credential_access_lsass_loaded_susp_dll.toml
+++ b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/12/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -102,6 +102,50 @@ any where event.category in ("library", "driver") and host.os.type == "windows"
                  "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb",
                  "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Module Loaded by LSASS
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and handling user authentication in Windows environments. Adversaries exploit LSASS by loading malicious or untrusted DLLs to access sensitive credentials. The detection rule identifies such threats by monitoring LSASS for non-standard DLLs, focusing on unsigned or untrusted modules, and excluding known safe signatures and hashes.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific DLL file that was loaded by LSASS, focusing on the `dll.code_signature.subject_name` and `dll.hash.sha256` fields to determine if the DLL is unsigned or untrusted.
+- Cross-reference the `dll.hash.sha256` with known threat intelligence databases to check if the hash is associated with any known malicious activity.
+- Use Osquery to list all DLLs currently loaded by the LSASS process to identify any other potentially suspicious modules. Example query: `SELECT path, pid, name FROM processes JOIN process_open_sockets USING (pid) WHERE name = 'lsass.exe';`
+- Investigate the file path and properties of the suspicious DLL using the `dll.path` field to determine its origin and any associated metadata.
+- Check the `dll.code_signature.status` to understand the nature of the signature issue, such as whether it is expired or has a chaining error, which might provide context on the DLL's legitimacy.
+- Analyze recent system logs and events around the time the DLL was loaded to identify any unusual activities or changes in the system that could be related to the suspicious module.
+- Examine the system's startup programs and services to determine if the suspicious DLL is set to load at startup, which could indicate persistence mechanisms.
+- Investigate the parent process of LSASS using the `process.parent.executable` field to identify if there are any anomalies or unexpected parent processes that could suggest process injection or manipulation.
+- Review user account activities and authentication logs to identify any unauthorized access attempts or anomalies that could be linked to credential dumping activities.
+- Conduct a historical search for similar alerts or activities on the same host or across the network to determine if this is an isolated incident or part of a broader pattern.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate software that loads DLLs into LSASS but is not included in the predefined list of trusted signatures or hashes. This can include custom or in-house applications that have not been signed by a recognized certificate authority.
+- Security software updates or new installations might introduce new DLLs that are not immediately recognized as trusted, leading to false positives.
+- Users can manage these false positives by updating the list of trusted code signatures and hashes to include those from verified and legitimate sources.
+- Implementing a process to regularly review and update the exception list based on the organization's software inventory can help minimize false positives.
+- Monitoring for patterns of behavior rather than isolated events can help distinguish between benign and malicious activity, reducing the likelihood of false positives.
+- Engaging with software vendors to verify the legitimacy of their DLLs and obtaining their code signatures can aid in maintaining an accurate exception list.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on the suspicious DLL loaded by LSASS.
+- Utilize forensic tools to capture memory and disk images for detailed analysis and evidence preservation.
+- Remove the malicious or untrusted DLL from the system and replace it with a legitimate version if necessary.
+- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring policies to capture detailed information on DLL loads and process activities in LSASS.
+- Integrate threat intelligence feeds to improve detection capabilities and correlate with known threat actor behaviors.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring all software is up to date."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_posh_relay_tools.toml b/rules/windows/credential_access_posh_relay_tools.toml
index c376b490b2d..40540ed760d 100644
--- a/rules/windows/credential_access_posh_relay_tools.toml
+++ b/rules/windows/credential_access_posh_relay_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,6 +68,48 @@ event.category:process and host.os.type:windows and
   ) and
   not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential PowerShell Pass-the-Hash/Relay Script
+
+PowerShell, a powerful scripting language in Windows, can be exploited by attackers to perform pass-the-hash (PtH) and relay attacks, leveraging NTLM authentication protocols. These attacks allow adversaries to authenticate as users without knowing their passwords. The detection rule identifies suspicious PowerShell scripts by scanning for specific NTLM negotiation patterns and byte sequences, excluding legitimate system directories, to flag potential credential theft activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific PowerShell script block text that triggered the detection, focusing on the presence of NTLM negotiation patterns and byte sequences.
+- Verify the process details by examining the `event.category:process` field to identify the parent and child processes associated with the suspicious PowerShell activity.
+- Check the `host.os.type:windows` field to confirm the operating system environment and gather additional context about the host involved in the alert.
+- Investigate the script's origin by analyzing the file path and directory, ensuring it does not match the excluded directory "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads".
+- Use Osquery to gather more information about the process and its parent by executing a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND path NOT LIKE 'C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\\\\%'`.
+- Examine the PowerShell script block text for any hardcoded credentials or suspicious commands that could indicate credential theft or lateral movement attempts.
+- Cross-reference the alert with recent authentication logs to identify any unusual or unauthorized access attempts that may correlate with the detected PowerShell activity.
+- Analyze network traffic logs for any signs of NTLM relay attacks or anomalous SMB traffic patterns that align with the time of the alert.
+- Review historical alerts and logs for the same host to determine if there is a pattern of similar suspicious activities, indicating a persistent threat.
+- Consult threat intelligence sources to check if the detected patterns or byte sequences are associated with known malware or attack campaigns.
+
+### False positive analysis
+
+- Legitimate administrative scripts: PowerShell scripts used by IT administrators for legitimate purposes may contain NTLM negotiation patterns similar to those flagged by the rule. Users can handle these by creating exceptions for scripts verified as safe and necessary for operations.
+- Security software operations: Some security tools may use PowerShell scripts that mimic NTLM negotiation patterns for scanning or monitoring purposes. Users should identify these tools and exclude their scripts from detection to prevent false positives.
+- Automated system processes: Certain automated processes or system maintenance tasks might trigger the rule due to their use of NTLM protocols. Users can manage these by reviewing the processes and excluding known benign scripts from detection.
+- Development and testing environments: Developers or testers might run scripts that simulate NTLM authentication for testing purposes. Users should ensure these environments are properly documented and excluded from the detection rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation of the PowerShell script execution logs to identify the source and scope of the attack.
+- Analyze the script block text and associated processes to determine if any credentials were compromised.
+- Reset passwords for any accounts that may have been affected, focusing on those with elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and module logging.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore the system from a known good backup to ensure no malicious code remains.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Harden the system by disabling NTLM where possible and enforcing the use of stronger authentication protocols like Kerberos."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_posh_veeam_sql.toml b/rules/windows/credential_access_posh_veeam_sql.toml
index 65831163c1c..655052fc20b 100644
--- a/rules/windows/credential_access_posh_veeam_sql.toml
+++ b/rules/windows/credential_access_posh_veeam_sql.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,48 @@ event.category:process and host.os.type:windows and
     "ProtectedStorage]::GetLocalString"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Veeam Credential Access Capabilities
+
+PowerShell scripts can interact with Veeam's stored credentials in MSSQL databases, a feature intended for legitimate backup management. However, attackers exploit this to decrypt credentials, potentially targeting backups in ransomware attacks. The detection rule identifies suspicious script activity by monitoring for specific database interactions and decryption attempts, flagging potential credential access abuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the specific PowerShell script block text that triggered the alert, focusing on the presence of "[dbo].[Credentials]" and "ProtectedStorage]::GetLocalString".
+- Examine the process execution details, such as the process ID, parent process, and user account under which the PowerShell script was executed, to identify any anomalies or unauthorized access.
+- Check the event logs for any preceding or subsequent suspicious activities around the time of the alert, such as unusual login attempts or privilege escalations.
+- Investigate the host from which the alert originated to determine if there are any other signs of compromise, such as unexpected network connections or changes in system configurations.
+- Use Osquery to gather more information about the PowerShell script execution. For example, run the following query to list recent PowerShell script executions: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%[dbo].[Credentials]%' OR cmdline LIKE '%ProtectedStorage]::GetLocalString%';`
+- Analyze the PowerShell script content if available, to understand its purpose and whether it includes any malicious or unauthorized actions.
+- Correlate the alert with other security tools and logs, such as antivirus, endpoint detection and response (EDR), or network monitoring solutions, to gather additional context and evidence.
+- Investigate the MSSQL database logs to identify any unauthorized access attempts or suspicious queries related to Veeam credentials.
+- Check for any recent changes or updates to the Veeam backup configurations that could indicate tampering or unauthorized access.
+- Consult with the database and backup administrators to verify if the access to Veeam credentials was legitimate or if it aligns with any recent administrative activities.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may run PowerShell scripts that interact with Veeam credentials for routine backup management or maintenance tasks. These activities can trigger the detection rule but are non-threatening. Users can manage these by creating exceptions for known administrative scripts or specific user accounts that regularly perform these tasks.
+- Scheduled backup operations: Automated scripts scheduled to run at specific intervals for backup verification or testing purposes might be flagged. To handle these, users can whitelist specific script names or hash values that are verified as part of regular operations.
+- Security audits: Security teams may conduct audits that involve accessing Veeam credentials to ensure compliance and security posture. These activities can be excluded by identifying and allowing specific audit tools or scripts used by the security team.
+- Development and testing environments: In environments where developers or testers are experimenting with backup solutions, similar script activities might occur. Users can exclude these environments from monitoring or set up specific rules that differentiate between production and non-production activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on PowerShell script execution and MSSQL database interactions.
+- Review and analyze logs from the affected system and any associated network devices to trace the attacker's activities and identify any additional compromised systems.
+- Change all Veeam-related credentials and any other potentially exposed credentials to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging and monitoring for PowerShell activities and MSSQL database access to detect similar threats in the future.
+- Restore the affected system from a known good backup, ensuring that the backup is free from any malicious modifications.
+- Apply security patches and updates to the operating system, Veeam software, and any other relevant applications to mitigate known vulnerabilities.
+- Conduct a security review of the Veeam backup environment, ensuring that access controls and encryption settings are properly configured to prevent unauthorized access.
+- Educate and train staff on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
index 3b9496723a6..219b2656f13 100644
--- a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
+++ b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,49 @@ process where host.os.type == "windows" and event.code == "10" and
  /* call is coming from an unknown executable region */
  winlog.event_data.CallTrace : "*UNKNOWN*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Credential Access via DuplicateHandle in LSASS
+
+The Local Security Authority Subsystem Service (LSASS) manages security policies and user authentication in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing standard APIs to evade detection and extract credentials. The detection rule identifies anomalies by monitoring LSASS handle access requests with unusual call traces, flagging potential unauthorized memory dumps.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event code "10" and ensure the process name is "lsass.exe" with the GrantedAccess value of "0x40".
+- Examine the call trace information in the alert to identify the presence of "*UNKNOWN*" modules, which may indicate suspicious activity.
+- Cross-reference the timestamp of the alert with other security logs to identify any correlated events or anomalies around the same time.
+- Use Osquery to list all processes with open handles to LSASS by running: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = '127.0.0.1' AND remote_port = 135);`
+- Investigate the parent process of the suspicious LSASS handle access to determine if it is a known and legitimate process or potentially malicious.
+- Check for any recent changes or anomalies in the system's process creation logs that might indicate the introduction of unauthorized software or scripts.
+- Analyze network traffic logs for any unusual outbound connections that coincide with the time of the alert, which might suggest data exfiltration attempts.
+- Review user account activity logs to identify any unauthorized or unusual login attempts or privilege escalations around the time of the alert.
+- Investigate the system for any signs of persistence mechanisms that could indicate a broader compromise, such as scheduled tasks or startup items.
+- Consult threat intelligence sources to determine if there are any known malware campaigns or threat actor tactics that align with the observed behavior.
+
+### False positive analysis
+
+- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. These tools might use similar techniques to access LSASS memory for legitimate reasons, such as antivirus programs or system management software.
+- System administrators or security teams should identify and document any authorized software that accesses LSASS memory. This can be done by reviewing the call traces and verifying the legitimacy of the processes involved.
+- To manage false positives, users can create exceptions for known and trusted software by excluding specific call traces or process names from the detection rule. This helps in reducing noise and focusing on genuine threats.
+- Regularly update the list of exceptions to accommodate new software updates or changes in the environment, ensuring that only verified processes are excluded from monitoring.
+- Collaborate with software vendors to understand the behavior of their applications concerning LSASS access, which can aid in distinguishing between benign and malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the alert by reviewing logs and correlating with other security events to determine the scope and impact.
+- Capture a memory dump of the affected system for forensic analysis to identify any malicious processes or tools used by the adversary.
+- Terminate any suspicious processes identified during the investigation that are attempting to access LSASS memory.
+- Change all potentially compromised credentials, focusing on high-privilege accounts, and enforce a password reset policy.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process creation and handle access events, ensuring visibility into similar activities in the future.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security configurations are hardened.
+- Conduct a post-incident review to identify gaps in the security posture and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
index 90adf75f13c..481a89364b8 100644
--- a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
+++ b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/30"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,52 @@ process where host.os.type == "windows" and event.type == "start" and
   /* Access to named pipe via http */
   process.args : ("http*/print/pipe/*", "http*/pipe/spoolss", "http*/pipe/srvsvc")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Local NTLM Relay via HTTP
+
+NTLM, a suite of Microsoft security protocols, is often targeted by adversaries for credential theft. Attackers may exploit the Windows Printer Spooler service to coerce NTLM authentication over HTTP, potentially elevating privileges. The detection rule identifies suspicious rundll32.exe executions invoking WebDAV client DLLs with specific arguments, indicating attempts to access named pipes via HTTP, a hallmark of NTLM relay attacks.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious `rundll32.exe` executions with arguments pointing to `davclnt.dll` and HTTP access patterns, as specified in the detection rule.
+- Verify the process start event to ensure it matches the criteria: `process.name` as "rundll32.exe" and `process.args` containing paths to `davclnt.dll` and HTTP named pipe access.
+- Check the parent process of `rundll32.exe` to determine if it was spawned by a legitimate process or if it indicates malicious activity.
+- Investigate the user account associated with the process execution to determine if it is a privileged account or if there are signs of compromise.
+- Use Osquery to list all processes related to `rundll32.exe` and their network connections to identify any unusual or unauthorized network activity:
+  ```sql
+  SELECT pid, name, path, cmdline, parent, uid, gid FROM processes WHERE name = 'rundll32.exe';
+  ```
+- Examine the system's event logs for any related authentication events or anomalies around the time of the alert to gather additional context.
+- Analyze network traffic logs to identify any external connections made by the system that could indicate data exfiltration or communication with a command and control server.
+- Cross-reference the alert with any recent changes or updates to the system that might explain the behavior, such as software installations or configuration changes.
+- Investigate other systems within the network for similar alerts or suspicious activity to determine if this is an isolated incident or part of a broader attack.
+- Consult threat intelligence sources to check for any known campaigns or threat actors that utilize similar techniques, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate software or system processes may invoke `rundll32.exe` with WebDAV client DLLs for valid operations, such as network file access or synchronization tasks, which can trigger the detection rule.
+- System administrators or automated scripts might use similar command patterns for maintenance or configuration purposes, leading to false positives.
+- To manage these false positives, users can create exceptions for known benign processes or scripts by whitelisting specific command-line arguments or process hashes that are verified as non-threatening.
+- Regularly review and update the exception list to ensure it reflects the current environment and does not inadvertently exclude new or modified malicious activities.
+- Consider implementing additional context checks, such as verifying the source and destination of the HTTP requests, to differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the NTLM relay attack by reviewing logs and identifying any unauthorized access or changes.
+- Terminate any suspicious rundll32.exe processes that match the detection criteria to stop ongoing malicious activities.
+- Reset credentials for any accounts that may have been compromised during the attack to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on rundll32.exe and NTLM authentication events.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of similar threats in the future.
+- Restore the system to its operational state by applying the latest security patches and updates, particularly for the Windows Printer Spooler service.
+- Conduct a security audit of the network to identify and remediate any other potential vulnerabilities that could be exploited in similar attacks.
+- Implement hardening measures such as disabling unnecessary services, enforcing strong authentication mechanisms, and applying the principle of least privilege to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_saved_creds_vault_winlog.toml b/rules/windows/credential_access_saved_creds_vault_winlog.toml
index 385a6037a93..ffc866598e4 100644
--- a/rules/windows/credential_access_saved_creds_vault_winlog.toml
+++ b/rules/windows/credential_access_saved_creds_vault_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,49 @@ sequence by winlog.computer_name, winlog.process.pid with maxspan=1s
   not winlog.event_data.SubjectLogonId : "0x3e7" and 
   not winlog.event_data.Resource : "http://localhost/"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Multiple Vault Web Credentials Read
+
+Windows Credential Manager stores credentials for web logins, apps, and networks, simplifying user access. However, adversaries can exploit this by extracting stored credentials, potentially facilitating lateral movement within a network. The detection rule identifies suspicious activity by monitoring consecutive credential access events from the same process, excluding benign actions like local or system account access, thus highlighting potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of two consecutive vault read events with event code "5382" from the same process ID (winlog.process.pid) within a 1-second span.
+- Verify the winlog.computer_name to identify the affected system and determine if it is a high-value target or contains sensitive information.
+- Check the winlog.event_data.SchemaFriendlyName field to ensure the events are related to "Windows Web Password Credential" and not another type of credential.
+- Examine the winlog.event_data.Resource field to identify the specific web resources accessed, ensuring they are not benign resources like "http://localhost/".
+- Investigate the winlog.event_data.SubjectLogonId to determine the user context under which the process is running, ensuring it is not the local system account "0x3e7".
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <suspicious_pid>;` to gather details like the process path, command line arguments, and parent process.
+- Cross-reference the suspicious process with recent login events to identify any unusual or unauthorized logins around the time of the alert.
+- Check for any recent changes or installations on the affected system that could explain the behavior, such as new software or updates.
+- Review network logs to identify any unusual outbound connections from the affected system that could indicate data exfiltration.
+- Correlate the findings with other security alerts or logs to determine if this activity is part of a larger attack pattern or campaign.
+
+### False positive analysis
+
+- Routine system processes or legitimate applications may trigger the rule if they frequently access web credentials for normal operations, such as automated scripts or background services that require web authentication.
+- Scheduled tasks or maintenance scripts that access web credentials for updates or data synchronization might be misidentified as suspicious activity.
+- Users can manage these false positives by creating exceptions for known benign processes or specific logon IDs that are verified to perform legitimate credential access.
+- Implementing a whitelist of trusted applications or processes that regularly access web credentials can help reduce noise and focus on truly suspicious activities.
+- Monitoring the frequency and context of credential access events can aid in distinguishing between legitimate and potentially malicious activities, allowing for more informed exception handling.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to identify the process and user account associated with the suspicious credential access events.
+- Review the system's event logs to identify any other unusual activities or patterns that may indicate further compromise.
+- Change all potentially compromised credentials, especially those stored in the Windows Credential Manager, and enforce a password reset policy for affected users.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed credential access events and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all software is up to date.
+- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
+- Educate users on secure credential management practices and the importance of reporting suspicious activities.
+- Implement hardening measures such as disabling unnecessary services, applying the principle of least privilege, and using multi-factor authentication to protect sensitive accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_saved_creds_vaultcmd.toml b/rules/windows/credential_access_saved_creds_vaultcmd.toml
index 2e9c04c2ec9..e77d5f2e782 100644
--- a/rules/windows/credential_access_saved_creds_vaultcmd.toml
+++ b/rules/windows/credential_access_saved_creds_vaultcmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,49 @@ process where host.os.type == "windows" and event.type == "start" and
   (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and
   process.args:"/list*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Searching for Saved Credentials via VaultCmd
+
+Windows Credential Manager is a tool for managing saved credentials, such as usernames and passwords, for various services. Adversaries may exploit this by using VaultCmd to list or extract these credentials, potentially facilitating unauthorized access or lateral movement within a network. The detection rule identifies such activities by monitoring for the execution of VaultCmd with specific arguments indicative of credential listing attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `vaultcmd.exe` in the `process.name` or `process.pe.original_file_name` fields, and verify the use of the `/list*` argument in `process.args`.
+- Check the `event.type` field to ensure the process start event is accurately captured, indicating the execution of VaultCmd.
+- Identify the user account associated with the process execution by examining the `user.name` or `process.user.name` fields to determine if it aligns with expected behavior or if it is suspicious.
+- Investigate the `host.name` or `host.hostname` fields to determine the machine where the activity occurred and assess if it is a high-value target or a critical system.
+- Examine the `process.parent.name` and `process.parent.pid` fields to understand the parent process that initiated VaultCmd, which may provide context on how the execution was triggered.
+- Utilize Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'vaultcmd.exe';` to retrieve detailed information about the process execution.
+- Check for any recent logins or unusual activity associated with the identified user account by reviewing authentication logs or security events.
+- Investigate any network connections established by the host during the time of the alert to identify potential lateral movement or data exfiltration attempts.
+- Review historical data for any previous instances of VaultCmd execution on the same host or by the same user to identify patterns or repeated attempts.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign or isolated event.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use VaultCmd for legitimate purposes, such as managing user credentials or performing audits. These activities can trigger the detection rule but are not malicious.
+- Automated scripts: Some organizations may have automated scripts that utilize VaultCmd to manage credentials as part of their regular maintenance or security protocols. These scripts can generate alerts that are false positives.
+- Credential management software: Third-party credential management tools might invoke VaultCmd as part of their operations, leading to benign alerts.
+- User training and awareness programs: Security teams might use VaultCmd in training exercises to demonstrate credential management, which could be mistakenly flagged as suspicious activity.
+- To manage these false positives, users can create exceptions for known administrative accounts or scripts that regularly use VaultCmd. This can be done by adding specific user accounts or process hashes to an allowlist, ensuring that only unexpected or unauthorized use of VaultCmd triggers alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been accessed using the compromised credentials.
+- Review the event logs and security logs on the affected system to gather evidence of the VaultCmd execution and any subsequent suspicious activities.
+- Change all potentially compromised credentials, including those stored in the Windows Credential Manager, and enforce a password reset policy for affected users.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments, to improve detection of similar activities in the future.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to provide real-time alerts and context for suspicious activities related to credential access.
+- Restore the affected system to its operational state by reimaging the system or applying a clean backup, ensuring that all malicious artifacts are removed.
+- Apply security hardening measures, such as disabling unnecessary services, applying the principle of least privilege, and ensuring all systems are up to date with security patches.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_generic.toml b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
index 3d128e0eda8..4962a93f389 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_generic.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/22"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/21"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -73,6 +73,54 @@ process where host.os.type == "windows" and event.code == "10" and
   ) and
   not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Lsass Process Access
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and user authentication in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on potential credential dumping activities. This helps in pinpointing malicious actions while minimizing false positives.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event code is "10" and the target image is "?:\\\\WINDOWS\\\\system32\\\\lsass.exe" to ensure the alert is relevant to LSASS access.
+- Check the process name and executable path against the exclusion list to verify if the process is indeed suspicious and not a known legitimate process.
+- Investigate the process that attempted access by gathering additional details such as process ID, parent process ID, and command line arguments to understand the context of the access attempt.
+- Examine the user account associated with the process to determine if it is a privileged account or if there are any anomalies in its usage patterns.
+- Utilize Osquery to gather more information about the suspicious process. For example, run the following query to list all processes with their parent process and command line:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE '%lsass.exe%';
+  ```
+- Analyze the call trace data to identify any known malicious DLLs or unusual patterns that could indicate tampering or injection attempts.
+- Cross-reference the timestamp of the alert with other security logs, such as authentication logs or network activity, to identify any correlated suspicious activities.
+- Investigate any recent changes or installations on the host that could have introduced the suspicious process, focusing on software updates or new applications.
+- Check for any other alerts or indicators of compromise on the same host or within the same network segment to assess if this is part of a broader attack.
+- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation for future reference and analysis.
+
+### False positive analysis
+
+- Known false positives for the Suspicious Lsass Process Access rule include legitimate software and system processes that access LSASS for valid reasons, such as security software, system management tools, and certain enterprise applications.
+- Security tools like Sysmon, Windows Defender, and other endpoint protection platforms may trigger false positives due to their legitimate access to LSASS for monitoring and protection purposes.
+- System management and monitoring tools, such as those used for software updates or system diagnostics, might also access LSASS, leading to false positives.
+- Enterprise applications, particularly those involved in authentication or system integration, may require access to LSASS, which can be mistaken for suspicious activity.
+- To manage these false positives, users can create exceptions by adding known legitimate processes and executables to the exclusion list within the detection rule.
+- Regularly review and update the exclusion list to include new legitimate processes as they are identified, ensuring that the detection rule remains effective without generating unnecessary alerts.
+- Consider the context of the environment and the specific use cases of the organization to tailor the exclusion list, minimizing the risk of overlooking genuine threats while reducing false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the alert by reviewing logs and correlating with other security events to determine the scope and impact.
+- Capture a memory dump of the affected system for forensic analysis to identify any malicious processes or tools used for credential dumping.
+- Reset passwords for any accounts that may have been compromised, especially those with elevated privileges, and enforce multi-factor authentication.
+- Remove any identified malicious software or tools from the system and ensure that the system is clean before reconnecting it to the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and access patterns, focusing on critical system processes like LSASS.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for future investigations.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
index b4b6624514c..b78a81b0811 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/07"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,49 @@ process where host.os.type == "windows" and event.code == "10" and
         "?:\\Windows\\System32\\WerFaultSecure.exe"
       )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Credential Access via LSASS Memory Dump
+
+LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and handling user logins. Adversaries exploit this by using tools that leverage the MiniDumpWriteDump API, often exported by libraries like DBGHelp.dll, to extract sensitive credentials from LSASS memory. The detection rule identifies suspicious access patterns to LSASS, excluding legitimate crash handlers, to flag potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious access to the LSASS handle, focusing on the `winlog.event_data.TargetImage` field to ensure it points to "?:\\\\WINDOWS\\\\system32\\\\lsass.exe".
+- Examine the `winlog.event_data.CallTrace` field to verify if the call trace includes references to "dbghelp" or "dbgcore", indicating potential use of the MiniDumpWriteDump API.
+- Check the process that triggered the alert by analyzing the `process.executable` field to ensure it is not a legitimate crash handler like WerFault.exe or WerFaultSecure.exe.
+- Investigate the parent process of the suspicious activity to determine if it is a known legitimate process or potentially malicious.
+- Use Osquery to list all processes with open handles to LSASS by running: `SELECT pid, name, path FROM processes WHERE path LIKE '%lsass.exe%';` to identify any unexpected processes.
+- Correlate the timestamp of the alert with other security events on the host to identify any concurrent suspicious activities or anomalies.
+- Review recent user logins and account activities on the affected host to detect any unauthorized access attempts.
+- Analyze network connections from the host around the time of the alert to identify any unusual outbound connections that could indicate data exfiltration.
+- Check for any recent changes or installations of software on the host that could have introduced the suspicious behavior.
+- Consult threat intelligence sources to determine if the identified behavior matches any known attack patterns or tools used by adversaries.
+
+### False positive analysis
+
+- Legitimate software debugging tools may trigger this rule if they access LSASS memory for troubleshooting purposes, as they might use the MiniDumpWriteDump API. Users should verify if the process is part of a known debugging or monitoring tool.
+- System crash handlers, other than those explicitly excluded, might access LSASS memory during a crash event. Users can add additional known crash handler executables to the exclusion list to prevent false positives.
+- Security software or endpoint protection solutions may access LSASS memory as part of their normal operations. Users should confirm with their security vendor and consider excluding these processes if they are verified as safe.
+- Custom in-house applications that perform memory dumps for diagnostic purposes could also be flagged. Users should ensure these applications are documented and add them to the exclusion list if necessary.
+- To manage false positives, users can create exceptions by adding specific process executables or paths to the exclusion list, ensuring these are thoroughly vetted to avoid overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential access and lateral movement by the adversary.
+- Conduct a thorough investigation to confirm the presence of unauthorized LSASS memory access, reviewing logs and call traces for DBGHelp.dll or DBGCore.dll usage.
+- Capture a memory dump of the affected system for forensic analysis to identify any malicious processes or tools used for credential dumping.
+- If unauthorized access is confirmed, reset passwords for all accounts that may have been compromised, prioritizing high-privilege accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process creation and DLL loading events, ensuring visibility into future suspicious activities.
+- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious access patterns to critical system processes like LSASS.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are hardened.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks of credential dumping and the importance of maintaining strong, unique passwords and enabling multi-factor authentication (MFA)."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
index 157283aefb3..9f3f73b6b37 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,49 @@ event.category:process and host.os.type:windows and event.code:10 and
                                  "c:\\Windows\\system32\\lsass.exe" or
                                  "c:\\Windows\\System32\\lsass.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential LSASS Memory Dump via PssCaptureSnapShot
+
+PssCaptureSnapShot is a Windows API used for creating snapshots of processes, which can be leveraged for legitimate debugging and diagnostics. However, adversaries may exploit this to capture LSASS process memory, aiming to extract credentials. The detection rule identifies suspicious behavior by monitoring for repeated access to LSASS by the same process, targeting different LSASS instances, which may suggest an evasion attempt to dump credentials stealthily.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event category is 'process' and the host operating system type is 'windows', ensuring the alert is relevant to the environment.
+- Verify the event code is '10', which indicates a process access event, to confirm the alert is triggered by the correct type of activity.
+- Check the 'winlog.event_data.TargetImage' field to ensure it matches the path of LSASS (e.g., "C:\\\\Windows\\\\system32\\\\lsass.exe"), confirming the target process is indeed LSASS.
+- Identify the process that accessed LSASS by examining the process name and process ID fields in the event data to determine the source of the suspicious activity.
+- Investigate the parent process of the suspicious process to understand the context of how it was launched and whether it is associated with legitimate software or known malicious activity.
+- Use Osquery to gather additional context about the suspicious process. For example, run the query: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;` to retrieve details such as the command line, user, and start time.
+- Check for any recent process creation events involving the suspicious process to identify if it was spawned by another potentially malicious process.
+- Review the system's security logs for any other unusual or related activities around the time of the alert, such as failed login attempts or other process access events.
+- Analyze network logs to determine if the suspicious process has made any outbound connections, which could indicate data exfiltration attempts.
+- Correlate the findings with threat intelligence sources to determine if the behavior matches any known attack patterns or if the process is associated with known malware.
+
+### False positive analysis
+
+- Legitimate software tools used for system diagnostics or debugging may trigger this rule if they access LSASS memory using PssCaptureSnapShot. These tools often perform similar actions for legitimate purposes, such as performance monitoring or troubleshooting.
+- Security software or endpoint protection solutions might also access LSASS memory as part of their routine checks, leading to false positives. These solutions are designed to ensure system integrity and may mimic suspicious behavior unintentionally.
+- To manage these false positives, users can create exceptions for known and trusted software by whitelisting their process names or paths. This can be done by updating the detection rule to exclude specific processes that are verified as non-threatening.
+- Regularly review and update the list of exceptions to ensure that only legitimate processes are excluded, maintaining a balance between security and operational efficiency.
+- Collaborate with IT and security teams to identify and document legitimate processes that require access to LSASS, ensuring that these are accounted for in the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential access and lateral movement by the adversary.
+- Conduct a thorough investigation to confirm the presence of unauthorized LSASS memory access by reviewing security logs and process activity.
+- Terminate any suspicious processes that have accessed LSASS memory and ensure they are not legitimate administrative tools.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access.
+- Restore the system to a known good state by reimaging the affected machine and applying the latest security patches and updates.
+- Implement enhanced logging policies to capture detailed process creation and access events, focusing on LSASS and other critical system processes.
+- Integrate endpoint detection and response (EDR) solutions to monitor for similar suspicious activities and provide real-time alerts.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks of credential dumping and the importance of maintaining strong, unique passwords."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_veeam_backup_dll_imageload.toml b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
index c22dbdbccee..fe51f99a7b8 100644
--- a/rules/windows/credential_access_veeam_backup_dll_imageload.toml
+++ b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,48 @@ library where host.os.type == "windows" and event.action == "load" and
     process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Veeam Backup Library Loaded by Unusual Process
+
+Veeam Backup software is crucial for data protection, managing backups, and ensuring data recovery. However, attackers may exploit its credential management by loading the Veeam.Backup.Common.dll library through PowerShell or untrusted processes to decrypt credentials, potentially leading to data breaches or ransomware attacks. The detection rule identifies such anomalies by monitoring for the library's loading by suspicious processes, focusing on untrusted or unsigned code signatures and PowerShell activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the Veeam.Backup.Common.dll library loaded by an unusual process, focusing on the process name and code signature status.
+- Verify the process code signature by checking if it is trusted or exists, and identify if the process is PowerShell-related (e.g., powershell.exe, pwsh.exe, powershell_ise.exe).
+- Gather additional context by examining the parent process of the suspicious activity to understand how the process was initiated.
+- Check the user account associated with the process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Investigate recent PowerShell command history on the host to identify any suspicious or unauthorized scripts that may have been executed.
+- Use Osquery to list all processes that have recently loaded the Veeam.Backup.Common.dll library with the following query: `SELECT pid, name, path FROM processes WHERE path LIKE '%Veeam.Backup.Common.dll%';`
+- Analyze network connections from the host to identify any unusual outbound connections that may suggest data exfiltration or communication with a command and control server.
+- Review recent system and security logs for any additional indicators of compromise or related suspicious activities around the time of the alert.
+- Check for any recent changes to Veeam Backup configurations or settings that could indicate tampering or unauthorized access.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools may load the Veeam.Backup.Common.dll library using PowerShell for routine backup management tasks, leading to false positives. Users can handle these by creating exceptions for known scripts or tools that are verified and regularly used by the IT department.
+- Some third-party backup management solutions might integrate with Veeam and load the library through unsigned processes. To manage these, users should verify the legitimacy of the third-party software and add it to an allowlist if deemed safe.
+- During software updates or maintenance, Veeam's own processes might temporarily appear unsigned or untrusted, triggering alerts. Users should monitor the timing of these alerts and correlate them with scheduled maintenance activities, excluding them if they match.
+- In environments where PowerShell is heavily used for legitimate administrative tasks, frequent alerts may occur. Users can reduce noise by implementing strict code-signing policies and only allowing signed scripts to execute, thereby minimizing the risk of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the anomaly, focusing on the processes that loaded the Veeam.Backup.Common.dll library.
+- Review PowerShell logs and any unsigned process activity to determine if there are any unauthorized or suspicious commands executed.
+- Verify the integrity of Veeam Backup credentials and change them if any compromise is suspected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
+- Integrate security tools with SIEM solutions to automate the detection of similar threats and improve response times.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting PowerShell execution policies, enforcing code signing, and regularly auditing privileged accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_veeam_commands.toml b/rules/windows/credential_access_veeam_commands.toml
index 9cfdf005e9b..6e074224e71 100644
--- a/rules/windows/credential_access_veeam_commands.toml
+++ b/rules/windows/credential_access_veeam_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,48 @@ process where host.os.type == "windows" and event.type == "start" and
   ) and
   process.args : "*[VeeamBackup].[dbo].[Credentials]*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Veeam Credential Access Command
+
+Veeam Backup & Replication software stores credentials in MSSQL databases to facilitate backup operations. Adversaries may exploit this by executing specific SQL commands to access and decrypt these credentials, potentially leading to unauthorized access and data destruction, such as in ransomware attacks. The detection rule identifies suspicious processes and arguments indicative of such credential access attempts, focusing on SQL command-line utilities and PowerShell cmdlets that interact with Veeam's credential storage.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious processes such as `sqlcmd.exe` or PowerShell cmdlets like `Invoke-Sqlcmd`, `Invoke-SqlExecute`, `Invoke-DbaQuery`, or `Invoke-SqlQuery` in the process arguments.
+- Verify the process execution context by checking the user account under which the suspicious process was executed to determine if it aligns with expected administrative or service accounts.
+- Examine the command line arguments of the flagged process to identify any references to the `[VeeamBackup].[dbo].[Credentials]` table, which may indicate an attempt to access stored credentials.
+- Check the process creation time and correlate it with any other suspicious activities or alerts around the same timeframe to identify potential lateral movement or privilege escalation attempts.
+- Investigate the parent process of the suspicious command to determine if it was spawned by a legitimate application or a potentially malicious script or executable.
+- Utilize Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name = 'sqlcmd.exe' OR name LIKE 'powershell%' AND cmdline LIKE '%[VeeamBackup].[dbo].[Credentials]%';` to identify other instances of similar activity.
+- Review recent login events and access logs for the database server to identify any unauthorized or unusual access patterns that may correlate with the alert.
+- Analyze network traffic logs to detect any data exfiltration attempts or connections to known malicious IP addresses following the execution of the suspicious process.
+- Check for any recent changes or anomalies in the Veeam Backup & Replication configuration or backup jobs that could indicate tampering or unauthorized access.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors targeting Veeam credentials, and assess if the observed activity matches any known indicators of compromise.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may use SQL command-line utilities or PowerShell cmdlets to manage Veeam Backup & Replication configurations, leading to benign alerts. To manage these, users can create exceptions for known administrator accounts or specific scripts that are regularly used for maintenance.
+- Automated backup scripts: Organizations might have automated scripts that interact with Veeam's credential storage for backup verification or testing purposes. These scripts can be whitelisted by identifying their unique process names or arguments to prevent false positives.
+- Monitoring and auditing tools: Security or compliance tools that perform regular checks on database credentials might trigger this rule. Users can exclude these tools by specifying their process names or paths in the detection rule exceptions.
+- Development and testing environments: In non-production environments, developers might frequently access Veeam credentials for testing purposes. Users can adjust the rule to exclude specific hostnames or IP addresses associated with these environments to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to confirm the presence of unauthorized SQL command execution targeting Veeam credentials, using logs and forensic tools.
+- Review and analyze recent access logs for unusual activity, focusing on SQL command-line utilities and PowerShell cmdlets interacting with Veeam's credential storage.
+- Change all potentially compromised credentials stored in the Veeam Backup & Replication system and any other systems where these credentials might have been reused.
+- Restore affected systems from the most recent clean backup to ensure no malicious changes persist.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate security solutions with SIEM systems to improve detection and correlation of suspicious activities related to credential access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Apply security patches and updates to Veeam Backup & Replication software and underlying systems to mitigate known vulnerabilities.
+- Conduct a security review and harden the environment by implementing least privilege access controls, network segmentation, and regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
index 84213f9d53c..be72d21bcc2 100644
--- a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
+++ b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/11/27"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,49 @@ process where host.os.type == "windows" and event.code:"4688" and
   process.executable : "?:\\Windows\\System32\\lsass.exe" and
   process.parent.executable : "?:\\Windows\\System32\\lsass.exe"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential LSASS Clone Creation via PssCaptureSnapShot
+
+PssCaptureSnapShot is a Windows API used for creating snapshots of processes, often for debugging or analysis. Adversaries exploit this to clone the LSASS process, aiming to extract credentials without triggering alarms. The detection rule identifies suspicious LSASS clones by monitoring process creation events where both the process and its parent are LSASS, signaling potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a process creation event with event code 4688, where both the process and its parent are `lsass.exe`.
+- Verify the timestamp of the event to determine when the suspicious LSASS clone was created and correlate it with other security events around the same time.
+- Check the user account context under which the LSASS clone process was created to identify any unusual or unauthorized access.
+- Investigate the command line arguments used during the process creation to identify any anomalies or suspicious parameters.
+- Use Osquery to list all running processes and their parent processes to confirm the presence of any LSASS clones. Example query: `SELECT pid, name, path, parent FROM processes WHERE name = 'lsass.exe';`
+- Examine the network connections and open ports on the host to identify any unusual outbound connections that might indicate data exfiltration.
+- Review recent login events and account activity on the host to identify any unauthorized access attempts or anomalies.
+- Analyze the host for any recent changes to system files or configurations that could indicate tampering or preparation for credential dumping.
+- Check for any other security alerts or logs related to the host or user account to identify potential patterns or repeated attempts.
+- Consult threat intelligence sources to determine if there are any known campaigns or tools that match the observed behavior, providing additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate software or security tools that perform memory analysis or debugging might trigger this rule by creating LSASS process snapshots for non-malicious purposes.
+- System administrators or security teams using authorized tools for system diagnostics or forensic investigations may inadvertently cause LSASS clones, leading to false positives.
+- Exclude known and trusted applications or tools that are verified to perform legitimate LSASS process interactions by adding them to an exception list in the monitoring system.
+- Regularly update the exception list to include new versions or updates of trusted software that interact with LSASS to prevent unnecessary alerts.
+- Collaborate with IT and security teams to identify and document routine maintenance or diagnostic activities that could mimic suspicious behavior, ensuring these are accounted for in the monitoring setup.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential access and lateral movement.
+- Conduct a thorough investigation to confirm the presence of unauthorized LSASS process clones using forensic tools and logs.
+- Terminate any suspicious LSASS clone processes identified during the investigation to halt potential credential dumping.
+- Review and analyze security logs, including Windows Event Logs and security information and event management (SIEM) data, to trace the source and scope of the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process creation events and monitor for similar suspicious activities in the future.
+- Integrate endpoint detection and response (EDR) solutions to provide real-time monitoring and automated response capabilities.
+- Restore the affected system from a known good backup to ensure no residual malicious activity remains.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for credential dumping.
+- Strengthen system hardening measures by enforcing least privilege access, enabling Credential Guard, and regularly reviewing user permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_wbadmin_ntds.toml b/rules/windows/credential_access_wbadmin_ntds.toml
index efc78263512..1bbaf193932 100644
--- a/rules/windows/credential_access_wbadmin_ntds.toml
+++ b/rules/windows/credential_access_wbadmin_ntds.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,48 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and 
      process.args : "recovery" and process.command_line : "*ntds.dit*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 NTDS Dump via Wbadmin
+
+Wbadmin is a Windows utility for managing backups, including system state data like the NTDS.dit file, which stores Active Directory data. Adversaries with sufficient privileges can exploit Wbadmin to extract this file, gaining access to sensitive credentials. The detection rule identifies suspicious Wbadmin usage by monitoring for specific command patterns indicative of NTDS.dit access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `wbadmin.exe` process execution with arguments related to "recovery" and "ntds.dit" in the command line.
+- Verify the user account associated with the process execution to determine if it belongs to privileged groups such as Backup Operators or Domain Admins.
+- Check the event logs for any preceding or subsequent suspicious activities around the time of the wbadmin execution, focusing on privilege escalation or lateral movement attempts.
+- Investigate the source host by examining its recent login history and any unusual access patterns to identify potential unauthorized access.
+- Use Osquery to gather additional context on the process execution. For example, run the following query to list recent wbadmin executions: `SELECT * FROM processes WHERE name = 'wbadmin.exe' AND cmdline LIKE '%ntds.dit%';`
+- Analyze network traffic logs to identify any data exfiltration attempts or connections to suspicious external IP addresses following the wbadmin execution.
+- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or coordinated attack activities.
+- Examine the file system for any unauthorized copies or movements of the NTDS.dit file, especially in non-standard directories or external storage devices.
+- Review any recent changes to user permissions or group memberships that could have facilitated the wbadmin execution.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar wbadmin abuse techniques.
+
+### False positive analysis
+
+- Scheduled or legitimate backup operations: Organizations may have routine backup processes that involve the use of Wbadmin to access system state data, including the NTDS.dit file. These operations are typically performed by IT personnel with appropriate privileges and should be verified against scheduled tasks or backup logs.
+- Testing and maintenance activities: IT departments may conduct tests or maintenance activities that involve accessing the NTDS.dit file using Wbadmin. These activities should be documented and cross-referenced with the detected events to confirm legitimacy.
+- Third-party backup solutions: Some third-party backup solutions may utilize Wbadmin as part of their backup processes. It's important to identify these solutions and create exceptions for their known behaviors to prevent false positives.
+- To manage false positives, users can create exceptions for known legitimate processes by whitelisting specific command lines or process arguments associated with authorized backup activities. Additionally, maintaining an updated list of authorized personnel and scheduled tasks can help in quickly identifying and excluding non-threatening behaviors.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Verify the legitimacy of the wbadmin command execution by checking the user account and context in which it was run. Investigate if the account has been compromised.
+- Review the membership of privileged groups such as Backup Operators and Domain Admins to ensure only authorized personnel have access.
+- Conduct a thorough forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms.
+- Reset passwords for all potentially compromised accounts, especially those with elevated privileges, and enforce multi-factor authentication.
+- Restore the NTDS.dit file and any other affected system components from a known good backup to ensure integrity.
+- Implement enhanced logging and monitoring for wbadmin usage and other sensitive operations, ensuring logs are sent to a centralized security information and event management (SIEM) system.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) for improved detection and response.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Review and update security policies and procedures to include regular audits of privileged accounts and the implementation of least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_cve_2020_0601.toml b/rules/windows/defense_evasion_cve_2020_0601.toml
index c5462af0a0c..f0cbb4db46d 100644
--- a/rules/windows/defense_evasion_cve_2020_0601.toml
+++ b/rules/windows/defense_evasion_cve_2020_0601.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/19"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,48 @@ type = "query"
 query = '''
 event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" and host.os.type:windows
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall)
+
+The Windows CryptoAPI is crucial for validating ECC certificates, ensuring secure communications and software authenticity. CVE-2020-0601, known as CurveBall, allows attackers to exploit this by crafting fake certificates, making malicious files appear legitimate. The detection rule identifies such exploits by monitoring specific event logs and messages related to this vulnerability, focusing on defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the event.provider field as "Microsoft-Windows-Audit-CVE" and ensure the message contains "[CVE-2020-0601]" to verify the alert's relevance to the CurveBall vulnerability.
+- Check the host.os.type field to confirm the affected system is running Windows, as this vulnerability specifically targets Windows CryptoAPI.
+- Examine the event logs for any recent entries related to certificate validation failures or anomalies, focusing on the time frame around the alert.
+- Investigate the source of the potentially spoofed certificate by identifying the issuer and subject fields in the certificate details, if available.
+- Use Osquery to gather more information about the affected system. For example, run the following query to list all certificates in the system's certificate store: `SELECT * FROM certificates WHERE common_name LIKE '%CVE-2020-0601%';`
+- Analyze network traffic logs to identify any unusual outbound connections that may have been initiated by the potentially malicious executable.
+- Cross-reference the hash of the suspicious executable with known malware databases to determine if it has been previously identified as malicious.
+- Review recent software installations or updates on the affected system to identify any unauthorized or unexpected changes that could be related to the spoofed certificate.
+- Check for any other alerts or indicators of compromise on the same host that might suggest a broader attack campaign or additional tactics being used.
+- Collaborate with other security teams to gather intelligence on any similar incidents or patterns observed in the network, which could provide additional context or indicators for the investigation.
+
+### False positive analysis
+
+- Legitimate software updates or installations might trigger the detection rule if they use ECC certificates that resemble the characteristics of those exploited in CVE-2020-0601. Users should verify the source of the software and, if confirmed safe, create an exception for these specific certificates.
+- Internal testing environments that utilize self-signed ECC certificates for development purposes may also be flagged. To manage this, users can whitelist these certificates or exclude specific test environments from monitoring.
+- Security tools or applications that perform certificate validation testing might generate alerts. Users should identify these tools and configure the detection rule to ignore their activities by adding them to an exception list.
+- Some enterprise environments may have custom applications that use non-standard ECC certificates, which could be mistaken for malicious activity. In such cases, users should document these applications and adjust the detection parameters to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further exploitation and lateral movement.
+- Validate the presence of the spoofed certificate by checking the event logs for entries matching the detection query.
+- Revoke any identified malicious certificates and update the certificate trust list to prevent future misuse.
+- Apply the latest security patches from Microsoft to address CVE-2020-0601 and ensure all systems are up to date.
+- Conduct a thorough investigation to identify any additional compromised systems or accounts using the MITRE ATT&CK framework, focusing on Defense Evasion and Subvert Trust Controls.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Implement enhanced logging policies to capture detailed cryptographic operations and certificate validation processes.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Restore affected systems from clean backups and verify the integrity of critical files and applications before reconnecting to the network.
+- Strengthen system hardening measures by enforcing strict certificate validation policies and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_disable_nla.toml b/rules/windows/defense_evasion_disable_nla.toml
index 817b3ffbd14..864918db51c 100644
--- a/rules/windows/defense_evasion_disable_nla.toml
+++ b/rules/windows/defense_evasion_disable_nla.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/25"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,48 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
     "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication"
   ) and registry.data.strings :  ("0", "0x00000000")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network-Level Authentication (NLA) Disabled
+
+Network-Level Authentication (NLA) enhances security for Remote Desktop Protocol (RDP) by requiring user authentication before establishing a session. Disabling NLA can allow attackers to exploit the Windows sign-in screen for persistence, bypassing authentication. The detection rule identifies registry changes that disable NLA, flagging potential unauthorized modifications indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path and value changes, specifically checking for modifications to `HKLM\\SYSTEM\\ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication` with values set to "0" or "0x00000000".
+- Verify the timestamp of the registry change to determine when the modification occurred and correlate it with other events in the system logs around the same time.
+- Identify the user account and process responsible for the registry modification by examining the event logs for the `event.action` field, ensuring it is not a deletion, and cross-referencing with the `host.os.type` to confirm it is a Windows system.
+- Check for any recent logins or RDP sessions around the time of the registry change to identify potential unauthorized access attempts.
+- Use Osquery to gather additional context on the system by running a query to list all recent registry changes: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\SYSTEM\\ControlSet%\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication';`
+- Investigate any other registry changes made by the same user or process to identify if there are additional unauthorized modifications.
+- Examine the system's security and application logs for any suspicious activities or errors that might indicate an attempt to exploit the disabled NLA.
+- Review network logs for unusual RDP connection attempts or traffic patterns that could suggest an attacker is attempting to exploit the disabled NLA.
+- Check for the presence of known persistence mechanisms, such as modified Accessibility Features, that could be leveraged by an attacker after disabling NLA.
+- Consult threat intelligence sources to determine if there are any known campaigns or malware that specifically target NLA settings for persistence or defense evasion.
+
+### False positive analysis
+
+- Legitimate administrative actions: System administrators may intentionally disable NLA for troubleshooting or compatibility reasons. To manage this, create exceptions for known administrative accounts or scheduled maintenance periods.
+- Software updates or installations: Certain software updates or installations might modify registry settings, including NLA, as part of their process. Users can handle these by monitoring update schedules and excluding known software processes from triggering alerts.
+- Group policy changes: Changes in group policies might inadvertently disable NLA across multiple systems. To address this, ensure that group policy changes are documented and approved, and exclude these changes from detection rules.
+- Virtual machine templates: Cloning or deploying virtual machines from templates where NLA is disabled can trigger false positives. Users should verify template configurations and exclude these specific registry changes during deployment processes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the registry change by checking the specified registry path to confirm if NLA has been disabled.
+- Conduct a thorough investigation to identify any unauthorized access or persistence mechanisms, such as checking for unusual user accounts or scheduled tasks.
+- Restore the registry setting to enable NLA by setting the "UserAuthentication" value to "1" or "0x00000001".
+- Review system and security logs to identify any suspicious activities or patterns that may indicate a broader compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed RDP connection attempts and registry changes for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Conduct a security audit of RDP configurations across the network to ensure compliance with security best practices, such as enforcing strong authentication and using VPNs for remote access.
+- Educate users and administrators on the importance of NLA and other security measures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_dns_over_https_enabled.toml b/rules/windows/defense_evasion_dns_over_https_enabled.toml
index 9bb21c0aa79..64eb424f1d1 100644
--- a/rules/windows/defense_evasion_dns_over_https_enabled.toml
+++ b/rules/windows/defense_evasion_dns_over_https_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,48 @@ registry where host.os.type == "windows" and event.type == "change" and
   (registry.path : "*\\SOFTWARE\\Policies\\Mozilla\\Firefox\\DNSOverHTTPS" and
   registry.data.strings : ("1", "0x00000001"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 DNS-over-HTTPS Enabled via Registry
+
+DNS-over-HTTPS (DoH) encrypts DNS queries to enhance privacy and security, preventing eavesdropping and manipulation. However, adversaries can exploit DoH to conceal malicious activities, such as data exfiltration, by bypassing traditional DNS monitoring. The detection rule identifies registry changes enabling DoH in browsers like Edge, Chrome, and Firefox, signaling potential misuse by monitoring specific registry paths and values.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path and value that triggered the alert, focusing on the `registry.path` and `registry.data.strings` fields.
+- Verify the legitimacy of the registry change by checking if the change aligns with any recent software updates or policy changes within the organization.
+- Use Osquery to list recent registry changes on the affected host to identify any other suspicious modifications. Example query: `SELECT * FROM registry WHERE path LIKE '%SOFTWARE\\\\Policies\\\\%' AND mtime > (SELECT datetime('now', '-1 day'));`
+- Investigate the user account associated with the registry change to determine if the account has a history of suspicious activity or if it has been compromised.
+- Check the system's event logs for any unusual activity around the time of the registry change, such as unexpected logins or process executions.
+- Analyze network traffic from the affected host to identify any unusual DNS queries or connections that could indicate data exfiltration or communication with malicious domains.
+- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
+- Review the browser settings and extensions on the affected host to ensure no unauthorized changes or installations have occurred.
+- Consult with the user of the affected host to determine if they made the change intentionally and if so, understand the context and purpose behind it.
+- Document all findings and observations to provide a comprehensive overview of the investigation, which can be used for further analysis or reporting.
+
+### False positive analysis
+
+- Enabling DNS-over-HTTPS for legitimate privacy reasons: Users or IT departments may enable DoH to enhance privacy and security without malicious intent. This can be a common practice in organizations prioritizing data protection.
+- Browser updates or policy changes: Automatic updates or changes in browser policies might enable DoH by default, triggering the detection rule without any malicious activity.
+- Security software configurations: Some security software might enable DoH as part of their protective measures, leading to false positives.
+- Handling false positives: To manage these, users can create exceptions for known legitimate changes by whitelisting specific registry paths or values associated with trusted applications or updates. Regularly review and update these exceptions to ensure they align with current organizational policies and software configurations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential data exfiltration or further malicious activity.
+- Conduct a thorough investigation to determine if the registry changes were authorized or if they indicate malicious intent, focusing on recent user activities and installed software.
+- Review system logs and network traffic for any signs of data exfiltration or communication with known malicious IP addresses, leveraging existing security tools and threat intelligence feeds.
+- If unauthorized changes are confirmed, revert the registry settings to their original state and ensure DNS-over-HTTPS is disabled unless explicitly required for business purposes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for registry changes and DNS queries to improve detection of similar activities in the future.
+- Integrate threat intelligence platforms and endpoint detection and response (EDR) solutions to provide better visibility and context for future investigations.
+- Educate users on the risks associated with unauthorized changes to system settings and the importance of reporting suspicious activities.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited by attackers.
+- Review and update security policies and procedures to include specific measures for handling DNS-over-HTTPS and registry modifications, ensuring alignment with MITRE ATT&CK framework techniques such as T1112."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
index f0b273d90e7..e929e9fa930 100644
--- a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
+++ b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,48 @@ process where host.os.type == "windows" and event.type == "start" and
   process.name : ("csc.exe", "vbc.exe") and
   process.parent.name : ("wscript.exe", "mshta.exe", "cscript.exe", "wmic.exe", "svchost.exe", "rundll32.exe", "cmstp.exe", "regsvr32.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious .NET Code Compilation
+
+.NET compilers like `csc.exe` and `vbc.exe` are essential for converting human-readable code into executable programs on Windows systems. Adversaries exploit these compilers by executing them with unusual parent processes, such as scripting engines or system utilities, to compile malicious code stealthily. The detection rule identifies such anomalies by monitoring compiler executions initiated by atypical parent processes, signaling potential evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a .NET compiler execution (`csc.exe` or `vbc.exe`) with a suspicious parent process (`wscript.exe`, `mshta.exe`, `cscript.exe`, `wmic.exe`, `svchost.exe`, `rundll32.exe`, `cmstp.exe`, `regsvr32.exe`).
+- Examine the process tree to understand the sequence of events leading to the compiler execution, focusing on the parent and grandparent processes.
+- Check the command line arguments used in the suspicious process execution to identify any potentially malicious scripts or commands.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Use Osquery to gather additional context about the process, such as the full command line and environment variables, with a query like: `SELECT * FROM processes WHERE name IN ('csc.exe', 'vbc.exe') AND parent IN (SELECT pid FROM processes WHERE name IN ('wscript.exe', 'mshta.exe', 'cscript.exe', 'wmic.exe', 'svchost.exe', 'rundll32.exe', 'cmstp.exe', 'regsvr32.exe'));`
+- Analyze recent file modifications in directories commonly used for temporary or suspicious file storage to identify any newly compiled executables or scripts.
+- Correlate the event with network activity logs to detect any unusual outbound connections that might indicate data exfiltration or command and control communication.
+- Review system logs for any other suspicious activities or anomalies around the time of the alert, such as privilege escalation attempts or unusual login patterns.
+- Check for any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or coordinated attacks.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise (IOCs).
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators may use scripts that invoke .NET compilers for legitimate tasks, such as automating software deployments or configurations. These scripts might be executed by scripting engines like `wscript.exe` or `cscript.exe`, leading to false positives.
+- Software development environments: Developers working on .NET applications might use integrated development environments (IDEs) or build scripts that call `csc.exe` or `vbc.exe` with parent processes that are not typical for production environments, such as `cmd.exe` or `powershell.exe`.
+- Automated build systems: Continuous integration/continuous deployment (CI/CD) systems might trigger .NET compiler executions as part of their build processes, which could be flagged if the parent process is a script or utility.
+- To manage these false positives, users can create exceptions for known benign processes or scripts by adding them to an allowlist. This can be done by identifying the specific parent processes or command lines associated with legitimate activities and excluding them from the detection rule. Regularly reviewing and updating these exceptions is crucial to ensure that only non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potentially malicious code.
+- Conduct a thorough investigation to identify the source and scope of the suspicious activity, focusing on the parent processes that initiated the .NET compiler execution.
+- Review and analyze logs from the affected system and any associated systems to trace the attacker's activities and identify any additional compromised systems.
+- Remove any malicious code or files identified during the investigation, ensuring that all remnants of the attack are eradicated from the system.
+- Restore the system from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from any compromise.
+- Update and patch all software and systems to the latest versions to mitigate vulnerabilities that could be exploited by similar attacks.
+- Implement enhanced logging policies to capture detailed process execution data, including parent-child process relationships, to aid in future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities for similar threats.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to address these gaps, such as deploying application whitelisting or restricting script execution.
+- Escalate the incident to relevant internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and assistance in preventing future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
index 24186a5e8cd..d1c7bdd6f01 100644
--- a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
+++ b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/08"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,49 @@ process where host.os.type == "windows" and event.type == "start" and
     "*\\AppData\\Local\\*"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Control Panel Process with Unusual Arguments
+
+The Windows Control Panel, typically used for system settings, can be exploited by adversaries to execute malicious code under the guise of legitimate processes. By manipulating command line arguments, attackers can proxy execution through control.exe, evading detection. The detection rule identifies anomalies by flagging unusual file types and suspicious paths in the command line, indicating potential misuse for malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific command line arguments that triggered the detection, focusing on unusual file types and suspicious paths.
+- Examine the process tree to identify the parent process of control.exe, which may provide context on how the process was initiated.
+- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Investigate the file paths and file types in the command line arguments to verify if they are legitimate or if they could be indicative of malicious activity.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'control.exe' AND cmdline LIKE '%<suspicious_argument>%';` to find other instances of similar command line usage.
+- Analyze recent file modifications in the directories specified in the command line arguments to identify any unauthorized changes or suspicious files.
+- Review system logs for any related events around the time the control.exe process was started to identify any correlated activities or anomalies.
+- Check for any network connections initiated by the control.exe process to determine if there is any suspicious outbound communication.
+- Investigate any scheduled tasks or startup items that might have been used to persistently execute the control.exe process with unusual arguments.
+- Correlate the findings with threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Users may encounter false positives when legitimate applications or system processes use control.exe with unusual file types or paths for valid purposes, such as custom configuration tools or third-party software that integrates with the Control Panel.
+- Some software installations or updates might temporarily use control.exe with paths like `*/AppData/Local/*` or `*:\\\\Users\\\\Public\\\\*` to manage settings or user data, which could trigger the rule.
+- Multimedia applications might inadvertently use image file extensions in command lines for legitimate reasons, leading to false positives when extensions like `*.jpg*` or `*.png*` are detected.
+- To manage these false positives, users can create exceptions for known benign processes or paths by adding them to an allowlist, ensuring that frequent non-threatening behaviors are not flagged.
+- Regularly review and update the allowlist to accommodate new legitimate applications or changes in system behavior, reducing unnecessary alerts while maintaining security.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation of the process command line arguments to confirm the presence of malicious activity, focusing on unusual file types and suspicious paths.
+- Review recent changes to the system, including installed applications and modified files, to identify any unauthorized or suspicious modifications.
+- Utilize endpoint detection and response (EDR) tools to perform a deep scan of the system for additional indicators of compromise (IOCs) and potential persistence mechanisms.
+- Remove any identified malicious files or processes and restore any altered system files from a known good backup.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution data, including command line arguments, to aid in future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are properly set.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and educating users on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
index bb5c221efa9..9d01ccc7c40 100755
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,50 @@ host.os.type:windows and event.category:process and event.type:start and (
   process.parent.name:("cmd.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "cscript.exe" or
     "wscript.exe" or "mshta.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft Build Engine Started by a Script Process
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers during software development. However, adversaries can exploit MSBuild to execute malicious code by embedding scripts within build files, leveraging its trusted status to bypass security controls. The detection rule identifies unusual MSBuild invocations initiated by script interpreters, signaling potential misuse for executing unauthorized actions.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of MSBuild.exe being started by a script process, focusing on the `process.name` and `process.parent.name` fields.
+- Examine the `host.os.type` and `event.category` fields to ensure the event pertains to a Windows process start, confirming the context of the alert.
+- Investigate the parent process (`process.parent.name`) to determine if it is a known script interpreter like `cmd.exe`, `powershell.exe`, or others listed in the query.
+- Check the `process.command_line` field to gather more context on the command executed, looking for any suspicious or unexpected arguments.
+- Correlate the event with other recent process creation events on the same host to identify any patterns or related activities.
+- Use Osquery to list all running processes and their parent-child relationships to identify any other unusual process trees. Example query: `SELECT pid, name, path, parent FROM processes WHERE name = 'msbuild.exe';`
+- Investigate the user account associated with the process (`user.name`) to determine if it aligns with expected usage patterns or if it might be compromised.
+- Review recent file modifications or creations in directories commonly used by MSBuild to identify any unauthorized or suspicious build files.
+- Check for any network connections initiated by the MSBuild process using network monitoring tools to identify potential data exfiltration or command and control activity.
+- Analyze historical data for similar events on the same host or across the environment to determine if this is an isolated incident or part of a broader pattern.
+
+### False positive analysis
+
+- Developers and build automation systems may legitimately invoke MSBuild through scripts for continuous integration and deployment processes, leading to false positives. 
+- Automated testing frameworks might use script-based invocations of MSBuild to compile test environments, which can be mistaken for malicious activity.
+- Some development environments or integrated development environments (IDEs) may use scripts to trigger MSBuild as part of their normal operation, causing benign alerts.
+- To manage these false positives, users can create exceptions for known and trusted script processes or parent processes that regularly invoke MSBuild in a non-threatening manner.
+- Implementing a whitelist of specific script paths or parent process hashes that are verified as part of legitimate development workflows can help reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only verified and non-malicious activities are excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to determine the scope of the incident, focusing on identifying any additional systems that may have been compromised.
+- Analyze the MSBuild process and its parent script process to understand the nature of the payload and any potential persistence mechanisms.
+- Review and collect relevant logs, including PowerShell logs, command line history, and security event logs, to gather evidence and understand the attack vector.
+- Remove any unauthorized or malicious scripts and build files identified during the investigation to prevent further execution.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup to ensure the integrity of the operating environment.
+- Implement enhanced logging and monitoring policies to detect similar activities in the future, such as enabling script block logging and command line auditing.
+- Integrate threat intelligence feeds and security solutions to improve detection capabilities and provide context for future investigations.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
index 3478af63413..755e767f9d5 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,48 @@ process where host.os.type == "windows" and event.type == "start" and
   process.name : "MSBuild.exe" and
   process.parent.name : ("explorer.exe", "wmiprvse.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft Build Engine Started by a System Process
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers or integrated development environments. However, adversaries may exploit MSBuild to execute malicious code by disguising it as a legitimate build process. This detection rule identifies unusual MSBuild activity initiated by system processes like Explorer or WMI, which may indicate an attempt to evade defenses by leveraging trusted utilities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "MSBuild.exe" and the parent process is either "explorer.exe" or "wmiprvse.exe" to ensure the rule was triggered correctly.
+- Check the timestamp of the MSBuild.exe process start event to determine when the activity occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the user account associated with the MSBuild.exe process to determine if it is a legitimate user or if the account may have been compromised.
+- Examine the command line arguments used to start MSBuild.exe to identify any unusual or suspicious parameters that could indicate malicious intent.
+- Use Osquery to gather additional context about the MSBuild.exe process. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'MSBuild.exe';`
+- Analyze the parent process (explorer.exe or wmiprvse.exe) to understand its recent activities and determine if it has been involved in any other suspicious behavior.
+- Check for any network connections initiated by MSBuild.exe to identify potential communication with external servers or command and control infrastructure.
+- Review system logs and security events around the time of the alert to identify any other indicators of compromise or related suspicious activities.
+- Investigate any recent changes to the system, such as new software installations or updates, that could explain the unusual MSBuild activity.
+- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize MSBuild.exe in a similar manner, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Known false positives for the Microsoft Build Engine Started by a System Process rule may include legitimate software installations or updates that utilize MSBuild as part of their setup process. These activities might be initiated by system processes like Explorer or WMI, leading to benign triggers of the detection rule.
+- Development environments or automated build systems that integrate with Windows Explorer or WMI for project management tasks can also cause false positives. These systems might start MSBuild as part of their normal operation, which is non-threatening.
+- To manage these false positives, users can create exceptions for specific parent-child process relationships that are known to be safe. This can be done by identifying the hash or path of the legitimate MSBuild instances and excluding them from the detection rule.
+- Users should regularly review and update their exception lists to ensure that only verified and non-malicious activities are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation to confirm the legitimacy of the MSBuild process by reviewing the process tree and any associated scripts or commands executed.
+- Analyze the parent process (explorer.exe or wmiprvse.exe) to determine if it was compromised or used as a proxy for malicious activity.
+- Review system logs and security alerts to identify any other suspicious activities or related incidents on the network.
+- If malicious activity is confirmed, remove any identified malware or unauthorized scripts from the system.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Implement enhanced logging policies to capture detailed process execution and parent-child relationships for future investigations.
+- Integrate threat intelligence feeds and security solutions to detect similar tactics, techniques, and procedures (TTPs) associated with MITRE ATT&CK T1127.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Apply system hardening measures, such as restricting the execution of MSBuild to authorized users and processes, and regularly update security patches and configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
index 0e0e298687a..ac5d2f1d4da 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,49 @@ query = '''
 host.os.type:windows and event.category:process and event.type:start and process.parent.name:("MSBuild.exe" or "msbuild.exe") and
 process.name:("csc.exe" or "iexplore.exe" or "powershell.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft Build Engine Started an Unusual Process
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries exploit MSBuild to execute malicious scripts or compile code, bypassing security controls. This detection rule identifies unusual processes initiated by MSBuild, such as PowerShell or C# compiler, which may indicate an attempt to deploy obfuscated or malicious payloads, aligning with known evasion techniques.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of unusual processes initiated by MSBuild, focusing on the `process.parent.name` and `process.name` fields to identify the specific processes involved.
+- Examine the process command line arguments (`process.command_line`) for any suspicious or obfuscated scripts that may indicate malicious intent.
+- Check the user account (`user.name`) associated with the MSBuild process to determine if the activity aligns with expected behavior for that user.
+- Investigate the parent process tree to understand the context in which MSBuild was executed, looking for any preceding suspicious activities.
+- Utilize Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('MSBuild.exe', 'csc.exe', 'powershell.exe');` to identify any related processes and their attributes.
+- Analyze the network connections (`network.connection`) established by the suspicious processes to identify any unusual or unauthorized external communications.
+- Review recent file modifications or creations (`file.path`) on the host to detect any potentially malicious payloads or scripts dropped by the processes.
+- Correlate the event timestamp with other security logs (e.g., firewall, intrusion detection systems) to identify any concurrent suspicious activities.
+- Check for any recent changes in system configurations or scheduled tasks that could be associated with the execution of the unusual processes.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise (IOCs) related to MSBuild exploitation.
+
+### False positive analysis
+
+- Developers and build servers often use MSBuild to automate the compilation of code, which may legitimately invoke processes like the C# compiler (csc.exe) or PowerShell scripts for build tasks, leading to false positives.
+- Continuous Integration/Continuous Deployment (CI/CD) pipelines might trigger these processes as part of their normal operation, especially in environments where automated testing or deployment scripts are executed.
+- To manage these false positives, users can create exceptions for specific build servers or developer workstations by excluding known, trusted sources or specific process command lines that are frequently observed and verified as non-threatening.
+- Monitoring the frequency and context of these events can help distinguish between legitimate development activities and potential threats, allowing for more informed decisions on exclusions.
+- Implementing a baseline of normal MSBuild activity within the environment can aid in identifying deviations that are more likely to be malicious, thus reducing the likelihood of overlooking genuine threats while managing false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity.
+- Conduct a thorough investigation to identify the scope of the incident, focusing on any unusual processes initiated by MSBuild, such as PowerShell or C# compiler executions.
+- Analyze the scripts or code executed by MSBuild for any signs of obfuscation or malicious intent, leveraging threat intelligence sources and MITRE ATT&CK framework for context.
+- Terminate any malicious processes identified during the investigation to halt ongoing threats.
+- Remove any malicious files or scripts from the system and ensure that any persistence mechanisms are disabled.
+- Restore the system from a known good backup to ensure that no remnants of the attack remain.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution data, focusing on MSBuild and related processes, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Review and update security policies and hardening measures, such as application whitelisting and script execution restrictions, to prevent exploitation of MSBuild in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
index 17ca6cfd018..6f9396434a2 100644
--- a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
+++ b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,48 @@ process where host.os.type == "windows" and event.type == "start" and
                                "?:\\Windows\\System32\\inetsrv\\w3wp.exe")
          )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential DLL Side-Loading via Trusted Microsoft Programs
+
+DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs. The detection rule identifies unusual execution paths or renamed instances of known vulnerable programs, flagging potential evasion attempts by checking against expected file names and paths.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and executable path that triggered the alert, focusing on the `process.name` and `process.executable` fields.
+- Verify the legitimacy of the process by checking the `process.pe.original_file_name` against known trusted Microsoft programs such as "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", and "DISM.EXE".
+- Investigate the parent process that initiated the suspicious process using the `process.parent.name` and `process.parent.executable` fields to determine if it is a legitimate or expected parent.
+- Check the file path of the executable using the `process.executable` field to see if it matches any non-standard or unexpected paths that deviate from the typical installation directories.
+- Use Osquery to list all DLLs loaded by the suspicious process to identify any unusual or unauthorized DLLs. Example query: `SELECT pid, name, path FROM processes JOIN process_open_sockets USING (pid) WHERE name = '<suspicious_process_name>';`
+- Examine the file creation and modification timestamps of the suspicious executable and any associated DLLs to identify any recent changes that could indicate tampering.
+- Cross-reference the hash of the suspicious executable and DLLs with known malware databases or threat intelligence sources to check for known malicious signatures.
+- Analyze the network activity associated with the suspicious process using network monitoring tools to identify any unusual or unauthorized connections.
+- Review system logs and security events around the time of the alert to gather additional context and identify any related suspicious activities.
+- Consult with other team members or departments to determine if there are any legitimate reasons for the process to be running from a non-standard path, such as a recent software update or deployment.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths, triggering false positives. Users can handle these by monitoring update schedules and creating temporary exceptions during known update windows.
+- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes, such as compatibility or integration needs. Users should document these instances and create exceptions for known benign paths or renamed executables.
+- Virtual environments or sandboxed applications may execute trusted programs from non-standard paths as part of their isolation mechanisms. Users can identify these environments and exclude their specific paths from the detection rule.
+- Security or IT administrative tools might leverage renamed or relocated trusted programs for legitimate system management tasks. Users should verify the legitimacy of these tools and add them to an exception list if they are deemed non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to confirm the presence of unauthorized DLLs by analyzing the process execution paths and comparing them against known trusted paths.
+- Utilize endpoint detection and response (EDR) tools to identify any additional systems that may exhibit similar suspicious behavior.
+- Remove or quarantine any identified malicious DLLs and restore the original trusted Microsoft program files to their correct paths and names.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has established persistence or lateral movement.
+- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring that future anomalies can be detected more efficiently.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of known malicious DLLs and associated tactics.
+- Restore the system to its operational state by applying the latest security patches and updates to all software, particularly focusing on the affected Microsoft programs.
+- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
+- Implement hardening measures such as application whitelisting, restricting DLL loading paths, and educating users on recognizing and reporting suspicious activity."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
index c46c13405b5..65a8b933af6 100644
--- a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
+++ b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/07"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,48 @@ process where host.os.type == "windows" and event.type == "start" and
                               "?:\\Program Files (x86)\\Microsoft Security Client\\*.exe"))
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential DLL Side-Loading via Microsoft Antimalware Service Executable
+
+The Microsoft Antimalware Service Executable is a core component of Windows Defender, responsible for real-time protection against malware. Adversaries may exploit its DLL search order vulnerability by renaming or relocating the executable to load malicious DLLs, bypassing security measures. The detection rule identifies anomalies in the executable's path or name, signaling potential side-loading attempts, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Verify the alert by checking the process details, focusing on the `process.name` and `process.executable` fields to confirm if the executable is running from a non-standard path or has been renamed.
+- Review the `process.pe.original_file_name` field to ensure it matches the expected original file name "MsMpEng.exe" and investigate any discrepancies.
+- Examine the parent process information to determine how the suspicious process was initiated, which might provide insights into potential exploitation methods.
+- Check for any recent file modifications or creations in the directories where the suspicious executable is located, which could indicate tampering or preparation for side-loading.
+- Use Osquery to list all DLLs loaded by the suspicious process to identify any unexpected or malicious DLLs. Example query: `SELECT * FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name = 'MsMpEng.exe');`
+- Investigate the system's event logs for any related security events or anomalies around the time the suspicious process started, focusing on logs that might indicate privilege escalation or lateral movement.
+- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
+- Cross-reference the hash of the suspicious executable with known malware databases to check for any known malicious signatures.
+- Review user activity and access logs to determine if any unauthorized users or accounts were active around the time of the alert.
+- Conduct a historical search for similar alerts or patterns on the host or across the network to assess if this is an isolated incident or part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate software updates or system maintenance tasks may temporarily alter the path or name of the Microsoft Antimalware Service Executable, triggering false positives. Users should verify if any updates or maintenance activities coincide with the detection.
+- Some third-party security or system optimization tools might interact with Windows Defender in a way that changes the executable's path or name. Users should review the list of installed software to identify any such tools and consider excluding their activities if deemed safe.
+- In enterprise environments, custom scripts or deployment tools might relocate or rename the executable for legitimate reasons. Users should consult with IT administrators to confirm if such practices are in place and create exceptions for these known activities.
+- To manage false positives, users can create exceptions in their security monitoring tools for specific paths or names that are verified as non-threatening. This involves updating the detection rule to exclude these known benign behaviors while ensuring that the core detection capabilities remain intact.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Verify the legitimacy of the Microsoft Antimalware Service Executable by checking its path and name against known safe locations and names.
+- Conduct a thorough investigation to identify any malicious DLLs loaded by the renamed or relocated executable.
+- Utilize endpoint detection and response (EDR) tools to analyze the process tree and identify any suspicious child processes or network connections.
+- Remove any identified malicious DLLs and restore the Microsoft Antimalware Service Executable to its original state and location.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
+- Integrate threat intelligence feeds to correlate the detected activity with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by applying the latest security patches and updates to Windows Defender and the operating system.
+- Harden the system by configuring application whitelisting and ensuring that only trusted executables and DLLs are allowed to run."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_file_creation_mult_extension.toml b/rules/windows/defense_evasion_file_creation_mult_extension.toml
index b3b03816550..e495e8c575b 100644
--- a/rules/windows/defense_evasion_file_creation_mult_extension.toml
+++ b/rules/windows/defense_evasion_file_creation_mult_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,49 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten
   not (process.executable : ("?:\\Windows\\System32\\msiexec.exe", "C:\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe") and
        file.path : "?:\\Program Files\\QGIS *\\apps\\grass\\*.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Executable File Creation with Multiple Extensions
+
+In Windows environments, files with multiple extensions can be used by adversaries to disguise malicious executables as benign files, such as documents or images. This technique, known as masquerading, exploits user trust and can bypass security measures. The detection rule identifies suspicious file creations by checking for executables with misleading extensions, excluding known legitimate processes, to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file name and path that triggered the rule, focusing on the `file.name` and `file.path` fields.
+- Verify the file extension pattern by checking if the file name matches the regex pattern for multiple extensions, particularly looking for `.exe` files masquerading as other types.
+- Examine the `process.executable` field to determine the process responsible for creating the file, ensuring it is not a known legitimate process like `msiexec.exe`.
+- Use Osquery to gather additional context about the file by running a query such as: `SELECT * FROM file WHERE path = 'C:\\\\Path\\\\To\\\\SuspiciousFile.exe';` to retrieve metadata and attributes.
+- Investigate the parent process of the file creation event by examining the `process.parent` field to understand the origin of the executable.
+- Check the file's digital signature and hash against known threat intelligence databases to assess its legitimacy.
+- Analyze recent user activity on the host to identify any unusual behavior or actions that might have led to the file creation.
+- Review system logs for any other suspicious activities or anomalies around the time of the file creation event.
+- Investigate network connections from the host to determine if there are any suspicious outbound connections that could indicate data exfiltration or command and control communication.
+- Correlate the findings with other alerts or incidents in the environment to identify potential patterns or related threats.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate software installations or updates create files with multiple extensions, such as setup or update executables that include additional extensions for versioning or compatibility purposes.
+- Users can handle these false positives by creating exceptions for specific processes or file paths that are known to be safe, such as trusted software installers or update mechanisms.
+- Another potential false positive source is software development environments where developers might create test files with multiple extensions for debugging or testing purposes.
+- To manage these, users can exclude specific directories or processes associated with development tools from the detection rule.
+- It's important to regularly review and update the list of exceptions to ensure that only verified and trusted activities are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to identify the source and scope of the masquerading executable, using endpoint detection and response (EDR) tools.
+- Analyze the file creation event and associated processes to determine if any unauthorized changes or additional malicious activities have occurred.
+- Remove the malicious executable and any associated files or registry entries from the system.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on executable files with multiple extensions.
+- Integrate threat intelligence feeds to improve detection capabilities and correlate with known indicators of compromise (IOCs) related to masquerading techniques.
+- Educate users on the risks of opening files with multiple extensions and the importance of verifying file types before execution.
+- Apply system hardening measures, such as restricting script execution policies and enforcing application whitelisting, to reduce the attack surface and prevent similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
index 25ed246466d..d9cab01bc42 100644
--- a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
+++ b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,48 @@ registry where host.os.type == "windows" and
 /* update here with encoding combinations */
  registry.data.strings : "TVqQAAMAAAAEAAAA*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Encoded Executable Stored in the Registry
+
+Windows Registry is a critical system database that stores configuration settings and options. Adversaries may exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications by searching for specific encoded patterns, indicating potential defense evasion tactics. This helps analysts pinpoint and investigate hidden threats effectively.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path and key where the encoded executable was detected. This information is crucial for understanding the scope and potential impact.
+- Use the registry path and key information to perform a manual inspection of the registry entry. Verify the presence of the encoded data and assess its legitimacy.
+- Decode the identified encoded string to determine if it corresponds to a known malicious executable or if it appears suspicious. Utilize tools or scripts capable of decoding base64 or other encoding schemes.
+- Cross-reference the decoded executable with known malware signatures or hashes using threat intelligence databases to identify any matches with known threats.
+- Investigate the process that made the registry modification by correlating the timestamp of the registry change with process creation logs. This can help identify the responsible process or user.
+- Utilize Osquery to gather additional context about the system. For example, run the following query to list recent registry modifications: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\%\\\\%';`
+- Check for any associated network activity around the time of the registry modification. Look for unusual outbound connections that might indicate data exfiltration or command and control communication.
+- Examine the system for other indicators of compromise, such as unusual scheduled tasks, startup items, or services that could be related to the encoded executable.
+- Review user activity logs to determine if the registry modification aligns with legitimate user actions or if it appears to be unauthorized or suspicious.
+- Consult with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather additional insights and corroborate findings from the registry investigation.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the registry with encoded data, which could trigger the detection rule. Users should verify the source and purpose of such modifications to determine if they are benign.
+- Some security tools or system management software might store encoded executables in the registry as part of their normal operation. Users can create exceptions for these known applications to prevent unnecessary alerts.
+- Custom scripts or administrative tools developed in-house may use encoded registry entries for configuration or deployment purposes. It is advisable to document these practices and exclude them from the detection rule if they are verified as non-threatening.
+- Regularly review and update the list of exceptions to ensure that only verified and trusted software is excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the registry modifications to confirm the presence of encoded executables and identify the scope of the compromise.
+- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) related to the identified threat.
+- Remove or revert unauthorized registry changes to eliminate the persistence mechanism used by the adversary.
+- Restore affected systems from known good backups to ensure the removal of any hidden malicious executables.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Implement enhanced logging policies to capture detailed registry activity and monitor for similar suspicious patterns in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for registry-based threats.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
+- Educate users on recognizing and reporting suspicious activities to reduce the risk of future incidents involving registry modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_injection_msbuild.toml b/rules/windows/defense_evasion_injection_msbuild.toml
index d89f796cde2..5bcc6479a16 100755
--- a/rules/windows/defense_evasion_injection_msbuild.toml
+++ b/rules/windows/defense_evasion_injection_msbuild.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,48 @@ query = '''
 process where host.os.type == "windows" and process.name: "MSBuild.exe" and
     event.action:("CreateRemoteThread detected (rule: CreateRemoteThread)", "CreateRemoteThread")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Injection by the Microsoft Build Engine
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries exploit MSBuild to perform process injection, a technique to execute malicious code within the address space of another process, thereby evading detection and elevating privileges. The detection rule identifies suspicious activity by monitoring MSBuild for actions like creating remote threads, a common indicator of process injection attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the "CreateRemoteThread" event action associated with "MSBuild.exe" to ensure the alert is not a false positive.
+- Check the process tree to identify the parent process of "MSBuild.exe" to determine if it was launched by a legitimate application or a suspicious one.
+- Investigate the command line arguments used to launch "MSBuild.exe" to identify any unusual or unexpected parameters that could indicate malicious activity.
+- Examine the timeline of events leading up to and following the "CreateRemoteThread" event to identify any other suspicious activities or patterns.
+- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'MSBuild.exe';`
+- Check for any network connections initiated by "MSBuild.exe" to external IP addresses, which could indicate data exfiltration or command and control communication.
+- Analyze any files or scripts that "MSBuild.exe" may have accessed or executed to determine if they contain malicious code or payloads.
+- Review the user account context under which "MSBuild.exe" was executed to assess if it aligns with expected user behavior or if it indicates potential credential compromise.
+- Correlate the alert with other security events or logs from the same host or network segment to identify if this is part of a broader attack campaign.
+- Consult threat intelligence sources to determine if there are known attack patterns or campaigns involving MSBuild process injection that match the observed behavior.
+
+### False positive analysis
+
+- Legitimate software development activities: MSBuild is commonly used in development environments, and legitimate processes may create remote threads as part of normal operations. Developers should verify if the activity aligns with known development tasks.
+- Automated build systems: Continuous integration and deployment systems might trigger MSBuild to perform actions that resemble process injection. Users should review the context of the build process to determine if the activity is expected.
+- Debugging tools: Some debugging or profiling tools may interact with processes in a way that mimics process injection. Users should check if such tools are running and exclude their activities if verified as non-threatening.
+- Excluding known safe processes: Users can create exceptions for specific processes or environments where MSBuild's behavior is understood and deemed safe, reducing noise from false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the threat.
+- Conduct a thorough investigation to confirm the presence of process injection by analyzing logs and memory dumps for suspicious activity related to MSBuild.
+- Terminate any malicious processes identified during the investigation to halt ongoing malicious activities.
+- Review and analyze the affected system's startup items, scheduled tasks, and services for unauthorized changes or additions.
+- Restore the system from a known good backup if available, ensuring that the backup is free from any signs of compromise.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process creation and thread injection events for future analysis.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_installutil_beacon.toml b/rules/windows/defense_evasion_installutil_beacon.toml
index 6abd0388863..d1d47636da7 100644
--- a/rules/windows/defense_evasion_installutil_beacon.toml
+++ b/rules/windows/defense_evasion_installutil_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,49 @@ 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")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 execute malicious code under the guise of legitimate operations, often to bypass security measures. The detection rule identifies suspicious activity by monitoring for outbound network connections initiated by InstallUtil.exe, which is atypical behavior for this utility, thus signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "installutil.exe" and verify the network connection direction is "outgoing" or "egress" as specified in the detection rule.
+- Check the process entity ID to identify the specific instance of InstallUtil.exe that initiated the network connection.
+- Investigate the parent process of InstallUtil.exe to determine how it was launched and assess if this is part of a legitimate operation or potentially malicious activity.
+- Examine the command line arguments used with InstallUtil.exe to identify any unusual or suspicious parameters that could indicate malicious intent.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'installutil.exe';` to retrieve details like process start time, user, and parent process.
+- Analyze the destination IP address and port of the network connection to determine if it is associated with known malicious infrastructure or if it is an expected destination for legitimate operations.
+- Cross-reference the network connection details with threat intelligence sources to identify any known indicators of compromise (IOCs) related to the destination.
+- Review recent system logs and security events for any other suspicious activities or anomalies that occurred around the same time as the InstallUtil.exe network connection.
+- Investigate the user account under which InstallUtil.exe was executed to determine if it has been compromised or if there are any signs of unauthorized access.
+- Check for any recent changes or installations on the system that could explain the use of InstallUtil.exe, such as legitimate software updates or installations, to rule out false positives.
+
+### False positive analysis
+
+- Legitimate software installations or updates: Some legitimate applications may use InstallUtil.exe to perform necessary installations or updates, which could trigger the detection rule. Users should verify if the network connection is associated with a known and trusted software installation or update process.
+- Internal network connections: InstallUtil.exe might be used within an organization's internal network for legitimate administrative tasks. If the network connections are directed towards internal IP addresses or known internal servers, these can be considered for exclusion.
+- Automated deployment tools: Organizations using automated deployment tools or scripts that leverage InstallUtil.exe for legitimate purposes might trigger false positives. Users should identify these tools and consider creating exceptions for known benign activities.
+- Exclude known benign processes: Users can create exceptions for specific processes or scripts that are verified to use InstallUtil.exe for legitimate purposes, ensuring these are documented and regularly reviewed to prevent abuse.
+- Regular monitoring and review: Continuously monitor and review alerts to distinguish between legitimate and suspicious activities, updating exceptions as necessary to minimize false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm the malicious use of InstallUtil.exe by reviewing process execution logs and network connection details.
+- Terminate any suspicious processes associated with InstallUtil.exe to halt ongoing malicious activities.
+- Analyze the network traffic logs to identify any external IP addresses or domains contacted by InstallUtil.exe and block them at the firewall.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Restore the system to a known good state by reimaging the affected machine and applying the latest security patches and updates.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious use of system binaries like InstallUtil.exe.
+- Educate users and administrators on the risks associated with misuse of legitimate utilities and encourage reporting of unusual system behavior.
+- Review and update security policies to include specific measures against system binary proxy execution techniques as outlined in MITRE ATT&CK T1218."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
index ff5cb36de8a..8e8c267d1cf 100644
--- a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
+++ b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,51 @@ process where host.os.type == "windows" and event.type == "start" and
         "\\Device\\HarddiskVolume?\\Program Files\\*\\cdb.exe"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution via Windows Command Debugging Utility
+
+The Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. The detection rule identifies suspicious use of cdb.exe by monitoring its execution outside standard installation paths and checking for specific command-line arguments, indicating potential misuse for malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of cdb.exe execution outside the standard installation paths specified in the detection rule.
+- Verify the process arguments used with cdb.exe by examining the `process.args` field to identify any suspicious commands such as `-cf`, `-c`, or `-pd`.
+- Check the `process.executable` field to determine the exact path from which cdb.exe was executed, ensuring it is not within the expected directories.
+- Investigate the parent process of cdb.exe using the `process.parent.name` and `process.parent.executable` fields to understand how cdb.exe was launched and identify potential malicious parent processes.
+- Correlate the event timestamp with other security logs to identify any concurrent suspicious activities or anomalies on the host.
+- Use Osquery to gather additional context about the process and its execution environment. For example, run the following Osquery query to list all processes related to cdb.exe:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'cdb.exe';
+  ```
+- Examine the user account associated with the cdb.exe process using the `process.user.name` field to determine if the account is legitimate and authorized to perform debugging tasks.
+- Investigate network connections established by the host around the time of the alert to identify any unusual outbound connections that may indicate data exfiltration or command-and-control activity.
+- Review recent file modifications and creations on the host to detect any unauthorized changes or the presence of suspicious files that may have been introduced by the execution of cdb.exe.
+- Consult threat intelligence sources to determine if there are known campaigns or threat actors that utilize cdb.exe for malicious purposes, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate software development and debugging activities: Developers and IT professionals may use cdb.exe for legitimate debugging purposes, which can trigger the detection rule. To manage this, users can create exceptions for known development environments or specific user accounts that regularly perform debugging tasks.
+- Automated testing environments: Continuous integration and automated testing setups might utilize cdb.exe as part of their processes. Users should identify these environments and exclude them from the rule to prevent false positives.
+- System administration scripts: Some system administrators might use cdb.exe in scripts for maintenance or monitoring tasks. It's advisable to review these scripts and whitelist them if they are verified as non-threatening.
+- Security tools and forensic analysis: Security teams might employ cdb.exe during forensic investigations or security assessments. Users should document these activities and exclude them from the detection rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been affected.
+- Analyze the command-line arguments used with cdb.exe to understand the adversary's intent and actions taken on the system.
+- Review system and security logs to identify any other suspicious activities or anomalies that occurred around the time of the alert.
+- Remove any unauthorized or malicious files and restore any altered system files from a known good backup.
+- Apply patches and updates to the operating system and installed applications to mitigate any exploited vulnerabilities.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks associated with misuse of legitimate tools like cdb.exe and enforce strict access controls to limit their use."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
index 2aa5a43e6fe..611b69e3384 100644
--- a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
+++ b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -71,6 +71,48 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Endpoint Security Parent Process
+
+Endpoint security solutions, like Elastic Endpoint, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes. The detection rule identifies anomalies by flagging unexpected parent processes of endpoint security executables, excluding known benign sources, to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific parent process executable and its path that triggered the alert, focusing on the `process.parent.executable` field.
+- Verify the legitimacy of the parent process by checking its digital signature and comparing it against known trusted signatures.
+- Investigate the process tree to understand the relationship between the parent and child processes, using the `process.name` and `process.parent.executable` fields to map out the hierarchy.
+- Examine the command-line arguments of the parent process using the `process.args` field to identify any unusual or suspicious commands that may indicate malicious activity.
+- Use Osquery to gather additional context about the parent process. For example, run the following query to retrieve details about the parent process: `SELECT * FROM processes WHERE path = '<parent_process_path>';`.
+- Check the file hash of the parent process executable against threat intelligence databases to determine if it is associated with known malware.
+- Analyze recent system logs and security events for any other anomalies or related activities around the time the suspicious process was started.
+- Investigate the user account associated with the process start event to determine if there are any signs of compromise or unusual behavior.
+- Review network connections initiated by the suspicious process to identify any unexpected or unauthorized external communications.
+- Correlate the findings with other alerts or incidents in the environment to determine if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- Known false positives for the Suspicious Endpoint Security Parent Process rule may include legitimate administrative or system maintenance activities where processes like `cmd.exe` or `powershell.exe` are used to execute benign scripts or commands. These activities might be flagged if they involve endpoint security executables as child processes.
+- Users can manage these false positives by adding exceptions for specific parent processes and command-line arguments that are known to be safe. For instance, if a script regularly uses `powershell.exe` with arguments like "status" or "upgrade" for legitimate purposes, these can be added to the exclusion list to prevent unnecessary alerts.
+- It's important to regularly review and update the list of excluded processes and arguments to ensure that only verified benign activities are excluded, maintaining a balance between security and operational efficiency.
+- Users should also consider the context of the flagged activity, such as the time of execution and the user account involved, to better assess whether an alert is a false positive or a potential threat.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the parent process to determine if it is indeed malicious, using forensic tools to analyze process memory and behavior.
+- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
+- Review and collect relevant logs from the endpoint and network devices to understand the scope and impact of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Restore the system from a known good backup if the investigation confirms system compromise, ensuring that the backup is free from any malicious code.
+- Apply security patches and updates to the operating system and all installed software to mitigate vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities against similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
index 69125b3d1b2..5601b1148bb 100644
--- a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
+++ b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -163,6 +163,49 @@ process where host.os.type == "windows" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Masquerading as Business App Installer
+
+In Windows environments, executables often mimic legitimate business apps to deceive users into executing malicious software. Adversaries exploit this by distributing fake installers via ads or forums. The detection rule identifies suspicious executables in user download directories that lack proper code signatures from trusted developers, flagging potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific executable name and path that triggered the alert, focusing on the `process.name` and `process.executable` fields.
+- Verify the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to determine if the executable is indeed unsigned or signed by an untrusted entity.
+- Check the download source by examining browser history or download logs to identify how the executable was obtained, focusing on potential malicious ads or forum links.
+- Use Osquery to gather additional context about the executable. For example, run the following query to check the file's metadata and hash: `SELECT path, filename, md5, sha256, size FROM hash WHERE path = 'C:\\\\Users\\\\<username>\\\\Downloads\\\\<executable_name>'`.
+- Investigate the parent process that initiated the download or execution of the suspicious file by examining the `process.parent` field to understand the execution chain.
+- Cross-reference the executable's hash with known malware databases or threat intelligence platforms to check for any known malicious indicators.
+- Analyze the network activity associated with the executable using network logs or tools to identify any suspicious outbound connections or data exfiltration attempts.
+- Check for any persistence mechanisms that the executable might have established by reviewing startup items, scheduled tasks, or registry entries.
+- Review user activity logs around the time of the alert to identify any unusual behavior or actions that might indicate compromise.
+- Consult with the user who downloaded or executed the file to gather additional context and verify if they were expecting the download or if it was unsolicited.
+
+### False positive analysis
+
+- Legitimate software updates or beta versions may not have updated code signatures, leading to false positives. Users can verify the source and version of the software and create exceptions for these specific versions.
+- Custom or internally developed applications that mimic the naming conventions of popular business apps but are not signed by a recognized authority can trigger alerts. Organizations should ensure these applications are signed with a trusted internal certificate or add them to an exception list.
+- Some third-party tools or utilities that integrate with or enhance the functionality of legitimate business applications might not be signed by the original developer. Users should verify the legitimacy of these tools and consider adding them to an exception list if they are deemed safe.
+- In educational or testing environments, users might intentionally download unsigned versions of software for learning purposes. In such cases, exceptions can be made for specific user accounts or directories to prevent unnecessary alerts.
+- Users can manage false positives by regularly reviewing and updating the list of trusted code signatures and ensuring that any exceptions are documented and justified to maintain security integrity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Verify the legitimacy of the executable by checking its hash against known malware databases and consulting with the software vendor if necessary.
+- Terminate any suspicious processes associated with the masquerading executable to halt any ongoing malicious activity.
+- Conduct a thorough investigation of the system to identify any additional indicators of compromise or lateral movement.
+- Remove the malicious executable and any related files from the system to prevent re-execution.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Update and patch all software and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
+- Implement enhanced logging and monitoring policies to capture detailed process execution and network activity for future investigations.
+- Educate users on recognizing phishing attempts and the risks of downloading executables from untrusted sources.
+- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further analysis and threat intelligence sharing."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_communication_apps.toml b/rules/windows/defense_evasion_masquerading_communication_apps.toml
index 27f59a47cb9..ea8c87169c9 100644
--- a/rules/windows/defense_evasion_masquerading_communication_apps.toml
+++ b/rules/windows/defense_evasion_masquerading_communication_apps.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -90,6 +90,52 @@ process where host.os.type == "windows" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Masquerading as Communication Apps
+
+Communication apps are integral to business operations, facilitating collaboration and information exchange. Adversaries may exploit these apps by masquerading malicious processes as legitimate ones, bypassing security measures and deceiving users. The detection rule identifies suspicious instances by checking for unsigned or improperly signed processes, ensuring they match known trusted signatures, thus flagging potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify which specific communication app process triggered the alert, focusing on the `process.name` field.
+- Verify the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to confirm if the process is unsigned or improperly signed.
+- Check the process's parent process using the `process.parent.name` field to determine if it was spawned by a legitimate application or a suspicious one.
+- Investigate the process's command line arguments using the `process.command_line` field to identify any unusual or unexpected parameters.
+- Use Osquery to gather additional information about the process. For example, run the following query to check for any anomalies in the process's file path or hash:
+  ```sql
+  SELECT path, md5, sha256 FROM processes WHERE name = 'slack.exe' OR name = 'WebexHost.exe' OR name = 'Teams.exe' OR name = 'Discord.exe' OR name = 'Rocket.Chat.exe' OR name = 'Mattermost.exe' OR name = 'WhatsApp.exe' OR name = 'Zoom.exe' OR name = 'outlook.exe' OR name = 'thunderbird.exe';
+  ```
+- Examine the network connections established by the process using the `network.connection` field to identify any suspicious or unauthorized external communications.
+- Check the process's file path and compare it with the expected installation directory for the legitimate application to detect any discrepancies.
+- Review recent system logs and events around the time the process was started to identify any related activities or anomalies.
+- Investigate the user account associated with the process using the `user.name` field to determine if the activity aligns with the user's typical behavior.
+- Correlate the findings with other security alerts or incidents to identify any patterns or connections that may indicate a broader attack campaign.
+
+### False positive analysis
+
+- Unsigned or improperly signed legitimate applications: Some legitimate communication apps may occasionally have unsigned or improperly signed updates or versions, leading to false positives. Users should verify the legitimacy of the application version and consider adding exceptions for known safe versions.
+- Custom or internal communication tools: Organizations may use custom-built communication tools that mimic the names of popular apps for compatibility or user familiarity. These should be reviewed and, if deemed safe, added to an allowlist to prevent false positives.
+- Development or testing environments: In environments where communication apps are frequently modified or tested, unsigned versions may trigger alerts. Users should ensure these environments are isolated and consider excluding them from the rule to avoid unnecessary alerts.
+- Third-party integrations or plugins: Some third-party tools or plugins may interact with communication apps, causing them to appear unsigned or improperly signed. Users should verify these integrations and, if trusted, create exceptions for them.
+- Temporary network issues: Occasional network issues might prevent proper signature verification, leading to false positives. Users should monitor for repeated occurrences and investigate network stability if this becomes a frequent issue.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware.
+- Verify the legitimacy of the detected process by checking the file path, hash, and any associated network activity.
+- Terminate any suspicious processes that are confirmed to be malicious or unauthorized.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware.
+- Review system and security logs to trace the origin and timeline of the suspicious activity, focusing on any unauthorized access or changes.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed or if there is potential for widespread impact.
+- Implement or update application allowlists to ensure only trusted and signed applications can execute on the system.
+- Enhance logging policies to capture detailed process execution and code signing events for future investigations.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be remediated.
+- Apply security patches and updates to the operating system and all installed applications to mitigate vulnerabilities that could be exploited by similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
index c6e35d6317b..e6c906234f0 100644
--- a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
+++ b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,49 @@ process where host.os.type == "windows" and event.type == "start" and
 
   not process.executable : ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious WerFault Child Process
+
+WerFault.exe is a Windows Error Reporting tool that handles application crashes. Adversaries may exploit it by manipulating the SilentProcessExit registry key to stealthily execute malicious processes. The detection rule identifies unusual child processes of WerFault.exe, focusing on specific command-line arguments indicative of this abuse, while excluding known legitimate executables, thus highlighting potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the command line arguments of the suspicious WerFault child process to confirm the presence of "-s", "-t", and "-c" flags, which are indicative of SilentProcessExit abuse.
+- Examine the parent process details, specifically WerFault.exe, to verify its legitimacy and check for any anomalies in its execution context.
+- Investigate the process executable path to ensure it is not one of the known legitimate executables excluded in the detection rule, such as "?:\\\\Windows\\\\SysWOW64\\\\Initcrypt.exe" or "?:\\\\Program Files (x86)\\\\Heimdal\\\\Heimdal.Guard.exe".
+- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
+- Check for any file writes or modifications made by the suspicious process to detect potential data exfiltration or tampering activities.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all child processes of WerFault.exe: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'WerFault.exe');`
+- Correlate the process start event with other security logs to identify any related activities or patterns that might indicate a broader attack.
+- Investigate the user account under which the suspicious process was executed to determine if it has been compromised or is being misused.
+- Review recent changes to the registry, particularly the SilentProcessExit key, to identify unauthorized modifications that could facilitate process masquerading.
+- Cross-reference the suspicious process with threat intelligence sources to determine if it matches any known malicious signatures or behaviors.
+
+### False positive analysis
+
+- Known false positives for the Suspicious WerFault Child Process rule may include legitimate software that uses the SilentProcessExit mechanism for valid purposes, such as certain system utilities or third-party applications that are not widely recognized.
+- Users can handle these false positives by creating exceptions for specific executables that are known to be safe and frequently trigger the rule. This can be done by adding these executables to the exclusion list in the detection rule.
+- It is important to verify the legitimacy of the process by checking the digital signature of the executable and ensuring it matches the expected vendor.
+- Regularly review and update the exclusion list to accommodate new legitimate software that may be introduced into the environment, while ensuring that no malicious processes are inadvertently excluded.
+- Consider implementing additional monitoring for excluded processes to ensure they do not exhibit other suspicious behaviors, such as unexpected network connections or file modifications, which could indicate a compromise.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Investigate the suspicious WerFault child process by reviewing the command line arguments, network connections, and file writes to determine the scope and impact of the incident.
+- Terminate any malicious processes identified during the investigation to stop ongoing threats.
+- Review and analyze the SilentProcessExit registry key for unauthorized modifications and revert any changes to their default state.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if assistance is needed for further analysis.
+- Implement enhanced logging policies to capture detailed process execution and registry changes for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are correctly set.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and regularly reviewing security policies to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_trusted_directory.toml b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
index 34442a07c20..ef084008203 100644
--- a/rules/windows/defense_evasion_masquerading_trusted_directory.toml
+++ b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -75,6 +75,49 @@ process where host.os.type == "windows" and event.type == "start" and
       )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Program Files Directory Masquerading
+
+The Program Files directories in Windows are trusted locations typically reserved for legitimate software installations. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures that whitelist these paths. The detection rule identifies suspicious executions from directories mimicking these trusted paths, excluding known legitimate locations, to flag potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific executable path that triggered the rule, focusing on the `process.executable` field to understand the masquerading attempt.
+- Verify the legitimacy of the directory by checking for any typos or slight variations in the directory name compared to known trusted paths like `C:\\Program Files` or `C:\\Program Files (x86)`.
+- Use Osquery to list all executables in the suspicious directory. Example query: `SELECT path, name, sha256 FROM file WHERE directory LIKE 'C:\\\\%Program%Files%\\\\%' AND NOT directory LIKE 'C:\\\\Program Files%' AND NOT directory LIKE 'C:\\\\Program Files (x86)%';`
+- Investigate the file metadata, such as creation and modification dates, to determine if the executable was recently added or modified, which might indicate malicious activity.
+- Check the file's digital signature to verify its authenticity and identify the publisher. Unsigned or suspiciously signed files may warrant further investigation.
+- Correlate the process start event with other logs, such as user login events, to identify the user account associated with the execution and assess if the activity aligns with their typical behavior.
+- Analyze the parent process of the suspicious executable to understand how it was launched and if it was initiated by a legitimate process or another potentially malicious one.
+- Search for any network connections initiated by the process to external IP addresses, which could indicate data exfiltration or command and control communication.
+- Review any recent changes to the system, such as software installations or updates, that might explain the presence of the executable in the masquerading directory.
+- Consult threat intelligence sources to check if the file hash or any related indicators of compromise (IOCs) are associated with known malware or adversary campaigns.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate software installations or updates that create temporary directories mimicking the Program Files path structure. These can include software development tools or custom applications that use non-standard installation paths.
+- Users can manage these false positives by creating exceptions for specific executable paths that are verified as legitimate. This can be done by adding these paths to the exclusion list in the detection rule.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate software paths that may trigger the rule.
+- Consider implementing a process to verify the legitimacy of any new paths that trigger the rule before adding them to the exclusion list, ensuring that only trusted software is excluded.
+- Collaborate with IT and security teams to maintain an updated inventory of software installations and their expected paths, which can help in quickly identifying false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation to identify the source and scope of the masquerading attempt, focusing on the suspicious directories and executables.
+- Terminate any malicious processes identified during the investigation to prevent further execution.
+- Remove or quarantine any malicious files found in the masquerading directories to eliminate the threat.
+- Review and update allowlisting policies to ensure only legitimate software can execute from trusted directories.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution data, focusing on directory paths and executable names.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by reinstalling affected software from trusted sources and applying the latest security patches.
+- Conduct a security awareness training session for users to recognize and report suspicious activities, emphasizing the importance of directory integrity."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_mshta_beacon.toml b/rules/windows/defense_evasion_mshta_beacon.toml
index e36fa0afdba..ffe230f6755 100644
--- a/rules/windows/defense_evasion_mshta_beacon.toml
+++ b/rules/windows/defense_evasion_mshta_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,51 @@ sequence by process.entity_id with maxspan=10m
      not process.args : "ADSelfService_Enroll.hta"]
   [network where host.os.type == "windows" and process.name : "mshta.exe"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Mshta Making Network Connections
+
+Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, bypassing security measures. The detection rule identifies suspicious network activity by Mshta, excluding known benign processes, to flag potential threats. This helps in identifying unauthorized script execution and network connections, indicating possible malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of Mshta.exe making outbound network connections and verify the process entity ID for correlation.
+- Check the process start event to gather additional context, such as the exact command line arguments used with Mshta.exe, to identify potential malicious scripts.
+- Investigate the parent process of Mshta.exe to determine if it is a known benign process or if it could be part of a suspicious chain of execution.
+- Examine the network connections made by Mshta.exe, including destination IP addresses and ports, to identify any known malicious or suspicious endpoints.
+- Utilize Osquery to gather more information about the Mshta.exe process. For example, run the following query to list all network connections made by Mshta.exe:
+  ```sql
+  SELECT pid, local_address, local_port, remote_address, remote_port, state FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'mshta.exe');
+  ```
+- Cross-reference the network activity with threat intelligence sources to determine if the IP addresses or domains are associated with known threats.
+- Analyze the timeline of events to see if there are any other suspicious activities occurring around the same time as the Mshta.exe execution.
+- Check for any other alerts or logs related to the same process entity ID to identify if this is part of a larger attack pattern.
+- Investigate the user account under which Mshta.exe was executed to determine if it has been compromised or is being used for unauthorized activities.
+- Review system logs and other security tools for any additional indicators of compromise that may correlate with the Mshta.exe activity.
+
+### False positive analysis
+
+- Known false positives for the Mshta Making Network Connections rule include legitimate applications that use mshta.exe for valid purposes, such as software updates or internal scripts executed by IT departments. These can trigger alerts if not properly excluded.
+- Users can manage these false positives by creating exceptions for specific parent processes or command-line arguments that are known to be safe. For instance, if a particular internal application frequently uses mshta.exe, its parent process can be added to the exclusion list.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate use cases for mshta.exe, minimizing unnecessary alerts while maintaining security.
+- Consider implementing a monitoring period to observe mshta.exe activity and identify patterns that are consistently benign, which can then be safely excluded from triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the execution of mshta.exe and any associated scripts or payloads.
+- Terminate any malicious processes associated with mshta.exe and remove any unauthorized scripts or files from the system.
+- Review and analyze logs from security information and event management (SIEM) systems to trace the attack vector and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of known malicious indicators related to mshta.exe abuse.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as application whitelisting and user education on phishing threats.
+- Document the incident and response actions taken, updating incident response plans and playbooks to improve readiness for future incidents involving similar tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
index 3ec331c277f..1dd30da230c 100644
--- a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
+++ b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,49 @@ sequence by process.entity_id with maxspan=1m
  not (process.name : ("rundll32.exe", "regsvr32.exe") and process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*"))]
 [any where host.os.type == "windows" and event.category in ("network", "dns") and process.name != null]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 MsiExec Service Child Process With Network Connection
+
+MsiExec is a Windows utility for installing, modifying, and removing applications. Adversaries exploit it to execute malicious payloads by spawning child processes that initiate network connections, often bypassing security controls. The detection rule identifies suspicious child processes of MsiExec that engage in network or DNS activities, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific process entity ID and timestamp of the suspicious activity.
+- Verify the parent process by checking if the parent process name is "msiexec.exe" and confirm the presence of the "/v" argument, which may indicate verbose logging or specific installation actions.
+- Examine the child process executable path to ensure it does not match known legitimate paths such as "?:\\\\Windows\\\\System32\\\\msiexec.exe" or "?:\\\\Program Files\\\\*.exe".
+- Investigate the child process name and arguments to identify any unusual or unexpected executables or scripts being executed.
+- Check for any network or DNS activity associated with the child process to identify potential command and control communication or data exfiltration attempts.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <child_process_id>;` to retrieve detailed information about the process.
+- Analyze the process creation time and compare it with known legitimate software installation or update schedules to rule out false positives.
+- Investigate the user account under which the process was executed to determine if it aligns with expected user behavior or if it indicates potential compromise.
+- Review historical data for similar alerts or patterns involving the same process or user to identify any recurring suspicious activity.
+- Correlate the findings with threat intelligence sources to determine if the activity matches known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they involve network connections, as some installers use MsiExec to download additional components or updates from the internet.
+- System administrators or IT personnel performing routine software maintenance or deployment might inadvertently cause alerts when using MsiExec for legitimate purposes.
+- Some enterprise environments use custom scripts or automation tools that leverage MsiExec for software management, which could be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for known and trusted software installations by excluding specific process names or paths that are frequently involved in legitimate activities.
+- Regularly review and update the exclusion list to ensure it reflects the current software landscape and organizational practices, minimizing unnecessary alerts while maintaining security vigilance.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation of the child process spawned by MsiExec to determine if it is part of a legitimate installation or a malicious payload.
+- Review network logs and DNS queries associated with the suspicious process to identify any external connections or data exfiltration attempts.
+- If malicious activity is confirmed, remove any unauthorized software or malware from the system using trusted antivirus or endpoint detection and response (EDR) tools.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process creation, network activity, and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate and detect similar threats in real-time.
+- Apply system hardening measures, such as restricting the use of MsiExec to authorized users and applications, and implementing application whitelisting.
+- Educate users on recognizing phishing attempts and the risks of executing unknown installers to reduce the likelihood of initial access through social engineering."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_msxsl_network.toml b/rules/windows/defense_evasion_msxsl_network.toml
index 513740d35b9..4a0ec99a494 100644
--- a/rules/windows/defense_evasion_msxsl_network.toml
+++ b/rules/windows/defense_evasion_msxsl_network.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,48 @@ sequence by process.entity_id
        "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")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Connection via MsXsl
+
+MsXsl.exe is a legitimate Windows utility used to transform XML data using XSLT stylesheets. Adversaries exploit it to execute malicious scripts, bypassing security measures. The detection rule identifies suspicious network activity by MsXsl.exe, focusing on connections to non-local IPs, which may indicate unauthorized data exfiltration or command-and-control communication.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is msxsl.exe and the event type is "start" to ensure the alert is valid.
+- Check the destination IP address in the alert to determine if it falls outside the specified non-local IP ranges, indicating a potential external connection.
+- Investigate the process entity ID to trace the parent process and identify how msxsl.exe was executed, which may provide insight into the initial vector of execution.
+- Use Osquery to gather additional context on the msxsl.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'msxsl.exe';` to retrieve details like process path, command line arguments, and parent process ID.
+- Examine the command line arguments used with msxsl.exe to identify any suspicious or unexpected scripts or files being processed.
+- Correlate the network activity with other logs to identify any additional suspicious connections or data transfers involving the same destination IP.
+- Review recent system changes or user activity logs to identify any anomalies or unauthorized actions that coincide with the msxsl.exe execution.
+- Check for any other alerts or indicators of compromise on the host that may suggest a broader attack or compromise.
+- Analyze historical data to determine if msxsl.exe has been used previously on the host and if similar network connections were made.
+- Consult threat intelligence sources to see if the destination IP or any related indicators are associated with known malicious activity or threat actors.
+
+### False positive analysis
+
+- Legitimate use of MsXsl.exe by IT administrators or software developers for XML data transformation tasks may trigger the rule. Users can handle this by creating exceptions for known and verified internal IP addresses or specific user accounts that regularly perform these tasks.
+- Automated scripts or applications that utilize MsXsl.exe for legitimate data processing or integration purposes might be flagged. To manage this, users can whitelist specific processes or applications that are known to use MsXsl.exe in a non-malicious manner.
+- Network monitoring tools or security software that leverage MsXsl.exe for legitimate network diagnostics or reporting could cause false positives. Users should identify these tools and exclude their network activities from the rule.
+- In environments where MsXsl.exe is part of a standard software deployment or configuration management process, its network activity might be benign. Users can exclude these processes by verifying the source and destination of the network connections and ensuring they align with expected operational patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify any additional compromised systems by reviewing logs and network traffic for similar suspicious activity involving msxsl.exe.
+- Terminate any malicious processes associated with msxsl.exe and remove any unauthorized scripts or files from the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution and network connection data, focusing on msxsl.exe and other potential living-off-the-land binaries (LOLBins).
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar tactics and techniques.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are hardened.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on the risks associated with executing unknown scripts and the importance of reporting suspicious activity.
+- Monitor for any recurrence of the activity and adjust security measures as necessary to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
index 6cdf87d08fc..b99029c8ced 100644
--- a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
+++ b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,52 @@ sequence by host.id, user.id with maxspan=3m
               "?:\\Windows\\SysWOW64\\WerFault.exe")
  ] by process.parent.Ext.real.pid
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Parent Process PID Spoofing
+
+Parent Process ID (PPID) spoofing involves manipulating the PPID of a process to mislead security tools and analysts about the true origin of a process. Adversaries exploit this to evade detection and escalate privileges. The detection rule identifies suspicious processes by monitoring for mismatches between expected and actual PPIDs, focusing on processes with non-system integrity levels and unverified signatures, thus highlighting potential spoofing activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and parent process involved, focusing on `process.pid` and `process.parent.Ext.real.pid` fields.
+- Verify the integrity level of the process using the `process.Ext.token.integrity_level_name` field to determine if it is non-system, which may indicate suspicious activity.
+- Check the `process.pe.original_file_name` and `process.executable` fields to identify if the process is a known application or if it is running from an unusual location.
+- Investigate the code signature status using the `process.code_signature.exists` and `process.code_signature.status` fields to determine if the executable is unsigned or has a bad digest.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list processes with their parent process IDs and names:
+  ```sql
+  SELECT pid, name, parent, path FROM processes WHERE pid = <triggered_process_pid>;
+  ```
+- Cross-reference the parent process ID (`process.parent.Ext.real.pid`) with known legitimate parent processes to identify potential anomalies.
+- Examine the process creation time and compare it with the parent process's start time to identify any discrepancies that might suggest spoofing.
+- Investigate the user context (`user.id`) under which the process is running to determine if it aligns with expected behavior for that user.
+- Review historical data for the host (`host.id`) to identify any patterns or previous instances of similar suspicious activity.
+- Correlate the findings with other security events or logs from the same timeframe to build a comprehensive picture of the potential threat.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate software updates or installations temporarily alter the parent process ID, such as during system updates or software patching. These activities can mimic the behavior of PPID spoofing but are benign.
+- Certain administrative tools or scripts that automate tasks might also trigger the rule if they launch processes with altered PPIDs as part of their normal operation.
+- Users can manage these false positives by creating exceptions for specific processes or directories known to be safe, such as trusted software update paths or administrative scripts.
+- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempted, maintaining a balance between security and operational efficiency.
+- Consider implementing additional context checks, such as verifying the digital signature of the process or cross-referencing with known safe hash values, to further reduce false positives while maintaining robust detection capabilities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Use endpoint detection and response (EDR) tools to gather detailed information about the suspicious process, including its parent process and any child processes it may have spawned.
+- Terminate the malicious process and any associated processes that are identified as part of the attack chain.
+- Conduct a thorough investigation to determine the initial access vector and identify any other systems that may be compromised.
+- Review and analyze security logs to trace the origin of the spoofed process and understand the scope of the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Implement or enhance logging policies to ensure comprehensive monitoring of process creation events and parent-child process relationships.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security tools to improve detection capabilities for similar tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan to ensure no remnants of the attack remain.
+- Harden the system by implementing least privilege access controls, enabling application whitelisting, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
index e58222e18b6..1d06b158032 100644
--- a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
+++ b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,50 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\*\\LocalAccountTokenFilterPolicy"
   ) and registry.data.strings : ("1", "0x00000001")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Local Account TokenFilter Policy Disabled
+
+The Local Account TokenFilter Policy controls how local administrator accounts are treated during remote connections on Windows systems. When enabled, it grants full administrative privileges, potentially bypassing User Account Control (UAC). Adversaries exploit this by modifying the registry to escalate privileges remotely. The detection rule monitors registry changes to identify unauthorized modifications, signaling potential abuse of administrative access.
+
+### Possible investigation steps
+
+- Verify the alert by checking the registry path and value to confirm if the LocalAccountTokenFilterPolicy has been modified. Use the query fields `registry.path` and `registry.data.strings` to ensure the change is unauthorized.
+- Review the event logs around the time of the registry change to identify any associated user accounts or processes that may have initiated the modification.
+- Investigate the source of the remote connection by examining network logs to identify any unusual or unauthorized access attempts from external IP addresses.
+- Check for any recent changes in user account privileges, especially for local administrator accounts, to determine if there have been unauthorized privilege escalations.
+- Use Osquery to gather more information about the system state and user activities. For example, run the following Osquery command to check for recent registry changes: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\%\\\\LocalAccountTokenFilterPolicy';`
+- Analyze the system's security logs for any signs of suspicious activity or patterns that coincide with the registry modification, such as failed login attempts or unusual process executions.
+- Correlate the alert with other security events or alerts in the same timeframe to identify potential indicators of a broader attack or compromise.
+- Review the system's patch and update history to ensure that all security patches have been applied, as unpatched systems may be more vulnerable to exploitation.
+- Investigate any recent software installations or updates that may have inadvertently or maliciously altered the registry settings.
+- Consult threat intelligence sources to determine if there are any known exploits or attack campaigns targeting the LocalAccountTokenFilterPolicy, which could provide additional context for the alert.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts may modify the LocalAccountTokenFilterPolicy registry setting as part of routine system management or configuration tasks, leading to false positives.
+- System administrators might intentionally enable this policy to facilitate remote management tasks, especially in environments where UAC prompts are disruptive to workflow.
+- Security software or compliance tools could alter this registry setting during audits or system checks, triggering the detection rule.
+- To manage these false positives, users can create exceptions for known administrative tools or scripts by excluding specific processes or user accounts from the detection rule.
+- Regularly review and update the list of exceptions to ensure that only trusted activities are excluded, maintaining a balance between security and operational efficiency.
+- Implement logging and alerting mechanisms to monitor the frequency and context of these registry changes, helping to distinguish between benign and potentially malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the registry change by checking the LocalAccountTokenFilterPolicy value and confirm if it was set to 1 without authorization.
+- Conduct a thorough investigation to identify any unauthorized users or processes that may have modified the registry setting.
+- Review system and security logs to trace the origin of the change and identify any other suspicious activities or related events.
+- Restore the registry setting to its default state by removing the LocalAccountTokenFilterPolicy entry or setting it to 0 if necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to monitor registry changes and remote access attempts, ensuring that all critical changes are logged and reviewed regularly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
+- Apply security patches and updates to the affected system and ensure that all systems are configured with the principle of least privilege to minimize potential attack vectors.
+- Conduct a post-incident review to assess the effectiveness of the response and update security policies and procedures to prevent recurrence, including user training on security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_posh_obfuscation.toml b/rules/windows/defense_evasion_posh_obfuscation.toml
index a526da2b50a..4c208408a9c 100644
--- a/rules/windows/defense_evasion_posh_obfuscation.toml
+++ b/rules/windows/defense_evasion_posh_obfuscation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/03"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,49 @@ event.category:process and host.os.type:windows and
     ("rahc" or "ekovin" or "gnirts" or "ecnereferpesobrev" or "ecalper" or "cepsmoc" or "dillehs")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential PowerShell Obfuscated Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating scripts to evade security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts that attempt to bypass security defenses.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific obfuscation pattern triggered the detection, focusing on the `powershell.file.script_block_text` field.
+- Examine the full script block text associated with the alert to identify any additional obfuscation techniques or suspicious commands not covered by the detection rule.
+- Check the `event.category` and `host.os.type` fields to confirm the context of the alert, ensuring it pertains to a Windows process execution.
+- Investigate the process tree to identify the parent process of the PowerShell script execution, which may provide insights into how the script was launched.
+- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND pid = <PID>;` to retrieve details about the PowerShell process, including its command line arguments and parent process.
+- Analyze the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised.
+- Review recent login events and user activity logs for the account in question to identify any anomalies or unauthorized access attempts.
+- Check for any network connections initiated by the PowerShell process to external IP addresses, which could indicate data exfiltration or command-and-control communication.
+- Search for any file modifications or new file creations on the host around the time of the alert to identify potential payloads or artifacts left by the script.
+- Correlate the alert with other security events or alerts from the same host or user account to identify patterns or a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts: PowerShell scripts used by IT administrators for legitimate purposes may contain obfuscation techniques to protect sensitive information or to streamline complex operations. Users should review these scripts to ensure they are not flagged as malicious.
+- Automated deployment tools: Some deployment or configuration management tools may use obfuscation to protect proprietary code or to ensure compatibility across different environments. Users can create exceptions for these tools if they are verified as safe.
+- Security software: Certain security solutions may use obfuscation in their scripts to prevent tampering or reverse engineering. Users should verify the source and purpose of these scripts before excluding them.
+- Development and testing environments: Developers may use obfuscation techniques during the development or testing phases to simulate real-world scenarios. Users should ensure these scripts are confined to controlled environments and are not mistakenly flagged in production.
+- To manage false positives, users can create exceptions for known safe scripts by whitelisting specific script signatures or paths. Regularly updating the list of exceptions based on verified activities can help maintain a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
+- Conduct a thorough investigation of the PowerShell script to determine the extent of obfuscation and potential malicious intent.
+- Utilize endpoint detection and response (EDR) tools to analyze the behavior of the script and identify any additional indicators of compromise (IOCs).
+- Remove or quarantine any identified malicious scripts or files from the system.
+- Review and update PowerShell execution policies to restrict the execution of unauthorized scripts.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging for PowerShell activities, including script block logging and module logging, to improve future detection capabilities.
+- Integrate threat intelligence feeds to correlate detected patterns with known threat actors and techniques.
+- Restore the system from a known good backup to ensure the removal of any persistent threats.
+- Apply system hardening measures, such as disabling unnecessary PowerShell features and enforcing the use of AMSI, to reduce the risk of future obfuscation attempts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
index 01bf525400c..9f8a77bcbdf 100644
--- a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
+++ b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/31"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,51 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.pe.original_file_name == "msdt.exe" and not process.executable : ("?:\\Windows\\system32\\msdt.exe", "?:\\Windows\\SysWOW64\\msdt.exe"))
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Microsoft Diagnostics Wizard Execution
+
+The Microsoft Diagnostics Troubleshooting Wizard (MSDT) is a legitimate tool used for diagnosing and resolving issues within Windows environments. However, adversaries can exploit MSDT to execute malicious commands by manipulating its process arguments. This detection rule identifies such abuse by monitoring for unusual execution patterns, such as atypical file paths, unexpected parent processes, and altered executable names, which may indicate an attempt to proxy malicious activities through MSDT.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious MSDT execution, focusing on the `process.name`, `process.args`, and `process.parent.name` fields to understand the context of the execution.
+- Examine the `process.args` field for any unusual or unexpected arguments, such as "IT_RebrowseForFile=*", "ms-msdt:/id", or "*FromBase64*", which may indicate malicious intent.
+- Check the `process.parent.name` field to identify the parent process that initiated the MSDT execution. Look for unusual parent processes that are not typically associated with MSDT, such as `cmd.exe`, `powershell.exe`, or `rundll32.exe`.
+- Investigate the `process.executable` path to ensure it matches the expected locations for MSDT, such as "?:\\\\Windows\\\\system32\\\\msdt.exe" or "?:\\\\Windows\\\\SysWOW64\\\\msdt.exe". Any deviation might suggest tampering or misuse.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with the name "msdt.exe" and their parent processes:
+  ```sql
+  SELECT pid, name, path, parent, cmdline FROM processes WHERE name = 'msdt.exe';
+  ```
+- Analyze the `process.pe.original_file_name` field to verify that the executable is indeed "msdt.exe". If the original file name does not match, it could indicate a masquerading attempt.
+- Correlate the suspicious MSDT execution with other logs or alerts from the same host to identify any related malicious activities or patterns.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Check for any recent file modifications or creations in directories specified in the `process.args`, such as "?:\\\\Users\\\\Public\\\\*" or "?:\\\\Windows\\\\Temp\\\\*", which could indicate payload delivery or staging.
+- Review historical data for similar MSDT execution patterns on the host to determine if this is an isolated incident or part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate troubleshooting activities: Users or IT administrators may legitimately use MSDT for diagnosing system issues, which can trigger the rule. To manage this, consider creating exceptions for known IT maintenance periods or specific user accounts frequently involved in troubleshooting.
+- Automated system diagnostics: Some automated scripts or system management tools might invoke MSDT as part of routine checks. Identify these tools and exclude their execution patterns from the rule to prevent unnecessary alerts.
+- Custom diagnostic tools: Organizations may develop custom diagnostic tools that leverage MSDT, leading to false positives. Review and whitelist these tools by their specific process arguments or parent processes.
+- Software updates or installations: Certain software installations or updates might use MSDT for compatibility checks. Monitor and exclude these processes by correlating them with known update schedules or software deployment activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation of the process tree to identify any additional malicious processes or scripts that may have been executed alongside MSDT.
+- Review the system's event logs and security logs to gather more context on the suspicious MSDT execution, including any associated user accounts and network connections.
+- Terminate any malicious processes identified during the investigation and remove any associated files or scripts from the system.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if sensitive data may have been accessed.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that the system's antivirus and endpoint protection software are up to date.
+- Implement enhanced logging policies to capture detailed process execution data and network activity, which can aid in future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate suspicious activities across the network.
+- Conduct a post-incident review to identify any gaps in security controls and update the organization's incident response plan accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and features, to reduce the attack surface and prevent similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
index e42b52ac964..e6f89915cf7 100644
--- a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
+++ b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,50 @@ registry where host.os.type == "windows" and event.type == "change" and
   (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 DNS Global Query Block List Modified or Disabled
+
+The DNS Global Query Block List (GQBL) is a security feature that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling exploitation for privilege escalation. The detection rule identifies such changes by monitoring registry modifications, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry value that triggered the alert, focusing on `registry.value` and `registry.data.strings` fields.
+- Verify the timestamp of the registry change event to determine when the modification occurred.
+- Identify the user account associated with the registry change event to assess if the account has elevated privileges, such as DNSAdmins.
+- Check the host's recent login history to see if there were any unusual or unauthorized access attempts around the time of the registry modification.
+- Use Osquery to list all current registry settings related to the DNS Global Query Block List on the affected host. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\CurrentControlSet\\\\Services\\\\DNS\\\\Parameters\\\\%';`
+- Investigate any recent changes to user group memberships, especially those related to DNSAdmins, to identify potential privilege escalation.
+- Examine the system's event logs for any other suspicious activities or errors that coincide with the registry change event.
+- Cross-reference the affected host with other security alerts or incidents to determine if it is part of a broader attack pattern.
+- Analyze network traffic logs for any unusual DNS queries or connections from the affected host, particularly those involving WPAD.
+- Consult threat intelligence sources to check for any known campaigns or adversaries that exploit changes to the DNS Global Query Block List.
+
+### False positive analysis
+
+- Changes to the DNS Global Query Block List may occur during legitimate administrative tasks, such as network configuration updates or security policy adjustments, leading to false positives.
+- Organizations using custom DNS configurations might intentionally modify the GQBL to accommodate specific network requirements, which could trigger the detection rule.
+- Security software or network management tools that automatically adjust DNS settings for optimization or compliance purposes might inadvertently alter the GQBL, resulting in false alerts.
+- To manage these false positives, users can create exceptions for known and approved administrative activities by documenting and excluding specific registry changes associated with these tasks.
+- Implementing a whitelist of trusted applications or processes that are allowed to modify the GQBL can help reduce unnecessary alerts while maintaining security oversight.
+- Regularly reviewing and updating the list of exceptions based on changes in network policies or configurations can ensure that only non-threatening behaviors are excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Verify the current state of the DNS Global Query Block List by checking the registry settings to confirm unauthorized changes.
+- Conduct a thorough investigation to identify any unauthorized users or processes that modified the GQBL settings, focusing on accounts with elevated privileges like DNSAdmins.
+- Review system and security logs to trace the origin of the changes and identify any potential indicators of compromise or related suspicious activities.
+- Restore the DNS Global Query Block List to its default settings, ensuring that entries like WPAD are included to prevent spoofing attacks.
+- Apply patches and updates to the operating system and DNS services to mitigate known vulnerabilities that could be exploited.
+- Implement enhanced logging policies to capture detailed registry changes and monitor for any future unauthorized modifications.
+- Integrate security solutions such as SIEM to correlate events and provide real-time alerts for similar incidents.
+- Conduct a security audit of privileged accounts and enforce the principle of least privilege to minimize the risk of future exploitation.
+- Educate and train IT staff on recognizing and responding to DNS-related threats, leveraging MITRE ATT&CK framework for threat context and defense strategies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_root_dir_ads_creation.toml b/rules/windows/defense_evasion_root_dir_ads_creation.toml
index 3da978e81f0..3f567c11007 100644
--- a/rules/windows/defense_evasion_root_dir_ads_creation.toml
+++ b/rules/windows/defense_evasion_root_dir_ads_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,49 @@ any where host.os.type == "windows" and event.category in ("file", "process") an
     (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Alternate Data Stream Creation/Execution at Volume Root Directory
+
+Alternate Data Streams (ADS) in Windows allow files to contain multiple streams of data, which can be used to hide information. Adversaries exploit ADS at the volume root to conceal malicious tools, as these streams are not visible through standard file utilities. The detection rule identifies suspicious ADS activity by monitoring file creation and process execution patterns at the root directory, flagging potential attempts to evade defenses.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path or process executable that triggered the alert, focusing on the `file.path` and `process.executable` fields.
+- Verify the legitimacy of the file or process by checking its digital signature and comparing it against known good software lists.
+- Use Osquery to list all alternate data streams on the system with a query like: `SELECT path, name FROM file WHERE path LIKE 'C:\\\\%' AND name LIKE '%:%';` to identify any suspicious streams.
+- Investigate the parent process of the suspicious executable using the `process.parent` field to determine if it was spawned by a legitimate application or a known malicious process.
+- Check the file creation time and compare it with recent user activity logs to identify any correlation with user actions or scheduled tasks.
+- Examine the file or process hash against threat intelligence databases to see if it matches known malware signatures.
+- Review recent system logs for any other unusual activities around the time of the alert, such as unexpected network connections or privilege escalations.
+- Analyze the user account associated with the process or file creation to determine if it has been compromised or is exhibiting unusual behavior.
+- Investigate the system for any other indicators of compromise, such as unauthorized registry changes or new services, that might suggest a broader attack.
+- Consult with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather additional context and corroborate findings.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create Alternate Data Streams at the volume root directory as part of their normal operations, which can trigger false positives. Users can handle these by identifying the specific software responsible and creating exceptions for these known processes or file paths.
+- System maintenance tools or backup software might use ADS for storing metadata or additional information, leading to false positives. To manage this, users should monitor and document regular maintenance activities and exclude these from the detection rule.
+- Some antivirus or security tools may utilize ADS for storing signatures or logs, which could be misinterpreted as malicious activity. Users should verify the source of the ADS and whitelist these tools if they are confirmed to be legitimate.
+- Developers or IT administrators might use ADS for testing or configuration purposes, which can be mistaken for suspicious activity. Users should ensure that these activities are documented and create exceptions for known development or administrative tasks.
+- Certain file system operations or scripts executed by system administrators might inadvertently create ADS, resulting in false positives. Users should review these operations and exclude them from monitoring if they are part of routine administrative tasks.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Use forensic tools to capture a memory dump and collect relevant logs for further analysis of the suspicious ADS activity.
+- Identify and terminate any malicious processes associated with the ADS by analyzing process execution patterns and correlating with known threat indicators.
+- Remove the identified ADS and any associated malicious files from the system to eliminate the immediate threat.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to ensure no other threats are present.
+- Review and enhance logging policies to ensure comprehensive monitoring of file and process activities, particularly at the volume root directory.
+- Implement additional security measures such as application whitelisting and endpoint detection and response (EDR) solutions to detect and prevent future ADS exploitation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign.
+- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied before reconnecting to the network.
+- Educate users on the risks associated with ADS and provide training on recognizing and reporting suspicious activities to enhance overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sc_sdset.toml b/rules/windows/defense_evasion_sc_sdset.toml
index c5be261625f..19e99d6c170 100644
--- a/rules/windows/defense_evasion_sc_sdset.toml
+++ b/rules/windows/defense_evasion_sc_sdset.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,48 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "sdset" and process.args : "*D;*" and
   process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Service DACL Modification via sc.exe
+
+Service Control Manager (SCM) in Windows manages service configurations, including their Discretionary Access Control Lists (DACLs). Adversaries may exploit `sc.exe` to alter DACLs, restricting access to services, making them unmanageable or hidden. The detection rule identifies such modifications by monitoring `sc.exe` executions with specific arguments indicative of DACL changes, signaling potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `sc.exe` execution with the `sdset` argument, which indicates a potential DACL modification attempt.
+- Examine the `process.args` field to identify the specific DACL string used, focusing on patterns like `*D;*` and permissions such as `*;IU*`, `*;SU*`, `*;BA*`, `*;SY*`, and `*;WD*` to understand the intended access changes.
+- Check the `process.name` and `process.pe.original_file_name` fields to ensure the process is indeed `sc.exe` and not a masquerading executable.
+- Investigate the parent process of `sc.exe` to determine if it was launched by a legitimate application or a suspicious process.
+- Correlate the event with user activity by examining the user context under which `sc.exe` was executed to identify potential unauthorized access.
+- Use Osquery to list all services and their current DACLs to identify any discrepancies or unauthorized changes. Example query: `SELECT name, service_type, start_type, status, path, service_dacl FROM services WHERE path LIKE '%sc.exe%';`
+- Review recent system logs and security events around the time of the alert to identify any related activities or anomalies.
+- Investigate any network connections or file modifications made by `sc.exe` during the time of the alert to uncover potential lateral movement or data exfiltration attempts.
+- Check for any other alerts or indicators of compromise on the host that may suggest a broader attack campaign.
+- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the potential security incident.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use `sc.exe` to modify service DACLs for valid reasons, such as configuring service permissions during system setup or maintenance. These actions can trigger the detection rule but are not malicious.
+- Automated scripts and software: Some enterprise management tools or scripts might use `sc.exe` to adjust service permissions as part of their normal operation, leading to false positives.
+- Testing environments: In testing or development environments, developers might frequently modify service DACLs to test application behavior, which can be mistaken for suspicious activity.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that regularly perform these actions. This can be done by excluding certain user accounts or process hashes from the detection rule, ensuring that only unexpected or unauthorized modifications trigger alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
+- Review the security logs to identify the source and scope of the DACL modification, focusing on the user account and process that executed `sc.exe`.
+- Verify the integrity of the service's DACLs and restore them to their default or intended state using backup configurations or system baselines.
+- Conduct a thorough investigation to determine if any other services or system components have been similarly modified or compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team if unauthorized access or malicious intent is confirmed.
+- Implement enhanced logging policies to capture detailed information on service configuration changes, including command-line arguments and user context.
+- Integrate with a Security Information and Event Management (SIEM) system to correlate events and detect similar patterns of behavior across the network.
+- Apply security patches and updates to the operating system and critical applications to mitigate known vulnerabilities.
+- Educate users and administrators on the risks associated with improper DACL configurations and the importance of maintaining secure service settings.
+- Consider deploying endpoint detection and response (EDR) solutions to monitor and alert on suspicious activities related to service management and DACL modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sccm_scnotification_dll.toml b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
index 8abfbc3726a..8aa0bda3a9d 100644
--- a/rules/windows/defense_evasion_sccm_scnotification_dll.toml
+++ b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,52 @@ query = '''
 library where host.os.type == "windows" and process.name : "SCNotification.exe" and
   (dll.Ext.relative_file_creation_time < 86400 or dll.Ext.relative_file_name_modify_time <= 500) and dll.code_signature.status != "trusted"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Windows Session Hijacking via CcmExec
+
+CcmExec, part of Microsoft's System Center Configuration Manager, manages client operations. Adversaries may exploit it by loading malicious DLLs into processes like SCNotification.exe to hijack user sessions. The detection rule identifies suspicious DLL activity by checking for recent file modifications and untrusted signatures, signaling potential session hijacking attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is 'SCNotification.exe' and verify the DLL involved has an untrusted code signature.
+- Check the 'dll.Ext.relative_file_creation_time' and 'dll.Ext.relative_file_name_modify_time' fields to determine the recency of the DLL file's creation or modification, indicating potential tampering.
+- Investigate the origin of the untrusted DLL by examining its file path and comparing it against known legitimate paths for SCNotification.exe dependencies.
+- Use Osquery to list all DLLs loaded by SCNotification.exe to identify any other suspicious or untrusted modules:
+  ```sql
+  SELECT path, pid, name FROM processes JOIN process_open_sockets USING (pid) WHERE name = 'SCNotification.exe';
+  ```
+- Cross-reference the untrusted DLL's hash against threat intelligence databases to check for known malicious signatures.
+- Analyze the parent process of SCNotification.exe to determine if it was spawned by a legitimate process or if there are signs of compromise.
+- Review recent system logs and security events around the time of the DLL's creation or modification for any anomalies or unauthorized access attempts.
+- Investigate user accounts active on the system at the time of the alert to identify any unauthorized or suspicious sessions.
+- Examine network connections established by SCNotification.exe to detect any unusual outbound traffic that could indicate data exfiltration or command-and-control communication.
+- Correlate this alert with other security events or alerts in the environment to identify potential patterns or coordinated attack activities.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve DLLs with recent file modifications or untrusted signatures. Users should verify the source of the update and consider excluding these specific DLLs if they are confirmed to be safe.
+- Custom or in-house applications that are not signed by a trusted certificate authority might be flagged. Users can create exceptions for these applications by adding their signatures to a trusted list after confirming their legitimacy.
+- Security or system management tools that frequently update their components might cause false positives. Users should monitor these tools and exclude their DLLs from the rule if they are verified as non-malicious.
+- Development environments where DLLs are frequently compiled and modified can also trigger the rule. Developers should ensure that their development directories are excluded from monitoring to prevent unnecessary alerts.
+- In environments with strict security policies, some legitimate administrative actions might be flagged. Users should document these actions and adjust the rule to exclude known administrative processes that are part of regular operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the untrusted DLL and any other potentially malicious files or processes on the system.
+- Review recent user activity and system logs to determine if any unauthorized access or actions have occurred.
+- Remove the malicious DLL and any associated files from the system, ensuring that all traces of the threat are eliminated.
+- Restore the system from a known good backup if available, ensuring that the backup is free from any compromise.
+- Update all system and application software to the latest versions to patch any vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed information on DLL loads and process execution for future investigations.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to improve detection and response capabilities.
+- Escalate the incident to the security team or relevant authorities if the investigation reveals a broader threat or compliance implications.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and stricter access controls, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
index 7d5d97ca9d5..d913233cad9 100644
--- a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
+++ b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,50 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt"
   ) and registry.data.strings : ("1", "0x00000001")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Scheduled Tasks AT Command Enabled
+
+The AT command, a legacy tool in Windows, schedules tasks to run at specified times. Despite its deprecation in newer Windows versions, it remains for compatibility, posing a security risk. Attackers exploit this by enabling it via registry changes to maintain persistence or move laterally. The detection rule monitors specific registry paths for changes, identifying when the AT command is enabled, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path involved matches one of the specified paths: `HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt`, `\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt`, or `MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt`.
+- Verify the registry data value change to ensure it was set to "1" or "0x00000001", indicating the AT command was enabled.
+- Check the event logs for the specific host to identify any other registry changes or suspicious activities around the same time as the alert.
+- Investigate the user account associated with the registry change event to determine if it is a legitimate user or potentially compromised.
+- Use Osquery to list all scheduled tasks on the host to identify any unusual or unauthorized tasks. Example query: `SELECT * FROM scheduled_tasks WHERE hidden = 0;`
+- Examine the system's security logs for any recent login attempts or anomalies that could indicate unauthorized access.
+- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
+- Check for any recent software installations or updates that might have inadvertently enabled the AT command.
+- Investigate network logs for any unusual outbound connections from the host that could suggest lateral movement or data exfiltration.
+- Review the host's patch and update status to ensure it is up-to-date, as attackers often exploit outdated systems.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts may modify the registry to enable the AT command for backward compatibility or specific operational needs, leading to false positives.
+- System administrators might enable the AT command temporarily for testing or maintenance purposes, which could trigger the detection rule.
+- Some legacy applications may require the AT command to function correctly, resulting in registry changes that are benign but flagged by the rule.
+- To manage these false positives, users can create exceptions for known and trusted administrative activities by excluding specific user accounts or processes from the detection rule.
+- Implementing a whitelist of approved applications or scripts that are allowed to modify the registry path can help reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the balance between security and operational needs.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Verify the registry change by checking the specified registry path to confirm if the AT command has been enabled.
+- Conduct a thorough investigation to identify any unauthorized scheduled tasks created using the AT command and disable or remove them.
+- Review system logs and security events to identify any suspicious activities or patterns that coincide with the registry change.
+- Restore the registry setting to its original state by disabling the AT command if it was enabled without authorization.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to monitor registry changes and scheduled task creations, ensuring that future unauthorized changes are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Apply system hardening measures, such as disabling legacy tools like the AT command if not required for business operations, to reduce the attack surface.
+- Educate users and administrators on the risks associated with legacy tools and the importance of maintaining updated security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_script_via_html_app.toml b/rules/windows/defense_evasion_script_via_html_app.toml
index 12b49fd1160..b31daa2c7d0 100644
--- a/rules/windows/defense_evasion_script_via_html_app.toml
+++ b/rules/windows/defense_evasion_script_via_html_app.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,52 @@ process where host.os.type == "windows" and event.type == "start" and
       process.args : ("?:\\Users\\*\\Temp\\7z*", "?:\\Users\\*\\Temp\\Rar$*", "?:\\Users\\*\\Temp\\Temp?_*", "?:\\Users\\*\\Temp\\BNZ.*"))
    )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Script Execution via Microsoft HTML Application
+
+Microsoft HTML Applications (HTA) allow HTML code to run as trusted applications, leveraging Windows utilities like `rundll32.exe` and `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns and unusual command-line arguments, flagging potential misuse of these utilities for malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (`rundll32.exe` or `mshta.exe`) and command-line arguments that triggered the detection.
+- Examine the parent process of the suspicious execution to determine if it is a known legitimate application or an unexpected source, using the `process.parent.executable` field.
+- Check the command-line arguments for any known malicious patterns, such as `*script*eval(*`, `*mshta*http*`, or `*StrReverse*`, which may indicate obfuscation or remote script execution.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Use Osquery to gather additional context about the process execution. For example, run the following query to list all processes executed by the same user within a short time frame:
+  ```sql
+  SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <suspicious_pid>);
+  ```
+- Analyze network connections made by the suspicious process to identify any unusual or unauthorized external communications.
+- Check for any recent downloads or file modifications in the user's `Downloads` or `Temp` directories, especially `.hta` files, which may indicate the source of the script.
+- Review system logs for any other suspicious activities or errors around the time of the alert to identify potential lateral movement or additional compromise.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack campaign.
+- Consult threat intelligence sources to see if the observed patterns or indicators match known attack techniques or threat actor behaviors.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they use `rundll32.exe` or `mshta.exe` with command-line arguments that resemble those used in malicious scripts. Users can handle these by creating exceptions for known software paths or processes.
+- Some enterprise applications, like Citrix or Microsoft Office, may use these utilities in a manner that appears suspicious but is actually benign. Users should exclude these applications by specifying their executable paths in the exception list.
+- Automated scripts or administrative tools that leverage `mshta.exe` for legitimate purposes, such as system configuration or maintenance tasks, might be flagged. Users can manage these by identifying and excluding specific command-line patterns or parent processes associated with these tasks.
+- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users should maintain a list of trusted download locations or file hashes to prevent false positives.
+- Temporary files created during legitimate software extraction or installation processes, especially from archives, may match the rule's criteria. Users can exclude specific temporary directories or file patterns commonly used by trusted applications.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the process execution logs to confirm the presence of malicious activity, focusing on the command-line arguments and parent processes.
+- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
+- Remove any malicious scripts or files identified on the system, ensuring to check common directories such as Downloads and Temp folders.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Update and patch all software and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate alerts with known threat indicators.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Educate users on the risks of downloading and executing files from untrusted sources, emphasizing the importance of verifying the legitimacy of email attachments and links."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sip_provider_mod.toml b/rules/windows/defense_evasion_sip_provider_mod.toml
index 64d6862f7ec..ed4036dc3e0 100644
--- a/rules/windows/defense_evasion_sip_provider_mod.toml
+++ b/rules/windows/defense_evasion_sip_provider_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,48 @@ registry where host.os.type == "windows" and event.type == "change" and registry
   not (process.name : "msiexec.exe" and registry.data.strings : "mso.dll") and
   not (process.name : "regsvr32.exe" and registry.data.strings == "WINTRUST.DLL")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SIP Provider Modification
+
+Subject Interface Package (SIP) providers are integral to Windows' cryptographic system, ensuring file signature validation. Adversaries may alter these providers to bypass security checks or inject malicious code. The detection rule identifies suspicious registry changes linked to SIP providers, excluding benign processes, to flag potential subversion of trust controls, aligning with MITRE ATT&CK's defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to understand which registry path was modified, focusing on the `registry.path` field to identify the specific SIP provider affected.
+- Examine the `registry.value` and `registry.data.strings` fields to determine the DLL involved in the modification and assess if it is a known or suspicious file.
+- Check the `process.name` field to identify the process responsible for the registry change, and verify if it is a legitimate process or potentially malicious.
+- Investigate the process execution history using endpoint detection and response (EDR) tools to trace the origin and behavior of the process that made the registry change.
+- Use Osquery to list all current SIP providers and their associated DLLs to identify any unauthorized or unexpected entries. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Microsoft\\\\Cryptography\\\\OID\\\\EncodingType 0\\\\CryptSIPDllPutSignedDataMsg\\\\%\\\\Dll';`
+- Cross-reference the modified DLL with known good DLLs or a threat intelligence database to determine if it is associated with known malware or suspicious activity.
+- Analyze recent system logs and security events around the time of the registry change to identify any correlated suspicious activities or anomalies.
+- Investigate the user account context under which the registry change was made to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Review any recent software installations or updates that might have legitimately modified the SIP provider settings to rule out false positives.
+- Conduct a file integrity check on the modified DLL and other critical system files to ensure they have not been tampered with or replaced by malicious versions.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate software installations or updates modify SIP provider registry entries. For example, the installation of Microsoft Office or other trusted software might trigger changes in the registry paths monitored by the rule.
+- To manage these false positives, users can create exceptions for specific processes known to perform legitimate modifications. For instance, excluding `msiexec.exe` when it modifies `mso.dll` or `regsvr32.exe` when it interacts with `WINTRUST.DLL` can reduce noise from trusted activities.
+- Regularly review and update the list of excluded processes and registry paths to ensure that only benign activities are filtered out, maintaining the effectiveness of the detection rule against genuine threats.
+- Consider implementing a monitoring period to observe the behavior of newly installed or updated software, allowing for the identification of any additional benign processes that may need to be excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
+- Conduct a thorough investigation to identify the source of the registry modification, focusing on recent changes and associated processes.
+- Verify the legitimacy of the modified SIP provider DLLs by comparing them against known good versions or using a trusted source.
+- If malicious activity is confirmed, remove or replace the compromised DLLs with clean versions from a trusted backup or installation media.
+- Review and analyze system logs, including security and application logs, to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan.
+- Harden the system by implementing least privilege access controls, enabling secure boot, and regularly auditing critical system configurations to prevent future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
index 14445099941..1f5f94e20fa 100644
--- a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
+++ b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,52 @@ registry where host.os.type == "windows" and event.type == "change" and registry
   ) and
   registry.data.strings : ("4", "0x00000004")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SolarWinds Process Disabling Services via Registry
+
+SolarWinds software is integral for network management, often requiring deep system access. Adversaries may exploit this by altering registry settings to disable critical services, evading defenses. The detection rule identifies changes in registry paths linked to service start types, specifically targeting SolarWinds processes. This helps pinpoint unauthorized modifications indicative of potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the specific SolarWinds process involved by checking the `process.name` field against the list of known SolarWinds binaries.
+- Verify the registry path involved in the alert by examining the `registry.path` field to ensure it matches the critical paths associated with service start types.
+- Check the `registry.data.strings` field to confirm if the service start type was set to "4" (disabled), indicating a potential attempt to disable a service.
+- Correlate the timestamp of the registry change event with other logs to identify any concurrent suspicious activities or anomalies on the host.
+- Investigate the user account context under which the SolarWinds process was executed to determine if it aligns with expected administrative activity.
+- Use Osquery to gather additional context on the affected system. For example, run the following query to list all services with a start type of "disabled":
+  ```sql
+  SELECT name, start_type FROM services WHERE start_type = 'disabled';
+  ```
+- Examine recent process execution logs to identify any unusual or unauthorized execution of SolarWinds processes around the time of the alert.
+- Review system and security event logs for any signs of privilege escalation or lateral movement attempts that may coincide with the registry modification.
+- Investigate network logs for any unusual outbound connections from the affected host that could indicate data exfiltration or command-and-control activity.
+- Cross-reference the alert with threat intelligence sources to determine if the activity matches known attack patterns or indicators of compromise related to SolarWinds exploitation.
+
+### False positive analysis
+
+- Routine updates or maintenance activities by SolarWinds software may trigger the detection rule, as legitimate processes might modify registry settings during normal operations.
+- Scheduled tasks or automated scripts that involve SolarWinds processes could also lead to false positives if they alter service start types as part of their function.
+- To manage these false positives, users can create exceptions for known and verified SolarWinds processes that regularly perform such modifications, ensuring these are documented and approved by the security team.
+- Implementing a baseline of expected registry changes during normal operations can help differentiate between legitimate and suspicious activities, allowing for more accurate exclusions.
+- Regularly review and update the list of excluded processes and registry paths to adapt to changes in the network environment and SolarWinds software updates.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
+- Conduct a thorough investigation to confirm the unauthorized registry modification by reviewing system logs and correlating with other security events.
+- Identify and terminate any malicious processes associated with the SolarWinds binaries listed in the detection rule.
+- Restore the registry settings to their original state by referencing system backups or using known good configurations.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed registry changes and process activities, ensuring that future unauthorized modifications are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate similar events and improve detection capabilities.
+- Apply security patches and updates to the SolarWinds software and the operating system to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as restricting registry access permissions, enabling application whitelisting, and conducting regular security audits to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
index 4fbeafb570a..8bae14b6adc 100644
--- a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
+++ b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,49 @@ process where host.os.type == "windows" and event.type == "start" and process.ex
   process.name : ("rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe",
                   "cscript.exe", "wscript.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Execution from a Mounted Device
+
+In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when launched by common parent processes like Explorer. This helps in spotting potential evasion tactics where attackers use system binaries to execute malicious scripts stealthily.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and working directory, ensuring they match the criteria specified in the detection rule.
+- Check the parent process name to verify if it is "explorer.exe," as this is a common parent process for user-initiated actions.
+- Investigate the process executable path to ensure it is not a legitimate application running from a non-standard directory.
+- Use Osquery to list all mounted devices and their paths to identify any unusual or unauthorized devices. Example query: `SELECT * FROM mounts WHERE device NOT LIKE '/dev/%';`
+- Examine the process command line arguments for any suspicious or unexpected parameters that could indicate malicious activity.
+- Correlate the process start time with user login sessions to determine if the execution aligns with legitimate user activity.
+- Check for any recent file modifications or creations in the non-standard working directory to identify potential malicious files.
+- Investigate the user account associated with the process to determine if it has a history of suspicious activity or if it has been compromised.
+- Review system logs for any other suspicious activities or alerts around the same time frame to identify potential lateral movement or additional threats.
+- Analyze network connections initiated by the process to detect any communication with known malicious IP addresses or domains.
+
+### False positive analysis
+
+- Legitimate software installations or updates: Some software installations or updates may execute scripts or binaries from mounted devices or external drives. Users should verify the source and purpose of such executions and consider excluding these specific processes if they are deemed safe.
+- Portable applications: Applications that are designed to run without installation, often from USB drives or network shares, may trigger this rule. Users can create exceptions for known and trusted portable applications to prevent false alerts.
+- IT administrative tasks: System administrators might use mounted devices to run scripts for maintenance or configuration purposes. It's important to document these activities and exclude them from the rule if they are part of regular administrative tasks.
+- Backup or recovery operations: Backup software might execute scripts from external drives during backup or recovery processes. Users should identify these operations and exclude them if they are part of a legitimate backup strategy.
+- Development and testing environments: Developers might run scripts from mounted devices during testing phases. It's advisable to differentiate between production and development environments and apply exceptions where necessary to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the execution, including reviewing logs and correlating with other security events.
+- Terminate any suspicious processes identified as being executed from non-standard directories to halt potential malicious activity.
+- Analyze the parent process and any associated files or scripts for signs of tampering or malicious intent.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are removed.
+- Apply system hardening measures, such as restricting script interpreter execution from non-standard directories and enforcing application whitelisting.
+- Conduct a post-incident review to identify gaps in detection and response capabilities, and update security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
index ef418dc1c99..f289e1706d1 100644
--- a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
+++ b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,49 @@ file where host.os.type == "windows" and event.type != "deletion" and
                "cmstp.exe.log",
                "regsvr32.exe.log")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Managed Code Hosting Process
+
+Managed code hosting processes like wscript.exe, cscript.exe, and others are integral to executing scripts and managing code in Windows environments. Adversaries exploit these processes for code injection, enabling stealthy execution of malicious payloads. The detection rule identifies anomalies by monitoring specific log files associated with these processes, flagging potential misuse indicative of process injection tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify which specific managed code hosting process log file triggered the alert (e.g., wscript.exe.log, cscript.exe.log).
+- Examine the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events in the same timeframe.
+- Check the parent process of the suspicious managed code hosting process to identify if it was spawned by a legitimate or potentially malicious process.
+- Investigate the command line arguments used by the suspicious process to identify any unusual or unexpected parameters that could indicate malicious activity.
+- Analyze the user account associated with the process execution to determine if it aligns with normal user behavior or if it could be indicative of compromised credentials.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('wscript.exe', 'cscript.exe', 'mshta.exe', 'wmic.exe', 'svchost.exe', 'dllhost.exe', 'cmstp.exe', 'regsvr32.exe');`
+- Cross-reference the process hash with threat intelligence databases to check if it is associated with known malware.
+- Review network connections established by the suspicious process to identify any unusual or unauthorized external communications.
+- Check for any recent changes to the system, such as new software installations or updates, that could explain the process behavior.
+- Investigate any related alerts or logs from other security tools that might provide additional context or corroborate the suspicious activity.
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators often use scripts executed by processes like wscript.exe or cscript.exe for routine maintenance tasks, which can trigger false positives. To manage this, users can create exceptions for known scripts or script paths that are regularly used in their environment.
+- Software updates and installations: Some software installations or updates may use processes like mshta.exe or regsvr32.exe as part of their legitimate operations. Users should monitor these activities and whitelist specific update processes or installation paths that are verified as safe.
+- Automated system tasks: Windows Management Instrumentation (WMI) tasks or other automated system tasks might utilize wmic.exe or svchost.exe, leading to false alerts. Users can exclude these tasks by identifying and documenting regular system operations that are expected to use these processes.
+- Custom applications: In environments where custom applications are developed, these applications might use managed code hosting processes for legitimate purposes. Users should work with development teams to identify and exclude these applications from triggering alerts.
+- Security software: Some security tools may use these processes as part of their scanning or monitoring activities. Users should verify with their security vendors and exclude these processes if they are part of the security software's normal operation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the flagged process by reviewing the associated log files and any related system events to confirm the presence of malicious activity.
+- Utilize endpoint detection and response (EDR) tools to perform a memory analysis and identify any injected code or anomalous behavior in the process.
+- If malicious activity is confirmed, terminate the suspicious process and remove any associated malicious files or scripts from the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution data and integrate with a security information and event management (SIEM) system for real-time monitoring and alerting.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are up to date.
+- Conduct a post-incident review to identify any gaps in the current security posture and update incident response plans accordingly.
+- Educate users on recognizing and reporting suspicious activities to prevent future incidents.
+- Implement hardening measures such as application whitelisting, disabling unnecessary scripting engines, and enforcing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_scrobj_load.toml b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
index 02c9c309f06..58fb5fe069b 100644
--- a/rules/windows/defense_evasion_suspicious_scrobj_load.toml
+++ b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,49 @@ any where host.os.type == "windows" and
        "?:\\Windows\\System32\\wbem\\WMIADAP.exe",
        "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Script Object Execution
+
+The scrobj.dll is a legitimate Windows library used for executing scriptlets, often within trusted processes. Adversaries exploit this by loading scrobj.dll into atypical processes to execute malicious scripts, evading detection. The detection rule identifies such anomalies by monitoring for scrobj.dll in unexpected processes, excluding known safe executables, thus highlighting potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of scrobj.dll in an unexpected process by checking the `process.executable` field against the list of known safe executables.
+- Examine the `event.category` and `event.action` fields to determine if the alert was triggered by a library or driver load event, or a process image load event.
+- Investigate the parent process of the suspicious executable using the `process.parent.executable` field to identify potential sources of the script execution.
+- Check the `host.os.type` field to ensure the alert is relevant to a Windows environment, as the rule is specific to Windows systems.
+- Use Osquery to gather additional context on the suspicious process by running a query such as: `SELECT * FROM processes WHERE name = 'suspicious_process_name';` to retrieve details like process ID, parent process ID, and command line arguments.
+- Analyze the command line arguments of the suspicious process using the `process.command_line` field to identify any potentially malicious script or command being executed.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
+- Investigate the user account associated with the process execution using the `user.name` field to determine if the account has been compromised or is being misused.
+- Review recent changes or anomalies in the system's file system or registry that could indicate the presence of malicious scriptlets or persistence mechanisms.
+- Consult threat intelligence sources to check if the observed behavior or process is associated with known malware or attack techniques, leveraging the MITRE ATT&CK references provided in the alert.
+
+### False positive analysis
+
+- Known false positives for the Suspicious Script Object Execution rule may include legitimate administrative scripts or automation tools that load scrobj.dll for benign purposes. These can occur in environments where custom scripts are used for system management or monitoring.
+- Users can handle these false positives by identifying and documenting regular processes that load scrobj.dll as part of their normal operation. Once identified, these processes can be added to the exclusion list within the detection rule to prevent unnecessary alerts.
+- It is important to regularly review and update the exclusion list to ensure that only verified safe processes are excluded, maintaining a balance between security and operational efficiency.
+- In environments with frequent legitimate use of scriptlets, consider implementing additional monitoring or logging to differentiate between expected and unexpected script object executions, providing context for further analysis.
+- Collaboration with IT and security teams can help in understanding the typical use cases of scrobj.dll within the organization, aiding in the accurate identification of false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to confirm the presence of malicious script execution by analyzing the process tree and associated network connections.
+- Terminate any suspicious processes that have loaded scrobj.dll in an unusual manner, ensuring to capture memory dumps for further analysis.
+- Remove any identified malicious scriptlets or files from the system and perform a full antivirus and anti-malware scan.
+- Review and update security policies to ensure that only trusted processes are allowed to load scrobj.dll, leveraging application whitelisting where possible.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution and DLL loading events, ensuring logs are forwarded to a centralized logging solution for analysis.
+- Integrate threat intelligence feeds to correlate detected anomalies with known threat actor tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
+- Harden the system by disabling unnecessary scripting capabilities and enforcing the principle of least privilege to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_wmi_script.toml b/rules/windows/defense_evasion_suspicious_wmi_script.toml
index 3f1cee8f4c1..9dd9b75b4c4 100644
--- a/rules/windows/defense_evasion_suspicious_wmi_script.toml
+++ b/rules/windows/defense_evasion_suspicious_wmi_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,48 @@ sequence by process.entity_id with maxspan = 2m
 [any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and
  (?dll.name : ("jscript.dll", "vbscript.dll") or file.name : ("jscript.dll", "vbscript.dll"))]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious WMIC XSL Script Execution
+
+Windows Management Instrumentation Command-line (WMIC) is a powerful tool for managing Windows systems. Adversaries exploit WMIC to bypass security controls by executing scripts via XSL files, often loading scripting libraries like JScript or VBScript. The detection rule identifies such abuse by monitoring for unusual WMIC command patterns and the loading of specific scripting libraries, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific WMIC command that triggered the alert, focusing on the `process.args` field to identify the suspicious format pattern used.
+- Examine the `process.command_line` field to gather the full command executed, noting any deviations from typical WMIC usage patterns.
+- Check the `process.entity_id` to correlate this event with other related processes within the 2-minute window specified by the `maxspan` parameter.
+- Investigate the parent process of the WMIC execution to determine if it was initiated by a legitimate application or a potentially malicious process.
+- Analyze the `dll.name` or `file.name` fields to confirm the loading of `jscript.dll` or `vbscript.dll`, which may indicate script execution.
+- Use Osquery to list all processes that have recently loaded `jscript.dll` or `vbscript.dll` with a query like: `SELECT pid, name, path FROM processes WHERE path LIKE '%jscript.dll%' OR path LIKE '%vbscript.dll%';`
+- Cross-reference the process start time with user activity logs to determine if the execution aligns with expected user behavior or if it occurred during off-hours.
+- Investigate the network activity of the host around the time of the alert to identify any suspicious outbound connections that may indicate data exfiltration or command and control communication.
+- Review recent changes to the system's allowlist or security policies that might have permitted the execution of such scripts.
+- Check for any other alerts or indicators of compromise on the same host or associated user account to assess if this event is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use WMIC with XSL scripts for legitimate purposes, such as automating system management tasks. These activities can trigger the rule if they involve loading scripting libraries like JScript or VBScript.
+- Monitoring and management software: Some enterprise monitoring or management tools may use WMIC and scripting libraries to gather system information or perform routine checks, leading to false positives.
+- Custom scripts: Organizations may have custom scripts that utilize WMIC and XSL files for specific operational needs, which could be mistakenly flagged as suspicious.
+- To manage these false positives, users can create exceptions for known legitimate processes by adding them to an allowlist. This can be done by identifying the specific command lines or scripts that are frequently used and excluding them from the detection rule. Additionally, users should regularly review and update the allowlist to ensure it reflects current legitimate activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the execution of WMIC with suspicious XSL script patterns.
+- Review and analyze logs from the affected system and any related systems to trace the adversary's actions and identify any additional compromised systems.
+- Remove any unauthorized scripts or files identified during the investigation, particularly those involving jscript.dll or vbscript.dll.
+- Apply patches and updates to the operating system and all installed software to mitigate vulnerabilities that may have been exploited.
+- Restore the system from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from compromise.
+- Implement enhanced logging policies to capture detailed information on script execution and library loading activities, aiding future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and support.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as application whitelisting and stricter execution policies to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_timestomp_sysmon.toml b/rules/windows/defense_evasion_timestomp_sysmon.toml
index 1664fbad7f2..d0bb44cc50a 100644
--- a/rules/windows/defense_evasion_timestomp_sysmon.toml
+++ b/rules/windows/defense_evasion_timestomp_sysmon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,49 @@ file where host.os.type == "windows" and event.code : "2" and
  not file.extension : ("temp", "tmp", "~tmp", "xml", "newcfg") and not user.name : ("SYSTEM", "Local Service", "Network Service") and
  not file.name : ("LOG", "temp-index", "license.rtf", "iconcache_*.db")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File Creation Time Changed
+
+File creation timestamps are crucial for tracking file history and integrity. Adversaries may alter these timestamps, a tactic known as timestomping, to disguise malicious files as benign by aligning their timestamps with trusted files. The detection rule leverages Sysmon EventID 2 to identify such changes, excluding legitimate processes and file types, thus highlighting suspicious activities that may indicate an attempt to evade detection.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file and process involved in the creation time change, focusing on the `file.name` and `process.executable` fields.
+- Verify the legitimacy of the process by checking the `process.executable` path against known trusted applications and directories.
+- Investigate the user context under which the file creation time was changed by examining the `user.name` field to determine if it aligns with expected user behavior.
+- Cross-reference the file path and name with known benign files and directories to assess if the file is typically found in trusted locations.
+- Utilize Osquery to gather additional context about the file and process. For example, run the following query to check for recent file modifications: `SELECT * FROM file WHERE path = 'C:\\\\path\\\\to\\\\suspicious\\\\file' AND mtime > (SELECT strftime('%s', 'now') - 86400);`
+- Check for any recent changes in the file's hash value to determine if the file content has been altered, which could indicate tampering.
+- Investigate the parent process of the suspicious executable to understand the process hierarchy and identify potential process injection or masquerading.
+- Review system logs and other security events around the time of the file creation time change to identify any correlated suspicious activities or anomalies.
+- Analyze network activity from the host to detect any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
+- Consult threat intelligence sources to determine if the file or process has been associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger file creation time changes, especially for applications that frequently update, such as web browsers or productivity tools. Users can manage these by adding exceptions for known update processes or directories.
+- System maintenance tasks, like disk cleanup or system updates, might alter file timestamps. These can be handled by excluding specific system processes like cleanmgr.exe or msiexec.exe from the detection rule.
+- User-initiated file modifications, such as copying files to different directories, can also result in timestamp changes. To reduce false positives, users can exclude common user directories or specific file types that are often modified.
+- Automated backup or synchronization software may modify file timestamps to ensure data consistency. Users should consider excluding these applications or their associated directories from the rule.
+- Temporary files created by legitimate applications during normal operation might have their timestamps altered. Excluding file extensions like "temp" or "tmp" can help minimize these false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on files with altered timestamps and correlating with other suspicious activities.
+- Review Sysmon logs and other relevant logs to trace the origin of the timestomping activity and identify any associated malicious processes or files.
+- Remove or quarantine any identified malicious files and terminate any associated malicious processes.
+- Restore any altered or deleted files from known good backups to ensure data integrity and system functionality.
+- Escalate the incident to the security operations center (SOC) or incident response team if the scope of the attack is beyond initial containment efforts.
+- Implement or enhance logging policies to ensure comprehensive monitoring of file attribute changes and other critical system events.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by adversaries.
+- Educate users on recognizing and reporting suspicious activities to enhance the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
index 17af2ccdeeb..a4c2be1e51c 100644
--- a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
+++ b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -125,6 +125,50 @@ library where host.os.type == "windows" and
 	 /* DLL loaded from the process.executable current directory */
 	 endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unsigned DLL Side-Loading from a Suspicious Folder
+
+DLL side-loading involves loading a malicious DLL into a trusted process to evade detection. Adversaries exploit this by placing unsigned DLLs in directories that mimic legitimate paths. The detection rule identifies trusted processes loading recently modified, unsigned DLLs from suspicious directories, indicating potential malicious activity. This helps in identifying attempts to bypass security measures by masquerading as legitimate software.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific trusted process and the unsigned DLL involved. Pay attention to the `process.code_signature.trusted` and `dll.code_signature.status` fields to confirm the trust status of the process and the unsigned nature of the DLL.
+- Examine the `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` fields to determine how recently the DLL was created or modified, which can indicate recent malicious activity.
+- Investigate the `dll.path` to verify if it matches any of the suspicious directories listed in the detection rule. This can help confirm if the DLL is located in a directory commonly abused for side-loading attacks.
+- Use Osquery to gather additional context about the process and DLL. For example, run the following query to list all DLLs loaded by the process: `SELECT * FROM process_open_sockets WHERE pid = <process_id>;` Replace `<process_id>` with the actual process ID from the alert.
+- Check the file properties and metadata of the unsigned DLL, including its creation and modification timestamps, to identify any anomalies or inconsistencies.
+- Correlate the process and DLL activity with other logs, such as Windows Event Logs, to identify any related suspicious behavior or events around the time of the alert.
+- Investigate the parent process of the trusted process to determine if it was spawned by a legitimate application or if it shows signs of compromise.
+- Analyze network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
+- Review the system's recent changes, such as software installations or updates, that might explain the presence of the unsigned DLL in a suspicious directory.
+- Conduct a file integrity check on the system to identify any other unauthorized or unexpected changes to critical system files and directories.
+
+### False positive analysis
+
+- Legitimate software updates: Some legitimate software may update their DLLs frequently, causing them to appear as recently modified. Users can create exceptions for known software update processes to prevent false positives.
+- Development environments: Developers often compile and test DLLs in directories that might match suspicious paths. Excluding directories used for development can help reduce false alerts.
+- Custom or in-house applications: Organizations may have custom applications that load unsigned DLLs from non-standard directories. Identifying and excluding these applications can prevent unnecessary alerts.
+- Backup or recovery software: Certain backup or recovery tools might temporarily load unsigned DLLs from unusual paths. Users should verify the legitimacy of such tools and consider excluding them if they are trusted.
+- Security software: Some security tools may use unsigned DLLs for legitimate purposes, such as monitoring or scanning. Users should ensure these tools are recognized and excluded from detection rules.
+- Testing or sandbox environments: In testing environments, unsigned DLLs might be used to simulate attacks or test software. Excluding these environments from production detection rules can help avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to identify the source of the unsigned DLL and any associated malicious activity.
+- Use endpoint detection and response (EDR) tools to analyze the behavior of the trusted process and the loaded DLL.
+- Remove the malicious DLL and any other suspicious files from the system, ensuring that legitimate files are not affected.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Update antivirus and anti-malware solutions to ensure they can detect and prevent similar threats in the future.
+- Implement application whitelisting to prevent unauthorized DLLs from being loaded by trusted processes.
+- Enhance logging policies to capture detailed information about DLL loads and process execution for future investigations.
+- Integrate threat intelligence feeds to stay informed about emerging threats and adapt defenses accordingly.
+- Escalate the incident to the security operations center (SOC) or relevant team if the threat is part of a larger attack campaign, referencing MITRE ATT&CK techniques TA0005 and T1036 for context."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_dir_ads.toml b/rules/windows/defense_evasion_unusual_dir_ads.toml
index 9d0dc28418d..95f452ee05b 100644
--- a/rules/windows/defense_evasion_unusual_dir_ads.toml
+++ b/rules/windows/defense_evasion_unusual_dir_ads.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -39,6 +39,49 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.args : "?:\\*:*" and process.args_count == 1
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process Execution Path - Alternate Data Stream
+
+Alternate Data Streams (ADS) in Windows allow files to contain multiple data streams, which can be used to store metadata or additional information. Adversaries exploit ADS to conceal malicious code, making it harder to detect. The detection rule identifies processes initiated from ADS by monitoring specific execution patterns, such as unique argument structures, which are atypical for legitimate processes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a process execution from an Alternate Data Stream (ADS) by checking the `process.args` field for the pattern `?:\\\\*:*`.
+- Verify the `process.args_count` field to ensure it equals 1, indicating the process was initiated with a single argument, which is atypical and may suggest malicious intent.
+- Identify the parent process using the `process.parent.name` and `process.parent.pid` fields to understand the origin of the suspicious process execution.
+- Examine the `process.executable` field to determine the exact executable file path and verify its legitimacy by checking its digital signature and hash against known good values.
+- Use Osquery to list all processes running from ADS by executing a query such as: `SELECT pid, name, path FROM processes WHERE path LIKE '%:%';` to identify any other potentially suspicious processes.
+- Investigate the user context under which the process was executed by reviewing the `user.name` field to determine if it aligns with expected user behavior.
+- Check the `host.name` and `host.ip` fields to identify the affected system and correlate with any other alerts or logs from the same host for additional context.
+- Analyze recent file modifications on the host by querying file creation and modification times to identify any unusual changes that coincide with the process execution.
+- Review network activity associated with the process by examining logs for any unusual outbound connections or data transfers that could indicate exfiltration or command-and-control communication.
+- Cross-reference the process and host information with threat intelligence sources to determine if the behavior matches any known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate software installations or updates may use Alternate Data Streams to store metadata or additional information, leading to false positives. Users can create exceptions for known software paths or processes that frequently trigger alerts.
+- Some backup or file synchronization tools might utilize ADS to manage file versions or metadata, which can be mistaken for malicious activity. Identifying these tools and excluding their processes from monitoring can reduce false positives.
+- Certain system utilities or administrative scripts may leverage ADS for legitimate purposes, such as storing configuration data. Users should review and whitelist these utilities if they are known and trusted within their environment.
+- Developers or IT personnel might use ADS for testing or development purposes, which could trigger alerts. Establishing a policy to document and approve such activities can help in creating appropriate exceptions.
+- Security software or forensic tools might interact with ADS as part of their scanning or analysis processes. Users should verify these interactions and exclude them if they are part of routine security operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation to confirm the presence of malicious code within the Alternate Data Stream by analyzing the process execution path and associated files.
+- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) across the network.
+- If malware is confirmed, remove the malicious files and any associated ADS using trusted antivirus or anti-malware software.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution data and monitor for similar suspicious activities in the future.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of tactics, techniques, and procedures (TTPs) associated with Defense Evasion and Hide Artifacts.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and features, to reduce the attack surface and prevent future exploitation of Alternate Data Streams."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
index 0e2c84b0d56..f28cd23ae0d 100644
--- a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
+++ b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,49 @@ sequence by host.id, process.entity_id with maxspan=1m
     "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")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Network Connection via DllHost
+
+Dllhost.exe is a legitimate Windows process responsible for managing DLL-based applications. Adversaries may exploit it to execute malicious code under the guise of a trusted process, often for Command and Control (C2) activities. The detection rule identifies suspicious outbound connections by dllhost.exe, focusing on connections to non-local IP addresses, which may indicate unauthorized network activity. This helps in identifying potential misuse of system binaries for evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "dllhost.exe" and verify the process.args_count is 1, as specified in the detection rule.
+- Check the destination IP address of the outbound connection to determine if it falls outside the specified non-local IP ranges, indicating a potential external connection.
+- Correlate the process.entity_id and host.id with other logs to identify any related processes or activities on the same host around the time of the alert.
+- Use Osquery to gather additional context about the dllhost.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'dllhost.exe' AND pid = <process_id>;` to retrieve details like parent process, command line arguments, and execution path.
+- Investigate the parent process of dllhost.exe to determine if it was spawned by a legitimate application or a potentially malicious one.
+- Examine historical network activity from the same host to identify any patterns or repeated connections to suspicious IP addresses.
+- Check for any recent changes or anomalies in the system's configuration or installed software that could explain the unusual network activity.
+- Review any related security alerts or incidents involving the same host or IP address to identify potential patterns or ongoing threats.
+- Analyze the network traffic associated with the suspicious connection using packet captures or network logs to identify any data exfiltration or command and control communication.
+- Consult threat intelligence sources to determine if the destination IP address or any related indicators are associated with known malicious activity or threat actors.
+
+### False positive analysis
+
+- Legitimate software updates or cloud services may cause dllhost.exe to make outbound connections to non-local IP addresses, which can be mistaken for malicious activity.
+- Some enterprise applications may use dllhost.exe for legitimate network communications, especially in environments with custom or legacy software.
+- Users can handle these false positives by creating exceptions for known IP addresses or domains associated with trusted software updates and services.
+- Regularly review and update the list of exceptions to ensure it reflects current legitimate network activities and does not inadvertently allow malicious traffic.
+- Collaborate with IT and security teams to identify and document legitimate use cases of dllhost.exe network connections within the organization.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
+- Conduct a thorough investigation of the dllhost.exe process to determine if it is executing unauthorized or malicious code, using tools like process explorers or endpoint detection and response (EDR) solutions.
+- Analyze network traffic logs to identify any unusual outbound connections made by dllhost.exe and correlate them with known malicious IP addresses or domains.
+- Terminate any suspicious instances of dllhost.exe and remove any associated malicious files or scripts from the system.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be remediated through other means.
+- Update and patch the operating system and all installed software to mitigate vulnerabilities that could be exploited by adversaries.
+- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
+- Integrate threat intelligence feeds to automatically update detection rules with known indicators of compromise (IOCs) related to dllhost.exe misuse.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or advanced persistent threat (APT) activity.
+- Conduct a post-incident review to identify gaps in detection and response capabilities and implement hardening measures such as application whitelisting and least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
index f2dc01c3942..3c1590b0543 100644
--- a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
+++ b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,48 @@ process where host.os.type == "windows" and event.type == "start" and
   process.parent.pid == 4 and process.executable : "?*" and
   not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Child Process from a System Virtual Process
+
+In Windows environments, the System process (PID 4) is a critical component responsible for managing system-level operations. Adversaries may exploit this by injecting malicious code to spawn unauthorized child processes, evading detection. The detection rule identifies anomalies by flagging unexpected child processes of the System process, excluding known legitimate executables, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process executable and parent PID match the criteria: process.parent.pid == 4 and process.executable : "?*".
+- Cross-reference the process executable against known legitimate system processes to ensure it is not a false positive.
+- Use Osquery to gather additional context about the suspicious process. Example query: `SELECT * FROM processes WHERE pid = <suspicious_process_pid>;`
+- Investigate the command line arguments of the suspicious process to identify any unusual or malicious patterns.
+- Check the process creation time and correlate it with other system events or logs to identify any related activities.
+- Examine the parent process tree to understand the lineage and determine if there are any other suspicious processes involved.
+- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized communication.
+- Review recent changes to the system, such as software installations or updates, that might explain the presence of the process.
+- Investigate the user account context under which the process is running to determine if it aligns with expected behavior.
+- Consult threat intelligence sources to see if the process executable or related indicators have been associated with known threats.
+
+### False positive analysis
+
+- Known false positives for the Unusual Child Process from a System Virtual Process rule may include legitimate system maintenance or update processes that are not typically associated with malicious activity. These can include certain third-party security or system management tools that interact with the System process for legitimate purposes.
+- Users can handle these false positives by creating exceptions for specific executables that are verified as non-threatening. This can be done by adding these executables to the exclusion list in the detection rule, ensuring they are not flagged in future scans.
+- It is important to regularly review and update the list of excluded executables to ensure that only verified and trusted processes are excluded, maintaining a balance between security and operational efficiency.
+- Users should also consider the context of the flagged process, such as the time of execution and the associated user account, to determine if the activity aligns with expected behavior or scheduled tasks, which can help in distinguishing false positives from genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation to confirm the presence of malicious code injection by analyzing the suspicious child process and its parent process.
+- Terminate any unauthorized processes spawned by the System process (PID 4) to halt malicious activity.
+- Review and collect relevant logs, including process creation logs and security event logs, to understand the scope and impact of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
+- Implement enhanced logging policies to capture detailed process creation and termination events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities against similar threats.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for process injection.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_windows_filtering_platform.toml b/rules/windows/defense_evasion_windows_filtering_platform.toml
index a409ebe9849..3adf5226b1a 100644
--- a/rules/windows/defense_evasion_windows_filtering_platform.toml
+++ b/rules/windows/defense_evasion_windows_filtering_platform.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -97,6 +97,49 @@ sequence by winlog.computer_name with maxspan=1m
         "splunk.exe", "sysmon.exe", "sysmon64.exe", "taniumclient.exe"
     )] with runs=5
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Evasion via Windows Filtering Platform
+
+The Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for network filtering and packet processing. Adversaries may exploit WFP by creating malicious rules to block security software from sending telemetry, thus evading detection. The detection rule identifies multiple blocked network events linked to security processes, indicating potential tampering with WFP rules to impair defenses.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `winlog.computer_name` and `process.name` involved in the blocked network events.
+- Check the frequency and pattern of the blocked events to determine if they are consistent with normal operations or indicative of tampering.
+- Correlate the `process.name` with known security software to confirm if it is legitimate and expected on the system.
+- Use event logs to trace back any recent changes to the Windows Filtering Platform rules on the affected system.
+- Investigate the user accounts and processes that have modified WFP rules recently to identify any unauthorized changes.
+- Utilize Osquery to gather more information about the network configuration and WFP rules. Example query: `SELECT * FROM wfp_filters WHERE name LIKE '%<process_name>%';` to list any WFP rules associated with the suspicious process.
+- Examine the system for any signs of compromise, such as unusual processes, services, or scheduled tasks that could indicate malicious activity.
+- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns.
+- Investigate the network traffic from the affected system to determine if there are any anomalies or connections to known malicious IPs.
+- Consult threat intelligence sources to check if the identified process or behavior is associated with known evasion techniques or threat actors.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they temporarily block network traffic for security processes, leading to false positives.
+- Network congestion or misconfigurations in firewall settings can cause legitimate security software to appear as if it's being blocked, resulting in false positives.
+- Users can handle these false positives by creating exceptions for known and trusted software update processes or installation activities that are frequently flagged.
+- Regularly review and update the list of process names in the detection rule to ensure it aligns with the current security software deployed in the environment, reducing unnecessary alerts.
+- Implement a monitoring period to observe the behavior of flagged processes and determine if they consistently result in false positives, allowing for informed decisions on exclusions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
+- Conduct a thorough investigation to identify any unauthorized WFP rules and remove or correct them to restore normal security software operations.
+- Review and analyze logs from the affected system and network devices to trace the source and scope of the attack, focusing on any anomalies related to the processes listed in the detection query.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Restore the system to its operational state by reinstalling or updating endpoint security software and ensuring all security patches are applied.
+- Implement enhanced logging policies to capture detailed network and process activity, ensuring that future incidents can be detected and analyzed more effectively.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
+- Conduct a review of firewall and WFP configurations to ensure they are aligned with security best practices and do not allow unauthorized modifications.
+- Educate users and administrators on recognizing signs of potential evasion techniques and the importance of reporting suspicious activity promptly.
+- Consider implementing network segmentation and access controls to limit the potential impact of compromised systems and prevent lateral movement by adversaries."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_bash_exec.toml b/rules/windows/defense_evasion_wsl_bash_exec.toml
index 28b232f3d9d..87369355226 100644
--- a/rules/windows/defense_evasion_wsl_bash_exec.toml
+++ b/rules/windows/defense_evasion_wsl_bash_exec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,52 @@ process where host.os.type == "windows" and event.type : "start" and
   ) and 
     not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Execution via Windows Subsystem for Linux
+
+Windows Subsystem for Linux (WSL) allows users to run Linux binaries on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process executable path and command-line arguments that triggered the alert, focusing on paths like `?:\\Windows\\System32\\bash.exe` and command-line deviations from typical usage.
+- Examine the parent-child process relationship, particularly if the parent process is `wsl.exe` and the child process is not `wslhost.exe`, to understand the context of the execution.
+- Investigate the command-line arguments used with `wsl.exe`, especially if they include suspicious commands like `curl`, `cat`, or access to sensitive files such as `/etc/shadow` or `/etc/passwd`.
+- Check for any exclusions in the command-line arguments that might indicate legitimate use, such as `wsl-bootstrap`, `docker-desktop-data`, or `*.vscode-server*`.
+- Verify the parent process executable path to ensure it is not a known legitimate application like Docker, which might indicate a false positive.
+- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes related to WSL:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE '%\\\\Windows\\\\System32\\\\bash.exe%' OR path LIKE '%\\\\Users\\\\%\\\\AppData\\\\Local\\\\Packages\\\\%\\\\rootfs\\\\usr\\\\bin\\\\bash%';
+  ```
+- Analyze the network activity associated with the suspicious process to identify any unusual outbound connections or data exfiltration attempts.
+- Review the user account context under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Check the system's security logs for any related events or anomalies around the time of the alert to gather additional context.
+- Correlate the findings with other security tools and logs to determine if this activity is part of a broader attack pattern or an isolated incident.
+
+### False positive analysis
+
+- **Development Tools Usage**: Developers using WSL for legitimate purposes, such as running development environments or testing scripts, may trigger alerts. To manage this, users can create exceptions for specific user accounts or processes frequently involved in development activities.
+- **System Administration Tasks**: System administrators might use WSL for routine maintenance tasks, which could be flagged as suspicious. Excluding known administrative scripts or commands from the detection rule can help reduce false positives.
+- **Docker Integration**: Docker Desktop for Windows uses WSL 2 as its backend, which might generate alerts. Users can exclude Docker-related processes by adding exceptions for Docker executable paths or specific command-line arguments associated with Docker operations.
+- **VSCode Remote Development**: Visual Studio Code's remote development feature may utilize WSL, leading to potential false positives. Users can exclude processes or command-line arguments related to VSCode's remote server operations to mitigate this.
+- **Custom Scripts**: Organizations may have custom scripts that run via WSL for automation or integration purposes. Identifying and excluding these scripts from the detection rule can help prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the alert by reviewing the process execution details, including command-line arguments and parent-child process relationships, to confirm malicious activity.
+- Capture and preserve relevant logs and artifacts, such as WSL execution logs, system event logs, and network traffic, for further analysis and evidence collection.
+- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to monitor WSL activity, including command execution and file access, to improve detection capabilities.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to identify and respond to similar threats in the future.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan to ensure no residual threats remain.
+- Harden the system by disabling WSL if not required, or by configuring strict access controls and monitoring for WSL usage.
+- Review and update security policies and procedures to address gaps identified during the incident and to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_child_process.toml b/rules/windows/defense_evasion_wsl_child_process.toml
index eb1713f9cfb..7cbc976b497 100644
--- a/rules/windows/defense_evasion_wsl_child_process.toml
+++ b/rules/windows/defense_evasion_wsl_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -70,6 +70,50 @@ process where host.os.type == "windows" and event.type : "start" and
       )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution via Windows Subsystem for Linux
+
+Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, bridging the gap between Windows and Linux environments. Adversaries may exploit WSL to execute malicious Linux binaries, bypassing traditional Windows security measures. The detection rule identifies suspicious executions initiated by WSL processes, excluding known legitimate paths, to flag potential misuse while minimizing false positives.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process was executed and its parent process, focusing on the `process.parent.name` field to confirm it was initiated by `wsl.exe` or `wslhost.exe`.
+- Examine the `process.executable` field to identify the exact path of the executed binary and determine if it is a known legitimate application or potentially malicious.
+- Check the `event.type` field to confirm the event is a process start, ensuring the alert is relevant to execution attempts.
+- Investigate the user context under which the process was executed by reviewing the user account details associated with the process to identify any anomalies or unauthorized access.
+- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'wsl.exe' OR name = 'wslhost.exe';` to list all instances and their command-line arguments.
+- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Analyze network connections initiated by the suspicious process using network monitoring tools or logs to detect any unauthorized data exfiltration or communication with known malicious IPs.
+- Review the system's WSL configuration and installed distributions to ensure they are legitimate and have not been tampered with by running: `wsl --list --verbose` to list all installed distributions and their states.
+- Check for any recent changes to the WSL configuration files or related registry keys that could indicate tampering or unauthorized modifications.
+- Investigate the timeline of events on the host to identify any other suspicious activities or changes that coincide with the execution attempt, providing a broader context for the alert.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate software development activities where developers use WSL to compile or test code, as these processes can mimic adversarial behavior.
+- System administrators or IT professionals might use WSL for routine maintenance tasks, which could trigger the detection rule if not properly excluded.
+- Automated scripts or scheduled tasks that leverage WSL for legitimate operations can also be flagged as suspicious.
+- To manage these false positives, users can create exceptions for specific processes or paths that are known to be safe and frequently used in their environment.
+- Regularly review and update the exclusion list to ensure it reflects the current operational needs and legitimate use cases of WSL within the organization.
+- Consider implementing a logging and alerting system to monitor excluded activities, ensuring that any changes in behavior are promptly investigated.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the WSL installation and any associated processes by cross-referencing with known software inventories.
+- Conduct a thorough investigation of the executed processes to determine if they are part of a legitimate application or a potential threat.
+- Review system logs and WSL-specific logs to identify any unusual or unauthorized activities that may indicate compromise.
+- Remove any unauthorized or malicious Linux binaries identified during the investigation from the WSL environment.
+- Update antivirus and endpoint detection and response (EDR) solutions to ensure they can detect and block similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution data, especially for WSL-related activities.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities for similar threats.
+- Apply system hardening measures, such as restricting WSL usage to authorized users and regularly updating WSL components, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_filesystem.toml b/rules/windows/defense_evasion_wsl_filesystem.toml
index eb37721421f..4ba60069530 100644
--- a/rules/windows/defense_evasion_wsl_filesystem.toml
+++ b/rules/windows/defense_evasion_wsl_filesystem.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,52 @@ sequence by process.entity_id with maxspan=5m
   process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"]
  [file where host.os.type == "windows" and process.name : "dllhost.exe" and not file.path : "?:\\Users\\*\\Downloads\\*"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Host Files System Changes via Windows Subsystem for Linux
+
+Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute commands and modify files on the host system, bypassing traditional security measures. The detection rule identifies suspicious file operations initiated by WSL processes, specifically monitoring for unusual activity by the Plan9FileSystem, which is responsible for file system interactions, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the process.entity_id and the timestamp of the event to correlate with other logs.
+- Verify the process start event for "dllhost.exe" with the specific Plan9FileSystem CLSID in the command line to confirm the use of WSL for file operations.
+- Check the file path involved in the alert to determine if it is a legitimate location or if it deviates from normal user behavior, especially outside the Downloads directory.
+- Investigate the parent process of "dllhost.exe" to identify how it was initiated and if it correlates with any known legitimate or suspicious activities.
+- Use Osquery to list all running WSL instances and their associated processes to identify any unusual or unauthorized WSL usage:
+  ```sql
+  SELECT name, state, version FROM wsl_instances;
+  ```
+- Examine recent file creation and modification events on the host system to identify any unauthorized changes or anomalies in file paths and names.
+- Correlate the event with user activity logs to determine if the file operations align with expected user behavior or if they indicate potential misuse.
+- Check for any recent changes in WSL configuration or installation logs to identify if WSL was recently enabled or modified, which could indicate an attempt to bypass security.
+- Review network logs for any unusual outbound connections from the host that could suggest data exfiltration attempts following the file system changes.
+- Investigate other security alerts or logs from the same host around the time of the alert to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use WSL for legitimate purposes such as running scripts or managing files, which could trigger the detection rule. To handle this, users can create exceptions for known administrative accounts or specific scripts that are regularly executed.
+- Development activities: Developers often use WSL for software development, which involves frequent file creation and modification. Users can exclude specific development environments or directories from monitoring to reduce false positives.
+- Automated processes: Scheduled tasks or automated processes that interact with the file system via WSL might be flagged. Identifying and excluding these processes based on their command lines or execution patterns can help minimize false alerts.
+- Backup operations: Some backup solutions may utilize WSL to access and copy files, leading to potential false positives. Users should identify these backup processes and configure exceptions for them to prevent unnecessary alerts.
+- Security tools: Certain security tools or monitoring solutions might use WSL for scanning or analysis purposes. Users can whitelist these tools by their process names or command lines to avoid false detections.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on WSL processes and any unusual file modifications.
+- Review and analyze logs from WSL and Plan9FileSystem activities to understand the adversary's actions and entry points.
+- Remove any unauthorized WSL installations or configurations that were not approved or are deemed suspicious.
+- Restore any modified or deleted files from known good backups to ensure data integrity and system functionality.
+- Apply security patches and updates to both Windows and WSL to mitigate any known vulnerabilities that could be exploited.
+- Implement enhanced logging policies to capture detailed WSL activity, including process creation, file access, and network connections.
+- Integrate security solutions with SIEM systems to improve detection capabilities and automate alerting for suspicious WSL activities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks associated with WSL and provide training on secure configuration and usage practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_kalilinux.toml b/rules/windows/defense_evasion_wsl_kalilinux.toml
index 5e45f738e56..100441808ae 100644
--- a/rules/windows/defense_evasion_wsl_kalilinux.toml
+++ b/rules/windows/defense_evasion_wsl_kalilinux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,50 @@ process where host.os.type == "windows" and event.type == "start" and
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Install Kali Linux via WSL
+
+Windows Subsystem for Linux (WSL) allows users to run Linux distributions on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to install distributions like Kali Linux, leveraging its capabilities for stealthy operations and evading traditional Windows security measures. The detection rule identifies suspicious activities by monitoring specific process executions and arguments related to Kali Linux installation, helping to uncover potential misuse of WSL for malicious purposes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious process executions related to Kali Linux installation via WSL, focusing on the `process.name` and `process.args` fields.
+- Check the `process.executable` path to verify if it matches known paths for Kali Linux installations, such as those in `AppData` or `Program Files`.
+- Use Osquery to list all installed WSL distributions on the host to confirm the presence of Kali Linux. Example query: `SELECT name FROM wsl_distributions;`
+- Investigate the parent process of `wsl.exe` to determine how the installation was initiated and identify any associated user accounts.
+- Examine the user account associated with the suspicious process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Review recent login events for the user account to identify any unusual access patterns or times that could suggest unauthorized activity.
+- Analyze network activity from the host around the time of the alert to detect any connections to known malicious IPs or domains associated with Kali Linux usage.
+- Check for any additional processes or scripts executed by the user that could indicate further malicious activity or attempts to leverage Kali Linux tools.
+- Investigate any file modifications or creations in the directories associated with the Kali Linux installation paths to identify potential tampering or unauthorized changes.
+- Correlate the findings with other security alerts or logs from the same host to build a comprehensive picture of the potential threat and its scope.
+
+### False positive analysis
+
+- Users or administrators may intentionally install Kali Linux via WSL for legitimate purposes such as development, testing, or educational activities, which can trigger the detection rule.
+- Automated scripts or deployment tools that configure development environments might include steps to install Kali Linux on WSL, leading to benign alerts.
+- Security researchers or IT professionals might use Kali Linux on WSL for vulnerability assessments or penetration testing within a controlled environment, which should be considered non-threatening.
+- To manage these false positives, users can create exceptions for known and authorized users or systems that regularly perform these installations.
+- Implementing a whitelist of approved processes or users who are allowed to install Kali Linux via WSL can help reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from detection, maintaining a balance between security and operational needs.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the WSL installation by checking with the user or system owner and reviewing recent changes or installations.
+- Conduct a thorough investigation of the system to identify any additional malicious activities or unauthorized access, focusing on processes and files related to Kali Linux.
+- Remove any unauthorized or suspicious WSL distributions, particularly Kali Linux, and ensure that WSL is configured according to organizational policies.
+- Review and update security policies to restrict the installation of unauthorized WSL distributions and enforce application whitelisting where possible.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging and monitoring for WSL activities, including process execution and network connections, to improve detection of similar threats in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate WSL-related alerts with other security events.
+- Restore the system to its operational state by reinstalling necessary software and applying security patches, ensuring that no unauthorized changes remain.
+- Apply system hardening measures, such as disabling WSL if not needed, enforcing least privilege access, and regularly reviewing user permissions and installed software."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_active_directory_webservice.toml b/rules/windows/discovery_active_directory_webservice.toml
index e43e63aa66c..3f3e952d1c2 100644
--- a/rules/windows/discovery_active_directory_webservice.toml
+++ b/rules/windows/discovery_active_directory_webservice.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,49 @@ sequence by process.entity_id with maxspan=3m
  [network where host.os.type == "windows" and destination.port == 9389 and source.port >= 49152 and
   network.direction == "egress" and network.transport == "tcp" and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Enumeration via Active Directory Web Service
+
+Active Directory Web Service (ADWS) facilitates querying Active Directory (AD) over a network, providing a web-based interface for directory services. Adversaries may exploit ADWS to enumerate network resources and user accounts, gaining insights into the environment. The detection rule identifies suspicious activity by monitoring processes loading specific AD-related modules and making network connections to the ADWS port, which may indicate unauthorized enumeration attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process entity ID that triggered the rule, focusing on the process loading the AD-related modules.
+- Examine the process executable path to determine if it matches any known legitimate applications or if it appears suspicious based on the exclusion list in the query.
+- Check the user ID associated with the process to verify if it belongs to a legitimate system account or an unexpected user, as the query excludes well-known service accounts.
+- Investigate the network connection details, particularly the destination IP and port 9389, to confirm if the connection was made to a legitimate ADWS server or an unexpected destination.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <process_id>;` to retrieve command-line arguments and other process details.
+- Analyze the source port used in the network connection to determine if it falls within the expected ephemeral port range, as specified in the query.
+- Cross-reference the destination IP address with known internal ADWS servers or external threat intelligence sources to assess its legitimacy.
+- Review recent login events and user activity logs for the user associated with the process to identify any unusual behavior or patterns.
+- Check for any other recent alerts or logs related to the same process entity ID or user ID to identify potential patterns or repeated attempts.
+- Investigate any other network connections made by the same process to determine if there are additional suspicious activities or connections to other critical services.
+
+### False positive analysis
+
+- Legitimate administrative tools and scripts may load Active Directory-related modules and connect to the ADWS port as part of routine operations, leading to false positives. 
+- Scheduled tasks or automated processes that query Active Directory for system management or monitoring purposes might trigger the rule.
+- Security software or monitoring agents that perform regular checks on Active Directory services could be mistakenly flagged.
+- To manage these false positives, users can create exceptions for known benign processes by excluding specific executables or user accounts that are verified as non-threatening.
+- Regularly review and update the list of excluded processes and users to ensure that only legitimate activities are exempted, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the enumeration attempt, including reviewing logs and correlating with other security events.
+- Verify the legitimacy of the process and user account involved in the suspicious activity to determine if it is a false positive or a genuine threat.
+- If malicious activity is confirmed, terminate the suspicious process and disable the associated user account to prevent further access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Review and enhance logging policies to ensure comprehensive monitoring of Active Directory-related activities, including module loads and network connections.
+- Implement additional security controls, such as network segmentation and access controls, to limit exposure of the Active Directory Web Service.
+- Restore the system to its operational state by applying necessary patches, updating security configurations, and conducting a full system scan for malware.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks associated with Active Directory enumeration and the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_high_number_ad_properties.toml b/rules/windows/discovery_high_number_ad_properties.toml
index 0b6dad34e2a..201a96a97e8 100644
--- a/rules/windows/discovery_high_number_ad_properties.toml
+++ b/rules/windows/discovery_high_number_ad_properties.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,48 @@ any where event.action in ("Directory Service Access", "object-operation-perform
  event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and
  winlog.event_data.AccessMaskDescription == "Read Property" and length(winlog.event_data.Properties) >= 2000
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Access to LDAP Attributes
+
+LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to read numerous object attributes, seeking vulnerabilities or sensitive data. The detection rule identifies unusual read access patterns, excluding system accounts, by monitoring specific event codes and access descriptions, flagging potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the event logs to confirm the alert by checking for event code 4662 and ensuring the AccessMaskDescription is "Read Property".
+- Verify the SubjectUserSid to ensure it is not the system account (S-1-5-18) and identify the actual user or service account involved.
+- Analyze the winlog.event_data.Properties field to understand which attributes were accessed and assess their sensitivity or relevance to potential vulnerabilities.
+- Cross-reference the identified user or service account with recent changes in user permissions or roles to determine if the access is legitimate or part of a broader pattern.
+- Investigate the source IP address or host from which the LDAP access was initiated to determine if it aligns with expected network behavior for the identified user or service account.
+- Use Osquery to gather additional context on the host involved. For example, run the query: `SELECT * FROM processes WHERE name LIKE '%ldap%' AND user = '<identified_user>';` to identify any suspicious processes related to LDAP access.
+- Check for any correlated alerts or logs that might indicate lateral movement or privilege escalation attempts by the same user or from the same host.
+- Review historical access patterns for the identified user or service account to determine if this level of access is typical or anomalous.
+- Consult with the directory services team to verify if there were any legitimate administrative tasks or audits that could explain the high volume of attribute reads.
+- Document all findings and observations, including any unusual patterns or discrepancies, to support further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators or automated scripts may perform legitimate bulk reads of LDAP attributes as part of regular maintenance or audits. These activities can trigger the rule but are non-threatening.
+- Monitoring and compliance tools: Security and compliance software often access a large number of LDAP attributes to ensure policy adherence and system health, which can be mistaken for suspicious activity.
+- Application service accounts: Some applications require extensive access to LDAP attributes for functionality, such as user provisioning or authentication services, which may appear as suspicious reads.
+- To manage false positives, users can create exceptions for known administrative accounts, service accounts, or specific tools that regularly perform high-volume LDAP reads. This can be done by adding these accounts to an exclusion list or adjusting the rule to ignore specific access patterns associated with legitimate activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Conduct a thorough investigation to identify the source and scope of the suspicious LDAP access, focusing on the user accounts and systems involved.
+- Review and analyze logs from the affected system and related network devices to gather evidence and understand the attack vector.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Reset passwords and review permissions for any accounts that were involved in the suspicious activity to prevent further unauthorized access.
+- Implement enhanced logging policies to capture detailed LDAP access events, ensuring that all read operations on sensitive attributes are monitored.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate LDAP access patterns with known threat indicators.
+- Restore the affected system to its operational state by applying necessary patches, updates, and configuration changes to address any identified vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting LDAP access to only necessary accounts, enabling multi-factor authentication, and regularly auditing directory permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
index 6c49a43316c..e0d4c6ae29a 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,48 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
   "c4e9ed3e-55a2-4309-a012-bc3c78dad10a" or "51176ed2-2d90-49f2-9f3d-17196428b169"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Discovery Signal Alert with Unusual Process Command Line
+
+In Windows environments, adversaries often exploit command-line tools to gather system information stealthily. This detection rule identifies anomalies by monitoring unique combinations of host, user, and command-line entries. By correlating these with known discovery tactics, it flags potential misuse, alerting analysts to investigate further.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific host.id, user.id, and process.command_line that triggered the alert. This will provide context on the potentially suspicious activity.
+- Cross-reference the command line entry with known legitimate processes and commands to determine if the activity is expected or unusual for the given host and user.
+- Check the event logs on the affected host for any related events around the time of the alert to gather additional context on the process execution.
+- Investigate the user.id associated with the alert to determine if the user has a history of executing similar commands or if this behavior is atypical.
+- Utilize Osquery to gather more information about the process and its parent process. For example, run the following Osquery query to list processes with their parent processes: `SELECT pid, name, path, parent FROM processes WHERE pid = <suspicious_pid>;`
+- Examine the network activity from the host during the time of the alert to identify any unusual outbound connections that may correlate with the command line activity.
+- Review any recent changes or updates to the host that might explain the unusual command line activity, such as software installations or configuration changes.
+- Check for any other alerts or signals from the same host or user within a similar timeframe to identify potential patterns or related activities.
+- Consult threat intelligence sources to determine if the command line or process is associated with known malicious activity or threat actor techniques.
+- Document all findings and observations during the investigation to provide a comprehensive overview of the incident and support any further analysis or escalation.
+
+### False positive analysis
+
+- Known false positives for the Unusual Discovery Signal Alert with Unusual Process Command Line rule often arise from legitimate administrative tasks or automated scripts that use command-line tools for system management or monitoring. These activities can mimic adversarial discovery techniques but are benign in nature.
+- Users can manage these false positives by identifying and documenting regular administrative processes and scripts that trigger the alert. Once identified, these can be excluded from the alerting criteria by creating exceptions based on specific host.id, user.id, or process.command_line patterns that are known to be safe.
+- It is important to regularly review and update these exceptions to ensure they remain relevant and do not inadvertently exclude new or modified legitimate processes that could be exploited by adversaries.
+- Collaboration with IT and security teams can help in distinguishing between legitimate and suspicious activities, ensuring that the rule remains effective in detecting genuine threats while minimizing noise from false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the unusual process command line to determine if it aligns with known malicious patterns or behaviors.
+- Review user activity and permissions associated with the alert to identify any unauthorized access or privilege escalation.
+- Utilize endpoint detection and response (EDR) tools to perform a detailed analysis of the affected system, focusing on any additional indicators of compromise (IOCs).
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a confirmed threat or if the scope of the attack is unclear.
+- Apply patches and updates to the operating system and any vulnerable applications to mitigate known vulnerabilities.
+- Restore the system from a clean backup if malicious activity is confirmed and ensure that the backup is free from compromise.
+- Implement enhanced logging and monitoring policies to capture detailed command-line activity and user actions for future investigations.
+- Integrate threat intelligence feeds to correlate alerts with known threat actor tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
index b39b57e1999..c0f04a97115 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,48 @@ type = "new_terms"
 query = '''
 host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:"1d72d014-e2ab-4707-b056-9b96abe7b511"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Discovery Signal Alert with Unusual Process Executable
+
+This detection rule focuses on identifying anomalies in Windows environments by monitoring signals with atypical host, user, and process attributes. Adversaries often exploit legitimate discovery tools to gather system information stealthily. The rule flags unusual process executions, which may indicate unauthorized reconnaissance activities, by leveraging unique identifiers and alert data to pinpoint suspicious behavior.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the unique `host.id`, `user.id`, and `process.executable` involved in the alert.
+- Verify the legitimacy of the `process.executable` by checking its digital signature and comparing it against known good executables.
+- Cross-reference the `host.id` with asset management systems to gather information about the host, such as its role, owner, and recent changes or updates.
+- Investigate the `user.id` to determine if the user has a history of executing similar processes or if there are any anomalies in their recent activity.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes executed by the user on the host: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<user.id>') AND host = '<host.id>';`
+- Check for any recent logins or access attempts on the host that might correlate with the alert, focusing on unusual times or locations.
+- Analyze network traffic from the host around the time of the alert to identify any suspicious outbound connections or data exfiltration attempts.
+- Review historical alerts and logs to determine if there have been previous instances of similar unusual process executions on the same host or by the same user.
+- Consult threat intelligence sources to see if the `process.executable` or any related indicators have been associated with known threat actors or campaigns.
+- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation for future reference.
+
+### False positive analysis
+
+- Known false positives for the Unusual Discovery Signal Alert with Unusual Process Executable rule may include legitimate administrative tools or scripts that perform system discovery tasks as part of routine operations. These can be flagged due to their atypical execution patterns or unique identifiers.
+- Users can manage these false positives by creating exceptions for known and trusted processes, users, or hosts that frequently trigger alerts. This can be done by adding specific host.id, user.id, or process.executable entries to an allowlist within the rule configuration.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness in detecting genuine threats.
+- Consider implementing a baseline of normal activity for your environment to better distinguish between legitimate and suspicious discovery activities, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on unusual process executions and correlating with other security alerts.
+- Review user activity logs to determine if any legitimate user accounts have been compromised and reset passwords as necessary.
+- Analyze the unusual process executable to understand its origin and functionality, using threat intelligence sources to identify any known malicious signatures.
+- Remove any unauthorized or malicious software identified during the investigation from the affected systems.
+- Restore the system from a known good backup to ensure all traces of the compromise are removed.
+- Implement enhanced logging policies to capture detailed process execution and user activity data for future investigations.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and detection capabilities.
+- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity partners for further analysis and response.
+- Review and update security policies and procedures to address any gaps identified during the incident, including implementing stricter access controls and regular security training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
index e80673b2bbd..dce23e455c0 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,48 @@ process.parent.name: (
      "SolarwindsDiagnostics*.exe"
      )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Command Execution via SolarWinds Process
+
+SolarWinds is a suite of network and system management tools widely used in IT environments. Adversaries may exploit SolarWinds processes to execute unauthorized commands by spawning child processes like Cmd.exe or Powershell.exe, leveraging trusted SolarWinds executables to evade detection. The detection rule identifies suspicious activity by monitoring the initiation of these child processes from specific SolarWinds parent processes, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) using the `process.parent.name` field.
+- Check the `process.command_line` field for the suspicious child process to understand the exact command or script executed, which can provide insights into the intent of the execution.
+- Investigate the user account associated with the process execution by examining the `user.name` field to determine if the activity aligns with expected behavior for that account.
+- Correlate the timestamp of the event with other security logs to identify any concurrent suspicious activities or anomalies in the network or system.
+- Use Osquery to gather additional context about the parent process by running a query such as: `SELECT * FROM processes WHERE name LIKE 'SolarWinds%' AND pid = <parent_process_id>;` to retrieve details about the process state and its environment.
+- Examine historical data to determine if similar command executions have occurred previously from the same SolarWinds parent process, indicating a potential pattern or ongoing issue.
+- Analyze network traffic logs around the time of the event to identify any unusual outbound connections that may suggest data exfiltration or command-and-control communication.
+- Check for any recent changes or updates to the SolarWinds software that might explain the execution of the child process as part of legitimate operations.
+- Investigate the system for any signs of compromise, such as unauthorized changes to system files or configurations, which could indicate a broader security incident.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with exploiting SolarWinds processes in a similar manner.
+
+### False positive analysis
+
+- Routine administrative tasks: SolarWinds administrators may use Cmd.exe or Powershell.exe for legitimate configuration or maintenance tasks, leading to false positives. Users can create exceptions for known administrative activities by whitelisting specific user accounts or time frames.
+- Automated scripts: Scheduled scripts or automated processes that utilize Cmd.exe or Powershell.exe for system checks or updates might trigger alerts. To manage these, users can exclude specific scripts or processes by identifying their unique command-line arguments or execution patterns.
+- Software updates: During SolarWinds software updates, legitimate child processes may be spawned, which could be mistaken for suspicious activity. Users should monitor update schedules and temporarily adjust detection rules to accommodate these updates.
+- Third-party integrations: Some third-party tools integrated with SolarWinds may invoke Cmd.exe or Powershell.exe for data collection or reporting. Users can handle these by verifying the legitimacy of the third-party tool and excluding its known processes from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been affected.
+- Analyze the suspicious child processes (Cmd.exe or Powershell.exe) to understand the commands executed and assess potential damage or data exfiltration.
+- Review and collect relevant logs from SolarWinds and other security tools to gather evidence and understand the attack vector.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
+- Remove any unauthorized or malicious scripts or executables identified during the investigation from the affected systems.
+- Apply patches and updates to SolarWinds and other software to mitigate known vulnerabilities and prevent similar attacks.
+- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate alerts.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and least privilege access, to strengthen defenses against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
index 1d85e3cce88..65d99284cb2 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -58,6 +58,49 @@ process where host.os.type == "windows" and event.type == "start" and
  ) and
  not process.executable : ("?:\\Windows\\SysWOW64\\ARP.EXE", "?:\\Windows\\SysWOW64\\lodctr.exe", "?:\\Windows\\SysWOW64\\unlodctr.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious SolarWinds Child Process
+
+SolarWinds is a widely used IT management software that operates critical network functions. Adversaries may exploit its trusted processes to execute unauthorized programs, bypassing security measures. The detection rule identifies unusual child processes spawned by SolarWinds' core executables, excluding known legitimate ones, to flag potential malicious activity. This approach leverages process behavior and code signature verification to detect anomalies indicative of compromise.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific child process was spawned by SolarWinds and verify if it matches any known legitimate processes.
+- Check the process code signature to determine if it is trusted or untrusted, focusing on the `process.code_signature.trusted` field.
+- Investigate the parent process details, specifically `SolarWinds.BusinessLayerHost.exe` or `SolarWinds.BusinessLayerHostx64.exe`, to confirm its legitimacy and recent activity.
+- Examine the process executable path using the `process.executable` field to ensure it is not located in suspicious directories.
+- Utilize Osquery to gather additional context on the suspicious process. Example query: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve detailed information about the process.
+- Cross-reference the suspicious process with known threat intelligence sources to identify if it is associated with any known malicious activity.
+- Analyze the process command line arguments to identify any unusual or unexpected parameters that could indicate malicious intent.
+- Review recent system logs and events around the time of the alert to identify any correlated activities or anomalies.
+- Investigate network connections initiated by the suspicious process to detect any unauthorized or suspicious outbound communication.
+- Check for any recent changes or updates to the SolarWinds software that could explain the unusual child process behavior, ensuring it aligns with legitimate updates or patches.
+
+### False positive analysis
+
+- Known false positives may include legitimate SolarWinds processes that are not yet included in the exclusion list. These can occur when new SolarWinds updates introduce additional child processes that are not recognized by the current rule.
+- Users can handle these false positives by monitoring the detected processes and verifying their legitimacy through process code signature checks. If a process is confirmed to be non-threatening, it can be added to the exclusion list to prevent future alerts.
+- Another potential false positive source is third-party integrations or plugins that interact with SolarWinds processes. Users should verify these integrations and, if deemed safe, update the rule to exclude these specific child processes.
+- Regularly review and update the exclusion list to include new legitimate processes as SolarWinds software evolves. This proactive approach helps minimize false positives while maintaining security vigilance.
+- Consider implementing a logging mechanism to track and review all flagged processes over time. This can help identify patterns and refine the exclusion criteria to better distinguish between benign and suspicious activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the suspicious child process to determine its origin and intent, using forensic tools to analyze process execution and network connections.
+- Verify the integrity of SolarWinds software and its components by checking for unauthorized modifications or tampering.
+- Terminate any unauthorized or suspicious processes identified during the investigation to contain the threat.
+- Review and update security policies to ensure that only legitimate child processes are allowed to execute under SolarWinds parent processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger campaign.
+- Implement enhanced logging and monitoring for SolarWinds processes and related network activity to detect future anomalies.
+- Restore the system to its operational state by applying clean backups and ensuring all software is up to date with the latest security patches.
+- Conduct a post-incident review to identify gaps in security controls and improve response strategies.
+- Harden the environment by implementing least privilege access controls, regular software audits, and continuous security awareness training for staff."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_com_object_xwizard.toml b/rules/windows/execution_com_object_xwizard.toml
index d0f0f60ae02..ade95978e37 100644
--- a/rules/windows/execution_com_object_xwizard.toml
+++ b/rules/windows/execution_com_object_xwizard.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,49 @@ process where host.os.type == "windows" and event.type == "start" and
    )
  )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution of COM object via Xwizard
+
+The Windows Component Object Model (COM) facilitates communication between software components. Adversaries exploit this by using Xwizard to execute COM objects, bypassing security measures. The detection rule identifies suspicious Xwizard executions by checking for unusual arguments or non-standard executable paths, indicating potential misuse for malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `xwizard.exe` in the process name or original file name fields, as this is the primary indicator of potential misuse.
+- Examine the process arguments to check for the presence of "RunWizard" and GUID-like patterns (e.g., "{*}"), which may indicate an attempt to execute a COM object.
+- Verify the executable path of `xwizard.exe` to determine if it deviates from standard paths such as "C:\\Windows\\SysWOW64\\xwizard.exe" or "C:\\Windows\\System32\\xwizard.exe", which could suggest tampering or unauthorized use.
+- Investigate the parent process of `xwizard.exe` to understand how it was launched and identify any potentially malicious parent processes.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'xwizard.exe';` to retrieve details like process ID, parent process ID, and command line arguments.
+- Check the system's event logs for any related entries around the time of the alert to identify other suspicious activities or corroborating evidence.
+- Analyze the registry for any unusual or unauthorized COM objects that may have been created or modified, focusing on recent changes.
+- Investigate network connections initiated by `xwizard.exe` to identify any suspicious outbound communication that could indicate data exfiltration or command-and-control activity.
+- Review the user account associated with the `xwizard.exe` process to determine if it has been compromised or is being used in an unauthorized manner.
+- Correlate the findings with other security alerts or incidents in the environment to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Legitimate administrative tasks: Xwizard.exe may be used by system administrators for legitimate configuration tasks, which can trigger the detection rule. Users should verify the context of the execution to determine if it aligns with routine administrative activities.
+- Software installations or updates: Some software installations or updates might invoke Xwizard.exe as part of their setup process. Users can create exceptions for known software that frequently triggers this rule during installation or updates.
+- System maintenance scripts: Automated scripts for system maintenance might use Xwizard.exe to perform legitimate operations. Users should review these scripts and whitelist them if they are verified as non-threatening.
+- Custom enterprise applications: In some environments, custom applications may use Xwizard.exe for inter-process communication. Users should document these applications and exclude their known behaviors from triggering the rule.
+- To manage false positives, users can create exceptions in their detection systems for specific processes or paths that are verified as safe. This can be done by adding these known benign activities to an allowlist or exclusion list, ensuring that only truly suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on the execution of the COM object via Xwizard and any associated processes or files.
+- Terminate any suspicious processes related to Xwizard that are not running from standard executable paths.
+- Review and analyze the Windows Event Logs and any available security logs for additional indicators of compromise or related suspicious activities.
+- Restore the system from a known good backup if the investigation confirms malicious activity and system integrity is compromised.
+- Update and apply security patches to the operating system and all installed software to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on recognizing and reporting suspicious activities to prevent future incidents and improve overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_command_shell_started_by_unusual_process.toml b/rules/windows/execution_command_shell_started_by_unusual_process.toml
index 437d881b36d..29e787c3804 100644
--- a/rules/windows/execution_command_shell_started_by_unusual_process.toml
+++ b/rules/windows/execution_command_shell_started_by_unusual_process.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,48 @@ process where host.os.type == "windows" and event.type == "start" and
                          "wlanext.exe" ) and
   not (process.parent.name : "dllhost.exe" and process.parent.args : "/Processid:{CA8C87C1-929D-45BA-94DB-EF8E6CB346AD}")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Parent Process for cmd.exe
+
+The cmd.exe process is a command-line interpreter in Windows environments, often used for legitimate administrative tasks. However, adversaries can exploit it by launching it from atypical parent processes to execute malicious commands stealthily. The detection rule identifies such anomalies by flagging cmd.exe instances spawned by uncommon parent processes, which may indicate unauthorized or suspicious activity, thus helping analysts pinpoint potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of cmd.exe being spawned by an unusual parent process as specified in the detection rule.
+- Verify the legitimacy of the parent process by checking its usual behavior and purpose within the environment. Cross-reference with known software documentation or internal process baselines.
+- Examine the command-line arguments used by the parent process to launch cmd.exe, if available, to identify any suspicious or unexpected commands.
+- Investigate the user account associated with the process execution to determine if it aligns with expected usage patterns or if it might be compromised.
+- Check the process creation time and correlate it with other security events or logs to identify any concurrent suspicious activities.
+- Utilize Osquery to gather additional context about the parent process. For example, run the following query to list details about the parent process: `SELECT * FROM processes WHERE name = 'unusual_parent_process_name';`
+- Analyze network connections initiated by the cmd.exe process to identify any unusual or unauthorized external communications.
+- Review recent changes or updates to the system that might have introduced new or altered processes, potentially explaining the unusual parent-child relationship.
+- Investigate any file modifications or registry changes made by the cmd.exe process to assess potential malicious actions.
+- Consult threat intelligence sources to determine if the unusual parent process is associated with known malware or attack techniques.
+
+### False positive analysis
+
+- Certain legitimate applications or system processes may occasionally spawn cmd.exe for valid reasons, leading to false positives. For example, software updates or system maintenance tasks might trigger cmd.exe from processes like GoogleUpdate.exe or FlashPlayerUpdateService.exe.
+- Automated scripts or administrative tools that are scheduled to run at specific times might also cause cmd.exe to be launched by processes such as taskhostw.exe or sppsvc.exe, which are typically benign.
+- Users can manage these false positives by creating exceptions for known and verified processes that frequently trigger cmd.exe in a non-threatening manner. This can be done by adding specific process names or command-line arguments to an exclusion list within the detection rule.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and any changes in legitimate software behavior, thus minimizing the risk of overlooking genuine threats while reducing noise from false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the unusual parent process that spawned cmd.exe.
+- Review and analyze logs from the affected system and any related systems to trace the attacker's actions and identify any additional compromised systems.
+- Terminate any malicious processes and remove any unauthorized files or scripts identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Implement enhanced logging policies to capture detailed process creation events and parent-child process relationships for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as application whitelisting, least privilege access, and regular security awareness training to reduce the risk of similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_command_shell_via_rundll32.toml b/rules/windows/execution_command_shell_via_rundll32.toml
index f19d1e775db..4f2fe2dfc1b 100644
--- a/rules/windows/execution_command_shell_via_rundll32.toml
+++ b/rules/windows/execution_command_shell_via_rundll32.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,50 @@ process where host.os.type == "windows" and event.type == "start" and
   not process.parent.args : ("C:\\Windows\\System32\\SHELL32.dll,RunAsNewUser_RunDLL",
                              "C:\\WINDOWS\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Command Shell Activity Started via RunDLL32
+
+RunDLL32 is a Windows utility that executes functions within DLLs, often used for legitimate purposes. However, attackers exploit it to run malicious scripts or commands by invoking command shells like cmd.exe or PowerShell. The detection rule identifies suspicious activity by monitoring processes initiated by RunDLL32, excluding known benign patterns, to flag potential misuse aligned with MITRE ATT&CK's execution tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `cmd.exe` or `powershell.exe` processes initiated by `rundll32.exe` and verify that the `process.parent.command_line` is not null.
+- Examine the `process.parent.command_line` field to understand the context in which `rundll32.exe` was executed, looking for any unusual or suspicious command-line arguments.
+- Check the `process.parent.args` field to ensure that the command line does not match known benign patterns, such as those involving `SHELL32.dll` or temporary files.
+- Investigate the parent process of `rundll32.exe` to determine how it was launched and whether it was initiated by a legitimate application or user action.
+- Use Osquery to gather additional context about the process tree. For example, run the following query to list processes related to the suspicious activity:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cmd.exe', 'powershell.exe') AND parent IN (SELECT pid FROM processes WHERE name = 'rundll32.exe');
+  ```
+- Analyze the timeline of events leading up to the alert to identify any preceding activities that might indicate compromise, such as suspicious file downloads or registry changes.
+- Correlate the alert with other security events or logs, such as network traffic or file access logs, to identify any related indicators of compromise.
+- Check for any recent changes in the system, such as new software installations or updates, that might explain the execution of `rundll32.exe` with command shells.
+- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised.
+- Review historical data to see if similar alerts have been triggered in the past, which could indicate a recurring issue or persistent threat.
+
+### False positive analysis
+
+- Known false positives for the Command Shell Activity Started via RunDLL32 rule include legitimate system or application processes that invoke command shells for routine operations. For example, certain software installations or updates may use RunDLL32 to execute scripts as part of their setup process.
+- Users can manage these false positives by identifying and excluding frequent non-threatening behaviors. This can be done by adding exceptions to the detection rule for specific command line arguments or parent process command lines that are known to be safe. For instance, excluding command lines that match patterns like "C:\\\\Windows\\\\System32\\\\SHELL32.dll,RunAsNewUser_RunDLL" or "C:\\\\WINDOWS\\\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc" can help reduce noise from benign activities.
+- It is important to regularly review and update these exceptions to ensure they align with the current environment and do not inadvertently allow malicious activity to go undetected.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the rundll32.exe process and its command line arguments to determine if the activity is malicious.
+- Review recent system changes and user activity logs to identify any unauthorized access or modifications.
+- If malicious activity is confirmed, terminate the suspicious processes and remove any associated malicious files or scripts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process creation events and command line arguments for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics and techniques.
+- Restore the system to its operational state by applying the latest security patches and updates, and conducting a full system scan with updated antivirus software.
+- Educate users on recognizing and reporting suspicious activities to prevent future incidents.
+- Implement system hardening measures, such as restricting the use of rundll32.exe to authorized applications and users, and applying application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
index 1fe398d770d..47e464e0ffb 100644
--- a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
+++ b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,49 @@ sequence by process.parent.entity_id with maxspan=1m
                      "?:\\Users\\*\\AppData\\Local\\Temp\\QBTools\\"))
     ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Delayed Execution via Ping
+
+Ping is a network utility used to test connectivity and measure response times. Adversaries exploit it for delayed execution by using it to introduce pauses in scripts, often to evade detection. The detection rule identifies suspicious use of ping with specific arguments, followed by execution of potentially malicious utilities, indicating an attempt to stealthily execute harmful payloads.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the specific process names and arguments involved, such as "ping.exe" with the "-n" argument and the subsequent execution of suspicious utilities like "rundll32.exe" or "powershell.exe".
+- Examine the parent process information, particularly focusing on "cmd.exe", to determine how the ping command was initiated and whether it aligns with typical user behavior or automated scripts.
+- Investigate the user account associated with the process execution, especially if the user ID is not "S-1-5-18", to assess whether the activity is expected for that user or indicative of compromised credentials.
+- Check the process execution timeline to identify any patterns or sequences that suggest a coordinated attack, using the maxspan=1m parameter to focus on closely timed events.
+- Utilize Osquery to gather additional context on the involved processes. For example, run the following query to list all processes executed by the same user within a short timeframe: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<user_id>' AND start_time > datetime('now', '-5 minutes');`
+- Analyze the command line arguments of the suspicious processes to identify any encoded or obfuscated commands that may indicate malicious intent.
+- Investigate the file paths and code signatures of the executed processes, especially those in user directories like "?:\\\\Users\\\\*\\\\AppData\\\\*.exe", to determine if they are trusted or potentially malicious.
+- Review the system's event logs for any additional indicators of compromise or related suspicious activity, such as failed login attempts or unusual network connections.
+- Cross-reference the alert with known threat intelligence sources to identify if the observed behavior matches any known attack patterns or malware signatures.
+- Document all findings and observations, including any anomalies or deviations from normal behavior, to support further analysis and potential escalation.
+
+### False positive analysis
+
+- Scheduled tasks or legitimate administrative scripts may use ping for delay purposes, leading to false positives. Users can handle this by identifying and excluding these specific scripts or tasks from the detection rule.
+- Software installers or updaters might use ping to introduce delays during installation processes. Users should monitor and whitelist these known installers to prevent unnecessary alerts.
+- Network troubleshooting tools or scripts executed by IT personnel could trigger the rule. It's advisable to create exceptions for these tools when used by trusted users or within specific environments.
+- Automated testing environments might use ping to simulate network conditions, which could be mistaken for malicious activity. Users can exclude these environments or specific test scripts from the rule.
+- Some legitimate applications might use ping as part of their normal operation, especially in network-heavy applications. Users should identify these applications and adjust the rule to exclude them based on their process signatures or paths.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise, focusing on the processes and files executed after the ping command.
+- Terminate any malicious processes identified during the investigation to stop ongoing threats.
+- Remove or quarantine any malicious files or scripts found on the system to prevent re-execution.
+- Review and analyze logs from the affected system and network devices to understand the scope and timeline of the attack, leveraging MITRE ATT&CK T1059 for context on command and scripting interpreter techniques.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger campaign or if sensitive data may have been compromised.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring that security configurations align with best practices to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_downloaded_shortcut_files.toml b/rules/windows/execution_downloaded_shortcut_files.toml
index 43fbff23e7a..00d1470d608 100644
--- a/rules/windows/execution_downloaded_shortcut_files.toml
+++ b/rules/windows/execution_downloaded_shortcut_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,49 @@ type = "eql"
 query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension == "lnk" and file.Ext.windows.zone_identifier > 1
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Downloaded Shortcut Files
+
+Shortcut files (.lnk) are used in Windows environments to link to executable files or scripts, streamlining user access. Adversaries exploit this by embedding malicious commands in .lnk files, often delivered via phishing, to execute unauthorized actions. The detection rule identifies .lnk files created on Windows systems with a zone identifier indicating they were downloaded, flagging potential phishing attempts.
+
+### Possible investigation steps
+
+- Verify the alert by checking the file creation event details, focusing on the `file.extension` and `file.Ext.windows.zone_identifier` fields to confirm the presence of a downloaded .lnk file.
+- Examine the file path and name to determine if it matches known malicious patterns or if it appears suspicious or unusual for the user or system.
+- Review the user account associated with the file creation event to assess if the activity aligns with their typical behavior or if it appears anomalous.
+- Investigate the source of the download by analyzing network logs or browser history to identify the URL or IP address from which the .lnk file was downloaded.
+- Use Osquery to gather additional context about the .lnk file. For example, run the following query to list all .lnk files in the user's Downloads directory: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%.lnk';`
+- Check the file hash against threat intelligence databases or a service like VirusTotal to determine if the .lnk file is associated with known malware.
+- Analyze the contents of the .lnk file to identify any embedded commands or scripts that could indicate malicious intent.
+- Review recent email logs for the user to identify any phishing emails that may have delivered the .lnk file as an attachment or link.
+- Correlate the event with other security alerts or logs from the same timeframe to identify any related suspicious activities or patterns.
+- Consult with the user to verify if they recall downloading the file and if they can provide any context or details about its origin.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they include .lnk files downloaded from trusted sources. Users should verify the source and context of the download to determine if it is a false positive.
+- Corporate environments often use remote desktop or file-sharing services that might download .lnk files as part of routine operations. Users can create exceptions for known and trusted services to reduce noise.
+- Some web browsers or email clients may download .lnk files as part of their normal operation, especially if configured to save shortcuts for frequently accessed sites or applications. Users should review browser or email client settings and consider excluding these specific applications if they are known to be safe.
+- Automated scripts or tools that download and create .lnk files for legitimate purposes, such as system maintenance or monitoring, can be excluded by identifying the specific processes or scripts involved and adding them to an exception list.
+- Users should regularly review and update their exception lists to ensure that only verified and non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Analyze the .lnk file to determine the embedded command or script and assess its impact.
+- Check for any unauthorized changes or execution of malicious payloads on the system.
+- Remove the malicious .lnk file and any associated malware or unauthorized software.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools.
+- Review user activity logs to identify how the .lnk file was downloaded and if any other systems are affected.
+- Escalate the incident to the security team if the threat is part of a larger campaign or if multiple systems are compromised.
+- Implement or update email filtering and web proxy rules to block similar phishing attempts in the future.
+- Enhance logging policies to capture detailed file creation and execution events for better future detection.
+- Restore the system from a clean backup if necessary and apply security patches and updates to harden the system against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_downloaded_url_file.toml b/rules/windows/execution_downloaded_url_file.toml
index 8b72e8d4a46..fa688e40028 100644
--- a/rules/windows/execution_downloaded_url_file.toml
+++ b/rules/windows/execution_downloaded_url_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,48 @@ query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension == "url"
    and file.Ext.windows.zone_identifier > 1 and not process.name : "explorer.exe"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Downloaded URL Files
+URL shortcut files, typically used to link to web resources, can be exploited by adversaries in phishing attacks to execute malicious content. These files, when downloaded from external sources, may bypass traditional security measures. The detection rule identifies such files created on Windows systems, excluding those initiated by the Explorer process, and flags them if they originate from non-local zones, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file extension is ".url" and verify the event type is "creation" on a Windows host.
+- Check the file.Ext.windows.zone_identifier field to determine the zone from which the file was downloaded, ensuring it is greater than 1, indicating a non-local source.
+- Investigate the process that created the .url file by examining the process.name field, ensuring it is not "explorer.exe" to rule out legitimate user activity.
+- Use Osquery to list all .url files on the system with the following query: `SELECT path, filename, size, atime, mtime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%.url';` to identify any other potentially suspicious files.
+- Correlate the creation time of the .url file with user activity logs to determine if the file was created during normal working hours or during unusual times.
+- Analyze network logs to identify any outbound connections made by the system around the time the .url file was created, focusing on connections to unfamiliar or suspicious domains.
+- Check the file's metadata and properties to gather additional context, such as the target URL and any embedded scripts or commands.
+- Investigate the user account associated with the creation of the .url file to determine if there are any signs of compromise or unusual behavior.
+- Review email logs or web browsing history to identify potential phishing emails or websites that could have led to the download of the .url file.
+- Cross-reference the identified URL with threat intelligence sources to determine if it is associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Legitimate software updates or installations may download .url files as part of their process, which could trigger the rule. Users should verify the source and context of these files to determine if they are part of a trusted application.
+- Corporate environments might use .url files for internal shortcuts or links to intranet resources. These should be reviewed and, if deemed safe, added to an exception list to prevent future alerts.
+- Some web browsers or download managers may create .url files as part of their download process. Users can monitor these applications and exclude them if they consistently generate non-malicious .url files.
+- Automated scripts or tools that interact with web resources might inadvertently create .url files. Users should assess these scripts and, if they are part of routine operations, consider excluding them from the detection rule.
+- To manage false positives, users can create exceptions based on file paths, specific processes, or known safe sources, ensuring that only unexpected or suspicious .url file creations are flagged.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Analyze the .url file to determine its origin and the URL it points to, checking for known malicious domains or IP addresses.
+- Review user activity logs to identify any execution of the .url file and any subsequent suspicious behavior.
+- Remove the .url file and any associated malicious files or processes from the system.
+- Conduct a full antivirus and anti-malware scan on the affected system to ensure no additional threats are present.
+- Restore the system from a known good backup if any critical system files or configurations have been altered.
+- Report the incident to the security team and escalate to management if the threat is part of a larger campaign or if sensitive data may have been compromised.
+- Implement enhanced logging policies to capture detailed file creation and process execution events for future investigations.
+- Integrate threat intelligence feeds to automatically update detection rules with known malicious URLs and domains.
+- Educate users on recognizing phishing attempts and the risks associated with downloading and executing files from untrusted sources."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_enumeration_via_wmiprvse.toml b/rules/windows/execution_enumeration_via_wmiprvse.toml
index dce7b4392db..900bdac5f56 100644
--- a/rules/windows/execution_enumeration_via_wmiprvse.toml
+++ b/rules/windows/execution_enumeration_via_wmiprvse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,56 @@ process where host.os.type == "windows" and event.type == "start" and process.co
   ) and
   not process.args : "tenable_mw_scan"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Enumeration Command Spawned via WMIPrvSE
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute enumeration commands stealthily, leveraging the WMI Provider Service (WMIPrvSE) to gather system and network information. The detection rule identifies suspicious processes initiated by WMIPrvSE, focusing on common enumeration tools, while excluding benign operations, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and command line arguments that triggered the alert, focusing on the `process.name` and `process.command_line` fields.
+- Verify the parent process by examining the `process.parent.name` field to ensure it is indeed `wmiprvse.exe`, confirming the use of WMI for process execution.
+- Check the timestamp of the event to determine when the suspicious process was started, which can help correlate with other activities on the system.
+- Investigate the user context under which the process was executed by reviewing the `user.name` field to identify if it was run under a privileged account.
+- Examine the network connections and activities around the time of the alert to identify any unusual outbound connections or data exfiltration attempts.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list processes with their parent process details:
+  ```sql
+  SELECT p.pid, p.name, p.cmdline, p.parent, pp.name AS parent_name, pp.cmdline AS parent_cmdline 
+  FROM processes p 
+  JOIN processes pp ON p.parent = pp.pid 
+  WHERE p.name IN ("arp.exe", "dsquery.exe", "dsget.exe", "gpresult.exe", "hostname.exe", "ipconfig.exe", "nbtstat.exe", "net.exe", "net1.exe", "netsh.exe", "netstat.exe", "nltest.exe", "ping.exe", "qprocess.exe", "quser.exe", "qwinsta.exe", "reg.exe", "sc.exe", "systeminfo.exe", "tasklist.exe", "tracert.exe", "whoami.exe") 
+  AND pp.name = "wmiprvse.exe";
+  ```
+- Correlate the event with other security logs, such as Windows Event Logs, to identify any related suspicious activities or anomalies.
+- Investigate the system's recent changes or configurations that might have allowed the execution, such as new software installations or changes in WMI settings.
+- Check for any known vulnerabilities or exploits related to WMI that might have been used by adversaries to execute the command.
+- Document all findings and observations to build a comprehensive understanding of the incident, which can aid in further analysis and reporting.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use WMI to execute legitimate enumeration commands for system management and troubleshooting, which can trigger this rule. To manage this, users can create exceptions for known administrative accounts or specific command patterns that are regularly used in their environment.
+- Monitoring and management software: Some security and network management tools use WMI to gather system information, which may appear as suspicious activity. Users should identify these tools and exclude their processes or command lines from the rule to prevent false positives.
+- Automated scripts and scheduled tasks: Scripts or scheduled tasks that perform regular system checks or updates might use WMI for enumeration. Users can handle these by excluding specific scripts or task names that are verified as non-threatening.
+- Software updates and installations: Certain software installations or updates might use WMI to check system compatibility or network settings. Users should monitor these activities and exclude known update processes to avoid unnecessary alerts.
+- Security scans: Security tools like vulnerability scanners may use WMI to collect data, which can be mistaken for malicious activity. Users should whitelist these tools by excluding their specific command lines or process names from the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on processes initiated by WMIPrvSE and any suspicious enumeration activity.
+- Terminate any malicious processes identified during the investigation to halt ongoing adversary actions.
+- Review and analyze logs from the affected system and related network devices to trace the adversary's activities and identify any additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process creation events and WMI activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting WMI access to authorized users only and disabling unnecessary WMI components to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_initial_access_foxmail_exploit.toml b/rules/windows/execution_initial_access_foxmail_exploit.toml
index 7a82513cf24..26bdda59cff 100644
--- a/rules/windows/execution_initial_access_foxmail_exploit.toml
+++ b/rules/windows/execution_initial_access_foxmail_exploit.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "m3
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,48 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and 
  process.parent.name : "Foxmail.exe" and process.args : ("?:\\Users\\*\\AppData\\*", "\\\\*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Foxmail Exploitation
+
+Foxmail, a popular email client, manages emails and attachments, storing temporary files in specific directories. Adversaries may exploit vulnerabilities in Foxmail to execute malicious payloads by manipulating these temp files. The detection rule identifies suspicious child processes initiated by Foxmail, focusing on those accessing temp directories, which may indicate exploitation attempts for unauthorized execution.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a child process spawned by Foxmail.exe, focusing on the process arguments that point to the temp directories (e.g., `?:\\Users\\*\\AppData\\*`).
+- Verify the legitimacy of the parent process by checking the hash and signature of Foxmail.exe to ensure it hasn't been tampered with.
+- Use Osquery to list all processes spawned by Foxmail.exe to identify any unusual or unexpected child processes. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'Foxmail.exe');`
+- Investigate the specific child process identified in the alert by examining its command line arguments and execution path for any anomalies or suspicious patterns.
+- Check the file creation and modification times in the temp directories accessed by the suspicious process to identify any recent changes that coincide with the alert.
+- Analyze the network activity of the suspicious process to detect any unusual outbound connections that could indicate data exfiltration or command and control communication.
+- Correlate the alert with other security events or logs, such as email gateway logs, to determine if a malicious email was received around the time of the alert.
+- Review the user account associated with the Foxmail process to determine if there are any signs of compromise or unauthorized access.
+- Examine the system for any additional indicators of compromise, such as registry changes, scheduled tasks, or persistence mechanisms that may have been established by the malicious process.
+- Consult threat intelligence sources to identify if the observed behavior matches any known exploitation techniques or campaigns targeting Foxmail vulnerabilities.
+
+### False positive analysis
+
+- Routine software updates or legitimate plugins for Foxmail may trigger the detection rule by spawning child processes that access temporary directories. These updates or plugins often require temporary file storage and execution, which can mimic the behavior of exploitation attempts.
+- Automated backup or synchronization tools that interact with Foxmail's temporary files might also be flagged as suspicious. These tools often access and modify files in the temp directories as part of their normal operation.
+- Users can manage these false positives by creating exceptions for known legitimate processes or tools that frequently interact with Foxmail's temp directories. This can be done by identifying the specific process names or paths and excluding them from the detection rule.
+- Monitoring the frequency and context of the alerts can help distinguish between benign and potentially malicious activities. If a process consistently triggers alerts but is verified as safe, it can be added to an allowlist to prevent future false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential exploitation.
+- Conduct a thorough investigation of the affected system to identify any malicious processes or files, focusing on the Foxmail temp directories.
+- Terminate any suspicious child processes spawned by Foxmail and delete any malicious files identified during the investigation.
+- Review email logs and quarantine any suspicious emails that may have been the source of the exploitation attempt.
+- Apply the latest security patches and updates to Foxmail and the operating system to mitigate known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and file access events, particularly for email clients and temp directories.
+- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging threats related to email client vulnerabilities.
+- Restore the system to its operational state by reinstalling Foxmail and restoring any affected files from clean backups.
+- Conduct a security awareness training session for users to recognize and report suspicious emails, reducing the risk of future exploitation attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_initial_access_wps_dll_exploit.toml b/rules/windows/execution_initial_access_wps_dll_exploit.toml
index 499d310019c..05f3e7a5cc4 100644
--- a/rules/windows/execution_initial_access_wps_dll_exploit.toml
+++ b/rules/windows/execution_initial_access_wps_dll_exploit.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,49 @@ any where host.os.type == "windows" and process.name : "promecefpluginhost.exe"
       "\\Device\\Mup\\**", "\\\\*"))
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WPS Office Exploitation via DLL Hijack
+
+DLL hijacking in WPS Office involves adversaries exploiting the ksoqing protocol handler to load malicious libraries via the promecefpluginhost.exe process. Attackers may leverage this to execute arbitrary code by placing a rogue DLL in specific directories or network paths. The detection rule identifies suspicious library loads and process actions, focusing on paths indicative of exploitation attempts, thus alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `promecefpluginhost.exe` process and verify the suspicious DLL path matches the patterns specified in the detection rule.
+- Check the event category to determine if the alert was triggered by a library load or a process action, as this will guide the focus of the investigation.
+- Investigate the specific DLL path involved in the alert, especially if it matches `?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*`, `\\Device\\Mup\\**`, or `\\\\*`, to identify any unauthorized or unexpected files.
+- Use Osquery to list all DLLs loaded by `promecefpluginhost.exe` to identify any anomalies. Example query: `SELECT path FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE name = 'promecefpluginhost.exe';`
+- Examine the network connections of `promecefpluginhost.exe` to identify any unusual or suspicious external communications that may indicate data exfiltration or command-and-control activity.
+- Correlate the alert with other security events or logs to identify any related activities or patterns, such as other processes or files accessed around the same time.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Check for any recent changes or updates to WPS Office that might have introduced vulnerabilities or been exploited by attackers.
+- Analyze the system for any other signs of compromise, such as unexpected registry changes, scheduled tasks, or startup items that could indicate persistence mechanisms.
+- Review historical data to determine if similar alerts have been triggered in the past, which could indicate a recurring issue or ongoing attack campaign.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they temporarily load libraries from network paths or temporary directories, which are common behaviors for some applications.
+- Network drives or shared folders accessed by WPS Office for legitimate purposes might be flagged, especially in environments where network resources are frequently used for document storage and collaboration.
+- Users can manage these false positives by creating exceptions for known safe directories or network paths that are regularly accessed by WPS Office, ensuring these paths are documented and monitored for any changes in behavior.
+- Regularly review and update the list of exceptions to accommodate new legitimate software or changes in network infrastructure, maintaining a balance between security and operational efficiency.
+- Consider implementing additional context checks, such as verifying the digital signature of loaded libraries, to differentiate between legitimate and potentially malicious activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to confirm the presence of malicious DLLs in the specified directories or network paths.
+- Utilize endpoint detection and response (EDR) tools to analyze the behavior of the promecefpluginhost.exe process and identify any additional malicious activities.
+- Remove any identified malicious DLLs and associated files from the system to prevent further execution.
+- Apply patches or updates to WPS Office to address vulnerabilities CVE-2024-7262 and CVE-2024-7263, ensuring the software is up to date.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process and library load events, focusing on suspicious paths and activities.
+- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging threats related to DLL hijacking.
+- Restore the system to its operational state by verifying the integrity of system files and ensuring no unauthorized changes have been made.
+- Harden the system by restricting write permissions to critical directories and implementing application whitelisting to prevent unauthorized DLL loads."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_mofcomp.toml b/rules/windows/execution_mofcomp.toml
index be4fb305278..89077b148fb 100644
--- a/rules/windows/execution_mofcomp.toml
+++ b/rules/windows/execution_mofcomp.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "m365_defender", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,48 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Mofcomp Activity
+
+Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and instances for Windows Management Instrumentation (WMI). Adversaries exploit this by creating malicious MOF files to manipulate WMI for persistence or execution. The detection rule identifies suspicious mofcomp.exe executions, excluding legitimate system processes, to flag potential misuse by attackers.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "mofcomp.exe" and verify the presence of suspicious arguments matching "*.mof".
+- Check the user ID associated with the process execution to ensure it is not "S-1-5-18", which corresponds to the Local System account, indicating potential misuse by a non-system user.
+- Investigate the parent process of "mofcomp.exe" to determine if it is "ScenarioEngine.exe" and verify if the arguments match any of the known legitimate paths, such as "*\\\\MSSQL\\\\Binn\\\\*.mof", to rule out false positives.
+- Examine the timeline of events leading up to the mofcomp.exe execution to identify any preceding suspicious activities or processes.
+- Utilize Osquery to gather additional context on the mofcomp.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'mofcomp.exe';` to retrieve details like process ID, parent process ID, and command line arguments.
+- Cross-reference the mofcomp.exe execution with recent changes in the WMI repository to identify any new or modified namespaces and classes.
+- Analyze the network activity of the host around the time of the mofcomp.exe execution to detect any unusual outbound connections that might indicate data exfiltration or command and control communication.
+- Review the security logs for any recent login attempts or privilege escalation activities that could be related to the mofcomp.exe execution.
+- Check for any scheduled tasks or WMI Event Subscriptions that might have been created or modified around the time of the alert to establish persistence.
+- Investigate other hosts within the same network segment for similar mofcomp.exe activity to determine if the threat is isolated or part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use mofcomp.exe for legitimate purposes, such as compiling MOF files for system management or configuration tasks. These activities can be mistaken for malicious behavior.
+- SQL Server installations: During the installation or maintenance of Microsoft SQL Server, mofcomp.exe may be executed to compile MOF files related to SQL Server components. This is a common and expected behavior.
+- ScenarioEngine.exe interactions: Processes initiated by ScenarioEngine.exe that involve MOF files in specific directories related to SQL Server or OLAP services are typically benign and should be excluded from alerts.
+- To manage false positives, users can create exceptions in the detection rule by specifying known benign parent processes or directories associated with legitimate MOF file compilations. This helps in reducing noise and focusing on truly suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any malicious MOF files and determine the scope of the compromise, focusing on WMI namespaces and classes.
+- Terminate any suspicious processes related to mofcomp.exe that are not part of legitimate system operations.
+- Remove any unauthorized MOF files and restore the WMI repository to a known good state using backups or system restore points.
+- Review and update security policies to restrict the execution of mofcomp.exe to only trusted administrators and processes.
+- Implement enhanced logging for WMI activities and mofcomp.exe executions to improve detection of future suspicious activities.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze related threat indicators.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited by similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update the incident response plan to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_posh_hacktool_authors.toml b/rules/windows/execution_posh_hacktool_authors.toml
index 40c31c3be42..86da75fd610 100644
--- a/rules/windows/execution_posh_hacktool_authors.toml
+++ b/rules/windows/execution_posh_hacktool_authors.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/08"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,50 @@ host.os.type:windows and event.category:process and
       "splinter_code"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential PowerShell HackTool Script by Author
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities to execute malicious scripts, often leveraging well-known offensive tools without altering author identifiers. The detection rule identifies these scripts by scanning for specific author names linked to popular hacking tools, thus flagging potential misuse of PowerShell for malicious activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific author name detected in the PowerShell script, as this can provide insight into the potential tool or script being used.
+- Examine the `powershell.file.script_block_text` field in the event logs to analyze the script content for any suspicious or malicious commands.
+- Check the `event.category:process` field to identify the process that executed the PowerShell script, including the parent process, to understand the context of execution.
+- Investigate the `host.os.type:windows` field to confirm the affected host and gather additional system information such as hostname, IP address, and user context.
+- Use Osquery to gather more information about the process and its parent process. Example query: `SELECT * FROM processes WHERE name = 'powershell.exe';`
+- Correlate the detected author name with known offensive tools and techniques to assess the potential impact and intent of the script.
+- Review recent login events and user activity on the affected host to identify any unauthorized access or anomalies around the time the script was executed.
+- Check for any network connections initiated by the PowerShell process to external IP addresses, which may indicate data exfiltration or command-and-control communication.
+- Analyze other security logs and alerts from the same timeframe to identify any related or supporting indicators of compromise.
+- Consult threat intelligence sources to determine if the detected author or script is associated with any known threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate security researchers or IT administrators may use PowerShell scripts authored by well-known security experts for educational purposes or internal security assessments, leading to false positives.
+- Organizations that conduct regular red team exercises might have authorized scripts containing these author identifiers, which could be mistakenly flagged as malicious.
+- PowerShell scripts used in penetration testing environments may include these author names, as they are often part of widely accepted testing frameworks.
+- To manage false positives, users can create exceptions for specific scripts or processes that are known to be safe and are used regularly within their environment.
+- Implementing a whitelist of approved scripts or author names that are recognized as non-threatening can help reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only trusted scripts are excluded from detection, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential malicious activity.
+- Conduct a thorough investigation of the PowerShell script to confirm if it is indeed malicious by analyzing the script content and its execution context.
+- Review system logs and PowerShell execution logs to identify any additional indicators of compromise or related activities.
+- If confirmed malicious, remove the script and any associated files or processes from the system.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed PowerShell execution logs and script block logging for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in the future.
+- Apply security patches and updates to the system and ensure that all software is up to date to mitigate vulnerabilities.
+- Educate users and administrators on the risks of using unverified scripts and the importance of maintaining security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_powershell_susp_args_via_winscript.toml b/rules/windows/execution_powershell_susp_args_via_winscript.toml
index 146ff0b2c9b..5a48be483a7 100644
--- a/rules/windows/execution_powershell_susp_args_via_winscript.toml
+++ b/rules/windows/execution_powershell_susp_args_via_winscript.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -98,6 +98,50 @@ process where host.os.type == "windows" and event.action == "start" and
    not (process.parent.name : "wscript.exe" and
         ?process.parent.args : "C:\\Program Files (x86)\\Telivy\\Telivy Agent\\telivy.js")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious PowerShell Execution via Windows Scripts
+
+Windows Script Host (WSH) allows scripts to be executed directly on Windows systems, often using cscript or wscript. Adversaries exploit this by launching PowerShell scripts from WSH to execute malicious payloads, leveraging PowerShell's powerful capabilities. The detection rule identifies such abuse by monitoring PowerShell processes initiated by WSH, focusing on suspicious command patterns and excluding known legitimate activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and parent process name, focusing on `powershell.exe`, `pwsh.exe`, `wscript.exe`, `cscript.exe`, and `mshta.exe`.
+- Examine the `process.command_line` field for suspicious patterns such as encoded commands, use of `Invoke-Expression`, or downloading scripts from external sources.
+- Check the `process.args_count` to determine if the command line arguments are unusually minimal, which might indicate obfuscation.
+- Investigate the parent process's command line (`process.parent.command_line`) to understand the context in which the PowerShell script was executed.
+- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes with their parent processes: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name IN ('powershell.exe', 'pwsh.exe') AND parent IN (SELECT pid FROM processes WHERE name IN ('wscript.exe', 'cscript.exe', 'mshta.exe'));`
+- Cross-reference the `process.args` with known legitimate activities to rule out false positives, especially those excluded in the detection rule.
+- Investigate network connections initiated by the suspicious PowerShell process to identify any external communications, using tools like Osquery: `SELECT * FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name IN ('powershell.exe', 'pwsh.exe'));`
+- Check for any file modifications or creations by the PowerShell process, which might indicate payload delivery or execution.
+- Review the system's event logs for any additional context or related activities around the time of the alert, focusing on security and application logs.
+- Correlate the findings with other alerts or logs from the same host or user to identify potential patterns or repeated suspicious behavior.
+
+### False positive analysis
+
+- Legitimate PowerShell commands often use non-shortened execution flags, which can trigger false positives. Users can manage these by excluding specific command patterns, such as those involving "-EncodedCommand" and "Import-Module", while ensuring they are paired with "-ExecutionPolicy" to filter out benign activities.
+- Third-party installation scripts, like those related to Microsoft System Center or WebLogic, may inadvertently match suspicious patterns. Users should identify and exclude these specific scripts by adding exceptions for known file paths or command line arguments.
+- Some enterprise applications, such as those involving network information gathering or ICMP probes, may execute PowerShell scripts in a manner that appears suspicious. Users can handle these by excluding the specific parent script names or arguments associated with these applications.
+- Scripts related to software updates or system management, such as those for Microsoft Office or AppxPackage management, might trigger alerts. Users should create exceptions for these known processes by specifying the exact command line patterns or arguments used.
+- Custom scripts or tools, like those for speed tests or KMS activation, may also be flagged. Users can manage these by excluding the specific URLs or script names involved, ensuring that only recognized and trusted scripts are allowed.
+- In cases where specific applications, such as Telivy Agent, use PowerShell in a controlled manner, users should exclude these by identifying the parent script or application path, ensuring that only legitimate instances are permitted.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the PowerShell script execution to determine the scope and intent of the activity, focusing on the command patterns identified in the detection rule.
+- Review and analyze logs from Windows Event Viewer, especially PowerShell and Script Block Logging, to gather more context on the execution and any related activities.
+- If malicious activity is confirmed, remove any identified malicious scripts or payloads from the system and ensure no persistence mechanisms are in place.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a larger attack campaign or if sensitive data is at risk.
+- Implement or enhance logging policies to include detailed PowerShell logging and Windows Script Host activity to improve future detection and investigation capabilities.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance visibility and detection of similar threats in the future.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
+- Educate users on the risks of executing unknown scripts and reinforce the importance of reporting suspicious activities to the IT department."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_scheduled_task_powershell_source.toml b/rules/windows/execution_scheduled_task_powershell_source.toml
index 443716555aa..366bc63be00 100644
--- a/rules/windows/execution_scheduled_task_powershell_source.toml
+++ b/rules/windows/execution_scheduled_task_powershell_source.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,49 @@ sequence by host.id, process.entity_id with maxspan = 5s
   (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")]
  [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not destination.address in ("127.0.0.1", "::1")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Outbound Scheduled Task Activity via PowerShell
+
+PowerShell is a powerful scripting language and automation framework in Windows environments, often used for task automation and configuration management. Adversaries may exploit PowerShell to create scheduled tasks for executing malicious payloads or conducting lateral movement. The detection rule identifies suspicious activity by monitoring PowerShell processes that load the Task Scheduler DLL and initiate outbound RPC connections, which may indicate unauthorized task scheduling for malicious purposes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host.id and process.entity_id associated with the suspicious PowerShell activity.
+- Check the timestamp of the alert to determine the exact time window of the activity and correlate it with any other suspicious events on the same host.
+- Investigate the specific PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) that loaded the taskschd.dll by examining the process command line arguments and parent process to understand the context of execution.
+- Analyze the network connection details, focusing on the destination port 135, to identify the target system of the outbound RPC connection and verify if it is a legitimate communication.
+- Use Osquery to list all scheduled tasks on the host to identify any newly created or modified tasks around the time of the alert. Example query: `SELECT * FROM scheduled_tasks WHERE name LIKE '%task%' AND last_run_time > 'YYYY-MM-DD HH:MM:SS';`
+- Cross-reference the destination.address with known internal IP addresses to determine if the connection was made to a trusted or expected endpoint.
+- Examine the user account under which the PowerShell process was executed to assess if it has the necessary privileges to create scheduled tasks and if the activity aligns with the user's typical behavior.
+- Review recent login events on the host to identify any unusual or unauthorized access that might have preceded the PowerShell activity.
+- Check for any other alerts or logs related to the same host or user account to identify patterns or additional indicators of compromise.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, particularly those involving scheduled tasks and PowerShell exploitation.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often use PowerShell to automate routine tasks, which may involve loading the Task Scheduler DLL and making outbound RPC connections. To manage this, users can create exceptions for known administrative scripts or processes by whitelisting specific script paths or process hashes.
+- Software updates and installations: Some software update mechanisms or installation processes may use PowerShell to schedule tasks for updates, triggering the detection rule. Users can handle these by identifying and excluding specific update processes or trusted software vendors from the rule.
+- Monitoring and management tools: Certain IT management or monitoring tools may use PowerShell to schedule tasks for system checks or data collection. Users should review and whitelist these tools by verifying their legitimacy and adding them to an exclusion list based on process names or network addresses.
+- Development and testing environments: Developers may use PowerShell scripts to test scheduled tasks or network connections in a controlled environment. To prevent false positives, users can exclude specific development machines or IP ranges from the detection rule.
+- Backup and recovery operations: Backup solutions might use PowerShell to schedule tasks for regular data backups, which could be mistaken for suspicious activity. Users can manage this by identifying backup processes and excluding them from the rule based on known backup software signatures or network patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on recent scheduled tasks and PowerShell activity.
+- Terminate any suspicious PowerShell processes and remove unauthorized scheduled tasks identified during the investigation.
+- Review and analyze logs from the affected system and any connected systems to trace the origin and timeline of the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed PowerShell activity and scheduled task creation events for future monitoring.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system from a known good backup to ensure all malicious changes are removed and the system is returned to a secure operational state.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the adversary.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing application whitelisting to prevent unauthorized PowerShell execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_suspicious_cmd_wmi.toml b/rules/windows/execution_suspicious_cmd_wmi.toml
index 1e55aa7ab0d..11c924cccb7 100644
--- a/rules/windows/execution_suspicious_cmd_wmi.toml
+++ b/rules/windows/execution_suspicious_cmd_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,54 @@ process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "WmiPrvSE.exe" and process.name : "cmd.exe" and
  process.args : "\\\\127.0.0.1\\*" and process.args : ("2>&1", "1>")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Cmd Execution via WMI
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing commands remotely, often using the command prompt (cmd.exe). The detection rule identifies such activity by monitoring for cmd.exe processes initiated by WMI, especially those with arguments indicating potential redirection or network access, signaling possible malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of cmd.exe execution initiated by WmiPrvSE.exe, focusing on the process arguments, especially those indicating network access or redirection (e.g., "\\\\\\\\127.0.0.1\\\\*", "2>&1", "1>").
+- Check the event logs on the affected host for any additional context around the time of the alert, particularly looking for other WMI-related activities or unusual process creations.
+- Investigate the parent process WmiPrvSE.exe to determine if it was started by a legitimate user or process, and verify its command line arguments and execution history.
+- Use Osquery to gather more information about the cmd.exe process. For example, run the following query to list all processes with their parent process IDs and command line arguments:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'cmd.exe';
+  ```
+- Examine network connections on the host to identify any suspicious outbound connections that may correlate with the cmd.exe execution, using tools like netstat or Osquery:
+  ```sql
+  SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'cmd.exe');
+  ```
+- Correlate the alert with other security events or alerts in your environment to identify if this activity is part of a broader attack pattern or campaign.
+- Check for any recent changes in user accounts or permissions on the affected host that could indicate unauthorized access or privilege escalation.
+- Investigate the user account associated with the WMI activity to determine if it has been compromised or is being misused.
+- Review any recent software installations or updates on the host that could have introduced vulnerabilities or backdoors exploited by the adversary.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) of specific threat actors or malware families.
+
+### False positive analysis
+
+- Scheduled administrative tasks: Routine administrative scripts executed via WMI for system maintenance or updates may trigger this rule. Users can create exceptions for known scripts or scheduled tasks by identifying their specific command patterns and excluding them from the detection criteria.
+- Monitoring and management tools: Some legitimate monitoring or management software may use WMI to execute commands remotely, which could be flagged as suspicious. Users should identify these tools and whitelist their processes or specific command arguments to prevent false alerts.
+- Internal IT operations: IT departments may use WMI for legitimate remote command execution as part of their daily operations. Users should document these operations and adjust the detection rule to exclude known internal IP addresses or specific command patterns associated with these activities.
+- Automated scripts: Automated scripts that perform network diagnostics or system checks might use WMI and cmd.exe, leading to false positives. Users can refine the detection rule by excluding specific script names or command arguments that are consistently used in these benign operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Verify the legitimacy of the WMI activity by checking the source and context of the command execution.
+- Conduct a thorough investigation of the cmd.exe process and its arguments to determine if the activity is malicious.
+- Review recent WMI activity logs to identify any other suspicious or unauthorized actions.
+- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Implement enhanced logging policies to capture detailed WMI and cmd.exe activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor behaviors and tactics.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Apply security hardening measures, such as restricting WMI access to authorized users and systems, to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
index dc17bde0562..80cebecba22 100644
--- a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
+++ b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,48 @@ any where host.os.type == "windows" and
   process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE") and
   (?dll.name : "wmiutils.dll" or file.name : "wmiutils.dll")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious WMI Image Load from MS Office
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute code stealthily, bypassing traditional security measures by spawning processes indirectly. The detection rule identifies unusual loading of the `wmiutils.dll` library by Microsoft Office applications, signaling potential misuse of WMI for malicious activities. This rule focuses on monitoring specific Office processes for suspicious library loads, which may indicate adversarial attempts to execute code covertly.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `wmiutils.dll` being loaded by one of the specified Microsoft Office processes (`WINWORD.EXE`, `EXCEL.EXE`, `POWERPNT.EXE`, `MSPUB.EXE`, `MSACCESS.EXE`).
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities on the system around the same time.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Examine the parent process of the Office application to identify if it was launched by a legitimate user action or another process that might indicate malicious activity.
+- Use Osquery to gather additional context about the process and DLL load. Example query: `SELECT * FROM processes WHERE name IN ('WINWORD.EXE', 'EXCEL.EXE', 'POWERPNT.EXE', 'MSPUB.EXE', 'MSACCESS.EXE') AND pid IN (SELECT pid FROM process_open_sockets WHERE remote_address IS NOT NULL);`
+- Analyze network connections established by the Office process to identify any suspicious or unexpected external communications.
+- Review recent changes to the system, such as new software installations or updates, that might explain the unusual DLL load.
+- Check for any other security alerts or logs that might indicate a broader attack pattern or campaign targeting the system or network.
+- Investigate the system for any signs of persistence mechanisms that might have been established by an adversary using WMI or other techniques.
+- Consult threat intelligence sources to determine if there are known campaigns or threat actors that utilize similar techniques involving WMI and Office applications.
+
+### False positive analysis
+
+- Legitimate software updates or plugins for Microsoft Office applications may load `wmiutils.dll` as part of their normal operation, leading to false positives. Users should verify the source and purpose of the update or plugin to determine if it is benign.
+- Some enterprise environments use custom scripts or automation tools that leverage WMI for legitimate administrative tasks, which might trigger this rule. Users can create exceptions for known scripts or tools by excluding specific process hashes or command lines associated with these tasks.
+- Security software or monitoring tools that integrate with Microsoft Office for enhanced protection or data analysis might also load `wmiutils.dll` as part of their functionality. Users should confirm the legitimacy of such software and consider excluding it from the rule if it is verified as safe.
+- To manage false positives, users can implement a whitelist of known safe applications or processes that are allowed to load `wmiutils.dll`, ensuring that only unexpected or unknown instances trigger alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm the presence of malicious activity by analyzing the process tree and any associated network connections.
+- Terminate any suspicious processes that are identified as part of the malicious activity, particularly those involving WMI and Microsoft Office applications.
+- Review and collect relevant logs, including Windows Event Logs and security logs, to gather evidence and understand the scope of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement or enhance logging policies to ensure detailed monitoring of WMI activities and Microsoft Office processes, focusing on unusual DLL loads.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and conducting a full system scan.
+- Harden the system by disabling unnecessary WMI services and applying least privilege principles to limit the execution of unauthorized scripts and processes.
+- Educate users on recognizing phishing attempts and suspicious activities, as these are common vectors for initiating such attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_via_mmc_console_file_unusual_path.toml b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
index 5e8bd3c2454..34768aaed32 100644
--- a/rules/windows/execution_via_mmc_console_file_unusual_path.toml
+++ b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,49 @@ process where host.os.type == "windows" and event.type == "start" and
         "?:\\Program Files (x86)\\*.msc"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft Management Console File from Unusual Path
+
+Microsoft Management Console (MMC) is a Windows utility that provides a framework for system management tools. Adversaries may exploit MMC by executing .msc files from non-standard directories to bypass security controls. The detection rule identifies such anomalies by monitoring the execution of MMC files from paths outside trusted directories, flagging potential unauthorized access or execution attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific .msc file and the unusual path from which it was executed.
+- Verify the legitimacy of the process by checking the user account associated with the execution and correlating it with known user activity.
+- Examine the parent process of the mmc.exe execution to determine if it was initiated by a legitimate or suspicious process.
+- Use Osquery to list all running processes and their command-line arguments to identify any other unusual or unauthorized executions. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE name = 'mmc.exe';`
+- Investigate the file path of the .msc file to determine if it is a known or expected location for such files. Check for any recent changes or modifications to the directory.
+- Check the file hash of the .msc file against known good hashes or threat intelligence databases to identify any known malicious files.
+- Review recent system logs and security events for any other suspicious activities or anomalies around the time of the alert.
+- Analyze network traffic from the host to identify any unusual outbound connections that may indicate data exfiltration or command and control activity.
+- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or coordinated attacks.
+- Consult with the user or system owner to verify if the execution was intentional and authorized, and gather any additional context or information.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may execute .msc files from non-standard directories for legitimate purposes, such as custom scripts or tools stored in user-specific directories. To manage these, users can create exceptions for known administrative accounts or specific directories frequently used for legitimate tasks.
+- Software installations and updates: Some software installations or updates might temporarily execute .msc files from non-standard paths. Users can handle these by monitoring installation or update activities and creating temporary exceptions during these periods.
+- Development and testing environments: Developers or IT staff might run .msc files from unusual paths during testing or development phases. To reduce false positives, users can exclude specific development machines or user accounts from the rule.
+- Third-party management tools: Certain third-party management tools might use .msc files from non-standard locations. Users should identify these tools and add their execution paths to the exception list to prevent false alerts.
+- User-specific customizations: Advanced users might create custom .msc files for personal use, stored in non-standard directories. Users can manage these by allowing exceptions for specific user profiles or directories known to contain custom .msc files.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the execution of .msc files from untrusted paths.
+- Review system logs and security alerts to gather evidence of the attack vector and any associated malicious activity.
+- Remove any unauthorized .msc files and related malicious software from the system.
+- Restore the system from a known good backup to ensure all malicious changes are reverted.
+- Update and patch the operating system and all installed software to mitigate known vulnerabilities.
+- Implement application whitelisting to restrict the execution of .msc files to trusted directories only.
+- Enhance logging and monitoring policies to include detailed process execution and file access events for early detection of similar threats.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_windows_cmd_shell_susp_args.toml b/rules/windows/execution_windows_cmd_shell_susp_args.toml
index d6bb9f17af1..24a9502453e 100644
--- a/rules/windows/execution_windows_cmd_shell_susp_args.toml
+++ b/rules/windows/execution_windows_cmd_shell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -104,6 +104,49 @@ process where host.os.type == "windows" and event.type == "start" and
   not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and 
   not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Windows Command Shell Arguments
+
+The Windows Command Shell (cmd.exe) is a critical component for executing commands and scripts. Adversaries exploit it to execute malicious scripts, download payloads, or manipulate system settings. The detection rule identifies unusual command-line arguments and patterns indicative of such abuse, while excluding known benign processes, to flag potential threats effectively.
+
+### Possible investigation steps
+
+- Review the full command line of the cmd.exe process to understand the context and intent of the suspicious arguments.
+- Check the parent process of cmd.exe to determine if it is a known benign process or if it might be part of a malicious chain of execution.
+- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Examine the network connections made by the host during the time of the alert to identify any suspicious outbound connections or data exfiltration attempts.
+- Use Osquery to list all running processes on the host to identify any other suspicious activities or processes. Example query: `SELECT name, path, cmdline FROM processes WHERE name = 'cmd.exe';`
+- Analyze the file system for any newly created or modified files that could be related to the suspicious command execution.
+- Check for any scheduled tasks or startup items that might have been created or modified to persist malicious activities.
+- Review the Windows Event Logs, particularly Security and System logs, for any additional indicators of compromise or related events.
+- Investigate any registry changes that might have been made by the cmd.exe process to alter system settings or establish persistence.
+- Correlate the alert with other security events or alerts from the same host or user to identify patterns or broader attack campaigns.
+
+### False positive analysis
+
+- The rule excludes processes with known benign parent executables such as Perl, Node.js, and PostgreSQL, which are often used in legitimate scripting and database operations. Users should ensure these paths are correctly specified to avoid unnecessary alerts.
+- Specific command-line patterns related to software like NetBeans, Citrix Secure Access Client, and npm installations are excluded to prevent false positives from common development and IT management tasks. Users should verify these patterns align with their environment's typical usage.
+- Processes originating from Spiceworks and other IT management tools are excluded to prevent alerts from routine network monitoring and management activities. Users can add similar exclusions for other trusted IT tools in their environment.
+- The rule excludes certain command-line arguments and parent processes associated with known benign applications like PRTG Network Monitor and Tripwire Agent. Users should review and update these exclusions based on the specific software versions and configurations in use.
+- Users can manage false positives by adding exceptions for specific command-line patterns or parent processes that are frequently observed in their environment but are known to be non-threatening. This can be done by updating the exclusion list with paths or patterns unique to their trusted applications.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation of the suspicious command-line activity to determine the scope and impact, using available logs and forensic tools.
+- Identify and terminate any malicious processes associated with the suspicious command-line arguments.
+- Remove any malicious files or scripts identified during the investigation from the affected system.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Restore the system from a clean backup if the integrity of the system is compromised beyond repair.
+- Implement enhanced logging policies to capture detailed command-line activity and integrate with a centralized logging solution for future analysis.
+- Review and update security policies and procedures to include detection and response to similar threats, leveraging MITRE ATT&CK framework for guidance.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
+- Escalate the incident to the appropriate internal or external cybersecurity team if the threat is beyond the organization's capability to handle."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_windows_powershell_susp_args.toml b/rules/windows/execution_windows_powershell_susp_args.toml
index 190e0bee76c..2f71d9313bd 100644
--- a/rules/windows/execution_windows_powershell_susp_args.toml
+++ b/rules/windows/execution_windows_powershell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -106,6 +106,49 @@ process where host.os.type == "windows" and event.type == "start" and
        process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*"))
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Windows Powershell Arguments
+
+PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, which are common in malware activities.
+
+### Possible investigation steps
+
+- Review the full command line captured in the alert to understand the context and intent of the PowerShell execution, focusing on any encoded or obfuscated segments.
+- Check the parent process of the PowerShell execution to determine if it was launched by a legitimate process like explorer.exe or cmd.exe, which might indicate user interaction, or by a suspicious process.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Examine the network connections made by the host around the time of the alert to identify any suspicious outbound connections, especially those involving known malicious IPs or domains.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%encodedCommand%' OR cmdline LIKE '%Invoke-webrequest%' OR cmdline LIKE '%WebClient%' OR cmdline LIKE '%Reflection.Assembly%';`
+- Analyze any downloaded files or payloads referenced in the command line for malicious content using a sandbox or antivirus tools.
+- Correlate the alert with other security events or logs from the same host or user to identify patterns or repeated suspicious activities.
+- Check for any recent changes to the system, such as new scheduled tasks, services, or startup items, that might indicate persistence mechanisms.
+- Review the system's security patches and updates to ensure it is not vulnerable to known exploits that could have been leveraged in the attack.
+- Investigate any additional alerts or anomalies from the same timeframe to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts: PowerShell is commonly used by IT administrators for legitimate automation tasks, which may include encoded commands or downloading files. Users should review the context of the script execution and consider excluding known administrative scripts from the detection rule.
+- Software installations and updates: Some software installations or updates may use PowerShell scripts with arguments that match suspicious patterns. Users can create exceptions for specific software processes or installation paths that are verified as safe.
+- Security tools and monitoring solutions: Certain security tools or monitoring solutions may use PowerShell to perform checks or gather system information, potentially triggering the rule. Users should identify and exclude these tools from the detection criteria.
+- Development and testing environments: Developers and testers might use PowerShell to simulate attacks or test scripts, which could be flagged as suspicious. Users should consider excluding processes running in designated development or testing environments.
+- Automated backup or maintenance scripts: Scheduled tasks or automated scripts for backup and maintenance may use PowerShell with arguments that appear suspicious. Users should verify these scripts and exclude them if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation of the PowerShell command line arguments and scripts executed to identify the scope and intent of the activity.
+- Review and analyze logs from the affected system and any associated systems to trace the origin and timeline of the suspicious activity.
+- Remove any identified malicious scripts or payloads from the system and ensure that no unauthorized changes have been made to system configurations.
+- Update antivirus and endpoint protection solutions to the latest definitions and perform a full system scan to detect and remove any remaining threats.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a larger attack campaign or if sensitive data may have been compromised.
+- Implement enhanced logging policies to capture detailed PowerShell execution events, including command line arguments and script block logging.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and correlation of suspicious activities.
+- Restore the system to its operational state by applying verified clean backups and ensuring all security patches and updates are applied.
+- Harden the system by disabling unnecessary PowerShell features, enforcing script execution policies, and implementing application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/exfiltration_smb_rare_destination.toml b/rules/windows/exfiltration_smb_rare_destination.toml
index 4d605159cf9..0e2bd02b538 100644
--- a/rules/windows/exfiltration_smb_rare_destination.toml
+++ b/rules/windows/exfiltration_smb_rare_destination.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -79,6 +79,50 @@ event.category:network and host.os.type:windows and process.pid:4 and
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Rare SMB Connection to the Internet
+
+Server Message Block (SMB) is a protocol used for sharing files and printers within local networks. Adversaries exploit SMB to exfiltrate data by injecting rogue paths to capture NTLM credentials. The detection rule identifies unusual SMB traffic from internal IPs to external networks, flagging potential exfiltration attempts by monitoring specific ports and excluding known safe IP ranges.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the source IP address falls within the internal IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and the destination IP is external.
+- Verify the destination port is either 139 or 445, as these are the ports associated with SMB traffic, to ensure the alert is relevant.
+- Check the process ID (PID) 4 on the host, which typically corresponds to the System process, to confirm the legitimacy of the SMB connection.
+- Use network logs to trace the SMB connection path and identify any unusual patterns or repeated attempts to connect to the same external IP.
+- Investigate the external IP address to determine if it is associated with known malicious activity or if it belongs to a legitimate service.
+- Utilize Osquery to gather more information about the host's network connections. Example query: `SELECT * FROM process_open_sockets WHERE pid = 4 AND remote_port IN (139, 445);` to identify all active connections from the System process.
+- Examine recent changes or updates on the host that might have triggered the unusual SMB connection, such as new software installations or configuration changes.
+- Review user activity logs on the host to identify any suspicious behavior or unauthorized access attempts around the time of the alert.
+- Correlate the alert with other security events or alerts in the network to determine if this is part of a larger attack pattern.
+- Consult threat intelligence sources to check for any recent campaigns or tactics involving SMB exfiltration that match the observed behavior.
+
+### False positive analysis
+
+- Known false positives may include legitimate SMB traffic to external cloud services or remote offices that are part of the organization's infrastructure but not included in the safe IP ranges.
+- Regularly scheduled backups or file synchronization tasks that use SMB to connect to external storage solutions can trigger alerts.
+- Users can handle these false positives by identifying and documenting legitimate external SMB connections and updating the detection rule to exclude these specific IP addresses or IP ranges.
+- Implementing a whitelist of known and trusted external IPs or domains that require SMB access can help reduce false positives.
+- Monitoring and reviewing the frequency and context of flagged connections can assist in distinguishing between legitimate and suspicious activities.
+- Collaborate with network and security teams to ensure that any changes in infrastructure or external partnerships are reflected in the detection rule's exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the SMB connection, including reviewing logs and network traffic for any signs of unauthorized access or data transfer.
+- Reset credentials for any accounts that may have been compromised, particularly those using NTLM authentication.
+- Remove any unauthorized SMB shares or rogue UNC paths identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed network traffic and SMB activity, ensuring that logs are stored securely and monitored regularly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify that all security controls are functioning correctly.
+- Conduct a post-incident review to identify any gaps in the security posture and update incident response plans accordingly.
+- Implement hardening measures such as disabling SMBv1, enforcing strong password policies, and using network segmentation to limit the exposure of critical systems."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
index 9833b3ed3e6..362aa1dfbce 100644
--- a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
+++ b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/08"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,51 @@ index = ["logs-endpoint.events.process-*", "logs-endpoint.events.file-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious HTML File Creation"
-note = "This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence."
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious HTML File Creation
+
+HTML files, often used for web content, can be exploited by adversaries to smuggle malicious payloads past security filters. Attackers may embed harmful data within HTML files, leveraging browsers to execute these files. The detection rule identifies such threats by monitoring HTML file creation with high entropy or large size in common directories, coupled with browser processes accessing these files. This approach helps pinpoint potential phishing attempts or unauthorized data transfers.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file extension and size, ensuring it matches the criteria of high entropy or large size as specified in the detection rule.
+- Check the file path to verify if it is located in common download or temporary directories, such as `?:\\Users\\*\\Downloads\\*` or `?:\\Users\\*\\AppData\\Local\\Temp\\*`.
+- Investigate the user account associated with the file creation event to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the process details to identify which browser was used to open the HTML file, focusing on processes like `chrome.exe`, `msedge.exe`, or `firefox.exe`.
+- Analyze the process arguments to confirm if the browser was launched with a single argument or specific URL, which may indicate an attempt to execute the HTML file directly.
+- Utilize Osquery to gather additional context about the file and process. For example, run the following query to list recent file modifications in the user's Downloads directory: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%' ORDER BY mtime DESC LIMIT 10;`.
+- Cross-reference the file hash with threat intelligence databases to check for known malicious indicators.
+- Review recent email activity for the user to identify any potential phishing emails that may have delivered the suspicious HTML file.
+- Check for any network connections initiated by the browser process after opening the HTML file, which could indicate data exfiltration or communication with a command and control server.
+- Investigate any other alerts or logs related to the same user or system to identify patterns or additional suspicious activities that may correlate with the HTML file creation event.
+
+### False positive analysis
+
+- Legitimate software updates or installations may create large HTML files in temporary directories, triggering the rule. Users can exclude specific software update processes by identifying their unique file paths or process names.
+- Some web development tools or environments might generate high entropy HTML files during normal operations. Users should monitor and whitelist these tools if they are known and trusted within their environment.
+- Automated scripts or applications that download or generate HTML files for reporting purposes could be flagged. Users can create exceptions for these scripts by specifying their file paths or associated process names.
+- Browsers opening HTML files from email clients or collaboration tools might be misidentified as suspicious. Users should consider excluding known safe email client directories or specific browser processes when they are part of a trusted workflow.
+- Large HTML files used for legitimate data visualization or documentation purposes may be mistakenly flagged. Users can manage this by excluding specific directories or file names associated with these legitimate files.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the HTML file to determine if it contains malicious payloads, using tools like antivirus or sandbox analysis.
+- Review browser history and recent downloads to identify any suspicious activity or unauthorized access attempts.
+- Remove any identified malicious files and clean the system using updated antivirus or anti-malware software.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Implement enhanced logging policies to capture detailed file creation and process execution events for future investigations.
+- Integrate security solutions with threat intelligence platforms to improve detection capabilities and response times.
+- Educate users on recognizing phishing attempts and safe browsing practices to reduce the risk of future incidents.
+- Apply security patches and updates to browsers and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
+
+This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence."""
 risk_score = 47
 rule_id = "f0493cb4-9b15-43a9-9359-68c23a7f2cf3"
 setup = """## Setup
diff --git a/rules/windows/initial_access_execution_from_inetcache.toml b/rules/windows/initial_access_execution_from_inetcache.toml
index 78d9de0f304..287dd3ba901 100644
--- a/rules/windows/initial_access_execution_from_inetcache.toml
+++ b/rules/windows/initial_access_execution_from_inetcache.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,49 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Execution from INET Cache
+
+The INetCache folder stores temporary internet files, which can be exploited by adversaries to execute malicious payloads. Attackers may use this cache to deliver harmful content via web interactions, often leveraging phishing techniques. The detection rule identifies suspicious processes initiated from this cache, especially those spawned by common file explorers, signaling potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments, focusing on the `process.parent.name` field to verify if the process was spawned by `explorer.exe`, `winrar.exe`, `7zFM.exe`, or `Bandizip.exe`.
+- Examine the `process.args` field to identify the specific file path within the INetCache that was executed, noting any unusual or suspicious file names or extensions.
+- Check the `process.executable` field to determine the exact executable path and verify if it matches known legitimate software or if it appears suspicious.
+- Use Osquery to list all files in the INetCache directory for the affected user to identify any other potentially malicious files. Example query: `SELECT path, filename, size, atime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Local\\\\Microsoft\\\\Windows\\\\INetCache\\\\IE\\\\%';`
+- Investigate the parent process tree to understand the sequence of events leading to the execution, focusing on any unusual or unexpected parent-child process relationships.
+- Correlate the event timestamp with user activity logs to determine if the execution aligns with legitimate user actions or if it occurred during a period of inactivity.
+- Analyze network logs for any outbound connections made by the suspicious process to identify potential command and control communication or data exfiltration attempts.
+- Review email logs or web browsing history for the affected user to identify any recent phishing attempts or suspicious downloads that could have led to the execution.
+- Check for any recent changes or anomalies in the user's system configuration or installed software that could indicate compromise or unauthorized access.
+- Consult threat intelligence sources to determine if the identified file or behavior is associated with known malware or attack campaigns, providing additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they temporarily store files in the INetCache folder during the process. Users should verify the source and purpose of the process to determine if it is benign.
+- Web browsers or file explorers might cache legitimate files in the INetCache folder, leading to false positives when these files are executed. Users can create exceptions for known safe processes or applications that frequently use this cache.
+- Automated scripts or tools that interact with web content and store temporary files in the INetCache folder could be flagged. Users should review these scripts and whitelist them if they are part of routine operations.
+- Some enterprise applications may use the INetCache folder for temporary storage during normal operations. Users should identify these applications and configure the rule to exclude them from triggering alerts.
+- To manage false positives, users can adjust the detection rule to exclude specific processes or paths that are consistently identified as non-threatening, ensuring that only genuine threats are flagged.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to identify the source of the suspicious execution, focusing on recent web interactions and email communications.
+- Terminate any malicious processes identified as originating from the INetCache folder.
+- Remove any malicious files found in the INetCache directory and perform a full antivirus scan on the system.
+- Review and analyze logs from the affected system to identify any additional indicators of compromise or lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger campaign or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds to improve detection capabilities and correlate with known phishing and initial access techniques.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security software is up to date.
+- Harden the system by implementing security best practices, such as disabling unnecessary services, enforcing strong password policies, and educating users on recognizing phishing attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_from_removable_media.toml b/rules/windows/initial_access_execution_from_removable_media.toml
index 495c84b76fd..a3d134b3775 100644
--- a/rules/windows/initial_access_execution_from_removable_media.toml
+++ b/rules/windows/initial_access_execution_from_removable_media.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,49 @@ sequence by process.entity_id with maxspan=5m
   not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")]
  [network where host.os.type == "windows" and event.action == "connection_attempted"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution from a Removable Media with Network Connection
+
+Removable media, like USB drives, facilitate data transfer but can be exploited by adversaries to introduce malware into isolated systems. Attackers may leverage autorun features to execute malicious code upon media insertion. The detection rule identifies suspicious process executions from USBs, especially those lacking valid code signatures, and correlates them with network connection attempts, signaling potential unauthorized access or data exfiltration efforts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process entity ID and timestamp of the suspicious execution from the removable media.
+- Verify the process details, including the process name, path, and command line arguments, to determine if it aligns with known legitimate applications or if it appears suspicious.
+- Check the code signature status of the process to confirm if it is indeed untrusted or unsigned, as indicated by the alert.
+- Investigate the USB device details, such as the device bus type and product ID, to identify the specific removable media used and its history of usage on the system.
+- Correlate the process execution with network connection attempts by examining the network event details, including the destination IP addresses and ports, to identify any unusual or unauthorized connections.
+- Use Osquery to gather additional context on the process and USB device. For example, run the following query to list processes executed from USB devices: `SELECT * FROM processes WHERE path LIKE 'E:\\\\%' OR path LIKE 'F:\\\\%';`
+- Analyze the user account associated with the process execution to determine if it aligns with expected user behavior or if it indicates potential compromise.
+- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may be related.
+- Investigate the history of the USB device on the system by checking for previous insertions and any other processes executed from it.
+- Cross-reference the alert with threat intelligence sources to determine if the process or network activity matches known indicators of compromise or attack patterns.
+
+### False positive analysis
+
+- Legitimate software installations or updates from USB drives may trigger the rule if the software lacks a valid code signature. Users can create exceptions for known software vendors or specific USB devices used for updates.
+- IT personnel using USB drives for system maintenance or diagnostics might cause false positives. To manage this, organizations can whitelist specific USB devices or processes associated with IT operations.
+- Educational or training environments where software is frequently distributed via USB may also generate alerts. In such cases, users can exclude specific processes or devices commonly used in these settings.
+- Developers or testers using unsigned applications from USB drives for testing purposes might inadvertently trigger the rule. Exceptions can be made for specific development environments or devices.
+- In environments where USB devices are used for legitimate data transfer between isolated systems, users can establish a list of trusted devices or processes to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on the processes executed from the removable media and any network connections attempted.
+- Quarantine the removable media to prevent further use and analyze it for malware or unauthorized files.
+- Remove any identified malicious software from the affected system using trusted antivirus or anti-malware tools.
+- Review and update the system's autorun settings to disable automatic execution of programs from removable media.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems may be affected.
+- Implement enhanced logging policies to capture detailed information on process executions and network connections, particularly those involving removable media.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors or campaigns, leveraging MITRE ATT&CK framework for context.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
+- Strengthen security measures by enforcing strict access controls, conducting regular security awareness training, and implementing endpoint protection solutions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_remote_via_msiexec.toml b/rules/windows/initial_access_execution_remote_via_msiexec.toml
index 054e39cfd39..d20c7a1b069 100644
--- a/rules/windows/initial_access_execution_remote_via_msiexec.toml
+++ b/rules/windows/initial_access_execution_remote_via_msiexec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,53 @@ sequence with maxspan=1m
   not (process.name : "rundll32.exe" and process.args : "printui.dll,PrintUIEntry")
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Remote File Execution via MSIEXEC
+
+MSIEXEC is a Windows utility for installing and managing software packages. Adversaries may exploit it to execute remote files, potentially bypassing security controls. The detection rule identifies suspicious MSIEXEC activity by monitoring for specific command-line arguments, network connections, and unusual child processes, filtering out known legitimate behaviors to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific command-line arguments used with `msiexec.exe`, focusing on the presence of the `/V` flag, which indicates verbose logging and potential remote execution.
+- Examine the network connections associated with `msiexec.exe` to identify any unusual or unauthorized remote IP addresses or domains that the process attempted to connect to.
+- Investigate the parent process of `msiexec.exe` to determine if it was launched by a legitimate process or if it was spawned by a suspicious or unexpected parent.
+- Check the user account associated with the `msiexec.exe` process, focusing on user IDs like "S-1-5-21-*" and "S-1-5-12-1-*", to verify if the activity aligns with normal user behavior or if it indicates potential compromise.
+- Analyze the child processes spawned by `msiexec.exe` to identify any unusual or unauthorized executables, especially those not located in typical directories like `?:\\Windows\\System32` or `?:\\Program Files`.
+- Verify the code signature of any executables involved in the alert to ensure they are from trusted sources, paying particular attention to any discrepancies in the signature's subject name or trust status.
+- Use Osquery to gather additional context on the system. For example, run the following query to list recent processes executed by `msiexec.exe`:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'msiexec.exe');
+  ```
+- Cross-reference the alert with any recent phishing attempts or suspicious emails received by the user to determine if the `msiexec.exe` activity could be linked to a phishing attack.
+- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that might correlate with the `msiexec.exe` execution.
+- Consult threat intelligence sources to check if the IP addresses or domains contacted by `msiexec.exe` are associated with known malicious activities or threat actors.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they use msiexec.exe with remote packages, especially in enterprise environments where software deployment is automated.
+- Network administrators using msiexec.exe for remote installations across the network might be flagged; consider excluding these activities by identifying the specific network paths or IP addresses used.
+- Some IT management tools and scripts that automate software installations could mimic the behavior of adversaries; these should be reviewed and potentially excluded by process name or signature.
+- Exclude processes with trusted code signatures from known vendors, such as Citrix Systems, Inc., to reduce false positives from legitimate software.
+- Regularly review and update the list of excluded executables and paths to ensure that new legitimate software is not mistakenly flagged.
+- Consider the context of the user ID and integrity level; system administrators or automated service accounts might frequently trigger this rule during routine operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the MSIEXEC command and the source of the remote package by reviewing logs and network connections.
+- Terminate any suspicious processes initiated by msiexec.exe that are not part of known legitimate software installations.
+- Conduct a thorough investigation to identify any additional compromised systems or accounts, focusing on the MITRE ATT&CK tactic of Initial Access and technique of Phishing.
+- Remove any unauthorized software or files installed via the suspicious MSIEXEC activity and restore affected files from backups if necessary.
+- Update and apply security patches to the affected system to mitigate vulnerabilities that may have been exploited.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that MSIEXEC usage is closely monitored.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Educate users on recognizing phishing attempts and the importance of reporting suspicious emails or activities to reduce the risk of initial access through social engineering.
+- Review and strengthen endpoint protection configurations, including application whitelisting and execution restrictions, to prevent unauthorized use of system utilities like msiexec.exe."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_via_office_addins.toml b/rules/windows/initial_access_execution_via_office_addins.toml
index 4faad5dfbcf..2551c4201aa 100644
--- a/rules/windows/initial_access_execution_via_office_addins.toml
+++ b/rules/windows/initial_access_execution_via_office_addins.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -81,6 +81,52 @@ process where
          process.parent.args : "?:\\WINDOWS\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc") and
     not (process.name : "VSTOInstaller.exe" and process.args : "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Execution via Microsoft Office Add-Ins
+
+Microsoft Office Add-Ins enhance productivity by allowing custom functionalities within Office applications. However, adversaries can exploit this by embedding malicious code in add-ins, often delivered via phishing. The detection rule identifies unusual execution patterns, such as Office apps launching add-ins from atypical paths or with unexpected parent processes, signaling potential malicious activity. It filters out known benign processes to reduce false positives, focusing on genuine threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Microsoft Office application involved (e.g., WINWORD.EXE, EXCEL.EXE) and the suspicious add-in file path or parent process.
+- Examine the process arguments to determine the type of add-in file executed (e.g., .wll, .xll, .ppa) and verify if the path is listed as suspicious in the detection rule.
+- Check the parent process name to see if it matches any unusual or suspicious processes such as cmd.exe or powershell.exe, which could indicate script-based execution.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Utilize Osquery to gather additional context about the process execution. For example, run the following query to list recent processes executed by the user:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'target_username');
+  ```
+- Correlate the process execution time with any known phishing attempts or suspicious email activity targeting the user to assess potential initial access vectors.
+- Analyze network logs to identify any outbound connections made by the process, especially to external IPs or domains, which could indicate data exfiltration or command-and-control communication.
+- Review system logs for any additional suspicious activities or errors around the time of the alert, such as failed logins or unusual file access patterns.
+- Check for any recent changes or installations on the system that could have introduced the suspicious add-in, such as new software installations or updates.
+- Consult threat intelligence sources to determine if the identified add-in file or associated domains/IPs are known to be associated with malicious activity or campaigns.
+
+### False positive analysis
+
+- The rule may trigger on legitimate installations or updates of Microsoft Office Add-Ins, particularly those involving Logitech software, as these processes can mimic suspicious behavior. Users can manage this by excluding processes with arguments like "*.vsto" and parent executables from Logitech directories, such as "?:\\\\Program Files\\\\Logitech\\\\LogiOptions\\\\PlugInInstallerUtility*.exe".
+- Another potential false positive involves the VSTOInstaller.exe process when it is used for legitimate purposes, such as uninstalling add-ins. Users can exclude processes with arguments like "/Uninstall" and the process name "VSTOInstaller.exe" to prevent unnecessary alerts.
+- The rule might also flag processes initiated by "rundll32.exe" with specific arguments related to Windows Installer temporary files. Users can exclude these by specifying the parent name "rundll32.exe" and parent arguments like "?:\\\\WINDOWS\\\\Installer\\\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc".
+- To avoid false positives related to the Sidekick add-in for Outlook, users can exclude the process name "VSTOInstaller.exe" with arguments pointing to "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto".
+- Users should regularly review and update their exclusion lists to ensure that only non-threatening behaviors are filtered out, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the suspicious Office Add-In by analyzing the file path, parent process, and any associated network activity.
+- Use endpoint detection and response (EDR) tools to identify and terminate any malicious processes or scripts running on the system.
+- Remove the malicious Office Add-In and any associated files from the system, ensuring that all remnants are deleted.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Update antivirus and anti-malware solutions to ensure they can detect and prevent similar threats in the future.
+- Implement logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds to enhance detection capabilities and stay informed about emerging threats.
+- Escalate the incident to the security operations center (SOC) or relevant team if the threat is part of a larger attack campaign.
+- Review and update security policies and user training programs to reduce the risk of phishing attacks and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
index 288d91f4f02..4ef622c631f 100644
--- a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
+++ b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funne
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,46 @@ type = "new_terms"
 query = '''
 event.category:"registry" and host.os.type:"windows" and registry.value:"FriendlyName" and registry.path:*USBSTOR*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Time Seen Removable Device
+
+Removable devices, like USB drives, are commonly used for data transfer. However, adversaries can exploit them for unauthorized data exfiltration or malware distribution. The detection rule monitors registry changes related to new removable devices on Windows systems, focusing on the device's friendly name. By identifying first-time-seen devices, analysts can spot potential threats linked to unauthorized access or data replication activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a new removable device by checking the `registry.value` field for the "FriendlyName" of the device.
+- Verify the `registry.path` field to ensure it includes "USBSTOR," indicating the device is a USB storage device.
+- Cross-reference the `host.os.type` field to confirm the operating system is Windows, as the rule is specific to Windows systems.
+- Check the event timestamp to determine when the device was first seen and correlate it with any other suspicious activities around the same time.
+- Investigate the user account associated with the event to determine if the user has a history of using removable devices or if this is unusual behavior.
+- Use Osquery to gather more information about the device. For example, run the following query to list all USB devices connected to the system: `SELECT * FROM usb_devices WHERE serial NOT IN (SELECT serial FROM usb_devices WHERE last_seen < (SELECT MAX(last_seen) FROM usb_devices) - 86400);`
+- Examine the system's recent file access logs to identify any files that may have been copied to or from the removable device.
+- Check for any other registry changes or system modifications that occurred around the same time as the device connection to identify potential malicious activity.
+- Review network logs for any unusual outbound traffic that might indicate data exfiltration attempts following the device's connection.
+- Consult with the user or system owner to verify if the device usage was authorized and legitimate, and gather any additional context about the device's purpose.
+
+### False positive analysis
+
+- Known false positives for the First Time Seen Removable Device rule include legitimate use cases such as employees using personal USB drives for work purposes, IT staff deploying new hardware, or routine backups involving external drives. These activities can trigger alerts despite being non-threatening.
+- To manage these false positives, users can create exceptions for specific devices by whitelisting their friendly names or serial numbers if they are frequently used and verified as safe. Additionally, implementing a policy to register and approve certain removable devices can help reduce unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential data exfiltration or further spread of malware.
+- Conduct a thorough investigation to identify the source and intent of the removable device usage, checking for any unauthorized data transfers or suspicious files.
+- Review and analyze registry modification events to confirm the presence of unauthorized or malicious activity linked to the newly seen removable device.
+- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system using trusted antivirus or anti-malware tools.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat level is beyond initial containment capabilities or if it involves sensitive data.
+- Implement enhanced logging policies to capture detailed events related to removable device usage, including file transfers and registry changes, for future investigations.
+- Integrate security solutions such as Data Loss Prevention (DLP) and Endpoint Detection and Response (EDR) to monitor and control data transfers to removable devices.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are correctly set.
+- Educate users on the risks associated with removable devices and enforce policies that restrict their use to authorized personnel only.
+- Apply hardening measures such as disabling USB ports where possible, or using endpoint management tools to control device access, in line with the MITRE ATT&CK framework's guidance on mitigating replication through removable media (T1091)."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
index bd42e3ff3ef..433b259a9f3 100644
--- a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
+++ b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -72,6 +72,49 @@ process where host.os.type == "windows" and event.type == "start" and
  not (process.name : "powershell.exe" and process.args : "-ExecutionPolicy" and process.args : "?:\\TeamCity\\buildAgent\\work\\*.ps1") and
  not (process.name : "cmd.exe" and process.args : "dir" and process.args : "/-c")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious JetBrains TeamCity Child Process
+
+JetBrains TeamCity is a continuous integration and deployment server used to automate software development processes. Adversaries may exploit vulnerabilities in TeamCity to execute unauthorized code, potentially spawning malicious child processes. The detection rule identifies unusual child processes initiated by TeamCity's Java executable, flagging potential exploitation attempts by monitoring for known suspicious executables and excluding benign operations.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific child process was spawned by the TeamCity Java executable and note the process name and path.
+- Verify the parent process by checking the path of the Java executable to ensure it matches one of the expected TeamCity paths: `?:\\TeamCity\\jre\\bin\\java.exe`, `?:\\Program Files\\TeamCity\\jre\\bin\\java.exe`, `?:\\Program Files (x86)\\TeamCity\\jre\\bin\\java.exe`, or `?:\\TeamCity\\BuildAgent\\jre\\bin\\java.exe`.
+- Examine the command-line arguments of the suspicious child process to identify any potentially malicious or unusual commands being executed.
+- Cross-reference the suspicious process name against known legitimate processes and common malicious tools to assess the likelihood of malicious activity.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<suspicious_process_name>';`.
+- Investigate the user account under which the suspicious process is running to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Check for any recent changes or updates to the TeamCity server configuration or plugins that might explain the unexpected process behavior.
+- Review network connections initiated by the suspicious process using network monitoring tools or logs to identify any unusual or unauthorized external communications.
+- Analyze system logs for any other suspicious activities or anomalies around the time the alert was triggered to identify potential indicators of compromise.
+- Consult threat intelligence sources to determine if there are any known vulnerabilities or exploits related to the specific version of TeamCity in use that could explain the suspicious activity.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate scripts or applications are executed as part of regular TeamCity operations, such as build scripts or deployment tasks that use command-line tools like `cmd.exe` or `powershell.exe`.
+- Exclude specific scripts or applications by adding exceptions for known benign processes, such as those with specific arguments or paths, to prevent them from being flagged.
+- Regularly review and update the exclusion list to accommodate changes in the build or deployment processes that may introduce new legitimate child processes.
+- Consider the context of the flagged process, such as the timing and frequency of execution, to determine if it aligns with expected TeamCity activities.
+- Collaborate with development and operations teams to identify and document routine processes that may trigger false positives, ensuring these are accounted for in the detection rule exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm the nature of the suspicious process, using forensic tools to analyze logs and system changes.
+- Terminate any malicious processes identified and remove any unauthorized files or executables from the system.
+- Review and update the TeamCity server and any related software to the latest versions to patch known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process execution data, focusing on child processes spawned by TeamCity.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for early detection of similar threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Restore the system from a known good backup, ensuring that the backup is free from any malicious modifications.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting execution policies, applying least privilege principles, and using application whitelisting to prevent unauthorized code execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_rdp_file_mail_attachment.toml b/rules/windows/initial_access_rdp_file_mail_attachment.toml
index 87b45b1a35b..d18e7035e0d 100644
--- a/rules/windows/initial_access_rdp_file_mail_attachment.toml
+++ b/rules/windows/initial_access_rdp_file_mail_attachment.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/05"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/11/05"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,49 @@ process where host.os.type == "windows" and event.type == "start" and
                  "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*.rdp",
                  "C:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\Content.Outlook\\*.rdp")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Remote Desktop File Opened from Suspicious Path
+
+Remote Desktop Protocol (RDP) enables users to connect to and control remote computers over a network. Adversaries exploit RDP files, which store connection settings, by placing them in suspicious directories to gain unauthorized access. The detection rule identifies when RDP files are opened from unusual paths, indicating potential phishing attempts or initial access tactics, by monitoring specific file locations and process activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the process `mstsc.exe` starting with arguments pointing to suspicious RDP file paths.
+- Verify the user account associated with the process to determine if it aligns with expected behavior or if it is an unusual account for RDP usage.
+- Check the file creation and modification timestamps of the suspicious RDP file to understand when it was placed in the directory.
+- Investigate the source of the RDP file by examining recent downloads or email attachments that may have been saved to the suspicious path.
+- Use Osquery to list all RDP files in the user's Downloads and Temp directories with the query: `SELECT path, size, atime, mtime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%.rdp' OR path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Local\\\\Temp\\\\%.rdp';`
+- Analyze the network connections made by `mstsc.exe` to identify any unusual or unauthorized remote IP addresses.
+- Correlate the event with other security logs to identify any additional suspicious activities around the same timeframe, such as failed login attempts or unusual file access patterns.
+- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
+- Review endpoint security logs for any alerts or detections related to the execution of `mstsc.exe` or the handling of RDP files.
+- Investigate the presence of any other suspicious processes or files on the host that could indicate a broader compromise or lateral movement attempts.
+
+### False positive analysis
+
+- Users may frequently download legitimate RDP files from trusted sources, such as corporate emails or internal portals, which could be flagged if stored in monitored directories like Downloads or Temp folders.
+- Automated scripts or software updates might temporarily store RDP files in these paths for legitimate purposes, triggering false alerts.
+- Employees working remotely might use RDP files sent via email or collaboration tools, which could be saved in the INetCache directory, leading to false positives.
+- To manage these false positives, consider creating exceptions for known safe sources or paths by whitelisting specific directories or file hashes associated with trusted RDP files.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and usability.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Conduct a thorough investigation to identify the source of the suspicious RDP file and determine if any other systems are compromised.
+- Analyze the RDP file and associated processes to understand the adversary's tactics and potential objectives.
+- Remove any unauthorized RDP files and terminate any suspicious processes related to the incident.
+- Reset credentials for any accounts that may have been compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
+- Integrate threat intelligence feeds to identify and block known malicious RDP file signatures and related indicators of compromise (IOCs).
+- Restore the system to its operational state by applying the latest security patches and updates, and verifying system integrity.
+- Harden the system by enforcing strict access controls, disabling unnecessary services, and educating users on recognizing phishing attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_scripts_process_started_via_wmi.toml b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
index 23c41341535..77ee1fc334f 100644
--- a/rules/windows/initial_access_scripts_process_started_via_wmi.toml
+++ b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/27"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -69,6 +69,50 @@ sequence by host.id with maxspan = 5s
      )
     ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows Script Interpreter Executing Process via WMI
+
+Windows Management Instrumentation (WMI) is a powerful feature in Windows that allows for system management and automation. Adversaries may exploit WMI to execute scripts using interpreters like cscript.exe or wscript.exe, often bypassing traditional security measures. The detection rule identifies suspicious script execution via WMI by monitoring for specific processes initiated by WMI, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and executable path that triggered the alert, focusing on `process.name` and `process.executable` fields.
+- Check the `host.id` and `host.os.type` fields to confirm the affected host and ensure it is a Windows system.
+- Investigate the parent process `wmiprvse.exe` to determine if it has any unusual or unexpected child processes, using the `process.parent.name` field.
+- Examine the `user.domain` field to identify the user context under which the suspicious process was executed, paying attention to any non-standard domains.
+- Use Osquery to list all processes currently running on the host and identify any other suspicious activities. Example query: `SELECT name, path, pid, parent, uid FROM processes WHERE name IN ('cscript.exe', 'wscript.exe', 'PowerShell.EXE', 'Cmd.Exe');`
+- Analyze the `event.category` and `event.action` fields to understand the nature of the event, especially focusing on "Image loaded" actions that might indicate DLL loading.
+- Investigate the presence and usage of `wmiutils.dll` by checking the `dll.name` or `file.name` fields to confirm if it was loaded during the suspicious activity.
+- Correlate the alert with other recent alerts or logs from the same host to identify patterns or repeated suspicious behavior.
+- Review historical data for the same `process.name` and `process.executable` to determine if this is a recurring event or a one-time occurrence.
+- Check for any recent changes or anomalies in the system's configuration or user accounts that might explain the suspicious activity, using system logs and configuration management tools.
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators often use scripts executed via WMI for legitimate purposes such as system maintenance, software deployment, or configuration management. These activities can trigger the detection rule, leading to false positives.
+- Monitoring and management tools: Some enterprise monitoring and management tools use WMI to execute scripts for gathering system information or performing routine tasks, which may be flagged by the rule.
+- Automated software updates: Certain software update mechanisms might use WMI to execute scripts as part of their update process, potentially causing false alerts.
+- To manage these false positives, users can create exceptions for known legitimate scripts or processes by whitelisting specific script names, paths, or user accounts that are verified as non-threatening.
+- Implementing a baseline of normal WMI activity within the organization can help distinguish between expected and suspicious behavior, reducing the likelihood of false positives.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary activities are excluded from detection, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been affected.
+- Analyze the script executed via WMI to understand its purpose and potential impact, and check for any persistence mechanisms it may have established.
+- Terminate any malicious processes identified during the investigation and remove any unauthorized scripts or files from the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and WMI activity, ensuring that future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting WMI access, using application whitelisting, and enforcing the principle of least privilege to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
index cfc6a035f4e..cdf660f4773 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,6 +82,53 @@ process where host.os.type == "windows" and event.type == "start" and
           "\\Device\\HarddiskVolume?\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe"
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft Exchange Server UM Spawning Suspicious Processes
+
+Microsoft Exchange Server's Unified Messaging (UM) integrates voicemail and email, enhancing communication efficiency. However, adversaries can exploit vulnerabilities, such as CVE-2021-26857, to execute unauthorized processes. The detection rule identifies unusual processes initiated by UM services, excluding known legitimate executables, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and executable path that triggered the alert, focusing on the `process.parent.name` and `process.executable` fields.
+- Verify the legitimacy of the process by checking the parent process `UMService.exe` or `UMWorkerProcess.exe` against known legitimate executables listed in the detection rule.
+- Cross-reference the process executable path with known Exchange Server installation paths to identify any anomalies or deviations.
+- Use Osquery to list all processes spawned by `UMService.exe` or `UMWorkerProcess.exe` to identify any unexpected or suspicious processes:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name IN ('UMService.exe', 'UMWorkerProcess.exe'));
+  ```
+- Investigate the command line arguments (`cmdline`) of the suspicious process to gather more context about its execution.
+- Check the process creation time and correlate it with any known suspicious activity or anomalies in the system logs.
+- Examine the user account context under which the suspicious process was executed to determine if it aligns with expected behavior.
+- Review recent security patches and updates applied to the Exchange Server to ensure CVE-2021-26857 and other vulnerabilities are addressed.
+- Analyze network traffic logs for any unusual outbound connections initiated by the suspicious process to external IP addresses.
+- Consult threat intelligence sources to determine if the identified process or behavior is associated with known threat actors or campaigns exploiting Exchange Server vulnerabilities.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate administrative tools or scripts are executed by the UM services, which are not included in the predefined list of known executables. 
+- Scheduled maintenance tasks or updates that involve UM services might trigger alerts if they spawn processes not recognized by the detection rule.
+- Custom scripts or third-party applications integrated with Exchange Server for enhanced functionality could also be flagged if they initiate processes through UM services.
+- To manage these false positives, users can create exceptions by adding the specific executable paths of these legitimate processes to the exclusion list within the detection rule.
+- Regularly review and update the exclusion list to accommodate any new legitimate processes that are part of routine operations or maintenance activities.
+- Collaborate with IT and security teams to identify and document any custom or third-party applications that interact with UM services to ensure they are accounted for in the detection rule.
+
+### Response and remediation
+
+- Isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify any unauthorized processes or changes made by exploiting CVE-2021-26857, using forensic tools to analyze logs and system changes.
+- Terminate any suspicious processes spawned by the UM service that are not part of the known legitimate executables list.
+- Apply the latest security patches and updates from Microsoft to address CVE-2021-26857 and other known vulnerabilities.
+- Restore the system from a clean backup taken before the compromise, ensuring that the backup is free from any malicious alterations.
+- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) and Intrusion Detection Systems (IDS) to monitor for similar threats.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.
+- Review and update firewall and access control policies to restrict unnecessary exposure of the Exchange Server to the internet.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
index 24a7a35c94a..62cdb4671a5 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/08"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,51 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") or
   ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft Exchange Worker Spawning Suspicious Processes
+
+Microsoft Exchange Server uses the worker process (w3wp.exe) to handle web requests, often running under specific application pools. Adversaries exploit this by executing malicious scripts or commands, potentially through web shells, to gain unauthorized access. The detection rule identifies unusual child processes like command-line interpreters spawned by w3wp, signaling possible exploitation or backdoor activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious child processes spawned by `w3wp.exe`, focusing on processes like `cmd.exe`, `powershell.exe`, `pwsh.exe`, and `powershell_ise.exe`.
+- Examine the command-line arguments (`process.parent.args`) associated with the `w3wp.exe` process to identify the specific application pool (`MSExchange*AppPool`) involved, which may provide context on the targeted service.
+- Check the process creation time (`event.type == "start"`) to correlate with any known suspicious activity or incidents reported around the same timeframe.
+- Investigate the parent process (`process.parent.name`) to ensure it is indeed `w3wp.exe` and verify its legitimacy by checking its file path and hash against known good values.
+- Use Osquery to gather additional context on the suspicious processes. For example, run the following query to list all child processes of `w3wp.exe`:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'w3wp.exe');
+  ```
+- Analyze the network connections and traffic associated with the `w3wp.exe` process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control activity.
+- Review the system and security event logs for any additional indicators of compromise or related suspicious activity around the time the alert was triggered.
+- Investigate the user accounts and privileges associated with the `w3wp.exe` process to determine if any unauthorized access or privilege escalation has occurred.
+- Check for any recent changes or anomalies in the Microsoft Exchange Server configuration or application pool settings that could have facilitated the suspicious activity.
+- Correlate the findings with threat intelligence sources to determine if the activity matches any known attack patterns or campaigns targeting Microsoft Exchange Servers.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use command-line tools like cmd.exe or PowerShell for legitimate maintenance activities on the Exchange server, which could trigger the rule. To manage this, create exceptions for known administrative accounts or scheduled tasks that regularly perform these actions.
+- Monitoring and management tools: Some third-party monitoring or management tools might spawn processes from w3wp.exe as part of their normal operation. Identify these tools and exclude their specific process names or hashes from the rule to prevent false alerts.
+- Automated scripts: Legitimate automated scripts running under the MSExchangeAppPool may occasionally invoke command-line interpreters. Review and whitelist these scripts by their specific command-line arguments or script paths to reduce false positives.
+- Software updates: During software updates or patches, certain processes might be temporarily spawned by w3wp.exe. Temporarily disable the rule or adjust its sensitivity during scheduled maintenance windows to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on logs and alerts related to the suspicious processes spawned by w3wp.exe.
+- Terminate any malicious processes identified during the investigation to halt ongoing exploitation activities.
+- Review and analyze web server logs to identify any web shells or unauthorized scripts that may have been uploaded or executed.
+- Apply the latest security patches and updates to the Microsoft Exchange Server to mitigate known vulnerabilities, particularly those related to public-facing applications.
+- Restore the system from a known good backup taken before the compromise, ensuring that any backdoors or malicious modifications are removed.
+- Implement enhanced logging and monitoring policies to capture detailed process creation events and network activity, aiding in future detection and investigation efforts.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate alerts and improve detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train IT staff on the latest threat tactics, techniques, and procedures (TTPs) related to web shell exploitation and public-facing application attacks, leveraging MITRE ATT&CK framework insights."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
index 3f33d06e360..c36ab2d1dc2 100644
--- a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
+++ b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/29"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,50 @@ process where host.os.type == "windows" and event.type == "start" and
             "/factory,{ceff45ee-c862-41de-aee2-a022c81eda92}"
           )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Explorer Child Process
+
+Windows Explorer, a core component of the Windows operating system, manages file and folder navigation. Adversaries exploit its trusted status to launch malicious scripts or executables, often using it as a parent process to execute harmful payloads via child processes like PowerShell or cmd.exe. The detection rule identifies such anomalies by monitoring for specific child processes initiated by Explorer, excluding benign operations, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a suspicious child process initiated by explorer.exe, focusing on the process names and original file names such as "powershell.exe", "cmd.exe", and others listed in the query.
+- Check the process command line arguments for any unusual or suspicious patterns, especially those not matching the excluded COM Class IDs.
+- Investigate the parent process explorer.exe to determine if it was started with the "-Embedding" argument, which may indicate an attempt to exploit DCOM for malicious purposes.
+- Correlate the event with user activity logs to identify the user account associated with the suspicious process execution and determine if the activity aligns with their typical behavior.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cscript.exe', 'wscript.exe', 'powershell.exe', 'rundll32.exe', 'cmd.exe', 'mshta.exe', 'regsvr32.exe');`
+- Examine the network connections established by the suspicious process using network monitoring tools or logs to identify any unusual or unauthorized external communications.
+- Check for any recent file modifications or creations in directories commonly used by the suspicious process, which may indicate payload delivery or execution.
+- Analyze the system's security logs for any other related events or anomalies around the time of the suspicious process execution, such as failed login attempts or privilege escalation activities.
+- Investigate the system for any known vulnerabilities or misconfigurations that could have been exploited to launch the suspicious process.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, providing additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule as they often use scripts or command-line tools like PowerShell or cmd.exe, which are flagged by the detection rule.
+- System administrators or IT personnel executing scripts for maintenance or configuration purposes might inadvertently match the rule criteria, especially if using remote management tools.
+- Some enterprise applications may use explorer.exe to launch necessary components or scripts, which could be misidentified as suspicious activity.
+- Users can manage these false positives by creating exceptions for known and verified processes or scripts that are frequently executed in their environment.
+- Implementing a whitelist of trusted applications or scripts that are known to use explorer.exe as a parent process can help reduce noise.
+- Regularly review and update the exclusion list to ensure it reflects the current operational environment and any new legitimate software deployments.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the suspicious child process to determine if it is indeed malicious, using endpoint detection and response (EDR) tools.
+- Terminate any malicious processes identified during the investigation to stop ongoing malicious activity.
+- Analyze the parent process (explorer.exe) and its command-line arguments to understand how the malicious process was initiated.
+- Review and collect relevant logs, such as Windows Event Logs and security logs, to gather evidence and understand the scope of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Implement or enhance logging policies to ensure detailed process creation logs are captured for future investigations.
+- Integrate threat intelligence feeds to correlate detected threats with known attack patterns and adversary tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by removing any malicious files, registry entries, or scheduled tasks, and apply security patches and updates.
+- Harden the system by implementing application whitelisting, disabling unnecessary scripting engines, and enforcing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_webshell_screenconnect_server.toml b/rules/windows/initial_access_webshell_screenconnect_server.toml
index c00dfc3018e..c7f8f3af7f7 100644
--- a/rules/windows/initial_access_webshell_screenconnect_server.toml
+++ b/rules/windows/initial_access_webshell_screenconnect_server.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,48 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or
   ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 ScreenConnect Server Spawning Suspicious Processes
+
+ScreenConnect, a remote support tool, allows administrators to control systems remotely. Adversaries may exploit this by executing unauthorized commands or scripts, potentially using it as a vector for deploying web shell backdoors. The detection rule identifies unusual child processes initiated by the ScreenConnect service, flagging potential exploitation or misuse by monitoring for specific command-line utilities and scripting engines.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the parent process is "ScreenConnect.Service.exe" and identify the suspicious child process name and command-line arguments.
+- Check the timestamp of the event to determine when the suspicious process was spawned and correlate it with any known activities or changes in the environment.
+- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Examine the network connections established by the suspicious process to identify any unusual or unauthorized external communications.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'cmd.exe' OR name = 'powershell.exe' AND parent = (SELECT pid FROM processes WHERE name = 'ScreenConnect.Service.exe');`
+- Analyze the command-line arguments of the suspicious process to identify any potentially malicious scripts or commands being executed.
+- Review the system's event logs for any additional indicators of compromise or related suspicious activities around the same timeframe.
+- Check for any recent changes or updates to the ScreenConnect application that could explain the spawning of the suspicious process.
+- Investigate any other alerts or incidents involving the same host or user account to identify patterns or repeated attempts of exploitation.
+- Consult threat intelligence sources to determine if there are any known vulnerabilities or exploits associated with the specific version of ScreenConnect in use.
+
+### False positive analysis
+
+- Routine administrative tasks: ScreenConnect may legitimately spawn processes like cmd.exe or powershell.exe during regular maintenance or updates. Users should verify if these activities align with scheduled tasks or known administrative actions.
+- Automated scripts: Organizations using automated scripts for system management might see these processes triggered by ScreenConnect. It's important to cross-reference with scheduled automation tasks to confirm legitimacy.
+- Software updates: During software updates, ScreenConnect might execute scripts or commands that appear suspicious. Users should check if the timing of these processes coincides with known update schedules.
+- Exclusion methods: To manage false positives, users can create exceptions for known benign activities by whitelisting specific parent-child process relationships or by excluding processes executed during certain time frames associated with legitimate tasks.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or changes made through the ScreenConnect service.
+- Review logs and alerts to identify any additional systems that may have been accessed or compromised using similar methods.
+- Terminate any suspicious processes spawned by ScreenConnect.Service.exe and remove any unauthorized scripts or tools found on the system.
+- Change all credentials associated with the compromised system and any other systems that may have been accessed using the same credentials.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
+- Implement enhanced logging and monitoring for ScreenConnect activities, including command-line auditing and process creation events, to detect future suspicious activities.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings to improve detection capabilities and contextual understanding of similar threats.
+- Restore the system from a known good backup to ensure all malicious changes are removed and the system is returned to a secure operational state.
+- Apply security hardening measures, such as restricting ScreenConnect access to authorized users and implementing multi-factor authentication, to reduce the risk of future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_xsl_script_execution_via_com.toml b/rules/windows/initial_access_xsl_script_execution_via_com.toml
index 4b35a4ed939..e52ec50672d 100644
--- a/rules/windows/initial_access_xsl_script_execution_via_com.toml
+++ b/rules/windows/initial_access_xsl_script_execution_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,48 @@ sequence with maxspan=1m
          "?:\\Program Files\\*.exe",
          "?:\\Program Files (x86)\\*exe")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Remote XSL Script Execution via COM
+
+The Microsoft.XMLDOM COM interface allows applications to parse and transform XML documents using XSL scripts. Adversaries exploit this by embedding malicious scripts in Office documents, triggering execution via Office processes like Word or Excel. The detection rule identifies suspicious activity by monitoring for the loading of specific DLLs and the execution of unexpected child processes, indicating potential script execution abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `msxml3.dll` loaded by Office processes such as `winword.exe`, `excel.exe`, `powerpnt.exe`, or `mspub.exe`, as this indicates potential XSL script execution.
+- Examine the parent process information, specifically the `process.entity_id` and `process.parent.entity_id`, to trace the origin of the suspicious activity and understand the process hierarchy.
+- Check the `process.executable` path of the child processes started by the Office applications to identify any unusual or unexpected executables that do not match known safe paths.
+- Investigate the command line arguments of the suspicious child processes to gather more context on the nature of the execution and any potential scripts or payloads involved.
+- Utilize Osquery to list all running processes and their parent-child relationships to verify the alert findings. Example query: `SELECT pid, name, path, parent FROM processes WHERE name IN ('winword.exe', 'excel.exe', 'powerpnt.exe', 'mspub.exe');`
+- Analyze recent file modifications and creations in directories commonly used by Office applications to identify any new or altered files that could be related to the suspicious activity.
+- Review the system's event logs, particularly security and application logs, for any additional indicators of compromise or related suspicious activities around the time of the alert.
+- Check network logs for any unusual outbound connections initiated by the Office processes, which could indicate data exfiltration or command and control communication.
+- Correlate the alert with any other recent alerts or incidents on the same host to determine if this is part of a broader attack campaign.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors associated with similar techniques, leveraging the MITRE ATT&CK tactic and technique identifiers (TA0001, T1566) for context.
+
+### False positive analysis
+
+- Legitimate business applications or custom scripts that utilize the Microsoft.XMLDOM COM interface for XML parsing and transformation may trigger this detection rule. Users should identify and document these applications to differentiate them from malicious activity.
+- Automated document processing systems that rely on Office applications to handle XML data might also cause false positives. It's important to review these systems and consider creating exceptions for known, safe processes.
+- Some enterprise environments may have scheduled tasks or scripts that execute Office applications with XML processing capabilities. These should be cataloged, and exceptions should be configured to prevent unnecessary alerts.
+- Users can manage false positives by creating exceptions for specific process paths or executable names that are verified as non-malicious. This can be done by updating the detection rule to exclude these known safe processes from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the malicious script.
+- Conduct a thorough investigation to identify the source of the malicious document and any other potentially affected systems.
+- Terminate any suspicious processes identified in the alert, particularly those spawned by Office applications.
+- Remove any malicious files or scripts found on the system, ensuring to check common persistence locations.
+- Restore the system from a known good backup if the integrity of the system is in question.
+- Update antivirus and endpoint protection solutions to ensure they can detect and block similar threats in the future.
+- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze similar threats.
+- Educate users on recognizing phishing attempts and the risks of opening unsolicited Office documents.
+- Review and apply security patches and hardening measures for Microsoft Office and Windows systems to mitigate exploitation risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_alternate_creds_pth.toml b/rules/windows/lateral_movement_alternate_creds_pth.toml
index b8afff146d2..ec8db41f831 100644
--- a/rules/windows/lateral_movement_alternate_creds_pth.toml
+++ b/rules/windows/lateral_movement_alternate_creds_pth.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,49 @@ event.category : "authentication" and event.action : "logged-in" and
 winlog.logon.type : "NewCredentials" and event.outcome : "success" and 
 user.id : (S-1-5-21-* or S-1-12-1-*) and winlog.event_data.LogonProcessName : "seclogo"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Pass-the-Hash (PtH) Attempt
+
+Pass-the-Hash (PtH) exploits authentication processes by using stolen password hashes to gain unauthorized access, bypassing the need for plaintext passwords. Adversaries leverage this to move laterally across systems. The detection rule identifies suspicious logins on Windows systems, focusing on successful authentications using specific logon types and processes, indicating potential PtH activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the specific logon type "NewCredentials" and the logon process name "seclogo" to ensure it matches the criteria for a potential PtH attempt.
+- Correlate the user ID (S-1-5-21-* or S-1-12-1-*) with known user accounts to determine if the account is legitimate and if the activity aligns with expected behavior for that user.
+- Examine the source and destination IP addresses associated with the login event to identify if the access originated from an unusual or unauthorized location.
+- Check the timestamp of the event to determine if the login occurred during non-business hours, which could indicate suspicious activity.
+- Investigate the host from which the login attempt was made using Osquery to gather additional context. For example, run the following Osquery query to list recent logon sessions: `SELECT * FROM logged_in_users WHERE user = '<username>';`
+- Analyze the event logs on the involved systems for any preceding or subsequent suspicious activities, such as failed login attempts or unusual process executions.
+- Review any recent changes to user account privileges or group memberships that could have facilitated the PtH attempt.
+- Investigate any other authentication events involving the same user ID across the network to identify patterns or additional instances of suspicious logins.
+- Check for any known vulnerabilities or misconfigurations on the involved systems that could have been exploited to facilitate the PtH attempt.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently using PtH techniques that match the observed behavior.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that automate tasks may trigger the rule if they use the "NewCredentials" logon type and "seclogo" process, as these can mimic PtH behavior. Users should review the context of such logins to determine if they are part of routine administrative operations.
+- Scheduled tasks or services that require authentication using stored credentials might appear as PtH attempts. To manage these, users can create exceptions for known and verified tasks or services by excluding specific user IDs or hostnames.
+- Security software or network monitoring tools that perform regular checks or audits on systems might generate false positives. Users should identify these tools and exclude their associated processes or user IDs from the detection rule.
+- In environments with single sign-on (SSO) solutions, certain authentication processes might resemble PtH activity. Users should ensure that SSO-related logins are recognized and excluded from the rule by verifying the legitimacy of the logon process and user IDs involved.
+- To handle false positives effectively, users can maintain a whitelist of known non-threatening behaviors, regularly update it based on observed patterns, and apply it to the detection rule to minimize unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to identify the source of the hash theft, reviewing recent changes and access logs for anomalies.
+- Reset passwords for all accounts that were potentially compromised, ensuring that new passwords are strong and unique.
+- Analyze the event logs for other instances of the "seclogo" logon process to identify additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed authentication events, including logon types and processes.
+- Integrate threat intelligence feeds to correlate detected PtH attempts with known threat actor tactics and techniques.
+- Restore the affected system from a known good backup to ensure no malicious code remains.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for hash theft.
+- Implement network segmentation and least privilege access controls to limit the potential impact of future PtH attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_cmd_service.toml b/rules/windows/lateral_movement_cmd_service.toml
index 6bc844d0c45..2a143a6d184 100644
--- a/rules/windows/lateral_movement_cmd_service.toml
+++ b/rules/windows/lateral_movement_cmd_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,49 @@ sequence by process.entity_id with maxspan = 1m
       process.args : ("create", "config", "failure", "start")]
   [network where host.os.type == "windows" and process.name : "sc.exe" and destination.ip != "127.0.0.1"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Service Command Lateral Movement
+
+The `sc.exe` utility in Windows is used for managing services, including creating, modifying, or starting them on remote systems. While essential for administrative tasks, adversaries can exploit it for lateral movement by executing malicious services on remote hosts. The detection rule identifies suspicious use of `sc.exe` by monitoring for specific command patterns and network activity, flagging potential unauthorized service manipulations.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `process.entity_id` and `process.name` involved in the suspicious activity.
+- Examine the `process.args` to determine the exact command executed, focusing on arguments like `binPath=*`, `create`, `config`, `failure`, and `start` to understand the service manipulation intent.
+- Check the `destination.ip` field to identify the remote host targeted by the `sc.exe` command and verify if it is a legitimate administrative action or an unauthorized attempt.
+- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior.
+- Correlate the timestamp of the event with other security logs to identify any concurrent suspicious activities or anomalies on the involved systems.
+- Use Osquery to gather additional context on the involved systems. For example, run the following query to list services recently created or modified: `SELECT name, path, start_type, status FROM services WHERE timestamp > (SELECT MAX(timestamp) - 3600 FROM services);`
+- Analyze network logs to trace any unusual connections or data transfers between the source and destination IPs around the time of the alert.
+- Review historical data for similar patterns of `sc.exe` usage across the network to identify potential trends or repeated unauthorized access attempts.
+- Check for any related alerts or incidents involving the same `process.entity_id` or `destination.ip` to assess if this is part of a larger attack campaign.
+- Consult with system administrators to verify if the detected activity was part of routine maintenance or an expected operation, ensuring alignment with organizational policies.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use `sc.exe` for legitimate purposes such as configuring services on remote systems, which can trigger false positives. To manage this, users can create exceptions for known administrative accounts or specific IP addresses frequently used for these tasks.
+- Automated scripts and management tools: Automated processes or management tools that rely on `sc.exe` for service management across multiple machines may also be flagged. Users should identify these scripts or tools and exclude their associated processes or network patterns from the detection rule.
+- Monitoring and management software: Some enterprise monitoring or management software may use `sc.exe` to interact with services on remote hosts. Users can whitelist these applications by their process names or digital signatures to reduce noise.
+- Internal IT operations: Regular IT operations, such as software updates or system maintenance, might involve the use of `sc.exe` across the network. Users should document these operations and adjust the detection rule to exclude them based on time windows or specific network segments.
+- Testing and development environments: In environments where frequent testing or development occurs, `sc.exe` might be used extensively. Users can create exceptions for specific environments or subnets to prevent false positives in these areas.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to confirm the unauthorized use of sc.exe, reviewing logs and correlating with other security events.
+- Identify and terminate any malicious services created or modified by the adversary using sc.exe on the affected and remote systems.
+- Change credentials for any accounts that were used to execute the sc.exe commands, as they may be compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed service creation and modification events, including command-line arguments and network connections.
+- Integrate threat intelligence feeds to correlate detected activity with known adversary tactics, techniques, and procedures (TTPs) from MITRE ATT&CK.
+- Restore the system to its operational state by reinstalling or repairing the operating system and applications, ensuring all patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
+- Harden systems by disabling unnecessary services, enforcing least privilege access, and implementing network segmentation to limit lateral movement opportunities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_hta.toml b/rules/windows/lateral_movement_dcom_hta.toml
index 17625556c65..853c6bd44c4 100644
--- a/rules/windows/lateral_movement_dcom_hta.toml
+++ b/rules/windows/lateral_movement_dcom_hta.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,49 @@ sequence with maxspan=1m
      source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1"
   ] by host.id, process.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Incoming DCOM Lateral Movement via MSHTA
+
+DCOM allows software components to communicate over a network, enabling remote execution of applications like MSHTA, which runs HTML applications. Adversaries exploit this by executing commands remotely, bypassing traditional security measures. The detection rule identifies such abuse by monitoring for MSHTA processes initiated with specific arguments and network activity indicative of lateral movement, focusing on unusual port usage and non-local IP addresses.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `mshta.exe` process execution with the `-Embedding` argument, as this is a key indicator of potential DCOM abuse.
+- Verify the source and destination IP addresses involved in the network activity. Ensure that the source IP is not a local address (i.e., not `127.0.0.1` or `::1`) and assess whether the IP is known or expected within the network.
+- Check the source and destination ports used in the network connection. Ports greater than 49151 are typically dynamic and may indicate unusual activity.
+- Correlate the `host.id` and `process.entity_id` from the alert with other logs to identify any related processes or activities on the same host.
+- Use Osquery to gather additional context on the `mshta.exe` process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, parent, path, cmdline FROM processes WHERE name = 'mshta.exe';`
+- Investigate the parent process of `mshta.exe` to determine if it was spawned by a legitimate application or if it is part of a suspicious chain of execution.
+- Examine recent login events on the affected host to identify any unusual or unauthorized access attempts that may correlate with the alert.
+- Review any recent changes to the system's DCOM configuration or related registry keys that could indicate tampering or preparation for lateral movement.
+- Analyze network traffic logs for any other unusual or unexpected connections originating from or targeting the affected host around the time of the alert.
+- Consult threat intelligence sources to determine if the observed IP addresses or behavior patterns are associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that utilize MSHTA for remote management tasks may trigger this rule. Users should identify and document these tools to differentiate them from malicious activity.
+- Automated software deployment or update processes that use MSHTA for executing scripts across the network can be mistaken for lateral movement. Exclude these processes by creating exceptions based on known source IP addresses and process arguments.
+- Internal network scanning or monitoring tools that simulate lateral movement for security assessments might be flagged. Ensure these tools are whitelisted by their specific network and process characteristics.
+- Developers or IT personnel testing applications that involve remote execution via MSHTA could inadvertently trigger alerts. Establish a list of authorized personnel and their associated activities to prevent false positives.
+- In environments where MSHTA is used for legitimate inter-process communication, especially in legacy systems, consider excluding specific host IDs or process entity IDs that are known to engage in benign activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation to identify the source of the DCOM abuse, including reviewing logs for unusual MSHTA activity and correlating with other security events.
+- Terminate any suspicious MSHTA processes identified during the investigation to halt any ongoing malicious activity.
+- Reset credentials for any accounts that may have been compromised during the attack to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on DCOM and MSHTA usage.
+- Integrate threat intelligence feeds to improve detection capabilities for known indicators of compromise related to DCOM lateral movement.
+- Restore the affected system from a known good backup to ensure it is free from any malicious modifications.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for DCOM abuse.
+- Review and update security policies and configurations to harden systems against similar attacks, including disabling unnecessary DCOM components and restricting MSHTA usage."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_mmc20.toml b/rules/windows/lateral_movement_dcom_mmc20.toml
index fd2ad45bc02..e592a0a39db 100644
--- a/rules/windows/lateral_movement_dcom_mmc20.toml
+++ b/rules/windows/lateral_movement_dcom_mmc20.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,51 @@ sequence by host.id with maxspan=1m
  [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe"
  ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Incoming DCOM Lateral Movement with MMC
+
+Distributed Component Object Model (DCOM) allows software components to communicate over a network, often used in Windows environments for remote management. Adversaries exploit DCOM to execute commands remotely, leveraging applications like MMC20. The detection rule identifies suspicious activity by monitoring network traffic and process creation patterns, focusing on remote command execution via MMC, which may indicate lateral movement attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious network activity involving `mmc.exe` with high source and destination ports (>= 49152), indicating potential DCOM exploitation.
+- Verify the source and destination IP addresses involved in the alert to determine if the source IP is external or internal, and assess the legitimacy of the connection.
+- Check the process creation logs to identify the parent process of `mmc.exe` and ensure it aligns with expected behavior; unexpected parent processes may indicate malicious activity.
+- Investigate the timeline of events by correlating the `process.entity_id` and `process.parent.entity_id` to understand the sequence of process creation and network activity.
+- Use Osquery to gather additional context on the host by running a query to list all processes related to `mmc.exe`:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'mmc.exe';
+  ```
+- Examine the command line arguments of `mmc.exe` to identify any unusual or unauthorized commands that may have been executed.
+- Analyze the network traffic logs to identify any other suspicious connections or patterns that coincide with the alert timeframe, focusing on the `network.direction` and `network.transport` fields.
+- Cross-reference the alert with other security logs, such as Windows Event Logs, to identify any related authentication attempts or anomalies around the same time.
+- Investigate the user account associated with the `mmc.exe` process to determine if it has been compromised or is being used in an unauthorized manner.
+- Review historical data for similar alerts or patterns involving `mmc.exe` to assess if this is an isolated incident or part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use MMC for legitimate remote management tasks, which can trigger the rule. To manage this, users can create exceptions for known administrator accounts or specific IP addresses that regularly perform these tasks.
+- Automated scripts or management tools: Some organizations use automated scripts or third-party management tools that leverage DCOM and MMC for routine operations. Users can exclude these processes by identifying their unique characteristics, such as specific command-line arguments or process hashes.
+- Software updates and patches: Certain software updates or patches might use DCOM and MMC to apply changes across the network. Users should monitor update schedules and exclude related activities during these periods to avoid false positives.
+- Internal network scanning tools: Security teams might use network scanning tools that interact with MMC for vulnerability assessments. Users can whitelist these tools by their source IP addresses or specific network ranges to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation of the affected host to identify any unauthorized access or changes, focusing on the processes initiated by mmc.exe.
+- Review network logs and traffic patterns to identify other potentially compromised systems or lateral movement attempts.
+- Terminate any suspicious processes associated with the DCOM exploitation and remove any unauthorized scheduled tasks or services.
+- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited via DCOM.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process creation and network activity, ensuring that future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by reinstalling the operating system if necessary and restoring data from verified backups.
+- Harden the environment by disabling unnecessary DCOM services and configuring firewall rules to restrict high-numbered ports used for DCOM communication."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
index 0ae4173fb6c..ff221416a8e 100644
--- a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
+++ b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,52 @@ sequence by host.id with maxspan=5s
   process.parent.name : "explorer.exe"
  ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows
+
+DCOM allows software components to communicate over a network, enabling remote execution of applications. Adversaries exploit this by using ShellBrowserWindow or ShellWindows to execute commands stealthily on remote systems. The detection rule identifies such activity by monitoring network traffic and process creation patterns, specifically looking for remote command execution initiated by explorer.exe, which may indicate lateral movement attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of network traffic and process creation patterns that match the rule criteria, focusing on the involvement of `explorer.exe` and the specified port range.
+- Verify the source IP address to determine if it is an expected or known entity within the network, ensuring it is not a loopback address like `127.0.0.1` or `::1`.
+- Check the destination IP address and port to identify the target system and service involved in the potential lateral movement attempt.
+- Investigate the process tree for `explorer.exe` to identify any unusual child processes that may have been spawned, indicating potential malicious activity.
+- Use Osquery to gather additional context on the involved processes. For example, run the following query to list processes with `explorer.exe` as the parent:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'explorer.exe');
+  ```
+- Examine the network traffic logs for any other suspicious connections or patterns that coincide with the time of the alert, focusing on the `source.port` and `destination.port` fields.
+- Correlate the alert with other security events or logs from the same time period to identify any additional indicators of compromise or related activities.
+- Check for any recent changes or anomalies in user accounts or permissions on the involved systems that could facilitate lateral movement.
+- Review historical data for similar alerts or patterns involving the same source or destination IP addresses to assess if this is part of a broader attack campaign.
+- Consult threat intelligence sources to determine if there are any known threats or campaigns that match the observed behavior, leveraging the MITRE ATT&CK framework references (TA0008, T1021) for context.
+
+### False positive analysis
+
+- Legitimate administrative tools or software updates may trigger the rule if they use DCOM for remote management or updates, as these processes can mimic the behavior of lateral movement attempts.
+- Network monitoring solutions or security software that perform regular scans or updates across the network might also cause false positives by initiating connections that resemble the described pattern.
+- Users can manage these false positives by creating exceptions for known and trusted IP addresses or specific process names that are verified to be part of legitimate operations.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+- Consider implementing additional context checks, such as verifying the source of the network traffic or correlating with other security events, to differentiate between benign and malicious activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation to identify the source of the DCOM exploitation, including reviewing network logs and process creation events.
+- Terminate any suspicious processes that were initiated by explorer.exe and are not part of normal operations.
+- Reset credentials for any accounts that were used during the lateral movement attempt to prevent unauthorized access.
+- Apply patches and updates to the operating system and any vulnerable applications to mitigate the exploited vulnerability.
+- Implement enhanced logging policies to capture detailed network and process activity, focusing on DCOM-related events and explorer.exe executions.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system from a known good backup to ensure no malicious artifacts remain on the system.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Harden the environment by disabling unnecessary DCOM components and configuring firewalls to restrict high-numbered ports used in the attack."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
index 74e5284a1ad..40032b4ffe0 100644
--- a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
+++ b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,49 @@ registry.path : (
 ) and length(registry.data.strings) > 0 and
 not registry.data.strings : "(empty)"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 NullSessionPipe Registry Modification
+
+The NullSessionPipe registry setting in Windows environments defines which named pipes can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to allow unauthorized access, aiding lateral movement within a network. The detection rule identifies changes to this registry path, focusing on non-empty modifications, to flag potential misuse indicative of adversarial activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path matches one of the specified paths in the query: "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes", "\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes", or "MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes".
+- Check the event type to ensure it is a "change" event, indicating a modification to the registry.
+- Examine the registry data strings to identify which named pipes have been added or modified, ensuring they are not empty or marked as "(empty)".
+- Correlate the timestamp of the registry change event with other logs to identify any suspicious activities or patterns around the same time, such as unusual logins or file access.
+- Investigate the user account or process responsible for the registry modification to determine if it is a known and authorized entity.
+- Use Osquery to further investigate the registry modification by running a query such as: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes';` to gather more details about the current state of the registry key.
+- Analyze network traffic logs to detect any unusual or unauthorized access attempts to the named pipes specified in the registry modification.
+- Review historical data to determine if similar registry modifications have occurred in the past and assess if there is a pattern or recurring threat actor involved.
+- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or evidence of lateral movement attempts.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors that commonly exploit NullSessionPipe modifications for lateral movement.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the NullSessionPipe registry setting to facilitate necessary communication between components, which can trigger false positives. Users should verify if the modification aligns with recent software changes or updates.
+- Network management tools or legitimate administrative scripts might alter the NullSessionPipe settings to enable specific functionalities, leading to benign registry changes. Users can create exceptions for known tools or scripts that are part of regular network operations.
+- Certain enterprise applications may require anonymous access to specific named pipes for proper functionality. Users should document and exclude these applications from triggering alerts by adding them to an exception list.
+- Regular audits and reviews of registry changes can help identify patterns of benign modifications, allowing users to refine detection rules and reduce false positives by excluding these patterns.
+- Collaboration with IT and security teams to maintain an updated list of approved applications and tools that interact with the NullSessionPipe registry can help in managing exceptions effectively.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized modifications to the NullSessionPipe registry setting and determine the scope of the compromise.
+- Review recent changes in the registry and correlate them with user activity logs to identify potential malicious actors or compromised accounts.
+- Restore the NullSessionPipe registry setting to its default state to eliminate unauthorized anonymous access.
+- Implement enhanced logging and monitoring for registry changes, focusing on critical paths like NullSessionPipes, to detect future unauthorized modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Review and update access controls and permissions for sensitive systems to ensure that only authorized users have access to modify critical registry settings.
+- Conduct a security audit of the network to identify and remediate other potential vulnerabilities that could be exploited for lateral movement.
+- Implement network segmentation to limit the spread of threats and reduce the attack surface for lateral movement.
+- Educate users and administrators on the risks associated with unauthorized registry modifications and the importance of maintaining secure configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
index 1e1e22abd20..f4a52a9f0e9 100644
--- a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
+++ b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/12"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,53 @@ any where host.os.type == "windows" and
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Remote Desktop Shadowing Activity
+
+Remote Desktop Shadowing allows administrators to view or control active RDP sessions, aiding in support and troubleshooting. However, adversaries can exploit this feature to monitor or hijack user sessions without consent. The detection rule identifies suspicious registry changes and process executions linked to shadowing, flagging potential unauthorized access attempts by monitoring specific registry paths and process activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the specific registry path or process that triggered the alert, focusing on the `registry.path` and `process.name` fields.
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
+- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the source IP address and hostname of the machine where the activity was detected to identify if it is a known and trusted device.
+- Use Osquery to list all current RDP sessions on the host to identify any active shadowing sessions:
+  ```sql
+  SELECT * FROM rdp_connections;
+  ```
+- Query the Windows Event Logs for any related events around the time of the alert, focusing on Event ID 1149 (RDP connection) and Event ID 4624 (successful logon).
+- Investigate the parent process `svchost.exe` to determine if it has any unusual child processes or command-line arguments that could indicate malicious activity.
+- Check for any recent changes to the registry path `HKLM\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow` to identify unauthorized modifications.
+- Review the process execution history on the host to identify any instances of `mstsc.exe` with the `/shadow:*` argument, which could indicate shadowing attempts.
+- Analyze network traffic logs to identify any unusual outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
+
+### False positive analysis
+
+- Legitimate administrative activities: System administrators may use Remote Desktop Shadowing for valid support and troubleshooting purposes, leading to benign registry changes or process executions. 
+- Scheduled maintenance tasks: Automated scripts or scheduled tasks might trigger similar registry modifications or process starts as part of routine system maintenance.
+- Third-party remote support tools: Some remote support applications may mimic RDP shadowing behavior, causing similar registry and process activity.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific maintenance windows where such activities are expected.
+- Implementing a whitelist for trusted third-party remote support tools can help reduce unnecessary alerts.
+- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the unauthorized RDP shadowing activity by reviewing logs and correlating with other security events.
+- Terminate any suspicious RDP sessions and processes identified during the investigation to stop ongoing unauthorized access.
+- Change passwords for all accounts that were active during the suspicious RDP sessions to prevent further unauthorized access.
+- Review and update the RDP configuration settings to ensure that shadowing requires user consent and is logged appropriately.
+- Implement enhanced logging policies to capture detailed RDP session activities, including shadowing attempts, for future investigations.
+- Integrate security solutions such as SIEM and EDR to provide real-time monitoring and alerting on suspicious RDP activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Restore the system to its operational state by applying the latest security patches and updates, and conducting a full malware scan.
+- Harden the system by disabling unnecessary RDP features, enforcing strong authentication mechanisms, and regularly reviewing user access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
index d5fa197c1de..2e610cce520 100644
--- a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
+++ b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,48 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.executable : "\\Device\\Mup\\tsclient\\*.exe"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution via TSClient Mountpoint
+
+The TSClient mountpoint is a feature of the Remote Desktop Protocol (RDP) that allows users to access local drives from a remote session. Adversaries can exploit this by executing malicious binaries from the shared mountpoint, facilitating lateral movement within a network. The detection rule identifies such activities by monitoring for process executions originating from the TSClient path, indicating potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process execution path matches the pattern `\\\\Device\\\\Mup\\\\tsclient\\\\*.exe`, indicating execution from the TSClient mountpoint.
+- Identify the user account associated with the process execution to determine if it aligns with expected user behavior or if it might be compromised.
+- Check the timestamp of the process execution to correlate with any other suspicious activities or anomalies in the network around the same time.
+- Investigate the parent process of the executed binary to understand how the execution was initiated and if it was part of a legitimate workflow.
+- Use Osquery to list all processes executed from the TSClient mountpoint with a query like: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE path LIKE '\\\\Device\\\\Mup\\\\tsclient\\\\%';` to gather more context on the execution.
+- Examine the network connections from the host at the time of the alert to identify any unusual outbound connections that might indicate data exfiltration or further lateral movement.
+- Review the security logs on the host for any failed login attempts or other authentication anomalies that could suggest unauthorized access.
+- Check for any recent changes to user permissions or group memberships that might have facilitated the execution from the TSClient mountpoint.
+- Analyze any related file modifications or creations on the host to identify if the executed binary made any unauthorized changes to the system.
+- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to build a comprehensive picture of the potential threat.
+
+### False positive analysis
+
+- Legitimate administrative activities: System administrators may use the TSClient mountpoint to execute scripts or administrative tools for maintenance and troubleshooting purposes. These activities can be mistaken for malicious behavior.
+- Software updates and installations: IT personnel might deploy software updates or install applications via the TSClient path, triggering the detection rule.
+- Automated backup or synchronization tools: Some organizations use automated tools that access local drives through RDP for backup or file synchronization, which could be flagged as suspicious.
+- To manage these false positives, users can create exceptions for known and verified administrative accounts or specific executable paths that are frequently used for legitimate purposes. This can be done by updating the detection rule to exclude certain user accounts or executable names that are identified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Verify the execution of any suspicious binaries from the TSClient path and terminate any malicious processes identified.
+- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise or persistence mechanisms.
+- Review RDP access logs to identify unauthorized access attempts and determine the source of the intrusion.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed RDP session activities and process execution events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by removing any malicious files, applying security patches, and ensuring system integrity.
+- Harden RDP configurations by enforcing strong authentication methods, limiting access to trusted IP addresses, and disabling unnecessary features.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans based on lessons learned."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
index f3a096eded1..8759b59f806 100644
--- a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
+++ b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,49 @@ sequence by host.id with maxspan=30s
    [process where host.os.type == "windows" and 
     event.type == "start" and process.parent.name : "winrshost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Incoming Execution via WinRM Remote Shell
+
+Windows Remote Management (WinRM) facilitates remote command execution and management, crucial for system administration. However, adversaries exploit it for lateral movement by executing commands on remote systems. The detection rule identifies such abuse by monitoring network traffic for incoming connections on WinRM ports and subsequent suspicious process starts, indicating potential unauthorized remote shell activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of incoming network connections on WinRM ports (5985, 5986) and verify the network direction is "incoming" or "ingress".
+- Check the source IP address of the incoming connection to determine if it is from a known or trusted source. Investigate any unfamiliar or suspicious IP addresses.
+- Examine the process start event to identify the process that was initiated by "winrshost.exe". Pay attention to the process name and executable path to determine if it is expected or potentially malicious.
+- Use Osquery to list all processes currently running on the host to identify any unusual or unexpected processes. Example query: `SELECT pid, name, path FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'winrshost.exe');`
+- Investigate the parent-child process relationship to understand the context of the process execution. Look for any anomalies in the process tree that could indicate malicious activity.
+- Analyze the network traffic logs to identify any additional connections from the same source IP or to the same destination port that could indicate further lateral movement attempts.
+- Check the Windows Event Logs, particularly Security and System logs, for any related events around the time of the alert to gather more context on the activity.
+- Review the host's security configuration and WinRM settings to ensure they are in line with best practices and have not been altered to allow unauthorized access.
+- Investigate any recent changes or updates on the host that could have introduced vulnerabilities or misconfigurations exploited by the adversary.
+- Correlate the findings with other alerts or incidents in the environment to determine if this activity is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often use WinRM for legitimate remote management tasks, which can trigger the rule. To manage this, users can create exceptions for known administrative IP addresses or user accounts frequently performing these tasks.
+- Automated scripts and tools: Automated scripts or management tools that utilize WinRM for routine operations may also cause false positives. Users should identify these scripts and tools and exclude their associated processes or IP addresses from the rule.
+- Monitoring and security software: Some security and monitoring solutions use WinRM to gather data from remote systems, potentially triggering the rule. Users can whitelist these solutions by excluding their process names or network traffic patterns.
+- Internal network scans: Internal network scans or vulnerability assessments that interact with WinRM ports might be flagged. Users should coordinate with IT teams to recognize these activities and exclude them from detection.
+- Testing environments: In testing or development environments, frequent use of WinRM for testing purposes can lead to false positives. Users can exclude these environments by specifying their IP ranges or hostnames.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation to identify the source of the WinRM connection, including reviewing logs for unusual login attempts or unauthorized access.
+- Terminate any suspicious processes associated with the WinRM remote shell activity, particularly those not originating from legitimate administrative tasks.
+- Change credentials for any accounts that were used during the unauthorized WinRM session to prevent further unauthorized access.
+- Review and enhance logging policies to ensure detailed monitoring of WinRM activities, including successful and failed login attempts, and process creation events.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate WinRM activity with known threat indicators.
+- Restore the system to its operational state by applying the latest security patches and updates, and verifying the integrity of critical system files.
+- Implement network segmentation to limit the ability of adversaries to move laterally within the network using remote services like WinRM.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on secure remote management practices and the risks associated with improper use of WinRM."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_incoming_wmi.toml b/rules/windows/lateral_movement_incoming_wmi.toml
index 0c695c6002d..6d3c8704351 100644
--- a/rules/windows/lateral_movement_incoming_wmi.toml
+++ b/rules/windows/lateral_movement_incoming_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,50 @@ sequence by host.id with maxspan = 2s
    not (process.executable : "?:\\Windows\\System32\\inetsrv\\appcmd.exe" and process.args : "uninstall")
    ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WMI Incoming Lateral Movement
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing processes remotely, often bypassing traditional security controls. The detection rule identifies suspicious WMI activity by monitoring specific network connections and process executions, while filtering out common false positives, to flag potential unauthorized lateral movements.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and timestamp of the suspicious activity to establish a timeline.
+- Examine the network connection details, focusing on the source.ip and destination.port, to determine if the connection originated from a known or trusted source.
+- Check the process.name and process.parent.name fields to verify if the svchost.exe and WmiPrvSE.exe processes are behaving as expected or if they are associated with any known malicious activity.
+- Investigate the user.id associated with the process execution to determine if it aligns with expected administrative activity or if it could indicate unauthorized access.
+- Analyze the process.executable path to identify any unusual or unexpected executables being launched, especially those not excluded by the rule.
+- Utilize Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name = 'WmiPrvSE.exe' OR name = 'svchost.exe';` to list all instances and their command-line arguments.
+- Cross-reference the source.ip with known threat intelligence feeds to check for any history of malicious activity associated with the IP address.
+- Review recent security logs and events on the affected host to identify any other suspicious activities or anomalies around the time of the alert.
+- Check for any recent changes in user permissions or group memberships that could explain the unexpected WMI activity.
+- Consult with system administrators to confirm if the detected WMI activity aligns with any legitimate remote management tasks or scheduled maintenance activities.
+
+### False positive analysis
+
+- Known false positives for the WMI Incoming Lateral Movement rule include legitimate administrative activities where WMI is used for remote management, such as software deployment or system configuration tasks.
+- Common tools that may trigger false positives include Nessus and SCCM, which are often used for network scanning and system management, respectively.
+- To manage these false positives, users can create exceptions for specific processes or user accounts that are known to perform legitimate WMI activities. This can be done by excluding certain process executables or user IDs from the detection rule.
+- Users should regularly review and update their exclusion lists to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+- It is important to monitor the integrity level of processes, as legitimate administrative tasks typically run with higher integrity levels, which can be used as a criterion for exclusion.
+- By understanding the context of WMI usage within their environment, users can better distinguish between legitimate and suspicious activities, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further lateral movement and contain the threat.
+- Verify the legitimacy of the WMI activity by checking if it aligns with known administrative tasks or scheduled jobs.
+- Conduct a thorough investigation of the affected host to identify any unauthorized changes or additional malicious activity.
+- Review and analyze network logs and WMI logs to trace the source of the lateral movement and identify other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed to be malicious.
+- Remove any unauthorized accounts or processes identified during the investigation and reset credentials for affected accounts.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Implement enhanced logging policies to capture detailed WMI activity and network connections for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Apply hardening measures such as restricting WMI access to only necessary accounts and implementing network segmentation to limit lateral movement opportunities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
index 9f0ca208eae..4edf203b40a 100644
--- a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
+++ b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/02"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,49 @@ process where host.os.type == "windows" and event.type == "start" and
  /* excluding shares deletion operation */
  not process.args : "/d*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Mounting Hidden or WebDav Remote Shares
+
+WebDav and hidden remote shares facilitate file sharing and collaboration over networks, often used in enterprise environments. Adversaries exploit these to move laterally or exfiltrate data by mounting shares using tools like net.exe. The detection rule identifies suspicious use of net.exe to mount such shares, focusing on patterns indicative of hidden or WebDav shares, while excluding benign operations like share deletions.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `net.exe` or `net1.exe` in the process name or original file name, as this is crucial for identifying the suspicious activity.
+- Examine the process arguments to verify the use of the "use" command, which indicates an attempt to mount a share.
+- Check for the presence of patterns in the process arguments that match hidden or WebDav shares, such as `\\\\*\\\\*$*`, `\\\\*@SSL\\\\*`, or `http*`, to confirm the nature of the share being accessed.
+- Investigate the parent process of `net1.exe` to ensure it is not `net.exe`, as this could indicate a legitimate operation.
+- Look for any exclusion patterns in the process arguments, such as `/d*`, to rule out share deletion operations.
+- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE name = 'net.exe' OR name = 'net1.exe';` to obtain details such as process ID, parent process, and command line arguments.
+- Correlate the event with other logs to identify any preceding or subsequent suspicious activities, such as unusual network connections or file access patterns.
+- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Check for any recent changes in user permissions or group memberships that could facilitate unauthorized access to remote shares.
+- Review network traffic logs to identify any data exfiltration attempts or connections to known malicious IP addresses associated with the mounted shares.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use net.exe to mount hidden or WebDav shares for routine maintenance or configuration tasks. To manage these, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
+- Automated scripts and tools: Some enterprise environments use automated scripts or third-party tools that rely on net.exe to manage network shares. Users should identify these scripts and tools and exclude their associated processes or command patterns from the detection rule.
+- Backup and synchronization software: Applications like backup solutions or file synchronization services (e.g., OneDrive) might use similar commands to access remote shares. Users can handle these by excluding processes associated with these applications or by specifying known safe network paths.
+- Testing and development environments: In environments where testing of network configurations or software development occurs, net.exe might be used frequently. Users should consider excluding specific development machines or user accounts from the detection rule to reduce noise.
+- User training and awareness: Educating users about the legitimate use of network shares and monitoring for unusual patterns can help distinguish between benign and suspicious activities, allowing for more accurate tuning of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on recent use of net.exe and net1.exe for mounting shares.
+- Review and analyze logs from the affected system and any connected systems to trace the adversary's activities and identify any additional compromised systems.
+- Remove any unauthorized mounted shares and terminate any suspicious processes related to net.exe or net1.exe.
+- Change all potentially compromised credentials and enforce multi-factor authentication to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring visibility into future suspicious activities.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for future incidents.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
+- Harden the environment by disabling unnecessary services, enforcing least privilege access, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_powershell_remoting_target.toml b/rules/windows/lateral_movement_powershell_remoting_target.toml
index d819cf2f387..1f1d148d748 100644
--- a/rules/windows/lateral_movement_powershell_remoting_target.toml
+++ b/rules/windows/lateral_movement_powershell_remoting_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,52 @@ sequence by host.id with maxspan = 30s
    [process where host.os.type == "windows" and 
     event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Incoming Execution via PowerShell Remoting
+
+PowerShell Remoting enables administrators to execute commands on remote Windows systems, facilitating efficient management. However, adversaries can exploit this for lateral movement by executing commands on compromised machines. The detection rule identifies such abuse by monitoring network traffic on specific ports and correlating it with suspicious process activities, indicating potential unauthorized remote command execution.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and timestamp of the suspicious activity to focus the investigation on the relevant system and timeframe.
+- Examine network logs to verify the presence of incoming network traffic on ports 5985 or 5986, which are used for PowerShell Remoting, and confirm the source IP address is external and not a known or trusted internal IP.
+- Check for any recent process start events on the affected host where the parent process is "wsmprovhost.exe" and the child process is not "conhost.exe", indicating potential unauthorized command execution.
+- Use Osquery to list all processes on the affected host that have "wsmprovhost.exe" as a parent process to identify any unusual or unexpected child processes:
+  ```sql
+  SELECT pid, name, path, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'wsmprovhost.exe');
+  ```
+- Investigate the source IP address by checking if it is associated with any known malicious activity or if it belongs to an external network that should not have access to the internal systems.
+- Correlate the timing of the network activity with any user logins or scheduled tasks on the affected host to determine if the activity aligns with legitimate administrative actions.
+- Review Windows Event Logs on the affected host for any additional context around the time of the alert, focusing on security and system logs for any anomalies or related events.
+- Check for any recent changes in user accounts or permissions on the affected host that could indicate unauthorized access or privilege escalation.
+- Analyze any command-line arguments or scripts executed by the suspicious processes to understand the intent and potential impact of the activity.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Scheduled administrative tasks: Regularly scheduled tasks by IT administrators using PowerShell Remoting for legitimate system management can trigger this rule. Users can handle these by creating exceptions for known administrative IP addresses or specific time windows when these tasks are expected to occur.
+- Automated scripts: Automated scripts that use PowerShell Remoting for system monitoring or maintenance might be flagged. To manage this, users can whitelist specific scripts or processes that are verified as non-threatening.
+- Internal security tools: Some security tools use PowerShell Remoting for scanning or compliance checks. Users should identify these tools and exclude their activities from triggering alerts by specifying their process names or executable paths.
+- Development and testing environments: In environments where developers frequently use PowerShell Remoting for testing purposes, these activities might be mistaken for lateral movement. Users can exclude specific development machines or user accounts from the rule to reduce false positives.
+- Remote management software: Software that relies on PowerShell Remoting for remote management might be misinterpreted as suspicious activity. Users should identify such software and configure exceptions based on the software's known network behavior or process characteristics.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Verify the legitimacy of the PowerShell remoting activity by contacting the system owner or administrator to confirm if the activity was authorized.
+- Conduct a thorough investigation of the affected system to identify any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
+- Review network logs and endpoint detection logs to trace the source of the unauthorized access and identify any other potentially compromised systems.
+- If unauthorized access is confirmed, reset credentials for affected accounts and implement multi-factor authentication to prevent future unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the breach.
+- Restore the affected system from a known good backup to ensure that any malicious changes are removed.
+- Implement enhanced logging policies to capture detailed PowerShell activity and network traffic for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Apply system hardening measures, such as disabling unnecessary services and ports, to reduce the attack surface and prevent exploitation of remote services."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_rdp_sharprdp_target.toml b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
index ea6733fab44..d155d4aeed9 100644
--- a/rules/windows/lateral_movement_rdp_sharprdp_target.toml
+++ b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,48 @@ sequence by host.id with maxspan=1m
    not process.name : "conhost.exe"
    ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential SharpRDP Behavior
+
+Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement within a network, using tools like SharpRDP to execute commands on remote machines. The detection rule identifies suspicious RDP activity by monitoring for specific registry changes and process executions, indicating potential misuse of RDP for unauthorized access.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id where the suspicious activity was detected, as this will be the focal point of the investigation.
+- Examine the network event logs to confirm the presence of incoming RDP connections on port 3389, noting the source IP address and ensuring it is not a loopback address (127.0.0.1 or ::1).
+- Investigate the registry change event to verify the modification of the RunMRU registry key by the process explorer.exe, focusing on the presence of suspicious strings such as cmd.exe, powershell.exe, taskmgr, or \\\\tsclient\\\\*.exe.
+- Analyze the process execution logs to identify any processes started with parent processes cmd.exe, powershell.exe, or taskmgr.exe, and ensure that conhost.exe is not the process name.
+- Correlate the timestamps of the network, registry, and process events to confirm they occurred within the specified 1-minute window, indicating a sequence of potentially malicious actions.
+- Use Osquery to gather additional context on the affected host by running a query to list recent RDP sessions: `SELECT * FROM rdp_connections WHERE state = 'active';` to identify any unusual or unauthorized sessions.
+- Investigate the user account associated with the RDP session to determine if it is a legitimate user or potentially compromised, checking for any anomalies in login patterns or privileges.
+- Check for any additional registry changes or process executions on the host that might indicate further malicious activity or persistence mechanisms.
+- Review historical data for the source IP address to determine if it has been involved in previous suspicious activities or if it is known to be associated with malicious behavior.
+- Consult threat intelligence sources to gather information on SharpRDP and similar tools, assessing if there are any known indicators of compromise (IOCs) that match the observed activity.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use RDP for routine maintenance and troubleshooting, which can trigger the detection rule if they execute commands like cmd, powershell, or taskmgr. To manage this, users can create exceptions for known administrator accounts or specific IP addresses that regularly perform these tasks.
+- Automated scripts: Some organizations use automated scripts that remotely execute commands via RDP for software updates or system checks. These scripts might mimic SharpRDP behavior. Users can exclude these scripts by identifying their unique process names or command-line arguments and adding them to an exception list.
+- Remote support tools: Third-party remote support tools may use similar mechanisms to SharpRDP for legitimate remote assistance. Users should identify these tools and exclude their associated processes or network activities from the detection rule.
+- Testing environments: In environments where security testing or penetration testing is conducted, SharpRDP or similar tools might be used intentionally. Users can exclude specific testing IP ranges or hostnames to prevent false positives during these activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and unauthorized access.
+- Conduct a thorough investigation to confirm the presence of SharpRDP or similar tools by analyzing logs and system artifacts.
+- Terminate any suspicious processes identified during the investigation, particularly those related to cmd.exe, powershell.exe, taskmgr.exe, or tsclient.
+- Review and restore any altered registry settings to their original state to prevent unauthorized command execution.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed RDP session activities, registry changes, and process executions for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
+- Educate users and administrators on secure RDP practices and the risks associated with unauthorized remote access tools.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
index 232552123a3..a6157ad447a 100644
--- a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
+++ b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,49 @@ process where host.os.type == "windows" and event.type == "start" and
     process.name : "robocopy.exe"
   ) and process.args : "*\\\\*\\*$*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Remote File Copy to a Hidden Share
+
+In Windows environments, hidden network shares are often used for legitimate administrative tasks, allowing file transfers without user visibility. However, adversaries exploit these shares for lateral movement or data exfiltration by copying files remotely. The detection rule identifies suspicious activities by monitoring command-line tools like cmd.exe and powershell.exe for file operations targeting hidden shares, flagging potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (e.g., cmd.exe, powershell.exe, xcopy.exe, robocopy.exe) and arguments used, focusing on those that match the query criteria such as "copy*", "move*", "cp", "mv", and paths containing "*\\\\\\\\*\\\\*$*".
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time for additional context.
+- Identify the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Investigate the source and destination IP addresses involved in the file copy operation to assess if they are part of the organization's network or if they are external and potentially malicious.
+- Examine the parent process of the flagged process to understand how the suspicious process was initiated and if it was part of a larger chain of events.
+- Use Osquery to gather additional context about the system involved. For example, run the following query to list all network shares on the system: `SELECT * FROM shares WHERE name LIKE '%$';`
+- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized access to hidden shares.
+- Review system logs for any other unusual activities or errors that coincide with the time of the alert, which might indicate a broader attack or misconfiguration.
+- Investigate any recent login attempts or authentication failures on the involved systems to identify potential unauthorized access attempts.
+- Cross-reference the event with known threat intelligence sources to determine if the IP addresses, file paths, or user accounts have been associated with known malicious activities.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often use hidden shares for routine maintenance and file transfers, which can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks.
+- Backup operations: Automated backup processes may use hidden shares to store data, leading to false positives. Users can exclude backup software processes or designate specific time windows when these operations are expected.
+- Software updates and deployments: IT departments might deploy software updates or patches using hidden shares. To handle these, users can whitelist certain deployment tools or scripts that are verified and regularly used.
+- Monitoring and security tools: Some security and monitoring tools might access hidden shares for log collection or system checks. Users should identify and exclude these tools from triggering the rule by specifying their process names or paths.
+- Development and testing environments: In environments where developers frequently test applications, file operations to hidden shares might be common. Users can create exceptions for specific development machines or user accounts to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on recent file transfers and access logs.
+- Review and analyze the command-line history and process execution details to understand the adversary's actions and objectives.
+- Remove any unauthorized accounts or access permissions that may have been established during the intrusion.
+- Restore the system from a known good backup to ensure no malicious modifications persist.
+- Implement enhanced logging policies to capture detailed command-line activity and network share access for future monitoring.
+- Integrate security solutions with SIEM systems to correlate events and improve detection capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Apply security patches and updates to all systems to mitigate known vulnerabilities that could be exploited for lateral movement.
+- Educate users and administrators on the risks associated with hidden shares and enforce strict access controls and monitoring."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_remote_service_installed_winlog.toml b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
index 52e69a456f1..562262e9a1e 100644
--- a/rules/windows/lateral_movement_remote_service_installed_winlog.toml
+++ b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -63,6 +63,50 @@ event.outcome=="success" and source.ip != null and source.ip != "127.0.0.1" and
                 "?:\\Windows\\SysWOW64\\NwxExeSvc\\NwxExeSvc.exe",
                 "?:\\Windows\\System32\\taskhostex.exe")]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Remote Windows Service Installed
+
+Windows services are background processes that can be configured to start automatically, manually, or be triggered by specific events. Adversaries may exploit this by installing malicious services remotely to maintain persistence or facilitate lateral movement within a network. The detection rule identifies suspicious service installations following a network logon, excluding known legitimate services, to flag potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `winlog.logon.id` and `winlog.computer_name` associated with the suspicious service installation.
+- Verify the `source.ip` address from the authentication event to determine if it is from a known or trusted source within the network.
+- Check the `winlog.event_data.ServiceFileName` to identify the installed service's executable path and compare it against known legitimate services.
+- Use Osquery to list all services on the affected machine and identify any unfamiliar or suspicious services. Example query: `SELECT name, path, start_type FROM services WHERE path LIKE '%<suspicious_service_name>%';`
+- Investigate the user account associated with the `winlog.logon.id` to determine if it has a history of legitimate administrative actions or if it might be compromised.
+- Correlate the timestamp of the service installation with other logs to identify any concurrent suspicious activities, such as file modifications or registry changes.
+- Examine the service's executable file for any signs of tampering or unusual attributes, such as recent modification dates or unexpected file sizes.
+- Check for any recent changes in user permissions or group memberships that might have facilitated the unauthorized service installation.
+- Review network logs to identify any unusual outbound connections from the affected machine following the service installation.
+- Consult threat intelligence sources to determine if the service name or executable path is associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Known false positives for the Remote Windows Service Installed rule often arise from legitimate administrative activities, such as IT staff installing or updating software remotely, which can trigger service creation events.
+- Frequent non-threatening behaviors may include automated deployment tools or scripts that install services as part of routine maintenance or software updates.
+- To manage these false positives, users can create exceptions for specific service file paths or LogonIds that are known to be associated with legitimate administrative tasks.
+- Users should regularly review and update the list of excluded service file paths to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats.
+- Implementing a whitelist of trusted IP addresses or user accounts that are known to perform legitimate service installations can help reduce noise in the detection rule.
+- Monitoring and correlating these events with other security logs can provide additional context to distinguish between benign and malicious activities, aiding in the refinement of exceptions.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Verify the legitimacy of the installed service by checking its origin, digital signature, and associated files.
+- Terminate any malicious services identified and remove associated files from the system.
+- Conduct a thorough investigation of the source IP address to determine if it is part of a larger attack campaign.
+- Review recent logon events and network activity to identify any other compromised accounts or systems.
+- Reset credentials for any accounts that were used in the suspicious logon events to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed information on service installations and network logons for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
index d6bf620d013..0185455a4fe 100644
--- a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
+++ b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,6 +68,48 @@ any where host.os.type == "windows" and
     "?:\\Windows\\System32\\hvsirdpclient.exe"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious RDP ActiveX Client Loaded
+
+The Remote Desktop Services ActiveX Client, mstscax.dll, facilitates remote desktop connections, enabling users to access and control remote systems. Adversaries may exploit this by loading the DLL in unauthorized contexts to perform lateral movement within a network. The detection rule identifies unusual loading of mstscax.dll outside typical system paths, flagging potential misuse indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `mstscax.dll` being loaded from an unusual path, as indicated by the `process.executable` field.
+- Verify the legitimacy of the process by checking the `process.executable` path against known safe paths and any additional paths specific to your environment.
+- Examine the `host.os.type` field to ensure the alert pertains to a Windows system, as this rule is specific to Windows environments.
+- Investigate the parent process of the suspicious activity using the `event.category` and `event.action` fields to determine if the process was initiated by a legitimate user or application.
+- Use Osquery to gather more information about the process and its parent. For example, run the following query to list processes with their parent process IDs and paths: `SELECT pid, name, path, parent FROM processes WHERE path LIKE '%mstscax.dll%';`
+- Check the `file.name` field to confirm the file involved is indeed `mstscax.dll` and not a similarly named file that could be used to obfuscate malicious activity.
+- Analyze the network activity associated with the process to identify any unusual remote connections that could indicate lateral movement attempts.
+- Review recent user activity on the affected host to determine if any legitimate user actions could explain the loading of `mstscax.dll` from an unexpected location.
+- Correlate the alert with other security events or logs from the same host or network segment to identify any patterns or additional indicators of compromise.
+- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize similar techniques involving `mstscax.dll` for lateral movement.
+
+### False positive analysis
+
+- Known false positives for the Suspicious RDP ActiveX Client Loaded rule may include legitimate applications or system processes that load mstscax.dll for valid remote desktop functionalities. These can occur in environments where remote desktop services are frequently used for administrative purposes.
+- Users can handle these false positives by identifying and excluding specific processes or paths that are known to be safe. This can be done by adding exceptions to the detection rule for processes that are verified as non-threatening, such as those associated with trusted remote management tools or internal IT operations.
+- To manage false positives effectively, users should monitor the frequency and context of alerts. If a particular process or path consistently triggers alerts but is confirmed to be legitimate, it should be added to the exclusion list in the detection rule.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation to confirm the unauthorized loading of mstscax.dll, reviewing logs and correlating with other security events.
+- Terminate any suspicious processes associated with the unauthorized mstscax.dll loading to halt any ongoing malicious activity.
+- Remove any unauthorized or malicious files and restore the system to a known good state using backups or system restore points.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed information on DLL loads, process executions, and network connections for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for lateral movement.
+- Conduct a review of user access permissions and implement least privilege principles to reduce the risk of unauthorized access.
+- Educate users on recognizing phishing attempts and other social engineering tactics that adversaries may use to gain initial access to the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
index 1694f8e9ad5..53def153720 100644
--- a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
+++ b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,49 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
    file.path : ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
                 "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Lateral Movement via Startup Folder
+
+The Windows Startup folder is a mechanism that allows programs to run automatically upon user logon or system reboot. Adversaries exploit this by placing malicious files in the Startup folder of a remote system, often accessed via RDP or SMB, to ensure persistence and facilitate lateral movement. The detection rule identifies suspicious file activities in these folders, focusing on processes like mstsc.exe, which may indicate unauthorized access and file creation, signaling potential lateral movement attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process name involved in the suspicious activity, focusing on the `file.path` and `process.name` fields.
+- Verify the legitimacy of the process by checking the `process.name` and `process.pid` fields to determine if `mstsc.exe` or a process with PID 4 was involved, as these are indicative of RDP or SMB activity.
+- Use Osquery to list all files in the Startup folder to identify any unexpected or unauthorized files. Example query: `SELECT path, filename, md5 FROM file WHERE directory LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\%' OR directory LIKE 'C:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\%';`
+- Investigate the file creation or modification time to determine if it aligns with known user activity or if it occurred during unusual hours.
+- Check the file hash against known malware databases to identify if the file is a known threat.
+- Review recent RDP or SMB connection logs to identify any unusual or unauthorized access attempts that coincide with the file creation or modification event.
+- Analyze the user account associated with the process to determine if it has been compromised or if it has unusual permissions or activity.
+- Correlate the event with other security alerts or logs to identify if there are additional indicators of compromise or related suspicious activities.
+- Investigate the parent process of `mstsc.exe` or the process with PID 4 to understand the origin of the connection and whether it was initiated by a legitimate user or process.
+- Conduct a historical search for similar file creation events in the Startup folder to determine if this is an isolated incident or part of a broader pattern of activity.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create files in the Startup folder, triggering the detection rule. Users can handle this by verifying the software's authenticity and adding it to an exception list if deemed safe.
+- System administrators might use scripts or tools that modify the Startup folder for maintenance or configuration purposes. These activities should be documented, and exceptions can be created for known administrative processes.
+- Remote desktop management tools or services that utilize mstsc.exe for legitimate purposes might inadvertently match the rule's criteria. Users should ensure these tools are authorized and consider excluding their specific file paths or process names.
+- Automated backup or synchronization software that interacts with the Startup folder could cause false positives. Users should verify the software's legitimacy and exclude its activities if they are part of routine operations.
+- In environments where shared systems are common, multiple users might have legitimate reasons to modify the Startup folder. Organizations should establish a baseline of expected behavior and create exceptions for known, non-threatening activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and contain the threat.
+- Verify the presence of unauthorized files in the Startup folder and remove any malicious scripts or executables identified.
+- Conduct a thorough investigation to determine the source of the unauthorized access, focusing on RDP and SMB logs to identify potential entry points.
+- Change credentials for any accounts that may have been compromised, especially those with administrative privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed file creation and modification events, particularly in critical directories like the Startup folder.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting RDP access to trusted IP addresses, enabling multi-factor authentication, and regularly auditing user permissions and access rights."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_via_wsus_update.toml b/rules/windows/lateral_movement_via_wsus_update.toml
index bd697c08064..d88800ca44e 100644
--- a/rules/windows/lateral_movement_via_wsus_update.toml
+++ b/rules/windows/lateral_movement_via_wsus_update.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,48 @@ process.executable : (
 ) and
 (process.name : "psexec64.exe" or ?process.pe.original_file_name : "psexec.c")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential WSUS Abuse for Lateral Movement
+
+Windows Server Update Services (WSUS) is a system that manages updates for Microsoft products, ensuring that only trusted, signed binaries are executed. However, adversaries can exploit WSUS to execute Microsoft-signed tools like PsExec for lateral movement within a network. The detection rule identifies suspicious processes initiated by WSUS, specifically targeting the execution of PsExec, which is indicative of potential abuse for unauthorized lateral movement.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the suspicious process execution, focusing on the `process.parent.name` field to verify if `wuauclt.exe` is the parent process.
+- Examine the `process.executable` path to ensure it matches the specified paths in the query, indicating potential abuse of the WSUS download directory.
+- Check the `process.name` and `process.pe.original_file_name` fields to confirm the execution of `psexec64.exe` or `psexec.c`, which are indicative of lateral movement attempts.
+- Investigate the timeline of events leading up to the alert by reviewing related process creation events to identify any preceding suspicious activities.
+- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name = 'psexec64.exe' OR name = 'psexec.c';` to identify other instances of these processes running on the host.
+- Analyze network logs to identify any unusual outbound connections from the affected host that may indicate lateral movement attempts.
+- Review user account activity on the affected host to determine if any unauthorized or unexpected accounts were used to execute the suspicious processes.
+- Check for any recent changes or updates to the WSUS configuration that could have been exploited to facilitate the execution of unauthorized binaries.
+- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attack activities.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar WSUS abuse techniques.
+
+### False positive analysis
+
+- Legitimate administrative activities: In some environments, system administrators may use PsExec for legitimate purposes, such as deploying software or performing maintenance tasks. These activities can trigger the detection rule, leading to false positives.
+- Automated update scripts: Organizations may have automated scripts that utilize PsExec for deploying updates or patches across the network. These scripts, if executed by WSUS, can be mistaken for malicious activity.
+- Testing and development environments: In testing or development environments, PsExec might be used frequently for testing purposes, which could lead to false positives if these environments are not properly excluded from monitoring.
+- To manage these false positives, users can create exceptions for known legitimate activities by excluding specific processes or scripts that are regularly used for administrative tasks. Additionally, users can refine the detection rule to exclude certain hosts or environments, such as development or testing servers, where PsExec usage is expected and non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to confirm the presence of PsExec execution initiated by WSUS and identify any other potentially compromised systems.
+- Review and analyze logs from WSUS, endpoint detection and response (EDR) tools, and network traffic to trace the adversary's activities and entry points.
+- Remove unauthorized PsExec binaries and any other malicious tools or scripts found on the affected systems.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
+- Reset credentials for accounts that were accessed or potentially compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on WSUS and related services.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection of similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting WSUS permissions and monitoring for unusual process executions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ad_adminsdholder.toml b/rules/windows/persistence_ad_adminsdholder.toml
index 943a4663f0c..ad1a243d54b 100644
--- a/rules/windows/persistence_ad_adminsdholder.toml
+++ b/rules/windows/persistence_ad_adminsdholder.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/31"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,50 @@ query = '''
 event.action:("Directory Service Changes" or "directory-service-object-modified") and event.code:5136 and
   winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AdminSDHolder Backdoor
+
+The AdminSDHolder object in Active Directory is crucial for maintaining consistent permissions across privileged accounts. It ensures that any changes to these accounts are reverted to match the AdminSDHolder's settings. Adversaries exploit this by modifying the AdminSDHolder to create persistent backdoors, allowing unauthorized access. The detection rule identifies such modifications by monitoring specific directory service events, signaling potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.action field includes "Directory Service Changes" or "directory-service-object-modified" and the event.code is 5136, indicating a modification to the directory service object.
+- Verify the winlog.event_data.ObjectDN field to ensure it matches CN=AdminSDHolder,CN=System*, confirming the specific object of interest.
+- Check the timestamp of the event to determine when the modification occurred and correlate it with any other suspicious activities or alerts around the same time.
+- Identify the user account associated with the modification by examining the event data for the user who initiated the change, and assess whether this account has a legitimate reason to modify the AdminSDHolder object.
+- Investigate the source IP address or host from which the modification was made to determine if it is a known and trusted system within the network.
+- Use Osquery to gather additional context on the system involved. For example, run the following query to list recent changes to Active Directory objects: `SELECT * FROM ad_config WHERE distinguished_name LIKE 'CN=AdminSDHolder,CN=System%' AND last_modified > DATE_SUB(NOW(), INTERVAL 1 DAY);`
+- Review the history of changes to the AdminSDHolder object by querying the security logs for previous event.code 5136 entries related to this object to identify any patterns or repeated unauthorized modifications.
+- Cross-reference the user account and system involved with known threat intelligence sources to check for any indicators of compromise or known malicious activity.
+- Analyze any related logs or alerts from endpoint detection and response (EDR) tools to identify potential lateral movement or privilege escalation attempts following the modification.
+- Document all findings and maintain a timeline of events to support further investigation and potential escalation to incident response teams if necessary.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or changes made by authorized IT personnel to the AdminSDHolder object can trigger alerts. These are often part of legitimate maintenance activities.
+- Scheduled security audits: Automated scripts or tools used during security audits may modify or access the AdminSDHolder object, leading to false positives.
+- Software updates: Certain software updates, especially those related to security or directory services, might involve changes to the AdminSDHolder object.
+- To manage these false positives, users can create exceptions for known and verified administrative actions by whitelisting specific user accounts or processes that are authorized to make changes.
+- Implementing a review process for alerts can help distinguish between legitimate changes and potential threats, ensuring that only suspicious activities are flagged.
+- Regularly updating the list of authorized personnel and tools that interact with the AdminSDHolder object can help in maintaining accurate exceptions and reducing false positives.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further unauthorized access.
+- Review recent changes to the AdminSDHolder object and identify any unauthorized modifications.
+- Revert any unauthorized changes to the AdminSDHolder object to restore original permissions.
+- Conduct a thorough investigation to identify the source of the modification, including reviewing logs and correlating with other security events.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging for Active Directory changes, focusing on critical objects like AdminSDHolder, to improve detection of future unauthorized modifications.
+- Integrate security information and event management (SIEM) solutions with Active Directory to automate detection and alerting of suspicious activities.
+- Review and update access controls and permissions for privileged accounts to ensure they adhere to the principle of least privilege.
+- Conduct a security audit of the Active Directory environment to identify and remediate any other potential vulnerabilities or misconfigurations.
+- Educate and train IT staff and administrators on the risks associated with AdminSDHolder modifications and the importance of monitoring privileged account activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_app_compat_shim.toml b/rules/windows/persistence_app_compat_shim.toml
index 888afb2ac42..0be8a5e0563 100644
--- a/rules/windows/persistence_app_compat_shim.toml
+++ b/rules/windows/persistence_app_compat_shim.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,48 @@ registry where host.os.type == "windows" and event.type == "change" and
                          "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", 
                          "?:\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Installation of Custom Shim Databases
+
+Application Compatibility Shim databases are used in Windows to ensure older applications run smoothly on newer OS versions by applying compatibility fixes. However, attackers can exploit this feature to maintain persistence and execute arbitrary code by installing malicious custom shim databases. The detection rule identifies changes in specific registry paths associated with these databases, excluding known legitimate processes, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path involved matches one of the specified paths in the detection rule, focusing on paths like "HKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\AppCompatFlags\\\\Custom\\\\*.sdb".
+- Check the process executable that triggered the alert to ensure it is not one of the known legitimate processes listed in the exclusion list, such as "NwSapSetup.exe" or "kavfs.exe".
+- Investigate the timestamp of the registry change event to correlate with any other suspicious activities or changes on the system around the same time.
+- Use Osquery to list all custom shim databases installed on the system with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\AppCompatFlags\\\\Custom\\\\%'`.
+- Examine the contents and metadata of the identified custom shim database files to determine their origin and purpose.
+- Cross-reference the identified shim database files with known good or bad hashes using threat intelligence sources or a file reputation service.
+- Investigate the user account context under which the registry change was made to determine if it aligns with expected administrative activity.
+- Review system logs and security events for any signs of privilege escalation or unauthorized access that could have led to the installation of the custom shim database.
+- Check for any recent software installations or updates that might have legitimately introduced new shim databases, ensuring they align with organizational policies.
+- Analyze network activity from the host around the time of the registry change for any unusual outbound connections that could indicate data exfiltration or command and control communication.
+
+### False positive analysis
+
+- Known false positives for the Installation of Custom Shim Databases rule include legitimate software installations or updates that modify the registry paths associated with shim databases. These can include software from vendors like SAP and Kaspersky, which are known to use these registry paths during their installation or update processes.
+- Users can handle these false positives by creating exceptions for specific processes that are known to be legitimate. This can be done by adding the executable paths of these trusted applications to the exclusion list in the detection rule, ensuring that these processes do not trigger alerts.
+- It is important to regularly review and update the list of excluded processes to ensure that only verified and trusted applications are excluded, minimizing the risk of overlooking potential threats.
+- Users should also monitor for any new software installations or updates that might interact with the registry paths in question, and assess whether these should be added to the exclusion list based on their legitimacy and frequency of occurrence.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the custom shim database installation, focusing on recent changes and unauthorized access.
+- Review and analyze the process execution logs to determine if any known malicious executables were involved in the shim database installation.
+- Remove any unauthorized or suspicious shim databases from the registry paths identified in the detection rule.
+- Restore the system to a known good state using backups or system restore points, ensuring that no malicious changes persist.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by attackers.
+- Educate users and administrators on the risks associated with shim databases and the importance of monitoring for unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_appcertdlls_registry.toml b/rules/windows/persistence_appcertdlls_registry.toml
index 8ced36769d3..9a9cdac8f64 100644
--- a/rules/windows/persistence_appcertdlls_registry.toml
+++ b/rules/windows/persistence_appcertdlls_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,49 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Registry Persistence via AppCert DLL
+
+AppCert DLLs are dynamic link libraries that can be configured to load into every process that uses certain API functions, providing a mechanism for legitimate software to extend or modify process behavior. However, adversaries exploit this by inserting malicious DLLs into the registry path associated with AppCert DLLs, ensuring their code executes whenever a process is created. The detection rule identifies changes to specific registry paths linked to AppCert DLLs, signaling potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path that triggered the alert, focusing on the `registry.path` field to determine which AppCert DLL path was modified.
+- Check the `event.type` field to confirm that the change event is indeed related to a modification, as this indicates a potential persistence attempt.
+- Use Osquery to list all DLLs currently configured in the AppCertDLLs registry path with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\%'`.
+- Investigate the timestamp of the registry change to correlate it with other system events or user activities that occurred around the same time.
+- Examine the system's event logs, particularly the Security and System logs, for any suspicious activities or anomalies that coincide with the registry change.
+- Identify the user account associated with the registry change by reviewing the `user.name` field in the alert, and investigate the user's recent activities and access patterns.
+- Check for any known malicious or suspicious DLLs by comparing the modified DLLs against threat intelligence databases or using a malware analysis tool.
+- Investigate the parent process that initiated the registry change by correlating process creation events with the timestamp of the registry modification.
+- Review network activity logs for any unusual outbound connections or data transfers that might suggest communication with a command and control server.
+- Conduct a historical search for similar registry changes on the host or across the network to determine if this is an isolated incident or part of a broader pattern.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the AppCert DLL registry paths as part of their normal operation, leading to false positives. Users should verify if the changes coincide with known software updates or installations.
+- Security software or system management tools might also interact with these registry paths to enhance security or manage system configurations, which can trigger alerts. Users can create exceptions for these trusted applications to reduce noise.
+- Custom enterprise applications developed in-house may use AppCert DLLs for legitimate process management purposes. It's important to document these applications and exclude their known behaviors from triggering alerts.
+- Regular audits of the registry changes can help identify patterns of benign activity, allowing users to refine detection rules and exclude non-threatening behaviors from being flagged.
+- Users should maintain a whitelist of known good DLLs and their associated registry paths to quickly identify and exclude them from false positive alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation to confirm the presence of unauthorized AppCert DLLs by reviewing the registry paths specified in the detection rule.
+- Utilize endpoint detection and response (EDR) tools to identify any additional indicators of compromise (IOCs) related to the AppCert DLL persistence technique.
+- Remove any unauthorized or suspicious DLLs found in the AppCertDLLs registry path and restore the registry to its previous state if possible.
+- Perform a comprehensive malware scan on the affected system to identify and remove any additional malicious software.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to monitor changes to critical registry paths and integrate with a security information and event management (SIEM) system for real-time alerts.
+- Review and update endpoint protection policies to prevent unauthorized modifications to the registry and ensure that all systems are running the latest security patches.
+- Educate users on recognizing and reporting suspicious activities to reduce the risk of future incidents.
+- Consider implementing application whitelisting to prevent unauthorized DLLs from being loaded into processes, thereby hardening the system against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_browser_extension_install.toml b/rules/windows/persistence_browser_extension_install.toml
index 7bcc2ade5b5..c8d2bf7290e 100644
--- a/rules/windows/persistence_browser_extension_install.toml
+++ b/rules/windows/persistence_browser_extension_install.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,49 @@ file where host.os.type == "windows" and event.type : "creation" and
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Browser Extension Install
+
+Browser extensions enhance functionality in web browsers but can be exploited by adversaries to gain persistence or execute malicious activities. Attackers may disguise harmful extensions as legitimate or use compromised systems to install them. The detection rule identifies suspicious extension installations by monitoring specific file creation patterns in user directories, focusing on Firefox and Chromium-based browsers, while excluding known safe processes.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file name and path involved in the suspicious extension installation, focusing on the `file.name` and `file.path` fields.
+- Verify the process responsible for the file creation by checking the `process.name` field to ensure it is not a known safe process like `firefox.exe` with legitimate extension names.
+- Cross-reference the file path with known directories for Firefox and Chromium-based browsers to confirm the legitimacy of the extension installation location.
+- Use Osquery to list all installed extensions for the affected browser. For Firefox, run: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\%\\\\Profiles\\\\%\\\\Extensions\\\\%' AND path LIKE '%.xpi';`
+- For Chromium-based browsers, use Osquery to query installed extensions: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Local\\\\%\\\\User Data\\\\Webstore Downloads\\\\%' AND path LIKE '%.crx';`
+- Investigate the origin of the extension by checking the browser's extension management interface or settings to see if the extension is listed and if it provides any additional information about its source.
+- Check the browser's history and download logs to identify any recent downloads or installations that coincide with the alert timestamp.
+- Analyze the system for any signs of compromise that could have led to unauthorized extension installation, such as unusual network activity or other suspicious file creations.
+- Consult threat intelligence sources to determine if the extension name or hash is associated with known malicious activity.
+- Document findings and gather all relevant evidence, including file hashes, paths, and process details, to support further analysis or escalation if needed.
+
+### False positive analysis
+
+- Known false positives may occur when legitimate browser extensions are installed or updated, especially if they are not from the official browser stores but are still safe and necessary for business operations.
+- Language packs and dictionary extensions for Firefox, such as those from `firefox.mozilla.org` and `dictionaries.addons.mozilla.org`, are common false positives and should be excluded from alerts.
+- Users can manage false positives by creating exceptions for specific processes or file paths that are verified as safe, ensuring that these are regularly reviewed and updated to reflect any changes in legitimate extension usage.
+- Regularly update the list of known safe processes and file paths to include any new legitimate extensions that are frequently used within the organization, reducing unnecessary alerts.
+- Consider implementing a whitelist of approved extensions and processes, which can be cross-referenced during the detection process to minimize false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the malicious extension.
+- Verify the legitimacy of the detected browser extension by checking its source and comparing it against known malicious extensions.
+- Remove the suspicious browser extension from the affected browser to eliminate the immediate threat.
+- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats.
+- Review system and browser logs to trace the origin of the extension installation and identify any potential security breaches.
+- Escalate the incident to the security team if the extension is confirmed to be part of a larger attack or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed browser activity and file creation events for future investigations.
+- Integrate threat intelligence feeds to automatically update and block known malicious extensions and sources.
+- Restore the system to its operational state by ensuring all security patches and updates are applied to the operating system and browsers.
+- Harden the system by enforcing strict browser extension policies, such as allowing only extensions from trusted sources and regularly reviewing installed extensions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_evasion_registry_ifeo_injection.toml b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
index 783c763a025..92d5cfcfe95 100644
--- a/rules/windows/persistence_evasion_registry_ifeo_injection.toml
+++ b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,51 @@ registry where host.os.type == "windows" and event.type == "change" and
     /* add FPs here */
   not registry.data.strings regex~ ("""C:\\Program Files( \(x86\))?\\ThinKiosk\\thinkiosk\.exe""", """.*\\PSAppDeployToolkit\\.*""")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Image File Execution Options Injection
+
+Image File Execution Options (IFEO) is a Windows feature that allows developers to debug applications by specifying an alternative executable to run instead of the original. Adversaries exploit this by setting a debugger to execute malicious code, achieving persistence. The detection rule identifies changes to specific registry keys associated with IFEO, flagging potential misuse by monitoring for suspicious executables being set as debuggers.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path and value that triggered the alert, focusing on the `registry.path` and `registry.value` fields.
+- Verify the legitimacy of the executable set as the debugger by examining the `registry.data.strings` field to identify any suspicious or unknown executables.
+- Cross-reference the suspicious executable with known malicious file hashes or signatures using threat intelligence sources.
+- Use Osquery to list all entries under the Image File Execution Options registry key to identify any other potentially malicious configurations:
+  ```sql
+  SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Image File Execution Options\\\\%';
+  ```
+- Investigate the process creation history on the host to determine if the suspicious executable has been executed, using event logs or endpoint detection and response (EDR) tools.
+- Check for any recent changes to the registry keys by reviewing the `event.type` field for "change" events and correlating with user activity logs to identify the responsible user or process.
+- Analyze the system's startup and scheduled tasks to ensure no additional persistence mechanisms are in place that could be related to the suspicious executable.
+- Review network activity logs for any unusual outbound connections initiated by the suspicious executable, which could indicate command and control communication.
+- Examine the file properties and metadata of the suspicious executable to gather information about its origin, such as creation date, digital signature, and file path.
+- Consult with the system owner or user to verify if the executable was intentionally installed or configured, and gather any additional context about recent software installations or updates.
+
+### False positive analysis
+
+- Known false positives for the Image File Execution Options Injection rule include legitimate software that uses the IFEO feature for debugging or monitoring purposes, such as ThinKiosk and PSAppDeployToolkit. These applications may set themselves as debuggers or monitor processes, which can trigger the detection rule.
+- To manage these false positives, users can create exceptions in the detection rule by adding specific paths or patterns to the exclusion list. For example, the rule already excludes paths like `C:\\Program Files\\ThinKiosk\\thinkiosk.exe` and any path containing `PSAppDeployToolkit`.
+- Users should regularly review and update the exclusion list to include other known benign applications that utilize IFEO for legitimate purposes, ensuring that the detection rule remains effective without generating unnecessary alerts.
+- It is important to maintain a balance between excluding known false positives and ensuring that the rule still detects potential malicious activity. Users should conduct thorough testing and validation before adding new exclusions to avoid missing genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation to identify the malicious executable set as a debugger by reviewing the registry changes and correlating with known threat intelligence.
+- Remove or revert any unauthorized changes to the registry keys associated with Image File Execution Options and SilentProcessExit.
+- Perform a comprehensive malware scan on the affected system using updated antivirus or endpoint detection and response (EDR) tools.
+- Review system and security logs to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if multiple systems are affected.
+- Implement enhanced logging policies to monitor registry changes and process executions, ensuring that future suspicious activities are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and contextual analysis.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Harden the system by implementing least privilege principles, disabling unnecessary services, and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_group_modification_by_system.toml b/rules/windows/persistence_group_modification_by_system.toml
index a652ef77e0b..e29ff57d98f 100644
--- a/rules/windows/persistence_group_modification_by_system.toml
+++ b/rules/windows/persistence_group_modification_by_system.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,48 @@ winlog.event_data.SubjectUserSid : "S-1-5-18" and
 /* DOMAIN_USERS and local groups */
 not group.id : "S-1-5-21-*-513"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Active Directory Group Modification by SYSTEM
+
+Active Directory (AD) is a critical component in many enterprise environments, managing user and group permissions. SYSTEM, a highly privileged account, should not typically modify AD groups. Adversaries gaining SYSTEM privileges on a domain controller can exploit this to escalate privileges by adding users to sensitive groups. The detection rule identifies such anomalies by monitoring specific event codes and user SIDs, flagging unauthorized group modifications by SYSTEM, thus alerting to potential security breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event code "4728" and the SubjectUserSid "S-1-5-18" to ensure it matches the criteria for SYSTEM account modifications.
+- Check the specific group ID involved in the modification to determine if it is a sensitive group, excluding known safe groups like "S-1-5-21-*-513".
+- Correlate the timestamp of the event with other logs to identify any preceding or subsequent suspicious activities on the domain controller.
+- Investigate the source IP address and hostname from which the SYSTEM account modification was initiated to identify potential unauthorized access points.
+- Examine recent changes in user privileges or group memberships on the domain controller to identify any unusual patterns or unauthorized escalations.
+- Utilize Osquery to gather additional context on the domain controller. For example, run the following query to list recent group modifications: `SELECT * FROM ad_group_membership WHERE action = 'add' AND user_sid = 'S-1-5-18';`
+- Analyze the event logs for any signs of privilege escalation techniques, such as the exploitation of vulnerabilities or abuse of default group privileges.
+- Review the security patches and configurations on the domain controller to ensure they are up-to-date and not susceptible to known vulnerabilities.
+- Check for any recent changes in the domain controller's security policies or configurations that could have inadvertently allowed SYSTEM account modifications.
+- Consult with the IT team to verify if there were any legitimate administrative tasks performed that could explain the SYSTEM account's involvement in group modifications.
+
+### False positive analysis
+
+- Scheduled tasks or automated processes running under the SYSTEM account may legitimately modify AD groups, leading to false positives. Users can handle these by identifying and documenting such tasks, then creating exceptions in the detection rule to exclude these specific activities.
+- Certain security or management software might operate under the SYSTEM account and perform group modifications as part of their normal operations. Users should verify the legitimacy of these software actions and adjust the detection rule to exclude these known benign activities.
+- During system maintenance or updates, administrators might temporarily use SYSTEM privileges to modify groups. Users should ensure that such activities are logged and approved, and consider temporarily disabling the rule or adding exceptions during these periods to prevent false alerts.
+- In environments where SYSTEM account usage is more common due to legacy applications or configurations, users should conduct a thorough review to understand the context and adjust the detection rule to accommodate these specific scenarios without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or changes.
+- Verify the legitimacy of the group modification by reviewing recent changes in Active Directory and cross-referencing with authorized change requests.
+- Conduct a thorough investigation to identify how SYSTEM privileges were obtained, focusing on potential vulnerabilities or misconfigurations that could have been exploited.
+- Reset passwords and review permissions for any accounts added to sensitive groups to ensure they have not been compromised.
+- Escalate the incident to the security operations center (SOC) and relevant IT management teams for further analysis and decision-making.
+- Implement enhanced logging and monitoring for Active Directory, ensuring that all group modifications and privilege escalations are logged and reviewed regularly.
+- Integrate security information and event management (SIEM) solutions to correlate events and detect similar anomalies in the future.
+- Restore the domain controller to a known good state using backups, ensuring that all unauthorized changes are reverted.
+- Apply security patches and updates to the domain controller and related systems to mitigate known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence, including hardening measures such as restricting SYSTEM account usage and reviewing group membership policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_local_scheduled_job_creation.toml b/rules/windows/persistence_local_scheduled_job_creation.toml
index e771f3d2d8e..dd17603012b 100644
--- a/rules/windows/persistence_local_scheduled_job_creation.toml
+++ b/rules/windows/persistence_local_scheduled_job_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,51 @@ file where host.os.type == "windows" and event.type != "deletion" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via Scheduled Job Creation
+
+Scheduled jobs in Windows allow users to automate the execution of tasks at specified times. Adversaries exploit this feature to maintain persistence by scheduling malicious scripts or programs to run automatically. The detection rule identifies suspicious job files in the Windows Tasks directory, excluding known legitimate processes, to flag potential abuse of this functionality for unauthorized persistence.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process executable involved in the scheduled job creation.
+- Verify the legitimacy of the file path by checking if it matches any known legitimate processes or paths excluded in the detection rule.
+- Use Osquery to list all scheduled tasks on the host to identify any other potentially suspicious tasks:
+  ```sql
+  SELECT * FROM scheduled_tasks WHERE path LIKE 'C:\\\\Windows\\\\Tasks\\\\%';
+  ```
+- Investigate the process executable associated with the scheduled job to determine if it is a known legitimate application or potentially malicious.
+- Check the creation and modification timestamps of the suspicious job file to understand when it was created and if it aligns with any known user activity or system changes.
+- Correlate the scheduled job creation with other security events or logs from the same timeframe to identify any related suspicious activity.
+- Examine the user account context under which the scheduled job was created to determine if it was created by an authorized user or potentially compromised account.
+- Investigate the parent process of the executable that created the scheduled job to trace back the origin of the job creation.
+- Review any network connections or external communications initiated by the process executable to identify potential command and control activity.
+- Consult threat intelligence sources to determine if the process executable or file path is associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Scheduled jobs created by legitimate software such as CCleaner and ManageEngine UEMS Agent can trigger false positives. These applications are known to create job files in the Windows Tasks directory for routine maintenance and updates.
+- To manage these false positives, users can implement exceptions in the detection rule. For instance, exclude job files associated with CCleanerCrashReporting.job and DCAgentUpdater.job by specifying their respective process executables in the exclusion criteria.
+- Regularly review and update the exclusion list to include any new legitimate applications that may create scheduled jobs, ensuring that the detection rule remains effective without flagging benign activities.
+- Consider the context of the environment and the presence of known software that utilizes scheduled tasks for legitimate purposes, adjusting the rule to accommodate these scenarios while maintaining security vigilance.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Review the scheduled job details, including the script or program being executed, to determine if it is malicious or unauthorized.
+- Terminate any malicious processes associated with the suspicious scheduled job to stop further execution.
+- Delete the unauthorized scheduled job from the Windows Tasks directory to remove persistence.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
+- Investigate the source of the scheduled job creation by reviewing system logs and user activity to identify potential compromise vectors.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if additional expertise is required.
+- Implement enhanced logging policies to capture detailed information on scheduled task creation and modification events for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in the future.
+- Apply system hardening measures, such as restricting user permissions and implementing application whitelisting, to prevent unauthorized task scheduling and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_local_scheduled_task_creation.toml b/rules/windows/persistence_local_scheduled_task_creation.toml
index b16d94cda6a..e9bd05836b1 100644
--- a/rules/windows/persistence_local_scheduled_task_creation.toml
+++ b/rules/windows/persistence_local_scheduled_task_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,50 @@ sequence with maxspan=1m
     not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System")
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Local Scheduled Task Creation
+
+Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, or privilege escalation. They may create tasks using command-line tools like `schtasks.exe`. The detection rule identifies suspicious task creation by monitoring processes linked to task creation, especially when initiated by non-system users, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process that triggered the rule, focusing on the `process.name` and `process.args` fields to understand the context of the task creation.
+- Check the `process.entity_id` and `process.parent.entity_id` to trace the parent-child relationship of the processes involved, which can help identify the origin of the task creation.
+- Investigate the user account associated with the task creation by examining the `process.args` for `/RU` to determine if it aligns with expected user behavior or if it is a non-system user.
+- Verify the integrity level of the process using `?process.Ext.token.integrity_level_name` or `?winlog.event_data.IntegrityLevel` to confirm that the task was created by a non-SYSTEM user, which could indicate suspicious activity.
+- Use Osquery to list all scheduled tasks on the host and identify any recently created or modified tasks. Example query: `SELECT * FROM scheduled_tasks WHERE hidden = 0;`
+- Cross-reference the scheduled task name and path from the alert with known legitimate tasks to identify any anomalies or unauthorized tasks.
+- Examine the command or script specified in the task's `/TR` argument to determine if it contains any suspicious or unexpected actions.
+- Review the task's schedule specified by `/SC` to assess if the timing aligns with typical user activity or if it appears to be set for persistence.
+- Check for any recent changes in the system's environment or configuration that could explain the task creation, such as software updates or new application installations.
+- Correlate the findings with other security events or logs from the same timeframe to identify any related activities or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Scheduled tasks created by legitimate administrative tools or scripts can trigger false positives, especially in environments with automated maintenance or deployment processes.
+- Regularly scheduled tasks by IT management software, such as patch management or system monitoring tools, may appear suspicious but are benign.
+- Users can manage these false positives by creating exceptions for known administrative tools or scripts that frequently create scheduled tasks.
+- Exclude specific user accounts or processes that are known to perform legitimate task creation, ensuring they are documented and verified as non-threatening.
+- Implement a review process to regularly update and refine exceptions based on changes in the environment or new legitimate task creation patterns.
+- Consider the context of task creation, such as the time of day or associated user activity, to differentiate between legitimate and suspicious behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Review the scheduled task details, including the user account that created it, the command executed, and the timing of the task, to understand the scope and intent of the task.
+- Terminate any malicious processes associated with the scheduled task and remove the task from the system.
+- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise or persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team if the task is part of a broader attack campaign or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed process creation events and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as restricting the use of administrative tools and enforcing least privilege principles.
+- Educate users on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security policies and procedures."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ms_office_addins_file.toml b/rules/windows/persistence_ms_office_addins_file.toml
index 040eb7fed6e..51b20c440c1 100644
--- a/rules/windows/persistence_ms_office_addins_file.toml
+++ b/rules/windows/persistence_ms_office_addins_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/16"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,48 @@ file where host.os.type == "windows" and event.type != "deletion" and
     "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*"
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via Microsoft Office AddIns
+
+Microsoft Office add-ins enhance functionality by allowing custom code execution when Office applications start. Adversaries exploit this by placing malicious add-ins in specific directories, ensuring their code runs whenever the application launches, thus achieving persistence. The detection rule identifies suspicious files with extensions like .xll or .xlam in these directories, signaling potential abuse for persistence.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and extension that triggered the detection, focusing on the `file.path` and `file.extension` fields.
+- Verify the legitimacy of the file by checking its creation and modification timestamps to determine if it aligns with known user activity or software updates.
+- Examine the file's metadata and properties to identify the publisher or author, which may provide clues about its legitimacy.
+- Use Osquery to list all files in the suspicious directories to identify any other potentially malicious add-ins. Example query: `SELECT path, filename, extension, size, atime, mtime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\Microsoft\\\\%\\\\%' AND extension IN ('wll', 'xll', 'ppa', 'ppam', 'xla', 'xlam');`
+- Check the file's hash against known malware databases or threat intelligence sources to determine if it is a known threat.
+- Investigate the user account associated with the file path to determine if there is any unusual or unauthorized activity linked to that account.
+- Review recent system logs and events for any signs of suspicious activity or anomalies around the time the file was created or modified.
+- Analyze network traffic from the affected endpoint to identify any unusual outbound connections that may indicate data exfiltration or command-and-control communication.
+- Correlate the alert with other security events or alerts from the same endpoint to identify potential patterns or related incidents.
+- Consult with the user or system owner to verify if the add-in was intentionally installed and if they have experienced any unusual behavior with their Office applications.
+
+### False positive analysis
+
+- Legitimate add-ins: Users may have legitimate Microsoft Office add-ins installed that match the detection criteria, such as productivity tools or custom scripts developed by IT departments. These can trigger false positives if they reside in the monitored directories.
+- Frequent updates: Some legitimate add-ins may update frequently, causing repeated alerts. This is common with add-ins that receive regular feature enhancements or security patches.
+- User-specific add-ins: In environments where users are allowed to install their own add-ins, personal productivity tools or educational add-ins might be flagged as suspicious.
+- Handling false positives: To manage these, users can create exceptions for known legitimate add-ins by excluding specific file paths or hashes from the detection rule. Regularly review and update the list of exceptions to ensure it reflects the current environment and does not inadvertently exclude new threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the malicious add-in.
+- Conduct a thorough investigation to identify the source of the malicious add-in, checking for any recent downloads or email attachments that may have been the initial vector.
+- Remove the identified malicious add-in files from the specified directories to eliminate the persistence mechanism.
+- Perform a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats.
+- Review user account activity for any unauthorized access or changes, and reset passwords if necessary to secure accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on the directories used for Office add-ins.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
+- Restore the system to its operational state by ensuring all legitimate add-ins are intact and the system is fully patched and updated.
+- Apply hardening measures such as restricting write access to Office add-in directories and educating users on the risks of downloading and opening untrusted files."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ms_outlook_vba_template.toml b/rules/windows/persistence_ms_outlook_vba_template.toml
index 3cec5159564..038959bac3d 100644
--- a/rules/windows/persistence_ms_outlook_vba_template.toml
+++ b/rules/windows/persistence_ms_outlook_vba_template.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,48 @@ query = '''
 file where host.os.type == "windows" and event.type != "deletion" and
  file.path : "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via Microsoft Outlook VBA
+
+Microsoft Outlook supports VBA scripting to automate tasks, which can be exploited by adversaries to maintain persistence. By embedding malicious scripts in the Outlook VBA environment, attackers can execute code each time Outlook is launched. The detection rule identifies suspicious activity by monitoring for unauthorized modifications to the VBA project file, a common indicator of such persistence techniques.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path matches "C:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Outlook\\\\VbaProject.OTM" and ensure the event type is not a deletion.
+- Verify the timestamp of the modification event to determine when the unauthorized change occurred.
+- Identify the user account associated with the file path to understand which user's Outlook environment was potentially compromised.
+- Check the system's event logs for any unusual login activities or privilege escalations around the time of the modification.
+- Use Osquery to list all processes running under the user's context to identify any suspicious or unexpected processes. Example query: `SELECT name, pid, path FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'target_username');`
+- Investigate the contents of the VbaProject.OTM file to identify any suspicious or malicious VBA code.
+- Cross-reference the identified VBA code with known malicious scripts or indicators of compromise (IOCs) from threat intelligence sources.
+- Examine the user's Outlook rules and settings for any unauthorized changes that could indicate further persistence mechanisms.
+- Review network logs for any outbound connections initiated by the user's machine that could suggest data exfiltration or command and control communication.
+- Consult with other security tools or logs to identify any correlated alerts or anomalies on the same endpoint or user account.
+
+### False positive analysis
+
+- Legitimate use of VBA scripts by power users or IT administrators for automating routine tasks in Microsoft Outlook can trigger the detection rule. These scripts might be used for tasks like email sorting, auto-replies, or calendar management.
+- Some third-party Outlook add-ins or plugins may modify the VBA project file as part of their normal operation, leading to false positives.
+- Users can manage these false positives by creating exceptions for known and trusted scripts or applications. This can be done by maintaining a whitelist of approved VBA scripts or by verifying the digital signatures of trusted add-ins.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from detection, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm unauthorized modifications to the VbaProject.OTM file and identify any additional compromised systems.
+- Remove or disable the malicious VBA script from the Outlook environment to prevent further execution.
+- Restore the VbaProject.OTM file from a known good backup if available, or recreate it to ensure no malicious code remains.
+- Review and update endpoint protection solutions to detect and block similar persistence techniques in the future.
+- Implement enhanced logging policies to monitor changes to critical files and directories, focusing on the AppData and Outlook directories.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious activities related to Office applications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
+- Educate users on the risks of enabling macros and VBA scripts, emphasizing the importance of vigilance against phishing attacks that may deliver such payloads.
+- Apply hardening measures by configuring Outlook security settings to restrict the execution of unauthorized scripts and macros, aligning with best practices and organizational policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
index 446ca449b00..9b66056fd9b 100644
--- a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
+++ b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,49 @@ query = '''
 iam where event.action == "modified-user-account" and event.code == "4738" and
   winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 KRBTGT Delegation Backdoor
+
+In Active Directory, the KRBTGT account is crucial for Kerberos ticket granting. Adversaries may exploit this by altering delegation settings, allowing them to request tickets for KRBTGT, thus maintaining domain persistence. The detection rule identifies such modifications by monitoring specific event actions and codes, flagging unauthorized changes to the delegation attributes linked to KRBTGT.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event code is "4738" and the event action is "modified-user-account" to ensure it aligns with the KRBTGT Delegation Backdoor rule.
+- Examine the `winlog.event_data.AllowedToDelegateTo` field to verify if it contains any entries related to "krbtgt" to confirm unauthorized delegation settings.
+- Check the timestamp of the event to determine when the modification occurred and correlate it with other suspicious activities in the same timeframe.
+- Identify the user account that performed the modification by reviewing the `winlog.event_data.SubjectUserName` and `winlog.event_data.SubjectUserSid` fields to assess if the account has a legitimate reason for such changes.
+- Investigate the source machine from which the modification was made by examining the `winlog.event_data.SubjectLogonId` and `winlog.event_data.IpAddress` fields to trace the origin of the activity.
+- Use Osquery to gather additional context on the KRBTGT account by running a query such as: `SELECT * FROM ad_users WHERE name = 'krbtgt';` to check for any unusual attributes or changes.
+- Cross-reference the modification event with recent login activities of the involved user account to identify any anomalies or patterns of suspicious behavior.
+- Analyze the Active Directory logs for any other recent changes to critical accounts or delegation settings that might indicate a broader compromise.
+- Review historical data to determine if similar modifications have occurred in the past, which could suggest a recurring pattern of unauthorized access attempts.
+- Consult with the IT team to verify if there were any legitimate administrative tasks or changes scheduled that could explain the modification to the KRBTGT delegation settings.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate changes to the msDS-AllowedToDelegateTo attribute for service accounts might trigger the rule. Administrators should verify if the modification aligns with scheduled maintenance or updates.
+- Service account updates: Updates or changes to service accounts that require delegation might be flagged. Users can create exceptions for known service accounts that regularly undergo such changes.
+- Automated scripts: Scripts that manage or update delegation settings across multiple accounts could cause false positives. Ensure these scripts are documented and create exceptions for their activity.
+- Third-party software: Some software solutions that integrate with Active Directory may modify delegation settings as part of their operation. Verify the software's behavior and exclude its actions if deemed non-threatening.
+- Regular audits: Security audits or compliance checks might involve reviewing and updating delegation settings, potentially triggering alerts. Document these activities and consider excluding them from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or ticket requests.
+- Conduct a thorough investigation to determine the extent of the compromise, focusing on recent changes to the KRBTGT account and related delegation settings.
+- Revert any unauthorized changes to the msDS-AllowedToDelegateTo attribute for the KRBTGT account to its original state.
+- Reset the KRBTGT account password twice to invalidate any existing Kerberos tickets that may have been issued using the compromised account.
+- Review and analyze security logs to identify any other suspicious activities or accounts that may have been compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed audit logs of account modifications and delegation changes for future investigations.
+- Integrate with security information and event management (SIEM) systems to automate detection and alerting of similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
+- Apply hardening measures such as implementing least privilege access, regular account audits, and continuous monitoring to protect against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msi_installer_task_startup.toml b/rules/windows/persistence_msi_installer_task_startup.toml
index 6c41a97a039..3343f7e061c 100644
--- a/rules/windows/persistence_msi_installer_task_startup.toml
+++ b/rules/windows/persistence_msi_installer_task_startup.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/05"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,52 @@ any where host.os.type == "windows" and
                     "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*"))
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via a Windows Installer
+
+Windows Installer, through msiexec.exe, facilitates software installation and configuration. Adversaries exploit this by creating persistence mechanisms, such as scheduled tasks or startup entries, to maintain access. The detection rule identifies suspicious activity by monitoring msiexec.exe for file creations in startup directories or registry modifications linked to auto-run keys, signaling potential persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `msiexec.exe` in the process name or effective process name fields, indicating the Windows Installer was involved.
+- Examine the event category and action fields to determine if the alert was triggered by a file creation or registry modification event.
+- If the alert is related to file creation, check the file path to see if it matches known startup directories such as `?:\\Windows\\System32\\Tasks\\*` or user-specific startup paths.
+- For registry modification alerts, verify the registry path to see if it aligns with auto-run keys like `HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*`.
+- Use Osquery to list all scheduled tasks on the system to identify any suspicious or newly created tasks:
+  ```sql
+  SELECT * FROM scheduled_tasks WHERE path LIKE '%\\\\Windows\\\\System32\\\\Tasks\\\\%';
+  ```
+- Investigate the parent process of `msiexec.exe` to understand how it was initiated and whether it was triggered by a legitimate application or script.
+- Check the timestamp of the event to correlate with any known user activity or other suspicious events occurring around the same time.
+- Review the user context under which `msiexec.exe` was executed to determine if it aligns with expected user behavior or privileges.
+- Analyze any associated network activity from the host around the time of the alert to identify potential command and control communication.
+- Gather additional context by reviewing system logs and other security tools for any related alerts or anomalies that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate software installations or updates: Many legitimate applications use msiexec.exe to install or update software, which may create entries in startup directories or modify registry auto-run keys. Users should verify if the activity corresponds to known software installations or updates.
+- System maintenance tasks: Some system maintenance tools or scripts may use msiexec.exe to schedule tasks or modify startup settings as part of their normal operation. Users can create exceptions for these known tools to prevent false alerts.
+- IT administrative actions: IT administrators might use msiexec.exe to deploy software across multiple systems, which can trigger the detection rule. Users should ensure that such activities are documented and create exceptions for these administrative actions.
+- Software deployment tools: Tools like SCCM or other deployment solutions might use msiexec.exe to manage software installations, leading to false positives. Users can exclude these tools from the detection rule by identifying their specific process names or paths.
+- Regular system updates: Windows updates or other system updates might involve msiexec.exe, resulting in registry or file changes. Users should correlate the timing of these updates with the detected events to determine if they are benign.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the persistence mechanism by reviewing logs and identifying any unauthorized scheduled tasks or startup entries created by msiexec.exe.
+- Remove any identified malicious scheduled tasks or startup entries and restore legitimate configurations.
+- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software.
+- Review and modify user permissions to ensure that only authorized personnel have the ability to create or modify scheduled tasks and startup entries.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process creation and registry modification events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
+- Harden the system by disabling unnecessary services, applying the principle of least privilege, and ensuring that security configurations align with best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msoffice_startup_registry.toml b/rules/windows/persistence_msoffice_startup_registry.toml
index 4565aedddf2..6a68f4c7771 100644
--- a/rules/windows/persistence_msoffice_startup_registry.toml
+++ b/rules/windows/persistence_msoffice_startup_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -42,6 +42,48 @@ query = '''
 registry where host.os.type == "windows" and event.action != "deletion" and
     registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Office Test Registry Persistence
+
+The Office Test Registry key in Windows environments allows specifying a DLL to execute whenever an Office application launches, intended for legitimate testing purposes. Adversaries exploit this by inserting malicious DLLs, ensuring persistence on compromised systems. The detection rule monitors modifications to this registry path, excluding deletions, to identify potential abuse by tracking unauthorized changes.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path that was modified, focusing on the `registry.path` field to understand which DLL might be involved.
+- Check the `event.action` field to confirm the type of modification that occurred, ensuring it wasn't a deletion, as deletions are excluded from the rule.
+- Investigate the timestamp of the modification to determine when the change occurred and correlate it with other events on the system.
+- Use Osquery to list all DLLs specified in the Office Test Registry path with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_CURRENT_USER\\\\Software\\\\Microsoft\\\\Office Test\\\\Special\\\\Perf\\\\%' OR path LIKE 'HKEY_LOCAL_MACHINE\\\\Software\\\\Microsoft\\\\Office Test\\\\Special\\\\Perf\\\\%';`
+- Examine the DLL file's properties, such as its creation and modification dates, to assess if it aligns with known legitimate software updates or installations.
+- Check the file hash of the DLL against known malware databases to determine if it is a known malicious file.
+- Review recent user activity on the host to identify any suspicious behavior or unauthorized access that might have led to the registry modification.
+- Investigate other registry changes around the same time to identify if there are additional persistence mechanisms being established.
+- Analyze network logs for any unusual outbound connections from the host that might indicate data exfiltration or command and control communication.
+- Cross-reference the host's security logs for any other alerts or anomalies that could provide additional context to the registry modification event.
+
+### False positive analysis
+
+- Legitimate software testing: Developers or IT personnel may use the Office Test Registry key for legitimate testing purposes, leading to benign modifications. Users can handle this by identifying and documenting authorized testing activities and excluding these from alerts.
+- Software updates: Some legitimate software updates might modify the registry key as part of their installation or update process. Users should verify the source of the update and, if confirmed as safe, create exceptions for these specific update activities.
+- Security tools: Certain security or monitoring tools might interact with the registry key as part of their normal operations. Users should review the behavior of these tools and, if deemed non-threatening, exclude them from triggering alerts.
+- Custom scripts or automation: Organizations may have custom scripts or automation processes that modify the registry key for operational purposes. Users should ensure these scripts are documented and create exceptions for their known activities to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the threat.
+- Conduct a thorough investigation to identify the malicious DLL and any associated processes or files. Use endpoint detection and response (EDR) tools to gather detailed information.
+- Remove the unauthorized DLL from the specified Office Test Registry path and any other locations where it may have been copied.
+- Restore the registry to its previous state using backups or system restore points, ensuring no unauthorized changes remain.
+- Perform a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats.
+- Review and enhance logging policies to ensure detailed monitoring of registry changes, particularly focusing on the Office Test Registry path.
+- Implement additional security measures such as application whitelisting to prevent unauthorized DLLs from executing.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Update security policies and conduct user awareness training to prevent similar incidents, emphasizing the risks associated with unauthorized software installations.
+- Consider integrating threat intelligence feeds and MITRE ATT&CK framework mappings into security tools to improve detection and response capabilities for persistence techniques like T1137."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_netsh_helper_dll.toml b/rules/windows/persistence_netsh_helper_dll.toml
index b024cd12e5b..9eb573494f3 100644
--- a/rules/windows/persistence_netsh_helper_dll.toml
+++ b/rules/windows/persistence_netsh_helper_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,48 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\Software\\Microsoft\\netsh\\*"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Netsh Helper DLL
+
+Netsh Helper DLLs are extensions for the netsh.exe utility, enhancing its capabilities in Windows environments. While legitimate, adversaries can exploit this by adding malicious DLLs, ensuring their payloads execute whenever netsh runs, often via admin actions or scheduled tasks. The detection rule monitors registry changes in specific paths, flagging unauthorized DLL additions to thwart such persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path that triggered the alert, focusing on paths like "HKLM\\\\Software\\\\Microsoft\\\\netsh\\\\*".
+- Verify the legitimacy of the DLL by checking its file path and comparing it against known good DLLs or a whitelist of approved Netsh Helper DLLs.
+- Use Osquery to list all DLLs associated with Netsh by executing: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\Software\\\\Microsoft\\\\netsh\\\\%';`.
+- Investigate the file properties of the suspicious DLL, including its creation and modification dates, using tools like PowerShell or the command line.
+- Check the digital signature of the DLL to ensure it is signed by a trusted publisher.
+- Correlate the timestamp of the registry change event with other logs, such as user login events or scheduled task executions, to identify potential responsible users or processes.
+- Search for any related scheduled tasks that might execute netsh.exe, using commands like `schtasks` or reviewing Task Scheduler logs.
+- Analyze network activity around the time of the registry change to detect any unusual outbound connections that might indicate data exfiltration or command and control communication.
+- Review system logs for any other suspicious activities or errors that coincide with the time of the registry modification.
+- Consult threat intelligence sources to determine if the DLL or its associated file path has been reported in any known attack campaigns or malware signatures.
+
+### False positive analysis
+
+- Legitimate software installations or updates may add or modify Netsh Helper DLLs, triggering the detection rule. Users should verify the source and purpose of the DLL changes to determine if they are part of a trusted application.
+- System administrators might intentionally add custom Netsh Helper DLLs to enhance network management capabilities. In such cases, these changes should be documented and excluded from the detection rule to prevent unnecessary alerts.
+- Some network management tools or scripts may programmatically modify the Netsh registry paths as part of their normal operation. Users should identify these tools and create exceptions for their known behaviors to avoid false positives.
+- Regular audits of the Netsh Helper DLL registry paths can help distinguish between expected changes and potential threats. Users should maintain a baseline of known good DLLs and update their detection rules to exclude these from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized Netsh Helper DLLs by reviewing recent registry changes and correlating them with known malicious indicators.
+- Remove any unauthorized or suspicious DLLs from the registry paths specified in the detection rule to prevent further execution of malicious payloads.
+- Perform a comprehensive malware scan on the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats.
+- Review and analyze system logs, including Windows Event Logs and security logs, to trace the origin of the unauthorized changes and identify potential entry points or compromised accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if additional expertise is required.
+- Implement enhanced logging policies to capture detailed registry changes and process execution events, ensuring better visibility for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate alerts and improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying clean backups, ensuring all security patches and updates are installed, and verifying the integrity of critical system files.
+- Harden the system by implementing least privilege principles, disabling unnecessary services, and regularly auditing user permissions and scheduled tasks to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
index 35c401eed9e..43893c386f1 100644
--- a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
+++ b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,48 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name: ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and process.args : "Set-CASMailbox*ActiveSyncAllowedDeviceIDs*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 New ActiveSyncAllowedDeviceID Added via PowerShell
+
+ActiveSync is a protocol enabling mobile devices to synchronize with Exchange mailboxes. The Set-CASMailbox cmdlet can modify mailbox settings, including allowed devices. Adversaries may exploit this to add unauthorized devices, gaining persistent access to sensitive emails. The detection rule identifies suspicious PowerShell activity by monitoring for specific cmdlet usage, helping to flag potential account manipulation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and device involved in the Set-CASMailbox cmdlet execution.
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
+- Investigate the source IP address and host from which the PowerShell command was executed to determine if it is a known or trusted source.
+- Examine the user account's recent activity logs to identify any other unusual or unauthorized actions, such as login attempts from unfamiliar locations or devices.
+- Use Osquery to gather more information about the process execution. For example, run the following query to list recent PowerShell executions: `SELECT * FROM processes WHERE name IN ('powershell.exe', 'pwsh.exe', 'powershell_ise.exe') AND cmdline LIKE '%Set-CASMailbox%ActiveSyncAllowedDeviceIDs%';`
+- Check for any recent changes to the user's mailbox settings, including other cmdlets that may have been executed, to identify potential account manipulation.
+- Review the organization's change management records to verify if the addition of the ActiveSyncAllowedDeviceID was authorized or part of a legitimate change request.
+- Analyze the PowerShell script or command used to execute the Set-CASMailbox cmdlet to understand its intent and whether it contains any malicious or suspicious elements.
+- Investigate any other alerts or incidents related to the same user account or device to determine if this is part of a broader attack or compromise.
+- Consult with the user or their manager to confirm whether they recognize the device and if they authorized its addition to the ActiveSync allowed list.
+
+### False positive analysis
+
+- Routine administrative tasks: IT administrators may regularly use the Set-CASMailbox cmdlet to manage and update ActiveSyncAllowedDeviceIDs for legitimate purposes, such as onboarding new employees or updating device policies. To manage these, consider creating exceptions for known administrative accounts or specific time windows when these tasks are typically performed.
+- Automated scripts: Organizations might have automated scripts that run periodically to update mailbox settings, including ActiveSyncAllowedDeviceIDs. These scripts can trigger false positives. To handle this, identify and exclude these scripts by their unique process arguments or execution paths.
+- Device policy updates: Changes in organizational device policies may require bulk updates to ActiveSyncAllowedDeviceIDs, leading to multiple detections. In such cases, coordinate with the IT team to whitelist these activities during policy rollout periods.
+- Testing and development environments: In environments where Exchange settings are frequently tested or developed, the Set-CASMailbox cmdlet might be used often. Exclude these environments from the detection rule by filtering based on hostnames or IP ranges associated with testing and development.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further unauthorized access to sensitive emails.
+- Review the PowerShell logs and audit logs to identify the source and scope of the unauthorized Set-CASMailbox cmdlet usage.
+- Verify the legitimacy of the newly added ActiveSyncAllowedDeviceID by contacting the user and checking device enrollment records.
+- Remove any unauthorized devices from the ActiveSyncAllowedDeviceID list to cut off adversary access.
+- Reset the credentials of the compromised account and enforce multi-factor authentication to enhance security.
+- Conduct a thorough investigation to determine if any other accounts or systems have been compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed PowerShell activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Educate users on recognizing phishing attempts and secure handling of credentials to prevent future account manipulation.
+- Apply security hardening measures such as restricting PowerShell usage to administrative accounts and using Just Enough Administration (JEA) to limit cmdlet access."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_registry_uncommon.toml b/rules/windows/persistence_registry_uncommon.toml
index dba7ca9b4e9..5a7bfeae050 100644
--- a/rules/windows/persistence_registry_uncommon.toml
+++ b/rules/windows/persistence_registry_uncommon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -115,6 +115,49 @@ registry where host.os.type == "windows" and event.type == "change" and
       )
      )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Uncommon Registry Persistence Change
+
+Windows Registry is a critical system database that stores configuration settings. Adversaries exploit registry keys for persistence by adding or modifying entries to execute malicious code during system events like startup or user logon. The detection rule identifies unusual changes in specific registry paths often targeted for stealthy persistence, filtering out common legitimate modifications to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the specific registry path and value that triggered the alert to understand the context of the change. Focus on paths listed in the query, such as `HKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Winlogon\\\\Userinit`.
+- Check the `registry.data.strings` field to identify the new or modified data associated with the registry change. This can provide clues about the potential payload or command being executed.
+- Investigate the process that made the registry change by examining the `process.name` and `process.executable` fields. Determine if the process is legitimate or potentially malicious.
+- Use Osquery to gather additional context about the process that made the change. For example, run the following query to list processes with their command-line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE name = '<process_name>';`.
+- Cross-reference the process information with known good and bad processes to assess the likelihood of malicious activity. Utilize threat intelligence sources if available.
+- Examine the system's event logs around the time of the registry change for any related events, such as user logons or other system changes, to build a timeline of activity.
+- Check for any network connections initiated by the process that made the registry change. This can help identify potential command and control communication.
+- Investigate the user account context under which the registry change was made. Determine if the account has a history of suspicious activity or if it was compromised.
+- Review any recent software installations or updates that might have legitimately modified the registry. This can help rule out false positives.
+- If the registry change is associated with a known persistence technique, research the specific technique to understand its implications and how it might be leveraged by an adversary.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify registry keys for legitimate persistence purposes, such as adding entries to the Run or RunOnce keys. Users can handle these by monitoring installation activities and correlating them with registry changes.
+- System administrators might use scripts or group policies that modify registry keys for configuration management. These should be documented and excluded from alerts by creating exceptions for known administrative processes.
+- Security software, like antivirus or endpoint protection solutions, may alter registry settings as part of their normal operation. Users should identify these processes and exclude them from detection by specifying their executable paths in the exception list.
+- Windows system processes, such as `msiexec.exe` or `svchost.exe`, may trigger registry changes during normal operations like updates or system maintenance. Users can manage these by excluding these processes from detection when they are associated with known benign registry paths or values.
+- Custom scripts or applications developed in-house that require registry modifications for functionality might trigger false positives. Users should document these applications and create specific exceptions based on their known behaviors and registry paths.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential threats.
+- Conduct a thorough investigation of the registry changes to identify any unauthorized or malicious entries.
+- Utilize endpoint detection and response (EDR) tools to analyze the processes and executables associated with the registry changes.
+- Remove or revert any unauthorized registry modifications to their original state to restore system integrity.
+- Scan the system with updated antivirus and anti-malware tools to detect and remove any associated threats.
+- Review and enhance logging policies to ensure comprehensive monitoring of registry changes and related system activities.
+- Implement additional security measures such as application whitelisting and user access controls to prevent unauthorized registry modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is determined to be part of a larger attack campaign.
+- Document the incident, including the root cause analysis and remediation steps, to improve future response efforts.
+- Consider deploying threat intelligence integrations to stay informed about emerging threats and tactics related to registry persistence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_remote_password_reset.toml b/rules/windows/persistence_remote_password_reset.toml
index c0698e0647d..d6c14a40a56 100644
--- a/rules/windows/persistence_remote_password_reset.toml
+++ b/rules/windows/persistence_remote_password_reset.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -18,7 +18,50 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Account Password Reset Remotely"
-note = """
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Account Password Reset Remotely
+
+Remote password resets are crucial for managing user access in distributed environments. However, adversaries exploit this by resetting passwords of privileged accounts to maintain unauthorized access or bypass security policies. The detection rule identifies such activities by monitoring successful network logins followed by password resets on accounts with administrative-like names or specific security identifiers, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific account involved in the password reset by examining the `winlog.event_data.TargetUserName` field.
+- Check the `source.ip` field to determine the origin of the network login and assess if it is from a known or suspicious location.
+- Investigate the `winlog.computer_name` to identify the system where the password reset was initiated and verify if it is a legitimate administrative system.
+- Correlate the `winlog.event_data.TargetLogonId` and `winlog.event_data.SubjectLogonId` fields to trace the session and user context of the login and password reset events.
+- Use Osquery to gather additional context on the involved system. For example, run the following query to list recent logins on the system: `SELECT * FROM logged_in_users WHERE user = '<TargetUserName>';`.
+- Examine historical login patterns for the `winlog.event_data.TargetUserName` to identify any anomalies or deviations from normal behavior.
+- Check for any recent changes in group memberships or privileges for the account using the `winlog.event_data.TargetSid` to ensure no unauthorized privilege escalation has occurred.
+- Review any related security logs or alerts around the time of the event to identify potential lateral movement or other suspicious activities.
+- Investigate any other accounts accessed from the same `source.ip` to determine if there is a broader compromise.
+- Consult with the account owner or relevant personnel to verify if the password reset was authorized and gather any additional context or concerns they might have.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular password resets by IT staff for maintenance or user support can trigger false positives. To manage this, exclude known IT staff accounts or specific IP addresses from the rule.
+- Automated system processes: Scheduled tasks or scripts that reset passwords for service accounts might be flagged. Identify and exclude these accounts by adding their specific naming conventions to the exception list.
+- Third-party management tools: Tools used for account management that perform password resets as part of their operation can cause alerts. Whitelist these tools by excluding their associated IP addresses or account names.
+- Frequent password policy changes: Organizations with strict password policies may have frequent legitimate resets. Adjust the rule to account for these by excluding accounts that follow a predictable reset pattern.
+- Shared administrative accounts: In environments where shared accounts are used, legitimate resets by different users can appear suspicious. Consider excluding these accounts or implementing additional monitoring to verify legitimate use.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Verify the legitimacy of the password reset by contacting the account owner or reviewing recent activity logs.
+- If unauthorized access is confirmed, reset the compromised account's password and any other accounts that may have been affected.
+- Conduct a thorough investigation to identify the source of the breach, including reviewing network logs, authentication logs, and any other relevant security logs.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement additional monitoring and alerting for suspicious account activities, focusing on privileged accounts.
+- Review and enhance logging policies to ensure comprehensive coverage of authentication and account management events.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics.
+- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all security controls are functioning correctly.
+- Implement hardening measures such as enforcing strong password policies, enabling multi-factor authentication, and restricting remote access to privileged accounts.
+
 ## Performance
 This rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity.
 """
diff --git a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
index ddc19d2048d..ef781e850cf 100644
--- a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
+++ b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,49 @@ sequence by host.id, user.name with maxspan=1m
     process.args : ("C:\\Users\\*", "C:\\ProgramData\\*", "C:\\Windows\\Temp\\*", "C:\\Windows\\Tasks\\*", "C:\\PerfLogs\\*", "C:\\Intel\\*")
    ]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution of Persistent Suspicious Program
+
+Persistent programs, often legitimate, can be exploited by adversaries to maintain access to a system. By leveraging process lineage and command line analysis, attackers may execute scripts or utilities like PowerShell or rundll32 to persist malicious activities. The detection rule identifies such abuse by monitoring the sequence of process executions post-login, flagging early child processes of explorer.exe that are unlikely to be user-initiated, and scrutinizing their command line arguments and file paths for suspicious patterns.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and user involved, using the `host.id` and `user.name` fields from the query.
+- Examine the process lineage to confirm the sequence of `userinit.exe`, `explorer.exe`, and the suspicious child process. Verify the `process.name` and `process.parent.name` fields to ensure the sequence matches the alert criteria.
+- Analyze the command line arguments of the suspicious process using the `process.args` field to identify any unusual or potentially malicious commands or scripts being executed.
+- Check the file path of the suspicious process using the `process.args` field to determine if it matches any of the known suspicious paths, such as `C:\\Users\\*`, `C:\\ProgramData\\*`, or `C:\\Windows\\Temp\\*`.
+- Investigate the parent process `explorer.exe` to determine if it has any other unusual child processes that may indicate further suspicious activity.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following Osquery query to list all processes with their parent process IDs and command line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cscript.exe', 'wscript.exe', 'PowerShell.EXE', 'MSHTA.EXE', 'RUNDLL32.EXE', 'REGSVR32.EXE', 'RegAsm.exe', 'MSBuild.exe', 'InstallUtil.exe');`
+- Check the system's startup items and scheduled tasks to identify any persistent mechanisms that may have been used to execute the suspicious program.
+- Review recent login events on the host to correlate the timing of the suspicious process execution with user activity, using event logs or security information and event management (SIEM) tools.
+- Investigate any network connections initiated by the suspicious process to identify potential command and control (C2) communication or data exfiltration attempts.
+- Consult threat intelligence sources to determine if the identified process or command line patterns are associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators often use scripts for maintenance tasks, which may trigger the rule if they are executed shortly after login. To manage this, users can create exceptions for known administrative scripts by specifying their file paths or command line arguments.
+- Software updates and installations: Some software updates or installations may use processes like PowerShell or rundll32, which could be flagged as suspicious. Users can handle these by excluding specific update or installation processes that are known to be safe.
+- Automated tasks and scheduled jobs: Certain automated tasks or scheduled jobs may run shortly after login and use processes listed in the detection rule. Users can exclude these tasks by identifying their specific command line patterns or file paths.
+- Development tools: Developers might use tools like MSBuild or InstallUtil during their workflow, which could be misidentified as malicious. Users can create exceptions for these tools when used in known development environments or by specific user accounts.
+- Security software: Some security software may use similar processes to perform legitimate actions, such as scanning or updating. Users should identify and exclude these processes by verifying their source and purpose.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the flagged processes and their command line arguments to confirm malicious activity.
+- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
+- Review and analyze the process lineage to understand the scope of the compromise and identify any additional affected systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and command line activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by removing any malicious files and ensuring all software is up to date with the latest security patches.
+- Harden the system by disabling unnecessary services and implementing application whitelisting to prevent unauthorized execution of scripts and utilities.
+- Conduct a post-incident review to identify gaps in detection and response capabilities and update security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_scheduled_task_creation_winlog.toml b/rules/windows/persistence_scheduled_task_creation_winlog.toml
index 6fa9f59b94f..b018a814c6d 100644
--- a/rules/windows/persistence_scheduled_task_creation_winlog.toml
+++ b/rules/windows/persistence_scheduled_task_creation_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,48 @@ iam where event.action == "scheduled-task-created" and
               "\\OneDrive Standalone Update Task-S-1-12-1-*"
  )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 A scheduled task was created
+
+Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, and privilege escalation. Malicious actors may create tasks to execute harmful scripts or programs at specific times. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats that align with known attack techniques.
+
+### Possible investigation steps
+
+- Review the event logs to confirm the creation of the scheduled task by checking the `event.action` field for "scheduled-task-created".
+- Verify the `user.name` field to identify the user account that created the task, ensuring it is not a system account or a known service account.
+- Examine the `winlog.event_data.TaskName` field to determine the name of the scheduled task and check if it matches any known malicious patterns or unusual naming conventions.
+- Cross-reference the `winlog.event_data.TaskName` with a list of known benign tasks to ensure it is not mistakenly flagged.
+- Use Osquery to list all scheduled tasks on the system and identify any discrepancies or unknown tasks. Example query: `SELECT * FROM scheduled_tasks WHERE name = '<TaskName>';`.
+- Investigate the `winlog.event_data.TaskContent` if available, to understand the script or program that the task is set to execute.
+- Check the creation time of the task to determine if it aligns with any known suspicious activity or outside of normal business hours.
+- Analyze the system's recent login events to correlate the task creation with any unusual login activity or unauthorized access attempts.
+- Review any associated network activity around the time of task creation to identify potential lateral movement or data exfiltration attempts.
+- Consult threat intelligence sources to see if the task name or associated user account has been linked to any known attack campaigns or threat actors.
+
+### False positive analysis
+
+- Scheduled tasks created by legitimate software updates or system maintenance can trigger false positives. For example, tasks related to HP device checks or Microsoft Visual Studio updates are common and benign.
+- Tasks initiated by OneDrive updates are also frequent and typically non-threatening, as they are part of regular software maintenance.
+- To manage these false positives, users can exclude specific task names from the detection rule, as shown in the provided query. This involves adding known benign task names to the exclusion list to prevent unnecessary alerts.
+- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the detection rule remains effective without generating excessive false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Review the details of the scheduled task creation event, including the user account involved and the task's payload, to assess the potential impact and scope of the compromise.
+- Terminate any malicious processes associated with the scheduled task and delete the task itself to prevent further execution.
+- Conduct a thorough investigation of the affected system and related systems to identify any additional indicators of compromise or persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team if the task is linked to known advanced persistent threat (APT) groups or if the scope of the attack is beyond initial containment efforts.
+- Implement enhanced logging policies to capture detailed information on scheduled task creation and execution, including command-line arguments and user context.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting scheduled task creation to authorized users only and using application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_scheduled_task_updated.toml b/rules/windows/persistence_scheduled_task_updated.toml
index 6983c1da7a1..2f08831bc42 100644
--- a/rules/windows/persistence_scheduled_task_updated.toml
+++ b/rules/windows/persistence_scheduled_task_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,49 @@ iam where event.action == "scheduled-task-updated" and
            "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload") and 
   not winlog.event_data.SubjectUserSid :  ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 A scheduled task was updated
+
+Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this by modifying tasks to maintain persistence, often altering legitimate tasks to avoid detection. The detection rule identifies suspicious updates by filtering out benign changes, such as those by system accounts or known safe tasks, focusing on anomalies that suggest malicious intent.
+
+### Possible investigation steps
+
+- Review the event logs to confirm the occurrence of the "scheduled-task-updated" event and identify the specific task that was modified.
+- Examine the `user.name` field to determine the account responsible for the task update and verify if it is a legitimate user or potentially compromised account.
+- Investigate the `winlog.event_data.TaskName` field to identify the name of the scheduled task that was updated and assess if it is a known legitimate task or an unusual one.
+- Check the `winlog.event_data.SubjectUserSid` field to ensure the task update was not performed by system accounts (e.g., S-1-5-18, S-1-5-19, S-1-5-20) which are typically benign.
+- Use Osquery to gather more information about the scheduled task by running a query such as: `SELECT * FROM scheduled_tasks WHERE name = '<TaskName>'` to retrieve details about the task's configuration and recent changes.
+- Cross-reference the task name and user account with known safe lists or previous incidents to determine if this is a recurring issue or a new anomaly.
+- Analyze the timing of the task update to see if it coincides with other suspicious activities or known attack patterns.
+- Investigate the system's security logs for any other unusual activities or alerts around the time of the task update to identify potential lateral movement or privilege escalation.
+- Review the system's network logs to check for any outbound connections or data exfiltration attempts following the task update.
+- Consult threat intelligence sources to see if the task name or user account has been associated with known malware or attack campaigns.
+
+### False positive analysis
+
+- Scheduled tasks updated by legitimate software updates or system maintenance activities can trigger false positives. These often involve tasks related to system or software updates, such as those by Microsoft or other trusted vendors.
+- Tasks modified by IT administrators for maintenance or operational purposes may also appear suspicious. These changes are typically routine and part of regular system management.
+- To manage these false positives, users can create exceptions for known benign tasks by adding them to the exclusion list in the detection rule. This involves identifying the specific task names or user accounts responsible for legitimate updates and excluding them from triggering alerts.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate tasks that may have been introduced.
+- Collaborate with IT and security teams to understand the context of scheduled task updates and distinguish between legitimate administrative actions and potential threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Review the specific scheduled task changes in the event logs to identify unauthorized modifications and determine the scope of the compromise.
+- Verify the legitimacy of the user account that made the changes to the scheduled task, checking for signs of account compromise.
+- Restore the scheduled task to its original configuration using backups or by manually resetting it to a known good state.
+- Conduct a thorough malware scan on the affected system to identify and remove any malicious software that may have been introduced.
+- Escalate the incident to the security operations center (SOC) or incident response team if the task modification is linked to a broader attack campaign.
+- Implement enhanced logging policies to capture detailed information on scheduled task changes, including user actions and timestamps.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of similar threats in the future.
+- Educate users on the importance of using strong, unique passwords and enable multi-factor authentication to reduce the risk of account compromise.
+- Regularly review and update security policies and procedures to ensure they align with the latest threat intelligence and best practices for system hardening."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_service_dll_unsigned.toml b/rules/windows/persistence_service_dll_unsigned.toml
index 63ce6c7c0e4..468ac20d93b 100644
--- a/rules/windows/persistence_service_dll_unsigned.toml
+++ b/rules/windows/persistence_service_dll_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -126,6 +126,49 @@ library where host.os.type == "windows" and
              "23aa95b637a1bf6188b386c21c4e87967ede80242327c55447a5bb70d9439244", 
              "5050b025909e81ae5481db37beb807a80c52fc6dd30c8aa47c9f7841e2a31be7")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unsigned DLL Loaded by Svchost
+
+Svchost.exe is a critical Windows process that hosts multiple services, allowing efficient resource management. Adversaries exploit this by loading unsigned DLLs to gain persistence or elevated privileges. The detection rule identifies such threats by monitoring DLLs recently created and loaded by svchost, focusing on untrusted signatures and unusual file paths, thus flagging potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of an unsigned DLL loaded by svchost.exe, focusing on the `dll.code_signature.trusted` field to verify the signature status.
+- Check the `dll.Ext.relative_file_creation_time` to determine if the DLL was created within 5 minutes of being loaded, indicating potential malicious activity.
+- Investigate the `dll.path` to identify if the DLL is located in any unusual or suspicious directories listed in the query, which could suggest unauthorized placement.
+- Examine the `dll.hash.sha256` to ensure it is not part of the known benign hashes excluded in the query, which could indicate a false positive.
+- Use Osquery to gather more information about the DLL file. For example, run the following query to list details about the DLL: `SELECT * FROM file WHERE path = '<DLL_PATH>';` replacing `<DLL_PATH>` with the actual path of the DLL.
+- Cross-reference the DLL's hash with threat intelligence databases to check for any known associations with malware or suspicious activity.
+- Analyze the parent process of svchost.exe to determine if it was spawned by a legitimate process or if there are any anomalies in its process tree.
+- Investigate recent system changes or installations that might have introduced the unsigned DLL, focusing on any unusual or unauthorized software installations.
+- Review system logs and event logs around the time of the DLL creation and loading to identify any related suspicious activities or errors.
+- Conduct a network analysis to check for any unusual outbound connections or data exfiltration attempts that might be associated with the loaded DLL.
+
+### False positive analysis
+
+- Some legitimate software may load unsigned DLLs as part of their normal operation, especially older applications or those developed by smaller vendors who may not sign their libraries. Users should verify the legitimacy of such software and consider excluding these specific DLLs from the detection rule.
+- System administrators might deploy custom scripts or tools that load unsigned DLLs for maintenance or monitoring purposes. These should be reviewed and, if deemed safe, added to an exception list to prevent false alerts.
+- Certain security or system management tools might intentionally load unsigned DLLs to perform specific functions. Users should confirm the source and purpose of these tools and exclude them if they are verified as non-malicious.
+- In some cases, software updates or patches might temporarily load unsigned DLLs before a signature is applied. Users should monitor update cycles and exclude these DLLs if they are confirmed to be part of a legitimate update process.
+- To manage false positives, users can create exceptions based on the hash of known non-malicious DLLs, the file path, or the specific software involved, ensuring that only verified and trusted instances are excluded from detection.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the unsigned DLL's legitimacy by checking its hash against known malware databases and analyzing its behavior.
+- Terminate the svchost process that loaded the unsigned DLL if it is confirmed to be malicious.
+- Remove the malicious DLL from the system and any associated registry entries or scheduled tasks that may have been created for persistence.
+- Conduct a full antivirus and antimalware scan on the affected system to identify and remove any additional threats.
+- Review and enhance logging policies to ensure detailed monitoring of DLL loads, process creations, and network connections.
+- Implement application whitelisting to prevent unauthorized DLLs from being loaded by svchost or other critical processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
+- Educate users on recognizing suspicious activities and reinforce security awareness to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_services_registry.toml b/rules/windows/persistence_services_registry.toml
index 7225410023f..473c59cec07 100644
--- a/rules/windows/persistence_services_registry.toml
+++ b/rules/windows/persistence_services_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -65,6 +65,49 @@ registry where host.os.type == "windows" and event.type == "change" and
       "?:\\Windows\\System32\\WaaSMedicAgent.exe"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Persistence via Services Registry
+
+Windows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path and value that triggered the alert, focusing on the `registry.path` and `registry.value` fields.
+- Check the `process.name` and `process.executable` fields to determine which process made the registry change and assess if it is a known legitimate process or potentially malicious.
+- Investigate the parent process of the identified process to understand the process tree and determine if the process was spawned by a legitimate application or a suspicious one.
+- Use Osquery to list all services and their associated executables to identify any discrepancies or unusual entries. Example query: `SELECT name, display_name, path FROM services WHERE path LIKE '%ServiceDLL%' OR path LIKE '%ImagePath%';`
+- Examine the `registry.data.strings` field to see the new data written to the registry and assess if it points to a legitimate or suspicious file path.
+- Cross-reference the file path in `registry.data.strings` with known good files and directories to identify any anomalies or unauthorized files.
+- Check the file hash of the executable involved in the registry change against threat intelligence databases to determine if it is associated with known malware.
+- Review recent system logs and events around the time of the registry change to identify any other suspicious activities or related events.
+- Investigate the user account context under which the process ran to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Analyze network connections made by the process to identify any unusual or unauthorized external communications that could suggest malicious activity.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify service registry keys directly, leading to false positives. Users can handle these by identifying the specific software involved and creating exceptions for its processes.
+- System maintenance tools, such as those used for driver updates or system optimizations, might also trigger this rule. Users should verify the legitimacy of these tools and exclude their processes if deemed safe.
+- Custom scripts or administrative tools that modify service configurations for legitimate purposes can be mistaken for malicious activity. Users should document these scripts and add them to the exclusion list to prevent false alerts.
+- Certain enterprise applications may have unique installation or update mechanisms that interact with the registry in non-standard ways. Users should work with their IT departments to identify these applications and configure exceptions accordingly.
+- Security software or monitoring tools that perform deep system scans or modifications might be flagged. Users should ensure these tools are from trusted vendors and exclude their processes to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the process responsible for the registry modification by analyzing logs and correlating with known malicious indicators.
+- Terminate any suspicious processes identified during the investigation to halt potential malicious activity.
+- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries.
+- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Apply security patches and updates to the operating system and installed software to mitigate vulnerabilities that could be exploited for persistence.
+- Review and strengthen access controls and user permissions to limit the ability of unauthorized users to modify critical system settings."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
index a593685c0f5..5a7ae86c030 100644
--- a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
+++ b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,52 @@ process where host.os.type == "windows" and event.type == "start" and
      not (process.name : "powershell.exe" and process.args : ("-File", "-PSConsoleFile") and user.id : "S-1-5-18") and
      not (process.name : "msiexec.exe" and user.id : "S-1-5-18")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Execution via Scheduled Task
+
+Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence by executing malicious programs. They may use common utilities like PowerShell or scripts in unusual directories. The detection rule identifies such abuse by analyzing process lineage, command line usage, and excluding known benign activities, focusing on suspicious programs and paths.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific process triggered the rule, focusing on the `process.pe.original_file_name` and `process.args` fields to identify the suspicious program and its execution path.
+- Examine the `process.parent.name` and `process.parent.args` fields to confirm the parent process is `svchost.exe` with the "Schedule" argument, indicating the use of scheduled tasks.
+- Check the `event.type` field to ensure the event is a process start, confirming the execution of the suspicious program.
+- Investigate the user context by reviewing the `user.id` field to determine if the process was executed under a privileged account or a service account.
+- Use Osquery to gather additional context about the scheduled task. For example, run the following query to list all scheduled tasks and their associated actions:
+  ```sql
+  SELECT * FROM scheduled_tasks WHERE action LIKE '%cscript.exe%' OR action LIKE '%wscript.exe%' OR action LIKE '%PowerShell.EXE%' OR action LIKE '%Cmd.Exe%' OR action LIKE '%MSHTA.EXE%' OR action LIKE '%RUNDLL32.EXE%' OR action LIKE '%REGSVR32.EXE%' OR action LIKE '%MSBuild.exe%' OR action LIKE '%InstallUtil.exe%' OR action LIKE '%RegAsm.exe%' OR action LIKE '%RegSvcs.exe%' OR action LIKE '%msxsl.exe%' OR action LIKE '%CONTROL.EXE%' OR action LIKE '%EXPLORER.EXE%' OR action LIKE '%Microsoft.Workflow.Compiler.exe%' OR action LIKE '%msiexec.exe%';
+  ```
+- Analyze the command line arguments (`process.args`) for any encoded or obfuscated commands that may indicate malicious intent.
+- Cross-reference the suspicious paths (`process.args`) with known legitimate software installations or temporary file usage to rule out false positives.
+- Review recent system changes or installations that might have introduced the suspicious program or scheduled task.
+- Check for any network connections initiated by the suspicious process to identify potential command and control communication.
+- Correlate the findings with other security alerts or logs to determine if this activity is part of a broader attack campaign.
+
+### False positive analysis
+
+- Scheduled tasks created by legitimate software updates or system maintenance tools can trigger false positives. These tasks often use common utilities like PowerShell or cmd.exe, which are also used by malicious actors.
+- System administrators may use scheduled tasks to run scripts for routine maintenance or monitoring, which can appear suspicious if they use paths or programs listed in the detection rule.
+- Some enterprise applications may use scheduled tasks to perform legitimate background operations, especially if they are installed in non-standard directories like C:\\ProgramData or C:\\Windows\\Temp.
+- To manage these false positives, users can create exceptions for known benign activities by excluding specific process names, paths, or user IDs that are frequently involved in legitimate scheduled tasks.
+- Regularly review and update the list of excluded processes and paths to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Investigate the scheduled task to determine the origin and purpose of the suspicious execution, focusing on the process lineage and command line arguments.
+- Terminate any malicious processes identified during the investigation to stop ongoing threats.
+- Remove or disable the malicious scheduled task to prevent future execution.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
+- Review and analyze system logs, including Windows Event Logs and security logs, to trace the attack vector and identify any other compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and command line arguments for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate suspicious activities.
+- Apply system hardening measures, such as restricting the use of scripting engines and enforcing least privilege access, to reduce the attack surface and prevent similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_suspicious_service_created_registry.toml b/rules/windows/persistence_suspicious_service_created_registry.toml
index 491958437d6..72058869b24 100644
--- a/rules/windows/persistence_suspicious_service_created_registry.toml
+++ b/rules/windows/persistence_suspicious_service_created_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,49 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* add suspicious registry ImagePath values here */
   registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious ImagePath Service Creation
+
+Windows services are crucial for running background processes. Adversaries may exploit the ImagePath registry value to persist or escalate privileges by pointing it to malicious executables or scripts. The detection rule monitors changes to this registry path, focusing on unusual patterns like command shells or named pipes, which often indicate malicious intent. This helps identify potential threats early in the attack lifecycle.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path and data that triggered the alert, focusing on the `registry.path` and `registry.data.strings` fields.
+- Check the `host.os.type` to ensure the alert is relevant to a Windows system, as the rule is designed for Windows environments.
+- Investigate the `event.type` to verify that the change event is consistent with a suspicious modification, indicating a potential threat.
+- Use Osquery to list all services and their ImagePath values on the affected host to identify any other unusual entries. Example query: `SELECT name, image_path FROM services WHERE image_path LIKE '%\\\\pipe\\\\%' OR image_path LIKE '%COMSPEC%';`
+- Examine the process creation logs around the time of the registry change to identify any processes that might have been responsible for the modification.
+- Correlate the suspicious ImagePath with any known malicious executables or scripts by checking threat intelligence sources or databases.
+- Investigate the user account context under which the registry change was made to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Review recent login events on the affected host to identify any unusual or unauthorized access patterns that could be related to the suspicious service creation.
+- Check for any network connections initiated by the suspicious service, especially those involving named pipes, to identify potential lateral movement or data exfiltration attempts.
+- Analyze any related file modifications or creations in the system directories that could be associated with the suspicious ImagePath, looking for signs of tampering or unauthorized files.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the ImagePath registry value, triggering the rule. Users should verify if the change aligns with recent software activities.
+- System administrators might create or modify services for maintenance or configuration purposes, which could be flagged. It's important to confirm if these actions were authorized and expected.
+- Some security tools or monitoring software may use command shells or named pipes in their operations, leading to false positives. Users can create exceptions for these known tools by specifying their paths or signatures.
+- Automated scripts or deployment tools that configure services might also be detected. Users should review these scripts and, if deemed safe, exclude them from monitoring by adding their specific patterns to the exception list.
+- Regularly review and update the exception list to ensure it reflects the current environment and excludes only verified non-threatening behaviors.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent lateral movement and further compromise.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the suspicious ImagePath registry changes.
+- Review recent service creations and modifications in the registry to identify any unauthorized or malicious entries.
+- Remove or disable any malicious services identified during the investigation to prevent further execution.
+- Restore the system to a known good state using backups or system restore points, ensuring that no malicious services are reintroduced.
+- Implement enhanced logging policies to capture detailed registry changes and service creation events for future analysis.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
+- Apply system hardening measures, such as restricting permissions on critical registry paths and disabling unnecessary services, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_sysmon_wmi_event_subscription.toml b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
index 3a2b3cca798..98df1eb92e5 100644
--- a/rules/windows/persistence_sysmon_wmi_event_subscription.toml
+++ b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/02/02"
 integration = ["windows", "endpoint"]
 maturity = "production"
-updated_date = "2024/12/23"
+updated_date = "2025/01/08"
 min_stack_version = "8.15.0"
 min_stack_comments = "Elastic Defend WMI events were added in Elastic Defend 8.15.0."
 
@@ -45,6 +45,49 @@ any where
     process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer"))
  )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious WMI Event Subscription Created
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this by creating malicious event subscriptions to maintain persistence or execute code with elevated privileges. The detection rule identifies such abuse by monitoring specific event creation patterns linked to suspicious consumer types, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event code 21 from the "windows.sysmon_operational" dataset, indicating a WMI event subscription creation.
+- Examine the `winlog.event_data.Operation` field to ensure it specifies "Created," confirming the creation of a new event subscription.
+- Analyze the `winlog.event_data.Consumer` field to identify if it matches suspicious patterns like "*subscription:CommandLineEventConsumer*" or "*subscription:ActiveScriptEventConsumer*," which are commonly used in malicious activities.
+- Check the timestamp of the event to determine when the suspicious WMI event subscription was created and correlate it with other events or activities on the system around the same time.
+- Investigate the user account associated with the event to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior.
+- Use Osquery to gather more information about the WMI subscriptions on the affected system. For example, run the query: `SELECT * FROM wmi_event_subscriptions WHERE consumer LIKE '%CommandLineEventConsumer%' OR consumer LIKE '%ActiveScriptEventConsumer%';` to identify all similar subscriptions.
+- Cross-reference the system's process creation logs to identify any processes that were spawned as a result of the WMI event subscription, focusing on unusual or unexpected processes.
+- Review the system's security logs for any signs of privilege escalation or lateral movement attempts that might be associated with the WMI event subscription.
+- Investigate any network connections initiated by the system around the time of the event to identify potential communication with external or suspicious IP addresses.
+- Consult threat intelligence sources to determine if the identified WMI event subscription patterns are associated with known malware or threat actor tactics.
+
+### False positive analysis
+
+- Legitimate administrative tools and scripts may create WMI event subscriptions for system monitoring or automation purposes, which can trigger this detection rule. 
+- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes, leading to benign alerts.
+- System management software, such as configuration management tools or monitoring solutions, often utilize WMI event subscriptions to track system changes or performance metrics.
+- To manage these false positives, users can create exceptions for known and trusted applications or scripts by identifying their specific event patterns and excluding them from the detection rule.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule against genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Use endpoint detection and response (EDR) tools to collect and analyze forensic data from the affected system, focusing on the WMI event subscription details.
+- Identify and terminate any malicious processes or scripts associated with the suspicious WMI event subscription.
+- Review and remove any unauthorized WMI event subscriptions, particularly those linked to CommandLineEventConsumer or ActiveScriptEventConsumer.
+- Conduct a thorough investigation to determine if the attacker has established additional persistence mechanisms or compromised other systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to assess the scope of the breach.
+- Implement enhanced logging policies to capture detailed WMI activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Restore the system to a known good state using backups or reimaging, ensuring all malicious artifacts are removed.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Strengthen system hardening measures by disabling unnecessary WMI features and enforcing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_temp_scheduled_task.toml b/rules/windows/persistence_temp_scheduled_task.toml
index a23aede04b4..27e2c69e87c 100644
--- a/rules/windows/persistence_temp_scheduled_task.toml
+++ b/rules/windows/persistence_temp_scheduled_task.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,49 @@ sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m
    [iam where event.action == "scheduled-task-created" and not user.name : "*$"]
    [iam where event.action == "scheduled-task-deleted" and not user.name : "*$"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Temporarily Scheduled Task Creation
+
+Scheduled tasks in Windows environments automate routine tasks, but adversaries exploit them for persistence and stealthy execution. By creating and quickly deleting tasks, they can execute malicious code while evading detection. The detection rule identifies this behavior by tracking task creation and deletion events within a short timeframe, flagging potential misuse by excluding system accounts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the `winlog.computer_name` and `winlog.event_data.TaskName` fields to determine which system and task are involved.
+- Check the timestamp of the task creation and deletion events to confirm they occurred within the specified `maxspan=5m` timeframe.
+- Investigate the user account associated with the task creation and deletion events, ensuring it is not a system account (i.e., does not end with `$`).
+- Use Osquery to list all scheduled tasks on the affected system to verify if the task still exists or if it was indeed deleted. Example query: `SELECT * FROM scheduled_tasks WHERE name = '<TaskName>';`
+- Examine the command or script associated with the scheduled task to identify any potentially malicious code or unusual behavior.
+- Cross-reference the task name and associated command with known indicators of compromise (IOCs) or threat intelligence feeds.
+- Analyze the system's event logs around the time of the task creation and deletion for any other suspicious activities or related events.
+- Check for any recent changes in user privileges or group memberships that might have allowed the creation of the scheduled task.
+- Investigate network logs for any unusual outbound connections from the affected system around the time of the task execution.
+- Review historical data to determine if similar scheduled task creation and deletion patterns have occurred on the same or other systems within the network.
+
+### False positive analysis
+
+- Scheduled tasks created and deleted by legitimate software updates or system maintenance tools can trigger false positives. These tasks often run under non-system accounts but are benign in nature.
+- Automated scripts or administrative tools used by IT departments for routine maintenance might create and delete tasks within a short timeframe, mimicking the behavior flagged by the rule.
+- Users can manage these false positives by identifying and documenting known legitimate task creation and deletion patterns, then creating exceptions for these specific tasks or user accounts.
+- Implementing a whitelist of trusted applications and scripts that are known to create and delete tasks can help reduce noise and focus on truly suspicious activities.
+- Regularly review and update the list of exceptions to ensure it reflects current legitimate activities, especially after software updates or changes in IT processes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity.
+- Review the scheduled task creation and deletion logs to confirm the presence of suspicious activity and identify any associated user accounts.
+- Conduct a thorough investigation to determine if any malicious payloads were executed and assess the scope of the compromise.
+- Remove any unauthorized scheduled tasks and ensure no remnants of the malicious activity remain on the system.
+- Reset credentials for any compromised user accounts and enforce strong password policies to prevent future unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed information on scheduled task activities and user actions for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_user_account_creation_event_logs.toml b/rules/windows/persistence_user_account_creation_event_logs.toml
index 316984f9db8..24061159a2e 100644
--- a/rules/windows/persistence_user_account_creation_event_logs.toml
+++ b/rules/windows/persistence_user_account_creation_event_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["system", "windows"]
 maturity = "development"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,48 @@ query = '''
 event.module:("system" or "security") and winlog.api:"wineventlog" and
   (event.code:"4720" or event.action:"added-user-account")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows User Account Creation
+
+Windows user accounts are essential for managing access and permissions within systems and domains. Adversaries may exploit this by creating unauthorized accounts to maintain persistence or escalate privileges. The detection rule leverages event logs, specifically targeting account creation events, to identify suspicious activities indicative of such abuse, aligning with MITRE ATT&CK's persistence tactics.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event codes 4720 or actions labeled as "added-user-account" to confirm the account creation event.
+- Identify the user account that was created and note the username and any associated details such as the domain or system where it was created.
+- Check the timestamp of the account creation event to determine when the account was created and correlate it with other events around the same time for additional context.
+- Investigate the source of the account creation by identifying the user or process that initiated the event, using fields such as event.module and winlog.api.
+- Examine the system or domain where the account was created to determine if there are any other suspicious activities or anomalies present.
+- Use Osquery to gather more information about the newly created account. For example, run the query: `SELECT * FROM users WHERE username = '<newly_created_username>';` to retrieve details about the account.
+- Analyze the privileges and group memberships of the newly created account to assess if it has elevated permissions that could pose a security risk.
+- Cross-reference the account creation event with other security alerts or logs to identify any patterns or indicators of compromise.
+- Investigate any recent changes to user account policies or configurations that could have facilitated unauthorized account creation.
+- Consult with relevant personnel or teams to verify if the account creation was authorized or part of any legitimate administrative activities.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate system administrators often create user accounts as part of their daily responsibilities. These actions can trigger the detection rule, leading to false positives. To manage this, users can create exceptions for known administrator accounts or specific times when account creation is expected.
+- Automated account creation: Some organizations use scripts or automated processes to create user accounts in bulk, such as during onboarding. These activities can be mistaken for suspicious behavior. Users can exclude these processes by identifying and whitelisting the scripts or automation tools involved.
+- Software installations: Certain software installations may create service accounts or user accounts as part of their setup process. To handle these, users should document and exclude known software-related account creation events.
+- Testing environments: In testing or development environments, frequent account creation may occur as part of testing procedures. Users can exclude these environments from monitoring or create specific rules to differentiate between test and production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Verify the legitimacy of the newly created user account by cross-referencing with authorized account creation requests and contacting the account requester if necessary.
+- If the account is unauthorized, disable or delete the account to prevent its use for persistence or privilege escalation.
+- Conduct a thorough investigation of the system and network logs to identify any additional unauthorized accounts or suspicious activities linked to the same threat actor.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Review and enhance logging policies to ensure comprehensive coverage of account creation events, including enabling detailed auditing for user account management.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying any necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
+- Implement hardening measures such as enforcing strong password policies, enabling multi-factor authentication, and restricting account creation privileges to minimize the risk of unauthorized account creation.
+- Conduct a post-incident review to identify gaps in the response process and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_application_shimming.toml b/rules/windows/persistence_via_application_shimming.toml
index bd2dc22911a..d7aa980b125 100644
--- a/rules/windows/persistence_via_application_shimming.toml
+++ b/rules/windows/persistence_via_application_shimming.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,49 @@ process where host.os.type == "windows" and event.type == "start" and process.na
   not (process.args : "-m" and process.args : "-bg") and
   not process.args : "-mm"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Application Shimming via Sdbinst
+
+Application shimming is a Windows feature designed to ensure software compatibility across different OS versions. However, attackers exploit this by using the sdbinst.exe tool to execute malicious code under the guise of legitimate processes, achieving persistence. The detection rule identifies suspicious sdbinst.exe executions by filtering out benign arguments, flagging potential misuse indicative of adversarial activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious `sdbinst.exe` execution, focusing on the `process.args` field to identify any unusual or unexpected arguments.
+- Check the process tree to understand the parent-child relationship of the `sdbinst.exe` process, identifying the parent process that initiated the execution.
+- Investigate the user account associated with the `sdbinst.exe` process to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Examine the timestamp of the `sdbinst.exe` execution to correlate with other suspicious activities or events on the host.
+- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'sdbinst.exe';` to retrieve detailed information about the process execution.
+- Search for any recent file modifications or creations in directories commonly associated with application shimming, such as the AppCompat folder, to identify potential malicious SDB files.
+- Analyze the network activity of the host around the time of the `sdbinst.exe` execution to detect any unusual outbound connections or data exfiltration attempts.
+- Review system logs for any other indicators of compromise or related suspicious activities that occurred around the same time as the alert.
+- Investigate any other alerts or detections involving the same host or user account to identify patterns or a broader attack campaign.
+- Consult threat intelligence sources to determine if there are known campaigns or threat actors that commonly use application shimming techniques similar to those detected.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger sdbinst.exe with arguments that appear suspicious but are benign, such as custom software deployment scripts or enterprise software updates that use sdbinst.exe for compatibility reasons.
+- System administrators or IT personnel might use sdbinst.exe intentionally for legitimate application compatibility testing or deployment, which could be misidentified as malicious activity.
+- To manage these false positives, users can create exceptions for known and verified software installations by whitelisting specific command-line arguments or paths associated with trusted applications.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary processes are excluded, minimizing the risk of overlooking genuine threats.
+- Implement logging and monitoring to track the frequency and context of sdbinst.exe executions, allowing for better differentiation between legitimate and potentially malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the sdbinst.exe process execution, including reviewing the command-line arguments and correlating with known malicious patterns.
+- Analyze the system for additional indicators of compromise (IOCs) related to application shimming and persistence mechanisms.
+- Terminate any suspicious processes associated with the malicious use of sdbinst.exe and remove any unauthorized application compatibility databases.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Review and update security policies and procedures to include specific measures against application shimming and related persistence techniques.
+- Conduct a post-incident review to identify gaps in detection and response, and apply lessons learned to strengthen the overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_bits_job_notify_command.toml b/rules/windows/persistence_via_bits_job_notify_command.toml
index 42a345b965a..23e91a5c868 100644
--- a/rules/windows/persistence_via_bits_job_notify_command.toml
+++ b/rules/windows/persistence_via_bits_job_notify_command.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,52 @@ process where host.os.type == "windows" and event.type == "start" and
                "?:\\Windows\\System32\\wermgr.exe",
                "?:\\WINDOWS\\system32\\directxdatabaseupdater.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via BITS Job Notify Cmdline
+
+The Background Intelligent Transfer Service (BITS) is a Windows component that facilitates asynchronous, prioritized, and throttled transfer of files between machines. Adversaries exploit BITS by using the SetNotifyCmdLine method to execute malicious programs post-transfer, achieving persistence. The detection rule identifies suspicious processes initiated by BITS, excluding legitimate executables, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process was initiated by `svchost.exe` with arguments containing "BITS" and verify the process executable is not among the known legitimate ones listed in the detection rule.
+- Gather additional context by identifying the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Check the process creation time and correlate it with any known scheduled tasks or user activity to identify if the execution was expected or anomalous.
+- Investigate the command line arguments of the suspicious process to understand its intended function and assess if it aligns with typical BITS job activities.
+- Use Osquery to list all BITS jobs on the system and their associated notify command lines to identify any other potentially malicious jobs:
+  ```sql
+  SELECT job_id, notify_cmd_path, notify_cmd_arguments FROM bits_jobs;
+  ```
+- Examine the network connections established by the suspicious process to identify any unusual or unauthorized external communications.
+- Review the system's event logs around the time of the process execution for any additional indicators of compromise or related activities.
+- Investigate the parent process `svchost.exe` to ensure it is legitimate and not a masqueraded or compromised instance.
+- Check for any recent changes to the system's BITS configuration or related registry keys that could indicate tampering or persistence mechanisms.
+- Cross-reference the findings with threat intelligence sources to determine if the observed behavior matches any known threat actor techniques or campaigns.
+
+### False positive analysis
+
+- Legitimate software updates or system maintenance tasks may trigger the BITS Job Notify Cmdline rule, as some applications use BITS for downloading updates or patches, leading to false positives.
+- System administrators might use BITS for deploying software or updates across a network, which could be flagged by the rule if the executables are not in the exclusion list.
+- To manage these false positives, users can create exceptions for known legitimate processes that frequently trigger the rule by adding them to the exclusion list in the detection query.
+- Regularly review and update the exclusion list to include new legitimate processes that are identified as false positives, ensuring that the detection rule remains effective without generating unnecessary alerts.
+- Collaborate with IT and security teams to identify and document legitimate use cases of BITS within the organization, which can then be used to refine the detection rule and minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on processes initiated by BITS and any associated files or network connections.
+- Terminate any suspicious processes that were initiated by BITS and remove any malicious files identified during the investigation.
+- Review and analyze the BITS job configurations to identify any unauthorized or suspicious jobs and remove them.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process creation events, including command-line arguments, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
+- Educate users and administrators about the risks associated with BITS abuse and provide training on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_hidden_run_key_valuename.toml b/rules/windows/persistence_via_hidden_run_key_valuename.toml
index 88ed115ee77..5992490ebfa 100644
--- a/rules/windows/persistence_via_hidden_run_key_valuename.toml
+++ b/rules/windows/persistence_via_hidden_run_key_valuename.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,49 @@ registry where host.os.type == "windows" and event.type == "change" and length(r
                   "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\",
                   "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via Hidden Run Key Detected
+
+Windows systems use registry keys to manage startup programs, a feature adversaries exploit to maintain persistence. By leveraging the NtSetValueKey API, attackers can create hidden registry entries that evade standard tools like regedit. The detection rule identifies changes in specific registry paths, focusing on entries with null-terminated keys, signaling potential stealthy persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path and key that triggered the detection, focusing on paths ending with a backslash as indicated in the query.
+- Verify the host information from the alert to determine the affected system and gather additional context about its role and importance within the network.
+- Use a tool like Osquery to list all registry keys under the specified path to identify any null-terminated keys. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_USERS\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE 'HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE 'HKLM\\\\Software\\\\WOW6432Node\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE 'HKEY_USERS\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE 'HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\USER\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\WOW6432Node\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\USER\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%'`.
+- Check the timestamp of the registry change event to correlate it with other system activities or logs, such as user logins or software installations, to identify potential sources or related events.
+- Investigate the process that made the registry change by reviewing process creation logs or using endpoint detection and response (EDR) tools to trace the process lineage and command-line arguments.
+- Examine the registry key value data to determine if it points to a legitimate application or a suspicious executable, and verify the file's existence and properties on the disk.
+- Cross-reference the registry key value data with known good baselines or threat intelligence sources to identify any known malicious indicators or patterns.
+- Analyze network logs or traffic from the affected host around the time of the registry change to detect any unusual outbound connections or data exfiltration attempts.
+- Review user activity logs to determine if the registry change was made by a legitimate user or if there are signs of compromised credentials or unauthorized access.
+- Document all findings and evidence collected during the investigation to support further analysis or potential escalation to incident response teams.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify registry keys in the specified paths, leading to false positives. Users should verify if the changes coincide with known software activities.
+- System administrators may use scripts or management tools that alter registry keys for configuration purposes. These should be documented and excluded from alerts if verified as non-malicious.
+- Some security software may create or modify registry entries in these paths as part of their normal operation. Users should identify these applications and create exceptions for them.
+- Group Policy Objects (GPOs) applied in enterprise environments might result in registry changes that trigger the detection rule. Administrators should review GPO settings and exclude expected changes.
+- Users can handle false positives by creating exceptions for specific registry paths or values that are known to be safe, ensuring these exceptions are regularly reviewed and updated as necessary.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Use a trusted tool to inspect the registry paths identified in the alert for any suspicious or unauthorized entries.
+- Remove any unauthorized or suspicious registry entries found in the specified paths to eliminate persistence mechanisms.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any associated malware.
+- Review recent system changes and user activity logs to identify how the persistence mechanism was introduced and assess the scope of the compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
+- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
+- Apply hardening measures such as restricting registry editing permissions, enforcing least privilege principles, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
index 7a3c8569eb7..aaca3df5a6f 100644
--- a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
+++ b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,48 @@ registry where host.os.type == "windows" and event.type == "change" and
    ) and
    not process.executable : ("C:\\Windows\\System32\\msiexec.exe", "C:\\Windows\\SysWOW64\\msiexec.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Installation of Security Support Provider
+
+Security Support Providers (SSPs) in Windows are crucial for handling authentication requests. They are configured via specific registry paths. Adversaries may exploit SSPs to gain persistence by modifying these registry entries to load malicious code at system startup. The detection rule identifies unauthorized changes to these registry paths, excluding legitimate processes, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path that was modified, focusing on paths related to "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\Security Packages*" and "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\OSConfig\\\\Security Packages*".
+- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other events in the system logs around the same time.
+- Investigate the process that made the registry change by examining the process ID and executable path, ensuring it is not one of the excluded legitimate processes like "C:\\\\Windows\\\\System32\\\\msiexec.exe".
+- Use Osquery to list all current entries in the Security Packages registry key to identify any unfamiliar or suspicious entries. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%\\\\Control\\\\Lsa\\\\Security Packages';`
+- Cross-reference the process that made the change with known malicious processes or hash values using threat intelligence sources.
+- Analyze the user account context under which the registry change was made to determine if it was performed by an unauthorized or compromised account.
+- Review recent login events and user activity for the account associated with the registry change to identify any anomalies or unauthorized access.
+- Check for any recent software installations or updates that might have legitimately modified the Security Support Provider configuration.
+- Investigate network activity from the host around the time of the registry change for any signs of data exfiltration or communication with known malicious IP addresses.
+- Examine other systems in the network for similar registry changes to assess if this is an isolated incident or part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger registry changes in the Security Support Provider paths, particularly when using installers like msiexec.exe. These are typically benign and can be excluded from alerts.
+- System administrators or security tools may intentionally modify SSP registry entries as part of routine maintenance or security hardening, which could be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for known and trusted processes or executables that frequently modify these registry paths, ensuring they are not flagged by the detection rule.
+- Regularly review and update the list of excluded processes to reflect changes in the environment, such as new software deployments or updates to existing applications, to maintain an accurate and effective detection strategy.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or spread of malicious code.
+- Review the registry changes to confirm unauthorized modifications and identify any malicious SSPs that have been added.
+- Terminate any suspicious processes associated with the unauthorized registry changes to halt potential malicious activity.
+- Restore the registry entries to their original state using a known good backup or by manually removing the unauthorized entries.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
+- Review system and security logs to trace the source of the unauthorized changes and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and response.
+- Implement enhanced logging policies to capture detailed information on registry changes and process executions for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Apply security hardening measures, such as restricting registry access permissions and implementing application whitelisting, to prevent similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
index 93aef1c28b4..7bbe784167b 100644
--- a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
+++ b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,49 @@ process where host.os.type == "windows" and event.type == "start" and
                       "rundll32.exe",
                       "powershell.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via TelemetryController Scheduled Task Hijack
+
+The Microsoft Compatibility Appraiser, part of Windows telemetry, uses scheduled tasks to assess system compatibility. Adversaries may hijack these tasks to gain persistent, high-integrity access by executing unauthorized processes. The detection rule identifies anomalies by monitoring process executions initiated by the telemetry task, excluding known legitimate processes, to flag potential hijacks.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments that triggered the detection, focusing on the `process.parent.name` and `process.args` fields.
+- Verify the legitimacy of the process by checking the process hash against known good hashes or threat intelligence databases.
+- Investigate the parent process `CompatTelRunner.exe` to determine if it has been tampered with or replaced by a malicious version.
+- Examine the command line arguments (`process.args`) used by the suspicious process to understand its intended actions and potential impact.
+- Use Osquery to list all scheduled tasks on the system and identify any modifications or unusual entries related to the Microsoft Compatibility Appraiser. Example query: `SELECT * FROM scheduled_tasks WHERE name LIKE '%CompatTelRunner%';`
+- Check the system's event logs for any recent changes to scheduled tasks, especially those involving `CompatTelRunner.exe`, to identify potential unauthorized modifications.
+- Analyze the timeline of events leading up to the alert to identify any preceding suspicious activities or related alerts that might indicate a broader attack campaign.
+- Investigate the user account context under which the suspicious process was executed to determine if it has been compromised or misused.
+- Review network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
+- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather additional context and confirm the scope of the potential compromise.
+
+### False positive analysis
+
+- Known false positives may include legitimate processes that are not part of the predefined exclusion list but are still initiated by the Microsoft Compatibility Appraiser task. These could be custom scripts or applications that organizations have integrated into their system maintenance routines.
+- Users can handle these false positives by reviewing the flagged processes to determine if they are part of legitimate operations. If confirmed as non-threatening, these processes can be added to the exclusion list to prevent future alerts.
+- Another potential false positive scenario involves system administrators using custom tools or scripts that mimic the behavior of excluded processes for maintenance or monitoring purposes. These should be documented and excluded accordingly.
+- Regularly updating the exclusion list to reflect changes in legitimate system processes or newly introduced applications can help minimize false positives.
+- It is important to maintain a balance between security and operational efficiency by ensuring that only verified non-threatening processes are excluded, thus maintaining the integrity of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the hijack by reviewing the process execution logs and identifying any unauthorized processes initiated by the telemetry task.
+- Terminate any malicious processes identified during the investigation to halt any ongoing unauthorized activities.
+- Restore the scheduled task to its original state by reconfiguring it to execute only legitimate processes, ensuring the integrity of the Microsoft Compatibility Appraiser.
+- Perform a comprehensive scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats or malware.
+- Review and update the system's scheduled tasks and permissions to ensure only authorized users and processes can modify them.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed telemetry task execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate similar events across the network.
+- Apply system hardening measures, such as disabling unnecessary services and applying the principle of least privilege, to reduce the attack surface and prevent future hijacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
index c174b2eed5e..d707ae79add 100644
--- a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
+++ b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,49 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "create" and
   process.args : ("ActiveScriptEventConsumer", "CommandLineEventConsumer")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Persistence via WMI Event Subscription
+
+Windows Management Instrumentation (WMI) allows for system management and monitoring through event subscriptions, which can be exploited by adversaries to maintain persistence. By creating event filters and consumers, attackers can execute code in response to system events. The detection rule identifies suspicious use of `wmic.exe` to create event consumers, signaling potential abuse for persistence.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `wmic.exe` in the process name or `process.pe.original_file_name` fields, indicating the use of Windows Management Instrumentation Command-line.
+- Examine the `process.args` field to verify the presence of "create" along with "ActiveScriptEventConsumer" or "CommandLineEventConsumer", which suggests the creation of event consumers.
+- Check the `event.type` field to ensure it is marked as "start", indicating the initiation of a process that could be related to persistence mechanisms.
+- Investigate the parent process of `wmic.exe` to determine if it was spawned by a legitimate or suspicious process, which could provide context on how the execution was initiated.
+- Use Osquery to list all WMI event consumers on the system with a query like: `SELECT * FROM wmi_event_consumers;` to identify any suspicious or unauthorized consumers.
+- Cross-reference the timestamp of the alert with other logs or events on the system to identify any correlated activities or anomalies around the same time.
+- Analyze the user account context under which `wmic.exe` was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Review system logs for any additional WMI-related activities or errors that could provide further insight into the persistence mechanism being established.
+- Investigate any network connections or external communications initiated by `wmic.exe` or its parent process to identify potential command and control activities.
+- Check for any recent changes in system configurations or scheduled tasks that might have been altered to facilitate persistence through WMI event subscriptions.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators may use `wmic.exe` to create event consumers for legitimate monitoring and automation purposes. These activities can trigger the detection rule but are not malicious.
+- Software installations and updates: Some software installations or updates might use WMI event subscriptions as part of their setup or configuration processes, leading to false positives.
+- Monitoring and management tools: Certain IT management tools may utilize WMI event subscriptions to monitor system events, which can be mistaken for malicious activity.
+- To manage false positives, users can create exceptions for known legitimate processes or activities by whitelisting specific command lines or process hashes associated with trusted software and administrative tasks.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on WMI event subscriptions and any associated scripts or commands.
+- Terminate any malicious processes identified, particularly those related to `wmic.exe` and suspicious event consumers.
+- Remove unauthorized WMI event subscriptions by using tools like `wevtutil` or PowerShell to list and delete suspicious filters and consumers.
+- Restore the system to a known good state using backups or system restore points, ensuring that all malicious changes are reverted.
+- Implement enhanced logging policies to monitor WMI activity, including event subscription creation and execution, to detect future abuse.
+- Integrate security solutions with SIEM systems to correlate WMI activity with other security events for comprehensive threat detection.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Review and update security policies and procedures to include regular audits of WMI configurations and event subscriptions.
+- Apply system hardening measures, such as restricting WMI access to authorized users and implementing application whitelisting to prevent unauthorized execution of `wmic.exe`."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_werfault_reflectdebugger.toml b/rules/windows/persistence_werfault_reflectdebugger.toml
index b798b066051..311aeb5ec2d 100644
--- a/rules/windows/persistence_werfault_reflectdebugger.toml
+++ b/rules/windows/persistence_werfault_reflectdebugger.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,48 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Werfault ReflectDebugger Persistence
+
+Werfault, the Windows Error Reporting service, aids in diagnosing application crashes. Attackers can exploit its ReflectDebugger registry key to persistently execute malicious code by configuring it to trigger on error reports. The detection rule monitors changes to specific registry paths, identifying unauthorized modifications that suggest adversaries are setting up persistence mechanisms through this method.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path involved matches one of the specified paths in the detection rule: "HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\Hangs\\\\ReflectDebugger", "\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\Hangs\\\\ReflectDebugger", or "MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\Hangs\\\\ReflectDebugger".
+- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other events or activities on the system around the same time.
+- Identify the user account or process that made the registry change by examining the event logs for user or process information associated with the change event.
+- Investigate the system for any recent application crashes or error reports that could have triggered the Werfault service, potentially executing the malicious payload.
+- Use Osquery to list all current registry keys under the Windows Error Reporting path to identify any other suspicious entries: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\%';`
+- Examine the system for any unusual or unauthorized processes running, especially those that may have been initiated around the time of the registry change.
+- Review network logs for any suspicious outbound connections from the host that could indicate data exfiltration or command and control activity.
+- Check for any recent software installations or updates that could have introduced the registry change, focusing on software that interacts with error reporting or debugging.
+- Analyze the system for any additional persistence mechanisms that may have been established, such as scheduled tasks or startup items, which could indicate a broader compromise.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, providing additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the ReflectDebugger registry key as part of their error reporting configuration, leading to false positives. Users should verify the source of the change and consider excluding known trusted software from triggering alerts.
+- System administrators or IT management tools might intentionally configure the ReflectDebugger key for monitoring or debugging purposes. In such cases, document these changes and create exceptions for these specific registry modifications to prevent unnecessary alerts.
+- Some security or diagnostic tools may interact with the ReflectDebugger registry key as part of their normal operation. Users should identify these tools and whitelist their activities to avoid false positives.
+- Regular audits of registry changes by authorized personnel might trigger alerts. Ensure that these activities are logged and recognized as non-threatening, and adjust the detection rule to exclude these known activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm unauthorized modifications to the ReflectDebugger registry key and identify any associated malicious payloads.
+- Review recent system and application logs to trace the origin of the unauthorized changes and gather additional context on the attack vector.
+- Remove or revert any unauthorized changes to the ReflectDebugger registry key to eliminate the persistence mechanism.
+- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to monitor registry changes and other critical system activities for early detection of similar threats in the future.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
+- Restore the system to its operational state by applying verified clean backups and ensuring all security patches and updates are installed.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_create_process_as_different_user.toml b/rules/windows/privilege_escalation_create_process_as_different_user.toml
index ffaaf3a68b9..327451454a3 100644
--- a/rules/windows/privilege_escalation_create_process_as_different_user.toml
+++ b/rules/windows/privilege_escalation_create_process_as_different_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,49 @@ sequence by winlog.computer_name with maxspan=1m
 
 [process where event.type == "start"] by winlog.event_data.TargetLogonId
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Creation via Secondary Logon
+
+The Secondary Logon service allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process initiations, linking them through unique logon identifiers.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, focusing on the `winlog.computer_name` and `winlog.event_data.TargetLogonId` to identify the affected system and session.
+- Verify the `user.id` involved in the event to determine if the account is known and if it has legitimate reasons to use the Secondary Logon service.
+- Check the `source.ip` field to confirm if the login originated from a local source (`::1`) and assess if this is expected behavior for the user or system.
+- Investigate the `process.name` to ensure it is indeed `svchost.exe` and not a masquerading process, which could indicate malicious activity.
+- Correlate the `winlog.event_data.LogonProcessName` with "seclogo*" to confirm the use of the Secondary Logon service.
+- Use Osquery to list all processes started by the identified `winlog.event_data.TargetLogonId` to gather more context on what actions were taken post-login. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');`
+- Examine the timeline of events around the alert to identify any unusual patterns or sequences of actions that deviate from normal user behavior.
+- Cross-reference the `event.action` and `event.outcome` fields with other authentication logs to identify any anomalies or repeated patterns of successful logins using alternate credentials.
+- Investigate any other security alerts or logs related to the same `winlog.computer_name` or `user.id` to determine if this event is part of a larger attack pattern.
+- Consult with the user or system owner to verify if the use of the Secondary Logon service was authorized and necessary, and gather any additional context that may explain the activity.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often use the Secondary Logon service to perform tasks requiring elevated privileges, which can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific tasks that are regularly performed.
+- Scheduled tasks and maintenance scripts: Automated scripts or scheduled tasks that require elevated privileges might also use the Secondary Logon service. Users can handle these by identifying and excluding specific scripts or task names that are part of routine maintenance.
+- Software updates and installations: Some software updates or installations may use alternate credentials to execute necessary processes. Users should monitor and whitelist known update processes or installation packages to prevent false positives.
+- Internal security tools: Certain security tools may use the Secondary Logon service for legitimate monitoring or scanning activities. Users can exclude these tools by identifying their process names or associated logon identifiers.
+- Testing and development environments: In environments where frequent testing or development occurs, processes may be created with alternate credentials for testing purposes. Users can manage these by excluding specific environments or user accounts associated with development activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Verify the legitimacy of the user account involved in the alert by checking recent activity and cross-referencing with known user behavior.
+- Investigate the process tree associated with the suspicious process creation to identify any malicious or unauthorized processes.
+- Terminate any malicious processes identified during the investigation to prevent further execution of unauthorized actions.
+- Reset the credentials of the compromised user account and any other accounts that may have been affected.
+- Conduct a thorough review of system and security logs to identify any additional indicators of compromise or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if assistance is needed.
+- Implement enhanced logging policies to capture detailed authentication and process creation events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface and prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
index ffd8fd02012..efc451df324 100644
--- a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
+++ b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,49 @@ process where host.os.type == "windows" and event.action == "start" and
  not (process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe" and 
       process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\msiexec.exe", "?:\\Windows\\twain_32\\*.exe"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Created with a Duplicated Token
+
+In Windows environments, tokens are used to represent user credentials and permissions. Adversaries may duplicate tokens to create processes with elevated privileges, bypassing security controls. The detection rule identifies suspicious process creation by examining token impersonation patterns, process origins, and anomalies in executable paths, helping to uncover potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process was created and the associated user ID, focusing on the `process.name` and `user.id` fields.
+- Examine the `process.Ext.effective_parent.executable` field to determine the origin of the parent process and assess if it is a known legitimate source or potentially malicious.
+- Check the `process.command_line` for any suspicious or unexpected command-line arguments that could indicate malicious intent.
+- Investigate the `process.Ext.relative_file_creation_time` and `process.Ext.relative_file_name_modify_time` to identify if the process was recently created or modified, which could suggest tampering.
+- Verify the `process.code_signature.status` to determine if the executable is signed and trusted, which can help differentiate between legitimate and potentially malicious processes.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list processes with their parent details: `SELECT pid, name, path, parent, uid FROM processes WHERE name = '<suspicious_process_name>';`
+- Cross-reference the `process.parent.name` and `process.Ext.effective_parent.name` fields to identify any discrepancies or unusual parent-child relationships that could indicate token manipulation.
+- Analyze the `process.parent.executable` to ensure it aligns with expected behavior for the parent process, checking for any anomalies or unexpected paths.
+- Review historical data for the `user.id` to identify any patterns of unusual activity or previous alerts that could suggest a compromised account.
+- Correlate the alert with other security events or logs from the same timeframe to build a comprehensive timeline of activities and identify any additional indicators of compromise.
+
+### False positive analysis
+
+- Legitimate administrative tools: Processes like "powershell.exe" or "cmd.exe" may be flagged when used by IT administrators for routine tasks. Users can create exceptions for these processes when executed by known administrative accounts.
+- Software updates and installations: During software updates or installations, processes such as "msiexec.exe" or "svchost.exe" might trigger alerts. Users can exclude these processes when they originate from trusted software update paths.
+- System maintenance tasks: Scheduled tasks or system maintenance activities might involve processes like "tasklist.exe" or "reg.exe". Users should monitor the context and frequency of these tasks and consider excluding them if they align with regular maintenance schedules.
+- Custom scripts and automation: Organizations using custom scripts for automation might see false positives with processes like "rundll32.exe" or "bitsadmin.exe". Users can whitelist these scripts by verifying their source and ensuring they are signed or located in trusted directories.
+- Third-party security tools: Some security tools may mimic adversarial behavior for testing purposes, triggering false positives. Users should identify these tools and exclude their processes from detection rules, ensuring they are from a trusted vendor.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the token duplication, examining logs and correlating events to determine the adversary's entry point and actions.
+- Terminate any suspicious processes identified as running with duplicated tokens to halt any ongoing malicious activity.
+- Review and analyze user account activity to identify any unauthorized access or privilege escalation attempts, focusing on accounts associated with the duplicated tokens.
+- Reset passwords for compromised accounts and enforce multi-factor authentication to enhance account security.
+- Restore the system to a known good state using backups, ensuring that the backup is free from any compromise.
+- Implement enhanced logging policies to capture detailed process creation and token usage events, aiding in future detection and investigation efforts.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to provide real-time monitoring and automated response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate users and administrators on the risks of token manipulation and privilege escalation, emphasizing the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_credroaming_ldap.toml b/rules/windows/privilege_escalation_credroaming_ldap.toml
index 2595cb73e58..49fee5b8584 100644
--- a/rules/windows/privilege_escalation_credroaming_ldap.toml
+++ b/rules/windows/privilege_escalation_credroaming_ldap.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,6 +60,49 @@ event.action:("Directory Service Changes" or "directory-service-object-modified"
   winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and winlog.event_data.OperationType:"%%14674" and
   not winlog.event_data.SubjectUserSid : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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. Attackers may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service change events, focusing on unauthorized user actions, thus helping to thwart privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event code "5136" and ensure the modification pertains to the "msPKIAccountCredentials" attribute.
+- Verify the "event.action" field to determine if the action was logged as "Directory Service Changes" or "directory-service-object-modified" to confirm the type of change.
+- Check the "winlog.event_data.SubjectUserSid" field to identify the user who initiated the change and ensure it is not the system account "S-1-5-18".
+- Investigate the "winlog.event_data.OperationType" field for the value "%%14674" to understand the nature of the operation performed on the attribute.
+- Correlate the timestamp of the event with other logs to identify any concurrent suspicious activities or anomalies in the network.
+- Use Osquery to gather additional context on the affected system. For example, run the following query to list recent changes to Active Directory objects: `SELECT * FROM ad_config WHERE attribute = 'msPKIAccountCredentials' AND action = 'MODIFY';`
+- Examine the history of changes to the "msPKIAccountCredentials" attribute for the affected user object to identify any patterns or repeated unauthorized modifications.
+- Cross-reference the user account involved with known threat intelligence sources to check for any history of malicious activity or compromise.
+- Analyze network traffic logs around the time of the event to detect any unusual outbound connections or data exfiltration attempts.
+- Consult with the Active Directory team to verify if the change was part of any legitimate administrative activity or if it was unauthorized.
+
+### False positive analysis
+
+- Routine administrative tasks: Regular updates or maintenance activities by authorized IT personnel may trigger the rule. To manage this, create exceptions for known administrative accounts or specific maintenance windows.
+- Automated system processes: Scheduled tasks or automated scripts that interact with Active Directory objects might modify the msPKIAccountCredentials attribute. Identify these processes and exclude them from the rule to prevent unnecessary alerts.
+- Software updates: Certain software updates or installations may require modifications to credential attributes. Monitor and document these updates, and consider excluding them if they are verified as non-threatening.
+- Legitimate credential management: Tools or services that manage user credentials, such as password managers or enterprise credential management systems, may cause changes to the attribute. Verify these tools and exclude their actions if they are deemed safe.
+- User account migrations: During user account migrations or domain consolidations, the msPKIAccountCredentials attribute might be modified. Recognize these events and exclude them from the rule to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the modification, including reviewing logs for any unauthorized access or changes to the msPKIAccountCredentials attribute.
+- Verify the integrity of the affected Active Directory objects and restore them from a known good backup if necessary.
+- Reset passwords and revoke any potentially compromised certificates or keys associated with the affected accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring for Active Directory changes, focusing on sensitive attributes like msPKIAccountCredentials, to detect future unauthorized modifications.
+- Integrate security information and event management (SIEM) solutions to correlate events and provide real-time alerts for suspicious activities related to privilege escalation attempts.
+- Review and update access controls and permissions for Active Directory objects to ensure the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements to prevent similar incidents.
+- Educate and train IT staff and users on recognizing and reporting suspicious activities, emphasizing the importance of maintaining secure credentials and adhering to security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
index a6e2874c53a..fafd16ce93b 100644
--- a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
+++ b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,50 @@ any where host.os.type == "windows" and event.category : ("library", "process")
   not ?dll.code_signature.trusted == true and
   not file.code_signature.status == "Valid"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unsigned DLL loaded by DNS Service
+
+The DNS service on Windows systems is crucial for resolving domain names to IP addresses. It uses DLLs to extend its functionality. Adversaries may exploit this by loading malicious, unsigned DLLs into the DNS service, potentially gaining elevated privileges and executing arbitrary code. The detection rule identifies such threats by monitoring for DLLs loaded by the DNS process that lack valid signatures, indicating possible tampering or unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process executable is "?:\\\\windows\\\\system32\\\\dns.exe" and verify the DLL in question is indeed unsigned.
+- Check the event logs for any recent changes or unusual activity around the time the unsigned DLL was loaded, focusing on event categories "library" and "process" with event types "start" and "change".
+- Investigate the file path and name of the unsigned DLL to determine if it is known or expected within the environment.
+- Use Osquery to list all DLLs currently loaded by the DNS service with the following query: `SELECT path, name, pid FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE path LIKE '%dns.exe%';`
+- Examine the file metadata of the unsigned DLL, including creation and modification timestamps, to identify any anomalies or recent changes.
+- Cross-reference the unsigned DLL's hash against threat intelligence databases to check for known malicious signatures.
+- Analyze the parent process and any associated child processes of the DNS service to identify potential lateral movement or further exploitation attempts.
+- Review user and system activity logs around the time of the DLL load event to identify any suspicious behavior or unauthorized access attempts.
+- Investigate network connections initiated by the DNS service to detect any unusual or unauthorized external communications.
+- Consult with the system owner or administrator to verify if the unsigned DLL is part of a legitimate application or recent update that may not yet be signed.
+
+### False positive analysis
+
+- Some legitimate software may load unsigned DLLs into the DNS service for valid reasons, such as custom network management tools or legacy applications that do not have signed components. 
+- Security software or monitoring tools might inject unsigned DLLs for tracking or analysis purposes, which could be mistaken for malicious activity.
+- In environments with custom or in-house developed applications, these applications might not have signed DLLs, leading to false positives when they interact with the DNS service.
+- To manage these false positives, users can create exceptions for known and trusted applications by whitelisting their DLLs or processes in the security monitoring tool.
+- Regularly update the list of trusted software and their components to ensure that legitimate updates or changes do not trigger false alerts.
+- Collaborate with IT and security teams to maintain an inventory of authorized software and their expected behaviors, which can help in quickly identifying and excluding benign activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the unsigned DLLs loaded by the DNS service.
+- Verify the integrity of the DNS service and its associated files by comparing them against known good versions or using a trusted source.
+- Remove any unauthorized or malicious DLLs identified during the investigation and replace them with legitimate versions.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed information on DLL loads and process activities, ensuring future incidents can be detected more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and conducting a full system scan to ensure no residual threats remain.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring all software is up-to-date.
+- Review and update security policies and procedures to incorporate lessons learned from the incident, enhancing the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_expired_driver_loaded.toml b/rules/windows/privilege_escalation_expired_driver_loaded.toml
index 5026c5b0606..fe544837b92 100644
--- a/rules/windows/privilege_escalation_expired_driver_loaded.toml
+++ b/rules/windows/privilege_escalation_expired_driver_loaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,49 @@ query = '''
 driver where host.os.type == "windows" and process.pid == 4 and
   dll.code_signature.status : ("errorExpired", "errorRevoked")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Expired or Revoked Driver Loaded
+
+In Windows environments, drivers facilitate communication between the OS and hardware. Adversaries exploit vulnerabilities in outdated drivers or misuse revoked certificates to execute malicious code in kernel mode, gaining elevated privileges. The detection rule identifies such threats by monitoring for drivers with expired or revoked signatures, specifically targeting processes with system-level access.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a driver with an expired or revoked signature, focusing on the `dll.code_signature.status` field for values "errorExpired" or "errorRevoked".
+- Verify the process ID (`process.pid`) to ensure it matches the system process (PID 4), which indicates a driver loaded at the system level.
+- Identify the specific driver file involved by examining the associated file path and name, if available, in the alert details.
+- Check the driver file's digital signature details to confirm its expiration or revocation status using tools like Sigcheck.
+- Investigate the driver file's origin and history by checking its creation and modification timestamps to determine if it was recently introduced to the system.
+- Use Osquery to gather additional context about the driver file. Example query: `SELECT * FROM kernel_modules WHERE name = '<driver_name>';` to retrieve details about the loaded driver.
+- Cross-reference the driver file's hash against known malware databases or threat intelligence sources to identify any known malicious activity associated with it.
+- Examine system logs and security events around the time the driver was loaded to identify any suspicious activities or related alerts.
+- Investigate any recent changes or updates to the system that might have introduced the driver, such as software installations or updates.
+- Collaborate with other security teams or stakeholders to gather additional context or insights about the driver and its potential impact on the system.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve drivers with expired or revoked signatures, especially if the vendor has not updated their certificates promptly.
+- Some older hardware devices may rely on drivers that are no longer supported or updated, leading to false positives when these drivers are loaded.
+- Security or system management tools that interact with kernel mode might use drivers with expired signatures for legitimate purposes, causing alerts.
+- To manage these false positives, users can create exceptions for specific drivers or processes known to be safe by adding them to an allowlist within the monitoring system.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening drivers are excluded, maintaining a balance between security and operational needs.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Verify the legitimacy of the driver by checking its source and intended use; remove any unauthorized or malicious drivers.
+- Conduct a thorough investigation to identify how the expired or revoked driver was loaded, focusing on potential vulnerabilities or misconfigurations.
+- Utilize endpoint detection and response (EDR) tools to scan for additional signs of compromise or related malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and containment measures.
+- Apply patches or updates to the operating system and all drivers to mitigate known vulnerabilities.
+- Implement strict driver signing policies and enforce the use of only trusted and verified drivers.
+- Enhance logging and monitoring to capture detailed information on driver loads and process activities, integrating with SIEM solutions for real-time alerts.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on the risks associated with outdated or unauthorized drivers and the importance of maintaining up-to-date systems."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_exploit_cve_202238028.toml b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
index 3d234029f7e..3a7d532fb8c 100644
--- a/rules/windows/privilege_escalation_exploit_cve_202238028.toml
+++ b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,48 @@ file where host.os.type == "windows" and event.type != "deletion" and
         "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js"
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential privilege escalation via CVE-2022-38028
+
+CVE-2022-38028 targets the Windows Print Spooler service, a core component managing print jobs. Adversaries exploit this by manipulating specific JavaScript files within system directories to gain elevated privileges. The detection rule identifies unauthorized modifications to these files, signaling potential exploitation attempts, thus enabling timely intervention.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file name and path match those specified in the detection query: "MPDW-constraints.js" within the specified system directories.
+- Verify the event type to ensure it is not a deletion event, as the query excludes such events.
+- Check the file modification timestamps to determine when the unauthorized changes occurred and correlate with any known user activity or scheduled tasks.
+- Investigate the user account associated with the file modification event to assess if it has the necessary permissions and if the activity aligns with their typical behavior.
+- Use Osquery to gather additional context on the file by running a query such as: `SELECT * FROM file WHERE path LIKE 'C:\\\\Windows\\\\system32\\\\DriVerStoRe\\\\FiLeRePoSiToRy\\\\%\\\\MPDW-constraints.js' OR path LIKE 'C:\\\\Windows\\\\WinSxS\\\\amd64_microsoft-windows-printing-printtopdf_%\\\\MPDW-constraints.js';` to verify file attributes and metadata.
+- Examine recent system logs for any unusual or suspicious activities around the time of the file modification, focusing on print spooler service logs and security logs.
+- Cross-reference the event with any other alerts or incidents involving the same host to identify potential patterns or related activities.
+- Investigate any network connections or external communications from the host around the time of the event to detect possible data exfiltration or command and control activities.
+- Check for any recent software installations or updates on the host that might have inadvertently or maliciously modified the file.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently exploiting CVE-2022-38028, which could provide additional context or indicators of compromise.
+
+### False positive analysis
+
+- Routine system updates or legitimate software installations may modify the `MPDW-constraints.js` file, triggering the detection rule. Users should verify if these changes coincide with scheduled updates or trusted software installations.
+- Security software or system maintenance tools might access or modify the `MPDW-constraints.js` file as part of their normal operations. Users can create exceptions for these known tools to prevent false alerts.
+- Custom scripts or administrative tasks that interact with the print spooler service or related files could inadvertently trigger the rule. Users should document and exclude these scripts if they are verified as non-threatening.
+- To manage false positives, users can implement a whitelist of known, legitimate processes or applications that are allowed to modify the `MPDW-constraints.js` file, ensuring that only unauthorized changes are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to confirm unauthorized modifications to the specified JavaScript files and identify any other compromised files or services.
+- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) related to CVE-2022-38028.
+- Revert any unauthorized changes to the JavaScript files by restoring them from a known good backup or reinstalling the affected components.
+- Apply the latest security patches and updates from Microsoft to address CVE-2022-38028 and other known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging and monitoring policies to capture detailed file access and modification events, focusing on critical system directories.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Strengthen system hardening measures by disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
index 1b27f5b2e7c..68c4e946e9f 100644
--- a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
+++ b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,48 @@ file where host.os.type == "windows" and event.type != "deletion" and event.acti
   ) and
   not process.executable : "C:\\Windows\\System32\\dfsrs.exe"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation or Modification of a new GPO Scheduled Task or Service
+
+Group Policy Objects (GPOs) are crucial for centralized management in Windows environments, allowing administrators to configure settings across domain-joined machines. Adversaries with domain admin rights can exploit GPOs to deploy malicious tasks or services, executing harmful payloads network-wide. The detection rule identifies suspicious changes to specific XML files associated with GPO tasks and services, excluding legitimate system processes, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific XML file involved, either "ScheduledTasks.xml" or "Services.xml", and note the file path to determine which GPO was modified.
+- Verify the timestamp of the event to establish when the modification occurred and correlate it with any known changes or maintenance activities.
+- Identify the user account associated with the modification event to determine if it was performed by a legitimate administrator or a potentially compromised account.
+- Check the process executable that triggered the event, ensuring it is not "C:\\\\Windows\\\\System32\\\\dfsrs.exe", which is excluded as a legitimate process.
+- Use Active Directory logs to trace any recent changes in domain admin group membership that might indicate unauthorized access.
+- Investigate the source host from which the modification was made to determine if it is a known administrative workstation or an unusual source.
+- Utilize Osquery to gather additional context on the host involved. For example, run the following query to list recent changes to scheduled tasks: `SELECT * FROM scheduled_tasks WHERE path LIKE '%\\\\SYSVOL\\\\domain\\\\Policies\\\\%\\\\MACHINE\\\\Preferences\\\\ScheduledTasks\\\\ScheduledTasks.xml';`
+- Examine recent network activity from the source host to identify any suspicious connections or data transfers that could indicate lateral movement or data exfiltration.
+- Review historical alerts and logs for any previous suspicious activity associated with the same user account or host to identify patterns or repeated attempts.
+- Consult with the IT team to confirm if the change was part of a planned update or deployment, and cross-reference with change management records for validation.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often create or modify GPO scheduled tasks or services for routine maintenance or updates. These actions can trigger the detection rule, leading to false positives.
+- Automated system management tools: Tools like Microsoft System Center Configuration Manager (SCCM) or other third-party management solutions may modify GPO tasks or services as part of their normal operation, which can be mistaken for malicious activity.
+- Software updates and patches: Some software updates or patches may alter GPO scheduled tasks or services, causing the rule to flag these legitimate changes.
+- To manage false positives, users can create exceptions for known legitimate processes or tools by adding them to the exclusion list in the detection rule. This can be done by identifying the process executable paths or specific file changes that are known to be safe and adding them to the 'not process.executable' or 'not file.name' conditions in the query.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further spread of potential malicious tasks or services.
+- Conduct a thorough investigation to identify the source of the GPO modification, focusing on recent changes and the accounts used to make these changes.
+- Review and verify the legitimacy of the scheduled tasks and services created or modified in the GPO, comparing them against known baselines.
+- Revoke domain admin privileges from any accounts that are not actively required for administrative tasks to limit potential misuse.
+- Restore any unauthorized changes to the GPO by reverting to a known good configuration or using backups.
+- Implement enhanced logging and monitoring for GPO changes, ensuring that all modifications are tracked and alerts are generated for suspicious activities.
+- Integrate security information and event management (SIEM) systems to correlate events and provide a comprehensive view of potential threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent future occurrences.
+- Apply hardening measures such as enforcing the principle of least privilege, using multi-factor authentication, and regularly auditing privileged accounts to reduce the risk of similar attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
index c2ba7fc2038..9ddbe7bf7b2 100644
--- a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
+++ b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,49 @@ sequence by winlog.computer_name with maxspan=5m
    /* event 4697 need to be logged */
    event.action : "service-installed"] by winlog.event_data.SubjectLogonId
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Service Creation via Local Kerberos Authentication
+
+Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. In a Windows environment, it is often used for authenticating domain users. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating unauthorized services. The detection rule identifies suspicious local logins using Kerberos, followed by service creation, indicating possible misuse of Kerberos for privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a successful local logon event (event ID 4624) with the Logon Package set to "Kerberos" and the source IP address within the loopback range (127.0.0.0/8 or ::1).
+- Verify the timestamp and LogonId of the suspicious logon event to ensure it aligns with the subsequent service creation event (event ID 4697).
+- Check the winlog.computer_name field to identify the affected host and determine if it is a domain-joined machine.
+- Investigate the winlog.event_data.TargetLogonId and winlog.event_data.SubjectLogonId fields to confirm that the same LogonId is used in both the logon and service creation events, indicating a potential Kerberos relay attack.
+- Use Osquery to list all services created or modified recently on the affected host with the following query: `SELECT name, path, start_type, status FROM services WHERE timestamp >= (SELECT MAX(timestamp) FROM services) - 300;`
+- Examine the source.port field in the logon event to identify any unusual or high-numbered ports that might indicate non-standard communication.
+- Correlate the alert with other security events or logs from the same timeframe to identify any additional suspicious activities or anomalies on the host.
+- Check for any known vulnerabilities or misconfigurations in the Kerberos setup on the affected host that could have been exploited.
+- Review user account activity associated with the logon event to determine if the account has been involved in any other suspicious activities or if it has been compromised.
+- Consult threat intelligence sources to identify if there are any known Kerberos relay attack variants or indicators of compromise that match the observed behavior.
+
+### False positive analysis
+
+- Scheduled tasks or legitimate software updates may trigger local Kerberos authentication followed by service creation, as these processes often use network logon types and may appear similar to malicious activity.
+- System administrators performing routine maintenance or deploying new services might inadvertently match the detection criteria, especially if they use scripts or tools that authenticate locally.
+- Security software or monitoring tools that perform regular checks or updates could also generate events that resemble the described pattern, leading to false positives.
+- To manage these false positives, users can create exceptions for known and trusted processes or accounts that frequently trigger the rule, ensuring that these are well-documented and regularly reviewed to maintain security integrity.
+- Implementing a whitelist of approved service creation activities or specific logon IDs associated with legitimate administrative tasks can help reduce noise and focus on truly suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the presence of a Kerberos relay attack by reviewing relevant logs, including event IDs 4624 and 4697, and correlating them with the suspicious activity.
+- Identify and terminate any unauthorized services created during the attack to prevent further exploitation.
+- Reset passwords for affected accounts and consider implementing multi-factor authentication to enhance security.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the attack.
+- Restore the system to its operational state by removing any malicious software and ensuring all security patches and updates are applied.
+- Implement enhanced logging policies to capture detailed authentication and service creation events, ensuring that event IDs 4624 and 4697 are consistently logged.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities for similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Apply hardening measures such as disabling unused services, enforcing least privilege access, and regularly auditing user permissions to reduce the risk of future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_lsa_auth_package.toml b/rules/windows/privilege_escalation_lsa_auth_package.toml
index 73c5572df3c..eed25abfc5a 100644
--- a/rules/windows/privilege_escalation_lsa_auth_package.toml
+++ b/rules/windows/privilege_escalation_lsa_auth_package.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,49 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* exclude SYSTEM SID - look for changes by non-SYSTEM user */
   not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential LSA Authentication Package Abuse
+
+The Local Security Authority (LSA) in Windows manages authentication and security policies. Adversaries may exploit LSA by modifying registry paths to load malicious binaries during system authentication, gaining elevated privileges or persistence. The detection rule identifies unauthorized registry changes to LSA authentication packages by non-SYSTEM users, signaling potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path involved is "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\Authentication Packages" or "\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\Authentication Packages".
+- Verify the user ID associated with the registry change to ensure it is not "S-1-5-18" (SYSTEM), indicating a non-SYSTEM user made the change.
+- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other suspicious activities.
+- Investigate the user account that made the change to assess if it has a history of unusual behavior or if it has been compromised.
+- Use Osquery to list all current LSA authentication packages by running: `SELECT name, data FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Lsa\\\\Authentication Packages';` to identify any unauthorized binaries.
+- Examine the binary referenced in the registry change for known malicious signatures or unusual characteristics using a threat intelligence platform or antivirus tools.
+- Review system logs around the time of the registry change for any related events, such as process creation logs, to identify potential execution of the malicious binary.
+- Check for any recent privilege escalation attempts or successful escalations on the host to determine if the registry change was part of a broader attack.
+- Investigate network activity from the host around the time of the registry change to identify any suspicious outbound connections or data exfiltration attempts.
+- Consult with other security tools or logs, such as endpoint detection and response (EDR) solutions, to gather additional context and corroborate findings related to the suspicious registry change.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the LSA authentication packages registry path, leading to false positives. Users should verify if the change coincides with a known software update or installation.
+- Security software or system management tools might alter the registry path as part of their normal operations. Users can create exceptions for these trusted applications by identifying their specific user IDs or process names.
+- System administrators performing maintenance or configuration changes might trigger the rule. To manage this, users can exclude specific administrator accounts or scheduled maintenance windows from the detection rule.
+- In environments with custom authentication solutions, legitimate changes to the LSA authentication packages might occur. Users should document these solutions and adjust the rule to exclude known benign modifications.
+- Regular audits and baselining of the registry path can help identify expected changes, allowing users to refine the detection rule to focus on truly anomalous activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify any unauthorized registry changes and determine the scope of the compromise, focusing on the LSA authentication packages registry path.
+- Review recent user activity and system logs to identify the non-SYSTEM user responsible for the registry modification and assess their access level and actions.
+- Remove any unauthorized binaries referenced in the LSA authentication packages registry path to prevent malicious execution during system authentication.
+- Restore the registry to its previous state using backups or system restore points, ensuring that only legitimate authentication packages are loaded.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed registry changes and user activities, ensuring that future unauthorized modifications are detected promptly.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Conduct a security review of user permissions and access controls, ensuring that only authorized personnel have the ability to modify critical registry paths.
+- Apply system hardening measures, such as enabling Windows Defender Credential Guard, to protect LSA processes and prevent unauthorized access to sensitive authentication data."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_make_token_local.toml b/rules/windows/privilege_escalation_make_token_local.toml
index 087a566beff..992e9bfc506 100644
--- a/rules/windows/privilege_escalation_make_token_local.toml
+++ b/rules/windows/privilege_escalation_make_token_local.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,49 @@ authentication where
              "?:\\Windows\\System32\\inetsrv\\w3wp.exe", 
              "?:\\Windows\\SysWOW64\\msiexec.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Interactive Logon by an Unusual Process
+
+Interactive logons in Windows environments typically involve processes like winlogon.exe, which handle user authentication. Adversaries may exploit this by using alternate processes to create tokens, escalating privileges and bypassing controls. The detection rule identifies anomalies by flagging logons initiated by unexpected processes, especially those not originating from standard system directories, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process executable path that triggered the alert, ensuring it matches the criteria of being outside standard system directories.
+- Verify the legitimacy of the process executable by checking its digital signature and comparing it against known good hashes or software inventories.
+- Examine the `winlog.event_data.LogonProcessName` field to determine if the process name "Advapi*" is expected or if it indicates potential misuse.
+- Investigate the `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetUserSid` fields to identify the user accounts involved in the logon attempt and assess if they are legitimate or potentially compromised.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE path = 'C:\\\\path\\\\to\\\\suspicious\\\\executable.exe';` to retrieve details like process start time, parent process, and command-line arguments.
+- Check the system's security and application logs for any related events around the time of the alert to identify any preceding or subsequent suspicious activities.
+- Investigate the host's network connections during the time of the alert to identify any unusual outbound or inbound connections that could indicate lateral movement or data exfiltration.
+- Analyze the process tree to understand the parent-child relationship of the suspicious process and identify any other processes that may have been spawned as part of the activity.
+- Review recent changes to the system, such as software installations or updates, that could explain the presence of the unusual process.
+- Consult threat intelligence sources to determine if the process or behavior matches any known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that initiate logons from non-standard directories may trigger this rule. Users should review the source and purpose of these tools to determine if they are authorized.
+- Custom applications or services that require interactive logons and are installed in non-standard directories can also be flagged. Users can create exceptions for these applications by adding their executable paths to the exclusion list.
+- Automated processes or scheduled tasks that perform logons for maintenance or updates might be misidentified. Users should verify these tasks and, if legitimate, exclude their associated processes.
+- Developers or IT personnel using remote desktop or other remote management tools from non-standard locations may cause false positives. Users should ensure these activities are documented and consider excluding known safe processes.
+- To manage false positives, users can refine the detection rule by adding specific process paths or user SIDs to the exclusion criteria, ensuring that only unexpected or unauthorized activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the unusual process and determine if it is malicious or unauthorized, using endpoint detection and response (EDR) tools.
+- Review recent changes to user accounts and permissions to identify any unauthorized privilege escalations or account creations.
+- Terminate any suspicious processes and remove any unauthorized accounts or permissions identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation confirms malicious activity or if the scope of the incident is unclear.
+- Implement enhanced logging policies to capture detailed authentication and process execution events, ensuring logs are stored securely for future analysis.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are compliant with organizational policies.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as enforcing least privilege access, using multi-factor authentication, and regularly auditing user accounts and permissions to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
index 61ad9c71af4..62bce7ccc9b 100644
--- a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
+++ b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel", "m365_defender", "window
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,52 @@ process where event.type == "start" and host.os.type == "windows" and
                         "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and
  process.parent.command_line : "*go.microsoft.com*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Escalation via Vulnerable MSI Repair
+
+Windows Installer (MSI) is a service used for the installation, maintenance, and removal of software. Adversaries may exploit vulnerabilities in MSI repair processes to gain elevated privileges. This detection rule identifies suspicious activity by monitoring browser processes that access Microsoft Help pages and subsequently initiate elevated processes, indicating potential exploitation attempts for privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a browser process accessing Microsoft Help pages, as indicated by the `process.parent.command_line` field containing "*go.microsoft.com*".
+- Verify the parent process name using the `process.parent.name` field to ensure it matches one of the specified browsers (e.g., "chrome.exe", "msedge.exe", etc.).
+- Check the user domain in the `user.domain` field to confirm if the process is running under a system account like "NT AUTHORITY", which may indicate an attempt to gain elevated privileges.
+- Investigate the child process that was spawned by the browser to determine if it is an elevated process, using the `process` field to identify the process name and command line.
+- Correlate the timing of the browser navigation to the Microsoft Help page with the start time of the elevated process to assess if they are closely linked.
+- Use Osquery to gather additional context on the processes involved. For example, run the following Osquery query to list processes with elevated privileges:
+  ```sql
+  SELECT pid, name, path, cmdline, uid, gid FROM processes WHERE uid = 0;
+  ```
+- Examine the system's event logs for any additional indicators of privilege escalation attempts or anomalies around the time of the alert.
+- Investigate any recent software installations or updates that might have triggered the MSI repair process, potentially leading to the exploitation attempt.
+- Check for any known vulnerabilities or patches related to Windows Installer that might be relevant to the alert.
+- Gather information on the network activity of the involved processes to identify any suspicious outbound connections or data exfiltration attempts.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger this rule if they involve accessing Microsoft Help pages and subsequently launching elevated processes. Users should verify if the process is part of a known update or installation routine.
+- Automated scripts or system management tools that access Microsoft Help pages for documentation or troubleshooting purposes might also cause false positives. Users can create exceptions for these tools by identifying their specific command lines or process names.
+- Browsers with extensions or plugins that automatically navigate to Microsoft Help pages for support or information gathering could be flagged. Users should review the extensions in use and whitelist trusted ones.
+- IT support activities where technicians access Microsoft Help pages to assist users and then perform administrative tasks might be misidentified. Organizations can exclude known IT support tools or processes from triggering the rule.
+- Users can manage false positives by maintaining a list of known safe processes and command lines that frequently interact with Microsoft Help pages and ensuring these are excluded from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Conduct a thorough investigation to confirm the exploitation by reviewing logs and identifying any unauthorized elevated processes initiated by browser activity.
+- Terminate any suspicious elevated processes that were spawned following the browser's access to Microsoft Help pages.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Apply the latest security patches and updates to the Windows Installer service to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar exploitation attempts.
+- Restore the system to its operational state by verifying the integrity of system files and reinstalling any compromised software.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege principles, and conducting regular security audits to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
index 77e4e70c55a..eda15a8dbfc 100644
--- a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
+++ b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -28,6 +28,49 @@ type = "new_terms"
 query = '''
 event.category:"authentication" and host.os.type:"windows" and winlog.logon.type:"NewCredentials" and winlog.event_data.LogonProcessName:(Advapi* or "Advapi  ") and not winlog.event_data.SubjectUserName:*$ and not process.executable :???\\Program?Files*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Time Seen NewCredentials Logon Process
+
+The NewCredentials logon type in Windows allows a user to create a new security context using different credentials without logging off. Adversaries exploit this by forging access tokens to escalate privileges or bypass controls. The detection rule identifies unusual processes initiating such logons, excluding known system paths, to flag potential misuse indicative of token manipulation tactics.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process triggered the NewCredentials logon type and note the `process.executable` path for further analysis.
+- Verify the `winlog.event_data.SubjectUserName` to identify the user account involved and check if it aligns with expected behavior or known user activity.
+- Investigate the `winlog.event_data.LogonProcessName` to confirm if it is indeed an unusual process initiating the logon, focusing on processes like "Advapi" that are commonly used in token manipulation.
+- Cross-reference the `host.os.type` to ensure the alert pertains to a Windows system, as this context is crucial for understanding the environment.
+- Use Osquery to gather more information about the suspicious process. For example, run the query: `SELECT * FROM processes WHERE path = '<process.executable path>'` to gather details such as process start time, parent process, and command line arguments.
+- Check the event logs for any preceding or subsequent suspicious activities related to the same `SubjectUserName` or `process.executable` to identify potential patterns or additional indicators of compromise.
+- Investigate the system's recent authentication logs to identify any other unusual logon types or failed logon attempts that might correlate with the alert.
+- Analyze network logs to determine if there was any unusual outbound or inbound traffic from the host around the time of the alert, which might indicate lateral movement or data exfiltration attempts.
+- Review any recent changes or updates to the system that might explain the new process behavior, such as software installations or configuration changes.
+- Consult threat intelligence sources to check if the `process.executable` or any related indicators have been associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Scheduled tasks or automated scripts that use the NewCredentials logon type for legitimate purposes may trigger false positives. These tasks often run under specific service accounts or known user accounts.
+- Administrative tools or software that require elevated privileges and use the NewCredentials logon type can also be flagged. These tools might be part of regular IT operations or maintenance activities.
+- Users can manage these false positives by creating exceptions for specific processes or user accounts that are known to perform legitimate NewCredentials logons. This can be done by adding these processes or accounts to an allowlist within the detection rule.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+- Consider monitoring the frequency and context of NewCredentials logons to distinguish between normal operational patterns and potential threats, adjusting the detection criteria as necessary.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Review the event logs to identify the source and scope of the NewCredentials logon activity, focusing on unusual processes and user accounts involved.
+- Terminate any suspicious processes identified during the investigation to halt potential malicious activity.
+- Change passwords for any compromised accounts and enforce multi-factor authentication to enhance security.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software.
+- Restore the system from a known good backup if malicious activity has compromised system integrity.
+- Implement enhanced logging policies to capture detailed authentication and process execution events for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response if necessary.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by adversaries."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
index a7cba94a807..6752731d19c 100644
--- a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
+++ b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,49 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* exclude SYSTEM SID - look for changes by non-SYSTEM user */
   not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Port Monitor or Print Processor Registration Abuse
+
+Port monitors and print processors are components in Windows that manage print jobs and data formatting. Adversaries exploit these by modifying registry paths to load malicious DLLs during system boot, gaining SYSTEM-level privileges. The detection rule identifies unauthorized registry changes to these paths, excluding those made by the SYSTEM user, to flag potential abuse for privilege escalation or persistence.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path that was modified, focusing on paths related to port monitors and print processors as specified in the query.
+- Verify the user account associated with the registry change by examining the `user.id` field to ensure it is not the SYSTEM user (S-1-5-18), which is excluded in the detection rule.
+- Check the timestamp of the registry modification event to determine when the change occurred and correlate it with other system activities or logs around the same time.
+- Investigate the DLL file specified in the `registry.data.strings` field to determine its legitimacy by checking its file path, digital signature, and any known associations with malicious activity.
+- Use Osquery to list all DLLs currently registered as port monitors or print processors with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Print\\\\Monitors\\\\%' OR path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Print\\\\Environments\\\\Windows%\\\\Print Processors\\\\%';`
+- Cross-reference the identified DLL with threat intelligence databases or malware repositories to check for any known indicators of compromise.
+- Analyze the system's event logs, particularly the Security and System logs, for any suspicious activities or anomalies around the time of the registry change.
+- Investigate the system's startup programs and services to identify any unauthorized or unusual entries that could indicate persistence mechanisms.
+- Conduct a historical review of similar registry changes on the affected host to determine if this is an isolated incident or part of a recurring pattern.
+- If possible, perform a memory analysis on the affected system to detect any in-memory threats or anomalies associated with the suspicious DLL.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify print processor or port monitor registry paths, leading to false positives. Users should verify if the changes coincide with known software updates or installations.
+- Printer driver updates or installations can also trigger this rule. Users should check if the registry changes align with recent printer-related activities.
+- Some enterprise environments may have custom print solutions that modify these registry paths as part of their normal operation. Users can create exceptions for these known applications by identifying their specific user IDs or paths.
+- System administrators performing maintenance or configuration changes might inadvertently cause registry modifications. Users should ensure that such activities are documented and can be correlated with the detected changes.
+- To manage false positives, users can implement exceptions by excluding specific user IDs, paths, or known benign DLLs from the detection rule, ensuring that these exceptions are regularly reviewed and updated as necessary.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Verify the unauthorized registry changes by comparing with a known good baseline and identify the malicious DLLs involved.
+- Terminate any suspicious processes associated with the malicious DLLs to prevent further execution.
+- Remove or revert the unauthorized registry changes to their original state to disable the persistence mechanism.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
+- Review user accounts and permissions to ensure that only authorized users have the necessary privileges to modify critical registry paths.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to monitor registry changes and DLL loads, ensuring that logs are forwarded to a centralized logging solution for analysis.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) for improved detection and response.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege principles, to reduce the attack surface and prevent similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
index c27dff3ffb8..8f00c7b892e 100644
--- a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
+++ b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,52 @@ sequence by host.id with maxspan=30s
     ) and
  registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4\\*"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Print Spooler Point and Print DLL
+
+The Windows Print Spooler service manages print jobs and related tasks, often requiring elevated privileges. Adversaries exploit vulnerabilities like CVE-2020-1030 to load malicious DLLs, gaining SYSTEM-level access. The detection rule identifies registry changes linked to unauthorized DLL loading paths, signaling potential exploitation attempts by monitoring specific registry keys and values associated with the print spooler.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry paths involved, specifically checking for changes in `HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\SpoolDirectory` and `HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\CopyFiles\\Payload\\Module`.
+- Verify the `registry.data.strings` value to ensure it matches the suspicious path `C:\\Windows\\System32\\spool\\drivers\\x64\\4` or any subdirectory, indicating potential unauthorized DLL loading.
+- Cross-reference the host.id from the alert with recent logs to identify any other suspicious activities or anomalies on the same host.
+- Use Osquery to list all DLLs currently loaded by the print spooler process to identify any unexpected or unauthorized modules:
+  ```sql
+  SELECT pid, name, path FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE name LIKE '%spoolsv%';
+  ```
+- Investigate the process tree for the print spooler service to identify any unusual parent or child processes that could indicate exploitation.
+- Check for any recent privilege escalation attempts or successful escalations on the host by reviewing security event logs, particularly those related to user privilege changes.
+- Analyze network traffic logs from the host around the time of the alert to detect any outbound connections that could suggest data exfiltration or command and control activity.
+- Review recent changes to the system, including software installations or updates, that could have introduced vulnerabilities or been exploited.
+- Examine the timeline of registry changes to determine if they coincide with known attack patterns or other suspicious activities.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors currently exploiting CVE-2020-1030, which could provide additional context or indicators of compromise.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the registry paths monitored by the rule, leading to false positives. Users should verify if any authorized software changes align with the detected activity.
+- Printer driver updates or installations can trigger the rule due to legitimate changes in the spool directory or module paths. Users should cross-reference the timing of these updates with the alerts to determine if they are benign.
+- Network administrators performing routine maintenance or configuration changes on print servers might inadvertently cause registry modifications that match the rule's criteria. Users should document and exclude these known maintenance windows to reduce false positives.
+- To manage false positives, users can create exceptions for specific registry paths or values that are known to be safe and frequently modified by trusted processes. This can be done by updating the detection rule to exclude these paths or by using a security information and event management (SIEM) system to filter out non-threatening alerts.
+- Regularly review and update the list of exceptions to ensure that only verified and non-malicious activities are excluded, maintaining the balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to confirm the presence of unauthorized DLLs and identify any other compromised systems by reviewing registry changes and system logs.
+- Remove any unauthorized DLLs and restore legitimate DLLs from a known good backup or installation media.
+- Apply the latest security patches and updates from Microsoft to address CVE-2020-1030 and other known vulnerabilities.
+- Reset all credentials and passwords for accounts that have been accessed or could potentially be compromised, especially those with elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging and monitoring policies to capture detailed information on registry changes, DLL loads, and print spooler activities for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide real-time alerts on suspicious activities.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, ensuring no backdoors or persistence mechanisms remain.
+- Harden the system by disabling unnecessary services, enforcing least privilege principles, and regularly reviewing and updating security configurations to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
index f43288f064e..ab507a91f1d 100644
--- a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
+++ b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,48 @@ query = '''
 event.category : "file" and host.os.type : "windows" and event.type : "creation" and
   process.name : "spoolsv.exe" and file.extension : "dll"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious PrintSpooler Service Executable File Creation
+
+The Print Spooler service manages print jobs in Windows environments, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies suspicious DLL file creation by monitoring file events linked to the spooler process, helping to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the suspicious DLL file creation event, focusing on the `event.category`, `host.os.type`, `event.type`, `process.name`, and `file.extension` fields.
+- Verify the file path and name of the created DLL to determine if it matches known malicious patterns or if it is located in an unusual directory.
+- Check the timestamp of the DLL creation event to correlate it with other suspicious activities or known attack timelines.
+- Investigate the parent process of `spoolsv.exe` to identify any unusual or unauthorized processes that may have initiated the DLL creation.
+- Use Osquery to list all DLL files in the spooler directory and their creation times with a query like: `SELECT path, ctime FROM file WHERE directory = 'C:\\\\Windows\\\\System32\\\\spool\\\\drivers\\\\' AND extension = 'dll';`
+- Examine recent login events and user activities around the time of the DLL creation to identify any unauthorized access or privilege escalation attempts.
+- Analyze network traffic logs for any unusual outbound connections from the host around the time of the event, which may indicate data exfiltration or command and control communication.
+- Check for any recent patches or updates applied to the system to ensure that vulnerabilities like CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 have been addressed.
+- Review security logs for any other alerts or anomalies related to the Print Spooler service or the affected host to build a comprehensive picture of the incident.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns targeting the Print Spooler service.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve creating DLL files through the Print Spooler service. Users should verify the source and context of the file creation to determine if it is part of a trusted update or installation process.
+- Some printer drivers or management software might create DLL files as part of their normal operation. Users can create exceptions for specific file paths or hashes associated with known and trusted printer software to reduce false positives.
+- In environments with custom scripts or administrative tools that interact with the Print Spooler service, these might inadvertently trigger the rule. Users should review and whitelist these scripts or tools if they are verified to be safe and necessary for operations.
+- To manage false positives, users can implement a monitoring period to identify patterns of benign activity and adjust the detection rule to exclude these patterns, ensuring that only truly suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Conduct a thorough investigation to confirm the presence of malicious DLL files and identify any other compromised components.
+- Utilize endpoint detection and response (EDR) tools to analyze the spoolsv.exe process and associated file creation events for further indicators of compromise.
+- Apply the latest security patches for the Print Spooler service, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to mitigate known vulnerabilities.
+- Remove any unauthorized or suspicious DLL files and restore legitimate versions from a trusted backup or installation media.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed file creation events and process activities related to the Print Spooler service for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats proactively.
+- Restore the system to its operational state by verifying the integrity of critical system files and ensuring all security patches are applied.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly reviewing security configurations to reduce the attack surface."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
index 65e8bd0d499..9cb198cb66c 100644
--- a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
+++ b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,49 @@ file where host.os.type == "windows" and event.type == "deletion" and
   file.extension : "dll" and file.path : "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.dll" and
   not process.name : ("spoolsv.exe", "dllhost.exe", "explorer.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Print Spooler File Deletion
+
+The Print Spooler service manages print jobs in Windows environments, crucial for handling print requests. Adversaries exploit vulnerabilities in this service to escalate privileges, often deleting driver files to cover tracks post-exploitation. The detection rule identifies unusual deletions of these files by monitoring for non-standard processes performing such actions, signaling potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path and extension match the suspicious criteria: `?:\\\\Windows\\\\System32\\\\spool\\\\drivers\\\\x64\\\\3\\\\*.dll`.
+- Identify the process responsible for the deletion by examining the `process.name` field and verify it is not one of the expected processes: `spoolsv.exe`, `dllhost.exe`, or `explorer.exe`.
+- Check the `host.os.type` to ensure the event occurred on a Windows system, as the rule is specific to Windows environments.
+- Investigate the parent process of the suspicious process to understand the context of how it was initiated.
+- Use Osquery to gather more information about the suspicious process. Example query: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';`.
+- Examine recent login events on the affected host to identify any unusual or unauthorized access patterns around the time of the file deletion.
+- Review the system's event logs for any related security events or anomalies that coincide with the time of the file deletion.
+- Check for any recent changes or updates to the Print Spooler service or related drivers that could explain the file deletion.
+- Investigate network activity from the affected host to identify any suspicious outbound connections or data exfiltration attempts.
+- Correlate the event with other alerts or incidents in the environment to determine if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks or software updates may trigger the deletion of print driver files by legitimate processes not included in the exclusion list, such as custom scripts or third-party management tools.
+- Security software or system optimization tools might delete or modify these files as part of their regular operations, leading to false positives.
+- Users can manage these false positives by identifying and documenting legitimate processes that interact with print driver files and adding them to the exclusion list in the detection rule.
+- Regularly review and update the exclusion list to include any new legitimate processes that are introduced into the environment, ensuring that only non-threatening behaviors are excluded.
+- Collaborate with IT and security teams to understand the context of each alert, verifying whether the process involved is part of a known and safe operation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the process responsible for the deletion, using endpoint detection and response (EDR) tools to trace the process lineage and gather forensic evidence.
+- Verify the integrity of the Print Spooler service and associated files by comparing them against known good baselines or using file integrity monitoring tools.
+- Restore any deleted or altered print driver files from a trusted backup to ensure the Print Spooler service can function correctly.
+- Apply the latest security patches and updates to the Windows operating system and specifically to the Print Spooler service to mitigate known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of privilege escalation or further compromise.
+- Implement enhanced logging and monitoring for the Print Spooler service and related processes to detect future anomalies, ensuring logs are sent to a centralized logging solution for analysis.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) to enhance detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly, focusing on improving detection and response times.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing application whitelisting to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
index fb45da30925..73a812de142 100644
--- a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
+++ b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -87,6 +87,49 @@ registry where host.os.type == "windows" and event.type == "change" and process.
         )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privilege Escalation via Service ImagePath Modification
+
+Windows services run with elevated privileges, often as SYSTEM, making them targets for privilege escalation. Adversaries may modify the ImagePath registry key of a service to execute malicious code with these privileges. The detection rule identifies changes to the ImagePath of critical services, excluding legitimate paths, to spot unauthorized modifications indicative of an attack.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific service whose ImagePath registry key was modified, using the `registry.key` field from the query.
+- Check the `process.executable` field to determine which process was responsible for the registry modification, and verify if it is a known legitimate process or potentially malicious.
+- Investigate the `registry.data.strings` field to see the new value of the ImagePath and assess if it points to a suspicious or unauthorized executable.
+- Use Osquery to list all services and their ImagePaths on the affected host to identify any other unusual modifications. Example query: `SELECT name, path FROM services WHERE path NOT LIKE 'C:\\\\Windows\\\\system32\\\\%';`
+- Cross-reference the modified ImagePath with known malicious file hashes or paths using threat intelligence sources.
+- Examine the event logs on the affected host for any additional context around the time of the modification, focusing on user activity and other system changes.
+- Check for any recent logins or privilege escalations on the host that could indicate how the attacker gained the necessary permissions to modify the registry.
+- Investigate the user account associated with the modification event to determine if it has been compromised or if it has legitimate reasons for making such changes.
+- Look for any other alerts or anomalies on the same host or network segment that might correlate with the suspicious activity, indicating a broader attack.
+- Review historical data to see if similar modifications have occurred in the past, which could suggest a recurring issue or persistent threat actor.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify the ImagePath of services, triggering the rule. Users can handle these by verifying the source and purpose of the change and adding exceptions for trusted software vendors.
+- System administrators may intentionally modify service configurations for maintenance or optimization purposes. To manage this, document and approve such changes through a change management process and exclude these specific modifications from the rule.
+- Some security tools or monitoring solutions might alter service paths as part of their operation. Identify these tools and create exceptions for their known behaviors to prevent false alerts.
+- Custom scripts or automation tasks that modify service configurations for legitimate reasons can also trigger the rule. Review these scripts, ensure they are secure, and exclude their actions from the detection rule.
+- In environments with frequent legitimate service modifications, consider implementing a baseline of expected service configurations and use it to differentiate between authorized and unauthorized changes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the modification, including reviewing recent user activity and process execution logs.
+- Verify the integrity of the modified service by comparing its current ImagePath with a known good configuration or baseline.
+- Restore the ImagePath registry key to its original, legitimate value using a backup or by manually correcting it.
+- Scan the system for additional signs of compromise, such as unauthorized user accounts or scheduled tasks, using endpoint detection and response (EDR) tools.
+- Escalate the incident to the security operations center (SOC) or incident response team if the modification is part of a broader attack campaign.
+- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
+- Apply system hardening measures, such as restricting service modification permissions to only trusted administrators and enabling Windows Defender Application Control (WDAC) to prevent unauthorized executables.
+- Conduct a post-incident review to identify gaps in detection and response capabilities and update security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
index c87668f25ff..3e093e74b5f 100644
--- a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
+++ b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,49 @@ registry.path : (
     ) and
  not registry.data.strings : ("C:\\windows", "%SystemRoot%")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privilege Escalation via Windir Environment Variable
+
+The Windir environment variable in Windows specifies the directory where system files reside. Adversaries may manipulate this variable to redirect processes to malicious directories, thereby gaining elevated privileges. The detection rule identifies changes to this variable in user registry paths, flagging deviations from expected values like "C:\\windows" to detect potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the registry path and value that triggered the alert, focusing on the `registry.path` and `registry.data.strings` fields to identify deviations from expected values like "C:\\windows" or "%SystemRoot%".
+- Check the user account associated with the registry change by examining the `HKEY_USERS` or `HKCU` path to determine if the change was made under a specific user profile.
+- Investigate recent login activity for the user account identified in the previous step to determine if there were any unusual or unauthorized access attempts.
+- Use Osquery to list all environment variables for the affected user to identify any other suspicious modifications. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_USERS\\\\%\\\\Environment\\\\%' OR path LIKE 'HKCU\\\\%\\\\Environment\\\\%';`
+- Examine the process creation logs around the time of the registry change to identify any suspicious processes that might have been executed with elevated privileges.
+- Correlate the registry change event with any recent software installations or updates that might have altered environment variables, checking for legitimate changes.
+- Search for any other registry changes made by the same user or process to identify patterns or additional indicators of compromise.
+- Review system and security event logs for any anomalies or errors that coincide with the time of the registry change, which might provide additional context or evidence of exploitation.
+- Investigate network activity from the affected host to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
+- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with privilege escalation or other malicious activities.
+
+### False positive analysis
+
+- Changes to the Windir environment variable may occur during legitimate software installations or updates, where applications temporarily modify environment variables to point to custom directories. Users should verify if the change coincides with a known software update or installation.
+- Some enterprise environments may have custom scripts or administrative tools that modify the Windir variable for specific operational needs. Users should document and whitelist these known scripts or tools to prevent false positives.
+- Virtual environments or sandboxed applications might alter the Windir variable to redirect system calls within the virtualized context. Users should identify and exclude these environments from triggering alerts.
+- In development environments, developers might intentionally change the Windir variable for testing purposes. Users should establish a policy to track and approve such changes, allowing exceptions for known development activities.
+- To manage false positives, users can create exceptions in the detection rule for specific user accounts or systems where these changes are expected and verified as non-malicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized changes to the Windir environment variable and determine the source of the modification.
+- Review system logs and security events to identify any additional indicators of compromise or related suspicious activities.
+- Restore the Windir environment variable to its default value, typically "C:\\windows", and verify the integrity of system files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to monitor changes to critical environment variables and registry paths, ensuring that all modifications are logged and reviewed.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
+- Apply security patches and updates to address any vulnerabilities that may have been exploited in conjunction with the Windir manipulation.
+- Educate users and administrators on the risks associated with environment variable manipulation and provide training on recognizing potential security threats.
+- Consider implementing application whitelisting and endpoint protection solutions to prevent unauthorized changes to system configurations and environment variables."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
index 74ffe84b293..5cf5047467b 100644
--- a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
+++ b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/12"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,52 @@ iam where event.action == "renamed-user-account" and
   /* machine account name renamed to user like account name */
   winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Privileged Escalation via SamAccountName Spoofing
+
+In Active Directory environments, the `samAccountName` attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to rename computer accounts, mimicking domain controllers and gaining elevated privileges. The detection rule identifies suspicious renaming events where a machine account is altered to resemble a user account, signaling potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a `renamed-user-account` event action, focusing on the `winlog.event_data.OldTargetUserName` and `winlog.event_data.NewTargetUserName` fields to verify if a machine account was renamed to resemble a user account.
+- Cross-reference the `OldTargetUserName` and `NewTargetUserName` with known domain controller and user account naming conventions to identify any anomalies or patterns that suggest spoofing.
+- Check the event timestamp to determine when the renaming occurred and correlate it with other security events or logs around the same time for additional context.
+- Investigate the source of the renaming event by identifying the user or process that initiated the change, using the `winlog.event_data.SubjectUserName` and `winlog.event_data.SubjectUserSid` fields.
+- Utilize Osquery to gather more information about the system where the renaming event originated. For example, run the following Osquery query to list recent account changes on the system:
+  ```sql
+  SELECT * FROM users WHERE last_change > (SELECT MAX(last_change) - 86400 FROM users);
+  ```
+- Examine the system logs and security logs on the originating machine for any signs of unauthorized access or suspicious activity leading up to the renaming event.
+- Check for any recent changes in group memberships, especially those involving privileged groups like Domain Admins, to identify potential privilege escalation.
+- Analyze network traffic logs to detect any unusual communication patterns between the affected machine and other domain controllers or critical servers.
+- Review any recent patches or updates applied to the system to ensure that CVE-2021-42278 and related vulnerabilities have been addressed.
+- Consult with other security team members or stakeholders to gather additional insights or context that may aid in understanding the scope and impact of the potential privilege escalation attempt.
+
+### False positive analysis
+
+- Routine administrative tasks: In some environments, IT administrators may regularly rename computer accounts as part of maintenance or reorganization efforts. These legitimate activities can trigger the detection rule, leading to false positives. To manage this, create exceptions for known administrative actions by excluding specific administrator accounts or scheduled maintenance periods from the rule.
+- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage Active Directory accounts, which might include renaming operations. These can be mistaken for malicious activity. Identify and exclude these scripts or tools by their unique identifiers or execution context to reduce false positives.
+- Migrations or upgrades: During system migrations or software upgrades, bulk renaming of accounts might occur, which can be flagged by the rule. To handle this, temporarily disable the rule during planned migrations or add exceptions for the duration of the upgrade process.
+- Testing environments: In test or development environments, frequent renaming of accounts for testing purposes can trigger alerts. Consider excluding these environments from the rule or setting up a separate monitoring policy that accounts for the higher volume of changes.
+- Known service accounts: Some service accounts may have legitimate reasons to change their names, such as aligning with new naming conventions. Document these accounts and create exceptions to prevent them from being flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the exploitation of CVE-2021-42278 by reviewing logs and identifying any unauthorized changes to the samAccountName attribute.
+- Revert any unauthorized changes to the samAccountName attribute to restore the original state of the affected accounts.
+- Reset passwords for any accounts that were potentially compromised during the incident to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the breach.
+- Implement enhanced logging policies to capture detailed events related to account management and privilege escalation attempts for future investigations.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze security events across the network for improved threat detection.
+- Apply security patches and updates to all systems to mitigate known vulnerabilities, including CVE-2021-42278, and prevent similar attacks.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate and train IT staff and users on recognizing and responding to potential security threats, emphasizing the importance of maintaining strong security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
index 100d963e6e4..381165b6e37 100644
--- a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
+++ b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/11"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,50 @@ iam where event.action == "changed-computer-account" and user.id : ("S-1-5-21-*"
     /* exclude FPs where DnsHostName starts with the ComputerName that was changed */
     not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Remote Computer Account DnsHostName Update
+
+In Active Directory environments, the DnsHostName attribute is crucial for identifying and locating computers within the network. Adversaries may exploit this by altering a computer account's DnsHostName to mimic a domain controller, potentially leveraging vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, while filtering out false positives.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific computer account and the new DnsHostName value that triggered the alert.
+- Verify if the new DnsHostName matches any known domain controller DNS hostnames within the network to assess the likelihood of malicious intent.
+- Check the user.id field to determine which user account initiated the change and assess if this account has a history of similar activities or elevated privileges.
+- Investigate the winlog.event_data.TargetUserName to confirm the original computer account name and compare it with the new DnsHostName for any suspicious similarities.
+- Use Osquery to gather additional context on the affected computer account by running a query such as: `SELECT * FROM users WHERE uid = '<user_id_from_alert>';` to retrieve user details and recent activities.
+- Examine recent login events and changes associated with the user.id to identify any unusual patterns or unauthorized access attempts.
+- Cross-reference the event.action field with other logs to determine if there are additional changes or anomalies related to the same computer account or user.
+- Analyze network traffic logs to detect any unusual communication patterns from the affected computer account, especially towards domain controllers.
+- Consult Active Directory logs to verify if there are any other recent changes to the DnsHostName attribute across different computer accounts that might indicate a broader attack.
+- Collaborate with IT and security teams to gather insights on any recent network changes or incidents that could provide context to the alert.
+
+### False positive analysis
+
+- False positives may occur when legitimate administrative tasks involve updating the DnsHostName attribute of computer accounts, especially during network reconfigurations or migrations.
+- Routine maintenance activities by IT staff, such as renaming computers or updating DNS records, can trigger the detection rule if the new hostname coincidentally resembles a domain controller's.
+- Automated scripts or tools used for bulk updates to computer accounts might inadvertently match the detection criteria, especially in large environments with frequent changes.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific time windows when legitimate changes are expected.
+- Implementing a whitelist of authorized scripts or tools that perform bulk updates can help reduce unnecessary alerts.
+- Regularly review and update the detection rule's filters to align with the organization's operational patterns and reduce noise from expected activities.
+
+### Response and remediation
+
+- Immediately isolate the affected computer from the network to prevent further unauthorized access or potential lateral movement.
+- Verify the legitimacy of the DnsHostName change by cross-referencing with recent administrative activities and change management records.
+- Conduct a thorough investigation to determine if CVE-2022-26923 or any other vulnerabilities were exploited, using endpoint detection and response (EDR) tools to gather forensic evidence.
+- Revert the DnsHostName to its original value if the change is confirmed to be unauthorized, and ensure that the computer account is not impersonating a domain controller.
+- Reset passwords for any accounts that may have been compromised during the incident, focusing on privileged accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed events related to Active Directory changes, including DnsHostName updates, and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify critical attributes like DnsHostName.
+- Conduct a post-incident review to identify gaps in security controls and processes, and apply lessons learned to improve future incident response efforts.
+- Apply hardening measures such as patching known vulnerabilities, enforcing least privilege principles, and conducting regular security audits to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
index b661cf23c54..e1c202781c5 100644
--- a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
+++ b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -70,6 +70,52 @@ any where host.os.type == "windows" and event.provider: "Microsoft-Windows-Secur
           "?:\\Windows\\System32\\wbem\\WmiPrvSe.exe",
           "?:\\Windows\\SysWOW64\\wbem\\WmiPrvSe.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 SeDebugPrivilege Enabled by a Suspicious Process
+
+SeDebugPrivilege allows processes to debug and modify other processes, a capability often reserved for system-level tasks. Adversaries exploit this by creating processes with elevated privileges to bypass security controls. The detection rule identifies suspicious processes enabling SeDebugPrivilege by filtering out legitimate system processes and focusing on unusual privilege escalations, helping analysts spot potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process triggered the SeDebugPrivilege and note the timestamp, process name, and user context.
+- Verify the `winlog.event_data.SubjectUserSid` to determine the user account associated with the suspicious process and check if it deviates from expected system accounts.
+- Examine the `winlog.event_data.ProcessName` to identify the executable path and assess if it matches any known legitimate applications or if it appears unusual.
+- Cross-reference the process name and path against the exclusion list in the detection rule to confirm it is not a false positive from a known system process.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list processes with SeDebugPrivilege:
+  ```sql
+  SELECT pid, name, path, uid, gid, on_disk FROM processes WHERE name = '<suspicious_process_name>';
+  ```
+- Investigate the parent process of the suspicious process to understand the process lineage and identify any potential anomalies in process creation.
+- Check for any recent changes in user privileges or group memberships that might explain the unexpected privilege escalation.
+- Analyze the system's security logs around the time of the alert for any other suspicious activities or related events that could provide additional context.
+- Review network activity logs to identify any unusual outbound connections or data transfers initiated by the suspicious process.
+- Consult threat intelligence sources to determine if the process name or behavior is associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate administrative tools: Some legitimate administrative tools and processes, such as certain system maintenance or monitoring applications, may require SeDebugPrivilege to function correctly. These tools might trigger the detection rule if they are not included in the exclusion list. Users can handle these by identifying and adding these tools to the exclusion list based on their file paths or process names.
+- Software updates and installations: During software updates or installations, processes like msiexec.exe may temporarily enable SeDebugPrivilege. These processes are typically benign and can be excluded by ensuring their paths are included in the exclusion list.
+- System maintenance tasks: Scheduled tasks or system maintenance activities, such as those performed by cleanmgr.exe or MRT.exe, might also enable SeDebugPrivilege. Users should verify the legitimacy of these tasks and exclude them if they are part of routine system operations.
+- Custom scripts or applications: In environments where custom scripts or applications are used for system management, these might require elevated privileges. Users should review these scripts or applications and, if deemed safe, add them to the exclusion list to prevent false positives.
+- Security software: Some security software may use SeDebugPrivilege to perform deep system scans or other protective measures. Users should confirm the legitimacy of such software and exclude it from the detection rule if necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Investigate the process that enabled SeDebugPrivilege by reviewing logs and identifying the parent process and any associated files or network connections.
+- Terminate any suspicious processes that have been identified as enabling SeDebugPrivilege without legitimate justification.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and analyze security logs to determine if there are any other systems that may have been compromised or are exhibiting similar suspicious behavior.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process creation and privilege escalation events for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
+- Restore the system to its operational state by applying the latest security patches, updating software, and ensuring all security configurations are hardened.
+- Educate users and administrators on the importance of maintaining least privilege principles and regularly reviewing privilege assignments to prevent unauthorized privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
index fc2f865bcc9..895078f3548 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/28"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,48 @@ process where host.os.type == "windows" and event.type == "start" and process.na
   /* CLSID of the Elevated COM Interface IEditionUpgradeManager */
   process.parent.args : "/Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface
+
+User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. The IEditionUpgradeManager COM interface can be exploited by attackers to bypass UAC, allowing them to execute code with elevated privileges without user consent. This detection rule identifies such attempts by monitoring for the execution of the ClipUp program from non-standard paths, initiated by a specific COM interface process, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the ClipUp.exe process execution from a non-standard path, as indicated by the process.executable field.
+- Verify the parent process information to ensure it matches dllhost.exe, and check the process.parent.args for the specific CLSID {BD54C901-076B-434E-B6C7-17C531F4AB41} to confirm the use of the IEditionUpgradeManager COM interface.
+- Use Osquery to list all running processes and identify any suspicious processes that may have been spawned by ClipUp.exe. Example query: `SELECT pid, name, path, parent FROM processes WHERE name = 'Clipup.exe';`
+- Investigate the origin of the ClipUp.exe file by checking its file properties, such as creation date and digital signature, to determine if it is a legitimate or potentially malicious file.
+- Examine the system's event logs, particularly the Security and Application logs, for any related events around the time of the alert to gather additional context on the activity.
+- Check for any recent changes in user account privileges or group memberships that could indicate an attempt to escalate privileges.
+- Investigate any network connections initiated by ClipUp.exe or its parent process to identify potential command and control communication or data exfiltration.
+- Review the system's scheduled tasks and startup items to identify any persistence mechanisms that may have been established by the attacker.
+- Analyze any recent software installations or updates that could have introduced the rogue ClipUp.exe file, focusing on software installed around the time of the alert.
+- Correlate this alert with other security alerts or incidents in the environment to determine if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger this detection if they use the ClipUp program from non-standard paths as part of their process. Users should verify the source and purpose of such installations to determine if they are benign.
+- System administrators or IT personnel might use scripts or tools that inadvertently mimic the behavior of a UAC bypass attempt. In such cases, ensure these activities are documented and authorized.
+- Some enterprise environments may have custom applications that utilize the ClipUp program for legitimate purposes. These should be reviewed and, if deemed safe, added to an exception list to prevent false alarms.
+- To manage false positives, users can create exceptions in their monitoring tools for known safe processes or paths that frequently trigger this rule. This can be done by specifying trusted parent processes or executable paths in the detection rule configuration.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing logs and identifying any unauthorized changes or suspicious activities.
+- Terminate any malicious processes associated with the ClipUp program running from non-standard paths.
+- Remove any unauthorized or malicious files and restore any altered system files from a known good backup.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced logging policies to capture detailed process execution and COM interface usage, ensuring future attempts are detected promptly.
+- Integrate security information and event management (SIEM) solutions to correlate events and provide comprehensive threat visibility.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for UAC bypass.
+- Educate users on the importance of UAC prompts and encourage reporting of any unexpected or suspicious prompts.
+- Review and update security policies and hardening measures, such as restricting COM interface access and enforcing least privilege principles, to prevent similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
index 216891dbd73..20a5a5ec323 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,51 @@ process where host.os.type == "windows" and event.type == "start" and
  /* uncomment once in winlogbeat */
  /* and not (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) */
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer
+
+User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. Adversaries exploit elevated COM interfaces, like the Internet Explorer Add-On Installer, to bypass UAC and execute malicious code with higher privileges. The detection rule identifies such attempts by monitoring specific process behaviors, such as the execution of temporary files with a parent process linked to the installer, indicating potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a process execution event where the executable path matches the pattern `C:\\\\*\\\\AppData\\\\*\\\\Temp\\\\IDC*.tmp\\\\*.exe` and the parent process is `ieinstal.exe` with arguments `-Embedding`.
+- Verify the legitimacy of the parent process `ieinstal.exe` by checking its file path and hash against known good values or threat intelligence databases.
+- Investigate the process tree to understand the sequence of events leading to the execution of the suspicious temporary executable. Look for any unusual parent or sibling processes.
+- Examine the command-line arguments of the parent process `ieinstal.exe` to identify any anomalies or unexpected parameters that could indicate malicious intent.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command-line arguments:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE 'C:\\\\%\\\\AppData\\\\%\\\\Temp\\\\IDC%.tmp\\\\%.exe';
+  ```
+- Check the code signature of the suspicious executable and its parent process to determine if they are signed by a trusted entity. If the signature is missing or untrusted, it may indicate malicious activity.
+- Investigate the network activity associated with the suspicious process to identify any external connections or data exfiltration attempts. Use network logs or tools like Wireshark for deeper analysis.
+- Review recent system changes or user activities that might have led to the execution of the suspicious process, such as software installations or updates.
+- Correlate the alert with other security events or logs from the same host or user account to identify any patterns or additional indicators of compromise.
+- Consult with threat intelligence sources or community forums to determine if the observed behavior matches any known UAC bypass techniques or malware campaigns.
+
+### False positive analysis
+
+- Legitimate software installations or updates that use the Internet Explorer Add-On Installer may trigger this detection rule, as they can create temporary executable files in the specified directory. Users should verify the legitimacy of the software being installed or updated to determine if it is a false positive.
+- System administrators may encounter false positives when deploying software through automated scripts or management tools that utilize the same COM interface for legitimate purposes. In such cases, adding exceptions for known and trusted software deployment tools can help reduce noise.
+- Some enterprise environments may have custom applications that interact with the Internet Explorer Add-On Installer for legitimate reasons. Identifying these applications and excluding their specific process signatures can prevent unnecessary alerts.
+- To manage false positives, users can create exceptions by adding specific process paths or signatures to an allowlist, ensuring that only verified and trusted processes are excluded from detection. This approach helps maintain security while reducing false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing the process execution details and correlating with other security logs.
+- Terminate any suspicious processes identified during the investigation, particularly those matching the pattern of temporary files executed with "ieinstal.exe" as the parent process.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Remove any unauthorized or malicious software identified during the investigation and ensure the system is free from malware.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of system files.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate security solutions such as endpoint detection and response (EDR) tools to improve visibility and detection capabilities.
+- Educate users on the risks of UAC bypass techniques and encourage reporting of any suspicious activity.
+- Review and update security policies and hardening measures, such as restricting the use of elevated COM interfaces and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
index 1f75e4522af..323b94b0b42 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,48 @@ process where host.os.type == "windows" and event.type == "start" and
  process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and
  process.pe.original_file_name != "WerFault.exe"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 UAC Bypass via ICMLuaUtil Elevated COM Interface
+
+The ICMLuaUtil Elevated COM Interface is a component in Windows that facilitates certain processes to run with elevated privileges, bypassing User Account Control (UAC) prompts. Adversaries exploit this by invoking specific COM objects to execute code stealthily with higher permissions. The detection rule identifies such bypass attempts by monitoring processes initiated by `dllhost.exe` with specific arguments, excluding legitimate system processes, to flag potential privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the specific `dllhost.exe` process with the arguments `/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}` or `/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}` to ensure it matches the UAC bypass signature.
+- Check the process tree to identify the parent process of `dllhost.exe` to understand the origin of the execution and determine if it is a legitimate system process or a suspicious one.
+- Investigate the user account under which the `dllhost.exe` process was executed to determine if it aligns with expected user behavior or if it indicates potential compromise.
+- Use Osquery to gather additional context about the `dllhost.exe` process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'dllhost.exe';`
+- Examine the command-line arguments of the `dllhost.exe` process to identify any unusual or unexpected parameters that could indicate malicious activity.
+- Cross-reference the `process.pe.original_file_name` field to ensure it is not `WerFault.exe`, which is excluded from the detection rule, to validate the alert.
+- Analyze recent system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that could be related to the UAC bypass attempt.
+- Check for any recent changes or installations on the system that could have introduced the potential for UAC bypass, such as new software or updates.
+- Investigate network activity from the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
+- Review historical alerts and incidents involving the same host or user account to identify patterns or repeated attempts of privilege escalation or other suspicious activities.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the detection rule as they sometimes use the ICMLuaUtil Elevated COM Interface for necessary elevated operations. Users should verify the source and purpose of the process to determine if it is benign.
+- System maintenance tools or scripts that require elevated permissions might also be flagged. Users can create exceptions for these tools by adding them to an allowlist based on their file hash or specific command-line arguments.
+- Certain administrative tasks performed by IT personnel, such as system configuration changes, may inadvertently match the detection criteria. Organizations can manage these by documenting and excluding known administrative activities from the rule.
+- Automated system processes that are part of the operating system's normal functioning could occasionally be misidentified. Users should monitor these processes and, if consistently identified as false positives, adjust the detection rule to exclude them by specifying additional conditions or exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing logs and correlating with other security events.
+- Terminate any suspicious processes initiated by dllhost.exe that match the identified arguments to stop potential malicious activity.
+- Escalate the incident to the security operations team for a deeper analysis and to determine if other systems are affected.
+- Review and enhance logging policies to ensure comprehensive monitoring of COM object invocations and UAC bypass attempts.
+- Implement additional security controls, such as application whitelisting, to prevent unauthorized execution of elevated processes.
+- Restore the system to its operational state by removing any malicious code or unauthorized changes and applying necessary security patches.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on the risks of UAC bypass techniques and the importance of adhering to security best practices.
+- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
index b967a003284..c2802e39231 100644
--- a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,6 +60,49 @@ process where host.os.type == "windows" and event.type == "start" and
         "\\Device\\HarddiskVolume?\\Windows\\System32\\taskhostw.exe"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 UAC Bypass via DiskCleanup Scheduled Task Hijack
+
+User Account Control (UAC) is a security feature in Windows that helps prevent unauthorized changes by prompting for permission or an administrator password. Adversaries may exploit scheduled tasks like DiskCleanup to bypass UAC, executing code with elevated privileges. The detection rule identifies suspicious processes using specific arguments and executables, excluding legitimate system paths, to flag potential UAC bypass attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious process arguments `/autoclean` and `/d` in conjunction with the process start event.
+- Verify the executable path of the process to ensure it does not match any of the legitimate system paths listed in the detection rule.
+- Check the parent process of the suspicious executable to understand how it was initiated and assess if it aligns with expected behavior.
+- Investigate the user account under which the suspicious process was executed to determine if it has administrative privileges or a history of unusual activity.
+- Use Osquery to list all scheduled tasks on the system and identify any modifications or unusual entries related to DiskCleanup. Example query: `SELECT * FROM scheduled_tasks WHERE name LIKE '%DiskCleanup%';`
+- Examine the system's event logs, particularly the Security and System logs, for any related entries that might provide additional context or corroborate the suspicious activity.
+- Analyze the file hash of the suspicious executable using threat intelligence sources to determine if it is associated with known malicious activity.
+- Investigate any network connections initiated by the suspicious process to identify potential command and control communication or data exfiltration.
+- Review recent changes to the system, such as software installations or updates, that might explain the presence of the suspicious executable.
+- Correlate the findings with other alerts or incidents in the environment to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate software updates or maintenance tools may trigger the detection rule if they use similar command-line arguments and executables not listed in the exclusion paths. Users should verify the source and purpose of such processes to determine if they are benign.
+- Custom scripts or administrative tools developed in-house that automate disk cleanup tasks might also be flagged. Users can manage these by adding the specific executable paths of trusted scripts to the exclusion list.
+- Scheduled tasks created by IT departments for routine maintenance that mimic the DiskCleanup process could be misidentified. To handle this, users should document and exclude these known tasks from the detection rule.
+- Security software or system optimization tools that perform disk cleanup operations might inadvertently match the rule's criteria. Users should confirm the legitimacy of these tools and consider excluding their executables if they are verified as safe.
+- In environments with non-standard system configurations, legitimate system processes might reside in different paths. Users should adjust the exclusion list to accommodate these variations by adding the correct paths for their specific setup.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify any unauthorized changes or additional malicious activities on the system, focusing on processes and scheduled tasks.
+- Terminate any suspicious processes identified during the investigation that are not part of legitimate system operations.
+- Review and restore any altered scheduled tasks to their default configurations, ensuring no unauthorized tasks remain.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and scheduled task changes, aiding in future detection and investigation efforts.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze potential threats in real-time.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for UAC bypass.
+- Educate users on the importance of UAC prompts and the risks associated with bypassing them, reinforcing security awareness.
+- Consider deploying application whitelisting and endpoint detection and response (EDR) solutions to prevent unauthorized code execution and improve threat visibility."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
index 8e26acb0697..4832780b218 100644
--- a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/27"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,50 @@ file where host.os.type == "windows" and event.type : "change" and process.name
   /* has no impact on rule logic just to avoid OS install related FPs */
   not file.path : ("C:\\Windows\\SoftwareDistribution\\*", "C:\\Windows\\WinSxS\\*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 UAC Bypass Attempt via Privileged IFileOperation COM Interface
+
+The IFileOperation COM interface is a Windows component that facilitates file operations with elevated privileges. Adversaries exploit this by side-loading malicious DLLs into processes like dllhost.exe, which run with high integrity levels, to bypass User Account Control (UAC). The detection rule identifies such attempts by monitoring changes in specific DLLs known for side-loading, excluding benign paths to reduce false positives.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a UAC bypass attempt by checking if the process name is "dllhost.exe" and the file name matches any of the known side-loaded modules such as "wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", or "Accessibility.ni.dll".
+- Verify the file path to ensure it does not match benign paths like "C:\\\\Windows\\\\SoftwareDistribution\\\\*" or "C:\\\\Windows\\\\WinSxS\\\\*" to rule out false positives related to OS installations.
+- Use process monitoring tools to trace the parent process of "dllhost.exe" to identify how it was initiated and whether it was spawned by a legitimate process or a suspicious one.
+- Check the integrity level of the "dllhost.exe" process to confirm it is running with high or system integrity, which is necessary for a successful UAC bypass.
+- Investigate recent file modifications or creations in the directories where the suspicious DLLs were detected to identify any unauthorized changes or additions.
+- Utilize Osquery to gather more context about the system state and running processes. For example, run the following Osquery query to list all processes with high integrity levels: `SELECT pid, name, path, uid, gid FROM processes WHERE integrity_level = 'high';`
+- Examine the system's event logs, particularly the Security and Application logs, for any unusual activity or errors around the time the alert was triggered.
+- Check for any network connections initiated by "dllhost.exe" to external IP addresses, which could indicate data exfiltration or command and control communication.
+- Review the system's scheduled tasks and startup items to identify any persistent mechanisms that could be used to reinitiate the UAC bypass.
+- Correlate the findings with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate software updates or installations that modify DLLs in monitored paths, such as Windows updates or third-party software installations.
+- System maintenance tasks, like disk cleanup or system restore operations, might also trigger alerts due to changes in DLLs, especially in directories like `C:\\Windows\\SoftwareDistribution\\` or `C:\\Windows\\WinSxS\\`.
+- To manage these false positives, users can create exceptions for specific file paths or processes known to perform legitimate operations, ensuring these are well-documented and reviewed regularly.
+- Implementing a whitelist for trusted software that frequently updates or modifies DLLs can help reduce unnecessary alerts while maintaining security.
+- Regularly updating the detection rule to include new benign paths or processes identified during routine monitoring can further minimize false positives.
+- Users should ensure that any exclusions do not inadvertently allow malicious activity by carefully analyzing the context and behavior of the processes involved.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing security logs and identifying any unauthorized changes or suspicious activities associated with the identified DLLs.
+- Terminate any suspicious processes, particularly those involving dllhost.exe with the identified side-loaded DLLs, to stop the execution of potentially malicious code.
+- Remove any unauthorized or malicious DLLs from the system and restore legitimate versions from a trusted source or backup.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed file and process activity, focusing on high-integrity processes and known side-loading DLLs.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar UAC bypass attempts in the future.
+- Review and update user account control (UAC) settings and policies to ensure they are configured to the highest security level appropriate for the environment.
+- Conduct a security audit of the system to identify and address any other vulnerabilities or misconfigurations that could be exploited for privilege escalation.
+- Educate users and administrators on the risks of UAC bypass techniques and the importance of maintaining secure configurations and practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unquoted_service_path.toml b/rules/windows/privilege_escalation_unquoted_service_path.toml
index a5d975e7816..3efe2d4556b 100644
--- a/rules/windows/privilege_escalation_unquoted_service_path.toml
+++ b/rules/windows/privilege_escalation_unquoted_service_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/13"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,49 @@ process where host.os.type == "windows" and event.type == "start" and
     process.executable regex """(C:\\Program Files \(x86\)\\|C:\\Program Files\\)\w+.exe"""
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Exploitation of an Unquoted Service Path Vulnerability
+
+Unquoted service paths in Windows can be exploited by adversaries to gain elevated privileges. When a service path lacks quotes and contains spaces, Windows may execute a malicious executable placed in a higher-level directory. The detection rule identifies suspicious process executions by monitoring for executables named "Program.exe" or those in common program directories, indicating potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific executable path that triggered the alert, focusing on the `process.executable` field.
+- Verify the existence of the suspicious executable (e.g., "Program.exe") in the specified directory by manually navigating to the path on the affected host.
+- Use Osquery to list all services with unquoted paths on the host to identify potential vulnerabilities. Example query: `SELECT name, path FROM services WHERE path LIKE '% %' AND path NOT LIKE '"%"';`
+- Check the file creation and modification timestamps of the suspicious executable to determine when it was placed in the directory.
+- Investigate the parent process of the suspicious executable using the `process.parent` field to understand how it was initiated.
+- Examine the user account context under which the suspicious process was executed to assess potential privilege escalation.
+- Review recent system logs and security events around the time of the alert for any anomalous activities or related events.
+- Conduct a file integrity check on the directory containing the suspicious executable to identify any unauthorized changes.
+- Analyze network connections initiated by the suspicious process to detect any potential communication with external hosts.
+- Cross-reference the alert with other security tools and logs to gather additional context and corroborate findings.
+
+### False positive analysis
+
+- Known false positives may include legitimate applications that are poorly configured with unquoted service paths but do not pose a security threat. These applications might inadvertently trigger the detection rule due to their executable names or locations.
+- System administrators can handle these false positives by creating exceptions for specific executables that are known to be safe. This can be done by adding these executables to an allowlist or by modifying the detection rule to exclude certain paths or executable names.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening applications are excluded, maintaining a balance between security and operational efficiency.
+- Consider monitoring the behavior of excluded applications to ensure they do not exhibit any unexpected or malicious activity over time, as threat landscapes can change.
+- Engage with application vendors to address unquoted service path issues in their software, reducing the potential for false positives and improving overall security posture.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Conduct a thorough investigation to identify any malicious executables named "Program.exe" or located in common program directories, as indicated by the detection rule.
+- Review the service paths of all services on the affected system to identify any unquoted paths and correct them by adding quotes around the executable paths.
+- Remove any unauthorized or malicious executables found during the investigation to prevent further execution.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all services have correctly quoted paths.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update security policies and procedures accordingly.
+- Educate users and administrators on the importance of secure service configurations and the risks associated with unquoted service paths to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
index 99d0b03ae20..2ac94219cc2 100644
--- a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
+++ b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,52 @@ process where host.os.type == "windows" and event.type == "start" and
     "?:\\Program Files (x86)\\GPLGS\\gswin32c.exe"
  )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Print Spooler Child Process
+
+The Print Spooler service, integral to Windows environments, manages print jobs by interacting with printer hardware. Adversaries exploit this service to escalate privileges, leveraging vulnerabilities to execute unauthorized processes. The detection rule identifies anomalies by monitoring child processes spawned by the spooler, excluding known benign activities, and focusing on those with elevated integrity levels, signaling potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific child process of `spoolsv.exe` was flagged, focusing on the `process.name` and `process.command_line` fields.
+- Verify the integrity level of the process using the `process.Ext.token.integrity_level_name` or `winlog.event_data.IntegrityLevel` fields to confirm if it is running with elevated privileges.
+- Cross-reference the `process.name` and `process.command_line` against known benign processes and command lines to rule out false positives.
+- Check the parent process details to ensure that `spoolsv.exe` is the legitimate parent and not a masqueraded process.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all child processes of `spoolsv.exe`:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'spoolsv.exe');
+  ```
+- Investigate the file path and hash of the executable using the `process.executable` field to determine if it matches known malicious files or has been altered.
+- Examine the system's event logs around the time of the alert for any related suspicious activities or anomalies.
+- Check for any recent changes or installations on the system that could have introduced the unusual process, focusing on software updates or new applications.
+- Review network activity from the host to identify any unusual outbound connections that might indicate data exfiltration or command and control communication.
+- Consult threat intelligence sources to see if the process or command line has been associated with known attack patterns or campaigns.
+
+### False positive analysis
+
+- Known false positives include legitimate processes that are commonly spawned by the Print Spooler service but are not associated with malicious activity. These include processes like "splwow64.exe", "PDFCreator.exe", "acrodist.exe", "spoolsv.exe", "msiexec.exe", "route.exe", and "WerFault.exe".
+- Exclusions are in place for command lines that involve typical system paths or operations, such as those involving the Windows system drivers directory or common network and system configuration commands.
+- Users can manage false positives by adding exceptions for specific processes or command lines that are known to be safe in their environment. This can be done by modifying the detection rule to include additional exclusions based on observed benign behavior.
+- It is important to regularly review and update the list of exclusions to ensure that new legitimate processes are not mistakenly flagged as threats, especially after system updates or changes in the environment.
+- Users should also consider the context of the detected process, such as the time of execution and the user account under which it was run, to better assess whether it is likely to be a false positive.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the unusual child processes spawned by spoolsv.exe.
+- Review system logs and security events to gather evidence and understand the attack vector, leveraging MITRE ATT&CK framework details for T1068 to identify exploitation patterns.
+- Terminate any unauthorized or suspicious processes identified during the investigation to contain the threat.
+- Apply the latest security patches and updates to the Windows operating system and Print Spooler service to mitigate known vulnerabilities.
+- Restore the system from a clean backup if available, ensuring that the backup is free from compromise.
+- Implement enhanced logging policies to capture detailed process creation events and integrity level changes for future investigations.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to improve threat detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on secure printing practices and the importance of applying security updates promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
index 12e5a8b5448..010c24ed347 100644
--- a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
+++ b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,48 @@ process where host.os.type == "windows" and event.type == "start" and
     ) and process.parent.args : "imgsvc"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Service Host Child Process - Childless Service
+
+Service Host (svchost.exe) is a critical Windows process that hosts multiple services. Some services, known as "childless," typically do not spawn child processes. Adversaries may exploit this by injecting malicious code into these services to escalate privileges or evade detection. The detection rule identifies anomalies by monitoring for unexpected child processes from these "childless" services, flagging potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific child process and parent service involved, focusing on the `process.name` and `process.parent.args` fields.
+- Verify the legitimacy of the parent service by checking the `process.parent.args` against known childless services to confirm if the service should indeed be childless.
+- Examine the command-line arguments of the child process using the `process.args` field to identify any suspicious or unusual parameters that may indicate malicious activity.
+- Check the executable path of the child process using the `process.executable` field to determine if it resides in a legitimate directory, such as `?:\\Windows\\System32\\` or `?:\\Program Files\\`.
+- Investigate the process creation time and user context to determine if the process was created during unusual hours or by an unexpected user.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<child_process_name>';`.
+- Cross-reference the child process with known good or bad hashes using threat intelligence sources to determine if the executable is known to be malicious.
+- Analyze recent system logs and events around the time of the alert to identify any other suspicious activities or related events.
+- Check for any network connections initiated by the child process using network monitoring tools to identify potential C2 communication.
+- Review the system's security and application logs for any signs of exploitation or privilege escalation attempts that may correlate with the alert.
+
+### False positive analysis
+
+- **WerFault.exe, WerFaultSecure.exe, wermgr.exe**: These processes are related to Windows Error Reporting and may occasionally be spawned by svchost.exe during legitimate error handling scenarios. Users can exclude these processes from triggering alerts by adding them to the exception list.
+- **RelPost.exe with WdiSystemHost**: This executable may be launched by the WdiSystemHost service under certain conditions, such as system diagnostics or performance data collection. Users should monitor the context of these executions and consider excluding them if they are part of routine system operations.
+- **rundll32.exe with winethc.dll and WdiServiceHost**: This combination might occur during legitimate network configuration changes or diagnostics. Users can exclude this specific execution pattern if it is verified as part of normal system behavior.
+- **Executables under Program Files or Kodak directories with imgsvc**: These may be legitimate processes related to image processing or Kodak software operations. Users should verify the legitimacy of these processes and exclude them if they are consistently identified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation to identify the source of the unusual child process, focusing on recent changes or suspicious activities.
+- Utilize forensic tools to capture memory and disk images for deeper analysis of potential code injection or exploitation.
+- Terminate any suspicious processes identified as child processes of svchost.exe that are not typically expected.
+- Review and analyze security logs to trace the origin of the attack and identify any other potentially compromised systems.
+- Apply patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be remediated.
+- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as disabling unnecessary services and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_ppid_spoofing.toml b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
index 57c9603c900..2bb8025781e 100644
--- a/rules/windows/privilege_escalation_via_ppid_spoofing.toml
+++ b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,53 @@ process where host.os.type == "windows" and event.action == "start" and
     )
  )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privileges Elevation via Parent Process PID Spoofing
+
+Parent Process ID (PPID) spoofing is a technique where attackers manipulate the PPID of a process to disguise its origin, often to gain elevated privileges or evade detection. By altering the PPID, adversaries can make malicious processes appear as if they were spawned by legitimate, trusted processes. The detection rule identifies such spoofing by monitoring process creation events, specifically looking for anomalies in parent-child process relationships and excluding known legitimate processes and signatures to reduce false positives. This helps in identifying unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process triggered the rule, focusing on the `process.name`, `process.executable`, and `process.parent.executable` fields to identify the suspicious process and its parent.
+- Check the `process.parent.Ext.real.pid` field to verify if the parent process ID has been spoofed and assess the legitimacy of the parent process.
+- Investigate the `user.id` field to determine if the process is attempting to escalate privileges to SYSTEM, which could indicate malicious intent.
+- Examine the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to verify the authenticity of the process's digital signature and identify any discrepancies.
+- Cross-reference the `process.executable` and `process.parent.executable` paths against known legitimate software paths to rule out false positives.
+- Utilize Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and user IDs:
+  ```sql
+  SELECT pid, name, path, parent, uid FROM processes WHERE pid = <suspicious_process_pid>;
+  ```
+- Analyze historical process creation events to identify any patterns or anomalies in parent-child relationships that could suggest further spoofing attempts.
+- Investigate any network connections initiated by the suspicious process using network monitoring tools to identify potential command and control communication.
+- Review system logs for any other unusual activities or errors around the time the alert was triggered, which might provide additional context or evidence of compromise.
+- Consult threat intelligence sources to determine if the process or its parent is associated with known malware or attack campaigns, providing further insight into the potential threat.
+
+### False positive analysis
+
+- The rule may trigger false positives when legitimate processes are involved in activities that resemble PPID spoofing, such as software updates or system utilities that spawn processes with elevated privileges. 
+- Common false positives include processes related to Windows Error Reporting (WerFault.exe, Wermgr.exe) and Windows Update (MpSigStub.exe, wuauclt.exe) which are known to exhibit behavior similar to PPID spoofing during normal operations.
+- Third-party software like remote support tools (TeamViewer, LogMeIn) and accessibility utilities (Utilman.exe spawning osk.exe, Narrator.exe, Magnify.exe) can also generate false positives due to their legitimate use of elevated privileges.
+- To manage these false positives, users can create exceptions by excluding specific process paths or code signatures from the detection rule. This involves adding known legitimate processes and their parent-child relationships to the exclusion list.
+- Users should regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate software that may trigger the rule.
+- It is crucial to verify the trustworthiness of the code signatures associated with excluded processes to prevent adversaries from exploiting these exceptions.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the PPID spoofing, including reviewing process creation logs and correlating with known attack patterns.
+- Terminate any malicious processes identified during the investigation to stop ongoing threats.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if sensitive data may have been compromised.
+- Restore the system to a known good state using backups or system restore points, ensuring that all malicious changes are removed.
+- Implement enhanced logging policies to capture detailed process creation events and parent-child process relationships for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Review and update security policies and access controls to minimize the risk of privilege escalation through PPID spoofing.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users and administrators on recognizing signs of privilege escalation and the importance of reporting suspicious activities promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
index 05672066a7b..248d51aa7d6 100644
--- a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
+++ b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/13"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,52 @@ file where host.os.type == "windows" and event.action : "Pipe Created*" and
  /* normal sysmon named pipe creation events truncate the pipe keyword */
   file.name : "\\*\\Pipe\\*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Privilege Escalation via Rogue Named Pipe Impersonation
+
+Named pipes facilitate inter-process communication in Windows environments, allowing data exchange between processes. Adversaries exploit this by creating rogue named pipes, tricking privileged processes into connecting and escalating privileges. The detection rule identifies suspicious named pipe creation events, focusing on patterns indicative of impersonation attempts, thus flagging potential privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a named pipe creation event with the pattern "\\\\*\\\\Pipe\\\\*" on a Windows host, as indicated by the query.
+- Correlate the event with the specific host and timestamp to identify the process that created the named pipe. Check for any unusual or unauthorized processes running on the host.
+- Investigate the parent process of the named pipe creation event to determine if it is a legitimate process or potentially malicious. Use process lineage data to trace back the process tree.
+- Examine the user context under which the named pipe was created. Verify if the user has legitimate reasons to perform such actions or if there are signs of compromised credentials.
+- Utilize Osquery to gather additional context about the processes involved. For example, run the following Osquery query to list all named pipes and their associated processes:
+  ```sql
+  SELECT name, pid, path FROM pipes WHERE path LIKE '\\\\%\\\\Pipe\\\\%';
+  ```
+- Check for any recent privilege escalation attempts or access token manipulation activities on the host, as these may be related to the named pipe impersonation.
+- Analyze network activity from the host around the time of the event to identify any suspicious connections or data exfiltration attempts.
+- Review system logs and security events for any other indicators of compromise or related suspicious activities on the host.
+- Investigate any other alerts or anomalies associated with the same host or user account to determine if this is part of a broader attack campaign.
+- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the potential privilege escalation attempt.
+
+### False positive analysis
+
+- Legitimate software and system processes may create named pipes that match the detection pattern, leading to false positives. For example, certain enterprise applications or system management tools might use named pipes for legitimate inter-process communication.
+- Regularly occurring named pipe creation by trusted applications can be excluded by creating exceptions in the detection rule. This involves identifying the specific named pipes or processes that are known to be safe and adding them to an allowlist.
+- System administrators should monitor and document normal named pipe activity within their environment to distinguish between benign and suspicious behavior. This documentation can help refine detection rules and reduce false positives.
+- Consider the context of the named pipe creation event, such as the user account and process involved. If the event is associated with a known and trusted process, it may be safe to exclude it from alerts.
+- Implement a review process for flagged events to ensure that legitimate activities are not being incorrectly classified as threats, which can help in adjusting the detection parameters over time.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to identify the source of the rogue named pipe and determine if any other systems are compromised.
+- Terminate any suspicious processes associated with the rogue named pipe to stop ongoing malicious activities.
+- Review and analyze logs from Sysmon and other security tools to gather evidence and understand the scope of the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited.
+- Implement enhanced logging policies to capture detailed named pipe creation events and other relevant security events for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all malicious artifacts are removed.
+- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to prevent future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_token_theft.toml b/rules/windows/privilege_escalation_via_token_theft.toml
index 4e4c0049a82..f7d7f5de92f 100644
--- a/rules/windows/privilege_escalation_via_token_theft.toml
+++ b/rules/windows/privilege_escalation_via_token_theft.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -98,6 +98,53 @@ not (process.parent.executable : "?\\Windows\\System32\\spoolsv.exe" and
                  "Cisco WebEx LLC", 
                  "Dell Inc"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Created with an Elevated Token
+
+In Windows environments, processes can be created with elevated tokens to perform tasks requiring higher privileges. Adversaries exploit this by impersonating system-level processes to escalate privileges and bypass security controls. The detection rule identifies suspicious process creations by monitoring for processes running as SYSTEM, excluding known legitimate activities, and focusing on potential token theft scenarios. This helps in identifying unauthorized privilege escalations.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process was created with an elevated token, focusing on the `process.executable` and `process.parent.executable` fields.
+- Verify the `user.id` field to confirm the process is running as SYSTEM (S-1-5-18), indicating potential privilege escalation.
+- Examine the `process.Ext.effective_parent.executable` field to identify the parent process and determine if it is a known target for token theft.
+- Check the `process.code_signature.trusted` and `process.code_signature.subject_name` fields to assess if the process has a trusted signature, which might indicate a false positive.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with elevated tokens:
+  ```sql
+  SELECT pid, name, path, uid, gid, on_disk, wired_size FROM processes WHERE uid = 0;
+  ```
+- Investigate the command-line arguments of the process using the `process.parent.args` field to identify any unusual or suspicious parameters.
+- Correlate the process creation event with other logs, such as authentication logs, to identify any anomalous user activity around the time of the alert.
+- Check for any recent changes or updates in the system that might explain the process creation, focusing on the `process.parent.executable` paths.
+- Review historical data to determine if this process creation pattern has occurred previously and if it correlates with any known malicious activity.
+- Consult threat intelligence sources to see if the process or its parent is associated with known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Known false positives include processes initiated by legitimate system maintenance tasks or software updates that require elevated privileges, such as Windows Update processes or system diagnostics tools.
+- Processes related to Windows core binaries like `Utilman.exe` in debug mode or `spoolsv.exe` associated with Access Intelligent Form can trigger false positives.
+- Windows error reporting tools like `WerFault.exe` and `WerMgr.exe` may also be flagged, despite being legitimate.
+- Software installations or updates using `msiexec.exe` or processes under `DriverStore` can be mistakenly identified as threats.
+- Trusted applications with valid code signatures from known vendors such as TeamViewer, Cisco WebEx, or Dell may be incorrectly flagged.
+- Users can manage these false positives by creating exceptions for known legitimate processes and paths in their monitoring tools, ensuring that frequent non-threatening behaviors are excluded from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to confirm the legitimacy of the process creation and identify any unauthorized privilege escalation attempts.
+- Review system logs and security alerts to gather evidence of the attack vector and any associated malicious activities.
+- Terminate any suspicious processes running with elevated privileges that are not part of legitimate system operations.
+- Change all potentially compromised credentials, especially those with administrative privileges, to prevent further unauthorized access.
+- Restore the system from a known good backup if malicious activity is confirmed and the system integrity is compromised.
+- Implement enhanced logging policies to capture detailed process creation events and access token manipulations for future investigations.
+- Integrate security solutions with threat intelligence feeds to improve detection capabilities and correlate alerts with known threat actors.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Apply system hardening measures, such as enforcing least privilege access, enabling multi-factor authentication, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
index 758b1a47d47..0f0dfff831d 100644
--- a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
+++ b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/02/07"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,49 @@ configuration where host.os.type == "windows" and
     "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" "
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows Service Installed via an Unusual Client
+
+Windows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges, often from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations from atypical client processes, excluding known legitimate services, to spot potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand which client process triggered the service installation and note the `winlog.event_data.ClientProcessId` and `winlog.event_data.ParentProcessId` fields for further context.
+- Verify the legitimacy of the client process by checking its file path, hash, and digital signature to ensure it is not a known malicious or suspicious executable.
+- Use Osquery to list all services on the host and identify any newly created or modified services. Example query: `SELECT name, display_name, path, start_type, status FROM services WHERE path LIKE '%<suspicious_path>%';`
+- Investigate the parent process using the `winlog.event_data.ParentProcessId` to determine if it is a known legitimate process or if it has any suspicious characteristics.
+- Cross-reference the `winlog.event_data.ServiceFileName` with known legitimate service paths to ensure it is not a false positive.
+- Check the system's event logs for any additional activities around the time of the service installation, focusing on process creation, network connections, and user logins.
+- Analyze the timeline of events leading up to and following the service installation to identify any patterns or anomalies in user or process behavior.
+- Investigate the user account associated with the service installation to determine if it has been compromised or is exhibiting unusual activity.
+- Review any recent changes to the system's configuration or installed software that could explain the unusual service installation.
+- Consult threat intelligence sources to determine if the client process or service file name is associated with known malware or attack campaigns.
+
+### False positive analysis
+
+- Known false positives for this rule include legitimate software installations or updates that create services using atypical client processes. Examples include software deployment tools or system management utilities that may not follow standard service installation procedures.
+- Users can handle these false positives by creating exceptions for known legitimate services. This can be done by adding the specific service file paths or client process identifiers to the exclusion list within the detection rule.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate services that may trigger the rule.
+- Consider implementing a process to verify the legitimacy of flagged services by cross-referencing with software inventory or change management records to distinguish between benign and potentially malicious activities.
+- Engage with IT and security teams to identify any new software deployments or updates that could result in false positives, ensuring these are documented and accounted for in the rule configuration.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the service by checking the service name, file path, and associated process against known software and threat intelligence databases.
+- Terminate any suspicious processes associated with the unusual client process that installed the service.
+- Remove the malicious service and any associated files from the system to prevent re-execution.
+- Conduct a thorough investigation of the system to identify any additional indicators of compromise or persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process creation and service installation events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Harden the system by enforcing least privilege principles, disabling unnecessary services, and implementing application whitelisting to prevent unauthorized service installations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_wpad_exploitation.toml b/rules/windows/privilege_escalation_wpad_exploitation.toml
index 4ce6d2b03c5..b86f393f1d8 100644
--- a/rules/windows/privilege_escalation_wpad_exploitation.toml
+++ b/rules/windows/privilege_escalation_wpad_exploitation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "development"
-updated_date = "2024/04/08"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,49 @@ sequence with maxspan=5s
   [process where host.os.type == "windows" and event.type == "start" and
      process.parent.name : "svchost.exe"] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WPAD Service Exploit
+
+The Web Proxy Auto-Discovery Protocol (WPAD) helps devices on a network automatically find a proxy server. Adversaries can exploit WPAD by injecting malicious scripts into the service, potentially compromising systems. The detection rule identifies suspicious WPAD activity by monitoring specific processes and network behaviors, such as DNS queries and unauthorized script execution, to flag potential exploits.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the WPAD Service Exploit by checking the sequence of events, particularly focusing on the `process.entity_id` and `process.parent.entity_id` fields to trace the process lineage.
+- Examine the DNS queries for the "wpad" domain by analyzing the `dns.question.name` field to identify any unusual or unauthorized requests that could indicate malicious activity.
+- Investigate the network activity associated with `svchost.exe` by reviewing the `network.direction` and `destination.port` fields to ensure that the outgoing traffic on port 80 is legitimate and expected.
+- Check the execution of `jscript.dll` by `svchost.exe` using the `dll.name` field to determine if there is any unauthorized script execution that could be part of the exploit.
+- Use Osquery to gather additional context on the `svchost.exe` process. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE name = 'svchost.exe';` to verify the command line arguments and path for any anomalies.
+- Correlate the `user.domain` and `user.name` fields to ensure that the process is running under the expected user context, specifically "NT AUTHORITY\\LOCAL SERVICE", and investigate any deviations.
+- Analyze the parent-child process relationship using the `process.parent.name` field to identify any unusual process spawning from `svchost.exe` that could indicate exploitation.
+- Review historical logs for similar patterns of activity involving `svchost.exe` and `jscript.dll` to determine if this is an isolated incident or part of a broader attack pattern.
+- Investigate any other network connections initiated by `svchost.exe` around the time of the alert to identify potential command and control communication or data exfiltration attempts.
+- Cross-reference the alert with other security tools and logs to gather additional context and corroborate findings, focusing on any indicators of compromise related to privilege escalation or exploitation attempts.
+
+### False positive analysis
+
+- Legitimate network configurations may trigger the WPAD Service Exploit rule, such as environments where WPAD is used for legitimate proxy configuration. In such cases, frequent DNS queries for "wpad" and subsequent network activity may be normal and not indicative of an exploit.
+- Automated software updates or network management tools that utilize WPAD for configuration purposes can also generate similar patterns of activity, leading to false positives.
+- To manage these false positives, users can create exceptions for known benign processes or network behaviors by whitelisting specific DNS queries or network traffic patterns associated with trusted applications.
+- Monitoring and logging should be adjusted to differentiate between expected WPAD traffic and potentially malicious activity, ensuring that only suspicious deviations from the norm are flagged.
+- Regularly review and update the exclusion list to accommodate changes in network infrastructure or software updates that may alter legitimate WPAD usage patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
+- Conduct a thorough investigation to confirm the exploitation by reviewing DNS logs, network traffic, and process execution details related to WPAD activity.
+- Terminate any suspicious processes associated with svchost.exe that are not part of legitimate system operations.
+- Remove any unauthorized scripts or injected code found within the WPAD service or related processes.
+- Apply security patches and updates to the operating system and any vulnerable services to mitigate the exploitation risk.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging and monitoring for DNS queries, network traffic, and process execution to detect similar threats in the future.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore the system to its operational state by reinstalling affected services and verifying the integrity of system files.
+- Harden the network by disabling WPAD if not needed, enforcing strict access controls, and educating users on the risks associated with automatic proxy discovery."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_archive_data_zip_imageload.toml b/rules_building_block/collection_archive_data_zip_imageload.toml
index 445af055e36..fbca435582b 100644
--- a/rules_building_block/collection_archive_data_zip_imageload.toml
+++ b/rules_building_block/collection_archive_data_zip_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,52 @@ library where host.os.type == "windows" and event.action == "load" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Compression DLL Loaded by Unusual Process
+
+Compression DLLs, like those in the .NET framework, facilitate data compression and decompression, crucial for efficient storage and transfer. Adversaries exploit these DLLs to compress data before exfiltration, masking their activities. The detection rule identifies unusual processes loading these DLLs, excluding trusted applications, to flag potential misuse indicative of data exfiltration attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process that triggered the rule, focusing on the `process.executable` and `process.name` fields to understand which application attempted to load the compression DLL.
+- Verify the legitimacy of the process by checking the `process.code_signature.trusted` field. If the signature is not trusted, prioritize this alert for further investigation.
+- Investigate the user context under which the process was executed by examining the `user.id` field. Determine if the user is expected to run such processes and if their activity aligns with their role.
+- Cross-reference the process path with known trusted applications and environments. If the path is unusual or not listed in the exclusion criteria, it may warrant further scrutiny.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes that have loaded the specified DLLs:
+  ```sql
+  SELECT pid, name, path FROM processes WHERE path LIKE '%System.IO.Compression%';
+  ```
+- Check the process's parent process to understand the chain of execution. This can provide insights into whether the process was spawned by a legitimate application or a potentially malicious one.
+- Analyze recent file modifications and network connections initiated by the process to identify any suspicious data exfiltration activities.
+- Review system logs and other security tools for any correlated alerts or anomalies around the same timeframe to build a comprehensive picture of the event.
+- Investigate any recent changes or updates to the system that might explain the unusual process behavior, such as new software installations or updates.
+- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or DLLs in question, which could provide additional context for the alert.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate applications that are not included in the predefined exclusion list but still load compression DLLs as part of their normal operations. These could include custom or third-party applications that use .NET compression libraries for legitimate data processing tasks.
+- Users can handle these false positives by identifying and documenting the legitimate applications that trigger the rule. Once identified, these applications can be added to the exclusion list by specifying their executable paths and ensuring their code signatures are trusted.
+- Another potential false positive source is system maintenance or administrative scripts that utilize compression DLLs for routine data management tasks. Users should verify the legitimacy of these scripts and, if deemed safe, exclude them from the rule.
+- Regularly review and update the exclusion list to accommodate new trusted applications or changes in existing applications' behavior, ensuring that only genuine threats are flagged while minimizing false positives.
+- Consider the context of the flagged event, such as the user account involved and the process's typical behavior, to determine if the activity is expected or warrants further investigation.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration and lateral movement.
+- Conduct a thorough investigation to identify the source of the unusual process loading the compression DLL, focusing on recent changes or suspicious activities.
+- Review and analyze logs from the affected system and any associated network traffic to identify potential data exfiltration attempts.
+- Terminate any suspicious processes identified during the investigation that are not part of the trusted applications list.
+- Remove any unauthorized or malicious software discovered during the investigation and ensure all security patches are up to date.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure that all security controls are re-enabled.
+- Apply system hardening measures, such as restricting DLL loading paths and enforcing application whitelisting, to reduce the attack surface and prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_common_compressed_archived_file.toml b/rules_building_block/collection_common_compressed_archived_file.toml
index 8cbf9f55494..ff8372ed089 100644
--- a/rules_building_block/collection_common_compressed_archived_file.toml
+++ b/rules_building_block/collection_common_compressed_archived_file.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = "endpoint"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -110,6 +110,51 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
    )
  )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File Compressed or Archived into Common Format
+
+File compression and archiving are essential for efficient data storage and transfer, using formats like ZIP, RAR, and 7-Zip. However, adversaries exploit these technologies to obfuscate malicious files or stage data for exfiltration. The detection rule identifies suspicious compression activities by monitoring file creation or modification events, excluding trusted processes, and analyzing file headers for known compression signatures.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file and process involved, focusing on fields like `file.name`, `file.path`, and `process.name`.
+- Verify the legitimacy of the process by checking the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to ensure the process is signed and trusted.
+- Investigate the user context by examining the `user.id` field to determine if the activity was performed by a legitimate user or a system account.
+- Check the file header bytes (`file.Ext.header_bytes`) to confirm the type of compression or archive format used and cross-reference with known malicious signatures.
+- Use Osquery to gather additional context about the file and process. For example, run the following query to list recent file modifications by the process:
+  ```sql
+  SELECT path, size, atime, mtime FROM file WHERE path = 'C:\\\\Path\\\\To\\\\Suspicious\\\\File' OR path LIKE 'C:\\\\Path\\\\To\\\\Suspicious\\\\Directory\\\\%';
+  ```
+- Investigate the parent process of the suspicious activity by examining `process.parent.name` and `process.parent.executable` to understand the process lineage.
+- Analyze network activity associated with the process using network monitoring tools to identify any potential data exfiltration attempts.
+- Cross-reference the file path and process name with known indicators of compromise (IOCs) from threat intelligence sources.
+- Review system logs and security events around the time of the alert to identify any correlated suspicious activities or anomalies.
+- If applicable, check for any recent changes in the system or application configurations that might explain the compression activity, such as scheduled tasks or software updates.
+
+### False positive analysis
+
+- Trusted applications like Mozilla Firefox, Wazuh Agent, Microsoft Office Suite (Excel, Word, PowerPoint), OneDrive, Dropbox, Dell SupportAssist, and IIS may trigger false positives when they perform legitimate compression or archiving activities. These applications are often involved in routine operations that involve file compression, such as saving documents in compressed formats or creating temporary compressed files for performance optimization.
+- To manage these false positives, users can create exceptions for these trusted processes by verifying their code signatures and ensuring they are from recognized and trusted publishers. This can be done by adding specific conditions to exclude these processes from triggering alerts, as shown in the detection rule.
+- Users should regularly review and update the list of trusted applications and processes to ensure that new legitimate applications are not mistakenly flagged. This involves monitoring for any changes in application behavior or updates that might affect how files are compressed or archived.
+- It is important to maintain a balance between security and usability by carefully selecting which processes to exclude, ensuring that only well-known and verified applications are exempted from the rule to prevent potential security risks.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration or lateral movement.
+- Verify the legitimacy of the process that triggered the alert by checking its code signature and cross-referencing with known trusted applications.
+- Conduct a thorough investigation of the compressed or archived files to determine if they contain malicious content or sensitive data staged for exfiltration.
+- Review recent file creation and modification events on the system to identify any unauthorized or suspicious activities.
+- If malicious files are confirmed, remove them and any associated processes or services from the system.
+- Restore any affected files from a known good backup to ensure system integrity and operational continuity.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is determined to be part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed file and process activities, aiding in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
index 9ac96708907..bbaea2c1f5c 100644
--- a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
+++ b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,49 @@ file where host.os.type == "windows" and event.type == "creation" and
   not file.path : "?:\\$RECYCLE.BIN\\*\\*" and
   not file.name : "desktop.ini"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File Staged in Root Folder of Recycle Bin
+
+The Recycle Bin in Windows is designed to temporarily store deleted files, allowing users to recover them if needed. Adversaries may exploit this by placing files directly in the root of the Recycle Bin to prepare for data exfiltration or to bypass security measures. The detection rule identifies such suspicious activity by monitoring file creation events in the root directory, excluding typical system files, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file creation event in the root of the Recycle Bin, focusing on the `file.path` and `file.name` fields to identify the suspicious file.
+- Verify the timestamp of the file creation event to determine when the activity occurred and correlate it with other events on the system.
+- Check the user account associated with the file creation event to identify who might have created or moved the file to the Recycle Bin.
+- Investigate the file's origin by examining recent file access and modification events on the system to trace back its source.
+- Use Osquery to list all files in the Recycle Bin, including their metadata, to gather more context about the file. Example query: `SELECT path, filename, size, atime, mtime FROM file WHERE directory LIKE 'C:\\\\$RECYCLE.BIN\\\\%' AND NOT directory LIKE 'C:\\\\$RECYCLE.BIN\\\\%\\\\%';`
+- Analyze the file's content and metadata to determine its nature and potential sensitivity, using file hashing and comparison against known malicious signatures if necessary.
+- Cross-reference the file's hash with threat intelligence databases to check for known malicious files.
+- Review system logs and security events around the time of the file creation for any signs of suspicious activity or anomalies.
+- Investigate any network connections or data transfers initiated by the host around the time of the file creation to identify potential exfiltration attempts.
+- Consult with the user or system owner to verify if the file placement was intentional or authorized, and gather any additional context they might provide.
+
+### False positive analysis
+
+- System or application updates may temporarily create files in the root of the Recycle Bin, leading to false positives. Users can monitor update schedules and correlate these events to rule out threats.
+- Certain backup or recovery software might use the Recycle Bin for temporary storage, triggering the detection rule. Identifying and excluding these specific software behaviors can reduce false alerts.
+- User actions such as manually moving files to the Recycle Bin root for organizational purposes can be mistaken for malicious activity. Educating users on proper file management practices can help minimize these occurrences.
+- Automated scripts or maintenance tasks that interact with the Recycle Bin might inadvertently place files in the root directory. Reviewing and adjusting these scripts to use subdirectories can prevent false positives.
+- To manage these false positives, users can create exceptions in the detection rule for known benign file paths or processes, ensuring that only genuinely suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential data exfiltration.
+- Verify the legitimacy of the file by checking its origin, creation time, and associated user account.
+- Conduct a thorough investigation to determine if the file is part of a larger attack, using endpoint detection and response (EDR) tools.
+- Remove the suspicious file from the Recycle Bin and perform a full system scan using updated antivirus and anti-malware software.
+- Review recent user activity and access logs to identify any unauthorized access or anomalies.
+- Escalate the incident to the security operations center (SOC) or incident response team if the file is confirmed to be malicious or part of a targeted attack.
+- Implement enhanced logging policies to capture detailed file creation and modification events, especially in sensitive directories.
+- Integrate threat intelligence feeds to improve detection capabilities and correlate with known indicators of compromise (IOCs).
+- Restore the system to its operational state by ensuring all security patches are applied and verifying system integrity.
+- Harden the system by enforcing least privilege access, disabling unnecessary services, and regularly reviewing security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_outlook_email_archive.toml b/rules_building_block/collection_outlook_email_archive.toml
index 921f2861096..4c08108c07c 100644
--- a/rules_building_block/collection_outlook_email_archive.toml
+++ b/rules_building_block/collection_outlook_email_archive.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,49 @@ process where host.os.type == "windows" and event.type == "start" and process.ar
         process.args : "*davclnt.dll,DavSetCookie*"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Accessing Outlook Data Files
+
+Outlook data files, such as OST and PST, store emails and other data locally on Windows systems. Adversaries may target these files to collect sensitive information, bypassing email server security. The detection rule identifies suspicious processes accessing these files, excluding legitimate Outlook operations, to flag potential unauthorized access or data exfiltration attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process triggered the rule, focusing on the `process.name` and `process.args` fields to identify the suspicious activity.
+- Check the `host.os.type` to confirm the operating system is Windows, as the rule is specific to Windows systems.
+- Investigate the `event.type` to ensure it is a "start" event, indicating the initiation of a process that accessed the Outlook data files.
+- Examine the `process.args` field to identify the specific OST or PST files being accessed and determine if they contain sensitive or critical information.
+- Verify the legitimacy of the process by checking the `process.name` against known legitimate applications that might access Outlook data files, excluding "outlook.exe" and the specific "rundll32.exe" with "davclnt.dll,DavSetCookie" arguments.
+- Use Osquery to gather more context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve details like process path, parent process, and user context.
+- Investigate the parent process of the suspicious activity to determine if it was spawned by a legitimate application or another potentially malicious process.
+- Check the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised.
+- Review recent system logs and security events for any other suspicious activities or anomalies around the time the alert was triggered.
+- Correlate the findings with other alerts or incidents in the environment to identify any patterns or potential indicators of a broader attack campaign.
+
+### False positive analysis
+
+- Known false positives may include legitimate applications or scripts that access Outlook data files for backup or synchronization purposes, such as third-party email clients or backup software.
+- System administrators can handle these false positives by creating exceptions for known and trusted applications that regularly access OST and PST files, ensuring these are documented and reviewed periodically.
+- Users should monitor for any unusual patterns or unexpected applications accessing these files, as this could indicate a potential security risk despite being initially classified as a false positive.
+- Regularly update the list of exceptions to include new legitimate applications as they are identified, while ensuring that these exceptions do not inadvertently allow malicious activity.
+- Consider implementing additional monitoring or logging for processes that frequently trigger the rule to better understand their behavior and confirm their legitimacy.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access to OST and PST files.
+- Review system and security logs to trace the origin of the suspicious process and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Remove any malicious software or unauthorized tools found on the system, ensuring that all traces of the threat actor's presence are eradicated.
+- Restore the system from a known good backup, ensuring that all security patches and updates are applied before reconnecting to the network.
+- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Educate users on the importance of email security and the risks associated with unauthorized access to email data files.
+- Review and update access controls and permissions related to email data files, ensuring that only authorized personnel have access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_posh_compression.toml b/rules_building_block/collection_posh_compression.toml
index 5b1150f75d0..3e58fd4d9aa 100644
--- a/rules_building_block/collection_posh_compression.toml
+++ b/rules_building_block/collection_posh_compression.toml
@@ -5,7 +5,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 
 
 [rule]
@@ -70,6 +70,48 @@ not powershell.file.script_block_text : (
 ) and
 not file.directory : "C:\Program Files\Microsoft Dependency Agent\plugins\lib"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Archive Compression Capabilities
+
+PowerShell, a powerful scripting language in Windows, includes capabilities for file compression using various .NET classes and cmdlets. Adversaries exploit these to compress and encrypt data for exfiltration. The detection rule identifies suspicious use of compression methods and cmdlets, excluding known legitimate activities, to flag potential data exfiltration attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific PowerShell script block text triggered the alert, focusing on the use of compression methods like "IO.Compression.ZipFile" or cmdlets like "Compress-Archive".
+- Check the event logs for the process category to identify the user account and host involved in the activity, using the `event.category:process` and `host.os.type:windows` fields.
+- Investigate the script block text to determine if the compression activity is part of a known legitimate process or if it appears suspicious, especially if it involves unusual directories or file paths.
+- Examine the command line arguments and script content for any signs of obfuscation or attempts to hide the true intent of the script.
+- Use Osquery to gather more context about the process by running a query like: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%IO.Compression%'`.
+- Cross-reference the timestamp of the alert with other security events on the host to identify any correlated activities, such as network connections or file modifications.
+- Check for any recent changes in the file system, especially in directories not excluded by the rule, to identify any compressed files that may have been created.
+- Investigate the network activity from the host around the time of the alert to detect any potential data exfiltration attempts.
+- Review the history of PowerShell execution on the host to identify any patterns or repeated use of compression methods that could indicate malicious behavior.
+- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with adversaries using PowerShell for data exfiltration.
+
+### False positive analysis
+
+- Legitimate software updates or system maintenance tasks may trigger the rule, such as Lenovo diagnostics using compression for log files. Users can handle these by adding specific paths or script block text to the exclusion list.
+- Backup solutions like Ansible may use compression methods for routine operations. Users should identify and exclude these by recognizing specific script block text patterns associated with these tools.
+- Microsoft Dependency Agent plugins might use compression for legitimate purposes. Excluding the directory "C:\\Program Files\\Microsoft Dependency Agent\\plugins\\lib" can prevent false positives related to this activity.
+- Regularly review and update exclusion lists to ensure they reflect current legitimate activities, minimizing the risk of overlooking genuine threats while reducing false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration.
+- Conduct a thorough investigation of the PowerShell script logs to identify the source and scope of the compression activity.
+- Verify if any unauthorized data access or exfiltration has occurred by reviewing network logs and data transfer records.
+- Remove any malicious scripts or files identified during the investigation from the affected system.
+- Apply security patches and updates to the operating system and any vulnerable applications to prevent exploitation of known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and module logging, for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
+- Restore the system to its operational state by reinstalling the operating system if necessary and restoring data from verified clean backups.
+- Harden the system by disabling unnecessary PowerShell features, enforcing the principle of least privilege, and implementing application whitelisting to prevent unauthorized script execution."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/command_and_control_bitsadmin_activity.toml b/rules_building_block/command_and_control_bitsadmin_activity.toml
index 2b54cbba541..9b117091f60 100644
--- a/rules_building_block/command_and_control_bitsadmin_activity.toml
+++ b/rules_building_block/command_and_control_bitsadmin_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,48 @@ process where host.os.type == "windows" and event.type == "start" and
    )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Bitsadmin Activity
+
+Windows Background Intelligent Transfer Service (BITS) facilitates low-bandwidth file transfers, often used for updates. Adversaries exploit BITS to persistently download and execute malicious payloads, leveraging its ability to operate in the background. The detection rule identifies suspicious BITS usage by monitoring specific command-line arguments in processes like `bitsadmin.exe` and `powershell.exe`, which are indicative of potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (`bitsadmin.exe` or `powershell.exe`) and the command-line arguments that triggered the alert. This will help determine the nature of the suspicious activity.
+- Check the process start time and correlate it with other events on the system to identify any unusual patterns or activities around the same time.
+- Investigate the parent process of the suspicious `bitsadmin.exe` or `powershell.exe` process to understand how it was initiated. This can provide insights into whether the process was started by a legitimate application or a potentially malicious script.
+- Examine the user account associated with the process to determine if the activity aligns with the user's typical behavior or if it might indicate compromised credentials.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all BITS jobs on the system: `SELECT * FROM bits_jobs;` This can help identify any ongoing or completed BITS transfers that may be related to the alert.
+- Analyze network connections established by the suspicious process to identify any unusual or unauthorized external communications. This can help determine if data exfiltration or command and control activity is occurring.
+- Review the system's event logs for any additional indicators of compromise or related activities, such as failed login attempts, privilege escalation, or other suspicious processes.
+- Check for any recent file modifications or new files created on the system that could be associated with the suspicious BITS activity, indicating potential payloads or scripts.
+- Investigate any scheduled tasks or startup items that might have been created or modified to persist the malicious activity, especially if the `SetNotifyCmdLine` argument was used.
+- Consult threat intelligence sources to determine if the observed command-line arguments or network indicators match known malicious campaigns or tools, providing further context for the investigation.
+
+### False positive analysis
+
+- Legitimate software updates or patch management systems may trigger the Bitsadmin Activity rule, as they often use BITS for downloading updates, which can be mistaken for malicious activity.
+- System administrators or IT personnel using scripts to automate file transfers or system maintenance tasks might inadvertently match the rule's criteria, leading to false positives.
+- To manage these false positives, users can create exceptions for known and trusted processes or scripts by whitelisting specific command-line arguments or process names that are frequently used in legitimate operations.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening activities are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Analyze the process tree and command-line arguments associated with the suspicious BITS activity to understand the scope and intent of the attack.
+- Terminate any malicious processes identified, such as those initiated by bitsadmin.exe or powershell.exe with suspicious arguments.
+- Remove any unauthorized or malicious BITS jobs using the bitsadmin tool or PowerShell cmdlets to prevent further execution.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
+- Review and enhance logging policies to ensure detailed monitoring of BITS activities and PowerShell executions, including command-line arguments.
+- Implement application whitelisting to prevent unauthorized use of bitsadmin.exe and restrict PowerShell script execution to signed scripts only.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied.
+- Educate users on recognizing and reporting suspicious activities, and consider conducting a security awareness training session focused on phishing and social engineering tactics."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
index 1eed992f989..0d7927fcf41 100644
--- a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
+++ b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
@@ -5,7 +5,7 @@ integration = ["endpoint", "windows", "system"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,48 @@ process where host.os.type == "windows" and event.type == "start" and
    (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and
    process.args : "list" and process.args : "/text*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft IIS Service Account Password Dumped
+
+Microsoft IIS is a web server technology that uses service accounts for application pools, which can be managed via the AppCmd command-line tool. Adversaries with access to the server might exploit AppCmd to extract and decrypt these service account passwords, potentially leading to unauthorized access. The detection rule identifies suspicious use of AppCmd by monitoring for specific command-line arguments indicative of password dumping activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `appcmd.exe` process with the specific arguments `list` and `/text*` to ensure the alert is not a false positive.
+- Check the process execution context, including the user account under which `appcmd.exe` was executed, to determine if it aligns with expected administrative activity.
+- Investigate the parent process of `appcmd.exe` to identify how it was initiated and whether it was triggered by a legitimate administrative tool or a suspicious script or process.
+- Examine the host's security logs for any recent login events or anomalies around the time `appcmd.exe` was executed to identify potential unauthorized access.
+- Use Osquery to gather additional context on the process execution by running a query such as: `SELECT * FROM processes WHERE name = 'appcmd.exe' AND cmdline LIKE '%list%/text*%';` to verify the command-line arguments and execution details.
+- Analyze network logs to identify any unusual outbound connections from the host that might indicate data exfiltration following the password dump.
+- Review recent changes to IIS configuration files and application pool settings to detect any unauthorized modifications that could be related to the alert.
+- Check for the presence of web shells or other malicious files on the IIS server that could have been used to execute `appcmd.exe`.
+- Correlate the alert with other security events or alerts from the same host or network segment to identify potential lateral movement or coordinated attacks.
+- Consult threat intelligence sources to determine if there are known campaigns or threat actors associated with similar tactics, techniques, and procedures (TTPs) involving IIS and `appcmd.exe`.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use AppCmd to manage IIS configurations, including listing application pools and their properties, which can trigger the rule. To handle this, identify and document regular maintenance schedules and exclude these activities from alerts during those times.
+- Automated scripts: Some organizations use automated scripts for IIS management that might include commands similar to those flagged by the rule. Review and whitelist these scripts by creating exceptions based on specific command-line arguments or script paths.
+- Monitoring and auditing tools: Security and monitoring tools might execute AppCmd commands as part of their regular checks. Verify the legitimacy of these tools and exclude their known processes from triggering alerts.
+- Development and testing environments: In non-production environments, developers might frequently use AppCmd for testing purposes. Consider excluding these environments from the rule or adjusting the sensitivity of alerts based on the environment type.
+
+### Response and remediation
+
+- Immediately isolate the affected server from the network to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any additional compromised accounts or systems.
+- Review server logs and AppCmd usage history to identify unauthorized access patterns and potential entry points.
+- Change all service account passwords associated with the IIS server and ensure they follow strong password policies.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for IIS servers, including command-line activity and access logs, to detect future unauthorized actions.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze security events across the network.
+- Apply security patches and updates to the IIS server and related software to mitigate known vulnerabilities.
+- Conduct a security review of the IIS server configuration and apply hardening measures, such as disabling unnecessary services and enforcing least privilege access.
+- Educate and train IT staff on recognizing and responding to similar threats, leveraging MITRE ATT&CK framework details for context on credential dumping techniques."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_mdmp_file_creation.toml b/rules_building_block/credential_access_mdmp_file_creation.toml
index 938d4cba5ab..69041206444 100644
--- a/rules_building_block/credential_access_mdmp_file_creation.toml
+++ b/rules_building_block/credential_access_mdmp_file_creation.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,50 @@ file where host.os.type == "windows" and event.type == "creation" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Credential Access via Memory Dump File Creation
+
+Memory dump files capture the state of a process's memory, often used for debugging. Adversaries exploit this by creating dumps to extract sensitive data, like credentials. The detection rule identifies suspicious dump file creation on Windows systems, focusing on files with specific headers and sizes, while excluding trusted processes and paths, to flag potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the "4d444d50" header in the file, indicating a memory dump file.
+- Verify the file size to ensure it meets the threshold of 30,000 bytes or more, which aligns with the rule's criteria for medium-sized dumps.
+- Check the process name and executable path to determine if the process is listed as a trusted process or path in the exclusion list.
+- Investigate the process code signature to confirm whether it is marked as trusted, which might indicate a false positive.
+- Examine the file path to see if it matches any of the excluded directories, such as "?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\WER\\\\*" or "?:\\\\Users\\\\*\\\\AppData\\\\*\\\\CrashDumps\\\\*".
+- Use Osquery to gather additional context about the process that created the dump file. For example, run the following query to list processes with their command line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE path LIKE 'C:\\\\Windows\\\\System32\\\\%' OR path LIKE 'C:\\\\Program Files\\\\%';`
+- Check the system's event logs for any related events around the time of the dump file creation to identify any suspicious activities or anomalies.
+- Investigate the user account associated with the process to determine if it has the necessary privileges to create memory dumps and if the activity aligns with normal behavior.
+- Analyze network activity from the host to identify any unusual outbound connections that might suggest data exfiltration attempts.
+- Correlate the alert with other security events or alerts from the same host or user to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Memory dump files created by legitimate system processes such as Windows Error Reporting (WER) can trigger false positives. These processes are often involved in crash reporting and diagnostics, which are benign activities.
+- Trusted third-party applications, like Zoom, may generate memory dumps for crash analysis, leading to false positives. These applications are typically signed and can be verified through their code signatures.
+- System administrators or developers might intentionally create memory dumps for debugging purposes, which should be considered non-threatening if performed by authorized personnel.
+- To manage these false positives, users can refine the detection rule by adding exceptions for known trusted processes and paths, ensuring that only suspicious activities are flagged.
+- Regularly update the list of trusted applications and paths based on organizational needs and software updates to minimize unnecessary alerts.
+- Implement a review process for flagged events to verify the legitimacy of the memory dump creation, allowing for the adjustment of rules and exceptions as needed.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the memory dump file creation, focusing on any untrusted processes or unusual activity.
+- Review the process and file paths involved in the alert to determine if they align with known malicious behaviors or anomalies.
+- If malicious activity is confirmed, remove any unauthorized software or malware from the system using trusted antivirus or endpoint detection and response tools.
+- Change all potentially compromised credentials, especially those with administrative privileges, to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process creation, file access, and network activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are properly set.
+- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly reviewing security policies to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
index 666c28d4f06..9e13f5bf925 100644
--- a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
+++ b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,52 @@ file where host.os.type == "windows" and event.type == "creation" and
     process.name : "System" and file.extension : "tmpscan"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Memory Dump File with Unusual Extension
+
+Memory dumps capture the contents of system memory, often used for debugging or forensic analysis. Adversaries may disguise these files with atypical extensions to evade detection, potentially hiding credential dumping activities. The detection rule identifies such anomalies by checking for specific memory dump signatures and filtering out known benign processes and extensions, thus highlighting suspicious file creations.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the file path, file name, and the unusual extension used for the memory dump file.
+- Verify the file header bytes to confirm the presence of the "MDMP" signature, ensuring it matches the expected pattern "4d444d50*".
+- Check the process that created the file by examining the `process.executable` and `process.name` fields to determine if it is a known or trusted application.
+- Investigate the parent process of the file creation event to understand the process hierarchy and identify any potentially malicious parent processes.
+- Use Osquery to list all running processes and their associated command lines to identify any suspicious activities or processes that may have interacted with the memory dump file:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE path LIKE 'C:\\\\%';
+  ```
+- Examine the file creation time and correlate it with other system events or logs to identify any unusual activities or patterns around that time.
+- Check for any recent changes in the system's security settings or configurations that might have allowed the creation of such files.
+- Investigate the user account context under which the file was created to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Review network logs for any outbound connections from the host around the time of the file creation to detect potential data exfiltration attempts.
+- Cross-reference the alert with other security tools or logs to gather additional context and corroborate findings, such as endpoint detection and response (EDR) solutions or SIEM logs.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate software that generates memory dumps with non-standard extensions for internal use or debugging purposes. 
+- Security tools or monitoring software might create memory dumps with unusual extensions as part of their normal operation, which could trigger the rule.
+- Developers or IT personnel might intentionally use non-standard extensions for memory dumps during testing or troubleshooting to avoid overwriting existing files.
+- To manage these false positives, users can create exceptions for specific processes or file paths known to generate benign memory dumps with unusual extensions.
+- Users should regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the source of the memory dump file creation, focusing on processes and users involved.
+- Analyze the memory dump file to determine if sensitive information, such as credentials, has been compromised.
+- Remove any unauthorized or suspicious files and processes identified during the investigation.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Review and enhance logging policies to ensure comprehensive monitoring of file creation events and process activities.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to improve threat detection and response capabilities.
+- Restore the system from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Implement hardening measures, such as enforcing least privilege access and disabling unnecessary services, to reduce the attack surface.
+- Escalate the incident to the security team or relevant authorities if the investigation reveals a significant breach or ongoing threat."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_win_private_key_access.toml b/rules_building_block/credential_access_win_private_key_access.toml
index 5cb1e8fc4d8..7c04039a85b 100644
--- a/rules_building_block/credential_access_win_private_key_access.toml
+++ b/rules_building_block/credential_access_win_private_key_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,50 @@ process where host.os.type == "windows" and event.type == "start" and
     "?:\\Windows\\System32\\OpenSSH\\*"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Attempted Private Key Access
+
+Private keys are critical for secure authentication in environments, often used in SSH for encrypted communication. Adversaries may target these keys to gain unauthorized access. The detection rule identifies suspicious processes on Windows systems attempting to access files typically associated with private keys, while excluding legitimate applications. This helps in pinpointing potential credential access threats by filtering out benign activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process and arguments that triggered the rule, focusing on the `process.args` field to understand what files were accessed.
+- Check the `process.executable` field to determine the exact executable that attempted to access the private key files and verify if it is a known or expected application in the environment.
+- Investigate the parent process of the suspicious executable using process lineage data to understand how the process was initiated and if it was spawned by a legitimate application.
+- Use Osquery to list all processes currently running on the host that match the suspicious executable path. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE 'C:\\\\Path\\\\To\\\\Suspicious\\\\Executable\\\\%'`.
+- Examine the user context under which the suspicious process was executed by reviewing the `user.name` field to determine if it aligns with expected user behavior.
+- Analyze recent login events on the host to identify any unusual or unauthorized access patterns that might correlate with the attempted private key access.
+- Check for any recent file modifications or access events on the private key files by reviewing file system audit logs or using Osquery to query file access times.
+- Investigate network connections initiated by the suspicious process to identify any potential exfiltration attempts or communication with known malicious IP addresses.
+- Review historical data for any previous alerts or activities associated with the same executable or user to identify patterns or repeated attempts.
+- Correlate the findings with threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Known false positives may include legitimate software or system processes that access private key files for valid reasons, such as automated updates or system maintenance tasks.
+- Applications like LogiLuUpdater.exe, osqueryd.exe, and various Guardicore agents are known to access files that match private key patterns but are typically benign.
+- Users can manage these false positives by creating exceptions for these known legitimate processes in the detection rule, ensuring they are not flagged as suspicious.
+- Regularly review and update the list of excluded executables to include any new legitimate applications that may trigger the rule.
+- Consider the context of the process execution, such as the user account under which the process runs and the frequency of access, to better assess the legitimacy of the activity.
+- Implement logging and monitoring to track any changes in behavior of these processes, which might indicate a shift from benign to potentially malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access.
+- Conduct a thorough investigation to identify the source and scope of the attempted access, focusing on the processes and files involved.
+- Review system logs and security alerts to gather additional context and evidence of the intrusion attempt.
+- Change all potentially compromised credentials, including SSH keys and any other authentication mechanisms used on the affected system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
+- Integrate threat intelligence feeds and security tools to improve detection capabilities and correlate alerts with known threat actors.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Implement hardening measures such as restricting access to private key files, using multi-factor authentication, and regularly rotating keys."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
index f825349247d..e8b14ff3105 100644
--- a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
+++ b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/06/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/06/25"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,48 @@ query = '''
 event.dataset: "aws.cloudtrail" and event.provider: "rds.amazonaws.com" 
     and event.action: ("CreateDBSnapshot" or "CreateDBClusterSnapshot") and event.outcome: "success" 
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS RDS DB Snapshot Created
+
+AWS RDS DB Snapshots are backups of databases that ensure data recovery and continuity. Adversaries may exploit this by creating snapshots to bypass access controls or revert changes, masking their activities. The detection rule monitors successful snapshot creation events in AWS CloudTrail, serving as a foundation for identifying potential misuse when correlated with other suspicious activities.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the `CreateDBSnapshot` or `CreateDBClusterSnapshot` event by examining the `userIdentity` field.
+- Check the `sourceIPAddress` field in the CloudTrail logs to determine the origin of the request and assess if it aligns with known IP addresses or locations for your organization.
+- Investigate the `eventTime` field to establish a timeline and correlate it with other activities or alerts that occurred around the same time.
+- Examine the `requestParameters` field to identify the specific database instance or cluster for which the snapshot was created, and assess its criticality or sensitivity.
+- Cross-reference the `userAgent` field to identify the tool or service used to initiate the snapshot creation and determine if it matches expected patterns.
+- Utilize Osquery to query AWS RDS instances and snapshots for additional context. For example, use the following Osquery query to list all RDS snapshots: `SELECT * FROM aws_rds_snapshots WHERE snapshot_create_time > 'YYYY-MM-DD HH:MM:SS';` replacing the timestamp with the relevant timeframe.
+- Investigate any recent changes to IAM policies or roles that might have granted new permissions related to RDS snapshot creation.
+- Check for any unusual or unauthorized access patterns in the AWS Management Console or API calls that could indicate compromised credentials.
+- Correlate the snapshot creation event with any recent alerts or anomalies in your security monitoring tools to identify potential patterns of malicious activity.
+- Review historical data to determine if there is a pattern of frequent snapshot creation by the same user or role, which could indicate an ongoing attempt to evade detection or maintain persistence.
+
+### False positive analysis
+
+- Routine database maintenance or backup operations by authorized personnel can trigger the AWS RDS DB Snapshot Created rule, leading to false positives. These activities are typically scheduled and documented, making them identifiable.
+- Automated backup solutions or scripts that create snapshots as part of a disaster recovery plan may also result in false positives. These should be reviewed and whitelisted if they align with organizational policies.
+- Development and testing environments often involve frequent snapshot creation for testing purposes. These environments should be monitored separately, and known non-threatening behaviors can be excluded by setting exceptions for specific user accounts or roles.
+- To manage false positives, users can create exceptions in the detection rule for specific AWS accounts, IAM roles, or IP addresses associated with legitimate snapshot creation activities. This helps in focusing on truly suspicious activities while reducing noise from expected operations.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to identify the source and context of the snapshot creation, including the user or service account involved.
+- Contain the potential threat by revoking access for the identified user or service account and reviewing their permissions to ensure least privilege.
+- Investigate any other suspicious activities associated with the same user or service account, such as unauthorized access attempts or changes to security groups.
+- If unauthorized snapshot creation is confirmed, delete the snapshot to prevent any rollback to a compromised state.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data have been affected.
+- Implement enhanced logging and monitoring for AWS RDS and related services to detect similar activities in the future, ensuring logs are retained for an appropriate period.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to correlate events and improve threat detection capabilities.
+- Restore the database to a known good state if any unauthorized changes were made, using verified snapshots or backups.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
+- Apply hardening measures such as enabling multi-factor authentication (MFA) for all users, regularly reviewing access permissions, and implementing network segmentation to limit access to critical resources."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
index 45e62b40635..6b450bac8c8 100644
--- a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
+++ b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,49 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.args : "type" and process.args : (">", ">>")) or
     (process.args : "copy" and process.args : "/b"))
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Binary Content Copy via Cmd.exe
+
+Cmd.exe, a command-line interpreter on Windows, can be exploited by attackers to reconstruct binary files from fragments using commands like 'type' and 'copy' with specific arguments. This technique allows adversaries to evade detection by assembling malicious payloads directly on the target system. The detection rule identifies suspicious cmd.exe activity by monitoring for specific command patterns indicative of binary reassembly, thus alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of cmd.exe activity with arguments related to 'type' and 'copy' commands, specifically looking for the use of '>' or '>>' with 'type' and '/b' with 'copy'.
+- Examine the process tree to identify the parent process of cmd.exe to understand how it was initiated and assess if it was launched by a legitimate application or script.
+- Check the user account associated with the cmd.exe process to determine if it aligns with expected user behavior or if it might be indicative of compromised credentials.
+- Investigate the file paths and names involved in the 'type' and 'copy' commands to identify if they correspond to known or suspicious binary files.
+- Utilize Osquery to gather additional context on the cmd.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'cmd.exe' AND (cmdline LIKE '%type%' OR cmdline LIKE '%copy%');` to retrieve detailed command-line arguments and process metadata.
+- Analyze recent file creation and modification events on the system to identify any new or altered binaries that may have resulted from the cmd.exe activity.
+- Correlate the cmd.exe activity with network logs to check for any outbound connections that might indicate data exfiltration or command-and-control communication.
+- Review system logs for any other suspicious activities or anomalies around the time of the cmd.exe execution to identify potential lateral movement or privilege escalation attempts.
+- Check for any scheduled tasks or startup items that might have been created or modified to persist the malicious payload on the system.
+- Consult threat intelligence sources to determine if the observed cmd.exe activity matches known attack patterns or indicators of compromise associated with specific threat actors or malware families.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger this rule, such as system administrators using cmd.exe to concatenate log files or other benign data files using 'type' and 'copy' commands. 
+- Automated scripts or batch files that perform legitimate file operations using cmd.exe might also be flagged, especially if they involve binary files or use the '/b' switch with 'copy'.
+- Developers or IT personnel testing or deploying software might use similar command patterns to assemble application components, leading to false positives.
+- To manage these false positives, users can create exceptions for known safe scripts or processes by whitelisting specific command patterns or file paths that are regularly used in non-threatening contexts.
+- Implementing a review process for flagged activities can help distinguish between legitimate administrative actions and potential threats, allowing for more accurate tuning of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the cmd.exe process activity, focusing on the specific command patterns identified in the detection rule.
+- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
+- Utilize forensic tools to capture and analyze memory and disk images from the affected system to understand the scope and impact of the attack.
+- Remove any identified malicious binaries or payloads from the system and ensure that all associated processes are terminated.
+- Apply security patches and updates to the operating system and any vulnerable applications to mitigate exploitation risks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging and monitoring policies to capture detailed command-line activity and process execution for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_cmstp_execution.toml b/rules_building_block/defense_evasion_cmstp_execution.toml
index 5e901e34f2b..b68e35b4cb6 100644
--- a/rules_building_block/defense_evasion_cmstp_execution.toml
+++ b/rules_building_block/defense_evasion_cmstp_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,49 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name : "cmstp.exe" and process.args == "/s"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Defense Evasion via CMSTP.exe
+
+CMSTP.exe is a Windows utility for installing network profiles using INF files. Adversaries exploit it to execute malicious code by crafting INF files with harmful commands, bypassing security measures. The detection rule identifies suspicious activity by monitoring the execution of CMSTP.exe with specific arguments, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of CMSTP.exe execution with the "/s" argument, as this indicates a silent installation which could be suspicious.
+- Check the parent process of CMSTP.exe to determine if it was launched by a legitimate application or a potentially malicious process.
+- Investigate the user account associated with the CMSTP.exe process to verify if the activity aligns with their typical behavior or if it appears anomalous.
+- Examine the command line arguments used with CMSTP.exe to identify any unusual or unexpected parameters that could indicate malicious intent.
+- Use Osquery to list recent processes executed by the user associated with the alert to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
+- Analyze the INF file associated with the CMSTP.exe execution to check for any embedded malicious commands or scripts.
+- Review recent file modifications in directories commonly used for storing INF files to identify any unauthorized changes or suspicious files.
+- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
+- Check network logs for any unusual outbound connections initiated around the time of the CMSTP.exe execution, which could suggest data exfiltration or command and control activity.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns involving CMSTP.exe.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they use CMSTP.exe with the "/s" argument for silent installations, which is a common practice for deploying network profiles or VPN configurations.
+- System administrators might use CMSTP.exe in scripts or automated tasks for deploying or updating network settings across multiple machines, leading to benign alerts.
+- To manage these false positives, users can create exceptions for known and trusted software installations by whitelisting specific INF files or directories from which these files are executed.
+- Monitoring the context of CMSTP.exe execution, such as the parent process or the source of the INF file, can help differentiate between legitimate and suspicious activities.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary activities are excluded from alerts, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source of the malicious INF file and any other potentially compromised systems.
+- Analyze the execution context of CMSTP.exe, including the command-line arguments and associated files, to understand the scope of the attack.
+- Review and collect relevant logs, such as Windows Event Logs and security software logs, to gather evidence and trace the attacker's actions.
+- Remove any malicious files or scripts identified during the investigation and ensure that no unauthorized changes remain on the system.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
+- Implement enhanced logging and monitoring policies to detect similar activities in the future, focusing on process execution and command-line arguments.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate events.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
index e59ad5a89c1..9d101bf4284 100644
--- a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
+++ b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,51 @@ file where host.os.type == "windows" and event.action != "deletion" and
 
   not (process.executable : "?:\\Windows\\System32\\inetsrv\\w3wp.exe" and file.path : "?:\\inetpub\\temp\\IIS Temporary Compressed Files\\*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Archive File with Unusual Extension
+In computing environments, archive files are used to compress and bundle data for efficient storage and transfer. Adversaries exploit this by disguising archives with extensions typical of benign file types like images or documents, evading detection. The detection rule identifies such anomalies by checking for archive file signatures paired with unusual extensions, flagging potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and extension that triggered the alert, focusing on the `file.path` and `file.extension` fields.
+- Verify the file header bytes using the `file.Ext.header_bytes` field to confirm the file is indeed an archive, despite its unusual extension.
+- Check the file creation timestamp and compare it with recent user activity to determine if the file creation aligns with legitimate user actions.
+- Investigate the process that created the file by examining the `process.executable` field to identify any suspicious or unexpected processes.
+- Use Osquery to list all files in the directory where the suspicious file was found, which can help identify other potentially malicious files:
+  ```sql
+  SELECT path, filename, extension FROM file WHERE directory = 'C:\\\\path\\\\to\\\\suspicious\\\\file\\\\directory';
+  ```
+- Analyze recent network activity from the host to detect any unusual outbound connections that might indicate data exfiltration.
+- Check the user account associated with the file creation for any signs of compromise, such as unusual login times or locations.
+- Review system logs for any recent changes or installations that could be related to the creation of the suspicious file.
+- Investigate any other alerts or incidents involving the same host or user to identify potential patterns or related activities.
+- Consult threat intelligence sources to determine if the file's characteristics match known malicious patterns or campaigns.
+
+### False positive analysis
+
+- Files generated by legitimate software that use non-standard extensions for archives, such as backup or compression tools, may trigger false positives. Users can handle these by identifying the specific software and excluding its file creation activities from the rule.
+- Web server operations, particularly those involving temporary file storage, might produce files with unusual extensions that match archive signatures. Excluding known server processes and paths, such as IIS temporary files, can reduce false positives.
+- Some enterprise applications may use custom file extensions for archives as part of their normal operation. Identifying these applications and creating exceptions for their file extensions can help minimize false alerts.
+- Multimedia editing software might save project files with extensions that resemble common media types but contain embedded archives. Users should identify these applications and exclude their specific file types from the rule.
+- Automated scripts or batch processes that generate files with non-standard extensions for internal use might be flagged. Users can manage this by excluding specific directories or processes known to produce such files.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or data exfiltration.
+- Verify the alert by checking the file's header and extension to confirm it is a masqueraded archive file.
+- Conduct a thorough investigation to identify the source of the file and any associated processes or network connections.
+- Remove the suspicious file and any related malicious files or processes from the system.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
+- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on unusual file extensions and headers.
+- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
+- Review and update endpoint protection and intrusion detection systems to recognize and block similar masquerading attempts.
+- Conduct a security awareness training session for users to recognize and report suspicious files and activities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
index 60798ca9d0f..2ef1f5c5fd3 100644
--- a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
+++ b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -253,6 +253,50 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Communication App Child Process
+
+Communication apps like Slack, WebEx, and Teams are integral to modern workflows, facilitating seamless interaction. However, adversaries can exploit these apps by spawning unauthorized child processes, potentially masquerading as legitimate ones or exploiting vulnerabilities to execute malicious code. The detection rule identifies such anomalies by monitoring child processes of these apps, ensuring they are trusted and signed by recognized entities. This helps in spotting deviations that could indicate malicious activity, such as unexpected command executions or unsanctioned software launches, thereby safeguarding against potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific communication app and child process involved, using fields like `process.parent.name` and `process.name`.
+- Verify the legitimacy of the child process by checking the `process.executable` path and `process.code_signature.trusted` status to ensure it matches known trusted paths and signatures.
+- Examine the `process.command_line` and `process.args` fields for any unusual or unexpected command executions that could indicate malicious activity.
+- Cross-reference the `process.code_signature.subject_name` with known legitimate entities to confirm the authenticity of the process.
+- Utilize Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'suspicious_process_name';`
+- Investigate the parent process (`process.parent.name`) to determine if it has been compromised or if it is behaving unexpectedly.
+- Check for any recent changes or updates to the communication app that might have introduced vulnerabilities or unauthorized modifications.
+- Analyze network activity associated with the suspicious process to identify any unusual outbound connections or data exfiltration attempts.
+- Review system logs and event history around the time of the alert to identify any correlated events or anomalies that could provide additional context.
+- Consult threat intelligence sources to determine if there are any known threats or vulnerabilities associated with the specific communication app or process involved in the alert.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they spawn child processes from communication apps, as these processes might not be recognized or signed by trusted entities at the time of the update.
+- Custom scripts or automation tools that interact with communication apps could be flagged if they execute commands or launch processes that are not explicitly whitelisted.
+- Users running communication apps in non-standard directories or using portable versions might see false positives due to the rule's reliance on specific file paths for trusted executables.
+- To manage these false positives, users can create exceptions for known and verified processes by adding them to the list of trusted executables or code signatures.
+- Regularly review and update the list of trusted entities and executable paths to accommodate new software versions or organizational changes in software deployment practices.
+- Consider implementing a logging mechanism to track and analyze flagged processes, allowing for a more informed decision when creating exceptions.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation of the suspicious child process, including reviewing process trees and command-line arguments to identify any malicious behavior.
+- Verify the code signatures of the involved processes to ensure they are from trusted sources and have not been tampered with.
+- If malicious activity is confirmed, terminate the suspicious processes and remove any associated files or executables from the system.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected anomalies with known threat indicators and improve detection capabilities.
+- Restore the system to its operational state by applying the latest security patches and updates to the operating system and communication applications.
+- Conduct a security review of the affected applications and implement hardening measures, such as application whitelisting and least privilege access controls.
+- Educate users on recognizing and reporting suspicious activity to improve the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_dll_hijack.toml b/rules_building_block/defense_evasion_dll_hijack.toml
index 68d23e22874..8cde72f8f6c 100644
--- a/rules_building_block/defense_evasion_dll_hijack.toml
+++ b/rules_building_block/defense_evasion_dll_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,49 @@ library where host.os.type == "windows" and
         "553451008520a5f0110d84192cba40208fb001c27454f946e85e6fb2e6553292"
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unsigned DLL Loaded by a Trusted Process
+
+In Windows environments, DLLs are essential for modularizing code, allowing trusted processes to load necessary functions dynamically. Adversaries exploit this by placing malicious, unsigned DLLs in directories of trusted applications, causing them to execute under the guise of legitimate processes. The detection rule identifies such anomalies by checking for unsigned DLLs loaded by trusted processes, focusing on recent file modifications and excluding known safe hashes, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the trusted process that loaded the unsigned DLL, focusing on the `process.executable` and `dll.path` fields.
+- Verify the digital signature status of the process using the `process.code_signature.status` field to confirm it is indeed trusted.
+- Check the `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` fields to determine if the DLL was recently created or modified, which could indicate suspicious activity.
+- Investigate the `dll.hash.sha256` field to see if the hash is known to be associated with malicious activity by cross-referencing with threat intelligence databases.
+- Use Osquery to list all DLLs loaded by the process in question, focusing on unsigned ones. Example query: `SELECT path, name, pid FROM processes JOIN process_open_sockets USING (pid) WHERE path LIKE '%<process_name>%' AND path NOT LIKE '%.dll';`
+- Examine the directory from which the DLL was loaded to identify any other suspicious files or recent changes, using the `dll.path` field for context.
+- Check the `user.id` field to determine which user account was associated with the process execution, looking for unusual or unauthorized accounts.
+- Investigate the `dll.Ext.device.product_id` field to see if the DLL was loaded from a virtual device, which might indicate an attempt to bypass security controls.
+- Review system logs and other security alerts around the time of the DLL loading to identify any correlated suspicious activities or patterns.
+- Consult with the application owner or system administrator to verify if the unsigned DLL is expected or part of a legitimate update or installation.
+
+### False positive analysis
+
+- Known false positives may include legitimate software updates or installations where unsigned DLLs are temporarily loaded by trusted processes. These scenarios can occur when software vendors release updates that have not yet been signed or when installation processes involve unsigned components.
+- Another potential false positive is the use of custom or in-house developed applications that may not have signed DLLs but are still trusted within the organization. These applications might load unsigned DLLs as part of their normal operation.
+- To manage these false positives, users can create exceptions for specific DLL hashes that are known to be safe but unsigned. This can be done by adding these hashes to the exclusion list in the detection rule.
+- Users can also exclude specific processes or directories from monitoring if they are known to frequently load unsigned DLLs as part of their legitimate function. This helps in reducing noise and focusing on truly suspicious activities.
+- Regularly updating the list of known safe hashes and maintaining a whitelist of trusted applications can help in minimizing false positives while ensuring that legitimate activities are not flagged as threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Verify the legitimacy of the unsigned DLL by checking its origin and purpose; if malicious, remove it from the system.
+- Conduct a thorough investigation to identify how the unsigned DLL was introduced, focusing on recent file modifications and access logs.
+- Review and update the list of known safe hashes to ensure that legitimate DLLs are not mistakenly flagged in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution and DLL loading activities for future investigations.
+- Integrate threat intelligence feeds to automatically update detection rules with the latest known malicious hashes and signatures.
+- Restore the system to its operational state by reinstalling affected applications and applying the latest security patches.
+- Conduct a security audit of the application directories to ensure no other unauthorized files are present.
+- Implement hardening measures such as application whitelisting and enforcing strict code-signing policies to prevent unauthorized DLL loading."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
index 79332fc5371..de0f1b0adde 100644
--- a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
+++ b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,52 @@ sequence by user.id with maxspan=5s
   process.name : "rundll32.exe" and process.command_line : ("*dfshim*ShOpenVerbApplication*", "*dfshim*#*")]
  [network where host.os.type == "windows" and process.name : "dfsvc.exe"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution via Microsoft DotNet ClickOnce Host
+
+Microsoft DotNet ClickOnce is a deployment technology that allows users to install and run applications by clicking a link in a web browser. Adversaries can exploit this by using trusted processes like Dfsvc.exe to execute malicious payloads, bypassing security measures. The detection rule identifies suspicious activity by monitoring for specific process executions and network activities associated with ClickOnce misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the process `rundll32.exe` with command lines containing `dfshim` and `ShOpenVerbApplication` or `#`, as these are indicative of ClickOnce misuse.
+- Check the process tree to identify the parent process of `rundll32.exe` to understand how it was initiated and if it was spawned by a legitimate application or script.
+- Investigate the network activity associated with `dfsvc.exe` to identify any unusual or unauthorized connections, focusing on external IP addresses or domains that are not typically accessed by the organization.
+- Use endpoint detection and response (EDR) tools to gather additional context on the `dfsvc.exe` process, such as its execution path, command line arguments, and any related file modifications.
+- Examine the user account (`user.id`) associated with the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Utilize Osquery to further investigate the execution context of `dfsvc.exe`. For example, run the following query to list all processes related to `dfsvc.exe`:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'dfsvc.exe';
+  ```
+- Check for any recent changes or installations of ClickOnce applications on the affected host that could explain the execution of `dfsvc.exe`.
+- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the ClickOnce execution.
+- Investigate any downloaded files or payloads associated with the ClickOnce execution to determine if they are malicious or unauthorized.
+- Correlate the findings with threat intelligence sources to identify if the observed behavior matches known attack patterns or indicators of compromise (IOCs) related to ClickOnce exploitation.
+
+### False positive analysis
+
+- Legitimate software updates or installations using ClickOnce technology may trigger the detection rule, as they often involve the execution of Dfsvc.exe and network activities similar to those of malicious payloads.
+- Internal applications deployed via ClickOnce within an organization can cause false positives if they are not properly documented or recognized by the security monitoring system.
+- Users can manage these false positives by creating exceptions for known and trusted ClickOnce applications, ensuring that their command lines and network behaviors are documented and whitelisted.
+- Regularly review and update the list of trusted ClickOnce applications to include any new internal or third-party software that is verified as safe.
+- Implement a process to verify the legitimacy of ClickOnce activities flagged by the detection rule, such as cross-referencing with software deployment schedules or consulting with IT departments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the malicious payload.
+- Conduct a thorough investigation to identify the source of the ClickOnce misuse, focusing on recent downloads and executed applications.
+- Analyze the process tree and network connections associated with Dfsvc.exe and rundll32.exe to identify any additional malicious activities or payloads.
+- Remove any unauthorized or suspicious applications installed via ClickOnce, and ensure that all legitimate applications are up to date.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on ClickOnce-related events.
+- Integrate threat intelligence feeds to identify known indicators of compromise (IOCs) related to ClickOnce exploitation.
+- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all security patches are applied.
+- Educate users on the risks associated with downloading and executing applications from untrusted sources, emphasizing the importance of verifying application legitimacy.
+- Harden the environment by configuring application whitelisting policies to restrict the execution of unauthorized applications and by monitoring for unusual ClickOnce activities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_download_susp_extension.toml b/rules_building_block/defense_evasion_download_susp_extension.toml
index 0e65e8b4c34..aa4d93a62b1 100644
--- a/rules_building_block/defense_evasion_download_susp_extension.toml
+++ b/rules_building_block/defense_evasion_download_susp_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,48 @@ file where host.os.type == "windows" and event.type == "creation" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File with Suspicious Extension Downloaded
+
+In Windows environments, certain file extensions can be leveraged for executing code, often bypassing traditional security measures. Adversaries exploit these extensions to execute malicious payloads under the guise of legitimate files. The detection rule identifies downloads of such files from external sources, excluding known safe paths and processes, to flag potential threats. This helps in early detection of attempts to evade defenses using system binary proxy execution techniques.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file extension and path involved, focusing on the `file.extension` and `file.path` fields to determine if the file is indeed suspicious.
+- Check the `file.Ext.windows.zone_identifier` field to understand the origin of the file and confirm it was downloaded from an external source.
+- Investigate the process that created the file using the `process.name` field to determine if it is a known and trusted application.
+- Verify the digital signature of the process using the `process.code_signature.trusted` field to ensure it is from a legitimate source.
+- Cross-reference the file path against known safe paths listed in the query to rule out false positives.
+- Use Osquery to gather additional context about the file. For example, run the following query to check for recent file modifications: `SELECT * FROM file WHERE path = 'C:\\\\Path\\\\To\\\\Suspicious\\\\File';`
+- Examine the file's metadata and properties to identify any anomalies or inconsistencies that could indicate tampering or malicious intent.
+- Analyze network logs to trace the download source and determine if it is a known malicious domain or IP address.
+- Review user activity logs around the time of the file download to identify any unusual behavior or patterns that could suggest compromise.
+- Consult threat intelligence sources to check if the file hash or associated domains/IPs are linked to known threats or campaigns.
+
+### False positive analysis
+
+- **Microsoft Winget Source Files**: Downloads of files with the "msix" extension from the Microsoft Winget Source paths are known false positives. These files are part of legitimate package management operations. Users can handle these by adding exceptions for the specified paths in the detection rule.
+- **Microsoft Teams Temporary Files**: Files with the "msix" extension downloaded by the trusted "Teams.exe" process into its temporary directory are also false positives. These are typically updates or temporary files used by Microsoft Teams. Users should exclude this specific process and path combination to prevent unnecessary alerts.
+- **Legitimate Software Installations**: Some legitimate software installations may use extensions like "appinstaller" or "appx" for their setup files. Users should verify the source and context of such downloads and consider excluding known safe software sources or processes from the detection rule.
+- **System Updates and Configurations**: Files with extensions like "manifest" or "theme" may be part of system updates or user-initiated configuration changes. Users should assess the origin and purpose of these files and exclude them if they are part of routine system operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Conduct a thorough investigation of the downloaded file using a sandbox environment to determine its behavior and potential impact.
+- Check for any unauthorized changes or suspicious activities in the system logs and file integrity monitoring systems.
+- Remove the suspicious file and any associated malicious processes or scheduled tasks identified during the investigation.
+- Restore the system from a known good backup if any unauthorized changes or damages are detected.
+- Update antivirus and endpoint protection solutions to ensure they can detect and block similar threats in the future.
+- Implement enhanced logging policies to capture detailed file creation and modification events, especially for the identified suspicious extensions.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of similar threats.
+- Educate users on the risks of downloading files from untrusted sources and the importance of verifying file origins.
+- Review and update security policies to include hardening measures such as application whitelisting and restricting the execution of files with suspicious extensions."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
index 2eecbdb9c35..6437782436f 100644
--- a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
+++ b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,53 @@ sequence with maxspan=1m
                    "*Common\\..\\..\\BuildTools\\*"))
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution via MS VisualStudio Pre/Post Build Events
+
+Microsoft Visual Studio allows developers to automate tasks using pre/post build events, which execute commands during the build process. Adversaries can exploit this by injecting malicious commands into these events, executing them under the guise of legitimate development activities. The detection rule identifies suspicious command executions linked to Visual Studio builds, focusing on unusual parent-child process relationships and command arguments, while excluding known benign patterns, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific process and parent process involved, focusing on `process.name`, `process.parent.name`, and `process.args` fields to identify the command executed and its context.
+- Examine the `process.entity_id` and `process.parent.entity_id` to trace the process lineage and determine if there are any unusual or unexpected parent-child relationships.
+- Check the `process.command_line` for any suspicious or unexpected command arguments that could indicate malicious activity.
+- Investigate the file path in `process.args` to verify if it matches known temporary file patterns or if it appears suspicious, such as residing in unusual directories.
+- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes executed by MSBuild.exe:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'MSBuild.exe');
+  ```
+- Analyze the execution history of the involved processes by reviewing logs or using endpoint detection tools to identify any patterns or anomalies in their behavior.
+- Cross-reference the involved executable paths against known good or whitelisted paths to identify any deviations that could suggest tampering or unauthorized modifications.
+- Investigate the user account associated with the process execution to determine if it aligns with expected usage patterns or if it could be compromised.
+- Review any recent changes or commits to the Visual Studio project files to identify potential unauthorized modifications to pre/post build events.
+- Correlate the alert with other security events or alerts in the environment to identify if this is part of a broader attack campaign or isolated incident.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate development activities where Visual Studio projects use pre/post build events for automation, such as running scripts for deployment or configuration tasks.
+- Developers often use scripts like PowerShell or batch files in build events for tasks like copying files, setting environment variables, or generating resources, which can trigger the detection rule.
+- Frequent non-threatening behaviors include executing scripts related to version control operations, package management, or custom build tools that are part of the development workflow.
+- Users can handle these false positives by creating exceptions for specific command patterns or script paths that are known to be safe and part of the regular build process.
+- Excluding known benign patterns, such as those involving common development tools or scripts, can reduce noise and focus on truly suspicious activities.
+- It's important to regularly review and update the list of exceptions to ensure that new legitimate activities are not mistakenly flagged as threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on the Visual Studio project files and build scripts for unauthorized modifications.
+- Review and analyze the process execution logs to trace the origin of the malicious commands and identify any additional compromised systems.
+- Remove any unauthorized or suspicious pre/post build event scripts from the Visual Studio projects and restore them from a known good backup if necessary.
+- Apply patches and updates to Visual Studio and related development tools to mitigate any known vulnerabilities that could be exploited.
+- Implement strict access controls and permissions for Visual Studio projects to limit the ability to modify build scripts to authorized personnel only.
+- Enhance logging and monitoring by enabling detailed process creation and command-line logging to detect similar activities in the future.
+- Integrate security tools with SIEM solutions to correlate alerts and automate responses to suspicious activities related to build processes.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate developers and IT staff on secure coding practices and the risks associated with build process manipulation to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_file_permission_modification.toml b/rules_building_block/defense_evasion_file_permission_modification.toml
index f58bdff58c1..de6fd0901ba 100644
--- a/rules_building_block/defense_evasion_file_permission_modification.toml
+++ b/rules_building_block/defense_evasion_file_permission_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,49 @@ not (
   process.args : ("C:\\ProgramData\\Lenovo\\*", "C:\\ProgramData\\Adobe\\*", "C:\\ProgramData\\ASUS\\ASUS*")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File and Directory Permissions Modification
+
+File and directory permissions in Windows environments control access and modification rights, crucial for maintaining system integrity. Adversaries exploit utilities like `icacls`, `cacls`, `takeown`, and `attrib` to alter permissions, enabling unauthorized file access or deletion. The detection rule identifies suspicious permission changes by monitoring these utilities' execution, filtering out benign processes, and focusing on potential threats, excluding known safe operations.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
+- Check the user context by examining the `user.id` field to determine if the action was performed by a legitimate user or a potential adversary.
+- Investigate the parent process using `process.parent.name` to understand the origin of the suspicious process execution.
+- Correlate the timestamp of the event with other security events to identify any related activities or anomalies around the same time.
+- Use Osquery to list recent file permission changes on the system with a query like: `SELECT path, mode, uid, gid FROM file WHERE path LIKE 'C:\\\\%' AND mode != '0644';` to identify unauthorized modifications.
+- Examine the command line arguments (`process.args`) for any unusual or unauthorized permission changes, such as granting full control (`*:F`) or resetting permissions.
+- Verify if the file or directory targeted by the permission change is critical or sensitive, which could indicate a higher risk.
+- Check for any exclusions in the query, such as known safe operations, to ensure the alert is not a false positive.
+- Investigate the system's recent login history and user activity to identify any unauthorized access attempts.
+- Review historical data for similar alerts on the same host to determine if this is part of a recurring pattern or isolated incident.
+
+### False positive analysis
+
+- Routine administrative tasks often trigger the execution of utilities like `icacls`, `cacls`, `takeown`, and `attrib`, leading to false positives. For instance, system administrators may use these tools to manage permissions during software installations or updates.
+- Automated scripts or system management tools from trusted vendors, such as Lenovo, Adobe, or ASUS, may execute these utilities as part of their normal operations, which can be safely excluded from alerts.
+- To manage these false positives, users can create exceptions by excluding specific processes or directories known to be safe, such as those related to trusted software vendors or internal IT scripts.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new trusted processes or directories that may have been added.
+- Consider implementing a whitelist approach for known safe operations, allowing only specific, verified processes to execute these utilities without triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
+- Conduct a thorough investigation to determine the scope of the permissions modification, identifying all affected files and directories.
+- Review system logs and security events to trace the origin of the suspicious activity, focusing on the execution of utilities like `icacls`, `cacls`, `takeown`, and `attrib`.
+- Verify the legitimacy of the user account involved in the permission changes and reset credentials if necessary to prevent further unauthorized access.
+- Restore original file and directory permissions from backups or use system restore points to revert changes, ensuring system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is determined to be part of a larger attack or if sensitive data is involved.
+- Implement enhanced logging policies to capture detailed information on file and directory permission changes, including user actions and process executions.
+- Integrate security solutions such as endpoint detection and response (EDR) tools to monitor and alert on suspicious permission changes in real-time.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
+- Apply hardening measures by restricting the use of permission-altering utilities to authorized personnel only and implementing least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_generic_deletion.toml b/rules_building_block/defense_evasion_generic_deletion.toml
index 845c9e5546e..4b59dc4b229 100644
--- a/rules_building_block/defense_evasion_generic_deletion.toml
+++ b/rules_building_block/defense_evasion_generic_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,48 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name: "powershell.exe" and process.args: ("*rmdir", "rm", "rd", "*Remove-Item*", "del", "*]::Delete(*"))
 ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 File or Directory Deletion Command
+
+In Windows environments, commands like `rundll32.exe`, `reg.exe`, `cmd.exe`, and `powershell.exe` are integral for system management, allowing users to delete files or directories. However, adversaries exploit these to erase logs or malware traces, hindering forensic analysis. The detection rule identifies suspicious deletions by monitoring these command executions, excluding benign paths, and flagging non-system user activities, thus highlighting potential malicious actions.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on `process.name` and `process.args` fields.
+- Check the `user.id` field to determine which user account executed the command and assess if this account has a history of suspicious activity.
+- Investigate the parent process of the flagged command using the `process.parent.name` and `process.parent.args` fields to understand the context in which the deletion command was executed.
+- Examine the timestamp of the event to correlate with other activities on the system, such as logins or other process executions, to identify any patterns or anomalies.
+- Use Osquery to list recent file deletions on the system with a query like: `SELECT * FROM file_events WHERE action = 'DELETE' AND datetime >= 'YYYY-MM-DD HH:MM:SS';` to gather more context around the deletion activity.
+- Cross-reference the paths in `process.args` with known benign paths to ensure the exclusion list is comprehensive and verify if any new paths should be considered suspicious.
+- Analyze the network activity around the time of the event to identify any potential data exfiltration attempts or connections to known malicious IPs.
+- Review system logs for any other suspicious activities or errors that occurred around the same time as the deletion command execution.
+- Check for any recent changes in system configurations or installed software that might explain the use of deletion commands.
+- Investigate the presence of any known malware or indicators of compromise on the system using threat intelligence sources and compare them with the command arguments and user activity.
+
+### False positive analysis
+
+- Routine system maintenance tasks or software updates may trigger the rule, as they often involve deleting temporary files or old logs, which can be mistaken for malicious activity.
+- Automated scripts or scheduled tasks that clean up directories or manage file storage can also be flagged, especially if they use command-line tools like `cmd.exe` or `powershell.exe`.
+- Users can manage these false positives by creating exceptions for known benign processes or paths, such as excluding specific user accounts or directories frequently involved in legitimate deletions.
+- It's important to regularly review and update the exclusion list to ensure that new legitimate activities are not mistakenly flagged, while still maintaining the integrity of the detection rule against genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
+- Conduct a thorough investigation to identify the scope of the deletion, focusing on critical files such as logs, browser history, or potential malware traces.
+- Utilize forensic tools to recover deleted files if possible, and analyze them for indicators of compromise or further malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team if the deletion is linked to a broader attack or if sensitive data is involved.
+- Implement enhanced logging policies to capture detailed command execution and file access activities, ensuring that future deletions are detected promptly.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and correlate with known threat actor behaviors.
+- Restore the system to its operational state by reinstalling affected applications and restoring data from verified backups.
+- Apply system hardening measures, such as restricting the use of command-line tools to authorized personnel and implementing application whitelisting.
+- Review and update security policies and procedures to address gaps identified during the investigation and ensure compliance with best practices.
+- Conduct a post-incident review to learn from the event, improve response strategies, and prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
index 68ad590b53a..ca67a27d2a2 100644
--- a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
+++ b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,51 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.parent.name : ("pcalua.exe", "forfiles.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Indirect Command Execution via Forfiles/Pcalua
+
+Forfiles and pcalua.exe are legitimate Windows utilities. Forfiles is used for batch processing files, while pcalua.exe is part of the Program Compatibility Assistant, aiding in application compatibility. Adversaries exploit these tools to execute commands indirectly, bypassing security controls. The detection rule identifies suspicious activity by monitoring process initiations with these utilities as parents, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of "pcalua.exe" or "forfiles.exe" as the parent process in the event logs.
+- Examine the command line arguments used with "pcalua.exe" or "forfiles.exe" to identify any suspicious or unexpected commands being executed.
+- Check the user account associated with the process initiation to determine if it aligns with expected behavior or if it might be compromised.
+- Investigate the child processes spawned by "pcalua.exe" or "forfiles.exe" to identify any potentially malicious activities or anomalies.
+- Utilize Osquery to gather additional context on the processes. For example, run the following query to list processes with "pcalua.exe" or "forfiles.exe" as the parent:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name IN ('pcalua.exe', 'forfiles.exe'));
+  ```
+- Analyze the file paths and locations associated with the executed commands to determine if they are legitimate or potentially harmful.
+- Cross-reference the event timestamp with other security logs (e.g., network, authentication) to identify any correlated suspicious activities.
+- Investigate any recent changes to the system or software installations that might have triggered the use of these utilities.
+- Check for any known vulnerabilities or exploits related to the applications or scripts executed via "pcalua.exe" or "forfiles.exe".
+- Document findings and gather evidence to support further analysis or escalation if necessary.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use forfiles.exe for legitimate batch processing tasks, such as file cleanup or automated maintenance scripts. These activities can trigger the detection rule but are typically non-threatening.
+- Software installations and updates: pcalua.exe is frequently invoked during legitimate software installations or updates to ensure compatibility, which can be mistakenly flagged as suspicious activity.
+- Automated scripts: Some organizations use automated scripts that leverage forfiles.exe for file management across multiple systems, which can lead to false positives if these scripts are not accounted for in the detection logic.
+- To manage false positives, users can create exceptions for known benign activities by whitelisting specific scripts or processes that regularly use forfiles.exe or pcalua.exe. This can be done by adding conditions to the detection rule to exclude these known processes or by using a centralized management system to maintain a list of approved activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to determine the scope of the incident, focusing on identifying any additional compromised systems or accounts.
+- Review the process execution logs to confirm the misuse of forfiles.exe or pcalua.exe and identify any commands executed indirectly.
+- Terminate any malicious processes identified during the investigation to halt ongoing threats.
+- Remove any unauthorized or malicious files and restore any altered system configurations to their original state.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the adversary.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate related events.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
+- Educate users on recognizing and reporting suspicious activities to prevent future incidents and reinforce security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_injection_from_msoffice.toml b/rules_building_block/defense_evasion_injection_from_msoffice.toml
index 6d1c96172e8..6dcbf018ffd 100644
--- a/rules_building_block/defense_evasion_injection_from_msoffice.toml
+++ b/rules_building_block/defense_evasion_injection_from_msoffice.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,49 @@ process where host.os.type == "windows" and event.action == "start" and
     "?:\\Windows\\Sys*\\ctfmon.exe",
     "?:\\Windows\\System32\\notepad.exe")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Process Injection from Malicious Document
+
+Microsoft Office applications are often targeted by adversaries who exploit vulnerabilities or use malicious macros to execute unauthorized code. This can lead to process injection, where malicious code is executed within legitimate processes, evading detection. The detection rule identifies unusual child processes spawned by Office apps, focusing on atypical arguments and paths, to flag potential injection attempts. By monitoring these anomalies, the rule helps in identifying and mitigating threats associated with process injection tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the parent process is one of the targeted Microsoft Office applications: excel.exe, powerpnt.exe, or winword.exe.
+- Examine the child process executable path to verify if it matches the suspicious paths: "?:\\\\Windows\\\\SysWOW64\\\\*.exe" or "?:\\\\Windows\\\\system32\\\\*.exe".
+- Check the process arguments count to ensure it is exactly one, as specified in the detection rule.
+- Investigate the process code signature to determine if it is untrusted or if the subject name does not start with "Microsoft".
+- Cross-reference the child process executable against known legitimate processes to rule out false positives, focusing on exclusions like Taskmgr.exe, ctfmon.exe, and notepad.exe.
+- Use Osquery to gather additional context about the suspicious process. Example query: `SELECT * FROM processes WHERE name = '<suspicious_process_name>' AND path LIKE 'C:\\\\Windows\\\\SysWOW64\\\\%' OR path LIKE 'C:\\\\Windows\\\\system32\\\\%';`
+- Analyze the parent process's recent activity, including any network connections or file modifications, to identify potential malicious behavior.
+- Review the document or macro that initiated the Office application to identify any embedded scripts or suspicious content.
+- Check for any recent patches or vulnerabilities related to the Office application version in use, which might have been exploited.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Known false positives may include legitimate applications or scripts that are executed with minimal arguments from Office applications, such as internal automation tools or scripts used by IT departments for maintenance tasks.
+- System administrators might run diagnostic or monitoring tools that match the rule's criteria, especially if these tools are executed from common system directories like SysWOW64 or system32.
+- Users can handle these false positives by creating exceptions for specific processes that are known to be safe and frequently triggered, such as internal scripts or tools that have been verified and are necessary for business operations.
+- To manage false positives, users can refine the detection rule by adding exclusions for specific executable paths or process names that are consistently identified as non-threatening, ensuring these are well-documented and reviewed regularly to maintain security integrity.
+- It is important to monitor the frequency and context of these alerts to distinguish between benign and potentially malicious activities, adjusting the rule's parameters as needed to reduce noise without compromising detection capabilities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Analyze the suspicious process and its parent Office application to confirm if it is indeed a malicious activity.
+- Terminate any identified malicious processes and remove any associated files or executables from the system.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to ensure no other threats are present.
+- Review and collect relevant logs, including process creation and network activity, to understand the scope and impact of the incident.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network connections for future incidents.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
+- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied.
+- Apply hardening measures such as disabling macros by default in Office applications and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_installutil_command_activity.toml b/rules_building_block/defense_evasion_installutil_command_activity.toml
index f0718951b7f..17279604699 100644
--- a/rules_building_block/defense_evasion_installutil_command_activity.toml
+++ b/rules_building_block/defense_evasion_installutil_command_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,49 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name : "installutil.exe" and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Activity
+
+InstallUtil is a legitimate Windows utility used for installing and uninstalling .NET applications by executing installer components. However, adversaries can exploit it to execute malicious code under the guise of a trusted process, bypassing security measures. The detection rule identifies suspicious InstallUtil activity by monitoring process starts on Windows systems, specifically flagging instances not initiated by the system account, which may indicate unauthorized use.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "installutil.exe" and verify the user ID is not "S-1-5-18" to ensure it matches the detection criteria.
+- Check the parent process of "installutil.exe" to determine how it was initiated and assess if the parent process is legitimate or suspicious.
+- Investigate the user account associated with the process start to determine if the activity aligns with their typical behavior or if the account may be compromised.
+- Examine the command-line arguments used with "installutil.exe" to identify any unusual or malicious parameters that could indicate misuse.
+- Correlate the timestamp of the InstallUtil activity with other security events or logs to identify any related suspicious activities or anomalies.
+- Use Osquery to gather additional context about the system state at the time of the alert. For example, run the following query to list recent processes executed by the same user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<suspicious_user>') ORDER BY start_time DESC LIMIT 10;`
+- Check for any recent changes to the system, such as new software installations or modifications to critical files, that could be associated with the InstallUtil activity.
+- Investigate network connections made by the system around the time of the alert to identify any unusual outbound traffic that could suggest data exfiltration or command-and-control communication.
+- Review historical data for any previous instances of InstallUtil activity on the same host or by the same user to identify patterns or repeated attempts.
+- Consult threat intelligence sources to determine if the observed InstallUtil activity matches known tactics, techniques, and procedures (TTPs) used by adversaries.
+
+### False positive analysis
+
+- Legitimate software installations: Some enterprise applications may use InstallUtil for legitimate installation processes, which could trigger the detection rule. Users should verify the source and context of the InstallUtil execution to determine if it is part of a sanctioned software deployment.
+- Developer activities: Developers might use InstallUtil during the development and testing of .NET applications. Organizations should consider excluding known developer machines or user accounts from the rule to reduce noise.
+- Automated scripts and maintenance tasks: Scheduled tasks or scripts that utilize InstallUtil for routine maintenance or updates can also be flagged. Users can create exceptions for these tasks by identifying the specific user accounts or scripts involved.
+- System administration tools: Certain administrative tools or scripts may leverage InstallUtil for legitimate purposes. Administrators should document and exclude these known tools from the detection rule to prevent false positives.
+- To manage false positives, users can create exceptions based on user accounts, specific hostnames, or known benign command-line arguments associated with InstallUtil executions. This approach helps maintain the effectiveness of the detection rule while minimizing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the InstallUtil activity by checking the source and context of the process initiation, focusing on user accounts and associated tasks.
+- Conduct a thorough investigation of the system to identify any additional indicators of compromise, such as unusual network connections or file modifications.
+- Review and analyze security logs to trace the origin and timeline of the malicious activity, ensuring that all related events are captured.
+- Remove any unauthorized or malicious software identified during the investigation, using trusted antivirus or endpoint detection and response tools.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning.
+- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that future suspicious activities are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze security events more effectively.
+- Escalate the incident to the appropriate internal or external cybersecurity teams if the scope of the attack is beyond initial containment and remediation efforts.
+- Apply system hardening measures, such as restricting the use of system utilities like InstallUtil to authorized users only, and regularly update security policies to mitigate similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
index 2017bffb2fb..d78e756d328 100644
--- a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
+++ b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,50 @@ library where host.os.type == "windows" and event.action == "load" and
     "?:\\Windows\\System32\\DriverStore\\FileRepository\\*"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Image Loaded with Invalid Signature
+
+In Windows environments, code signing ensures the integrity and authenticity of binaries. Adversaries may exploit this by loading binaries with invalid signatures to masquerade as legitimate software, evading detection. The detection rule identifies such anomalies by checking for invalid signatures, recent file modifications, and mismatches between DLL and process names, excluding trusted system paths. This helps in pinpointing potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which binary triggered the alert, focusing on the `dll.name` and `process.name` fields to identify potential mismatches.
+- Check the `dll.code_signature.status` field to determine the specific signature error, such as "errorUntrustedRoot" or "errorBadDigest," to assess the nature of the invalid signature.
+- Investigate the `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` fields to determine if the binary was recently created or modified, which could indicate suspicious activity.
+- Verify the `dll.path` to ensure it is not located in a trusted system path, as the rule excludes paths like "?:\\\\Windows\\\\System32\\\\DriverStore\\\\FileRepository\\\\*".
+- Use Osquery to gather additional context about the binary. For example, run the following query to list details about the binary: `SELECT path, sha256, signature_status FROM file WHERE path = '<dll.path>';`.
+- Cross-reference the hash of the binary (obtained from the Osquery result) with known threat intelligence databases to check for any known malicious activity.
+- Examine the parent process of the binary using the `process.name` field to understand the context in which the binary was loaded and identify any unusual parent-child process relationships.
+- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised.
+- Review recent system logs and events around the time the binary was loaded to identify any other suspicious activities or anomalies.
+- Consult with other security tools or logs to gather additional information about the network activity or other system changes that occurred around the time of the alert.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate software that uses self-signed certificates or certificates from less common certificate authorities, which may not be recognized by the system, leading to an "errorUntrustedRoot" status.
+- Software updates or patches can temporarily result in mismatches between DLL and process names, especially if the update process involves temporary files or renaming during installation.
+- Development or testing environments often load unsigned or self-signed binaries, which can trigger this rule due to the nature of the software being tested.
+- Users can manage these false positives by creating exceptions for known and trusted software that frequently triggers the rule, ensuring that these exceptions are well-documented and reviewed regularly to maintain security integrity.
+- Implementing a whitelist for specific paths or binaries that are known to be safe, even if they occasionally show invalid signatures, can help reduce noise in the detection system.
+- Regularly updating the list of trusted certificate authorities and ensuring that legitimate software is using up-to-date certificates can also help minimize false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious activity.
+- Verify the invalid signature by cross-referencing with known trusted certificates and check for any recent unauthorized changes to the system.
+- Conduct a thorough investigation to identify the source of the invalid binary, including reviewing recent file modifications and process execution logs.
+- Remove or quarantine the suspicious binary and any associated files to prevent execution.
+- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Restore the system using a clean backup or reinstall the operating system if necessary to ensure all malicious components are removed.
+- Implement enhanced logging policies to capture detailed information on file creation, modification, and execution events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Conduct a security audit of the system and network to identify and remediate any vulnerabilities that may have been exploited.
+- Educate users on recognizing and reporting suspicious activities to improve overall security awareness and reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_browsers.toml b/rules_building_block/defense_evasion_masquerading_browsers.toml
index 3ad0df05445..d18448e7409 100644
--- a/rules_building_block/defense_evasion_masquerading_browsers.toml
+++ b/rules_building_block/defense_evasion_masquerading_browsers.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -157,6 +157,52 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Masquerading as Browser Process
+
+Browsers are integral to accessing web content, often running with elevated privileges and trusted by users. Adversaries exploit this by masquerading malicious processes as legitimate browser processes to evade detection, bypass security measures, or deceive users. The detection rule identifies anomalies in browser processes, such as unexpected signatures or paths, to flag potential masquerading attempts, thereby enhancing security posture against such tactics.
+
+### Possible investigation steps
+
+- Review the process name and executable path to determine if it matches known legitimate browser paths or if it appears suspicious or unusual.
+- Check the process code signature details, including the subject name and trust status, to verify if the process is signed by a recognized and trusted entity.
+- Investigate the parent process to understand how the suspicious process was initiated and whether it was spawned by a legitimate application or a potentially malicious one.
+- Examine the command-line arguments used to start the process for any unusual or suspicious flags that might indicate malicious behavior.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list processes with their parent process and command-line arguments:
+  ```sql
+  SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('chrome.exe', 'msedge.exe', 'firefox.exe', 'brave.exe', 'opera.exe', 'whale.exe');
+  ```
+- Cross-reference the process executable path with known software installation directories to determine if the executable is located in an expected location.
+- Analyze recent system logs and events around the time the process was started to identify any related activities or anomalies.
+- Investigate the network connections established by the process to identify any suspicious or unexpected external communications.
+- Check for any recent changes to the system, such as software installations or updates, that might explain the presence of the process.
+- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process name or signature details.
+
+### False positive analysis
+
+- Legitimate software that uses browser processes for automation or testing, such as Selenium or Puppeteer, may trigger false positives. Users can handle these by adding exceptions for known automation tools in the detection rule.
+- Security software or monitoring tools that utilize browser processes for sandboxing or analysis, like HP Sure Click or Dynatrace, may be flagged. Users should exclude these processes by verifying their code signatures and adding them to an allowlist.
+- Custom or enterprise-specific applications that embed browser components might be misidentified. Users should ensure these applications are signed with trusted certificates and add them to exceptions if necessary.
+- Updates or beta versions of browsers that have not yet been recognized by the detection rule may cause false positives. Users can manage this by temporarily excluding these versions until the rule is updated.
+- Non-standard installations of browsers, such as portable versions, might not match expected paths or signatures. Users should verify the legitimacy of these installations and adjust the rule to accommodate them.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware.
+- Verify the legitimacy of the suspicious browser process by checking the process's executable path and code signature against known trusted sources.
+- Terminate any identified malicious processes to stop ongoing malicious activity.
+- Conduct a thorough investigation of the system to identify any additional indicators of compromise or persistence mechanisms.
+- Review and analyze system logs to trace the origin and timeline of the suspicious activity, leveraging MITRE ATT&CK framework for context on masquerading techniques.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Update and patch all software and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
+- Implement enhanced logging policies to capture detailed process execution and code signature verification for future incidents.
+- Integrate threat intelligence feeds and security solutions to improve detection capabilities and reduce response times.
+- Escalate the incident to the appropriate internal or external cybersecurity team if the threat level is beyond current handling capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
index 7df37c1057b..b8a42671c1f 100644
--- a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
+++ b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,49 @@ file where host.os.type == "windows" and event.action != "deletion" and
   not process.pid == 4 and
   not process.executable : "?:\\Program Files (x86)\\Trend Micro\\Client Server Security Agent\\Ntrtscan.exe"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Executable File with Unusual Extension
+
+Executable files are typically identified by specific extensions, but attackers may disguise them using extensions associated with benign file types like images or documents to evade detection. This detection rule identifies such anomalies by checking for executable headers in files with unexpected extensions, excluding known safe processes, thus highlighting potential masquerading attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file's extension and header bytes, ensuring they match the criteria specified in the detection rule (e.g., MZ header with unexpected extensions like jpg, mp3, etc.).
+- Check the file creation or modification timestamp to determine when the suspicious activity occurred and correlate it with other events on the system.
+- Identify the user account associated with the file creation or modification event to assess if the activity aligns with their typical behavior or role.
+- Investigate the parent process that created or modified the file by examining the process ID and executable path, ensuring it is not a known safe process like Ntrtscan.exe.
+- Use Osquery to gather additional context about the file and its associated process. For example, run the following query to list processes with the suspicious file as an argument: `SELECT * FROM processes WHERE path LIKE '%<suspicious_file_name>%'`.
+- Examine the file's metadata and properties, such as its size, hash, and digital signature, to determine if it matches known malicious files or legitimate software.
+- Search for any network connections or communications initiated by the process that created or modified the file to identify potential command and control activity.
+- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may be related.
+- Check for any recent changes in system configurations or installed software that could explain the presence of the executable file with an unusual extension.
+- Consult threat intelligence sources to determine if the file or its characteristics are associated with known malware campaigns or threat actors.
+
+### False positive analysis
+
+- Files with executable headers but benign extensions may be generated by legitimate software installations or updates, which often use temporary files with non-standard extensions during the process.
+- Some software development tools may create or modify files with executable headers and unexpected extensions as part of their normal operation, especially during compilation or packaging processes.
+- Security or system management tools might scan or modify files, resulting in temporary files with executable headers and non-standard extensions, which are not malicious.
+- Users can manage these false positives by creating exceptions for known safe processes or directories where such legitimate activities occur frequently.
+- Regularly review and update the list of excluded processes or directories to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Conduct a thorough investigation to identify the source and scope of the incident, focusing on the file's origin, associated processes, and any network connections.
+- Use endpoint detection and response (EDR) tools to analyze the behavior of the suspicious file and any related processes.
+- Remove or quarantine the suspicious file and any associated malicious software identified during the investigation.
+- Review and update antivirus and anti-malware signatures to ensure they can detect similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if additional expertise is required.
+- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on unusual file extensions and executable headers.
+- Integrate threat intelligence feeds to improve detection capabilities and provide context on known masquerading techniques and associated threat actors.
+- Restore the system to its operational state by applying clean backups and verifying the integrity of critical system files and applications.
+- Harden the system by applying security patches, disabling unnecessary services, and enforcing strict access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
index 63f9383bbda..3cb7e0f2082 100644
--- a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,49 @@ library where host.os.type == "windows" and event.action == "load" and
     and dll.code_signature.trusted == true
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Masquerading as VLC DLL
+
+Dynamic Link Libraries (DLLs) are crucial for modularizing code in Windows environments, allowing applications like VLC to function efficiently. Adversaries exploit this by crafting malicious DLLs with names mimicking legitimate VLC components, aiming to evade detection. The detection rule identifies such threats by flagging unsigned or improperly signed DLLs masquerading as VLC, focusing on specific filenames and verifying their digital signatures against trusted sources.
+
+### Possible investigation steps
+
+- Verify the alert details by checking the specific DLL name that triggered the alert, focusing on "libvlc.dll", "libvlccore.dll", or "axvlc.dll".
+- Confirm the digital signature status of the DLL by examining the `dll.code_signature.subject_name` and `dll.code_signature.trusted` fields to ensure they do not match trusted sources like "VideoLAN".
+- Use Osquery to list all loaded DLLs on the affected host and their signature status with a query such as: `SELECT path, name, signer FROM processes JOIN signature ON processes.path = signature.path WHERE name IN ('libvlc.dll', 'libvlccore.dll', 'axvlc.dll');`.
+- Investigate the file path and location of the suspicious DLL to determine if it resides in a directory typically used by VLC or if it is in an unusual location.
+- Check the file creation and modification timestamps of the DLL to identify any anomalies or recent changes that could indicate tampering.
+- Review the process that loaded the DLL by examining the `event.action` field to understand the context in which the DLL was used.
+- Analyze the parent process and any associated child processes of the application that loaded the DLL to identify any suspicious activity or process lineage.
+- Gather additional context by reviewing recent system logs and events around the time the DLL was loaded to identify any related activities or anomalies.
+- Cross-reference the hash of the suspicious DLL against known malware databases or threat intelligence sources to check for any known malicious indicators.
+- Consult with the user or system owner to verify if there have been any recent installations or updates that could explain the presence of the unsigned DLL.
+
+### False positive analysis
+
+- Some legitimate software may use custom or modified versions of VLC DLLs that are not signed by VideoLAN, leading to false positives. Users should verify the source and purpose of these DLLs before excluding them.
+- In corporate environments, IT departments might deploy VLC with custom configurations or additional plugins that are unsigned. Users can create exceptions for these known internal deployments by verifying their origin and ensuring they are part of the organization's standard software package.
+- Security tools or software that integrate VLC functionalities might include their own versions of VLC DLLs, which could trigger the rule. Users should confirm the legitimacy of these tools and whitelist them if they are verified as safe.
+- To manage false positives, users can maintain a list of known and trusted unsigned DLLs that are regularly used in their environment and configure the detection system to exclude these from alerts.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary DLLs are excluded, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Verify the legitimacy of the detected DLLs by checking their digital signatures and comparing them against known good signatures from VideoLAN.
+- Conduct a thorough investigation to identify any other systems that may have loaded the same or similar unsigned DLLs.
+- Remove any identified malicious DLLs and replace them with legitimate versions from a trusted source.
+- Perform a full system scan using updated antivirus and anti-malware tools to detect and remove any additional threats.
+- Review and update endpoint protection policies to ensure that only signed and trusted DLLs are allowed to load.
+- Implement enhanced logging policies to capture detailed DLL load events and code signature verification results for future investigations.
+- Integrate threat intelligence feeds to automatically update detection rules with the latest known malicious DLL signatures and behaviors.
+- Restore the system to its operational state by applying any necessary patches and updates, and verifying system integrity.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and stricter execution policies, to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_windows_dll.toml b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
index f64458b81cf..41927e72ae2 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -104,6 +104,55 @@ library where event.action == "load" and dll.Ext.relative_file_creation_time <=
       )
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Masquerading as System32 DLL
+
+System32 DLLs are critical components of Windows, providing essential functions for applications. Adversaries may exploit this by replacing or hijacking these DLLs to execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies by checking for unsigned or non-Microsoft signed DLLs, recent file creation, and specific DLL names, helping to uncover potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific DLL name and path that triggered the alert. Pay attention to the `dll.name` and `dll.path` fields.
+- Check the `dll.code_signature.subject_name` and `dll.code_signature.trusted` fields to determine if the DLL is signed by a trusted entity or if there are any anomalies in the signature.
+- Investigate the `dll.Ext.relative_file_creation_time` to understand how recently the DLL was created. A creation time within the last hour could indicate suspicious activity.
+- Use Osquery to list all DLLs loaded by the process that triggered the alert. Example query: `SELECT path, name, signed, sign_info FROM processes JOIN signature ON processes.path = signature.path WHERE name = '<process_name>';`
+- Examine the process that loaded the suspicious DLL using the `process.name` field. Determine if the process is legitimate and expected to load such DLLs.
+- Cross-reference the `dll.path` with known safe directories and check if it matches any of the excluded paths in the query to rule out false positives.
+- Investigate the parent process of the process that loaded the DLL to understand the process hierarchy and identify any unusual parent-child relationships.
+- Check for any recent changes or installations on the system that might have introduced the DLL, using system logs or software inventory tools.
+- Analyze network activity associated with the process to identify any suspicious connections or data exfiltration attempts.
+- Review historical data to determine if the same DLL or process has triggered alerts in the past, indicating a recurring issue or persistent threat.
+
+### False positive analysis
+
+- **Valve and Adobe Inc. DLLs**: The rule may flag `icuuc.dll` signed by Valve, Valve Corp., Avanquest Software, or Adobe Inc. as suspicious. These are known false positives and can be excluded by verifying the signature and adding exceptions for these trusted entities.
+- **VMware DLLs**: `timeSync.dll` and `appInfo.dll` signed by VMware Inc. or VMware, Inc. may trigger alerts. Users can handle these by confirming the signature and excluding these DLLs from the rule.
+- **NoMachine and Oculus VR DLLs**: `libcrypto.dll` signed by NoMachine S.a.r.l. or Oculus VR, LLC is a known false positive. Users should verify the signature and add exceptions for these trusted sources.
+- **Bitdefender DLLs**: `libcrypto.dll`, `wmi.dll`, `geolocation.dll`, and `kerberos.dll` signed by Bitdefender SRL may be flagged. These can be excluded by confirming the signature and adding them to the exception list.
+- **Paessler AG DLL**: `ICMP.dll` signed by Paessler AG is a known false positive. Users should verify the signature and exclude it from the rule.
+- **Adobe Inc. DirectML DLL**: `DirectML.dll` signed by Adobe Inc. may trigger alerts. Users can handle this by confirming the signature and excluding it.
+- **Dell Technologies DLL**: `icsvc.dll` signed by Dell Inc or Dell Technologies Inc. is a known false positive. Users should verify the signature and add exceptions for these trusted entities.
+- **Malwarebytes DLL**: `offreg.dll` signed by Malwarebytes Inc. may be flagged. Users can exclude this by confirming the signature and adding it to the exception list.
+- **Autodesk DLL**: `AppMgr.dll` signed by Autodesk, Inc is a known false positive. Users should verify the signature and exclude it.
+- **DismHost.exe Process**: DLLs like `SsShim.dll`, `Msi.dll`, and `wdscore.dll` in the `C:\\Windows\\Temp\\` directory when associated with the `DismHost.exe` process may trigger alerts. Users can exclude these by confirming the process and path context.
+- **Specific Paths**: DLLs located in paths such as `?:\\Windows\\SystemApps\\*\\dxgi.dll`, `?:\\Windows\\SystemApps\\*\\wincorlib.dll`, `?:\\Windows\\dxgi.dll`, and `?:\\Users\\*\\AppData\\Local\\LINE\\bin\\current\\dbghelp.dll` are known false positives. Users should verify the path and exclude these from the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Verify the legitimacy of the detected DLLs by checking their digital signatures and comparing them against known good versions.
+- Conduct a thorough investigation of recent file creation and modification activities to identify any unauthorized changes.
+- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) across the network.
+- Remove or replace any identified malicious or unauthorized DLLs with legitimate versions from a trusted source.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed information on DLL loads and process executions for future investigations.
+- Integrate threat intelligence feeds to stay updated on emerging threats and incorporate them into detection mechanisms.
+- Restore the system to its operational state by applying the latest security patches and updates to prevent exploitation of known vulnerabilities.
+- Harden the system by implementing application whitelisting, restricting administrative privileges, and ensuring regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
index 96aa94f8133..f66e05b473e 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,53 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Masquerading as System32 Executable
+
+System32 executables are critical components of Windows, often targeted by adversaries for masquerading attacks to evade detection. Attackers may replace or backdoor these executables with malicious versions, often altering their signatures. The detection rule identifies suspicious executions of these files by checking for non-Microsoft signatures or unsigned executables, while excluding known trusted exceptions, to flag potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the process name and executable path to confirm if it matches any known legitimate System32 executables or if it appears suspicious or out of place.
+- Check the process code signature status and subject name to determine if the executable is signed by a trusted Microsoft certificate or if it is unsigned or signed by a non-Microsoft entity.
+- Investigate the parent process to understand how the suspicious executable was launched and if it was initiated by a legitimate process or a potentially malicious one.
+- Examine the process creation time to see if it aligns with any known user activity or scheduled tasks, which might provide context for its execution.
+- Use Osquery to gather additional details about the process. For example, run the following query to check for any anomalies in the process's file attributes:
+  ```sql
+  SELECT * FROM processes WHERE name = 'suspicious_executable_name.exe';
+  ```
+- Analyze the network activity associated with the process to identify any unusual connections or data transfers that could indicate malicious behavior.
+- Check the file hash of the executable against known malware databases to see if it matches any known threats.
+- Review recent system changes or updates that might have affected the executable, such as software installations or patches, to determine if they could explain the signature anomaly.
+- Investigate any other alerts or logs from the same host around the time of the alert to identify potential patterns or related activities.
+- Consult threat intelligence sources to see if there are any known campaigns or techniques that match the observed behavior, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- **Git for Windows**: The rule may flag executables like `hostname.exe` and `find.exe` located in the Git for Windows installation path. Users can handle this by adding exceptions for these specific paths.
+- **Temporary Files**: Executables such as `taskkill.exe` in temporary directories may trigger alerts. Users should consider excluding these paths if they are part of legitimate processes.
+- **Windows Upgrade**: During Windows upgrades, executables like `ie4ushowIE.exe` in the `$WINDOWS.~BT` directory might be flagged. Users can exclude this path during known upgrade periods.
+- **Third-party Software**: Some third-party software, such as Axence nVision Agent, may use executables like `certutil.exe` that are flagged. Users should verify the software's legitimacy and add exceptions for these specific paths.
+- **Trusted Vendors**: Executables signed by trusted vendors like Wellbia.com Co., Ltd., Lenovo, HP Inc., Dell Inc., ImageMagick Studio LLC, Arctic Wolf Networks, Intel, Fortinet, and Cisco may be flagged. Users can add exceptions for these vendors if the signatures are verified as trusted.
+- **Custom Software**: Organizations using custom or less common software that mimics system32 executables should verify the software's legitimacy and add necessary exceptions to avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware.
+- Verify the legitimacy of the suspicious executable by checking its hash against known good versions or using a trusted source.
+- If the executable is confirmed malicious, remove or replace it with a clean version from a trusted source.
+- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or changes to system settings.
+- Review and analyze logs from the affected system and any associated network devices to trace the origin and scope of the attack.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is beyond the current team's capabilities.
+- Implement enhanced logging policies to capture detailed process execution and code signing events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security controls are functioning correctly.
+- Harden the system by implementing least privilege access, disabling unnecessary services, and ensuring all software is up to date to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
index 1c7efb230f7..ce9d8f444db 100644
--- a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
+++ b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,49 @@ process where host.os.type == "windows" and event.action == "start" and
     "ftp://*"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Troubleshooting Pack Cabinet Execution
+
+The Microsoft Diagnostic Wizard, often invoked via `msdt.exe`, is a legitimate tool used for troubleshooting and diagnostics in Windows environments. However, adversaries can exploit it to execute malicious files, particularly when these files are disguised as troubleshooting packs (`.diagcab`). The detection rule identifies unusual executions of `msdt.exe` from suspicious paths or with atypical parent processes, such as web browsers or email clients, which may indicate an attempt to misuse this tool for malicious purposes. By monitoring these specific conditions, the rule helps in identifying potential threats that leverage system binary proxy execution for defense evasion.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `msdt.exe` execution with `/cab` argument, ensuring it matches the suspicious criteria outlined in the detection rule.
+- Identify and document the parent process of `msdt.exe` from the alert, focusing on unusual parent processes such as web browsers or email clients, which may indicate a phishing attempt or drive-by download.
+- Examine the full command line arguments used in the `msdt.exe` execution to gather more context about the potential source and nature of the `.diagcab` file.
+- Investigate the file path from which the `.diagcab` file was executed, especially if it originates from user directories, network shares, or URLs, to assess the legitimacy of the file.
+- Use Osquery to list recent processes executed by the user associated with the alert to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspected_user') ORDER BY start_time DESC LIMIT 10;`
+- Check the network connections established by `msdt.exe` or its parent process to identify any suspicious outbound connections that may indicate data exfiltration or command and control communication.
+- Analyze the `.diagcab` file itself, if accessible, using static and dynamic analysis tools to determine if it contains any malicious payloads or scripts.
+- Review the security logs for any other alerts or events related to the same user or system around the time of the alert to identify potential patterns or additional indicators of compromise.
+- Investigate the user's email and web browsing history to determine if they interacted with any suspicious emails or websites that could have led to the execution of the `.diagcab` file.
+- Correlate the findings with threat intelligence sources to check if the observed behavior or indicators match any known threat actor tactics, techniques, or procedures.
+
+### False positive analysis
+
+- Legitimate troubleshooting activities: Users or IT administrators may legitimately use `msdt.exe` to open `.diagcab` files for troubleshooting purposes. If these activities are frequent and known to be safe, they can be excluded by creating exceptions for specific user accounts or paths.
+- Software updates and installations: Some software installations or updates might invoke `msdt.exe` as part of their process. Monitoring these activities and correlating them with known update schedules or installation logs can help identify and exclude these benign events.
+- Remote support tools: IT support tools that remotely troubleshoot or diagnose issues might trigger this rule. Identifying and excluding these tools by their parent process or specific command-line arguments can reduce false positives.
+- Custom scripts or automation: Organizations may have custom scripts or automation that utilize `msdt.exe` for legitimate purposes. Documenting these scripts and excluding their specific execution patterns can help manage false positives.
+- Frequent use by specific applications: If certain applications are known to frequently invoke `msdt.exe` in a non-malicious manner, consider excluding these applications by their parent process name or path to reduce noise in the detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation to identify the source of the diagcab file and determine if any other systems have been affected.
+- Analyze the process tree and command-line arguments to confirm the execution path and parent process, ensuring it aligns with the detection rule criteria.
+- If malicious activity is confirmed, remove any unauthorized diagcab files and associated malicious binaries from the system.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are at risk.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds to correlate detected activity with known threat actor tactics, techniques, and procedures (TTPs) related to MITRE ATT&CK T1218.
+- Educate users on the risks of opening files from untrusted sources, particularly those received via email or downloaded from the internet.
+- Apply system hardening measures, such as restricting the execution of diagcab files to trusted directories and implementing application whitelisting to prevent unauthorized software execution."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
index 2627af83080..b898930a60c 100644
--- a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
+++ b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/05"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,49 @@ sequence with maxspan=1m
     not process.name : "msiexec.exe" and
     not (process.executable : ("?:\\Program Files (x86)\\*.exe", "?:\\Program Files\\*.exe") and process.code_signature.trusted == true)]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows Installer with Suspicious Properties
+
+Windows Installer, a core component for application deployment on Windows, can be exploited by adversaries to bypass security measures. Attackers may misuse `msiexec.exe` to execute malicious MSI files, often sourced from archives like ZIP or RAR, or disguised with deceptive names. The detection rule identifies such activities by monitoring registry changes and process executions linked to `msiexec.exe`, flagging untrusted or unusual sources and executables.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific registry changes and process executions that triggered the alert, focusing on the `msiexec.exe` process and associated registry values like `InstallSource`, `DisplayName`, and `ProductName`.
+- Check the source of the MSI file by examining the `registry.data.strings` field to determine if it originated from a suspicious archive path, such as a ZIP, 7z, or RAR file in a user's temporary directory.
+- Investigate the parent process of `msiexec.exe` to identify how the installer was launched, ensuring it aligns with expected user or system behavior.
+- Verify the legitimacy of the executed process by checking its path and code signature status, especially if it is not located in the trusted `Program Files` directories.
+- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with `msiexec.exe` as the parent: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'msiexec.exe');`
+- Examine recent user activity on the host to identify any actions that might have led to the execution of the suspicious installer, such as downloading files from the internet or opening email attachments.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
+- Check for any network connections initiated by the suspicious process to determine if it is communicating with external or potentially malicious servers.
+- Review the system's application whitelisting policies to assess if there are any gaps or misconfigurations that could have allowed the execution of the suspicious installer.
+- Consult threat intelligence sources to determine if the suspicious installer or its components are associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they are executed from compressed archives or temporary directories, especially during software development or testing phases.
+- Automated deployment tools or scripts that utilize `msiexec.exe` to install software from network locations or temporary paths might be flagged as suspicious.
+- Users can manage these false positives by creating exceptions for known and trusted software sources, such as specific directories or network paths frequently used for legitimate installations.
+- Exclude processes with verified code signatures from trusted vendors to reduce false positives while maintaining security.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation to identify the source of the suspicious MSI file, checking for any unauthorized downloads or email attachments.
+- Review the registry changes and process execution logs to confirm the presence of malicious activity linked to msiexec.exe.
+- If malware is confirmed, use a trusted antivirus or endpoint detection and response (EDR) tool to remove the malicious files and any associated threats.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be cleaned effectively.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and registry changes, focusing on msiexec.exe activities.
+- Integrate threat intelligence feeds to improve detection capabilities and correlate with known indicators of compromise (IOCs) related to msiexec.exe abuse.
+- Educate users on the risks of downloading and executing files from untrusted sources, emphasizing the dangers of opening email attachments from unknown senders.
+- Apply system hardening measures, such as application whitelisting and restricting msiexec.exe execution to trusted sources only, to prevent future exploitation attempts."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_posh_defender_tampering.toml b/rules_building_block/defense_evasion_posh_defender_tampering.toml
index d512e623895..bb36b59fdc9 100644
--- a/rules_building_block/defense_evasion_posh_defender_tampering.toml
+++ b/rules_building_block/defense_evasion_posh_defender_tampering.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/09/11"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,6 +60,48 @@ event.category: "process" and host.os.type:windows and
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Windows Defender Tampering Capabilities
+
+PowerShell is a powerful scripting language in Windows environments, often used for automation and configuration. However, adversaries exploit its capabilities to disable Windows Defender features, reducing detection risks. The detection rule identifies scripts using specific cmdlets and parameters that modify Defender settings, signaling potential tampering attempts aimed at impairing system defenses.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious PowerShell activity, focusing on the `powershell.file.script_block_text` field for any of the specified cmdlets and parameters.
+- Check the `event.category` field to ensure the event is categorized as a "process" and verify the `host.os.type` is "windows" to confirm the environment context.
+- Investigate the user account associated with the PowerShell process to determine if it is a known or privileged account, which could indicate a higher risk if compromised.
+- Examine the process tree to identify the parent process of the PowerShell script, which may provide insights into how the script was executed and whether it was initiated by a legitimate application or a suspicious source.
+- Use Osquery to gather additional context on the PowerShell process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%Set-MpPreference%';` to identify all instances of PowerShell with similar command lines.
+- Analyze recent login events and user activity on the host to identify any unusual patterns or unauthorized access attempts that could correlate with the PowerShell activity.
+- Review the system's security logs for any other related events, such as changes to security settings or other tampering attempts, to build a timeline of suspicious activities.
+- Check for any network connections initiated by the PowerShell process to external IP addresses, which could indicate data exfiltration or command-and-control communication.
+- Investigate any file modifications or new files created around the time of the PowerShell execution to identify potential payloads or additional scripts dropped by the attacker.
+- Correlate the findings with threat intelligence sources to determine if the observed behavior matches known attack patterns or indicators of compromise associated with specific threat actors.
+
+### False positive analysis
+
+- Legitimate administrative scripts: System administrators may use PowerShell scripts to configure or troubleshoot Windows Defender settings as part of routine maintenance or system optimization. These scripts might include cmdlets and parameters that resemble tampering attempts.
+- Security software updates: Some security software or system updates might temporarily adjust Windows Defender settings to ensure compatibility or performance, triggering the detection rule.
+- Automated deployment tools: Tools used for automated deployment and configuration management might execute scripts that modify Defender settings, which could be mistaken for malicious activity.
+- To manage false positives, users can create exceptions for known legitimate scripts by whitelisting specific script paths or hashes. Additionally, monitoring the context of script execution, such as the user account and process lineage, can help differentiate between benign and malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further tampering or spread of malicious activities.
+- Conduct a thorough investigation of the PowerShell script execution logs to identify the source and scope of the tampering attempt.
+- Review and analyze Windows Event Logs, especially Security and PowerShell logs, to gather more context on the attack and identify any additional compromised systems.
+- Remove any unauthorized or malicious scripts and restore Windows Defender settings to their default state using the Set-MpPreference cmdlet.
+- Update all antivirus and endpoint protection signatures to ensure the latest threat intelligence is applied.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and module logging, to improve future detection capabilities.
+- Integrate security information and event management (SIEM) systems with threat intelligence feeds to enhance detection and response to similar threats.
+- Restore the system to its operational state by applying the latest security patches and updates, and verify that all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and restricting PowerShell execution policies, to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
index ed5067dbc9e..1181d955639 100644
--- a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
+++ b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ event.category:process and host.os.type:windows and
   ) and
   not file.directory : "C:\Program Files\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.Configuration"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Log Clear Capabilities
+
+PowerShell, a powerful scripting language in Windows, enables automation and configuration management. Adversaries exploit its capabilities to clear event logs, erasing traces of their activities to evade detection. The detection rule identifies suspicious PowerShell commands linked to log deletion, excluding benign scripts and known directories, thus highlighting potential malicious actions.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific PowerShell command or method triggered the detection, focusing on the `powershell.file.script_block_text` field.
+- Examine the `event.category:process` field to identify the process that executed the suspicious PowerShell command, noting the process ID and parent process ID for further context.
+- Check the `host.os.type:windows` field to confirm the operating system and ensure the alert pertains to a Windows environment.
+- Investigate the user account associated with the execution of the PowerShell script to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Analyze the execution context by reviewing the `file.directory` field to verify if the script was executed from a known or suspicious directory, excluding benign directories like "C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration".
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve details about the process that executed the PowerShell command.
+- Investigate recent login events for the user account involved to identify any unusual login patterns or anomalies that could suggest unauthorized access.
+- Review other security logs and alerts around the same timeframe to identify any correlated activities or additional indicators of compromise.
+- Check for any recent changes to system configurations or scheduled tasks that might have been used to facilitate the execution of the PowerShell script.
+- Document all findings and maintain a timeline of events to assist in understanding the scope and potential impact of the activity.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate administrative tasks where system administrators use PowerShell scripts to manage event logs as part of routine maintenance or troubleshooting. These activities might include clearing logs to free up space or reset logs after resolving issues.
+- Scripts executed from trusted directories, such as those used by Windows Admin Center, may trigger alerts if not properly excluded. Ensure that directories like "C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration" are added to exclusion lists to prevent unnecessary alerts.
+- To manage false positives, users can create exceptions for specific scripts or directories known to perform legitimate log management tasks. This can be done by updating the detection rule to exclude these benign activities, ensuring that only suspicious or unknown scripts trigger alerts.
+- Regularly review and update exclusion lists to reflect changes in administrative practices or new trusted scripts, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the attack, focusing on recent PowerShell activities and event log modifications.
+- Review and analyze other systems for similar PowerShell script executions to determine if the attack has spread.
+- Restore cleared event logs from backups if available to aid in forensic analysis and understanding of the attack timeline.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed PowerShell execution data, including script block logging and module logging.
+- Integrate with a security information and event management (SIEM) system to correlate and analyze PowerShell activities across the network.
+- Apply security patches and updates to the affected system to mitigate vulnerabilities exploited by the attacker.
+- Educate users and administrators on the risks of PowerShell misuse and enforce the principle of least privilege to limit script execution capabilities.
+- Consider deploying application whitelisting or PowerShell Constrained Language Mode to restrict unauthorized script execution."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
index c5e63bbb893..de8e08b4a67 100644
--- a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
+++ b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,49 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name : "* "
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Processes with Trailing Spaces
+
+In computing environments, process names are crucial for identifying and managing running applications. Adversaries exploit this by appending trailing spaces to process names, making them appear legitimate while evading detection. This tactic leverages the masquerading technique to bypass security measures. The detection rule identifies such anomalies by flagging processes with unexpected trailing spaces, thus uncovering potential evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of trailing spaces in the process name by examining the `process.name` field.
+- Cross-reference the `process.name` with known legitimate processes to identify any discrepancies or unusual patterns.
+- Investigate the `event.type` and `event.action` fields to understand the context of the process start event and confirm it aligns with typical execution patterns.
+- Check the parent process using the `process.parent.name` field to determine if the process was spawned by a legitimate or suspicious parent.
+- Utilize Osquery to gather additional context on the suspicious process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '% ';`
+- Examine the `process.executable` field to verify the file path and ensure it matches the expected location for legitimate processes.
+- Analyze the `user.name` field to identify the user account under which the process was executed, and assess if this aligns with normal user behavior.
+- Investigate any network connections or file modifications associated with the process using relevant logs or monitoring tools to identify potential malicious activity.
+- Review historical data for similar process names with trailing spaces to determine if this is part of a broader pattern or isolated incident.
+- Collaborate with other security teams or use threat intelligence sources to assess if the process name with trailing spaces is associated with known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Known false positives for the Processes with Trailing Spaces rule may include legitimate applications or scripts that unintentionally have trailing spaces in their process names due to coding errors or formatting issues.
+- System administrators and developers might create scripts or batch files with trailing spaces for testing purposes, which can trigger the detection rule.
+- To manage these false positives, users can create exceptions for specific processes that are known to be safe and frequently exhibit trailing spaces, ensuring they are not flagged by the detection rule.
+- Regularly review and update the list of exceptions to accommodate changes in legitimate software behavior while maintaining security vigilance.
+- Implement logging and monitoring to track the frequency and context of trailing space occurrences, helping to distinguish between benign and potentially malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on processes with trailing spaces and any associated files or network activity.
+- Terminate any suspicious processes identified with trailing spaces to halt any ongoing malicious activity.
+- Review and analyze system logs to trace the adversary's actions and identify any additional compromised systems or accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Implement enhanced logging policies to capture detailed process creation events, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for masquerading techniques.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary services, enforcing strong authentication mechanisms, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_service_disabled_registry.toml b/rules_building_block/defense_evasion_service_disabled_registry.toml
index c1f1d49dab7..9657068c3d5 100644
--- a/rules_building_block/defense_evasion_service_disabled_registry.toml
+++ b/rules_building_block/defense_evasion_service_disabled_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,49 @@ registry where host.os.type == "windows" and event.type == "change" and
     )
   and not registry.path : "HKLM\\SYSTEM\\ControlSet001\\Services\\MrxSmb10\\Start"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Service Disabled via Registry Modification
+
+Windows services are crucial for system operations, often configured via the registry. Adversaries may alter service start settings to disable security tools, evading detection. This detection rule identifies unauthorized registry changes to service start values, excluding legitimate modifications by services.exe. It focuses on changes indicating potential tampering, alerting analysts to possible defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path and data strings involved in the modification, focusing on paths like "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Services\\\\*\\\\Start".
+- Verify the process responsible for the registry change by examining the process name and user ID, ensuring it is not "services.exe" with user ID "S-1-5-18".
+- Check the event logs for any recent changes to the registry path "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Services\\\\*\\\\Start" to identify patterns or repeated attempts.
+- Investigate the user account associated with the registry change to determine if it has a history of suspicious activity or if it has been compromised.
+- Use Osquery to gather more information about the service in question. For example, run the query: `SELECT name, start_type, path FROM services WHERE name = '<ServiceName>';` to check the current configuration and status of the service.
+- Cross-reference the timestamp of the registry change with other security events or logs to identify any correlated activities, such as logins or file modifications.
+- Analyze the system for any other unauthorized registry changes or anomalies that might indicate broader tampering or compromise.
+- Investigate the network activity from the host around the time of the registry change to identify any suspicious outbound connections or data exfiltration attempts.
+- Review any recent software installations or updates on the host that might have inadvertently or maliciously altered service configurations.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware campaigns.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify service start settings, triggering the rule. Users can handle these by identifying the specific update processes and adding them to an exception list.
+- System administrators may intentionally change service configurations for maintenance or optimization purposes. To manage this, document and exclude these known administrative activities from triggering alerts.
+- Some third-party management tools might alter service start values as part of their normal operation. Users should verify these tools' behavior and exclude them if they are deemed non-threatening.
+- Automated scripts or scheduled tasks that modify service settings for legitimate reasons can also cause false positives. Users should review these scripts and tasks, ensuring they are authorized, and exclude them from detection.
+- In environments with custom security policies, certain service modifications might be routine. Users should map these policies and create exceptions for expected changes to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized changes or potential lateral movement by the adversary.
+- Conduct a thorough investigation to identify the process responsible for the registry modification, focusing on any suspicious processes other than services.exe.
+- Review recent changes in the registry and correlate them with known malicious patterns or behaviors using threat intelligence sources.
+- Restore the modified registry settings to their original state, ensuring that critical security and monitoring services are re-enabled.
+- Escalate the incident to the security operations center (SOC) or incident response team if the modification is linked to a known threat actor or campaign.
+- Implement enhanced logging policies to capture detailed registry changes and process activities, ensuring that future unauthorized modifications are detected promptly.
+- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
+- Conduct a security audit of the affected system to identify and remediate any other potential vulnerabilities or misconfigurations.
+- Educate users and administrators on the importance of maintaining secure configurations and monitoring for unauthorized changes.
+- Apply hardening measures, such as restricting registry access to authorized processes and users, to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_service_path_registry.toml b/rules_building_block/defense_evasion_service_path_registry.toml
index d8411c0a57f..53c35880bc7 100644
--- a/rules_building_block/defense_evasion_service_path_registry.toml
+++ b/rules_building_block/defense_evasion_service_path_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,49 @@ registry where host.os.type == "windows" and event.type == "change" and
     )
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Service Path Modification
+
+In Windows environments, services are crucial for running background processes. The service path, stored in the registry, dictates the executable a service runs. Adversaries may alter this path to execute malicious code, achieving persistence or privilege escalation. The detection rule identifies changes to service paths by monitoring registry modifications, excluding trusted executables, thus highlighting suspicious activity by unusual processes.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific registry path that was modified, focusing on the `registry.path` field to understand which service's executable path was altered.
+- Examine the `process.executable` field to determine the process responsible for the modification, noting any unusual or untrusted executables that do not match the excluded paths.
+- Check the `host.os.type` field to confirm the operating system is Windows, ensuring the context of the alert is accurate.
+- Investigate the parent process of the modifying executable to understand the process hierarchy and identify potential sources of compromise.
+- Use Osquery to list all services and their current executable paths to verify if other services have been similarly modified. Example query: `SELECT name, path FROM services WHERE path LIKE '%\\\\ImagePath';`
+- Cross-reference the timestamp of the registry change event with other logs, such as security or application logs, to identify any correlated suspicious activities.
+- Analyze recent user logins and account activities on the affected host to determine if the modification was performed by a legitimate user or through compromised credentials.
+- Investigate network connections from the host around the time of the modification to identify any unusual outbound or inbound connections that could indicate lateral movement or data exfiltration.
+- Review any recent software installations or updates on the host that could have inadvertently or maliciously altered the service path.
+- Check for any known vulnerabilities or exploits associated with the modified service or the process that made the change, which could provide further context on the attack vector used.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger service path modifications, as they often update registry entries to point to new or updated executables. Users can handle these by monitoring the update schedules of trusted software and creating exceptions for known update processes.
+- IT administrative tools or scripts that modify service paths for legitimate configuration changes can also be flagged. To manage this, users should identify and document these tools, then create exceptions for their associated processes.
+- Custom in-house applications that are not widely recognized may be flagged if they modify service paths during normal operations. Users should ensure these applications are signed and trusted, then add them to the exclusion list to prevent false positives.
+- Security software or endpoint protection solutions might modify service paths as part of their protective measures. Users should verify the legitimacy of these actions and exclude the corresponding processes if they are deemed safe.
+- During system maintenance or troubleshooting, administrators might manually change service paths, which could be flagged by the rule. Users should document these activities and temporarily disable the rule or add exceptions for the duration of the maintenance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the process that modified the service path, using endpoint detection and response (EDR) tools to trace the process lineage and identify any associated malicious files or activities.
+- Review recent changes in the registry and restore the service path to its original state using backup data or system restore points if available.
+- Scan the system with updated antivirus and anti-malware tools to detect and remove any additional threats that may have been introduced.
+- Escalate the incident to the security operations center (SOC) or incident response team if the modification is linked to a known threat actor or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
+- Integrate threat intelligence feeds to correlate the detected activity with known indicators of compromise (IOCs) and threat actor tactics, techniques, and procedures (TTPs).
+- Apply security patches and updates to the operating system and installed software to mitigate vulnerabilities that could be exploited for similar attacks.
+- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of maintaining strong security hygiene.
+- Consider deploying application whitelisting and enforcing least privilege principles to reduce the risk of unauthorized modifications to critical system components."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_services_exe_path.toml b/rules_building_block/defense_evasion_services_exe_path.toml
index f31ea296712..868b8a6b7ac 100644
--- a/rules_building_block/defense_evasion_services_exe_path.toml
+++ b/rules_building_block/defense_evasion_services_exe_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,48 @@ query = '''
 process where event.type == "start" and process.name : "sc.exe" and
   process.args : "*config*" and process.args : "*binPath*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Service Path Modification via sc.exe
+
+The `sc.exe` utility is a command-line tool used to manage Windows services, including configuring service paths. Adversaries may exploit this by altering service paths to execute malicious binaries, achieving persistence or privilege escalation. The detection rule identifies suspicious modifications by monitoring for `sc.exe` executions with specific arguments related to service configuration, signaling potential unauthorized changes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `sc.exe` execution with arguments containing `*config*` and `*binPath*`, indicating a service path modification attempt.
+- Correlate the timestamp of the `sc.exe` execution with other logs to identify any preceding or subsequent suspicious activities, such as file modifications or network connections.
+- Identify the user account associated with the `sc.exe` process execution to determine if it aligns with expected administrative activity or if it might be compromised.
+- Examine the parent process of `sc.exe` to understand how it was initiated, which could provide insights into whether the execution was automated or manually triggered.
+- Use Osquery to list all services and their current binary paths to identify any discrepancies or unexpected changes. Example query: `SELECT name, path FROM services WHERE path LIKE '%suspicious_binary%'`.
+- Investigate the modified service's purpose and typical behavior to assess the potential impact of the path change and whether it aligns with legitimate operations.
+- Check for any recent changes to the system's registry, particularly in areas related to service configurations, to identify unauthorized modifications.
+- Analyze network logs for any unusual outbound connections from the host around the time of the `sc.exe` execution, which might indicate data exfiltration or command-and-control activity.
+- Review historical logs for previous instances of `sc.exe` usage by the same user or on the same host to identify patterns or repeated attempts at service path modification.
+- Consult threat intelligence sources to determine if the modified service path or associated binary is linked to known malware or adversary techniques.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use `sc.exe` to legitimately modify service paths during maintenance or configuration changes. To manage these, users can create exceptions for known administrative accounts or specific time windows when such tasks are expected.  
+- Software updates: Some software installations or updates might modify service paths using `sc.exe` as part of their setup process. Users can exclude these by identifying and whitelisting the associated software update processes or vendors.  
+- Automated scripts: Organizations may have automated scripts that use `sc.exe` for service management. To handle these, users can exclude specific scripts or processes by their hash or command line patterns.  
+- Monitoring tools: Certain monitoring or management tools might invoke `sc.exe` for legitimate service checks or configurations. Users should identify these tools and create exceptions based on their known behavior or signatures.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify the scope of the compromise, focusing on recent changes to service paths and any unauthorized binaries.
+- Review system logs and security events to trace the origin of the `sc.exe` command execution and identify any associated user accounts or processes.
+- Restore the original service path configurations from backups or system documentation to ensure legitimate service operation.
+- Remove any unauthorized binaries or scripts that were introduced as part of the service path modification.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future monitoring.
+- Integrate endpoint detection and response (EDR) solutions to provide real-time alerts and automated responses to suspicious service modifications.
+- Conduct a security audit of all services and their configurations to identify and remediate any other potential vulnerabilities.
+- Apply system hardening measures, such as restricting administrative privileges and implementing application whitelisting, to prevent unauthorized service modifications in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
index 6928b4187a8..39c26822ed0 100644
--- a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
+++ b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,6 +68,49 @@ process where host.os.type == "windows" and event.action == "start" and
 
   not process.args : ("?:\\Program Files (x86)\\*", "?:\\Program Files\\*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Execution via MSIEXEC
+
+MSIEXEC is a Windows Installer utility used for installing, maintaining, and removing software. Adversaries exploit it to execute malicious MSI files, often bypassing security controls. The detection rule identifies unusual MSIEXEC activity by scrutinizing execution paths, parent processes, and command-line arguments, flagging deviations from typical usage patterns to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific conditions of the detection rule were met, focusing on the process name, parent process, and command-line arguments.
+- Examine the `process.parent.executable` field to identify the parent process that initiated `msiexec.exe`. Determine if this parent process is commonly associated with legitimate software installations.
+- Investigate the `process.args` field to analyze the command-line arguments used with `msiexec.exe`, paying particular attention to the presence of `/i`, `/q`, or `/quiet` flags, which may indicate silent installations.
+- Check the `process.args_count` to ensure it aligns with typical usage patterns. An unusual count may suggest additional, potentially malicious arguments.
+- Analyze the `process.working_directory` to verify if the execution path is consistent with standard software installation directories or if it points to suspicious locations.
+- Use Osquery to gather more context about the process and its parent. For example, run the following query to list processes with their parent details: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name = 'msiexec.exe';`
+- Investigate the `user.id` field to determine the user account under which `msiexec.exe` was executed. Check if this account has a history of performing software installations.
+- Cross-reference the `process.parent.name` with known legitimate processes like `explorer.exe` or `wmiprvse.exe` to assess if the parent process is expected or unusual.
+- Look into the `process.parent.command_line` length, especially if the parent process is `powershell.exe` or `cmd.exe`, to identify potentially obfuscated or complex command lines.
+- Review historical data for similar alerts involving the same `process.parent.executable` or `process.args` to identify patterns or repeated suspicious behavior.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they use msiexec.exe with command-line arguments that match the suspicious patterns, such as silent installations using "/q" or "/quiet" switches.
+- System administrators or automated deployment tools might use msiexec.exe to install software across multiple systems, which could be flagged if the parent process or execution path is unusual.
+- Custom scripts or third-party management tools that leverage msiexec.exe for software management tasks could be misidentified as malicious if they execute from non-standard directories or with uncommon parent processes.
+- To manage these false positives, users can create exceptions for known benign processes or paths by adding them to the exclusion list in the detection rule, ensuring that frequent non-threatening behaviors are not flagged.
+- Regularly review and update the exclusion list to accommodate changes in legitimate software deployment practices or new trusted applications that may trigger the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential threats.
+- Analyze the suspicious msiexec.exe process and its parent process to determine if it is part of a known attack pattern or a false positive.
+- Terminate any malicious processes identified during the investigation to stop ongoing malicious activity.
+- Review and collect relevant logs, including Windows Event Logs and security software logs, to gather evidence and understand the scope of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Remove any malicious MSI files and associated artifacts from the system to ensure complete remediation.
+- Restore the system from a known good backup if the integrity of the system is compromised.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities.
+- Apply system hardening measures, such as restricting the execution of msiexec.exe to authorized users and paths, to reduce the risk of similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unsigned_bits_client.toml b/rules_building_block/defense_evasion_unsigned_bits_client.toml
index 84012c3b2d4..f3abf25d95c 100644
--- a/rules_building_block/defense_evasion_unsigned_bits_client.toml
+++ b/rules_building_block/defense_evasion_unsigned_bits_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,49 @@ library where dll.name : "Bitsproxy.dll" and process.executable != null and
 not process.code_signature.trusted == true and
 not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unsigned BITS Service Client Process
+
+The Background Intelligent Transfer Service (BITS) is a Windows component that facilitates asynchronous, prioritized, and throttled transfer of files between machines. While beneficial for legitimate updates and data transfers, adversaries can exploit BITS to stealthily download or upload malicious payloads. The detection rule identifies suspicious BITS activity by flagging processes using the BITS library that lack a valid code signature, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of an unsigned BITS client process by checking the `process.executable` field for the specific executable path.
+- Verify the `dll.name` field to ensure that "Bitsproxy.dll" is indeed being used by the process, as this is a key indicator of BITS activity.
+- Examine the `process.code_signature.trusted` field to confirm that the process lacks a valid code signature, which is crucial for identifying potentially malicious activity.
+- Investigate the `process.code_signature.status` field to ensure that the status does not indicate a known error like "errorExpired" or "errorCode_endpoint*", which could explain the unsigned status.
+- Use Osquery to gather more information about the process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE path = '<process.executable>';` to retrieve details about the process execution.
+- Check the process's parent process ID and lineage to determine how the unsigned BITS client process was initiated, which can provide insights into potential compromise vectors.
+- Analyze network activity associated with the process to identify any suspicious data transfers or connections that could indicate malicious use of BITS.
+- Review recent file modifications and creations in directories associated with the process to detect any unauthorized changes or payloads.
+- Correlate the findings with other security alerts or logs to identify patterns or related activities that could suggest a broader attack campaign.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware families.
+
+### False positive analysis
+
+- Some legitimate software may use the BITS service without a valid code signature, especially older or custom-developed applications. These can trigger false positives if they are unsigned but not malicious.
+- System administrators should identify and document any known legitimate applications that use BITS and lack a valid code signature. These applications can be added to an exception list to prevent them from being flagged.
+- Regularly review and update the exception list to ensure it reflects the current environment and includes any new legitimate applications that may trigger the rule.
+- Consider the context of the flagged activity, such as the source and destination of the file transfers, to determine if the behavior aligns with expected and benign operations.
+- Collaborate with software vendors to verify the legitimacy of unsigned applications and encourage them to provide properly signed versions to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and data exfiltration.
+- Verify the unsigned BITS client process by checking the process details and associated files for any known malicious indicators.
+- Terminate the suspicious BITS process and remove any associated files that are identified as malicious.
+- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
+- Review system and security logs to trace the origin of the unsigned BITS process and identify any lateral movement or additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on BITS-related events.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of similar threats in the future.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all software is from trusted sources.
+- Harden the system by disabling unnecessary services, enforcing strict application whitelisting, and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unusual_process_extension.toml b/rules_building_block/defense_evasion_unusual_process_extension.toml
index 62072e9e4ed..356440873c5 100644
--- a/rules_building_block/defense_evasion_unusual_process_extension.toml
+++ b/rules_building_block/defense_evasion_unusual_process_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,48 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.name: "AGSRunner.bin" and process.code_signature.subject_name: "Intel Corporation")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process Extension
+
+In Windows environments, processes typically run with standard executable extensions like .exe or .com. Adversaries may exploit this by using non-standard extensions to disguise malicious executables, evading detection. The 'Unusual Process Extension' rule identifies such anomalies by flagging processes with atypical extensions, excluding known legitimate cases, thus highlighting potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the process name and executable path to determine if the extension is indeed unusual and not a false positive by checking against known legitimate cases.
+- Verify the process's code signature details, such as the subject name, to confirm if the process is signed by a trusted entity or if it lacks a valid signature.
+- Cross-reference the process name and executable path with threat intelligence sources to identify if they are associated with known malicious activities.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with unusual extensions: `SELECT pid, name, path, cmdline, cwd, uid, gid FROM processes WHERE path LIKE '%.%' AND path NOT LIKE '%.exe' AND path NOT LIKE '%.com' AND path NOT LIKE '%.scr' AND path NOT LIKE '%.tmp' AND path NOT LIKE '%.dat';`
+- Investigate the parent process of the flagged process to understand how it was spawned and if the parent process is legitimate.
+- Check the process's command line arguments for any suspicious or unexpected parameters that could indicate malicious behavior.
+- Analyze the process's network activity to identify any unusual or unauthorized connections that could suggest data exfiltration or command and control communication.
+- Examine the process's file creation and modification activities to detect any unauthorized changes to critical system files or directories.
+- Review system logs and security events around the time the process was started to identify any correlated suspicious activities or anomalies.
+- Consult with other team members or departments to gather additional insights or context about the process, especially if it is related to a specific application or business function.
+
+### False positive analysis
+
+- Certain legitimate processes may run with unusual extensions due to specific software requirements or configurations, such as those from Dell, Bloomberg LP, Adobe Inc., McAfee, LLC, The Document Foundation, Veeam Software Group GmbH, LLC 1C-Soft, and Intel Corporation. These are already accounted for in the rule's exceptions.
+- Users may encounter false positives from custom or proprietary software that uses non-standard extensions for executable files. In such cases, users should verify the legitimacy of the process and consider adding it to the exclusion list if it is deemed safe.
+- Processes related to software development or testing environments might also trigger false positives due to the use of unique or temporary extensions. Users should assess the context and, if necessary, exclude these processes to reduce noise.
+- To manage false positives, users can update the rule's exclusion list by adding specific process names or paths that are verified as non-threatening, ensuring that these are regularly reviewed and updated to maintain security integrity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware.
+- Conduct a thorough investigation of the flagged process to determine if it is indeed malicious, using tools like antivirus scans and behavioral analysis.
+- Review the process's parent-child relationship to identify any other potentially malicious processes or scripts that may have initiated the unusual process.
+- If confirmed malicious, terminate the process and delete any associated files or registry entries to prevent re-execution.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a larger attack.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent process information, to aid in future investigations.
+- Integrate threat intelligence feeds to correlate the unusual process with known threat actor tactics, techniques, and procedures (TTPs) for better context and response.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security software is up to date.
+- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
+- Implement hardening measures such as application whitelisting, disabling unnecessary services, and enforcing least privilege access to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
index f5ab763eba2..fac2f4d190a 100644
--- a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
+++ b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,48 @@ process where host.os.type == "windows" and event.type == "start" and
     "wmiprvse.exe"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process Execution on WBEM Path
+
+The Windows Management Instrumentation (WMI) is a core component for managing data and operations on Windows systems. It typically runs processes from the WBEM directory. Adversaries may exploit WMI to execute malicious processes under the guise of legitimate WMI activity, evading detection. The detection rule identifies non-standard processes executing from the WBEM path, flagging potential misuse by excluding known legitimate WMI executables.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process executable path and name that triggered the alert, focusing on the `process.executable` and `process.name` fields.
+- Verify the legitimacy of the process by checking the file hash against known good hashes or threat intelligence databases to identify any known malicious files.
+- Investigate the parent process using the `process.parent.name` and `process.parent.executable` fields to determine if the process was spawned by a legitimate or suspicious parent.
+- Examine the user context under which the process was executed using the `user.name` field to assess if the execution aligns with typical user behavior.
+- Check the process command line arguments with the `process.command_line` field to identify any suspicious or unusual parameters that may indicate malicious intent.
+- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes running from the WBEM directory: `SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE 'C:\\\\Windows\\\\System32\\\\wbem\\\\%' OR path LIKE 'C:\\\\Windows\\\\SysWow64\\\\wbem\\\\%';`
+- Investigate recent file modifications in the WBEM directory to identify any unauthorized changes or additions that could be related to the suspicious process.
+- Analyze network connections initiated by the process using network monitoring tools or logs to detect any unusual outbound connections that may indicate data exfiltration or command and control activity.
+- Review system logs for any related events or anomalies around the time of the process execution to gather additional context or identify other potentially related suspicious activities.
+- Consult with other security team members or stakeholders to determine if there are any ongoing investigations or incidents that might be related to the alert, ensuring a coordinated response.
+
+### False positive analysis
+
+- Some legitimate third-party applications may occasionally execute processes from the WBEM path for monitoring or management purposes, which could be flagged as unusual. Users should verify the legitimacy of these applications and consider adding them to an exclusion list if they are deemed safe.
+- System administrators might run custom scripts or tools that interact with WMI for system management tasks. These scripts could trigger the detection rule if they execute processes from the WBEM directory. To handle this, administrators can document and exclude these known scripts from the detection rule.
+- During software updates or installations, certain applications might temporarily execute processes from the WBEM path. Users should monitor these activities and, if they are part of a legitimate update process, add them to the exclusion list to prevent future false positives.
+- Security tools or monitoring solutions that integrate with WMI might also execute processes from the WBEM path as part of their normal operation. Users should identify these tools and exclude them from the detection rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the process by checking the process hash against known malware databases and reviewing the process's parent-child relationship.
+- Terminate any suspicious processes identified as running from the WBEM path that are not part of the known legitimate WMI executables.
+- Conduct a thorough investigation of the system to identify any additional indicators of compromise, such as unusual network connections or file modifications.
+- Review system and security logs to trace the origin of the malicious process execution and identify any potential persistence mechanisms.
+- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
+- Implement enhanced logging policies to capture detailed process execution and WMI activity for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for alerts.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if additional expertise is required.
+- Apply system hardening measures, such as restricting WMI access to authorized users and processes, and regularly updating and patching systems to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_write_dac_access.toml b/rules_building_block/defense_evasion_write_dac_access.toml
index de838caec6d..1cefc72efcf 100644
--- a/rules_building_block/defense_evasion_write_dac_access.toml
+++ b/rules_building_block/defense_evasion_write_dac_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,49 @@ query = '''
 host.os.type: "windows" and event.action : ("Directory Service Access" or "object-operation-performed") and
   event.code : "4662" and winlog.event_data.AccessMask:"0x40000"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WRITEDAC Access on Active Directory Object
+
+WRITEDAC permissions allow modification of an object's access control list in Active Directory, crucial for managing access rights. Adversaries exploit this by altering permissions to escalate privileges or maintain persistence. The detection rule identifies suspicious WRITEDAC activities by monitoring specific Windows event codes and access masks, signaling potential unauthorized access modifications.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event code "4662" and AccessMask "0x40000" to verify that the alert is related to WRITEDAC access.
+- Identify the user account associated with the WRITEDAC event by examining the event data fields such as `winlog.event_data.SubjectUserName` and `winlog.event_data.SubjectUserSid`.
+- Determine the target object of the WRITEDAC operation by reviewing `winlog.event_data.ObjectName` and `winlog.event_data.ObjectType` to understand what was potentially modified.
+- Check the timestamp of the event to establish a timeline and correlate it with other suspicious activities or alerts in the same timeframe.
+- Investigate the source machine from which the WRITEDAC operation was performed using `winlog.event_data.IpAddress` and `winlog.event_data.WorkstationName`.
+- Use Osquery to gather additional context on the involved user account and machine. For example, run the following query to list recent logins for the user: `SELECT * FROM logged_in_users WHERE user = '<username>';`.
+- Examine the user's recent activities and access patterns in Active Directory to identify any anomalies or deviations from their normal behavior.
+- Cross-reference the WRITEDAC event with other security logs and alerts to identify potential lateral movement or privilege escalation attempts.
+- Review the access control list (ACL) changes on the target object to determine what specific permissions were altered and assess the potential impact.
+- Consult with relevant stakeholders or system owners to verify if the WRITEDAC operation was authorized or part of a legitimate administrative task.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate system administrators may perform WRITEDAC operations as part of their regular duties, such as updating permissions for user accounts or groups. These actions can be excluded by creating exceptions for known administrator accounts or specific times when these tasks are scheduled.
+- Automated scripts and tools: Some organizations use automated scripts or third-party tools to manage Active Directory permissions, which may trigger the WRITEDAC rule. Users can handle these by identifying and excluding the specific scripts or tools from the detection rule.
+- Software updates and installations: Certain software updates or installations may require temporary changes to access control lists, resulting in WRITEDAC events. Users should monitor and document these activities, creating exceptions for known software processes or during maintenance windows.
+- Group policy updates: Changes to group policies can sometimes involve WRITEDAC operations. Users can manage these by correlating the events with scheduled group policy updates and excluding them from the detection rule.
+- Service account activities: Service accounts with legitimate access to modify permissions may trigger false positives. Users should identify these accounts and exclude their activities from the rule, ensuring they are monitored separately for any unusual behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Review the event logs, specifically Windows Event ID 4662, to identify the source of the WRITEDAC access and any associated accounts or systems.
+- Verify the integrity of the access control lists (ACLs) on the affected Active Directory objects and revert any unauthorized changes.
+- Conduct a thorough investigation to determine if any other systems or accounts have been compromised, focusing on privilege escalation and persistence techniques.
+- Reset passwords and review permissions for any accounts involved in the incident to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed access and modification events in Active Directory for future investigations.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze security events across the network.
+- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are installed.
+- Harden the Active Directory environment by applying least privilege principles, regularly reviewing permissions, and conducting security awareness training for administrators."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_capnetraw_capability.toml b/rules_building_block/discovery_capnetraw_capability.toml
index 7fd2ca5a2a7..98be470a1aa 100644
--- a/rules_building_block/discovery_capnetraw_capability.toml
+++ b/rules_building_block/discovery_capnetraw_capability.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/01/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,48 @@ event.category:"process" and host.os.type:"linux" and event.type:"start" and eve
 (process.thread.capabilities.effective:"CAP_NET_RAW" or process.thread.capabilities.permitted:"CAP_NET_RAW") and
 not user.id:"0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Network Traffic Capture via CAP_NET_RAW
+
+CAP_NET_RAW is a Linux capability that allows processes to create raw sockets, enabling them to capture and manipulate network traffic. While useful for legitimate network diagnostics, adversaries can exploit it to intercept data, bypass controls, or tamper with communications. The detection rule identifies non-root processes with this capability, flagging potential unauthorized network sniffing activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and user ID associated with the CAP_NET_RAW capability, focusing on the `process.name` and `user.id` fields.
+- Verify the legitimacy of the process by checking the process's path and hash against known good software inventories or threat intelligence databases.
+- Investigate the user account (`user.id`) that initiated the process to determine if it is a legitimate user or potentially compromised.
+- Use Osquery to list all processes with CAP_NET_RAW capabilities by executing: `SELECT pid, name, path FROM processes WHERE capabilities LIKE '%CAP_NET_RAW%';` to identify any other suspicious processes.
+- Examine the command line arguments (`process.command_line`) used to start the process for any unusual or suspicious parameters that might indicate malicious intent.
+- Check the parent process (`process.parent.name`) to understand the process hierarchy and determine if the process was spawned by a legitimate application or a potentially malicious one.
+- Analyze recent login events for the user account in question to identify any unusual login times or sources that could indicate unauthorized access.
+- Review network connections initiated by the process using tools like `netstat` or `ss` to identify any suspicious external communications.
+- Correlate the event with other security logs, such as firewall or intrusion detection system logs, to identify any related suspicious activities or anomalies.
+- Investigate the host's network configuration and firewall settings to ensure that they are properly configured to prevent unauthorized network traffic capture and manipulation.
+
+### False positive analysis
+
+- Legitimate network diagnostic tools: Some network diagnostic tools used by system administrators or network engineers may require CAP_NET_RAW capabilities to function correctly. These tools, while non-root, are not malicious and should be reviewed to determine if they are part of regular network maintenance activities. Users can handle these by creating exceptions for known diagnostic tools that are frequently used in their environment.
+- Containerized applications: In environments using containerization, certain applications may be granted CAP_NET_RAW capabilities to manage network traffic within the container. These applications should be verified to ensure they are part of the expected container setup. Users can exclude these applications by identifying and documenting the containers that require such capabilities for legitimate purposes.
+- Security monitoring tools: Some security tools designed to monitor network traffic for anomalies may also require CAP_NET_RAW capabilities. These tools should be assessed to confirm they are part of the organization's security infrastructure. Users can manage these by maintaining an updated list of approved security tools and excluding them from the detection rule.
+- Development and testing environments: Developers may use CAP_NET_RAW capabilities in non-production environments for testing network-related features. These activities should be monitored to ensure they do not inadvertently transition to production environments. Users can handle these by setting up separate rules or exceptions for development and testing environments, ensuring they are clearly distinguished from production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to identify the process and user associated with the CAP_NET_RAW capability, focusing on non-root users.
+- Review system logs and network traffic to determine the scope of the activity and identify any other potentially compromised systems.
+- Terminate any unauthorized processes identified during the investigation that are using CAP_NET_RAW capabilities.
+- Change credentials and review user permissions for any accounts involved in the incident to prevent further misuse.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack.
+- Implement enhanced logging and monitoring for network traffic and process execution to detect similar activities in the future.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection and response capabilities for network sniffing and related tactics.
+- Restore the system to its operational state by applying patches, updating configurations, and ensuring all security controls are in place.
+- Harden the system by reviewing and restricting capabilities like CAP_NET_RAW to only trusted processes and users, and ensure firewalls are configured to limit packet types and contents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_account_groups.toml b/rules_building_block/discovery_generic_account_groups.toml
index eb8dadcd502..e6b1c3fd522 100644
--- a/rules_building_block/discovery_generic_account_groups.toml
+++ b/rules_building_block/discovery_generic_account_groups.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,48 @@ process where host.os.type == "windows" and event.type == "start" and
 ) and not process.parent.args: "C:\\Program Files (x86)\\Microsoft Intune Management Extension\\Content\\DetectionScripts\\*.ps1"
 and not process.parent.name : "LTSVC.exe" and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows Account or Group Discovery
+
+Windows environments utilize built-in tools to manage and query user and group information, essential for system administration. Adversaries exploit these tools to gather intelligence on user accounts and group memberships, aiding in privilege escalation and lateral movement. The detection rule identifies suspicious use of these tools by monitoring specific command executions and arguments, filtering out benign activities to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command and arguments that triggered the rule, focusing on the `process.name` and `process.args` fields.
+- Check the `user.id` field to determine which user account executed the suspicious command and assess if this account has a history of similar activities.
+- Investigate the `process.parent.name` and `process.parent.args` fields to understand the parent process that initiated the command, which can provide context on whether the execution was part of a legitimate script or application.
+- Examine the `host.os.type` and `event.type` fields to confirm the environment and nature of the event, ensuring it aligns with the expected Windows system behavior.
+- Utilize Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('net.exe', 'dsquery.exe', 'whoami.exe');` to identify other related processes running on the host.
+- Cross-reference the `process.args` with known benign scripts or administrative tasks to rule out false positives, especially focusing on arguments like "accounts", "group", "user", and "localgroup".
+- Check for any recent changes in user permissions or group memberships on the system that could correlate with the suspicious command execution.
+- Review system logs and security events around the time of the alert to identify any other anomalous activities or patterns that could indicate a broader attack.
+- Investigate the network activity from the host to see if there are any unusual outbound connections or data transfers that might suggest data exfiltration or lateral movement.
+- Consult with the user associated with the `user.id` to verify if they were performing legitimate administrative tasks or if their credentials might have been compromised.
+
+### False positive analysis
+
+- Scheduled administrative tasks: Routine system administration tasks often involve querying user and group information, which can trigger this rule. Users can create exceptions for known administrative scripts or scheduled tasks by excluding specific process names or command arguments.
+- Software management tools: Applications like Microsoft Intune or other endpoint management solutions may execute similar commands for inventory or compliance checks. Exclude these processes by specifying their parent process names or paths in the rule.
+- Legitimate user queries: Users may use command-line tools to check their own account information. To reduce noise, consider excluding processes initiated by specific user IDs or those with known benign parent processes.
+- Custom scripts: Organizations may have custom scripts that perform account or group enumeration as part of their operations. Identify these scripts and exclude them by their file paths or specific command-line arguments to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized accounts or group memberships created or modified.
+- Review the execution logs of the identified commands to understand the adversary's actions and objectives.
+- Remove any unauthorized accounts or group memberships identified during the investigation to prevent privilege escalation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed command execution and user activity, ensuring that future suspicious activities are detected promptly.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze potential threats more effectively.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are hardened according to best practices.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness and reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_process_discovery.toml b/rules_building_block/discovery_generic_process_discovery.toml
index 5cd753d8699..f66ae49eb51 100644
--- a/rules_building_block/discovery_generic_process_discovery.toml
+++ b/rules_building_block/discovery_generic_process_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,48 @@ process where host.os.type == "windows" and event.type == "start" and
    (process.name : "query.exe" and process.args : "process")
   ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Discovery Using Built-in Tools
+
+Process discovery tools, like PsList, qprocess, and PowerShell commands, are integral for system management, allowing administrators to monitor active processes. However, adversaries exploit these tools to identify running applications and security defenses, aiding in further attacks. The detection rule identifies suspicious use of these tools by monitoring specific command executions and excluding known system accounts, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command and process name that triggered the alert, focusing on the `process.name` and `process.args` fields.
+- Check the `user.id` field to determine which user account executed the command and verify if it is a known or expected user for such activities.
+- Investigate the `host.os.type` and `event.type` fields to confirm the environment and context in which the command was executed.
+- Correlate the timestamp of the alert with other security events or logs to identify any concurrent suspicious activities.
+- Use Osquery to gather additional context about the processes running on the host. For example, execute the following query to list all running processes: `SELECT pid, name, path, cmdline FROM processes WHERE name IN ('PsList.exe', 'qprocess.exe', 'powershell.exe', 'wmic.exe', 'tasklist.exe', 'query.exe');`
+- Examine the command line arguments (`process.args`) for any unusual or unexpected parameters that could indicate malicious intent.
+- Investigate the parent process of the suspicious command to understand how it was initiated and whether it was spawned by a legitimate application or another suspicious process.
+- Check for any recent changes in user permissions or group memberships that could have allowed unauthorized execution of these commands.
+- Review historical data to determine if this behavior is part of a recurring pattern or a one-time event.
+- Consult threat intelligence sources to see if there are any known campaigns or adversaries that utilize similar techniques, focusing on the MITRE ATT&CK technique T1057 for Process Discovery.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use built-in tools like PsList, qprocess, and PowerShell commands for legitimate process monitoring and management, which can trigger the rule. To manage this, create exceptions for known administrative accounts or specific time frames when these tasks are performed.
+- Automated scripts: Scheduled scripts or maintenance tasks that utilize these commands for system health checks or inventory purposes may also be flagged. Identify and exclude these scripts by their unique user accounts or specific command patterns.
+- Monitoring software: Some security or monitoring software may use similar commands to gather system information, leading to false positives. Review and whitelist these applications by their process names or associated user accounts.
+- Testing environments: In environments where security tools or processes are being tested, these commands might be executed frequently. Exclude these environments by filtering based on hostnames or IP ranges associated with testing labs.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to identify any unauthorized access or changes made to the system, focusing on the processes identified by the detection rule.
+- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
+- Review and analyze logs from the affected system and related network devices to trace the adversary's actions and identify potential entry points.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement hardening measures such as restricting the use of built-in tools to authorized users only and employing application whitelisting to prevent unauthorized execution of processes."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_registry_query.toml b/rules_building_block/discovery_generic_registry_query.toml
index 4370465eb15..876f56ba08b 100644
--- a/rules_building_block/discovery_generic_registry_query.toml
+++ b/rules_building_block/discovery_generic_registry_query.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,49 @@ host.os.type:windows and event.category:process and event.type:start and
     "reg  query \"HKLM\\Software\\WOW6432Node\\Npcap\" /ve  "
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Query Registry using Built-in Tools
+
+The Windows Registry is a critical database for system configuration and application settings. Adversaries exploit built-in tools like `reg.exe` and PowerShell to query the registry, seeking information on installed software and system configurations. The detection rule identifies suspicious registry queries by monitoring specific command executions, filtering out benign activities, and focusing on potential misuse patterns, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to understand which process triggered the rule, focusing on `process.name` and `process.args` to identify the specific command executed.
+- Check the `process.command_line` field to see the full command executed, which can provide context on the intent and scope of the registry query.
+- Investigate the parent process using `process.parent.name` and `process.parent.args` to determine if the registry query was initiated by a legitimate application or script.
+- Examine the user context under which the process was executed by reviewing the `user.name` field to assess if the activity aligns with the user's role and responsibilities.
+- Correlate the event timestamp with other logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'reg.exe' OR name LIKE 'powershell%';` to list all instances of these processes and their command lines.
+- Investigate the network activity associated with the process using network logs to determine if there was any data exfiltration or communication with known malicious IPs.
+- Check for any recent changes in the registry keys queried by the process to identify unauthorized modifications or configurations.
+- Review historical data to determine if similar registry queries have been executed in the past, which might indicate a persistent threat or recurring reconnaissance activity.
+- Consult threat intelligence sources to see if the specific command or pattern matches known attack techniques or campaigns, providing further context on the potential threat actor.
+
+### False positive analysis
+
+- Routine administrative tasks often involve querying the registry using `reg.exe` or PowerShell, which can trigger false positives. System administrators frequently use these tools for legitimate purposes such as checking software installations or system configurations.
+- Automated scripts and software management tools may execute registry queries as part of their normal operations, leading to benign alerts. For example, inventory management systems might query registry keys to gather information about installed applications.
+- Security software updates or checks might involve registry queries to verify settings or configurations, which can be mistaken for suspicious activity.
+- To manage these false positives, users can create exceptions for known benign processes by excluding specific command lines or process arguments that are regularly used in their environment.
+- Regularly review and update the exclusion list to ensure it reflects current legitimate activities, minimizing unnecessary alerts while maintaining effective threat detection.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the registry query activity, identifying any unauthorized access or changes.
+- Review the process execution details and command line arguments to confirm if the activity aligns with known malicious patterns or legitimate administrative tasks.
+- If malicious activity is confirmed, remove any unauthorized software or scripts that may have been installed or executed as a result of the registry query.
+- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed.
+- Implement enhanced logging policies to capture detailed process execution and command line activity for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate registry query activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a broader attack campaign or if additional expertise is required.
+- Apply security patches and updates to the operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries.
+- Educate users and administrators on the risks associated with registry queries and the importance of adhering to security best practices to prevent unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_hosts_file_access.toml b/rules_building_block/discovery_hosts_file_access.toml
index 8a3177bf266..c63ae32c035 100644
--- a/rules_building_block/discovery_hosts_file_access.toml
+++ b/rules_building_block/discovery_hosts_file_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,52 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name in ("vi", "nano", "cat", "more", "less") and process.args == "/etc/hosts"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 System Hosts File Access
+
+The system hosts file maps hostnames to IP addresses, facilitating local network navigation. Adversaries exploit this by accessing the file to identify potential targets for lateral movement. The detection rule monitors the initiation of processes like 'vi', 'nano', or 'cat' accessing '/etc/hosts', signaling potential reconnaissance activities by unauthorized users.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments, ensuring they match the query criteria: process.name in ("vi", "nano", "cat", "more", "less") and process.args == "/etc/hosts".
+- Check the user account associated with the process initiation to determine if it is a known and authorized user.
+- Investigate the timestamp of the event to correlate with any other suspicious activities or anomalies in the system logs around the same time.
+- Examine the parent process of the alerted process to understand how the process was initiated and if it was part of a legitimate workflow.
+- Use Osquery to list recent processes executed by the user to identify any other potentially suspicious activities:
+  ```sql
+  SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');
+  ```
+- Analyze network logs to identify any unusual outbound connections or data transfers that might indicate lateral movement attempts following the hosts file access.
+- Review system access logs to check for any unauthorized login attempts or successful logins around the time of the alert.
+- Investigate any recent changes to the /etc/hosts file by checking file modification times and comparing with known baselines or backups.
+- Cross-reference the alert with any other security alerts or incidents involving the same user or system to identify patterns or coordinated attacks.
+- Consult threat intelligence sources to determine if there are any known campaigns or adversaries that use similar tactics, techniques, and procedures (TTPs) as identified in the alert.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often access the '/etc/hosts' file using tools like 'vi', 'nano', or 'cat' for legitimate purposes such as updating host entries or troubleshooting network issues. These activities can trigger false positives.
+- Automated scripts: Some automated maintenance or monitoring scripts may read the '/etc/hosts' file to verify or log network configurations, leading to benign alerts.
+- Software installations or updates: Certain software installations or updates may access the '/etc/hosts' file to configure network settings, which can be mistaken for suspicious activity.
+- User education: Educate users about the importance of the '/etc/hosts' file and encourage them to report any legitimate access they perform, which can help in distinguishing between normal and suspicious activities.
+- Exception handling: Implement exceptions for known administrative accounts or specific scripts that regularly access the '/etc/hosts' file, reducing unnecessary alerts while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to determine if unauthorized access to the '/etc/hosts' file was part of a larger attack, checking for other signs of compromise.
+- Review system logs and process execution history to identify any additional suspicious activities or processes initiated by unauthorized users.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader threat or if sensitive data may have been accessed.
+- Restore the system to its operational state by reverting any unauthorized changes to the '/etc/hosts' file and ensuring all system configurations are secure.
+- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and identify potential threats in real-time.
+- Apply system hardening measures, such as restricting access to critical files like '/etc/hosts' to only authorized users and processes.
+- Educate users and administrators on the importance of maintaining secure configurations and recognizing signs of potential reconnaissance activities.
+- Regularly review and update security policies and procedures to align with the latest MITRE ATT&CK framework tactics and techniques, ensuring comprehensive threat coverage."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_internet_capabilities.toml b/rules_building_block/discovery_internet_capabilities.toml
index 2ae9e761e72..8b619a83f2c 100644
--- a/rules_building_block/discovery_internet_capabilities.toml
+++ b/rules_building_block/discovery_internet_capabilities.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,49 @@ host.os.type:windows and event.category:process and event.type:start and
 process.name.caseless:("ping.exe" or "tracert.exe" or "pathping.exe") and
 not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Discovery of Internet Capabilities via Built-in Tools
+
+Built-in network diagnostic tools like ping, tracert, and pathping are essential for assessing connectivity and network paths. Adversaries exploit these tools to verify internet access and map network routes, aiding in C2 communication. The detection rule identifies suspicious use of these tools by monitoring process starts and filtering out benign local addresses, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand which built-in tool (ping.exe, tracert.exe, or pathping.exe) was used and the specific arguments passed to the process.
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time.
+- Investigate the user account associated with the process start event to determine if it is a legitimate user or potentially compromised.
+- Examine the source IP address and destination IP addresses involved in the process arguments to identify any external or unusual network connections.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('ping.exe', 'tracert.exe', 'pathping.exe');` to list all instances of these processes and their command-line arguments.
+- Analyze the parent process of the suspicious activity to understand how the built-in tool was executed and if it was initiated by another suspicious process.
+- Check for any related network activity logs that might indicate data exfiltration or communication with known malicious IP addresses.
+- Investigate any recent changes to the system's network configuration that could have facilitated the use of these tools for malicious purposes.
+- Review historical data to determine if there have been previous instances of similar activity on the same host or by the same user account.
+- Cross-reference the identified IP addresses with threat intelligence sources to check for any known associations with malicious activity or C2 servers.
+
+### False positive analysis
+
+- Routine network diagnostics by IT personnel can trigger false positives, as they often use tools like ping, tracert, and pathping for legitimate troubleshooting. To manage this, create exceptions for known IT user accounts or specific IP addresses associated with IT operations.
+- Automated monitoring systems or scripts that regularly check network connectivity might also cause false positives. Exclude these processes by identifying their unique command-line arguments or execution patterns.
+- Scheduled tasks or maintenance scripts that include network diagnostics as part of their operation can be mistaken for malicious activity. Document and exclude these tasks by their scheduled times or specific hostnames.
+- Software updates or installations that perform network checks to verify connectivity can be flagged. Identify and exclude these processes by their parent process names or associated software update services.
+- Remote management tools that use these network diagnostic commands as part of their functionality can lead to false positives. Whitelist these tools by their process hashes or digital signatures to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further communication with potential C2 servers.
+- Conduct a thorough investigation of the process execution logs to identify any unauthorized use of network diagnostic tools and determine the scope of the compromise.
+- Review and analyze network traffic logs to identify any suspicious outbound connections that may indicate C2 communication.
+- Remove any malicious software or scripts identified during the investigation from the affected system.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by reimaging the affected machine and restoring data from verified backups.
+- Implement network segmentation and access controls to limit the use of built-in network diagnostic tools to authorized personnel only."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
index e6ea704526d..9a07dc1d95d 100644
--- a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
+++ b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/12"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,49 @@ query = '''
 host.os.type:linux and event.category:file and event.action:"opened-file" and file.path:"/proc/modules" and
 not process.name:(python* or chef-client)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Enumeration of Kernel Modules via Proc
+
+Loadable Kernel Modules (LKMs) enhance kernel functionality dynamically. The `/proc/modules` file lists these modules, aiding utilities like `lsmod` in module management. Adversaries exploit this by querying `/proc/modules` to gather system insights, potentially identifying security weaknesses. The detection rule flags unauthorized access attempts to this file, excluding benign processes, to identify suspicious enumeration activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event category is 'file' and the action is 'opened-file', ensuring it matches the rule criteria.
+- Verify the file path is indeed '/proc/modules' to confirm the alert is related to kernel module enumeration.
+- Check the process name that triggered the alert. Ensure it is not a benign process like 'python*' or 'chef-client', which are excluded in the rule.
+- Investigate the user account associated with the process to determine if it has legitimate reasons to access '/proc/modules'.
+- Examine the process's parent process to understand the context in which the access attempt was made.
+- Use Osquery to gather more information about the process. For example, run the query: `SELECT * FROM processes WHERE name = '<process_name>';` to get details about the process that accessed '/proc/modules'.
+- Check the system's recent login history to identify any unusual or unauthorized access patterns that might correlate with the alert.
+- Review system logs for any other suspicious activities around the time of the alert, such as failed login attempts or other file access anomalies.
+- Investigate any network connections established by the process to determine if there is any communication with known malicious IPs or domains.
+- Correlate this alert with other security events in the environment to identify if this is part of a broader attack pattern or isolated incident.
+
+### False positive analysis
+
+- System management tools and scripts that regularly check kernel module status for legitimate purposes may trigger false positives. These include automated monitoring tools or configuration management systems like Ansible or Puppet.
+- Scheduled maintenance scripts that verify system integrity by accessing `/proc/modules` can also be mistaken for suspicious activity.
+- Developers and system administrators using custom scripts to monitor or log kernel module changes might inadvertently cause false positives.
+- To manage these false positives, users can create exceptions for known benign processes by adding them to the exclusion list in the detection rule, similar to the existing exclusion for `python*` or `chef-client`.
+- Regularly review and update the exclusion list to include any new legitimate processes that frequently access `/proc/modules` to ensure accurate detection without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough investigation to identify the process or user responsible for accessing /proc/modules, focusing on any unauthorized or suspicious activity.
+- Review system logs and security alerts to gather additional context and determine if the access was part of a broader attack pattern.
+- If malicious activity is confirmed, remove any unauthorized kernel modules and restore the system to a known good state using backups or system snapshots.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed access attempts to critical files like /proc/modules, ensuring that logs are stored securely and monitored regularly.
+- Integrate threat intelligence feeds to correlate the activity with known attack patterns and adversary tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
+- Apply system hardening measures, such as restricting access to /proc/modules to only trusted processes and users, and regularly updating and patching the system to mitigate vulnerabilities.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users and administrators on the importance of monitoring and securing kernel modules to prevent future unauthorized access attempts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_modprobe_enumeration.toml b/rules_building_block/discovery_linux_modprobe_enumeration.toml
index 1a41af5ad2f..40648ebaf93 100644
--- a/rules_building_block/discovery_linux_modprobe_enumeration.toml
+++ b/rules_building_block/discovery_linux_modprobe_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/08"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,48 @@ file.path : ("/etc/modprobe.conf" or "/etc/modprobe.d" or /etc/modprobe.d/*) and
   aide or modprobe or python*
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Modprobe File Event
+
+Modprobe manages Linux kernel modules, essential for system functionality. Adversaries may exploit modprobe configurations to load unauthorized modules, potentially bypassing security, escalating privileges, or concealing activities. The detection rule identifies suspicious file access in modprobe directories, excluding benign processes, to flag potential tampering attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific file path triggered the event, focusing on `/etc/modprobe.conf` or files within `/etc/modprobe.d`.
+- Identify the process that accessed the modprobe file by examining the `process.name` field in the alert. Determine if the process is expected or potentially malicious.
+- Check the `host.os.type` field to confirm the operating system is Linux, ensuring the alert is relevant to the environment.
+- Investigate the `event.action` field to verify that the action was indeed "opened-file," indicating potential unauthorized access.
+- Use Osquery to list all processes that have accessed modprobe files recently. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/etc/modprobe%' ORDER BY start_time DESC;`
+- Cross-reference the process ID and name with known benign processes to rule out false positives.
+- Examine system logs for any additional file access or modification events around the same time as the alert to identify patterns or repeated access attempts.
+- Investigate the user account associated with the process that accessed the modprobe file to determine if it has the necessary permissions and if the access was legitimate.
+- Review recent changes to the modprobe files by checking file modification timestamps and comparing them with known change management records.
+- Analyze network activity from the host to identify any suspicious outbound connections that may correlate with the timing of the modprobe file access.
+
+### False positive analysis
+
+- Routine system maintenance tasks or updates may trigger the rule, as legitimate processes might access modprobe files during these operations. For example, package managers like `apt` or `yum` could access these files when installing or updating software.
+- Custom scripts or administrative tools that interact with kernel modules for legitimate purposes might also be flagged. These could include backup scripts or system monitoring tools that are not part of the default exclusion list.
+- Users can manage these false positives by reviewing the processes that are accessing the modprobe files and determining if they are part of regular system operations. If so, they can be added to the exclusion list in the detection rule to prevent future alerts.
+- It's important to regularly review and update the exclusion list to ensure that new legitimate processes are not mistakenly flagged, while also ensuring that potentially malicious activities are not overlooked.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker.
+- Conduct a thorough investigation to identify the source of the suspicious modprobe file event, examining logs and system changes to determine if unauthorized kernel modules were loaded.
+- Verify the integrity of the modprobe configuration files and compare them against known good baselines to identify any unauthorized modifications.
+- Remove any unauthorized or malicious kernel modules identified during the investigation to restore the system's integrity.
+- Restore the modprobe configuration files from a trusted backup if any tampering is detected, ensuring that only legitimate modules are loaded.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
+- Implement enhanced logging and monitoring for modprobe-related activities, ensuring that all file access and modifications are captured for future investigations.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection capabilities and contextual understanding of similar threats.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as restricting access to modprobe directories and enforcing strict user permissions.
+- Educate system administrators and security personnel on the risks associated with kernel module manipulation and the importance of maintaining secure configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_sysctl_enumeration.toml b/rules_building_block/discovery_linux_sysctl_enumeration.toml
index 4da1313644c..cdb86c65dfe 100644
--- a/rules_building_block/discovery_linux_sysctl_enumeration.toml
+++ b/rules_building_block/discovery_linux_sysctl_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/08"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,49 @@ file.path : ("/etc/sysctl.conf" or "/etc/sysctl.d" or /etc/sysctl.d/*) and not p
   dpkg or dockerd or unattended-upg or systemd-sysctl or python* or auditbeat or dpkg or pool*
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Sysctl File Event
+
+Sysctl configuration files in Linux systems manage kernel parameters, crucial for system performance and security. Adversaries may exploit these files to alter system behavior, potentially destabilizing or compromising the system. The detection rule identifies unauthorized access or changes to these files by monitoring file events and excluding legitimate processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to understand which sysctl configuration file was accessed or modified, focusing on the `file.path` field to identify the specific file involved.
+- Examine the `event.action` field to determine the type of file operation (e.g., "opened-file", "read-file", "wrote-to-file") that triggered the alert.
+- Identify the process responsible for the file event by reviewing the `process.name` field, and cross-reference it with known legitimate processes to confirm if it is indeed suspicious.
+- Check the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is specifically designed for Linux environments.
+- Investigate the user account associated with the process by examining the `user.name` field to determine if the access was performed by a legitimate or suspicious user.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve details like process ID, parent process, and command line arguments.
+- Review recent system logs for any unusual activity around the time of the alert, focusing on authentication logs and other security-related logs.
+- Analyze the system's process tree to understand the parent-child relationship of the suspicious process, which can provide insights into how the process was initiated.
+- Check for any recent changes to the sysctl configuration files by comparing the current file contents with a known good baseline or backup, if available.
+- Investigate any network connections established by the suspicious process using Osquery: `SELECT * FROM socket_events WHERE pid = <suspicious_process_pid>;` to identify potential external communication.
+
+### False positive analysis
+
+- Routine system maintenance tasks can trigger false positives. For example, legitimate system updates or package installations may access sysctl files, especially if not all relevant processes are excluded in the detection rule.
+- Automated configuration management tools like Ansible, Puppet, or Chef might access sysctl files to ensure system configurations are consistent, leading to benign alerts.
+- Backup or monitoring software that reads system configuration files for integrity checks or data collection purposes can also cause false positives.
+- To manage these false positives, users can update the detection rule to exclude additional known legitimate processes by adding them to the `not process.name` list. This can include specific maintenance scripts or tools that are regularly used in the environment.
+- Regularly review and update the exclusion list to reflect changes in system management practices or new tools introduced into the environment, ensuring that only non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
+- Conduct a thorough investigation to identify the source of the unauthorized access, focusing on recent changes to sysctl configuration files and correlating with process activity.
+- Review system logs and security alerts to determine if any other systems have been targeted or compromised.
+- Restore the sysctl configuration files from a known good backup to ensure system stability and security.
+- Apply patches and updates to the operating system and applications to mitigate any known vulnerabilities that may have been exploited.
+- Implement stricter access controls and permissions on sysctl configuration files to limit who can read or modify them.
+- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect future unauthorized access attempts.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate and train staff on recognizing and responding to suspicious activities related to system configuration files.
+- Consider deploying additional security measures such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_system_information_discovery.toml b/rules_building_block/discovery_linux_system_information_discovery.toml
index 431c60f4301..3cc11e5edc1 100644
--- a/rules_building_block/discovery_linux_system_information_discovery.toml
+++ b/rules_building_block/discovery_linux_system_information_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/10"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,50 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
   )
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Linux System Information Discovery
+
+Linux system information discovery involves commands like `uname`, `cat`, `more`, and `less` to gather system details such as kernel version, hardware, and configuration files. Adversaries exploit these to understand the environment and tailor their attacks. The detection rule identifies suspicious use of these commands, focusing on process initiation events and specific arguments that suggest system probing, thus flagging potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific command triggered the detection, focusing on the `process.name` and `process.args` fields.
+- Examine the `event.type` and `event.action` fields to confirm the nature of the process initiation and ensure it aligns with typical reconnaissance activities.
+- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Investigate the parent process of the suspicious command to identify if it was spawned by a legitimate application or script.
+- Analyze the command execution context by reviewing the `process.args` field to understand the specific system information being queried.
+- Correlate the timing of the alert with other security events or logs to identify any related suspicious activities or patterns.
+- Use Osquery to gather additional context on the system. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
+- Investigate network connections at the time of the alert to identify any unusual outbound connections that may indicate data exfiltration.
+- Review system logs for any anomalies or errors around the time of the alert that could provide additional context or evidence of compromise.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) of specific threat actors.
+
+### False positive analysis
+
+- Routine administrative tasks often involve the use of commands like `uname`, `cat`, `more`, and `less` to check system configurations, kernel versions, or hardware details, which can trigger false positives.
+- Automated scripts or monitoring tools that regularly check system status or configurations may also generate alerts, as they frequently execute these commands with arguments that match the detection criteria.
+- Developers and system administrators might use these commands during troubleshooting or system audits, leading to benign process initiation events being flagged.
+- To manage these false positives, users can create exceptions for known scripts or processes that are verified as non-threatening, ensuring they are excluded from triggering alerts.
+- Implementing a whitelist of trusted users or processes that regularly perform these actions can help reduce noise and focus on genuinely suspicious activities.
+- Regularly review and update the list of exceptions to adapt to changes in system administration practices or new tools that might be introduced into the environment.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the process events to confirm the nature and scope of the suspicious activity, focusing on the commands and arguments used.
+- Review user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed command-line activity and process execution events for future investigations.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework into security monitoring tools to improve detection of similar tactics and techniques.
+- Restore the system to its operational state by applying necessary patches, updating configurations, and ensuring all security controls are active.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Implement system hardening measures, such as disabling unnecessary services, enforcing strong authentication mechanisms, and applying least privilege principles.
+- Educate users and administrators on recognizing and reporting suspicious activities to enhance organizational security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_linux_system_owner_user_discovery.toml b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
index 2e2c8d3def8..a346df9537a 100644
--- a/rules_building_block/discovery_linux_system_owner_user_discovery.toml
+++ b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/10"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,49 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and 
 process.name : ("whoami", "w", "who", "users", "id")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 System Owner/User Discovery Linux
+
+In Linux environments, commands like `whoami`, `w`, `who`, `users`, and `id` are used to identify the current user and other logged-in users. Adversaries exploit these tools to gather information about system ownership and user activity, aiding in privilege escalation and lateral movement. The detection rule monitors the execution of these commands, flagging potential misuse by correlating process start events with specific command executions, thus alerting analysts to suspicious user enumeration activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the specific command that triggered the alert by examining the `process.name` field.
+- Check the `user.name` field to identify the user account that executed the command and determine if it aligns with expected user behavior.
+- Investigate the `process.parent.name` field to understand the parent process that initiated the command, which may provide context on whether the execution was part of a legitimate workflow or potentially malicious activity.
+- Analyze the `host.name` field to determine if the activity occurred on a critical or sensitive system, which may elevate the priority of the investigation.
+- Examine the `process.command_line` field to see the full command executed, which can provide additional context or reveal if the command was part of a script or automated task.
+- Utilize Osquery to gather more information about the user and system context by running a query such as: `SELECT * FROM logged_in_users WHERE user = '<suspicious_user>';` to identify all sessions associated with the user.
+- Cross-reference the `event.timestamp` with other security logs (e.g., authentication logs, network logs) to identify any correlated suspicious activities around the same time.
+- Check for any recent changes in user privileges or group memberships that might indicate privilege escalation attempts.
+- Review historical data for similar command executions by the same user or on the same host to identify patterns or repeated suspicious behavior.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or campaigns.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use commands like `whoami`, `w`, `who`, `users`, and `id` as part of their regular system management activities. These legitimate uses can trigger false positives. To manage this, create exceptions for known administrator accounts or specific times when these tasks are typically performed.
+- Automated scripts: Some automated scripts or monitoring tools may execute these commands to gather system information for performance monitoring or auditing purposes. Identify and whitelist these scripts or processes to prevent unnecessary alerts.
+- Scheduled jobs: Cron jobs or other scheduled tasks might run these commands for reporting or maintenance purposes. Review and exclude these scheduled tasks from triggering alerts by specifying the exact command patterns and associated user accounts.
+- Development and testing environments: In environments where frequent testing and development occur, developers might use these commands to verify user permissions or system states. Consider excluding specific user groups or environments from the detection rule to reduce noise.
+- Security tools: Some security tools or agents might use these commands as part of their normal operation to collect user and system data. Verify the legitimacy of these tools and exclude their processes from the detection criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or privilege escalation attempts.
+- Review system logs and security alerts to correlate the execution of user discovery commands with other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of a broader attack or advanced persistent threat (APT) activity.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, to aid in future investigations.
+- Integrate threat intelligence feeds and MITRE ATT&CK framework data to enrich alerts with context about known adversary tactics and techniques.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
+- Educate users on recognizing and reporting suspicious activities to improve the organization's overall security posture.
+- Continuously monitor for any signs of re-infection or further malicious activity, adjusting detection rules and response strategies as necessary."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_net_share_discovery_winlog.toml b/rules_building_block/discovery_net_share_discovery_winlog.toml
index 3194c52904e..27fae038da8 100644
--- a/rules_building_block/discovery_net_share_discovery_winlog.toml
+++ b/rules_building_block/discovery_net_share_discovery_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/14"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,49 @@ sequence by user.name, source.port, source.ip with maxspan=15s
   winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and 
   source.ip != null and source.ip != "0.0.0.0" and source.ip != "::1" and source.ip != "::" and source.ip != "127.0.0.1"]
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Network Share Discovery
+
+Network shares allow users to access files and resources across systems, facilitating collaboration. However, adversaries exploit this by scanning for shared folders, especially administrative shares, to gather intelligence or move laterally within a network. The detection rule identifies suspicious access attempts to default administrative shares from non-local IPs, signaling potential reconnaissance or lateral movement activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the `user.name`, `source.ip`, and `source.port` involved in the suspicious access attempt to the administrative shares.
+- Verify the legitimacy of the `source.ip` by checking if it belongs to a known and trusted network segment or if it is an external or unexpected internal IP address.
+- Cross-reference the `user.name` with organizational records to determine if the user should have access to the targeted network shares.
+- Check historical logs for previous access attempts from the same `source.ip` or `user.name` to identify patterns or repeated suspicious behavior.
+- Use Osquery to gather more information about the system associated with the `source.ip`. For example, run the following query to list active network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<source.ip>';`
+- Investigate the system associated with the `source.ip` for signs of compromise, such as unusual processes or services running, by using endpoint detection and response (EDR) tools.
+- Analyze the timing and frequency of the access attempts to determine if they align with normal user activity or if they occur at unusual times.
+- Check for any recent changes or updates to the system or network configuration that might explain the access attempt.
+- Review any related alerts or logs from other security tools that might provide additional context or corroborate the suspicious activity.
+- Consult with the user associated with the `user.name` to verify if they initiated the access attempt and if they are aware of any potential security issues.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate IT administrators may access administrative shares for maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known administrator IP addresses or user accounts.
+- Automated backup or monitoring systems: These systems often access network shares to perform regular backups or health checks. Identify and exclude these systems by their IP addresses or service accounts to prevent false positives.
+- Software updates and patch management: Some update services may access administrative shares to deploy patches. Recognize these services and exclude their IPs or associated user accounts from triggering the rule.
+- Internal security scans: Security tools that perform vulnerability assessments or compliance checks might access network shares. Document these tools and exclude their IPs or user accounts to avoid unnecessary alerts.
+- Development and testing environments: Developers or automated testing scripts might access network shares as part of their workflow. Identify these environments and exclude relevant IPs or user accounts to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to identify the source of the suspicious access attempts, focusing on the non-local IP addresses involved.
+- Review and analyze logs from the affected system and network devices to gather more context on the access attempts and identify any other potentially compromised systems.
+- Change passwords for accounts that were used to access the administrative shares, especially if they have elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement stricter access controls and permissions on network shares, ensuring that only authorized users have access to administrative shares.
+- Enhance logging policies to include detailed auditing of network share access and integrate with a security information and event management (SIEM) system for real-time monitoring.
+- Apply security patches and updates to all systems to mitigate known vulnerabilities that could be exploited for lateral movement.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users on recognizing and reporting suspicious activities to improve the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
index 534e6b19c1c..213c9d24bb1 100644
--- a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
+++ b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,50 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
   (process.name == "getent" and process.args in ("passwd", "group"))
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Account or Group Discovery via Built-In Tools
+
+Built-in tools like `groups`, `id`, `dscl`, and `getent` are essential for managing and querying user and group information in Unix-like systems. Adversaries exploit these tools to enumerate accounts and groups, gaining insights into system configurations and potential targets. The detection rule identifies suspicious use of these tools by monitoring process execution patterns and specific arguments, flagging potential unauthorized discovery activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on fields like `process.name` and `process.args`.
+- Check the `event.timestamp` to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
+- Investigate the `user.name` and `user.id` fields to identify the user account associated with the process execution and assess if the account has a legitimate reason to perform such actions.
+- Examine the `host.name` or `host.ip` fields to determine which system the activity originated from and assess its role within the network.
+- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('groups', 'id', 'dscl', 'dscacheutil', 'getent');` to identify any other related processes that may have been executed.
+- Analyze the `parent.process.name` and `parent.process.id` fields to understand the parent process that initiated the suspicious activity, which might provide insights into the origin of the command.
+- Review historical logs for the same `process.name` and `process.args` to determine if this is a recurring pattern or an isolated incident.
+- Check for any recent changes in user permissions or group memberships that might explain the use of these tools, focusing on the `process.args` that reference user or group files.
+- Investigate any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration attempts.
+- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign or an isolated event.
+
+### False positive analysis
+
+- Routine administrative tasks can trigger this rule, as system administrators often use tools like `groups`, `id`, `dscl`, and `getent` for legitimate purposes such as user account management and system maintenance. 
+- Automated scripts or scheduled jobs that perform regular system audits or backups may also execute these commands, leading to false positives.
+- Security software or monitoring tools that periodically check system configurations and user permissions might invoke these commands, resulting in benign alerts.
+- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that are verified as non-threatening.
+- Implementing a baseline of normal system behavior can help distinguish between legitimate use and potential threats, allowing for more accurate filtering of alerts.
+- Regularly updating the list of approved processes and arguments in the detection rule can reduce the occurrence of false positives by excluding recognized safe activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying all accounts and groups accessed by the adversary.
+- Review system logs and security alerts to trace the adversary's activities and identify any additional compromised systems or accounts.
+- Change passwords for all potentially compromised accounts and enforce multi-factor authentication to enhance security.
+- Remove any unauthorized accounts or groups created by the adversary and ensure all legitimate accounts have appropriate permissions.
+- Restore the system from a known good backup to ensure no malicious changes persist.
+- Implement enhanced logging and monitoring policies to capture detailed information on account and group access activities.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Educate users and administrators on recognizing and reporting suspicious activities to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_of_domain_groups.toml b/rules_building_block/discovery_of_domain_groups.toml
index 6a1122dd0d6..de68c61530b 100644
--- a/rules_building_block/discovery_of_domain_groups.toml
+++ b/rules_building_block/discovery_of_domain_groups.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,48 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   process.name in ("ldapsearch", "dscacheutil") or (process.name == "dscl" and process.args : "*-list*")
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Discovery of Domain Groups
+
+In Linux environments, commands like `ldapsearch`, `dscacheutil`, and `dscl` are used for querying domain group information, aiding system administrators in managing user permissions. Adversaries exploit these commands to gather intelligence on group memberships, which can inform privilege escalation strategies. The detection rule identifies suspicious use of these commands by monitoring process execution patterns, helping to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command executed, focusing on the `process.name` and `process.args` fields to understand the context of the command usage.
+- Check the `host.os.type` field to confirm the operating system is Linux, ensuring the alert is relevant to the environment.
+- Investigate the `event.type` and `event.action` fields to verify the nature of the process execution and ensure it aligns with the suspicious activity pattern.
+- Examine the user account associated with the process execution to determine if the activity is expected or if the account has a history of similar actions.
+- Cross-reference the timestamp of the event with other logs to identify any correlated activities or anomalies around the same time.
+- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('ldapsearch', 'dscacheutil', 'dscl');` to list all instances of these processes and their arguments.
+- Analyze the network connections at the time of the event to identify any unusual outbound connections that may indicate data exfiltration or further reconnaissance.
+- Review historical data for patterns of similar command executions to determine if this is part of a broader trend or a one-off event.
+- Check for any recent changes in user permissions or group memberships that could be related to the suspicious command execution.
+- Consult threat intelligence sources to see if there are any known campaigns or adversaries that use similar techniques, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use commands like `ldapsearch`, `dscacheutil`, and `dscl` for legitimate purposes such as managing user accounts and permissions. These activities can trigger the detection rule, leading to false positives.
+- Automated scripts: Scheduled scripts or cron jobs that perform regular checks or updates on user and group information may execute these commands, resulting in benign alerts.
+- Monitoring and auditing tools: Security and compliance tools that audit system configurations and user permissions might use these commands as part of their normal operations, causing false positives.
+- To manage false positives, users can create exceptions for known administrative accounts or specific scripts that frequently execute these commands. This can be done by adding filters to exclude processes initiated by trusted users or scripts from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the activity, including identifying all systems and accounts accessed by the adversary.
+- Review logs and alerts to identify any additional suspicious activities or related incidents, focusing on the use of `ldapsearch`, `dscacheutil`, and `dscl` commands.
+- Change passwords and review permissions for any accounts that may have been compromised or accessed during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for command execution and process creation events to detect similar activities in the future.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
+- Implement hardening measures such as restricting the use of domain enumeration commands to authorized personnel only and using multi-factor authentication (MFA) for sensitive accounts."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_posh_generic.toml b/rules_building_block/discovery_posh_generic.toml
index 99cc4afdb5d..e7e1c09a9b1 100644
--- a/rules_building_block/discovery_posh_generic.toml
+++ b/rules_building_block/discovery_posh_generic.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 
 
 [rule]
@@ -140,6 +140,49 @@ event.category:process and host.os.type:windows and
   ) and
   not user.id : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Discovery Capabilities
+
+PowerShell is a powerful scripting language and automation framework used in Windows environments for system administration. Adversaries exploit its capabilities to gather information about the system, network, and domain, such as user accounts, network configurations, and installed software. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and methods indicative of reconnaissance efforts, while excluding benign processes and trusted user accounts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific PowerShell cmdlet or method triggered the detection, focusing on the `powershell.file.script_block_text` field for context.
+- Check the `user.id` field to identify the user account associated with the PowerShell activity and determine if it is a known or trusted account.
+- Investigate the `event.category:process` to gather information about the parent process and any related child processes to understand the context of the PowerShell execution.
+- Examine the `host.os.type:windows` field to confirm the operating system and ensure the environment aligns with expected configurations.
+- Use Osquery to gather additional context about the system. For example, run the following query to list all running processes and their command-line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%powershell%';`
+- Cross-reference the PowerShell script block text with known benign scripts or administrative tasks to rule out false positives.
+- Analyze network logs to identify any unusual outbound connections or data exfiltration attempts that may correlate with the PowerShell activity.
+- Review recent changes to the system, such as new software installations or updates, that might explain the PowerShell activity.
+- Check for any other security alerts or logs related to the same user or system to identify potential patterns or additional suspicious behavior.
+- Consult threat intelligence sources to determine if the detected PowerShell activity matches known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- **System Administration Tasks**: Legitimate system administrators often use PowerShell cmdlets for routine tasks such as checking system configurations, user accounts, and network settings. These activities can trigger the rule. To manage this, create exceptions for known administrator accounts or specific cmdlets used in regular maintenance.
+- **Automated Scripts and Tools**: Some automated scripts or third-party tools may use PowerShell for legitimate discovery activities, such as inventory management or system monitoring. Identify these scripts and tools, and exclude their specific processes or user accounts from the rule.
+- **Security Software Operations**: Security software may use PowerShell to gather system information for protection purposes. Exclude processes associated with trusted security software to prevent false positives.
+- **Software Updates and Installations**: During software updates or installations, PowerShell may be used to check system compatibility or configurations, which can be mistaken for reconnaissance. Exclude known update processes or installation scripts from the rule.
+- **Development and Testing Environments**: Developers and testers might use PowerShell to simulate various scenarios, including discovery activities. Consider excluding user accounts or processes associated with development and testing environments to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the PowerShell script execution to determine the scope and intent of the activity, focusing on the cmdlets and methods used.
+- Review user account activity and permissions to identify any unauthorized access or privilege escalation attempts.
+- Remove any malicious scripts or files identified during the investigation and ensure that all unauthorized changes are reverted.
+- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and transcription.
+- Integrate security solutions such as SIEM or EDR to improve detection and response capabilities for similar threats in the future.
+- Educate users on recognizing phishing attempts and suspicious activities to reduce the risk of initial compromise.
+- Restore the system to its operational state by verifying the integrity of critical system files and configurations.
+- Harden the system by disabling unnecessary services, enforcing strong password policies, and implementing network segmentation to limit lateral movement."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/discovery_posh_password_policy.toml b/rules_building_block/discovery_posh_password_policy.toml
index 3178120fd4f..6a532ee0eb5 100644
--- a/rules_building_block/discovery_posh_password_policy.toml
+++ b/rules_building_block/discovery_posh_password_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -91,6 +91,50 @@ event.category: "process" and host.os.type:windows and
   )
   and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Password Policy Discovery Capabilities
+
+PowerShell is a powerful scripting language used for automating tasks in Windows environments, including querying Active Directory for password policies. Adversaries exploit this by executing scripts to discover password policies, aiding in lateral movement and privilege escalation. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and script patterns associated with password policy queries, while excluding known benign scripts and system accounts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific PowerShell cmdlet or script pattern triggered the alert, focusing on fields like `powershell.file.script_block_text`.
+- Check the `user.id` field to identify the user account associated with the suspicious activity, ensuring it is not a known system account like "S-1-5-18".
+- Investigate the `event.category` and `host.os.type` fields to confirm the activity occurred on a Windows host and is categorized as a process event.
+- Examine the script block text for any of the specific cmdlets or methods such as "Get-ADDefaultDomainPasswordPolicy" or "ActiveDirectory.DirectorySearcher" to determine the nature of the password policy query.
+- Cross-reference the `powershell.file.script_block_text` with known benign scripts or exclusions, such as "sentinelbreakpoints" or "43c15630-959c-49e4-a977-758c5cc93408", to rule out false positives.
+- Use Osquery to gather additional context on the process execution. For example, run the following query to list recent PowerShell executions: `SELECT * FROM processes WHERE name = 'powershell.exe';`
+- Investigate the parent process of the PowerShell execution to determine if it was initiated by a legitimate application or a potentially malicious process.
+- Check for any network connections or remote execution attempts associated with the PowerShell process, particularly if WinRM is involved, to assess potential lateral movement.
+- Review historical logs for any previous similar activities by the same user or on the same host to identify patterns or repeated attempts.
+- Correlate the findings with other security alerts or logs from the same timeframe to build a comprehensive picture of the potential threat actor's activities.
+
+### False positive analysis
+
+- Known false positives may include legitimate administrative scripts that query Active Directory for password policies as part of routine security audits or compliance checks. These scripts often use the same cmdlets and methods flagged by the detection rule.
+- System administrators using PowerShell to manage password policies across multiple domains might trigger the rule, especially if they use custom scripts that resemble the patterns identified in the detection rule.
+- Security tools or monitoring solutions that perform regular checks on password policies for reporting purposes can also generate false positives if they utilize PowerShell scripts with similar characteristics.
+- To manage these false positives, users can create exceptions for specific script block texts that are known to be benign, such as those used by trusted administrative tools or scripts.
+- Excluding specific user accounts, such as those belonging to system administrators or service accounts that regularly perform these tasks, can help reduce false positives. This can be done by adding their user IDs to the exclusion list.
+- Regularly reviewing and updating the exclusion list to include new benign scripts or accounts as they are identified can help maintain the balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation to identify the source of the PowerShell script execution, including reviewing logs for suspicious user activity and correlating with known threat intelligence.
+- Terminate any malicious PowerShell processes identified during the investigation to halt ongoing unauthorized activities.
+- Reset passwords for any compromised accounts and enforce a password policy that includes complexity requirements and regular expiration.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging for PowerShell activities, including script block logging and transcription, to improve future detection and investigation capabilities.
+- Integrate security information and event management (SIEM) solutions with threat intelligence feeds to identify and respond to similar threats more effectively.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are in place.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary services like WinRM, applying least privilege principles, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_potential_memory_seeking_activity.toml b/rules_building_block/discovery_potential_memory_seeking_activity.toml
index 5da12a7bb77..63791094020 100644
--- a/rules_building_block/discovery_potential_memory_seeking_activity.toml
+++ b/rules_building_block/discovery_potential_memory_seeking_activity.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,49 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   process.args like "/var/tmp/dracut*"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Memory Seeking Activity
+
+In Unix-based systems, utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` are used for legitimate data processing tasks, including reading and comparing file contents. However, adversaries can exploit these tools to probe memory addresses, potentially setting the stage for further exploitation. The detection rule identifies suspicious executions of these utilities, filtering out benign use cases by examining process arguments and parent processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific utility and arguments that triggered the alert, focusing on the `process.name` and `process.args` fields.
+- Examine the `process.parent.name` and `process.parent.args` fields to understand the context in which the utility was executed and determine if it aligns with known benign processes or scripts.
+- Check the `process.parent.executable` and `process.parent.command_line` fields to identify the full path and command line of the parent process, which may provide additional context about the execution environment.
+- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity is consistent with the user's typical behavior or role.
+- Use Osquery to gather additional context about the process and its parent. For example, run the following Osquery query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, parent FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
+- Analyze system logs and other security tools for any related or preceding suspicious activity involving the same user or process, which might indicate a broader attack pattern.
+- Check for any network connections initiated by the process or its parent using network monitoring tools or logs to identify potential data exfiltration or command-and-control activity.
+- Review file system changes around the time of the alert, focusing on any files accessed or modified by the process, to identify potential data tampering or reconnaissance.
+- Correlate the alert with other security events or alerts from the same host or network segment to identify potential coordinated or multi-stage attacks.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware families.
+
+### False positive analysis
+
+- Legitimate system maintenance scripts: Some system maintenance scripts may use utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` for routine tasks such as log file analysis or data processing. These scripts can trigger the rule if they match the specified arguments. Users can handle these by identifying the specific scripts and adding their parent process names or command lines to the exclusion list.
+- Backup and data migration processes: Automated backup or data migration processes might use these utilities to read or compare large data sets. If these processes are known and trusted, users can exclude them by specifying the parent executable paths or command lines in the exclusion criteria.
+- Security and monitoring tools: Some security tools or monitoring agents might use these utilities to perform legitimate checks on system files or memory. Users should verify the legitimacy of these tools and exclude their parent processes or command lines if they are frequently triggering the rule.
+- Development and testing environments: Developers or testers might use these utilities during debugging or testing phases, especially when working with memory dumps or binary files. Users can exclude specific development tools or scripts by adding their parent process details to the exclusion list.
+- Custom scripts and automation: Organizations often have custom scripts that utilize these utilities for various automation tasks. Users should review these scripts and, if deemed non-threatening, add their parent process names or command lines to the exclusion list to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the suspicious process executions to determine if they were part of a legitimate operation or a potential attack. Review process arguments and parent processes for anomalies.
+- Analyze system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary.
+- If malicious activity is confirmed, terminate any unauthorized processes and remove any malicious files or scripts identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships, to aid in future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for potential threats.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are in place.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Implement hardening measures such as disabling unnecessary utilities, enforcing least privilege access, and conducting regular security audits to reduce the attack surface and prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
index d3826371012..c06105be566 100644
--- a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
+++ b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,49 @@ process where event.type == "start" and event.action in ("exec", "exec_event") a
 ) and 
 not process.parent.name in ("amazon-ssm-agent", "snap")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Process Discovery via Built-In Applications
+
+Built-in applications like `ps`, `pstree`, `htop`, and `pgrep` are essential for system administrators to monitor and manage processes on endpoints. However, adversaries exploit these tools to gain insights into running processes, aiding in lateral movement or privilege escalation. The detection rule identifies suspicious use of these tools by monitoring process start events, filtering out benign parent processes like system management agents, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name matches one of the built-in tools: `ps`, `pstree`, `htop`, or `pgrep`.
+- Check the `event.type` and `event.action` fields to ensure the event corresponds to a process start with actions like "exec" or "exec_event".
+- Investigate the `process.parent.name` to verify it is not a benign process like "amazon-ssm-agent" or "snap", which are filtered out in the detection rule.
+- Examine the timestamp of the event to determine if it coincides with any known scheduled tasks or maintenance windows.
+- Correlate the event with user activity by checking the user account associated with the process start event to identify if it aligns with expected behavior.
+- Use Osquery to gather additional context about the process. For example, run the query: `SELECT * FROM processes WHERE name IN ('ps', 'pstree', 'htop', 'pgrep');` to list all instances of these processes and their details.
+- Investigate the command line arguments used with the process to identify any unusual or suspicious parameters that could indicate malicious intent.
+- Check for any network connections or file modifications initiated by the process to assess if it is part of a larger attack chain.
+- Review historical data to determine if there have been previous instances of similar process discovery activities on the endpoint.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors associated with the use of these tools in a malicious context.
+
+### False positive analysis
+
+- System administrators and automated scripts often use built-in tools like `ps`, `pstree`, `htop`, and `pgrep` for legitimate monitoring and management tasks, which can trigger false positives in the detection rule.
+- Regularly scheduled maintenance tasks or health checks performed by IT teams may also appear as suspicious activity if they involve these tools.
+- To manage these false positives, users can create exceptions for known benign parent processes or specific user accounts that frequently execute these commands as part of their routine operations.
+- Implementing a whitelist for certain processes or users that are verified to perform legitimate activities can help reduce noise and focus on truly suspicious events.
+- Monitoring the frequency and context of these tool executions can aid in distinguishing between normal administrative use and potential malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected endpoint from the network to prevent further lateral movement by the adversary.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or privilege escalation attempts.
+- Review process execution logs to identify any unusual patterns or anomalies that could indicate malicious activity.
+- Terminate any suspicious processes identified during the investigation to prevent further exploitation.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
+- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
+- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures such as disabling unnecessary built-in tools or restricting their use to authorized personnel only.
+- Provide training and awareness sessions for system administrators and users to recognize signs of process discovery attempts and report suspicious activities promptly."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_signal_unusual_user_host.toml b/rules_building_block/discovery_signal_unusual_user_host.toml
index ac2bc337f90..524063c3552 100644
--- a/rules_building_block/discovery_signal_unusual_user_host.toml
+++ b/rules_building_block/discovery_signal_unusual_user_host.toml
@@ -2,7 +2,7 @@
 bypass_bbr_timing = true
 creation_date = "2023/10/10"
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,48 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
   "1d72d014-e2ab-4707-b056-9b96abe7b511"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Discovery Activity by User
+
+The 'Unusual Discovery Activity by User' detection rule identifies atypical behavior by monitoring alert data for unique host and user identifiers. This technology is crucial in environments to detect when adversaries exploit discovery techniques to gather system information. By correlating signals from multiple sources, the rule flags potential reconnaissance activities, helping analysts preemptively address threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific host.id and user.id involved in the unusual activity.
+- Cross-reference the host.os.type field to confirm the operating system is Windows, as specified in the query.
+- Examine the event.kind field to ensure the alert is based on a signal, indicating potential reconnaissance activity.
+- Investigate the specific Discovery building block rule IDs (e.g., "d68e95ad-1c82-4074-a12a-125fe10ac8ba") that triggered the alert to understand the context and type of discovery technique used.
+- Check historical data for the same host.id and user.id to determine if this activity is part of a pattern or a one-time occurrence.
+- Use Osquery to gather additional system information. For example, run the query: `SELECT * FROM processes WHERE user = '<user.id>' AND host = '<host.id>';` to identify any unusual processes initiated by the user on the host.
+- Analyze network logs for any unusual outbound connections from the host that might indicate data exfiltration or further reconnaissance.
+- Review user activity logs to identify any recent changes in behavior or access patterns that could correlate with the alert.
+- Correlate the alert with other security events or alerts from the same timeframe to identify potential lateral movement or coordinated attacks.
+- Consult threat intelligence sources to determine if the observed activity matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors.
+
+### False positive analysis
+
+- Known false positives for the 'Unusual Discovery Activity by User' rule often arise from legitimate administrative tasks or automated scripts that perform system discovery operations. These activities can mimic reconnaissance techniques but are non-threatening.
+- Frequent system scans by IT management tools or security software can trigger alerts. These should be reviewed and, if deemed safe, excluded from future alerts by adding them to an exception list.
+- Users can manage false positives by identifying and documenting regular maintenance activities that align with the rule's detection criteria. Once identified, these activities can be excluded by creating exceptions based on specific host.id and user.id combinations.
+- It's important to regularly review and update exception lists to ensure that new legitimate activities are accounted for while maintaining the rule's effectiveness in detecting genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Conduct a thorough investigation of the alert by reviewing the associated host.id and user.id to determine the scope and impact of the unusual activity.
+- Analyze logs and signals from the identified host to identify any unauthorized access or data exfiltration attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed to be malicious or if it involves sensitive systems or data.
+- Remediate the affected system by removing any discovered malware or unauthorized tools and patching any vulnerabilities that may have been exploited.
+- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensuring all security controls are re-enabled.
+- Implement enhanced logging policies to capture detailed information on user and host activities, focusing on discovery and reconnaissance techniques.
+- Integrate additional security tools and threat intelligence feeds to improve detection capabilities and provide context for future investigations.
+- Review and update access controls and user permissions to minimize the risk of unauthorized discovery activities.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as disabling unnecessary services and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_suspicious_proc_enumeration.toml b/rules_building_block/discovery_suspicious_proc_enumeration.toml
index 5416dfa0a22..3006da567c8 100644
--- a/rules_building_block/discovery_suspicious_proc_enumeration.toml
+++ b/rules_building_block/discovery_suspicious_proc_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/09"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,49 @@ file.path : (/proc/*/cmdline or /proc/*/stat or /proc/*/exe) and not process.nam
   ps or netstat or landscape-sysin or w or pgrep or pidof or needrestart or apparmor_status
 ) and not process.parent.pid : 1
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Suspicious Proc Pseudo File System Enumeration
+
+The proc pseudo file system in Linux provides a window into the kernel and running processes, offering critical insights for system management. Adversaries exploit this by rapidly accessing multiple proc files to gather intelligence on active processes, potentially for reconnaissance or privilege escalation. The detection rule identifies such behavior by monitoring for unusual access patterns to specific proc files, excluding benign processes, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific proc files were accessed and by which process, focusing on the `file.path` and `process.name` fields.
+- Check the `process.parent.pid` to identify the parent process of the suspicious activity, as this can provide context on how the process was initiated.
+- Investigate the timeline of events leading up to the alert by examining logs for any related file access or process creation events.
+- Use Osquery to gather more information about the suspicious process. For example, run the query: `SELECT pid, name, path, cmdline, parent FROM processes WHERE pid = <suspicious_pid>;` to get details about the process and its parent.
+- Analyze the command line arguments (`cmdline`) of the suspicious process to determine its intended actions and whether they align with legitimate activities.
+- Cross-reference the `process.name` and `process.parent.pid` with known benign processes to rule out false positives.
+- Check for any recent changes or anomalies in user accounts or permissions that could be related to the suspicious process.
+- Investigate network activity associated with the suspicious process to identify any external connections or data exfiltration attempts.
+- Review historical data to determine if similar patterns of proc file enumeration have occurred in the past, indicating a persistent threat.
+- Consult threat intelligence sources to see if the process name or behavior matches any known malicious activity or indicators of compromise.
+
+### False positive analysis
+
+- System monitoring tools and legitimate administrative scripts may trigger the rule by accessing multiple proc files in a short period, as part of their normal operation. These tools often perform routine checks on system processes and should be reviewed to determine if they are benign.
+- Automated backup or system management software might also exhibit similar access patterns to the proc file system, especially during scheduled tasks. Identifying these processes and adding them to an exception list can help reduce false positives.
+- Developers and system administrators running diagnostic or performance analysis scripts may inadvertently trigger the rule. These scripts should be evaluated for their necessity and frequency, and exceptions can be made for known safe scripts.
+- Security software performing regular scans or checks on system processes might access proc files rapidly. It's important to verify the legitimacy of such software and consider excluding it from the rule if it is deemed safe.
+- To manage false positives, users can create exceptions by adding known benign process names or parent process IDs to the exclusion list in the detection rule. Regularly updating this list based on observed patterns and operational needs will help maintain the accuracy of threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary.
+- Conduct a thorough investigation to identify the process responsible for the suspicious enumeration by analyzing logs and process details.
+- Terminate any malicious or unauthorized processes identified during the investigation to halt further malicious activity.
+- Review and analyze the system's recent activity and changes to identify any additional indicators of compromise or persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced logging policies to capture detailed process and file access activities, ensuring future suspicious behaviors are detected promptly.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by applying necessary patches, updates, and verifying the integrity of critical system files.
+- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
+- Implement system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_network_connections.toml b/rules_building_block/discovery_system_network_connections.toml
index 146fae92b45..11b6cc0d189 100644
--- a/rules_building_block/discovery_system_network_connections.toml
+++ b/rules_building_block/discovery_system_network_connections.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,49 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name in ("netstat", "lsof", "who", "w")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 System Network Connections Discovery
+
+System network connections discovery involves tools like `netstat` and `lsof` to list active connections, aiding in network diagnostics. Adversaries exploit this to map network topology and identify potential targets. The detection rule monitors process initiation events for these tools, flagging suspicious activity indicative of reconnaissance efforts, aligning with MITRE ATT&CK's discovery tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name involved is either "netstat", "lsof", "who", or "w" and verify the event type is "start" with actions like "exec", "exec_event", "executed", or "process_started".
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
+- Identify the user account associated with the process initiation to determine if it aligns with expected behavior or if it might be a compromised account.
+- Investigate the parent process of the flagged process to understand how it was initiated and if it was spawned by a legitimate or suspicious application.
+- Examine the command line arguments used with the process to gather more context on what specific network information the adversary might be targeting.
+- Utilize Osquery to further investigate by running a query such as `SELECT * FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name = 'netstat' OR name = 'lsof');` to identify active network connections associated with the suspicious process.
+- Cross-reference the network connections discovered with known malicious IP addresses or domains to identify potential communication with threat actors.
+- Analyze historical data to determine if there have been previous instances of similar process executions and if they correlate with any known attack patterns.
+- Review system logs and network traffic logs for any anomalies or indicators of compromise that coincide with the time of the alert.
+- Consult threat intelligence sources to check for any recent campaigns or tactics involving the use of these tools for reconnaissance purposes.
+
+### False positive analysis
+
+- Routine administrative tasks often involve the use of `netstat` and `lsof` for legitimate network diagnostics, which can trigger false positives. System administrators frequently use these tools to monitor network performance and troubleshoot issues.
+- Automated scripts and monitoring tools may execute `netstat` or `lsof` as part of regular system health checks, leading to benign process initiation events being flagged.
+- Security software and network management applications might utilize these commands to gather network statistics, which can be mistaken for adversarial reconnaissance.
+- To manage false positives, users can create exceptions for known administrative accounts or specific scripts that regularly execute these commands. This can be done by excluding certain user accounts or process paths from the detection rule.
+- Implementing a baseline of normal network diagnostic activities can help differentiate between legitimate use and potential threats, allowing for more accurate detection and fewer false alarms.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Conduct a thorough investigation of the process initiation events to confirm whether the use of tools like netstat or lsof was authorized or indicative of malicious activity.
+- Review system logs and network traffic to identify any unauthorized access or data exfiltration attempts that may have occurred.
+- If unauthorized activity is confirmed, perform a full malware scan and remove any identified threats from the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar reconnaissance activities.
+- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are hardened.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_service_discovery.toml b/rules_building_block/discovery_system_service_discovery.toml
index c70601ed3a0..9e37bb40288 100644
--- a/rules_building_block/discovery_system_service_discovery.toml
+++ b/rules_building_block/discovery_system_service_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/01/24"
 integration = ["windows", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,48 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : "psservice.exe" or process.pe.original_file_name == "psservice.exe")
   ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 System Service Discovery through built-in Windows Utilities
+
+System service discovery is a technique used to enumerate services running on a Windows system, often leveraging built-in utilities like `net.exe`, `sc.exe`, and `tasklist.exe`. Adversaries exploit these tools to gather information about the system's services, which can aid in privilege escalation or lateral movement. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and process behaviors, excluding known benign system accounts, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the detection, focusing on `process.name` and `process.args`.
+- Check the `user.id` associated with the process to determine if it is a known or unknown user, and verify if it deviates from normal behavior.
+- Investigate the parent process of the suspicious activity using `process.parent.name` to understand the context in which the utility was executed.
+- Examine the `host.os.type` and `event.type` fields to confirm the environment and nature of the event, ensuring it aligns with the detection criteria.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('net.exe', 'sc.exe', 'tasklist.exe', 'psservice.exe');`
+- Analyze recent login events and user activity on the host to identify any unusual patterns or unauthorized access attempts.
+- Correlate the event with other logs, such as network or authentication logs, to identify any related suspicious activities or lateral movement attempts.
+- Check for any recent changes in system services or configurations that could indicate tampering or unauthorized modifications.
+- Investigate the timeline of events leading up to and following the alert to identify any potential precursor or follow-up activities.
+- Review historical data for similar alerts on the same host or user to determine if this is part of a recurring pattern or isolated incident.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use utilities like `net.exe`, `sc.exe`, and `tasklist.exe` for legitimate purposes such as service management and system monitoring. These activities can trigger false positives. To manage this, create exceptions for known administrative accounts or specific command-line patterns that are part of regular maintenance activities.
+- Automated scripts and management tools: Organizations may deploy scripts or third-party management tools that utilize these utilities for system checks and reporting. Identify and whitelist these scripts or tools by their process names or specific command-line arguments to reduce false positives.
+- Software updates and installations: Some software installations or updates may invoke these utilities to configure or verify services. Monitor installation logs and correlate with detection events to identify benign activities, then exclude these specific processes or arguments from triggering alerts.
+- Security software operations: Certain security solutions might use these utilities as part of their scanning or monitoring processes. Verify with the security software vendor and exclude these operations by process name or user account to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or changes to system services.
+- Review the command-line arguments and process behaviors flagged by the detection rule to confirm malicious activity and gather intelligence on the adversary's tactics.
+- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed as malicious, providing them with all relevant logs and findings.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations, ensuring that all relevant data is retained for analysis.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats in the future.
+- Restore the system to its operational state by removing any unauthorized services or changes made by the adversary, and apply security patches to address any vulnerabilities exploited during the attack.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update security policies and procedures accordingly.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and using application whitelisting to reduce the attack surface.
+- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_time_discovery.toml b/rules_building_block/discovery_system_time_discovery.toml
index d58b327e2a1..f3d41b88e55 100644
--- a/rules_building_block/discovery_system_time_discovery.toml
+++ b/rules_building_block/discovery_system_time_discovery.toml
@@ -5,7 +5,7 @@ integration = ["windows", "endpoint", "system"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,47 @@ process where host.os.type == "windows" and event.type == "start" and
  (process.name: "tzutil.exe" and process.args: "/g")
 ) and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 System Time Discovery
+System time discovery involves querying a system's time settings, often used by attackers to synchronize their activities or evade detection. Adversaries may exploit commands like `net time`, `w32tm`, or `tzutil` to gather time-related information. The detection rule identifies suspicious use of these commands, excluding legitimate system accounts, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
+- Check the `user.id` field to identify the user account associated with the process execution and verify if it is a known or expected user.
+- Investigate the `process.parent.name` to understand the parent process that initiated the suspicious command, which might provide context on how the command was executed.
+- Examine the `host.os.type` to ensure the alert is relevant to a Windows system, as the rule is designed for Windows environments.
+- Correlate the event timestamp with other logs to identify any concurrent suspicious activities or patterns that might indicate a broader attack.
+- Use Osquery to gather additional context on the system's time settings and recent changes. For example, run the query: `SELECT * FROM time;` to retrieve current system time details.
+- Investigate any recent logins or user activity around the time of the alert to determine if there was unauthorized access or unusual behavior.
+- Check for any recent changes to system time settings or configurations that could indicate tampering, using system logs or configuration management tools.
+- Review network logs for any outbound connections around the time of the alert that could suggest data exfiltration or communication with a command and control server.
+- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or campaigns.
+
+### False positive analysis
+
+- Scheduled tasks or scripts that regularly check system time settings for synchronization purposes may trigger false positives. Users can handle these by identifying and excluding specific scripts or task names from the detection rule.
+- IT administrative tools or monitoring software that perform routine checks on system time settings might be flagged. To manage this, users should whitelist these tools by adding their process names or user IDs to the exception list.
+- Legitimate software updates or installations that require time synchronization could also be mistakenly identified. Users can mitigate this by monitoring the context of these activities and excluding known update processes.
+- In environments where time synchronization is critical, such as financial institutions, frequent legitimate use of time-related commands may occur. Users should document these use cases and adjust the detection rule to exclude them, ensuring that only unexpected or unusual activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activities and lateral movement.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional indicators of compromise (IOCs) related to system time discovery.
+- Review and analyze logs from the affected system and any associated systems to trace the attacker's activities and identify any other compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
+- Remediate the affected system by removing any malicious software or unauthorized changes, and restore the system to a known good state using backups if necessary.
+- Implement enhanced logging policies to capture detailed process execution and command-line arguments to improve future detection capabilities.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance monitoring and detection of similar threats.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface.
+- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness and response readiness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
index 86698b83778..c42f45b852a 100644
--- a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
+++ b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/14"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,48 @@ event.dataset:aws.cloudtrail
     and event.action:DescribeInstanceAttribute
     and aws.cloudtrail.request_parameters:(*attribute=userData* and *instanceId*)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Retrieve User Data from AWS EC2 Instance
+
+AWS EC2 instances can store sensitive configuration data in user data scripts, which are executed at launch. Adversaries may exploit the `DescribeInstanceAttribute` API call to access this data, potentially exposing vulnerabilities or sensitive information. The detection rule monitors AWS CloudTrail logs for this API call targeting user data, signaling potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the `DescribeInstanceAttribute` API call with `attribute=userData` and `instanceId` was executed, ensuring the event dataset is `aws.cloudtrail`.
+- Identify the source IP address and user agent associated with the API call to determine if it aligns with known or expected activity.
+- Check the AWS IAM user or role that initiated the API call to verify if it has legitimate access to the EC2 instance.
+- Investigate the time and frequency of the API call to assess if it coincides with any scheduled tasks or known maintenance activities.
+- Cross-reference the `instanceId` with your asset inventory to determine the sensitivity and criticality of the EC2 instance involved.
+- Examine the AWS CloudTrail logs for any other suspicious activities or API calls made by the same IAM user or role around the same timeframe.
+- Utilize Osquery to gather additional context from the EC2 instance by running a query such as: `SELECT * FROM ec2_instance_metadata WHERE key = 'user-data';` to verify if any unauthorized changes or access attempts have been made.
+- Analyze any recent changes to the IAM policies or roles associated with the EC2 instance to identify potential misconfigurations or privilege escalations.
+- Review the security group and network ACL configurations for the EC2 instance to ensure they are not overly permissive and align with security best practices.
+- Consult with the instance owner or relevant stakeholders to validate if the API call was part of an authorized operation or if further investigation is warranted.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators or automated scripts may regularly use the `DescribeInstanceAttribute` API call to check or update configurations, leading to benign occurrences of this event. Users can handle these by creating exceptions for known administrative accounts or scripts that frequently perform this action.
+- Monitoring and auditing tools: Security and compliance tools might invoke the `DescribeInstanceAttribute` API call as part of their regular monitoring activities. To manage these, users can whitelist specific tools or services that are known to perform legitimate monitoring.
+- Cloud management platforms: Third-party cloud management solutions may use this API call to gather information about EC2 instances for inventory or management purposes. Users should identify and exclude these platforms from triggering alerts by adding them to an exception list.
+- Development and testing environments: In environments where developers frequently launch and configure EC2 instances, the `DescribeInstanceAttribute` call may be part of normal operations. Users can reduce false positives by excluding specific development accounts or environments from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance to prevent further unauthorized access and data exfiltration.
+- Review AWS CloudTrail logs to identify the source of the DescribeInstanceAttribute API call and determine if it was authorized or part of a larger attack.
+- Revoke any suspicious or unauthorized access keys and credentials associated with the compromised instance.
+- Conduct a thorough investigation to assess the extent of the data exposure and identify any other potentially affected resources.
+- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are required.
+- Implement enhanced logging and monitoring policies to capture detailed API activity, focusing on sensitive operations like DescribeInstanceAttribute.
+- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities within your AWS environment.
+- Restore the EC2 instance from a known good backup if necessary, ensuring that all security patches and updates are applied.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have access to sensitive operations.
+- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and multi-factor authentication, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_win_network_connections.toml b/rules_building_block/discovery_win_network_connections.toml
index dc1f9d25751..d50f53e8710 100644
--- a/rules_building_block/discovery_win_network_connections.toml
+++ b/rules_building_block/discovery_win_network_connections.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,49 @@ process where event.type == "start" and
   (process.name : "nbtstat.exe" and process.args : "-s*")
 ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows System Network Connections Discovery
+
+Windows systems provide utilities like `netstat`, `net`, and `nbtstat` to manage and monitor network connections. Adversaries exploit these tools to map network connections, identifying potential targets. The detection rule flags unusual use of these commands, especially when executed by non-system users, to uncover unauthorized network enumeration attempts, thereby helping analysts identify potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command executed, including the process name and arguments, to understand the context of the network enumeration attempt.
+- Check the user ID associated with the process execution to determine if it was initiated by a non-system user, as indicated by the exclusion of user ID "S-1-5-18".
+- Investigate the parent process of the suspicious command to identify if it was spawned by a legitimate process or potentially malicious activity.
+- Examine the process start time to correlate with other events or activities on the system that might indicate a broader attack pattern.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name IN ('netstat.exe', 'net.exe', 'net1.exe', 'nbtstat.exe');` to retrieve details about the process execution.
+- Analyze network logs to identify any unusual outbound or inbound connections that coincide with the execution of the flagged command.
+- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized users to execute network discovery commands.
+- Review system logs for any other suspicious activities or anomalies around the time of the alert to identify potential lateral movement or privilege escalation attempts.
+- Investigate the system for any signs of compromise, such as unexpected files, scheduled tasks, or registry changes, that could indicate a broader intrusion.
+- Correlate the findings with threat intelligence sources to determine if the activity matches known tactics, techniques, and procedures (TTPs) of adversaries targeting similar environments.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use `netstat`, `net`, and `nbtstat` for legitimate network management and troubleshooting, which can trigger the rule. To manage this, create exceptions for specific user accounts or processes known to perform these tasks regularly.
+- Automated scripts: Scheduled scripts or automated tools that perform network diagnostics or inventory checks may execute these commands. Identify and exclude these scripts by their process names or paths to reduce false positives.
+- Monitoring software: Network monitoring or security software might use these commands to gather network data. Verify the legitimacy of such software and exclude its processes from the rule.
+- System updates or patches: Some system updates or patches might temporarily use these commands as part of their installation process. Monitor update schedules and exclude related processes during these times.
+- Training or testing environments: In environments where users are trained on network management or security testing, these commands might be used frequently. Consider excluding specific user IDs or machine names associated with these environments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation of the system to identify any additional signs of compromise, focusing on unusual processes, network connections, and user activities.
+- Review the execution context of the flagged commands, including the user account and associated processes, to determine if the activity was authorized or malicious.
+- Escalate the incident to the security operations center (SOC) or incident response team if unauthorized network enumeration is confirmed, providing them with detailed logs and findings.
+- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future incidents can be detected and analyzed more effectively.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
+- Restore the system to its operational state by removing any malicious software, resetting compromised credentials, and applying necessary security patches.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Implement network segmentation and access controls to limit the ability of adversaries to move laterally within the environment.
+- Educate users on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security policies and procedures."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_windows_system_information_discovery.toml b/rules_building_block/discovery_windows_system_information_discovery.toml
index af6dab02a4d..3aa17611d62 100644
--- a/rules_building_block/discovery_windows_system_information_discovery.toml
+++ b/rules_building_block/discovery_windows_system_information_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/06"
 integration = ["windows", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,49 @@ process.parent.executable : (
     "?:\\ProgramData\\*"
 ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Windows System Information Discovery
+
+Windows System Information Discovery involves using built-in commands to gather system details, aiding attackers in understanding the environment post-compromise. Adversaries exploit tools like `cmd.exe`, `systeminfo.exe`, and `wmic.exe` to extract OS and hardware data. The detection rule identifies suspicious use of these commands, excluding legitimate processes and system accounts, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific command triggered the detection, focusing on the `process.name` and `process.args` fields.
+- Check the `process.parent.executable` field to identify the parent process that initiated the suspicious command, which can provide context on whether the execution was part of a legitimate process chain.
+- Investigate the `user.id` associated with the process to determine if the activity was performed by a legitimate user or a potentially compromised account.
+- Examine the `host.os.type` and `event.type` fields to confirm the environment and nature of the event, ensuring it aligns with the detection rule's focus on Windows systems and process start events.
+- Correlate the timestamp of the alert with other security events or logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Use Osquery to gather additional context about the system and processes. For example, run the following Osquery query to list recent processes executed on the system: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cmd.exe', 'systeminfo.exe', 'wmic.exe');`
+- Investigate the network activity around the time of the alert to identify any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
+- Review historical data for similar alerts on the same host or user account to determine if this is an isolated incident or part of a recurring pattern.
+- Check for any recent changes in user permissions or system configurations that could have facilitated the execution of the suspicious command.
+- Consult threat intelligence sources to see if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware campaigns.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they use `cmd.exe`, `systeminfo.exe`, or `wmic.exe` to check system compatibility or gather system information. Users can handle these by adding specific update or installation executables to the exclusion list.
+- System management tools or scripts that regularly run to gather system information for inventory or monitoring purposes might be flagged. To manage these, users should identify and exclude the specific scripts or management tools from the detection rule.
+- Automated tasks or scheduled jobs that use these commands for legitimate system maintenance or reporting can also cause false positives. Users can exclude these tasks by specifying the parent executable paths or user accounts associated with these jobs.
+- Developers or IT personnel running diagnostic commands during troubleshooting or system checks may inadvertently trigger the rule. Organizations can create exceptions for known user accounts or specific development environments to reduce false positives.
+- Security software or endpoint protection solutions that perform regular system scans and use these commands might be mistakenly flagged. Users should verify and exclude these security tools from the detection criteria to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the attacker.
+- Conduct a thorough investigation to confirm the legitimacy of the detected activity by reviewing process execution details and correlating with known user behavior.
+- If malicious activity is confirmed, terminate any suspicious processes and remove any unauthorized tools or scripts found on the system.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Review and enhance logging policies to ensure comprehensive monitoring of command-line activities and process executions, focusing on the use of system information discovery tools.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for future investigations.
+- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
+- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and applying application whitelisting to prevent unauthorized execution of system discovery tools.
+- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
+- Educate users on recognizing and reporting suspicious activities to enhance the organization's overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_aws_lambda_function_updated.toml b/rules_building_block/execution_aws_lambda_function_updated.toml
index 773ea2fdede..15fa498aa34 100644
--- a/rules_building_block/execution_aws_lambda_function_updated.toml
+++ b/rules_building_block/execution_aws_lambda_function_updated.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,50 @@ event.dataset: "aws.cloudtrail"
     and event.outcome: "success"
     and event.action: (CreateFunction* or UpdateFunctionCode*)
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS Lambda Function Created or Updated
+
+AWS Lambda allows execution of code without server management, streamlining deployment. However, adversaries may exploit this by creating or updating functions to run harmful code, steal data, or gain unauthorized access. The detection rule monitors successful creation or updates of Lambda functions, flagging potential misuse by identifying specific actions within AWS CloudTrail logs.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the specific Lambda function that was created or updated by examining the `event.action` field for "CreateFunction" or "UpdateFunctionCode".
+- Check the `event.userIdentity` field to determine the identity of the user or service that performed the action, and verify if this aligns with expected behavior or known accounts.
+- Analyze the `event.time` field to understand when the function was created or updated, and correlate this with other activities in the environment to identify any suspicious patterns.
+- Investigate the `event.sourceIPAddress` field to determine the origin of the request, and assess if the IP address is known or associated with any previous suspicious activities.
+- Examine the `event.requestParameters` field to gather details about the function, such as its name, runtime, and any environment variables that might have been set.
+- Utilize Osquery to further investigate by running a query to list all AWS Lambda functions and their configurations, for example: `SELECT * FROM aws_lambda_functions WHERE function_name = 'suspicious_function_name';`
+- Cross-reference the Lambda function's ARN (Amazon Resource Name) with IAM policies and roles to ensure that permissions are appropriate and have not been overly permissive.
+- Review the function's code or any associated S3 buckets for signs of malicious code or scripts that could indicate tampering or unauthorized changes.
+- Check for any recent changes in the AWS environment that might coincide with the Lambda function creation or update, such as new IAM roles or changes to security groups.
+- Investigate any related alerts or logs from other security tools that might provide additional context or corroborate suspicious activity related to the Lambda function.
+
+### False positive analysis
+
+- Routine updates or deployments by authorized personnel can trigger the rule, as legitimate development and maintenance activities often involve creating or updating Lambda functions.
+- Automated deployment tools or CI/CD pipelines that frequently update Lambda functions as part of regular operations may also cause false positives.
+- Scheduled updates or function optimizations performed by DevOps teams can be mistaken for suspicious activity.
+- To manage these false positives, users can create exceptions for known, trusted accounts or roles that regularly perform these actions.
+- Implementing a whitelist of specific Lambda function names or tags associated with routine updates can help reduce noise.
+- Monitoring the context of the changes, such as the source IP address or the IAM user making the changes, can assist in distinguishing between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS Lambda function by disabling it to prevent further execution of potentially malicious code.
+- Review AWS CloudTrail logs to identify unauthorized access patterns or suspicious activities related to the Lambda function creation or update.
+- Conduct a thorough code review of the affected Lambda function to identify and remove any malicious code or unauthorized changes.
+- Revert the Lambda function to a known good state using version control or backups, ensuring that only authorized code is deployed.
+- Implement AWS Identity and Access Management (IAM) policies to restrict permissions for creating or updating Lambda functions to only trusted users and roles.
+- Enable detailed logging and monitoring for AWS Lambda and related services to detect future unauthorized changes or executions.
+- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance real-time threat detection and response capabilities.
+- Escalate the incident to the security team if evidence of broader compromise or data exfiltration is found, following the organization's incident response plan.
+- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
+- Apply hardening measures such as enabling AWS Lambda function environment variable encryption and using AWS Key Management Service (KMS) for sensitive data protection."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_event_action_for_pat.toml b/rules_building_block/execution_github_new_event_action_for_pat.toml
index e8ab2101ae1..7870f906daf 100644
--- a/rules_building_block/execution_github_new_event_action_for_pat.toml
+++ b/rules_building_block/execution_github_new_event_action_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,49 @@ event.dataset:"github.audit" and event.category:"configuration" and
 event.action:* and github.hashed_token:* and 
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence GitHub Event for a Personal Access Token (PAT)
+
+Personal Access Tokens (PATs) in GitHub provide a way to authenticate programmatic access to repositories, enabling automation and integration. Adversaries may exploit PATs to gain unauthorized access, execute code, or exfiltrate data. The detection rule identifies new PAT events not seen in the past 14 days, flagging potential misuse by monitoring specific GitHub audit logs and access patterns.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to identify the specific event details, focusing on the `event.dataset:"github.audit"` and `event.category:"configuration"` fields to understand the context of the PAT usage.
+- Examine the `event.action` field to determine the specific action that triggered the alert, which can provide insights into the nature of the access or configuration change.
+- Investigate the `github.hashed_token` field to identify the specific PAT involved and check if it matches any known tokens or patterns associated with legitimate users or applications.
+- Analyze the `github.programmatic_access_type` field to determine whether the access was through an "OAuth access token" or a "Fine-grained personal access token," which can help assess the level of access granted.
+- Cross-reference the PAT event with recent user activity logs to identify any unusual patterns or anomalies in user behavior that might indicate misuse or compromise.
+- Use Osquery to gather additional context on the system or environment where the PAT was used. For example, run the following Osquery query to list recent network connections that might correlate with the PAT usage: `SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL;`
+- Check for any recent changes in repository permissions or settings that might have coincided with the PAT event, which could indicate an attempt to escalate privileges or exfiltrate data.
+- Investigate any associated IP addresses or geolocations from which the PAT was used to determine if they align with expected user locations or if they suggest unauthorized access.
+- Review any recent changes to the repositories accessed using the PAT to identify potential unauthorized modifications or data exfiltration attempts.
+- Collaborate with the user or team associated with the PAT to verify the legitimacy of the token and understand the intended use case, which can help determine if the alert is a false positive or a genuine security concern.
+
+### False positive analysis
+
+- Frequent legitimate automation scripts or integrations may trigger false positives if they generate new PATs regularly. Users can manage these by creating exceptions for known scripts or applications that are verified as non-threatening.
+- Developers or teams who rotate their PATs as part of a security best practice might also cause false positives. To handle this, users can maintain a list of accounts or tokens that are expected to rotate frequently and exclude them from alerts.
+- Testing environments or sandbox accounts that frequently generate and revoke PATs for testing purposes can be another source of false positives. Users should consider excluding these environments from the detection rule or setting up specific monitoring that accounts for their unique behavior.
+- In organizations with high developer turnover, new developers may frequently create PATs, leading to false positives. Implementing a process to quickly verify new developer accounts and their associated PATs can help mitigate this issue.
+- Users can also adjust the detection rule to include additional context, such as IP address or user agent, to better differentiate between legitimate and suspicious activity, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately revoke the identified Personal Access Token (PAT) to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying any repositories accessed using the compromised PAT.
+- Review GitHub audit logs for any suspicious activities or anomalies associated with the compromised PAT.
+- Notify the affected repository owners and stakeholders about the potential breach and actions taken.
+- Escalate the incident to the security team for further analysis and to determine if additional systems or data were affected.
+- Implement enhanced logging and monitoring for GitHub activities to detect similar incidents in the future.
+- Educate users on secure PAT management practices, including regular rotation and using fine-grained permissions.
+- Integrate security tools with GitHub to automate the detection of anomalous PAT usage and other security events.
+- Restore any affected systems or repositories to their last known good state, ensuring no malicious code or data remains.
+- Apply hardening measures such as enforcing multi-factor authentication (MFA) for all GitHub accounts and restricting PAT usage to specific IP addresses or environments."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
index af1fe749b4a..23ee919a82f 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -36,6 +36,48 @@ 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
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT)
+
+GitHub Personal Access Tokens (PATs) enable programmatic access to repositories, facilitating automation and integration. However, adversaries can exploit compromised PATs to access private repositories, potentially exfiltrating sensitive data. This detection rule identifies unusual private repo interactions by monitoring for PAT activity not observed in the past 14 days, signaling potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific GitHub Personal Access Token (PAT) involved, using the `github.hashed_token` field for reference.
+- Check the `event.dataset` and `event.category` fields to confirm the event is related to GitHub audit logs and configuration changes, ensuring the alert is valid.
+- Investigate the `github.repo` field to determine which private repository was accessed and assess the sensitivity of the data within.
+- Verify the `github.programmatic_access_type` to understand the type of access token used, distinguishing between "OAuth access token" and "Fine-grained personal access token."
+- Examine the user or service account associated with the PAT to determine if the access was expected or authorized.
+- Cross-reference the PAT activity with recent user activity logs to identify any anomalies or patterns that could indicate unauthorized access.
+- Utilize Osquery to gather additional context on the system where the PAT might have been used. Example query: `SELECT * FROM processes WHERE name LIKE '%git%' AND cmdline LIKE '%<hashed_token_value>%';` to find processes using the token.
+- Check for any recent changes in the repository's access permissions or settings that could have facilitated unauthorized access.
+- Investigate any other recent alerts or incidents involving the same PAT or repository to identify potential patterns or related threats.
+- Collaborate with the repository owner or relevant stakeholders to verify if the access was legitimate and gather additional context on the PAT's intended use.
+
+### False positive analysis
+
+- Regularly scheduled automated tasks or scripts using GitHub PATs may trigger this rule if they interact with private repositories infrequently, such as once a month. Users can manage this by creating exceptions for known, trusted scripts or automation tools that are expected to access private repositories periodically.
+- Developers or team members who rotate their PATs for security reasons might cause false positives when accessing private repositories with a new token. To handle this, maintain a list of authorized personnel and their expected access patterns, and update the monitoring system to recognize these changes as non-threatening.
+- Integration tools or third-party services that use PATs for legitimate access to private repositories might be flagged if they have not interacted with the repository in the past 14 days. Users should document and whitelist these services to prevent unnecessary alerts.
+- Temporary access granted to contractors or external collaborators using PATs could be misidentified as unauthorized access. Ensure that any temporary access is logged and that exceptions are in place for the duration of their engagement to avoid false positives.
+
+### Response and remediation
+
+- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access.
+- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized changes or data exfiltration.
+- Notify the affected repository owners and stakeholders about the potential breach and advise them to review their repositories for any suspicious activity.
+- Escalate the incident to the security team for a comprehensive investigation and to determine the scope of the breach.
+- Implement enhanced logging and monitoring for all PAT activities to detect unusual patterns and potential threats in the future.
+- Integrate security tools with GitHub to automate the detection of anomalous activities and improve response times.
+- Review and update access controls and permissions for all repositories to ensure the principle of least privilege is enforced.
+- Conduct a security awareness session for developers and repository managers on the importance of securing PATs and recognizing phishing attempts.
+- Restore any affected systems or repositories to their last known good state, ensuring that all unauthorized changes are reverted.
+- Implement additional security measures such as multi-factor authentication (MFA) for accessing sensitive repositories and resources."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_user.toml b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
index 5aabab32d3c..6fe2af7c8b1 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_user.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,48 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.repo:* and user.name:* and 
 github.repository_public:false
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of GitHub User Interaction with Private Repo
+
+GitHub is a platform for version control and collaboration, often hosting private repositories for sensitive projects. Adversaries may exploit unauthorized access to these private repos to exfiltrate data or inject malicious code. The detection rule identifies unusual user interactions with private repos by flagging users who haven't accessed them in the past 14 days, helping to spot potential breaches early.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user (`user.name`) and repository (`github.repo`) involved in the interaction.
+- Verify the user's access history to confirm that this is indeed the first interaction with the private repository in the last 14 days.
+- Check the user's recent activity logs on GitHub to identify any other unusual behavior or access patterns.
+- Investigate the repository's access logs to determine if there have been any other unusual access attempts or changes.
+- Cross-reference the user's access with known project timelines or team assignments to assess if the access is legitimate.
+- Use Osquery to gather additional context on the user's machine. For example, run the following query to check for recent GitHub-related processes: `SELECT * FROM processes WHERE name LIKE '%git%' OR path LIKE '%github%';`
+- Examine any recent changes or commits made to the repository to identify if any unauthorized modifications have occurred.
+- Check for any recent changes in the repository's access permissions or settings that might explain the new interaction.
+- Review the organization's GitHub audit logs for any other anomalies or patterns that coincide with the user's access.
+- Consult with the repository owner or project manager to verify if the user was expected to access the repository and if any recent changes in team roles might explain the access.
+
+### False positive analysis
+
+- Users who are part of a rotating team or have roles that require infrequent but legitimate access to private repositories may trigger false positives. These users can be added to an exception list to prevent unnecessary alerts.
+- Automated systems or scripts that interact with private repositories on a schedule longer than 14 days might be flagged. Identifying these systems and excluding them from the rule can reduce false positives.
+- Temporary contractors or consultants who have legitimate access for specific projects may appear as new interactions. Their access patterns should be reviewed and, if deemed non-threatening, can be excluded from the detection rule.
+- Users returning from extended leave or vacation might trigger alerts upon their first interaction with a private repo. These cases can be managed by temporarily adjusting the rule parameters or adding exceptions for known absences.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by revoking access to the private repository to prevent further unauthorized actions.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying any data exfiltrated or malicious code injected.
+- Review the user's recent activity logs to identify any other suspicious actions or access to additional repositories.
+- Escalate the incident to the security operations team for a deeper analysis and to determine if the breach is part of a larger attack.
+- Notify the repository owner and relevant stakeholders about the incident and the steps being taken to address it.
+- Implement enhanced logging policies to capture detailed user activity on private repositories for future monitoring and investigations.
+- Integrate security tools with GitHub, such as anomaly detection systems, to automatically flag unusual user behavior.
+- Restore the system to its operational state by ensuring all unauthorized changes are reverted and verifying the integrity of the repository.
+- Conduct a post-incident review to identify gaps in security controls and update policies to prevent similar incidents.
+- Apply hardening measures such as enforcing multi-factor authentication, regular access reviews, and least privilege principles for repository access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_repo_created.toml b/rules_building_block/execution_github_repo_created.toml
index 40ab0a8d88b..f9a79861435 100644
--- a/rules_building_block/execution_github_repo_created.toml
+++ b/rules_building_block/execution_github_repo_created.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,49 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "repo.create"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Repo Created
+GitHub repositories are essential for code collaboration and version control, enabling developers to manage and share projects. However, adversaries may exploit this by creating repositories to host malicious code or scripts for serverless execution, aligning with MITRE ATT&CK tactics. The detection rule monitors GitHub audit logs for repository creation events, helping identify unauthorized or suspicious activities that could indicate potential threats.
+
+### Possible investigation steps
+
+- Review the GitHub audit log entry to confirm the event details, focusing on the `event.dataset` and `event.action` fields to ensure it matches "github.audit" and "repo.create".
+- Identify the user associated with the repository creation by examining the `actor` field in the audit log to determine if the action was performed by an authorized individual.
+- Check the `repository.name` and `repository.url` fields to gather information about the newly created repository, including its name and location.
+- Investigate the `repository.visibility` field to determine if the repository is public or private, as public repositories may pose a higher risk if they contain sensitive information.
+- Cross-reference the `actor` field with known user accounts and roles within the organization to assess if the user has the appropriate permissions to create repositories.
+- Use Osquery to gather additional context about the user's recent activities. For example, run the following query to list recent GitHub actions by the user: `SELECT * FROM github_events WHERE actor_login = '<actor_login>' ORDER BY created_at DESC LIMIT 10;`.
+- Examine the commit history of the new repository, if available, to identify any suspicious or unauthorized code changes that may indicate malicious intent.
+- Review any associated pull requests or issues linked to the repository to detect any unusual or unexpected activity that could suggest a security concern.
+- Analyze the repository's description and README files for any indications of malicious intent or unauthorized project objectives.
+- Collaborate with the repository owner or the user who created the repository to verify the legitimacy of the creation and gather additional context if necessary.
+
+### False positive analysis
+
+- Frequent repository creation by trusted developers or automated systems can trigger false positives. These activities are often part of regular development workflows and not indicative of malicious intent.
+- Internal projects or sandbox environments where repositories are created and deleted frequently for testing purposes may also lead to false positives.
+- To manage these, users can create exceptions for specific users or teams known to regularly create repositories as part of their job functions.
+- Implementing a whitelist of known safe IP addresses or user accounts can help reduce noise from expected repository creation events.
+- Regularly review and update the list of exceptions to ensure it reflects current organizational practices and personnel changes.
+- Consider integrating additional context, such as repository names or descriptions, to better assess the intent behind repository creation events.
+
+### Response and remediation
+
+- Immediately review the newly created GitHub repository to determine if it contains any malicious or unauthorized content.
+- Revoke access to the repository for any suspicious users or accounts to prevent further unauthorized actions.
+- Conduct a thorough investigation of the audit logs to identify any other suspicious activities or related events.
+- Notify the security team and relevant stakeholders about the potential threat and findings for further analysis and decision-making.
+- If malicious content is confirmed, remove the repository and any associated files from the GitHub platform.
+- Implement stricter access controls and permissions for repository creation to limit the ability of unauthorized users to create repositories.
+- Enhance logging policies to ensure comprehensive monitoring of all repository-related activities, including creation, modification, and deletion events.
+- Integrate GitHub with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
+- Conduct a post-incident review to identify gaps in the current security posture and update policies and procedures accordingly.
+- Educate developers and users on secure coding practices and the importance of reporting suspicious activities to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
index 46e625fe8c3..426f7f15e5e 100644
--- a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
+++ b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,51 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and github.repo:* and 
 github.repository_public:false
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of GitHub Repo Interaction From a New IP
+
+GitHub repositories are crucial for code collaboration and storage, often containing sensitive information. Adversaries may exploit unauthorized access to private repositories by interacting from unfamiliar IPs, potentially leading to data breaches or code tampering. This detection rule identifies such anomalies by flagging interactions from IPs not seen in recent activity, helping to mitigate unauthorized access risks.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific IP address involved in the interaction and the exact timestamp of the event.
+- Cross-reference the IP address with known IP addresses in your organization's network to determine if it is an internal or external IP.
+- Check the GitHub audit logs for any other activities associated with the same IP address to identify patterns or additional unauthorized access attempts.
+- Investigate the GitHub actor associated with the event to verify if the user account has a history of accessing the repository from different IPs or if this is an anomaly.
+- Examine the specific repository accessed to assess the sensitivity of the data and determine the potential impact of unauthorized access.
+- Utilize Osquery to gather additional context on the system that may have been used for the interaction. For example, run the following Osquery query to check for recent network connections from the suspicious IP:
+  ```sql
+  SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious_ip>';
+  ```
+- Analyze any recent changes or commits made to the repository around the time of the alert to identify any unauthorized modifications.
+- Check for any recent changes in user permissions or access levels within the GitHub organization that could explain the new IP access.
+- Investigate any other security alerts or incidents that occurred around the same time to determine if this event is part of a larger attack pattern.
+- Consult threat intelligence sources to see if the IP address has been associated with known malicious activity or threat actors.
+
+### False positive analysis
+
+- Employees working remotely or traveling may trigger false positives when accessing GitHub repositories from new IP addresses. To manage this, maintain a list of known employee IPs or use a VPN to standardize IP addresses.
+- Automated systems or CI/CD pipelines that interact with GitHub repositories from dynamic IP addresses can also cause false positives. Consider whitelisting IP ranges associated with these systems or using static IPs for such interactions.
+- Third-party services or contractors with legitimate access to repositories might access from unfamiliar IPs. Establish a process to verify and document these IPs, and create exceptions for trusted partners.
+- Changes in corporate network infrastructure, such as new VPN endpoints or proxy servers, can result in new IP addresses being flagged. Regularly update the list of internal IPs to reflect these changes and prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected repository by restricting access to known, trusted IP addresses to prevent further unauthorized interactions.
+- Conduct a thorough investigation to identify the source and intent of the interaction, focusing on the new IP address and any associated user accounts.
+- Review recent changes in the repository for any unauthorized modifications or suspicious activity, and revert any unauthorized changes if necessary.
+- Notify the security team and relevant stakeholders about the incident, providing details of the IP address and any potential impact on the repository.
+- Implement enhanced logging and monitoring for GitHub interactions, ensuring that all access attempts, especially from new IPs, are logged and reviewed regularly.
+- Integrate threat intelligence feeds to correlate the new IP address with known malicious actors or activities, leveraging MITRE ATT&CK framework for context.
+- Update access controls and authentication mechanisms, such as enabling multi-factor authentication (MFA) for all users accessing private repositories.
+- Conduct a security awareness session for developers and repository maintainers to reinforce best practices for securing code repositories.
+- Restore the repository to its last known good state if any unauthorized changes were detected, ensuring that all code and data integrity is maintained.
+- Review and update incident response and recovery plans to incorporate lessons learned from the incident, enhancing future readiness and resilience."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_linux_segfault.toml b/rules_building_block/execution_linux_segfault.toml
index e1d006ca679..cef4de382b0 100644
--- a/rules_building_block/execution_linux_segfault.toml
+++ b/rules_building_block/execution_linux_segfault.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/26"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,48 @@ type = "query"
 query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:segfault
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Segfault Detected
+Segmentation faults occur when a program accesses restricted memory, often causing it to crash. While typically a sign of programming errors, adversaries can exploit these faults to execute unauthorized code, leveraging vulnerabilities like buffer overflows. The 'Segfault Detected' rule monitors Linux kernel logs for segfault messages, identifying potential exploitation attempts by correlating specific log patterns.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a segmentation fault by examining the `message` field for specific segfault patterns.
+- Verify the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is designed for Linux kernel logs.
+- Check the `event.dataset` field to confirm that the log source is `system.syslog`, ensuring the data is from the expected log source.
+- Identify the process that caused the segfault by examining the `process.name` field and gather additional context about this process.
+- Use Osquery to list recent processes that have experienced segmentation faults with a query like: `SELECT pid, name, path, cmdline FROM processes WHERE name = 'kernel' AND cmdline LIKE '%segfault%';`
+- Investigate the history of the process by reviewing logs or using Osquery to determine if this process has a history of segfaults or other anomalies.
+- Correlate the timing of the segfault with other system events to identify any preceding suspicious activities or changes in the system.
+- Examine the system for any recent updates or changes that might have introduced vulnerabilities, focusing on software related to the segfaulting process.
+- Analyze the system for signs of exploitation attempts, such as buffer overflow patterns, by reviewing logs and using tools like Osquery to check for unusual memory usage.
+- Gather additional context by checking for any related alerts or anomalies on the same host or network segment that might indicate a broader attack pattern.
+
+### False positive analysis
+
+- Routine software crashes: Some applications may crash frequently due to bugs or compatibility issues, leading to repeated segfault messages in the logs. These are not necessarily indicative of malicious activity but rather poor software stability.
+- Debugging activities: Developers often intentionally cause segfaults during debugging to test error handling or to identify vulnerabilities. These activities can generate false positives in the monitoring system.
+- Kernel module testing: Testing or development of kernel modules can result in segfaults as part of normal operations, especially when modules are being loaded or unloaded frequently.
+- Legacy software: Older software that is not fully compatible with current systems may cause segfaults due to outdated code practices, which are not necessarily security threats.
+- To manage these false positives, users can create exceptions or filters for known non-threatening processes or applications that frequently cause segfaults. This can be done by updating the monitoring rule to exclude specific process names or paths associated with benign activities. Additionally, maintaining an updated list of trusted applications and regularly reviewing and adjusting the exceptions can help minimize unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough investigation of the kernel logs and any associated application logs to identify the source and nature of the segfault.
+- Analyze recent changes or updates to the system that might have introduced vulnerabilities, focusing on software known for buffer overflow issues.
+- Utilize memory analysis tools to detect any unauthorized code execution or memory manipulation attempts.
+- If malicious activity is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Restore the system from a known good backup to ensure that any malicious code or corrupted data is removed.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
+- Implement enhanced logging policies to capture detailed information on process execution and memory access patterns for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update the incident response plan to address these weaknesses."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_settingcontent_ms_file_creation.toml b/rules_building_block/execution_settingcontent_ms_file_creation.toml
index e359ebfef9c..0b94cd745e1 100644
--- a/rules_building_block/execution_settingcontent_ms_file_creation.toml
+++ b/rules_building_block/execution_settingcontent_ms_file_creation.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,48 @@ file where host.os.type == "windows" and event.type == "creation" and
     "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\amd64_microsoft-windows-s..*\\*.settingcontent-ms"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation of SettingContent-ms Files
+
+SettingContent-ms files are XML-based shortcuts used in Windows to link to specific settings pages. While legitimate in function, adversaries exploit them to execute malicious code by embedding harmful scripts. The detection rule identifies unusual creation of these files outside typical directories, flagging potential misuse by checking file creation events and paths, thus helping analysts spot and mitigate threats effectively.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file creation event, focusing on the `file.path` and `file.extension` fields to ensure it matches the suspicious criteria outlined in the detection rule.
+- Check the `host.os.type` to verify that the event occurred on a Windows system, as this rule is specific to Windows environments.
+- Investigate the `file.path` to determine if the SettingContent-ms file was created in an unusual or unauthorized directory, which could indicate malicious activity.
+- Use Osquery to list all SettingContent-ms files on the system with the following query: `SELECT path FROM file WHERE path LIKE '%.settingcontent-ms';` to identify any other potentially suspicious files.
+- Examine the file creation timestamp to correlate with other system events or user activities that occurred around the same time, which might provide additional context.
+- Analyze the user account associated with the file creation event to determine if it aligns with expected behavior or if it might be compromised.
+- Investigate any associated processes or command-line activities that occurred around the time of the file creation to identify potential malicious scripts or commands.
+- Check for any recent changes in system settings or installed applications that might explain the creation of the SettingContent-ms file.
+- Review system logs for any other unusual activities or alerts that coincide with the file creation event, which could indicate a broader attack.
+- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize SettingContent-ms files for execution, which could provide additional context for the investigation.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create SettingContent-ms files in non-standard directories, triggering false positives. Users should verify the source of the file creation and consider excluding these paths if they are consistently associated with trusted software.
+- System administrators or IT management tools might generate these files during configuration changes or system maintenance tasks. Users can create exceptions for these activities by identifying the responsible processes and excluding them from the detection rule.
+- Custom scripts or automation tools used within an organization might inadvertently create SettingContent-ms files as part of their operations. Users should review these scripts and, if deemed safe, add them to an allowlist to prevent unnecessary alerts.
+- In environments with multiple users, shared systems might see SettingContent-ms files created in unusual locations due to user-specific settings adjustments. Users can monitor these patterns and exclude paths that are consistently associated with benign user activity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Conduct a thorough investigation to identify the source and scope of the SettingContent-ms file creation, examining recent file creation events and user activity.
+- Remove any malicious SettingContent-ms files identified during the investigation to prevent further execution of harmful scripts.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if multiple systems are affected.
+- Implement enhanced logging policies to capture detailed file creation events and user actions, ensuring comprehensive monitoring of SettingContent-ms file activities.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the system to its operational state by applying clean backups and verifying the integrity of system files and settings.
+- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
+- Educate users on the risks associated with executing unknown files and scripts, emphasizing the importance of reporting suspicious activities.
+- Review and update security policies and configurations to harden the system against future attacks, focusing on restricting the creation and execution of SettingContent-ms files outside of legitimate directories."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_unsigned_service_executable.toml b/rules_building_block/execution_unsigned_service_executable.toml
index e6c2b4816cc..7bca37b54c7 100644
--- a/rules_building_block/execution_unsigned_service_executable.toml
+++ b/rules_building_block/execution_unsigned_service_executable.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,49 @@ process.parent.executable:"C:\\Windows\\System32\\services.exe" and
 (process.code_signature.exists:false or process.code_signature.trusted:false) and
 not process.code_signature.status : (errorCode_endpoint* or "errorChaining")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Execution of an Unsigned Service
+
+The Service Control Manager (SCM) in Windows manages the execution of system services. Adversaries exploit SCM to run unsigned executables, potentially deploying malware or gaining elevated privileges. The detection rule identifies such activities by monitoring processes initiated by SCM, specifically those lacking valid code signatures, thus flagging potential security threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand the context, including the timestamp, host information, and the specific unsigned executable that was initiated.
+- Verify the parent process by checking if `process.parent.executable` is indeed "C:\\\\Windows\\\\System32\\\\services.exe" to confirm the involvement of the Service Control Manager.
+- Examine the `process.code_signature.exists` and `process.code_signature.trusted` fields to determine if the executable lacks a signature or if the signature is untrusted.
+- Investigate the process's command line arguments and execution path to identify any anomalies or suspicious patterns.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all running services and their associated executables: `SELECT name, path, state FROM services WHERE path LIKE 'C:\\\\Windows\\\\System32\\\\%' AND NOT signed;`
+- Check the system's event logs for any related entries around the time of the alert to identify any preceding or subsequent suspicious activities.
+- Investigate the network connections of the host during the time of the alert to identify any unusual outbound or inbound traffic.
+- Review the user account context under which the unsigned service was executed to assess if it aligns with expected behavior or if it indicates potential privilege escalation.
+- Correlate the alert with other security events or alerts from the same host to identify patterns or a broader attack campaign.
+- Consult threat intelligence sources to determine if the unsigned executable or its hash is associated with known malware or threat actors.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger this rule if the executable lacks a valid code signature. Users should verify the source and purpose of the executable before excluding it.
+- Custom or in-house applications often lack code signatures. Organizations should maintain a list of trusted internal applications and exclude them from the rule.
+- Some open-source or freeware applications may not be signed. Users should assess the risk and consider excluding these applications if they are deemed safe and necessary for business operations.
+- In development environments, unsigned executables are common. Users can create exceptions for specific development machines or directories to reduce noise.
+- To manage false positives, users can create exceptions by adding specific hashes, paths, or process names to an allowlist, ensuring that only verified and trusted unsigned executables are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware.
+- Verify the unsigned service's legitimacy by cross-referencing with known software inventories and contacting the software vendor if necessary.
+- Terminate the suspicious process and any related processes to halt malicious activity.
+- Conduct a thorough investigation of the system to identify any additional indicators of compromise, such as unusual network connections or file modifications.
+- Review system logs and security alerts to determine the initial vector of compromise and assess the scope of the incident.
+- Restore the system from a known good backup if the integrity of the system is compromised and ensure all patches and updates are applied.
+- Implement enhanced logging policies to capture detailed process execution and service creation events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for alerts.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if sensitive data is at risk.
+- Apply system hardening measures, such as enforcing strict code signing policies, disabling unnecessary services, and implementing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_wmi_wbemtest.toml b/rules_building_block/execution_wmi_wbemtest.toml
index 7e05911003e..e305b0d35df 100644
--- a/rules_building_block/execution_wmi_wbemtest.toml
+++ b/rules_building_block/execution_wmi_wbemtest.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,49 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.name : "wbemtest.exe"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WMI WBEMTEST Utility Execution
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. The WBEMTEST utility is a diagnostic tool that allows users to interact with WMI, often used for querying and managing system configurations. However, adversaries can exploit this tool to execute unauthorized commands or gather sensitive information from local or remote systems. The detection rule identifies suspicious activity by monitoring the initiation of the wbemtest.exe process, which may indicate potential misuse of WMI for malicious purposes.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "wbemtest.exe" and the event type is "start" to ensure the alert is valid.
+- Check the timestamp of the wbemtest.exe process initiation to determine when the activity occurred.
+- Identify the user account associated with the wbemtest.exe process to assess if the activity aligns with expected user behavior.
+- Investigate the parent process of wbemtest.exe to understand how it was launched and if it was initiated by a legitimate application or script.
+- Examine the command line arguments used with wbemtest.exe to identify any specific WMI queries or operations that were executed.
+- Use Osquery to gather additional context about the system state at the time of execution. Example query: `SELECT * FROM processes WHERE name = 'wbemtest.exe';`
+- Correlate the wbemtest.exe execution with other security events or logs from the same timeframe to identify any related suspicious activities.
+- Check for any network connections initiated by wbemtest.exe to determine if it was used to interact with remote systems.
+- Review historical data to see if wbemtest.exe has been executed previously on the system and if there is a pattern or increase in frequency.
+- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that commonly use wbemtest.exe for malicious purposes.
+
+### False positive analysis
+
+- The WMI WBEMTEST utility is often used by system administrators and IT professionals for legitimate purposes such as troubleshooting, system monitoring, and configuration management, which can lead to false positives when monitoring for suspicious activity.
+- Automated scripts or management tools that rely on WMI for regular system checks or inventory tasks may trigger the detection rule, as they might initiate the wbemtest.exe process as part of their operations.
+- To manage these false positives, users can create exceptions for known and trusted sources, such as specific user accounts or systems that regularly perform legitimate WMI operations.
+- Implementing a baseline of normal WMI activity within the organization can help distinguish between routine use and potential misuse, allowing for more accurate detection and fewer false positives.
+- Regularly reviewing and updating the list of exceptions based on changes in IT operations or personnel can help maintain the effectiveness of the detection rule while minimizing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the activity, including identifying any additional compromised systems or accounts.
+- Review system and security logs to trace the origin of the wbemtest.exe execution and identify any associated suspicious activities or anomalies.
+- Terminate any unauthorized processes or sessions initiated by wbemtest.exe to halt potential malicious operations.
+- Change credentials for any accounts that may have been compromised during the incident to prevent further unauthorized access.
+- Restore the system from a known good backup to ensure that any malicious changes are reverted and the system is returned to a secure state.
+- Implement enhanced logging and monitoring for WMI activities, including the execution of wbemtest.exe, to detect future misuse attempts.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze WMI-related alerts more effectively.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional response actions are necessary.
+- Apply security hardening measures, such as restricting WMI access to authorized users and systems only, to reduce the attack surface and prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_member_removed_from_organization.toml b/rules_building_block/impact_github_member_removed_from_organization.toml
index 7153494eaa4..85e3ea7d152 100644
--- a/rules_building_block/impact_github_member_removed_from_organization.toml
+++ b/rules_building_block/impact_github_member_removed_from_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,49 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.remove_member"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Member Removed From GitHub Organization
+
+GitHub Organizations manage collaborative projects, controlling member access to repositories. Adversaries might exploit this by removing members to disrupt operations or conceal unauthorized changes. The detection rule monitors audit logs for member removal actions, identifying potential misuse by correlating these events with known threat tactics, ensuring timely alerts for security teams.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event details, focusing on the `event.dataset` and `event.action` fields to ensure the alert corresponds to a member removal action.
+- Identify the user who performed the removal by examining the `actor` field in the audit logs to determine if the action was authorized or suspicious.
+- Check the `target` field to identify the member who was removed and assess their role and access level within the organization.
+- Investigate the timing of the removal by analyzing the `timestamp` field to see if it coincides with any other suspicious activities or known threat patterns.
+- Correlate the removal event with other recent audit log entries to identify any unusual patterns or sequences of actions that might indicate malicious intent.
+- Use Osquery to gather additional context on the system from which the removal action was performed. Example query: `SELECT * FROM processes WHERE name = 'git' AND user = '<actor_username>';`
+- Examine any recent changes to critical repositories or settings that the removed member had access to, ensuring no unauthorized modifications were made.
+- Cross-reference the removal event with any recent security alerts or incidents to determine if it is part of a broader attack or compromise.
+- Verify if there were any recent changes to the organization's membership policies or permissions that could explain the removal action.
+- Consult with the organization's team members or administrators to validate the legitimacy of the removal and gather any additional context or insights.
+
+### False positive analysis
+
+- Routine administrative actions: Regular maintenance or restructuring of a GitHub Organization may involve removing members who no longer need access. These actions are typically non-threatening and can be identified by correlating with scheduled administrative tasks.
+- Employee offboarding: When employees leave a company, their access to the GitHub Organization is often removed as part of the offboarding process. This is a standard security practice and can be excluded by verifying against HR records.
+- Temporary project access: Members might be removed after completing their work on a temporary project. These removals can be considered non-threatening if they align with project timelines and deliverables.
+- Automated account management: Some organizations use automated tools to manage GitHub access, which might include removing inactive or unnecessary accounts. These actions can be excluded by identifying and trusting the automation tools in use.
+- To manage false positives, users can create exceptions for known non-threatening behaviors by maintaining a whitelist of expected member removal actions, such as those associated with specific administrative or HR processes.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the member removal by contacting the organization owner or admin to confirm if the action was authorized.
+- Review the audit logs for any suspicious activities or patterns around the time of the member removal to identify potential unauthorized access or changes.
+- If unauthorized removal is confirmed, temporarily restrict access to critical repositories and resources to prevent further unauthorized actions.
+- Restore the removed member's access if the removal was unauthorized and ensure they are informed of the incident.
+- Escalate the incident to the security team for a thorough investigation and to determine if any sensitive data or systems were compromised.
+- Implement additional logging and monitoring to capture detailed events related to member access and changes within the organization.
+- Integrate alerts with a Security Information and Event Management (SIEM) system to enhance real-time monitoring and correlation with other security events.
+- Conduct a review of current access policies and permissions to ensure they follow the principle of least privilege and adjust as necessary.
+- Educate organization members on security best practices and the importance of reporting suspicious activities promptly.
+- Consider implementing multi-factor authentication (MFA) and regular access reviews to strengthen account security and prevent unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_pat_access_revoked.toml b/rules_building_block/impact_github_pat_access_revoked.toml
index 4dd48492420..3c9b3aa8969 100644
--- a/rules_building_block/impact_github_pat_access_revoked.toml
+++ b/rules_building_block/impact_github_pat_access_revoked.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,49 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "personal_access_token.access_revoked"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PAT Access Revoked
+
+GitHub Personal Access Tokens (PATs) are used to authenticate API requests without a password, granting access to private resources. Adversaries may exploit compromised PATs to access sensitive data or disrupt operations. The detection rule monitors audit logs for revoked PAT access, signaling potential unauthorized use or security policy enforcement, aligning with MITRE ATT&CK's account access removal technique.
+
+### Possible investigation steps
+
+- Review the audit logs to identify the specific user associated with the revoked PAT by examining the `user.name` and `user.id` fields.
+- Check the `event.time` field to determine when the PAT access was revoked and correlate this with any other suspicious activities around the same time.
+- Investigate the `source.ip` field to identify the IP address from which the PAT was used before revocation, and assess if it is a known or trusted source.
+- Examine the `repository.name` and `organization.name` fields to understand which repositories and organizations were potentially accessed using the revoked PAT.
+- Use Osquery to gather additional context on the system from which the PAT was used. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<source.ip>';`
+- Analyze the `event.outcome` field to confirm whether the revocation was successful and if there were any failed attempts to use the PAT after revocation.
+- Cross-reference the `user.email` field with internal HR or user management systems to verify the user's current status and any recent changes in their role or access levels.
+- Investigate any recent changes to the user's account settings or permissions in GitHub that might indicate unauthorized access or privilege escalation.
+- Review any recent commits or changes made by the user in the repositories accessed by the PAT to identify any unauthorized or suspicious modifications.
+- Check for any other alerts or incidents related to the same user or IP address in your security information and event management (SIEM) system to identify potential patterns or broader threats.
+
+### False positive analysis
+
+- Routine administrative actions: Revocation of PATs as part of regular security audits or policy updates can trigger false positives. Users can manage this by creating exceptions for known administrative activities.
+- User-initiated revocations: Developers or team members may revoke their own PATs when rotating credentials or leaving a project. To handle these, users can exclude events associated with specific user actions that are documented and expected.
+- Automated security tools: Some security tools automatically revoke PATs if they detect potential security issues. Users should identify and exclude these tools' actions from the detection rule to prevent false alerts.
+- Organizational policy changes: Changes in organizational security policies that require revocation of all existing PATs can lead to multiple false positives. Users can temporarily adjust the detection rule to account for these policy-driven actions.
+- Test environments: PATs used in test or development environments may be revoked frequently as part of testing processes. Users can exclude these environments from the detection rule to reduce noise.
+
+### Response and remediation
+
+- Immediately revoke any remaining access for the compromised PAT to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying any accessed or modified resources.
+- Notify affected stakeholders and teams about the incident and potential data exposure.
+- Review audit logs and other security logs to trace the adversary's actions and identify any additional compromised accounts or tokens.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging and monitoring for GitHub activities to detect similar incidents in the future.
+- Integrate security tools with GitHub to automate the detection and revocation of compromised tokens.
+- Educate users on secure token management practices, including regular rotation and minimal permissions.
+- Restore any affected systems or data to their last known good state, ensuring integrity and availability.
+- Apply hardening measures such as enforcing multi-factor authentication (MFA) for all GitHub accounts and regularly reviewing access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_user_blocked_from_organization.toml b/rules_building_block/impact_github_user_blocked_from_organization.toml
index 60fb77cb60d..e368bb2645f 100644
--- a/rules_building_block/impact_github_user_blocked_from_organization.toml
+++ b/rules_building_block/impact_github_user_blocked_from_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,50 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.block_user"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 User Blocked From Organization
+
+GitHub is a platform for version control and collaboration, crucial for software development. Organizations use it to manage access to repositories. Adversaries might exploit account access to exfiltrate data or disrupt operations. The detection rule monitors audit logs for user blocks, signaling potential unauthorized access removal, aligning with MITRE ATT&CK's account access removal technique.
+
+### Possible investigation steps
+
+- Review the audit log entry to confirm the event dataset is "github.audit" and the action is "org.block_user" to ensure the alert is valid.
+- Identify the user who was blocked by examining the relevant fields in the audit log, such as "actor" and "target" fields, to understand who initiated the block and who was blocked.
+- Check the timestamp of the event to determine when the block occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the user's recent activity within the organization by reviewing their commit history, pull requests, and any other interactions with repositories to identify any unusual behavior.
+- Examine the organization's access control policies and recent changes to understand if the block aligns with any policy updates or if it was an unexpected action.
+- Cross-reference the blocked user's access permissions with other users in the organization to determine if there were any anomalies or deviations in their access level.
+- Utilize Osquery to gather additional context on the user's activity. For example, run a query to list recent login attempts or access patterns: `SELECT * FROM github_user_events WHERE user = 'blocked_user' AND action = 'login';`
+- Check for any recent security alerts or incidents reported within the organization that might have prompted the user block.
+- Review communication logs or messages within the organization to see if there was any discussion or decision-making process regarding the block.
+- Investigate any third-party integrations or applications the blocked user had access to, ensuring no unauthorized data access or exfiltration occurred through those channels.
+
+### False positive analysis
+
+- Routine administrative actions: Sometimes, users are blocked as part of regular administrative tasks, such as removing access for former employees or contractors. These actions are not malicious but can trigger the detection rule.
+- Temporary access restrictions: Users might be blocked temporarily due to policy changes or during security audits, which are non-threatening but can appear as suspicious activity.
+- Automated security tools: Some organizations use automated tools to block users based on predefined criteria, which might not always indicate a security threat.
+- To manage these false positives, organizations can create exceptions for known administrative actions by maintaining a list of expected user blocks and excluding them from alerts.
+- Implementing a review process for user blocks can help differentiate between legitimate administrative actions and potential security threats, reducing unnecessary alerts.
+- Regularly updating the list of users with temporary access can help in excluding these cases from triggering false positives.
+
+### Response and remediation
+
+- Verify the legitimacy of the block by reviewing the audit logs and confirming the action with the organization’s admin team.
+- Contain the potential threat by ensuring the blocked user no longer has access to any other organization resources or repositories.
+- Investigate the blocked user's recent activities to identify any unauthorized access or data exfiltration attempts.
+- Remediate any unauthorized changes or data breaches by restoring affected repositories from backups and revoking any compromised credentials.
+- Escalate the incident to the organization's security team if malicious intent is suspected, providing them with detailed logs and findings.
+- Enhance logging policies to ensure comprehensive audit trails for all user actions within the organization.
+- Implement additional security integrations, such as multi-factor authentication and anomaly detection tools, to prevent future unauthorized access.
+- Conduct a security review of the organization's GitHub settings and permissions to ensure they align with best practices.
+- Restore the system to its operational state by verifying that all legitimate users have appropriate access and that no unauthorized changes remain.
+- Harden the organization's security posture by regularly updating access controls and conducting security awareness training for all users."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_cross_site_scripting.toml b/rules_building_block/initial_access_cross_site_scripting.toml
index 0ed9fe480fb..b14228c0a02 100644
--- a/rules_building_block/initial_access_cross_site_scripting.toml
+++ b/rules_building_block/initial_access_cross_site_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,52 @@ any where processor.name == "transaction" and
 url.fragment : ("<iframe*", "*prompt(*)*", "<script*>", "<svg*>", "*onerror=*", "*javascript*alert*", "*eval*(*)*", "*onclick=*",
 "*alert(document.cookie)*", "*alert(document.domain)*","*onresize=*","*onload=*","*onmouseover=*")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Cross Site Scripting (XSS)
+
+Cross-Site Scripting (XSS) exploits vulnerabilities in web applications by injecting malicious scripts into trusted sites, often targeting users' browsers. Adversaries leverage this to execute harmful scripts, potentially stealing data or hijacking sessions. The detection rule identifies suspicious script patterns in web transactions, such as script tags or event handlers, signaling potential XSS attempts.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific pattern from the query triggered the alert, such as "<script*>", "*onerror=*", or "*alert(document.cookie)*".
+- Examine the URL and URL fragment fields in the alert to identify the source and context of the suspicious script injection.
+- Check the HTTP request and response headers for any anomalies or indications of script injection attempts.
+- Analyze the user agent string to determine if the request originated from a legitimate browser or a potentially malicious source.
+- Investigate the referrer field to trace back the navigation path that led to the suspicious request, which might reveal the attack vector.
+- Use Osquery to gather additional context on the affected system. For example, run the following query to list all running browser processes and their command-line arguments:
+  ```sql
+  SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%chrome%' OR name LIKE '%firefox%' OR name LIKE '%edge%';
+  ```
+- Correlate the alert with other logs, such as web server logs or application logs, to identify any patterns or repeated attempts of similar XSS payloads.
+- Check for any recent changes or deployments in the web application that might have introduced new vulnerabilities or bypassed existing security controls.
+- Investigate the affected user's session details to determine if any unauthorized actions were performed or if sensitive data was accessed.
+- Review historical alerts and incidents to see if this is part of a larger pattern or campaign targeting the organization.
+
+### False positive analysis
+
+- Certain legitimate web applications may use script tags or event handlers for benign purposes, such as loading external resources or enhancing user interaction, which can trigger false positives in the detection rule.
+- Web development tools and frameworks often include inline scripts or event handlers for debugging or functionality testing, which might be mistakenly flagged as XSS attempts.
+- User-generated content platforms, like forums or comment sections, may allow HTML or script-like syntax for formatting or embedding media, leading to false positives if not properly sanitized.
+- To manage these false positives, users can create exceptions for known safe scripts or domains by updating the detection rule to exclude specific patterns or URLs that are verified as non-threatening.
+- Regularly reviewing and updating the list of exceptions based on the evolving web application landscape and user behavior can help minimize unnecessary alerts while maintaining security.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further exploitation and data exfiltration.
+- Conduct a thorough investigation to identify the source and scope of the XSS attack, focusing on logs and user activity around the time of the alert.
+- Remove any injected scripts or malicious code from the affected web applications and databases.
+- Reset credentials and session tokens for users who may have been affected to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement or enhance web application firewalls (WAF) to detect and block XSS attempts in real-time.
+- Review and update input validation and output encoding practices in web applications to prevent future XSS vulnerabilities.
+- Enable comprehensive logging of web application activities and integrate with a security information and event management (SIEM) system for continuous monitoring.
+- Conduct a security awareness training session for developers and users to recognize and prevent XSS attacks.
+- Apply security patches and updates to web applications and underlying systems to mitigate known vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
index 173fa693fb1..76e69b50b21 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,49 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and github.hashed_token:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of IP Address For GitHub Personal Access Token (PAT)
+
+GitHub Personal Access Tokens (PATs) facilitate secure API interactions, but adversaries can exploit them to gain unauthorized access. By monitoring for new IP addresses accessing PATs, this detection rule identifies potential misuse, as attackers often use unfamiliar IPs. It leverages GitHub audit logs to flag unusual activity, aligning with MITRE ATT&CK's focus on detecting valid account abuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `github.actor_ip` and `github.hashed_token` involved in the suspicious activity.
+- Cross-reference the `github.actor_ip` with known IP addresses in your organization's network to determine if it is a recognized or expected IP.
+- Check the `github.audit` logs for any other activities associated with the same `github.hashed_token` to identify any patterns or additional suspicious behavior.
+- Investigate the user account associated with the `github.hashed_token` to verify if the access was legitimate or if the account may have been compromised.
+- Use Osquery to gather more information about the system from which the suspicious IP address originated. Example query: `SELECT * FROM osquery_info WHERE uuid = '<system_uuid>';` to identify the system details.
+- Analyze the `github.programmatic_access_type` to understand the scope of access granted by the token and assess the potential impact of its misuse.
+- Look for any recent changes in the `event.category:"configuration"` logs that might indicate unauthorized modifications to the GitHub account settings.
+- Check for any other alerts or incidents involving the same IP address or token in the past 14 days to identify potential patterns of attack.
+- Review the geographical location and ISP information of the `github.actor_ip` to assess if it aligns with the expected locations for your organization.
+- Collaborate with the user associated with the token to confirm if they recognize the IP address and if they have recently accessed GitHub from a new location or device.
+
+### False positive analysis
+
+- Frequent travel or remote work by legitimate users can trigger false positives when accessing GitHub from new IP addresses. Users can manage this by maintaining a list of known IP ranges associated with trusted locations and excluding them from alerts.
+- Use of VPNs or dynamic IP addresses by authorized personnel may result in new IP detections. To handle this, organizations can implement a process to regularly update and whitelist IP addresses associated with these services.
+- Automated systems or CI/CD pipelines that rotate IP addresses might be flagged. Users should document and exclude these systems' IP ranges from the detection rule to prevent unnecessary alerts.
+- Changes in corporate network infrastructure, such as new proxies or gateways, can lead to new IP addresses being flagged. It's advisable to update the detection rule with these new IP addresses as they become part of the trusted network.
+- Legitimate third-party integrations or services that access GitHub using PATs from different IP addresses can be mistaken for threats. Users should verify and whitelist these services' IP addresses to avoid false positives.
+
+### Response and remediation
+
+- Immediately revoke the compromised GitHub Personal Access Token to prevent further unauthorized access.
+- Conduct a thorough investigation to determine the scope of the breach, including identifying any unauthorized changes or data exfiltration.
+- Cross-reference the new IP address with known threat intelligence sources to assess if it is associated with malicious activity.
+- Notify the affected user and relevant stakeholders about the potential compromise and provide guidance on securing their accounts.
+- Implement multi-factor authentication (MFA) for all GitHub accounts to enhance security and prevent unauthorized access.
+- Review and update access controls and permissions to ensure the principle of least privilege is enforced across all GitHub repositories.
+- Integrate GitHub audit logs with a Security Information and Event Management (SIEM) system for continuous monitoring and alerting on suspicious activities.
+- Develop and enforce a logging policy that ensures all access and modification events are captured and retained for a sufficient period.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users on recognizing phishing attempts and the importance of safeguarding their access tokens and credentials."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_user.toml b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
index b9e80d855c5..d1b33ed3c6c 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_user.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,49 @@ query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and user.name:*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of IP Address For GitHub User
+
+The detection rule monitors GitHub audit logs for new IP addresses associated with user accounts, flagging those not seen in the past 14 days. This helps identify potential unauthorized access attempts, as adversaries may exploit compromised credentials to gain initial access from unfamiliar IPs. By correlating IP changes with user activity, the rule aids in detecting suspicious behavior indicative of account misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a new IP address associated with the GitHub user account, focusing on the `github.actor_ip` and `user.name` fields.
+- Verify the legitimacy of the IP address by checking its geolocation and ASN information to determine if it aligns with the user's usual activity patterns.
+- Cross-reference the new IP address with known malicious IP databases to identify any potential threats.
+- Examine the user's recent activity logs in the GitHub audit dataset to identify any unusual or unauthorized actions, such as repository access or changes in configuration.
+- Check for any recent changes in the user's account settings, such as password changes or the addition of new SSH keys, which could indicate account compromise.
+- Investigate any other users who have logged in from the same IP address to determine if there is a broader issue affecting multiple accounts.
+- Use Osquery to gather additional context on the user's machine, such as running processes or network connections, with a query like: `SELECT * FROM processes WHERE user = '<username>';`
+- Review any recent email notifications sent to the user regarding suspicious activity or login attempts from unfamiliar locations.
+- Collaborate with the user to verify if they recognize the IP address or if they have recently traveled or used a VPN service that could explain the new IP.
+- Document all findings and observations in the investigation report to maintain a comprehensive record of the analysis process.
+
+### False positive analysis
+
+- Users frequently accessing GitHub from dynamic IP addresses, such as those assigned by ISPs, may trigger false positives. To manage this, consider creating exceptions for known user accounts with dynamic IPs by maintaining a list of trusted IP ranges.
+- Employees traveling or working remotely from different locations can result in new IP addresses being flagged. Implement a process to verify travel schedules or remote work arrangements and exclude these IPs from alerts.
+- Use of VPNs or proxy services by legitimate users can cause IP address changes. Establish a list of approved VPN or proxy IP addresses and configure the rule to ignore these.
+- Automated systems or scripts that access GitHub from various cloud environments might generate alerts. Identify and whitelist IP addresses associated with these systems to prevent unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure it reflects current organizational practices and does not inadvertently allow unauthorized access.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by temporarily disabling access to prevent further unauthorized actions.
+- Conduct a thorough investigation of the flagged IP address to determine its origin and assess whether it is associated with known malicious activity.
+- Review recent user activity logs to identify any unauthorized actions or changes made from the new IP address.
+- Reset the compromised user's credentials and enforce multi-factor authentication (MFA) to enhance account security.
+- Notify the affected user and relevant stakeholders about the potential security incident and provide guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if multiple accounts are affected.
+- Implement enhanced logging and monitoring policies to capture detailed user activity and IP address changes for future investigations.
+- Integrate threat intelligence feeds to correlate IP addresses with known threat actors and improve detection capabilities.
+- Restore the system to its operational state by verifying that no unauthorized changes persist and that all security measures are in place.
+- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as regular security training and periodic access reviews, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
index de9956f7246..a741e8e76d1 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,48 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.user_agent:* and github.hashed_token:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of User Agent For a GitHub Personal Access Token (PAT)
+
+GitHub Personal Access Tokens (PATs) facilitate programmatic access to repositories, enabling automation and integration. Adversaries may exploit PATs to gain unauthorized access, leveraging new user agents to mask their activities. This detection rule identifies anomalies by flagging unfamiliar user agents associated with PATs, indicating potential misuse or compromise, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user agent and GitHub Personal Access Token (PAT) involved in the anomaly.
+- Cross-reference the user agent with known legitimate user agents used within the organization to determine if it is expected or potentially malicious.
+- Examine the `event.dataset` and `event.category` fields to confirm the event is related to GitHub audit and configuration changes, ensuring the context of the alert is accurate.
+- Investigate the `github.user_agent` field to gather more information about the new user agent, including its origin and any associated IP addresses.
+- Check the `github.hashed_token` field to identify the specific PAT involved and determine its owner or associated user account.
+- Analyze the `github.programmatic_access_type` field to understand the type of access granted by the PAT, focusing on whether it is an OAuth access token or a fine-grained personal access token.
+- Use Osquery to gather additional context on the system or environment where the new user agent was first observed. Example query: `SELECT * FROM processes WHERE name = 'github' AND user_agent = '<new_user_agent>';`
+- Review recent activity logs for the associated user account to identify any unusual or unauthorized actions that may correlate with the new user agent usage.
+- Investigate any recent changes in repository access or permissions that might have been made using the PAT, focusing on any unauthorized modifications.
+- Collaborate with the user or team associated with the PAT to verify if the new user agent usage was intentional and authorized, or if it indicates a potential compromise.
+
+### False positive analysis
+
+- Frequent updates or changes in legitimate automation tools or scripts may introduce new user agents, triggering false positives. Users should maintain an updated list of known and trusted user agents associated with their automation tools to minimize these alerts.
+- Developers or teams using multiple environments or devices for testing and development might inadvertently cause new user agents to appear. It's advisable to document and whitelist user agents from these environments if they are verified as non-threatening.
+- Integration of third-party services or plugins that access GitHub repositories using PATs can result in new user agents. Users should verify the legitimacy of these services and consider adding them to an exception list if they are deemed safe.
+- Regularly rotating or regenerating PATs as part of security best practices can lead to new user agents being flagged. Users should ensure that any new user agents resulting from such practices are reviewed and, if necessary, added to a whitelist to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access.
+- Investigate the source of the new user agent by reviewing logs to determine if it aligns with known or expected activity.
+- Conduct a thorough review of recent repository changes and access logs to identify any unauthorized actions or data exfiltration.
+- Notify the affected user and relevant security teams about the potential compromise and provide guidance on securing their accounts.
+- Escalate the incident to the security operations center (SOC) if unauthorized access or data breach is confirmed.
+- Implement enhanced logging and monitoring for GitHub activities, focusing on user agent changes and PAT usage.
+- Integrate security information and event management (SIEM) tools to correlate GitHub events with other security data for comprehensive threat detection.
+- Educate users on the importance of using strong, unique PATs and regularly rotating them to minimize the risk of compromise.
+- Restore any affected repositories or systems to their last known good state, ensuring that all unauthorized changes are reverted.
+- Apply security hardening measures, such as enforcing multi-factor authentication (MFA) for all GitHub accounts and restricting PAT scopes to the minimum necessary permissions."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_user.toml b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
index 15d3b4dfcf7..2f338eb691b 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_user.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,49 @@ query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
 github.user_agent:* and user.name:*
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of User-Agent For a GitHub User
+User-Agent strings identify the software acting on behalf of a user, such as browsers or scripts, in GitHub environments. Adversaries may exploit this by using unfamiliar User-Agents to mask unauthorized access. The detection rule identifies new User-Agents associated with GitHub users, flagging potential unauthorized access attempts by comparing against a 14-day history.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific GitHub user and the new User-Agent string that triggered the alert.
+- Cross-reference the User-Agent string with known legitimate User-Agents to determine if it is commonly associated with authorized applications or browsers.
+- Check the GitHub audit logs for any other recent activities associated with the same user to identify any unusual patterns or anomalies.
+- Investigate the IP address associated with the new User-Agent to determine its geolocation and assess if it aligns with the user's typical access patterns.
+- Examine the event timestamps to see if the new User-Agent coincides with any known maintenance or deployment activities that could explain the change.
+- Utilize Osquery to gather additional context from the user's machine, such as running processes or network connections. Example query: `SELECT * FROM processes WHERE name LIKE '%github%' OR path LIKE '%github%';`
+- Review any recent changes in the user's access permissions or roles within the GitHub organization to assess if there have been unauthorized modifications.
+- Check for any recent password changes or multi-factor authentication (MFA) events for the user to determine if there have been attempts to secure the account.
+- Analyze any other security alerts or incidents involving the same user or User-Agent to identify potential correlations or patterns.
+- Consult with the user or relevant team members to verify if the new User-Agent is expected and authorized, documenting any findings for future reference.
+
+### False positive analysis
+
+- Frequent legitimate changes in User-Agent strings can occur due to updates in browsers or scripts used by GitHub users, leading to false positives. 
+- Automated tools or CI/CD systems that regularly update their User-Agent strings might trigger alerts despite being authorized and non-threatening.
+- Users accessing GitHub from different devices or networks may have varying User-Agent strings, which could be mistakenly flagged as suspicious.
+- To manage these false positives, users can create exceptions for known and trusted User-Agent strings that frequently change but are verified as non-malicious.
+- Implementing a whitelist of User-Agent strings associated with specific automated tools or scripts can help reduce unnecessary alerts.
+- Regularly reviewing and updating the list of exceptions based on user behavior and tool updates can help maintain the balance between security and usability.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling access to prevent further unauthorized actions.
+- Conduct a thorough investigation of the new User-Agent string to determine if it is associated with known malicious activity or legitimate changes.
+- Review recent activity logs for the affected user account to identify any suspicious actions or unauthorized access attempts.
+- Reset the credentials for the affected user account and enforce multi-factor authentication to enhance security.
+- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if multiple accounts are affected.
+- Implement enhanced logging policies to capture detailed User-Agent information and other relevant metadata for future analysis.
+- Integrate threat intelligence feeds to correlate User-Agent strings with known threat actors or attack patterns.
+- Restore the system to its operational state by ensuring all unauthorized changes are reverted and security controls are re-enabled.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Apply hardening measures such as regular audits of user access permissions and continuous monitoring of user activity to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_at.toml b/rules_building_block/lateral_movement_at.toml
index 7d63c514bbc..31745de4cfb 100644
--- a/rules_building_block/lateral_movement_at.toml
+++ b/rules_building_block/lateral_movement_at.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,49 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.name : "at.exe" and process.args : "\\\\*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 At.exe Command Lateral Movement
+
+The `at.exe` utility is a legacy Windows command-line tool used to schedule tasks on local or remote systems. Adversaries may exploit this tool to execute tasks on remote hosts, facilitating lateral movement within a network. The detection rule identifies suspicious use of `at.exe` by monitoring for its execution with network paths, which may indicate attempts to schedule tasks on remote systems, a common tactic in lateral movement.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `at.exe` execution with network paths in the `process.args` field, indicating potential remote task scheduling.
+- Verify the `host.os.type` field to ensure the event occurred on a Windows system, as `at.exe` is specific to Windows environments.
+- Examine the `event.type` field to confirm the process start event, ensuring that the alert is triggered by the execution of `at.exe`.
+- Investigate the source host by checking the hostname or IP address to determine if it is a known or trusted system within the network.
+- Analyze the destination network path in the `process.args` field to identify the target host and assess if it is a legitimate target for task scheduling.
+- Check the user account associated with the `at.exe` execution to determine if it is a privileged account and if the activity aligns with the user's typical behavior.
+- Use Osquery to gather additional context on the source host by running a query such as: `SELECT * FROM processes WHERE name = 'at.exe';` to identify any related processes or anomalies.
+- Review historical logs and previous alerts for similar `at.exe` executions to identify patterns or repeated attempts of lateral movement.
+- Correlate the `at.exe` activity with other network or host-based alerts to determine if it is part of a larger attack campaign or isolated incident.
+- Consult with system administrators or the user associated with the alert to verify if the `at.exe` execution was authorized or part of a legitimate task scheduling activity.
+
+### False positive analysis
+
+- Scheduled administrative tasks: Legitimate IT operations may use `at.exe` to schedule routine maintenance or updates on remote systems, which can trigger the detection rule. Users should identify and document these tasks to differentiate them from malicious activity.
+- Backup operations: Some backup solutions might use `at.exe` to initiate backup processes on remote machines. Users can create exceptions for known backup operations by specifying the associated network paths or process arguments.
+- Software deployment: Organizations deploying software across multiple systems might use `at.exe` for task scheduling. Users should maintain a list of authorized deployment activities and exclude these from alerts.
+- Testing and development: Developers or IT staff might use `at.exe` in test environments to simulate task scheduling. Users can exclude specific test environments or user accounts from triggering alerts.
+- To manage false positives, users can implement exceptions by creating allowlists for known benign network paths or specific user accounts frequently associated with non-threatening `at.exe` usage. This helps in reducing noise and focusing on genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Verify the legitimacy of the scheduled tasks created by at.exe by reviewing the task details and the user account that initiated them.
+- Terminate any unauthorized or suspicious tasks that were scheduled using at.exe to halt potential malicious activities.
+- Conduct a thorough investigation to identify any other systems that may have been targeted or compromised using similar tactics.
+- Review and analyze logs from the affected system and any connected systems to trace the adversary's actions and identify their entry point.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on remote task scheduling attempts.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
+- Restore the affected system to its operational state by removing any malicious artifacts and applying necessary security patches and updates.
+- Harden the environment by disabling legacy tools like at.exe if not needed, and enforce strict access controls and network segmentation to limit lateral movement opportunities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_posh_winrm_activity.toml b/rules_building_block/lateral_movement_posh_winrm_activity.toml
index 1ab4424ae66..238782d47b1 100644
--- a/rules_building_block/lateral_movement_posh_winrm_activity.toml
+++ b/rules_building_block/lateral_movement_posh_winrm_activity.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,48 @@ event.category:process and host.os.type:windows and
     "function Invoke-Command {"
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 PowerShell Script with Remote Execution Capabilities via WinRM
+
+Windows Remote Management (WinRM) facilitates remote command execution and management, leveraging PowerShell for automation. Adversaries exploit this by using cmdlets like `Invoke-Command` to move laterally across networks. The detection rule identifies suspicious PowerShell scripts executing remotely via WinRM, excluding benign processes, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific PowerShell cmdlet triggered the alert, focusing on `Invoke-WmiMethod`, `Invoke-Command`, or `Enter-PSSession` with the `ComputerName` parameter.
+- Check the `event.category:process` and `host.os.type:windows` fields to confirm the event is related to a Windows process execution.
+- Investigate the user context by examining the `user.id` field to determine if the activity was performed by a non-system account, as the rule excludes the system account `S-1-5-18`.
+- Analyze the `powershell.file.script_block_text` to understand the script's intent and identify any potentially malicious commands or patterns.
+- Verify the file path in `file.directory` to ensure the script did not originate from a known benign directory like `C:\\\\Program Files\\\\LogicMonitor\\\\Agent\\\\tmp`.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND path NOT LIKE 'C:\\\\Program Files\\\\LogicMonitor\\\\Agent\\\\tmp\\\\%' AND user_id != 'S-1-5-18';`
+- Cross-reference the alert with recent login events to identify any unusual or unauthorized access patterns that might correlate with the PowerShell activity.
+- Examine network logs for connections to the `ComputerName` specified in the PowerShell command to identify any unexpected or unauthorized remote connections.
+- Review historical data for the involved user account and host to identify any previous suspicious activities or patterns that might indicate a broader compromise.
+- Consult threat intelligence sources to determine if the observed PowerShell script or its components are associated with known malicious campaigns or threat actors.
+
+### False positive analysis
+
+- Legitimate administrative tasks: System administrators often use PowerShell cmdlets like `Invoke-Command` and `Enter-PSSession` for routine management tasks across multiple machines. These activities can trigger the detection rule, leading to false positives. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform these tasks regularly.
+- Monitoring and management software: Some software solutions, such as monitoring tools, may use similar PowerShell commands to gather data or perform actions on remote systems. These benign processes can be excluded by adding their file directories or specific script block texts to the exception list.
+- Automated scripts: Organizations may have automated scripts that utilize WinRM for legitimate purposes, such as deploying updates or configurations. Identifying these scripts and excluding their specific characteristics, like script names or execution paths, can help reduce false positives.
+- Service accounts: Service accounts that are used for legitimate remote management tasks might trigger alerts. Users can exclude these accounts by adding their user IDs to the exception list, ensuring that only unexpected or unauthorized use is flagged.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Conduct a thorough investigation to identify the source of the PowerShell script execution, including reviewing logs for any unauthorized access or changes.
+- Terminate any suspicious PowerShell processes running on the affected system to halt ongoing malicious activities.
+- Reset credentials for any compromised accounts to prevent further unauthorized access.
+- Review and update firewall rules to restrict WinRM access to only trusted hosts and networks.
+- Implement enhanced logging for PowerShell activities, including script block logging and module logging, to improve future detection capabilities.
+- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious activities across the network.
+- Restore the system from a known good backup to ensure the removal of any persistent threats or unauthorized changes.
+- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
+- Educate users and administrators on secure practices for remote management and the risks associated with improper use of WinRM and PowerShell."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
index c6ca1947e93..02280db35de 100644
--- a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
+++ b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,49 @@ network where host.os.type == "windows" and
     ) and process.code_signature.trusted == true
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Potential Outgoing RDP Connection by Unusual Process
+
+Remote Desktop Protocol (RDP) enables users to connect to other systems over a network, facilitating remote management and troubleshooting. However, adversaries can exploit RDP for lateral movement within a network, often bypassing detection by using non-standard processes. The detection rule identifies unusual processes attempting RDP connections, excluding known legitimate applications, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the unusual process attempting the RDP connection, focusing on the `process.executable` field to determine the exact path and name of the executable.
+- Verify the `process.code_signature.trusted` field to check if the process is signed and trusted, which might indicate a false positive if the signature is valid.
+- Examine the `destination.ip` field to identify the target of the RDP connection and determine if it is an internal or external IP address, which can provide context on the potential risk.
+- Investigate the `host.os.type` field to confirm the operating system is Windows, as the rule is specifically designed for Windows environments.
+- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE path = '<path_to_unusual_process>';` to retrieve details like process ID, parent process, and command line arguments.
+- Check the process's parent process to understand the process hierarchy and determine if the parent process is legitimate or potentially malicious.
+- Analyze network logs to identify any other unusual network activity originating from the same host, focusing on other connection attempts or data transfers.
+- Review recent system logs and security events on the host to identify any other suspicious activities or anomalies that coincide with the RDP connection attempt.
+- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of account compromise.
+- Correlate the findings with threat intelligence sources to check if the unusual process or IP address is associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Known false positives may include legitimate applications or scripts that are not part of the predefined exclusion list but are used for remote management or monitoring purposes. These could be custom IT management tools or scripts developed in-house.
+- Users can handle these false positives by identifying and documenting any legitimate processes that frequently trigger the rule. Once identified, these processes can be added to the exclusion list, ensuring they are signed and trusted.
+- Another potential false positive source is automated tasks or scheduled jobs that use RDP for legitimate purposes. Users should review scheduled tasks and automation scripts to determine if they are causing alerts and consider excluding them if they are verified as non-threatening.
+- It's important to regularly review and update the exclusion list to accommodate changes in the organization's software landscape, ensuring that new legitimate tools are not mistakenly flagged.
+- Users should also consider the context of the network environment, such as known IP addresses or subnets that are part of regular operations, and adjust the rule to exclude these from triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Verify the legitimacy of the process attempting the RDP connection by checking its executable path and code signature.
+- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
+- Review recent RDP connection logs to identify any other unusual or unauthorized access attempts.
+- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system.
+- Reset credentials for any accounts that may have been compromised during the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed process execution and network connection events for future investigations.
+- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
+- Apply system hardening measures, such as disabling RDP if not needed, enforcing strong password policies, and ensuring all systems are up to date with security patches."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
index dbc9fce692a..66445e92336 100644
--- a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
+++ b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,49 @@ process where event.type == "start" and host.os.type == "windows" and
     (process.name : "cmd.exe" and process.parent.name : "forfiles.exe" and process.command_line : "/c echo *")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Unusual Process For MSSQL Service Accounts
+
+MSSQL service accounts are integral to managing SQL Server operations, executing processes necessary for database management. Adversaries may exploit these accounts to execute unauthorized processes, gaining initial access or moving laterally within a network. The detection rule identifies atypical processes initiated by MSSQL service accounts, excluding known legitimate activities, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific MSSQL service account and process that triggered the alert, focusing on the `user.name` and `process.name` fields.
+- Verify the legitimacy of the process by checking the `process.executable` path and comparing it against known legitimate paths for MSSQL-related processes.
+- Examine the `process.code_signature` fields to determine if the process is signed by a trusted entity, such as "Microsoft Corporation," and if the signature is valid.
+- Investigate the parent process using the `process.parent.name` field to understand the process hierarchy and identify any unusual parent-child relationships.
+- Check the `process.command_line` field for any suspicious or unexpected command-line arguments that could indicate malicious activity.
+- Use Osquery to gather additional context about the process. For example, run the following query to list all processes started by the MSSQL service account: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'MSSQLSERVER');`
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
+- Investigate the network activity associated with the process to identify any unusual connections or data transfers that could indicate lateral movement or data exfiltration.
+- Review recent changes or updates to the SQL Server configuration or environment that could explain the unusual process execution.
+- Consult with the database administration team to verify if the process execution aligns with any recent maintenance tasks or legitimate administrative activities.
+
+### False positive analysis
+
+- Scheduled tasks or maintenance scripts that run under MSSQL service accounts may trigger false positives if they execute processes not typically associated with SQL operations. Users should review these tasks and consider excluding them if they are verified as legitimate.
+- Custom monitoring or backup solutions that interact with SQL Server and use service accounts might be flagged. Users can create exceptions for these processes by adding them to the exclusion list if they are confirmed to be safe.
+- Third-party applications that integrate with SQL Server and require execution of specific processes under MSSQL service accounts could be mistakenly identified as threats. Users should validate these applications and exclude their processes if they are deemed non-threatening.
+- In environments with custom SQL Server configurations or extensions, legitimate processes might not be recognized by the rule. Users should document these configurations and adjust the detection criteria to prevent unnecessary alerts.
+- Users can manage false positives by regularly reviewing the list of excluded processes and ensuring that only verified, non-malicious activities are exempted from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized processes initiated by MSSQL service accounts.
+- Review and analyze logs from the affected system and related network devices to trace the attacker's activities and identify any additional compromised systems.
+- Terminate any unauthorized processes and remove any malicious files or scripts found on the system.
+- Reset credentials for all MSSQL service accounts and any other potentially compromised accounts to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that future anomalies can be detected more effectively.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events across the network.
+- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are in place.
+- Harden the environment by implementing network segmentation, restricting MSSQL service account permissions, and applying the principle of least privilege to minimize the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_wmic_remote.toml b/rules_building_block/lateral_movement_wmic_remote.toml
index 0125b3949d9..f26e3a63b0c 100644
--- a/rules_building_block/lateral_movement_wmic_remote.toml
+++ b/rules_building_block/lateral_movement_wmic_remote.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,49 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : ("call", "set", "get") and
   not process.args : ("*/node:localhost*", "*/node:\"127.0.0.1\"*", "/node:127.0.0.1")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 WMIC Remote Command
+
+WMIC (Windows Management Instrumentation Command-line) is a powerful tool for managing Windows systems, allowing administrators to execute commands on remote hosts. However, attackers can exploit WMIC for lateral movement by executing commands on other systems within a network. The detection rule identifies suspicious WMIC usage by monitoring command executions targeting remote nodes, excluding local addresses, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of `WMIC.exe` in the `process.name` field and ensure the `process.args` include remote node specifications.
+- Verify the `host.os.type` is "windows" and the `event.type` is "start" to ensure the alert is relevant to the rule.
+- Examine the `process.args` field to identify the specific command executed (e.g., "call", "set", "get") and the targeted remote node.
+- Check for any exclusion patterns in `process.args` to ensure the command was not targeting local addresses like "localhost" or "127.0.0.1".
+- Correlate the alert with other logs or alerts from the same host to identify any patterns or sequences of suspicious activities.
+- Investigate the user account associated with the process execution to determine if it is a legitimate administrative account or potentially compromised.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'WMIC.exe';` to retrieve details like process ID, parent process, and execution path.
+- Analyze network logs to identify any unusual connections or data transfers between the source and target nodes around the time of the alert.
+- Review historical data to determine if there have been previous instances of similar WMIC usage from the same host or user account.
+- Consult threat intelligence sources to check if the remote node or any associated IP addresses have been flagged for malicious activity.
+
+### False positive analysis
+
+- Legitimate administrative tasks: Administrators often use WMIC for routine management tasks across multiple systems, which can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific command patterns that are regularly used for maintenance.
+- Automated scripts and management tools: Some automated scripts or third-party management tools may utilize WMIC to perform legitimate operations on remote hosts. Users should identify these scripts or tools and exclude their specific command patterns or originating accounts from the detection rule.
+- Monitoring and alerting systems: Certain monitoring solutions might use WMIC to gather system information from remote hosts. Users can handle these false positives by excluding the IP addresses or hostnames of known monitoring systems from the rule.
+- Scheduled tasks: Scheduled tasks that use WMIC for legitimate purposes, such as system updates or health checks, can also be excluded by identifying the specific task names or associated user accounts.
+- Testing and development environments: In environments where WMIC is used frequently for testing or development purposes, users can exclude specific IP ranges or hostnames associated with these environments to reduce noise in alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
+- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying other systems that may have been targeted or affected.
+- Review WMIC logs and other relevant system logs to gather evidence of unauthorized access and command execution.
+- Change all credentials that may have been exposed or used during the attack, especially those with administrative privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement enhanced logging policies to capture detailed information on WMIC usage and other remote command executions.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
+- Restore the affected system from a known good backup to ensure it is free from any malicious modifications.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
+- Implement network segmentation and access controls to limit the ability of attackers to move laterally within the network."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
index f4aaaef461d..125e8722286 100644
--- a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
+++ b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,48 @@ query = '''
 event.dataset: aws.cloudtrail and event.provider: "iam.amazonaws.com"
     and event.action: "CreateLoginProfile" and event.outcome: success
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS IAM Login Profile Added to User
+
+AWS IAM login profiles enable console access for users, typically reserved for programmatic access. Adversaries may exploit this by adding a login profile to maintain access even if access keys are changed. The detection rule monitors AWS CloudTrail logs for successful login profile creations, aiding in identifying unauthorized persistence attempts by correlating with other suspicious activities.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the `CreateLoginProfile` event by filtering logs with `event.dataset: aws.cloudtrail` and `event.provider: "iam.amazonaws.com"`.
+- Verify the `event.action: "CreateLoginProfile"` and `event.outcome: success` fields to ensure the login profile creation was successful.
+- Identify the IAM user associated with the login profile creation by examining the `userIdentity.arn` field in the CloudTrail logs.
+- Check the `sourceIPAddress` and `userAgent` fields to determine the origin of the request and assess if it aligns with expected activity.
+- Investigate the `eventTime` field to establish a timeline and correlate with other activities or alerts around the same time.
+- Use Osquery to gather additional context on the IAM user by running a query such as: `SELECT * FROM aws_iam_users WHERE user_name = '<IAM User Name>';` to retrieve details about the user.
+- Examine the IAM user's activity history to identify any unusual or unauthorized actions by querying for recent events involving the user.
+- Review the IAM policies attached to the user to assess their permissions and determine if they have been modified recently.
+- Cross-reference the login profile creation with other security alerts or logs to identify potential patterns or indicators of compromise.
+- Consult with relevant stakeholders or teams to verify if the login profile creation was authorized and aligns with any ongoing projects or changes.
+
+### False positive analysis
+
+- Routine administrative actions: Legitimate IAM administrators may create login profiles for users as part of regular account management or onboarding processes. To handle these, identify and document such activities and consider excluding them from alerts by creating exceptions for specific IAM administrator accounts or known maintenance periods.
+- Automated provisioning tools: Some organizations use automated tools or scripts to manage IAM users, which may include creating login profiles as part of their workflow. To manage these false positives, review and whitelist actions performed by these tools, ensuring they are recognized as non-threatening.
+- User role changes: Users transitioning from programmatic access to console access may require a login profile. In such cases, verify the legitimacy of the role change and exclude these events from alerts by correlating them with approved change management records.
+- Training and testing environments: In environments where IAM configurations are frequently modified for training or testing purposes, these actions may trigger false positives. To mitigate this, exclude specific environments or accounts used for training and testing from the detection rule.
+
+### Response and remediation
+
+- Immediately disable the newly created login profile to prevent unauthorized access.
+- Review CloudTrail logs to identify the source IP and user agent associated with the login profile creation for further investigation.
+- Correlate the event with other suspicious activities, such as unusual login attempts or changes to IAM policies, to assess the scope of the potential compromise.
+- Verify the IAM user's intended use and confirm with the account owner if the login profile creation was authorized.
+- Rotate and reissue access keys for the affected IAM user to ensure no unauthorized access persists.
+- Implement multi-factor authentication (MFA) for all IAM users to enhance security and prevent unauthorized access.
+- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further action is required.
+- Review and update IAM policies to enforce the principle of least privilege and restrict unnecessary permissions.
+- Enhance logging and monitoring by enabling AWS CloudTrail and AWS Config to track changes and maintain a history of AWS account activity.
+- Conduct a security awareness session for users to educate them on the importance of securing IAM credentials and recognizing potential security threats."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
index 6da7d3f2bff..61e13fe0b16 100644
--- a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
+++ b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/01/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,48 @@ event.category:"process" and host.os.type:"linux" and event.type:"start" and eve
 (process.thread.capabilities.effective:"CAP_SYS_ADMIN" or process.thread.capabilities.permitted:"CAP_SYS_ADMIN") and
 not user.id:"0"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 CAP_SYS_ADMIN Assigned to Binary
+
+In Linux, the CAP_SYS_ADMIN capability grants extensive system administration privileges, enabling processes to perform critical operations like mounting filesystems and configuring networks. Adversaries may exploit binaries with this capability to escalate privileges. The detection rule identifies non-root processes executing with CAP_SYS_ADMIN, signaling potential misuse or misconfiguration.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of CAP_SYS_ADMIN in the effective or permitted capabilities of the process, ensuring the process is not running as root (user.id:"0").
+- Identify the process name and path (process.name) to determine if it is a known or expected binary on the system.
+- Check the process's parent process (process.parent.name) to understand the context of how the process was initiated.
+- Investigate the user account (user.id) associated with the process to determine if it is a legitimate user or potentially compromised.
+- Use Osquery to list all processes with CAP_SYS_ADMIN capabilities by running: `SELECT pid, name, path, uid, gid FROM processes WHERE capabilities LIKE '%CAP_SYS_ADMIN%';` to gather more context on other processes with similar capabilities.
+- Examine recent system logs and audit logs for any unusual activity or errors related to the process or user account.
+- Investigate the binary's file integrity and permissions to ensure it has not been tampered with or improperly configured.
+- Cross-reference the process's hash or signature against known malware databases to rule out any known threats.
+- Analyze network activity associated with the process to identify any suspicious connections or data transfers.
+- Consult with system administrators or application owners to verify if the process and its capabilities are expected and authorized within the environment.
+
+### False positive analysis
+
+- Known false positives for the CAP_SYS_ADMIN Assigned to Binary rule may include legitimate administrative tools or scripts that require CAP_SYS_ADMIN capabilities for routine operations, such as backup software, monitoring agents, or container management tools.
+- Users can handle these false positives by creating exceptions for specific processes or users that are known to require CAP_SYS_ADMIN capabilities for legitimate purposes. This can be done by adding exclusions in the detection rule for specific process names or user IDs that are verified to be non-threatening.
+- It is important to regularly review and update these exceptions to ensure they remain relevant and do not inadvertently allow malicious activity. This involves monitoring the behavior of excluded processes to confirm they continue to operate within expected parameters.
+- Additionally, users should consider the context of the system and its typical usage patterns. For example, a development server may have different legitimate uses of CAP_SYS_ADMIN compared to a production server, and exceptions should be tailored accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Conduct a thorough investigation to identify the source of the CAP_SYS_ADMIN capability assignment, reviewing recent changes and user activities.
+- Terminate any suspicious processes running with CAP_SYS_ADMIN capabilities that are not associated with legitimate system administration tasks.
+- Review and audit user accounts and permissions to ensure no unauthorized privilege escalations have occurred.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced logging for process execution and capability changes to improve detection of similar incidents in the future.
+- Integrate security tools with SIEM solutions to automate the detection of CAP_SYS_ADMIN misuse and generate alerts for security teams.
+- Restore the system to a known good state using backups, ensuring that any unauthorized changes are reverted.
+- Apply system hardening measures, such as restricting the use of capabilities and employing the principle of least privilege for user accounts.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_creation_of_kernel_module.toml b/rules_building_block/persistence_creation_of_kernel_module.toml
index 4ba49615de2..8e1226c7d98 100644
--- a/rules_building_block/persistence_creation_of_kernel_module.toml
+++ b/rules_building_block/persistence_creation_of_kernel_module.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,48 @@ file.extension == "ko" and not process.name : (
   "dpkg", "systemd", "falcon-sensor*", "dnf", "yum", "rpm", "cp"
 )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Creation of Kernel Module
+
+Kernel modules are dynamic components that extend the functionality of the Linux kernel, often used for hardware drivers or system enhancements. Adversaries may exploit this by loading malicious modules to gain persistence or execute unauthorized actions at a low level. The detection rule identifies suspicious module creation by monitoring changes in the kernel module directory, excluding known legitimate processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific kernel module file was created or changed, focusing on the file path and extension, particularly looking for ".ko" files in "/lib/modules/*".
+- Identify the process responsible for the creation or modification of the kernel module by examining the process name and ensuring it is not one of the excluded legitimate processes like "dpkg", "systemd", "falcon-sensor*", "dnf", "yum", "rpm", or "cp".
+- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other system activities or logs around the same time.
+- Use Osquery to list all currently loaded kernel modules and compare them against known legitimate modules. Example query: `SELECT * FROM kernel_modules;`
+- Investigate the parent process of the process that created or modified the kernel module to understand the origin of the activity and whether it was initiated by a user or another process.
+- Examine system logs, such as syslog or dmesg, for any related entries that might provide additional context or indicate other suspicious activities around the time of the module creation.
+- Verify the integrity and authenticity of the suspicious kernel module file by checking its hash against known good hashes or using a tool to analyze its contents for malicious code.
+- Investigate the user account associated with the process that created or modified the kernel module to determine if it has been compromised or is exhibiting unusual behavior.
+- Review recent system changes or updates that might have legitimately introduced new kernel modules, ensuring they align with expected maintenance or deployment activities.
+- Cross-reference the alert with threat intelligence sources to determine if the kernel module or associated process is linked to known malware or adversary techniques.
+
+### False positive analysis
+
+- Routine system updates or package installations can trigger false positives as legitimate processes like `dpkg`, `dnf`, `yum`, and `rpm` may create or modify kernel modules during their operations. These processes are already excluded in the detection rule, but additional package managers or custom scripts might need to be added to the exclusion list.
+- Security or monitoring tools such as `falcon-sensor` may also create or modify kernel modules as part of their normal operation. If other similar tools are in use, consider adding them to the exclusion list to prevent false positives.
+- Custom scripts or administrative tasks that involve kernel module management might inadvertently trigger the rule. Users should review these scripts and, if deemed safe, add them to the exclusion list to avoid unnecessary alerts.
+- To handle these false positives, users can update the detection rule to include additional known legitimate processes or paths in the exclusion list, ensuring that only truly suspicious activities are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the kernel module by checking the file's origin, creation time, and associated processes.
+- Use forensic tools to capture a memory dump and disk image of the affected system for further analysis.
+- Review system logs and audit trails to identify any unauthorized access or changes made around the time of the kernel module creation.
+- Remove the suspicious kernel module and any associated files or processes from the system.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
+- Restore the system from a known good backup if the integrity of the system cannot be assured.
+- Implement enhanced logging policies to monitor kernel module directories and critical system files for unauthorized changes.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
+- Review and update security policies and procedures to include kernel module monitoring and ensure compliance with best practices for system hardening and threat mitigation."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_github_new_pat_for_user.toml b/rules_building_block/persistence_github_new_pat_for_user.toml
index 1e6f93f050b..b2a91b7f812 100644
--- a/rules_building_block/persistence_github_new_pat_for_user.toml
+++ b/rules_building_block/persistence_github_new_pat_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,52 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.hashed_token:* and user.name:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 First Occurrence of Personal Access Token (PAT) Use For a GitHub User
+
+Personal Access Tokens (PATs) in GitHub provide a way to authenticate programmatic access to repositories, enabling automation and integration. However, adversaries can exploit PATs to maintain persistent access or manipulate accounts. The detection rule identifies unusual PAT usage by flagging tokens not seen in the past 14 days, helping to uncover potential unauthorized access or account manipulation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific GitHub user and the hashed token involved in the alert.
+- Verify the legitimacy of the GitHub user by cross-referencing with internal user directories or HR records to ensure the account is valid and active.
+- Check the event timestamp to determine when the PAT was first used and correlate it with any known user activities or changes.
+- Investigate the `event.dataset` and `event.category` fields to confirm the event is related to GitHub audit and configuration changes, ensuring the alert is not a false positive.
+- Examine the `github.programmatic_access_type` field to understand the type of token used (OAuth access token or Fine-grained personal access token) and assess the potential risk level.
+- Analyze the user's recent activity logs in GitHub to identify any unusual or unauthorized actions that may have occurred around the time of the PAT usage.
+- Use Osquery to gather additional context on the system where the PAT was used. For example, run the following query to list recent network connections that might indicate where the token was used:
+  ```sql
+  SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL;
+  ```
+- Investigate any recent changes to the user's account settings or permissions in GitHub that could indicate account manipulation.
+- Cross-reference the hashed token with any known compromised tokens or security incidents to determine if it matches any previously identified threats.
+- Collaborate with the user or their manager to verify if the PAT usage was authorized and part of a legitimate automation or integration process.
+
+### False positive analysis
+
+- Frequent legitimate use of new PATs by developers or automation scripts can trigger false positives. Developers often create new tokens for different projects or environments, which may not indicate malicious activity.
+- Automated systems or CI/CD pipelines that generate new PATs for each deployment cycle can also be flagged. These systems might use tokens for short-lived tasks, leading to frequent new token appearances.
+- To manage these false positives, users can create exceptions for known developers or systems that regularly generate new PATs. This can be done by maintaining a whitelist of user accounts or systems that are expected to exhibit such behavior.
+- Implementing a monitoring period longer than 14 days for specific users or systems can help differentiate between normal and suspicious activity, reducing the likelihood of false positives.
+- Regularly reviewing and updating the list of exceptions based on changes in team members or system configurations can ensure that only non-threatening behaviors are excluded from alerts.
+
+### Response and remediation
+
+- Immediately revoke the suspicious Personal Access Token (PAT) to prevent further unauthorized access.
+- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized changes or data access.
+- Notify the affected user and relevant security teams about the incident and provide guidance on securing their account, including changing passwords and enabling two-factor authentication.
+- Investigate the source of the PAT compromise by reviewing logs and identifying any potential phishing attempts or credential leaks.
+- Escalate the incident to the security operations center (SOC) if there is evidence of broader compromise or if multiple accounts are affected.
+- Implement enhanced logging and monitoring for GitHub activities to detect unusual patterns or unauthorized access attempts in the future.
+- Integrate security tools with GitHub to automate the detection and alerting of suspicious PAT usage.
+- Review and update access controls and permissions for GitHub repositories to ensure the principle of least privilege is enforced.
+- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
+- Educate users on the importance of securing their PATs and recognizing phishing attempts to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_github_new_user_added_to_organization.toml b/rules_building_block/persistence_github_new_user_added_to_organization.toml
index 70bec844ae0..ef599c0edbc 100644
--- a/rules_building_block/persistence_github_new_user_added_to_organization.toml
+++ b/rules_building_block/persistence_github_new_user_added_to_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/08"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,48 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.add_member"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 New User Added To GitHub Organization
+
+GitHub organizations manage collaborative projects, where adding users is routine for access control. However, adversaries may exploit this by adding unauthorized users to maintain persistence or manipulate accounts. The detection rule monitors GitHub audit logs for specific actions indicating new user additions, aligning with MITRE ATT&CK's account manipulation tactics, to identify potential security breaches.
+
+### Possible investigation steps
+
+- Review the GitHub audit log entry to confirm the `event.action` is "org.add_member" and verify the `event.dataset` is "github.audit" to ensure the alert is valid.
+- Identify the `user.name` and `user.email` fields in the audit log to determine who added the new user to the organization.
+- Check the `target.user` field to identify the new user added to the organization and gather their profile information.
+- Investigate the `organization.name` field to understand which organization the user was added to and assess the potential impact.
+- Review recent activity logs for the `user.name` who added the new member to identify any unusual or unauthorized actions.
+- Use Osquery to query the system for any recent changes in user accounts or permissions. Example query: `SELECT * FROM users WHERE username = '<new_user>' OR username = '<user_who_added>';`
+- Cross-reference the new user's email and username with known employees or contractors to verify their legitimacy.
+- Check for any recent changes in the organization's repositories or settings that might correlate with the new user addition.
+- Investigate any other alerts or incidents involving the same `user.name` or `target.user` to identify patterns or repeated suspicious behavior.
+- Consult with the organization's team leads or project managers to confirm if the new user addition was expected and authorized.
+
+### False positive analysis
+
+- Routine administrative actions: Regularly scheduled additions of new team members or collaborators by authorized personnel can trigger this rule. To manage this, organizations can maintain a list of known administrators whose actions are considered non-threatening and exclude their activities from triggering alerts.
+- Onboarding processes: Large organizations may have automated scripts or workflows that add new users as part of their onboarding process. These can be excluded by identifying and filtering out actions performed by these specific automation accounts.
+- Temporary project collaborations: Short-term projects may require adding external collaborators, which can be mistaken for unauthorized access. Organizations can create exceptions for specific projects or timeframes to prevent false positives.
+- Organizational restructuring: Changes in team structures or mergers may lead to a spike in user additions. Monitoring these events and temporarily adjusting the rule's sensitivity can help manage false positives during such periods.
+
+### Response and remediation
+
+- Verify the legitimacy of the new user addition by contacting the organization owner or admin to confirm if the addition was authorized.
+- Temporarily restrict the new user's access to sensitive repositories and resources until their legitimacy is confirmed.
+- Review the audit logs for any suspicious activities associated with the new user account, such as unusual repository access or changes.
+- If unauthorized access is confirmed, remove the user from the organization and reset credentials for any affected accounts.
+- Escalate the incident to the security team for further investigation and to determine if additional accounts or systems have been compromised.
+- Implement multi-factor authentication (MFA) for all organization members to enhance account security and prevent unauthorized access.
+- Update and enforce strict access control policies, ensuring that only necessary permissions are granted to users based on their roles.
+- Integrate GitHub audit logs with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting of suspicious activities.
+- Conduct a security awareness training session for organization members to recognize and report potential security threats.
+- Regularly review and update the organization's security policies and procedures to align with best practices and emerging threats."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
index e4a2ed6fd5e..20101b8d9fc 100644
--- a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
+++ b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,49 @@ any where event.dataset == "aws.cloudtrail"
             or startsWith(event.action, "Tag")
     )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 AWS EC2 Instance Interaction with IAM Service
+
+AWS EC2 instances can assume IAM roles to access resources securely, using their instance ID as a session identifier. While this is standard for legitimate operations, attackers may exploit this by assuming roles to manipulate IAM settings, such as creating users or altering permissions. The detection rule identifies unusual role assumptions by EC2 instances, focusing on actions like creating or modifying resources, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the specific EC2 instance involved by examining the `user.id` field for the pattern ":i-" which indicates an assumed role session by an EC2 instance.
+- Check the `event.action` field to determine the specific IAM actions attempted by the EC2 instance, such as "CreateUser" or "AttachRolePolicy", to understand the potential impact.
+- Investigate the `aws.cloudtrail.user_identity.arn` field to identify the assumed role and verify if it aligns with expected roles for the EC2 instance.
+- Analyze the `event.time` field to establish a timeline of events and correlate with other activities in the environment to identify any patterns or anomalies.
+- Use Osquery to gather additional context on the EC2 instance by running a query like `SELECT * FROM ec2_instance_metadata WHERE instance_id = '<instance_id>';` to retrieve metadata about the instance.
+- Cross-reference the `aws.cloudtrail.source_ip_address` field to determine the origin of the request and verify if it matches known IP addresses associated with the EC2 instance.
+- Examine the `aws.cloudtrail.recipient_account_id` field to ensure the actions were performed within the expected AWS account and not across multiple accounts.
+- Check for any recent changes to IAM policies or roles that might have inadvertently allowed the EC2 instance to perform these actions.
+- Review the `aws.cloudtrail.error_code` field for any failed attempts that might indicate probing or unauthorized access attempts.
+- Correlate this event with other security alerts or logs to identify if this activity is part of a larger attack pattern or isolated incident.
+
+### False positive analysis
+
+- EC2 instances that are part of automated workflows or deployment pipelines may frequently assume roles to interact with IAM services for legitimate purposes, such as updating configurations or managing resources. These actions can trigger the rule but are not indicative of malicious activity.
+- Scheduled maintenance tasks or automated scripts that require role assumption to perform routine updates or resource management can also generate false positives. These tasks often involve actions like "Update" or "Create" that match the rule's criteria.
+- Users can manage these false positives by creating exceptions for known EC2 instance IDs or specific IAM roles that are part of regular operations. This can be done by maintaining a list of trusted instance IDs or roles and excluding them from the rule's scope.
+- Another approach is to refine the rule by adding additional context checks, such as verifying the source IP address or the time of the action, to differentiate between expected and unexpected behavior.
+- Regularly reviewing and updating the list of exceptions based on changes in the environment or operational requirements can help minimize false positives while maintaining effective threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized actions.
+- Review CloudTrail logs to identify the scope of the activity, focusing on the specific actions taken by the assumed role.
+- Revoke any newly created IAM users or roles and remove any unauthorized permissions or policies that were added.
+- Conduct a thorough investigation to determine how the credentials were compromised, including checking for any other affected resources.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced logging and monitoring for IAM activities, ensuring that all role assumptions and privilege changes are logged and reviewed regularly.
+- Integrate AWS GuardDuty and AWS Config to provide continuous monitoring and compliance checks for IAM activities.
+- Restore the EC2 instance to its operational state by applying the latest security patches and ensuring that only necessary permissions are granted.
+- Harden the environment by enforcing the principle of least privilege, using IAM policies to restrict access based on roles and responsibilities.
+- Educate users and administrators on security best practices, including the importance of using strong, unique credentials and enabling multi-factor authentication (MFA) for all accounts."""
 
 [rule.investigation_fields]
 field_names = [
diff --git a/rules_building_block/persistence_startup_folder_lnk.toml b/rules_building_block/persistence_startup_folder_lnk.toml
index 0cfb8ff93eb..d2a67877663 100644
--- a/rules_building_block/persistence_startup_folder_lnk.toml
+++ b/rules_building_block/persistence_startup_folder_lnk.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,50 @@ file where host.os.type == "windows" and event.type != "deletion" and file.exten
     (process.name : "APPServerClient.exe" and process.code_signature.status: "trusted" and file.name : "Parallels Client.lnk")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Shortcut File Written or Modified on Startup Folder
+
+In Windows environments, the Startup folder is used to launch programs automatically when a user logs in. Adversaries exploit this by placing or altering shortcut files (.lnk) in this folder to achieve persistence. The detection rule identifies such activities by monitoring for non-deletion events involving .lnk files in the Startup folder, excluding trusted processes, thus highlighting potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific .lnk file path and name that triggered the alert, focusing on the `file.path` and `file.name` fields.
+- Check the `process.name` field to determine which process was responsible for writing or modifying the shortcut file, and verify if it is a known or trusted application.
+- Investigate the `process.code_signature.status` to confirm whether the process is signed and trusted, which might indicate a false positive if the process is legitimate.
+- Use Osquery to list all .lnk files in the Startup folder to identify any other potentially unauthorized shortcuts:
+  ```sql
+  SELECT path, filename FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\%' OR path LIKE 'C:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\StartUp\\\\%';
+  ```
+- Examine the file creation and modification timestamps to determine when the shortcut was created or altered, which can provide context on the timing of the suspicious activity.
+- Cross-reference the user account associated with the `file.path` to determine if the activity aligns with the user's normal behavior or if it appears suspicious.
+- Check the system's event logs for any related login or process execution events around the time the shortcut was modified to gather additional context.
+- Investigate the parent process of the process that created or modified the shortcut to understand the origin of the activity and whether it was initiated by a legitimate application or script.
+- Review any recent changes or installations on the system that might explain the presence of the new or modified shortcut, such as software updates or new applications.
+- If applicable, correlate the findings with network activity logs to identify any external connections or data transfers that coincide with the shortcut file modification, which might indicate a broader compromise.
+
+### False positive analysis
+
+- Known false positives for the Shortcut File Written or Modified on Startup Folder rule include legitimate software installations or updates that create or modify shortcut files in the Startup folder. These can include applications like OneNote, Okta Verify, OneLaunch, and Parallels Client, which are often trusted and not indicative of malicious activity.
+- To manage these false positives, users can create exceptions in the detection rule for processes with verified code signatures that are known to create shortcuts in the Startup folder. This can be done by adding specific conditions to exclude these trusted processes and their associated shortcut files, as demonstrated in the existing rule with exceptions for ONENOTE.EXE, OktaVerifySetup.exe, OneLaunch.exe, and APPServerClient.exe.
+- Regularly review and update the list of trusted processes and their associated shortcut files to ensure that new legitimate applications are not flagged as potential threats. This helps maintain the balance between security and usability by reducing unnecessary alerts while still monitoring for unauthorized persistence attempts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or persistence.
+- Investigate the source of the .lnk file creation or modification by reviewing process execution logs and identifying the responsible process.
+- Verify the legitimacy of the process that created or modified the .lnk file by checking its code signature and cross-referencing with known trusted applications.
+- Remove any unauthorized .lnk files from the Startup folder to eliminate persistence mechanisms.
+- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional malicious software.
+- Restore the system to a known good state using backups or system restore points if available and necessary.
+- Implement logging policies to capture detailed file and process activity, focusing on the Startup folder and related processes.
+- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to enhance monitoring and detection capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if further expertise is required.
+- Review and update security policies and user awareness training to prevent similar incidents in the future, emphasizing the risks of unauthorized software installations and persistence mechanisms."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_transport_agent_exchange.toml b/rules_building_block/persistence_transport_agent_exchange.toml
index d4a1efd3be7..e1158d13ab7 100644
--- a/rules_building_block/persistence_transport_agent_exchange.toml
+++ b/rules_building_block/persistence_transport_agent_exchange.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/08"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,48 @@ event.category: "process" and host.os.type:windows and
     ("scriptCmd.GetSteppablePipeline" and "ForwardHelpTargetName Install-TransportAgent")
   )
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Microsoft Exchange Transport Agent Install Script
+
+Microsoft Exchange Transport Agents are components that process email messages as they move through the transport pipeline. Adversaries may exploit these agents to execute malicious tasks, achieving persistence by installing or enabling rogue agents. The detection rule identifies suspicious use of PowerShell cmdlets related to transport agents, excluding benign activities, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to understand which specific PowerShell cmdlet was used, focusing on "Install-TransportAgent" or "Enable-TransportAgent" as indicated in the query.
+- Check the user ID associated with the event to determine if it deviates from the expected system account (S-1-5-18), which could indicate unauthorized activity.
+- Analyze the script block text captured in the alert to identify any unusual or suspicious patterns that might suggest malicious intent.
+- Investigate the process execution context by examining the parent process and any child processes spawned by the PowerShell command to identify potential lateral movement or further exploitation.
+- Use Osquery to gather additional context on the host by running a query to list all installed transport agents: `SELECT name, version, enabled FROM exchange_transport_agents;` to verify if any unauthorized agents are present.
+- Correlate the event with other logs, such as Windows Event Logs, to identify any related activities or anomalies around the same timeframe, such as failed login attempts or unusual network connections.
+- Check for any recent changes in the Exchange server configuration or permissions that could have facilitated the installation or enabling of a rogue transport agent.
+- Review historical data to determine if similar activities have been observed in the past, which could indicate a recurring threat or persistent adversary.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors that utilize similar techniques involving Microsoft Exchange Transport Agents.
+- Engage with the system owner or administrator to verify if the activity was authorized or part of a legitimate administrative task, ensuring that any benign activities are accounted for.
+
+### False positive analysis
+
+- Routine administrative tasks: Legitimate administrators may use PowerShell cmdlets like "Install-TransportAgent" or "Enable-TransportAgent" during regular maintenance or updates, which can trigger false positives. To manage this, users can create exceptions for known administrative accounts or specific maintenance windows.
+- Monitoring and diagnostic scripts: Some monitoring tools or diagnostic scripts might invoke these cmdlets as part of their operations. Users should identify these tools and exclude their associated processes or script signatures from the detection rule.
+- Automated deployment scripts: Organizations using automated scripts for deploying or configuring Exchange environments might inadvertently trigger the rule. Users can handle this by whitelisting specific script hashes or deployment accounts.
+- Testing environments: In test or development environments, frequent changes and installations might cause false positives. Users can exclude these environments from the rule or adjust the sensitivity of the detection in these contexts.
+
+### Response and remediation
+
+- Immediately isolate the affected Exchange server from the network to prevent further malicious activity and lateral movement.
+- Conduct a thorough investigation to identify any unauthorized transport agents installed on the server by reviewing PowerShell logs and Exchange server logs.
+- Remove any identified malicious transport agents using the Remove-TransportAgent cmdlet and disable any suspicious agents using the Disable-TransportAgent cmdlet.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
+- Review and update the PowerShell logging policy to ensure that all script block logging and module logging are enabled for enhanced visibility into future activities.
+- Implement additional security measures such as application whitelisting and endpoint detection and response (EDR) solutions to detect and prevent unauthorized changes to the Exchange server.
+- Restore the Exchange server from a known good backup if necessary, ensuring that all patches and updates are applied to prevent exploitation of known vulnerabilities.
+- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
+- Educate and train IT staff and users on recognizing and reporting suspicious activities related to Exchange server operations.
+- Monitor for any signs of persistence or re-infection, and ensure that all security measures are continuously updated and tested."""
 
 
 [[rule.filters]]
diff --git a/rules_building_block/privilege_escalation_trap_execution.toml b/rules_building_block/privilege_escalation_trap_execution.toml
index 52787ad90e8..d182472c531 100644
--- a/rules_building_block/privilege_escalation_trap_execution.toml
+++ b/rules_building_block/privilege_escalation_trap_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,48 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name == "trap" and process.args : "SIG*"
 '''
+note = """## Triage and analysis
+
+### Disclaimer
+
+This investigation guide was generated 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 Trap Signals Execution
+Trap signals in Unix-like systems allow processes to execute specific commands when receiving interrupt signals, such as SIGINT or SIGTERM. Adversaries exploit this by embedding malicious commands in trap handlers, enabling unauthorized actions upon signal reception. The detection rule identifies such abuse by monitoring process initiation events where the 'trap' command is executed with signal-related arguments, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'trap' command execution with signal-related arguments, focusing on the fields `process.name` and `process.args`.
+- Examine the `event.type` and `event.action` fields to verify that the process initiation aligns with suspicious activity, such as "exec" or "process_started".
+- Identify the parent process of the 'trap' command using process lineage data to understand the context in which the trap was set.
+- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential privilege escalation.
+- Investigate the command history of the user associated with the process to identify any unusual or unauthorized commands executed prior to the trap setup.
+- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'trap';` to retrieve detailed information about the process.
+- Analyze the system logs for any preceding or subsequent signals (e.g., SIGINT, SIGTERM) that may have triggered the trap, indicating potential misuse.
+- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign.
+- Review network activity logs to detect any outbound connections or data exfiltration attempts following the trap execution.
+- Consult threat intelligence sources to determine if similar trap execution techniques have been reported in recent attacks, providing additional context for the investigation.
+
+### False positive analysis
+
+- Routine administrative scripts: System administrators often use trap commands in scripts to handle signals gracefully during maintenance tasks. These scripts may trigger the detection rule but are typically benign.
+- Development and testing environments: Developers might use trap commands to test signal handling in applications, leading to false positives in environments where such activities are common.
+- Backup and cleanup scripts: Automated scripts for backups or cleanup operations may include trap commands to ensure proper termination and resource release, which can be mistaken for malicious activity.
+- To manage these false positives, users can create exceptions for known scripts or processes by whitelisting specific command paths or user accounts associated with legitimate activities.
+- Implementing a baseline of normal behavior for processes using trap commands can help distinguish between expected and suspicious activities, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized actions and lateral movement.
+- Conduct a thorough investigation to identify the source and scope of the trap signal abuse, focusing on recent changes to trap handlers and associated processes.
+- Review and analyze logs from the affected system to identify any unauthorized commands executed via trap signals, correlating with known MITRE ATT&CK techniques.
+- Remove or disable any malicious trap handlers identified during the investigation to prevent further exploitation.
+- Restore the system to a known good state using backups or system snapshots, ensuring that all malicious modifications are removed.
+- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and signal handling activities.
+- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and processes, using insights from the MITRE ATT&CK framework to strengthen defenses against event-triggered execution techniques.
+- Escalate the incident to relevant internal teams and, if necessary, external partners or authorities, providing detailed findings and context for further action.
+- Apply system hardening measures, such as restricting the use of trap commands to trusted users and processes, and regularly updating security patches to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/tests/test_all_rules.py b/tests/test_all_rules.py
index 9bef889a834..a45bcbcee12 100644
--- a/tests/test_all_rules.py
+++ b/tests/test_all_rules.py
@@ -212,6 +212,24 @@ def test_index_or_data_view_id_present(self):
             """
             self.fail(fail_msg + '\n'.join(failures))
 
+    def test_note_contains_triage_and_analysis(self):
+        """Ensure the note field contains Triage and analysis content for Elastic rules."""
+        failures = []
+
+        for rule in self.all_rules:
+            if not rule.contents.data.is_elastic_rule:
+                continue  # Don't enforce on non-Elastic rules
+
+            note_field = rule.contents.data.get("note")
+
+            # Check if note field contains ## Triage and analysis
+            if not note_field or "## triage and analysis" not in note_field.casefold():
+                failures.append(f"{self.rule_str(rule)}: note field is missing ## Triage and analysis content.")
+
+        if failures:
+            fail_msg = "The following rules failed the note validation (missing investigation guide content):\n"
+            self.fail(fail_msg + "\n".join(failures))
+
 
 class TestThreatMappings(BaseRuleTest):
     """Test threat mapping data for rules."""

From 736b7c5ec3a92ff380a68d8077a13cd1cc0b3bc9 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 8 Jan 2025 15:22:10 -0600
Subject: [PATCH 02/16] Normalize the investigation guide header

---
 ...tial_access_aws_getpassword_for_ec2_instance.toml |  4 ++--
 ...romisedkeyquarantine_policy_attached_to_user.toml | 12 ++++++------
 ...ss_retrieve_secure_string_parameters_via_ssm.toml |  4 ++--
 ...n_route53_dns_query_resolver_config_deletion.toml |  4 ++--
 ...evasion_s3_bucket_lifecycle_expiration_added.toml |  4 ++--
 ...ion_s3_bucket_server_access_logging_disabled.toml | 10 +++++-----
 ...up_ingress_rule_added_for_remote_connections.toml |  4 ++--
 ...iscovery_ec2_multi_region_describe_instances.toml |  4 ++--
 ...ery_ec2_multiple_discovery_api_calls_via_cli.toml |  4 ++--
 ...tion_lambda_external_layer_added_to_function.toml |  4 ++--
 ...on_ssm_command_document_created_by_rare_user.toml |  4 ++--
 .../aws/execution_ssm_sendcommand_by_rare_user.toml  |  4 ++--
 ...tration_ec2_ami_shared_with_separate_account.toml |  4 ++--
 ...ec2_ebs_snapshot_shared_with_another_account.toml |  4 ++--
 ...ion_rds_snapshot_shared_with_another_account.toml |  6 +++---
 ...ket_policy_added_for_external_account_access.toml |  4 ++--
 ...ion_s3_bucket_replicated_to_external_account.toml |  8 ++++----
 ...ltration_sns_email_subscription_by_rare_user.toml |  4 ++--
 ...nstance_cluster_deletion_protection_disabled.toml |  6 +++---
 ...bucket_object_uploaded_with_ransom_extension.toml |  4 ++--
 ...mpact_s3_object_encryption_with_external_key.toml |  4 ++--
 .../aws/impact_s3_object_versioning_disabled.toml    | 10 +++++-----
 ...vement_aws_ssm_start_session_to_ec2_instance.toml |  4 ++--
 ...create_user_via_assumed_role_on_ec2_instance.toml |  4 ++--
 ...rsistence_iam_roles_anywhere_profile_created.toml |  4 ++--
 ...here_trusted_anchor_created_with_external_ca.toml |  4 ++--
 ...a_backdoor_invoke_function_for_any_principal.toml |  4 ++--
 ...ersistence_rds_db_instance_password_modified.toml |  6 +++---
 .../aws/persistence_rds_instance_made_public.toml    |  8 ++++----
 ...ec2_instance_connect_ssh_public_key_uploaded.toml |  4 ++--
 ...iam_customer_managed_policy_attached_to_role.toml |  4 ++--
 ...vilege_escalation_role_assumption_by_service.toml |  4 ++--
 ...privilege_escalation_role_assumption_by_user.toml |  4 ++--
 ...ssume_root_from_rare_user_and_member_account.toml |  4 ++--
 ...access_azure_entra_totp_brute_force_attempts.toml |  4 ++--
 .../threat_intel_indicator_match_address.toml        |  4 ++--
 .../threat_intel_indicator_match_hash.toml           |  4 ++--
 .../threat_intel_indicator_match_registry.toml       |  4 ++--
 .../threat_intel_indicator_match_url.toml            |  4 ++--
 .../threat_intel_rapid7_threat_command.toml          |  4 ++--
 40 files changed, 97 insertions(+), 97 deletions(-)

diff --git a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
index cbb1e5613fc..066ae589412 100644
--- a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
+++ b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Admin Credential Fetch via Assumed Role"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS EC2 Admin Credential Fetch via Assumed Role
 
diff --git a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
index e8549d773a8..11487b63bbf 100644
--- a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
+++ b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/20"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -21,12 +21,12 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS IAM CompromisedKeyQuarantine Policy Attached to User"
 note = """
-## Triage and Analysis
+## 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. 
+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
 
@@ -70,9 +70,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
+any where event.dataset == "aws.cloudtrail"
    and event.action == "AttachUserPolicy"
-   and event.outcome == "success" 
+   and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine")
 '''
 
diff --git a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
index b77b7bdd90c..05875087478 100644
--- a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
+++ b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -28,7 +28,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS Systems Manager SecureString Parameter Request with Decryption Flag"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag
 
diff --git a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
index 0df31df63c9..00c7c497c90 100644
--- a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "Route53 Resolver Query Log Configuration Deleted"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating Route53 Resolver Query Log Configuration Deleted
 
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
index 00d6eb47dfd..d99b4215ed4 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Expiration Lifecycle Configuration Added"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added
 
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
index 6815557fb75..47b812b4bf5 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/12"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ license = "Elastic License v2"
 name = "AWS S3 Bucket Server Access Logging Disabled"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Server Access Logging Disabled
 
@@ -80,9 +80,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
-   and event.action == "PutBucketLogging" 
-   and event.outcome == "success" 
+any where event.dataset == "aws.cloudtrail"
+   and event.action == "PutBucketLogging"
+   and event.outcome == "success"
    and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled")
 '''
 
diff --git a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
index 305ae622ff5..94745a92c6e 100644
--- a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
+++ b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Insecure AWS EC2 VPC Security Group Ingress Rule Added"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added
 
diff --git a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
index ac33fffcfe4..a7d0429b0e1 100644
--- a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
+++ b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/26"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS EC2 Multi-Region DescribeInstances API Calls"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS EC2 Multi-Region DescribeInstances API Calls
 
diff --git a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
index a3e05953da5..42324ef7d46 100644
--- a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
+++ b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS Discovery API Calls via CLI from a Single Resource"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS Discovery API Calls via CLI from a Single Resource
 
diff --git a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
index edd6adb3742..9f08cee9b9d 100644
--- a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
+++ b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS Lambda Layer Added to Existing Function"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS Lambda Layer Added to Existing Function
 
diff --git a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
index 6062fe1ad86..81e0458229c 100644
--- a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
+++ b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SSM Command Document Created by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS SSM Command Document Created by Rare User
 
diff --git a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
index 4f860173b1c..58e6c1d5b61 100644
--- a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
+++ b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/05"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SSM `SendCommand` Execution by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS SSM `SendCommand` Execution by Rare User
 
diff --git a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
index bc1ecf1dadb..1a4feac937c 100644
--- a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "EC2 AMI Shared with Another Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating EC2 AMI Shared with Another Account
 
diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
index 926072b8026..d7329dfa0af 100644
--- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2024/10/02"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ license = "Elastic License v2"
 name = "AWS EC2 EBS Snapshot Shared with Another Account"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS EC2 EBS Snapshot Shared with Another Account
 
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
index 20d686e65be..c0031febfca 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Snapshot Shared with Another Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Snapshot Shared with Another Account
 
@@ -81,7 +81,7 @@ query = '''
 any where event.dataset == "aws.cloudtrail"
     and event.provider == "rds.amazonaws.com"
     and event.outcome == "success"
-    and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute") 
+    and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute")
     and stringContains(aws.cloudtrail.request_parameters, "attributeName=restore")
     and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]")
 '''
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
index 814222060d1..8ff65c6ebbc 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Policy Added to Share with External Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Policy Change to Share with External Account
 
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
index 1939fa0d9ec..11b5f5d081e 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/12"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Replicated to Another Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Replicated to Another Account
 
@@ -73,9 +73,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
+any where event.dataset == "aws.cloudtrail"
    and event.action == "PutBucketReplication"
-   and event.outcome == "success" 
+   and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "Account")
 '''
 
diff --git a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
index 256caac2f0b..43d3d92d2cb 100644
--- a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
+++ b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SNS Email Subscription by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS SNS Email Subscription by Rare User
 
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
index 26419ea1c3a..9725523299f 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/06/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment. 
+Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment.
 """
 false_positives = [
     """
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Deletion Protection Disabled"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled
 
diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
index b6452e68392..d28e4e22a37 100644
--- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
+++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ license = "Elastic License v2"
 name = "Potential AWS S3 Bucket Ransomware Note Uploaded"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded
 
diff --git a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
index 7c80014e43c..c5bec7d3a1b 100644
--- a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
+++ b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ license = "Elastic License v2"
 name = "AWS S3 Object Encryption Using External KMS Key"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Object Encryption Using External KMS Key
 
diff --git a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
index 3e5550fa6ec..9b5a79e4db2 100644
--- a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
+++ b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/08/02"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. 
+Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted.
 """
 false_positives = [
     """
@@ -21,7 +21,7 @@ license = "Elastic License v2"
 name = "AWS S3 Object Versioning Suspended"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Object Versioning Suspended
 
@@ -76,9 +76,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
+any where event.dataset == "aws.cloudtrail"
    and event.action == "PutBucketVersioning"
-   and event.outcome == "success" 
+   and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended")
 '''
 
diff --git a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
index a32e91109c9..c8aec1676cb 100644
--- a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
+++ b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "SSM Session Started to EC2 Instance"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating SSM Session Started to EC2 Instance
 
diff --git a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
index 787afc8f6ad..ade0d2e0e00 100644
--- a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
+++ b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Create User via Assumed Role on EC2 Instance"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS IAM User Creation via Assumed Role on an EC2 Instance
 
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
index 1d800bd6854..f8fd0389964 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Roles Anywhere Profile Creation"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS IAM Roles Anywhere Profile Creation
 
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
index d55e1007ae7..d483f02834f 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA
 
diff --git a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
index 7bc76bfde42..00527b85f4f 100644
--- a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
+++ b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Lambda Function Policy Updated to Allow Public Invocation"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation
 
diff --git a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
index ac4bbc343f9..1cfab6536d8 100644
--- a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
+++ b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/06/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation. 
+Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation.
 """
 false_positives = [
     """
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Password Modified"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Instance or Cluster Password Modified
 
diff --git a/rules/integrations/aws/persistence_rds_instance_made_public.toml b/rules/integrations/aws/persistence_rds_instance_made_public.toml
index 8c40eeebabd..4f7cfb8e0ce 100644
--- a/rules/integrations/aws/persistence_rds_instance_made_public.toml
+++ b/rules/integrations/aws/persistence_rds_instance_made_public.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance Made Public"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Instance Made Public
 
@@ -42,7 +42,7 @@ This rule identifies when an RDS DB instance is created or modified to enable pu
 
 ### Response and Remediation
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes. 
+- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes.
 - **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
 - **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
 - **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
@@ -81,7 +81,7 @@ any where event.dataset == "aws.cloudtrail"
     and event.outcome == "success"
     and (
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true"))
-        or 
+        or
         (event.action in ("CreateDBInstance", "CreateDBCluster") and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true"))
     )
 '''
diff --git a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
index 1e152b855ff..5e74f3fd992 100644
--- a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
+++ b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Instance Connect SSH Public Key Uploaded"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS EC2 Instance Connect SSH Public Key Uploaded
 
diff --git a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
index 0e20b0ca5e4..a857e24bbce 100644
--- a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Customer-Managed Policy Attached to Role by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS IAM Customer-Managed Policy Attachment to Role by Unusual User
 
diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
index c23ae37fbfb..00f976acafe 100644
--- a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
+++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS Role Assumption by Service"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS STS Role Assumption by Service
 
diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
index da41ca73b82..0239f26ff66 100644
--- a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
+++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS Role Assumption by User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS STS Role Assumption by User
 
diff --git a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
index 3bb48c3b9a7..a17bc1e8242 100644
--- a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/24"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS AssumeRoot by Rare User and Member Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS STS AssumeRoot by Rare User and Member Account
 
diff --git a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
index 8bb0b88fad1..353f914e356 100644
--- a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
+++ b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/12/11"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "Azure Entra MFA TOTP Brute Force Attempts"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Azure Entra MFA TOTP Brute Force Attempts
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_address.toml b/rules/threat_intel/threat_intel_indicator_match_address.toml
index 6026f6f265d..13261edbb75 100644
--- a/rules/threat_intel/threat_intel_indicator_match_address.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_address.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel IP Address Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel IP Address Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_hash.toml b/rules/threat_intel/threat_intel_indicator_match_hash.toml
index 236fb01db80..577dd771593 100644
--- a/rules/threat_intel/threat_intel_indicator_match_hash.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_hash.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel Hash Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel Hash Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_registry.toml b/rules/threat_intel/threat_intel_indicator_match_registry.toml
index 5612c34e435..15173c681fb 100644
--- a/rules/threat_intel/threat_intel_indicator_match_registry.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_registry.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel Windows Registry Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel Windows Registry Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_url.toml b/rules/threat_intel/threat_intel_indicator_match_url.toml
index 1f829b8c28c..33d08abe5a2 100644
--- a/rules/threat_intel/threat_intel_indicator_match_url.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_url.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel URL Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel URL Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_rapid7_threat_command.toml b/rules/threat_intel/threat_intel_rapid7_threat_command.toml
index 28bd096da4b..ecba0a4dcf4 100644
--- a/rules/threat_intel/threat_intel_rapid7_threat_command.toml
+++ b/rules/threat_intel/threat_intel_rapid7_threat_command.toml
@@ -4,7 +4,7 @@ integration = ["ti_rapid7_threat_command"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for Rapid7 Threat Command Integration"
 min_stack_version = "8.13.0"
-updated_date = "2024/08/06"
+updated_date = "2025/01/08"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 max_signals = 10000
 name = "Rapid7 Threat Command CVEs Correlation"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Rapid7 Threat Command CVEs Correlation
 

From 114a4b406cf52dcc33ce4b6f3719d3dd3f0fa0e9 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Fri, 10 Jan 2025 14:28:06 -0600
Subject: [PATCH 03/16] Prep - reset files to main for the next bulk update

---
 rules/apm/apm_403_response_to_a_post.toml     | 49 +----------
 .../apm_405_response_method_not_allowed.toml  | 45 +---------
 rules/apm/apm_sqlmap_user_agent.toml          | 48 +---------
 ..._google_drive_malicious_file_download.toml | 48 +---------
 ...and_and_control_non_standard_ssh_port.toml | 45 +---------
 ...s_cookies_chromium_browsers_debugging.toml | 45 +---------
 ...al_access_forced_authentication_pipes.toml | 44 +---------
 ..._evasion_agent_spoofing_mismatched_id.toml | 45 +---------
 ...evasion_agent_spoofing_multiple_hosts.toml | 45 +---------
 ...e_evasion_deleting_websvr_access_logs.toml | 46 +---------
 ...deletion_of_bash_command_line_history.toml | 45 +---------
 ...sion_elastic_agent_service_terminated.toml | 45 +---------
 ..._evasion_encoding_rot13_python_script.toml | 50 +----------
 ...ion_masquerading_space_after_filename.toml | 45 +---------
 .../defense_evasion_timestomp_touch.toml      | 44 +---------
 ...y_virtual_machine_fingerprinting_grep.toml | 45 +---------
 ...m_sendcommand_with_command_parameters.toml | 49 +----------
 ...on_pentest_eggshell_remote_admin_tool.toml | 50 +----------
 ...otential_widespread_malware_infection.toml | 44 +---------
 ...tion_suspicious_java_netcon_childproc.toml | 45 +---------
 .../guided_onboarding_sample_rule.toml        | 47 ++--------
 ..._access_zoom_meeting_with_no_passcode.toml | 46 +---------
 ...ultiple_alerts_different_tactics_host.toml | 45 +---------
 .../multiple_alerts_involving_user.toml       | 44 +---------
 ...l_access_modify_auth_module_or_config.toml | 45 +---------
 ...ersistence_shell_profile_modification.toml | 46 +---------
 ...ence_ssh_authorized_keys_modification.toml | 45 +---------
 ...lege_escalation_echo_nopasswd_sudoers.toml | 44 +---------
 ...ation_setuid_setgid_bit_set_via_chmod.toml | 45 +---------
 ...ilege_escalation_sudo_buffer_overflow.toml | 47 +---------
 ...privilege_escalation_sudoers_file_mod.toml | 43 +--------
 ...collection_cloudtrail_logging_created.toml | 48 +---------
 ...cess_aws_getpassword_for_ec2_instance.toml |  4 +-
 ...keyquarantine_policy_attached_to_user.toml | 12 +--
 ...ieve_secure_string_parameters_via_ssm.toml |  4 +-
 ...cess_root_console_failure_brute_force.toml | 48 +---------
 ...vasion_configuration_recorder_stopped.toml | 48 +---------
 ...ense_evasion_ec2_network_acl_deletion.toml | 49 +----------
 ...n_elasticache_security_group_creation.toml | 47 +---------
 ...he_security_group_modified_or_deleted.toml | 48 +---------
 ...e_evasion_guardduty_detector_deletion.toml | 47 +---------
 ...defense_evasion_rds_instance_restored.toml | 46 +---------
 ...53_dns_query_resolver_config_deletion.toml |  4 +-
 ...sion_s3_bucket_configuration_deletion.toml | 47 +---------
 ..._s3_bucket_lifecycle_expiration_added.toml |  4 +-
 ...bucket_server_access_logging_disabled.toml | 10 +--
 ...ense_evasion_sts_get_federation_token.toml | 45 +---------
 ...ess_rule_added_for_remote_connections.toml |  4 +-
 .../aws/defense_evasion_waf_acl_deletion.toml | 48 +---------
 ...asion_waf_rule_or_rule_group_deletion.toml | 49 +----------
 ...y_ec2_multi_region_describe_instances.toml |  4 +-
 ..._multiple_discovery_api_calls_via_cli.toml |  4 +-
 ...s_multi_region_service_quota_requests.toml | 46 +---------
 ...mbda_external_layer_added_to_function.toml |  4 +-
 ..._new_terms_cloudformation_createstack.toml | 44 +---------
 ...command_document_created_by_rare_user.toml |  4 +-
 ...xecution_ssm_sendcommand_by_rare_user.toml |  4 +-
 ..._ec2_ami_shared_with_separate_account.toml |  4 +-
 ..._snapshot_shared_with_another_account.toml |  4 +-
 ..._full_network_packet_capture_detected.toml | 47 +---------
 .../exfiltration_ec2_vm_export_failure.toml   | 47 +---------
 .../aws/exfiltration_rds_snapshot_export.toml | 49 +----------
 ..._snapshot_shared_with_another_account.toml |  6 +-
 ...icy_added_for_external_account_access.toml |  4 +-
 ...bucket_replicated_to_external_account.toml |  8 +-
 ...n_sns_email_subscription_by_rare_user.toml |  4 +-
 ..._eventbridge_rule_disabled_or_deleted.toml | 47 +---------
 .../impact_ec2_disable_ebs_encryption.toml    | 48 +---------
 ...mpact_efs_filesystem_or_mount_deleted.toml | 47 +---------
 .../aws/impact_iam_group_deletion.toml        | 47 +---------
 ...mk_disabled_or_scheduled_for_deletion.toml | 47 +---------
 .../aws/impact_rds_group_deletion.toml        | 51 +----------
 .../impact_rds_instance_cluster_deletion.toml | 49 +----------
 ..._cluster_deletion_protection_disabled.toml |  6 +-
 .../impact_rds_instance_cluster_stoppage.toml | 48 +---------
 .../aws/impact_rds_snapshot_deleted.toml      | 44 +---------
 ...object_uploaded_with_ransom_extension.toml |  4 +-
 ...3_object_encryption_with_external_key.toml |  4 +-
 .../impact_s3_object_versioning_disabled.toml | 10 +--
 .../aws/initial_access_password_recovery.toml | 47 +---------
 ...al_access_signin_console_login_no_mfa.toml | 45 +---------
 ...aws_ssm_start_session_to_ec2_instance.toml |  4 +-
 ...l_movement_ec2_instance_console_login.toml | 45 +---------
 .../persistence_ec2_network_acl_creation.toml | 50 +----------
 ..._group_configuration_change_detection.toml | 46 +---------
 ...nce_iam_create_login_profile_for_root.toml | 46 +---------
 ...user_via_assumed_role_on_ec2_instance.toml |  4 +-
 .../aws/persistence_iam_group_creation.toml   | 47 +---------
 ...ce_iam_roles_anywhere_profile_created.toml |  4 +-
 ...usted_anchor_created_with_external_ca.toml |  4 +-
 ...oor_invoke_function_for_any_principal.toml |  4 +-
 .../aws/persistence_rds_cluster_creation.toml | 47 +---------
 ...nce_rds_db_instance_password_modified.toml |  6 +-
 .../aws/persistence_rds_group_creation.toml   | 48 +---------
 .../persistence_rds_instance_creation.toml    | 47 +---------
 .../persistence_rds_instance_made_public.toml |  8 +-
 ...ersistence_redshift_instance_creation.toml | 48 +---------
 ...oute_53_domain_transfer_lock_disabled.toml | 47 +---------
 ...domain_transferred_to_another_account.toml | 48 +---------
 ..._53_hosted_zone_associated_with_a_vpc.toml | 48 +---------
 .../aws/persistence_route_table_created.toml  | 48 +---------
 ...tence_route_table_modified_or_deleted.toml | 44 +---------
 ...sistence_sts_assume_role_with_new_mfa.toml | 47 +---------
 ...tance_connect_ssh_public_key_uploaded.toml |  4 +-
 ...tomer_managed_policy_attached_to_role.toml |  4 +-
 ..._escalation_iam_saml_provider_updated.toml | 47 +---------
 ...escalation_role_assumption_by_service.toml |  4 +-
 ...ge_escalation_role_assumption_by_user.toml |  4 +-
 ...oot_from_rare_user_and_member_account.toml |  4 +-
 ..._escalation_sts_getsessiontoken_abuse.toml | 48 +---------
 ...rivilege_escalation_sts_role_chaining.toml | 47 +---------
 ...collection_update_event_hub_auth_rule.toml | 48 +---------
 ...azure_entra_totp_brute_force_attempts.toml |  4 +-
 ..._full_network_packet_capture_detected.toml | 47 +---------
 ...d_device_code_auth_with_broker_client.toml | 45 +---------
 ...ntra_signin_brute_force_microsoft_365.toml | 48 +---------
 ...ute_force_microsoft_365_repeat_source.toml | 48 +---------
 ...cess_first_time_seen_device_code_auth.toml | 44 +---------
 .../credential_access_key_vault_modified.toml | 47 +---------
 ...ccess_storage_account_key_regenerated.toml | 47 +---------
 ...e_application_credential_modification.toml | 48 +---------
 ...sion_azure_automation_runbook_deleted.toml | 48 +---------
 ...asion_azure_blob_permissions_modified.toml | 48 +---------
 ...on_azure_diagnostic_settings_deletion.toml | 47 +---------
 .../defense_evasion_event_hub_deletion.toml   | 48 +---------
 ...ense_evasion_firewall_policy_deletion.toml | 47 +---------
 ...on_frontdoor_firewall_policy_deletion.toml | 47 +---------
 ...nse_evasion_kubernetes_events_deleted.toml | 48 +---------
 ...ense_evasion_network_watcher_deletion.toml | 48 +---------
 ...ense_evasion_suppression_rule_created.toml | 48 +---------
 .../discovery_blob_container_access_mod.toml  | 47 +---------
 .../execution_command_virtual_machine.toml    | 47 +---------
 ...e_service_principal_credentials_added.toml | 49 +----------
 .../azure/impact_kubernetes_pod_deleted.toml  | 48 +---------
 .../azure/impact_resource_group_deletion.toml | 48 +---------
 ...mpact_virtual_network_device_modified.toml | 47 +---------
 ...ial_access_external_guest_user_invite.toml | 48 +---------
 ...ence_azure_automation_account_created.toml | 47 +---------
 ...utomation_runbook_created_or_modified.toml | 47 +---------
 ...ence_azure_automation_webhook_created.toml | 49 +----------
 ...re_conditional_access_policy_modified.toml | 47 +---------
 ...re_global_administrator_role_assigned.toml | 49 +----------
 ...nce_azure_pim_user_added_global_admin.toml | 47 +---------
 ..._added_as_owner_for_azure_application.toml | 47 +---------
 ..._as_owner_for_azure_service_principal.toml | 47 +---------
 ..._azure_kubernetes_rolebinding_created.toml | 48 +---------
 .../command_and_control_beaconing.toml        | 45 +---------
 ...and_control_beaconing_high_confidence.toml | 45 +---------
 .../container_workload_protection.toml        | 45 +---------
 ...s_aws_creds_search_inside_a_container.toml | 44 +---------
 ..._files_compression_inside_a_container.toml | 45 +---------
 ...r_passwords_search_inside_a_container.toml | 45 +---------
 ...ed_object_modified_inside_a_container.toml | 45 +---------
 ...work_tool_launched_inside_a_container.toml | 45 +---------
 ...nt_binary_launched_inside_a_container.toml | 45 +---------
 ...ecutable_via_chmod_inside_a_container.toml | 44 +---------
 ...ecution_interactive_exec_to_container.toml | 44 +---------
 ...shell_spawned_from_inside_a_container.toml | 44 +---------
 ...stener_established_inside_a_container.toml | 44 +---------
 ...ection_established_inside_a_container.toml | 44 +---------
 ...h_process_launched_inside_a_container.toml | 45 +---------
 ..._keys_modification_inside_a_container.toml | 44 +---------
 ...aunched_inside_a_privileged_container.toml | 46 +---------
 ...aunched_inside_a_privileged_container.toml | 45 +---------
 ...e_via_modified_notify_on_release_file.toml | 44 +---------
 ...scape_via_modified_release_agent_file.toml | 44 +---------
 ...ytes_destination_geo_country_iso_code.toml | 47 +---------
 ...ltration_ml_high_bytes_destination_ip.toml | 45 +---------
 ...ration_ml_high_bytes_destination_port.toml | 48 +---------
 ...ml_high_bytes_destination_region_name.toml | 44 +---------
 ...high_bytes_written_to_external_device.toml | 45 +---------
 ...es_written_to_external_device_airdrop.toml | 45 +---------
 ...re_process_writing_to_external_device.toml | 45 +---------
 ...ml_dga_activity_using_sunburst_domain.toml | 45 +---------
 ...d_control_ml_dga_high_sum_probability.toml | 44 +---------
 ...l_ml_dns_request_high_dga_probability.toml | 44 +---------
 ..._request_predicted_to_be_a_dga_domain.toml | 45 +---------
 .../endpoint/elastic_endpoint_security.toml   | 45 +---------
 ...istence_suspicious_file_modifications.toml | 44 +---------
 ...ion_gcp_pub_sub_subscription_creation.toml | 49 +----------
 ...collection_gcp_pub_sub_topic_creation.toml | 47 +---------
 ...nse_evasion_gcp_firewall_rule_created.toml | 46 +---------
 ...nse_evasion_gcp_firewall_rule_deleted.toml | 47 +---------
 ...se_evasion_gcp_firewall_rule_modified.toml | 47 +---------
 ...e_evasion_gcp_logging_bucket_deletion.toml | 48 +---------
 ...nse_evasion_gcp_logging_sink_deletion.toml | 47 +---------
 ...ion_gcp_pub_sub_subscription_deletion.toml | 47 +---------
 ...se_evasion_gcp_pub_sub_topic_deletion.toml | 49 +----------
 ...storage_bucket_configuration_modified.toml | 47 +---------
 ...p_storage_bucket_permissions_modified.toml | 47 +---------
 ...virtual_private_cloud_network_deleted.toml | 47 +---------
 ...p_virtual_private_cloud_route_created.toml | 48 +---------
 ...p_virtual_private_cloud_route_deleted.toml | 48 +---------
 ...tration_gcp_logging_sink_modification.toml | 47 +---------
 .../gcp/impact_gcp_iam_role_deletion.toml     | 47 +---------
 .../impact_gcp_service_account_deleted.toml   | 49 +----------
 .../impact_gcp_service_account_disabled.toml  | 47 +---------
 .../impact_gcp_storage_bucket_deleted.toml    | 47 +---------
 ...l_access_gcp_iam_custom_role_creation.toml | 51 +----------
 ..._gcp_iam_service_account_key_deletion.toml | 47 +---------
 ...e_gcp_key_created_for_service_account.toml | 47 +---------
 ...rsistence_gcp_service_account_created.toml | 48 +---------
 ...hub_protected_branch_settings_changed.toml | 45 +---------
 .../github/execution_github_app_deleted.toml  | 45 +---------
 ..._high_number_of_cloned_repos_from_pat.toml | 45 +---------
 ...multiple_behavior_alerts_from_account.toml | 44 +---------
 .../execution_new_github_app_installed.toml   | 45 +---------
 .../impact_github_repository_deleted.toml     | 44 +---------
 .../persistence_github_org_owner_added.toml   | 44 +---------
 ...tence_organization_owner_role_granted.toml | 46 +---------
 ...yption_key_accessed_by_anonymous_user.toml | 48 +---------
 ...th_login_from_third_party_application.toml | 49 +----------
 ...ogle_workspace_suspended_user_renewed.toml | 47 +---------
 ...covery_denied_service_account_request.toml | 50 +----------
 ...covery_suspicious_self_subject_review.toml | 47 +---------
 .../execution_user_exec_to_pod.toml           | 47 +---------
 ...l_access_anonymous_request_authorized.toml | 47 +---------
 ...ed_service_created_with_type_nodeport.toml | 48 +---------
 ...e_escalation_pod_created_with_hostipc.toml | 47 +---------
 ...calation_pod_created_with_hostnetwork.toml | 47 +---------
 ...e_escalation_pod_created_with_hostpid.toml | 47 +---------
 ...reated_with_sensitive_hostpath_volume.toml | 48 +---------
 ...ege_escalation_privileged_pod_created.toml | 48 +---------
 ...ignment_of_controller_service_account.toml | 47 +---------
 ...ovement_ml_high_mean_rdp_process_args.toml | 47 +---------
 ...ent_ml_high_mean_rdp_session_duration.toml | 45 +---------
 ...ral_movement_ml_high_remote_file_size.toml | 45 +---------
 ...ml_high_variance_rdp_session_duration.toml | 48 +---------
 ...ovement_ml_rare_remote_file_directory.toml | 45 +---------
 ...ovement_ml_rare_remote_file_extension.toml | 45 +---------
 ...spike_in_connections_from_a_source_ip.toml | 45 +---------
 ...ke_in_connections_to_a_destination_ip.toml | 44 +---------
 ...al_movement_ml_spike_in_rdp_processes.toml | 45 +---------
 ...ent_ml_spike_in_remote_file_transfers.toml | 45 +---------
 ...nt_ml_unusual_time_for_an_rdp_session.toml | 45 +---------
 ...llection_microsoft_365_new_inbox_rule.toml | 48 +---------
 ..._365_brute_force_user_account_attempt.toml | 48 +---------
 ...65_potential_password_spraying_attack.toml | 49 +----------
 ...ccess_user_excessive_sso_logon_errors.toml | 48 +---------
 ...osoft_365_exchange_dlp_policy_removed.toml | 47 +---------
 ...change_malware_filter_policy_deletion.toml | 47 +---------
 ..._365_exchange_malware_filter_rule_mod.toml | 49 +----------
 ...65_exchange_safe_attach_rule_disabled.toml | 47 +---------
 ...oft_365_mailboxauditbypassassociation.toml | 47 +---------
 ..._365_exchange_transport_rule_creation.toml | 48 +---------
 ...osoft_365_exchange_transport_rule_mod.toml | 47 +---------
 ...ft_365_mass_download_by_a_single_user.toml | 48 +---------
 ...oft_365_potential_ransomware_activity.toml | 48 +---------
 ...t_365_unusual_volume_of_file_deletion.toml | 48 +---------
 ...5_exchange_anti_phish_policy_deletion.toml | 47 +---------
 ...soft_365_exchange_anti_phish_rule_mod.toml | 47 +---------
 ...osoft_365_exchange_safelinks_disabled.toml | 47 +---------
 ...rosoft_365_impossible_travel_activity.toml | 46 +---------
 ...t_365_impossible_travel_portal_logins.toml | 46 +---------
 ...t_365_portal_login_from_rare_location.toml | 45 +---------
 ...65_user_restricted_from_sending_email.toml | 49 +----------
 ...cess_o365_user_reported_phish_malware.toml | 49 +----------
 ...al_movement_malware_uploaded_onedrive.toml | 48 +---------
 ..._movement_malware_uploaded_sharepoint.toml | 48 +---------
 ...e_suspicious_mailbox_right_delegation.toml | 48 +---------
 ...exchange_dkim_signing_config_disabled.toml | 47 +---------
 ...5_exchange_management_role_assignment.toml | 47 +---------
 ..._365_global_administrator_role_assign.toml | 47 +---------
 ..._teams_custom_app_interaction_allowed.toml | 49 +----------
 ...oft_365_teams_external_access_enabled.toml | 48 +---------
 ...rosoft_365_teams_guest_access_enabled.toml | 47 +---------
 ...ion_new_or_modified_federation_domain.toml | 47 +---------
 ..._app_client_credential_token_exchange.toml | 45 +---------
 ...ta_attempt_to_delete_okta_application.toml | 47 +---------
 ...ta_attempt_to_modify_okta_application.toml | 47 +---------
 .../okta/impact_possible_okta_dos_attack.toml | 47 +---------
 ...initial_access_okta_fastpass_phishing.toml | 51 +----------
 ...ta_user_attempted_unauthorized_access.toml | 51 +----------
 ...cation_sso_from_unknown_client_device.toml | 47 +---------
 ...icious_activity_reported_by_okta_user.toml | 51 +----------
 ...ent_multiple_sessions_for_single_user.toml | 48 +---------
 ...tor_privileges_assigned_to_okta_group.toml | 47 +---------
 ...inistrator_role_assigned_to_okta_user.toml | 46 +---------
 ...ence_attempt_to_create_okta_api_token.toml | 47 +---------
 ...set_mfa_factors_for_okta_user_account.toml | 47 +---------
 ..._or_delete_application_sign_on_policy.toml | 50 +----------
 ...se_evasion_ml_rare_process_for_a_host.toml | 44 +---------
 ..._ml_rare_process_for_a_parent_process.toml | 45 +---------
 ...se_evasion_ml_rare_process_for_a_user.toml | 44 +---------
 ...icious_windows_event_high_probability.toml | 45 +---------
 ...picious_windows_event_low_probability.toml | 49 +----------
 ...ous_windows_process_cluster_from_host.toml | 45 +---------
 ...s_process_cluster_from_parent_process.toml | 48 +---------
 ...ous_windows_process_cluster_from_user.toml | 44 +---------
 .../collection_linux_clipboard_activity.toml  | 44 +---------
 ...and_control_aws_cli_endpoint_url_used.toml | 45 +---------
 ...and_control_curl_socks_proxy_detected.toml | 45 +---------
 ...nd_and_control_ip_forwarding_activity.toml | 57 ++----------
 ...mand_and_control_linux_kworker_netcon.toml | 44 +---------
 ...nd_control_linux_proxychains_activity.toml | 12 ++-
 ..._and_control_linux_ssh_x11_forwarding.toml | 12 ++-
 ...linux_suspicious_proxychains_activity.toml | 12 ++-
 ...l_linux_tunneling_and_port_forwarding.toml | 12 ++-
 ...ial_access_collection_sensitive_files.toml | 45 +---------
 .../credential_access_credential_dumping.toml | 54 ++----------
 ...ntial_access_gdb_init_process_hooking.toml | 55 ++----------
 ...credential_access_gdb_process_hooking.toml | 55 ++----------
 ...ential_linux_local_account_bruteforce.toml | 45 +---------
 ...ntial_successful_linux_ftp_bruteforce.toml | 44 +---------
 ...ntial_successful_linux_rdp_bruteforce.toml | 45 +---------
 ...ential_access_proc_credential_dumping.toml | 58 ++----------
 .../credential_access_ssh_backdoor_log.toml   | 46 +---------
 ...instance_metadata_service_api_request.toml | 48 +---------
 ..._evasion_acl_modification_via_setfacl.toml | 54 ++----------
 ...ion_attempt_to_disable_auditd_service.toml | 56 ++----------
 ...tempt_to_disable_iptables_or_firewall.toml | 53 ++---------
 ...ion_attempt_to_disable_syslog_service.toml | 56 ++----------
 ..._base32_encoding_or_decoding_activity.toml | 57 +++---------
 ...binary_copied_to_suspicious_directory.toml | 45 +---------
 ...defense_evasion_chattr_immutable_file.toml | 45 +---------
 ...ense_evasion_clear_kernel_ring_buffer.toml | 56 ++----------
 ..._creation_of_hidden_files_directories.toml | 45 +---------
 ...nse_evasion_directory_creation_in_bin.toml | 58 +++---------
 ...ense_evasion_disable_apparmor_attempt.toml | 58 +++---------
 ...fense_evasion_disable_selinux_attempt.toml | 59 +++----------
 ...doas_configuration_creation_or_rename.toml | 44 +---------
 ..._evasion_dynamic_linker_file_creation.toml | 46 +---------
 ...asion_esxi_suspicious_timestomp_touch.toml | 58 +++---------
 ...fense_evasion_file_deletion_via_shred.toml | 45 +---------
 ...defense_evasion_file_mod_writable_dir.toml | 45 +---------
 ...defense_evasion_hex_payload_execution.toml | 72 ++++-----------
 ...nse_evasion_hidden_directory_creation.toml | 55 ++----------
 .../defense_evasion_hidden_file_dir_tmp.toml  | 45 +---------
 .../defense_evasion_hidden_shared_object.toml | 45 +---------
 ...on_interactive_shell_from_system_user.toml | 45 +---------
 ...defense_evasion_kernel_module_removal.toml | 63 +++----------
 ...defense_evasion_kthreadd_masquerading.toml | 55 ++----------
 .../linux/defense_evasion_ld_so_creation.toml | 45 +---------
 .../defense_evasion_log_files_deleted.toml    | 45 +---------
 .../defense_evasion_mount_execution.toml      | 58 ++----------
 ...ense_evasion_potential_proot_exploits.toml | 55 ++----------
 .../defense_evasion_rename_esxi_files.toml    | 48 +---------
 ...efense_evasion_rename_esxi_index_file.toml | 47 +---------
 ...evasion_root_certificate_installation.toml | 54 ++----------
 ...ux_configuration_creation_or_renaming.toml | 46 +---------
 ...ense_evasion_ssl_certificate_deletion.toml | 44 +---------
 ...s_utility_executed_via_tmux_or_screen.toml | 64 +++-----------
 ...ense_evasion_unusual_preload_env_vars.toml | 48 +---------
 .../discovery_dynamic_linker_via_od.toml      | 56 ++----------
 .../discovery_esxi_software_via_find.toml     | 58 ++----------
 .../discovery_esxi_software_via_grep.toml     | 61 +++----------
 .../discovery_kernel_module_enumeration.toml  | 48 +---------
 .../linux/discovery_linux_hping_activity.toml | 58 +++---------
 .../linux/discovery_linux_nping_activity.toml | 56 +++---------
 .../discovery_pam_version_discovery.toml      | 64 +++-----------
 .../linux/discovery_ping_sweep_detected.toml  | 45 +---------
 ...ivate_key_password_searching_activity.toml | 64 +++-----------
 rules/linux/discovery_proc_maps_read.toml     | 45 +---------
 .../linux/discovery_process_capabilities.toml | 58 ++----------
 ...very_pspy_process_monitoring_detected.toml | 43 +--------
 ...curity_file_access_via_common_utility.toml | 74 ++++------------
 ...very_sudo_allowed_command_enumeration.toml | 62 +++----------
 .../discovery_suid_sguid_enumeration.toml     | 44 +---------
 ...overy_suspicious_memory_grep_activity.toml | 57 +++---------
 ...ry_suspicious_which_command_execution.toml | 67 +++-----------
 ...overy_unusual_user_enumeration_via_id.toml | 45 +---------
 ...covery_virtual_machine_fingerprinting.toml | 46 +---------
 .../discovery_yum_dnf_plugin_detection.toml   | 64 +++-----------
 ...tion_cupsd_foomatic_rip_file_creation.toml | 11 ++-
 ..._cupsd_foomatic_rip_lp_user_execution.toml | 24 ++---
 ...on_cupsd_foomatic_rip_shell_execution.toml | 29 +++---
 ...omatic_rip_suspicious_child_execution.toml | 13 ++-
 ...ion_curl_cve_2023_38545_heap_overflow.toml | 45 +---------
 ...nnection_from_entrypoint_in_container.toml | 45 +---------
 ...n_file_execution_followed_by_deletion.toml | 45 +---------
 .../execution_interpreter_tty_upgrade.toml    | 62 +++----------
 .../execution_nc_listener_via_rlwrap.toml     | 57 +++---------
 ...ion_netcon_from_rwx_mem_region_binary.toml | 48 +---------
 ...cution_network_event_post_compilation.toml | 44 +---------
 rules/linux/execution_perl_tty_shell.toml     | 46 +---------
 ...xecution_potential_hack_tool_executed.toml | 56 ++----------
 ..._overly_permissive_container_creation.toml | 44 +---------
 ...ss_started_in_shared_memory_directory.toml | 44 +---------
 rules/linux/execution_python_tty_shell.toml   | 56 ++----------
 .../execution_python_webserver_spawned.toml   | 68 +++-----------
 ..._remote_code_execution_via_postgresql.toml | 45 +---------
 ...cution_shell_openssl_client_or_server.toml | 63 +++----------
 ...xecution_shell_via_background_process.toml | 58 +++---------
 ...ion_shell_via_child_tcp_utility_linux.toml | 45 +---------
 ...ecution_shell_via_java_revshell_linux.toml | 45 +---------
 ...on_shell_via_lolbin_interpreter_linux.toml | 44 +---------
 ...execution_shell_via_meterpreter_linux.toml | 45 +---------
 ...execution_shell_via_suspicious_binary.toml | 45 +---------
 ...ution_shell_via_tcp_cli_utility_linux.toml | 45 +---------
 ...ution_shell_via_udp_cli_utility_linux.toml | 48 +---------
 ...traction_or_decrompression_via_funzip.toml | 51 ++---------
 ...us_executable_running_system_commands.toml | 46 +---------
 ...icious_mining_process_creation_events.toml | 44 +---------
 rules/linux/execution_tc_bpf_filter.toml      | 50 ++---------
 .../execution_unix_socket_communication.toml  | 56 ++----------
 ...nknown_rwx_mem_region_binary_executed.toml | 45 +---------
 ...ntial_data_splitting_for_exfiltration.toml | 83 ++++++-----------
 .../impact_data_encrypted_via_openssl.toml    | 45 +---------
 rules/linux/impact_esxi_process_kill.toml     | 45 +---------
 .../impact_memory_swap_modification.toml      | 53 ++---------
 ...ential_linux_ransomware_note_detected.toml | 45 +---------
 ...lateral_movement_ssh_it_worm_download.toml | 59 ++-----------
 ...ment_telnet_network_activity_external.toml | 45 +---------
 ...ment_telnet_network_activity_internal.toml | 44 +---------
 ...istence_apt_package_manager_execution.toml | 53 ++---------
 ...nce_apt_package_manager_file_creation.toml | 46 +---------
 ...ersistence_apt_package_manager_netcon.toml | 46 +---------
 rules/linux/persistence_at_job_creation.toml  | 46 +---------
 .../persistence_chkconfig_service_add.toml    | 11 ++-
 ..._package_manager_plugin_file_creation.toml | 52 ++---------
 ...kage_installation_from_unusual_parent.toml | 44 +---------
 .../persistence_dpkg_unusual_execution.toml   | 45 +---------
 .../linux/persistence_git_hook_execution.toml | 54 ++----------
 .../persistence_git_hook_file_creation.toml   | 45 +---------
 rules/linux/persistence_git_hook_netcon.toml  | 44 +---------
 ...ersistence_git_hook_process_execution.toml | 82 +++++------------
 ...ersistence_kde_autostart_modification.toml |  9 +-
 .../linux/persistence_kernel_driver_load.toml | 45 +---------
 ...stence_kernel_driver_load_by_non_root.toml | 45 +---------
 ...rsistence_kernel_object_file_creation.toml | 45 +---------
 .../persistence_kworker_file_creation.toml    | 10 ++-
 ...sistence_linux_backdoor_user_creation.toml | 13 ++-
 ...e_linux_shell_activity_via_web_server.toml | 11 ++-
 ..._linux_user_added_to_privileged_group.toml | 27 +++---
 ...tence_lkm_configuration_file_creation.toml | 53 +----------
 ...sistence_message_of_the_day_execution.toml | 88 ++++++++++++-------
 ...ggable_authentication_module_creation.toml | 46 +---------
 ...cation_module_creation_in_unusual_dir.toml | 56 ++----------
 ...authentication_module_source_download.toml | 48 +---------
 ...persistence_script_executable_bit_set.toml | 52 ++---------
 ...nce_process_capability_set_via_setcap.toml | 57 ++----------
 ...persistence_rc_local_error_via_syslog.toml | 43 +--------
 ...ence_rc_local_service_already_running.toml | 45 +---------
 ...kage_installation_from_unusual_parent.toml | 45 +---------
 ...sistence_setuid_setgid_capability_set.toml | 21 +++--
 .../persistence_shadow_file_modification.toml | 45 +---------
 ...ence_shell_configuration_modification.toml | 47 +---------
 ...simple_web_server_connection_accepted.toml | 45 +---------
 ...ersistence_simple_web_server_creation.toml | 61 +++----------
 .../linux/persistence_ssh_key_generation.toml | 52 ++---------
 rules/linux/persistence_ssh_netcon.toml       | 45 +---------
 ...stence_ssh_via_backdoored_system_user.toml | 45 +---------
 ...suspicious_file_opened_through_editor.toml | 52 ++---------
 ...e_suspicious_ssh_execution_xzbackdoor.toml | 45 +---------
 ...ersistence_systemd_generator_creation.toml | 45 +---------
 rules/linux/persistence_systemd_netcon.toml   | 48 +---------
 ...ersistence_tainted_kernel_module_load.toml | 48 +---------
 ...ainted_kernel_module_out_of_tree_load.toml | 44 +---------
 .../linux/persistence_udev_rule_creation.toml | 45 +---------
 .../persistence_unusual_pam_grantor.toml      | 45 +---------
 ...ersistence_unusual_sshd_child_process.toml | 44 +---------
 ...ser_or_group_creation_or_modification.toml | 44 +---------
 .../persistence_xdg_autostart_netcon.toml     | 49 +----------
 ..._package_manager_plugin_file_creation.toml | 45 +---------
 ...on_chown_chmod_unauthorized_file_read.toml | 55 ++----------
 ...ation_container_util_misconfiguration.toml | 45 +---------
 .../privilege_escalation_dac_permissions.toml | 46 +---------
 ..._escalation_docker_escape_via_nsenter.toml | 44 +---------
 ..._docker_mount_chroot_container_escape.toml | 55 ++----------
 ...calation_enlightenment_window_manager.toml | 44 +---------
 ...e_escalation_gdb_sys_ptrace_elevation.toml | 44 +---------
 ...lege_escalation_gdb_sys_ptrace_netcon.toml | 48 +---------
 ...lege_escalation_kworker_uid_elevation.toml | 47 +---------
 ...lation_ld_preload_shared_object_modif.toml | 47 +---------
 ...lation_linux_suspicious_symbolic_link.toml | 45 +---------
 ...lege_escalation_linux_uid_int_max_bug.toml | 52 ++---------
 ...n_load_and_unload_of_kernel_via_kexec.toml | 57 +++---------
 ...alation_looney_tunables_cve_2023_4911.toml | 44 +---------
 ...ege_escalation_netcon_via_sudo_binary.toml | 45 +---------
 ...ge_escalation_overlayfs_local_privesc.toml | 44 +---------
 ...vilege_escalation_pkexec_envar_hijack.toml | 52 ++---------
 ...ation_potential_bufferoverflow_attack.toml | 45 +---------
 ...tion_potential_suid_sgid_exploitation.toml | 45 +---------
 ...lation_potential_wildcard_shell_spawn.toml | 55 ++----------
 ...ge_escalation_sda_disk_mount_non_root.toml | 45 +---------
 ...privilege_escalation_shadow_file_read.toml | 45 +---------
 ...vilege_escalation_sudo_cve_2019_14287.toml | 55 ++----------
 .../privilege_escalation_sudo_hijacking.toml  | 46 +---------
 ...tion_sudo_token_via_process_injection.toml | 44 +---------
 ...uspicious_cap_setuid_python_execution.toml | 44 +---------
 ...ion_suspicious_chown_fowner_elevation.toml | 47 +---------
 ...calation_suspicious_passwd_file_write.toml | 44 +---------
 ...alation_suspicious_uid_guid_elevation.toml | 45 +---------
 ...scalation_uid_change_post_compilation.toml | 44 +---------
 ...uid_elevation_from_unknown_executable.toml | 48 +---------
 ...lation_unshare_namespace_manipulation.toml | 52 ++---------
 ...ege_escalation_writable_docker_socket.toml | 44 +---------
 ...edential_access_credentials_keychains.toml | 45 +---------
 ...dential_access_dumping_hashes_bi_cmds.toml | 44 +---------
 ...tial_access_dumping_keychain_security.toml | 45 +---------
 .../credential_access_kerberosdump_kcc.toml   | 44 +---------
 ...s_keychain_pwd_retrieval_security_cmd.toml | 48 +---------
 ...ential_access_mitm_localhost_webproxy.toml | 44 +---------
 ...access_potential_macos_ssh_bruteforce.toml | 44 +---------
 ...al_access_promt_for_pwd_via_osascript.toml | 44 +---------
 ...ous_web_browser_sensitive_file_access.toml | 44 +---------
 .../credential_access_systemkey_dumping.toml  | 44 +---------
 ...vasion_apple_softupdates_modification.toml | 44 +---------
 ...evasion_attempt_del_quarantine_attrib.toml | 49 +----------
 ...evasion_attempt_to_disable_gatekeeper.toml | 44 +---------
 ...ense_evasion_install_root_certificate.toml | 45 +---------
 ..._evasion_modify_environment_launchctl.toml | 45 +---------
 ...cy_controls_tcc_database_modification.toml | 44 +---------
 ...tion_privacy_pref_sshd_fulldiskaccess.toml | 45 +---------
 .../defense_evasion_safari_config_change.toml | 45 +---------
 ...dboxed_office_app_suspicious_zip_file.toml | 45 +---------
 ...vasion_tcc_bypass_mounted_apfs_access.toml | 45 +---------
 ..._evasion_unload_endpointsecurity_kext.toml | 49 +----------
 ...covery_users_domain_built_in_commands.toml | 45 +---------
 ...vasion_electron_app_childproc_node_js.toml | 49 +----------
 ...l_access_suspicious_browser_childproc.toml | 45 +---------
 ...staller_package_spawned_network_event.toml | 45 +---------
 ...cution_script_via_automator_workflows.toml | 46 +---------
 ...ing_osascript_exec_followed_by_netcon.toml | 44 +---------
 ...n_shell_execution_via_apple_scripting.toml | 44 +---------
 ...uspicious_mac_ms_office_child_process.toml | 47 +---------
 ...ential_access_kerberos_bifrostconsole.toml | 44 +---------
 .../lateral_movement_mounting_smb_share.toml  | 45 +---------
 ...ral_movement_remote_ssh_login_enabled.toml | 45 +---------
 ...teral_movement_vpn_connection_attempt.toml | 44 +---------
 ...stence_account_creation_hide_at_logon.toml | 44 +---------
 ...ce_creation_change_launch_agents_file.toml | 45 +---------
 ..._creation_hidden_login_item_osascript.toml | 44 +---------
 ...creation_modif_launch_deamon_sequence.toml | 45 +---------
 ..._access_authorization_plugin_creation.toml | 46 +---------
 rules/macos/persistence_crontab_creation.toml | 45 +---------
 ...launch_agent_deamon_logonitem_process.toml | 51 +----------
 ...rectory_services_plugins_modification.toml | 45 +---------
 ...e_docker_shortcuts_plist_modification.toml | 45 +---------
 ...persistence_emond_rules_file_creation.toml | 44 +---------
 ...istence_emond_rules_process_execution.toml | 44 +---------
 .../persistence_enable_root_account.toml      | 44 +---------
 ...n_hidden_launch_agent_deamon_creation.toml | 48 +---------
 ...sistence_finder_sync_plugin_pluginkit.toml | 49 +----------
 ...istence_folder_action_scripts_runtime.toml | 45 +---------
 ...rsistence_login_logout_hooks_defaults.toml | 45 +---------
 ...fication_sublime_app_plugin_or_script.toml | 45 +---------
 ...ersistence_periodic_tasks_file_mdofiy.toml | 45 +---------
 ...ence_suspicious_calendar_modification.toml | 45 +---------
 ...tence_via_atom_init_file_modification.toml | 44 +---------
 ...calation_applescript_with_admin_privs.toml | 43 +--------
 ...calation_explicit_creds_via_scripting.toml | 45 +---------
 ...alation_exploit_adobe_acrobat_updater.toml | 47 +---------
 ..._escalation_local_user_added_to_admin.toml | 44 +---------
 ...ilege_escalation_root_crontab_filemod.toml | 44 +---------
 ...d_control_ml_packetbeat_dns_tunneling.toml | 46 +---------
 ...ntrol_ml_packetbeat_rare_dns_question.toml | 44 +---------
 ...d_and_control_ml_packetbeat_rare_urls.toml | 45 +---------
 ...control_ml_packetbeat_rare_user_agent.toml | 44 +---------
 ..._access_ml_auth_spike_in_logon_events.toml | 45 +---------
 ...s_ml_linux_anomalous_metadata_process.toml | 45 +---------
 ...cess_ml_linux_anomalous_metadata_user.toml | 44 +---------
 ...l_access_ml_suspicious_login_activity.toml | 47 +---------
 ...ml_windows_anomalous_metadata_process.toml | 44 +---------
 ...ss_ml_windows_anomalous_metadata_user.toml | 45 +---------
 ...ml_linux_system_information_discovery.toml | 44 +---------
 ...ystem_network_configuration_discovery.toml | 45 +---------
 ...x_system_network_connection_discovery.toml | 45 +---------
 ...ery_ml_linux_system_process_discovery.toml | 45 +---------
 ...covery_ml_linux_system_user_discovery.toml | 45 +---------
 ...execution_ml_windows_anomalous_script.toml | 44 +---------
 ...ess_ml_auth_rare_source_ip_for_a_user.toml | 46 +---------
 rules/ml/ml_high_count_network_denies.toml    | 50 +----------
 rules/ml/ml_high_count_network_events.toml    | 46 +---------
 ...linux_anomalous_network_port_activity.toml | 49 +----------
 .../ml/ml_packetbeat_rare_server_domain.toml  | 45 +---------
 rules/ml/ml_rare_destination_country.toml     | 46 +---------
 ...ce_ml_windows_anomalous_path_activity.toml | 46 +---------
 ...sistence_ml_windows_anomalous_service.toml | 43 +--------
 ...tion_ml_linux_anomalous_sudo_activity.toml | 48 +---------
 ...tion_ml_windows_rare_user_runas_event.toml | 45 +---------
 ..._ml_linux_anomalous_compiler_activity.toml | 45 +---------
 ...cepted_default_telnet_port_connection.toml | 45 +---------
 ...mand_and_control_cobalt_strike_beacon.toml | 49 +----------
 ...cobalt_strike_default_teamserver_cert.toml | 47 +---------
 ...download_rar_powershell_from_internet.toml | 51 +----------
 .../command_and_control_halfbaked_beacon.toml | 48 +---------
 ...d_control_nat_traversal_port_activity.toml | 45 +---------
 .../command_and_control_port_26_activity.toml | 45 +---------
 ...te_desktop_protocol_from_the_internet.toml | 45 +---------
 ...l_network_computing_from_the_internet.toml | 48 +---------
 ...ual_network_computing_to_the_internet.toml | 46 +---------
 ...very_potential_network_sweep_detected.toml | 44 +---------
 ...iscovery_potential_port_scan_detected.toml | 43 +--------
 ...very_potential_syn_port_scan_detected.toml | 47 +---------
 ...mote_procedure_call_from_the_internet.toml | 49 +----------
 ...remote_procedure_call_to_the_internet.toml | 45 +---------
 ...file_sharing_activity_to_the_internet.toml | 46 +---------
 ...al_access_unsecure_elasticsearch_node.toml | 48 +---------
 ..._access_endgame_cred_dumping_detected.toml | 48 +---------
 ...access_endgame_cred_dumping_prevented.toml | 45 +---------
 .../endgame_adversary_behavior_detected.toml  | 44 +---------
 .../promotions/endgame_malware_detected.toml  | 45 +---------
 .../promotions/endgame_malware_prevented.toml | 45 +---------
 .../endgame_ransomware_detected.toml          | 48 +---------
 .../endgame_ransomware_prevented.toml         | 44 +---------
 .../execution_endgame_exploit_detected.toml   | 46 +---------
 .../execution_endgame_exploit_prevented.toml  | 45 +---------
 rules/promotions/external_alerts.toml         | 44 +---------
 ...on_endgame_cred_manipulation_detected.toml | 44 +---------
 ...n_endgame_cred_manipulation_prevented.toml | 48 +---------
 ...ion_endgame_permission_theft_detected.toml | 45 +---------
 ...on_endgame_permission_theft_prevented.toml | 44 +---------
 ...on_endgame_process_injection_detected.toml | 44 +---------
 ...n_endgame_process_injection_prevented.toml | 42 +--------
 .../threat_intel_indicator_match_address.toml |  4 +-
 .../threat_intel_indicator_match_hash.toml    |  4 +-
 ...threat_intel_indicator_match_registry.toml |  4 +-
 .../threat_intel_indicator_match_url.toml     |  4 +-
 .../threat_intel_rapid7_threat_command.toml   |  4 +-
 ...lection_email_outlook_mailbox_via_com.toml | 44 +---------
 .../collection_posh_webcam_video_capture.toml | 49 +----------
 ...control_encrypted_channel_freesslcert.toml | 46 +---------
 .../command_and_control_iexplore_via_com.toml | 48 +---------
 ...command_and_control_outlook_home_page.toml | 44 +---------
 ...d_and_control_screenconnect_childproc.toml | 45 +---------
 .../command_and_control_tunnel_vscode.toml    | 44 +---------
 .../credential_access_adidns_wildcard.toml    | 45 +---------
 .../credential_access_adidns_wpad_record.toml | 45 +---------
 ...redential_access_dcsync_user_backdoor.toml | 47 +---------
 .../credential_access_dnsnode_creation.toml   | 45 +---------
 ...redential_access_dollar_account_relay.toml | 45 +---------
 .../credential_access_generic_localdumps.toml | 44 +---------
 ..._access_iis_connectionstrings_dumping.toml | 48 +---------
 ...ccess_imageload_azureadconnectauthsvc.toml | 46 +---------
 .../windows/credential_access_kirbi_file.toml | 45 +---------
 .../credential_access_ldap_attributes.toml    | 48 +---------
 ...l_access_lsass_handle_via_malseclogon.toml | 45 +---------
 ...edential_access_lsass_loaded_susp_dll.toml | 46 +---------
 .../credential_access_posh_relay_tools.toml   | 44 +---------
 .../credential_access_posh_veeam_sql.toml     | 44 +---------
 ..._potential_lsa_memdump_via_mirrordump.toml | 45 +---------
 ...cess_relay_ntlm_auth_via_http_spoolss.toml | 48 +---------
 ...ntial_access_saved_creds_vault_winlog.toml | 45 +---------
 ...redential_access_saved_creds_vaultcmd.toml | 45 +---------
 ...ccess_suspicious_lsass_access_generic.toml | 50 +----------
 ...ccess_suspicious_lsass_access_memdump.toml | 45 +---------
 ..._suspicious_lsass_access_via_snapshot.toml | 45 +---------
 ...ial_access_veeam_backup_dll_imageload.toml | 44 +---------
 .../credential_access_veeam_commands.toml     | 44 +---------
 ...ess_via_snapshot_lsass_clone_creation.toml | 45 +---------
 .../credential_access_wbadmin_ntds.toml       | 44 +---------
 .../defense_evasion_cve_2020_0601.toml        | 44 +---------
 .../windows/defense_evasion_disable_nla.toml  | 44 +---------
 ...efense_evasion_dns_over_https_enabled.toml | 44 +---------
 ...vasion_dotnet_compiler_parent_process.toml | 44 +---------
 ...ecution_control_panel_suspicious_args.toml | 45 +---------
 ...n_execution_msbuild_started_by_script.toml | 46 +---------
 ...ion_msbuild_started_by_system_process.toml | 44 +---------
 ...cution_msbuild_started_unusal_process.toml | 45 +---------
 ...execution_suspicious_explorer_winword.toml | 44 +---------
 ...sion_execution_windefend_unusual_path.toml | 44 +---------
 ..._evasion_file_creation_mult_extension.toml | 45 +---------
 ...sion_hide_encoded_executable_registry.toml | 44 +---------
 .../defense_evasion_injection_msbuild.toml    | 44 +---------
 .../defense_evasion_installutil_beacon.toml   | 45 +---------
 ...efense_evasion_lolbas_win_cdb_utility.toml | 47 +---------
 ...querading_as_elastic_endpoint_process.toml | 44 +---------
 ..._masquerading_business_apps_installer.toml | 45 +---------
 ...asion_masquerading_communication_apps.toml | 48 +---------
 ...erading_suspicious_werfault_childproc.toml | 45 +---------
 ...vasion_masquerading_trusted_directory.toml | 45 +---------
 .../windows/defense_evasion_mshta_beacon.toml | 47 +---------
 ...nse_evasion_msiexec_child_proc_netcon.toml | 45 +---------
 .../defense_evasion_msxsl_network.toml        | 44 +---------
 ...e_evasion_parent_process_pid_spoofing.toml | 48 +---------
 ...persistence_account_tokenfilterpolicy.toml | 46 +---------
 .../defense_evasion_posh_obfuscation.toml     | 45 +---------
 ...ense_evasion_proxy_execution_via_msdt.toml | 47 +---------
 ...eg_disable_enableglobalqueryblocklist.toml | 46 +---------
 ...defense_evasion_root_dir_ads_creation.toml | 45 +---------
 rules/windows/defense_evasion_sc_sdset.toml   | 44 +---------
 ...fense_evasion_sccm_scnotification_dll.toml | 48 +---------
 ...ion_scheduledjobs_at_protocol_enabled.toml | 46 +---------
 .../defense_evasion_script_via_html_app.toml  | 48 +---------
 .../defense_evasion_sip_provider_mod.toml     | 44 +---------
 ...ackdoor_service_disabled_via_registry.toml | 48 +---------
 ...picious_execution_from_mounted_device.toml | 45 +---------
 ...n_suspicious_managedcode_host_process.toml | 45 +---------
 ...efense_evasion_suspicious_scrobj_load.toml | 45 +---------
 ...defense_evasion_suspicious_wmi_script.toml | 44 +---------
 .../defense_evasion_timestomp_sysmon.toml     | 45 +---------
 ...sion_unsigned_dll_loaded_from_suspdir.toml | 46 +---------
 .../defense_evasion_unusual_dir_ads.toml      | 45 +---------
 ...nusual_network_connection_via_dllhost.toml | 45 +---------
 ...asion_unusual_system_vp_child_program.toml | 44 +---------
 ...se_evasion_windows_filtering_platform.toml | 45 +---------
 .../defense_evasion_wsl_bash_exec.toml        | 48 +---------
 .../defense_evasion_wsl_child_process.toml    | 46 +---------
 .../defense_evasion_wsl_filesystem.toml       | 48 +---------
 .../defense_evasion_wsl_kalilinux.toml        | 46 +---------
 ...discovery_active_directory_webservice.toml | 45 +---------
 .../discovery_high_number_ad_properties.toml  | 44 +---------
 ...unusual_discovery_signal_proc_cmdline.toml | 44 +---------
 ...sual_discovery_signal_proc_executable.toml | 44 +---------
 ...arwinds_backdoor_child_cmd_powershell.toml | 44 +---------
 ...inds_backdoor_unusual_child_processes.toml | 45 +---------
 .../windows/execution_com_object_xwizard.toml | 45 +---------
 ...mand_shell_started_by_unusual_process.toml | 44 +---------
 .../execution_command_shell_via_rundll32.toml | 46 +---------
 ...tion_delayed_via_ping_lolbas_unsigned.toml | 45 +---------
 .../execution_downloaded_shortcut_files.toml  | 45 +---------
 .../execution_downloaded_url_file.toml        | 44 +---------
 .../execution_enumeration_via_wmiprvse.toml   | 52 +----------
 ...cution_initial_access_foxmail_exploit.toml | 44 +---------
 ...cution_initial_access_wps_dll_exploit.toml | 45 +---------
 rules/windows/execution_mofcomp.toml          | 44 +---------
 .../execution_posh_hacktool_authors.toml      | 46 +---------
 ...on_powershell_susp_args_via_winscript.toml | 46 +---------
 ...tion_scheduled_task_powershell_source.toml | 45 +---------
 .../windows/execution_suspicious_cmd_wmi.toml | 50 +----------
 ...n_suspicious_image_load_wmi_ms_office.toml | 44 +---------
 ...ion_via_mmc_console_file_unusual_path.toml | 45 +---------
 ...execution_windows_cmd_shell_susp_args.toml | 45 +---------
 ...xecution_windows_powershell_susp_args.toml | 45 +---------
 .../exfiltration_smb_rare_destination.toml    | 46 +---------
 ..._evasion_suspicious_htm_file_creation.toml | 48 +---------
 ...itial_access_execution_from_inetcache.toml | 45 +---------
 ...access_execution_from_removable_media.toml | 45 +---------
 ...l_access_execution_remote_via_msiexec.toml | 49 +----------
 ...al_access_execution_via_office_addins.toml | 48 +---------
 ...cess_exfiltration_first_time_seen_usb.toml | 42 +--------
 ...ial_access_exploit_jetbrains_teamcity.toml | 45 +---------
 ...itial_access_rdp_file_mail_attachment.toml | 45 +---------
 ...ccess_scripts_process_started_via_wmi.toml | 46 +---------
 ...access_suspicious_ms_exchange_process.toml | 49 +----------
 ...ious_ms_exchange_worker_child_process.toml | 47 +---------
 ...explorer_suspicious_child_parent_args.toml | 46 +---------
 ..._access_webshell_screenconnect_server.toml | 44 +---------
 ...l_access_xsl_script_execution_via_com.toml | 44 +---------
 .../lateral_movement_alternate_creds_pth.toml | 45 +---------
 .../windows/lateral_movement_cmd_service.toml | 45 +---------
 rules/windows/lateral_movement_dcom_hta.toml  | 45 +---------
 .../windows/lateral_movement_dcom_mmc20.toml  | 47 +---------
 ...t_dcom_shellwindow_shellbrowserwindow.toml | 48 +---------
 ...n_lanman_nullsessionpipe_modification.toml | 45 +---------
 ...ateral_movement_evasion_rdp_shadowing.toml | 49 +----------
 ..._movement_execution_from_tsclient_mup.toml | 44 +---------
 ...vement_incoming_winrm_shell_execution.toml | 45 +---------
 .../lateral_movement_incoming_wmi.toml        | 46 +---------
 ...ment_mount_hidden_or_webdav_share_net.toml | 45 +---------
 ...l_movement_powershell_remoting_target.toml | 48 +---------
 .../lateral_movement_rdp_sharprdp_target.toml | 44 +---------
 ...ovement_remote_file_copy_hidden_share.toml | 45 +---------
 ...ement_remote_service_installed_winlog.toml | 46 +---------
 ...ement_suspicious_rdp_client_imageload.toml | 44 +---------
 ...l_movement_via_startup_folder_rdp_smb.toml | 45 +---------
 .../lateral_movement_via_wsus_update.toml     | 44 +---------
 .../windows/persistence_ad_adminsdholder.toml | 46 +---------
 .../windows/persistence_app_compat_shim.toml  | 44 +---------
 .../persistence_appcertdlls_registry.toml     | 45 +---------
 ...persistence_browser_extension_install.toml | 45 +---------
 ...tence_evasion_registry_ifeo_injection.toml | 47 +---------
 ...sistence_group_modification_by_system.toml | 44 +---------
 ...sistence_local_scheduled_job_creation.toml | 47 +---------
 ...istence_local_scheduled_task_creation.toml | 46 +---------
 .../persistence_ms_office_addins_file.toml    | 44 +---------
 .../persistence_ms_outlook_vba_template.toml  | 44 +---------
 ...istence_msds_alloweddelegateto_krbtgt.toml | 45 +---------
 ...ersistence_msi_installer_task_startup.toml | 48 +---------
 ...persistence_msoffice_startup_registry.toml | 44 +---------
 .../windows/persistence_netsh_helper_dll.toml | 44 +---------
 ...ll_exch_mailbox_activesync_add_device.toml | 44 +---------
 .../persistence_registry_uncommon.toml        | 45 +---------
 .../persistence_remote_password_reset.toml    | 47 +---------
 ...ce_runtime_run_key_startup_susp_procs.toml | 45 +---------
 ...stence_scheduled_task_creation_winlog.toml | 44 +---------
 .../persistence_scheduled_task_updated.toml   | 45 +---------
 .../persistence_service_dll_unsigned.toml     | 45 +---------
 .../persistence_services_registry.toml        | 45 +---------
 ...nce_suspicious_scheduled_task_runtime.toml | 48 +---------
 ...e_suspicious_service_created_registry.toml | 45 +---------
 ...istence_sysmon_wmi_event_subscription.toml | 45 +---------
 .../persistence_temp_scheduled_task.toml      | 45 +---------
 ...ence_user_account_creation_event_logs.toml | 44 +---------
 .../persistence_via_application_shimming.toml | 45 +---------
 ...rsistence_via_bits_job_notify_command.toml | 48 +---------
 ...sistence_via_hidden_run_key_valuename.toml | 45 +---------
 ...sa_security_support_provider_registry.toml | 44 +---------
 ...emetrycontroller_scheduledtask_hijack.toml | 45 +---------
 ...nt_instrumentation_event_subscription.toml | 45 +---------
 .../persistence_werfault_reflectdebugger.toml | 44 +---------
 ...tion_create_process_as_different_user.toml | 45 +---------
 ...tion_create_process_with_token_unpriv.toml | 45 +---------
 ...privilege_escalation_credroaming_ldap.toml | 45 +---------
 ...e_escalation_dns_serverlevelplugindll.toml | 46 +---------
 ...lege_escalation_expired_driver_loaded.toml | 45 +---------
 ...lege_escalation_exploit_cve_202238028.toml | 44 +---------
 ...calation_gpo_schtask_service_creation.toml | 44 +---------
 ...scalation_krbrelayup_service_creation.toml | 45 +---------
 ...privilege_escalation_lsa_auth_package.toml | 45 +---------
 ...privilege_escalation_make_token_local.toml | 45 +---------
 ...escalation_msi_repair_via_mshelp_link.toml | 48 +---------
 ...scalation_newcreds_logon_rare_process.toml | 45 +---------
 ...ion_port_monitor_print_pocessor_abuse.toml | 45 +---------
 ...ation_printspooler_registry_copyfiles.toml | 48 +---------
 ..._printspooler_service_suspicious_file.toml | 44 +---------
 ...printspooler_suspicious_file_deletion.toml | 45 +---------
 ..._escalation_reg_service_imagepath_mod.toml | 45 +---------
 ...calation_rogue_windir_environment_var.toml | 45 +---------
 ...lation_samaccountname_spoofing_attack.toml | 48 +---------
 ...alation_suspicious_dnshostname_update.toml | 46 +---------
 ...lation_tokenmanip_sedebugpriv_enabled.toml | 48 +---------
 ...lege_escalation_uac_bypass_com_clipup.toml | 44 +---------
 ...ge_escalation_uac_bypass_com_ieinstal.toml | 47 +---------
 ...n_uac_bypass_com_interface_icmluautil.toml | 44 +---------
 ...alation_uac_bypass_diskcleanup_hijack.toml | 45 +---------
 ...escalation_uac_bypass_dll_sideloading.toml | 46 +---------
 ...lege_escalation_unquoted_service_path.toml | 45 +---------
 ...ion_unusual_printspooler_childprocess.toml | 48 +---------
 ...n_unusual_svchost_childproc_childless.toml | 44 +---------
 ...rivilege_escalation_via_ppid_spoofing.toml | 49 +----------
 ...ilege_escalation_via_rogue_named_pipe.toml | 48 +---------
 .../privilege_escalation_via_token_theft.toml | 49 +----------
 ...on_windows_service_via_unusual_client.toml | 45 +---------
 ...rivilege_escalation_wpad_exploitation.toml | 45 +---------
 ...collection_archive_data_zip_imageload.toml | 48 +---------
 ...ction_common_compressed_archived_file.toml | 47 +---------
 ...tion_files_staged_in_recycle_bin_root.toml | 45 +---------
 .../collection_outlook_email_archive.toml     | 45 +---------
 .../collection_posh_compression.toml          | 44 +---------
 ...ommand_and_control_bitsadmin_activity.toml | 44 +---------
 ...ntial_access_iis_apppoolsa_pwd_appcmd.toml | 44 +---------
 .../credential_access_mdmp_file_creation.toml | 46 +---------
 ...al_access_mdmp_file_unusual_extension.toml | 48 +---------
 ...dential_access_win_private_key_access.toml | 46 +---------
 ...ense_evasion_aws_rds_snapshot_created.toml | 44 +---------
 ...ense_evasion_cmd_copy_binary_contents.toml | 45 +---------
 .../defense_evasion_cmstp_execution.toml      | 45 +---------
 ...rading_unusual_archive_file_extension.toml | 47 +---------
 ...ication_apps_suspicious_child_process.toml | 46 +---------
 .../defense_evasion_dll_hijack.toml           | 45 +---------
 ...evasion_dotnet_clickonce_dfsvc_netcon.toml | 48 +---------
 ...fense_evasion_download_susp_extension.toml | 44 +---------
 ...cution_via_visualstudio_prebuildevent.toml | 49 +----------
 ..._evasion_file_permission_modification.toml | 45 +---------
 .../defense_evasion_generic_deletion.toml     | 44 +---------
 ...indirect_command_exec_pcalua_forfiles.toml | 47 +---------
 ...fense_evasion_injection_from_msoffice.toml | 45 +---------
 ..._evasion_installutil_command_activity.toml | 45 +---------
 ...se_evasion_invalid_codesign_imageload.toml | 46 +---------
 ...defense_evasion_masquerading_browsers.toml | 48 +---------
 ...squerading_unusual_exe_file_extension.toml | 45 +---------
 .../defense_evasion_masquerading_vlc_dll.toml | 45 +---------
 ...ense_evasion_masquerading_windows_dll.toml | 51 +----------
 ...ion_masquerading_windows_system32_exe.toml | 49 +----------
 ...fense_evasion_msdt_suspicious_diagcab.toml | 45 +---------
 ...on_msiexec_installsource_archive_file.toml | 45 +---------
 ...fense_evasion_posh_defender_tampering.toml | 44 +---------
 ..._evasion_powershell_clear_logs_script.toml | 44 +---------
 ...vasion_processes_with_trailing_spaces.toml | 45 +---------
 ...nse_evasion_service_disabled_registry.toml | 45 +---------
 ...defense_evasion_service_path_registry.toml | 45 +---------
 .../defense_evasion_services_exe_path.toml    | 44 +---------
 ..._evasion_suspicious_msiexec_execution.toml | 45 +---------
 .../defense_evasion_unsigned_bits_client.toml | 45 +---------
 ...nse_evasion_unusual_process_extension.toml | 44 +---------
 ...nse_evasion_unusual_process_path_wbem.toml | 44 +---------
 .../defense_evasion_write_dac_access.toml     | 45 +---------
 .../discovery_capnetraw_capability.toml       | 44 +---------
 .../discovery_generic_account_groups.toml     | 44 +---------
 .../discovery_generic_process_discovery.toml  | 44 +---------
 .../discovery_generic_registry_query.toml     | 45 +---------
 .../discovery_hosts_file_access.toml          | 48 +---------
 .../discovery_internet_capabilities.toml      | 45 +---------
 ...ry_kernel_module_enumeration_via_proc.toml | 45 +---------
 .../discovery_linux_modprobe_enumeration.toml | 44 +---------
 .../discovery_linux_sysctl_enumeration.toml   | 45 +---------
 ...ry_linux_system_information_discovery.toml | 46 +---------
 ...ery_linux_system_owner_user_discovery.toml | 45 +---------
 .../discovery_net_share_discovery_winlog.toml | 45 +---------
 ..._accounts_or_groups_via_builtin_tools.toml | 46 +---------
 .../discovery_of_domain_groups.toml           | 44 +---------
 .../discovery_posh_generic.toml               | 45 +---------
 .../discovery_posh_password_policy.toml       | 46 +---------
 ...ery_potential_memory_seeking_activity.toml | 45 +---------
 ...y_process_discovery_via_builtin_tools.toml | 45 +---------
 .../discovery_signal_unusual_user_host.toml   | 44 +---------
 ...discovery_suspicious_proc_enumeration.toml | 45 +---------
 .../discovery_system_network_connections.toml | 45 +---------
 .../discovery_system_service_discovery.toml   | 44 +---------
 .../discovery_system_time_discovery.toml      | 43 +--------
 ...ry_userdata_request_from_ec2_instance.toml | 44 +---------
 .../discovery_win_network_connections.toml    | 45 +---------
 ..._windows_system_information_discovery.toml | 45 +---------
 ...execution_aws_lambda_function_updated.toml | 46 +---------
 ...ution_github_new_event_action_for_pat.toml | 45 +---------
 ...n_github_new_repo_interaction_for_pat.toml | 44 +---------
 ..._github_new_repo_interaction_for_user.toml | 44 +---------
 .../execution_github_repo_created.toml        | 45 +---------
 ...n_github_repo_interaction_from_new_ip.toml | 47 +---------
 .../execution_linux_segfault.toml             | 44 +---------
 ...ution_settingcontent_ms_file_creation.toml | 44 +---------
 ...execution_unsigned_service_executable.toml | 45 +---------
 .../execution_wmi_wbemtest.toml               | 45 +---------
 ...thub_member_removed_from_organization.toml | 45 +---------
 .../impact_github_pat_access_revoked.toml     | 45 +---------
 ...github_user_blocked_from_organization.toml | 46 +---------
 .../initial_access_cross_site_scripting.toml  | 48 +---------
 ..._access_github_new_ip_address_for_pat.toml | 45 +---------
 ...access_github_new_ip_address_for_user.toml | 45 +---------
 ..._access_github_new_user_agent_for_pat.toml | 44 +---------
 ...access_github_new_user_agent_for_user.toml | 45 +---------
 rules_building_block/lateral_movement_at.toml | 45 +---------
 .../lateral_movement_posh_winrm_activity.toml | 44 +---------
 ...ral_movement_rdp_conn_unusual_process.toml | 45 +---------
 ...movement_unusual_process_sql_accounts.toml | 45 +---------
 .../lateral_movement_wmic_remote.toml         | 45 +---------
 ...e_aws_iam_login_profile_added_to_user.toml | 44 +---------
 ...nce_cap_sys_admin_added_to_new_binary.toml | 44 +---------
 ...persistence_creation_of_kernel_module.toml | 44 +---------
 .../persistence_github_new_pat_for_user.toml  | 48 +---------
 ...github_new_user_added_to_organization.toml | 44 +---------
 ...e_iam_instance_request_to_iam_service.toml | 45 +---------
 .../persistence_startup_folder_lnk.toml       | 46 +---------
 .../persistence_transport_agent_exchange.toml | 44 +---------
 .../privilege_escalation_trap_execution.toml  | 44 +---------
 917 files changed, 1898 insertions(+), 38862 deletions(-)

diff --git a/rules/apm/apm_403_response_to_a_post.toml b/rules/apm/apm_403_response_to_a_post.toml
index 1792cc910fd..d8010b71afc 100644
--- a/rules/apm/apm_403_response_to_a_post.toml
+++ b/rules/apm/apm_403_response_to_a_post.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -32,51 +32,4 @@ type = "query"
 query = '''
 http.response.status_code:403 and http.request.method:post
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Web Application Suspicious Activity: POST Request Declined
-
-Web applications often use POST requests to handle data submissions securely. However, adversaries may exploit this by attempting unauthorized actions, triggering a 403 error when access is denied. The detection rule identifies such anomalies by flagging POST requests that receive a 403 response, indicating potential misuse or probing by attackers.
-
-### Possible investigation steps
-
-- Review the specific POST request details, including the URL and parameters, to understand what action was attempted and why it might have been denied.
-- Examine the source IP address of the POST request to determine if it is associated with known malicious activity or if it is an unusual source for your application.
-- Check the user-agent string in the request headers to identify if the request was made by a legitimate browser or a suspicious tool or script.
-- Analyze the frequency and pattern of 403 responses from the same IP or user-agent to identify potential probing or brute force attempts.
-- Investigate the timing of the POST request in relation to other suspicious activities in the logs to identify any correlation with other alerts or incidents.
-- Use Osquery to gather additional context from the server hosting the web application. For example, run the following query to check for recent changes in web server configuration files that might affect POST request handling:
-  ```sql
-  SELECT * FROM file WHERE path LIKE '/etc/httpd/conf/httpd.conf' OR path LIKE '/etc/nginx/nginx.conf' ORDER BY mtime DESC LIMIT 5;
-  ```
-- Review application logs for any error messages or warnings around the time of the POST request to identify potential misconfigurations or application errors.
-- Check for any recent updates or changes to the web application code that might have inadvertently introduced stricter access controls or bugs.
-- Investigate whether the POST request was part of a legitimate user's session by correlating it with authentication logs and session data.
-- Consult threat intelligence sources to determine if there are any known vulnerabilities or attack patterns associated with the specific endpoint or application version targeted by the POST request.
-
-### False positive analysis
-
-- Legitimate users may trigger a 403 response when they attempt to access restricted areas of a web application without proper permissions, such as administrative sections or user-specific content.
-- Automated scripts or bots used for web scraping or data collection might inadvertently cause 403 errors if they attempt to access protected resources, leading to false positives.
-- Security tools or plugins that perform vulnerability scanning on web applications can generate POST requests that result in 403 responses, which are not necessarily malicious.
-- Users can manage these false positives by creating exceptions for known IP addresses or user agents that frequently cause 403 errors but are verified as non-threatening.
-- Implementing a whitelist for specific endpoints or user roles that are known to trigger 403 responses during normal operations can help reduce unnecessary alerts.
-- Regularly reviewing and updating the list of exceptions based on the analysis of web application logs and user behavior patterns can help maintain the accuracy of the detection rule.
-
-### Response and remediation
-
-- Immediately review the logs to identify the source IP address of the suspicious POST requests and block it at the firewall or web application firewall (WAF) to prevent further unauthorized attempts.
-- Analyze the request payloads to determine if there are any patterns or specific data being targeted, which could indicate the attacker's intent or the vulnerability being exploited.
-- Conduct a thorough review of the web application's access control policies to ensure that permissions are correctly configured and that sensitive endpoints are adequately protected.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity appears to be part of a larger attack campaign or if multiple systems are affected.
-- Implement enhanced logging for POST requests, including capturing request headers and payloads, to improve visibility and aid in future investigations.
-- Integrate threat intelligence feeds to correlate the detected activity with known attack patterns or threat actors, providing additional context for the investigation.
-- Restore any affected systems or services to their operational state by rolling back unauthorized changes and applying necessary patches or updates to address any identified vulnerabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement security hardening measures such as input validation, rate limiting, and multi-factor authentication to reduce the risk of similar incidents in the future.
-- Educate development and operations teams on secure coding practices and the importance of regular security assessments to prevent exploitation of web application vulnerabilities."""
 
diff --git a/rules/apm/apm_405_response_method_not_allowed.toml b/rules/apm/apm_405_response_method_not_allowed.toml
index 4021b259177..bedc96ade16 100644
--- a/rules/apm/apm_405_response_method_not_allowed.toml
+++ b/rules/apm/apm_405_response_method_not_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -32,47 +32,4 @@ type = "query"
 query = '''
 http.response.status_code:405
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Web Application Suspicious Activity: Unauthorized Method
-
-Web applications use HTTP methods to define actions on resources. A 405 status code signals a method is not allowed, often due to misconfigurations or probing by attackers. Adversaries may exploit this by testing various methods to find vulnerabilities. The detection rule identifies such attempts by flagging responses with a 405 status, indicating potential unauthorized method usage.
-
-### Possible investigation steps
-
-- Review the logs for the specific time frame when the 405 status code was triggered to identify any patterns or anomalies in the requests.
-- Examine the source IP addresses associated with the 405 responses to determine if they are known or potentially malicious.
-- Analyze the user-agent strings in the requests to identify if they are associated with known malicious tools or scripts.
-- Check the HTTP methods used in the requests that resulted in a 405 response to understand which methods were attempted.
-- Investigate the requested URLs or endpoints to determine if they are legitimate resources or if they appear to be probing for vulnerabilities.
-- Correlate the 405 response events with other security events or alerts to identify any related suspicious activity.
-- Use Osquery to gather additional context from the web server, such as running processes or open network connections. Example query: `SELECT * FROM processes WHERE name LIKE '%httpd%' OR name LIKE '%nginx%';`
-- Review the web application configuration files to ensure that the HTTP methods are correctly configured and that there are no misconfigurations.
-- Check for any recent changes or updates to the web application or server that might have affected the allowed HTTP methods.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar activity.
-
-### False positive analysis
-
-- Legitimate applications or services may trigger a 405 response when they are misconfigured or when certain HTTP methods are intentionally disabled for security reasons. 
-- Automated tools or scripts used for testing or monitoring web applications might inadvertently use unsupported HTTP methods, resulting in 405 responses.
-- Web crawlers or bots that are not malicious but are poorly configured can also cause 405 status codes by attempting to access resources with incorrect methods.
-- To manage these false positives, users can create exceptions for known and trusted IP addresses or user agents that frequently trigger 405 responses without malicious intent.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately review the web server logs to identify the source IP addresses and user agents associated with the 405 status code responses to determine if they are part of a legitimate request or a potential attack.
-- Block or rate-limit the identified suspicious IP addresses at the firewall or web application firewall (WAF) to prevent further unauthorized method attempts.
-- Conduct a thorough investigation to determine if the unauthorized method attempts were successful in exploiting any vulnerabilities, and assess the potential impact on the system.
-- Review and update the web application's configuration to ensure that only necessary HTTP methods are allowed for each resource, reducing the attack surface.
-- Escalate the incident to the security operations team if there is evidence of a coordinated attack or if sensitive data may have been exposed.
-- Implement enhanced logging policies to capture detailed information about HTTP requests, including headers and payloads, to aid in future investigations.
-- Integrate security information and event management (SIEM) systems with web server logs to enable real-time monitoring and alerting of suspicious activities.
-- Restore the system to its operational state by applying patches or updates to address any identified vulnerabilities and ensure the web application is functioning correctly.
-- Conduct a post-incident review to analyze the attack vectors and improve the incident response plan, incorporating lessons learned from the investigation.
-- Implement hardening measures such as disabling unused HTTP methods, enforcing strong authentication and authorization controls, and regularly testing the web application for vulnerabilities."""
 
diff --git a/rules/apm/apm_sqlmap_user_agent.toml b/rules/apm/apm_sqlmap_user_agent.toml
index 9c6d0d1111f..c8ba5b28669 100644
--- a/rules/apm/apm_sqlmap_user_agent.toml
+++ b/rules/apm/apm_sqlmap_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -32,50 +32,4 @@ type = "query"
 query = '''
 user_agent.original:"sqlmap/1.3.11#stable (http://sqlmap.org)"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Web Application Suspicious Activity: sqlmap User Agent
-
-Sqlmap is a widely-used open-source tool designed to automate the detection and exploitation of SQL injection vulnerabilities in web applications. While beneficial for security testing, adversaries can exploit it to gain unauthorized access to databases. The detection rule identifies suspicious activity by flagging the specific user agent string associated with sqlmap, helping security analysts pinpoint potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the sqlmap user agent string: `sqlmap/1.3.11#stable (http://sqlmap.org)` in the `user_agent.original` field.
-- Correlate the timestamp of the alert with web server logs to identify the source IP address and any associated requests.
-- Investigate the source IP address to determine if it is known for malicious activity or if it belongs to a legitimate user or organization.
-- Examine the request URL and parameters in the web server logs to identify any potential SQL injection attempts or unusual patterns.
-- Check for any other user agents or unusual activity from the same IP address around the time of the alert to identify patterns of behavior.
-- Use Osquery to gather additional context on the system that received the request. For example, run the following Osquery query to list recent web server access logs:
-  ```sql
-  SELECT * FROM apache_access WHERE user_agent = 'sqlmap/1.3.11#stable (http://sqlmap.org)';
-  ```
-- Investigate any database logs or alerts for suspicious queries or access patterns that coincide with the time of the alert.
-- Review any recent changes or updates to the web application that might have introduced vulnerabilities or altered security configurations.
-- Check for any other alerts or incidents involving the same user agent or IP address across different systems or applications.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently using sqlmap for malicious purposes.
-
-### False positive analysis
-
-- Legitimate security teams or developers may use sqlmap for authorized penetration testing, leading to false positives when the tool is used in a controlled environment.
-- Automated security scans or vulnerability assessments conducted by third-party services might trigger the rule if sqlmap is part of their testing suite.
-- To manage these false positives, organizations can create exceptions for known IP addresses or user agents associated with authorized security testing activities.
-- Implementing a whitelist of IP addresses or user agents for trusted security tools can help reduce noise and focus on genuine threats.
-- Regularly review and update the list of exceptions to ensure that only current and authorized activities are excluded from alerts.
-
-### Response and remediation
-
-- Immediately block the IP address associated with the suspicious sqlmap user agent activity to prevent further unauthorized access attempts.
-- Conduct a thorough investigation of the affected web application logs to identify any successful SQL injection attempts and assess the extent of potential data exposure.
-- Review and update web application firewall (WAF) rules to detect and block SQL injection attempts more effectively.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed user agent strings and other relevant HTTP request headers for future analysis.
-- Integrate threat intelligence feeds to correlate detected sqlmap activity with known malicious IP addresses and attack patterns.
-- Restore any compromised databases from the most recent clean backup and ensure that all patches and updates are applied to the database management system.
-- Conduct a security review of the web application code to identify and remediate any SQL injection vulnerabilities.
-- Educate development and operations teams on secure coding practices and the importance of input validation to prevent SQL injection attacks.
-- Consider deploying additional security measures such as intrusion detection systems (IDS) and regular vulnerability assessments to strengthen the overall security posture."""
 
diff --git a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
index 9e13383d8df..cde6a30ffa4 100644
--- a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
+++ b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/19"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/09"
 
 [rule]
 author = ["Elastic"]
@@ -49,52 +49,6 @@ process where
     /* Look for Google Drive download URL with AV flag skipping */
     (process.command_line : "*drive.google.com*" and process.command_line : "*export=download*" and process.command_line : "*confirm=no_antivirus*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious File Downloaded from Google Drive
-
-Google Drive is a widely used cloud storage service that allows users to store and share files. Adversaries may exploit its trusted nature to deliver malicious payloads by crafting URLs that bypass antivirus checks. The detection rule identifies unusual download activities from Google Drive by monitoring browser processes and specific URL patterns, flagging potential threats for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the suspicious Google Drive URL pattern, specifically checking for the `*drive.google.com*`, `*export=download*`, and `*confirm=no_antivirus*` strings in the `process.command_line`.
-- Identify the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior.
-- Examine the process tree to understand the parent and child processes of the suspicious download activity, which can provide context on how the download was initiated.
-- Check the timestamp of the event to correlate with other security events or logs that might indicate related suspicious activities.
-- Investigate the network connections made by the process using the suspicious URL to identify any unusual or unauthorized data transfers.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with command lines containing the suspicious Google Drive URL pattern:
-  ```sql
-  SELECT pid, name, path, cmdline, start_time FROM processes WHERE cmdline LIKE '%drive.google.com%' AND cmdline LIKE '%export=download%' AND cmdline LIKE '%confirm=no_antivirus%';
-  ```
-- Analyze browser history and cache files to determine if the user visited any other suspicious or related URLs around the time of the alert.
-- Review any downloaded files for malicious content using a sandbox environment or antivirus tools to assess potential threats.
-- Check for any recent changes in browser extensions or plugins that might have facilitated the download of the suspicious file.
-- Consult threat intelligence sources to see if the specific Google Drive URL or file hash has been reported in any known phishing or malware campaigns.
-
-### False positive analysis
-
-- Legitimate business operations may involve downloading files from Google Drive using automated scripts or tools like curl or wget, which could trigger the rule. Users can create exceptions for specific IP addresses or user accounts known to perform these tasks regularly.
-- Educational institutions often share large volumes of files via Google Drive for academic purposes. If these activities are flagged, users can whitelist domains or email addresses associated with the institution to prevent false positives.
-- Software developers and IT teams might use Google Drive to distribute software updates or patches. To manage these, users can exclude specific file types or known update URLs from triggering the rule.
-- Marketing teams frequently share media files and assets through Google Drive links. Users can handle these by setting up exceptions for recognized marketing team members or specific project-related URLs.
-- Collaborative projects often involve sharing documents and resources via Google Drive. Users can mitigate false positives by excluding known project-related Google Drive URLs or user accounts from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the downloaded file to determine its nature and potential impact, using sandboxing and static analysis tools.
-- Review browser and system logs to identify any other suspicious activities or downloads that may have occurred around the same time.
-- Remove the malicious file and any associated processes or registry entries from the affected system.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Update antivirus and endpoint protection solutions to ensure they can detect and block similar threats in the future.
-- Implement enhanced logging policies to capture detailed information on file downloads and process executions for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Educate users on the risks of downloading files from untrusted sources and the importance of verifying URLs before clicking.
-- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further assistance."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
index 4558c62759b..7e90f0a3dc5 100644
--- a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
+++ b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -56,49 +56,6 @@ sequence by process.entity_id with maxspan=1m
    )
   ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Non-Standard Port SSH connection
-
-SSH is a protocol used for secure remote access and data transfer. Adversaries may exploit non-standard ports to evade detection and bypass network filters. The detection rule identifies unusual SSH activity by monitoring processes and network connections on ports other than the default 22, excluding common legitimate uses, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the process.entity_id and the specific non-standard port being used for the SSH connection.
-- Verify the process name and parent process name to ensure it is not part of a legitimate application or service, as listed in the exclusion list (e.g., "rsync", "git").
-- Check the destination IP address to determine if it falls outside the excluded IP ranges and assess if it is a known or trusted entity.
-- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` to obtain details like the command line, user, and start time.
-- Investigate the network activity associated with the process by examining logs or using network monitoring tools to identify any unusual patterns or data transfers.
-- Correlate the process start time with user login events to determine if the SSH connection aligns with expected user activity.
-- Analyze historical data to see if the same non-standard port has been used previously and if it correlates with any known malicious activity.
-- Check for any recent changes in the system configuration or firewall rules that might explain the use of a non-standard port for SSH.
-- Investigate any related alerts or incidents that might provide additional context or indicate a broader attack campaign.
-- Consult threat intelligence sources to see if the destination IP or non-standard port is associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Legitimate applications or services that use SSH on non-standard ports for operational purposes, such as custom backup solutions or internal tools, may trigger false positives. Users should identify these applications and add them to the exclusion list in the detection rule.
-- Development environments or testing scenarios where SSH is configured to use non-standard ports for convenience or isolation can also result in false positives. Users can manage these by documenting and excluding these specific environments from the rule.
-- Automated scripts or deployment tools that utilize SSH on non-standard ports for configuration management or software deployment might be flagged. Users should ensure these tools are recognized and excluded by adding their parent process names to the exception list.
-- In some network architectures, non-standard ports might be used for SSH to avoid conflicts or due to specific firewall configurations. Users should review their network policies and adjust the detection rule to accommodate these legitimate configurations.
-- Users can handle false positives by regularly reviewing the logs and identifying patterns of benign activity, then updating the rule to exclude these patterns while ensuring that security is not compromised.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the process and network logs to identify the source and scope of the unauthorized SSH connection.
-- Verify the integrity of critical system files and configurations to ensure no unauthorized changes have been made.
-- Change all credentials associated with the compromised system and any other systems that may have been accessed using the same credentials.
-- Apply patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Implement network segmentation to limit the ability of adversaries to move laterally within the network.
-- Enhance logging policies to include detailed SSH connection attempts and process execution logs for better future detection.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the system from a known good backup if any unauthorized changes or malware are detected.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
index c00bdf87d7e..3a940510079 100644
--- a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
+++ b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/28"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ process where event.type in ("start", "process_started", "info") and
                    "--remote-debugging-pipe=*") and
    process.args : "--user-data-dir=*" and not process.args:"--remote-debugging-port=0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Cookies Theft via Browser Debugging
-
-Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate attempts to hijack cookies, by monitoring specific process names and arguments indicative of debugging activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious process arguments, specifically checking for `--remote-debugging-port=*`, `--remote-debugging-targets=*`, and `--remote-debugging-pipe=*` in conjunction with `--user-data-dir=*`.
-- Verify the process name involved in the alert to ensure it matches one of the targeted Chromium-based browsers such as "chrome.exe", "Google Chrome", "msedge.exe", or "Microsoft Edge".
-- Check the process start time and correlate it with user activity logs to determine if the browser was launched during normal working hours or if it coincides with unusual activity.
-- Investigate the user account associated with the process to determine if the account has a history of legitimate debugging activities or if it is potentially compromised.
-- Use Osquery to gather additional context about the process by running a query like: `SELECT pid, name, path, cmdline FROM processes WHERE name IN ('chrome.exe', 'msedge.exe') AND cmdline LIKE '%--remote-debugging-port=%';` to identify the full command line and path of the suspicious process.
-- Examine network logs to identify any unusual outbound connections from the host that may indicate data exfiltration or communication with a command and control server.
-- Review browser history and cache files for any evidence of unauthorized access to sensitive web applications or services.
-- Check for any recent changes to browser extensions or plugins that could have been used to facilitate cookie theft.
-- Analyze system logs for any other suspicious activities or anomalies around the time the alert was triggered, such as unexpected file modifications or new user accounts.
-- Consult with the user or system owner to verify if they were conducting legitimate debugging activities and gather any additional context that may explain the alert.
-
-### False positive analysis
-
-- Developers and IT professionals often use debugging features in Chromium-based browsers for legitimate purposes, such as testing and troubleshooting web applications, which can trigger this detection rule.
-- Automated testing frameworks and tools that rely on browser automation may use debugging arguments to control browser instances, leading to false positives.
-- Users can manage these false positives by creating exceptions for known and trusted processes or users who regularly engage in legitimate debugging activities.
-- Implementing a whitelist of IP addresses or user accounts associated with development and testing environments can help reduce false positives.
-- Regularly review and update the list of exceptions to ensure that only authorized debugging activities are excluded from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Investigate the process logs to confirm the presence of suspicious debugging arguments and identify any unauthorized access to session cookies.
-- Terminate any suspicious browser processes that are running with debugging arguments to stop potential cookie theft.
-- Change passwords and invalidate session tokens for any accounts that may have been compromised to prevent unauthorized access.
-- Escalate the incident to the security operations team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and network connections.
-- Integrate security tools with SIEM systems to automate the detection of suspicious debugging activities and alert security teams in real-time.
-- Restore the system to its operational state by applying security patches, updating software, and ensuring all security configurations are correctly set.
-- Conduct a security review to identify and address any vulnerabilities that allowed the attack, such as weak browser configurations or insufficient monitoring.
-- Educate users on the risks of session hijacking and the importance of secure browsing practices to reduce the likelihood of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/credential_access_forced_authentication_pipes.toml b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
index e65ec69b629..db0ec420cba 100644
--- a/rules/cross-platform/credential_access_forced_authentication_pipes.toml
+++ b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/23"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/01"
 
 [rule]
 author = ["Elastic"]
@@ -60,48 +60,6 @@ sequence with maxspan=15s
 [network where host.os.type == "linux" and event.action == "connection_attempted" and destination.port == 445 and not startswith~(string(destination.ip), string(host.ip))] by host.ip, data_stream.namespace
 [file where host.os.type == "windows" and event.code == "5145" and file.name : ("Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc")] by source.ip, data_stream.namespace
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Active Directory Forced Authentication from Linux Host - SMB Named Pipes
-
-Active Directory (AD) and SMB named pipes facilitate communication and resource sharing in networks. Adversaries exploit these by forcing authentication from a Linux host to capture credentials or perform relay attacks. The detection rule identifies suspicious connection attempts to SMB ports from Linux hosts and monitors specific named pipes on Windows, indicating potential forced authentication attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the source and destination IP addresses involved in the suspicious connection attempt, focusing on the `host.ip` and `destination.ip` fields.
-- Verify the Linux host's activity by checking recent network logs for any unusual or unauthorized connection attempts to SMB port 445, using the `event.action` and `destination.port` fields.
-- Cross-reference the `source.ip` from the Windows event logs with known IP addresses to determine if the connection originated from a trusted or suspicious source.
-- Investigate the specific named pipes accessed on the Windows host by examining the `file.name` field in the event logs to identify any unusual or unauthorized access attempts.
-- Use Osquery to gather additional context on the Linux host by running a query to list all active network connections: `SELECT * FROM process_open_sockets WHERE remote_port = 445;`
-- Check for any recent changes or anomalies in the Linux host's configuration or installed software that could indicate compromise or unauthorized access.
-- Analyze the Windows event logs for any other related events around the same timestamp as the alert to identify potential patterns or additional suspicious activity.
-- Investigate the user accounts involved in the connection attempt by reviewing authentication logs on both the Linux and Windows hosts to identify any unauthorized access attempts.
-- Correlate the alert with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to gather additional context and evidence.
-- Document all findings and observations during the investigation to build a comprehensive understanding of the incident and support further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Routine administrative tasks: Linux hosts performing legitimate administrative tasks on Windows servers may trigger the rule. These tasks often involve connecting to SMB ports for file sharing or management purposes. Users can manage this by creating exceptions for known administrative IP addresses or specific time windows when these tasks are scheduled.
-- Backup operations: Automated backup processes from Linux systems to Windows servers might generate connection attempts to SMB ports. To handle this, users can exclude IP addresses of backup servers or specific data streams associated with backup operations.
-- Monitoring and security tools: Security or monitoring tools running on Linux hosts may attempt to connect to Windows systems for log collection or system checks, leading to false positives. Users should identify and whitelist these tools by their IP addresses or data stream namespaces.
-- Development and testing environments: In environments where Linux hosts are used for testing or development, frequent connections to Windows systems might occur as part of normal operations. Users can exclude these environments by defining exceptions for specific subnets or hostnames associated with development and testing activities.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or credential capture.
-- Conduct a thorough investigation of the Linux host to identify any malicious scripts or tools used for forced authentication attempts.
-- Review and analyze logs from both the Linux and Windows systems to trace the source and scope of the attack, focusing on the specific named pipes and network connections involved.
-- Change passwords for any accounts that may have been exposed or compromised during the attack to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed authentication events and network traffic, ensuring that future suspicious activities are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Restore the affected systems to their operational state by removing any malicious software and applying necessary security patches and updates.
-- Harden the security posture of the network by disabling unnecessary SMB services and enforcing strong authentication mechanisms, such as multi-factor authentication (MFA).
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans to address similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
index bee9815b398..0387b769dc3 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -31,49 +31,6 @@ type = "query"
 query = '''
 event.agent_id_status:(agent_id_mismatch or mismatch)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Agent Spoofing - Mismatched Agent ID
-
-In security environments, agent IDs are crucial for authenticating and tracking events from various sources. Adversaries may exploit this by spoofing agent IDs to disguise malicious activities as legitimate, thereby evading detection. The detection rule identifies discrepancies between expected and actual agent IDs, signaling potential spoofing attempts and helping analysts pinpoint suspicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the specific event and agent IDs involved in the mismatch.
-- Verify the legitimacy of the API key associated with the expected agent ID to ensure it hasn't been compromised or misused.
-- Cross-reference the actual agent ID with known legitimate agents in your environment to determine if it is recognized or expected.
-- Analyze the event logs surrounding the alert for any unusual or suspicious activities that might indicate malicious intent.
-- Use Osquery to gather additional information about the system associated with the actual agent ID. Example query: `SELECT * FROM osquery_info WHERE uuid = '<actual_agent_id>';`
-- Check for any recent changes or updates in the system configurations or software that might explain the agent ID mismatch.
-- Investigate the network traffic from the source IP address associated with the actual agent ID to identify any anomalies or unauthorized access attempts.
-- Correlate the alert with other security events or alerts to identify patterns or related incidents that might indicate a broader attack.
-- Consult with system administrators or relevant personnel to verify if there have been any legitimate changes or deployments that could account for the mismatch.
-- Document all findings and observations during the investigation to maintain a comprehensive record for future reference and analysis.
-
-### False positive analysis
-
-- Legitimate software updates or configuration changes can cause agent ID mismatches if the agent ID is regenerated or altered during the process. Users should verify if recent updates or changes align with the timing of the mismatched events.
-- Network issues or temporary disconnections might lead to agent ID mismatches when agents reconnect with a new ID. Users can monitor network stability and correlate with the timing of mismatches to identify such cases.
-- Virtual machine snapshots or clones can result in agent ID mismatches if the agent ID is not updated or synchronized properly. Users should ensure that virtual environments are configured to handle agent ID updates correctly.
-- Testing environments where agent IDs are frequently changed or reused can trigger false positives. Users can create exceptions for known testing environments to prevent unnecessary alerts.
-- In environments with shared API keys, mismatches may occur if multiple agents use the same key but have different IDs. Users should consider assigning unique API keys to each agent to reduce the likelihood of mismatches.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further malicious activity and contain the threat.
-- Verify the legitimacy of the agent ID by cross-referencing with known good configurations and records.
-- Conduct a thorough investigation to identify the source and scope of the spoofing attempt, utilizing logs and network traffic analysis.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
-- Revoke and reissue API keys associated with the compromised agent IDs to prevent unauthorized access.
-- Implement enhanced logging policies to capture detailed information on agent ID usage and anomalies for future investigations.
-- Integrate threat intelligence feeds to correlate detected spoofing attempts with known threat actor tactics and techniques.
-- Restore affected systems by reimaging or applying clean backups, ensuring all malicious artifacts are removed.
-- Apply system hardening measures, such as enforcing strict authentication mechanisms and regular agent ID audits.
-- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
index 3e0f053382b..0a5ee5c15a7 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/14"
 
 [rule]
 author = ["Elastic"]
@@ -31,49 +31,6 @@ type = "threshold"
 query = '''
 event.agent_id_status:* and not tags:forwarded
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Agent Spoofing - Multiple Hosts Using Same Agent
-
-In network environments, agents are deployed on hosts to monitor and report activities. Each agent has a unique ID to ensure accurate tracking. Adversaries may exploit this by using a single agent ID across multiple hosts to inject false data, masking their actions. The detection rule identifies such anomalies by flagging instances where the same agent ID appears on different hosts, indicating potential spoofing attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific agent ID that has been flagged for appearing on multiple hosts.
-- Cross-reference the `event.agent_id_status` field in the alert to determine the status and any additional context provided by the event.
-- Check the network logs to identify all hosts associated with the flagged agent ID and note any unusual patterns or discrepancies in their activities.
-- Use Osquery to gather more information about the hosts involved. For example, run the following query to list all processes associated with the agent ID on each host: `SELECT pid, name, path FROM processes WHERE name = 'agent_name';`
-- Investigate the timeline of events to determine when the agent ID first appeared on each host and identify any correlating events or changes in the network environment.
-- Examine the `tags` field in the alert to ensure that the events are not legitimate forwarded events, which could explain the presence of the same agent ID on multiple hosts.
-- Analyze the configuration and deployment logs of the agent to check for any unauthorized changes or anomalies that could indicate tampering.
-- Review user access logs and permissions to identify any unauthorized access or privilege escalation that might have facilitated the spoofing.
-- Correlate the findings with other security alerts or incidents to identify any patterns or connections that could indicate a broader attack campaign.
-- Document all findings and observations to build a comprehensive understanding of the incident, which will aid in further investigation and eventual remediation.
-
-### False positive analysis
-
-- Legitimate load balancing or failover scenarios where an agent ID is intentionally used across multiple hosts for redundancy can trigger false positives. Users can handle this by creating exceptions for known load-balanced systems.
-- Virtualized environments where snapshots or clones of a host are created might result in the same agent ID appearing on multiple hosts. Users should identify and exclude these virtualized instances from the rule.
-- During system migrations or upgrades, an agent ID might temporarily appear on multiple hosts. Users can manage this by setting temporary exceptions during the migration period.
-- In environments with shared or pooled resources, such as VDI (Virtual Desktop Infrastructure), the same agent ID might be used across different sessions. Users should configure the rule to recognize and exclude these shared resource scenarios.
-- Testing or development environments where agents are duplicated for testing purposes can also lead to false positives. Users should ensure these environments are excluded from the rule or tagged appropriately to prevent alerts.
-
-### Response and remediation
-
-- Immediately isolate affected hosts to prevent further spread of the spoofed agent ID across the network.
-- Conduct a thorough investigation to identify all hosts using the compromised agent ID and assess the scope of the intrusion.
-- Validate the integrity of the agent software on affected hosts and reinstall or update agents as necessary to ensure they are not compromised.
-- Review and analyze logs to identify any unauthorized activities or data injections associated with the spoofed agent ID.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement stricter access controls and authentication mechanisms for agent deployment and management to prevent unauthorized use.
-- Enhance logging policies to capture detailed agent activity and host interactions for improved monitoring and future investigations.
-- Integrate threat intelligence feeds to correlate detected spoofing attempts with known adversary tactics, techniques, and procedures (TTPs).
-- Restore affected systems to their operational state by applying necessary patches, updates, and configuration changes.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as network segmentation and endpoint protection, to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
index 4b95989382a..27c9ce51e5b 100644
--- a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
+++ b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,50 +49,6 @@ file where event.type == "deletion" and
                "/var/log/httpd/access_log",
                "/var/www/*/logs/access.log")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WebServer Access Logs Deleted
-
-Web server access logs are crucial for monitoring and analyzing web traffic, providing insights into user activity and potential security incidents. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies log deletions across common web server paths, signaling potential attempts at evasion or evidence destruction, thus alerting analysts to investigate further.
-
-### Possible investigation steps
-
-- Verify the alert by checking the specific file paths mentioned in the query to confirm if the deletion event is legitimate and not a false positive.
-- Review recent access logs, if available, to identify any suspicious activity or patterns leading up to the deletion event.
-- Use Osquery to list all recent file modifications in the web server directories to identify any unauthorized changes. Example query: `SELECT * FROM file WHERE path LIKE '/var/log/apache%/access.log' OR path LIKE '/etc/httpd/logs/access_log' OR path LIKE '/var/log/httpd/access_log' OR path LIKE '/var/www/%/logs/access.log';`
-- Check for any recent user account activity or privilege escalations that could indicate unauthorized access to the server.
-- Investigate any recent changes in user permissions or roles that might have allowed the deletion of log files.
-- Correlate the deletion event with other security alerts or logs from the same timeframe to identify potential related incidents.
-- Examine system logs for any signs of tampering or anomalies that could suggest an attempt to cover tracks.
-- Review network traffic logs for unusual outbound connections or data exfiltration attempts around the time of the log deletion.
-- Check for any scheduled tasks or scripts that might have been used to automate the deletion of log files.
-- Consult with the web server administrator to determine if there were any legitimate maintenance activities or updates that could have resulted in the log deletion.
-
-### False positive analysis
-
-- Routine maintenance tasks or automated scripts may delete old web server access logs to free up disk space, which can trigger false positives. 
-- Log rotation processes, which are standard in many server environments, might also result in log deletions that are benign and expected.
-- Scheduled cleanup jobs configured by system administrators to manage log file sizes can lead to false alerts.
-- To manage these false positives, users can create exceptions for known maintenance scripts or log rotation processes by excluding specific file paths or event sources from the detection rule.
-- Implementing a whitelist of trusted processes or users responsible for legitimate log deletions can help reduce unnecessary alerts.
-- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity to go undetected.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the log deletion, identifying any other compromised systems or services.
-- Review recent user activity and access logs from other sources to identify potential unauthorized access or malicious behavior.
-- Restore deleted logs from backups if available, and analyze them for any indicators of compromise or suspicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement stricter access controls and permissions on log files to prevent unauthorized deletion or modification.
-- Enhance logging policies by ensuring logs are sent to a centralized, secure logging server that is less susceptible to tampering.
-- Integrate additional security tools such as file integrity monitoring and endpoint detection and response (EDR) solutions to detect and alert on suspicious activities.
-- Apply system and application patches to address any vulnerabilities that may have been exploited by the adversary.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
index 0852d7d7344..d741251924d 100644
--- a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
+++ b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -54,49 +54,6 @@ process where event.action in ("exec", "exec_event", "executed", "process_starte
   (process.args : "set" and process.args : "history" and process.args : "+o")
  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Tampering of Shell Command-Line History
-
-Shell command-line history is a crucial feature that logs user commands, aiding in troubleshooting and audits. Adversaries may manipulate this history to hide their tracks, using commands to delete or redirect history files, or alter environment variables to disable logging. The detection rule identifies such tampering by monitoring for suspicious command patterns and arguments indicative of history manipulation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and user involved in the tampering attempt, focusing on the `process.args` and `process.user` fields.
-- Check the process execution timeline to determine if there are any preceding or subsequent suspicious activities, using the `event.action` and `event.type` fields.
-- Investigate the command history of the user associated with the alert to identify any other potentially malicious commands executed around the same time.
-- Use Osquery to list all recent modifications to shell history files. Example query: `SELECT path, size, mtime FROM file WHERE path LIKE '/home/%/.bash_history' OR path LIKE '/root/.bash_history';`
-- Examine the system logs for any anomalies or errors that coincide with the time of the alert, which might indicate tampering or other malicious activities.
-- Verify the integrity of the shell history files by comparing them with backups or snapshots, if available, to identify any unauthorized changes.
-- Investigate any changes to environment variables related to shell history, such as `HISTFILE` and `HISTFILESIZE`, by reviewing the user's shell configuration files (e.g., `.bashrc`, `.bash_profile`).
-- Check for the presence of symbolic links or redirections of history files to `/dev/null` using the `ln` command, as indicated in the alert.
-- Analyze the system for any other indicators of compromise or persistence mechanisms that might suggest a broader attack campaign.
-- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or threat actor behaviors.
-
-### False positive analysis
-
-- System administrators or developers may intentionally clear command-line history for privacy or security reasons, leading to false positives. To manage this, users can create exceptions for specific user accounts or roles known to perform these actions regularly.
-- Automated scripts or maintenance tasks might include commands that manipulate shell history as part of their normal operation. Users can handle these by excluding processes or scripts with known benign behavior from triggering alerts.
-- Some security tools or compliance checks may execute commands that resemble history tampering to verify system configurations. Users should identify these tools and add them to an allowlist to prevent false positives.
-- Developers working in shared environments might redirect history files to avoid conflicts, which could be mistaken for tampering. Users can exclude specific directories or environments where this practice is common.
-- In environments where disk space is a concern, users might truncate history files to save space, which could trigger alerts. Users can set exceptions for these actions when performed by authorized personnel or scripts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further tampering or data exfiltration.
-- Conduct a thorough investigation to identify the scope of the tampering, including reviewing logs and correlating with other security events.
-- Restore the shell command-line history from backups if available, to aid in understanding the adversary's actions.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed command-line activity, ensuring that logs are stored securely and are tamper-proof.
-- Integrate with a centralized logging solution or SIEM to aggregate and analyze shell command-line history across the organization.
-- Review and update security policies to include regular audits of shell history files and environment variables related to command logging.
-- Apply system hardening measures, such as restricting access to history files and enforcing the use of secure shell configurations.
-- Educate users on the importance of shell history for security and encourage reporting of any suspicious activity.
-- Leverage MITRE ATT&CK framework to understand potential adversary techniques and improve detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
index a51d23d6c42..655695f3cae 100644
--- a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
+++ b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -61,49 +61,6 @@ or
     process.args : "com.apple.iokit.EndpointSecurity" and
     event.action : "end"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Elastic Agent Service Terminated
-
-The Elastic Agent is a critical component for monitoring and securing systems across various environments, including Windows, Linux, and MacOS. It collects and sends data to the Elastic Stack for analysis. Adversaries may attempt to stop or disable this service to evade detection, impairing defense mechanisms. The detection rule identifies suspicious processes and commands that attempt to terminate or disable the Elastic Agent, signaling potential malicious activity. By monitoring these actions, security analysts can quickly respond to threats and ensure continuous protection.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on the `process.name` and `process.args` fields.
-- Check the event type (`event.type`) to determine if the process was starting or ending, which can provide context on whether the service was being stopped or disabled.
-- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised.
-- Examine the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the Elastic Agent service was terminated.
-- Use Osquery to gather additional context on the host. For example, run the following query to check for recent process executions: `SELECT * FROM processes WHERE name IN ('net.exe', 'sc.exe', 'wmic.exe', 'powershell.exe', 'taskkill.exe', 'PsKill.exe', 'ProcessHacker.exe');`
-- Verify the integrity and configuration of the Elastic Agent on the affected host to ensure it has not been tampered with or misconfigured.
-- Cross-reference the alert with any recent changes or updates to the system that might have inadvertently caused the service to stop.
-- Check for any network connections or communications from the host that might indicate data exfiltration or command-and-control activity.
-- Review any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or correlations with other malicious activities.
-- Consult threat intelligence sources to determine if there are any known campaigns or adversaries that use similar tactics to disable security services.
-
-### False positive analysis
-
-- Routine maintenance or updates: Scheduled system maintenance or software updates may involve stopping services, including the Elastic Agent, leading to false positives. To manage this, create exceptions for known maintenance windows or update processes.
-- System administrators' actions: Legitimate actions by system administrators, such as troubleshooting or reconfiguring systems, might trigger the rule. To handle this, whitelist specific administrator accounts or processes that are known to perform these actions regularly.
-- Automated scripts: Some automated scripts or deployment tools may stop the Elastic Agent as part of their workflow. Identify these scripts and exclude them from triggering alerts by specifying their process names or arguments in the exception list.
-- Testing environments: In testing or development environments, the Elastic Agent might be stopped frequently for testing purposes. Consider excluding these environments from monitoring or creating specific rules that account for their unique behavior.
-- Non-malicious software conflicts: Certain non-malicious software might inadvertently stop the Elastic Agent due to conflicts or misconfigurations. Investigate and resolve these conflicts, and if necessary, exclude the specific software from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further spread or communication with potential threat actors.
-- Verify the termination of the Elastic Agent service by checking system logs and process status to confirm unauthorized stoppage.
-- Conduct a thorough investigation to identify any unauthorized access or changes made to the system, focusing on the processes and commands listed in the detection query.
-- Review user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
-- Re-enable and restart the Elastic Agent service to restore monitoring capabilities, ensuring it is configured to start automatically on boot.
-- Apply patches and updates to the Elastic Agent and related software to mitigate any known vulnerabilities that could be exploited.
-- Implement enhanced logging policies to capture detailed process execution and service management activities for future analysis.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team if evidence of a broader intrusion or advanced threat is detected.
-- Conduct a post-incident review to identify gaps in security controls and update hardening measures, such as disabling unnecessary services and enforcing strict access controls."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
index 26d5d0815ac..81c67c2d202 100644
--- a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
+++ b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/17"
 
 [rule]
 author = ["Elastic"]
@@ -38,54 +38,6 @@ sequence by process.entity_id with maxspan=1m
  [file where host.os.type in ("windows", "macos") and
   event.action != "deletion" and process.name : "python*" and file.name : "rot_??.cpython-*.pyc*"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 ROT Encoded Python Script Execution
-
-ROT encoding, a simple letter substitution cipher, is often used to obfuscate Python scripts, making them harder to analyze. Adversaries exploit this by embedding ROT-encoded scripts within legitimate Python packages to evade detection. The detection rule identifies such activities by monitoring the execution of Python scripts and the presence of ROT-encoded compiled files, signaling potential malicious obfuscation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process.entity_id associated with the suspicious activity to understand which process triggered the alert.
-- Examine the process.name field to confirm the execution of a Python interpreter, ensuring it matches the expected pattern "python*".
-- Investigate the file.name field to identify the presence of ROT-encoded compiled files, specifically looking for patterns like "rot_??.cpython-*.pyc*".
-- Check the event timestamps to determine the sequence and timing of the process start and file creation events, ensuring they fall within the maxspan=1m window.
-- Use Osquery to list all Python processes running on the host to identify any other potentially suspicious Python scripts:
-  ```sql
-  SELECT pid, name, path FROM processes WHERE name LIKE 'python%';
-  ```
-- Query the file system using Osquery to locate all files matching the ROT-encoded pattern to identify other potentially obfuscated scripts:
-  ```sql
-  SELECT path FROM file WHERE path LIKE '%rot_??.cpython-*.pyc%';
-  ```
-- Analyze the parent process of the suspicious Python execution to determine if it was launched by a legitimate application or a potentially malicious one.
-- Review the command-line arguments of the Python process to identify any additional scripts or modules being executed that may not be ROT-encoded but are still suspicious.
-- Investigate the user account associated with the process execution to determine if the activity aligns with expected behavior for that user.
-- Cross-reference the host.os.type field to ensure the investigation is tailored to the specific operating system, considering differences in file paths and process management between Windows and macOS.
-
-### False positive analysis
-
-- Legitimate software development activities: Developers may use ROT encoding during the development process for testing or educational purposes, leading to false positives. Users can manage this by creating exceptions for known development environments or specific developer machines.
-- Security research and educational tools: Security researchers and educators might use ROT encoding to demonstrate obfuscation techniques, which could trigger the detection rule. To handle this, users can whitelist specific research tools or educational scripts that are known to be non-malicious.
-- Automated code analysis tools: Some automated tools might use ROT encoding as part of their analysis or transformation processes, resulting in false positives. Users should identify and exclude these tools from the detection rule to prevent unnecessary alerts.
-- Custom scripts with ROT encoding: Organizations might have internal scripts that use ROT encoding for legitimate purposes, such as data transformation or encoding. Users should document these scripts and exclude them from the detection rule to avoid false alarms.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potentially malicious activity.
-- Conduct a thorough investigation to identify the source and scope of the ROT-encoded script execution, focusing on recent installations or updates of Python packages.
-- Analyze the ROT-encoded scripts to determine their functionality and potential impact, using deobfuscation techniques if necessary.
-- Remove any identified malicious scripts or packages from the system and ensure they are not present in any other systems within the network.
-- Restore the system from a known good backup prior to the execution of the ROT-encoded script to ensure no residual malicious code remains.
-- Implement enhanced logging policies to capture detailed execution logs of Python scripts, including command-line arguments and script contents.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of obfuscation techniques like ROT encoding.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Educate users and developers on the risks of using obfuscated code and the importance of verifying the integrity of third-party packages.
-- Apply system hardening measures, such as restricting the execution of scripts from untrusted sources and enforcing strict access controls on sensitive systems."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
index c28faa0283d..4b46332364f 100644
--- a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
+++ b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -52,49 +52,6 @@ process.executable regex~ """/[a-z0-9\s_\-\\./]+\s""" and not (
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Masquerading Space After Filename
-
-In Linux and macOS environments, appending a space to a filename can trick the OS into executing a file based on its true type rather than its extension. Adversaries exploit this by disguising malicious files with benign extensions, adding a space to ensure execution. The detection rule identifies such anomalies by monitoring process creation events, filtering out known benign processes, and flagging suspicious executable patterns.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process executable path that triggered the rule, focusing on the presence of a space at the end of the filename.
-- Verify the legitimacy of the process by checking the process name and executable path against known benign processes and paths listed in the query's exceptions.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT pid, name, path, cmdline, cwd, uid, gid, start_time FROM processes WHERE path LIKE '% ' AND path = '<triggered_executable_path>';` to retrieve detailed information about the suspicious process.
-- Investigate the parent process of the suspicious executable to understand the process hierarchy and determine if the parent process is known or expected.
-- Check the file metadata of the suspicious executable, including creation and modification times, to identify any anomalies or recent changes that could indicate tampering.
-- Examine the file type of the executable using the `file` command to confirm if the actual file type matches the expected type based on the file extension.
-- Search for any network connections or communications initiated by the suspicious process to identify potential command and control activity or data exfiltration.
-- Review system logs and other security tools for any additional indicators of compromise or related suspicious activity around the time the process was executed.
-- Investigate the user account associated with the process execution to determine if the account has been compromised or is exhibiting unusual behavior.
-- Correlate the findings with threat intelligence sources to check for known indicators of compromise or patterns associated with the detected behavior.
-
-### False positive analysis
-
-- Known false positives for the Masquerading Space After Filename rule include legitimate processes that may have a space appended to their filenames due to user error or specific application behavior. These can include scripts or executables that are mistakenly renamed with a trailing space.
-- Users can manage these false positives by creating exceptions for known benign processes. This can be done by adding specific process names or executable paths to the exclusion list within the detection rule.
-- For instance, if a legitimate script in a custom directory frequently triggers the rule, users can modify the rule to exclude that specific path or process name.
-- It's important to regularly review and update the exclusion list to ensure that new legitimate processes are not mistakenly flagged, while still maintaining the integrity of the detection for potential threats.
-- Users should also consider the context of the flagged process, such as its parent process and command-line arguments, to determine if it aligns with expected behavior or if it warrants further investigation.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to identify the source and scope of the masquerading file, examining logs and process creation events.
-- Terminate any suspicious processes identified as being executed with a space after the filename to halt any ongoing malicious activity.
-- Remove or quarantine the identified malicious files from the system to prevent re-execution.
-- Review and update endpoint protection and antivirus signatures to detect similar threats in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process creation events and file modifications for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar masquerading techniques.
-- Restore the system from a known good backup to ensure the integrity and security of the operating environment.
-- Apply system hardening measures, such as restricting file execution permissions and educating users on recognizing suspicious file behaviors, to reduce the risk of future attacks."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_timestomp_touch.toml b/rules/cross-platform/defense_evasion_timestomp_touch.toml
index aeea69f9e48..36d4a8ca911 100644
--- a/rules/cross-platform/defense_evasion_timestomp_touch.toml
+++ b/rules/cross-platform/defense_evasion_timestomp_touch.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -46,48 +46,6 @@ process where event.type == "start" and
    "/usr/lib/go-*/bin/go", "/usr/lib/dracut/dracut-functions.sh", "/tmp/KSInstallAction.*/m/.patch/*"
 ) and not process.parent.name in ("pmlogger_daily", "pmlogger_janitor", "systemd")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Timestomping using Touch Command
-
-Timestomping involves altering file timestamps to evade detection, often using the 'touch' command in Unix-like systems. Adversaries exploit this to blend malicious files with legitimate ones by mimicking their timestamps. The detection rule identifies suspicious 'touch' command executions by non-root users, focusing on specific arguments that modify access and modification times, while excluding benign processes and known legitimate paths.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'touch' command execution by a non-root user, focusing on the specific arguments used, such as "-r", "-t", "-a", and "-m".
-- Identify the user account associated with the alert by examining the 'user.id' field to determine if the account is known or potentially compromised.
-- Investigate the parent process of the 'touch' command using the 'process.parent.name' field to understand the context in which the command was executed and check for any unusual or suspicious parent processes.
-- Cross-reference the file paths involved in the 'touch' command with known legitimate paths to ensure they are not part of the excluded paths, such as "/usr/lib/go-*/bin/go" or "/tmp/KSInstallAction.*/m/.patch/*".
-- Use Osquery to list recent file modifications in the directory where the 'touch' command was executed. Example query: `SELECT path, atime, mtime, ctime FROM file WHERE directory = '/path/to/suspicious/directory' ORDER BY mtime DESC LIMIT 10;`
-- Check system logs for any other suspicious activities or anomalies around the time of the 'touch' command execution to identify potential related events.
-- Analyze the command history of the user account involved to determine if there are any other suspicious commands executed around the same time.
-- Investigate any network connections or external communications initiated by the user account or the system around the time of the alert to identify potential data exfiltration or command-and-control activities.
-- Review any recent changes to user permissions or group memberships that might have allowed the execution of the 'touch' command by a non-root user.
-- Correlate the alert with other security events or alerts in the environment to identify if this is part of a larger attack campaign or isolated incident.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate administrative scripts or maintenance tasks that use the 'touch' command with timestamp modification arguments. These scripts might be scheduled to run regularly and are not indicative of malicious activity.
-- Developers and system administrators might use the 'touch' command with specific arguments during software development or system configuration processes, which can trigger the detection rule.
-- To manage these false positives, users can create exceptions for specific scripts or processes by adding them to the exclusion list in the detection rule. This can be done by identifying the benign processes and paths that frequently trigger the rule and updating the exclusion criteria accordingly.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify all files and processes that have been timestomped, using forensic tools to analyze file metadata and system logs.
-- Review user activity logs to determine if the non-root user executing the 'touch' command was authorized and if their account has been compromised.
-- Restore affected files from a known good backup to ensure integrity and correct timestamps, and verify the system's operational state.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed command execution and file modification events, ensuring that future timestomping attempts are detected promptly.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and correlate alerts with known threat actors.
-- Apply system hardening measures, such as restricting the use of the 'touch' command to authorized users only and implementing strict access controls.
-- Educate users on security best practices and the risks associated with unauthorized command execution to prevent future incidents.
-- Review and update incident response plans to incorporate lessons learned from the investigation and ensure readiness for similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
index c5c9653f16f..2ef727a4d0a 100644
--- a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
+++ b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -51,49 +51,6 @@ process where event.type == "start" and
  process.args : ("parallels*", "vmware*", "virtualbox*") and process.args : "Manufacturer*" and
  not process.parent.executable in ("/Applications/Docker.app/Contents/MacOS/Docker", "/usr/libexec/kcare/virt-what")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Virtual Machine Fingerprinting via Grep
-
-Virtual machine fingerprinting involves identifying virtualized environments by querying system details. Adversaries exploit tools like `grep` to extract information about virtual machine hardware, aiding in evasion or targeted attacks. The detection rule identifies non-root users executing `grep` with arguments related to virtual machine identifiers, flagging potential reconnaissance activities while excluding benign processes like Docker.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is either "grep" or "egrep" and verify the user ID is not "0" to ensure the alert is triggered by a non-root user.
-- Examine the specific arguments used with the grep command to identify if they include terms like "parallels*", "vmware*", "virtualbox*", or "Manufacturer*". This helps determine if the command was likely used for virtual machine fingerprinting.
-- Check the parent process of the grep command to ensure it is not a benign process such as Docker or kcare/virt-what, as these are excluded in the detection rule.
-- Investigate the user account associated with the alert to determine if the account has a history of suspicious activity or if it is a legitimate user who might have a valid reason for running such commands.
-- Use Osquery to gather more context about the system and user activity. For example, run the following Osquery query to list recent processes executed by the user: `SELECT * FROM processes WHERE uid = '<user_id>' ORDER BY start_time DESC LIMIT 10;`.
-- Analyze system logs to identify any other unusual activities or patterns that coincide with the time of the alert, such as failed login attempts or other reconnaissance commands.
-- Check for any recent changes in the system environment or configurations that might explain the use of virtual machine-related grep commands.
-- Review network logs to identify any outbound connections that might suggest data exfiltration or communication with a command and control server.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack campaign.
-- Consult threat intelligence sources to see if there are any known campaigns or malware that use similar techniques, such as the Pupy RAT, to understand the potential threat actor's tactics and objectives.
-
-### False positive analysis
-
-- Non-root users running legitimate scripts or applications that query virtual machine identifiers for maintenance or monitoring purposes may trigger false positives. 
-- Developers or IT personnel using `grep` to check virtual machine configurations during routine checks or system audits can be mistakenly flagged.
-- Automated scripts or tools that include virtual machine identifier checks as part of their functionality, such as inventory management or compliance tools, might be incorrectly identified as threats.
-- To manage these false positives, users can create exceptions for known benign processes by adding them to the exclusion list in the detection rule, ensuring that routine operations are not disrupted.
-- Regularly review and update the exclusion list to accommodate new legitimate processes that may arise, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the intrusion, focusing on identifying any additional compromised systems or accounts.
-- Review system logs and security alerts to gather information on the adversary's activities and potential entry points.
-- Remove any unauthorized software or malware identified during the investigation, ensuring that all malicious processes are terminated.
-- Change all passwords and credentials associated with the affected system and any potentially compromised accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging and monitoring policies to capture detailed information on system and network activities, aiding in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context on similar threats.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly updating security configurations to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
index bc2a628fb03..ee87869d33c 100644
--- a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
+++ b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/03"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -86,53 +86,6 @@ and process.args: (
     and ("AWS-RunShellScript" or "AWS-RunPowerShellScript")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS SSM `SendCommand` with Run Shell Command Parameters
-
-AWS Systems Manager (SSM) `SendCommand` allows remote command execution on EC2 instances, bypassing traditional access methods like SSH. Adversaries exploit this to execute unauthorized commands, potentially leading to data breaches or system compromise. The detection rule identifies unusual `SendCommand` usage, flagging first-time occurrences of shell script execution on hosts, which may indicate malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific EC2 instance and the time when the `SendCommand` was executed. Pay attention to the `process.args` field to understand the exact command and parameters used.
-- Verify the identity of the user or role that initiated the `SendCommand` by examining the AWS CloudTrail logs. Look for the `userIdentity` field to determine if the action was performed by an expected user or service.
-- Check the AWS CloudTrail logs for any other unusual activities around the same time, such as changes in IAM policies or unusual API calls, which might indicate a broader attack.
-- Investigate the EC2 instance's recent activity by reviewing its system logs. Look for any unexpected processes or network connections that could suggest malicious behavior.
-- Use Osquery to gather more information about the processes running on the affected EC2 instance. For example, run the following query to list all processes that have been started recently:
-  ```sql
-  SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));
-  ```
-- Examine the `host.os.type` field to determine the operating system of the affected instance and tailor your investigation steps accordingly, such as checking for specific OS-related logs or configurations.
-- Analyze the `event.category` and `event.type` fields to confirm that the event is indeed a process start event, ensuring that the alert is not a false positive.
-- Cross-reference the `process.name` field with known legitimate AWS CLI usage patterns within your organization to determine if the command execution is expected or anomalous.
-- Investigate any other alerts or incidents involving the same EC2 instance or AWS account to identify potential patterns or correlations with other suspicious activities.
-- Consult with the instance owner or relevant stakeholders to verify if the `SendCommand` execution was authorized and part of a legitimate operation, or if it requires further investigation.
-
-### False positive analysis
-
-- Routine administrative tasks: Organizations often use AWS SSM `SendCommand` with `AWS-RunShellScript` or `AWS-RunPowerShellScript` for legitimate administrative purposes, such as patch management or software installation. These activities can trigger the rule as false positives.
-- Automated scripts: Scheduled or automated scripts that perform regular maintenance or monitoring tasks on EC2 instances may also use these parameters, leading to false positives.
-- DevOps processes: Continuous integration and deployment pipelines might leverage AWS SSM `SendCommand` for deploying applications or configurations, which can be mistakenly flagged as suspicious.
-- To manage these false positives, users can create exceptions for known, non-threatening behaviors by identifying and excluding specific hosts or processes that regularly use these commands for legitimate purposes.
-- Implementing a baseline of normal activity for each host can help distinguish between expected and anomalous command executions, reducing the likelihood of false positives.
-- Regularly review and update the list of exceptions to ensure that only verified and safe activities are excluded from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized access or data exfiltration.
-- Review AWS CloudTrail logs to identify the source of the `SendCommand` API call and determine if it was authorized or if credentials were compromised.
-- Verify the integrity of the affected instance by checking for unauthorized changes or installed software, focusing on the execution of shell scripts.
-- Revoke any compromised AWS IAM credentials and rotate keys to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the incident, including identifying other potentially affected instances or services.
-- Escalate the incident to the security operations team for further analysis and to determine if additional resources are needed.
-- Implement enhanced logging and monitoring for AWS SSM and related services to detect similar activities in the future.
-- Restore the affected EC2 instance from a known good backup or AMI to ensure it is free from malicious modifications.
-- Apply security hardening measures, such as restricting SSM command execution permissions to only trusted users and roles.
-- Update security policies and provide training to relevant personnel to prevent similar incidents, leveraging MITRE ATT&CK framework insights on cloud administration command threats."""
 
 [rule.investigation_fields]
 field_names = [
diff --git a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
index 32da36c246f..f97739824da 100644
--- a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
+++ b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -30,54 +30,6 @@ type = "query"
 query = '''
 event.category:process and event.type:(process_started or start) and process.name:espl and process.args:eyJkZWJ1ZyI6*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 EggShell Backdoor Execution
-
-EggShell is a post-exploitation tool used on macOS and Linux systems, allowing adversaries to execute commands remotely, capture keystrokes, and access system data. Attackers exploit this tool to maintain persistence and control over compromised systems. The detection rule identifies suspicious process activities by monitoring specific process names and arguments, signaling potential EggShell execution, thus enabling timely threat response.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the EggShell Backdoor Execution by verifying the process name `espl` and the process arguments starting with `eyJkZWJ1ZyI6`.
-- Correlate the alert with other events in the same timeframe to identify any additional suspicious activities or related alerts.
-- Use Osquery to list all running processes and check for any instances of the `espl` process to confirm its execution:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE name = 'espl';
-  ```
-- Investigate the parent process of the `espl` process to determine how it was initiated and identify any potential initial access vectors.
-- Examine the user account associated with the `espl` process to determine if it is a legitimate user or if the account may have been compromised.
-- Check for any network connections established by the `espl` process to identify potential command and control communication:
-  ```sql
-  SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'espl');
-  ```
-- Analyze the process arguments and any encoded data within `eyJkZWJ1ZyI6` to understand the commands or payloads being executed.
-- Review system logs for any signs of privilege escalation or lateral movement attempts following the execution of the `espl` process.
-- Investigate any file modifications or new files created around the time of the alert to identify potential payloads or data exfiltration attempts.
-- Cross-reference the alert with threat intelligence sources to determine if the observed behavior matches known EggShell Backdoor campaigns or tactics.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts that use similar process names or arguments as EggShell may trigger false positives. For instance, custom scripts or applications that include 'espl' in their process name or use encoded arguments starting with 'eyJkZWJ1ZyI6' could be mistakenly flagged.
-- Developers or IT personnel testing security tools or conducting penetration tests might inadvertently execute processes that resemble EggShell activity, leading to false alerts.
-- To manage these false positives, users can create exceptions for known benign processes by whitelisting specific process names or arguments that are regularly used in their environment but are confirmed to be non-threatening.
-- Regularly review and update the list of exceptions to ensure that only verified non-malicious activities are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation to confirm the presence of the EggShell backdoor by analyzing process execution logs and correlating with known indicators of compromise.
-- Terminate any suspicious processes associated with EggShell and remove any unauthorized user accounts or credentials that may have been created.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
-- Educate users on recognizing phishing attempts and other common attack vectors to reduce the risk of future compromises.
-- Implement hardening measures such as disabling unnecessary services, enforcing strong password policies, and using multi-factor authentication to enhance overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_potential_widespread_malware_infection.toml b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
index 2cbdcfe2008..99d34658172 100644
--- a/rules/cross-platform/execution_potential_widespread_malware_infection.toml
+++ b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/08"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
 
@@ -38,48 +38,6 @@ from logs-endpoint.alerts-*
 | stats hosts = count_distinct(host.id) by rule.name, event.code
 | where hosts >= 3
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Widespread Malware Infection Across Multiple Hosts
-
-Endpoint detection technologies monitor systems for signs of malicious activity, such as malware signatures or suspicious behavior. Adversaries exploit these systems by deploying malware across multiple hosts to maximize impact. The detection rule identifies potential widespread infections by flagging when malware indicators appear on three or more hosts, enabling analysts to prioritize and respond swiftly to potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which `rule.name` and `event.code` triggered the alert, focusing on the specific malware signatures or behaviors detected.
-- Identify the affected hosts by examining the `host.id` field in the alert data to determine the scope of the potential infection.
-- Cross-reference the `host.id` with asset management systems to gather additional context about the affected hosts, such as their role, operating system, and criticality.
-- Use endpoint detection and response (EDR) tools to collect and analyze recent activity on the affected hosts, looking for unusual processes, network connections, or file modifications.
-- Execute an Osquery to gather detailed information about running processes on the affected hosts. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE host_id IN ('<affected_host_ids>');`
-- Investigate any suspicious files or processes identified in the previous step by checking their hashes against threat intelligence databases to determine if they are known malware.
-- Analyze network traffic logs for the affected hosts to identify any unusual outbound connections that may indicate command and control (C2) communication.
-- Review user activity on the affected hosts to determine if any unauthorized or unexpected user actions occurred around the time of the alert.
-- Check for any recent changes in system configurations or installed software on the affected hosts that could have introduced vulnerabilities.
-- Document all findings and gather evidence to support further analysis or escalation, ensuring that all relevant data points, such as `rule.name`, `event.code`, and `host.id`, are included for context.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger malware signatures, especially if they involve changes to system files or memory, leading to false positives. Users can manage these by creating exceptions for known update processes or trusted software vendors.
-- Security tools or system management software that perform regular scans or updates might mimic suspicious behavior, such as executing shellcode or modifying memory, which could be flagged incorrectly. To handle this, users should whitelist these tools in the detection system.
-- Custom scripts or administrative tools used for system maintenance might be misidentified as malicious if they perform actions similar to malware. Users can reduce false positives by excluding these scripts or tools from monitoring, provided they are verified as safe.
-- Testing environments or sandboxed applications that simulate malware behavior for research or development purposes can trigger alerts. Users should ensure these environments are isolated and excluded from the detection rule to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Isolate affected hosts from the network to prevent further spread of the malware and contain the infection.
-- Conduct a thorough investigation on the isolated hosts to identify the malware variant and entry point, leveraging forensic tools and endpoint detection logs.
-- Remove the identified malware from the affected systems using antivirus or specialized malware removal tools, ensuring all traces are eradicated.
-- Apply security patches and updates to all systems to close vulnerabilities exploited by the malware, focusing on those related to the MITRE ATT&CK technique T1204: User Execution.
-- Restore systems from clean backups if malware removal is unsuccessful, ensuring backups are free from infection before restoration.
-- Escalate the incident to the security operations center (SOC) or incident response team if the infection is severe or cannot be contained, providing detailed findings from the investigation.
-- Implement enhanced logging policies to capture detailed endpoint activity, including process execution and network connections, to improve future detection and analysis.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance visibility and correlation of suspicious activities across the network.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement hardening measures such as application whitelisting, user education on phishing, and least privilege access controls to reduce the risk of future infections."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
index 53a8c788c44..877e4ced8fd 100644
--- a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
+++ b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ sequence by host.id with maxspan=1m
                    "php*",
                    "wget")] by process.parent.pid
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential JAVA/JNDI Exploitation Attempt
-
-Java Naming and Directory Interface (JNDI) is a Java API that provides naming and directory functionality, allowing Java applications to discover and look up data and resources via a directory service. Adversaries can exploit JNDI by injecting malicious payloads that trigger outbound connections to attacker-controlled servers, potentially leading to remote code execution. The detection rule identifies such exploitation attempts by monitoring Java processes making outbound connections to specific ports associated with directory services, followed by the execution of suspicious child processes, which may indicate malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `process.pid` associated with the suspicious activity.
-- Examine the network logs to confirm the outbound connection attempt by the Java process to the specified ports (1389, 389, 1099, 53, 5353) and verify if the destination IP addresses are known or suspicious.
-- Check the process tree to identify the parent Java process and any child processes that were spawned, focusing on those listed in the query (e.g., "sh", "bash", "curl").
-- Use Osquery to gather additional context about the Java process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <process.pid>;` to retrieve command-line arguments and the executable path.
-- Investigate the child processes further by querying their command-line arguments and execution paths to determine if they were used to download or execute additional payloads.
-- Analyze the timing of the events to see if the suspicious child processes were executed immediately after the network connection attempt, which could indicate a successful exploitation.
-- Cross-reference the destination IP addresses with threat intelligence sources to determine if they are associated with known malicious activity or command-and-control servers.
-- Review historical logs for the same `host.id` to identify any previous similar activities or patterns that might indicate ongoing exploitation attempts.
-- Check for any other alerts or anomalies related to the same Java process or host within the same timeframe to gather more context about the potential attack.
-- If available, use endpoint detection and response (EDR) tools to perform a deeper analysis of the affected host, focusing on file modifications, registry changes, and other indicators of compromise that may have occurred around the time of the alert.
-
-### False positive analysis
-
-- Legitimate enterprise applications may use JNDI for valid purposes, such as connecting to LDAP directories for authentication or configuration management, which could trigger the rule. Users should identify and whitelist these applications by excluding their specific process names or network behaviors.
-- Automated scripts or tools that perform regular maintenance or monitoring tasks might initiate outbound connections to directory service ports and spawn child processes like shell scripts or command-line tools. Users can create exceptions for these known scripts by specifying their process hashes or command-line arguments.
-- Development environments often use JNDI for testing purposes, which may involve connections to local or remote directory services and execution of various scripts. Developers should document these activities and exclude them from the rule by defining specific hostnames or IP addresses used in the development environment.
-- Security tools or network monitoring solutions might simulate JNDI exploitation attempts as part of their testing or alerting mechanisms. Users should coordinate with their security teams to identify these tools and exclude their activities from triggering the rule by using process or network identifiers.
-- In some cases, cloud-based services or microservices architectures might use JNDI for service discovery or configuration, leading to benign outbound connections and child process executions. Users should review their cloud configurations and exclude known service patterns by specifying relevant service accounts or container IDs.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to identify the scope of the attack, including checking for other systems that may have been compromised.
-- Analyze logs and network traffic to determine the source of the malicious payload and any outbound connections to attacker-controlled servers.
-- Terminate any suspicious processes identified in the alert, particularly those involving shell or scripting interpreters spawned by Java.
-- Apply security patches and updates to the Java environment and any other vulnerable software to mitigate the exploitation vector.
-- Restore the system from a known good backup if the integrity of the system is in question.
-- Implement enhanced logging policies to capture detailed process execution and network connection attempts for future analysis.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of timely patch management and monitoring."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/guided_onboarding_sample_rule.toml b/rules/cross-platform/guided_onboarding_sample_rule.toml
index 98dd2afd90a..90163be7f7e 100644
--- a/rules/cross-platform/guided_onboarding_sample_rule.toml
+++ b/rules/cross-platform/guided_onboarding_sample_rule.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/09/22"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/19"
 
 [rule]
 author = ["Elastic"]
@@ -20,50 +20,13 @@ language = "kuery"
 license = "Elastic License v2"
 max_signals = 1
 name = "My First Rule"
-note = """## Triage and analysis
+note = """This is a test alert.
 
-### Disclaimer
+This alert does not show threat activity. Elastic created this alert to help you understand how alerts work.
 
-This investigation guide was generated 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 My First Rule
-
-Elastic Security leverages event data to monitor system activities. Adversaries often exploit event logs to cover tracks or execute unauthorized actions. The 'My First Rule' is a foundational query that captures all event types, serving as a baseline for understanding normal versus suspicious activities. While it doesn't target specific threats, it aids in familiarizing analysts with alert mechanisms. This is a test alert. This alert does not show threat activity. Elastic created this alert to help you understand how alerts work. For normal rules, the Investigation Guide will help analysts investigate alerts. This alert will show once every 24 hours for each host. It is safe to disable this rule.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context and specific event that triggered the alert, focusing on the `event.kind:event` field.
-- Examine the timestamp of the event to determine when the activity occurred and correlate it with other events around the same time.
-- Identify the source and destination IP addresses involved in the event to assess if they are internal or external to the organization.
-- Check the user account associated with the event to verify if the activity aligns with the user's normal behavior or role.
-- Investigate the host or system where the event originated to gather more context about its current state and recent activities.
-- Utilize Osquery to gather additional information about the system. For example, run the query `SELECT * FROM processes WHERE pid = <suspicious_pid>;` to investigate any suspicious processes.
-- Analyze related logs from other security tools or systems to identify any patterns or anomalies that could indicate suspicious behavior.
-- Look for any recent changes in system configurations or installed software that might explain the event.
-- Cross-reference the event with known threat intelligence sources to determine if it matches any known indicators of compromise.
-- Document findings and any hypotheses about the nature of the event to facilitate further investigation or handoff to other analysts.
-
-### False positive analysis
-
-- The 'My First Rule' captures all event types, which means it can generate alerts for routine system activities that are not indicative of malicious behavior, such as regular user logins, system updates, or scheduled tasks.
-- To manage these false positives, users can create exceptions for known benign activities by identifying patterns in the event data that consistently trigger alerts but are verified as non-threatening.
-- Analysts should regularly review and update exception lists to ensure that new benign activities are accounted for, reducing unnecessary alerts and focusing on potential threats.
-- It's important to collaborate with IT and security teams to understand the context of frequent events and determine which can be safely excluded from triggering alerts.
-- Users can leverage Elastic Security's filtering capabilities to refine the rule's query, excluding specific event types or sources that are known to generate false positives without compromising security monitoring.
-
-### Response and remediation
-
-- Review the alert details to understand the context and determine if it aligns with normal activity or indicates a potential issue.
-- Contain the affected system by isolating it from the network to prevent further unauthorized access or damage.
-- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities in the system logs.
-- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system.
-- Restore the system to its last known good state using backups or system restore points.
-- Escalate the incident to the appropriate security team or management if the activity suggests a broader threat or breach.
-- Implement enhanced logging policies to capture more detailed event data for future analysis and detection.
-- Integrate additional security tools, such as intrusion detection systems or endpoint protection, to improve monitoring capabilities.
-- Review and update security policies and procedures to address any gaps identified during the investigation.
-- Conduct a post-incident review to learn from the event and strengthen the organization's security posture.
+For normal rules, the Investigation Guide will help analysts investigate alerts.
 
+This alert will show once every 24 hours for each host. It is safe to disable this rule.
 """
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-rules.html"]
 risk_score = 21
diff --git a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
index 918dc8ff87a..c335de8be23 100644
--- a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
+++ b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/09/14"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -34,50 +34,6 @@ query = '''
 event.type:creation and event.module:zoom and event.dataset:zoom.webhook and
   event.action:meeting.created and not zoom.meeting.password:*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Zoom Meeting with no Passcode
-
-Zoom meetings without passcodes are vulnerable to unauthorized access, known as Zoombombing, where intruders disrupt sessions with inappropriate content. Adversaries exploit this by targeting unprotected meetings, leading to potential data breaches or session shutdowns. The detection rule identifies such meetings by monitoring Zoom event logs for creation events lacking a passcode, helping to mitigate these security risks.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `event.type:creation` and `event.action:meeting.created` fields, ensuring the alert is triggered by a meeting creation event.
-- Check the `event.module:zoom` and `event.dataset:zoom.webhook` fields to verify the event source and ensure it is related to Zoom's webhook data.
-- Investigate the `zoom.meeting.password` field to confirm the absence of a passcode, which is the primary trigger for this alert.
-- Identify the user or account associated with the meeting creation by examining the user-related fields in the event logs.
-- Cross-reference the meeting ID with other logs to determine if there were any unauthorized access attempts or unusual activities associated with the meeting.
-- Use Osquery to gather additional context on the host machine from which the meeting was created. Example query: `SELECT * FROM processes WHERE name LIKE '%zoom%' AND start_time > (SELECT datetime('now', '-1 hour'));` to identify recent Zoom processes.
-- Analyze network logs to detect any suspicious IP addresses or connections that may have interacted with the meeting link.
-- Review historical data for patterns of meetings created without passcodes by the same user or account to identify potential negligence or malicious intent.
-- Check for any related alerts or incidents involving the same user or meeting ID to assess if this is part of a larger security issue.
-- Document findings and gather evidence from the investigation to support further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Internal meetings intentionally set without passcodes for ease of access can trigger false positives. These are often non-threatening if the meeting links are shared only within a trusted network.
-- Educational institutions may host open sessions for public webinars or lectures, which might be flagged by the rule. These sessions are typically non-threatening if they are monitored and managed by the host.
-- Organizations conducting public events or community outreach programs might create meetings without passcodes to encourage participation. These should be reviewed to ensure they are not mistakenly flagged as threats.
-- To manage these false positives, users can create exceptions for specific meeting hosts or recurring meeting IDs that are known to be safe and intentionally set without passcodes.
-- Implementing a whitelist of trusted domains or email addresses that frequently create meetings without passcodes can help reduce unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure it aligns with current organizational practices and security policies.
-
-### Response and remediation
-
-- Immediately terminate any ongoing Zoom meetings identified without a passcode to prevent further unauthorized access or disruption.
-- Notify the meeting host and relevant stakeholders about the security incident and advise them to reschedule the meeting with appropriate security measures, such as enabling a passcode or waiting room.
-- Review Zoom account settings to ensure that passcodes are required for all future meetings by default and consider enabling additional security features like waiting rooms or authentication.
-- Conduct a thorough investigation of the event logs to identify any unauthorized access or data breaches that may have occurred during the unprotected meeting.
-- Escalate the incident to the IT security team for further analysis and to determine if any sensitive information was compromised, leveraging the MITRE ATT&CK framework to understand potential exploitation methods.
-- Implement enhanced logging policies to capture detailed Zoom meeting events, including participant join and leave times, to aid in future investigations.
-- Integrate Zoom with security information and event management (SIEM) systems to automate the detection and alerting of meetings created without passcodes.
-- Educate users on the importance of securing virtual meetings and provide training on how to configure Zoom settings to prevent Zoombombing.
-- Restore any affected systems or services to their operational state by applying necessary security patches and updates to prevent similar incidents.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as enforcing multi-factor authentication for all Zoom accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/multiple_alerts_different_tactics_host.toml b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
index 3f5a63f224a..676a9a892e7 100644
--- a/rules/cross-platform/multiple_alerts_different_tactics_host.toml
+++ b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -31,49 +31,6 @@ type = "threshold"
 query = '''
 signal.rule.name:* and kibana.alert.rule.threat.tactic.id:*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Multiple Alerts in Different ATT&CK Tactics on a Single Host
-
-In cybersecurity, detecting multiple alerts across different ATT&CK tactics on a single host is crucial for identifying potential compromises. Adversaries often exploit various tactics to infiltrate and persist within a network, such as initial access, execution, and exfiltration. The detection rule leverages alert data to identify hosts triggering alerts in multiple attack phases, indicating a higher likelihood of compromise. This prioritizes these hosts for triage, enabling analysts to respond swiftly to potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific ATT&CK tactics and techniques were triggered, focusing on the `kibana.alert.rule.threat.tactic.id` field for context.
-- Correlate the alert timestamps to identify the sequence of events and determine if there is a pattern or timeline of activities on the host.
-- Examine the host's network traffic logs to identify any unusual outbound connections that may indicate data exfiltration or command and control communication.
-- Check for any recent changes in user accounts or privileges on the host that could suggest lateral movement or privilege escalation.
-- Use Osquery to gather detailed information about the host's current state. For example, run the following query to list all running processes: `SELECT pid, name, path, cmdline FROM processes;`.
-- Investigate any newly installed or modified software on the host that could be related to the alerts, using file integrity monitoring logs or software inventory records.
-- Analyze the host's event logs for any failed login attempts, unusual login times, or logins from unexpected locations.
-- Review any recent email activity associated with the host's user account to identify potential phishing attempts or suspicious attachments.
-- Check for any scheduled tasks or cron jobs on the host that could be used for persistence or automated malicious activities.
-- Cross-reference the host's alert data with threat intelligence feeds to identify any known indicators of compromise (IOCs) that match the observed activities.
-
-### False positive analysis
-
-- Routine administrative tasks or software updates can trigger alerts across multiple ATT&CK tactics, leading to false positives. For example, legitimate software installations might involve execution and persistence tactics.
-- Security tools or scripts running on a host for monitoring or maintenance purposes may generate alerts in different tactics, such as execution and discovery, without indicating a compromise.
-- Users can manage these false positives by creating exceptions for known benign activities, such as scheduled software updates or specific administrative scripts, ensuring these do not trigger unnecessary alerts.
-- Implementing a baseline of normal behavior for hosts can help distinguish between legitimate activities and potential threats, reducing the likelihood of false positives.
-- Regularly reviewing and updating the list of exceptions based on changes in the network environment or operational procedures can help maintain the accuracy of the detection rule.
-
-### Response and remediation
-
-- Isolate the affected host from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to identify the specific ATT&CK tactics and techniques involved, using available threat intelligence and alert data.
-- Analyze logs and network traffic to determine the scope of the compromise and identify any additional affected systems.
-- Remove any identified malicious software or unauthorized access tools from the host.
-- Apply security patches and updates to the affected host to address any exploited vulnerabilities.
-- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
-- Implement enhanced logging and monitoring policies to capture detailed activity on critical systems for future investigations.
-- Integrate additional security tools and threat intelligence feeds to improve detection capabilities and reduce response times.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and staff on security best practices and the specific tactics used in the attack to prevent future incidents."""
 
 
 
diff --git a/rules/cross-platform/multiple_alerts_involving_user.toml b/rules/cross-platform/multiple_alerts_involving_user.toml
index b8d97bade69..076a1096ea5 100644
--- a/rules/cross-platform/multiple_alerts_involving_user.toml
+++ b/rules/cross-platform/multiple_alerts_involving_user.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -33,48 +33,6 @@ type = "threshold"
 query = '''
 signal.rule.name:* and user.name:* and not user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Multiple Alerts Involving a User
-The detection rule leverages alert data to identify users triggering multiple distinct alerts, which may indicate potential compromise. Adversaries often exploit user accounts to escalate privileges or exfiltrate data. By filtering out system accounts, the rule focuses on genuine user activity, helping analysts prioritize investigations and respond to potential threats effectively.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific alerts triggered for the user, focusing on the `signal.rule.name` field to identify the types of alerts involved.
-- Verify the user's identity and role within the organization using the `user.name` field to assess the potential impact of a compromise.
-- Check the user's recent activity logs to identify any unusual behavior patterns or deviations from their normal activity.
-- Investigate the user's login history, including timestamps and IP addresses, to detect any suspicious access attempts or locations.
-- Examine any recent changes to the user's account, such as password resets or privilege escalations, that could indicate unauthorized access.
-- Use Osquery to gather additional context on the user's machine. For example, run the following query to list recent processes executed by the user: `SELECT * FROM processes WHERE user = '<user.name>';`.
-- Correlate the alerts with other security events or logs to identify any related incidents or broader attack patterns.
-- Check for any recent changes in the user's network activity, such as unusual data transfers or connections to known malicious IPs.
-- Investigate any associated alerts or incidents involving other users or systems that may indicate a coordinated attack.
-- Document all findings and observations to provide a comprehensive overview of the investigation for further analysis and decision-making.
-
-### False positive analysis
-
-- Known false positives for the Multiple Alerts Involving a User rule may include users with roles that inherently trigger multiple alerts due to their job functions, such as system administrators or security personnel who regularly access sensitive systems or data.
-- Users involved in automated processes or scripts that interact with various systems might also trigger multiple alerts without any malicious intent.
-- To manage these false positives, users can create exceptions for specific user accounts that are known to generate frequent alerts as part of their normal operations, ensuring these are documented and reviewed regularly.
-- Implementing a baseline of normal user behavior can help distinguish between legitimate and suspicious activities, allowing for more accurate identification of potential threats.
-- Regularly updating the list of system accounts and roles that are excluded from the rule can help reduce the number of false positives and improve the efficiency of threat detection.
-
-### Response and remediation
-
-- Isolate the affected user account by disabling it temporarily to prevent further unauthorized access.
-- Conduct a thorough investigation of the alerts to determine the nature and scope of the compromise, focusing on any unusual activities or access patterns.
-- Review and analyze logs from relevant systems and applications to identify any additional indicators of compromise or lateral movement.
-- Reset the credentials of the compromised user account and any other accounts that may have been affected.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a significant threat or widespread impact.
-- Implement additional logging and monitoring to capture detailed user activity and detect similar threats in the future.
-- Integrate threat intelligence feeds to enhance detection capabilities and provide context for future alerts.
-- Restore affected systems to their operational state by applying necessary patches and updates, and ensure data integrity is maintained.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Implement hardening measures such as multi-factor authentication, least privilege access, and regular security awareness training for users."""
 
 
 
diff --git a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
index 811a13321e3..85d4432c091 100644
--- a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
+++ b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -68,49 +68,6 @@ event.category:file and event.type:change and
            systemd or containerd or pacman
          )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Standard Authentication Module or Configuration
-
-Authentication modules, such as PAM (Pluggable Authentication Modules), are crucial for managing user authentication in systems. Adversaries may exploit these by altering modules or configurations to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to authentication files and processes, excluding legitimate system updates, to flag potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file and process involved in the modification, focusing on `file.name` and `file.path` fields to determine which authentication module was altered.
-- Check the `process.executable` field to identify the process that made the change and verify if it is listed as an excluded legitimate process.
-- Investigate the `event.category` and `event.type` fields to confirm the nature of the change and ensure it aligns with unauthorized modifications.
-- Use Osquery to list all PAM modules and their current configurations to identify any discrepancies or unauthorized changes. Example query: `SELECT * FROM file WHERE path LIKE '/etc/pam.d/%' OR path LIKE '/usr/lib64/security/%';`
-- Cross-reference the timestamp of the alert with system logs to identify any concurrent suspicious activities or user logins that could indicate unauthorized access.
-- Examine the system's package management logs (e.g., yum, dnf, apt) to rule out legitimate updates or installations that might have triggered the alert.
-- Check for any recent user account changes or additions that could be associated with the modification, using commands like `getent passwd` or `cat /etc/passwd`.
-- Investigate the system's cron jobs and startup scripts for any unauthorized entries that could indicate persistence mechanisms.
-- Review the system's audit logs for any anomalies or patterns of access that coincide with the time of the modification.
-- Conduct a historical search for similar alerts or modifications on the same system or across the network to identify potential patterns or repeated attempts.
-
-### False positive analysis
-
-- System updates and package installations can trigger false positives as they often involve legitimate changes to authentication modules or configurations. Users should monitor and exclude processes related to package management tools like `yum`, `dnf`, `apt`, and `rpm` to reduce noise.
-- Administrative tasks such as system configuration changes or maintenance activities performed by authorized personnel may also result in false positives. It's advisable to create exceptions for known administrative processes and users during these periods.
-- Automated scripts or tools that manage system configurations, such as configuration management software (e.g., Ansible, Puppet, Chef), can cause false positives. Users should identify and exclude these tools from triggering alerts.
-- Temporary files or directories used during legitimate software installations or updates, such as those in `/tmp` or `/private/var/folders`, may be flagged. Excluding these paths from monitoring can help minimize false positives.
-- Development or testing environments where frequent changes to authentication modules are expected might generate false positives. Users should consider applying more lenient rules or exclusions in these environments to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the scope of the modification, including reviewing logs and identifying any unauthorized changes to authentication modules or configurations.
-- Verify the integrity of the authentication modules by comparing them against known good versions or using a trusted source to restore them.
-- Remove any unauthorized users or credentials that may have been added as a result of the modification.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for authentication-related activities to detect future unauthorized changes promptly.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify authentication modules or configurations.
-- Apply security patches and updates to the system to address any vulnerabilities that may have been exploited.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to prevent similar incidents in the future.
-- Consider deploying additional security measures such as multi-factor authentication (MFA) and intrusion detection systems (IDS) to enhance the overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/persistence_shell_profile_modification.toml b/rules/cross-platform/persistence_shell_profile_modification.toml
index a5c39525b8b..60a1afc60aa 100644
--- a/rules/cross-platform/persistence_shell_profile_modification.toml
+++ b/rules/cross-platform/persistence_shell_profile_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -49,50 +49,6 @@ event.category:file and event.type:change and
              /Users/*/.bash_profile or
              /Users/*/.zshenv)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Bash Shell Profile Modification
-
-Bash shell profiles, such as `.bash_profile` and `.bashrc`, are scripts that configure user environments upon login. Adversaries exploit these files to maintain persistence by embedding malicious commands that execute automatically. The detection rule identifies unauthorized changes to these profiles by monitoring file modifications and filtering out benign processes, thus highlighting potential security threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path that was modified, focusing on paths like `/home/*/.bash_profile` or `/home/*/.bashrc`.
-- Examine the `process.name` field in the alert to determine which process was responsible for the modification, ensuring it is not one of the benign processes filtered out in the query.
-- Check the `process.executable` field to verify the location of the executable that made the change, ensuring it is not from a known safe directory like `/Applications/*` or `/usr/local/*`.
-- Use Osquery to list recent modifications to the user's shell profile files with a query like: `SELECT path, mtime FROM file WHERE path IN ('/home/*/.bash_profile', '/home/*/.bashrc') ORDER BY mtime DESC LIMIT 5;`.
-- Investigate the user account associated with the modified file to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Review the contents of the modified shell profile file to identify any unusual or malicious commands that may have been added.
-- Cross-reference the timestamp of the file modification with other logs, such as authentication or network logs, to identify any correlated suspicious activity.
-- Check for any recent installations or updates on the system that might have legitimately modified the shell profile files.
-- Investigate any other alerts or anomalies associated with the same user or system to determine if this is part of a broader attack pattern.
-- Consult threat intelligence sources to see if the identified modification or process is associated with known adversary techniques or campaigns.
-
-### False positive analysis
-
-- Frequent legitimate modifications to Bash shell profiles by system administrators or automated scripts can trigger false positives. These include updates made by package managers or configuration management tools.
-- Users often customize their shell environment by adding aliases, functions, or environment variables, which can be mistakenly flagged as suspicious.
-- Development tools and IDEs might modify these profiles to set up necessary environment variables or paths, leading to benign alerts.
-- To manage these false positives, users can create exceptions for known benign processes or specific file paths that are regularly modified for legitimate reasons.
-- Implementing a whitelist of trusted processes or directories can help reduce noise by excluding routine modifications from triggering alerts.
-- Regularly review and update the detection rule to accommodate new legitimate processes or tools that interact with Bash shell profiles.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify unauthorized changes by comparing the current Bash shell profile files with known good backups or baselines.
-- Review recent user activity and process execution logs to identify the source of the unauthorized modifications and any associated malicious processes.
-- Remove any malicious entries from the Bash shell profile files and restore them to their original state using verified backups.
-- Scan the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any identified threats.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger attack campaign or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed file modification events and process execution data for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Educate users on the importance of secure shell practices and the risks associated with unauthorized profile modifications.
-- Apply system hardening measures, such as restricting write permissions to critical configuration files and using multi-factor authentication (MFA) for user logins, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
index ba6b53aff50..71edbff424d 100644
--- a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
+++ b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -50,49 +50,6 @@ event.category:file and event.type:(change or creation) and
               /usr/bin/chef-client
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SSH Authorized Keys File Modification
-
-SSH authorized_keys files are crucial for secure, password-less authentication, allowing specified users to access systems via public keys. Adversaries exploit this by adding their keys, ensuring persistent access. The detection rule identifies unauthorized changes to these files, excluding benign processes, to flag potential malicious activity, aligning with MITRE ATT&CK's persistence tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file that was modified, focusing on `file.name` to determine if it was "authorized_keys", "authorized_keys2", or another critical SSH configuration file.
-- Examine the `event.category` and `event.type` fields to confirm the nature of the change, whether it was a file creation or modification.
-- Check the `process.executable` field to identify the process responsible for the modification and verify if it is listed in the exclusion list of benign processes.
-- Investigate the user account associated with the modification event to determine if it aligns with expected administrative activity or if it appears suspicious.
-- Use Osquery to list all current entries in the authorized_keys file for the affected user account. Example query: `SELECT * FROM authorized_keys WHERE path = '/home/username/.ssh/authorized_keys';`
-- Cross-reference the public keys found in the authorized_keys file with known legitimate keys to identify any unauthorized additions.
-- Review recent login events for the affected user account to identify any unusual access patterns or times that could indicate unauthorized access.
-- Analyze system logs around the time of the modification event to identify any other suspicious activities or related events.
-- Investigate any network connections or data transfers initiated by the process responsible for the modification to assess potential data exfiltration or lateral movement.
-- Correlate the findings with other security alerts or incidents to determine if this event is part of a broader attack campaign.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often modify SSH authorized_keys files during regular maintenance or when adding new users. These legitimate changes can trigger false positives.
-- Automated configuration management: Tools like Puppet, Chef, or Ansible may update authorized_keys files as part of their configuration management processes, leading to benign alerts.
-- Software updates: Some software installations or updates might modify SSH configuration files, including authorized_keys, as part of their setup process.
-- Development tools: Developers using tools like Git or Maven might inadvertently trigger alerts when these tools interact with SSH keys during development activities.
-- To manage false positives, users can refine the detection rule by adding exceptions for known benign processes or specific user actions that are regularly audited and verified. This can be done by updating the exclusion list in the detection rule to include additional trusted processes or paths that are identified during routine operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Verify the integrity of the SSH authorized_keys file by comparing it with a known good backup or baseline.
-- Remove any unauthorized keys found in the authorized_keys file and reset SSH configurations to default settings.
-- Conduct a thorough investigation to identify how the adversary gained access and whether other systems are affected.
-- Review system logs and security alerts to trace the adversary's activities and identify any additional compromised accounts or systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed SSH access logs and file modification events for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore the system to its operational state by applying security patches, updating software, and ensuring all configurations are secure.
-- Harden the system by enforcing strong authentication mechanisms, such as multi-factor authentication, and regularly auditing user access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
index d323deb87b3..d6509cbfe32 100644
--- a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
+++ b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -33,48 +33,6 @@ type = "query"
 query = '''
 event.category:process and event.type:start and process.args:(echo and *NOPASSWD*ALL*)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via Sudoers File Modification
-
-The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by modifying the file to allow unauthorized privilege escalation, often using the NOPASSWD directive to bypass password prompts. The detection rule identifies suspicious process activities, such as attempts to alter sudoers configurations, by monitoring specific command patterns indicative of such abuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the specific process and command line arguments that triggered the alert, focusing on `process.args` containing `echo` and `*NOPASSWD*ALL*`.
-- Verify the user account associated with the process by examining the `user.name` field to determine if the account has a history of administrative actions or if it is a potential target for compromise.
-- Check the `process.executable` field to identify the binary used to execute the command and ensure it is a legitimate system binary.
-- Investigate the parent process using `process.parent.executable` and `process.parent.args` to understand the origin of the suspicious process and assess if it was initiated by a legitimate or suspicious activity.
-- Use Osquery to list recent modifications to the sudoers file by running: `SELECT * FROM file WHERE path = '/etc/sudoers' OR path LIKE '/etc/sudoers.d/%' ORDER BY atime DESC LIMIT 5;` to identify any unauthorized changes.
-- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any entries related to sudo or authentication attempts around the time of the alert to gather additional context.
-- Cross-reference the alert timestamp with other security events or alerts to identify any correlated activities that might indicate a broader attack campaign.
-- Investigate the network activity of the involved host around the time of the alert to identify any suspicious outbound connections that might suggest data exfiltration or command-and-control communication.
-- Review the history of sudoers file modifications by checking version control systems or backup logs, if available, to identify when and by whom the changes were made.
-- Assess the system for other indicators of compromise, such as unusual user accounts, unauthorized software installations, or unexpected system configurations, to determine if the privilege escalation attempt is part of a larger intrusion.
-
-### False positive analysis
-
-- System administrators or automated scripts may legitimately modify the sudoers file to update permissions, which can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or scripts by excluding their process identifiers or command patterns from the rule.
-- Configuration management tools like Ansible, Puppet, or Chef might alter the sudoers file as part of routine system updates or deployments. Users can handle these by identifying the specific processes or tools involved and excluding them from the detection criteria.
-- During system setup or maintenance, temporary changes to the sudoers file might be necessary and benign. Users should document these activities and adjust the detection rule to ignore changes made during scheduled maintenance windows.
-- Some software installations require modifications to the sudoers file to function correctly. Users can whitelist these specific installation processes by excluding their associated command patterns or process names from the rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
-- Review the sudoers file for unauthorized modifications, specifically looking for entries with the NOPASSWD directive, and revert any changes to their original state.
-- Conduct a thorough investigation of system logs to identify any unauthorized access or command execution attempts, focusing on the timeframe of the detected modification.
-- Utilize MITRE ATT&CK framework details to understand the potential impact and methods used by the adversary, specifically focusing on T1548: Abuse Elevation Control Mechanism.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate with a security information and event management (SIEM) system to correlate events and detect similar threats across the network.
-- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are applied.
-- Conduct a security audit of user permissions and sudoers configurations to ensure adherence to the principle of least privilege.
-- Implement hardening measures such as multi-factor authentication for administrative access and regular reviews of privileged access configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
index 3f1ae9992d9..d23c490865c 100644
--- a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
+++ b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -49,49 +49,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SUID/SGID Bit Set
-
-The SUID/SGID bits in Unix-like systems allow files to execute with the privileges of the file's owner or group, rather than the executing user. Adversaries exploit this by setting these bits on files to gain elevated privileges, potentially executing malicious code with higher access rights. The detection rule identifies such abuses by monitoring processes that attempt to set these bits, excluding known legitimate paths and arguments.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args`.
-- Check the `process.parent.executable` field to determine the parent process and assess whether it is a known legitimate path or potentially malicious.
-- Investigate the user account associated with the process by examining the `user.name` field to determine if the account has a history of suspicious activity or if it is a privileged account.
-- Use Osquery to list all files with the SUID/SGID bit set on the system to identify any unexpected or unauthorized files. Example query: `SELECT path, mode FROM file WHERE mode & 4000 OR mode & 2000;`
-- Cross-reference the file paths identified in the alert with known system binaries and applications to determine if the SUID/SGID bit setting is expected or unusual.
-- Analyze the `event.type` and `event.action` fields to confirm the nature of the event and ensure it aligns with the expected behavior of the process.
-- Review system logs and audit logs around the time of the alert to gather additional context on the process execution and any related activities.
-- Investigate any network connections or external communications initiated by the process using network monitoring tools to identify potential data exfiltration or command-and-control activity.
-- Check for any recent changes or installations on the system that might explain the SUID/SGID bit setting, such as software updates or new application installations.
-- Consult threat intelligence sources to determine if the process or file path is associated with known malware or adversary techniques, leveraging the MITRE ATT&CK framework for context on potential privilege escalation tactics.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule when setting SUID/SGID bits as part of their normal operation. Users can handle these by adding exceptions for known software paths or processes, such as package managers or system update tools.
-- System maintenance scripts or administrative tasks that require elevated privileges might also set these bits temporarily. Users should review and potentially exclude these scripts if they are verified as safe and necessary for system operations.
-- Docker or container-related processes might set SUID/SGID bits within their environments, which can be non-threatening. Users can exclude paths related to Docker or container management to reduce false positives.
-- Some security tools or monitoring agents may use SUID/SGID bits to perform their functions. Users should verify these tools and exclude their processes or paths if they are confirmed to be legitimate and secure.
-- Custom scripts or applications developed in-house that require elevated privileges might also trigger the rule. Users should ensure these scripts are secure and then exclude them from monitoring to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes to file permissions and any unauthorized setuid/setgid bit modifications.
-- Review system logs and security alerts to trace the adversary's actions and identify any additional compromised accounts or systems.
-- Remove the setuid/setgid bits from unauthorized files and restore original permissions to prevent further privilege escalation.
-- Scan the system for malware and other indicators of compromise, removing any malicious files or processes discovered.
-- Reset passwords and review user accounts for unauthorized access, ensuring that only legitimate users have access to the system.
-- Escalate the incident to the security team or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring to detect future attempts to exploit setuid/setgid bits, including integrating with SIEM solutions for real-time alerting.
-- Apply system and application patches to address any vulnerabilities that may have been exploited by the adversary.
-- Review and update security policies and hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface and prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
index 163002abfdb..0fa03093486 100644
--- a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
+++ b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -48,51 +48,6 @@ event.category:process and event.type:start and
   process.name:(sudo or sudoedit) and
   process.args:(*\\ and ("-i" or "-s"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Sudo Heap-Based Buffer Overflow Attempt
-
-Sudo is a critical utility in Unix-like systems, allowing users to execute commands with elevated privileges. A heap-based buffer overflow vulnerability (CVE-2021-3156) in Sudo can be exploited by attackers to gain root access. Adversaries may craft specific command arguments to trigger this overflow. The detection rule identifies suspicious Sudo or Sudoedit process starts with particular argument patterns, signaling potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious Sudo or Sudoedit process starts with arguments matching the pattern `*\\\\` and either `"-i"` or `"-s"`.
-- Examine the process execution context by checking the `event.category:process` and `event.type:start` fields to understand the timing and frequency of the suspicious activity.
-- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
-- Analyze the command line arguments (`process.args`) used in the suspicious Sudo or Sudoedit process to identify any unusual or unexpected patterns.
-- Check the system logs for any other related activities around the same timestamp to identify potential lateral movement or further exploitation attempts.
-- Use Osquery to gather additional context about the system state and running processes. For example, run the following Osquery query to list recent Sudo command executions:
-  ```sql
-  SELECT * FROM sudo_log WHERE time > (SELECT MAX(time) - 3600 FROM sudo_log);
-  ```
-- Correlate the findings with any known indicators of compromise (IOCs) related to CVE-2021-3156 to assess the likelihood of a successful exploitation attempt.
-- Investigate any network connections initiated by the affected system around the time of the alert to identify potential data exfiltration or command-and-control communication.
-- Review historical data for similar patterns of Sudo or Sudoedit process starts to determine if this is an isolated incident or part of a broader attack campaign.
-- Document all findings and observations to support further analysis and potential escalation to the incident response team.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often use `sudo` or `sudoedit` with arguments like `-i` or `-s` for legitimate purposes, such as performing routine maintenance or executing scripts that require elevated privileges. These actions can trigger the detection rule, leading to false positives.
-- Automated scripts: Some automated scripts or cron jobs may use `sudo` with specific arguments to perform scheduled tasks. These scripts, if not properly documented or excluded, can cause repeated false positives.
-- Development and testing environments: In environments where developers or testers frequently use `sudo` to simulate production scenarios or test new configurations, the detection rule might flag these activities as suspicious.
-- To manage false positives, users can create exceptions for known benign processes by whitelisting specific command patterns or user accounts that are verified to perform legitimate actions. Additionally, monitoring and logging can be adjusted to focus on unusual patterns or deviations from normal behavior, reducing noise from expected activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Verify the alert by checking process logs and command history for suspicious Sudo or Sudoedit usage patterns that match the detection rule.
-- Conduct a thorough investigation to determine if the vulnerability was successfully exploited and assess the extent of any unauthorized access or changes.
-- If exploitation is confirmed, reset all potentially compromised credentials, especially those with elevated privileges.
-- Apply the latest security patches and updates to the Sudo utility to mitigate the CVE-2021-3156 vulnerability.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Enhance logging policies to capture detailed process execution data, including command-line arguments, to improve future detection capabilities.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to identify and respond to similar threats more effectively.
-- Restore the system to its operational state by verifying the integrity of critical system files and configurations, and ensure all security patches are applied.
-- Implement system hardening measures, such as restricting Sudo access to only necessary users and regularly reviewing user permissions, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
index 4fa584d7cb6..b0d2ae7d57e 100644
--- a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
+++ b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -35,47 +35,6 @@ event.category:file and event.type:change and file.path:(/etc/sudoers* or /priva
 not process.name:(dpkg or platform-python or puppet or yum or dnf) and 
 not process.executable:(/opt/chef/embedded/bin/ruby or /opt/puppetlabs/puppet/bin/ruby or /usr/bin/dockerd)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Sudoers File Modification
-The sudoers file is crucial in Unix-like systems, defining which users can execute commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path involved is indeed `/etc/sudoers` or `/private/etc/sudoers*`, as specified in the query.
-- Check the `event.category` and `event.type` fields to ensure the event is categorized as a file change, confirming the nature of the alert.
-- Identify the `process.name` and `process.executable` fields to determine which process attempted to modify the sudoers file, ensuring it is not one of the excluded legitimate processes.
-- Investigate the user account associated with the process by examining the `user.name` field to determine if the account has a history of suspicious activity or if it is a known administrative account.
-- Use Osquery to list recent changes to the sudoers file with a query like: `SELECT * FROM file WHERE path = '/etc/sudoers' OR path LIKE '/private/etc/sudoers%' ORDER BY atime DESC LIMIT 5;` to gather more context on recent access times.
-- Cross-reference the timestamp of the alert with system logs to identify any concurrent suspicious activities or anomalies that might correlate with the sudoers file modification.
-- Examine the `host.name` or `host.ip` fields to determine if the alert originated from a critical or high-risk system within the network.
-- Review historical alerts or logs for similar sudoers file modification attempts to identify patterns or repeated unauthorized access attempts.
-- Check for any recent privilege escalation attempts or successful escalations on the system by reviewing related security logs or alerts.
-- Investigate any network connections or external communications initiated by the process that modified the sudoers file to identify potential data exfiltration or command-and-control activities.
-
-### False positive analysis
-
-- System updates or package installations may trigger changes to the sudoers file, especially when using package managers like dpkg, yum, or dnf, which are typically legitimate and non-threatening.
-- Configuration management tools such as Puppet or Chef might modify the sudoers file as part of their routine operations, which can be safely excluded if these tools are known to be in use.
-- Docker daemon processes might also interact with the sudoers file during container operations, which can be considered benign if Docker is part of the system's infrastructure.
-- To manage these false positives, users can create exceptions in the detection rule by excluding known legitimate processes and executables, such as those associated with system updates or configuration management tools, ensuring that only suspicious modifications are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
-- Conduct a thorough investigation to identify the source of the modification, reviewing logs for any unauthorized access or changes to the sudoers file.
-- Verify the integrity of the sudoers file by comparing it with a known good backup and restore it if necessary.
-- Check for any unauthorized accounts or changes in user privileges and revert them to their original state.
-- Escalate the incident to the security team if the modification appears to be part of a broader attack or if multiple systems are affected.
-- Implement enhanced logging for sudoers file changes and monitor for any future unauthorized modifications.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate events and improve detection capabilities.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify the sudoers file.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Apply hardening measures such as using sudoers.d for granular control and regularly auditing user privileges to minimize the risk of privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/collection_cloudtrail_logging_created.toml b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
index d6de2ccc1cb..f4c31b3d257 100644
--- a/rules/integrations/aws/collection_cloudtrail_logging_created.toml
+++ b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -20,51 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS CloudTrail Log Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS CloudTrail Log Created
-
-AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs and monitors account activity across your AWS infrastructure. Adversaries may create new trails to capture sensitive data or cover their tracks. The detection rule identifies successful creation events of log trails, which could indicate unauthorized activity or configuration changes, helping analysts to quickly investigate potential security incidents.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `cloudtrail.amazonaws.com`, ensuring the alert is relevant to AWS CloudTrail activity.
-- Verify the event action is `CreateTrail` and the event outcome is `success` to confirm that a new log trail was successfully created.
-- Identify the AWS account and region where the trail was created to understand the scope and potential impact of the activity.
-- Check the IAM user or role associated with the `CreateTrail` action to determine if the activity was performed by an authorized entity.
-- Investigate the time and date of the trail creation to correlate with other suspicious activities or known incidents.
-- Use AWS CloudTrail logs to review recent activities by the identified IAM user or role to detect any other unauthorized or unusual actions.
-- Examine the configuration of the newly created trail, including the S3 bucket and SNS topic settings, to ensure they align with organizational policies and do not expose sensitive data.
-- Utilize Osquery to gather additional context on the AWS environment. For example, run the following Osquery query to list all CloudTrail trails and their configurations: `SELECT * FROM aws_cloudtrail_trails;`
-- Cross-reference the trail creation event with other security tools and logs, such as AWS Config or GuardDuty, to identify any related alerts or configuration changes.
-- Document findings and gather evidence, including logs and screenshots, to support further analysis and potential escalation if unauthorized activity is confirmed.
-
-### False positive analysis
-
-- Routine administrative actions: Regular maintenance or configuration changes by authorized personnel can trigger the AWS CloudTrail Log Created rule. These actions are typically non-threatening and can be excluded by creating exceptions for known administrative accounts or specific time windows when maintenance is scheduled.
-- Automated deployment tools: Organizations using automated tools for infrastructure deployment may frequently create and delete log trails as part of their processes. To manage these false positives, users can identify and exclude specific IAM roles or services associated with these tools.
-- Testing environments: In environments where AWS services are frequently tested, the creation of log trails might be a common occurrence. Users can handle these by excluding specific AWS accounts or regions dedicated to testing.
-- Third-party integrations: Some third-party security or monitoring tools may create log trails as part of their integration with AWS. Users should review and whitelist these tools to prevent unnecessary alerts.
-- Policy updates: Changes in organizational policies might require the creation of new log trails. Users can document and exclude these changes by correlating them with policy update records.
-
-### Response and remediation
-
-- Verify the legitimacy of the newly created AWS CloudTrail log by checking with the responsible team or individual to confirm if the action was authorized.
-- If unauthorized, immediately disable or delete the suspicious CloudTrail log to prevent further data collection or misuse.
-- Review AWS CloudTrail logs and other relevant logs to identify any unauthorized access or suspicious activities that may have occurred before or after the trail creation.
-- Conduct a thorough investigation to determine the scope of the incident, including identifying any compromised accounts or credentials.
-- Reset passwords and rotate access keys for any accounts that may have been compromised to prevent further unauthorized access.
-- Escalate the incident to the security operations team or incident response team for further analysis and to determine if additional actions are required.
-- Implement stricter IAM policies and multi-factor authentication to enhance account security and prevent unauthorized changes to CloudTrail configurations.
-- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
-- Review and update AWS logging policies to ensure all critical actions and changes are logged and monitored effectively.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as least privilege access and regular security training for staff.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
index 066ae589412..cbb1e5613fc 100644
--- a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
+++ b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Admin Credential Fetch via Assumed Role"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS EC2 Admin Credential Fetch via Assumed Role
 
diff --git a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
index 11487b63bbf..e8549d773a8 100644
--- a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
+++ b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/20"
 
 [rule]
 author = ["Elastic"]
@@ -21,12 +21,12 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS IAM CompromisedKeyQuarantine Policy Attached to User"
 note = """
-## Triage and analysis
+## 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.
+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
 
@@ -70,9 +70,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+any where event.dataset == "aws.cloudtrail" 
    and event.action == "AttachUserPolicy"
-   and event.outcome == "success"
+   and event.outcome == "success" 
    and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine")
 '''
 
diff --git a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
index 05875087478..b77b7bdd90c 100644
--- a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
+++ b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -28,7 +28,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS Systems Manager SecureString Parameter Request with Decryption Flag"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag
 
diff --git a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
index 36ab25906c9..e8cfdda99fe 100644
--- a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
+++ b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,51 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Management Console Brute Force of Root User Identity"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Management Console Brute Force of Root User Identity
-
-The AWS Management Console is a web-based interface for managing AWS resources. The root user has unrestricted access, making it a prime target for attackers. Adversaries may attempt brute force attacks to gain unauthorized access. The detection rule monitors failed login attempts by the root user, identifying potential brute force activity by analyzing specific event patterns in AWS CloudTrail logs.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the high number of failed login attempts by filtering for `event.dataset:aws.cloudtrail`, `event.provider:signin.amazonaws.com`, `event.action:ConsoleLogin`, `aws.cloudtrail.user_identity.type:Root`, and `event.outcome:failure`.
-- Analyze the timestamps of the failed login attempts to determine if they occurred in a short period, indicating a potential brute force attack.
-- Identify the source IP addresses associated with the failed login attempts to check for any patterns or anomalies, such as multiple attempts from a single IP or a range of IPs.
-- Cross-reference the source IP addresses with known malicious IP databases or threat intelligence feeds to assess if they are associated with previous malicious activities.
-- Investigate the geographical locations of the source IP addresses to determine if they are consistent with the expected locations of legitimate users.
-- Check for any successful login attempts by the root user around the same time as the failed attempts to assess if the brute force attack was successful.
-- Review the AWS CloudTrail logs for any unusual activities or changes made by the root user following the failed login attempts.
-- Use Osquery to gather additional context on the AWS environment. For example, run a query to list all recent login attempts: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'ConsoleLogin' AND userIdentity.type = 'Root';`
-- Examine the AWS account's security settings, such as multi-factor authentication (MFA) status for the root user, to evaluate the account's resilience against brute force attacks.
-- Collaborate with other security teams or stakeholders to gather additional context or insights regarding the alert and any related activities within the AWS environment.
-
-### False positive analysis
-
-- **Frequent failed logins by legitimate users:** Users may occasionally forget their passwords or mistype them, leading to multiple failed login attempts. To manage this, consider setting a threshold for the number of failed attempts within a specific time frame before triggering an alert.
-- **Automated scripts or tools:** Some organizations use automated scripts for testing or monitoring purposes that may inadvertently cause failed login attempts. Identify and whitelist these scripts or tools to prevent false positives.
-- **IP address changes:** Users accessing the AWS Management Console from different locations or through VPNs may trigger failed login attempts due to IP address changes. Implement IP whitelisting or geolocation checks to reduce false positives.
-- **Time zone differences:** Users in different time zones may log in at unusual hours, leading to suspicion of brute force attempts. Adjust alerting rules to account for legitimate access patterns based on user time zones.
-- **Password policy changes:** Recent changes in password policies may lead to an increase in failed login attempts as users adjust. Monitor for a temporary spike in failed logins following policy updates and adjust thresholds accordingly.
-
-### Response and remediation
-
-- Immediately disable the root user account to prevent further unauthorized access attempts.
-- Review AWS CloudTrail logs to identify the source IP addresses of the failed login attempts and block these IPs using AWS security groups or network ACLs.
-- Conduct a thorough investigation to determine if any successful logins occurred and assess any potential unauthorized changes or data access.
-- Reset the root account password and ensure it is strong and unique, following best practices for password security.
-- Enable multi-factor authentication (MFA) for the root user to add an additional layer of security.
-- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger threat campaign.
-- Implement AWS GuardDuty to enhance threat detection capabilities and receive alerts on suspicious activities.
-- Review and update IAM policies to ensure the principle of least privilege is enforced across all user accounts.
-- Conduct a security awareness training session for all users to reinforce the importance of secure password practices and recognizing phishing attempts.
-- Regularly audit and monitor AWS account activity using CloudTrail and other logging services to quickly identify and respond to future threats.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
diff --git a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
index c1883ad5e71..c0cd38ab247 100644
--- a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
+++ b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -20,51 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Configuration Recorder Stopped"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Configuration Recorder Stopped
-
-AWS Config is a service that tracks AWS resource configurations, enabling compliance auditing and security analysis. Adversaries may stop the configuration recorder to evade detection and impair defenses, aligning with MITRE ATT&CK's Defense Evasion tactics. The detection rule identifies successful attempts to halt this recording, signaling potential malicious activity by monitoring specific AWS CloudTrail events.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to identify the user or role associated with the `StopConfigurationRecorder` event by examining the `userIdentity` field.
-- Check the `sourceIPAddress` field in the CloudTrail logs to determine the origin of the request and assess if it aligns with known IP addresses or locations.
-- Investigate the `eventTime` field to establish a timeline and correlate with other events or activities that occurred around the same time.
-- Analyze the `userAgent` field to understand the tool or method used to stop the configuration recorder, which may provide insights into whether it was a scripted or manual action.
-- Examine the AWS IAM policies and permissions associated with the user or role to determine if they have legitimate access to stop the configuration recorder.
-- Utilize Osquery to gather additional context on the AWS environment by running a query such as: `SELECT * FROM aws_config_recorders WHERE status = 'STOPPED';` to verify the current state of configuration recorders.
-- Cross-reference the `eventID` field with other CloudTrail events to identify any related or sequential actions that might indicate a broader attack pattern.
-- Review any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could have facilitated the stopping of the configuration recorder.
-- Investigate any alerts or logs from other security tools that might indicate concurrent suspicious activities or anomalies in the AWS environment.
-- Consult with relevant stakeholders or teams to verify if the action was authorized or part of a planned maintenance activity, ensuring alignment with organizational policies.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may trigger the AWS Configuration Recorder Stopped rule, as administrators might stop the recorder temporarily for configuration updates or troubleshooting.
-- Automated scripts or third-party tools used for AWS resource management might stop the configuration recorder as part of their normal operation, leading to false positives.
-- To manage these false positives, users can create exceptions for known administrative actions by excluding specific IAM roles or user accounts frequently involved in legitimate configuration changes.
-- Implement tagging or naming conventions for resources and actions that are part of regular maintenance, allowing for easier identification and exclusion from alerts.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the integrity of the detection rule.
-
-### Response and remediation
-
-- Immediately re-enable the AWS Configuration Recorder to ensure continuous monitoring of AWS resource configurations.
-- Conduct a thorough investigation to identify the IAM user or role responsible for stopping the configuration recorder and review their recent activities for any other suspicious actions.
-- Isolate the affected AWS account or resources if malicious activity is confirmed to prevent further unauthorized changes.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can stop the configuration recorder.
-- Implement AWS CloudTrail logging and enable AWS Config rules to monitor and alert on changes to critical configurations in real-time.
-- Escalate the incident to the security operations team for a detailed analysis and to determine if the incident is part of a larger attack pattern.
-- Restore any altered configurations to their last known good state using AWS Config's configuration history and snapshots.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Enhance security monitoring by integrating AWS Config with a Security Information and Event Management (SIEM) system for centralized alerting and analysis.
-- Educate and train staff on security best practices and the importance of maintaining AWS Config to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
index a83bf579818..fb2e47ad909 100644
--- a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/26"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,52 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Network Access Control List Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 Network Access Control List Deletion
-
-Network Access Control Lists (ACLs) in AWS EC2 are essential for managing inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors successful deletion events of ACLs or their entries, signaling potential defense evasion attempts by identifying specific actions and outcomes in AWS CloudTrail logs.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail`, `event.provider:ec2.amazonaws.com`, `event.action:(DeleteNetworkAcl or DeleteNetworkAclEntry)`, and `event.outcome:success` fields to ensure the alert is valid.
-- Identify the IAM user or role associated with the deletion event by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by an authorized entity.
-- Check the `sourceIPAddress` field in the CloudTrail logs to identify the IP address from which the deletion request originated, and assess if it aligns with known and trusted IP addresses.
-- Investigate the `eventTime` field to establish a timeline of events and correlate it with other activities in the AWS environment to identify any suspicious patterns or anomalies.
-- Use Osquery to gather additional context about the affected EC2 instances and subnets. For example, run the following Osquery query to list all current network ACLs and their entries: `SELECT * FROM aws_ec2_network_acls;`.
-- Examine the AWS CloudTrail logs for any preceding or subsequent events related to the same IAM user or role to identify any other potentially malicious activities.
-- Review the AWS Config history for changes to the network ACLs and associated resources to understand the broader impact of the deletion event.
-- Analyze the `userAgent` field in the CloudTrail logs to determine the tool or service used to perform the deletion, which may provide insights into the method of access.
-- Check for any recent changes in IAM policies or roles that might have inadvertently granted excessive permissions, allowing unauthorized users to delete network ACLs.
-- Investigate any alerts or logs from other security tools or services that might indicate concurrent or related suspicious activities in the AWS environment.
-
-### False positive analysis
-
-- Routine maintenance or infrastructure changes by authorized personnel can trigger false positives when ACLs are intentionally deleted as part of network reconfiguration or updates. 
-- Automated scripts or tools used for infrastructure management might delete and recreate ACLs as part of their normal operation, leading to benign deletion events.
-- Scheduled decommissioning of resources, where ACLs are removed as part of the cleanup process, can also result in false positives.
-- To manage these false positives, users can create exceptions for known maintenance windows or specific IAM roles that are authorized to perform such actions.
-- Implementing tagging strategies for resources can help identify and exclude ACL deletions associated with legitimate operational activities.
-- Regularly reviewing and updating the list of trusted IP addresses and IAM roles involved in network management can help refine detection rules and reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration.
-- Review AWS CloudTrail logs to identify the source and user responsible for the deletion of the Network ACL.
-- Verify if the deletion was authorized by cross-referencing with change management records or contacting the responsible team.
-- Restore the deleted Network ACL or its entries from backups or recreate them based on documented configurations.
-- Implement AWS Identity and Access Management (IAM) policies to restrict permissions for deleting Network ACLs to only necessary personnel.
-- Enable AWS Config to continuously monitor and record configuration changes to Network ACLs for future audits.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
-- Conduct a root cause analysis to determine how the deletion was executed and identify any security gaps.
-- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other AWS resources.
-- Review and update the incident response plan to include specific procedures for handling Network ACL deletions and similar defense evasion tactics.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
index e39d3700b0d..d39dcc0b035 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,50 +21,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS ElastiCache Security Group Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS ElastiCache Security Group Created
-
-AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential misuse aligned with defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `elasticache.amazonaws.com` to ensure the alert is relevant to ElastiCache security group creation.
-- Verify the event action is "Create Cache Security Group" and the event outcome is "success" to confirm the security group was successfully created.
-- Identify the AWS account and user or role that initiated the creation of the security group by examining the `user.identity.arn` and `aws.account.id` fields.
-- Check the time of the event to determine if the creation occurred during normal business hours or if it was an unusual time, which might indicate suspicious activity.
-- Investigate the IP addresses and locations associated with the request using the `source.ip` field to identify any anomalies or unexpected geolocations.
-- Review the CloudTrail logs for any preceding or subsequent actions by the same user or role to identify potential patterns of suspicious behavior.
-- Examine the configuration of the newly created security group, including any inbound or outbound rules, to assess if it allows overly permissive access.
-- Use Osquery to query the AWS environment for additional context on the security group. Example query: `SELECT * FROM aws_elasticache_security_groups WHERE name = '<security_group_name>';`
-- Cross-reference the security group creation with any recent changes in IAM policies or roles that might have granted new permissions to the user or role involved.
-- Consult with the relevant team or individual responsible for AWS ElastiCache management to verify if the security group creation was authorized and aligns with expected changes or deployments.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular maintenance or configuration changes by authorized personnel can trigger the creation of new ElastiCache security groups. These actions are typically non-threatening and can be verified by cross-referencing with change management logs or authorized user activity.
-- Automated deployment scripts: Organizations using infrastructure as code (IaC) tools like Terraform or AWS CloudFormation may automatically create security groups as part of their deployment processes. These should be reviewed and, if deemed non-threatening, can be excluded by identifying specific user agents or IAM roles associated with these tools.
-- Testing environments: Development or testing environments often mimic production setups, including the creation of security groups. These environments can be excluded by tagging resources appropriately and filtering alerts based on these tags.
-- Third-party integrations: Some third-party services or applications may require the creation of security groups for integration purposes. It's important to verify these integrations and, if legitimate, exclude them by identifying specific service accounts or API calls associated with these services.
-
-### Response and remediation
-
-- Immediately review the AWS CloudTrail logs to identify the source and context of the ElastiCache security group creation event.
-- Verify the identity and access management (IAM) permissions of the user or role that created the security group to ensure it aligns with expected behavior.
-- Temporarily revoke or restrict permissions for the identified user or role to prevent further unauthorized actions.
-- Assess the configuration of the newly created security group to determine if it allows overly permissive access and adjust the rules to align with the principle of least privilege.
-- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration has occurred using the new security group.
-- Escalate the incident to the security operations center (SOC) or incident response team if malicious intent is suspected, providing them with all relevant logs and findings.
-- Implement enhanced logging and monitoring for ElastiCache and related AWS services to detect similar activities in the future.
-- Integrate AWS CloudTrail with a security information and event management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Restore any affected systems or data to their last known good state if unauthorized changes or access were detected.
-- Review and update security group policies and IAM roles to harden the environment against similar threats, ensuring alignment with best practices and compliance requirements.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
index 0dc82db5441..a496a341a8c 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,51 +21,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS ElastiCache Security Group Modified or Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS ElastiCache Security Group Modified or Deleted
-
-AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, identifying successful modifications or deletions that could indicate potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific event.action that triggered the alert, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress."
-- Examine the event.outcome field to confirm the success of the action, ensuring that the modification or deletion was indeed successful.
-- Check the event.dataset and event.provider fields to verify that the event originated from AWS CloudTrail and is related to ElastiCache, confirming the context of the alert.
-- Investigate the user identity associated with the event by reviewing the user identity fields in the CloudTrail logs to determine if the action was performed by an authorized user or an unexpected account.
-- Analyze the event time to correlate the action with other activities in the environment, identifying any unusual patterns or sequences of events.
-- Use Osquery to gather additional context on the AWS environment. For example, run a query to list recent changes to ElastiCache security groups: `SELECT * FROM aws_cloudtrail_events WHERE eventSource='elasticache.amazonaws.com' AND (eventName='DeleteCacheSecurityGroup' OR eventName='AuthorizeCacheSecurityGroupIngress' OR eventName='RevokeCacheSecurityGroupIngress') AND eventTime > date('now', '-1 day');`
-- Review the IP addresses and locations associated with the event to identify any anomalies or unexpected access patterns.
-- Investigate any related alerts or logs from other AWS services or security tools that might provide additional context or indicate a broader security incident.
-- Check for any recent changes in IAM policies or roles that might have inadvertently allowed unauthorized access to modify ElastiCache security groups.
-- Document all findings and observations to build a comprehensive understanding of the event, which will aid in determining the legitimacy of the action and any potential security implications.
-
-### False positive analysis
-
-- Routine maintenance activities by authorized personnel can trigger alerts when they modify or delete ElastiCache security groups as part of their regular duties. To manage these, users can create exceptions for specific IAM roles or users known to perform these tasks regularly.
-- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Users should identify these scripts and exclude their actions from triggering alerts by using tags or specific identifiers.
-- Changes made during scheduled updates or deployments can also result in false positives. Users can mitigate these by setting up maintenance windows and excluding activities within these time frames from alerting.
-- Testing environments often undergo frequent changes, including security group modifications. Users can exclude specific environments or accounts dedicated to testing from the detection rule to reduce noise.
-- Integration with third-party services that require security group modifications might lead to false positives. Users should document these integrations and create exceptions for known service accounts or API calls associated with these services.
-
-### Response and remediation
-
-- Immediately isolate the affected ElastiCache instance by modifying the security group to restrict all inbound and outbound traffic.
-- Review CloudTrail logs to identify unauthorized API calls related to the security group changes and determine the source and identity of the actor.
-- Conduct a thorough investigation to assess the extent of unauthorized access or data exfiltration, focusing on the time window around the detected changes.
-- Revert any unauthorized modifications to the security group by restoring it to its previous state using backups or documented configurations.
-- Escalate the incident to the security operations team and notify relevant stakeholders, including data owners and compliance officers, if sensitive data is involved.
-- Implement additional monitoring and alerting for changes to ElastiCache security groups to detect similar activities in the future.
-- Enhance logging policies to ensure comprehensive coverage of all security group modifications and deletions, including detailed user activity logs.
-- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities related to ElastiCache.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can modify security groups.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as multi-factor authentication and regular security audits.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html"]
diff --git a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
index 09422ea01e8..d0f4ad05d7d 100644
--- a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS GuardDuty Detector Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS GuardDuty Detector Deletion
-
-AWS GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior. Deleting a GuardDuty detector halts this monitoring, potentially concealing malicious actions. Adversaries may exploit this by deleting detectors to evade detection. The detection rule identifies successful deletion events, signaling potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail`, the event provider is `guardduty.amazonaws.com`, and the event action is `DeleteDetector` with an outcome of `success`.
-- Identify the AWS account and region where the detector deletion occurred to understand the scope of the potential impact.
-- Check the CloudTrail logs for the user identity or role that performed the `DeleteDetector` action to determine if it was an authorized user or a potential compromise.
-- Investigate the timing of the deletion event to see if it coincides with any other suspicious activities or alerts in the environment.
-- Examine the IAM policies and permissions associated with the user or role to assess if they have legitimate access to delete GuardDuty detectors.
-- Use Osquery to query the AWS environment for any recent changes in IAM roles or policies that might have allowed unauthorized access. Example query: `SELECT * FROM aws_iam_roles WHERE role_name = 'SuspiciousRole';`
-- Review any recent GuardDuty findings prior to the deletion to identify potential threats that might have prompted the deletion.
-- Analyze network traffic and logs around the time of the deletion for any unusual patterns or connections that could indicate malicious activity.
-- Cross-reference the deletion event with other security tools and logs to gather additional context and corroborate findings.
-- Document all findings and observations to build a comprehensive timeline and context for the deletion event, aiding in further analysis and potential escalation.
-
-### False positive analysis
-
-- Routine maintenance or administrative actions by authorized personnel can trigger false positives when a GuardDuty detector is intentionally deleted for legitimate reasons, such as reconfiguring the service or migrating to a different AWS account.
-- Automated scripts or cloud management tools that manage AWS resources might delete detectors as part of their normal operation, leading to false positives if these actions are not properly documented or communicated.
-- To manage these false positives, users can create exceptions for known and documented maintenance windows or authorized personnel actions by using tags or specific IAM roles associated with legitimate detector deletions.
-- Implementing a review process for detector deletion events can help distinguish between legitimate administrative actions and potential malicious activities, reducing the likelihood of false positives impacting security operations.
-
-### Response and remediation
-
-- Immediately verify the deletion event by cross-referencing with CloudTrail logs to confirm the identity and location of the user or service account responsible for the action.
-- Contain the potential threat by temporarily revoking access for the identified user or service account and reviewing their recent activity for any other suspicious actions.
-- Initiate a comprehensive investigation to determine if the deletion was authorized and assess the potential impact on the environment, including any missed detections during the downtime.
-- Restore the GuardDuty detector by re-enabling it and ensuring that all configurations are correctly set to resume monitoring and threat detection.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can delete or modify GuardDuty detectors.
-- Implement enhanced logging and monitoring policies to capture detailed audit trails of all security-related actions, including detector deletions.
-- Integrate GuardDuty with a Security Information and Event Management (SIEM) system to centralize alerts and facilitate real-time monitoring and response.
-- Escalate the incident to the security operations team if unauthorized activity is confirmed, and consider involving legal or compliance teams if sensitive data may have been compromised.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply hardening measures by enabling multi-factor authentication (MFA) for all accounts with permissions to modify security settings and regularly review and update security configurations.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
index 9d68311c766..4a584d3a37c 100644
--- a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
+++ b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/20"
 
 [rule]
 author = ["Austin Songer", "Elastic"]
@@ -46,50 +46,6 @@ any where event.dataset == "aws.cloudtrail"
     and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3") 
     and event.outcome == "success"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS DB Instance Restored
-
-Amazon RDS (Relational Database Service) allows users to set up, operate, and scale databases in the cloud. Adversaries may exploit this by restoring databases from snapshots or S3 to access sensitive data or bypass security controls. The detection rule identifies successful restoration attempts, flagging potential unauthorized activities by monitoring specific API calls and outcomes, thus aiding in early threat detection.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is "aws.cloudtrail" and the event provider is "rds.amazonaws.com" to ensure the alert is relevant to AWS RDS activities.
-- Verify the event action is either "RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3" and the event outcome is "success" to confirm the restoration activity was completed successfully.
-- Identify the user or role associated with the API call by examining the user identity fields in the event data to determine if the credentials used were legitimate or potentially compromised.
-- Check the source IP address and user agent string in the event data to identify any unusual access patterns or locations that could indicate unauthorized access.
-- Investigate the timing of the restoration event to see if it coincides with any other suspicious activities or alerts in the environment.
-- Review CloudTrail logs for any preceding or subsequent API calls made by the same user or role to identify any additional suspicious activities or patterns.
-- Examine the specific DB instance details, such as the DB instance identifier and snapshot or S3 bucket used, to understand what data may have been accessed or restored.
-- Use Osquery to further investigate the AWS environment. For example, run the following Osquery query to list recent RDS restoration activities: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('RestoreDBInstanceFromDBSnapshot', 'RestoreDBInstanceFromS3') AND eventSource = 'rds.amazonaws.com' AND responseElements IS NOT NULL;`
-- Cross-reference the restored DB instance details with known business operations or maintenance activities to determine if the restoration was authorized or expected.
-- Collaborate with the database administration team to verify if the restoration aligns with any scheduled tasks or if it was an unexpected event requiring further investigation.
-
-### False positive analysis
-
-- Routine database maintenance or recovery operations by authorized personnel can trigger this rule, leading to false positives. These activities might include regular backups or disaster recovery tests.
-- Development or testing environments often involve frequent restoration of databases from snapshots or S3 for testing purposes, which can be mistaken for unauthorized activities.
-- Automated processes or scripts that restore databases as part of their workflow can also generate alerts. These should be reviewed and, if deemed non-threatening, excluded from triggering the rule.
-- To manage these false positives, users can create exceptions for known IP addresses or IAM roles associated with legitimate restoration activities.
-- Implement tagging or naming conventions for databases restored as part of regular operations, allowing for easy identification and exclusion from alerts.
-- Regularly review and update the list of exceptions to ensure that only non-threatening activities are excluded, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected RDS instance to prevent further unauthorized access or data exfiltration.
-- Review CloudTrail logs to identify the source of the compromised credentials and assess the scope of the incident.
-- Revoke any compromised credentials and rotate keys or passwords associated with the affected AWS account.
-- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated during the unauthorized restoration.
-- Escalate the incident to the security operations team and notify relevant stakeholders, including data protection officers if sensitive data is involved.
-- Implement additional logging and monitoring for RDS activities, ensuring that all API calls related to database restoration are captured and reviewed.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance real-time threat detection and response capabilities.
-- Restore the RDS instance to its last known good state using backups or snapshots, ensuring data integrity and availability.
-- Apply security hardening measures such as enabling multi-factor authentication (MFA), enforcing least privilege access, and regularly reviewing IAM policies.
-- Educate users on security best practices and conduct regular security awareness training to prevent credential compromise in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
index 00c7c497c90..0df31df63c9 100644
--- a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "Route53 Resolver Query Log Configuration Deleted"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating Route53 Resolver Query Log Configuration Deleted
 
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
index 58226f3abab..ceb62849c0d 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -20,50 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Configuration Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS S3 Bucket Configuration Deletion
-
-Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. Adversaries may delete these configurations to evade defenses, remove traces, or disrupt operations. The detection rule monitors successful deletions of these configurations, signaling potential malicious activity by correlating specific actions and outcomes in AWS CloudTrail logs.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to identify the user or role associated with the `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle` actions.
-- Check the `event.outcome` field to confirm the success of the deletion actions and correlate with the time of the alert.
-- Investigate the `event.provider` field to ensure the actions were performed on `s3.amazonaws.com`, confirming the target service.
-- Analyze the `event.dataset` field to verify the logs are from `aws.cloudtrail`, ensuring the source of the data is accurate.
-- Examine the IP address and location from which the actions were initiated to identify any anomalies or unauthorized access patterns.
-- Review the IAM policies and permissions of the user or role involved to determine if they had legitimate access to perform the deletions.
-- Cross-reference the actions with recent changes in the AWS environment to identify if these deletions were part of a planned change or an unexpected event.
-- Utilize Osquery to gather additional context on the AWS environment. For example, run an Osquery query to list recent S3 bucket configuration changes: `SELECT * FROM aws_s3_bucket WHERE action IN ('DeleteBucketPolicy', 'DeleteBucketReplication', 'DeleteBucketCors', 'DeleteBucketEncryption', 'DeleteBucketLifecycle') AND outcome = 'success';`
-- Check for any other suspicious activities in the AWS account around the same timeframe, such as unusual login attempts or changes to other critical resources.
-- Consult with the team responsible for AWS operations to verify if the deletions were authorized and documented as part of routine maintenance or updates.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular maintenance or updates by authorized personnel may involve deleting and reconfiguring S3 bucket settings, which can trigger this rule. To manage this, users can create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated scripts or tools: Some organizations use automated processes to manage S3 configurations, which might include deleting and recreating configurations as part of their workflow. Users should identify these scripts and exclude their activity from triggering alerts by whitelisting specific IAM roles or user accounts associated with these processes.
-- Third-party integrations: Certain third-party services or applications may require temporary deletion of S3 configurations to function correctly. Users should review and document these integrations, then adjust the detection rule to exclude actions performed by these trusted services.
-- Testing environments: In development or testing environments, frequent changes to S3 configurations, including deletions, are common. Users can exclude these environments from the rule by filtering out specific AWS accounts or tags associated with non-production resources.
-
-### Response and remediation
-
-- Immediately isolate the affected S3 bucket to prevent further unauthorized changes or data loss.
-- Review AWS CloudTrail logs to identify the source and user responsible for the configuration deletion, correlating with other suspicious activities.
-- Restore the deleted configurations from backups or previous versions to ensure the bucket's security and compliance settings are reinstated.
-- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the period of misconfiguration.
-- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack pattern.
-- Implement additional logging and monitoring for S3 buckets to detect future unauthorized configuration changes promptly.
-- Review and update IAM policies to ensure that only authorized users have permissions to modify S3 bucket configurations.
-- Integrate AWS GuardDuty and other threat detection services to enhance visibility and automated alerting for suspicious activities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate and train staff on security best practices and the importance of maintaining secure configurations to prevent similar incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
index d99b4215ed4..00d6eb47dfd 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Expiration Lifecycle Configuration Added"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added
 
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
index 47b812b4bf5..6815557fb75 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/12"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ license = "Elastic License v2"
 name = "AWS S3 Bucket Server Access Logging Disabled"
 note = """
 
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS S3 Bucket Server Access Logging Disabled
 
@@ -80,9 +80,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
-   and event.action == "PutBucketLogging"
-   and event.outcome == "success"
+any where event.dataset == "aws.cloudtrail" 
+   and event.action == "PutBucketLogging" 
+   and event.outcome == "success" 
    and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled")
 '''
 
diff --git a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
index 140c2ac28f1..5d042038e21 100644
--- a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
+++ b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/19"
 
 [rule]
 author = ["Elastic"]
@@ -39,49 +39,6 @@ event.dataset: "aws.cloudtrail"
     and event.provider: sts.amazonaws.com
     and event.action: GetFederationToken
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of STS GetFederationToken Request by User
-
-AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user within a 10-day window, helping to uncover potential misuse.
-
-### Possible investigation steps
-
-- Review the `event.dataset` field to confirm the event source is "aws.cloudtrail" and ensure the event is related to AWS CloudTrail logs.
-- Verify the `event.provider` field to ensure the event is associated with "sts.amazonaws.com", confirming it involves the AWS Security Token Service.
-- Check the `event.action` field to confirm the action is "GetFederationToken", indicating a request for temporary credentials.
-- Identify the user who initiated the `GetFederationToken` request by examining the `user.identity.arn` or `user.identity.userName` fields to determine if the user is legitimate and authorized.
-- Investigate the `sourceIPAddress` field to determine the origin of the request and assess if the IP address is expected or unusual for the user.
-- Analyze the `userAgent` field to understand the context of the request, such as the application or service used, and determine if it aligns with typical user behavior.
-- Review the `event.time` field to establish the timing of the request and correlate it with other activities or events that may indicate suspicious behavior.
-- Examine the `requestParameters` field to understand the specifics of the `GetFederationToken` request, such as the duration and permissions requested, to assess if they are appropriate.
-- Utilize Osquery to gather additional context on the user's activity on the host. For example, run the following Osquery query to list recent AWS CLI commands executed by the user: `SELECT * FROM shell_history WHERE command LIKE '%aws%' AND user = '<username>';`
-- Cross-reference the `GetFederationToken` request with other logs and alerts to identify any patterns or anomalies that could indicate a broader security incident.
-
-### False positive analysis
-
-- **Routine Administrative Tasks**: Regular administrative operations may involve the use of `GetFederationToken` for legitimate purposes, such as accessing AWS resources for maintenance or monitoring. Users can manage these by creating exceptions for known administrative accounts or roles that frequently perform these tasks.
-- **Automated Scripts and Tools**: Automated processes or third-party tools that integrate with AWS services might use `GetFederationToken` to function correctly. To handle these, identify and whitelist the specific scripts or tools that are known to use this API call regularly.
-- **New Service Integrations**: When integrating new services or applications with AWS, initial `GetFederationToken` requests might be flagged. Users should document and exclude these occurrences by updating the detection rule to recognize these integrations as non-threatening.
-- **User Onboarding**: During the onboarding of new users or roles, initial `GetFederationToken` requests may be expected. To prevent false positives, establish a process to temporarily exclude these users or roles from the detection rule during their onboarding period.
-- **Testing and Development Environments**: In testing or development environments, `GetFederationToken` requests might be used frequently for testing purposes. Users can manage these by setting up separate monitoring rules or exclusions for these environments to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately revoke the temporary credentials obtained through the GetFederationToken request to prevent unauthorized access to AWS resources.
-- Investigate the user account that made the GetFederationToken request to determine if the activity was legitimate or indicative of compromise.
-- Review CloudTrail logs for any other unusual or unauthorized activities associated with the user account or related AWS resources.
-- If compromise is suspected, reset the credentials for the affected user account and any other accounts that may have been accessed using the temporary credentials.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or resources are affected.
-- Implement enhanced logging and monitoring for AWS STS activities, focusing on GetFederationToken requests, to detect similar activities in the future.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Educate users on the risks associated with the misuse of AWS STS and the importance of reporting suspicious activities.
-- Review and update AWS IAM policies to ensure that only authorized users have the necessary permissions to request temporary credentials.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as multi-factor authentication and least privilege access controls, to prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
index 94745a92c6e..305ae622ff5 100644
--- a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
+++ b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Insecure AWS EC2 VPC Security Group Ingress Rule Added"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added
 
diff --git a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
index 9a54de6c9d9..33ddcf3751a 100644
--- a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -20,51 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS WAF Access Control List Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS WAF Access Control List Deletion
-
-AWS WAF protects web applications by filtering and monitoring HTTP requests. Access Control Lists (ACLs) define rules to block or allow traffic. Adversaries may delete ACLs to disable protections, facilitating attacks. The detection rule monitors successful deletion events in AWS CloudTrail, signaling potential defense evasion attempts by identifying unauthorized or suspicious ACL deletions.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the `event.action:DeleteWebACL` and `event.outcome:success` to ensure the alert is valid and not a false positive.
-- Identify the `user.identity.arn` field in the CloudTrail logs to determine which IAM user or role initiated the deletion of the WAF ACL.
-- Check the `sourceIPAddress` field to identify the IP address from which the deletion request was made, and verify if it aligns with known or expected IP addresses for your organization.
-- Investigate the `userAgent` field to understand the application or service used to perform the deletion, which might provide additional context about the source of the request.
-- Examine the `eventTime` field to establish a timeline of events and correlate it with other activities in the AWS environment around the same time.
-- Use Osquery to query AWS API logs for any other suspicious activities around the same time. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'DeleteWebACL' AND eventTime BETWEEN 'start_time' AND 'end_time';`
-- Cross-reference the IAM user or role identified with recent IAM activity logs to check for any unusual permission changes or access patterns.
-- Investigate any recent changes to IAM policies or roles that might have inadvertently allowed unauthorized users to delete WAF ACLs.
-- Review the AWS WAF configuration history to determine if there were any recent changes to the ACLs that could have been a precursor to the deletion.
-- Check for any other security alerts or incidents in the AWS environment that might indicate a broader attack or compromise.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may trigger the AWS WAF Access Control List Deletion rule, especially if performed by authorized personnel. These actions are typically non-threatening and can be considered false positives.
-- Automated scripts or tools used for infrastructure management might delete and recreate ACLs as part of their normal operation, leading to false positives. Users should identify these scripts and consider excluding their activity from alerts.
-- Changes in security policies or compliance requirements might necessitate the deletion of certain ACLs, which could be misinterpreted as suspicious activity. Users should document these changes and adjust the detection rule to account for them.
-- To manage false positives, users can create exceptions for specific IAM roles or users known to perform legitimate ACL deletions regularly. This can be done by adding conditions to the detection rule to exclude these entities.
-- Implementing a review process for deletion events can help differentiate between legitimate and suspicious activities, allowing for more accurate threat detection while minimizing false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS account to prevent further unauthorized actions and assess the scope of the incident.
-- Review AWS CloudTrail logs to identify the source and user responsible for the deletion of the WAF ACL, focusing on any anomalies or unauthorized access patterns.
-- Verify the integrity of other security configurations and access controls within the AWS environment to ensure no additional tampering has occurred.
-- Restore the deleted WAF ACL from backups or recreate it using predefined templates to re-establish web application protections.
-- Implement multi-factor authentication (MFA) for all AWS accounts to enhance security and prevent unauthorized access.
-- Conduct a thorough review of IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized actions.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were compromised.
-- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and analysis.
-- Develop and implement a comprehensive incident response plan that includes regular drills and updates based on lessons learned from the incident.
-- Educate and train staff on security best practices and the importance of maintaining robust access controls to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
index 4f99551a51e..1206af84945 100644
--- a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/09"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -20,52 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS WAF Rule or Rule Group Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS WAF Rule or Rule Group Deletion
-
-AWS Web Application Firewall (WAF) protects web applications by filtering and monitoring HTTP requests. Adversaries may delete WAF rules or groups to disable security measures, facilitating attacks like data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion actions, identifying potential defense evasion attempts by tracking specific API calls related to rule deletions.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to confirm the deletion event by filtering for `event.dataset:aws.cloudtrail` and `event.action:(DeleteRule or DeleteRuleGroup)` to ensure the alert is not a false positive.
-- Identify the `event.provider` field to determine which AWS WAF service (waf.amazonaws.com, waf-regional.amazonaws.com, or wafv2.amazonaws.com) was involved in the deletion.
-- Examine the `userIdentity` field in the CloudTrail logs to identify the IAM user or role that performed the deletion action.
-- Check the `sourceIPAddress` field to determine the IP address from which the deletion request originated, which can help identify if the action was performed from an unusual location.
-- Investigate the `eventTime` field to establish a timeline of events and correlate with other activities in the AWS environment around the same time.
-- Use the `requestParameters` field to identify which specific WAF rule or rule group was deleted, providing context on what protections were removed.
-- Cross-reference the `userAgent` field to understand the tool or service used to perform the deletion, which might indicate if it was done through the AWS Management Console, CLI, or another method.
-- Utilize Osquery to gather additional context on the AWS environment by running a query such as: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('DeleteRule', 'DeleteRuleGroup') AND eventSource IN ('waf.amazonaws.com', 'waf-regional.amazonaws.com', 'wafv2.amazonaws.com') AND outcome = 'success';`
-- Review IAM policies and permissions associated with the identified user or role to determine if they have legitimate access to delete WAF rules or groups.
-- Investigate any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions, potentially leading to unauthorized deletions.
-
-### False positive analysis
-
-- Routine maintenance or updates by authorized personnel can trigger false positives when legitimate changes are made to AWS WAF rules or rule groups. 
-- Automated scripts or tools used for infrastructure management might delete and recreate rules as part of their normal operation, leading to false positives.
-- Scheduled policy updates or deployments that involve rule deletions can also be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for known maintenance windows or specific IAM roles that are authorized to perform such actions.
-- Implementing tagging or naming conventions for rules and rule groups can help in identifying legitimate deletions and excluding them from alerts.
-- Regularly review and update the list of trusted IP addresses or user agents that are allowed to perform these actions to minimize unnecessary alerts.
-
-### Response and remediation
-
-- Immediately review AWS CloudTrail logs to confirm the deletion of the WAF rule or rule group and identify the user or service account responsible for the action.
-- Contain the potential threat by temporarily revoking access for the identified user or service account and reviewing their recent activity for any other suspicious actions.
-- Investigate the context of the deletion by checking for any related alerts or anomalies in network traffic or application logs that might indicate an ongoing attack.
-- Restore the deleted WAF rule or rule group from backups or recreate them based on documented configurations to ensure continued protection of web applications.
-- Escalate the incident to the security operations team if the deletion appears to be part of a larger attack or if unauthorized access is suspected.
-- Implement stricter access controls and multi-factor authentication for accounts with permissions to modify WAF configurations to prevent unauthorized changes.
-- Enhance logging and monitoring by ensuring that all AWS WAF-related actions are logged in CloudTrail and integrated with a Security Information and Event Management (SIEM) system for real-time analysis.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future.
-- Educate relevant personnel on the importance of WAF configurations and the potential impact of unauthorized deletions to raise awareness and prevent recurrence.
-- Consider implementing additional AWS security services, such as AWS Config, to continuously monitor and enforce compliance with security policies related to WAF configurations.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
index a7d0429b0e1..ac33fffcfe4 100644
--- a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
+++ b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/26"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS EC2 Multi-Region DescribeInstances API Calls"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS EC2 Multi-Region DescribeInstances API Calls
 
diff --git a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
index 42324ef7d46..a3e05953da5 100644
--- a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
+++ b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS Discovery API Calls via CLI from a Single Resource"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS Discovery API Calls via CLI from a Single Resource
 
diff --git a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
index 2a30806c376..e0fa48aacb1 100644
--- a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
+++ b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/08/26"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 
 [rule]
 author = ["Elastic"]
@@ -60,50 +60,6 @@ from logs-aws.cloudtrail-*
 // sort the results by time windows in descending order
 | sort target_time_window desc
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Service Quotas Multi-Region `GetServiceQuota` Requests
-
-AWS Service Quotas manage resource limits, crucial for maintaining cloud efficiency. Adversaries exploit `GetServiceQuota` API calls to probe EC2 limits, potentially using compromised credentials to map infrastructure across regions. The detection rule identifies unusual multi-region queries within a short timeframe, signaling possible reconnaissance activities by counting distinct regions and API calls, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific `aws.cloudtrail.user_identity.arn` involved in the suspicious activity, as this will help identify the potentially compromised user or service account.
-- Examine the `target_time_window` to determine the exact 30-second period during which the unusual activity occurred, providing a precise timeframe for further investigation.
-- Analyze the `cloud.region` field to identify all regions where the `GetServiceQuota` API calls were made, which can help in understanding the scope of the potential reconnaissance.
-- Check the `window_count` to assess the total number of API calls made within the 30-second window, which can indicate the intensity of the activity.
-- Investigate the `aws.cloudtrail.user_identity.arn` in the AWS IAM console to verify the permissions and recent activity of the user or service account, looking for any anomalies or unauthorized changes.
-- Use AWS CloudTrail logs to trace back the source IP addresses associated with the `GetServiceQuota` API calls, which can help identify the origin of the requests.
-- Cross-reference the `aws.cloudtrail.user_identity.arn` with other recent CloudTrail logs to detect any other suspicious activities or patterns involving the same user or service account.
-- Utilize Osquery to gather additional context on the involved AWS resources. For example, run an Osquery query to list recent AWS API calls made by the same user or service account: `SELECT * FROM aws_cloudtrail_events WHERE user_identity_arn = '<aws.cloudtrail.user_identity.arn>' AND event_time BETWEEN '<start_time>' AND '<end_time>';`.
-- Investigate any recent changes to the AWS environment, such as new instance launches or configuration changes, that coincide with the timeframe of the alert, as these could be related to the suspicious activity.
-- Collaborate with the security team to correlate this alert with other security events or alerts, which may provide a broader context of a potential attack campaign or ongoing threat.
-
-### False positive analysis
-
-- Automated scripts or tools used by legitimate AWS administrators for infrastructure monitoring or management across multiple regions can trigger this rule. These tools might perform `GetServiceQuota` API calls as part of their routine checks.
-- Multi-region deployments by large organizations that frequently check service quotas to ensure compliance with internal policies or to optimize resource allocation can also result in false positives.
-- Scheduled tasks or cron jobs that run at specific intervals to gather quota information for reporting or auditing purposes might inadvertently match the rule's criteria.
-- To manage these false positives, users can create exceptions for known benign sources by excluding specific AWS Identity and Access Management (IAM) roles or user ARNs that are responsible for legitimate multi-region queries.
-- Implementing a whitelist of IP addresses or regions associated with trusted operations can help reduce noise from expected activities.
-- Regularly reviewing and updating the list of exceptions based on changes in organizational processes or infrastructure can help maintain the accuracy of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS account or instance to prevent further unauthorized access and limit potential damage.
-- Review CloudTrail logs to identify the source of the `GetServiceQuota` requests and determine if any other suspicious activities are associated with the same credentials or instance.
-- Revoke any compromised credentials and rotate access keys for the affected AWS account to prevent further unauthorized access.
-- Conduct a thorough investigation to determine if any malware or unauthorized software has been deployed on the affected instances, and remove any malicious components found.
-- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging and monitoring policies to capture detailed API activity, focusing on unusual patterns or access from unexpected regions.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Review and update AWS IAM policies to enforce the principle of least privilege, ensuring that users and services have only the permissions necessary for their roles.
-- Restore affected systems to their operational state by redeploying clean instances from known-good backups or images, ensuring that all security patches are applied.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as enabling multi-factor authentication (MFA) and using AWS Config to enforce compliance with security best practices."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
index 9f08cee9b9d..edd6adb3742 100644
--- a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
+++ b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS Lambda Layer Added to Existing Function"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS Lambda Layer Added to Existing Function
 
diff --git a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
index d2445998710..6dcc33f9728 100644
--- a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
+++ b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -49,48 +49,6 @@ query = '''
 event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and
     event.action: (CreateStack or CreateStackSet) and event.outcome:success
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Time AWS Cloudformation Stack Creation by User
-
-AWS CloudFormation automates the setup of cloud resources using templates, streamlining infrastructure management. Adversaries with access can exploit this to deploy malicious resources, escalating their control. The detection rule identifies unusual activity by flagging the initial use of stack creation APIs by a user, helping to spot potential unauthorized actions early.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific IAM user or role that triggered the alert by calling the `CreateStack` or `CreateStackSet` API.
-- Check the AWS CloudTrail logs for additional context around the event, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:cloudformation.amazonaws.com` fields to confirm the legitimacy of the action.
-- Investigate the `event.outcome:success` field to ensure the stack creation was successful and determine if any errors or anomalies were logged during the process.
-- Analyze the IAM policies and permissions associated with the user or role to verify if they have the necessary privileges to perform stack creation and assess if these permissions are excessive.
-- Examine the stack template used in the `CreateStack` or `CreateStackSet` action to identify the resources being provisioned and assess if they align with expected or authorized configurations.
-- Cross-reference the timing of the stack creation event with other logs and alerts to identify any correlated suspicious activities, such as unusual login attempts or privilege escalations.
-- Utilize Osquery to gather additional system-level information. For example, run an Osquery query to list recent AWS API calls made by the user: `SELECT * FROM aws_cloudtrail_events WHERE user_identity_arn = '<user_arn>' AND event_name IN ('CreateStack', 'CreateStackSet') ORDER BY event_time DESC LIMIT 10;`.
-- Investigate the geographical location and IP address from which the API call was made to determine if it aligns with known user activity patterns.
-- Review any recent changes to the AWS environment, such as modifications to security groups or network configurations, that could be related to the stack creation.
-- Consult with the user or team responsible for the account to verify if the stack creation was an expected action and gather any additional context or documentation related to the event.
-
-### False positive analysis
-
-- New legitimate projects or services: When a new project or service is initiated, legitimate users may create CloudFormation stacks for the first time, triggering the rule. To manage this, users can create exceptions for known projects or services by tagging these activities and excluding them from the rule.
-- Onboarding of new team members: New team members with appropriate permissions may trigger the rule when they first use CloudFormation. To handle this, maintain a list of new users and temporarily exclude their activities from the rule until their behavior is established as non-threatening.
-- Automated deployment tools: Some automated tools or scripts may use CloudFormation to deploy resources, appearing as a first-time use by a user. Users can identify these tools and exclude their activities by recognizing specific patterns or tags associated with the tool.
-- Testing and development environments: Activities in testing or development environments may trigger the rule. Users can exclude these environments by filtering based on environment-specific tags or account IDs to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS account to prevent further unauthorized access or resource creation.
-- Review CloudTrail logs to identify the source and scope of the unauthorized stack creation, focusing on the user or role involved.
-- Revoke or adjust IAM permissions for the user or role that initiated the stack creation to prevent further misuse.
-- Investigate the created resources for any malicious configurations or data exfiltration mechanisms and remove them if necessary.
-- Escalate the incident to the security operations team for a deeper investigation and to assess potential impacts on other systems.
-- Implement enhanced logging and monitoring for AWS CloudFormation and related services to detect similar activities in the future.
-- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities.
-- Conduct a post-incident review to identify gaps in security controls and update IAM policies to enforce the principle of least privilege.
-- Restore any affected systems or data from backups, ensuring that the restored state is free from unauthorized changes.
-- Educate users and administrators on secure AWS practices and the importance of monitoring for unusual activities, leveraging MITRE ATT&CK framework insights for threat awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
index 81e0458229c..6062fe1ad86 100644
--- a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
+++ b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SSM Command Document Created by Rare User"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS SSM Command Document Created by Rare User
 
diff --git a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
index 58e6c1d5b61..4f860173b1c 100644
--- a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
+++ b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/05"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SSM `SendCommand` Execution by Rare User"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS SSM `SendCommand` Execution by Rare User
 
diff --git a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
index 1a4feac937c..bc1ecf1dadb 100644
--- a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "EC2 AMI Shared with Another Account"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating EC2 AMI Shared with Another Account
 
diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
index d7329dfa0af..926072b8026 100644
--- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/02"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ license = "Elastic License v2"
 name = "AWS EC2 EBS Snapshot Shared with Another Account"
 note = """
 
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS EC2 EBS Snapshot Shared with Another Account
 
diff --git a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
index 07b73c9da4d..e809fcaf22f 100644
--- a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
+++ b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -24,50 +24,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Full Network Packet Capture Detected"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 Full Network Packet Capture Detected
-
-Traffic Mirroring in AWS EC2 allows the duplication of network traffic from an Elastic Network Interface for monitoring and analysis. While beneficial for diagnostics, adversaries can exploit this to siphon off unencrypted data. The detection rule identifies successful creation events of traffic mirroring components, signaling potential misuse for data exfiltration.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to identify the user or role associated with the creation of traffic mirroring components by examining the `user.identity.arn` field.
-- Check the `sourceIPAddress` field in the CloudTrail logs to determine the origin of the request, which can help identify if the request was made from an unusual or unauthorized location.
-- Analyze the `event.time` field to establish a timeline of when the traffic mirroring components were created, which can help correlate with other suspicious activities.
-- Investigate the `eventName` field to confirm which specific traffic mirroring component was created (e.g., `CreateTrafficMirrorFilter`, `CreateTrafficMirrorFilterRule`, `CreateTrafficMirrorSession`, or `CreateTrafficMirrorTarget`).
-- Use Osquery to query the AWS EC2 instance metadata and configuration for any unusual changes or configurations. Example query: `SELECT * FROM ec2_instance_metadata WHERE key = 'instance-id';`
-- Examine the `event.outcome` field to ensure the creation event was successful, confirming that the traffic mirroring components are active.
-- Cross-reference the `awsRegion` field to verify if the traffic mirroring activity is occurring in an expected region or if it is happening in a region that is not typically used by your organization.
-- Investigate the `requestParameters` field to gather more details about the configuration of the traffic mirroring components, such as the target and session settings.
-- Check for any other related CloudTrail events around the same timeframe that might indicate additional suspicious activities, such as changes to security groups or IAM policies.
-- Review network traffic logs and flow logs for the mirrored traffic to identify any unusual data patterns or potential data exfiltration attempts.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate network monitoring activities by security teams can trigger this detection. Regularly scheduled traffic mirroring for performance analysis or troubleshooting may appear as suspicious but are benign.
-- Automated infrastructure management: Automated scripts or tools that manage AWS resources might create traffic mirroring components as part of their operations. These should be reviewed to ensure they align with expected behavior.
-- Development and testing environments: In non-production environments, developers might use traffic mirroring to test network configurations or application performance, leading to false positives.
-- To manage these false positives, users can create exceptions for known IP addresses or AWS accounts that regularly perform legitimate traffic mirroring. Additionally, tagging resources with specific identifiers for approved activities can help in filtering out non-threatening events.
-
-### Response and remediation
-
-- Immediately isolate the affected EC2 instance to prevent further data exfiltration by disabling the traffic mirroring session.
-- Review CloudTrail logs to identify the source and scope of the traffic mirroring creation events, focusing on the user or service account responsible.
-- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated during the traffic mirroring session.
-- Change credentials and access keys for any compromised accounts and review IAM policies to ensure least privilege access is enforced.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement network segmentation to limit the exposure of sensitive data and reduce the risk of unauthorized traffic mirroring.
-- Enable encryption for all sensitive data in transit to mitigate the risk of data exfiltration through unencrypted traffic.
-- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and analysis.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply hardening measures such as disabling unused services, regularly updating software, and conducting security awareness training for users.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
index c501710147d..6b99a4eed46 100644
--- a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
+++ b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,50 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 VM Export Failure"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 VM Export Failure
-
-AWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, aligning with MITRE ATT&CK's exfiltration tactics.
-
-### Possible investigation steps
-
-- Review the specific CloudTrail event details associated with the failed export attempt, focusing on the `event.dataset`, `event.provider`, `event.action`, and `event.outcome` fields to confirm the nature of the failure.
-- Identify the IAM user or role (`userIdentity.arn`) that initiated the failed export task to determine if the action was performed by an authorized entity.
-- Check the source IP address (`sourceIPAddress`) and user agent (`userAgent`) associated with the failed export attempt to identify any unusual access patterns or locations.
-- Investigate the EC2 instance details (`requestParameters.instanceId`) involved in the export attempt to understand the potential sensitivity of the data within the instance.
-- Examine the AWS account activity logs for any other suspicious actions or patterns around the time of the failed export attempt to identify potential coordinated activities.
-- Use Osquery to gather additional context on the EC2 instance by running a query such as: `SELECT * FROM ec2_instance_metadata WHERE instance_id = '<instance_id>';` to retrieve metadata and assess the instance's configuration and network settings.
-- Analyze the CloudTrail logs for any successful export attempts or other related actions by the same IAM user or role to identify potential previous exfiltration activities.
-- Review the permissions and policies associated with the IAM user or role to ensure they align with the principle of least privilege and do not allow unauthorized export actions.
-- Correlate the failed export attempt with any recent changes in the AWS environment, such as new IAM policies or changes in network configurations, to identify potential misconfigurations.
-- Consult with relevant stakeholders or system owners to verify the legitimacy of the export attempt and gather additional context on the business need or lack thereof for such an action.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate export attempts by system administrators for backup or migration purposes may trigger the rule. Users can handle these by creating exceptions for known administrator accounts or specific time windows when such tasks are scheduled.
-- Testing and development activities: Developers or IT staff may export VMs as part of testing or development processes. To manage these, users can exclude specific development accounts or tags associated with test environments.
-- Automated backup solutions: Some organizations use automated tools that periodically export VMs for backup. Users should identify and exclude these tools by their associated IAM roles or service accounts to prevent false positives.
-- Misconfigured export tasks: Failed export attempts due to misconfigurations or permission issues might be flagged. Users can review and adjust IAM policies or export configurations to ensure legitimate tasks are not mistakenly identified as threats.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS account to prevent further unauthorized export attempts by restricting permissions and access.
-- Review AWS CloudTrail logs to identify the source of the failed export attempt, including the user or service account involved, and assess if there are any other suspicious activities.
-- Verify the integrity of the EC2 instances involved in the export attempt to ensure no data has been altered or exfiltrated.
-- Change credentials and access keys for any compromised accounts to prevent further unauthorized access.
-- Escalate the incident to the security operations team for a thorough investigation and to determine if the attempt is part of a larger attack.
-- Implement stricter IAM policies to limit export permissions to only trusted and necessary accounts, reducing the risk of unauthorized export attempts.
-- Enhance logging and monitoring by enabling detailed CloudTrail logging and integrating with a SIEM solution for real-time alerting and analysis.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Restore any affected systems to their operational state by verifying configurations and ensuring all security patches are applied.
-- Implement hardening measures such as multi-factor authentication, regular audits of access permissions, and continuous security training for users to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance"]
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
index d6c4526f36e..3acc55c151f 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,52 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Snapshot Export"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS Snapshot Export
-
-Amazon RDS allows users to create snapshots of their databases, which can be exported for backup or migration. Adversaries may exploit this feature to exfiltrate sensitive data by exporting snapshots to external locations. The detection rule monitors successful initiation of snapshot export tasks, flagging potential unauthorized data transfers by correlating specific CloudTrail events related to RDS operations.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to confirm the `event.action:StartExportTask` and `event.outcome:success` to ensure the snapshot export task was successfully initiated.
-- Identify the `userIdentity` field in the CloudTrail event to determine which IAM user or role initiated the snapshot export.
-- Check the `sourceIPAddress` field to verify the IP address from which the export task was initiated, and assess if it aligns with known and expected IP addresses.
-- Examine the `eventTime` field to establish the timeline of the export task and correlate it with other activities in the environment.
-- Investigate the `requestParameters` field to gather details about the specific RDS snapshot being exported, including the database identifier and snapshot name.
-- Analyze the `responseElements` field to confirm the destination of the exported snapshot and ensure it aligns with authorized S3 buckets or external locations.
-- Use Osquery to query AWS RDS configurations and permissions, for example: `SELECT * FROM aws_rds_instances WHERE instance_id = '<instance_id>'` to verify the instance details and associated permissions.
-- Cross-reference the IAM user or role with AWS IAM policies to ensure that the permissions granted are appropriate and do not allow unauthorized export actions.
-- Review recent changes in IAM policies or roles that might have inadvertently allowed the snapshot export, focusing on the `eventName:PutRolePolicy` or `eventName:AttachRolePolicy` in CloudTrail logs.
-- Investigate any other related CloudTrail events around the same `eventTime` to identify potential lateral movement or other suspicious activities that could indicate a broader security incident.
-
-### False positive analysis
-
-- Routine database maintenance or migration activities by authorized personnel can trigger the AWS RDS Snapshot Export rule, leading to false positives. 
-- Scheduled exports for backup purposes, especially in organizations with automated backup policies, may also be flagged as suspicious.
-- Development and testing environments often involve frequent snapshot exports, which can be mistaken for unauthorized activities.
-- To manage these false positives, users can create exceptions for known and scheduled export tasks by whitelisting specific IAM roles or user accounts responsible for legitimate exports.
-- Implementing tagging strategies for RDS instances and snapshots can help differentiate between routine operations and potential threats, allowing for more precise filtering in detection rules.
-- Regularly review and update the list of approved export tasks and associated personnel to ensure that only legitimate activities are excluded from alerts.
-
-### Response and remediation
-
-- Immediately verify the legitimacy of the snapshot export by contacting the database owner or relevant stakeholders to confirm if the action was authorized.
-- If unauthorized, revoke any temporary credentials or access keys that may have been used to initiate the export task.
-- Isolate the affected RDS instance by restricting network access and applying security groups to prevent further unauthorized actions.
-- Review CloudTrail logs and other relevant logs to identify any suspicious activities or patterns leading up to the export task.
-- Conduct a thorough investigation to determine the scope of the data exfiltration, including identifying any other compromised resources or accounts.
-- Escalate the incident to the security operations team and, if necessary, involve legal and compliance teams to assess potential data breach implications.
-- Restore the database from a known good snapshot or backup if data integrity is suspected to be compromised.
-- Implement enhanced logging and monitoring policies, such as enabling AWS Config and GuardDuty, to detect and alert on similar activities in the future.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export snapshots.
-- Conduct a post-incident review to identify gaps in the current security posture and apply hardening measures, such as multi-factor authentication and regular security training for users.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartExportTask.html"]
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
index c0031febfca..20d686e65be 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/06"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Snapshot Shared with Another Account"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS RDS DB Snapshot Shared with Another Account
 
@@ -81,7 +81,7 @@ query = '''
 any where event.dataset == "aws.cloudtrail"
     and event.provider == "rds.amazonaws.com"
     and event.outcome == "success"
-    and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute")
+    and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute") 
     and stringContains(aws.cloudtrail.request_parameters, "attributeName=restore")
     and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]")
 '''
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
index 8ff65c6ebbc..814222060d1 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Policy Added to Share with External Account"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS S3 Bucket Policy Change to Share with External Account
 
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
index 11b5f5d081e..1939fa0d9ec 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/12"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Replicated to Another Account"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS S3 Bucket Replicated to Another Account
 
@@ -73,9 +73,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+any where event.dataset == "aws.cloudtrail" 
    and event.action == "PutBucketReplication"
-   and event.outcome == "success"
+   and event.outcome == "success" 
    and stringContains(aws.cloudtrail.request_parameters, "Account")
 '''
 
diff --git a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
index 43d3d92d2cb..256caac2f0b 100644
--- a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
+++ b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SNS Email Subscription by Rare User"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS SNS Email Subscription by Rare User
 
diff --git a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
index 0c4ca32eb59..4dced14d748 100644
--- a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
+++ b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EventBridge Rule Disabled or Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EventBridge Rule Disabled or Deleted
-
-AWS EventBridge is a serverless event bus service that enables applications to respond to changes in data. Disabling or deleting rules can disrupt event-driven workflows, potentially masking malicious activities. Adversaries might exploit this by halting critical alerts or data flows. The detection rule monitors for successful disablement or deletion actions, signaling potential misuse or configuration tampering.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to identify the user or role associated with the `DeleteRule` or `DisableRule` actions by examining the `user.identity.arn` field.
-- Check the `event.time` field in the CloudTrail logs to determine the exact time the rule was disabled or deleted, and correlate this with other activities in the AWS account around the same time.
-- Investigate the `event.sourceIPAddress` field to identify the source IP address from which the action was initiated, and determine if it is a known or expected address.
-- Examine the `event.requestParameters` field to identify the specific EventBridge rule that was disabled or deleted, and assess its importance in the event-driven architecture.
-- Use AWS CloudTrail insights to detect any unusual activity patterns or anomalies associated with the user or role that performed the action.
-- Cross-reference the `event.userAgent` field to understand the tool or service used to perform the action, which might provide additional context about the method of access.
-- Utilize Osquery to query AWS API logs for any other suspicious activities related to EventBridge. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('DeleteRule', 'DisableRule') AND eventSource = 'eventbridge.amazonaws.com';`
-- Investigate any recent IAM policy changes that might have granted new permissions to the user or role involved, which could indicate privilege escalation.
-- Review the AWS Config history for the EventBridge rule to understand its previous state and any recent changes that might have led to its disablement or deletion.
-- Check for any associated CloudWatch alarms or logs that might have been affected by the rule's disablement or deletion, to assess the potential impact on monitoring and alerting.
-
-### False positive analysis
-
-- Routine maintenance or updates: Scheduled maintenance activities or updates by authorized personnel may involve disabling or deleting EventBridge rules temporarily. These actions, while legitimate, can trigger alerts. Users can manage these by creating exceptions for known maintenance windows or by whitelisting actions performed by specific IAM roles or users responsible for maintenance.
-- Development and testing environments: In non-production environments, developers might frequently disable or delete rules as part of testing new features or configurations. To reduce noise, users can exclude events originating from specific AWS accounts or regions designated for development and testing.
-- Automated workflows: Some automated processes or third-party tools might disable or delete rules as part of their normal operation. Users should identify these tools and create exceptions for their actions, ensuring that only expected and documented automated changes are excluded.
-- Organizational policy changes: Changes in organizational policies might require temporary suspension of certain rules. Users should document these policy-driven changes and adjust detection rules to account for them, possibly by excluding actions taken by specific policy enforcement tools or teams.
-
-### Response and remediation
-
-- Immediately review CloudTrail logs to identify the user or service account responsible for disabling or deleting the EventBridge rule and verify if the action was authorized.
-- Contain the potential threat by temporarily revoking permissions for the identified user or service account to prevent further unauthorized actions.
-- Investigate the context and intent behind the rule modification by checking related activities in CloudTrail and other AWS services to determine if it is part of a larger attack pattern.
-- Restore the disabled or deleted EventBridge rule from backups or recreate it based on the last known good configuration to resume normal operations.
-- Escalate the incident to the security operations team if unauthorized activity is confirmed, and involve relevant stakeholders for a coordinated response.
-- Implement AWS CloudWatch alarms to monitor for future disablement or deletion of critical EventBridge rules to ensure timely detection of similar incidents.
-- Enhance logging policies by enabling detailed logging for EventBridge and related AWS services to improve visibility and facilitate future investigations.
-- Integrate AWS Security Hub or a similar security information and event management (SIEM) tool to centralize alerts and streamline incident response processes.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address identified weaknesses.
-- Apply hardening measures by enforcing least privilege access, using AWS Identity and Access Management (IAM) roles with strict permissions, and regularly reviewing access policies to minimize the risk of unauthorized actions.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
index 8ae09533df0..06305eb8968 100644
--- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
+++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,51 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Encryption Disabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 Encryption Disabled
-
-Amazon EC2's EBS encryption ensures data at rest is secure by default. Disabling this feature can expose sensitive data, making it vulnerable to unauthorized access. Adversaries might exploit this by disabling encryption to manipulate or exfiltrate data without detection. The detection rule monitors CloudTrail logs for successful attempts to disable EBS encryption, alerting analysts to potential security breaches.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to confirm the event by filtering for `event.dataset:aws.cloudtrail` and `event.provider:ec2.amazonaws.com` to ensure the event is related to EC2 actions.
-- Verify the specific action by checking `event.action:DisableEbsEncryptionByDefault` to confirm that the alert was triggered by an attempt to disable EBS encryption by default.
-- Check the `event.outcome:success` field to ensure that the action was successfully executed, indicating a potential security concern.
-- Identify the IAM user or role responsible for the action by examining the `user.identity.arn` field in the CloudTrail logs to determine if the action was authorized or potentially malicious.
-- Investigate the source IP address and location by reviewing the `sourceIPAddress` field to identify any unusual or unauthorized access patterns.
-- Cross-reference the timestamp of the event with other logs and alerts to identify any correlated activities or anomalies around the same time.
-- Use Osquery to gather additional context on the instance involved. For example, run the following Osquery query to list all EC2 instances and their encryption status: `SELECT instance_id, block_device_mapping FROM ec2_instance WHERE region = 'your-region';`
-- Analyze the historical activity of the IAM user or role involved by reviewing past CloudTrail logs to identify any patterns of suspicious behavior or previous attempts to disable encryption.
-- Check for any recent changes in IAM policies or permissions that might have allowed the user or role to disable EBS encryption by default.
-- Collaborate with the AWS account management team to verify if the action was part of a legitimate change request or if it requires further investigation.
-
-### False positive analysis
-
-- Routine administrative actions: In some cases, disabling EBS encryption by default may be part of regular maintenance or configuration changes performed by authorized personnel. Users should verify if the action aligns with scheduled tasks or approved change requests.
-- Testing and development environments: Developers might disable encryption in non-production environments for testing purposes. It's important to differentiate between production and non-production activities to avoid unnecessary alerts.
-- Automated scripts or tools: Some automation tools or scripts might disable encryption as part of their setup process. Users should review and whitelist these tools if they are deemed non-threatening.
-- Regional configuration changes: Changes in regional settings might trigger this alert. Users should ensure that such changes are intentional and documented, and consider excluding these events if they are part of a known process.
-- To manage false positives, users can create exceptions or filters in their monitoring systems to exclude known non-threatening behaviors, ensuring that alerts are only generated for unexpected or unauthorized actions.
-
-### Response and remediation
-
-- Immediately isolate the affected EC2 instances to prevent further unauthorized access or data manipulation.
-- Review CloudTrail logs to identify the user or service account responsible for disabling EBS encryption and assess their activity for any other suspicious actions.
-- Re-enable EBS encryption by default in the affected region to ensure future volumes are encrypted.
-- Conduct a thorough investigation of the affected volumes to determine if any data manipulation or exfiltration has occurred.
-- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are needed.
-- Implement AWS Config rules to continuously monitor and alert on changes to EBS encryption settings.
-- Enhance logging policies by ensuring that all relevant AWS services are logging to CloudTrail and that logs are retained for an appropriate period.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
-- Restore any manipulated data from backups, ensuring that restored data is encrypted and secure.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized users can modify encryption settings.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
index fe60165fc75..289a125097f 100644
--- a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
+++ b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,50 +24,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EFS File System or Mount Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EFS File System or Mount Deleted
-
-Amazon Elastic File System (EFS) provides scalable file storage for use with AWS cloud services and on-premises resources. Adversaries may exploit EFS by deleting file systems or mount targets, disrupting applications reliant on these resources. The detection rule identifies successful deletion events, signaling potential malicious activity by monitoring specific AWS CloudTrail logs for actions like DeleteMountTarget or DeleteFileSystem.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:elasticfilesystem.amazonaws.com` fields to ensure the alert is valid and not a false positive.
-- Examine the `event.action` field to determine whether the action was `DeleteMountTarget` or `DeleteFileSystem`, as this will help identify the specific resource affected.
-- Check the `event.outcome:success` field to verify that the deletion action was completed successfully, confirming the potential impact on resources.
-- Identify the AWS account and user or role responsible for the deletion by reviewing the `userIdentity` field in the CloudTrail logs to determine if the action was authorized or potentially malicious.
-- Investigate the `sourceIPAddress` field to trace the origin of the request, which can help identify if the action was performed from a known or suspicious location.
-- Use Osquery to gather additional context on the affected EFS resources by running a query such as: `SELECT * FROM aws_efs_file_systems WHERE file_system_id = '<affected_file_system_id>';` to retrieve details about the deleted file system.
-- Cross-reference the deletion event with recent IAM policy changes or access logs to identify any unusual modifications that might have enabled unauthorized access.
-- Review recent activity logs for the affected EFS resources to identify any preceding actions or patterns that could indicate a broader attack or misconfiguration.
-- Check for any associated alerts or incidents in your security information and event management (SIEM) system that might correlate with the EFS deletion event, providing additional context or evidence of malicious activity.
-- Consult with relevant stakeholders or application owners to assess the impact of the deletion on business operations and gather any additional insights or suspicions they might have regarding the event.
-
-### False positive analysis
-
-- Routine maintenance activities: Scheduled maintenance or updates by system administrators may involve deleting and recreating EFS file systems or mount targets. Users can handle these by creating exceptions for known maintenance windows or specific administrator actions.
-- Automated scaling operations: In environments with automated scaling, EFS resources might be programmatically deleted and recreated to optimize resource usage. Users should identify and exclude these automated processes from triggering alerts by using tags or specific identifiers.
-- Development and testing environments: In non-production environments, frequent creation and deletion of EFS resources for testing purposes can trigger false positives. Users can manage this by excluding specific accounts or environments dedicated to development and testing.
-- CloudFormation or other infrastructure as code tools: When using tools like AWS CloudFormation, EFS resources might be deleted as part of stack updates or deletions. Users should consider excluding actions initiated by these tools by filtering based on user agents or specific IAM roles associated with these operations.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further damage or data loss.
-- Verify the deletion event by cross-referencing with AWS CloudTrail logs to confirm unauthorized activity.
-- Conduct a thorough investigation to identify the source and method of the attack, focusing on compromised credentials or misconfigurations.
-- Restore the deleted EFS file system or mount from the most recent backup to minimize downtime and data loss.
-- Implement AWS Identity and Access Management (IAM) policies to restrict permissions, ensuring only authorized users can delete EFS resources.
-- Enable detailed logging and monitoring for AWS EFS and related services to detect and respond to future unauthorized activities promptly.
-- Integrate AWS CloudTrail logs with a Security Information and Event Management (SIEM) system for enhanced threat detection and analysis.
-- Escalate the incident to the security team and relevant stakeholders, providing them with detailed findings and impact assessments.
-- Review and update the incident response plan to incorporate lessons learned and improve future response efforts.
-- Apply hardening measures such as multi-factor authentication (MFA) and regular security audits to reduce the risk of similar incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml
index 92a11153d77..97463e97775 100644
--- a/rules/integrations/aws/impact_iam_group_deletion.toml
+++ b/rules/integrations/aws/impact_iam_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS IAM Group Deletion
-
-AWS IAM groups facilitate efficient management of user permissions by organizing users with similar access needs. Adversaries may exploit group deletion to disrupt access controls, potentially hindering legitimate user activities. The detection rule monitors successful group deletions via AWS CloudTrail logs, flagging potential unauthorized access removal activities aligned with MITRE ATT&CK's impact tactics.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail`, `event.provider:iam.amazonaws.com`, and `event.action:DeleteGroup` fields to ensure the alert is valid.
-- Identify the IAM user or role responsible for the group deletion by examining the `userIdentity` field in the CloudTrail logs.
-- Check the `event.time` field to determine when the group deletion occurred and correlate this with any other suspicious activities around the same time.
-- Investigate the `sourceIPAddress` field to identify the origin of the request and determine if it aligns with known IP addresses or locations for legitimate users.
-- Review the `userAgent` field to understand the method used for deletion (e.g., AWS Management Console, AWS CLI) and assess if it matches typical usage patterns.
-- Examine the IAM policies and permissions associated with the user or role that performed the deletion to determine if they had the necessary permissions and if those permissions are appropriate.
-- Use Osquery to gather additional context on the IAM group deletion by running a query such as: `SELECT * FROM aws_iam_groups WHERE group_name = 'DeletedGroupName';` to verify if the group was recreated or if there are any related changes.
-- Check for any recent changes to IAM policies or roles that might have inadvertently allowed unauthorized group deletions.
-- Investigate other IAM activities by the same user or role around the time of the deletion to identify any patterns or additional unauthorized actions.
-- Review any recent security alerts or incidents involving the affected AWS account to determine if the group deletion is part of a larger security event.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IAM group deletions may occur during regular maintenance or restructuring of AWS resources, where administrators remove outdated or unnecessary groups. 
-- Automated scripts or tools: Organizations may use automated processes to manage IAM groups, leading to frequent deletions that are non-threatening.
-- Testing environments: In development or testing environments, IAM groups may be created and deleted frequently as part of testing procedures.
-- To manage these false positives, users can create exceptions for known administrative accounts or scripts that regularly perform these actions, ensuring that alerts are only triggered for unexpected deletions.
-
-### Response and remediation
-
-- Immediately review AWS CloudTrail logs to confirm the deletion of the IAM group and identify the user or service responsible for the action.
-- Verify if the group deletion was authorized by checking with the IAM administrators or reviewing change management records.
-- If unauthorized, disable the IAM user or role responsible for the deletion to prevent further unauthorized actions.
-- Restore the deleted IAM group by recreating it and reassigning the necessary permissions and users based on the last known configuration.
-- Conduct a thorough investigation to determine if any other IAM resources or permissions were altered or deleted.
-- Escalate the incident to the security operations team for further analysis and to determine if there is a broader security breach.
-- Implement enhanced logging and monitoring for IAM activities, ensuring that all critical actions are captured and reviewed regularly.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have permissions to delete IAM groups.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
index 6965a5b2d0c..11c2d13335e 100644
--- a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
+++ b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Xavier Pich"]
@@ -25,50 +25,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS KMS Customer Managed Key Disabled or Scheduled for Deletion
-
-AWS KMS Customer Managed Keys (CMKs) are crucial for encrypting sensitive data. Disabling or scheduling their deletion can lead to irreversible data loss, as encrypted data becomes inaccessible. Adversaries may exploit this to destroy data or disrupt operations. The detection rule monitors successful disablement or deletion attempts, alerting security teams to potential malicious activities targeting data integrity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `kms.amazonaws.com`, ensuring the alert is related to AWS KMS activities.
-- Verify the event action is either `DisableKey` or `ScheduleKeyDeletion` and that the event outcome is `success` to confirm the key was successfully disabled or scheduled for deletion.
-- Identify the specific AWS KMS Customer Managed Key (CMK) involved by examining the key ID or ARN in the event details.
-- Check the CloudTrail logs for the user identity or role that initiated the action to determine if it was an authorized user or a potential compromise.
-- Investigate the time and date of the event to correlate with any other suspicious activities or changes in the AWS environment.
-- Use AWS CloudTrail to review the history of actions taken on the affected CMK to identify any previous suspicious or unauthorized activities.
-- Examine IAM policies and permissions associated with the user or role to ensure they have the appropriate level of access and no excessive permissions.
-- Utilize Osquery to gather additional context on the AWS environment. For example, run a query to list all KMS keys and their current status: `SELECT * FROM aws_kms_keys WHERE key_state IN ('Disabled', 'PendingDeletion');`
-- Check for any recent changes in IAM roles, policies, or configurations that could have allowed unauthorized access to the KMS key.
-- Collaborate with the AWS account owner or security team to verify if the action was part of a planned operation or if it indicates a potential security incident.
-
-### False positive analysis
-
-- Routine maintenance activities: Organizations may have scheduled tasks or maintenance activities that involve disabling or scheduling the deletion of KMS keys as part of their lifecycle management. These actions, while legitimate, can trigger alerts. To manage this, users can create exceptions for specific keys or timeframes when these activities are expected.
-- Automated processes: Some automated systems or scripts might disable or schedule the deletion of KMS keys as part of their normal operation, such as rotating keys or decommissioning resources. Users should identify these processes and exclude them from alerts by specifying the associated user or service accounts.
-- Testing environments: In testing or development environments, disabling or scheduling the deletion of KMS keys might be a common practice to simulate scenarios or test recovery processes. Users can exclude these environments from alerts by filtering based on environment tags or resource identifiers.
-- Misconfigured alerts: Sometimes, alerts may be triggered due to misconfigured monitoring rules or incorrect tagging of resources. Users should review and adjust their alert configurations to ensure they accurately reflect the organization's security policies and operational practices.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS account or resources to prevent further unauthorized actions.
-- Review CloudTrail logs to identify the source and scope of the disablement or deletion attempt, focusing on user identity, IP address, and time of the event.
-- Verify if the disablement or deletion was authorized by cross-referencing with change management records or contacting the responsible team.
-- If unauthorized, revoke any compromised credentials and enforce a password reset for affected accounts.
-- Restore any disabled keys by re-enabling them if within the allowed recovery period, or initiate data recovery procedures if keys were deleted.
-- Escalate the incident to the security operations center (SOC) for further investigation and potential legal action if malicious intent is confirmed.
-- Implement AWS CloudTrail and AWS Config rules to continuously monitor and alert on key management activities.
-- Enhance logging policies to include detailed audit trails and integrate with a Security Information and Event Management (SIEM) system for real-time analysis.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply hardening measures such as enforcing multi-factor authentication (MFA) for all users and restricting key management permissions to a minimal set of trusted administrators.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_group_deletion.toml b/rules/integrations/aws/impact_rds_group_deletion.toml
index 1b510ba00e4..989081659af 100644
--- a/rules/integrations/aws/impact_rds_group_deletion.toml
+++ b/rules/integrations/aws/impact_rds_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,54 +21,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Security Group Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS Security Group Deletion
-
-Amazon RDS Security Groups control access to RDS instances, acting as a firewall to manage inbound traffic. Adversaries may delete these groups to disrupt database security, potentially leading to unauthorized access or data breaches. The detection rule monitors successful deletion events in AWS CloudTrail logs, identifying potential misuse by correlating specific actions and outcomes, thus alerting analysts to investigate further.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the `event.action:DeleteDBSecurityGroup` and `event.outcome:success` fields to ensure the alert is valid and corresponds to a successful deletion event.
-- Identify the `userIdentity` field in the CloudTrail logs to determine which IAM user or role performed the deletion action.
-- Check the `sourceIPAddress` field to verify the IP address from which the deletion request originated, and assess if it aligns with known or expected IP addresses.
-- Investigate the `eventTime` field to establish the exact time of the deletion and correlate it with any other suspicious activities or alerts around the same timeframe.
-- Examine the `requestParameters` field to identify which specific RDS Security Group was deleted and assess its importance and impact on the environment.
-- Utilize Osquery to gather additional context on the AWS environment. For example, run a query to list all current RDS instances and their associated security groups to understand the current security posture:
-  ```sql
-  SELECT * FROM aws_rds_instances;
-  ```
-- Cross-reference the IAM user or role identified with recent IAM activity logs to check for any unusual or unauthorized access patterns or privilege escalations.
-- Review AWS CloudTrail logs for any recent `CreateDBSecurityGroup` or `ModifyDBSecurityGroup` actions to determine if there were any recent changes or creations that might relate to the deletion.
-- Investigate any recent changes to IAM policies or roles that might have inadvertently granted permissions to delete RDS Security Groups.
-- Check for any other alerts or anomalies in the AWS environment that might indicate a broader security incident or compromise.
-
-### False positive analysis
-
-- Routine maintenance or infrastructure changes by authorized personnel can trigger the AWS RDS Security Group Deletion rule, leading to false positives. 
-- Automated scripts or tools used for managing RDS instances might delete security groups as part of their normal operation, which could be misinterpreted as malicious activity.
-- To manage these false positives, users can create exceptions for specific IAM roles or users known to perform regular maintenance tasks, ensuring that alerts are only generated for unexpected deletions.
-- Implementing a whitelist of known, non-threatening actions or users can help reduce noise and focus on genuine threats.
-- Regularly review and update the list of exceptions to ensure it reflects current operational practices and does not inadvertently exclude suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected RDS instance by modifying its security group to restrict all inbound and outbound traffic.
-- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess if it was authorized.
-- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected accounts to prevent further unauthorized actions.
-- Restore the deleted RDS security group from a backup or recreate it with the same rules to ensure continued protection of the database.
-- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration occurred during the period of exposure.
-- Escalate the incident to the security operations team and notify relevant stakeholders, including data protection officers, if sensitive data is involved.
-- Implement enhanced logging and monitoring policies to capture detailed access and modification events for RDS security groups.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized personnel can modify RDS security groups.
-- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as enabling multi-factor authentication (MFA) for all administrative access.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html"]
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
index 2b9330dd5fc..8648fe43465 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,52 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Deletion of RDS Instance or Cluster"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Deletion of RDS Instance or Cluster
-
-Amazon RDS is a managed service that simplifies database setup, operation, and scaling. Adversaries may exploit this by deleting RDS instances or clusters to disrupt services or destroy data, aligning with data destruction tactics. The detection rule monitors AWS CloudTrail logs for successful deletion actions, alerting security teams to potential malicious activity targeting RDS resources.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset`, `event.provider`, `event.action`, and `event.outcome` fields to ensure the alert is valid and corresponds to a successful deletion action.
-- Identify the user or role responsible for the deletion by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by an authorized entity or potentially compromised credentials.
-- Check the `sourceIPAddress` and `userAgent` fields in the CloudTrail logs to gather information about the origin of the request, which can help identify if the action was performed from an unusual location or device.
-- Investigate the `requestParameters` field to understand the specific RDS instance or cluster that was deleted, including its name and any associated tags, to assess the impact of the deletion.
-- Cross-reference the deletion event with recent IAM activity logs to identify any unusual permission changes or role assignments that could have facilitated unauthorized access.
-- Utilize Osquery to query the AWS environment for recent changes in IAM policies or roles that might have allowed the deletion. Example query: `SELECT * FROM aws_iam_policies WHERE action = 'rds:DeleteDBInstance' OR action = 'rds:DeleteDBCluster';`
-- Examine the AWS Config history for the deleted RDS instance or cluster to gather information on its configuration and any recent changes that might indicate a precursor to the deletion.
-- Review any recent AWS CloudWatch alarms or logs for anomalies or alerts related to the RDS instance or cluster prior to its deletion, which might provide context or indicate a broader attack.
-- Check for any correlated events in the AWS environment, such as EC2 instance terminations or S3 bucket deletions, that might suggest a coordinated attack or broader impact.
-- Consult with the database and application teams to verify if the deletion was part of a planned maintenance or decommissioning activity, ensuring alignment with organizational processes and avoiding false positives.
-
-### False positive analysis
-
-- Routine maintenance or infrastructure updates by authorized personnel can trigger alerts when RDS instances or clusters are intentionally deleted as part of scheduled tasks. 
-- Automated scripts or cloud management tools that manage database lifecycles might delete RDS resources as part of their normal operation, leading to false positives.
-- Development or testing environments often involve frequent creation and deletion of RDS instances, which can be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for specific IAM roles or users known to perform regular maintenance or development tasks.
-- Implementing tagging policies for RDS resources can help differentiate between production and non-production environments, allowing for more precise alerting and exclusion rules.
-- Regularly review and update the list of known benign activities and authorized personnel to ensure that the detection rule remains effective without generating unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further unauthorized access or data loss.
-- Verify the deletion event by cross-referencing with internal change management records to confirm if it was authorized.
-- Conduct a thorough investigation using AWS CloudTrail logs to identify the source and method of the deletion action.
-- Restore the deleted RDS instance or cluster from the latest backup to minimize data loss and service disruption.
-- Review and update IAM policies to ensure least privilege access, reducing the risk of unauthorized deletions.
-- Implement enhanced logging and monitoring for RDS activities, ensuring all actions are captured and reviewed regularly.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerting and analysis.
-- Escalate the incident to the security team and relevant stakeholders if malicious intent is suspected, following the organization's incident response plan.
-- Conduct a post-incident review to identify gaps in security controls and update incident response procedures accordingly.
-- Apply hardening measures such as enabling Multi-Factor Authentication (MFA) for all users with access to RDS resources and regularly reviewing access logs for suspicious activities.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
index 9725523299f..26419ea1c3a 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/06/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/06"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment.
+Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment. 
 """
 false_positives = [
     """
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Deletion Protection Disabled"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled
 
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
index 47a734fbc99..ecdf99bd422 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -20,51 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Instance/Cluster Stoppage"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS Instance/Cluster Stoppage
-
-Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, aligning with the MITRE ATT&CK tactic of service stop. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS, alerting analysts to potential malicious activity aimed at impacting database availability.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `rds.amazonaws.com`, ensuring the alert is relevant to an RDS stoppage.
-- Verify the event action is either `StopDBCluster` or `StopDBInstance` and the event outcome is `success` to confirm the stoppage was successful.
-- Identify the user or role that initiated the stop action by examining the `userIdentity` field in the CloudTrail logs.
-- Check the `sourceIPAddress` field to determine the IP address from which the stop action was initiated, which may provide clues about the origin of the request.
-- Investigate the `eventTime` field to establish a timeline and correlate with other events or activities that occurred around the same time.
-- Use Osquery to gather additional context on the AWS environment. For example, run a query to list all recent changes to RDS instances: `SELECT * FROM aws_rds_instances WHERE last_modified > date('now', '-1 day');`
-- Examine the `requestParameters` field to understand the specific parameters used in the stop request, which might indicate whether it was a planned action or an anomaly.
-- Cross-reference the stopped RDS instance or cluster with any scheduled maintenance or deployment activities to rule out legitimate administrative actions.
-- Review IAM policies and permissions associated with the user or role to determine if they have the necessary permissions to stop RDS instances or clusters, and if those permissions are appropriate.
-- Check for any other alerts or anomalies in the AWS environment that might indicate a broader attack or misconfiguration, such as unauthorized access attempts or changes to security groups.
-
-### False positive analysis
-
-- Routine maintenance activities: Scheduled maintenance or updates by authorized personnel may trigger the rule. Users can handle this by creating exceptions for known maintenance windows or specific user accounts responsible for these tasks.
-- Automated scaling operations: Some environments may have automated scripts or tools that stop RDS instances as part of scaling operations. Users should identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.
-- Cost-saving measures: Organizations may stop RDS instances during off-peak hours to save costs. Users can manage this by setting up time-based exceptions for these known cost-saving schedules.
-- Testing and development environments: Instances in non-production environments may be stopped frequently for testing purposes. Users can exclude these environments by filtering based on instance identifiers or environment tags.
-- Disaster recovery drills: Regularly scheduled disaster recovery tests may involve stopping RDS instances. Users should document these drills and exclude them from alerts by using specific event identifiers or user accounts involved in the drills.
-
-### Response and remediation
-
-- Immediately verify the legitimacy of the stop action by checking the user identity and source IP address in the CloudTrail logs to determine if the action was authorized.
-- If unauthorized, isolate the affected RDS instance or cluster by restricting access through security groups and network ACLs to prevent further unauthorized actions.
-- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
-- Conduct a root cause analysis to understand how the unauthorized stop action was executed, focusing on compromised credentials or misconfigurations.
-- Restore the RDS instance or cluster to its operational state by starting the service and verifying data integrity and availability.
-- Review and update IAM policies to ensure the principle of least privilege is enforced, limiting who can stop RDS instances or clusters.
-- Implement enhanced logging and monitoring by enabling AWS CloudTrail and Amazon CloudWatch to capture detailed activity logs and set up alerts for critical actions.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect potential threats proactively.
-- Conduct regular security awareness training for users to recognize phishing attempts and other tactics that could lead to credential compromise.
-- Consider implementing additional security measures such as multi-factor authentication (MFA) and automated incident response playbooks to improve resilience against similar threats.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_snapshot_deleted.toml b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
index eb23cec9373..ff2c665c4c9 100644
--- a/rules/integrations/aws/impact_rds_snapshot_deleted.toml
+++ b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/06"
 
 [rule]
 author = ["Elastic"]
@@ -46,48 +46,6 @@ any where event.dataset == "aws.cloudtrail"
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS Snapshot Deleted
-
-AWS RDS snapshots are critical for data recovery, capturing full backups of database instances. Adversaries may delete these snapshots to prevent data restoration, effectively causing data loss. The detection rule monitors AWS CloudTrail logs for successful deletion actions or modifications that disable automated backups, signaling potential malicious activity aimed at data destruction.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.action` field to verify if it matches "DeleteDBSnapshot", "DeleteDBClusterSnapshot", or "ModifyDBInstance" with `backupRetentionPeriod=0`.
-- Check the `event.provider` field to ensure the event is associated with "rds.amazonaws.com", confirming it pertains to RDS operations.
-- Analyze the `event.outcome` field to ensure the action was successful, indicating the snapshot was indeed deleted or the backup retention was modified.
-- Investigate the `aws.cloudtrail.user_identity` field to identify the user or role that performed the deletion or modification, which can help determine if the action was authorized.
-- Examine the `aws.cloudtrail.source_ip_address` field to identify the source IP address from which the request originated, which may provide clues about the actor's location or network.
-- Review the `aws.cloudtrail.request_parameters` field for additional context on the request, such as the specific snapshot or DB instance affected.
-- Utilize Osquery to gather further information on the AWS environment by running a query like: `SELECT * FROM aws_cloudtrail_events WHERE eventName IN ('DeleteDBSnapshot', 'DeleteDBClusterSnapshot', 'ModifyDBInstance') AND requestParameters LIKE '%backupRetentionPeriod=0%';` to cross-reference and validate the CloudTrail logs.
-- Check for any recent IAM policy changes or unusual activity in the AWS account that could indicate compromised credentials or privilege escalation.
-- Investigate other related AWS services and logs for any concurrent suspicious activities, such as unauthorized access attempts or changes in security group configurations.
-- Correlate the event with any known threat intelligence or past incidents to determine if this activity aligns with known attack patterns or adversary tactics.
-
-### False positive analysis
-
-- Routine maintenance activities by authorized personnel can trigger the rule, such as scheduled deletions of outdated snapshots to manage storage costs. Users can handle these by creating exceptions for specific user accounts or roles known to perform these tasks regularly.
-- Automated scripts or tools used for database management might delete snapshots as part of their normal operation. Users should identify these scripts and exclude their actions from triggering alerts by specifying the associated IAM roles or user accounts.
-- Changes in backup policies by the database administration team, such as temporarily setting the backupRetentionPeriod to 0 for testing purposes, can be mistaken for malicious activity. Users can manage this by documenting and excluding these policy changes when performed by trusted personnel.
-- Development or testing environments where snapshots are frequently created and deleted as part of the workflow may generate false positives. Users can exclude these environments by filtering out events associated with specific database instance identifiers or tags.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS account to prevent further unauthorized actions and assess the scope of the incident.
-- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and verify if it was authorized.
-- If unauthorized access is confirmed, rotate credentials and access keys for compromised accounts and implement multi-factor authentication (MFA) for all users.
-- Restore the deleted RDS snapshot from a backup if available, or contact AWS Support for potential recovery options.
-- Increase the backup frequency and retention period for critical databases to minimize data loss in future incidents.
-- Implement AWS Config rules to monitor and alert on changes to RDS snapshot configurations and backup settings.
-- Conduct a thorough investigation to determine if other AWS resources have been compromised and take necessary actions to secure them.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess regulatory impacts.
-- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
-- Review and update the organization's incident response plan to incorporate lessons learned from the incident and improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
index d28e4e22a37..b6452e68392 100644
--- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
+++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ license = "Elastic License v2"
 name = "Potential AWS S3 Bucket Ransomware Note Uploaded"
 note = """
 
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded
 
diff --git a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
index c5bec7d3a1b..7c80014e43c 100644
--- a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
+++ b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ license = "Elastic License v2"
 name = "AWS S3 Object Encryption Using External KMS Key"
 note = """
 
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS S3 Object Encryption Using External KMS Key
 
diff --git a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
index 9b5a79e4db2..3e5550fa6ec 100644
--- a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
+++ b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/02"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted.
+Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. 
 """
 false_positives = [
     """
@@ -21,7 +21,7 @@ license = "Elastic License v2"
 name = "AWS S3 Object Versioning Suspended"
 note = """
 
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS S3 Object Versioning Suspended
 
@@ -76,9 +76,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail"
+any where event.dataset == "aws.cloudtrail" 
    and event.action == "PutBucketVersioning"
-   and event.outcome == "success"
+   and event.outcome == "success" 
    and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended")
 '''
 
diff --git a/rules/integrations/aws/initial_access_password_recovery.toml b/rules/integrations/aws/initial_access_password_recovery.toml
index 49f66d041e7..76273e283f6 100644
--- a/rules/integrations/aws/initial_access_password_recovery.toml
+++ b/rules/integrations/aws/initial_access_password_recovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Password Recovery Requested"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS IAM Password Recovery Requested
-
-AWS IAM manages user access and permissions in AWS environments. Password recovery requests are legitimate processes for users to regain access. However, adversaries may exploit this by initiating unauthorized recovery attempts to gain access. The detection rule monitors AWS CloudTrail logs for successful password recovery requests, flagging potential unauthorized access attempts by correlating specific event attributes.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the details of the password recovery request, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:signin.amazonaws.com` fields to ensure the event is related to AWS IAM.
-- Verify the `event.action:PasswordRecoveryRequested` field to confirm that the alert was triggered by a password recovery request.
-- Check the `event.outcome:success` field to ensure the password recovery request was successful, indicating a potential unauthorized access attempt.
-- Identify the IAM user associated with the password recovery request and review their recent activity for any anomalies or unauthorized actions.
-- Investigate the source IP address and geolocation from which the password recovery request was initiated to determine if it aligns with the user's typical access patterns.
-- Examine the AWS account's login history to identify any unusual login attempts or patterns that could indicate compromised credentials.
-- Use Osquery to gather additional context on the IAM user's activity. For example, run the following Osquery query to list recent actions by the user: `SELECT * FROM aws_cloudtrail_events WHERE userIdentity.arn = 'arn:aws:iam::<account-id>:user/<username>' ORDER BY eventTime DESC LIMIT 10;`
-- Review any recent changes to IAM policies or permissions associated with the user to identify potential privilege escalation attempts.
-- Check for any other security alerts or incidents related to the same user or account to assess if this is part of a broader attack.
-- Collaborate with the user or account owner to verify if the password recovery request was legitimate and authorized, ensuring that the user is aware of the request and its implications.
-
-### False positive analysis
-
-- Legitimate user activity: Regular users may frequently request password recovery due to forgotten passwords or account lockouts. These actions can be considered false positives if they originate from known and trusted users.
-- Automated processes: Some organizations may have automated systems or scripts that periodically test password recovery mechanisms for security audits. These should be identified and excluded from alerts.
-- Third-party integrations: Applications or services integrated with AWS IAM might trigger password recovery requests as part of their normal operation. Identifying these integrations and excluding them can reduce false positives.
-- Handling false positives: Implement user and entity behavior analytics (UEBA) to establish a baseline of normal password recovery activities. Create exceptions for users or systems that regularly perform legitimate password recovery requests by adding them to an allowlist or using conditional logic in detection rules.
-
-### Response and remediation
-
-- Immediately verify the legitimacy of the password recovery request by contacting the user associated with the request to confirm if they initiated it.
-- Temporarily disable the affected IAM user account to prevent any unauthorized access until the investigation is complete.
-- Review AWS CloudTrail logs for any suspicious activities associated with the IAM user account, focusing on any unusual login attempts or changes in permissions.
-- Check for any other recent password recovery requests or account changes that may indicate a broader attack.
-- If unauthorized access is confirmed, reset the IAM user's password and enforce multi-factor authentication (MFA) to enhance account security.
-- Escalate the incident to the security operations team for a deeper investigation and to assess the potential impact on the AWS environment.
-- Implement logging policies to ensure comprehensive monitoring of IAM activities, including password recovery requests and login attempts.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance real-time detection and alerting capabilities.
-- Conduct a security review of IAM policies and permissions to ensure the principle of least privilege is enforced across all user accounts.
-- Educate users on recognizing phishing attempts and the importance of reporting suspicious activities to prevent future unauthorized access attempts.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"]
diff --git a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
index 34a83d7090f..7b3b75e46ad 100644
--- a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
+++ b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ['aws']
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
 
@@ -46,49 +46,6 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index
 | where mfa_used == "No"
 | keep @timestamp, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Signin Single Factor Console Login with Federated User
-
-Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent IAM user. This setup is convenient but can be risky if MFA is not enforced, as it leaves the door open for adversaries to exploit these credentials, potentially bypassing security measures. The detection rule identifies instances where federated users access the AWS console without MFA, signaling potential misuse of temporary credentials or STS tokens, which could indicate an attempt to gain unauthorized access. By monitoring these events, security teams can quickly respond to suspicious activities and mitigate risks associated with single-factor authentication.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.provider is "signin.amazonaws.com" and the event.action is "GetSigninToken" to ensure the alert is relevant to the AWS console login.
-- Verify the aws.cloudtrail.user_identity.type is "FederatedUser" to confirm that the login attempt was made by a federated user.
-- Check the aws.cloudtrail.event_type to ensure it is "AwsConsoleSignIn" to validate that the event pertains to a console login.
-- Examine the mfa_used field in the dissected aws.cloudtrail.additional_eventdata to confirm that MFA was not used during the login attempt.
-- Investigate the @timestamp field to determine the exact time of the login attempt and correlate it with other security events or logs around the same time.
-- Identify the source IP address of the login attempt from the CloudTrail logs to assess if it originates from a known or suspicious location.
-- Cross-reference the federated user's identity with IAM roles and policies to understand the level of access granted and potential impact.
-- Use Osquery to gather additional context on the federated user's activity by running a query such as: `SELECT * FROM aws_cloudtrail_events WHERE user_identity_type = 'FederatedUser' AND event_name = 'ConsoleLogin' AND mfa_used = 'No';`
-- Analyze historical login patterns for the federated user to identify any anomalies or deviations from typical behavior.
-- Check for any recent changes in IAM roles, policies, or federated user configurations that might have inadvertently allowed single-factor authentication.
-
-### False positive analysis
-
-- Federated users accessing the AWS Management Console from trusted networks or IP addresses without MFA may trigger false positives. These instances can be managed by creating exceptions for known IP ranges or trusted network locations.
-- Automated processes or scripts that use federated credentials for legitimate purposes without MFA can also result in false positives. To handle these, security teams can whitelist specific user agents or service accounts that are known to operate without MFA.
-- Temporary credentials used by third-party services or integrations that do not support MFA might be flagged. In such cases, exceptions can be made for specific service accounts or roles that are verified to be secure and necessary for business operations.
-- Regularly scheduled tasks or maintenance activities performed by federated users without MFA could be misidentified as threats. These can be excluded by documenting and approving such activities, then updating the detection rule to ignore these specific events.
-- Users who are part of a pilot program or testing environment where MFA is temporarily disabled might cause false positives. Security teams can manage this by setting up temporary exceptions for these users until the testing phase is complete.
-
-### Response and remediation
-
-- Immediately revoke the temporary credentials associated with the federated user to prevent further unauthorized access.
-- Investigate the source of the login attempt by reviewing the IP address, user agent, and any associated CloudTrail logs to determine if the access was legitimate or malicious.
-- Verify the identity of the federated user by contacting the user or the identity provider to confirm if the login attempt was authorized.
-- Implement or enforce multi-factor authentication (MFA) for all federated user logins to enhance security and prevent similar incidents in the future.
-- Review and update IAM policies to ensure that federated users have the least privilege necessary to perform their tasks.
-- Escalate the incident to the security operations team if there is evidence of malicious intent or if the scope of the incident is beyond initial containment measures.
-- Conduct a thorough audit of all recent federated user activities to identify any other suspicious actions or potential security breaches.
-- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
-- Develop and implement a security awareness program to educate users about the importance of MFA and secure credential handling.
-- Review and update the incident response plan to incorporate lessons learned from the incident and improve future response efforts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
index c8aec1676cb..a32e91109c9 100644
--- a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
+++ b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "SSM Session Started to EC2 Instance"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating SSM Session Started to EC2 Instance
 
diff --git a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
index 239db47d9aa..153db90dc33 100644
--- a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
+++ b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/31"
 
 [rule]
 author = ["Elastic"]
@@ -43,49 +43,6 @@ any where event.dataset == "aws.cloudtrail"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
    and stringContains (user.id, ":i-")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 Instance Console Login via Assumed Role
-
-AWS EC2 instances can assume roles to access resources securely, using temporary credentials. Adversaries may exploit this by using compromised instance credentials to assume roles and gain unauthorized access. The detection rule identifies unusual console login activities by checking for EC2 instance IDs in session names and successful login events, signaling potential misuse of assumed roles.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the "i-" pattern in the session name, indicating an EC2 instance assumed role.
-- Verify the `event.dataset` field to ensure the event is sourced from "aws.cloudtrail" and the `event.provider` is "signin.amazonaws.com" to confirm the context of the alert.
-- Check the `event.action` field for "ConsoleLogin" or "GetSigninToken" to validate the type of login activity that occurred.
-- Examine the `event.outcome` field to confirm the login was successful, which is critical for identifying potential unauthorized access.
-- Investigate the `aws.cloudtrail.user_identity.type` field to ensure it is "AssumedRole", indicating the use of temporary credentials.
-- Identify the specific EC2 instance by extracting the instance ID from the `user.id` field, which contains the "i-" pattern.
-- Cross-reference the instance ID with AWS EC2 inventory to gather details about the instance, such as its purpose, owner, and associated security groups.
-- Use AWS CloudTrail logs to trace back the assumed role session to identify the source IP address and any preceding API calls that might indicate how the credentials were compromised.
-- If using Osquery, run a query to list all active sessions on the EC2 instance to identify any unusual or unauthorized users: `SELECT user, host, time FROM logged_in_users WHERE host = '<instance_id>';`
-- Analyze the AWS IAM role associated with the instance to review its permissions and determine if they are overly permissive or if there are any recent changes to the role's policy.
-
-### False positive analysis
-
-- **Automated Processes**: Some legitimate automated processes may use EC2 instance profiles to assume roles for routine tasks, leading to successful console login events. Users should identify and document these processes to differentiate them from potential threats.
-- **Frequent Role Assumptions**: In environments where EC2 instances frequently assume roles for legitimate purposes, such as accessing shared resources or services, these activities might trigger the rule. Users can create exceptions for known instance IDs or specific roles that are regularly assumed.
-- **Testing and Development Environments**: In testing or development environments, developers might frequently assume roles using EC2 instances for testing purposes. Users should consider excluding these environments from the rule or creating specific exceptions for known testing activities.
-- **Third-party Integrations**: Some third-party services or integrations might require EC2 instances to assume roles for legitimate operations. Users should verify these integrations and exclude them from the rule if they are deemed non-threatening.
-- **Handling False Positives**: To manage false positives, users can implement tagging or naming conventions for EC2 instances and roles that are known to perform legitimate activities. Additionally, users can adjust the rule to exclude specific instance IDs, roles, or environments that are verified as non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected EC2 instance to prevent further unauthorized access and lateral movement within the network.
-- Review CloudTrail logs to identify the source of the compromised credentials and any other potentially affected resources or accounts.
-- Revoke the temporary credentials associated with the assumed role to prevent further misuse.
-- Conduct a thorough investigation to determine how the credentials were compromised, focusing on recent changes or anomalies in the instance's environment.
-- Reset credentials and rotate keys for the affected instance and any other potentially compromised accounts.
-- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed.
-- Implement enhanced logging and monitoring policies to capture detailed access and activity logs for all EC2 instances and associated roles.
-- Integrate AWS GuardDuty and other threat detection services to provide real-time alerts and insights into suspicious activities.
-- Restore the affected EC2 instance from a known good backup or snapshot to ensure it is free from any unauthorized changes or malware.
-- Apply security hardening measures, such as enforcing least privilege access, enabling multi-factor authentication, and regularly reviewing IAM policies and roles."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
index 63f05e31011..0ec4ba8c4a3 100644
--- a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
+++ b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,53 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Network Access Control List Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 Network Access Control List Creation
-
-AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or enable unauthorized access by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential misuse by identifying unusual or unauthorized configurations.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `ec2.amazonaws.com`, ensuring the alert is relevant to AWS EC2 Network ACL creation.
-- Verify the event action is either `CreateNetworkAcl` or `CreateNetworkAclEntry` and the event outcome is `success` to confirm the alert is triggered by a successful creation event.
-- Identify the AWS account and user or role that initiated the ACL creation by examining the `user.identity.arn` and `user.identity.accountId` fields.
-- Check the `sourceIPAddress` field to determine the IP address from which the request originated, which can help identify potential unauthorized access.
-- Investigate the `aws.region` field to understand the geographical location of the resource creation and assess if it aligns with expected operations.
-- Examine the `requestParameters` field to gather details about the specific ACL rules created, such as rule number, protocol, and port range, to identify any overly permissive configurations.
-- Cross-reference the `userAgent` field to determine the tool or service used to create the ACL, which may provide insights into whether the action was automated or manual.
-- Utilize AWS CloudTrail logs to search for any preceding or subsequent suspicious activities associated with the same user or IP address.
-- If using Osquery, execute a query to list all current network ACLs and their entries for the affected AWS account to compare against known configurations:
-  ```sql
-  SELECT * FROM aws_ec2_network_acls WHERE account_id = '<affected_account_id>';
-  ```
-- Review IAM policies and permissions associated with the user or role that created the ACL to ensure they align with the principle of least privilege.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or changes to network configurations by authorized personnel can trigger alerts. To manage this, users can create exceptions for known IP addresses or user accounts that frequently perform these tasks.
-- Automated scripts or tools: Organizations may use automated processes to manage network ACLs, which can result in multiple creation events. Users should identify and whitelist these scripts or tools to prevent unnecessary alerts.
-- Infrastructure as Code (IaC) deployments: Deployments using IaC tools like Terraform or CloudFormation can generate numerous ACL creation events. Users can exclude these events by filtering based on the source of the deployment or tagging conventions.
-- Testing and development environments: Frequent changes in non-production environments can lead to false positives. Users can exclude these environments by using environment-specific tags or identifiers in their monitoring rules.
-
-### Response and remediation
-
-- Immediately review the newly created Network ACLs and entries to verify if they align with the organization's security policies and intended configurations.
-- Contain potential threats by temporarily restricting or removing overly permissive ACL rules that could allow unauthorized access.
-- Investigate the source of the ACL creation by reviewing CloudTrail logs to identify the user or service account responsible for the action.
-- If unauthorized access is suspected, rotate credentials and access keys for affected accounts and services to prevent further exploitation.
-- Escalate the incident to the security operations team if the ACL creation is determined to be malicious or part of a larger attack pattern.
-- Implement additional logging and monitoring for Network ACL changes to ensure real-time detection of suspicious activities.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance threat detection and response capabilities.
-- Restore the system to its operational state by reapplying the correct ACL configurations and ensuring all security policies are enforced.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Harden the environment by applying the principle of least privilege to IAM roles and ensuring that only authorized personnel can modify network configurations.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
index 748f81ea33f..c01a4fe6b96 100644
--- a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
+++ b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,49 +23,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Security Group Configuration Change"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 Security Group Configuration Change
-
-AWS EC2 Security Groups act as virtual firewalls, controlling inbound and outbound traffic to instances. Adversaries may exploit changes in these configurations to gain unauthorized access, maintain persistence, or move laterally within an AWS environment. The detection rule monitors successful changes to security group settings, such as rule modifications or group creation, to identify potential misuse by threat actors.
-
-### Possible investigation steps
-
-- Review the specific `event.action` that triggered the alert to understand the type of change made to the security group configuration.
-- Examine the `event.dataset` and `event.provider` fields to confirm the event source and ensure it is related to AWS EC2.
-- Check the `event.outcome` field to verify that the change was successful, as unsuccessful attempts may indicate probing or testing by an adversary.
-- Identify the `user.identity` or `user.name` associated with the event to determine who made the change and assess if this user has legitimate access and reasons for the modification.
-- Investigate the `source.ip` or `source.address` to determine the origin of the request and assess if it is from a known or expected location.
-- Review the `aws.region` field to ensure the change was made in an expected region, as unexpected regions may indicate unauthorized activity.
-- Analyze the `event.time` to correlate the timing of the change with other suspicious activities or known incidents.
-- Use Osquery to gather additional context on the affected instances. For example, run the following query to list all security groups and their rules: `SELECT * FROM ec2_security_groups WHERE group_id = '<affected_group_id>';`
-- Cross-reference the security group changes with recent IAM policy changes or user activity logs to identify potential privilege escalation or misuse.
-- Investigate any other related CloudTrail logs around the same timeframe to identify additional suspicious activities or patterns that may indicate a broader attack.
-
-### False positive analysis
-
-- Routine administrative tasks: Changes made by authorized personnel during regular maintenance or updates can trigger alerts. To manage this, users can create exceptions for specific user accounts or roles known to perform these tasks regularly.
-- Automated scripts or tools: Security group modifications by automated processes or tools used for infrastructure management may be flagged. Users should identify these tools and exclude their actions from triggering alerts by specifying their associated IAM roles or user accounts.
-- CloudFormation or other infrastructure as code deployments: Deployments that involve security group changes as part of infrastructure updates can result in false positives. Users can handle these by excluding changes initiated by specific CloudFormation stacks or deployment tools.
-- Third-party integrations: Some third-party services may require security group modifications for functionality. Users should review and whitelist these services if they are deemed non-threatening, ensuring that their actions do not trigger unnecessary alerts.
-
-### Response and remediation
-
-- Immediately review the AWS CloudTrail logs to identify the source and nature of the security group changes, focusing on the user or service account responsible for the modifications.
-- Contain the potential threat by reverting unauthorized security group changes to their previous state and temporarily restricting access to critical resources.
-- Investigate the IAM roles and permissions associated with the user or service account that made the changes to ensure they are appropriate and not overly permissive.
-- If unauthorized access is confirmed, rotate credentials and access keys for affected accounts and services to prevent further unauthorized actions.
-- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms used by the threat actor.
-- Implement enhanced logging and monitoring policies to capture detailed information on security group changes and other critical AWS activities.
-- Integrate AWS GuardDuty and other threat detection services to provide real-time alerts on suspicious activities and potential security breaches.
-- Restore the system to its operational state by ensuring all security group configurations are aligned with the organization's security policies and best practices.
-- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
-- Apply hardening measures such as implementing least privilege access, enabling multi-factor authentication, and regularly reviewing security group rules to minimize the risk of future incidents.
-
+note = """
 ### Investigating AWS EC2 Security Group Configuration Change
 
 This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.
diff --git a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
index 5f9eb975308..447c69c9399 100644
--- a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
+++ b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL available in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/12/02"
 
 [rule]
 author = ["Elastic"]
@@ -17,49 +17,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS IAM Login Profile Added for Root"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS IAM Login Profile Added for Root
-
-AWS IAM allows management of user access and permissions within AWS environments. A login profile enables console access, typically not used by root accounts. Adversaries may exploit temporary root access to create a login profile, ensuring persistent access. The detection rule identifies this by monitoring specific API calls and conditions, such as successful profile creation without explicit user assignment, indicating potential self-assignment by a root user.
-
-### Possible investigation steps
-
-- Review the `@timestamp` field to determine when the login profile was created and correlate it with any known activities or changes in the environment around that time.
-- Examine the `aws.cloudtrail.user_identity.arn` to confirm the identity of the root user and verify if this action aligns with expected behavior or known activities.
-- Analyze the `source.address` to identify the IP address from which the CreateLoginProfile API call was made, and check if it matches known IP addresses associated with legitimate users or if it appears suspicious.
-- Investigate the `aws.cloudtrail.request_parameters` to understand the specifics of the request, ensuring no unexpected parameters were included that could indicate malicious intent.
-- Check the `aws.cloudtrail.response_elements` for any additional information or anomalies that might provide context or indicate a misconfiguration or security issue.
-- Use the `cloud.account.id` to identify the specific AWS account involved and verify if there have been any recent changes or incidents reported for this account.
-- Cross-reference the `aws.cloudtrail.user_identity.access_key_id` with known access keys to determine if the key used is legitimate or potentially compromised.
-- Utilize Osquery to further investigate the environment. For example, run an Osquery query to list all IAM users and their associated login profiles: `SELECT user_name, create_date FROM aws_iam_login_profiles;` to verify if any unexpected profiles exist.
-- Review historical CloudTrail logs for any other unusual or unauthorized activities associated with the root account, focusing on actions that could indicate privilege escalation or persistence attempts.
-- Collaborate with the account owner or security team to verify if the login profile creation was authorized and to gather any additional context or evidence that could aid in the investigation.
-
-### False positive analysis
-
-- **Automated Account Management Tools**: Some organizations use automated tools for account management that might inadvertently trigger the rule by creating login profiles for root accounts as part of their routine operations. To handle this, users can create exceptions for specific tools or scripts by identifying their unique access patterns or source IP addresses.
-- **Internal Security Audits**: During internal security audits, administrators might temporarily create login profiles for root accounts to test security configurations. These activities can be excluded by setting time-based exceptions during known audit periods or by excluding specific user identities associated with the audit team.
-- **Misconfigured Automation Scripts**: Scripts intended to manage IAM users might be misconfigured to include root account operations. Users should review and correct these scripts, and in the meantime, exclude known script-related activities by identifying their access keys or source IPs.
-- **Testing Environments**: In testing environments, developers might create login profiles for root accounts to simulate real-world scenarios. Users can manage these false positives by excluding specific testing environments based on account IDs or by tagging activities with identifiable metadata.
-
-### Response and remediation
-
-- Immediately revoke the login profile for the root account to prevent unauthorized access.
-- Rotate the root account's access keys and passwords to ensure no further unauthorized access can occur.
-- Review CloudTrail logs to identify any other suspicious activities or API calls made by the root account during the timeframe of the incident.
-- Implement multi-factor authentication (MFA) for the root account to add an additional layer of security.
-- Conduct a thorough investigation to determine how the adversary gained temporary access to the root account and address any identified vulnerabilities.
-- Escalate the incident to the security operations team for further analysis and to determine if any other accounts or resources have been compromised.
-- Enhance logging policies to ensure all critical actions, especially those involving root account activities, are logged and monitored in real-time.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for improved threat detection and response capabilities.
-- Restore the system to its operational state by verifying the integrity of all AWS resources and ensuring no unauthorized changes have been made.
-- Implement hardening measures such as least privilege access, regular security audits, and continuous monitoring to prevent future incidents.
-
+note = """
 ## Investigating AWS IAM Login Profile Added for Root
 
 This rule detects when a login profile is added to the AWS root account. Adding a login profile to the root account, especially if self-assigned, is highly suspicious as it might indicate an adversary trying to establish persistence in the environment.
diff --git a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
index ade0d2e0e00..787afc8f6ad 100644
--- a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
+++ b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Create User via Assumed Role on EC2 Instance"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS IAM User Creation via Assumed Role on an EC2 Instance
 
diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml
index fbf567bd93e..5d678c72d7c 100644
--- a/rules/integrations/aws/persistence_iam_group_creation.toml
+++ b/rules/integrations/aws/persistence_iam_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS IAM Group Creation
-
-AWS IAM groups streamline permission management by allowing multiple users to inherit group-assigned permissions. Adversaries may exploit this by creating unauthorized groups to escalate privileges or maintain persistence. The detection rule monitors successful group creation events in AWS CloudTrail, flagging potential misuse by correlating specific IAM actions with known threat tactics.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to confirm the `event.action:CreateGroup` and `event.outcome:success` to ensure the alert is valid and not a false positive.
-- Identify the `userIdentity` field in the CloudTrail logs to determine which IAM user or role initiated the group creation.
-- Check the `event.time` field to establish the exact time of the group creation and correlate it with any other suspicious activities around the same timeframe.
-- Investigate the `requestParameters.groupName` to understand the naming convention and assess if it aligns with the organization's standard naming practices.
-- Examine the `sourceIPAddress` and `userAgent` fields to identify the origin of the request and determine if it was made from an unusual location or device.
-- Use AWS IAM console or CLI to list the members of the newly created group and verify if any unauthorized users have been added.
-- Review the permissions and policies attached to the new group to assess if they grant excessive or sensitive permissions that could be exploited.
-- Cross-reference the `userIdentity` with recent IAM activity logs to check for any other unusual or unauthorized actions performed by the same user or role.
-- Utilize Osquery to further investigate by running a query such as `SELECT * FROM aws_iam_groups WHERE group_name = '<group_name>';` to gather more details about the group and its configurations.
-- Check for any recent changes in IAM policies or configurations that might indicate an attempt to cover tracks or escalate privileges.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IAM group creation by system administrators for organizational purposes can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time frames when such activities are expected.
-- Automated processes: Some organizations use automated scripts or tools to manage IAM groups, which may lead to frequent group creation events. Users can exclude these processes by identifying and filtering out the specific IAM roles or user accounts associated with these automated tasks.
-- Third-party integrations: Certain third-party services or applications may require the creation of IAM groups as part of their setup or operation. Users should review and whitelist these services by correlating the group creation events with known application behavior and excluding them from alerts.
-- Testing environments: In environments where IAM group creation is part of regular testing or development activities, users can exclude specific AWS accounts or regions dedicated to testing to reduce noise from non-threatening group creation events.
-
-### Response and remediation
-
-- Immediately review the IAM group creation event in AWS CloudTrail to verify if it was authorized or potentially malicious.
-- Identify the user or service that initiated the group creation and assess their activity for any other suspicious actions.
-- If unauthorized, disable the newly created IAM group and revoke any permissions associated with it to prevent privilege escalation.
-- Conduct a thorough investigation of the IAM policies attached to the group to ensure no sensitive permissions were granted.
-- Escalate the incident to the security operations team if the group creation is linked to known threat actors or tactics, such as those outlined in MITRE ATT&CK T1136.
-- Implement additional logging and monitoring for IAM activities to detect similar unauthorized actions in the future.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring users and groups have only the permissions necessary for their roles.
-- Integrate AWS CloudTrail logs with a Security Information and Event Management (SIEM) system for enhanced threat detection and correlation.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate and train staff on recognizing and reporting suspicious IAM activities to improve organizational awareness and response capabilities.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
index f8fd0389964..1d800bd6854 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Roles Anywhere Profile Creation"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS IAM Roles Anywhere Profile Creation
 
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
index d483f02834f..d55e1007ae7 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA
 
diff --git a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
index 00527b85f4f..7bc76bfde42 100644
--- a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
+++ b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Lambda Function Policy Updated to Allow Public Invocation"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation
 
diff --git a/rules/integrations/aws/persistence_rds_cluster_creation.toml b/rules/integrations/aws/persistence_rds_cluster_creation.toml
index 6f5591d1d8e..352fd7c484b 100644
--- a/rules/integrations/aws/persistence_rds_cluster_creation.toml
+++ b/rules/integrations/aws/persistence_rds_cluster_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Cluster Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS Cluster Creation
-
-Amazon RDS facilitates database management by automating tasks like scaling and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes within AWS CloudTrail logs.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:rds.amazonaws.com` fields to ensure the event is related to RDS cluster creation.
-- Verify the `event.action` field to determine whether the action was `CreateDBCluster` or `CreateGlobalCluster`, as these are the specific actions of interest.
-- Check the `event.outcome:success` field to confirm that the cluster creation was successful, which is crucial for identifying potential unauthorized activities.
-- Identify the AWS account and user associated with the event by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by a legitimate user or an adversary.
-- Investigate the source IP address and location from which the request originated using the `sourceIPAddress` field to identify any unusual or suspicious access patterns.
-- Analyze the `requestParameters` field to gather details about the configuration of the newly created RDS cluster, such as the database engine, instance type, and region, to assess if they align with expected configurations.
-- Cross-reference the `userAgent` field to understand the tool or service used to perform the action, which can provide insights into whether the action was automated or manually executed.
-- Utilize Osquery to further investigate the AWS environment by running a query such as `SELECT * FROM aws_rds_clusters WHERE name = '<cluster_name>';` to gather additional details about the cluster, including its status and configuration.
-- Review recent IAM policy changes or role assignments that might have granted the necessary permissions for RDS cluster creation, focusing on any anomalies or deviations from standard practices.
-- Correlate the event with other recent AWS activity logs to identify any patterns or sequences of actions that could indicate a broader attack or unauthorized access attempt.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular database management activities by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or IP addresses.
-- Automated deployment scripts: Organizations using infrastructure as code (IaC) tools like Terraform or CloudFormation may inadvertently trigger the rule during legitimate deployments. Users should consider excluding specific IAM roles or tags associated with these tools.
-- Testing and development environments: Frequent creation of RDS clusters in non-production environments for testing purposes can lead to false positives. Users can exclude specific AWS accounts or regions dedicated to development and testing.
-- Scheduled maintenance: Automated processes for scaling or updating databases during scheduled maintenance windows might be flagged. Users can set time-based exceptions to ignore events during these periods.
-
-### Response and remediation
-
-- Immediately isolate the newly created RDS cluster to prevent any potential data exfiltration or unauthorized access.
-- Review AWS CloudTrail logs to identify the source of the cluster creation, including the IAM user or role responsible for the action.
-- Verify the legitimacy of the cluster creation with the relevant team or individual; if unauthorized, proceed with further investigation.
-- Revoke any suspicious or unauthorized IAM roles or user permissions that may have been used to create the RDS cluster.
-- Conduct a thorough review of network traffic and access logs to identify any data exfiltration attempts or unusual activity associated with the cluster.
-- If data exfiltration is confirmed, follow your organization's incident response plan to notify affected parties and regulatory bodies as required.
-- Implement enhanced logging and monitoring policies to capture detailed events related to RDS activities, ensuring future unauthorized actions are detected promptly.
-- Integrate AWS GuardDuty and other security tools to provide additional layers of threat detection and response capabilities.
-- Restore the system to its operational state by deleting unauthorized clusters and ensuring all legitimate clusters are configured securely with appropriate access controls.
-- Harden the environment by enforcing least privilege access, regularly reviewing IAM policies, and applying security patches to all related services.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
index 1cfab6536d8..ac4bbc343f9 100644
--- a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
+++ b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/06/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/06"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation.
+Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation. 
 """
 false_positives = [
     """
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Password Modified"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS RDS DB Instance or Cluster Password Modified
 
diff --git a/rules/integrations/aws/persistence_rds_group_creation.toml b/rules/integrations/aws/persistence_rds_group_creation.toml
index 43a0e8c8179..1140f4e4ef5 100644
--- a/rules/integrations/aws/persistence_rds_group_creation.toml
+++ b/rules/integrations/aws/persistence_rds_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,51 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Security Group Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS Security Group Creation
-
-Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors AWS CloudTrail logs for successful creation events of RDS security groups, signaling potential misuse by identifying unexpected or suspicious activity.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to confirm the `event.action:CreateDBSecurityGroup` and `event.outcome:success` to ensure the alert is valid and not a false positive.
-- Identify the `userIdentity` field in the CloudTrail logs to determine which IAM user or role initiated the creation of the RDS security group.
-- Check the `sourceIPAddress` field to identify the IP address from which the request originated, and assess if it aligns with known or expected IP addresses.
-- Examine the `eventTime` field to understand when the security group was created and correlate it with other activities or alerts around the same time.
-- Investigate the `requestParameters` field to gather details about the security group, such as its name and description, to assess if it matches known naming conventions or appears suspicious.
-- Use Osquery to query AWS API logs for additional context on the IAM user or role involved. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'CreateDBSecurityGroup' AND userIdentity.arn = '<IAM User ARN>';`
-- Cross-reference the IAM user or role with recent changes in IAM policies or permissions to determine if there have been any unauthorized modifications.
-- Analyze the `responseElements` field to verify the configuration of the newly created security group, including any inbound or outbound rules that may pose a security risk.
-- Check for any other recent `CreateDBSecurityGroup` events in the logs to identify patterns or repeated unauthorized activities.
-- Review the organization's change management records or ticketing system to verify if the creation of the security group was part of an approved change request.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular maintenance or configuration changes by authorized personnel can trigger the creation of RDS security groups. Users should review the context of the event, such as the user identity and associated project, to determine if the activity is expected.
-- Automated deployment tools: Continuous integration and deployment pipelines may automatically create RDS security groups as part of their operations. Users can manage these by identifying and excluding specific IAM roles or user accounts associated with these tools from the detection rule.
-- Infrastructure as Code (IaC) practices: Tools like Terraform or AWS CloudFormation might create security groups as part of infrastructure provisioning. Users should document and exclude these known IaC processes to reduce noise in alerts.
-- Testing environments: Security groups created in non-production environments for testing purposes can be mistaken for suspicious activity. Users should differentiate between production and non-production environments and apply exceptions accordingly.
-- Frequent changes in dynamic environments: In environments where resources are frequently scaled or modified, security group creation might be a common occurrence. Users should establish a baseline of normal activity and adjust the detection rule to focus on deviations from this baseline.
-
-### Response and remediation
-
-- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved.
-- Contain the threat by revoking access for the identified user account and removing the unauthorized RDS security group.
-- Investigate the extent of the compromise by checking for any other unauthorized changes or access patterns in the AWS environment.
-- Escalate the incident to the security operations team for a deeper investigation and to determine if any data exfiltration occurred.
-- Remediate by rotating credentials and implementing multi-factor authentication for all AWS accounts to prevent further unauthorized access.
-- Restore the system by ensuring all security groups are configured according to the organization's security policies and best practices.
-- Enhance future investigations by enabling detailed logging for all AWS services and integrating with a Security Information and Event Management (SIEM) system for real-time monitoring.
-- Implement a policy to regularly review and audit security group configurations and access logs to detect any anomalies promptly.
-- Educate and train staff on recognizing and reporting suspicious activities to improve the organization's security posture.
-- Apply hardening measures by restricting security group creation permissions to a limited number of trusted administrators and using AWS Identity and Access Management (IAM) roles with the principle of least privilege.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html"]
diff --git a/rules/integrations/aws/persistence_rds_instance_creation.toml b/rules/integrations/aws/persistence_rds_instance_creation.toml
index ed891dad756..ba167a1cb93 100644
--- a/rules/integrations/aws/persistence_rds_instance_creation.toml
+++ b/rules/integrations/aws/persistence_rds_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,50 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Instance Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS Instance Creation
-
-Amazon RDS simplifies database management, offering scalable and cost-effective solutions. However, adversaries may exploit RDS by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creation events, flagging potential misuse by correlating specific AWS CloudTrail logs, thus enabling timely investigation and response.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the event details, focusing on the `event.dataset:aws.cloudtrail` and `event.provider:rds.amazonaws.com` fields to ensure the event is related to RDS instance creation.
-- Verify the `event.action:CreateDBInstance` and `event.outcome:success` fields to confirm that the instance creation was successful and intended.
-- Identify the AWS account and user associated with the instance creation by examining the `userIdentity` field in the CloudTrail logs to determine if the action was performed by an authorized user.
-- Check the `sourceIPAddress` field to identify the IP address from which the request originated, and assess if it aligns with known and trusted IP addresses.
-- Investigate the `requestParameters` field to gather details about the RDS instance configuration, such as instance type, database engine, and allocated storage, to understand the potential impact.
-- Cross-reference the `awsRegion` field to ensure the instance was created in an expected and authorized region.
-- Utilize Osquery to further investigate the AWS environment by running a query such as: `SELECT * FROM aws_rds_instances WHERE instance_id = '<instance_id>'` to gather more details about the newly created RDS instance.
-- Review IAM policies and roles associated with the user or service that created the instance to ensure they have appropriate permissions and are not overly permissive.
-- Check for any related alerts or anomalies in the same timeframe that might indicate a broader security incident or unauthorized activity.
-- Document all findings and observations in a centralized investigation log to maintain a clear record of the investigation process and support any further analysis or escalation.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular database maintenance or scaling activities by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
-- Automated processes: Scheduled scripts or automated workflows that create RDS instances for testing or development purposes may be flagged. Users should identify these processes and exclude them by tagging instances or using specific IAM roles associated with these tasks.
-- Third-party integrations: Some third-party services may create RDS instances as part of their functionality. Users should verify these integrations and whitelist the associated actions or service accounts to prevent false positives.
-- Testing environments: Instances created in non-production environments for testing purposes might be detected. Users can exclude these environments by filtering based on tags, VPC IDs, or other identifiable attributes specific to test setups.
-
-### Response and remediation
-
-- Verify the legitimacy of the RDS instance creation by checking with the relevant stakeholders or database administrators.
-- Contain the potential threat by immediately revoking access to the unauthorized RDS instance and isolating it from the network.
-- Investigate the source of the instance creation by reviewing AWS CloudTrail logs for unusual activity or unauthorized access patterns.
-- Remediate by terminating the unauthorized RDS instance and ensuring no data has been exfiltrated or compromised.
-- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or persistent threat.
-- Implement enhanced logging policies to capture detailed access and activity logs for all RDS instances and related AWS services.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
-- Restore the system to its operational state by ensuring all legitimate RDS instances are functioning correctly and securely.
-- Harden the environment by enforcing strict IAM policies, using multi-factor authentication, and regularly reviewing access permissions.
-- Educate and train staff on recognizing and responding to potential security incidents, emphasizing the importance of vigilance and prompt reporting.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html"]
diff --git a/rules/integrations/aws/persistence_rds_instance_made_public.toml b/rules/integrations/aws/persistence_rds_instance_made_public.toml
index 4f7cfb8e0ce..8c40eeebabd 100644
--- a/rules/integrations/aws/persistence_rds_instance_made_public.toml
+++ b/rules/integrations/aws/persistence_rds_instance_made_public.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/06"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance Made Public"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS RDS DB Instance Made Public
 
@@ -42,7 +42,7 @@ This rule identifies when an RDS DB instance is created or modified to enable pu
 
 ### Response and Remediation
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes.
+- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes. 
 - **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
 - **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
 - **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
@@ -81,7 +81,7 @@ any where event.dataset == "aws.cloudtrail"
     and event.outcome == "success"
     and (
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true"))
-        or
+        or 
         (event.action in ("CreateDBInstance", "CreateDBCluster") and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true"))
     )
 '''
diff --git a/rules/integrations/aws/persistence_redshift_instance_creation.toml b/rules/integrations/aws/persistence_redshift_instance_creation.toml
index 29d11691e98..ee4a8e87d42 100644
--- a/rules/integrations/aws/persistence_redshift_instance_creation.toml
+++ b/rules/integrations/aws/persistence_redshift_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,51 +24,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Redshift Cluster Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Redshift Cluster Creation
-
-Amazon Redshift is a data warehousing service that allows for scalable data storage and analysis. Adversaries might exploit Redshift by creating unauthorized clusters to exfiltrate data or conduct unauthorized data analysis. The detection rule monitors for successful cluster creation events, especially by non-admin users, to identify potential misuse or misconfigurations that could lead to security vulnerabilities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `redshift.amazonaws.com` to ensure the alert is related to Redshift cluster creation.
-- Verify the `event.action` field is `CreateCluster` and the `event.outcome` is `success` to confirm a successful cluster creation event.
-- Identify the user who initiated the cluster creation by examining the `user.name` field in the event logs.
-- Check the `user.role` or `user.group` fields to determine if the user has administrative privileges or if they are a non-admin user.
-- Investigate the `source.ip` field to identify the IP address from which the cluster creation request originated and determine if it is a known or trusted source.
-- Review the `aws.region` field to verify if the cluster was created in an expected region or if it was created in an unusual or unauthorized region.
-- Use AWS CloudTrail logs to gather additional context around the time of the cluster creation event, looking for any other suspicious activities or related events.
-- If available, use Osquery to query AWS Redshift configurations and gather more details about the newly created cluster. Example Osquery query: `SELECT * FROM aws_redshift_clusters WHERE cluster_identifier = '<cluster_id>';`
-- Check for any recent changes in IAM policies or roles that might have inadvertently granted the user permissions to create Redshift clusters.
-- Review the organization's policy on Redshift cluster creation to determine if the creation aligns with expected usage patterns and business needs.
-
-### False positive analysis
-
-- Routine administrative tasks: Regularly scheduled maintenance or updates by authorized personnel might trigger cluster creation events. Users can manage these by creating exceptions for known maintenance windows or specific user accounts.
-- Automated processes: Some organizations use automated scripts or third-party tools to manage Redshift clusters, which could lead to false positives. Identifying and excluding these processes from alerts can reduce noise.
-- Development and testing environments: Non-admin users might create clusters for legitimate development or testing purposes. Establishing a list of approved users or environments can help in filtering out these benign activities.
-- Training and onboarding: New employees or teams might create clusters as part of their training or onboarding process. Monitoring and documenting these activities can help distinguish them from potential threats.
-- Temporary projects: Short-term projects might require the creation of Redshift clusters by non-admin users. Implementing a review process for temporary projects can help in identifying and excluding these from alerts.
-
-### Response and remediation
-
-- Verify the identity and permissions of the user who created the Redshift cluster to ensure they have the appropriate authorization.
-- Immediately isolate the newly created Redshift cluster to prevent any potential data exfiltration or unauthorized access.
-- Review CloudTrail logs to identify any suspicious activities or patterns associated with the cluster creation event.
-- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated using the unauthorized cluster.
-- Revoke any unnecessary permissions or roles from the user involved in the cluster creation to prevent further unauthorized actions.
-- Escalate the incident to the security operations team if the investigation reveals malicious intent or data compromise.
-- Implement enhanced logging and monitoring policies to capture detailed events related to Redshift cluster activities for future investigations.
-- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities within the AWS environment.
-- Restore the system to its operational state by deleting the unauthorized Redshift cluster and ensuring no residual configurations remain.
-- Apply hardening measures such as enforcing least privilege access, enabling multi-factor authentication, and regularly reviewing IAM policies to prevent similar incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateCluster.html"]
diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
index 14d611b2f55..3adaff849fd 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,50 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route 53 Domain Transfer Lock Disabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Route 53 Domain Transfer Lock Disabled
-
-AWS Route 53's domain transfer lock is a security feature that prevents unauthorized domain transfers by locking the domain at the registrar level. Adversaries may disable this lock to transfer domains illicitly, potentially redirecting traffic or disrupting services. The detection rule monitors successful events where this lock is disabled, signaling potential unauthorized activity and enabling timely investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `route53.amazonaws.com` to ensure the alert is relevant to AWS Route 53.
-- Verify the event action is `DisableDomainTransferLock` and the event outcome is `success` to confirm that the transfer lock was indeed disabled successfully.
-- Identify the user or role that performed the action by examining the `user.identity.arn` field in the event logs to determine if the action was performed by an authorized entity.
-- Check the `sourceIPAddress` field to identify the IP address from which the request originated and assess if it is a known or trusted source.
-- Investigate the `userAgent` field to understand the application or service used to perform the action, which might provide additional context about the method of access.
-- Review the `eventTime` field to establish a timeline and correlate with other events or activities that occurred around the same time.
-- Use Osquery to gather additional context by querying AWS CloudTrail logs for any other suspicious activities related to the same user or IP address. Example query: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'DisableDomainTransferLock' AND userIdentity.arn = '<user_arn>' AND sourceIPAddress = '<source_ip>'`.
-- Examine any recent changes in IAM policies or roles that might have inadvertently granted permissions to disable the domain transfer lock.
-- Cross-reference with other security tools or logs to identify any concurrent alerts or anomalies that might indicate a broader security incident.
-- Document all findings and observations to build a comprehensive understanding of the event and prepare for potential escalation or further analysis.
-
-### False positive analysis
-
-- Routine administrative actions: Domain administrators may intentionally disable the transfer lock as part of legitimate domain management tasks, such as preparing for a planned transfer to another registrar. Users should verify the intent behind such actions by cross-referencing with change management records or direct communication with the domain management team.
-- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage domain settings, which might include disabling the transfer lock as part of their operations. Users can handle these by identifying and excluding known scripts or tools from triggering alerts, ensuring they are documented and approved.
-- Testing and development environments: In non-production environments, disabling the transfer lock might be part of testing procedures. Users should maintain a list of test domains and exclude them from monitoring to avoid unnecessary alerts.
-- Known trusted users: If certain users or roles are frequently involved in legitimate domain transfer activities, consider creating exceptions for these users after verifying their actions are authorized and documented.
-
-### Response and remediation
-
-- Immediately verify the legitimacy of the domain transfer lock removal by contacting the domain's registered owner or administrator.
-- Temporarily re-enable the domain transfer lock to prevent any unauthorized transfers while the investigation is ongoing.
-- Review AWS CloudTrail logs for any suspicious activity related to the domain, focusing on the user or service account that performed the action.
-- Check for any recent changes in IAM policies or roles that might have allowed unauthorized access to Route 53 settings.
-- If unauthorized activity is confirmed, rotate credentials and update access controls for affected accounts to prevent further unauthorized actions.
-- Escalate the incident to the security operations team for a deeper investigation and to assess potential impacts on other domains or services.
-- Implement enhanced logging and monitoring for Route 53 activities, ensuring that alerts are generated for any future changes to domain transfer locks.
-- Integrate AWS CloudTrail logs with a SIEM solution to improve detection and response capabilities for similar incidents.
-- Conduct a post-incident review to identify gaps in security controls and update policies or procedures to prevent recurrence.
-- Educate relevant personnel on the importance of domain security and the risks associated with unauthorized domain transfers, incorporating lessons learned from the incident.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
index ad6f63592ec..758c5f25b39 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,51 +21,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route 53 Domain Transferred to Another Account"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Route 53 Domain Transferred to Another Account
-
-AWS Route 53 is a scalable DNS web service designed to route end-user requests to internet applications. Adversaries may exploit domain transfer capabilities to hijack domains, redirecting traffic or disrupting services. The detection rule monitors successful domain transfer requests, flagging potential unauthorized account manipulations, aligning with MITRE ATT&CK's persistence and account manipulation tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `route53.amazonaws.com`, ensuring the alert is relevant to a Route 53 domain transfer.
-- Verify the `event.action` field to ensure it is `TransferDomainToAnotherAwsAccount` and the `event.outcome` is `success`, confirming a successful domain transfer request.
-- Identify the AWS account ID and user or role that initiated the transfer by examining the `user.identity.arn` and `aws.account.id` fields in the event logs.
-- Check the `sourceIPAddress` field to determine the IP address from which the transfer request was made, and assess if it aligns with known or expected IP addresses for the account.
-- Investigate the `userAgent` field to understand the application or service used to initiate the transfer, looking for anomalies or unexpected user agents.
-- Use Osquery to gather additional context on the AWS environment by running a query such as: `SELECT * FROM aws_cloudtrail_events WHERE eventName = 'TransferDomainToAnotherAwsAccount' AND recipientAccountId = '<target_account_id>';` to identify other related events.
-- Review recent AWS CloudTrail logs for any unusual activity or patterns around the time of the domain transfer, focusing on changes to IAM policies or roles.
-- Examine the AWS Route 53 configuration and domain settings to ensure no unauthorized changes were made post-transfer, such as DNS record modifications.
-- Cross-reference the domain transfer event with any recent support tickets or change requests to validate if the transfer was authorized and documented.
-- Consult with the domain's business owner or relevant stakeholders to confirm the legitimacy of the transfer and gather any additional context or concerns they may have.
-
-### False positive analysis
-
-- Legitimate domain transfers between accounts within the same organization can trigger this rule as a false positive. These transfers might occur during organizational restructuring or when consolidating domains under a single account for management purposes.
-- Routine domain management activities by authorized personnel, such as IT administrators or domain management teams, may also result in false positives if they frequently transfer domains for operational reasons.
-- To manage these false positives, users can create exceptions for known and trusted account IDs involved in regular domain transfers. This can be done by maintaining a whitelist of account IDs that are authorized to perform domain transfers.
-- Implementing a review process for domain transfer requests can help distinguish between legitimate and suspicious activities. This process should involve verifying the intent and authorization of the transfer with the involved parties.
-- Regularly updating and auditing the list of authorized personnel and accounts can help minimize false positives by ensuring only current and necessary accounts are included in exception lists.
-
-### Response and remediation
-
-- Immediately revoke any unauthorized access to the AWS account by changing credentials and implementing multi-factor authentication (MFA) for all users.
-- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized actions or anomalies associated with the domain transfer.
-- Verify the integrity of DNS records and ensure that they have not been altered to redirect traffic maliciously.
-- Contact AWS Support to report the unauthorized domain transfer and seek assistance in reversing the transfer if necessary.
-- Notify relevant stakeholders, including IT security teams and management, about the incident and potential impacts on services.
-- Implement network monitoring to detect any unusual traffic patterns that may indicate further exploitation attempts.
-- Review and update IAM policies to ensure that only authorized personnel have permissions to transfer domains.
-- Enhance logging and monitoring by integrating AWS CloudTrail with a Security Information and Event Management (SIEM) system for real-time alerts.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on security best practices and the importance of safeguarding credentials to prevent future account manipulation attempts.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html"]
diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
index 7638b2aa8bb..50c7b0fa2ed 100644
--- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
+++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -20,51 +20,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route53 private hosted zone associated with a VPC"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Route53 private hosted zone associated with a VPC
-
-AWS Route53 private hosted zones allow for DNS management within a Virtual Private Cloud (VPC), ensuring internal resources are accessible only within the VPC. Adversaries may exploit this by associating unauthorized VPCs to intercept or reroute traffic. The detection rule monitors successful associations of VPCs with hosted zones, flagging potential unauthorized access or configuration changes indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `route53.amazonaws.com`, ensuring the alert is relevant to AWS Route53 activities.
-- Verify the event action is `AssociateVPCWithHostedZone` and the event outcome is `success` to confirm that a VPC was successfully associated with a private hosted zone.
-- Identify the AWS account and user or role that performed the action by examining the `userIdentity` field in the CloudTrail logs to determine if the action was authorized.
-- Check the `sourceIPAddress` field to identify the IP address from which the request originated, and assess if it aligns with known or expected IP addresses for your organization.
-- Investigate the `requestParameters` field to gather details about the VPC and hosted zone involved, including VPC ID and hosted zone ID, to understand the scope of the association.
-- Cross-reference the VPC ID with your organization's inventory to determine if the VPC is recognized and authorized to be associated with the hosted zone.
-- Use Osquery to query AWS metadata and configuration for further context. For example, run the following Osquery query to list all VPCs associated with a specific hosted zone: `SELECT * FROM aws_route53_vpc_associations WHERE hosted_zone_id = '<hosted_zone_id>';`.
-- Review recent changes in IAM policies or roles that might have granted new permissions related to Route53 or VPC associations, focusing on any modifications around the time of the event.
-- Analyze historical CloudTrail logs for any previous `AssociateVPCWithHostedZone` events to identify patterns or repeated unauthorized associations.
-- Consult with relevant stakeholders or teams to verify if the association was part of a planned change or deployment, ensuring alignment with organizational processes and approvals.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular operations by network administrators to associate VPCs with private hosted zones for legitimate purposes can trigger this rule. To manage this, create exceptions for known administrative accounts or specific time windows when these tasks are expected.
-- Automated infrastructure changes: Infrastructure as Code (IaC) tools like Terraform or AWS CloudFormation may automatically associate VPCs with hosted zones as part of deployment processes. Users can handle these by identifying and excluding specific automation accounts or tags associated with these tools.
-- Development and testing environments: Frequent changes in development or testing environments might lead to multiple VPC associations with hosted zones. Consider excluding specific environments or using tags to differentiate between production and non-production activities.
-- Multi-account setups: In organizations with multiple AWS accounts, cross-account VPC associations might be legitimate. Users should maintain a list of authorized accounts and exclude these from triggering alerts.
-- Scheduled maintenance: Planned maintenance activities might involve associating VPCs with hosted zones. Users can manage this by setting up maintenance windows and excluding activities during these periods from being flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected VPC to prevent further unauthorized access or traffic interception.
-- Review AWS CloudTrail logs to identify the source and time of the unauthorized VPC association and gather evidence for further investigation.
-- Verify the IAM roles and permissions to ensure that only authorized users have the ability to associate VPCs with Route53 private hosted zones.
-- Revoke any unauthorized access or credentials that may have been used to perform the VPC association.
-- Conduct a thorough review of all VPC associations with Route53 private hosted zones to ensure no other unauthorized associations exist.
-- Escalate the incident to the security operations team for a deeper investigation into potential persistence mechanisms or account manipulation tactics used by the adversary.
-- Implement enhanced logging and monitoring policies to detect future unauthorized changes to Route53 configurations, leveraging AWS CloudTrail and AWS Config.
-- Integrate AWS GuardDuty and other threat detection services to provide real-time alerts on suspicious activities related to DNS and VPC configurations.
-- Restore the system to its operational state by reconfiguring the Route53 private hosted zone associations to only include authorized VPCs.
-- Apply hardening measures such as multi-factor authentication (MFA) for all IAM users and regular audits of access permissions to prevent future unauthorized access.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html"]
diff --git a/rules/integrations/aws/persistence_route_table_created.toml b/rules/integrations/aws/persistence_route_table_created.toml
index c8f43c8b2c1..c254309c058 100644
--- a/rules/integrations/aws/persistence_route_table_created.toml
+++ b/rules/integrations/aws/persistence_route_table_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,51 +21,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route Table Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Route Table Created
-
-AWS Route Tables are crucial for directing network traffic within AWS environments, defining how packets are routed between subnets and external networks. Adversaries may exploit this by creating unauthorized routes to intercept or redirect traffic, potentially leading to data exfiltration or service disruption. The detection rule monitors successful creation events of route tables, flagging potential misuse by identifying unexpected or suspicious activity patterns.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `aws.cloudtrail` and the event provider is `ec2.amazonaws.com`, ensuring the alert is relevant to AWS Route Table creation.
-- Verify the event action is either `CreateRoute` or `CreateRouteTable` and the event outcome is `success` to confirm the alert is triggered by a successful route table creation.
-- Identify the AWS account and region where the route table was created to understand the scope and potential impact of the event.
-- Check the identity information (user or role) associated with the event to determine if the action was performed by an expected or authorized entity.
-- Investigate the source IP address and user agent from which the request originated to identify any unusual access patterns or locations.
-- Review CloudTrail logs for additional context around the time of the event to identify any related or suspicious activities.
-- Use Osquery to gather more information about the AWS environment. For example, run the following query to list all route tables in the account: `SELECT * FROM aws_ec2_route_tables;`
-- Analyze the route table configuration to identify any unauthorized or suspicious routes that could indicate malicious intent.
-- Cross-reference the route table creation event with IAM policies and permissions to ensure the user or role had legitimate access to perform the action.
-- Consult with the relevant AWS account owner or administrator to verify if the route table creation was part of an expected change or deployment.
-
-### False positive analysis
-
-- Routine infrastructure changes: Regular updates or expansions in AWS environments may involve creating new route tables, which can trigger the detection rule. Users should review change management logs to verify if the route table creation aligns with planned activities.
-- Automated deployment tools: Tools like AWS CloudFormation, Terraform, or other infrastructure-as-code solutions may automatically create route tables as part of their deployment processes. Users can create exceptions for specific IAM roles or user accounts associated with these tools to reduce noise.
-- Testing and development environments: Route tables created in non-production environments for testing purposes might be flagged. Users can exclude specific AWS accounts or regions dedicated to development and testing to minimize false positives.
-- Third-party integrations: Some third-party services or applications may require the creation of route tables for integration purposes. Users should identify and whitelist these services to prevent unnecessary alerts.
-- Temporary configurations: Short-term projects or experiments might necessitate the creation of route tables. Users can implement time-based exceptions to account for these temporary changes, ensuring they are automatically removed after a set period.
-
-### Response and remediation
-
-- Immediately review the AWS CloudTrail logs to verify the source and context of the route table creation event, ensuring it aligns with expected administrative actions.
-- Identify and isolate any unauthorized route tables by removing or disabling them to prevent potential data exfiltration or service disruption.
-- Conduct a thorough investigation to determine if any unauthorized access or changes have been made to other network configurations or resources.
-- Escalate the incident to the security operations team if the activity is confirmed to be malicious or if there is evidence of a broader compromise.
-- Implement AWS Identity and Access Management (IAM) policies to restrict route table creation permissions to only necessary personnel or roles.
-- Enable detailed logging and monitoring for AWS network activities, including route table changes, to enhance visibility and facilitate future investigations.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious network configuration changes.
-- Review and update the incident response plan to include specific procedures for handling unauthorized network configuration changes.
-- Restore the system to its operational state by verifying that all network routes are correctly configured and that no unauthorized routes remain.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as network segmentation and enhanced access controls, to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
index 77cc617cb1e..8829dc1659b 100644
--- a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
+++ b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,47 +21,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route Table Modified or Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Route Table Modified or Deleted
-
-AWS Route Tables direct network traffic within a VPC, crucial for maintaining secure and efficient communication. Adversaries may alter or delete route tables to reroute traffic, disrupt services, or exfiltrate data. The detection rule monitors successful modifications or deletions of route tables, identifying potential unauthorized changes by analyzing specific AWS CloudTrail events related to EC2 actions.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to identify the specific `event.action` that triggered the alert, focusing on actions like `ReplaceRoute`, `ReplaceRouteTableAssociation`, `DeleteRouteTable`, `DeleteRoute`, or `DisassociateRouteTable`.
-- Examine the `event.outcome` field to confirm the success of the action and ensure that the alert is not a false positive.
-- Identify the `user.identity` field in the CloudTrail logs to determine which IAM user or role performed the action, and verify if this user is authorized to make such changes.
-- Check the `sourceIPAddress` field to see where the request originated from, and assess if this IP address is expected or known within your network.
-- Investigate the `event.time` to understand when the modification or deletion occurred and correlate it with any other suspicious activities or alerts around the same time.
-- Use the `aws.region` field to determine the region where the change was made, and verify if this aligns with your organization's standard operations.
-- Query the AWS Config service to review the historical configuration of the affected route table and identify any previous changes or patterns.
-- Utilize Osquery to gather additional context by running a query such as: `SELECT * FROM aws_vpc_route_tables WHERE route_table_id = '<affected_route_table_id>';` to retrieve current route table configurations and compare them with expected settings.
-- Cross-reference the affected route table with any associated VPCs, subnets, or network interfaces to assess the potential impact on your network architecture.
-- Review any recent IAM policy changes or access key usage for the identified user to ensure there are no signs of credential compromise or privilege escalation.
-
-### False positive analysis
-
-- Routine infrastructure changes by authorized personnel can trigger alerts, such as scheduled updates or maintenance activities, which are not malicious. - Automated processes or scripts that modify route tables for scaling or failover purposes may also result in false positives. - To manage these, users can create exceptions for known IP addresses or IAM roles that regularly perform these actions. - Implementing a change management process and documenting expected modifications can help differentiate between legitimate and suspicious activities. - Regularly review and update the list of exceptions to ensure they align with current operational practices and security policies.
-
-### Response and remediation
-
-- Immediately isolate the affected VPC to prevent further unauthorized access or data exfiltration.
-- Review AWS CloudTrail logs to identify the source and scope of the unauthorized changes to the route tables.
-- Verify the integrity of other network configurations within the VPC to ensure no additional unauthorized modifications have been made.
-- Restore the route tables to their last known good configuration using backups or documented configurations.
-- Implement AWS Identity and Access Management (IAM) policies to restrict permissions for modifying route tables to only essential personnel.
-- Enable detailed logging and monitoring for all VPC and route table changes to ensure real-time detection of unauthorized activities.
-- Conduct a security review of the affected AWS account to identify and remediate any other potential vulnerabilities or misconfigurations.
-- Escalate the incident to the security operations team for further investigation and to determine if the incident is part of a larger attack.
-- Update incident response plans and playbooks to include lessons learned from the incident and improve future response efforts.
-- Consider implementing additional security measures such as AWS Config rules and GuardDuty to enhance detection and prevention of unauthorized network changes.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
index 6b80a7fbe29..c4dcc60e1a5 100644
--- a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
+++ b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/25"
 
 
 [rule]
@@ -18,50 +18,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS AssumeRole with New MFA Device"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS STS AssumeRole with New MFA Device
-
-AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse by monitoring specific AWS CloudTrail events and parameters.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user and role involved in the AssumeRole event, focusing on the `user.id` and `aws.cloudtrail.flattened.request_parameters.serialNumber` fields.
-- Verify the legitimacy of the new MFA device by checking the AWS IAM console for recent changes or additions to MFA devices associated with the user.
-- Cross-reference the `event.provider` and `event.action` fields to confirm the type of AssumeRole action taken and ensure it aligns with expected user behavior.
-- Analyze the `event.outcome` field to ensure the role assumption was successful and not part of a failed attempt pattern.
-- Investigate the source IP address and geolocation from which the AssumeRole request originated to identify any anomalies or unexpected locations.
-- Check the AWS CloudTrail logs for any preceding or subsequent suspicious activities related to the same user or role, such as changes in permissions or unusual API calls.
-- Use Osquery to gather additional context on the user's activity on their local machine. For example, run a query to list recent AWS CLI commands executed: `SELECT * FROM shell_history WHERE command LIKE '%aws%' AND user = '<username>';`.
-- Review the user's recent login history and access patterns to determine if there are any deviations from their normal behavior.
-- Consult with the user or their manager to verify if the new MFA device was legitimately added and if the role assumption was expected as part of their duties.
-- Document all findings and observations in the investigation report, highlighting any indicators of compromise or benign explanations for the alert.
-
-### False positive analysis
-
-- Users frequently adding new MFA devices for legitimate reasons, such as device upgrades or replacements, can trigger false positives. To manage this, maintain a list of known device changes and exclude these from alerts.
-- Organizational policy changes that require users to update or rotate MFA devices can result in multiple role assumptions with new devices. Implement a temporary exception during the policy change period to reduce noise.
-- Automated processes or scripts that involve role assumptions with new MFA devices for testing or deployment purposes may be flagged. Identify and whitelist these processes to prevent unnecessary alerts.
-- Shared accounts or roles used by multiple team members might show new MFA devices as different users authenticate. Consider monitoring these accounts separately and establish a baseline of expected behavior to differentiate between legitimate and suspicious activity.
-
-### Response and remediation
-
-- Verify the legitimacy of the new MFA device by contacting the user or reviewing the change request logs to ensure it was an authorized action.
-- Temporarily disable the assumed role or the associated user account if the new MFA device is deemed suspicious or unauthorized.
-- Review AWS CloudTrail logs for any unusual activity associated with the user or role, focusing on actions taken after the role assumption.
-- Conduct a thorough investigation to determine if any unauthorized changes or data access occurred during the session with the temporary credentials.
-- Escalate the incident to the security operations team if unauthorized access or malicious activity is confirmed, following the organization's incident response plan.
-- Implement additional logging and monitoring for AWS STS and MFA-related activities to detect similar incidents in the future.
-- Review and update IAM policies to ensure that only necessary permissions are granted and consider implementing least privilege principles.
-- Educate users on the importance of securing MFA devices and recognizing phishing attempts that could lead to unauthorized MFA registration.
-- Restore any unauthorized changes made during the incident to return the system to its operational state, ensuring data integrity and security.
-- Consider implementing additional security measures such as conditional access policies or more frequent reviews of MFA device registrations to enhance overall security posture.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
index 5e74f3fd992..1e152b855ff 100644
--- a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
+++ b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Instance Connect SSH Public Key Uploaded"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS EC2 Instance Connect SSH Public Key Uploaded
 
diff --git a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
index a857e24bbce..0e20b0ca5e4 100644
--- a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Customer-Managed Policy Attached to Role by Rare User"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS IAM Customer-Managed Policy Attachment to Role by Unusual User
 
diff --git a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
index 77e834aea16..7d54a01401c 100644
--- a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/16"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -19,50 +19,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM SAML Provider Updated"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS IAM SAML Provider Updated
-
-AWS IAM SAML providers facilitate federated access, allowing users to authenticate via external identity providers. Adversaries may exploit this by updating SAML providers to gain unauthorized access or escalate privileges. The detection rule monitors successful updates to SAML providers, flagging potential privilege escalation attempts by correlating specific AWS CloudTrail events.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to identify the user or role that performed the `UpdateSAMLProvider` action by examining the `userIdentity` field.
-- Check the `eventTime` field in the CloudTrail logs to determine when the update occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the `sourceIPAddress` field to identify the IP address from which the update was made and determine if it is a known or trusted source.
-- Examine the `userAgent` field to understand the application or service used to perform the update, which might provide additional context about the activity.
-- Verify the `requestParameters` field to see what specific changes were made to the SAML provider, such as metadata updates or certificate changes.
-- Cross-reference the `awsRegion` field to ensure the activity aligns with expected geographic locations for your AWS operations.
-- Use Osquery to gather additional context on the AWS environment by running a query like: `SELECT * FROM aws_iam_saml_providers WHERE name = '<SAML Provider Name>'` to retrieve details about the current configuration of the SAML provider.
-- Check for any recent IAM policy changes or role modifications that might be related to the SAML provider update, which could indicate a broader privilege escalation attempt.
-- Review any recent login attempts or access patterns for the user or role identified in the `userIdentity` field to detect any anomalies or unauthorized access.
-- Consult with the team responsible for identity and access management to confirm whether the SAML provider update was expected and authorized, and gather any additional context they might have.
-
-### False positive analysis
-
-- Routine administrative updates: Regular updates to SAML providers by authorized personnel for maintenance or configuration changes can trigger this rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated scripts or tools: Organizations may use automated tools to update SAML providers as part of their identity management processes. Identify these tools and exclude their activity from triggering alerts by whitelisting their associated accounts or IP addresses.
-- Third-party integrations: Some third-party services may require updates to SAML providers for integration purposes. Document these services and exclude their known update patterns to prevent false positives.
-- Frequent legitimate changes: In dynamic environments where SAML provider updates are common, establish a baseline of normal activity and adjust the detection thresholds or alerting criteria to reduce noise from expected changes.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS account to prevent further unauthorized access by disabling the updated SAML provider.
-- Review AWS CloudTrail logs to identify any unauthorized changes or suspicious activities associated with the SAML provider update.
-- Verify the identity and permissions of the user who performed the update to ensure it aligns with expected behavior and access policies.
-- Revert any unauthorized changes to the SAML provider configuration to restore the system to its previous operational state.
-- Conduct a thorough investigation to determine if any other AWS resources or accounts have been compromised.
-- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization.
-- Implement enhanced logging and monitoring for AWS IAM activities, focusing on SAML provider updates and other critical changes.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to improve real-time detection and alerting capabilities.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring only authorized users can modify SAML providers.
-- Conduct regular security awareness training for users on the risks associated with federated access and the importance of maintaining secure configurations.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
index 00f976acafe..c23ae37fbfb 100644
--- a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
+++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS Role Assumption by Service"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS STS Role Assumption by Service
 
diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
index 0239f26ff66..da41ca73b82 100644
--- a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
+++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS Role Assumption by User"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating AWS STS Role Assumption by User
 
diff --git a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
index a17bc1e8242..3bb48c3b9a7 100644
--- a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/24"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS AssumeRoot by Rare User and Member Account"
 note = """
-## Triage and analysis
+## Triage and Analysis
 
 ### Investigating AWS STS AssumeRoot by Rare User and Member Account
 
diff --git a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
index 3a4afc7a1ea..7bde75f679e 100644
--- a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,51 +21,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS GetSessionToken Abuse"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS STS GetSessionToken Abuse
-
-AWS Security Token Service (STS) provides temporary credentials for AWS resources. Adversaries may exploit the GetSessionToken API to generate tokens, enabling lateral movement and privilege escalation within an environment. The detection rule identifies successful GetSessionToken requests by IAM users, signaling potential misuse by attackers to gain unauthorized access or elevate privileges.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `event.dataset:aws.cloudtrail`, `event.provider:sts.amazonaws.com`, `event.action:GetSessionToken`, `aws.cloudtrail.user_identity.type:IAMUser`, and `event.outcome:success` to ensure the alert is valid and matches the detection rule criteria.
-- Identify the IAM user associated with the GetSessionToken request by examining the `aws.cloudtrail.user_identity.arn` field to determine if the user is expected to perform such actions.
-- Check the `aws.cloudtrail.sourceIPAddress` field to verify the source IP address of the request and determine if it is from a known or expected location.
-- Investigate the `aws.cloudtrail.user_agent` field to identify the client or tool used to make the request, which may provide insights into whether the request was automated or manual.
-- Analyze the `aws.cloudtrail.recipientAccountId` field to confirm the account targeted by the GetSessionToken request and assess if it aligns with normal operations.
-- Review historical CloudTrail logs for the identified IAM user to detect any unusual patterns or deviations in behavior leading up to the GetSessionToken request.
-- Use Osquery to gather additional context on the system from which the request originated. For example, run the following query to list recent AWS CLI commands executed on the host: `SELECT * FROM shell_history WHERE command LIKE '%aws%' ORDER BY time DESC LIMIT 10;`.
-- Cross-reference the GetSessionToken request with other AWS CloudTrail events to identify any subsequent actions taken using the temporary credentials, such as accessing sensitive resources or modifying configurations.
-- Investigate any recent changes to IAM policies or roles associated with the IAM user to determine if permissions were altered to facilitate the GetSessionToken request.
-- Collaborate with the account owner or relevant stakeholders to verify if the GetSessionToken request was authorized and part of legitimate activities, or if it indicates potential misuse.
-
-### False positive analysis
-
-- Routine administrative tasks: IAM users may frequently use GetSessionToken for legitimate purposes such as accessing AWS resources temporarily. These actions can be mistaken for malicious activity. To manage this, identify and document regular patterns of GetSessionToken usage by trusted users and exclude these from alerts.
-- Automated scripts and applications: Some applications or scripts might be configured to use GetSessionToken for temporary access. These should be reviewed and, if deemed non-threatening, added to an exception list to prevent false alerts.
-- Third-party integrations: External services integrated with AWS may use GetSessionToken as part of their normal operation. Verify these integrations and exclude their activity from detection rules if they are legitimate and secure.
-- Development and testing environments: Developers might use GetSessionToken during testing or development phases. Monitor these environments separately and consider excluding known development accounts from alerts to reduce noise.
-- Cross-account access: In environments with multiple AWS accounts, GetSessionToken might be used for cross-account access. Ensure that these actions are part of approved workflows and exclude them if they are verified as non-malicious.
-
-### Response and remediation
-
-- Immediately revoke the temporary credentials associated with the suspicious GetSessionToken request to prevent further unauthorized access.
-- Isolate the affected IAM user account by disabling it or applying a restrictive policy to limit its permissions until the investigation is complete.
-- Conduct a thorough review of CloudTrail logs to identify any anomalous activities or patterns associated with the compromised credentials, focusing on lateral movement and privilege escalation attempts.
-- Cross-reference the IAM user's activities with known MITRE ATT&CK techniques, such as T1548, to understand the potential impact and scope of the attack.
-- Notify the security operations team and relevant stakeholders about the incident and escalate to higher management if the threat level is deemed critical.
-- Implement enhanced logging and monitoring for AWS STS and IAM activities to detect similar suspicious behavior in the future, ensuring that logs are retained for an adequate period.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious GetSessionToken activities.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring that users have only the permissions necessary for their roles.
-- Conduct a security awareness session for the team to highlight the risks associated with AWS STS and the importance of monitoring and securing temporary credentials.
-- After confirming the environment is secure, restore normal operations by re-enabling the IAM user account with appropriate permissions and continue to monitor for any further suspicious activities.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html"]
diff --git a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
index e4531d2ab37..8fad43bd2ff 100644
--- a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/23"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/23"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ from = "now-6m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS STS Role Chaining"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS STS Role Chaining
-
-AWS STS (Security Token Service) allows temporary, limited-privilege credentials for AWS resources. Role chaining involves using one temporary role to assume another, potentially escalating privileges if the second role has more access. Adversaries exploit this for privilege escalation or persistence. The detection rule identifies such activity by monitoring specific API calls and access patterns within a single account, focusing on temporary credentials to spot potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `aws.cloudtrail.user_identity.arn` to identify the user or service that initiated the role chaining.
-- Examine the `aws.cloudtrail.user_identity.access_key_id` to confirm it begins with "ASIA", indicating the use of temporary credentials.
-- Check the `cloud.region` field to determine the geographical location of the activity and assess if it aligns with expected operations.
-- Analyze the `aws.cloudtrail.resources.account_id` and `aws.cloudtrail.recipient_account_id` to ensure the activity is confined within a single account, ruling out cross-account role assumptions.
-- Investigate the history of the `aws.cloudtrail.user_identity.arn` to identify any unusual patterns or recent changes in behavior.
-- Use Osquery to gather additional context on the system where the role chaining was initiated. Example query: `SELECT * FROM aws_sts WHERE access_key_id LIKE 'ASIA%' AND arn = '<user_arn>';`
-- Correlate the `AssumeRole` events with other logs to identify any subsequent actions taken using the assumed role, focusing on sensitive operations.
-- Review IAM policies associated with the roles involved to determine if the permissions granted could lead to privilege escalation.
-- Check for any recent changes to IAM roles or policies that might have inadvertently allowed for increased privileges.
-- Consult with relevant stakeholders or system owners to verify if the role chaining activity was expected or authorized as part of normal operations.
-
-### False positive analysis
-
-- Role chaining within a single account for legitimate operational purposes can trigger false positives. This often occurs in environments where automated processes or scripts frequently assume roles for routine tasks.
-- Cross-account role assumptions are common in multi-account AWS environments, but this rule specifically filters them out to reduce false positives. However, similar patterns within a single account can still be flagged.
-- Users can manage these false positives by creating exceptions for known, benign role chaining activities. This can be done by maintaining a list of trusted role ARNs or access key IDs that are known to perform legitimate role chaining.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, and monitor for any changes in access patterns that might indicate misuse.
-
-### Response and remediation
-
-- Immediately revoke the temporary credentials associated with the suspicious AssumeRole activity to prevent further unauthorized access.
-- Conduct a thorough investigation of the AWS CloudTrail logs to identify the source and scope of the role chaining activity, focusing on the user identity and access patterns.
-- Verify the permissions of the roles involved in the chaining to ensure they do not exceed the intended access levels and adjust policies to adhere to the principle of least privilege.
-- Escalate the incident to the security operations team if the role chaining activity is linked to a known threat actor or if it involves sensitive resources.
-- Implement enhanced logging and monitoring for AWS STS and IAM activities to detect similar patterns in the future, ensuring that all AssumeRole actions are logged and reviewed.
-- Integrate AWS CloudTrail logs with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious role chaining activities.
-- Review and update the AWS IAM policies and roles to include multi-factor authentication (MFA) for sensitive operations to reduce the risk of unauthorized access.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Restore any affected systems or services to their operational state by rolling back unauthorized changes and verifying the integrity of critical resources.
-- Educate and train staff on the risks associated with role chaining and the importance of adhering to security best practices to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
index 3c846f3c55d..b3ffe646b7d 100644
--- a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
+++ b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -25,51 +25,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Event Hub Authorization Rule Created or Updated"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Event Hub Authorization Rule Created or Updated
-
-Azure Event Hub Authorization Rules manage access to Event Hubs, using cryptographic keys to define permissions. Adversaries may exploit these rules to gain unauthorized access, potentially extracting sensitive data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `azure.activitylogs` and the operation name is `MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE` with a successful outcome.
-- Identify the user or service principal that performed the operation by examining the `azure.activitylogs.caller` field.
-- Check the timestamp of the event to determine when the authorization rule was created or updated.
-- Investigate the specific Event Hub namespace affected by reviewing the `azure.activitylogs.resource_id` field to understand the scope of the change.
-- Correlate the event with other recent activities by the same user or service principal to identify any suspicious patterns or anomalies.
-- Examine the `azure.activitylogs.correlation_id` to trace related operations and understand the broader context of the activity.
-- Use Osquery to query Azure logs for additional context, such as: `SELECT * FROM azure_activitylogs WHERE operation_name = 'MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE' AND outcome = 'Success';`
-- Review any associated network or application logs to identify potential data exfiltration or unauthorized access attempts following the rule change.
-- Check for any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to the user or service principal involved.
-- Consult with the relevant application or infrastructure teams to verify if the change was expected and authorized, and gather any additional context or documentation related to the change.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or creations of authorization rules by system administrators or automated scripts can trigger alerts. To manage these, users can create exceptions for known administrative accounts or scheduled tasks that frequently perform these operations.
-- Deployment and configuration changes: During the deployment of new applications or updates to existing ones, authorization rules may be created or modified as part of the setup process. Users can exclude these events by identifying and filtering out activities associated with specific deployment tools or processes.
-- Testing and development environments: In non-production environments, developers may frequently create or update authorization rules for testing purposes. Users can handle these by setting up separate monitoring rules or excluding specific environments from triggering alerts.
-- Third-party integrations: Some third-party services or integrations may require the creation or modification of authorization rules. Users should document and exclude these known integrations to prevent false positives.
-- Service health checks: Automated health checks or monitoring services might create or update authorization rules as part of their operation. Users can identify these services and exclude their activities from alerting.
-
-### Response and remediation
-
-- Immediately review the Azure Activity Logs to confirm the creation or modification of the Event Hub Authorization Rule and identify the user or service principal responsible for the change.
-- Contain the potential threat by revoking the modified or newly created authorization rule if it is deemed unauthorized or suspicious.
-- Investigate the source of the change by checking the associated IP addresses, user agents, and timestamps to determine if the activity aligns with expected behavior.
-- Escalate the incident to the security operations team if the activity is confirmed to be unauthorized or if there is evidence of data exfiltration.
-- Implement additional logging and monitoring for Azure Event Hubs to capture detailed access and modification events, ensuring that all changes are auditable.
-- Review and update access policies to ensure that only necessary permissions are granted, and consider using Azure Managed Identities to reduce reliance on cryptographic keys.
-- Conduct a security review of all Event Hub Authorization Rules to ensure compliance with the principle of least privilege.
-- Restore the system to its operational state by reapplying any necessary authorization rules that were revoked during containment, ensuring they are configured securely.
-- Enhance future investigations by integrating Azure Security Center and Azure Sentinel for advanced threat detection and response capabilities.
-- Implement hardening measures such as regular audits of authorization rules, enforcing multi-factor authentication, and using Azure Policy to enforce security best practices across the environment.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-shared-access-signature"]
diff --git a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
index 353f914e356..8bb0b88fad1 100644
--- a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
+++ b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/12/11"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "Azure Entra MFA TOTP Brute Force Attempts"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating Azure Entra MFA TOTP Brute Force Attempts
 
diff --git a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
index fe681292190..92c23e47a2b 100644
--- a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
+++ b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,50 +24,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Full Network Packet Capture Detected"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Full Network Packet Capture Detected
-
-Azure Network Watcher's packet capture feature allows for detailed inspection of network traffic, aiding in diagnostics and performance monitoring. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to intercept credentials or other confidential information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure operations and successful outcomes, alerting analysts to potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific operation name and outcome, focusing on `azure.activitylogs.operation_name` and `event.outcome` fields to confirm the type of packet capture activity detected.
-- Check the timestamp of the alert to determine when the packet capture was initiated and correlate it with any other suspicious activities in the same timeframe.
-- Identify the user or service principal associated with the packet capture operation by examining the `azure.activitylogs.caller` field to determine if the activity aligns with expected behavior.
-- Investigate the source IP address and location from which the packet capture was initiated using the `azure.activitylogs.callerIpAddress` field to identify any anomalies or unauthorized access.
-- Analyze the resource group and network interface involved in the packet capture by reviewing the `azure.activitylogs.resource` field to understand the scope and potential impact of the capture.
-- Cross-reference the packet capture activity with any recent changes in network configurations or deployments to identify if the capture was part of a legitimate change or deployment process.
-- Utilize Osquery to gather additional context on the systems involved. For example, run an Osquery query to list recent network connections on the affected virtual machines: `SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious IP>';`.
-- Check for any other alerts or logs related to network sniffing or credential access attempts in the same environment to identify potential patterns or coordinated attacks.
-- Review access logs and permissions for the Azure Network Watcher to ensure that only authorized personnel have the ability to initiate packet captures.
-- Consult with the network and security teams to verify if the packet capture aligns with any ongoing troubleshooting or monitoring activities, ensuring that it was not a sanctioned operation.
-
-### False positive analysis
-
-- Routine network diagnostics: Regularly scheduled packet captures for legitimate network diagnostics or performance monitoring can trigger this detection. Users can manage these by creating exceptions for known diagnostic operations or specific time windows when these activities are expected.
-- Security audits: Organizations conducting security audits may intentionally perform packet captures to assess network security. To handle these, users can whitelist specific audit-related operations or IP addresses involved in the audit process.
-- Automated monitoring tools: Some automated tools may initiate packet captures as part of their monitoring processes. Users should identify these tools and exclude their activities from triggering alerts by specifying their operation names or associated user accounts.
-- Testing environments: In testing or development environments, packet captures might be used frequently for troubleshooting. Users can exclude these environments by filtering based on resource groups or tags associated with non-production environments.
-
-### Response and remediation
-
-- Immediately isolate the affected Azure resources to prevent further data exposure or unauthorized access.
-- Review Azure activity logs to identify the source and scope of the packet capture activity, focusing on the specific operations flagged by the detection rule.
-- Verify the legitimacy of the packet capture request by contacting the resource owner or administrator to confirm if the activity was authorized.
-- If unauthorized, revoke any compromised credentials and enforce a password reset for affected accounts.
-- Escalate the incident to the security operations team for further investigation and to determine if any data was exfiltrated.
-- Implement network segmentation to limit the exposure of sensitive data and reduce the risk of unauthorized packet capture.
-- Enhance logging and monitoring by enabling Azure Security Center and integrating with a Security Information and Event Management (SIEM) system for real-time alerts and analysis.
-- Conduct a thorough review of access controls and permissions to ensure that only authorized personnel can initiate packet captures.
-- Restore affected systems to their operational state by applying any necessary patches or updates and verifying system integrity.
-- Implement hardening measures such as encrypting internal traffic and using secure protocols to mitigate the risk of network sniffing in the future.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"]
diff --git a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
index 02211441084..65b062f0ebf 100644
--- a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
+++ b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/26"
 
 [rule]
 author = ["Elastic"]
@@ -43,49 +43,6 @@ query = '''
         azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e
         and azure.activitylogs.properties.authentication_protocol:deviceCode)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Entra ID Device Code Auth with Broker Client
-
-Entra ID Device Code Authentication facilitates seamless access to Azure resources by leveraging device-based controls and Primary Refresh Tokens (PRTs). Adversaries exploit PRTs to bypass multi-factor authentication, gaining unauthorized access. The detection rule identifies suspicious sign-ins by monitoring device code authentications linked to a specific broker client application, flagging potential misuse of PRTs.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e) in the sign-in logs, focusing on the `azure.signinlogs.properties.conditional_access_audiences.application_id` field.
-- Examine the `event.dataset` field to determine whether the alert originated from `azure.activitylogs` or `azure.signinlogs`, as this will guide the context of the investigation.
-- Analyze the `azure.signinlogs.properties.authentication_protocol` field to verify that the authentication protocol used was `deviceCode`, confirming the method of access.
-- Check the `event.outcome` field to ensure the sign-in attempt was successful, which is crucial for identifying unauthorized access.
-- Investigate the user account associated with the alert to determine if there are any known security incidents or unusual activities linked to this account.
-- Use Osquery to gather additional context on the device involved in the authentication attempt. For example, run a query to list all recent logins on the device: `SELECT * FROM logins WHERE user = '<username>';`.
-- Review the `azure.activitylogs.properties.appId` field in the activity logs to identify any other applications accessed using the same broker client application ID.
-- Correlate the sign-in event with other security logs to identify any concurrent suspicious activities, such as changes in user permissions or unusual data access patterns.
-- Investigate the IP address and location associated with the sign-in attempt to determine if it aligns with the user's typical access patterns or if it appears suspicious.
-- Check for any recent changes in Conditional Access policies that might have inadvertently allowed the bypass of multi-factor authentication, focusing on policies related to device-based controls.
-
-### False positive analysis
-
-- Legitimate device code authentications by trusted applications or services may trigger the rule if they use the same broker client application ID. Users should verify the source of the authentication and assess whether it aligns with expected behavior.
-- Frequent sign-ins from known and secure devices using device code authentication might be flagged. To manage this, users can create exceptions for specific device IDs or IP addresses that are consistently verified as non-threatening.
-- Automated processes or scripts that utilize device code authentication for legitimate purposes could be misidentified as suspicious. Users should document and exclude these processes by adding them to an allowlist based on their application ID or other identifying attributes.
-- Organizations with a high volume of device code authentications due to legitimate business operations may experience numerous alerts. Implementing a baseline of normal activity and adjusting the rule's sensitivity can help reduce false positives.
-- Collaboration tools or third-party applications integrated with Azure that use device code authentication might be mistakenly flagged. Users should review these integrations and, if deemed safe, exclude them from the rule by specifying their application IDs.
-
-### Response and remediation
-
-- Immediately isolate the affected device from the network to prevent further unauthorized access.
-- Revoke all active Primary Refresh Tokens (PRTs) associated with the compromised account to disrupt the adversary's access.
-- Conduct a thorough investigation of the sign-in logs and activity logs to identify any unauthorized access or actions taken by the adversary.
-- Reset passwords and enforce multi-factor authentication (MFA) for all accounts involved in the incident to enhance security.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems or accounts have been compromised.
-- Implement enhanced logging policies to capture detailed authentication and access events, ensuring comprehensive monitoring of device code authentications.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities in real-time.
-- Restore the affected systems to their operational state by applying the latest security patches and updates, and verifying the integrity of critical files and configurations.
-- Conduct a post-incident review to identify gaps in security controls and update the incident response plan accordingly.
-- Implement hardening measures such as restricting device code authentication to trusted devices and applications, and regularly reviewing and updating Conditional Access policies."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
index e57c6cdc716..32a179c5ecd 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 
 [rule]
 author = ["Elastic"]
@@ -25,51 +25,7 @@ language = "esql"
 interval = "10m"
 license = "Elastic License v2"
 name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
-
-Azure Entra, part of Microsoft's identity and access management suite, secures Microsoft 365 accounts by managing sign-ins and authentication. Adversaries may exploit this by attempting numerous failed logins to guess passwords, aiming to gain unauthorized access to services like Exchange or Teams. The detection rule identifies such brute-force attempts by analyzing sign-in logs for high volumes of failed logins or diverse login sources within a short timeframe, flagging potential threats for further investigation.
-
-### Possible investigation steps
-
-- Review the `target_time_window` to determine the specific 30-minute period during which the brute-force attempts occurred, providing a focused timeframe for further analysis.
-- Examine the `azure.signinlogs.properties.user_principal_name` to identify the specific user accounts targeted by the brute-force attempts, allowing for a user-centric investigation.
-- Analyze the `source.ip` field to identify the IP addresses involved in the failed login attempts, which can help in determining if the attempts are coming from known malicious sources or unusual locations.
-- Check the `azure.signinlogs.properties.resource_display_name` to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted, providing insight into the attacker's potential objectives.
-- Investigate the `event.outcome` to confirm the nature of the failed attempts and cross-reference with known error codes from the Azure documentation to understand the specific reasons for failure.
-- Utilize Osquery to gather additional context on the affected systems. For example, run a query to list recent login attempts on the endpoint: `SELECT * FROM users WHERE username = '<target_user>' AND last_login > '<target_time_window_start>' AND last_login < '<target_time_window_end>';`
-- Correlate the `login_source_count` and `failed_login_count` with historical data to determine if this is an isolated incident or part of a larger pattern of attacks against the organization.
-- Investigate any unusual patterns or anomalies in the `event.dataset` and `event.category` fields to identify if the attack is leveraging specific authentication methods or protocols.
-- Cross-reference the identified `source.ip` addresses with threat intelligence feeds to check for any known associations with malicious activity.
-- Review any additional logs or alerts from other security tools that may provide context or corroborate the findings from the Azure Entra sign-in logs, such as firewall logs or endpoint detection and response (EDR) alerts.
-
-### False positive analysis
-
-- High-volume legitimate access: Users with roles that require frequent access to multiple Microsoft 365 services, such as IT administrators or support staff, may trigger false positives due to their high number of login attempts. To manage this, create exceptions for known user accounts or IP addresses associated with these roles.
-- Automated scripts or applications: Some organizations use automated scripts or applications that perform regular sign-ins to Microsoft 365 services for maintenance or data retrieval. These can be mistaken for brute-force attempts. Identify and whitelist these scripts or applications by their user agent or IP address.
-- Shared IP addresses: Users accessing Microsoft 365 services from shared networks, such as corporate VPNs or educational institutions, may appear to have multiple login sources. To handle this, exclude known shared IP ranges from the rule.
-- Frequent password changes: Organizations with policies that enforce regular password changes may see an increase in failed login attempts as users adjust to new credentials. Consider extending the monitoring window or adjusting the threshold for failed attempts during these periods.
-- Third-party integrations: Integrations with third-party services that require frequent authentication to Microsoft 365 can generate numerous failed attempts if not configured correctly. Review and adjust the settings of these integrations to ensure they are not flagged as threats.
-
-### Response and remediation
-
-- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.
-- Conduct a thorough investigation of the sign-in logs to identify the source IP addresses and determine if they are associated with known malicious activity.
-- Reset passwords for the compromised accounts and enforce multi-factor authentication (MFA) to enhance security.
-- Notify the affected users and relevant stakeholders about the incident and provide guidance on recognizing phishing attempts and securing their accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other accounts or systems are affected.
-- Implement conditional access policies to restrict access based on location, device compliance, and risk level to prevent future brute-force attempts.
-- Review and update logging policies to ensure comprehensive capture of authentication events and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply security patches and updates to all systems and applications to mitigate vulnerabilities that could be exploited in similar attacks.
-- Educate users on best practices for password management and the importance of using unique, strong passwords for different accounts.
-
-This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
+note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."
 references = [
     "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
     "https://github.com/0xZDH/o365spray"
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
index 35e490274d8..0517b3b14f8 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 
 [rule]
 author = ["Elastic"]
@@ -25,51 +25,7 @@ language = "esql"
 interval = "10m"
 license = "Elastic License v2"
 name = "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source
-
-Azure Entra, part of Microsoft's identity and access management suite, secures access to Microsoft 365 services. Adversaries may exploit this by attempting numerous failed logins to guess user credentials, aiming to breach accounts. The detection rule identifies such brute-force attempts by flagging multiple failed logins from a single IP within a short timeframe, focusing on patterns indicative of unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand the source IP and the number of distinct failed login attempts, focusing on the `source.ip` and `target_count` fields.
-- Cross-reference the `source.ip` with known threat intelligence feeds to determine if the IP is associated with any known malicious activity.
-- Analyze the `azure.signinlogs.properties.user_principal_name` field to identify which user accounts were targeted and assess if these accounts have any commonalities or are high-value targets.
-- Check the `azure.signinlogs.properties.resource_display_name` to determine which Microsoft 365 services were targeted, such as Exchange, SharePoint, or Teams, to understand the potential impact.
-- Investigate the `azure.signinlogs.properties.status.error_code` to identify specific error codes associated with the failed login attempts, which may provide insights into the attack method.
-- Use Osquery to gather additional context on the affected user accounts. For example, run a query to list recent login activities for the targeted user accounts: `SELECT * FROM azure_signin_logs WHERE user_principal_name IN ('user1@example.com', 'user2@example.com') AND outcome != 'success';`
-- Examine historical login patterns for the affected user accounts to determine if the failed attempts are anomalous compared to typical behavior.
-- Check for any successful logins from the same `source.ip` around the time of the failed attempts to assess if the attacker eventually gained access.
-- Review any recent changes to the user accounts or permissions that might have been made prior to the alert, which could indicate preparatory actions by the attacker.
-- Collaborate with the network team to analyze network traffic logs for the `source.ip` to identify any other suspicious activities or connections related to the brute-force attempts.
-
-### False positive analysis
-
-- Legitimate high-volume automated processes: Some organizations may have automated scripts or services that perform numerous login attempts in a short period, such as system health checks or batch processing tasks. These can trigger the rule as false positives.
-- Shared IP addresses: Users accessing Microsoft 365 services from shared IP addresses, such as those in corporate networks or VPNs, may result in multiple failed login attempts from a single source, leading to false positives.
-- Frequent password changes: Users who frequently change their passwords and subsequently enter incorrect credentials multiple times may inadvertently trigger the rule.
-- Testing and development environments: In environments where developers or IT staff are testing authentication processes, multiple failed logins may occur, which can be mistaken for brute-force attempts.
-- To manage these false positives, users can create exceptions for known IP addresses associated with legitimate automated processes or shared networks. Additionally, monitoring and adjusting the threshold for failed login attempts based on organizational behavior can help reduce false positives.
-
-### Response and remediation
-
-- Immediately block the source IP address identified in the alert to prevent further unauthorized access attempts.
-- Investigate the affected user accounts for any signs of compromise or unauthorized access, and reset passwords as a precautionary measure.
-- Review the sign-in logs for additional suspicious activity from the same IP or related IP addresses to identify potential patterns or coordinated attacks.
-- Escalate the incident to the security operations team if there is evidence of a broader attack or if multiple accounts are targeted.
-- Implement multi-factor authentication (MFA) for all user accounts to add an additional layer of security against brute-force attacks.
-- Enhance logging policies to ensure comprehensive capture of authentication events, including both successful and failed login attempts, for better future analysis.
-- Integrate Azure Entra logs with a Security Information and Event Management (SIEM) system to enable real-time monitoring and automated alerting for similar threats.
-- Conduct a security awareness training session for users to educate them on recognizing phishing attempts and the importance of strong, unique passwords.
-- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to detect and block similar brute-force attempts in the future.
-- Apply security patches and updates to all systems and applications to mitigate vulnerabilities that could be exploited in conjunction with brute-force attacks.
-
-This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
+note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."
 references = [
     "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
     "https://github.com/0xZDH/o365spray"
diff --git a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
index eafec4e7395..76341ee2959 100644
--- a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
+++ b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/14"
 
 [rule]
 author = ["Elastic", "Matteo Potito Giorgio"]
@@ -38,48 +38,6 @@ query = '''
  event.dataset:(azure.activitylogs or azure.signinlogs) and 
      (azure.signinlogs.properties.authentication_protocol:deviceCode or azure.activitylogs.properties.authentication_protocol:deviceCode) and event.outcome:success
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of Entra ID Auth via DeviceCode Protocol
-
-The device code authentication flow is designed for devices lacking keyboards, facilitating user login without direct input of credentials. However, attackers can exploit this by phishing users to capture access tokens, enabling unauthorized access. The detection rule identifies new instances of this protocol use, flagging potential misuse by monitoring successful authentications within a specified timeframe.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account involved in the first occurrence of the deviceCode protocol authentication.
-- Verify the timestamp of the authentication event to understand when the activity took place and correlate it with any known user activities or scheduled tasks.
-- Examine the `event.dataset` field to determine whether the event originated from `azure.activitylogs` or `azure.signinlogs`, providing context on the type of log and its source.
-- Analyze the `event.outcome` field to confirm the success of the authentication attempt, ensuring that the alert is based on a successful login.
-- Investigate the `azure.signinlogs.properties.authentication_protocol` or `azure.activitylogs.properties.authentication_protocol` fields to confirm the use of the deviceCode protocol.
-- Check the IP address and location associated with the authentication event to identify any anomalies or unexpected geolocations.
-- Use Osquery to gather additional context on the device involved in the authentication. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_ADDRESS_FROM_ALERT>';`
-- Review the user's recent activity logs to identify any unusual patterns or deviations from their typical behavior, such as logins from new devices or locations.
-- Cross-reference the user's activity with any recent phishing campaigns or security incidents that might have targeted the organization.
-- Consult with the user to verify whether they initiated the authentication and to gather any additional context or insights into the event.
-
-### False positive analysis
-
-- Legitimate use of the device code protocol by users accessing applications on devices without keyboards, such as smart TVs or IoT devices, can trigger false positives. These instances should be reviewed to confirm the legitimacy of the device and user.
-- Automated scripts or applications that use the device code protocol for authentication as part of their normal operation may also be flagged. Identifying these scripts and adding them to an exception list can prevent unnecessary alerts.
-- Users who frequently travel or work remotely might use the device code protocol on new devices, leading to repeated alerts. Monitoring user behavior and establishing a baseline for normal activity can help differentiate between legitimate and suspicious use.
-- Organizations can create exceptions for known and trusted devices or applications that regularly use the device code protocol, reducing the likelihood of false positives while maintaining security oversight.
-
-### Response and remediation
-
-- Immediately isolate the affected user account to prevent further unauthorized access and token misuse.
-- Conduct a thorough investigation to determine the source of the device code request and verify if it aligns with legitimate user activity.
-- Revoke any access tokens associated with the compromised account to prevent further unauthorized access.
-- Notify the user and relevant stakeholders about the potential compromise and advise them to change their passwords and review their account activity.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems are affected.
-- Implement enhanced logging and monitoring for device code authentication attempts to detect and respond to future misuse promptly.
-- Integrate threat intelligence feeds to correlate device code authentication attempts with known malicious IP addresses or threat actors.
-- Review and update security policies to restrict the use of device code authentication to only necessary scenarios and enforce multi-factor authentication.
-- Restore the affected system to its operational state by ensuring all compromised tokens are revoked and user credentials are reset.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as user training on phishing awareness and regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/azure/credential_access_key_vault_modified.toml b/rules/integrations/azure/credential_access_key_vault_modified.toml
index 391f753cec9..b58c6dfac3f 100644
--- a/rules/integrations/azure/credential_access_key_vault_modified.toml
+++ b/rules/integrations/azure/credential_access_key_vault_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Key Vault Modified"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Key Vault Modified
-
-Azure Key Vault is a critical service for managing sensitive information like encryption keys and secrets. It ensures that only authorized users and applications can access this data. However, adversaries may attempt to modify Key Vault settings to gain unauthorized access to credentials. The detection rule monitors for successful write operations to Key Vaults, signaling potential unauthorized modifications that could lead to credential exposure.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.dataset:azure.activitylogs and ensure the operation_name is "MICROSOFT.KEYVAULT/VAULTS/WRITE" with a successful outcome.
-- Identify the user or application that performed the write operation by examining the user or service principal details in the activity logs.
-- Check the timestamp of the modification to determine when the change occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the IP address and location from which the write operation was performed to identify any anomalies or unauthorized access patterns.
-- Review the change history of the specific Key Vault to understand what modifications were made and assess if they align with expected changes.
-- Analyze the access policies of the Key Vault to verify if any unauthorized users or applications have been granted access.
-- Use Osquery to gather additional context on the system from which the modification was made. Example query: `SELECT * FROM azure_key_vault WHERE operation_name = 'MICROSOFT.KEYVAULT/VAULTS/WRITE' AND outcome = 'Success';`
-- Cross-reference the activity with any recent changes in user permissions or roles that might explain the modification.
-- Check for any related alerts or incidents in the security monitoring system that might indicate a broader attack or compromise.
-- Consult with the relevant teams or stakeholders to verify if the modification was part of a legitimate change request or deployment.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular maintenance or updates by authorized personnel can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when maintenance is scheduled.
-- Automated deployment processes: Continuous integration and deployment pipelines may modify Key Vault settings as part of their normal operation. Users should identify and exclude these automated processes by whitelisting specific service accounts or IP addresses.
-- Third-party integrations: Some third-party applications may require write access to Key Vaults for legitimate reasons. Users should verify these integrations and exclude them from the detection rule by adding them to an allowlist.
-- Policy updates: Changes in organizational security policies might necessitate updates to Key Vault configurations. Users can handle these by documenting policy changes and temporarily excluding related activities during the transition period.
-
-### Response and remediation
-
-- Immediately isolate the affected Key Vault to prevent further unauthorized access by restricting network access and disabling any suspicious accounts or applications.
-- Review Azure Activity Logs to identify unauthorized changes and determine the scope of the compromise, focusing on the specific write operations detected.
-- Revoke any potentially compromised credentials and secrets stored in the Key Vault and rotate them to new, secure values.
-- Conduct a thorough investigation to identify the source of the unauthorized access, leveraging threat intelligence and MITRE ATT&CK framework to understand potential adversary techniques.
-- Escalate the incident to the security operations team and, if necessary, involve legal and compliance teams to assess potential impacts and regulatory obligations.
-- Implement enhanced logging and monitoring policies for Azure Key Vault, ensuring that all access and modification attempts are logged and reviewed regularly.
-- Integrate Azure Key Vault with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Restore the Key Vault to its operational state by verifying the integrity of its contents and ensuring that only authorized users and applications have access.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent future incidents.
-- Implement hardening measures such as enabling Azure Key Vault firewall, using private endpoints, and enforcing strict access controls and multi-factor authentication for all users and applications accessing the Key Vault.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
index ba885d1a6ce..5f1e83dabbf 100644
--- a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
+++ b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Storage Account Key Regenerated"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Storage Account Key Regenerated
-
-Azure Storage Account keys are critical credentials that grant access to storage resources. They are often used by applications and services to authenticate and interact with Azure Storage. Adversaries may regenerate these keys to gain unauthorized access, potentially disrupting services or exfiltrating data. The detection rule monitors for successful key regeneration events, signaling potential credential misuse, and aligns with known threat tactics to alert security teams.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `azure.activitylogs` and the operation name is `MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION` with a successful outcome.
-- Identify the user or service principal associated with the key regeneration event by examining the `azure.activitylogs.caller` field.
-- Check the timestamp of the key regeneration event to determine when the action occurred and correlate it with other security events or anomalies around the same time.
-- Investigate the storage account involved by reviewing the `azure.activitylogs.resource_id` field to understand which resources might be affected.
-- Analyze the `azure.activitylogs.correlation_id` to trace related activities and identify any other suspicious operations performed by the same user or service principal.
-- Use Osquery to gather additional context on the system where the key regeneration was initiated. For example, run the following query to list recent Azure CLI commands executed: `SELECT * FROM shell_history WHERE command LIKE '%az storage%' ORDER BY time DESC LIMIT 10;`.
-- Review the access patterns and usage of the storage account before and after the key regeneration event to identify any unusual data access or exfiltration attempts.
-- Check for any recent changes in permissions or roles assigned to the user or service principal involved in the key regeneration to assess if there was a privilege escalation.
-- Investigate any other alerts or incidents involving the same storage account or user to determine if this event is part of a broader attack campaign.
-- Consult with the application or service owners using the storage account to verify if the key regeneration was authorized and necessary for operational purposes.
-
-### False positive analysis
-
-- Routine administrative tasks: Regularly scheduled key rotations by IT administrators for security best practices can trigger this alert. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
-- Automated scripts or tools: Some organizations use automated processes to periodically regenerate keys for compliance or security reasons. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses.
-- Third-party integrations: Certain third-party services may require key regeneration as part of their normal operation. Review and document these integrations, then configure exceptions for their expected behavior to prevent false positives.
-- Testing environments: In development or testing environments, frequent key regenerations may occur as part of testing procedures. Exclude these environments from alerting by using tags or specific resource group identifiers to differentiate them from production systems.
-
-### Response and remediation
-
-- Immediately revoke the regenerated storage account keys to prevent unauthorized access and assess the impact on dependent applications and services.
-- Conduct a thorough investigation to determine the source and intent of the key regeneration, reviewing logs and correlating with other security events.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement Azure Key Vault to manage and rotate storage account keys securely, reducing the risk of unauthorized key regeneration.
-- Enable and configure Azure Monitor and Azure Security Center to enhance logging and alerting capabilities for storage account activities.
-- Review and update access controls and permissions for Azure Storage Accounts to ensure the principle of least privilege is enforced.
-- Conduct a security awareness session for administrators and developers on the importance of key management and the risks associated with key regeneration.
-- Restore affected applications and services by updating them with new, secure access keys and verifying their operational status.
-- Implement multi-factor authentication (MFA) and conditional access policies for accessing Azure resources to add an additional layer of security.
-- Regularly review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
index 5941010698b..e6d6c3ef2b1 100644
--- a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
+++ b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -25,51 +25,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Application Credential Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Application Credential Modification
-
-Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. The detection rule monitors audit logs for successful modifications in application credentials, signaling potential misuse by identifying unauthorized credential additions.
-
-### Possible investigation steps
-
-- Review the Azure audit logs to confirm the alert by checking for entries with `event.dataset:azure.auditlogs` and `azure.auditlogs.operation_name:"Update application - Certificates and secrets management"` with a successful outcome.
-- Identify the application involved in the credential modification by examining the specific application ID or name in the audit log entry.
-- Determine the user or service principal that performed the modification by reviewing the `initiatedBy` field in the audit log.
-- Check the timestamp of the modification to understand when the change occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the new credential added by identifying its type (certificate or secret) and any associated metadata, such as expiration date or permissions.
-- Review the application's activity logs for any unusual or unauthorized access patterns following the credential modification.
-- Cross-reference the user or service principal involved with other logs or alerts to identify any patterns of suspicious behavior or previous incidents.
-- Use Osquery to gather additional context on the system where the modification was initiated. For example, run a query to list recent Azure CLI commands executed: `SELECT * FROM shell_history WHERE command LIKE '%az ad app credential%'`.
-- Verify if the new credential has been used by checking for any token requests or authentications involving the application post-modification.
-- Consult with the application owner or relevant stakeholders to confirm if the credential modification was authorized and aligns with expected changes or maintenance activities.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or maintenance by IT staff may involve adding new credentials to applications, which can trigger the detection rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated processes: Some applications may automatically rotate their credentials as part of a security policy. Identify these applications and exclude their credential updates from triggering alerts by using specific application IDs or tags.
-- Third-party integrations: Integrations with external services might require adding new credentials. Document and whitelist these integrations to prevent false positives.
-- Development and testing environments: Frequent changes in non-production environments can lead to numerous alerts. Consider excluding these environments from the rule or applying a different threshold for alerts.
-- Organizational changes: Mergers, acquisitions, or restructuring may necessitate credential updates. During such periods, increase monitoring of changes but adjust the rule to reduce noise by temporarily excluding certain user groups or departments.
-
-### Response and remediation
-
-- Immediately revoke any unauthorized credentials added to the Azure application to prevent further unauthorized access.
-- Conduct a thorough investigation to identify how the unauthorized credential was added, including reviewing audit logs and identifying any compromised accounts or systems.
-- Reset passwords and rotate keys for any accounts or applications that may have been compromised to ensure no further unauthorized access.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential impacts and obligations.
-- Implement additional monitoring and alerting for changes to application credentials to detect similar activities in the future.
-- Review and update access controls and permissions for Azure applications to ensure the principle of least privilege is enforced.
-- Enhance logging policies to ensure comprehensive coverage of credential modifications and other critical security events.
-- Integrate Azure security logs with a Security Information and Event Management (SIEM) system for centralized monitoring and analysis.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement improvements to prevent recurrence.
-- Apply hardening measures such as enabling multi-factor authentication (MFA) for administrative access and using managed identities for Azure resources to reduce reliance on static credentials.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
index 20ff0558b43..50ea493d443 100644
--- a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -15,51 +15,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Runbook Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Automation Runbook Deleted
-
-Azure Automation Runbooks automate repetitive tasks in cloud environments, enhancing operational efficiency. Adversaries may delete these runbooks to disrupt operations or conceal malicious activities. The detection rule monitors Azure activity logs for successful deletion events, signaling potential defense evasion attempts by identifying unauthorized or suspicious runbook deletions.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE"`.
-- Verify the `event.outcome` field to ensure the deletion was successful, as indicated by values "Success" or "success".
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
-- Check the timestamp of the deletion event to determine when the runbook was deleted and correlate it with other suspicious activities around the same time.
-- Investigate the `azure.activitylogs.resource_id` field to identify the specific runbook and automation account affected.
-- Review the Azure AD sign-in logs for the identified user or service principal to detect any unusual login patterns or locations.
-- Examine the Azure activity logs for any preceding or subsequent operations by the same user or service principal to identify potential malicious activities.
-- Use Osquery to query the local system for any related Azure credentials or configurations that might have been used in the deletion. Example query: `SELECT * FROM azure_credentials WHERE user = '<identified_user>';`.
-- Cross-reference the deletion event with any recent changes in Azure policies or permissions that might have allowed unauthorized access.
-- Consult with the team responsible for Azure Automation to verify if the deletion was planned or authorized, and gather any additional context or documentation related to the runbook.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may lead to legitimate runbook deletions, which can trigger false positives. These activities are often scheduled and documented, making them identifiable.
-- Automated scripts or third-party tools used for managing Azure resources might delete runbooks as part of their normal operation, leading to false alerts.
-- Users can manage false positives by creating exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
-- Implementing a review process for deletion events can help distinguish between legitimate and suspicious activities, reducing the likelihood of false positives.
-- Monitoring for additional context, such as associated user accounts or IP addresses, can help in identifying benign deletions and refining detection rules accordingly.
-
-### Response and remediation
-
-- Immediately isolate the affected Azure Automation account to prevent further unauthorized deletions or modifications.
-- Review Azure activity logs to identify the source of the deletion request, including user accounts and IP addresses involved.
-- Verify if the deletion was authorized by cross-referencing with change management records or contacting the responsible team.
-- Restore the deleted runbook from backups or version history to ensure continuity of automated operations.
-- Conduct a thorough investigation to determine if any other runbooks or resources were tampered with or deleted.
-- Escalate the incident to the security operations team if unauthorized access or malicious intent is confirmed.
-- Implement stricter access controls and multi-factor authentication for Azure Automation accounts to prevent unauthorized actions.
-- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system for real-time alerts on suspicious activities.
-- Review and update incident response plans to include specific procedures for handling Azure Automation-related incidents.
-- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as regular audits and least privilege access policies.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
index 272a9d212c5..7802a541aa0 100644
--- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
+++ b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,51 +21,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Blob Permissions Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Blob Permissions Modification
-
-Azure Blob Storage is a service for storing large amounts of unstructured data, such as text or binary data. It uses Azure RBAC to manage access permissions. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt data integrity. The detection rule monitors specific Azure activity logs for successful operations that change blob permissions, signaling potential security threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific operation that triggered the alert, focusing on the `azure.activitylogs.operation_name` field to determine if it was a "MANAGEOWNERSHIP/ACTION" or "MODIFYPERMISSIONS/ACTION".
-- Check the `event.outcome` field to confirm the operation was successful, as this indicates a confirmed change in permissions.
-- Identify the user or service principal responsible for the change by examining the `azure.activitylogs.caller` field to determine if the action was performed by an authorized entity.
-- Investigate the `azure.activitylogs.resource_id` field to pinpoint the specific Azure Blob or container affected by the permission change.
-- Correlate the timestamp of the alert with other logs to identify any concurrent suspicious activities, such as unusual login attempts or data access patterns.
-- Use Osquery to gather additional context on the affected Azure Blob by running a query like: `SELECT * FROM azure_blob_permissions WHERE blob_name = '<affected_blob_name>' AND account_name = '<storage_account_name>';` to verify current permissions and compare with expected configurations.
-- Review recent changes in Azure Active Directory (AAD) logs to check for any modifications to roles or group memberships that could have influenced the permission change.
-- Analyze historical activity logs for the same `azure.activitylogs.caller` to identify any patterns of behavior that might suggest malicious intent or previous unauthorized access attempts.
-- Consult with the data owner or relevant stakeholders to verify if the permission change was expected or authorized, providing context from the alert details.
-- Document findings and gather evidence, including screenshots and log extracts, to support further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular maintenance or updates by administrators may trigger the rule when they modify blob permissions as part of their duties. Users can handle these by identifying and excluding specific administrative accounts or operations from the rule.
-- Automated processes: Scheduled scripts or automated tools that manage blob permissions for operational purposes might cause false positives. Users should document these processes and create exceptions for known benign operations.
-- Third-party integrations: Some third-party applications may require permission changes to function correctly, leading to false positives. Users should review and whitelist these applications if they are verified as non-threatening.
-- Testing environments: Changes in permissions within testing or development environments can trigger alerts. Users can exclude these environments from monitoring or adjust the rule to focus on production environments only.
-- Temporary access changes: Short-term permission modifications for troubleshooting or temporary projects might be flagged. Users should track these changes and set up temporary exceptions with expiration dates to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected Azure Blob Storage account to prevent further unauthorized access or data manipulation.
-- Review Azure Activity Logs to identify the source and scope of the permission changes, focusing on the user or service principal responsible for the modification.
-- Verify the current permissions on the affected blobs and compare them with the baseline or expected permissions to assess the extent of unauthorized changes.
-- Revert any unauthorized permission changes to their original state to restore security controls and prevent data exposure.
-- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the period of unauthorized access.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential data breach implications.
-- Implement enhanced logging and monitoring policies to capture detailed access and modification events for Azure Blob Storage, ensuring future incidents are detected promptly.
-- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities related to blob permissions.
-- Educate administrators and users on the importance of maintaining strict access controls and regularly reviewing permissions to prevent inadvertent exposure.
-- Apply hardening measures such as enabling Azure AD Conditional Access policies and using Azure Key Vault to manage and rotate access keys securely.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles"]
diff --git a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
index 206483a7d6c..3d1aed02314 100644
--- a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Diagnostic Settings Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Diagnostic Settings Deletion
-
-Azure Diagnostic Settings are crucial for monitoring and logging, directing platform logs and metrics to various destinations for analysis. Adversaries may delete these settings to obscure their tracks and evade detection. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful operations related to the removal of diagnostic settings, aligning with defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"`.
-- Verify the `event.outcome` field to ensure the operation was successful, indicating that the diagnostic settings were indeed deleted.
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
-- Check the `azure.activitylogs.resource_id` field to determine which specific diagnostic settings were deleted and assess the potential impact on monitoring and logging.
-- Investigate the `azure.activitylogs.correlation_id` to trace related activities and identify any other suspicious operations that occurred around the same time.
-- Analyze the `azure.activitylogs.timestamp` to establish a timeline of events and correlate with other security alerts or anomalies in the environment.
-- Use Osquery to gather additional context on the affected resources by running a query such as: `SELECT * FROM azure_diagnostic_settings WHERE resource_id = '<resource_id_from_logs>';` to retrieve current settings and compare with historical data.
-- Cross-reference the deletion event with any recent changes in user permissions or roles that might have allowed unauthorized access to delete diagnostic settings.
-- Investigate any other alerts or logs from the same user or service principal to identify patterns of suspicious behavior or potential lateral movement.
-- Review the organization's change management records to determine if the deletion was part of an approved change or if it was unauthorized.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may lead to the deletion of diagnostic settings, which can trigger false positives. These activities are often performed by authorized personnel and should be reviewed to confirm legitimacy.
-- Automated scripts or tools used for infrastructure management might delete and recreate diagnostic settings as part of their normal operation. Identifying these scripts and excluding their activity from alerts can reduce false positives.
-- Changes in organizational policies or compliance requirements might necessitate the removal of certain diagnostic settings. Documenting these changes and updating monitoring rules accordingly can help in managing false positives.
-- To handle false positives, users can create exceptions for known and verified activities by excluding specific user accounts or service principals that are responsible for legitimate deletions. This can be done by adjusting the detection rule to ignore operations performed by these trusted entities.
-
-### Response and remediation
-
-- Immediately isolate affected Azure resources to prevent further unauthorized actions and assess the scope of the deletion.
-- Review Azure activity logs to identify the source and timeline of the deletion event, focusing on user accounts and IP addresses involved.
-- Verify if any other critical settings or configurations have been altered or deleted, indicating a broader compromise.
-- Restore deleted diagnostic settings from backups or reconfigure them manually to ensure continued logging and monitoring.
-- Implement Azure Role-Based Access Control (RBAC) to restrict permissions for deleting diagnostic settings to only essential personnel.
-- Escalate the incident to the security operations team for a detailed investigation and to determine if further actions are required.
-- Conduct a root cause analysis to understand how the adversary gained access and deleted the settings, leveraging MITRE ATT&CK framework for threat context.
-- Enhance logging policies to include alerts for any changes to diagnostic settings and other critical configurations.
-- Integrate Azure Security Center and other security tools to provide comprehensive monitoring and alerting capabilities.
-- Review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings"]
diff --git a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
index 4281bbbcce4..b94eb74a53b 100644
--- a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,51 +22,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Event Hub Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Event Hub Deletion
-
-Azure Event Hubs is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may delete Event Hubs to disrupt monitoring and evade detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific deletion operations, flagging successful attempts to impair defenses.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by checking the `event.dataset` and `azure.activitylogs.operation_name` fields for "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE".
-- Verify the `event.outcome` field to ensure the deletion was successful, as indicated by "Success" or "success".
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
-- Check the `azure.activitylogs.correlation_id` to trace related activities and understand the sequence of events leading to the deletion.
-- Investigate the `azure.activitylogs.resource_id` to determine which specific Event Hub was deleted and assess its importance and impact on operations.
-- Analyze the `azure.activitylogs.timestamp` to establish the exact time of the deletion and correlate it with other security events or anomalies.
-- Use Osquery to gather additional context on the system from which the deletion was initiated. Example query: `SELECT * FROM azure_event_hubs WHERE operation_name = 'MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE' AND outcome = 'Success';`
-- Review any recent changes in Azure IAM roles and permissions that might have allowed unauthorized users to delete Event Hubs.
-- Cross-reference the deletion event with network logs to identify any unusual access patterns or connections from suspicious IP addresses around the time of the event.
-- Consult with relevant stakeholders or teams to verify if the deletion was part of a planned activity or if it was unauthorized, gathering any additional context or documentation.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may trigger the Azure Event Hub Deletion rule, as legitimate users might delete Event Hubs during regular operations or resource management activities.
-- Automated scripts or deployment tools that manage Azure resources could also lead to false positives if they include Event Hub deletion as part of their workflow.
-- To manage these false positives, users can create exceptions for known maintenance windows or specific user accounts that regularly perform these operations.
-- Implementing a whitelist of trusted IP addresses or service accounts that are authorized to delete Event Hubs can help reduce false positives.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the integrity of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further unauthorized access or data loss.
-- Conduct a thorough investigation to confirm the deletion was unauthorized, reviewing Azure activity logs and correlating with other security events.
-- Restore the deleted Event Hub from backups or snapshots to resume normal operations and minimize data loss.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response coordination.
-- Implement enhanced logging and monitoring policies to capture detailed activity logs for all critical Azure resources, including Event Hubs.
-- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities.
-- Review and update access controls and permissions for Azure resources to ensure the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
-- Educate and train staff on recognizing and responding to potential security incidents, emphasizing the importance of timely reporting.
-- Regularly test and update incident response plans to ensure readiness for future threats, incorporating lessons learned from the current incident.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
index e24c97ab8e4..f0c701c2cb6 100644
--- a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Firewall Policy Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Firewall Policy Deletion
-
-Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE"` with `event.outcome:Success`.
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
-- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events around the same time.
-- Investigate the IP address and location associated with the deletion event using the `azure.activitylogs.callerIpAddress` field to identify any anomalies or suspicious access patterns.
-- Review the Azure AD sign-in logs for the identified user or service principal to check for any unusual login activities or failed login attempts.
-- Examine the change history of the deleted firewall policy to understand its previous configuration and assess the potential impact of its deletion.
-- Use Osquery to query the Azure environment for any recent changes to network security configurations. Example query: `SELECT * FROM azure_firewall_policies WHERE operation_name = 'DELETE' AND outcome = 'Success';`
-- Investigate any other related Azure resources that might have been affected by the deletion, such as virtual networks or subnets, to assess the broader impact.
-- Check for any other recent deletions or modifications of security policies in the Azure environment to identify potential patterns or coordinated attacks.
-- Collaborate with the incident response team to gather additional context from other security tools and logs, such as SIEM or endpoint detection systems, to build a comprehensive picture of the incident.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT operations may involve the deletion of Azure Firewall policies as part of regular maintenance or updates. These actions can be identified by correlating the deletion event with scheduled maintenance windows or change management records.
-- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage Azure resources, including the deletion of firewall policies. These can be identified by reviewing the source of the operation and verifying if it aligns with known automation processes.
-- Testing environments: In development or testing environments, frequent creation and deletion of firewall policies may occur as part of testing procedures. These can be excluded by filtering events from specific resource groups or subscriptions designated for testing.
-- To manage false positives, users can create exceptions by excluding specific user accounts, service principals, or IP addresses associated with known non-threatening activities. Additionally, integrating with change management systems can help validate whether a deletion event is authorized.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further unauthorized access or data exfiltration.
-- Review Azure activity logs to confirm the deletion of the firewall policy and identify any associated suspicious activities or accounts.
-- Recreate the deleted firewall policy using backup configurations or documented rules to restore network security controls.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying compromised accounts and systems.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
-- Implement enhanced logging and monitoring for Azure activity logs to detect similar unauthorized actions in the future.
-- Integrate Azure Security Center and other security tools to provide comprehensive visibility and automated alerts for policy changes.
-- Review and update access controls and permissions to ensure only authorized personnel can modify or delete firewall policies.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate and train staff on security best practices and the importance of maintaining robust firewall policies to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/firewall-manager/policy-overview"]
diff --git a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
index e5ca3f91913..acea8b019f8 100644
--- a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,50 +24,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Frontdoor Web Application Firewall (WAF) Policy Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Frontdoor Web Application Firewall (WAF) Policy Deleted
-
-Azure Frontdoor WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific operations, alerting security teams to potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE"` with `event.outcome:(Success or success)`.
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the activity logs.
-- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events or alerts around the same time.
-- Investigate the IP address and location associated with the deletion event using the `azure.activitylogs.callerIpAddress` field to identify any anomalies or suspicious access patterns.
-- Review the audit logs for any recent changes to user permissions or roles that might have allowed unauthorized deletion of the WAF policy.
-- Examine other Azure resources and configurations for any additional unauthorized changes or suspicious activities that might indicate a broader attack.
-- Use Osquery to gather more information about the system from which the deletion was initiated. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_ADDRESS_FROM_LOGS>';`.
-- Check for any recent failed login attempts or unusual login activities in Azure Active Directory that could suggest compromised credentials.
-- Investigate any recent alerts or incidents related to the affected Azure Frontdoor instance to identify potential precursors or related activities.
-- Collaborate with the application and network teams to understand the potential impact of the WAF policy deletion on the security posture and application availability.
-
-### False positive analysis
-
-- Routine maintenance or administrative actions: Legitimate deletions of Azure Frontdoor WAF policies may occur during scheduled maintenance or when administrators are updating or replacing policies. These actions can be mistaken for malicious activity.
-- Policy migration: During a migration process, old WAF policies might be deleted as new ones are implemented. This can trigger alerts even though the activity is part of a planned upgrade or restructuring.
-- Testing and development environments: In non-production environments, frequent policy deletions may occur as part of testing or development processes. These should be distinguished from production environment alerts.
-- To manage these false positives, users can create exceptions for known administrative accounts or IP addresses that regularly perform these actions. Additionally, implementing a change management process that logs and approves legitimate deletions can help differentiate between authorized and unauthorized activities.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further unauthorized access or data exfiltration.
-- Review Azure activity logs to confirm the deletion of the WAF policy and identify any unauthorized access or suspicious activities around the time of deletion.
-- Restore the deleted Azure Frontdoor WAF policy from backups or recreate it using predefined templates to re-establish security controls.
-- Conduct a thorough investigation to determine the root cause of the policy deletion, including identifying any compromised accounts or insider threats.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response coordination.
-- Implement enhanced logging and monitoring for Azure activity logs to detect similar unauthorized actions in the future.
-- Integrate Azure Security Center and other security tools to provide comprehensive visibility and automated alerts for suspicious activities.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify or delete WAF policies.
-- Conduct a post-incident review to identify gaps in security posture and update incident response plans accordingly.
-- Educate and train staff on security best practices and the importance of maintaining robust security configurations to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
index d4692276400..12782cf9cb0 100644
--- a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,51 +23,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Events Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Kubernetes Events Deleted
-
-Azure Kubernetes Service (AKS) logs events to track state changes like container creation or pod scheduling. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these events to hide their tracks and evade detection. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful event deletion operations, signaling potential malicious activity.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE"`.
-- Verify the `event.outcome` field to ensure the deletion operation was successful, as indicated by values "Success" or "success".
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field.
-- Check the timestamp of the deletion event to determine when the activity occurred and correlate it with other suspicious activities.
-- Investigate the source IP address and location associated with the deletion event to identify any anomalies or unauthorized access.
-- Review the Kubernetes audit logs for any related activities around the same time to identify potential unauthorized actions or patterns.
-- Use Osquery to gather additional context on the affected Kubernetes cluster. For example, run the query: `SELECT * FROM kubernetes_events WHERE event_name = 'delete' AND cluster_name = '<cluster_name>';` to list all deletion events in the cluster.
-- Analyze the Kubernetes RBAC (Role-Based Access Control) settings to ensure that permissions are appropriately configured and no excessive privileges are granted.
-- Cross-reference the deletion event with any recent changes in the cluster configuration or deployments to identify potential causes or related activities.
-- Consult with the team responsible for the Kubernetes environment to verify if the deletion was part of a legitimate maintenance activity or if it requires further investigation.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may trigger event deletions, such as clearing old or irrelevant logs to manage storage space. These actions are typically benign and can be identified by correlating with scheduled maintenance windows or known administrative activities.
-- Automated scripts or tools used for log management might delete events as part of their normal operation. Users should review the source and purpose of these scripts to determine if they are legitimate.
-- Certain third-party applications integrated with Azure Kubernetes might perform event deletions as part of their functionality. Users should verify the application's behavior and consider excluding these operations if they are confirmed to be non-threatening.
-- To manage false positives, users can create exceptions for specific user accounts or service principals known to perform legitimate event deletions. This can be done by adding conditions to the detection rule to exclude these entities.
-- Regularly review and update the list of exceptions to ensure that only verified non-malicious activities are excluded, maintaining the balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or changes.
-- Conduct a thorough investigation to identify the source and scope of the event deletions, focusing on recent access logs and user activities.
-- Review Azure activity logs to determine if any other suspicious activities occurred around the time of the event deletions.
-- Restore deleted Kubernetes events from backups if available, to ensure continuity in monitoring and troubleshooting.
-- Escalate the incident to the security operations team for a deeper analysis and to determine if the attack is part of a larger campaign.
-- Implement stricter access controls and audit policies on Kubernetes clusters to limit who can delete events and perform other critical operations.
-- Enhance logging and monitoring by integrating Azure Security Center and other security tools to provide real-time alerts on suspicious activities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply security patches and updates to the Kubernetes environment to mitigate any known vulnerabilities that could have been exploited.
-- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining robust security practices.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
index ce651bd4988..4bf9be6b02e 100644
--- a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,51 +23,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Network Watcher Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Network Watcher Deletion
-
-Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments, providing insights and enabling logging for virtual network resources. Adversaries may delete Network Watchers to evade detection and impair defenses. The detection rule identifies such deletions by monitoring Azure activity logs for specific deletion operations, flagging successful attempts to ensure timely investigation and response.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE"` with `event.outcome:Success`.
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the logs.
-- Check the timestamp of the deletion event to determine when the Network Watcher was deleted and correlate it with other security events around the same time.
-- Investigate the source IP address and location from which the deletion request was made using the `azure.activitylogs.caller_ip_address` field.
-- Analyze the context of the deletion by reviewing any preceding or subsequent operations in the Azure activity logs that involve the same user or resource group.
-- Use Osquery to query the Azure environment for any recent changes to network configurations or security settings that might indicate further malicious activity. Example query: `SELECT * FROM azure_network_watcher WHERE operation_name = 'MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE';`
-- Check for any alerts or anomalies in other security tools that might correlate with the deletion event, such as unusual login attempts or privilege escalations.
-- Review the audit logs for any changes to user roles or permissions that could have allowed unauthorized deletion of the Network Watcher.
-- Investigate whether there are any other Network Watchers in the environment and assess their current status and configuration for signs of tampering.
-- Consult with the team responsible for network security to verify if the deletion was authorized and documented as part of a legitimate change management process.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may lead to the deletion of Network Watchers, which can trigger false positives. These tasks are often scheduled and documented, making them identifiable.
-- Automated scripts or deployment tools that manage Azure resources might delete and recreate Network Watchers as part of their normal operation, leading to benign alerts.
-- Users can manage these false positives by creating exceptions for known maintenance windows or specific administrative accounts that perform these tasks regularly.
-- Implementing a tagging system for resources involved in routine operations can help in distinguishing between legitimate and suspicious deletions.
-- Regularly reviewing and updating the list of exceptions based on changes in administrative practices or automation scripts can minimize unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected Azure environment to prevent further unauthorized actions and assess the scope of the deletion.
-- Review Azure activity logs to identify the source of the deletion request, including user accounts, IP addresses, and timestamps.
-- Verify if the deletion was authorized by cross-referencing with change management records and contacting relevant personnel.
-- Restore the deleted Network Watcher by redeploying it from a known good configuration or backup to resume monitoring and diagnostics.
-- Implement Azure Role-Based Access Control (RBAC) to restrict permissions for deleting critical resources like Network Watchers to only essential personnel.
-- Enable and configure Azure Security Center and Azure Monitor to enhance visibility and alerting on suspicious activities related to network resources.
-- Conduct a thorough investigation to determine if other resources were affected or if there are signs of further compromise.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments for potential breaches.
-- Update incident response plans and playbooks to include specific procedures for handling Network Watcher deletions and similar threats.
-- Review and enhance logging policies to ensure comprehensive coverage and retention of activity logs, integrating with SIEM solutions for improved threat detection and analysis.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview"]
diff --git a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
index 8886a0e9fca..5adfd45abdd 100644
--- a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
+++ b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,51 +23,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Alert Suppression Rule Created or Modified"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Alert Suppression Rule Created or Modified
-
-Azure Alert Suppression Rules help manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to evade detection by suppressing legitimate security alerts. The detection rule monitors for successful creation or modification of these rules, flagging potential misuse that aligns with defense evasion tactics, ensuring security teams maintain visibility over critical alerts.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the timestamp, user, and source IP address associated with the creation or modification of the suppression rule.
-- Verify the identity of the user who created or modified the suppression rule by checking their role and permissions in Azure Active Directory to ensure they have legitimate access.
-- Examine the `azure.activitylogs.operation_name` field to confirm the specific operation, "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE," was performed successfully.
-- Investigate the `event.outcome` field to ensure the operation was indeed successful and not a failed attempt, which might indicate a misconfiguration or unauthorized access attempt.
-- Cross-reference the `event.dataset:azure.activitylogs` with other logs to identify any unusual or suspicious activities around the same time, such as failed login attempts or changes to other security settings.
-- Use Osquery to gather additional context on the system where the rule was created or modified. For example, run a query to list recent changes to Azure configurations: `SELECT * FROM azure_activity_logs WHERE operation_name = 'MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE' AND outcome = 'success';`
-- Check for any recent changes in the environment that might have necessitated the creation or modification of the suppression rule, such as new deployments or updates.
-- Analyze historical data to determine if there is a pattern of suppression rule modifications that could indicate a broader attempt to evade detection.
-- Consult with the security team or the user who made the change to understand the rationale behind the creation or modification of the suppression rule.
-- Document all findings and observations to maintain a comprehensive record of the investigation, which can be useful for future reference or audits.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate changes made by security administrators to manage alert noise can trigger this rule. These changes are often necessary to maintain operational efficiency and should be reviewed to ensure they align with security policies.
-- Automated processes: Some organizations use automated scripts or tools to manage alert suppression rules, which can result in frequent rule modifications. These should be documented and monitored to distinguish between expected and unexpected changes.
-- Testing and development environments: In non-production environments, suppression rules may be frequently created or modified as part of testing processes. These environments should be clearly identified, and alerts from them can be excluded from triggering false positives.
-- Known maintenance windows: During scheduled maintenance, suppression rules might be adjusted to prevent alert fatigue. Establishing exceptions for these periods can help reduce unnecessary alerts.
-- To manage these false positives, users can implement exception lists for known benign activities, use tagging to differentiate between environments, and establish baselines for expected behavior to quickly identify deviations.
-
-### Response and remediation
-
-- Immediately review the Azure activity logs to identify the user or service principal responsible for creating or modifying the alert suppression rule.
-- Verify the legitimacy of the change by contacting the responsible user or team to confirm if the action was authorized and necessary.
-- If unauthorized, disable or delete the suspicious suppression rule to restore visibility to critical alerts.
-- Conduct a thorough investigation to determine if any other security configurations have been altered or if there are additional unauthorized changes.
-- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture.
-- Implement enhanced logging and monitoring for Azure activity logs to detect similar unauthorized changes in the future.
-- Integrate Azure activity logs with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Review and update access controls and permissions for users and service principals to ensure that only authorized personnel can modify alert suppression rules.
-- Conduct a post-incident review to identify gaps in the current security processes and implement measures to prevent recurrence.
-- Consider implementing additional security measures such as multi-factor authentication (MFA) and conditional access policies to strengthen the security of Azure resources.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/discovery_blob_container_access_mod.toml b/rules/integrations/azure/discovery_blob_container_access_mod.toml
index 5103ce53027..61d9adf1f1c 100644
--- a/rules/integrations/azure/discovery_blob_container_access_mod.toml
+++ b/rules/integrations/azure/discovery_blob_container_access_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Blob Container Access Level Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Blob Container Access Level Modification
-
-Azure Blob Storage allows for scalable data storage, where access levels can be set to control data visibility. Adversaries may exploit this by altering access levels to expose sensitive data publicly. The detection rule monitors for changes in container access settings, focusing on successful operations, to identify potential unauthorized modifications that could lead to data exposure.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `azure.activitylogs` and the operation name is `MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE` with a successful outcome.
-- Identify the specific storage account and container involved in the access level modification by examining the relevant fields in the alert.
-- Check the timestamp of the modification to determine when the change occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the identity of the user or service principal that performed the modification by reviewing the `azure.activitylogs.caller` field.
-- Verify if the user or service principal has a legitimate reason to modify the container access level by checking their role and permissions in Azure Active Directory.
-- Examine the previous access level settings of the container to understand the extent of the change and potential exposure.
-- Use Osquery to gather additional context on the system from which the modification was made, for example: `SELECT * FROM azure_blob_containers WHERE account_name = 'your_storage_account' AND container_name = 'your_container';`
-- Review any related logs or alerts that might indicate lateral movement or privilege escalation attempts leading up to the modification.
-- Check for any recent changes in the organization's policies or configurations that might have inadvertently allowed the modification.
-- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the access level change.
-
-### False positive analysis
-
-- Routine administrative tasks: Changes to container access levels may be part of regular maintenance or configuration updates by authorized personnel. To manage these, users can create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated processes: Some organizations use automated scripts or tools to manage storage configurations, which might trigger the detection rule. Users can exclude these processes by identifying and whitelisting the specific service accounts or automation tools involved.
-- Development and testing environments: Access level modifications in non-production environments might be frequent and benign. Users can exclude these environments by filtering out specific storage accounts or resource groups associated with development and testing.
-- Third-party integrations: Certain third-party applications or services may require changes to access levels for functionality. Users should review and whitelist these integrations after ensuring they do not pose a security risk.
-
-### Response and remediation
-
-- Immediately revoke public access to the affected Azure Blob container to prevent further unauthorized data exposure.
-- Conduct a thorough investigation to identify the source and intent of the access level modification, reviewing logs and access patterns.
-- Verify the integrity and confidentiality of the data within the container to assess any potential data breach.
-- Escalate the incident to the security operations team if malicious intent is suspected, providing them with detailed logs and findings.
-- Implement Azure Monitor and Azure Security Center to enhance logging and alerting for future unauthorized access level changes.
-- Review and update access control policies to ensure that only authorized personnel can modify container access levels.
-- Conduct a security audit of all Azure Blob containers to identify and rectify any other instances of misconfigured access levels.
-- Restore the container's access level to its original state, ensuring compliance with organizational security policies.
-- Educate relevant staff on the importance of secure access configurations and the risks associated with public data exposure.
-- Consider implementing Azure Policy to enforce compliance with access level configurations and prevent unauthorized changes.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent"]
diff --git a/rules/integrations/azure/execution_command_virtual_machine.toml b/rules/integrations/azure/execution_command_virtual_machine.toml
index b98400db730..6913c697a2e 100644
--- a/rules/integrations/azure/execution_command_virtual_machine.toml
+++ b/rules/integrations/azure/execution_command_virtual_machine.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -25,50 +25,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Command Execution on Virtual Machine"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Command Execution on Virtual Machine
-
-Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they can't directly access them. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute malicious scripts. The detection rule monitors Azure activity logs for successful command executions, identifying potential misuse by correlating specific operation names and outcomes.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the details of the command execution event, focusing on the `azure.activitylogs.operation_name` field to ensure it matches "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION".
-- Verify the `event.outcome` field to ensure the command execution was successful, as this indicates the command was executed on the VM.
-- Identify the user or service principal that initiated the command execution by examining the `azure.activitylogs.caller` field.
-- Check the timestamp of the event to determine when the command execution occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the specific command or script executed on the VM by reviewing any available command logs or script content, if accessible.
-- Cross-reference the VM's activity with other logs, such as network logs or application logs, to identify any unusual behavior or data exfiltration attempts following the command execution.
-- Use Osquery to gather more information about the VM's current state. For example, run the following Osquery query to list all running processes on the VM: `SELECT pid, name, path FROM processes;`.
-- Analyze the roles and permissions of the user or service principal involved in the command execution to determine if they have legitimate access or if there are any privilege escalation concerns.
-- Investigate any recent changes to the VM's configuration or security settings that could have facilitated unauthorized command execution.
-- Review the history of command executions on the VM to identify any patterns or repeated attempts that could indicate ongoing malicious activity.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular maintenance or updates performed by IT staff using PowerShell commands on VMs may trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when these tasks are scheduled.
-- Automated scripts: Scheduled scripts or automation tools that execute commands on VMs for legitimate purposes, such as backups or performance monitoring, can be mistaken for malicious activity. Users should document these scripts and exclude their associated accounts or operations from the detection rule.
-- Third-party integrations: Some third-party services or applications may require command execution on VMs as part of their normal operation. Identifying these services and excluding their activity from the rule can help reduce false positives.
-- Testing environments: Commands executed in test or development environments may not pose a threat. Users can exclude these environments by filtering out specific resource groups or VM names associated with non-production use.
-
-### Response and remediation
-
-- Immediately isolate the affected virtual machine from the network to prevent further malicious activity.
-- Review Azure activity logs to identify the source and scope of the command execution, focusing on the user or service principal involved.
-- Verify the integrity of the system by checking for unauthorized changes or the presence of malicious scripts or software.
-- Revoke or adjust permissions for the user or role that executed the command, ensuring least privilege access is enforced.
-- Conduct a thorough investigation to determine if any data exfiltration or lateral movement occurred as a result of the command execution.
-- Escalate the incident to the security operations team for further analysis and to determine if additional resources are needed.
-- Implement enhanced logging and monitoring policies to capture detailed activity on virtual machines, including command execution and network traffic.
-- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities.
-- Restore the virtual machine to a known good state using backups or snapshots, ensuring all malicious artifacts are removed.
-- Apply hardening measures such as enabling Just-In-Time VM access, using Azure Bastion for secure RDP/SSH, and regularly updating security patches.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
index 5c749ce3905..d66662ddb29 100644
--- a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
+++ b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -25,52 +25,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Service Principal Credentials Added"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Service Principal Credentials Added
-
-Azure Service Principals are identities used by applications or services to access Azure resources securely. They typically have specific permissions and are less frequently updated. Adversaries may exploit this by adding unauthorized credentials, bypassing MFA, and accessing sensitive data. The detection rule monitors audit logs for successful additions of credentials, signaling potential misuse or hijacking attempts.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event details, focusing on the `event.dataset:azure.auditlogs` and `azure.auditlogs.operation_name:"Add service principal credentials"` fields to ensure the alert is valid.
-- Check the `event.outcome` field to verify the success of the credential addition and determine if it aligns with expected behavior.
-- Identify the service principal involved by examining the relevant fields in the audit logs, such as the service principal's name or ID.
-- Investigate the user or application that performed the credential addition by reviewing the `user.name` or `user.id` fields in the logs.
-- Cross-reference the time of the credential addition with other security events or logs to identify any suspicious activity or patterns.
-- Analyze the permissions and roles assigned to the service principal to assess the potential impact of unauthorized access.
-- Use Osquery to gather additional context on the affected service principal. For example, run a query to list all credentials associated with the service principal: `SELECT * FROM azure_service_principal_credentials WHERE service_principal_id = '<service_principal_id>';`.
-- Review recent changes or updates to the service principal's configuration or permissions to identify any unauthorized modifications.
-- Check for any recent or unusual login attempts or access patterns associated with the service principal to detect potential misuse.
-- Collaborate with the application or service owner to verify if the credential addition was authorized and aligns with expected operational procedures.
-
-### False positive analysis
-
-- Routine administrative tasks: In some organizations, service principal credentials may be updated as part of regular maintenance or automated processes. These updates can trigger the detection rule, leading to false positives.
-- DevOps and CI/CD pipelines: Automated systems that manage deployments and infrastructure might add or update service principal credentials frequently, which can be mistaken for unauthorized activity.
-- Third-party integrations: Some third-party applications or services may require periodic updates to service principal credentials, which could be misinterpreted as suspicious behavior.
-- To manage these false positives, users can create exceptions for known and trusted sources or processes that regularly update service principal credentials. This can be done by identifying specific patterns or attributes in the audit logs that are associated with legitimate activities and excluding them from triggering alerts.
-- Implementing a whitelist of service principals that are expected to have frequent credential updates can help reduce noise and focus on truly suspicious activities.
-- Regularly reviewing and updating the list of exceptions is crucial to ensure that new legitimate behaviors are accounted for and that the detection rule remains effective against potential threats.
-
-### Response and remediation
-
-- Immediately revoke the newly added credentials to prevent unauthorized access to Azure resources.
-- Conduct a thorough investigation to determine the source and method of the unauthorized credential addition, focusing on recent changes and access logs.
-- Review and audit all permissions associated with the affected service principal to identify any potential misuse or over-permissioning.
-- Escalate the incident to the security operations team and relevant stakeholders for further analysis and response coordination.
-- Implement additional monitoring and alerting for any further unauthorized changes to service principal credentials.
-- Enhance logging policies to ensure comprehensive capture of all authentication and authorization events related to service principals.
-- Integrate Azure Security Center and other security tools to provide a unified view of security alerts and incidents.
-- Restore the system to its operational state by ensuring all legitimate credentials are intact and functioning as expected.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update policies accordingly.
-- Implement hardening measures such as enforcing stricter access controls, regular credential rotation, and multi-factor authentication for all service principals.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://www.fireeye.com/content/dam/collateral/en/wp-m-unc2452.pdf"]
diff --git a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
index b69cd7b9d37..791f2c8c25a 100644
--- a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
+++ b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -22,51 +22,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Pods Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Kubernetes Pods Deleted
-
-Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, orchestrating tasks like deployment and scaling. Pods, the smallest deployable units, can be targeted by adversaries to disrupt services by deletion. The detection rule monitors Azure activity logs for successful pod deletion operations, signaling potential malicious activity aimed at impacting service availability.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by filtering for `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE"` with `event.outcome:(Success or success)`.
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the logs.
-- Check the timestamp of the deletion event to determine when the activity occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the specific pod(s) deleted by looking at the `azure.activitylogs.resource_id` field to understand which applications or services were impacted.
-- Analyze the context of the deletion by reviewing any related events in the activity logs, such as preceding or subsequent operations by the same user or on the same resources.
-- Verify if the deletion was part of a legitimate maintenance or deployment activity by cross-referencing with change management records or deployment logs.
-- Use Osquery to gather additional context on the affected Kubernetes cluster. For example, run a query to list all current pods and their statuses: `SELECT name, namespace, status FROM kubernetes_pods WHERE cluster_name = 'your_cluster_name';`.
-- Check for any recent alerts or incidents related to the same cluster or namespace to identify potential patterns or ongoing threats.
-- Investigate the network activity around the time of the deletion to detect any unusual access patterns or connections to the Kubernetes API server.
-- Consult with the application or service owners to verify if they were aware of or authorized the pod deletion, and gather any additional context they might have.
-
-### False positive analysis
-
-- Routine maintenance or updates: Regular updates or maintenance activities may involve the deletion and recreation of pods, which can trigger the detection rule. Users can manage this by creating exceptions for known maintenance windows or specific operations teams.
-- Automated scaling operations: Kubernetes may automatically delete pods as part of scaling operations, either up or down, which are benign activities. Users should consider excluding these operations by identifying and filtering out specific scaling-related events.
-- Deployment rollouts: During application deployment rollouts, old pods may be deleted to make way for new versions. Users can handle these by setting up exceptions for deployment-related activities, possibly by correlating with deployment logs.
-- Testing environments: In testing or development environments, frequent pod deletions may occur as part of normal testing procedures. Users can exclude these environments from monitoring or adjust the rule to focus on production environments only.
-- Known service accounts: If certain service accounts are responsible for legitimate pod deletions, users can exclude these accounts from triggering alerts by adding them to an allowlist.
-
-### Response and remediation
-
-- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or damage.
-- Review Azure activity logs to confirm the deletion event and identify any unauthorized access patterns or suspicious IP addresses.
-- Recreate the deleted pods using the latest known good configuration to restore service availability.
-- Conduct a root cause analysis to determine how the deletion was initiated and identify any security gaps.
-- Escalate the incident to the security operations team if malicious intent is suspected, providing them with all relevant logs and findings.
-- Implement stricter access controls and role-based access management to limit who can delete pods in the future.
-- Enhance logging policies to ensure all Kubernetes API actions are logged and monitored for anomalies.
-- Integrate Azure Security Center and other security tools to provide real-time alerts and automated responses to suspicious activities.
-- Regularly update and patch Kubernetes clusters and associated components to mitigate vulnerabilities.
-- Conduct a security review and harden the Kubernetes environment by following best practices, such as network segmentation and using pod security policies.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_resource_group_deletion.toml b/rules/integrations/azure/impact_resource_group_deletion.toml
index e6c58cc1146..6ccdd075ad5 100644
--- a/rules/integrations/azure/impact_resource_group_deletion.toml
+++ b/rules/integrations/azure/impact_resource_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,51 +24,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Resource Group Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Resource Group Deletion
-
-Azure Resource Groups are containers that hold related resources for an Azure solution, enabling streamlined management and organization. Adversaries may exploit this by deleting entire groups to disrupt services or erase data, causing significant impact. The detection rule monitors Azure activity logs for successful deletion operations, alerting analysts to potential malicious actions aimed at data destruction.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the deletion event by checking the `event.dataset` and `azure.activitylogs.operation_name` fields for "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and ensure the `event.outcome` is marked as Success.
-- Identify the user or service principal responsible for the deletion by examining the `azure.activitylogs.caller` field in the logs.
-- Check the timestamp of the deletion event to determine when the resource group was deleted and correlate it with any other suspicious activities around the same time.
-- Investigate the IP address and location from which the deletion request was made using the `azure.activitylogs.caller_ip_address` field to identify any anomalies or unauthorized access.
-- Review the audit logs for any preceding activities by the same user or IP address to identify potential reconnaissance or privilege escalation attempts.
-- Examine the `azure.activitylogs.correlation_id` to trace related operations and understand the broader context of the deletion event.
-- Use Osquery to query the Azure environment for any recent changes in user roles or permissions that could have facilitated the deletion. Example query: `SELECT * FROM azure_role_assignments WHERE principal_id = '<user_id>' AND timestamp > '<deletion_time>';`
-- Check for any alerts or incidents in the security information and event management (SIEM) system that might be related to the same user or resource group.
-- Investigate any recent changes to the Azure subscription or resource group policies that might have allowed the deletion to occur without proper authorization.
-- Collaborate with the affected teams to gather additional context about the resource group, such as its importance, the data it contained, and any potential impact of its deletion.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks can trigger the Azure Resource Group Deletion alert, especially during scheduled clean-up operations or when decommissioning resources. 
-- Automated scripts or tools used for resource management might also delete resource groups as part of their normal operation, leading to false positives.
-- To manage these false positives, users can create exceptions for known maintenance windows or specific administrative accounts that regularly perform these tasks.
-- Implementing a whitelist of trusted IP addresses or service accounts that are authorized to delete resource groups can help reduce unnecessary alerts.
-- Regularly reviewing and updating the list of exceptions based on changes in administrative practices or personnel can further minimize false positives.
-
-### Response and remediation
-
-- Immediately isolate affected Azure subscriptions to prevent further unauthorized actions and assess the scope of the deletion.
-- Review Azure activity logs to identify the source of the deletion request, including user accounts, IP addresses, and timestamps.
-- Verify if the deletion was authorized by contacting the responsible team or individual; if unauthorized, escalate to the security incident response team.
-- Restore deleted resources from backups if available, prioritizing critical services to minimize downtime and operational impact.
-- Implement Azure Role-Based Access Control (RBAC) to restrict permissions, ensuring only authorized personnel can delete resource groups.
-- Enable Azure Multi-Factor Authentication (MFA) for all accounts with permissions to delete resources to add an additional layer of security.
-- Configure Azure Monitor and Security Center to alert on suspicious activities, such as unexpected deletions or changes in resource configurations.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Integrate Azure activity logs with a Security Information and Event Management (SIEM) system for enhanced monitoring and correlation with other security events.
-- Educate and train staff on security best practices and the importance of monitoring and protecting critical resources against data destruction threats.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_virtual_network_device_modified.toml b/rules/integrations/azure/impact_virtual_network_device_modified.toml
index 634f2ff1118..f1e9e003e68 100644
--- a/rules/integrations/azure/impact_virtual_network_device_modified.toml
+++ b/rules/integrations/azure/impact_virtual_network_device_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Virtual Network Device Modified or Deleted"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Virtual Network Device Modified or Deleted
-
-Azure virtual network devices, such as network interfaces, virtual hubs, and routers, are crucial for managing network traffic and connectivity in cloud environments. Adversaries may target these devices to disrupt services or reroute traffic for data exfiltration. The detection rule monitors specific Azure activity logs for operations indicating modifications or deletions, helping identify unauthorized changes that could signify malicious activity.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the specific operation that triggered the alert, focusing on the `azure.activitylogs.operation_name` field to identify whether it was a modification or deletion.
-- Check the `event.outcome` field to ensure the operation was successful, as this indicates the change was applied.
-- Identify the user or service principal responsible for the operation by examining the `azure.activitylogs.caller` field to determine if the action was authorized.
-- Investigate the timestamp of the event to correlate with any other suspicious activities or changes in the environment.
-- Cross-reference the affected virtual network device with recent changes in network traffic patterns or connectivity issues to assess potential impact.
-- Use Osquery to gather additional context about the affected virtual network device. For example, run a query to list all network interfaces and their configurations: `SELECT * FROM azure_network_interfaces WHERE name = '<affected_device_name>';`.
-- Review any associated Azure Resource Manager (ARM) templates or scripts that might have been used to deploy or modify the network device to ensure they have not been tampered with.
-- Check for any recent changes in Azure policies or role assignments that might have inadvertently allowed unauthorized modifications.
-- Investigate any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or coordinated attacks.
-- Consult with the network and cloud infrastructure teams to verify if the change was part of a planned maintenance or deployment activity.
-
-### False positive analysis
-
-- Routine maintenance activities by network administrators can trigger this rule, such as scheduled updates or configuration changes to network interfaces, virtual hubs, or routers. These actions are typically non-threatening and can be excluded by creating exceptions for known maintenance windows or specific user accounts.
-- Automated scripts or tools used for network management might also cause false positives if they perform frequent write or delete operations on virtual network devices. Users can handle these by identifying and excluding operations from trusted automation tools or service accounts.
-- Changes made by authorized third-party services or integrations that manage network configurations could be mistakenly flagged. To manage this, users should whitelist operations from these services by specifying their unique identifiers or IP addresses in the exclusion criteria.
-- In environments with dynamic scaling, automated processes that modify or delete network interfaces as part of scaling operations may be misinterpreted as malicious. Users can mitigate this by setting up exceptions for operations linked to known scaling activities or specific resource groups.
-
-### Response and remediation
-
-- Immediately isolate the affected virtual network device to prevent further unauthorized access or changes.
-- Review Azure activity logs to identify the source and scope of the modification or deletion, focusing on user accounts and IP addresses involved.
-- Verify the integrity of other network devices and configurations to ensure no additional unauthorized changes have occurred.
-- Restore the modified or deleted virtual network device from a known good backup to return the system to its operational state.
-- Implement stricter access controls and multi-factor authentication for accounts with permissions to modify network devices.
-- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack.
-- Conduct a root cause analysis to understand how the unauthorized change occurred and identify any security gaps.
-- Enhance logging policies to ensure comprehensive monitoring of all critical network device operations and integrate with a SIEM for real-time alerts.
-- Update and patch all network devices and related software to mitigate vulnerabilities that could be exploited by adversaries.
-- Educate and train staff on recognizing and responding to suspicious activities related to network device management, leveraging MITRE ATT&CK framework for threat context.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"]
diff --git a/rules/integrations/azure/initial_access_external_guest_user_invite.toml b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
index bc31030ecb0..ec46d414b1e 100644
--- a/rules/integrations/azure/initial_access_external_guest_user_invite.toml
+++ b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,51 +24,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure External Guest User Invitation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure External Guest User Invitation
-
-Azure Active Directory (AD) facilitates collaboration by allowing external users to be invited as guests, enhancing flexibility but also introducing security risks. Adversaries might exploit this by creating guest accounts to gain unauthorized access. The detection rule monitors audit logs for successful external user invitations, flagging potential misuse by identifying operations linked to guest account creation.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the details of the invitation event by checking the `azure.auditlogs.operation_name` field for "Invite external user" and ensure the `event.outcome` is marked as "Success".
-- Identify the inviter by examining the `azure.auditlogs.properties.initiated_by.user.display_name` and `azure.auditlogs.properties.initiated_by.user.user_principal_name` fields to determine who initiated the guest invitation.
-- Verify the legitimacy of the invited guest by checking the `azure.auditlogs.properties.target_resources.*.display_name` field for the guest's display name and cross-referencing it with known business contacts or partners.
-- Investigate the inviter's recent activities by querying additional audit logs for any unusual or unauthorized actions performed by the inviter's account.
-- Check the `azure.auditlogs.properties.target_resources.*.user_principal_name` field to gather more information about the guest account and verify if it aligns with any known external collaborators.
-- Use Osquery to further investigate the inviter's machine for any signs of compromise. Example query: `SELECT * FROM processes WHERE user = '<inviter_user_principal_name>';` to list running processes under the inviter's account.
-- Assess the frequency and pattern of guest invitations by the same inviter to identify any anomalies or patterns that deviate from normal business operations.
-- Review the organization's guest user policy and compare it with the current invitation to ensure compliance and identify any deviations.
-- Investigate any recent changes to the Azure AD configuration or permissions that might have facilitated unauthorized guest invitations.
-- Collaborate with the IT or security team to gather additional context on the business need for the guest invitation and verify if it aligns with ongoing projects or partnerships.
-
-### False positive analysis
-
-- Invitations sent to external partners or vendors for legitimate business collaborations can trigger false positives. These are often necessary for project-based work or temporary access needs.
-- Automated systems or applications that require guest access for integration purposes might also be flagged. These systems often have predictable patterns and can be whitelisted.
-- Regular audits of guest accounts can help identify and exclude known, non-threatening guest users from triggering alerts. This involves maintaining an updated list of approved external collaborators.
-- Implementing a review process for guest invitations can help distinguish between legitimate and suspicious activities. This process can include verifying the inviter's identity and the business justification for the invitation.
-- Use Azure AD's built-in features to set up conditional access policies that can help reduce false positives by allowing only specific domains or email addresses to be invited as guests.
-
-### Response and remediation
-
-- Verify the legitimacy of the guest user invitation by contacting the inviter and confirming the business need for the guest account.
-- Temporarily disable the guest account to prevent unauthorized access while the investigation is ongoing.
-- Review the audit logs to identify any suspicious activities associated with the guest account, such as unusual login attempts or access to sensitive resources.
-- Cross-reference the guest account details with known threat intelligence sources to determine if the account is linked to any known adversaries or malicious activities.
-- If the guest account is deemed unauthorized, remove the account from Azure Active Directory and revoke any permissions or access granted.
-- Escalate the incident to the security operations team if the investigation reveals potential compromise or if the guest account is linked to a broader attack campaign.
-- Implement stricter guest user invitation policies, such as requiring multi-factor authentication and approval from a higher-level authority before creating guest accounts.
-- Enhance logging and monitoring by integrating Azure AD logs with a Security Information and Event Management (SIEM) system to detect and alert on suspicious activities in real-time.
-- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
-- Educate employees on the risks associated with guest user invitations and provide training on secure collaboration practices to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/governance/policy/samples/cis-azure-1-1-0"]
diff --git a/rules/integrations/azure/persistence_azure_automation_account_created.toml b/rules/integrations/azure/persistence_azure_automation_account_created.toml
index cac9f142857..114f1210d26 100644
--- a/rules/integrations/azure/persistence_azure_automation_account_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -16,50 +16,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Account Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Automation Account Created
-
-Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud and on-premises environments. Adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule identifies the creation of such accounts by monitoring specific Azure activity logs, focusing on successful operations that could indicate unauthorized account creation.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the creation of the Automation account by filtering logs with `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE"`.
-- Verify the `event.outcome` field to ensure the operation was successful, indicating the account was indeed created.
-- Identify the user or service principal responsible for the account creation by examining the `azure.activitylogs.caller` field.
-- Check the timestamp of the account creation event to determine when the activity occurred and correlate it with other suspicious activities.
-- Investigate the IP address and location associated with the `azure.activitylogs.callerIpAddress` field to assess if the activity originated from an expected or unusual source.
-- Review the `azure.activitylogs.correlationId` to trace related activities and operations that might provide additional context or indicate a broader attack.
-- Use Osquery to gather more information about the environment by running a query such as: `SELECT * FROM azure_automation_accounts WHERE account_name = '<AccountName>'` to retrieve details about the newly created account.
-- Examine the permissions and roles assigned to the new Automation account to determine if they are excessive or deviate from the norm.
-- Cross-reference the creation event with any recent changes in Azure policies or configurations that might have allowed unauthorized account creation.
-- Investigate any subsequent activities performed by the Automation account to identify potential malicious actions or scripts executed post-creation.
-
-### False positive analysis
-
-- Routine administrative tasks: Organizations often create Azure Automation accounts for legitimate purposes such as automating routine administrative tasks, patch management, or resource scaling. These activities can trigger the detection rule, leading to false positives.
-- Development and testing environments: In environments where developers frequently create and delete resources for testing purposes, the creation of Azure Automation accounts may be a common occurrence and not indicative of malicious activity.
-- Third-party integrations: Some third-party services and tools may automatically create Azure Automation accounts as part of their integration process, which can be mistaken for unauthorized activity.
-- To manage false positives, users can create exceptions for known and trusted sources by whitelisting specific user accounts or service principals that are authorized to create Azure Automation accounts. Additionally, users can implement tagging or naming conventions for automation accounts to easily identify legitimate accounts and exclude them from alerts. Regularly reviewing and updating these exceptions based on changes in the environment can help maintain the accuracy of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the Azure Automation account to prevent further unauthorized activities by disabling the account or restricting its permissions.
-- Conduct a thorough investigation to determine the origin of the account creation, including reviewing the activity logs for the user or service principal responsible for the action.
-- Verify the legitimacy of the account creation with relevant stakeholders or system owners to confirm whether it was authorized or not.
-- If unauthorized, remove the Automation account and any associated resources or scripts that may have been deployed by the adversary.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised.
-- Implement enhanced logging and monitoring for Azure Automation activities, ensuring that all account creations and modifications are logged and reviewed regularly.
-- Integrate Azure Security Center or other security information and event management (SIEM) solutions to provide real-time alerts and automated responses to suspicious activities.
-- Review and update access controls and permissions for Azure resources to ensure the principle of least privilege is enforced, reducing the risk of unauthorized account creation.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements to prevent future incidents.
-- Educate and train staff on recognizing and responding to suspicious activities related to Azure Automation accounts and other cloud resources, enhancing overall security awareness.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
index c297b574ece..94aa992de20 100644
--- a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
+++ b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -15,50 +15,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Runbook Created or Modified"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Automation Runbook Created or Modified
-
-Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code, ensuring persistence and control. The detection rule monitors specific operations indicating runbook creation or modification, flagging successful events to identify potential misuse and safeguard against malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific operation that triggered the alert, focusing on the `azure.activitylogs.operation_name` field to determine if it was a draft write, a write, or a publish action.
-- Examine the `event.outcome` field to confirm the success of the operation, ensuring that the alert is based on a successful event.
-- Identify the user or service principal that performed the operation by reviewing the relevant fields in the activity logs, such as `azure.activitylogs.caller`.
-- Check the timestamp of the event to determine when the runbook was created or modified, which can help correlate with other activities in the environment.
-- Investigate the runbook's content and changes by accessing the Azure Automation account and reviewing the runbook's version history and code.
-- Cross-reference the user or service principal with recent login activities and other actions in Azure AD logs to identify any unusual or unauthorized access patterns.
-- Use Osquery to gather additional context on the system where the runbook might be executed. For example, run an Osquery query to list all scheduled tasks or cron jobs that might be related to the runbook execution.
-- Query Azure Resource Graph or Azure Monitor logs to identify any other recent changes or deployments in the same Azure Automation account or resource group.
-- Investigate any network or system logs for unusual outbound connections or data transfers that might be associated with the runbook's execution.
-- Collaborate with the application or system owner to verify the legitimacy of the runbook changes and gather additional context on its intended use and any recent operational changes.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or maintenance activities by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time windows when these tasks are expected.
-- Automated deployment processes: Continuous integration and deployment pipelines might create or modify runbooks as part of their normal operation. Users should identify and exclude these processes by filtering based on the service accounts or automation tools involved.
-- Third-party integrations: Some third-party services may interact with Azure Automation to enhance functionality, leading to benign runbook modifications. Users can handle these by whitelisting specific application IDs or service principals associated with trusted integrations.
-- Testing and development activities: Developers may frequently create or modify runbooks in non-production environments. Users can reduce false positives by excluding specific environments or resource groups dedicated to development and testing.
-
-### Response and remediation
-
-- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions.
-- Review the activity logs to identify the source and scope of the unauthorized runbook creation or modification.
-- Verify the integrity of all runbooks within the affected Automation account to ensure no other scripts have been tampered with.
-- Revoke any suspicious or unauthorized access permissions to the Azure Automation account and associated resources.
-- Restore any modified or deleted runbooks from backups to ensure the system returns to its intended operational state.
-- Implement Azure Monitor alerts for any future runbook creation or modification activities to ensure timely detection of unauthorized changes.
-- Conduct a thorough investigation to determine if the unauthorized runbook activity is part of a larger attack, leveraging MITRE ATT&CK framework for threat context.
-- Escalate the incident to the security operations team if the activity is linked to known threat actors or if the scope of the attack is beyond initial containment.
-- Enhance logging policies to include detailed audit logs for all Azure Automation activities and integrate with a Security Information and Event Management (SIEM) system for continuous monitoring.
-- Review and update security policies and access controls for Azure Automation accounts to adhere to the principle of least privilege, reducing the risk of future unauthorized access.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
index 456327599a5..370c2d78c7c 100644
--- a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -16,52 +16,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Webhook Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Automation Webhook Created
-
-Azure Automation webhooks enable automated task execution via HTTP requests, integrating external systems with Azure runbooks. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts. The detection rule monitors Azure activity logs for webhook creation events, identifying potential misuse by flagging successful operations related to webhook actions.
-
-### Possible investigation steps
-
-- Review the Azure activity logs to confirm the details of the webhook creation event, focusing on the `azure.activitylogs.operation_name` field to verify if it matches "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/ACTION" or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/WRITE".
-- Check the `event.outcome` field to ensure the operation was successful, as this indicates the webhook was indeed created.
-- Identify the user or service principal that initiated the webhook creation by examining the `azure.activitylogs.caller` field to determine if the action was authorized or suspicious.
-- Investigate the source IP address and location from which the webhook creation request originated to identify any anomalies or unexpected geolocations.
-- Review the associated runbook that the webhook is configured to trigger, ensuring it does not contain any unauthorized or malicious scripts.
-- Cross-reference the webhook creation event with other recent Azure activity logs to identify any related suspicious activities, such as changes to runbooks or automation accounts.
-- Utilize Osquery to gather additional context on the system where the webhook was created. For example, run the following Osquery query to list recent Azure Automation activities: `SELECT * FROM azure_activity WHERE operation_name LIKE '%WEBHOOKS%' AND outcome = 'Success';`
-- Check for any recent changes in permissions or roles assigned to the user or service principal involved in the webhook creation to ensure they have not been escalated improperly.
-- Analyze any alerts or logs from security monitoring tools that might indicate attempts to exploit the webhook or the associated runbook.
-- Consult with the team responsible for Azure Automation to verify if the webhook creation was part of a legitimate change or deployment process.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT operations may involve creating webhooks for automation purposes, such as regular system maintenance or data processing tasks. These actions can trigger the detection rule, leading to false positives.
-- Development and testing activities: Developers and IT teams often create and test webhooks during the development of new automation processes. These activities can be mistaken for malicious actions.
-- Third-party integrations: Some third-party applications and services integrate with Azure Automation using webhooks to perform authorized tasks, which might be flagged by the rule.
-- To manage false positives, users can create exceptions for known and trusted sources by whitelisting specific IP addresses or user accounts associated with legitimate webhook creation activities.
-- Implementing a review process for webhook creation logs can help differentiate between authorized and unauthorized activities, allowing for more accurate threat detection.
-- Regularly updating and refining the detection rule criteria based on organizational needs and known benign activities can reduce the occurrence of false positives.
-
-### Response and remediation
-
-- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks.
-- Review the Azure activity logs to identify the source and context of the webhook creation, including the user account and IP address involved.
-- Conduct a thorough investigation of the runbook associated with the webhook to determine if it contains malicious code or unauthorized changes.
-- If malicious activity is confirmed, isolate affected systems and runbooks to prevent further compromise.
-- Escalate the incident to the security operations team for a detailed analysis and to determine the scope of the breach.
-- Implement Azure Monitor alerts to notify security teams of any future webhook creation events for proactive monitoring.
-- Enhance logging policies to ensure comprehensive capture of Azure activity logs, focusing on automation accounts and webhook activities.
-- Integrate Azure Security Center and other security tools to provide a unified view of security alerts and streamline incident response.
-- Restore any affected systems or runbooks to their last known good state, ensuring that all malicious code is removed.
-- Apply hardening measures such as restricting webhook creation permissions to only trusted administrators and regularly reviewing access controls.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
index d340bd832ba..fda5b5dbbe4 100644
--- a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
+++ b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -17,50 +17,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Conditional Access Policy Modified"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Conditional Access Policy Modified
-
-Azure Conditional Access policies are critical for securing access to resources by enforcing specific conditions, such as requiring multi-factor authentication. Adversaries may exploit this by altering policies to reduce security, thereby gaining unauthorized access. The detection rule monitors logs for successful updates to these policies, signaling potential tampering attempts that could compromise security.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Conditional Access policy that was modified, focusing on the `event.action` and `event.outcome` fields to confirm the successful update.
-- Check the `event.dataset` field to determine whether the modification was logged in `azure.activitylogs` or `azure.auditlogs`, as this can provide context on the type of activity.
-- Identify the user or service principal responsible for the modification by examining the `user.name` or `user.id` fields in the logs.
-- Investigate the user's recent activities and login history to determine if there are any anomalies or signs of compromise, such as unusual login locations or times.
-- Review the changes made to the Conditional Access policy, including any alterations to conditions or controls like multi-factor authentication requirements.
-- Cross-reference the modification time with other security events or alerts to identify any correlated suspicious activities.
-- Use Osquery to gather additional context on the system or user involved. For example, run a query to list recent Azure AD sign-ins: `SELECT * FROM azure_ad_signins WHERE user_principal_name = 'user@example.com' AND timestamp > 'YYYY-MM-DD'`.
-- Check for any recent changes in user permissions or roles that might indicate privilege escalation attempts.
-- Analyze the IP addresses and devices associated with the modification event to identify any unfamiliar or suspicious sources.
-- Consult with the policy owner or relevant stakeholders to verify if the modification was authorized and aligns with current security policies.
-
-### False positive analysis
-
-- Routine administrative updates: Regular updates or changes made by authorized IT personnel to improve or maintain security policies can trigger the detection rule. To manage this, organizations can create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated policy updates: Some organizations use automated scripts or tools to update Conditional Access policies as part of their security management processes. These actions can be excluded by identifying and whitelisting the specific scripts or service accounts involved.
-- Third-party integrations: Integrations with third-party security tools or services that modify Conditional Access policies as part of their functionality may cause false positives. Users can handle these by reviewing and approving the integration processes and excluding them from the detection rule.
-- Policy testing and validation: Security teams may modify policies temporarily for testing or validation purposes. To prevent these from being flagged, organizations can document and exclude these activities by correlating them with change management records.
-
-### Response and remediation
-
-- Immediately review the modified Conditional Access policy to understand the changes and assess the potential impact on security.
-- Revert any unauthorized changes to the Conditional Access policy to restore the original security posture.
-- Conduct a thorough investigation to identify the source of the modification, including reviewing audit logs for unusual activity or unauthorized access attempts.
-- Isolate any compromised accounts or systems identified during the investigation to prevent further unauthorized access.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments to assess potential regulatory impacts.
-- Implement additional logging and monitoring for Conditional Access policy changes to detect future unauthorized modifications promptly.
-- Integrate security information and event management (SIEM) solutions to correlate events and enhance threat detection capabilities.
-- Educate and train staff on the importance of Conditional Access policies and the risks associated with unauthorized modifications.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify Conditional Access policies.
-- Consider implementing additional security measures, such as just-in-time access or privileged access management, to further protect critical configurations.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview"]
diff --git a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
index abccd352026..d3509a4a043 100644
--- a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
+++ b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -18,52 +18,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure AD Global Administrator Role Assigned"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure AD Global Administrator Role Assigned
-
-Azure AD's Global Administrator role grants comprehensive access to manage Azure AD and associated services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit logs for role changes, focusing on the addition of members to the Global Administrator role.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement fields, ensuring the alert is related to role management activities.
-- Examine the azure.auditlogs.operation_name field to verify that the operation was indeed "Add member to role," confirming the nature of the role assignment.
-- Check the azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value field to ensure the new value is "\\"Global Administrator\\"", indicating the specific role assigned.
-- Identify the user account that was added to the Global Administrator role by reviewing the azure.auditlogs.properties.target_resources.0.display_name field.
-- Investigate the initiator of the role assignment by examining the azure.auditlogs.properties.initiated_by.user.display_name and azure.auditlogs.properties.initiated_by.user.user_principal_name fields to determine if the action was performed by a legitimate administrator.
-- Correlate the timestamp of the event with other security logs to identify any suspicious activities or patterns around the time of the role assignment.
-- Use Osquery to gather additional context on the involved user accounts. For example, run a query to list all current Global Administrators: `SELECT * FROM azure_ad_users WHERE role = 'Global Administrator';`
-- Review the sign-in logs for the user account added to the Global Administrator role to identify any unusual login locations or times that could indicate unauthorized access.
-- Check for any recent changes to the organization's Azure AD configuration or policies that might have allowed unauthorized role assignments.
-- Investigate any other alerts or incidents involving the same user accounts or IP addresses to assess if this role assignment is part of a broader attack campaign.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may frequently assign users to the Global Administrator role as part of their regular duties, such as onboarding new IT staff or managing temporary access for troubleshooting. 
-- Automated processes: Some organizations use automated scripts or third-party tools to manage role assignments, which can trigger alerts if not properly documented or excluded.
-- Role assignment during migrations: During migrations or system upgrades, temporary role assignments might be necessary, leading to potential false positives.
-- To manage these false positives, organizations can create exceptions for known administrative accounts or processes by using filters or exclusion lists in their monitoring tools.
-- Implementing a review process for role assignments can help distinguish between legitimate and suspicious activities, reducing the likelihood of false positives.
-- Regularly updating and reviewing the list of exceptions ensures that only current and necessary exclusions are in place, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Immediately remove unauthorized users from the Global Administrator role to contain the threat and prevent further unauthorized access.
-- Conduct a thorough investigation to identify how the unauthorized assignment occurred, reviewing audit logs and any related security alerts.
-- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were added to the Global Administrator role to prevent further unauthorized access.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential impacts and obligations.
-- Review and update Azure AD role assignment policies to ensure that only authorized personnel can assign or modify Global Administrator roles.
-- Implement enhanced logging and monitoring for Azure AD role changes, ensuring that alerts are generated for any future unauthorized role assignments.
-- Integrate Azure AD logs with a Security Information and Event Management (SIEM) system to improve detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
-- Restore any affected systems or services to their operational state, ensuring that all security patches and updates are applied.
-- Harden Azure AD security by implementing least privilege access, regular role reviews, and continuous security awareness training for administrators.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
index f7798c1b942..c27d826a2e9 100644
--- a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
+++ b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,50 +24,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Global Administrator Role Addition to PIM User"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Global Administrator Role Addition to PIM User
-
-Azure AD's Global Administrator role grants extensive access, allowing users to modify any administrative setting. Privileged Identity Management (PIM) helps manage and monitor such roles. Adversaries may exploit this by adding themselves or others to this role to maintain persistent access. The detection rule identifies suspicious role additions by monitoring specific audit logs, focusing on successful role assignments to detect potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the timestamp, user involved, and the specific operation name from the query: "Add eligible member to role in PIM completed (permanent)" or "Add member to role in PIM completed (timebound)".
-- Verify the identity of the user who was added to the Global Administrator role by checking the `azure.auditlogs.properties.target_resources.*.display_name` field for "Global Administrator".
-- Examine the `event.dataset` and `azure.auditlogs.properties.category` fields to confirm the event is related to Role Management and originated from Azure audit logs.
-- Check the `event.outcome` field to ensure the operation was successful, as the query filters for "Success" or "success".
-- Investigate the user account that performed the role addition by reviewing their recent activities and login history in Azure AD logs to identify any unusual behavior or patterns.
-- Use Osquery to gather additional context on the system from which the role addition was performed. Example query: `SELECT * FROM users WHERE username = '<username_of_actor>';` to gather information about the user account on the system.
-- Cross-reference the timestamp of the role addition with other security logs and alerts to identify any correlated suspicious activities or anomalies.
-- Review the organization's change management records or tickets to determine if the role addition was authorized or part of a legitimate administrative task.
-- Investigate any recent changes to Privileged Identity Management (PIM) settings or configurations that could have facilitated unauthorized role additions.
-- Consult with the user or their manager to verify if the role addition was expected and authorized, and gather any additional context or explanations for the activity.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may frequently add users to the Global Administrator role for maintenance or operational purposes. To manage this, organizations can create exceptions for known administrative accounts or specific timeframes when such activities are expected.
-- Automated processes: Some organizations use automated scripts or tools to manage role assignments in Azure AD. These processes might trigger the detection rule. To handle this, users can whitelist specific service accounts or scripts that are known to perform these actions regularly.
-- Temporary role assignments: In some cases, users may be temporarily assigned the Global Administrator role for specific projects or tasks. These assignments can be excluded by setting up alerts only for permanent role additions or by monitoring the duration of the role assignment.
-- Training and testing environments: Activities in non-production environments might mimic suspicious behavior. Users can exclude these environments from monitoring or adjust the sensitivity of alerts to reduce noise from test scenarios.
-
-### Response and remediation
-
-- Immediately revoke the Global Administrator role from any unauthorized users identified in the alert to contain potential misuse.
-- Conduct a thorough investigation to determine how the unauthorized role assignment occurred, reviewing audit logs and any related security alerts.
-- Verify the identity and intent of the user who performed the role assignment to assess if it was a legitimate action or a potential compromise.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems have been compromised.
-- Implement conditional access policies to enforce multi-factor authentication (MFA) for all privileged role assignments to enhance security.
-- Review and update Privileged Identity Management (PIM) settings to ensure that only authorized personnel can assign or approve Global Administrator roles.
-- Enable and configure Azure AD logging to capture detailed audit logs for all role assignments and changes, ensuring logs are retained for an appropriate period.
-- Integrate Azure AD logs with a Security Information and Event Management (SIEM) system to enhance monitoring and alerting capabilities.
-- Restore any affected systems or configurations to their original state prior to the unauthorized role assignment, ensuring no residual access remains.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as least privilege access and regular role review processes.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
index 7b19c11ef1d..1da8d4b0099 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -16,50 +16,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "User Added as Owner for Azure Application"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 User Added as Owner for Azure Application
-
-Azure applications often require specific permissions to function, managed through ownership roles. Adversaries may exploit this by adding themselves or compromised accounts as owners, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations.
-
-### Possible investigation steps
-
-- Review the Azure audit logs to confirm the event details, focusing on the `azure.auditlogs.operation_name` field to ensure it matches "Add owner to application" and the `event.outcome` field to verify it indicates a success.
-- Identify the user account that was added as an owner by examining the relevant fields in the audit log entry, such as `azure.auditlogs.target_user`.
-- Determine the identity of the actor who performed the operation by checking the `azure.auditlogs.initiated_by` field to understand if it was an expected administrator or a potentially compromised account.
-- Cross-reference the timestamp of the event with other security logs to identify any unusual activities or patterns around the same time, such as failed login attempts or changes in user permissions.
-- Investigate the application in question by reviewing its configuration and permissions to assess the potential impact of the new owner addition.
-- Check the history of changes to the application to see if there have been any recent modifications that could indicate malicious intent.
-- Use Osquery to gather additional context on the user account added as an owner. For example, run a query to list recent logins or changes to the account: `SELECT * FROM users WHERE username = 'added_user';`
-- Analyze the network traffic logs for any suspicious connections or data transfers involving the application or the newly added owner account.
-- Review the organization's change management records to verify if the addition of the owner was part of an approved change request.
-- Consult with the application owner or relevant stakeholders to confirm if the addition of the new owner was expected and authorized.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may frequently add users as owners to manage application settings, leading to false positives. To handle this, create exceptions for known administrative accounts or specific time frames when these tasks are expected.  
-- Automated processes: Some organizations use automated scripts or tools to manage application ownership, which can trigger alerts. Identify and exclude these processes by filtering based on known service accounts or automation tools.  
-- Organizational changes: During mergers, acquisitions, or restructuring, there may be a legitimate need to update application ownership. Document these changes and temporarily adjust the detection rule to accommodate the expected increase in ownership changes.  
-- Training and onboarding: New employees or teams may require ownership access as part of their onboarding process. Coordinate with HR or team leads to anticipate these changes and exclude them from triggering alerts.
-
-### Response and remediation
-
-- Immediately revoke the added user's owner permissions from the Azure application to contain potential unauthorized access.
-- Conduct a thorough investigation to determine how the user was added as an owner, reviewing audit logs and identifying any suspicious activities or compromised accounts.
-- Verify the integrity of the Azure application configurations and data to ensure no unauthorized changes were made during the period of elevated access.
-- Reset credentials and enforce multi-factor authentication (MFA) for any accounts involved in the incident to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems were affected.
-- Implement enhanced logging policies to capture detailed audit logs of all administrative actions within Azure applications for future investigations.
-- Integrate security information and event management (SIEM) solutions to correlate Azure audit logs with other security events for comprehensive threat detection.
-- Restore the Azure application to its last known good configuration if any unauthorized changes were detected during the investigation.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
-- Apply hardening measures such as least privilege access, regular review of application owners, and continuous monitoring to reduce the risk of unauthorized privilege escalation.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 21
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
index 84cf1217c45..cdb7081845a 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -18,50 +18,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "User Added as Owner for Azure Service Principal"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 User Added as Owner for Azure Service Principal
-
-Azure service principals are crucial for managing application permissions within a tenant, dictating access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over app permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific service principal and user account involved in the owner addition event.
-- Verify the event timestamp to determine when the owner addition occurred and correlate it with other activities in the audit logs.
-- Check the event.dataset field to ensure it matches azure.auditlogs, confirming the source of the log data.
-- Investigate the azure.auditlogs.operation_name field to confirm the operation was "Add owner to service principal" and the event.outcome field to ensure it was a success.
-- Examine the Azure AD sign-in logs for the user account to identify any unusual login patterns or locations around the time of the event.
-- Use Osquery to gather additional context on the user account by running a query such as: `SELECT * FROM users WHERE username = '<username>';` to retrieve user details and recent activity.
-- Review the permissions and roles assigned to the service principal to assess the potential impact of the new owner addition.
-- Check for any recent changes to the application associated with the service principal, including modifications to permissions or configurations.
-- Investigate any other recent audit log entries related to the service principal or user account to identify potential patterns or additional suspicious activities.
-- Consult with the application owner or relevant stakeholders to verify if the owner addition was authorized and aligns with expected changes or maintenance activities.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may frequently add users as owners to service principals as part of regular maintenance or updates. To manage this, create exceptions for known administrative accounts or specific service principals that are regularly updated.
-- Automated processes: Some organizations use automated scripts or tools to manage service principal ownership, which can trigger false positives. Identify and exclude these automated processes by filtering based on known script or tool identifiers.
-- Third-party integrations: Certain third-party applications may require ownership changes to function correctly. Review and whitelist these applications by their service principal IDs to prevent unnecessary alerts.
-- Organizational changes: During periods of organizational restructuring, ownership changes may occur more frequently. Temporarily adjust the rule sensitivity or add exceptions for specific departments undergoing changes to reduce false positives.
-
-### Response and remediation
-
-- Immediately revoke the newly added owner's permissions to prevent further unauthorized access or changes to the service principal.
-- Conduct a thorough investigation to determine how the unauthorized addition occurred, including reviewing audit logs and identifying the source of the change.
-- Verify the integrity of the service principal and associated applications to ensure no malicious configurations or permissions have been set.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or service principals have been compromised.
-- Implement conditional access policies to restrict who can modify service principal ownership and enforce multi-factor authentication for privileged actions.
-- Enhance logging and monitoring by integrating Azure Security Center and Azure Sentinel to provide real-time alerts and deeper insights into suspicious activities.
-- Review and update access control policies to ensure the principle of least privilege is enforced across all service principals and associated resources.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Restore the system to its operational state by ensuring all service principals and applications are configured correctly and securely.
-- Implement hardening measures such as regular audits of service principal permissions and continuous security training for administrators to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
index ea5691caa57..c57337e5f17 100644
--- a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
+++ b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -17,51 +17,7 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Rolebindings Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Azure Kubernetes Rolebindings Created
-
-Azure Kubernetes role bindings are crucial for managing access control by linking users or service accounts to specific roles within a cluster. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others to high-privilege roles like cluster-admin. The detection rule monitors activity logs for role binding creation events, flagging successful operations that could indicate unauthorized privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the activity logs to confirm the presence of the role binding creation event by checking the `event.dataset:azure.activitylogs` and `azure.activitylogs.operation_name` fields for the specific operations related to role bindings and cluster role bindings.
-- Verify the `event.outcome` field to ensure the operation was successful, as this indicates the role binding was indeed created.
-- Identify the user or service account responsible for the role binding creation by examining the `azure.activitylogs.caller` field to determine if the action was performed by an authorized entity.
-- Check the `azure.activitylogs.resource` field to understand which specific role or cluster role was assigned and to whom, providing insight into potential privilege escalation.
-- Investigate the historical activity of the identified user or service account to determine if there are any patterns of suspicious behavior or previous unauthorized access attempts.
-- Use Osquery to gather additional context on the Kubernetes cluster by running a query such as: `SELECT * FROM kubernetes_rolebindings WHERE name = '<rolebinding_name>';` to retrieve detailed information about the role binding.
-- Cross-reference the role binding creation event with other security logs and alerts to identify any correlated activities that might indicate a broader attack or compromise.
-- Assess the current permissions and roles assigned to the user or service account involved in the role binding creation to evaluate if they have been granted excessive privileges.
-- Review any recent changes to the cluster's RBAC policies or configurations that might have inadvertently allowed unauthorized role binding creation.
-- Consult with the cluster administrators or security team to verify if the role binding creation was part of a legitimate change or deployment process, ensuring alignment with organizational policies.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular operations by authorized personnel, such as creating role bindings for legitimate service accounts or users, can trigger alerts. To manage these, identify and document routine administrative activities and create exceptions for these specific actions in the detection rule.
-- Automated deployment tools: Continuous integration and deployment pipelines often create role bindings as part of their normal operation. Review and whitelist these tools by identifying their specific service accounts or user identities to prevent unnecessary alerts.
-- Third-party integrations: Some third-party applications or services may require role bindings to function correctly. Evaluate these integrations and, if deemed non-threatening, add them to an exception list based on their unique identifiers or operation patterns.
-- Testing environments: Development and testing environments may frequently create and modify role bindings as part of testing processes. Consider excluding these environments from monitoring or adjusting the sensitivity of alerts for these specific clusters to reduce noise.
-- Scheduled maintenance: During scheduled maintenance windows, role bindings might be created or modified as part of system updates or configuration changes. Document these maintenance activities and temporarily adjust alerting rules to avoid false positives during these periods.
-
-### Response and remediation
-
-- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation.
-- Review the activity logs to identify the source of the role binding creation and determine if it was authorized or part of a malicious activity.
-- Revoke any unauthorized role bindings or cluster role bindings that have been created, especially those granting high privileges like cluster-admin.
-- Conduct a thorough investigation to identify any other potential security breaches or compromised accounts within the cluster.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data have been affected.
-- Implement enhanced logging and monitoring for Kubernetes role binding activities to detect future unauthorized changes promptly.
-- Integrate security information and event management (SIEM) tools to correlate Kubernetes activity logs with other security events for comprehensive threat detection.
-- Restore the system to its operational state by reapplying legitimate role bindings and ensuring all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
-- Implement hardening measures such as role-based access control (RBAC) policies, network segmentation, and regular security audits to reduce the attack surface.
-
-## Setup
+note = """## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/beaconing/command_and_control_beaconing.toml b/rules/integrations/beaconing/command_and_control_beaconing.toml
index cedf60cd009..9d4a5ba44d8 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -56,49 +56,6 @@ not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "
                    "agentbeat" or "dnf" or "yum" or "apt"
                   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity
-
-Statistical models analyze network traffic patterns to identify anomalies indicative of command-and-control (C2) beaconing, a technique used by attackers to maintain covert communication with compromised systems. Adversaries exploit this by sending periodic signals to C2 servers, often mimicking legitimate traffic. The detection rule filters out known benign processes, focusing on unusual beaconing patterns to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the timestamp, source IP, destination IP, and any associated user accounts.
-- Verify the process name involved in the alert to ensure it is not one of the known benign processes listed in the query filter.
-- Analyze network traffic logs to identify patterns or anomalies in the communication frequency, size, and timing that may indicate beaconing behavior.
-- Cross-reference the destination IP address with threat intelligence databases to check for any known malicious activity or associations with C2 infrastructure.
-- Use Osquery to gather additional context on the process involved in the alert. For example, run the following query to list network connections for the suspicious process: `SELECT pid, local_address, local_port, remote_address, remote_port, state FROM process_open_sockets WHERE pid = <suspicious_process_id>;`
-- Investigate the parent process of the suspicious activity to determine if it was spawned by a legitimate application or another potentially malicious process.
-- Check the system's event logs for any unusual activity or errors around the time of the alert that could provide additional context or indicators of compromise.
-- Examine the file system for any new or modified files associated with the suspicious process, which may indicate payload delivery or data exfiltration.
-- Review user activity logs to determine if the user associated with the alert was performing any unusual actions or accessing sensitive data.
-- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
-
-### False positive analysis
-
-- Known false positives for the Statistical Model Detected C2 Beaconing Activity rule include legitimate applications that exhibit periodic network communication patterns similar to C2 beaconing. These applications often include system monitoring tools, cloud service agents, and software update services.
-- Users can manage these false positives by creating exceptions for processes that are known to generate benign beaconing patterns. This can be done by adding these processes to the exclusion list within the detection rule, ensuring that legitimate traffic is not flagged as suspicious.
-- Regularly review and update the exclusion list to accommodate new software or updates to existing applications that may alter their network communication behavior.
-- Consider the context of the network environment and the typical behavior of applications in use. For instance, if a new application is introduced that mimics beaconing patterns, assess its legitimacy before adding it to the exclusion list.
-- Collaborate with IT and security teams to identify and document legitimate processes that may trigger false positives, ensuring that the detection rule remains effective without compromising security.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further communication with the C2 server and limit potential data exfiltration.
-- Conduct a thorough investigation of the affected system to identify any malicious processes or files, leveraging endpoint detection and response (EDR) tools.
-- Analyze network traffic logs to identify any other systems that may be communicating with the same C2 server, expanding the scope of the investigation if necessary.
-- Remove any identified malicious software or files from the affected system and apply security patches to address any vulnerabilities exploited by the attacker.
-- Change passwords and credentials that may have been compromised, focusing on accounts with elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring policies to capture detailed network and endpoint activity, aiding in future detection and investigation efforts.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of known C2 infrastructure and tactics.
-- Restore the system to its operational state by reinstalling the operating system if necessary and ensuring all security measures are in place.
-- Apply hardening measures such as disabling unnecessary services, enforcing least privilege access, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
index 713b0cd09d4..aaef19e8d11 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -50,49 +50,6 @@ type = "query"
 query = '''
 beacon_stats.beaconing_score: 3
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity with High Confidence
-
-Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic where attackers maintain covert communication with their servers. Adversaries exploit this to issue commands, exfiltrate data, and sustain network presence. The detection rule flags high-confidence beaconing activity by scoring traffic patterns, aligning with known C2 tactics and techniques.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the timestamp, source and destination IP addresses, and any associated user accounts.
-- Examine the `beacon_stats.beaconing_score` field to assess the severity and confidence level of the detected activity.
-- Correlate the detected IP addresses with known threat intelligence feeds to check for any matches with known malicious C2 servers.
-- Use network traffic analysis tools to inspect the traffic patterns associated with the flagged IP addresses, focusing on regular intervals or unusual data transfer patterns.
-- Investigate the processes and applications on the affected host(s) using Osquery to identify any suspicious or unauthorized software. Example Osquery query: `SELECT name, path, pid FROM processes WHERE pid IN (SELECT pid FROM listening_ports WHERE address = '<flagged IP address>');`
-- Check for any recent changes or anomalies in the system logs of the affected host(s) that might indicate compromise or unauthorized access.
-- Analyze DNS query logs to identify any unusual or frequent DNS requests to domains associated with the flagged IP addresses.
-- Review user activity logs to determine if any unauthorized or unusual actions were performed by the user accounts associated with the alert.
-- Investigate any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or correlations with other suspicious activities.
-- Consult with threat intelligence teams or resources to gather additional context or insights into the potential threat actor's tactics, techniques, and procedures (TTPs) associated with the detected C2 activity.
-
-### False positive analysis
-
-- Known false positives for the Statistical Model Detected C2 Beaconing Activity with High Confidence rule may include legitimate applications or services that regularly communicate with external servers, such as software updates, cloud services, or telemetry data transmissions. These activities can mimic C2 beaconing patterns due to their periodic nature.
-- To manage these false positives, users can create exceptions for specific IP addresses or domains known to be associated with legitimate services. This can be done by maintaining a whitelist of trusted sources and updating it regularly to ensure that benign traffic is not flagged as malicious.
-- Users should also consider analyzing the frequency and timing of the detected beaconing activity. If the pattern aligns with known update schedules or business operations, it may be a candidate for exclusion.
-- Implementing network segmentation and monitoring can help differentiate between legitimate and suspicious traffic, allowing for more accurate identification of false positives.
-- Regularly reviewing and updating the statistical model's parameters and thresholds can help reduce the occurrence of false positives by better aligning the detection criteria with the organization's specific network environment and traffic patterns.
-
-### Response and remediation
-
-- Isolate the affected systems from the network to prevent further communication with the C2 server and contain the threat.
-- Conduct a thorough investigation of the affected systems to identify the scope of the compromise, focusing on network traffic logs and endpoint activity.
-- Utilize MITRE ATT&CK framework details to understand the adversary's tactics, techniques, and procedures, specifically focusing on TA0011 and T1102, to anticipate potential attacker actions.
-- Remove any identified malicious software or scripts from the affected systems and ensure all unauthorized access points are closed.
-- Change all credentials and authentication tokens that may have been exposed or compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Implement enhanced logging policies to capture detailed network traffic and endpoint activity for future investigations, ensuring logs are stored securely and are easily accessible.
-- Integrate threat intelligence feeds and anomaly detection tools to improve the detection of similar threats in the future.
-- Restore the affected systems from clean backups, ensuring that all security patches and updates are applied before reconnecting to the network.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and stricter access controls, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/container_workload_protection.toml b/rules/integrations/cloud_defend/container_workload_protection.toml
index 2e99a1d4fce..af8cc879b82 100644
--- a/rules/integrations/cloud_defend/container_workload_protection.toml
+++ b/rules/integrations/cloud_defend/container_workload_protection.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/05"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -37,47 +37,4 @@ type = "query"
 query = '''
 event.kind:alert and event.module:cloud_defend
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Container Workload Protection
-
-Container Workload Protection is crucial for securing containerized environments by monitoring and defending against threats. Adversaries may exploit vulnerabilities in container orchestration or misconfigurations to gain unauthorized access or execute malicious code. The detection rule identifies suspicious activities by generating alerts when specific cloud defense events are triggered, enabling swift investigation and response.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `event.kind:alert` and `event.module:cloud_defend` fields to confirm the alert's origin and type.
-- Check the timestamp of the alert to determine when the suspicious activity occurred and correlate it with any known changes or events in the environment.
-- Identify the container and host involved in the alert by examining metadata such as container ID, image name, and host IP address.
-- Investigate recent changes or deployments in the container orchestration platform that might have introduced vulnerabilities or misconfigurations.
-- Use Osquery to gather additional information about the container environment. For example, run the following query to list all running containers and their associated images: `SELECT id, name, image FROM docker_containers;`
-- Analyze logs from the container orchestration system (e.g., Kubernetes, Docker) to identify any unusual activities or errors around the time of the alert.
-- Cross-reference the alert with other security tools and logs to identify any related alerts or indicators of compromise.
-- Investigate the user accounts and roles involved in the alert to ensure they have appropriate permissions and have not been compromised.
-- Examine network traffic logs to detect any unusual or unauthorized connections to or from the container.
-- Review historical data for similar alerts to identify patterns or recurring issues that might indicate a broader security concern.
-
-### False positive analysis
-
-- Alerts may be triggered by routine administrative tasks or benign activities within the container environment, such as regular updates or maintenance operations, which are not indicative of malicious behavior.
-- Automated deployment processes or continuous integration/continuous deployment (CI/CD) pipelines might generate alerts due to frequent changes and updates, which can be mistaken for suspicious activity.
-- Misconfigured security tools or overly sensitive alert thresholds can lead to false positives by flagging normal container orchestration activities as threats.
-- To manage these false positives, users can create exceptions for known non-threatening behaviors by adjusting alert thresholds or excluding specific event types that are consistently identified as benign.
-- Regularly review and update the list of exceptions to ensure that new legitimate activities are not mistakenly flagged as threats, while maintaining vigilance against potential new attack vectors.
-
-### Response and remediation
-
-- Immediately isolate the affected container or node to prevent further unauthorized access or execution of malicious code.
-- Conduct a thorough investigation of the alert by reviewing logs and events associated with the container workload to identify the source and nature of the threat.
-- Remediate identified vulnerabilities or misconfigurations in the container orchestration environment to prevent similar incidents in the future.
-- Escalate the incident to the security operations team if the threat is determined to be part of a larger attack or if it involves sensitive data.
-- Implement enhanced logging policies to capture detailed information about container activities and network communications for future investigations.
-- Integrate additional security tools and services, such as intrusion detection systems or threat intelligence platforms, to improve threat detection capabilities.
-- Restore the affected container or node to its operational state by redeploying from a known good image and verifying the integrity of the application and data.
-- Apply security patches and updates to the container orchestration platform and underlying infrastructure to address known vulnerabilities.
-- Conduct a post-incident review to analyze the response process and identify areas for improvement in detection and response strategies.
-- Implement hardening measures, such as network segmentation and least privilege access controls, to reduce the attack surface of the containerized environment."""
 
diff --git a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
index ec85708e77b..da057f623e1 100644
--- a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/28"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -39,48 +39,6 @@ process where event.module == "cloud_defend" and
 (process.name : ("grep", "egrep", "fgrep", "find", "locate", "mlocate") or process.args : ("grep", "egrep", "fgrep", "find", "locate", "mlocate")) and 
 process.args : ("*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", "*access_key*", "*.aws/credentials*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Credentials Searched For Inside A Container
-
-Containers often house applications that interact with AWS services, necessitating the storage of AWS credentials. Adversaries may exploit this by using search utilities to locate these credentials, potentially leading to unauthorized access. The detection rule identifies suspicious use of search tools within containers, focusing on attempts to locate AWS credential files, thus helping to thwart credential theft and subsequent attacks.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific container and process that triggered the rule, focusing on the `process.name` and `process.args` fields to understand which search utility was used and what specific AWS credential patterns were targeted.
-- Examine the `event.module` and `event.type` fields to confirm the context of the event, ensuring it aligns with the expected behavior of a container environment.
-- Check the container's metadata and logs to gather information about the container's purpose, owner, and any recent changes or deployments that might explain the search activity.
-- Investigate the user or service account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Use Osquery to list all running processes within the container to identify any other potentially malicious or unexpected processes. Example query: `SELECT pid, name, cmdline FROM processes WHERE name IN ('grep', 'find', 'locate');`
-- Analyze the container's file system to check for the presence of AWS credential files and verify their integrity and access permissions.
-- Review network logs to identify any outbound connections from the container that might indicate data exfiltration or communication with unauthorized external services.
-- Correlate the event with other security alerts or logs from the same timeframe to identify any patterns or related suspicious activities within the container or across the environment.
-- Investigate the history of the container image to ensure it has not been tampered with or contains embedded malicious scripts or tools.
-- Consult with the development or operations team responsible for the container to verify if the search activity was part of legitimate troubleshooting or maintenance tasks.
-
-### False positive analysis
-
-- Developers or system administrators may legitimately use search utilities like grep or find to locate AWS credentials for debugging or configuration purposes within a container. These actions, while benign, can trigger the detection rule.
-- Automated scripts or configuration management tools that verify the presence of AWS credentials as part of routine checks may also be flagged as suspicious activity.
-- To manage these false positives, users can create exceptions for specific containers or processes known to perform legitimate searches for AWS credentials. This can be done by whitelisting certain process names or arguments that are part of routine operations.
-- Users should regularly review and update their exception lists to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any unauthorized access to AWS resources.
-- Review container logs and AWS CloudTrail logs to trace any suspicious activities or access patterns related to the compromised credentials.
-- Revoke and rotate the compromised AWS credentials to prevent further unauthorized access.
-- Escalate the incident to the security operations team and relevant stakeholders, providing them with detailed findings and potential impacts.
-- Implement enhanced logging and monitoring for container environments, ensuring that all access to sensitive files and credentials is logged and reviewed regularly.
-- Integrate security tools that provide real-time alerts for suspicious activities within containers, such as unauthorized searches for credentials.
-- Restore the container to its operational state by redeploying it from a known good image, ensuring that all security patches and configurations are up to date.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
-- Apply hardening measures to container environments, such as using environment variables for credentials, implementing least privilege access, and regularly scanning for vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
index 7b7524bb177..ad37dcc18f5 100644
--- a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ and process.args: (
 "/etc/shadow",
 "/etc/gshadow")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Sensitive Files Compression Inside A Container
-
-Containers encapsulate applications and their dependencies, often containing sensitive files like credentials and configurations. Adversaries exploit compression utilities within containers to exfiltrate these files, bypassing security controls. The detection rule identifies suspicious compression activities by monitoring process executions and arguments for known utilities and sensitive file paths, alerting analysts to potential credential access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific container ID (`container.id`) where the suspicious activity was detected.
-- Examine the `process.name` and `process.args` fields to determine which compression utility was used and what specific files were targeted.
-- Check the `event.type` field to confirm the process start event and gather additional context about the timing and frequency of the activity.
-- Use Osquery to list all running processes within the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE container_id = '<container.id>');`
-- Investigate the container's history and logs to identify any recent changes or deployments that might have introduced vulnerabilities.
-- Analyze the container's network activity to detect any unusual outbound connections that could indicate data exfiltration.
-- Review the container's file system for any newly created or modified files that could be related to the compression activity.
-- Check for any other alerts or anomalies associated with the same container or host to identify potential patterns or related incidents.
-- Verify the integrity and permissions of the sensitive files listed in the `process.args` to ensure they have not been altered or accessed inappropriately.
-- Consult with the development or operations team to understand the expected behavior of the container and confirm whether the detected activity aligns with legitimate use cases.
-
-### False positive analysis
-
-- Routine backup processes: Automated scripts or scheduled tasks that compress sensitive files for backup purposes may trigger alerts. Users can handle these by identifying and excluding specific backup processes or scripts from the rule.
-- Development and testing activities: Developers or system administrators might compress sensitive files during testing or development within containers. To manage this, users can create exceptions for known development environments or user accounts.
-- Configuration management tools: Tools like Ansible, Puppet, or Chef might compress configuration files as part of their operations. Users should identify these tools and exclude their activities from the rule to prevent false positives.
-- Container orchestration tasks: Orchestration platforms like Kubernetes might perform legitimate compression tasks for configuration management. Users can exclude specific container IDs or orchestration-related processes to reduce false positives.
-- Security audits and compliance checks: Security teams might intentionally compress sensitive files for audit purposes. Users should coordinate with security teams to whitelist these activities and avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further data exfiltration and unauthorized access.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on logs and process execution details related to the detected compression activity.
-- Review and analyze the container's file system to identify any additional unauthorized changes or access to sensitive files.
-- Remove any unauthorized compression utilities or scripts found within the container to prevent further exploitation.
-- Rotate and update all credentials and keys that may have been exposed, including SSH keys, AWS credentials, and Docker configurations.
-- Escalate the incident to the security operations team for further analysis and to determine if the threat actor has accessed other parts of the network.
-- Implement enhanced logging and monitoring within the container environment to detect similar activities in the future, focusing on process execution and file access patterns.
-- Integrate security tools with container orchestration platforms to automate the detection and response to suspicious activities.
-- Restore the container from a known good backup to ensure the system is free from any malicious modifications.
-- Apply hardening measures such as restricting access to sensitive files, using least privilege principles, and regularly updating container images to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
index e87cec7ada7..dc8fd0b0b06 100644
--- a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -46,49 +46,6 @@ or
     and process.args : ("*id_rsa*", "*id_dsa*")
 ))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Sensitive Keys Or Passwords Searched For Inside A Container
-
-Containers encapsulate applications, isolating them from the host system, but they can still be vulnerable to attacks. Adversaries may exploit search utilities like grep and find to locate sensitive keys or passwords within a container, potentially leading to unauthorized access or container escape. The detection rule identifies suspicious use of these utilities by monitoring process activities and arguments, flagging attempts to search for private keys or password patterns, thus helping to prevent credential theft and maintain container security.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific container ID (`container.id`) where the suspicious activity was detected. This will help in focusing the investigation on the affected container.
-- Examine the process name (`process.name`) and arguments (`process.args`) to determine which utility (e.g., grep, find) was used and what specific patterns or files were being searched for. This can provide insight into the intent of the search.
-- Check the event type (`event.type`) to confirm that the process was indeed started, which indicates active execution of the search command.
-- Investigate the user context under which the process was executed to determine if it was initiated by a legitimate user or a potential adversary. This can be done by reviewing user-related logs or metadata.
-- Use Osquery to gather more information about the container environment. For example, run the following query to list all running processes within the container: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_events WHERE container_id = '<container.id>');`
-- Analyze the command history within the container, if available, to identify any previous commands that might indicate reconnaissance or preparatory actions leading up to the alert.
-- Review network activity logs associated with the container to identify any unusual outbound connections that might suggest data exfiltration attempts.
-- Check for any recent changes to the container's filesystem, especially in directories where sensitive keys or passwords are typically stored, to identify potential tampering or unauthorized access.
-- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns that could indicate a broader attack.
-- Consult threat intelligence sources to determine if there are any known campaigns or adversaries that use similar tactics, techniques, and procedures (TTPs) as those detected in the alert.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use grep or find to search for configuration files or logs that contain keywords like "pass" or "user" as part of regular maintenance or troubleshooting, which can trigger false positives.
-- Automated scripts: Some automated scripts or monitoring tools might use these utilities to check for the presence of certain files or strings as part of their normal operation, leading to benign alerts.
-- Development and testing: Developers working within containers might search for test keys or placeholder passwords during development, which are not indicative of malicious activity.
-- Excluding known safe processes: Users can handle these false positives by creating exceptions for specific processes or scripts that are known to perform these searches as part of their legitimate function, ensuring that only unexpected or unauthorized searches are flagged.
-- Contextual analysis: Reviewing the context in which the search utilities are used, such as the user account executing the command or the time of execution, can help differentiate between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential container breakout.
-- Conduct a thorough investigation to identify the source of the suspicious activity, including reviewing logs and process histories within the container.
-- Verify if any sensitive keys or passwords have been accessed or exfiltrated, and rotate any compromised credentials promptly.
-- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other containers or the host system.
-- Implement enhanced logging within the container environment to capture detailed process activities and access patterns for future investigations.
-- Integrate security monitoring tools with centralized logging solutions to ensure real-time alerting and correlation of suspicious activities.
-- Review and update container security policies to enforce least privilege access and restrict the use of search utilities to trusted users only.
-- Apply security patches and updates to the container image and underlying host system to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and develop a plan to address these weaknesses.
-- Educate development and operations teams on secure coding practices and the importance of safeguarding sensitive information within containers."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
index 022d5792c85..14581165c8e 100644
--- a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/06"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -34,49 +34,6 @@ type = "eql"
 query = '''
 file where event.module== "cloud_defend" and event.type != "deletion" and file.path== "/etc/ld.so.preload"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Dynamic Linker Preload Shared Object Inside A Container
-
-The dynamic linker in Linux loads necessary libraries for programs at runtime, with the `ld.so.preload` file specifying libraries to load first. Adversaries exploit this by redirecting it to malicious libraries, gaining unauthorized access and evading detection. The detection rule identifies suspicious modifications to this file within containers, signaling potential hijacking attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.module is "cloud_defend" and the event.type is not "deletion" to ensure the alert is relevant to the modification of the ld.so.preload file.
-- Verify the file path in the alert to confirm it is "/etc/ld.so.preload" to ensure the correct file is being investigated.
-- Check the timestamp of the modification event to determine when the suspicious activity occurred.
-- Identify the container ID or name where the modification took place to focus the investigation on the specific container environment.
-- Investigate the user or process that initiated the modification by examining the user.id and process.name fields in the alert data.
-- Use Osquery to list all processes running in the container at the time of the modification with a query like: `SELECT pid, name, path FROM processes WHERE container_id = '<container_id>';`
-- Examine the contents of the modified /etc/ld.so.preload file to identify any suspicious or unauthorized libraries being loaded.
-- Cross-reference the libraries listed in the modified ld.so.preload file with known malicious libraries or hashes to assess potential threats.
-- Review recent logs and events from the container for any other suspicious activities or anomalies around the time of the modification.
-- Investigate any network connections or data transfers initiated by the container around the time of the modification to identify potential data exfiltration or command and control activities.
-
-### False positive analysis
-
-- Routine updates or legitimate software installations within a container might modify the `ld.so.preload` file as part of their normal operation, leading to false positives. Users should verify if the modification aligns with known update or installation activities.
-- Some containerized applications may intentionally use the `ld.so.preload` mechanism for performance optimization or compatibility reasons. Users can create exceptions for these specific applications by identifying their typical behavior patterns and excluding them from the rule.
-- Automated configuration management tools or scripts that manage library paths might inadvertently trigger this rule. Users should review these tools' activities and whitelist them if they are confirmed to be non-malicious.
-- In development environments, developers might modify the `ld.so.preload` file for testing purposes. Users can exclude these environments from the rule or set up alerts to be less sensitive during known development periods.
-- To manage false positives, users can implement a monitoring period to establish a baseline of normal behavior, then adjust the rule to exclude these patterns while maintaining vigilance for truly suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or execution of malicious code.
-- Conduct a thorough investigation to identify any malicious libraries specified in the /etc/ld.so.preload file and assess the extent of the compromise.
-- Remove any unauthorized or malicious entries from the /etc/ld.so.preload file and replace them with legitimate libraries if necessary.
-- Review container logs and system logs to trace the source of the modification and identify any other potentially compromised containers or systems.
-- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a broader campaign.
-- Restore the container from a known good backup or image to ensure the system is free from any malicious modifications.
-- Implement stricter access controls and monitoring on critical files like /etc/ld.so.preload to prevent unauthorized modifications in the future.
-- Enhance logging policies to capture detailed events related to file modifications and access within containers, integrating with SIEM solutions for real-time alerting.
-- Conduct a security review of container configurations and apply hardening measures, such as using read-only file systems and minimizing privileges.
-- Educate and train staff on recognizing and responding to similar threats, leveraging MITRE ATT&CK framework details to understand adversary techniques and tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
index 725db83c43a..bb9fab55b3f 100644
--- a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -48,49 +48,6 @@ process where container.id: "*" and event.type== "start" and
 (process.args: ("nc", "ncat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab"))
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Network Tool Launched Inside A Container
-
-Containers are lightweight, portable environments that encapsulate applications and their dependencies. Adversaries exploit network tools within containers for reconnaissance or data exfiltration. The detection rule identifies the initiation of known network utilities, either as primary processes or subprocess arguments, signaling potential misuse for malicious network activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific network utility that triggered the rule, using the `process.name` and `process.args` fields to understand which tool was executed.
-- Check the `container.id` field to determine which container the suspicious process was running in, and gather additional context about the container's purpose and the application it hosts.
-- Investigate the `event.type` field to confirm the process start event and ensure that the alert corresponds to a new process initiation.
-- Use Osquery to list all running processes within the container to identify any other potentially suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE container_id = '<container.id>');`
-- Examine the container's creation and start times to determine if the suspicious activity aligns with any recent changes or deployments.
-- Review the container's network connections using Osquery to identify any unusual or unauthorized external communications. Example query: `SELECT * FROM process_open_sockets WHERE container_id = '<container.id>';`
-- Analyze the container's logs for any anomalies or errors around the time the suspicious process was executed, which might provide additional context or indicators of compromise.
-- Check for any recent changes to the container's configuration or image that could have introduced the network tool, such as updates or new deployments.
-- Investigate the user context under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential privilege misuse.
-- Correlate the alert with other security events or alerts in the environment to identify if this activity is part of a broader attack pattern or campaign.
-
-### False positive analysis
-
-- Legitimate administrative tasks: Network utilities like `nmap` or `tcpdump` may be used by system administrators for legitimate network diagnostics or monitoring within containers. Users can handle these by creating exceptions for specific user accounts or container IDs known to perform regular maintenance.
-- Automated testing environments: Continuous integration/continuous deployment (CI/CD) pipelines might use tools like `nc` or `telnet` for testing network connectivity or service availability. Users should consider excluding these processes when they originate from known testing containers or environments.
-- Development and debugging: Developers might use network tools such as `dig` or `nslookup` for debugging DNS issues within development containers. To manage these, users can exclude processes initiated by specific development containers or during known development timeframes.
-- Security tools: Security teams might deploy tools like `masscan` or `zmap` for vulnerability assessments or penetration testing. Users can exclude these activities by whitelisting processes executed by security team accounts or during scheduled security assessments.
-- Monitoring solutions: Some monitoring solutions might use utilities like `tshark` or `ngrep` to capture and analyze network traffic. Users should identify and exclude these processes when they are part of recognized monitoring solutions or services.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further network activity and potential lateral movement within the environment.
-- Conduct a thorough investigation of the container's logs and network traffic to identify any unauthorized access or data exfiltration attempts.
-- Review the process tree and command-line arguments to understand the context in which the suspicious network tool was executed.
-- If malicious activity is confirmed, remove the compromised container and redeploy a clean version from a trusted image.
-- Escalate the incident to the security operations team for further analysis and to determine if the threat extends beyond the container.
-- Implement enhanced logging policies to capture detailed process execution and network activity within containers for future investigations.
-- Integrate container security solutions that provide real-time monitoring and alerting for suspicious activities.
-- Apply security patches and updates to the container images and underlying host systems to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate development and operations teams on secure container practices, emphasizing the importance of using minimal and verified images."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
index bc8f4306140..24a7ee25a08 100644
--- a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -42,49 +42,6 @@ query = '''
 process where container.id: "*" and event.type== "start" 
   and process.name: ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "runc", "systemd", "crictl")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Container Management Utility Run Inside A Container
-
-Container management utilities like Docker and Kubernetes are essential for orchestrating and managing containerized applications. They facilitate deployment, scaling, and operations of application containers. However, adversaries can exploit these utilities to execute unauthorized commands or deploy malicious containers. The detection rule identifies suspicious activity by monitoring for the execution of key container management binaries within a container, which may indicate a security breach or misconfiguration.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific container ID (`container.id`) and process name (`process.name`) that triggered the alert.
-- Verify the legitimacy of the container by checking its origin, such as the image source and the deployment method, to ensure it aligns with expected configurations.
-- Use Osquery to gather more information about the container environment. For example, run the query: `SELECT * FROM docker_containers WHERE id = '<container_id>';` to retrieve details about the container.
-- Investigate the command line arguments and environment variables of the suspicious process to understand its intended actions and context.
-- Check the container's creation and start times to determine if the timing aligns with expected operational activities or if it coincides with any known suspicious events.
-- Examine the user and permissions under which the container management utility was executed to assess if there are any privilege escalation concerns.
-- Review the container's network activity to identify any unusual connections or data transfers that could indicate malicious behavior.
-- Analyze logs from the host system and container runtime to identify any anomalies or patterns that could suggest unauthorized access or actions.
-- Cross-reference the container's activity with other security alerts or incidents to determine if it is part of a broader attack or compromise.
-- Consult with relevant teams or stakeholders to verify if the execution of the container management utility was part of a legitimate operation or if further investigation is warranted.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may run container management utilities inside containers for troubleshooting or maintenance purposes. To handle these, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
-- Automated scripts and CI/CD pipelines: Some automated processes might execute container management commands within containers as part of their normal operation. Users can exclude these by identifying and whitelisting specific scripts or pipeline jobs that are known to perform these actions.
-- Development and testing environments: In development or testing environments, developers might frequently run container management commands inside containers for testing purposes. Users can manage these false positives by excluding specific environments or namespaces where such activities are common.
-- Monitoring and security tools: Certain monitoring or security tools might execute container management commands to gather information or enforce policies. Users should identify these tools and exclude their activities from triggering alerts.
-- Containerized management utilities: In some cases, container management utilities themselves might be containerized for operational reasons. Users can handle these by excluding specific container images or labels associated with these utilities.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or execution of malicious commands.
-- Investigate the container's logs and process history to identify the source and scope of the unauthorized execution.
-- Verify the integrity of the container image and check for any unauthorized modifications or additions.
-- Review access logs and permissions to determine if there was unauthorized access or privilege escalation.
-- Escalate the incident to the security operations team if evidence of compromise is found, following the organization's incident response plan.
-- Implement enhanced logging and monitoring for container management utilities to detect future unauthorized executions.
-- Integrate security tools with container orchestration platforms to automate detection and response to suspicious activities.
-- Restore the container from a known good backup or rebuild it using a verified clean image.
-- Apply security patches and updates to the container management utilities and underlying infrastructure.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
index 75c60ee703b..64fb497ec44 100644
--- a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -38,48 +38,6 @@ file where container.id: "*" and event.type in ("change", "creation") and
 (process.name : "chmod" or process.args : "chmod") and 
 process.args : ("*x*", "777", "755", "754", "700") and not process.args: "-x"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File Made Executable via Chmod Inside A Container
-
-Containers isolate applications, ensuring consistent environments. However, adversaries may exploit this by using `chmod` to make files executable, potentially running unauthorized code. The detection rule identifies such actions by monitoring for `chmod` usage that alters file permissions to executable states, flagging suspicious changes that could indicate malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific container ID (`container.id`) where the `chmod` command was executed. This will help in narrowing down the scope of the investigation to the affected container.
-- Examine the `process.name` and `process.args` fields to confirm that the `chmod` command was indeed used and to understand the exact permissions that were set. Look for patterns such as `777`, `755`, `754`, or `700` that indicate executable permissions.
-- Check the `event.type` field to determine whether the file was newly created or if its permissions were changed. This can provide context on whether the file is new or if an existing file was modified.
-- Investigate the parent process of the `chmod` command to understand the context in which it was executed. This can be done by examining the process tree to see if there are any suspicious parent processes.
-- Use Osquery to gather more information about the file that was made executable. For example, run the following Osquery query to list details about the file: `SELECT * FROM file WHERE path = '/path/to/suspicious/file';` Replace `/path/to/suspicious/file` with the actual file path.
-- Check the container's logs for any other suspicious activities around the time the `chmod` command was executed. Look for unusual commands or access patterns that might indicate malicious behavior.
-- Investigate the user account associated with the `chmod` command execution. Determine if the user has a legitimate reason to modify file permissions within the container.
-- Review network activity logs for the container to identify any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
-- Analyze the file that was made executable for any signs of malicious code or scripts. This can involve using static analysis tools or sandboxing the file in a controlled environment.
-- Correlate this event with other security alerts or logs from the same container or user to identify any patterns or repeated attempts to execute unauthorized code.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators or automated scripts may use `chmod` to modify file permissions as part of regular maintenance or deployment processes. These actions, while legitimate, can trigger the rule. To manage this, users can create exceptions for known scripts or administrative accounts that frequently perform these tasks.
-- Software installations and updates: During the installation or update of software within a container, `chmod` may be used to set executable permissions on necessary files. Users can handle these false positives by excluding specific installation or update processes from the rule.
-- Development and testing activities: Developers working within containers might use `chmod` to test scripts or applications, leading to false positives. To address this, users can exclude specific development environments or user accounts from the rule.
-- Container orchestration tools: Tools like Kubernetes or Docker Compose might use `chmod` as part of their operations to ensure proper file permissions. Users can manage these false positives by identifying and excluding the specific processes or tools involved in these operations.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized execution and potential lateral movement within the environment.
-- Conduct a thorough investigation to identify the source and scope of the unauthorized `chmod` command, reviewing logs and process trees for suspicious activity.
-- Verify the integrity of the files that were made executable and check for any unauthorized or malicious code that may have been introduced.
-- Revert any unauthorized changes to file permissions and remove any malicious files or processes identified during the investigation.
-- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if the attack vector is unclear.
-- Implement enhanced logging policies to capture detailed process execution and file permission changes within containers for future investigations.
-- Integrate container security tools that provide real-time monitoring and alerting for suspicious activities, such as unauthorized permission changes.
-- Restore the container to its operational state by redeploying from a known good image and ensuring all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply hardening measures such as restricting the use of `chmod` within containers, implementing least privilege access controls, and using container runtime security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
index 43cbae17fc8..16de26f880e 100644
--- a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,48 +58,6 @@ process.entry_leader.same_as_process== true and
 /* interactive process */
 process.interactive == true
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Interactive Exec Command Launched Against A Running Container
-
-Containers often use the 'exec' command to run processes within a running container, providing a shell for real-time interaction. Adversaries exploit this to gain unauthorized access, potentially leading to further compromise or escape from the container. The detection rule identifies such threats by monitoring for interactive 'exec' events, focusing on initial processes in containers that indicate potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'exec' command in the container, focusing on the `process.entry_leader.entry_meta.type` field to ensure it is a container process.
-- Verify the `process.interactive` field to confirm that the process was indeed interactive, indicating a real-time shell session was established.
-- Check the `process.entry_leader.same_as_process` field to ensure the process is the initial one run in the container, which could indicate unauthorized access.
-- Investigate the user account associated with the `exec` command to determine if it is a known and authorized user.
-- Examine the command history within the container to identify any suspicious or unauthorized commands executed during the session.
-- Use Osquery to gather additional context about the container environment. For example, run the following query to list all processes running in the container: `SELECT pid, name, path FROM processes WHERE container_id = '<container_id>';`.
-- Analyze network activity from the container during the time of the alert to identify any unusual outbound connections or data exfiltration attempts.
-- Review logs from the container orchestration platform (e.g., Kubernetes) to identify any recent changes or deployments that might explain the interactive session.
-- Cross-reference the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
-- Consult with the application or development team to verify if the interactive session was part of a legitimate maintenance or troubleshooting activity.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use the 'exec' command for legitimate purposes such as debugging, monitoring, or performing maintenance tasks within containers. These activities can trigger the rule but are not malicious. Users can handle these by creating exceptions for known administrative accounts or specific maintenance windows.
-- Automated scripts and tools: Some automated deployment or monitoring tools may use the 'exec' command to perform health checks or updates within containers. These actions can be mistaken for threats. To manage this, users can whitelist specific scripts or tools that are known to perform these actions regularly.
-- Development and testing activities: Developers might use the 'exec' command during the development or testing phases to interact with containers. These actions are typically benign. Users can exclude these activities by setting exceptions for development environments or specific user roles associated with development tasks.
-- Container orchestration platforms: Certain container orchestration platforms might use the 'exec' command as part of their normal operations to manage container lifecycles. Users can address this by identifying and excluding specific processes or commands associated with these platforms.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the environment.
-- Investigate the source of the 'exec' command to determine if it was initiated by a legitimate user or an adversary, checking for any anomalies in user behavior or access patterns.
-- Review container logs and audit trails to identify any suspicious activities or commands executed during the interactive session.
-- If unauthorized access is confirmed, revoke any compromised credentials and review access controls to ensure least privilege principles are enforced.
-- Escalate the incident to the security operations team for further analysis and to determine if the breach extends beyond the container.
-- Implement enhanced logging and monitoring for container environments, focusing on 'exec' commands and other high-risk activities.
-- Integrate security tools with SIEM systems to improve real-time detection and response capabilities for container-related threats.
-- Restore the container to its last known good state from a secure backup, ensuring that any malicious changes are removed.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Apply hardening measures such as disabling unnecessary interactive access, enforcing network segmentation, and using container security solutions to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
index 2ad6423c76b..55c5ccec6c3 100644
--- a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -47,48 +47,6 @@ event.action in ("fork", "exec") and event.action != "end"
 process.args: "*/*sh"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Interactive Shell Spawned From Inside A Container
-
-Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries may exploit interactive shells within containers to execute unauthorized commands, potentially leading to container breakout and host compromise. The detection rule identifies such threats by monitoring for shell processes initiated with interactive flags, indicating potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of an interactive shell spawned inside a container by checking the `process.executable` and `process.args` fields for shell indicators like `*/*sh` and flags `-i` or `-it`.
-- Verify the `container.id` to identify the specific container involved and gather context about its purpose and the application it is running.
-- Check the `event.type` and `event.action` fields to ensure the process is indeed in a "start" state and initiated by "fork" or "exec" actions, confirming it is an ongoing process.
-- Investigate the `process.entry_leader.same_as_process` field to determine if the shell process is a new entry point, which could indicate an unauthorized access attempt.
-- Use Osquery to list all running processes within the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE container_id = '<container.id>' AND name LIKE '%sh%';`
-- Examine the container's logs for any unusual activities or commands executed around the time the shell was spawned.
-- Check the user context under which the shell was spawned to determine if it aligns with expected user behavior or if it indicates a potential compromise.
-- Investigate network connections from the container using Osquery to identify any suspicious outbound connections. Example query: `SELECT * FROM socket_events WHERE container_id = '<container.id>';`
-- Review the container's image and configuration to ensure it has not been tampered with or altered to allow unauthorized shell access.
-- Correlate the findings with other security alerts or logs from the host system to identify any patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Developers or system administrators may intentionally spawn interactive shells within containers for debugging or maintenance purposes, which can trigger the rule. To manage this, users can create exceptions for specific user accounts or container IDs known to perform these actions regularly.
-- Automated scripts or orchestration tools might initiate interactive shells as part of their normal operation, leading to false positives. Users can handle these by identifying and excluding specific process names or arguments associated with these tools.
-- Some containerized applications might inherently require interactive shell access for legitimate functionality, such as certain development environments. Users should document these cases and configure the rule to exclude these specific applications or container images.
-- Continuous integration/continuous deployment (CI/CD) pipelines may execute interactive shells during build or deployment processes. Users can mitigate false positives by setting exceptions for known pipeline processes or by scheduling rule suppression during expected pipeline activity times.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential breakout to the host system.
-- Investigate the container's logs and process history to identify the source and nature of the unauthorized shell access.
-- Terminate any suspicious processes running within the container that are not part of the expected application workflow.
-- Review and update access controls and permissions for the container to ensure only authorized users and processes can initiate interactive shells.
-- Escalate the incident to the security operations team if evidence of a container breakout or host compromise is found.
-- Implement enhanced logging policies to capture detailed process execution and network activity within containers for future investigations.
-- Integrate container security tools with SIEM systems to improve real-time monitoring and alerting capabilities.
-- Restore the container from a known good backup or image to ensure the system is free from any unauthorized modifications.
-- Conduct a post-incident review to identify gaps in security controls and update container hardening measures, such as disabling unnecessary interactive shell access.
-- Educate development and operations teams on secure container practices and the importance of monitoring for suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
index fd888ad8d71..c739bdcdcbf 100644
--- a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -52,48 +52,6 @@ process.args: ("nc","ncat","netcat","netcat.openbsd","netcat.traditional")
           or process.args:("-*l*", "--listen", "-*p*", "--source-port")
           )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Netcat Listener Established Inside A Container
-
-Netcat is a versatile networking tool often used for debugging and network exploration. Within container environments, it can be exploited by adversaries to establish unauthorized network connections, acting as a backdoor or facilitating data exfiltration. The detection rule identifies suspicious Netcat activity by monitoring process starts within containers, focusing on specific command-line arguments indicative of a listening service, which may signal malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of Netcat-related process names or arguments, such as "nc", "ncat", "netcat", "netcat.openbsd", or "netcat.traditional", in the process.name or process.args fields.
-- Examine the container ID (container.id) associated with the alert to identify the specific container where the Netcat listener was established.
-- Check the event.type and event.action fields to verify that the process start event corresponds to a "fork" or "exec" action, indicating a new process creation.
-- Investigate the command-line arguments (process.args) for any suspicious flags like "-l", "--listen", "-p", "--source-port", "-c", "--sh-exec", "-e", or "--exec" that suggest a listening service or command execution.
-- Use Osquery to gather additional context about the container environment by running a query such as: `SELECT * FROM processes WHERE name IN ('nc', 'ncat', 'netcat', 'netcat.openbsd', 'netcat.traditional') AND cmdline LIKE '%-l%' AND cmdline LIKE '%-p%';`
-- Analyze the parent process of the Netcat listener to determine how it was initiated and whether it was spawned by a legitimate or suspicious process.
-- Review the network connections associated with the container to identify any unusual or unauthorized connections that may indicate data exfiltration or a backdoor.
-- Check the container's image and configuration to ensure it aligns with expected baselines and does not include unauthorized modifications or additional tools.
-- Investigate the user context under which the Netcat process is running to determine if it aligns with expected user activity or if it indicates potential privilege escalation.
-- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns that could provide further context.
-
-### False positive analysis
-
-- Development and testing environments may frequently use Netcat for legitimate purposes such as debugging or network testing, leading to false positives. Users can handle these by creating exceptions for specific container IDs or process names known to be used in these environments.
-- Automated scripts or tools that utilize Netcat for routine network checks or data transfers might trigger the rule. To manage this, users can exclude specific command-line arguments or process arguments that are consistently associated with these benign activities.
-- Some containerized applications might use Netcat as part of their normal operation for inter-container communication. In such cases, users should identify and whitelist these applications by excluding their specific process names or container IDs from the detection rule.
-- Security tools or monitoring solutions that incorporate Netcat for legitimate network monitoring or penetration testing could also be flagged. Users should document and exclude these tools by adding exceptions for their known process arguments or container environments.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration.
-- Investigate the container's logs and network activity to identify the source and scope of the compromise.
-- Terminate the netcat process and any other unauthorized processes running within the container.
-- Conduct a thorough review of the container's configuration and deployed applications to identify vulnerabilities or misconfigurations that may have been exploited.
-- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other parts of the network.
-- Implement enhanced logging policies to capture detailed process and network activity within containers for future investigations.
-- Integrate threat intelligence feeds and security tools to improve detection capabilities and correlate alerts with known threat actors and tactics.
-- Restore the container from a known good backup or rebuild it using secure configurations and updated software versions.
-- Apply hardening measures such as disabling unnecessary services, enforcing least privilege access, and using network segmentation to limit exposure.
-- Review and update security policies and incident response plans to incorporate lessons learned from the incident and improve readiness for future threats."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
index de2a7d81f22..d4cdae3dcc6 100644
--- a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -52,48 +52,6 @@ process.entry_leader.entry_meta.type: "sshd"  and
 /* interactive process*/
 process.interactive== true
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SSH Connection Established Inside A Running Container
-
-SSH (Secure Shell) is a protocol used to securely access and manage systems remotely. Within containerized environments, running an SSH daemon is generally discouraged due to security risks. Adversaries may exploit SSH to gain unauthorized access or maintain persistence by leveraging stolen credentials. The detection rule identifies SSH sessions initiated within containers by monitoring for SSH daemon processes that start new interactive sessions, indicating potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `container.id` and ensure the event type is "start" to verify the context of the SSH connection.
-- Check the `process.entry_leader.entry_meta.type` field to confirm that the process is indeed "sshd", indicating an SSH daemon is involved.
-- Investigate the `process.entry_leader.same_as_process` and `process.session_leader.same_as_process` fields to determine if the SSH session is the initial process or a new session within the container.
-- Verify the `process.interactive` field to ensure the process is interactive, which could indicate an active user session.
-- Use Osquery to list all running processes within the container to identify any suspicious or unexpected processes. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address IS NOT NULL);`
-- Examine the container's logs for any unusual activity or errors around the time the SSH connection was established.
-- Check for any recent changes to the container's configuration or image that might have introduced vulnerabilities or unauthorized access points.
-- Investigate the source IP address of the SSH connection to determine if it is from a known or trusted network.
-- Review user access logs and authentication attempts to identify any unauthorized or failed login attempts that could indicate credential theft.
-- Correlate the event with other security alerts or logs to identify any patterns or related activities that might suggest a broader attack campaign.
-
-### False positive analysis
-
-- **Development and Testing Environments**: In some development or testing scenarios, SSH might be intentionally used within containers for debugging or administrative purposes. Users can handle these by creating exceptions for specific containers or environments where SSH usage is expected and authorized.
-- **Automated Maintenance Tasks**: Certain automated scripts or maintenance tasks might use SSH to perform updates or configurations within containers. To manage these, users can whitelist specific processes or scripts known to perform legitimate maintenance activities.
-- **Containerized SSH Services**: Some organizations might run legitimate SSH services within containers as part of their infrastructure. In such cases, users should document and exclude these specific containers or services from triggering alerts, ensuring that only unauthorized SSH activities are flagged.
-- **Monitoring and Security Tools**: Security or monitoring tools that use SSH to gather data from containers might trigger false positives. Users should identify these tools and configure the detection rule to exclude their activities, ensuring that only unexpected SSH connections are detected.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
-- Investigate the source of the SSH connection by reviewing logs to identify the IP address and user credentials used for the connection.
-- Verify the integrity of the container by checking for any unauthorized changes or additional processes that may have been initiated.
-- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent further unauthorized access.
-- Escalate the incident to the security operations team for a thorough investigation and to determine if other containers or systems have been compromised.
-- Implement network segmentation to limit access to critical containers and reduce the attack surface.
-- Enhance logging policies to ensure comprehensive monitoring of SSH connections and container activities, including detailed audit logs.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the container to its operational state by redeploying it from a known good image and ensuring all security patches are applied.
-- Apply hardening measures such as disabling SSH daemon in containers, using non-root users, and implementing multi-factor authentication for remote access."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
index 22493e7eda9..5ed644ebed5 100644
--- a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -47,49 +47,6 @@ process where container.id: "*" and event.type== "start" and
 event.action in ("fork", "exec") and event.action != "end" and 
 process.name: ("sshd", "ssh", "autossh")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SSH Process Launched From Inside A Container
-
-SSH, a protocol for secure remote access, is crucial in managing systems but poses risks when used inside containers. Adversaries exploit SSH to move laterally or establish persistence. The detection rule identifies SSH processes initiated within containers, signaling potential misuse. It monitors process starts, focusing on SSH-related binaries, to alert on unauthorized or suspicious activity.
-
-### Possible investigation steps
-
-- Verify the container ID by examining the `container.id` field to identify which container initiated the SSH process.
-- Check the `process.name` field to determine whether the process is `ssh`, `sshd`, or `autossh`, and assess the potential risk based on the specific binary used.
-- Review the `event.type` and `event.action` fields to confirm the process start and ensure it aligns with the expected behavior of the container.
-- Investigate the parent process of the SSH process to understand how it was initiated and whether it was expected or authorized.
-- Use Osquery to gather more information about the container environment. For example, run the query: `SELECT * FROM processes WHERE name IN ('ssh', 'sshd', 'autossh') AND pid = <PID>;` to get details about the SSH process.
-- Examine the container's network connections to identify any unusual or unauthorized connections that may have been established using SSH.
-- Check the container's logs for any signs of unauthorized access or suspicious activity around the time the SSH process was started.
-- Investigate the user context under which the SSH process was initiated to determine if it was executed by a legitimate user or potentially compromised credentials.
-- Review the history of the container's image and configuration to ensure there are no vulnerabilities or misconfigurations that could have been exploited.
-- Correlate the event with other security alerts or logs to identify any patterns or related activities that could indicate a broader attack or compromise.
-
-### False positive analysis
-
-- **Development and Testing Environments**: In some development or testing environments, SSH might be used legitimately for debugging or administrative tasks within containers. Users can handle these by creating exceptions for specific container IDs or environments where SSH usage is expected and authorized.
-- **Automated Maintenance Tasks**: Automated scripts or maintenance tasks might use SSH to perform updates or backups within containers. To manage these, users can exclude processes initiated by known maintenance scripts or from specific source IPs associated with trusted automation tools.
-- **Containerized SSH Services**: Some applications might intentionally run SSH services within containers for specific use cases, such as providing secure access to containerized applications. Users should document and exclude these known services by specifying the container names or image IDs that are expected to run SSH processes.
-- **Monitoring and Security Tools**: Security or monitoring tools might use SSH to gather data or perform security checks within containers. Users can manage these false positives by identifying and excluding processes started by these tools, often identifiable by specific user accounts or process arguments.
-- **Legacy Systems**: In environments with legacy systems, SSH might be used as a workaround for certain functionalities. Users should assess the necessity of these practices and, if deemed non-threatening, exclude them by defining exceptions based on process arguments or container labels.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further lateral movement or potential breakout to the host system.
-- Investigate the source of the SSH process by reviewing container logs and identifying any unauthorized access or suspicious activity.
-- Verify the integrity of the container image and check for any unauthorized modifications or additional binaries.
-- Revoke any compromised SSH credentials and enforce the use of strong, unique passwords or SSH keys for access.
-- Escalate the incident to the security operations team if there is evidence of a container breakout or if multiple containers are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity within containers for future investigations.
-- Integrate with security information and event management (SIEM) systems to correlate container activity with other security events across the environment.
-- Restore the container from a known good backup or rebuild it using a verified secure image to ensure no persistence mechanisms remain.
-- Apply container hardening measures, such as disabling SSH access within containers and using network policies to restrict inter-container communication.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
index f0a5a4410a8..30220e18f92 100644
--- a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,48 +36,6 @@ query = '''
 file where container.id:"*" and
   event.type in ("change", "creation") and file.name: ("authorized_keys", "authorized_keys2", "sshd_config")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SSH Authorized Keys File Modified Inside a Container
-
-SSH authorized_keys files are crucial for managing access to systems via public key authentication, ensuring secure, password-less logins. In containerized environments, adversaries may exploit these files to gain unauthorized access or maintain persistence by adding their own keys. The detection rule identifies suspicious modifications to these files within containers, signaling potential compromise and warranting further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific container where the modification occurred, using the `container.id` field for context.
-- Verify the event type by checking the `event.type` field to confirm whether it was a "change" or "creation" event, which can help determine the nature of the modification.
-- Examine the `file.name` field to identify which file was modified: `authorized_keys`, `authorized_keys2`, or `sshd_config`, as this can indicate the method of potential unauthorized access.
-- Use Osquery to list all current SSH keys in the container by running: `SELECT * FROM authorized_keys WHERE path LIKE '/path/to/container/%';` to identify any unauthorized keys.
-- Check the container's creation and start time to determine if the modification aligns with expected operational activities or if it occurred at an unusual time.
-- Investigate the user context under which the modification was made by reviewing logs or using Osquery: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM file_events WHERE path LIKE '/path/to/container/%');` to identify the process responsible for the change.
-- Correlate the container's network activity around the time of the modification to identify any suspicious connections or data transfers.
-- Review the container's history and any associated images to determine if the modification could have originated from a compromised image or during the build process.
-- Check for any other alerts or anomalies related to the same container or host to identify potential patterns or broader compromise.
-- Consult with the team responsible for the container to verify if the modification was authorized or part of a legitimate update or maintenance activity.
-
-### False positive analysis
-
-- Routine updates or maintenance tasks: In some environments, automated processes or configuration management tools may update SSH authorized_keys or sshd_config files as part of regular maintenance. These changes, while legitimate, can trigger the detection rule. Users can handle these by creating exceptions for known maintenance windows or specific automation tools.
-- Developer or administrator actions: Developers or system administrators might modify these files within containers for legitimate reasons, such as adding keys for new team members or updating configurations. To manage these, users can maintain a list of authorized personnel and their expected activities, creating exceptions for their actions.
-- Container orchestration tools: Some container orchestration platforms might modify SSH configurations as part of their operations, especially in environments where SSH access is used for debugging or management. Users should identify these tools and processes, and exclude their activities from triggering alerts.
-- Testing and development environments: In non-production environments, frequent changes to SSH configurations might occur as part of testing or development processes. Users can reduce false positives by applying the rule more strictly in production environments and less so in development settings.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
-- Conduct a thorough investigation to identify any unauthorized keys added to the authorized_keys file and determine the source of the modification.
-- Review container logs and access records to trace any suspicious activities or unauthorized access attempts.
-- Remove any unauthorized keys from the authorized_keys file and verify the integrity of the sshd_config file to ensure no malicious configurations are present.
-- Rotate SSH keys for all legitimate users who had access to the compromised container to prevent further unauthorized access.
-- Escalate the incident to the security operations team for a comprehensive analysis and to determine if other containers or systems have been affected.
-- Implement enhanced logging and monitoring for SSH activities within containers to detect future unauthorized access attempts promptly.
-- Integrate security tools with SIEM solutions to automate the detection and alerting of suspicious modifications to SSH-related files.
-- Restore the container to its operational state by redeploying it from a known good image and ensuring all security patches are applied.
-- Apply hardening measures such as disabling SSH access to containers unless absolutely necessary and using network policies to restrict access to SSH services."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
index f73a6b4a5ff..84a94f11ed9 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -42,50 +42,6 @@ process where event.module == "cloud_defend" and
   process.args : "/dev/sd*" and not process.args == "-R" and
   container.security_context.privileged == true
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File System Debugger Launched Inside a Privileged Container
-
-DebugFS is a Linux utility that allows direct interaction with file systems, typically used for debugging purposes. When executed within a privileged container, it can access host-level files, posing a security risk. Adversaries may exploit this to escalate privileges or escape the container. The detection rule identifies such misuse by monitoring DebugFS processes initiated in privileged containers, focusing on specific arguments that indicate potential malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "debugfs" and verify the presence of the specific arguments "/dev/sd*" to ensure the alert is not a false positive.
-- Check the container's security context to confirm it is indeed privileged by examining the `container.security_context.privileged` field.
-- Investigate the origin of the container by identifying the image and container ID to understand its purpose and whether it should have privileged access.
-- Use Osquery to list all running processes within the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address != '');`
-- Examine the container's logs for any unusual activities or errors around the time the DebugFS process was started.
-- Review the user account and credentials used to launch the container to determine if they have been compromised or misused.
-- Investigate the host system for any signs of compromise or unauthorized access, focusing on the time frame when the DebugFS process was initiated.
-- Check for any recent changes to the container's configuration or deployment scripts that might have inadvertently allowed privileged access.
-- Correlate the event with other security alerts or logs from the same host or container to identify potential patterns or related incidents.
-- Consult with the development or operations team to verify if there was a legitimate need for using DebugFS within a privileged container and gather context on any recent changes or deployments.
-
-### False positive analysis
-
-- DebugFS may be legitimately used by system administrators for troubleshooting or maintenance tasks within a privileged container, especially in environments where direct disk access is necessary for diagnostics. 
-- Automated scripts or monitoring tools that perform regular checks on disk health or integrity might trigger this rule if they utilize DebugFS within a privileged container context.
-- Development or testing environments where privileged containers are used to simulate production-like conditions might see DebugFS usage as part of routine operations, leading to false positives.
-- To manage these false positives, users can create exceptions for known benign processes or scripts by specifying their unique identifiers or command patterns in the detection rule.
-- Implementing a whitelist of trusted users or processes that are allowed to execute DebugFS within privileged containers can help reduce unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational needs.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further access to host-level files and potential privilege escalation.
-- Conduct a thorough investigation to determine the extent of the compromise, focusing on logs and process activity related to DebugFS usage.
-- Review container deployment configurations to ensure that privileged containers are only used when absolutely necessary and with strict access controls.
-- Remove any unauthorized or suspicious processes and files identified during the investigation from the container and host system.
-- Apply security patches and updates to the container runtime and host operating system to mitigate known vulnerabilities.
-- Implement strict logging policies to capture detailed process execution and container activity, ensuring that logs are stored securely and monitored regularly.
-- Integrate security tools with SIEM systems to enhance real-time detection and alerting capabilities for suspicious container activities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Restore the container and host system to a known good state from backups, ensuring that the restored environment is free from any malicious modifications.
-- Harden container security by minimizing the use of privileged containers, employing least privilege principles, and using security features like AppArmor or SELinux for additional protection."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
index 22ef505e0cb..b8ce04a318a 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -40,49 +40,6 @@ query = '''
 process where event.module == "cloud_defend" and  event.type== "start" and 
 (process.name== "mount" or process.args== "mount") and container.security_context.privileged == true
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Mount Launched Inside a Privileged Container
-
-In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When used in privileged containers, which have extensive host capabilities, it can expose sensitive host files. Adversaries exploit this to escalate privileges or escape to the host. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `mount` command execution within a privileged container by checking the `process.name` and `process.args` fields.
-- Verify the `container.security_context.privileged` field to ensure the container was indeed running with privileged access.
-- Identify the container ID and image name associated with the alert to understand which application or service might be involved.
-- Check the `event.module` and `event.type` fields to confirm the event source and type, ensuring it aligns with the expected behavior of the detection rule.
-- Use Osquery to list all processes running inside the container to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = 'container_ip');`
-- Investigate the container's logs for any unusual or unauthorized access patterns around the time of the alert.
-- Examine the host system's logs for any signs of privilege escalation or attempts to access sensitive files from the container.
-- Review the container's configuration and deployment scripts to ensure no unintended privileged access was granted.
-- Check for any recent changes or deployments that might have introduced the privileged container or altered its behavior.
-- Collaborate with the development or DevOps team to understand the intended use of the `mount` command within the container and verify if it aligns with expected operations.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use the `mount` command within privileged containers for legitimate purposes such as attaching storage volumes or performing maintenance. These actions, while benign, can trigger the detection rule.
-- Backup operations: Automated backup processes might involve mounting file systems within privileged containers to access data, leading to false positives.
-- Monitoring and logging tools: Some security or monitoring tools may use the `mount` command to access file systems for scanning or logging purposes, which can be mistakenly flagged.
-- To manage these false positives, users can create exceptions for known benign processes by specifying trusted process names or arguments in the detection rule. This can be done by updating the query to exclude certain process names or arguments that are identified as non-threatening.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
-- Investigate the container's logs and process history to identify any unauthorized or suspicious activities, focusing on the use of the mount command.
-- Verify the container's security context and configuration to ensure it was not inadvertently deployed with privileged access.
-- Conduct a thorough review of the container's filesystem to identify any unauthorized changes or access to sensitive host files.
-- Escalate the incident to the security operations team if evidence of privilege escalation or host escape is found, providing detailed findings and context.
-- Implement enhanced logging policies to capture detailed process execution and container activity, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate security monitoring tools with SIEM systems to automate the detection of privileged container activities and generate alerts for suspicious behavior.
-- Restore the container to a known good state from a secure backup, ensuring any unauthorized changes are reverted.
-- Apply container hardening measures, such as using the principle of least privilege, to minimize the capabilities of containers and reduce the attack surface.
-- Review and update security policies and procedures to prevent similar incidents, incorporating lessons learned from the investigation and remediation process."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
index 335ea835d6e..e02c4778a14 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -41,48 +41,6 @@ query = '''
 file where event.module == "cloud_defend" and event.action == "open" and 
 event.type == "change" and file.name : "notify_on_release"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Container Escape via Modified notify_on_release File
-
-Containers use cgroups to manage resources, with the `notify_on_release` file triggering host-level commands when a cgroup is released. Adversaries exploit this by modifying the file from privileged containers to execute unauthorized commands on the host, leading to potential escapes. The detection rule monitors changes to `notify_on_release` files, flagging suspicious modifications indicative of such exploits.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.module is "cloud_defend" and the event.action is "open" with event.type as "change" for the file named "notify_on_release".
-- Identify the container from which the modification originated by examining the source IP, container ID, and associated metadata.
-- Check the user and process that initiated the change by reviewing the user ID and process ID associated with the event.
-- Investigate the history of the container to determine if it has been granted SYS_ADMIN capabilities, which are necessary for modifying cgroup settings.
-- Use Osquery to list all processes running within the container to identify any suspicious or unauthorized processes. Example query: `SELECT pid, name, path FROM processes WHERE cgroup LIKE '%<container_id>%';`
-- Examine the release_agent file associated with the cgroup to determine if it has been modified or contains suspicious commands.
-- Review recent logs and events from the host system to identify any execution of commands that could be linked to the release_agent.
-- Analyze network activity from the container to detect any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
-- Cross-reference the alert with other security events or alerts to identify potential patterns or coordinated activities.
-- Consult threat intelligence sources to determine if there are known exploits or attack patterns related to the modification of the notify_on_release file.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may modify the `notify_on_release` file during legitimate maintenance or configuration activities. To handle this, users can create exceptions for known administrative actions by whitelisting specific user accounts or processes that are authorized to perform these changes.
-- Automated container management tools: Some container orchestration or management tools might modify the `notify_on_release` file as part of their normal operations. Users should identify these tools and exclude their actions from triggering alerts by specifying the tool's process names or IDs in the exception list.
-- Testing and development environments: In environments where containers are frequently created and destroyed for testing purposes, modifications to the `notify_on_release` file might be common and benign. Users can reduce noise by setting up separate monitoring rules or thresholds for these environments, ensuring that only unexpected changes trigger alerts.
-- Custom scripts or applications: Organizations may have custom scripts or applications that interact with cgroups and modify the `notify_on_release` file. Users should document these scripts and create exceptions based on their unique identifiers or execution paths to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
-- Conduct a thorough investigation to identify any unauthorized changes made to the notify_on_release file and determine the extent of the compromise.
-- Review container logs and host system logs to trace the actions of the adversary and identify any additional indicators of compromise.
-- Revoke any unnecessary privileged access and capabilities from containers, especially SYS_ADMIN, to minimize the risk of exploitation.
-- Restore the affected container and host system from a known good backup to ensure the integrity of the environment.
-- Update and patch the container runtime and host operating system to address any known vulnerabilities that could be exploited for container escapes.
-- Implement enhanced logging and monitoring for cgroup modifications and other critical system files to detect similar activities in the future.
-- Integrate security tools with SIEM solutions to correlate alerts and improve threat detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Educate and train staff on container security best practices and the specific risks associated with cgroup modifications and container escapes."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
index fd3c2bda6a5..8c44e8b3c60 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -40,48 +40,6 @@ query = '''
 file where event.module == "cloud_defend" and event.action == "open" and 
 event.type == "change" and file.name : "release_agent"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Container Escape via Modified release_agent File
-
-In containerized environments, the release_agent file in CGroup directories can execute scripts upon process termination. Adversaries exploit this by modifying the file from privileged containers, potentially escalating privileges or escaping to the host. The detection rule monitors changes to the release_agent file, signaling possible malicious activity by identifying unauthorized modifications.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file involved is indeed the `release_agent` file and verify the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
-- Identify the container from which the modification originated by examining the source IP, container ID, and any associated user or process information.
-- Check the privileges of the container, specifically looking for SYS_ADMIN capabilities, to assess if it has the necessary permissions to modify the release_agent file.
-- Use Osquery to list all processes running in the container to identify any suspicious or unauthorized processes. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/proc/%/exe';`
-- Investigate the history of the release_agent file to determine when it was last modified and by which process or user.
-- Examine the contents of the modified release_agent file to understand what script or command is being executed upon process termination.
-- Correlate the modification event with any other suspicious activities or alerts in the same timeframe to identify potential lateral movement or privilege escalation attempts.
-- Check for any recent changes in the CGroup directory permissions or configurations that could have facilitated the modification.
-- Review system logs and audit logs for any anomalies or unauthorized access attempts around the time of the modification.
-- Investigate any network connections from the container to external IPs that could indicate data exfiltration or command and control communication.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may legitimately modify the release_agent file during maintenance or configuration changes. Users can handle these by creating exceptions for known administrative activities or specific time windows when such tasks are expected.
-- Automated scripts or tools: Some container management tools or scripts might modify the release_agent file as part of their normal operation. Users should identify these tools and whitelist their activities to prevent false alerts.
-- Testing environments: In development or testing environments, developers might intentionally modify the release_agent file to test container behaviors. Users can exclude these environments from monitoring or set up specific rules that differentiate between production and non-production environments.
-- Legitimate software updates: Certain software updates might involve changes to the release_agent file. Users should maintain an updated list of software that is allowed to perform such updates and configure exceptions accordingly.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
-- Investigate the container's logs and any associated network traffic to identify the source and scope of the compromise.
-- Verify the integrity of the release_agent file and any scripts it may execute, ensuring they have not been tampered with or replaced by malicious versions.
-- Check for any unauthorized changes to the container's configuration, particularly those related to CGroup settings and SYS_ADMIN capabilities.
-- Escalate the incident to the security operations team if the investigation reveals a potential breach or if the threat actor's identity and methods are unclear.
-- Restore the container from a known good backup if available, ensuring that any vulnerabilities exploited by the attacker are patched.
-- Implement enhanced logging and monitoring for CGroup directories and privileged container activities to detect similar threats in the future.
-- Review and update access controls and permissions for containers, ensuring that only necessary privileges are granted to minimize the risk of exploitation.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate relevant personnel on the risks associated with container escapes and the importance of maintaining strict security practices in containerized environments."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
index a80ab44b70a..fc951b330cb 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 75
@@ -52,51 +52,6 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual ISO Code
-
-Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to unexpected geo-locations. Adversaries may exploit command and control channels to exfiltrate data to these unusual regions. The detection rule leverages these models to flag deviations from normal traffic, indicating potential exfiltration activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific unusual ISO code and the associated geo-location flagged by the machine learning model.
-- Cross-reference the unusual ISO code with known business operations to determine if there is a legitimate reason for data transfer to this location.
-- Analyze historical network traffic logs to identify patterns or previous instances of data transfers to the flagged geo-location.
-- Examine the source IP addresses involved in the data transfer to determine if they belong to known or trusted entities within the organization.
-- Utilize Osquery to gather additional context on the systems involved in the data transfer. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<flagged IP address>';`
-- Investigate the destination IP addresses and domains to assess their reputation and check for any known associations with malicious activities.
-- Check for any recent changes or anomalies in the network configuration or firewall rules that could have facilitated the data transfer.
-- Review user activity logs to identify any unusual or unauthorized access patterns that coincide with the data transfer event.
-- Correlate the alert with other security events or alerts to identify potential patterns or coordinated activities indicative of a larger threat.
-- Consult threat intelligence sources to gather additional information on the flagged geo-location and any associated threat actors or campaigns.
-
-### False positive analysis
-
-- Legitimate business operations may involve data transfers to new or infrequent geo-locations, such as expanding into new markets or collaborating with international partners, which could trigger false positives.
-- Automated systems or third-party services that route data through different regions for optimization or redundancy purposes might be flagged as unusual traffic.
-- Employees working remotely or traveling may connect from unexpected locations, causing their data transfers to appear suspicious.
-- To manage these false positives, users can create exceptions for known and verified business operations that involve data transfers to specific regions.
-- Implementing a whitelist of trusted IP addresses or domains associated with legitimate services can help reduce unnecessary alerts.
-- Regularly updating the list of approved geo-locations based on business needs and employee travel patterns can minimize false positives.
-- Users should review flagged activities in the context of their organization's normal operations to determine if they are indeed non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
-- Analyze network logs and endpoint data to trace the source of the command and control channel used for exfiltration.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for awareness and further action.
-- Implement or enhance logging policies to ensure comprehensive monitoring of outbound traffic, focusing on unusual geo-locations.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of suspicious activities.
-- Restore affected systems from clean backups, ensuring that any compromised credentials or configurations are reset.
-- Apply security patches and updates to all systems to mitigate vulnerabilities that may have been exploited.
-- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
-- Educate employees on recognizing phishing attempts and other social engineering tactics that could lead to data exfiltration."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
index bbd50923e4b..350448b6a9b 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 75
@@ -52,49 +52,6 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual IP Address
-
-Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical geo-locations. Adversaries exploit command and control (C2) channels to exfiltrate data to these unusual IP addresses. The detection rule leverages this analysis to flag potential exfiltration activities, aligning with MITRE ATT&CK's exfiltration tactics and techniques.
-
-### Possible investigation steps
-
-- Review the alert details to identify the unusual IP address and geo-location involved in the potential exfiltration activity.
-- Cross-reference the unusual IP address with threat intelligence databases to determine if it is associated with known malicious activities or threat actors.
-- Analyze historical network traffic logs to identify any previous communications with the unusual IP address, noting the frequency and volume of data transferred.
-- Examine the specific machine or endpoint involved in the alert to gather information on recent activities, user logins, and running processes.
-- Use Osquery to investigate the endpoint further. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<unusual_ip_address>';`
-- Check for any recent changes or anomalies in the system configurations or installed software on the affected endpoint.
-- Investigate user activity logs to determine if any unauthorized access or unusual user behavior occurred around the time of the alert.
-- Correlate the alert with other security events or alerts to identify potential patterns or related incidents.
-- Review data transfer logs to assess the type and sensitivity of the data that may have been exfiltrated to the unusual IP address.
-- Consult with relevant stakeholders or departments to verify if the data transfer to the unusual IP address was authorized or part of legitimate business operations.
-
-### False positive analysis
-
-- Legitimate business operations may involve data transfers to geo-locations that are atypical but necessary, such as international offices or third-party service providers. These should be reviewed and, if verified as non-threatening, added to an exception list.
-- Automated system updates or cloud service interactions might trigger alerts if they involve IP addresses outside the usual geographic range. Users can manage these by identifying and excluding known update servers or cloud service IPs.
-- Remote work scenarios where employees connect from various global locations can result in false positives. Organizations should maintain an updated list of employee travel plans or remote work locations to adjust the detection parameters accordingly.
-- Partner or vendor integrations that require data exchange with external IPs might be flagged. Establishing a whitelist of trusted partner IP addresses can help mitigate these false positives.
-- Temporary projects or collaborations with international teams may necessitate data transfers to unusual IP addresses. Users should document these activities and adjust the detection rules to accommodate such temporary changes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
-- Analyze network logs and endpoint data to trace the source of the command and control channel and identify any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders, providing them with detailed findings and potential impacts.
-- Implement enhanced logging policies to capture detailed network traffic and endpoint activities for future investigations.
-- Integrate threat intelligence feeds and anomaly detection tools to improve the detection of unusual network patterns and potential C2 channels.
-- Restore the affected system by removing any malicious software, applying security patches, and verifying the integrity of critical files.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement network segmentation and access controls to limit the potential impact of future exfiltration attempts.
-- Educate employees on recognizing phishing attempts and other social engineering tactics that adversaries might use to establish C2 channels."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
index 2b3d71a7c5c..119651afe53 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 75
@@ -51,52 +51,6 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual Destination Port
-
-Machine learning models analyze network traffic to identify anomalies, such as data transfers to uncommon ports, which may suggest exfiltration via command and control channels. Adversaries exploit these channels to stealthily siphon data. The detection rule leverages these models to flag deviations from typical traffic patterns, aiding in the identification of potential exfiltration activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the unusual destination port and the source IP address involved in the potential exfiltration activity.
-- Analyze historical network traffic logs to determine if the identified destination port has been used previously and assess the frequency and volume of data transferred.
-- Cross-reference the source IP address with asset management databases to identify the device and user associated with the activity.
-- Examine the destination IP address to determine if it is associated with known malicious activity or if it belongs to an unfamiliar or suspicious domain.
-- Utilize threat intelligence feeds to check if the destination IP or domain is linked to any known command and control infrastructure.
-- Conduct a deeper inspection of the network traffic associated with the alert using packet capture tools to identify the nature of the data being transferred.
-- Use Osquery to gather additional context from the source machine. For example, run the following query to list active network connections and identify any unusual or persistent connections:
-  ```sql
-  SELECT * FROM process_open_sockets WHERE remote_port = <unusual_port>;
-  ```
-- Investigate any processes on the source machine that are associated with the unusual network activity to determine if they are legitimate or potentially malicious.
-- Check for any recent changes or anomalies in the system logs of the source machine that could indicate compromise or unauthorized access.
-- Collaborate with other security teams to correlate this alert with any other suspicious activities or alerts that may have been triggered around the same time frame.
-
-### False positive analysis
-
-- Routine administrative tasks or legitimate software updates may trigger alerts if they involve data transfers to uncommon ports, as these activities can mimic exfiltration patterns.
-- Internal testing or development environments might use non-standard ports for data transfer, leading to false positives if these activities are not accounted for in the baseline traffic patterns.
-- Certain legitimate applications or services may inherently use unusual ports for communication, which could be misinterpreted as exfiltration attempts.
-- To manage these false positives, users can create exceptions for known benign activities by updating the detection rule to exclude specific IP addresses, ports, or applications that are verified as non-threatening.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the effectiveness of the detection rule against genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
-- Analyze network logs and endpoint data to trace the source of the anomaly and identify any compromised accounts or systems.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and decision-making.
-- Implement enhanced logging and monitoring on network traffic, focusing on unusual destination ports and data transfer patterns.
-- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block traffic to and from the identified unusual ports.
-- Apply patches and updates to all affected systems to close any vulnerabilities exploited during the exfiltration.
-- Conduct a security awareness training session for employees to recognize and report suspicious activities.
-- Restore systems to their operational state by reimaging affected machines and verifying the integrity of data backups.
-- Implement hardening measures such as network segmentation, least privilege access, and multi-factor authentication to reduce the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
index 2641095e8b0..b66d2fcbc9f 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 75
@@ -52,48 +52,6 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual Region
-
-Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical regions. Adversaries exploit command and control (C2) channels to exfiltrate data to these unusual locations, bypassing traditional security measures. The detection rule leverages these models to flag suspicious geo-location activities, aligning with MITRE ATT&CK's exfiltration tactics, thus aiding in early threat identification.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific geo-location flagged as unusual and the volume of data transferred.
-- Cross-reference the geo-location with the organization's known business operations to determine if the location is indeed atypical.
-- Analyze historical network traffic logs to identify patterns and determine if similar data transfers have occurred in the past.
-- Examine the source IP address and destination IP address involved in the data transfer to identify any known malicious activity or anomalies.
-- Utilize Osquery to gather additional context on the involved endpoints. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<destination_ip>';`
-- Investigate the user accounts associated with the data transfer to check for any signs of compromise or unusual activity.
-- Check for any recent changes in firewall or proxy configurations that might have allowed the data transfer to bypass security controls.
-- Correlate the alert with other security events or alerts to identify potential patterns or coordinated attacks.
-- Review endpoint logs for any signs of malware or unauthorized software that could facilitate data exfiltration.
-- Consult threat intelligence sources to determine if the destination IP or geo-location is associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Legitimate business operations involving international data transfers can trigger false positives. Organizations with global operations may frequently transfer data to regions that are atypical for other businesses but normal for them.
-- Cloud service providers often have data centers in various regions. Routine data synchronization or backup activities to these locations might be misidentified as exfiltration attempts.
-- Remote work scenarios where employees connect from different geographical locations can lead to false positives, especially if employees are traveling or using VPNs that exit in unusual regions.
-- To manage these false positives, users can create exceptions for known and verified data transfer activities that align with business operations. This involves maintaining an updated list of trusted geo-locations and regularly reviewing and adjusting the detection rule's sensitivity to accommodate legitimate traffic patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the scope of the exfiltration, including the data types and volumes transferred.
-- Analyze network logs and endpoint data to trace the source of the command and control (C2) channel used for exfiltration.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for awareness and further action.
-- Implement enhanced logging policies to capture detailed network traffic and endpoint activities for future investigations.
-- Integrate threat intelligence feeds to update detection rules and improve anomaly detection capabilities.
-- Restore affected systems from clean backups to ensure no malicious code remains.
-- Apply security patches and updates to all systems to mitigate vulnerabilities exploited during the attack.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement network segmentation and data loss prevention (DLP) measures to harden the environment against future exfiltration attempts."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
index cde76e7fc8c..39917340b0a 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 75
@@ -51,49 +51,6 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Bytes Sent to an External Device
-
-In modern environments, data transfer to external devices is common, yet it follows predictable patterns. Adversaries exploit this by transferring large volumes of data to external media, bypassing network defenses. The detection rule leverages machine learning to identify anomalies in data transfer volumes, flagging potential exfiltration attempts that deviate from normal operational behavior.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the timestamp, user, and device involved in the data transfer.
-- Verify the volume of data transferred against historical data transfer patterns for the specific user and device to confirm the anomaly.
-- Check the user activity logs around the time of the alert to identify any unusual behavior or access patterns.
-- Investigate the external device's details, such as the device ID and connection history, to determine if it is a known or trusted device.
-- Use Osquery to gather more information about the external device connection. Example query: `SELECT * FROM usb_devices WHERE serial = '<device_serial_number>';`
-- Examine file access logs to identify which files were accessed and potentially transferred to the external device.
-- Correlate the alert with other security events or alerts to identify if this is part of a larger pattern of suspicious activity.
-- Interview the user associated with the alert to gather context on the data transfer and verify if it was a legitimate business need.
-- Check for any recent changes in user permissions or roles that might explain the increased data transfer.
-- Review the organization's data transfer policies and compare them with the user's activity to assess compliance and identify any policy violations.
-
-### False positive analysis
-
-- Routine data backups to external devices can trigger false positives, especially if they involve large volumes of data. Users can manage this by creating exceptions for scheduled backup activities.
-- Software updates or installations that require transferring substantial data to external media may be flagged. To handle this, users should whitelist known update processes or installation activities.
-- Data transfers related to legitimate business operations, such as transferring large datasets for analysis or reporting, can be mistaken for exfiltration attempts. Users should document and exclude these regular business processes from triggering alerts.
-- Employee use of external storage for legitimate purposes, like presentations or offsite work, might cause false positives. Implementing a policy to register and approve such devices can help in excluding these activities.
-- Automated system processes that involve data archiving or migration to external devices can be misinterpreted as suspicious. Users should identify and exclude these automated tasks from the anomaly detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected device from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the data transfer, including reviewing logs and any available forensic data.
-- Verify the legitimacy of the data transfer by contacting the user or department responsible for the device.
-- If malicious activity is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
-- Implement additional logging and monitoring on external device connections and data transfers to detect future anomalies.
-- Review and update data transfer policies to ensure they align with current security standards and practices.
-- Restore the system to its operational state by removing any unauthorized software or malware and applying necessary patches or updates.
-- Conduct a security awareness training session for employees to reinforce the importance of data security and the risks associated with unauthorized data transfers.
-- Implement hardening measures such as disabling unused ports, enforcing strict access controls, and using data loss prevention (DLP) tools.
-- Document the incident and response actions taken to improve future incident handling and refine detection capabilities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
index 47deab331a2..9236fbdd189 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 75
@@ -52,49 +52,6 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Bytes Sent to an External Device via Airdrop
-
-Airdrop facilitates seamless file sharing between Apple devices, leveraging Bluetooth and Wi-Fi. While convenient, adversaries can exploit it to exfiltrate data stealthily. The detection rule identifies anomalies by monitoring data transfer volumes, flagging unusually high data spikes as potential illicit activities, thus alerting analysts to investigate possible data breaches.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the timestamp, source device, and volume of data transferred.
-- Verify the identity of the external device receiving the data to determine if it is a known and trusted device.
-- Cross-reference the user account associated with the data transfer to check for any unusual or unauthorized access patterns.
-- Analyze historical data transfer patterns for the source device to identify deviations from normal behavior.
-- Use Osquery to gather additional context on the source device. For example, run the following query to list recent Airdrop activities: `SELECT * FROM process_events WHERE path LIKE '%AirDrop%' AND datetime > (SELECT datetime('now', '-1 day'));`
-- Check for any recent changes in user permissions or configurations on the source device that might have facilitated the data transfer.
-- Investigate any concurrent network activities or connections from the source device that could indicate coordinated data exfiltration efforts.
-- Examine system logs for any signs of malware or unauthorized software that could be facilitating the data transfer.
-- Correlate the alert with other security events or alerts to identify potential patterns or coordinated attacks.
-- Consult with the user or device owner to verify if the data transfer was legitimate and authorized, and gather any additional context or explanations.
-
-### False positive analysis
-
-- High data transfer volumes via Airdrop can occur during legitimate activities such as software updates, large media file transfers, or backups, which may trigger false positives.
-- Users frequently sharing large files for collaborative projects or educational purposes might also cause spikes that are non-threatening.
-- To manage these false positives, analysts can create exceptions for known devices or users who regularly transfer large amounts of data as part of their normal workflow.
-- Implementing a baseline of typical data transfer patterns for specific departments or roles can help distinguish between legitimate and suspicious activities.
-- Regularly updating the detection model with feedback from investigations can improve its accuracy in differentiating between false positives and genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected device from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the data transfer, including reviewing logs and any associated user activity.
-- Verify the legitimacy of the data transfer by contacting the user involved and cross-referencing with business operations.
-- If malicious activity is confirmed, escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
-- Implement additional logging and monitoring for Airdrop activities to capture detailed information on future data transfers.
-- Review and update security policies to restrict Airdrop usage to only authorized personnel and devices.
-- Restore the system to its operational state by ensuring all unauthorized changes are reverted and any malicious software is removed.
-- Conduct a post-incident review to identify gaps in the current security posture and improve detection capabilities.
-- Educate employees on the risks associated with Airdrop and best practices for secure data sharing.
-- Consider integrating advanced threat detection tools that leverage machine learning to enhance anomaly detection and response capabilities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
index e35fa6e5686..ea9d9ea5633 100644
--- a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 75
@@ -51,49 +51,6 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process Writing Data to an External Device
-
-In modern environments, processes writing data to external devices are common for legitimate tasks like backups. However, adversaries exploit this by using innocuous processes to exfiltrate data. The detection rule leverages machine learning to identify rare processes performing such actions, flagging potential exfiltration attempts by correlating with MITRE ATT&CK's exfiltration tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name, process ID, and the external device involved in the data writing activity.
-- Check the historical activity of the identified process to determine if it has previously interacted with external devices or if this behavior is anomalous.
-- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or job responsibilities.
-- Use Osquery to gather additional context about the process. For example, run the following query to retrieve details about the process and its parent process: `SELECT pid, name, path, parent, cmdline FROM processes WHERE pid = <process_id>;`
-- Examine the command line arguments and execution path of the process to identify any suspicious or unexpected parameters that could indicate malicious intent.
-- Analyze the external device's connection history to determine if it has been used frequently or if it is a new or rarely used device.
-- Cross-reference the process and device activity with network logs to identify any concurrent data transfer events that could suggest exfiltration.
-- Check for any recent changes or updates to the system that might have introduced new software or scripts capable of writing data to external devices.
-- Review any related security alerts or logs from other security tools that might provide additional context or corroborate the suspicious activity.
-- Consult with the user or system owner to verify if the process activity was authorized or if they are aware of any legitimate reason for the data transfer to the external device.
-
-### False positive analysis
-
-- Backup software: Legitimate backup processes may frequently write data to external devices, triggering false positives. Users can handle this by creating exceptions for known backup applications.
-- System updates: Operating system or application updates might involve writing data to external devices, which can be mistaken for exfiltration. Users should whitelist update processes to prevent unnecessary alerts.
-- Data synchronization tools: Applications like cloud storage sync tools may write data to external devices as part of their normal operation. Users can exclude these tools from monitoring to reduce false positives.
-- IT administrative tasks: IT personnel might use scripts or tools to transfer data to external devices for maintenance or troubleshooting. Users should document and exclude these routine tasks from detection rules.
-- Media creation software: Software used for creating media content may write large amounts of data to external devices, which could be misinterpreted as exfiltration. Users can add exceptions for these specific applications.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the process responsible for writing data to the external device, including reviewing logs and process histories.
-- Verify the legitimacy of the process by cross-referencing with known software and legitimate use cases; if malicious, terminate the process.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process activities and external device interactions for future monitoring.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by removing any malicious software and applying necessary patches or updates.
-- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
-- Educate employees on recognizing and reporting suspicious activities, emphasizing the importance of data security and device usage policies.
-- Review and update security policies and procedures to include specific measures against data exfiltration tactics, leveraging MITRE ATT&CK framework insights."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
index 906a62255ca..8fd4b2d3054 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,49 +59,6 @@ type = "query"
 query = '''
 ml_is_dga.malicious_prediction:1 and dns.question.registered_domain:avsvmcloud.com
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Machine Learning Detected DGA activity using a known SUNBURST DNS domain
-
-Machine learning models can identify patterns in DNS queries indicative of Domain Generation Algorithms (DGAs), often used by malware like SUNBURST for command and control. Adversaries exploit DGAs to dynamically generate domain names, evading static blocklists. This detection rule leverages machine learning to flag DNS queries linked to SUNBURST, focusing on domains like avsvmcloud.com, thus identifying potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `ml_is_dga.malicious_prediction:1` field, indicating a high-confidence prediction of DGA activity.
-- Verify the DNS query details, specifically focusing on the `dns.question.registered_domain:avsvmcloud.com`, to confirm the domain associated with SUNBURST activity.
-- Cross-reference the detected domain with known threat intelligence sources to gather additional context on its association with SUNBURST or other malicious activities.
-- Analyze historical DNS logs to identify any patterns or frequency of queries to `avsvmcloud.com` from the same host or network segment.
-- Use Osquery to investigate the host that generated the DNS query. For example, run the following query to list recent DNS queries made by the host: `SELECT name, time, count FROM dns_cache WHERE name LIKE '%avsvmcloud.com%';`
-- Examine network traffic logs to identify any additional suspicious domains or IP addresses that the host may have communicated with around the time of the alert.
-- Check endpoint security logs for any signs of suspicious processes or anomalies on the host that could indicate compromise or malware activity.
-- Investigate user activity on the affected host to determine if any unauthorized or unusual actions were performed around the time of the alert.
-- Review system and application logs on the host for any errors or warnings that could be related to the detected DGA activity.
-- Collaborate with other security teams to correlate this alert with any other ongoing investigations or incidents that might be related to SUNBURST or similar threats.
-
-### False positive analysis
-
-- Legitimate software or services that use dynamic DNS for load balancing or failover purposes may trigger false positives, as they can exhibit similar domain generation patterns to those used by DGAs.
-- Security researchers or network administrators conducting tests or simulations involving SUNBURST-related domains might inadvertently generate traffic that resembles malicious activity.
-- Organizations using security tools that perform DNS lookups on known malicious domains for threat intelligence purposes could also be flagged by this rule.
-- To manage these false positives, users can create exceptions for known legitimate services or internal testing environments by whitelisting specific IP addresses or domain names.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further communication with potentially malicious domains.
-- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise, such as unusual processes or unauthorized access attempts.
-- Utilize endpoint detection and response (EDR) tools to scan for and remove any malicious software associated with the SUNBURST malware.
-- Review DNS logs and network traffic to identify other systems that may have communicated with the SUNBURST-related domains, expanding the scope of the investigation as needed.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are required.
-- Implement or update DNS filtering policies to block known malicious domains and prevent future connections to SUNBURST-related domains.
-- Restore the affected system from a known good backup, ensuring that all security patches and updates are applied before reconnecting to the network.
-- Enhance logging and monitoring capabilities to capture detailed DNS query logs and network traffic for future investigations.
-- Integrate threat intelligence feeds to stay informed about emerging threats and update detection rules accordingly.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and least privilege access controls, to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
index 2c33e452467..5f43ccebc1a 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -60,48 +60,6 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential DGA Activity
-Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. Adversaries exploit this by frequently changing domains to evade detection. The 'Potential DGA Activity' detection rule leverages machine learning to analyze DNS requests from source IPs, identifying patterns indicative of DGA usage, thus flagging potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the source IP address associated with the potential DGA activity.
-- Analyze DNS logs to identify the specific domains queried by the source IP and check for patterns or anomalies in the domain names.
-- Cross-reference the identified domains with threat intelligence feeds to determine if they are known malicious or suspicious domains.
-- Use Osquery to gather additional context on the source IP's host by running a query to list recent DNS queries: `SELECT name, count FROM dns_cache WHERE name LIKE '%.%' ORDER BY count DESC LIMIT 10;`
-- Investigate the network traffic from the source IP to identify any unusual or unexpected outbound connections, focusing on the frequency and timing of the connections.
-- Check for any other alerts or logs related to the source IP to determine if there is a broader pattern of suspicious activity.
-- Examine endpoint logs for the source IP to identify any processes or applications that may be responsible for generating the DNS requests.
-- Review user activity associated with the source IP to determine if there is any legitimate reason for the observed DNS behavior.
-- Consult with other teams or departments to gather additional context or insights about the source IP or the domains in question.
-- Document findings and observations to build a comprehensive picture of the potential threat, which can be used for further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Legitimate applications or services that frequently update or communicate with multiple domains may trigger false positives. Examples include content delivery networks (CDNs), cloud services, or software update mechanisms that use dynamic domain resolution.
-- Internal company services that use dynamic DNS for load balancing or failover purposes might be mistakenly flagged as DGA activity.
-- Users can manage these false positives by creating exceptions for known benign domains or IP addresses associated with trusted services, ensuring they are not flagged in future analyses.
-- Regularly review and update the list of exceptions to accommodate changes in legitimate service behaviors, reducing the likelihood of overlooking genuine threats.
-- Collaborate with IT and network teams to identify and document legitimate dynamic domain usage within the organization, aiding in the refinement of detection rules.
-
-### Response and remediation
-
-- Isolate the affected systems from the network to prevent further communication with potentially malicious domains.
-- Conduct a thorough investigation of DNS logs to identify all domains queried by the affected source IPs and cross-reference them with known malicious DGA patterns.
-- Utilize endpoint detection and response (EDR) tools to scan the affected systems for malware and remove any identified threats.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger campaign.
-- Implement network-level blocking of identified malicious domains and IP addresses to prevent future communication attempts.
-- Review and enhance DNS logging policies to ensure comprehensive visibility into DNS queries and responses for future investigations.
-- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection of DGA-related activities.
-- Restore affected systems from clean backups and ensure all security patches and updates are applied to prevent exploitation of known vulnerabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement network segmentation and least privilege access controls to limit the potential impact of future DGA-related threats."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
index 235f4b807fd..c144bd2ddb0 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,48 +59,6 @@ type = "query"
 query = '''
 ml_is_dga.malicious_probability > 0.98
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Machine Learning Detected a DNS Request With a High DGA Probability Score
-
-Machine learning models can identify DNS requests likely generated by Domain Generation Algorithms (DGAs), which adversaries use to dynamically change domain names for command and control servers, evading detection. This detection rule flags DNS queries with a high DGA probability, indicating potential malicious activity by correlating with known threat tactics and techniques.
-
-### Possible investigation steps
-
-- Review the DNS query logs to identify the specific domain name associated with the high DGA probability score and note the timestamp of the query.
-- Cross-reference the identified domain name with threat intelligence databases to check for any known associations with malicious activity or threat actors.
-- Analyze the source IP address of the DNS request to determine the originating device within the network and assess its role and importance.
-- Use Osquery to gather additional context on the originating device by running a query such as: `SELECT * FROM processes WHERE pid IN (SELECT pid FROM dns_resolvers WHERE domain = '<suspicious_domain>');` to identify processes that may have initiated the DNS request.
-- Investigate the network traffic logs for the source IP address around the time of the DNS request to identify any unusual or suspicious outbound connections.
-- Check for any other DNS requests from the same source IP address that have high DGA probability scores to determine if there is a pattern of suspicious behavior.
-- Examine endpoint security logs for the originating device to identify any recent alerts or anomalies that could correlate with the suspicious DNS activity.
-- Review user activity logs for the user associated with the originating device to identify any unusual behavior or access patterns.
-- Consult with the network team to verify if there have been any recent changes or anomalies in network configurations that could explain the DNS request.
-- Document all findings and correlations in a centralized investigation report to facilitate further analysis and decision-making.
-
-### False positive analysis
-
-- Known false positives for the Machine Learning Detected a DNS Request With a High DGA Probability Score rule can include legitimate services that frequently change domain names, such as content delivery networks (CDNs) or cloud service providers, which may use dynamic DNS techniques similar to DGAs.
-- Users can manage these false positives by creating exceptions for known benign domains or IP addresses that are frequently flagged. This can be done by maintaining a whitelist of trusted domains that are known to use dynamic resolution but are not associated with malicious activity.
-- Regularly updating the whitelist and reviewing flagged domains against threat intelligence feeds can help ensure that legitimate services are not mistakenly blocked, while still maintaining robust security against actual threats.
-- Implementing a feedback loop where security analysts can mark certain detections as false positives can help refine the machine learning model over time, reducing the likelihood of similar false positives in the future.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further communication with potential command and control servers.
-- Conduct a thorough investigation of the DNS logs to identify all domains queried by the affected system and cross-reference with known malicious DGA patterns.
-- Utilize endpoint detection and response (EDR) tools to perform a deep scan of the affected system for any signs of malware or unauthorized software.
-- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block identified malicious domains and IP addresses.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced DNS logging and monitoring to capture detailed query data for future analysis and threat hunting.
-- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection of DGA-related activities.
-- Restore the affected system from a known good backup to ensure it is free from compromise and verify the integrity of critical files and configurations.
-- Apply security patches and updates to the operating system and all installed software to mitigate vulnerabilities that could be exploited by attackers.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures such as network segmentation and least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
index 839d71b1056..9bdf80ef78a 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,49 +59,6 @@ type = "query"
 query = '''
 ml_is_dga.malicious_prediction:1 and not dns.question.registered_domain:avsvmcloud.com
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Machine Learning Detected a DNS Request Predicted to be a DGA Domain
-
-Machine learning models can identify patterns in DNS requests that suggest the use of Domain Generation Algorithms (DGAs), often employed by adversaries to dynamically generate domain names for command and control servers, evading static blocklists. This detection rule leverages such models to flag DNS queries likely generated by DGAs, excluding known benign domains, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `ml_is_dga.malicious_prediction` field to confirm the prediction of a DGA domain.
-- Examine the `dns.question.registered_domain` field to identify the specific domain flagged by the machine learning model.
-- Cross-reference the flagged domain against known threat intelligence sources to determine if it has been previously associated with malicious activity.
-- Investigate the source IP address of the DNS request to identify the device or user responsible for the query.
-- Use network logs to trace the DNS request's path and identify any other suspicious domains queried by the same source.
-- Analyze historical DNS logs to check for patterns or repeated queries to similar domains, which might indicate ongoing DGA activity.
-- Utilize Osquery to gather additional context from the endpoint. For example, run the following query to list recent DNS queries from the device: `SELECT name, time FROM dns_resolvers WHERE name LIKE '%<suspicious_domain>%' ORDER BY time DESC;`
-- Check for any associated processes or applications on the endpoint that might be generating the suspicious DNS requests, using endpoint detection and response (EDR) tools.
-- Investigate any outbound connections from the source IP to external IPs that might correlate with the flagged domain, using firewall or proxy logs.
-- Collaborate with other teams to gather additional context, such as user activity logs or recent changes to the network environment, to better understand the potential threat.
-
-### False positive analysis
-
-- Known false positives for the Machine Learning Detected a DNS Request Predicted to be a DGA Domain rule can include legitimate services that frequently change their domain names, such as content delivery networks (CDNs) or cloud service providers, which may use dynamic domain generation for load balancing or redundancy.
-- Users can manage these false positives by creating exceptions for domains that are verified to be part of legitimate services. This can be done by maintaining a whitelist of known benign domains that are frequently flagged, ensuring that these are excluded from the machine learning model's predictions.
-- Another potential false positive source is internal applications that use dynamic domain generation for legitimate purposes, such as testing environments or internal load balancing. Users should identify these applications and add their domains to an exception list to prevent unnecessary alerts.
-- Regularly reviewing and updating the list of exceptions is crucial, as legitimate services may change their domain generation patterns over time. This ensures that the detection rule remains effective without being overwhelmed by false positives.
-- Collaboration with network and security teams can help in identifying patterns of legitimate dynamic domain usage, allowing for more accurate tuning of the detection rule and reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further communication with potential command and control servers.
-- Conduct a thorough investigation of the DNS logs to identify other potentially malicious domains and assess the scope of the compromise.
-- Utilize endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise (IOCs) and remove any identified malware.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement a temporary block on the identified malicious domains across the network to prevent further access.
-- Review and enhance DNS logging policies to ensure comprehensive monitoring and detection of suspicious activities in the future.
-- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection capabilities for DGA-related threats.
-- Restore the affected system from a known good backup to ensure it is free from compromise and return it to operational status.
-- Apply security patches and updates to the affected system and other vulnerable systems to mitigate exploitation risks.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and enhanced access controls, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/endpoint/elastic_endpoint_security.toml b/rules/integrations/endpoint/elastic_endpoint_security.toml
index 74c72bfeba3..37be3ddc9b9 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "New fields added: required_fields, related_integrations, setup"
 min_stack_version = "8.3.0"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/11/27"
 
 [rule]
 author = ["Elastic"]
@@ -59,49 +59,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:(endpoint and not endgame)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Endpoint Security
-
-Endpoint Security plays a crucial role in safeguarding devices by monitoring and responding to threats. It leverages alerts from Elastic Endpoint Security to detect suspicious activities. Adversaries may exploit endpoints to execute unauthorized actions or exfiltrate data. The detection rule identifies potential threats by filtering alerts related to endpoint activities, excluding non-relevant modules, thus enabling swift investigation and response.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `event.kind:alert` and `event.module:endpoint` fields to confirm the alert's origin and type.
-- Check the alert timestamp to determine when the suspicious activity occurred and correlate it with other events around the same time.
-- Investigate the affected endpoint by identifying the device's hostname or IP address from the alert details.
-- Examine user activity on the affected endpoint to identify any unauthorized access or actions, using logs that capture user logins and executed commands.
-- Utilize Osquery to gather more information about the endpoint. For example, run the following query to list all running processes: `SELECT pid, name, path, cmdline FROM processes;`.
-- Analyze network connections from the affected endpoint to identify any unusual or unauthorized external communications.
-- Cross-reference the alert with other security tools and logs to gather additional context, such as firewall logs or intrusion detection system alerts.
-- Investigate any file modifications or creations on the endpoint around the alert time to detect potential malicious files or scripts.
-- Check for any recent changes in system configurations or installed software that could indicate tampering or exploitation.
-- Review historical alerts and incidents related to the same endpoint or user to identify patterns or repeated attack attempts.
-
-### False positive analysis
-
-- Known false positives for the Endpoint Security rule may include benign activities that resemble threat patterns, such as routine software updates or legitimate administrative tasks that trigger alerts.
-- Users can manage these false positives by creating exceptions for specific processes or activities that are consistently identified as non-threatening, ensuring these are well-documented and reviewed regularly.
-- It's important to analyze the context of each alert to determine if it aligns with expected behavior, such as scheduled maintenance or known software behavior, before categorizing it as a false positive.
-- Implementing a feedback loop with security teams can help refine detection rules and reduce the frequency of false positives by adjusting the criteria for alerts.
-- Regularly updating the list of exceptions and reviewing them against current threat intelligence can help maintain a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected endpoint from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the alert by analyzing logs and endpoint data to determine the scope and impact of the threat.
-- Identify and terminate any malicious processes or unauthorized access points on the affected endpoint.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is beyond the current team's capability to handle.
-- Apply patches or updates to the affected systems to address any vulnerabilities exploited by the adversary.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup if necessary.
-- Implement enhanced logging policies to capture detailed endpoint activity for future investigations.
-- Integrate additional security tools, such as intrusion detection systems or threat intelligence platforms, to improve threat detection capabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update security policies accordingly.
-- Apply hardening measures, such as disabling unnecessary services and enforcing strong authentication mechanisms, to reduce the attack surface of endpoints."""
 
 
 [[rule.exceptions_list]]
diff --git a/rules/integrations/fim/persistence_suspicious_file_modifications.toml b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
index a4201fe00fb..3d4d2b5e806 100644
--- a/rules/integrations/fim/persistence_suspicious_file_modifications.toml
+++ b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["fim"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/17"
 
 [rule]
 author = ["Elastic"]
@@ -133,48 +133,6 @@ file.path : (
   file.extension in ("dpkg-new", "dpkg-remove", "SEQ")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Persistence via File Modification
-
-File Integrity Monitoring (FIM) is crucial for detecting unauthorized changes to critical files, often targeted by adversaries for persistence. Attackers may modify cron jobs, systemd services, or shell configurations to maintain access. The detection rule identifies suspicious updates to these files, excluding benign changes, to alert analysts to potential persistence mechanisms.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path that triggered the alert, focusing on the `file.path` field to understand which critical file was modified.
-- Check the `event.action` field to confirm that the action was indeed an "updated" event, indicating a modification rather than a creation or deletion.
-- Investigate the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is specifically designed for Linux environments.
-- Examine the `event.dataset` field to verify that the event originated from the "fim.event" dataset, confirming it was captured by File Integrity Monitoring.
-- Use Osquery to gather additional context about the modified file. For example, run the following query to check the file's current permissions and ownership: `SELECT path, mode, uid, gid FROM file WHERE path = '<file_path>';` Replace `<file_path>` with the actual path from the alert.
-- Investigate recent user activity on the system by reviewing authentication logs (e.g., `/var/log/auth.log`) to identify any suspicious logins or user actions around the time of the file modification.
-- Check for any recent changes to systemd services or cron jobs by listing all active services and scheduled tasks, which might provide clues about persistence mechanisms.
-- Review the system's bash history or other shell history files for commands executed by users that might have led to the file modification.
-- Use Osquery to list all currently loaded kernel modules and running processes to identify any unusual or unauthorized modules or processes that could be related to persistence: `SELECT name, path FROM kernel_modules;` and `SELECT pid, name, path FROM processes;`.
-- Investigate the system for any additional indicators of compromise, such as unexpected network connections or unusual system behavior, which might correlate with the file modification event.
-
-### False positive analysis
-
-- Routine system updates or package installations may modify files monitored by the rule, leading to false positives. Users can manage this by excluding file extensions like "dpkg-new" or "dpkg-remove" from triggering alerts.
-- Temporary files created during system operations, such as those in "/var/spool/cron/crontabs/tmp.*" or "/run/udev/rules.d/*rules.*", can cause false positives. These can be excluded from monitoring to reduce noise.
-- Known hosts files in SSH directories, such as "/home/*/.ssh/known_hosts.*" and "/root/.ssh/known_hosts.*", are often updated during normal SSH operations and can be safely excluded to prevent false alerts.
-- Users should regularly review and update the exclusion list to reflect any new benign patterns observed in their environment, ensuring that legitimate changes do not trigger unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the scope of the modification, including reviewing logs and correlating with other security events.
-- Verify the integrity of the modified files against known good configurations or backups to determine unauthorized changes.
-- Restore the affected files from a clean backup if unauthorized modifications are confirmed.
-- Change all credentials and keys that may have been exposed or compromised due to the persistence mechanism.
-- Escalate the incident to the security operations center (SOC) or incident response team if the modification is part of a broader attack campaign.
-- Implement enhanced logging and monitoring for critical files and directories to detect future unauthorized changes promptly.
-- Review and update file integrity monitoring policies to ensure comprehensive coverage of critical system files.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
index 00027696cb0..3d33d2ee993 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,52 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Subscription Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Pub/Sub Subscription Creation
-
-Google Cloud Platform's Pub/Sub service facilitates asynchronous messaging, allowing services to communicate without direct interaction. Adversaries might exploit this by creating unauthorized subscriptions to intercept or exfiltrate data. The detection rule monitors audit logs for successful subscription creation events, helping identify potential misuse by flagging unexpected or suspicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `gcp.audit` and the action is `google.pubsub.v*.Subscriber.CreateSubscription` with a successful outcome.
-- Identify the user or service account associated with the subscription creation event to determine if it aligns with expected activity.
-- Check the timestamp of the event to see if it coincides with any known maintenance windows or scheduled tasks.
-- Investigate the project and resource names involved in the subscription creation to verify if they are legitimate and expected.
-- Examine the IP address and location from which the subscription creation request originated to identify any anomalies or unexpected access patterns.
-- Use Osquery to gather additional context on the GCP environment. For example, run a query to list all subscriptions in the project: `SELECT * FROM gcp_pubsub_subscriptions WHERE project_id = '<project_id>';`.
-- Cross-reference the subscription creation event with other logs, such as IAM activity logs, to identify any preceding or subsequent suspicious actions.
-- Analyze the permissions and roles assigned to the user or service account to ensure they are appropriate and have not been escalated recently.
-- Review historical data to determine if there have been any similar subscription creation events in the past and their outcomes.
-- Consult with relevant stakeholders or teams to confirm if the subscription creation was part of a legitimate business process or project initiative.
-
-### False positive analysis
-
-- Routine subscription creations by automated processes or scheduled jobs can trigger false positives. These are often part of normal operations and not indicative of malicious activity.
-- Development and testing environments may frequently create and delete subscriptions as part of their workflow, leading to benign alerts.
-- Internal monitoring or logging services might create subscriptions to capture application metrics or logs, which are legitimate and expected activities.
-- To manage these false positives, users can create exceptions for known service accounts or projects that regularly perform these actions.
-- Implementing a baseline of normal subscription creation activity can help differentiate between expected and suspicious behavior.
-- Regularly review and update the list of exceptions to ensure they align with current operational practices and do not inadvertently exclude genuine threats.
-
-### Response and remediation
-
-- Verify the legitimacy of the subscription creation by checking the associated user or service account and their permissions.
-- Contain the potential threat by temporarily disabling the suspicious subscription and any associated service accounts.
-- Investigate the source of the subscription creation by reviewing audit logs for unusual activity or unauthorized access patterns.
-- Remediate by revoking any unauthorized access and resetting credentials for compromised accounts.
-- Escalate the incident to the security operations team if the activity is confirmed as malicious or if there is evidence of data exfiltration.
-- Implement enhanced logging policies to capture detailed access and modification events for Pub/Sub resources.
-- Integrate with a Security Information and Event Management (SIEM) system to automate the detection of suspicious subscription activities.
-- Restore the system to its operational state by re-enabling legitimate subscriptions and ensuring all security measures are in place.
-- Harden the environment by applying the principle of least privilege to all service accounts and regularly reviewing permissions.
-- Educate users and administrators on recognizing and reporting suspicious activities related to Pub/Sub services.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
index f48f9365a3e..701fd52c77f 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Topic Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Pub/Sub Topic Creation
-
-Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between services by decoupling event producers and consumers. Adversaries might exploit this by creating topics to exfiltrate data or orchestrate malicious activities. The detection rule monitors audit logs for successful topic creation events, helping identify unauthorized or suspicious activities that could indicate abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.pubsub.v*.Publisher.CreateTopic`, and `event.outcome:success` to ensure the alert is based on a successful topic creation event.
-- Identify the user or service account associated with the topic creation by examining the `user.name` or `user.email` fields in the audit log.
-- Check the `source.ip` field to determine the origin of the request and assess if it aligns with known and expected IP addresses for your organization.
-- Investigate the `gcp.project_id` field to understand which project the topic was created in and verify if the project is legitimate and expected to have new topics created.
-- Examine the `gcp.resource.name` field to identify the specific topic name and assess if it follows the naming conventions and patterns used within your organization.
-- Review historical logs for the identified user or service account to determine if there have been any other unusual or unauthorized activities.
-- Use Osquery to gather additional context on the GCP environment. For example, run the following query to list all topics in the project: `SELECT * FROM gcp_pubsub_topics WHERE project_id = '<project_id>';`.
-- Check for any recent changes in IAM policies or permissions related to Pub/Sub within the project to identify potential privilege escalations or misconfigurations.
-- Correlate the topic creation event with other logs or alerts to identify any related suspicious activities, such as data exfiltration attempts or unusual data processing patterns.
-- Consult with the project owner or relevant stakeholders to verify if the topic creation was authorized and aligns with current business needs or projects.
-
-### False positive analysis
-
-- Routine operations by development teams: Developers often create Pub/Sub topics during application development and testing. These activities are typically benign and can be excluded by identifying and whitelisting specific user accounts or service accounts associated with development environments.
-- Automated infrastructure provisioning: Tools like Terraform or Cloud Deployment Manager may automatically create Pub/Sub topics as part of infrastructure setup. To manage these, users can exclude events originating from known automation tools or specific project IDs used for infrastructure management.
-- Scheduled maintenance or updates: Regular maintenance tasks or updates might involve creating new topics temporarily. Users can handle these by setting time-based exceptions during known maintenance windows.
-- Internal data processing workflows: Some internal workflows may require the creation of new topics for data processing. Users should document these workflows and exclude related events by identifying specific patterns or labels associated with these processes.
-
-### Response and remediation
-
-- Verify the legitimacy of the topic creation by checking the associated user or service account and their permissions.
-- Contain potential threats by temporarily disabling the topic or restricting access to it until further investigation is completed.
-- Investigate the source of the topic creation by reviewing audit logs and identifying any unusual patterns or unauthorized access attempts.
-- Remediate unauthorized access by revoking permissions or credentials of compromised accounts and enforcing multi-factor authentication.
-- Escalate the incident to the security operations team if the topic creation is determined to be part of a larger attack or data exfiltration attempt.
-- Implement logging policies to ensure comprehensive monitoring of Pub/Sub activities, including topic creation, modification, and deletion.
-- Integrate with security information and event management (SIEM) systems to enhance real-time detection and correlation of suspicious activities.
-- Restore the system to its operational state by re-enabling legitimate topics and ensuring all security measures are in place.
-- Harden the environment by applying the principle of least privilege to all accounts and regularly reviewing access controls.
-- Educate users and administrators on recognizing and reporting suspicious activities related to Pub/Sub services to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/admin"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
index 98434b70a9e..bf65a769bb5 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,49 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Firewall Rule Creation
-In GCP, firewall rules manage network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may exploit this by creating rules that allow unauthorized access, bypassing security measures. The detection rule monitors audit logs for specific actions indicating new rule creation, helping identify potential security breaches by flagging suspicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `event.action` that triggered the alert, focusing on `*.compute.firewalls.insert` or `google.appengine.*.Firewall.Create*Rule`.
-- Examine the `event.dataset` field to confirm the event source is `gcp.audit`, ensuring the alert is based on audit logs.
-- Check the `user` or `serviceAccount` associated with the firewall rule creation to determine if the action was performed by a legitimate user or service.
-- Investigate the `sourceIP` and `userAgent` fields to identify the origin of the request and assess if it aligns with expected behavior or known IP addresses.
-- Analyze the `resource.name` field to determine which specific VPC or App Engine application the firewall rule was created for, and assess its criticality.
-- Review the `request` field to understand the parameters of the firewall rule, such as allowed IP ranges, protocols, and ports, to evaluate the potential impact on security.
-- Cross-reference the `timestamp` of the event with other security events or logs to identify any correlated suspicious activities around the same time.
-- Utilize Osquery to gather additional context from affected systems. For example, run the following Osquery query to list recent firewall rule changes: `SELECT * FROM gcp_firewall_rules WHERE action = 'insert' AND timestamp > date('now', '-1 day');`
-- Check for any recent changes in IAM roles or permissions that might have allowed unauthorized users to create firewall rules.
-- Consult with the relevant teams or stakeholders to verify if the firewall rule creation was part of a legitimate change request or deployment process.
-
-### False positive analysis
-
-- Routine administrative actions: Legitimate changes made by network administrators or automated processes can trigger the rule. To manage this, users can create exceptions for known IP addresses or service accounts frequently involved in authorized rule creation.
-- Automated deployment tools: Tools like Terraform or Deployment Manager that automate infrastructure changes may create firewall rules as part of their normal operation. Users should identify and exclude these tools' actions by filtering based on service accounts or specific project IDs.
-- Scheduled maintenance: Regularly scheduled updates or maintenance tasks might involve creating or modifying firewall rules. Users can handle these by setting up time-based exceptions or correlating with maintenance schedules to differentiate between expected and suspicious activities.
-- Development and testing environments: Firewall rules created in non-production environments for testing purposes can be mistaken for malicious activity. Users should tag or label these environments and exclude them from alerts to reduce noise.
-
-### Response and remediation
-
-- Immediately isolate the affected VPC or application to prevent further unauthorized access while maintaining essential services.
-- Review the audit logs to identify the source and context of the unauthorized firewall rule creation, focusing on user accounts and IP addresses involved.
-- Revoke any suspicious or unauthorized firewall rules and revert to the last known good configuration to restore security posture.
-- Conduct a thorough investigation to determine if any other security controls have been impaired or if additional unauthorized changes have been made.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments to assess potential impacts and obligations.
-- Implement enhanced logging policies to capture detailed information on firewall rule changes and other critical security events for future analysis.
-- Integrate with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious firewall rule activities.
-- Educate and train staff on the importance of secure firewall configurations and the risks associated with unauthorized changes.
-- Apply hardening measures such as least privilege access, multi-factor authentication, and regular audits of firewall rules and configurations.
-- Review and update incident response plans to incorporate lessons learned from the incident, ensuring a more robust response to future threats.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
index 11ab2691670..2bd5d930541 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Firewall Rule Deletion
-
-In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, exposing systems to unauthorized access. The detection rule monitors audit logs for deletion actions in VPC and App Engine environments, identifying potential security evasion attempts by tracking specific delete operations.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the deletion event by filtering logs with `event.dataset:gcp.audit` and `event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule)`.
-- Identify the user or service account responsible for the deletion by examining the `principalEmail` field in the audit log entry.
-- Check the `resourceName` field to determine which specific firewall rule was deleted and assess its importance to the network security posture.
-- Investigate the `timestamp` field to establish the exact time of the deletion and correlate it with other security events or anomalies in the environment.
-- Analyze the `sourceIP` field to identify the origin of the request and determine if it matches known or expected IP addresses.
-- Review the `userAgent` field to understand the tool or method used to perform the deletion, which might indicate whether it was a manual action or automated script.
-- Cross-reference the deletion event with recent changes in IAM roles or permissions to see if there were any unauthorized privilege escalations.
-- Use Osquery to gather additional context on the affected VM instances or applications. For example, run a query to list all current firewall rules: `SELECT * FROM gcp_firewall_rules WHERE project_id = 'your_project_id';`.
-- Investigate any recent changes in the network configuration or architecture that might have preceded the firewall rule deletion.
-- Check for any other suspicious activities or alerts in the same timeframe that could indicate a coordinated attack or broader security incident.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks can lead to legitimate firewall rule deletions, such as when network configurations are updated or deprecated rules are removed. Users should verify if the deletion aligns with scheduled maintenance activities.
-- Automated processes or scripts that manage firewall rules might trigger false positives if they are designed to periodically clean up or update rules. Users can create exceptions for these processes by identifying and excluding their specific identifiers or service accounts.
-- Changes in project ownership or restructuring within an organization might result in the deletion of firewall rules as part of resource reallocation. Users should ensure that such changes are documented and authorized to differentiate them from malicious activities.
-- Development and testing environments often have dynamic rule changes, including deletions, as part of normal operations. Users can manage false positives by excluding specific environments or using tags to differentiate between production and non-production resources.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further unauthorized access or damage.
-- Review audit logs to confirm the deletion of firewall rules and identify the source of the action.
-- Recreate the deleted firewall rules based on the last known good configuration to restore security controls.
-- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration occurred following the rule deletion.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed information on firewall rule changes and other critical security events.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate events and detect similar threats in the future.
-- Review and update access controls to ensure only authorized personnel can modify firewall rules.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate and train staff on the importance of firewall rules and the potential impact of their unauthorized deletion, leveraging MITRE ATT&CK framework insights on defense evasion and impair defenses.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
index 37ec443a9c3..ae5126fc5fb 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Firewall Rule Modification
-In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential security breaches by tracking specific actions indicative of such changes.
-
-### Possible investigation steps
-
-- Review the audit logs to identify the specific firewall rule that was modified by filtering logs with `event.dataset:gcp.audit` and `event.action:(*.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule)`.
-- Examine the `user.email` field in the audit logs to determine who made the modification and verify if the user is authorized to make such changes.
-- Check the `resource.name` field to identify the specific firewall rule and associated VPC or App Engine application that was altered.
-- Analyze the `protoPayload.request` field to understand the nature of the changes made to the firewall rule, such as new IP ranges or protocols allowed.
-- Investigate the `protoPayload.serviceData.policyDelta` field to see the before and after states of the firewall rule to assess the impact of the modification.
-- Use Osquery to query the GCP environment for additional context on the affected resources. Example query: `SELECT * FROM gcp_firewall_rules WHERE name = '<firewall_rule_name>';`.
-- Correlate the time of the firewall rule modification with other security events or alerts to identify any suspicious activity that might have occurred concurrently.
-- Review the `protoPayload.authenticationInfo.principalEmail` field to confirm the identity of the user and cross-reference with HR or identity management systems for any anomalies.
-- Investigate any recent changes in IAM roles or permissions for the user identified in the audit logs to ensure there are no unauthorized privilege escalations.
-- Check for any other recent modifications to firewall rules or security settings in the GCP environment to identify potential patterns or coordinated attacks.
-
-### False positive analysis
-
-- Routine administrative changes: Regular updates or maintenance by network administrators can trigger the rule. To manage this, users can create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated deployment tools: Tools that automatically adjust firewall settings during deployments may cause false positives. Users should identify and exclude these tools' actions from the rule.
-- Internal security audits: Security teams may intentionally modify firewall rules for testing purposes. Users can whitelist these activities by correlating them with audit schedules or specific user accounts.
-- Application updates: Updates to App Engine applications might require temporary firewall rule changes. Users can track these updates and exclude related actions from triggering alerts.
-- Cloud infrastructure changes: Changes in cloud infrastructure, such as scaling operations, might necessitate firewall rule modifications. Users should document these changes and adjust the rule to ignore them when they align with expected patterns.
-
-### Response and remediation
-
-- Immediately isolate affected systems or networks to prevent further unauthorized access or data exfiltration.
-- Review the audit logs to identify the source and scope of the firewall rule modification, including the user account and IP address involved.
-- Revert the modified firewall rules to their previous state to restore intended security controls and prevent unauthorized traffic.
-- Conduct a thorough investigation to determine if any unauthorized access or data exfiltration occurred during the period of altered firewall rules.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement additional logging and monitoring for firewall rule changes to detect and respond to future unauthorized modifications promptly.
-- Integrate with security information and event management (SIEM) systems to correlate firewall rule changes with other security events for comprehensive threat detection.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify firewall rules.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to address these vulnerabilities.
-- Enhance security awareness training for staff to recognize and report suspicious activities related to firewall rule modifications.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
index 0446f0ced5d..a9e9ba23557 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,51 +24,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Bucket Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Logging Bucket Deletion
-
-In GCP, log buckets are crucial for storing and managing log data, ensuring visibility into system activities. Adversaries may delete these buckets to obscure their tracks and evade detection. The detection rule identifies successful deletion actions by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.logging.v*.ConfigServiceV*.DeleteBucket`, and `event.outcome:success` to ensure the alert is triggered by a successful bucket deletion.
-- Check the timestamp of the deletion event to determine when the bucket was deleted and correlate it with other security events or anomalies around the same time.
-- Identify the user or service account associated with the deletion action by examining the `actor` field in the audit log to determine if the action was authorized or potentially malicious.
-- Investigate the source IP address and location from which the deletion request was made to identify any unusual access patterns or locations.
-- Review the project and resource details in the audit log to understand the scope and impact of the deletion, including which logs were being stored in the deleted bucket.
-- Examine the `request` and `response` fields in the audit log for additional context on the deletion request, such as any parameters or configurations that were specified.
-- Use Osquery to gather more information about the GCP environment. For example, run the following query to list all current log sinks and their destinations: `SELECT * FROM gcp_logging_sinks;`
-- Check for any recent changes to IAM policies or permissions that might have allowed unauthorized users to delete the log bucket.
-- Investigate any other recent audit logs for suspicious activities involving the same user or service account to identify potential patterns of malicious behavior.
-- Collaborate with the GCP admin team to verify if the deletion was part of a legitimate maintenance activity or if it requires further investigation.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may trigger the GCP Logging Bucket Deletion rule, as legitimate users might delete log buckets for reorganization or storage management purposes.
-- Automated scripts or tools used for managing GCP resources could inadvertently delete log buckets as part of their operations, leading to false positives.
-- To manage these false positives, users can create exceptions for known maintenance activities by excluding specific user accounts or service accounts from the detection rule.
-- Implementing a whitelist of IP addresses or user roles associated with regular administrative tasks can help reduce noise from non-threatening deletions.
-- Regularly review and update the detection rule's filters to exclude actions from trusted sources or during scheduled maintenance windows, ensuring that only suspicious deletions are flagged.
-
-### Response and remediation
-
-- Immediately verify the deletion event by cross-referencing with other logs and alerts to confirm unauthorized activity.
-- Contain the incident by disabling any compromised accounts or credentials that may have been used to delete the log bucket.
-- Investigate the scope of the incident by reviewing access logs and identifying any other suspicious activities or changes in the environment.
-- Remediate by restoring the deleted log bucket from backup if available, or reconfigure log sinks to redirect logs to an alternative bucket.
-- Escalate the incident to the security operations team and relevant stakeholders for further analysis and response.
-- Implement enhanced logging policies to ensure all critical actions are logged and monitored, including changes to logging configurations.
-- Integrate additional security tools and services, such as SIEM or cloud-native security solutions, to improve detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Harden the environment by applying the principle of least privilege to all accounts and regularly reviewing permissions and access controls.
-- Educate and train staff on security best practices and the importance of monitoring and protecting log data to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/buckets", "https://cloud.google.com/logging/docs/storage"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
index 7443b7a558b..3b91941b1cc 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Sink Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Logging Sink Deletion
-
-In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and monitoring. Adversaries may delete these sinks to prevent logs from being exported, thus evading detection. The detection rule identifies successful deletion events of logging sinks, signaling potential defense evasion attempts by matching specific audit log actions and outcomes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.logging.v*.ConfigServiceV*.DeleteSink`, and `event.outcome:success` to ensure the alert is valid and corresponds to a successful sink deletion.
-- Identify the user or service account associated with the deletion event by examining the `user.name` or `principalEmail` fields in the audit log entry.
-- Check the timestamp of the deletion event to determine when the sink was deleted and correlate this with any other suspicious activities around the same time.
-- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or unauthorized access patterns.
-- Review the permissions and roles assigned to the user or service account involved in the deletion to assess if they had legitimate access to perform this action.
-- Examine the specific logging sink that was deleted, including its previous configuration and destination, to understand the potential impact on log monitoring and analysis.
-- Cross-reference other logs and alerts from the same time period to identify any related or preceding suspicious activities that might indicate a broader attack or compromise.
-- Utilize Osquery to gather additional context on the affected GCP environment. For example, run a query to list all current logging sinks and their configurations: `SELECT * FROM gcp_logging_sinks;` to verify if other sinks have been tampered with.
-- Investigate any recent changes to IAM policies or service accounts that might have inadvertently or maliciously granted excessive permissions related to logging sink management.
-- Consult with relevant stakeholders or teams to verify if the sink deletion was part of a legitimate change or maintenance activity, and document any findings for future reference.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks: Regular updates or reconfigurations by authorized personnel may involve the deletion and recreation of logging sinks, which can trigger the detection rule. To manage this, users can create exceptions for known maintenance windows or specific user accounts that perform these tasks.
-- Automated scripts or tools: Some organizations use automated processes to manage logging configurations, which might include deleting and recreating sinks as part of their operation. Users should identify these scripts and exclude their actions from triggering alerts by specifying the service accounts or IP addresses associated with these tools.
-- Testing environments: In development or testing environments, logging sinks may be frequently deleted and recreated as part of testing procedures. Users can exclude these environments from the detection rule by filtering based on project IDs or labels associated with non-production environments.
-- Misconfigured alerts: Sometimes, alerts may be triggered due to misconfigured logging sinks that are intentionally deleted to correct errors. Users should review and adjust the configurations to ensure that only relevant deletions are monitored, possibly by refining the query to exclude specific error codes or conditions.
-
-### Response and remediation
-
-- Immediately isolate the affected GCP project to prevent further unauthorized changes and assess the scope of the incident.
-- Review audit logs to identify the user or service account responsible for the sink deletion and determine if any other suspicious activities have been performed.
-- Recreate the deleted logging sink with the appropriate filters and export destinations to restore logging capabilities.
-- Implement additional logging and monitoring to capture any further unauthorized changes, focusing on high-value resources and critical operations.
-- Conduct a thorough investigation to determine if any other security controls have been impaired or if there are signs of lateral movement or data exfiltration.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if law enforcement or external parties need to be notified.
-- Review and update IAM policies to ensure that only authorized users have permissions to modify or delete logging sinks and other critical resources.
-- Implement automated alerts for any future logging sink deletions or modifications to enable rapid response to similar incidents.
-- Consider integrating with a Security Information and Event Management (SIEM) system to enhance log analysis and correlation capabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as enabling multi-factor authentication and regular security training for users.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/export"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
index 97c219fa573..d81d4f1c70e 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Subscription Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Pub/Sub Subscription Deletion
-
-Google Cloud Platform's Pub/Sub service facilitates asynchronous communication by decoupling event producers and consumers. Subscriptions are critical as they define message delivery to applications. Adversaries may delete subscriptions to disrupt services or evade detection. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the deletion event by checking the `event.dataset:gcp.audit` and `event.action:google.pubsub.v*.Subscriber.DeleteSubscription` fields to ensure the alert is valid.
-- Identify the user or service account responsible for the deletion by examining the `user.email` or `authenticationInfo.principalEmail` fields in the audit log entry.
-- Determine the time and date of the deletion event using the `event.start` or `timestamp` fields to understand the context and timeline of the activity.
-- Investigate the IP address and location from which the deletion request was made by reviewing the `requestMetadata.callerIp` field to identify any unusual access patterns.
-- Check for any other related activities by the same user or service account around the same time, such as other deletions or modifications, to assess if this is part of a broader attack.
-- Analyze the `resource.labels.subscription_id` field to identify which specific subscription was deleted and assess its importance and impact on the system.
-- Use Osquery to gather additional context on the system where the deletion was initiated. For example, run a query like `SELECT * FROM gcp_pubsub_subscriptions WHERE subscription_id = 'deleted_subscription_id';` to retrieve details about the subscription.
-- Review IAM policies and permissions associated with the user or service account to determine if the deletion was authorized or if there are excessive permissions that need to be addressed.
-- Cross-reference the deletion event with any recent changes in the environment, such as deployments or configuration changes, to identify potential causes or correlations.
-- Consult with relevant stakeholders or teams to gather additional context about the subscription's role and any potential business impact due to its deletion.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may lead to legitimate subscription deletions, which could be flagged as false positives. Users should verify if the deletion aligns with scheduled maintenance activities.
-- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Users can create exceptions for known scripts or service accounts responsible for these actions.
-- Development and testing environments often involve frequent creation and deletion of subscriptions. Users should consider excluding these environments from monitoring or setting up specific rules to differentiate between production and non-production activities.
-- Subscription deletions by authorized personnel for resource optimization or cost management purposes can also trigger alerts. Users should maintain a list of authorized personnel and cross-reference deletion events with their activities to confirm legitimacy.
-
-### Response and remediation
-
-- Immediately verify the legitimacy of the subscription deletion by checking with the responsible team or individual.
-- Contain the potential threat by temporarily suspending any related service accounts or credentials that may have been compromised.
-- Investigate the audit logs to identify any unauthorized access patterns or anomalies leading up to the deletion event.
-- Restore the deleted subscription from backups or recreate it using documented configurations to resume normal operations.
-- Escalate the incident to the security operations team if unauthorized access is confirmed, and initiate a full security incident response.
-- Implement enhanced logging policies to capture detailed access and modification events for Pub/Sub resources.
-- Integrate with a Security Information and Event Management (SIEM) system to automate alerting and correlation of suspicious activities.
-- Review and update access controls and permissions for Pub/Sub resources to ensure the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate and train relevant personnel on recognizing and responding to similar threats, leveraging MITRE ATT&CK framework insights for defense evasion tactics.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
index ef6307a582e..b0c2ba3b66a 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,52 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Topic Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Pub/Sub Topic Deletion
-
-Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between applications by decoupling event producers and consumers. Adversaries may delete topics to disrupt communication, impair defenses, or evade detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping to uncover potential malicious activity.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the deletion event by checking the `event.dataset:gcp.audit` and `event.action:google.pubsub.v*.Publisher.DeleteTopic` fields to ensure the alert is not a false positive.
-- Verify the `event.outcome:success` field to confirm that the deletion was successful and not an attempted action.
-- Identify the user or service account responsible for the deletion by examining the `user.name` or `serviceAccount` fields in the audit logs.
-- Check the `source.ip` field to determine the origin of the request and assess if it aligns with expected network activity.
-- Investigate the `timestamp` of the deletion event to understand the timing and correlate it with other activities in the environment.
-- Review the `resource.name` field to identify the specific topic that was deleted and assess its importance and impact on the system.
-- Use Osquery to gather additional context about the GCP environment. For example, run a query to list all remaining Pub/Sub topics: `SELECT * FROM gcp_pubsub_topics;` to understand the current state of the messaging service.
-- Examine related logs and events around the same timeframe to identify any suspicious activities or patterns that might indicate a broader attack.
-- Check for any recent changes in IAM policies or permissions that could have allowed unauthorized users to delete topics.
-- Collaborate with the application or service owners to understand the potential impact of the topic deletion and gather any additional context or insights they might have.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may lead to legitimate topic deletions, which can be mistaken for malicious activity. 
-- Automated scripts or tools used for managing Pub/Sub topics might delete topics as part of their normal operation, triggering false positives.
-- Development and testing environments often involve frequent creation and deletion of topics, which can generate noise in the detection system.
-- To manage these false positives, users can create exceptions for known maintenance periods or specific service accounts that perform regular topic deletions.
-- Implementing a whitelist of topics or service accounts that are expected to be deleted regularly can help reduce unnecessary alerts.
-- Monitoring the context of the deletion, such as the source IP or user agent, can help differentiate between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately verify the deletion event by cross-referencing with change management records to confirm if it was authorized.
-- Contain the incident by temporarily disabling any service accounts or credentials that were used to perform the deletion, if unauthorized.
-- Investigate the source of the deletion by reviewing audit logs for any unusual activity or access patterns leading up to the event.
-- Restore the deleted Pub/Sub topic from backups or recreate it using documented configurations to resume normal operations.
-- Escalate the incident to the security operations team if unauthorized access is confirmed, providing them with all relevant logs and findings.
-- Implement enhanced logging policies to ensure all Pub/Sub activities are captured with sufficient detail for future investigations.
-- Integrate Pub/Sub monitoring with a Security Information and Event Management (SIEM) system to enable real-time alerting and analysis.
-- Review and update access controls and permissions for Pub/Sub resources to ensure the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in detection and response processes, and update incident response plans accordingly.
-- Educate relevant teams on the importance of monitoring and securing Pub/Sub resources, emphasizing the potential impact of unauthorized deletions.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
index f5f8ff375e6..58c3e161484 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -20,50 +20,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Configuration Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Storage Bucket Configuration Modification
-
-Google Cloud Platform (GCP) storage buckets are essential for storing and managing data. They can be configured to control access and security settings. Adversaries may alter these configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful bucket configuration changes, signaling potential security threats by identifying unauthorized modifications.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the details of the event, focusing on the `event.dataset:gcp.audit` and `event.action:"storage.buckets.update"` fields to verify the specific configuration changes made.
-- Check the `event.outcome:success` field to ensure the modification was successful and not a failed attempt, which might indicate a different type of issue.
-- Identify the user or service account responsible for the change by examining the `user.name` or `user.email` fields in the audit logs.
-- Investigate the source IP address and location from which the change was made to determine if it aligns with expected activity patterns.
-- Review the timing of the configuration change to see if it coincides with any other suspicious activities or known attack patterns.
-- Examine the specific changes made to the bucket configuration, such as changes to access controls or permissions, to assess the potential impact on security.
-- Cross-reference the bucket name and project ID with known assets to determine the criticality and sensitivity of the data stored in the affected bucket.
-- Utilize Osquery to gather additional context on the environment. For example, run the following Osquery query to list all recent bucket configuration changes: `SELECT * FROM gcp_storage_buckets WHERE action = 'update' AND outcome = 'success';`
-- Check for any other recent alerts or anomalies in the environment that might indicate a coordinated attack or broader security incident.
-- Consult with relevant stakeholders or teams to verify if the change was authorized and documented as part of a legitimate business process or project.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or maintenance by authorized personnel can trigger this rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated processes: Some organizations use automated scripts or tools to update bucket configurations as part of their workflow. Identify these processes and exclude them from triggering alerts by whitelisting specific service accounts or automation tools.
-- Third-party integrations: External services or applications with legitimate access may modify bucket settings as part of their operation. Review and document these integrations, then configure exceptions for their actions to prevent false positives.
-- Policy updates: Changes in organizational security policies may require updates to bucket configurations. Ensure that these policy-driven changes are documented and excluded from alerts by correlating them with change management records.
-
-### Response and remediation
-
-- Immediately isolate the affected storage bucket to prevent further unauthorized access or data exfiltration.
-- Review the audit logs to identify the source and nature of the configuration change, focusing on the user or service account responsible for the modification.
-- Verify the integrity of the data within the bucket to ensure no unauthorized changes or deletions have occurred.
-- Revert the storage bucket configuration to its last known secure state using backup configurations or documented settings.
-- Conduct a thorough investigation to determine if the configuration change is part of a larger attack, correlating with other suspicious activities in the environment.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance departments to assess potential data breach implications.
-- Implement additional logging and monitoring policies to capture detailed access and modification events for storage buckets, enhancing future detection capabilities.
-- Integrate with security information and event management (SIEM) systems to automate alerting and response processes for similar incidents.
-- Apply hardening measures such as enforcing least privilege access, enabling bucket versioning, and implementing strong authentication mechanisms for accessing storage resources.
-- Educate and train staff on security best practices and the importance of maintaining secure configurations to prevent similar incidents in the future.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
index 1df8709608b..5aa2543b2d8 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Permissions Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Storage Bucket Permissions Modification
-
-Google Cloud Platform (GCP) storage buckets are used to store and manage data. Permissions are controlled via IAM policies, which define who can access or modify resources. Adversaries may exploit these permissions to gain unauthorized access or expose sensitive data. The detection rule monitors audit logs for successful changes to bucket permissions, signaling potential security risks or misconfigurations.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event details, focusing on the `event.dataset:gcp.audit` and `event.action:"storage.setIamPermissions"` fields to ensure the alert is valid and corresponds to a permissions change.
-- Identify the user or service account responsible for the permissions modification by examining the `user.name` or `user.email` fields in the audit logs.
-- Determine the specific changes made to the IAM policy by reviewing the `event.outcome:success` field and any associated details about the new permissions granted or removed.
-- Cross-reference the user or service account with known authorized personnel or services to assess if the change was expected or potentially malicious.
-- Investigate the timing of the permissions change to see if it coincides with any other suspicious activities or known incidents.
-- Check the history of permissions changes for the affected storage bucket to identify any patterns or repeated unauthorized modifications.
-- Use Osquery to gather additional context about the environment. For example, run a query to list all current IAM policies for the storage bucket: `SELECT * FROM gcp_iam_policies WHERE resource_name = 'projects/<project-id>/buckets/<bucket-name>';`.
-- Analyze any related network activity or access logs to determine if there was any unauthorized data access following the permissions change.
-- Review any recent changes in the organization's GCP environment or configurations that might explain the permissions modification.
-- Consult with the bucket owner or relevant stakeholders to verify if the permissions change was part of a legitimate business process or project.
-
-### False positive analysis
-
-- Routine administrative tasks: Changes made by authorized personnel during regular maintenance or updates can trigger the rule. To manage this, users can create exceptions for known maintenance windows or specific admin accounts.
-- Automated processes: Scheduled scripts or automated tools that modify bucket permissions as part of their operation may cause false positives. Users should identify these processes and exclude them from the rule by specifying their service accounts.
-- Third-party integrations: Some third-party services require permission changes to function correctly. Users should review and whitelist these services if they are deemed non-threatening.
-- Organizational policy updates: Changes in organizational policies that necessitate permission updates across multiple buckets can be mistaken for suspicious activity. Users can document and exclude these policy-driven changes by correlating them with internal change management records.
-
-### Response and remediation
-
-- Immediately review the IAM policy change to identify the user or service account responsible for the modification and verify if the change was authorized.
-- Revert any unauthorized or suspicious IAM permission changes to their previous state to prevent further unauthorized access.
-- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the period of unauthorized access.
-- Implement additional logging and monitoring for IAM changes on storage buckets to detect and alert on future unauthorized modifications.
-- Escalate the incident to the security operations team for further analysis and to determine if the incident is part of a larger attack campaign.
-- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of future unauthorized changes.
-- Conduct a security awareness session with administrators to reinforce the importance of careful IAM policy management and the potential risks of misconfigurations.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate IAM changes with other security events for enhanced threat detection.
-- Restore any affected systems or data to their last known good state if data integrity was compromised during the incident.
-- Implement additional security controls such as multi-factor authentication and conditional access policies to strengthen the security posture of GCP resources.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/access-control/iam-permissions"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
index 386e69d90f5..ae837651b9c 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Network Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Virtual Private Cloud Network Deletion
-
-Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, identifying potential malicious activities by correlating specific event actions and outcomes.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event by filtering for `event.dataset:gcp.audit` and `event.action:v*.compute.networks.delete` with `event.outcome:success` to ensure the alert is not a false positive.
-- Identify the user or service account responsible for the deletion by examining the `user.name` and `user.email` fields in the audit logs.
-- Check the timestamp of the deletion event to determine when the VPC network was deleted and correlate it with other activities in the environment.
-- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or suspicious access patterns.
-- Review the project and organization context by examining the `project.id` and `project.name` fields to understand the scope and potential impact of the deletion.
-- Analyze related events in the audit logs around the same timeframe to identify any preceding or subsequent suspicious activities, such as changes to IAM roles or permissions.
-- Use Osquery to gather additional context on the affected GCP environment. For example, run the following Osquery query to list recent changes in the GCP project: `SELECT * FROM gcp_audit_logs WHERE action = 'v*.compute.networks.delete' AND outcome = 'success';`
-- Check for any recent changes to IAM policies or roles that might have granted the necessary permissions for the VPC deletion.
-- Investigate whether there were any alerts or incidents reported by other security tools around the same time, which might indicate a broader attack campaign.
-- Consult with the project owner or relevant stakeholders to verify if the VPC deletion was authorized and gather any additional context or insights they might have.
-
-### False positive analysis
-
-- Routine maintenance or infrastructure changes: Organizations may regularly delete and recreate VPC networks as part of their infrastructure management or during scheduled maintenance. These actions, while legitimate, can trigger the detection rule. To manage this, users can create exceptions for specific projects or time frames where such activities are expected.
-- Automated deployment tools: Tools like Terraform or Google Cloud Deployment Manager might delete and recreate VPC networks as part of their automated workflows. Users should identify these tools and exclude their actions from triggering alerts by filtering based on service accounts or specific project IDs associated with these tools.
-- Testing environments: In development or testing environments, VPC networks may be frequently created and deleted as part of testing processes. Users can exclude these environments from the detection rule by using tags or labels that identify non-production environments.
-- User error: Accidental deletions by authorized users can occur, especially in environments with less stringent access controls. Implementing role-based access controls and monitoring for patterns of behavior can help distinguish between malicious and non-malicious deletions.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further unauthorized access or damage.
-- Review audit logs to confirm the deletion event and identify any associated suspicious activities or accounts.
-- Verify the identity and access permissions of users involved in the deletion to ensure they are legitimate and authorized.
-- Restore the deleted VPC network from backups or recreate it using documented configurations to resume normal operations.
-- Implement additional logging and monitoring for VPC network changes to detect and respond to future unauthorized deletions.
-- Escalate the incident to the security operations team for further investigation and to determine the full scope of the breach.
-- Conduct a root cause analysis to understand how the adversary gained access and deleted the VPC network.
-- Update access controls and permissions to follow the principle of least privilege, reducing the risk of unauthorized deletions.
-- Integrate threat intelligence feeds to enhance detection capabilities and stay informed about emerging threats related to VPC deletions.
-- Educate and train staff on security best practices and the importance of reporting suspicious activities promptly.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/vpc"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
index 57e88af4595..14e579912ce 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,51 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Route Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Virtual Private Cloud Route Creation
-
-In GCP, VPC routes dictate network traffic paths between VM instances and other destinations, both internal and external. Adversaries may exploit this by creating routes to reroute or intercept traffic, potentially evading defenses. The detection rule monitors audit logs for route creation actions, identifying suspicious activities that could indicate such abuse.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event dataset is `gcp.audit` and the event action is either `v1.compute.routes.insert` or `beta.compute.routes.insert` to ensure the alert is valid.
-- Identify the user or service account associated with the route creation by examining the `principalEmail` field in the audit log entry.
-- Check the `resourceName` field to determine the specific VPC and route that was created, and assess whether it aligns with expected network configurations.
-- Investigate the `request` field in the audit log to gather details about the route parameters, such as destination range and next hop, to understand the potential impact on network traffic.
-- Cross-reference the `sourceIP` field to identify the origin of the request and determine if it matches known IP addresses or locations associated with legitimate administrative activity.
-- Use Osquery to query the GCP environment for recent changes in network configurations. Example query: `SELECT * FROM gcp_vpc_routes WHERE creation_time > datetime('now', '-1 day');` to find any recent route creations.
-- Analyze historical audit logs for patterns of similar route creation activities by the same user or service account to identify potential malicious behavior.
-- Check for any recent changes in IAM policies or permissions that might have allowed unauthorized users to create routes.
-- Correlate the route creation event with other security alerts or anomalies in the environment to identify potential coordinated attack patterns.
-- Consult with the network or cloud infrastructure team to verify if the route creation was part of a planned change or if it deviates from standard operating procedures.
-
-### False positive analysis
-
-- Routine network configuration changes by authorized personnel can trigger the rule, as legitimate route creation is a common administrative task in managing cloud environments.
-- Automated deployment tools or scripts that create or modify routes as part of infrastructure provisioning or scaling activities may also generate alerts.
-- Scheduled maintenance activities that involve network reconfiguration might lead to false positives if not properly documented or communicated.
-- To manage these false positives, users can create exceptions for known and trusted sources of route creation, such as specific service accounts or IP addresses associated with legitimate administrative activities.
-- Implementing a review process for flagged events can help distinguish between benign and suspicious activities, ensuring that only genuine threats are escalated for further investigation.
-
-### Response and remediation
-
-- Immediately isolate the affected VPC to prevent further unauthorized traffic routing and potential data exfiltration.
-- Review the audit logs to identify the source and context of the route creation, focusing on user accounts and IP addresses involved.
-- Verify the legitimacy of the route by consulting with the network and security teams to determine if it aligns with expected network configurations.
-- Revoke any unauthorized access or permissions that allowed the route creation, and reset credentials for compromised accounts.
-- Remove the unauthorized route and restore the network configuration to its previous state to ensure normal traffic flow.
-- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed network and user activity, ensuring future incidents can be detected more efficiently.
-- Integrate threat intelligence feeds and anomaly detection tools to identify similar tactics, techniques, and procedures (TTPs) associated with MITRE ATT&CK T1562.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply network hardening measures, such as least privilege access controls and regular audits of network configurations, to prevent future unauthorized route creations.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
index 0a0dc22a3fd..b0b775a5f06 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,51 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Route Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Virtual Private Cloud Route Deletion
-
-In GCP, VPC routes dictate network traffic paths between VM instances and other destinations. Adversaries may delete these routes to disrupt network traffic, potentially evading defenses or impairing system operations. The detection rule monitors audit logs for successful route deletions, flagging potential malicious activity by identifying unusual or unauthorized changes in network configurations.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event by checking the `event.dataset:gcp.audit` and `event.action:v*.compute.routes.delete` fields to ensure the deletion was successful, as indicated by `event.outcome:success`.
-- Identify the user or service account responsible for the route deletion by examining the `user.name` or `user.email` fields in the audit logs.
-- Check the timestamp of the deletion event to determine when the route was deleted and correlate it with any other suspicious activities around the same time.
-- Investigate the source IP address from which the deletion request was made to determine if it aligns with known and authorized IP addresses.
-- Review the specific route details that were deleted, including the destination and next hop, to assess the potential impact on network traffic.
-- Examine the project and VPC network associated with the deleted route to understand the broader context and potential impact on the cloud environment.
-- Use Osquery to gather additional context by running a query to list all current routes in the affected VPC network: `SELECT * FROM gcp_vpc_routes WHERE network = '<affected-network-name>';`.
-- Check for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete routes.
-- Look for any other recent audit log entries related to network configuration changes to identify patterns or additional unauthorized activities.
-- Consult with the network or cloud infrastructure team to verify if the route deletion was part of a planned change or if it was unexpected.
-
-### False positive analysis
-
-- Routine maintenance or network reconfiguration activities by authorized personnel can trigger false positives. These activities often involve legitimate route deletions as part of network optimization or updates.
-- Automated scripts or tools used for infrastructure management may delete routes as part of their normal operation, leading to false alerts. Monitoring for patterns or schedules of such activities can help differentiate between benign and suspicious deletions.
-- Changes in network architecture, such as the decommissioning of certain VPCs or the migration of services, may necessitate route deletions. These should be documented and communicated to the security team to prevent unnecessary alerts.
-- To manage false positives, users can create exceptions for known and approved activities by maintaining a whitelist of authorized users or service accounts that regularly perform route deletions.
-- Implementing a change management process where all network changes, including route deletions, are logged and reviewed can help in distinguishing between legitimate and unauthorized actions.
-
-### Response and remediation
-
-- Immediately isolate affected systems to prevent further unauthorized access or disruption of network traffic.
-- Review audit logs to identify the source of the route deletion and determine if it was authorized or part of a larger attack.
-- Restore deleted routes using backup configurations or manually recreate them based on documented network architecture.
-- Conduct a thorough investigation to identify any additional unauthorized changes or suspicious activities in the network.
-- Escalate the incident to the security operations team and relevant stakeholders for further analysis and response.
-- Implement stricter access controls and permissions for managing VPC routes to prevent unauthorized deletions.
-- Enhance logging and monitoring policies to ensure comprehensive visibility into network configuration changes and access attempts.
-- Integrate threat intelligence feeds and anomaly detection tools to identify potential indicators of compromise related to route deletions.
-- Regularly review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
-- Apply network hardening measures, such as enabling multi-factor authentication and using service accounts with the least privilege, to reduce the risk of similar incidents.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
diff --git a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
index d1b4f8841e6..c1b0254c4f0 100644
--- a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
+++ b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Sink Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Logging Sink Modification
-
-In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule monitors audit logs for successful sink updates, flagging potential unauthorized modifications indicative of such malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `event.action` and `event.outcome` fields, confirming that the action was a successful `UpdateSink`.
-- Examine the `event.dataset` field to ensure the log entry is from `gcp.audit`, verifying the source of the alert.
-- Identify the user or service account associated with the `UpdateSink` action by reviewing the `user.name` or `user.email` fields in the audit log.
-- Check the `source.ip` or `source.location` fields to determine the origin of the request, which may provide insights into whether the action was performed from an unusual location.
-- Investigate the `destination` field in the log entry to identify the new export destination for the logging sink, assessing whether it is an authorized and expected location.
-- Review historical logs for the same `user.name` or `user.email` to identify any other suspicious activities or patterns of behavior.
-- Use Osquery to query the GCP environment for recent changes to logging sinks with a command like: `SELECT * FROM gcp_logging_sinks WHERE last_modified > date('now', '-1 day');` to identify any other recent modifications.
-- Cross-reference the `UpdateSink` action with any recent IAM policy changes to determine if there were any permissions granted that could facilitate unauthorized sink modifications.
-- Analyze the timeline of events leading up to the `UpdateSink` action to identify any preceding suspicious activities or anomalies.
-- Consult with the relevant GCP project owners or administrators to verify if the sink modification was authorized and aligns with expected changes or business needs.
-
-### False positive analysis
-
-- Routine administrative changes: Regular updates or maintenance by authorized personnel can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific time frames when maintenance is scheduled.
-- Automated processes: Some organizations use automated scripts or tools to update logging sinks as part of their cloud management strategy. Users should identify these processes and exclude them from triggering alerts by whitelisting the associated service accounts or IP addresses.
-- Integration with third-party services: When integrating GCP with third-party logging or monitoring services, sink modifications may occur. Users can handle these by verifying the legitimacy of the third-party service and excluding its associated actions from the rule.
-- Testing and development environments: Changes in non-production environments might be frequent and benign. Users can exclude specific projects or environments from the rule to reduce noise while ensuring production environments remain monitored.
-
-### Response and remediation
-
-- Immediately isolate the affected GCP project to prevent further unauthorized access or data exfiltration.
-- Review the audit logs to identify the source and scope of the sink modification, including the user account and IP address involved.
-- Revert the logging sink configuration to its original state to ensure logs are routed to the intended destinations.
-- Conduct a thorough investigation to determine if any data was exfiltrated and assess the impact on the organization.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
-- Implement stricter access controls and permissions for modifying logging sinks, ensuring only authorized personnel have access.
-- Enhance logging and monitoring policies to include alerts for any future modifications to logging sinks.
-- Integrate with a security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply hardening measures such as enabling multi-factor authentication (MFA) and regular audits of logging configurations to prevent similar incidents.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/export#how_sinks_work"]
diff --git a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
index ec13ab4b6fd..c999c7eebe1 100644
--- a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
+++ b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Role Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP IAM Role Deletion
-
-Google Cloud Platform's Identity and Access Management (IAM) system is crucial for defining permissions and access controls across cloud resources. Adversaries may exploit this by deleting IAM roles, thereby disrupting legitimate user access and potentially masking unauthorized activities. The detection rule monitors audit logs for successful role deletions, signaling potential misuse and enabling timely investigation.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event by checking the `event.dataset:gcp.audit` and `event.action:google.iam.admin.v*.DeleteRole` fields to ensure the deletion was successful, as indicated by `event.outcome:success`.
-- Identify the user or service account responsible for the deletion by examining the `user.name` or `principalEmail` fields in the audit logs.
-- Determine the time and date of the role deletion to establish a timeline of events by reviewing the `@timestamp` field.
-- Investigate the specific IAM role that was deleted by looking at the `resource.name` field to understand the permissions that were removed.
-- Check for any recent changes in IAM policies or permissions associated with the affected resources to identify potential unauthorized modifications.
-- Correlate the role deletion event with other logs or alerts around the same timeframe to identify any suspicious activities or patterns.
-- Use Osquery to gather additional context on the affected resources or accounts. For example, run the following Osquery command to list recent IAM role changes: `SELECT * FROM gcp_iam_policy WHERE action = 'DeleteRole' AND timestamp > 'YYYY-MM-DDTHH:MM:SSZ';`.
-- Investigate the network activity of the user or service account involved in the deletion to identify any unusual access patterns or connections.
-- Review the organization's change management records or communication logs to verify if the role deletion was authorized or part of a planned change.
-- Consult with relevant stakeholders or team members to gather additional context or insights regarding the role deletion and its potential impact on operations.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate role deletions may occur during regular maintenance or restructuring of IAM roles by authorized personnel. To manage these, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
-- Automated role management tools: Some organizations use automated tools or scripts to manage IAM roles, which might include role deletions as part of their normal operation. Users should identify these tools and exclude their activities from triggering alerts by whitelisting their service accounts or specific actions.
-- Role lifecycle management: In environments where roles are frequently created and deleted as part of a lifecycle management process, users can reduce false positives by setting up alerts only for roles that are critical or have been flagged for monitoring.
-- Testing and development environments: Role deletions in non-production environments might not indicate malicious activity. Users can exclude these environments from monitoring or adjust the sensitivity of alerts to focus on production environments where the impact of role deletion is more significant.
-
-### Response and remediation
-
-- Immediately contain the incident by revoking any active sessions and access tokens associated with the affected IAM role to prevent further unauthorized access.
-- Investigate the audit logs to identify the source of the role deletion, including the user or service account responsible, and assess whether it was a legitimate action or part of a malicious activity.
-- Restore the deleted IAM role by recreating it with the original permissions, ensuring that legitimate users regain access to necessary resources.
-- Escalate the incident to the security operations team if the deletion is determined to be unauthorized or part of a broader attack, providing them with all relevant logs and findings.
-- Implement enhanced logging policies to capture detailed IAM activity, including role creation, modification, and deletion events, to improve future detection and investigation capabilities.
-- Integrate with a Security Information and Event Management (SIEM) system to automate the monitoring and alerting of suspicious IAM activities, ensuring timely response to potential threats.
-- Conduct a thorough review of IAM policies and permissions to identify and remediate any overly permissive roles that could be exploited by adversaries.
-- Educate users and administrators on the importance of IAM security and the potential impact of unauthorized role deletions, promoting awareness and adherence to best practices.
-- Regularly audit IAM roles and permissions to ensure they align with the principle of least privilege, reducing the risk of misuse or accidental deletions.
-- Consider implementing multi-factor authentication (MFA) and conditional access policies to add an additional layer of security for accessing and managing IAM roles.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/understanding-roles"]
diff --git a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
index 0332fcd7d36..7f30b45a128 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,52 +23,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Service Account Deletion
-
-Service accounts in GCP are crucial for applications and VMs to perform authorized operations without user intervention. Adversaries may delete these accounts to disrupt services or remove access, impacting business operations. The detection rule monitors audit logs for successful service account deletions, identifying potential malicious activity by correlating specific actions and outcomes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.iam.admin.v*.DeleteServiceAccount`, and `event.outcome:success` to ensure the alert is valid and corresponds to a successful service account deletion.
-- Identify the specific service account that was deleted by examining the relevant fields in the audit log, such as `serviceAccountId` or `serviceAccountName`.
-- Determine the timestamp of the deletion event to establish a timeline and correlate it with other activities in the environment.
-- Investigate the user or service that initiated the deletion by reviewing the `actor` field in the audit log to understand if it was an expected or authorized action.
-- Check for any recent changes in IAM policies or permissions related to the deleted service account to identify potential misconfigurations or unauthorized access.
-- Analyze other audit logs around the same timeframe for any unusual or suspicious activities, such as failed login attempts or changes to other critical resources.
-- Use Osquery to gather additional context on the affected systems or applications. For example, run a query to list all service accounts and their current status: `SELECT * FROM gcp_service_accounts WHERE status = 'ACTIVE';` to verify if other accounts are impacted.
-- Investigate any recent deployments or changes in the environment that might have triggered the deletion, such as automated scripts or CI/CD pipeline activities.
-- Review communication channels and change management records to verify if the deletion was part of a planned maintenance or update.
-- Collaborate with the application or system owners to understand the potential impact of the service account deletion and gather insights into any ongoing issues or disruptions.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may lead to legitimate service account deletions, such as when accounts are no longer needed or are being rotated for security purposes.
-- Automated scripts or tools used for infrastructure management might delete service accounts as part of their normal operation, especially in environments with dynamic resource provisioning.
-- Service account deletions during organizational restructuring or project decommissioning can trigger alerts, even though these actions are planned and authorized.
-- To manage these false positives, users can create exceptions for known maintenance windows or specific projects where frequent deletions are expected.
-- Implementing a whitelist of service accounts that are regularly deleted as part of automated processes can help reduce noise in the detection system.
-- Users should regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Immediately contain the incident by revoking any remaining access that the deleted service account had to critical resources.
-- Investigate the audit logs to identify the source of the deletion request, including the user or system that initiated the action and the IP address used.
-- Verify if the deletion was authorized by checking with the relevant team or personnel responsible for managing service accounts.
-- Restore the deleted service account from a backup or recreate it with the same permissions to ensure continuity of operations.
-- Escalate the incident to the security operations team if unauthorized deletion is confirmed, and involve legal or compliance teams if necessary.
-- Implement additional logging policies to capture detailed actions related to service account management, including creation, modification, and deletion events.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate service account activities with other security events for enhanced monitoring.
-- Conduct a review of current IAM policies and permissions to ensure the principle of least privilege is enforced for service account management.
-- Educate and train staff on the importance of service account security and the potential impact of unauthorized deletions.
-- Consider implementing automated alerts for critical service account changes to enable rapid response to potential security incidents.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
index 05fb74405c4..034f249af9b 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Disabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Service Account Disabled
-
-In GCP, service accounts facilitate secure application interactions by authorizing API calls. Disabling these accounts can disrupt services, a tactic adversaries might use to impair operations. The detection rule monitors audit logs for successful disablement actions, signaling potential malicious interference by identifying when a service account is intentionally deactivated.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event details, focusing on `event.dataset:gcp.audit` to ensure the event source is accurate.
-- Verify the `event.action:google.iam.admin.v*.DisableServiceAccount` to confirm that the action taken was indeed a service account disablement.
-- Check the `event.outcome:success` field to ensure the disablement action was successful, indicating the account is currently disabled.
-- Identify the service account that was disabled by examining the specific service account ID or name in the audit logs.
-- Investigate the user or process that initiated the disablement by reviewing the actor's identity in the audit logs.
-- Correlate the timestamp of the disablement event with other logs to identify any preceding or subsequent suspicious activities.
-- Use Osquery to gather additional context on the affected service account by running a query such as: `SELECT * FROM gcp_service_accounts WHERE account_id = '<service_account_id>';` to retrieve details about the service account.
-- Assess the impact of the disabled service account by identifying the applications or services that rely on it for API calls.
-- Review IAM policies and permissions associated with the disabled service account to understand its access scope and potential impact.
-- Investigate any recent changes to IAM roles or permissions that might have facilitated the disablement action, looking for anomalies or unauthorized modifications.
-
-### False positive analysis
-
-- Routine maintenance activities: Service accounts may be disabled during scheduled maintenance or updates by administrators. To manage this, users can create exceptions for known maintenance periods or specific accounts frequently involved in such activities.
-- Decommissioning of services: When services or applications are retired, associated service accounts might be intentionally disabled. Users should document and exclude these decommissioning events from alerts to avoid false positives.
-- Security policy enforcement: Organizations may have policies that require periodic disabling of service accounts for security audits or compliance checks. Users can handle these by maintaining a list of accounts subject to such policies and excluding them from the detection rule.
-- Automated scripts or tools: Some automated processes might disable service accounts as part of their operation. Users should identify these scripts or tools and configure exceptions for their actions to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately verify the legitimacy of the service account disablement by checking with the account owner or relevant team.
-- Contain the potential threat by temporarily restricting access to critical resources that the disabled service account was associated with.
-- Investigate audit logs to identify any unauthorized access or suspicious activities leading up to the disablement event.
-- If malicious activity is confirmed, escalate the incident to the security operations team for further analysis and response.
-- Restore the disabled service account by re-enabling it and ensuring that its permissions are correctly configured to prevent unauthorized access.
-- Implement additional logging policies to capture detailed information on service account activities and access patterns.
-- Integrate with a Security Information and Event Management (SIEM) system to enhance real-time monitoring and alerting capabilities.
-- Conduct a review of all service accounts to ensure they follow the principle of least privilege and are necessary for current operations.
-- Educate relevant personnel on the importance of monitoring service account activities and recognizing signs of potential compromise.
-- Apply hardening measures such as enabling multi-factor authentication (MFA) for administrative actions and regularly rotating service account keys.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
index 2f7a1676ef8..cfc19dbb136 100644
--- a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Storage Bucket Deletion
-
-Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in cloud environments. Adversaries may target these buckets to delete critical data, causing operational disruptions. The detection rule monitors audit logs for deletion actions, identifying potential malicious activity by flagging unauthorized or suspicious bucket deletions, thus enabling timely incident response.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the deletion event by filtering for `event.dataset:gcp.audit` and `event.action:"storage.buckets.delete"`.
-- Identify the user or service account associated with the deletion by examining the `principalEmail` field in the audit logs.
-- Check the `resourceName` field to determine the specific storage bucket that was deleted.
-- Investigate the `requestMetadata.callerIp` field to identify the source IP address from which the deletion request originated.
-- Analyze the `timestamp` field to establish the exact time of the deletion and correlate it with other events or activities in the environment.
-- Verify if there are any other suspicious activities associated with the same user or service account around the time of the deletion.
-- Use Osquery to gather additional context on the system from which the deletion was initiated. Example query: `SELECT * FROM process_events WHERE cmdline LIKE '%gcloud%' AND time >= 'timestamp_of_deletion'`.
-- Check for any recent changes in IAM policies or permissions that might have allowed unauthorized access to the storage bucket.
-- Review any alerts or logs from other security tools that might indicate a broader attack or compromise.
-- Consult with relevant stakeholders or teams to gather additional context or insights regarding the deleted storage bucket and its importance to business operations.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may lead to legitimate bucket deletions, such as when a project is being decommissioned or data is being migrated to a different storage solution. Users should verify if the deletion aligns with scheduled maintenance activities.
-- Automated scripts or tools that manage cloud resources might delete buckets as part of their normal operation. Users can create exceptions for these actions by identifying and excluding specific service accounts or automation tools from the detection rule.
-- Development and testing environments often involve frequent creation and deletion of storage buckets. Users should consider excluding these environments from the detection rule to avoid unnecessary alerts.
-- Temporary buckets used for data processing or analysis might be deleted once the task is completed. Users can manage these false positives by tagging such buckets and configuring the detection rule to ignore deletions of tagged resources.
-
-### Response and remediation
-
-- Immediately isolate affected systems and accounts to prevent further unauthorized access or data loss.
-- Verify the deletion event by cross-referencing with internal change management records to confirm if it was authorized.
-- Conduct a thorough investigation to identify the source of the deletion, including reviewing access logs and identifying any compromised credentials.
-- Restore the deleted storage bucket from the most recent backup to minimize operational disruption.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response.
-- Implement enhanced logging and monitoring policies to capture detailed access and modification events for storage buckets.
-- Integrate with a security information and event management (SIEM) system to correlate events and detect similar threats in the future.
-- Review and update access controls and permissions for storage buckets to ensure the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to potential security threats, emphasizing the importance of reporting suspicious activities.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
diff --git a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
index dd91cafabd1..fbf52054537 100644
--- a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
+++ b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,54 +22,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Custom Role Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP IAM Custom Role Creation
-
-Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, enhancing security by adhering to the principle of least privilege. However, adversaries may exploit these roles to gain unauthorized access or escalate privileges. The detection rule monitors audit logs for successful custom role creation events, helping identify potential misuse by correlating them with known threat tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `gcp.audit` and the event action is `google.iam.admin.v*.CreateRole` with a successful outcome.
-- Examine the timestamp of the custom role creation event to determine when the activity occurred.
-- Identify the user or service account associated with the role creation by reviewing the `actor` field in the audit log.
-- Check the `request` field in the audit log to understand the permissions included in the newly created custom role.
-- Investigate the `resource` field to determine the project or organization where the custom role was created.
-- Correlate the custom role creation event with other recent IAM activities, such as role assignments or permission changes, to identify potential privilege escalation attempts.
-- Use Osquery to gather additional context on the involved user or service account. For example, run the following query to list recent IAM activities for the account:
-  ```sql
-  SELECT * FROM gcp_iam_policy_audit WHERE actor_email = '<user_email>' ORDER BY timestamp DESC LIMIT 10;
-  ```
-- Review the organization's IAM policy change history to identify any unusual patterns or unauthorized modifications.
-- Investigate any associated network or system logs for suspicious activities around the time of the custom role creation.
-- Consult with relevant stakeholders or the user involved to verify the legitimacy of the custom role creation and understand its intended purpose.
-
-### False positive analysis
-
-- Routine administrative tasks: Custom roles may be created as part of regular administrative activities to tailor permissions for new projects or teams. These actions are typically non-threatening and can be identified by correlating the role creation with authorized change management records.
-- Automated processes: Some organizations use automation tools to manage IAM roles, which may include the creation of custom roles. These processes should be documented and can be excluded from alerts by identifying the service accounts or automation tools involved.
-- Development and testing environments: Custom roles are often created in non-production environments for testing purposes. These environments can be excluded from monitoring by filtering based on project or environment tags.
-- Known service accounts: If certain service accounts are regularly involved in creating custom roles as part of their legitimate function, these can be added to an exception list to reduce noise.
-- Frequent role updates: In dynamic environments where roles are frequently updated to accommodate changing needs, it may be beneficial to establish a baseline of expected behavior and exclude these from alerts unless they deviate significantly from the norm.
-
-### Response and remediation
-
-- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action.
-- Contain the potential threat by temporarily disabling the custom role to prevent any unauthorized access or privilege escalation.
-- Verify the permissions assigned to the custom role and assess whether they align with the principle of least privilege.
-- Investigate the context of the role creation by checking for any recent changes in IAM policies or unusual activities associated with the involved accounts.
-- If unauthorized access is confirmed, revoke any sessions or tokens associated with the compromised accounts and reset their credentials.
-- Escalate the incident to the security operations team for a thorough investigation and to determine if further actions are needed.
-- Implement enhanced logging policies to capture detailed IAM activities and integrate with a Security Information and Event Management (SIEM) system for real-time monitoring.
-- Conduct a review of all custom roles in the environment to ensure they are necessary and properly scoped, removing any that are redundant or overly permissive.
-- Develop and enforce a policy for regular audits of IAM roles and permissions to prevent privilege creep and ensure compliance with security best practices.
-- Consider implementing additional security measures such as multi-factor authentication (MFA) and automated alerts for critical IAM changes to strengthen the security posture.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/understanding-custom-roles"]
diff --git a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
index ade127102ba..18048b305d9 100644
--- a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
+++ b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Service Account Key Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP IAM Service Account Key Deletion
-
-In GCP, service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries may delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aligning with MITRE ATT&CK's account manipulation techniques.
-
-### Possible investigation steps
-
-- Review the audit log entry details for the event.dataset:gcp.audit to confirm the deletion event and gather additional context such as timestamp, user identity, and source IP address.
-- Examine the event.action field to ensure it matches google.iam.admin.v*.DeleteServiceAccountKey, confirming the specific action of key deletion.
-- Check the event.outcome field to verify the success of the key deletion, ensuring the alert is not a false positive due to a failed attempt.
-- Identify the service account associated with the deleted key and determine its role and permissions within the GCP environment to assess potential impact.
-- Investigate the user or service account responsible for the deletion by reviewing the actor identity in the audit logs, focusing on any anomalies or unauthorized access patterns.
-- Cross-reference the timestamp of the key deletion with other security events or logs to identify any correlated suspicious activities or access attempts.
-- Utilize Osquery to query the GCP environment for recent changes to IAM policies or roles that might indicate broader account manipulation. Example query: `SELECT * FROM gcp_iam_policies WHERE action = 'DeleteServiceAccountKey' AND outcome = 'success';`
-- Analyze historical audit logs for patterns of key deletions or other IAM changes that could suggest a recurring issue or targeted attack.
-- Review the service account's usage history to determine if the deleted key was actively in use and identify any services or applications that may be affected.
-- Consult with relevant stakeholders or application owners to verify if the key deletion was authorized and part of a scheduled key rotation or if it was unexpected.
-
-### False positive analysis
-
-- Routine key rotation: Regularly scheduled key rotations by administrators or automated processes can trigger this detection rule. To manage this, users can create exceptions for known maintenance windows or specific service accounts involved in routine rotations.
-- Testing and development activities: In development environments, service account keys may be frequently created and deleted as part of testing processes. Users can exclude these environments from the detection rule or set up alerts with lower priority.
-- Decommissioning of services: When services are intentionally decommissioned, associated service account keys may be deleted. Users should document and verify these activities to differentiate them from malicious actions.
-- Automated security tools: Some security tools may automatically delete and recreate service account keys as part of their operations. Users should identify these tools and configure the detection rule to recognize and exclude their legitimate actions.
-
-### Response and remediation
-
-- Immediately contain the incident by revoking access for the compromised service account and disabling any associated applications to prevent further unauthorized access.
-- Investigate the audit logs to identify the source of the key deletion, including the user or service account responsible, and any associated IP addresses or locations.
-- Verify if any unauthorized changes or access occurred using the deleted key and assess the impact on the affected services and data.
-- Restore the service by creating a new service account key, updating the application configuration with the new key, and ensuring the application regains access to necessary resources.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems have been compromised.
-- Implement enhanced logging policies to capture detailed audit logs for all IAM activities, ensuring that key deletions and other critical actions are monitored in real-time.
-- Integrate with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious IAM activities, including key deletions.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply hardening measures by enforcing strict IAM policies, such as least privilege access, regular key rotation, and multi-factor authentication for sensitive operations.
-- Educate and train staff on security best practices and the importance of monitoring and responding to IAM-related alerts to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
index 352d205f731..07b969e6a80 100644
--- a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
+++ b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,50 +24,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Key Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Service Account Key Creation
-
-In GCP, service accounts enable applications to interact with Google APIs securely. They use keys for authentication, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. Malicious actors might create new keys to leverage existing permissions stealthily. The detection rule identifies successful key creation events, signaling potential misuse by monitoring specific audit logs.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `event.dataset:gcp.audit`, `event.action:google.iam.admin.v*.CreateServiceAccountKey`, and `event.outcome:success` to ensure the alert is valid and corresponds to a successful key creation event.
-- Identify the service account associated with the key creation by examining the audit log entry for details such as `serviceAccountId` and `serviceAccountEmail`.
-- Check the `principalEmail` field in the audit log to determine which user or service account initiated the key creation event.
-- Investigate the context of the key creation by reviewing the `timestamp` field to understand when the event occurred and correlate it with any other suspicious activities around the same time.
-- Analyze the `resourceName` field to identify the specific resource or project associated with the service account key creation.
-- Use Osquery to gather additional information about the service account and its permissions. For example, run the following Osquery query to list all service accounts and their associated keys: `SELECT * FROM gcp_service_account_keys WHERE service_account_email = '<serviceAccountEmail>';`.
-- Review the IAM policy for the project or resource to understand the permissions granted to the service account and assess if they align with expected usage.
-- Check for any recent changes in IAM roles or permissions for the service account by reviewing the audit logs for `event.action:google.iam.admin.v*.SetIamPolicy`.
-- Investigate any other recent key creation events for the same service account to determine if there is a pattern or repeated unauthorized activity.
-- Collaborate with the account owner or relevant stakeholders to verify if the key creation was authorized and necessary, and gather any additional context or explanations for the activity.
-
-### False positive analysis
-
-- Routine administrative tasks: Service account keys may be created as part of regular maintenance or deployment processes by authorized personnel. To manage these, users can create exceptions for known administrative activities by correlating key creation events with change management records or deployment logs.
-- Automated processes: Some automated systems or CI/CD pipelines might generate service account keys as part of their normal operation. Users can handle these by identifying and excluding key creation events associated with specific automated workflows or service accounts dedicated to these processes.
-- Testing environments: In development or testing environments, service account keys might be frequently created and deleted. Users can reduce false positives by excluding events from specific projects or environments that are designated for testing purposes.
-- Third-party integrations: Certain third-party tools or integrations may require the creation of service account keys to function correctly. Users should document and exclude these known integrations by maintaining an inventory of approved third-party services and their associated service accounts.
-
-### Response and remediation
-
-- Immediately revoke the newly created service account key to prevent unauthorized access and potential misuse.
-- Investigate the IAM audit logs to identify the user or service that created the key and assess if it was an authorized action.
-- Review the permissions associated with the affected service account to ensure they are aligned with the principle of least privilege.
-- Conduct a thorough review of recent activities performed by the service account to detect any suspicious or unauthorized actions.
-- Escalate the incident to the security operations team if the key creation is deemed unauthorized or malicious, and initiate an incident response process.
-- Implement logging policies to ensure all service account key creation events are logged and monitored in real-time for future detection.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate service account key creation events with other security events for enhanced threat detection.
-- Restore the system to its operational state by ensuring all unauthorized keys are revoked and legitimate keys are securely managed.
-- Harden the environment by enforcing key rotation policies and using Cloud Identity-Aware Proxy (IAP) to limit access to applications.
-- Educate and train relevant personnel on the risks associated with service account key management and the importance of adhering to security best practices.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/persistence_gcp_service_account_created.toml b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
index 1cf9858cb6a..b929f9b69a2 100644
--- a/rules/integrations/gcp/persistence_gcp_service_account_created.toml
+++ b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,51 +24,7 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 GCP Service Account Creation
-
-In GCP, service accounts enable applications and VMs to authenticate and interact with Google services securely. However, adversaries may exploit this by creating unauthorized service accounts to maintain persistence and evade detection. The detection rule monitors audit logs for successful service account creation events, helping identify potential misuse by correlating specific actions and outcomes.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event details, focusing on `event.dataset:gcp.audit` to ensure the event is related to GCP audit logs.
-- Verify the `event.action:google.iam.admin.v*.CreateServiceAccount` to confirm that the action was indeed a service account creation.
-- Check the `event.outcome:success` field to ensure the service account creation was successful.
-- Identify the user or service that initiated the service account creation by examining the `actor` field in the audit logs.
-- Investigate the context of the service account creation by reviewing the `request` and `response` fields in the audit logs for any unusual parameters or configurations.
-- Cross-reference the service account details with known legitimate service accounts to determine if the creation aligns with expected patterns or projects.
-- Use Osquery to gather additional context on the service account creation. For example, run the following query to list recent service account creations: `SELECT * FROM gcp_service_accounts WHERE creation_time > (NOW() - INTERVAL 1 DAY);`
-- Check for any associated IAM policy changes around the time of the service account creation to identify if the new account was granted elevated permissions.
-- Investigate any recent activity associated with the new service account, such as API calls or resource access, to identify potential misuse.
-- Collaborate with the relevant project or application owners to verify if the service account creation was authorized and aligns with current operational needs.
-
-### False positive analysis
-
-- Routine administrative tasks: Service accounts may be created as part of regular administrative operations, such as setting up new applications or services. To manage these, users can create exceptions for known administrative actions by correlating them with change management records or approved workflows.
-- Automated deployment processes: Continuous integration and deployment pipelines might automatically create service accounts. Users can handle these by identifying and excluding service account creation events linked to specific deployment tools or scripts.
-- Third-party integrations: Some third-party services require the creation of service accounts for integration purposes. Users should maintain a list of approved third-party services and exclude related service account creation events from alerts.
-- Testing and development environments: Service accounts are often created in non-production environments for testing purposes. Users can exclude these environments from monitoring or create specific rules that differentiate between production and non-production service account creation events.
-- Frequent legitimate service account creation: In environments with high service account turnover, such as those using microservices architectures, users can establish baseline patterns and exclude events that match these patterns from triggering alerts.
-
-### Response and remediation
-
-- Immediately review the audit logs to confirm the unauthorized creation of the service account and identify the source of the request.
-- Disable the suspicious service account to prevent further unauthorized access and actions.
-- Investigate the permissions and roles assigned to the service account to assess potential access and impact.
-- Check for any API calls or actions performed by the service account to identify any malicious activities.
-- Escalate the incident to the security operations team for further analysis and to determine if other systems or accounts have been compromised.
-- Implement additional logging and monitoring for service account activities to detect future unauthorized creations or actions.
-- Review and update IAM policies to ensure that only authorized personnel can create and manage service accounts.
-- Conduct a security review of the affected environment to identify and remediate any vulnerabilities that may have been exploited.
-- Restore the system to its operational state by re-enabling legitimate service accounts and ensuring all unauthorized changes are reverted.
-- Educate and train staff on the importance of monitoring and managing service accounts to prevent similar incidents in the future.
-
-## Setup
+note = """## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
index b6dcf20c21c..9b43b940301 100644
--- a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
+++ b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -30,49 +30,6 @@ query = '''
 configuration where event.dataset == "github.audit"
   and github.category == "protected_branch" and event.type == "change"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Protected Branch Settings Changed
-
-GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation.
-
-### Possible investigation steps
-
-- Review the audit log entry details to identify the user who made the changes to the protected branch settings, focusing on fields like `event.dataset`, `github.category`, and `event.type`.
-- Verify the user's recent activity on GitHub to determine if there are any other suspicious actions or patterns, such as multiple changes to security settings or unusual commit activity.
-- Check the timestamp of the change to see if it aligns with any known maintenance windows or authorized change periods.
-- Cross-reference the user's GitHub activity with internal logs to see if there are any corresponding access logs or anomalies, such as unusual login locations or times.
-- Investigate the specific changes made to the branch protection settings to understand the potential impact on the repository's security posture.
-- Consult with the repository owner or relevant team members to confirm if the changes were authorized and align with current security policies.
-- Use Osquery to gather additional context on the user's machine, such as recent processes or network connections, with a query like: `SELECT * FROM processes WHERE user = 'username' AND start_time > 'timestamp';`
-- Analyze any related pull requests or commits to the affected branch to identify if any unauthorized code changes were made following the settings modification.
-- Review any recent communications or tickets that might provide context or justification for the changes, such as planned feature releases or security audits.
-- Document all findings and observations in a centralized investigation report to facilitate further analysis or handoff to incident response teams if necessary.
-
-### False positive analysis
-
-- Changes made by authorized personnel during routine maintenance or updates can trigger false positives. To manage this, maintain a list of trusted users whose actions are expected and can be excluded from alerts.
-- Automated processes or scripts that update branch protection settings as part of a continuous integration/continuous deployment (CI/CD) pipeline may also cause false positives. Consider creating exceptions for these automated actions by identifying and excluding specific service accounts or IP addresses.
-- Organizational policy changes that require updates to branch protection settings might be flagged. Document these policy changes and adjust the detection rule to recognize them as legitimate.
-- Temporary adjustments to branch protection settings for specific projects or deadlines can be mistaken for unauthorized changes. Implement a process to log and approve these temporary changes, allowing them to be excluded from alerts.
-- Frequent changes by specific teams or projects that have a higher rate of legitimate modifications can be excluded by setting up tailored rules or thresholds for those specific contexts.
-
-### Response and remediation
-
-- Immediately review the audit logs to identify the user who made the changes to the protected branch settings and verify if the change was authorized.
-- Revert any unauthorized changes to the branch protection settings to restore the original security posture.
-- Temporarily restrict access to branch protection settings to a limited number of trusted administrators until the investigation is complete.
-- Conduct a thorough review of recent commits and merges to the affected branches to ensure no unauthorized code changes were introduced.
-- Notify the security team and relevant stakeholders about the incident and provide them with details of the unauthorized changes.
-- If malicious activity is confirmed, initiate a security incident response plan, including isolating affected systems if necessary.
-- Enhance logging and monitoring by integrating GitHub audit logs with a centralized security information and event management (SIEM) system for real-time alerts.
-- Implement additional security measures such as two-factor authentication and stricter access controls for repository settings.
-- Conduct a post-incident review to identify gaps in the current security posture and update policies and procedures accordingly.
-- Educate developers and administrators on the importance of branch protection settings and the potential risks of unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_app_deleted.toml b/rules/integrations/github/execution_github_app_deleted.toml
index 54271a2fac6..7bced445fa9 100644
--- a/rules/integrations/github/execution_github_app_deleted.toml
+++ b/rules/integrations/github/execution_github_app_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -24,49 +24,6 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 App Deleted
-
-GitHub Apps enhance automation and integration within repositories and organizations, facilitating seamless workflows. However, adversaries may exploit this by deleting apps to disrupt services or erase audit trails, potentially executing unauthorized actions. The detection rule monitors audit logs for app deletions, identifying suspicious activities linked to serverless execution tactics, thus safeguarding against such malicious interventions.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the deletion event by checking the `event.dataset` field for "github.audit" and `event.type` for "deletion".
-- Identify the specific GitHub app that was deleted by examining the `github.category` field for "integration_installation".
-- Determine the user or account responsible for the deletion by reviewing the `user.name` and `user.id` fields in the audit logs.
-- Check the timestamp of the deletion event to understand when the action took place and correlate it with other activities in the logs.
-- Investigate the IP address and location associated with the deletion event using the `source.ip` field to identify any unusual access patterns.
-- Review recent changes or activities in the affected repository or organization to assess any potential impact or unauthorized actions.
-- Cross-reference the deletion event with other security alerts or incidents around the same time to identify any related suspicious activities.
-- Use Osquery to gather additional context on the system where the deletion was initiated. Example query: `SELECT * FROM processes WHERE name LIKE '%git%' AND start_time > 'timestamp_of_deletion';`
-- Analyze the permissions and roles of the user who deleted the app to determine if they had the necessary authorization and if any privilege escalation occurred.
-- Consult with the repository or organization owners to verify if the deletion was authorized and gather any additional context or concerns they might have.
-
-### False positive analysis
-
-- Routine maintenance or updates by authorized personnel may trigger the GitHub App Deleted rule, as legitimate app deletions can occur during these processes.
-- Organizational policy changes or restructuring might lead to the removal of certain GitHub apps, which could be mistakenly flagged as suspicious activity.
-- Users can manage these false positives by creating exceptions for known maintenance periods or authorized personnel actions, ensuring that only unexpected deletions are flagged.
-- Implementing a whitelist of trusted apps and users can help reduce false positives by allowing deletions from these sources without triggering alerts.
-- Regularly reviewing and updating the list of exceptions based on organizational changes can help maintain the accuracy of the detection rule.
-
-### Response and remediation
-
-- Immediately review the audit logs to confirm the deletion of the GitHub app and identify the user or process responsible for the action.
-- Contain the incident by revoking access tokens and permissions associated with the deleted app to prevent further unauthorized actions.
-- Investigate the scope of the incident by checking for any unauthorized changes or actions performed by the app prior to its deletion.
-- Restore the deleted GitHub app from a backup or reconfigure it to ensure continuity of services and workflows.
-- Escalate the incident to the security team if malicious intent is suspected, providing them with all relevant logs and findings.
-- Implement enhanced logging policies to capture detailed events related to app installations, deletions, and modifications for future investigations.
-- Integrate with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious activities related to GitHub apps.
-- Review and update access controls and permissions for GitHub apps to ensure they follow the principle of least privilege.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate and train users on recognizing and reporting suspicious activities related to GitHub apps to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
index f9c94aee1b3..1d14e096df7 100644
--- a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
+++ b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,49 +35,6 @@ event.dataset:"github.audit" and event.category:"configuration" and event.action
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and
 github.repository_public:false
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 High Number of Cloned GitHub Repos From PAT
-
-Personal Access Tokens (PATs) facilitate programmatic access to GitHub repositories, enabling automation and integration. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive data. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific personal access token (PAT) involved in the unusual cloning activity.
-- Cross-reference the PAT with internal records to determine the owner and intended use of the token.
-- Analyze the `event.dataset`, `event.category`, and `event.action` fields to confirm the activity is related to `git.clone` operations on private repositories.
-- Check the `github.programmatic_access_type` field to verify if the access was through an "OAuth access token" or "Fine-grained personal access token" and assess the associated permissions.
-- Investigate the `github.repository_public` field to ensure the cloned repositories are indeed private, confirming the potential sensitivity of the data.
-- Examine the time frame of the cloning activity to understand the duration and frequency of the events, identifying any patterns or anomalies.
-- Use GitHub audit logs to trace back the IP addresses and locations from which the cloning requests originated, looking for any unusual or unauthorized access points.
-- Conduct a review of recent changes or updates to the repositories involved to identify any potential triggers or reasons for the cloning activity.
-- Utilize Osquery to gather additional context from the systems involved. For example, run an Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_of_interest>';` to identify any suspicious connections.
-- Collaborate with the repository owners and relevant stakeholders to gather insights into any recent activities or changes that might explain the cloning events, ensuring a comprehensive understanding of the situation.
-
-### False positive analysis
-
-- **Automated Backup Processes**: Organizations may have automated systems that regularly clone private repositories for backup purposes. These processes can trigger the detection rule due to the high volume of clone events. To manage this, users can create exceptions for known backup systems by identifying their associated PATs and excluding them from the rule.
-- **Continuous Integration/Continuous Deployment (CI/CD) Pipelines**: CI/CD tools often clone repositories to build and test code. If these tools use PATs, they might cause false positives. Users should identify PATs used by trusted CI/CD systems and exclude them from the detection rule to prevent unnecessary alerts.
-- **Development and Testing Activities**: During development sprints or testing phases, developers might clone repositories frequently. This can be mistaken for malicious activity. Users can mitigate this by setting time-based exceptions during known development periods or by excluding PATs associated with specific development teams.
-- **Third-party Integrations**: Some third-party services require access to repositories and may clone them as part of their functionality. Users should review and whitelist PATs used by trusted third-party services to avoid false positives.
-- **High-Volume User Activity**: In large organizations, certain users may have legitimate reasons to clone multiple repositories in a short time. Identifying these users and their associated PATs can help in creating exceptions to reduce false alerts.
-
-### Response and remediation
-
-- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access.
-- Notify the affected repository owners and stakeholders about the potential breach and advise them to review recent changes and access logs.
-- Conduct a thorough investigation to identify the source of the compromise, including reviewing access logs and identifying any unauthorized changes or data exfiltration.
-- Escalate the incident to the security team and, if necessary, involve legal and compliance teams to assess the impact and regulatory obligations.
-- Implement additional monitoring and alerting for unusual access patterns or cloning activities across all repositories.
-- Review and update access controls, ensuring that PATs are issued with the least privilege necessary and have expiration dates.
-- Educate users on secure handling of PATs, including avoiding hardcoding them in scripts and using environment variables instead.
-- Enhance logging policies to capture detailed access and activity logs, integrating them with a centralized security information and event management (SIEM) system for better analysis.
-- Consider implementing multi-factor authentication (MFA) for accessing sensitive repositories to add an additional layer of security.
-- Restore any affected systems or repositories to their last known good state, ensuring that any unauthorized changes are reverted and data integrity is maintained."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
index 463e2f42185..aeefde947c4 100644
--- a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
+++ b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/14"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,48 +34,6 @@ type = "threshold"
 query = '''
 signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 UEBA - Multiple Alerts from a GitHub Account
-
-User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify unusual patterns that may indicate compromised accounts. Adversaries might exploit GitHub by executing multiple unauthorized actions within a short period, such as using stolen credentials or personal access tokens (PATs). The detection rule flags accounts with multiple alerts in an hour, signaling potential misuse and enabling analysts to prioritize investigation and response.
-
-### Possible investigation steps
-
-- Review the alert details in the security information and event management (SIEM) system, focusing on the `signal.rule.tags` field to confirm the alert is related to GitHub UEBA and involves multiple alerts from the same account.
-- Check the `kibana.alert.workflow_status` field to ensure the alert is still open and requires investigation.
-- Identify the specific GitHub account associated with the alert and gather historical activity logs for this account to establish a baseline of normal behavior.
-- Analyze the timestamps of the alerts to determine the exact time window of the suspicious activity and correlate it with any known events or changes in the environment.
-- Investigate the types of actions or events that triggered the alerts to understand the nature of the potential compromise, such as unauthorized repository access or unusual API calls.
-- Use Osquery to gather additional context on the system or environment where the suspicious activity originated. For example, run an Osquery query to list recent GitHub API calls made from the system: `SELECT * FROM curl WHERE url LIKE '%github.com%' AND time > strftime('%s', 'now', '-1 hour');`
-- Cross-reference the GitHub account activity with other security logs, such as network or endpoint logs, to identify any related suspicious behavior or anomalies.
-- Check for any recent changes to the account's permissions or settings that could indicate unauthorized access or privilege escalation.
-- Investigate any associated IP addresses or geolocations involved in the alerts to determine if they are consistent with the user's typical access patterns or if they suggest a potential threat actor.
-- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation and facilitate further analysis if needed.
-
-### False positive analysis
-
-- Frequent legitimate activities by automated scripts or CI/CD pipelines can trigger multiple alerts within a short period, leading to false positives. Users should identify and document these scripts or pipelines to differentiate them from potential threats.
-- Developers or teams working on high-intensity projects may generate numerous alerts due to rapid code pushes or repository interactions. Establishing a baseline of normal activity for these users can help in distinguishing between expected behavior and potential threats.
-- Scheduled tasks or maintenance activities that involve multiple repository interactions can also result in false positives. Users can create exceptions for these known activities by setting specific time windows or user accounts that are exempt from triggering alerts.
-- Collaborations with external partners or contributors who have legitimate access to repositories might cause multiple alerts if their activity patterns differ from internal users. Regularly reviewing and updating access permissions and documenting expected behaviors can help manage these false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected GitHub account by revoking access tokens and changing passwords to prevent further unauthorized actions.
-- Conduct a thorough investigation to identify the scope of the compromise, including reviewing recent activity logs and identifying any unauthorized changes or data exfiltration.
-- Utilize GitHub's audit logs and integrate with SIEM tools to enhance visibility and trace the adversary's actions within the environment.
-- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if sensitive data has been accessed or modified.
-- Remediate any unauthorized changes by reverting code or configuration changes and ensuring that no malicious code remains in the repositories.
-- Implement additional security measures such as enabling two-factor authentication (2FA) for all users and enforcing strong password policies.
-- Enhance logging and monitoring by integrating GitHub with centralized logging solutions to ensure comprehensive visibility of user activities and potential threats.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent future incidents.
-- Consider implementing automated alerting and response mechanisms to quickly detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_new_github_app_installed.toml b/rules/integrations/github/execution_new_github_app_installed.toml
index 5512b4145ee..10754ac939c 100644
--- a/rules/integrations/github/execution_new_github_app_installed.toml
+++ b/rules/integrations/github/execution_new_github_app_installed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -30,49 +30,6 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "integration_installation.create"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 New GitHub App Installed
-
-GitHub Apps enhance functionality by integrating with repositories and organizations, often requiring permissions to access or modify data. Adversaries may exploit this by installing malicious apps to gain unauthorized access or control. The detection rule monitors audit logs for new app installations, flagging potential threats by identifying unauthorized or suspicious integrations.
-
-### Possible investigation steps
-
-- Review the audit logs to identify the specific GitHub App that was installed by examining the `event.action` field for "integration_installation.create".
-- Check the `user.name` field in the audit logs to determine who installed the app and verify if they have the appropriate permissions and role to do so.
-- Investigate the `github.app.name` field to gather more information about the app, including its purpose and the permissions it requests.
-- Cross-reference the app's permissions with your organization's security policies to ensure they align and do not pose a risk.
-- Look into the app's developer or vendor by researching the `github.app.owner` field to assess their reputation and trustworthiness.
-- Use Osquery to query the local system for any related processes or network connections initiated by the app. Example query: `SELECT * FROM processes WHERE name LIKE '%github%' OR path LIKE '%github%'`.
-- Check for any recent changes in the repositories or organization settings that could be linked to the app installation by reviewing the `event.dataset` field for related activities.
-- Analyze the `event.created` timestamp to determine if the app installation coincides with any other suspicious activities or alerts.
-- Consult with the team or individual who installed the app to understand the rationale behind its installation and verify its necessity.
-- Document all findings and context gathered during the investigation to aid in future reference and potential incident response activities.
-
-### False positive analysis
-
-- Known false positives for the New GitHub App Installed rule may include legitimate apps installed by trusted team members or automated processes that are part of regular operations. These installations might be flagged if they occur frequently or during unusual hours.
-- To manage these false positives, users can create exceptions for specific apps that are regularly installed and verified as safe. This can be done by maintaining a whitelist of trusted apps and updating it as necessary.
-- Another approach is to monitor the installation patterns and identify any recurring non-threatening behaviors, such as installations by specific users or teams, and exclude these from triggering alerts.
-- Users should also consider the context of the installation, such as whether it aligns with ongoing projects or initiatives, to determine if an alert is a false positive.
-- Implementing a review process for app installations can help in quickly identifying and excluding false positives, ensuring that only genuine threats are flagged for further investigation.
-
-### Response and remediation
-
-- Immediately review the permissions requested by the newly installed GitHub App to assess potential risks and determine if they align with organizational policies.
-- Verify the legitimacy of the app by checking its developer's reputation, user reviews, and any available security assessments.
-- Temporarily disable or uninstall the app if it is deemed suspicious or unauthorized to prevent further access or data modification.
-- Conduct a thorough audit of recent activities in the affected repositories and organization to identify any unauthorized changes or data access.
-- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
-- Escalate the issue to GitHub support if the app is confirmed to be malicious or if there is a need for further assistance in handling the incident.
-- Implement logging policies to capture detailed audit logs of app installations and other critical actions for future investigations.
-- Integrate security tools that can automatically monitor and alert on suspicious activities related to GitHub Apps and other integrations.
-- Restore any affected systems or repositories to their last known good state if unauthorized changes were detected.
-- Review and update organizational policies on app installations, ensuring only trusted and verified apps are allowed, and educate team members on the importance of scrutinizing app permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/impact_github_repository_deleted.toml b/rules/integrations/github/impact_github_repository_deleted.toml
index 1bcb8ec593e..da383c6b1d6 100644
--- a/rules/integrations/github/impact_github_repository_deleted.toml
+++ b/rules/integrations/github/impact_github_repository_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,48 +35,6 @@ type = "eql"
 query = '''
 configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Repository Deleted
-
-GitHub repositories are vital for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase evidence of unauthorized access, leading to data loss. The detection rule monitors GitHub audit logs for repository deletion events, flagging potential unauthorized actions for further investigation.
-
-### Possible investigation steps
-
-- Review the GitHub audit logs to confirm the repository deletion event by checking the `event.action` field for "repo.destroy".
-- Identify the user associated with the deletion by examining the `actor` field in the audit logs to determine if the action was performed by an authorized individual.
-- Check the `repository.name` field to understand which repository was deleted and assess its importance and sensitivity to the organization.
-- Investigate the `event.created` timestamp to establish the exact time of the deletion and correlate it with other activities or anomalies in the system.
-- Analyze the `actor.ip` field to verify the IP address from which the deletion was initiated and determine if it matches known IP addresses associated with the user.
-- Use Osquery to gather additional context on the user's recent activities. For example, run the following query to list recent GitHub actions by the same user: `SELECT * FROM github_events WHERE actor = '<actor_name>' ORDER BY created_at DESC LIMIT 10;`.
-- Cross-reference the deletion event with recent access logs to see if there were any unusual login attempts or access patterns around the time of the deletion.
-- Check for any recent changes in user permissions or roles that might have inadvertently allowed unauthorized access to delete the repository.
-- Review any recent communications or tickets related to the repository to determine if there was a legitimate reason for its deletion.
-- Consult with the repository's owner or key stakeholders to verify if the deletion was planned or if they have any insights into the event.
-
-### False positive analysis
-
-- Routine maintenance or cleanup activities by authorized personnel can trigger false positives when repositories are intentionally deleted as part of organizational housekeeping. Users can manage these by creating exceptions for known maintenance periods or specific user accounts responsible for such tasks.
-- Automated scripts or bots that manage repository lifecycles might delete repositories as part of their normal operation. To handle these, users can exclude actions performed by these scripts by identifying their unique user agents or tokens in the audit logs.
-- Deletion of test or temporary repositories that are frequently created and removed during development cycles can also result in false positives. Users can mitigate this by setting up filters to ignore deletions of repositories with specific naming conventions or tags that indicate their temporary nature.
-- Organizational restructuring or project completion may lead to legitimate repository deletions. Users should ensure that such actions are documented and communicated within the team, allowing for the creation of temporary exceptions during these periods.
-
-### Response and remediation
-
-- Immediately contain the incident by revoking access to the affected GitHub account and any associated API tokens to prevent further unauthorized actions.
-- Investigate the audit logs to identify the user or process responsible for the deletion and determine if it was an authorized action or a potential compromise.
-- If unauthorized access is confirmed, conduct a thorough review of all access logs and permissions to identify other potential security breaches or compromised accounts.
-- Restore the deleted repository from backups, if available, to minimize operational disruption and data loss.
-- Escalate the incident to the security team and relevant stakeholders, providing them with detailed findings and any indicators of compromise.
-- Implement enhanced logging and monitoring policies to capture detailed audit trails of all repository actions, ensuring future incidents can be detected and investigated promptly.
-- Integrate GitHub with a Security Information and Event Management (SIEM) system to automate the detection and alerting of suspicious activities.
-- Review and update access controls and permissions for all GitHub repositories to ensure the principle of least privilege is enforced.
-- Conduct a security awareness training session for all users to reinforce the importance of secure practices and recognizing potential phishing or social engineering attacks.
-- Regularly test and update the incident response plan to ensure readiness for future incidents, incorporating lessons learned from this event."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/persistence_github_org_owner_added.toml b/rules/integrations/github/persistence_github_org_owner_added.toml
index 68721c60a9b..3046b5e72be 100644
--- a/rules/integrations/github/persistence_github_org_owner_added.toml
+++ b/rules/integrations/github/persistence_github_org_owner_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,48 +34,6 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 New GitHub Owner Added
-
-GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation.
-
-### Possible investigation steps
-
-- Review the audit log entry details to confirm the event action is "org.add_member" and the permission level is "admin" to ensure the alert is valid.
-- Identify the user account that was added as an owner by examining the relevant fields in the audit log, such as `github.actor` and `github.target_user`.
-- Verify the identity and role of the user added as an owner by cross-referencing with internal HR or user management systems to determine if the addition was authorized.
-- Check the timestamp of the event to understand when the new owner was added and correlate this with any other suspicious activities around the same time.
-- Investigate the IP address and location from which the action was performed using the `source.ip` field to identify any anomalies or unexpected access patterns.
-- Review recent activity by the new owner account in the GitHub organization to identify any unauthorized changes or access to sensitive repositories.
-- Use Osquery to gather additional context on the system from which the action was performed. For example, run the following query to check for recent logins: `SELECT * FROM last WHERE username = '<new_owner_username>';`
-- Examine any recent changes to the organization's settings or repositories that could indicate malicious intent or unauthorized access.
-- Check for any other recent additions or changes to the organization's membership, especially those with elevated permissions, to identify potential patterns of compromise.
-- Collaborate with the organization's security team to gather additional context or insights from other security tools and logs that might indicate a broader security incident.
-
-### False positive analysis
-
-- Routine administrative actions: In some organizations, adding new owners may be a regular part of onboarding or restructuring processes. To manage this, users can create exceptions for specific accounts or time periods when these actions are expected.
-- Automated processes: Some organizations use automation tools that may add or modify owner roles as part of their workflow. Users should identify these tools and exclude their actions from triggering alerts by filtering based on known service accounts or automation identifiers.
-- Internal audits or security reviews: During internal audits or security reviews, additional owner roles might be temporarily assigned. Users can handle these by coordinating with the audit team and setting temporary exceptions for the duration of the review.
-- Organizational changes: Mergers, acquisitions, or departmental changes might necessitate the addition of new owners. Users should document these changes and adjust the detection rule to exclude known, legitimate changes during these periods.
-
-### Response and remediation
-
-- Immediately revoke the newly added owner's permissions to prevent further unauthorized access.
-- Conduct a thorough investigation to determine how the unauthorized addition occurred, reviewing audit logs and access patterns.
-- Verify the legitimacy of the new owner with the organization's management and confirm if the addition was intentional.
-- If a compromise is confirmed, reset credentials and review access permissions for all critical accounts within the organization.
-- Escalate the incident to the security team and relevant stakeholders to ensure awareness and coordinated response efforts.
-- Implement enhanced logging policies to capture detailed audit trails of administrative actions within the GitHub organization.
-- Integrate GitHub audit logs with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
-- Educate team members on security best practices and the importance of monitoring for unauthorized access attempts.
-- Review and update the organization's incident response plan to include specific procedures for handling GitHub-related security incidents.
-- Apply hardening measures such as enabling two-factor authentication for all users and regularly reviewing and updating access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/persistence_organization_owner_role_granted.toml b/rules/integrations/github/persistence_organization_owner_role_granted.toml
index 0e36f6948e0..fae3507ce48 100644
--- a/rules/integrations/github/persistence_organization_owner_role_granted.toml
+++ b/rules/integrations/github/persistence_organization_owner_role_granted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,50 +34,6 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Owner Role Granted To User
-
-In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating their privileges to maintain persistence or exfiltrate sensitive information. The detection rule identifies suspicious privilege escalations by monitoring audit logs for changes in member roles to 'admin', signaling potential unauthorized access.
-
-### Possible investigation steps
-
-- Review the audit log entry to confirm the event details, focusing on the `event.dataset`, `event.action`, and `github.permission` fields to ensure the alert is valid and corresponds to a role change to 'admin'.
-- Identify the user who was granted the owner role by examining the `user.name` and `user.id` fields in the audit log entry.
-- Determine the initiator of the role change by checking the `actor.name` and `actor.id` fields to see if the change was made by an authorized individual.
-- Cross-reference the timestamp of the event with other logs to identify any concurrent suspicious activities, such as failed login attempts or unusual repository access.
-- Check the user's recent activity in the organization to identify any anomalies or actions that could indicate malicious intent.
-- Investigate the user's account history for any previous suspicious activities or privilege escalations.
-- Use Osquery to gather additional context on the user's machine, such as running the query: `SELECT * FROM processes WHERE user = '<user.name>';` to identify any unusual processes or connections.
-- Review the organization's member list and permissions to ensure no other unauthorized changes have been made.
-- Consult with the organization's administrators to verify if the role change was expected or authorized.
-- Document all findings and observations to provide a comprehensive overview of the investigation for further analysis or escalation if needed.
-
-### False positive analysis
-
-- Legitimate role changes: In some organizations, it is common for certain users to be granted the owner role temporarily for administrative tasks. These changes can be considered false positives if they are part of regular operations.
-- Automated processes: Some organizations use automated scripts or bots to manage user roles, which might trigger the detection rule. These should be reviewed to ensure they are authorized and documented.
-- Organizational restructuring: During periods of restructuring or mergers, role changes might occur frequently and could be mistaken for unauthorized access.
-- To manage these false positives, users can create exceptions for known and documented role changes by maintaining a list of authorized personnel who can be granted the owner role.
-- Implementing a review process for role changes can help in quickly identifying and excluding non-threatening behaviors from triggering alerts.
-- Regularly update and audit the list of exceptions to ensure it reflects current organizational policies and personnel changes.
-
-### Response and remediation
-
-- Immediately revoke the unauthorized owner role to prevent further access and potential damage.
-- Conduct a thorough investigation to determine how the privilege escalation occurred, reviewing audit logs and access patterns.
-- Verify the integrity of critical repositories and settings to ensure no unauthorized changes have been made.
-- Notify the security team and relevant stakeholders about the incident for awareness and further action.
-- Escalate the incident to higher management if the breach is confirmed to be part of a larger attack or if sensitive data has been compromised.
-- Implement additional logging and monitoring to capture detailed access and modification events for future investigations.
-- Integrate with security information and event management (SIEM) systems to enhance real-time detection and response capabilities.
-- Review and update access control policies to enforce the principle of least privilege and reduce the risk of future privilege escalations.
-- Conduct a security awareness session for organization members to educate them on recognizing and reporting suspicious activities.
-- Apply hardening measures such as enabling two-factor authentication for all users and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
index 1b31a35f4b7..5af838db9fc 100644
--- a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
+++ b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/21"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -24,51 +24,7 @@ interval = "10m"
 language = "eql"
 license = "Elastic License v2"
 name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
-
-Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If these keys are shared via links without proper restrictions, they can be accessed by unauthorized users. Adversaries exploit this by using rogue links to obtain keys, potentially compromising data security. The detection rule identifies suspicious activities by monitoring anonymous access to key files, focusing on actions like viewing or downloading, and flags files with specific extensions indicative of encryption keys.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file extension matches those indicative of encryption keys, as specified in the query (e.g., "pem", "key", "pfx").
-- Verify the event.action field to determine the specific action taken (e.g., "view", "copy", "download") and assess the potential impact of the action.
-- Check the google_workspace.drive.visibility field to confirm that the file was shared with "people_with_link", indicating it was accessible to anyone with the link.
-- Investigate the source.user.email field to ensure it is empty, confirming the access was anonymous.
-- Cross-reference the file name and path with internal records to identify the owner and intended access permissions of the file.
-- Use Google Workspace audit logs to trace any recent changes to the file's sharing settings or access permissions.
-- Conduct a search for other files with similar extensions in the same Google Workspace Drive to assess if there are additional files at risk.
-- Utilize Osquery to gather more context on the file access. Example query: `SELECT * FROM google_drive_files WHERE visibility = 'people_with_link' AND extension IN ('pem', 'key', 'pfx') AND user_email = '';`
-- Analyze historical access patterns to the file to identify any previous unauthorized access attempts or changes in access patterns.
-- Collaborate with the file owner to understand the necessity of the current sharing settings and gather insights into any recent activities that might have led to the exposure.
-
-### False positive analysis
-
-- **Shared Team Resources**: Files containing encryption keys might be shared among team members using links for collaborative purposes. If these links are accessed by team members who are not logged into their Google accounts, it could trigger a false positive. To manage this, ensure that team members are logged in when accessing shared resources or create exceptions for specific shared links known to be safe.
-- **Automated System Access**: Some systems or scripts may access encryption key files using anonymous links for automated processes. These accesses can be mistaken for unauthorized activity. To handle this, document and whitelist known automated processes that require such access.
-- **Third-party Integrations**: Certain third-party applications may require access to encryption keys stored in Google Workspace Drive. If these applications use anonymous links, they might be flagged as suspicious. Users should verify and whitelist trusted third-party applications that need access to these files.
-- **Testing and Development**: During testing or development phases, encryption keys might be shared via links for convenience. These activities can be misinterpreted as malicious. To mitigate this, establish a separate environment for testing and development with its own set of rules or exceptions.
-- **Expired Employee Access**: Former employees might still have access to shared links if not properly revoked. This can lead to false positives if they access files anonymously. Regularly audit and update access permissions to prevent this issue.
-
-### Response and remediation
-
-- Immediately revoke access to the shared link for the identified encryption key file to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the extent of the exposure, including identifying any other files accessed by the anonymous user and reviewing access logs for suspicious activities.
-- Notify the affected parties and stakeholders about the potential data breach and the steps being taken to mitigate the risk.
-- Change the encryption keys that were accessed and update any systems or services that rely on these keys to prevent unauthorized access.
-- Implement access controls to ensure that sensitive files, such as encryption keys, are only shared with specific users and not via public links.
-- Enable detailed logging and monitoring for Google Workspace activities to detect and respond to similar incidents in the future.
-- Integrate Google Workspace with a Security Information and Event Management (SIEM) system to enhance threat detection and response capabilities.
-- Review and update the organization's data sharing policies to include guidelines on securely sharing sensitive information.
-- Conduct a security awareness training session for employees to educate them on the risks of sharing sensitive files via public links and best practices for data protection.
-- Consider implementing additional security measures such as Data Loss Prevention (DLP) tools to automatically detect and prevent the sharing of sensitive information.
-
-## Setup
+note = """## Setup
 
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
index b601bd9acf5..35730889fc6 100644
--- a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
+++ b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/30"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -23,52 +23,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "First Time Seen Google Workspace OAuth Login from Third-Party Application"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Time Seen Google Workspace OAuth Login from Third-Party Application
-
-OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access and privileges. The detection rule identifies unusual OAuth logins by monitoring first-time authorizations from third-party apps, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific third-party application involved by examining the `google_workspace.token.client.id` field.
-- Verify the legitimacy of the third-party application by researching the client ID and checking if it is a known or trusted application.
-- Check the `google_workspace.token.scope.data` field to understand the permissions and data access requested by the application, assessing if they align with expected usage.
-- Investigate the user account associated with the OAuth login to determine if the login aligns with their typical behavior or if it appears suspicious.
-- Examine historical login patterns for the user to identify any anomalies or deviations from their normal activity.
-- Use Osquery to gather additional context on the user's device, such as running processes or network connections, with a query like: `SELECT * FROM processes WHERE user = '<username>';`.
-- Cross-reference the event timestamp with other security logs to identify any concurrent suspicious activities or anomalies.
-- Check for any recent changes in user permissions or roles that might have been exploited by the third-party application.
-- Investigate if there have been any recent phishing attempts or credential leaks that could have compromised the user's credentials.
-- Collaborate with the user to confirm whether they authorized the application and if they recognize the activity as legitimate.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate third-party applications are authorized for the first time by users, such as productivity tools or integrations that enhance Google Workspace functionality.
-- Users can handle these false positives by creating exceptions for applications that are frequently used and verified as safe, ensuring they do not trigger alerts in the future.
-- Regularly review and update the list of trusted applications to include new tools that are widely adopted within the organization, reducing unnecessary alerts.
-- Implement a process for users to report and verify new applications they intend to use, allowing security teams to pre-approve these applications and prevent false positives.
-- Consider the context of the OAuth login, such as the time, location, and user behavior, to differentiate between legitimate and potentially malicious activities.
-- Use historical data to identify patterns of legitimate OAuth logins, which can help refine detection rules and minimize false positives.
-
-### Response and remediation
-
-- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access.
-- Conduct a thorough investigation to determine if any sensitive data was accessed or modified by the third-party application.
-- Review the permissions granted to the third-party application and assess whether they align with the principle of least privilege.
-- Notify affected users and relevant stakeholders about the potential security incident and provide guidance on monitoring for unusual activity.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems are compromised.
-- Implement enhanced logging and monitoring for OAuth activities in Google Workspace to detect similar incidents in the future.
-- Integrate threat intelligence feeds to correlate OAuth activity with known malicious indicators and improve detection capabilities.
-- Restore any affected systems or data to their last known good state, ensuring that any unauthorized changes are reversed.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Educate users on the risks associated with third-party applications and the importance of scrutinizing permissions before granting access.
-
-## Setup
+note = """## Setup
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 ### Important Information Regarding Google Workspace Event Lag Times
 - As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
diff --git a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
index 30372f2c3e2..a1022b5fa15 100644
--- a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
+++ b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -24,50 +24,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Google Workspace Suspended User Account Renewed"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Google Workspace Suspended User Account Renewed
-
-Google Workspace allows administrators to manage user accounts, including suspending and unsuspending them. Adversaries may exploit this by unsuspending accounts to regain access to an organization. The detection rule monitors for unsuspension actions within the IAM category, alerting analysts to potential unauthorized access attempts by identifying when a suspended account is reactivated.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.dataset is "google_workspace.admin" and the event.category is "iam" with the event.action "UNSUSPEND_USER" to ensure the alert is valid.
-- Identify the user account that was unsuspended by examining the specific user details in the alert, such as user.email or user.name.
-- Check the timestamp of the unsuspension event to determine when the action occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the actor responsible for the unsuspension by reviewing the admin.email or admin.name fields to determine if the action was performed by an authorized administrator.
-- Analyze the user's account history to identify any previous suspicious activities or patterns that might indicate compromise.
-- Use Google Workspace audit logs to search for any other recent administrative actions performed by the same actor to identify potential patterns of unauthorized access.
-- Cross-reference the unsuspended user account with recent login activity to determine if there have been any successful logins post-unsuspension, especially from unusual locations or devices.
-- Utilize Osquery to gather additional context on the unsuspended account by running a query such as: `SELECT * FROM google_workspace_users WHERE email = 'user@example.com';` to retrieve detailed user information and status.
-- Investigate any recent changes to the organization's IAM policies or permissions that might have allowed unauthorized unsuspension actions.
-- Collaborate with the IT or security team to review any recent changes in administrative roles or permissions that could have inadvertently allowed unauthorized access to user management functions.
-
-### False positive analysis
-
-- Routine administrative actions: Legitimate IT administrators may unsuspend user accounts as part of regular account management tasks, such as when an employee returns from leave. To manage these, organizations can create exceptions for known administrative actions by whitelisting specific administrator accounts or IP addresses.
-- Automated processes: Some organizations may have automated workflows that unsuspend accounts based on predefined criteria, such as a scheduled return date for employees. These processes can be excluded from alerts by identifying and excluding the specific automated system accounts or scripts involved.
-- User error: Occasionally, an account may be unsuspended by mistake due to human error. To handle these, organizations can implement a review process for unsuspension actions, ensuring that any unsuspension is verified by a second administrator before being excluded from alerts.
-- Third-party integrations: Certain third-party applications integrated with Google Workspace may have permissions to unsuspend accounts as part of their functionality. To address this, organizations should review and document all third-party applications with such permissions and exclude their actions from alerts if deemed non-threatening.
-
-### Response and remediation
-
-- Immediately suspend the reactivated user account to prevent further unauthorized access.
-- Review audit logs to identify who performed the unsuspension action and assess if it was authorized.
-- Investigate any recent activities associated with the reactivated account to determine if any sensitive data was accessed or modified.
-- Change passwords and enforce multi-factor authentication for the affected account and any other accounts accessed by the adversary.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems were compromised.
-- Implement stricter access controls and review permissions for user accounts to minimize the risk of unauthorized actions.
-- Enhance logging policies to ensure detailed tracking of account management activities, including suspensions and unsuspensions.
-- Integrate Google Workspace with a Security Information and Event Management (SIEM) system to improve real-time monitoring and alerting capabilities.
-- Conduct a security awareness training session for administrators to reinforce the importance of account management best practices.
-- Review and update incident response plans to incorporate lessons learned from the incident and improve future response efforts.
-
-## Setup
+note = """## Setup
 
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
index 40bdc6e19c0..50e54311ef7 100644
--- a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
+++ b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,53 +23,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Denied Service Account Request"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Denied Service Account Request
-
-Kubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow a consistent access pattern. However, adversaries can exploit compromised credentials to make unauthorized API requests, aiming to discover or manipulate resources. The detection rule identifies such anomalies by flagging denied requests from service accounts, indicating potential misuse or compromise.
-
-### Possible investigation steps
-
-- Review the specific audit log entry that triggered the alert, focusing on the `event.dataset` field to confirm it is from "kubernetes.audit_logs".
-- Identify the service account involved by examining the `kubernetes.audit.user.username` field to determine which service account made the unauthorized request.
-- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm the request was indeed "forbid" and not a false positive.
-- Investigate the source IP and user agent from the audit logs to determine where the request originated from and what tool or application was used.
-- Cross-reference the service account with known deployments and pods to understand its typical usage and permissions.
-- Use Osquery to list all pods and their associated service accounts to verify if the service account is being used by unexpected or unauthorized pods:
-  ```sql
-  SELECT name, namespace, service_account_name FROM kubernetes_pods WHERE service_account_name = '<compromised_service_account>';
-  ```
-- Examine recent changes or deployments in the cluster that might have affected the service account's permissions or behavior.
-- Review the cluster's RoleBindings and ClusterRoleBindings to ensure the service account's permissions have not been altered unexpectedly.
-- Check for any recent access or modification to the service account's secrets or tokens that could indicate credential compromise.
-- Analyze historical audit logs for any patterns of similar unauthorized requests from the same or different service accounts to identify potential broader issues.
-
-### False positive analysis
-
-- Service accounts used in automated testing or development environments may generate denied requests as part of their normal operation, leading to false positives. Users can handle these by creating exceptions for specific service accounts known to exhibit this behavior.
-- Misconfigured service accounts that lack necessary permissions might trigger the rule. Regular audits and proper configuration management can help identify and rectify these issues, reducing false positives.
-- Service accounts involved in legitimate but unusual operations, such as temporary maintenance tasks, might be flagged. Users should document these operations and adjust the detection rule to exclude these specific activities.
-- In some cases, service accounts might be involved in legitimate access attempts that are denied due to temporary network issues or API server misconfigurations. Monitoring network stability and ensuring API server configurations are correct can help mitigate these occurrences.
-
-### Response and remediation
-
-- Immediately isolate the affected service account by revoking its credentials or tokens to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the compromise, including reviewing audit logs for any other suspicious activities associated with the service account.
-- Identify and analyze the source of the unauthorized request to understand how the adversary gained access, focusing on potential vulnerabilities or misconfigurations in the cluster.
-- Escalate the incident to the security operations team and relevant stakeholders to ensure awareness and coordinated response efforts.
-- Implement enhanced logging policies to capture detailed audit logs for all service account activities, ensuring that future unauthorized access attempts are detected promptly.
-- Integrate security tools and platforms, such as SIEM systems, to automate the detection and alerting of anomalous service account behaviors.
-- Restore the system to its operational state by reissuing new credentials or tokens for the affected service account and ensuring all unauthorized changes are reverted.
-- Apply hardening measures by enforcing the principle of least privilege for service accounts, ensuring they have only the necessary permissions to perform their functions.
-- Conduct a post-incident review to identify lessons learned and update incident response plans and security policies accordingly.
-- Leverage MITRE ATT&CK framework to understand potential adversary tactics and techniques, enhancing threat detection and response capabilities for future incidents.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
index c2ef47bed53..d0589a903d9 100644
--- a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
+++ b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/30"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Suspicious Self-Subject Review"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Suspicious Self-Subject Review
-
-Kubernetes uses Self-Subject Access Review APIs to allow entities to check their own permissions, a feature typically unnecessary for service accounts or nodes. Adversaries exploiting compromised credentials might use these APIs to assess their access rights, aiding lateral movement or privilege escalation. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific service account or node involved by examining the `kubernetes.audit.user.username` or `kubernetes.audit.impersonatedUser.username` fields.
-- Check the `kubernetes.audit.objectRef.resource` field to confirm whether the API call was for `selfsubjectaccessreviews` or `selfsubjectrulesreviews`.
-- Investigate the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the request was indeed allowed, indicating a successful permission check.
-- Analyze the `kubernetes.audit.verb` field to verify that the action was a `create` operation, which is necessary for initiating a self-subject review.
-- Correlate the timestamp of the alert with other logs to identify any preceding or subsequent suspicious activities involving the same service account or node.
-- Use Osquery to gather additional context about the node or pod from which the request originated. Example query: `SELECT * FROM kubernetes_pods WHERE name = '<pod_name>' AND namespace = '<namespace>';`
-- Examine the Kubernetes RBAC (Role-Based Access Control) settings to determine the permissions associated with the service account or node in question.
-- Investigate any recent changes to the service account or node's permissions or roles that might explain the unusual behavior.
-- Check for any known vulnerabilities or security advisories related to Kubernetes that might be relevant to the observed behavior.
-- Review historical logs to determine if similar self-subject review requests have been made by the same or other service accounts or nodes, indicating a pattern of behavior.
-
-### False positive analysis
-
-- Service accounts or nodes that are part of automated processes or CI/CD pipelines might legitimately use self-subject access review APIs to verify permissions before executing tasks. These should be reviewed and, if deemed non-threatening, can be excluded from the rule by adding exceptions for specific service accounts or node identities.
-- Monitoring or security tools that integrate with Kubernetes may perform self-subject access reviews as part of their normal operation to ensure they have the necessary permissions to function correctly. Identifying these tools and excluding their service accounts from the rule can reduce false positives.
-- During cluster setup or maintenance, administrators might temporarily use service accounts or nodes to verify permissions, which could trigger the rule. Documenting these activities and excluding the relevant accounts during these periods can help manage false positives.
-- In environments where role-based access control (RBAC) policies are frequently updated, service accounts might perform self-subject access reviews to adapt to new permissions. Regularly reviewing and updating the list of exceptions to include these accounts can help maintain the balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected service account or node to prevent further unauthorized access or lateral movement within the cluster.
-- Review Kubernetes audit logs to identify any other suspicious activities or API calls made by the compromised identity.
-- Revoke and rotate credentials or tokens associated with the compromised service account or node to prevent further misuse.
-- Conduct a thorough investigation to determine how the credentials were compromised and assess the extent of the breach.
-- Escalate the incident to the security operations team and involve relevant stakeholders to ensure a coordinated response.
-- Implement enhanced logging and monitoring for Kubernetes audit logs to detect similar suspicious activities in the future.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate Kubernetes events with other security data for comprehensive threat detection.
-- Apply Kubernetes Role-Based Access Control (RBAC) policies to limit permissions for service accounts and nodes, adhering to the principle of least privilege.
-- Restore the system to its operational state by verifying the integrity of the cluster and ensuring no unauthorized changes were made.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future resilience against similar threats.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
index 76b83a7372f..1c134a8e0b8 100644
--- a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
+++ b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/17"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -26,50 +26,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes User Exec into Pod"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes User Exec into Pod
-
-Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating debugging and management. However, adversaries can exploit this to gain unauthorized shell access, potentially exposing sensitive data. The detection rule identifies such attempts by monitoring audit logs for specific actions, ensuring any unauthorized access is promptly flagged for investigation.
-
-### Possible investigation steps
-
-- Review the audit log entry to confirm the 'exec' command was used by checking the `kubernetes.audit.objectRef.subresource` field for "exec".
-- Verify the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was indeed allowed, indicating a successful execution attempt.
-- Identify the user or service account responsible for the action by examining the `kubernetes.audit.user.username` field.
-- Determine the source IP address of the request using the `kubernetes.audit.sourceIPs` field to assess if it originates from a known or suspicious location.
-- Check the `kubernetes.audit.objectRef.name` field to identify the specific pod targeted by the exec command.
-- Investigate the `kubernetes.audit.verb` field to confirm the action was a "create" operation, indicating a new exec session was initiated.
-- Use Osquery to gather more context about the pod by running a query such as: `SELECT * FROM kubernetes_pods WHERE name = '<pod_name>';` replacing `<pod_name>` with the value from `kubernetes.audit.objectRef.name`.
-- Examine the `kubernetes.audit.metadata.creationTimestamp` to establish a timeline and correlate with other events or alerts.
-- Review the pod's role and permissions to understand the potential impact of unauthorized access, focusing on any secrets or sensitive data it may have access to.
-- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular maintenance or debugging activities by authorized personnel can trigger this rule. To manage this, create exceptions for known administrative accounts or specific namespaces where such activities are expected.
-- Automated scripts: Some automated processes or CI/CD pipelines may use the 'exec' command for legitimate purposes. Identify these scripts and exclude their associated service accounts or IP addresses from triggering alerts.
-- Monitoring and logging tools: Certain monitoring or logging solutions may use 'exec' to gather metrics or logs from pods. Whitelist these tools by their service accounts or specific pod labels to prevent false positives.
-- Development environments: In development or testing environments, developers may frequently use 'exec' for testing purposes. Consider excluding these environments by namespace or label to reduce noise in alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected pod to prevent further unauthorized access and data exposure.
-- Review Kubernetes audit logs to identify the source of the unauthorized 'exec' command and determine the scope of the breach.
-- Revoke any compromised credentials and access tokens associated with the affected pod and user accounts.
-- Conduct a thorough investigation to determine if any sensitive data was accessed or exfiltrated, and document findings for further analysis.
-- Escalate the incident to the security operations team and relevant stakeholders for awareness and additional support.
-- Implement stricter role-based access controls (RBAC) to limit the use of the 'exec' command to only trusted administrators.
-- Enhance logging policies to ensure comprehensive monitoring of all 'exec' command attempts and integrate with a SIEM for real-time alerting.
-- Apply security patches and updates to the Kubernetes environment to address any known vulnerabilities that may have been exploited.
-- Restore the affected pod from a known good backup to ensure system integrity and continuity of operations.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future resilience.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
index e4c358d7d19..2fd9df0a9e0 100644
--- a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
+++ b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Anonymous Request Authorized"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Anonymous Request Authorized
-
-Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. However, anonymous requests can occur, often for health checks. Adversaries might exploit this by using anonymous access to infiltrate clusters undetected. The detection rule identifies unauthorized anonymous access by monitoring audit logs for allowed requests from unauthenticated users, excluding common health endpoints.
-
-### Possible investigation steps
-
-- Review the audit logs to identify the specific unauthenticated user request that was authorized, focusing on the `kubernetes.audit.user.username` field to confirm if it matches "system:anonymous" or "system:unauthenticated".
-- Examine the `kubernetes.audit.requestURI` field to determine the exact resource or endpoint accessed, ensuring it is not one of the excluded health check endpoints like `/healthz`, `/livez`, or `/readyz`.
-- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to verify that the decision was indeed "allow", confirming unauthorized access.
-- Investigate the source IP address and user agent from the audit logs to identify the origin of the request and gather more context about the client making the request.
-- Cross-reference the timestamp of the unauthorized access with other logs and events to identify any correlated activities or anomalies in the cluster around the same time.
-- Use Osquery to gather more information about the nodes in the cluster. For example, run the following Osquery query to list all running pods and their associated namespaces: `SELECT name, namespace FROM kubernetes_pods;`.
-- Check for any recent changes in the cluster's RBAC (Role-Based Access Control) policies that might have inadvertently allowed anonymous access.
-- Review the cluster's network policies to ensure there are no misconfigurations that could allow unauthorized access from external sources.
-- Investigate any recent deployments or changes in the cluster that might have introduced vulnerabilities or misconfigurations.
-- Consult with the team responsible for the cluster to verify if there were any legitimate reasons for the anonymous access, such as testing or maintenance activities.
-
-### False positive analysis
-
-- Health checks and monitoring tools: Although the rule excludes common health endpoints like /healthz, /livez, and /readyz, other monitoring tools might access different endpoints anonymously, leading to false positives. Users should identify and exclude these specific endpoints in their environment.
-- Internal services or applications: Some internal services might be configured to use anonymous access for specific operations. Users should review these services and consider adding exceptions for known benign activities.
-- Misconfigured applications: Applications that are not properly configured might inadvertently make anonymous requests. Users should audit application configurations and adjust the rule to exclude these known benign requests.
-- Development and testing environments: In non-production environments, developers might use anonymous access for testing purposes. Users should differentiate between production and non-production environments and apply the rule accordingly to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by adversaries.
-- Review audit logs to identify the source and scope of the unauthorized anonymous access, focusing on any unusual patterns or repeated access attempts.
-- Revoke any unauthorized access tokens or credentials that may have been compromised during the incident.
-- Escalate the incident to the security operations team and, if necessary, involve incident response specialists to assist with a thorough investigation.
-- Implement stricter authentication and authorization policies, ensuring that anonymous access is limited to only necessary endpoints like /healthz, /livez, and /readyz.
-- Enhance logging policies to capture detailed audit logs, including user activities and access attempts, and integrate with a Security Information and Event Management (SIEM) system for real-time monitoring.
-- Conduct a thorough review of the cluster's security configurations, ensuring that Role-Based Access Control (RBAC) is properly configured to minimize permissions for anonymous users.
-- Restore the system to its operational state by applying patches and updates to the Kubernetes environment and any affected applications.
-- Implement network segmentation and micro-segmentation to limit the potential impact of unauthorized access within the cluster.
-- Educate and train the development and operations teams on security best practices and the importance of monitoring for unauthorized access attempts, leveraging MITRE ATT&CK framework insights for threat-specific context.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
index 2d7aa15a652..84e57ae7e00 100644
--- a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
+++ b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -29,51 +29,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Exposed Service Created With Type NodePort"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Exposed Service Created With Type NodePort
-
-Kubernetes NodePort services enable external access to pods by opening a port on each node, facilitating direct communication with the cluster. Adversaries may exploit this by configuring NodePort services to intercept or redirect traffic, bypassing security controls. The detection rule identifies such activities by monitoring audit logs for service creation or modification events with NodePort specifications, ensuring any unauthorized exposure is flagged for investigation.
-
-### Possible investigation steps
-
-- Review the Kubernetes audit logs to identify the source of the NodePort service creation or modification by examining the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields.
-- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and not denied, ensuring the alert is valid.
-- Identify the user or service account responsible for the action by analyzing the `kubernetes.audit.user.username` field in the audit logs.
-- Investigate the context of the service creation or modification by reviewing the `kubernetes.audit.requestObject.spec.type` field to confirm it is set to "NodePort".
-- Use Osquery to gather additional context about the nodes involved. For example, run the following query to list all services of type NodePort: `SELECT * FROM kubernetes_services WHERE type = 'NodePort';`
-- Examine the network policies in place to determine if there are any existing rules that could have been bypassed due to the NodePort configuration.
-- Review the cluster's role-based access control (RBAC) settings to ensure that only authorized users have permissions to create or modify services.
-- Analyze the logs for any unusual or unexpected traffic patterns directed towards the NodePort, which could indicate potential misuse or exploitation.
-- Cross-reference the NodePort service details with known legitimate services to determine if the creation or modification aligns with expected behavior.
-- Investigate any associated pods or applications that are exposed via the NodePort service to assess their security posture and potential vulnerabilities.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate administrative actions may involve creating or updating NodePort services for maintenance or deployment purposes. To manage these, users can create exceptions for specific user accounts or service accounts known to perform these tasks regularly.
-- Development and testing environments: In non-production environments, NodePort services might be frequently created for testing purposes. Users can exclude these environments from alerts by filtering based on namespace or labels associated with development and testing.
-- Automated deployment tools: Continuous integration and deployment tools might automatically create or modify NodePort services as part of their workflows. Users should identify these tools and exclude their activities by recognizing specific user agents or service accounts.
-- Internal services with external dependencies: Some internal services may require NodePort configurations to interact with external systems. Users can whitelist these services by specifying known IP ranges or service names that are expected to use NodePort.
-- Monitoring and logging tools: Certain monitoring or logging solutions might use NodePort services to collect data from the cluster. Users can manage these by identifying and excluding the specific tools or services involved in these activities.
-
-### Response and remediation
-
-- Immediately isolate the affected NodePort service to prevent further unauthorized access by removing or disabling the service.
-- Review Kubernetes audit logs to identify any unauthorized changes or suspicious activities related to NodePort services.
-- Verify the identity and permissions of the user or service account that created or modified the NodePort service to ensure it aligns with expected behavior.
-- Conduct a thorough investigation to determine if any data was accessed or exfiltrated through the exposed NodePort service.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems or services were compromised.
-- Implement network segmentation and firewall rules to restrict NodePort access to only trusted IP addresses and services.
-- Enhance logging policies to ensure comprehensive monitoring of Kubernetes audit logs, focusing on service creation and modification events.
-- Integrate security tools with Kubernetes to automate the detection and alerting of suspicious NodePort activities.
-- Restore the system to its operational state by reconfiguring services to use more secure access methods, such as LoadBalancer or Ingress, instead of NodePort.
-- Apply hardening measures by regularly reviewing and updating Kubernetes RBAC policies to minimize permissions and reduce the attack surface.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
index 4c74c8b6cd7..6b67122e530 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -26,50 +26,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostIPC"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Pod Created With HostIPC
-
-Kubernetes allows pods to share the host's IPC namespace, enabling access to shared memory and other IPC resources. While useful for certain applications, this can be exploited by attackers to access sensitive data or interfere with host processes. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the `event.dataset` field to ensure it matches "kubernetes.audit_logs".
-- Verify the authorization decision by checking the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed.
-- Examine the `kubernetes.audit.objectRef.resource` field to ensure the resource involved is a pod, and check the `kubernetes.audit.verb` field to determine if the action was a "create", "update", or "patch".
-- Investigate the `kubernetes.audit.requestObject.spec.hostIPC` field to confirm that host IPC was indeed enabled for the pod.
-- Cross-reference the `kubernetes.audit.requestObject.spec.containers.image` field to ensure the image used is not part of the known benign images, such as "docker.elastic.co/beats/elastic-agent:8.4.0".
-- Identify the user or service account responsible for the action by examining the `kubernetes.audit.user.username` field to determine if the action was performed by a legitimate user or service.
-- Use Osquery to gather more information about the pod and its containers. For example, run the following Osquery query to list all pods with host IPC enabled: `SELECT name, namespace, host_ipc FROM kubernetes_pods WHERE host_ipc = 1;`.
-- Check for any unusual or unauthorized processes running within the pod by querying the process table using Osquery: `SELECT pid, name, cmdline FROM processes WHERE pid IN (SELECT pid FROM process_namespaces WHERE ipc_namespace_id = (SELECT ipc_namespace_id FROM process_namespaces WHERE pid = <PID of the suspicious pod>));`.
-- Investigate the `/dev/shm` directory on the host and within the pod for any suspicious files or data that could indicate unauthorized access or data exfiltration.
-- Review the network activity associated with the pod to identify any unusual or unauthorized connections that could suggest lateral movement or data exfiltration attempts.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate applications require the use of the host IPC namespace for valid operational reasons, such as performance optimization or specific inter-process communication needs. These applications might include database systems or distributed computing frameworks that rely on shared memory for efficiency.
-- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to require host IPC access. This can be done by updating the detection rule to exclude additional trusted images or namespaces beyond the already excluded "docker.elastic.co/beats/elastic-agent:8.4.0".
-- Regularly review and update the list of exceptions to ensure that only verified and necessary applications are excluded, minimizing the risk of overlooking potential threats.
-- Consider implementing additional monitoring and logging for pods using host IPC to ensure that any unexpected behavior is quickly identified and addressed, even if the pod is part of an exception list.
-
-### Response and remediation
-
-- Immediately isolate the affected pod to prevent further access to the host's IPC namespace and limit potential data exposure.
-- Review Kubernetes audit logs to identify the source of the pod creation or modification request and determine if it was authorized.
-- Investigate the container image used in the pod to ensure it is not malicious or compromised, focusing on images not excluded by the detection rule.
-- Check for any unauthorized access or modifications to shared memory, semaphore arrays, or message queues on the host.
-- Escalate the incident to the security team if unauthorized access or malicious activity is confirmed, providing them with detailed findings and logs.
-- Implement stricter access controls and policies to prevent unauthorized use of the host IPC namespace in future deployments.
-- Enhance logging and monitoring by integrating with security information and event management (SIEM) systems to detect similar threats more effectively.
-- Conduct a thorough review of all pods using the host IPC namespace and ensure they are necessary and secure.
-- Restore affected systems by redeploying pods with secure configurations and verified container images.
-- Apply hardening measures such as network segmentation, least privilege access, and regular security audits to reduce the risk of privilege escalation and host escape attempts.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
index 0c140639e20..e1e7005a68c 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -25,50 +25,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostNetwork"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Pod Created With HostNetwork
-
-Kubernetes allows pods to connect to the host's network namespace, granting them access to services on the host's localhost. This can be exploited by attackers to monitor network traffic or bypass network restrictions. The detection rule identifies suspicious pod creation or modification events by monitoring audit logs for pods using the host network, excluding known benign images, to flag potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the audit log entry that triggered the alert to confirm the presence of `hostNetwork:true` in the `kubernetes.audit.requestObject.spec` field, ensuring the pod is indeed using the host network.
-- Verify the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was allowed, indicating a potential security concern.
-- Check the `kubernetes.audit.objectRef.resource` field to confirm the resource type is "pods" and the action in `kubernetes.audit.verb` is "create", "update", or "patch" to validate the context of the alert.
-- Investigate the image used by the pod by examining the `kubernetes.audit.requestObject.spec.containers.image` field to identify if it is a known or unknown image, focusing on those not explicitly excluded by the rule.
-- Cross-reference the pod's namespace and node information to determine if the pod is running in a sensitive or critical environment, which might increase the risk level.
-- Use Osquery to gather additional context about the node where the pod is running. For example, execute the following query to list all pods using the host network on the node: `SELECT name, namespace, hostNetwork FROM kubernetes_pods WHERE hostNetwork = 1;`
-- Analyze network traffic logs from the node to identify any unusual or unauthorized access patterns that might indicate malicious activity originating from the pod.
-- Review recent changes or deployments in the Kubernetes environment to identify if the pod creation or modification aligns with expected operational activities or if it was unexpected.
-- Check for any other alerts or anomalies related to the same pod or node to identify potential patterns or coordinated activities.
-- Consult with the team responsible for the Kubernetes environment to verify if the use of host networking was intentional and authorized, and gather any additional context or documentation related to the deployment.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate applications or services require access to the host network for valid operational reasons, such as monitoring tools or network utilities that need to interact with the host's network stack.
-- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to require host network access. This can be done by updating the detection rule to exclude additional trusted images or namespaces beyond the default exclusion of "docker.elastic.co/beats/elastic-agent:8.4.0".
-- Regularly review and update the list of exceptions to ensure that only necessary and trusted applications are allowed to use the host network, minimizing the risk of overlooking potential threats.
-- Consider implementing additional context-based checks, such as verifying the source of the pod creation request or correlating with other security events, to further reduce the likelihood of false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected pod by removing it from the host network to prevent further unauthorized access to the host's network services.
-- Conduct a thorough investigation of the pod's configuration and logs to identify any unauthorized access or data exfiltration attempts.
-- Review Kubernetes audit logs to trace the origin of the pod creation or modification request and identify any compromised user accounts or credentials.
-- Revoke access and rotate credentials for any accounts suspected of being compromised to prevent further unauthorized actions.
-- Escalate the incident to the security operations team if evidence of privilege escalation or lateral movement is found, following the organization's incident response plan.
-- Implement stricter network policies and role-based access controls (RBAC) to limit the use of host networking to only essential and trusted pods.
-- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities in the future.
-- Conduct a security review of all pods and containers running in the environment to ensure compliance with security best practices and identify any other potential vulnerabilities.
-- Restore the system to its operational state by redeploying affected services with secure configurations and ensuring no unauthorized changes remain.
-- Educate the development and operations teams on the risks associated with host networking and the importance of adhering to security policies and procedures.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
index ca7c965102c..49a1dec6249 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -26,50 +26,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostPID"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Pod Created With HostPID
-
-Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges or execute unauthorized actions. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation threats.
-
-### Possible investigation steps
-
-- Review the Kubernetes audit logs to confirm the alert details, focusing on the `event.dataset` field to ensure it matches "kubernetes.audit_logs".
-- Verify the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was allowed, indicating a potential security concern.
-- Examine the `kubernetes.audit.objectRef.resource` field to confirm the resource type is "pods", ensuring the alert pertains to pod creation or modification.
-- Check the `kubernetes.audit.verb` field to determine the action taken, whether it was "create", "update", or "patch", to understand the nature of the change.
-- Investigate the `kubernetes.audit.requestObject.spec.hostPID` field to confirm it is set to true, indicating the pod is sharing the host's PID namespace.
-- Cross-reference the `kubernetes.audit.requestObject.spec.containers.image` field to ensure the image is not part of the known safe list, such as "docker.elastic.co/beats/elastic-agent:8.4.0".
-- Identify the user or service account responsible for the action by examining the `kubernetes.audit.user.username` field to assess if it aligns with expected behavior.
-- Use Osquery to gather additional context on the host by running a query like `SELECT * FROM processes WHERE pid IN (SELECT pid FROM processes WHERE name = 'kubelet');` to identify processes that might be interacting with the Kubernetes API.
-- Investigate the pod's configuration and deployment history to determine if the use of HostPID was intentional or a potential misconfiguration.
-- Review any recent changes in the cluster's configuration or deployments that might have introduced the use of HostPID, correlating with the alert's timestamp.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate administrative tasks require the use of HostPID for debugging or monitoring purposes. These tasks might involve trusted images or tools that are essential for system maintenance.
-- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to be safe and frequently use HostPID for legitimate reasons. This can be done by updating the detection rule to exclude additional trusted images or namespaces.
-- Another potential false positive scenario involves automated processes or CI/CD pipelines that temporarily require HostPID access for testing or deployment purposes. Users should identify these processes and adjust the rule to exclude them from triggering alerts.
-- It is important to regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected pod to prevent further interaction with the host processes and potential privilege escalation.
-- Review Kubernetes audit logs to identify any unauthorized access or modifications to pods with HostPID enabled, focusing on the specific time frame of the alert.
-- Verify the integrity of the host system by checking for any unauthorized processes or changes, especially those related to privilege escalation attempts.
-- Revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled, and ensure that only trusted users have the ability to create such pods.
-- Escalate the incident to the security team if evidence of privilege escalation or host compromise is found, providing them with detailed logs and findings.
-- Implement stricter pod security policies to prevent the use of HostPID unless absolutely necessary, and ensure that all containers are running with the least privilege.
-- Enhance logging and monitoring by integrating with security information and event management (SIEM) systems to detect similar threats in the future.
-- Conduct a thorough review of container images and ensure that only approved and secure images are used in the environment.
-- Restore the system to its operational state by redeploying affected services with secure configurations and verified images.
-- Educate the development and operations teams on the risks associated with HostPID and the importance of adhering to security best practices.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
index d6f7b8883fa..20c8c18652f 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/11"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -26,51 +26,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod created with a Sensitive hostPath Volume"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Pod created with a Sensitive hostPath Volume
-
-Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks.
-
-### Possible investigation steps
-
-- Review the Kubernetes audit logs to confirm the alert by checking the `event.dataset` field for "kubernetes.audit_logs" and ensure the `kubernetes.audit.annotations.authorization_k8s_io/decision` is "allow".
-- Identify the specific pod involved by examining the `kubernetes.audit.objectRef.resource` field for "pods" and note the `kubernetes.audit.verb` to determine if it was a "create", "update", or "patch" action.
-- Investigate the `kubernetes.audit.requestObject.spec.volumes.hostPath.path` field to determine which sensitive directory was mounted and assess the potential risk associated with this path.
-- Check the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container image used and verify if it is a known or trusted image, excluding "docker.elastic.co/beats/elastic-agent:8.4.0".
-- Use Osquery to gather more information about the node where the pod is running. For example, run the query: `SELECT * FROM kubernetes_pods WHERE name = '<pod_name>';` to get details about the pod's configuration and status.
-- Examine the Kubernetes cluster's RBAC policies to determine if the service account associated with the pod has excessive permissions that could be exploited.
-- Review the pod's logs and any associated application logs for suspicious activity or errors that might indicate a compromise.
-- Check for any recent changes in the cluster configuration or deployments that could have introduced vulnerabilities or misconfigurations.
-- Investigate network activity from the pod to identify any unusual outbound connections or data exfiltration attempts.
-- Correlate the findings with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to identify any related alerts or incidents.
-
-### False positive analysis
-
-- Certain monitoring or logging agents may require access to hostPath volumes for legitimate purposes, such as collecting system metrics or logs. These agents might trigger the rule if they mount sensitive directories.
-- Backup or disaster recovery solutions might use hostPath volumes to access and back up critical data, which could be flagged by the rule.
-- Development or testing environments often use hostPath volumes to simulate production-like conditions, which might not pose a security risk in these controlled settings.
-- Users can handle these false positives by creating exceptions for known benign applications or agents that require hostPath access. This can be done by excluding specific container images or namespaces from the rule.
-- Regularly review and update the list of exceptions to ensure that only trusted applications are excluded, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected pod to prevent further access to sensitive host data and potential privilege escalation.
-- Investigate the pod's configuration and logs to determine if there has been unauthorized access or malicious activity.
-- Review Kubernetes audit logs to identify any suspicious activities or patterns related to the creation or modification of pods with sensitive hostPath volumes.
-- Revoke any unnecessary permissions or access rights that may have been granted to the compromised pod or its associated service account.
-- Patch and update the Kubernetes cluster and any affected applications to address known vulnerabilities that could be exploited.
-- Escalate the incident to the security team if evidence of a breach or compromise is found, and consider involving incident response experts if necessary.
-- Implement logging policies to ensure comprehensive monitoring of Kubernetes audit logs and container activities for future incidents.
-- Integrate security tools such as intrusion detection systems and anomaly detection to enhance monitoring and alerting capabilities.
-- Restore the system to its operational state by redeploying the affected pod with secure configurations and without sensitive hostPath volumes.
-- Harden the Kubernetes environment by enforcing security best practices, such as using network policies, role-based access control (RBAC), and regular security audits.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
index 53a9502652c..f1f93659d1d 100644
--- a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -26,51 +26,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Privileged Pod Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Privileged Pod Created
-
-Kubernetes allows for the creation of privileged pods, which can access the host's resources, bypassing container isolation. Adversaries exploit this to escalate privileges, potentially compromising the host. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the Kubernetes audit logs to confirm the creation of the privileged pod by checking the `event.dataset` field for "kubernetes.audit_logs" and the `kubernetes.audit.verb` field for "create".
-- Verify the authorization decision by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure it was set to "allow".
-- Identify the specific pod and container involved by reviewing the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.requestObject.spec.containers.securityContext.privileged` fields to confirm the pod was created with privileged settings.
-- Cross-reference the image used for the pod against known safe images by checking the `kubernetes.audit.requestObject.spec.containers.image` field to ensure it is not part of the excluded list, such as "docker.elastic.co/beats/elastic-agent:8.4.0".
-- Investigate the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.user.username` field to determine if the action was authorized or suspicious.
-- Check the source IP address and user agent from the audit logs to identify where the request originated, which can provide context on whether the action was internal or external.
-- Use Osquery to gather additional context on the node where the privileged pod was created. For example, run the following Osquery query to list all running containers and their privileges: `SELECT * FROM kubernetes_pods WHERE privileged = 1;`.
-- Analyze the timeline of events leading up to the creation of the privileged pod by reviewing related audit logs to identify any preceding suspicious activities or patterns.
-- Investigate any lateral movement or persistence mechanisms by examining network logs and other security tools for connections or changes initiated from the node hosting the privileged pod.
-- Collaborate with the Kubernetes administrators to verify if the creation of the privileged pod aligns with any recent changes or deployments, ensuring it was not part of a legitimate operation.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate administrative tasks require the creation of privileged pods, such as during system maintenance or when deploying certain monitoring tools that need elevated permissions.
-- Users can handle these false positives by creating exceptions for specific images or namespaces that are known to be safe and necessary for operational purposes, such as internal monitoring tools or trusted third-party applications.
-- It's important to regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-- Consider implementing additional context checks, such as verifying the source of the request or the identity of the user, to further reduce false positives and ensure that only authorized personnel can create privileged pods.
-- Regular audits and reviews of privileged pod usage can help identify patterns that may indicate false positives, allowing for more accurate tuning of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected node to prevent further access or lateral movement by the adversary.
-- Review Kubernetes audit logs to identify the source of the privileged pod creation and any associated user accounts or IP addresses.
-- Revoke access for any compromised user accounts and reset credentials to prevent unauthorized access.
-- Terminate the privileged pod and any other suspicious pods that may have been created by the adversary.
-- Conduct a thorough investigation of the host for signs of compromise, including unauthorized processes, files, or network connections.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed audit logs for all Kubernetes API activities, focusing on pod creation and privilege escalation attempts.
-- Integrate security tools with Kubernetes, such as intrusion detection systems or runtime security solutions, to monitor for and alert on suspicious activities.
-- Restore the system to its operational state by redeploying affected applications and ensuring all security patches and configurations are up to date.
-- Harden the Kubernetes environment by enforcing strict RBAC policies, disabling unnecessary privileges, and regularly reviewing and updating security configurations.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
index b0348369f28..051c4b214e9 100644
--- a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -24,50 +24,7 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Suspicious Assignment of Controller Service Account"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kubernetes Suspicious Assignment of Controller Service Account
-
-Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these powerful accounts to pods, gaining admin-level access. The detection rule identifies such suspicious activity by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, signaling potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the audit log entry that triggered the alert, focusing on the `kubernetes.audit.verb`, `kubernetes.audit.objectRef.resource`, and `kubernetes.audit.objectRef.namespace` fields to confirm the creation of a pod in the `kube-system` namespace.
-- Verify the `kubernetes.audit.requestObject.spec.serviceAccountName` field to identify the specific controller service account assigned to the pod and assess if it is typically used in your environment.
-- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to ensure the action was indeed allowed and not a false positive.
-- Investigate the source of the request by examining the `kubernetes.audit.user.username` field to identify the user or service account that initiated the pod creation.
-- Analyze the `kubernetes.audit.sourceIPs` field to determine the origin IP address of the request, which can help identify if it was made from a known or suspicious location.
-- Use Osquery to gather more information about the pod by running a query such as: `SELECT * FROM kubernetes_pods WHERE namespace = 'kube-system' AND service_account_name LIKE '%controller%';` to list all pods with controller service accounts in the `kube-system` namespace.
-- Cross-reference the pod's creation time with other logs and events to identify any correlated suspicious activities or anomalies around the same timeframe.
-- Review the pod's configuration and associated resources, such as ConfigMaps and Secrets, to identify any unauthorized or unexpected configurations.
-- Investigate the history of the service account in question to determine if it has been used in any other suspicious activities or if there have been recent changes to its permissions.
-- Consult with the team responsible for the Kubernetes environment to verify if the pod creation and service account assignment were part of any legitimate maintenance or deployment activities.
-
-### False positive analysis
-
-- Legitimate administrative actions: In some cases, cluster administrators may intentionally assign controller service accounts to pods for maintenance or testing purposes. These actions, while legitimate, can trigger the detection rule. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform these tasks regularly.
-- Automated deployment tools: Certain automated deployment or orchestration tools might temporarily assign controller service accounts to pods as part of their operation. Users should identify these tools and exclude their activities from triggering alerts by specifying the tool's service account or namespace in the exception list.
-- System updates or upgrades: During system updates or upgrades, Kubernetes might temporarily assign controller service accounts to pods as part of the process. Users can handle these by setting time-based exceptions during known maintenance windows to prevent false positives.
-- Testing environments: In testing or development environments, developers might assign controller service accounts to pods to simulate production scenarios. Users can exclude these environments from monitoring or create specific rules that differentiate between production and non-production environments to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected pod to prevent further unauthorized access or actions within the cluster.
-- Review Kubernetes audit logs to identify the source of the suspicious activity and determine if other pods or resources have been compromised.
-- Revoke any unauthorized service account tokens and reset credentials for affected accounts to prevent further misuse.
-- Conduct a thorough investigation to determine how the adversary gained the ability to assign the controller service account, focusing on potential vulnerabilities or misconfigurations.
-- Escalate the incident to the security operations team and relevant stakeholders to ensure awareness and coordinated response efforts.
-- Implement stricter role-based access control (RBAC) policies to limit permissions and prevent unauthorized service account assignments in the kube-system namespace.
-- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities in the future.
-- Apply security patches and updates to Kubernetes components and related infrastructure to mitigate known vulnerabilities.
-- Restore affected systems and services to their operational state by redeploying clean versions of compromised pods and verifying their integrity.
-- Conduct a post-incident review to identify lessons learned and update incident response plans, incorporating additional hardening measures such as network segmentation and regular security audits.
-
-## Setup
+note = """## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
index c6c6005acfb..34ee5a28519 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -52,51 +52,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 High Mean of Process Arguments in an RDP Session
-
-Remote Desktop Protocol (RDP) allows users to connect to systems remotely, often used for administrative tasks. Adversaries exploit RDP for lateral movement by executing complex commands with numerous arguments, often to obfuscate their actions. The detection rule identifies anomalies in the number of process arguments during RDP sessions, signaling potential misuse or sophisticated attack attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific RDP session and the associated user account that triggered the high mean of process arguments.
-- Examine the timestamp of the alert to correlate it with any known scheduled tasks or legitimate administrative activities.
-- Analyze the process command line arguments captured in the alert to identify any suspicious patterns, such as excessive length, obfuscation, or unusual command structures.
-- Check the source and destination IP addresses involved in the RDP session to determine if they are part of the organization's network or if they are external and potentially malicious.
-- Investigate the historical activity of the user account involved in the alert to identify any previous suspicious behavior or anomalies.
-- Utilize Osquery to gather additional context on the processes executed during the RDP session. For example, run the following Osquery query to list processes with a high number of arguments:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE length(cmdline) > 1000;
-  ```
-- Cross-reference the processes identified with known malicious software or tools commonly used for lateral movement and exploitation.
-- Review the system logs for any failed login attempts or unusual authentication patterns around the time of the alert.
-- Check for any recent changes in user privileges or group memberships that could indicate privilege escalation attempts.
-- Investigate any network connections initiated by the processes with high argument counts to identify potential data exfiltration or communication with command and control servers.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often execute complex scripts or commands with numerous arguments during maintenance or configuration tasks, which can trigger false positives. To manage this, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
-- Automated scripts and software updates: Scheduled tasks or automated scripts that run during RDP sessions may involve commands with a high number of arguments. Users can whitelist these scripts or processes by identifying their unique characteristics, such as specific command patterns or originating IP addresses.
-- Development and testing environments: Developers and testers might use RDP sessions to run scripts with multiple arguments for testing purposes. Organizations can exclude these environments from monitoring or set up specific rules that account for the high argument count typical in these scenarios.
-- Third-party software: Some legitimate third-party applications may inherently use complex commands with many arguments during their operation. Users should identify these applications and create exceptions based on their known behavior and usage patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation of the RDP session logs to identify the source IP address and any associated user accounts involved in the suspicious activity.
-- Analyze the process arguments and commands executed during the RDP session to determine the intent and scope of the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are compromised.
-- Implement enhanced logging policies to capture detailed RDP session activities, including command-line arguments and user actions, for future investigations.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework into the security information and event management (SIEM) system to improve detection capabilities.
-- Restore the affected system to its operational state by removing any malicious software, resetting compromised credentials, and applying necessary security patches.
-- Conduct a security audit of RDP configurations and apply hardening measures such as enforcing strong authentication, using network-level authentication, and limiting RDP access to trusted IP addresses.
-- Provide security awareness training to users on the risks associated with RDP and best practices for secure remote access.
-- Review and update the incident response plan to incorporate lessons learned from the incident and improve response strategies for future threats."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
index 8a8c783f708..0b13d9e762e 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -52,49 +52,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 High Mean of RDP Session Duration
-
-Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks and support. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific parameters of the anomaly, including the mean session duration and the threshold that triggered the alert.
-- Correlate the alert with user activity logs to identify the user accounts involved in the prolonged RDP sessions and verify if these accounts are expected to have extended access.
-- Examine the source and destination IP addresses associated with the RDP sessions to determine if they are from known or trusted networks.
-- Check for any concurrent alerts or anomalies related to the same user accounts or IP addresses, such as failed login attempts or unusual login times, to identify potential patterns of malicious behavior.
-- Investigate the session start and end times to determine if the prolonged duration aligns with legitimate business activities or if it occurred during off-hours, which might indicate suspicious activity.
-- Utilize Osquery to gather additional context on the systems involved. For example, run the following Osquery query to list active RDP sessions and their durations: `SELECT user, remote_address, start_time, (strftime('%s','now') - strftime('%s',start_time)) AS session_duration FROM rdp_sessions WHERE session_duration > <threshold>;`
-- Analyze system logs for any signs of lateral movement or exploitation of remote services, such as unusual process executions or network connections initiated during the RDP sessions.
-- Review any recent changes or updates to the systems involved that might explain the prolonged sessions, such as software installations or configuration changes.
-- Check for any known vulnerabilities or exploits related to RDP on the affected systems and ensure they are patched and up-to-date.
-- Consult with the system owners or users involved to verify if the extended RDP sessions were authorized and necessary for legitimate tasks.
-
-### False positive analysis
-
-- Legitimate administrative tasks: Extended RDP sessions may occur during routine system maintenance or software updates by IT staff. These sessions can be excluded by identifying and whitelisting known IP addresses or user accounts associated with IT personnel.
-- Remote support activities: Support teams might require prolonged access to troubleshoot and resolve complex issues. To manage this, create exceptions for support team accounts or specific time frames when support activities are expected.
-- Automated processes: Some automated scripts or processes might use RDP for legitimate purposes, leading to longer session durations. Identify these processes and exclude them by recognizing their unique session patterns or associated user accounts.
-- Training sessions or demonstrations: Extended RDP sessions may be used for training or demonstration purposes. These can be managed by setting exceptions for specific user accounts or during scheduled training periods.
-- Unusual work hours: Employees working outside regular hours might have longer RDP sessions. Consider implementing a policy to monitor and verify these sessions, allowing exceptions for verified after-hours work.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation of the RDP session logs to identify the source IP address and user account involved in the prolonged session.
-- Review and analyze any other network activity from the identified source IP to detect additional signs of compromise or lateral movement.
-- Reset credentials for any user accounts involved in the suspicious RDP sessions to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed RDP session activity, including session start and end times, user accounts, and source IP addresses.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate RDP session anomalies with known threat indicators.
-- Restore the affected system from a known good backup to ensure it is free from any malicious modifications or persistence mechanisms.
-- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation of remote services.
-- Harden RDP access by enforcing multi-factor authentication, using strong password policies, and restricting RDP access to only necessary users and IP addresses."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
index ee4899c5e3f..910d0e198f5 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -53,49 +53,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Remote File Size
-
-Machine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule flags these anomalies, leveraging MITRE ATT&CK frameworks to pinpoint potential exploitation of remote services.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific remote host and file size that triggered the alert. Pay attention to fields such as source IP, destination IP, file path, and file size.
-- Correlate the alert with recent network activity logs to determine if there are any other unusual patterns or connections involving the same remote host.
-- Check historical data to see if the remote host has previously transferred files of similar sizes or if this is an anomaly.
-- Use Osquery to gather more information about the file in question. For example, run the following query to list files in the directory where the unusual file was detected: `SELECT path, size, atime, mtime FROM file WHERE directory = '/path/to/suspicious/directory';`
-- Investigate the user account associated with the file transfer to determine if there are any signs of compromise or unusual activity, such as failed login attempts or changes in user privileges.
-- Examine the processes running on the remote host at the time of the file transfer to identify any suspicious or unauthorized applications that could be involved in data aggregation or exfiltration.
-- Analyze the file metadata to understand its origin, creation date, and any modifications that might indicate tampering or aggregation of data.
-- Cross-reference the alert with threat intelligence feeds to check if the remote host IP or domain is associated with known malicious activity or threat actors.
-- Review any recent changes in network configurations or security policies that might have inadvertently allowed or facilitated the unusual file transfer.
-- Consult with other security team members or departments to gather additional context or insights that might aid in understanding the nature and intent of the file transfer.
-
-### False positive analysis
-
-- Large file transfers related to legitimate business operations, such as regular backups or data migrations, can trigger false positives. Users should identify these routine activities and create exceptions to prevent unnecessary alerts.
-- Software updates or patches distributed across the network may also be flagged. To manage this, users can whitelist known update servers or processes.
-- Data transfers involving multimedia files, such as video or high-resolution images, might be mistakenly identified as threats. Users should assess the context of these transfers and exclude them if they are part of normal business functions.
-- Remote file sharing services used for collaboration, like cloud storage solutions, can generate large file transfers. Users should monitor these services and exclude them if they are verified as secure and necessary for operations.
-- Automated data processing tasks that involve large datasets can be misinterpreted as suspicious activity. Users should document these processes and configure the system to recognize them as non-threatening.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement and data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the anomaly, focusing on recent file transfer activities and user access logs.
-- Analyze the large file for any malicious content or sensitive data that may have been aggregated by the adversary.
-- Review and update access controls and permissions to ensure that only authorized users have access to sensitive data and remote services.
-- Implement enhanced logging and monitoring policies to capture detailed file transfer activities and user actions for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual file size alerts with other suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response if the threat persists or is part of a larger attack.
-- Restore the affected system to its operational state by removing any malicious files, patching vulnerabilities, and verifying system integrity.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement hardening measures such as network segmentation, multi-factor authentication, and regular security training to reduce the risk of future exploitation of remote services."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
index cd8918fe1fd..9002606a3a3 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -52,52 +52,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 High Variance in RDP Session Duration
-Remote Desktop Protocol (RDP) enables remote access to systems, facilitating legitimate administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, often for lateral movement within networks. The detection rule leverages machine learning to identify anomalies in session duration, flagging potential misuse by highlighting sessions with unusually high variance, indicative of suspicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific RDP session(s) with high variance in duration, noting the user accounts and source IP addresses involved.
-- Correlate the session details with historical data to determine if the user or IP address has a pattern of unusual activity or if this is an isolated incident.
-- Check the login times and durations of the flagged RDP sessions to see if they align with typical working hours or if they occur at unusual times.
-- Investigate the user account(s) involved in the sessions for any recent changes, such as password resets or privilege escalations, that could indicate compromise.
-- Use Osquery to gather additional context on the affected systems. For example, run the following query to list active RDP sessions and their durations:
-  ```sql
-  SELECT user, remote_address, start_time, end_time, (julianday(end_time) - julianday(start_time)) * 24 * 60 AS duration_minutes 
-  FROM rdp_sessions 
-  WHERE duration_minutes > <threshold>;
-  ```
-- Examine the network traffic logs for the source IP addresses to identify any other suspicious connections or data transfers that coincide with the RDP sessions.
-- Analyze system logs on the affected machines for any unusual processes or commands executed during the flagged RDP sessions.
-- Check for any recent changes in firewall or security group configurations that might have allowed unauthorized RDP access.
-- Review any recent alerts or incidents involving the same user accounts or IP addresses to identify potential patterns of malicious activity.
-- Consult with the user(s) associated with the flagged sessions to verify if the activity was legitimate and authorized, documenting their responses for further analysis.
-
-### False positive analysis
-
-- Legitimate administrative tasks: Extended RDP sessions by IT staff for system maintenance or software updates can trigger false positives. Users can manage this by creating exceptions for known administrative accounts or IP addresses.
-- Remote support sessions: Third-party vendors providing remote support might have prolonged RDP sessions. To handle this, users can whitelist specific vendor IPs or user accounts.
-- Training sessions: RDP sessions used for training purposes may last longer than usual. Users should consider excluding training-related accounts or session times from the detection rule.
-- Automated processes: Some automated scripts or processes might require long RDP sessions. Users can exclude these by identifying and listing the specific scripts or processes that are known to be non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation of the RDP session logs to identify the source IP address and any associated user accounts involved in the suspicious activity.
-- Review and analyze other network logs and security alerts to determine if there are additional compromised systems or accounts.
-- Reset passwords for any user accounts that were involved in the suspicious RDP sessions and enforce multi-factor authentication (MFA) for all remote access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed RDP session data, including session duration, source IP addresses, and user activity.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate RDP session anomalies with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the affected system to its operational state by reimaging the machine and applying the latest security patches and updates.
-- Conduct a post-incident review to identify gaps in security controls and update the incident response plan accordingly.
-- Implement hardening measures such as restricting RDP access to specific IP addresses, using network segmentation, and regularly auditing RDP usage to prevent future exploitation."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
index 2159b1e97ed..95486b7b141 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -52,49 +52,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Remote File Directory
-
-In enterprise environments, remote file transfers are common for legitimate operations. However, adversaries exploit this by targeting less monitored directories to evade detection. The 'Unusual Remote File Directory' detection rule identifies anomalies in file transfers to atypical directories, signaling potential lateral movement. By focusing on uncommon paths, it helps uncover stealthy exploitation attempts, aligning with MITRE ATT&CK's lateral movement tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific unusual directory involved in the remote file transfer.
-- Check the source and destination IP addresses associated with the file transfer to determine if they are known or expected within the network.
-- Analyze the user account involved in the transfer to verify if the activity aligns with their typical behavior or job role.
-- Investigate the timestamp of the file transfer to see if it coincides with any other suspicious activities or known attack patterns.
-- Use Osquery to list recent file modifications in the unusual directory with a query like: `SELECT path, size, atime, mtime FROM file WHERE directory = '/path/to/unusual/directory';`
-- Examine the file types and names transferred to assess if they are commonly used in legitimate operations or if they appear suspicious.
-- Cross-reference the unusual directory with known directories used in previous incidents or documented attack techniques.
-- Check for any recent changes in permissions or ownership of the unusual directory that could indicate unauthorized access.
-- Look for any related alerts or logs that might provide additional context or corroborate the suspicious activity.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors that use similar tactics or target similar directories.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may perform legitimate file transfers to less common directories for maintenance or configuration purposes. These activities can be excluded by identifying and whitelisting known administrative accounts and their typical operations.
-- Software updates and deployments: Automated processes for software updates or deployments might use non-standard directories temporarily. Users can manage these by creating exceptions for specific update tools or deployment scripts.
-- Backup operations: Backup solutions might store data in unusual directories to avoid interference with regular operations. To handle this, users should identify and exclude directories used by verified backup solutions.
-- Development and testing environments: Developers may transfer files to atypical directories during testing phases. Organizations can mitigate false positives by excluding directories associated with development and testing environments.
-- Third-party integrations: Some third-party applications may require file transfers to non-standard directories as part of their functionality. Users should document and exclude these directories after verifying the application's legitimacy.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further lateral movement and contain the threat.
-- Conduct a thorough investigation of the unusual directory to identify any unauthorized files or scripts that may have been transferred.
-- Analyze logs and network traffic to trace the source of the remote file transfer and identify any other potentially compromised systems.
-- Remove any malicious files or scripts found in the unusual directory and restore any altered system files from a known good backup.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to monitor file transfers to and from less common directories, ensuring comprehensive coverage of potential attack vectors.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate employees on recognizing and reporting suspicious activities to enhance the organization's overall security awareness and readiness."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
index bc0f79de5ec..e652d49aef9 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -51,49 +51,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Remote File Extension
-In enterprise environments, remote file transfers are common for legitimate operations. However, adversaries may exploit this by transferring files with rare or unusual extensions to facilitate lateral movement, often bypassing standard security measures. The 'Unusual Remote File Extension' detection rule identifies anomalies in file extensions during remote transfers, flagging potential exploitation of remote services, aligning with MITRE ATT&CK's lateral movement tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file extension and the source and destination of the remote file transfer.
-- Check the historical data for the identified file extension to determine if it has been used previously in legitimate operations.
-- Analyze the user account associated with the file transfer to verify if the activity aligns with their typical behavior and access patterns.
-- Investigate the source and destination IP addresses to determine if they are known and trusted within the organization.
-- Use Osquery to gather additional context on the host involved in the transfer. For example, run the following query to list recent file modifications: `SELECT path, size, atime, mtime FROM file WHERE path LIKE '/path/to/directory/%' ORDER BY mtime DESC LIMIT 10;`
-- Examine the process tree on the source host to identify any unusual or unexpected processes that may have initiated the file transfer.
-- Cross-reference the file hash with threat intelligence databases to check for any known malicious indicators.
-- Review network logs to identify any other unusual or suspicious activities associated with the source or destination IP addresses.
-- Check for any recent changes in user permissions or configurations that could have facilitated the unusual file transfer.
-- Consult with the user or department associated with the file transfer to verify if the activity was authorized and legitimate.
-
-### False positive analysis
-
-- Known false positives for the Unusual Remote File Extension rule often include legitimate software updates or patches that use uncommon file extensions during remote transfers. These can be mistakenly flagged as suspicious.
-- Internal development teams may transfer files with custom extensions for testing or deployment purposes, which can trigger the rule despite being non-threatening.
-- Automated backup systems might use unique file extensions to differentiate between versions or types of data, leading to false positives.
-- To manage these false positives, users can create exceptions for specific file extensions that are regularly used in legitimate operations by trusted applications or systems.
-- Implementing a whitelist of known and verified file extensions associated with routine business processes can help reduce unnecessary alerts.
-- Regularly reviewing and updating the list of exceptions based on changes in business operations or software updates can ensure that the detection rule remains effective without generating excessive false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation of the unusual file extension to determine its origin, purpose, and any associated processes or network connections.
-- Review recent remote file transfer logs to identify any other instances of unusual file extensions or suspicious activity.
-- Utilize endpoint detection and response (EDR) tools to scan the affected host for known indicators of compromise (IOCs) related to the identified threat.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of compromise or if the threat level is beyond initial containment capabilities.
-- Remove any malicious files or software identified during the investigation and apply security patches to address any exploited vulnerabilities.
-- Restore the system to its operational state by ensuring all malicious artifacts are removed and verifying system integrity.
-- Implement enhanced logging policies to capture detailed information on remote file transfers and unusual file extensions for future investigations.
-- Integrate threat intelligence feeds and automated alerting systems to improve detection of similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting remote file transfer capabilities to trusted sources and implementing strict access controls."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
index 4ab09e203d9..f2f1c672314 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -52,49 +52,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Number of Connections Made from a Source IP
-
-Remote Desktop Protocol (RDP) is a common technology used for remote management and access. Adversaries exploit RDP to move laterally within networks, seeking valuable data or further access. The detection rule identifies unusual spikes in RDP connections from a single source IP, signaling potential lateral movement attempts, aligning with MITRE ATT&CK's lateral movement tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the source IP address and the list of destination IPs involved in the spike of RDP connections.
-- Verify the legitimacy of the source IP by checking if it belongs to a known and trusted device within the organization.
-- Analyze historical logs to determine if the source IP has exhibited similar behavior in the past or if this is an anomaly.
-- Cross-reference the source IP with threat intelligence feeds to check for any known malicious activity associated with it.
-- Use Osquery to gather more information about the source system. For example, run the following query to list active RDP sessions: `SELECT * FROM rdp_connections WHERE local_address = '<source_ip>';`
-- Investigate the destination IPs to determine if they are critical assets or if they have any known vulnerabilities that could be exploited.
-- Check for any recent changes or updates on the source system that might explain the spike in connections, such as new software installations or configuration changes.
-- Review user activity logs to identify any unusual login patterns or failed login attempts associated with the source IP.
-- Examine network traffic logs for any signs of data exfiltration or other suspicious activities originating from the source IP.
-- Collaborate with the IT team to verify if there were any legitimate administrative tasks or maintenance activities that could account for the increased RDP connections.
-
-### False positive analysis
-
-- Routine administrative tasks: Regularly scheduled maintenance or updates by IT staff can result in a spike in RDP connections from a single source IP. These activities are typically non-threatening and can be excluded by identifying and whitelisting the IP addresses of known administrative machines.
-- Automated scripts or tools: Some organizations use automated scripts or management tools that initiate multiple RDP connections for monitoring or configuration purposes. These should be reviewed and, if deemed safe, excluded from triggering alerts by adding them to an exception list.
-- Load balancers or proxy servers: In environments where RDP connections are routed through load balancers or proxy servers, a single source IP may appear to make numerous connections. Identifying these devices and excluding their IPs can prevent false positives.
-- Remote work scenarios: Employees working remotely might connect to multiple systems via RDP for legitimate business purposes. Recognizing these patterns and excluding the associated IPs can help reduce unnecessary alerts.
-- Testing and development environments: In testing or development environments, frequent RDP connections might occur as part of normal operations. These environments can be excluded from monitoring or have specific rules applied to minimize false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
-- Conduct a thorough investigation to identify the source of the RDP connection spike, including reviewing logs and network traffic for any signs of unauthorized access or exploitation.
-- Reset credentials for any accounts that may have been compromised, especially those with administrative privileges, to prevent further unauthorized access.
-- Apply security patches and updates to all systems, focusing on vulnerabilities related to RDP and remote services, to mitigate exploitation risks.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for RDP connections and other remote access protocols to detect future anomalies and potential threats.
-- Review and update firewall rules and access controls to restrict RDP access to only trusted IP addresses and necessary users.
-- Conduct a post-incident review to identify gaps in security controls and processes, and develop an action plan to address these weaknesses.
-- Restore the affected system to its operational state by reimaging or rebuilding it from a known good backup, ensuring all security measures are in place.
-- Implement hardening measures such as enabling network-level authentication for RDP, using multi-factor authentication, and disabling unused services to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
index 89c33260bb6..b155d1cd313 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -52,48 +52,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Number of Connections Made to a Destination IP
-
-Remote Desktop Protocol (RDP) facilitates remote access to systems, crucial for IT management. However, adversaries exploit RDP for lateral movement within networks, often using multiple compromised IPs to avoid detection. The detection rule identifies unusual spikes in RDP connections to a single IP, signaling potential coordinated attacks, thus enabling timely threat mitigation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the destination IP and the time frame of the spike in RDP connections.
-- Cross-reference the destination IP with internal asset inventories to determine the role and importance of the system within the network.
-- Analyze historical connection patterns to the destination IP to establish a baseline and confirm the anomaly.
-- Identify the source IPs involved in the spike and check for any known malicious activity or reputation using threat intelligence sources.
-- Use network logs to trace the origin of the source IPs and determine if they belong to internal or external networks.
-- Investigate user accounts associated with the source IPs to check for any unauthorized access or unusual activity.
-- Utilize Osquery to gather more information about the processes and users on the destination system. Example query: `SELECT * FROM processes WHERE name LIKE '%rdp%' OR name LIKE '%mstsc%';`
-- Check for any recent changes or updates on the destination system that might have triggered the spike in connections.
-- Review any recent security alerts or incidents that might be related to the destination IP or the source IPs.
-- Collaborate with IT and security teams to gather additional context, such as recent network changes or ongoing projects, that might explain the spike in connections.
-
-### False positive analysis
-
-- High-volume legitimate administrative activities: Organizations with centralized IT management might see spikes in RDP connections due to routine maintenance or software updates. These activities can be excluded by identifying and whitelisting known administrative IPs.
-- Automated backup or monitoring systems: Systems that regularly connect to multiple endpoints for backups or monitoring can trigger false positives. Users should configure exceptions for these systems by recognizing their IP addresses and connection patterns.
-- Load balancing or failover mechanisms: In environments using load balancers or failover systems, multiple connections to a single IP might occur as part of normal operations. Users can manage these by excluding IPs associated with these mechanisms from the detection rule.
-- Training or testing environments: In scenarios where multiple users are accessing a single system for training or testing purposes, spikes in RDP connections can be expected. Users should consider excluding these environments by setting up specific rules or exceptions for known training IPs.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further lateral movement by the attacker.
-- Conduct a thorough investigation to identify all compromised source IPs and assess the extent of the breach.
-- Block the identified malicious IPs at the firewall and update intrusion detection/prevention systems to recognize similar patterns.
-- Reset credentials for all accounts that were accessed via RDP during the time of the spike to prevent unauthorized access.
-- Review and enhance logging policies to ensure detailed RDP connection logs are maintained for future analysis and detection.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore affected systems from known good backups and ensure all systems are updated with the latest security patches.
-- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users and administrators on secure RDP practices and the importance of using multi-factor authentication to enhance security."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
index 1454bd87bcd..6da8b35fb4b 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -51,49 +51,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Number of Processes in an RDP Session
-
-Remote Desktop Protocol (RDP) allows users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement by executing numerous processes on a target machine, indicating potential exploitation of remote services. The detection rule leverages machine learning to identify anomalies in process activity within RDP sessions, flagging unusual spikes that may suggest malicious behavior.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific RDP session and the user account involved in the spike of processes.
-- Examine the timestamp of the alert to correlate with any known scheduled tasks or legitimate administrative activities.
-- Check the source and destination IP addresses of the RDP session to determine if they are within expected ranges or if they are unusual for the user or organization.
-- Analyze the list of processes that were started during the RDP session to identify any known malicious or suspicious executables.
-- Investigate the parent-child relationship of the processes to understand the execution flow and identify any anomalies.
-- Use Osquery to gather additional context on the processes. For example, run the following query to list processes started by the user during the session: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>' AND start_time BETWEEN '<start_time>' AND '<end_time>';`
-- Check for any recent changes in user permissions or group memberships that might have facilitated the execution of multiple processes.
-- Review the event logs on the target machine for any additional indicators of compromise or related suspicious activities.
-- Investigate any network connections initiated by the processes to identify potential data exfiltration or communication with command and control servers.
-- Correlate the findings with other security alerts or logs to determine if this activity is part of a larger attack campaign or isolated incident.
-
-### False positive analysis
-
-- Routine administrative tasks: High process activity can occur during legitimate administrative operations, such as software updates or system maintenance, which may trigger false positives. Users can manage these by creating exceptions for known maintenance windows or specific administrative accounts.
-- Automated scripts: Scheduled tasks or automated scripts that execute multiple processes in a short time frame can also lead to false positives. To handle this, users can whitelist specific scripts or processes that are known to be safe and frequently executed.
-- Software installations: Installing or updating software often involves starting numerous processes, which might be flagged as suspicious. Users should consider excluding these activities by identifying and allowing specific installation processes or packages.
-- Testing environments: In environments where testing and development occur, there may be legitimate reasons for high process activity. Users can exclude these environments from monitoring or adjust the sensitivity of the detection rule for these specific contexts.
-- High user activity: During periods of high user activity, such as training sessions or workshops, there may be a legitimate increase in process activity. Users can temporarily adjust thresholds or create exceptions for these events to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation of the processes executed during the RDP session to identify any malicious or unauthorized activities.
-- Review user account activity and permissions associated with the RDP session to ensure no unauthorized access or privilege escalation has occurred.
-- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed RDP session activities, including process creation, user logins, and network connections.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the affected system from a known good backup to ensure it is free from any malicious modifications.
-- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation of known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
index a8ac3535dbc..793014dff2b 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -53,49 +53,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Remote File Transfers
-
-Remote file transfer technologies facilitate seamless data sharing across networks, essential for collaboration and operations. However, adversaries exploit these technologies to move laterally within a network, often transferring data in small, inconspicuous batches to avoid detection. The 'Spike in Remote File Transfers' detection rule leverages machine learning to identify unusual transfer volumes, signaling potential malicious activity and aligning with MITRE ATT&CK's lateral movement tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and user account involved in the unusual remote file transfer activity.
-- Examine the timestamp of the detected spike to correlate with any known scheduled tasks or legitimate business operations.
-- Analyze network logs to identify the source and destination IP addresses involved in the file transfers, checking for any known malicious IPs.
-- Investigate the file types and sizes transferred to determine if they align with typical business operations or if they contain sensitive data.
-- Use Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name LIKE '%scp%' OR name LIKE '%rsync%' OR name LIKE '%ftp%';` to identify any suspicious file transfer processes.
-- Check user activity logs to verify if the user account involved in the transfer has a history of similar activities or if this is an anomaly.
-- Review authentication logs to determine if there were any unusual login attempts or successful logins around the time of the file transfer spike.
-- Investigate any recent changes in user permissions or roles that might have facilitated the file transfers.
-- Correlate the detected activity with any other alerts or incidents in the same timeframe to identify potential patterns or coordinated attacks.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors using similar tactics, techniques, and procedures (TTPs) that match the observed activity.
-
-### False positive analysis
-
-- Known false positives for the Spike in Remote File Transfers rule often include legitimate business operations such as regular data backups, software updates, or large file transfers related to business processes. These activities can mimic the patterns of small, frequent data transfers that the rule is designed to detect.
-- To manage these false positives, users can create exceptions for specific hosts or IP addresses known to perform regular, non-threatening file transfers. This can be done by analyzing historical data to identify consistent patterns and then configuring the detection system to exclude these patterns from triggering alerts.
-- Another method to handle false positives is to adjust the sensitivity of the machine learning model. By fine-tuning the model parameters, users can reduce the likelihood of false positives while still maintaining the ability to detect genuine threats.
-- Users should also consider implementing a whitelist of trusted applications and services that are known to perform legitimate remote file transfers. This can help in distinguishing between benign and potentially malicious activities.
-- Regularly reviewing and updating the list of exceptions and whitelisted entities is crucial, as network environments and business processes evolve over time, potentially altering the baseline of normal activity.
-
-### Response and remediation
-
-- Isolate the affected systems from the network to prevent further lateral movement and data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on logs and alerts related to remote file transfers.
-- Analyze the detected abnormal file transfer patterns to determine if they align with known MITRE ATT&CK techniques, specifically T1210 Exploitation of Remote Services.
-- Review and enhance logging policies to ensure comprehensive monitoring of remote file transfer activities, including the implementation of centralized logging solutions.
-- Implement additional security controls such as network segmentation and access controls to limit the potential for lateral movement.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Remove any identified malicious software or tools used by the adversary to facilitate remote file transfers.
-- Restore affected systems from clean backups and ensure all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate employees on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security policies and procedures."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
index dbd105d1fd3..91706bb4f63 100644
--- a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 anomaly_threshold = 70
@@ -52,49 +52,6 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Time or Day for an RDP Session
-
-Remote Desktop Protocol (RDP) enables remote access to systems, crucial for IT management but also a target for adversaries seeking unauthorized access. Attackers exploit RDP by initiating sessions at odd hours to avoid detection. The detection rule leverages machine learning to identify RDP sessions occurring at atypical times, flagging potential lateral movement or exploitation attempts, thus aiding in early threat identification.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account and source IP address involved in the unusual RDP session.
-- Check the timestamp of the RDP session to determine the exact time and day it occurred, comparing it with the user's typical access patterns.
-- Correlate the unusual RDP session with other security events around the same time, such as failed login attempts or changes in user permissions, to identify potential indicators of compromise.
-- Investigate the source IP address to determine if it is associated with known malicious activity or if it originates from an unexpected location for the user.
-- Use Osquery to gather additional context on the system accessed via RDP. For example, run the following query to list recent RDP sessions: `SELECT * FROM rdp_connections WHERE timestamp > (SELECT MAX(timestamp) - 86400 FROM rdp_connections);`
-- Examine the system's security logs for any anomalies or suspicious activities that occurred before or after the RDP session, such as new software installations or changes to system configurations.
-- Verify the legitimacy of the user account involved by checking recent account activity and any changes to account settings or privileges.
-- Consult with the user or their manager to confirm whether the RDP session was authorized and if there were any legitimate reasons for accessing the system at that time.
-- Investigate any other systems accessed by the same user account or from the same source IP address to identify potential lateral movement within the network.
-- Document all findings and observations during the investigation to provide a comprehensive overview of the incident and support further analysis if needed.
-
-### False positive analysis
-
-- Known false positives for the Unusual Time or Day for an RDP Session rule may include legitimate administrative tasks performed by IT staff during off-hours or scheduled maintenance activities that occur outside of typical business hours.
-- Users can manage these false positives by creating exceptions for specific user accounts or IP addresses that are known to perform legitimate RDP sessions at unusual times, ensuring these are documented and reviewed regularly.
-- Another method to handle false positives is to analyze historical data to identify patterns of legitimate access during atypical hours, allowing for the adjustment of the machine learning model's sensitivity or thresholds.
-- It's important to consider the context of the organization, such as global operations or remote work policies, which may naturally lead to RDP sessions at odd hours, and adjust the detection criteria accordingly.
-- Regularly updating the list of known exceptions and reviewing them in the context of any changes in the organization's operations or IT policies can help minimize false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the RDP session by contacting the user or system owner to confirm if the session was authorized.
-- Conduct a thorough investigation of the system for any signs of compromise, such as unusual processes, unauthorized user accounts, or unexpected network connections.
-- Review system and security logs to identify any other suspicious activities that may have occurred before or after the unusual RDP session.
-- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team if evidence of compromise is found, providing them with all relevant logs and findings.
-- Implement enhanced logging policies to capture detailed RDP session information, including timestamps, user accounts, and source IP addresses.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate RDP session data with known threat indicators.
-- Restore the system to its operational state by applying necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
-- Harden the system by enforcing strong authentication mechanisms, such as multi-factor authentication (MFA), and restricting RDP access to only trusted IP addresses."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
index f0b7da11273..9cd9d0b4429 100644
--- a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
+++ b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/29"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Gary Blackwell", "Austin Songer"]
@@ -23,51 +23,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Inbox Forwarding Rule Created"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Inbox Forwarding Rule Created
-
-Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to covertly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation or modification of such rules, specifically targeting actions that forward or redirect emails, thereby identifying potential unauthorized email collection activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account associated with the creation or modification of the inbox forwarding rule by examining the `o365.audit.Parameters` fields.
-- Verify the `event.action` field to determine whether the rule was newly created or modified, which can provide context on whether this is a new behavior or a change to existing configurations.
-- Check the `o365.audit.Parameters.ForwardTo`, `o365.audit.Parameters.ForwardAsAttachmentTo`, and `o365.audit.Parameters.RedirectTo` fields to identify the destination email addresses to which emails are being forwarded or redirected.
-- Investigate the `event.outcome` field to confirm the success of the rule creation or modification, ensuring that the alert is not a false positive due to a failed attempt.
-- Correlate the user account activity with recent login events to determine if there are any unusual login patterns or locations, using the `event.dataset:o365.audit` and `event.provider:Exchange` fields.
-- Examine the user's recent activity logs for any other suspicious actions or anomalies that might indicate account compromise, such as changes in user settings or permissions.
-- Utilize Osquery to gather additional context on the user's device and activity. For example, run a query to list recent processes executed by the user: `SELECT * FROM processes WHERE user = '<username>';`.
-- Check for any recent changes in the user's permissions or roles within Microsoft 365 that might indicate privilege escalation attempts.
-- Investigate whether similar forwarding rules have been created for other users within the organization, which could suggest a broader attack campaign.
-- Review any recent security alerts or incidents related to the user or the destination email addresses to identify potential links to known threats or ongoing investigations.
-
-### False positive analysis
-
-- Legitimate forwarding rules set by users for business purposes can trigger false positives. Users should review the context of the rule creation, such as the involved email addresses and the user's role, to determine if the action is expected.
-- Automated systems or third-party applications that integrate with Microsoft 365 and require email forwarding for functionality might also cause false positives. Identifying these systems and excluding their actions from the rule can help reduce noise.
-- Temporary forwarding rules set during employee transitions or for out-of-office scenarios can be mistaken for malicious activity. Organizations can manage this by maintaining a list of approved temporary rules and excluding them from detection.
-- Regular audits of forwarding rules can help distinguish between legitimate and suspicious activities. Implementing a process to document and approve forwarding rules can aid in quickly identifying false positives.
-- Users can create exceptions in the detection rule for specific users or departments known to frequently use forwarding rules for legitimate reasons, reducing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately disable the suspicious inbox forwarding rule to prevent further unauthorized email redirection.
-- Conduct a thorough investigation to determine the scope of the compromise, including identifying any other potentially malicious rules or configurations.
-- Review the affected user's account activity for any signs of compromise, such as unusual login locations or times, and reset the account password.
-- Notify the affected user and relevant stakeholders about the incident and provide guidance on recognizing phishing attempts and securing their accounts.
-- Escalate the incident to the security operations team for further analysis and to determine if additional accounts or systems are affected.
-- Implement enhanced logging and monitoring for email rule changes and user account activities to detect similar threats in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze related security events.
-- Restore any affected systems or accounts to their operational state by removing unauthorized changes and verifying system integrity.
-- Apply security hardening measures, such as enabling multi-factor authentication (MFA) for all users and restricting the ability to create forwarding rules to trusted users.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
index 4261c630c4e..ceb1b377150 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
@@ -4,7 +4,7 @@ integration = ["o365"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/09"
 
 [rule]
 author = ["Elastic", "Willem D'Haese", "Austin Songer"]
@@ -86,52 +86,6 @@ from logs-o365.audit-*
 // filter for users with more than 20 login sources or failed login attempts
 | where (login_source_count >= 20 or failed_login_count >= 20)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Attempts to Brute Force a Microsoft 365 User Account
-
-Microsoft 365 is a cloud-based suite offering productivity and collaboration tools. Adversaries may exploit its authentication mechanisms by attempting brute-force attacks, trying numerous password combinations to gain unauthorized access. The detection rule identifies such attempts by analyzing audit logs for unusual patterns, such as a high number of failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity.
-
-### Possible investigation steps
-
-- Review the `o365.audit.UserId` field to identify the specific user account targeted by the brute-force attempt and check for any unusual activity associated with this account.
-- Examine the `source.ip` field to identify the IP addresses involved in the failed login attempts. Cross-reference these IPs with threat intelligence sources to determine if they are known for malicious activity.
-- Analyze the `target_time_window` to understand the timeframe of the brute-force attempt and correlate it with other security events or alerts that occurred during the same period.
-- Investigate the `event.provider` field to determine whether the brute-force attempts were made against Azure Active Directory or Exchange, which may provide insights into the attacker's target.
-- Check the `o365.audit.LogonError` field to identify the specific errors encountered during the login attempts, which may indicate the attacker's method or level of access.
-- Utilize the `event.action` field to confirm the nature of the failed login attempts, ensuring they align with the expected actions for a brute-force attack.
-- Use Osquery to gather additional context on the affected user account. For example, run the following query to check recent login activities on the user's device:
-  ```sql
-  SELECT * FROM logins WHERE user = '<o365.audit.UserId>';
-  ```
-- Investigate the `o365.audit.ExtendedProperties.RequestType` field to determine the type of login request, which may help identify if the attacker is using a specific method or tool.
-- Review the `o365.audit.Target.Type` field to understand the type of target involved in the login attempts, which can help differentiate between user and application logins.
-- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather a comprehensive view of the attack and its potential impact.
-
-### False positive analysis
-
-- High volume of legitimate login attempts: Users or applications that frequently log in from multiple locations or devices may trigger the rule. To manage this, create exceptions for known IP addresses or user accounts that are verified as non-threatening.
-- Automated scripts or services: Some organizations use automated scripts or services that log in to Microsoft 365 accounts for legitimate purposes, which may appear as brute-force attempts. Identify these scripts and whitelist their IP addresses or user accounts to prevent false positives.
-- Shared accounts: Accounts used by multiple users across different locations can generate numerous login attempts from various sources. Consider implementing stricter access controls or monitoring these accounts separately to reduce false positives.
-- Frequent password changes: Users who frequently change their passwords may inadvertently cause multiple failed login attempts. Educate users on best practices for password management and consider excluding these accounts from the rule if they are known to follow security protocols.
-- Security testing: Internal security teams conducting penetration tests or security assessments may trigger the rule. Coordinate with these teams to whitelist their activities during testing periods to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
-- Conduct a thorough investigation of the audit logs to identify the source IP addresses involved in the brute-force attempts and block these IPs at the firewall or network level.
-- Reset the password for the compromised user account and enforce a strong password policy to prevent easy guessing.
-- Enable multi-factor authentication (MFA) for the affected account and other high-risk accounts to add an additional layer of security.
-- Review and update conditional access policies to restrict access based on location, device compliance, and other risk factors.
-- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been targeted.
-- Implement enhanced logging and monitoring policies to capture detailed authentication events and integrate with a Security Information and Event Management (SIEM) system for real-time analysis.
-- Conduct a security awareness training session for users to educate them on recognizing phishing attempts and the importance of using strong, unique passwords.
-- Restore the system to its operational state by verifying that no unauthorized changes were made during the attack and ensuring all security patches are up to date.
-- Harden the environment by reviewing and applying security best practices, such as disabling legacy authentication protocols and regularly reviewing access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
index 3e85ad70a16..7b2baeefe60 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/01"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/05"
 
 [rule]
 author = ["Elastic"]
@@ -22,52 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Deprecated - Potential Password Spraying of Microsoft 365 User Accounts"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Deprecated - Potential Password Spraying of Microsoft 365 User Accounts
-
-Microsoft 365 is a cloud-based suite offering productivity and collaboration tools, which relies on robust authentication mechanisms to secure user access. Adversaries may exploit these mechanisms through password spraying, a technique involving numerous login attempts with common passwords across many accounts. The detection rule identifies such attempts by monitoring failed logins from a single IP, flagging potential unauthorized access efforts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the number of failed login attempts from the specific IP address and verify if it meets the threshold of 25 failed attempts within 30 minutes.
-- Identify the IP address involved in the alert and perform a reverse DNS lookup to gather more information about its origin and whether it is associated with known malicious activity.
-- Cross-reference the IP address with threat intelligence sources to determine if it has been previously reported for suspicious or malicious activities.
-- Examine the list of user accounts targeted by the failed login attempts to identify any patterns, such as common roles or departments, which might indicate a targeted attack.
-- Check the event logs for successful logins from the same IP address to determine if any unauthorized access was achieved.
-- Analyze the timestamps of the failed login attempts to identify any unusual patterns or timing that could provide additional context about the attack.
-- Use Osquery to investigate the affected systems for any signs of compromise or unusual activity. For example, run the following Osquery query to check for recent login attempts on a specific system: `SELECT * FROM last WHERE username IN ('user1', 'user2', 'user3') AND time > (SELECT strftime('%s', 'now') - 1800);`
-- Investigate any other authentication-related events from the same IP address or involving the same user accounts to identify potential lateral movement or further attack attempts.
-- Review the organization's security policies and configurations for Microsoft 365 to ensure that they align with best practices for preventing password spraying attacks.
-- Collaborate with other teams, such as network or security operations, to gather additional context or logs that might assist in the investigation, such as firewall logs or network traffic analysis.
-
-### False positive analysis
-
-- High volume of failed login attempts from a single IP may occur due to legitimate reasons such as users mistyping passwords or using outdated credentials, especially after a password change policy is enforced.
-- Automated scripts or applications that use outdated credentials for authentication can trigger false positives if they repeatedly attempt to log in.
-- Shared IP addresses, such as those from corporate networks or VPNs, can result in multiple failed login attempts being logged from the same IP, even if they originate from different users.
-- To manage these false positives, users can create exceptions for known IP addresses associated with trusted networks or services.
-- Implementing a monitoring system to track and whitelist IP addresses that consistently show non-threatening behavior can help reduce false positives.
-- Regularly updating and maintaining a list of known applications or scripts that may cause failed login attempts can assist in excluding these from triggering alerts.
-
-### Response and remediation
-
-- Immediately block the IP address from which the failed login attempts originated to prevent further unauthorized access attempts.
-- Review the affected user accounts for any signs of successful unauthorized access or suspicious activity and reset passwords as necessary.
-- Enable multi-factor authentication (MFA) for all user accounts to add an additional layer of security against password spraying attacks.
-- Conduct a thorough investigation of the logs to identify any other IP addresses or accounts that may be involved in similar activities.
-- Escalate the incident to the security operations center (SOC) or relevant IT security team for further analysis and response.
-- Implement or enhance logging policies to ensure comprehensive capture of authentication events, including both successful and failed login attempts.
-- Integrate threat intelligence feeds to identify known malicious IP addresses and enhance detection capabilities.
-- Educate users on the importance of using strong, unique passwords and the risks associated with password spraying attacks.
-- Restore any affected systems or accounts to their operational state by ensuring all security patches are applied and configurations are secure.
-- Review and update security policies and procedures to incorporate lessons learned from the incident and improve future response efforts.
-
-This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
+note = """This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
 risk_score = 73
 rule_id = "3efee4f0-182a-40a8-a835-102c68a4175d"
 severity = "high"
diff --git a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
index 8771996d827..f74a123e361 100644
--- a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
+++ b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,51 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Excessive Single Sign-On Logon Errors"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 O365 Excessive Single Sign-On Logon Errors
-
-Single Sign-On (SSO) streamlines user access across multiple applications using one set of credentials, enhancing user experience and security. However, adversaries may exploit SSO by attempting brute force attacks to gain unauthorized access. The detection rule monitors for unusual spikes in SSO logon errors, specifically targeting invalid or expired tokens, to identify potential brute force attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific account(s) associated with the excessive SSO logon errors, focusing on the `o365.audit.LogonError` field for "SsoArtifactInvalidOrExpired".
-- Check the timestamp of the logon errors to determine if there is a pattern or specific time frame when the errors occurred.
-- Investigate the source IP addresses associated with the logon attempts to identify any unusual or suspicious locations, using the `event.dataset` and `event.provider` fields for context.
-- Correlate the identified IP addresses with known threat intelligence sources to check for any malicious activity or reputation.
-- Examine the user account's recent activity logs for any other anomalies or unusual behavior, such as logins from different geographic locations or changes in user settings.
-- Use Osquery to gather additional context on the affected systems. For example, run a query to list recent login attempts: `SELECT * FROM logon_sessions WHERE logon_type = 'SSO' AND status = 'failed';`
-- Analyze the frequency and volume of the logon errors to determine if they align with typical brute force attack patterns.
-- Check for any recent changes in the user's account settings or permissions that could have triggered the errors.
-- Investigate if there are any other accounts experiencing similar logon errors, which could indicate a broader attack.
-- Review any recent security updates or changes in the SSO configuration that might have inadvertently caused the logon errors.
-
-### False positive analysis
-
-- Users with expired passwords or tokens may trigger excessive SSO logon errors, leading to false positives. Regularly updating credentials and tokens can help mitigate this issue.
-- Automated scripts or applications using outdated credentials can cause repeated logon errors. Ensure that all automated processes are updated with current credentials to prevent unnecessary alerts.
-- Users frequently accessing multiple applications simultaneously might experience token expiration, resulting in logon errors. Consider extending token expiration times for specific users or applications to reduce false positives.
-- Network latency or connectivity issues can lead to repeated logon attempts and errors. Monitoring network performance and addressing connectivity issues can help minimize these occurrences.
-- Implement exception rules for known non-threatening behaviors, such as specific users or IP addresses that consistently generate logon errors due to legitimate reasons, to prevent them from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected accounts to prevent further unauthorized access and reset their passwords.
-- Review the logs for the affected accounts to identify any successful logins or suspicious activities following the logon errors.
-- Conduct a thorough investigation to determine if the logon errors are part of a broader brute force attack or if they are isolated incidents.
-- Escalate the incident to the security operations center (SOC) or incident response team if there is evidence of a coordinated attack or if sensitive data may have been accessed.
-- Implement multi-factor authentication (MFA) for all users to add an additional layer of security against brute force attacks.
-- Enhance logging policies to ensure detailed records of authentication attempts and errors are captured for future analysis.
-- Integrate threat intelligence feeds to correlate logon errors with known malicious IP addresses or threat actors.
-- Educate users on recognizing phishing attempts and the importance of using strong, unique passwords to reduce the risk of credential compromise.
-- Restore affected systems and accounts to their operational state by ensuring all security patches are applied and configurations are hardened.
-- Regularly review and update security policies and procedures to address any gaps identified during the investigation and to improve the organization's overall security posture.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 73
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
index 9c0d0481195..77bc6a6dfa9 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange DLP Policy Removed"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange DLP Policy Removed
-
-Microsoft 365 Exchange DLP policies are crucial for preventing unauthorized data sharing by monitoring and controlling sensitive information flow. Adversaries may remove these policies to bypass data protection measures, facilitating data exfiltration. The detection rule identifies successful removal actions by analyzing specific audit events, signaling potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `o365.audit`, the event provider is `Exchange`, and the event action is `Remove-DlpPolicy` with a successful outcome.
-- Correlate the timestamp of the alert with other logs to identify any concurrent suspicious activities or anomalies in the environment.
-- Identify the user account associated with the `Remove-DlpPolicy` action and verify if the account has legitimate reasons or permissions to perform such actions.
-- Check the user's recent activity logs for any unusual or unauthorized actions, such as changes in permissions or access to sensitive data.
-- Investigate the IP address and location from which the `Remove-DlpPolicy` action was initiated to determine if it aligns with the user's typical access patterns.
-- Examine the audit logs for any preceding failed attempts to remove DLP policies, which might indicate persistent attempts to bypass security controls.
-- Utilize Osquery to gather additional context on the user's device by running a query such as: `SELECT * FROM users WHERE username = '<suspicious_user>';` to check for any anomalies or unauthorized software.
-- Review the organization's change management records to verify if the DLP policy removal was part of an approved change request.
-- Analyze any recent changes to the organization's security policies or configurations that might have inadvertently allowed the DLP policy removal.
-- Consult with the security team to determine if there are any ongoing investigations or incidents that might be related to the DLP policy removal event.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may remove DLP policies as part of regular maintenance or updates, which can trigger false positives. To manage this, organizations can create exceptions for known administrative accounts or schedule maintenance windows where such actions are expected.  
-- Policy updates and migrations: During policy updates or migrations, DLP policies might be temporarily removed and reconfigured, leading to false positives. Users can handle this by documenting and excluding these activities during planned update periods.  
-- Testing and development environments: In testing or development environments, DLP policies may be frequently added and removed for testing purposes. To reduce false positives, these environments can be excluded from monitoring or flagged as low-risk.  
-- Automated scripts or tools: Automated processes that manage DLP policies might inadvertently trigger the rule. Identifying and excluding these scripts or tools from monitoring can help minimize false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected user account to prevent further unauthorized actions and assess if any other accounts have been compromised.
-- Review audit logs to identify the scope of the policy removal, including the user who performed the action and any associated IP addresses or devices.
-- Reapply the removed DLP policy and verify that all other DLP policies are intact and functioning as expected.
-- Conduct a thorough investigation to determine if any sensitive data was exfiltrated during the period the DLP policy was inactive.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this action is part of a larger attack.
-- Implement enhanced logging and monitoring for DLP policy changes, ensuring that alerts are generated for any future modifications.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate this event with other suspicious activities across the network.
-- Educate users on the importance of DLP policies and the risks associated with unauthorized changes to these policies.
-- Restore any affected systems to their operational state by ensuring all security configurations are correctly applied and verified.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify DLP policies, reducing the risk of future unauthorized changes.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
index 2c98367720f..ec5a1d9bbc5 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Malware Filter Policy Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Malware Filter Policy Deletion
-
-Microsoft 365 Exchange uses malware filter policies to detect and alert administrators about emails containing malware, which helps in identifying potential account or machine compromises. Adversaries may delete these policies to bypass detection mechanisms, facilitating undetected malicious activities. The detection rule monitors audit logs for successful deletions of these policies, signaling potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the audit logs for the specific event.action:"Remove-MalwareFilterPolicy" to confirm the deletion event and gather details such as the timestamp, user account involved, and the IP address from which the action was performed.
-- Cross-reference the user account identified in the deletion event with recent login activity to determine if there are any unusual or suspicious login patterns, such as logins from unfamiliar locations or IP addresses.
-- Investigate the event.outcome:success field to ensure that the deletion was indeed successful and not a failed attempt, which might indicate a different type of issue or misconfiguration.
-- Examine the event.provider:Exchange and event.category:web fields to verify that the event is correctly categorized and associated with the Exchange service, ensuring the alert is not a false positive.
-- Utilize Osquery to gather additional context on the user account involved in the deletion. For example, run a query to list recent activities by the user: `SELECT * FROM users WHERE username = 'suspected_user';`
-- Check for any recent changes to permissions or roles associated with the user account to determine if they were granted elevated privileges that could have allowed the policy deletion.
-- Investigate other security logs and alerts around the same timeframe to identify any correlated events or activities that might indicate a broader attack or compromise.
-- Review the organization's change management records to verify if the deletion was part of an authorized change or maintenance activity, potentially ruling out malicious intent.
-- Analyze email logs to identify any recent emails sent by the user account that might have contained malware, which could suggest a motive for deleting the malware filter policy.
-- Consult with other security team members or stakeholders to gather additional insights or context that might aid in understanding the significance of the policy deletion and any potential impact on the organization.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may delete malware filter policies as part of regular maintenance or policy updates. To manage this, organizations can create exceptions for known administrative accounts or schedule maintenance windows where such activities are expected.
-- Policy reconfiguration: During reconfiguration or migration of policies, deletions might occur as part of the process. Users can handle these by documenting and approving such changes in advance, allowing for temporary exceptions during the reconfiguration period.
-- Testing and development environments: In environments where policies are frequently created and deleted for testing purposes, these actions might trigger false positives. To mitigate this, users can exclude specific test accounts or environments from the detection rule.
-- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage their Microsoft 365 environment, which might include policy deletions. Identifying and excluding these scripts or tools from the detection rule can help reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate affected accounts or systems to prevent further malicious activity and contain the threat.
-- Review audit logs and email logs to identify any other suspicious activities or policy deletions that may indicate a broader compromise.
-- Conduct a thorough investigation to determine the scope of the compromise, including identifying any other compromised accounts or systems.
-- Restore the deleted malware filter policy from a backup or recreate it to ensure continued protection against malware threats.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for Microsoft 365 Exchange to detect similar activities in the future, ensuring audit logs are retained for an appropriate duration.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Educate users and administrators on recognizing phishing attempts and the importance of maintaining security policies.
-- Apply security patches and updates to all systems and applications to mitigate vulnerabilities that could be exploited by adversaries.
-- Review and strengthen access controls and permissions to ensure that only authorized personnel can modify or delete security policies.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
index 12743ce2a87..3a8e0b5063c 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,52 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Malware Filter Rule Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Malware Filter Rule Modification
-
-Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to delete or disable these rules to bypass security measures, facilitating the delivery of harmful payloads. The detection rule monitors audit logs for successful actions that remove or disable malware filter rules, signaling potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the audit logs for the specific `event.action` values "Remove-MalwareFilterRule" or "Disable-MalwareFilterRule" to confirm the alert's validity and gather initial context.
-- Examine the `event.outcome` field to ensure the action was successful, as unsuccessful attempts may indicate a different type of issue or misconfiguration.
-- Identify the `event.provider` and `event.category` fields to confirm that the event is related to Exchange and web activities, ensuring the alert is relevant to the Microsoft 365 environment.
-- Investigate the user account associated with the action by reviewing the `user.name` and `user.id` fields to determine if the account is legitimate or potentially compromised.
-- Check the `source.ip` and `source.geo.location` fields to identify the origin of the action, looking for unusual or unexpected locations that might indicate unauthorized access.
-- Analyze the `event.time` field to establish a timeline of events, correlating with other security events or anomalies that occurred around the same time.
-- Use Osquery to further investigate the user account and device involved. For example, run a query to list recent logins: `SELECT * FROM users WHERE username = 'suspicious_user';`
-- Review any recent changes to permissions or roles associated with the user account to determine if they have been granted elevated privileges that could facilitate such actions.
-- Cross-reference the alert with other security tools and logs, such as endpoint protection or network monitoring, to identify any related suspicious activities or patterns.
-- Consult with the IT or security team to verify if the action was part of a legitimate administrative task or change management process, potentially ruling out malicious intent.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may occasionally remove or disable malware filter rules as part of regular maintenance or updates, which can trigger false positives. 
-- Policy updates: Changes in organizational security policies might necessitate the modification of malware filter rules, leading to alerts that are not indicative of malicious activity.
-- Testing and troubleshooting: Security teams may disable or remove rules temporarily for testing or troubleshooting purposes, which can be mistaken for suspicious behavior.
-- To manage these false positives, organizations can implement exception lists that include known and trusted administrative accounts or IP addresses involved in regular maintenance activities.
-- Regularly review and update the exception lists to ensure they reflect current administrative practices and personnel changes, minimizing unnecessary alerts.
-- Implement a change management process that logs and approves legitimate rule modifications, providing context for alerts and reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Immediately isolate affected accounts or systems to prevent further unauthorized changes to malware filter rules.
-- Conduct a thorough investigation to identify the source of the modification, including reviewing audit logs and correlating with other security events.
-- Verify the integrity of other security configurations and rules within Microsoft 365 to ensure no additional unauthorized changes have been made.
-- Restore the deleted or disabled malware filter rules from backups or recreate them based on documented configurations.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for Microsoft 365, focusing on changes to security configurations and rules.
-- Integrate threat intelligence feeds to correlate with observed activities and identify potential indicators of compromise.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify security rules.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
-- Educate and train staff on recognizing and reporting suspicious activities related to security rule modifications.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
index 6decdea9f6a..9d9933ff325 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Safe Attachment Rule Disabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Safe Attachment Rule Disabled
-
-Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect malware. Disabling this rule can expose organizations to threats, as it allows potentially harmful attachments to bypass scrutiny. Adversaries may exploit this by disabling the rule to facilitate data exfiltration or evade detection. The detection rule monitors audit logs for successful attempts to disable this feature, alerting security teams to potential misuse.
-
-### Possible investigation steps
-
-- Review the audit logs for the specific event.action "Disable-SafeAttachmentRule" to confirm the alert's validity and gather initial context.
-- Identify the user account associated with the event by examining the user information in the audit logs, focusing on the event.dataset:o365.audit and event.provider:Exchange fields.
-- Check the event.outcome field to ensure the action was successful, confirming that the rule was indeed disabled.
-- Investigate the timing of the event by analyzing the timestamp to determine if it coincides with any other suspicious activities or known incidents.
-- Correlate the event with other logs or alerts around the same timeframe to identify any patterns or additional suspicious activities.
-- Examine the user's recent activity history in Microsoft 365 to identify any unusual behavior or deviations from their normal activity patterns.
-- Use Osquery to gather more information about the user's device and recent activities. For example, run a query to list recent logins: `SELECT * FROM users WHERE username = 'suspected_user';`
-- Investigate any recent changes to security settings or configurations in Microsoft 365 that might indicate a broader attempt to impair defenses.
-- Check for any other recent successful or failed attempts to disable security features in Microsoft 365, which could indicate a larger attack strategy.
-- Collaborate with other security team members to cross-reference findings with threat intelligence sources to determine if the activity aligns with known threat actor behaviors or tactics.
-
-### False positive analysis
-
-- Routine administrative actions: Sometimes, IT administrators may disable the Safe Attachment Rule temporarily for maintenance or troubleshooting purposes. These actions, while legitimate, can trigger alerts. To manage this, organizations can create exceptions for specific user accounts or IP addresses known to perform these tasks regularly.
-- Automated scripts or tools: Certain automated processes or third-party tools might disable the rule as part of their operation. Identifying these tools and excluding their actions from alerts can reduce false positives.
-- Policy updates or changes: During policy updates or configuration changes, the rule might be disabled as part of the process. Documenting these changes and excluding them from alerts can help in managing false positives.
-- Testing environments: In testing or development environments, the rule might be disabled to simulate scenarios or test new configurations. Excluding these environments from monitoring can prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately re-enable the Safe Attachment Rule in Microsoft 365 to restore protection against malicious attachments.
-- Conduct a thorough investigation to identify the user or account responsible for disabling the rule and assess their access privileges.
-- Review audit logs to determine the scope of potential exposure and identify any suspicious activities or data exfiltration attempts.
-- Isolate any systems or accounts that may have been compromised to prevent further unauthorized access or data loss.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement additional logging and monitoring to capture detailed events related to email security settings and rule changes.
-- Integrate threat intelligence feeds to enhance detection capabilities and correlate with known threat actor behaviors.
-- Educate employees on the importance of email security and the risks associated with disabling security features.
-- Restore any affected systems to a known good state and apply security patches and updates to mitigate vulnerabilities.
-- Review and update security policies and procedures to include regular audits of security configurations and rule settings.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
index e0945e59b03..c702bee9a9c 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/13"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Mailbox Audit Logging Bypass"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 O365 Mailbox Audit Logging Bypass
-
-O365 Mailbox Audit Logging is crucial for tracking mailbox activities, ensuring transparency and security. However, bypass associations can be configured to exclude certain accounts from logging, often for operational efficiency. Adversaries exploit this by adding malicious accounts to the bypass list, concealing their actions. The detection rule identifies successful bypass configurations, signaling potential abuse by monitoring specific audit events.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific account associated with the `Set-MailboxAuditBypassAssociation` event and verify the `event.outcome:success` field to confirm the bypass was successfully configured.
-- Cross-reference the account in question with known authorized accounts that may have legitimate reasons for bypassing audit logging, such as service accounts or accounts used by third-party tools.
-- Examine the `event.dataset:o365.audit` and `event.provider:Exchange` fields to gather additional context about the environment and the specific actions taken.
-- Investigate recent activities associated with the account by querying O365 audit logs for any unusual or unauthorized actions that might have been performed by the account.
-- Utilize Osquery to gather additional information about the system and user activities. For example, run a query to list recent login events: `SELECT * FROM users WHERE username = 'suspicious_account';`.
-- Check for any recent changes in permissions or roles for the account in question that might indicate privilege escalation or unauthorized access.
-- Analyze the timeline of events leading up to the bypass configuration to identify any preceding suspicious activities or anomalies.
-- Investigate any other accounts that have been added to the bypass list recently to determine if there is a pattern or coordinated effort to conceal malicious activities.
-- Review the organization's policy and documentation regarding audit logging bypass to ensure the configuration aligns with operational requirements and security policies.
-- Consult with the IT or security team to verify if there were any legitimate operational needs or changes that could justify the bypass configuration for the account.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate administrative actions where certain accounts are intentionally added to the bypass list for operational efficiency, such as service accounts used by third-party applications or monitoring tools that generate excessive log entries.
-- To manage these false positives, organizations can create exceptions by maintaining a documented list of approved accounts that are allowed to bypass audit logging. This list should be regularly reviewed and updated to ensure it only includes accounts necessary for business operations.
-- Implementing a review process for any changes to the bypass list can help distinguish between legitimate and potentially malicious modifications, reducing the risk of overlooking unauthorized actions.
-- Users should consider correlating bypass events with other security logs and alerts to verify the legitimacy of the bypass configuration, ensuring that it aligns with expected behavior and does not coincide with other suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected accounts by removing them from the bypass list to prevent further unauthorized actions.
-- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities associated with the affected accounts.
-- Review and validate the list of accounts with bypass associations to ensure only legitimate accounts are included.
-- Escalate the incident to the security operations team for a deeper analysis of potential compromise and to assess the scope of the breach.
-- Implement enhanced logging policies to capture detailed audit logs for all accounts, including those with bypass associations, to improve visibility.
-- Integrate security information and event management (SIEM) tools to correlate audit logs with other security events for comprehensive threat detection.
-- Restore any altered or deleted mailbox data from backups to ensure data integrity and continuity of operations.
-- Apply security patches and updates to the O365 environment to mitigate any known vulnerabilities that could be exploited.
-- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
-- Educate and train administrators on the risks associated with audit logging bypass and the importance of maintaining strict access controls.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://twitter.com/misconfig/status/1476144066807140355"]
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
index 6700bf68169..b000de68c75 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,51 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Transport Rule Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Transport Rule Creation
-
-Microsoft 365 Exchange transport rules manage email flow and apply specific actions to messages. Adversaries may exploit these rules to redirect emails to external domains, facilitating data exfiltration. The detection rule monitors successful creation of new transport rules, focusing on web-based actions within Exchange, to identify potential misuse indicative of such malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.action field with the value "New-TransportRule" and ensure the event.outcome is marked as success.
-- Examine the event.dataset field to verify it is set to o365.audit and the event.provider field is Exchange, confirming the source of the alert.
-- Check the event.category field for the value web to ensure the rule creation was performed through a web-based interface, which might indicate unauthorized access.
-- Identify the user account associated with the transport rule creation by reviewing the user.name or user.id fields in the alert details.
-- Investigate the IP address from which the transport rule was created using the source.ip field to determine if it is from a known or suspicious location.
-- Analyze the transport rule's configuration, focusing on any actions that forward emails to external domains, which could indicate data exfiltration attempts.
-- Review recent login activities for the user account involved, looking for unusual patterns or locations, using Microsoft 365 audit logs.
-- Use Osquery to gather additional context on the user account and recent activities. Example query: `SELECT * FROM users WHERE username = '<user.name from alert>';`
-- Check for any other recent changes in the Microsoft 365 environment, such as modifications to user permissions or other transport rules, that could be related to the alert.
-- Correlate this alert with other security events or alerts in your environment to identify potential patterns or coordinated activities that might indicate a broader attack.
-
-### False positive analysis
-
-- Legitimate administrative activities: IT administrators may create transport rules for valid business purposes, such as managing email flow or applying compliance policies. Regular audits and communication with the IT team can help distinguish between legitimate and suspicious rule creations.
-- Automated system processes: Some automated systems or third-party applications integrated with Microsoft 365 might create transport rules as part of their normal operation. Identifying these systems and documenting their expected behavior can help in excluding them from alerts.
-- Testing and development environments: Transport rules might be created frequently in testing or development environments as part of routine testing procedures. Excluding these environments from monitoring or setting up specific alerts for production environments only can reduce false positives.
-- Organizational changes: During mergers, acquisitions, or organizational restructuring, transport rules may be created to facilitate email redirection and communication. Understanding the context of these changes and temporarily adjusting monitoring criteria can help manage false positives.
-- To handle these false positives, users can create exceptions for known non-threatening behaviors by maintaining an allowlist of trusted administrators, systems, and environments. Regularly updating this list and reviewing transport rule creation logs can ensure that only suspicious activities trigger alerts.
-
-### Response and remediation
-
-- Immediately disable the newly created transport rule to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the source of the rule creation, including reviewing audit logs for suspicious activities around the time of the rule creation.
-- Verify if any data was exfiltrated by analyzing email logs and any external communications initiated by the transport rule.
-- Escalate the incident to the security operations team for a deeper analysis and to determine if other systems or accounts have been compromised.
-- Reset credentials and enforce multi-factor authentication for any accounts involved in the incident to prevent unauthorized access.
-- Implement stricter transport rule policies to prevent the creation of rules that forward emails to external domains without proper authorization.
-- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities in the future.
-- Conduct a security awareness training session for administrators to recognize and respond to suspicious activities related to transport rules.
-- Restore the system to its operational state by ensuring all unauthorized changes are reverted and verifying the integrity of the email system.
-- Apply hardening measures such as restricting administrative access to the Exchange management interface and regularly reviewing transport rule configurations.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
index 1ae057908ae..1d3f8d6595f 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Transport Rule Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Transport Rule Modification
-
-Microsoft 365 Exchange transport rules manage email flow by applying specific actions to messages. Adversaries may exploit these rules to disable or delete them, facilitating data exfiltration or bypassing security measures. The detection rule monitors successful actions of rule removal or disabling, signaling potential misuse by tracking specific event categories and actions within the audit logs.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.dataset is "o365.audit" and the event.provider is "Exchange" to ensure the alert is related to Microsoft 365 Exchange.
-- Verify the event.category is "web" and the event.action is either "Remove-TransportRule" or "Disable-TransportRule" to confirm the specific actions that triggered the alert.
-- Check the event.outcome field to ensure the action was successful, indicating that a transport rule was indeed removed or disabled.
-- Identify the user account associated with the action by examining the user.name or user.id fields in the audit logs to determine if the action was performed by an authorized user or a potential adversary.
-- Investigate the timestamp of the event to establish a timeline and correlate it with other suspicious activities or anomalies in the environment.
-- Examine the source IP address and location from which the action was performed to identify any unusual or unauthorized access patterns.
-- Review the history of changes to transport rules in the audit logs to identify any patterns or repeated attempts to modify rules by the same user or IP address.
-- Utilize Osquery to gather additional context on the user account involved. For example, run a query to list recent login activities: `SELECT * FROM users WHERE username = '<user.name>'`.
-- Cross-reference the identified user account and IP address with known threat intelligence sources to check for any associations with malicious activity.
-- Investigate any related email flow logs to determine if there was any data exfiltration or unauthorized email forwarding that coincided with the transport rule modification.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may regularly disable or remove transport rules as part of routine maintenance or updates. To manage these, organizations can create exceptions for specific user accounts or roles known to perform these tasks frequently.
-- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage transport rules, which might trigger the detection rule. Users can handle these by identifying and excluding the specific scripts or tools from the monitoring process.
-- Testing and development environments: Changes in transport rules might occur frequently in testing or development environments. To reduce false positives, users can exclude these environments from the detection scope or adjust the rule to focus on production environments only.
-- Scheduled policy updates: Organizations may have scheduled updates to transport rules that coincide with policy changes or compliance requirements. Users can manage these by documenting the schedule and creating temporary exceptions during these periods.
-
-### Response and remediation
-
-- Immediately isolate the affected user accounts and systems to prevent further unauthorized actions.
-- Conduct a thorough investigation to determine the scope of the rule modification, identifying any data exfiltration or security bypass attempts.
-- Review audit logs to trace the origin of the modification, focusing on user activity and access patterns around the time of the event.
-- Re-enable or recreate the disabled or deleted transport rules to restore email flow security measures.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed user actions and changes to transport rules for future monitoring.
-- Integrate additional security tools, such as SIEM solutions, to correlate events and improve detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update policies or procedures as necessary.
-- Educate users on security best practices and the importance of maintaining transport rule integrity.
-- Apply hardening measures, such as multi-factor authentication and least privilege access, to reduce the risk of unauthorized modifications.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
index 014db96c20b..ad5ac070602 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2025/01/08"
+updated_date = "2023/06/22"
 
 [rule]
 author = ["Austin Songer"]
@@ -13,51 +13,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Mass download by a single user"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Mass download by a single user
-
-Microsoft 365's cloud services facilitate seamless data access and collaboration. However, adversaries may exploit these capabilities to exfiltrate data by downloading large volumes rapidly. The detection rule identifies suspicious activity by flagging instances where a user downloads over 50 files in a minute, leveraging audit logs to pinpoint potential data exfiltration attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `SecurityComplianceCenter`, ensuring the alert is genuine and not a false positive.
-- Verify the event category is `web` and the event action is "Mass download by a single user" to confirm the nature of the activity.
-- Check the event outcome to ensure it is marked as `success`, indicating the downloads were completed.
-- Identify the user account involved in the mass download and gather additional context about the user's role and typical behavior within the organization.
-- Analyze the time and date of the downloads to determine if they coincide with any known business activities or if they occurred during unusual hours.
-- Investigate the IP address and location from which the downloads were initiated to assess if they align with the user's normal access patterns.
-- Examine the types and sensitivity of the files downloaded to evaluate the potential impact of the data exfiltration.
-- Use Osquery to gather more information about the user's device, such as running processes or recent network connections, with a query like: `SELECT * FROM processes WHERE user = '<username>';`
-- Review recent login activity for the user in Microsoft 365 to identify any anomalies or unauthorized access attempts.
-- Cross-reference the user's activity with other security logs and alerts to identify any correlated suspicious behavior or potential indicators of compromise.
-
-### False positive analysis
-
-- Legitimate business activities: Users involved in data-intensive roles, such as data analysts or IT administrators, may legitimately download large volumes of files for business purposes. These activities can be mistaken for suspicious behavior.
-- Automated processes: Scheduled scripts or automated tools that download files for backup or synchronization purposes can trigger the rule. These processes are typically non-threatening and should be reviewed for legitimacy.
-- Software updates: IT departments may download software updates or patches in bulk, which can result in a high number of downloads within a short period.
-- Training or onboarding sessions: New employees or users undergoing training may download numerous files as part of their onboarding process or training materials.
-- To manage false positives, organizations can create exceptions for known users or processes that regularly perform high-volume downloads. This can be done by maintaining a whitelist of users or IP addresses associated with legitimate activities. Additionally, reviewing and updating the detection rule parameters to better align with the organization's typical usage patterns can help reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further data exfiltration.
-- Review the audit logs to confirm the scope of the downloads and identify any other potentially compromised accounts.
-- Conduct a thorough investigation to determine if the downloads were authorized or if they indicate malicious activity.
-- If malicious activity is confirmed, reset the affected user's password and enforce multi-factor authentication (MFA) for all users.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed user activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Review and update data access policies to ensure that only necessary permissions are granted to users.
-- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials.
-- Restore any affected systems or data from backups if data integrity is compromised.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
index 96619440cb4..d249e245d1a 100644
--- a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
+++ b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,51 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Potential ransomware activity"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Potential ransomware activity
-
-Microsoft 365's Cloud App Security monitors user activities to identify potential ransomware threats, such as suspicious file uploads. Adversaries may exploit cloud storage to distribute or store ransomware, encrypting data for impact. The detection rule leverages audit logs to flag successful web actions linked to ransomware, aligning with MITRE ATT&CK's impact tactics, ensuring timely threat identification and response.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.dataset is "o365.audit" and the event.provider is "SecurityComplianceCenter" to ensure the alert is from a legitimate source.
-- Verify the event.category is "web" and the event.action is "Potential ransomware activity" to confirm the nature of the alert.
-- Check the event.outcome field to ensure it is marked as "success," indicating the action was completed and potentially harmful.
-- Identify the user account involved in the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the timestamp of the alert to correlate with other security events or anomalies that may have occurred around the same time.
-- Investigate the specific files uploaded by the user by reviewing file names, types, and sizes to identify any unusual or suspicious characteristics.
-- Utilize Osquery to gather additional context on the user's activity. For example, run a query to list recent file modifications: `SELECT * FROM file WHERE path LIKE '/path/to/suspected/files/%';`
-- Cross-reference the user's IP address and location with known locations for the user to identify any discrepancies or unusual access patterns.
-- Analyze audit logs for any other recent activities by the same user that may indicate a broader pattern of suspicious behavior.
-- Collaborate with other security teams to gather additional intelligence or context on the potential ransomware activity, leveraging threat intelligence feeds if available.
-
-### False positive analysis
-
-- Legitimate file uploads by users, such as regular backups or large data transfers, may trigger the rule as potential ransomware activity due to the volume or nature of the files.
-- Automated processes or scripts that upload files to the cloud as part of routine operations can be mistakenly flagged as ransomware activity.
-- Users can manage these false positives by creating exceptions for known safe activities, such as whitelisting specific users or processes that regularly perform large uploads.
-- Implementing a review process for flagged activities can help distinguish between genuine threats and benign actions, allowing for more accurate threat detection.
-- Regularly updating the list of exceptions based on user feedback and activity patterns can reduce the occurrence of false positives over time.
-
-### Response and remediation
-
-- Immediately isolate the affected user account and device from the network to prevent further spread of the ransomware.
-- Conduct a thorough investigation of the audit logs to identify the scope of the ransomware activity and determine if other accounts or systems are compromised.
-- Remove any identified malicious files from the cloud storage and ensure they are quarantined for further analysis.
-- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional resources are needed.
-- Restore any encrypted or compromised files from the most recent clean backup to ensure data integrity and availability.
-- Implement or review existing logging policies to ensure comprehensive monitoring of user activities and cloud interactions for early detection of similar threats.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to enhance visibility and response capabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users on recognizing phishing attempts and suspicious activities to reduce the risk of future ransomware infections.
-- Apply security hardening measures, such as enabling multi-factor authentication (MFA) and ensuring all systems are patched and up-to-date, to mitigate potential vulnerabilities.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
index 0f874db7647..91ff9f58844 100644
--- a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
+++ b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -13,51 +13,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Unusual Volume of File Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Unusual Volume of File Deletion
-
-Microsoft 365's cloud services facilitate collaboration and data management, but adversaries can exploit these features to delete large volumes of files, causing data loss. This detection rule leverages Microsoft Cloud App Security to identify and alert on such unusual file deletion activities, which may indicate malicious intent, aligning with MITRE ATT&CK's data destruction techniques.
-
-### Possible investigation steps
-
-- Review the alert details in Microsoft Cloud App Security to understand the scope and context of the unusual file deletion event.
-- Verify the user account involved in the deletion by examining the `event.dataset` and `event.provider` fields to ensure the activity is associated with Microsoft 365 and the Security Compliance Center.
-- Check the `event.category` and `event.action` fields to confirm that the activity is categorized as web-based and specifically flagged as "Unusual volume of file deletion."
-- Analyze the `event.outcome` field to ensure the deletion activity was successful, which may indicate a higher risk of data loss.
-- Investigate the user's recent activity logs in Microsoft 365 to identify any other suspicious actions or patterns that could suggest malicious intent.
-- Correlate the user's activity with any recent changes in permissions or access levels that might have facilitated the unusual file deletion.
-- Use Osquery to gather additional context on the user's device, such as running processes or network connections, to identify any signs of compromise. Example query: `SELECT * FROM processes WHERE user = 'username';`
-- Examine the user's login history and IP addresses to detect any anomalies or unauthorized access attempts that could be related to the file deletion.
-- Cross-reference the alert with other security tools and logs to identify any concurrent alerts or incidents that might be linked to the same user or activity.
-- Consult with the user or their manager to verify if the file deletion was intentional and authorized, or if it was unexpected and potentially malicious.
-
-### False positive analysis
-
-- Routine administrative tasks: Large file deletions may occur during regular maintenance or data management activities by IT administrators. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
-- User-initiated cleanups: Users may delete large volumes of files as part of personal data organization or cleanup efforts. Implement user education and awareness programs to ensure such activities are reported or logged appropriately.
-- Automated processes: Some automated workflows or third-party applications may perform bulk deletions as part of their normal operation. Identify and whitelist these processes to prevent unnecessary alerts.
-- Migration activities: During data migration projects, significant file deletions might occur as data is moved or reorganized. Coordinate with project teams to anticipate these events and adjust monitoring rules accordingly.
-- Shared drive management: In environments with shared drives, users may delete large numbers of files to manage storage space. Establish policies for shared drive management and incorporate them into exception handling procedures.
-
-### Response and remediation
-
-- Immediately isolate the affected user account to prevent further unauthorized deletions and assess if the account has been compromised.
-- Conduct a thorough investigation to determine the scope of the deletion, including identifying the files deleted, the time frame, and any associated user activities.
-- Review audit logs and Microsoft Cloud App Security alerts to identify any other suspicious activities or patterns that may indicate a broader compromise.
-- Restore deleted files from backups or version history, ensuring data integrity and availability are maintained.
-- Escalate the incident to the security operations team if the deletion is determined to be part of a larger attack or if sensitive data is involved.
-- Implement stricter access controls and multi-factor authentication for users with permissions to delete large volumes of files.
-- Enhance logging and monitoring policies to ensure detailed tracking of file operations and user activities within Microsoft 365.
-- Integrate Microsoft 365 with a Security Information and Event Management (SIEM) system for real-time alerting and correlation with other security events.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on recognizing phishing attempts and secure handling of credentials to prevent account compromise.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
index bbfbeb76dfe..19722674349 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Anti-Phish Policy Deletion"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Anti-Phish Policy Deletion
-
-Microsoft 365's anti-phishing policies are crucial for enhancing email security by identifying and blocking phishing attempts. Adversaries may delete these policies to weaken defenses, facilitating phishing attacks. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity aimed at compromising email security.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the deletion event by filtering for `event.dataset:o365.audit` and `event.provider:Exchange` to ensure the event is related to Microsoft 365 Exchange.
-- Verify the `event.action:"Remove-AntiPhishPolicy"` to confirm that the action taken was indeed the removal of an anti-phishing policy.
-- Check the `event.outcome:success` field to ensure the deletion was successful, indicating a potential security concern.
-- Identify the user account associated with the deletion by examining the `user.name` field in the audit logs to determine if the action was performed by an authorized user.
-- Investigate the `source.ip` field to trace the IP address from which the deletion request originated, helping to identify if it was an internal or external source.
-- Cross-reference the `user.name` and `source.ip` with known user activity and location to detect any anomalies or unauthorized access patterns.
-- Utilize Osquery to gather additional context on the user account and device involved. For example, run a query like `SELECT * FROM users WHERE username = '<user.name>'` to gather more information about the user.
-- Check for any recent changes in user permissions or roles that might have allowed the deletion by reviewing the `event.category:web` logs for any privilege escalation activities.
-- Analyze other related security events around the same timestamp to identify any correlated activities, such as failed login attempts or unusual email forwarding rules.
-- Review the organization's change management records to verify if the deletion was part of a planned change or if it was unauthorized, providing further context to the investigation.
-
-### False positive analysis
-
-- Routine administrative actions: Legitimate IT administrators may delete anti-phishing policies as part of regular maintenance or policy updates. These actions can be mistaken for malicious activity.
-- Policy reconfiguration: Organizations may periodically review and reconfigure their security policies, including anti-phishing settings, which could involve deleting and recreating policies.
-- Testing and audits: Security teams might delete policies temporarily during testing phases or audits to evaluate system responses and ensure compliance.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific time frames when policy changes are expected. This can be done by setting up filters or rules in the monitoring system to exclude these non-threatening activities from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate affected accounts and systems to prevent further unauthorized access or damage.
-- Review audit logs to identify the source and scope of the policy deletion, focusing on user accounts and IP addresses involved.
-- Recreate and apply the deleted anti-phishing policy to restore email security defenses.
-- Conduct a thorough investigation to determine if any phishing attacks were successful during the period the policy was absent.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for Microsoft 365 activities, ensuring that all policy changes are tracked and alerted.
-- Integrate threat intelligence feeds to correlate the incident with known phishing campaigns or threat actors.
-- Educate users on recognizing phishing attempts and the importance of reporting suspicious emails.
-- Review and update access controls and permissions to ensure only authorized personnel can modify security policies.
-- Consider deploying additional security measures such as multi-factor authentication (MFA) and advanced threat protection (ATP) to harden the environment against future attacks.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
index b816965742e..71db20bf46d 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Anti-Phish Rule Modification"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Anti-Phish Rule Modification
-
-Microsoft 365's anti-phishing rules are crucial for enhancing email security by fine-tuning detection settings to thwart phishing attempts. Adversaries may exploit this by disabling or removing these rules, thus weakening defenses and facilitating phishing attacks. The detection rule monitors for successful actions that alter these rules, such as disabling or removing them, to identify potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.action field indicating "Remove-AntiPhishRule" or "Disable-AntiPhishRule" and ensure the event.outcome is marked as success.
-- Check the event.dataset field to verify it is set to o365.audit and the event.provider is Exchange, confirming the source of the alert.
-- Identify the user account associated with the modification by examining the user.name or user.id fields in the alert details.
-- Investigate the user's recent activity in Microsoft 365 to determine if there are any other suspicious actions or anomalies, such as unusual login times or locations.
-- Correlate the alert with other security events or logs, such as sign-in logs, to identify any potential compromise of the user's account.
-- Use Osquery to gather additional context on the user's device. For example, run a query to list recent processes executed by the user: `SELECT * FROM processes WHERE user = '<user_name>';`.
-- Examine the timestamp of the rule modification to determine if it coincides with any known phishing campaigns or other security incidents.
-- Review the organization's change management records to verify if the rule modification was authorized or part of a scheduled change.
-- Analyze email logs to identify any phishing emails that may have bypassed security controls following the rule modification.
-- Consult with the user or their manager to confirm whether the rule modification was intentional and authorized, and gather any additional context or insights.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may occasionally modify anti-phishing rules as part of regular maintenance or updates. These actions can trigger alerts but are not necessarily malicious.
-- Automated scripts: Some organizations use automated scripts to manage and update security settings, including anti-phishing rules. These scripts can generate alerts if they perform actions like disabling or removing rules.
-- Testing and audits: Security teams might intentionally modify anti-phishing rules to test system responses or during security audits, leading to false positives.
-- To manage these false positives, organizations can create exceptions for known administrative accounts or specific IP addresses associated with trusted IT personnel. Additionally, monitoring the context of the action, such as the time of day or associated user activity, can help differentiate between legitimate and suspicious modifications.
-
-### Response and remediation
-
-- Immediately isolate affected accounts or systems to prevent further unauthorized access or changes.
-- Review audit logs and identify any unauthorized modifications to anti-phishing rules, focusing on the "Remove-AntiPhishRule" or "Disable-AntiPhishRule" actions.
-- Verify the integrity of other security configurations and rules within Microsoft 365 to ensure no additional unauthorized changes have been made.
-- Restore any modified or removed anti-phishing rules to their original state using backup configurations or documented settings.
-- Conduct a thorough investigation to determine the source of the modification, including reviewing user activity and access permissions.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring policies to capture detailed information on future changes to security settings and rules.
-- Integrate additional security tools and services, such as Security Information and Event Management (SIEM) systems, to improve detection and response capabilities.
-- Educate users and administrators on the importance of maintaining security configurations and the risks associated with phishing attacks.
-- Apply hardening measures by enforcing multi-factor authentication (MFA) and least privilege access to reduce the risk of unauthorized modifications.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
index 1ec4d9a4fad..c0734782b56 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Safe Link Policy Disabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Safe Link Policy Disabled
-
-Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats. Disabling these policies can expose users to malicious links, often used in phishing attacks to gain unauthorized access. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches by monitoring specific audit events in the Exchange environment.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.action:"Disable-SafeLinksRule" and event.outcome:success fields, ensuring the alert is valid and corresponds to a successful policy disablement.
-- Check the event.dataset:o365.audit and event.provider:Exchange fields to verify the source and context of the event, confirming it originated from the Microsoft 365 Exchange environment.
-- Identify the user or account associated with the action by examining the user information in the audit logs, focusing on any unusual or unauthorized accounts.
-- Investigate the timestamp of the event to determine when the policy was disabled and correlate it with other security events or anomalies around the same time.
-- Analyze the IP address and location data associated with the event to identify any suspicious or unexpected access patterns.
-- Review recent changes in the Microsoft 365 environment, including any new or modified user accounts, to identify potential unauthorized access or privilege escalation.
-- Utilize Osquery to gather additional context on the system where the action was initiated. Example query: `SELECT * FROM users WHERE username = 'suspicious_user';` to check for any unusual user accounts or activity.
-- Examine email logs and communication patterns of the involved user to identify any phishing attempts or suspicious emails that may have led to the policy being disabled.
-- Cross-reference the event with other security tools and logs, such as endpoint protection or network monitoring systems, to gather a comprehensive view of the incident.
-- Document all findings and maintain a timeline of events to assist in understanding the scope and potential impact of the policy disablement.
-
-### False positive analysis
-
-- Routine administrative tasks: IT administrators may disable Safe Link policies temporarily for testing or troubleshooting purposes, which can trigger false positives. To manage this, organizations can create exceptions for known administrative accounts or specific time frames when such activities are expected.
-- Policy updates or changes: During policy updates or configuration changes, Safe Link policies might be disabled as part of the process. To handle these, organizations can document and schedule these changes, allowing for temporary exclusions during maintenance windows.
-- Third-party integrations: Some third-party applications or services may require Safe Link policies to be disabled for compatibility reasons. In such cases, organizations should assess the risk and, if deemed safe, create exceptions for these specific applications or services.
-- User training sessions: Training sessions that involve demonstrating the disabling of Safe Link policies can also result in false positives. Organizations can mitigate this by scheduling these sessions and excluding them from monitoring during the training period.
-
-### Response and remediation
-
-- Immediately re-enable the Safe Link policy to restore phishing protection for users and prevent further exposure to malicious links.
-- Conduct a thorough investigation to identify the user or system account responsible for disabling the Safe Link policy by reviewing audit logs and correlating with other security events.
-- Isolate any affected systems or accounts to prevent further unauthorized access or potential spread of malicious activity.
-- Notify the security team and relevant stakeholders about the incident and provide them with details of the investigation and current status.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify security policies such as Safe Links.
-- Implement enhanced logging and monitoring for Microsoft 365 and Exchange environments to detect similar activities in the future, ensuring that audit logs are retained for an appropriate duration.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities for phishing and other related threats.
-- Conduct a security awareness training session for users to reinforce the importance of recognizing phishing attempts and reporting suspicious activities.
-- Restore any affected systems to their operational state by applying necessary patches, updates, and security configurations.
-- Implement hardening measures such as multi-factor authentication (MFA) and conditional access policies to reduce the risk of unauthorized access and enhance overall security posture.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
index 0395688d557..50b93ea0d00 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2025/01/08"
+updated_date = "2024/09/05"
 
 [rule]
 author = ["Austin Songer"]
@@ -16,49 +16,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Impossible travel activity"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Impossible travel activity
-
-Microsoft 365's security features monitor user sign-ins to detect anomalies like impossible travel, where logins occur from geographically distant locations in a short time. Adversaries may exploit compromised credentials to access accounts from various locations. The detection rule identifies such suspicious activities by analyzing audit logs for successful logins flagged as impossible travel, helping to pinpoint potential unauthorized access.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the "Impossible travel activity" event action and ensure the event outcome is marked as success.
-- Verify the user's recent login history to identify any patterns or anomalies in login locations and times, focusing on the event.dataset:o365.audit field.
-- Check the event.provider:SecurityComplianceCenter field to ensure the alert originated from a trusted source and is not a false positive.
-- Analyze the event.category:web field to understand the context of the login attempt, such as the application or service accessed.
-- Cross-reference the IP addresses involved in the login attempts with known malicious IP databases to identify any potential threats.
-- Use Osquery to gather additional context on the user's device by running a query like: `SELECT * FROM users WHERE username = '<username>';` to verify if the user account has been accessed from multiple devices.
-- Investigate any recent changes to the user's account settings or permissions that could indicate unauthorized access.
-- Review the user's activity logs for any unusual behavior or actions that could suggest account compromise.
-- Collaborate with the network team to trace the network path of the login attempt and identify any anomalies in network traffic.
-- Consult with the user to verify if they were traveling or using a VPN that could explain the impossible travel alert, ensuring the legitimacy of the login attempt.
-
-### False positive analysis
-
-- Known false positives for the Microsoft 365 Impossible travel activity rule often arise from legitimate users who travel frequently or use VPN services that route traffic through different geographic locations. These scenarios can trigger alerts as they mimic the behavior of compromised accounts accessing from various locations.
-- To manage these false positives, users can create exceptions for specific users or IP addresses that are known to frequently travel or use VPNs. This can be done by configuring conditional access policies or adjusting the sensitivity of the detection rule to better align with the organization's typical user behavior.
-- Another method to handle false positives is to integrate user behavior analytics (UBA) to establish a baseline of normal activity for each user. This allows the system to differentiate between legitimate and suspicious activities more accurately.
-- Organizations should regularly review and update their exception lists and detection rules to ensure they reflect current user behavior and network configurations, minimizing the risk of overlooking genuine threats while reducing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
-- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) for additional security.
-- Conduct a thorough investigation of the audit logs to identify any other suspicious activities or compromised accounts.
-- Review and analyze the sign-in history and patterns to determine if any other accounts exhibit similar impossible travel activities.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if there is a broader security breach.
-- Implement enhanced logging policies to capture detailed sign-in activities and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Educate users on recognizing phishing attempts and the importance of using strong, unique passwords to prevent credential compromise.
-- Restore the system to its operational state by ensuring all affected accounts are secured and any unauthorized changes are reverted.
-- Apply hardening measures such as restricting access based on geographic location and implementing conditional access policies.
-- Utilize MITRE ATT&CK framework to understand the adversary's tactics and techniques, and update security measures to mitigate similar threats in the future.
-
+note = """
 ## Important
 
 This rule is no longer applicable based on changes to Microsoft Defender for Office 365. Please refer to the following rules for similar detections:
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
index fc0ab8aaa8f..2f593839be0 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/25"
 
 [rule]
 author = ["Elastic"]
@@ -39,50 +39,6 @@ event.dataset: "o365.audit"
     and not o365.audit.UserId: "Not Available"
     and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Portal Logins from Impossible Travel Locations
-
-Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries who log in from disparate locations within short timeframes, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for successful access from different countries, flagging suspicious activity that aligns with known threat tactics like using valid accounts for unauthorized access.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account involved by examining the `o365.audit.UserId` field.
-- Verify the login locations by checking the IP addresses associated with the login events and cross-reference them with known locations for the user.
-- Analyze the timestamps of the login events to determine the time difference between the logins from different countries.
-- Check for any recent changes in the user's account settings or permissions that could indicate unauthorized access.
-- Investigate the `event.provider` and `event.action` fields to confirm the source and nature of the login events.
-- Use Osquery to gather additional context on the user's activity. For example, run a query to list recent login events: `SELECT * FROM o365_audit WHERE event_action = 'UserLoggedIn' AND user_id = '<UserId>' ORDER BY timestamp DESC LIMIT 10;`
-- Examine the `event.outcome` field to ensure that the logins were indeed successful and not failed attempts.
-- Look for any other suspicious activities associated with the user account, such as unusual file access or email forwarding rules.
-- Cross-reference the login events with known threat intelligence sources to identify any IP addresses or locations associated with malicious activity.
-- Collaborate with the user to verify if they were traveling or using a VPN service that could explain the login from an unexpected location.
-
-### False positive analysis
-
-- Frequent travelers or employees using VPNs may trigger false positives as they can appear to log in from different countries within a short timeframe. 
-- Users accessing Microsoft 365 services through corporate VPNs that route traffic through different countries can also be flagged as impossible travel.
-- To manage these false positives, organizations can create exceptions for known frequent travelers by maintaining a list of users who regularly travel and excluding their login events from the rule.
-- Implementing geolocation-based VPN detection can help differentiate between legitimate VPN use and suspicious activity.
-- Regularly updating the list of trusted IP addresses and locations can reduce false positives by allowing logins from these sources without triggering alerts.
-- Monitoring and correlating login events with travel itineraries or VPN usage logs can provide additional context to determine if an alert is a false positive.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
-- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) for additional security.
-- Conduct a thorough investigation of the login events to identify the source IP addresses and geolocations involved in the suspicious activity.
-- Review audit logs for any unauthorized changes or access to sensitive data during the period of compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement conditional access policies to restrict access based on geographic location and risk level.
-- Enhance logging policies to ensure comprehensive capture of authentication events and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Educate users on recognizing phishing attempts and the importance of using strong, unique passwords.
-- Restore any affected systems or data to their last known good state, ensuring no malicious artifacts remain.
-- Regularly review and update security policies and configurations to align with best practices and mitigate similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
index 852b0982731..7edab168de5 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/25"
 
 [rule]
 author = ["Elastic"]
@@ -37,49 +37,6 @@ event.dataset: "o365.audit"
     and not o365.audit.UserId: "Not Available"
     and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Portal Login from Rare Location
-
-Microsoft 365 is a cloud-based suite that facilitates collaboration and productivity. Adversaries may exploit it by logging in from uncommon locations, potentially using stolen credentials or VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access by analyzing login events and user location patterns.
-
-### Possible investigation steps
-
-- Review the login event details in the security logs to confirm the event dataset is "o365.audit" and the event provider is "AzureActiveDirectory" to ensure the alert is based on accurate data.
-- Verify the user account involved by checking the "o365.audit.UserId" field to determine if the account is legitimate and active.
-- Analyze the "event.outcome" field to confirm the login was successful, indicating potential unauthorized access.
-- Investigate the "event.action" field to ensure it matches "UserLoggedIn," confirming the nature of the event.
-- Examine the "o365.audit.Target.Type" field to understand the type of resource accessed, which can provide context on the potential impact.
-- Cross-reference the login location with known user travel patterns or VPN usage to determine if the location is indeed rare or expected.
-- Check historical login patterns for the user to identify any previous logins from the same location or similar unusual locations.
-- Use Osquery to gather additional context on the user's device, such as recent network connections or VPN usage, with a query like: `SELECT * FROM users WHERE username = '<UserId>';`
-- Investigate any recent changes to the user's account settings or permissions that could indicate account compromise.
-- Collaborate with the user or their manager to verify if the login was legitimate, potentially involving direct communication to confirm the user's activities.
-
-### False positive analysis
-
-- Users traveling for business or personal reasons may trigger false positives if they log in from locations not typically associated with their account. To manage this, organizations can create exceptions for known travel patterns or pre-approved travel destinations.
-- Employees using VPNs for legitimate purposes might appear to be logging in from rare locations. To handle this, IT teams can maintain a list of approved VPN IP addresses and exclude them from triggering alerts.
-- Remote workers who frequently change their physical location, such as digital nomads, may also cause false positives. Organizations can address this by identifying and documenting these users' typical movement patterns and adjusting the detection rule accordingly.
-- Temporary relocations, such as employees working from a different office or location for a short period, can be managed by setting temporary exceptions for these users during the specified timeframe.
-- Users accessing Microsoft 365 services through shared or public networks, like cafes or coworking spaces, might be flagged. To mitigate this, organizations can educate users on secure access practices and adjust the rule to account for these common access points.
-
-### Response and remediation
-
-- Verify the login attempt by contacting the user to confirm if the login was legitimate or unauthorized.
-- Temporarily suspend the user's account to prevent further unauthorized access if the login is confirmed to be suspicious.
-- Review the user's recent activity logs in Microsoft 365 to identify any other unusual or unauthorized actions.
-- Reset the user's password and enforce multi-factor authentication (MFA) to enhance account security.
-- Investigate the source IP address and location of the login attempt to determine if it correlates with known threat actors or VPN services.
-- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems are compromised.
-- Implement logging policies to ensure comprehensive capture of login events and user activities for future investigations.
-- Integrate threat intelligence feeds to enhance detection capabilities and correlate with known threat indicators.
-- Restore the user's account access once it is confirmed secure and provide guidance on recognizing phishing attempts and securing credentials.
-- Conduct a security awareness training session for users to reinforce the importance of account security and recognizing suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
index a3ca1d0d20a..9eb423152f7 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Austin Songer"]
@@ -16,52 +16,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 User Restricted from Sending Email"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 User Restricted from Sending Email
-
-Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions on email sending, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic.
-
-### Possible investigation steps
-
-- Review the audit logs for the specific event.action "User restricted from sending email" to confirm the alert's validity and gather initial context.
-- Check the event.outcome field to ensure the restriction was successfully applied, indicating a potential misuse of the account.
-- Investigate the event.provider field to verify that the alert originated from the Security Compliance Center, ensuring the source's reliability.
-- Analyze the event.dataset field to confirm the data source is o365.audit, which provides relevant Microsoft 365 audit logs.
-- Examine the user's recent email activity to identify any unusual patterns or spikes in email sending that could have triggered the restriction.
-- Cross-reference the user's account details with known compromised accounts or recent security incidents to assess potential account compromise.
-- Utilize Osquery to gather additional context on the user's device and activity. For example, run the following query to check for recent login activities: `SELECT * FROM users WHERE username = 'affected_user';`
-- Investigate any recent changes to the user's account settings or permissions that could indicate unauthorized access or configuration changes.
-- Review the user's recent login history and IP addresses to identify any suspicious or unfamiliar access patterns.
-- Collaborate with other security tools and logs to correlate the user's activity with other potential indicators of compromise, such as phishing attempts or malware alerts.
-
-### False positive analysis
-
-- Legitimate high-volume senders such as marketing or customer service teams may trigger sending limits due to their normal operational activities. 
-- Automated systems or applications that send bulk emails for notifications or alerts might also be restricted, even though they are performing expected tasks.
-- Users who are part of email campaigns or newsletters might exceed limits if not properly configured or if there is a sudden increase in email volume.
-- To manage these false positives, organizations can create exceptions for known high-volume senders by adjusting their sending limits within Microsoft 365 settings.
-- Implementing monitoring and alerting for unusual spikes in email activity can help differentiate between legitimate high-volume sending and potential misuse.
-- Regularly reviewing and updating the list of users or systems with exceptions can ensure that only authorized entities are allowed higher sending limits, reducing the risk of abuse.
-
-### Response and remediation
-
-- Verify the legitimacy of the account activity by contacting the user to confirm if they were aware of the email sending activity.
-- Temporarily disable the compromised account to prevent further unauthorized access and email sending.
-- Conduct a thorough investigation of the account's recent activities, including login locations and times, to identify any suspicious behavior or unauthorized access.
-- Reset the password of the compromised account and enforce multi-factor authentication (MFA) to enhance security.
-- Review and analyze email logs to identify any recipients of potentially malicious emails sent from the compromised account and notify them to prevent further spread.
-- Escalate the incident to the security operations team for a deeper analysis of potential lateral movement or additional compromised accounts.
-- Implement enhanced logging and monitoring policies to capture detailed audit logs for email activities and account access.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the account to operational status only after confirming that it is secure and no longer compromised.
-- Educate users on recognizing phishing attempts and the importance of reporting suspicious emails to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
index 53860d357cc..0b96dcaff21 100644
--- a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
+++ b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/12"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -18,52 +18,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Email Reported by User as Malware or Phish"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 O365 Email Reported by User as Malware or Phish
-
-Office 365 (O365) provides email services that are crucial for business communication but can be exploited by adversaries through phishing attacks to gain unauthorized access. Users reporting suspicious emails help identify potential threats that bypass security measures. The detection rule leverages audit logs from the Security Compliance Center to flag emails reported as malicious, enabling swift investigation and response to phishing attempts.
-
-### Possible investigation steps
-
-- Review the alert details in the Security Compliance Center to gather initial information, focusing on the `event.dataset:o365.audit`, `event.provider:SecurityComplianceCenter`, and `event.action:AlertTriggered` fields to confirm the alert's legitimacy.
-- Identify the user who reported the email and gather context on their role and typical email activity to assess the potential impact of the threat.
-- Examine the reported email's metadata, including sender address, subject line, and timestamp, to identify any patterns or anomalies that could indicate a phishing attempt.
-- Cross-reference the sender's email address and domain against known threat intelligence sources to determine if they are associated with previous phishing campaigns.
-- Analyze the email headers and body for suspicious links or attachments, using tools to safely extract and inspect these elements for malicious content.
-- Utilize Osquery to investigate the user's device for any signs of compromise or unusual activity. Example query: `SELECT * FROM processes WHERE name LIKE '%outlook%' AND user = '<username>';` to check for any suspicious processes related to email activity.
-- Check the organization's email gateway logs for any other instances of emails from the same sender or domain to determine if this is an isolated incident or part of a broader campaign.
-- Investigate any other alerts or incidents involving the same user or email address to identify potential patterns or repeated targeting.
-- Review the organization's security awareness training records to verify if the user has completed recent training, which could provide insight into their ability to recognize phishing attempts.
-- Document all findings and observations in a centralized incident management system to maintain a comprehensive record for future reference and analysis.
-
-### False positive analysis
-
-- Users may report legitimate marketing emails or newsletters as phishing due to unfamiliarity with the sender or content, leading to false positives.
-- Internal company emails with unusual formatting or language might be flagged by users as suspicious, especially if they deviate from typical communication patterns.
-- Automated system notifications or alerts from trusted services can be mistakenly reported as phishing if users are not aware of their purpose or origin.
-- To manage these false positives, organizations can create exceptions for known and verified senders by adding them to an allowlist, reducing unnecessary alerts.
-- Regularly updating user training to include examples of legitimate emails can help reduce the number of false reports by improving user discernment.
-- Implementing a feedback loop where users are informed about the outcome of their reports can enhance their understanding and accuracy in identifying true threats.
-
-### Response and remediation
-
-- Immediately isolate the affected email account to prevent further unauthorized access or spread of malicious content.
-- Conduct a thorough investigation of the reported email, including headers and links, to confirm the phishing attempt and identify any compromised accounts.
-- Remove the malicious email from all user inboxes and quarantine it to prevent further interaction.
-- Escalate the incident to the security operations team if the phishing attempt is part of a larger campaign or if multiple users are affected.
-- Review and update email filtering rules and security policies to block similar threats in the future.
-- Implement enhanced logging policies to capture detailed email activity and user actions for better future analysis.
-- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging phishing tactics.
-- Educate users on recognizing phishing attempts and reinforce the importance of reporting suspicious emails promptly.
-- Restore any affected systems or accounts to their operational state by resetting passwords and verifying system integrity.
-- Apply security hardening measures, such as multi-factor authentication and regular security awareness training, to reduce the risk of future incidents.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
index d9486c4284e..1e179228799 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -18,51 +18,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "OneDrive Malware File Upload"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 OneDrive Malware File Upload
-
-OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement. The detection rule monitors OneDrive audit logs for malware detection events, identifying potential threats when malicious files are uploaded, thus helping to prevent unauthorized access and propagation.
-
-### Possible investigation steps
-
-- Review the OneDrive audit logs to confirm the event details, focusing on fields such as `event.dataset`, `event.provider`, `event.code`, and `event.action` to ensure the alert is valid and corresponds to a malware detection.
-- Identify the user account associated with the file upload by examining the `user.name` and `user.id` fields in the audit logs to determine if the account is compromised or if the upload was accidental.
-- Investigate the file details, including the file name, size, and hash, by checking the `file.name`, `file.size`, and `file.hash` fields to gather more context about the nature of the file.
-- Check the file's origin by reviewing the `source.ip` and `source.geo.location` fields to understand where the file was uploaded from and if it matches the user's typical behavior.
-- Analyze the file's sharing permissions and access history using the `file.permissions` and `file.accessed` fields to determine if the file has been shared with other users or accessed by unauthorized parties.
-- Use Osquery to gather additional context on the endpoint from which the file was uploaded. For example, run the following Osquery query to list recent file modifications in the OneDrive directory: `SELECT * FROM file WHERE directory LIKE '%OneDrive%' AND mtime > (SELECT strftime('%s', 'now') - 86400);`
-- Correlate the OneDrive event with other security logs, such as endpoint detection and response (EDR) or intrusion detection system (IDS) logs, to identify any related suspicious activities or alerts.
-- Investigate the user's recent activity by reviewing additional OneDrive and Office 365 audit logs to identify any other unusual or unauthorized actions performed by the user.
-- Check for any other malware detection events in the OneDrive environment by searching for similar `event.action:FileMalwareDetected` events to assess if this is an isolated incident or part of a larger campaign.
-- Document all findings and evidence collected during the investigation to support further analysis and potential escalation to the incident response team.
-
-### False positive analysis
-
-- Legitimate software updates or patches may be flagged as malware if they contain code patterns similar to known threats. Users should verify the source and integrity of these files before excluding them from detection.
-- Files with macros or scripts used in business operations might trigger false positives due to their executable nature. It's important to assess the necessity and origin of these files and whitelist them if they are deemed safe.
-- Internal security tools or penetration testing files could be misidentified as malicious. Ensure these tools are recognized and documented within the organization to prevent unnecessary alerts.
-- Large files or compressed archives might be flagged due to heuristic scanning limitations. Users should review these files for any suspicious content and create exceptions for trusted sources.
-- Frequent collaboration documents that undergo regular changes might be mistakenly detected as threats. Implementing a review process for these documents can help in identifying genuine threats while allowing safe files to be excluded from alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected OneDrive account to prevent further spread of the malware within the organization.
-- Notify the user associated with the account about the detected malware and provide guidance on avoiding similar incidents in the future.
-- Conduct a thorough investigation of the uploaded file to determine its origin and potential impact on the organization.
-- Remove the malicious file from all shared locations and ensure it is quarantined for further analysis.
-- Review OneDrive audit logs and other relevant logs to identify any lateral movement or additional compromised accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement or update logging policies to ensure comprehensive monitoring of file uploads and sharing activities in OneDrive.
-- Integrate threat intelligence feeds and security solutions to enhance detection capabilities for similar threats in the future.
-- Restore affected systems and accounts to their operational state by removing any residual malware and applying necessary security patches.
-- Strengthen security measures by enforcing multi-factor authentication, regular security awareness training, and least privilege access controls.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
index fddadca5a97..4ba15633da1 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -18,51 +18,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "SharePoint Malware File Upload"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SharePoint Malware File Upload
-
-SharePoint serves as a collaborative platform for file sharing within organizations, but its openness can be exploited by adversaries. Attackers may upload malicious files to SharePoint, leveraging it to spread malware laterally across the network. The detection rule identifies such threats by monitoring specific SharePoint events where files are flagged as malware, helping to mitigate potential breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `event.dataset:o365.audit`, `event.provider:SharePoint`, `event.code:SharePointFileOperation`, and `event.action:FileMalwareDetected` to ensure the alert is valid and triggered by the correct conditions.
-- Identify the user account associated with the file upload by examining the event logs for user identifiers, such as user ID or email address, to determine if the account is compromised or if the user was unaware of the file's malicious nature.
-- Investigate the file's origin by checking the file name, size, and hash values in the event logs to see if it matches known malware signatures or if it has been flagged in other security tools.
-- Cross-reference the file hash with threat intelligence databases to gather additional context on the file's reputation and any known associated threat actors or campaigns.
-- Analyze the SharePoint site and document library where the file was uploaded to understand the potential impact and scope of exposure within the organization.
-- Check for any other recent file uploads by the same user or to the same SharePoint site to identify patterns or additional suspicious activities.
-- Use Osquery to gather more information about the affected endpoints. For example, run a query to list all files recently accessed or modified by the user: `SELECT * FROM file WHERE path LIKE '/path/to/sharepoint/directory/%' AND mtime > (SELECT strftime('%s', 'now') - 86400);`
-- Review access logs and permissions for the SharePoint site to identify any unauthorized access or privilege escalation attempts that may have facilitated the malware upload.
-- Investigate any lateral movement attempts by checking for subsequent access to other network resources or systems by the user or associated accounts.
-- Document all findings and evidence collected during the investigation to support further analysis and potential escalation to the incident response team.
-
-### False positive analysis
-
-- Files flagged as malware may include legitimate software or scripts that are incorrectly identified by the scanning engine due to heuristic or signature-based detection methods. This can occur with custom-developed applications or scripts that are not widely recognized.
-- Frequent uploads of large datasets or files from trusted internal sources might trigger false positives if the scanning engine misinterprets the data patterns as malicious.
-- Users can manage these false positives by creating exceptions for specific files or file types that are consistently flagged but verified as safe. This can be done by adjusting the scanning engine's sensitivity settings or by whitelisting certain file hashes or sources.
-- Regularly updating the scanning engine's malware definitions and maintaining a list of known safe files can help reduce the occurrence of false positives.
-- Implementing a review process for flagged files, where security teams can manually verify the legitimacy of the files before taking action, can also help in managing false positives effectively.
-
-### Response and remediation
-
-- Immediately isolate the affected SharePoint site or document library to prevent further access and potential spread of the malware.
-- Notify the IT security team and relevant stakeholders about the detected malware to initiate a coordinated response.
-- Conduct a thorough investigation to identify the source and scope of the malware upload, including reviewing user activity logs and file access history.
-- Remove the malicious file from SharePoint and perform a comprehensive scan of the environment to ensure no other instances of the malware exist.
-- Reset credentials and enforce multi-factor authentication for users involved in the incident to prevent unauthorized access.
-- Escalate the incident to higher-level security teams if the malware is part of a broader attack campaign or if multiple systems are affected.
-- Implement enhanced logging and monitoring policies to capture detailed SharePoint activity, focusing on file uploads and access patterns.
-- Integrate advanced threat detection tools with SharePoint to improve real-time monitoring and automated response capabilities.
-- Restore affected systems and SharePoint sites to their operational state from clean backups, ensuring no remnants of the malware remain.
-- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting file types allowed for upload and educating users on safe file-sharing practices.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
index e41ce6f41f0..348964efd89 100644
--- a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
+++ b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -16,51 +16,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Exchange Suspicious Mailbox Right Delegation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 O365 Exchange Suspicious Mailbox Right Delegation
-
-Microsoft 365 Exchange allows users to delegate mailbox access, enabling collaboration by granting permissions like FullAccess, SendAs, or SendOnBehalf. However, adversaries can exploit this by assigning these rights to compromised accounts, facilitating unauthorized access and communication. The detection rule identifies such suspicious delegations by monitoring successful permission assignments, excluding legitimate system processes, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account and mailbox involved in the suspicious delegation event using the `user.id` and `o365.audit.Parameters.AccessRights` fields.
-- Verify the legitimacy of the mailbox permission change by contacting the mailbox owner or relevant department to confirm if the delegation was authorized.
-- Examine the `event.provider` and `event.action` fields to ensure the event is related to Exchange and involves the addition of mailbox permissions.
-- Check the `event.outcome` field to confirm the permission assignment was successful, indicating a potential unauthorized access.
-- Investigate the `event.dataset` field to ensure the event is part of the O365 audit logs, confirming the source of the data.
-- Analyze the historical activity of the involved user account to identify any unusual patterns or recent changes in behavior that could indicate compromise.
-- Use Osquery to gather additional context on the involved user account and mailbox. For example, run a query to list recent login activities: `SELECT * FROM o365_login WHERE user_id = '<user.id>' ORDER BY timestamp DESC LIMIT 10;`.
-- Review any recent changes to inbox rules for the affected mailbox to identify potential attempts to evade detection mechanisms.
-- Cross-reference the event with other security logs and alerts to identify any correlated activities or indicators of compromise.
-- Document all findings and observations during the investigation to maintain a comprehensive record for further analysis or escalation if needed.
-
-### False positive analysis
-
-- Delegations made by IT administrators for legitimate business purposes can trigger false positives. These should be reviewed and, if deemed non-threatening, added to an exception list to prevent future alerts.
-- Automated processes or third-party applications that require mailbox access for functionality might be flagged. Identifying these applications and excluding their associated accounts can reduce false positives.
-- Temporary delegations for projects or team collaborations may appear suspicious. Documenting these activities and setting time-bound exceptions can help manage alerts.
-- Changes made during organizational restructuring, such as department mergers, can result in multiple legitimate delegations. Monitoring these changes and updating the exception list accordingly can mitigate unnecessary alerts.
-- Regular audits of the exception list are recommended to ensure that only valid and current exceptions are maintained, reducing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately revoke the suspicious mailbox permissions to prevent further unauthorized access.
-- Isolate the compromised account by disabling it or resetting its password to contain the threat.
-- Conduct a thorough investigation to determine the extent of the compromise, including reviewing mailbox access logs and identifying any unauthorized activities.
-- Notify the affected users and relevant stakeholders about the incident and potential data exposure.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for mailbox permission changes to detect future unauthorized delegations.
-- Integrate threat intelligence feeds to correlate suspicious activities with known threat actors and tactics.
-- Restore the affected mailboxes to their last known good state, ensuring no malicious rules or forwarding settings remain.
-- Educate users on recognizing phishing attempts and the importance of reporting suspicious activities to prevent account compromise.
-- Apply security hardening measures, such as enabling multi-factor authentication (MFA) and regularly reviewing mailbox permissions, to reduce the risk of future incidents.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 21
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
index 7a624cd749f..90ef1163536 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange DKIM Signing Configuration Disabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange DKIM Signing Configuration Disabled
-
-DomainKeys Identified Mail (DKIM) is a security protocol that ensures email authenticity by allowing receiving servers to verify that emails are sent from authorized domains. Disabling DKIM can expose organizations to email spoofing attacks. Adversaries might exploit this by disabling DKIM to send fraudulent emails that appear legitimate. The detection rule identifies successful attempts to disable DKIM, signaling potential misuse or configuration errors.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `Exchange`, ensuring the alert is relevant to Microsoft 365 Exchange DKIM configuration.
-- Verify the event category is `web` and the event action is `Set-DkimSigningConfig` to confirm the specific action of disabling DKIM signing configuration.
-- Check the `o365.audit.Parameters.Enabled` field to ensure it is set to `False`, indicating that DKIM signing was indeed disabled.
-- Examine the `event.outcome` field to confirm it shows `success`, indicating the action to disable DKIM was successfully executed.
-- Identify the user or service account associated with the action by reviewing the `user.name` or `user.id` fields to determine if the action was performed by an authorized individual.
-- Investigate the `source.ip` field to identify the IP address from which the DKIM configuration change was made, and assess if it is a known or trusted source.
-- Review recent activity logs for the identified user or service account to detect any unusual or unauthorized actions around the time of the DKIM configuration change.
-- Utilize Osquery to gather additional context on the system or user involved. For example, run a query to list recent login activities: `SELECT * FROM users WHERE username = '<identified_user>' AND last_login > date('now', '-1 day');`
-- Check for any recent changes in administrative roles or permissions that might have allowed the DKIM configuration to be disabled.
-- Correlate this event with other security alerts or incidents in the same timeframe to identify potential patterns or coordinated actions that could indicate a broader security issue.
-
-### False positive analysis
-
-- Routine administrative changes: Organizations may intentionally disable DKIM temporarily for maintenance or configuration updates. To manage this, create exceptions for known maintenance periods or authorized personnel performing these actions.
-- Testing and troubleshooting: IT teams might disable DKIM as part of testing or troubleshooting email configurations. Implement a process to log and approve such activities, allowing you to exclude these events from triggering alerts.
-- Misconfigured automation scripts: Automated scripts or tools used for managing email settings might inadvertently disable DKIM. Review and update scripts to ensure they align with security policies, and exclude known scripts from alerting.
-- Third-party integrations: Some third-party email services or integrations might require DKIM to be disabled temporarily. Document and approve these integrations, and set up exceptions for recognized third-party actions.
-
-### Response and remediation
-
-- Verify the alert by checking the audit logs to confirm that the DKIM signing configuration was indeed disabled and identify the user or system account responsible for the change.
-- Contain the potential threat by immediately re-enabling DKIM signing for the affected domain to prevent further spoofing attempts.
-- Investigate the source of the change by reviewing user activity logs and correlating with other security events to determine if the action was authorized or part of a malicious activity.
-- If unauthorized, reset the credentials of the compromised account and review access permissions to ensure least privilege principles are enforced.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised.
-- Implement enhanced logging and monitoring for DKIM configuration changes and other critical security settings within Microsoft 365 to detect similar incidents in the future.
-- Integrate with a Security Information and Event Management (SIEM) system to centralize alerts and improve threat detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the importance of DKIM and other email security protocols to prevent accidental or malicious misconfigurations.
-- Apply hardening measures by enabling multi-factor authentication (MFA) for all administrative accounts and regularly reviewing security configurations in Microsoft 365.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
index f8f1a99ce05..d445e6723d7 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Management Group Role Assignment"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Exchange Management Group Role Assignment
-
-Microsoft 365 Exchange Management roles define permissions for managing Exchange environments. Adversaries may exploit this by assigning roles to unauthorized users, ensuring persistent access. The detection rule monitors successful role assignments within Exchange, flagging potential unauthorized changes that align with persistence tactics, thus aiding in identifying and mitigating account manipulation threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `Exchange`, ensuring the alert is relevant to Exchange role assignments.
-- Verify the `event.category` is `web` and the `event.action` is `New-ManagementRoleAssignment` to confirm the specific action that triggered the alert.
-- Check the `event.outcome` field to ensure it indicates a `success`, confirming that the role assignment was completed.
-- Identify the user account associated with the role assignment by examining the relevant fields in the alert, such as `user.name` or `user.id`.
-- Investigate the assigned role by reviewing the `management.role` field to understand the permissions granted and assess the potential impact.
-- Cross-reference the user account with known authorized personnel to determine if the role assignment aligns with expected administrative activities.
-- Utilize Osquery to gather additional context on the user account by running a query such as: `SELECT * FROM users WHERE username = '<user.name from alert>';` to check for any anomalies or recent changes.
-- Examine the `source.ip` field to identify the originating IP address of the role assignment action and assess if it matches known or expected locations.
-- Review historical logs for any previous role assignments or suspicious activities associated with the same user or IP address to identify patterns or repeated unauthorized actions.
-- Collaborate with the IT or security team to gather additional context on recent administrative changes or projects that might explain the role assignment, ensuring it was not part of a legitimate operation.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular role assignments by authorized IT personnel for maintenance or updates can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated scripts or tools: Some organizations use automated processes for role assignments, which may be flagged. Identify and exclude these scripts or tools by their unique identifiers or execution patterns.
-- Organizational changes: During mergers, acquisitions, or restructuring, role assignments may increase. Monitor these periods closely and temporarily adjust thresholds or exclusions to accommodate expected changes.
-- Training or onboarding: New employee onboarding or training sessions might involve temporary role assignments. Implement a process to log and verify these activities, allowing for temporary exclusions during these periods.
-
-### Response and remediation
-
-- Immediately isolate the affected account to prevent further unauthorized access and assess the scope of the role assignment.
-- Review audit logs to identify any additional unauthorized role assignments or suspicious activities linked to the compromised account.
-- Revoke any unauthorized role assignments and reset credentials for affected accounts to prevent adversary persistence.
-- Conduct a thorough investigation to determine how the adversary gained access and whether other accounts or systems are compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring policies to capture detailed audit logs of role assignments and other critical actions within Microsoft 365.
-- Integrate security information and event management (SIEM) solutions to correlate events and detect similar threats in the future.
-- Restore the system to its operational state by verifying that all unauthorized changes have been reverted and that security controls are in place.
-- Apply hardening measures such as multi-factor authentication (MFA) for administrative accounts and regular review of role assignments.
-- Educate users and administrators on recognizing phishing attempts and other common tactics used to gain unauthorized access.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
index 67a8655cd83..821b0bf2f8c 100644
--- a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -18,50 +18,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Global Administrator Role Assigned"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Global Administrator Role Assigned
-
-The Global Administrator role in Microsoft 365 grants comprehensive access to manage Azure AD and related services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit events, focusing on role changes to "Global Administrator," thus alerting to potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is "o365.audit" and the event code is "AzureActiveDirectory" to ensure the alert is relevant to Azure AD role changes.
-- Verify the event action is "Add member to role" and check if the "o365.audit.ModifiedProperties.Role_DisplayName.NewValue" is "Global Administrator" to confirm the specific role assignment.
-- Identify the user account that was added to the Global Administrator role by examining the event logs for the user ID or email address associated with the role change.
-- Investigate the user account that performed the role assignment to determine if it was an authorized action or potentially malicious.
-- Check the timestamp of the event to understand when the role assignment occurred and correlate it with other security events or anomalies around the same time.
-- Use Osquery to gather additional context on the user account involved in the role assignment. Example query: `SELECT * FROM users WHERE username = 'suspected_user';`
-- Review the audit logs for any other recent changes or suspicious activities involving the same user account or related accounts.
-- Examine the IP address and location from which the role assignment was made to determine if it aligns with expected user behavior or if it appears suspicious.
-- Investigate any recent changes to the organization's Azure AD configuration or security settings that might have facilitated unauthorized role assignments.
-- Collaborate with the IT or security team to gather additional context on the user accounts involved, such as recent password changes, MFA status, or any reported incidents.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may frequently assign the Global Administrator role during regular maintenance or onboarding processes. To manage these, organizations can create exceptions for known administrative accounts or specific time frames when such activities are expected.
-- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage user roles, which might trigger the detection rule. Users can exclude these scripts or tools by identifying their unique identifiers or IP addresses and adding them to an exception list.
-- Temporary role assignments: In some cases, users may be temporarily assigned the Global Administrator role for specific projects or tasks. To handle these, organizations can implement a process to document and approve temporary assignments, then exclude these documented cases from triggering alerts.
-- Delegated administration: Organizations that use delegated administration might see frequent role changes as part of their operational model. To reduce false positives, they can exclude changes made by specific delegated admin accounts or within certain organizational units.
-
-### Response and remediation
-
-- Immediately revoke the Global Administrator role from any unauthorized users to contain the threat and prevent further misuse.
-- Conduct a thorough investigation to identify how the unauthorized assignment occurred, reviewing audit logs and any related security alerts.
-- Reset passwords and enforce multi-factor authentication (MFA) for all affected accounts to prevent further unauthorized access.
-- Escalate the incident to the security operations team for a deeper analysis and to determine if any other systems or accounts have been compromised.
-- Review and update role assignment policies to ensure that only authorized personnel can assign or modify Global Administrator roles.
-- Implement enhanced logging and monitoring for Azure AD role changes, ensuring that all role assignments and modifications are captured and reviewed regularly.
-- Integrate security information and event management (SIEM) systems with Azure AD to automate alerting and improve incident response times.
-- Restore any affected systems or services to their operational state by verifying configurations and ensuring no unauthorized changes remain.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate and train staff on the importance of role-based access control and the risks associated with improper role assignments to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
index 9b6d4c89b3d..a8da34138b9 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,52 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams Custom Application Interaction Allowed"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Teams Custom Application Interaction Allowed
-
-Microsoft Teams allows organizations to enhance functionality by integrating custom applications, which can be developed and uploaded if the default app store offerings are insufficient. However, this flexibility can be exploited by adversaries to maintain persistence within a network. The detection rule monitors changes in tenant settings that permit custom app interactions, flagging successful modifications as potential security threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `o365.audit` and the event provider is `MicrosoftTeams`, ensuring the alert is relevant to Microsoft Teams settings.
-- Verify the event category is `web` and the action is `TeamsTenantSettingChanged` to confirm that the alert pertains to a change in tenant settings.
-- Check the `o365.audit.Name` field for "Allow sideloading and interaction of custom apps" to ensure the alert is specifically about enabling custom app interactions.
-- Confirm the `o365.audit.NewValue` is `True` and the `event.outcome` is `success` to validate that the change was successfully applied.
-- Investigate the user account associated with the change to determine if the account has a history of making administrative changes or if it appears suspicious.
-- Review recent activity logs for the user account to identify any unusual behavior or patterns that could indicate compromise or misuse.
-- Examine the IP address and location associated with the change to assess if it aligns with expected user activity or if it appears anomalous.
-- Use Osquery to gather additional context on the system from which the change was made. For example, run the following query to list recent administrative actions: `SELECT * FROM osquery_events WHERE event_type = 'admin_action' AND user = '<user_account>' ORDER BY timestamp DESC LIMIT 10;`
-- Check for any recent uploads or installations of custom applications in Microsoft Teams to identify potential unauthorized or malicious apps.
-- Collaborate with the IT or security team to gather more context on the organization's policy regarding custom applications and verify if the change aligns with any recent business needs or projects.
-
-### False positive analysis
-
-- Organizations frequently enabling custom applications for legitimate business needs may trigger this rule, leading to false positives.
-- Regular updates or changes in tenant settings by IT administrators for maintenance or feature enhancements can be mistaken for suspicious activity.
-- To manage these false positives, users can create exceptions for known and trusted administrative actions by whitelisting specific user accounts or IP addresses.
-- Implementing a review process for changes in tenant settings can help differentiate between legitimate and suspicious modifications.
-- Monitoring the context of changes, such as correlating with scheduled maintenance windows or approved change requests, can reduce false positives.
-- Regularly updating the list of approved custom applications and their developers can help in distinguishing between legitimate and potentially malicious activities.
-
-### Response and remediation
-
-- Immediately disable the setting that allows sideloading and interaction of custom apps in Microsoft Teams to prevent further unauthorized access.
-- Conduct a thorough investigation to identify any custom applications that have been uploaded recently and verify their legitimacy.
-- Review audit logs and user activity to identify any suspicious behavior or unauthorized access attempts related to the custom applications.
-- Isolate any compromised accounts or systems identified during the investigation to prevent lateral movement within the network.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for Microsoft Teams and related services to detect similar activities in the future.
-- Review and update security policies to restrict permissions for uploading and interacting with custom applications to only trusted users.
-- Educate users on the risks associated with custom applications and provide training on recognizing potential security threats.
-- Restore any affected systems to a known good state by removing unauthorized applications and applying necessary security patches.
-- Consider implementing additional security measures such as multi-factor authentication and conditional access policies to harden the environment against future threats.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/deploy-and-publish/apps-upload"]
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
index bcfe158fd0c..a47f63526f6 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,51 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams External Access Enabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Teams External Access Enabled
-
-Microsoft Teams allows external access to facilitate communication with users outside an organization, enhancing collaboration. However, adversaries can exploit this feature to exfiltrate data or maintain persistence by enabling external access or adding trusted domains. The detection rule monitors audit logs for successful configuration changes that permit external communication, flagging potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.action "Set-CsTenantFederationConfiguration" and ensure the event.outcome is marked as success.
-- Verify the event.dataset is o365.audit and the event.provider is either SkypeForBusiness or MicrosoftTeams to confirm the source of the alert.
-- Check the o365.audit.Parameters.AllowFederatedUsers field to ensure it is set to True, indicating that external access was enabled.
-- Investigate the user account associated with the configuration change to determine if the action was performed by a legitimate administrator or a potentially compromised account.
-- Examine the timestamp of the event to correlate with any other suspicious activities or anomalies in the environment around the same time.
-- Review the audit logs for any recent changes to the list of allowed domains for external access to identify any unauthorized additions.
-- Utilize Osquery to gather additional context on the user account involved. Example query: `SELECT * FROM users WHERE username = 'suspected_user';`
-- Check for any recent login activities from unusual locations or IP addresses associated with the user account involved in the configuration change.
-- Investigate any other recent configuration changes in Microsoft Teams or Skype for Business that might indicate further unauthorized access attempts.
-- Collaborate with the IT team to verify if the configuration change aligns with any recent legitimate business needs or projects that required enabling external access.
-
-### False positive analysis
-
-- Routine administrative changes: Legitimate IT administrators may enable external access as part of regular configuration updates or to facilitate business operations. To manage these, organizations can maintain a list of authorized personnel and cross-reference changes with approved change requests.
-- Partner or vendor communication: External access might be enabled to allow communication with trusted partners or vendors. Users can handle these by creating exceptions for known and verified domains, ensuring they are documented and regularly reviewed.
-- Temporary project requirements: Teams working on joint projects with external entities may require temporary external access. Implementing a process to log and approve such temporary access can help differentiate between legitimate and suspicious activities.
-- Misconfigured alerts: Sometimes, alerts may trigger due to misconfigured settings or testing environments. Regularly reviewing and updating alert configurations can help minimize these false positives.
-- Automated scripts or tools: Automated processes that modify configurations for maintenance or updates might trigger alerts. Identifying and documenting these scripts can help in excluding them from triggering false positives.
-
-### Response and remediation
-
-- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains.
-- Conduct a thorough investigation of audit logs to identify any unauthorized configuration changes and determine the scope of potential data exfiltration.
-- Verify the list of allowed domains and remove any that are not recognized or authorized by the organization.
-- Reset credentials and review account permissions for any accounts involved in the suspicious activity to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed audit logs of configuration changes and access attempts in Microsoft Teams.
-- Integrate Microsoft 365 security logs with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting.
-- Conduct a review of current security policies and update them to include stricter controls on external access and domain whitelisting.
-- Restore the system to its operational state by ensuring all unauthorized changes are reverted and verifying the integrity of the Teams environment.
-- Apply hardening measures such as multi-factor authentication (MFA) for administrative accounts and regular security awareness training for users.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/microsoftteams/manage-external-access"]
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
index 5ddaff067f6..cad302f3660 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,50 +21,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams Guest Access Enabled"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft 365 Teams Guest Access Enabled
-
-Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access by enabling guest access without authorization. The detection rule identifies such unauthorized actions by monitoring specific audit events and configurations, ensuring any suspicious enabling of guest access is promptly flagged for investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.action "Set-CsTeamsClientConfiguration" and ensure the event.outcome is marked as success.
-- Verify the identity of the user or account that performed the action by examining the user information in the event logs, focusing on any anomalies or unfamiliar accounts.
-- Check the timestamp of the event to determine when the guest access was enabled and correlate it with other security events or logs around the same time for additional context.
-- Investigate the o365.audit.Parameters.AllowGuestUser field to confirm that it is set to True, indicating that guest access was indeed enabled.
-- Examine the event.provider field to determine whether the action was performed through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used.
-- Utilize Osquery to gather more information about the user account involved. For example, run the following query to list recent logins and activities for the user: `SELECT * FROM users WHERE username = '<username>';`
-- Review the organization's Microsoft 365 audit logs for any other suspicious activities or changes made by the same user or account around the same time.
-- Investigate any recent changes to the Teams configuration settings to identify if there were any unauthorized modifications or patterns of suspicious behavior.
-- Cross-reference the alert with known threat intelligence sources to determine if the activity matches any known adversary tactics or techniques.
-- Consult with team members or stakeholders to gather additional context or insights regarding the legitimacy of the guest access enablement, especially if the user is unfamiliar or the action is unexpected.
-
-### False positive analysis
-
-- Routine administrative actions: Legitimate IT administrators may enable guest access as part of their regular duties to facilitate collaboration with external partners or clients. These actions can be considered false positives if they align with documented business processes.
-- Automated scripts or tools: Organizations may use automated scripts or third-party tools to manage Microsoft Teams configurations, including enabling guest access. These actions should be reviewed to ensure they are authorized and align with organizational policies.
-- Policy updates: Changes in organizational policies or compliance requirements may necessitate enabling guest access. Such changes should be documented and communicated to avoid being flagged as suspicious.
-- Exception handling: To manage false positives, organizations can create exceptions for known and authorized activities by maintaining a list of approved users or scripts that are allowed to enable guest access. Regularly review and update this list to ensure it reflects current business needs and security policies.
-
-### Response and remediation
-
-- Immediately disable guest access in Microsoft Teams to prevent unauthorized external access.
-- Review audit logs to identify any unauthorized changes to guest access settings and determine the scope of the incident.
-- Verify the identity and permissions of any external users who were granted guest access to ensure they are legitimate and authorized.
-- Conduct a thorough investigation to identify any potential data exfiltration or malicious activities performed by the adversary.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement stricter access controls and review the organization's guest access policies to prevent unauthorized changes in the future.
-- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect similar activities promptly.
-- Educate employees on the risks associated with guest access and provide training on identifying suspicious activities.
-- Restore any affected systems or configurations to their original state, ensuring no backdoors or unauthorized changes remain.
-- Apply hardening measures such as multi-factor authentication (MFA) and regular audits of access permissions to reduce the risk of persistence tactics like account manipulation.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
index d5be6beb5ad..273f81c599d 100644
--- a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
+++ b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Austin Songer"]
@@ -14,50 +14,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "New or Modified Federation Domain"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 New or Modified Federation Domain
-Federation domains enable trust relationships between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions within Exchange logs, identifying successful modifications to federation domains, which may indicate malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific action that triggered the alert, focusing on the `event.action` field to determine whether it was a domain addition, modification, or removal.
-- Examine the `event.outcome` field to confirm the success of the action, ensuring that the alert is not a false positive due to a failed attempt.
-- Check the `event.provider` and `event.dataset` fields to verify that the event originated from the expected source, ensuring the integrity of the alert.
-- Investigate the user account associated with the action by reviewing the `user.name` field to determine if the account has a history of suspicious activity or if it is a known administrative account.
-- Analyze the `event.time` field to establish a timeline of events, identifying any unusual patterns or times that could indicate malicious intent.
-- Correlate the event with other logs or alerts from the same time period to identify any related suspicious activities, such as unauthorized access attempts or privilege escalations.
-- Use Osquery to gather additional context on the system where the action was performed. For example, run the following query to list recent changes to federation settings: `SELECT * FROM federated_domains WHERE action IN ('Set-AcceptedDomain', 'Set-MsolDomainFederationSettings', 'Add-FederatedDomain', 'New-AcceptedDomain', 'Remove-AcceptedDomain', 'Remove-FederatedDomain');`
-- Investigate any recent changes to administrative roles or permissions that could have facilitated the unauthorized modification of federation domains.
-- Review the organization's change management records to verify if the action was part of a planned and approved change, potentially ruling out malicious activity.
-- Consult with the identity and access management team to confirm whether the federation domain changes align with current business needs and security policies.
-
-### False positive analysis
-
-- Routine administrative changes: Legitimate IT administrators may frequently update federation domains as part of regular maintenance or configuration changes. These actions can trigger the detection rule, leading to false positives.
-- Scheduled domain updates: Organizations may have scheduled updates or migrations that involve modifying federation domains, which can be mistaken for malicious activity.
-- Integration with new identity providers: When an organization integrates a new external identity provider, it may involve adding or modifying federation domains, which could be flagged by the rule.
-- To manage these false positives, users can create exceptions for known administrative accounts or scheduled maintenance windows, ensuring that only unexpected or unauthorized changes trigger alerts.
-- Implementing a review process for flagged events can help distinguish between legitimate administrative actions and potential threats, reducing the number of false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected accounts or systems to prevent further unauthorized access.
-- Review the audit logs to identify the scope of the changes made to federation domains and determine if any unauthorized domains were added or modified.
-- Revert any unauthorized changes to federation settings by restoring the original configuration from backups or documented settings.
-- Conduct a thorough investigation to identify the source of the unauthorized changes, including reviewing user activity and access logs.
-- Escalate the incident to the security operations team and, if necessary, involve legal or compliance teams to assess potential impacts.
-- Implement additional monitoring and alerting for changes to federation domains to detect future unauthorized modifications promptly.
-- Enhance logging policies to ensure comprehensive capture of authentication and federation-related activities, integrating with SIEM solutions for real-time analysis.
-- Educate users and administrators on the importance of secure federation settings and the risks associated with unauthorized modifications.
-- Apply security hardening measures such as multi-factor authentication (MFA) for administrative accounts and regular reviews of federation trust relationships.
-- Review and update incident response plans to incorporate lessons learned from the investigation and ensure readiness for similar future incidents.
-
-## Setup
+note = """## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
index 532b4ab7e4a..7feaeba1c62 100644
--- a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
+++ b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/11"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -51,49 +51,6 @@ event.dataset: okta.system
     and not okta.debug_context.debug_data.flattened.requestedScopes: ("okta.logs.read" or "okta.eventHooks.read" or "okta.inlineHooks.read")
     and okta.outcome.reason: "no_matching_scope"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials
-
-OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of a user. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token requests due to scope mismatches, signaling potential misuse by unfamiliar actors.
-
-### Possible investigation steps
-
-- Review the `okta.actor.display_name` field to identify the actor involved in the failed token grant attempt and determine if this actor is known or expected to request such scopes.
-- Examine the `okta.debug_context.debug_data.flattened.requestedScopes` field to understand which unauthorized scopes were requested and assess their potential impact if accessed.
-- Analyze the `okta.actor.type` field to confirm that the actor is indeed a "PublicClientApp" and verify if this aligns with the expected behavior of the application.
-- Investigate the `okta.outcome.reason` field, specifically looking for "no_matching_scope," to confirm that the failure was due to unauthorized scope requests.
-- Check the `okta.client.user_agent.raw_user_agent` field to ensure the request did not originate from known integrations like "Okta-Integrations," which are excluded from the rule.
-- Utilize Osquery to gather additional context on the system from which the request originated. For example, run an Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_of_interest>';`.
-- Correlate the event with other logs in the `event.dataset: okta.system` to identify any patterns or repeated attempts from the same actor or IP address.
-- Investigate the `okta.outcome.result` field to confirm the failure status and cross-reference with other successful attempts to identify any anomalies.
-- Review historical data for the `okta.actor.display_name` to determine if this is the first occurrence of such behavior or if there is a pattern of similar unauthorized attempts.
-- Consult with application owners or developers to verify if there have been any recent changes or updates to the application that might explain the unexpected scope request.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate public client apps are misconfigured or updated, leading to failed token requests due to scope mismatches. These apps might not pose a threat but trigger the rule due to their unfamiliar behavior.
-- Frequent legitimate actors, such as internal development teams testing new integrations or updates, might inadvertently cause false positives. Monitoring these actors over time can help identify patterns that are non-threatening.
-- To manage false positives, users can create exceptions for specific `okta.actor.display_name` values that are known to be safe and frequently involved in legitimate activities. This can be done by adding these values to the exclusion list in the detection rule.
-- Regularly review and update the list of excluded scopes and actors to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the rule in detecting genuine threats.
-- Consider implementing additional logging and monitoring for actors that are excluded to ensure that their behavior remains consistent with expected patterns and does not evolve into a potential threat.
-
-### Response and remediation
-
-- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts.
-- Investigate the source of the unauthorized scope request by reviewing logs and identifying the actor's IP address and user agent.
-- Conduct a thorough review of recent access logs to identify any other suspicious activities or anomalies associated with the compromised credentials.
-- Notify the security team and relevant stakeholders about the incident and provide them with details of the unauthorized access attempt.
-- Implement additional logging and monitoring for OAuth 2.0 token requests to detect similar unauthorized attempts in the future.
-- Update and enforce strong authentication policies for public client apps, including the use of multi-factor authentication where possible.
-- Review and restrict the scopes available to public client apps to minimize the risk of unauthorized access.
-- Educate developers and users about secure credential management practices to prevent future credential compromises.
-- Consider integrating with a Security Information and Event Management (SIEM) system to enhance threat detection and response capabilities.
-- Restore the system to its operational state by ensuring all security patches are applied and conducting a security audit to identify and address any vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
index 39b0b451063..816c943f532 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Delete an Okta Application"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Delete an Okta Application
-
-Okta is a widely used identity and access management service that helps organizations manage user authentication and application access. Adversaries may target Okta applications to disrupt operations or weaken security by attempting deletions. The detection rule monitors system events for deletion actions, identifying potential threats by flagging unauthorized attempts to remove applications, thus safeguarding organizational integrity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `okta.system` and the event action is `application.lifecycle.delete` to ensure the alert is valid.
-- Check the timestamp of the event to determine when the deletion attempt occurred and correlate it with any other suspicious activities around the same time.
-- Identify the user account associated with the deletion attempt by examining the event data, and verify if the account has legitimate access and permissions to perform such actions.
-- Investigate the IP address and location from which the deletion attempt was made to determine if it aligns with the user's typical access patterns.
-- Review recent login activities for the user account involved to identify any unusual or unauthorized access attempts.
-- Examine the application targeted for deletion to understand its role within the organization and assess the potential impact of its removal.
-- Utilize Osquery to gather additional context on the system from which the attempt was made. For example, run the query: `SELECT * FROM processes WHERE name LIKE '%okta%'` to identify any related processes running on the system.
-- Check for any recent changes in user permissions or roles that might have inadvertently allowed the deletion attempt.
-- Look for any other alerts or logs related to Okta applications or user accounts that might indicate a broader attack or compromise.
-- Document all findings and observations to build a comprehensive understanding of the incident and facilitate further analysis if needed.
-
-### False positive analysis
-
-- Routine maintenance or administrative tasks may trigger the detection rule if legitimate users with appropriate permissions delete or modify Okta applications as part of their job responsibilities.
-- Automated scripts or third-party integrations that manage application lifecycles could also generate false positives if they perform deletion actions as part of their normal operation.
-- To manage these false positives, organizations can create exceptions for specific user accounts or service accounts known to perform regular maintenance tasks, ensuring these actions are not flagged as threats.
-- Implementing a review process for flagged events can help distinguish between legitimate administrative actions and potential security threats, allowing for more accurate threat detection.
-
-### Response and remediation
-
-- Immediately isolate the affected Okta application to prevent further unauthorized actions and assess the scope of the incident.
-- Verify the identity and access permissions of the user or system that attempted the deletion to determine if it was a legitimate action or a compromised account.
-- Review Okta system logs and event history to gather detailed information about the deletion attempt, including timestamps, IP addresses, and user agents.
-- Escalate the incident to the security operations team for further investigation and to determine if other systems or applications are at risk.
-- Restore the deleted application from backups or snapshots, ensuring that all configurations and settings are intact and operational.
-- Implement additional logging and monitoring policies to capture detailed events related to application lifecycle changes in Okta.
-- Integrate Okta with a Security Information and Event Management (SIEM) system to enhance real-time monitoring and alerting capabilities.
-- Conduct a thorough review of access controls and permissions within Okta to ensure that only authorized personnel have the ability to modify or delete applications.
-- Educate users and administrators on the importance of strong authentication practices and the risks associated with unauthorized application modifications.
-- Consider implementing multi-factor authentication (MFA) and other security hardening measures to reduce the risk of unauthorized access and actions in the future.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
index 007b366adac..79b5c489099 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,50 +22,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Modify an Okta Application"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Modify an Okta Application
-
-Okta is a widely used identity and access management service that helps organizations manage user authentication and application access. Adversaries may target Okta applications to alter configurations, disable security features, or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to safeguard against potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.dataset is "okta.system" and the event.action is "application.lifecycle.update" to ensure the alert is valid and relevant.
-- Check the timestamp of the event to determine when the modification attempt occurred and correlate it with any other suspicious activities around the same time.
-- Identify the user or service account associated with the modification attempt by examining the user.id and user.name fields in the event data.
-- Investigate the IP address and geolocation from which the modification attempt was made to determine if it aligns with expected user behavior or if it appears suspicious.
-- Examine the specific application targeted for modification by reviewing the app.id and app.name fields to assess its criticality and potential impact on the organization.
-- Analyze the change details to understand what specific modifications were attempted, such as configuration changes or security feature deactivation.
-- Cross-reference the user or service account activity with recent login events to verify if there were any unusual login patterns or failed login attempts.
-- Utilize Osquery to gather additional context on the system from which the modification attempt originated. For example, run the following Osquery query to list recent processes executed on the system: `SELECT * FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
-- Check for any recent changes in user permissions or roles that might have inadvertently allowed unauthorized modification attempts.
-- Review audit logs and historical data for any previous similar modification attempts or patterns that could indicate a broader attack campaign.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or maintenance activities performed by authorized personnel may trigger the rule. To manage this, users can create exceptions for specific user accounts or roles known to perform these tasks frequently.
-- Scheduled application updates: Automated processes that update application configurations as part of scheduled maintenance can be mistaken for unauthorized modifications. Users should identify and exclude these processes from triggering alerts.
-- Integration with third-party services: Some integrations may require periodic updates to application settings, which could be flagged as modification attempts. Users can whitelist these integrations to prevent false positives.
-- Testing and development environments: Changes made in non-production environments for testing purposes might be detected by the rule. Users should consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these contexts.
-
-### Response and remediation
-
-- Immediately isolate the affected Okta application to prevent further unauthorized modifications.
-- Review the Okta system logs to identify the source and scope of the modification attempt, focusing on the event.dataset:okta.system and event.action:application.lifecycle.update.
-- Verify the integrity of the Okta application configurations and restore them to their last known good state if any unauthorized changes are detected.
-- Conduct a thorough investigation to determine if any user accounts have been compromised, and reset credentials for affected accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed audit trails of application lifecycle events and user activities within Okta.
-- Integrate Okta with a security information and event management (SIEM) system to enable real-time monitoring and alerting of suspicious activities.
-- Review and update access controls and permissions for Okta applications to ensure the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users and administrators on security best practices and the importance of reporting suspicious activities to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/impact_possible_okta_dos_attack.toml b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
index 1f1749a802e..6300d7e24df 100644
--- a/rules/integrations/okta/impact_possible_okta_dos_attack.toml
+++ b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -16,50 +16,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Possible Okta DoS Attack"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Possible Okta DoS Attack
-
-Okta is a widely used identity and access management service that facilitates secure user authentication and application integration. Adversaries may exploit Okta by overwhelming it with excessive requests, leading to a Denial of Service (DoS) that disrupts business operations. The detection rule identifies potential DoS attacks by monitoring for specific rate limit violations and warnings, indicating abnormal activity that could signify an attack.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of rate limit violations by checking the `event.action` field for values like `application.integration.rate_limit_exceeded`, `system.org.rate_limit.warning`, `system.org.rate_limit.violation`, or `core.concurrency.org.limit.violation`.
-- Examine the `event.dataset` field to ensure it is set to `okta.system`, confirming the alert is related to Okta system events.
-- Correlate the timestamps of the alerts to identify patterns or spikes in activity that may indicate a coordinated attack.
-- Investigate the source IP addresses associated with the suspicious activity to determine if they are known or have been flagged in past incidents.
-- Check the user accounts involved in the events to see if they are legitimate users or potentially compromised accounts.
-- Analyze the frequency and volume of requests to identify if the activity is consistent with a DoS attack or if it could be a result of legitimate high usage.
-- Use Osquery to gather additional context on the systems involved. For example, run a query to list all active network connections: `SELECT * FROM listening_ports WHERE port = 443;` to check for unusual connections to Okta services.
-- Review historical logs to identify any previous occurrences of similar rate limit violations and determine if there is a recurring pattern.
-- Investigate any recent changes in the organization's Okta configuration or integrations that might have inadvertently caused increased load or rate limit issues.
-- Collaborate with the network team to analyze network traffic patterns during the time of the alert to identify any anomalies or potential sources of the excessive requests.
-
-### False positive analysis
-
-- High-volume legitimate traffic: Organizations with high user activity may naturally exceed rate limits without malicious intent. This can occur during peak business hours or when deploying new applications that require extensive authentication requests.
-- Automated processes: Scheduled tasks or automated scripts that interact with Okta services might trigger rate limit warnings if they perform numerous requests in a short period.
-- Integration testing: During the development or testing of new integrations, developers may inadvertently generate excessive requests, leading to false positives.
-- To manage these false positives, users can create exceptions for known high-traffic periods or specific IP addresses associated with trusted automated processes. Additionally, monitoring and adjusting rate limits based on typical organizational activity can help reduce unnecessary alerts.
-
-### Response and remediation
-
-- Immediately assess the scope of the attack by reviewing logs for the specific rate limit violations and warnings identified in the detection query.
-- Contain the attack by implementing IP blocking or rate limiting on the source of excessive requests, if identifiable.
-- Notify the security operations team and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response.
-- Investigate the origin of the attack to determine if it is part of a larger threat campaign or a targeted attack against the organization.
-- Remediate by working with Okta support to ensure that any affected services are restored to normal operation and that any temporary measures are lifted once the threat is mitigated.
-- Escalate the incident to higher management and legal teams if the attack results in significant business disruption or data compromise.
-- Enhance logging policies to ensure comprehensive capture of authentication and access events, enabling better detection and analysis of future incidents.
-- Integrate additional security tools, such as intrusion detection systems or SIEM solutions, to improve monitoring and response capabilities.
-- Restore the system to its operational state by verifying that all services are functioning correctly and that no unauthorized changes have been made.
-- Implement hardening measures, such as multi-factor authentication and stricter access controls, to reduce the risk of future DoS attacks and improve overall security posture.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
index f8e9e870fd4..7b3bfb33839 100644
--- a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
+++ b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -13,54 +13,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Okta FastPass Phishing Detection"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Okta FastPass Phishing Detection
-
-Okta FastPass is a security feature that enhances user authentication by preventing access to phishing sites. Adversaries may attempt to exploit this by redirecting users to malicious sites to capture credentials. The detection rule identifies failed authentication attempts where FastPass blocks phishing, signaling potential phishing activity. This helps security analysts quickly respond to and mitigate phishing threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `event.dataset:okta.system` and `event.category:authentication` fields, ensuring the alert is related to an authentication event.
-- Verify the `okta.event_type:user.authentication.auth_via_mfa` field to confirm that the authentication attempt involved multi-factor authentication, which adds context to the security posture.
-- Check the `event.outcome:failure` field to ensure the authentication attempt was unsuccessful, indicating a potential phishing attempt blocked by FastPass.
-- Investigate the `okta.outcome.reason:"FastPass declined phishing attempt"` field to confirm that the failure was due to FastPass identifying a phishing attempt.
-- Identify the user involved in the alert by examining the user-related fields in the event data to determine if they have a history of similar alerts or suspicious activity.
-- Analyze the timestamp of the event to correlate with other security events or logs that might provide additional context or evidence of a broader attack.
-- Use Osquery to gather additional information about the user's device at the time of the alert. For example, run the following Osquery query to check for recent network connections that might indicate communication with suspicious domains:
-  ```sql
-  SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL AND remote_port != 0;
-  ```
-- Investigate any associated IP addresses or domains from the alert to determine if they are known for malicious activity by cross-referencing threat intelligence sources.
-- Review the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior that might suggest compromised credentials.
-- Collaborate with other security tools and logs, such as firewall or proxy logs, to trace the origin of the phishing attempt and gather more context about the potential threat actor.
-
-### False positive analysis
-
-- Legitimate third-party applications or services that use authentication methods similar to phishing sites may trigger false positives. Security teams should review these instances to determine if they are benign.
-- Users accessing unfamiliar but legitimate websites for the first time might be flagged. Analysts should verify the legitimacy of these sites and consider adding them to an allowlist if they are deemed safe.
-- Internal testing environments that mimic phishing scenarios for training purposes can also be mistakenly identified. These should be documented and excluded from detection rules to prevent unnecessary alerts.
-- Frequent false positives from specific users or departments may indicate a need for additional user education or adjustments to the detection parameters. Security teams can create exceptions for known safe behaviors to reduce noise.
-- Collaboration with IT and security teams to regularly update and refine the list of exceptions can help maintain the balance between security and usability, ensuring that legitimate activities are not hindered by the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected user account to prevent further unauthorized access and notify the user of the potential phishing attempt.
-- Conduct a thorough investigation of the phishing attempt by analyzing logs and identifying the source of the phishing URL to understand the scope of the attack.
-- Review and update email filtering and web proxy settings to block the identified phishing domain and similar malicious domains.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if other users or systems have been targeted.
-- Implement additional logging policies to capture detailed authentication events and user activity for enhanced monitoring and future investigations.
-- Integrate threat intelligence feeds with security information and event management (SIEM) systems to improve detection of phishing attempts and related threats.
-- Restore the affected user account by resetting credentials and ensuring no unauthorized changes were made to the account or associated systems.
-- Educate the user and potentially affected employees on recognizing phishing attempts and best practices for maintaining account security.
-- Review and update security policies and procedures to incorporate lessons learned from the incident and improve organizational resilience against phishing attacks.
-- Apply hardening measures such as enabling multi-factor authentication (MFA) for all users and regularly updating security software to protect against similar threats in the future.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
index 6de4d09f5ac..1dcfb9ddfb6 100644
--- a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
+++ b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/14"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -13,54 +13,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Unauthorized Access to an Okta Application"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unauthorized Access to an Okta Application
-
-Okta is a widely used identity management service that facilitates secure user authentication across applications. Adversaries may exploit valid credentials to gain unauthorized access, bypassing security controls. The detection rule monitors specific Okta system events, flagging attempts to access applications without proper authorization, thus helping identify potential breaches early.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.dataset is "okta.system" and the event.action is "app.generic.unauth_app_access_attempt" to ensure the alert is valid.
-- Check the timestamp of the unauthorized access attempt to determine when the event occurred.
-- Identify the user account involved in the unauthorized access attempt by examining the user.id and user.name fields in the event data.
-- Investigate the source IP address from which the unauthorized access attempt originated to determine if it is known or suspicious.
-- Cross-reference the source IP address with threat intelligence feeds to check for any known malicious activity associated with it.
-- Review the application details, such as app.id and app.name, to understand which application was targeted in the unauthorized access attempt.
-- Analyze the user's recent activity logs in Okta to identify any unusual behavior or patterns that could indicate compromised credentials.
-- Use Osquery to gather additional context on the endpoint associated with the user account. For example, run the following query to check for recent login activities:
-  ```sql
-  SELECT * FROM last WHERE username = '<user.name>';
-  ```
-- Check for any recent changes to the user's account settings or permissions that could have facilitated the unauthorized access attempt.
-- Collaborate with the IT or security team to gather additional logs or data from network devices, firewalls, or other security tools to correlate with the Okta event and build a comprehensive timeline of the incident.
-
-### False positive analysis
-
-- Employees using new devices or networks may trigger unauthorized access alerts if their login attempts are flagged as unusual. To manage this, consider creating exceptions for known employee devices or IP addresses.
-- Automated scripts or applications that interact with Okta using service accounts might be misidentified as unauthorized access attempts. Regularly review and whitelist these service accounts to prevent false positives.
-- Third-party integrations or applications that require frequent authentication checks can generate alerts. Ensure these integrations are documented and create exceptions for their expected behavior.
-- Users who frequently travel or work remotely might access Okta from various locations, leading to false positives. Implement geolocation-based exceptions for these users to reduce unnecessary alerts.
-- Temporary access granted to contractors or partners can be mistaken for unauthorized access. Maintain an updated list of authorized external users and adjust the detection rule to accommodate their access patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying any other compromised accounts or systems.
-- Review Okta logs and other relevant security logs to trace the adversary's actions and identify any additional unauthorized access attempts.
-- Reset passwords for the affected account and any other accounts that may have been compromised, ensuring the use of strong, unique passwords.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement multi-factor authentication (MFA) for all user accounts to enhance security and prevent future unauthorized access.
-- Review and update logging policies to ensure comprehensive monitoring of all authentication and access events in Okta.
-- Integrate Okta with a security information and event management (SIEM) system to enable real-time monitoring and alerting of suspicious activities.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements.
-- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent credential theft.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
index 408b58d2b6b..2da36ae59b4 100644
--- a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
+++ b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -40,51 +40,6 @@ event.dataset: "okta.system"
     and event.outcome: "success"
     and okta.client.device: ("Unknown" or "unknown")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Successful Application SSO from Rare Unknown Client Device
-
-Single sign-on (SSO) streamlines user access across applications by using a single set of credentials. However, if compromised, it can be exploited by attackers to bypass security policies. Adversaries may leverage vulnerabilities to gain unauthorized access using stolen credentials. The detection rule identifies unusual SSO events from unknown devices, signaling potential misuse of valid accounts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a successful SSO event from an unknown client device by checking the `event.dataset`, `event.action`, `event.outcome`, and `okta.client.device` fields.
-- Verify the user account involved in the SSO event by examining the user details in the alert and cross-referencing with known user activity and access patterns.
-- Check the user-agent string associated with the SSO event to identify any anomalies or inconsistencies that could indicate spoofing or the use of unauthorized devices.
-- Investigate the IP address associated with the SSO event to determine its geolocation and assess whether it aligns with the user's typical access locations.
-- Review recent login history for the user account to identify any other unusual or suspicious login attempts, especially from unknown devices or locations.
-- Utilize Osquery to gather additional context on the device involved in the SSO event. For example, run the following Osquery query to check for recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<IP_ADDRESS_FROM_ALERT>';`
-- Examine Okta logs for any recent changes to the user's account settings or permissions that could indicate account compromise or unauthorized access.
-- Check for any other security alerts or incidents involving the same user account or IP address to identify potential patterns of malicious activity.
-- Collaborate with the user to verify whether they recognize the device and the SSO event, and gather any additional context they can provide about their recent activities.
-- Review the organization's security policies and configurations related to SSO and Okta to ensure they are properly enforced and have not been bypassed or misconfigured.
-
-### False positive analysis
-
-- Employees using new or updated devices may trigger false positives if the device is not yet recognized by the system. This can occur when users upgrade their hardware or use a different browser that alters the user-agent string.
-- Remote workers accessing applications from different locations or networks, such as public Wi-Fi or VPNs, might appear as unknown devices, leading to false positives.
-- IT personnel conducting legitimate testing or troubleshooting activities on unregistered devices can also trigger this rule.
-- To manage these false positives, organizations can create exceptions for known and trusted devices by maintaining an updated inventory of user devices and their corresponding user-agent strings.
-- Implementing a process to quickly verify and whitelist new devices for regular users can help reduce unnecessary alerts.
-- Regularly reviewing and updating network and device policies to reflect changes in user behavior and technology can minimize false positives.
-- Encourage users to report new devices or changes in their access patterns to IT, allowing for proactive adjustments to the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the breach, focusing on identifying any other accounts accessed from the same unknown device.
-- Review Okta logs and cross-reference with other security logs to identify any lateral movement or additional suspicious activities.
-- Reset passwords for compromised accounts and enforce multi-factor authentication (MFA) for all users to mitigate the risk of future unauthorized access.
-- Escalate the incident to the security operations center (SOC) and inform relevant stakeholders, including IT and management, to ensure coordinated response efforts.
-- Apply patches or updates to Okta's Classic Engine to address any known vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed user-agent strings and device information for future investigations.
-- Integrate Okta with a security information and event management (SIEM) system to enable real-time monitoring and alerting of suspicious SSO activities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent credential theft."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
index 17b4d76a13b..12c7bfaf265 100644
--- a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
+++ b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -17,54 +17,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Suspicious Activity Reported by Okta User"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Activity Reported by Okta User
-
-Okta is an identity management service that enables secure user authentication and access control. Adversaries may exploit valid user accounts to gain unauthorized access, bypassing security measures. The detection rule monitors for user-reported suspicious activity, signaling potential account compromise. By analyzing these alerts, security teams can identify and mitigate unauthorized access attempts, aligning with MITRE ATT&CK's Initial Access tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event dataset is `okta.system` and the event action is `user.account.report_suspicious_activity_by_enduser`.
-- Verify the identity of the user who reported the suspicious activity by checking their user profile and recent login history in Okta.
-- Analyze the user's login history for any unusual patterns, such as logins from unfamiliar IP addresses or locations.
-- Check for any recent changes to the user's account settings, such as password changes or multi-factor authentication (MFA) modifications.
-- Investigate any other alerts or logs related to the same user account within the same timeframe to identify potential correlations.
-- Use Osquery to gather additional context on the user's device. For example, run the following query to check for recent login attempts on the user's machine:
-  ```sql
-  SELECT * FROM last WHERE username = '<username>';
-  ```
-- Examine network logs for any suspicious activity originating from the IP addresses associated with the reported suspicious activity.
-- Cross-reference the reported suspicious activity with known threat intelligence sources to identify any indicators of compromise (IOCs).
-- Review any recent changes in user permissions or access levels that could indicate unauthorized privilege escalation.
-- Document all findings and observations in a centralized investigation report to facilitate further analysis and decision-making.
-
-### False positive analysis
-
-- Known false positives for the Suspicious Activity Reported by Okta User rule may include legitimate users mistakenly reporting their own activity as suspicious, such as logging in from a new device or location that they forgot to whitelist.
-- Users may also report suspicious activity when they receive unexpected but legitimate security alerts or notifications from Okta, leading to unnecessary investigations.
-- To manage these false positives, security teams can implement exception lists for users who frequently report non-threatening activities, ensuring that their reports are reviewed with context.
-- Establishing a baseline of normal user behavior can help differentiate between genuine threats and benign activities, reducing the number of false positives.
-- Educating users on recognizing legitimate security alerts and understanding their own activity patterns can minimize incorrect reports and improve the accuracy of threat detection.
-
-### Response and remediation
-
-- Immediately isolate the affected user account to prevent further unauthorized access and limit potential damage.
-- Conduct a thorough investigation of the reported suspicious activity, reviewing logs and user actions to determine the scope and impact of the incident.
-- Reset the compromised user's password and enforce multi-factor authentication (MFA) to enhance account security.
-- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader threat or multiple compromised accounts.
-- Implement enhanced logging and monitoring for Okta and related systems to detect similar activities in the future, ensuring logs are retained for an appropriate period.
-- Integrate Okta with a security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
-- Review and update access control policies to ensure the principle of least privilege is enforced across the organization.
-- Conduct a post-incident review to identify gaps in the current security posture and develop an action plan to address them.
-- Educate users on security best practices and the importance of reporting suspicious activities promptly to prevent future incidents.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
index c4606ed7e3d..9d015d679b8 100644
--- a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
+++ b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/19"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -20,51 +20,7 @@ interval = "30m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Multiple Okta Sessions Detected for a Single User"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Multiple Okta Sessions Detected for a Single User
-
-Okta is a widely used identity management service that facilitates secure user authentication across various applications. Adversaries may exploit session cookies to hijack user accounts, initiating unauthorized sessions from different locations. The detection rule identifies anomalies by flagging multiple active sessions with distinct IDs for a single user, excluding legitimate Okta system actors, thus highlighting potential session hijacking attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the user account involved and the specific session IDs that triggered the alert.
-- Verify the legitimacy of the user by checking recent login activities and patterns for any anomalies or deviations from the norm.
-- Use the `okta.authentication_context.external_session_id` field to correlate and identify all active sessions associated with the user account.
-- Investigate the `okta.actor.id` and `okta.actor.display_name` fields to ensure that the sessions are not initiated by legitimate Okta system actors.
-- Examine the geographical locations and IP addresses associated with each session to identify any unusual or unexpected access points.
-- Check for any recent changes in the user's account settings or permissions that could indicate unauthorized access.
-- Utilize Osquery to gather additional context on the user's device by running a query such as: `SELECT * FROM logged_in_users WHERE user = '<username>';` to identify any suspicious logins or processes.
-- Review any recent Okta system logs for failed login attempts or other suspicious activities that could be related to the session hijacking.
-- Cross-reference the session data with other security logs (e.g., firewall, VPN) to identify any correlated suspicious activities or access patterns.
-- Engage with the user to confirm whether they recognize the sessions and if they have recently accessed their account from multiple devices or locations.
-
-### False positive analysis
-
-- Legitimate use of multiple devices: Users may legitimately access their accounts from multiple devices, such as a laptop and a smartphone, leading to multiple session IDs. To manage this, organizations can create exceptions for users who frequently use multiple devices.
-- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing their accounts from various locations. Implementing geolocation-based exceptions for known travel patterns can help reduce false positives.
-- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Organizations should consider policy adjustments or exceptions for shared accounts to prevent unnecessary alerts.
-- Use of VPNs or proxy services: Users employing VPNs or proxy services may appear to have sessions from different locations. Identifying and excluding known VPN or proxy IP addresses can help mitigate these false positives.
-- Automated scripts or integrations: Some users may have automated scripts or integrations that initiate multiple sessions. Reviewing and excluding these known scripts or integrations can prevent false alerts.
-
-### Response and remediation
-
-- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access.
-- Notify the user of the suspicious activity and instruct them to change their password and review their account activity for any unauthorized actions.
-- Conduct a thorough investigation to determine the source of the session hijacking, including reviewing logs for unusual IP addresses or user-agent strings.
-- Escalate the incident to the security operations team if evidence of a broader compromise or lateral movement is detected.
-- Implement multi-factor authentication (MFA) for all user accounts to add an additional layer of security against session hijacking.
-- Review and enhance logging policies to ensure comprehensive capture of authentication events and session activities for future investigations.
-- Integrate Okta logs with a Security Information and Event Management (SIEM) system to enable real-time monitoring and alerting of suspicious activities.
-- Apply network segmentation and access controls to limit the potential impact of compromised accounts and restrict lateral movement.
-- Educate users on recognizing phishing attempts and the importance of safeguarding session cookies and credentials.
-- Regularly review and update security policies and procedures to incorporate lessons learned from the incident and align with best practices.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
index 6a2316ddabe..0260f558495 100644
--- a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
+++ b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Administrator Privileges Assigned to an Okta Group"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Administrator Privileges Assigned to an Okta Group
-
-Okta is a widely used identity management service that facilitates secure user authentication and authorization. Administrator roles in Okta grant elevated permissions, allowing significant control over user accounts and settings. Adversaries may exploit this by assigning admin roles to groups, thereby escalating privileges and maintaining unauthorized access. The detection rule monitors system events for privilege grants to groups, identifying potential misuse by flagging suspicious role assignments.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Okta group and the administrator role that was assigned, using the `event.dataset:okta.system` and `event.action:group.privilege.grant` fields for context.
-- Check the Okta system logs for any recent changes or unusual activities related to the group in question, focusing on the timeframe around the alert.
-- Identify the user account that performed the privilege assignment by examining the `actor.id` and `actor.alternateId` fields in the event logs.
-- Investigate the history of the user account that made the change to determine if there are any signs of compromise or unusual behavior, such as logins from unfamiliar locations or devices.
-- Cross-reference the group membership to identify all users who are now granted elevated privileges and assess if any of these accounts show signs of compromise.
-- Use Osquery to gather additional context on the systems used by the user account that made the change. For example, run the following Osquery query to list recent logins on the user's machine: `SELECT * FROM last WHERE username = '<username>';`.
-- Analyze any recent changes to the Okta configuration or policies that might have facilitated the unauthorized privilege assignment.
-- Review any associated alerts or incidents that might provide additional context or indicate a broader attack pattern.
-- Check for any other privilege assignments to groups within the same timeframe to identify potential patterns or coordinated actions.
-- Collaborate with the IT or security team to gather additional context on the business justification for the role assignment, if any, and verify its legitimacy.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may assign administrator roles to groups as part of regular maintenance or onboarding processes. To manage these, users can create exceptions for known administrative actions by whitelisting specific user accounts or groups involved in these tasks.
-- Organizational changes: During mergers, acquisitions, or restructuring, there may be a legitimate need to reassign roles and privileges. Users can handle these by temporarily adjusting the detection thresholds or excluding specific events during the transition period.
-- Automated processes: Some organizations use automated scripts or tools to manage user roles and permissions. These processes might trigger the detection rule. Users can exclude these automated actions by identifying and whitelisting the associated service accounts or scripts.
-- Testing and development: In environments where testing or development occurs, admin roles might be assigned to groups for testing purposes. Users can manage these by creating exceptions for specific test environments or by using separate detection rules for production and non-production environments.
-
-### Response and remediation
-
-- Immediately revoke the administrator privileges assigned to the Okta group to contain potential unauthorized access.
-- Conduct a thorough investigation to identify any compromised accounts within the group and assess the extent of unauthorized access or changes made.
-- Review recent Okta system logs for any suspicious activities or anomalies that coincide with the privilege assignment event.
-- Reset passwords and enforce multi-factor authentication (MFA) for all accounts within the affected group to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive analysis and response.
-- Implement enhanced logging and monitoring policies to capture detailed events related to privilege changes and group assignments in Okta.
-- Integrate Okta with a security information and event management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Conduct a post-incident review to identify gaps in security controls and update policies to prevent similar incidents in the future.
-- Apply hardening measures by limiting the number of users with the ability to assign administrator roles and regularly auditing group memberships.
-- Educate users and administrators on the risks associated with privilege escalation and the importance of adhering to the principle of least privilege.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
index 3da7365ca5c..65649731dde 100644
--- a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
+++ b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,49 +23,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Administrator Role Assigned to an Okta User"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Administrator Role Assigned to an Okta User
-Okta is a widely used identity management service that facilitates secure user authentication and authorization. Administrator roles in Okta grant elevated permissions, allowing users to manage settings and access controls. Adversaries may exploit this by assigning admin roles to themselves or compromised accounts to gain persistent access. The detection rule monitors system events for privilege grants, flagging suspicious admin role assignments to mitigate unauthorized access.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.dataset is "okta.system" and the event.action is "user.account.privilege.grant" to ensure the alert is valid and triggered by the correct rule.
-- Identify the user account that was assigned the administrator role by examining the relevant fields in the alert, such as user.name and user.id.
-- Check the timestamp of the event to determine when the administrator role was assigned and correlate it with any other suspicious activities around that time.
-- Investigate the source IP address and geolocation associated with the event to determine if the access was from an unusual or unexpected location.
-- Review the user's recent login history and activity logs in Okta to identify any anomalies or patterns that could indicate compromise.
-- Examine the change history for the user account to see if there were any recent modifications or unusual activities prior to the role assignment.
-- Use Osquery to gather additional context on the system where the role assignment was made. For example, run the following query to list recent Okta-related processes: `SELECT * FROM processes WHERE name LIKE '%okta%';`
-- Check for any other privilege escalation events or role assignments in the same timeframe to identify potential coordinated attacks or multiple compromised accounts.
-- Review the list of users with administrative roles in Okta to ensure no other unauthorized assignments have occurred.
-- Cross-reference the event with any other security alerts or incidents in your environment to determine if this is part of a larger attack campaign.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT staff may frequently assign administrator roles as part of their job responsibilities. To manage this, organizations can create exceptions for known IT personnel or specific time frames when such activities are expected.
-- Automated provisioning systems: Some organizations use automated systems to manage user roles, which might trigger the rule. Users can exclude events originating from these systems by identifying their unique identifiers or IP addresses.
-- Role-based access control updates: Regular updates to role-based access controls might involve temporary admin role assignments. Users can handle these by setting up alerts only for unexpected changes outside of scheduled maintenance windows.
-- Training and onboarding: New administrators might be assigned roles during training or onboarding processes. Organizations can mitigate false positives by excluding events related to new employee onboarding sessions or specific training periods.
-
-### Response and remediation
-
-- Immediately revoke the newly assigned administrator role from the affected Okta user account to prevent further unauthorized access.
-- Conduct a thorough investigation to determine if the role assignment was legitimate or if it indicates a compromise, reviewing recent activity logs for suspicious behavior.
-- Isolate the affected user account by temporarily disabling it until the investigation is complete to prevent potential lateral movement or further privilege escalation.
-- Notify the security team and relevant stakeholders about the incident for awareness and to initiate a coordinated response.
-- Review and enhance logging policies to ensure comprehensive capture of privilege changes and other critical events in Okta for future investigations.
-- Integrate Okta logs with a Security Information and Event Management (SIEM) system to enable real-time monitoring and alerting on suspicious activities.
-- Conduct a root cause analysis to identify how the adversary gained access and assigned the administrator role, addressing any identified vulnerabilities or misconfigurations.
-- Restore the system to its operational state by re-enabling legitimate user accounts and ensuring all security controls are functioning as intended.
-- Implement hardening measures such as multi-factor authentication (MFA) for all administrative accounts and regular audits of user permissions to reduce the risk of future incidents.
-- Escalate the incident to higher management and, if necessary, involve legal or law enforcement agencies if the breach is significant or involves sensitive data.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
index 5dea673d71c..babed655d21 100644
--- a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
+++ b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Create Okta API Token"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Create Okta API Token
-
-Okta API tokens are crucial for automating and managing access within an organization's network. They allow seamless integration and interaction with Okta's identity management services. However, adversaries can exploit these tokens to gain persistent access, manipulate user accounts, or disable security measures. The detection rule identifies suspicious token creation activities by monitoring specific Okta system events, helping to thwart unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `event.dataset:okta.system` and `event.action:system.api_token.create` fields, ensuring the alert is valid and corresponds to an API token creation attempt.
-- Identify the user account associated with the token creation attempt by examining the `actor.id` and `actor.alternateId` fields in the event logs.
-- Check the timestamp of the event to determine when the token creation attempt occurred and correlate it with other suspicious activities around the same time.
-- Investigate the IP address and geolocation from which the token creation request originated to identify any anomalies or unexpected locations.
-- Examine the `client.userAgent` field to understand the device and browser used during the token creation attempt, looking for any unusual or unauthorized devices.
-- Review recent login activities for the identified user account to detect any unauthorized access or unusual login patterns.
-- Use Osquery to gather additional context on the system from which the request originated. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious IP address>';`.
-- Check for any recent changes to user permissions or roles associated with the account in question, which might indicate privilege escalation attempts.
-- Analyze other Okta system events around the same timeframe to identify any related suspicious activities, such as failed login attempts or changes to security settings.
-- Collaborate with the IT or security team to verify if the token creation was part of a legitimate administrative task or if it requires further investigation.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may frequently create Okta API tokens for maintenance or integration purposes. To manage these, users can create exceptions for specific administrator accounts or IP addresses known to perform these tasks regularly.
-- Automated processes: Some automated systems or applications might generate Okta API tokens as part of their normal operation. Users should identify these systems and exclude their activities from triggering alerts by whitelisting their associated service accounts or application identifiers.
-- Third-party integrations: Organizations often use third-party services that require Okta API tokens for integration. Users can handle these by maintaining a list of approved third-party services and excluding their token creation activities from detection.
-- Testing environments: In development or testing environments, API tokens might be created frequently for testing purposes. Users can exclude these environments from monitoring by setting up environment-specific exceptions or filters.
-
-### Response and remediation
-
-- Immediately revoke the suspicious Okta API token to prevent further unauthorized access.
-- Conduct a thorough investigation to identify any unauthorized changes made using the token, such as new user accounts or altered security policies.
-- Review Okta system logs to trace the origin of the token creation attempt and identify any associated user accounts or IP addresses.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed API activity and monitor for unusual patterns or behaviors.
-- Integrate Okta with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Restore any unauthorized changes to user accounts or security settings to their original state.
-- Conduct a security review of Okta configurations and permissions to ensure least privilege access is enforced.
-- Educate users and administrators on the importance of API security and the risks associated with token misuse.
-- Regularly review and update security policies and procedures to incorporate lessons learned from the incident and improve future response efforts.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
index fbdbac4542a..a615d4a5740 100644
--- a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
+++ b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,50 +23,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Reset MFA Factors for an Okta User Account"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Reset MFA Factors for an Okta User Account
-
-Okta's MFA system enhances security by requiring multiple verification methods. Adversaries may exploit this by resetting MFA factors, allowing them to register their own and gain unauthorized access. The detection rule identifies such attempts by monitoring specific system events, alerting analysts to potential account manipulation threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `event.dataset:okta.system` and `event.action:user.mfa.factor.reset_all` fields, which indicate an attempt to reset MFA factors.
-- Identify the user account associated with the alert by examining the `user.name` or `user.id` fields in the event data.
-- Check the timestamp of the event to determine when the MFA reset attempt occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the source IP address and geolocation from which the MFA reset attempt was made to assess if it aligns with the user's typical access patterns.
-- Review the user's recent login history and activity logs in Okta to identify any unusual behavior or unauthorized access attempts.
-- Examine any changes to the user's account settings or permissions around the time of the MFA reset attempt to detect potential account manipulation.
-- Utilize Osquery to gather additional context on the user's device, such as running processes or network connections, to identify any signs of compromise. Example Osquery: `SELECT * FROM processes WHERE user = '<username>';`
-- Check for any other alerts or incidents involving the same user account or IP address to identify potential patterns or coordinated attacks.
-- Review the organization's change management and access request logs to verify if the MFA reset was authorized or part of a legitimate request.
-- Collaborate with the user or their manager to confirm whether the MFA reset attempt was expected or if it indicates unauthorized activity.
-
-### False positive analysis
-
-- Routine administrative actions: IT administrators may legitimately reset MFA factors for maintenance or user support, which can trigger the detection rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
-- User-initiated resets: Users might reset their own MFA factors due to lost devices or personal preference changes. Implement a verification process to confirm user-initiated actions and exclude these from alerts.
-- Automated processes: Some organizations use automated scripts or tools to manage MFA settings, which could be mistaken for malicious activity. Identify and whitelist these processes to prevent false positives.
-- Third-party integrations: Integrations with other security or identity management systems might reset MFA factors as part of their normal operation. Document and exclude these integrations from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
-- Verify the identity of the legitimate user through an out-of-band communication method to ensure they are not compromised.
-- Review recent login and activity logs for the affected account to identify any suspicious behavior or unauthorized access attempts.
-- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices.
-- Conduct a thorough investigation to determine how the adversary gained access to reset the MFA factors, focusing on potential phishing attacks or credential compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other accounts or systems are affected.
-- Implement enhanced logging and monitoring for Okta events, specifically focusing on MFA-related actions, to improve detection of similar threats in the future.
-- Integrate Okta logs with a security information and event management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials and MFA devices.
-- Review and update security policies and procedures related to account management and MFA to incorporate lessons learned from the incident and strengthen defenses against account manipulation.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
index 494e1b73a5b..7373dae2b31 100644
--- a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
+++ b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/01"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/09"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,53 +22,7 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Modification or Removal of an Okta Application Sign-On Policy"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 or Removal of an Okta Application Sign-On Policy
-
-Okta's sign-on policies are crucial for enforcing authentication controls within applications, ensuring secure access. Adversaries may target these policies to weaken security, potentially allowing unauthorized access. The detection rule monitors system events for policy updates or deletions, identifying suspicious activities that could indicate attempts to bypass or compromise authentication processes.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `event.action` that triggered the alert, focusing on `application.policy.sign_on.update` or `application.policy.sign_on.rule.delete`.
-- Examine the `event.dataset` field to confirm that the event is from `okta.system`, ensuring the alert is relevant to Okta system events.
-- Identify the user account associated with the event by reviewing the `user.name` or `actor.id` fields to determine if the action was performed by a legitimate user or a potential adversary.
-- Check the `event.time` field to establish a timeline of when the modification or deletion occurred, which can help correlate with other suspicious activities.
-- Investigate the `source.ip` field to determine the origin of the request, identifying if it came from a known or suspicious IP address.
-- Use Osquery to gather additional context on the system from which the modification was made. For example, run the following query to check for recent changes in Okta policies:
-  ```sql
-  SELECT * FROM okta_system_events WHERE action IN ('application.policy.sign_on.update', 'application.policy.sign_on.rule.delete') AND time > (SELECT MAX(time) - INTERVAL '1 DAY' FROM okta_system_events);
-  ```
-- Review recent login activities for the identified user account to check for any unusual patterns or anomalies, such as logins from unfamiliar locations or devices.
-- Analyze the `application.id` or `application.name` fields to determine which specific application’s sign-on policy was modified or deleted, assessing the potential impact on the organization.
-- Cross-reference the event with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack.
-- Consult with the application owner or relevant stakeholders to verify if the policy change was authorized and documented, providing additional context for the investigation.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate updates or deletions of sign-on policies by IT administrators during regular maintenance or policy updates can trigger this rule. To manage this, organizations can create exceptions for known administrative accounts or schedule maintenance windows where such activities are expected.
-- Policy testing and development: During the development or testing of new security policies, changes to sign-on policies may occur frequently. To handle these, organizations can exclude events from test environments or specific development accounts from triggering alerts.
-- Automated policy management tools: Some organizations use automated tools to manage and update security policies, which might result in frequent policy changes. Users can whitelist these tools or their associated accounts to prevent false positives.
-- Mergers or acquisitions: During organizational changes like mergers or acquisitions, policy modifications might be necessary to integrate systems. In such cases, temporary exceptions can be applied to accounts involved in the integration process to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate affected systems or accounts to prevent further unauthorized access.
-- Review Okta system logs to identify the source and scope of the policy modification or deletion.
-- Verify the integrity of other sign-on policies to ensure no additional unauthorized changes have been made.
-- Restore the original sign-on policy from backups or recreate it based on documented security requirements.
-- Conduct a thorough investigation to determine if any unauthorized access occurred during the policy modification period.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for Okta policy changes to detect future unauthorized modifications promptly.
-- Integrate Okta with a Security Information and Event Management (SIEM) system for centralized monitoring and alerting.
-- Educate users and administrators on the importance of maintaining strong authentication policies and recognizing potential security threats.
-- Review and update security policies and procedures to incorporate lessons learned from the incident and improve overall security posture.
-
-## Setup
+note = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
index ca1ef972651..d3ae5ec27f7 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/19"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,48 +57,6 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process Spawned by a Host
-
-The detection of unusual processes on a host leverages machine learning to identify anomalies in process behavior, particularly on systems not typically associated with malicious activity. Adversaries may exploit legitimate system binaries, known as LOLbins, to evade detection. The detection rule utilizes the ProblemChild ML model to flag processes that deviate from normal patterns, focusing on tactics like System Binary Proxy Execution to uncover potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process flagged as unusual, including the process name, path, and the host on which it was detected.
-- Check the process's parent process to understand the context of how it was spawned and whether it aligns with typical behavior for that host.
-- Investigate the user account associated with the process to determine if it is a legitimate user and if the activity aligns with their normal behavior.
-- Examine the process's command line arguments for any suspicious or unexpected parameters that could indicate malicious intent.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process and command line details: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<suspicious_process_name>';`
-- Cross-reference the process with known LOLbins to determine if it is a legitimate system binary being used in an unusual manner.
-- Analyze recent system logs and security events on the host to identify any other anomalies or related activities that occurred around the same time as the process execution.
-- Check for any network connections initiated by the process to external IP addresses, which could indicate data exfiltration or command and control communication.
-- Review any recent changes or updates to the host that could have introduced the unusual process, such as software installations or configuration changes.
-- Consult threat intelligence sources to see if the process or its behavior has been associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Known false positives for the Unusual Process Spawned by a Host rule often involve legitimate administrative tools or scripts that are used in non-standard ways, which may be flagged by the ProblemChild ML model. These can include system maintenance scripts or software updates that utilize system binaries in a manner similar to LOLbins.
-- Users can manage these false positives by creating exceptions for processes that are identified as non-threatening through consistent monitoring and verification. This involves analyzing the context in which the process is executed, such as the user account initiating the process and the frequency of its occurrence.
-- To handle frequent non-threatening behaviors, users can implement allowlists for specific processes or paths that are known to be safe, ensuring that these are regularly reviewed and updated to reflect any changes in the environment.
-- It is important to maintain a balance between reducing false positives and ensuring that potential threats are not overlooked, which can be achieved by continuously refining the detection rules and incorporating feedback from security teams.
-
-### Response and remediation
-
-- Isolate the affected host from the network to prevent further malicious activity and lateral movement.
-- Analyze the suspicious process and its parent processes to understand the scope and potential impact of the activity.
-- Terminate the suspicious process if it is confirmed to be malicious or unauthorized.
-- Review system logs and security alerts to identify any additional indicators of compromise or related activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and threat intelligence correlation.
-- Implement enhanced logging policies to capture detailed process execution data and network activity for future analysis.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities against similar threats.
-- Restore the system to its operational state by applying necessary patches, updates, and security configurations.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement system hardening measures, such as restricting the use of LOLbins and enforcing application whitelisting, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
index 03c093fa95b..479bddbead7 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,49 +57,6 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process Spawned by a Parent Process
-
-In modern security environments, machine learning models are pivotal in identifying anomalies. The detection rule leverages both supervised and unsupervised ML to flag processes that deviate from normal behavior, indicating potential misuse of legitimate tools (LOLBins) by adversaries. By correlating unusual child processes with known malicious patterns, it effectively uncovers stealthy tactics like masquerading, enhancing defense against evasion techniques.
-
-### Possible investigation steps
-
-- Review the alert details to identify the parent and child process names, process IDs, and the timestamp of the event.
-- Cross-reference the parent and child process names against known legitimate and malicious process lists to assess their typical behavior and reputation.
-- Use Osquery to gather additional context about the processes. For example, run the following query to retrieve details about the child process: `SELECT * FROM processes WHERE pid = <child_process_id>;`.
-- Investigate the command line arguments used by the child process to identify any suspicious or unusual parameters that may indicate malicious activity.
-- Check the parent process's historical behavior to determine if spawning the flagged child process is typical or anomalous for this parent.
-- Analyze the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Examine the network connections established by the child process using Osquery: `SELECT * FROM process_open_sockets WHERE pid = <child_process_id>;` to identify any unusual or unauthorized external communications.
-- Review recent system logs and security events around the time of the alert to identify any correlated activities or anomalies.
-- Investigate any file modifications or registry changes made by the child process to assess potential persistence mechanisms or system alterations.
-- Consult threat intelligence sources to determine if the process behavior or associated indicators of compromise (IOCs) match known attack patterns or campaigns.
-
-### False positive analysis
-
-- Known false positives for the Unusual Process Spawned by a Parent Process rule often involve legitimate administrative tools or scripts that are frequently used in enterprise environments. These tools may be flagged due to their unusual execution patterns or names that resemble known malicious processes.
-- Users can manage these false positives by creating exceptions for processes that are regularly used and verified as safe within their organization. This can be done by maintaining a whitelist of known benign processes or by configuring the detection system to ignore specific parent-child process relationships that are deemed non-threatening.
-- It's important to regularly review and update these exceptions to ensure they reflect current operational practices and do not inadvertently allow new threats to go undetected.
-- In environments where certain processes are known to exhibit behavior similar to LOLBins but are part of routine operations, users should document these cases and adjust the detection thresholds or rules accordingly to minimize unnecessary alerts.
-- Collaboration with IT and security teams is crucial to accurately identify and exclude these benign processes without compromising the overall security posture.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the unusual process and its parent process to determine the scope and impact of the activity.
-- Terminate the suspicious process and any associated processes that are confirmed to be malicious.
-- Review and analyze logs to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
-- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected anomalies with known threat patterns and adversary tactics.
-- Restore the system to its operational state by applying necessary patches, updates, and security configurations.
-- Conduct a post-incident review to identify gaps in detection and response capabilities and update security policies accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
index b1611718cce..14b9364879e 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,48 +58,6 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process Spawned by a User
-
-The detection of unusual processes spawned by users leverages machine learning to identify anomalies in user behavior and process execution. Adversaries may exploit legitimate tools, known as LOLbins, to evade detection by masquerading malicious activities as benign processes. This detection rule employs both supervised and unsupervised ML models to flag processes that deviate from typical user patterns, indicating potential misuse or malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name, user context, and timestamp of the unusual process execution.
-- Cross-reference the process name with known legitimate tools and LOLbins to determine if it is commonly used for legitimate purposes or known for malicious activity.
-- Analyze the user context to understand if the user typically runs such processes. Check historical data for any previous instances of this process being executed by the same user.
-- Investigate the parent process that spawned the unusual process to determine if it is a legitimate process or potentially compromised.
-- Use Osquery to gather additional context about the process. For example, run the following query to retrieve details about the process and its parent: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name = '<process_name>';`
-- Check for any recent changes in the user's behavior or system configuration that might explain the unusual process execution.
-- Examine network connections initiated by the process to identify any suspicious or unexpected external communications.
-- Review system logs and security events around the time of the process execution for any related anomalies or indicators of compromise.
-- Correlate the findings with other security alerts or incidents to determine if this is part of a broader attack campaign.
-- Document all findings and observations to provide a comprehensive overview of the investigation, which can be used for further analysis or reporting.
-
-### False positive analysis
-
-- Known false positives for the Unusual Process Spawned by a User rule may include legitimate administrative tools or scripts that are infrequently used but necessary for specific tasks, such as system updates or maintenance activities, which may be flagged due to their atypical execution patterns.
-- Users can manage these false positives by creating exceptions for processes that are verified as non-threatening. This can be done by analyzing the context in which these processes are executed, such as the time, user, and system involved, and then configuring the ML models to recognize these patterns as benign.
-- Another common false positive scenario involves software updates or installations that temporarily alter user behavior or process execution patterns. Users should document these occurrences and adjust the detection parameters to accommodate such changes without compromising security.
-- To handle false positives effectively, users should regularly review flagged processes and update the exception list to include any new legitimate processes that are consistently misclassified, ensuring that the detection system remains accurate and efficient.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the flagged process, including reviewing process execution details, parent processes, and associated user activity.
-- Utilize endpoint detection and response (EDR) tools to analyze the system for additional indicators of compromise (IOCs) and identify any persistence mechanisms.
-- Terminate the suspicious process and remove any associated files or artifacts identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team if the process is confirmed to be malicious or if there is evidence of broader compromise.
-- Implement enhanced logging policies to capture detailed process execution and user activity for future analysis and detection.
-- Integrate threat intelligence feeds to enrich alerts with context and improve detection capabilities against known LOLbins and masquerading techniques.
-- Restore the system to its operational state by applying necessary patches, updates, and verifying system integrity.
-- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly.
-- Implement hardening measures such as application whitelisting, user behavior analytics, and least privilege access controls to reduce the risk of similar incidents in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
index c9465a4e9e9..6e6e84e73d4 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,49 +62,6 @@ query = '''
 process where ((problemchild.prediction == 1 and problemchild.prediction_probability > 0.98) or
 blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
-
-The detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit this by masquerading legitimate processes to evade detection. The rule flags processes with high malicious scores or those on a blocklist, excluding known benign activities, to pinpoint potential threats effectively.
-
-### Possible investigation steps
-
-- Review the process details flagged by the alert, focusing on the `process.args` field to understand the command line arguments used, which may provide insights into the process's intent.
-- Check the `problemchild.prediction_probability` score to assess the confidence level of the machine learning model in classifying the process as malicious.
-- Investigate the parent process of the flagged event to determine if it is a legitimate process or if it has been compromised, using the `process.parent` field.
-- Cross-reference the process name and path against known legitimate software and common masquerading techniques to identify potential false positives.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with similar names or paths: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%<suspicious_process_name>%' OR path LIKE '%<suspicious_process_path>%';`
-- Examine the process's network activity to identify any suspicious connections or data exfiltration attempts, using network monitoring tools or logs.
-- Check for any recent changes or anomalies in the system's file integrity, focusing on the directories and files associated with the flagged process.
-- Review the system's event logs for any related security events or anomalies that occurred around the same time as the suspicious process execution.
-- Investigate the user account associated with the process execution to determine if it has been compromised or is exhibiting unusual behavior.
-- Correlate the findings with threat intelligence sources to identify if the process or its behavior matches any known threat actor techniques or campaigns.
-
-### False positive analysis
-
-- Known false positives for the Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score rule may include legitimate processes that mimic suspicious patterns, such as system updates or software installations that temporarily exhibit unusual behavior.
-- Users can manage these false positives by creating exceptions for processes that are verified as non-threatening, such as those related to trusted software updates or internal IT scripts.
-- Regularly review and update the blocklist and exception list to ensure that legitimate processes are not inadvertently flagged, especially after system updates or changes in software configurations.
-- Consider implementing additional context checks, such as verifying the digital signature of flagged processes, to differentiate between legitimate and malicious activities.
-- Engage with security teams to analyze flagged events and refine the machine learning model's parameters to reduce the likelihood of false positives while maintaining effective threat detection.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the flagged process to confirm its malicious nature, using forensic tools to analyze process behavior and associated files.
-- Review and cross-reference the process with known threat intelligence sources to identify any indicators of compromise (IOCs) related to the detected activity.
-- If confirmed malicious, terminate the process and remove any associated files or registry entries to prevent persistence.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and reduce false positives.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are correctly set.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement hardening measures such as application whitelisting, disabling unnecessary services, and enforcing least privilege access to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
index 153c2e86a99..12ba9cd1c50 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/21"
 
 [rule]
 author = ["Elastic"]
@@ -60,53 +60,6 @@ query = '''
 process where ((problemchild.prediction == 1 and problemchild.prediction_probability <= 0.98) or
 blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a Low Malicious Probability Score
-
-The detection leverages a machine learning model, ProblemChild, to identify potentially suspicious Windows processes. It flags events with a low probability of being malicious, focusing on defense evasion tactics like masquerading. Adversaries may exploit this by disguising malicious processes as legitimate ones. The rule detects such anomalies by analyzing process predictions and blocklist matches, excluding known benign patterns.
-
-### Possible investigation steps
-
-- Review the process details flagged by the ProblemChild model, focusing on the `process.args` field to understand the command line arguments used during execution.
-- Check the `problemchild.prediction_probability` to assess how close the event is to being considered benign, and prioritize investigation based on lower probabilities.
-- Investigate the `blocklist_label` to determine if the process is explicitly marked as malicious by the blocklist, which may indicate a higher risk.
-- Examine the parent process of the flagged event to identify if it was spawned by a known legitimate process or a potentially suspicious one.
-- Use Osquery to gather additional context about the process. For example, run the following query to get details about the process and its parent: 
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE pid = <flagged_process_pid>;
-  ```
-- Cross-reference the process path and name with known legitimate software to rule out false positives due to masquerading.
-- Analyze recent system logs and events around the time of the flagged process execution to identify any correlated suspicious activities.
-- Check for any recent changes or anomalies in the system's file system, registry, or network connections that could be related to the flagged process.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it shows signs of compromise.
-- Review historical data to see if the flagged process or similar processes have been detected previously, which might indicate a recurring issue or false positive pattern.
-
-### False positive analysis
-
-- Known false positives for this rule often include legitimate system processes or third-party applications that mimic common Windows processes for compatibility or performance reasons. These can be mistakenly flagged due to their resemblance to malicious activities.
-- Users may encounter false positives from software updates or installations that temporarily alter process names or paths, triggering the masquerading detection.
-- To manage these false positives, users can create exceptions for specific processes or paths that are consistently flagged but verified as non-threatening. This can be done by updating the rule to exclude these known benign patterns.
-- Regularly review and update the blocklist and exception list to ensure that new legitimate processes are not mistakenly flagged as threats.
-- Collaborate with IT and security teams to maintain a list of approved software and processes, which can be referenced when analyzing flagged events to quickly identify false positives.
-- Consider implementing additional context checks, such as verifying the digital signature of a process, to reduce the likelihood of false positives related to legitimate software masquerading as system processes.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the flagged process to determine if it is indeed masquerading as a legitimate process.
-- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
-- Utilize the MITRE ATT&CK framework to understand the adversary's tactics, techniques, and procedures, focusing on Defense Evasion and Masquerading.
-- If confirmed malicious, remove or quarantine the identified process and any associated files from the system.
-- Update antivirus and endpoint detection and response (EDR) solutions to block similar threats in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and machine learning models with existing security information and event management (SIEM) systems for improved detection capabilities.
-- Restore the system to its operational state by applying necessary patches, updates, and security configurations to prevent reoccurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
index 40fba83f661..0b7e329bef3 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,49 +57,6 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Host
-
-The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries may exploit legitimate binaries, known as LOLbins, to evade detection by masquerading them as benign processes. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific processes flagged as suspicious, including their names, paths, and associated host names.
-- Cross-reference the flagged processes with known legitimate binaries (LOLbins) to determine if they are being used in an unusual context.
-- Analyze the process tree to understand the parent-child relationships and identify any unusual process spawning patterns.
-- Check the process execution times and compare them with normal activity patterns for the host to identify anomalies.
-- Use Osquery to gather additional context on the suspicious processes. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name IN ('<suspicious_process_name>');`
-- Investigate the network connections initiated by the suspicious processes to identify any unusual or unauthorized external communications.
-- Examine the file hashes of the suspicious binaries and compare them against threat intelligence databases to check for known malicious signatures.
-- Review the user accounts associated with the execution of the suspicious processes to determine if there are signs of compromised credentials or privilege escalation.
-- Analyze the system logs for any additional indicators of compromise or related suspicious activities around the time the processes were executed.
-- Correlate the findings with other security alerts or incidents to determine if the suspicious processes are part of a larger attack campaign.
-
-### False positive analysis
-
-- Known false positives for the Suspicious Windows Process Cluster Spawned by a Host rule may include legitimate administrative tools or scripts that are frequently used in the environment but are flagged due to their resemblance to LOLbins or unusual execution patterns.
-- Users can handle these false positives by creating exceptions for specific processes or process clusters that are regularly observed and verified as non-threatening. This can be done by whitelisting certain process names or paths that are known to be safe.
-- It is important to regularly review and update these exceptions to ensure that they do not inadvertently allow malicious activity to go undetected. This involves monitoring the environment for changes in legitimate process behavior and adjusting the exceptions accordingly.
-- In environments where certain processes are known to execute with high frequency, users can adjust the sensitivity of the ML models or set thresholds to reduce the likelihood of these processes being flagged as suspicious.
-- Collaboration with IT and security teams to understand the context of flagged processes can help in distinguishing between false positives and genuine threats, ensuring that only benign activities are excluded from alerts.
-
-### Response and remediation
-
-- Isolate the affected host from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation of the flagged processes to confirm malicious activity, focusing on identifying any LOLbins or masquerading techniques used.
-- Terminate any identified malicious processes and remove any associated files or artifacts from the system.
-- Review and analyze system logs and security alerts to understand the scope of the attack and identify any additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are in place.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement hardening measures such as application whitelisting, disabling unnecessary services, and enforcing strict access controls to reduce the risk of future attacks."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
index abbf3125613..7e06990450b 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,52 +59,6 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Parent Process
-
-The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores, often linked to a common parent process. Adversaries exploit this by using legitimate binaries (LOLBins) to evade detection. The rule combines supervised and unsupervised ML models to flag anomalies, focusing on clusters with unusually high aggregate scores, indicating potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the parent process name and the associated child processes that triggered the alert. Focus on the aggregate score and individual malicious probability scores.
-- Cross-reference the parent process name with known legitimate binaries (LOLBins) to determine if it is commonly used for evasion techniques.
-- Use endpoint detection and response (EDR) tools to gather additional context on the parent process, including its command line arguments, execution path, and any associated network activity.
-- Investigate the timeline of the parent process and its child processes to identify any unusual patterns or sequences of execution that deviate from normal behavior.
-- Check the parent process and child processes against threat intelligence databases to see if they are associated with known malicious activity or threat actors.
-- Utilize Osquery to gather more information about the suspicious processes. For example, run the following query to list all processes spawned by the parent process:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = '<parent_process_name>');
-  ```
-- Analyze the file hashes of the suspicious processes using a threat intelligence platform to determine if they are known malware.
-- Examine the user account context under which the parent process and its child processes were executed to assess if there is any indication of compromised credentials.
-- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the process cluster.
-- If applicable, check for any recent changes or updates to the system or software that could explain the unusual process behavior, ensuring to rule out false positives.
-
-### False positive analysis
-
-- Known false positives for the Suspicious Windows Process Cluster Spawned by a Parent Process rule often involve legitimate administrative tools or scripts that are frequently used in enterprise environments. These tools may include PowerShell scripts, system management software, or other automation tools that mimic the behavior of malicious processes.
-- Users can handle these false positives by creating exceptions for specific parent processes that are known to spawn legitimate clusters of processes. This can be done by maintaining a whitelist of trusted parent process names or paths that are regularly reviewed and updated.
-- Another method to manage false positives is to analyze the context of the detected processes, such as the time of execution, user account involved, and network activity. This can help differentiate between benign and potentially malicious activities.
-- It is also recommended to monitor the frequency and pattern of these process clusters. If a particular cluster is consistently flagged but is known to be part of routine operations, it can be excluded from future alerts.
-- Collaboration with IT and security teams to understand the normal behavior of systems and applications can aid in refining the detection rules and reducing false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the parent process and its spawned processes to identify any malicious behavior or indicators of compromise.
-- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activity.
-- Review and analyze logs from the affected system to gather additional context and identify any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected anomalies with known threat actors and tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by applying the latest security patches and updates, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in detection and response capabilities, and update security policies and procedures accordingly.
-- Implement system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
index 84fdb9304ba..a010cb7e723 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,48 +59,6 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a User
-The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries may exploit legitimate binaries (LOLBins) to evade detection, masquerading as benign processes. This rule uses both supervised and unsupervised ML models to flag anomalies, focusing on clusters with shared user names and high aggregate scores, indicating potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific processes flagged as suspicious, focusing on the user name and the aggregate malicious probability score.
-- Cross-reference the flagged processes with known legitimate binaries (LOLBins) to determine if they are being used in an unusual context or manner.
-- Use process lineage analysis to trace the parent and child processes of the flagged processes, identifying any unusual or unexpected process relationships.
-- Investigate the user account associated with the suspicious processes to determine if there have been any recent changes in behavior or access patterns.
-- Check for any recent logins or access attempts from unusual locations or devices for the user associated with the suspicious processes.
-- Utilize Osquery to gather additional context on the suspicious processes. For example, run the following query to list all processes started by the user in question: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
-- Examine network connections initiated by the suspicious processes to identify any unusual or unauthorized external communications.
-- Review recent file modifications or creations by the suspicious processes to detect any potential data exfiltration or tampering activities.
-- Analyze system logs for any other anomalies or errors that coincide with the time frame of the suspicious process activity.
-- Correlate the findings with other security tools and logs to build a comprehensive picture of the potential threat and its scope.
-
-### False positive analysis
-
-- Legitimate administrative tools: Some legitimate administrative tools and scripts may trigger false positives due to their similarity to known malicious patterns. Users should review these alerts and consider adding exceptions for trusted tools frequently used in their environment.
-- Software updates and installations: During software updates or installations, processes may exhibit behaviors that resemble malicious activity. Users can mitigate these false positives by creating exceptions for known update processes or installation scripts.
-- Custom scripts and automation: Custom scripts or automated tasks that perform system-level operations might be flagged as suspicious. Users should evaluate these scripts and, if deemed safe, exclude them from detection to prevent unnecessary alerts.
-- Frequent use of LOLBins: In environments where legitimate use of LOLBins is common, such as in development or testing, these processes might be incorrectly classified as malicious. Users should identify and exclude these benign uses to reduce false positives.
-- Shared user accounts: Environments with shared user accounts may see higher false positive rates due to the aggregation of process scores. Users should consider monitoring these accounts separately or implementing more granular user tracking to better assess the context of alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the flagged processes to confirm malicious activity, focusing on the use of LOLBins and masquerading techniques.
-- Terminate any identified malicious processes and remove any associated files or executables from the system.
-- Review and analyze user account activity to identify any unauthorized access or privilege escalation attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and user activity, aiding in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and verifying system integrity.
-- Conduct a security awareness session for users to educate them on recognizing and reporting suspicious activities.
-- Implement system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/linux/collection_linux_clipboard_activity.toml b/rules/linux/collection_linux_clipboard_activity.toml
index 4134ee47e56..ab497282884 100644
--- a/rules/linux/collection_linux_clipboard_activity.toml
+++ b/rules/linux/collection_linux_clipboard_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -36,48 +36,6 @@ event.action:("exec" or "exec_event" or "executed" or "process_started") and
 process.name:("xclip" or "xsel" or "wl-clipboard" or "clipman" or "copyq") and
 not process.parent.name:("bwrap" or "micro")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Linux Clipboard Activity Detected
-
-Clipboard utilities on Linux facilitate data transfer between applications, enhancing user productivity. However, adversaries can exploit these tools to capture sensitive information copied by users. The detection rule identifies unusual clipboard activity by monitoring specific utilities initiated by uncommon process leaders, flagging potential unauthorized data collection attempts. This approach helps in identifying and mitigating clipboard-based data exfiltration threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which clipboard utility was triggered and the associated process leader by examining the `process.name` and `process.parent.name` fields.
-- Verify the legitimacy of the parent process by checking its usual behavior and purpose on the system, focusing on the `process.parent.name` field.
-- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior by examining the `user.name` field.
-- Check the process command line arguments for any unusual or suspicious parameters using the `process.command_line` field.
-- Correlate the event with other recent process start events on the host to identify any patterns or anomalies using the `event.category:process` and `event.type:start` fields.
-- Use Osquery to list recent clipboard-related processes and their parent processes with a query like: `SELECT pid, name, parent, path FROM processes WHERE name IN ('xclip', 'xsel', 'wl-clipboard', 'clipman', 'copyq');`
-- Investigate the network activity of the host around the time of the alert to identify any potential data exfiltration attempts.
-- Review system logs for any other suspicious activities or errors that occurred around the same time as the clipboard event.
-- Check for any recent changes in user permissions or group memberships that might explain the unusual process initiation.
-- Consult with the user or system owner to verify if the clipboard activity was expected or authorized, providing context from the gathered data.
-
-### False positive analysis
-
-- Known false positives for the Linux Clipboard Activity Detected rule may include legitimate applications or scripts that frequently use clipboard utilities for automation or data processing tasks. These can be triggered by system administrators or developers who use scripts to automate data transfer between applications.
-- Users can handle these false positives by creating exceptions for specific process parent names or user accounts that are known to perform legitimate clipboard operations. This can be done by updating the detection rule to exclude these known benign activities.
-- Another common false positive scenario involves desktop environments or window managers that use clipboard utilities as part of their normal operation. Users should identify these environments and exclude their process parent names from the detection rule.
-- To manage false positives effectively, users should regularly review and update the list of excluded process parent names and user accounts based on observed activity patterns and organizational needs. This ensures that only non-threatening behaviors are excluded while maintaining the integrity of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the clipboard activity, focusing on the uncommon process leaders identified in the alert.
-- Review system logs and process execution history to determine if any unauthorized data access or transfer occurred.
-- If malicious activity is confirmed, remove any unauthorized software or scripts that may have been used to capture clipboard data.
-- Change passwords and credentials that may have been exposed through clipboard activity to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and clipboard activity for future investigations.
-- Integrate threat intelligence feeds to correlate clipboard activity with known threat actors or campaigns.
-- Restore the system to its operational state by applying security patches and updates, and ensure all security configurations are properly set.
-- Harden the system by restricting clipboard access to trusted applications and users, and consider using application whitelisting to prevent unauthorized process execution."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
index d17f37ac6ed..67bd077656d 100644
--- a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
+++ b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/21"
 
 [rule]
 author = ["Elastic"]
@@ -32,49 +32,6 @@ timestamp_override = "event.ingested"
 query = '''
 host.os.type: "linux" and event.category: "process" and process.name: "aws" and process.args:  "--endpoint-url"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS CLI Command with Custom Endpoint URL
-
-The AWS CLI allows users to interact with AWS services via command-line, offering flexibility in managing cloud resources. The `--endpoint-url` option lets users specify alternative endpoints, which can be exploited by adversaries to reroute requests to malicious servers, bypassing security measures. The detection rule identifies such misuse by monitoring Linux processes for AWS CLI commands using this option, flagging potential unauthorized activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `--endpoint-url` argument in the AWS CLI command and identify the specific custom endpoint URL used.
-- Examine the process execution context by checking the `host.os.type`, `event.category`, and `process.name` fields to ensure the alert is relevant and correctly triggered.
-- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Check the command history for the user to identify any other unusual or unauthorized AWS CLI commands executed around the same time.
-- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE name = 'aws' AND cmdline LIKE '%--endpoint-url%'`.
-- Analyze network logs to trace any outbound connections to the custom endpoint URL and determine if the destination is known or potentially malicious.
-- Review AWS CloudTrail logs for any corresponding API calls made using the custom endpoint to assess the scope and impact of the activity.
-- Investigate any related IAM roles or credentials used in the AWS CLI command to ensure they have not been compromised or misused.
-- Correlate the alert with other security events or anomalies on the host to identify any patterns or indicators of a broader attack.
-- Consult threat intelligence sources to check if the custom endpoint URL or associated IP addresses are linked to known malicious activities or actors.
-
-### False positive analysis
-
-- Legitimate use of the `--endpoint-url` option may occur in development or testing environments where developers use local or custom endpoints to simulate AWS services, which can trigger false positives.
-- Organizations using AWS-compatible services from third-party providers might configure the AWS CLI with custom endpoints, leading to benign alerts.
-- Automated scripts or CI/CD pipelines that interact with mock services for testing purposes may also use custom endpoints, resulting in false positives.
-- To manage these false positives, users can create exceptions or whitelist specific processes or environments known to use custom endpoints legitimately, ensuring that only unexpected or unauthorized uses are flagged.
-- Regularly review and update the list of approved custom endpoints and associated processes to minimize false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Review AWS CloudTrail logs and other relevant logs to identify any unauthorized API calls or data access attempts associated with the custom endpoint URL.
-- Conduct a thorough investigation to determine the scope of the compromise, including identifying any other systems or accounts that may have been affected.
-- Revoke any potentially compromised AWS credentials and rotate access keys and passwords for affected accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for AWS CLI usage, focusing on the detection of the `--endpoint-url` argument in future commands.
-- Integrate threat intelligence feeds to identify known malicious endpoints and update security controls to block them.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
-- Educate users on the risks associated with using custom endpoint URLs and provide training on secure AWS CLI usage practices."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/command_and_control_curl_socks_proxy_detected.toml b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
index 11055191e04..24109e074a5 100644
--- a/rules/linux/command_and_control_curl_socks_proxy_detected.toml
+++ b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/04"
 
 [rule]
 author = ["Elastic"]
@@ -79,49 +79,6 @@ process.name == "curl" and (
   process.env_vars like ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Activity from Unusual Parent
-
-Curl is a versatile command-line tool used for transferring data with URLs, often employed for legitimate data retrieval. However, adversaries can exploit it to establish SOCKS proxy connections, bypassing network restrictions for data exfiltration or C2 communication. The detection rule identifies suspicious curl usage by monitoring its execution from atypical parent processes and specific proxy-related arguments, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `curl` process execution with SOCKS proxy options and identify the unusual parent process from which it was launched.
-- Examine the parent process's executable path and name to determine if it is located in a suspicious directory such as `/dev/shm/`, `/tmp/`, or `/var/tmp/`, which are commonly used for temporary or potentially malicious activities.
-- Investigate the command-line arguments used with the `curl` process to verify the presence of SOCKS proxy options like `--socks5-hostname`, `--proxy`, or `-x`, which may indicate an attempt to bypass network restrictions.
-- Check the environment variables associated with the `curl` process for any proxy settings such as `http_proxy=socks5h://*`, which could suggest the use of a proxy for data exfiltration or C2 communication.
-- Use Osquery to gather additional context about the `curl` process and its parent. For example, run the following query to list processes with their parent details: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name = 'curl';`
-- Investigate the parent process's history and behavior by reviewing shell history files (e.g., `.bash_history`) to identify any commands that may have led to the execution of the `curl` process.
-- Analyze network logs to identify any unusual outbound connections made by the `curl` process, focusing on connections to external IP addresses or domains that are not part of normal business operations.
-- Correlate the alert with other security events or logs to identify any related activities or patterns that may indicate a broader attack campaign or compromise.
-- Review user activity and access logs to determine if the user associated with the `curl` process execution has a history of suspicious behavior or if their credentials may have been compromised.
-- Consult threat intelligence sources to check if the IP addresses or domains contacted by the `curl` process are associated with known malicious activities or threat actors.
-
-### False positive analysis
-
-- **System Administrators and Developers**: Legitimate use of curl with SOCKS proxy options by system administrators or developers for testing or maintenance purposes can trigger false positives. To manage this, consider creating exceptions for specific user accounts or known maintenance scripts.
-- **Automated Scripts and Tools**: Some automated scripts or tools may use curl with SOCKS proxy options for legitimate data retrieval or network testing. Identify these scripts and exclude them by specifying their parent process paths or names in the detection rule.
-- **Security Tools and Monitoring Solutions**: Security tools that perform network diagnostics or monitoring might use curl with SOCKS proxy options. Verify the source of these processes and exclude them if they are part of trusted security solutions.
-- **Custom Applications**: Custom applications developed in-house might use curl for legitimate purposes, including through SOCKS proxies. Document these applications and adjust the detection rule to exclude their specific parent processes or execution paths.
-- **Frequent Network Testing**: Organizations that frequently conduct network testing or audits might see false positives from legitimate curl usage. Establish a list of known testing activities and exclude them from the rule to reduce noise.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration or communication with C2 servers.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on unusual parent processes and the use of SOCKS proxy options with curl.
-- Review system logs and network traffic to trace the origin of the malicious activity and identify any other potentially compromised systems.
-- Remove any unauthorized or suspicious scripts and files found in directories like /dev/shm, /tmp, /var/tmp, and others specified in the detection rule.
-- Change credentials and keys that may have been exposed or used during the compromise, especially those related to network access and system administration.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all patches and updates are applied.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
-- Educate users and administrators on the risks associated with command-line tools and the importance of monitoring for unusual activity.
-- Apply system hardening measures, such as restricting the execution of scripts from writable directories and enforcing the principle of least privilege for user accounts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_ip_forwarding_activity.toml b/rules/linux/command_and_control_ip_forwarding_activity.toml
index c7bc87d22f3..442f15c5872 100644
--- a/rules/linux/command_and_control_ip_forwarding_activity.toml
+++ b/rules/linux/command_and_control_ip_forwarding_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/11/04"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ forwarding can be used to route network traffic between different network interf
 pivot between networks, exfiltrate data, or establish command and control channels.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "IPv4/IPv6 Forwarding Activity"
@@ -25,11 +27,13 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and
 process.parent.executable != null and process.command_line like (
   "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*",
   "*/proc/sys/net/ipv6/conf/all/forwarding*"
@@ -41,51 +45,6 @@ process.parent.executable != null and process.command_line like (
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 IPv4/IPv6 Forwarding Activity
-
-IPv4/IPv6 forwarding allows a system to route traffic between networks, a legitimate function in network management. However, attackers can exploit this to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on processes like `sysctl` and shell commands that modify forwarding settings, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command and process that triggered the rule, focusing on the `process.command_line` and `process.name` fields to understand the exact action taken.
-- Check the `process.parent.executable` field to determine the parent process that initiated the command, which can provide context on whether the action was part of a legitimate script or user activity.
-- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity aligns with the user's typical behavior or role.
-- Analyze the timing of the event by reviewing the `event.start` timestamp to correlate with other network or system activities that might indicate a broader attack pattern.
-- Use Osquery to gather additional context on the system's network configuration. For example, run the following query to check the current IP forwarding settings:
-  ```sql
-  SELECT * FROM osquery_flags WHERE name IN ('net.ipv4.ip_forward', 'net.ipv6.conf.all.forwarding');
-  ```
-- Examine recent login events on the host to identify any unusual or unauthorized access attempts that could be related to the suspicious activity.
-- Review network logs or use network monitoring tools to identify any unusual traffic patterns or connections that might suggest data exfiltration or lateral movement.
-- Check for any recent changes to network configurations or firewall settings on the host that could indicate an attempt to facilitate unauthorized network routing.
-- Investigate other processes running on the host around the same time as the alert to identify any additional suspicious activities or processes that might be part of a coordinated attack.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that use similar techniques, which could provide additional context or indicators of compromise.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may legitimately enable IP forwarding during network configuration or troubleshooting, leading to false positives. To manage this, users can create exceptions for known administrative scripts or specific user accounts that regularly perform these tasks.
-- Automated scripts and tools: Some network management tools or automated scripts might enable IP forwarding as part of their normal operation. Users should identify these tools and exclude their processes from triggering alerts by specifying their process names or command patterns in the exception list.
-- Containerized environments: In environments using containers, certain orchestration tools might enable IP forwarding to manage network traffic between containers. Users can handle these false positives by excluding processes associated with these tools or by monitoring only specific hosts where such behavior is unexpected.
-- Testing and development environments: Developers might enable IP forwarding during testing phases to simulate network conditions. Users can reduce false positives by excluding specific development environments or by setting up temporary exceptions during known testing periods.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify any unauthorized changes to IP forwarding settings and determine the scope of the compromise.
-- Review system logs and network traffic to identify any suspicious activities or connections that may indicate lateral movement or data exfiltration.
-- Revert any unauthorized changes to the system's IP forwarding settings to restore normal network configuration.
-- Apply patches and updates to the operating system and any relevant software to mitigate known vulnerabilities.
-- Implement strict access controls and ensure that only authorized personnel can modify network settings.
-- Enhance logging policies to capture detailed information on command executions and network configuration changes for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and response.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as disabling IP forwarding by default and using network segmentation to limit potential attack vectors."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_linux_kworker_netcon.toml b/rules/linux/command_and_control_linux_kworker_netcon.toml
index dfa722d3a7f..cebba118b0b 100644
--- a/rules/linux/command_and_control_linux_kworker_netcon.toml
+++ b/rules/linux/command_and_control_linux_kworker_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -70,48 +70,6 @@ process.name:kworker* and not destination.ip:(
   "FF00::/8"
 ) and not destination.port:("2049" or "111" or "892" or "597")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Activity Detected via Kworker
-
-Kworker processes are integral to Linux systems, handling tasks like interrupts and background activities within the kernel. However, attackers can exploit these processes to disguise malicious network activities, evading detection. The detection rule identifies suspicious network connections initiated by kworker processes, excluding legitimate internal and reserved IP ranges, to uncover potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a kworker process initiating a network connection, focusing on the `process.name:kworker*` field.
-- Verify the destination IP address to ensure it is not within the excluded internal and reserved IP ranges specified in the query.
-- Check the destination port to confirm it is not one of the excluded ports (2049, 111, 892, 597) and assess if the port is commonly used for legitimate services.
-- Use Osquery to list all active network connections on the host to identify any other unusual connections. Example query: `SELECT * FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name LIKE 'kworker%');`
-- Investigate the parent process of the kworker instance to determine if it was spawned by a legitimate process or if there are signs of process injection or tampering.
-- Examine the command line arguments and environment variables of the kworker process to identify any anomalies or suspicious parameters.
-- Review recent system logs and security events on the host for any signs of compromise or unusual activity preceding the alert.
-- Analyze the network traffic associated with the kworker process using packet capture tools to identify any suspicious patterns or data exfiltration attempts.
-- Cross-reference the alert with other security tools and logs to identify if there are correlated events or indicators of compromise.
-- Consult threat intelligence sources to determine if the destination IP or any related indicators are associated with known malicious activity.
-
-### False positive analysis
-
-- **Legitimate System Tasks**: Kworker processes are designed to handle legitimate system tasks such as managing hardware interrupts and executing scheduled kernel tasks. These activities might occasionally trigger the detection rule if they involve network connections, especially if they are directed to external IP addresses. Users can manage these by monitoring the frequency and context of such connections to determine if they align with expected system behavior.
-- **Network Monitoring Tools**: Some network monitoring or management tools might use kworker processes to perform legitimate network checks or diagnostics. If these tools are known and trusted, users can create exceptions for specific IP addresses or ports associated with these tools to prevent false positives.
-- **Custom Kernel Modules**: In environments where custom kernel modules are used, they might leverage kworker processes for network communication. Users should document and review these modules to ensure they are not inadvertently flagged by the rule. Exceptions can be made for specific modules or their associated network activities.
-- **Development and Testing Environments**: In development or testing environments, kworker processes might be used in unconventional ways that involve network communication. Users should assess whether these activities are part of normal operations and, if so, exclude them from the rule to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement.
-- Conduct a thorough investigation to confirm the legitimacy of the kworker process initiating the network connection, using tools like ps, netstat, or lsof to gather process details and network activity.
-- Analyze system logs and network traffic to identify any unusual patterns or connections that could indicate compromise, focusing on the time frame around the detected activity.
-- If malicious activity is confirmed, terminate the suspicious kworker process and any associated processes to stop ongoing threats.
-- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Restore the system by applying the latest security patches and updates, and ensure that the system is free from any backdoors or persistent threats.
-- Implement enhanced logging policies to capture detailed process and network activity, ensuring that future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events with known threat indicators.
-- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block unauthorized network connections and alert on suspicious activities.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as disabling unnecessary services and enforcing strict access controls, to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_linux_proxychains_activity.toml b/rules/linux/command_and_control_linux_proxychains_activity.toml
index 6af677c749b..f2230615631 100644
--- a/rules/linux/command_and_control_linux_proxychains_activity.toml
+++ b/rules/linux/command_and_control_linux_proxychains_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/23"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/05/21"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [transform]
 [[transform.osquery]]
@@ -39,7 +41,7 @@ resources. Attackers can exploit the ProxyChains utility to hide their true sour
 perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "ProxyChains Activity"
@@ -118,12 +120,14 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "proxychains"
 '''
 
diff --git a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
index 67dd0bf13e7..6e8a5b2e0fb 100644
--- a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
+++ b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/23"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/18"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [transform]
 [[transform.osquery]]
@@ -39,7 +41,7 @@ can abuse X11 forwarding for tunneling their GUI-based tools, pivot through comp
 communication channels, enabling lateral movement and facilitating remote control of systems within a network.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux SSH X11 Forwarding"
@@ -113,11 +115,13 @@ tags = [
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name in ("ssh", "sshd") and process.args in ("-X", "-Y") and process.args_count >= 3 and 
 process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
diff --git a/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml b/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml
index d0e52b96bfe..fb7dc238406 100644
--- a/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml
+++ b/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/23"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/05/21"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [transform]
 [[transform.osquery]]
@@ -40,7 +42,7 @@ detection, and perform malicious activities through a chain of proxy servers, po
 intentions.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Utility Launched via ProxyChains"
@@ -144,12 +146,14 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "proxychains" and process.args : (
   "ssh", "sshd", "sshuttle", "socat", "iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng",
   "ssf", "3proxy", "ngrok", "gost", "pivotnacci", "chisel*", "nmap", "ping", "python*", "php*", "perl", "ruby",
diff --git a/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml b/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml
index b1ca0af322f..c7132a16ec5 100644
--- a/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml
+++ b/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/23"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/05/21"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [transform]
 [[transform.osquery]]
@@ -39,7 +41,7 @@ and gain unauthorized access to internal resources, facilitating data exfiltrati
 control.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Tunneling and/or Port Forwarding"
@@ -145,12 +147,14 @@ tags = [
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and (
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
   (
     // gost & pivotnacci - spawned without process.parent.name
     (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or (process.name == "pivotnacci")) or (
diff --git a/rules/linux/credential_access_collection_sensitive_files.toml b/rules/linux/credential_access_collection_sensitive_files.toml
index 1e54759482e..b4def3d777d 100644
--- a/rules/linux/credential_access_collection_sensitive_files.toml
+++ b/rules/linux/credential_access_collection_sensitive_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -106,49 +106,6 @@ event.category:process and host.os.type:linux and event.type:start and
       /etc/gshadow
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Sensitive Files Compression
-
-Compression utilities like zip, tar, and gzip are commonly used to reduce file sizes for storage or transfer. Adversaries exploit these tools to bundle sensitive files, such as SSH keys or configuration files, for exfiltration. The detection rule identifies suspicious compression activities by monitoring process executions involving these utilities and targeting known sensitive file paths, thus alerting analysts to potential credential theft attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on the compression utility used (e.g., zip, tar, gzip).
-- Check the timestamp of the event to determine when the suspicious compression activity occurred and correlate it with other events around the same time.
-- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the command line arguments to identify the specific sensitive files targeted for compression and verify if these files are indeed present on the system.
-- Use Osquery to list recent process executions involving compression utilities with the following query: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name IN ('zip', 'tar', 'gzip', 'hdiutil', '7z');`
-- Analyze system logs for any signs of unauthorized access or privilege escalation that might have preceded the compression activity.
-- Check for any network connections or data transfer activities initiated by the user or process around the time of the alert to identify potential exfiltration attempts.
-- Investigate the file system for any newly created or modified compressed files that match the suspicious activity, focusing on their location and contents.
-- Review the system's audit logs to track any file access or modification events related to the sensitive files listed in the alert.
-- Cross-reference the alert with other security tools and logs to gather additional context and determine if this activity is part of a broader attack pattern.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may regularly compress sensitive files for legitimate backup or transfer purposes. To manage this, users can create exceptions for known administrative accounts or specific time windows when these tasks are expected.
-- Automated backup processes: Some systems may have scheduled jobs that compress sensitive files for backup. Users should identify and whitelist these processes by their specific command patterns or associated service accounts.
-- Development and testing activities: Developers might compress configuration files or credentials during testing or development. Users can exclude these activities by specifying development environments or user accounts involved in these tasks.
-- Security audits and compliance checks: Security teams may compress sensitive files as part of audits or compliance checks. Users should document and exclude these activities by recognizing the tools and accounts used during such operations.
-- Custom scripts or tools: Organizations might use custom scripts that compress sensitive files for internal processes. Users should review these scripts and exclude them by their unique signatures or execution paths.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on the processes and files involved in the suspicious compression activity.
-- Review system logs and process execution history to determine if any sensitive files were successfully exfiltrated.
-- Change all potentially compromised credentials, including SSH keys and AWS credentials, and update any related configurations.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring future suspicious activities are detected promptly.
-- Integrate security tools with threat intelligence platforms to correlate alerts with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Harden the system by implementing least privilege access controls, disabling unused services, and enforcing strong authentication mechanisms.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_credential_dumping.toml b/rules/linux/credential_access_credential_dumping.toml
index 5426b725923..8f23688749d 100644
--- a/rules/linux/credential_access_credential_dumping.toml
+++ b/rules/linux/credential_access_credential_dumping.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/02/27"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +16,7 @@ password-cracking utilities or prepare themselves for future operations by gathe
 victim.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Credential Dumping via Unshadow"
@@ -54,56 +56,16 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name == "unshadow" and process.args_count >= 3
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Linux Credential Dumping via Unshadow
-
-Unshadow is a utility within the John the Ripper suite, used to merge '/etc/shadow' and '/etc/passwd' files, creating a format suitable for password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of 'unshadow' by monitoring process initiation events with specific arguments, flagging potential credential dumping activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "unshadow" and verify the process arguments count is greater than or equal to 3, as these are key indicators of the rule trigger.
-- Check the user account associated with the process execution to determine if it is a privileged account or if the account has a history of suspicious activity.
-- Investigate the parent process of "unshadow" to understand how it was initiated and whether it was executed by a legitimate process or script.
-- Examine the command line arguments used with "unshadow" to identify the specific files targeted, such as '/etc/shadow' and '/etc/passwd', and assess if they align with typical usage patterns.
-- Utilize Osquery to gather additional context about the process execution. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'unshadow' LIMIT 1);`
-- Analyze system logs for any other suspicious activities or anomalies around the time of the "unshadow" execution, such as unauthorized access attempts or changes to user accounts.
-- Check for any recent file modifications or access to '/etc/shadow' and '/etc/passwd' using file integrity monitoring tools or logs to identify unauthorized access.
-- Investigate network activity from the host to detect any potential exfiltration of the combined credential files or communication with known malicious IP addresses.
-- Review historical data to determine if there have been previous instances of "unshadow" execution on the host, which could indicate a recurring threat or misconfiguration.
-- Correlate the findings with threat intelligence sources to identify if the activity matches known attack patterns or threat actor behaviors associated with credential dumping.
-
-### False positive analysis
-
-- System administrators or security teams may use the unshadow utility legitimately during security audits or password recovery operations. These activities can trigger the detection rule, leading to false positives.
-- Automated scripts or maintenance tasks that involve password management or system integrity checks might execute unshadow as part of their routine operations, causing benign alerts.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that are authorized to use unshadow. This can be done by whitelisting certain process execution contexts or by excluding specific user accounts from triggering the alert.
-- Regularly review and update the list of exceptions to ensure that only legitimate and necessary uses of unshadow are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the use of the unshadow utility and identify any unauthorized access or data extraction.
-- Review system logs and process execution history to determine the scope of the compromise and identify any additional affected systems.
-- Change all user passwords on the affected system and any other systems where the same credentials might have been used.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for critical files such as '/etc/shadow' and '/etc/passwd' to detect future unauthorized access attempts.
-- Integrate threat intelligence feeds to identify known indicators of compromise (IOCs) related to credential dumping and similar tactics.
-- Restore the system from a known good backup to ensure the integrity of the operating environment.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Conduct a security awareness training session for users to educate them on the importance of strong passwords and recognizing phishing attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_gdb_init_process_hooking.toml b/rules/linux/credential_access_gdb_init_process_hooking.toml
index 5700d1bb6ca..316c22a5392 100644
--- a/rules/linux/credential_access_gdb_init_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_init_process_hooking.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/30"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ dumping techniques to attempt secret extraction from privileged processes. Tools
 "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux init (PID 1) Secret Dump via GDB"
@@ -52,57 +54,16 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
 process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Linux init (PID 1) Secret Dump via GDB
-
-In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of GDB execution targeting PID 1, focusing on the `process.name` and `process.args` fields to ensure they match the rule criteria.
-- Check the user context under which the GDB process was executed to determine if it was initiated by a legitimate user or an unauthorized account.
-- Investigate the parent process of the GDB execution to understand how it was initiated, using the `parent_process.name` and `parent_process.args` fields.
-- Examine the command history of the user who executed GDB to identify any suspicious commands or patterns leading up to the event.
-- Use Osquery to gather additional context about the GDB process and its parent process. Example query: `SELECT * FROM processes WHERE pid = (SELECT parent FROM processes WHERE name = 'gdb' AND pid = 1);`
-- Analyze system logs around the time of the event to identify any other suspicious activities or anomalies that may correlate with the GDB execution.
-- Check for any recent changes to system binaries or configuration files that could indicate tampering or preparation for the attack.
-- Review network logs to identify any unusual outbound connections that may suggest data exfiltration attempts following the memory dump.
-- Investigate any other alerts or indicators of compromise on the host that may suggest a broader attack campaign.
-- Consult threat intelligence sources to determine if there are any known campaigns or adversaries using similar techniques, focusing on the MITRE ATT&CK technique T1003 for context.
-
-### False positive analysis
-
-- System administrators or developers may use GDB to debug legitimate issues with the init process, leading to false positives. In such cases, verify the identity and intent of the user executing GDB and consider adding exceptions for known maintenance activities.
-- Automated scripts or monitoring tools might inadvertently trigger this rule if they include debugging or diagnostic routines involving PID 1. Review these scripts to ensure they are authorized and adjust the rule to exclude these specific processes or users.
-- Security or forensic tools that perform regular system checks might mimic the behavior flagged by this rule. Confirm the legitimacy of these tools and, if necessary, whitelist them to prevent repeated alerts.
-- In development environments, testing of new system initialization scripts or processes might involve debugging the init process. Ensure that these activities are documented and authorized, and create exceptions for these environments to reduce noise.
-- If a known and trusted application requires debugging access to the init process for functionality, document this requirement and configure the rule to exclude this application's specific execution context.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Verify the legitimacy of the GDB process targeting PID 1 by checking user permissions and the context of execution.
-- Conduct a thorough investigation to identify any unauthorized access or data extraction attempts, focusing on logs and system changes.
-- Terminate any unauthorized GDB processes and any other suspicious processes identified during the investigation.
-- Review and analyze system logs, including authentication logs, to identify any other potential indicators of compromise or lateral movement.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Restore the system to a known good state using backups, ensuring that any compromised credentials are reset and access controls are reviewed.
-- Implement enhanced logging policies to capture detailed process execution and memory access events for future investigations.
-- Integrate security tools with SIEM solutions to improve detection capabilities and automate alerting for similar threats.
-- Apply system hardening measures, such as restricting debugging tools to authorized users only and implementing strict access controls on critical processes."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_gdb_process_hooking.toml b/rules/linux/credential_access_gdb_process_hooking.toml
index 2d18c8a602d..25ac63aca2f 100644
--- a/rules/linux/credential_access_gdb_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_process_hooking.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/30"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ secret extraction from privileged processes. Tools that display this behavior in
 "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux Process Hooking via GDB"
@@ -28,59 +30,18 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "gdb" and process.args in ("--pid", "-p") and 
 /* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
 process.args != "1"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Linux Process Hooking via GDB
-
-GDB, the GNU Debugger, is a powerful tool used for debugging applications on Linux systems. It allows users to inspect the memory and state of running processes. Adversaries can exploit GDB to dump memory from privileged processes, potentially extracting sensitive information like credentials. The detection rule identifies suspicious GDB usage by monitoring process initiation events with specific arguments, flagging potential unauthorized memory access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "gdb" and check if the process arguments include "--pid" or "-p", which indicate an attempt to attach to a running process.
-- Verify the user account associated with the gdb process initiation to determine if it is a privileged account or an account that should not typically use gdb.
-- Check the parent process of the gdb instance to understand how it was initiated and if it was spawned by a legitimate process or script.
-- Investigate the process ID (PID) specified in the gdb arguments to identify the target process and assess its sensitivity, such as whether it handles credentials or other sensitive data.
-- Use Osquery to gather additional context about the gdb process and its parent process. Example query: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'gdb';`
-- Examine system logs and audit logs around the time of the gdb process start event to identify any related suspicious activities or anomalies.
-- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized access to gdb or the target process.
-- Look for other instances of gdb usage on the system to determine if this is an isolated event or part of a broader pattern of behavior.
-- Analyze network activity from the host to detect any potential data exfiltration attempts following the gdb process execution.
-- Correlate this event with other security alerts or incidents to identify if it is part of a coordinated attack or a larger security incident.
-
-### False positive analysis
-
-- Developers and system administrators may use GDB for legitimate debugging purposes, which can trigger the rule. To manage this, users can create exceptions for specific user accounts or processes that are known to perform authorized debugging.
-- Automated testing environments might utilize GDB to test software under development. In such cases, users can exclude these environments by identifying and whitelisting the associated process IDs or hostnames.
-- Some monitoring or security tools may use GDB-like functionality to inspect processes for security assessments. Users should verify the legitimacy of these tools and exclude them from the rule if they are deemed safe.
-- In educational or research settings, GDB might be used for learning purposes. Users can handle these false positives by setting up exceptions for specific educational user groups or lab environments.
-- To ensure that exceptions do not introduce security risks, users should regularly review and update the list of exceptions, ensuring that only trusted entities are excluded from the rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Verify the legitimacy of the GDB process by checking the user who initiated it and the context in which it was executed.
-- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or unexpected network connections.
-- Review system logs and GDB usage history to determine the scope of the attack and identify any other potentially affected systems.
-- If unauthorized memory access is confirmed, change all credentials that may have been exposed, focusing on privileged accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to a known good state by reinstalling the operating system and applications, ensuring all security patches are applied.
-- Harden the system by disabling unnecessary debugging tools on production servers and enforcing strict access controls and monitoring for privileged operations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
index 136ef280e44..c53f414129c 100644
--- a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
+++ b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ sequence by host.id, process.parent.executable, user.id with maxspan=1s
    )
   ] with runs=10
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Linux Local Account Brute Force Detected
-
-In Linux environments, the 'su' command is used to switch user accounts, often requiring a password. Adversaries may exploit this by attempting numerous logins in quick succession, using either default or custom password lists, to gain unauthorized access. The detection rule identifies such brute force attempts by monitoring for multiple rapid 'su' executions from a single process, excluding common legitimate parent processes, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the `host.id`, `process.parent.executable`, and `user.id` involved in the potential brute force attempt to understand the scope and context of the activity.
-- Check the process execution history on the affected host to determine if there are any unusual patterns or anomalies associated with the `su` command, focusing on the `process.parent.executable` to identify any uncommon parent processes.
-- Investigate the user account (`user.id`) targeted by the brute force attempt to determine if it is a high-value account or if it has been involved in previous suspicious activities.
-- Examine the system logs, such as `/var/log/auth.log` or `/var/log/secure`, for additional context around the time of the alert to identify any other suspicious login attempts or related activities.
-- Use Osquery to gather more information about the processes running on the host. For example, execute the following query to list all processes with their parent processes: `SELECT pid, name, path, parent FROM processes WHERE name = 'su';`
-- Analyze network activity from the host to identify any unusual outbound or inbound connections that may correlate with the timing of the brute force attempts.
-- Check for any recent changes in user account configurations or permissions that could indicate unauthorized modifications or preparations for further attacks.
-- Review the system's security settings and configurations to ensure that they are aligned with best practices, particularly focusing on password policies and account lockout settings.
-- Correlate the alert with other security events or alerts from the same host or user account to identify potential patterns or coordinated attack attempts.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that match the tactics, techniques, and procedures (TTPs) observed in the alert, specifically focusing on the MITRE ATT&CK technique T1110 (Brute Force).
-
-### False positive analysis
-
-- Scheduled scripts or automated tasks that require frequent user switching might trigger false positives. These can be managed by identifying the specific scripts or tasks and adding their parent processes to the exclusion list.
-- System maintenance activities, such as updates or backups, often involve multiple 'su' commands in a short period. To handle these, ensure that maintenance scripts are run by known and trusted parent processes, which can then be excluded.
-- Development environments where developers frequently switch between user accounts for testing purposes may also cause false positives. In such cases, consider excluding the development tools or environments from the detection rule.
-- Continuous integration/continuous deployment (CI/CD) pipelines that use 'su' for various tasks might be flagged. To prevent this, identify the CI/CD tools and add them to the list of legitimate parent processes.
-- Custom administrative scripts that perform user account checks or management tasks could be mistaken for brute force attempts. Review these scripts and, if they are legitimate, add their parent processes to the exclusion list.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Review the logs to identify the source of the brute force attempts and determine if any accounts were compromised.
-- Reset passwords for any accounts that were targeted, ensuring they are strong and unique.
-- Conduct a thorough investigation to determine if the adversary gained access to sensitive data or systems.
-- Escalate the incident to the security team and, if necessary, involve legal or law enforcement agencies.
-- Implement additional logging and monitoring to detect similar activities in the future, such as enabling detailed audit logs for user authentication attempts.
-- Integrate threat intelligence feeds to enhance detection capabilities and stay informed about emerging threats.
-- Restore the system to its operational state by applying any necessary patches and updates, and verifying system integrity.
-- Harden the system by disabling unnecessary services, enforcing the principle of least privilege, and implementing multi-factor authentication.
-- Educate users on security best practices, including recognizing phishing attempts and the importance of using strong passwords."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
index 88dacaf4595..936f72da6b4 100644
--- a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -75,48 +75,6 @@ sequence by host.id, auditd.data.addr, related.user with maxspan=5s
    auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and
    auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Successful Linux FTP Brute Force Attack Detected
-
-FTP is a protocol used for transferring files between systems, often requiring authentication. Adversaries exploit this by attempting numerous username-password combinations to gain unauthorized access. The detection rule identifies a pattern of repeated failed login attempts from a single source, followed by a successful login, indicating a potential brute force attack.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id`, `auditd.data.addr`, and `related.user` involved in the potential brute force attack.
-- Check the logs for the specified `host.id` to gather more information about the failed and successful login attempts, focusing on the `auditd.data.terminal` field to confirm they were FTP-related.
-- Analyze the source IP address (`auditd.data.addr`) to determine if it is known for malicious activity or if it belongs to a legitimate user or partner.
-- Investigate the `related.user` account to verify if it has been compromised or if there are any unusual activities associated with it.
-- Use Osquery to gather additional context on the affected host. For example, run the following query to list recent login attempts: `SELECT * FROM last WHERE tty = 'ftp';`
-- Examine the time interval between the failed and successful login attempts to assess the likelihood of a brute force attack, considering the `maxspan=5s` parameter in the detection rule.
-- Cross-reference the `host.id` with other security alerts or logs to identify any correlated suspicious activities or patterns.
-- Check for any recent changes in the FTP server configuration or user account settings that might have facilitated the attack.
-- Review network traffic logs to identify any unusual data transfers or connections from the source IP address during or after the successful login.
-- Consult threat intelligence sources to determine if the attack pattern or source IP address matches any known threat actors or campaigns.
-
-### False positive analysis
-
-- Automated scripts or applications that frequently attempt to connect to an FTP server with incorrect credentials due to misconfigurations can trigger false positives. Users should identify and correct these configurations or whitelist the IP addresses of trusted scripts.
-- Legitimate users who frequently mistype their passwords or use password managers that incorrectly autofill credentials may cause false positives. Implementing user education on proper password management and verifying user behavior patterns can help mitigate this.
-- Security testing tools or vulnerability scanners that perform credential testing as part of their operations might be mistaken for brute force attacks. Users should ensure these tools are configured to exclude FTP services or whitelist their IP addresses in the detection rule.
-- Frequent legitimate access attempts from a single source, such as a shared corporate IP address, can be misinterpreted as a brute force attack. Users can adjust the detection rule to account for known safe IP ranges or implement additional context checks, such as user behavior analysis, to differentiate between legitimate and malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access and data exfiltration.
-- Review and analyze the logs of the FTP server and related systems to identify the source of the attack and any compromised accounts.
-- Reset passwords for all affected accounts and consider implementing multi-factor authentication (MFA) to enhance security.
-- Conduct a thorough investigation to determine if any data was accessed or exfiltrated and assess the extent of the compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement additional logging and monitoring to detect similar brute force attempts in the future, ensuring logs are retained for an adequate period.
-- Integrate threat intelligence feeds to enhance detection capabilities and correlate with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by applying patches, updating software, and ensuring all security configurations are correctly set.
-- Harden the FTP server by disabling anonymous access, limiting login attempts, and using secure protocols like SFTP or FTPS.
-- Conduct a post-incident review to identify gaps in the security posture and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
index 8c7698de40b..f4c9c353808 100644
--- a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -73,49 +73,6 @@ sequence by host.id, related.user with maxspan=5s
   [authentication where host.os.type == "linux" and event.action  == "authenticated" and
    auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Successful Linux RDP Brute Force Attack Detected
-
-Remote Desktop Protocol (RDP) allows users to connect to and control remote systems, often used for administrative tasks. Adversaries exploit RDP by attempting numerous login attempts to gain unauthorized access, potentially leading to data breaches or further network attacks. The detection rule identifies a pattern of multiple failed login attempts followed by a successful one, indicating a possible brute force attack, by monitoring authentication events on Linux systems.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `related.user` involved in the potential brute force attack.
-- Examine the authentication logs on the identified Linux host to verify the sequence of failed and successful login attempts, focusing on entries with `event.action` as "authenticated" and `auditd.data.terminal` containing "*rdp*".
-- Check the time interval between the failed and successful login attempts to confirm if they occurred within the `maxspan=5s` window, indicating a rapid succession of attempts.
-- Investigate the source IP addresses associated with the failed and successful login attempts to determine if they originate from suspicious or known malicious sources.
-- Use Osquery to gather additional context on the user account involved. For example, run the query: `SELECT * FROM users WHERE username = '<related.user>';` to check for anomalies in user account settings or recent changes.
-- Analyze the system's audit logs for any unusual activity or changes around the time of the successful login, such as new processes or network connections initiated by the compromised account.
-- Correlate the findings with other security events or alerts in the network to identify if this incident is part of a larger attack campaign.
-- Review historical login patterns for the `related.user` to determine if the login behavior is consistent with past activity or if it deviates significantly.
-- Check for any recent vulnerabilities or patches related to RDP on Linux systems that might have been exploited in this attack.
-- Document all findings and evidence collected during the investigation to support further analysis and potential escalation.
-
-### False positive analysis
-
-- Frequent legitimate administrative access: Regular administrative tasks may involve multiple failed login attempts due to mistyped credentials or password changes, followed by a successful login. Users can handle this by creating exceptions for known administrative accounts or IP addresses.
-- Automated scripts or tools: Some automated maintenance scripts or tools might attempt multiple logins in a short period, leading to false positives. Users should identify and whitelist these scripts or tools to prevent unnecessary alerts.
-- User error: Users may accidentally enter incorrect credentials multiple times before succeeding, especially if they are using complex passwords. Implementing user-specific exceptions or increasing the threshold for failed attempts can help reduce false positives.
-- Testing environments: In testing or development environments, frequent login attempts might be part of normal operations. Users can exclude these environments from monitoring or adjust the detection parameters to better fit the expected behavior.
-- Shared accounts: If multiple users share an account, failed login attempts may occur more frequently. Consider monitoring shared accounts separately and adjusting the detection criteria to account for this behavior.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Review authentication logs to confirm the brute force attack and identify the source IP address of the attacker.
-- Block the attacker's IP address at the network firewall to prevent further attempts.
-- Reset passwords for the compromised account and any other accounts that may have been targeted during the attack.
-- Conduct a thorough investigation to determine if any data was accessed or exfiltrated during the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement multi-factor authentication (MFA) for RDP access to enhance security and prevent future brute force attacks.
-- Review and update logging policies to ensure comprehensive monitoring of authentication events and potential security incidents.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to enhance detection capabilities.
-- Apply system hardening measures, such as disabling RDP if not needed, using strong password policies, and regularly updating and patching systems."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_proc_credential_dumping.toml b/rules/linux/credential_access_proc_credential_dumping.toml
index a4f2f87b74a..d6efb4506b7 100644
--- a/rules/linux/credential_access_proc_credential_dumping.toml
+++ b/rules/linux/credential_access_proc_credential_dumping.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/04/26"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +15,7 @@ known vulnerability CVE-2018-20781. Malicious actors can exploit the cleartext c
 process and extracting lines that have a high probability of containing cleartext passwords.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Credential Dumping via Proc Filesystem"
@@ -56,60 +58,18 @@ tags = [
     "Tactic: Credential Access",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 type = "eql"
 
 query = '''
 sequence by host.id, process.parent.name with maxspan=1m
-  [process where host.os.type == "linux" and process.name == "ps" and event.action == "exec"
+  [process where host.os.type == "linux" and process.name == "ps" and event.action in ("exec", "start", "exec_event")
    and process.args in ("-eo", "pid", "command")]
-  [process where host.os.type == "linux" and process.name == "strings" and event.action == "exec"
+  [process where host.os.type == "linux" and process.name == "strings" and event.action in ("exec", "start", "exec_event")
    and process.args : "/tmp/*"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Linux Credential Dumping via Proc Filesystem
-
-The /proc filesystem in Linux provides a mechanism to access process information, which is crucial for system diagnostics. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences of commands, like 'ps' and 'strings', executed in a short span, indicating potential credential dumping activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and process.parent.name involved in the suspicious activity.
-- Verify the execution of the 'ps' command by checking the process.args field for the presence of "-eo", "pid", "command" to ensure it matches the alert criteria.
-- Examine the execution of the 'strings' command by confirming the process.args field includes paths like "/tmp/*", which may indicate temporary storage of dumped credentials.
-- Use Osquery to list all processes running on the affected host to identify any unusual or unauthorized processes. Example query: `SELECT pid, name, path FROM processes WHERE name IN ('ps', 'strings');`
-- Investigate the parent process of the suspicious 'ps' and 'strings' commands to determine if they were spawned by a legitimate or malicious process.
-- Check the process execution timeline to see if the 'ps' and 'strings' commands were executed within a short span (maxspan=1m) to confirm the sequence of events.
-- Analyze the command history on the affected host to identify any manual execution of similar commands that could indicate an insider threat or misconfiguration.
-- Review system logs for any additional context around the time of the alert, focusing on authentication logs and any anomalies in user activity.
-- Investigate any files in the /tmp directory that may have been created or modified around the time of the alert to identify potential credential dumps.
-- Correlate the findings with other security tools and logs to determine if there are any related alerts or indicators of compromise on the same host or network.
-
-### False positive analysis
-
-- System administrators or automated scripts may frequently use the 'ps' and 'strings' commands for legitimate monitoring and diagnostic purposes, leading to false positives. 
-- Security tools or monitoring solutions might execute similar command sequences as part of their regular operations, which could be mistaken for malicious activity.
-- Developers and testers might use these commands during software development or testing phases, especially when debugging or analyzing application behavior.
-- To manage these false positives, users can create exceptions for known benign processes or scripts by whitelisting specific process names or paths that are regularly used in their environment.
-- Implementing a baseline of normal system behavior can help differentiate between legitimate and suspicious activities, allowing for more accurate detection and fewer false positives.
-- Regularly updating and reviewing the list of exceptions is crucial to ensure that new legitimate processes are not flagged as threats while maintaining security against actual credential dumping attempts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further credential exposure and lateral movement.
-- Conduct a thorough investigation to confirm the presence of mimipenguin or similar tools by reviewing process execution logs and file system changes.
-- Terminate any suspicious processes identified during the investigation, particularly those related to 'ps' and 'strings' commands executed in sequence.
-- Change all passwords for accounts that were logged in on the affected system to prevent unauthorized access using potentially compromised credentials.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system from a known good backup to ensure no residual malicious artifacts remain.
-- Apply security patches and updates to address vulnerabilities like CVE-2018-20781 and ensure all systems are up to date.
-- Conduct a security awareness training session for users to recognize and report suspicious activities, emphasizing the importance of credential security."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_ssh_backdoor_log.toml b/rules/linux/credential_access_ssh_backdoor_log.toml
index 98a4923ae3a..bbd78ee7232 100644
--- a/rules/linux/credential_access_ssh_backdoor_log.toml
+++ b/rules/linux/credential_access_ssh_backdoor_log.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -111,50 +111,6 @@ file where host.os.type == "linux" and event.type == "change" and process.execut
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential OpenSSH Backdoor Logging Activity
-
-OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to create backdoors, allowing unauthorized access or logging credentials. The detection rule identifies suspicious file changes by monitoring SSH processes and unusual file activities, such as writing to atypical directories or using uncommon file extensions, which may indicate backdoor logging attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file change event, including the file name, file path, and process executable involved, to understand the context of the suspicious activity.
-- Verify the legitimacy of the process executable by checking the hash of the binary at the path "/usr/sbin/sshd" or "/usr/bin/ssh" against known good hashes to detect any unauthorized modifications.
-- Examine the file name and extension involved in the alert to determine if it matches any known patterns of backdoor logging files, such as unusual extensions like "in", "out", "ini", or temporary file patterns like "*~".
-- Investigate the file path to determine if it matches any of the suspicious directories listed in the query, such as "/private/etc/ssh/.sshd_auth" or "/usr/lib/*.so.*", which may indicate unauthorized file placement.
-- Use Osquery to list all files in the suspicious directories identified in the alert to check for other potentially malicious files. Example query: `SELECT * FROM file WHERE directory IN ('/private/etc', '/usr/lib') AND (name LIKE '%.so%' OR name LIKE '%~%');`
-- Check the system logs for any recent SSH login attempts or connections around the time of the file change event to identify any unauthorized access attempts.
-- Analyze the process tree and parent-child relationships of the SSH process involved in the alert to identify any unusual or unexpected process behavior.
-- Review the system's user accounts and SSH configuration files to ensure no unauthorized changes have been made that could facilitate backdoor access.
-- Investigate any network connections made by the SSH process to external IP addresses to identify potential data exfiltration or command-and-control activity.
-- Correlate the alert with other security events or alerts from the same host or network segment to identify any patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Routine administrative tasks or legitimate software updates may trigger file changes in monitored directories or with uncommon file extensions, leading to false positives. 
-- System maintenance scripts or automated processes that modify files in directories like `/usr/share/` or `/usr/local/share/` could be misinterpreted as suspicious activity.
-- Temporary files created by text editors or development tools, such as those with extensions like `.so` or `.sock`, might be flagged incorrectly.
-- Users can manage these false positives by creating exceptions for known benign processes or file paths that frequently trigger alerts, ensuring that legitimate activities are not continuously flagged.
-- Implementing a whitelist for specific file names or extensions that are known to be safe in the context of your environment can help reduce unnecessary alerts.
-- Regularly review and update the exclusion list to adapt to changes in legitimate system behavior, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify any unauthorized changes to SSH binaries or configuration files, focusing on the paths and file types specified in the detection rule.
-- Review system logs and SSH logs for any unusual login attempts or file access patterns that could indicate backdoor activity.
-- Revert any unauthorized changes to SSH binaries and configuration files by restoring them from a known good backup.
-- Change all SSH-related credentials and keys that may have been compromised, and ensure that new keys are distributed securely.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed SSH activity, including command execution and file access, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of similar threats in the future.
-- Apply security patches and updates to the SSH service and related components to mitigate known vulnerabilities.
-- Harden the SSH configuration by disabling unused authentication methods, enforcing strong password policies, and using multi-factor authentication (MFA) where possible."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
index bdc755eedaa..f333f48428b 100644
--- a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
+++ b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -62,52 +62,6 @@ sequence by host.id,  process.parent.entity_id with maxspan=1s
   and event.action == "connection_attempted"
   and destination.ip == "169.254.169.254"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Instance Metadata Service (IMDS) API Request
-
-The Instance Metadata Service (IMDS) API provides essential instance-specific data, including credentials, to applications running on cloud instances. Adversaries exploit this by using scripts or tools to access sensitive data, potentially leading to unauthorized access. The detection rule identifies suspicious access attempts by monitoring specific processes and network connections to the IMDS endpoint, filtering out known legitimate activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and command line that triggered the alert, focusing on the `process.name`, `process.executable`, and `process.command_line` fields.
-- Check the `process.parent.entity_id` to understand the parent process and its relationship to the suspicious process, which might provide context on how the process was initiated.
-- Investigate the `process.working_directory` to determine if the process was executed from a suspicious or unusual directory, which could indicate malicious activity.
-- Examine the `network` event details, particularly the `destination.ip`, to confirm if there was an attempted connection to the IMDS endpoint at `169.254.169.254`.
-- Use Osquery to gather more information about the suspicious process. For example, run the following query to list all processes with network connections to the IMDS endpoint:
-  ```sql
-  SELECT pid, name, path, cmdline, cwd FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = '169.254.169.254');
-  ```
-- Cross-reference the `host.id` with other security logs to identify any other suspicious activities or alerts associated with the same host.
-- Investigate the `event.type` and `event.action` fields to confirm the nature of the process execution and network connection attempt, ensuring they align with the alert's context.
-- Review historical data for the same `host.id` to identify any patterns or repeated attempts to access the IMDS API, which could indicate persistent malicious activity.
-- Check for any legitimate software or scripts that might have been recently installed or updated on the host, which could explain the alert as a false positive.
-- Collaborate with the cloud infrastructure team to verify if there are any known legitimate processes or maintenance activities that could have triggered the alert, ensuring alignment with operational changes.
-
-### False positive analysis
-
-- Security and monitoring tools such as Rapid7, Nessus, and Amazon SSM Agent may trigger false positives due to their legitimate access to the IMDS API for vulnerability assessments and system management. Users can handle these by adding exceptions for processes running from directories like `/opt/rapid7*`, `/opt/nessus*`, and `/snap/amazon-ssm-agent*`.
-- Automated scripts or services that require instance metadata for configuration or management purposes might also be flagged. These can be excluded by specifying known safe process executables or parent executables, such as `/opt/rumble/bin/rumble-agent*` or `/usr/bin/setup-policy-routes`.
-- Cloud-native services like EC2 Instance Connect, which use the IMDS API for legitimate operations, may appear suspicious. Users should consider excluding processes with parent executables located in `/usr/share/ec2-instance-connect/*`.
-- Regular system updates or maintenance scripts that temporarily access the IMDS API could be misidentified as threats. To manage these, users can create exceptions for processes with specific working directories or command lines that are known to be safe.
-- Network monitoring tools that check connectivity to the IMDS endpoint for health checks might be mistakenly flagged. Users should ensure that these tools are recognized and excluded by specifying their network activity as non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected instance from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and method of the unauthorized IMDS API access attempt, focusing on the processes and network connections flagged by the detection rule.
-- Review and analyze logs from the affected instance and any associated cloud services to gather more context on the incident, including timestamps, IP addresses, and user accounts involved.
-- Revoke any temporary security credentials that may have been accessed and rotate all potentially compromised credentials, including API keys and passwords.
-- Escalate the incident to the security operations team and, if necessary, involve cloud service provider support for further assistance and investigation.
-- Implement enhanced logging and monitoring for IMDS API access attempts, ensuring that all access is logged and alerts are configured for suspicious activities.
-- Deploy additional security controls such as network segmentation and firewall rules to restrict access to the IMDS endpoint to only trusted processes and users.
-- Restore the affected instance to its operational state by applying security patches, updating configurations, and verifying the integrity of system files and applications.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train staff on the risks associated with IMDS API access and the importance of adhering to security best practices, leveraging MITRE ATT&CK framework details for threat context."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
index 5d9e2b91a54..14a99c7acf8 100644
--- a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
+++ b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/08/23"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -10,7 +12,7 @@ description = """
 This rule detects Linux Access Control List (ACL) modification via the setfacl command.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Access Control List Modification via setfacl"
@@ -26,59 +28,19 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-event.action in ("exec", "exec_event", "executed", "process_started") and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 process.name == "setfacl" and not (
   process.command_line == "/bin/setfacl --restore=-" or
   process.args == "/var/log/journal/"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Access Control List Modification via setfacl
-
-Access Control Lists (ACLs) in Linux enhance file permissions by allowing more granular control over who can access or modify files. The `setfacl` command is used to set these permissions. Adversaries may exploit `setfacl` to stealthily alter permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential unauthorized ACL modifications.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `setfacl` command execution, focusing on the `process.name` and `event.type` fields to ensure the event is a process start.
-- Examine the `process.command_line` field to understand the exact command executed and identify any unusual or suspicious arguments that deviate from typical usage patterns.
-- Check the `process.args` field to determine the specific files or directories targeted by the `setfacl` command, paying attention to any sensitive or critical system files.
-- Investigate the user account associated with the `setfacl` execution to determine if the action aligns with their typical behavior or role within the organization.
-- Correlate the event with other recent activities from the same user or process to identify any patterns or sequences that suggest malicious intent.
-- Use Osquery to gather additional context on the file or directory affected by the ACL modification. For example, run the following query to list current ACLs for a specific file: `SELECT * FROM file WHERE path = '/path/to/suspicious/file';`
-- Review system logs around the time of the `setfacl` execution to identify any related events or anomalies that could provide further context or indicate a broader attack.
-- Investigate the parent process of the `setfacl` execution to determine if it was initiated by a legitimate application or script, or if it was potentially spawned by malicious software.
-- Assess the system for any signs of compromise or unauthorized access that could explain the unexpected ACL modification, such as unusual network connections or new user accounts.
-- Consult with the system owner or relevant personnel to verify if the `setfacl` execution was authorized and necessary, and gather any additional context that could aid in the investigation.
-
-### False positive analysis
-
-- Routine administrative tasks often involve the use of `setfacl` to manage file permissions, which can trigger false positives. System administrators frequently use `setfacl` to configure permissions for shared directories or to restore permissions from backups.
-- Automated scripts or configuration management tools like Ansible, Puppet, or Chef may execute `setfacl` as part of their normal operations, leading to benign alerts.
-- To manage these false positives, users can create exceptions for specific command-line patterns or arguments that are known to be safe, such as excluding processes with command lines that match regular maintenance tasks.
-- Users should regularly review and update the exclusion list to ensure it reflects current operational practices, minimizing the risk of overlooking genuine threats while reducing noise from legitimate activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the scope of the ACL modifications, including which files or directories were affected and the specific changes made.
-- Review system logs and security alerts to determine if the `setfacl` command was executed by a legitimate user or if credentials may have been compromised.
-- Revert unauthorized ACL changes by restoring permissions to their original state using backups or predefined security baselines.
-- Escalate the incident to the security operations center (SOC) or incident response team if unauthorized access or potential compromise is confirmed.
-- Implement enhanced logging for ACL changes and `setfacl` command executions to improve detection of future unauthorized modifications.
-- Integrate with a security information and event management (SIEM) system to correlate ACL modification events with other suspicious activities.
-- Educate users on the importance of secure credential management and the risks associated with unauthorized permission changes.
-- Apply system hardening measures, such as restricting the use of `setfacl` to authorized administrators only and using role-based access controls.
-- Regularly review and update access control policies to ensure they align with the principle of least privilege and are resilient against evasion techniques."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
index 553054753f4..581929efea0 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/08/28"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ provides system auditing and logging. Disabling the Auditd service can prevent t
 security events, which can be used to detect malicious activity.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*"]
+index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Disable Auditd Service"
@@ -51,61 +53,19 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and (
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
   (process.name == "service" and process.args == "stop") or
   (process.name == "chkconfig" and process.args == "off") or
   (process.name == "systemctl" and process.args in ("disable", "stop", "kill"))
 ) and
 process.args in ("auditd", "auditd.service")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Disable Auditd Service
-
-Auditd is a crucial Linux service for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by stopping or disabling it, thus impairing the system's ability to log malicious activities. The detection rule identifies such attempts by monitoring processes that execute commands to stop or disable Auditd, flagging potential defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
-- Check the user context under which the suspicious command was executed to determine if it was run by an unauthorized or unexpected user.
-- Investigate the parent process of the flagged process to understand how the command was initiated, using the `process.parent.name` and `process.parent.args` fields.
-- Examine the command execution history for the user involved to identify any other suspicious activities or patterns.
-- Use Osquery to list all recent changes to system services, including Auditd, with a query like: `SELECT * FROM osquery_schedule WHERE name = 'auditd';`
-- Review system logs around the time of the alert for any other suspicious activities or anomalies that might correlate with the attempt to disable Auditd.
-- Check for any recent modifications to the Auditd configuration files to ensure they have not been tampered with.
-- Investigate network connections from the host to identify any unusual outbound connections that might indicate data exfiltration or command-and-control activity.
-- Look for any other alerts or indicators of compromise on the same host that might suggest a broader attack campaign.
-- Verify the integrity of the Auditd service by checking its current status and configuration to ensure it is running as expected.
-
-### False positive analysis
-
-- Routine system maintenance or administrative tasks may trigger this rule if administrators legitimately stop or disable the Auditd service for updates or configuration changes. 
-- Automated scripts or configuration management tools like Ansible, Puppet, or Chef might execute commands that match the rule criteria during system provisioning or updates.
-- Testing environments where services are frequently started and stopped for development purposes can also lead to false positives.
-- To manage these false positives, users can create exceptions for known maintenance windows or specific administrative accounts that regularly perform these actions.
-- Implementing a whitelist of trusted scripts or tools that are known to perform legitimate service management can help reduce noise.
-- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Investigate the alert by reviewing the process execution logs to identify the user and source of the command attempting to disable Auditd.
-- Check for any unauthorized changes to system configurations or additional suspicious activities that may have occurred around the time of the alert.
-- Restore the Auditd service to its operational state by restarting it and ensuring it is enabled to start on boot.
-- Review and update access controls to ensure only authorized personnel can modify or stop critical services like Auditd.
-- Escalate the incident to the security operations team for further analysis and to determine if this is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed audit logs and ensure they are securely stored and monitored for anomalies.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and applying security patches, to reduce the attack surface and prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
index 228b7d7d268..3d423f932de 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/02/22"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ Adversaries may attempt to disable the iptables or firewall service in an attemp
 receive or send network traffic.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Disable IPTables or Firewall"
@@ -51,12 +53,13 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
   (
    /* disable FW */
    (
@@ -74,48 +77,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Disable IPTables or Firewall
-
-Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these defenses to facilitate malicious activities, such as data exfiltration or lateral movement. The detection rule identifies suspicious processes that aim to disable or stop firewall services, signaling potential defense evasion attempts by monitoring specific command executions and arguments.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on fields like `process.name` and `process.args`.
-- Check the `event.type` and `event.action` fields to confirm the nature of the process execution and ensure it aligns with the suspicious activity described in the rule.
-- Investigate the parent process using `process.parent.args` to understand the context in which the suspicious process was executed, which might reveal if it was part of a larger script or command sequence.
-- Examine the user account associated with the process execution to determine if it was initiated by a legitimate user or potentially compromised account.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <suspicious_pid>);`
-- Check system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication events or anomalies around the time of the alert to identify potential unauthorized access.
-- Investigate any recent changes to firewall configurations by reviewing the history of commands executed by the user, which can be found in shell history files like `.bash_history`.
-- Correlate the alert with other security events or alerts from the same host to identify if this is part of a broader attack pattern, such as lateral movement or privilege escalation attempts.
-- Analyze network traffic logs to detect any unusual outbound connections or data exfiltration attempts that might have occurred after the firewall was disabled.
-- Review any recent system updates or patches applied to the host to rule out the possibility of legitimate maintenance activities that might have triggered the alert.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may frequently execute commands to disable or stop firewall services during maintenance or troubleshooting. These actions, while legitimate, can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific maintenance windows.
-- Automated scripts: Some automated scripts or configuration management tools may include commands to disable or modify firewall settings as part of their normal operation. Users should review these scripts and, if deemed non-threatening, exclude them from triggering alerts by specifying the script names or paths in the exception list.
-- Testing environments: In testing or development environments, firewall services might be intentionally disabled to facilitate testing. Users can handle these false positives by excluding specific hosts or environments from the detection rule.
-- Legacy systems: Older systems might use different methods or commands to manage firewall settings, which could be flagged by the rule. Users should identify these systems and adjust the detection criteria or add exceptions accordingly.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities on the host, focusing on recent process executions and network connections.
-- Review system logs and security alerts to determine the scope of the incident and identify any other potentially compromised systems.
-- Restore the firewall settings to their original state using backup configurations or by manually re-enabling the firewall services.
-- Apply patches and updates to the operating system and firewall software to address any known vulnerabilities.
-- Implement enhanced logging policies to capture detailed information on process executions and network activities, ensuring that logs are stored securely and monitored regularly.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection and response capabilities.
-- Conduct a post-incident review to analyze the attack vector and update security policies and procedures to prevent similar incidents in the future.
-- Educate and train staff on recognizing and responding to potential security threats, emphasizing the importance of maintaining firewall integrity.
-- Consider implementing additional hardening measures, such as disabling unnecessary services, enforcing strong access controls, and using multi-factor authentication to enhance system security."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
index f768b84ba2e..11b15107458 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2020/04/27"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ Adversaries may attempt to disable the syslog service in an attempt to an attemp
 detection by security controls.
 """
 from = "now-9m"
-index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*"]
+index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Disable Syslog Service"
@@ -63,59 +65,19 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
  ( (process.name == "service" and process.args == "stop") or
    (process.name == "chkconfig" and process.args == "off") or
    (process.name == "systemctl" and process.args in ("disable", "stop", "kill"))
- ) and process.args in ("syslog", "rsyslog", "syslog-ng")
+ ) and process.args in ("syslog", "rsyslog", "syslog-ng", "syslog.service", "rsyslog.service", "syslog-ng.service")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Disable Syslog Service
-
-Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disrupt logging, thereby evading detection by security systems. They might use commands like `service stop`, `chkconfig off`, or `systemctl disable` to halt syslog services. The detection rule identifies such attempts by monitoring process executions that match these patterns, ensuring any disruption attempts are flagged for investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields to ensure they match the suspicious patterns.
-- Check the `event.action` field to verify if the action was an execution event, which is critical for confirming the attempt to disable the syslog service.
-- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised, using the `user.name` field.
-- Examine the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is specifically designed for Linux environments.
-- Use Osquery to gather additional context about the process execution. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
-- Analyze the process tree to understand the parent process and any child processes spawned by the suspicious process, which can provide insights into how the command was executed.
-- Review system logs around the time of the alert to identify any other suspicious activities or anomalies that might correlate with the attempt to disable syslog.
-- Check for any recent changes to system configurations or services that might indicate tampering or preparation for disabling syslog.
-- Investigate network connections from the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
-- Correlate the alert with other security events or alerts from the same host or user to identify patterns or repeated attempts to disable logging services.
-
-### False positive analysis
-
-- Routine maintenance activities by system administrators may trigger this rule when they intentionally stop or disable syslog services for updates or configuration changes. To manage this, users can create exceptions for known maintenance windows or specific administrator accounts.
-- Automated scripts or configuration management tools that manage service states might also cause false positives if they include commands to stop or disable syslog services as part of their operations. Users should review these scripts and, if deemed non-threatening, exclude them from triggering the rule by specifying the script names or paths.
-- Testing environments where syslog services are intentionally stopped for testing purposes can also lead to false positives. Users can handle this by excluding specific test environment hosts or IP addresses from the rule.
-- Some legitimate software installations or updates might require stopping syslog services temporarily, which could be flagged by this rule. Users should identify such software and create exceptions based on the software's process names or installation paths.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
-- Investigate the process execution logs to confirm the attempt to disable the syslog service and identify any associated processes or users involved.
-- Review user access logs to determine if unauthorized access was gained and identify any compromised accounts.
-- Re-enable the syslog service using the appropriate command for your system (e.g., `systemctl enable syslog` and `systemctl start syslog`) to restore logging functionality.
-- Conduct a thorough review of system logs to identify any other suspicious activities or anomalies that occurred around the time of the syslog service disruption attempt.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attempt is part of a larger attack campaign.
-- Implement stricter access controls and monitoring on critical services like syslog to prevent unauthorized modifications, including using role-based access controls and multi-factor authentication.
-- Enhance logging policies by ensuring that all critical system events are logged and that logs are securely stored and regularly reviewed for signs of tampering or suspicious activity.
-- Integrate additional security tools and threat intelligence feeds to improve detection capabilities and provide context for future investigations, such as endpoint detection and response (EDR) solutions.
-- Apply system hardening measures by regularly updating and patching software, disabling unnecessary services, and configuring security settings according to best practices to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
index 82d6f1c8927..aa3acf071d1 100644
--- a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
+++ b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2020/04/17"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +16,7 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Base16 or Base32 Encoding/Decoding Activity"
@@ -66,57 +68,18 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name in ("base16", "base32", "base32plain", "base32hex") and
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name in ("base16", "base32", "base32plain", "base32hex") and
 not process.args in ("--help", "--version")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Base16 or Base32 Encoding/Decoding Activity
-
-Base16 and Base32 are encoding schemes that convert binary data into text, making it easier to transmit over text-based protocols. Adversaries exploit these encodings to obfuscate data, evading detection by security systems. The detection rule identifies suspicious encoding activities by monitoring specific processes on Linux systems, excluding benign actions like help or version checks, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name involved is one of the specified encoding tools: "base16", "base32", "base32plain", or "base32hex".
-- Examine the process arguments to ensure they do not include benign actions like "--help" or "--version", which are excluded in the detection rule.
-- Check the user account associated with the process to determine if it is a known and trusted user or if it might be compromised.
-- Investigate the parent process of the encoding activity to understand the context in which the encoding tool was executed.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('base16', 'base32', 'base32plain', 'base32hex');`
-- Analyze recent command history for the user associated with the process to identify any suspicious commands or patterns leading up to the encoding activity.
-- Review system logs for any related events or anomalies around the time the encoding process was executed, such as unusual login attempts or file access patterns.
-- Check for any network connections initiated by the process to determine if data might be exfiltrated or communicated to an external host.
-- Investigate any file modifications or creations by the process to identify if encoded data was written to disk or if there are any suspicious files.
-- Correlate the encoding activity with other security alerts or indicators of compromise to assess if it is part of a larger attack campaign or isolated incident.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use Base16 or Base32 encoding/decoding for legitimate purposes such as data integrity checks or configuration management. These activities can be mistaken for malicious behavior.
-- Automated scripts: Some automated scripts or applications may use Base16 or Base32 encoding as part of their normal operation, leading to false positives if these processes are not excluded.
-- Development and testing: Developers might use encoding/decoding tools during software development or testing phases, which can trigger alerts if not properly accounted for.
-- To manage false positives, users can create exceptions for known benign processes by adding specific process names or arguments to an exclusion list. This can be done by updating the detection rule to ignore certain command-line arguments or by whitelisting processes that are verified as non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration or lateral movement by the adversary.
-- Conduct a thorough investigation of the process execution logs to identify the source and scope of the encoding/decoding activity.
-- Analyze the command-line arguments and any associated scripts or files to determine if sensitive data was encoded or if malicious payloads were delivered.
-- Review user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar encoding/decoding activities.
-- Restore the system to its operational state by removing any malicious files, applying security patches, and verifying the integrity of critical system files.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface and prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
index 57b9ecdaca4..b2a6a079cf5 100644
--- a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
+++ b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -95,49 +95,6 @@ file.Ext.original.path : (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 System Binary Moved or Copied
-
-System binaries are essential executables in Linux environments, responsible for core system functions. Adversaries may exploit these by moving or copying them to evade detection, often renaming them to mask malicious activities. The detection rule identifies unusual movements of these binaries, excluding legitimate processes and paths, to flag potential threats. This helps in identifying masquerading attempts, aligning with defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific system binary that was moved or copied, focusing on the `file.Ext.original.path` and `event.action` fields.
-- Check the `process.name` and `process.executable` fields to determine which process initiated the action and assess if it is a known legitimate process or potentially malicious.
-- Investigate the `host.os.type` to confirm the operating system environment and ensure the alert pertains to a Linux system.
-- Examine the `event.type` field to verify that the event is indeed a "change" event, indicating a modification to the file system.
-- Use Osquery to gather additional context about the process that triggered the alert. For example, run the following query to get more details about the process: `SELECT * FROM processes WHERE name = '<process.name from alert>';`
-- Check the system logs for any related entries around the time of the alert to identify any other suspicious activities or anomalies.
-- Investigate the user account associated with the process by checking the `process.user` field, if available, to determine if the action was performed by a legitimate user.
-- Look for any recent changes in the system's package management logs (e.g., dpkg, rpm) that might explain the movement or copying of the binary.
-- Assess the file's new location and permissions to determine if it aligns with typical system configurations or if it appears suspicious.
-- Cross-reference the alert with any other recent alerts or incidents involving the same host or process to identify potential patterns or ongoing threats.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate system updates or package management activities, where system binaries are moved or copied as part of routine operations. These include processes like `dpkg`, `rpm`, `yum`, `apt`, and `snapd`, which are commonly used for installing or updating software packages.
-- System maintenance tasks performed by administrators or automated scripts might also trigger this rule. For example, using `ln` to create symbolic links or `sed` for in-place file editing can result in file movements that are benign.
-- Development and testing environments often involve frequent changes to system binaries, especially when using tools like `pip`, `node`, or `platform-python` for package management and script execution.
-- To manage these false positives, users can create exceptions for known benign processes and paths by adding them to the exclusion list in the detection rule. This involves specifying trusted process names, executables, or file paths that are known to perform legitimate operations.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the binary movement, examining logs and system changes.
-- Verify the integrity of the moved or copied binaries by comparing them with known good versions or using a trusted source.
-- Remove or quarantine any unauthorized or suspicious binaries and restore legitimate versions from backups or trusted repositories.
-- Escalate the incident to the security operations team if the activity is confirmed as malicious, providing detailed findings and context.
-- Implement enhanced logging policies to capture detailed file and process activity, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Review and update access controls and permissions to limit the ability of unauthorized users to move or copy system binaries.
-- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly.
-- Apply system hardening measures, such as enabling file integrity monitoring and restricting execution of binaries from non-standard directories, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_chattr_immutable_file.toml b/rules/linux/defense_evasion_chattr_immutable_file.toml
index 1757e477670..6d5ba1837fd 100644
--- a/rules/linux/defense_evasion_chattr_immutable_file.toml
+++ b/rules/linux/defense_evasion_chattr_immutable_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -84,49 +84,6 @@ process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and n
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File made Immutable by Chattr
-
-The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, excluding known legitimate parent processes, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file that was made immutable and the exact time the `chattr` command was executed.
-- Examine the `process.parent.executable` and `process.parent.name` fields to determine the parent process that initiated the `chattr` command, ensuring it is not a known legitimate process.
-- Use Osquery to list all immutable files on the system to identify any other files that may have been altered. Example query: `SELECT path FROM file WHERE attributes LIKE '%i%';`
-- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
-- Check the system logs around the time of the alert for any other suspicious activities or related events that might provide additional context.
-- Analyze the command-line arguments (`process.args`) used with `chattr` to understand the specific changes made to the file attributes.
-- Review recent changes to critical system files (e.g., `.ssh`, `/etc/passwd`) to identify any unauthorized modifications.
-- Correlate the alert with other security events or alerts from the same host to identify potential patterns or related incidents.
-- Investigate the network activity of the host around the time of the alert to detect any suspicious outbound or inbound connections.
-- Consult threat intelligence sources to determine if the file or process involved in the alert is associated with known malicious activity or threat actors.
-
-### False positive analysis
-
-- System maintenance scripts or administrative tasks may use `chattr` to protect critical system files, leading to false positives. Users can handle these by identifying and excluding specific scripts or processes that are known to perform legitimate file attribute changes.
-- Backup or security software might use `chattr` to safeguard files during operations, which could trigger the rule. Users should review and whitelist these applications if they are verified as non-threatening.
-- Automated configuration management tools like Ansible or Puppet may employ `chattr` to enforce file states, resulting in false positives. Users can exclude these tools by adding their process names or paths to the exception list.
-- Some system updates or package installations might temporarily use `chattr` to lock files, causing false alerts. Users should monitor update processes and exclude them if they are confirmed to be safe.
-- To manage false positives, users can refine the detection rule by adding specific parent process names or executable paths to the exclusion criteria, ensuring that only suspicious or unknown uses of `chattr` are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Investigate the process tree to identify the parent process of the `chattr` command and determine if it is associated with known malicious activity.
-- Review recent file changes and access logs to identify any unauthorized modifications to critical system files such as `.ssh` or `/etc/passwd`.
-- Remove the immutable attribute from any files identified as malicious or suspicious using `chattr -i` and conduct a thorough malware scan on these files.
-- Restore any altered system files from a known good backup to ensure system integrity and functionality.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and file modification events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Apply system hardening measures, such as restricting the use of `chattr` to authorized users only and regularly auditing file permissions and attributes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
index 0c8749b81d0..92f07b4a59a 100644
--- a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
+++ b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/10/24"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ Monitors for the deletion of the kernel ring buffer events through dmesg. Attack
 to evade detection after installing a Linux kernel module (LKM).
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Clear Kernel Ring Buffer"
@@ -51,58 +53,16 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "dmesg" and process.args == "-c"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Clear Kernel Ring Buffer
-
-The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may exploit the `dmesg -c` command to clear these logs, concealing traces of malicious activities like installing unauthorized kernel modules. The detection rule identifies this by monitoring the execution of `dmesg` with specific arguments, flagging potential attempts to erase evidence from the kernel ring buffer.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `dmesg -c` command execution, focusing on the `process.name` and `process.args` fields to ensure the command was executed with the `-c` argument.
-- Check the `event.type` and `event.action` fields to verify that the process was indeed started and executed, confirming the legitimacy of the alert.
-- Investigate the user account associated with the `dmesg` command execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.
-- Examine the process tree to identify any parent processes that may have initiated the `dmesg` command, which could provide context on how the command was executed.
-- Utilize Osquery to gather additional context on the system state at the time of the alert. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
-- Analyze system logs around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the execution of the `dmesg -c` command.
-- Check for any recent changes to kernel modules or system configurations that could indicate an attempt to install unauthorized software.
-- Investigate network activity from the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
-- Review historical alerts and logs for similar `dmesg -c` executions to determine if this is part of a recurring pattern or a one-time event.
-- Correlate the findings with threat intelligence sources to assess if the activity matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or campaigns.
-
-### False positive analysis
-
-- System administrators or automated scripts may use the `dmesg -c` command as part of routine maintenance or troubleshooting, leading to false positives. 
-- Regularly scheduled tasks or cron jobs that clear the kernel ring buffer for log management purposes can trigger the detection rule.
-- Developers or IT personnel might execute `dmesg -c` during testing or debugging processes, which are non-malicious activities.
-- To manage these false positives, users can create exceptions for specific users or processes known to perform legitimate `dmesg -c` operations.
-- Implementing a whitelist for trusted scripts or administrative accounts that frequently use `dmesg -c` can help reduce unnecessary alerts.
-- Monitoring the context of the `dmesg -c` execution, such as the user account and associated processes, can aid in distinguishing between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to determine the scope of the incident, focusing on identifying any unauthorized kernel modules or other suspicious activities.
-- Review system logs and other security telemetry to identify any additional indicators of compromise or related malicious activities.
-- Remove any unauthorized kernel modules and restore the kernel to its original state using trusted sources or backups.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to ensure comprehensive monitoring of kernel activities and system changes, including the use of tools like auditd for detailed process tracking.
-- Integrate security solutions such as endpoint detection and response (EDR) tools to improve visibility and detection capabilities for similar threats in the future.
-- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities that could be exploited by attackers.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining system integrity and security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
index abbdaa5efd9..ca6700c78de 100644
--- a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
+++ b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -36,49 +36,6 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Hidden Files and Directories via Hidden Flag
-
-In Linux environments, the 'chflags' command can set file attributes, including the 'hidden' flag, to conceal files from standard directory listings. Adversaries exploit this to obscure malicious files, evading detection. The detection rule monitors file creation events where 'chflags' is used, identifying potential misuse by correlating these actions with known evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file creation event, focusing on the 'host.os.type', 'event.type', and 'process.name' fields to confirm the use of 'chflags' on a Linux system.
-- Examine the file path and name associated with the alert to determine if it matches known malicious patterns or locations commonly used for hiding files.
-- Check the user account associated with the 'chflags' process to assess if the activity aligns with expected behavior for that user or if it indicates potential compromise.
-- Investigate the parent process of 'chflags' to understand the context of how and why the hidden flag was applied, which may reveal additional suspicious activity.
-- Utilize Osquery to list all files with the hidden flag set on the system to identify any other potentially malicious files. Example query: `SELECT path FROM file WHERE flags LIKE '%hidden%';`
-- Cross-reference the timestamp of the file creation event with other logs, such as authentication or network activity, to identify any correlated suspicious behavior.
-- Analyze recent command history for the user associated with the 'chflags' process to uncover any manual commands that may indicate malicious intent.
-- Review system logs for any recent privilege escalation attempts that could have allowed an adversary to execute 'chflags' with elevated permissions.
-- Investigate any recent changes to system configurations or security settings that could facilitate the use of hidden files for evasion.
-- Consult threat intelligence sources to determine if the file path, name, or associated user account has been linked to known threat actors or campaigns.
-
-### False positive analysis
-
-- System administrators or automated scripts may use the 'chflags' command for legitimate purposes, such as managing system files or organizing directories, which can trigger false positives.
-- Backup or maintenance scripts that regularly modify file attributes to protect or hide system-critical files might also be flagged by this rule.
-- To manage these false positives, users can create exceptions for specific processes or scripts known to use 'chflags' legitimately by adding them to an allowlist.
-- Regularly review and update the allowlist to ensure it includes only trusted sources, minimizing the risk of overlooking genuine threats.
-- Consider implementing additional context checks, such as verifying the user or process context, to differentiate between benign and potentially malicious use of the 'chflags' command.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Conduct a thorough investigation to identify all files and directories with the 'hidden' flag set using 'chflags', and determine if they are associated with known malicious activity.
-- Review system logs and security alerts to trace the origin of the 'chflags' command usage and identify any unauthorized access or suspicious user accounts.
-- Remove or quarantine any identified malicious files and directories, ensuring that legitimate files are not affected.
-- Restore any altered or deleted legitimate files from backups, ensuring that the backup is clean and free from any malicious modifications.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed file attribute changes and process execution events for future monitoring and investigation.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar evasion tactics.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Apply system hardening measures, such as restricting the use of 'chflags' to authorized users only and regularly auditing file permissions and attributes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_directory_creation_in_bin.toml b/rules/linux/defense_evasion_directory_creation_in_bin.toml
index 0c1ff2b25b2..a38e54d6203 100644
--- a/rules/linux/defense_evasion_directory_creation_in_bin.toml
+++ b/rules/linux/defense_evasion_directory_creation_in_bin.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/11/01"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ files that are required for the system to function properly. The creation of dir
 attempt to hide malicious files or executables, as these /bin directories usually just contain binaries.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Directory Creation in /bin directory"
@@ -51,56 +53,18 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "mkdir" and
-process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "start", "ProcessRollup2", "exec_event") and process.name == "mkdir" and
+  process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
 not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Directory Creation in /bin directory
-
-The /bin directory is crucial for system operations, housing essential binaries. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule monitors for directory creation commands targeting /bin and similar paths, excluding legitimate uses, to identify potential threats linked to defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the directory creation event, focusing on the `process.name` and `process.args` fields to verify the use of the `mkdir` command in sensitive directories.
-- Check the `host.os.type` field to ensure the event occurred on a Linux system, as the rule is designed for Linux environments.
-- Investigate the `event.type` and `event.action` fields to confirm the event was a process start and execution, indicating an active directory creation attempt.
-- Examine the `process.args` field to identify the exact directory path targeted for creation, ensuring it matches the monitored paths like `/bin/*`, `/usr/bin/*`, etc.
-- Cross-reference the `process.args` with known legitimate directory creation commands to rule out false positives, as specified in the exclusion list (e.g., `/bin/mkdir`).
-- Use Osquery to gather additional context about the process that triggered the alert. For example, run the query: `SELECT * FROM processes WHERE name = 'mkdir' AND path LIKE '/bin/%';` to identify any suspicious `mkdir` processes.
-- Investigate the parent process of the `mkdir` command to determine if it was initiated by a legitimate user or process, which can provide insights into potential compromise.
-- Check system logs and user activity around the time of the alert to identify any unusual behavior or unauthorized access attempts that could correlate with the directory creation.
-- Review recent changes to the system's environment, such as software installations or updates, that might explain the directory creation in a legitimate context.
-- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize directory creation in the `/bin` directory as part of their tactics, techniques, and procedures (TTPs).
-
-### False positive analysis
-
-- System administrators or automated scripts may create directories in the /bin directory for legitimate purposes, such as organizing custom scripts or binaries that are not part of the default system installation. These actions can trigger false positives.
-- Software installations or updates might temporarily create directories in these paths as part of their setup or configuration processes, leading to benign alerts.
-- To manage these false positives, users can create exceptions for known and trusted processes or scripts that regularly perform directory creation in these paths. This can be done by adding specific process names or command patterns to an exclusion list.
-- Regularly review and update the exclusion list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats while reducing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized directories and files within the /bin and similar directories, using forensic tools if necessary.
-- Review system logs and process execution history to determine the origin and timeline of the directory creation, identifying any associated malicious processes or users.
-- Remove any unauthorized directories and files identified during the investigation, ensuring that no malicious binaries remain in the system.
-- Restore any affected binaries or system files from a known good backup to ensure system integrity and functionality.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed process execution and file system changes, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide real-time alerts for suspicious activities.
-- Apply system hardening measures, such as restricting write permissions in critical directories and implementing application whitelisting to prevent unauthorized software execution.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans, incorporating lessons learned to improve future response efforts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_disable_apparmor_attempt.toml b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
index 13b269e5c58..3c61939ffe3 100644
--- a/rules/linux/defense_evasion_disable_apparmor_attempt.toml
+++ b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/28"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ fine-grained access control policies to restrict the actions and resources that
 access. Adversaries may disable security tools to avoid possible detection of their tools and activities.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Disabling of AppArmor"
@@ -52,61 +54,21 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and (
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ (
   (process.name == "systemctl" and process.args in ("stop", "disable", "kill") and process.args in ("apparmor", "apparmor.service")) or
   (process.name == "service" and process.args == "apparmor" and process.args == "stop") or 
   (process.name == "chkconfig" and process.args == "apparmor" and process.args == "off") or
   (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Disabling of AppArmor
-
-AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do and access. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes that attempt to stop or disable AppArmor services, such as using commands like `systemctl`, `service`, or `chkconfig` with specific arguments, indicating potential tampering with security defenses.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time.
-- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
-- Examine the parent process of the suspicious activity to understand how the process was initiated and if it was part of a larger chain of events.
-- Use Osquery to list all processes related to AppArmor to verify if any have been stopped or disabled. Example query: `SELECT name, path, pid FROM processes WHERE name IN ('systemctl', 'service', 'chkconfig', 'ln');`
-- Review system logs, such as `/var/log/syslog` or `/var/log/auth.log`, for any additional context or anomalies around the time of the alert.
-- Check for any recent changes to AppArmor profiles or configurations in `/etc/apparmor.d/` to identify unauthorized modifications.
-- Investigate network connections from the host to determine if there are any suspicious outbound connections that could indicate data exfiltration or command and control activity.
-- Verify the integrity of AppArmor-related files and directories to ensure they have not been tampered with, using tools like `sha256sum` to compare against known good hashes.
-- Cross-reference the alert with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to gather additional context and corroborate findings.
-
-### False positive analysis
-
-- Routine system maintenance or administrative tasks may trigger this rule, such as legitimate updates or configuration changes that require temporarily stopping AppArmor.
-- Automated scripts or configuration management tools like Ansible, Puppet, or Chef might execute commands that match the rule criteria during system provisioning or updates.
-- Users can handle these false positives by creating exceptions for known maintenance windows or trusted administrative scripts, ensuring that these activities are logged and reviewed to confirm their legitimacy.
-- Exclude specific user accounts or process paths associated with trusted administrative tasks from triggering the rule, while maintaining a log of these exclusions for audit purposes.
-- Regularly review and update the list of exceptions to adapt to changes in system administration practices or infrastructure updates, ensuring that only non-threatening behaviors are excluded.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Investigate the process logs to identify the source and scope of the attempt to disable AppArmor, focusing on the user accounts and IP addresses involved.
-- Review recent changes to AppArmor profiles and configurations to ensure no unauthorized modifications have been made.
-- Restore AppArmor to its operational state by re-enabling the service using `systemctl start apparmor` or `service apparmor start`.
-- Conduct a thorough malware scan on the affected system to detect and remove any malicious software that may have been introduced.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a broader attack.
-- Implement enhanced logging policies to capture detailed process execution and system changes, ensuring that future attempts to disable security tools are detected promptly.
-- Integrate security information and event management (SIEM) solutions to correlate events and improve detection capabilities across the network.
-- Apply system hardening measures, such as restricting administrative privileges and implementing strict access controls, to reduce the risk of future attacks.
-- Review and update security policies and procedures to incorporate lessons learned from the incident, ensuring a more robust defense against similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_disable_selinux_attempt.toml b/rules/linux/defense_evasion_disable_selinux_attempt.toml
index 24b00198b2b..491a0e169ca 100644
--- a/rules/linux/defense_evasion_disable_selinux_attempt.toml
+++ b/rules/linux/defense_evasion_disable_selinux_attempt.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2020/04/22"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ support access control policies. Adversaries may disable security tools to avoid
 activities.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Disabling of SELinux"
@@ -64,58 +66,17 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name == "setenforce" and process.args == "0"
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name == "setenforce" and process.args == "0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Disabling of SELinux
-
-SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for processes that execute the command to set SELinux to permissive mode, indicating a potential security compromise.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "setenforce" and the process arguments are "0", indicating an attempt to set SELinux to permissive mode.
-- Check the timestamp of the event to determine when the attempt to disable SELinux occurred.
-- Identify the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
-- Investigate the parent process of "setenforce" to understand the context in which it was executed and identify any related suspicious activity.
-- Examine the command history of the user account involved to see if there are other suspicious commands executed around the same time.
-- Use Osquery to gather additional context about the system state and user activity. For example, run the following Osquery query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY time DESC LIMIT 20;`
-- Analyze system logs, such as /var/log/audit/audit.log, for any related entries that might provide more context on the SELinux status change and other security events.
-- Check for any recent changes to SELinux configuration files, such as /etc/selinux/config, to see if there have been unauthorized modifications.
-- Investigate network activity from the host around the time of the event to identify any potential data exfiltration or communication with known malicious IP addresses.
-- Correlate this event with other security alerts or anomalies in the environment to determine if it is part of a larger attack campaign.
-
-### False positive analysis
-
-- System administrators or automated scripts may legitimately set SELinux to permissive mode during system maintenance or troubleshooting, leading to false positives. 
-- Development environments might temporarily disable SELinux to facilitate software testing, which can trigger the detection rule.
-- Some legacy applications may require SELinux to be set to permissive mode for compatibility reasons, resulting in non-malicious alerts.
-- To manage these false positives, users can create exceptions for known maintenance windows or specific user accounts that are authorized to modify SELinux settings.
-- Implementing a whitelist of processes or scripts that are allowed to change SELinux modes can help reduce unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the current SELinux status using the command `sestatus` to confirm if it has been set to permissive or disabled.
-- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities on the system, focusing on recent process executions and file modifications.
-- Review system logs and security alerts to determine the timeline and scope of the compromise, correlating with the MITRE ATT&CK technique T1562 for impair defenses.
-- Restore SELinux to enforcing mode using the command `setenforce 1` and ensure that the SELinux configuration is set to enforcing in the `/etc/selinux/config` file.
-- Perform a comprehensive malware scan and integrity check on the system to identify and remove any malicious software or unauthorized changes.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and system changes, integrating with SIEM solutions for real-time alerting.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future occurrences.
-- Apply system hardening measures, such as regular patching, disabling unnecessary services, and enforcing strict access controls, to reduce the attack surface and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
index b16f05110fb..1b325e4f75f 100644
--- a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
+++ b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and event.type != "deletion" and file.path == "/etc/doas.conf"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Defense Evasion via Doas
-
-Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or execute commands stealthily. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion" to ensure the alert is relevant.
-- Check the timestamp of the alert to determine when the suspicious activity occurred and correlate it with other events in the system logs around the same time.
-- Identify the user account associated with the event to determine if the activity was performed by a legitimate user or a potential adversary.
-- Examine the process that made changes to the Doas configuration file by reviewing process creation logs or using process monitoring tools.
-- Use Osquery to list recent modifications to the Doas configuration file with the query: `SELECT * FROM file WHERE path = '/etc/doas.conf' ORDER BY mtime DESC LIMIT 5;` to gather more context on the changes.
-- Investigate the command history of the user involved in the alert to identify any suspicious commands executed around the time of the alert.
-- Check for any recent changes in user privileges or group memberships that might indicate privilege escalation attempts.
-- Review system authentication logs to identify any unusual login attempts or patterns that coincide with the alert.
-- Analyze network logs for any suspicious outbound connections or data exfiltration attempts following the alert.
-- Cross-reference the alert with other security tools and logs to identify any additional indicators of compromise or related suspicious activities.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may regularly update or modify the Doas configuration file as part of legitimate system maintenance or configuration changes. These activities can trigger the detection rule but are not indicative of malicious behavior.
-- Software updates: Certain software installations or updates might modify the Doas configuration file to ensure compatibility or to set specific permissions, leading to false positives.
-- Configuration management tools: Automated tools like Ansible, Puppet, or Chef might alter the Doas configuration file as part of their normal operation, which can be mistaken for suspicious activity.
-- To manage these false positives, users can create exceptions for known administrative activities or trusted software processes by whitelisting specific users or processes that are authorized to modify the Doas configuration file. Additionally, maintaining a log of legitimate changes and correlating them with detected events can help differentiate between benign and suspicious modifications.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the integrity of the Doas configuration file by comparing it with a known good backup or baseline configuration.
-- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities in the system logs, focusing on user access and command execution patterns.
-- Revert any unauthorized changes to the Doas configuration file and restore it from a trusted backup if necessary.
-- Change all potentially compromised user credentials, especially those with elevated privileges, to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for critical configuration files and privileged command executions to detect future unauthorized changes.
-- Integrate security information and event management (SIEM) solutions to correlate events and improve threat detection capabilities.
-- Apply system hardening measures, such as restricting access to configuration files and enforcing the principle of least privilege for user accounts.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
index 2d12d6c931f..2e7b12d950d 100644
--- a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
+++ b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -80,50 +80,6 @@ not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Dynamic Linker Creation or Modification
-
-The dynamic linker in Linux systems is crucial for loading shared libraries needed by programs at runtime. Adversaries may exploit this by altering linker configuration files to hijack program execution, redirecting it to malicious libraries. The detection rule identifies suspicious creation or modification of these files, excluding legitimate processes and temporary files, to flag potential hijacking attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path involved in the creation or modification event, focusing on paths like "/etc/ld.so.preload", "/etc/ld.so.conf.d/*", and "/etc/ld.so.conf".
-- Check the process executable that triggered the alert to determine if it is listed in the exclusion list, which includes common package managers and system processes.
-- Investigate the user account associated with the process that made the change to assess if it has legitimate access or if it might be compromised.
-- Use Osquery to gather more information about the process that triggered the alert. For example, run the following query to get details about the process: `SELECT * FROM processes WHERE pid = <process_id>;`.
-- Examine the process tree to understand the parent-child relationship and identify if the process was spawned by a legitimate or suspicious parent process.
-- Check the file's modification history and access times to determine if there have been any recent unauthorized changes or access patterns.
-- Investigate any network connections or external communications initiated by the process to identify potential command and control activity.
-- Review system logs for any other suspicious activities or anomalies around the time of the alert, such as failed login attempts or unusual user behavior.
-- Correlate the alert with other security events or alerts in the environment to identify if this is part of a broader attack campaign.
-- Verify the integrity of the dynamic linker configuration files by comparing them against known good baselines or backups to identify unauthorized changes.
-
-### False positive analysis
-
-- Package management operations: Legitimate package managers such as dpkg, rpm, yum, and others may modify dynamic linker configuration files during software installation or updates. These actions are typically benign and can be excluded by adding the package manager executables to the exception list.
-- System updates and maintenance: Automated system updates or maintenance scripts might trigger the rule. Exclude known update processes or scripts by specifying their executables in the exception criteria.
-- Temporary files: Editors like vim may create temporary swap files (e.g., with extensions like .swp, .swpx) during editing sessions. These can be safely ignored by excluding files with these extensions.
-- Virtualization and containerization tools: Tools such as Docker, Podman, and VMware may modify linker configurations as part of their normal operations. Exclude these processes by adding their executables to the exception list.
-- Monitoring and security tools: Some monitoring or security tools, like Dynatrace OneAgent, may interact with linker files. Exclude these tools by specifying their installation paths in the exception criteria.
-- Custom scripts or applications: If custom scripts or applications are known to modify linker configurations as part of their functionality, consider excluding these by adding their process names or paths to the exception list.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the modification, including reviewing recent changes to dynamic linker configuration files and correlating with process execution logs.
-- Verify the integrity of the dynamic linker configuration files by comparing them with known good backups or baselines.
-- Restore any altered dynamic linker configuration files from a trusted backup to ensure the system's execution flow is not hijacked.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and file modification events, focusing on critical system directories and configuration files.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Review and update access controls and permissions for critical system files to minimize the risk of unauthorized modifications.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements to prevent recurrence.
-- Educate users and administrators on the importance of maintaining system integrity and recognizing signs of potential compromise."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
index 7d13bf34482..6bf55b5f216 100644
--- a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
+++ b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/04/11"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +16,7 @@ their presence in the touch command arguments may indicate that a threat actor i
 of VM-related files and configurations on the system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "ESXI Timestomping using Touch Command"
@@ -57,57 +59,17 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name == "touch" and process.args == "-r" and
-process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*")
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name == "touch" and process.args == "-r" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 ESXI Timestomping using Touch Command
-
-VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring for the 'touch' command targeting specific VMware paths, signaling potential timestamp tampering for evasion.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'touch' command with the "-r" flag in the process arguments, specifically targeting paths like "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*".
-- Verify the user account associated with the process execution to determine if it aligns with expected administrative activity or if it might be indicative of unauthorized access.
-- Check the process execution timeline to identify any preceding or subsequent suspicious activities that might correlate with the timestamp modification attempt.
-- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any potential script or application that might have triggered it.
-- Utilize Osquery to list recent file modifications in the targeted directories to identify any unauthorized changes. Example query: `SELECT path, mtime FROM file WHERE path LIKE '/etc/vmware/%' OR path LIKE '/usr/lib/vmware/%' OR path LIKE '/vmfs/%' ORDER BY mtime DESC LIMIT 10;`
-- Examine system logs for any login attempts or access patterns around the time of the alert to identify potential unauthorized access.
-- Cross-reference the alert with any other security events or alerts from the same host to identify patterns or correlations that might indicate a broader attack.
-- Review network logs for any unusual outbound connections from the host that might suggest data exfiltration or communication with a command and control server.
-- Check for any recent changes in user privileges or group memberships that might have facilitated the execution of the 'touch' command with elevated permissions.
-- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the potential security incident.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use the 'touch' command with the "-r" flag during legitimate maintenance activities, such as synchronizing timestamps across files for backup or archival purposes. To manage these, users can create exceptions for known administrative scripts or processes that regularly perform these actions.
-- Automated scripts: Some automated scripts or system management tools might use the 'touch' command with the "-r" flag as part of their normal operations. Users should identify these scripts and exclude them from the detection rule by specifying their process names or paths.
-- Software updates: During software updates or installations, legitimate processes might modify timestamps in VMware-related directories. Users can handle these by temporarily disabling the rule during scheduled updates or by creating exceptions for update processes.
-- Backup operations: Backup software might use the 'touch' command to ensure file metadata consistency. Users should identify and exclude these backup processes from the rule to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or changes.
-- Conduct a thorough investigation to identify any unauthorized changes or access, focusing on the specific VMware paths mentioned in the alert.
-- Review system logs and command history to determine the extent of the compromise and identify any additional malicious activities.
-- Restore any altered files from known good backups to ensure the integrity of the VMware environment.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed command execution and file access events, particularly for critical directories like VMware paths.
-- Integrate with a security information and event management (SIEM) system to correlate events and detect similar activities across the network.
-- Apply security patches and updates to the ESXi host and associated systems to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting access to critical directories, enforcing least privilege, and using file integrity monitoring tools."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_file_deletion_via_shred.toml b/rules/linux/defense_evasion_file_deletion_via_shred.toml
index 95d66a7cac4..e942a964e63 100644
--- a/rules/linux/defense_evasion_file_deletion_via_shred.toml
+++ b/rules/linux/defense_evasion_file_deletion_via_shred.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ process where host.os.type == "linux" and event.type == "start" and process.name
   "-u", "--remove", "-z", "--zero"
 ) and not process.parent.name == "logrotate"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File Deletion via Shred
-
-The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential misuse for stealthy file removal.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the execution of the `shred` command, focusing on the `process.name` and `process.args` fields to verify the suspicious arguments used.
-- Check the `process.parent.name` field to ensure the parent process is not a benign process like `logrotate`, which is excluded in the detection rule.
-- Investigate the user account associated with the `shred` process by examining the `user.name` field to determine if the activity aligns with expected behavior for that user.
-- Analyze the `host.os.type` and `host.name` fields to identify the specific system where the `shred` command was executed, and assess if this system is a common target for such activities.
-- Use Osquery to gather additional context about the file system activity around the time of the alert. For example, run the following Osquery query to list recent file modifications: `SELECT * FROM file WHERE path LIKE '/path/to/suspicious/directory/%' AND mtime > (SELECT strftime('%s', 'now') - 3600);`
-- Examine the `event.type` field to confirm the event type is "start," indicating the initiation of the `shred` process, and correlate with other process events to understand the sequence of actions.
-- Review system logs and other security tools for any related alerts or anomalies around the time of the `shred` execution to identify potential precursor or follow-up activities.
-- Investigate network activity from the host using network monitoring tools to check for any suspicious outbound connections that might indicate data exfiltration or command-and-control communication.
-- Cross-reference the alert with known threat intelligence sources to determine if the observed behavior matches any known adversary tactics, techniques, or procedures (TTPs).
-- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation and facilitate further analysis if needed.
-
-### False positive analysis
-
-- The `shred` command may be used by legitimate system maintenance processes, such as automated scripts for secure file deletion, which can trigger false positives. 
-- System administrators might use `shred` for routine secure deletion of sensitive files, which should be considered when analyzing alerts.
-- To manage these false positives, users can create exceptions for known benign processes or scripts that frequently use `shred` with the specified arguments.
-- Implementing a whitelist for specific users or processes that are authorized to use `shred` can help reduce noise in the detection system.
-- Regularly review and update the list of exceptions to ensure that only legitimate uses of `shred` are excluded from alerts, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
-- Conduct a thorough investigation to identify the scope of the intrusion, focusing on logs and other forensic evidence to determine the extent of file deletion and any other malicious actions.
-- Utilize file recovery tools to attempt restoration of any critical files that may have been deleted using the `shred` command.
-- Review and analyze the process tree to identify the parent process of `shred` and any associated processes that may indicate the presence of malware or unauthorized scripts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships, to aid in future investigations.
-- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious file deletion activities and other potential indicators of compromise.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future.
-- Implement hardening measures such as restricting the use of the `shred` command to authorized users only and employing file integrity monitoring to detect unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_file_mod_writable_dir.toml b/rules/linux/defense_evasion_file_mod_writable_dir.toml
index cbc636c7321..7c4265bf95b 100644
--- a/rules/linux/defense_evasion_file_mod_writable_dir.toml
+++ b/rules/linux/defense_evasion_file_mod_writable_dir.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -76,49 +76,6 @@ host.os.type:linux and event.category:process and event.type:start and
 process.name:(chattr or chgrp or chmod or chown) and process.working_directory:(/dev/shm or /tmp or /var/tmp) and
 not process.parent.name:(apt-key or update-motd-updates-available or apt-get)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File Permission Modification in Writable Directory
-
-In Linux environments, file permissions control access to files and directories. Writable directories like /tmp are often targeted by adversaries to drop and execute malicious payloads. By modifying file permissions, attackers can ensure their payloads execute with the necessary privileges. The detection rule identifies suspicious permission changes by non-root users in these directories, excluding benign processes, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name (chattr, chgrp, chmod, or chown) that triggered the alert and the associated user account.
-- Examine the process.working_directory field to confirm the directory involved (/dev/shm, /tmp, or /var/tmp) and assess if the directory is commonly used for legitimate purposes by the user.
-- Check the process.parent.name field to ensure the process was not initiated by a benign parent process like apt-key, update-motd-updates-available, or apt-get.
-- Investigate the history of the user account involved in the alert to determine if there have been any previous suspicious activities or alerts associated with this user.
-- Use Osquery to list recent file permission changes in the specified directory. Example query: `SELECT path, mode, uid, gid, atime, mtime FROM file WHERE directory IN ('/dev/shm', '/tmp', '/var/tmp') AND mode != '0755';`
-- Correlate the timestamp of the alert with other logs, such as authentication logs, to identify any unusual login activities or patterns around the time of the permission change.
-- Analyze the command-line arguments of the process to understand the specific permission changes made and assess if they align with typical user behavior.
-- Review any associated network activity from the host around the time of the alert to identify potential data exfiltration or communication with known malicious IP addresses.
-- Investigate other processes running on the host to identify any additional suspicious activities or processes that may have been spawned as a result of the permission change.
-- Check for any recent file modifications or new file creations in the involved directory to identify potential payloads or scripts that may have been dropped by the adversary.
-
-### False positive analysis
-
-- Routine administrative tasks by non-root users, such as developers or system administrators, may trigger the rule when they modify file permissions in writable directories for legitimate purposes. 
-- Automated scripts or applications that require temporary file permission changes in directories like /tmp for functionality or performance reasons can also result in false positives.
-- Development environments where non-root users frequently compile or test software may involve permission changes that are benign.
-- To manage these false positives, users can create exceptions for specific processes or users known to perform legitimate permission modifications by updating the detection rule to exclude these entities.
-- Regularly review and update the list of excluded processes or users to ensure that only non-threatening behaviors are ignored, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the process that modified file permissions by checking the process owner, command line arguments, and parent process.
-- If the process is deemed malicious, terminate it and any associated processes to stop further execution.
-- Conduct a thorough investigation to identify any additional files or payloads dropped by the adversary in writable directories.
-- Restore file permissions to their original state and remove any unauthorized files or payloads identified during the investigation.
-- Review and analyze system logs to trace the origin of the attack and identify any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed information on file permission changes and process executions in writable directories.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities.
-- Apply system hardening measures, such as restricting write access to critical directories and implementing least privilege principles, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_hex_payload_execution.toml b/rules/linux/defense_evasion_hex_payload_execution.toml
index 9e23e1d8ce8..2077dd5f76e 100644
--- a/rules/linux/defense_evasion_hex_payload_execution.toml
+++ b/rules/linux/defense_evasion_hex_payload_execution.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/11/04"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ This rule detects potential hex payload execution on Linux systems. Adversaries
 and evade detection mechanisms.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*"]
+index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Hex Payload Execution"
@@ -50,62 +52,24 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
-  (process.name == "xxd" and process.args like ("-r*", "-p*")) or
-  (process.name like "python*" and process.command_line like "*fromhex*" and process.command_line like ("*decode*", "*encode*")) or
-  (process.name like "php*" and process.command_line like "*hex2bin*") or
-  (process.name like "ruby*" and process.command_line like "*].pack(\"H*\")*") or
-  (process.name like "perl*" and process.command_line like "*pack(\"H*\",*") or
-  (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*")
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  (
+    (process.name == "xxd" and process.args like ("-r*", "-p*")) or
+    (process.name like "python*" and process.command_line like "*fromhex*" and process.command_line like ("*decode*", "*encode*")) or
+    (process.name like "php*" and process.command_line like "*hex2bin*") or
+    (process.name like "ruby*" and process.command_line like "*].pack(\"H*\")*") or
+    (process.name like "perl*" and process.command_line like "*pack(\"H*\",*") or
+    (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*")
+  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Hex Payload Execution
-
-Hex encoding is often used to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding payloads in hex to bypass defenses. The detection rule identifies suspicious execution patterns on Linux, such as using tools like `xxd`, or scripting languages like Python and PHP, to decode hex-encoded data, signaling potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and command line arguments that triggered the rule, focusing on fields like `process.name` and `process.command_line`.
-- Check the `host.os.type` and `event.type` fields to confirm the alert pertains to a Linux system and involves a process start event.
-- Investigate the parent process of the suspicious execution using the `process.parent.name` and `process.parent.command_line` fields to understand the context in which the hex decoding was initiated.
-- Examine the user account associated with the process execution by reviewing the `user.name` field to determine if the activity aligns with expected behavior for that user.
-- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<process_name>' AND cmdline LIKE '%<suspicious_command_line>%';` to verify the process details and any related activity.
-- Analyze the network activity of the host during the time of the alert to identify any suspicious connections or data transfers that may correlate with the hex payload execution.
-- Review recent file modifications or creations on the host using file integrity monitoring tools or logs to detect any changes that coincide with the alert.
-- Check for any other alerts or logs related to the same host or user around the time of the alert to identify potential patterns or additional suspicious activities.
-- Investigate the system's history for any previous instances of similar alerts or processes to determine if this is part of a recurring pattern.
-- Consult threat intelligence sources to see if the specific command line patterns or process names have been associated with known malicious campaigns or tools.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use tools like `xxd`, Python, PHP, Ruby, Perl, or Lua for legitimate purposes such as data conversion or debugging, which can trigger this rule. To manage these, users can create exceptions for known administrative scripts or processes that frequently use these tools in a non-threatening manner.
-- Development and testing activities: Developers often use hex encoding and decoding during software development and testing phases. To handle these false positives, users can exclude specific development environments or user accounts from the rule.
-- Automated scripts and cron jobs: Automated scripts or scheduled tasks that perform regular data processing might use hex encoding for legitimate reasons. Users can whitelist these scripts by identifying their unique command-line patterns or process names.
-- Security tools and monitoring software: Some security tools may use hex encoding as part of their normal operations. Users should identify these tools and exclude them from the rule to prevent unnecessary alerts.
-- Data analysis and research: Researchers and data analysts might use hex encoding for data analysis purposes. Users can manage these false positives by excluding specific user accounts or processes associated with research activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the process execution logs to identify the source and scope of the hex payload execution.
-- Analyze the decoded payload to determine its intent and potential impact on the system.
-- Remove any identified malicious files or processes from the system to prevent further execution.
-- Apply patches and updates to the operating system and applications to mitigate vulnerabilities that may have been exploited.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics.
-- Restore the system from a known good backup to ensure the integrity and security of the operational environment.
-- Review and update security policies and configurations to harden the system against similar obfuscation and execution techniques in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_directory_creation.toml b/rules/linux/defense_evasion_hidden_directory_creation.toml
index e14a291c242..621d5aa8d1d 100644
--- a/rules/linux/defense_evasion_hidden_directory_creation.toml
+++ b/rules/linux/defense_evasion_hidden_directory_creation.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/11/01"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +20,7 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Hidden Directory Creation via Unusual Parent"
@@ -57,11 +59,13 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Tactic: Persistence",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and
 process.name == "mkdir" and process.parent.executable like (
   "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/run/*", "/root/*", "/boot/*", "/var/www/html/*", "/opt/.*"
 ) and process.args like (".*", "/*/.*") and process.args_count <= 3 and not (
@@ -72,49 +76,6 @@ process.name == "mkdir" and process.parent.executable like (
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Hidden Directory Creation via Unusual Parent
-
-In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files. Adversaries exploit this feature to conceal malicious files by creating hidden directories using uncommon parent processes. The detection rule identifies such activities by monitoring directory creation commands executed by unexpected parent executables in sensitive directories, filtering out known benign patterns to reduce false positives.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific parent executable and the directory path where the hidden directory was created. Pay attention to the `process.parent.executable` and `process.args` fields.
-- Check the process tree to understand the context of the `mkdir` command execution. Determine if the parent process is part of a known application or script.
-- Use Osquery to list all processes running under the parent executable identified in the alert. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE path LIKE '/dev/shm/%' OR path LIKE '/tmp/%' OR path LIKE '/var/tmp/%' OR path LIKE '/var/run/%' OR path LIKE '/root/%' OR path LIKE '/boot/%' OR path LIKE '/var/www/html/%' OR path LIKE '/opt/%';`
-- Investigate the parent executable's origin and integrity. Check if it matches known hashes or if it has been modified recently.
-- Examine the contents of the newly created hidden directory to identify any suspicious files or scripts. Look for known malicious file signatures or unusual file types.
-- Cross-reference the timestamp of the directory creation with other logs (e.g., authentication, network, or application logs) to identify any correlated suspicious activities.
-- Check for any recent changes in user accounts or permissions that could have facilitated the creation of the hidden directory.
-- Investigate the user account associated with the process execution to determine if it has been compromised or is behaving unusually.
-- Review historical data to see if similar hidden directory creation events have occurred in the past, indicating a potential pattern or ongoing campaign.
-- Consult threat intelligence sources to determine if the parent executable or directory path is associated with known attack techniques or threat actors.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate administrative scripts or applications that create hidden directories for configuration or temporary storage purposes. These can include package managers, build systems, or development tools that operate in directories like `/tmp` or `/var/tmp`.
-- Users can handle these false positives by creating exceptions for specific parent executables or command patterns that are known to be benign. For instance, adding exceptions for processes like `/tmp/newroot/*` or `/run/containerd/*` can help reduce noise.
-- Another method to manage false positives is to refine the rule by excluding command lines that match known safe patterns, such as `mkdir -p .` or `mkdir ./*`, which are commonly used in legitimate operations.
-- Regularly reviewing and updating the list of exceptions based on the environment's typical behavior can help maintain the balance between detection accuracy and minimizing false positives.
-- It's important to consider the context of the environment and the typical behavior of applications and scripts to ensure that legitimate activities are not inadvertently flagged as suspicious.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on the unusual parent process and any associated hidden directories.
-- Review and analyze logs from the system and network to trace the origin and timeline of the attack, leveraging MITRE ATT&CK T1564 for context on hiding artifacts.
-- Remove any identified malicious files or directories and terminate any suspicious processes related to the alert.
-- Restore the system from a known good backup if the integrity of the system is in question.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process creation events and file system changes for future investigations.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
-- Conduct a security review and harden the system by disabling unnecessary services, enforcing least privilege access, and implementing strong authentication mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
index 659ef922c75..f013e542b90 100644
--- a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
+++ b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -84,49 +84,6 @@ not process.name in (
   "command-not-found"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation of Hidden Files and Directories via CommandLine
-
-In Linux environments, files and directories prefixed with a dot (.) are hidden by default, a feature often exploited by adversaries to conceal malicious activities. Attackers may create hidden files in writable directories like /tmp or /var/tmp to evade detection. The detection rule identifies suspicious processes creating such hidden files, excluding benign commands like 'ls' or 'git', thus highlighting potential threats while minimizing false positives.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process that triggered the rule, focusing on the `process.name` and `process.args` fields to understand what command was executed.
-- Examine the `process.working_directory` field to determine the directory where the hidden file or directory was created, ensuring it matches one of the common writable directories like `/tmp`, `/var/tmp`, or `/dev/shm`.
-- Check the `host.os.type` field to confirm the operating system is Linux, as the rule is specifically designed for Linux environments.
-- Investigate the parent process of the suspicious process using the `process.parent.name` and `process.parent.args` fields to understand the context in which the hidden file creation was initiated.
-- Use Osquery to list all hidden files in the directory where the alert was triggered. Example query: `SELECT * FROM file WHERE directory = '/tmp' AND filename LIKE '.%'`.
-- Analyze the contents of the hidden file or directory, if accessible, to determine if it contains malicious code or scripts.
-- Review recent system logs and command history for the user associated with the process to identify any unusual or unauthorized activities leading up to the alert.
-- Check for any network connections or data exfiltration attempts associated with the process using network monitoring tools or logs.
-- Investigate other processes executed by the same user or from the same working directory to identify any additional suspicious activities.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack or campaign.
-
-### False positive analysis
-
-- Known false positives for the Creation of Hidden Files and Directories via CommandLine rule include legitimate system and user activities that create hidden files for configuration or temporary purposes. Common examples are software installations or updates that generate hidden files in directories like /tmp or /var/tmp.
-- Users can manage these false positives by adding exceptions for specific processes or commands that are known to create hidden files as part of their normal operation. This can be done by updating the exclusion list in the detection rule to include additional benign processes that are identified during routine monitoring.
-- Regularly review and update the exclusion list to reflect changes in system behavior or new software deployments that may introduce new benign processes creating hidden files.
-- Consider the context of the process creating the hidden file, such as the user account under which the process is running and the typical behavior of that account, to determine if an activity is likely to be a false positive.
-- Implement logging and alerting mechanisms to track the frequency and context of hidden file creation events, which can help in distinguishing between legitimate and suspicious activities over time.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the hidden files and directories created, analyzing their contents and associated processes for malicious indicators.
-- Terminate any suspicious processes identified during the investigation that are associated with the creation of hidden files.
-- Remove or quarantine the hidden files and directories after confirming they are not legitimate or required for system operations.
-- Review and analyze system logs, including process execution and file access logs, to trace the origin and timeline of the malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a broader attack campaign or if advanced persistent threat (APT) involvement is suspected.
-- Implement enhanced logging policies to capture detailed process execution and file creation events, ensuring future incidents can be detected and investigated more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying necessary patches, updating security configurations, and ensuring all malicious artifacts are removed.
-- Harden the system by implementing least privilege access controls, disabling unnecessary services, and regularly auditing writable directories for unauthorized changes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_shared_object.toml b/rules/linux/defense_evasion_hidden_shared_object.toml
index 63a6b75a4f3..3f6201d9255 100644
--- a/rules/linux/defense_evasion_hidden_shared_object.toml
+++ b/rules/linux/defense_evasion_hidden_shared_object.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -78,49 +78,6 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and file.extension == "so" and file.name : ".*.so" and
 not process.name == "dockerd"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation of Hidden Shared Object File
-
-Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to uncover potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file creation event, focusing on the file name and path to determine if it matches the pattern of a hidden shared object file (e.g., `.hiddenfile.so`).
-- Examine the process that created the file by checking the `process.name` and `process.pid` fields to identify any suspicious or unexpected processes involved in the file creation.
-- Investigate the user account associated with the file creation event using the `user.name` field to determine if the action was performed by a legitimate user or a potentially compromised account.
-- Use Osquery to list all hidden shared object files on the system with a query like: `SELECT path FROM file WHERE path LIKE '/%.so';` to identify any other hidden .so files that may have been created.
-- Check the file metadata, such as creation and modification timestamps, to understand the timeline of the file's existence and correlate it with other system events.
-- Analyze the file's contents or hash it and compare it against known malicious signatures using a threat intelligence database to determine if it is a known threat.
-- Investigate the parent process of the file creation event to understand the origin of the process chain and identify any potential exploitation or lateral movement activities.
-- Review system logs around the time of the file creation for any unusual activity or errors that might indicate exploitation attempts or other malicious behavior.
-- Check for any network connections initiated by the process that created the file to identify potential command and control communication or data exfiltration attempts.
-- Correlate the event with other alerts or incidents in the environment to determine if this is part of a larger attack campaign or isolated incident.
-
-### False positive analysis
-
-- Development and testing environments may generate hidden .so files as part of normal operations, especially when developers are working on shared libraries and use hidden files for version control or temporary storage.
-- System maintenance scripts or automated backup processes might create hidden .so files to temporarily store or manage shared libraries, which can be mistaken for malicious activity.
-- Some legitimate applications or services may use hidden .so files for configuration or internal operations, particularly those that manage plugins or extensions, leading to false positives.
-- Users can manage these false positives by creating exceptions for known benign processes or directories where hidden .so files are expected, such as specific development directories or application-specific paths.
-- Regularly review and update the list of exceptions to ensure that new legitimate processes or directories are accounted for, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to identify the source and scope of the hidden .so file creation, examining process trees and user activity.
-- Remove the malicious hidden .so file and any associated files or processes identified during the investigation.
-- Review and update access controls and permissions to prevent unauthorized file creation and execution.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Implement enhanced logging policies to capture detailed file creation events and process activities, ensuring visibility into similar future activities.
-- Integrate with threat intelligence platforms to enrich alerts with context and improve detection capabilities.
-- Restore the system from a known good backup to ensure the integrity and security of the operating environment.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing strict file permissions, to reduce the attack surface.
-- Conduct a post-incident review to identify gaps in detection and response, updating security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
index 75b6802fbbb..caeffc29de3 100644
--- a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
+++ b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/04"
 
 [rule]
 author = ["Elastic"]
@@ -69,49 +69,6 @@ event.category:process and host.os.type:linux and event.type:start and event.act
   (user.name:daemon and process.name:at)
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Interactive Shell Launched from System User
-
-In Linux environments, system users are typically non-interactive and serve specific system functions. Adversaries may exploit these accounts to launch interactive shells, bypassing security measures and evading detection. The detection rule identifies such anomalies by monitoring process activities linked to system users, excluding legitimate processes, to flag potential misuse indicative of malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific system user and process involved in launching the interactive shell. Pay attention to the `user.name` and `process.name` fields.
-- Check the `process.parent.executable` and `process.parent.name` fields to understand the parent process that initiated the shell. This can provide context on how the shell was launched.
-- Use Osquery to list all active processes for the identified system user to determine if there are other suspicious activities. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'system_user');`
-- Investigate the command-line arguments of the suspicious process using the `process.args` field to identify any potentially malicious commands or scripts being executed.
-- Examine the system logs around the time of the alert to identify any related events or anomalies that could provide additional context.
-- Check for any recent changes to user accounts or permissions that might have allowed the system user to launch an interactive shell.
-- Investigate network connections initiated by the suspicious process using tools like `netstat` or `ss` to identify any unusual outbound connections.
-- Review the system's authentication logs (e.g., `/var/log/auth.log`) to identify any unauthorized access attempts or successful logins around the time of the alert.
-- Use Osquery to check for any recent file modifications or creations in critical directories that might indicate tampering or preparation for further attacks. Example query: `SELECT * FROM file WHERE path LIKE '/etc/%' AND mtime > (SELECT strftime('%s', 'now') - 3600);`
-- Correlate the findings with other security tools and logs to determine if this activity is part of a broader attack pattern or isolated incident.
-
-### False positive analysis
-
-- System maintenance tasks: Some system maintenance scripts or automated tasks may inadvertently trigger interactive shells under system user accounts. These tasks are typically scheduled and can be identified by their regular occurrence and specific command patterns.
-- Software updates: During software updates, certain processes might temporarily launch interactive shells as part of their installation or configuration routines. Monitoring the timing and context of these updates can help differentiate between legitimate and suspicious activities.
-- Backup operations: Backup software might use system accounts to perform data integrity checks or other operations that could involve launching interactive shells. Identifying the specific backup software and its behavior can help in creating exceptions.
-- Custom scripts: Organizations may have custom scripts that run under system user accounts for specific operational needs. These should be documented, and their behavior should be analyzed to ensure they are not flagged as false positives.
-- To manage false positives, users can create exceptions by adding specific process names, arguments, or user names to the exclusion list in the detection rule. Regularly reviewing and updating these exceptions based on observed legitimate activities will help maintain the accuracy of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the processes and user accounts involved.
-- Terminate any unauthorized interactive shell sessions and processes initiated by system users.
-- Review and analyze system logs, including authentication logs and process execution logs, to gather evidence and understand the attack vector.
-- Change passwords and review permissions for all system user accounts to prevent further exploitation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and user activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore the system to a known good state using backups, ensuring that all malicious artifacts are removed.
-- Apply system hardening measures, such as disabling unnecessary system user accounts and services, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
diff --git a/rules/linux/defense_evasion_kernel_module_removal.toml b/rules/linux/defense_evasion_kernel_module_removal.toml
index f72081cf85a..3b7b0ffd12f 100644
--- a/rules/linux/defense_evasion_kernel_module_removal.toml
+++ b/rules/linux/defense_evasion_kernel_module_removal.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2020/04/24"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +20,7 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Kernel Module Removal"
@@ -58,57 +60,20 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and (
-  process.name == "rmmod" or
-  (process.name == "modprobe" and process.args in ("--remove", "-r"))
-) and process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  (
+    process.name == "rmmod" or
+    (process.name == "modprobe" and process.args in ("--remove", "-r"))
+  ) and
+  process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kernel Module Removal
-
-Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring specific processes and commands, such as `rmmod` and `modprobe`, especially when executed from common shell environments, indicating potential defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name (`rmmod` or `modprobe`) and the parent process name that triggered the alert, as these can provide initial context on how the module removal was attempted.
-- Check the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
-- Investigate the command-line arguments used with `modprobe` to confirm if the `--remove` or `-r` flags were used, indicating an attempt to remove a module.
-- Examine the process execution timeline to identify any preceding or subsequent suspicious activities, such as privilege escalation attempts or other defense evasion tactics.
-- Use Osquery to list currently loaded kernel modules and compare them with historical data to identify any discrepancies or missing modules. Example query: `SELECT * FROM kernel_modules;`
-- Correlate the alert with other security events or logs from the same host to identify any patterns or related activities that could indicate a broader attack.
-- Analyze the parent process (`sudo`, `bash`, etc.) to determine if it was used legitimately or if it shows signs of compromise, such as unusual execution paths or unexpected arguments.
-- Review system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication anomalies or unauthorized access attempts around the time of the alert.
-- Investigate the network activity of the host to identify any suspicious outbound connections that could suggest data exfiltration or command-and-control communication.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or if there are any active campaigns targeting similar vulnerabilities.
-
-### False positive analysis
-
-- System administrators or automated scripts may legitimately remove kernel modules during routine maintenance or updates, leading to false positives. Users can handle these by creating exceptions for known maintenance scripts or trusted administrator accounts.
-- Some security tools or monitoring solutions might remove kernel modules as part of their normal operation, which could trigger the rule. To manage this, users should identify and whitelist these specific tools or processes.
-- Development environments where kernel modules are frequently loaded and unloaded for testing purposes might also trigger false positives. Users can exclude these environments or specific user accounts from the rule to reduce noise.
-- In environments where custom scripts are used to manage kernel modules, these scripts might inadvertently trigger the rule. Users should review and, if necessary, modify the rule to exclude these scripts by adding them to an exception list based on their process names or paths.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the kernel module removal by checking user permissions and correlating with recent administrative activities.
-- Conduct a thorough investigation of the system logs to identify any unauthorized access or suspicious activities leading up to the module removal.
-- Utilize forensic tools to capture a snapshot of the current system state, including memory and disk images, for further analysis.
-- If unauthorized removal is confirmed, restore the affected kernel modules from a trusted backup or reinstall them using verified sources.
-- Review and update access controls and permissions to ensure only authorized personnel can modify kernel modules.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future monitoring.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.
-- Apply system hardening measures, such as disabling unnecessary kernel modules and enforcing strict module signing, to reduce the attack surface and prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_kthreadd_masquerading.toml b/rules/linux/defense_evasion_kthreadd_masquerading.toml
index 967852d22fb..af5551a5132 100644
--- a/rules/linux/defense_evasion_kthreadd_masquerading.toml
+++ b/rules/linux/defense_evasion_kthreadd_masquerading.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/02/01"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ as kthreadd and kworker typically do not have process.executable fields associat
 hide their malicious programs by masquerading as legitimate kernel processes.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Executable Masquerading as Kernel Process"
@@ -53,57 +55,16 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name : ("kworker*", "kthread*") and process.executable != null
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Executable Masquerading as Kernel Process
-
-In Linux environments, kernel processes like kthreadd and kworker are integral to system operations and typically lack associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes that have non-empty executable fields, indicating potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and executable path, focusing on the `process.name` and `process.executable` fields to verify if they match known kernel process names like "kworker" or "kthreadd".
-- Check the process start time and correlate it with any known legitimate system activities or updates that might have occurred around the same time.
-- Use Osquery to gather more information about the suspicious process. Execute a query such as: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name LIKE 'kworker%' OR name LIKE 'kthreadd%' AND path IS NOT NULL;` to list processes with kernel-like names and non-empty paths.
-- Investigate the parent process of the suspicious executable by examining the `process.parent` field to determine if it was spawned by a legitimate process or another suspicious one.
-- Analyze the command line arguments (`process.cmdline`) used to start the process to identify any unusual or unexpected parameters that could indicate malicious activity.
-- Check the file hash of the executable using a tool like `sha256sum` and compare it against known malware databases or threat intelligence feeds to identify any known malicious signatures.
-- Review system logs around the time of the process start event for any additional context or related suspicious activities, such as unauthorized access attempts or privilege escalation.
-- Investigate the user account (`process.user`) under which the process is running to determine if it has the necessary permissions and if the account has been involved in any suspicious activities.
-- Examine network connections initiated by the process using tools like `netstat` or `ss` to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
-- Cross-reference the findings with other security tools and logs, such as intrusion detection systems or endpoint protection solutions, to gather additional context and corroborate the suspicious activity.
-
-### False positive analysis
-
-- Some legitimate software or system updates may create processes with names similar to kernel processes, leading to false positives. Users should verify the source and legitimacy of such processes before taking action.
-- Custom scripts or administrative tools that mimic kernel process names for legitimate purposes can trigger alerts. Users can create exceptions for these known scripts by whitelisting their executable paths.
-- Certain monitoring or security tools may use kernel-like process names for internal operations. Users should consult with their IT or security teams to identify these tools and exclude them from the detection rule.
-- In environments with custom kernel modules or patches, legitimate processes might be named similarly to kernel processes. Users should document these customizations and adjust the detection rule to prevent unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening processes are excluded, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to confirm the masquerading attempt by analyzing the process tree and associated executable paths.
-- Terminate any suspicious processes that are masquerading as kernel processes to halt malicious activity.
-- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Restore the system by removing any malicious executables and ensuring all system files are intact and unaltered.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_ld_so_creation.toml b/rules/linux/defense_evasion_ld_so_creation.toml
index 95957a6245d..e7cda7b8898 100644
--- a/rules/linux/defense_evasion_ld_so_creation.toml
+++ b/rules/linux/defense_evasion_ld_so_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ file where host.os.type == "linux" and event.type == "creation" and process.exec
 file.path like~ ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and
 not process.name in ("dockerd", "yum", "dnf", "microdnf", "pacman")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Dynamic Linker (ld.so) Creation
-
-The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, bypassing security measures. The detection rule identifies suspicious creation of ld.so files, excluding legitimate processes, to flag potential threats and prevent system binary proxy execution abuses.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path matches the suspicious patterns ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and verify the event type is "creation".
-- Check the process that created the file by examining the `process.executable` field to determine if it is a known legitimate process or potentially malicious.
-- Investigate the `process.name` to ensure it is not one of the excluded legitimate processes such as "dockerd", "yum", "dnf", "microdnf", or "pacman".
-- Use Osquery to gather more information about the process that created the file. Example query: `SELECT * FROM processes WHERE pid = <process_id>;` where `<process_id>` is the ID of the process that triggered the alert.
-- Examine the parent process of the suspicious process to understand the process hierarchy and identify any potential anomalies or unexpected parent-child relationships.
-- Check the file metadata, including creation and modification timestamps, to determine if the timing aligns with any known legitimate activities or scheduled tasks.
-- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity is consistent with the user's typical behavior.
-- Review recent system logs and audit logs for any other suspicious activities or anomalies around the time of the file creation event.
-- Analyze network activity from the host to identify any unusual outbound connections or data transfers that may indicate malicious behavior.
-- Correlate the alert with other security events or alerts from the same host or network segment to identify potential patterns or coordinated attacks.
-
-### False positive analysis
-
-- Routine system updates or package installations may trigger the rule as package managers like `apt`, `yum`, or `dnf` could create or update the dynamic linker as part of their operations. These processes are generally safe and can be excluded by adding them to the exception list if they are not already included.
-- Custom scripts or administrative tasks that involve rebuilding or updating system libraries might also lead to the creation of ld.so files. If these scripts are verified as safe, their associated processes can be added to the exclusion list to prevent false positives.
-- Automated configuration management tools such as Ansible, Puppet, or Chef might deploy or update ld.so files as part of their configuration tasks. Users should verify these actions and consider excluding these tools from the detection rule if they are part of regular, secure operations.
-- Development environments where developers frequently compile and test new versions of system libraries may inadvertently trigger the rule. In such cases, it is advisable to exclude specific development processes or paths that are known to be safe.
-- To manage these false positives, users can regularly review and update the exclusion list in the detection rule to include any new legitimate processes that are identified during routine operations. This helps in maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the integrity of the dynamic linker (ld.so) by comparing it with a known good version from a trusted source or backup.
-- Conduct a thorough investigation to identify the source of the malicious ld.so creation, including reviewing logs and process execution history.
-- Remove the malicious ld.so file and replace it with a legitimate version from a trusted source.
-- Perform a comprehensive scan of the system for additional signs of compromise, such as unauthorized user accounts or other modified binaries.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and file creation events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying security patches, updating software, and ensuring all security configurations are hardened.
-- Educate users and administrators on the importance of monitoring system binaries and the risks associated with unauthorized modifications."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_log_files_deleted.toml b/rules/linux/defense_evasion_log_files_deleted.toml
index 6fd3f8eeed8..4004647cc05 100644
--- a/rules/linux/defense_evasion_log_files_deleted.toml
+++ b/rules/linux/defense_evasion_log_files_deleted.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -95,49 +95,6 @@ file where host.os.type == "linux" and event.type == "deletion" and
     ) and
     not process.name in ("gzip", "executor", "dockerd")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 System Log File Deletion
-
-System logs in Linux environments are crucial for monitoring and forensic analysis, capturing events like user logins and system errors. Adversaries may delete these logs to hide their tracks and evade detection. The detection rule identifies such deletions by monitoring specific log file paths and filtering out benign processes, thus alerting analysts to potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the specific log file path that was deleted and the timestamp of the event.
-- Check the process information associated with the deletion event, including the process ID, name, and user context, to identify any suspicious activity.
-- Use Osquery to list recent processes executed on the system that could be related to the deletion event. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
-- Investigate the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was compromised.
-- Examine other system logs for unusual activity around the time of the deletion, such as failed login attempts or unauthorized access.
-- Correlate the deletion event with any recent changes in system configuration or software installations that could explain the log file removal.
-- Check for any other alerts or indicators of compromise on the system that might suggest a broader attack or compromise.
-- Investigate network activity from the host around the time of the log deletion to identify any potential data exfiltration or command-and-control communication.
-- Review file integrity monitoring logs to determine if any other critical files were modified or deleted around the same time.
-- Consult threat intelligence sources to see if the observed behavior matches any known attack patterns or threat actor tactics.
-
-### False positive analysis
-
-- Routine system maintenance tasks or log rotation processes may trigger false positives, as these operations can involve the deletion of log files to manage disk space and ensure system performance.
-- Automated backup solutions might delete logs after archiving them, which could be misinterpreted as malicious activity.
-- Certain system updates or administrative scripts may also delete or rotate logs as part of their normal operation, leading to false alerts.
-- To manage these false positives, users can create exceptions for known benign processes involved in log management, such as logrotate or backup scripts, by adding them to the exclusion list in the detection rule.
-- Regularly review and update the exclusion list to include any new legitimate processes that are identified as part of routine system operations, ensuring that only genuine threats trigger alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
-- Conduct a thorough investigation to determine the scope of the log deletion, identifying any other compromised systems or accounts.
-- Review user activity and process execution logs to identify unauthorized access or suspicious behavior leading up to the log deletion.
-- Restore deleted log files from backups if available, to aid in the forensic investigation and maintain historical data integrity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to ensure critical logs are backed up regularly and stored securely, reducing the risk of future deletions.
-- Integrate additional security tools such as file integrity monitoring and endpoint detection and response (EDR) solutions to detect and alert on unauthorized file deletions.
-- Apply system hardening measures, including disabling unnecessary services, applying security patches, and enforcing least privilege access controls.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the importance of system logs and the potential impact of their deletion, promoting a culture of security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_mount_execution.toml b/rules/linux/defense_evasion_mount_execution.toml
index 8f267a1e94d..9d6d2c01c6b 100644
--- a/rules/linux/defense_evasion_mount_execution.toml
+++ b/rules/linux/defense_evasion_mount_execution.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/04/11"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +18,7 @@ hidepid option all the user has to do is remount the /proc filesystem with the o
 detected.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Hidden Process via Mount Hidepid"
@@ -57,58 +59,16 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-event.action in ("exec", "exec_event", "executed", "process_started") and
-process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and
-not process.parent.command_line like "/opt/cloudlinux/*"
+  event.action in ("exec", "exec_event", "start", "executed", "process_started") and
+  process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and
+  not process.parent.command_line like "/opt/cloudlinux/*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Hidden Process via Mount Hidepid
-
-The hidepid mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with hidepid=2, concealing their processes from system monitoring tools. The detection rule identifies such activity by monitoring for specific mount commands, excluding benign uses, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `mount` command with the `hidepid=2` option in the process arguments, as specified in the query.
-- Verify the user account associated with the `mount` command execution to determine if it aligns with expected administrative activity or if it appears suspicious.
-- Check the parent process of the `mount` command to understand the context of its execution and identify any potentially malicious parent processes.
-- Investigate the command history of the user who executed the `mount` command to identify any other suspicious activities or commands executed around the same time.
-- Use Osquery to list all current mounts and their options to verify if `/proc` is currently mounted with `hidepid=2`. Example query: `SELECT * FROM mounts WHERE path = '/proc' AND options LIKE '%hidepid=2%';`
-- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual login attempts or privilege escalation activities around the time of the alert.
-- Cross-reference the alert with any other security alerts or anomalies on the host to identify potential patterns or coordinated activities.
-- Check for any recent changes to user accounts or group memberships that might indicate unauthorized privilege escalation.
-- Review network activity logs for the host to identify any suspicious outbound connections or data exfiltration attempts that might correlate with the timing of the alert.
-- Consult with system administrators or the user associated with the alert to verify if the `hidepid=2` mount was part of a legitimate maintenance or configuration task.
-
-### False positive analysis
-
-- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons, such as enhancing user data protection on multi-user systems.
-- Cloud service providers or hosting environments might use hidepid=2 to prevent users from viewing other tenants' processes, which is a standard practice in shared environments.
-- Security tools or compliance frameworks could implement hidepid=2 as part of their hardening guidelines, leading to benign occurrences of this behavior.
-- To manage these false positives, users can create exceptions for known benign sources by excluding specific parent command lines or paths, such as "/opt/cloudlinux/*", or by whitelisting trusted administrative scripts and processes.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the presence of the hidepid=2 mount option by checking the current mount options for the /proc filesystem using the command `mount | grep /proc`.
-- If unauthorized use of hidepid=2 is confirmed, identify and terminate any suspicious processes that may be running under the hidden context.
-- Review system logs and process execution history to identify the source and timeline of the unauthorized mount command.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Restore the /proc filesystem to its default mount options by remounting it without the hidepid parameter using `mount -o remount,defaults /proc`.
-- Implement enhanced logging policies to capture detailed process execution and mount command activities for future investigations.
-- Integrate with security information and event management (SIEM) systems to automate detection and alerting of similar activities.
-- Apply system hardening measures, such as restricting mount command usage to authorized users and implementing least privilege access controls.
-- Conduct a post-incident review to update incident response plans and improve detection capabilities based on the findings from this incident."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_potential_proot_exploits.toml b/rules/linux/defense_evasion_potential_proot_exploits.toml
index 897f16a364a..d5a8be6b691 100644
--- a/rules/linux/defense_evasion_potential_proot_exploits.toml
+++ b/rules/linux/defense_evasion_potential_proot_exploits.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/03/07"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +20,7 @@ malicious payload or elevate privileges or perform network scans or orchestrate
 Although PRoot was originally not developed with malicious intent it can be easily tuned to work for one.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Defense Evasion via PRoot"
@@ -58,57 +60,16 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.parent.name == "proot"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Defense Evasion via PRoot
-
-PRoot is a tool that emulates a chroot-like environment, allowing users to run applications in a consistent environment across different Linux distributions. Adversaries exploit PRoot to bypass system defenses by running malicious payloads in a controlled environment. The detection rule identifies suspicious activity by monitoring processes initiated by PRoot, flagging potential misuse for defense evasion.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the PRoot process by checking the `process.parent.name` field for "proot" and ensure the `event.type` is "start" with `event.action` as "exec" or "exec_event".
-- Identify the user account associated with the PRoot process by examining the `user.name` field to determine if the activity is linked to a legitimate user or a potential adversary.
-- Investigate the command line arguments used with the PRoot process by analyzing the `process.command_line` field to understand the context and purpose of the execution.
-- Check the parent process of PRoot using the `process.parent.executable` field to identify how PRoot was initiated and assess if it was launched by a legitimate or suspicious process.
-- Use Osquery to list all processes running under the PRoot environment to identify any unusual or unauthorized applications. Example query: `SELECT pid, name, path FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'proot');`
-- Examine network connections established by processes running under PRoot using Osquery to detect any suspicious outbound connections. Example query: `SELECT pid, local_address, remote_address, remote_port FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'proot'));`
-- Analyze file system changes or access patterns by processes under PRoot to identify any unauthorized data access or modifications.
-- Review system logs for any additional context or anomalies around the time the PRoot process was initiated, focusing on authentication logs and system events.
-- Correlate the PRoot activity with other security alerts or incidents to determine if it is part of a larger attack campaign or isolated event.
-- Investigate the presence of any unusual or unauthorized binaries or scripts within the PRoot environment that could indicate malicious intent.
-
-### False positive analysis
-
-- Legitimate use of PRoot by developers or system administrators for testing or development purposes can trigger false positives. Users should identify and document these activities to differentiate them from malicious use.
-- Automated scripts or tools that utilize PRoot for legitimate cross-distribution compatibility testing may also be flagged. Implementing exceptions for known scripts or tools can help reduce unnecessary alerts.
-- Security researchers or penetration testers might use PRoot in controlled environments to simulate attacks or test defenses, which could be mistaken for malicious activity. Establishing a whitelist for these activities can prevent false alarms.
-- Some containerization or virtualization solutions might employ PRoot-like functionality for legitimate purposes. Users should verify the context of such processes and consider excluding them if they are part of approved software solutions.
-- Regular audits and reviews of flagged PRoot activities can help refine detection rules and improve the accuracy of alerts by excluding benign use cases.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any malicious payloads or processes running within the PRoot environment and terminate them.
-- Review system logs and PRoot usage history to determine the scope of the attack and identify any additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds to correlate PRoot activity with known threat actor tactics, techniques, and procedures (TTPs) for improved detection and response.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a known good backup, ensuring all malicious artifacts are removed.
-- Apply system hardening measures, such as disabling unnecessary services, applying security patches, and enforcing least privilege access controls.
-- Educate users and administrators on the risks associated with tools like PRoot and the importance of monitoring for unusual activity.
-- Regularly review and update security policies and procedures to address emerging threats and incorporate lessons learned from the incident."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_rename_esxi_files.toml b/rules/linux/defense_evasion_rename_esxi_files.toml
index 599d279d028..114e0492005 100644
--- a/rules/linux/defense_evasion_rename_esxi_files.toml
+++ b/rules/linux/defense_evasion_rename_esxi_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,52 +62,6 @@ file where host.os.type == "linux" and event.action == "rename" and
 file.Ext.original.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
 and not file.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Renaming of ESXI Files
-
-VMware ESXi files, crucial for virtual machine operations, can be targeted by adversaries aiming to disguise malicious activities. By renaming files like ".vmdk" or ".vmx", attackers may evade detection tools. The detection rule identifies such renaming events on Linux systems, flagging potential masquerading attempts by monitoring changes in file extensions, thus aiding in defense evasion detection.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file extensions involved in the renaming event, ensuring they match the specified VMware-related extensions such as ".vmdk", ".vmx", etc.
-- Verify the source and destination file names to understand the nature of the renaming and assess if the new file name appears suspicious or attempts to masquerade as a legitimate file.
-- Check the timestamp of the renaming event to determine if it coincides with any other suspicious activities or known attack timelines.
-- Investigate the user account associated with the renaming event to determine if it is a legitimate user or potentially compromised.
-- Examine the host where the renaming occurred to identify any other unusual activities or anomalies, such as unexpected processes or network connections.
-- Utilize Osquery to gather additional context about the file and system state. For example, run the following Osquery query to list recent file modifications on the host:
-  ```sql
-  SELECT * FROM file_events WHERE action = 'RENAME' AND path LIKE '%.vmdk' OR path LIKE '%.vmx' OR path LIKE '%.vmxf' OR path LIKE '%.vmsd' OR path LIKE '%.vmsn' OR path LIKE '%.vswp' OR path LIKE '%.vmss' OR path LIKE '%.nvram' OR path LIKE '%.vmem';
-  ```
-- Cross-reference the event with system logs to identify any correlated events, such as login attempts, privilege escalations, or other file operations around the same time.
-- Analyze network traffic logs from the host to detect any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
-- Check for any recent changes in system configurations or installed software that could indicate a broader compromise or persistence mechanism.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise (IOCs) related to VMware ESXi environments.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may rename VMware ESXi files during maintenance or migration activities, which can trigger the rule. To manage this, users can create exceptions for known administrative actions or specific time frames when such tasks are performed.
-- Backup operations: Automated backup processes might rename files as part of their operation, leading to false positives. Users can exclude backup-related processes or directories from the rule to reduce noise.
-- Software updates: Updates to VMware or related software might involve renaming files, which could be flagged by the rule. Users should consider excluding update processes or specific update directories to prevent unnecessary alerts.
-- Testing environments: In environments where frequent testing and development occur, file renaming might be a common practice. Users can create exceptions for specific test environments or user accounts to minimize false positives.
-- Custom scripts: Organizations may use custom scripts that rename VMware files for legitimate purposes. Identifying and excluding these scripts from the rule can help in reducing false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm the renaming event's legitimacy by reviewing logs and correlating with recent administrative activities.
-- If malicious activity is confirmed, identify and terminate any suspicious processes associated with the renamed files.
-- Restore any renamed VMware ESXi files to their original state using verified backups to ensure virtual machine integrity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed file operation events, including renaming actions, to improve future detection capabilities.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to identify and respond to similar threats more effectively.
-- Review and update access controls and permissions on VMware ESXi files to limit the ability to rename or modify them without proper authorization.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate and train staff on recognizing and reporting suspicious activities related to VMware ESXi files to enhance organizational awareness and readiness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_rename_esxi_index_file.toml b/rules/linux/defense_evasion_rename_esxi_index_file.toml
index 8e6b924a9cd..c9061d947da 100644
--- a/rules/linux/defense_evasion_rename_esxi_index_file.toml
+++ b/rules/linux/defense_evasion_rename_esxi_index_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,51 +61,6 @@ query = '''
 file where host.os.type == "linux" and event.action == "rename" and file.name : "index.html" and
 file.Ext.original.path : "/usr/lib/vmware/*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Renaming of ESXI index.html File
-
-In VMware ESXi environments, the `index.html` file is crucial for web-based management interfaces. Adversaries may rename this file to evade detection or to replace it with a malicious version, facilitating unauthorized access or data exfiltration. The detection rule identifies such renaming events by monitoring Linux systems for specific file operations within the VMware directory, flagging potential masquerading attempts.
-
-### Possible investigation steps
-
-- Verify the alert details, including the timestamp, to understand when the renaming event occurred.
-- Check the user account associated with the event to determine if it was an authorized user or a potential adversary.
-- Review the system logs around the time of the event for any additional suspicious activities or anomalies.
-- Use Osquery to list recent file modifications in the `/usr/lib/vmware/` directory to identify any other unauthorized changes:
-  ```sql
-  SELECT * FROM file WHERE path LIKE '/usr/lib/vmware/%' AND mtime > (SELECT strftime('%s', 'now') - 86400);
-  ```
-- Investigate the process that performed the renaming by correlating the event with process execution logs to identify the parent process and command line used.
-- Examine network logs for any unusual outbound connections from the host around the time of the event, which might indicate data exfiltration attempts.
-- Check for any recent privilege escalation events on the host that could have allowed an adversary to perform the renaming.
-- Review the file integrity monitoring logs to see if there are any other changes to critical files in the VMware directory.
-- Analyze the system for any signs of malware or rootkits that could have facilitated unauthorized access or file manipulation.
-- Cross-reference the event with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Routine maintenance or updates: During regular system updates or maintenance, the `index.html` file may be temporarily renamed as part of the update process. Users can handle this by creating exceptions for known maintenance windows or update scripts.
-- Customization by administrators: System administrators might rename the `index.html` file for legitimate customization purposes, such as implementing a custom login page. To manage this, users can whitelist specific administrator actions or paths where such customizations are expected.
-- Backup operations: Automated backup processes might rename the `index.html` file as part of their operation to prevent overwriting or to create versioned backups. Users can exclude these operations by identifying and allowing known backup scripts or tools.
-- Testing and development: In environments where testing or development occurs, the `index.html` file might be renamed frequently for testing purposes. Users can manage this by setting exceptions for specific development environments or user accounts involved in testing.
-
-### Response and remediation
-
-- Immediately isolate the affected ESXi host from the network to prevent further unauthorized access or data exfiltration.
-- Verify the integrity of the renamed index.html file by comparing it with a known good version to determine if it has been tampered with or replaced.
-- Conduct a thorough investigation to identify any unauthorized access or changes made to the system, focusing on recent user activities and file modifications.
-- Restore the original index.html file from a secure backup if it has been altered or replaced with a malicious version.
-- Review and update access controls and permissions for the VMware directory to ensure only authorized personnel have the ability to modify critical files.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems have been compromised.
-- Implement enhanced logging and monitoring for file operations within the VMware directory to detect similar activities in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and identify potential indicators of compromise.
-- Apply security patches and updates to the ESXi host and associated management interfaces to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans, incorporating lessons learned to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_root_certificate_installation.toml b/rules/linux/defense_evasion_root_certificate_installation.toml
index 2e6c7737c52..c462f2c7dab 100644
--- a/rules/linux/defense_evasion_root_certificate_installation.toml
+++ b/rules/linux/defense_evasion_root_certificate_installation.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/08/28"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +15,7 @@ in public key cryptography to identify a root certificate authority (CA). When a
 system or application will trust certificates in the root's chain of trust that have been signed by the root certificate.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*"]
+index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Root Certificate Installation"
@@ -52,11 +54,13 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.name in ("update-ca-trust", "update-ca-certificates") and not (
   process.parent.name like (
     "ca-certificates.postinst", "ca-certificates-*.trigger", "pacman", "pamac-daemon", "autofirma.postinst",
@@ -66,48 +70,6 @@ process.name in ("update-ca-trust", "update-ca-certificates") and not (
   (process.parent.name in ("sh", "bash", "zsh") and process.args == "-e")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Root Certificate Installation
-
-Root certificates are pivotal in establishing trust in digital communications, as they validate the authenticity of other certificates in a chain. Adversaries may exploit this by installing rogue root certificates on Linux systems, thus bypassing security warnings and facilitating undetected communication with malicious servers. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and parent process name involved in the root certificate installation attempt.
-- Verify the legitimacy of the process by checking the command line arguments and execution context, focusing on the `process.name` and `process.parent.name` fields.
-- Investigate the parent process to determine if it is a known and trusted application or script, using the `process.parent.args` field for additional context.
-- Check the user account associated with the process execution to determine if it aligns with expected behavior for root certificate installations.
-- Use Osquery to list all installed root certificates and their details to identify any recent or suspicious additions. Example query: `SELECT * FROM certificates WHERE common_name LIKE '%<suspicious_common_name>%' OR issuer LIKE '%<suspicious_issuer>%';`
-- Examine system logs for any related activities or anomalies around the time of the alert to gather more context on the event.
-- Cross-reference the alert with any recent changes or updates to the system that might explain the certificate installation.
-- Investigate network connections from the host to identify any unusual or unauthorized communication with external servers.
-- Review any recent user activity or access logs to determine if there were any unauthorized access attempts or privilege escalations.
-- Consult threat intelligence sources to check if the certificate or associated processes are linked to known malicious activities or threat actors.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they involve updating root certificates, such as during system updates or package installations. These processes often use "update-ca-trust" or "update-ca-certificates" but are typically initiated by trusted parent processes.
-- System administrators or automated scripts performing routine maintenance or configuration changes might also cause false positives. These activities are generally benign and can be identified by their consistent patterns or known parent processes.
-- To manage these false positives, users can create exceptions for specific parent processes or command-line arguments that are known to be safe. This can be done by adding these processes to the exclusion list in the detection rule, ensuring that only truly suspicious activities are flagged.
-- Monitoring the frequency and context of the alerts can help in distinguishing between legitimate and malicious activities. If a particular process frequently triggers the rule but is verified as safe, it can be added to the exclusion criteria to reduce noise.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further communication with potential malicious servers.
-- Conduct a thorough investigation to identify any unauthorized root certificates installed on the system and remove them.
-- Review system logs and process execution history to trace the origin of the unauthorized certificate installation and identify any other compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future unauthorized certificate installations are detected promptly.
-- Integrate threat intelligence feeds to correlate the incident with known threat actors or campaigns, leveraging MITRE ATT&CK framework details for context.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all unauthorized changes are removed.
-- Apply system hardening measures, such as restricting certificate installation permissions and implementing application whitelisting to prevent unauthorized software execution.
-- Conduct a security awareness training session for users and administrators to recognize and report suspicious activities related to certificate management.
-- Regularly review and update security policies and procedures to address gaps identified during the incident response and ensure robust defenses against similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
index cf48ddcf05f..46d5a10dc28 100644
--- a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
+++ b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.16.2 for the SentinelOne Integration."
 min_stack_version = "8.16.2"
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -62,50 +62,6 @@ query = '''
 file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event")
 and file.path : "/etc/selinux/config"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SELinux Configuration Creation or Renaming
-
-SELinux is a Linux kernel security module that enforces access control policies to protect systems from unauthorized access. Adversaries may attempt to modify or rename the SELinux configuration file to weaken these defenses, facilitating unauthorized actions. The detection rule identifies such suspicious activities by monitoring file creation or renaming events specifically targeting the SELinux configuration path, signaling potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event action is either "creation", "file_create_event", "rename", or "file_rename_event" and the file path is "/etc/selinux/config".
-- Check the timestamp of the event to determine when the SELinux configuration file was created or renamed.
-- Identify the user account and process responsible for the file creation or renaming by examining the event's user and process fields.
-- Investigate the command history of the identified user around the time of the event to find any suspicious commands using `history` or `bash_history`.
-- Use Osquery to gather more context about the process that triggered the event with a query like: `SELECT * FROM processes WHERE pid = <process_id>;`.
-- Examine the system logs, such as `/var/log/audit/audit.log` or `/var/log/secure`, for any related entries that might provide additional context or corroborate the event.
-- Check for any recent changes in user privileges or group memberships that might have allowed unauthorized access to modify SELinux configurations.
-- Investigate other recent file modifications in the `/etc/selinux/` directory to identify any additional unauthorized changes.
-- Review network logs for any unusual outbound connections from the host around the time of the event, which might indicate data exfiltration or command-and-control activity.
-- Correlate this event with other security alerts or anomalies on the same host to determine if it is part of a broader attack campaign.
-
-### False positive analysis
-
-- Routine system updates or administrative tasks may trigger the rule if SELinux configurations are updated or modified as part of legitimate maintenance activities. 
-- Automated configuration management tools like Ansible, Puppet, or Chef might modify the SELinux configuration file as part of their normal operations, leading to false positives.
-- System administrators may intentionally rename or create SELinux configuration files during troubleshooting or system hardening processes, which could be misinterpreted as suspicious activity.
-- To manage these false positives, users can create exceptions for known and trusted processes or users that regularly interact with the SELinux configuration file.
-- Implementing a whitelist of approved scripts or tools that are allowed to modify the SELinux configuration can help reduce noise from legitimate activities.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the integrity of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
-- Verify the integrity of the SELinux configuration file by comparing it with a known good backup or baseline to identify unauthorized changes.
-- Conduct a thorough investigation to determine the source and method of the modification, checking for any signs of compromise or unauthorized access.
-- Review system logs and security alerts to identify any related suspicious activities or indicators of compromise.
-- Restore the SELinux configuration file from a trusted backup if unauthorized changes are detected, and ensure SELinux is re-enabled and configured correctly.
-- Escalate the incident to the security operations team or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for SELinux-related activities to detect future unauthorized modifications promptly.
-- Integrate security tools with SIEM solutions to improve visibility and correlation of security events related to SELinux and other critical configurations.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Apply system hardening measures, such as restricting access to configuration files and enforcing least privilege principles, to reduce the risk of future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_ssl_certificate_deletion.toml b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
index 32c0e464493..861b9a5dd90 100644
--- a/rules/linux/defense_evasion_ssl_certificate_deletion.toml
+++ b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ query = '''
 file where host.os.type == "linux" and event.type == "deletion" and file.path : "/etc/ssl/certs/*" and
 file.extension in ("pem", "crt") and not process.name in ("dockerd", "pacman")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SSL Certificate Deletion
-
-SSL certificates are crucial for establishing secure communications in Linux environments, ensuring data integrity and trust. Adversaries may delete these certificates to bypass security controls, leading to potential data breaches or system compromise. The detection rule identifies suspicious deletions by monitoring specific directories and file types, excluding benign processes, thus highlighting potential malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path and extension involved in the deletion, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt".
-- Check the process name that triggered the deletion event to verify it is not one of the excluded benign processes like "dockerd" or "pacman".
-- Investigate the user account associated with the deletion event to determine if it is a legitimate user or potentially compromised.
-- Examine the process execution history on the host to identify any unusual or unauthorized processes that may have led to the certificate deletion.
-- Use Osquery to list all current SSL certificates in the "/etc/ssl/certs/" directory to assess the extent of the deletion. Example query: `SELECT * FROM file WHERE directory = '/etc/ssl/certs' AND (path LIKE '%.pem' OR path LIKE '%.crt');`
-- Analyze recent system logs for any signs of unauthorized access or other suspicious activities around the time of the certificate deletion.
-- Correlate the deletion event with any recent changes or updates in the system that might explain the certificate removal.
-- Investigate network logs to identify any unusual outbound connections that might suggest data exfiltration or communication with a command and control server.
-- Review any recent alerts or incidents on the same host to identify patterns or related activities that could indicate a broader attack.
-- Consult with system administrators or relevant personnel to verify if the certificate deletion was part of a planned maintenance or update activity.
-
-### False positive analysis
-
-- Routine system updates or maintenance tasks may trigger false positives, especially if they involve the removal or replacement of SSL certificates. Users can manage these by identifying and excluding specific update processes or maintenance scripts from the detection rule.
-- Automated certificate renewal processes, such as those used by Let's Encrypt, might delete old certificates as part of their renewal cycle. To handle this, users should identify the renewal process and add it to the list of excluded processes.
-- Custom scripts or applications that manage SSL certificates for legitimate purposes could also be flagged. Users should review these scripts and, if deemed safe, add them to the exclusion list to prevent unnecessary alerts.
-- In environments where containers are frequently created and destroyed, SSL certificates might be deleted as part of container lifecycle management. Users can exclude specific container management processes, like those related to Kubernetes or Docker, to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Verify the deletion of SSL certificates by checking the system logs and correlating with the detection rule to confirm malicious activity.
-- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls.
-- Conduct a thorough investigation to identify the source of the deletion, focusing on unauthorized access or compromised accounts.
-- Review and update access controls and permissions to ensure only authorized users and processes can modify SSL certificates.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed file access and modification events, including process and user information.
-- Integrate with security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing strong authentication mechanisms.
-- Educate users and administrators on the importance of SSL certificates and the potential impact of their unauthorized deletion."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
index 744d058aeed..86b5173a792 100644
--- a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
+++ b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/09/04"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ directly, the commands will be executed in the background via its parent process
 to execute commands while attempting to evade detection.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potentially Suspicious Process Started via tmux or screen"
@@ -26,59 +28,19 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
-process.parent.name in ("screen", "tmux") and process.name like (
-  "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*",
-  "openssl", "telnet", "wget", "curl", "id"
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
+  process.parent.name in ("screen", "tmux") and process.name like (
+    "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*",
+    "openssl", "telnet", "wget", "curl", "id"
+  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potentially Suspicious Process Started via tmux or screen
-
-Tmux and screen are terminal multiplexers that allow users to manage multiple terminal sessions from a single window, enhancing productivity in Linux environments. However, adversaries can exploit these tools to execute commands stealthily, detaching sessions to run processes in the background. The detection rule identifies suspicious activity by monitoring for specific command executions initiated by tmux or screen, focusing on processes often associated with malicious behavior.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and parent process involved, focusing on the `process.name` and `process.parent.name` fields.
-- Check the timestamp of the event to determine when the suspicious process was started, using the `event.start` field.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior, using the `user.name` field.
-- Examine the command line arguments used in the process execution to identify any potentially malicious or unusual commands, using the `process.command_line` field.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'nmap' OR name = 'nc' OR name = 'curl';` to identify any related processes running on the system.
-- Check the network connections established by the suspicious process to identify any unusual or unauthorized connections, using the `process.network` field.
-- Review the process's parent-child relationship to understand the process hierarchy and identify any other potentially suspicious processes, using the `process.parent_pid` and `process.pid` fields.
-- Investigate the system logs for any other suspicious activities or anomalies around the time of the alert to gather additional context.
-- Analyze the file system for any new or modified files that may be associated with the suspicious process, using file integrity monitoring tools.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign.
-
-### False positive analysis
-
-- System administrators and developers often use tmux or screen to run legitimate processes in the background for maintenance or development purposes, such as running scripts or monitoring tools, which may trigger the rule.
-- Automated scripts or cron jobs that utilize tmux or screen to execute routine tasks like backups, updates, or network monitoring can be mistakenly flagged as suspicious.
-- Security tools or network diagnostic utilities that are legitimately used for troubleshooting or performance testing, such as nmap or curl, may be executed via tmux or screen, leading to false positives.
-- To manage these false positives, users can create exceptions for known benign processes by adding specific command patterns or user accounts to an allowlist, ensuring that routine administrative tasks are not flagged.
-- Implementing a review process for flagged events can help differentiate between legitimate and suspicious activities, allowing security teams to refine detection rules and reduce false positives over time.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on the processes initiated by tmux or screen and any associated suspicious commands.
-- Terminate any malicious processes identified during the investigation to stop ongoing threats.
-- Review system logs and command histories to gather evidence and understand the attack vector and timeline.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed command execution and process creation events, ensuring future suspicious activities are detected promptly.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and correlate alerts with known threat actors or tactics.
-- Restore the system to its operational state by applying patches, updating software, and ensuring all security configurations are in place.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting the use of terminal multiplexers to authorized users only and employing least privilege principles to minimize potential attack surfaces."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_unusual_preload_env_vars.toml b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
index 2230a1f7f32..06cc415ae7d 100644
--- a/rules/linux/defense_evasion_unusual_preload_env_vars.toml
+++ b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/16"
 
 [rule]
 author = ["Elastic"]
@@ -70,52 +70,6 @@ type = "new_terms"
 query = '''
 event.category:process and host.os.type:linux and event.type:start and event.action:exec and process.env_vars:*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Preload Environment Variable Process Execution
-
-In Linux environments, preload environment variables like `LD_PRELOAD` allow users to load shared libraries before others, altering process behavior. Adversaries exploit this by injecting malicious libraries to hijack execution flow. The detection rule identifies processes with uncommon environment variables, signaling potential misuse for defense evasion and execution hijacking.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and environment variables involved, focusing on `process.env_vars` to understand which variables are uncommon.
-- Examine the process command line (`process.command_line`) to gather more context about the executed process and its intended function.
-- Check the parent process (`process.parent.name`) to determine if the process was spawned by a legitimate or suspicious parent, which might indicate a compromise.
-- Investigate the user account (`user.name`) associated with the process execution to assess if the account is legitimate and if it has been involved in any other suspicious activities.
-- Use Osquery to list all processes with their environment variables to identify any other processes with unusual preload variables:
-  ```sql
-  SELECT pid, name, path, cmdline, environ FROM processes WHERE environ LIKE '%LD_PRELOAD%';
-  ```
-- Analyze the loaded libraries (`process.loaded_libraries`) to identify any unfamiliar or suspicious libraries that could be injected for malicious purposes.
-- Cross-reference the hash of the suspicious libraries or binaries with threat intelligence databases to check for known malicious signatures.
-- Review recent login events and user activity (`event.category:authentication`) to identify any unauthorized access attempts that might correlate with the process execution.
-- Check for any recent changes to the system's shared libraries or binaries that could indicate tampering or unauthorized modifications.
-- Investigate network connections (`network.connection`) initiated by the process to identify any suspicious outbound connections that could suggest data exfiltration or command-and-control communication.
-
-### False positive analysis
-
-- Some legitimate applications may use uncommon environment variables for performance optimization or debugging purposes, which could trigger this rule. Users should identify these applications and consider them for exclusion if they are verified as non-threatening.
-- Development environments often set unique environment variables for testing and debugging, which might be flagged by this rule. Developers should document these variables and create exceptions for known safe processes.
-- System administrators might use custom scripts that set unusual environment variables for system maintenance tasks. These should be reviewed and, if deemed safe, added to an exception list to prevent false alerts.
-- Security tools and monitoring solutions sometimes use specific environment variables to function correctly. It's important to verify these tools and exclude their processes from the rule to avoid unnecessary alerts.
-- Users can manage false positives by maintaining a whitelist of known safe environment variables and associated processes, regularly updating this list as new legitimate use cases are identified.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the malicious library or binary loaded via the `LD_PRELOAD` or other unusual environment variables.
-- Review process execution logs and environment variables to determine the scope of the compromise and identify any other affected systems.
-- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
-- Remove or quarantine the identified malicious libraries or binaries from the system to prevent re-execution.
-- Restore the system from a known good backup if the integrity of the system is in question and ensure all patches and updates are applied.
-- Implement enhanced logging policies to capture detailed process execution and environment variable changes for future investigations.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to monitor and alert on unusual process behaviors and environment variable usage.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Review and update security policies and hardening measures, such as restricting the use of environment variables like `LD_PRELOAD` to trusted users and applications only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml
index 52a4692553b..cb335926989 100644
--- a/rules/linux/discovery_dynamic_linker_via_od.toml
+++ b/rules/linux/discovery_dynamic_linker_via_od.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/02/01"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +15,7 @@ for examining and debugging binary files or data streams. Attackers can leverage
 identifying injection points and craft exploits based on the observed behaviors and structures within these files.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Dynamic Linker Discovery via od"
@@ -55,61 +57,19 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "od" and process.args in (
   "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/etc/ld.so.preload", "/lib64/ld-linux-x86-64.so.2",
   "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Dynamic Linker Discovery via od
-
-The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Adversaries may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker paths, flagging potential reconnaissance activities aimed at exploiting dynamic linker mechanisms.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "od" and verify the specific arguments used, such as "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2" or other linker paths listed in the query.
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time.
-- Identify the user account associated with the process execution to determine if it aligns with expected behavior or if it might be a compromised account.
-- Investigate the parent process of "od" to understand how it was initiated and whether it was part of a legitimate workflow or a potential attack chain.
-- Use Osquery to gather additional context about the process. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'od' LIMIT 1);`
-- Examine system logs for any unusual activity or errors around the time of the alert that might indicate tampering or exploitation attempts.
-- Check for any recent changes to the dynamic linker files or related configuration files, such as "/etc/ld.so.preload", to identify unauthorized modifications.
-- Review network activity logs to detect any outbound connections or data exfiltration attempts that might coincide with the suspicious process execution.
-- Investigate other alerts or anomalies involving the same host to determine if this is part of a broader attack pattern or isolated incident.
-- Consult threat intelligence sources to see if there are any known campaigns or adversaries that use similar techniques, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- System administrators or developers may use the `od` utility to legitimately inspect dynamic linker files for debugging or system maintenance purposes, leading to false positives. 
-- Automated scripts or monitoring tools that perform regular checks on system files, including dynamic linkers, might trigger the rule unintentionally.
-- Security audits or compliance checks that involve examining system binaries and linkers could also result in false positives.
-- To manage these false positives, users can create exceptions for known benign activities by whitelisting specific user accounts or processes that regularly perform these actions.
-- Implementing a baseline of normal system behavior can help differentiate between legitimate use and potential threats, allowing for more accurate filtering of alerts.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening activities are excluded from triggering the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
-- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing logs and correlating with other security events.
-- Analyze the process tree and command-line arguments to understand the scope and intent of the suspicious `od` usage.
-- If confirmed malicious, terminate any unauthorized processes and remove any malicious files or scripts identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging for process execution and file access, focusing on critical system paths and binaries.
-- Integrate threat intelligence feeds to correlate with known indicators of compromise related to dynamic linker exploitation.
-- Restore the system to a known good state using backups or system snapshots, ensuring all patches and updates are applied.
-- Conduct a post-incident review to identify gaps in detection and response, updating security policies and procedures accordingly.
-- Implement hardening measures such as restricting access to critical system files, enforcing least privilege, and using application whitelisting."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml
index fef13f050c7..b5f479b5766 100644
--- a/rules/linux/discovery_esxi_software_via_find.toml
+++ b/rules/linux/discovery_esxi_software_via_find.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/04/11"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +15,7 @@ software, and their presence in the find command arguments may indicate that a t
 analyze, or manipulate VM-related files and configurations on the system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "ESXI Discovery via Find"
@@ -56,58 +58,16 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-event.action in ("exec", "exec_event", "executed", "process_started") and process.name == "find" and
-process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and 
-not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
+  event.action in ("exec", "exec_event", "start", "executed", "process_started") and
+  process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and 
+  not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 ESXI Discovery via Find
-
-VMware ESXi is a hypervisor used to manage virtual machines (VMs) on physical servers. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather intelligence or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the 'find' command was executed on a Linux system, focusing on the 'process.name' and 'process.args' fields to verify the targeted VMware paths.
-- Check the 'process.parent.executable' field to ensure the command was not initiated by a legitimate process like "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh".
-- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks.
-- Examine the 'host.os.type' and 'event.type' fields to confirm the environment and context in which the command was executed.
-- Use Osquery to list all running processes related to VMware to identify any unusual or unauthorized activities. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/usr/lib/vmware/%' OR path LIKE '/etc/vmware/%';`
-- Analyze system logs around the time of the alert to identify any other suspicious activities or commands executed by the same user or process.
-- Check for any recent changes or anomalies in the VMware configuration files located in the targeted paths to assess potential tampering or reconnaissance.
-- Investigate network logs for any unusual outbound connections from the host that might indicate data exfiltration or communication with a command and control server.
-- Review historical data to determine if similar 'find' command executions have occurred in the past, indicating a pattern or ongoing reconnaissance activity.
-- Correlate the alert with other security events or alerts from the same host or user to build a comprehensive picture of the potential threat actor's activities.
-
-### False positive analysis
-
-- System administrators or automated scripts may use the 'find' command to perform legitimate maintenance tasks, such as searching for configuration files or performing backups, which could trigger the rule.
-- Regular updates or installations of VMware software might involve the 'find' command to verify file integrity or locate specific files, leading to false positives.
-- Monitoring or security tools that scan directories for compliance or security checks might execute the 'find' command on VMware paths as part of their routine operations.
-- To manage these false positives, users can create exceptions for known benign processes or scripts by adding their parent executable paths to the exclusion list, similar to the existing exclusion for "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh".
-- Users should regularly review and update the exclusion list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats while reducing noise from false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the activity, including reviewing logs and identifying any other systems that may have been targeted.
-- Analyze the 'find' command usage to confirm whether it was executed by a legitimate user or process, or if it indicates malicious activity.
-- If malicious activity is confirmed, remove any unauthorized accounts or processes identified during the investigation.
-- Restore the system from a known good backup to ensure that any potential malicious changes are reverted.
-- Implement enhanced logging policies to capture detailed process execution data, focusing on command-line arguments and parent-child process relationships.
-- Integrate security solutions such as SIEM or EDR to improve detection capabilities and automate alerting for suspicious activities.
-- Review and update access controls and permissions on VMware-related directories to limit exposure to unauthorized users.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of maintaining security hygiene."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml
index 6863405a28a..ab1ce5793f0 100644
--- a/rules/linux/discovery_esxi_software_via_grep.toml
+++ b/rules/linux/discovery_esxi_software_via_grep.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/04/11"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +15,7 @@ related to virtual machine (VM) files, such as "vmdk", "vmx", "vmxf", "vmsd", "v
 may indicate that a threat actor is attempting to search for, analyze, or manipulate VM files on the system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "ESXI Discovery via Grep"
@@ -56,60 +58,17 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-event.action in ("exec", "exec_event", "executed", "process_started") and
-process.name in ("grep", "egrep", "pgrep") and
-process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and
-not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init"
+  event.action in ("exec", "exec_event", "start", "executed", "process_started") and
+  process.name in ("grep", "egrep", "pgrep") and
+  process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and
+  not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 ESXI Discovery via Grep
-
-In virtualized environments, ESXi hosts manage VM files with specific extensions. Adversaries may exploit tools like grep to locate these files, aiming to gather intelligence or manipulate VMs. The detection rule identifies suspicious grep usage targeting VM file extensions, excluding legitimate processes, to flag potential threats. This helps in early detection of unauthorized VM file access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is one of "grep", "egrep", or "pgrep" and verify the presence of VM-related file extensions in the process arguments.
-- Check the process's parent executable to ensure it is not "/usr/share/qemu/init/qemu-kvm-init", which is excluded from the rule, to rule out false positives.
-- Investigate the user account associated with the process to determine if it is a known and authorized user for accessing VM files.
-- Examine the command line history for the user to identify any other suspicious commands executed around the same time as the alert.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with VM-related arguments: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%vmdk%' OR cmdline LIKE '%vmx%' OR cmdline LIKE '%vmxf%' OR cmdline LIKE '%vmsd%' OR cmdline LIKE '%vmsn%' OR cmdline LIKE '%vswp%' OR cmdline LIKE '%vmss%' OR cmdline LIKE '%nvram%' OR cmdline LIKE '%vmem%';`
-- Analyze network activity from the host to identify any unusual connections or data transfers that may indicate exfiltration or further reconnaissance.
-- Review system logs for any other anomalies or related events that occurred before or after the alert to build a timeline of activities.
-- Check for any recent changes to VM files on the system, such as modifications or deletions, that could indicate tampering.
-- Investigate any other alerts or incidents involving the same host or user to determine if this is part of a broader attack pattern.
-- Consult with the system owner or administrator to verify if the activity was authorized or part of a legitimate maintenance task.
-
-### False positive analysis
-
-- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. These legitimate activities can trigger the detection rule, leading to false positives.
-- Backup or snapshot management processes might involve searching for VM file extensions to ensure data integrity or to verify backup completion, which can also be mistakenly flagged.
-- Developers or IT personnel conducting audits or inventory checks on virtual environments may use grep to locate VM files, resulting in non-malicious alerts.
-- To manage these false positives, users can create exceptions for known legitimate processes by excluding specific parent processes or scripts that regularly perform these actions.
-- Implementing a whitelist of trusted users or service accounts that frequently interact with VM files can help reduce unnecessary alerts.
-- Regularly review and update the exclusion list to accommodate changes in legitimate operational procedures, ensuring that only genuine threats are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the presence of unauthorized grep usage by reviewing process execution logs and correlating with other security events.
-- If unauthorized access is confirmed, identify and terminate any malicious processes running on the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Review and enhance logging policies to ensure comprehensive monitoring of process execution and file access activities, focusing on VM-related files.
-- Implement additional security controls, such as file integrity monitoring and access controls, to protect VM files from unauthorized access.
-- Restore the system to its operational state by applying the latest security patches and updates, and verifying the integrity of VM files.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate system administrators and users on recognizing and reporting suspicious activities related to VM file access.
-- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to enhance detection and response capabilities for similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_kernel_module_enumeration.toml b/rules/linux/discovery_kernel_module_enumeration.toml
index 7949a743899..e57a6d27d55 100644
--- a/rules/linux/discovery_kernel_module_enumeration.toml
+++ b/rules/linux/discovery_kernel_module_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -75,52 +75,6 @@ not (
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Enumeration of Kernel Modules
-
-Loadable Kernel Modules (LKMs) enhance a Linux kernel's capabilities dynamically, without requiring a system reboot. Adversaries may exploit this by enumerating kernel modules to gather system information or identify vulnerabilities. The detection rule identifies suspicious enumeration activities by monitoring specific processes and arguments associated with module listing, while excluding legitimate system processes to reduce false positives.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
-- Check the `event.category` and `event.type` fields to confirm the nature of the event and ensure it aligns with a process start event.
-- Investigate the `process.parent.name` to determine if the parent process is one of the excluded legitimate system processes, which might indicate a false positive.
-- Examine the user account associated with the process execution to determine if it is a privileged or unprivileged account, which can provide context on the potential risk.
-- Use Osquery to list currently loaded kernel modules and compare them with the modules listed in the alert to identify any discrepancies or unusual modules:
-  ```sql
-  SELECT * FROM kernel_modules;
-  ```
-- Analyze the system logs around the time of the alert to identify any other suspicious activities or related events that might provide additional context.
-- Check for any recent changes or updates to the system that might have triggered legitimate module enumeration, such as system updates or configuration changes.
-- Investigate the network activity of the host to identify any potential data exfiltration or communication with known malicious IP addresses.
-- Review historical data to determine if similar enumeration activities have been observed on the host or across the network, which might indicate a pattern or ongoing reconnaissance.
-- Consult threat intelligence sources to check if the specific process names or arguments used in the alert are associated with known adversary techniques or campaigns.
-
-### False positive analysis
-
-- Legitimate system processes or administrative scripts may trigger the rule if they perform kernel module enumeration as part of routine operations, such as system updates or hardware checks.
-- Automated maintenance tasks, like those executed by configuration management tools (e.g., Ansible, Puppet, Chef), might also cause false positives if they include module listing commands.
-- Security monitoring or auditing tools that check system configurations and module statuses could inadvertently match the rule's criteria.
-- Users can manage these false positives by creating exceptions for known benign processes or scripts that frequently trigger the rule, ensuring they are added to the exclusion list in the detection logic.
-- Regularly review and update the exclusion list to accommodate new legitimate processes that may arise from system updates or changes in administrative practices.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the source and intent of the kernel module enumeration, checking for any unauthorized access or privilege escalation attempts.
-- Review system logs and security alerts to identify any other suspicious activities or anomalies that may indicate a broader compromise.
-- If malicious activity is confirmed, remove any unauthorized kernel modules and restore the system to a known good state using backups or system snapshots.
-- Update and patch the system to address any identified vulnerabilities that may have been exploited during the attack.
-- Implement enhanced logging policies to capture detailed process execution and module loading activities for future investigations.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining system security and vigilance.
-- Consider hardening measures such as disabling unnecessary kernel modules, implementing strict access controls, and using security-enhanced Linux (SELinux) or AppArmor to enforce security policies."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_linux_hping_activity.toml b/rules/linux/discovery_linux_hping_activity.toml
index d46985c63ec..526bdb48d37 100644
--- a/rules/linux/discovery_linux_hping_activity.toml
+++ b/rules/linux/discovery_linux_hping_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2020/02/18"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +19,7 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Hping Process Activity"
@@ -70,57 +72,17 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name in ("hping", "hping2", "hping3")
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name in ("hping", "hping2", "hping3")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Hping Process Activity
-
-Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies the initiation of Hping processes on Linux systems, flagging potential misuse by monitoring specific process events and names associated with Hping.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name matches "hping", "hping2", or "hping3" and verify the event type is "start" with actions like "exec", "exec_event", "executed", or "process_started".
-- Check the timestamp of the event to determine when the Hping process was initiated and correlate it with any other suspicious activities around the same time.
-- Identify the user account under which the Hping process was executed to assess if it aligns with expected behavior or if it indicates potential misuse.
-- Investigate the parent process of the Hping activity to understand how it was initiated and if it was spawned by a legitimate or suspicious process.
-- Examine the command-line arguments used with the Hping process to determine the specific actions it was attempting to perform, such as network scanning or probing.
-- Utilize Osquery to gather additional context about the Hping process by running a query like: `SELECT * FROM processes WHERE name IN ('hping', 'hping2', 'hping3');` to retrieve detailed process information.
-- Analyze network logs to identify any unusual outbound or inbound traffic patterns that coincide with the Hping process execution, indicating potential reconnaissance activity.
-- Cross-reference the host's recent login history and user activity to identify any unauthorized access attempts or anomalies that could be related to the Hping execution.
-- Review system logs for any error messages or warnings that occurred around the time of the Hping process start, which might provide additional context or indicators of compromise.
-- Investigate any other alerts or detections from the same host or user account to determine if the Hping activity is part of a broader attack pattern or isolated incident.
-
-### False positive analysis
-
-- Legitimate network administrators and security professionals may use Hping for authorized network testing and diagnostics, leading to false positives when these activities are part of routine security assessments or troubleshooting.
-- Automated scripts or scheduled tasks that include Hping for regular network health checks or performance monitoring can trigger alerts, even though they are non-malicious in nature.
-- To manage these false positives, users can create exceptions or exclusions in the detection rule for specific users, IP addresses, or time frames that are known to perform legitimate Hping activities.
-- Implementing a whitelist of trusted processes or users who are authorized to use Hping can help reduce unnecessary alerts while maintaining security oversight.
-- Regularly review and update the list of exceptions to ensure that only verified and necessary activities are excluded from triggering alerts, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary.
-- Conduct a thorough investigation to determine the scope of the activity, including reviewing logs and process trees to identify any additional suspicious behavior or related processes.
-- Terminate any unauthorized Hping processes running on the system to halt any ongoing reconnaissance activities.
-- Analyze network traffic logs to identify any unusual outbound connections or data exfiltration attempts that may have occurred during the Hping activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future Hping or similar activities are detected promptly.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to improve detection capabilities for reconnaissance and discovery tactics.
-- Restore the system to its operational state by applying any necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address any deficiencies discovered during the investigation.
-- Implement system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface and mitigate the risk of future misuse of tools like Hping."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_linux_nping_activity.toml b/rules/linux/discovery_linux_nping_activity.toml
index df3fb9a26d9..5d217c0f4fb 100644
--- a/rules/linux/discovery_linux_nping_activity.toml
+++ b/rules/linux/discovery_linux_nping_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2020/02/18"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +19,7 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Nping Process Activity"
@@ -70,55 +72,17 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name == "nping"
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name == "nping"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Nping Process Activity
-Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by probing network services. The detection rule identifies Nping execution on Linux systems by monitoring process initiation events, helping to flag potential misuse aligned with network discovery tactics.
-
-### Possible investigation steps
-
-- Verify the alert by checking the process initiation event details, focusing on the `process.name` field to confirm it is indeed "nping".
-- Examine the `host.os.type` field to ensure the alert pertains to a Linux system, as expected.
-- Review the `event.type` and `event.action` fields to confirm the process was started and executed, ensuring the alert is not a false positive.
-- Investigate the user account associated with the `process` to determine if the execution was authorized or expected.
-- Check the parent process of the Nping execution to understand how it was initiated and if it was part of a larger script or automated task.
-- Use Osquery to gather more context on the Nping process by running a query such as: `SELECT * FROM processes WHERE name = 'nping';` to retrieve details like process ID, user, and command line arguments.
-- Analyze the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or options that indicate reconnaissance or denial-of-service activities.
-- Review network logs and traffic patterns around the time of the Nping execution to identify any unusual or suspicious network activity that correlates with the alert.
-- Cross-reference the alert with other security events or logs to identify if there are any related activities or patterns, such as multiple reconnaissance attempts or other suspicious processes.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that commonly use Nping in their operations, providing additional context to the alert.
-
-### False positive analysis
-
-- Routine network diagnostics: System administrators may use Nping for legitimate network diagnostics and performance testing, which can trigger the detection rule. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform regular diagnostics.
-- Security testing by authorized personnel: Security teams might employ Nping as part of scheduled vulnerability assessments or penetration testing. Users can handle these false positives by excluding processes initiated by designated security team accounts or during predefined testing windows.
-- Automated scripts or tools: Some automated network management scripts or tools might incorporate Nping for monitoring purposes. Users should identify these scripts and exclude their execution paths or associated service accounts from triggering alerts.
-- Development and testing environments: In environments where network tools are frequently tested, Nping might be executed as part of development activities. Users can exclude specific development servers or environments from the detection rule to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks.
-- Verify the legitimacy of the Nping process by checking the user account that initiated it and cross-referencing with authorized network testing activities.
-- Conduct a thorough investigation of the system logs to identify any unauthorized access or suspicious activities preceding the Nping execution.
-- Review network traffic logs to determine if there were any unusual patterns or connections initiated by the Nping process.
-- If unauthorized use is confirmed, terminate the Nping process and any other suspicious processes running on the host.
-- Escalate the incident to the security operations team for further analysis and to determine if other systems may be affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more efficiently.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate Nping activity with known threat actor behaviors.
-- Restore the system to its operational state by applying any necessary patches, updating security configurations, and conducting a full system scan for malware.
-- Harden the system by disabling unnecessary network services, enforcing strict access controls, and regularly updating security policies to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml
index 1716494d177..e4c58f72f89 100644
--- a/rules/linux/discovery_pam_version_discovery.toml
+++ b/rules/linux/discovery_pam_version_discovery.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/12/16"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ This rule detects PAM version discovery activity on Linux systems. PAM version d
 attacker attempting to backdoor the authentication process through malicious PAM modules.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Pluggable Authentication Module (PAM) Version Discovery"
@@ -56,59 +58,19 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and (
-  (process.name in ("dpkg", "dpkg-query") and process.args == "libpam-modules") or
-  (process.name == "rpm" and process.args == "pam")
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  (
+    (process.name in ("dpkg", "dpkg-query") and process.args == "libpam-modules") or
+    (process.name == "rpm" and process.args == "pam")
+  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 (PAM) Version Discovery
-
-Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious activities by monitoring processes like `dpkg` or `rpm` that query PAM-related packages, indicating potential reconnaissance or tampering attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the triggering process name and arguments, specifically checking if `dpkg`, `dpkg-query`, or `rpm` were used with arguments `libpam-modules` or `pam`.
-- Verify the user account associated with the process execution to determine if it aligns with expected administrative activity or if it appears suspicious.
-- Check the process execution timeline to identify any unusual patterns or sequences of commands that might indicate reconnaissance or tampering.
-- Investigate the parent process of the alert-triggering process to understand the context of how the command was initiated.
-- Examine the command history of the user associated with the process to identify any other potentially suspicious activities or commands executed around the same time.
-- Utilize Osquery to gather more information about PAM-related files and configurations. For example, run the query: `SELECT * FROM rpm_packages WHERE name LIKE 'pam%' OR name LIKE 'libpam%';` to list installed PAM packages and their versions.
-- Cross-reference the PAM version information obtained with known vulnerabilities or advisories to assess potential risks.
-- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual authentication attempts or errors that might correlate with the alert.
-- Investigate network activity from the host to identify any connections to known malicious IPs or domains that could suggest external reconnaissance or data exfiltration.
-- Review recent changes to PAM configuration files, such as `/etc/pam.d/`, to detect unauthorized modifications or the presence of suspicious modules.
-
-### False positive analysis
-
-- Routine system updates or package management activities can trigger the rule, as legitimate processes like `dpkg` or `rpm` may query PAM-related packages during normal operations.
-- System administrators performing audits or checks on installed packages might inadvertently cause alerts when using package management tools to verify PAM versions.
-- Automated scripts or configuration management tools that regularly check for package updates or system configurations could also lead to false positives if they include commands querying PAM packages.
-- To manage these false positives, users can create exceptions for known benign activities by excluding specific user accounts or processes that are regularly involved in legitimate package management tasks.
-- Implementing a whitelist for certain scripts or automation tools that are verified and trusted can help reduce unnecessary alerts while maintaining security monitoring.
-- Regularly reviewing and updating the list of exceptions based on observed patterns and system changes can help maintain the balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the presence of malicious PAM modules by reviewing system logs and checking for unauthorized changes in PAM configuration files.
-- Use forensic tools to capture and analyze memory and disk images to identify any additional indicators of compromise or persistence mechanisms.
-- Remove any unauthorized or suspicious PAM modules and restore the original configuration from a known good backup.
-- Apply security patches and updates to the PAM software and other system components to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed authentication and process execution events for future analysis.
-- Integrate security information and event management (SIEM) systems to correlate PAM-related events with other security alerts for comprehensive threat detection.
-- Conduct a review of user accounts and authentication policies to ensure they adhere to the principle of least privilege and enforce strong password policies.
-- Escalate the incident to the appropriate internal security team or external cybersecurity experts if advanced persistent threats or sophisticated attack techniques are suspected.
-- Develop and implement a system hardening guide that includes disabling unused PAM modules, restricting access to PAM configuration files, and regularly auditing PAM-related activities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_ping_sweep_detected.toml b/rules/linux/discovery_ping_sweep_detected.toml
index 746f221f252..0fa247325c9 100644
--- a/rules/linux/discovery_ping_sweep_detected.toml
+++ b/rules/linux/discovery_ping_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,49 +61,6 @@ query = '''
 event.category:process and host.os.type:linux and event.action:(exec or exec_event or executed or process_started) and
 event.type:start and process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Network Scan Executed From Host
-
-Network scanning utilities like ping, netcat, and socat are essential for diagnosing connectivity and network issues in Linux environments. However, adversaries exploit these tools to map networks stealthily, often using rapid execution to avoid detection. The detection rule identifies suspicious activity by monitoring the initiation of these processes, flagging potential misuse indicative of network reconnaissance efforts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the specific process name that triggered the alert, focusing on `process.name` to identify if it was ping, netcat, socat, or another utility.
-- Check the `event.category` and `event.action` fields to ensure the alert corresponds to a process execution event on a Linux host.
-- Investigate the `host.os.type` to confirm the operating system is Linux, as this rule is specific to Linux environments.
-- Examine the `event.type` field to verify that the process was indeed started, which aligns with the rule's focus on process initiation.
-- Use Osquery to gather more context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('ping', 'nping', 'hping', 'hping2', 'hping3', 'nc', 'ncat', 'netcat', 'socat');` to retrieve detailed information about the suspicious process.
-- Analyze the command line arguments of the process to understand the scope and intent of the network scan, which can be done by checking the `process.command_line` field.
-- Review the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
-- Check the process's parent process to identify if it was spawned by another suspicious or unauthorized process.
-- Investigate network connections established by the host around the time of the alert to identify any unusual or unauthorized network activity.
-- Correlate this event with other logs and alerts from the same host or network segment to identify patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use tools like ping, netcat, and socat for legitimate network diagnostics and troubleshooting, which can trigger false positives. To manage this, create exceptions for known administrative activities by whitelisting specific user accounts or IP addresses associated with these tasks.
-- Automated monitoring scripts: Some environments deploy automated scripts that regularly execute network scanning utilities to ensure network health and connectivity. These scripts can be excluded by identifying their unique process names or execution patterns and adding them to an exception list.
-- Scheduled maintenance activities: During scheduled network maintenance, network scanning tools may be used to verify network configurations and connectivity. To prevent false positives, schedule exceptions during known maintenance windows or for specific maintenance-related processes.
-- Security tools: Certain security tools and intrusion detection systems may use similar utilities for legitimate network scanning and monitoring purposes. Identify these tools and exclude their processes from triggering alerts by adding them to a trusted list.
-- Development and testing environments: In environments where network scanning is part of development or testing processes, frequent execution of these utilities may occur. Implement exceptions for specific environments or subnets where such activities are expected and non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary.
-- Conduct a thorough investigation of the host to identify any unauthorized access or additional malicious activities, focusing on the processes and network connections initiated by the flagged utilities.
-- Review system and network logs to trace the origin and scope of the network scan, identifying any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Remediate the affected host by removing any unauthorized tools or scripts and applying security patches to address known vulnerabilities.
-- Restore the host to its operational state by verifying the integrity of system files and configurations, and ensuring that all security controls are re-enabled.
-- Implement enhanced logging policies to capture detailed process execution and network activity, enabling better detection of similar threats in the future.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve the detection and response capabilities for network reconnaissance activities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply hardening measures such as disabling unnecessary services, enforcing least privilege access, and regularly updating security configurations to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml
index 09a17d26acc..13ef862b2a7 100644
--- a/rules/linux/discovery_private_key_password_searching_activity.toml
+++ b/rules/linux/discovery_private_key_password_searching_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/11/04"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ This rule detects private key searching activity on Linux systems. Searching for
 attacker attempting to escalate privileges or exfiltrate sensitive information.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Private Key Searching Activity"
@@ -48,59 +50,19 @@ tags = [
         "OS: Linux",
         "Use Case: Threat Detection",
         "Tactic: Discovery",
-        "Data Source: Elastic Defend"
+        "Data Source: Elastic Defend",
+        "Data Source: Crowdstrike",
+        "Data Source: SentinelOne",
+        "Data Source: Elastic Endgame"
         ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "find" and
-process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
-process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "find" and
+  process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
+  process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Private Key Searching Activity
-
-In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key file patterns in sensitive directories, signaling potential malicious intent to locate and misuse private keys.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'find' command execution, focusing on the `process.command_line` field to identify the specific patterns and directories targeted.
-- Examine the `process.name` and `process.command_line` fields to verify if the command was executed by a legitimate user or process, or if it appears suspicious.
-- Check the `host.os.type` and `event.type` fields to ensure the alert pertains to a Linux system and corresponds to a process start event.
-- Investigate the user account associated with the `event.action` field to determine if the account has a history of legitimate access to private keys or if it might be compromised.
-- Use Osquery to list recent 'find' command executions on the host for further context. Example query: `SELECT * FROM processes WHERE name = 'find' AND cmdline LIKE '%id_%' ORDER BY start_time DESC LIMIT 10;`
-- Analyze the `process.parent` field to identify the parent process of the 'find' command, which may provide insights into how the command was initiated.
-- Review system logs and user activity around the time of the alert to identify any other suspicious behavior or commands executed by the same user.
-- Check for any recent changes or anomalies in the directories specified in the `process.command_line` field, such as `/home/`, `/etc/ssh`, and `/root/`.
-- Investigate network activity from the host to detect any potential exfiltration attempts, especially if the 'find' command was executed by an unauthorized user.
-- Correlate this alert with other security events or alerts from the same host or user to identify patterns or a broader attack campaign.
-
-### False positive analysis
-
-- System administrators or automated scripts may legitimately use the 'find' command to locate private keys for backup or migration purposes, leading to false positives.
-- Developers working on applications that require key management might execute searches to verify key locations, which can trigger the rule.
-- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place, potentially causing false alerts.
-- To manage these false positives, users can create exceptions for known benign activities by excluding specific user accounts or scripts from triggering the rule.
-- Implementing a whitelist of trusted processes or directories can help reduce noise from legitimate key searches.
-- Regularly review and update the detection rule to align with organizational changes and reduce unnecessary alerts from routine operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or changes to private keys.
-- Review system logs and command history to trace the actions of the adversary and identify any additional compromised accounts or systems.
-- Change all potentially compromised private keys and associated passwords, and update any systems or services that rely on these keys for authentication.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed command-line activity and process execution, ensuring future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents.
-- Implement hardening measures such as disabling unused services, enforcing least privilege access, and regularly auditing key directories for unauthorized access attempts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_proc_maps_read.toml b/rules/linux/discovery_proc_maps_read.toml
index ee7e61d8757..fa5cc29d2ef 100644
--- a/rules/linux/discovery_proc_maps_read.toml
+++ b/rules/linux/discovery_proc_maps_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ process.name in ("cat", "grep") and process.args : "/proc/*/maps" and process.en
   "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious /proc/maps Discovery
-
-In Linux environments, the `/proc/*/maps` file reveals a process's memory layout, including segment permissions and file mappings. Adversaries exploit this to locate memory addresses for injecting malicious code or hijacking processes. The detection rule identifies suspicious reads of this file by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, signaling potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments, ensuring they match the suspicious pattern of reading `/proc/*/maps` using `cat` or `grep`.
-- Check the `process.entry_leader.name` to identify the shell environment from which the command was executed, as this can provide context on the user's activity.
-- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
-- Examine the parent process of the suspicious command to understand the sequence of events leading to the execution of the `/proc/*/maps` read.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;` to retrieve detailed information about the process.
-- Analyze the command history of the user associated with the shell session to identify any preceding commands that might indicate reconnaissance or preparatory actions.
-- Check for any recent logins or session initiations by the user to determine if the activity coincides with a new or unexpected session.
-- Review system logs for any other suspicious activities or anomalies around the time of the alert to identify potential related events.
-- Investigate network connections established by the process or user to detect any unusual outbound connections that might suggest data exfiltration or command-and-control activity.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack pattern or campaign.
-
-### False positive analysis
-
-- System administrators or developers may legitimately access `/proc/*/maps` for debugging or performance monitoring purposes, leading to false positives. Users can handle these by creating exceptions for known administrative scripts or tools that require such access.
-- Automated monitoring tools or security software might read `/proc/*/maps` as part of their regular operations. To manage these, users should identify and whitelist these tools to prevent unnecessary alerts.
-- Some legitimate applications may access their own memory maps for optimization or self-checking routines. Users can exclude these applications by adding them to an exception list based on their process names or specific command patterns.
-- During software development, developers might use commands like `cat` or `grep` on `/proc/*/maps` to troubleshoot or test applications. Users should consider excluding development environments or specific user accounts from triggering alerts.
-- Security audits or compliance checks might involve reading `/proc/*/maps` to verify system integrity. Users can manage these by scheduling such activities during known maintenance windows and temporarily disabling the rule or by excluding specific audit tools.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to determine the source and intent of the suspicious /proc/maps access, including reviewing logs and correlating with other security events.
-- Capture and preserve relevant forensic data, such as memory dumps and disk images, to support a detailed analysis and potential legal actions.
-- Identify and terminate any unauthorized processes or sessions that may have been initiated by the adversary.
-- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for similar attacks.
-- Review and enhance logging policies to ensure comprehensive monitoring of process executions and file access, particularly for sensitive files like /proc/maps.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of suspicious activities.
-- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for advanced threat analysis and response.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security configurations are applied.
-- Implement hardening measures, such as disabling unnecessary services, enforcing least privilege access, and using security tools like intrusion detection systems (IDS) to prevent future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_process_capabilities.toml b/rules/linux/discovery_process_capabilities.toml
index ffb191998f8..cb11c2facc4 100644
--- a/rules/linux/discovery_process_capabilities.toml
+++ b/rules/linux/discovery_process_capabilities.toml
@@ -1,8 +1,8 @@
 [metadata]
 creation_date = "2024/01/09"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +11,7 @@ Identifies recursive process capability enumeration of the entire filesystem thr
 may manipulate identified capabilities to gain root privileges.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Process Capability Enumeration"
@@ -51,59 +51,17 @@ tags = [
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
-process.name == "getcap" and process.args == "-r" and process.args == "/" and process.args_count == 3 and
-user.id != "0"
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "ProcessRollup2") and
+  process.name == "getcap" and process.args == "-r" and process.args == "/" and
+  process.args_count == 3 and user.id != "0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Capability Enumeration
-
-In Linux environments, the `getcap` command is used to list file capabilities, which define specific privileges for executables. Adversaries may exploit this by recursively scanning the filesystem to identify and manipulate capabilities, potentially escalating privileges to root. The detection rule identifies suspicious use of `getcap` by monitoring for non-root users executing it with specific arguments, indicating potential malicious enumeration activities.
-
-### Possible investigation steps
-
-- Verify the alert details by checking the user ID associated with the `getcap` command execution to ensure it is indeed a non-root user (user.id != "0").
-- Review the process execution context by examining the parent process of `getcap` to understand how it was initiated and if it was part of a larger script or command chain.
-- Investigate the command line arguments used with `getcap` to confirm the recursive scan of the entire filesystem (`-r /`) and ensure the args_count is exactly 3.
-- Check the user's login history and session details to determine if the user was logged in at the time of the alert and if there were any unusual login patterns.
-- Use Osquery to list all capabilities set on files in the system to identify any unusual or suspicious capabilities that might have been manipulated. Example query: `SELECT * FROM file WHERE capabilities IS NOT NULL;`
-- Examine the user's shell history files (e.g., `.bash_history`) to identify any other potentially suspicious commands executed around the time of the alert.
-- Review system logs for any other unusual activities or errors that occurred around the time of the `getcap` execution, focusing on authentication logs and sudo usage.
-- Investigate any recent changes to the system's capabilities database or related configuration files to identify unauthorized modifications.
-- Cross-reference the alert with other security tools or logs to identify if there are any correlated alerts or indicators of compromise involving the same user or system.
-- Assess the user's role and permissions within the organization to determine if they have a legitimate reason to perform such enumeration and if their access level is appropriate.
-
-### False positive analysis
-
-- System administrators or security teams may intentionally use the `getcap` command with recursive options during routine audits or security assessments, leading to false positives.
-- Automated scripts or configuration management tools that verify file capabilities across the filesystem for compliance or security hardening purposes might trigger the rule.
-- Developers or DevOps personnel might execute `getcap` as part of testing or debugging processes in development environments, which could be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for specific user accounts or groups known to perform legitimate capability checks, ensuring these are well-documented and reviewed regularly.
-- Implementing a whitelist of known safe scripts or tools that use `getcap` can help reduce noise while maintaining security oversight.
-- Regularly review and update the detection rule to accommodate changes in legitimate use cases, ensuring that only suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
-- Verify the identity and permissions of the user who executed the `getcap` command to determine if the action was authorized or malicious.
-- Conduct a thorough review of the system's audit logs and process execution history to identify any unauthorized changes or suspicious activities following the `getcap` execution.
-- Check for any modifications to file capabilities and revert any unauthorized changes to prevent privilege escalation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for the `getcap` command and other capability-modifying commands to detect future unauthorized use.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection and response capabilities for similar threats.
-- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
-- Implement system hardening measures, such as restricting the use of capability-modifying commands to authorized users only and employing the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_pspy_process_monitoring_detected.toml b/rules/linux/discovery_pspy_process_monitoring_detected.toml
index 469e8de33db..a61e6a1a297 100644
--- a/rules/linux/discovery_pspy_process_monitoring_detected.toml
+++ b/rules/linux/discovery_pspy_process_monitoring_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -60,47 +60,6 @@ sequence by process.pid, host.id with maxspan=5s
    not process.name == "agentbeat"
   ] with runs=10
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Pspy Process Monitoring Detected
-
-Auditd is a powerful tool used in Linux environments to track system calls, providing insights into process activities. Adversaries exploit utilities like pspy to monitor processes without elevated privileges, seeking opportunities for privilege escalation. The detection rule identifies suspicious activity by tracking the 'openat' syscall within the /proc directory, flagging repeated access patterns indicative of pspy usage.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'openat' syscall within the /proc directory, focusing on the specific auditd data fields: `auditd.data.syscall`, `auditd.data.a0`, and `auditd.data.a2`.
-- Verify the frequency and pattern of the 'openat' syscall by examining the sequence of events for the same `process.pid` and `host.id` within the specified `maxspan=5s` to ensure it aligns with the rule's conditions.
-- Check the process name associated with the alert to confirm it is not a legitimate process like "agentbeat" that might be excluded from the rule.
-- Use Osquery to gather more information about the suspicious process. Execute a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <suspicious_pid>;` to retrieve details about the process.
-- Investigate the parent process of the suspicious process to understand its origin and whether it was spawned by a legitimate or malicious process.
-- Examine the command line arguments (`cmdline`) of the suspicious process to identify any unusual or unexpected parameters that might indicate malicious intent.
-- Review the user account associated with the process to determine if it is a standard user or a service account, which might provide insights into potential misuse or compromise.
-- Check the process's file path and hash against known good or malicious software databases to identify if it matches any known utilities or malware.
-- Analyze the network activity of the host during the time of the alert to identify any suspicious outbound connections that might correlate with the process activity.
-- Correlate the findings with other security events or logs from the same host or network segment to identify any additional indicators of compromise or related suspicious activities.
-
-### False positive analysis
-
-- Known false positives for the Potential Pspy Process Monitoring Detected rule may include legitimate system monitoring tools or scripts that frequently access the /proc directory using the openat syscall. These tools might be part of regular system administration tasks or monitoring solutions that do not pose a security threat.
-- To manage these false positives, users can create exceptions for specific processes or scripts that are known to perform benign activities. This can be done by modifying the detection rule to exclude certain process names or paths that are identified as non-threatening. For example, adding exceptions for known monitoring tools or system processes that are verified to be safe can reduce noise in the detection system.
-- Users should regularly review and update the list of exceptions to ensure that only legitimate processes are excluded, maintaining a balance between reducing false positives and not missing actual threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the presence of pspy or similar unauthorized monitoring tools by analyzing audit logs and process activity.
-- Terminate any suspicious processes identified during the investigation to halt potential malicious activities.
-- Review user accounts and permissions on the affected system to identify and remove any unauthorized access or privilege escalation paths.
-- Escalate the incident to the security operations team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process activity and syscall usage, focusing on the /proc directory and openat syscall.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by reinstalling affected software and applying the latest security patches and updates.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface and prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_security_file_access_via_common_utility.toml b/rules/linux/discovery_security_file_access_via_common_utility.toml
index 40e8872f9af..fdb6eb3c908 100644
--- a/rules/linux/discovery_security_file_access_via_common_utility.toml
+++ b/rules/linux/discovery_security_file_access_via_common_utility.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/11/04"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ This rule detects sensitive security file access via common utilities on Linux s
 from sensitive files using common utilities to gather information about the system and its security configuration.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Security File Access via Common Utilities"
@@ -48,63 +50,25 @@ tags = [
         "OS: Linux",
         "Use Case: Threat Detection",
         "Tactic: Discovery",
-        "Data Source: Elastic Defend"
+        "Data Source: Elastic Defend",
+        "Data Source: Crowdstrike",
+        "Data Source: SentinelOne",
+        "Data Source: Elastic Endgame"
         ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
-process.name in ("cat", "grep", "less", "more", "strings", "awk", "find", "xargs") and
-process.args like (
-  "/etc/security/*", "/etc/pam.d/*", "/etc/login.defs", "/lib/security/*", "/lib64/security/*",
-  "/usr/lib/security/*", "/usr/lib64/security/*", "/usr/lib/x86_64-linux-gnu/security/*",
-  "/home/*/.aws/credentials", "/home/*/.aws/config", "/home/*/.config/gcloud/*credentials.json",
-  "/home/*/.config/gcloud/configurations/config_default", "/home/*/.azure/accessTokens.json",
-  "/home/*/.azure/azureProfile.json"
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.name in ("cat", "grep", "less", "more", "strings", "awk", "find", "xargs") and
+  process.args like (
+    "/etc/security/*", "/etc/pam.d/*", "/etc/login.defs", "/lib/security/*", "/lib64/security/*",
+    "/usr/lib/security/*", "/usr/lib64/security/*", "/usr/lib/x86_64-linux-gnu/security/*",
+    "/home/*/.aws/credentials", "/home/*/.aws/config", "/home/*/.config/gcloud/*credentials.json",
+    "/home/*/.config/gcloud/configurations/config_default", "/home/*/.azure/accessTokens.json",
+    "/home/*/.azure/azureProfile.json"
+  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Security File Access via Common Utilities
-
-In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to extract system configuration details. The detection rule identifies such unauthorized access attempts by monitoring the execution of these utilities when they target specific security-related file paths, thus helping to thwart potential information-gathering activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific utility (e.g., `cat`, `grep`, `less`) that was executed and the exact file path targeted, as indicated by the `process.name` and `process.args` fields.
-- Check the `host.os.type` and `event.type` fields to confirm the alert pertains to a Linux system and that the event type is a process start, ensuring the context aligns with the rule's intent.
-- Investigate the user account associated with the process execution by examining the `user.name` field to determine if the access attempt was made by a legitimate user or a potential adversary.
-- Analyze the `process.parent.name` field to understand the parent process that initiated the utility, which may provide insights into whether the access was part of a larger script or automated task.
-- Use Osquery to gather additional context about the process and its execution environment. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
-- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, to identify any unusual login activities or privilege escalations around the time of the alert.
-- Check for any recent changes to the targeted files by reviewing file modification timestamps and comparing them with the alert timestamp to identify unauthorized modifications.
-- Investigate network activity from the host during the time of the alert to detect any potential data exfiltration attempts or connections to suspicious external IP addresses.
-- Correlate the alert with other security events or alerts from the same host or user to identify patterns or repeated access attempts to sensitive files.
-- Review the system's security configuration and access controls to ensure that sensitive files are adequately protected and that only authorized users have access to them.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use utilities like `cat`, `grep`, and `less` to review security configurations and logs as part of regular maintenance. These legitimate activities can trigger the rule. To manage this, users can create exceptions for specific user accounts or processes that are known to perform these tasks regularly.
-- Automated scripts: Scheduled scripts or cron jobs that perform system checks or backups might access security files using these utilities. Users should identify such scripts and exclude them from triggering alerts by specifying their process IDs or command patterns in the rule configuration.
-- Security audits: During security audits, tools may be employed to verify system configurations, which could involve accessing sensitive files. Users can temporarily disable the rule or whitelist the audit tools during the audit period to prevent false positives.
-- Development and testing environments: Developers or testers might access security files to simulate or test configurations. In such cases, users can exclude specific environments or IP ranges from the rule to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the unauthorized access, focusing on the processes and users involved.
-- Review system logs and security alerts to determine if any sensitive data was accessed or exfiltrated, and document findings for further analysis.
-- Change credentials and access tokens for any compromised accounts, especially those related to cloud services like AWS, GCP, and Azure.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and file access events, ensuring future unauthorized access attempts are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts with known threat actors and tactics.
-- Restore the system to its operational state by applying patches, updating security configurations, and ensuring all unauthorized changes are reverted.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting access to sensitive files, enforcing least privilege principles, and using file integrity monitoring to detect unauthorized changes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_sudo_allowed_command_enumeration.toml b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
index 6c40f9d467f..e0ec108809d 100644
--- a/rules/linux/discovery_sudo_allowed_command_enumeration.toml
+++ b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/30"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ the invoking user. Attackers may execute this command to enumerate commands allo
 permissions, potentially allowing to escalate privileges to root.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Sudo Command Enumeration Detected"
@@ -50,58 +52,18 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
-process.name == "sudo" and process.args == "-l" and process.args_count == 2 and
-process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
-not process.args == "dpkg"
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "sudo" and process.args == "-l" and
+  process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
+  not process.args == "dpkg"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Sudo Command Enumeration Detected
-
-The sudo command in Linux environments allows users to execute commands with elevated privileges. Attackers may exploit this by using `sudo -l` to list permissible commands, seeking privilege escalation opportunities. The detection rule identifies this activity by monitoring for the execution of `sudo -l` from common shell environments, excluding benign cases like package management, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `sudo -l` execution, focusing on the `process.name`, `process.args`, and `process.parent.name` fields to ensure the command was executed from a common shell environment.
-- Check the `host.os.type` and `event.type` fields to verify that the event occurred on a Linux system and was a process start event.
-- Investigate the user account associated with the `sudo -l` command execution to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the `process.parent.name` to understand the context in which the `sudo -l` command was executed, identifying if it was part of a script or an interactive session.
-- Use Osquery to gather additional context about the user and process. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
-- Analyze the `process.args_count` field to ensure that the command was executed with the expected number of arguments, which can help identify any anomalies or deviations from typical usage.
-- Cross-reference the `process.args` field with known benign cases, such as package management activities, to rule out false positives.
-- Investigate any other processes or network connections initiated by the same user around the time of the `sudo -l` execution to identify potential lateral movement or data exfiltration attempts.
-- Review system logs and audit logs for any additional suspicious activity or failed login attempts that may correlate with the `sudo -l` execution.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that commonly use `sudo -l` enumeration as part of their attack techniques.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may frequently use `sudo -l` to verify their own permissions or to troubleshoot user access issues. These legitimate uses can be excluded by creating exceptions for specific user accounts or roles known to perform these tasks regularly.
-- Automated scripts: Some automated scripts or monitoring tools might use `sudo -l` to check permissions as part of their normal operation. Identifying these scripts and excluding their execution paths or parent processes can help reduce false positives.
-- Package management: Although the rule already excludes `dpkg`, other package management tools or scripts might invoke `sudo -l` as part of their operations. Users can extend the exclusion list to include these specific cases by analyzing the context in which `sudo -l` is executed.
-- Development environments: Developers might use `sudo -l` in development or testing environments to ensure their applications have the necessary permissions. Excluding specific development environments or user accounts can help manage these false positives.
-- User training: Educating users about the implications of using `sudo -l` and encouraging them to limit its use to necessary situations can help reduce unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
-- Review the sudoers file to identify any unauthorized or suspicious entries that may have been added or modified.
-- Conduct a thorough investigation of the user's activity logs to determine if any unauthorized commands were executed using elevated privileges.
-- Check for any additional signs of compromise, such as unexpected new user accounts, changes in system configurations, or unusual network traffic.
-- If unauthorized changes are detected, revert the system to a known good state using backups or system snapshots.
-- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed command execution and user activity, ensuring that logs are securely stored and regularly reviewed.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze data for early detection of similar threats.
-- Apply system hardening measures, such as restricting sudo access to only necessary users, using multi-factor authentication, and regularly updating and patching the system.
-- Educate users on security best practices and the importance of reporting suspicious activities to help prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_suid_sguid_enumeration.toml b/rules/linux/discovery_suid_sguid_enumeration.toml
index efbe1dc0e00..131a1e897c6 100644
--- a/rules/linux/discovery_suid_sguid_enumeration.toml
+++ b/rules/linux/discovery_suid_sguid_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/24"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -67,48 +67,6 @@ process.name == "find" and process.args : "-perm" and process.args : (
   (process.args : "/usr/bin/pkexec" and process.args : "-xdev" and process.args_count == 7)
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SUID/SGUID Enumeration Detected
-
-SUID and SGID are Linux permissions that allow programs to run with elevated privileges, potentially enabling users to perform tasks they otherwise couldn't. Adversaries exploit misconfigured binaries with these permissions to escalate privileges. The detection rule identifies suspicious use of the "find" command to locate such binaries, filtering out benign cases to highlight potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the specific `process.name` and `process.args` that triggered the alert.
-- Verify the user context by checking the `user.Ext.real.id` and `group.Ext.real.id` fields to determine if the command was executed by a privileged user or group.
-- Examine the `process.args` field to identify the exact permissions being searched for, such as "/6000", "-6000", "/4000", "-4000", "/2000", "-2000", "/u=s", "-u=s", "/g=s", "-g=s", "/u=s,g=s", or "/g=s,u=s".
-- Check the `process.args_count` to see if the command includes an unusually high number of arguments, which might indicate a complex or automated script.
-- Investigate the parent process of the "find" command to determine if it was initiated by a legitimate process or a potentially malicious one.
-- Use Osquery to list all files with SUID/SGID permissions on the system for further analysis. Example query: `SELECT path, mode FROM file WHERE mode & 4000 OR mode & 2000;`
-- Cross-reference the list of SUID/SGID files with known vulnerable binaries or those that should not have elevated permissions.
-- Analyze recent system logs for any other suspicious activities or anomalies around the time the "find" command was executed.
-- Investigate the network activity of the host to identify any potential data exfiltration or communication with known malicious IPs.
-- Review historical data to determine if similar "find" command executions have occurred in the past, indicating a pattern or ongoing reconnaissance activity.
-
-### False positive analysis
-
-- System administrators or security teams may use the "find" command with SUID/SGID arguments during routine audits or security assessments, which can trigger false positives. To manage this, consider excluding these activities by identifying the specific user accounts or groups performing these tasks and adding them to an exception list.
-- Automated scripts or security tools that regularly scan for SUID/SGID binaries as part of compliance checks can also generate false positives. Users can handle these by creating exceptions for known scripts or processes, ensuring they are documented and verified as non-threatening.
-- Some legitimate software installations or updates might use the "find" command with SUID/SGID arguments to verify permissions, leading to false positives. To address this, users can exclude these processes by identifying the specific software and its associated process arguments, then adding them to an exception list.
-- In environments where custom applications are developed, developers might use the "find" command with SUID/SGID arguments during testing or debugging, resulting in false positives. Users can mitigate this by excluding known development environments or user accounts from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
-- Conduct a thorough investigation to identify any misconfigured SUID/SGID binaries and assess if they have been exploited. Use forensic tools to analyze system logs and process execution history.
-- Remove or correct the permissions of any misconfigured SUID/SGID binaries to prevent unauthorized privilege escalation.
-- Review user accounts and privileges on the affected system to ensure no unauthorized changes have been made. Revoke any suspicious or unnecessary elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has compromised other systems.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and permission changes, ensuring future incidents can be detected more effectively.
-- Integrate security tools with SIEM solutions to automate the detection of suspicious SUID/SGID enumeration activities and alert security teams in real-time.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files and configurations.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future.
-- Educate system administrators and users on the risks associated with SUID/SGID permissions and best practices for maintaining secure configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml
index cbce0a51505..83efd842f34 100644
--- a/rules/linux/discovery_suspicious_memory_grep_activity.toml
+++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/02/05"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ specific process, detailing the memory segments, permissions, and what files are
 read a process's memory map to identify memory addresses for code injection or process hijacking.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Memory grep Activity"
@@ -27,55 +29,16 @@ tags = [
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
-process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]")
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Memory grep Activity
-
-In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for understanding memory segments and permissions. Adversaries exploit this by using tools like `grep` to scan for specific memory areas, aiding in code injection or hijacking. The detection rule identifies such misuse by monitoring the execution of `grep` variants targeting memory-related arguments, signaling potential reconnaissance or preparatory actions for an attack.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments, ensuring they match the suspicious criteria: `grep`, `egrep`, `fgrep`, or `rgrep` with arguments like `[stack]`, `[vdso]`, or `[heap]`.
-- Check the process execution context by examining the parent process and any child processes spawned by the suspicious `grep` activity to understand the broader context of the execution.
-- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
-- Use Osquery to gather additional details about the process. For example, run the following query to list processes accessing `/proc/*/maps`: `SELECT pid, name, path FROM processes WHERE path LIKE '/proc/%/maps';`
-- Analyze the command history of the user associated with the suspicious process to identify any preceding commands that might indicate reconnaissance or preparatory actions.
-- Review system logs for any other unusual activities or errors around the time of the alert to identify potential correlations or patterns.
-- Check for any recent changes in system configurations or installed software that might explain the unusual `grep` activity.
-- Investigate network activity from the host to identify any suspicious outbound connections that could indicate data exfiltration or communication with a command and control server.
-- Correlate the alert with other security events or alerts from the same host or user to identify if this is part of a larger attack pattern.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar tactics, techniques, and procedures (TTPs).
-
-### False positive analysis
-
-- System administrators or developers may use `grep` to inspect memory maps for legitimate debugging or performance tuning purposes, which can trigger false positives. To manage this, users can create exceptions for specific user accounts or processes known to perform these activities regularly.
-- Automated monitoring tools or scripts that perform regular checks on system memory for health or performance metrics might also cause false positives. Users can handle these by identifying and excluding these tools from the detection rule.
-- Security software or forensic tools that analyze memory maps as part of their routine operations may be flagged. Users should whitelist these trusted applications to prevent unnecessary alerts.
-- In environments where custom applications frequently interact with memory maps for legitimate reasons, users should document these behaviors and adjust the detection rule to exclude these specific cases, ensuring that only suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the suspicious activity by reviewing logs and correlating with other security events.
-- Capture a memory dump and relevant logs for forensic analysis to understand the extent of the compromise and identify any injected code or malicious processes.
-- Terminate any unauthorized or suspicious processes identified during the investigation to prevent further malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to a known good state using backups or reinstallation, ensuring that all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_suspicious_which_command_execution.toml b/rules/linux/discovery_suspicious_which_command_execution.toml
index dfcc1fc71b4..a480c04a7ae 100644
--- a/rules/linux/discovery_suspicious_which_command_execution.toml
+++ b/rules/linux/discovery_suspicious_which_command_execution.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/08/30"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ leverage the which command to enumerate the system for useful installed utilitie
 system to escalate privileges or move latteraly across the network.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious which Enumeration"
@@ -26,67 +28,24 @@ tags = [
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
-process.name == "which" and process.args_count >= 10 and not (
-  process.parent.name == "jem" or
-  process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or
-  process.args == "--tty-only"
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start") and 
+  process.name == "which" and process.args_count >= 10 and not (
+    process.parent.name == "jem" or
+    process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or
+    process.args == "--tty-only"
+  )
 
 /* potential tuning if rule would turn out to be noisy
 and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and 
 process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 */
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious which Enumeration
-
-The 'which' command in Linux environments is typically used to locate the executable path of a command. Adversaries may exploit this utility to identify installed software that can aid in privilege escalation or lateral movement. The detection rule identifies unusual usage patterns, such as an excessive number of arguments, which may indicate malicious intent. It filters out benign scenarios, like specific parent processes or known safe paths, to reduce false positives.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "which" and the process.args_count is 10 or more, indicating an unusual number of arguments.
-- Check the parent process name and executable path to ensure it is not "jem" or within the specified benign paths ("/vz/root/*", "/var/lib/docker/*").
-- Examine the full command line (process.command_line) used in the suspicious "which" execution to understand the context and intent of the command.
-- Investigate the user account (user.name) associated with the process to determine if the activity aligns with their typical behavior or role.
-- Analyze the process start time (event.start) to correlate with other suspicious activities or known attack timelines.
-- Use Osquery to list all processes started by the same user around the time of the alert to identify any other potentially malicious activities:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<user.name>');
-  ```
-- Check for any network connections or file modifications made by the user or process around the time of the alert to identify lateral movement or data exfiltration attempts.
-- Review system logs for any failed or successful authentication attempts that could indicate privilege escalation efforts.
-- Investigate any recent changes to user permissions or group memberships that could facilitate unauthorized access or privilege escalation.
-- Correlate the alert with other security events or alerts from the same host or network segment to identify potential coordinated attack patterns.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate scripts or applications use the 'which' command with a high number of arguments for system checks or configuration validation. Users can handle these by identifying and excluding specific parent processes or paths that are known to be safe.
-- Frequent non-threatening behaviors can be managed by adding exceptions for specific parent processes like 'jem' or known safe paths such as those under '/vz/root/*' or '/var/lib/docker/*'.
-- If the rule is noisy, consider tuning it by excluding common command-line utilities like 'nmap', 'nc', 'ncat', 'netcat', 'nc.traditional', 'gcc', 'g++', and 'socat' when executed from standard shell environments like 'bash', 'dash', 'ash', 'sh', 'tcsh', 'csh', 'zsh', 'ksh', and 'fish'.
-- Users should regularly review and update the list of exceptions to ensure that new legitimate use cases are not flagged as suspicious, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
-- Conduct a thorough investigation of the process tree to identify the parent process and any child processes spawned by the suspicious 'which' command execution.
-- Review system logs and command history to determine the scope of the enumeration and identify any other suspicious activities or commands executed around the same time.
-- If malicious activity is confirmed, perform a full malware scan and remove any identified threats from the system.
-- Change all passwords and credentials that may have been exposed or compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed command execution and process creation events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all security patches and updates are applied.
-- Harden the system by disabling unnecessary services, enforcing the principle of least privilege, and regularly auditing installed software and user permissions."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_unusual_user_enumeration_via_id.toml b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
index 1c404621d83..860c3e226b4 100644
--- a/rules/linux/discovery_unusual_user_enumeration_via_id.toml
+++ b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,49 +59,6 @@ sequence by host.id, process.parent.entity_id with maxspan=1s
    process.name == "id" and process.args_count == 2 and 
    not (process.parent.name == "rpm" or process.parent.args : "/var/tmp/rpm-tmp*")] with runs=20
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual User Privilege Enumeration via id
-
-In Linux environments, the `id` command is used to display user identity and group memberships, crucial for privilege assessment. Adversaries exploit this by executing scripts like LinPEAS to rapidly enumerate user privileges, potentially revealing sensitive information. The detection rule identifies suspicious activity by flagging rapid, repeated `id` executions, suggesting automated enumeration attempts, thus alerting analysts to potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and process.parent.entity_id associated with the suspicious activity.
-- Check the process execution timeline to verify if the 20 "id" command executions occurred within the specified 1-second window.
-- Investigate the parent process of the "id" command using the process.parent.entity_id to determine if it is a known or legitimate process.
-- Examine the process.parent.name and process.parent.args fields to identify any unusual or unexpected parent processes that might have triggered the "id" command.
-- Use Osquery to list all processes running on the host at the time of the alert to identify any other suspicious activities. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE start_time > (SELECT datetime('now', '-1 minute'));`
-- Analyze the command-line arguments (process.args) used with the "id" command to check for any specific patterns or anomalies.
-- Review system logs and audit logs for any other unusual activities or errors around the time of the alert.
-- Investigate the user account associated with the process to determine if it has been compromised or is being misused.
-- Check for any recent changes in user privileges or group memberships on the system that could indicate privilege escalation attempts.
-- Correlate this activity with other alerts or incidents on the same host or network to identify potential patterns or coordinated attacks.
-
-### False positive analysis
-
-- System administration scripts or automated maintenance tasks that frequently execute the `id` command as part of their routine checks can trigger false positives. These scripts may be scheduled to run at regular intervals and are not indicative of malicious activity.
-- Monitoring tools or security solutions that perform regular checks on user privileges for compliance or auditing purposes might also execute the `id` command multiple times in quick succession, leading to false alerts.
-- Developers or system administrators testing scripts that involve user privilege checks could inadvertently cause the rule to trigger during development or debugging sessions.
-- To manage these false positives, users can create exceptions for known benign processes by excluding specific parent process names or paths that are identified as non-threatening. This can be done by updating the detection rule to ignore executions originating from trusted scripts or applications.
-- Another approach is to adjust the threshold of the rule to better fit the environment's normal behavior, such as increasing the number of allowed `id` executions or extending the time window, while ensuring it still effectively detects genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the presence of enumeration scripts like LinPEAS or LinEnum by reviewing process execution logs and command history.
-- Analyze the parent process and its origin to determine if the activity was initiated by a legitimate user or an adversary.
-- Escalate the incident to the security operations center (SOC) for further analysis and to assess the potential impact on other systems within the network.
-- Review and enhance logging policies to ensure comprehensive monitoring of command executions and user activities, focusing on privilege escalation attempts.
-- Implement additional security measures such as multi-factor authentication and least privilege access to reduce the risk of unauthorized privilege enumeration.
-- Restore the system to its operational state by removing any unauthorized scripts or tools and applying necessary security patches.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on recognizing and reporting suspicious activities to improve overall security awareness within the organization.
-- Leverage MITRE ATT&CK framework to understand the adversary's tactics and techniques, and apply relevant threat intelligence to enhance detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_virtual_machine_fingerprinting.toml b/rules/linux/discovery_virtual_machine_fingerprinting.toml
index e9c51eeaf7e..62990271aa5 100644
--- a/rules/linux/discovery_virtual_machine_fingerprinting.toml
+++ b/rules/linux/discovery_virtual_machine_fingerprinting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -82,50 +82,6 @@ event.category:process and host.os.type:linux and event.type:(start or process_s
                 "/proc/ide/hd0/model") and
   not user.name:root
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Virtual Machine Fingerprinting
-
-Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to evade detection or tailor attacks. Adversaries exploit this by querying system files for hardware details, which can reveal if a system is virtualized. The detection rule targets non-root users accessing specific system paths indicative of VM environments, flagging potential reconnaissance activities by malware like Pupy RAT.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event category is 'process' and the host operating system type is 'linux', as specified in the query.
-- Verify the event type to ensure it matches 'start' or 'process_started', indicating a new process initiation.
-- Check the process arguments to identify which specific system path was accessed, such as "/sys/class/dmi/id/bios_version" or "/proc/scsi/scsi", to understand the nature of the fingerprinting attempt.
-- Investigate the user context by confirming the user name is not 'root', which could indicate unauthorized access attempts by a non-privileged user.
-- Correlate the alert with other recent alerts or logs to identify patterns or repeated access attempts to the same or similar system paths.
-- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE path IN ('/sys/class/dmi/id/bios_version', '/sys/class/dmi/id/product_name', '/sys/class/dmi/id/chassis_vendor', '/proc/scsi/scsi', '/proc/ide/hd0/model');`
-- Examine the parent process of the flagged process to determine if it was spawned by a known legitimate application or a suspicious one.
-- Check the process execution history for the non-root user to identify any other unusual or unauthorized activities.
-- Investigate the network activity associated with the process to detect any potential data exfiltration or communication with known malicious IP addresses.
-- Review system logs for any recent changes or anomalies that could indicate a compromise or unauthorized configuration changes related to virtualization detection.
-
-### False positive analysis
-
-- Non-malicious software or legitimate administrative scripts may access the same system paths for inventory or monitoring purposes, leading to false positives.
-- Developers or IT personnel using scripts to gather system information for troubleshooting or system management might trigger the rule.
-- Automated system management tools that check hardware details for compliance or inventory purposes could be flagged.
-- To manage these false positives, users can create exceptions for known benign processes or users by adding them to an allowlist.
-- Regularly review and update the allowlist to ensure it includes only trusted sources, minimizing the risk of overlooking genuine threats.
-- Consider implementing additional context checks, such as verifying the frequency and timing of access, to differentiate between routine operations and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the intrusion, focusing on identifying any additional compromised systems or accounts.
-- Review system logs and process execution details to understand the adversary's actions and identify any persistence mechanisms.
-- Remove any unauthorized software or malware identified during the investigation, such as Pupy RAT, and ensure all malicious processes are terminated.
-- Change passwords and credentials for any accounts that may have been compromised, especially those with elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if law enforcement notification is necessary.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and user activity, aiding in future detection and investigation efforts.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml
index 073367e8177..751c8c67492 100644
--- a/rules/linux/discovery_yum_dnf_plugin_detection.toml
+++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/06/25"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -12,7 +14,7 @@ to search for YUM/DNF configurations and/or plugins with an enabled state. This
 attempting to establish persistence in a YUM or DNF plugin.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Yum/DNF Plugin Status Discovery"
@@ -52,60 +54,20 @@ tags = [
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
-process.name == "grep" and process.args : "plugins*" and process.args : (
-  "/etc/yum.conf", "/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*",
-  "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf"
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.name == "grep" and process.args : "plugins*" and process.args : (
+    "/etc/yum.conf", "/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*",
+    "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf"
+  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Yum/DNF Plugin Status Discovery
-
-Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands like `grep` to identify active plugins, indicating potential tampering. The detection rule identifies such suspicious activity by monitoring for specific command executions that query plugin configurations, signaling possible malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `grep` command execution with arguments related to Yum/DNF plugin configurations, as specified in the detection rule.
-- Examine the process execution context, including the `process.name` and `process.args` fields, to verify if the command was executed with the intent to discover plugin status.
-- Check the `host.os.type` field to ensure the alert is relevant to a Linux system, as the rule is designed for Linux environments.
-- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
-- Analyze the command's parent process to understand the origin of the execution and identify any suspicious parent-child process relationships.
-- Utilize Osquery to gather additional context on Yum/DNF configurations by running a query such as: `SELECT * FROM file WHERE path IN ('/etc/yum.conf', '/etc/dnf/dnf.conf');` to check for any unauthorized modifications.
-- Review system logs around the time of the alert to identify any other suspicious activities or related events that could indicate a broader attack.
-- Check for any recent changes in the `/etc/yum/pluginconf.d/` and `/etc/dnf/plugins/` directories to identify potential unauthorized plugin installations or modifications.
-- Investigate network connections from the host to determine if there are any unusual outbound connections that could suggest data exfiltration or command-and-control activity.
-- Correlate this alert with other security events or alerts from the same host to identify patterns or indicators of a larger compromise.
-
-### False positive analysis
-
-- System administrators or automated scripts may regularly use the `grep` command to check the status of Yum/DNF plugins as part of routine maintenance or compliance checks, leading to false positives.
-- Developers or IT personnel might execute similar commands during debugging or when developing custom plugins, which can trigger the detection rule.
-- To manage these false positives, users can create exceptions for specific user accounts or scripts known to perform these actions regularly, ensuring that only unexpected or unauthorized executions are flagged.
-- Implementing a whitelist of trusted processes or users that frequently interact with Yum/DNF configurations can help reduce noise from legitimate activities.
-- Monitoring the context of the command execution, such as the user account and the associated process tree, can provide additional insights to differentiate between benign and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or persistence.
-- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing system logs, particularly focusing on the execution of the `grep` command with plugin-related arguments.
-- Identify and document any unauthorized changes to YUM/DNF plugin configurations and revert them to their original state.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed command execution and configuration changes, ensuring future detection of similar activities.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities across the network.
-- Restore the system to its operational state by reinstalling or updating affected packages and ensuring all configurations are secure and verified.
-- Apply hardening measures such as restricting access to configuration files, disabling unnecessary plugins, and enforcing the principle of least privilege.
-- Conduct a post-incident review to identify gaps in detection and response capabilities, and update security policies and procedures accordingly.
-- Educate users and administrators on recognizing signs of compromise and the importance of reporting suspicious activities promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml
index 218d5df1ff1..d51248099e6 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/09/27"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/09/30"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +16,7 @@ and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP UR
 crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "File Creation by Cups or Foomatic-rip Child"
@@ -104,11 +106,12 @@ tags = [
     "Use Case: Vulnerability",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 type = "eql"
 query = '''
 sequence by host.id with maxspan=10s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.parent.name == "foomatic-rip" and
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id
   [file where host.os.type == "linux" and event.type != "deletion" and
diff --git a/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml
index eb277625d18..21f230e9eb9 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,7 @@ through crafted UDP packets or network spoofing. This can result in arbitrary co
 initiated.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Printer User (lp) Shell Execution"
@@ -105,19 +105,21 @@ tags = [
     "Use Case: Vulnerability",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and user.name == "lp" and
-process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
-process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not (
-  process.command_line like (
-    "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat",
-    "/bin/bash -e -c cat"
-  ) or
-  process.args like "gs*"
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event") and user.name == "lp" and
+  process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not (
+    process.command_line like (
+      "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat",
+      "/bin/bash -e -c cat"
+    ) or
+    process.args like "gs*"
+  )
 '''
 
 [[rule.threat]]
diff --git a/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml
index cc566589e2a..7a6a95cdea9 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/09/27"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +16,7 @@ remote unauthenticated attackers to manipulate IPP URLs or inject malicious data
 spoofing. This can result in arbitrary command execution when a print job is initiated.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Cupsd or Foomatic-rip Shell Execution"
@@ -104,19 +106,22 @@ tags = [
     "Use Case: Vulnerability",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
-process.parent.name == "foomatic-rip" and
-process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not (
-  process.command_line like (
-    "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat",
-    "/bin/bash -e -c cat"
-  ) or
-  process.args like "gs*"
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name == "foomatic-rip" and
+  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not (
+    process.command_line like (
+      "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat",
+      "/bin/bash -e -c cat"
+    ) or
+    process.args like "gs*"
+  )
 '''
 
 [[rule.threat]]
diff --git a/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml
index 50898bab05b..bc76b2de76e 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/09/27"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +17,7 @@ through crafted UDP packets or network spoofing. This can result in arbitrary co
 initiated.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Execution from Foomatic-rip or Cupsd Parent"
@@ -105,11 +107,14 @@ tags = [
     "Use Case: Vulnerability",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like (
   // persistence
   "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*", "*/etc/sudoers*",
diff --git a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
index 6e2d7a17024..e07e6d73e79 100644
--- a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
+++ b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -86,49 +86,6 @@ and (
   process.parent.executable like ("/vz/root/*", "/var/rudder/*")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential curl CVE-2023-38545 Exploitation
-
-Curl is a command-line tool used for transferring data with URLs, often employed in scripts and automation. The CVE-2023-38545 vulnerability in curl versions up to 8.3 can be exploited via a buffer overflow during SOCKS5 proxy handshakes, potentially allowing remote code execution. Adversaries might exploit this by crafting specific command-line arguments or environment variables. The detection rule identifies suspicious curl executions by monitoring for unusual command-line lengths and specific SOCKS5-related arguments, excluding known benign processes, to flag potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious curl executions, focusing on the command line arguments and environment variables related to SOCKS5 proxy usage.
-- Verify the version of curl installed on the affected system to determine if it is vulnerable (version <= 8.3). Use the command `curl --version` to check.
-- Examine the `process.command_line` field to understand the full context of the curl command executed, paying attention to any unusual or unexpected arguments.
-- Investigate the `process.parent.name` and `process.parent.executable` fields to identify the parent process that initiated the curl command, ensuring it is not a known benign process.
-- Check the `process.env_vars` field for any suspicious proxy settings, such as `http_proxy`, `HTTPS_PROXY`, or `ALL_PROXY`, that might indicate an attempt to exploit the vulnerability.
-- Use Osquery to gather additional context about the process and its environment. For example, run the following Osquery query to list all processes with their environment variables: `SELECT pid, name, path, cmdline, environ FROM processes WHERE name = 'curl';`
-- Analyze network logs to identify any unusual outbound connections or data transfers that coincide with the time of the suspicious curl execution.
-- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
-- Review user activity logs to determine if the curl execution aligns with legitimate user actions or if it appears to be unauthorized or unexpected.
-- Consult threat intelligence sources to check for any known indicators of compromise or attack patterns associated with CVE-2023-38545 that might match the observed activity.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate administrative scripts or automation tools that use curl with SOCKS5 proxies for valid purposes, such as network testing or configuration management.
-- Processes like "cf-agent", "agent-run", "agent-check", "rudder", "agent-inventory", and "cf-execd" are already excluded as they are known to use curl in a non-threatening manner.
-- Users can handle additional false positives by identifying and excluding other benign parent processes or specific command-line patterns that are frequently observed in their environment.
-- Consider adding exceptions for specific directories or executable paths, such as "/opt/rudder/*" or "/vz/root/*", if they are known to host non-malicious curl operations.
-- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that legitimate activities are not flagged as suspicious.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized changes or suspicious activities, focusing on processes involving curl and SOCKS5 proxy usage.
-- Upgrade curl to version 8.4 or later on all systems to patch the CVE-2023-38545 vulnerability and prevent future exploitation.
-- Review and update firewall and proxy configurations to restrict unauthorized SOCKS5 proxy connections.
-- Implement enhanced logging for curl executions, including capturing command-line arguments and environment variables, to improve detection capabilities.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious patterns related to curl usage.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Restore the system to its operational state by verifying the integrity of critical files and applications, and ensure all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unused services, enforcing least privilege access, and conducting regular security audits to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
index c78c4821cbd..63d52d93d78 100644
--- a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
+++ b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/10"
 
 [rule]
 author = ["Elastic"]
@@ -44,49 +44,6 @@ sequence by host.id with maxspan=3s
        )
     )] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Egress Connection from Entrypoint in Container
-
-Containers use entrypoints to execute initial commands or scripts upon startup, often defined in Dockerfiles. Adversaries may exploit this by embedding malicious scripts to initiate unauthorized outbound connections, potentially breaching network boundaries. The detection rule identifies such threats by monitoring for the execution of `entrypoint.sh` followed by suspicious network activity, flagging attempts to connect to non-local IPs, which may indicate an attacker's effort to establish external communication or persistence.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name `entrypoint.sh` and verify it is associated with a container by checking `process.entry_leader.entry_meta.type`.
-- Examine the `host.id` and `process.entity_id` to identify the specific container and host involved in the alert.
-- Check the `destination.ip` in the network event to determine the external IP address the container attempted to connect to, ensuring it is not within the specified local or reserved IP ranges.
-- Investigate the `process.parent.entity_id` to trace the parent process of `entrypoint.sh` and understand the process hierarchy and potential origin of the script.
-- Use Osquery to gather more information about the container environment. For example, run the following query to list all running processes within the container: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = '<destination.ip>');`
-- Analyze the Dockerfile or container image used to deploy the container to identify any embedded scripts or commands that could be malicious.
-- Review the container's logs and any associated application logs for additional context around the time of the alert to identify any anomalous behavior or errors.
-- Check for any recent changes or deployments to the container or host that could have introduced the suspicious behavior.
-- Investigate the network traffic patterns from the host to determine if there are other unusual outbound connections or if this is an isolated incident.
-- Correlate the alert with other security events or alerts from the same host or container to identify potential patterns or related incidents.
-
-### False positive analysis
-
-- **Legitimate Software Updates**: Containers may initiate outbound connections for legitimate software updates or to download necessary dependencies. Users can handle these by identifying and excluding known update servers or IP ranges from the detection rule.
-- **Cloud Service Integrations**: Containers often connect to cloud services for integrations or data processing tasks. Users should identify these regular connections and create exceptions for specific IP addresses or domains associated with trusted cloud services.
-- **Monitoring and Logging Tools**: Some containers are designed to send logs or monitoring data to external systems. Users can manage these by excluding IPs or domains related to known logging and monitoring services.
-- **Internal Microservices Communication**: In environments where microservices communicate across different subnets, some connections might be flagged. Users should map out their internal network architecture and exclude IP ranges that are part of legitimate internal communications.
-- **Development and Testing Environments**: Containers in development or testing environments might exhibit behaviors that mimic suspicious activity. Users can exclude these environments by tagging them appropriately and adjusting the detection rule to ignore these tags.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized egress connections and potential lateral movement.
-- Conduct a thorough investigation of the container's entrypoint script to identify any malicious code or unauthorized modifications.
-- Review network logs to trace the destination of the egress connection and assess if any data exfiltration occurred.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
-- Remove any identified malicious scripts or files from the container and ensure the entrypoint script is restored to its original, secure state.
-- Apply security patches and updates to the container image and underlying host to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process and network activity within containers for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics, techniques, and procedures (TTPs).
-- Restore the container to its operational state by redeploying it from a clean, verified image.
-- Harden the container environment by enforcing least privilege access, using network segmentation, and regularly scanning for vulnerabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_file_execution_followed_by_deletion.toml b/rules/linux/execution_file_execution_followed_by_deletion.toml
index 85bd242c0fa..4547501ded4 100644
--- a/rules/linux/execution_file_execution_followed_by_deletion.toml
+++ b/rules/linux/execution_file_execution_followed_by_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -68,49 +68,6 @@ sequence by host.id, user.id with maxspan=1m
    file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*",
      "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File Creation, Execution and Self-Deletion in Suspicious Directory
-
-In Linux environments, temporary directories like `/tmp` and `/dev/shm` are often used for legitimate file storage and execution. However, adversaries exploit these directories to create, execute, and delete malicious files quickly, evading detection. The detection rule identifies this pattern by monitoring file creation, execution, and deletion within a short timeframe, focusing on directories frequently targeted by threat actors. This approach helps in identifying and mitigating potential malware activities that attempt to conceal their presence by self-deleting after execution.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file name and path involved in the creation, execution, and deletion sequence. Pay attention to the `file.name` and `file.path` fields.
-- Check the `host.id` and `user.id` fields to determine which host and user account were involved in the suspicious activity. This can help in understanding the context and potential impact.
-- Investigate the process that executed the file by examining the `process.name` and `process.parent.name` fields. Determine if the parent process is a known shell or script interpreter.
-- Use Osquery to list recent file activities in the suspicious directories. Example query: `SELECT * FROM file_events WHERE action IN ('CREATED', 'DELETED') AND path LIKE '/tmp/%' OR path LIKE '/dev/shm/%';`
-- Correlate the timestamps of file creation, execution, and deletion to confirm the short timespan and sequence of events. This can help validate the alert.
-- Examine the network activity on the host around the time of the alert to identify any potential data exfiltration or command and control communication.
-- Check for any other alerts or logs related to the same `host.id` or `user.id` to identify if this is part of a larger attack pattern.
-- Investigate the origin of the file by checking if it was downloaded using tools like `curl`, `wget`, or similar, as indicated in the query.
-- Review the system's process tree to understand the relationship between the processes involved and identify any anomalies.
-- Analyze the system's bash history or other shell histories for the `user.id` involved to uncover any manual commands that might have led to the file's creation and execution.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger this rule, as package managers or scripts often download, execute, and clean up files in temporary directories. Users can handle these by creating exceptions for known update processes or package manager activities.
-- Automated scripts or cron jobs that perform regular maintenance tasks might also match the rule's criteria. To manage this, users can exclude specific scripts or processes that are verified as non-malicious.
-- Development or testing environments where files are frequently created, executed, and deleted as part of normal operations can lead to false positives. Users should consider excluding these environments or specific directories from monitoring if they are known to be secure.
-- Backup or synchronization tools that temporarily store files in monitored directories before moving or deleting them can be mistaken for malicious activity. Users can add exceptions for these tools by identifying their specific process names or file paths.
-- Security tools or monitoring agents that perform integrity checks or other operations in temporary directories might inadvertently trigger the rule. Users should whitelist these tools by their process names or executable paths to prevent false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the files and processes involved in the alert.
-- Capture and preserve relevant logs and artifacts for forensic analysis, including file creation, execution, and deletion events.
-- Terminate any malicious processes identified during the investigation to halt ongoing malicious activities.
-- Remove any malicious files or scripts found in the suspicious directories to prevent re-execution.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed file and process activities, especially in temporary directories.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches are up to date.
-- Harden the system by restricting write and execute permissions in temporary directories and implementing application whitelisting."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml
index aee02066a4a..3df209bbcc9 100644
--- a/rules/linux/execution_interpreter_tty_upgrade.toml
+++ b/rules/linux/execution_interpreter_tty_upgrade.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/09/20"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ simple reverse shell to a fully interactive tty after obtaining initial access t
 stable connection.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Upgrade of Non-interactive Shell"
@@ -51,59 +53,21 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and (
-  (process.name == "stty" and process.args == "raw" and process.args == "-echo" and process.args_count >= 3) or
-  (process.name == "script" and process.args in ("-qc", "-c") and process.args == "/dev/null" and 
-   process.args_count == 4)
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  (
+    (process.name == "stty" and process.args == "raw" and process.args == "-echo" and process.args_count >= 3) or
+    (process.name == "script" and process.args in ("-qc", "-c") and process.args == "/dev/null" and
+    process.args_count == 4)
+  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Upgrade of Non-interactive Shell
-
-In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging attempts to upgrade non-interactive sessions to interactive ones, thus alerting security teams to potential intrusions.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments match those specified in the detection rule, focusing on `stty` or `script` with the relevant arguments.
-- Check the `process.args_count` to ensure it aligns with the expected number of arguments for the detected process execution.
-- Investigate the parent process of the flagged process to understand how the shell was initiated and identify any potential malicious scripts or commands.
-- Use Osquery to list all active processes and their command-line arguments to identify any other suspicious activities. Example query: `SELECT pid, name, cmdline FROM processes WHERE name IN ('stty', 'script');`
-- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
-- Review recent login events and authentication logs to identify any unusual or unauthorized access attempts around the time of the alert.
-- Analyze network connections from the host to identify any suspicious outbound connections that may indicate a reverse shell.
-- Check for any recent file modifications or new files in common directories used for persistence or staging, such as `/tmp` or `/var/tmp`.
-- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
-- Investigate any other alerts or anomalies from the same timeframe to determine if this activity is part of a larger attack campaign.
-
-### False positive analysis
-
-- System administrators or legitimate users may use `stty` or `script` commands for valid purposes such as configuring terminal settings or logging terminal sessions, which can trigger the rule. 
-- Automated scripts or maintenance tasks that involve terminal manipulation might also match the rule's criteria, leading to false positives.
-- To manage these false positives, users can create exceptions for known benign processes or users by adding specific conditions to the detection rule, such as excluding certain user accounts or process paths.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the balance between security and operational needs.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on logs and alerts related to the execution of `stty` and `script` commands.
-- Terminate any unauthorized processes or sessions that have been identified as part of the attack.
-- Review and analyze system logs, including shell history and process execution logs, to understand the attacker's actions and objectives.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed command execution and process creation events for future detection and analysis.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection capabilities and contextual understanding of similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
-- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining vigilance and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml
index 6fa05201c84..9298d4d3de7 100644
--- a/rules/linux/execution_nc_listener_via_rlwrap.toml
+++ b/rules/linux/execution_nc_listener_via_rlwrap.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/09/22"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -19,7 +21,7 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Netcat Listener Established via rlwrap"
@@ -59,57 +61,18 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
-process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and
-process.args : "*l*" and process.args_count >= 4
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
+  process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and
+  process.args : "*l*" and process.args_count >= 4
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Netcat Listener Established via rlwrap
-
-Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring for rlwrap executing netcat with specific arguments, indicating a potential reverse shell setup.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of rlwrap executing netcat with the specified arguments, focusing on the process name and arguments fields.
-- Verify the user account associated with the process execution to determine if it aligns with expected behavior or if it is potentially compromised.
-- Check the parent process of rlwrap to understand how it was initiated and if it was part of a legitimate workflow or script.
-- Investigate the command-line arguments used with netcat to identify the intended target and port, which can provide insight into the potential reverse shell setup.
-- Use Osquery to list all active network connections and identify any unusual or unauthorized connections that may correlate with the netcat listener. Example query: `SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name = 'nc' OR name = 'ncat' OR name = 'netcat' OR name = 'nc.openbsd' OR name = 'socat');`
-- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that may indicate a broader attack chain.
-- Check system logs for any failed login attempts or other anomalies around the time of the alert to assess if there was an attempt to gain unauthorized access.
-- Review the system's bash history or other shell histories for the user to identify any manual commands that may have been executed leading up to the alert.
-- Investigate any file modifications or new file creations in the user's home directory or other sensitive directories that could indicate malicious activity.
-- Correlate the alert with other security events or alerts from the same host or user to determine if this is part of a larger attack pattern or isolated incident.
-
-### False positive analysis
-
-- Development and testing environments: In environments where developers or system administrators frequently use rlwrap with netcat for legitimate testing or debugging purposes, this rule may trigger false positives. Users can manage these by creating exceptions for specific user accounts or IP addresses known to be involved in such activities.
-- Automated scripts and tools: Some automated scripts or tools may use rlwrap and netcat for legitimate purposes, such as network diagnostics or performance testing. To handle these, users can exclude specific scripts or processes by identifying their unique command-line arguments or execution paths.
-- Security training exercises: In scenarios where security teams conduct training exercises or penetration testing, rlwrap and netcat might be used intentionally. Users should coordinate with security teams to whitelist these activities during specific time frames or for particular user groups.
-- System maintenance tasks: Certain system maintenance tasks might involve the use of rlwrap and netcat for remote management or troubleshooting. Users can address these false positives by setting up exceptions for maintenance windows or specific maintenance scripts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on logs and network traffic related to the execution of rlwrap and netcat.
-- Terminate any unauthorized processes associated with rlwrap and netcat to disrupt the adversary's access.
-- Review user accounts and privileges on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
-- Apply patches and updates to the operating system and any vulnerable applications to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more effectively.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to monitor for similar activities.
-- Restore the system from a known good backup to ensure the integrity of the operating environment.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks associated with tools like netcat and rlwrap, emphasizing the importance of secure configurations and monitoring."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
index 2c77d19224f..4caaf8cd36e 100644
--- a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
+++ b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -61,52 +61,6 @@ sample by host.id, process.pid, process.name
   [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
    not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Connection from Binary with RWX Memory Region
-
-In Linux environments, the `mprotect()` system call adjusts memory permissions, potentially enabling read, write, and execute (RWX) access. Adversaries exploit this to execute malicious code in memory, often followed by network activity. The detection rule identifies such behavior by monitoring for RWX memory changes and subsequent network connections, excluding benign processes like `httpd`.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id`, `process.pid`, and `process.name` involved in the suspicious activity.
-- Verify the legitimacy of the process by checking its path and hash against known good software or malware databases.
-- Use `ps` or `top` commands to gather more information about the process, such as its parent process, command-line arguments, and current status.
-- Investigate the network connection details, including `destination.ip` and `destination.port`, to determine if the connection is to a known malicious or suspicious IP address.
-- Check the process's history of network connections to see if it has made similar connections in the past.
-- Use Osquery to gather more context about the process and its network activity. For example, run the following query to list all network connections made by the process:
-  ```sql
-  SELECT pid, local_address, local_port, remote_address, remote_port, state FROM process_open_sockets WHERE pid = <process.pid>;
-  ```
-- Examine the system logs for any other suspicious activities or anomalies around the time of the alert, such as unusual login attempts or file modifications.
-- Investigate the memory region changes by reviewing the `mprotect` syscall logs to understand why the process required RWX permissions.
-- Check for any recent changes to the system, such as software installations or updates, that might explain the behavior.
-- Consult threat intelligence sources to see if there are any known campaigns or malware that match the observed behavior.
-
-### False positive analysis
-
-- Certain legitimate applications may use `mprotect()` to change memory permissions for performance optimization or legitimate functionality, leading to false positives. Users should identify these applications and consider excluding them from the rule.
-- Development tools and environments, such as compilers or interpreters, might exhibit this behavior during normal operation. Users can create exceptions for these processes if they are verified as non-malicious.
-- Security software or monitoring tools may also trigger this rule due to their nature of scanning and analyzing memory. Users should verify these tools and exclude them if they are confirmed to be safe.
-- Some system utilities or services might temporarily use RWX memory regions for legitimate purposes. Users should monitor these utilities and exclude them if they consistently trigger false positives without any associated threat.
-- To manage false positives, users can refine the rule by adding specific process names or paths to an exclusion list, ensuring that only verified non-threatening behaviors are excluded.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the process that initiated the RWX memory change and network connection, focusing on the process name, PID, and associated binaries.
-- Analyze the network traffic logs to determine the destination of the network connection and assess if any data exfiltration occurred.
-- Terminate any suspicious processes identified during the investigation to halt potential malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Restore the system to a known good state using backups or system snapshots, ensuring that any malicious changes are removed.
-- Implement enhanced logging policies to capture detailed process execution and network activity, aiding in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing strict memory protection policies, to reduce the attack surface.
-- Review and update security policies and procedures to incorporate lessons learned from the incident, ensuring better preparedness for future threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_network_event_post_compilation.toml b/rules/linux/execution_network_event_post_compilation.toml
index f81bb4c0480..366caed4d72 100644
--- a/rules/linux/execution_network_event_post_compilation.toml
+++ b/rules/linux/execution_network_event_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -63,48 +63,6 @@ sequence by host.id with maxspan=1m
      process.name in ("simpleX", "conftest", "ssh", "python", "ispnull", "pvtui")
    )] by process.name
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Connection via Recently Compiled Executable
-
-In Linux environments, compiling and executing programs is routine, but adversaries can exploit this by compiling malicious code to establish unauthorized network connections, such as reverse shells, to control systems remotely. The detection rule identifies this threat by monitoring a sequence of events: program compilation, file creation, execution, and suspicious network activity, flagging potential command-and-control setups.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host.id and process.args associated with the compilation event to understand the context of the executable creation.
-- Examine the file.name of the recently created executable to determine if it matches known malicious binaries or if it appears suspicious based on naming conventions.
-- Investigate the process.name of the executed file to verify if it aligns with legitimate software or if it is an unexpected or unauthorized application.
-- Analyze the network connection details, focusing on the destination.ip to identify if the connection was attempted to a known malicious IP or an unusual external address.
-- Use Osquery to gather additional context on the host by running a query to list all processes executed by the user who initiated the compilation, such as: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');`
-- Check the process tree for the executed file to trace its parent processes and understand the sequence of events leading to its execution.
-- Correlate the timing of the compilation, file creation, and network connection events to determine if they occurred in quick succession, indicating potential malicious activity.
-- Investigate any other network connections from the same host around the time of the alert to identify additional suspicious activity or patterns.
-- Review system logs and audit logs on the host for any other anomalies or indicators of compromise that coincide with the alert.
-- Consult threat intelligence sources to check if the destination IP or any other indicators from the alert are associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Developers frequently compile and test new code, which can trigger this rule. To manage this, users can create exceptions for specific user accounts or directories commonly used for development activities.
-- Automated build systems or continuous integration pipelines may compile and execute code as part of their normal operation. Users can exclude these systems by identifying and whitelisting their specific process names or host identifiers.
-- Some legitimate applications may compile code at runtime for performance optimization or other reasons. Users should identify these applications and add them to an exception list to prevent false alerts.
-- Network monitoring tools or security applications might establish connections that appear suspicious but are benign. Users can exclude these processes by adding their names to the exception list, ensuring they are not flagged by the rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the malicious executable, including reviewing recent file changes and user activity logs.
-- Terminate any suspicious processes identified during the investigation, especially those related to the compiled executable and unauthorized network connections.
-- Remove the malicious executable and any associated files from the system to prevent re-execution.
-- Review and update firewall rules to block outbound connections to known malicious IP addresses and domains.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network connection events for future investigations.
-- Integrate threat intelligence feeds to automatically update detection rules with known indicators of compromise (IOCs) related to command-and-control activities.
-- Restore the system from a known good backup to ensure all traces of the compromise are removed and the system is returned to a secure operational state.
-- Apply system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and regularly updating software to mitigate future risks."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_perl_tty_shell.toml b/rules/linux/execution_perl_tty_shell.toml
index f2e19045ca1..e8399decc4a 100644
--- a/rules/linux/execution_perl_tty_shell.toml
+++ b/rules/linux/execution_perl_tty_shell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -70,50 +70,6 @@ query = '''
 event.category:process and host.os.type:linux and event.type:(start or process_started) and process.name:perl and
   process.args:("exec \"/bin/sh\";" or "exec \"/bin/dash\";" or "exec \"/bin/bash\";")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Interactive Terminal Spawned via Perl
-
-Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, upgrading basic shells to fully interactive ones. The detection rule identifies such activity by monitoring process events where Perl executes shell commands, signaling potential misuse for unauthorized access.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the specific process arguments indicating an interactive terminal spawn via Perl, such as "exec \\"/bin/sh\\";", "exec \\"/bin/dash\\";", or "exec \\"/bin/bash\\";".
-- Examine the process tree to identify the parent process of the Perl execution, which may provide insights into how the Perl script was initiated.
-- Check the user account associated with the Perl process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
-- Investigate the source IP address and network connections associated with the host to identify any suspicious or unauthorized access attempts.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'perl' AND cmdline LIKE '%exec%';` to list all Perl processes with execution commands.
-- Analyze recent login events on the host to identify any unusual or unauthorized access that may correlate with the timing of the Perl process execution.
-- Review file modification and creation events around the time of the alert to detect any scripts or files that may have been used to execute the Perl command.
-- Check for any other alerts or anomalies on the host that may indicate a broader attack or compromise, such as other scripting or command execution alerts.
-- Investigate the environment for any signs of privilege escalation attempts or lateral movement that may have been facilitated by the interactive terminal.
-- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- Routine administrative scripts: System administrators may use Perl scripts to automate tasks that involve spawning shells for legitimate purposes, such as maintenance or configuration changes. These activities can trigger the detection rule but are not malicious.
-- Development and testing environments: Developers might use Perl to test scripts that require shell access, leading to false positives. These environments often have frequent, non-threatening shell spawns.
-- Monitoring and automation tools: Some monitoring or automation tools may use Perl to execute shell commands as part of their normal operation, which can be mistaken for malicious activity.
-- To manage false positives, users can create exceptions for known benign scripts or processes by whitelisting specific script paths or process arguments that are regularly used in legitimate operations.
-- Implementing a baseline of normal activity for specific hosts or environments can help differentiate between expected and suspicious behavior, reducing the likelihood of false positives.
-- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
-- Investigate the process tree to identify the parent process and any child processes spawned by the Perl script to understand the scope of the compromise.
-- Terminate any malicious processes identified during the investigation to halt ongoing unauthorized activities.
-- Review system logs and security alerts to determine the initial access vector and any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the affected system from a known good backup to ensure the removal of any persistent threats or backdoors.
-- Apply security patches and updates to the operating system and installed applications to mitigate known vulnerabilities.
-- Conduct a security review and harden the system by disabling unnecessary services, enforcing least privilege access, and implementing multi-factor authentication (MFA) where possible."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_potential_hack_tool_executed.toml b/rules/linux/execution_potential_hack_tool_executed.toml
index 95ed4f051d6..c1c2f7c4f02 100644
--- a/rules/linux/execution_potential_hack_tool_executed.toml
+++ b/rules/linux/execution_potential_hack_tool_executed.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/09/22"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ this rule should be investigated further, as hack tools are commonly used by blu
 well.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Hack Tool Launched"
@@ -53,12 +55,14 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-event.action in ("exec", "exec_event", "executed", "process_started") and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 process.name in~ (
   // exploitation frameworks
   "crackmapexec", "msfconsole", "msfvenom", "sliver-client", "sliver-server", "havoc",
@@ -77,52 +81,6 @@ process.name in~ (
   "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Linux Hack Tool Launched
-
-In Linux environments, various tools are used for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies the execution of known hacking tools by monitoring process start events. It flags tools often used in exploitation, scanning, and enumeration, enabling analysts to investigate potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name that triggered the alert, using the `process.name` field to understand which tool was executed.
-- Check the `host.os.type` and `event.type` fields to confirm the environment and event type, ensuring the alert pertains to a Linux system and a process start event.
-- Investigate the `event.action` field to determine the exact action that was performed, such as "exec" or "process_started," to understand the context of the execution.
-- Examine the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with the same name and their parent processes:
-  ```sql
-  SELECT pid, name, path, parent, user FROM processes WHERE name = '<process_name>';
-  ```
-- Analyze the parent process of the suspicious execution to identify if it was spawned by a legitimate application or script.
-- Review system logs and audit logs around the time of the alert to identify any other suspicious activities or related events.
-- Check for any network connections initiated by the process using network monitoring tools or logs to identify potential data exfiltration or communication with command and control servers.
-- Investigate the file system for any new or modified files that could be related to the execution of the tool, focusing on directories commonly used for temporary or unauthorized files.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack or isolated incident.
-
-### False positive analysis
-
-- System administrators and security teams often use the flagged tools for legitimate purposes such as network diagnostics, vulnerability assessments, and system audits, which can trigger false positives.
-- Blue team exercises and penetration testing activities may involve the use of these tools, leading to alerts that are not indicative of malicious activity.
-- To manage these false positives, users can create exceptions for specific hosts or user accounts known to regularly use these tools for authorized activities.
-- Implementing a whitelist for certain processes or users can help reduce noise from expected and non-threatening tool usage.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the flagged process to determine if it was executed with malicious intent or as part of legitimate administrative tasks.
-- Review system logs and process execution history to identify any additional suspicious activities or related processes.
-- If malicious activity is confirmed, remove any unauthorized tools or scripts and change all potentially compromised credentials.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for alerts.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_potentially_overly_permissive_container_creation.toml b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
index 0c05f74de08..d70d112d89b 100644
--- a/rules/linux/execution_potentially_overly_permissive_container_creation.toml
+++ b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -55,48 +55,6 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:docker and
 process.args:(run and --privileged)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privileged Docker Container Creation
-
-Docker containers are lightweight, portable units that package applications and their dependencies. The `--privileged` flag grants containers extensive host access, posing security risks. Adversaries exploit this to escalate privileges or escape containers. The detection rule identifies unusual privileged container creation by monitoring specific process actions and arguments, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `--privileged` flag in the `process.args` field, indicating a privileged container creation attempt.
-- Examine the `process.name` field to ensure the process involved is indeed `docker`, confirming the context of the alert.
-- Investigate the `event.category` and `event.type` fields to verify that the event is categorized as a process start, which aligns with the creation of a new container.
-- Analyze the `event.action` field to ensure it reflects an execution action, which is critical for understanding the nature of the process activity.
-- Identify the parent process of the Docker command using the `process.parent.name` field to determine if it originates from an unusual or suspicious source.
-- Use Osquery to gather additional context about the Docker process. For example, run the query: `SELECT * FROM processes WHERE name = 'docker';` to retrieve detailed information about the Docker process and its attributes.
-- Check the user context under which the Docker process was executed by examining the `user.name` field to assess if it aligns with expected administrative activities.
-- Investigate the timeline of events leading up to the alert by reviewing related logs and events to identify any preceding suspicious activities.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack pattern or isolated incident.
-- Document findings and gather evidence, including logs and process details, to support further analysis and potential escalation to the incident response team.
-
-### False positive analysis
-
-- Known false positives for the Privileged Docker Container Creation rule may include legitimate administrative tasks where privileged containers are intentionally created for maintenance or testing purposes. These activities might be performed by system administrators or developers who require elevated access for specific operations.
-- To manage these false positives, users can create exceptions for known and trusted parent processes or specific user accounts that regularly perform these actions. This can be done by updating the detection rule to exclude certain process parent names or user identifiers that are recognized as non-threatening.
-- Another approach is to implement a whitelist of specific container images or commands that are known to be safe and necessary for regular operations. This helps in reducing noise from expected and benign privileged container creations.
-- Regularly reviewing and updating the list of exceptions is crucial to ensure that new legitimate use cases are accounted for while maintaining security against potential threats.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the network.
-- Investigate the parent process that initiated the privileged container creation to determine if it was a legitimate action or part of a malicious activity.
-- Review logs and process histories to identify any other suspicious activities or commands executed around the time of the alert.
-- If malicious activity is confirmed, terminate the unauthorized container and any associated processes to halt the attack.
-- Escalate the incident to the security operations team for a deeper forensic analysis and to assess the scope of the compromise.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate with SIEM solutions to correlate events and improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by redeploying clean container images and ensuring no residual malicious artifacts remain.
-- Apply security hardening measures such as restricting the use of the --privileged flag and enforcing least privilege principles for container operations.
-- Educate and train staff on secure container management practices and the risks associated with privileged container operations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_process_started_in_shared_memory_directory.toml b/rules/linux/execution_process_started_in_shared_memory_directory.toml
index 9069976d6bb..f3f896a29d3 100644
--- a/rules/linux/execution_process_started_in_shared_memory_directory.toml
+++ b/rules/linux/execution_process_started_in_shared_memory_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -74,48 +74,6 @@ user.id == "0" and process.executable : ("/dev/shm/*", "/run/shm/*", "/var/run/*
 not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", 
 "/var/run/argo/argoexec") and not process.parent.command_line : "/usr/bin/runc init"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Binary Executed from Shared Memory Directory
-
-Shared memory directories in Linux, such as /dev/shm and /run/shm, are used for inter-process communication, allowing processes to exchange data efficiently. Adversaries exploit these directories by placing executables there, leveraging their high uptime for persistence. The detection rule identifies abnormal execution by the root user in these directories, excluding known benign processes, to flag potential backdoor activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the execution of a binary from a shared memory directory by the root user, focusing on the `process.executable` field to identify the exact path and binary executed.
-- Check the `event.timestamp` to determine when the execution occurred and correlate it with any other suspicious activities or alerts around the same time.
-- Investigate the `process.parent.command_line` to understand the parent process that initiated the execution, which might provide insights into how the binary was executed.
-- Use Osquery to list all files in the shared memory directories to identify any other suspicious binaries or scripts: `SELECT * FROM file WHERE path LIKE '/dev/shm/%' OR path LIKE '/run/shm/%' OR path LIKE '/var/run/%' OR path LIKE '/var/lock/%';`
-- Examine the `user.id` field to confirm the execution was indeed by the root user and check for any unauthorized privilege escalation activities.
-- Analyze the `process.command_line` to gather more context about the executed command and its arguments, which might reveal the intent or functionality of the binary.
-- Cross-reference the `host.os.type` and `event.type` fields to ensure the alert pertains to a Linux system and involves a process start event, confirming the relevance of the alert.
-- Investigate the system logs around the time of the alert for any anomalies or related events, such as unauthorized access attempts or configuration changes.
-- Check for any network connections initiated by the suspicious process using Osquery: `SELECT * FROM process_open_sockets WHERE pid = <suspicious_process_id>;`
-- Review historical data for any previous alerts or activities involving the same `process.executable` or similar patterns to identify potential persistence mechanisms or repeated attack attempts.
-
-### False positive analysis
-
-- Known false positives for the Binary Executed from Shared Memory Directory rule include legitimate processes that are executed by root in shared memory directories for operational purposes. These can include container management tools like Docker, which may use these directories for temporary storage and execution.
-- To manage these false positives, users can create exceptions for specific processes that are known to be benign. This can be done by adding exclusions for process executables that are frequently observed and verified as non-threatening, such as those related to Docker or other container orchestration tools.
-- Users should regularly review and update the list of excluded processes to ensure that only legitimate activities are excluded, minimizing the risk of overlooking potential threats.
-- It is important to maintain a balance between reducing noise from false positives and ensuring that potentially malicious activities are not ignored. This can be achieved by closely monitoring the behavior of excluded processes and adjusting the detection rule as necessary.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the executed binary and its origin, examining logs and process trees for any related suspicious activity.
-- Terminate any malicious processes identified during the investigation to halt ongoing threats.
-- Remove the malicious binary from the shared memory directory and any other locations it may have been copied to.
-- Review and analyze system logs, including authentication and access logs, to identify potential unauthorized access or privilege escalation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
-- Harden the system by implementing least privilege access controls, disabling unnecessary services, and regularly auditing shared memory directories for unauthorized executables."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml
index 65d37b76682..5dd00e41674 100644
--- a/rules/linux/execution_python_tty_shell.toml
+++ b/rules/linux/execution_python_tty_shell.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2020/04/15"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -11,7 +13,7 @@ Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a
 interactive tty after obtaining initial access to a host.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Interactive Terminal Spawned via Python"
@@ -50,12 +52,13 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 (
   (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh",
    "fish") and process.parent.args_count >= 3 and process.parent.args : "*pty.spawn*" and process.parent.args : "-c") or
@@ -63,53 +66,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
    "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1)
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Interactive Terminal Spawned via Python
-
-Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns shell environments, focusing on specific patterns in process arguments and parent-child relationships indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a Python process spawning a shell, focusing on the `process.parent.name` and `process.name` fields to verify the parent-child relationship.
-- Examine the `process.parent.args` field to identify the specific command used, looking for patterns like `*pty.spawn*` and `-c` that indicate an attempt to spawn an interactive terminal.
-- Check the `process.args` field for any suspicious shell commands that might have been executed, especially if the `args_count` is minimal, suggesting a direct shell invocation.
-- Investigate the `host.os.type` to ensure the alert is relevant to a Linux environment, as the rule is specifically designed for Linux systems.
-- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes spawned by Python that match the suspicious criteria:
-  ```sql
-  SELECT pid, name, cmdline, parent FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name LIKE 'python%') AND name IN ('bash', 'dash', 'ash', 'sh', 'tcsh', 'csh', 'zsh', 'ksh', 'fish');
-  ```
-- Analyze the `event.type` and `event.action` fields to confirm that the process was indeed started and executed, which aligns with the rule's focus on process initiation.
-- Correlate the alert with any recent network activity logs to identify potential reverse shell connections or data exfiltration attempts.
-- Review user activity logs to determine if the Python process was initiated by a legitimate user or if it might be indicative of compromised credentials.
-- Check for any recent changes in user privileges or group memberships that could have facilitated the execution of such commands.
-- Investigate any other alerts or anomalies on the host around the same timeframe to identify potential lateral movement or further exploitation attempts.
-
-### False positive analysis
-
-- System administrators and developers often use Python scripts to automate tasks that require spawning shell environments, which can trigger this detection rule. These activities are typically benign and part of routine operations.
-- Automated deployment tools and configuration management systems like Ansible or Puppet may execute Python scripts that spawn shells as part of their normal operation, leading to false positives.
-- Security tools and monitoring solutions might use Python scripts to perform checks or gather system information, inadvertently matching the detection criteria.
-- To manage these false positives, users can create exceptions for known scripts or processes by whitelisting specific parent process names or arguments that are verified as non-threatening.
-- Implementing a baseline of normal behavior for Python processes in the environment can help distinguish between legitimate and suspicious activity, allowing for more accurate tuning of the detection rule.
-- Regularly reviewing and updating the list of exceptions based on changes in administrative practices or tool usage can help maintain the effectiveness of the detection rule while minimizing false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm the presence of a reverse shell and identify any additional compromised systems or accounts.
-- Terminate any suspicious processes identified by the detection rule, particularly those involving Python spawning shell environments.
-- Review and analyze logs from the affected system and network devices to trace the attacker's actions and entry point.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on command and scripting interpreter usage.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Harden the environment by implementing least privilege access controls, disabling unnecessary services, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml
index 77c579f97b6..9f0f14b0134 100644
--- a/rules/linux/execution_python_webserver_spawned.toml
+++ b/rules/linux/execution_python_webserver_spawned.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/11/04"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -11,7 +13,7 @@ This rule identifies when a web server is spawned via Python. Attackers may use
 exfiltrate/infiltrate data or to move laterally within a network.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Web Server Spawned via Python"
@@ -49,65 +51,23 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
-  (process.name like "python*" and process.args in ("http.server", "SimpleHTTPServer")) or
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
   (
-    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
-    process.command_line like~ "*python* -m http.server*"
+    (process.name like "python*" and process.args in ("http.server", "SimpleHTTPServer")) or
+    (
+      process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+      process.command_line like~ "*python* -m http.server*"
+    )
   )
-)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Web Server Spawned via Python
-
-Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this by launching servers to exfiltrate data or facilitate lateral movement. The detection rule identifies such activity by monitoring process executions on Linux systems, specifically looking for Python or shell commands initiating HTTP servers, indicating potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments, ensuring they match the criteria for spawning a web server via Python.
-- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Investigate the parent process of the Python or shell command to understand how the web server was initiated and if it was part of a larger script or command sequence.
-- Examine the network connections on the host to identify any unusual outbound connections that could indicate data exfiltration.
-- Use Osquery to list all active network listeners on the host to verify if the Python web server is currently running:
-  ```sql
-  SELECT pid, name, port, address FROM listening_ports WHERE pid IN (SELECT pid FROM processes WHERE name LIKE 'python%');
-  ```
-- Analyze the command line arguments of the process to determine the specific directory being served, which could provide insight into the data being accessed or shared.
-- Review system logs for any recent login attempts or changes in user permissions that could suggest unauthorized access.
-- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or related activities.
-- Investigate any recent file modifications or creations in the directory being served by the web server to identify potential data staging or tampering.
-- Check for any scheduled tasks or cron jobs that might have been set up to automate the execution of the Python web server, indicating a persistent threat.
-
-### False positive analysis
-
-- Development and testing environments often use Python's built-in HTTP server for legitimate purposes, such as serving static files or testing web applications, which can trigger false positives.
-- System administrators or developers may use Python's HTTP server for quick file sharing within a secure network, leading to benign alerts.
-- Automated scripts or CI/CD pipelines might spawn temporary web servers for testing purposes, which could be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for known development or testing environments by excluding specific hostnames or IP addresses from the detection rule.
-- Users can also whitelist certain user accounts or process execution paths that are known to frequently and legitimately use Python's HTTP server.
-- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration or lateral movement.
-- Investigate the process execution details, including the user account that initiated the server, to determine if it was authorized or malicious.
-- Review system logs and network traffic to identify any data that may have been exfiltrated or any other systems that may have been accessed.
-- Terminate the unauthorized Python web server process to stop any ongoing malicious activity.
-- Conduct a thorough scan of the system for any additional malicious scripts or tools that may have been deployed by the attacker.
-- Reset credentials and review permissions for the user account involved to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_remote_code_execution_via_postgresql.toml b/rules/linux/execution_remote_code_execution_via_postgresql.toml
index a1e129687a5..67ad46d0a1e 100644
--- a/rules/linux/execution_remote_code_execution_via_postgresql.toml
+++ b/rules/linux/execution_remote_code_execution_via_postgresql.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -68,49 +68,6 @@ event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "p
   process.parent.command_line like "*BECOME-SUCCESS-*"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Code Execution via Postgresql
-
-PostgreSQL, a robust open-source database system, is often targeted by attackers seeking to execute arbitrary code. Adversaries exploit vulnerabilities like SQL injection or gain unauthorized access to execute shell commands, potentially leading to system compromise. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions with specific patterns, while excluding legitimate operations, to flag potential malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the triggering conditions, focusing on the `user.name` field to ensure the process was initiated by the "postgres" user.
-- Examine the `process.parent.args` and `process.args` fields to identify the specific shell commands executed, looking for patterns that match "*sh" and "echo*".
-- Check the `process.parent.name` and `process.command_line` fields to rule out any false positives by verifying that the process is not associated with known legitimate operations like "puppet" or commands containing "BECOME-SUCCESS".
-- Investigate the `event.type` and `event.action` fields to understand the nature of the process start event, ensuring it aligns with suspicious activities such as "exec" or "fork".
-- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE name = 'sh' AND uid = (SELECT uid FROM users WHERE username = 'postgres');` to identify any other related processes initiated by the postgres user.
-- Analyze the network activity associated with the PostgreSQL server during the time of the alert to identify any unusual connections or data transfers.
-- Review the PostgreSQL logs for any signs of unauthorized access or SQL injection attempts that could have led to the execution of arbitrary code.
-- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns.
-- Investigate the system's history for any recent changes or updates that could have introduced vulnerabilities or been exploited by attackers.
-- Consult threat intelligence sources to determine if there are any known exploits or attack patterns targeting PostgreSQL that match the observed behavior.
-
-### False positive analysis
-
-- Legitimate administrative scripts: Routine maintenance or administrative scripts executed by the PostgreSQL user might match the rule's criteria, especially if they involve shell commands for database management or system updates. Users can handle these by identifying and excluding specific scripts or command patterns that are known to be safe.
-- Automation tools: Tools like Puppet, Ansible, or other configuration management systems may execute shell commands as part of their normal operations. These can be excluded by adding exceptions for known automation tool processes or command lines.
-- Backup and monitoring processes: Scheduled backup scripts or monitoring tools that interact with the PostgreSQL database might trigger the rule. Users should review these processes and exclude them if they are verified to be non-threatening.
-- Custom user scripts: Organizations may have custom scripts developed for specific tasks that inadvertently match the rule's criteria. These should be reviewed, and if deemed safe, added to the exclusion list to prevent false positives.
-- Development and testing environments: In environments where developers frequently test new scripts or commands, the rule might generate false positives. Users can manage this by creating separate rules or exceptions for development and testing environments to reduce noise.
-
-### Response and remediation
-
-- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and method of the attack, focusing on logs and any suspicious activity around the time of the alert.
-- Review PostgreSQL logs and system logs for any unauthorized access attempts or anomalies that align with the MITRE ATT&CK T1059 technique.
-- If unauthorized access is confirmed, reset credentials for the PostgreSQL user and any other potentially compromised accounts.
-- Apply the latest security patches and updates to PostgreSQL and the underlying operating system to mitigate known vulnerabilities.
-- Implement enhanced logging and monitoring for PostgreSQL activities, ensuring that all command executions and access attempts are logged and reviewed regularly.
-- Integrate security tools such as intrusion detection systems (IDS) and security information and event management (SIEM) solutions to improve threat detection capabilities.
-- Develop and enforce a strict access control policy, limiting PostgreSQL access to only necessary users and services.
-- Conduct a post-incident review to identify gaps in security posture and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to potential security threats, emphasizing the importance of maintaining a secure database environment."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml
index ff7c420b270..4333ff0ccd9 100644
--- a/rules/linux/execution_shell_openssl_client_or_server.toml
+++ b/rules/linux/execution_shell_openssl_client_or_server.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/07/30"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ establish a secure connection to a remote server or to create a secure server to
 may be used to exfiltrate data or establish a command and control channel.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Openssl Client or Server Activity"
@@ -51,60 +53,19 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame"
+    "Data Source: Elastic Endgame",
+    "Data Source: SentinelOne"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
-process.name == "openssl" and (
-  (process.args == "s_client" and process.args : ("-connect", "*:*") and not process.args == "-showcerts") or
-  (process.args == "s_server" and process.args == "-port")
-) and
-not process.parent.executable in ("/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert")
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
+  process.name == "openssl" and (
+    (process.args == "s_client" and process.args : ("-connect", "*:*") and not process.args == "-showcerts") or
+    (process.args == "s_server" and process.args == "-port")
+  ) and
+  not process.parent.executable in ("/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Openssl Client or Server Activity
-
-OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to establish encrypted connections. Adversaries may exploit OpenSSL to create secure channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting client or server activities that deviate from typical operations, while excluding known benign processes.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific process execution that triggered the rule, focusing on the `process.name`, `process.args`, and `process.parent.executable` fields.
-- Verify the legitimacy of the `openssl` process by checking the `process.parent.executable` to determine if it originates from a known benign source or a suspicious one.
-- Examine the `process.args` to identify whether the `openssl` command is being used as a client (`s_client`) or server (`s_server`) and note any unusual arguments or patterns.
-- Investigate the network connections associated with the `openssl` process using tools like `netstat` or `ss` to identify any suspicious remote IP addresses or ports.
-- Use Osquery to gather additional context about the `openssl` process. For example, run the following query to list all processes with their network connections: `SELECT pid, name, path, cmdline, remote_address, remote_port FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE name = 'openssl';`
-- Check system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any related authentication attempts or anomalies around the time the `openssl` process was executed.
-- Review user activity logs to determine if the `openssl` process was initiated by a legitimate user or if there are signs of compromised credentials.
-- Investigate any file transfers or data exfiltration attempts by examining file access logs and monitoring tools for unusual data movement.
-- Correlate the `openssl` activity with other security alerts or logs to identify potential patterns or coordinated actions indicative of a larger attack.
-- Consult threat intelligence sources to determine if the IP addresses or domains associated with the `openssl` connections are known to be malicious or part of a threat actor's infrastructure.
-
-### False positive analysis
-
-- Known false positives for the Openssl Client or Server Activity rule may include legitimate administrative tasks where OpenSSL is used for secure communications, such as system administrators testing SSL/TLS connections or setting up secure servers for internal use.
-- Automated scripts or monitoring tools that use OpenSSL for regular checks, such as certificate validation or network diagnostics, can trigger this rule. These processes often have predictable patterns and can be excluded by identifying their parent processes or specific command-line arguments.
-- To manage these false positives, users can create exceptions by adding known benign parent processes to the exclusion list, as seen with "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" in the rule. This helps in reducing noise and focusing on truly suspicious activities.
-- Regularly review and update the exclusion list to accommodate new legitimate processes that may arise in the environment, ensuring that the detection rule remains effective without generating excessive false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized connections established using OpenSSL.
-- Review system logs and network traffic to identify any additional indicators of compromise or related suspicious activities.
-- Terminate any unauthorized OpenSSL processes and remove any malicious scripts or binaries found on the system.
-- Change all credentials and keys that may have been exposed during the incident to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are hardened.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address any deficiencies."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml
index c79a78fdd30..1b18cd14333 100644
--- a/rules/linux/execution_shell_via_background_process.toml
+++ b/rules/linux/execution_shell_via_background_process.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/09/20"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -11,7 +13,7 @@ Monitors for the execution of background processes with process arguments capabl
 channel. This may indicate the creation of a backdoor reverse connection, and should be investigated further.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Reverse Shell via Background Process"
@@ -50,58 +52,18 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
-process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and 
-process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
+  process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and 
+  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Reverse Shell via Background Process
-
-In Linux environments, adversaries may exploit shell capabilities to establish reverse shells, allowing remote control over a compromised system. By leveraging background processes like `setsid` or `nohup` with socket connections via `/dev/tcp`, attackers can create persistent backdoors. The detection rule identifies such activities by monitoring specific process executions and arguments, signaling potential reverse shell attempts for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious process executions involving `setsid` or `nohup` with `/dev/tcp` in the arguments, as these are key indicators of potential reverse shell activity.
-- Examine the `process.parent.name` field to identify the shell used to execute the command, which can provide insights into the attacker's preferred environment or tools.
-- Check the `process.args` field for any additional suspicious patterns or commands that might indicate further malicious intent or context.
-- Investigate the `process.parent.pid` to trace back to the parent process and understand the origin of the suspicious activity.
-- Use Osquery to gather more information about the process tree and environment variables by running a query like: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;`.
-- Analyze the network connections on the host to identify any unusual outbound connections that might correlate with the reverse shell attempt, using tools like `netstat` or `ss`.
-- Review the user's command history files (e.g., `.bash_history`) for any evidence of manual execution or testing of reverse shell commands.
-- Check for any recent changes in user accounts or permissions that might have facilitated the execution of the reverse shell.
-- Investigate any related logs, such as authentication logs, to identify potential unauthorized access or privilege escalation attempts.
-- Correlate the findings with other security alerts or logs to determine if this activity is part of a larger attack campaign or isolated incident.
-
-### False positive analysis
-
-- Legitimate administrative scripts or maintenance tasks may use `setsid` or `nohup` with `/dev/tcp` for network communication, leading to false positives. Users should review such scripts and, if verified as non-threatening, create exceptions for these specific processes.
-- Automated monitoring or logging tools might employ similar techniques to establish network connections for data collection or alerting purposes. Identifying these tools and excluding their process signatures can reduce false alerts.
-- Developers or system administrators testing network applications might use `/dev/tcp` in shell scripts for debugging or connectivity checks. These activities should be documented, and exceptions should be configured for known testing environments.
-- Backup or synchronization scripts that use shell commands to transfer data between systems could trigger the rule. Users should ensure these scripts are secure and add them to an allowlist if they are deemed safe.
-- Custom user scripts that are part of routine operations might inadvertently match the rule's criteria. Regular audits and documentation of such scripts can help in distinguishing between benign and malicious activities, allowing for appropriate exclusions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the process tree and network connections to identify any additional compromised systems or lateral movement.
-- Terminate any suspicious processes identified as part of the reverse shell activity to halt the attacker's access.
-- Review and analyze logs from the affected system and any connected systems to gather evidence and understand the scope of the compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Restore the system from a known good backup to ensure that no malicious code remains on the system.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Implement enhanced logging and monitoring policies to detect similar activities in the future, focusing on process execution and network connections.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
index cdf26300557..dcbcb5da900 100644
--- a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
+++ b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -69,49 +69,6 @@ sequence by host.id, process.entity_id with maxspan=5s
        (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*")
    )]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Reverse Shell via Child
-
-Reverse shells are a common technique used by attackers to gain remote access to a system by initiating a connection from the target back to the attacker's machine. This detection rule identifies such activity by monitoring for network events followed by suspicious shell process creation. It flags unusual command-line arguments or parent processes, indicating potential exploitation of shell interpreters for unauthorized access.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and process entity IDs involved in the suspicious activity.
-- Examine the network event details, focusing on the destination IP address to determine if it is known or associated with malicious activity. Check if the IP is external and not within the specified internal ranges.
-- Analyze the process creation event, paying close attention to the command-line arguments used, such as "-i" or "-l", which may indicate interactive shell usage.
-- Investigate the parent process of the shell, especially if it is "socat" with arguments containing "exec", to understand the context of the shell execution.
-- Use Osquery to gather additional context on the process by running a query like: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve detailed information about the process, including its parent process and command-line arguments.
-- Check the process execution timeline to see if there are any other related processes or network connections that occurred around the same time.
-- Review the user's activity associated with the process to determine if the actions align with their typical behavior or if they appear suspicious.
-- Investigate any other network connections from the host around the time of the alert to identify potential lateral movement or data exfiltration attempts.
-- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
-- Consult threat intelligence sources to see if the destination IP or any other indicators from the alert are associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Legitimate administrative scripts or automation tools may trigger this rule if they establish network connections and spawn shell processes with similar command-line arguments. Users should review the context of these scripts and consider excluding them if they are verified as non-threatening.
-- System maintenance tasks or monitoring tools that use shell scripts to perform network diagnostics or configuration changes might be flagged. Users can create exceptions for these processes by identifying their unique command-line patterns or parent processes.
-- Development or testing environments where developers frequently use shell scripts to connect to remote systems for debugging or deployment purposes may generate false positives. Users should document these activities and exclude them from detection if they are part of regular operations.
-- Security tools or network utilities like 'socat' that are used for legitimate purposes, such as port forwarding or network testing, can mimic reverse shell behavior. Users should ensure these tools are configured securely and exclude them based on their typical usage patterns.
-- To manage false positives, users can implement a whitelist of known safe IP addresses or process names that are commonly involved in legitimate activities, ensuring these are not flagged by the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the network events and processes flagged by the detection rule.
-- Terminate any suspicious processes identified as part of the reverse shell activity to stop the attacker's access.
-- Review and analyze logs from network devices and the affected system to gather evidence and understand the attack vector.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Apply patches and updates to the affected system and any other vulnerable systems to mitigate the exploited vulnerabilities.
-- Implement enhanced logging and monitoring policies to capture detailed process and network activity, aiding in future detection and investigation.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all data is clean.
-- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and applying least privilege principles to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_java_revshell_linux.toml b/rules/linux/execution_shell_via_java_revshell_linux.toml
index ccb4b85a3f1..8294a0bd405 100644
--- a/rules/linux/execution_shell_via_java_revshell_linux.toml
+++ b/rules/linux/execution_shell_via_java_revshell_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -75,49 +75,6 @@ sequence by host.id with maxspan=5s
      "/usr/lib64/NetExtender.jar", "/usr/lib/jenkins/jenkins.war"
    )] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Reverse Shell via Java
-
-Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `process.entity_id` involved in the suspicious activity.
-- Examine the network connection details, focusing on the `destination.ip` to determine if it is an external or potentially malicious IP address.
-- Check the `process.executable` path to confirm if the Java process is running from a legitimate location or if it appears suspicious.
-- Investigate the `process.parent.args` to verify if the Java application was executed with the `-jar` argument, which could indicate the execution of a JAR file.
-- Cross-reference the `process.name` with known shell processes (e.g., bash, sh, zsh) to confirm if a shell was indeed spawned by the Java process.
-- Utilize Osquery to gather more information about the Java process and its parent process. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <process.entity_id>;`
-- Analyze the process tree to understand the parent-child relationship and identify any other processes spawned by the suspicious Java process.
-- Check for any recent modifications or unusual files in the directories associated with the Java process using file integrity monitoring tools or Osquery.
-- Review system logs and network logs for any additional indicators of compromise or related suspicious activities around the time of the alert.
-- Correlate the findings with threat intelligence sources to determine if the IP addresses, file hashes, or other indicators are associated with known threats or campaigns.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate Java applications that execute shell processes as part of their normal operation, such as Jenkins or remote IoT services.
-- Users can handle these false positives by adding exceptions for specific Java applications that are known to execute shell commands, such as excluding processes with parent arguments like "/usr/share/java/jenkins.war" or "/etc/remote-iot/services/remoteiot.jar".
-- Regularly review and update the list of excluded processes to ensure that only trusted applications are exempted, minimizing the risk of overlooking genuine threats.
-- Consider monitoring the frequency and context of these events to distinguish between benign and potentially malicious activities, focusing on unusual patterns or deviations from normal behavior.
-- Collaborate with application owners to understand the expected behavior of Java applications within the environment, ensuring that legitimate activities are not mistakenly flagged as threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the presence of a reverse shell by analyzing network logs, process execution details, and any suspicious Java activity.
-- Terminate any malicious Java processes and associated shell processes to stop the attacker's access.
-- Review and analyze the system's security logs to identify the initial access vector and any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Restore the system from a known good backup to ensure all malicious changes are removed, and verify the integrity of the restored system.
-- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate suspicious activities.
-- Apply system hardening measures, such as disabling unnecessary Java features, applying security patches, and enforcing least privilege access controls.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
index 5bcacbe4846..4d5cb20854a 100644
--- a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
+++ b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -84,48 +84,6 @@ sequence by host.id, process.entity_id with maxspan=1s
     process.name : ("python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk") and 
     destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Reverse Shell via Suspicious Child Process
-
-Reverse shells are a common technique used by attackers to gain remote access to a compromised system. They exploit scripting languages and utilities like Python, Perl, and Netcat to execute commands remotely. The detection rule identifies suspicious process chains and network activities, such as shell processes initiating unexpected network connections, to flag potential reverse shell attempts. This helps in identifying and mitigating unauthorized access and persistence mechanisms used by adversaries.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process chain and network activity that triggered the rule, focusing on `process.name`, `process.args`, and `destination.ip`.
-- Verify the parent process by examining `process.parent.name` to understand the context in which the suspicious process was spawned.
-- Check the `process.entity_id` and `host.id` to correlate this event with other activities on the same host, looking for patterns or repeated behavior.
-- Use Osquery to list all processes running on the host at the time of the alert. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <suspicious_pid>;`.
-- Investigate the network connections initiated by the suspicious process using the `destination.ip` and `destination.port` fields to determine if they are known or expected.
-- Examine the command-line arguments (`process.args`) for any encoded or obfuscated commands that might indicate malicious intent.
-- Cross-reference the `destination.ip` with threat intelligence sources to check if it is associated with known malicious activity.
-- Review system logs and other security tools for any additional indicators of compromise or related alerts around the same timeframe.
-- Analyze the user account associated with the process to determine if it has been compromised or is being used in an unusual manner.
-- Investigate any file modifications or new files created by the suspicious process to identify potential payloads or scripts used in the attack.
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators may use scripts that match the detection criteria for legitimate purposes, such as automating tasks or managing remote systems. These scripts might use utilities like Python, Perl, or Netcat to establish network connections, which could trigger the rule.
-- Development and testing environments: Developers often use scripting languages and network utilities to test applications or network configurations. These activities can mimic the behavior of a reverse shell, leading to false positives.
-- Security tools and penetration testing: Security teams might use penetration testing tools that simulate reverse shell behavior to assess system vulnerabilities. These tools can trigger the detection rule during authorized security assessments.
-- Excluding known safe processes: Users can manage false positives by creating exceptions for specific processes or scripts that are known to be safe. This can be done by adding these processes to an allowlist or by modifying the detection rule to exclude certain process names or arguments that are frequently used in non-threatening contexts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the suspicious process chain and network activity to confirm the presence of a reverse shell and identify the entry point.
-- Terminate any malicious processes identified during the investigation to stop the attacker's access.
-- Review and analyze system logs, including process execution and network connection logs, to understand the scope and impact of the compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement or enhance logging policies to capture detailed process execution and network activity for future detection and analysis.
-- Restore the system from a known good backup to ensure all traces of the compromise are removed.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the attacker.
-- Implement network segmentation and access controls to limit the ability of attackers to move laterally within the network.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans and security measures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_meterpreter_linux.toml b/rules/linux/execution_shell_via_meterpreter_linux.toml
index 397b8716261..c279ac88981 100644
--- a/rules/linux/execution_shell_via_meterpreter_linux.toml
+++ b/rules/linux/execution_shell_via_meterpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -79,49 +79,6 @@ sample by host.id, process.pid, user.id
   [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"]
   [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Meterpreter Reverse Shell
-
-Meterpreter is a powerful payload within the Metasploit framework, often used by attackers to gain control over a compromised system. It operates by executing commands and gathering system information stealthily. Adversaries exploit it to fingerprint systems by reading specific files like `/etc/passwd` and network routes. The detection rule identifies these suspicious file access patterns, signaling a potential Meterpreter shell presence by monitoring system calls related to file reads on Linux systems.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id`, `process.pid`, and `user.id` associated with the suspicious file access.
-- Verify the legitimacy of the process by checking the `process.pid` against known legitimate processes on the system.
-- Use Osquery to gather more information about the process by running: `SELECT * FROM processes WHERE pid = <process.pid>;` to check the command line, parent process, and other attributes.
-- Investigate the `user.id` to determine if the user account is legitimate and if it has been compromised or misused.
-- Check the system logs for any unusual login activities or privilege escalations related to the `user.id`.
-- Examine the network connections of the host using Osquery: `SELECT * FROM socket_events WHERE pid = <process.pid>;` to identify any suspicious outbound connections.
-- Analyze the file access patterns on the host to see if other sensitive files have been accessed using: `SELECT * FROM file_events WHERE path IN ('/etc/passwd', '/etc/machine-id', '/proc/net/route', '/proc/net/ipv6_route', '/proc/net/if_inet6');`
-- Correlate the timestamps of the suspicious file accesses with other system events to identify any related activities or anomalies.
-- Investigate any recent changes to the system configuration or installed software that could have introduced vulnerabilities.
-- Consult threat intelligence sources to determine if there are any known campaigns or indicators of compromise associated with the observed behavior.
-
-### False positive analysis
-
-- Legitimate system administration tools or scripts may access files like `/etc/passwd` and network routes for configuration or monitoring purposes, leading to false positives. 
-- Automated backup or inventory management software might read these files to gather system information, which can trigger the detection rule.
-- Security monitoring tools that perform regular checks on system files and network configurations could also mimic the behavior of a Meterpreter shell.
-- To manage these false positives, users can create exceptions for known benign processes or users by excluding specific process IDs or user IDs from the detection rule.
-- Regularly review and update the list of exceptions to ensure that only trusted activities are excluded, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation to confirm the presence of a Meterpreter shell by analyzing system logs, network traffic, and any suspicious processes or connections.
-- Terminate any malicious processes identified during the investigation to stop ongoing malicious activities.
-- Change all passwords and credentials that may have been compromised, especially those with elevated privileges.
-- Restore the system from a known good backup to ensure all malicious changes are removed, and verify the integrity of the restored system.
-- Implement enhanced logging and monitoring policies to capture detailed system and network activity, focusing on file access and process execution.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate alerts with known threat patterns.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on recognizing phishing attempts and other common attack vectors to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_suspicious_binary.toml b/rules/linux/execution_shell_via_suspicious_binary.toml
index 4f896e16d09..3e79f5cfac4 100644
--- a/rules/linux/execution_shell_via_suspicious_binary.toml
+++ b/rules/linux/execution_shell_via_suspicious_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -77,49 +77,6 @@ sequence by host.id, process.entity_id with maxspan=1s
   process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
   process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Reverse Shell via Suspicious Binary
-
-Reverse shells are a common technique used by attackers to gain persistent access to a compromised system. They exploit legitimate shell environments to execute commands remotely. Adversaries often use binaries in unusual directories to initiate these shells, followed by network connections to external IPs. The detection rule identifies this behavior by monitoring for suspicious binary executions, network activities, and shell spawns, flagging potential reverse shell activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `process.entity_id` involved in the suspicious activity.
-- Examine the `process.executable` path to determine if it is located in a commonly abused directory, such as `/tmp/*` or `/var/tmp/*`, which may indicate malicious intent.
-- Check the `process.parent.name` to verify if the parent process is a shell, such as `bash` or `sh`, which could suggest a shell was spawned by the suspicious binary.
-- Investigate the `destination.ip` in the network event to identify if the connection was made to an external or suspicious IP address, excluding local addresses like `127.0.0.1` or `::1`.
-- Use Osquery to gather more information about the suspicious binary. For example, run the following query to list details about the executable: `SELECT * FROM processes WHERE path = '/path/to/suspicious/binary';`
-- Analyze the process tree to understand the sequence of events leading to the shell spawn, focusing on the relationship between the suspicious binary and the spawned shell.
-- Check for any recent file modifications or creations in the directories where the suspicious binary was executed, which might indicate additional malicious activity.
-- Review system logs for any other unusual activities or errors around the time of the alert to gather more context about the potential compromise.
-- Investigate the user account associated with the process execution to determine if it has been compromised or is being used maliciously.
-- Correlate the findings with other alerts or incidents involving the same `host.id` or `destination.ip` to identify patterns or repeated attempts of reverse shell activities.
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators may use scripts located in directories like `/tmp` or `/var/tmp` for maintenance tasks, which could trigger the rule. Users can create exceptions for known scripts by specifying their exact paths or hashes.
-- Automated deployment tools: Tools that deploy applications or updates might execute binaries from non-standard directories. Users should identify these tools and exclude their processes from the rule.
-- Development and testing activities: Developers might run binaries from temporary directories during testing phases. Users can exclude specific user accounts or processes associated with development activities.
-- Backup and recovery operations: Some backup solutions might use temporary directories for storing scripts or binaries. Users should identify these operations and exclude them based on process names or paths.
-- Custom monitoring scripts: Organizations may have custom scripts for monitoring or logging that execute from unusual directories. Users can whitelist these scripts by adding exceptions for their specific paths or process names.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the suspicious binary and network connections.
-- Terminate any malicious processes identified during the investigation to stop ongoing threats.
-- Review and analyze logs from the affected system and network devices to gather evidence and understand the attack vector.
-- Remove any unauthorized binaries and scripts from the system, especially those located in commonly abused directories.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Restore the system from a known good backup if the integrity of the system is in question.
-- Implement enhanced logging and monitoring policies to detect similar threats in the future, including network traffic analysis and process execution monitoring.
-- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and response.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing network segmentation to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
index e1deb7bfe4c..56c51e0f506 100644
--- a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -67,49 +67,6 @@ sequence by host.id with maxspan=5s
        (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*")
    )] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Reverse Shell
-
-Reverse shells are tools that adversaries use to gain remote access to a system by initiating a connection from the target back to the attacker's machine. This is often achieved by exploiting vulnerabilities or misconfigurations. The detection rule identifies suspicious activity by monitoring for network events followed by shell process creation, focusing on unusual parent-child process relationships and specific command-line arguments, which are indicative of reverse shell attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and process.entity_id involved in the suspicious activity, ensuring you have the correct context for the investigation.
-- Examine the network event details, focusing on the destination.ip to identify if the connection was made to an external or potentially malicious IP address. Cross-reference this IP with threat intelligence sources.
-- Investigate the process.name and process.args fields to determine the shell type and any arguments used, which may indicate the nature of the reverse shell attempt.
-- Check the process.parent.name and process.parent.args to understand the parent process that initiated the shell, especially if it involves socat, which is commonly used in reverse shell scenarios.
-- Use Osquery to gather additional context on the involved processes. For example, run the following query to list all processes with their parent processes on the affected host: `SELECT pid, name, path, parent, cmdline FROM processes WHERE pid = <process.entity_id>;`
-- Analyze the timeline of events by correlating the network event and process creation timestamps to understand the sequence and duration of the activity.
-- Investigate any other network connections from the same host around the time of the alert to identify additional suspicious activity or patterns.
-- Review system logs on the affected host for any anomalies or related events that coincide with the alert, such as unusual login attempts or privilege escalation.
-- Check for any recent changes or anomalies in user accounts or permissions on the host that could indicate compromise or unauthorized access.
-- Assess the host's security posture by reviewing installed software and configurations to identify potential vulnerabilities or misconfigurations that could have been exploited.
-
-### False positive analysis
-
-- Legitimate administrative scripts or automation tools that initiate network connections followed by shell processes can trigger false positives. These might include backup scripts, configuration management tools, or system monitoring agents that use shells for executing commands remotely.
-- Developers or system administrators using secure shell (SSH) or other remote management tools might inadvertently match the rule's criteria, especially if they use non-standard ports or configurations that mimic reverse shell behavior.
-- Network scanning or security testing tools that simulate attack patterns for vulnerability assessments can also be mistaken for reverse shell attempts.
-- To manage these false positives, users can create exceptions by identifying and excluding specific process names, parent-child process relationships, or network patterns that are known to be benign in their environment. This can be done by adjusting the detection rule to whitelist certain IP addresses, process names, or command-line arguments that are part of regular operations.
-- Regularly review and update the exclusion list to ensure it reflects the current operational environment and does not inadvertently allow malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the reverse shell activity by analyzing network logs, process creation events, and command-line arguments.
-- Terminate any suspicious processes identified as part of the reverse shell activity to stop the attacker's access.
-- Review and analyze the system's security logs to identify any additional indicators of compromise or lateral movement attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Restore the system to a known good state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Implement enhanced logging policies to capture detailed network and process activity, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
-- Apply system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and using application whitelisting to prevent unauthorized software execution.
-- Educate users and administrators on recognizing phishing attempts and other common attack vectors used to establish reverse shells, reinforcing the importance of security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
index 031ec1573cc..e4c42a2a178 100644
--- a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -87,52 +87,6 @@ sample by host.id, process.pid, process.parent.pid
     ) and network.direction == "egress" and destination.ip != null and
    not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Reverse Shell via UDP
-
-Reverse shells over UDP exploit the stateless nature of UDP to bypass firewalls, allowing attackers to execute commands remotely. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies such activity by monitoring for specific process executions, UDP socket creation, and unusual outbound connections, flagging potential misuse of these technologies.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and process involved using `host.id`, `process.pid`, and `process.parent.pid`.
-- Verify the process name and command line arguments to confirm if it matches known reverse shell patterns, focusing on `process.name` and `event.action`.
-- Check the `auditd.data.syscall` for the "socket" call and ensure `auditd.data.a1` indicates a UDP connection (value "2").
-- Analyze the network connection details, particularly `network.direction` and `destination.ip`, to identify unusual or unauthorized egress connections.
-- Use Osquery to list all active network connections on the host to identify any other suspicious UDP connections:
-  ```sql
-  SELECT pid, local_address, local_port, remote_address, remote_port, protocol FROM process_open_sockets WHERE protocol = 'udp';
-  ```
-- Investigate the parent process (`process.parent.pid`) to determine if it was spawned by a legitimate or suspicious process.
-- Cross-reference the destination IP address with threat intelligence sources to check for known malicious indicators.
-- Examine historical logs for the host to identify any previous similar activities or patterns that might indicate a persistent threat.
-- Review user activity on the host around the time of the alert to identify any unauthorized access or actions.
-- Check for any recent changes to the system's firewall or security configurations that might have allowed the reverse shell to bypass protections.
-
-### False positive analysis
-
-- Legitimate administrative scripts or tools that use UDP for network diagnostics or configuration may trigger this rule. Users can handle these by identifying and excluding specific scripts or processes that are known to be safe.
-- Automated backup or monitoring systems that utilize UDP for communication might be flagged. To manage this, users should create exceptions for these systems by specifying their process names or network patterns.
-- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes may cause false positives. Users can mitigate this by excluding specific user accounts or IP ranges associated with these environments.
-- Custom applications that use UDP for legitimate data transfer could be mistakenly identified as reverse shells. Users should document and exclude these applications by their process names or network behavior.
-- Security tools that perform network scans or penetration testing using UDP might be detected. Users can address this by excluding known security tools and their associated processes from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the processes and network connections flagged by the detection rule.
-- Terminate any suspicious processes identified as part of the reverse shell activity to halt ongoing malicious actions.
-- Review and analyze system logs, including auditd and network logs, to gather evidence and understand the attack vector and timeline.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Apply patches and updates to the operating system and any vulnerable applications to mitigate known vulnerabilities exploited by the attacker.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and network activity, aiding in future detection and investigation efforts.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system from a known good backup to ensure the removal of any persistent threats or backdoors installed by the attacker.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as restricting outbound UDP traffic and enforcing least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
index 5075425aa35..5ad64dc7846 100644
--- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
+++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/06/26"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ output from tail can be piped to funzip in order to decompress malicious code be
 consistent with malware families such as Bundlore.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Content Extracted or Decompressed via Funzip"
@@ -53,59 +55,18 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and
 ((process.args == "tail" and process.args == "-c" and process.args == "funzip")) and
 not process.args : "/var/log/messages" and 
 not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and
 not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Content Extracted or Decompressed via Funzip
-
-Funzip is a utility used to decompress files directly from a stream, often used in conjunction with other command-line tools. Adversaries exploit this by using commands like `tail` to read file ends and pipe the output to `funzip`, decompressing potentially malicious content for execution. The detection rule identifies this pattern by monitoring specific command sequences and excluding benign processes, thus flagging suspicious decompression activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `tail` and `funzip` command sequence in the process arguments, as this is the primary indicator of suspicious activity.
-- Check the process tree to identify the parent process of the suspicious command execution. This can provide context on how the command was initiated and whether it was part of a larger script or process.
-- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if the account may have been compromised.
-- Examine the command line arguments used with `tail` and `funzip` to identify the specific file being accessed and decompressed. This can help determine if the file is known or potentially malicious.
-- Use Osquery to gather additional context on the file being decompressed. For example, run the following query to check the file's metadata and hash: `SELECT path, size, md5, sha256 FROM file WHERE path = '/path/to/suspicious/file';`
-- Analyze the file's contents, if accessible, to determine if it contains malicious code or scripts. This may involve using static analysis tools or sandboxing the file in a controlled environment.
-- Cross-reference the file's hash with threat intelligence databases to see if it matches known malware signatures or has been reported in previous incidents.
-- Review system logs around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the decompression event.
-- Investigate network activity from the host to determine if there were any outbound connections or data exfiltration attempts following the decompression event.
-- Check for any other alerts or indicators of compromise on the host that may suggest a broader attack or compromise, such as unusual login attempts or privilege escalation activities.
-
-### False positive analysis
-
-- Known false positives for this rule may include legitimate administrative or maintenance activities where system administrators use `tail` and `funzip` in combination for routine file management tasks. These activities might involve decompressing log files or other non-malicious data for analysis.
-- Another potential false positive scenario involves automated scripts or cron jobs that utilize `tail` and `funzip` for legitimate data processing or backup operations. These scripts might be part of system maintenance or data archiving processes.
-- To manage these false positives, users can create exceptions by excluding specific command sequences or parent processes that are known to be benign. For instance, if a particular script or administrative tool frequently triggers this rule but is verified as safe, users can add its process name or command line pattern to the exclusion list.
-- Users should regularly review and update their exclusion lists to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between reducing false positives and ensuring effective threat detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential malware.
-- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing logs and identifying any unauthorized processes or files.
-- Terminate any suspicious processes related to the funzip and tail command sequence to halt any ongoing malicious activity.
-- Remove any identified malicious files or software from the system to prevent re-execution.
-- Restore the system from a known good backup if available, ensuring that the backup is free from any compromise.
-- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed command-line activity and process execution for future investigations.
-- Integrate threat intelligence feeds and security solutions to improve detection capabilities and correlate alerts with known threat actors or techniques.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Review and update security policies and user training to reinforce awareness of suspicious activities and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_suspicious_executable_running_system_commands.toml b/rules/linux/execution_suspicious_executable_running_system_commands.toml
index 731aa663d32..799dfcc7778 100644
--- a/rules/linux/execution_suspicious_executable_running_system_commands.toml
+++ b/rules/linux/execution_suspicious_executable_running_system_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -75,50 +75,6 @@ process.parent.executable:(
   process.executable:(/run/containerd/* or /srv/snp/docker/* or /tmp/.criu*)
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious System Commands Executed by Previously Unknown Executable
-
-In Linux environments, system commands are essential for managing processes and configurations. Adversaries exploit this by executing commands via unknown executables in vulnerable directories, aiming to run unauthorized code. The detection rule identifies such anomalies by monitoring command executions from unfamiliar sources, excluding known safe processes, thus highlighting potential threats for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific unknown executable and the directory from which it was executed. Pay close attention to the `process.executable` field to determine the exact path.
-- Examine the `process.args` field to understand the specific system commands that were executed. This can provide insight into the potential intent of the executable.
-- Check the `process.parent.executable` field to identify the parent process that initiated the suspicious executable. This can help determine if the parent process is legitimate or potentially compromised.
-- Use Osquery to list all processes running from the directory of the suspicious executable. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/tmp/%';` to identify other potentially malicious processes.
-- Investigate the file attributes and metadata of the unknown executable using Osquery. Example query: `SELECT * FROM file WHERE path = '/path/to/suspicious/executable';` to gather information such as file size, creation time, and modification time.
-- Check the system logs for any recent changes or anomalies around the time the suspicious executable was first observed. This can help identify how the executable was introduced to the system.
-- Analyze network activity associated with the suspicious process using network monitoring tools or logs. Look for unusual outbound connections or data transfers.
-- Review user activity logs to determine if any legitimate user accounts were involved in executing or creating the suspicious executable. This can help identify potential insider threats or compromised accounts.
-- Cross-reference the suspicious executable and its hash against threat intelligence databases to check for known malware signatures or related threat actor activity.
-- Investigate other systems within the network for similar suspicious activity, focusing on the same directories and system commands, to assess if the threat is isolated or part of a broader attack.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate administrative scripts or tools that are executed from directories typically associated with suspicious activity, such as `/tmp` or `/var/tmp`. These scripts might be part of routine maintenance or monitoring tasks.
-- Developers or system administrators might run custom scripts from their home directories, which could trigger alerts if these scripts execute common system commands.
-- Automated deployment tools or configuration management systems might temporarily place executables in monitored directories during updates or installations, leading to false positives.
-- To manage these false positives, users can create exceptions for specific scripts or executables by adding them to the exclusion list in the detection rule. This can be done by specifying the full path of the known safe executable or script.
-- Users should regularly review and update the exclusion list to ensure that only verified and non-threatening processes are excluded, maintaining a balance between security and operational efficiency.
-- It is important to document any exceptions made to the rule to ensure that all team members are aware of the changes and the rationale behind them, which helps in maintaining a secure environment.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation of the alert by reviewing the process execution details, including the executable path, arguments, and parent process, to confirm malicious activity.
-- Terminate any suspicious processes identified during the investigation to halt potential malicious actions.
-- Analyze system logs and network traffic to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations team if the investigation confirms a breach or if the scope of the attack is beyond initial containment efforts.
-- Restore the system to its operational state by removing any unauthorized executables and ensuring all system files are intact and unaltered.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds and security tools to improve detection capabilities and correlate alerts with known threat actors and tactics.
-- Apply system hardening measures, such as restricting executable permissions in commonly abused directories and implementing application whitelisting.
-- Review and update security policies and procedures to address any gaps identified during the incident response and ensure better preparedness for future threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml
index 978a95f9e27..98437b758b5 100644
--- a/rules/linux/execution_suspicious_mining_process_creation_events.toml
+++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -62,48 +62,6 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and 
 file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Mining Process Creation Event
-
-Cryptominers exploit system resources to mine cryptocurrency without user consent, often leveraging Linux services for persistence. Adversaries create or modify service files to execute mining software, disguising them as legitimate processes. The detection rule identifies unusual service creation events linked to known mining services, flagging potential unauthorized cryptomining activities by monitoring specific file names and creation actions.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file name involved in the event matches one of the known suspicious service names: "aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", or "xvf.service".
-- Check the timestamp of the event to determine when the suspicious service was created and correlate it with other system activities around the same time.
-- Identify the user account or process that initiated the service creation event to assess if it was an authorized action or potentially compromised.
-- Use Osquery to list all services on the affected host and verify the presence of the suspicious service. Example query: `SELECT name, path, pid FROM services WHERE name IN ('aliyun.service', 'moneroocean_miner.service', 'c3pool_miner.service', 'pnsd.service', 'apache4.service', 'pastebin.service', 'xvf.service');`
-- Investigate the parent process of the service creation event to understand the origin and context of the execution.
-- Examine the file path and permissions of the suspicious service file to determine if it has been altered or if it resides in an unusual location.
-- Analyze system logs for any additional indicators of compromise or related suspicious activities, such as unusual network connections or high CPU usage.
-- Check for any recent changes to the system's scheduled tasks or cron jobs that might indicate persistence mechanisms related to cryptomining.
-- Investigate any outbound network connections from the host to known mining pools or suspicious IP addresses.
-- Gather and review any available threat intelligence or previous incidents related to the identified service names to understand potential adversary tactics and techniques.
-
-### False positive analysis
-
-- Legitimate administrative actions: System administrators may create or modify service files for legitimate purposes, such as deploying new applications or updating existing services. These actions can trigger the detection rule, resulting in false positives.
-- Custom scripts or services: Organizations may use custom scripts or services that have similar naming conventions to those flagged by the rule. These can be mistaken for mining services if they share file names with known cryptominer services.
-- Automated deployment tools: Tools like Ansible, Puppet, or Chef might create or modify service files as part of automated deployment processes, which could be incorrectly identified as suspicious activity.
-- To manage false positives, users can create exceptions for known legitimate service creation events by whitelisting specific file names or paths that are frequently used in non-threatening administrative tasks. Additionally, users can refine the detection rule to exclude certain hosts or directories that are known to be safe, reducing unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the cryptominer and potential data exfiltration.
-- Conduct a thorough investigation to confirm the presence of unauthorized mining software by examining the identified service files and correlating them with known cryptomining signatures.
-- Terminate any suspicious processes associated with the identified service files to halt the mining activity.
-- Remove or disable the unauthorized service files to prevent them from being executed again.
-- Review and update the system's security patches and configurations to close any vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed information on service creation and modification events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system from a known good backup to ensure the removal of any persistent threats and verify the integrity of critical system files.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on recognizing signs of cryptomining infections and the importance of maintaining security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml
index 3b2c15ba8b1..fbd2b0989e1 100644
--- a/rules/linux/execution_tc_bpf_filter.toml
+++ b/rules/linux/execution_tc_bpf_filter.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2022/07/11"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ A threat actor can utilize tc to set a bpf filter on an interface for the purpos
 This technique is not at all common and should indicate abnormal, suspicious or malicious activity.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "BPF filter applied using TC"
@@ -57,6 +59,7 @@ tags = [
     "Threat: TripleCross",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -66,49 +69,6 @@ process where host.os.type == "linux" and event.type != "end" and process.execut
 process.args == "filter" and process.args == "add" and process.args == "bpf" and
 not process.parent.executable == "/usr/sbin/libvirtd"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 BPF filter applied using TC
-
-BPF (Berkeley Packet Filter) is a powerful tool for packet filtering and analysis, often used in conjunction with the `tc` command to manage network traffic on Linux systems. Adversaries may exploit this by applying BPF filters to manipulate or monitor traffic covertly. The detection rule identifies suspicious use of `tc` to add BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `tc` command with arguments `filter`, `add`, and `bpf`, ensuring the process executable is `/usr/sbin/tc`.
-- Verify the parent process of the `tc` command to ensure it is not `/usr/sbin/libvirtd`, as this is excluded from the detection rule.
-- Check the user account associated with the process to determine if it is a known or privileged account, which might indicate a higher risk if compromised.
-- Investigate the network interface on which the BPF filter was applied to understand the potential impact on network traffic.
-- Use Osquery to list all active BPF programs on the system to identify any other suspicious filters. Example query: `SELECT * FROM bpf_programs;`
-- Examine system logs for any other unusual activities or errors around the time the `tc` command was executed to gather more context.
-- Review recent command history for the user associated with the `tc` process to identify any other suspicious commands or patterns.
-- Analyze network traffic logs to detect any anomalies or unexpected patterns that might correlate with the time the BPF filter was applied.
-- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized use of the `tc` command.
-- Investigate any other alerts or incidents involving the same host or user to determine if this is part of a broader attack pattern.
-
-### False positive analysis
-
-- Legitimate use of `tc` by system administrators for network performance tuning or traffic management can trigger the rule. This is common in environments where network optimization is a priority.
-- Automated scripts or configuration management tools that deploy network configurations using `tc` may also be flagged. These scripts often run as part of routine maintenance or deployment processes.
-- Network monitoring or security tools that utilize BPF filters for legitimate traffic analysis might inadvertently match the rule's criteria.
-- To manage these false positives, users can create exceptions for known benign processes by excluding specific parent processes or command patterns that are verified as non-threatening.
-- Regularly review and update the exclusion list to ensure it reflects the current network management practices and tools in use, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic.
-- Conduct a thorough investigation to identify any unauthorized BPF filters applied using the `tc` command by reviewing system logs and process execution history.
-- Verify the legitimacy of the `tc` command usage by checking for known legitimate processes, such as `/usr/sbin/libvirtd`, and ensure no other unauthorized processes are involved.
-- Remove any unauthorized BPF filters and restore the network interface configuration to its original state.
-- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on the use of `tc` and BPF filters.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate similar events and detect potential threats proactively.
-- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to detect and block suspicious `tc` command usage.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply system hardening measures, such as restricting the use of the `tc` command to authorized users and processes, to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml
index 96834e4c576..561bf0c43b6 100644
--- a/rules/linux/execution_unix_socket_communication.toml
+++ b/rules/linux/execution_unix_socket_communication.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/09/04"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ privileges or set up malicious communication channels via Unix sockets for inter
 evade detection.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Unix Socket Connection"
@@ -28,12 +30,15 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and (
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ (
   (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and 
    process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or
   (process.name == "socat" and 
@@ -41,49 +46,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and
 not process.args == "/var/run/libvirt/libvirt-sock"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unix Socket Connection
-
-Unix sockets facilitate efficient inter-process communication (IPC) on the same host, enabling data exchange between applications. Adversaries exploit this by connecting to local sockets to gather application data, identify vulnerabilities, or establish covert channels. The detection rule identifies suspicious processes like 'nc' or 'socat' using specific arguments, signaling potential misuse while excluding legitimate operations like those involving libvirt.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on processes like 'nc', 'ncat', 'netcat', or 'socat' with suspicious arguments.
-- Check the process execution timeline to determine when the suspicious process started and if there are any patterns or anomalies in its execution frequency.
-- Investigate the parent process of the suspicious process to understand the context of its execution and identify if it was initiated by a legitimate application or a potentially malicious script.
-- Examine the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
-- Use Osquery to list all active Unix socket connections on the host to identify any unusual or unauthorized connections. Example query: `SELECT * FROM socket_events WHERE family = 'unix';`
-- Correlate the suspicious process activity with other system logs, such as authentication logs, to identify any concurrent suspicious activities or failed login attempts.
-- Analyze the command-line arguments of the process to understand the intended target of the Unix socket connection and assess if it aligns with known legitimate services or applications.
-- Investigate the file paths specified in the process arguments (e.g., "/usr/local/*", "/run/*", "/var/run/*") to verify if they are associated with known applications or if they have been recently modified.
-- Check for any recent changes or anomalies in the system's configuration files or application settings that could indicate tampering or misconfiguration.
-- Review historical data to determine if similar alerts have been triggered in the past and if they were associated with any confirmed security incidents or false positives.
-
-### False positive analysis
-
-- Legitimate administrative tools and services may trigger the rule, such as system management scripts or monitoring tools that use 'nc' or 'socat' for valid purposes. Users should review the context of these processes to determine if they are part of routine operations.
-- Automated backup or synchronization processes might use Unix sockets for data transfer, appearing suspicious but being part of regular maintenance tasks. Users can create exceptions for these processes by identifying their unique command-line arguments or execution patterns.
-- Development and testing environments often use Unix sockets for application testing and debugging, which can lead to false positives. Users should consider excluding known development tools or specific user accounts associated with these activities.
-- Some containerized applications may use Unix sockets for internal communication, which could be misinterpreted as malicious. Users can whitelist specific container IDs or paths that are known to be safe.
-- To manage false positives, users can refine the detection rule by adding exceptions for specific process arguments or paths that are consistently identified as non-threatening, ensuring that legitimate activities are not disrupted.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on processes using Unix sockets with suspicious arguments.
-- Terminate any unauthorized or suspicious processes identified during the investigation to halt potential malicious activities.
-- Review system logs and Unix socket connections to gather evidence and understand the adversary's actions and objectives.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed process execution and Unix socket activity for future monitoring and investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
-- Restore the system to its operational state by applying patches, updating configurations, and ensuring all unauthorized changes are reverted.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting Unix socket access, using application whitelisting, and regularly auditing system configurations to prevent similar incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
index 08071861d5f..72ddcdf21c0 100644
--- a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
+++ b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -60,49 +60,6 @@ event.category:process and host.os.type:linux and auditd.data.syscall:mprotect a
   process.name:httpd
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unknown Execution of Binary with RWX Memory Region
-
-In Unix systems, the `mprotect()` syscall alters memory permissions, potentially enabling read, write, and execute (RWX) access. While necessary for legitimate processes, adversaries exploit this to execute malicious code stealthily. The detection rule identifies suspicious RWX memory changes by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on fields such as `event.category`, `host.os.type`, `auditd.data.syscall`, and `auditd.data.a2` to confirm the presence of an `mprotect()` call with RWX permissions.
-- Verify the process executable path and name using `process.executable` and `process.name` fields to ensure it is not part of the known safe binaries list.
-- Gather additional context about the process by checking its parent process using `process.parent.executable` and `process.parent.name` to identify potential sources of the suspicious activity.
-- Use Osquery to list all processes with RWX memory regions by executing: `SELECT pid, name, path FROM processes WHERE on_disk = 0 AND (path NOT LIKE '/usr/share/kibana/node/bin/node' AND path NOT LIKE '/usr/share/elasticsearch/jdk/bin/java' AND path NOT LIKE '/usr/sbin/apache2' AND name NOT LIKE 'httpd');`
-- Investigate the command line arguments of the suspicious process using `process.command_line` to identify any unusual or unexpected commands that might indicate malicious intent.
-- Check the process's network activity using `network.connection` fields to identify any suspicious outbound connections that could suggest data exfiltration or command and control communication.
-- Examine the file hashes of the binary using `file.hash.md5`, `file.hash.sha1`, and `file.hash.sha256` to determine if it matches any known malicious signatures in threat intelligence databases.
-- Review recent system logs and audit logs for any other suspicious activities or anomalies around the time of the alert to identify potential lateral movement or privilege escalation attempts.
-- Investigate the user account associated with the process using `user.name` and `user.id` to determine if the account has been compromised or is exhibiting unusual behavior.
-- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to build a comprehensive picture of the potential threat and its impact on the system.
-
-### False positive analysis
-
-- Known false positives for the Unknown Execution of Binary with RWX Memory Region rule often include legitimate applications that require RWX permissions for normal operations, such as just-in-time (JIT) compilers or certain database management systems. These applications may use `mprotect()` to optimize performance by dynamically generating and executing code.
-- Users can manage these false positives by creating exceptions for specific binaries or processes that are known to exhibit this behavior regularly. This can be done by adding these binaries to the exclusion list in the detection rule, ensuring that only truly suspicious activities are flagged.
-- It is important to regularly review and update the list of excluded binaries to ensure that new legitimate applications are not mistakenly flagged as threats. This can be achieved by maintaining a whitelist of trusted applications and processes that are known to use RWX memory regions safely.
-- In environments where custom or in-house applications are used, it is advisable to conduct a thorough analysis of these applications to understand their memory usage patterns. If they are identified as false positives, they should be documented and excluded from the detection rule to prevent unnecessary alerts.
-- Users should also consider the context of the system and its typical usage patterns. For instance, development environments may have more frequent legitimate use of RWX memory regions compared to production environments, and this context should guide the configuration of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the process that triggered the `mprotect()` syscall with RWX permissions.
-- Review and analyze logs from the affected system and any related systems to trace the execution path and identify any additional compromised binaries or processes.
-- Remove or quarantine any identified malicious binaries or scripts, and terminate any suspicious processes that are running with RWX memory permissions.
-- Restore the affected system from a known good backup to ensure that no remnants of the malicious activity remain.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities that could be exploited.
-- Implement enhanced logging policies to capture detailed syscall activity and process execution, ensuring that future suspicious activities are logged and can be analyzed.
-- Integrate security solutions such as endpoint detection and response (EDR) tools to provide real-time monitoring and alerting for suspicious activities, including unauthorized memory permission changes.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of monitoring for unusual memory permission changes and other indicators of compromise."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
index 7239c5ccb4c..e227515767a 100644
--- a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
+++ b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/11/04"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ for exfiltration on Linux systems. Data splitting is a technique used by adversa
 avoid detection and exfiltrate data.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Data Splitting Detected"
@@ -49,69 +51,34 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Exfiltration",
-    "Data Source: Elastic Defend"
+    "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
-  (process.name == "dd" and process.args like "bs=*" and process.args like "if=*") or
-  (process.name in ("split", "rsplit") and (
-    (process.args == "-b" or process.args like "--bytes*") or
-    (process.args == "-C" or process.args like "--line-bytes*")
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  (
+    (process.name == "dd" and process.args like "bs=*" and process.args like "if=*") or
+    (
+      process.name in ("split", "rsplit") and
+      (
+        (process.args == "-b" or process.args like "--bytes*") or
+        (process.args == "-C" or process.args like "--line-bytes*")
+      )
+    )
+  ) and
+  not (
+    process.parent.name in ("apport", "overlayroot") or
+    process.args like (
+      "if=/tmp/nvim*", "if=/boot/*", "if=/dev/random", "if=/dev/urandom", "/dev/mapper/*",
+      "if=*.iso", "of=/dev/stdout", "if=/dev/zero", "if=/dev/sda", "/proc/sys/kernel/*"
     )
   )
-) and not (
-  process.parent.name in ("apport", "overlayroot") or
-  process.args like (
-    "if=/tmp/nvim*", "if=/boot/*", "if=/dev/random", "if=/dev/urandom", "/dev/mapper/*",
-    "if=*.iso", "of=/dev/stdout", "if=/dev/zero", "if=/dev/sda", "/proc/sys/kernel/*"
-  )
-)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Data Splitting Detected
-
-Data splitting utilities on Linux, like `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit this by splitting data to evade detection systems during exfiltration. The detection rule identifies suspicious use of these utilities by monitoring specific arguments and excluding benign processes, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on `process.name` and `process.args`.
-- Check the parent process using `process.parent.name` to determine if the process was spawned by a known benign application or a potentially malicious one.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Examine the command line arguments (`process.args`) for any unusual patterns or destinations, especially focusing on the `if=` and `of=` parameters to identify source and destination files.
-- Use Osquery to list recent processes executed by the same user to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
-- Analyze the file paths involved in the process arguments to determine if they are legitimate or if they point to sensitive or unusual locations.
-- Check system logs for any related events around the same timestamp to gather additional context on the system's state and activities.
-- Investigate network connections from the host to identify any unusual outbound connections that might indicate data exfiltration.
-- Review historical data for similar alerts on the same host or user to identify patterns or repeated attempts at data splitting.
-- Correlate the alert with other security events or alerts in the environment to determine if it is part of a larger attack campaign.
-
-### False positive analysis
-
-- Known false positives may include legitimate system processes or administrative tasks that use data splitting utilities for non-malicious purposes, such as system backups or log management.
-- Processes like `apport` and `overlayroot` are excluded as they are known to use these utilities in benign contexts.
-- Users can handle false positives by adding exceptions for specific parent processes or argument patterns that are frequently observed in non-threatening activities.
-- Consider excluding processes that operate on files within directories like `/tmp`, `/boot`, or `/proc/sys/kernel`, as these are often involved in routine system operations.
-- Regularly review and update the exclusion list to adapt to changes in system behavior and reduce unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the data splitting activity, focusing on the processes and users involved.
-- Review system logs and network traffic to trace any data exfiltration attempts and determine if any sensitive data was compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities.
-- Restore the system to its operational state by removing any unauthorized processes or files and applying necessary security patches.
-- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
-- Educate users and administrators on the risks of data splitting and exfiltration techniques, emphasizing the importance of monitoring and reporting suspicious activities.
-- Implement hardening measures such as restricting the use of data splitting utilities to authorized personnel and employing data loss prevention (DLP) solutions to monitor and control data transfers."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/impact_data_encrypted_via_openssl.toml b/rules/linux/impact_data_encrypted_via_openssl.toml
index cc417ddb3dc..2e7a762d6bc 100644
--- a/rules/linux/impact_data_encrypted_via_openssl.toml
+++ b/rules/linux/impact_data_encrypted_via_openssl.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -66,49 +66,6 @@ sequence by host.id, user.name, process.parent.entity_id with maxspan=5s
     /* excluding base64 encoding options and including encryption password or key params */
     not process.args in ("-d", "-a", "-A", "-base64", "-none", "-nosalt") ] with runs=10
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Data Encryption via OpenSSL Utility
-
-OpenSSL is a robust tool for secure data encryption, widely used to protect sensitive information. However, adversaries can exploit it to encrypt files maliciously, disrupting data availability and demanding ransom. The detection rule identifies rapid, repeated encryption attempts using OpenSSL, focusing on specific command patterns and arguments, signaling potential misuse for data impact.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and user.name associated with the suspicious OpenSSL activity to understand which system and user account are involved.
-- Examine the process.parent.entity_id to identify the parent process that initiated the OpenSSL command, which can provide context on how the encryption was triggered.
-- Check the process.args used in the OpenSSL command to verify the presence of encryption-specific arguments like "-k", "-K", "-kfile", "-pass", "-iv", and "-md", and ensure that no base64 encoding options were used.
-- Analyze the sequence of events within the maxspan=5s to determine if there are multiple rapid encryption attempts, indicating potential malicious activity.
-- Investigate the process.parent.name to see if the OpenSSL command was executed from a common shell or scripting language, which might suggest automated or scripted execution.
-- Use Osquery to gather additional context on the processes running on the host. For example, run the following query to list recent OpenSSL processes: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name = 'openssl';`
-- Check system logs and audit logs for any unusual login attempts or privilege escalations around the time of the OpenSSL activity to identify potential unauthorized access.
-- Review file access logs to determine which files were targeted for encryption and assess the potential impact on data availability.
-- Correlate the OpenSSL activity with network logs to identify any outbound connections that might indicate data exfiltration or communication with a command and control server.
-- Investigate the user account associated with the activity for any signs of compromise, such as changes in user behavior, unexpected privilege changes, or recent password resets.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use OpenSSL for legitimate encryption tasks, such as securing backups or transferring sensitive files, which could trigger the rule. To manage this, users can create exceptions for specific user accounts or scripts known to perform these tasks regularly.
-- Automated scripts: Some automated processes or cron jobs might use OpenSSL to encrypt data as part of their normal operation. Users should identify these scripts and exclude them from the rule by specifying the script names or paths.
-- Development and testing environments: Developers might frequently use OpenSSL for testing encryption functionalities, leading to false positives. Users can exclude specific development environments or user accounts from the rule to prevent unnecessary alerts.
-- Backup operations: Backup software or scripts that utilize OpenSSL for encrypting data during backup processes can be mistaken for malicious activity. Users should whitelist these operations by identifying the associated processes or user accounts.
-- Data transfer processes: Organizations that regularly encrypt data for secure transfer might trigger the rule. Users can handle this by excluding known data transfer processes or specific network paths associated with these operations.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further encryption or lateral movement.
-- Identify and terminate the malicious OpenSSL processes to stop ongoing encryption activities.
-- Conduct a thorough investigation to determine the scope of the attack, including identifying all affected files and systems.
-- Preserve forensic evidence by collecting relevant logs and snapshots of the system for further analysis.
-- Restore encrypted files from the most recent clean backups to ensure data availability and integrity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for OpenSSL usage and other encryption tools to detect similar activities in the future.
-- Review and update access controls and permissions to limit the use of encryption tools to authorized personnel only.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate employees on recognizing phishing attempts and other common attack vectors to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/impact_esxi_process_kill.toml b/rules/linux/impact_esxi_process_kill.toml
index b174cb4ef1c..bc58c8a9c8c 100644
--- a/rules/linux/impact_esxi_process_kill.toml
+++ b/rules/linux/impact_esxi_process_kill.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -63,49 +63,6 @@ query = '''
 process where host.os.type == "linux" and event.type == "end" and process.name in ("vmware-vmx", "vmx")
 and process.parent.name == "kill"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Termination of ESXI Process
-
-VMware ESXi is a hypervisor used to run virtual machines on physical servers, crucial for data center operations. Adversaries may disrupt these environments by terminating key processes like "vmware-vmx" using commands such as "kill," potentially leading to service outages. The detection rule identifies such terminations by monitoring for specific process events, signaling possible malicious interference.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and parent process name, ensuring they match "vmware-vmx" or "vmx" and "kill" respectively.
-- Check the timestamp of the event to determine when the termination occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the user account associated with the "kill" command to determine if it is a legitimate user or potentially compromised.
-- Examine the command line history of the user who executed the "kill" command to identify any other suspicious commands or activities.
-- Use Osquery to gather additional context about the terminated process by running: `SELECT * FROM processes WHERE name IN ('vmware-vmx', 'vmx') AND pid = <terminated_process_pid>;`
-- Analyze system logs for any unauthorized access attempts or anomalies around the time of the process termination.
-- Check for any recent changes in user permissions or roles that might have allowed the execution of the "kill" command on critical processes.
-- Investigate network logs to identify any unusual connections or data transfers that coincide with the process termination event.
-- Review any recent patches or updates applied to the ESXi host that might have inadvertently affected the process stability.
-- Consult with the system administrator responsible for the ESXi environment to verify if the termination was part of any scheduled maintenance or known issue.
-
-### False positive analysis
-
-- Routine maintenance activities: System administrators may intentionally terminate VMware processes during scheduled maintenance or updates, which can trigger the detection rule. To manage this, users can create exceptions for known maintenance windows or specific administrator actions.
-- Automated scripts: Some environments may use automated scripts to manage or restart VMware processes, leading to false positives. Users should identify and exclude these scripts by specifying their process names or execution contexts in the detection rule.
-- Testing and development environments: In non-production environments, developers or testers might frequently start and stop VMware processes as part of their workflow. Users can exclude these environments by filtering based on hostnames or IP addresses associated with testing and development.
-- Backup and recovery operations: Certain backup solutions may temporarily stop VMware processes to ensure data consistency, which could be misinterpreted as malicious activity. Users should identify these backup operations and exclude them by recognizing the associated process names or parent processes.
-- Misconfigured monitoring tools: Some monitoring tools might inadvertently terminate processes as part of their error-handling routines. Users should review and adjust the configurations of these tools to prevent unnecessary terminations and exclude them from the detection rule if needed.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further malicious activity and potential spread to other systems.
-- Investigate the source of the "kill" command by reviewing user activity logs and identifying any unauthorized access or anomalies.
-- Terminate any unauthorized or suspicious sessions and change credentials for accounts that may have been compromised.
-- Restore terminated VMware processes by restarting the affected virtual machines and ensuring all services are operational.
-- Review and update firewall rules and access controls to limit the ability of unauthorized users to execute commands on the host.
-- Implement enhanced logging policies to capture detailed process creation and termination events, including parent-child process relationships.
-- Integrate security information and event management (SIEM) systems to correlate and analyze logs for early detection of similar threats.
-- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and coordination with relevant stakeholders.
-- Apply hardening measures such as disabling unnecessary services, applying security patches, and enforcing least privilege access to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/impact_memory_swap_modification.toml b/rules/linux/impact_memory_swap_modification.toml
index d8f3791dae0..7b01fd5d3c7 100644
--- a/rules/linux/impact_memory_swap_modification.toml
+++ b/rules/linux/impact_memory_swap_modification.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/11/04"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ the system's memory and potentially impact the system's performance. This behavi
 deploys miner software such as XMRig.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Memory Swap Modification"
@@ -53,11 +55,13 @@ tags = [
     "Tactic: Impact",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.parent.executable != null and
 process.name in ("swapon", "swapoff") or (
   process.command_line like ("*vm.swappiness*", "*/proc/sys/vm/swappiness*") and (
@@ -69,49 +73,6 @@ process.name in ("swapon", "swapoff") or (
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Memory Swap Modification
-
-Memory swapping in Linux involves moving data between RAM and disk storage to manage system memory efficiently. Adversaries exploit this by altering swap settings to degrade performance or facilitate resource hijacking, often for cryptomining. The detection rule identifies suspicious processes like `swapon` or `swapoff`, and commands modifying swappiness settings, signaling potential misuse by malware such as XMRig.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and command line that triggered the alert, focusing on `process.name` and `process.command_line` fields.
-- Check the `process.parent.executable` field to determine the parent process of the suspicious activity, which can provide context on how the process was initiated.
-- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity was initiated by a legitimate user or a compromised account.
-- Use Osquery to list all current swap devices and their usage with the query: `SELECT * FROM memory_info WHERE name LIKE 'Swap%';` to assess if there are any unusual swap activities.
-- Examine the system logs, such as `/var/log/syslog` or `/var/log/messages`, for any related entries around the time of the alert to gather additional context.
-- Check for any recent changes to the system's swappiness setting by reviewing the `/etc/sysctl.conf` file or using the command `sysctl vm.swappiness` to see if it matches expected configurations.
-- Investigate any recent modifications to the `/proc/sys/vm/swappiness` file by checking the file's metadata, such as modification time, using `stat /proc/sys/vm/swappiness`.
-- Use Osquery to identify any other processes that have been executed by the same user or parent process recently with the query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'swapon' OR name = 'swapoff');`.
-- Analyze network activity for the host to identify any unusual outbound connections that could indicate resource hijacking, using tools like `netstat` or `ss`.
-- Review any other security alerts or logs from the same host or user account to identify patterns or additional indicators of compromise that may correlate with the memory swap modification activity.
-
-### False positive analysis
-
-- Routine system administration tasks can trigger this rule, such as when system administrators manually adjust swap settings for performance tuning or during system maintenance. These actions are typically benign and not indicative of malicious activity.
-- Automated scripts or configuration management tools like Ansible, Puppet, or Chef that manage system settings might execute commands that match the rule's criteria, leading to false positives.
-- Some Linux distributions or custom setups may include startup scripts that adjust swappiness settings as part of their normal boot process, which could be mistakenly flagged by this rule.
-- To manage these false positives, users can create exceptions for known administrative scripts or processes by excluding specific command lines or process names that are verified as non-threatening.
-- Implementing a whitelist of trusted users or processes that are allowed to modify swap settings can help reduce false positives while maintaining security monitoring for unauthorized changes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further resource hijacking and potential lateral movement.
-- Investigate the process tree to identify the parent process and any related processes that may have initiated the swap modification.
-- Terminate any suspicious processes, especially those related to cryptomining software like XMRig, to halt malicious activity.
-- Review system logs and command history to determine the extent of the compromise and identify any unauthorized changes to swap settings.
-- Restore swap settings to their default values and ensure that no unauthorized modifications persist.
-- Conduct a thorough scan of the system using updated antivirus or anti-malware tools to detect and remove any remaining threats.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and command-line activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Apply system hardening measures, such as restricting access to swap configuration files and limiting the execution of swap-related commands to authorized users only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/impact_potential_linux_ransomware_note_detected.toml b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
index 6b0a3c524a8..73956314421 100644
--- a/rules/linux/impact_potential_linux_ransomware_note_detected.toml
+++ b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -71,49 +71,6 @@ sequence by process.entity_id, host.id with maxspan=1s
    file.name : ("*restore*", "*lock*", "*recovery*", "*read*", "*instruction*", "*how_to*", "*ransom*")
   ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Linux Ransomware Note Creation Detected
-
-Ransomware exploits file encryption to extort victims, often leaving a note with payment instructions. This detection rule identifies suspicious mass file renaming and the creation of text files with keywords like "ransom" or "recovery" within a second. By monitoring these patterns, it helps detect ransomware activity, focusing on unusual file operations in critical directories while excluding benign processes.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process.entity_id and host.id involved in the suspicious activity.
-- Examine the process.executable path to determine if it is located in unusual directories such as /tmp, /var/tmp, or /dev/shm, which are often used by malicious actors.
-- Check the file paths involved in the renaming and creation events to see if they are in critical directories like /home/*/Documents, /root, or /var/www, which could indicate a targeted attack.
-- Investigate the process.name to ensure it is not one of the benign processes listed in the exclusion criteria, such as dpkg, yum, or python*.
-- Use Osquery to gather more information about the process by running a query like: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve details about the process, including its parent process and command line arguments.
-- Analyze the timing of the events to confirm that the mass file renaming and text file creation occurred within the 1-second timespan, as specified in the detection rule.
-- Look for additional file creation events on the host with names containing keywords like "restore", "lock", or "ransom" to identify other potential ransom notes.
-- Check the system logs for any unusual activity or errors around the time of the alert to gather more context about the system's state.
-- Investigate any network connections made by the suspicious process to external IP addresses, which could indicate communication with a command and control server.
-- Review any recent changes or installations on the host that could have introduced the suspicious process, such as new software installations or updates.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule due to mass file renaming or creation of temporary files with suspicious keywords. Users can handle this by excluding known update processes like "dpkg", "yum", "dnf", and "rpm" from the detection rule.
-- Development environments or scripts that frequently create or rename files in monitored directories might be flagged. Excluding processes such as "go", "java", "python*", and "node" can reduce false positives in these scenarios.
-- Backup or recovery operations that generate files with names containing keywords like "restore" or "recovery" could be mistakenly identified as ransomware activity. Users should consider excluding backup software processes from the rule.
-- Automated system maintenance tasks that involve file renaming or creation in critical directories may also be misinterpreted. Adding exceptions for known maintenance processes can help mitigate these false positives.
-- Users can refine the detection rule by adjusting the monitored directories or file name patterns to better align with their specific environment and reduce unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network immediately to prevent further spread of the ransomware.
-- Identify and terminate the malicious process responsible for the mass file encryption and note creation using process monitoring tools.
-- Conduct a thorough investigation to determine the scope of the attack, including identifying all affected files and systems.
-- Restore encrypted files from the most recent clean backup to ensure data integrity and minimize data loss.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Implement enhanced logging policies to capture detailed file and process activity, focusing on critical directories and suspicious file operations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide real-time alerts.
-- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known ransomware indicators and prevent future attacks.
-- Educate employees on recognizing phishing attempts and other common ransomware delivery methods to reduce the risk of initial infection.
-- Apply system hardening measures, such as disabling unnecessary services, applying security patches, and enforcing least privilege access controls, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/lateral_movement_ssh_it_worm_download.toml b/rules/linux/lateral_movement_ssh_it_worm_download.toml
index a433439b817..b356618ce41 100644
--- a/rules/linux/lateral_movement_ssh_it_worm_download.toml
+++ b/rules/linux/lateral_movement_ssh_it_worm_download.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/09/21"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -11,7 +13,7 @@ Identifies processes that are capable of downloading files with command line arg
 autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential SSH-IT SSH Worm Downloaded"
@@ -53,63 +55,20 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name in ("curl", "wget") and process.args : (
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name in ("curl", "wget") and process.args : (
   "https://thc.org/ssh-it/x", "http://nossl.segfault.net/ssh-it-deploy.sh", "https://gsocket.io/x",
   "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential SSH-IT SSH Worm Downloaded
-
-SSH is a protocol used for secure remote access and management of systems. Adversaries exploit this by deploying worms like SSH-IT, which hijack SSH sessions to spread laterally across networks. The detection rule identifies suspicious file downloads via common tools like curl and wget, targeting specific URLs associated with the SSH-IT worm, thus flagging potential threats early in the infection chain.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious file downloads using `curl` or `wget` with URLs associated with the SSH-IT worm.
-- Examine the process arguments (`process.args`) to verify if they match any of the known malicious URLs listed in the detection rule.
-- Identify the user account under which the suspicious process was executed to determine if it was initiated by a legitimate user or a compromised account.
-- Check the process execution time (`event.type == "start"`) to correlate with any unusual user activity or other suspicious events in the network.
-- Investigate the source IP address and hostname (`host.os.type == "linux"`) to determine if the affected system is part of a larger pattern of compromise.
-- Use Osquery to list all active SSH sessions on the affected host to identify any unauthorized or unusual connections:
-  ```sql
-  SELECT user, remote_address, remote_port, start_time FROM process_open_sockets WHERE local_port = 22;
-  ```
-- Analyze the system's SSH configuration files and logs to identify any unauthorized changes or anomalies that could indicate worm activity.
-- Review network traffic logs for the affected host to detect any lateral movement attempts or connections to known malicious IP addresses.
-- Cross-reference the alert with other security tools and logs to gather additional context and identify any related alerts or incidents.
-- Document all findings and observations to build a comprehensive timeline of events leading up to and following the alert.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often use tools like curl and wget for routine maintenance and updates, which may involve downloading scripts or files from URLs that are not malicious. To manage this, users can create exceptions for known and trusted URLs or specific administrative accounts that frequently perform these tasks.
-- Automated scripts and cron jobs: Some automated processes may use curl or wget to fetch updates or data from external sources. Users should review these scripts to ensure they are benign and consider excluding them from the detection rule by specifying the script names or paths.
-- Development and testing environments: Developers might use curl and wget to test connectivity or download resources during development. In such cases, users can exclude specific development machines or user accounts from the rule to prevent false positives.
-- Security tools and monitoring solutions: Some security tools may use these commands to verify the availability of resources or to perform security checks. Users should identify these tools and exclude their processes from triggering the detection rule.
-- Educational and research activities: In academic or research settings, users might download various resources for study purposes. Users can manage these false positives by excluding specific user groups or IP ranges associated with educational activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the SSH-IT worm.
-- Conduct a thorough investigation of the affected system to identify any unauthorized SSH connections or additional malware.
-- Terminate any suspicious processes related to the worm, such as those initiated by curl or wget with the identified malicious URLs.
-- Remove any downloaded malicious files and scripts associated with the SSH-IT worm from the system.
-- Reset credentials for any compromised accounts and ensure SSH keys are rotated to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the infection.
-- Implement enhanced logging policies to capture detailed SSH session activities and command executions for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
-- Harden the system by configuring SSH to use key-based authentication, disabling root login, and enforcing strong password policies."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/lateral_movement_telnet_network_activity_external.toml b/rules/linux/lateral_movement_telnet_network_activity_external.toml
index 756687b2e87..4e1372c9e34 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_external.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_external.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -88,49 +88,6 @@ sequence by process.entity_id
     )
   ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Connection to External Network via Telnet
-
-Telnet is a protocol offering command-line access to remote systems, often used for network device management. Adversaries exploit Telnet to gain unauthorized access to external networks, bypassing security controls. The detection rule identifies Telnet connections to non-private IPs, flagging potential lateral movement or remote service abuse, aligning with MITRE ATT&CK's T1021 technique.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process.entity_id and destination.ip involved in the Telnet connection to a non-private IP address.
-- Verify the legitimacy of the destination IP by checking if it belongs to known external services or if it is associated with any suspicious or malicious activity.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve details about the Telnet process, including its parent process and command-line arguments.
-- Investigate the user account associated with the Telnet process by checking the process's user ID and correlating it with recent login activities to determine if the account has been compromised.
-- Examine network logs to identify any other unusual or unauthorized connections originating from the same host, focusing on connections to external IPs.
-- Check for any recent changes or anomalies in the system's configuration files or network settings that could indicate tampering or unauthorized access.
-- Analyze historical data to determine if there have been previous Telnet connections from the same host to external networks, which could indicate a pattern of suspicious behavior.
-- Correlate the Telnet activity with other security alerts or logs to identify potential lateral movement or coordinated attacks within the network.
-- Investigate the host's security posture by reviewing installed software, open ports, and running services to identify any vulnerabilities or misconfigurations that could have been exploited.
-- Consult threat intelligence sources to determine if the destination IP or any related indicators of compromise are associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Telnet connections to external IPs that are part of legitimate business operations, such as remote management of company-owned devices, can trigger false positives. Users can handle these by creating exceptions for known IP addresses that are part of regular business activities.
-- Automated scripts or monitoring tools that use Telnet for legitimate network management tasks may be flagged. To manage this, users can whitelist specific process names or scripts that are verified as non-threatening.
-- Connections to cloud service providers or third-party vendors that use public IP addresses for legitimate services might be incorrectly flagged. Users should identify and exclude these IP ranges from the detection rule to prevent unnecessary alerts.
-- Testing environments or labs that simulate external connections for development purposes can cause false positives. Users can exclude these environments by specifying their IP ranges or hostnames in the rule exceptions.
-- Legacy systems that rely on Telnet for communication with external partners may be mistakenly identified as threats. Users should document and exclude these systems from the rule to ensure they are not flagged during routine operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying any other systems that may have been accessed using Telnet.
-- Review system logs and Telnet session records to gather evidence and understand the adversary's actions and objectives.
-- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions.
-- Remove any unauthorized accounts or backdoors that may have been created by the adversary.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Implement network segmentation to limit the ability of adversaries to move laterally within the network.
-- Enhance logging and monitoring policies to include detailed Telnet session logs and alerts for connections to non-private IPs.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/lateral_movement_telnet_network_activity_internal.toml b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
index fb8dd422f01..2f57dba3856 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_internal.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -88,48 +88,6 @@ sequence by process.entity_id
     )
   ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Connection to Internal Network via Telnet
-
-Telnet is a protocol offering command-line access to remote systems, often used for network device management. However, its lack of encryption makes it vulnerable to interception and misuse by adversaries for lateral movement within a network. The detection rule identifies Telnet connections to private IP ranges, signaling potential unauthorized access attempts, aligning with MITRE ATT&CK's lateral movement tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a Telnet connection to a private IP address, focusing on the `process.entity_id`, `destination.ip`, and `event.type` fields.
-- Verify the legitimacy of the Telnet process by checking the `process.name` and `host.os.type` fields to ensure it matches expected behavior for the system.
-- Use Osquery to gather additional context about the Telnet process by running a query such as: `SELECT * FROM processes WHERE name = 'telnet';` to retrieve details like the process ID, user, and command line arguments.
-- Investigate the source and destination IP addresses involved in the connection to determine if they belong to known or trusted devices within the network.
-- Check historical logs for previous Telnet connections from the same source IP to identify patterns or repeated unauthorized access attempts.
-- Analyze user activity associated with the Telnet process by reviewing login records and user sessions to identify any anomalies or unauthorized access.
-- Correlate the Telnet activity with other network traffic logs to identify any concurrent suspicious activities or lateral movement attempts.
-- Examine the system's security configuration and patch levels to assess if vulnerabilities could have been exploited to initiate the Telnet connection.
-- Review firewall and network access control logs to determine if there were any changes or anomalies that could have facilitated the Telnet connection.
-- Consult with system administrators or network engineers to verify if the Telnet connection was part of any scheduled maintenance or legitimate administrative task.
-
-### False positive analysis
-
-- Telnet connections initiated by network administrators for legitimate device management tasks can trigger false positives. Users can handle these by creating exceptions for known administrator IP addresses or specific devices frequently accessed for maintenance.
-- Automated scripts or monitoring tools that use Telnet for routine checks on network devices may also be flagged. To manage this, users can whitelist the IP addresses or process names associated with these scripts.
-- Internal testing environments that simulate network conditions using Telnet might be mistakenly identified as threats. Users should consider excluding IP ranges or hostnames associated with these testing environments.
-- Legacy systems that rely on Telnet for communication within a secure network segment could generate false positives. Users can mitigate this by defining exceptions for these systems, ensuring they are monitored through other security measures.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the Telnet connection, including reviewing logs and network traffic for any suspicious activity.
-- Terminate any unauthorized Telnet sessions and disable Telnet services on the affected system to prevent future misuse.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement network segmentation to limit access to critical systems and reduce the risk of lateral movement.
-- Enhance logging and monitoring by enabling detailed logging for Telnet and other remote access protocols, and integrate with a security information and event management (SIEM) system for real-time analysis.
-- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate known vulnerabilities.
-- Conduct a security audit of the affected system to identify and remediate any additional security weaknesses.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure that all security measures are in place.
-- Implement hardening measures such as disabling unused services, enforcing strong authentication mechanisms, and using encrypted protocols for remote access to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_execution.toml b/rules/linux/persistence_apt_package_manager_execution.toml
index ad7844829cc..89411c0d829 100644
--- a/rules/linux/persistence_apt_package_manager_execution.toml
+++ b/rules/linux/persistence_apt_package_manager_execution.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/02/01"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -14,7 +16,7 @@ repositories. Attackers can backdoor APT to gain persistence by injecting malici
 thereby ensuring continued unauthorized access or control each time APT is used for package management.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious APT Package Manager Execution"
@@ -56,64 +58,23 @@ tags = [
     "Tactic: Execution",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 type = "eql"
 
 query = '''
 sequence by host.id with maxspan=5s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.parent.name == "apt" and process.args == "-c" and process.name in (
      "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
    )
   ] by process.entity_id
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name : (
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name : (
      "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*",
      "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk"
    )
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious APT Package Manager Execution
-
-APT, a tool for managing software on Debian-based Linux systems, can be exploited by attackers to maintain persistence. By injecting malicious code into scripts executed by APT, adversaries can ensure unauthorized access whenever APT is used. The detection rule identifies suspicious executions by monitoring for shell or scripting language processes initiated by APT, indicating potential backdoor activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and process entity IDs involved in the suspicious execution.
-- Examine the process tree to understand the parent-child relationship, focusing on the parent process named "apt" and its child processes, especially those involving shell or scripting languages.
-- Check the command-line arguments of the suspicious processes, particularly looking for the "-c" flag, which may indicate execution of a command string.
-- Investigate the timing of the suspicious process events to determine if they align with legitimate package management activities or if they appear anomalous.
-- Use Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name IN ('bash', 'dash', 'sh', 'tcsh', 'csh', 'zsh', 'ksh', 'fish', 'python', 'php', 'perl', 'ruby', 'lua', 'openssl', 'nc', 'netcat', 'ncat', 'telnet', 'awk') AND parent = (SELECT pid FROM processes WHERE name = 'apt');`
-- Analyze the environment variables and working directory of the suspicious processes to identify any unusual settings or paths that could indicate tampering.
-- Review the system logs for any additional context around the time of the alert, such as user logins, cron jobs, or other scheduled tasks that might correlate with the suspicious activity.
-- Check for any recent changes to APT configuration files or scripts that could have been modified to include malicious code.
-- Investigate the network activity of the host around the time of the alert to identify any suspicious outbound connections that could suggest data exfiltration or command-and-control communication.
-- Correlate the findings with other security alerts or incidents involving the same host or user account to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use APT to perform legitimate package management tasks that may trigger the detection rule. These tasks can include running scripts for configuration or maintenance purposes, which might involve shell or scripting language processes.
-- Custom scripts: Organizations may have custom scripts that are executed during package installations or updates. These scripts could be mistakenly flagged as suspicious if they involve shell or scripting language processes.
-- Automated deployment tools: Tools like Ansible, Puppet, or Chef might use APT as part of their automated deployment processes, leading to benign script executions that could be misinterpreted as suspicious.
-- To manage false positives, users can create exceptions for known benign processes or scripts by whitelisting specific process names or command-line arguments that are frequently used in legitimate operations. This can be done by adjusting the detection rule to exclude these known non-threatening behaviors.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify any malicious scripts or code injected into APT-related scripts or processes.
-- Review and analyze logs from the affected system to trace the origin and timeline of the suspicious APT execution.
-- Remove any identified malicious scripts or code and restore original APT scripts from a trusted source or backup.
-- Update all system packages and apply security patches to mitigate any known vulnerabilities that could be exploited.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to monitor for similar threats.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence sharing.
-- Restore the system to its operational state by verifying the integrity of critical system files and configurations.
-- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and regularly reviewing user permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_file_creation.toml b/rules/linux/persistence_apt_package_manager_file_creation.toml
index ea7c9a53d31..a9d7f872d29 100644
--- a/rules/linux/persistence_apt_package_manager_file_creation.toml
+++ b/rules/linux/persistence_apt_package_manager_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -88,50 +88,6 @@ file.path : "/etc/apt/apt.conf.d/*" and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 APT Package Manager Configuration File Creation
-
-APT, a key utility in Debian-based Linux systems, manages software packages and repositories. Adversaries may exploit APT by inserting malicious scripts into its configuration files, ensuring persistent unauthorized access. The detection rule identifies suspicious file creation or renaming in APT's configuration directory, excluding legitimate processes, to flag potential backdoor attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and name involved in the creation or renaming event within the `/etc/apt/apt.conf.d/` directory.
-- Check the `process.executable` field to determine which process was responsible for the file creation or renaming. Verify if it matches any known legitimate processes or if it appears suspicious.
-- Investigate the `process.name` field to identify the process name associated with the event. Cross-reference this with known benign processes to rule out false positives.
-- Examine the `file.extension` and `file.Ext.original.extension` fields to ensure the file does not have extensions commonly associated with temporary or transitional files, such as "swp", "swpx", "swx", or "dpkg-new".
-- Use Osquery to gather more context about the file and process. For example, run the following query to list details about the file and its associated process: `SELECT * FROM file WHERE path = '/etc/apt/apt.conf.d/<file_name>';`.
-- Investigate the parent process of the suspicious process using the `process.parent` field to understand the process hierarchy and identify potential sources of the unauthorized action.
-- Check system logs, such as `/var/log/auth.log` or `/var/log/syslog`, for any related entries around the time of the event to identify any unusual activity or unauthorized access attempts.
-- Review recent user activity on the system to determine if any user accounts were active during the time of the event and if they have a history of legitimate administrative actions.
-- Analyze network logs to identify any outbound connections from the host that may indicate data exfiltration or communication with a command and control server.
-- Correlate the event with other security alerts or incidents in the environment to determine if this is part of a larger attack campaign or isolated incident.
-
-### False positive analysis
-
-- Legitimate package management operations: System administrators or automated processes may create or rename files in the APT configuration directory during routine package management tasks. These actions are typically performed by trusted package management tools like `dpkg`, `apt-get`, or `snapd`, which are already excluded in the detection rule.
-- Temporary files: Editors like `vim` or `nano` may create temporary files with extensions such as `.swp` or `.swx` while editing configuration files. These are non-threatening and are excluded by checking for specific file extensions.
-- System updates and maintenance scripts: Automated scripts or system maintenance tools may modify APT configuration files as part of their normal operation. Users can handle these by adding exceptions for known maintenance scripts or processes.
-- Custom scripts or tools: Organizations may use custom scripts or third-party tools for managing APT configurations. Users should identify these scripts and add their paths or process names to the exclusion list to prevent false positives.
-- Exclude specific directories: If certain directories within `/etc/apt/apt.conf.d/` are known to be used for legitimate purposes, users can modify the rule to exclude these paths from monitoring.
-- Monitor process context: Ensure that the process context of file creation or renaming events is analyzed. If a known and trusted process is responsible, consider adding it to the exclusion list to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the malicious file creation, examining logs and process histories to trace the attack vector.
-- Remove any unauthorized or suspicious files from the APT configuration directory and restore original configuration files from a known good backup.
-- Review and update the system's APT package manager and related software to the latest versions to patch any vulnerabilities.
-- Implement enhanced logging for file creation and modification events in critical directories, ensuring logs are sent to a centralized logging solution for continuous monitoring.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
-- Conduct a comprehensive security audit of the system to identify and remediate any additional vulnerabilities or misconfigurations.
-- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the attack appears to be part of a larger campaign or if advanced persistent threat (APT) actors are suspected.
-- Restore the system to its operational state by verifying the integrity of all system files and configurations, ensuring no backdoors or malicious scripts remain.
-- Implement hardening measures such as restricting write permissions to critical directories, enforcing the principle of least privilege, and regularly reviewing user access rights."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_netcon.toml b/rules/linux/persistence_apt_package_manager_netcon.toml
index 415647ccaa0..4fbac8005de 100644
--- a/rules/linux/persistence_apt_package_manager_netcon.toml
+++ b/rules/linux/persistence_apt_package_manager_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -77,50 +77,6 @@ sequence by host.id with maxspan=5s
    ) and not process.executable == "/usr/bin/apt-listbugs"
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious APT Package Manager Network Connection
-
-The APT package manager is crucial for managing software on Debian-based Linux systems, handling installations and updates. Adversaries may exploit APT by embedding malicious scripts to maintain unauthorized access. The detection rule identifies unusual network connections initiated by APT, excluding known safe IP ranges, to spot potential backdoor activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and process entity IDs involved in the suspicious activity.
-- Examine the process execution details, focusing on the parent process name "apt" and the child process names such as "bash", "dash", "sh", etc., to understand the context of the script execution.
-- Check the command-line arguments used with the APT process, especially the presence of the "-c" flag, which indicates a custom configuration file, to identify any unusual or unauthorized configurations.
-- Investigate the network connection details, particularly the destination IP address, to determine if it falls outside the known safe IP ranges and assess its legitimacy.
-- Use Osquery to gather additional context on the suspicious process by running a query like: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve detailed information about the process, including its command line, parent process, and execution path.
-- Analyze the network traffic logs for the host to identify any other unusual or unauthorized connections that may correlate with the suspicious APT activity.
-- Review the system logs on the affected host for any related entries that might provide additional context or evidence of compromise, such as authentication logs or system events.
-- Check for any recent changes to the APT configuration files or scripts on the host that could indicate tampering or unauthorized modifications.
-- Investigate the history of package installations and updates on the host to identify any recent or suspicious package activities that could be linked to the alert.
-- Correlate the findings with other security alerts or incidents involving the same host or network to determine if this activity is part of a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives may include legitimate scripts executed by APT that initiate network connections for valid package management tasks, such as fetching updates or accessing external repositories.
-- Network connections to newly added or less common repositories might be flagged as suspicious if they fall outside the predefined safe IP ranges, even if they are legitimate.
-- Users can handle these false positives by creating exceptions for specific IP addresses or ranges that are known to be safe and frequently accessed by APT during normal operations.
-- It is advisable to maintain an updated list of trusted repositories and their associated IP addresses to minimize false positives while ensuring security.
-- Regularly review and update the exclusion list to accommodate changes in network infrastructure or repository configurations, ensuring that legitimate activities are not mistakenly flagged.
-- Consider implementing additional context checks, such as verifying the digital signatures of packages, to differentiate between legitimate and potentially malicious activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the APT package manager logs and any associated scripts to identify and analyze the malicious code or backdoor.
-- Terminate any suspicious processes initiated by the APT package manager that are not part of legitimate package management activities.
-- Remove or replace any compromised scripts or packages identified during the investigation to eliminate the backdoor.
-- Restore the system from a known good backup if the integrity of the system is in question and ensure all software is up to date.
-- Implement enhanced logging policies to capture detailed information on APT package manager activities and network connections for future analysis.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known malicious IP addresses and unusual outbound connections.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface and prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_at_job_creation.toml b/rules/linux/persistence_at_job_creation.toml
index cac28b8ae71..cebef39e692 100644
--- a/rules/linux/persistence_at_job_creation.toml
+++ b/rules/linux/persistence_at_job_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -79,50 +79,6 @@ event.action in ("rename", "creation") and file.path : "/var/spool/cron/atjobs/*
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 At Job Created or Modified
-
-The 'at' command in Linux schedules tasks for future execution, aiding system administrators in automating routine jobs. However, attackers can exploit this by creating or altering 'at' jobs to maintain persistence, escalate privileges, or execute unauthorized commands. The detection rule identifies suspicious 'at' job activities by monitoring file changes in specific directories, excluding benign processes and extensions, thus highlighting potential malicious actions.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process executable involved in the 'at' job creation or modification, focusing on the `file.path` and `process.executable` fields.
-- Verify the legitimacy of the process executable by checking its hash against known good hashes or using threat intelligence sources to determine if it is associated with known malicious activity.
-- Use Osquery to list all scheduled 'at' jobs on the system to identify any unexpected or unauthorized entries. Example query: `SELECT * FROM at_jobs;`
-- Investigate the user account associated with the process that created or modified the 'at' job to determine if it has been compromised or is being misused.
-- Check the process tree to understand the parent process and any child processes spawned by the suspicious executable, which can provide context on how the 'at' job was created or modified.
-- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual login attempts or privilege escalation activities around the time the 'at' job was created or modified.
-- Analyze the contents of the 'at' job script or command to determine its purpose and whether it contains any malicious or unauthorized actions.
-- Cross-reference the timing of the 'at' job creation or modification with other security alerts or incidents to identify potential correlations or patterns of attack.
-- Investigate any network connections initiated by the process executable to external IP addresses, which may indicate data exfiltration or command-and-control communication.
-- Review the system's history of software installations and updates to ensure that the process executable is not part of a legitimate software update or installation process.
-
-### False positive analysis
-
-- System updates and package management activities can trigger false positives as they often involve creating or modifying files in the `/var/spool/cron/atjobs/` directory. Processes like `dpkg`, `rpm`, `yum`, and `dnf` are commonly involved in these activities and should be excluded to prevent unnecessary alerts.
-- Container management tools such as `dockerd` and `podman` may also modify files in the monitored directory during normal operations. Excluding these processes can help reduce false positives.
-- Automated system maintenance scripts, such as those run by `puppet` or `chef-client`, might create or modify at jobs as part of their configuration management tasks. These should be considered for exclusion if they are part of regular, authorized operations.
-- Temporary files created by text editors (e.g., with extensions like `.swp`, `.swpx`, `.swx`) can be mistaken for suspicious activity. Excluding these file extensions can help in minimizing false alerts.
-- Processes running from specific directories like `/nix/store/`, `/var/lib/dpkg/`, or `/snap/` are often part of legitimate system operations and can be safely excluded if verified as non-threatening.
-- Users can manage false positives by regularly reviewing and updating the exclusion list to include any new benign processes or file patterns that are identified during routine system operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks.
-- Review the 'at' job entries in the /var/spool/cron/atjobs/ directory to identify any unauthorized or suspicious jobs and remove them.
-- Investigate the process that created or modified the 'at' job by examining logs and process details to determine if it was a legitimate action or part of a malicious activity.
-- Check for other signs of compromise on the system, such as unexpected user accounts, unauthorized software installations, or unusual network activity.
-- Restore the system from a known good backup if the investigation confirms a compromise, ensuring that all malicious changes are removed.
-- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed information about process executions and file modifications, aiding in future investigations.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to monitor for similar activities in the future.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate users and administrators about the risks associated with scheduled tasks and the importance of monitoring and securing these configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_chkconfig_service_add.toml b/rules/linux/persistence_chkconfig_service_add.toml
index 68cc6cadbb7..3387c9b8070 100644
--- a/rules/linux/persistence_chkconfig_service_add.toml
+++ b/rules/linux/persistence_chkconfig_service_add.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2022/07/22"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -53,7 +55,7 @@ either a start or a kill entry in every runlevel and when the system is rebooted
 providing long-term persistence.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Chkconfig Service Add"
@@ -169,11 +171,12 @@ tags = [
     "Threat: Lightning Framework",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and
 ( 
   (process.executable : "/usr/sbin/chkconfig" and process.args : "--add") or
   (process.args : "*chkconfig" and process.args : "--add")
diff --git a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
index bfecd73a95d..8ebf2a224c5 100644
--- a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/06/25"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -14,7 +16,7 @@ persistence by injecting malicious code into plugins that DNF runs, thereby ensu
 control each time DNF is used for package management.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.file*"]
+index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "DNF Package Manager Plugin File Creation"
@@ -58,6 +60,8 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -84,50 +88,6 @@ file.path : ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 DNF Package Manager Plugin File Creation
-
-DNF, a package manager for Fedora-based systems, manages software installations and updates. Adversaries may exploit DNF by inserting malicious code into its plugins, ensuring persistent access whenever DNF is used. The detection rule identifies suspicious file creation or renaming in plugin directories, excluding benign processes and temporary files, to flag potential backdoor attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and event action (creation or rename) that triggered the alert. Focus on paths like `/usr/lib/python*/site-packages/dnf-plugins/*` and `/etc/dnf/plugins/*`.
-- Check the process executable that initiated the file creation or rename event. Ensure it is not one of the benign processes listed in the exclusion criteria, such as `/bin/dnf` or `/usr/bin/yum`.
-- Investigate the file extension of the newly created or renamed file to ensure it is not a temporary file with extensions like `swp`, `swpx`, or `swx`.
-- Use Osquery to gather more information about the file. For example, run the query: `SELECT * FROM file WHERE path = '/usr/lib/python*/site-packages/dnf-plugins/*' OR path = '/etc/dnf/plugins/*';` to get details about the file's metadata and attributes.
-- Examine the file's contents to identify any suspicious or unauthorized code that may have been injected. Look for unusual scripts or commands that do not align with typical plugin functionality.
-- Cross-reference the file creation or rename event with recent system logs to identify any correlated activities or anomalies around the time of the event.
-- Verify the integrity of the DNF package manager and its plugins by comparing the current state with known good baselines or checksums, if available.
-- Investigate the user account associated with the process that created or renamed the file to determine if it has the necessary permissions and if the activity aligns with expected behavior.
-- Check for any recent changes in user privileges or group memberships that could have facilitated unauthorized access to the plugin directories.
-- Review historical data to identify any previous similar alerts or patterns that could indicate a persistent threat or ongoing attack campaign targeting the DNF package manager.
-
-### False positive analysis
-
-- Routine system updates or administrative tasks may trigger file creation or renaming events in the DNF plugin directories, especially when legitimate software updates or configurations are applied. Users should verify if these events coincide with scheduled maintenance or updates.
-- Automated scripts or configuration management tools like Puppet or Chef might create or modify files in these directories as part of their normal operations. Users can exclude these processes by adding them to the exception list if they are verified as non-malicious.
-- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be mistakenly flagged. Users should ensure these extensions are included in the exclusion criteria to prevent false alerts.
-- Processes running from specific directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users can add these paths to the exclusion list if they are confirmed to be safe.
-- If the process executable is null, it might indicate a transient or incomplete event capture. Users should investigate these cases further to determine if they are benign or require additional context for exclusion.
-- Specific processes like "sed" or "perl" might create temporary files during their operations. Users can exclude these processes when they match known benign patterns, such as "sed*" or "e2scrub_all.tmp*", to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify any malicious code within the DNF plugin directories and determine the extent of the compromise.
-- Review recent file creation and modification events in the DNF plugin directories to identify unauthorized changes and potential backdoor installations.
-- Remove any identified malicious files or code from the DNF plugin directories and restore legitimate files from a known good backup.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging for DNF-related activities and file system changes to improve detection of future unauthorized modifications.
-- Integrate security tools with threat intelligence feeds to identify known malicious indicators related to DNF plugin tampering.
-- Apply security patches and updates to the DNF package manager and related software to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
-- Educate system administrators and users on recognizing signs of compromise and the importance of maintaining secure configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
index 4e3be9a2060..b55731cca6e 100644
--- a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -59,48 +59,6 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:dpkg and
 process.args:("-i" or "--install")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 DPKG Package Installed by Unusual Parent Process
-
-DPKG is a core utility for managing Debian packages on Linux, crucial for software installation and maintenance. Adversaries may exploit DPKG to install harmful packages, leveraging unusual parent processes to evade detection. The detection rule identifies such anomalies by monitoring DPKG executions initiated by atypical parent processes, focusing on installation actions, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `dpkg` command execution with the `-i` or `--install` argument, as these indicate package installation attempts.
-- Identify and document the unusual parent process that initiated the `dpkg` command. This can provide insights into potential misuse or compromise of legitimate processes.
-- Cross-reference the parent process with known benign processes or scheduled tasks to rule out false positives.
-- Use Osquery to gather additional context about the parent process. For example, run the following query to list processes with their parent process IDs and command lines: `SELECT pid, name, cmdline, parent FROM processes WHERE name = 'dpkg';`
-- Investigate the user account associated with the `dpkg` execution to determine if it aligns with expected administrative activity or if it suggests unauthorized access.
-- Check system logs for any preceding or subsequent suspicious activities around the time of the `dpkg` execution, such as unusual login attempts or privilege escalation.
-- Examine the installed package details, including the package name, version, and source, to assess whether it is a known or potentially malicious package.
-- Review network logs for any outbound connections made by the system around the time of the package installation, which might indicate data exfiltration or command-and-control communication.
-- Investigate any file modifications or new files created in system directories that could be associated with the installed package, using file integrity monitoring tools or manual inspection.
-- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- System administrators or automated scripts may trigger the DPKG installation process for legitimate software updates or installations, leading to false positives. To manage this, users can create exceptions for known administrative scripts or processes that regularly perform package installations.
-- Some system management tools or configuration management software, such as Ansible or Puppet, might use DPKG to install packages as part of their normal operations. Users can exclude these tools by identifying their typical parent processes and adding them to an allowlist.
-- During system provisioning or automated deployment processes, DPKG might be invoked by non-standard parent processes. Users should review these processes and, if deemed safe, configure exceptions to prevent unnecessary alerts.
-- Developers or testing environments might use custom scripts to install packages for testing purposes, which could be flagged as unusual. Users can handle these by documenting and excluding these specific scripts or environments from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity.
-- Conduct a thorough investigation to identify the unusual parent process that initiated the DPKG command and determine if it is associated with known malicious activity.
-- Review system logs and process execution history to trace the origin and impact of the installed package, ensuring no other systems are compromised.
-- Remove any suspicious or unauthorized packages installed by the DPKG command to mitigate potential threats.
-- Restore the system to a known good state using backups or system snapshots, ensuring all critical data is preserved.
-- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if the threat cannot be contained.
-- Implement enhanced logging policies to capture detailed process execution and parent-child relationships for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Apply system hardening measures, such as restricting the execution of administrative commands to authorized users and processes only.
-- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness and response times."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dpkg_unusual_execution.toml b/rules/linux/persistence_dpkg_unusual_execution.toml
index 57fb71013ea..63beaf41029 100644
--- a/rules/linux/persistence_dpkg_unusual_execution.toml
+++ b/rules/linux/persistence_dpkg_unusual_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ process.group_leader.name != null and not (
   process.parent.executable in ("/usr/share/debconf/frontend", "/usr/bin/unattended-upgrade")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual DPKG Execution
-
-DPKG is a core utility in Debian-based Linux systems for managing software packages. While essential for legitimate package management, adversaries can exploit DPKG to install malicious software, gaining persistence or executing unauthorized actions. The detection rule identifies anomalies by flagging DPKG executions from unexpected processes, excluding known legitimate sources, thus highlighting potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process triggered the Unusual DPKG Execution rule, focusing on the `process.executable` and `process.parent.name` fields.
-- Verify the legitimacy of the process by checking the `process.session_leader.name` and `process.group_leader.name` to ensure they are not associated with known legitimate DPKG operations.
-- Investigate the parent process by examining the `process.parent.executable` to determine if it is a known and trusted application.
-- Use Osquery to gather more information about the suspicious process. For example, run the following query to list all processes related to the suspicious executable: `SELECT * FROM processes WHERE path = '/var/lib/dpkg/info/*';`
-- Check the system logs for any recent package installations or removals that coincide with the alert timestamp to identify any unauthorized package management activities.
-- Investigate the network activity of the host around the time of the alert to identify any suspicious outbound connections that might indicate data exfiltration or command-and-control communication.
-- Examine the file system for any newly created or modified files in the `/var/lib/dpkg/info/` directory that could be associated with the suspicious DPKG execution.
-- Review user activity logs to determine if any unauthorized users were logged in or if there were any unusual login attempts around the time of the alert.
-- Cross-reference the alert with other security tools and logs to identify any correlated events or indicators of compromise that might provide additional context.
-- Document all findings and observations to build a comprehensive understanding of the incident, which will aid in determining the next steps for response and remediation.
-
-### False positive analysis
-
-- Automated system maintenance tasks: Some automated scripts or system maintenance tools might invoke DPKG for legitimate purposes, such as system updates or configuration changes, which could be flagged as unusual. Users can handle these by identifying the specific scripts or tools and adding them to the exclusion list.
-- Custom administrative scripts: Administrators may use custom scripts to manage packages across multiple systems. These scripts, if not recognized by the rule, could trigger false positives. Users should review these scripts and, if deemed safe, exclude them from the rule.
-- Non-standard package management tools: Some organizations might use alternative package management tools that interact with DPKG in unconventional ways. These tools should be identified and excluded if they are verified to be non-threatening.
-- Development and testing environments: In environments where software is frequently installed and removed for testing purposes, DPKG executions might be more common and benign. Users can create exceptions for these environments to reduce noise.
-- Legacy systems or configurations: Older systems or unique configurations might have different processes interacting with DPKG. Users should assess these systems and consider excluding them if they consistently generate false positives without indicating a threat.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious software.
-- Conduct a thorough investigation to identify the source of the unusual DPKG execution, examining process trees and related logs for any unauthorized changes or installations.
-- Verify the integrity of installed packages using checksums or package verification tools to identify any tampered or malicious packages.
-- Remove any unauthorized or malicious packages identified during the investigation to mitigate the threat.
-- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
-- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds to correlate unusual DPKG executions with known threat actor tactics, techniques, and procedures (TTPs).
-- Apply system hardening measures, such as restricting DPKG execution to trusted users and processes, and implementing application whitelisting.
-- Conduct a post-incident review to update incident response plans and improve detection rules based on lessons learned from the investigation."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_git_hook_execution.toml b/rules/linux/persistence_git_hook_execution.toml
index 66f1b25a248..02a845525d1 100644
--- a/rules/linux/persistence_git_hook_execution.toml
+++ b/rules/linux/persistence_git_hook_execution.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/07/15"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ executes before or after events such as: commit, push, and receive. An attacker
 commands on the system and establish persistence.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*"]
+index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Git Hook Command Execution"
@@ -56,61 +58,19 @@ tags = [
     "Tactic: Execution",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 type = "eql"
 
 query = '''
 sequence by host.id with maxspan=3s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.parent.name == "git" and process.args : ".git/hooks/*" and
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
   ] by process.entity_id
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Git Hook Command Execution
-
-Git hooks are scripts that automate tasks during Git operations like commits or pushes. While useful for developers, adversaries can exploit them to run unauthorized commands, gaining persistence on a system. The detection rule identifies suspicious activity by monitoring for shell processes initiated by Git hooks, flagging potential misuse when these processes execute commands, indicating possible malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Git hook script that triggered the alert by examining the `process.args` field for the path pattern ".git/hooks/*".
-- Verify the parent process by checking the `process.parent.name` field to confirm it is a Git process, ensuring the alert is related to Git hook execution.
-- Investigate the child process initiated by the Git hook by examining the `process.name` field to determine which shell was used (e.g., bash, zsh).
-- Check the `process.entity_id` and `process.parent.entity_id` fields to trace the process lineage and understand the sequence of execution.
-- Use Osquery to list all Git hooks present in the repository by running: `SELECT path, content FROM file WHERE directory LIKE '%.git/hooks%' AND type = 'file';` to identify any unauthorized or suspicious scripts.
-- Examine the content of the suspicious Git hook script identified in the alert to understand its purpose and any commands it executes.
-- Cross-reference the execution time of the suspicious process with user activity logs to determine if the execution aligns with legitimate user actions.
-- Review system logs for any additional context around the time of the alert, focusing on any unusual or unexpected system changes or network activity.
-- Investigate the user account associated with the process execution to determine if it has been compromised or is exhibiting unusual behavior.
-- Check for any recent changes to the Git repository, including new commits or branches, that might indicate tampering or unauthorized access.
-
-### False positive analysis
-
-- Developers often use Git hooks for legitimate automation tasks, such as running tests or formatting code before commits, which can trigger the detection rule. These activities, while benign, may appear suspicious if they involve shell processes.
-- Continuous Integration/Continuous Deployment (CI/CD) systems might execute Git hooks as part of their automated workflows, leading to false positives. These systems often use shell scripts to manage build and deployment processes.
-- To manage these false positives, users can create exceptions for known and trusted scripts or processes by whitelisting specific Git hook paths or process names that are frequently used in their development environment.
-- Users should regularly review and update their exception lists to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
-- It's important to monitor the context of the detected activity, such as the timing and frequency of the hook execution, to differentiate between normal development operations and potential malicious behavior.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Investigate the Git repository and its hooks to identify any unauthorized modifications or scripts that may have been added by an attacker.
-- Review recent commits and changes in the repository to trace back any suspicious activities or unauthorized access.
-- Terminate any suspicious processes identified as being executed from Git hooks to stop potential malicious activities.
-- Restore the affected system from a known good backup to ensure that any malicious changes are removed.
-- Implement strict access controls and permissions for Git repositories to limit who can modify hooks and other critical files.
-- Enhance logging and monitoring by enabling detailed audit logs for Git operations and shell command executions to detect future anomalies.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities.
-- Conduct a thorough review of user accounts and credentials to ensure no unauthorized access has been granted, and reset passwords if necessary.
-- Educate developers and system administrators on secure coding practices and the risks associated with Git hooks to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_git_hook_file_creation.toml b/rules/linux/persistence_git_hook_file_creation.toml
index 429f12e9a1f..240262b8807 100644
--- a/rules/linux/persistence_git_hook_file_creation.toml
+++ b/rules/linux/persistence_git_hook_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -84,49 +84,6 @@ file.extension == null and process.executable != null and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Git Hook Created or Modified
-
-Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for workflow customization, adversaries can exploit them to maintain persistence by embedding malicious scripts. The detection rule identifies suspicious hook file changes on Linux systems, excluding benign processes, to flag potential unauthorized modifications.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Git hook file path that was created or modified, as indicated by the `file.path` field.
-- Verify the `process.executable` field to determine which process was responsible for the creation or modification of the Git hook file, and assess whether it is a known and trusted application.
-- Check the `event.type` field to confirm whether the event was a creation or modification, as this can provide context on whether a new hook was added or an existing one was altered.
-- Investigate the user account associated with the process by examining the process owner and any related user activity around the time of the event.
-- Use Osquery to gather additional context about the file and process. For example, run the following query to list all files in the `.git/hooks` directory and their metadata: `SELECT * FROM file WHERE path LIKE '/path/to/repo/.git/hooks/%';`
-- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious or unexpected scripts or commands.
-- Cross-reference the `process.name` field with known benign processes to ensure that the process responsible for the change is not typically associated with legitimate Git operations.
-- Review system logs and other security tools for any related suspicious activity or anomalies around the time of the Git hook modification.
-- Investigate any recent changes to the repository or system configuration that might explain the legitimate creation or modification of the Git hook.
-- Consult with the development or operations team to verify if the change was authorized and aligns with any recent updates or deployments.
-
-### False positive analysis
-
-- System package managers like `dpkg`, `rpm`, `yum`, and `dnf` may trigger false positives when they update or install packages that include Git hooks. These processes are typically benign and can be excluded by adding them to the exception list in the detection rule.
-- Container management tools such as `dockerd`, `podman`, and `microdnf` might modify Git hooks during container operations. These are generally safe and can be excluded by specifying their executables in the rule's exception criteria.
-- Automated system maintenance scripts or tools like `puppet`, `chef-client`, and `autossl_check` may create or modify Git hooks as part of their routine operations. Users can handle these by adding the specific process names or paths to the exclusion list.
-- Development tools and scripts, including `git`, `gitea`, and `git-lfs`, may modify hooks during normal development activities. These should be considered for exclusion if they are part of the regular development workflow.
-- Custom scripts or processes that are known and trusted within the organization might also trigger this rule. Users should review these cases and, if deemed safe, add them to the exception list to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the unauthorized Git hook modification, examining recent changes and user activity logs.
-- Review the contents of the modified or newly created Git hook files to determine if malicious code is present and assess the potential impact.
-- Remove any unauthorized or malicious scripts found in the Git hook files and restore them to their original state if possible.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging for Git operations and file modifications on critical systems to improve future detection capabilities.
-- Integrate security tools with version control systems to monitor and alert on suspicious activities related to Git hooks.
-- Apply system hardening measures, such as restricting write permissions to the .git/hooks directory to trusted users only.
-- Educate developers and system administrators on the risks associated with Git hooks and best practices for securing them.
-- Review and update incident response plans to include specific procedures for handling Git hook-related security incidents, leveraging MITRE ATT&CK framework details for persistence and system process modification."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_git_hook_netcon.toml b/rules/linux/persistence_git_hook_netcon.toml
index 2aea6cd0d19..9e7e71207fd 100644
--- a/rules/linux/persistence_git_hook_netcon.toml
+++ b/rules/linux/persistence_git_hook_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -76,48 +76,6 @@ sequence by host.id with maxspan=3s
    )
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Git Hook Egress Network Connection
-
-Git hooks are scripts triggered by Git events like commits or pushes, allowing automation of tasks. Adversaries can exploit these hooks to execute unauthorized commands, maintain persistence, or initiate network connections for data exfiltration. The detection rule identifies suspicious network activities by monitoring script executions from Git hooks and subsequent external network connections, flagging potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Git hook script involved by examining the `process.args` field for the path and name of the script.
-- Check the `process.name` field to determine which shell was used to execute the Git hook script, as this might provide insight into the attacker's familiarity with the environment.
-- Investigate the `destination.ip` field in the network event to identify the external IP address the connection was attempted to, and perform a reputation check on this IP address to assess its potential maliciousness.
-- Use the `process.entity_id` and `process.parent.entity_id` fields to correlate the process execution and network connection events, confirming the sequence of actions.
-- Examine the `host.id` field to identify the affected host and gather additional context about its role and importance within the network.
-- Utilize Osquery to gather more information about the Git configuration and hooks on the affected system. For example, run the following Osquery query to list all Git hooks present on the system: `SELECT path, content FROM file WHERE path LIKE '/path/to/repo/.git/hooks/%';`
-- Check the system's process execution history around the time of the alert to identify any other suspicious activities or processes that might be related.
-- Review the system logs for any unusual or unauthorized access attempts or changes around the time of the alert to identify potential indicators of compromise.
-- Investigate the user account associated with the process execution to determine if it has been compromised or if there are any signs of unauthorized access.
-- Analyze any additional network traffic from the affected host to identify other potential connections to suspicious or unauthorized external IP addresses.
-
-### False positive analysis
-
-- Legitimate automation scripts: Developers often use Git hooks for automation tasks such as triggering CI/CD pipelines or deploying applications. These scripts might initiate network connections to internal servers or cloud services, which could be flagged as suspicious. Users can handle these by creating exceptions for known and trusted scripts or IP addresses.
-- Internal network connections: Git hooks might connect to internal resources for tasks like fetching dependencies or updating configurations. These connections could be mistakenly identified as egress attempts. To manage this, users can exclude specific internal IP ranges or domains from the detection rule.
-- Development tools and integrations: Some development tools or integrations might use Git hooks to communicate with external services for legitimate purposes, such as code quality checks or notifications. Users should identify these tools and add them to an allowlist to prevent false positives.
-- Testing environments: In testing or staging environments, developers might intentionally use Git hooks to simulate network activities for testing purposes. Users can exclude these environments from monitoring or adjust the rule to account for known testing activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the specific Git hook script responsible for the suspicious activity and review its contents for malicious code.
-- Terminate any unauthorized processes initiated by the Git hook to halt ongoing malicious activities.
-- Analyze network logs to identify any external IP addresses contacted during the incident and block these addresses at the firewall level.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Restore the affected system from a known good backup to ensure the removal of any persistent threats.
-- Implement enhanced logging policies to capture detailed process execution and network connection attempts for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics, techniques, and procedures (TTPs).
-- Review and update Git hook permissions and configurations to limit execution to trusted scripts and users only.
-- Conduct a security awareness session for developers and system administrators on the risks associated with Git hooks and best practices for secure coding and configuration."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_git_hook_process_execution.toml b/rules/linux/persistence_git_hook_process_execution.toml
index 5f9d86f0d90..ca62a6fc067 100644
--- a/rules/linux/persistence_git_hook_process_execution.toml
+++ b/rules/linux/persistence_git_hook_process_execution.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/06/26"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ spawned by the Git process itself. This behavior may indicate an attacker attemp
 leveraging the legitimate Git process to execute unauthorized commands.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*"]
+index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Git Hook Child Process"
@@ -57,68 +59,32 @@ tags = [
     "Tactic: Execution",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name in (
-  "applypatch-msg", "commit-msg", "fsmonitor-watchman", "post-update", "post-checkout", "post-commit",
-  "pre-applypatch", "pre-commit", "pre-merge-commit", "prepare-commit-msg", "pre-push", "pre-rebase", "pre-receive",
-  "push-to-checkout", "update", "post-receive", "pre-auto-gc", "post-rewrite", "sendemail-validate", "p4-pre-submit",
-  "post-index-change", "post-merge", "post-applypatch"
-) and (
-  process.name in ("nohup", "setsid", "disown", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or 
-  process.name : ("php*", "perl*", "ruby*", "lua*") or 
-  process.executable : (
-    "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*",
-    "/run/*", "/srv/*", "/tmp/*", "/var/tmp/*", "/var/log/*"
-  )
-) and not process.name in ("git", "dirname")
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.parent.name in (
+    "applypatch-msg", "commit-msg", "fsmonitor-watchman", "post-update", "post-checkout", "post-commit",
+    "pre-applypatch", "pre-commit", "pre-merge-commit", "prepare-commit-msg", "pre-push", "pre-rebase", "pre-receive",
+    "push-to-checkout", "update", "post-receive", "pre-auto-gc", "post-rewrite", "sendemail-validate", "p4-pre-submit",
+    "post-index-change", "post-merge", "post-applypatch"
+  ) and
+  (
+    process.name in ("nohup", "setsid", "disown", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or 
+    process.name : ("php*", "perl*", "ruby*", "lua*") or 
+    process.executable : (
+      "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*",
+      "/run/*", "/srv/*", "/tmp/*", "/var/tmp/*", "/var/log/*"
+    )
+  ) and
+  not process.name in ("git", "dirname")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Git Hook Child Process
-
-Git hooks are scripts that automate tasks during Git operations like commits and pushes. While they enhance workflow efficiency, adversaries can exploit them to execute unauthorized commands by embedding malicious scripts. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts and executables, thus flagging potential misuse and aiding in threat detection.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Git hook that triggered the alert by examining the `process.parent.name` field.
-- Check the `process.name` and `process.executable` fields to determine the nature of the child process spawned by the Git hook and assess if it aligns with typical usage patterns.
-- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity is expected or if the account may have been compromised.
-- Use Osquery to list all Git hooks present in the repository to identify any unauthorized or suspicious scripts. Example query: `SELECT * FROM file WHERE path LIKE '/path/to/repo/.git/hooks/%';`
-- Examine the contents of the Git hook script that triggered the alert to identify any embedded malicious commands or unusual modifications.
-- Review recent commit history and changes in the repository to identify any unauthorized modifications that could indicate tampering with Git hooks.
-- Analyze the process tree to understand the sequence of events leading to the execution of the suspicious child process, focusing on the `process.parent.name` and `process.name` fields.
-- Check system logs for any additional context around the time of the alert, such as login events or other process executions, to correlate with the suspicious activity.
-- Investigate the network activity associated with the process by reviewing network logs or using network monitoring tools to identify any suspicious outbound connections.
-- Consult with the repository owner or development team to verify if the detected activity aligns with any recent changes or deployments, ensuring it is not a false positive.
-
-### False positive analysis
-
-- Developers often use custom scripts in Git hooks for legitimate purposes, such as automating testing or deployment processes, which may trigger the rule. To handle this, users can create exceptions for specific scripts or processes that are known to be safe and frequently used in their development environment.
-- Continuous Integration/Continuous Deployment (CI/CD) systems might execute scripts as part of their workflow, leading to false positives. Users should identify and whitelist these processes to prevent unnecessary alerts.
-- Some development environments or tools might use shell scripts or other scripting languages that match the rule's criteria. Users can exclude these known benign processes by adding them to an exception list, ensuring they are not flagged as suspicious.
-- In environments where developers frequently use temporary directories for legitimate purposes, processes executed from these locations might be flagged. Users should review and whitelist specific directories or processes that are consistently used for non-malicious activities.
-- If certain processes are consistently flagged but are known to be part of regular operations, users can adjust the rule to exclude these processes by adding them to the list of exceptions, ensuring that only truly suspicious activities are highlighted.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on the specific Git hooks and child processes flagged by the detection rule.
-- Review the contents of the Git hooks to identify any unauthorized or malicious scripts and remove them.
-- Analyze system logs and process execution history to trace the origin of the malicious activity and identify any additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Restore the system to a known good state by reinstalling the operating system and applications from trusted sources, ensuring all patches and updates are applied.
-- Implement enhanced logging policies to capture detailed process execution and network activity, aiding in future investigations.
-- Integrate security tools such as endpoint detection and response (EDR) solutions to monitor for similar threats and provide real-time alerts.
-- Educate development and operations teams on secure Git practices, emphasizing the importance of monitoring and controlling Git hook scripts.
-- Apply hardening measures by restricting write permissions to Git hook directories and implementing strict access controls to minimize the risk of unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kde_autostart_modification.toml b/rules/linux/persistence_kde_autostart_modification.toml
index 8dedd636a02..4fbc4c9c845 100644
--- a/rules/linux/persistence_kde_autostart_modification.toml
+++ b/rules/linux/persistence_kde_autostart_modification.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2021/01/06"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [transform]
 [[transform.osquery]]
@@ -81,7 +83,7 @@ Identifies the creation or modification of a K Desktop Environment (KDE) AutoSta
 execute upon each user logon. Adversaries may abuse this method for persistence.
 """
 from = "now-9m"
-index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*"]
+index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Persistence via KDE AutoStart Script or Desktop File Modification"
@@ -203,6 +205,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_kernel_driver_load.toml b/rules/linux/persistence_kernel_driver_load.toml
index d6ddf5426a1..97ba74fa43d 100644
--- a/rules/linux/persistence_kernel_driver_load.toml
+++ b/rules/linux/persistence_kernel_driver_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -56,49 +56,6 @@ query = '''
 driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and
 auditd.data.syscall in ("init_module", "finit_module")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kernel Driver Load
-
-Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers and other components. Adversaries exploit this by loading malicious modules, or rootkits, to gain stealthy control over systems. The detection rule monitors system calls related to module loading, identifying suspicious activity by tracking specific actions indicative of unauthorized kernel modifications.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event action is "loaded-kernel-module" and verify the syscall involved is either "init_module" or "finit_module" as these are indicative of module loading.
-- Identify the specific kernel module that was loaded by examining the associated metadata in the alert, such as the module name or path, if available.
-- Check the timestamp of the event to determine when the module was loaded and correlate this with other system activities or logs around the same time for additional context.
-- Investigate the user or process that initiated the module load by examining the user ID and process ID fields in the alert to determine if it aligns with expected behavior or known legitimate processes.
-- Use Osquery to list all currently loaded kernel modules and their details to identify any unfamiliar or suspicious modules. Example query: `SELECT name, size, refcount, srcversion FROM kernel_modules;`
-- Cross-reference the loaded module with known good or bad modules by consulting threat intelligence sources or internal documentation to assess its legitimacy.
-- Analyze system logs, such as syslog or dmesg, for any additional messages or errors related to the module load event that could provide further insights.
-- Investigate the system's audit logs for any preceding or subsequent suspicious activities that might be related to the module load, such as unauthorized access attempts or privilege escalation.
-- Check for any recent changes to the system's configuration or installed software that could explain the module load, ensuring these changes are authorized and documented.
-- If the module is determined to be suspicious, consider conducting a deeper forensic analysis of the system to uncover any potential rootkits or other malicious activities that may have been facilitated by the module load.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the loading of kernel modules, leading to false positives. Users can manage this by creating exceptions for known and trusted software update processes.
-- Certain hardware drivers, such as those for graphics cards or network adapters, may load kernel modules during normal operation. To handle these, users can whitelist specific drivers or hardware-related processes that are known to be safe.
-- System administrators performing routine maintenance or configuration changes might load kernel modules, which could be flagged as suspicious. Users should document and exclude these activities from monitoring when performed by authorized personnel.
-- Security software or monitoring tools that interact with the kernel might also load modules as part of their normal function. Users can create exceptions for these tools by verifying their legitimacy and adding them to an exclusion list.
-- Custom or in-house developed applications that require kernel module loading for functionality might be misidentified as threats. Users should ensure these applications are properly documented and excluded from detection rules if they are verified as safe.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Use forensic tools to capture a memory dump and disk image of the affected system for further analysis.
-- Investigate the loaded kernel module by checking its origin, signature, and any associated files or processes to determine if it is malicious.
-- Cross-reference the module's details with known threat intelligence databases to identify any known rootkits or malicious actors.
-- If a rootkit is confirmed, remove the malicious module using safe methods such as rebooting into a clean environment and using trusted tools to unload the module.
-- Restore the system from a known good backup if the integrity of the system cannot be assured after module removal.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
-- Implement enhanced logging policies to monitor for future unauthorized kernel module loads, including detailed audit logs of system calls and module activities.
-- Integrate with security information and event management (SIEM) systems to correlate module loading events with other suspicious activities across the network.
-- Apply system hardening measures such as disabling unnecessary kernel module loading, enforcing strict access controls, and regularly updating the system to patch vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_driver_load_by_non_root.toml b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
index adab039beab..216b6be53ed 100644
--- a/rules/linux/persistence_kernel_driver_load_by_non_root.toml
+++ b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ query = '''
 driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and
 auditd.data.syscall in ("init_module", "finit_module") and user.id != "0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kernel Driver Load by non-root User
-
-Kernel modules extend the functionality of the Linux kernel, often requiring root privileges to load. Adversaries exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies non-root users attempting to load kernel modules via specific system calls, signaling potential unauthorized access or privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the non-root user involved in the kernel module loading attempt, focusing on the `user.id` field to determine the user account.
-- Examine the `auditd.data.syscall` field to confirm which system call was used (`init_module` or `finit_module`) and gather context on the specific action taken.
-- Check the timestamp of the event to correlate it with other system activities or logs that might provide additional context or indicate a pattern of suspicious behavior.
-- Investigate the source of the kernel module by reviewing the module's file path and name, if available, to determine if it is a known or legitimate module.
-- Use Osquery to list all currently loaded kernel modules and their details to identify any unfamiliar or suspicious modules. Example query: `SELECT name, size, used_by FROM kernel_modules;`
-- Cross-reference the non-root user's recent activities by reviewing system logs, such as `/var/log/auth.log` or `/var/log/secure`, to identify any unauthorized access or privilege escalation attempts.
-- Analyze the user's command history, if available, to check for any commands related to module loading or system modification that might indicate malicious intent.
-- Investigate the user's group memberships and permissions to assess whether they have been granted elevated privileges that could facilitate unauthorized module loading.
-- Review any recent changes to user accounts or group memberships in system logs to identify potential privilege escalation or account compromise.
-- Check for any related alerts or anomalies in the security monitoring system that might indicate a broader attack campaign or coordinated activity involving the same user or system.
-
-### False positive analysis
-
-- Non-root users with legitimate administrative privileges may load kernel modules as part of routine system maintenance or software installations, leading to false positives. 
-- Development environments where non-root users are testing kernel modules can trigger alerts; consider excluding specific users or processes associated with development activities.
-- Automated scripts or configuration management tools running under non-root accounts might load modules for legitimate purposes; identify and whitelist these processes to reduce noise.
-- Some security or monitoring tools may operate under non-root accounts and load kernel modules as part of their functionality; verify and exclude these tools to prevent unnecessary alerts.
-- To manage false positives, implement exceptions by creating a list of trusted users or processes that are known to load kernel modules for legitimate reasons, and adjust the detection rule to exclude these from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the identity and privileges of the non-root user attempting to load the kernel module to assess if the action was legitimate or malicious.
-- Conduct a thorough investigation of the loaded kernel module to determine its origin and functionality, focusing on identifying any rootkit characteristics.
-- Utilize forensic tools to capture and analyze memory and disk images from the affected system to identify any additional malicious activities or artifacts.
-- Review system logs and audit trails to trace the sequence of events leading to the module loading, identifying any potential privilege escalation or exploitation attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor is part of a larger campaign.
-- Remove the malicious kernel module and any associated files or processes from the system, ensuring that all backdoors or persistence mechanisms are eradicated.
-- Restore the system to a known good state using verified backups, ensuring that all security patches and updates are applied to prevent future exploitation.
-- Implement enhanced logging and monitoring policies, such as enabling auditd with specific rules to track kernel module loading and other critical system activities.
-- Strengthen system hardening measures by enforcing the principle of least privilege, disabling unnecessary services, and regularly reviewing user access rights to minimize the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_object_file_creation.toml b/rules/linux/persistence_kernel_object_file_creation.toml
index 939bda0303f..4d95f4e8f37 100644
--- a/rules/linux/persistence_kernel_object_file_creation.toml
+++ b/rules/linux/persistence_kernel_object_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/19"
 
 [rule]
 author = ["Elastic"]
@@ -59,49 +59,6 @@ event.category:file and host.os.type:linux and event.type:creation and file.exte
   file.path:/var/tmp/mkinitramfs_* or process.executable:/snap/* or process.name:cpio
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kernel Object File Creation
-
-Kernel object files (.ko) are loadable modules that extend the functionality of the Linux kernel. Adversaries exploit these to deploy rootkits, granting them stealthy control over a system. The detection rule identifies suspicious .ko file creation, excluding benign paths like system updates, to flag potential threats aligned with persistence tactics, ensuring early detection of malicious kernel modifications.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a .ko file creation event, focusing on the `event.category:file`, `host.os.type:linux`, `event.type:creation`, and `file.extension:ko` fields.
-- Examine the file path of the .ko file to determine if it resides in a suspicious or unusual directory, excluding known benign paths like `/var/tmp/mkinitramfs_*`.
-- Investigate the process that created the .ko file by analyzing the `process.executable` and `process.name` fields to identify any unusual or unauthorized processes.
-- Check the file creation timestamp to correlate with any other suspicious activities or anomalies on the system around the same time.
-- Use Osquery to list all loaded kernel modules and identify any that are not part of the standard or expected set. Example query: `SELECT * FROM kernel_modules WHERE name = '<suspicious_module_name>';`
-- Cross-reference the .ko file's hash with known malware databases to check for any matches with known malicious kernel modules.
-- Investigate the user account under which the .ko file was created to determine if it has the necessary privileges and if the activity aligns with typical user behavior.
-- Review system logs for any additional context or anomalies around the time of the .ko file creation, such as login attempts, privilege escalations, or other file modifications.
-- Analyze network activity from the host around the time of the .ko file creation to identify any suspicious outbound connections or data exfiltration attempts.
-- Consult with system administrators or other relevant personnel to verify if the .ko file creation was part of a legitimate update or maintenance activity.
-
-### False positive analysis
-
-- System updates and kernel upgrades often involve the creation of legitimate .ko files, which can trigger false positives. Users can manage this by excluding paths associated with these updates, such as `/lib/modules/` or specific update processes.
-- Custom kernel module development and testing environments may also generate .ko files as part of normal operations. Developers should consider excluding directories or processes related to their development activities to prevent unnecessary alerts.
-- Some legitimate software installations or updates might temporarily create .ko files in non-standard locations. Users should monitor and identify these patterns, then create exceptions for known benign software to reduce false positives.
-- Automated backup or recovery processes might involve the creation of .ko files, especially if they involve system snapshots or similar operations. Identifying these processes and excluding them can help in minimizing false alerts.
-- Users should regularly review and update their exclusion lists to ensure they reflect the current environment and operational needs, thus maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the .ko file creation, examining recent system changes, user activity, and any unauthorized access.
-- Utilize forensic tools to analyze the .ko file for malicious code or rootkit characteristics, and determine the extent of the compromise.
-- Remove the malicious .ko file and any associated malware or unauthorized kernel modules from the system.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring that the backup is free from compromise.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed file creation events, process executions, and network activity for future investigations.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
-- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.
-- Review and update security policies and hardening measures, such as disabling unnecessary kernel module loading and enforcing strict access controls, to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_kworker_file_creation.toml b/rules/linux/persistence_kworker_file_creation.toml
index 9d2d16e7c15..ee97df97488 100644
--- a/rules/linux/persistence_kworker_file_creation.toml
+++ b/rules/linux/persistence_kworker_file_creation.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/10/26"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/07/18"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [transform]
 [[transform.osquery]]
@@ -52,7 +54,7 @@ to be done in kernel space, which might include tasks like handling interrupts,
 kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious File Creation via Kworker"
@@ -159,6 +161,8 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_linux_backdoor_user_creation.toml b/rules/linux/persistence_linux_backdoor_user_creation.toml
index ef29d7ff160..695b3a0a636 100644
--- a/rules/linux/persistence_linux_backdoor_user_creation.toml
+++ b/rules/linux/persistence_linux_backdoor_user_creation.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/03/07"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/09/23"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -36,7 +38,7 @@ Identifies the attempt to create a new backdoor user by setting the user's UID t
 0 to establish persistence on a system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Backdoor User Account Creation"
@@ -125,12 +127,15 @@ tags = [
     "Resources: Investigation Guide",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "usermod" and process.args : "-u" and process.args : "0" and process.args : "-o"
 '''
 
diff --git a/rules/linux/persistence_linux_shell_activity_via_web_server.toml b/rules/linux/persistence_linux_shell_activity_via_web_server.toml
index 42ea56ee044..dac07d562e2 100644
--- a/rules/linux/persistence_linux_shell_activity_via_web_server.toml
+++ b/rules/linux/persistence_linux_shell_activity_via_web_server.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/03/04"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/05/21"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -40,7 +42,7 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Remote Code Execution via Web Server"
@@ -139,13 +141,14 @@ tags = [
     "Use Case: Vulnerability",
     "Resources: Investigation Guide",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-event.action in ("exec", "exec_event") and process.parent.executable : (
+event.action in ("exec", "exec_event", "start") and process.parent.executable : (
   "/usr/sbin/nginx", "/usr/local/sbin/nginx",
   "/usr/sbin/apache", "/usr/local/sbin/apache",
   "/usr/sbin/apache2", "/usr/local/sbin/apache2",
diff --git a/rules/linux/persistence_linux_user_added_to_privileged_group.toml b/rules/linux/persistence_linux_user_added_to_privileged_group.toml
index da5d94f4353..dd15fcc73a7 100644
--- a/rules/linux/persistence_linux_user_added_to_privileged_group.toml
+++ b/rules/linux/persistence_linux_user_added_to_privileged_group.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/02/13"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/24"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -29,7 +31,7 @@ Identifies attempts to add a user to a privileged group. Attackers may add users
 establish persistence on a system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux User Added to Privileged Group"
@@ -117,18 +119,21 @@ tags = [
     "Resources: Investigation Guide",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.args in (
-  "root", "admin", "wheel", "staff", "sudo","disk", "video", "shadow", "lxc", "lxd"
-) and
-(
-  process.name in ("usermod", "adduser") or
-  (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members")) 
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+  process.args in (
+    "root", "admin", "wheel", "staff", "sudo","disk", "video", "shadow", "lxc", "lxd"
+  ) and
+  (
+    process.name in ("usermod", "adduser") or
+    (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members")) 
+  )
 '''
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_lkm_configuration_file_creation.toml b/rules/linux/persistence_lkm_configuration_file_creation.toml
index 64f58edf954..ba7808de531 100644
--- a/rules/linux/persistence_lkm_configuration_file_creation.toml
+++ b/rules/linux/persistence_lkm_configuration_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/17"
 
 [rule]
 author = ["Elastic"]
@@ -61,57 +61,6 @@ file.path like~ (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Loadable Kernel Module Configuration File Creation
-
-Loadable Kernel Modules (LKMs) allow dynamic loading of code into the Linux kernel, enhancing functionality without rebooting. Adversaries exploit this by creating or altering LKM configuration files to ensure malicious modules load at startup, achieving persistence. The detection rule identifies suspicious file creation or renaming in key directories, excluding benign processes, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process executable involved in the suspicious file creation or renaming event.
-- Verify the legitimacy of the process executable by checking its hash against known good hashes or using a threat intelligence database to identify any known malicious signatures.
-- Use Osquery to list all currently loaded kernel modules and check for any unfamiliar or suspicious modules:
-  ```sql
-  SELECT name, size, used_by FROM kernel_modules;
-  ```
-- Investigate the file path where the LKM configuration file was created or renamed to determine if it aligns with typical system behavior or if it appears out of place.
-- Examine the process tree to understand the parent process and any child processes associated with the suspicious executable, which may provide context on how the file creation was initiated.
-- Check system logs, such as `/var/log/syslog` or `/var/log/messages`, for any related entries around the time of the alert to gather additional context on the event.
-- Use Osquery to identify any recent changes to the system's module directories that might indicate tampering:
-  ```sql
-  SELECT path, size, atime, mtime, ctime FROM file WHERE path LIKE '/etc/modules%' OR path LIKE '/etc/modprobe.d/%';
-  ```
-- Investigate the user account under which the process was executed to determine if it has the necessary privileges to modify LKM configuration files and if the activity aligns with the user's typical behavior.
-- Cross-reference the alert with any other recent alerts or incidents involving the same host or process to identify potential patterns or correlations.
-- Consult with system administrators or the asset owner to verify if the file creation or modification was part of a legitimate change or update to the system.
-
-### False positive analysis
-
-- System package managers such as `dpkg`, `rpm`, `yum`, and `dnf` may create or modify LKM configuration files during routine updates or installations, which are benign activities. Users can handle these by ensuring these processes are included in the exclusion list of the detection rule.
-- Container management tools like `dockerd` and `podman` might also trigger false positives when managing containerized environments. Excluding these executables from the rule can prevent unnecessary alerts.
-- Automation and configuration management tools such as `puppet`, `chef-client`, and `ansible` may modify LKM configuration files as part of their normal operations. Users should verify these processes and add them to the exclusion list if they are part of legitimate activities.
-- Temporary files created by text editors (e.g., files with extensions like `.swp`, `.swpx`, `.swx`) during editing sessions can be mistakenly flagged. Excluding these file extensions can reduce false positives.
-- Processes running from specific directories like `/nix/store/*` or `/snap/*` may be part of legitimate software installations or updates. Users should review these paths and consider excluding them if they are known to be safe.
-- Scheduled tasks or cron jobs executed by processes like `crond` or `anacron` might modify LKM configuration files as part of system maintenance. Users should assess these activities and exclude them if they are verified as non-threatening.
-- Users can manage false positives by regularly reviewing and updating the exclusion list to reflect changes in their environment, ensuring that only verified benign processes and paths are excluded from the detection rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the malicious loadable kernel module.
-- Conduct a thorough investigation to identify the source of the LKM configuration file creation or modification, focusing on the process and user account involved.
-- Review system logs and security alerts to gather additional context and determine if other systems are affected.
-- Remove the malicious LKM and any associated configuration files from the system to eliminate persistence mechanisms.
-- Restore the system to a known good state using backups or system snapshots, ensuring that the restored state is free from compromise.
-- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed information on file creation and modification events, especially in critical directories.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on security best practices and the importance of monitoring for unauthorized changes to system configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_message_of_the_day_execution.toml b/rules/linux/persistence_message_of_the_day_execution.toml
index 5fbd4a45571..da6736576b3 100644
--- a/rules/linux/persistence_message_of_the_day_execution.toml
+++ b/rules/linux/persistence_message_of_the_day_execution.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/02/28"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/05/31"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +43,7 @@ a backdoor script or command. This rule detects the execution of potentially mal
 utility.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*"]
+index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Process Spawned from Message-of-the-Day (MOTD)"
@@ -142,42 +144,60 @@ tags = [
     "Data Source: Elastic Endgame",
     "Resources: Investigation Guide",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where event.type == "start" and host.os.type == "linux" and event.action : ("exec", "exec_event") and
-  process.parent.executable : "/etc/update-motd.d/*" and (
-  (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and (
-    (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*"))) or
-  (process.name : ("nc", "ncat", "netcat", "nc.openbsd") and process.args_count >= 3 and 
-    not process.args : ("-*z*", "-*l*")) or
-  (process.name : "python*" and process.args : "-c" and process.args : (
-     "*import*pty*spawn*", "*import*subprocess*call*"
-  )) or
-  (process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : (
-     "*exec*", "*system*"
-  )) or
-  (process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : (
-     "*TCPSocket.new*", "*TCPSocket.open*"
-  )) or
-  (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : (
-     "*io.popen*", "*os.execute*"
-  )) or
-  (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or 
-  (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or 
-  (process.name in ("openssl", "telnet")) or
-  (process.args : (
-    "./*", "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*", "/run/*", "/srv/*",
-    "/tmp/*", "/var/tmp/*", "/var/log/*", "/opt/*"
-    ) and process.args_count == 1
+process where event.type == "start" and host.os.type == "linux" and event.action : ("exec", "exec_event", "start") and
+  process.parent.executable : "/etc/update-motd.d/*" and
+  (
+    (
+      process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+      (
+        process.args : ("-i", "-l") or
+        (process.parent.name == "socat" and process.parent.args : "*exec*")
+      )
+    ) or
+    (
+      process.name : ("nc", "ncat", "netcat", "nc.openbsd") and process.args_count >= 3 and 
+      not process.args : ("-*z*", "-*l*")
+    ) or
+    (
+      process.name : "python*" and process.args : "-c" and process.args : (
+        "*import*pty*spawn*", "*import*subprocess*call*"
+      )
+    ) or
+    (
+      process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : (
+        "*exec*", "*system*"
+      )
+    ) or
+    (
+      process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : (
+        "*TCPSocket.new*", "*TCPSocket.open*"
+      )
+    ) or
+    (
+      process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : (
+        "*io.popen*", "*os.execute*"
+      )
+    ) or
+    (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or 
+    (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or 
+    (process.name in ("openssl", "telnet")) or
+    (
+      process.args : (
+        "./*", "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*", "/run/*", "/srv/*",
+        "/tmp/*", "/var/tmp/*", "/var/log/*", "/opt/*"
+      ) and process.args_count == 1
+    )
+  ) and 
+  not (
+    process.parent.args == "--force" or
+    process.args in ("/usr/games/lolcat", "/usr/bin/screenfetch") or
+    process.parent.name == "system-crash-notification"
   )
-) and 
-not (
-  process.parent.args == "--force" or
-  process.args in ("/usr/games/lolcat", "/usr/bin/screenfetch") or
-  process.parent.name == "system-crash-notification"
-)
 '''
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation.toml b/rules/linux/persistence_pluggable_authentication_module_creation.toml
index 606ff3d6dca..fd3e0bb6fd6 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/16"
 
 [rule]
 author = ["Elastic"]
@@ -71,50 +71,6 @@ process.executable != null and (
   (process.name == "perl" and file.name like~ "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation or Modification of Pluggable Authentication Module or Configuration
-
-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 key PAM directories, excluding benign processes, to flag unauthorized changes indicative of potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process executable involved in the creation or modification event. Pay special attention to the `file.path` and `process.executable` fields.
-- Verify the legitimacy of the process executable by checking its hash against known good hashes or using a threat intelligence platform to determine if it is associated with known malicious activity.
-- Use Osquery to list all PAM modules and their metadata to identify any recent changes or anomalies. Example query: `SELECT * FROM file WHERE path LIKE '/lib/security/%' OR path LIKE '/etc/pam.d/%';`
-- Investigate the user account associated with the process that triggered the alert to determine if it has been compromised or is being used maliciously.
-- Check the system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any suspicious authentication attempts or errors around the time of the alert.
-- Examine the process tree to understand the parent and child processes of the executable involved in the alert. This can help identify if the process was spawned by a legitimate service or a malicious script.
-- Review recent system changes or package installations that might have legitimately modified PAM configurations, using package management logs or history commands.
-- Analyze network activity from the host to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
-- Cross-reference the alert with other security events or alerts from the same host to identify patterns or correlations that might indicate a broader attack campaign.
-- Consult with system administrators or application owners to verify if the changes were authorized or part of a scheduled update or maintenance activity.
-
-### False positive analysis
-
-- Routine system updates or package installations can trigger this rule, as legitimate package managers like `dpkg`, `rpm`, `yum`, and `apt` may modify PAM-related files. Users can handle these by ensuring that the processes associated with these package managers are included in the exclusion list.
-- Automated system management tools such as Puppet, Chef, or Ansible might also modify PAM configurations as part of their normal operations. Users should verify these activities and add the relevant process executables to the exclusion list if deemed non-threatening.
-- Temporary files created during legitimate software installations or updates, such as those with extensions like `swp`, `swpx`, or `dpkg-remove`, can be mistaken for suspicious activity. Users can exclude these extensions to reduce false positives.
-- Certain system maintenance scripts or tools, like `sed` or `perl`, may create temporary files that match the rule's criteria. Users should review these activities and consider excluding specific file names or patterns associated with these tools.
-- Snap package installations or updates may involve temporary paths like `/tmp/snap.rootfs_*`, which could be flagged by the rule. Users can exclude these paths if they are confident in the benign nature of the activities.
-- In environments using the Nix package manager, paths under `/nix/store/*` may be involved in legitimate PAM file modifications. Users should assess these activities and exclude the relevant paths if they are part of routine operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify any unauthorized PAM module or configuration changes, using forensic tools to analyze file integrity and system logs.
-- Review recent user account activity and authentication logs to identify any suspicious login attempts or credential harvesting.
-- Restore any modified or unauthorized PAM files from a known good backup to ensure system integrity.
-- Update all system and application software to the latest versions to patch any known vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed authentication and file modification events, ensuring logs are stored securely and monitored regularly.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
-- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting access to PAM directories, enforcing strong authentication policies, and conducting regular security audits."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
index 637b0272c95..be09d78657f 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/12/16"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +17,7 @@ false_positives = [
     "Trusted system module updates or allowed Pluggable Authentication Module (PAM) daemon configuration changes.",
 ]
 from = "now-9m"
-index = ["logs-endpoint.events.file*"]
+index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Pluggable Authentication Module (PAM) Creation in Unusual Directory"
@@ -35,6 +37,8 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -54,52 +58,6 @@ file where host.os.type == "linux" and event.type == "creation" and file.name li
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 (PAM) Creation in Unusual Directory
-
-Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and name of the PAM shared object file created, focusing on the `file.name` and `file.path` fields.
-- Verify the process responsible for creating the file by examining the `process.name` field to determine if it matches any known benign processes or if it appears suspicious.
-- Check the timestamp of the file creation event to correlate it with other system activities or anomalies that occurred around the same time.
-- Investigate the parent process of the file creation event to understand the context and origin of the action, using process lineage information if available.
-- Use Osquery to list all PAM modules on the system and their locations to identify any other unusual or unauthorized modules:
-  ```sql
-  SELECT * FROM file WHERE path LIKE '/%/pam_*.so';
-  ```
-- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication-related anomalies or errors that coincide with the file creation event.
-- Check for any recent user account changes or privilege escalations that might indicate unauthorized access or manipulation.
-- Investigate the network activity of the host around the time of the alert to identify any suspicious connections or data exfiltration attempts.
-- Review the system's history of software installations and updates to rule out legitimate software that might have created the PAM module.
-- Assess the integrity of other critical system files and configurations to ensure no further unauthorized modifications have been made.
-
-### False positive analysis
-
-- **Development and Testing Environments**: In environments where developers or system administrators are testing PAM modules, files may be created in non-standard directories temporarily. Users can handle these by excluding specific directories used for development and testing from the detection rule.
-- **Containerized Applications**: Applications running in containers might create PAM modules in unusual directories as part of their normal operation. Users can exclude paths related to container environments, such as those under `/var/lib/containerd` or `/home/*/.local/share/containers`, to reduce false positives.
-- **Package Management and System Updates**: Some package managers or system update processes might temporarily create PAM modules in non-standard directories before moving them to the correct location. Users can exclude processes like `pacman` or paths related to package management, such as `/nix/store/*`, to prevent these from triggering alerts.
-- **Custom Security Solutions**: Organizations with custom security solutions might have legitimate PAM modules in non-standard directories. Users should identify and exclude these specific paths or processes to avoid false positives.
-- **Temporary File Creation**: Some legitimate processes might create temporary PAM files in directories like `/tmp` or `/var/tmp` during their operation. Users can exclude these directories or specific processes known to create temporary files to minimize false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the malicious PAM module creation, including reviewing recent user activity and process logs.
-- Remove any unauthorized PAM modules found in unusual directories and verify the integrity of legitimate PAM modules in standard directories.
-- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed file creation events and process activities, ensuring that logs are stored securely and monitored regularly.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
-- Harden the system by implementing least privilege access controls, disabling unused services, and regularly auditing PAM configurations and modules."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_source_download.toml b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
index 674787295d3..c80244fef6e 100644
--- a/rules/linux/persistence_pluggable_authentication_module_source_download.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/16"
 
 [rule]
 author = ["Elastic"]
@@ -44,52 +44,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name in ("curl", "wget") and
 process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 (PAM) Source Download
-
-Pluggable Authentication Modules (PAM) are integral to Linux systems, providing a flexible mechanism for authenticating users. Adversaries may exploit PAM by downloading its source code to modify authentication processes, potentially creating backdoors. The detection rule identifies suspicious downloads of PAM source files using tools like `curl` or `wget`, signaling potential attempts to tamper with authentication mechanisms.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `curl` or `wget` in the `process.name` field and verify the URL pattern in `process.args` to ensure it matches the known PAM source download URL.
-- Check the `host.os.type` field to confirm the operating system is Linux, as this rule is specific to Linux environments.
-- Investigate the `event.type` and `event.action` fields to ensure the process was indeed started and executed, indicating an actual download attempt.
-- Examine the user account associated with the process to determine if the activity aligns with expected behavior or if it is potentially malicious.
-- Use Osquery to list all PAM modules currently installed on the system to identify any unauthorized or suspicious modules:
-  ```sql
-  SELECT * FROM pam_modules;
-  ```
-- Analyze the network logs to identify any other suspicious outbound connections from the host around the time of the alert.
-- Review the system's process execution history to identify any subsequent actions taken by the same user or process that downloaded the PAM source.
-- Check for any recent changes to PAM configuration files, such as `/etc/pam.d/`, to detect unauthorized modifications.
-- Investigate the file system for any downloaded PAM source files or extracted contents, focusing on directories typically used for temporary storage or user downloads.
-- Correlate this event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- System administrators or developers may legitimately download PAM source files for testing, development, or educational purposes, which could trigger the detection rule. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform these activities regularly.
-- Automated scripts or configuration management tools that update or install software packages might download PAM source files as part of their routine operations. Users can handle these by excluding specific processes or scripts from triggering the rule.
-- Security researchers or auditors conducting vulnerability assessments might download PAM source files to analyze potential security issues. Organizations can whitelist these activities by identifying and excluding the researchers' user accounts or IP addresses.
-- Some Linux distributions or custom setups might include scripts that download PAM source files for building or updating packages. Users should identify these scripts and add them to an exception list to prevent false positives.
-- In educational environments, students might download PAM source files as part of their coursework. Institutions can manage this by excluding specific user groups or network segments associated with educational activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the download of the PAM source code and identify any modifications made to the authentication modules.
-- Review system logs and process execution history to trace the origin of the suspicious activity and identify any other potentially compromised systems.
-- Remove any unauthorized or malicious PAM modules and restore the original, verified versions from trusted sources.
-- Change all passwords and authentication credentials that may have been exposed or compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for PAM-related activities, including downloads and modifications, to detect future attempts at unauthorized access.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities related to PAM.
-- Restore the system to its operational state by applying security patches, updating software, and ensuring all configurations adhere to security best practices.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
index 9f9e90302a0..20152cf97b1 100644
--- a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
+++ b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/06/03"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ environment. Adversaries may create these scripts to execute malicious code at s
 persistence onto the system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*"]
+index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Executable Bit Set for Potential Persistence Script"
@@ -58,12 +60,13 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.args : (
   // Misc.
   "/etc/rc.local", "/etc/rc.common", "/etc/rc.d/rc.local", "/etc/init.d/*", "/etc/update-motd.d/*",
@@ -82,49 +85,6 @@ process.args : (
   (process.name == "install" and process.args : "-m*" and process.args : ("7*", "5*", "3*", "1*"))
 ) and not process.parent.executable : "/var/lib/dpkg/*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Executable Bit Set for Potential Persistence Script
-
-In Linux environments, scripts can be set to execute automatically by setting the executable bit, a feature often exploited by adversaries to maintain persistence. Attackers may place scripts in directories typically used for startup processes, ensuring their code runs at boot or scheduled intervals. The detection rule identifies suspicious use of commands like `chmod` or `install` to set executable permissions on scripts in these sensitive directories, flagging potential persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific script path and the command used to set the executable bit, focusing on the `process.args` field to understand the exact operation performed.
-- Check the `process.parent.executable` field to determine the parent process that initiated the command, which can provide context on whether the action was part of a legitimate process or potentially malicious.
-- Use Osquery to list all files in the directory where the script is located to identify any other suspicious files or scripts. Example query: `SELECT * FROM file WHERE directory = '/path/to/suspicious/directory';`
-- Investigate the user account associated with the process by examining the `process.user.name` field to determine if the account has a history of suspicious activity or if it has been compromised.
-- Analyze the script content by accessing the file directly to understand its purpose and whether it contains any malicious code or commands.
-- Cross-reference the script's hash with known malware databases to check if it matches any known malicious scripts.
-- Review system logs around the time of the alert to identify any other unusual activities or related events that could provide additional context.
-- Check for any recent changes in the system's startup configuration files or directories, as these could indicate attempts to establish persistence.
-- Use Osquery to query the system's cron jobs and scheduled tasks to identify any unauthorized or suspicious entries. Example query: `SELECT * FROM crontab WHERE command LIKE '%/path/to/suspicious/script%';`
-- Investigate network connections initiated by the host around the time of the alert to identify any potential communication with known malicious IP addresses or domains.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use `chmod` or `install` commands to set executable permissions on scripts for legitimate purposes, such as system maintenance or software updates. These actions can trigger alerts if they occur in directories monitored by the rule.
-- Automated software updates: Some software packages may automatically update themselves by modifying scripts in startup directories, which can be mistaken for persistence attempts.
-- Custom user scripts: Users may create personal scripts in their home directories for convenience, which could be flagged if they are set to execute at startup.
-- To manage these false positives, users can create exceptions for known benign processes or directories by updating the detection rule to exclude specific paths or parent processes that are verified as non-threatening.
-- Regularly review and update the list of exceptions to ensure that legitimate activities are not inadvertently flagged while maintaining the integrity of the detection system.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Conduct a thorough investigation to identify the script's origin, purpose, and any associated processes or files. Use forensic tools to analyze the script and its execution history.
-- Review system logs and security alerts to determine if there are any other indicators of compromise or related activities on the system.
-- Remove the malicious script and any associated files or processes. Ensure that the executable bit is removed from any unauthorized scripts.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring that the backup is free from any malicious modifications.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a larger attack campaign.
-- Implement enhanced logging and monitoring policies to capture detailed information on file permission changes and script executions, aiding in future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
-- Apply system hardening measures, such as restricting write permissions to sensitive directories and using access control lists (ACLs) to limit script execution.
-- Educate users and administrators on the risks of unauthorized script execution and the importance of maintaining secure configurations and practices."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_process_capability_set_via_setcap.toml b/rules/linux/persistence_process_capability_set_via_setcap.toml
index 91bb8998ea6..b7312ca0f94 100644
--- a/rules/linux/persistence_process_capability_set_via_setcap.toml
+++ b/rules/linux/persistence_process_capability_set_via_setcap.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/06/03"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ by attackers to establish persistence by creating a backdoor, or escalate privil
 system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*"]
+index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Process Capability Set via setcap Utility"
@@ -53,64 +55,19 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Endgame",
-    "Data Source: Elastic Defend"
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.name == "setcap" and not (
   process.parent.executable == null or
   process.parent.executable : ("/var/lib/dpkg/*", "/var/lib/docker/*", "/tmp/newroot/*", "/var/tmp/newroot/*") or 
   process.parent.name in ("jem", "vzctl")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Capability Set via setcap Utility
-
-The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit `setcap` to maintain persistence or escalate privileges by misconfiguring binaries. The detection rule identifies suspicious `setcap` usage by monitoring process execution, excluding benign parent processes, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "setcap" and the event type is "start" with actions "exec" or "exec_event".
-- Verify the parent process executable path and name to ensure it is not in the excluded list (e.g., "/var/lib/dpkg/*", "/var/lib/docker/*", "/tmp/newroot/*", "/var/tmp/newroot/*", "jem", "vzctl").
-- Check the user context under which the "setcap" command was executed to determine if it aligns with expected administrative activities.
-- Investigate the specific capabilities that were set by the "setcap" command to assess if they are necessary and appropriate for the binary.
-- Use Osquery to list all files with capabilities set on the system to identify any other potentially suspicious binaries:
-  ```sql
-  SELECT path, capabilities FROM file WHERE capabilities IS NOT NULL;
-  ```
-- Examine the command-line arguments used with "setcap" to understand the intent and scope of the capability changes.
-- Cross-reference the timestamp of the "setcap" execution with other system logs to identify any correlated suspicious activities.
-- Investigate the history of the binary on which capabilities were set to determine if it has been recently modified or replaced.
-- Review user activity logs around the time of the "setcap" execution to identify any anomalous behavior or unauthorized access.
-- Assess the system for any signs of persistence mechanisms or privilege escalation attempts that may have been established using the modified binary.
-
-### False positive analysis
-
-- Known false positives for the Process Capability Set via setcap Utility rule often arise from legitimate administrative tasks where system administrators use `setcap` to configure capabilities for system binaries or custom applications. These actions are typically benign and part of routine system maintenance.
-- Another source of false positives can be automated scripts or configuration management tools that use `setcap` as part of their deployment or configuration processes. These tools might run regularly and trigger the detection rule.
-- To manage these false positives, users can create exceptions for specific parent processes or paths that are known to be safe. For instance, if a particular script or tool frequently uses `setcap` and is verified to be non-malicious, its parent process name or executable path can be added to the exclusion list.
-- Users should regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity. This involves monitoring for any changes in legitimate processes that use `setcap` and adjusting the rule accordingly.
-- It's important to maintain a balance between reducing false positives and ensuring that potential threats are not overlooked. Regular audits and reviews of the exceptions can help maintain this balance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on any binaries with altered capabilities and reviewing recent `setcap` command executions.
-- Remove any unauthorized capabilities set on binaries by using the `setcap` command to reset them to their default state.
-- Review and update user permissions and access controls to ensure that only authorized personnel can modify capabilities on executables.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging for process execution and `setcap` usage to improve detection of similar activities in the future.
-- Integrate security information and event management (SIEM) solutions to correlate events and provide better visibility into potential threats.
-- Restore the system to its operational state by verifying the integrity of critical system files and reinstalling any compromised software from trusted sources.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface.
-- Educate users and administrators on the risks associated with misconfigured capabilities and the importance of maintaining secure configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_rc_local_error_via_syslog.toml b/rules/linux/persistence_rc_local_error_via_syslog.toml
index a449c6a256f..6a62b00b786 100644
--- a/rules/linux/persistence_rc_local_error_via_syslog.toml
+++ b/rules/linux/persistence_rc_local_error_via_syslog.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -56,47 +56,6 @@ query = '''
 host.os.type:linux and event.dataset:system.syslog and process.name:rc.local and
 message:("Connection refused" or "No such file or directory" or "command not found")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious rc.local Error Message
-
-The rc.local script is crucial in Linux systems, executing commands at boot. Adversaries may exploit this by inserting malicious scripts to gain persistence. The detection rule monitors syslog for specific error messages linked to rc.local, such as "Connection refused," indicating potential tampering. This helps identify unauthorized modifications, aligning with MITRE ATT&CK's persistence tactics.
-
-### Possible investigation steps
-
-- Review the syslog entries around the time of the alert to gather more context about the suspicious error message and identify any other related log entries.
-- Verify the integrity of the rc.local file by comparing its current state with a known good backup or using a file integrity monitoring tool to check for unauthorized changes.
-- Use Osquery to list the current contents of the rc.local file with the query: `SELECT * FROM file WHERE path='/etc/rc.local';` to identify any suspicious or unexpected entries.
-- Investigate the process tree to identify any parent or child processes related to rc.local using the query fields `process.name:rc.local` and `host.os.type:linux` to trace the execution flow.
-- Check for recent modifications to the rc.local file by examining the file's metadata, such as the last modified timestamp, using `ls -l /etc/rc.local` or an equivalent command.
-- Search for any recent user account activity or privilege escalations around the time of the alert that could indicate unauthorized access or changes to the rc.local file.
-- Analyze network logs for any unusual outbound connections or failed connection attempts that coincide with the "Connection refused" error message.
-- Review the system's boot logs to identify any anomalies or errors during the startup process that could be related to the rc.local script execution.
-- Investigate other system logs for any additional error messages like "No such file or directory" or "command not found" that might provide further context on the issue.
-- Correlate the findings with known MITRE ATT&CK techniques, specifically focusing on persistence tactics, to determine if the activity aligns with known adversary behaviors.
-
-### False positive analysis
-
-- Routine administrative tasks or legitimate software updates may trigger error messages like "No such file or directory" if certain expected files are temporarily unavailable during the update process. Users can handle these by creating exceptions for known maintenance windows or specific update processes.
-- Custom scripts or applications that are intentionally executed at boot but occasionally fail due to misconfigurations might generate "command not found" errors. Users should review these scripts and, if deemed non-threatening, exclude them from triggering alerts by specifying the script names or paths in the exception list.
-- Network-related services that are not yet fully initialized during the boot process might cause "Connection refused" errors. Users can mitigate these false positives by adjusting the timing of service startups or excluding specific network services from the rule if they are known to cause such errors without security implications.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of malicious activity.
-- Conduct a thorough investigation of the rc.local file to identify any unauthorized modifications or suspicious entries.
-- Review system logs, particularly syslog, to trace the origin of the suspicious activity and identify any other affected systems or files.
-- Restore the rc.local file from a known good backup if available, ensuring that it is free from any unauthorized changes.
-- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could have been exploited.
-- Implement strict access controls and permissions for critical system files like rc.local to prevent unauthorized modifications.
-- Enhance logging policies to ensure comprehensive monitoring of system changes and potential security incidents, integrating with SIEM solutions for real-time alerts.
-- Conduct a security audit of the system to identify and address any other potential security weaknesses or misconfigurations.
-- Escalate the incident to the security operations team or relevant authorities if the investigation reveals a broader threat or compliance breach.
-- Educate and train staff on recognizing and responding to security incidents, emphasizing the importance of maintaining system integrity and vigilance against persistence tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_rc_local_service_already_running.toml b/rules/linux/persistence_rc_local_service_already_running.toml
index b9a69a22a4f..0027fc21226 100644
--- a/rules/linux/persistence_rc_local_service_already_running.toml
+++ b/rules/linux/persistence_rc_local_service_already_running.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -68,49 +68,6 @@ query = '''
 process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and 
 process.parent.args == "/etc/rc.local" and process.parent.args == "start"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Execution of rc.local Script
-
-The `/etc/rc.local` script is a legacy Linux initialization script executed at the end of the boot process. While not enabled by default, attackers can exploit it to run malicious commands persistently at startup. The detection rule identifies potential misuse by monitoring for the `already_running` event action linked to `rc-local.service`, indicating the script's execution, thus alerting to possible unauthorized activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `already_running` event action associated with the `rc-local.service` systemd service, indicating potential execution of the `/etc/rc.local` script.
-- Verify the system's configuration to determine if the `/etc/rc.local` script is enabled and check for any recent modifications to the file by examining its last modified timestamp.
-- Use Osquery to list the contents of the `/etc/rc.local` file to identify any suspicious or unauthorized commands or scripts. Example query: `SELECT * FROM file WHERE path = '/etc/rc.local';`
-- Investigate the parent process details captured in the alert, specifically focusing on `process.parent.args` to understand the context in which the `/etc/rc.local` script was executed.
-- Check system logs, such as `/var/log/syslog` or `/var/log/messages`, for any entries around the time of the alert that might provide additional context or indicate other suspicious activities.
-- Examine the system's boot logs, such as `journalctl -b`, to identify any anomalies or errors during the boot process that could be related to the execution of the `/etc/rc.local` script.
-- Investigate user accounts and permissions to determine if unauthorized users have access to modify or execute the `/etc/rc.local` script.
-- Review recent changes to system services and startup scripts to identify any unauthorized modifications that could indicate persistence mechanisms.
-- Use Osquery to check for other persistence mechanisms on the system, such as cron jobs or other startup scripts, that might be used in conjunction with the `/etc/rc.local` script. Example query: `SELECT * FROM crontab;`
-- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise that might suggest a broader attack campaign.
-
-### False positive analysis
-
-- The execution of legitimate administrative scripts or maintenance tasks via `/etc/rc.local` can trigger false positives. System administrators may use this script for benign purposes, such as configuring network settings or starting essential services at boot.
-- Some Linux distributions or custom configurations might still rely on `/etc/rc.local` for legitimate startup processes, leading to alerts that are not indicative of malicious activity.
-- To manage these false positives, users can create exceptions for known and verified scripts or commands within `/etc/rc.local` by specifying them in the detection rule's exclusion list.
-- Regularly review and update the exclusion list to ensure that only trusted and necessary scripts are allowed, minimizing the risk of overlooking potential threats.
-- Consider implementing additional monitoring or logging for `/etc/rc.local` modifications to quickly identify unauthorized changes that could indicate malicious intent.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious scripts.
-- Conduct a thorough investigation to identify any unauthorized changes to the `/etc/rc.local` script and review the script's contents for malicious commands.
-- Check system logs and use forensic tools to trace the origin of the unauthorized changes and identify any other compromised systems.
-- Remove any malicious entries from the `/etc/rc.local` script and restore it to its default state if necessary.
-- Apply patches and updates to the operating system and installed software to mitigate known vulnerabilities that could have been exploited.
-- Implement strict access controls and permissions for critical system files, including `/etc/rc.local`, to prevent unauthorized modifications.
-- Enhance logging and monitoring by enabling detailed audit logs for system changes and integrating with a centralized logging solution for real-time alerts.
-- Consider deploying additional security tools, such as host-based intrusion detection systems (HIDS), to detect and prevent similar threats in the future.
-- Escalate the incident to the security team or relevant authorities if the investigation reveals a broader compromise or if sensitive data has been accessed.
-- Educate users and administrators on security best practices and the importance of monitoring for unusual system behavior to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
index 317ee7db8ad..ae85b369470 100644
--- a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -54,49 +54,6 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:rpm and
 process.args:("-i" or "--install")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 RPM Package Installed by Unusual Parent Process
-
-RPM is a crucial package management tool in Linux systems like Red Hat and CentOS, facilitating software installation and updates. Adversaries may exploit RPM by installing backdoored or malicious packages to gain persistence or initial access. The detection rule identifies anomalies by flagging RPM installations initiated by atypical parent processes, signaling potential unauthorized activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and timestamp of the RPM installation event.
-- Examine the parent process of the RPM installation using the `process.parent.name` and `process.parent.pid` fields to determine if it is indeed unusual or suspicious.
-- Check the command-line arguments used during the RPM installation by reviewing the `process.args` field to understand what package was being installed.
-- Investigate the user account associated with the RPM installation event using the `user.name` field to determine if the action was authorized or expected.
-- Use Osquery to list all RPM packages installed on the host and identify any recent additions or modifications. Example query: `SELECT name, version, release, install_time FROM rpm_packages WHERE install_time > strftime('%s', '2023-10-01');`
-- Cross-reference the installed package name and version with known repositories or package signatures to verify its legitimacy.
-- Analyze the network activity around the time of the RPM installation to identify any unusual outbound or inbound connections that could indicate data exfiltration or command-and-control activity.
-- Review system logs for any other suspicious activities or errors around the time of the RPM installation to gather additional context.
-- Check for any recent privilege escalation events on the host that could have allowed an adversary to perform the RPM installation.
-- Consult threat intelligence sources to determine if the package or the parent process is associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- System administrators or automated scripts may frequently install or update RPM packages as part of routine maintenance, which could trigger the rule if these actions are initiated by non-standard parent processes like custom scripts or management tools.
-- Development environments often use containerization or virtualization tools that might execute RPM installations through atypical parent processes, leading to false positives.
-- Security or monitoring tools that perform regular checks or updates on system packages might also appear as unusual parent processes when executing RPM commands.
-- To manage these false positives, users can create exceptions for known benign parent processes by adding them to an allowlist, ensuring that routine administrative tasks or automated processes do not trigger alerts.
-- Regularly review and update the list of excluded parent processes to adapt to changes in system management practices or toolsets, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the parent process that initiated the RPM installation by reviewing process logs and correlating with known benign activities.
-- Conduct a thorough investigation to identify any malicious RPM packages installed, using file integrity monitoring and package verification tools.
-- Remove any identified malicious or unauthorized RPM packages and replace them with verified, clean versions from trusted repositories.
-- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if the threat actor's identity and intent are unclear.
-- Implement enhanced logging policies to capture detailed process execution data, including parent-child process relationships, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all software is up-to-date.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_setuid_setgid_capability_set.toml b/rules/linux/persistence_setuid_setgid_capability_set.toml
index 100c5dd7fe8..bc082eec7d3 100644
--- a/rules/linux/persistence_setuid_setgid_capability_set.toml
+++ b/rules/linux/persistence_setuid_setgid_capability_set.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/09/05"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/08"
 
 [transform]
 [[transform.osquery]]
@@ -39,7 +41,7 @@ file owner or group. Threat actors can exploit these attributes to achieve persi
 allowing them to maintain control over a compromised system with elevated permissions.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Setcap setuid/setgid Capability Set"
@@ -138,15 +140,18 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
-process.name == "setcap" and process.args : "cap_set?id+ep" and not (
-  process.parent.name in ("jem", "vzctl") or
-  process.args like "/usr/bin/new?idmap"
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
+  process.name == "setcap" and process.args : "cap_set?id+ep" and not (
+    process.parent.name in ("jem", "vzctl") or
+    process.args like "/usr/bin/new?idmap"
+  )
 '''
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_shadow_file_modification.toml b/rules/linux/persistence_shadow_file_modification.toml
index a8389910b6c..ae90763ce34 100644
--- a/rules/linux/persistence_shadow_file_modification.toml
+++ b/rules/linux/persistence_shadow_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -60,49 +60,6 @@ query = '''
 file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and
 file.path == "/etc/shadow" and file.Ext.original.path != null
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Shadow File Modification
-
-The shadow file in Linux systems securely stores hashed user passwords, crucial for system authentication. Adversaries may exploit this by altering the file to add users or change passwords, ensuring persistent access. The detection rule identifies suspicious modifications by monitoring changes and renames of the shadow file, signaling potential unauthorized account manipulation activities.
-
-### Possible investigation steps
-
-- Verify the alert details, including the timestamp and the host where the modification was detected, to understand the context of the event.
-- Check the user account associated with the event to determine if it is a legitimate system administrator or a potential threat actor.
-- Review recent login activity on the affected host to identify any unusual or unauthorized access attempts around the time of the shadow file modification.
-- Use Osquery to list all users on the system and check for any newly added or suspicious accounts. Example query: `SELECT * FROM users WHERE uid >= 1000;`
-- Investigate the process tree to identify any processes that were running at the time of the modification, which might indicate the tool or method used for the change.
-- Examine the system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any entries that correlate with the time of the shadow file modification.
-- Check for any recent changes to the `/etc/passwd` file, as modifications here might accompany changes to the shadow file.
-- Review the file integrity monitoring logs to see if there are any other unauthorized changes to critical system files.
-- Investigate any network connections from the host around the time of the event to identify potential command and control activity.
-- Correlate the event with other security alerts or incidents in the environment to determine if this is part of a larger attack campaign.
-
-### False positive analysis
-
-- Routine system updates or administrative tasks may trigger legitimate changes to the shadow file, such as when a system administrator updates user passwords or adds new users as part of regular maintenance.
-- Automated scripts or configuration management tools like Ansible, Puppet, or Chef that manage user accounts and passwords can also cause expected modifications to the shadow file.
-- To manage these false positives, users can create exceptions for known administrative activities or trusted scripts by correlating the changes with scheduled maintenance windows or specific user actions.
-- Implementing a whitelist of trusted processes or users that are allowed to modify the shadow file can help reduce noise from expected changes.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the integrity of the shadow file by comparing it with a known good backup, if available, to identify unauthorized changes.
-- Conduct a thorough investigation to identify any unauthorized user accounts or password changes and remove or reset them as necessary.
-- Review system logs and security alerts to trace the source of the modification and determine if other systems may be compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Restore the shadow file from a secure backup if unauthorized changes are confirmed and ensure all legitimate user accounts are intact.
-- Implement enhanced logging and monitoring for critical system files, including the shadow file, to detect future unauthorized modifications.
-- Integrate with security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Apply system hardening measures, such as enforcing strong password policies and disabling unnecessary services, to reduce the attack surface.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans and procedures accordingly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_shell_configuration_modification.toml b/rules/linux/persistence_shell_configuration_modification.toml
index 07212e3a970..95de3e6a32b 100644
--- a/rules/linux/persistence_shell_configuration_modification.toml
+++ b/rules/linux/persistence_shell_configuration_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -98,51 +98,6 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Shell Configuration Creation or Modification
-
-Shell configuration files in Unix systems are crucial for setting up user environments, including environment variables and command aliases. Adversaries exploit these files to execute malicious scripts and maintain persistence. The detection rule identifies suspicious creation or modification of these files, excluding legitimate processes and temporary files, to flag potential unauthorized changes indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific shell configuration file that was created or modified, using the `file.path` field from the query.
-- Check the `event.action` field to determine whether the file was newly created or renamed, which can provide context on the nature of the change.
-- Investigate the `process.executable` field to identify the process responsible for the file modification, ensuring it is not part of the excluded legitimate processes.
-- Examine the `process.name` field to gather more information about the process that triggered the alert, especially if it is not part of the known exclusions.
-- Use Osquery to list recent modifications to shell configuration files with a query like: `SELECT path, mtime FROM file WHERE path IN ('/etc/profile', '/etc/bash.bashrc', '/home/*/.bashrc', '/root/.bashrc') ORDER BY mtime DESC LIMIT 10;` to verify the alert and gather additional context.
-- Cross-reference the `process.executable` and `process.name` with known malicious binaries or scripts to assess potential threats.
-- Check the `file.extension` and `file.Ext.original.extension` fields to ensure the file is not a temporary or transitional file, which might be benign.
-- Investigate the user account associated with the file modification to determine if the activity aligns with expected behavior for that user.
-- Review system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader compromise.
-- Analyze the contents of the modified shell configuration file to identify any unauthorized or suspicious entries, such as unexpected scripts or commands that could indicate persistence mechanisms.
-
-### False positive analysis
-
-- **Package Management Tools**: Actions by package managers like `dpkg`, `rpm`, `yum`, and `apt` can trigger the rule when they update or install software, as they may modify shell configuration files. Users can handle these by excluding the executables of these package managers from the rule.
-- **Container and Virtualization Software**: Tools such as `dockerd`, `podman`, and `snapd` may modify shell configurations during container or virtual environment setups. Excluding these specific executables can prevent false positives.
-- **User Account Management**: Commands like `adduser` and `useradd` might modify shell configuration files when creating new user accounts. Excluding these processes can help reduce false alerts.
-- **System Maintenance Scripts**: Automated scripts or system maintenance tasks, such as those run by `cron` or `systemd`, might alter shell configurations. Users can exclude these processes or specific script names to avoid false positives.
-- **Text Editors and Temporary Files**: Editors like `vim` create temporary files (e.g., with extensions like `.swp`) that might be flagged. Excluding these file extensions can prevent unnecessary alerts.
-- **Development and Scripting Tools**: Tools like `perl` and `sed` might be used in scripts that modify shell configurations. Users can exclude these processes when they are known to be part of legitimate scripts.
-- **Custom Exclusions**: Users can create custom exclusions for specific paths or processes that are known to be safe in their environment, ensuring that legitimate activities do not trigger false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of malicious activity.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on recent changes to shell configuration files and correlating with known indicators of compromise related to the Kaiji malware family.
-- Review and analyze logs from the system and any connected systems to trace the origin of the unauthorized changes and identify any additional compromised systems.
-- Remove any unauthorized or malicious entries from the shell configuration files and restore them to their last known good state using backups if available.
-- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed information on file modifications and process executions, ensuring that future unauthorized changes are detected promptly.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to provide real-time monitoring and alerting for suspicious activities.
-- Conduct a security audit of user accounts and permissions to ensure that only authorized users have access to modify shell configuration files.
-- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the compromise is severe or if additional expertise is required.
-- Educate users on security best practices, including recognizing phishing attempts and maintaining strong, unique passwords, to reduce the risk of future compromises."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_simple_web_server_connection_accepted.toml b/rules/linux/persistence_simple_web_server_connection_accepted.toml
index 3577788b8ee..47c99c850ca 100644
--- a/rules/linux/persistence_simple_web_server_connection_accepted.toml
+++ b/rules/linux/persistence_simple_web_server_connection_accepted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/17"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ network where host.os.type == "linux" and event.type == "start" and event.action
   (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*"))
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Simple HTTP Web Server Connection
-
-Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain persistence on compromised systems by deploying malicious payloads, such as reverse shells. The detection rule identifies suspicious server activity by monitoring for specific process names and command-line patterns indicative of these lightweight servers being used inappropriately.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and command-line arguments match the patterns specified in the detection rule, focusing on `process.name` and `process.command_line`.
-- Check the source IP address and port associated with the `connection_accepted` event to identify potential external connections.
-- Investigate the parent process of the detected Python or PHP process to determine how the server was initiated and if it was spawned by a legitimate application or script.
-- Use Osquery to list all active network connections on the host to identify any other suspicious connections: `SELECT * FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name LIKE 'python%' OR name REGEXP 'php?[0-9]?\\.?[0-9]{0,2}');`
-- Examine the file system for any newly created or modified files in the web server's root directory that could indicate the presence of malicious payloads.
-- Review system logs for any recent user logins or privilege escalations that could correlate with the initiation of the HTTP server.
-- Analyze the command history of the user account associated with the process to identify any manual commands that may have started the server.
-- Check for any scheduled tasks or cron jobs that might be configured to restart the server automatically, indicating persistence mechanisms.
-- Investigate any other alerts or anomalies on the host around the same timeframe to identify potential lateral movement or additional compromise indicators.
-- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or threat actor behaviors.
-
-### False positive analysis
-
-- Development and testing environments: Simple HTTP servers are often used by developers for testing purposes. These environments may frequently trigger the rule due to legitimate use of Python or PHP servers. Users can handle this by creating exceptions for known development machines or specific user accounts that regularly perform these activities.
-- Automated scripts and tools: Some automated scripts or tools may use lightweight HTTP servers for legitimate tasks such as data collection or internal communication. Users should identify these scripts and exclude them from the rule by specifying their process names or command-line patterns.
-- Educational or training sessions: In educational settings, instructors or students might use simple HTTP servers to demonstrate web server concepts. Users can manage these false positives by excluding specific IP ranges or user accounts associated with educational activities.
-- Internal testing of web applications: Organizations may conduct internal testing of web applications using simple HTTP servers. To prevent false positives, users can whitelist specific IP addresses or hostnames where these tests are conducted.
-- Continuous integration/continuous deployment (CI/CD) pipelines: CI/CD processes might involve spinning up temporary HTTP servers for testing purposes. Users should identify these processes and exclude them by defining exceptions based on process names or command-line arguments.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on logs and network traffic related to the detected simple HTTP server activity.
-- Terminate any unauthorized processes related to the simple HTTP server, such as those running Python or PHP with suspicious command-line arguments.
-- Remove any malicious payloads or scripts uploaded to the server web root, ensuring no backdoors remain on the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all software is up to date with the latest security patches.
-- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and applying least privilege principles.
-- Review and update security policies and procedures to address gaps identified during the incident response process, leveraging MITRE ATT&CK framework insights for persistence and server software component threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_simple_web_server_creation.toml b/rules/linux/persistence_simple_web_server_creation.toml
index d0d9cb90565..34d6e9c307b 100644
--- a/rules/linux/persistence_simple_web_server_creation.toml
+++ b/rules/linux/persistence_simple_web_server_creation.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/12/17"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ simple HTTP web servers to establish persistence on a compromised system by uplo
 to the server web root, allowing them to regain remote access to the system if lost. 
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*"]
+index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Simple HTTP Web Server Creation"
@@ -52,57 +54,20 @@ tags = [
     "Tactic: Execution",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
-  (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.args == "-S") or
-  (process.name like "python*" and process.args in ("--cgi", "CGIHTTPServer"))
-)
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  (
+    (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.args == "-S") or
+    (process.name like "python*" and process.args in ("--cgi", "CGIHTTPServer"))
+  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Simple HTTP Web Server Creation
-
-Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised systems by hosting malicious payloads. The detection rule identifies suspicious server creation by monitoring process executions that match patterns indicative of PHP or Python web server initiation, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments match the patterns specified in the detection rule, focusing on `process.name` and `process.args`.
-- Check the timestamp of the event to determine when the suspicious server was initiated and correlate it with other events around the same time.
-- Investigate the parent process of the suspicious server creation to understand how the process was initiated and identify any potential malicious scripts or commands.
-- Examine the user account under which the process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Use Osquery to list all active network connections and identify any unusual or unauthorized connections that may be related to the web server. Example query: `SELECT * FROM listening_ports WHERE port = 80 OR port = 8000;`
-- Investigate the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads.
-- Review system logs for any additional context or anomalies around the time of the server creation, such as failed login attempts or privilege escalation activities.
-- Check for any scheduled tasks or cron jobs that might be used to restart the web server or maintain persistence.
-- Analyze network traffic logs to identify any external IP addresses communicating with the server, which could indicate an adversary's control server.
-- Cross-reference the detected activity with threat intelligence sources to determine if the observed behavior matches known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- Development and testing environments: In many organizations, developers and testers frequently use simple HTTP web servers for legitimate purposes such as testing web applications or sharing files temporarily. These activities can trigger the detection rule, leading to false positives.
-- Automated scripts and tools: Some automated scripts or tools may use PHP or Python to start simple HTTP servers for tasks like data collection or internal service hosting, which are benign but may be flagged by the rule.
-- Educational and training sessions: In educational settings, instructors or students might use simple HTTP servers as part of learning exercises, which can be mistakenly identified as suspicious activity.
-- To manage these false positives, users can create exceptions for known and trusted processes or users by whitelisting specific command patterns or user accounts that frequently initiate these servers for legitimate purposes. Additionally, monitoring the context of server creation, such as the associated user or network activity, can help differentiate between benign and malicious use.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any malicious payloads or scripts hosted on the simple HTTP web server and remove them.
-- Review system logs and process execution history to determine the initial access vector and scope of the compromise.
-- Utilize MITRE ATT&CK framework details to understand the adversary's tactics, techniques, and procedures (TTPs) and assess potential persistence mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and network activity for future detection and analysis.
-- Restore the system to a known good state by reinstalling the operating system and applications, ensuring all security patches are applied.
-- Change all credentials and keys that may have been exposed or compromised during the incident.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and deploying endpoint protection solutions to prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_ssh_key_generation.toml b/rules/linux/persistence_ssh_key_generation.toml
index 051fc639d5d..e391a1b9c89 100644
--- a/rules/linux/persistence_ssh_key_generation.toml
+++ b/rules/linux/persistence_ssh_key_generation.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2024/05/31"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +15,7 @@ tool to move laterally across a network or maintain persistence by generating un
 access to systems.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.file*", "endgame-*"]
+index = ["logs-endpoint.events.file*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "SSH Key Generated via ssh-keygen"
@@ -29,6 +31,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -38,49 +41,6 @@ file where host.os.type == "linux" and event.action in ("creation", "file_create
 process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and
 not file.name : "known_hosts.*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SSH Key Generated via ssh-keygen
-
-SSH keys, created using the ssh-keygen tool, are essential for secure authentication in Linux environments. While typically used for legitimate access to remote systems, adversaries can exploit this by generating unauthorized keys, enabling lateral movement or persistence. The detection rule monitors key creation events in critical directories, flagging potential misuse by excluding known benign files.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event action is either "creation" or "file_create_event" and verify the process executable is "/usr/bin/ssh-keygen" to ensure the alert is valid.
-- Check the file path where the SSH key was created, ensuring it matches one of the critical directories: "/home/*/.ssh/*", "/root/.ssh/*", or "/etc/ssh/*".
-- Investigate the user account associated with the SSH key creation event to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the timestamp of the SSH key creation to identify if it occurred during unusual hours or coincides with other suspicious activities.
-- Use Osquery to list all SSH keys in the system and identify any unauthorized or unexpected keys. Example query: `SELECT * FROM file WHERE path LIKE '/home/%/.ssh/id_%' OR path LIKE '/root/.ssh/id_%' OR path LIKE '/etc/ssh/ssh_host_%';`
-- Cross-reference the SSH key creation event with recent login attempts or successful logins to determine if the key has been used for unauthorized access.
-- Analyze system logs for any other unusual activities or errors around the time of the SSH key creation to gather additional context.
-- Check for any recent changes to the SSH configuration files in "/etc/ssh/" that might indicate tampering or preparation for unauthorized access.
-- Investigate any other processes or commands executed by the same user around the time of the SSH key creation to identify potential malicious behavior.
-- Review network logs for any outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often generate SSH keys for legitimate purposes, such as setting up automated scripts or configuring new servers. These activities can trigger the rule but are non-threatening. Users can manage these by creating exceptions for specific user accounts or directories known to be used by administrators.
-- Automated deployment tools: Tools like Ansible, Puppet, or Chef may generate SSH keys as part of their deployment processes. These are typically benign and can be excluded by identifying the specific processes or service accounts involved in these operations.
-- Backup and recovery operations: Some backup solutions may create SSH keys to facilitate secure data transfer between systems. Users should identify these operations and exclude them from the rule by specifying the associated file paths or process names.
-- Development and testing environments: Developers may frequently generate SSH keys for testing purposes. To handle these, users can exclude specific development environments or user accounts from the rule.
-- Known benign scripts: If there are scripts or applications that are known to generate SSH keys as part of their normal operation, users can create exceptions for these by specifying the script names or paths in the exclusion list.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the SSH key creation by checking the user account associated with the key and confirming with the account owner.
-- Review system logs and SSH access logs to identify any unauthorized access attempts or successful logins using the newly created SSH key.
-- Remove any unauthorized SSH keys from the affected directories and change passwords for any compromised accounts.
-- Conduct a thorough scan of the system for any additional signs of compromise, such as unexpected processes or network connections.
-- Escalate the incident to the security operations team if unauthorized access is confirmed, providing them with all relevant logs and findings.
-- Implement enhanced logging policies to capture detailed SSH key creation events and monitor for any future unauthorized key generation.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate SSH key creation events with other suspicious activities across the network.
-- Restore the system to its operational state by ensuring all unauthorized changes are reverted and applying any necessary security patches.
-- Harden the system by enforcing strict SSH key management policies, such as using key expiration and limiting key usage to specific IP addresses."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_ssh_netcon.toml b/rules/linux/persistence_ssh_netcon.toml
index 76d885a5e68..44b2a2d4a20 100644
--- a/rules/linux/persistence_ssh_netcon.toml
+++ b/rules/linux/persistence_ssh_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -47,49 +47,6 @@ sequence by host.id with maxspan=1s
     )
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Connection Initiated by SSHD Child Process
-
-The SSH Daemon (SSHD) is crucial for secure remote access on Linux systems, managing user logins and executing commands. Adversaries may exploit SSHD by altering shell configurations or backdooring the daemon to establish unauthorized connections, often for persistence or data exfiltration. The detection rule identifies suspicious outbound connections initiated by SSHD child processes, excluding benign processes and internal IP ranges, to flag potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `process.entity_id` associated with the suspicious activity.
-- Examine the `process.parent.executable` field to confirm that the parent process is indeed `/usr/sbin/sshd`, indicating the connection was initiated by an SSHD child process.
-- Check the `destination.ip` field to determine the external IP address the connection was attempted to, and assess its reputation using threat intelligence sources.
-- Investigate the `process.executable` and `process.name` fields to identify the specific process that initiated the network connection, ensuring it is not a benign process like `/bin/yum` or `login_duo`.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` where `<process_id>` is the ID of the suspicious process.
-- Analyze the SSHD configuration files and shell configuration files for any unauthorized modifications or scripts that could trigger the process execution upon SSH login.
-- Review recent login attempts and user activity on the affected host to identify any unusual patterns or unauthorized access.
-- Correlate the event with other logs, such as authentication logs, to determine if there are any related suspicious activities or failed login attempts.
-- Investigate the network traffic logs for the specified `host.id` to identify any other unusual outbound connections or patterns that coincide with the alert.
-- Consult with the network team to verify if the destination IP is part of any known or legitimate business operations, or if it is associated with any known malicious infrastructure.
-
-### False positive analysis
-
-- **Automated System Updates**: Processes like `/bin/yum` or `/usr/bin/yum` may initiate network connections as part of routine system updates. These should be considered for exclusion if they are part of regular maintenance activities.
-- **Legitimate SSH Sessions**: Tools such as `login_duo`, `ssh`, `sshd`, and `sshd-session` might trigger alerts when they establish connections as part of normal SSH operations. Users can exclude these processes if they are verified as part of legitimate administrative tasks.
-- **Internal Network Scans**: Network connections to internal IP ranges might be flagged if the rule is not correctly excluding them. Ensure that the rule's IP exclusions cover all internal ranges used by the organization.
-- **Custom Scripts**: Custom scripts executed upon SSH login that initiate network connections for legitimate purposes, such as logging or monitoring, may trigger this rule. Users should identify and exclude these scripts if they are verified as non-threatening.
-- **Handling False Positives**: Users can manage false positives by updating the rule to include exceptions for known benign processes and IP ranges. Regularly review and adjust the exclusion list to align with the organization's network behavior and security policies.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and method of the compromise, focusing on SSHD configuration files and recent changes to shell scripts.
-- Review and analyze logs from the SSHD and network traffic to identify any unauthorized access or data transfer attempts.
-- Terminate any suspicious processes initiated by SSHD child processes and remove any unauthorized or malicious files or scripts found on the system.
-- Change all credentials associated with the compromised system, especially those used for SSH access, to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed SSHD activity and network connections for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Harden the system by configuring SSHD with strong authentication methods, disabling root login, and using firewalls to restrict access to trusted IP addresses only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_ssh_via_backdoored_system_user.toml b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
index d4933505483..9be325eed2b 100644
--- a/rules/linux/persistence_ssh_via_backdoored_system_user.toml
+++ b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2025/01/07"
 
 [rule]
 author = ["Elastic"]
@@ -61,49 +61,6 @@ user.name in (
   "avahi", "sshd", "dnsmasq"
 ) and event.outcome == "success"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Login via Unusual System User
-
-In Linux environments, system users typically have restricted login capabilities to prevent unauthorized access. These accounts, often set with `nologin`, are not meant for interactive sessions. Adversaries may exploit these accounts by altering their configurations to enable SSH access, thus bypassing standard security measures. The detection rule identifies successful logins by these uncommon system users, signaling potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific system user involved in the login attempt and the host where the login occurred.
-- Verify the login time and correlate it with known maintenance windows or authorized activities to rule out false positives.
-- Check the user's shell configuration to confirm if it was altered from `nologin` to a valid shell, indicating potential tampering.
-- Investigate the source IP address of the login attempt to determine if it is from a known or trusted network.
-- Use Osquery to gather additional context on the system user by running: `SELECT * FROM etc_passwd WHERE username = '<system_user>';` to verify user details and shell configuration.
-- Examine the SSH configuration files (e.g., `/etc/ssh/sshd_config`) for any unauthorized changes that might allow system users to log in.
-- Review recent authentication logs (e.g., `/var/log/auth.log`) for any unusual patterns or repeated login attempts involving the system user.
-- Check for any recent changes to user accounts or group memberships that might indicate account manipulation.
-- Investigate any related processes or services running under the system user account to identify potential malicious activity.
-- Correlate the event with other security alerts or logs to identify if this login attempt is part of a broader attack pattern.
-
-### False positive analysis
-
-- System maintenance tasks: Some automated scripts or maintenance tasks may require temporary login access using system accounts. These should be reviewed and, if deemed non-threatening, can be excluded by adding exceptions for specific scripts or IP addresses.
-- Backup operations: Backup software might use system accounts like "backup" to perform regular data backups. Verify the legitimacy of these operations and exclude them if they are part of routine, authorized processes.
-- Monitoring and management tools: Certain monitoring or management tools may use system accounts for health checks or updates. Confirm these activities with your IT team and exclude them if they are recognized as safe and necessary.
-- Custom applications: In some environments, custom applications might be configured to use system accounts for specific functions. Ensure these applications are secure and exclude their activities if they are essential and authorized.
-- Scheduled tasks: Cron jobs or other scheduled tasks might inadvertently trigger logins using system accounts. Review these tasks and exclude them if they are part of expected and secure operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Review authentication logs to confirm the unusual login activity and identify any other potentially compromised accounts.
-- Change passwords for all system users and ensure that default system accounts are set back to 'nologin' where applicable.
-- Conduct a thorough investigation to determine how the adversary gained access and whether any other systems are affected.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed authentication events and system changes for future investigations.
-- Integrate threat intelligence feeds to correlate unusual login activities with known threat actor tactics and techniques.
-- Restore the system from a known good backup if any unauthorized changes or malware are detected.
-- Apply system hardening measures, such as disabling unused services and enforcing least privilege access controls.
-- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_suspicious_file_opened_through_editor.toml b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
index 133ce16a907..fecb6235a8a 100644
--- a/rules/linux/persistence_suspicious_file_opened_through_editor.toml
+++ b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2023/07/25"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -14,7 +16,7 @@ through an editor will trigger this event. Attackers may alter any of the files
 persistence, escalate privileges or perform reconnaisance on the system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 max_signals = 1
@@ -30,6 +32,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -55,49 +58,6 @@ file.path : (
   "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Suspicious File Edit
-
-In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert. Pay attention to the `file.path` field to understand which sensitive directory was involved.
-- Check the `event.action` field to confirm whether the action was a "creation" or "file_create_event" to ensure the alert is relevant to a new file creation.
-- Use Osquery to list recent file modifications in the directory where the .swp file was detected. Example query: `SELECT path, mtime FROM file WHERE directory = '/etc/' ORDER BY mtime DESC LIMIT 10;`
-- Investigate the user account associated with the file creation event. Look into the `user.name` field to determine if the action was performed by a legitimate user or a potential adversary.
-- Examine system logs around the time of the alert to identify any unusual login attempts or other suspicious activities. Focus on logs such as `/var/log/auth.log` or `/var/log/secure`.
-- Use Osquery to check for any running processes that might be related to text editors or suspicious activities. Example query: `SELECT name, pid, path FROM processes WHERE name IN ('vim', 'nano', 'emacs');`
-- Verify the integrity of the original file that the .swp file corresponds to by comparing it with a known good backup or using a file integrity monitoring tool.
-- Investigate any recent changes to user permissions or group memberships that could indicate privilege escalation attempts. Use Osquery: `SELECT * FROM user_groups WHERE user = 'suspicious_user';`
-- Check for any other .swp files in the system that might indicate a broader pattern of suspicious file edits. Use a command like `find / -name "*.swp"`.
-- Correlate the alert with other security events or alerts in your SIEM to identify if this is part of a larger attack pattern or campaign.
-
-### False positive analysis
-
-- Opening a file in a text editor without making any changes can trigger the creation of a .swp file, leading to a false positive. Users can handle this by monitoring the frequency and context of such events to distinguish between benign and suspicious activities.
-- System administrators or automated scripts that regularly open and review configuration files for maintenance purposes may inadvertently create .swp files. To manage this, users can create exceptions for known maintenance windows or specific user accounts that perform these tasks.
-- Development environments where users frequently edit configuration files in sensitive directories might generate numerous .swp files. Users can exclude specific directories or user accounts from triggering alerts if they are part of a controlled development process.
-- Backup or synchronization tools that temporarily open files for copying or syncing purposes might also create .swp files. Users can identify these tools and exclude their activities from the rule to prevent false positives.
-- In environments where multiple users have access to the same system, legitimate users might open files in sensitive directories for legitimate reasons. Users can implement user-based exceptions or monitor user behavior patterns to differentiate between normal and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement.
-- Conduct a thorough investigation to identify the source of the suspicious file edit, including reviewing recent user activity and system logs.
-- Verify the integrity of the affected files by comparing them with known good backups or using file integrity monitoring tools.
-- If unauthorized changes are confirmed, restore the affected files from a clean backup to ensure system integrity.
-- Escalate the incident to the security operations team if evidence of privilege escalation or persistence mechanisms is found.
-- Implement enhanced logging policies to capture detailed file access and modification events, focusing on sensitive directories and files.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate events and improve detection capabilities.
-- Apply system hardening measures, such as restricting access to critical files and directories and enforcing the principle of least privilege.
-- Regularly update and patch the system to mitigate vulnerabilities that could be exploited for unauthorized file edits.
-- Educate users on secure file handling practices and the risks associated with editing sensitive files in critical directories."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
index be87a383efc..5590ed91078 100644
--- a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
+++ b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -48,49 +48,6 @@ sequence by host.id, user.id with maxspan=1s
  [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.pid, process.entity_id
  [network where host.os.type == "linux" and event.type == "end" and event.action == "disconnect_received" and process.name == "sshd"] by process.pid, process.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Execution via XZBackdoor
-
-The XZBackdoor leverages SSH, a secure protocol for remote system access, to execute malicious commands. Adversaries exploit SSH by initiating sessions that appear legitimate but execute unauthorized processes, often terminating abruptly to avoid detection. The detection rule identifies such anomalies by monitoring SSH processes for unexpected terminations and unusual child process executions, signaling potential backdoor activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand which host and user IDs are involved, as these are key identifiers in the query.
-- Examine the process tree for the SSHD process using the `process.pid` and `process.entity_id` fields to identify any unusual child processes that were spawned.
-- Check the command-line arguments of the SSHD process using `process.args` to verify if the `-D` and `-R` flags were used, which may indicate a persistent SSH session.
-- Investigate the parent process of any suspicious child processes using `process.parent.name` and `process.parent.entity_id` to determine if they were initiated by SSHD.
-- Analyze the exit codes of the SSHD process using `process.exit_code` to identify any non-zero values that could indicate abnormal termination.
-- Look into the network activity associated with the SSHD process using `event.action` and `event.type` to confirm if there was a disconnect event, which might suggest abrupt session termination.
-- Use Osquery to gather more context on the SSHD process and its child processes. For example, run the following query to list all processes with their parent-child relationships: `SELECT pid, name, path, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'sshd');`
-- Cross-reference the executable paths of suspicious processes with known legitimate paths using `process.executable` to identify any anomalies.
-- Review the system logs for any additional context around the time of the alert, focusing on authentication logs and any other relevant security logs.
-- Correlate the findings with any other alerts or incidents involving the same host or user to identify patterns or repeated suspicious behavior.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use SSH to perform routine maintenance or execute scripts that could match the rule's criteria, such as starting and stopping services or running diagnostic commands. To manage this, users can create exceptions for known administrative accounts or specific command patterns that are regularly used in maintenance activities.
-- Automated scripts and cron jobs: Scheduled tasks or automated scripts that use SSH for remote execution might trigger the rule if they terminate unexpectedly due to errors or network issues. Users can handle these by identifying and excluding specific scripts or cron jobs that are known to cause such behavior.
-- Security tools and monitoring software: Some security tools or monitoring solutions might use SSH to perform checks or gather data, which could mimic the behavior detected by the rule. Users should review and whitelist these tools by their executable paths or command-line arguments to prevent false positives.
-- Testing and development environments: In environments where frequent testing or development occurs, SSH sessions may be started and stopped rapidly, leading to false positives. Users can exclude specific hosts or user accounts associated with testing and development to reduce noise.
-- Network instability: Temporary network issues might cause SSH sessions to disconnect unexpectedly, triggering the rule. Users can monitor network stability and exclude known periods of instability or specific network segments that are prone to such issues.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the SSH logs and process execution history to identify any unauthorized access or commands executed.
-- Terminate any suspicious or unauthorized SSH sessions and processes identified during the investigation.
-- Change all credentials associated with the compromised system, especially SSH keys and passwords, to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging and monitoring for SSH activities, including logging of all SSH sessions and command executions, to detect future anomalies.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system from a known good backup to ensure that no malicious code remains on the system.
-- Apply system hardening measures, such as disabling root login via SSH, using key-based authentication, and implementing two-factor authentication (2FA) for SSH access.
-- Review and update security policies and procedures to address any gaps identified during the incident response process, ensuring alignment with MITRE ATT&CK framework techniques for persistence and system process modification."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_systemd_generator_creation.toml b/rules/linux/persistence_systemd_generator_creation.toml
index 3e0de9c3b34..ac5ff2677bd 100644
--- a/rules/linux/persistence_systemd_generator_creation.toml
+++ b/rules/linux/persistence_systemd_generator_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -83,49 +83,6 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
   process.executable == null
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Systemd Generator Created
-
-Systemd generators are scripts that systemd runs at boot or during configuration reloads to convert non-native configurations into unit files. While they streamline service management, adversaries can exploit them to execute unauthorized code, ensuring persistence. The detection rule identifies suspicious generator file activities, excluding benign processes and file types, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path where the systemd generator was created or renamed, focusing on paths like `/run/systemd/system-generators/*` and `/etc/systemd/system-generators/*`.
-- Check the process that triggered the alert by examining the `process.executable` field to determine if it is a known benign process or potentially malicious.
-- Investigate the user account associated with the process that created or renamed the generator file to assess if it has legitimate access or if it might be compromised.
-- Use Osquery to list all systemd generator files and their metadata to identify any unexpected or unauthorized files. Example query: `SELECT * FROM file WHERE path LIKE '/run/systemd/system-generators/%' OR path LIKE '/etc/systemd/system-generators/%';`
-- Examine the file creation or modification timestamps to determine if the activity aligns with expected system changes or updates.
-- Cross-reference the alert with recent system updates or package installations to rule out legitimate changes that might have triggered the alert.
-- Analyze the contents of the suspicious generator file to identify any embedded scripts or commands that could indicate malicious intent.
-- Check system logs for any related entries around the time of the alert to gather additional context on the activity.
-- Investigate any network connections or external communications initiated by the process that created or modified the generator file to identify potential command and control activity.
-- Review historical alerts and incidents involving the same host or user account to identify patterns or repeated suspicious behavior that might indicate a broader compromise.
-
-### False positive analysis
-
-- Known false positives for the Systemd Generator Created rule often arise from legitimate software installations or updates, where package managers like dpkg, rpm, or snapd create or modify generator files as part of their normal operations.
-- To manage these false positives, users can exclude specific processes known to perform legitimate generator file operations by adding them to the exception list in the detection rule. This includes processes like dpkg, rpm, and snapd, which are already accounted for in the rule.
-- Another source of false positives can be temporary files created by text editors or system processes, which may have extensions like "swp" or "dpkg-remove". These can be excluded by adding their extensions to the exception list.
-- Users should regularly review and update the exception list to include any new legitimate processes or file types that are identified as causing false positives, ensuring that the detection rule remains effective without generating unnecessary alerts.
-- It's important to maintain a balance between excluding known benign activities and ensuring that potentially malicious activities are still detected, so users should carefully evaluate each exception added to the rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the unauthorized systemd generator file creation, examining logs and process histories.
-- Review the contents of the suspicious generator file to understand the potential impact and any malicious code it may contain.
-- Remove or disable the unauthorized systemd generator file to prevent it from executing during future boot processes.
-- Restore any modified or deleted legitimate systemd generator files from a known good backup to ensure system integrity.
-- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if the threat actor's identity is unknown.
-- Implement enhanced logging policies to capture detailed information on file creation and modification events, focusing on systemd generator directories.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Apply system hardening measures, such as restricting write permissions to systemd generator directories and ensuring only trusted processes can create or modify files in these locations.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address any deficiencies discovered during the investigation."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_systemd_netcon.toml b/rules/linux/persistence_systemd_netcon.toml
index 0e33b7d8024..ca08b619167 100644
--- a/rules/linux/persistence_systemd_netcon.toml
+++ b/rules/linux/persistence_systemd_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -67,52 +67,6 @@ sequence by host.id with maxspan=5s
   [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
    not process.executable == "/tmp/newroot/bin/curl"] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Network Connection via systemd
-
-Systemd is integral to Linux, managing system processes and services. Adversaries exploit it by altering unit files or replacing binaries, ensuring malicious scripts run at startup. The detection rule identifies suspicious network activities initiated by systemd, focusing on unusual processes like scripting languages or network tools, which may indicate a backdoor or persistence mechanism.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `process.entity_id` and `process.parent.entity_id` involved in the suspicious activity.
-- Examine the process command line and arguments for the suspicious process using the `process.name` field to understand what script or command was executed.
-- Check the parent process details using the `process.parent.name` field to confirm that the process was indeed initiated by systemd.
-- Investigate the network connection details, including the destination IP and port, using the `network` event data to determine if the connection is to a known malicious or unusual destination.
-- Use Osquery to list all systemd unit files and check for any unusual or recently modified files:
-  ```sql
-  SELECT * FROM systemd_units WHERE path LIKE '/etc/systemd/system/%' OR path LIKE '/lib/systemd/system/%';
-  ```
-- Cross-reference the `process.executable` path with known legitimate binaries to ensure it hasn't been replaced or tampered with.
-- Investigate the `/tmp/newroot/bin/curl` path to ensure it is not being used as a legitimate bypass for the detection rule.
-- Review system logs around the time of the alert to identify any other suspicious activities or related events.
-- Check for any recent changes to systemd configuration files or binaries using file integrity monitoring tools or by reviewing file modification timestamps.
-- Correlate the alert with other security events or alerts from the same host to identify potential patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- System administrators or automated scripts may use scripting languages like Python, PHP, or Perl for legitimate maintenance tasks, leading to false positives. Users can create exceptions for known maintenance scripts by whitelisting specific script paths or process names.
-- Network tools such as netcat or telnet might be used for legitimate troubleshooting or monitoring purposes. To handle these, users can exclude specific network activities by defining exceptions for known IP addresses or ports associated with routine operations.
-- Development environments often use scripting languages and network tools for testing and debugging, which can trigger alerts. Users can manage these by excluding processes executed within designated development directories or by specific user accounts.
-- Some legitimate applications may use systemd to manage their network connections, appearing suspicious. Users should identify and whitelist these applications by their process names or executable paths to prevent false positives.
-- Regularly scheduled tasks or cron jobs that involve network communication might be flagged. Users can mitigate this by excluding processes associated with known cron jobs or by specifying time-based exceptions for expected network activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any modified or newly created systemd unit files and verify their legitimacy.
-- Review and analyze the process tree to understand the scope of the compromise and identify any additional malicious processes or scripts.
-- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
-- Restore any modified or replaced systemd binaries from a trusted backup or reinstall the affected packages to ensure system integrity.
-- Implement enhanced logging for systemd activities and network connections to improve detection of similar threats in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited.
-- Review and update system hardening measures, such as disabling unnecessary services and enforcing strict access controls, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_tainted_kernel_module_load.toml b/rules/linux/persistence_tainted_kernel_module_load.toml
index 3ecc3a8754a..6cabc894a4d 100644
--- a/rules/linux/persistence_tainted_kernel_module_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/23"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -55,52 +55,6 @@ query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
 message:"module verification failed: signature and/or required key missing - tainting kernel"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Tainted Kernel Module Load
-
-Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of code. Adversaries exploit this by loading malicious modules to evade detection and maintain persistence. The detection rule identifies suspicious module loads by monitoring syslog for messages indicating failed module verification, signaling potential unauthorized kernel modifications. This helps in identifying and mitigating rootkit threats.
-
-### Possible investigation steps
-
-- Review the syslog entries around the time of the alert to gather more context about the module load attempt, focusing on the `message` field for any additional error messages or anomalies.
-- Check the `host.os.type` and `event.dataset` fields to confirm the alert pertains to a Linux system and is sourced from the syslog, ensuring the data is relevant to the investigation.
-- Identify the specific kernel module that triggered the alert by examining the `process.name` field and any associated module names or paths in the syslog message.
-- Use Osquery to list all currently loaded kernel modules and their details to identify any unfamiliar or suspicious modules:
-  ```sql
-  SELECT name, size, used_by FROM kernel_modules;
-  ```
-- Investigate the origin of the suspicious module by checking the file system for the module's file path and examining its metadata, such as creation and modification times.
-- Cross-reference the module's file path with known good or bad module lists to determine if it is a legitimate or potentially malicious module.
-- Analyze the system's boot logs and startup scripts to check for any unauthorized modifications that might load the suspicious module at boot time.
-- Review user and process activity logs around the time of the alert to identify any unusual behavior or processes that might have attempted to load the module.
-- Check for any recent changes in user privileges or new user accounts that could indicate unauthorized access or privilege escalation attempts.
-- Investigate network activity logs for any signs of communication with known malicious IP addresses or domains that could be associated with the suspicious module.
-
-### False positive analysis
-
-- Some legitimate kernel modules may not be signed or may lack the required keys, leading to false positives. This can occur with custom-built modules or those from trusted third-party vendors that do not follow the standard signing process.
-- Kernel modules used in development or testing environments might trigger alerts due to missing signatures, even though they are not malicious.
-- Users can manage these false positives by creating exceptions for specific modules known to be safe. This can be done by maintaining a whitelist of trusted module names or paths that are frequently loaded without signatures.
-- Regularly review and update the whitelist to ensure it only includes modules that are verified as non-threatening, reducing the risk of overlooking a genuine threat.
-- Consider implementing additional checks or monitoring for other indicators of compromise to complement the detection rule and provide a more comprehensive security posture.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Conduct a thorough investigation to identify the loaded kernel module and verify its legitimacy by checking against known good modules and signatures.
-- If the module is confirmed malicious, remove it from the system and check for any additional unauthorized changes or files.
-- Review system logs and use forensic tools to trace the origin of the tainted module load and identify any potential entry points or vulnerabilities exploited by the adversary.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Restore the system to a known good state using backups or system snapshots, ensuring that all malicious artifacts are removed.
-- Apply security patches and updates to the operating system and all software to close any vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed information on kernel module loads and other critical system events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context on similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update hardening measures, such as enforcing strict module signing policies and using secure boot mechanisms."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
index 5bc2effccdf..57ff1986c23 100644
--- a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -55,48 +55,6 @@ query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
 message:"loading out-of-tree module taints kernel."
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Tainted Out-Of-Tree Kernel Module Load
-
-Kernel modules extend the functionality of the Linux kernel without rebooting the system. While beneficial, out-of-tree modules, not included in the official kernel source, can taint the kernel, posing security risks. Adversaries exploit this by loading malicious modules to maintain persistence or evade detection. The detection rule monitors syslog for specific messages indicating such module loads, helping identify potential rootkit activity.
-
-### Possible investigation steps
-
-- Review the syslog entries around the time of the alert to gather more context about the module load event, focusing on the `event.dataset:"system.syslog"` and `process.name:kernel` fields.
-- Identify the specific out-of-tree module that was loaded by examining the `message` field for details about the module name and path.
-- Check the system's kernel module directory (e.g., `/lib/modules/$(uname -r)/extra/`) to verify the presence and legitimacy of the module file.
-- Use Osquery to list all currently loaded kernel modules and their details with the query: `SELECT name, size, used_by FROM kernel_modules WHERE name = '<module_name>';` to confirm the module's presence and usage.
-- Investigate the source and integrity of the module file by checking its creation and modification timestamps, and compare its hash against known good values if available.
-- Examine the system's package manager logs or configuration management tools to determine if the module was installed or updated recently as part of a legitimate package or update.
-- Review user and process activity logs around the time of the module load to identify any suspicious behavior or unauthorized access attempts.
-- Check for any recent changes to system configurations or scripts that could have led to the loading of the module, focusing on boot or startup scripts.
-- Investigate any other alerts or anomalies in the system logs that coincide with the module load event to identify potential related malicious activity.
-- Consult threat intelligence sources to determine if the module or its characteristics match any known malicious signatures or behaviors.
-
-### False positive analysis
-
-- Legitimate third-party drivers: Some out-of-tree kernel modules are legitimate third-party drivers necessary for specific hardware functionality. These can trigger the rule but do not pose a security threat. Users can create exceptions for these known drivers by identifying their specific module names and excluding them from the detection rule.
-- Custom kernel modules: Organizations may develop custom kernel modules for internal use, which can also taint the kernel. These should be documented and whitelisted to prevent false positives. Users should maintain a list of approved custom modules and adjust the detection rule to exclude these from alerts.
-- Development and testing environments: In environments where kernel development or testing occurs, frequent loading of out-of-tree modules is expected. Users can configure the rule to ignore these environments by excluding specific hostnames or IP addresses associated with development and testing.
-- Vendor-specific modules: Some vendors provide out-of-tree modules for enhanced functionality or performance. Users should verify the legitimacy of these modules and, if deemed safe, add them to an exception list to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Conduct a thorough investigation to identify the loaded out-of-tree kernel module, including its origin, purpose, and any associated processes or files.
-- Utilize forensic tools to capture memory and disk images for further analysis, ensuring evidence preservation for potential legal or compliance requirements.
-- Cross-reference the identified module with known malicious signatures or behaviors using threat intelligence databases and resources.
-- Remove the unauthorized or malicious kernel module and any associated files or processes from the system.
-- Apply patches and updates to the kernel and all installed software to mitigate vulnerabilities that could be exploited by similar threats.
-- Implement enhanced logging policies to capture detailed system and network activity, focusing on kernel module loads and other critical events.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve monitoring and detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to similar threats, emphasizing the importance of maintaining system integrity and security."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_udev_rule_creation.toml b/rules/linux/persistence_udev_rule_creation.toml
index 9fb9aa63ee4..aa3b26fe2c2 100644
--- a/rules/linux/persistence_udev_rule_creation.toml
+++ b/rules/linux/persistence_udev_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -83,49 +83,6 @@ file.path : (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Systemd-udevd Rule File Creation
-
-Systemd-udevd manages device nodes and handles kernel device events in Linux, using rule files to automate responses to hardware changes. Adversaries can exploit this by creating malicious rules that execute commands when specific devices are connected. The detection rule monitors the creation or renaming of these rule files, excluding legitimate processes, to identify potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and name of the rule file that was created or renamed, focusing on paths like "/lib/udev/*" and "/etc/udev/rules.d/*".
-- Check the process executable that triggered the alert to ensure it is not one of the legitimate processes listed in the exclusion criteria, such as "/bin/dpkg" or "/usr/bin/rpm".
-- Investigate the parent process of the executable to understand the context in which the rule file was created, using process lineage to identify any suspicious activity.
-- Use Osquery to list all udev rule files and their metadata, including creation and modification times, to identify any recent changes: `SELECT * FROM file WHERE path LIKE '/etc/udev/rules.d/%' OR path LIKE '/lib/udev/rules.d/%';`
-- Examine the contents of the suspicious rule file to identify any potentially malicious commands or scripts that could be executed when a device is connected.
-- Cross-reference the file creation or modification time with other system logs to identify any correlated events or activities that occurred around the same time.
-- Check for any recent connections of new or unusual devices to the system that might have triggered the rule file execution.
-- Investigate the user account associated with the process that created or modified the rule file to determine if it has been compromised or is acting suspiciously.
-- Review historical data to determine if similar rule file creation or modification events have occurred in the past, indicating a pattern of behavior.
-- Analyze network logs for any outbound connections or data exfiltration attempts following the rule file creation, which might suggest malicious intent.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the creation or modification of udev rule files, especially when using package managers like dpkg, rpm, or yum. These processes are typically excluded in the detection rule to prevent false positives.
-- System management tools such as Puppet, Chef, or Ansible might create or modify udev rules as part of their configuration management tasks. These tools are often run by trusted processes and can be excluded by adding their executables to the exception list.
-- Custom scripts or administrative tasks performed by system administrators might involve creating or modifying udev rules. If these actions are routine and verified as non-malicious, the specific scripts or processes can be added to the exclusion list.
-- Automated system updates or maintenance tasks, such as those performed by systemd or netplan, may also result in rule file changes. These processes are generally safe and can be excluded by specifying their names or paths in the detection rule.
-- Users can manage false positives by regularly reviewing and updating the exclusion list to include any new legitimate processes or paths that are identified as part of normal system operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the malicious udev rule file creation, examining recent user activity and process execution logs.
-- Remove any unauthorized or suspicious udev rule files from the system directories, ensuring that only legitimate rules remain.
-- Review and restore any system configurations or files that may have been altered by the malicious rule execution.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging for udev rule file changes and process executions to improve detection of similar threats in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze related security events.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
-- Educate users and administrators on the risks associated with unauthorized device connections and the importance of reporting suspicious activity."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_unusual_pam_grantor.toml b/rules/linux/persistence_unusual_pam_grantor.toml
index 2d57f0ccb2a..2fee0dc96ad 100644
--- a/rules/linux/persistence_unusual_pam_grantor.toml
+++ b/rules/linux/persistence_unusual_pam_grantor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -46,49 +46,6 @@ query = '''
 event.category:authentication and host.os.type:linux and event.action:authenticated and event.outcome:success and
 auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Authentication via Unusual PAM Grantor
-
-Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit uncommon PAM grantors to escalate privileges or maintain persistence by altering default configurations. The detection rule identifies successful authentications using atypical PAM grantors, signaling potential unauthorized modifications and aligning with MITRE ATT&CK's persistence tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific PAM grantor involved in the authentication event and cross-reference it with known legitimate PAM modules.
-- Examine the `event.category`, `host.os.type`, `event.action`, and `event.outcome` fields to confirm the context of the authentication event and ensure it aligns with the alert criteria.
-- Check the `auditd.data.grantors` field to identify the exact grantor used and determine if it is part of any known or expected configurations.
-- Investigate the user account associated with the authentication event to determine if it is a legitimate user or potentially compromised.
-- Use Osquery to list all PAM modules and configurations on the affected host to identify any unauthorized or unusual entries. Example query: `SELECT * FROM pam_modules;`
-- Review recent changes to PAM configuration files, such as `/etc/pam.d/`, to identify any unauthorized modifications or additions.
-- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any other suspicious authentication attempts or related activities around the time of the alert.
-- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise.
-- Investigate the source IP address and geolocation associated with the authentication event to determine if it originates from a known or suspicious location.
-- Consult with system administrators or users to verify if any legitimate changes were made to the PAM configuration that could explain the unusual grantor usage.
-
-### False positive analysis
-
-- Certain legitimate applications or services may use custom PAM modules for authentication, which could trigger this rule. For example, specialized software that requires unique authentication methods might not use standard PAM grantors.
-- System administrators might intentionally configure non-standard PAM modules for enhanced security or specific operational needs, leading to false positives.
-- To manage these false positives, users can create exceptions for known and trusted PAM grantors by updating the detection rule to exclude these specific modules.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the integrity of the detection process.
-- Collaborate with IT and security teams to document and understand the use of any non-standard PAM modules within the organization to accurately adjust the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes to PAM configurations and unusual user activity.
-- Review and analyze authentication logs to identify any unauthorized access attempts or successful authentications using unusual PAM grantors.
-- Revert any unauthorized changes to the PAM configuration files to their default state to ensure only legitimate authentication methods are used.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed authentication events and PAM module usage for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual PAM activity with known threat actor tactics.
-- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Harden the system by implementing least privilege access controls, regular audits of PAM configurations, and continuous monitoring for unusual authentication patterns."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_unusual_sshd_child_process.toml b/rules/linux/persistence_unusual_sshd_child_process.toml
index faa84e146d1..83eae707d3b 100644
--- a/rules/linux/persistence_unusual_sshd_child_process.toml
+++ b/rules/linux/persistence_unusual_sshd_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/16"
 
 [rule]
 author = ["Elastic"]
@@ -34,48 +34,6 @@ event.category:process and host.os.type:linux and event.type:start and event.act
 process.parent.name:(ssh or sshd) and process.args_count:2 and
 not process.command_line:(-bash or -zsh or -sh)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual SSHD Child Process
-
-Secure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, filtering out typical shell invocations, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific process that was spawned, including the `process.command_line` and `process.args_count` fields, to identify any unusual or suspicious command-line arguments.
-- Check the `process.parent.name` field to confirm whether the parent process is indeed `ssh` or `sshd`, and verify the legitimacy of the parent process by cross-referencing with known user activity or scheduled tasks.
-- Investigate the user account associated with the SSH session by examining the `user.name` field to determine if the account is known and authorized to perform such actions.
-- Use Osquery to gather more context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;` to retrieve detailed information about the process, including its path, arguments, and environment variables.
-- Examine the `host.os.type` field to ensure the alert pertains to a Linux system, as expected, and correlate with any other alerts or logs from the same host for additional context.
-- Analyze the `event.category` and `event.type` fields to confirm that the event is indeed a process start event, and correlate with other process events to identify any related or subsequent suspicious activity.
-- Check for any recent changes in the system's SSH configuration files, such as `/etc/ssh/sshd_config`, to identify potential unauthorized modifications that could facilitate persistence or backdoor creation.
-- Review historical logs and alerts for the same host or user to identify any patterns of unusual SSH activity or previous instances of similar alerts.
-- Investigate network logs to identify any unusual or unauthorized remote connections associated with the SSH session, focusing on the source IP address and geolocation.
-- Consult threat intelligence sources to determine if the command-line arguments or process names observed are associated with known malicious activity or threat actor tactics.
-
-### False positive analysis
-
-- Known false positives for the Unusual SSHD Child Process rule may include legitimate administrative scripts or automated tasks that are executed via SSH but do not follow typical shell invocation patterns. These can be routine maintenance scripts or monitoring tools that use SSH for remote execution.
-- Users can handle these false positives by creating exceptions for specific processes or command lines that are known to be safe. This can be done by adding these processes to an allowlist or by modifying the detection rule to exclude certain command patterns that are verified as non-threatening.
-- It is important to regularly review and update these exceptions to ensure that they do not inadvertently allow malicious activity. This involves monitoring the frequency and context of the flagged processes to distinguish between benign and potentially harmful activities.
-- Collaboration with system administrators and security teams can help in identifying and documenting legitimate use cases that may trigger the rule, ensuring that the detection remains effective while minimizing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on SSH logs and process creation events.
-- Terminate any suspicious or unauthorized SSHD child processes identified during the investigation.
-- Review user accounts and SSH keys on the affected system to ensure no unauthorized accounts or keys have been added.
-- Change passwords and regenerate SSH keys for all legitimate users on the compromised system.
-- Apply security patches and updates to the operating system and SSH service to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process creation and network activity, ensuring future anomalies are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze security events more effectively.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring all security measures are in place before reconnecting to the network.
-- Harden the system by disabling unused services, enforcing strong authentication mechanisms, and regularly reviewing security configurations to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_user_or_group_creation_or_modification.toml b/rules/linux/persistence_user_or_group_creation_or_modification.toml
index 2259864ffe0..3c1f2b7696b 100644
--- a/rules/linux/persistence_user_or_group_creation_or_modification.toml
+++ b/rules/linux/persistence_user_or_group_creation_or_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -72,48 +72,6 @@ query = '''
 iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and 
 event.action in ("changed-password", "added-user-account", "added-group-account-to")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 User or Group Creation/Modification
-
-In Linux environments, user and group management is crucial for access control. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes `auditd_manager` to monitor successful user or group changes, focusing on actions like password changes or account additions, aligning with MITRE ATT&CK's persistence tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `event.type` and `event.action` that triggered the alert, focusing on whether it was a "creation" or "change" event.
-- Check the `auditd.result` field to confirm the success of the user or group modification, ensuring that the action was completed successfully.
-- Identify the user account or group involved in the event by examining the relevant fields in the alert, such as the username or group name.
-- Investigate the source of the event by reviewing the `host.os.type` and any associated IP addresses or hostnames to determine where the change originated.
-- Use Osquery to gather additional context about the user or group modification. For example, run the following query to list recent user additions or modifications: `SELECT * FROM users WHERE username = '<username>'`.
-- Cross-reference the identified user or group with known legitimate accounts to determine if the change aligns with expected administrative activities.
-- Review system logs and audit logs around the time of the event to identify any related activities or anomalies that could indicate malicious intent.
-- Check for any other recent alerts or events involving the same user or group to assess if this is part of a broader pattern of suspicious behavior.
-- Investigate the account that performed the modification to determine if it has been compromised or if it is being used by an unauthorized user.
-- Consult with system administrators or other relevant personnel to verify if the user or group modification was authorized and aligns with current operational needs.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often create or modify user and group accounts as part of regular maintenance or onboarding processes. These legitimate actions can trigger the rule, leading to false positives.
-- Automated scripts or tools: Some organizations use automated scripts or configuration management tools (e.g., Ansible, Puppet) to manage user accounts, which can result in frequent non-threatening account changes being flagged.
-- Software installations: Certain software installations may create or modify user accounts as part of their setup process, which can be mistakenly identified as suspicious activity.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts/tools by filtering out events associated with these trusted sources. This can be done by adding conditions to the detection rule to exclude actions performed by specific user accounts or processes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Review the audit logs to identify the specific user or group changes and determine if they were authorized or suspicious.
-- Verify the legitimacy of the newly created or modified accounts by cross-referencing with recent administrative activities and user requests.
-- If unauthorized changes are confirmed, disable or remove the suspicious accounts and reset passwords for any affected legitimate accounts.
-- Conduct a thorough investigation to identify any additional compromised systems or accounts, leveraging threat intelligence and MITRE ATT&CK details for context.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Implement enhanced logging policies to capture detailed user and group management activities, ensuring audit logs are securely stored and regularly reviewed.
-- Integrate additional security tools, such as intrusion detection systems (IDS) or endpoint detection and response (EDR) solutions, to improve monitoring and detection capabilities.
-- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all security controls are active and functioning.
-- Harden the system by enforcing least privilege access, implementing multi-factor authentication, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_xdg_autostart_netcon.toml b/rules/linux/persistence_xdg_autostart_netcon.toml
index dba55e65de1..f9a8948444a 100644
--- a/rules/linux/persistence_xdg_autostart_netcon.toml
+++ b/rules/linux/persistence_xdg_autostart_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -97,53 +97,6 @@ sequence by host.id, process.entity_id with maxspan=1s
      )
   ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Connections Initiated Through XDG Autostart Entry
-
-XDG Autostart entries are used in Linux environments like GNOME and XFCE to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign applications and local IP ranges.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `process.entity_id` associated with the suspicious activity.
-- Examine the `process.executable` and `process.args` fields to determine the exact command or script executed through the XDG autostart entry.
-- Check the `process.parent.executable` to confirm if the process was initiated by a legitimate session manager like `/usr/bin/xfce4-session`.
-- Investigate the `destination.ip` field in the network event to identify the external IP address the system attempted to connect to, ensuring it is not within the excluded local IP ranges.
-- Cross-reference the `destination.ip` with threat intelligence sources to determine if it is associated with known malicious activity.
-- Use Osquery to list all XDG autostart entries on the affected host to identify any unauthorized or suspicious entries:
-  ```sql
-  SELECT * FROM xdg_autostart WHERE path LIKE '/etc/xdg/autostart/%' OR path LIKE '~/.config/autostart/%';
-  ```
-- Analyze the contents of any suspicious XDG autostart files identified in the previous step to understand their purpose and potential impact.
-- Review system logs around the time of the alert to identify any other unusual activities or related events that might provide additional context.
-- Check for any recent changes to the XDG autostart files by reviewing file modification timestamps and comparing them with known good baselines.
-- Investigate the user account associated with the login session to determine if it has been compromised or if there are any signs of unauthorized access.
-
-### False positive analysis
-
-- Known false positives may include legitimate applications that initiate network connections upon user login, such as desktop environments or productivity tools that check for updates or sync data.
-- Applications like web browsers or VPN clients that are not included in the exclusion list may trigger alerts if they are set to start automatically and establish network connections.
-- Users can manage these false positives by updating the exclusion list to include additional known benign applications that frequently initiate network connections upon startup.
-- Consider monitoring the frequency and context of the alerts to identify patterns that suggest non-malicious behavior, allowing for more informed decisions on exclusions.
-- Regularly review and update the list of excluded IP ranges and applications to ensure it reflects the current network environment and application usage.
-- Collaborate with IT and security teams to identify any new applications or services that should be added to the exclusion list to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify any unauthorized modifications to XDG autostart entries and associated scripts.
-- Review and analyze network logs to trace the origin and destination of suspicious network connections.
-- Remove or revert any unauthorized changes to XDG autostart entries and scripts to eliminate persistence mechanisms.
-- Update and patch the system to the latest security standards to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Restore the system to its operational state by verifying the integrity of critical system files and configurations.
-- Apply hardening measures such as restricting user permissions, disabling unnecessary services, and implementing application whitelisting."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
index 395d7480cea..d382a433ebc 100644
--- a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -85,49 +85,6 @@ file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Yum Package Manager Plugin File Creation
-
-Yum, a package manager for Fedora-based systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence by executing unauthorized actions whenever Yum is used. The detection rule identifies suspicious file creations in Yum's plugin directories, excluding legitimate processes and temporary files, to flag potential backdoor attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path where the creation or rename event occurred, focusing on paths like `/usr/lib/yum-plugins/*` and `/etc/yum/pluginconf.d/*`.
-- Check the process that triggered the file creation event by examining the `process.executable` field to determine if it matches any known legitimate processes or if it appears suspicious.
-- Investigate the `process.name` field to identify the process responsible for the file creation, ensuring it is not a known benign process like `yumBackend.py`.
-- Verify the file extension using the `file.extension` field to ensure it is not a temporary or swap file (e.g., `.swp`, `.swpx`, `.swx`).
-- Use Osquery to list all files in the Yum plugin directories and check for recent modifications or unusual file names. Example query: `SELECT path, filename, mtime FROM file WHERE path LIKE '/usr/lib/yum-plugins/%' OR path LIKE '/etc/yum/pluginconf.d/%';`
-- Cross-reference the `process.executable` path with known system paths to identify if it originates from unusual locations such as `/nix/store/*` or `/var/lib/dpkg/*`.
-- Examine the file metadata, including creation and modification timestamps, to determine if the timing aligns with any known system changes or updates.
-- Analyze system logs for any related events around the time of the file creation to identify potential unauthorized access or changes.
-- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with typical user behavior.
-- Review any recent changes to Yum configurations or updates that might explain the file creation, ensuring no unauthorized modifications have been made.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger file creation events in Yum's plugin directories, especially when performed by system administrators or automated scripts. Users can manage these by adding exceptions for known safe processes or scripts that regularly perform such actions.
-- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be mistakenly flagged. Users should ensure these extensions are included in the exclusion list to prevent unnecessary alerts.
-- Automation tools like Ansible may create temporary files in these directories, which can be mistaken for suspicious activity. Users can exclude file names starting with ".ansible" or ".ansible_tmp" to reduce false positives.
-- Processes running from specific directories, such as "/nix/store/*" or "/var/lib/dpkg/*", might be part of legitimate package management activities. Users should consider excluding these paths if they are part of regular system operations.
-- Certain system utilities like "sed" or "perl" might create temporary files during normal operations. Users can exclude these processes when they match specific patterns, such as "sed*" or "e2scrub_all.tmp*", to avoid false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the suspicious file creation, focusing on recent changes in the Yum plugin directories.
-- Review system logs and use forensic tools to trace the origin of the unauthorized file creation, paying attention to any unusual processes or user activities.
-- Remove any unauthorized or suspicious files from the Yum plugin directories and restore them from a known good backup if available.
-- Update all system packages and plugins to the latest versions to patch any known vulnerabilities that could have been exploited.
-- Implement strict access controls and permissions for the Yum plugin directories to limit who can create or modify files.
-- Enhance logging policies to include detailed monitoring of file creation and modification events in critical system directories.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat detection capabilities.
-- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if the attack is part of a larger campaign.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to prevent future occurrences."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
index 5e2b3b41415..4937bae0038 100644
--- a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
+++ b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/07/28"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ commands or input containing wildcards (e.g., *, ?, []) to execute unintended op
 tricking the system into interpreting the wildcard characters in unexpected ways.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Unauthorized Access via Wildcard Injection Detected"
@@ -55,56 +57,17 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*"
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+  process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Unauthorized Access via Wildcard Injection Detected
-
-In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse for privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `chown` or `chmod` command execution with the `-R` flag and wildcard references in the `process.args` field.
-- Examine the `process.name` field to verify which command (`chown` or `chmod`) was executed and assess the potential impact based on the command's function.
-- Check the `host.os.type` field to ensure the alert is relevant to a Linux environment, as the rule is designed for Linux systems.
-- Investigate the `event.type` and `event.action` fields to confirm the process was indeed started and executed, indicating the command was run.
-- Analyze the `process.args` field further to identify any specific patterns or anomalies in the arguments that could suggest malicious intent or misuse.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('chown', 'chmod') AND cmdline LIKE '%-R%' AND cmdline LIKE '%--reference=%';` to identify other instances of similar command executions.
-- Review system logs and audit logs for any additional context around the time of the alert to identify any preceding or subsequent suspicious activities.
-- Investigate the user account associated with the process execution to determine if the account has a history of suspicious activity or if it has been compromised.
-- Check for any recent changes in file ownership or permissions on critical files or directories that could indicate successful exploitation.
-- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use `chown` and `chmod` with recursive flags and wildcards for legitimate purposes, such as updating permissions across multiple files or directories. These actions can trigger the rule, leading to false positives.
-- Automated scripts: Scheduled scripts or cron jobs that perform regular maintenance tasks using these commands might also be flagged. These scripts are typically non-threatening if verified as part of standard operations.
-- Software installations or updates: Some software packages or updates may use these commands with wildcards during installation or configuration processes, which can be mistakenly identified as suspicious activity.
-- To manage false positives, users can create exceptions for known safe operations by whitelisting specific scripts, users, or directories that frequently trigger the rule. This can be done by adjusting the detection rule to exclude certain command patterns or by using a monitoring tool's built-in exception handling features.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the wildcard injection attack, reviewing logs and process execution details.
-- Terminate any suspicious processes that are running with elevated privileges or accessing sensitive data.
-- Review and update user permissions and access controls to ensure the principle of least privilege is enforced, reducing the risk of privilege escalation.
-- Apply patches and updates to the operating system and any vulnerable applications to mitigate known exploits, including those related to wildcard injection.
-- Implement enhanced logging policies to capture detailed command execution and process activity, aiding in future investigations.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to monitor for similar threats.
-- Restore the system to its operational state by verifying the integrity of critical files and configurations, and re-establishing network connectivity once secure.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks of wildcard injection and best practices for secure command execution to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_container_util_misconfiguration.toml b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
index c299e757a9f..b5167a53e88 100644
--- a/rules/linux/privilege_escalation_container_util_misconfiguration.toml
+++ b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -77,49 +77,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and 
 process.interactive == true and process.parent.interactive == true
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via Container Misconfiguration
-
-Containers, managed by tools like runc and ctr, isolate applications for security and efficiency. Misconfigurations can allow non-root users to exploit these tools, creating privileged containers or mounting sensitive directories, potentially leading to host system access. The detection rule identifies such misuse by monitoring non-root interactive shell executions of these utilities, flagging potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
-- Verify the user context by examining `user.Ext.real.id` and `group.Ext.real.id` to confirm that the process was executed by a non-root user.
-- Check the `process.interactive` and `process.parent.interactive` fields to ensure the process was initiated through an interactive shell, which might indicate direct user involvement.
-- Investigate the parent process to understand the context of execution by examining `process.parent.name` and `process.parent.args`.
-- Use Osquery to list all running containers and their configurations to identify any suspicious or misconfigured containers. Example query: `SELECT * FROM docker_containers WHERE privileged = 1 OR mount_label LIKE '%root%';`
-- Examine the system logs for any recent changes to container configurations or permissions that might have led to the misconfiguration.
-- Review the user's command history, if available, to identify any previous commands that might indicate attempts to exploit container misconfigurations.
-- Check for any recent user account changes or privilege escalations that could have facilitated unauthorized access to container management utilities.
-- Investigate network activity from the host to identify any unusual outbound connections that might suggest data exfiltration or communication with a command and control server.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Non-root users with legitimate administrative tasks may trigger the rule if they are required to run container management commands interactively. This can occur in development environments where developers have elevated permissions to manage containers without root access.
-- Automated scripts or CI/CD pipelines that execute container commands as non-root users might be flagged if they are designed to run interactively for debugging purposes.
-- Security tools or monitoring solutions that simulate container operations to test system defenses could inadvertently match the rule's criteria if they operate under non-root accounts.
-- To manage these false positives, users can create exceptions by identifying specific user accounts or groups that are known to perform legitimate container operations. This can be done by modifying the detection rule to exclude these users or groups from triggering alerts.
-- Another approach is to refine the rule by adding conditions that check for additional context, such as specific working directories or command-line arguments that are typical of benign operations, to reduce unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential spread to other containers or the host system.
-- Conduct a thorough investigation of the container's configuration and logs to identify the misconfiguration that allowed privilege escalation.
-- Review and analyze the command history and process execution logs to determine the extent of the attack and identify any additional compromised components.
-- Revoke any unauthorized access and reset credentials for any accounts that may have been compromised during the incident.
-- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if sensitive data may have been accessed.
-- Implement enhanced logging policies to capture detailed container activity, including process execution, network connections, and file access, to aid in future investigations.
-- Integrate security monitoring tools with container orchestration platforms to provide real-time alerts on suspicious activities and potential misconfigurations.
-- Restore the affected container to its operational state by redeploying it from a known good image and ensuring all security patches and configurations are up to date.
-- Harden container security by enforcing the principle of least privilege, ensuring that containers run with the minimum necessary permissions and that sensitive directories are not mounted.
-- Regularly review and update container security policies and configurations to align with best practices and mitigate the risk of privilege escalation and container escape attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_dac_permissions.toml b/rules/linux/privilege_escalation_dac_permissions.toml
index 84836cc63c2..3cf2729319a 100644
--- a/rules/linux/privilege_escalation_dac_permissions.toml
+++ b/rules/linux/privilege_escalation_dac_permissions.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -71,50 +71,6 @@ process.command_line:(*sudoers* or *passwd* or *shadow* or */root/*) and not (
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via Linux DAC permissions
-
-Linux Discretionary Access Control (DAC) allows file owners to set permissions, potentially leading to privilege escalation if misconfigured. Adversaries exploit DAC by using processes with capabilities like CAP_DAC_OVERRIDE to bypass permission checks. The detection rule identifies suspicious processes accessing sensitive files, excluding benign activities, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process triggered the rule, focusing on the `process.command_line` field to identify the specific command executed.
-- Check the `process.thread.capabilities.permitted` and `process.thread.capabilities.effective` fields to confirm if the process had CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH capabilities.
-- Investigate the `user.id` field to determine the user context under which the suspicious process was executed, especially if it is not the root user (ID 0).
-- Examine the `process.name` and `process.executable` fields to identify the binary responsible for the execution and verify its legitimacy.
-- Analyze the `process.parent.name` to trace the parent process and understand the process hierarchy, which might provide insights into how the process was initiated.
-- Use Osquery to gather more information about the suspicious process. For example, run the following query to list processes with DAC capabilities: `SELECT pid, name, path, uid, gid, on_disk FROM processes WHERE capabilities LIKE '%CAP_DAC_%';`
-- Investigate the file paths accessed by the process, especially those related to `*sudoers*`, `*passwd*`, `*shadow*`, or `*/root/*`, to determine if any unauthorized changes were made.
-- Cross-reference the timestamps of the alert with system logs to identify any concurrent suspicious activities or anomalies.
-- Check for any recent changes in user permissions or group memberships that might have facilitated the privilege escalation attempt.
-- Review historical data for similar alerts or patterns involving the same user, process, or file paths to assess if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives may include legitimate administrative tasks performed by system administrators or automated scripts that require elevated permissions, such as backup operations or system updates.
-- Processes like "tar", "getent", "su", "stat", "dirname", "chown", "sudo", "dpkg-split", "dpkg-deb", "dpkg", "podman", "awk", "passwd", "dpkg-maintscript-helper", "mutt_dotlock", "nscd", "logger", and "gpasswd" are often used in routine maintenance and can trigger alerts if not excluded.
-- Exclude processes with a user ID of "0" (root) as these are typically expected to have elevated permissions and are less likely to represent a threat.
-- Exclude processes with executables located in paths like /usr/lib/*/lxc/rootfs/*, which are commonly associated with containerized environments and may not pose a risk.
-- Parent processes such as "dpkg", "java", scripts ending in *postinst, "dpkg-preconfigure", and "gnome-shell" can be part of legitimate software installations or updates and should be considered for exclusion.
-- Users can manage false positives by creating exceptions for known benign processes and paths, ensuring that only truly suspicious activities are flagged for further investigation.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the privilege escalation attempt, focusing on the processes flagged by the detection rule.
-- Review and analyze logs from the affected system to determine the extent of the compromise and identify any additional suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Revoke any unauthorized access and reset credentials for compromised accounts, ensuring that all passwords are strong and unique.
-- Restore the system from a known good backup to ensure that any malicious changes are removed.
-- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and detection capabilities.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for privilege escalation.
-- Conduct a security review and harden system configurations by enforcing the principle of least privilege and regularly auditing file permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
index 9d856420012..ea2de502b4b 100644
--- a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
+++ b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/10"
 
 [rule]
 author = ["Elastic"]
@@ -35,48 +35,6 @@ process where host.os.type == "linux" and event.type == "change" and event.actio
 process.entry_leader.entry_meta.type == "container" and process.args == "nsenter" and
 process.args in ("-t", "--target") and process.args_count >= 4
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Docker Escape via Nsenter
-
-Docker containers use namespaces to isolate processes, ensuring they operate independently from the host. The `nsenter` command allows entry into these namespaces, which attackers can exploit to break out of a container and access the host system, potentially escalating privileges. The detection rule identifies suspicious UID changes involving `nsenter` within containers, signaling possible escape attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a UID change event involving `nsenter` within a container, as indicated by the query fields `event.type == "change"` and `event.action == "uid_change"`.
-- Verify the process context by examining `process.entry_leader.entry_meta.type` to ensure the event originated from a containerized environment.
-- Check the command-line arguments of the process using `process.args` to confirm the use of `nsenter` with the `-t` or `--target` options, which are indicative of namespace entry attempts.
-- Analyze the `process.args_count` to ensure it meets or exceeds 4, suggesting a potentially complex command that might be used for container escape.
-- Investigate the parent process and its command-line arguments to understand the context in which `nsenter` was executed, which might provide insights into the attacker's intentions.
-- Use Osquery to gather additional context about the container and host environment. For example, run the following query to list all running containers and their associated namespaces: `SELECT * FROM docker_containers JOIN docker_namespace ON docker_containers.id = docker_namespace.id;`
-- Examine the user and group context of the process by reviewing the UID and GID before and after the change to assess the potential impact of the privilege escalation.
-- Correlate the event with other logs and alerts from the same timeframe to identify any related suspicious activities or patterns that might indicate a broader attack.
-- Investigate the network activity associated with the container and host during the time of the alert to detect any unauthorized data exfiltration or lateral movement attempts.
-- Review historical data for similar events involving `nsenter` to determine if this is an isolated incident or part of a recurring pattern, which could indicate a persistent threat.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use `nsenter` for legitimate purposes, such as debugging or managing containers. These actions can trigger the rule, leading to false positives. To manage this, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
-- Monitoring and logging tools: Some monitoring or logging tools might use `nsenter` to gather metrics or logs from containers. These tools can be identified and excluded by specifying their process names or paths in the rule exceptions.
-- Automated scripts: Automated scripts or orchestration tools that manage container lifecycles might use `nsenter` as part of their operations. Users should identify these scripts and exclude their specific command patterns or execution contexts to reduce false positives.
-- Development and testing environments: In development or testing environments, developers might frequently use `nsenter` for testing purposes. Users can exclude specific environments or IP ranges from the rule to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the network.
-- Conduct a thorough investigation to determine the extent of the breach, focusing on identifying any unauthorized access to the host system and any changes made.
-- Review logs and audit trails to trace the attacker's actions and identify any other potentially compromised containers or systems.
-- Escalate the incident to the security operations team and, if necessary, involve legal and compliance teams to assess any regulatory implications.
-- Remediate the affected systems by removing any unauthorized changes, patching vulnerabilities, and restoring systems from clean backups if necessary.
-- Implement enhanced logging and monitoring for container activities, specifically focusing on namespace entry attempts and UID changes.
-- Integrate security tools with SIEM systems to improve detection capabilities and automate alerting for similar incidents in the future.
-- Review and update container security policies, ensuring that least privilege principles are enforced and unnecessary capabilities are removed.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate and train staff on the latest container security best practices and threat detection techniques to prevent future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
index 49a2f1e3c6c..fac9264d2f0 100644
--- a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
+++ b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2024/01/15"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ within a container is capable of mounting the root file system of the host, and
 containarized environment. This behavior pattern is very uncommon and should be investigated.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Chroot Container Escape via Mount"
@@ -64,61 +66,18 @@ tags = [
     "Tactic: Privilege Escalation",
     "Domain: Container",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 type = "eql"
 
 query = '''
 sequence by host.id, process.parent.entity_id with maxspan=5m
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.name == "mount" and process.args : "/dev/sd*" and process.args_count >= 3 and
    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")]
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.name == "chroot"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Chroot Container Escape via Mount
-
-Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for a mount command followed by a chroot execution, indicating a potential escape attempt.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the sequence of events, focusing on the `host.id` and `process.parent.entity_id` to ensure the events are related and occurred within the specified `maxspan=5m`.
-- Examine the `process.args` field of the mount command to identify the specific device or file system being mounted, especially looking for `/dev/sd*` patterns that suggest host file system access.
-- Check the `process.parent.name` to determine the shell used to execute the mount command, which can provide context on how the command was initiated.
-- Investigate the user account associated with the processes to determine if the user had legitimate reasons to perform these actions and if they have the necessary permissions.
-- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes executed by the same user within a short time frame: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <chroot_process_id>);`
-- Analyze the system logs around the time of the alert to identify any other suspicious activities or anomalies that might correlate with the escape attempt.
-- Check for any recent changes in user permissions or group memberships that might have inadvertently granted the necessary privileges for such an escape attempt.
-- Review the container's configuration and security settings to assess if there are any misconfigurations that could have facilitated the escape attempt.
-- Investigate any network connections initiated by the container around the time of the alert to identify potential data exfiltration or communication with external systems.
-- Correlate the findings with other security tools and logs to determine if this is an isolated incident or part of a broader attack pattern.
-
-### False positive analysis
-
-- System administrators or automated scripts may perform legitimate maintenance tasks that involve mounting file systems and using chroot, such as during system recovery or software installation, which could trigger this rule.
-- Backup or recovery operations that require mounting and chrooting into different file systems for data retrieval or restoration purposes might be flagged as false positives.
-- Developers or DevOps engineers working on containerized applications might use mount and chroot commands during testing or debugging processes, leading to benign alerts.
-- To manage these false positives, users can create exceptions for known maintenance scripts or processes by excluding specific parent process names or command arguments that are regularly used in non-threatening operations.
-- Implementing a whitelist of trusted users or processes that are known to perform these actions as part of their routine tasks can help reduce unnecessary alerts.
-- Regularly reviewing and updating the detection rule to align with the organization's operational patterns and known safe behaviors can help minimize false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the network.
-- Investigate the container's logs and process history to identify the source and method of the escape attempt, focusing on the sequence of mount and chroot commands.
-- Verify the permissions and roles assigned to the user or process that attempted the escape to ensure they are appropriate and not overly permissive.
-- Escalate the incident to the security operations team if unauthorized access to the host system is confirmed, as this may indicate a broader security breach.
-- Remediate by removing any unauthorized changes made to the host system and restoring the container to a known good state from a secure backup.
-- Implement enhanced logging policies to capture detailed command execution and file system changes within containers for future investigations.
-- Integrate security monitoring tools with SIEM systems to correlate events and detect similar escape attempts across the environment.
-- Review and update container security policies to enforce stricter isolation and limit the use of potentially dangerous commands like mount and chroot.
-- Conduct a post-incident review to identify gaps in the current security posture and develop a plan to address them, including user training and awareness.
-- Apply hardening measures such as using read-only file systems for containers, employing namespaces, and leveraging security modules like SELinux or AppArmor to restrict container capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_enlightenment_window_manager.toml b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
index 87c58530cb6..facebb25242 100644
--- a/rules/linux/privilege_escalation_enlightenment_window_manager.toml
+++ b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -62,48 +62,6 @@ sequence by host.id, process.parent.entity_id with maxspan=5s
     process.name == "enlightenment_sys" and process.args in ("/bin/mount/", "-o","noexec","nosuid","nodev","uid=*") ]
   [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via Enlightenment
-
-Enlightenment, a Linux window manager, can be exploited for privilege escalation due to a flaw in its setuid root binary, enlightenment_sys. Attackers exploit this by manipulating pathnames, gaining unauthorized root access. The detection rule identifies this by monitoring specific process executions and subsequent unauthorized user ID changes, flagging potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and process.parent.entity_id associated with the suspicious activity, ensuring you have the correct context for the investigation.
-- Verify the process execution by checking the process.name and process.args fields to confirm that the process "enlightenment_sys" was executed with the specific arguments ("/bin/mount/", "-o", "noexec", "nosuid", "nodev", "uid=*").
-- Investigate the timeline of events by examining the sequence of process executions and user ID changes within the maxspan of 5 seconds to identify any anomalies or patterns.
-- Check the user.id field to confirm if there was an unauthorized change to user ID "0", indicating a potential privilege escalation attempt.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'enlightenment_sys';` to retrieve details about the process, including its parent process, user, and execution path.
-- Investigate the parent process of "enlightenment_sys" using the process.parent.entity_id to understand the origin of the execution and whether it was initiated by a legitimate or suspicious process.
-- Examine system logs for any additional context around the time of the alert, focusing on authentication logs and any other security-related logs that might indicate unauthorized access attempts.
-- Review the system's history of privilege escalation attempts by searching for similar patterns or alerts in the past, which might indicate a recurring issue or targeted attack.
-- Analyze the host's environment for any recent changes or anomalies, such as new software installations or configuration changes, that could have facilitated the exploitation attempt.
-- Cross-reference the alert with known threat intelligence sources to determine if the activity matches any known attack patterns or threat actor behaviors associated with CVE-2022-37706.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may execute the `enlightenment_sys` binary with specific arguments for maintenance or configuration purposes, which could trigger the detection rule. To manage this, users can create exceptions for known administrative scripts or processes that regularly perform these tasks.
-- Automated scripts: Some automated scripts or system management tools might use `enlightenment_sys` for legitimate operations, leading to false positives. Users should identify these scripts and whitelist them to prevent unnecessary alerts.
-- Testing environments: In environments where security testing or development is conducted, the execution of `enlightenment_sys` with root privileges might be part of routine testing. Users can exclude specific testing environments or IP ranges from the rule to reduce false positives.
-- System updates: During system updates, certain processes might temporarily mimic the behavior flagged by the rule. Users should monitor update schedules and consider temporary exceptions during these periods to avoid false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the exploitation by reviewing logs and correlating events with the detection rule, focusing on unauthorized user ID changes and suspicious process executions.
-- If exploitation is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Remove or disable the vulnerable version of Enlightenment (before 0.25.4) and replace it with the latest patched version to mitigate the vulnerability.
-- Review and update system and application logging policies to ensure comprehensive coverage of process executions, user ID changes, and other relevant security events.
-- Implement additional security monitoring and alerting for similar privilege escalation attempts, leveraging MITRE ATT&CK framework techniques such as T1068 for context.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure no unauthorized changes persist.
-- Conduct a post-incident review to identify gaps in detection and response, and update incident response plans accordingly.
-- Enhance system hardening by applying the principle of least privilege, ensuring that only necessary permissions are granted to users and processes.
-- Consider integrating additional security tools and technologies, such as endpoint detection and response (EDR) solutions, to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
index 6ef74ffde34..10697c46f3a 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -64,48 +64,6 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=1m
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.name != null and user.id == "0"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privilege Escalation via GDB CAP_SYS_PTRACE
-
-The CAP_SYS_PTRACE capability in Linux allows processes to trace and control other processes, a feature primarily used for debugging. Adversaries can exploit this by using GDB with this capability to inject code into processes running as root, thereby escalating privileges. The detection rule identifies such abuse by monitoring sequences where GDB is executed with CAP_SYS_PTRACE, followed by a process running as root, indicating potential privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of GDB execution with CAP_SYS_PTRACE capability by checking the `process.name` and `process.thread.capabilities.effective` or `process.thread.capabilities.permitted` fields.
-- Verify the sequence of events by examining the `host.id` and `process.entry_leader.entity_id` to ensure the alert is not a false positive due to unrelated processes.
-- Check the `user.id` field to confirm that the process was executed by a non-root user before the privilege escalation attempt.
-- Investigate the parent process of GDB using the `process.parent.name` and `process.parent.pid` fields to understand the context in which GDB was executed.
-- Use Osquery to list all processes with CAP_SYS_PTRACE capability by running: `SELECT pid, name, uid, gid, capabilities FROM processes WHERE capabilities LIKE '%CAP_SYS_PTRACE%';`
-- Examine the command line arguments of the GDB process using the `process.args` field to identify any suspicious or unusual parameters that might indicate malicious intent.
-- Review the timeline of events around the alert using the `@timestamp` field to identify any other suspicious activities or anomalies occurring concurrently.
-- Check the system logs for any unauthorized access attempts or anomalies around the time of the alert to gather additional context.
-- Investigate the user account associated with the alert by reviewing the `user.id` and `user.name` fields to determine if the account has been compromised or is behaving unusually.
-- Correlate the findings with other security tools and logs to identify any patterns or indicators of compromise that align with the privilege escalation attempt.
-
-### False positive analysis
-
-- Development and debugging activities: Developers and system administrators may use GDB with CAP_SYS_PTRACE for legitimate debugging purposes, which can trigger the detection rule. To manage this, users can create exceptions for specific user accounts or processes that are known to perform regular debugging tasks.
-- Automated testing environments: In environments where automated testing frameworks utilize GDB for testing applications, the rule may generate false positives. Users can handle these by excluding specific testing processes or environments from the rule.
-- Security tools and monitoring software: Some security tools may use GDB with CAP_SYS_PTRACE as part of their monitoring or analysis functions. Users should identify and whitelist these tools to prevent false positives.
-- System maintenance scripts: Scheduled maintenance scripts that require debugging capabilities might inadvertently trigger the rule. Users can exclude these scripts by specifying their process names or execution times in the rule exceptions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the presence of unauthorized processes or code injections by reviewing process trees and system logs for anomalies.
-- Terminate any suspicious processes that are running with elevated privileges and were not initiated by legitimate users or administrators.
-- Conduct a thorough investigation to identify the source of the privilege escalation attempt, including reviewing user activity logs and access records.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Restore the system to a known good state by reverting to a clean backup or reinstalling the operating system if necessary.
-- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that CAP_SYS_PTRACE usage is monitored.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve visibility and detection capabilities.
-- Apply system hardening measures, such as removing unnecessary capabilities from processes, enforcing the principle of least privilege, and regularly updating software to patch vulnerabilities.
-- Educate users and administrators on the risks associated with debugging tools and the importance of maintaining secure configurations to prevent privilege escalation attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
index d3ae3ba7112..68dcaefd123 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -66,52 +66,6 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=30s
   [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
    process.name != null and user.id == "0"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Root Network Connection via GDB CAP_SYS_PTRACE
-
-GDB, a debugger, can be granted the CAP_SYS_PTRACE capability, allowing it to trace and control processes, a feature often exploited by attackers. By injecting code into root processes, adversaries can execute malicious payloads, such as reverse shells. The detection rule identifies this by monitoring GDB executions with CAP_SYS_PTRACE followed by root-initiated network connections, signaling potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of GDB execution with CAP_SYS_PTRACE capability and subsequent root-initiated network connection.
-- Verify the process entry leader entity ID and host ID to ensure the sequence of events occurred on the same host and process context.
-- Check the timestamp of the GDB execution and the network connection attempt to confirm they fall within the 30-second maxspan window.
-- Investigate the user context by examining the user ID associated with the GDB process to ensure it is not root (user.id != "0").
-- Use Osquery to list all processes with CAP_SYS_PTRACE capability on the host to identify any other potentially suspicious processes:
-  ```sql
-  SELECT pid, name, uid, gid, path FROM processes WHERE capabilities LIKE '%CAP_SYS_PTRACE%';
-  ```
-- Analyze the network connection details, including destination IP and port, to determine if the connection is to a known malicious or suspicious address.
-- Review the process tree to identify the parent process of GDB and any child processes spawned, which may provide insight into how GDB was executed.
-- Check system logs for any unusual activity or errors around the time of the alert to gather additional context.
-- Investigate the binary and hash of the GDB executable to ensure it has not been tampered with or replaced by a malicious version.
-- Correlate with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Development and debugging activities: Developers often use GDB with CAP_SYS_PTRACE for legitimate debugging purposes, which may trigger the rule when a root process initiates a network connection as part of normal operations. Users can handle these by creating exceptions for known development environments or specific user accounts frequently involved in debugging.
-- Automated system maintenance scripts: Some automated scripts running with root privileges might use GDB for monitoring or maintenance tasks, leading to false positives. Identifying and excluding these scripts from monitoring can reduce unnecessary alerts.
-- Security tools and monitoring software: Certain security tools may use GDB with CAP_SYS_PTRACE to monitor processes for security purposes, which could be misinterpreted as malicious activity. Users should whitelist these tools to prevent false positives.
-- Testing environments: In testing environments, GDB might be used extensively to simulate various scenarios, including network connections by root processes. Users can exclude specific testing environments or IP ranges to minimize false alerts.
-- Custom applications: Organizations may have custom applications that legitimately use GDB with CAP_SYS_PTRACE for process management or debugging. Users should document and exclude these applications from the rule to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement.
-- Conduct a thorough investigation to confirm the presence of malicious activity by reviewing logs and identifying any unauthorized use of GDB with CAP_SYS_PTRACE.
-- Terminate any suspicious processes initiated by GDB and any unauthorized network connections to mitigate ongoing threats.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Review and analyze system logs, including process execution and network connection logs, to identify any additional indicators of compromise (IOCs) or related malicious activities.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that CAP_SYS_PTRACE usage is monitored closely.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Restore the system to a known good state by reinstalling the operating system and applications, ensuring all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting the use of CAP_SYS_PTRACE to trusted users and processes, and regularly auditing system capabilities and permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_kworker_uid_elevation.toml b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
index 75b9e3b6812..f17fb467fd1 100644
--- a/rules/linux/privilege_escalation_kworker_uid_elevation.toml
+++ b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -64,51 +64,6 @@ query = '''
 process where host.os.type == "linux" and event.action == "session_id_change" and process.name : "kworker*" and
 user.id == "0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Kworker UID Elevation
-
-Kworker processes are integral to Linux, handling tasks like interrupts and background activities in kernel space. Adversaries may exploit these by masquerading as kworker processes to gain root access, often using rootkits to hijack execution flow. The detection rule identifies such abuse by monitoring for kworker processes that change session IDs and elevate user permissions to root, signaling potential privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name matches "kworker*" and the user ID is "0", indicating a potential privilege escalation.
-- Check the session ID change event to determine the previous and new session IDs, which can provide context on the session transition.
-- Investigate the parent process of the kworker process to identify if it was spawned by a legitimate kernel process or an unexpected user-space process.
-- Use Osquery to list all running kworker processes and their associated user IDs to identify any discrepancies or anomalies:
-  ```sql
-  SELECT pid, name, uid, parent FROM processes WHERE name LIKE 'kworker%';
-  ```
-- Examine the process tree to trace the lineage of the suspicious kworker process and identify any unusual parent-child relationships.
-- Analyze recent system logs for any unusual activities or errors around the time of the session ID change event to gather additional context.
-- Check for any recent modifications to kernel modules or system binaries that could indicate the presence of a rootkit.
-- Review user login and authentication logs to identify any unauthorized access attempts or successful logins around the time of the alert.
-- Investigate network activity from the host to detect any suspicious outbound connections that could indicate data exfiltration or command-and-control communication.
-- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Legitimate system maintenance tasks or updates may trigger session ID changes in kworker processes, leading to false positives. Users can monitor the timing of these alerts to correlate with scheduled maintenance activities and create exceptions for these periods.
-- Custom kernel modules or drivers that interact with kworker processes might inadvertently cause session ID changes. Users should review and whitelist known safe modules or drivers that are part of their standard operating environment.
-- Certain security tools or monitoring solutions may interact with kworker processes for legitimate reasons, causing session ID changes. Users should identify these tools and configure the detection rule to exclude their activity by specifying process names or user IDs associated with these tools.
-- In environments with automated scripts or cron jobs that require elevated permissions, kworker processes might be used as part of the execution flow. Users should document these scripts and create exceptions for their associated kworker activities to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the presence of a rootkit by analyzing system logs, process trees, and any anomalous behavior associated with kworker processes.
-- Utilize forensic tools to capture memory and disk images for detailed analysis and evidence preservation.
-- If a rootkit is confirmed, perform a full system scan using updated antivirus and anti-malware tools to identify and remove malicious components.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Restore the system from a known good backup to ensure all malicious modifications are removed, and verify the integrity of the restored system.
-- Implement enhanced logging policies to capture detailed process execution and user activity, focusing on session ID changes and privilege escalations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Review and update access controls and user permissions to minimize the risk of privilege escalation, ensuring the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in the current security posture and apply hardening measures, such as kernel module signing and regular integrity checks, to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
index 3f2fb6fa356..c1188e26d75 100644
--- a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
+++ b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -73,51 +73,6 @@ query = '''
 host.os.type:linux and event.category:file and event.action:(updated or renamed or rename or file_rename_event) and 
 not event.type:deletion and file.path:/etc/ld.so.preload and not process.name:(wine or oneagentinstallaction)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Dynamic Linker Preload Shared Object
-
-The dynamic linker preload mechanism in Linux, controlled via `/etc/ld.so.preload`, allows preloading of shared libraries before others. Adversaries exploit this by inserting malicious libraries, hijacking execution flow for privilege escalation. The detection rule monitors changes to this file, excluding benign processes, to identify unauthorized modifications indicative of such abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path involved is `/etc/ld.so.preload` and verify the event action is either `updated`, `renamed`, or `file_rename_event`.
-- Check the `process.name` field to ensure the process responsible for the modification is not `wine` or `oneagentinstallaction`, as these are excluded from the rule.
-- Investigate the `host.os.type` field to confirm the operating system is Linux, as this rule is specific to Linux environments.
-- Use Osquery to list the current contents of `/etc/ld.so.preload` to identify any suspicious or unexpected libraries being preloaded:
-  ```sql
-  SELECT * FROM file WHERE path = '/etc/ld.so.preload';
-  ```
-- Examine the `event.category` field to ensure it is categorized as a `file` event, confirming the nature of the alert.
-- Investigate the process that made the modification by checking the process ID and command line arguments to understand the context of the change.
-- Review recent system logs and audit logs around the time of the modification for any additional suspicious activity or related events.
-- Check the user account associated with the process that modified the file to determine if it has the necessary privileges and if the activity aligns with normal behavior for that account.
-- Investigate any recent changes in user permissions or group memberships that could have allowed unauthorized access to modify `/etc/ld.so.preload`.
-- Correlate this event with other alerts or anomalies in the environment to identify potential patterns or coordinated activities that could indicate a broader attack.
-
-### False positive analysis
-
-- Routine system updates or legitimate software installations may modify `/etc/ld.so.preload`, triggering the detection rule. Users can handle these by creating exceptions for known update processes or installation scripts.
-- Security tools or monitoring agents, such as OneAgent, may interact with the preload file as part of their normal operations. Exclude these processes by adding them to the exception list in the detection rule.
-- Custom scripts or administrative tasks performed by system administrators might also lead to modifications. Ensure these activities are documented and consider excluding specific scripts or user actions if they are verified as non-threatening.
-- In environments using Wine, the process may interact with the preload file, leading to false positives. Exclude the Wine process from the detection rule to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the unauthorized modification, focusing on recent changes and user activity logs.
-- Verify the integrity of the `/etc/ld.so.preload` file by comparing it with a known good backup or baseline configuration.
-- Remove any unauthorized or suspicious entries from the `/etc/ld.so.preload` file and restore it to its original state.
-- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious payloads.
-- Review user accounts and privileges on the system to ensure no unauthorized access or privilege escalation has occurred.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging and monitoring for critical system files and processes, including `/etc/ld.so.preload`, to detect future unauthorized modifications.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate events across the network.
-- Apply system hardening measures, such as restricting write access to critical files and directories, and regularly update and patch the system to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
index f1d89da9a2f..f1192e1a86d 100644
--- a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
+++ b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/30"
 
 [rule]
 author = ["Elastic"]
@@ -77,49 +77,6 @@ process.name == "ln" and process.args in ("-s", "-sf") and
   process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
   not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Symbolic Link Created
-Symbolic links in Linux are shortcuts that point to files or directories, facilitating easy access. Adversaries exploit them to redirect privileged processes to sensitive files, potentially escalating privileges. The detection rule identifies such abuse by monitoring the creation of symbolic links to critical files or directories, especially when executed by non-root users, indicating possible malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific symbolic link creation event, focusing on the `process.name`, `process.args`, and `process.working_directory` fields to understand the context of the command executed.
-- Verify the user context by examining the `user.Ext.real.id` and `group.Ext.real.id` fields to confirm that the action was performed by a non-root user, which could indicate potential privilege escalation attempts.
-- Check the parent process information using the `process.parent.name` field to determine if the symbolic link creation was initiated from a shell, which might suggest a script or manual command execution.
-- Investigate the target of the symbolic link by reviewing the `process.args` field to identify if it points to any critical files or directories, such as `/etc/shadow` or `/bin/bash`.
-- Use Osquery to list all symbolic links in the system and their targets to identify any other potentially malicious links. Example query: `SELECT * FROM file WHERE type = 'symlink';`
-- Examine the user's command history, if available, to identify any preceding commands that might provide context or indicate malicious intent.
-- Review system logs around the time of the event for any other suspicious activities or related events that could provide additional context.
-- Check for any recent changes to the files or directories targeted by the symbolic link to assess if any unauthorized modifications have occurred.
-- Investigate the user's recent login activity and source IP addresses to determine if there are any anomalies or indications of unauthorized access.
-- Correlate this event with other alerts or incidents involving the same user or system to identify patterns or ongoing attack campaigns.
-
-### False positive analysis
-
-- System administrators or automated scripts may create symbolic links to critical files for legitimate purposes, such as backups or system maintenance, which can trigger false positives.
-- Development environments might use symbolic links to manage dependencies or configurations, especially in shared directories, leading to benign alerts.
-- Some software installations or updates might create symbolic links to binaries or configuration files as part of their setup process, which could be misinterpreted as suspicious activity.
-- To manage these false positives, users can create exceptions for known benign processes or users by excluding specific user IDs or process names that are verified as non-threatening.
-- Implementing a whitelist of trusted directories or files that are frequently linked in a non-malicious context can help reduce unnecessary alerts.
-- Regularly review and update the detection rule to accommodate changes in legitimate system behavior, ensuring that only truly suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Investigate the symbolic link creation event by reviewing logs and process details to identify the source and intent of the action.
-- Verify the integrity of critical files and directories, such as /etc/shadow and /etc/sudoers, to ensure they have not been tampered with.
-- Remove any unauthorized symbolic links and restore any altered files from a known good backup.
-- Conduct a thorough review of user accounts and permissions, focusing on non-root users who executed the suspicious command, to identify potential privilege escalation paths.
-- Escalate the incident to the security operations team if evidence of privilege escalation or further compromise is found.
-- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate security tools with SIEM solutions to automate the detection of suspicious symbolic link creation and other privilege escalation attempts.
-- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all security controls are active and functioning.
-- Harden the system by implementing least privilege principles, restricting the use of symbolic links, and regularly auditing critical system files and directories."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
index 2661bbe3cc6..d628bd94d5b 100644
--- a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
+++ b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
@@ -1,6 +1,6 @@
 [metadata]
 creation_date = "2023/07/27"
-integration = ["endpoint"]
+integration = ["endpoint", "crowdstrike"]
 maturity = "production"
 updated_date = "2025/01/08"
 
@@ -12,7 +12,7 @@ allowed UID size (INT_MAX). Some older Linux versions were affected by a bug whi
 greater than INT_MAX to escalate privileges by spawning a shell through systemd-run.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Privilege Escalation via UID INT_MAX Bug Detected"
@@ -56,56 +56,16 @@ tags = [
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and 
-process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000"
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "ProcessRollup2") and
+  process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via UID INT_MAX Bug Detected
-
-In certain Linux environments, a bug in older versions allows users with a UID exceeding INT_MAX to gain elevated privileges by executing commands via systemd-run. Adversaries exploit this by spawning privileged shells, bypassing standard security controls. The detection rule identifies such exploitation attempts by monitoring systemd-run executions with unusually high UIDs, signaling potential privilege escalation activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a UID greater than INT_MAX, specifically checking the `user.id` field to ensure it meets the threshold of "1000000000" or higher.
-- Examine the `process.name` and `process.args` fields to verify that the command executed was indeed `systemd-run` with the `-t` argument, indicating an attempt to spawn a shell.
-- Check the `event.type` and `event.action` fields to confirm that the event was a process start and involved execution, aligning with the conditions specified in the detection rule.
-- Investigate the user account associated with the high UID by querying the `/etc/passwd` file to gather more information about the account, such as its creation date and any associated comments.
-- Use Osquery to list all processes started by the suspicious UID to identify any other potentially malicious activities. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE uid = <suspicious_uid>;`
-- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any unusual login attempts or authentication failures associated with the high UID.
-- Review the systemd service logs using `journalctl` to trace the execution history of `systemd-run` commands and identify any patterns or anomalies.
-- Check for any recent changes to user accounts or group memberships that might indicate unauthorized modifications, using commands like `getent passwd` and `getent group`.
-- Investigate network activity from the host to identify any suspicious outbound connections or data exfiltration attempts that might correlate with the privilege escalation attempt.
-- Correlate the findings with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign or an isolated incident.
-
-### False positive analysis
-
-- Users with legitimate high UIDs: In some organizations, system administrators may assign high UIDs for specific service accounts or applications, which could trigger the rule. To manage this, create exceptions for known service accounts by adding their UIDs to an exclusion list.
-- Testing environments: Developers or security teams might intentionally use high UIDs in testing environments to simulate attacks or test system responses. These activities can be excluded by filtering out events from designated testing servers or environments.
-- Legacy systems: Some older systems might have configurations that inadvertently assign high UIDs to certain users. Review and update these configurations to prevent unnecessary alerts, or exclude these systems from the rule if they are known to be non-threatening.
-- Automated scripts: Scripts that require elevated privileges might be configured to use high UIDs for execution. Identify and document these scripts, then exclude their associated UIDs from the detection rule to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
-- Verify the UID of the user executing the systemd-run command and confirm if it exceeds INT_MAX, indicating potential exploitation.
-- Conduct a thorough investigation of the affected system to identify any unauthorized changes or additional malicious activities, focusing on processes and files accessed by the high UID user.
-- Review system logs and security alerts to trace the origin of the attack and identify any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a broader campaign.
-- Apply patches or updates to the affected system to address the UID INT_MAX bug, ensuring all systems are running supported and secure versions of Linux.
-- Implement enhanced logging policies to capture detailed information on process executions, user activities, and system changes, aiding future investigations.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve monitoring and detection capabilities.
-- Restore the system to its operational state by removing any unauthorized changes, verifying system integrity, and re-enabling network connectivity once secure.
-- Harden the system by enforcing least privilege access controls, regularly reviewing user accounts and permissions, and conducting security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
index f225536eb41..57cab49ea6a 100644
--- a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
+++ b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/06/09"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -14,7 +16,7 @@ escalate privileges, establish persistence or hide their activities by loading a
 tamper with the system's trusted state, allowing e.g. a VM Escape.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Kernel Load or Unload via Kexec Detected"
@@ -61,56 +63,17 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name == "kexec" and process.args in ("--exec", "-e", "--load", "-l", "--unload", "-u") and not
- process.parent.name in ("kdumpctl", "unload.sh")
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+  process.name == "kexec" and process.args in ("--exec", "-e", "--load", "-l", "--unload", "-u") and
+  not process.parent.name in ("kdumpctl", "unload.sh")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kernel Load or Unload via Kexec Detected
-
-Kexec is a Linux utility that allows a new kernel to be loaded and executed without rebooting, facilitating quick kernel updates. However, attackers can exploit kexec to load malicious kernels, bypassing security controls and gaining unauthorized access or persistence. The detection rule identifies suspicious kexec usage by monitoring process execution patterns, focusing on specific arguments and excluding legitimate parent processes, thus highlighting potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the kexec process execution with suspicious arguments such as "--exec", "-e", "--load", "-l", "--unload", or "-u".
-- Verify the parent process of the kexec execution to ensure it is not a legitimate process like "kdumpctl" or "unload.sh", which are excluded in the detection rule.
-- Check the user account associated with the kexec process execution to determine if it has the necessary privileges and if the activity aligns with their typical behavior.
-- Investigate the command line arguments used with the kexec process to understand the intent and scope of the kernel load or unload operation.
-- Use Osquery to gather additional context about the kexec process by running a query such as: `SELECT * FROM processes WHERE name = 'kexec';` to retrieve details like process ID, parent process ID, and execution path.
-- Examine system logs and audit logs for any related entries around the time of the kexec execution to identify any preceding or subsequent suspicious activities.
-- Analyze network traffic logs to detect any unusual outbound connections or data exfiltration attempts that might coincide with the kexec activity.
-- Check for any recent changes to kernel modules or system configurations that could indicate tampering or unauthorized modifications.
-- Investigate other processes running on the system that might have been initiated by the same user or parent process to identify potential lateral movement or further compromise.
-- Correlate the kexec activity with other security alerts or incidents in the environment to determine if it is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate system maintenance activities: System administrators may use kexec for legitimate kernel updates or system maintenance tasks. These activities can trigger the detection rule if they involve the specified arguments. To manage this, users can create exceptions for known maintenance scripts or processes by adding them to the exclusion list of parent processes.
-- Automated backup or recovery processes: Some automated scripts or tools, such as kdumpctl, may use kexec as part of their normal operation for system recovery or backup purposes. These should be excluded by verifying the parent process and adding it to the exclusion list if deemed non-threatening.
-- Custom scripts for performance testing: Developers or system engineers might use custom scripts that leverage kexec for performance testing or system optimization. Users should review these scripts and, if they are verified as safe, add them to the list of exceptions to prevent false positives.
-- Security tools or monitoring solutions: Certain security tools might use kexec to test system resilience or for other security-related tasks. Users should identify these tools and exclude them from the detection rule by specifying their parent processes in the exclusion criteria.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the presence of a malicious kernel by analyzing system logs, process trees, and any anomalies in kernel behavior.
-- Utilize forensic tools to capture memory and disk images for further analysis and evidence preservation.
-- If a malicious kernel is confirmed, initiate a system recovery process by restoring from a known good backup or reinstalling the operating system.
-- Review and update security policies to restrict the use of kexec to authorized personnel only, potentially disabling it if not required for operational purposes.
-- Implement enhanced logging and monitoring for kexec usage and other critical system processes to detect future unauthorized activities.
-- Integrate security solutions such as intrusion detection systems (IDS) and endpoint detection and response (EDR) tools to improve threat visibility and response capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply system hardening measures, such as enabling secure boot, applying the latest security patches, and configuring kernel parameters to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
index a971b99b697..75d12aa5a97 100644
--- a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
+++ b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -74,48 +74,6 @@ sequence by host.id, process.parent.entity_id, process.executable with maxspan=5
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
   process.env_vars : "*GLIBC_TUNABLES=glibc.*=glibc.*=*"] with runs=5
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via CVE-2023-4911
-
-CVE-2023-4911 exploits a buffer overflow in the GNU C Library's dynamic loader, specifically targeting the GLIBC_TUNABLES environment variable. This vulnerability allows attackers to manipulate memory, potentially escalating privileges. The detection rule identifies suspicious activity by monitoring Linux processes for specific environment variable patterns, flagging rapid, repeated execution attempts indicative of exploitation efforts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the GLIBC_TUNABLES environment variable pattern in the process execution, as indicated by the query.
-- Identify the host and process information from the alert, focusing on `host.id`, `process.parent.entity_id`, and `process.executable` fields to understand which system and application are involved.
-- Check the frequency and timing of the alert by examining the `maxspan=5s` and `runs=5` parameters to determine if the execution attempts are rapid and repeated, suggesting exploitation.
-- Use Osquery to list all processes on the affected host that have the GLIBC_TUNABLES environment variable set. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%GLIBC_TUNABLES=glibc%'`.
-- Investigate the parent process (`process.parent.entity_id`) to determine if it is a legitimate process or potentially compromised, which could indicate how the exploit was initiated.
-- Analyze the `process.executable` path to verify if it is a known and trusted application or if it has been tampered with or replaced.
-- Cross-reference the alert with any recent changes or updates on the affected host that might have introduced the vulnerability or been exploited.
-- Check system logs and audit logs on the affected host for any unusual activity or errors related to the dynamic loader or GLIBC_TUNABLES environment variable.
-- Investigate network activity from the affected host around the time of the alert to identify any suspicious outbound connections or data exfiltration attempts.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack campaign or isolated incident.
-
-### False positive analysis
-
-- Known false positives for the CVE-2023-4911 detection rule may arise from legitimate applications or scripts that frequently set the GLIBC_TUNABLES environment variable for performance tuning or compatibility reasons. These applications might trigger the rule due to their rapid execution patterns, which mimic exploitation attempts.
-- System administrators can manage these false positives by identifying and documenting legitimate processes that use GLIBC_TUNABLES. Once identified, these processes can be excluded from the detection rule by creating exceptions based on specific process names, paths, or other unique identifiers.
-- Another approach to handle false positives is to adjust the detection rule's sensitivity by increasing the threshold for the number of rapid executions or extending the time window (maxspan) to better differentiate between benign and malicious activities.
-- Regularly reviewing and updating the list of exceptions is crucial, as software updates or changes in system configurations might alter the behavior of legitimate applications, potentially leading to new false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to confirm the presence of CVE-2023-4911 exploitation by reviewing logs and correlating with the detection rule's findings.
-- Terminate any suspicious processes identified as exploiting the GLIBC_TUNABLES environment variable to halt ongoing attacks.
-- Apply the latest security patches and updates to the GNU C Library to mitigate the vulnerability.
-- Restore the system from a known good backup taken before the exploitation occurred to ensure system integrity.
-- Implement enhanced logging policies to capture detailed process execution and environment variable changes for future analysis.
-- Integrate security solutions with SIEM systems to improve detection capabilities and automate alerting for similar threats.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly auditing environment variables for anomalies."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
index 54785d68578..19d9e7e5aa4 100644
--- a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
+++ b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/18"
 
 [rule]
 author = ["Elastic"]
@@ -67,49 +67,6 @@ event.action in ("connection_attempted", "ipv4_connection_attempt_event") and pr
   )
 ) 
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Connection via Sudo Binary
-
-The 'sudo' command in Linux allows users to execute commands with elevated privileges, typically as the root user. Adversaries may exploit this by injecting malicious code into processes running with these privileges, potentially establishing unauthorized network connections. The detection rule identifies unusual network activity initiated by 'sudo', excluding common internal IP ranges, to flag potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "sudo" and verify the event type is "start" with actions "connection_attempted" or "ipv4_connection_attempt_event".
-- Check the destination IP address to ensure it is not within the excluded internal IP ranges, indicating a potential external connection.
-- Investigate the command line arguments used with the "sudo" process to identify any suspicious or unexpected commands that may have been executed.
-- Examine the user account associated with the "sudo" command to determine if the account has a history of legitimate use or if it might be compromised.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'sudo';` to retrieve details about the process, including its parent process and command line.
-- Analyze the parent process of the "sudo" command to understand the context in which it was executed and identify any potential anomalies.
-- Review recent authentication logs to check for unusual login attempts or successful logins around the time the "sudo" command was executed.
-- Investigate network logs to identify any other unusual or unauthorized network connections from the host around the same time as the alert.
-- Check for any recent changes to the system's sudoers file that might allow unauthorized users to execute commands with elevated privileges.
-- Correlate the alert with other security events or alerts from the same host to identify any patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- **Administrative Scripts**: Some legitimate administrative scripts or tools may use 'sudo' to initiate network connections for system updates or configuration management. Users can handle these by identifying and excluding specific scripts or processes that are known to perform these actions regularly.
-- **Monitoring and Management Tools**: Network monitoring or management tools that require elevated privileges might trigger this rule. Users should review and whitelist these tools if they are verified to be safe and necessary for operations.
-- **Backup and Synchronization Services**: Services that perform backups or data synchronization might use 'sudo' to access network resources. Users can create exceptions for these services by specifying their process names or network destinations.
-- **Custom Internal Applications**: In some environments, custom applications may be designed to run with elevated privileges and initiate network connections. Users should document these applications and exclude them from the rule to prevent false positives.
-- **Testing and Development Environments**: Developers or testers might use 'sudo' to simulate network connections for testing purposes. Users can manage these by setting up separate rules or exceptions for known testing environments or IP ranges.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on logs related to the 'sudo' command and network connections.
-- Terminate any suspicious processes that were initiated by 'sudo' and verify the integrity of system binaries and configurations.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Review and enhance logging policies to ensure comprehensive monitoring of privileged command executions and network activities.
-- Implement additional security measures such as multi-factor authentication for privileged accounts and regular audits of sudoers files.
-- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of maintaining secure practices.
-- Consider deploying endpoint detection and response (EDR) solutions to improve visibility and response capabilities for future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
index 65d15832383..a62129ec619 100644
--- a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
+++ b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -65,48 +65,6 @@ sequence by process.parent.entity_id, host.id with maxspan=5s
   [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
     user.id == "0"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via OverlayFS
-
-OverlayFS is a union filesystem used in Linux environments to overlay one filesystem on top of another, allowing for efficient file management and updates. Adversaries exploit vulnerabilities in Ubuntu's OverlayFS modifications to execute crafted executables that elevate privileges to root. The detection rule identifies suspicious sequences involving the 'unshare' command with specific arguments and subsequent UID changes to root, indicating potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'unshare' command with suspicious arguments such as "-r", "-rm", "m", and "*cap_setuid*". Verify that the user ID is not "0" in the initial process execution.
-- Check the sequence of events to ensure that a UID change to "0" (root) occurred within 5 seconds of the 'unshare' command execution, as indicated by the query.
-- Investigate the parent process of the 'unshare' command by examining the `process.parent.entity_id` to understand the context and origin of the suspicious activity.
-- Use Osquery to gather more information about the processes involved. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, uid FROM processes WHERE uid = <user_id> ORDER BY start_time DESC LIMIT 10;`.
-- Examine the `host.id` field to identify the specific host involved in the alert and gather additional context about its role and importance within the network.
-- Check system logs on the affected host for any additional suspicious activity or errors around the time of the alert, focusing on authentication logs and system logs.
-- Investigate any recent changes or updates to the OverlayFS configuration or related packages on the affected host to identify potential sources of the vulnerability.
-- Review user activity and permissions for the user account involved in the alert to determine if there are any anomalies or unauthorized privilege assignments.
-- Analyze network traffic logs from the affected host to detect any unusual outbound connections or data exfiltration attempts that might correlate with the privilege escalation attempt.
-- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks involving OverlayFS exploitation.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use the 'unshare' command with similar arguments for legitimate purposes, such as container management or system maintenance, which could trigger the rule. To manage this, users can create exceptions for known administrative scripts or processes that frequently execute these commands.
-- Development and testing environments: Developers might use the 'unshare' command with the specified arguments during software testing or development, especially in environments that mimic production settings. Users can exclude specific development environments or user accounts from triggering alerts by setting up exceptions based on user roles or environment identifiers.
-- Automated scripts and tools: Some automated tools or scripts designed for system configuration or monitoring might inadvertently match the rule's criteria. Users should review these tools and, if deemed safe, add them to an allowlist to prevent false positives.
-- Custom security solutions: Organizations with custom security solutions that involve UID changes might see false positives. In such cases, users should document these solutions and configure the detection rule to exclude these specific processes or actions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Conduct a thorough investigation to confirm the exploitation of CVE-2023-2640 or CVE-2023-32629 by reviewing logs and identifying any unauthorized privilege escalations.
-- Terminate any suspicious processes identified in the detection rule, particularly those involving the 'unshare' command with the specified arguments.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Apply available patches or updates from Ubuntu to address the vulnerabilities in OverlayFS and prevent future exploitation.
-- Review and enhance logging policies to ensure comprehensive monitoring of privilege escalation attempts, focusing on command execution and UID changes.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
-- Restore the system to its operational state by verifying the integrity of critical files and configurations, and ensure no backdoors or malicious modifications remain.
-- Implement hardening measures, such as restricting the use of the 'unshare' command to trusted users and processes, and enforcing the principle of least privilege.
-- Document the incident and response actions taken, and update incident response plans and security policies to incorporate lessons learned and improve future readiness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
index 7e9183dbe4c..6b29e1b8b63 100644
--- a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
+++ b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
@@ -1,8 +1,10 @@
 [metadata]
 creation_date = "2022/01/26"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/01/06"
 
 [rule]
 author = ["Elastic"]
@@ -11,7 +13,7 @@ Identifies an attempt to exploit a local privilege escalation in polkit pkexec (
 variable injection. Successful exploitation allows an unprivileged user to escalate to the root user.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Privilege Escalation via PKEXEC"
@@ -52,6 +54,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -59,49 +62,6 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and file.path : "/*GCONV_PATH*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via PKEXEC
-
-Polkit's pkexec is a command-line tool used in Linux environments to execute commands as another user, typically root, by leveraging policies. Adversaries exploit vulnerabilities like CVE-2021-4034 by injecting unsecure environment variables, allowing unauthorized privilege escalation. The detection rule identifies suspicious file paths indicative of such exploitation attempts, focusing on patterns linked to environment variable manipulation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the suspicious file path pattern `/*GCONV_PATH*` on a Linux host, as this is indicative of potential exploitation attempts.
-- Verify the host's operating system type to ensure it matches "linux," as the rule is specifically designed for Linux environments.
-- Check the file creation and modification timestamps to determine when the suspicious file path was accessed or altered, which can help establish a timeline of events.
-- Use Osquery to list all environment variables set for processes running on the affected host to identify any unsecure or unusual entries. Example query: `SELECT pid, name, path, cmdline, environ FROM processes WHERE path LIKE '%pkexec%';`
-- Investigate the user account associated with the suspicious activity to determine if it has a history of privilege escalation attempts or other suspicious behavior.
-- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any entries related to pkexec usage or unauthorized access attempts around the time of the alert.
-- Analyze the process tree to identify parent and child processes of pkexec, which may reveal the origin of the exploitation attempt and any subsequent actions taken by the adversary.
-- Check for any recent changes to polkit configurations or policies that could have been exploited to facilitate the privilege escalation.
-- Review network activity logs to identify any external connections or data exfiltration attempts that may have occurred following the privilege escalation.
-- Correlate the findings with other security alerts or incidents to determine if this is part of a larger attack campaign targeting the organization.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the detection rule if they temporarily use environment variables that match the suspicious patterns, such as those involving GCONV_PATH. Users should verify the source and context of these activities to determine if they are benign.
-- Custom scripts or administrative tools that manipulate environment variables for configuration purposes might also match the detection criteria. Users can create exceptions for these known scripts by specifying their file paths or process names in the detection rule.
-- Development environments where developers frequently test or debug applications using environment variables may inadvertently trigger the rule. In such cases, users can whitelist specific development directories or user accounts to reduce noise.
-- Automated system management tools that perform legitimate privilege escalation tasks might be flagged. Users should review these tools and, if deemed safe, add them to an exception list to prevent false positives.
-- To manage false positives effectively, users can implement a logging and review process to regularly assess flagged activities, ensuring that only non-threatening behaviors are excluded from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Conduct a thorough investigation to confirm the exploitation of CVE-2021-4034 by reviewing logs and identifying any unauthorized changes or suspicious activities.
-- If exploitation is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Apply the latest security patches and updates for polkit and pkexec to mitigate the vulnerability and prevent future exploitation.
-- Review and enhance logging policies to ensure comprehensive monitoring of environment variable manipulations and pkexec usage.
-- Implement additional security controls such as application whitelisting and least privilege access to reduce the attack surface.
-- Restore the system to its operational state by removing any unauthorized changes and verifying the integrity of critical system files.
-- Conduct a post-incident review to identify gaps in security controls and improve incident response procedures.
-- Educate users and administrators on the importance of applying security patches promptly and recognizing signs of potential exploitation.
-- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to enhance detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
index 822c9a0e586..d0bdbf799f4 100644
--- a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
+++ b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/11"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -42,49 +42,6 @@ type = "threshold"
 query = '''
 kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.type:linux and event.kind:signal
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Buffer Overflow Attack Detected
-
-Buffer overflow attacks exploit vulnerabilities in software to execute arbitrary code, often leading to privilege escalation. Adversaries may trigger numerous segmentation faults (segfaults) on Linux systems as they attempt to exploit these vulnerabilities. The detection rule identifies potential attacks by monitoring for a surge in segfault alerts, indicating possible exploitation attempts, and correlates them with known privilege escalation tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the rule ID "5c81fc9d-1eae-437f-ba07-268472967013" and ensure it matches the Potential Buffer Overflow Attack Detected rule.
-- Examine the host information, specifically focusing on `host.os.type:linux`, to identify the affected systems and prioritize them based on criticality and exposure.
-- Analyze the timeline of the segfault alerts to determine if they occurred in a short timespan, indicating a potential exploitation attempt.
-- Correlate the segfault alerts with any recent changes or deployments on the affected systems that might have introduced vulnerabilities.
-- Investigate the processes associated with the segfaults by reviewing logs and identifying any unusual or unauthorized applications running on the system.
-- Use Osquery to gather more context on the affected system. For example, run the following query to list processes that have recently crashed: `SELECT pid, name, path, cmdline FROM processes WHERE state = 'Z';`
-- Check for any known vulnerabilities or exploits related to the applications or services that triggered the segfaults, using CVE databases or security advisories.
-- Look for any additional indicators of compromise (IOCs) on the affected systems, such as unexpected network connections or file modifications, that might suggest further malicious activity.
-- Review user and system logs for any signs of privilege escalation attempts, focusing on the timeframe of the segfault alerts.
-- Cross-reference the detected activity with MITRE ATT&CK framework, specifically tactic TA0004 and technique T1068, to identify potential adversary behavior patterns and refine the investigation focus.
-
-### False positive analysis
-
-- Known false positives for the Potential Buffer Overflow Attack Detected rule may include legitimate applications or processes that inherently generate a high number of segmentation faults during normal operation, such as software under development or testing environments where debugging and crash testing are frequent.
-- System administrators can manage these false positives by creating exceptions for specific applications or processes known to cause frequent segfaults without malicious intent. This can be done by adjusting the detection rule to exclude certain process names or paths that are identified as non-threatening.
-- Another approach is to refine the threshold settings to better align with the typical behavior of the monitored environment, ensuring that only unusual spikes in segfaults trigger alerts.
-- Users should regularly review and update the list of exceptions to ensure that new legitimate applications are accounted for and that any changes in application behavior are reflected in the rule configuration.
-- It is also advisable to correlate segfault alerts with other indicators of compromise or suspicious activity to differentiate between benign and potentially malicious behavior more effectively.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to confirm the buffer overflow attack by analyzing logs and correlating segfault alerts with other suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Apply patches and updates to the affected software and operating system to close the vulnerability exploited by the attacker.
-- Restore the system from a known good backup to ensure no malicious code remains on the system.
-- Implement enhanced logging policies to capture detailed information on system calls and application behavior for future investigations.
-- Integrate additional security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Harden the system by disabling unnecessary services, applying the principle of least privilege, and enabling security features such as stack canaries and address space layout randomization (ASLR).
-- Educate and train staff on recognizing and responding to buffer overflow attacks and other privilege escalation techniques to improve overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
index a6e6d323328..c5e85063fdc 100644
--- a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
+++ b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 
 [rule]
 author = ["Elastic"]
@@ -95,49 +95,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 ) and not process.parent.name == "spine"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privilege Escalation via SUID/SGID
-
-SUID/SGID are Unix permissions that allow users to execute files with the file owner's privileges, often root. Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access. The detection rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions for privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert. Pay special attention to the `process.name` and `process.args` fields.
-- Verify the user context by checking the `process.user.id` and `process.real_user.id` fields to confirm the discrepancy in user IDs, indicating potential misuse of SUID/SGID permissions.
-- Examine the `process.group.id` and `process.real_group.id` fields to identify any group ID discrepancies that might suggest SGID exploitation.
-- Investigate the parent process by reviewing the `process.parent.name` field to understand the process hierarchy and determine if the execution chain is suspicious.
-- Use Osquery to list all SUID/SGID binaries on the system with the following query: `SELECT path, mode FROM file WHERE mode & 4000 OR mode & 2000;` to identify potential misconfigurations.
-- Cross-reference the list of SUID/SGID binaries with the process name from the alert to determine if the binary is expected to have these permissions.
-- Check system logs for any recent changes to SUID/SGID binaries or user accounts that might indicate tampering or privilege escalation attempts.
-- Investigate the command-line arguments used by the process to determine if they are typical for the binary in question or if they suggest malicious intent.
-- Review the system's user and group configurations to ensure there are no unauthorized changes or additions that could facilitate privilege escalation.
-- Analyze network activity associated with the process to identify any external connections or data exfiltration attempts that might be related to the privilege escalation.
-
-### False positive analysis
-
-- Some legitimate administrative tasks may trigger the detection rule, such as system maintenance scripts or software updates that require elevated privileges. These tasks often run with SUID/SGID permissions but are not malicious.
-- Automated backup processes or monitoring tools that require root access might also be flagged. These processes are typically scheduled and can be verified by checking their source and purpose.
-- Developers or system administrators using certain tools for legitimate purposes, like debugging or performance monitoring, may inadvertently trigger the rule. Tools like `gdb`, `strace`, or `perf` are common in such scenarios.
-- To manage these false positives, users can create exceptions for known benign processes by adding them to an exclusion list. This can be done by identifying the specific process names and arguments that are frequently flagged but are part of routine operations.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker.
-- Investigate the process and user account involved in the alert to determine if the SUID/SGID permissions were intentionally set or misconfigured.
-- Review system logs and audit trails to identify any unauthorized access or changes made by the process, focusing on the time frame around the alert.
-- Remove or correct the SUID/SGID permissions on the identified binary if they are not required for legitimate operations.
-- Conduct a thorough scan of the system for any additional signs of compromise, such as unexpected user accounts, scheduled tasks, or backdoors.
-- Restore the system from a known good backup if unauthorized changes or malware are detected, ensuring that the backup is free from compromise.
-- Implement stricter access controls and permissions management to prevent unauthorized changes to SUID/SGID binaries in the future.
-- Enhance logging and monitoring to include detailed process execution and privilege escalation attempts, integrating with a SIEM for real-time alerting.
-- Educate users and administrators on the risks associated with SUID/SGID binaries and the importance of maintaining secure configurations.
-- Report the incident to relevant internal teams and, if necessary, external authorities or partners, following organizational policies and legal requirements."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
index 6f71f341214..656f678d771 100644
--- a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
+++ b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/07/28"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ vulnerability where attackers manipulate commands or input containing wildcards
 operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*"]
+index = ["logs-endpoint.events.*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Shell via Wildcard Injection Detected"
@@ -53,66 +55,23 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 type = "eql"
 
 query = '''
 sequence by host.id with maxspan=1s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and (
     (process.name == "tar" and process.args : "--checkpoint=*" and process.args : "--checkpoint-action=*") or
     (process.name == "rsync" and process.args : "-e*") or
     (process.name == "zip" and process.args == "--unzip-command")
    ) and not process.executable : "/tmp/newroot/*"
   ]  by process.entity_id
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and 
      process.parent.name : ("tar", "rsync", "zip") and 
      process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Shell via Wildcard Injection Detected
-
-Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries may leverage this to escalate privileges or access sensitive data. The detection rule identifies suspicious executions of vulnerable binaries like `tar`, `rsync`, and `zip`, followed by shell spawns, indicating potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific binary (e.g., `tar`, `rsync`, `zip`) and the suspicious command line flags that triggered the alert.
-- Examine the `process.entity_id` and `process.parent.entity_id` fields to trace the process lineage and understand the parent-child relationship of the processes involved.
-- Check the `host.id` and `host.os.type` fields to confirm the affected host and ensure it is running a Linux operating system.
-- Investigate the `process.args` field to analyze the exact command line arguments used, looking for any unusual or unexpected patterns that could indicate manipulation.
-- Use Osquery to gather additional context about the processes involved. For example, run the following query to list recent processes executed by the same user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <suspicious_process_id>);`
-- Review the `event.type` and `event.action` fields to confirm the nature of the process execution events and ensure they align with the expected behavior of the binaries.
-- Check for any recent changes or anomalies in the `/tmp/newroot/` directory, as the query excludes processes executed from this path, which might indicate an attempt to bypass detection.
-- Investigate the `process.parent.name` field to determine if the shell spawn was legitimate or if it indicates an unauthorized shell access attempt.
-- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns.
-- Consult threat intelligence sources or internal knowledge bases to determine if there are known vulnerabilities or exploits associated with the specific binaries and command line flags observed.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate administrative scripts or automated processes use the `tar`, `rsync`, or `zip` commands with wildcard characters for routine operations, such as backups or file synchronization, which may inadvertently match the detection criteria.
-- System administrators often use `tar` with `--checkpoint` and `--checkpoint-action` flags for monitoring purposes during large file operations, which can trigger the rule without malicious intent.
-- The `rsync` command with `-e` options is commonly used in secure file transfer scripts, which might be flagged if the script spawns a shell for legitimate reasons.
-- The `zip` command with `--unzip-command` is sometimes used in custom scripts to handle specific file extraction tasks, potentially leading to false positives if a shell is invoked as part of the process.
-- To manage these false positives, users can create exceptions by excluding specific scripts or processes known to perform these operations safely. This can be done by adding the paths or process names to an exclusion list within the detection rule configuration.
-- Regularly review and update the exclusion list to ensure it reflects current legitimate usage patterns, minimizing the risk of overlooking genuine threats while reducing noise from benign activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the scope of the intrusion, focusing on logs and process trees related to the detected binaries (tar, rsync, zip) and subsequent shell spawns.
-- Terminate any unauthorized processes that were spawned as a result of the wildcard injection to halt any ongoing malicious activities.
-- Review and analyze system logs to determine if any sensitive data was accessed or exfiltrated during the exploitation attempt.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Apply patches or updates to the affected binaries and the operating system to mitigate the vulnerability and prevent future exploitation.
-- Implement enhanced logging policies to capture detailed command-line arguments and process execution details for better visibility in future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to detect similar patterns of behavior and improve threat detection capabilities.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Harden the system by disabling unnecessary services, enforcing the principle of least privilege, and implementing application whitelisting to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
index e2af3a85c23..1ed28663043 100644
--- a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
+++ b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/30"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name == "debugfs" and process.args : "/dev/sd*" and not process.args == "-R" and 
 not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Suspicious DebugFS Root Device Access
-
-DebugFS is a Linux utility that provides low-level access to file systems, often used for debugging. Users in the "disk" group can exploit DebugFS to access sensitive files without root privileges, potentially leading to privilege escalation. The detection rule identifies non-root users executing DebugFS on disk devices, flagging potential unauthorized access attempts by monitoring specific process arguments and user group IDs.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of non-root user activity involving the DebugFS utility, focusing on the `process.name`, `process.args`, `user.Ext.real.id`, and `group.Ext.real.id` fields.
-- Verify the identity of the user by checking the `user.Ext.real.id` and cross-reference with the organization's user directory to determine if the user should have access to disk devices.
-- Investigate the user's group memberships, particularly the "disk" group, to understand if the user has legitimate reasons to be part of this group.
-- Examine the specific `process.args` used in the alert to identify which disk device was accessed and assess the potential impact of this access.
-- Use Osquery to gather more context about the process execution. For example, run the following query to list recent processes executed by the user: `SELECT * FROM processes WHERE uid = <user_id> AND name = 'debugfs';`
-- Check the system logs for any other suspicious activities or anomalies around the time of the alert, focusing on the same user and device.
-- Investigate any recent changes to the user's account or group memberships that might explain the activity.
-- Review the user's command history, if available, to identify any other potentially suspicious commands executed around the same time.
-- Analyze network logs to determine if there was any unusual outbound traffic from the host that might indicate data exfiltration.
-- Correlate this alert with any other security alerts or incidents involving the same user or host to identify patterns or repeated suspicious behavior.
-
-### False positive analysis
-
-- Users performing legitimate maintenance tasks: System administrators or maintenance scripts may use DebugFS for legitimate purposes, such as file system checks or repairs. To handle these, identify the specific users or scripts and create exceptions for their activities.
-- Automated backup processes: Some backup solutions might use DebugFS to access disk devices for data integrity checks. Review the backup processes and exclude these known benign activities by specifying the associated user accounts or process arguments.
-- Development and testing environments: Developers or testers might use DebugFS in non-production environments for debugging purposes. To prevent these from being flagged, consider excluding specific environments or user groups from the rule.
-- Educational or training sessions: In educational settings, DebugFS might be used as part of training exercises. Identify these sessions and exclude the relevant user accounts or time frames to avoid false positives.
-- Custom scripts or tools: Organizations may have custom scripts that utilize DebugFS for specific operational needs. Review these scripts and exclude their execution by defining exceptions based on process names or arguments.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Verify the identity and permissions of the user who executed DebugFS to determine if the access was legitimate or malicious.
-- Review system logs and DebugFS usage history to identify any sensitive files accessed or modified during the incident.
-- Change passwords and revoke any potentially compromised credentials, especially for accounts with elevated privileges.
-- Remove the user from the "disk" group if they do not require access to disk devices for their role.
-- Implement stricter access controls and audit policies for the "disk" group to prevent unauthorized use of DebugFS.
-- Escalate the incident to the security team for further investigation and to assess the potential impact on the organization.
-- Enhance logging and monitoring to include detailed tracking of file access and user activities, integrating with SIEM solutions for real-time alerts.
-- Restore the system from a known good backup if any unauthorized changes or data corruption are detected.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing the principle of least privilege, to reduce the attack surface."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_shadow_file_read.toml b/rules/linux/privilege_escalation_shadow_file_read.toml
index 8b56f4fd49f..327e52480d6 100644
--- a/rules/linux/privilege_escalation_shadow_file_read.toml
+++ b/rules/linux/privilege_escalation_shadow_file_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -65,49 +65,6 @@ host.os.type : "linux" and event.category : "process" and event.action : ("exec"
   process.parent.name:(gen_passwd_sets or scc_* or wazuh-modulesd)
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Shadow File Read via Command Line Utilities
-
-In Linux environments, the `/etc/shadow` file stores hashed passwords and is crucial for system security. Adversaries with elevated privileges may attempt to access this file to extract credentials, facilitating lateral movement and unauthorized access. The detection rule identifies suspicious command-line attempts to read this file, excluding legitimate processes, by monitoring process execution patterns and arguments, thus helping to thwart potential credential theft.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious command-line attempts to access the `/etc/shadow` file, focusing on the `process.args` and `process.executable` fields.
-- Verify the user account associated with the process by examining the `user.name` field to determine if the access was performed by a legitimate user or an unexpected account.
-- Check the `host.os.type` and `event.category` fields to ensure the alert pertains to a Linux system and involves a process execution event.
-- Investigate the `process.parent.name` field to identify the parent process and assess whether it is a known legitimate process or potentially malicious.
-- Examine the `process.working_directory` field to confirm if the process was executed from the `/etc` directory, which might indicate an attempt to access the shadow file directly.
-- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve detailed information about the process, including its command line, parent process, and user.
-- Cross-reference the `process.executable` field with known legitimate utilities and paths to rule out false positives, focusing on paths not excluded in the query.
-- Analyze recent login events and privilege escalation activities on the host to identify any unauthorized access attempts that might correlate with the alert.
-- Review system logs for any other suspicious activities or anomalies around the time of the alert to gather more context on potential malicious behavior.
-- Investigate any network connections initiated by the suspicious process to determine if there was any data exfiltration or communication with external hosts.
-
-### False positive analysis
-
-- System maintenance tasks: Legitimate system administrators may access the `/etc/shadow` file during routine maintenance or configuration changes. To handle these, users can create exceptions for known maintenance scripts or processes by adding them to the exclusion list in the detection rule.
-- Backup operations: Automated backup processes might access the `/etc/shadow` file as part of a comprehensive system backup. Users should identify and exclude these backup processes by specifying their executable paths or parent process names in the rule.
-- Security software: Some security tools, such as vulnerability scanners or compliance checkers, may read the `/etc/shadow` file to verify system security settings. Users can manage these false positives by excluding the specific security software processes from the detection rule.
-- Containerized environments: In environments using containers, certain processes might access the `/etc/shadow` file as part of container management tasks. Users should exclude paths related to container runtimes, such as Docker or containerd, to prevent false positives.
-- Custom scripts: Organizations may have custom scripts that legitimately access the `/etc/shadow` file for specific operational needs. Users should review these scripts and add them to the exclusion criteria based on their executable paths or parent process names.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the process attempting to access the /etc/shadow file by reviewing the process tree and associated user accounts.
-- Conduct a thorough investigation to determine if any credentials have been compromised and reset passwords for affected accounts.
-- Review system logs and security alerts to identify any additional suspicious activities or related incidents.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for critical files and directories, including /etc/shadow, to detect future unauthorized access attempts.
-- Apply security patches and updates to address any vulnerabilities that may have been exploited for privilege escalation.
-- Restore the system to a known good state from backups if necessary, ensuring that all compromised accounts and processes are remediated.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Implement hardening measures such as enforcing the principle of least privilege, using multi-factor authentication, and regularly auditing user access rights."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
index 41ca86ede4c..005178403d9 100644
--- a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
+++ b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2023/08/30"
-integration = ["endpoint", "auditd_manager"]
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -13,7 +15,7 @@ that can be chosen arbitrarily. By using the sudo privileges, the command "sudo
 representing the root user. This exploit may work for sudo versions prior to v1.28.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Sudo Privilege Escalation via CVE-2019-14287"
@@ -55,56 +57,17 @@ tags = [
     "Use Case: Vulnerability",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started")
- and process.name == "sudo" and process.args == "-u#-1"
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+  process.name == "sudo" and process.args == "-u#-1"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Sudo Privilege Escalation via CVE-2019-14287
-
-Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. CVE-2019-14287 exploits a flaw where specifying a user ID of -1 bypasses user validation, granting root access. Adversaries can leverage this to escalate privileges. The detection rule identifies suspicious sudo commands with specific arguments indicative of this exploit, helping to flag unauthorized privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the suspicious sudo command with the arguments `-u#-1` as indicated in the query.
-- Verify the version of sudo installed on the affected system to determine if it is prior to v1.28, which is vulnerable to CVE-2019-14287.
-- Check the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
-- Investigate the user account associated with the process execution to determine if it has a history of legitimate sudo usage or if it appears compromised.
-- Examine the command history of the user involved to identify any other potentially malicious commands executed around the same time.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes executed by the user in question: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');`
-- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, to identify any unauthorized access attempts or anomalies around the time of the alert.
-- Correlate the alert with network logs to check for any unusual outbound connections that might suggest data exfiltration or communication with a command-and-control server.
-- Investigate any file modifications or new file creations in critical directories that could indicate post-exploitation activities.
-- Cross-reference the alert with other security tools and logs to identify if this is part of a larger attack campaign targeting multiple systems.
-
-### False positive analysis
-
-- Legitimate administrative scripts or automation tools that use the "sudo -u#-1" command for testing or maintenance purposes may trigger this rule. Users should review such scripts and, if verified as non-threatening, create exceptions for these specific processes.
-- Development environments where developers have intentionally used the "sudo -u#-1" command for testing privilege escalation scenarios might cause false positives. In such cases, ensure that these activities are documented and consider excluding these environments from the rule.
-- Security testing or penetration testing activities that simulate the CVE-2019-14287 exploit could be flagged. Coordinate with security teams to whitelist these activities during scheduled testing periods.
-- Custom user applications that inadvertently use similar command patterns for legitimate reasons may also be flagged. Conduct a thorough review of these applications and, if deemed safe, add them to an exception list to prevent future alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the version of sudo installed on the system and upgrade to a version later than v1.28 to mitigate the vulnerability.
-- Conduct a thorough investigation of the system to identify any unauthorized changes or additional malicious activity, focusing on logs and recent changes.
-- Review and analyze logs for any other instances of the exploit attempt, particularly looking for the "sudo -u#-1" command.
-- Reset passwords and review user accounts to ensure no unauthorized accounts have been created or existing accounts have been compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed sudo command usage and integrate with a centralized logging solution for real-time monitoring.
-- Develop and deploy a security patch management process to ensure all systems are regularly updated with the latest security patches.
-- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily remediated.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_sudo_hijacking.toml b/rules/linux/privilege_escalation_sudo_hijacking.toml
index b7b9d1a2599..c188f2396b4 100644
--- a/rules/linux/privilege_escalation_sudo_hijacking.toml
+++ b/rules/linux/privilege_escalation_sudo_hijacking.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -79,50 +79,6 @@ file.path in ("/usr/bin/sudo", "/bin/sudo") and not (
   (process.name == "sed" and file.name : "sed*")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Sudo Hijacking
-
-Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the legitimate sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event action is either "creation" or "rename" for the file path "/usr/bin/sudo" or "/bin/sudo".
-- Check the process executable that triggered the alert to ensure it is not part of the legitimate package management processes listed in the exclusion criteria.
-- Investigate the file.Ext.original.path to determine if the original file path was "/usr/bin/sudo" or "/bin/sudo", which might indicate a legitimate update or replacement.
-- Examine the process name and executable path to identify any unusual or unauthorized processes that might have created or renamed the sudo binary.
-- Use Osquery to list recent changes to the sudo binary with a query like: `SELECT * FROM file WHERE path IN ('/usr/bin/sudo', '/bin/sudo') ORDER BY atime DESC LIMIT 5;` to gather more context on recent access times.
-- Check system logs for any related entries around the time of the alert to identify any suspicious activities or patterns.
-- Verify the integrity of the current sudo binary using checksums or hashes to compare against known good versions.
-- Investigate the user account associated with the process that triggered the alert to determine if it has a history of suspicious activity or if it has been compromised.
-- Review any recent changes in user permissions or sudoers file that might correlate with the alert.
-- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
-
-### False positive analysis
-
-- Legitimate package management operations can trigger false positives. These include processes like updates or installations using package managers such as dpkg, rpm, yum, dnf, and apt. These processes are typically responsible for creating or renaming the sudo binary as part of their normal operations.
-- Exclude these package management processes by adding their executables to the exception list in the detection rule. This includes paths like "/bin/dpkg", "/usr/bin/rpm", "/usr/bin/apt-get", and others specified in the rule.
-- Temporary files created during legitimate operations, such as those with the extension "dpkg-new", can also cause false positives. Ensure these are excluded by checking the file extension in the rule.
-- Processes running from specific directories like "/nix/store/*", "/var/lib/dpkg/*", or "/snap/*" are often part of legitimate system operations and should be excluded to prevent false alerts.
-- If a process executable is null, it might indicate a legitimate system process that should not be flagged. Consider adding checks to handle such cases appropriately.
-- The use of the "sed" command in scripts that modify the sudo binary name temporarily can also lead to false positives. Exclude these by checking for the process name "sed" and file names starting with "sed".
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source or repository.
-- Review system logs and security alerts to identify any unauthorized access or suspicious activity around the time of the sudo binary modification.
-- Conduct a thorough investigation to determine the source of the compromise, including reviewing user accounts and processes that initiated the change.
-- Restore the original sudo binary from a trusted backup or reinstall the sudo package using a secure package manager.
-- Escalate the incident to the security operations team if evidence of a broader compromise or advanced persistent threat is detected.
-- Implement enhanced logging policies to capture detailed audit logs of file modifications and process executions, focusing on critical system binaries.
-- Integrate with a centralized security information and event management (SIEM) system to correlate and analyze security events across the network.
-- Apply system hardening measures, such as restricting sudo access to only necessary users and implementing multi-factor authentication for privileged accounts.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
index 3184797ca78..ce6f74cdf9b 100644
--- a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
+++ b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,48 +65,6 @@ sequence by host.id, process.session_leader.entity_id with maxspan=15s
 [ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
   process.name == "sudo" and process.user.id == "0" and process.group.id == "0" ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Sudo Token Manipulation via Process Injection
-
-In Linux environments, process injection can be exploited by adversaries to manipulate sudo tokens, allowing unauthorized privilege escalation. Attackers may use debugging tools like gdb to inject code into processes with valid sudo tokens, leveraging ptrace capabilities. The detection rule identifies this threat by monitoring for gdb execution followed by a uid change in the sudo process, indicating potential token manipulation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and process.session_leader.entity_id involved in the sequence to ensure the correct context is being investigated.
-- Verify the execution of the gdb process by checking the process.name field and ensure it matches "gdb" with a non-root user and group id, as indicated by process.user.id != "0" and process.group.id != "0".
-- Investigate the timing and sequence of events by examining the maxspan=15s condition to determine if the gdb execution and sudo uid change occurred within this short timeframe.
-- Check the process tree and parent-child relationships for the gdb process to identify any suspicious parent processes or anomalies in the process hierarchy.
-- Analyze the sudo process event where the uid_change occurred, ensuring the process.name is "sudo" and the user and group ids are root (process.user.id == "0" and process.group.id == "0").
-- Use Osquery to gather additional context on the processes involved. For example, run the following query to list processes with their parent processes and command lines: `SELECT pid, parent, name, path, cmdline FROM processes WHERE pid IN (SELECT pid FROM processes WHERE name = 'gdb' OR name = 'sudo');`
-- Investigate the ptrace settings on the host to determine if ptrace is enabled, which is necessary for process injection. This can be done by checking the value of `/proc/sys/kernel/yama/ptrace_scope`.
-- Review system logs and audit logs for any additional context or anomalies around the time of the alert, focusing on user activity and any other privilege escalation attempts.
-- Examine the user account associated with the gdb process to determine if there are any signs of compromise or unusual activity, such as recent logins from unexpected locations or times.
-- Correlate the findings with any other alerts or incidents involving the same host or user to identify potential patterns or broader attack campaigns.
-
-### False positive analysis
-
-- Debugging activities by developers or system administrators using gdb on processes with valid sudo tokens can trigger false positives. To manage this, users can create exceptions for specific user IDs or process names that are known to be involved in legitimate debugging activities.
-- Automated scripts or maintenance tasks that involve gdb and result in uid changes in the sudo process may also cause false positives. Users can handle these by identifying and excluding specific scripts or cron jobs from the detection rule.
-- Security tools or monitoring solutions that utilize gdb for legitimate process analysis might be mistakenly flagged. Users should whitelist these tools by specifying their process names or user IDs in the exception list.
-- Training or testing environments where gdb is frequently used for educational purposes can lead to false positives. Users can exclude these environments by filtering based on host identifiers or specific session leader entity IDs.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Use forensic tools to capture memory and disk images of the affected system for further analysis and evidence preservation.
-- Investigate the process tree and logs to identify the source of the gdb execution and any associated processes that may have been injected.
-- Check for unauthorized changes in user privileges and revert any unauthorized uid changes detected in the sudo process.
-- Review and update ptrace settings to restrict debugging capabilities to trusted users only, reducing the risk of process injection.
-- Implement enhanced logging for sudo and gdb activities, ensuring that all execution and privilege changes are recorded and monitored.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious activities related to process injection.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and threat intelligence correlation.
-- Restore the system to its operational state by applying clean backups and verifying the integrity of critical system files and configurations.
-- Conduct a security review and harden the system by applying the principle of least privilege, ensuring that only necessary users have sudo access, and regularly updating all software and security patches."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
index 244ad47e105..099c3d7462e 100644
--- a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
+++ b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -63,48 +63,6 @@ sequence by host.id, process.entity_id with maxspan=1s
   [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and 
    (user.id == "0" or group.id == "0")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via Python cap_setuid
-
-In Unix-like systems, setuid and setgid allow processes to execute with elevated privileges, typically those of the file owner or group. Adversaries may exploit these features using Python scripts to gain unauthorized root access by executing commands with root privileges. The detection rule identifies such attempts by monitoring Python processes that invoke system commands with setuid or setgid, followed by a user or group ID change to root, indicating potential privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and process entity ID involved in the potential privilege escalation attempt.
-- Examine the process arguments captured in the alert to confirm the presence of the suspicious Python command pattern: `import os;os.set?id(0);os.system(*)`.
-- Verify the user ID associated with the process to ensure it is not root (`user.id != "0"`), as this is a key indicator of a potential privilege escalation attempt.
-- Check the sequence of events to confirm that a UID or GID change to root (`user.id == "0"` or `group.id == "0"`) occurred immediately after the suspicious Python command execution.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT pid, name, path, cmdline, uid, gid FROM processes WHERE pid = <process_id>;` to retrieve detailed information about the process.
-- Investigate the parent process of the suspicious Python process to understand how it was initiated and whether it was spawned by a legitimate or suspicious parent.
-- Review the system logs on the affected host for any additional context or anomalies around the time of the alert, focusing on authentication logs and any other privilege-related events.
-- Check for any recent changes to the file permissions or ownership of the Python script or any related files that could have facilitated the privilege escalation attempt.
-- Analyze network activity from the host around the time of the alert to identify any potential command and control communication or data exfiltration attempts.
-- Correlate this alert with any other recent alerts or incidents involving the same host or user account to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators may use Python scripts with setuid or setgid capabilities for legitimate purposes, such as system maintenance or automation tasks. These scripts might trigger the detection rule if they change user or group IDs to root. To handle this, users can create exceptions for known scripts by whitelisting specific script paths or hashes.
-- Development and testing environments: Developers might execute Python scripts with elevated privileges during testing or development phases, which could be mistaken for malicious activity. Users can exclude specific development environments or user accounts from the detection rule to reduce false positives.
-- Security tools and monitoring software: Some security tools or monitoring software may use Python scripts with setuid or setgid capabilities as part of their normal operation. Users should identify and exclude these tools from the detection rule by specifying their process names or paths.
-- Automated deployment processes: Automated deployment or configuration management systems might use Python scripts to perform tasks requiring elevated privileges. Users can manage these false positives by excluding known deployment processes or by setting up specific rules for these systems.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the privilege escalation attempt, including reviewing logs and process histories.
-- Terminate any suspicious processes that are running with elevated privileges and verify the integrity of critical system files.
-- Change all passwords for accounts that may have been compromised, especially those with elevated privileges.
-- Restore the system from a known good backup if unauthorized changes or malware are detected.
-- Implement enhanced logging policies to capture detailed process execution and user activity, focusing on setuid and setgid operations.
-- Integrate security monitoring tools with SIEM solutions to improve detection capabilities for similar threats in the future.
-- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
-- Conduct a security audit to identify and remediate any misconfigurations or weaknesses in user permissions and access controls.
-- Educate users and administrators on the risks of privilege escalation and the importance of adhering to the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
index 5a1b73d4a6d..438d47ec204 100644
--- a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -70,51 +70,6 @@ sequence by host.id, process.pid with maxspan=1s
    ) and user.id != "0"
   ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privilege Escalation via CAP_CHOWN/CAP_FOWNER Capabilities
-
-In Linux, CAP_CHOWN and CAP_FOWNER capabilities allow processes to change file ownership and bypass permission checks, respectively. Adversaries exploit these to gain unauthorized file access, potentially altering sensitive files like `/etc/passwd`. The detection rule identifies processes with these capabilities targeting critical files, flagging suspicious ownership changes by non-root users, thus highlighting potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and file involved, focusing on `process.pid`, `process.name`, and `file.path` fields.
-- Verify the user context by checking the `user.id` field to confirm that the action was performed by a non-root user.
-- Examine the command line used to execute the process by reviewing the `process.command_line` field to understand the intent and scope of the action.
-- Investigate the process's parent process to determine if it was spawned by a legitimate or suspicious parent using the `process.parent.name` and `process.parent.pid` fields.
-- Check the system logs for any related entries around the time of the event to gather additional context on the process execution and file ownership change.
-- Use Osquery to list all processes with CAP_CHOWN or CAP_FOWNER capabilities to identify any other potentially suspicious processes:
-  ```sql
-  SELECT pid, name, path, uid, gid, on_disk FROM processes WHERE capabilities LIKE '%CAP_CHOWN%' OR capabilities LIKE '%CAP_FOWNER%';
-  ```
-- Investigate the history of changes to the targeted file (e.g., `/etc/passwd`) to identify any unauthorized modifications or patterns of access.
-- Review user activity logs for the non-root user involved to identify any unusual behavior or access patterns leading up to the event.
-- Analyze network activity from the host to detect any potential exfiltration or communication with known malicious IPs or domains.
-- Correlate the event with other security alerts or incidents to determine if it is part of a broader attack campaign or isolated incident.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may perform legitimate file ownership changes as part of regular maintenance or configuration updates. These actions can trigger the detection rule if they involve files like `/etc/passwd` or `/etc/shadow`. To manage this, users can create exceptions for known administrative scripts or processes that are regularly executed by trusted users.
-- Automated system updates: Some automated update processes or configuration management tools may change file ownership as part of their operations. These processes might be flagged if they have the necessary capabilities. Users can handle these by identifying and excluding specific update processes or tools that are verified as safe.
-- Backup and restore operations: Backup software might change file ownership during the backup or restore process, especially if it needs to ensure files are restored with the correct permissions. Users should identify and whitelist these backup processes to prevent false positives.
-- Development and testing environments: In environments where developers or testers frequently change file permissions or ownership for testing purposes, these actions might be flagged. Users can manage this by excluding specific development or testing processes or by setting up separate monitoring rules for these environments.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the capability abuse, including reviewing logs for any suspicious process executions or file ownership changes.
-- Revert any unauthorized file ownership changes, especially for critical files like /etc/passwd, /etc/shadow, and /etc/sudoers, to their original state.
-- Reset passwords and review user accounts for any unauthorized changes or additions, focusing on accounts with elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and file modification events, ensuring that CAP_CHOWN and CAP_FOWNER usage is monitored.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve visibility and detection capabilities.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for privilege escalation.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting the use of capabilities to only necessary processes and users, and regularly auditing capability assignments."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
index 86e97c6c81d..0b8d920fccf 100644
--- a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
+++ b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/22"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -85,48 +85,6 @@ sequence by host.id, process.parent.pid with maxspan=1m
   [file where host.os.type == "linux" and file.path == "/etc/passwd" and process.parent.pid != 1 and
    not auditd.data.a2 == "80000" and event.outcome == "success" and user.id != "0"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Passwd File Event Action
-
-In Linux environments, the `/etc/passwd` file is crucial for managing user accounts. Adversaries may exploit vulnerabilities or misconfigurations to insert unauthorized entries, potentially gaining root access. The detection rule identifies suspicious activity by monitoring for the use of `openssl` to generate password entries, followed by unauthorized modifications to the `/etc/passwd` file, indicating potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and process.parent.pid involved in the suspicious activity to ensure accurate context.
-- Verify the user.id associated with the openssl process execution to determine if a non-root user attempted to generate a password entry.
-- Check the process.args field to confirm the use of "openssl passwd" and gather any additional arguments that might indicate the password generation method.
-- Investigate the file write activity on the /etc/passwd file by examining the file.path and event.outcome fields to confirm unauthorized modifications.
-- Use Osquery to list recent processes executed by the user.id in question to identify any other suspicious activities: `SELECT pid, name, path, cmdline FROM processes WHERE uid = <user_id>;`
-- Examine the process.parent.pid to trace the parent process and understand the context of how the openssl command was executed.
-- Review system logs for any login attempts or successful logins by the newly created user account, focusing on the time frame around the alert.
-- Check for any recent changes in file permissions or ownership of the /etc/passwd file that could have facilitated unauthorized access.
-- Investigate other security alerts or anomalies on the same host.id to identify potential lateral movement or additional compromise indicators.
-- Correlate the activity with known MITRE ATT&CK techniques, specifically T1068, to assess if this is part of a broader privilege escalation attempt.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use `openssl` to generate password entries for valid user account management. To handle this, users can create exceptions for specific user IDs or processes known to perform these tasks regularly.
-- Automated scripts: Some automated maintenance scripts might use `openssl` for password management and modify the `/etc/passwd` file as part of their routine operations. Users should identify these scripts and exclude them from triggering alerts by specifying their process names or paths.
-- Non-root user activities: Developers or non-root users might use `openssl` for testing purposes, leading to false positives. Users can exclude specific user IDs or groups from the detection rule to prevent unnecessary alerts.
-- System updates or installations: During system updates or software installations, legitimate processes might modify the `/etc/passwd` file. Users should monitor these activities and temporarily disable the rule or whitelist known update processes to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify any unauthorized entries in the `/etc/passwd` file and remove them. Verify the integrity of the file against a known good backup.
-- Review system logs and process execution history to trace the source of the unauthorized `openssl` command and any subsequent actions taken by the adversary.
-- Change all passwords for user accounts on the affected system, especially those with elevated privileges, to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging and monitoring for critical files like `/etc/passwd` and processes involving `openssl` to detect similar activities in the future.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for privilege escalation.
-- Conduct a security audit of user account permissions and file access controls to ensure they adhere to the principle of least privilege.
-- Restore the system from a clean backup if necessary, ensuring that all unauthorized changes are removed and the system is returned to a secure operational state.
-- Educate users and administrators on secure password practices and the importance of monitoring for suspicious activities to enhance overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
index a2fbd15f721..81d2c3ef6c1 100644
--- a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -79,49 +79,6 @@ sequence by host.id, process.entity_id with maxspan=1s
    (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID")
    and user.id == "0"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privilege Escalation via CAP_SETUID/SETGID Capabilities
-
-In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and host involved, focusing on `process.entity_id`, `process.name`, and `host.id`.
-- Verify the process's capabilities by checking `process.thread.capabilities.effective` and `process.thread.capabilities.permitted` to confirm the presence of CAP_SETUID or CAP_SETGID.
-- Examine the process's parent information using `process.parent.executable` and `process.parent.name` to determine if the parent process is known or expected.
-- Investigate the command line used to start the process with `process.command_line` to identify any suspicious or unexpected commands.
-- Check the user context before and after the process execution by reviewing `user.id` to confirm if there was an unauthorized change to UID 0 (root).
-- Use Osquery to gather additional context about the process and its capabilities. Example query: `SELECT pid, name, uid, gid, on_disk, path FROM processes WHERE pid = <process_id>;`
-- Analyze the process's executable path with `process.executable` to ensure it is not located in a suspicious directory or matches known benign paths.
-- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns.
-- Review the system's recent changes or configurations that might have inadvertently granted the process these capabilities.
-- Consult threat intelligence sources to determine if the process or its behavior is associated with known privilege escalation techniques or campaigns.
-
-### False positive analysis
-
-- Processes related to system management tools like VMware, SolarWinds, and Dynatrace may trigger false positives due to their legitimate use of CAP_SETUID/SETGID capabilities for operational purposes. Users can handle these by adding exceptions for specific executables or paths such as "/usr/bin/vmware-toolbox-cmd" and "/opt/SolarWinds/Agent/*".
-- System update and notification processes, including "update-notifier" and "language-options", might be flagged as they sometimes require elevated privileges. Exclude these by specifying their parent names or command lines in the detection rule.
-- Security and monitoring tools like osquery and saposcol may also be flagged due to their need to access various system resources. Users should consider excluding these processes by their names or executable paths to prevent false alerts.
-- Common administrative commands like "sudo" and "pkexec" are often used in legitimate scenarios to change user IDs. To manage these, users can exclude specific command lines or process names that are known to be safe in their environment.
-- Automation tools such as Ansible, which may execute scripts with elevated privileges, can be excluded by identifying their command lines, such as those starting with "/usr/bin/python*ansible*".
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the privilege escalation, focusing on recent changes to system configurations and user permissions.
-- Review system logs and security alerts to determine if any other systems have been compromised or if there are signs of lateral movement.
-- Revoke any unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users to minimize the risk of future privilege escalation.
-- Apply patches and updates to the operating system and any vulnerable applications to mitigate known exploits.
-- Restore the system to a known good state using backups, ensuring that the backup is free from any malicious modifications.
-- Implement enhanced logging policies to capture detailed information on process executions and user activities, aiding in future investigations.
-- Integrate security tools such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate users and administrators on security best practices and the importance of maintaining least privilege access to reduce the risk of privilege escalation attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_uid_change_post_compilation.toml b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
index c5247e31261..64e954706a1 100644
--- a/rules/linux/privilege_escalation_uid_change_post_compilation.toml
+++ b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -65,48 +65,6 @@ sequence by host.id with maxspan=1m
   [process where host.os.type == "linux" and event.action in ("uid_change", "guid_change") and event.type == "change" and 
    user.id == "0"] by process.name
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via Recently Compiled Executable
-
-In Linux environments, compiling and executing programs is routine, but adversaries can exploit this by compiling malicious code to escalate privileges. They may compile a program that, when executed, alters user permissions to gain root access. The detection rule identifies this threat by monitoring sequences of compilation, execution, and unauthorized UID changes, flagging potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host.id where the potential privilege escalation was detected.
-- Examine the process.args field from the initial compilation event to determine the source code or script being compiled, which may provide insight into the intent of the executable.
-- Investigate the file.name field from the file creation event to identify the newly created executable file and verify its legitimacy.
-- Analyze the process.name field from the execution event to understand which program was executed and assess if it aligns with typical user behavior.
-- Check the process.name field from the UID change event to identify the process responsible for altering user permissions and determine if it is a known privilege escalation tool or exploit.
-- Use Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve detailed information about the suspicious process, including its parent process and command line arguments.
-- Investigate the user.id field across all events to confirm whether the actions were performed by a non-root user initially and escalated to root privileges.
-- Correlate the timeline of events to verify if the sequence of compilation, execution, and UID change occurred within the specified maxspan of 1 minute, indicating a rapid privilege escalation attempt.
-- Review system logs and audit logs on the affected host for any additional suspicious activity or anomalies around the time of the alert.
-- Consult threat intelligence sources to check if the identified process names or file names are associated with known privilege escalation exploits or malware.
-
-### False positive analysis
-
-- Developers and system administrators frequently compile and execute programs as part of their routine tasks, which can trigger this rule. These activities are typically benign and not indicative of malicious behavior.
-- Automated build systems or continuous integration pipelines may compile and execute code, leading to false positives. These systems often run under specific user accounts that can be excluded from monitoring.
-- Educational environments where students compile and execute code as part of their learning process can also generate false positives. Identifying and excluding these user accounts or specific directories can help reduce noise.
-- To manage these false positives, users can create exceptions for known non-threatening behaviors by excluding specific user IDs, process names, or directories from the rule. This can be done by updating the detection rule to ignore certain patterns or by maintaining a whitelist of trusted users and processes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the malicious executable and determine if other systems are affected.
-- Review system logs and security alerts to gather evidence of the privilege escalation attempt and any subsequent actions taken by the adversary.
-- Revoke any unauthorized changes to user permissions and reset credentials for affected accounts to prevent further exploitation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring future incidents can be detected more effectively.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
-- Apply system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
index 3ae139ff32c..6d8b2ad4a2c 100644
--- a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
+++ b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -74,52 +74,6 @@ and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or
   process.args:/usr/bin/python*
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 UID Elevation from Previously Unknown Executable
-
-In Linux environments, user ID (UID) elevation is a critical function allowing users to gain root privileges. Adversaries exploit this by using unknown executables to hijack execution flows, often via rootkits, to stealthily gain root access. The detection rule identifies such anomalies by monitoring UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific unknown executable that triggered the UID elevation event.
-- Cross-reference the process executable path with known safe paths to confirm it is indeed unknown or suspicious.
-- Examine the parent process name and its command-line arguments to understand the context in which the executable was run.
-- Use Osquery to list all processes running on the host and identify any other instances of the suspicious executable:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE path = '<suspicious_executable_path>';
-  ```
-- Investigate the file attributes and metadata of the unknown executable, such as creation and modification times, to determine if it was recently introduced.
-- Check the system logs for any recent changes or installations that might correlate with the appearance of the unknown executable.
-- Analyze the network activity from the host to identify any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
-- Review user activity logs to determine if any legitimate user actions could have inadvertently triggered the UID elevation.
-- Investigate other security alerts or anomalies on the host that might be related to the same timeframe as the UID elevation event.
-- Consult threat intelligence sources to see if the unknown executable or its hash is associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate software updates or installations introduce new executables that are not yet recognized by the detection rule. These can include software from trusted vendors that temporarily reside in non-standard directories.
-- System administrators might execute scripts or binaries from custom paths for maintenance or monitoring purposes, which could trigger the rule if these paths are not included in the exceptions.
-- Developers and IT staff often compile and run custom applications or scripts in development environments, which may not be accounted for in the predefined safe paths.
-- To manage these false positives, users can update the detection rule to include exceptions for specific paths or executables that are verified as safe. This can be done by adding these paths to the `process.executable` exclusion list or by specifying known safe process names in the `process.name` exclusion list.
-- Regularly review and update the list of exceptions to ensure that new legitimate software and processes are accounted for, reducing unnecessary alerts while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the unknown executable and determine how it was introduced into the system.
-- Review system logs and use forensic tools to trace the execution flow and identify any rootkits or malicious modifications.
-- Remove any identified malicious executables and rootkits from the system, ensuring all traces are eradicated.
-- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and UID changes for future monitoring.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Conduct a security review and harden the system by implementing least privilege access, disabling unnecessary services, and using security tools like SELinux or AppArmor."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
index 1469adc5c9b..bb29544825f 100644
--- a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
+++ b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
@@ -1,7 +1,9 @@
 [metadata]
 creation_date = "2022/08/30"
-integration = ["endpoint"]
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
+min_stack_version = "8.13.0"
+min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 updated_date = "2025/01/08"
 
 [rule]
@@ -12,7 +14,7 @@ or escape container security boundaries. Threat actors have utilized this binary
 host and access other resources or escalate privileges.
 """
 from = "now-9m"
-index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*"]
+index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Namespace Manipulation Using Unshare"
@@ -67,59 +69,17 @@ tags = [
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action : ("exec", "exec_event") and
+process where host.os.type == "linux" and event.type == "start" and event.action : ("exec", "exec_event", "start") and
 process.executable: "/usr/bin/unshare" and
 not process.parent.executable: ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") and
 not process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Namespace Manipulation Using Unshare
-
-Unshare is a Linux utility that allows processes to run with a new set of namespaces, effectively isolating them from the rest of the system. While useful for containerization and sandboxing, adversaries can exploit unshare to bypass security boundaries, escalate privileges, or access unauthorized resources. The detection rule identifies suspicious unshare executions by filtering out benign parent processes and specific arguments, focusing on potential misuse indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process executable is "/usr/bin/unshare" and verify the absence of benign parent processes such as "/usr/bin/udevadm" or "*/lib/systemd/systemd-udevd".
-- Check the process arguments to ensure they do not match "/usr/bin/snap", which is considered benign in this context.
-- Investigate the parent process name to ensure it is not "zz-proxmox-boot" or "java", as these are excluded from the rule.
-- Use process lineage analysis to trace the ancestry of the unshare process and identify any potentially malicious parent processes.
-- Examine the user account associated with the unshare process to determine if it has a history of suspicious activity or if it is a privileged account.
-- Utilize Osquery to gather additional context about the process. For example, run the query: `SELECT * FROM processes WHERE name = 'unshare';` to gather details about the process state and associated metadata.
-- Investigate any network connections or file system changes initiated by the unshare process to identify potential lateral movement or data exfiltration.
-- Review system logs for any other suspicious activities or anomalies around the time the unshare process was executed.
-- Correlate the unshare activity with other security alerts or incidents to determine if it is part of a larger attack campaign.
-- Consult threat intelligence sources to check for any known threat actors or campaigns that utilize unshare for privilege escalation or container escape techniques.
-
-### False positive analysis
-
-- System management tools: Certain system management tools and scripts may legitimately use unshare for routine operations, such as system updates or configuration changes. Users can handle these by identifying the specific tools and adding their parent processes to the exclusion list.
-- Development environments: Developers might use unshare during software development and testing to create isolated environments. To manage these, users can exclude processes initiated by known development tools or scripts.
-- Container orchestration: Some container orchestration platforms may use unshare as part of their normal operations. Users should identify these platforms and exclude their associated processes to prevent false positives.
-- Automated scripts: Automated scripts that perform system maintenance or monitoring might invoke unshare. Users can manage these by reviewing the scripts and excluding their parent processes if they are deemed non-threatening.
-- Custom administrative tasks: Administrators may use unshare for custom tasks that require namespace isolation. Users should document these tasks and exclude the relevant processes to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on process trees and any unauthorized use of the unshare command.
-- Review system logs and security alerts to determine if privilege escalation or container escape attempts were successful.
-- Terminate any suspicious processes that were initiated using the unshare command and assess the integrity of the system.
-- Escalate the incident to the security operations team if evidence of privilege escalation or data exfiltration is found.
-- Restore the system from a known good backup if unauthorized changes or persistent threats are detected.
-- Implement enhanced logging policies to capture detailed process execution and namespace changes for future investigations.
-- Integrate security tools with SIEM solutions to improve detection capabilities for namespace manipulation and privilege escalation attempts.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Educate users and administrators on the risks associated with namespace manipulation and enforce the principle of least privilege to reduce attack surfaces."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_writable_docker_socket.toml b/rules/linux/privilege_escalation_writable_docker_socket.toml
index 434624b436a..be6a9360a51 100644
--- a/rules/linux/privilege_escalation_writable_docker_socket.toml
+++ b/rules/linux/privilege_escalation_writable_docker_socket.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -67,48 +67,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock"))
 ) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation through Writable Docker Socket
-
-Docker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. If misconfigured to be writable by unauthorized users, adversaries can exploit this to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious processes attempting to interact with Docker sockets without root or group privileges, signaling possible privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on `process.name` and `process.args` fields.
-- Verify the user and group IDs associated with the process using `user.Ext.real.id` and `group.Ext.real.id` fields to confirm they are not root or part of the docker group.
-- Check the system logs for any recent changes to Docker socket permissions that might have allowed unauthorized write access.
-- Use Osquery to list all processes interacting with Docker sockets by running: `SELECT pid, name, path FROM processes WHERE path LIKE '/var/run/docker.sock' OR path LIKE '/var/run/dockershim.sock';`
-- Investigate the user account associated with the process to determine if it has a history of legitimate Docker usage or if it might be compromised.
-- Examine the command history of the user to identify any recent commands that could indicate an attempt to exploit Docker socket permissions.
-- Analyze network logs to detect any unusual outbound connections from the host that might suggest data exfiltration or communication with a command and control server.
-- Review Docker daemon logs for any suspicious container creation or execution events that align with the alert timestamp.
-- Check for any newly created or modified containers on the host that could have been used to escalate privileges.
-- Investigate the system for any additional indicators of compromise, such as unauthorized file modifications or new user accounts, that might correlate with the alert.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators or authorized users may perform legitimate tasks that involve interacting with Docker sockets, such as maintenance or configuration changes. These actions can trigger the rule if they are not executed with root or group privileges. To manage this, users can create exceptions for specific user IDs or groups known to perform these tasks regularly.
-- Automated scripts or tools: Some automated scripts or monitoring tools might interact with Docker sockets as part of their normal operation. If these tools are known and trusted, users can exclude their process names or specific arguments from triggering the rule.
-- Development environments: In development environments, developers might frequently use Docker commands to test applications. If these actions are non-threatening and part of regular development workflows, users can exclude specific user IDs or process arguments associated with these activities.
-- Container orchestration systems: Systems like Kubernetes might interact with Docker sockets as part of their orchestration tasks. If these interactions are expected and secure, users can create exceptions for the specific processes or arguments used by these systems.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Investigate the source of the unauthorized access by reviewing logs and identifying any suspicious user accounts or processes that interacted with the Docker socket.
-- Terminate any unauthorized containers or processes that were started using the writable Docker socket to prevent further exploitation.
-- Change permissions on the Docker socket to restrict write access to only the root user and the docker group, ensuring no unauthorized users can access it.
-- Conduct a thorough review of user accounts and group memberships to ensure only authorized personnel have access to Docker-related privileges.
-- Implement enhanced logging for Docker daemon activities and socket interactions to capture detailed information for future investigations.
-- Integrate security monitoring tools with SIEM solutions to detect and alert on suspicious Docker socket activities in real-time.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, ensuring no backdoors or malicious modifications remain.
-- Apply security patches and updates to the Docker daemon and related components to mitigate known vulnerabilities.
-- Educate and train system administrators and users on secure Docker practices and the importance of maintaining strict access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_credentials_keychains.toml b/rules/macos/credential_access_credentials_keychains.toml
index 2acc0d53ffc..10a16206576 100644
--- a/rules/macos/credential_access_credentials_keychains.toml
+++ b/rules/macos/credential_access_credentials_keychains.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -94,49 +94,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                    "/usr/local/jamf/bin/jamf",
                                                    "/Applications/Microsoft Defender.app/Contents/MacOS/wdavdaemon")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Access to Keychain Credentials Directories
-
-macOS keychains securely store user credentials, such as passwords and certificates, essential for system and application authentication. Adversaries may target these directories to extract sensitive information, bypassing security measures. The detection rule identifies suspicious access attempts by monitoring process activities related to keychain directories, excluding legitimate operations and known safe executables, thus highlighting potential credential theft activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and arguments that triggered the rule, focusing on the `process.args` field to understand which keychain directory was accessed.
-- Examine the `process.parent.executable` and `process.executable` fields to determine the origin of the process and assess whether it is a known or unknown application.
-- Check the `process.Ext.effective_parent.executable` field to identify the effective parent process and evaluate if it is a legitimate application or potentially malicious.
-- Use Osquery to list all processes currently accessing keychain directories with a query like: `SELECT pid, name, path FROM processes WHERE path LIKE '/Users/%/Library/Keychains/%' OR path LIKE '/Library/Keychains/%';`
-- Investigate the user account associated with the process by examining the `process.user.name` field to determine if the activity aligns with the user's typical behavior.
-- Correlate the timestamp of the alert with other system logs to identify any concurrent suspicious activities or anomalies.
-- Review recent login events and user activity to determine if there were any unauthorized access attempts around the time of the alert.
-- Analyze network connections initiated by the process using network monitoring tools to identify any suspicious outbound connections that may indicate data exfiltration.
-- Check for any recent changes or installations of software on the system that could explain the process's behavior, focusing on software that interacts with keychain data.
-- Consult threat intelligence sources to determine if the process or its parent is associated with known malicious activity or campaigns targeting macOS keychain data.
-
-### False positive analysis
-
-- Legitimate applications accessing keychain directories for routine operations may trigger false positives. For example, security software like Microsoft Defender or management tools like JAMF may access keychain data as part of their normal functionality.
-- Users can manage these false positives by adding exceptions for known safe executables and processes. This can be done by updating the detection rule to exclude specific process arguments or executables that are verified as non-threatening.
-- Regularly review and update the list of excluded processes and executables to ensure that only trusted applications are allowed access without triggering alerts.
-- Consider the context of the access attempt, such as the time of day or the user account involved, to further refine the detection rule and reduce false positives.
-- Collaborate with IT and security teams to identify and document legitimate use cases for keychain access, ensuring these are accounted for in the detection rule exceptions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the process and user account involved in the suspicious access attempt, using available logs and forensic tools.
-- Review the process tree and command-line arguments to understand the context of the access attempt and determine if it was malicious.
-- If malicious activity is confirmed, reset passwords and revoke any compromised credentials associated with the affected keychain.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging for keychain access attempts and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Review and update security policies to ensure that only authorized applications and users have access to keychain directories.
-- Restore the system to its operational state by removing any malicious software and applying security patches and updates.
-- Conduct a post-incident review to identify gaps in security controls and improve detection and response capabilities.
-- Implement hardening measures such as enabling two-factor authentication and using strong, unique passwords for keychain-protected services."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
index 28c97257961..4eea3dcd5ff 100644
--- a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
+++ b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,48 +62,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:start and
  process.name:(defaults or mkpassdb) and process.args:(ShadowHashData or "-dump")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Dumping Account Hashes via Built-In Commands
-
-On macOS, built-in commands like `defaults` and `mkpassdb` can be exploited by adversaries to extract user account hashes, which are crucial for credential access. These hashes, once obtained, can be cracked or used for unauthorized access and lateral movement within a network. The detection rule identifies suspicious process activities involving these commands and specific arguments, signaling potential credential dumping attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `defaults` or `mkpassdb` commands in the process execution logs, focusing on the `process.name` and `process.args` fields.
-- Examine the `event.category`, `host.os.type`, and `event.type` fields to ensure the alert is specific to macOS and involves a process start event.
-- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it is an unusual account for such activity.
-- Investigate the parent process of the suspicious command execution to understand the context and origin of the command.
-- Use Osquery to list recent processes executed by the user in question to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE user = '<suspicious_user>' ORDER BY start_time DESC LIMIT 10;`
-- Analyze system logs for any other unusual activities or errors around the time of the alert to gather additional context.
-- Verify if there are any recent changes or updates to the system that might explain the use of these commands legitimately.
-- Check for any network connections initiated by the system around the time of the alert to identify potential data exfiltration attempts.
-- Review historical data to determine if there have been previous instances of similar command executions on the host.
-- Correlate the findings with other security tools and logs to identify if this activity is part of a broader attack pattern or isolated incident.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use the `defaults` or `mkpassdb` commands for legitimate purposes, such as managing user settings or performing system maintenance. These activities can trigger the detection rule, leading to false positives.
-- Software installations or updates: Certain software installations or updates might invoke these commands as part of their setup or configuration processes, which can be mistaken for malicious activity.
-- Automated scripts: Scripts designed for system management or user account maintenance might include these commands, causing alerts even though they are part of regular operations.
-- To manage false positives, users can create exceptions for known benign processes or scripts by whitelisting specific command executions that are verified as non-threatening. This can be done by identifying the process IDs or command patterns associated with legitimate activities and excluding them from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the presence of unauthorized access by reviewing logs and identifying any suspicious activities related to the `defaults` or `mkpassdb` commands.
-- Capture and preserve forensic evidence, including process execution details and any associated files, to support further analysis and potential legal actions.
-- Reset passwords for all affected accounts and consider implementing multi-factor authentication to enhance security.
-- Review and update security policies to ensure that only authorized personnel have access to sensitive commands and data.
-- Implement enhanced logging and monitoring for macOS systems to detect similar activities in the future, focusing on process execution and command-line arguments.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze potential threats more effectively.
-- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for further investigation and response.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are properly set.
-- Conduct a post-incident review to identify gaps in the security posture and implement hardening measures, such as disabling unnecessary services and restricting the use of built-in commands."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_dumping_keychain_security.toml b/rules/macos/credential_access_dumping_keychain_security.toml
index 010132600ff..e9e879c94a9 100644
--- a/rules/macos/credential_access_dumping_keychain_security.toml
+++ b/rules/macos/credential_access_dumping_keychain_security.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,49 +58,6 @@ type = "eql"
 query = '''
 process where host.os.type == "macos" and event.type in ("start", "process_started") and process.args : "dump-keychain" and process.args : "-d"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Dumping of Keychain Content via Security Command
-
-Keychains in macOS securely store user credentials, including passwords and certificates. Adversaries exploit this by using commands to extract keychain data, potentially gaining unauthorized access to sensitive information. The detection rule identifies suspicious activity by monitoring for specific command-line arguments associated with keychain dumping, alerting analysts to potential credential theft attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the "dump-keychain" and "-d" arguments in the process arguments, as these are indicative of keychain dumping attempts.
-- Identify the user account associated with the process to determine if the activity aligns with expected behavior or if it is potentially malicious.
-- Examine the parent process of the suspicious activity to understand how the keychain dumping command was initiated and if it was part of a larger chain of suspicious events.
-- Check the timestamp of the event to correlate with other security events or logs that might provide additional context or indicate a broader attack pattern.
-- Investigate the source IP address and geolocation, if available, to assess whether the activity originated from a trusted network or an unusual location.
-- Use Osquery to gather more information about the process. For example, run the following query to list all processes with similar command-line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%dump-keychain%' AND cmdline LIKE '%-d%';`
-- Analyze recent login events for the user account to determine if there were any unauthorized access attempts or anomalies around the time of the alert.
-- Review system logs for any other unusual activities or errors that occurred around the same time as the keychain dumping attempt.
-- Check for any recent changes to user permissions or system configurations that might have facilitated the keychain dumping attempt.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors currently exploiting keychain dumping techniques, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Routine administrative tasks or legitimate software updates may trigger the rule if they involve accessing or managing keychain data, as these processes might use similar command-line arguments.
-- Security or IT personnel conducting authorized audits or system checks might inadvertently match the rule criteria when verifying keychain integrity or performing backups.
-- Developers or advanced users using scripts or automation tools to manage their keychain entries for legitimate purposes could also be flagged.
-- To manage these false positives, users can create exceptions for known and trusted processes or users by whitelisting specific command invocations or user accounts that regularly perform these actions.
-- Implementing a baseline of normal keychain access patterns can help differentiate between legitimate and suspicious activities, allowing for more accurate filtering of alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the presence of unauthorized keychain access by reviewing system logs and correlating with the detected command-line arguments.
-- Identify and terminate any suspicious processes related to the keychain dumping activity to halt ongoing credential theft attempts.
-- Change all potentially compromised credentials stored in the keychain, including passwords for Wi-Fi, websites, and any other services.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed command-line activity and process execution on macOS systems for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all security patches are applied.
-- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
-- Educate users on security best practices, including recognizing phishing attempts and the importance of using strong, unique passwords for different services."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_kerberosdump_kcc.toml b/rules/macos/credential_access_kerberosdump_kcc.toml
index 6f422efeb4d..ef37c8198c4 100644
--- a/rules/macos/credential_access_kerberosdump_kcc.toml
+++ b/rules/macos/credential_access_kerberosdump_kcc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,48 +62,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   process.name:kcc and
   process.args:copy_cred_cache
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kerberos Cached Credentials Dumping
-
-Kerberos is a network authentication protocol that uses tickets to allow nodes to prove their identity securely. In macOS environments, the `kcc` utility manages these tickets. Adversaries may exploit `kcc` to extract cached credentials, facilitating unauthorized access and lateral movement. The detection rule identifies suspicious `kcc` activity by monitoring process initiation and specific arguments, signaling potential credential dumping attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `kcc` process activity with the `copy_cred_cache` argument, as indicated by the query fields `process.name:kcc` and `process.args:copy_cred_cache`.
-- Correlate the timestamp of the suspicious `kcc` activity with other logs to identify any concurrent or subsequent suspicious activities, such as unusual network connections or file access.
-- Investigate the user account associated with the `kcc` process initiation to determine if the account has a history of legitimate use of Kerberos utilities or if it shows signs of compromise.
-- Examine the parent process of the `kcc` activity to understand how the process was initiated and whether it was triggered by a legitimate application or a potentially malicious script.
-- Use Osquery to gather additional context about the system state and running processes. For example, execute the following Osquery query to list all processes related to Kerberos activities: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%kcc%' OR cmdline LIKE '%kcc%';`
-- Check for any recent changes in user privileges or group memberships that could indicate an attempt to escalate privileges or gain unauthorized access to Kerberos tickets.
-- Analyze network logs to identify any unusual outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
-- Review historical logs for any previous instances of `kcc` usage on the host to determine if this is a recurring pattern or an isolated incident.
-- Investigate any other processes or scripts executed around the same time as the `kcc` activity to identify potential lateral movement or further credential access attempts.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar Kerberos credential dumping techniques.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use the `kcc` utility for legitimate purposes, such as managing Kerberos tickets during maintenance or troubleshooting, which could trigger the detection rule.
-- Automated scripts: Some automated scripts or management tools might invoke `kcc` with similar arguments for regular operations, leading to false positives.
-- Testing environments: In environments where security tools or protocols are being tested, `kcc` might be used frequently, causing benign alerts.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that regularly use `kcc` for legitimate purposes. This can be done by excluding certain user accounts or process arguments from triggering the alert, ensuring that only truly suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation to confirm the presence of unauthorized `kcc` activity by reviewing process logs and correlating with other security events.
-- Identify and terminate any suspicious processes related to `kcc` and any other unauthorized access attempts.
-- Change passwords for any accounts that may have been compromised, focusing on those with elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the affected system from a known good backup to ensure no malicious artifacts remain.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
index 370d673c43c..fc4b71083a3 100644
--- a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
+++ b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -68,52 +68,6 @@ process where host.os.type == "macos" and event.action == "exec" and
  process.command_line : ("*Chrome*", "*Chromium*", "*Opera*", "*Safari*", "*Brave*", "*Microsoft Edge*", "*Firefox*") and
  not process.parent.executable : "/Applications/Keeper Password Manager.app/Contents/Frameworks/Keeper Password Manager Helper*/Contents/MacOS/Keeper Password Manager Helper*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Keychain Password Retrieval via Command Line
-
-macOS Keychain securely stores user credentials, including passwords and certificates. Adversaries exploit command-line tools to extract these credentials, targeting applications like browsers. The detection rule identifies suspicious command executions involving keychain access commands and browser references, excluding legitimate password manager activities, to flag potential credential theft attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious command executions involving the `security` process with arguments `-wa` or `-ga` and `find-generic-password` or `find-internet-password`.
-- Verify the command line details to check for references to browsers such as Chrome, Chromium, Opera, Safari, Brave, Microsoft Edge, or Firefox, which may indicate an attempt to access stored credentials.
-- Cross-reference the process parent executable to ensure it is not originating from a legitimate password manager, specifically checking against the Keeper Password Manager.
-- Use Osquery to gather additional context on the process execution. For example, run the following query to list recent executions of the `security` command:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'security' AND cmdline LIKE '%find-generic-password%' OR cmdline LIKE '%find-internet-password%';
-  ```
-- Investigate the user account associated with the suspicious process to determine if it aligns with expected behavior or if it might be compromised.
-- Check system logs for any other unusual activities or errors around the time of the alert to identify potential correlations or additional indicators of compromise.
-- Analyze network activity from the host to detect any suspicious outbound connections that might suggest data exfiltration.
-- Review recent login events on the system to identify any unauthorized access attempts that could be related to the alert.
-- Examine the file system for any newly created or modified files that could be associated with credential theft tools or scripts.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors using similar techniques, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate applications or scripts that access the keychain for routine operations may trigger false positives. For example, automated scripts that manage browser settings or credentials for enterprise environments might use similar command-line arguments.
-- Developers or IT administrators using command-line tools for debugging or managing browser settings could inadvertently match the detection criteria.
-- Users can manage these false positives by creating exceptions for known, trusted applications or scripts that frequently access the keychain. This can be done by adding specific process names or command-line patterns to an exclusion list.
-- Regularly review and update the exclusion list to ensure it reflects current legitimate activities, especially after software updates or changes in IT policies.
-- Consider implementing additional context checks, such as verifying the user account executing the command or the network location, to differentiate between benign and malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the alert by reviewing the command execution logs and identifying any unauthorized access to keychain data.
-- If unauthorized access is confirmed, reset all potentially compromised credentials stored in the keychain, including Wi-Fi, website passwords, and any other sensitive information.
-- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed command-line activity and process execution on macOS systems for future investigations.
-- Integrate security tools with SIEM solutions to correlate events and improve detection capabilities for similar threats.
-- Restore the system to its operational state by ensuring all security patches and updates are applied, and conduct a full malware scan to remove any persistent threats.
-- Educate users on the importance of using strong, unique passwords and the risks associated with storing sensitive information in easily accessible locations.
-- Review and update security policies to include regular audits of keychain access and implement multi-factor authentication for accessing sensitive applications and data.
-- Utilize MITRE ATT&CK framework to continuously assess and improve defenses against credential access techniques, focusing on T1555 (Credentials from Password Stores)."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_mitm_localhost_webproxy.toml b/rules/macos/credential_access_mitm_localhost_webproxy.toml
index 00c7c6d787f..6e915a16c92 100644
--- a/rules/macos/credential_access_mitm_localhost_webproxy.toml
+++ b/rules/macos/credential_access_mitm_localhost_webproxy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -66,48 +66,6 @@ event.category:process and host.os.type:macos and event.type:start and
                                   "/usr/libexec/xpcproxy") and
  not process.Ext.effective_parent.executable : ("/Applications/Proxyman.app/Contents/MacOS/Proxyman" or "/Applications/Incoggo.app/Contents/MacOS/Incoggo.app")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WebProxy Settings Modification
-
-WebProxy settings in macOS manage how web traffic is routed, often used to enhance security or performance. Adversaries may exploit these settings to intercept or redirect traffic, potentially capturing sensitive data like credentials. The detection rule identifies suspicious use of the `networksetup` command to alter proxy settings, excluding known legitimate applications, thus highlighting potential unauthorized modifications indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `networksetup` command with arguments like `-setwebproxy`, `-setsecurewebproxy`, or `-setautoproxyurl` in the process arguments.
-- Verify the process parent executable to ensure it is not one of the known legitimate applications such as `/Library/PrivilegedHelperTools/com.80pct.FreedomHelper`, `/Applications/Fiddler Everywhere.app/Contents/Resources/app/out/WebServer/Fiddler.WebUi`, or `/usr/libexec/xpcproxy`.
-- Check the effective parent executable to confirm it is not `/Applications/Proxyman.app/Contents/MacOS/Proxyman` or `/Applications/Incoggo.app/Contents/MacOS/Incoggo.app`.
-- Use Osquery to list all current proxy settings on the affected macOS system to identify any unauthorized changes. Example query: `SELECT * FROM preferences WHERE domain = 'com.apple.networkservices' AND key LIKE '%Proxy%';`
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that might correlate with the proxy settings modification.
-- Cross-reference the event with network logs to identify any unusual outbound connections or data exfiltration attempts following the proxy change.
-- Analyze other processes running on the host at the time of the alert to detect any additional suspicious activities or malware presence.
-- Review system logs for any failed or successful authentication attempts around the time of the alert to identify potential unauthorized access.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns targeting macOS systems.
-
-### False positive analysis
-
-- Known false positives for the WebProxy Settings Modification rule include legitimate applications that modify proxy settings for valid reasons, such as network management tools or security applications. These applications may use the `networksetup` command as part of their normal operation.
-- Users can manage these false positives by creating exceptions for known legitimate applications. This can be done by adding the application's executable path to the exclusion list in the detection rule, ensuring that routine and non-threatening behaviors are not flagged as suspicious.
-- Specific applications that may trigger false positives include network diagnostic tools, VPN clients, and security software that require proxy configuration to function correctly. Users should verify the legitimacy of these applications and update the exclusion list accordingly.
-- Regularly review and update the exclusion list to accommodate new legitimate applications or updates to existing ones, ensuring that the detection rule remains effective without generating unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
-- Review the process execution details and command-line arguments to confirm unauthorized changes to WebProxy settings.
-- Check for any suspicious network traffic or connections that may indicate data interception or redirection.
-- Investigate the user account associated with the process execution to determine if it has been compromised.
-- Revert any unauthorized changes to the WebProxy settings using the `networksetup` command to restore normal network configuration.
-- Conduct a thorough scan of the system for malware or other indicators of compromise using updated security tools.
-- Escalate the incident to the security operations team if evidence of credential theft or broader compromise is found.
-- Implement enhanced logging for network configuration changes and monitor for any future unauthorized modifications.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures.
-- Apply security hardening measures, such as restricting access to network configuration commands and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
index 2a80fe56946..40b3b2d181e 100644
--- a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
+++ b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -57,48 +57,6 @@ type = "threshold"
 query = '''
 event.category:process and host.os.type:macos and event.type:start and process.name:"sshd-keygen-wrapper" and process.parent.name:launchd
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential macOS SSH Brute Force Detected
-
-SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-keygen-wrapper` process is involved in SSH key generation. Adversaries may exploit this by repeatedly attempting to generate keys to gain unauthorized access, a technique known as brute force. The detection rule identifies unusual activity by monitoring for excessive SSH key generation attempts, signaling potential brute force attacks.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the number of `sshd-keygen-wrapper` process executions and verify if it meets or exceeds the threshold of 20 executions from the same host.
-- Check the `host.os.type` field to ensure the operating system is macOS, as the rule is specific to this OS.
-- Investigate the `process.parent.name` field to confirm that the parent process is `launchd`, which is expected for legitimate SSH key generation activities.
-- Use Osquery to list all recent processes executed on the host to identify any unusual or unauthorized activities. Example query: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name = 'sshd-keygen-wrapper';`
-- Examine the `event.category` and `event.type` fields to ensure the event is categorized as a process start, which aligns with the rule's focus on process execution.
-- Correlate the timestamps of the `sshd-keygen-wrapper` executions with user login attempts or other authentication logs to identify any patterns or anomalies.
-- Investigate the user accounts associated with the `sshd-keygen-wrapper` executions to determine if they are legitimate users or potentially compromised accounts.
-- Check for any recent changes in SSH configuration files on the host that might indicate tampering or misconfiguration that could facilitate brute force attempts.
-- Review network logs for any unusual inbound SSH traffic to the host, which might indicate external brute force attempts.
-- Analyze historical data to determine if this host has a pattern of similar alerts or if this is an isolated incident, which can help assess the severity and potential impact.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may perform legitimate tasks that involve generating multiple SSH keys, such as setting up new user accounts or configuring automated processes. These activities can trigger the detection rule as false positives.
-- Automated scripts or tools: Some automated scripts or tools used for system management or deployment may execute the `sshd-keygen-wrapper` process multiple times, leading to false positives.
-- Development environments: In development environments, developers might frequently generate SSH keys for testing purposes, which can be mistaken for brute force attempts.
-- To manage these false positives, users can create exceptions for known administrative activities or trusted scripts by excluding specific user accounts or processes from the detection rule. This can be done by refining the query to exclude certain conditions or by using allowlists for recognized non-threatening behaviors.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS host from the network to prevent further unauthorized access.
-- Review the system logs to identify the source IP addresses and user accounts involved in the excessive SSH key generation attempts.
-- Change passwords for all user accounts on the affected system and enforce strong password policies.
-- Investigate the source IP addresses for any known malicious activity or previous incidents.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Implement additional logging and monitoring for SSH activities, including successful and failed login attempts, to enhance future detection capabilities.
-- Integrate threat intelligence feeds to identify and block known malicious IP addresses attempting SSH brute force attacks.
-- Restore the system to its operational state by ensuring all unauthorized keys are removed and legitimate keys are verified.
-- Apply security patches and updates to the macOS system to mitigate any known vulnerabilities that could be exploited.
-- Harden the system by disabling SSH access for root accounts, using SSH key-based authentication, and configuring fail2ban or similar tools to block repeated failed login attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
index 7b07d7ec14b..ac83ec10af5 100644
--- a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
+++ b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -68,48 +68,6 @@ process where event.action == "exec" and host.os.type == "macos" and
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon",
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Prompt for Credentials with OSASCRIPT
-
-OSASCRIPT is a command-line utility in macOS used to execute AppleScript and other OSA language scripts. Adversaries may exploit it to display deceptive dialogs prompting users for credentials, mimicking legitimate requests. The detection rule identifies suspicious OSASCRIPT usage by monitoring specific command patterns and excluding known legitimate processes, thus highlighting potential credential phishing attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious `osascript` usage, focusing on the `process.command_line` field to identify if it includes patterns like `*display*dialog*password*` or `*display*dialog*passphrase*`.
-- Check the `process.parent.executable` field to determine the parent process of the `osascript` execution, ensuring it is not a known legitimate process such as `/usr/bin/sudo` or `/bin/bash` with specific command lines.
-- Investigate the `user.id` associated with the process to determine if the execution was performed by a privileged user, which might indicate a higher risk.
-- Examine the `process.Ext.effective_parent.executable` field to verify if the parent process is part of known legitimate applications like Jamf or Karabiner-Elements, which could explain the `osascript` usage.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list recent processes executed by the same user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM processes WHERE name = 'osascript' AND cmdline LIKE '%display dialog%');`
-- Analyze the timing of the `osascript` execution by reviewing the event timestamp to correlate with any user-reported suspicious activity or other security events.
-- Check system logs for any additional context or anomalies around the time of the `osascript` execution, such as login attempts or other process executions.
-- Investigate the network activity of the affected host around the time of the alert to identify any unusual outbound connections that might suggest data exfiltration.
-- Review any recent changes or updates to the system that might have introduced new scripts or applications capable of executing `osascript`.
-- Consult with the user of the affected system to determine if they recall any unexpected prompts or dialogs, which could provide insight into whether the alert was a false positive or a genuine phishing attempt.
-
-### False positive analysis
-
-- Legitimate administrative scripts: Some organizations use osascript in administrative scripts for legitimate purposes, such as automating system configurations or user notifications. These scripts might inadvertently match the detection criteria. To handle this, users can create exceptions for specific scripts by excluding their parent executable paths or command-line patterns.
-- Software management tools: Applications like JAMF or Karabiner-Elements may use osascript for legitimate functions, such as managing system settings or user preferences. These tools are often whitelisted in enterprise environments. Users can manage these false positives by adding exceptions for known software management tools, as indicated in the detection rule.
-- Terminal-based automation: Users or administrators might use Terminal to run osascript commands for automation tasks. If these tasks are routine and verified as non-threatening, users can exclude the Terminal executable path from the detection rule to prevent false positives.
-- System maintenance tasks: Some system maintenance tasks might involve osascript to prompt users for input or confirmation. If these tasks are part of regular system operations, users can exclude specific command-line patterns or parent processes associated with these tasks to reduce false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further credential theft or lateral movement.
-- Investigate the process tree to identify the source of the osascript execution and any associated scripts or files.
-- Terminate any suspicious processes related to the osascript activity to stop ongoing credential phishing attempts.
-- Review user accounts and credentials for any unauthorized access or changes, and reset passwords as necessary.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Implement enhanced logging for osascript executions and other scripting activities on macOS systems to improve future detection capabilities.
-- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious script executions and process behaviors.
-- Restore the system to its operational state by removing any malicious scripts or files and applying security patches and updates.
-- Conduct a security awareness training session for users to recognize and report phishing attempts and suspicious dialogs.
-- Harden macOS systems by restricting script execution permissions and implementing application whitelisting to prevent unauthorized script usage."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
index f48ef4293c4..6bbf5dbfbe9 100644
--- a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
+++ b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -66,48 +66,6 @@ file where event.action == "open" and host.os.type == "macos" and process.execut
  not process.code_signature.signing_id : "org.mozilla.firefox" and
  not Effective_process.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Web Browser Sensitive File Access
-
-Web browsers store sensitive data like cookies and login credentials in specific files. Adversaries exploit this by accessing these files using untrusted or unsigned processes, potentially stealing credentials. The detection rule identifies such unauthorized access on macOS by monitoring file access events, focusing on untrusted processes or scripts, and excluding known legitimate applications. This helps in identifying potential credential theft attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file accessed and the untrusted process involved, focusing on the `file.name` and `process.executable` fields.
-- Verify the legitimacy of the process by checking the `process.code_signature.trusted` and `process.code_signature.exists` fields to confirm if the process is unsigned or untrusted.
-- Investigate the process's parent process using the `process.parent.executable` field to determine if it was spawned by a legitimate application or script.
-- Check the `process.name` field to see if the process is `osascript`, which could indicate a script-based attempt to access sensitive files.
-- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE name = '<process_name>';` to retrieve details like process path, arguments, and parent process.
-- Examine recent system logs for any unusual activity around the time of the alert, focusing on login events or other process executions that might correlate with the suspicious access.
-- Cross-reference the `host.os.type` field to ensure the alert pertains to a macOS system, confirming the environment context for the investigation.
-- Investigate the user account associated with the process by checking the `user.name` field to determine if the activity aligns with the user's typical behavior.
-- Review any recent changes or installations on the system that might have introduced the untrusted process, focusing on software updates or new applications.
-- Consult threat intelligence sources to check if the process or file access pattern matches known malicious activity or indicators of compromise.
-
-### False positive analysis
-
-- Legitimate applications or scripts that access browser files for non-malicious purposes, such as backup utilities or browser extensions, may trigger this rule. Users should verify the legitimacy of these applications and consider adding them to an exclusion list if they are frequently flagged.
-- System maintenance or security software that scans or interacts with browser files might be mistakenly identified as suspicious. Users can create exceptions for these trusted processes by adding their code signatures or executable paths to the exclusion criteria.
-- Developers or IT personnel using automation scripts that interact with browser data for testing or configuration purposes may also cause false positives. It is advisable to review these scripts and, if deemed safe, exclude them from the detection rule.
-- Updates or new installations of legitimate software that temporarily lack a recognized code signature might be flagged. Users should monitor these events and update the exclusion list once the software is verified and trusted.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the untrusted process or script that accessed the sensitive files, using endpoint detection and response (EDR) tools.
-- Review system and application logs to trace the origin and timeline of the suspicious activity, focusing on any anomalies around the time of the alert.
-- Verify the integrity of the accessed files and check for any unauthorized changes or data exfiltration.
-- If credentials are suspected to be compromised, initiate a password reset for affected accounts and review access logs for any unauthorized logins.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
-- Integrate threat intelligence feeds to correlate the activity with known threat actors or campaigns, leveraging MITRE ATT&CK framework for context.
-- Restore the system to its operational state by removing any malicious processes or scripts and applying security patches and updates.
-- Harden the system by implementing application whitelisting, ensuring all software is signed and trusted, and educating users on recognizing phishing attempts and suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_systemkey_dumping.toml b/rules/macos/credential_access_systemkey_dumping.toml
index 9a744c4d047..01434aa4c83 100644
--- a/rules/macos/credential_access_systemkey_dumping.toml
+++ b/rules/macos/credential_access_systemkey_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -60,48 +60,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   process.args:("/private/var/db/SystemKey" or "/var/db/SystemKey") and
   not process.Ext.effective_parent.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SystemKey Access via Command Line
-
-In macOS, keychains securely store user credentials, including passwords and certificates. Adversaries may exploit command-line access to extract keychain data, gaining unauthorized credentials. The detection rule identifies suspicious process activities targeting SystemKey paths, excluding legitimate security processes, to flag potential credential theft attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious process activities targeting SystemKey paths, specifically checking the `process.args` field for "/private/var/db/SystemKey" or "/var/db/SystemKey".
-- Verify the `event.category` and `event.type` fields to ensure the event is related to a process start or initiation on a macOS host.
-- Examine the `process.Ext.effective_parent.executable` field to confirm that the process is not a legitimate security process, such as the Elastic Endpoint.
-- Use Osquery to list all processes that have accessed the SystemKey paths recently with a query like: `SELECT pid, name, path FROM processes WHERE path LIKE '/private/var/db/SystemKey%' OR path LIKE '/var/db/SystemKey%';`
-- Investigate the parent process of the suspicious activity by checking the `process.parent.name` and `process.parent.executable` fields to understand the origin of the process.
-- Check the `host.name` and `host.ip` fields to identify the affected system and correlate with any other suspicious activities on the same host.
-- Review user activity on the affected host by examining the `user.name` field to determine if the activity aligns with expected user behavior.
-- Analyze historical data for similar process activities on the same host or across the environment to identify patterns or repeated attempts.
-- Cross-reference the `process.name` and `process.executable` fields with known malicious or suspicious binaries to assess the threat level.
-- Consult threat intelligence sources to determine if the observed behavior or process is associated with known adversary techniques or campaigns.
-
-### False positive analysis
-
-- Legitimate security software or system maintenance tools may access SystemKey paths as part of routine operations, leading to false positives. Users should identify these processes and consider excluding them from the detection rule.
-- macOS updates or system diagnostics might trigger access to SystemKey paths. Users can monitor update schedules and correlate them with alerts to determine if they are false positives.
-- Custom scripts or administrative tools developed in-house that require access to keychain data for legitimate purposes may also be flagged. Users should document these scripts and create exceptions for them in the detection rule.
-- Security audits or compliance checks performed by authorized personnel might involve accessing SystemKey paths. Users should ensure these activities are logged and recognized as non-threatening, adjusting the rule to exclude them if necessary.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify any unauthorized processes or users accessing the SystemKey paths, focusing on the process arguments and parent processes.
-- Review system logs and security alerts to determine the scope of the breach and identify any other potentially compromised systems.
-- Terminate any suspicious processes identified during the investigation that are accessing the SystemKey paths without legitimate reasons.
-- Change all passwords and credentials stored in the keychain on the affected system and any other systems where the same credentials are used.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution data and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by reinstalling the operating system and applications, ensuring all security patches and updates are applied.
-- Harden the system by disabling unnecessary services, enforcing strong password policies, and implementing multi-factor authentication to reduce the risk of future credential theft."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_apple_softupdates_modification.toml b/rules/macos/defense_evasion_apple_softupdates_modification.toml
index 4ac545ec56e..44a47192117 100644
--- a/rules/macos/defense_evasion_apple_softupdates_modification.toml
+++ b/rules/macos/defense_evasion_apple_softupdates_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -60,48 +60,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.name:defaults and
  process.args:(write and "-bool" and (com.apple.SoftwareUpdate or /Library/Preferences/com.apple.SoftwareUpdate.plist) and not (TRUE or true))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SoftwareUpdate Preferences Modification
-
-In macOS environments, the 'defaults' command is used to modify system and application preferences, including SoftwareUpdate settings. Adversaries may exploit this to disable security updates, weakening system defenses. The detection rule identifies suspicious 'defaults' command executions that attempt to alter SoftwareUpdate preferences, focusing on disabling updates without setting them to true, thus flagging potential defense evasion activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'defaults' command execution with arguments targeting SoftwareUpdate preferences, specifically looking for the absence of 'TRUE' or 'true' in the command.
-- Cross-reference the timestamp of the alert with user activity logs to identify which user account executed the command.
-- Examine the process lineage to determine the parent process of the 'defaults' command, which may provide context on how the command was initiated.
-- Check for any recent login events or changes in user permissions around the time of the alert to identify potential unauthorized access.
-- Use Osquery to inspect the current state of the SoftwareUpdate preferences by running: `SELECT * FROM plist WHERE path = '/Library/Preferences/com.apple.SoftwareUpdate.plist';` to verify if updates have been disabled.
-- Investigate other process executions around the same time to identify any additional suspicious activities or commands that may indicate a broader attack.
-- Analyze network logs for any unusual outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
-- Review system logs for any error messages or warnings related to SoftwareUpdate services that might indicate tampering or misconfiguration.
-- Check for any recent installations or modifications of software that could have introduced malicious scripts or tools used to execute the 'defaults' command.
-- Correlate the alert with other security events or alerts from the same host or user to identify patterns or repeated attempts to modify system settings.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators or IT personnel may use the 'defaults' command to configure SoftwareUpdate settings for maintenance or compliance purposes. These actions, while benign, can trigger the detection rule.
-- Automated scripts: Some management tools or scripts may programmatically adjust SoftwareUpdate preferences as part of routine system configuration, leading to false positives.
-- User customization: Advanced users might modify SoftwareUpdate settings to manage updates manually, which could be flagged by the rule.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that are verified as non-threatening. This can be done by excluding certain user accounts or process hashes from the detection rule. Additionally, monitoring the frequency and context of the 'defaults' command usage can help differentiate between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further potential compromise or spread.
-- Review the process execution logs to confirm the unauthorized use of the 'defaults' command targeting SoftwareUpdate preferences.
-- Investigate the source of the command execution to determine if it was initiated by a legitimate user or an adversary.
-- Restore the SoftwareUpdate preferences to their default state to ensure security updates are re-enabled.
-- Conduct a full system scan using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate with a centralized logging solution, such as a Security Information and Event Management (SIEM) system, to monitor for similar suspicious activities.
-- Apply hardening measures by restricting the use of the 'defaults' command to authorized users only and consider using configuration management tools to enforce security settings.
-- Review and update security awareness training for users to recognize and report suspicious activities related to system preferences and updates."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
index 03a695d6c57..651cb2eae28 100644
--- a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
+++ b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -68,53 +68,6 @@ process.executable : ("/usr/bin/xattr",
                       "/Applications/.com.bomgar.scc.*/Remote Support Customer Client.app/Contents/MacOS/sdcust") and not
 file.path : "/private/var/folders/*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Quarantine Attrib Removed by Unsigned or Untrusted Process
-
-In macOS, files downloaded from the internet are tagged with a quarantine attribute, which is checked by Gatekeeper to ensure safety before execution. Adversaries may remove this attribute to bypass security checks. The detection rule identifies such actions by monitoring for the deletion of this attribute by untrusted or unsigned processes, excluding known safe executables and paths, thus highlighting potential evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process executable involved in the quarantine attribute removal. Pay attention to the `file.path` and `process.executable` fields.
-- Verify the legitimacy of the process executable by checking its code signature status. Use the `process.code_signature.trusted` and `process.code_signature.exists` fields to determine if the process is unsigned or untrusted.
-- Cross-reference the process executable path against known safe executables and paths to ensure it is not mistakenly flagged. Refer to the exclusion list in the detection rule.
-- Investigate the parent process of the flagged executable to understand the process hierarchy and determine if the parent process is legitimate or suspicious.
-- Use Osquery to gather additional context about the process and file involved. For example, run the following Osquery command to check for recent file modifications and process details:
-  ```sql
-  SELECT * FROM file WHERE path = '<file_path>';
-  SELECT * FROM processes WHERE pid = <process_id>;
-  ```
-- Check system logs for any related events or anomalies around the time the quarantine attribute was removed. Look for unusual activity that might correlate with the alert.
-- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential compromise.
-- Examine network activity from the host to identify any suspicious outbound connections that might suggest data exfiltration or command-and-control communication.
-- Review recent downloads or installations on the system to identify any potentially malicious software that could have triggered the alert.
-- Consult threat intelligence sources to determine if the process or file path is associated with known malware or adversary techniques, providing additional context for the investigation.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate applications or system processes that are not signed or trusted remove the quarantine attribute. This can include custom scripts or third-party applications that are not widely recognized or signed by Apple.
-- Users can handle these false positives by creating exceptions for specific processes or paths that are known to be safe. This can be done by adding these processes or paths to the exclusion list in the detection rule.
-- Frequent non-threatening behaviors, such as updates or installations from trusted sources that are not signed, can be excluded by specifying their executable paths in the exclusion criteria.
-- It is important to regularly review and update the exclusion list to ensure that only legitimate processes are excluded, maintaining a balance between security and usability.
-- Users should monitor the behavior of excluded processes to ensure they do not become vectors for malicious activity, as threat actors may attempt to exploit these exceptions.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further potential malicious activity and lateral movement.
-- Verify the process responsible for removing the quarantine attribute by checking its executable path and signature status.
-- Conduct a thorough investigation of the process's origin and behavior, including reviewing recent downloads and installations on the system.
-- If the process is confirmed malicious, remove the associated files and any other suspicious files or applications installed around the same time.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and file attribute changes for future investigations.
-- Integrate with threat intelligence platforms to correlate the activity with known threat actors or campaigns.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited.
-- Educate users on safe downloading practices and the importance of verifying the source of applications to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
index 16269af0209..9cf185bb72a 100644
--- a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
+++ b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
   process.args:(spctl and "--master-disable")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Disable Gatekeeper
-
-Gatekeeper is a macOS security feature that ensures only trusted software is executed by verifying app signatures. Adversaries may attempt to disable Gatekeeper to bypass these checks and run malicious code. The detection rule identifies such attempts by monitoring process activities for specific commands that indicate an effort to disable Gatekeeper, thus alerting analysts to potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the specific command `spctl --master-disable` in the `process.args` field, which indicates an attempt to disable Gatekeeper.
-- Check the `event.category` and `event.type` fields to ensure the event is related to a process start on a macOS host, confirming the context of the alert.
-- Identify the user account associated with the process by examining the `user.name` field to determine if the action was initiated by a legitimate user or a potential adversary.
-- Investigate the `process.name` and `process.executable` fields to gather more information about the process attempting to disable Gatekeeper, including its origin and legitimacy.
-- Use Osquery to list all processes running on the affected host to identify any other suspicious activities. Example query: `SELECT pid, name, path FROM processes WHERE name LIKE '%spctl%';`
-- Examine the `host.name` and `host.ip` fields to identify the affected machine and assess if it is part of a larger pattern or isolated incident.
-- Review recent login events on the affected host to identify any unauthorized access attempts that could correlate with the Gatekeeper disable attempt.
-- Analyze the `process.parent.name` and `process.parent.executable` fields to trace the parent process that initiated the Gatekeeper disable command, which may provide insights into the attack vector.
-- Check for any recent changes in system settings or configurations on the affected host that could indicate further tampering or preparation for executing malicious code.
-- Correlate the alert with other security events or logs from the same timeframe to identify any additional indicators of compromise or related suspicious activities.
-
-### False positive analysis
-
-- Legitimate administrative actions: System administrators or IT personnel may intentionally disable Gatekeeper for troubleshooting or software testing purposes. These actions can trigger the detection rule, leading to false positives.
-- Software development activities: Developers working on macOS applications might disable Gatekeeper to test unsigned apps during the development process, which can be mistakenly flagged as malicious behavior.
-- Custom scripts or automation tools: Some organizations use scripts or automation tools that include commands to disable Gatekeeper as part of their workflow, potentially causing false alerts.
-- To manage these false positives, users can create exceptions for known and trusted administrative accounts or specific processes that are regularly involved in legitimate Gatekeeper disabling activities. This can be done by refining the detection rule to exclude certain user accounts or process paths that are verified as non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration.
-- Verify the presence of unauthorized changes by reviewing system logs and Gatekeeper settings to confirm if it has been disabled.
-- Conduct a thorough investigation to identify any malicious processes or files that may have been executed following the Gatekeeper disablement attempt.
-- Restore Gatekeeper to its default state by re-enabling it using the command `sudo spctl --master-enable` and ensure that system integrity is maintained.
-- Escalate the incident to the security operations team for further analysis and to determine if this attempt is part of a broader attack campaign.
-- Implement enhanced logging policies to capture detailed process execution data and command-line arguments for future monitoring and analysis.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context on similar threats.
-- Review and update security policies to include regular audits of security settings and configurations, ensuring compliance with best practices.
-- Educate users on the importance of security features like Gatekeeper and the risks associated with disabling them, reinforcing the organization's security culture.
-- Conduct a post-incident review to identify gaps in the current security posture and develop a plan to address these vulnerabilities, including potential system hardening measures such as application whitelisting and regular software updates."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_install_root_certificate.toml b/rules/macos/defense_evasion_install_root_certificate.toml
index 61354a85f92..c4d2d688080 100644
--- a/rules/macos/defense_evasion_install_root_certificate.toml
+++ b/rules/macos/defense_evasion_install_root_certificate.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -63,49 +63,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   not process.parent.executable:("/Library/Bitdefender/AVP/product/bin/BDCoreIssues" or "/Applications/Bitdefender/SecurityNetworkInstallerApp.app/Contents/MacOS/SecurityNetworkInstallerApp"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Install Root Certificate
-
-Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by validating identities. Adversaries exploit this by installing rogue root certificates on compromised macOS systems, bypassing security warnings to stealthily connect to malicious servers. The detection rule identifies such attempts by monitoring specific process activities related to certificate installation, excluding known legitimate processes, thus highlighting potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `process.name:security` and `process.args:"add-trusted-cert"` fields, which indicate an attempt to add a trusted certificate.
-- Verify the `event.category:process` and `event.type:(start or process_started)` fields to ensure the alert is related to a process initiation event on a macOS system.
-- Check the `host.os.type:macos` field to confirm the operating system is macOS, as the rule is specifically designed for this environment.
-- Investigate the `process.parent.executable` field to determine if the parent process is one of the known legitimate processes excluded in the rule, such as Bitdefender applications.
-- Use Osquery to list all installed root certificates on the system to identify any recent or suspicious additions. Example query: `SELECT * FROM certificates WHERE common_name LIKE '%root%' AND issuer LIKE '%root%';`
-- Examine system logs for any other unusual activities or errors around the time of the alert to gather additional context.
-- Cross-reference the process execution details with known threat intelligence sources to identify if the certificate or process is associated with known malicious activity.
-- Analyze network logs to identify any connections made by the system to external servers around the time of the alert, focusing on any untrusted or suspicious IP addresses.
-- Review user activity logs to determine if the certificate installation was initiated by a legitimate user or if it was potentially automated or unauthorized.
-- Check for any recent changes in system configurations or installed applications that might explain the certificate installation, ensuring to rule out legitimate administrative actions.
-
-### False positive analysis
-
-- Known false positives for the Attempt to Install Root Certificate rule may include legitimate software installations or updates that require adding trusted certificates, such as security software or enterprise applications.
-- Users can manage these false positives by creating exceptions for known legitimate processes that frequently trigger the rule, such as those associated with trusted security software like Bitdefender.
-- To handle these exceptions, users should identify the parent executable paths of legitimate processes and add them to the exclusion list in the detection rule, ensuring that only non-threatening behaviors are excluded.
-- Regularly review and update the list of exceptions to accommodate new legitimate software that may require root certificate installation, maintaining a balance between security and operational efficiency.
-- It's crucial to monitor the environment for any changes in software behavior that could indicate a shift from legitimate to potentially malicious activity, adjusting the exceptions as necessary to maintain robust security controls.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further communication with potential malicious servers.
-- Verify the presence of unauthorized root certificates by checking the system's keychain and remove any suspicious certificates that are not recognized or expected.
-- Conduct a thorough investigation of the process activity logs to identify the source and timeline of the root certificate installation attempt.
-- Cross-reference the process parent executable with known legitimate applications to ensure no false positives are present.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all unauthorized changes are reverted.
-- Apply security hardening measures such as disabling unnecessary services, enforcing strong authentication mechanisms, and regularly updating software and security patches.
-- Educate users on the risks of unauthorized certificate installations and the importance of reporting suspicious activities to the IT department promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_modify_environment_launchctl.toml b/rules/macos/defense_evasion_modify_environment_launchctl.toml
index a8691ee53a4..4cd4dfee4f8 100644
--- a/rules/macos/defense_evasion_modify_environment_launchctl.toml
+++ b/rules/macos/defense_evasion_modify_environment_launchctl.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -74,49 +74,6 @@ event.category:process and host.os.type:macos and event.type:start and
                                   /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or 
                                   /usr/local/bin/kr)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Environment Variable via Unsigned or Untrusted Parent
-
-Environment variables in macOS can influence application behavior by specifying settings or paths. Adversaries exploit this by using the `launchctl` command to alter these variables, potentially loading malicious libraries or bypassing security measures. The detection rule identifies such modifications initiated by untrusted or unsigned parent processes, focusing on suspicious `launchctl` usage and excluding known safe applications, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which environment variable was modified and the specific `launchctl` command used.
-- Examine the `process.parent.code_signature` field to determine if the parent process is unsigned or untrusted, which could indicate a potential threat.
-- Investigate the parent process by checking its `process.parent.executable` path to identify the application or script that initiated the `launchctl` command.
-- Use Osquery to gather more information about the parent process. For example, run the following query to get details about the parent process: `SELECT * FROM processes WHERE pid = <parent_process_id>;`.
-- Check the `process.args` field to identify the specific environment variable being set and assess whether it is commonly used or potentially malicious.
-- Cross-reference the `process.parent.executable` with known safe applications to ensure it is not mistakenly flagged, as indicated in the exclusion list of the detection rule.
-- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
-- Review recent system logs and user activity to identify any unusual behavior or patterns that coincide with the time of the alert.
-- Analyze network activity from the host to detect any suspicious outbound connections that may indicate data exfiltration or command-and-control communication.
-- If applicable, use Osquery to list all environment variables for the affected process to understand the full context of the environment: `SELECT * FROM environment WHERE pid = <affected_process_id>;`.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate applications or scripts that are unsigned or lack a trusted code signature but are not malicious. These can include custom scripts or third-party applications that modify environment variables for legitimate purposes.
-- Users can handle these false positives by creating exceptions for specific parent processes that are known to be safe. This can be done by adding the executable paths of these trusted applications to the exclusion list in the detection rule.
-- Frequent non-threatening behaviors, such as development tools or automation scripts that use `launchctl` to set environment variables, can be excluded by identifying their parent process paths and ensuring they are added to the exclusion criteria.
-- It is important to regularly review and update the list of exclusions to ensure that new legitimate applications are not flagged as threats, while maintaining vigilance against potential adversarial activities.
-- Users should also verify the legitimacy of unsigned applications by checking their source and purpose, ensuring they are not inadvertently allowing malicious activities through overly broad exclusions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the untrusted or unsigned parent process that modified the environment variable using `launchctl`.
-- Review system logs and process execution history to determine if any malicious payloads were executed or if any unauthorized libraries were loaded.
-- Remove any identified malicious files or libraries and restore any altered environment variables to their original state.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has a broader presence in the network.
-- Implement enhanced logging policies to capture detailed process execution and environment variable changes, ensuring future incidents can be detected more effectively.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
-- Apply system and application patches to address any vulnerabilities that may have been exploited by the adversary.
-- Educate users on recognizing and reporting suspicious activities, emphasizing the importance of running only trusted applications.
-- Review and update security policies and procedures to include specific measures against environment variable hijacking and unauthorized use of `launchctl`."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
index 3b7c695be15..044d6b27ab3 100644
--- a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
+++ b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -64,48 +64,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
  process.args : "/*/Application Support/com.apple.TCC/TCC.db" and
  not process.parent.executable : "/Library/Bitdefender/AVP/product/bin/*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privacy Control Bypass via TCCDB Modification
-
-The Transparency, Consent, and Control (TCC) database in macOS manages app permissions for accessing sensitive resources. Adversaries may exploit this by using tools like sqlite3 to alter the TCC database, bypassing privacy controls to access resources like the camera or microphone. The detection rule identifies such attempts by monitoring for suspicious sqlite3 activity targeting the TCC database, excluding legitimate processes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of sqlite3 activity targeting the TCC database, specifically checking the process name and arguments for "sqlite*" and "/*/Application Support/com.apple.TCC/TCC.db".
-- Verify the parent process of the sqlite3 activity to ensure it is not a legitimate process, such as those from "/Library/Bitdefender/AVP/product/bin/*".
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities on the system.
-- Investigate the user account associated with the process to determine if it is a legitimate user or if the account may have been compromised.
-- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE name LIKE 'sqlite%' AND path LIKE '%/Application Support/com.apple.TCC/TCC.db%';`
-- Examine system logs around the time of the event for any other anomalies or related activities that could provide further context.
-- Investigate any recent changes to the TCC database by querying for recent modifications: `SELECT * FROM file WHERE path = '/Application Support/com.apple.TCC/TCC.db' AND mtime > (SELECT datetime('now', '-1 day'));`
-- Check for any other processes or scripts that may have been executed around the same time as the sqlite3 activity to identify potential automation or scripts used by an adversary.
-- Review network activity logs to identify any outbound connections that may indicate data exfiltration or communication with a command and control server.
-- Consult with the user or system owner to verify if any legitimate maintenance or software updates were performed that could explain the sqlite3 activity.
-
-### False positive analysis
-
-- Legitimate software updates or system maintenance tasks may trigger the rule if they involve sqlite3 operations on the TCC database. Users can handle these by identifying the specific update or maintenance process and adding it to an exclusion list.
-- Security software or system monitoring tools that perform regular checks on the TCC database might also be flagged. To manage this, users should verify the legitimacy of these tools and exclude their processes from the detection rule.
-- Developers or IT administrators conducting authorized testing or debugging on macOS systems may inadvertently trigger the rule. In such cases, users should document these activities and create exceptions for the specific processes involved.
-- Automated backup or synchronization applications that access the TCC database for legitimate reasons could be misidentified as threats. Users should confirm the application's purpose and add it to the exclusion list if deemed safe.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the unauthorized modification of the TCC database by reviewing system logs and identifying any suspicious sqlite3 activity.
-- Terminate any unauthorized processes that are currently accessing or modifying the TCC database.
-- Restore the TCC database from a known good backup to ensure that all privacy settings are reverted to their original state.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to monitor for future unauthorized access attempts, focusing on sqlite3 activity and changes to the TCC database.
-- Integrate with security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Apply macOS security updates and patches to address any vulnerabilities that may have been exploited.
-- Educate users on the importance of maintaining application permissions and the risks associated with unauthorized modifications.
-- Review and update security policies to include specific measures for protecting the TCC database and other critical system components."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
index ad79f7aed53..0e9e1000b8e 100644
--- a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
+++ b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -65,49 +65,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
  process.command_line:("scp *localhost:/*", "scp *127.0.0.1:/*") and
  not process.args:"vagrant@*127.0.0.1*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privacy Control Bypass via Localhost Secure Copy
-
-Secure Copy Protocol (SCP) is used for secure file transfers over SSH. On macOS, SSHD can gain Full Disk Access, potentially allowing unauthorized file access. Adversaries might exploit this by copying files locally, bypassing privacy controls. The detection rule identifies such activity by monitoring SCP commands targeting localhost, excluding benign uses like Vagrant, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of SCP commands targeting localhost or 127.0.0.1, as indicated by the `process.command_line` field.
-- Verify the `process.args` field to ensure that the SCP command includes `StrictHostKeyChecking=no`, which might indicate an attempt to bypass SSH security checks.
-- Check the `process.name` field to confirm that the process involved is indeed `scp`, ensuring the alert is not a false positive.
-- Investigate the user account associated with the SCP command to determine if it is a legitimate user or potentially compromised.
-- Examine the timing and frequency of the SCP commands to identify patterns or anomalies that could suggest malicious activity.
-- Use Osquery to gather additional context about the process. For example, run the following query to list recent SCP processes: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE name = 'scp';`
-- Cross-reference the SCP activity with other logs, such as SSH authentication logs, to identify any unauthorized access attempts or anomalies.
-- Investigate the source and destination paths involved in the SCP command to determine if sensitive files were targeted.
-- Check for any other suspicious activities on the host around the same time, such as unusual network connections or file modifications.
-- Review the system's Full Disk Access settings to ensure that only authorized applications have the necessary permissions, and verify if SSHD has been improperly added.
-
-### False positive analysis
-
-- **Vagrant Usage**: The rule excludes SCP commands involving Vagrant, as it commonly uses localhost for virtual machine management. Users should ensure that any Vagrant-related SCP activity is correctly excluded by verifying the exclusion pattern matches their specific Vagrant configurations.
-- **Local Development and Testing**: Developers may use SCP to transfer files between local environments for testing purposes. Users can manage these false positives by identifying and excluding specific user accounts or directories frequently involved in legitimate development activities.
-- **Automated Backup Scripts**: Some backup solutions might use SCP to copy files locally as part of their routine operations. Users should review and whitelist known backup scripts or processes to prevent them from being flagged.
-- **System Maintenance Tasks**: IT administrators might perform maintenance tasks that involve SCP commands targeting localhost. Users can handle these by creating exceptions for specific maintenance scripts or by scheduling these tasks during known maintenance windows to reduce false alerts.
-- **Custom Applications**: Organizations may have custom applications that use SCP for legitimate local file transfers. Users should document these applications and create specific exclusions based on process names or command-line patterns to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify any unauthorized SCP activities by reviewing system logs and correlating them with the detection rule triggers.
-- Verify the integrity of sensitive files and check for any unauthorized modifications or access, focusing on files that may have been targeted by the SCP command.
-- Remove SSHD from the Full Disk Access list if it was added without proper authorization, and review the list for any other unauthorized applications.
-- Escalate the incident to the security operations team if evidence of data exfiltration or further compromise is found, and consider involving legal or compliance teams if sensitive data is involved.
-- Implement enhanced logging policies to capture detailed command-line activities and file access events, ensuring that future incidents can be detected and investigated more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying any necessary patches, updating security configurations, and ensuring that all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing strict access controls.
-- Educate users and administrators on the risks associated with improper use of SCP and SSH, and provide training on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_safari_config_change.toml b/rules/macos/defense_evasion_safari_config_change.toml
index 71561afd43d..599eef17f93 100644
--- a/rules/macos/defense_evasion_safari_config_change.toml
+++ b/rules/macos/defense_evasion_safari_config_change.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -68,49 +68,6 @@ event.category:process and host.os.type:macos and event.type:start and
       )
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Safari Settings via Defaults Command
-
-The 'defaults' command in macOS is a powerful utility for modifying application settings, including Safari's configuration. Adversaries may exploit this to alter Safari settings, potentially enabling harmful features like JavaScript from Apple Events, which can facilitate browser hijacking. The detection rule identifies suspicious 'defaults' command usage targeting Safari settings, excluding benign modifications, to flag potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific Safari setting was modified using the 'defaults' command, focusing on the process.args field to identify the exact change.
-- Check the event.timestamp to determine when the modification occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the user account associated with the process.user.name field to determine if the account has a history of making unauthorized changes or if it has been compromised.
-- Examine the process.parent.name and process.parent.args fields to identify the parent process that initiated the 'defaults' command, which might provide context on how the command was executed.
-- Use Osquery to list recent processes executed by the user to identify any other potentially malicious activities. Example query: `SELECT * FROM processes WHERE user = '<user_name>' ORDER BY start_time DESC LIMIT 10;`
-- Check system logs for any other unusual activities or errors around the time of the modification, which might indicate a broader attack or compromise.
-- Investigate network connections from the host using Osquery to identify any suspicious outbound connections that could suggest data exfiltration or command and control activity. Example query: `SELECT * FROM process_open_sockets WHERE pid = <suspicious_pid>;`
-- Review any recent changes to the system's configuration or installed applications that could have facilitated the unauthorized modification of Safari settings.
-- Analyze the host's security software logs to check for any alerts or blocked activities that coincide with the time of the Safari settings modification.
-- Consult with the user or system owner to verify if the change was authorized or if they noticed any unusual behavior on their system, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Users may frequently modify Safari settings for legitimate reasons, such as personalizing their browsing experience or enhancing privacy. These benign changes can trigger false positives if they involve settings not explicitly excluded in the detection rule.
-- System administrators might use scripts to configure Safari settings across multiple devices for compliance or standardization purposes. These automated processes can be mistaken for malicious activity.
-- Developers and testers might adjust Safari settings to test web applications or browser features, leading to false positives if these changes are not part of the excluded settings.
-- To manage these false positives, users can create exceptions for known benign processes or scripts by adding specific process arguments to the exclusion list in the detection rule.
-- Regularly review and update the exclusion list to include new non-threatening behaviors as they are identified, ensuring that legitimate activities are not flagged as suspicious.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity or data exfiltration.
-- Review the process execution logs to confirm the unauthorized use of the 'defaults' command targeting Safari settings and identify any other suspicious activities.
-- Terminate any suspicious processes that may have been initiated as a result of the altered Safari settings.
-- Restore Safari settings to their default state using a known good configuration or by manually resetting the settings through the Safari preferences.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
-- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate with a centralized security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
-- Apply security patches and updates to the macOS system and Safari browser to mitigate known vulnerabilities.
-- Educate users on the risks of unauthorized configuration changes and reinforce the importance of reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
index 6486d19dd41..0c821e217e4 100644
--- a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
+++ b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ type = "query"
 query = '''
 event.category:file and host.os.type:(macos and macos) and not event.type:deletion and file.name:~$*.zip
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Microsoft Office Sandbox Evasion
-
-Microsoft Office applications on macOS operate within a sandbox to limit potential damage from malicious files. However, adversaries can exploit this by creating zip files with special character prefixes, allowing them to bypass sandbox restrictions and execute unauthorized actions. The detection rule identifies such suspicious zip file creations, focusing on non-deletion events with specific naming patterns, to flag potential evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a zip file with a name starting with special characters, as indicated by the `file.name:~$*.zip` pattern.
-- Verify the `event.category:file` and `host.os.type:macos` fields to ensure the event pertains to a file operation on a macOS system.
-- Check the `event.type` field to confirm that the event is not a deletion, which aligns with the rule's focus on non-deletion events.
-- Investigate the source of the zip file creation by identifying the user account and process responsible for the action.
-- Use Osquery to list recent file creations in the suspected directory. Example query: `SELECT path, filename, uid, gid, atime, mtime FROM file WHERE path LIKE '/path/to/suspected/directory/%' AND filename LIKE '~$%.zip';`
-- Examine the process tree to identify any parent processes that may have initiated the suspicious file creation, focusing on Microsoft Office applications.
-- Analyze system logs for any related events or anomalies around the time of the zip file creation to gather additional context.
-- Check for any AutoStart locations that may have been modified or targeted by the suspicious zip file to facilitate sandbox evasion.
-- Investigate any network connections or external communications initiated by the system around the time of the event to identify potential data exfiltration or command-and-control activity.
-- Correlate the findings with other security alerts or incidents to determine if this event is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate applications or processes that create zip files with special character prefixes for valid reasons, such as temporary file storage or backup processes, may trigger false positives.
-- Automated scripts or system processes that generate zip files with special characters as part of their normal operation can be mistakenly flagged.
-- Users can manage these false positives by identifying and documenting known benign processes that exhibit this behavior and creating exceptions for them in the detection rule.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening activities are excluded, maintaining the integrity of the detection system.
-- Consider implementing additional context checks, such as verifying the source application or process, to differentiate between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized actions or data exfiltration.
-- Conduct a thorough investigation to identify the source of the suspicious zip file and any associated processes or files that may have been executed.
-- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) related to the sandbox evasion technique.
-- Review system and application logs to trace the origin of the zip file and any user accounts involved in its creation or execution.
-- Remove any unauthorized files or applications identified during the investigation and ensure that the system is free from malicious software.
-- Restore the system to a known good state using backups or system restore points, ensuring that all security patches and updates are applied.
-- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on files with special character prefixes.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar evasion techniques.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Apply hardening measures such as restricting the execution of files with special character prefixes and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
index 46c912d7be6..8accc83b579 100644
--- a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
+++ b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -60,49 +60,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:mount_apfs and
   process.args:(/System/Volumes/Data and noowners)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 TCC Bypass via Mounted APFS Snapshot Access
-
-Apple's TCC framework safeguards user data by controlling app access to sensitive files. Adversaries exploit APFS snapshots, mounting them with specific flags to bypass these controls, gaining unauthorized access to protected data. The detection rule identifies suspicious use of the `mount_apfs` command, focusing on arguments that indicate attempts to access the file system without ownership restrictions, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `mount_apfs` command with the `noowners` flag in the process arguments, as this is a key indicator of potential misuse.
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time for additional context.
-- Identify the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates a compromised account.
-- Investigate the parent process of `mount_apfs` to understand how it was initiated and whether it was part of a legitimate workflow or a suspicious chain of processes.
-- Use Osquery to list all mounted file systems and verify if any APFS snapshots are currently mounted with the `noowners` flag. Example query: `SELECT * FROM mounts WHERE device LIKE '%snapshot%' AND options LIKE '%noowners%';`
-- Examine system logs for any other unusual activities or errors around the time of the alert that might indicate tampering or exploitation attempts.
-- Cross-reference the event with any recent changes or updates to the system that might have inadvertently triggered the alert, such as software installations or system updates.
-- Analyze network activity from the host to identify any potential data exfiltration attempts or connections to known malicious IP addresses.
-- Review historical data for similar alerts or patterns of behavior from the same host or user account to assess if this is an isolated incident or part of a recurring issue.
-- Consult threat intelligence sources to determine if there are any known campaigns or adversaries currently exploiting APFS snapshot access for TCC bypass, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate system maintenance or backup processes may trigger the rule if they involve mounting APFS snapshots with the `noowners` flag, as these operations can mimic the behavior of an adversary attempting to bypass TCC protections.
-- Security or IT administrators performing routine checks or data recovery might use the `mount_apfs` command with similar arguments, leading to false positives.
-- Users can manage these false positives by creating exceptions for known maintenance scripts or backup applications that regularly perform these actions, ensuring they are documented and verified as non-threatening.
-- Implementing a whitelist for specific processes or users that are authorized to perform such operations can help reduce noise from legitimate activities.
-- Regularly review and update the list of exceptions to ensure that only trusted processes are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the use of the mount_apfs command with the noowners flag and identify any unauthorized access to sensitive files.
-- Review system logs and process execution history to determine the scope of the compromise and identify any additional affected systems.
-- Remove any unauthorized APFS snapshots and ensure that no malicious processes are running on the system.
-- Restore the system from a known good backup prior to the unauthorized access, ensuring that all security patches and updates are applied.
-- Implement enhanced logging policies to monitor for suspicious use of the mount_apfs command and other potential indicators of compromise.
-- Integrate security tools with SIEM solutions to improve detection capabilities and automate alerting for similar threats in the future.
-- Conduct a security audit of the TCC framework settings and permissions to ensure that only authorized applications have access to sensitive data.
-- Educate users and administrators on the risks associated with APFS snapshot access and the importance of maintaining strict access controls.
-- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further investigation and guidance."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
index f8a34db6516..332860d1f4b 100644
--- a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
+++ b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -54,53 +54,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:kextunload and process.args:("/System/Library/Extensions/EndpointSecurity.kext" or "EndpointSecurity.kext")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 uses kernel extensions on macOS to monitor and protect system activities at a low level. Adversaries may attempt to disable these extensions using the `kextunload` command to evade detection and impair defenses. The detection rule identifies such attempts by monitoring process events for the execution of `kextunload` targeting the specific security extension, signaling potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `kextunload` command targeting `EndpointSecurity.kext` in the process arguments.
-- Check the timestamp of the event to determine when the attempt occurred and correlate it with other security events around the same time.
-- Identify the user account associated with the process execution to determine if it was initiated by a legitimate user or a potential adversary.
-- Investigate the parent process of `kextunload` to understand the context of how it was executed and if it was part of a larger chain of suspicious activities.
-- Examine the host's recent login history to identify any unusual or unauthorized access attempts that could be related to the event.
-- Use Osquery to gather additional context about the process and user activity on the host. For example, run the following query to list recent processes executed by the same user:
-  ```sql
-  SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');
-  ```
-- Check for any recent changes to system configurations or security settings that might indicate tampering or preparation for the unload attempt.
-- Analyze network activity from the host around the time of the event to identify any potential command and control communications or data exfiltration attempts.
-- Review system logs for any error messages or warnings related to kernel extensions that might provide additional context or indicate other attempts to impair defenses.
-- Cross-reference the event with threat intelligence sources to determine if the activity matches known tactics, techniques, and procedures (TTPs) of specific threat actors.
-
-### False positive analysis
-
-- System administrators or IT personnel may intentionally unload the Elastic Endpoint Security kernel extension during maintenance or troubleshooting activities, which can trigger the detection rule. 
-- Software updates or system upgrades might require unloading kernel extensions temporarily, leading to benign alerts.
-- Developers working on macOS kernel extensions might use `kextunload` as part of their development and testing processes, resulting in non-malicious detections.
-- To manage these false positives, users can create exceptions for specific user accounts or processes known to perform legitimate `kextunload` operations regularly.
-- Implementing a whitelist of trusted scripts or applications that require unloading the kernel extension can help reduce unnecessary alerts.
-- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further potential malicious activity.
-- Verify the legitimacy of the `kextunload` command execution by checking user activity logs and correlating with authorized change management records.
-- Conduct a thorough investigation to determine if the attempt was part of a broader attack, using endpoint detection and response (EDR) tools to analyze related processes and network connections.
-- If unauthorized, remove any malicious software or scripts that may have initiated the `kextunload` command and restore the Elastic Endpoint Security kernel extension.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Review and enhance logging policies to ensure comprehensive monitoring of kernel extension activities and unauthorized command executions.
-- Implement additional security measures, such as application whitelisting and stricter user permissions, to prevent unauthorized unloading of kernel extensions.
-- Update and patch the macOS system and security software to the latest versions to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on the importance of security practices and the risks associated with unauthorized system modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/discovery_users_domain_built_in_commands.toml b/rules/macos/discovery_users_domain_built_in_commands.toml
index b9bb23d2770..bc38d1d3874 100644
--- a/rules/macos/discovery_users_domain_built_in_commands.toml
+++ b/rules/macos/discovery_users_domain_built_in_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -75,49 +75,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                  "/Applications/NoMAD.app/Contents/MacOS/NoMAD",
                                                  "/Applications/ESET Management Agent.app/Contents/MacOS/ERAAgent")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Enumeration of Users or Groups via Built-in Commands
-
-Built-in commands on macOS, such as `ldapsearch`, `dsmemberutil`, and `dscl`, are essential for managing and querying user and group information. Adversaries exploit these to gather insights into user accounts and group memberships, aiding in privilege escalation or lateral movement. The detection rule identifies suspicious use of these commands by monitoring their execution patterns and excluding known legitimate applications, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command executed, focusing on `process.name` and `process.args` fields to understand the nature of the enumeration attempt.
-- Examine the `process.parent.executable` and `process.Ext.effective_parent.executable` fields to determine the parent process that initiated the command, which can provide context on whether the execution was part of a legitimate application or potentially malicious activity.
-- Check the `process.parent.name` and `process.Ext.effective_parent.name` fields to identify any unusual or suspicious parent process names that might indicate unauthorized use.
-- Investigate the user account associated with the process execution to determine if the account has a history of similar activities or if it has been compromised.
-- Utilize Osquery to gather additional context on the system. For example, run the following query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
-- Cross-reference the execution time of the command with other security events or logs to identify any correlated activities that might suggest a broader attack pattern.
-- Analyze network logs to check for any outbound connections made by the system around the time of the command execution, which could indicate data exfiltration attempts.
-- Review system logs for any recent changes to user accounts or group memberships that could be related to the enumeration activity.
-- Check for any other alerts or incidents involving the same host or user account to assess if this is part of a larger attack campaign.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that use similar enumeration techniques, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate applications such as security tools, system management software, or network monitoring solutions may trigger this rule due to their need to query user and group information for legitimate purposes. Examples include QualysCloudAgent, Kaspersky Anti-Virus, and ESET Endpoint Security.
-- System administrators or IT support personnel may use these commands during routine maintenance or troubleshooting, leading to benign alerts.
-- To manage these false positives, users can create exceptions for known legitimate applications by excluding their executable paths from the detection rule. This can be done by adding the application's executable path to the exclusion list in the detection query.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate applications that may trigger the rule.
-- Consider implementing additional context-based checks, such as verifying the user account executing the command or correlating with other suspicious activities, to reduce false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the activity, including reviewing logs for any unauthorized access or changes to user accounts and groups.
-- Utilize endpoint detection and response (EDR) tools to analyze the execution patterns of the identified commands and correlate them with known malicious behaviors.
-- If unauthorized enumeration is confirmed, reset passwords for affected accounts and review group memberships to ensure no unauthorized changes have been made.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed command execution and user activity, ensuring that logs are stored securely and retained for an appropriate period.
-- Integrate threat intelligence feeds to identify known indicators of compromise (IOCs) related to the detected activity and update detection rules accordingly.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are in line with best practices.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to prevent similar incidents in the future.
-- Educate users on security best practices and the importance of reporting suspicious activity to help prevent social engineering attacks that could lead to unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
index 25d118b498c..37396801ec4 100644
--- a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
+++ b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,53 +62,6 @@ type = "query"
 query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and process.args:("-e" and const*require*child_process*)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution via Electron Child Process Node.js Module
-
-Electron applications, built on Node.js, can execute system commands using the child_process module, inheriting parent process permissions. Adversaries exploit this to run unauthorized commands, leveraging elevated privileges. The detection rule identifies such activities on macOS by monitoring process events and specific command patterns, flagging potential misuse of the child_process module.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the specific process arguments that triggered the alert, focusing on the presence of "-e" and "require('child_process')".
-- Examine the parent process of the flagged process to determine if it is a legitimate Electron application, using the `process.parent.name` and `process.parent.executable` fields.
-- Check the user account associated with the process using `user.name` to assess if it aligns with expected usage patterns or if it might be compromised.
-- Investigate the command line arguments (`process.args`) further to identify any suspicious or unexpected commands being executed.
-- Use Osquery to list all running Electron applications and their associated processes to identify any anomalies:
-  ```sql
-  SELECT name, path, pid, parent, cmdline FROM processes WHERE name LIKE '%Electron%';
-  ```
-- Correlate the process start time (`event.start`) with any known user activity or scheduled tasks to determine if the execution was expected.
-- Analyze the network activity of the process using `network.traffic` logs to identify any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
-- Review recent file modifications or creations in directories commonly used by Electron applications to detect any unauthorized changes or script injections.
-- Check for any recent changes in the Electron application's source code or configuration files that might indicate tampering or the introduction of malicious code.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise related to Electron applications.
-
-### False positive analysis
-
-- Legitimate Electron applications often use the child_process module for valid operations such as spawning subprocesses for performance optimization or handling asynchronous tasks, which can trigger the detection rule.
-- Developers may use the child_process module during the development and testing phases of Electron applications, leading to benign process events being flagged.
-- Automated scripts or tools that rely on Electron applications for system management tasks might also generate alerts, as they frequently execute system commands.
-- To manage these false positives, users can create exceptions for known and trusted Electron applications by whitelisting specific process names or paths associated with legitimate use cases.
-- Implementing a baseline of normal behavior for Electron applications within the environment can help distinguish between expected and anomalous activities, reducing unnecessary alerts.
-- Regularly updating the list of trusted applications and processes can ensure that new legitimate use cases are not mistakenly flagged as threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes or installations of Electron applications.
-- Review process execution logs and command history to determine the specific commands executed via the child_process module.
-- Terminate any unauthorized or suspicious processes identified during the investigation to halt further malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to a known good state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting the use of the child_process module in Electron applications and enforcing the principle of least privilege for application permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
index e4c66a85907..a0c384dc8ef 100644
--- a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
+++ b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -82,49 +82,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
       "/usr/local/*brew*"
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Browser Child Process
-
-Web browsers often spawn child processes to handle tasks like rendering content or executing scripts. Adversaries exploit this by injecting malicious scripts or commands, leveraging browsers as entry points for attacks. The detection rule identifies unusual child processes spawned by browsers on macOS, focusing on shell scripts and command-line tools often used in attacks, while excluding known benign processes. This helps in pinpointing potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific browser and child process involved, focusing on the `process.parent.name` and `process.name` fields.
-- Examine the `process.command_line` field to understand the exact command executed by the child process, looking for any unusual or unexpected arguments.
-- Check the `process.args` field to identify any arguments that might indicate malicious activity, ensuring they are not part of the known benign exclusions.
-- Use Osquery to list all processes spawned by the identified browser during the time of the alert. Example query: `SELECT * FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'Google Chrome' OR name = 'firefox' OR name = 'Safari');`
-- Investigate the parent process's history to determine if it has been involved in any other suspicious activities or alerts.
-- Correlate the alert with any recent network activity logs to identify potential data exfiltration or communication with known malicious IPs.
-- Check the system's browser history to identify the websites visited around the time of the alert, looking for any known malicious or suspicious domains.
-- Review any recent downloads or file modifications on the system that might be related to the suspicious process execution.
-- Analyze the user account associated with the process to determine if there have been any unusual login attempts or privilege escalations.
-- Consult threat intelligence sources to see if the command line or process name matches any known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- Known false positives may include legitimate scripts or command-line tools executed by browser extensions or plugins, which are not inherently malicious but match the detection criteria.
-- System updates or software installations that use shell scripts or command-line tools can trigger the rule, especially if they are initiated through a browser download or update process.
-- Users can manage these false positives by creating exceptions for specific command-line patterns or arguments that are known to be safe, such as those related to software updates or trusted applications.
-- Regularly review and update the exclusion list to include new benign processes or command-line patterns that are identified over time, ensuring that the detection rule remains effective without generating excessive noise.
-- Consider the context of the process execution, such as the parent process and the command-line arguments, to differentiate between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential threats.
-- Conduct a thorough investigation of the suspicious process, including reviewing the command line and parent process details to understand the scope of the compromise.
-- Terminate any malicious processes identified during the investigation to halt ongoing malicious activity.
-- Review browser and system logs to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations team if the threat appears to be part of a larger attack campaign or if sensitive data may have been accessed.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all patches and updates are applied.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Educate users on safe browsing practices and the risks of executing unknown scripts or commands from web browsers.
-- Apply security hardening measures such as disabling unnecessary browser plugins, enforcing strict content security policies, and using browser isolation techniques to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_installer_package_spawned_network_event.toml b/rules/macos/execution_installer_package_spawned_network_event.toml
index 234cf30723c..2e53cc22289 100644
--- a/rules/macos/execution_installer_package_spawned_network_event.toml
+++ b/rules/macos/execution_installer_package_spawned_network_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -72,49 +72,6 @@ sequence by host.id with maxspan=15s
 [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and process.parent.name : ("installer", "package_script_service") and process.name : ("bash", "sh", "zsh", "python", "osascript", "tclsh*")] by process.entity_id
 [network where host.os.type == "macos" and event.type == "start" and process.name : ("curl", "osascript", "wget", "python", "java", "ruby", "node")] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 MacOS Installer Package Spawns Network Event
-
-MacOS installer packages, often with a .pkg extension, are used to distribute software. Adversaries exploit this by embedding scripts that execute upon installation, potentially launching network connections to download further malicious payloads. The detection rule identifies suspicious behavior by monitoring for installer-related processes spawning shell commands, followed by network activity, indicating possible malicious package execution.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `process.entity_id` involved in the suspicious activity.
-- Examine the parent process name (`installer` or `package_script_service`) to confirm it is associated with a MacOS installer package.
-- Investigate the child process spawned (e.g., `bash`, `sh`, `zsh`, `python`) to determine if it executed any unusual or unexpected commands.
-- Check the network activity details, focusing on the process name (`curl`, `osascript`, `wget`, `python`, `java`, `ruby`, `node`) to identify any suspicious external connections.
-- Use Osquery to gather additional context on the processes involved. For example, run the following query to list recent processes executed by the installer: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'installer');`
-- Investigate the command line arguments of the suspicious processes to identify any potentially malicious scripts or commands.
-- Review the file paths and hashes of the installer package and any downloaded files to check for known malicious signatures or anomalies.
-- Analyze the timing and sequence of events to determine if the network activity directly followed the process execution, indicating a potential download of additional payloads.
-- Check system logs for any other related events or anomalies around the time of the alert to gather more context on the system's state.
-- Correlate the findings with threat intelligence sources to determine if the behavior matches any known attack patterns or campaigns.
-
-### False positive analysis
-
-- Legitimate software installations: Some legitimate software packages may use scripts to perform necessary setup tasks, including network connections to download updates or additional components. Users should verify the source and integrity of the software to determine if the behavior is expected.
-- System updates: MacOS system updates or software updates from trusted vendors might trigger this rule due to their use of scripts and network connections during the installation process. Users can create exceptions for known update processes to prevent false positives.
-- Development tools: Developers using scripting languages and network tools for legitimate purposes, such as testing or deploying applications, may inadvertently trigger this rule. Users can exclude specific development environments or tools from monitoring to reduce false positives.
-- Automated scripts: Automated maintenance or configuration scripts that use network connections might be flagged. Users should review these scripts and, if deemed safe, add them to an exclusion list to avoid repeated alerts.
-- Custom software deployments: Organizations deploying custom software internally may use installer packages with embedded scripts that access the network. Users should ensure these packages are signed and trusted, then configure exceptions for these known processes.
-
-### Response and remediation
-
-- Immediately isolate the affected MacOS system from the network to prevent further malicious activity and data exfiltration.
-- Conduct a thorough investigation to identify the malicious package by reviewing recent installations and correlating them with the alert timestamp.
-- Terminate any suspicious processes identified in the alert, such as those initiated by the installer package, to halt ongoing malicious activities.
-- Remove the identified malicious package and any additional payloads it may have downloaded to ensure the system is free from threats.
-- Review and analyze system logs, including process execution and network activity, to understand the scope of the compromise and identify any lateral movement.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity, aiding in future investigations and threat detection.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all security patches are applied.
-- Harden the system by implementing security best practices, such as disabling unnecessary services, enforcing application whitelisting, and educating users on recognizing phishing attempts and suspicious software."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_script_via_automator_workflows.toml b/rules/macos/execution_script_via_automator_workflows.toml
index 4be83af433e..55faccc4136 100644
--- a/rules/macos/execution_script_via_automator_workflows.toml
+++ b/rules/macos/execution_script_via_automator_workflows.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,50 +59,6 @@ sequence by host.id with maxspan=30s
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "automator"]
  [network where host.os.type == "macos" and process.name:"com.apple.automator.runner"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Automator Workflows Execution
-Automator is a macOS utility that automates repetitive tasks through workflows. Adversaries may exploit this by embedding malicious JavaScript for Automation (JXA) in custom workflows, bypassing traditional script execution methods. The detection rule identifies this threat by monitoring the Automator process initiation followed by network activity from its XPC service, indicating potential malicious use.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and timestamp of the suspicious Automator process initiation.
-- Check the process lineage to determine the parent process of the Automator execution, which may provide insight into how it was launched.
-- Investigate the user account associated with the Automator process to determine if it aligns with expected behavior or if it appears compromised.
-- Examine recent file modifications or creations in directories commonly used for Automator workflows, such as ~/Library/Services or ~/Library/Automator, to identify any newly added or modified workflows.
-- Use Osquery to list all Automator workflows on the system and check for any unusual or unauthorized entries:
-  ```sql
-  SELECT * FROM file WHERE directory LIKE '/Users/%/Library/Services' OR directory LIKE '/Users/%/Library/Automator';
-  ```
-- Analyze the contents of any suspicious Automator workflows to identify embedded JavaScript for Automation (JXA) code that may indicate malicious intent.
-- Correlate the network activity from the com.apple.automator.runner process with known malicious IP addresses or domains to assess potential exfiltration or command-and-control communication.
-- Review system logs for any additional context around the time of the Automator process execution, focusing on security and application logs for anomalies.
-- Investigate other processes or network connections initiated by the same user or host around the same timeframe to identify potential lateral movement or further malicious activity.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns involving Automator or JXA.
-
-### False positive analysis
-
-- Legitimate use of Automator workflows by users or system processes can trigger false positives, especially if they involve network activity. Users should identify and document regular workflows that are known to be safe.
-- System updates or third-party applications that utilize Automator for legitimate automation tasks may also cause alerts. Monitoring and documenting these activities can help differentiate between benign and suspicious behavior.
-- Users can manage false positives by creating exceptions for specific workflows or processes that are verified as non-threatening. This can be done by whitelisting known safe process names or network activities associated with trusted applications.
-- Regularly review and update the list of exceptions to ensure that new legitimate workflows are accounted for, while also being cautious not to overlook potential threats.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity and potential lateral movement.
-- Conduct a thorough investigation of the Automator workflows on the affected system to identify any unauthorized or suspicious scripts, particularly those containing JavaScript for Automation (JXA).
-- Review recent file modifications and system logs to trace the origin of the malicious workflow and determine if any other systems are affected.
-- Remove any identified malicious workflows and associated files from the system to prevent re-execution.
-- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on Automator and related services.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Educate users on the risks of executing untrusted workflows and scripts, emphasizing the importance of verifying the source of any automation tools.
-- Apply system hardening measures, such as restricting the execution of scripts and workflows to trusted sources and regularly updating macOS and security software to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
index e5db388d4be..d643bd904f1 100644
--- a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
+++ b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -67,48 +67,6 @@ sequence by host.id, process.entity_id with maxspan=30s
     "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")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Apple Script Execution followed by Network Connection
-
-AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries exploit it to execute scripts that initiate network connections, potentially for command and control activities. The detection rule identifies such behavior by monitoring the osascript process for network activity shortly after script execution, excluding local and reserved IP addresses to focus on suspicious external connections.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the osascript process was involved, noting the `host.id` and `process.entity_id` for correlation.
-- Check the timestamp of the osascript process start event to establish a timeline and determine if the network connection occurred within the 30-second window.
-- Identify the destination IP address from the network event and verify if it is external and potentially malicious by cross-referencing threat intelligence sources.
-- Use Osquery to gather additional context on the osascript process by running a query such as: `SELECT * FROM processes WHERE name = 'osascript' AND pid = <process_id>;` to retrieve details like parent process, command line arguments, and execution path.
-- Investigate the parent process of osascript to determine if it was spawned by a legitimate application or a suspicious process.
-- Examine recent system logs and user activity around the time of the alert to identify any unusual behavior or script execution attempts.
-- Analyze the command line arguments used with osascript to understand the script's purpose and whether it aligns with known malicious patterns.
-- Check for any additional network connections made by the osascript process to other external IPs that might indicate further command and control activity.
-- Review historical data for the same `host.id` to identify any previous similar alerts or patterns of suspicious behavior involving osascript.
-- If available, use endpoint detection and response (EDR) tools to perform a deeper analysis of the affected host, focusing on file modifications, registry changes, and other indicators of compromise related to the osascript execution.
-
-### False positive analysis
-
-- Legitimate automation scripts: Users may have legitimate AppleScripts that automate tasks and require network access, such as scripts for data synchronization or cloud service interactions. To handle these, users can create exceptions for known scripts by whitelisting specific script names or paths.
-- Software updates and system processes: Some macOS system processes or third-party applications might use AppleScript for updates or network communications. Users should monitor and identify these processes, then exclude them from the detection rule by adding their process identifiers or network patterns to an exception list.
-- Development and testing environments: Developers often use AppleScript for testing network-related functionalities. In such environments, users can reduce false positives by excluding specific host IDs or IP ranges associated with development machines.
-- Remote management tools: IT departments might use AppleScript for remote management tasks that involve network connections. Users can manage these false positives by identifying and excluding the IP addresses or hostnames of known management servers from the detection criteria.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity and potential data exfiltration.
-- Conduct a thorough investigation of the osascript process to determine the script's origin and intent, checking for any unauthorized or suspicious scripts.
-- Review network logs to identify any external IP addresses the osascript process attempted to connect to, and block these IPs at the network perimeter.
-- Analyze the system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations.
-- Remove any identified malicious scripts or files from the system and ensure that the osascript process is not running unauthorized tasks.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring that the backup is free from compromise.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on scripting and network connection events.
-- Integrate threat intelligence feeds to update detection rules with known malicious IP addresses and script signatures.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Apply system hardening measures, such as disabling unnecessary scripting capabilities and enforcing strict application control policies, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_shell_execution_via_apple_scripting.toml b/rules/macos/execution_shell_execution_via_apple_scripting.toml
index fd997015f15..c0c517e9ea0 100644
--- a/rules/macos/execution_shell_execution_via_apple_scripting.toml
+++ b/rules/macos/execution_shell_execution_via_apple_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ sequence by host.id with maxspan=5s
  [process where host.os.type == "macos" and event.type in ("start", "process_started", "info") and process.name == "osascript" and process.args : "-e"] by process.entity_id
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : ("sh", "bash", "zsh") and process.args == "-c" and process.args : ("*curl*", "*pbcopy*", "*http*", "*chmod*")] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Shell Execution via Apple Scripting
-
-AppleScript and JXA are scripting languages used in macOS to automate tasks by executing system commands. Adversaries exploit these by using functions like `doShellScript` to run shell commands, potentially for malicious activities. The detection rule identifies such abuse by monitoring for shell processes initiated by `osascript` with specific arguments, indicating possible unauthorized command execution.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `osascript` execution with the `-e` argument, indicating potential AppleScript or JXA usage.
-- Examine the parent process of `osascript` to determine if it was initiated by a legitimate application or user action.
-- Investigate the specific shell command executed by `sh`, `bash`, or `zsh` with the `-c` argument, focusing on suspicious patterns like `curl`, `pbcopy`, `http`, or `chmod`.
-- Correlate the process entity IDs between `osascript` and the shell process to confirm the sequence of execution and identify any anomalies.
-- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Utilize Osquery to gather additional context on the processes involved. For example, run the following query to list recent `osascript` executions: `SELECT * FROM processes WHERE name = 'osascript' AND cmdline LIKE '%-e%';`
-- Investigate network connections made by the system around the time of the alert to identify any suspicious outbound traffic, especially related to `curl` or `http`.
-- Review system logs for any additional indicators of compromise or related suspicious activity around the time of the alert.
-- Analyze any files or scripts referenced in the command arguments for malicious content or unexpected modifications.
-- Cross-reference the alert with other security tools or logs to identify if this activity is part of a broader attack pattern or isolated incident.
-
-### False positive analysis
-
-- Legitimate automation scripts: Users may have legitimate AppleScripts or JXA scripts that automate tasks using `doShellScript` or `do shell script` to execute shell commands. These scripts might trigger the detection rule if they include commands like `curl`, `pbcopy`, `http`, or `chmod`. To manage this, users can create exceptions for known scripts by whitelisting specific script paths or process hashes.
-- System maintenance tools: Some system maintenance or monitoring tools might use AppleScript to execute shell commands for legitimate purposes. These tools can be identified and excluded from the detection rule by specifying their process names or command patterns in the exception list.
-- Developer environments: Developers often use scripting to automate build processes or other development tasks, which might involve shell command execution. Users can handle these false positives by excluding processes associated with known development environments or by setting up alerts only for non-development systems.
-- User-initiated scripts: Users might manually run scripts that include shell commands for personal productivity or customization. To reduce false positives, users can configure the detection rule to ignore scripts executed from specific user directories or by certain user accounts known to perform such activities.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the scope of the compromise by reviewing logs and identifying any additional systems that may have been affected.
-- Terminate any suspicious processes initiated by 'osascript' and any associated shell processes to stop ongoing malicious activities.
-- Analyze the command history and scripts executed via 'osascript' to understand the adversary's actions and objectives.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying the latest security patches, removing any unauthorized software, and ensuring all security configurations are up to date.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary scripting capabilities, enforcing least privilege access, and using application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
index 92ff97a3da0..c6fe7a360a3 100644
--- a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
+++ b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -124,51 +124,6 @@ process where event.action == "exec" and host.os.type == "macos" and
         "/usr/sbin/networksetup"
       )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious macOS MS Office Child Process
-
-Microsoft Office applications on macOS, like Word and Excel, can execute child processes, a feature often exploited by adversaries through malicious macros or document exploits. Attackers may launch scripts or utilities to gain unauthorized access or execute malicious payloads. The detection rule identifies unusual child processes spawned by Office apps, filtering out benign activities and known false positives, to pinpoint potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Microsoft Office application and child process involved, focusing on the `process.parent.name` and `process.name` fields.
-- Examine the `process.command_line` to understand the exact command executed by the child process, which may provide insights into the intent and potential malicious activity.
-- Check the `process.args` field to identify any arguments passed to the child process that could indicate suspicious behavior or attempts to evade detection.
-- Investigate the `process.parent.executable` and `process.Ext.effective_parent.executable` fields to verify the legitimacy of the parent process and ensure it is not a known false positive.
-- Use Osquery to gather additional context about the parent and child processes. For example, run the following Osquery query to list recent processes executed by Microsoft Office applications:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name IN ('Microsoft Word', 'Microsoft Excel', 'Microsoft PowerPoint', 'Microsoft Outlook', 'Microsoft OneNote'));
-  ```
-- Analyze the network activity associated with the suspicious process using network monitoring tools or logs to identify any unusual outbound connections or data exfiltration attempts.
-- Cross-reference the `process.name` with known malicious scripts or utilities to determine if the child process is commonly associated with malware or exploitation techniques.
-- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the alert.
-- Investigate the user account associated with the process execution to determine if there are any signs of account compromise or unauthorized access.
-- Consult threat intelligence sources to check if the observed behavior or process names are linked to known threat actors or campaigns targeting macOS systems.
-
-### False positive analysis
-
-- Known false positives include processes related to product version discovery and Office error reporting behavior, such as commands involving "ProductVersion", "hw.model", "ioreg", and paths like "/Library/Application Support/Microsoft/MERP*/Microsoft Error Reporting.app/Contents/MacOS/Microsoft Error Reporting".
-- False positives may also arise from legitimate applications and services like ToDesk, Privacy-i, Addigy, Elastic Agent, and JumpCloud Agent, which are filtered out by excluding their executables from detection.
-- Users can manage these false positives by adding exceptions for specific process arguments and parent executables that are known to be benign, ensuring that frequent non-threatening behaviors do not trigger alerts.
-- It is important to regularly review and update the list of exceptions to adapt to changes in legitimate software behavior and maintain effective threat detection.
-
-### Response and remediation
-
-- Isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the suspicious child process to determine the scope and impact of the potential compromise.
-- Review the parent Office document for any embedded macros or scripts that may have triggered the malicious activity.
-- Remove any identified malicious files or scripts from the system and ensure that all Office applications are updated to the latest security patches.
-- Escalate the incident to the security operations team if the investigation reveals a broader threat or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors and techniques.
-- Restore the system to its operational state by reinstalling affected applications and verifying system integrity.
-- Educate users on recognizing phishing attempts and the risks associated with enabling macros in Office documents.
-- Apply hardening measures such as disabling macros by default and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
index 0ac29de3aab..9013d41a7ab 100644
--- a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
+++ b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,48 +59,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:start and
  process.args:("-action" and ("-kerberoast" or askhash or asktgs or asktgt or s4u or ("-ticket" and ptt) or (dump and (tickets or keytab))))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Kerberos Attack via Bifrost
-
-Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. Adversaries exploit tools like Bifrost on macOS to manipulate Kerberos tickets, enabling unauthorized access through techniques like pass-the-ticket or kerberoasting. The detection rule identifies suspicious process activities linked to Bifrost's known attack methods, focusing on specific command-line arguments indicative of such exploits.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious command-line arguments such as "-action", "-kerberoast", "askhash", "asktgs", "asktgt", "s4u", "-ticket ptt", or "dump tickets/keytab" in the process arguments.
-- Correlate the process start event with the user account associated with the process to determine if the account is legitimate and authorized to perform such actions.
-- Examine the parent process of the suspicious activity to identify if it was initiated by a legitimate application or script, which might indicate a false positive.
-- Check the process execution history on the affected host to identify any other unusual or unauthorized activities that might be related to the alert.
-- Utilize Osquery to gather additional context on the suspicious process. For example, run the following query to list all processes with similar arguments: `SELECT pid, name, path, cmdline FROM processes WHERE cmdline LIKE '%-action%' AND (cmdline LIKE '%-kerberoast%' OR cmdline LIKE '%askhash%' OR cmdline LIKE '%asktgs%' OR cmdline LIKE '%asktgt%' OR cmdline LIKE '%s4u%' OR (cmdline LIKE '%-ticket%' AND cmdline LIKE '%ptt%') OR (cmdline LIKE '%dump%' AND (cmdline LIKE '%tickets%' OR cmdline LIKE '%keytab%')));`
-- Investigate the network connections established by the suspicious process to identify any unusual or unauthorized communication with external or internal systems.
-- Analyze the system logs for any Kerberos-related events that coincide with the time of the alert to identify potential unauthorized authentication attempts.
-- Review recent changes to the system, such as software installations or updates, that might have introduced the Bifrost tool or similar utilities.
-- Check for any other alerts or indicators of compromise on the same host or within the same network segment that might suggest a broader attack campaign.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently exploiting Bifrost or similar tools, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate administrative activities: System administrators may use Bifrost or similar tools for legitimate purposes such as testing Kerberos configurations or performing security audits. These activities can trigger the detection rule, leading to false positives.
-- Automated scripts: Some organizations may have automated scripts that interact with Kerberos tickets for maintenance or monitoring purposes. These scripts might use command-line arguments similar to those flagged by the detection rule.
-- Security testing: Security teams conducting penetration tests or red team exercises might intentionally use Bifrost to simulate attacks, which could be misidentified as genuine threats.
-- To manage false positives, users can create exceptions for known benign activities by whitelisting specific processes or users that are verified to perform legitimate tasks. Additionally, organizations can refine the detection rule to exclude certain command-line arguments or process paths that are consistently associated with non-threatening behavior.
-
-### Response and remediation
-
-- Isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the presence of Bifrost or any unauthorized Kerberos ticket manipulation by reviewing process logs and command-line arguments.
-- Revoke any compromised Kerberos tickets and reset credentials for affected accounts to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the attack.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments on macOS systems for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates to macOS and related software.
-- Conduct a security audit of Kerberos configurations and policies to ensure they adhere to best practices and reduce the risk of exploitation.
-- Educate users and administrators on recognizing and reporting suspicious activities related to Kerberos authentication and ticket usage.
-- Review and update access controls and permissions to ensure the principle of least privilege is enforced across the network."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_mounting_smb_share.toml b/rules/macos/lateral_movement_mounting_smb_share.toml
index e2b8bda188d..567c47b2457 100644
--- a/rules/macos/lateral_movement_mounting_smb_share.toml
+++ b/rules/macos/lateral_movement_mounting_smb_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
   ) and
   not process.parent.executable : "/Applications/Google Drive.app/Contents/MacOS/Google Drive"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Mount SMB Share via Command Line
-
-SMB (Server Message Block) is a protocol used for network file sharing, allowing users to access files on remote servers. On macOS, commands like `mount_smbfs` facilitate this interaction. Adversaries exploit SMB to move laterally within networks by accessing shared resources using stolen credentials. The detection rule identifies suspicious command executions related to SMB mounting, excluding benign processes like Google Drive, to flag potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific command triggered the alert, focusing on the `process.name` and `process.args` fields to identify the exact method used for the SMB mount attempt.
-- Examine the `process.parent.executable` field to determine the parent process that initiated the SMB mount command, which can provide context on whether the action was user-initiated or potentially automated by a script or application.
-- Check the user account associated with the process execution to verify if it is a legitimate user and if the account has a history of accessing SMB shares.
-- Investigate the timestamp of the event to correlate with any other suspicious activities or alerts that occurred around the same time, which might indicate a coordinated attack or lateral movement attempt.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following Osquery query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
-- Analyze network logs to identify any unusual SMB traffic patterns or connections to unfamiliar or suspicious IP addresses, which might indicate unauthorized access attempts.
-- Review system logs for any failed authentication attempts or unusual login activities that could suggest credential theft or misuse.
-- Investigate any recent changes to the system or user account, such as password changes or new software installations, that could be related to the alert.
-- Check for any other alerts or indicators of compromise on the same host that might suggest a broader security incident.
-- Consult with the user or system owner to verify if the SMB mount attempt was legitimate and authorized, and gather any additional context or explanations they might provide.
-
-### False positive analysis
-
-- Known false positives for the Attempt to Mount SMB Share via Command Line rule include legitimate applications or scripts that mount SMB shares as part of their normal operation, such as backup software or file synchronization tools.
-- Users can handle these false positives by creating exceptions for specific processes or parent executables that are known to perform legitimate SMB mounting, such as excluding specific backup software paths.
-- Frequent non-threatening behaviors can be excluded by refining the detection rule to ignore processes with specific command-line arguments or parent processes that are verified as safe.
-- It is important to regularly review and update the list of exceptions to ensure that new legitimate applications are not mistakenly flagged as threats.
-- Users should also consider the context of the network environment, such as known trusted devices or users, to further refine the detection criteria and reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Verify the credentials used in the SMB mounting attempt and reset passwords for any compromised accounts.
-- Conduct a thorough investigation of the system to identify any additional unauthorized access or malicious activity, focusing on lateral movement patterns.
-- Review and analyze logs from the affected system and network devices to trace the source and scope of the intrusion.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed information on SMB-related activities and other remote service interactions.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Restore the system to its operational state by removing any malicious software, applying security patches, and verifying system integrity.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as disabling unnecessary SMB services, enforcing strong password policies, and using multi-factor authentication to reduce the risk of future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
index ba79256083c..c312d9699ad 100644
--- a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
+++ b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,49 +61,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.args:("-setremotelogin" and on) and
  not process.parent.executable : /usr/local/jamf/bin/jamf
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Remote SSH Login Enabled via systemsetup Command
-
-The `systemsetup` command in macOS is a utility that allows administrators to configure system settings, including enabling remote SSH login. While useful for legitimate remote management, adversaries can exploit this to gain unauthorized access. The detection rule identifies suspicious use of `systemsetup` to enable SSH, excluding known legitimate processes, thus highlighting potential lateral movement attempts by attackers.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `systemsetup` command with arguments `-setremotelogin on` and verify the process name as `systemsetup`.
-- Check the parent process of the `systemsetup` command to ensure it is not `/usr/local/jamf/bin/jamf`, as this is a known legitimate process.
-- Identify the user account associated with the process execution to determine if it is a known administrator or a potentially compromised account.
-- Examine the timestamp of the event to correlate with any other suspicious activities or anomalies in the system logs around the same time.
-- Use Osquery to list all current SSH configurations and check if remote login is enabled with the following query: `SELECT * FROM plist WHERE path = '/etc/ssh/sshd_config' AND key = 'PermitRootLogin';`
-- Investigate the system's SSH access logs to identify any recent or unusual login attempts, especially around the time the `systemsetup` command was executed.
-- Cross-reference the host IP address with known assets to determine if the system is part of a critical network segment or if it has any history of security incidents.
-- Analyze any network traffic logs to identify potential lateral movement or data exfiltration attempts following the enabling of remote SSH login.
-- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
-- Review any other security alerts or incidents involving the same host or user account to assess if this event is part of a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives for the Remote SSH Login Enabled via systemsetup Command rule often arise from legitimate administrative tools and scripts that manage macOS systems, such as configuration management software or custom scripts used by IT departments.
-- One common source of false positives is the use of the `systemsetup` command by authorized IT personnel or automated scripts to enable SSH for legitimate remote management tasks.
-- To manage these false positives, users can create exceptions for specific parent processes or scripts that are known to perform legitimate SSH enabling actions. This can be done by adding these processes to the exclusion list in the detection rule.
-- Another method to handle false positives is to monitor the frequency and context of the `systemsetup` command usage. If a particular process or script frequently triggers the rule but is verified as non-threatening, it can be safely excluded.
-- It's important to regularly review and update the list of exceptions to ensure that new legitimate processes are accounted for while maintaining the integrity of the detection rule against potential threats.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the process by checking the user account that executed the `systemsetup` command and cross-reference with known administrative activities.
-- Review system logs and security alerts to identify any other suspicious activities or unauthorized access attempts around the time the SSH was enabled.
-- If unauthorized access is confirmed, reset credentials for affected accounts and any other accounts that may have been compromised.
-- Disable remote SSH login if it was enabled without authorization and ensure that only authorized users can enable it in the future.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future unauthorized changes are detected promptly.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying any necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
-- Harden the system by enforcing strong authentication mechanisms, such as multi-factor authentication, and regularly auditing user permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_vpn_connection_attempt.toml b/rules/macos/lateral_movement_vpn_connection_attempt.toml
index 74ebc8983d5..6388074a40d 100644
--- a/rules/macos/lateral_movement_vpn_connection_attempt.toml
+++ b/rules/macos/lateral_movement_vpn_connection_attempt.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -66,48 +66,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
     (process.name : "osascript" and process.command_line : "osascript*set VPN to service*")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Virtual Private Network Connection Attempt
-
-Virtual Private Networks (VPNs) are crucial for secure remote access, encrypting data between a user and the network. However, adversaries can exploit VPNs to move laterally within a network, gaining unauthorized access to remote systems. The detection rule identifies suspicious VPN connection attempts on macOS by monitoring specific command executions, helping to flag potential misuse by adversaries.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments that triggered the rule, focusing on `process.name` and `process.args` fields.
-- Check the `process.command_line` field for any unusual or unexpected command executions that might indicate malicious intent.
-- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the timestamp of the event to correlate with any other suspicious activities or alerts that occurred around the same time.
-- Use Osquery to list all active VPN connections on the system with a query like: `SELECT * FROM vpn_connections;` to identify any unauthorized or unexpected connections.
-- Cross-reference the IP addresses associated with the VPN connections against known malicious IP databases or threat intelligence feeds.
-- Analyze the parent process of the suspicious VPN connection attempt to understand how the process was initiated and if it was part of a larger attack chain.
-- Review system logs for any failed VPN connection attempts that might indicate brute force or unauthorized access attempts.
-- Investigate any recent changes to VPN configurations or settings on the system that could have been altered to facilitate unauthorized access.
-- Check for any other alerts or indicators of compromise on the same host that might suggest a broader compromise or lateral movement attempt.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate network administrators may frequently use macOS built-in commands like `networksetup`, `scutil`, or `osascript` to manage VPN connections as part of their regular duties. These actions, while flagged by the detection rule, are not necessarily malicious.
-- Automated scripts: Organizations may deploy scripts that automate VPN connections for users, especially in environments where remote work is common. These scripts can trigger the detection rule but are typically benign.
-- User-initiated connections: Employees might manually connect to VPNs using the same commands for legitimate purposes, such as accessing company resources remotely, which can result in false positives.
-- To manage these false positives, users can create exceptions for known, non-threatening behaviors by whitelisting specific processes or command patterns that are verified as safe. This can be done by maintaining a list of trusted scripts or administrative actions and excluding them from triggering alerts. Regularly reviewing and updating this list ensures that only genuine threats are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further lateral movement by the adversary.
-- Review the VPN connection logs and process execution details to identify unauthorized access attempts and determine the scope of the intrusion.
-- Terminate any suspicious VPN sessions and change credentials associated with the compromised VPN accounts to prevent further unauthorized access.
-- Conduct a thorough investigation to identify any additional compromised systems or accounts within the network, leveraging MITRE ATT&CK framework for guidance on potential lateral movement techniques.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed VPN connection attempts and process execution data for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the affected system to its operational state by reimaging the device and applying the latest security patches and updates.
-- Conduct a security review to identify and address any vulnerabilities or misconfigurations that may have facilitated the attack, such as weak VPN configurations or insufficient access controls.
-- Educate users on secure VPN usage practices and the importance of reporting suspicious activities to help prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_account_creation_hide_at_logon.toml b/rules/macos/persistence_account_creation_hide_at_logon.toml
index b7265c05198..88551bdc5f7 100644
--- a/rules/macos/persistence_account_creation_hide_at_logon.toml
+++ b/rules/macos/persistence_account_creation_hide_at_logon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,48 +58,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:dscl and process.args:(IsHidden and create and (true or 1 or yes))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Hidden Local User Account Creation
-
-In macOS environments, the `dscl` command-line utility is used for directory service management, including user account creation. Adversaries may exploit this to create hidden accounts, evading detection and maintaining persistence. The detection rule identifies suspicious `dscl` usage patterns, such as attempts to set accounts as hidden, signaling potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `dscl` command with arguments indicating account creation and hidden status (`IsHidden`, `create`, `true`, `1`, or `yes`).
-- Cross-reference the timestamp of the alert with other logs to identify any correlated activities or anomalies around the same time.
-- Use Osquery to list all user accounts and check for any discrepancies or unexpected hidden accounts with the query: `SELECT * FROM users WHERE uid >= 500 AND NOT hidden = 0;`.
-- Investigate the parent process of the `dscl` command to determine if it was executed by a legitimate user or process.
-- Check for any recent changes in user permissions or group memberships that might indicate privilege escalation.
-- Analyze the command history of the user who executed the `dscl` command to identify any other suspicious activities.
-- Review system logs for any failed login attempts or unusual login patterns that might suggest unauthorized access attempts.
-- Examine network logs for any outbound connections from the host that could indicate data exfiltration or communication with a command and control server.
-- Verify the integrity of critical system files and configurations to ensure they have not been tampered with.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar tactics.
-
-### False positive analysis
-
-- System administrators or IT personnel may use the `dscl` command to create hidden accounts for legitimate purposes, such as managing system processes or services that require a separate account. These actions can trigger the detection rule but are not malicious.
-- Some applications or scripts may automate the creation of hidden accounts for functionality or security reasons, such as sandboxing or running background tasks. These automated processes can be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for known and trusted processes or accounts by whitelisting specific `dscl` command patterns or arguments that are regularly used in their environment.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, and monitor for any changes in behavior that might indicate a new threat.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
-- Review the process execution logs to confirm the creation of a hidden user account using the `dscl` command with suspicious arguments.
-- Identify and document the hidden user account details, including username and UID, for further investigation.
-- Remove the unauthorized hidden user account using the `dscl` command to prevent further unauthorized access.
-- Conduct a thorough review of system logs and user activity to identify any additional unauthorized changes or suspicious behavior.
-- Escalate the incident to the security operations team for further analysis and to determine if other systems may be affected.
-- Implement enhanced logging policies to capture detailed process execution and user account changes for future investigations.
-- Integrate with a centralized security information and event management (SIEM) system to correlate events and improve detection capabilities.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, ensuring no backdoors or persistence mechanisms remain.
-- Apply hardening measures such as disabling unnecessary services, enforcing strong password policies, and regularly auditing user accounts to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_change_launch_agents_file.toml b/rules/macos/persistence_creation_change_launch_agents_file.toml
index 3e0b1abea92..043c9618c04 100644
--- a/rules/macos/persistence_creation_change_launch_agents_file.toml
+++ b/rules/macos/persistence_creation_change_launch_agents_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -63,49 +63,6 @@ sequence by host.id with maxspan=1m
  ]
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Launch Agent Creation or Modification and Immediate Loading
-
-Launch Agents in macOS are used to run scripts or applications automatically at user login, providing a mechanism for persistence. Adversaries exploit this by creating or modifying Launch Agents to execute malicious code. The detection rule identifies such abuse by monitoring for new or altered Launch Agent files and their immediate loading via `launchctl`, indicating potential unauthorized persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path of the Launch Agent that was created or modified, focusing on paths like `/System/Library/LaunchAgents/*`, `/Library/LaunchAgents/*`, and `/Users/*/Library/LaunchAgents/*`.
-- Check the timestamp of the file creation or modification event to correlate it with any known user activity or scheduled tasks.
-- Investigate the user account associated with the creation or modification of the Launch Agent to determine if the activity aligns with expected behavior.
-- Examine the contents of the Launch Agent plist file to identify any suspicious or unexpected scripts or executables being launched.
-- Use Osquery to list all Launch Agents on the system and compare them against known good configurations. Example query: `SELECT * FROM launchd WHERE path LIKE '/Users/%/Library/LaunchAgents/%';`
-- Analyze the process execution details of `launchctl` to verify the arguments used and ensure they match legitimate use cases.
-- Cross-reference the process start time of `launchctl` with the file modification time to confirm immediate loading, which may indicate malicious intent.
-- Investigate any network connections or external communications initiated by the processes or scripts specified in the Launch Agent.
-- Review system logs around the time of the event for any additional indicators of compromise or related suspicious activity.
-- Check for any other recent alerts or anomalies on the host that might suggest a broader compromise or coordinated attack.
-
-### False positive analysis
-
-- Routine software updates or legitimate application installations may create or modify Launch Agents, triggering the detection rule. Users can manage these by maintaining a list of trusted applications and their expected behaviors.
-- System maintenance tools or user-installed utilities that automate tasks at login might also create or modify Launch Agents. Users should verify the legitimacy of these tools and consider excluding them from monitoring if they are deemed safe.
-- Developers or power users who frequently create or modify Launch Agents for testing or automation purposes may inadvertently trigger the rule. These users can be excluded from monitoring by creating exceptions based on user accounts or specific directories.
-- Some enterprise management tools may deploy configuration profiles that include Launch Agents, which could be mistaken for malicious activity. Organizations should document and whitelist these tools to prevent false positives.
-- Users can implement a baseline of known good Launch Agents and compare new or modified entries against this baseline to identify legitimate changes, reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
-- Investigate the newly created or modified Launch Agent file to determine its origin and purpose, checking for any known malicious signatures or unusual behavior.
-- Use endpoint detection and response (EDR) tools to analyze the process tree and identify any additional malicious processes or files associated with the Launch Agent.
-- Remove the unauthorized Launch Agent file and any associated malicious files or processes from the system.
-- Review user accounts and permissions to ensure no unauthorized changes have been made, and reset passwords if necessary.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed information on file creation, modification, and process execution, focusing on Launch Agents and launchctl activities.
-- Integrate threat intelligence feeds to correlate the detected activity with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, and applying any necessary security patches or updates.
-- Harden the system by restricting write access to Launch Agent directories, implementing application whitelisting, and educating users on recognizing phishing attempts and other common attack vectors."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_hidden_login_item_osascript.toml b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
index 4d4424be0aa..1b48ca3d708 100644
--- a/rules/macos/persistence_creation_hidden_login_item_osascript.toml
+++ b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,48 +58,6 @@ query = '''
 process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : "osascript" and
  process.command_line : "osascript*login item*hidden:true*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation of Hidden Login Item via Apple Script
-
-AppleScript is a scripting language used to automate tasks on macOS. Adversaries may exploit it to create hidden login items, ensuring malicious programs start automatically while remaining concealed. The detection rule identifies such abuse by monitoring the execution of AppleScript commands that create hidden login items, focusing on specific command patterns indicative of this stealthy persistence technique.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `osascript` process execution with the command line pattern `osascript*login item*hidden:true*`.
-- Verify the timestamp of the event to understand when the suspicious activity occurred.
-- Identify the user account under which the `osascript` process was executed to determine if it aligns with expected user behavior.
-- Check the parent process of `osascript` to identify how the script was initiated and if it was triggered by another suspicious process.
-- Use Osquery to list all login items for the affected user to identify any hidden items. Example query: `SELECT * FROM login_items WHERE hidden = 1;`
-- Investigate the script content if accessible, to understand its purpose and any potential malicious actions it might perform.
-- Correlate the event with other logs, such as system logs or application logs, to gather additional context around the time of execution.
-- Examine recent file modifications in common script directories (e.g., `/Library/Scripts`, `~/Library/Scripts`) to identify any unauthorized changes.
-- Check for any recent changes in user permissions or system settings that could facilitate the execution of unauthorized scripts.
-- Review network activity logs around the time of the event to detect any unusual outbound connections that might indicate data exfiltration or command-and-control communication.
-
-### False positive analysis
-
-- Legitimate applications or scripts that use AppleScript to automate tasks may inadvertently trigger this detection rule if they create login items with hidden attributes. For example, productivity tools or system management scripts that use hidden login items for legitimate purposes could be flagged.
-- Users can manage these false positives by creating exceptions for known and trusted applications or scripts. This can be done by identifying the specific command patterns or process names associated with these legitimate activities and excluding them from the detection rule.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule against actual threats.
-- Consider implementing additional context checks, such as verifying the source or signature of the script, to differentiate between benign and potentially malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further spread or communication with potential command and control servers.
-- Investigate the process tree and command line arguments of the osascript execution to identify any associated malicious scripts or payloads.
-- Terminate any suspicious processes that were initiated by the osascript command to halt any ongoing malicious activity.
-- Review and remove any unauthorized login items or startup scripts to eliminate persistence mechanisms.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and command line arguments for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured.
-- Apply security hardening measures such as disabling unnecessary scripting capabilities and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
index 6ba07078f04..0c3009d0cc4 100644
--- a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
+++ b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,49 +61,6 @@ sequence by host.id with maxspan=1m
  [file where host.os.type == "macos" and event.type != "deletion" and file.path : ("/System/Library/LaunchDaemons/*", "/Library/LaunchDaemons/*")]
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 LaunchDaemon Creation or Modification and Immediate Loading
-
-LaunchDaemons in macOS are system-level services that start at boot and run in the background, often used for legitimate system tasks. Adversaries exploit this by creating or altering LaunchDaemons to ensure malicious payloads persistently execute. The detection rule identifies such abuse by monitoring for new or modified LaunchDaemons followed by their immediate loading, signaling potential unauthorized persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `host.id` and `file.path` involved in the LaunchDaemon creation or modification event.
-- Verify the legitimacy of the LaunchDaemon by checking the `file.path` against known system and third-party LaunchDaemons. Look for any unusual or unexpected entries.
-- Use Osquery to list all LaunchDaemons on the affected host and compare them with the baseline of known good configurations. Example query: `SELECT * FROM launchd WHERE path LIKE '/Library/LaunchDaemons/%' OR path LIKE '/System/Library/LaunchDaemons/%';`
-- Investigate the `process.name` and `process.args` fields to confirm the use of `launchctl` for loading the LaunchDaemon. Check for any anomalies in the arguments used.
-- Examine the `process.parent` and `process.executable` fields to determine the parent process that initiated the `launchctl` command, which may provide insight into how the LaunchDaemon was loaded.
-- Check the file metadata, such as creation and modification timestamps, to identify any discrepancies or unusual patterns that could indicate tampering.
-- Review recent system logs and security logs on the affected host for any related events or errors that coincide with the LaunchDaemon creation or modification.
-- Investigate the user account context under which the LaunchDaemon was created or modified to determine if it aligns with expected administrative activity.
-- Correlate the event with other alerts or suspicious activities on the same host to identify potential patterns or related incidents.
-- Consult threat intelligence sources to determine if the LaunchDaemon's name or characteristics match known malicious indicators or tactics.
-
-### False positive analysis
-
-- System updates or legitimate software installations may create or modify LaunchDaemons, triggering the detection rule. Users should verify if the changes coincide with known updates or installations.
-- Administrative tasks performed by IT personnel, such as configuring new services or updating existing ones, can also result in false positives. Users can manage these by maintaining a log of authorized changes and cross-referencing them with alerts.
-- Some third-party applications may use LaunchDaemons for legitimate background processes. Users can create exceptions for these applications by identifying their specific LaunchDaemon paths and excluding them from monitoring.
-- Regular maintenance scripts or system management tools might load LaunchDaemons as part of their operation. Users should document these tools and consider excluding their associated processes from the detection rule.
-- To handle frequent non-threatening behaviors, users can implement a whitelist of known safe LaunchDaemons and processes, ensuring that only unauthorized or unexpected changes trigger alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on recent changes to LaunchDaemons and correlating with other suspicious activities.
-- Review and analyze system logs, including file creation and modification times, to determine the timeline of the unauthorized LaunchDaemon creation or modification.
-- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) and ensure no other persistence mechanisms are in place.
-- Remove or disable the malicious LaunchDaemon by deleting the associated files and unloading them using the 'launchctl' command.
-- Restore the system to a known good state using backups or system snapshots, ensuring that all malicious changes are reverted.
-- Implement enhanced logging policies to capture detailed file and process activity, focusing on LaunchDaemon directories and 'launchctl' usage.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate alerts with known threat actor tactics.
-- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for further analysis and response.
-- Apply hardening measures such as restricting write access to LaunchDaemon directories, enforcing strict user permissions, and regularly auditing system configurations to prevent future persistence attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
index 09eec4330c9..86b2ab22a1b 100644
--- a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
+++ b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -64,50 +64,6 @@ event.category:file and host.os.type:macos and not event.type:deletion and
   not (/Library/Security/SecurityAgentPlugins/KandjiPassport.bundle/* or /Library/Security/SecurityAgentPlugins/TeamViewerAuthPlugin.bundle/*)) and
   not (process.name:shove and process.code_signature.trusted:true)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Authorization Plugin Modification
-
-Authorization plugins in macOS extend the system's authentication capabilities, enabling features like third-party multi-factor authentication. Adversaries may exploit these plugins to maintain persistence or capture credentials by modifying or adding unauthorized plugins. The detection rule identifies suspicious modifications by monitoring changes in specific plugin directories, excluding known trusted plugins and processes, to flag potential unauthorized activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process name involved in the modification, focusing on the `file.path` and `process.name` fields.
-- Verify the legitimacy of the modified or added plugin by checking the file path against known authorized plugins, ensuring it is not a false positive.
-- Use Osquery to list all plugins in the `/Library/Security/SecurityAgentPlugins/` directory to identify any unauthorized or suspicious plugins. Example query: `SELECT path, mode, uid, gid, size, atime, mtime, ctime FROM file WHERE directory = '/Library/Security/SecurityAgentPlugins/';`
-- Investigate the process that made the modification by examining the `process.name` and `process.code_signature.trusted` fields to determine if it is a trusted process.
-- Check the modification timestamps (`mtime` and `ctime`) of the suspicious plugin files to correlate with any known user activity or scheduled tasks.
-- Review system logs around the time of the modification for any unusual activity or errors that might provide additional context.
-- Cross-reference the involved process with known software installations or updates to determine if the modification was part of a legitimate update.
-- Investigate the user account associated with the modification to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Examine network logs for any unusual outbound connections from the host around the time of the modification, which might suggest data exfiltration or command and control activity.
-- Consult threat intelligence sources to check if the identified plugin or process is associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- Known false positives may include legitimate software updates or installations that modify authorization plugins, such as updates to security software or new installations of trusted third-party authentication tools.
-- Users can handle these false positives by creating exceptions for known trusted plugins and processes, ensuring that updates from verified vendors are not flagged.
-- Regularly review and update the list of trusted plugins and processes to include new legitimate software that may be installed in the monitored directories.
-- Implement a process to verify the digital signatures of plugins and processes, allowing those with valid and trusted signatures to be excluded from alerts.
-- Consider the context of the detected changes, such as recent software installations or updates, to determine if the activity is expected and non-threatening.
-- Collaborate with IT and security teams to maintain an updated inventory of authorized plugins and processes, which can be used to refine detection rules and reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
-- Conduct a thorough investigation to identify any unauthorized plugins in the /Library/Security/SecurityAgentPlugins/ directory and verify their legitimacy.
-- Review system logs and security events to trace the origin of the unauthorized plugin modification and identify any associated suspicious activities or processes.
-- Remove any unauthorized or suspicious plugins and restore any modified legitimate plugins to their original state using trusted backups.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed file and process activities, focusing on the SecurityAgentPlugins directory and related processes.
-- Integrate with threat intelligence platforms to correlate the incident with known threat actor tactics, techniques, and procedures (TTPs) as per MITRE ATT&CK framework.
-- Apply security patches and updates to the macOS system to mitigate any known vulnerabilities that could be exploited by similar threats.
-- Educate users on recognizing phishing attempts and other social engineering tactics that could lead to unauthorized plugin installations.
-- Consider deploying additional security controls, such as application whitelisting and endpoint detection and response (EDR) solutions, to prevent future unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_crontab_creation.toml b/rules/macos/persistence_crontab_creation.toml
index 988dd6e5213..b8396765b58 100644
--- a/rules/macos/persistence_crontab_creation.toml
+++ b/rules/macos/persistence_crontab_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,49 +61,6 @@ query = '''
 file where host.os.type == "macos" and event.type != "deletion" and process.name != null and
   file.path : "/private/var/at/tabs/*" and not process.executable == "/usr/bin/crontab"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious CronTab Creation or Modification
-
-Cron jobs are scheduled tasks in Unix-like systems, including macOS, used for automating repetitive tasks. Adversaries may exploit cron to maintain persistence by creating or altering cron jobs using unconventional processes like Python scripts. The detection rule identifies such anomalies by flagging non-standard processes modifying cron files, which could indicate malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and executable path that triggered the alert, focusing on the `process.name` and `process.executable` fields.
-- Verify the legitimacy of the process by checking the process's parent and child processes to understand its context and origin.
-- Use Osquery to list all cron jobs on the system and identify any recent changes. Example query: `SELECT * FROM crontab WHERE path LIKE '/private/var/at/tabs/%';`
-- Investigate the user account associated with the process to determine if it has a history of creating or modifying cron jobs.
-- Check the file modification timestamps in `/private/var/at/tabs/` to correlate with the alert time and identify any unauthorized changes.
-- Examine system logs around the time of the alert for any additional suspicious activity or related events.
-- Investigate the network activity of the process to identify any external connections that might indicate command and control communication.
-- Review the process's binary or script for any signs of tampering or malicious code, especially if it is a non-standard executable for cron modifications.
-- Cross-reference the process and file path with threat intelligence sources to identify any known malicious indicators.
-- Assess the system for other signs of compromise, such as unauthorized user accounts or unusual system behavior, to determine if the cron modification is part of a larger attack.
-
-### False positive analysis
-
-- System administrators or legitimate software may use scripts or automation tools to manage cron jobs, leading to false positives when these processes modify cron files. 
-- Development environments or testing scenarios might involve the use of scripts to automate task scheduling, which could trigger the rule.
-- Users can handle these false positives by creating exceptions for known and trusted processes that regularly modify cron files, such as specific automation scripts or administrative tools.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening processes are excluded from detection.
-- Consider the context of the environment, such as development or production, to better assess whether a detected modification is likely to be benign.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Investigate the process that modified the crontab by reviewing process execution details, including the parent process, command-line arguments, and user context.
-- Check for other signs of compromise on the system, such as unusual network connections, unexpected user accounts, or additional unauthorized scheduled tasks.
-- Remove or disable the suspicious cron job and any other unauthorized persistence mechanisms identified during the investigation.
-- Restore the crontab to its original state using backups or by manually recreating legitimate scheduled tasks.
-- Escalate the incident to the security operations team if the investigation reveals evidence of a broader compromise or if the threat actor's identity or intent is unclear.
-- Implement enhanced logging and monitoring for cron job modifications and process execution to detect similar activities in the future.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and contextualize alerts with known threat actor behaviors.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
-- Apply system hardening measures, such as restricting cron job creation to authorized users and processes, and regularly review and audit scheduled tasks for anomalies."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
index 803ba06956f..66941650995 100644
--- a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
+++ b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -63,55 +63,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:.* and process.parent.executable:/sbin/launchd
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Hidden Child Process of Launchd
-
-Launchd is a key macOS system process responsible for managing system and user services. Adversaries may exploit it to gain persistence by creating hidden processes that execute at login. The detection rule identifies such hidden child processes initiated by launchd, focusing on process start events and their parent executable paths, thus highlighting potential unauthorized modifications to system processes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a hidden child process initiated by launchd, focusing on the `process.name` and `process.parent.executable` fields.
-- Verify the legitimacy of the child process by checking its file path and hash against known good files and threat intelligence databases.
-- Use Osquery to list all current processes and their parent processes to identify any other suspicious child processes of launchd:
-  ```sql
-  SELECT pid, name, path, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE path = '/sbin/launchd');
-  ```
-- Investigate the file attributes of the suspicious process using Osquery to check for hidden or unusual file properties:
-  ```sql
-  SELECT * FROM file WHERE path = '<path_to_suspicious_process>';
-  ```
-- Examine the creation and modification timestamps of the suspicious process file to determine if it aligns with known legitimate updates or installations.
-- Check the system logs for any unusual activity or errors around the time the suspicious process was started, focusing on `event.category:process` and `event.type:start`.
-- Investigate the user account context under which the suspicious process was executed to determine if it aligns with expected user behavior.
-- Review recent changes to launch agents and daemons by listing files in `/Library/LaunchAgents`, `/Library/LaunchDaemons`, and `~/Library/LaunchAgents` for any unauthorized modifications.
-- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack campaign.
-
-### False positive analysis
-
-- Some legitimate applications may create hidden child processes of launchd as part of their normal operation, such as system utilities or software updates. These processes might be flagged as suspicious but are benign.
-- Developers and advanced users might run scripts or applications that intentionally create hidden processes for testing or automation purposes, which could trigger the detection rule.
-- Security software or system management tools may also generate hidden processes to perform background tasks, leading to false positives.
-- To manage these false positives, users can create exceptions for known and trusted applications by specifying their process names or paths in the detection rule.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the integrity of the detection system.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
-- Use endpoint detection and response (EDR) tools to perform a detailed analysis of the suspicious process and its parent-child relationship to confirm malicious activity.
-- Terminate the hidden child process and any other suspicious processes spawned by launchd to stop potential malicious actions.
-- Review and remove any unauthorized launch agents, daemons, or logon items that may have been installed to ensure persistence.
-- Conduct a thorough audit of user accounts and permissions to identify any unauthorized changes or accounts that may have been created by the adversary.
-- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation.
-- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships, to improve future detection capabilities.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to enhance detection and response strategies.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
-- Apply system hardening measures, such as disabling unnecessary services, enforcing strong authentication mechanisms, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_directory_services_plugins_modification.toml b/rules/macos/persistence_directory_services_plugins_modification.toml
index 18b4f5d9ab8..6212dfc742d 100644
--- a/rules/macos/persistence_directory_services_plugins_modification.toml
+++ b/rules/macos/persistence_directory_services_plugins_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,49 +59,6 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:deletion and
   file.path:/Library/DirectoryServices/PlugIns/*.dsplug
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via DirectoryService Plugin Modification
-
-DirectoryService PlugIns on macOS are integral for managing directory-based services, automatically executing on boot. Adversaries exploit this by modifying or creating malicious plugins to ensure their code runs persistently. The detection rule monitors for non-deletion events involving dsplug files in the PlugIns directory, flagging potential unauthorized changes indicative of persistence tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.category is 'file' and host.os.type is 'macos', ensuring the alert is relevant to the DirectoryService Plugin Modification.
-- Verify the file path in the alert matches the pattern /Library/DirectoryServices/PlugIns/*.dsplug to confirm the location of the suspicious file.
-- Check the timestamp of the event to determine when the modification or creation occurred, which can help correlate with other system activities.
-- Investigate the file metadata, such as the file size, creation date, and modification date, to identify any anomalies or recent changes.
-- Use Osquery to list all files in the /Library/DirectoryServices/PlugIns/ directory and gather additional details. Example query: `SELECT path, size, atime, mtime, ctime FROM file WHERE directory = '/Library/DirectoryServices/PlugIns/' AND path LIKE '%.dsplug';`
-- Examine the file's contents or hash to determine if it matches known malicious signatures or if it has been altered from a known good state.
-- Review system logs around the time of the event for any unusual activities or errors that might indicate tampering or unauthorized access.
-- Check for any recent user logins or privilege escalations that could be related to the modification of the DirectoryService Plugin.
-- Investigate any other alerts or events from the same host around the same time to identify potential patterns or related activities.
-- Consult threat intelligence sources to see if the file or its characteristics match any known threats or indicators of compromise.
-
-### False positive analysis
-
-- Routine system updates or legitimate software installations may trigger the rule by creating or modifying dsplug files, as these processes often involve updating or adding new plugins to the DirectoryServices PlugIns folder.
-- Administrative actions by IT personnel, such as troubleshooting or configuring directory services, can also result in legitimate modifications to dsplug files, leading to false positives.
-- Users can manage these false positives by creating exceptions for known and trusted software update processes or specific administrative actions, ensuring that these are documented and reviewed regularly to maintain security integrity.
-- Implementing a whitelist of approved dsplug files or directories can help reduce noise from expected changes, allowing security teams to focus on truly suspicious activities.
-- Regularly reviewing and updating the list of exceptions is crucial to adapt to changes in software and system configurations, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
-- Conduct a thorough investigation to identify any unauthorized dsplug files in the /Library/DirectoryServices/PlugIns/ directory and verify their legitimacy.
-- Review system logs and security alerts to determine the timeline and method of the unauthorized modification or creation of the dsplug file.
-- Remove any unauthorized or malicious dsplug files and restore any legitimate files from a known good backup.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on the DirectoryServices PlugIns directory.
-- Integrate with endpoint detection and response (EDR) tools to monitor for similar persistence techniques and improve detection capabilities.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that the DirectoryService daemon is functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and update security policies to prevent future occurrences.
-- Implement hardening measures such as restricting write permissions to critical directories and employing application whitelisting to prevent unauthorized code execution."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_docker_shortcuts_plist_modification.toml b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
index db6ae252b5a..25ac05e33e9 100644
--- a/rules/macos/persistence_docker_shortcuts_plist_modification.toml
+++ b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ event.category:file and host.os.type:macos and event.action:modification and
  not process.name:(xpcproxy or cfprefsd or plutil or jamf or PlistBuddy or InstallerRemotePluginService) and
  not process.executable:(/Library/Addigy/download-cache/* or "/Library/Kandji/Kandji Agent.app/Contents/MacOS/kandji-library-manager")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via Docker Shortcut Modification
-
-In macOS environments, the Dock is a user interface feature that provides quick access to applications. It relies on property list files to manage its configuration. Adversaries may exploit this by altering these files to redirect shortcuts to malicious applications, thus achieving persistence. The detection rule identifies unauthorized modifications to these property lists, excluding legitimate processes, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process name involved in the modification of the `com.apple.dock.plist` file.
-- Verify the legitimacy of the process that triggered the alert by checking its hash and comparing it against known malicious or benign hashes.
-- Use Osquery to list recent modifications to the `com.apple.dock.plist` file with a query like: `SELECT * FROM file WHERE path = '/Users/*/Library/Preferences/com.apple.dock.plist' ORDER BY atime DESC LIMIT 5;` to gather context on recent changes.
-- Investigate the user account associated with the modification by checking the file path for the specific user directory and correlating it with recent login activities.
-- Examine the process tree to understand the parent process and any child processes spawned by the suspicious process to identify potential lateral movement or further persistence mechanisms.
-- Check system logs for any unusual activity around the time of the modification, focusing on `event.category:file` and `event.action:modification` to correlate with other suspicious events.
-- Investigate the network activity of the process involved in the modification to identify any suspicious outbound connections that could indicate data exfiltration or command and control communication.
-- Review the system's installed applications and recent installations to identify any unauthorized or suspicious software that could be related to the persistence mechanism.
-- Cross-reference the process executable path against known legitimate paths to ensure it is not masquerading as a legitimate application.
-- Consult threat intelligence sources to determine if the process name or executable path has been associated with known threats or campaigns, providing additional context for the investigation.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate applications or system processes that modify the Dock property list for valid reasons, such as user preference changes or application updates.
-- Common non-threatening processes that could trigger false positives include system utilities or management tools that adjust Dock settings as part of their normal operation.
-- Users can manage these false positives by creating exceptions for specific processes or executable paths that are known to be safe, ensuring they are excluded from triggering alerts.
-- Regularly review and update the list of excluded processes to adapt to changes in legitimate software behavior and minimize unnecessary alerts.
-- Consider monitoring the frequency and context of modifications to the Dock property list to distinguish between routine changes and potential threats, allowing for more informed decision-making regarding exclusions.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to confirm unauthorized modifications by reviewing the specific changes in the com.apple.dock.plist file.
-- Identify and terminate any malicious processes that may have been initiated as a result of the dock modification.
-- Restore the original com.apple.dock.plist file from a known good backup to ensure the Dock shortcuts are pointing to legitimate applications.
-- Review system logs and security alerts to identify any other signs of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has established other persistence mechanisms.
-- Implement enhanced logging policies to capture detailed file modification events and process execution details for future investigations.
-- Integrate with endpoint detection and response (EDR) tools to improve visibility and automate detection of similar threats.
-- Educate users on recognizing suspicious activities and the importance of reporting unexpected behavior in their applications.
-- Apply security hardening measures such as restricting write permissions to critical configuration files and regularly updating macOS and installed applications to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_emond_rules_file_creation.toml b/rules/macos/persistence_emond_rules_file_creation.toml
index 65c2a6cd650..e6bbcdc0bd2 100644
--- a/rules/macos/persistence_emond_rules_file_creation.toml
+++ b/rules/macos/persistence_emond_rules_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ query = '''
 file where host.os.type == "macos" and event.type != "deletion" and
  file.path : ("/private/etc/emond.d/rules/*.plist", "/etc/emon.d/rules/*.plist", "/private/var/db/emondClients/*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Emond Rules Creation or Modification
-
-The Event Monitor Daemon (emond) on macOS is a service that executes commands based on specific events, such as system startup or user login. Adversaries can exploit emond by creating or altering rules to trigger malicious actions during these events. The detection rule monitors for non-deletion events involving emond rule files, identifying potential unauthorized modifications that could indicate abuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path involved in the rule creation or modification, focusing on paths like "/private/etc/emond.d/rules/*.plist" and "/private/var/db/emondClients/*".
-- Check the timestamp of the event to determine when the rule was created or modified, which can help correlate with other system activities or user actions.
-- Identify the user account associated with the event to determine if the action was performed by an authorized user or potentially compromised account.
-- Use Osquery to list all current emond rules and their contents to understand what actions are being triggered. Example query: `SELECT * FROM file WHERE path LIKE '/private/etc/emond.d/rules/%.plist' OR path LIKE '/private/var/db/emondClients/%';`
-- Investigate the contents of the modified or newly created plist file to identify any suspicious commands or scripts that may be executed.
-- Cross-reference the event with system logs to identify any related activities, such as user logins, system startups, or other event triggers around the same time.
-- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized access to modify emond rules.
-- Look for other signs of compromise on the system, such as unusual network connections, unexpected processes, or other file modifications.
-- Review historical data to determine if similar emond rule modifications have occurred in the past, which could indicate a recurring pattern or persistent threat.
-- Consult threat intelligence sources to see if the identified modifications or commands match known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- Routine system updates or legitimate software installations may modify emond rule files, leading to false positives. Users should verify if the changes coincide with known update schedules or software installations.
-- Administrative tasks performed by IT personnel, such as configuring new system policies or security settings, might also trigger alerts. Organizations can maintain a whitelist of authorized personnel and their expected activities to reduce unnecessary alerts.
-- Automated scripts or management tools used for system maintenance could inadvertently modify emond rules. Users should document and review these tools' activities to distinguish between legitimate and suspicious modifications.
-- To manage these false positives, users can create exceptions for known benign activities by specifying trusted file paths or processes in their monitoring tools, ensuring that only unexpected changes trigger alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
-- Conduct a thorough investigation to identify any unauthorized emond rule files by comparing them against a known-good baseline of emond rules.
-- Review system logs and emond logs to trace any suspicious activities or commands executed as a result of the modified or newly created rules.
-- Remove any unauthorized or malicious emond rule files and restore the original rules from a secure backup.
-- Scan the system for additional signs of compromise, such as unauthorized user accounts or unexpected network connections.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed information about file modifications and system events related to emond.
-- Integrate with a security information and event management (SIEM) system to correlate emond rule changes with other security events for comprehensive threat detection.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are hardened.
-- Educate users and administrators about the risks associated with emond rule modifications and provide training on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_emond_rules_process_execution.toml b/rules/macos/persistence_emond_rules_process_execution.toml
index d201e8574dd..ba4a84be2bd 100644
--- a/rules/macos/persistence_emond_rules_process_execution.toml
+++ b/rules/macos/persistence_emond_rules_process_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -85,48 +85,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
    "base64",
    "launchctl")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Emond Child Process
-
-The Event Monitor Daemon (emond) on macOS is a service that executes predefined actions when specific system events occur. Adversaries exploit emond by crafting rules that trigger malicious processes during events like startup or login. The detection rule identifies unusual child processes spawned by emond, such as shells or scripting languages, which are indicative of potential abuse for persistence or unauthorized command execution.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and parent process name, ensuring they match the suspicious criteria outlined in the detection rule.
-- Check the timestamp of the event to determine when the suspicious child process was initiated and correlate it with any known user activities or scheduled tasks.
-- Investigate the command line arguments of the suspicious process to understand its intended actions and identify any potentially malicious commands or scripts.
-- Examine the user account associated with the process to determine if it aligns with expected user behavior or if it indicates potential compromise.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all child processes of emond: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'emond');`
-- Check system logs for any related events around the time of the alert, such as login attempts, system reboots, or other process executions that might provide context.
-- Investigate the origin of the emond rule that triggered the process execution by reviewing configuration files or system settings that define event actions.
-- Analyze network activity associated with the process to identify any suspicious outbound connections or data exfiltration attempts.
-- Cross-reference the process hash with threat intelligence databases to determine if it is associated with known malware or adversary techniques.
-- Review historical data to identify any previous occurrences of similar suspicious child processes spawned by emond, which could indicate a persistent threat.
-
-### False positive analysis
-
-- System administrators or legitimate software may use scripting languages or command-line tools for routine maintenance tasks, which could trigger the rule. For example, automated scripts executed during system startup or user login might be flagged as suspicious.
-- Developers and IT professionals often use shells and scripting languages for testing and development purposes, which could result in false positives if these activities are performed on systems monitored by the rule.
-- Users can manage false positives by creating exceptions for known, benign processes that are frequently executed by emond. This can be done by maintaining a whitelist of trusted scripts or applications that are expected to run as child processes of emond.
-- Regularly review and update the list of exceptions to ensure that only legitimate processes are excluded, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized emond rules by reviewing the configuration files located in /etc/emond.d/rules/.
-- Terminate any suspicious child processes spawned by emond to halt potential malicious activities.
-- Review system logs and security alerts to gather additional context on the suspicious activity and identify any other affected systems.
-- Escalate the incident to the security operations team for further analysis and to determine if the attack is part of a broader campaign.
-- Remove any unauthorized emond rules and restore legitimate configurations from a known good backup.
-- Implement enhanced logging policies to monitor emond activity and child processes, ensuring detailed logs are collected for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Apply security patches and updates to the macOS system to mitigate vulnerabilities that could be exploited by adversaries.
-- Educate users on recognizing and reporting suspicious activities, and consider implementing additional security measures such as application whitelisting and endpoint detection and response (EDR) solutions."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_enable_root_account.toml b/rules/macos/persistence_enable_root_account.toml
index 32b45bbca82..47a4bdcfee6 100644
--- a/rules/macos/persistence_enable_root_account.toml
+++ b/rules/macos/persistence_enable_root_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,48 +58,6 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:dsenableroot and not process.args:"-d"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Enable the Root Account
-
-In macOS environments, the root account is typically disabled to enhance security. However, adversaries may attempt to enable it using the `dsenableroot` command to gain persistent, privileged access. The detection rule identifies such attempts by monitoring process events for the execution of this command without the disable flag, signaling potential misuse for unauthorized access.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `dsenableroot` command execution without the `-d` flag, as indicated by the query fields `process.name:dsenableroot` and `not process.args:"-d"`.
-- Check the `event.category:process` and `event.type:(start or process_started)` fields to verify the process initiation and gather the exact timestamp of the event.
-- Identify the user account associated with the process execution by examining the `user.name` field to determine if it aligns with expected administrative activity.
-- Investigate the parent process of `dsenableroot` using the `process.parent.name` field to understand the context in which the command was executed.
-- Use Osquery to list all recent processes executed by the user identified in the alert. Example query: `SELECT * FROM processes WHERE user = '<username>' ORDER BY start_time DESC LIMIT 10;`.
-- Examine the system logs around the time of the event for any additional suspicious activity or related events that might indicate a broader attack pattern.
-- Check for any recent changes to user accounts or permissions on the system that could suggest unauthorized access attempts.
-- Investigate network connections from the host around the time of the event to identify any potential exfiltration or command-and-control activity.
-- Review any recent software installations or updates on the host that could have introduced vulnerabilities or been used as a vector for the attack.
-- Correlate this event with other alerts or logs from the same host or user to identify patterns or repeated attempts to enable the root account.
-
-### False positive analysis
-
-- System administrators or IT personnel may legitimately enable the root account for maintenance or troubleshooting purposes, leading to false positives. To manage this, users can create exceptions for known administrator accounts or specific maintenance windows.
-- Automated scripts or management tools that require root access for legitimate tasks might trigger the detection rule. Users should identify these scripts and whitelist them by process hash or specific command-line arguments.
-- In educational or testing environments, enabling the root account might be part of a controlled exercise. Users can exclude these environments from monitoring or adjust the rule to account for specific IP ranges or hostnames.
-- Some third-party applications may require root access for installation or updates, potentially causing false positives. Users should verify the legitimacy of these applications and consider excluding their associated processes from the rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the `dsenableroot` command execution by checking user activity logs and correlating with authorized change requests.
-- If unauthorized, terminate any suspicious processes and sessions associated with the root account to contain potential threats.
-- Conduct a thorough investigation to identify any additional compromised accounts or systems, focusing on persistence mechanisms and unauthorized access patterns.
-- Reset passwords for all accounts with elevated privileges, including the root account, and enforce strong password policies.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that all critical events are monitored and retained for future investigations.
-- Integrate with security information and event management (SIEM) systems to automate alerting and correlation of suspicious activities related to account misuse.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files and configurations.
-- Harden the system by disabling the root account if not needed, and implement multi-factor authentication for all administrative access to reduce the risk of unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
index 8f83dfb8538..0b84f1c374e 100644
--- a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
+++ b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -68,52 +68,6 @@ file where host.os.type == "macos" and event.type != "deletion" and
     "/Library/LaunchDaemons/.*.plist"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation of Hidden Launch Agent or Daemon
-
-Launch agents and daemons in macOS are background services that start at login or system boot, respectively. Adversaries exploit these to maintain persistence by creating hidden or unauthorized entries in system directories. The detection rule identifies suspicious creation events in key directories, flagging potential unauthorized persistence mechanisms by monitoring file creation activities in specific system paths.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path where the suspicious launch agent or daemon was created, focusing on the directories specified in the query.
-- Check the file creation timestamp to determine when the suspicious file was created and correlate this with any known user activity or system events.
-- Use Osquery to list all launch agents and daemons on the system to identify any other potentially unauthorized entries:
-  ```sql
-  SELECT * FROM launchd WHERE path LIKE '/Library/LaunchAgents/%' OR path LIKE '/Library/LaunchDaemons/%' OR path LIKE '/System/Library/LaunchAgents/%' OR path LIKE '/System/Library/LaunchDaemons/%' OR path LIKE '/Users/%/Library/LaunchAgents/%';
-  ```
-- Investigate the file owner and permissions of the suspicious file to determine if it was created by a legitimate user or process.
-- Examine the contents of the .plist file to understand what executable or script it is configured to run and assess its legitimacy.
-- Cross-reference the executable or script specified in the .plist file with known malicious signatures or behaviors.
-- Check system logs around the time of file creation for any unusual activity or errors that might provide additional context.
-- Investigate any network connections or external communications initiated by the system around the time of the file creation to identify potential command and control activity.
-- Review user accounts and recent logins on the system to identify any unauthorized access that might have led to the creation of the launch agent or daemon.
-- Consult threat intelligence sources to determine if the identified behavior or file matches any known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- System or application updates: During legitimate system or application updates, new launch agents or daemons may be created in the monitored directories. These updates are typically signed by trusted developers and can be verified through digital signatures.
-- User-installed applications: Some user-installed applications may create launch agents or daemons to provide background services or functionalities. Users should verify the legitimacy of these applications and consider excluding them if they are deemed safe.
-- Development tools: Developers may create launch agents or daemons as part of their development process. These can be excluded by identifying the developer's environment and ensuring it aligns with expected behavior.
-- Administrative scripts: IT administrators might deploy scripts that create or modify launch agents or daemons for system management purposes. These should be documented and excluded if they are part of routine administrative tasks.
-- To manage false positives, users can create exceptions for known and verified applications or processes by using digital signatures, file hashes, or specific file paths to exclude them from triggering alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or persistence.
-- Investigate the creation event by reviewing the file path, timestamp, and associated user account to determine if the creation was authorized.
-- Check for other signs of compromise, such as unusual network activity or unauthorized user accounts, to assess the scope of the intrusion.
-- Remove the unauthorized launch agent or daemon by deleting the suspicious plist file and any associated scripts or binaries.
-- Restore the system to a known good state using backups or system restore points if available and necessary.
-- Update macOS and all installed applications to the latest versions to patch any known vulnerabilities.
-- Implement logging policies to monitor file creation and modification events in critical directories, ensuring logs are retained for an appropriate period.
-- Integrate security solutions such as endpoint detection and response (EDR) tools to enhance visibility and detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent future incidents.
-- Escalate the incident to the appropriate internal or external teams if the scope of the attack is beyond initial containment efforts, or if it involves sensitive data or critical systems."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
index de1c824e1db..9d39f3a9d97 100644
--- a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
+++ b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -78,53 +78,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                  "/Library/Application Support/Checkpoint/Endpoint Security/AMFinderExtensions.app/Contents/MacOS/AMFinderExtensions",
                                                  "/Applications/pCloud Drive.app/Contents/MacOS/pCloud Drive")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Finder Sync Plugin Registered and Enabled
-
-Finder Sync plugins enhance macOS Finder by allowing third-party applications to modify its interface, providing additional functionality. However, adversaries can exploit this by registering malicious plugins to maintain persistence on a system. The detection rule identifies suspicious plugin registrations by monitoring the `pluginkit` process for unusual arguments and excluding known legitimate plugins and parent processes, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific Finder Sync plugin registration triggered the alert, focusing on the `process.args` field to identify the suspicious plugin.
-- Verify the legitimacy of the plugin by researching the plugin identifier found in the `process.args` field against known legitimate plugins and any available threat intelligence sources.
-- Examine the `process.parent.executable` and `process.Ext.effective_parent.executable` fields to identify the parent process that initiated the plugin registration, checking for any unusual or unexpected parent processes.
-- Use Osquery to list all currently registered Finder Sync plugins on the system to identify any other potentially malicious plugins:
-  ```sql
-  SELECT * FROM plist WHERE path = '/Library/Preferences/com.apple.finder.plist' AND key = 'NSExtension' AND value LIKE '%FinderSync%';
-  ```
-- Investigate the system for any recent changes or installations that could have introduced the suspicious plugin, focusing on recent application installations or updates.
-- Check system logs for any other unusual activity around the time the plugin was registered, such as other process executions or network connections.
-- Review user activity on the system to determine if any user actions could have inadvertently led to the plugin registration, such as downloading and installing new software.
-- Investigate the file path and contents of the suspicious plugin to determine its purpose and whether it contains any malicious code or payloads.
-- Cross-reference the system's installed applications and extensions with known software inventory to identify any unauthorized or unexpected software.
-- Consult with other security tools or logs, such as endpoint detection and response (EDR) solutions, to gather additional context on the system's activity and any potential indicators of compromise.
-
-### False positive analysis
-
-- Known false positives for the Finder Sync Plugin Registered and Enabled rule include legitimate applications that register Finder Sync plugins for enhancing their functionality, such as cloud storage services and productivity tools.
-- Applications like Google Drive, Microsoft OneDrive, Adobe Creative Cloud, and Box are known to register Finder Sync plugins, which can trigger the detection rule if not properly excluded.
-- Users can manage these false positives by adding exceptions for known legitimate plugins and their parent processes in the detection rule, ensuring that these applications do not trigger alerts.
-- Regularly update the list of excluded plugins and parent processes to include any new legitimate applications that may register Finder Sync plugins, reducing unnecessary alerts.
-- Monitor updates from trusted software vendors for any changes in their plugin registration processes, which may require adjustments to the exclusion list.
-- Consider the context of the detected activity, such as the source and behavior of the parent process, to differentiate between benign and potentially malicious plugin registrations.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Review the Finder Sync plugin registration logs to identify any unauthorized or suspicious plugins.
-- Terminate any suspicious processes related to the unauthorized Finder Sync plugins.
-- Remove any identified malicious Finder Sync plugins from the system.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
-- Restore any affected system files from a known good backup to ensure system integrity.
-- Implement logging policies to monitor pluginkit process activities and other critical system processes for future detection of similar threats.
-- Integrate security solutions with SIEM tools to enhance real-time monitoring and alerting capabilities.
-- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Apply system hardening measures, such as restricting Finder Sync plugin installations to trusted applications only, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_folder_action_scripts_runtime.toml b/rules/macos/persistence_folder_action_scripts_runtime.toml
index 1e79a7bf7c7..18b114cfaf4 100644
--- a/rules/macos/persistence_folder_action_scripts_runtime.toml
+++ b/rules/macos/persistence_folder_action_scripts_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -60,49 +60,6 @@ query = '''
 process where host.os.type == "macos" and event.type : "start" and process.name in ("osascript", "python", "tcl", "node", "perl", "ruby", "php", "bash", "csh", "zsh", "sh") and
   process.parent.name == "com.apple.foundation.UserScriptService" and not process.args : ("/Users/*/Library/Application Support/iTerm2/Scripts/AutoLaunch/*.scpt", "/Users/*/Library/Application Scripts/com.microsoft.*/FoxitUtils.applescript")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via Folder Action Script
-
-Folder Action scripts on macOS automate tasks when folder contents change. Adversaries exploit this by attaching malicious scripts to folders, ensuring execution upon folder events, thus achieving persistence. The detection rule identifies suspicious script executions by monitoring specific processes initiated by the UserScriptService, excluding known benign scripts, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the detection, focusing on the `process.name` and `process.args` fields.
-- Verify the parent process by examining the `process.parent.name` field to confirm it is `com.apple.foundation.UserScriptService`, which indicates a Folder Action script execution.
-- Check the user account associated with the process to determine if it aligns with expected user behavior or if it appears suspicious.
-- Investigate the script path and content by accessing the folder specified in the `process.args` to identify any unauthorized or malicious modifications.
-- Use Osquery to list all Folder Action scripts currently configured on the system with the following query: `SELECT * FROM file WHERE path LIKE '/Users/%/Library/Scripts/Folder Action Scripts/%';`
-- Cross-reference the detected script with known benign scripts to ensure it is not mistakenly flagged, using the exclusion paths provided in the detection rule.
-- Analyze recent changes to the folder associated with the script to identify any unusual activity or unauthorized access.
-- Review system logs for any additional context or related events around the time of the alert to identify potential patterns or repeated attempts.
-- Check for any other processes or network connections initiated by the suspicious script to assess further malicious activity.
-- Consult threat intelligence sources to determine if the script or its behavior matches known malicious patterns or campaigns.
-
-### False positive analysis
-
-- Known false positives for the Persistence via Folder Action Script rule include legitimate automation scripts that users have intentionally attached to folders for productivity purposes, such as scripts for organizing files or triggering backups.
-- Users may frequently encounter false positives from development environments where scripts are executed as part of the software development process, especially if using scripting languages like Python, Ruby, or Node.js.
-- To manage these false positives, users can create exceptions for specific scripts or folders by modifying the detection rule to exclude known benign scripts or directories, similar to the existing exclusions for iTerm2 and Microsoft-related scripts.
-- Users should regularly review and update their exclusion list to ensure that only trusted scripts are excluded, maintaining a balance between reducing false positives and ensuring security.
-- It is advisable to document any exclusions made for auditing purposes and to reassess them periodically to confirm they remain non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Investigate the specific Folder Action script that triggered the alert to determine if it is indeed malicious by analyzing its contents and behavior.
-- Review recent changes to the folder and associated scripts to identify unauthorized modifications or additions.
-- Remove or disable the malicious script from the Folder Action configuration to prevent further execution.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional threats.
-- Restore any modified or deleted legitimate scripts from a known good backup to ensure system functionality.
-- Escalate the incident to the security operations team if the script is part of a broader attack campaign or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed script execution events and folder modifications for future investigations.
-- Integrate with a centralized security information and event management (SIEM) system to correlate events and improve threat detection capabilities.
-- Apply hardening measures such as restricting script execution permissions, disabling unnecessary scripting languages, and educating users on the risks of unauthorized script usage."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_login_logout_hooks_defaults.toml b/rules/macos/persistence_login_logout_hooks_defaults.toml
index 7f1b0604854..b0ef9cdda7d 100644
--- a/rules/macos/persistence_login_logout_hooks_defaults.toml
+++ b/rules/macos/persistence_login_logout_hooks_defaults.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -68,49 +68,6 @@ process where host.os.type == "macos" and event.type == "start" and
          "/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh"
        )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via Login or Logout Hook
-
-In macOS environments, login and logout hooks are scripts that execute automatically during user login or logout, respectively. Adversaries exploit this by inserting malicious scripts to maintain persistence. The detection rule identifies suspicious use of the 'defaults' command to set these hooks, excluding known legitimate scripts, thus highlighting potential unauthorized persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'defaults' command with 'write' arguments targeting 'LoginHook' or 'LogoutHook', ensuring it matches the query criteria.
-- Check the process execution context, including the user account under which the 'defaults' command was executed, to determine if it aligns with expected administrative activity.
-- Investigate the parent process of the 'defaults' command to understand how it was initiated and whether it was part of a legitimate workflow or a suspicious chain of processes.
-- Examine the command line arguments used with the 'defaults' command to identify the specific script or executable being set as a login or logout hook.
-- Cross-reference the script paths against known legitimate scripts to verify if they are indeed unauthorized or potentially malicious.
-- Utilize Osquery to list all current login and logout hooks on the system with a query like: `SELECT * FROM preferences WHERE domain = 'com.apple.loginwindow' AND key IN ('LoginHook', 'LogoutHook');` to gather more context.
-- Analyze the content of the identified scripts or executables to determine their purpose and whether they contain any malicious or unexpected code.
-- Review system logs around the time of the 'defaults' command execution for any additional suspicious activity or related events that could provide further context.
-- Check for any recent changes to user accounts or permissions that might indicate an adversary's attempt to gain or maintain access.
-- Correlate this activity with other alerts or indicators of compromise within the environment to assess if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives for the Persistence via Login or Logout Hook rule primarily involve legitimate scripts used by system management tools like JAMF, which utilize login and logout hooks for administrative tasks.
-- Users can manage these false positives by creating exceptions for known legitimate scripts, such as those located in "/Library/Application Support/JAMF/ManagementFrameworkScripts/".
-- To handle frequent non-threatening behaviors, users should maintain an updated list of trusted scripts and directories that are commonly used in their environment, ensuring these are excluded from detection.
-- Regularly review and update the exclusion list to accommodate any changes in legitimate administrative scripts or tools, minimizing the risk of overlooking genuine threats while reducing false positives.
-- Collaborate with IT and security teams to identify and document any new legitimate scripts that may trigger the rule, ensuring they are promptly added to the exclusion list.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
-- Review the process execution logs to confirm the unauthorized use of the 'defaults' command and identify any associated scripts or payloads.
-- Terminate any suspicious processes that are linked to the unauthorized login or logout hooks to halt potential malicious actions.
-- Remove the unauthorized login or logout hooks by resetting them to their default state or replacing them with legitimate scripts if necessary.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
-- Review user accounts and privileges on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to improve detection of similar threats.
-- Apply system hardening measures, such as disabling unused services and enforcing strong authentication mechanisms, to reduce the attack surface and prevent future persistence attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
index 8189274e07f..4023d557e1d 100644
--- a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
+++ b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -70,49 +70,6 @@ file where host.os.type == "macos" and event.type in ("change", "creation") and
       "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper"
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Sublime Plugin or Application Script Modification
-
-Sublime Text, a popular text editor, supports plugins and scripts written in Python to enhance functionality. Adversaries may exploit this by altering or creating scripts to execute malicious code whenever Sublime is launched, achieving persistence. The detection rule identifies suspicious modifications to Python files in specific Sublime directories on macOS, excluding legitimate processes, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and event type (change or creation) that triggered the alert. Focus on the `file.path` and `event.type` fields for context.
-- Verify the legitimacy of the process that modified or created the Python file by checking the `process.executable` field against known benign executables.
-- Use Osquery to list all Python files in the specified Sublime directories to identify any unexpected or recently modified files. Example query: `SELECT path, mtime FROM file WHERE path LIKE '/Users/%/Library/Application Support/Sublime Text%/Packages/%.py' OR path = '/Applications/Sublime Text.app/Contents/MacOS/sublime.py';`
-- Check the modification timestamps of the identified files to correlate with the alert time and determine if the changes are recent and potentially suspicious.
-- Investigate the content of the modified or newly created Python files for any signs of obfuscation, unusual imports, or suspicious code that could indicate malicious intent.
-- Cross-reference the user account associated with the file modification to determine if the activity aligns with expected user behavior or if it could be indicative of compromised credentials.
-- Review system logs and other security alerts around the time of the file modification to identify any related suspicious activities or anomalies.
-- Check for any recent installations or updates of Sublime Text or its plugins that could explain the file changes as legitimate.
-- Investigate the network activity of the host around the time of the alert to identify any potential command and control communication or data exfiltration attempts.
-- Consult threat intelligence sources to determine if there are any known threats or campaigns targeting Sublime Text plugins or scripts that match the observed behavior.
-
-### False positive analysis
-
-- Frequent updates or installations of Sublime Text plugins by developers can trigger false positives, as these actions involve legitimate changes to Python files in the monitored directories.
-- Automated scripts or tools used by developers to manage Sublime Text configurations may also cause false positives by creating or modifying Python files as part of their normal operation.
-- Users can manage these false positives by creating exceptions for specific processes or paths known to be safe, such as trusted plugin management tools or scripts.
-- Excluding specific user accounts or directories that are known to frequently update or modify Sublime Text plugins can help reduce noise from legitimate activities.
-- Monitoring the frequency and context of file changes can help distinguish between normal development activities and potential threats, allowing for more informed decisions on exclusions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to identify any unauthorized modifications to Sublime Text plugins or scripts, focusing on the specified directories.
-- Review recent changes to the system, including new user accounts, scheduled tasks, or other persistence mechanisms that may have been established.
-- Restore any modified or malicious Python scripts to their original state using known good backups or reinstall the Sublime Text application if necessary.
-- Implement logging policies to capture detailed file modification events, especially in directories where Sublime Text plugins and scripts are stored.
-- Integrate security solutions with threat intelligence feeds to enhance detection capabilities for similar threats in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Review and update security policies to restrict unauthorized access to application directories and enforce the principle of least privilege.
-- Conduct a post-incident review to identify gaps in detection and response processes and implement improvements.
-- Educate users on the risks of downloading and installing unverified plugins or scripts to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
index fcfb541e95b..fda11158c76 100644
--- a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
+++ b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:"deletion" and
  file.path:(/private/etc/periodic/* or /private/etc/defaults/periodic.conf or /private/etc/periodic.conf)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Persistence via Periodic Tasks
-
-Periodic tasks in macOS are scheduled operations that automate system maintenance and other routine activities. Adversaries may exploit these tasks to execute unauthorized code or maintain persistence by altering task configurations. The detection rule identifies suspicious file events related to periodic task configurations, excluding deletions, to spot potential tampering indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path that triggered the alert, focusing on paths like `/private/etc/periodic/*`, `/private/etc/defaults/periodic.conf`, or `/private/etc/periodic.conf`.
-- Check the timestamp of the event to determine when the suspicious modification or creation occurred.
-- Investigate the user account associated with the event to determine if the activity aligns with expected behavior or if it might be indicative of unauthorized access.
-- Use Osquery to list all periodic tasks and their configurations to identify any unexpected or unauthorized entries. Example query: `SELECT * FROM file WHERE path LIKE '/private/etc/periodic/%' OR path = '/private/etc/defaults/periodic.conf' OR path = '/private/etc/periodic.conf';`
-- Examine the contents of the modified or newly created configuration files to identify any suspicious scripts or commands that could indicate malicious intent.
-- Cross-reference the event with other logs, such as authentication logs, to identify any unusual login activities around the time of the event.
-- Check for any recent changes in user privileges or group memberships that could have allowed unauthorized modifications to periodic task configurations.
-- Investigate any network connections or external communications initiated by the host around the time of the event to identify potential data exfiltration or command-and-control activity.
-- Review historical data to determine if similar modifications have occurred in the past, which could indicate a pattern of persistence attempts.
-- Consult threat intelligence sources to see if the identified modifications or scripts match known malicious activity or indicators of compromise.
-
-### False positive analysis
-
-- Routine system updates or legitimate software installations may modify periodic task configurations, leading to false positives. Users should verify if the changes coincide with known update schedules or software installations.
-- Administrative scripts or maintenance tools used by IT departments might alter periodic task settings as part of their normal operations. Users can create exceptions for these known scripts or tools to reduce noise.
-- Configuration management systems like Puppet or Chef may update periodic task configurations as part of their automated processes. Users should ensure these systems are accounted for in their monitoring rules.
-- Developers or system administrators might manually adjust periodic task settings for testing or optimization purposes. Users can maintain a whitelist of authorized personnel or processes that are allowed to make such changes.
-- Some third-party applications may legitimately modify periodic task configurations to schedule their own maintenance tasks. Users should review and approve these applications to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or execution of malicious code.
-- Conduct a thorough investigation of the modified or newly created periodic task configurations to identify any unauthorized changes or scripts.
-- Review system logs and use endpoint detection and response (EDR) tools to trace the origin of the changes and identify any associated malicious activity.
-- Restore the original periodic task configurations from a known good backup to ensure system integrity.
-- Scan the system for additional indicators of compromise (IOCs) and remove any detected malware or unauthorized files.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if assistance is needed.
-- Implement enhanced logging policies to capture detailed file modification events and periodic task executions for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
-- Apply security patches and updates to the macOS system to mitigate vulnerabilities that could be exploited by adversaries.
-- Harden the system by restricting access to configuration files, enforcing least privilege principles, and regularly auditing scheduled tasks for unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_suspicious_calendar_modification.toml b/rules/macos/persistence_suspicious_calendar_modification.toml
index c0a5d0bd774..d9e648f11f1 100644
--- a/rules/macos/persistence_suspicious_calendar_modification.toml
+++ b/rules/macos/persistence_suspicious_calendar_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -74,49 +74,6 @@ event.category:file and host.os.type:macos and event.action:modification and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Calendar File Modification
-
-Calendar files on macOS can be manipulated to trigger events, potentially allowing adversaries to execute malicious programs at set intervals, thus maintaining persistence. By monitoring file modifications in calendar directories, especially by non-standard processes, the detection rule identifies unusual activity. It excludes legitimate system processes, focusing on unexpected executables, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific calendar file was modified and by which process, focusing on the `file.path` and `process.executable` fields.
-- Verify the legitimacy of the process executable by checking its location and signature. Use the `process.executable` field to determine if the process is expected or potentially malicious.
-- Cross-reference the process executable with known good applications and system processes to rule out false positives.
-- Use Osquery to list all processes that have recently interacted with calendar files. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/Users/%/Library/Calendars/%.calendar/Events/%.ics';`
-- Investigate the parent process of the suspicious executable to understand how it was launched. This can provide insights into whether it was user-initiated or automated.
-- Check the modification timestamps of the calendar file to determine if the timing aligns with any known user activity or scheduled tasks.
-- Review system logs around the time of the modification for any additional context or related events, such as user logins or other file modifications.
-- Examine the contents of the modified calendar file to identify any unusual or unexpected entries that could indicate malicious intent.
-- Investigate the user account associated with the modified calendar file to determine if there are any signs of compromise or unusual activity.
-- Correlate the event with other alerts or logs from the same host to identify patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Known false positives may include legitimate third-party applications that interact with calendar files for synchronization or notification purposes, such as productivity tools or calendar management apps.
-- Users can handle these false positives by identifying and documenting the legitimate applications that modify calendar files regularly, then creating exceptions for these applications in the detection rule.
-- Another potential false positive source could be user-initiated scripts or automation tools that modify calendar events for personal scheduling needs. Users should verify the legitimacy of these scripts and exclude them if they are deemed non-threatening.
-- Regularly review and update the list of excluded processes to ensure that only trusted applications are allowed, minimizing the risk of overlooking a genuine threat.
-- Consider implementing a logging mechanism to track excluded processes, allowing for periodic audits and ensuring that no malicious activity is being inadvertently ignored.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the process responsible for the calendar file modification, using endpoint detection and response (EDR) tools to trace the process lineage and identify any associated malicious files or processes.
-- Terminate any suspicious processes identified during the investigation and remove any unauthorized calendar events or scripts that have been added to the system.
-- Restore any modified calendar files from a known good backup to ensure the integrity of the calendar data.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of a broader compromise or if the threat actor's identity and intent are unclear.
-- Implement enhanced logging policies to capture detailed process execution and file modification events, ensuring that future suspicious activities are detected promptly.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security monitoring tools to improve detection capabilities for similar persistence techniques.
-- Apply security patches and updates to the macOS system and all installed applications to mitigate vulnerabilities that could be exploited by adversaries.
-- Educate users on the risks of calendar file modifications and the importance of reporting unusual system behavior to IT security personnel.
-- Review and update security policies and hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and improve overall system resilience."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_via_atom_init_file_modification.toml b/rules/macos/persistence_via_atom_init_file_modification.toml
index 3939d5988e5..f281678818e 100644
--- a/rules/macos/persistence_via_atom_init_file_modification.toml
+++ b/rules/macos/persistence_via_atom_init_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:"deletion" and
  file.path:/Users/*/.atom/init.coffee and not process.name:(Atom or xpcproxy) and not user.name:root
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Persistence via Atom Init Script Modification
-
-Atom, a popular text editor, allows customization via the init.coffee script, which executes JavaScript upon startup. Adversaries exploit this by embedding malicious code, ensuring persistence each time Atom launches. The detection rule identifies suspicious modifications to this script on macOS, excluding legitimate processes and root user actions, to flag potential unauthorized changes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path involved is `/Users/*/.atom/init.coffee` and verify the user account associated with the modification.
-- Check the process that made the modification by examining the `process.name` field to ensure it is not `Atom` or `xpcproxy`.
-- Verify the user account involved in the modification by reviewing the `user.name` field to ensure it is not `root`.
-- Use Osquery to list recent modifications to the `init.coffee` file with a query like: `SELECT * FROM file WHERE path = '/Users/*/.atom/init.coffee' ORDER BY atime DESC LIMIT 5;`.
-- Investigate the contents of the `init.coffee` file to identify any suspicious or unfamiliar JavaScript code.
-- Cross-reference the modification timestamp with user activity logs to determine if the modification aligns with legitimate user actions.
-- Check for any other suspicious file modifications or creations in the `.atom` directory that may indicate further persistence mechanisms.
-- Review system logs for any unusual activity or errors around the time of the modification to gather additional context.
-- Investigate the network activity of the user account and the host around the time of the modification for any signs of data exfiltration or command and control communication.
-- Correlate the findings with other security alerts or incidents involving the same user or host to identify potential patterns or related threats.
-
-### False positive analysis
-
-- Legitimate user customizations: Users often modify the init.coffee script to personalize their Atom experience, such as adding plugins or custom functions. These changes can trigger the detection rule. To manage this, users can create exceptions for known user accounts or specific script changes that are verified as safe.
-- Development and testing activities: Developers may frequently update the init.coffee file during testing or development of Atom packages. These activities can be excluded by setting exceptions for specific development environments or user accounts involved in these tasks.
-- Automated configuration management: Some organizations use automated tools to manage and update configuration files, including init.coffee. If these tools are known and trusted, their processes can be whitelisted to prevent false positives.
-- System updates or software installations: Occasionally, system updates or new software installations might modify the init.coffee file as part of their setup process. Users can monitor these events and exclude them if they are confirmed to be part of legitimate update or installation procedures.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized changes in the init.coffee file and determine the scope of the compromise.
-- Review recent modifications to the init.coffee file and cross-reference with known malicious JavaScript patterns or signatures.
-- Restore the init.coffee file from a known good backup if available, or manually remove any unauthorized code to ensure the system's integrity.
-- Scan the system for additional indicators of compromise, such as other modified configuration files or unexpected processes, to ensure no other persistence mechanisms are in place.
-- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if the malicious code is part of a known threat campaign.
-- Implement enhanced logging policies to capture detailed file modification events and process execution details for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar persistence techniques.
-- Educate users on the risks of unauthorized script modifications and encourage reporting of suspicious activity to prevent future incidents.
-- Apply security hardening measures, such as restricting write permissions to critical configuration files and using application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
index 8ab2b0dd0d3..b47455ab7a1 100644
--- a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
+++ b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -62,47 +62,6 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
   not process.Ext.effective_parent.executable : ("/Applications/Visual Studio Code.app/Contents/MacOS/Electron",
                                                  "/Applications/OpenVPN Connect/Uninstall OpenVPN Connect.app/Contents/MacOS/uninstaller")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Apple Scripting Execution with Administrator Privileges
-
-AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries may exploit it to execute scripts with elevated privileges, bypassing password prompts. The detection rule identifies such misuse by monitoring the execution of the Apple script interpreter, excluding benign parent processes like Electron, to flag unauthorized privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `osascript` process execution with administrator privileges and without a password prompt.
-- Verify the `process.command_line` field to understand the exact command executed and assess if it aligns with known malicious patterns or scripts.
-- Check the `process.parent.name` field to identify the parent process of `osascript` and ensure it is not a benign process like Electron.
-- Investigate the `process.Ext.effective_parent.executable` field to confirm the parent executable is not a known safe application such as Visual Studio Code or OpenVPN Connect.
-- Use Osquery to list recent processes executed by the same user to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE user = (SELECT user FROM processes WHERE name = 'osascript' LIMIT 1);`
-- Examine system logs for any other unusual activities or errors around the time of the `osascript` execution to gather additional context.
-- Check for any recent changes in user accounts or permissions that could indicate unauthorized privilege escalation attempts.
-- Investigate network connections initiated by the system around the time of the alert to identify any potential data exfiltration or command and control activities.
-- Review the system's installed applications and scripts to identify any unauthorized or suspicious software that could have triggered the `osascript` execution.
-- Correlate the findings with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives for the Apple Scripting Execution with Administrator Privileges rule may include legitimate applications that use AppleScript for automation purposes without malicious intent. Applications like Visual Studio Code and OpenVPN Connect have been identified as benign processes that may trigger this rule due to their use of Electron as a parent process.
-- Users can manage these false positives by creating exceptions for specific applications that are known to use AppleScript legitimately. This can be done by excluding the parent processes or executables of these applications in the detection rule, as demonstrated with the exclusion of Electron and specific paths for Visual Studio Code and OpenVPN Connect.
-- It is important to regularly review and update the list of exceptions to ensure that only trusted applications are excluded, minimizing the risk of overlooking genuine threats while reducing noise from false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the osascript execution by checking user activity logs and correlating with known user behavior.
-- Terminate any suspicious processes related to osascript that are running with elevated privileges without a password prompt.
-- Conduct a thorough investigation to identify how the script was executed with elevated privileges, focusing on potential vulnerabilities or misconfigurations.
-- Review and update user account permissions to ensure that only authorized personnel have the ability to execute scripts with administrator privileges.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to monitor and alert on suspicious script executions in real-time.
-- Restore the system to its operational state by applying necessary patches, updating software, and ensuring all security configurations are correctly set.
-- Educate users on the risks associated with script execution and the importance of adhering to security policies.
-- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further analysis and support."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
index 227b1445fa9..b05b7f04238 100644
--- a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
+++ b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -64,49 +64,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.name:"security_authtrampoline" and
  process.parent.name:(osascript or com.apple.automator.runner or sh or bash or dash or zsh or python* or Python or perl* or php* or ruby or pwsh)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution with Explicit Credentials via Scripting
-
-In macOS environments, the `security_authtrampoline` process is used to execute programs with elevated privileges via the Security framework. Adversaries may exploit this by using scripting interpreters to run unauthorized commands with root access, bypassing standard security measures. The detection rule identifies such abuse by monitoring the initiation of `security_authtrampoline` through common scripting languages, flagging potential misuse of explicit credentials for privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `security_authtrampoline` process execution and identify the parent scripting interpreter from the `process.parent.name` field.
-- Cross-reference the `event.category:process` and `event.type:(start or process_started)` fields to verify the timing and frequency of the suspicious process execution.
-- Examine the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential misuse of credentials.
-- Investigate the command line arguments used in the process execution to identify any unusual or unauthorized commands being executed with elevated privileges.
-- Utilize Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'security_authtrampoline';` to retrieve detailed information about the process, including its PID, parent PID, and execution path.
-- Check system logs for any related authentication events or anomalies around the time of the alert to identify potential unauthorized access attempts.
-- Analyze the network activity associated with the process to detect any suspicious outbound connections or data exfiltration attempts.
-- Review recent changes to the system, such as new software installations or script modifications, that could explain the unexpected use of `security_authtrampoline`.
-- Correlate the alert with other security events or alerts in the environment to identify patterns or coordinated activities that may indicate a broader attack.
-- Consult threat intelligence sources to determine if there are known campaigns or threat actors that commonly exploit `security_authtrampoline` for privilege escalation on macOS systems.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use scripting languages to perform routine maintenance or configuration tasks that require elevated privileges, leading to benign instances of `security_authtrampoline` execution. Users can create exceptions for known scripts or processes that are part of regular administrative workflows.
-- Automated scripts and tools: Some automated tools or scripts, such as those used for software deployment or system monitoring, might invoke `security_authtrampoline` as part of their normal operation. Users should identify these tools and whitelist them to prevent unnecessary alerts.
-- Development and testing environments: Developers might execute scripts that trigger `security_authtrampoline` during the development or testing of applications that require elevated privileges. In such cases, users can exclude specific development environments or user accounts from monitoring to reduce false positives.
-- Security software: Certain security applications may use scripting interpreters to perform legitimate security checks or updates that involve `security_authtrampoline`. Users should verify the legitimacy of these applications and consider excluding them from detection rules.
-- User-initiated actions: Advanced users or IT personnel might manually run scripts for troubleshooting or system management purposes. Organizations can implement a process to log and review these actions, allowing for the exclusion of verified user-initiated scripts from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the unauthorized script execution, focusing on recent changes or suspicious activities in user accounts and installed applications.
-- Terminate any unauthorized processes associated with the `security_authtrampoline` and any parent scripting interpreters identified in the alert.
-- Review and revoke any compromised credentials or accounts, ensuring that all passwords are reset and multi-factor authentication is enforced.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships, to aid in future investigations.
-- Integrate endpoint detection and response (EDR) solutions to monitor for similar suspicious activities and provide real-time alerts.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a known good backup, ensuring all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as disabling unnecessary scripting interpreters, restricting the use of `AuthorizationExecuteWithPrivileges`, and enforcing least privilege principles across all user accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
index 15886ce475a..2fbd033a24f 100644
--- a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
+++ b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -73,51 +73,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
                            /usr/sbin/installer or
                            /usr/bin/csrutil)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Child Process of Adobe Acrobat Reader Update Service
-
-Adobe Acrobat Reader's update service uses a privileged helper tool to manage updates on macOS, running with elevated permissions. Adversaries may exploit vulnerabilities in this service to escalate privileges by executing unauthorized processes as the root user. The detection rule identifies unusual child processes spawned by the update service, excluding known legitimate executables, to flag potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and executable path that triggered the alert, ensuring it matches the criteria specified in the detection rule.
-- Verify the parent process name is `com.adobe.ARMDC.SMJobBlessHelper` and the user context is `root` to confirm the alert's legitimacy.
-- Check the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
-- Use Osquery to list all child processes spawned by `com.adobe.ARMDC.SMJobBlessHelper` to identify any other potentially unauthorized processes:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'com.adobe.ARMDC.SMJobBlessHelper');
-  ```
-- Investigate the command line arguments of the suspicious process to understand its intended actions and potential impact.
-- Cross-reference the suspicious process's executable path with known legitimate software paths to rule out false positives.
-- Examine system logs for any unusual activity around the time the suspicious process was executed, focusing on authentication and system modification logs.
-- Check for any recent installations or updates of Adobe Acrobat Reader that might have introduced vulnerabilities or been exploited.
-- Investigate the network activity of the suspicious process to identify any external communications that could indicate data exfiltration or command-and-control activity.
-- Review the system's patch status to ensure it is up-to-date with security patches, particularly those addressing CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613.
-
-### False positive analysis
-
-- Known false positives may include legitimate administrative scripts or tools that are executed by the root user but are not part of the predefined list of allowed executables. These could be custom scripts or third-party management tools that are not typically associated with malicious activity.
-- Users can handle these false positives by reviewing the flagged processes to determine if they are part of regular administrative tasks or maintenance activities. If confirmed as non-threatening, these processes can be added to an exclusion list to prevent future alerts.
-- Another potential false positive scenario involves software updates or installations that utilize temporary or dynamically generated paths not covered by the existing exclusion list. Users should verify the legitimacy of these processes and consider updating the exclusion list to include these paths if they are deemed safe.
-- It is important to regularly review and update the exclusion list to reflect changes in legitimate software behavior or new administrative tools that may be introduced into the environment, ensuring that only genuine threats are flagged by the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the alert by reviewing process execution logs and identifying any unauthorized child processes spawned by the Adobe Acrobat Reader update service.
-- Verify the system's patch status and ensure that it is updated with the latest security patches, specifically addressing CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613.
-- Terminate any suspicious processes identified during the investigation that are not part of the legitimate update service operations.
-- Restore the system to a known good state using backups or system restore points if available and ensure that all security patches are applied.
-- Implement enhanced logging policies to capture detailed process execution data and user activity, focusing on privileged operations and service executions.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to provide real-time monitoring and automated response capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future exploitation attempts.
-- Implement hardening measures such as restricting the execution of unnecessary privileged services, enforcing the principle of least privilege, and regularly auditing privileged accounts and services."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_local_user_added_to_admin.toml b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
index 460a6377fb3..8e00d539268 100644
--- a/rules/macos/privilege_escalation_local_user_added_to_admin.toml
+++ b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -62,48 +62,6 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
                                                 "/opt/jc/bin/jumpcloud-agent" or
                                                 "/Library/Addigy/go-agent")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Admin Group Account Addition
-
-In macOS environments, tools like `dscl` and `dseditgroup` manage user group memberships, including admin groups. Adversaries may exploit these tools to escalate privileges by adding accounts to admin groups via command-line operations. The detection rule identifies such attempts by monitoring process activities related to these tools, excluding legitimate management services, to flag unauthorized privilege escalation efforts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `dscl` or `dseditgroup` in the `process.name` field and verify the command-line arguments in `process.args` to ensure they include "/Groups/admin" and "-a" or "-append".
-- Check the `event.category` and `event.type` fields to confirm the event is related to a process start on a macOS host.
-- Examine the `process.Ext.effective_parent.executable` field to ensure the process was not initiated by a legitimate management service like JAMF or JumpCloud.
-- Investigate the user account associated with the process to determine if it has a history of administrative actions or if it is a new or unexpected account.
-- Use Osquery to list current admin group members and identify any recent changes. Example query: `SELECT * FROM groups WHERE groupname = 'admin';`
-- Cross-reference the timestamp of the alert with system logs to identify any concurrent suspicious activities or anomalies.
-- Analyze the parent process of the flagged activity to understand the context in which the `dscl` or `dseditgroup` command was executed.
-- Review recent login events on the host to identify any unusual or unauthorized access attempts around the time of the alert.
-- Check for any other alerts or indicators of compromise on the same host that might suggest a broader attack or compromise.
-- Consult with the user or system owner to verify if the action was legitimate or if they have any knowledge of the activity.
-
-### False positive analysis
-
-- Legitimate administrative tools and services, such as JAMF and JumpCloud, may trigger this rule when performing authorized group management tasks. These tools are often used by IT departments for device management and may add accounts to admin groups as part of their normal operations.
-- To manage these false positives, users can create exceptions for known legitimate processes by excluding their executable paths in the detection rule. This can be done by adding the paths of trusted management services to the exclusion list, ensuring that only unauthorized attempts are flagged.
-- Regularly review and update the exclusion list to include any new legitimate management tools that may be introduced into the environment, ensuring that the detection rule remains effective without generating unnecessary alerts.
-- Consider implementing additional context checks, such as verifying the user context or correlating with other security events, to further reduce false positives and enhance the accuracy of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
-- Verify the account added to the admin group and determine if it is legitimate or unauthorized by cross-referencing with user management records.
-- Review system logs and security alerts to identify any other suspicious activities or related incidents that may indicate a broader compromise.
-- Remove the unauthorized account from the admin group and reset its credentials to prevent further misuse.
-- Conduct a thorough investigation to determine how the unauthorized account addition occurred, focusing on potential vulnerabilities or misconfigurations.
-- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization.
-- Implement enhanced logging and monitoring policies to capture detailed process activities and user actions, ensuring better visibility for future investigations.
-- Integrate security tools and solutions, such as SIEM and EDR, to automate detection and response to similar threats in the future.
-- Restore the system to its operational state by applying necessary patches, updates, and security configurations to prevent recurrence.
-- Harden the system by enforcing least privilege principles, regularly reviewing user group memberships, and conducting security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_root_crontab_filemod.toml b/rules/macos/privilege_escalation_root_crontab_filemod.toml
index 34e3b36ef7f..3e51714cdd2 100644
--- a/rules/macos/privilege_escalation_root_crontab_filemod.toml
+++ b/rules/macos/privilege_escalation_root_crontab_filemod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:deletion and
  file.path:/private/var/at/tabs/root and not process.executable:/usr/bin/crontab
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privilege Escalation via Root Crontab File Modification
-
-Crontab files in macOS are used to schedule tasks, often requiring elevated privileges for execution. Adversaries may exploit this by modifying the root crontab file to execute malicious code with root privileges. The detection rule identifies unauthorized changes to this file, excluding legitimate crontab processes, to flag potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event category is 'file' and the host operating system type is 'macos', ensuring the alert is relevant to the environment.
-- Verify the file path involved in the alert is '/private/var/at/tabs/root', which indicates a modification to the root crontab file.
-- Check the process executable path to ensure it is not '/usr/bin/crontab', as legitimate crontab modifications should originate from this executable.
-- Use Osquery to list all current scheduled tasks and jobs on the affected macOS system to identify any unauthorized or suspicious entries. Example query: `SELECT * FROM crontab WHERE path = '/private/var/at/tabs/root';`
-- Investigate the user account associated with the process that modified the root crontab file to determine if it has legitimate access or if it might be compromised.
-- Examine the timestamp of the modification event to correlate with other system activities or alerts that occurred around the same time.
-- Review system logs for any unusual or unauthorized login attempts or privilege escalation activities preceding the crontab modification.
-- Analyze the contents of the modified root crontab file to identify any suspicious or unexpected scheduled tasks that could indicate malicious intent.
-- Cross-reference the modification event with known MITRE ATT&CK techniques, specifically focusing on Privilege Escalation (TA0004) and Scheduled Task/Job (T1053), to understand potential adversary behavior.
-- Consult threat intelligence sources to determine if there are any known campaigns or malware that exploit root crontab modifications on macOS systems.
-
-### False positive analysis
-
-- System administrators may legitimately modify the root crontab file for maintenance tasks or scheduled updates, which could trigger the detection rule. To manage this, users can create exceptions for known administrator accounts or specific maintenance scripts.
-- Automated system management tools or software updates might alter the root crontab file as part of their normal operation. Users should identify these tools and add them to an exclusion list to prevent false alerts.
-- Backup or monitoring software that checks or modifies crontab entries for integrity purposes could also be flagged. Users can exclude these processes by specifying their executable paths in the detection rule.
-- In development environments, developers might test scheduled tasks using the root crontab, leading to false positives. Users can handle this by setting up a separate detection rule for development environments with relaxed criteria.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the integrity of the root crontab file by comparing it with a known good backup or baseline configuration.
-- Investigate the source of the modification by reviewing logs for any suspicious activity around the time of the change, focusing on unauthorized access attempts or unusual process executions.
-- Identify and terminate any malicious processes that may have been initiated through the modified crontab entry.
-- Restore the root crontab file to its original state using a backup or by manually removing unauthorized entries.
-- Conduct a thorough scan of the system for additional signs of compromise, such as unauthorized user accounts or unexpected changes to critical system files.
-- Escalate the incident to the security operations team for further analysis and to determine if other systems may be affected.
-- Implement enhanced logging policies to capture detailed information on file modifications and process executions, particularly for privileged files and directories.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate events and improve detection capabilities for similar threats in the future.
-- Apply system hardening measures, such as restricting write permissions to critical files and directories, and regularly auditing user privileges to minimize the risk of privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
index 65f85640ebe..debaac79b06 100644
--- a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -79,50 +79,6 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 DNS Tunneling
-DNS tunneling exploits the DNS protocol to covertly transmit data between a compromised system and an attacker-controlled server. Adversaries may use it for stealthy command-and-control or data exfiltration by embedding data within DNS queries. The 'DNS Tunneling' detection rule leverages machine learning to identify anomalies, such as an unusually high volume of DNS queries to a single domain, indicative of potential tunneling activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific domain involved in the unusually high volume of DNS queries. Note the domain name and the number of queries.
-- Check the source IP address or host that generated the DNS queries to determine if it is a known or trusted device within the network.
-- Analyze historical DNS logs to identify patterns or trends in DNS query activity from the source IP address. Look for any other unusual or repetitive query patterns.
-- Use network traffic analysis tools to capture and inspect DNS traffic from the source IP address. Look for any encoded data or unusual payloads within the DNS queries.
-- Investigate the domain involved in the alert using threat intelligence sources to determine if it is associated with known malicious activity or DNS tunneling tools.
-- Utilize Osquery to gather additional context from the affected host. For example, run the following Osquery query to list recent DNS queries made by the host:
-  ```sql
-  SELECT name, count FROM dns_cache WHERE name LIKE '%.<suspicious_domain>';
-  ```
-- Check for any running processes on the affected host that may be associated with DNS tunneling tools, such as dnscat or Iodine.
-- Review system logs and security events on the affected host for any signs of compromise or unusual activity around the time of the DNS queries.
-- Correlate the DNS tunneling alert with other security alerts or incidents to determine if it is part of a larger attack campaign or if other systems are affected.
-- Consult with other teams, such as threat intelligence or incident response, to gather additional insights or context about the potential threat and its implications.
-
-### False positive analysis
-
-- High volumes of DNS queries to legitimate content delivery networks (CDNs) or cloud service providers can trigger false positives, as these services often use DNS for load balancing and redundancy. Users can mitigate this by creating exceptions for known CDN or cloud service domains.
-- Internal applications that rely heavily on DNS for service discovery or configuration management might generate a large number of DNS queries, which could be mistaken for tunneling activity. Users should identify and whitelist these internal domains to prevent false alerts.
-- Automated security tools or network monitoring solutions that perform frequent DNS lookups for threat intelligence or domain reputation checks may also cause false positives. Users can exclude these tools' DNS queries from the detection rule to reduce noise.
-- Some legitimate software updates or patch management systems may use DNS queries to check for updates, leading to a high volume of DNS traffic. Users should identify these systems and add them to an exception list to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration or command-and-control communication.
-- Conduct a thorough investigation of DNS logs to identify the scope of the tunneling activity and determine which domains were queried excessively.
-- Analyze network traffic to identify any additional compromised systems or unusual patterns that may indicate further tunneling or malicious activity.
-- Remove any malicious software or scripts identified during the investigation from the affected system.
-- Change all credentials and access tokens that may have been exposed or compromised during the tunneling activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are at risk.
-- Implement enhanced DNS logging and monitoring to detect future tunneling attempts, including setting up alerts for high volumes of DNS queries to single domains.
-- Integrate threat intelligence feeds to enrich DNS query data and improve detection of known malicious domains.
-- Restore the affected system to its operational state by applying necessary patches and updates, and ensure all security controls are re-enabled.
-- Harden the network by implementing DNS filtering, restricting outbound DNS traffic to known and trusted servers, and regularly reviewing firewall and proxy configurations."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
index 012480dc85e..57cef36eac2 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -82,48 +82,6 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual DNS Activity
-DNS, a cornerstone of internet functionality, translates domain names into IP addresses. Adversaries exploit DNS by using rare domains for malicious activities like command-and-control or data exfiltration. The 'Unusual DNS Activity' detection rule leverages machine learning to identify atypical DNS queries, signaling potential threats such as phishing or malware communication, by flagging uncommon domain interactions.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific uncommon domain that triggered the alert and the associated timestamp.
-- Cross-reference the uncommon domain with threat intelligence sources to determine if it is associated with known malicious activity.
-- Analyze DNS logs to identify the source IP address of the device making the unusual DNS query and any other domains it has queried recently.
-- Investigate the user or system associated with the source IP address to determine if there are any signs of compromise or unusual behavior.
-- Use Osquery to gather additional context from the affected system. For example, run the following query to list recent DNS queries made by the system: `SELECT name, time FROM dns_resolvers WHERE time > strftime('%s', 'now', '-1 day');`
-- Check network traffic logs for any outbound connections to the uncommon domain and assess the volume and frequency of these connections.
-- Examine endpoint security logs for any alerts or detections that coincide with the timestamp of the unusual DNS activity.
-- Investigate any recent changes or installations on the affected system that could be related to the unusual DNS activity.
-- Review email logs for any phishing attempts or suspicious emails received by the user associated with the alert.
-- Consult with other security team members or departments to gather additional insights or context regarding the unusual DNS activity.
-
-### False positive analysis
-
-- Legitimate software updates or cloud services may trigger the Unusual DNS Activity rule if they use uncommon domains for content delivery or API calls. Users can manage these by identifying and whitelisting known update servers or cloud service domains.
-- Internal development or testing environments might use non-standard domains that appear unusual. To handle these, users should document and exclude these domains from the detection rule to prevent false alerts.
-- Third-party applications or services that rely on dynamic or ephemeral domains for functionality can be mistaken for malicious activity. Users should maintain a list of trusted applications and their associated domains to exclude them from triggering the rule.
-- Some organizations use custom DNS configurations or private domains that may not be widely recognized. Users should ensure these are accounted for in the detection rule settings to avoid false positives.
-- Temporary spikes in DNS queries due to legitimate business activities, such as marketing campaigns or product launches, can be misinterpreted as unusual activity. Users should monitor and adjust the rule thresholds during such events to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further communication with the malicious domain.
-- Conduct a thorough investigation to identify the scope of the compromise, including checking for other systems that may have communicated with the same domain.
-- Analyze DNS logs and network traffic to identify any additional indicators of compromise (IOCs) related to the unusual DNS activity.
-- Remove any identified malware or unauthorized software from the affected system using antivirus or endpoint detection and response (EDR) tools.
-- Change passwords and credentials that may have been exposed or used on the compromised system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Implement or enhance DNS logging and monitoring to detect future unusual DNS activities more effectively.
-- Integrate threat intelligence feeds to enrich DNS data and improve detection capabilities for known malicious domains.
-- Restore the system to its operational state by applying necessary patches and updates, and verify that all security controls are functioning correctly.
-- Harden the system by implementing security best practices, such as disabling unnecessary services, applying least privilege principles, and ensuring regular security training for users."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
index 3ef1ae396c5..7e7f50eccfe 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -85,49 +85,6 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Web Request
-The 'Unusual Web Request' detection leverages machine learning to identify rare URLs that deviate from normal web activity, potentially signaling malicious actions like initial access or data exfiltration. Adversaries exploit trusted sites by embedding uncommon URLs to deliver payloads or establish command-and-control channels. This rule detects anomalies by flagging atypical URL requests, aiding in early threat identification.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific unusual URL and the associated host or IP address that made the request.
-- Check historical logs to determine if the unusual URL has been accessed previously and identify any patterns or trends in access times.
-- Correlate the unusual URL with known threat intelligence sources to determine if it is associated with any known malicious activity or campaigns.
-- Analyze the user agent string and other HTTP headers in the request to identify any anomalies or indicators of automated tools or scripts.
-- Investigate the source IP address to determine its geolocation and check if it is associated with any known malicious activity or blacklists.
-- Use Osquery to gather additional context from the affected host. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<source IP>';`
-- Examine DNS logs to see if there are any other unusual domain resolutions around the same time as the alert.
-- Check for any related alerts or events in the same timeframe that might indicate a broader attack or compromise.
-- Review endpoint security logs on the affected host to identify any suspicious processes or file modifications that coincide with the unusual web request.
-- Consult with the user or system owner to verify if the unusual URL request was legitimate or if they noticed any unusual behavior on their system.
-
-### False positive analysis
-
-- Known false positives for the Unusual Web Request rule can include legitimate business applications or services that use uncommon URLs for regular operations, such as software updates or API calls.
-- Web crawlers and bots that are part of normal internet traffic may trigger alerts due to their access patterns, which can appear as unusual but are non-threatening.
-- Internal development or testing environments might generate rare URL requests that are benign but flagged by the detection system.
-- To manage these false positives, users can create exceptions for specific URLs or domains that are verified as safe and part of routine operations.
-- Implementing a whitelist for known and trusted services that frequently generate uncommon URLs can help reduce unnecessary alerts.
-- Regularly reviewing and updating the list of exceptions based on changes in business processes or new legitimate services can maintain the effectiveness of the detection system while minimizing false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further communication with potentially malicious URLs.
-- Conduct a thorough investigation of the unusual URL request to determine if it is part of a known attack pattern, referencing MITRE ATT&CK techniques such as T1071 for context.
-- Analyze network traffic logs and web server logs to identify any additional suspicious activity or related requests.
-- Remove any identified malware or unauthorized software from the affected system using updated antivirus or endpoint detection and response tools.
-- Restore the system from a clean backup if malware removal is not feasible or if the system's integrity is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a targeted attack or data exfiltration attempt.
-- Implement enhanced logging policies to capture detailed web request data, including URL parameters and referrer information, for future investigations.
-- Integrate threat intelligence feeds and anomaly detection systems to improve the detection of unusual web requests and related threats.
-- Conduct a security review of web server configurations and apply hardening measures, such as disabling unnecessary services and applying the latest security patches.
-- Educate users on recognizing phishing attempts and suspicious URLs to reduce the risk of initial access through social engineering tactics."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
index d80646fb4e6..92fe092fe32 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -83,48 +83,6 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Web User Agent
-User agents identify applications making web requests, typically browsers. However, adversaries may exploit this by using non-standard user agents for malicious activities like persistence or data exfiltration. The 'Unusual Web User Agent' detection rule leverages machine learning to identify rare user agents, flagging potential threats from unexpected processes, thus aiding in uncovering malicious web activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific unusual user agent string and the process associated with it.
-- Check the source and destination IP addresses involved in the alert to determine if the traffic is internal or external.
-- Investigate the process that generated the unusual user agent by examining process creation logs and command-line arguments.
-- Use Osquery to gather more information about the process. Example query: `SELECT name, path, cmdline, pid FROM processes WHERE name = '<process_name>';`
-- Analyze network traffic logs to identify any patterns or anomalies associated with the unusual user agent, such as repeated access to specific domains or IPs.
-- Cross-reference the unusual user agent with known malicious user agents or those associated with legitimate applications to assess potential threats.
-- Check for any recent changes or updates on the system that might have introduced new software or scripts using the unusual user agent.
-- Investigate any related alerts or logs that might provide additional context, such as failed login attempts or other suspicious activities around the same time.
-- Consult threat intelligence sources to determine if the unusual user agent has been reported in recent attacks or campaigns.
-- Document findings and gather evidence to support further analysis or escalation if the unusual user agent is deemed suspicious or malicious.
-
-### False positive analysis
-
-- Uncommon user agents from legitimate applications such as weather monitoring or stock-trading programs can trigger false positives. Users should identify these applications and create exceptions to prevent unnecessary alerts.
-- Automated tools like web scrapers, bots, or scanners that are part of regular internet traffic may be flagged. Regularly review and whitelist known benign sources to reduce noise.
-- Internal network monitoring tools or scripts that use custom user agents for legitimate purposes might be detected. Ensure these are documented and excluded from the detection rule.
-- Software updates or patches that temporarily use unusual user agents can cause alerts. Monitor update schedules and adjust detection parameters accordingly.
-- Development or testing environments where custom user agents are used for simulation purposes may trigger false positives. Implement environment-specific exceptions to manage these alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further data exfiltration or command-and-control communication.
-- Conduct a thorough investigation to identify the process using the unusual user agent and determine if it is malicious or benign.
-- Review system and network logs to trace the origin and scope of the activity, focusing on any connections to known malicious IP addresses or domains.
-- If malware is detected, remove it using updated antivirus or anti-malware tools and ensure the system is clean.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed as malicious or if it involves sensitive data.
-- Implement enhanced logging policies to capture detailed user agent strings and associated process information for future analysis.
-- Integrate threat intelligence feeds to correlate unusual user agents with known threat actor tools and techniques.
-- Restore the system to its operational state by applying necessary patches, updates, and verifying system integrity.
-- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures accordingly.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring all software is up to date."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
index a28de000b37..7c9569ca0b5 100644
--- a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
+++ b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -98,49 +98,6 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Logon Events
-
-The detection of a spike in logon events leverages machine learning to identify anomalies in authentication patterns, which may indicate malicious activities like password spraying or brute force attacks. Adversaries exploit these methods to gain unauthorized access by overwhelming systems with login attempts. The detection rule monitors for unusual surges in successful logins, aligning with MITRE ATT&CK's Credential Access tactics, to alert analysts of potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the scope of the spike, including the time frame and the number of logon events compared to the baseline.
-- Identify the user accounts involved in the spike and check for any patterns, such as repeated attempts from the same account or a group of accounts.
-- Analyze the source IP addresses associated with the logon events to determine if they originate from unusual or suspicious locations.
-- Cross-reference the source IP addresses with threat intelligence feeds to check for any known malicious activity.
-- Use Osquery to gather additional context on the affected systems. For example, run the following query to list recent logon events on a specific host: `SELECT * FROM users WHERE last_login > (SELECT MAX(last_login) - 86400 FROM users);`
-- Check for any recent changes in user account permissions or group memberships that could indicate unauthorized access.
-- Investigate any failed logon attempts that occurred around the same time as the spike in successful logons to identify potential brute force activity.
-- Review system and application logs for any other suspicious activities or anomalies that coincide with the spike in logon events.
-- Examine any recent changes in network configurations or security policies that might have inadvertently allowed the spike in logon events.
-- Collaborate with other teams, such as network or application security, to gather additional insights or context that might explain the spike in logon events.
-
-### False positive analysis
-
-- High-volume legitimate logins from automated processes or scripts can trigger false positives. These should be identified and excluded by creating exceptions for known IP addresses or service accounts.
-- Scheduled tasks or batch jobs that require frequent authentication may cause spikes in logon events. Analysts can manage these by setting up rules to ignore logins from specific systems or during certain time windows.
-- User behavior during events like company-wide password resets or system maintenance can lead to increased logon activity. To handle this, temporary exceptions can be applied during these periods to prevent false alerts.
-- Integration with third-party applications that authenticate using the same credentials might result in a surge of logon events. Users should whitelist these applications to avoid unnecessary alerts.
-- Employees accessing systems from multiple devices or locations, especially in remote work scenarios, can cause spikes. Implementing geolocation-based exclusions or device recognition can help mitigate these false positives.
-
-### Response and remediation
-
-- Immediately isolate affected accounts by disabling them to prevent further unauthorized access.
-- Conduct a thorough investigation of the spike in logon events to identify the source and scope of the attack, focusing on logs and authentication attempts.
-- Reset passwords for compromised accounts and enforce strong password policies to mitigate the risk of future brute force attacks.
-- Review and enhance logging policies to ensure comprehensive capture of authentication events, including failed login attempts and account lockouts.
-- Implement multi-factor authentication (MFA) for all users to add an additional layer of security against unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Integrate threat intelligence feeds to correlate detected anomalies with known threat actors and tactics, techniques, and procedures (TTPs).
-- Restore affected systems to their operational state by applying necessary patches and updates, and verify system integrity.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users on recognizing phishing attempts and the importance of secure password practices to reduce the likelihood of credential compromise."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
index f0d079bcdc7..25165dddda5 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -84,49 +84,6 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux Process Calling the Metadata Service
-
-In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries exploit this by using atypical processes to access metadata, aiming to extract sensitive information like credentials. The detection rule identifies anomalies by monitoring unexpected process interactions with the metadata service, flagging potential credential access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and user account involved in the unusual access to the metadata service.
-- Check the process command line and arguments to understand the intent and context of the process execution.
-- Investigate the parent process to determine if the process was spawned by a legitimate or suspicious application.
-- Use Osquery to gather additional context about the process. Example query: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<suspicious_process_name>';`
-- Examine the process execution history on the host to identify any patterns or anomalies in its behavior.
-- Analyze the network connections established by the process to verify if it accessed the metadata service endpoint.
-- Review system logs for any related authentication attempts or access logs that might indicate unauthorized access.
-- Correlate the process activity with other security events or alerts to identify potential lateral movement or privilege escalation.
-- Investigate the user account associated with the process for any signs of compromise or unusual activity.
-- Check for any recent changes or deployments on the host that might explain the presence of the unusual process.
-
-### False positive analysis
-
-- Scheduled maintenance scripts or automated backup processes may access the metadata service for legitimate reasons, leading to false positives. Users can handle these by identifying and whitelisting such processes.
-- Custom monitoring tools or configuration management systems might interact with the metadata service to gather instance information, which could be misinterpreted as suspicious activity. Users should document these tools and create exceptions for them.
-- Cloud-native applications that dynamically adjust configurations based on metadata service information might trigger alerts. Users should ensure these applications are recognized and excluded from the rule.
-- Developers or system administrators performing manual checks or updates might access the metadata service, which could be flagged as unusual. Users can mitigate this by logging and reviewing such activities to differentiate between legitimate and suspicious access.
-- In environments with frequent deployment changes, new or updated processes might temporarily appear unusual. Users should establish a baseline of normal behavior and update it regularly to accommodate these changes.
-
-### Response and remediation
-
-- Immediately isolate the affected instance to prevent further unauthorized access to the metadata service.
-- Conduct a thorough investigation to identify the unusual process and determine if any credentials or sensitive data were accessed or exfiltrated.
-- Revoke and rotate any credentials that may have been exposed to prevent unauthorized access to other systems.
-- Review and update security group rules and IAM policies to ensure least privilege access to the metadata service.
-- Implement enhanced logging and monitoring for metadata service access, including logging all API calls and process interactions.
-- Integrate threat intelligence feeds and anomaly detection tools to improve detection of unusual activities related to metadata access.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
-- Restore the affected system to its operational state by applying patches, updating configurations, and ensuring all security controls are in place.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary services, applying security patches, and enforcing strong authentication mechanisms to protect against future attacks."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
index abd7961e89d..1e960dc1f49 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -84,48 +84,6 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux User Calling the Metadata Service
-
-Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using unauthorized users to query the service, aiming to extract sensitive information. The detection rule identifies atypical access patterns by monitoring for unexpected user interactions with the metadata service, flagging potential credential harvesting attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account and instance involved in the unusual metadata service access.
-- Check the timestamp of the alert to determine when the access occurred and correlate it with any known scheduled tasks or maintenance activities.
-- Examine the command history of the identified user on the instance to look for any commands that might have been used to access the metadata service.
-- Use Osquery to gather more information about the user and their recent activities. For example, run the following query to list recent processes executed by the user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'unusual_user');`
-- Investigate the network logs to identify any other unusual outbound connections from the instance around the time of the alert.
-- Check for any recent changes in user permissions or roles that might have inadvertently granted access to the metadata service.
-- Review the instance's system logs for any signs of compromise or unauthorized access attempts.
-- Analyze the metadata service access logs to determine if there were multiple access attempts or if other users have also accessed it unexpectedly.
-- Cross-reference the instance's IP address with threat intelligence sources to check for any known malicious activity associated with it.
-- Consult with the team responsible for the instance to verify if the access was legitimate and if any recent changes or deployments could explain the unusual behavior.
-
-### False positive analysis
-
-- Scheduled maintenance scripts or automated processes may trigger the rule if they access the metadata service regularly. These should be reviewed and, if deemed non-threatening, added to an exception list to prevent future alerts.
-- Backup or monitoring tools that require metadata access for legitimate purposes might be flagged. Identifying these tools and excluding their access patterns can reduce false positives.
-- Developers or system administrators performing legitimate testing or configuration tasks may inadvertently access the metadata service. Regularly review and update the list of authorized users to ensure their activities are not mistakenly flagged.
-- Instances of newly deployed applications or services that access the metadata service as part of their initialization process can be mistaken for suspicious activity. Documenting and excluding these known behaviors can help in minimizing false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected instance to prevent further unauthorized access to the metadata service.
-- Conduct a thorough investigation to identify the unusual user and determine how they gained access to the system.
-- Review access logs and metadata service queries to assess the extent of the compromise and identify any data exfiltration.
-- Revoke any credentials that may have been exposed and rotate keys or tokens associated with the affected instance.
-- Escalate the incident to the security operations team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed access logs for the metadata service and monitor for future anomalies.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all credentials are secure.
-- Harden the system by enforcing least privilege access, using role-based access controls, and regularly auditing user permissions.
-- Educate users and administrators on the importance of securing credentials and recognizing signs of unauthorized access attempts."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_suspicious_login_activity.toml b/rules/ml/credential_access_ml_suspicious_login_activity.toml
index cb7b64df9d9..ee7a91db756 100644
--- a/rules/ml/credential_access_ml_suspicious_login_activity.toml
+++ b/rules/ml/credential_access_ml_suspicious_login_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -95,51 +95,6 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Login Activity
-In modern environments, authentication systems are crucial for verifying user identities. Adversaries often exploit these systems through brute force attacks, attempting numerous login attempts to gain unauthorized access. The 'Unusual Login Activity' detection rule monitors for spikes in authentication attempts, signaling potential credential access threats. By identifying these anomalies, security teams can swiftly respond to and mitigate unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user accounts and IP addresses involved in the unusual login activity.
-- Check the timestamp of the alert to determine the time window of the suspicious activity.
-- Analyze the source IP addresses to identify if they are from known malicious sources or unusual locations for the user.
-- Examine the number of failed versus successful login attempts to assess the likelihood of a brute force attack.
-- Investigate the user accounts involved to determine if they have been targeted in past incidents or have elevated privileges.
-- Use Osquery to gather additional context on the affected systems. For example, run the following query to list recent login attempts on a specific host:
-  ```sql
-  SELECT username, time, host, address FROM last WHERE host = 'affected_host_name';
-  ```
-- Correlate the unusual login activity with other security events, such as changes in user permissions or modifications to critical files.
-- Check for any recent changes in the authentication system configuration that might have triggered false positives.
-- Review logs from other security tools, such as firewalls or intrusion detection systems, for related suspicious activity.
-- Consult with the user(s) involved to verify if the login attempts were legitimate or if their credentials may have been compromised.
-
-### False positive analysis
-
-- High-volume automated processes: Systems or applications that perform regular, automated login attempts, such as scheduled tasks or health checks, can trigger false positives. To manage this, identify and whitelist these processes by creating exceptions for known IP addresses or service accounts.
-- User behavior during password resets: Users may attempt multiple logins during password reset processes, leading to a spike in authentication attempts. Security teams can mitigate this by monitoring for password reset activities and correlating them with login attempts to distinguish between legitimate and suspicious behavior.
-- Load testing activities: During performance testing, systems may simulate numerous login attempts to evaluate authentication service capacity. Exclude these activities by coordinating with development and testing teams to schedule and document load tests, allowing for temporary rule adjustments.
-- Shared workstations or kiosks: Environments where multiple users log in from the same device can result in a high number of authentication attempts. Implement user behavior baselines and exclude these devices from triggering alerts by recognizing their unique usage patterns.
-- VPN or remote access fluctuations: Users connecting from different locations or through VPNs may cause a surge in login attempts. To handle this, establish a baseline for remote access patterns and adjust detection thresholds accordingly, ensuring legitimate remote work does not trigger false positives.
-
-### Response and remediation
-
-- Immediately isolate affected accounts to prevent further unauthorized access and reset passwords for compromised accounts.
-- Conduct a thorough investigation of the login attempts to identify the source IP addresses and correlate them with known threat intelligence feeds.
-- Review and analyze logs from authentication systems to determine the scope of the attack and identify any additional compromised accounts.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
-- Implement multi-factor authentication (MFA) for all user accounts to enhance security and reduce the risk of future brute force attacks.
-- Update and enforce strong password policies, ensuring that passwords are complex and changed regularly.
-- Integrate additional security tools such as intrusion detection systems (IDS) and security information and event management (SIEM) solutions to improve monitoring and detection capabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Restore affected systems to their operational state by applying necessary patches and updates, and ensure all security controls are functioning correctly.
-- Educate users on recognizing phishing attempts and the importance of safeguarding their credentials to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
index eb38666dd18..33d8ed7590e 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,48 +80,6 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Windows Process Calling the Metadata Service
-
-In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries exploit this by using atypical Windows processes to access the service, aiming to extract sensitive data. The detection rule identifies anomalies by monitoring unexpected process interactions with the metadata service, aligning with MITRE ATT&CK's focus on credential access and unsecured credentials.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Windows process that accessed the metadata service, noting the process name, process ID, and the user account under which it was running.
-- Check the timestamp of the alert to determine when the unusual access occurred and correlate it with any other suspicious activities in the logs around the same time.
-- Investigate the parent process of the identified Windows process to understand how it was initiated and whether it was spawned by a legitimate application or script.
-- Use Osquery to gather more information about the process. For example, run the following query to get details about the process and its parent: `SELECT pid, name, path, parent, cmdline FROM processes WHERE pid = <process_id>;`
-- Examine the network connections established by the process using Osquery: `SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid = <process_id>;` to identify any unusual or unauthorized connections.
-- Analyze the command line arguments used by the process to determine if there are any indications of malicious intent or attempts to access sensitive data.
-- Check the Windows Event Logs for any related security events, such as logon events or privilege escalation attempts, that might provide additional context about the process's activity.
-- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access or privilege escalation.
-- Review any recent changes or updates to the system or applications that might have introduced the unusual process behavior, including software installations or script deployments.
-- Consult threat intelligence sources to see if the process or its behavior matches any known indicators of compromise or attack patterns related to credential access or metadata service exploitation.
-
-### False positive analysis
-
-- Known false positives may include legitimate administrative tools or scripts that access the metadata service for configuration management or system monitoring purposes. These tools might be scheduled to run at regular intervals, leading to repeated alerts.
-- Automated backup or deployment processes that interact with the metadata service to retrieve instance-specific information can also trigger false positives. These processes are typically part of routine operations and not indicative of malicious activity.
-- Users can manage these false positives by creating exceptions for known and trusted processes that regularly access the metadata service. This can be done by whitelisting specific process names or paths that are verified to be part of legitimate operations.
-- It is important to regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule against genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the unusual process and determine how it accessed the metadata service, focusing on process execution logs and network traffic.
-- Terminate the suspicious process and any associated processes to stop ongoing malicious activity.
-- Review and revoke any credentials or tokens that may have been exposed or compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging and monitoring for metadata service access, ensuring that all access attempts are logged and reviewed for anomalies.
-- Integrate threat intelligence feeds to correlate the incident with known threat actors or tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
-- Restore the system to its operational state by applying patches, updating security configurations, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as restricting metadata service access to only trusted processes.
-- Provide training and awareness to relevant personnel on the risks associated with metadata service access and the importance of securing credentials."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
index 4147284c43f..2e6b058293f 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,49 +80,6 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Windows User Calling the Metadata Service
-
-Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using compromised Windows accounts to query the service, aiming to extract sensitive information. The detection rule identifies atypical access patterns by monitoring for unexpected user interactions with the metadata service, flagging potential credential harvesting attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Windows user account involved and the timestamp of the metadata service access.
-- Check the source IP address and geolocation associated with the access to determine if it aligns with expected user behavior or known locations.
-- Analyze the user's recent login history and patterns to identify any anomalies or deviations from their typical activity.
-- Investigate the user's group memberships and permissions to assess if they have legitimate access to the metadata service.
-- Examine the process and command-line arguments used during the metadata service access to identify any suspicious or unauthorized tools.
-- Utilize Osquery to gather additional context on the system. For example, run the following query to list recent processes executed by the user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
-- Cross-reference the metadata service access with other security logs, such as firewall or intrusion detection system logs, to identify any correlated suspicious activities.
-- Review any recent changes to the user's account, such as password resets or privilege escalations, that could indicate account compromise.
-- Check for any other alerts or incidents involving the same user or system to determine if this is part of a broader attack pattern.
-- Consult threat intelligence sources to see if there are any known campaigns or tactics that match the observed behavior, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may occasionally access the metadata service for legitimate purposes, such as configuration checks or updates. These actions can be mistaken for suspicious activity.
-- Automated scripts: Some automated processes or scripts might be configured to interact with the metadata service regularly for maintenance or monitoring purposes, leading to false alerts.
-- Third-party tools: Certain third-party management or monitoring tools may access the metadata service as part of their normal operation, which could trigger the detection rule.
-- To manage these false positives, users can create exceptions for known administrative accounts or service accounts that regularly interact with the metadata service. This can be done by maintaining a whitelist of trusted users or processes.
-- Regularly review and update the list of exceptions to ensure it reflects current operational needs and does not inadvertently exclude genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the compromised user account and determine the scope of the breach, including any other systems or data accessed.
-- Reset passwords for the compromised account and any other accounts that may have been affected, ensuring the use of strong, unique passwords.
-- Review and analyze logs from the metadata service and other relevant systems to identify any unusual patterns or indicators of compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Implement enhanced logging and monitoring policies to capture detailed access logs for the metadata service and other critical systems.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the affected system to its operational state by applying necessary patches, updates, and security configurations.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to address these vulnerabilities.
-- Educate users on security best practices and the importance of safeguarding credentials to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_information_discovery.toml b/rules/ml/discovery_ml_linux_system_information_discovery.toml
index 9fcfd8261cd..2e06a27dba8 100644
--- a/rules/ml/discovery_ml_linux_system_information_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_information_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -86,48 +86,6 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux System Information Discovery Activity
-
-Linux systems often use commands like `uname`, `lscpu`, or `lsb_release` for legitimate system information discovery, aiding in troubleshooting and system management. However, adversaries can exploit these commands to gather critical system details, potentially leading to privilege escalation or persistence. The detection rule identifies atypical usage patterns by monitoring command execution from unexpected user contexts, signaling possible account compromise or malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command executed, the user account involved, and the timestamp of the activity.
-- Check the user account's login history and recent activity using `last` and `lastlog` commands to determine if the account has been accessed from unusual locations or at odd times.
-- Examine the user's shell history files (e.g., `.bash_history`) to identify any other suspicious commands executed around the same time.
-- Use Osquery to gather additional context about the system and user activity. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
-- Investigate the parent process of the suspicious command execution to determine if it was initiated by a legitimate process or a potentially malicious one.
-- Analyze system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any authentication anomalies or failed login attempts around the time of the alert.
-- Check for any recent changes to user permissions or group memberships that could indicate privilege escalation attempts.
-- Review network activity logs to identify any unusual outbound connections or data exfiltration attempts following the suspicious command execution.
-- Correlate the alert with other security events or alerts in the environment to identify potential patterns or related incidents.
-- Consult threat intelligence sources to determine if the observed activity matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware.
-
-### False positive analysis
-
-- System administrators or IT personnel may execute system information discovery commands during routine maintenance or troubleshooting, which could trigger the rule. To manage this, users can create exceptions for specific user accounts or roles known to perform these tasks regularly.
-- Automated scripts or monitoring tools that run system information commands as part of their normal operation might also be flagged. Users should identify these scripts and whitelist them by their execution paths or associated service accounts to prevent false positives.
-- Developers or engineers working on performance testing or system optimization might use these commands in non-production environments. Users can exclude specific environments or IP ranges from monitoring to reduce unnecessary alerts.
-- In educational or research institutions, students or researchers might execute these commands as part of their learning or experimentation processes. Users can implement exceptions for specific user groups or departments to accommodate these activities without compromising security.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying the user account involved and any other systems that may have been accessed.
-- Review system logs and command history to identify unusual patterns or unauthorized commands executed, correlating with MITRE ATT&CK technique T1082 for system information discovery.
-- Reset passwords for the compromised account and any other accounts that may have been accessed, ensuring the use of strong, unique passwords.
-- Remove any unauthorized users or processes identified during the investigation and ensure that all system software is up to date with the latest security patches.
-- Restore the system from a known good backup if necessary, ensuring that the backup is free from any malicious modifications.
-- Implement enhanced logging and monitoring policies to capture detailed command execution and user activity, integrating with SIEM solutions for real-time alerting.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Provide security awareness training to users, emphasizing the importance of recognizing and reporting suspicious activity.
-- Consider deploying additional security measures such as multi-factor authentication and endpoint detection and response (EDR) solutions to enhance system hardening and threat detection capabilities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
index 56ff2f61985..eae2bbef640 100644
--- a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 25
@@ -86,49 +86,6 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux Network Configuration Discovery
-
-Linux systems often use commands like `ifconfig`, `ip`, and `netstat` for network configuration discovery, essential for troubleshooting and network management. Adversaries exploit these commands to map network structures, aiding in lateral movement or further reconnaissance. The detection rule identifies atypical usage patterns by monitoring command execution from unexpected user accounts, signaling potential account compromise or malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command executed, the user account involved, and the timestamp of the activity.
-- Check the user account's login history and recent activity to determine if the account has been used in an unusual manner or from unexpected locations.
-- Analyze the command execution context, including the terminal or process that initiated the command, to identify any anomalies or suspicious patterns.
-- Investigate the source IP address and hostname associated with the command execution to verify if they are known and trusted within the network.
-- Use Osquery to gather additional context about the system and user activity. For example, run the following query to list recent network-related commands executed by the user: `SELECT * FROM shell_history WHERE command LIKE '%ifconfig%' OR command LIKE '%ip%' OR command LIKE '%netstat%' AND uid = <user_id>;`
-- Examine system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any signs of unauthorized access or privilege escalation attempts around the time of the alert.
-- Cross-reference the alert with other security events or alerts to identify any correlated activities that might indicate a broader attack campaign.
-- Review the system's network configuration and recent changes to identify any unauthorized modifications or suspicious network connections.
-- Check for any recent file modifications or new files in the user's home directory or other sensitive directories that might indicate malicious activity.
-- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with specific threat actors or campaigns.
-
-### False positive analysis
-
-- System administrators or network engineers performing routine network diagnostics may trigger the rule if they use unexpected accounts or workstations. To manage this, create exceptions for known user accounts or IP addresses that regularly perform these tasks.
-- Automated scripts or monitoring tools that execute network configuration commands for legitimate purposes might be flagged. Users can whitelist these scripts or processes by identifying their signatures or execution patterns.
-- Temporary or new user accounts created for specific projects or troubleshooting can cause alerts. Ensure these accounts are documented and added to an exception list if their activities are verified as non-threatening.
-- Changes in user roles or responsibilities might lead to legitimate network configuration commands being run by users who previously did not perform such tasks. Regularly update the exception list to reflect these role changes.
-- In environments with frequent network changes or testing, legitimate users might execute network discovery commands more often. Implement a review process to periodically assess and update the list of exceptions based on current network activity patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the user account that executed the unusual network configuration commands and reset its credentials if compromised.
-- Conduct a thorough investigation of the system logs to identify any additional suspicious activities or unauthorized access attempts.
-- Review and analyze the command history to understand the scope of the adversary's reconnaissance and any potential data exfiltration.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed command execution and user activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are intact.
-- Conduct a security audit of the network to identify and remediate any vulnerabilities that could be exploited for similar attacks.
-- Implement hardening measures such as least privilege access, multi-factor authentication, and regular user activity reviews to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
index 6b1c0595af4..83d47f0cbe2 100644
--- a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 25
@@ -86,49 +86,6 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux Network Connection Discovery
-
-In Linux environments, network connection discovery tools help administrators understand system connectivity. Adversaries exploit these tools to map networks, aiding in lateral movement or further reconnaissance. The detection rule identifies atypical usage patterns by monitoring commands executed from unexpected user contexts, signaling potential account compromise or unauthorized network probing.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command executed and the user context from which it was run. Pay attention to fields such as `user`, `command`, and `timestamp`.
-- Check the user's login history and session details using `last` and `who` commands to determine if the user context is legitimate or if there are signs of unauthorized access.
-- Analyze the command history for the user in question by reviewing the `.bash_history` or equivalent shell history files to identify any other suspicious activities.
-- Use Osquery to gather more context about the network connections on the system. For example, run the query: `SELECT * FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'netstat' OR name = 'ss');` to identify processes that have opened network connections.
-- Investigate the source IP addresses and destinations involved in the network connections to determine if they are known and trusted or if they are unusual or malicious.
-- Cross-reference the alert with any recent changes in user permissions or group memberships that might explain the unusual activity.
-- Check for any recent file modifications or new files in the user's home directory that could indicate the presence of malicious scripts or tools.
-- Review system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any anomalies or failed login attempts around the time of the alert.
-- Correlate the alert with other security events or alerts in the environment to identify if this is part of a larger attack pattern or campaign.
-- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with specific threat actors.
-
-### False positive analysis
-
-- System administrators or network engineers may execute network discovery commands during routine maintenance or troubleshooting, which could trigger the rule. To manage this, create exceptions for known user accounts or specific time windows when such activities are expected.
-- Automated scripts or monitoring tools that perform regular network checks might be flagged as unusual. Identify these scripts and whitelist their execution paths or associated user accounts to prevent false alerts.
-- New employees or contractors who are unfamiliar with standard procedures might inadvertently run network discovery commands. Educate these users on proper protocols and consider temporary exceptions while they are onboarded.
-- Changes in network infrastructure or security policies might necessitate increased network discovery activities. During these periods, adjust the rule's sensitivity or temporarily disable it to accommodate the expected increase in legitimate network probing.
-- In environments with frequent role changes, users might inherit permissions that allow them to execute network discovery commands. Regularly review and update user permissions to ensure they align with current job responsibilities, and adjust the rule to account for these transitions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying the user account and commands involved in the unusual network connection discovery.
-- Reset passwords and review permissions for the compromised account to prevent further unauthorized access.
-- Analyze system logs and network traffic to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has accessed other systems.
-- Implement enhanced logging policies to capture detailed command execution and network activity, ensuring future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual activities with known threat actor behaviors.
-- Restore the system to its operational state by applying necessary patches, updates, and verifying the integrity of critical system files.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unused network services, enforcing least privilege access, and regularly auditing user accounts and permissions."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_process_discovery.toml b/rules/ml/discovery_ml_linux_system_process_discovery.toml
index 9006b24e919..9eadd5f1c4b 100644
--- a/rules/ml/discovery_ml_linux_system_process_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_process_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -86,49 +86,6 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux Process Discovery Activity
-In Linux environments, process discovery commands help users and administrators understand active processes, aiding in system management and troubleshooting. However, adversaries can exploit these commands to map out running applications, potentially identifying vulnerabilities for privilege escalation or persistence. The detection rule identifies atypical usage patterns of these commands, especially from unexpected user accounts, signaling possible account compromise or malicious reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account and process discovery command that triggered the alert.
-- Check the timestamp of the alert to determine when the unusual activity occurred and correlate it with any other suspicious activities in the same timeframe.
-- Investigate the user account's recent activity history to identify any anomalies or signs of compromise, such as unusual login times or IP addresses.
-- Examine the command execution context, including the parent process and any associated child processes, to understand the broader activity chain.
-- Use Osquery to gather additional context on the system. For example, run the following query to list all processes executed by the suspicious user in the last 24 hours: `SELECT * FROM processes WHERE user = '<suspicious_user>' AND datetime(start_time, 'unixepoch') > datetime('now', '-1 day');`
-- Analyze system logs, such as auth logs and bash history, to identify any unauthorized access or command execution patterns.
-- Cross-reference the process discovery command with known legitimate administrative activities to rule out false positives.
-- Investigate any network connections initiated by the suspicious process to identify potential data exfiltration or lateral movement attempts.
-- Check for any recent changes to system files or configurations that could indicate an attempt to establish persistence or escalate privileges.
-- Consult threat intelligence sources to determine if the observed activity matches any known tactics, techniques, or procedures (TTPs) associated with specific threat actors.
-
-### False positive analysis
-
-- System administrators or IT personnel performing routine maintenance or troubleshooting may trigger the rule if they use process discovery commands from accounts not typically associated with such activities. 
-- Automated scripts or monitoring tools that regularly execute process discovery commands for legitimate system health checks can also be flagged as unusual activity.
-- Developers or engineers conducting performance testing or debugging on production systems might inadvertently cause alerts if their accounts are not recognized as standard for such operations.
-- To manage these false positives, users can create exceptions for specific user accounts or groups known to perform legitimate process discovery tasks regularly.
-- Implementing a whitelist of IP addresses or hostnames from which legitimate process discovery commands are expected can help reduce unnecessary alerts.
-- Regularly review and update the list of known benign activities and user accounts to ensure that legitimate actions are not mistakenly flagged as suspicious.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Review the user account activity logs to identify any unauthorized access or anomalies, focusing on the account that executed the unusual process discovery commands.
-- Terminate any suspicious processes identified during the investigation to halt potential malicious activities.
-- Change passwords for compromised accounts and enforce multi-factor authentication to enhance account security.
-- Conduct a thorough forensic analysis of the system to identify any additional indicators of compromise or persistence mechanisms.
-- Restore the system from a known good backup if malicious activity is confirmed and ensure all security patches are applied.
-- Implement enhanced logging policies to capture detailed process execution and user activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Review and update security policies and hardening measures, such as disabling unnecessary services and enforcing least privilege principles, to reduce the attack surface."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_user_discovery.toml b/rules/ml/discovery_ml_linux_system_user_discovery.toml
index d7e05941a19..c7ce566570c 100644
--- a/rules/ml/discovery_ml_linux_system_user_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_user_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -86,49 +86,6 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux User Discovery Activity
-
-In Linux environments, user discovery commands help administrators identify active users and system owners, crucial for system management. However, adversaries exploit these commands to gather intelligence on user accounts, potentially leading to further attacks like credential theft or privilege escalation. The detection rule identifies atypical execution of these commands by unexpected users, signaling possible account compromise or malicious reconnaissance.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account and the command executed that triggered the alert.
-- Check the timestamp of the alert to determine when the unusual activity occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the source IP address and hostname from which the command was executed to verify if it aligns with the user's typical access patterns.
-- Examine the user's login history and session details to identify any anomalies or unauthorized access attempts.
-- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM logged_in_users WHERE user = '<suspicious_user>';` to check for any active sessions of the suspicious user.
-- Analyze the command history of the user account to identify any other potentially malicious or unusual commands executed around the time of the alert.
-- Review system logs, such as `/var/log/auth.log` or `/var/log/secure`, for any failed login attempts or other suspicious authentication events related to the user.
-- Check for any recent changes to user account permissions or group memberships that could indicate privilege escalation attempts.
-- Investigate any recent file modifications or access patterns that could suggest data exfiltration or preparation for further attacks.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign.
-
-### False positive analysis
-
-- System administrators or support staff may execute user discovery commands during routine maintenance or troubleshooting, which can trigger false positives. To manage this, create exceptions for known administrator accounts or specific maintenance windows.
-- Automated scripts or monitoring tools that perform regular checks on user accounts might be flagged as unusual activity. Exclude these scripts or tools by identifying their execution patterns and adding them to an allowlist.
-- Developers or engineers with legitimate reasons to access user information for debugging purposes may also cause alerts. Document these use cases and establish exceptions for specific user roles or groups.
-- Temporary contractors or new employees performing legitimate user discovery as part of their onboarding process might be mistakenly flagged. Implement a review process to quickly assess and approve such activities when they occur.
-- In environments with frequent user account changes, such as educational institutions or large enterprises, regular user discovery might be necessary. Adjust the detection thresholds or create dynamic exceptions based on the frequency of these changes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying the commands executed and the user accounts involved.
-- Review system logs and user activity to identify any unauthorized access or suspicious behavior, leveraging enhanced logging policies if available.
-- Reset passwords for all potentially compromised accounts and enforce multi-factor authentication to prevent unauthorized access.
-- Remove any unauthorized users or accounts created by the adversary and ensure all legitimate accounts have appropriate permissions.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
-- Implement additional security measures such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to enhance monitoring and detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate users on security best practices and the importance of reporting suspicious activity to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/execution_ml_windows_anomalous_script.toml b/rules/ml/execution_ml_windows_anomalous_script.toml
index 68dc84ee722..43a98b856eb 100644
--- a/rules/ml/execution_ml_windows_anomalous_script.toml
+++ b/rules/ml/execution_ml_windows_anomalous_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -84,48 +84,6 @@ tags = [
     "Tactic: Execution",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Powershell Script
-
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities to execute malicious scripts, often employing obfuscation to evade detection. The 'Suspicious Powershell Script' detection rule leverages machine learning to identify anomalies in script characteristics, such as obfuscation, indicative of potential threats, aligning with MITRE ATT&CK's execution tactics.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific characteristics of the detected PowerShell script, focusing on fields such as script content, execution time, and user context.
-- Examine the script content for signs of obfuscation, such as encoded commands, unusual variable names, or excessive use of special characters.
-- Check the execution context by identifying the user account and machine involved, using fields like `user.name` and `host.name`.
-- Correlate the script execution with recent user activity logs to determine if the execution aligns with expected behavior or if it appears anomalous.
-- Investigate the parent process that initiated the PowerShell script using fields like `process.parent.name` and `process.parent.id` to identify potential malicious chains.
-- Utilize Osquery to gather additional context on the host. For example, run the following query to list recent PowerShell executions: `SELECT * FROM processes WHERE name = 'powershell.exe' ORDER BY start_time DESC LIMIT 10;`
-- Analyze network connections established by the host around the time of the script execution to identify any suspicious outbound connections.
-- Review any file modifications or registry changes made by the script using endpoint detection logs or file integrity monitoring tools.
-- Check for any related alerts or incidents involving the same user or host to identify patterns or repeated suspicious behavior.
-- Consult threat intelligence sources to determine if the script or its components match known malicious indicators or tactics.
-
-### False positive analysis
-
-- Legitimate administrative scripts: PowerShell is commonly used for legitimate administrative tasks, which may include obfuscation for efficiency or to protect sensitive information. Users should review scripts flagged by the detection rule to determine if they are part of routine administrative operations.
-- Automated deployment tools: Some deployment tools use PowerShell scripts that might appear suspicious due to their automated nature and obfuscation techniques. Users can create exceptions for these tools by identifying their unique characteristics and excluding them from the detection rule.
-- Security software: Certain security solutions use PowerShell scripts for scanning and remediation purposes. These scripts might be flagged as suspicious due to their complexity and obfuscation. Users should verify the source of these scripts and whitelist them if they are from trusted security vendors.
-- Development and testing environments: Developers often use PowerShell scripts for testing and development purposes, which might include obfuscation to simulate real-world scenarios. Users can exclude specific development environments or known developer accounts from the detection rule to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Analyze the detected PowerShell script to understand its behavior and intent, focusing on obfuscation techniques and any external connections it attempts to make.
-- Terminate any malicious processes associated with the script to halt its execution.
-- Review and collect relevant logs, such as PowerShell logs, Windows Event logs, and network traffic logs, to gather evidence and understand the scope of the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team if the script is part of a larger attack campaign or if multiple systems are affected.
-- Remove any malicious files or registry entries created by the script to remediate the system.
-- Apply security patches and updates to the affected system to address any vulnerabilities exploited by the script.
-- Implement enhanced logging and monitoring policies for PowerShell activities to improve detection of similar threats in the future.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance visibility and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
index 0ec1cb7f50f..f6b95127b55 100644
--- a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
+++ b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -95,50 +95,6 @@ tags = [
     "Tactic: Initial Access",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Source IP for a User to Logon from
-
-Machine learning models analyze login patterns to identify atypical IP addresses for users, flagging potential threats like compromised accounts or lateral movement. Adversaries exploit valid credentials to access systems from unexpected locations. This detection rule leverages these models to alert analysts to suspicious logins, aiding in early threat identification and response.
-
-### Possible investigation steps
-
-- Review the alert details to identify the unusual source IP address and the associated user account.
-- Check the login history for the user to determine if the IP address has been used previously and assess the frequency of its occurrence.
-- Correlate the unusual IP address with known threat intelligence sources to check if it has been associated with malicious activity.
-- Analyze the geolocation of the unusual IP address to determine if it aligns with the user's typical login locations or if it is from a high-risk region.
-- Investigate the time of the login event to see if it coincides with the user's normal working hours or if it is an anomaly.
-- Use Osquery to gather additional context on the endpoint from which the login was attempted. Example query: `SELECT * FROM logged_in_users WHERE user = '<username>';`
-- Examine any recent changes in the user's account permissions or group memberships that could indicate unauthorized access.
-- Review any concurrent login attempts from different locations for the same user, which could suggest account compromise.
-- Check for any recent password changes or failed login attempts for the user account that could indicate a brute force attack.
-- Investigate any other security alerts or logs related to the user or the unusual IP address to identify potential patterns or related incidents.
-
-### False positive analysis
-
-- Known false positives for the "Unusual Source IP for a User to Logon from" rule can occur when users travel or work remotely, leading to logins from legitimate but previously unseen IP addresses. 
-- Another common false positive scenario is when users access systems through VPNs or proxy services, which can result in logins from IP addresses that differ from their usual patterns.
-- To manage these false positives, users can create exceptions for known and verified IP addresses associated with frequent travel destinations or remote work locations.
-- Implementing a whitelist for IP addresses associated with trusted VPN or proxy services can help reduce unnecessary alerts.
-- Regularly updating the list of approved IP addresses based on user travel patterns and organizational changes can further minimize false positives.
-- Analysts should review and validate the context of flagged logins, considering factors like time of access and user activity, to distinguish between legitimate and suspicious behavior.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying any other compromised accounts or systems.
-- Analyze the unusual IP address to gather intelligence on its origin and any associated malicious activity.
-- Review recent login activity for the affected user and other users to identify any patterns or additional suspicious logins.
-- Reset passwords for the compromised account and any other accounts that may have been affected, ensuring the use of strong, unique passwords.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring policies to capture detailed login events and network activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore the system to its operational state by ensuring all compromised accounts are secured and any malicious software is removed.
-- Apply hardening measures such as multi-factor authentication (MFA) and least privilege access to reduce the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/ml_high_count_network_denies.toml b/rules/ml/ml_high_count_network_denies.toml
index 63be4372e58..c0f5fc17b56 100644
--- a/rules/ml/ml_high_count_network_denies.toml
+++ b/rules/ml/ml_high_count_network_denies.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -76,52 +76,4 @@ rule_id = "eaa77d63-9679-4ce3-be25-3ba8b795e5fa"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Firewall Denies
-
-Firewalls and ACLs are critical in regulating network traffic, blocking unauthorized access while allowing legitimate communication. Adversaries may exploit misconfigurations or launch attacks like reconnaissance or denial-of-service to generate a surge in denied traffic. The 'Spike in Firewall Denies' detection rule leverages machine learning to identify unusual spikes, signaling potential misconfigurations or malicious activities.
-
-### Possible investigation steps
-
-- Review the timestamp of the spike to determine the exact time window of the unusual activity.
-- Analyze the source IP addresses involved in the denied traffic to identify any patterns or anomalies, such as repeated attempts from a single IP or a range of IPs.
-- Examine the destination IP addresses and ports to understand which services or applications were targeted during the spike.
-- Check the firewall and ACL configuration logs for recent changes that might have led to misconfigurations, causing legitimate traffic to be denied.
-- Correlate the denied traffic with any known threat intelligence feeds to identify if the source IPs are associated with known malicious actors or activities.
-- Use Osquery to gather additional context on the affected systems. For example, run the following query to list recent network connections on a potentially affected host:
-  ```sql
-  SELECT datetime(start_time, 'unixepoch') AS start_time, local_address, local_port, remote_address, remote_port, protocol
-  FROM process_open_sockets
-  WHERE remote_address IN ('<suspicious_ip_1>', '<suspicious_ip_2>');
-  ```
-- Investigate any related alerts or logs from intrusion detection systems (IDS) or intrusion prevention systems (IPS) that might provide additional context on the nature of the denied traffic.
-- Check for any concurrent spikes in other network activities, such as successful connections or unusual data transfer volumes, which might indicate a broader attack pattern.
-- Review user activity logs to identify any unusual login attempts or access patterns that coincide with the spike in denied traffic.
-- Consult with application owners or network administrators to verify if any legitimate applications or services were impacted by the spike, which could indicate a misconfiguration rather than a malicious attempt.
-
-### False positive analysis
-
-- Routine network scans by security tools or vulnerability assessment software can trigger false positives, as these activities may generate a high volume of denied traffic. Users can handle this by creating exceptions for known IP addresses or ranges associated with these tools.
-- Legitimate applications with misconfigured network settings might cause a spike in denied traffic. Regularly auditing and updating application configurations can help minimize these occurrences.
-- Automated backup or synchronization processes that attempt to connect to restricted network segments may result in false positives. Identifying and whitelisting these processes can prevent unnecessary alerts.
-- Internal network changes, such as updates to firewall rules or ACLs, might temporarily increase denied traffic. Documenting and scheduling these changes can help correlate and exclude them from analysis.
-- High-volume legitimate business operations, like data migrations or large file transfers, could be mistaken for suspicious activity. Monitoring and adjusting thresholds during these operations can reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate affected systems from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and nature of the spike in denied traffic, focusing on recent changes in firewall or ACL configurations.
-- Review firewall and ACL logs to pinpoint any misconfigurations or unauthorized changes that may have led to the spike.
-- If malicious activity is suspected, analyze the traffic patterns to identify potential command-and-control (C2) communication attempts or reconnaissance activities.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of a targeted attack or advanced persistent threat (APT).
-- Implement enhanced logging and monitoring to capture detailed information on denied traffic, ensuring future spikes can be quickly analyzed and addressed.
-- Integrate threat intelligence feeds to correlate denied traffic with known malicious IP addresses or domains, enhancing detection capabilities.
-- Restore affected systems to their operational state by applying necessary patches, reconfiguring firewalls, and ensuring all security controls are properly implemented.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement hardening measures such as regular audits of firewall rules, continuous monitoring for anomalies, and employee training on recognizing and reporting suspicious activities."""
 
diff --git a/rules/ml/ml_high_count_network_events.toml b/rules/ml/ml_high_count_network_events.toml
index df9e3952ad6..edc03f65057 100644
--- a/rules/ml/ml_high_count_network_events.toml
+++ b/rules/ml/ml_high_count_network_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -75,48 +75,4 @@ rule_id = "b240bfb8-26b7-4e5e-924e-218144a3fa71"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Spike in Network Traffic
-
-Machine learning models monitor network traffic patterns to identify anomalies, such as unexpected spikes. These spikes may indicate malicious activities like data exfiltration, reconnaissance, or denial-of-service attacks. Adversaries exploit network vulnerabilities to flood traffic or extract data. The detection rule leverages these models to flag unusual traffic surges, prompting further investigation into potential threats.
-
-### Possible investigation steps
-
-- Review the timestamp of the spike to correlate with any scheduled business activities or known events that could justify the increase in traffic.
-- Analyze the source and destination IP addresses involved in the spike to identify any known malicious actors or unusual patterns.
-- Examine the network protocols and ports used during the spike to determine if they align with typical business operations or if they suggest suspicious activity.
-- Check for any recent changes in network configurations or firewall rules that could have inadvertently caused the spike.
-- Utilize Osquery to gather additional context on the systems involved. For example, run the following query to list active network connections: `SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL;`
-- Investigate the volume and type of data being transferred during the spike to assess if it aligns with potential data exfiltration activities.
-- Cross-reference the spike with any other security alerts or logs from intrusion detection systems to identify potential correlations.
-- Review user activity logs to determine if any unauthorized access or unusual user behavior coincides with the spike.
-- Check for any recent vulnerabilities or exploits that could have been leveraged to cause the spike in traffic.
-- Consult threat intelligence sources to see if there are any reports of similar traffic patterns or attacks targeting your industry or organization.
-
-### False positive analysis
-
-- Legitimate business activities such as scheduled data backups or software updates can cause spikes in network traffic, which may be mistakenly flagged as suspicious. 
-- High-volume data transfers during peak business hours or due to seasonal business demands can also trigger false positives.
-- Network performance testing or stress testing activities might generate traffic patterns similar to those of a denial-of-service attack.
-- Users can manage these false positives by creating exceptions for known, recurring activities that are verified as non-threatening.
-- Implementing a whitelist for IP addresses or domains associated with trusted business operations can help reduce false alerts.
-- Regularly updating the machine learning model with feedback on false positives can improve its accuracy over time.
-
-### Response and remediation
-
-- Immediately isolate affected systems from the network to prevent further data exfiltration or damage.
-- Conduct a thorough investigation to identify the source and nature of the traffic spike, using network logs and monitoring tools.
-- Analyze the traffic patterns to determine if the spike correlates with known malicious activities, referencing MITRE ATT&CK for potential tactics and techniques.
-- If malicious activity is confirmed, remove any identified malware or unauthorized access points from the affected systems.
-- Escalate the incident to the appropriate internal teams and, if necessary, external cybersecurity experts for further analysis and response.
-- Implement enhanced logging policies to capture detailed network traffic data for future analysis and early detection of anomalies.
-- Integrate additional security tools, such as intrusion detection systems (IDS) or endpoint detection and response (EDR) solutions, to improve monitoring capabilities.
-- Restore affected systems to their operational state by applying necessary patches, updates, and configurations to close any exploited vulnerabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement network hardening measures, such as segmenting the network, applying strict access controls, and regularly updating firewall rules, to prevent future incidents."""
 
diff --git a/rules/ml/ml_linux_anomalous_network_port_activity.toml b/rules/ml/ml_linux_anomalous_network_port_activity.toml
index fa5b3410b31..140a8bc735f 100644
--- a/rules/ml/ml_linux_anomalous_network_port_activity.toml
+++ b/rules/ml/ml_linux_anomalous_network_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -80,51 +80,4 @@ tags = [
     "Rule Type: Machine Learning",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Linux Network Port Activity
-
-In Linux environments, network ports facilitate communication between applications and services. Adversaries may exploit rarely used ports for malicious activities like command-and-control or data exfiltration, bypassing standard monitoring. The 'Unusual Linux Network Port Activity' detection rule identifies anomalies in port usage, flagging potential unauthorized access or threat actor presence by focusing on atypical destination port activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific destination port and source IP address involved in the unusual activity.
-- Check historical logs to determine if the destination port has been used previously and if so, assess the frequency and context of its usage.
-- Correlate the source IP address with known assets or users within the organization to determine if the activity aligns with expected behavior.
-- Use Osquery to gather additional context on the host involved. For example, run the following query to list active network connections and identify processes using the unusual port:
-  ```sql
-  SELECT pid, name, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE local_port = <unusual_port>;
-  ```
-- Investigate the process identified in the previous step to determine its legitimacy by checking its executable path, hash, and associated user.
-- Analyze network traffic logs to identify any patterns or anomalies associated with the unusual port, such as repeated connections or data transfers.
-- Cross-reference the unusual port activity with threat intelligence feeds to check for known malicious indicators or patterns.
-- Examine system logs for any signs of compromise or suspicious activity around the time the unusual port activity was detected.
-- Verify if there are any recent changes or deployments on the host that could explain the unusual port activity, such as new software installations or updates.
-- Consult with relevant teams or personnel to gather additional context or insights regarding the unusual port activity, ensuring a comprehensive understanding of the situation.
-
-### False positive analysis
-
-- Known false positives may include legitimate applications or services that use non-standard ports for communication, such as custom internal tools or legacy systems that have not been updated to use standard ports.
-- Automated backup or monitoring solutions might use unusual ports for data transfer, which can trigger alerts if not properly documented or excluded.
-- Development and testing environments often experiment with different port configurations, leading to benign anomalies in port usage.
-- To manage these false positives, users can create exceptions for known and verified applications or services that consistently use specific non-standard ports.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the effectiveness of the detection rule.
-- Collaborate with network and system administrators to document and understand the purpose of unusual port usage within the organization, reducing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the unusual port activity by reviewing network logs and identifying the source and destination of the traffic.
-- Verify the legitimacy of the process or application using the unusual port by cross-referencing with known software and services.
-- If malicious activity is confirmed, terminate any suspicious processes and remove any unauthorized software or scripts.
-- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed network traffic and system events for future analysis and detection.
-- Integrate threat intelligence feeds and anomaly detection tools to improve the identification of unusual network activities.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are correctly set.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement network segmentation and access controls to limit the exposure of critical systems and reduce the risk of similar incidents in the future."""
 
diff --git a/rules/ml/ml_packetbeat_rare_server_domain.toml b/rules/ml/ml_packetbeat_rare_server_domain.toml
index ff8e5dfc6c7..653e4cc3226 100644
--- a/rules/ml/ml_packetbeat_rare_server_domain.toml
+++ b/rules/ml/ml_packetbeat_rare_server_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -83,47 +83,4 @@ rule_id = "17e68559-b274-4948-ad0b-f8415bb31126"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Network Destination Domain Name
-
-Machine learning models analyze network traffic to identify domain names that deviate from typical patterns, flagging potential threats. Adversaries exploit this by using rare domains for malicious activities like phishing or command-and-control. The detection rule identifies these anomalies, alerting analysts to investigate potential security incidents.
-
-### Possible investigation steps
-
-- Review the alert details to identify the unusual domain name and the associated network activity, including timestamps and source IP addresses.
-- Cross-reference the unusual domain name with threat intelligence databases to check for any known associations with malicious activities.
-- Analyze the network traffic logs to determine the volume and frequency of requests to the unusual domain, looking for patterns that may indicate automated or scripted activity.
-- Investigate the source IP address to identify the device or user responsible for the network request, using asset management systems or endpoint detection and response (EDR) tools.
-- Use Osquery to gather additional context from the affected endpoint. For example, run the following query to list recent DNS queries made by the device: `SELECT name, COUNT(name) AS query_count FROM dns_queries GROUP BY name ORDER BY query_count DESC LIMIT 10;`
-- Check the endpoint's process execution logs to identify any suspicious processes that may have initiated the network request to the unusual domain.
-- Examine user activity logs to determine if the user associated with the source IP address engaged in any unusual behavior, such as clicking on phishing links or downloading suspicious files.
-- Review email logs for the user to identify any recent phishing attempts that may have led to the network request to the unusual domain.
-- Analyze any related alerts or incidents in the security information and event management (SIEM) system to identify potential correlations or patterns with other suspicious activities.
-- Consult with other analysts or teams to gather additional insights or context that may aid in understanding the significance of the unusual domain name and its potential impact.
-
-### False positive analysis
-
-- Legitimate business applications or services may use uncommon domain names for updates or communication, leading to false positives. Users should verify the domain's legitimacy and consider adding it to an allowlist if it is deemed safe.
-- Newly registered domains for legitimate purposes, such as marketing campaigns or new product launches, might trigger alerts. Users can monitor these domains for a period to ensure they are not associated with malicious activity before excluding them.
-- Internal development or testing environments often use unique domain names that could be flagged. Users should document these environments and exclude their domains from the detection rule to prevent unnecessary alerts.
-- Third-party services or APIs that are not widely recognized might be misidentified as threats. Users should confirm the service's authenticity and functionality, then create exceptions for these domains if they are verified as non-threatening.
-- Temporary or one-time use domains for legitimate purposes, such as event registrations or surveys, may cause false positives. Users should assess the context and frequency of access to these domains and exclude them if they are determined to be safe.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further communication with the suspicious domain.
-- Conduct a thorough investigation of the system to identify any malicious processes or files, focusing on indicators of initial access, persistence, command-and-control, or exfiltration activities.
-- Analyze network logs and DNS queries to determine the scope of the incident and identify any other systems that may have communicated with the unusual domain.
-- Remove any identified malware or unauthorized software from the affected system and ensure all security patches are up to date.
-- Change passwords and credentials that may have been compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger attack campaign.
-- Implement enhanced logging and monitoring policies to capture detailed network and DNS activity for future investigations.
-- Integrate threat intelligence feeds to improve detection of rare or suspicious domains in real-time.
-- Restore the system to its operational state by verifying the integrity of critical files and applications, and ensure all security measures are re-enabled.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and prevent future incidents."""
 
diff --git a/rules/ml/ml_rare_destination_country.toml b/rules/ml/ml_rare_destination_country.toml
index 2bb9293d248..3f293cd15f6 100644
--- a/rules/ml/ml_rare_destination_country.toml
+++ b/rules/ml/ml_rare_destination_country.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -79,48 +79,4 @@ rule_id = "35f86980-1fb1-4dff-b311-3be941549c8d"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Traffic to Rare Destination Country
-
-The detection of network traffic to uncommon destination countries leverages machine learning to identify anomalies in network logs. Adversaries exploit this by directing traffic to servers in atypical locations for activities like data exfiltration or command-and-control communication. This detection rule flags such anomalies, helping analysts investigate potential threats that deviate from normal business operations.
-
-### Possible investigation steps
-
-- Review the alert details to identify the rare destination country and the associated network traffic logs.
-- Examine the source IP address and user account involved in the alert to determine if they are legitimate and expected within the network.
-- Check historical network logs to see if there have been previous connections to the same destination country from the same source IP or user account.
-- Analyze the time and frequency of the connections to the rare destination country to identify any patterns or anomalies.
-- Investigate the domain or IP address of the destination server to determine if it is associated with known malicious activity or threat actors.
-- Use Osquery to gather additional context on the source machine. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<destination IP>';`
-- Correlate the network traffic with other security events, such as endpoint detection alerts, to identify any related suspicious activities.
-- Check for any recent changes or unusual behavior in the user account or device associated with the alert, such as new software installations or configuration changes.
-- Consult threat intelligence sources to gather information on the rare destination country and any known threats or campaigns targeting that region.
-- Document all findings and observations to build a comprehensive understanding of the potential threat and to assist in further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Legitimate business operations may occasionally involve communication with servers in rare destination countries, such as when a company expands its operations internationally or engages with new global partners. These activities can trigger false positives.
-- Automated software updates or cloud services might route traffic through servers located in uncommon countries, leading to benign alerts.
-- Employees traveling internationally and accessing company resources from unusual locations can also result in false positives.
-- To manage these false positives, users can create exceptions for known and verified business activities that involve rare destination countries, ensuring these are documented and regularly reviewed.
-- Implementing a whitelist of trusted IP addresses or domains associated with legitimate services and partners can help reduce unnecessary alerts.
-- Regularly updating the list of known business-related destinations and incorporating feedback from network analysts can further refine the detection rule and minimize false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further data exfiltration or communication with command-and-control servers.
-- Conduct a thorough investigation of the network logs to identify the scope of the anomaly and determine if other systems are affected.
-- Analyze the network traffic to the rare destination country to understand the nature of the communication and identify any malicious payloads or commands.
-- Review user activity and access logs to identify any unauthorized access or suspicious behavior that may have led to the anomaly.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and action.
-- Implement enhanced logging policies to capture detailed network traffic data, including destination IP addresses and geolocation information, for future investigations.
-- Integrate threat intelligence feeds to correlate the detected anomaly with known threat actors or campaigns targeting similar organizations.
-- Restore affected systems to their operational state by removing any malicious software and applying necessary security patches.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and stricter access controls.
-- Update security awareness training for employees to recognize phishing attempts and other social engineering tactics that could lead to similar incidents."""
 
diff --git a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
index 1cc41bb91f9..cc7adf6f4f9 100644
--- a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -85,50 +85,6 @@ tags = [
     "Tactic: Execution",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Windows Path Activity
-
-In corporate Windows environments, software is typically installed in standard directories, and deviations can signal potential threats. Adversaries exploit this by executing malware from non-standard paths like user or temporary directories, bypassing traditional security measures. The 'Unusual Windows Path Activity' rule detects such anomalies, flagging processes initiated from these atypical locations, thus aiding in identifying unauthorized or malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name, path, and user account associated with the unusual activity.
-- Check the process's parent process to understand how it was initiated, using fields like `parent_process_name` and `parent_process_id`.
-- Investigate the file path from which the process was executed to determine if it is a known or expected location for legitimate software.
-- Use Osquery to gather more information about the file, such as its hash, size, and creation date, with a query like: `SELECT path, md5, sha256, size, ctime FROM file WHERE path = '<unusual_path>';`.
-- Examine the file's metadata and digital signature to verify its authenticity and origin.
-- Cross-reference the process and file details with threat intelligence sources to check for known malicious indicators.
-- Analyze recent user activity on the system to identify any downloads or installations that coincide with the alert.
-- Review system logs for any network connections initiated by the process to external IP addresses or domains.
-- Check for any persistence mechanisms that may have been established by the process, such as registry modifications or scheduled tasks.
-- Consult with the user associated with the alert to gather additional context about their recent activities and any software installations they may have performed.
-
-### False positive analysis
-
-- Legitimate software updates: Some legitimate software may update themselves by downloading new versions to temporary directories before installation. Users can create exceptions for known update processes to prevent false positives.
-- Development environments: Developers often compile and test software in user directories, which can trigger alerts. Excluding specific development tools or directories used by developers can reduce unnecessary alerts.
-- Portable applications: These applications run from user directories without installation. Users should whitelist trusted portable applications to avoid false positives.
-- User-installed software: In some environments, users may have permission to install software in their own directories. Identifying and excluding these known applications can help manage alerts.
-- Automated scripts: Scheduled tasks or scripts that run from user directories for legitimate purposes can be flagged. Users should document and exclude these scripts to prevent false positives.
-- Security tools: Some security tools may execute from non-standard paths for scanning or remediation purposes. Whitelisting these tools can prevent them from being flagged as threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation to identify the process and its origin, using endpoint detection and response (EDR) tools to trace the execution path and any associated files.
-- Terminate any suspicious processes identified as originating from atypical directories, such as user or temporary folders.
-- Remove or quarantine any malicious files or scripts found during the investigation to prevent re-execution.
-- Review and analyze system logs to determine if there are any other indicators of compromise or related activities, leveraging MITRE ATT&CK framework for threat context.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is determined to be part of a larger attack campaign or if additional expertise is required.
-- Restore the system to its operational state by reinstalling affected software from trusted sources and applying the latest security patches.
-- Implement or enhance logging policies to capture detailed process execution data, focusing on atypical directories to improve future detection capabilities.
-- Integrate threat intelligence feeds and automated alerting systems to enhance the detection of similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting execution permissions in user and temporary directories."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/persistence_ml_windows_anomalous_service.toml b/rules/ml/persistence_ml_windows_anomalous_service.toml
index f655f236beb..63938309c94 100644
--- a/rules/ml/persistence_ml_windows_anomalous_service.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,47 +82,6 @@ tags = [
     "Tactic: Persistence",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Windows Service
-Windows services are crucial for running background processes and applications. Adversaries exploit this by creating or modifying services to maintain persistence or execute unauthorized actions. The 'Unusual Windows Service' detection rule leverages machine learning to identify atypical services, flagging potential threats by comparing against known service baselines, thus aiding in early detection of malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific service name, service path, and the host where the unusual service was detected.
-- Check the service's creation or modification timestamp to determine when the service was installed or altered.
-- Investigate the service's executable path to verify its legitimacy and check for any known malicious file signatures or hashes.
-- Use Osquery to gather additional information about the service with a query like: `SELECT name, display_name, path, start_type, status FROM services WHERE name = '<service_name>';` to confirm its current state and configuration.
-- Cross-reference the service name and executable path against known good baselines or whitelists to identify any deviations.
-- Examine the parent process that created or modified the service to understand the context of its creation.
-- Analyze the user account under which the service is running to determine if it has the necessary privileges and if the account has been compromised.
-- Review recent system and security logs on the affected host for any related suspicious activities or anomalies around the time the service was created or modified.
-- Check for any network connections initiated by the service to identify potential command and control communication or data exfiltration.
-- Consult threat intelligence sources to see if the service name, path, or associated file hashes have been reported in any recent threat campaigns or advisories.
-
-### False positive analysis
-
-- Known false positives for the Unusual Windows Service rule often include legitimate software updates or installations that create temporary services, as well as custom in-house applications that are not widely recognized by the machine learning model.
-- To manage these false positives, users can create exceptions for specific services that are known to be safe and frequently appear in their environment. This can be done by maintaining a whitelist of approved services or by configuring the detection rule to ignore certain service names or patterns.
-- It's important to regularly review and update the list of exceptions to ensure that new legitimate services are not mistakenly flagged as threats, while also ensuring that the list does not become overly permissive, which could allow actual threats to go undetected.
-- Users should also consider the context of the flagged service, such as the time of day it was created or modified, the user account associated with the change, and any related network activity, to better assess whether it is a false positive or a potential threat.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized services.
-- Conduct a thorough investigation of the unusual service, including its origin, purpose, and any associated files or processes.
-- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
-- Remove or disable the unauthorized service and any associated files or registry entries to eliminate the threat.
-- Restore the system from a known good backup if the integrity of the system is in question.
-- Escalate the incident to the security operations team or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed information on service creation and modification activities for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for unusual service activities.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
index fc6945554be..6d718fc767f 100644
--- a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
+++ b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 75
@@ -84,52 +84,6 @@ tags = [
     "Tactic: Privilege Escalation",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Sudo Activity
-
-Sudo allows users to execute commands with elevated privileges, essential for system administration. However, adversaries may exploit this by using compromised credentials to gain unauthorized access. The 'Unusual Sudo Activity' detection rule identifies anomalies in sudo usage patterns, flagging potential misuse by comparing current activity against typical user behavior, thus aiding in early threat detection.
-
-### Possible investigation steps
-
-- Review the alert details to identify the user account involved in the unusual sudo activity and the specific command executed.
-- Check the timestamp of the activity to determine if it aligns with the user's typical working hours or if it occurred at an unusual time.
-- Analyze the user's historical sudo usage patterns to assess whether this activity deviates from their normal behavior.
-- Verify the source IP address and hostname from which the sudo command was executed to ensure it matches the user's known devices and locations.
-- Cross-reference the user's recent login history to identify any suspicious logins or anomalies around the time of the sudo activity.
-- Use Osquery to gather additional context on the system where the sudo command was executed. For example, run the following query to list recent sudo commands:
-  ```sql
-  SELECT uid, user, command, time FROM sudo_log WHERE user = '<username>';
-  ```
-- Investigate any recent changes to the user's account, such as password resets or modifications to group memberships, that could indicate account compromise.
-- Check for any other security alerts or logs related to the user or system around the same timeframe to identify potential correlated activities.
-- Review the system's audit logs for any unauthorized changes or suspicious activities that occurred before or after the unusual sudo command.
-- Consult with the user, if possible, to verify whether they performed the action and to gather additional context about the necessity and legitimacy of the command.
-
-### False positive analysis
-
-- Known false positives for the Unusual Sudo Activity rule often arise from legitimate administrative tasks performed by users who do not typically require elevated privileges, such as developers or support staff temporarily granted sudo access for troubleshooting.
-- Another common false positive occurs when system updates or maintenance scripts are executed by service accounts that do not usually perform such actions, leading to flagged activity.
-- To manage these false positives, users can create exceptions for specific user accounts or groups that are known to perform these tasks regularly, ensuring that their activity is not flagged as unusual.
-- Implementing a baseline of normal sudo activity for each user or role can help in distinguishing between legitimate and suspicious actions, reducing the likelihood of false positives.
-- Regularly reviewing and updating the list of exceptions and baselines is crucial, as user roles and responsibilities may change over time, potentially altering what constitutes normal sudo activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the sudo activity by contacting the user involved and reviewing their recent activities and access needs.
-- Conduct a thorough investigation of the system logs to identify any unauthorized changes or additional suspicious activities, focusing on the time frame of the unusual sudo activity.
-- Reset passwords for the affected user account and any other accounts that may have been compromised, ensuring the use of strong, unique passwords.
-- Escalate the incident to the security operations team if evidence of a broader compromise is found, such as multiple accounts affected or signs of data exfiltration.
-- Implement enhanced logging policies to capture detailed sudo command usage and user activity, ensuring logs are stored securely and retained for an appropriate period.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate unusual sudo activity with known threat indicators and patterns.
-- Restore the system to its operational state by verifying the integrity of critical system files and configurations, and applying any necessary patches or updates.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Implement hardening measures such as enforcing the principle of least privilege, using multi-factor authentication, and regularly reviewing user access rights to minimize the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
index a48655d3f6f..e996d8761c8 100644
--- a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
+++ b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,49 +82,6 @@ tags = [
     "Tactic: Privilege Escalation",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Windows User Privilege Elevation Activity
-
-In Windows environments, privilege elevation is often achieved using tools like 'runas', typically by administrators. Adversaries exploit this by hijacking accounts to gain elevated access, posing risks of data breaches or system compromise. The detection rule leverages machine learning to identify atypical user context switches, flagging potential misuse indicative of account takeover or unauthorized privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account involved in the unusual privilege elevation activity.
-- Check the timestamp of the activity to correlate it with any known scheduled tasks or administrative activities.
-- Examine the source and destination IP addresses associated with the activity to determine if they are part of the organization's network or if they are external.
-- Investigate the command line used in the privilege elevation attempt, focusing on any unusual or suspicious parameters.
-- Analyze the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior.
-- Use Osquery to gather additional context on the system where the activity was detected. For example, run the following query to list recent processes executed by the user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
-- Check for any recent changes to the user's account, such as password resets or changes in group memberships, that could indicate account compromise.
-- Review system and security event logs for any additional suspicious activities around the time of the alert, such as failed login attempts or changes to security settings.
-- Investigate any other alerts or incidents involving the same user or system to identify potential patterns or related activities.
-- Consult with the user or their manager to verify if the activity was legitimate and authorized, ensuring to document any findings or explanations provided.
-
-### False positive analysis
-
-- Regular administrative tasks: Frequent use of the 'runas' command by legitimate domain or network administrators for routine maintenance can trigger false positives. Users can manage this by creating exceptions for known administrator accounts or specific tasks that are regularly performed.
-- Scheduled tasks or scripts: Automated scripts or scheduled tasks that require privilege elevation might be flagged. To handle this, users can whitelist these scripts or tasks by identifying their unique signatures or execution patterns.
-- Software updates or installations: Legitimate software updates or installations that require elevated privileges can be mistaken for suspicious activity. Users should consider excluding known update processes or installation paths from the detection rule.
-- Development and testing environments: Developers or testers might frequently switch user contexts to simulate different user roles, leading to false positives. In such cases, users can exclude specific development or testing environments from monitoring.
-- Third-party management tools: Some third-party tools that manage user accounts or perform administrative tasks might mimic privilege elevation activities. Users can address this by identifying and excluding these tools from the detection scope.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the privilege escalation, focusing on recent account activity and any anomalies in user behavior.
-- Reset passwords for compromised accounts and enforce multi-factor authentication (MFA) to prevent future unauthorized access.
-- Review and update user access controls, ensuring that only necessary privileges are granted to users based on their roles.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed user activity, including command execution and privilege changes, to aid in future investigations.
-- Integrate security information and event management (SIEM) tools with endpoint detection and response (EDR) solutions to improve threat detection and response capabilities.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary services, applying the principle of least privilege, and conducting regular security audits to reduce the risk of future incidents."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
diff --git a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
index 62da98d8b9b..e3878144a51 100644
--- a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
+++ b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/18"
 
 [rule]
 anomaly_threshold = 50
@@ -85,49 +85,6 @@ tags = [
     "Tactic: Resource Development",
 ]
 type = "machine_learning"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Anomalous Linux Compiler Activity
-
-Compilers transform source code into executable programs, a routine task in development environments. However, in atypical user contexts, such activity may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit compilers to deploy malware or execute exploits. The detection rule identifies unusual compiler usage patterns, flagging potential threats by monitoring deviations from normal user behavior.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user and host involved in the anomalous compiler activity.
-- Check the historical activity of the user to determine if compiler usage is indeed unusual for this user context.
-- Analyze the specific compiler command executed, including any flags or options, to understand the nature of the compilation.
-- Investigate the source code or files being compiled to assess if they are legitimate or potentially malicious.
-- Use Osquery to gather additional context on the host. For example, run the following query to list recent processes executed by the user: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<username>';`
-- Examine the file system for any newly created or modified executable files that may have resulted from the compilation.
-- Check for any recent privilege escalation attempts or suspicious activities in system logs that coincide with the compiler activity.
-- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern.
-- Verify the integrity and origin of the compiler binary used to ensure it has not been tampered with or replaced.
-- Consult threat intelligence sources to determine if the observed activity matches known tactics, techniques, or procedures (TTPs) associated with adversaries.
-
-### False positive analysis
-
-- Development environments or users who occasionally compile software for legitimate purposes may trigger false positives. To manage this, users can create exceptions for specific user accounts or directories known for regular development activities.
-- Automated build systems or continuous integration pipelines that compile code as part of their routine operations might be flagged. Exclude these systems by identifying their unique user accounts or IP addresses and adding them to an allowlist.
-- System updates or package installations that involve compiling components can also be mistaken for anomalous activity. Users should monitor and document regular update schedules and exclude these activities during known maintenance windows.
-- Educational or research environments where users compile code for learning or experimentation may generate alerts. Implement user-specific exceptions based on the context of their activities and the educational tools they use.
-- Temporary projects or one-time tasks that require compilation might be misinterpreted as threats. Users can temporarily disable the rule or add time-bound exceptions for these specific tasks to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
-- Conduct a thorough investigation to identify the source and scope of the anomalous compiler activity, reviewing logs and user activity to determine if it aligns with known threat patterns such as those described in MITRE ATT&CK T1588.
-- Verify the integrity of critical system files and executables to ensure they have not been altered or replaced by malicious versions.
-- Remove any unauthorized software or malware identified during the investigation, using trusted antivirus or anti-malware tools.
-- Reset credentials and review user permissions to ensure no unauthorized privilege escalations have occurred.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is linked to a broader attack campaign or if sensitive data may have been compromised.
-- Implement enhanced logging policies to capture detailed information on compiler usage and other potentially suspicious activities for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities against similar threats.
-- Restore the system to its operational state by applying verified backups and patches, ensuring all security updates are current.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and stricter access controls, to prevent recurrence."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
index e0344f36c68..d30f431fda5 100644
--- a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
+++ b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -49,49 +49,6 @@ query = '''
         flow_terminated or timeout or Reject or network_flow)
     and destination.port:23
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Accepted Default Telnet Port Connection
-
-Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing adversaries to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that aren't blocked or terminated, which may indicate unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of Telnet traffic on port 23, focusing on the `destination.port` field to ensure it matches the expected port for Telnet.
-- Examine the `event.dataset` and `event.category` fields to understand the context of the network traffic and confirm it is related to network flow or traffic.
-- Check the `event.type` field to verify that the event is categorized as a connection, indicating an active Telnet session attempt.
-- Investigate the `event.action` field to ensure that the connection was not blocked or terminated, which could suggest a successful unauthorized access attempt.
-- Identify the source and destination IP addresses involved in the connection to determine if they are known or expected within the network environment.
-- Use Osquery to gather more information about the systems involved. For example, run the following query to list active network connections on the potentially compromised host: `SELECT * FROM process_open_sockets WHERE remote_port = 23;`
-- Analyze historical network traffic logs to identify any patterns or repeated attempts to connect via Telnet from the same source IP address.
-- Correlate the Telnet connection event with other security events or logs to identify any related suspicious activities, such as failed login attempts or unusual user account behavior.
-- Investigate the user accounts involved in the Telnet session to determine if they have been compromised or are being used in an unauthorized manner.
-- Review the configuration and patch status of the systems involved to assess their vulnerability to exploitation via Telnet and ensure they are not inadvertently exposed to the internet.
-
-### False positive analysis
-
-- **Legacy Systems and Devices**: Some organizations may still use legacy systems or network devices that rely on Telnet for management purposes. These systems can generate legitimate Telnet traffic that is mistakenly flagged as suspicious. Users should identify these systems and create exceptions for their IP addresses or hostnames to prevent false positives.
-- **Internal Network Management**: In certain environments, Telnet might be used internally for network management tasks. If these activities are verified as secure and necessary, users can exclude specific internal IP ranges from the detection rule to reduce false alerts.
-- **Testing and Development Environments**: Telnet might be used in controlled testing or development environments where security risks are mitigated. Users should document these environments and apply exceptions to avoid unnecessary alerts.
-- **Automated Scripts and Tools**: Some automated scripts or network management tools might use Telnet for legitimate purposes. Users should review these tools and, if deemed safe, whitelist their traffic to minimize false positives.
-- **Vendor-Specific Implementations**: Certain vendors may implement Telnet in a way that is secure within a closed network. Users should assess these implementations and, if they meet security standards, exclude them from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the Telnet connection, including reviewing logs and network traffic for any suspicious activity.
-- Change all passwords associated with the affected system and any other systems that may have been accessed using the same credentials.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement network segmentation to limit the exposure of legacy systems and ensure Telnet is not accessible from the internet.
-- Disable Telnet services on all systems where it is not absolutely necessary, and replace it with secure alternatives like SSH.
-- Enhance logging policies to ensure all network traffic, especially on critical ports like 23, is monitored and logged for future analysis.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the affected system from a known good backup to ensure no malicious code remains.
-- Apply system hardening measures, such as disabling unnecessary services and applying the latest security patches, to reduce the risk of future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_cobalt_strike_beacon.toml b/rules/network/command_and_control_cobalt_strike_beacon.toml
index b6628c96e38..be14096630a 100644
--- a/rules/network/command_and_control_cobalt_strike_beacon.toml
+++ b/rules/network/command_and_control_cobalt_strike_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -22,52 +22,7 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Cobalt Strike Command and Control Beacon"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Cobalt Strike Command and Control Beacon
-
-Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using obfuscated network traffic. The detection rule identifies suspicious domain patterns typical of Cobalt Strike beacons, focusing on specific network events and domain structures indicative of C2 activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific network event and domain pattern that triggered the rule, focusing on the `destination.domain` field for suspicious domain structures.
-- Examine the network traffic logs associated with the alert, particularly those categorized under `event.category: network` or `network_traffic`, and `type: tls` or `http`, to identify any unusual patterns or anomalies.
-- Cross-reference the `destination.domain` with known malicious domains or threat intelligence feeds to determine if it has been previously associated with Cobalt Strike or other malicious activities.
-- Use Osquery to gather additional context on the affected host. For example, run the following query to list all network connections on the host: `SELECT * FROM process_open_sockets WHERE remote_address LIKE '%stage.%';`
-- Investigate the process responsible for the network connection by correlating the `process.pid` from the Osquery results with process execution logs to identify the parent process and any associated command-line arguments.
-- Analyze historical network traffic to determine if the suspicious domain has been contacted previously, indicating a potential ongoing C2 communication.
-- Check for any other alerts or logs related to the same `destination.domain` or IP address to assess the scope and potential impact of the activity.
-- Review endpoint security logs for any signs of suspicious activity or indicators of compromise on the affected host, such as unusual process executions or file modifications.
-- Investigate user activity on the affected host around the time of the alert to identify any unauthorized access or actions that may have facilitated the C2 communication.
-- Consult with threat intelligence teams or resources to gather additional insights or context about the specific Cobalt Strike variant or campaign potentially involved in the alert.
-
-### False positive analysis
-
-- Legitimate software updates or patch management systems may generate network traffic patterns similar to Cobalt Strike beacons, especially if they use automated scripts or tools that follow a predictable domain structure.
-- Content delivery networks (CDNs) and cloud services often use domain names that match the pattern detected by the rule, leading to potential false positives when these services are accessed frequently.
-- Internal development or testing environments might use domain naming conventions that inadvertently match the suspicious pattern, particularly if they employ automated deployment or staging processes.
-- To manage these false positives, users can create exceptions for known benign domains or IP addresses that consistently trigger the rule but are verified as non-threatening.
-- Implementing a whitelist of trusted domains or services can help reduce noise from false positives, allowing security teams to focus on genuine threats.
-- Regularly reviewing and updating the list of exceptions is crucial to ensure that new legitimate services are not mistakenly flagged as malicious.
-
-### Response and remediation
-
-- Isolate the affected systems from the network to prevent further communication with the command and control server.
-- Conduct a thorough investigation to identify the scope of the compromise, including all affected systems and data.
-- Utilize endpoint detection and response (EDR) tools to analyze and remove Cobalt Strike beacons and any associated malware.
-- Review and analyze network traffic logs to identify any additional indicators of compromise (IOCs) and ensure no other systems are affected.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed network and endpoint activity for future investigations.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
-- Restore affected systems from clean backups and ensure all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement network segmentation and hardening measures to reduce the attack surface and prevent similar incidents.
-
-## Threat intel
+note = """## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
index de596cf9df8..6086b36e1b0 100644
--- a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
+++ b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/05"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -18,50 +18,7 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Default Cobalt Strike Team Server Certificate"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Default Cobalt Strike Team Server Certificate
-
-Cobalt Strike is a tool used for simulating advanced cyber threats, often employed in security testing. However, adversaries can exploit its default server certificate to establish covert command and control channels. The detection rule identifies this misuse by monitoring network traffic for specific cryptographic hashes associated with the default certificate, flagging potential unauthorized activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the default Cobalt Strike Team Server Certificate by checking the cryptographic hashes: MD5, SHA1, and SHA256.
-- Correlate the alert with other network traffic logs to identify the source and destination IP addresses involved in the communication.
-- Use Packetbeat or a similar tool to capture and analyze the network packets associated with the alert to understand the context of the communication.
-- Investigate the source IP address to determine if it belongs to a known or trusted entity within the organization or if it is an external or suspicious address.
-- Check historical logs to see if the same cryptographic hashes have been detected previously, indicating a persistent or recurring issue.
-- Utilize Osquery to gather more information about the systems involved. For example, run the following query to check for any suspicious processes or network connections on the host: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%cobalt%' OR cmdline LIKE '%cobalt%';`
-- Examine the destination IP address for any known associations with malicious activities or threat actor infrastructure.
-- Investigate any related user accounts or credentials that may have been used in the communication to assess potential compromise.
-- Review any associated DNS queries or domain names to identify if they are linked to known malicious domains or C2 infrastructure.
-- Cross-reference the alert with threat intelligence feeds to determine if the detected activity aligns with known threat actor tactics, techniques, and procedures (TTPs).
-
-### False positive analysis
-
-- Legitimate security testing activities: Organizations conducting authorized penetration tests or red team exercises may use Cobalt Strike with its default server certificate, triggering the detection rule. Users should verify the legitimacy of such activities and consider excluding known testing IP addresses or domains from the rule to prevent false positives.
-- Misconfigured security tools: Some security tools or network monitoring solutions might inadvertently use the default Cobalt Strike certificate for testing or demonstration purposes. Users should ensure these tools are correctly configured and exclude their traffic from the rule if necessary.
-- Internal training environments: Training environments that simulate cyber threats for educational purposes might use the default certificate. Users can manage this by creating exceptions for specific training network segments or IP ranges.
-- Legacy systems or software: Older systems or software that have not been updated might still use the default certificate for compatibility reasons. Users should identify these systems and either update them or exclude their traffic from the detection rule to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further command and control communication.
-- Conduct a thorough investigation to confirm the presence of Cobalt Strike by analyzing network traffic and system logs for the identified cryptographic hashes.
-- Remove any unauthorized Cobalt Strike installations and associated malicious files from the affected systems.
-- Change all credentials and access tokens that may have been compromised during the incident.
-- Escalate the incident to the security operations center (SOC) and relevant stakeholders for further analysis and response coordination.
-- Implement enhanced logging policies to capture detailed network traffic and system events, focusing on TLS connections and certificate usage.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
-- Restore affected systems from clean backups and ensure all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement network segmentation and application whitelisting to reduce the attack surface and prevent unauthorized software execution.
-
-## Threat intel
+note = """## Threat intel
 
 While Cobalt Strike is intended to be used for penetration tests and IR training, it is frequently used by actual threat actors (TA) such as APT19, APT29, APT32, APT41, FIN6, DarkHydrus, CopyKittens, Cobalt Group, Leviathan, and many other unnamed criminal TAs. This rule uses high-confidence atomic indicators, so alerts should be investigated rapidly."""
 references = [
diff --git a/rules/network/command_and_control_download_rar_powershell_from_internet.toml b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
index 8a4d24846e8..353a1460eec 100644
--- a/rules/network/command_and_control_download_rar_powershell_from_internet.toml
+++ b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -23,54 +23,7 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*",
 language = "kuery"
 license = "Elastic License v2"
 name = "Roshal Archive (RAR) or PowerShell File Downloaded from the Internet"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet
-
-RAR files and PowerShell scripts are powerful tools in IT environments, used for compression and automation, respectively. However, adversaries exploit these by downloading them from the internet to deploy malicious payloads or scripts. The detection rule identifies such downloads by monitoring network traffic for specific file extensions and filtering out internal IP addresses, flagging potential threats for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to identify the source IP address and destination IP address involved in the download event. Verify if the source IP is within the internal network ranges specified in the query.
-- Check the URL extension or path to confirm whether the downloaded file is a RAR or PowerShell script, as indicated by the extensions `.ps1` or `.rar`.
-- Analyze network traffic logs to determine the volume and frequency of similar download events from the same source IP. This can help identify patterns or repeated behavior.
-- Investigate the destination IP address to determine if it is associated with known malicious activity or if it is an unusual destination for the internal network.
-- Use Osquery to gather more information about the host that initiated the download. For example, run the following query to list recent files downloaded to the system:
-  ```sql
-  SELECT * FROM file WHERE path LIKE '/path/to/downloads/%' AND (path LIKE '%.ps1' OR path LIKE '%.rar');
-  ```
-- Examine the process tree on the source host to identify the parent process that initiated the download. This can provide context on whether the download was user-initiated or automated by a script or application.
-- Check for any recent changes in the system's scheduled tasks or startup items that might indicate persistence mechanisms related to the downloaded file.
-- Review endpoint security logs for any alerts or detections related to the downloaded file, such as antivirus or EDR alerts, which might provide additional context or confirm malicious intent.
-- Correlate the event with other security alerts or incidents in the same timeframe to identify potential lateral movement or coordinated attacks.
-- Consult threat intelligence sources to gather information on the file hash or URL, if available, to determine if it is associated with known threats or campaigns.
-
-### False positive analysis
-
-- Legitimate software updates: Many software applications use RAR files or PowerShell scripts for updates or installations, which can trigger false positives. Users can create exceptions for known software update servers or domains to reduce these alerts.
-- Internal IT automation: IT departments often use PowerShell scripts for legitimate automation tasks. Monitoring and documenting these scripts can help differentiate between benign and malicious activity, allowing for specific exceptions to be made.
-- Backup and archival processes: Organizations may use RAR files for backup or archival purposes. Identifying and excluding these routine operations from the detection rule can help minimize false positives.
-- Development and testing environments: Developers might download RAR files or use PowerShell scripts for testing purposes. Establishing a list of trusted IP addresses or domains associated with development activities can help in excluding these from alerts.
-- Security tools and penetration testing: Security teams may use RAR files or PowerShell scripts as part of penetration testing or security assessments. Whitelisting known security tools and their associated IP addresses can prevent these activities from being flagged as threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
-- Conduct a thorough investigation of the downloaded RAR or PowerShell file to determine its origin and intent, using sandboxing or static analysis tools.
-- Review network logs and endpoint security alerts to identify any lateral movement or additional compromised systems.
-- Remove any malicious files or scripts identified during the investigation from the affected system.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Restore the system from a clean backup if the integrity of the system is compromised beyond repair.
-- Implement enhanced logging policies to capture detailed network traffic and endpoint activity for future incidents.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Educate users on the risks of downloading files from untrusted sources and enforce stricter download policies.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign, referencing MITRE ATT&CK T1105 for context on ingress tool transfer tactics.
-
-## Threat intel
+note = """## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_halfbaked_beacon.toml b/rules/network/command_and_control_halfbaked_beacon.toml
index 62acaa8e6ed..db956efc006 100644
--- a/rules/network/command_and_control_halfbaked_beacon.toml
+++ b/rules/network/command_and_control_halfbaked_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,51 +21,7 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Halfbaked Command and Control Beacon"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Halfbaked Command and Control Beacon
-
-Halfbaked malware exploits common network protocols like HTTP and TLS to maintain persistence and facilitate command and control (C2) communication within compromised networks. Adversaries leverage these protocols to blend malicious traffic with legitimate network activity, evading detection. The detection rule identifies suspicious TCP traffic patterns, specifically targeting HTTP requests to numeric IP addresses on common ports, indicative of Halfbaked C2 beacons.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious TCP traffic patterns, focusing on HTTP requests to numeric IP addresses on ports 53, 80, 8080, or 443.
-- Analyze the network traffic logs to identify the source and destination IP addresses involved in the suspicious activity, paying close attention to the `url.full` field for patterns matching `/http:\\/\\/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}\\/cd/`.
-- Correlate the identified IP addresses with known threat intelligence sources to determine if they are associated with malicious activity or known Halfbaked C2 infrastructure.
-- Examine the `event.dataset` and `event.category` fields to verify if the traffic is categorized under `network_traffic.tls` or `network_traffic.http`, which may indicate the use of common protocols for C2 communication.
-- Use Osquery to gather additional context on the affected host. For example, run the following query to list all network connections on the host: `SELECT * FROM process_open_sockets WHERE remote_address IN ('<suspicious_ip>');`.
-- Investigate the processes associated with the suspicious network connections by examining the process IDs and command lines to identify any unusual or unauthorized applications.
-- Check for any persistence mechanisms on the host that may be related to the Halfbaked malware, such as scheduled tasks or startup items, using Osquery: `SELECT * FROM scheduled_tasks WHERE name LIKE '%Halfbaked%';`.
-- Review historical network traffic data to determine if similar patterns of communication have occurred in the past, indicating a potential ongoing compromise.
-- Analyze any related alerts or logs from other security tools to gather additional context and corroborate the findings from the Halfbaked alert.
-- Document all findings and observations in a detailed report to support further analysis and decision-making by the security team.
-
-### False positive analysis
-
-- Legitimate applications or services that use numeric IP addresses in their HTTP requests can trigger false positives. For example, internal tools or monitoring systems that communicate with devices using IP addresses instead of domain names may be flagged.
-- Automated scripts or legacy systems that rely on numeric IP addresses for communication over common ports (53, 80, 8080, 443) might also be mistakenly identified as malicious.
-- To manage these false positives, users can create exceptions for known benign IP addresses or specific applications that are verified to use numeric IP addresses for legitimate purposes.
-- Regularly review and update the list of exceptions to ensure that only trusted sources are excluded, minimizing the risk of overlooking genuine threats.
-- Implement network segmentation and monitoring to distinguish between expected and unexpected traffic patterns, helping to refine detection rules and reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected systems from the network to prevent further communication with the command and control server.
-- Conduct a thorough investigation of the affected systems to identify the extent of the compromise and any additional indicators of compromise (IOCs).
-- Remove the Halfbaked malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools.
-- Apply patches and updates to all systems to address any vulnerabilities that may have been exploited by the malware.
-- Review and enhance firewall rules to block outbound traffic to known malicious IP addresses and domains associated with Halfbaked C2 activity.
-- Implement network segmentation to limit lateral movement within the network and protect critical assets.
-- Enable detailed logging of network traffic, especially for HTTP and TLS protocols, to improve detection of similar threats in the future.
-- Integrate threat intelligence feeds into security information and event management (SIEM) systems to stay informed about emerging threats and IOCs.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate employees on recognizing phishing attempts and other common attack vectors used to deliver malware like Halfbaked.
-
-## Threat intel
+note = """## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_nat_traversal_port_activity.toml b/rules/network/command_and_control_nat_traversal_port_activity.toml
index 360e700f00a..f61786952a2 100644
--- a/rules/network/command_and_control_nat_traversal_port_activity.toml
+++ b/rules/network/command_and_control_nat_traversal_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -35,49 +35,6 @@ type = "query"
 query = '''
 (event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and network.transport:udp and destination.port:4500
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 IPSEC NAT Traversal Port Activity
-
-IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC traffic in UDP packets, typically using port 4500. While essential for legitimate encrypted connections, adversaries exploit this to mask malicious traffic, evading detection. The detection rule identifies unusual UDP traffic on port 4500, flagging potential misuse of this technology for covert command and control activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the source and destination IP addresses, timestamps, and any associated user or device information.
-- Verify the legitimacy of the source and destination IP addresses by cross-referencing them with known internal assets or external threat intelligence sources.
-- Analyze historical network traffic logs to identify any patterns or anomalies associated with the source or destination IP addresses, focusing on previous instances of UDP traffic on port 4500.
-- Use Osquery to gather additional context on the involved systems. For example, run the following query to check for active IPSEC connections: `SELECT * FROM ipsec_status;`
-- Investigate the user or device associated with the alert to determine if there are any signs of compromise or unusual behavior, such as recent changes in user activity or system configurations.
-- Check for any other alerts or incidents related to the same source or destination IP addresses to identify potential correlations or patterns of malicious activity.
-- Examine the network flow data to determine the volume and frequency of the UDP traffic on port 4500, assessing whether it aligns with typical IPSEC NAT Traversal usage or suggests potential misuse.
-- Review firewall and intrusion detection/prevention system logs to identify any blocked or flagged traffic related to the source or destination IP addresses, which may provide additional context on the nature of the traffic.
-- Consult with network administrators to confirm whether the observed IPSEC NAT Traversal traffic is expected and authorized, particularly if the involved systems are part of known VPN configurations.
-- Document all findings and observations, including any identified anomalies or suspicious activities, to support further analysis and potential escalation if necessary.
-
-### False positive analysis
-
-- Legitimate VPN traffic: Many organizations use IPSEC NAT Traversal for secure VPN connections, which can generate expected UDP traffic on port 4500. This is a common false positive and should be considered when analyzing alerts.
-- Frequent remote access: Employees working remotely may frequently use VPNs that rely on IPSEC NAT Traversal, leading to regular traffic on port 4500. Monitoring patterns and establishing a baseline can help differentiate between normal and suspicious activity.
-- Automated network services: Some automated services or applications may use IPSEC NAT Traversal for legitimate purposes, resulting in consistent traffic that could be misinterpreted as malicious.
-- To manage false positives, users can create exceptions for known IP addresses or subnets associated with legitimate VPN endpoints. This can be done by updating the detection rule to exclude these trusted sources.
-- Regularly review and update the list of exceptions to ensure it reflects current network configurations and legitimate use cases, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further malicious activity and data exfiltration.
-- Conduct a thorough investigation of the flagged traffic to determine if it is legitimate or indicative of a compromise, using packet analysis tools to inspect the contents of the UDP traffic on port 4500.
-- Review and analyze logs from firewalls, intrusion detection systems, and VPN gateways to identify any patterns or anomalies associated with the suspicious IPSEC NAT Traversal traffic.
-- If malicious activity is confirmed, identify and remove any malware or unauthorized software from the affected systems using updated antivirus and anti-malware tools.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed network traffic data, focusing on VPN and NAT traversal activities, to improve future detection capabilities.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and enrich data for more effective threat detection and response.
-- Restore affected systems from clean backups, ensuring that all security patches and updates are applied to prevent exploitation of known vulnerabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement network segmentation and access controls to limit the potential impact of future incidents and reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_port_26_activity.toml b/rules/network/command_and_control_port_26_activity.toml
index b19d886482c..2a01401278b 100644
--- a/rules/network/command_and_control_port_26_activity.toml
+++ b/rules/network/command_and_control_port_26_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -36,49 +36,6 @@ type = "query"
 query = '''
 (event.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:26
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SMTP on Port 26/TCP
-
-SMTP, typically operating on port 25, is crucial for email transmission. However, port 26 is often used to avoid conflicts or restrictions on port 25. Adversaries exploit this by using port 26 for covert command and control, as seen with the BadPatch malware. The detection rule identifies suspicious activity by monitoring TCP traffic on port 26, focusing on network flow and SMTP-related events, thus helping to uncover potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of SMTP traffic on TCP port 26 by examining the `destination.port` field.
-- Analyze the `event.dataset` field to determine if the traffic is associated with `network_traffic.flow` or `zeek.smtp`, which can provide insights into the nature of the traffic.
-- Check the `event.category` field for values like `network` or `network_traffic` to understand the context of the event.
-- Investigate the source and destination IP addresses involved in the alert to identify any known malicious actors or unusual communication patterns.
-- Use network flow data to assess the volume and frequency of SMTP traffic on port 26, looking for anomalies or spikes in activity.
-- Correlate the alert with other security events or logs to identify any related suspicious activities or patterns.
-- Examine historical data to determine if this behavior is new or part of a recurring pattern, which might indicate a persistent threat.
-- Utilize Osquery to gather additional context from the affected systems. For example, run the following Osquery query to check for processes listening on port 26: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM listening_ports WHERE port = 26 AND protocol = 'tcp');`
-- Investigate any associated user accounts or credentials that may have been used in the communication to identify potential compromise or misuse.
-- Consult threat intelligence sources to check for any known indicators of compromise (IOCs) related to the IP addresses, domains, or other artifacts observed in the alert.
-
-### False positive analysis
-
-- Legitimate mail transfer agents: Some organizations use port 26 for legitimate email traffic to avoid conflicts with port 25. This can result in false positives when these agents are detected by the rule.
-- Internal testing environments: Development or testing environments may use port 26 for SMTP traffic, leading to benign alerts.
-- Network misconfigurations: Misconfigured network devices or services might inadvertently use port 26, triggering the rule without malicious intent.
-- To manage these false positives, users can create exceptions for known IP addresses or domains associated with legitimate mail transfer agents or internal environments.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further command and control communication.
-- Conduct a thorough investigation of the network traffic logs to identify any other systems that may be communicating over port 26.
-- Utilize endpoint detection and response (EDR) tools to scan the affected system for the presence of BadPatch malware or any other suspicious activity.
-- Remove any identified malware from the affected system using updated antivirus or anti-malware tools.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed network traffic and SMTP-related events for future investigations.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are properly set.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement network segmentation and access controls to limit the use of non-standard ports and reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
index da8e8be7a19..e9e59ab3aeb 100644
--- a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
+++ b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -74,49 +74,6 @@ query = '''
     192.168.0.0/16
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 RDP (Remote Desktop Protocol) from the Internet
-
-RDP enables remote access to systems, facilitating administrative tasks and resource sharing. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit RDP for initial access or persistence. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from non-private IPs, flagging potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the source IP address is indeed from a non-private range, as specified in the query, and verify if it is known or expected to access the network.
-- Check historical logs for any previous connections from the same source IP to determine if this is a recurring event or a new occurrence.
-- Analyze the destination IP address within the private range to identify the specific system being accessed and determine its role and importance within the network.
-- Investigate the user accounts associated with the RDP session to ensure they are legitimate and authorized to access the system remotely.
-- Utilize Osquery to gather more information about the RDP service on the destination machine. For example, run the following query to list active RDP sessions: `SELECT * FROM logged_in_users WHERE tty = 'rdp-tcp';`
-- Examine the network traffic logs for any unusual patterns or anomalies around the time of the alert, such as large data transfers or connections to other suspicious IP addresses.
-- Cross-reference the alert with any recent changes or updates to the system or network configuration that might explain the RDP exposure.
-- Check for any other security alerts or incidents involving the same source or destination IP addresses to identify potential patterns or coordinated attacks.
-- Review the system's security settings and logs for any signs of compromise, such as unauthorized changes to firewall rules or user account settings.
-- Consult threat intelligence sources to determine if the source IP address or any related indicators are associated with known malicious activity or threat actors.
-
-### False positive analysis
-
-- **Internal Testing and Monitoring**: Organizations may conduct legitimate RDP sessions from external IPs for testing or monitoring purposes. To manage this, users can create exceptions for known IP addresses used by their IT or security teams.
-- **Third-Party Vendors**: Some businesses rely on third-party vendors for remote support or maintenance, which may involve RDP access from external IPs. Users should whitelist the IP addresses of trusted vendors to prevent false positives.
-- **Remote Workforce**: Employees working remotely might use RDP to access internal resources. If these connections are from known and secure locations, their IPs can be added to an exception list.
-- **Cloud Services**: Connections from cloud service providers might be flagged if they are not part of the internal network. Users should identify and exclude IP ranges associated with their cloud services to avoid false alerts.
-- **VPN Misconfigurations**: If a VPN is not properly configured, RDP traffic might appear to originate from an external IP. Ensuring correct VPN setup and excluding known VPN IPs can help mitigate this issue.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Verify the alert by checking logs and network traffic to confirm the presence of unauthorized RDP connections.
-- Change all passwords associated with the affected system and any accounts that may have been compromised.
-- Conduct a thorough investigation to identify the source of the unauthorized access and any potential lateral movement within the network.
-- Remove any unauthorized users or backdoors that may have been installed by the attacker.
-- Restore the system from a known good backup to ensure no malicious software remains.
-- Implement network segmentation to limit RDP access to only necessary internal IP addresses.
-- Enable and configure logging for RDP access attempts and integrate with a Security Information and Event Management (SIEM) system for real-time monitoring.
-- Apply security patches and updates to the affected system and ensure all systems are regularly updated.
-- Review and update firewall rules to block RDP traffic from the internet and consider using a VPN for secure remote access."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
index ec782d37792..db915e0a059 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -70,52 +70,6 @@ query = '''
     192.168.0.0/16
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 VNC (Virtual Network Computing) from the Internet
-
-VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC to establish backdoors or gain initial access. The detection rule identifies suspicious VNC traffic by monitoring TCP connections on specific ports, filtering out trusted internal IPs, and flagging external sources attempting to connect to internal networks.
-
-### Possible investigation steps
-
-- Review the alert details to identify the source IP address attempting to connect to the internal network. Verify if the source IP is external and not part of the trusted internal IP ranges specified in the detection rule.
-- Check the destination IP address within the internal network to determine which system is being targeted. Confirm if this system is expected to have VNC services running.
-- Analyze the destination port (between 5800 and 5810) to verify if it corresponds to a known VNC service. Cross-reference with internal documentation to ensure this port is intended for VNC use.
-- Investigate the network traffic flow by examining the event dataset and category fields to understand the context of the connection attempt. Determine if there are any patterns or anomalies in the traffic.
-- Use Osquery to gather more information about the targeted system. Execute the following query to check for active VNC processes:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%vnc%';
-  ```
-- Review historical logs to identify any previous connection attempts from the same source IP address. Determine if this is part of a larger pattern of suspicious activity.
-- Correlate the alert with other security events or alerts to identify potential coordinated attacks or related incidents.
-- Check for any recent changes in firewall or network configurations that might have inadvertently exposed VNC services to the Internet.
-- Investigate user activity on the targeted system around the time of the alert to identify any unauthorized access or suspicious behavior.
-- Consult threat intelligence sources to gather information about known threat actors or campaigns that exploit VNC services, and assess if the observed activity matches any known patterns.
-
-### False positive analysis
-
-- **Internal Testing and Maintenance**: Organizations may conduct legitimate VNC testing or maintenance from external IPs, which can trigger the rule. To manage this, users can create exceptions for known testing IP addresses or timeframes.
-- **Third-Party Vendors**: External vendors may require VNC access for support or maintenance. Users should whitelist these vendor IPs after verifying their legitimacy and ensuring proper security measures are in place.
-- **Remote Workforce**: Employees working remotely might use VNC to access internal resources. To handle this, organizations can establish VPNs or secure gateways, and exclude these connections from the rule.
-- **Cloud Services**: Connections from cloud service providers might be flagged if they are used for legitimate purposes. Users should identify and exclude trusted cloud IP ranges to prevent false positives.
-- **Dynamic IP Addresses**: Some legitimate users may have dynamic IP addresses that change frequently, causing repeated false positives. Implementing a dynamic IP management strategy or using a secure access solution can help mitigate this issue.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any unauthorized access or changes made to the system.
-- Review and analyze network logs to trace the source of the VNC traffic and identify any other systems that may have been targeted or compromised.
-- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials.
-- Apply security patches and updates to the VNC software and any other vulnerable applications on the affected system.
-- Implement network segmentation to limit the exposure of critical systems to the Internet and restrict VNC access to trusted internal networks only.
-- Enhance logging and monitoring policies to capture detailed network traffic and system events, enabling quicker detection of similar threats in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve the detection and response capabilities for VNC-related threats.
-- Restore the system from a known good backup if the integrity of the system is in question, ensuring that all security patches are applied before reconnecting to the network.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans, incorporating lessons learned to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
index 04e52b37511..f7f629214dd 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -70,50 +70,6 @@ query = '''
     "FF00::/8"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 VNC (Virtual Network Computing) to the Internet
-
-VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC for initial access or as a backdoor. The detection rule identifies suspicious VNC traffic by monitoring TCP connections on specific ports from private to public IPs, flagging potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the source and destination IP addresses involved in the suspicious VNC traffic. Pay special attention to the source IP to determine if it belongs to a known internal system.
-- Verify the destination IP address to ascertain if it is a known or trusted external entity, or if it appears suspicious or unknown.
-- Check the destination port (between 5800 and 5810) to confirm it aligns with typical VNC usage, as these ports are commonly used for VNC services.
-- Investigate the source IP address within internal network logs to determine if there are any other unusual or unauthorized activities associated with this IP.
-- Use Osquery to check for VNC server processes running on the source machine. Example query: `SELECT name, path, pid FROM processes WHERE name LIKE '%vnc%';`
-- Examine historical network traffic logs to identify any previous instances of VNC traffic from the same source IP to external destinations, which might indicate a pattern of unauthorized access attempts.
-- Correlate the alert with any recent changes or updates in the network or system configurations that might have inadvertently exposed VNC services to the Internet.
-- Investigate user activity on the source machine to determine if any legitimate user actions could have triggered the VNC traffic, such as remote work or maintenance tasks.
-- Check for any known vulnerabilities or exploits related to the VNC software version running on the source machine, which could have been targeted by attackers.
-- Consult threat intelligence sources to see if the destination IP or similar VNC traffic patterns have been associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Legitimate remote work scenarios: Employees working remotely may use VNC to access their office computers. This can be a false positive if the access is authorized and secure. To manage this, create exceptions for known employee IP addresses or VPN ranges.
-- Third-party vendor access: Vendors may require VNC access for system maintenance or support. If this access is pre-approved and monitored, it can be excluded by whitelisting the vendor's IP addresses.
-- Internal testing and development: IT teams might use VNC for testing purposes, which could trigger alerts. Document and exclude these activities by specifying the IP ranges used for testing environments.
-- Misconfigured network devices: Devices that are incorrectly configured to expose VNC to the Internet might generate false positives. Regularly audit and correct device configurations to prevent unnecessary alerts.
-- Cloud-based services: Some cloud services might use VNC for legitimate purposes. Identify and whitelist these services' IP addresses to avoid false positives.
-- Temporary remote access setups: Occasionally, temporary VNC access might be set up for specific projects. Ensure these are documented and create temporary exceptions for the duration of the project.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the affected system to identify any unauthorized changes or installed backdoors, leveraging forensic tools and techniques.
-- Review and analyze network logs to trace the source of the VNC traffic and identify any other potentially compromised systems.
-- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials.
-- Apply security patches and updates to the affected system and ensure that VNC services are configured securely, including disabling direct Internet exposure.
-- Implement network segmentation to limit the exposure of critical systems and services to the Internet.
-- Enhance logging and monitoring policies to include detailed logging of remote access attempts and integrate with a Security Information and Event Management (SIEM) system for real-time analysis.
-- Escalate the incident to the security team or incident response team for further analysis and to determine if additional systems are affected.
-- Restore the system to its operational state from a known good backup, ensuring that all security measures are in place before reconnecting to the network.
-- Conduct a post-incident review to identify gaps in security controls and update the incident response plan, incorporating lessons learned and hardening measures such as disabling unused services and enforcing strong authentication mechanisms."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_network_sweep_detected.toml b/rules/network/discovery_potential_network_sweep_detected.toml
index 6c72287f691..1f4a3572f07 100644
--- a/rules/network/discovery_potential_network_sweep_detected.toml
+++ b/rules/network/discovery_potential_network_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -37,48 +37,6 @@ query = '''
 destination.port : (21 or 22 or 23 or 25 or 139 or 445 or 3389 or 5985 or 5986) and
 source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Network Sweep Detected
-
-Network sweeps are reconnaissance techniques where attackers scan networks to identify active hosts and services, often targeting common ports. This activity helps adversaries map out network vulnerabilities for future exploitation. The detection rule identifies suspicious behavior by monitoring connection attempts from a single source to multiple destinations on key ports, flagging potential reconnaissance efforts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the source IP address and the list of destination IP addresses involved in the network sweep, focusing on the `source.ip` and `destination.port` fields.
-- Verify the legitimacy of the source IP address by checking if it belongs to a known internal system or a potentially compromised device within the network.
-- Cross-reference the destination IP addresses with internal asset inventories to determine if they are critical systems or contain sensitive data.
-- Analyze historical logs to identify any previous suspicious activities associated with the source IP address, such as repeated failed login attempts or unusual data transfers.
-- Use network traffic analysis tools to inspect the packet data for the flagged connections, looking for any anomalies or patterns that suggest reconnaissance behavior.
-- Investigate the timing and frequency of the connection attempts to determine if they align with typical network usage patterns or if they indicate a deliberate scanning effort.
-- Utilize Osquery to gather additional context on the source host. For example, run the following Osquery query to check for recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address IN ('<destination_ip_1>', '<destination_ip_2>', ...);`
-- Check for any correlated alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader attack campaign.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) of specific threat actors or malware.
-- Document all findings and observations in a detailed report to facilitate further analysis and decision-making by the security team.
-
-### False positive analysis
-
-- Routine network management tasks: Network administrators often perform scans to monitor network health and identify issues. These legitimate activities can trigger the rule, leading to false positives.
-- Automated security tools: Security software and vulnerability scanners may conduct regular sweeps to ensure network security, which can be mistaken for malicious reconnaissance.
-- Internal application behavior: Some applications may communicate across multiple hosts and ports as part of their normal operation, potentially triggering the rule.
-- To manage false positives, users can create exceptions for known IP addresses or subnets associated with trusted network management tools and internal applications. This can be done by updating the detection rule to exclude these sources from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the network sweep, including reviewing logs and network traffic for any anomalies or patterns.
-- Verify the integrity of the systems involved by checking for any unauthorized changes or installations that may indicate a compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack.
-- Implement enhanced logging policies to capture detailed network traffic and connection attempts, focusing on the ports and IP ranges identified in the detection rule.
-- Integrate threat intelligence feeds to correlate the detected activity with known threat actors or campaigns, leveraging MITRE ATT&CK framework for context.
-- Restore affected systems to a known good state using backups or system images, ensuring that any potential backdoors or malware are removed.
-- Apply network segmentation and access controls to limit the exposure of critical systems and services to unauthorized scanning or access.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate staff on recognizing and reporting suspicious network activity to improve early detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_port_scan_detected.toml b/rules/network/discovery_potential_port_scan_detected.toml
index 411505251d8..718b4ef6da1 100644
--- a/rules/network/discovery_potential_port_scan_detected.toml
+++ b/rules/network/discovery_potential_port_scan_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -37,47 +37,6 @@ type = "threshold"
 query = '''
 destination.port : * and event.action : "network_flow" and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Network Scan Detected
-Network scanning is a technique used to identify open ports and services on a network, often as a precursor to an attack. Adversaries exploit this by mapping network vulnerabilities to plan intrusions. The detection rule identifies suspicious activity by monitoring for numerous connection attempts from a single source to multiple ports, indicating a potential scan. This helps in early detection and mitigation of unauthorized network probing.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the source IP address involved in the potential network scan, focusing on the private IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
-- Check the event logs for the specific event.action "network_flow" to gather more context about the network activity and verify the number of destination ports targeted.
-- Correlate the source IP address with internal asset inventories to identify the device or user associated with the IP address.
-- Analyze historical network traffic data to determine if the source IP has exhibited similar scanning behavior in the past.
-- Use Osquery to investigate the source host for any suspicious processes or network connections. Example query: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address IN ('<list of destination IPs>'));`
-- Investigate the destination ports that were targeted to identify if they correspond to critical services or known vulnerabilities.
-- Check for any other alerts or incidents involving the same source IP address to assess if this is part of a larger pattern of suspicious activity.
-- Review firewall and intrusion detection/prevention system logs to see if any blocks or alerts were triggered by the same source IP.
-- Consult threat intelligence sources to determine if the source IP or similar scanning patterns have been associated with known threat actors or campaigns.
-- Document findings and gather evidence to support further analysis or escalation if the activity is deemed malicious or part of a coordinated attack.
-
-### False positive analysis
-
-- Legitimate network monitoring tools or vulnerability scanners used by IT departments can trigger this rule as they often perform network scans to assess security posture. Users can handle these by creating exceptions for known IP addresses of authorized tools.
-- Automated backup systems or network management software that routinely check network connectivity and service availability might be flagged. To manage this, users should identify and whitelist these systems to prevent false alerts.
-- Internal network devices, such as printers or IoT devices, that periodically scan for available services or updates can also cause false positives. Users should document and exclude these devices from triggering the rule.
-- Security testing or penetration testing activities conducted by authorized personnel may mimic malicious scanning behavior. Users should coordinate with security teams to schedule these activities and temporarily adjust the rule or add exceptions for the duration of the tests.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the nature of the network scan and identify any potential breaches or compromised systems.
-- Review firewall and intrusion detection/prevention system (IDS/IPS) logs to identify the source of the scan and any other suspicious activities.
-- Block the source IP address of the scan at the network perimeter to prevent further scanning attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed network traffic and connection attempts for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics, techniques, and procedures (TTPs).
-- Restore affected systems to a known good state by applying patches, updating configurations, and ensuring all security controls are active.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement network hardening measures, such as disabling unused ports and services, to reduce the attack surface and prevent future scans."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_syn_port_scan_detected.toml b/rules/network/discovery_potential_syn_port_scan_detected.toml
index 019cf793704..7a85fc4e8c0 100644
--- a/rules/network/discovery_potential_syn_port_scan_detected.toml
+++ b/rules/network/discovery_potential_syn_port_scan_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ index = ["logs-endpoint.events.network-*", "logs-network_traffic.*", "packetbeat
 language = "kuery"
 license = "Elastic License v2"
 max_signals = 5
-name = "Potential SYN-Based Network Scan Detected"
+name = "Potential SYN-Based Port Scan Detected"
 risk_score = 21
 rule_id = "bbaa96b9-f36c-4898-ace2-581acb00a409"
 severity = "low"
@@ -37,49 +37,6 @@ type = "threshold"
 query = '''
 destination.port : * and network.packets <= 2 and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential SYN-Based Network Scan Detected
-
-SYN-based network scans exploit the TCP handshake process to identify open ports on a target system, which adversaries can use to find vulnerable services. By sending SYN packets to multiple ports and analyzing responses, attackers map network services without completing connections. The detection rule identifies such scans by flagging connection attempts from internal IPs to numerous ports with minimal packets, indicating potential reconnaissance activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the source IP address involved in the potential SYN-based network scan and verify if it falls within the internal IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16).
-- Check historical logs to determine if the source IP has been involved in similar scanning activities or other suspicious behavior in the past.
-- Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker.
-- Correlate the source IP with known user accounts or devices to determine if the activity is expected or if it could be indicative of a compromised system.
-- Use network flow data to assess the volume and frequency of SYN packets sent from the source IP to the destination ports, confirming the threshold logic of 2 or fewer packets per port.
-- Investigate any recent changes or anomalies in the network environment that could explain the scanning activity, such as new devices or software installations.
-- Utilize Osquery to gather additional context on the source system. For example, run the following Osquery query to list active network connections and identify any unusual or unauthorized connections: `SELECT * FROM process_open_sockets WHERE remote_address != '' AND local_address = '<source_ip>';`
-- Check for any related alerts or incidents that might provide additional context or indicate a broader attack campaign.
-- Review endpoint security logs and alerts from the source system to identify any signs of compromise or malicious software that could be responsible for the scanning activity.
-- Consult threat intelligence sources to determine if the observed scanning behavior matches any known attack patterns or threat actor tactics.
-
-### False positive analysis
-
-- **Automated Network Monitoring Tools**: Some network monitoring or management tools may periodically send SYN packets to check the status of network services. These legitimate activities can trigger the rule as false positives. Users can handle this by identifying the IP addresses of these tools and creating exceptions for them in the detection rule.
-- **Load Balancers and Health Checks**: Load balancers and health check services often perform SYN scans to ensure that backend services are operational. These scans are benign and necessary for maintaining service availability. Users should identify the IP addresses of these devices and exclude them from triggering the rule.
-- **Internal Security Scans**: Organizations may conduct regular security assessments or vulnerability scans that mimic SYN-based scanning techniques. These scans are typically scheduled and known to the IT department. Users can manage these false positives by scheduling exceptions during known scan windows or excluding the IP addresses of internal scanning tools.
-- **Network Troubleshooting Activities**: IT personnel may perform network troubleshooting that involves sending SYN packets to diagnose connectivity issues. These activities can be mistaken for malicious scans. Users should document and exclude the IP addresses of devices used for troubleshooting from the detection rule.
-- **Dynamic IP Addressing**: In environments with dynamic IP addressing, legitimate devices may occasionally trigger the rule due to IP address changes. Users should monitor and adjust exceptions as needed to account for these changes, ensuring that legitimate devices are not flagged as threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further reconnaissance or potential exploitation by the attacker.
-- Conduct a thorough investigation of the source IP to determine if the activity is legitimate or malicious, checking for any known vulnerabilities or misconfigurations.
-- Review firewall and intrusion detection/prevention system (IDS/IPS) logs to identify any other suspicious activities or patterns associated with the source IP.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed to be malicious, providing them with all relevant logs and findings.
-- Implement network segmentation to limit the exposure of critical systems and services, reducing the attack surface available to potential adversaries.
-- Enhance logging policies to ensure comprehensive monitoring of network traffic, focusing on unusual patterns or behaviors that may indicate reconnaissance activities.
-- Integrate threat intelligence feeds to improve detection capabilities and provide context on known malicious IPs or scanning techniques.
-- Apply security patches and updates to all systems and services to mitigate vulnerabilities that could be exploited by attackers.
-- Conduct a post-incident review to identify gaps in detection and response processes, using insights to improve future incident handling and prevention strategies.
-- Educate employees on recognizing and reporting suspicious network activities, reinforcing the importance of security awareness in preventing potential threats."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
index fe04253ad21..ddaf50fd579 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -62,53 +62,6 @@ query = '''
     192.168.0.0/16
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 RPC (Remote Procedure Call) from the Internet
-
-RPC allows systems to execute code on remote machines, facilitating administrative tasks and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, focusing on potential threats from external sources.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the source IP address is external and not part of the excluded internal IP ranges specified in the detection rule.
-- Verify the destination IP address to ensure it belongs to your internal network, as specified in the detection rule.
-- Check historical logs for any previous RPC traffic from the same external IP address to identify patterns or repeated attempts.
-- Analyze the network traffic flow data to determine the volume and frequency of RPC requests from the external source.
-- Use packet capture tools to inspect the payload of the suspicious RPC traffic for any signs of malicious activity or anomalies.
-- Cross-reference the external IP address with threat intelligence databases to check for any known malicious activity associated with it.
-- Investigate the destination host to determine if it has any vulnerabilities or misconfigurations that could be exploited via RPC.
-- Utilize Osquery to gather more information about the destination host. For example, run the following Osquery query to list active network connections and identify any unusual or unauthorized connections:
-  ```sql
-  SELECT * FROM process_open_sockets WHERE remote_address = '<external_ip>';
-  ```
-- Check for any recent changes or updates on the destination host that might have inadvertently exposed RPC services to the Internet.
-- Collaborate with the system administrators to verify if there is a legitimate reason for RPC traffic from the Internet and document any findings or anomalies for further analysis.
-
-### False positive analysis
-
-- **Internal Misconfigurations**: Sometimes, internal systems may be misconfigured to route traffic through external IPs, triggering false positives. Ensure network configurations are correct and internal traffic is not mistakenly flagged as external.
-- **Third-Party Services**: Certain legitimate third-party services might use RPC over the Internet for valid reasons, such as remote management or monitoring. Identify these services and create exceptions for their IP addresses to prevent false alerts.
-- **VPN and Proxy Usage**: Users connecting through VPNs or proxies might appear as external sources. Verify if the flagged IPs belong to known VPN or proxy services and consider excluding them if they are part of regular operations.
-- **Cloud-Based Resources**: Cloud environments might have public-facing IPs that are used for internal communications. Review cloud configurations and whitelist known IP ranges that are part of your cloud infrastructure.
-- **Testing and Development Environments**: Traffic from testing or development environments might mimic suspicious patterns. Document these environments and exclude their IPs from the rule to avoid unnecessary alerts.
-- **Regular Audits**: Conduct regular audits of the exceptions list to ensure that only legitimate and necessary exclusions are maintained, reducing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the intrusion, focusing on identifying any unauthorized access or changes made to the system.
-- Review logs and network traffic to identify the source of the RPC traffic and any other potentially malicious activity.
-- Apply patches and updates to the affected system and any other vulnerable systems to mitigate the exploited vulnerability.
-- Change all passwords and credentials that may have been compromised during the incident.
-- Restore the system from a known good backup if unauthorized changes or malware are detected.
-- Implement network segmentation to limit exposure of critical systems and services to the Internet.
-- Enhance logging and monitoring to include detailed records of RPC traffic and other critical services for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
index 0e5a02d1fc1..765d3d433c4 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -62,49 +62,6 @@ query = '''
     "FF00::/8"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 RPC (Remote Procedure Call) to the Internet
-
-RPC enables remote management and resource sharing, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, flagging potential threats from external sources.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of RPC traffic on TCP port 135 originating from internal IP addresses and destined for external IP addresses.
-- Verify the source IP address against known internal assets to determine if the traffic is originating from a legitimate system.
-- Check the destination IP address to identify if it belongs to a known or suspicious external entity, using threat intelligence sources if available.
-- Analyze historical network traffic logs to identify any previous instances of similar RPC traffic patterns from the same source or to the same destination.
-- Use Osquery to inspect the source system for any signs of compromise or unauthorized software that might be initiating the RPC traffic. Example query: `SELECT * FROM processes WHERE name LIKE '%rpc%' OR path LIKE '%rpc%'`.
-- Investigate the user accounts and processes on the source system to determine if any unauthorized access or execution has occurred.
-- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns.
-- Examine firewall and intrusion detection/prevention system logs to see if there were any blocked or flagged attempts related to the RPC traffic.
-- Consult with system administrators to verify if there were any legitimate remote management activities scheduled or performed that could explain the RPC traffic.
-- Document all findings and gather evidence to support further analysis or escalation if the activity is deemed suspicious or malicious.
-
-### False positive analysis
-
-- **Internal Testing and Monitoring Tools**: Organizations may have legitimate internal tools or testing environments that simulate external RPC traffic for monitoring or testing purposes. These can trigger false positives. Users can handle this by creating exceptions for known IP addresses or subnets associated with these tools.
-- **Cloud Services and VPNs**: Some cloud services or VPNs might route traffic in a way that appears as external RPC traffic. This can be managed by identifying and excluding the IP ranges of trusted cloud services or VPN endpoints from the detection rule.
-- **Misconfigured Network Devices**: Occasionally, network devices might be misconfigured to route internal RPC traffic through external IPs, leading to false positives. Regular audits and configuration checks can help identify and rectify these issues, and exceptions can be made for known devices during the interim.
-- **Third-party Software**: Certain third-party software solutions might use RPC over the internet for legitimate purposes, such as remote support or management. Users should verify the legitimacy of such software and exclude its traffic by specifying the associated IP addresses or domains.
-- **Legacy Systems**: Older systems might still rely on outdated configurations that expose RPC traffic externally. While these should ideally be updated, temporary exceptions can be made for these systems while a long-term solution is implemented.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the affected system to identify any unauthorized changes or installed backdoors, focusing on RPC-related processes and services.
-- Review network logs and firewall configurations to identify any other systems that may have been targeted or compromised using similar RPC traffic patterns.
-- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate known vulnerabilities exploited via RPC.
-- Change all passwords and credentials associated with the affected system and any potentially compromised accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging and monitoring for RPC traffic and other critical services to detect and respond to future threats more effectively.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection capabilities and understand the tactics, techniques, and procedures (TTPs) used by attackers.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security configurations are applied.
-- Harden the system by disabling unnecessary services, enforcing strong authentication mechanisms, and ensuring RPC services are not exposed to the Internet."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
index 32597e353c7..ec784917be1 100644
--- a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
+++ b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/18"
 
 [rule]
 author = ["Elastic"]
@@ -62,50 +62,6 @@ query = '''
     "FF00::/8"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SMB (Windows File Sharing) Activity to the Internet
-
-SMB, or Server Message Block, is a protocol used for sharing files and resources within trusted networks. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access or data theft. Adversaries exploit SMB by scanning for open ports and using vulnerabilities to gain entry. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges.
-
-### Possible investigation steps
-
-- Review the alert details to identify the internal source IP address involved in the suspicious SMB traffic. Cross-reference this IP with asset management systems to determine the device owner and its role within the network.
-- Examine the destination IP address to ascertain if it belongs to a known or trusted external entity. Use threat intelligence sources to check if the IP is associated with malicious activity.
-- Analyze network logs to identify the volume and frequency of SMB traffic from the source IP to the destination IP. Look for patterns that might indicate automated or scripted activity.
-- Check for any recent changes or updates on the source device that might have inadvertently exposed SMB services to the internet.
-- Use Osquery to gather more information about the SMB service running on the source device. Example query: `SELECT * FROM listening_ports WHERE port IN (139, 445);` to verify if the SMB service is actively listening on these ports.
-- Investigate any recent user activity on the source device that might have initiated the SMB connection. Look for unusual login times or access from unexpected locations.
-- Review firewall and security appliance logs to determine if there were any attempts to block or alert on this SMB traffic before the alert was triggered.
-- Check for any other alerts or incidents related to the same source or destination IPs to identify if this is part of a larger pattern of suspicious activity.
-- Analyze the payload of the SMB traffic, if available, to identify any potential data exfiltration or unauthorized access attempts.
-- Collaborate with the IT team to verify if there are legitimate business needs for SMB traffic to the internet from the identified source device, and document any findings for future reference.
-
-### False positive analysis
-
-- **Internal Services with External IPs**: Some organizations may have legitimate services hosted on external IPs that require SMB access. These should be identified and whitelisted to prevent false positives.
-- **VPN or Remote Access Scenarios**: Users accessing internal resources via VPNs or remote access solutions might trigger alerts if their traffic appears to originate from external IPs. Ensure these IP ranges are accounted for in exceptions.
-- **Cloud Services**: If cloud services are used for file sharing or backup, they might use SMB over the internet. Verify these services and exclude their IP ranges if they are deemed safe.
-- **Misconfigured Network Devices**: Devices that are incorrectly configured to route internal SMB traffic through external networks can cause false positives. Regularly audit network configurations to prevent this.
-- **Testing and Development Environments**: Test environments that simulate external access for development purposes might trigger alerts. Document and exclude these environments if they are secure and monitored.
-- **Handling False Positives**: Regularly review and update the list of excluded IPs and services to ensure they reflect current network architecture and business needs. Use network monitoring tools to validate the legitimacy of flagged traffic before adding exceptions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the SMB traffic, including reviewing logs and network traffic data.
-- Verify if any unauthorized access or data exfiltration has occurred and document all findings for further analysis.
-- Apply patches and updates to the SMB service and any other vulnerable applications to mitigate known vulnerabilities.
-- Change all passwords and credentials that may have been exposed or compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for SMB traffic and other critical services to detect future anomalies.
-- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging threats.
-- Restore the affected system to its operational state by reinstalling the operating system and applications from trusted sources.
-- Harden the network by disabling SMB access to the internet, configuring firewalls, and applying least privilege principles to reduce attack surfaces."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_unsecure_elasticsearch_node.toml b/rules/network/initial_access_unsecure_elasticsearch_node.toml
index c623772284b..8f51cb76b9c 100644
--- a/rules/network/initial_access_unsecure_elasticsearch_node.toml
+++ b/rules/network/initial_access_unsecure_elasticsearch_node.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/11"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -21,51 +21,7 @@ index = ["packetbeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Inbound Connection to an Unsecure Elasticsearch Node"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Inbound Connection to an Unsecure Elasticsearch Node
-
-Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access or manipulate data. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the destination port is 9200, indicating the default Elasticsearch port, and verify the network direction is inbound.
-- Check the absence of the `http.request.headers.authorization` field to confirm that the connection lacks authentication.
-- Analyze the source IP address of the inbound connection to determine if it is from a known or trusted entity, or if it appears suspicious or unexpected.
-- Investigate the `event.dataset` and `event.category` fields to ensure the traffic is categorized as HTTP and aligns with the expected network traffic patterns.
-- Examine historical data for similar inbound connections to the Elasticsearch node to identify any patterns or repeated access attempts from the same source.
-- Use Osquery to gather additional context on the Elasticsearch node by running a query such as: `SELECT * FROM listening_ports WHERE port = 9200;` to verify if the node is actively listening on the default port.
-- Check for any recent changes in the Elasticsearch configuration files that might have disabled TLS or authentication inadvertently.
-- Review the `http.response.headers.content-type` field to ensure the traffic is not related to benign requests, such as favicon requests, which are filtered out by the rule.
-- Correlate the alert with other security events or logs to identify any concurrent suspicious activities or anomalies in the network.
-- Consult with the system administrators or the team responsible for the Elasticsearch deployment to verify if the node should be publicly accessible and if proper security measures are in place.
-
-### False positive analysis
-
-- Internal monitoring tools or services that regularly check the health of Elasticsearch nodes might trigger this rule if they do not use authentication headers. Users can create exceptions for known IP addresses or services that perform these checks.
-- Automated scripts or applications that interact with Elasticsearch for legitimate purposes without using authentication might be flagged. To manage this, users should ensure these scripts are updated to include authentication or whitelist their IP addresses.
-- Development or testing environments where security configurations are intentionally relaxed might generate alerts. Users can exclude these environments by filtering based on IP ranges or hostnames.
-- Security scanners or vulnerability assessment tools that probe Elasticsearch nodes could be mistaken for malicious activity. Users should identify and exclude these tools from triggering alerts by adding them to an exception list.
-- Certain legitimate third-party integrations that do not support authentication might cause false positives. Users should verify the necessity of these integrations and, if safe, exclude them from the rule.
-
-### Response and remediation
-
-- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data manipulation.
-- Conduct a thorough investigation to determine the extent of unauthorized access, focusing on logs and network traffic to identify any data exfiltration or manipulation.
-- Review and update the Elasticsearch configuration to enable Transport Layer Security (TLS) and implement strong authentication mechanisms to prevent future unauthorized access.
-- Apply security patches and updates to the Elasticsearch software to mitigate any known vulnerabilities that could be exploited.
-- Restore any altered or deleted data from backups, ensuring that the backup data is clean and uncompromised.
-- Implement network segmentation to limit access to Elasticsearch nodes, allowing only trusted IP addresses and services to connect.
-- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect and alert on suspicious activities in real-time.
-- Conduct a security audit of the entire environment to identify and remediate other potential vulnerabilities or misconfigurations.
-- Educate and train the IT and security teams on secure configuration practices and the importance of regular security assessments.
-- Escalate the incident to the appropriate internal teams and, if necessary, report to external authorities or partners, especially if sensitive data was accessed or exfiltrated.
-
-## Setup
+note = """## Setup
 
 This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation."""
 references = [
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
index b650203e2f0..a438cc58550 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,52 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Credential Dumping - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution that identifies suspicious activities like credential dumping, where attackers extract sensitive authentication data to gain unauthorized access. Adversaries exploit system vulnerabilities to perform such actions, often targeting OS credentials. The detection rule leverages specific event types and actions to flag these malicious attempts, aligning with MITRE ATT&CK's framework for identifying credential access threats.
-
-### Possible investigation steps
-
-- Review the alert details in Elastic Endgame to understand the context, including the event.kind, event.module, and endgame.metadata.type fields to confirm the detection type and source.
-- Examine the event.action and endgame.event_subtype_full fields to identify the specific credential theft event that triggered the alert.
-- Check the timestamp of the alert to determine when the suspicious activity occurred and correlate it with other events in the same timeframe.
-- Investigate the affected host by reviewing its recent activity logs to identify any unusual behavior or unauthorized access attempts.
-- Use Osquery to gather more information about the processes running on the affected host. For example, run the following query to list processes that might be involved in credential dumping:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE name IN ('lsass.exe', 'mimikatz.exe', 'procdump.exe');
-  ```
-- Analyze user account activity on the affected host to identify any unauthorized access or privilege escalation attempts.
-- Review network logs to detect any suspicious outbound connections that might indicate data exfiltration following the credential dumping.
-- Cross-reference the alert with other security tools and logs to identify any related alerts or indicators of compromise (IOCs) that might suggest a broader attack campaign.
-- Investigate any recent changes to system configurations or installed software that could have introduced vulnerabilities exploited for credential dumping.
-- Document all findings and observations to build a comprehensive timeline of events and support further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Known false positives for the Credential Dumping - Detected - Elastic Endgame rule may include legitimate administrative tools or scripts that access credential stores for authorized purposes, such as system backups or password management software.
-- Security teams can manage these false positives by creating exceptions for specific processes or applications that are known to perform credential access in a non-malicious context, ensuring these are well-documented and regularly reviewed.
-- Users should also consider the context of the detected event, such as the time of day or the user account involved, to determine if the activity aligns with expected behavior.
-- Implementing a whitelist of trusted applications and processes that are allowed to access credentials can help reduce false positives while maintaining security.
-- Regularly updating the detection rules and maintaining communication with IT and security teams can help in identifying and excluding benign activities that trigger alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the credential dumping activity, utilizing logs and forensic tools.
-- Reset passwords for compromised accounts and implement multi-factor authentication to enhance security.
-- Review and update security patches and configurations to address vulnerabilities exploited during the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed authentication and access events for future investigations.
-- Integrate additional security solutions, such as endpoint detection and response (EDR) tools, to improve threat detection capabilities.
-- Restore the system to its operational state by reimaging affected machines and verifying the integrity of critical files and applications.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
index fa94b5ed89d..54622033143 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,49 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Credential Dumping - Prevented - Elastic Endgame
-
-Elastic Endgame is a security solution designed to prevent unauthorized access by detecting and blocking credential dumping attempts, a common tactic used by adversaries to extract sensitive authentication data. Attackers exploit this by accessing stored credentials to escalate privileges or move laterally within a network. The detection rule identifies such threats by monitoring for specific alert types and actions indicative of credential theft, leveraging event data to preemptively thwart these malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `event.kind:alert`, `event.module:endgame`, and `endgame.metadata.type:prevention` fields to confirm the alert type and source.
-- Examine the `event.action:cred_theft_event` and `endgame.event_subtype_full:cred_theft_event` fields to identify the specific actions that triggered the alert, providing insight into the attempted credential dumping method.
-- Check the timestamp of the alert to determine when the credential dumping attempt occurred and correlate it with other events in the network around the same time.
-- Investigate the source IP address and hostname associated with the alert to identify the potentially compromised system and assess its role within the network.
-- Analyze user account information involved in the alert to determine if the account is legitimate and if it has been used in any suspicious activities recently.
-- Utilize Osquery to gather additional context from the affected system. For example, run the following Osquery query to check for suspicious processes related to credential dumping: `SELECT pid, name, path, cmdline FROM processes WHERE name IN ('lsass.exe', 'mimikatz.exe', 'procdump.exe');`
-- Review recent login attempts and authentication logs on the affected system to identify any unauthorized access or failed login attempts that may indicate credential theft.
-- Cross-reference the alert with other security tools and logs, such as firewall logs or intrusion detection systems, to gather more evidence of the attack vector and potential lateral movement.
-- Investigate any recent changes to system configurations or installed software on the affected machine that could have facilitated the credential dumping attempt.
-- Document all findings and evidence collected during the investigation to build a comprehensive timeline and understanding of the incident, which will aid in further analysis and reporting.
-
-### False positive analysis
-
-- Known false positives for the Credential Dumping - Prevented - Elastic Endgame rule may include legitimate administrative tools or scripts that access credential stores for authorized purposes, such as system management or software updates.
-- Security software or backup solutions that scan or access credential files as part of their routine operations can also trigger false positives.
-- Users can manage these false positives by creating exceptions for specific processes or applications that are known to perform legitimate credential access, ensuring these are well-documented and regularly reviewed.
-- Implementing a whitelist of trusted applications and processes that are allowed to access credential stores can help reduce false positives while maintaining security.
-- Regularly updating the list of exceptions and monitoring for any changes in behavior of these applications can help maintain a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
-- Conduct a thorough investigation to identify the source and scope of the credential dumping attempt, utilizing Elastic Endgame logs and any other available security information.
-- Reset passwords for all compromised accounts and consider implementing multi-factor authentication to enhance security.
-- Review and update access controls and permissions to ensure the principle of least privilege is enforced across the network.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed authentication and access events, aiding in future investigations.
-- Integrate Elastic Endgame with other security tools such as SIEMs to improve threat detection and response capabilities.
-- Restore the affected system to its operational state by reimaging it and applying the latest security patches and updates.
-- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary services, applying security baselines, and conducting regular security audits to reduce the risk of future credential dumping attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/endgame_adversary_behavior_detected.toml b/rules/promotions/endgame_adversary_behavior_detected.toml
index 0a4551a4efa..37dae90c425 100644
--- a/rules/promotions/endgame_adversary_behavior_detected.toml
+++ b/rules/promotions/endgame_adversary_behavior_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,46 +36,4 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and (event.action:behavior_protection_event or endgame.event_subtype_full:behavior_protection_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Adversary Behavior - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution designed to detect and prevent adversarial actions by monitoring system behaviors. Adversaries often exploit system vulnerabilities or misuse legitimate tools to execute malicious activities. This detection rule identifies suspicious behavior by analyzing alerts and specific event actions related to behavior protection, helping security analysts pinpoint potential threats and mitigate risks effectively.
-
-### Possible investigation steps
-
-- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected behavior.
-- Examine the event.kind field to confirm that the alert is indeed an 'alert' type, ensuring that it requires immediate attention.
-- Analyze the event.module field to verify that the alert originated from the 'endgame' module, confirming the source of the detection.
-- Investigate the event.action and endgame.event_subtype_full fields to understand the specific behavior protection event that triggered the alert, identifying the nature of the suspicious activity.
-- Cross-reference the alert with other recent alerts or logs to identify any patterns or correlations that might indicate a broader attack campaign.
-- Use Osquery to gather additional system information related to the alert. For example, run the following query to list all running processes and their network connections: `SELECT pid, name, path, listening_ports FROM processes WHERE on_disk = 1;`
-- Check the affected system's recent login history and user activity to identify any unauthorized access attempts or unusual user behavior.
-- Review the system's installed software and running services to detect any unauthorized or suspicious applications that might have been used by the adversary.
-- Analyze network traffic logs to identify any unusual outbound connections or data exfiltration attempts that might be associated with the detected behavior.
-- Consult threat intelligence sources to determine if the detected behavior matches any known adversary tactics, techniques, or procedures, even though the MITRE ATT&CK tactic and technique fields are marked as 'None'.
-
-### False positive analysis
-
-- Known false positives for the Adversary Behavior - Detected - Elastic Endgame rule often arise from legitimate software or administrative tools that exhibit behavior similar to adversarial actions. For example, system administration scripts or automated maintenance tasks may trigger alerts due to their access patterns or execution methods.
-- Users can manage these false positives by creating exceptions for specific processes or actions that are known to be safe. This involves identifying the benign behavior patterns that frequently trigger alerts and configuring the security solution to exclude these from future detections.
-- It is important to regularly review and update these exceptions to ensure that they do not inadvertently allow new or modified threats to bypass detection. Security teams should document the rationale for each exception and periodically reassess their validity in the context of evolving threat landscapes.
-- Collaboration with IT and development teams can help in understanding the normal operational behaviors of systems and applications, which aids in distinguishing between legitimate activities and potential threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential threats.
-- Conduct a thorough investigation of the alert by reviewing related logs and events to understand the scope and impact.
-- Identify and terminate any malicious processes or unauthorized access points detected on the system.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is beyond initial containment capabilities.
-- Apply patches and updates to address any exploited vulnerabilities and prevent future exploitation.
-- Restore the system from a known good backup to ensure the removal of any persistent threats.
-- Implement enhanced logging policies to capture detailed system and network activity for future investigations.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve threat visibility and response capabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users on security best practices and awareness to reduce the risk of similar incidents occurring in the future."""
 
diff --git a/rules/promotions/endgame_malware_detected.toml b/rules/promotions/endgame_malware_detected.toml
index 64b893e5343..cbf07ce6b21 100644
--- a/rules/promotions/endgame_malware_detected.toml
+++ b/rules/promotions/endgame_malware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,47 +36,4 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Malware - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution that leverages advanced detection capabilities to identify malware threats within an environment. It monitors file classification events to detect suspicious activities. Adversaries may exploit file systems to execute or hide malware. The detection rule identifies alerts from the Endgame module, focusing on file classification events, to pinpoint potential malware activities, enabling timely threat response.
-
-### Possible investigation steps
-
-- Review the alert details in the security dashboard to understand the context and specifics of the detection, focusing on the `event.kind:alert` and `event.module:endgame` fields.
-- Examine the `endgame.metadata.type:detection` field to confirm the type of detection and ensure it aligns with the expected behavior of the Elastic Endgame module.
-- Investigate the `event.action:file_classification_event` or `endgame.event_subtype_full:file_classification_event` fields to identify the specific file classification event that triggered the alert.
-- Cross-reference the file path and hash values of the suspicious file with known malware databases to determine if it is a known threat.
-- Utilize Osquery to gather additional context about the file and its behavior on the system. For example, run the following Osquery query to list processes associated with the suspicious file: `SELECT * FROM processes WHERE path = '/path/to/suspicious/file';`
-- Check the system's recent file modification and creation events to identify any unusual activities around the time of the alert.
-- Analyze the parent process of the suspicious file to understand how it was executed and whether it was initiated by a legitimate application or process.
-- Review network connections established by the system around the time of the alert to identify any suspicious outbound connections that may indicate data exfiltration or command-and-control communication.
-- Investigate user activity on the affected system to determine if any unauthorized actions were performed that could have led to the execution of the malware.
-- Correlate the alert with other security events and logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives for the Malware - Detected - Elastic Endgame rule may include legitimate software updates or installations that mimic malware behavior, such as file classification events triggered by trusted applications.
-- Users can manage these false positives by creating exceptions for specific applications or processes that are known to generate benign file classification events, ensuring these are well-documented and regularly reviewed to maintain security integrity.
-- Another common false positive scenario involves automated scripts or system maintenance tasks that access or modify files in a manner similar to malware; these can be excluded by identifying and whitelisting the specific scripts or tasks involved.
-- To handle frequent non-threatening behaviors, users should leverage the exclusion capabilities within Elastic Endgame to filter out alerts from known safe sources, reducing noise and focusing on genuine threats.
-- Regularly updating the list of exceptions and exclusions based on the latest threat intelligence and organizational changes can help maintain an effective balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the malware.
-- Conduct a thorough investigation of the alert by reviewing the file classification events and any related logs to understand the scope and impact.
-- Utilize Elastic Endgame's detailed event data to identify the malware's entry point and any lateral movement within the network.
-- Remove the detected malware by using updated antivirus or anti-malware tools, ensuring that the system is clean.
-- Apply security patches and updates to the operating system and all installed software to close any vulnerabilities exploited by the malware.
-- Escalate the incident to the security operations center (SOC) or incident response team if the malware is part of a larger attack campaign or if it involves sensitive data.
-- Implement enhanced logging policies to capture detailed file system activities and network traffic for future investigations.
-- Integrate Elastic Endgame with other security tools such as SIEMs for improved threat detection and response capabilities.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure that backups are clean before restoring any data.
-- Strengthen system defenses by applying security hardening measures, such as disabling unnecessary services, enforcing strong password policies, and conducting regular security audits."""
 
diff --git a/rules/promotions/endgame_malware_prevented.toml b/rules/promotions/endgame_malware_prevented.toml
index 9b6a8c9169f..d00be854558 100644
--- a/rules/promotions/endgame_malware_prevented.toml
+++ b/rules/promotions/endgame_malware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,47 +36,4 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Malware - Prevented - Elastic Endgame
-
-Elastic Endgame is a security solution designed to prevent malware by leveraging advanced threat detection and prevention techniques. It monitors system activities and classifies files to identify and block malicious actions. Adversaries may attempt to bypass these defenses by disguising malware as legitimate files. The detection rule identifies such threats by focusing on alerts where file classification events indicate prevention actions, ensuring that any attempt to execute or propagate malware is promptly detected and mitigated.
-
-### Possible investigation steps
-
-- Review the alert details in the security dashboard to understand the context and specifics of the prevention event, focusing on the `event.kind:alert` and `event.module:endgame` fields.
-- Examine the `endgame.metadata.type:prevention` field to confirm that the alert is related to a prevention action, ensuring that the threat was blocked before execution.
-- Analyze the `event.action:file_classification_event` or `endgame.event_subtype_full:file_classification_event` fields to identify the type of file classification event that triggered the alert.
-- Investigate the file path and hash of the suspected malicious file to determine its origin and whether it matches known malware signatures.
-- Use Osquery to gather additional context about the file and its behavior on the system. For example, run the following Osquery query to check for any related processes: `SELECT * FROM processes WHERE path = '/path/to/suspected/file';`
-- Check the system's recent file modification and creation events to identify any suspicious activities that occurred around the time of the alert.
-- Review user activity logs to determine if any user actions could have inadvertently triggered the alert, focusing on any recent downloads or executed files.
-- Correlate the alert with other security events in the environment to identify potential patterns or related incidents that could indicate a broader attack campaign.
-- Consult threat intelligence sources to see if the file hash or any related indicators of compromise (IOCs) are associated with known threat actors or malware campaigns.
-- Document all findings and observations in the investigation report, ensuring that all relevant details from the alert and subsequent analysis are captured for future reference.
-
-### False positive analysis
-
-- Known false positives for the Malware - Prevented - Elastic Endgame rule may include legitimate software that mimics malware behavior, such as software updates or installers that modify system files in a manner similar to malware.
-- Users can handle these false positives by creating exceptions for specific file paths or processes that are known to be safe, ensuring that these legitimate activities are not flagged as threats.
-- It is important to regularly review and update these exceptions to accommodate new software versions or changes in system behavior, minimizing the risk of overlooking genuine threats.
-- Users should also consider the context of the alert, such as the source and destination of the file or process, to determine if the behavior is expected and non-threatening.
-- Implementing a feedback loop with security teams can help refine detection rules and reduce the occurrence of false positives by incorporating insights from past incidents.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the malware.
-- Verify the alert by cross-referencing with other security logs and alerts to confirm the presence of malware.
-- Conduct a thorough investigation to identify the source and entry point of the malware, using available forensic tools and techniques.
-- Remove the identified malware from the system using trusted antivirus or anti-malware solutions.
-- Restore the system from a clean backup if the malware has caused significant damage or if removal is not feasible.
-- Update all security software and apply the latest patches to the operating system and applications to close any vulnerabilities.
-- Implement enhanced logging policies to capture detailed system and network activities for future investigations.
-- Integrate additional security solutions, such as endpoint detection and response (EDR) tools, to improve threat visibility and response capabilities.
-- Escalate the incident to the appropriate internal or external teams if the malware is part of a larger attack campaign or if sensitive data has been compromised.
-- Conduct a post-incident review to identify gaps in the security posture and apply hardening measures, such as disabling unnecessary services and enforcing least privilege access controls."""
 
diff --git a/rules/promotions/endgame_ransomware_detected.toml b/rules/promotions/endgame_ransomware_detected.toml
index 2f44801a055..917f0ab088b 100644
--- a/rules/promotions/endgame_ransomware_detected.toml
+++ b/rules/promotions/endgame_ransomware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,50 +36,4 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Ransomware - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution designed to detect and respond to ransomware threats by monitoring system events and identifying suspicious activities. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activity by analyzing alerts and specific event actions, enabling timely intervention to mitigate damage.
-
-### Possible investigation steps
-
-- Review the alert details in Elastic Endgame by clicking the icon in the event.module column or the link in the rule.reference column to gather initial context about the detected ransomware event.
-- Examine the event.kind field to confirm that the alert is indeed an alert type and not a benign event.
-- Check the event.module field to ensure the alert is generated by the endgame module, confirming the source of detection.
-- Analyze the endgame.metadata.type field to verify that the alert is categorized as a detection, indicating a potential threat.
-- Investigate the event.action and endgame.event_subtype_full fields to identify the specific ransomware event or subtype that triggered the alert.
-- Correlate the alert with other related alerts or events in the system to determine if this is part of a larger attack pattern or isolated incident.
-- Use Osquery to gather additional system information. For example, run the following query to list processes that have been started recently, which might indicate ransomware activity:
-  ```sql
-  SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));
-  ```
-- Check for any recent file modifications or encryptions on the system by reviewing file access logs or using file integrity monitoring tools.
-- Investigate user activity around the time of the alert to identify any suspicious logins or actions that could be related to the ransomware execution.
-- Review network traffic logs for any unusual outbound connections that might indicate communication with a command and control server or data exfiltration attempts.
-
-### False positive analysis
-
-- Known false positives for the Ransomware - Detected - Elastic Endgame rule may include legitimate software updates or backup processes that mimic ransomware behavior by encrypting files temporarily. 
-- Users can manage these false positives by creating exceptions for specific processes or applications that are known to perform legitimate encryption activities, ensuring they are not flagged as threats.
-- Regularly review and update the list of exceptions to accommodate new software updates or changes in legitimate processes that could trigger alerts.
-- Implement a monitoring strategy to differentiate between benign and malicious encryption activities by analyzing the context and frequency of the detected events.
-- Collaborate with IT and security teams to identify and document legitimate processes that may trigger false positives, ensuring these are accounted for in the security policy.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent the spread of ransomware to other devices.
-- Conduct a thorough investigation to identify the ransomware variant and entry point by analyzing logs and alerts from Elastic Endgame.
-- Use endpoint detection and response tools to terminate malicious processes and remove ransomware executables from the affected systems.
-- Restore encrypted files from the most recent clean backups to ensure data integrity and minimize downtime.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed system and network activity, aiding in future investigations and threat hunting.
-- Integrate Elastic Endgame with other security solutions, such as SIEM and threat intelligence platforms, to improve detection and response capabilities.
-- Apply security patches and updates to all systems to close vulnerabilities exploited by the ransomware.
-- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
-- Educate employees on recognizing phishing attempts and other common ransomware delivery methods to reduce the risk of future incidents."""
 
diff --git a/rules/promotions/endgame_ransomware_prevented.toml b/rules/promotions/endgame_ransomware_prevented.toml
index 75d5d92fed0..d6e5e4b7667 100644
--- a/rules/promotions/endgame_ransomware_prevented.toml
+++ b/rules/promotions/endgame_ransomware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,46 +36,4 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Ransomware - Prevented - Elastic Endgame
-
-Elastic Endgame is a security solution designed to prevent ransomware by monitoring and analyzing system events. Adversaries often exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activities by focusing on alerts from the Endgame module, specifically targeting prevention events linked to ransomware actions, thus enabling early intervention and mitigation.
-
-### Possible investigation steps
-
-- Review the alert details in the security dashboard to understand the context and specifics of the prevention event, focusing on the `event.kind`, `event.module`, and `endgame.metadata.type` fields.
-- Examine the `event.action` and `endgame.event_subtype_full` fields to confirm the type of ransomware event that was prevented and gather more context about the specific actions that triggered the alert.
-- Check the timestamp of the alert to determine when the ransomware activity was detected and correlate it with other events in the system logs around the same time.
-- Investigate the source and destination IP addresses involved in the alert to identify potentially compromised systems or external connections.
-- Use Osquery to gather additional information about the affected system. For example, run the following query to list recent processes that might be related to the ransomware activity: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
-- Analyze the user account activity associated with the alert to determine if any unauthorized access or privilege escalation occurred.
-- Review file system changes on the affected system to identify any encrypted files or suspicious modifications that might indicate ransomware behavior.
-- Check for any related alerts or events in the security solution that might provide additional context or indicate a broader attack campaign.
-- Investigate any known vulnerabilities or exploits that might have been used to deploy the ransomware, focusing on recent patches or security advisories.
-- Document all findings and observations in a detailed report to support further analysis and potential response actions.
-
-### False positive analysis
-
-- Known false positives for the Ransomware - Prevented - Elastic Endgame rule may include legitimate software that performs file encryption as part of its normal operations, such as backup solutions or disk encryption tools. These applications can trigger alerts due to their behavior resembling ransomware activities.
-- Users can manage these false positives by creating exceptions for trusted applications. This involves identifying the legitimate software that triggers the alerts and adding them to an allowlist within the Elastic Endgame settings, ensuring that their activities are not flagged as malicious.
-- Regularly review and update the list of exceptions to accommodate any changes in software behavior or new legitimate applications that may be introduced into the environment.
-- It is crucial to maintain a balance between reducing false positives and ensuring that genuine threats are not overlooked. Therefore, any exceptions should be carefully evaluated and monitored to prevent potential security gaps.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the ransomware.
-- Conduct a thorough investigation to identify the entry point and the scope of the attack, utilizing logs and alerts from Elastic Endgame.
-- Remove the ransomware by using trusted antivirus or anti-malware tools, ensuring the system is clean before reconnecting to the network.
-- Restore encrypted files from the most recent clean backup to ensure data integrity and minimize data loss.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed system events and network traffic for future investigations.
-- Integrate Elastic Endgame with other security tools such as SIEMs for comprehensive threat detection and response capabilities.
-- Review and update security patches and configurations to close vulnerabilities exploited by the ransomware.
-- Educate employees on recognizing phishing attempts and other common ransomware delivery methods to reduce the risk of future incidents.
-- Conduct a post-incident review to assess the effectiveness of the response and update the incident response plan accordingly."""
 
diff --git a/rules/promotions/execution_endgame_exploit_detected.toml b/rules/promotions/execution_endgame_exploit_detected.toml
index ad4573624d1..891c48a3e07 100644
--- a/rules/promotions/execution_endgame_exploit_detected.toml
+++ b/rules/promotions/execution_endgame_exploit_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -41,50 +41,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:exploit_event or endgame.event_subtype_full:exploit_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Exploit - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution designed to detect and prevent exploits by monitoring system activities and identifying suspicious behaviors. Adversaries exploit vulnerabilities to execute unauthorized code, often leading to system compromise. The detection rule identifies alerts from the Endgame module, focusing on exploit-related events, thus enabling timely identification and response to potential threats.
-
-### Possible investigation steps
-
-- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional context.
-- Examine the event.kind field to confirm that the alert is indeed an 'alert' type, ensuring it is not a false positive or misclassification.
-- Check the event.module field to verify that the alert originated from the 'endgame' module, confirming the source of the detection.
-- Analyze the endgame.metadata.type field to ensure it is marked as 'detection', indicating that the alert is based on a detection rule rather than a simple log entry.
-- Investigate the event.action and endgame.event_subtype_full fields to determine the specific exploit event that triggered the alert, providing insight into the nature of the potential exploit.
-- Correlate the alert with other related events in the system to identify any patterns or sequences that may indicate a broader attack or compromise.
-- Use Osquery to gather additional system information related to the alert. For example, run the following query to list all running processes and their network connections: `SELECT pid, name, path, address, port FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid;`
-- Check for any recent changes or anomalies in system configurations or user accounts that could be related to the exploit attempt.
-- Review historical data and logs to identify any previous similar alerts or activities that might suggest a persistent threat or recurring vulnerability.
-- Consult threat intelligence sources to determine if the detected exploit is part of a known campaign or associated with specific threat actors, enhancing the context of the investigation.
-
-### False positive analysis
-
-- Known false positives for the Exploit - Detected - Elastic Endgame rule may include legitimate software updates or patches that mimic exploit-like behavior, triggering alerts. 
-- Certain administrative tools or scripts used for system maintenance might also be flagged as exploit events due to their nature of executing code.
-- Users can manage these false positives by creating exceptions for specific processes or applications that are known to exhibit such behaviors but are verified as non-threatening.
-- Implementing a whitelist of trusted software and regularly updating it can help reduce the occurrence of false positives.
-- Monitoring the frequency and context of alerts can assist in identifying patterns that are consistently non-malicious, allowing for more informed decisions on exclusions.
-- Collaboration with IT and security teams to review and validate alerts can ensure that only genuine threats are acted upon, minimizing disruptions from false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to identify the exploited vulnerability and determine the scope of the compromise using forensic tools and logs.
-- Apply available patches or updates to remediate the identified vulnerability and prevent re-exploitation.
-- Review and analyze the alert details in Elastic Endgame to understand the exploit's behavior and entry point.
-- Escalate the incident to the security operations center (SOC) or incident response team if the exploit is part of a larger attack campaign or if sensitive data is at risk.
-- Implement enhanced logging and monitoring policies to capture detailed system activities and potential exploit attempts for future investigations.
-- Integrate Elastic Endgame with other security tools such as SIEMs and threat intelligence platforms to improve detection and response capabilities.
-- Restore the system to its operational state by reinstalling the operating system and applications from trusted sources, ensuring all security patches are applied.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement system hardening measures, such as disabling unnecessary services, enforcing strong authentication, and applying least privilege principles, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/execution_endgame_exploit_prevented.toml b/rules/promotions/execution_endgame_exploit_prevented.toml
index 08b0c1ae7d1..8d924b7e725 100644
--- a/rules/promotions/execution_endgame_exploit_prevented.toml
+++ b/rules/promotions/execution_endgame_exploit_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -41,49 +41,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:exploit_event or endgame.event_subtype_full:exploit_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Exploit - Prevented - Elastic Endgame
-
-Elastic Endgame is a security solution designed to prevent exploits by monitoring and analyzing system behaviors. Adversaries often exploit vulnerabilities to execute unauthorized code, gaining control over systems. The detection rule identifies alerts where Elastic Endgame has preemptively blocked such exploit attempts, focusing on prevention events and specific exploit-related actions, thus safeguarding against potential execution threats.
-
-### Possible investigation steps
-
-- Review the alert details in the security dashboard to understand the context and specifics of the exploit attempt, focusing on the `event.kind`, `event.module`, and `endgame.metadata.type` fields.
-- Examine the `event.action` and `endgame.event_subtype_full` fields to determine the nature of the exploit event and identify any patterns or specific exploit techniques used.
-- Check the `rule.reference` column for additional documentation or guidance related to the specific exploit attempt to gain further insights.
-- Investigate the affected system by identifying the host and user involved in the alert to assess potential exposure and impact.
-- Use Osquery to gather more information about the affected system. For example, run the following query to list all running processes and their associated network connections: `SELECT pid, name, path, listening_ports FROM processes JOIN listening_ports USING (pid);`
-- Analyze recent system logs and security events on the affected host to identify any unusual activities or anomalies that occurred around the time of the alert.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack campaign or isolated incident.
-- Review the system's patch and update status to ensure that all known vulnerabilities are addressed, focusing on those related to the exploit attempt.
-- Investigate any recent changes or deployments on the affected system that might have introduced vulnerabilities or altered security configurations.
-- Consult threat intelligence sources to check for any known exploits or attack patterns that match the characteristics of the alert, which could provide additional context or indicators of compromise.
-
-### False positive analysis
-
-- Known false positives for the Exploit - Prevented - Elastic Endgame rule may include legitimate software behaviors that mimic exploit-like activities, such as certain software updates or debugging tools that modify system processes in a way that resembles exploit attempts.
-- Users can manage these false positives by creating exceptions for specific processes or applications that are known to trigger alerts but are verified as non-threatening. This can be done by adding these processes to an allowlist within the Elastic Endgame settings.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-- Consider implementing a monitoring period where alerts are closely observed to distinguish between true threats and benign activities, allowing for more informed decisions on which behaviors to exclude.
-- Engage with the security community or Elastic support to stay informed about common false positives and recommended practices for handling them, ensuring that the security posture remains robust while minimizing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Conduct a thorough investigation to identify the vulnerability exploited and gather forensic evidence, including logs and memory dumps.
-- Verify the alert by cross-referencing with other security tools and logs to confirm the exploit attempt and assess the scope of the incident.
-- Apply patches or updates to remediate the identified vulnerability and prevent future exploitation.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Implement enhanced logging policies to capture detailed system and network activity for future investigations.
-- Integrate Elastic Endgame with other security solutions, such as SIEM or EDR, to improve detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/external_alerts.toml b/rules/promotions/external_alerts.toml
index 3ac06c7b079..1eb2d1a0d7d 100644
--- a/rules/promotions/external_alerts.toml
+++ b/rules/promotions/external_alerts.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/08"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -43,48 +43,6 @@ type = "query"
 query = '''
 event.kind:alert and not event.module:(endgame or endpoint or cloud_defend)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 External Alerts
-
-External alerts are crucial for identifying potential threats from outside sources, leveraging logs and signals from various security tools. Adversaries may exploit these technologies by triggering false alerts or bypassing detection systems. The 'External Alerts' rule filters alerts, excluding specific modules, to focus on genuine threats, enabling analysts to swiftly investigate and mitigate risks.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `event.kind:alert` field to confirm the nature of the alert.
-- Check the `event.module` field to ensure the alert is not from excluded modules such as endgame, endpoint, or cloud_defend, which are filtered out by the rule.
-- Correlate the alert with other logs and alerts from the same timeframe to identify any patterns or related activities.
-- Investigate the source IP address or domain associated with the alert to determine if it is known for malicious activity.
-- Use threat intelligence sources to gather additional context on the external alert, such as known indicators of compromise (IOCs) or threat actor profiles.
-- Examine user activity logs to identify any unusual behavior or access patterns that coincide with the alert.
-- Utilize Osquery to gather more information from affected systems. For example, run the following Osquery query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious IP>';`
-- Analyze any file hashes or URLs associated with the alert using online malware analysis tools to assess their threat level.
-- Check for any recent changes in system configurations or security settings that could have contributed to the alert.
-- Document all findings and observations in a centralized investigation report to maintain a clear record of the investigation process.
-
-### False positive analysis
-
-- Known false positives for the External Alerts rule may include benign activities from trusted sources that inadvertently trigger alerts, such as routine network scans by authorized security tools or regular updates from trusted software vendors.
-- Users can manage these false positives by creating exceptions for specific event sources or modules that are consistently identified as non-threatening, ensuring that these are well-documented and reviewed regularly to maintain security integrity.
-- It is important to analyze the context of each alert to determine if it aligns with known benign behaviors or if it requires further investigation, thereby reducing unnecessary alert fatigue and focusing on genuine threats.
-- Implementing a feedback loop where analysts can flag and document false positives will help refine the rule over time, improving its accuracy and reducing the likelihood of overlooking real threats due to alert desensitization.
-
-### Response and remediation
-
-- Immediately isolate affected systems from the network to prevent further spread of the threat.
-- Conduct a thorough investigation of the alert to determine the scope and impact, utilizing available logs and security tools.
-- Validate the alert to confirm it is not a false positive by cross-referencing with other security data sources.
-- If malicious activity is confirmed, remove any identified malware or unauthorized access points from the affected systems.
-- Escalate the incident to the appropriate internal teams or external partners if the threat level is beyond current handling capabilities.
-- Implement additional logging and monitoring policies to capture more detailed information for future investigations.
-- Integrate threat intelligence feeds to enhance detection capabilities and provide context for similar threats.
-- Restore affected systems to their operational state by applying clean backups and ensuring all security patches are up to date.
-- Conduct a post-incident review to identify gaps in the current security posture and update response plans accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing strong authentication mechanisms, to reduce the risk of future incidents."""
 
 
 [[rule.risk_score_mapping]]
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
index 499a756db25..8155bb2f92e 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,48 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Credential Manipulation - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution designed to detect and respond to threats in real-time. Credential manipulation involves adversaries altering authentication tokens to escalate privileges or maintain access. This detection rule identifies suspicious token activities by monitoring specific alert types and event actions, aligning with MITRE ATT&CK's Access Token Manipulation technique, thus helping to thwart unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather initial context.
-- Examine the event.kind field to confirm that the alert is indeed an alert type and not a false positive or benign event.
-- Check the event.module field to ensure the alert originated from the endgame module, confirming the source of detection.
-- Investigate the endgame.metadata.type field to verify that the alert is categorized as a detection, which indicates a potential threat.
-- Analyze the event.action and endgame.event_subtype_full fields to identify the specific type of token manipulation event that triggered the alert.
-- Correlate the alert with other related events in the same timeframe to identify any patterns or additional suspicious activities.
-- Use Osquery to gather more information about the processes and users involved in the alert. For example, run the following query to list processes with suspicious token privileges: `SELECT pid, name, path, uid, gid FROM processes WHERE on_disk = 1 AND (name LIKE '%token%' OR path LIKE '%token%');`
-- Investigate the user account associated with the alert to determine if there have been any recent changes in privileges or unusual login activities.
-- Review system logs and security logs for any additional signs of credential manipulation or unauthorized access attempts around the time of the alert.
-- Cross-reference the alert with known MITRE ATT&CK techniques, specifically T1134, to understand the potential methods used by the adversary and gather insights into their tactics.
-
-### False positive analysis
-
-- Known false positives for the Credential Manipulation - Detected - Elastic Endgame rule may include legitimate administrative actions where tokens are altered as part of routine maintenance or software updates. These activities can trigger alerts due to their similarity to malicious token manipulation.
-- To manage these false positives, users can create exceptions for specific processes or user accounts that are known to perform legitimate token manipulations regularly. This can be done by identifying the event.action or endgame.event_subtype_full values associated with these benign activities and excluding them from triggering alerts.
-- Another approach is to monitor the frequency and context of the alerts. If certain alerts consistently correlate with non-threatening behaviors, users can adjust the detection rule to ignore these specific patterns while maintaining vigilance for truly suspicious activities.
-- It is also advisable to review and update the list of exceptions periodically to ensure that new legitimate activities are accounted for and that no malicious activities are inadvertently excluded.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the scope of the credential manipulation, including reviewing logs and correlating events to determine the source and method of attack.
-- Reset passwords and authentication tokens for affected accounts and any accounts that may have been accessed using manipulated credentials.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging and monitoring policies to capture detailed authentication and access events, ensuring future incidents can be detected more efficiently.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
-- Restore the affected system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate users on recognizing phishing attempts and other social engineering tactics that could lead to credential manipulation.
-- Apply hardening measures such as enforcing multi-factor authentication (MFA) and implementing least privilege access controls to reduce the risk of future credential manipulation."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
index ba4a8fb6b19..3d28513a582 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,52 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Credential Manipulation - Prevented - Elastic Endgame
-
-Elastic Endgame is a security solution designed to prevent unauthorized credential manipulation, a common tactic used by adversaries to escalate privileges within a system. Attackers often exploit access token manipulation to impersonate legitimate users and gain elevated access. The detection rule leverages event alerts from the Endgame module, specifically targeting prevention events related to token manipulation. By monitoring these events, the rule effectively identifies and thwarts attempts at credential abuse, aligning with the MITRE ATT&CK framework's focus on privilege escalation techniques.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `event.kind`, `event.module`, and `endgame.metadata.type` fields to confirm it is a prevention event related to token manipulation.
-- Examine the `event.action` and `endgame.event_subtype_full` fields to identify the specific type of token manipulation event that was prevented.
-- Check the timestamp of the alert to determine when the credential manipulation attempt occurred and correlate it with other events in the same timeframe.
-- Investigate the source and destination IP addresses associated with the alert to identify the origin of the attack and any potential targets within the network.
-- Analyze the user account involved in the alert to determine if it is a legitimate user or a potential compromised account by reviewing recent login activities and changes.
-- Utilize Osquery to gather additional context on the affected system. For example, run the following query to list recent processes that might have been involved in token manipulation:
-  ```sql
-  SELECT pid, name, path, cmdline, start_time FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));
-  ```
-- Review the system logs and security logs on the affected host for any suspicious activities or anomalies around the time of the alert.
-- Investigate any related alerts or events in the security information and event management (SIEM) system that might indicate a broader attack pattern or campaign.
-- Check for any recent changes in user privileges or group memberships that could be related to the attempted credential manipulation.
-- Collaborate with other security teams to gather intelligence on similar incidents or known threats that might be targeting the organization.
-
-### False positive analysis
-
-- Known false positives for the Credential Manipulation - Prevented - Elastic Endgame rule may include legitimate administrative actions where authorized users perform token manipulation as part of routine system maintenance or software updates. 
-- Another potential false positive scenario could involve automated scripts or security tools that perform token manipulation for legitimate security testing or monitoring purposes.
-- To manage these false positives, users can create exceptions for specific user accounts or processes that are known to perform legitimate token manipulation. This can be done by adding these accounts or processes to an allowlist within the Elastic Endgame configuration.
-- Users should regularly review and update the allowlist to ensure that only verified and non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-- It is also recommended to conduct periodic audits of the exceptions to confirm that no unauthorized or suspicious activities are being inadvertently allowed.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
-- Conduct a thorough investigation to determine the scope of the attack, focusing on identifying compromised accounts and any unauthorized changes made to the system.
-- Reset passwords for all affected accounts and implement multi-factor authentication to enhance security and prevent future unauthorized access.
-- Review and analyze logs from Elastic Endgame and other security tools to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to ensure comprehensive remediation efforts.
-- Restore the system to its operational state by removing any malicious artifacts, applying necessary patches, and verifying the integrity of critical system files.
-- Implement enhanced logging policies to capture detailed information on access token usage and other relevant security events for future investigations.
-- Integrate additional security solutions, such as endpoint detection and response (EDR) tools, to improve visibility and detection capabilities for similar threats.
-- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
-- Educate users on recognizing phishing attempts and other common attack vectors to reduce the risk of credential manipulation in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
index adfeb2d8df6..2e8870a4bed 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,49 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Permission Theft - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution that monitors and detects suspicious activities, such as permission theft, within an environment. Adversaries may exploit access token manipulation to escalate privileges, gaining unauthorized access to resources. The detection rule identifies such threats by analyzing alert events related to token protection, leveraging specific event actions and metadata to pinpoint malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather initial context about the alert.
-- Examine the event.kind field to confirm that the alert is indeed an alert type and not a false positive or benign event.
-- Check the event.module field to ensure the alert is generated by the endgame module, confirming the source of the detection.
-- Analyze the endgame.metadata.type field to verify that the alert is categorized as a detection, indicating a potential security threat.
-- Investigate the event.action and endgame.event_subtype_full fields to determine if the alert is related to token_protection_event, which is indicative of potential access token manipulation.
-- Correlate the alert with other related events in the same timeframe to identify any patterns or additional suspicious activities that might be associated with the permission theft.
-- Use Osquery to gather more information about the processes and tokens involved. For example, run the following Osquery query to list processes with suspicious token privileges: `SELECT pid, name, path, uid, gid FROM processes WHERE on_disk = 1 AND (name LIKE '%token%' OR path LIKE '%token%');`
-- Investigate the user account associated with the alert to determine if there are any signs of compromise or unauthorized access attempts.
-- Review system logs and security logs for any anomalies or unusual activities around the time of the alert to gather additional context.
-- Cross-reference the alert with known MITRE ATT&CK techniques, specifically Privilege Escalation (TA0004) and Access Token Manipulation (T1134), to understand the potential tactics and techniques used by the adversary.
-
-### False positive analysis
-
-- Known false positives for the Permission Theft - Detected - Elastic Endgame rule may include legitimate administrative actions where access tokens are manipulated as part of routine system maintenance or software updates. 
-- Security tools or scripts that automate token management for legitimate purposes might trigger alerts, as they can mimic the behavior of malicious token manipulation.
-- To manage these false positives, users can create exceptions for specific processes or scripts that are known to perform legitimate token manipulation. This can be done by identifying the process names or hashes and excluding them from triggering alerts.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-- Implementing a baseline of normal token manipulation activities within the environment can help in distinguishing between legitimate and suspicious actions, reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Conduct a thorough investigation to identify the source and scope of the permission theft, focusing on the compromised access tokens and any associated user accounts.
-- Revoke and reset credentials for any compromised accounts and invalidate any active sessions to prevent further exploitation.
-- Review and analyze security logs and alerts to identify any additional suspicious activities or indicators of compromise related to access token manipulation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources or expertise are required.
-- Implement enhanced logging and monitoring policies to capture detailed information on access token usage and privilege escalation attempts for future investigations.
-- Integrate additional security tools and solutions, such as endpoint detection and response (EDR) and security information and event management (SIEM) systems, to improve detection and response capabilities.
-- Restore the affected system to its operational state by applying security patches, updating software, and ensuring all security configurations are properly set.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as enforcing least privilege access and multi-factor authentication.
-- Educate and train employees on recognizing and reporting suspicious activities, emphasizing the importance of maintaining strong, unique passwords and adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
index 90427a56d12..24e914d7863 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,48 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Permission Theft - Prevented - Elastic Endgame
-
-Elastic Endgame is a security solution that prevents unauthorized access by monitoring and blocking attempts to manipulate access tokens, a common method for privilege escalation. Adversaries exploit token manipulation to gain elevated permissions illicitly. The detection rule identifies and alerts on such attempts by focusing on specific event types and actions related to token protection, ensuring swift response to potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `event.kind:alert`, `event.module:endgame`, and `endgame.metadata.type:prevention` fields to confirm the alert is related to a prevention event.
-- Examine the `event.action:token_protection_event` or `endgame.event_subtype_full:token_protection_event` fields to identify the specific type of token manipulation attempt that was prevented.
-- Check the timestamp of the alert to determine when the unauthorized access attempt occurred and correlate it with other events in the same timeframe.
-- Investigate the source and destination IP addresses associated with the alert to identify potential malicious actors or compromised systems.
-- Analyze the user account involved in the alert to determine if it has been used in other suspicious activities or if it has been compromised.
-- Use Osquery to gather additional context about the system involved. For example, run the following query to list recent processes that might have been involved in token manipulation: `SELECT pid, name, path, cmdline FROM processes WHERE start_time > (SELECT datetime('now', '-1 hour'));`
-- Review system logs and security logs for any other unusual activities or anomalies around the time of the alert to identify potential patterns or related incidents.
-- Investigate any recent changes to user permissions or access rights that could have facilitated the token manipulation attempt.
-- Check for any known vulnerabilities or exploits that might have been used in conjunction with the token manipulation attempt to gain unauthorized access.
-- Collaborate with other security teams or stakeholders to gather additional insights or context that might aid in understanding the scope and impact of the attempted permission theft.
-
-### False positive analysis
-
-- Known false positives for the Permission Theft - Prevented - Elastic Endgame rule may include legitimate administrative actions where access tokens are manipulated as part of routine system maintenance or software updates. These actions can trigger alerts if they mimic the behavior of token manipulation used in privilege escalation.
-- To manage these false positives, users can create exceptions for specific processes or users that are known to perform legitimate token manipulations. This can be done by identifying the event.action or endgame.event_subtype_full values associated with these benign activities and excluding them from triggering alerts.
-- Another approach is to monitor the frequency and context of the alerts. If certain actions consistently trigger alerts but are verified as non-threatening, users can adjust the detection rule to exclude these specific scenarios, ensuring that only genuine threats are flagged.
-- It is important to regularly review and update the list of exceptions to ensure that new legitimate behaviors are accounted for while maintaining the integrity of the security monitoring system.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and method of the token manipulation attempt, utilizing logs and alerts from Elastic Endgame.
-- Review user accounts and permissions to ensure no unauthorized changes have been made; reset credentials if necessary.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed information on access token usage and manipulation attempts for future investigations.
-- Integrate Elastic Endgame with other security tools such as SIEMs to improve threat detection and response capabilities.
-- Restore the system to its operational state by applying patches, updates, and verifying the integrity of critical system files.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate users on the importance of secure credential management and the risks associated with token manipulation.
-- Implement hardening measures such as enforcing multi-factor authentication and least privilege access to reduce the risk of future privilege escalation attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
index 3144f896d85..1eea20d6f70 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,48 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Injection - Detected - Elastic Endgame
-
-Elastic Endgame is a security solution that identifies malicious activities like process injection, a technique where adversaries inject code into legitimate processes to evade detection and escalate privileges. This detection rule leverages alerts from the Endgame module, focusing on kernel shellcode events, to identify suspicious process injection attempts, aligning with MITRE ATT&CK's T1055 technique for privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather initial context about the detected process injection.
-- Examine the event.kind, event.module, and endgame.metadata.type fields to confirm the alert is a detection type and is related to the Endgame module, ensuring the alert is relevant to process injection.
-- Analyze the event.action and endgame.event_subtype_full fields to verify the presence of kernel_shellcode_event, which indicates a potential process injection attempt.
-- Investigate the parent and child processes involved in the alert by reviewing process lineage data to identify any unusual or unexpected process relationships.
-- Use Osquery to gather additional information about the processes involved. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, ppid, name, path, cmdline FROM processes WHERE pid = <suspicious_process_id>;`
-- Check for any recent changes or anomalies in the system's process tree around the time of the alert to identify any suspicious activities or patterns.
-- Review the system's security logs and any other relevant logs for additional indicators of compromise or related suspicious activities around the time of the alert.
-- Investigate the user account context under which the suspicious process was executed to determine if there are any signs of account compromise or misuse.
-- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attacks.
-- Document all findings and observations during the investigation to maintain a comprehensive record for further analysis or escalation if needed.
-
-### False positive analysis
-
-- Known false positives for the Process Injection - Detected - Elastic Endgame rule may include legitimate software that uses process injection techniques for benign purposes, such as security tools, performance monitoring software, or certain types of debugging applications. These applications might trigger alerts due to their use of kernel shellcode events, which are also used by malicious actors.
-- To manage these false positives, users can create exceptions for specific processes or applications that are known to use process injection legitimately. This can be done by identifying the process names or hashes of the trusted applications and adding them to an exclusion list within the Elastic Endgame configuration. This approach helps in reducing noise and focusing on truly suspicious activities.
-- Regularly review and update the exception list to ensure that only verified and trusted applications are excluded. This helps maintain a balance between minimizing false positives and ensuring that new threats are not overlooked.
-- Collaborate with IT and security teams to understand the context of the detected process injection events, ensuring that any exclusions made do not inadvertently allow malicious activities to go undetected.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the threat and to contain the malicious activity.
-- Conduct a thorough investigation to identify the source and scope of the process injection, utilizing forensic tools to analyze memory dumps and process trees.
-- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has established persistence mechanisms.
-- Review and update endpoint detection and response (EDR) policies to ensure comprehensive logging of process creation, network connections, and code injection attempts.
-- Implement additional security measures such as application whitelisting and enhanced monitoring of high-risk processes to prevent future process injection attempts.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users on recognizing signs of potential compromise and encourage reporting of suspicious activities to improve early detection.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework into security operations to enhance detection capabilities and contextual understanding of threats."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
index 79c2c31346f..8b96514519b 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,46 +36,6 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Injection - Prevented - Elastic Endgame
-
-Elastic Endgame is a security solution that prevents malicious activities like process injection, a technique where adversaries insert code into legitimate processes to evade detection and escalate privileges. Attackers exploit this to execute arbitrary code stealthily. The detection rule identifies such threats by monitoring alerts for specific kernel shellcode events, indicating a prevention action against process injection attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on fields like `event.kind`, `event.module`, `endgame.metadata.type`, and `event.action` to confirm the nature of the prevention.
-- Examine the `endgame.event_subtype_full` field to verify if the alert is related to a `kernel_shellcode_event`, which indicates a process injection attempt.
-- Check the timestamp of the alert to determine when the process injection attempt occurred and correlate it with other events in the system around the same time.
-- Identify the process targeted by the injection attempt by reviewing process-related fields such as `process.name`, `process.pid`, and `process.executable`.
-- Investigate the parent process using `process.parent.name` and `process.parent.pid` to understand the process hierarchy and identify potential sources of the injection attempt.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list open network connections for the process: `SELECT * FROM process_open_sockets WHERE pid = <process.pid>;`.
-- Analyze the user context under which the process was running by examining fields like `user.name` and `user.id` to assess if the user account might have been compromised.
-- Review recent login events and user activity logs to identify any suspicious behavior or unauthorized access attempts that could be related to the process injection.
-- Cross-reference the alert with other security tools and logs, such as firewall logs or intrusion detection systems, to identify any related suspicious activities or patterns.
-- Document all findings and observations, including any anomalies or patterns, to build a comprehensive understanding of the incident and facilitate further investigation if needed.
-
-### False positive analysis
-
-- Known false positives for the Process Injection - Prevented - Elastic Endgame rule may include legitimate software that uses process injection techniques for benign purposes, such as certain security tools, software debuggers, or performance monitoring applications. These applications might trigger alerts due to their behavior, which resembles malicious process injection.
-- To manage these false positives, users can create exceptions for specific applications or processes that are known to use process injection legitimately. This can be done by identifying the process names or hashes of the trusted applications and adding them to an exclusion list within the Elastic Endgame configuration. This approach helps in reducing noise and focusing on genuine threats while maintaining security efficacy.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the threat.
-- Conduct a thorough investigation to identify the source and scope of the process injection attempt, using available logs and alerts.
-- Analyze the process and code involved in the injection attempt to understand the attacker's objectives and methods.
-- Remove any malicious code or unauthorized changes identified during the investigation from the affected system.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the attacker.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response if necessary.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve threat detection and response capabilities.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure all security measures are in place.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/threat_intel/threat_intel_indicator_match_address.toml b/rules/threat_intel/threat_intel_indicator_match_address.toml
index 13261edbb75..6026f6f265d 100644
--- a/rules/threat_intel/threat_intel_indicator_match_address.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_address.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel IP Address Indicator Match"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating Threat Intel IP Address Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_hash.toml b/rules/threat_intel/threat_intel_indicator_match_hash.toml
index 577dd771593..236fb01db80 100644
--- a/rules/threat_intel/threat_intel_indicator_match_hash.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_hash.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel Hash Indicator Match"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating Threat Intel Hash Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_registry.toml b/rules/threat_intel/threat_intel_indicator_match_registry.toml
index 15173c681fb..5612c34e435 100644
--- a/rules/threat_intel/threat_intel_indicator_match_registry.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_registry.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel Windows Registry Indicator Match"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating Threat Intel Windows Registry Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_url.toml b/rules/threat_intel/threat_intel_indicator_match_url.toml
index 33d08abe5a2..1f829b8c28c 100644
--- a/rules/threat_intel/threat_intel_indicator_match_url.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_url.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel URL Indicator Match"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating Threat Intel URL Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_rapid7_threat_command.toml b/rules/threat_intel/threat_intel_rapid7_threat_command.toml
index ecba0a4dcf4..28bd096da4b 100644
--- a/rules/threat_intel/threat_intel_rapid7_threat_command.toml
+++ b/rules/threat_intel/threat_intel_rapid7_threat_command.toml
@@ -4,7 +4,7 @@ integration = ["ti_rapid7_threat_command"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for Rapid7 Threat Command Integration"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/08"
+updated_date = "2024/08/06"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 max_signals = 10000
 name = "Rapid7 Threat Command CVEs Correlation"
-note = """## Triage and analysis
+note = """## Triage and Analysis
 
 ### Investigating Rapid7 Threat Command CVEs Correlation
 
diff --git a/rules/windows/collection_email_outlook_mailbox_via_com.toml b/rules/windows/collection_email_outlook_mailbox_via_com.toml
index 5f904f083f1..feb34e149a7 100644
--- a/rules/windows/collection_email_outlook_mailbox_via_com.toml
+++ b/rules/windows/collection_email_outlook_mailbox_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/20"
 
 [rule]
 author = ["Elastic"]
@@ -47,48 +47,6 @@ sequence with maxspan=1m
 [process where host.os.type == "windows" and event.action == "start" and process.name : "OUTLOOK.EXE" and
   process.Ext.effective_parent.name != null] by process.Ext.effective_parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Inter-Process Communication via Outlook
-
-Outlook's Component Object Model (COM) allows inter-process communication, enabling applications to automate tasks like email management. Adversaries exploit this by using unusual processes to interact with Outlook, potentially accessing sensitive emails or sending messages without user consent. The detection rule identifies such anomalies by monitoring unexpected processes initiating communication with Outlook, focusing on untrusted or newly created executables, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process that initiated communication with Outlook, focusing on the `process.name` and `process.entity_id` fields.
-- Check the `process.code_signature.trusted` and `process.code_signature.exists` fields to determine if the initiating process is signed and trusted. Investigate any unsigned or untrusted processes further.
-- Analyze the `process.Ext.relative_file_creation_time` and `process.Ext.relative_file_name_modify_time` fields to assess if the process is newly created or recently modified, which could indicate suspicious activity.
-- Examine the `process.Ext.effective_parent.name` and `process.Ext.effective_parent.entity_id` fields to identify the parent process of Outlook and determine if it is expected or unusual.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes and their parent processes: `SELECT pid, name, path, parent FROM processes WHERE name = '<suspicious_process_name>';`.
-- Investigate the network activity of the suspicious process using network monitoring tools to check for any unusual outbound connections that could indicate data exfiltration.
-- Review recent email activity in Outlook to identify any unauthorized access or email sending that aligns with the timeline of the suspicious process execution.
-- Check the system's event logs for any additional indicators of compromise or related suspicious activities around the time the alert was triggered.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack campaign.
-- Document all findings and observations in a detailed report to provide context for further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Legitimate administrative scripts or automation tools may trigger the rule if they interact with Outlook using COM, especially if they are newly created or lack a trusted code signature. Users should review these scripts and, if deemed safe, add them to an exception list to prevent future alerts.
-- Software updates or installations might temporarily create new executables that interact with Outlook, leading to false positives. Monitoring the frequency and context of these alerts can help determine if they are benign, and trusted software can be whitelisted.
-- Custom business applications that automate email tasks via Outlook may be flagged if they are not widely recognized or lack a valid code signature. Users should verify the legitimacy of these applications and consider excluding them from the rule if they are part of regular business operations.
-- In environments where developers frequently test new applications or scripts that interact with Outlook, these activities might be mistakenly identified as threats. Establishing a process to review and approve these activities can help in creating appropriate exceptions.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the suspicious process and determine if any sensitive information was accessed or exfiltrated.
-- Terminate any malicious or suspicious processes identified during the investigation to prevent further malicious activity.
-- Review email logs and Outlook activity to identify any unauthorized access or email transmissions.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and inter-process communication events for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by applying necessary patches, updates, and security configurations.
-- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities or misconfigurations.
-- Implement hardening measures such as application whitelisting, endpoint detection and response (EDR) solutions, and user training to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/collection_posh_webcam_video_capture.toml b/rules/windows/collection_posh_webcam_video_capture.toml
index f723df35eaf..a0006542832 100644
--- a/rules/windows/collection_posh_webcam_video_capture.toml
+++ b/rules/windows/collection_posh_webcam_video_capture.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/18"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -67,53 +67,6 @@ event.category:process and host.os.type:windows and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Webcam Video Capture Capabilities
-
-PowerShell, a powerful scripting language in Windows, can interface with system components like webcams. Adversaries exploit this by scripting webcam access to capture video, potentially for espionage or extortion. The detection rule identifies scripts using specific webcam-related functions and libraries, flagging suspicious activity indicative of video capture attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific PowerShell script block text that triggered the detection, focusing on keywords like "NewFrameEventHandler" or "VideoCaptureDevice".
-- Examine the process execution details, including the parent process, to understand the context in which the PowerShell script was executed.
-- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Investigate the source and integrity of the PowerShell script by reviewing its file path and hash values, if available, to identify any known malicious scripts.
-- Use Osquery to list all running PowerShell processes and their command-line arguments to identify any other suspicious activity:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE name = 'powershell.exe';
-  ```
-- Analyze recent login events and user activity on the host to identify any unauthorized access attempts that could correlate with the script execution.
-- Review network connections initiated by the host around the time of the alert to detect any suspicious outbound traffic that might indicate data exfiltration.
-- Check for any recent changes to webcam-related system settings or drivers that could suggest tampering or unauthorized access attempts.
-- Investigate any other alerts or logs from the same host or user account to identify patterns or additional indicators of compromise.
-- Correlate the findings with threat intelligence sources to determine if the activity matches known attack patterns or threat actor behaviors.
-
-### False positive analysis
-
-- Legitimate software or administrative scripts that utilize webcam functionalities for valid purposes, such as video conferencing applications or security monitoring tools, may trigger this detection rule. 
-- Developers or IT administrators testing webcam integration or functionality in a controlled environment might inadvertently match the rule's criteria.
-- Automated system health checks or diagnostics that access webcam components to verify hardware status could be flagged as suspicious.
-- To manage these false positives, users can create exceptions for known and trusted scripts or applications by whitelisting specific script hashes or paths.
-- Regularly review and update the exclusion list to ensure that only verified non-threatening activities are exempted, maintaining a balance between security and operational needs.
-- Implement logging and monitoring to track the behavior of excluded scripts, ensuring they do not deviate from expected patterns or access unauthorized resources.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the presence of malicious PowerShell scripts by reviewing script block logs and process execution details.
-- Terminate any suspicious PowerShell processes identified during the investigation to halt ongoing malicious activities.
-- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.
-- Reset credentials and review user account permissions on the affected system to ensure no unauthorized access persists.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed PowerShell activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Restore the system from a known good backup to ensure the removal of any persistent threats and return the system to its operational state.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
-- Educate users on recognizing phishing attempts and suspicious activities to reduce the risk of future incidents involving unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
index bbb27bd1ba1..915c09f4456 100644
--- a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
+++ b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,50 +55,6 @@ network where host.os.type == "windows" and network.protocol == "dns" and
   /* Insert noisy false positives here */
   not process.name : ("svchost.exe", "MicrosoftEdge*.exe", "msedge.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Connection to Commonly Abused Free SSL Certificate Providers
-
-Free SSL certificates, like those from Let's Encrypt, enable secure web traffic by encrypting data. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process executable path and domain name involved in the connection attempt. Focus on the `process.executable` and `dns.question.name` fields.
-- Verify the legitimacy of the domain by checking if it is associated with known malicious activities or if it is a legitimate service using free SSL certificates.
-- Investigate the process executable path to determine if it is a legitimate Windows process or if it has been tampered with. Pay attention to the paths specified in the query, such as `C:\\Windows\\System32\\*.exe`.
-- Use Osquery to gather additional context about the process. For example, run the following query to get details about the process and its parent process:
-  ```sql
-  SELECT pid, name, path, parent, cmdline FROM processes WHERE path = 'C:\\\\Windows\\\\System32\\\\<specific_process>.exe';
-  ```
-- Check the process's parent process to understand how it was spawned and if it aligns with expected behavior.
-- Examine the network traffic associated with the process to identify any unusual patterns or additional connections to suspicious domains.
-- Cross-reference the process and domain information with threat intelligence sources to identify any known indicators of compromise (IOCs).
-- Review system logs and event logs for any additional suspicious activities or anomalies around the time of the alert.
-- Investigate the user account associated with the process to determine if there are any signs of compromise or unauthorized access.
-- Consider running a full antivirus or endpoint detection and response (EDR) scan on the affected system to identify any additional threats or malware.
-
-### False positive analysis
-
-- **Common System Processes**: Some native Windows processes, such as `svchost.exe`, `MicrosoftEdge*.exe`, and `msedge.exe`, are known to generate network traffic that may appear suspicious but are typically benign. These processes are often involved in legitimate system operations and updates, which can include accessing domains secured with free SSL certificates.
-- **Web Browsers and Updates**: Web browsers and system update services frequently connect to a variety of domains, including those using free SSL certificates, for legitimate purposes such as downloading updates or accessing web content. These activities can trigger false positives if not properly excluded.
-- **Handling False Positives**: Users can manage false positives by creating exceptions for known benign processes and domains. This involves updating the detection rule to exclude specific process names or paths that are frequently involved in non-threatening activities. Regularly reviewing and updating these exceptions based on observed network behavior can help maintain the accuracy of the detection rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement.
-- Conduct a thorough investigation of the flagged process and domain connections to determine if they are indeed malicious or false positives.
-- Review and analyze network traffic logs to identify any additional suspicious activities or connections related to the alert.
-- If malicious activity is confirmed, terminate the suspicious processes and remove any associated malicious files or software from the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
-- Integrate threat intelligence feeds to update and refine detection rules with the latest indicators of compromise (IOCs) related to free SSL certificate abuse.
-- Restore the system to its operational state by applying necessary patches, updates, and verifying the integrity of system files.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as application whitelisting, network segmentation, and regular security audits to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_iexplore_via_com.toml b/rules/windows/command_and_control_iexplore_via_com.toml
index 099539a7ed3..79424244132 100644
--- a/rules/windows/command_and_control_iexplore_via_com.toml
+++ b/rules/windows/command_and_control_iexplore_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -49,52 +49,6 @@ sequence by host.id, user.name with maxspan = 5s
     )
   ] /* with runs=5 */
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Command and Control via Internet Explorer
-
-Internet Explorer can be manipulated through the Component Object Model (COM) to initiate network connections, potentially bypassing security measures. Adversaries exploit this by embedding IE in processes like rundll32.exe, making unusual DNS requests. The detection rule identifies such anomalies by monitoring for IE's unexpected network activity, excluding legitimate Microsoft-related domains, to flag potential command and control activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of Internet Explorer (iexplore.exe) being started via the Component Object Model (COM) with unusual network activity.
-- Verify the parent process of Internet Explorer by checking if it was started by processes like rundll32.exe or regsvr32.exe, as indicated in the query.
-- Examine the command-line arguments of the parent process to ensure it includes the "-Embedding" argument, which suggests COM usage.
-- Investigate the DNS requests made by Internet Explorer to identify any suspicious or non-whitelisted domains, as specified in the query.
-- Use Osquery to gather additional context on the processes involved. For example, run the following query to list processes with their parent process IDs and command-line arguments:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'iexplore.exe' OR name = 'rundll32.exe' OR name = 'regsvr32.exe';
-  ```
-- Check the network connections established by Internet Explorer using network monitoring tools or logs to identify any unusual or unexpected connections.
-- Correlate the timeline of the alert with other security events or logs to identify any related suspicious activities or anomalies on the host.
-- Investigate the user context (user.name) under which the suspicious processes were executed to determine if it aligns with expected user behavior.
-- Review the host's security posture and configuration to identify any potential vulnerabilities or misconfigurations that could have been exploited.
-- Consult threat intelligence sources to determine if the identified domains or IP addresses are associated with known malicious activities or command and control infrastructure.
-
-### False positive analysis
-
-- Legitimate enterprise applications may use Internet Explorer via COM for internal processes, leading to false positives if these applications frequently access non-Microsoft domains.
-- Automated scripts or administrative tools that leverage Internet Explorer for network tasks could trigger alerts if they connect to internal or third-party services not listed in the exclusion list.
-- Users can manage false positives by identifying and documenting regular network patterns of known safe applications and adding these domains to the exclusion list in the detection rule.
-- Regularly review and update the exclusion list to include any new legitimate domains that are frequently accessed by Internet Explorer in the organization’s environment.
-- Consider implementing a whitelist approach for specific processes or network activities that are known to be safe, reducing the likelihood of false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further command and control communication.
-- Conduct a thorough investigation to identify any additional compromised systems by reviewing network logs and endpoint detection data.
-- Terminate any suspicious processes associated with Internet Explorer and COM objects, such as rundll32.exe or regsvr32.exe, that are not part of legitimate operations.
-- Remove any unauthorized or malicious COM objects and DLLs, such as IEProxy.dll, from the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
-- Implement enhanced logging policies to capture detailed process creation, network connections, and DNS queries for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Apply security patches and updates to Internet Explorer and the operating system to mitigate known vulnerabilities.
-- Educate users on the risks of using outdated browsers and encourage the use of more secure alternatives to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_outlook_home_page.toml b/rules/windows/command_and_control_outlook_home_page.toml
index 9a3c4225444..e91e82eb0d6 100644
--- a/rules/windows/command_and_control_outlook_home_page.toml
+++ b/rules/windows/command_and_control_outlook_home_page.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/01"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,48 +49,6 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
         "USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL"
     ) and registry.data.strings : "*http*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Outlook Home Page Registry Modification
-
-The Outlook Home Page feature allows users to set a webpage as the default view for folders, enhancing productivity. However, adversaries can exploit this by modifying registry keys to redirect to malicious URLs, enabling command and control or persistence. The detection rule identifies suspicious registry changes by monitoring specific paths and URL patterns, alerting analysts to potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path and URL involved in the modification, focusing on the `registry.path` and `registry.data.strings` fields.
-- Verify the legitimacy of the URL by checking if it is a known or trusted domain, and assess its reputation using threat intelligence sources.
-- Examine the user account associated with the registry modification to determine if it aligns with expected behavior or if it appears suspicious.
-- Check the modification timestamp to correlate with any known user activity or scheduled tasks that might explain the change.
-- Investigate the host machine for any other signs of compromise, such as unusual network connections or processes, using endpoint detection tools.
-- Utilize Osquery to further inspect the registry changes with a query like: `SELECT * FROM registry WHERE path LIKE 'HKCU\\\\%\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\%\\\\Outlook\\\\Webview\\\\Inbox\\\\URL';` to gather more context on the modification.
-- Cross-reference the registry modification with recent email activity in Outlook to identify any potential phishing attempts or malicious emails that could have led to the change.
-- Analyze system logs for any other registry changes or suspicious activities around the same time frame to identify potential patterns or related incidents.
-- Investigate any recent software installations or updates on the host that might have inadvertently caused the registry modification.
-- Consult with the user or IT support to verify if the change was intentional or part of a legitimate configuration change.
-
-### False positive analysis
-
-- Legitimate software updates or installations may modify the Outlook Home Page registry keys, leading to false positives. Users should verify if recent updates or installations correspond with the detected changes.
-- Custom organizational policies or scripts that configure Outlook settings for productivity purposes might trigger alerts. Analysts should review these policies and consider excluding known safe configurations.
-- Users who frequently change their Outlook Home Page settings for personalization might inadvertently cause alerts. Monitoring user behavior patterns can help distinguish between benign and suspicious activities.
-- To manage false positives, users can create exceptions for known safe registry paths or URL patterns that are frequently modified by trusted applications or processes. This can be done by updating the detection rule to exclude these specific cases.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further command and control communication.
-- Conduct a thorough investigation to identify any additional compromised systems by reviewing logs and alerts related to the registry modification.
-- Verify the legitimacy of the URL set in the registry and remove or correct any unauthorized or malicious entries.
-- Restore the registry settings to their default state using a known good backup or by manually resetting the affected keys.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed registry changes and network traffic for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Apply security patches and updates to the operating system and Outlook to mitigate known vulnerabilities.
-- Educate users on recognizing phishing attempts and suspicious activities that could lead to registry modifications.
-- Consider deploying application whitelisting and endpoint detection and response (EDR) solutions to prevent unauthorized changes and enhance system hardening."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_screenconnect_childproc.toml b/rules/windows/command_and_control_screenconnect_childproc.toml
index 1ae6e98f4ff..890ac2e7d0f 100644
--- a/rules/windows/command_and_control_screenconnect_childproc.toml
+++ b/rules/windows/command_and_control_screenconnect_childproc.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 
 [rule]
 author = ["Elastic"]
@@ -59,49 +59,6 @@ process where host.os.type == "windows" and event.type == "start" and
                    "ssh.exe", "scp.exe", "wevtutil.exe", "wget.exe", "wmic.exe")
    )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious ScreenConnect Client Child Process
-
-ScreenConnect, a remote access tool, facilitates legitimate remote support by allowing users to control systems remotely. However, adversaries can exploit it to execute unauthorized commands, leveraging its access capabilities. The detection rule identifies unusual child processes spawned by ScreenConnect, such as PowerShell or cmd.exe, which may indicate malicious activity, by monitoring specific process names and arguments that are commonly used in attacks.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific child process and arguments that triggered the rule, focusing on the `process.name` and `process.args` fields.
-- Check the parent process details, specifically the `process.parent.name`, to confirm it is one of the ScreenConnect client processes listed in the query.
-- Investigate the user account associated with the process execution to determine if it aligns with expected usage patterns or if it appears suspicious.
-- Examine the network activity around the time of the alert to identify any unusual connections or data transfers, especially those involving external IP addresses.
-- Use Osquery to gather additional context on the suspicious process. For example, run the following query to list all processes spawned by ScreenConnect clients: `SELECT pid, name, path, cmdline FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name IN ('ScreenConnect.ClientService.exe', 'ScreenConnect.WindowsClient.exe', 'ScreenConnect.WindowsBackstageShell.exe', 'ScreenConnect.WindowsFileManager.exe'));`
-- Analyze the command-line arguments (`process.args`) for any encoded or obfuscated content, particularly if PowerShell is involved, to understand the intent of the command.
-- Check for any recent changes to scheduled tasks or services on the host, especially if `schtasks.exe` or `sc.exe` were involved, to identify potential persistence mechanisms.
-- Review the system's event logs for any additional context or anomalies around the time of the alert, focusing on security and application logs.
-- Investigate any file modifications or creations that occurred around the time of the alert, especially if `msiexec.exe` or `rundll32.exe` were involved, to identify potential payloads or malicious files.
-- Correlate the alert with other security events or alerts in your environment to determine if this is part of a broader attack campaign or isolated incident.
-
-### False positive analysis
-
-- Legitimate IT support activities: ScreenConnect is often used by IT support teams to perform legitimate tasks that may involve running scripts or commands, such as PowerShell or cmd.exe, which can trigger the detection rule. Users can handle these by creating exceptions for known IT support activities or specific user accounts that regularly perform these tasks.
-- Automated maintenance scripts: Organizations may have automated scripts that run through ScreenConnect for system maintenance or updates, which could be flagged as suspicious. To manage this, users can exclude specific scripts or processes that are verified as part of routine maintenance.
-- Software installations and updates: ScreenConnect might be used to deploy software updates or installations that involve processes like msiexec.exe, which could be misidentified as malicious. Users should document and exclude these known software deployment activities from the detection rule.
-- Remote troubleshooting: During remote troubleshooting sessions, support staff might use tools like net.exe or schtasks.exe to diagnose and fix issues, which could be mistaken for malicious activity. Users can create exceptions for these processes when executed by trusted support personnel.
-- Custom scripts or tools: Organizations may use custom scripts or third-party tools that are executed via ScreenConnect for specific business needs. Users should review and whitelist these custom tools to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the legitimacy of the ScreenConnect activity by reviewing logs and correlating with authorized access requests.
-- Terminate any suspicious processes identified in the alert, such as PowerShell or cmd.exe, that were spawned by ScreenConnect.
-- Analyze the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts.
-- Reset credentials for any accounts that may have been compromised, focusing on those with administrative privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing multi-factor authentication for remote access tools like ScreenConnect."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_tunnel_vscode.toml b/rules/windows/command_and_control_tunnel_vscode.toml
index ada93724c9d..d40001f8bc6 100644
--- a/rules/windows/command_and_control_tunnel_vscode.toml
+++ b/rules/windows/command_and_control_tunnel_vscode.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 
 [rule]
 author = ["Elastic"]
@@ -45,48 +45,6 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and 
   not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Establish VScode Remote Tunnel
-
-Visual Studio Code (VSCode) offers a feature to establish remote tunnels, enabling developers to connect to remote environments seamlessly. This functionality, while beneficial for legitimate remote development, can be exploited by adversaries to gain unauthorized access or control over systems. The detection rule identifies suspicious attempts by monitoring the execution of VSCode binaries with specific command-line arguments indicative of tunnel creation, excluding benign processes, thus helping to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the "tunnel" command-line argument in the process execution, as this is a key indicator of a potential remote tunnel attempt.
-- Verify the process name to ensure it matches "code*.exe" and check if the process arguments include "--accept-server-license-terms," which could indicate an attempt to establish a remote connection.
-- Examine the parent process name to determine if it is "Code.exe," as this could help differentiate between legitimate and suspicious activity.
-- Check the process execution time and correlate it with user activity logs to determine if the execution aligns with expected user behavior or work hours.
-- Investigate the user account associated with the process execution to verify if the user has a legitimate reason to establish a remote tunnel.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with the "tunnel" argument: `SELECT pid, name, path, cmdline, parent FROM processes WHERE cmdline LIKE '%tunnel%';`
-- Analyze network logs to identify any unusual outbound connections initiated by the process, focusing on connections to known VSCode or GitHub endpoints.
-- Review system logs for any recent changes or installations that might explain the presence of the VSCode remote tunnel feature.
-- Check for any recent alerts or incidents involving the same user or system to identify patterns or repeated suspicious behavior.
-- Consult with the user or system owner to gather additional context about the necessity and legitimacy of the remote tunnel attempt, if possible.
-
-### False positive analysis
-
-- Developers frequently using VSCode for legitimate remote development may trigger this rule when establishing remote tunnels for valid purposes, such as connecting to a remote development environment or a GitHub Codespace.
-- Automated scripts or CI/CD pipelines that utilize VSCode's remote capabilities for deployment or testing can also generate false positives if they include the tunnel command-line arguments.
-- To manage these false positives, users can create exceptions for specific processes or users known to regularly perform legitimate remote development activities. This can be done by excluding certain process names or command-line arguments that are consistently associated with non-threatening behavior.
-- Monitoring the frequency and context of alerts can help distinguish between legitimate use and potential threats. Users can adjust the detection rule to ignore processes initiated by trusted users or systems, reducing unnecessary alerts while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the intrusion, including identifying any other systems that may have been compromised.
-- Review system logs and VSCode activity to trace the origin of the tunnel creation attempt and gather evidence for further analysis.
-- Terminate any unauthorized VSCode remote tunnel sessions and remove any malicious binaries or scripts found on the system.
-- Change all credentials and access tokens that may have been exposed or compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
-- Implement enhanced logging policies to capture detailed process execution and network activity related to VSCode and other remote access tools.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by reinstalling affected software and applying the latest security patches and updates.
-- Harden the system by disabling unnecessary remote access features, enforcing strong authentication mechanisms, and conducting regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_adidns_wildcard.toml b/rules/windows/credential_access_adidns_wildcard.toml
index 7dec77c586d..7b42d66d267 100644
--- a/rules/windows/credential_access_adidns_wildcard.toml
+++ b/rules/windows/credential_access_adidns_wildcard.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,49 +66,6 @@ query = '''
 any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and
     event.code == "5137" and startsWith(winlog.event_data.ObjectDN, "DC=*,")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential ADIDNS Poisoning via Wildcard Record Creation
-
-Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create wildcard DNS records, redirecting traffic and enabling man-in-the-middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes, focusing on suspicious wildcard record creation activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of event code "5137" and ensure the event action is either "Directory Service Changes" or "directory-service-object-modified".
-- Examine the `winlog.event_data.ObjectDN` field to identify the specific DNS object that was modified, ensuring it starts with "DC=*," which indicates a wildcard record.
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time for additional context.
-- Identify the user account associated with the event to determine if it is a legitimate account or potentially compromised. Look for anomalies in the account's recent activities.
-- Investigate the source IP address and hostname from which the change was made to verify if it is a known and trusted system within the network.
-- Use Osquery to gather additional information about the system involved. For example, run the following query to list recent DNS changes on the system: `SELECT * FROM dns_cache WHERE name LIKE '%';`
-- Analyze network traffic logs to identify any unusual DNS queries or redirections that might indicate exploitation of the wildcard record.
-- Cross-reference the event with other security logs, such as authentication logs, to identify any suspicious login attempts or lateral movement activities.
-- Check for any other recent changes in the DNS zone that might indicate a broader attack or misconfiguration.
-- Consult with the system administrators to verify if the DNS change was authorized and part of a legitimate configuration update.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or changes made by IT administrators to DNS records can trigger this rule. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
-- Automated system processes: Some automated processes or scripts that modify DNS records as part of their normal operation may be flagged. Identify these processes and exclude them by their specific attributes, such as the account or system name.
-- Legitimate software installations: Certain software installations or updates may modify DNS settings, leading to false positives. Monitor installation logs and exclude these events if they align with known software changes.
-- Internal network changes: Changes in network infrastructure, such as the addition of new subdomains or services, might be misinterpreted as suspicious. Document these changes and adjust the rule to recognize them as non-threatening.
-- Testing environments: Activities in testing or development environments can mimic suspicious behavior. Clearly separate these environments in monitoring tools and apply different rules or exceptions to avoid false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected systems from the network to prevent further exploitation of the wildcard DNS records.
-- Conduct a thorough investigation to identify the source of the unauthorized DNS record creation, focusing on recent changes and user activities.
-- Review and audit Active Directory permissions, specifically for DNS record creation, to ensure that only authorized personnel have the necessary access.
-- Remove any unauthorized wildcard DNS records and verify the integrity of existing DNS records to ensure they have not been tampered with.
-- Implement enhanced logging and monitoring for DNS changes, including enabling detailed auditing of directory service changes to capture future unauthorized modifications.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
-- Escalate the incident to the security operations center (SOC) and, if necessary, involve incident response teams to handle potential data breaches.
-- Restore affected systems to their operational state by applying clean backups and verifying system integrity.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting DNS zone transfers, applying least privilege principles, and regularly reviewing and updating security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_adidns_wpad_record.toml b/rules/windows/credential_access_adidns_wpad_record.toml
index ba11a1ce67e..94388242ee5 100644
--- a/rules/windows/credential_access_adidns_wpad_record.toml
+++ b/rules/windows/credential_access_adidns_wpad_record.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -63,49 +63,6 @@ query = '''
 any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and
     event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential WPAD Spoofing via DNS Record Creation
-
-Web Proxy Auto-Discovery (WPAD) helps devices automatically locate proxy configuration files, streamlining network management. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule monitors Windows environments for suspicious DNS record changes, specifically targeting modifications that suggest WPAD spoofing attempts, thereby identifying potential security threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event code "5137" and the modification of the "DC=wpad,*" object in the event data, which indicates a DNS record change related to WPAD.
-- Verify the identity of the user or process that initiated the DNS record change by examining the associated user account details in the event logs.
-- Check the timestamp of the event to determine when the DNS record change occurred and correlate it with other suspicious activities in the network around the same time.
-- Investigate the source IP address and hostname of the system where the DNS record change was initiated to assess if it is a known and trusted device within the network.
-- Utilize Osquery to gather additional context on the system involved. For example, run the following Osquery query to list recent DNS changes: `SELECT * FROM dns_resolvers WHERE domain = 'wpad';`
-- Examine the system's network configuration and proxy settings to identify any unauthorized or unexpected changes that could indicate WPAD exploitation.
-- Cross-reference the event with other security logs, such as firewall or intrusion detection system logs, to identify any related network traffic anomalies or potential lateral movement attempts.
-- Investigate any recent changes to the Global Query Block List (GQBL) settings on the affected system to determine if it was disabled or altered to facilitate WPAD spoofing.
-- Review historical logs for similar DNS record changes or patterns that might suggest a broader or ongoing attack campaign targeting WPAD.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently exploiting WPAD vulnerabilities, and assess if the observed activity aligns with these threats.
-
-### False positive analysis
-
-- Legitimate network changes: Organizations may intentionally create or modify DNS records for WPAD as part of legitimate network configuration or updates. These changes can trigger the detection rule, leading to false positives. To manage this, users can maintain a list of authorized changes and compare them against detected events.
-- Testing and development environments: In environments where network configurations are frequently tested or modified, such as development or testing labs, DNS record changes related to WPAD might be common and benign. Users can create exceptions for these environments to reduce noise.
-- Third-party software: Some network management or security tools might automatically modify DNS records, including WPAD, as part of their operations. Identifying these tools and excluding their actions from the detection rule can help minimize false positives.
-- Temporary network setups: During events like conferences or temporary setups, network administrators might create WPAD records to facilitate proxy configurations. Users should document these temporary changes and exclude them from triggering alerts.
-- Regular audits and reviews: Conducting regular audits of DNS records and reviewing the detection rule's alerts can help distinguish between legitimate changes and potential threats, allowing users to refine exceptions over time.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and data interception.
-- Verify the presence of unauthorized "wpad" DNS records and remove them to mitigate the spoofing attempt.
-- Conduct a thorough investigation to identify the source of the DNS record change, focusing on recent administrative activities and user accounts with elevated privileges.
-- Review and re-enable the Global Query Block List (GQBL) if it has been disabled, ensuring that "wpad" is included to prevent future exploitation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for DNS changes and directory service modifications to detect similar threats in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Restore the system to its operational state by applying security patches, updating configurations, and conducting a full system scan to ensure no malware remains.
-- Educate users and administrators on the risks associated with WPAD and the importance of maintaining secure DNS configurations.
-- Review and update security policies and procedures to include specific measures against WPAD spoofing and related adversary-in-the-middle tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_dcsync_user_backdoor.toml b/rules/windows/credential_access_dcsync_user_backdoor.toml
index 4d0bf6b3c5d..409b70d352e 100644
--- a/rules/windows/credential_access_dcsync_user_backdoor.toml
+++ b/rules/windows/credential_access_dcsync_user_backdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -17,50 +17,7 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Potential Active Directory Replication Account Backdoor"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Active Directory Replication Account Backdoor
-
-Active Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to grant replication rights to unauthorized accounts, enabling them to extract sensitive credential data. The detection rule identifies suspicious changes to the nTSecurityDescriptor attribute, which could indicate an attempt to establish a backdoor for credential access. By monitoring specific event codes and attribute modifications, the rule helps detect unauthorized replication rights assignments, potentially thwarting credential dumping activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of event code 5136, which indicates a directory service object modification, and verify that the modification involves the nTSecurityDescriptor attribute.
-- Examine the specific user or computer account mentioned in the alert to determine if it has been granted unauthorized replication rights, focusing on the presence of the GUIDs: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, and 89e95b76-444d-4c62-991a-0facbeda640c.
-- Check the security logs for any recent logins or activities associated with the suspicious account to identify any unusual patterns or behaviors.
-- Use Osquery to gather additional context about the suspicious account by running a query such as: `SELECT * FROM users WHERE uid = '<suspicious_account_uid>';` to retrieve detailed information about the account.
-- Investigate the history of changes to the nTSecurityDescriptor attribute for the affected domain object to identify any other unauthorized modifications or patterns.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack campaign or isolated incident.
-- Review the Active Directory audit logs to identify any other accounts that may have been granted similar unauthorized replication rights.
-- Analyze network traffic logs to detect any unusual data exfiltration activities that may be associated with the compromised account.
-- Consult with the Active Directory administrators to verify if the changes were authorized or part of a legitimate administrative task.
-- Document all findings and gather evidence to support further investigation or escalation to the appropriate security team.
-
-### False positive analysis
-
-- Routine administrative tasks: Changes to the nTSecurityDescriptor attribute may occur during legitimate administrative activities, such as when IT personnel update permissions for maintenance or configuration purposes. Users can handle these by identifying and excluding known administrative accounts or activities from the detection rule.
-- Software updates and installations: Certain software updates or installations might modify security descriptors as part of their setup process. Users should maintain a list of trusted software and exclude these events when they coincide with known update schedules.
-- Automated scripts and tools: Organizations often use automated scripts or tools for managing AD environments, which might trigger the rule. Users can create exceptions for these scripts by verifying their legitimacy and ensuring they are executed by authorized accounts.
-- Third-party applications: Some third-party applications with legitimate access to AD might modify security descriptors as part of their functionality. Users should review and whitelist these applications after confirming their necessity and security compliance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the unauthorized modification of the nTSecurityDescriptor attribute and identify the compromised account.
-- Review recent changes in Active Directory, focusing on accounts with elevated privileges and any unusual modifications to security descriptors.
-- Revoke any unauthorized replication rights and reset passwords for affected accounts, ensuring they are strong and unique.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging and monitoring for Active Directory changes, specifically targeting event code 5136 and modifications to the nTSecurityDescriptor attribute.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in the future.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Implement hardening measures such as least privilege access, regular audits of privileged accounts, and continuous security awareness training for administrators.
-
-## Setup
+note = """## Setup
 
 The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
 Steps to implement the logging policy with Advanced Audit Configuration:
diff --git a/rules/windows/credential_access_dnsnode_creation.toml b/rules/windows/credential_access_dnsnode_creation.toml
index 50914d376d6..912a7da74cc 100644
--- a/rules/windows/credential_access_dnsnode_creation.toml
+++ b/rules/windows/credential_access_dnsnode_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -67,49 +67,6 @@ any where host.os.type == "windows" and event.action in ("Directory Service Chan
     event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
     not winlog.event_data.SubjectUserName : "*$"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation of a DNS-Named Record
-
-Active Directory Integrated DNS (ADIDNS) leverages Active Directory for DNS zone storage, enhancing domain consistency but posing security risks due to default permissions allowing any authenticated user to create DNS records. Adversaries exploit this by crafting malicious DNS entries for spoofing attacks. The detection rule identifies suspicious DNS record creation by monitoring specific Windows events, filtering out legitimate system accounts to highlight potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `event.action`, `event.code`, and `winlog.event_data.ObjectClass` fields to confirm the alert is related to DNS record creation.
-- Verify the `winlog.event_data.SubjectUserName` to identify the user account that initiated the DNS record creation. Investigate if this account is known and authorized to perform such actions.
-- Check the timestamp of the event to determine when the DNS record was created and correlate it with other security events or logs around the same time for additional context.
-- Use Osquery to list all DNS records created recently on the affected system with a query like: `SELECT * FROM dns_resolvers WHERE name = '<suspicious_dns_record>';` to gather more information about the DNS record.
-- Investigate the source IP address associated with the DNS record creation event to determine if it is from a known and trusted network or device.
-- Examine the `winlog.event_data.ObjectClass` field to confirm that the object class is indeed `dnsNode`, ensuring the alert is not a false positive.
-- Cross-reference the DNS record name with known malicious domains or internal blacklists to assess if it is associated with any known threats.
-- Analyze network traffic logs to identify any unusual or unauthorized DNS queries or responses related to the newly created DNS record.
-- Review historical logs for any previous DNS record creation events by the same user or from the same IP address to identify patterns or repeated suspicious activities.
-- Consult with the IT or network team to verify if there were any legitimate changes or updates to DNS records that could explain the alert, ensuring the activity is not part of a planned or authorized operation.
-
-### False positive analysis
-
-- Legitimate system processes or applications that frequently update DNS records may trigger false positives. These can include automated scripts or services that dynamically register DNS entries as part of their normal operation.
-- Regular updates from IT management tools or software deployment systems that modify DNS records for configuration management purposes might be mistakenly flagged as suspicious.
-- Exclude known and trusted system accounts or service accounts that are responsible for legitimate DNS record creation by adding them to an exception list. This can be done by identifying the specific SubjectUserName values associated with these accounts and modifying the detection rule to ignore these entries.
-- Monitor and document routine DNS record changes within the organization to establish a baseline of expected behavior, which can help in distinguishing between legitimate and potentially malicious activities.
-- Collaborate with network and system administrators to identify and whitelist specific DNS record changes that are part of regular maintenance or deployment activities, ensuring these do not trigger unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
-- Conduct a thorough investigation to identify the source of the malicious DNS record creation, focusing on recent changes and the user accounts involved.
-- Review and audit Active Directory permissions to ensure that only authorized users have the ability to create or modify DNS records, reducing the risk of unauthorized changes.
-- Remove any unauthorized or suspicious DNS records identified during the investigation to mitigate the risk of spoofing attacks.
-- Implement enhanced logging and monitoring for DNS record changes, ensuring that all modifications are logged and reviewed regularly for suspicious activity.
-- Integrate security information and event management (SIEM) solutions to correlate DNS activity with other security events, improving detection capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Restore the system to its operational state by applying necessary patches and updates, and ensure that all security configurations are properly set.
-- Educate users on the risks of DNS spoofing and the importance of reporting suspicious activity, enhancing overall security awareness.
-- Implement network segmentation and access controls to limit the impact of potential future attacks, reducing the attack surface available to adversaries."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_dollar_account_relay.toml b/rules/windows/credential_access_dollar_account_relay.toml
index 5aa07fa355f..38245c9dbb2 100644
--- a/rules/windows/credential_access_dollar_account_relay.toml
+++ b/rules/windows/credential_access_dollar_account_relay.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,49 +50,6 @@ authentication where host.os.type == "windows" and event.code in ("4624", "4625"
     not endswith(string(source.ip), string(host.ip)) and
     source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Relay Attack against a Domain Controller
-
-Domain Controllers (DCs) are critical in managing authentication within Windows environments. Adversaries exploit this by capturing and relaying authentication hashes, particularly using NTLM, to gain unauthorized access. The detection rule identifies suspicious authentication attempts by checking for machine account logins from unexpected sources, indicating potential relay attacks. It focuses on network logon events and mismatched source IPs to flag anomalies.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event codes (4624 or 4625) and ensure they align with the suspicious authentication attempts.
-- Verify the user.name field to confirm it ends with a "$", indicating a machine account, and check if it matches the host.name to ensure it is a legitimate account.
-- Examine the winlog.event_data.AuthenticationPackageName field to confirm the use of NTLM, which is commonly exploited in relay attacks.
-- Analyze the winlog.logon.type field to ensure the logon type is "network", as this is indicative of remote authentication attempts.
-- Investigate the source.ip field to identify the origin of the authentication attempt and determine if it is unexpected or unauthorized.
-- Cross-reference the source.ip with known IP addresses within the organization to identify any anomalies or unauthorized access points.
-- Use Osquery to gather additional context on the source host by running a query such as: `SELECT * FROM logged_in_users WHERE host = '<source.ip>';` to identify any active sessions or unusual user activity.
-- Check for any recent changes or anomalies in the domain controller's security logs that might correlate with the suspicious authentication attempt.
-- Investigate any other recent alerts or incidents involving the same source.ip or user.name to identify potential patterns or repeated attack attempts.
-- Collaborate with network and system administrators to gather additional network traffic logs or endpoint data that might provide further insights into the suspicious activity.
-
-### False positive analysis
-
-- Scheduled tasks or automated processes: Some environments may have scheduled tasks or automated processes that authenticate using machine accounts, which could trigger the rule. Users can handle these by identifying the specific tasks and excluding their source IPs from the detection rule.
-- Backup or monitoring software: Certain backup or monitoring solutions may use machine accounts to authenticate with domain controllers, leading to false positives. Users should identify these software solutions and create exceptions for their known IP addresses.
-- Load balancers or proxy servers: In environments where load balancers or proxy servers are used, the source IP may not match the expected host IP, causing false positives. Users can exclude the IPs of these devices from the rule to prevent unnecessary alerts.
-- Legitimate cross-domain authentication: In some cases, legitimate cross-domain authentication might appear suspicious if machine accounts are used. Users should verify such activities and whitelist the involved IPs if they are deemed non-threatening.
-- Testing or development environments: Activities in testing or development environments might mimic suspicious behavior. Users should consider excluding these environments from the rule or adjusting the rule parameters to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected domain controller from the network to prevent further unauthorized access.
-- Conduct a thorough investigation to identify the source of the relay attack, focusing on the mismatched source IPs and machine account logins.
-- Reset the passwords for all potentially compromised accounts, especially those associated with the domain controller.
-- Review and analyze logs from the domain controller and other relevant systems to trace the attack path and identify any additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed authentication events and network traffic, ensuring that NTLM authentication attempts are closely monitored.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
-- Restore the domain controller to its operational state by applying the latest security patches and updates, and verify the integrity of system files and configurations.
-- Harden the domain controller by disabling NTLM where possible, enforcing strong password policies, and implementing multi-factor authentication (MFA) for administrative access.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans to improve readiness for future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_generic_localdumps.toml b/rules/windows/credential_access_generic_localdumps.toml
index 48f3cdd79ae..ec951d94d75 100644
--- a/rules/windows/credential_access_generic_localdumps.toml
+++ b/rules/windows/credential_access_generic_localdumps.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/28"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,48 +50,6 @@ registry where host.os.type == "windows" and
     registry.data.strings : ("2", "0x00000002") and
     not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Full User-Mode Dumps Enabled System-Wide
-
-Full user-mode dumps are a diagnostic feature in Windows that captures detailed information about application crashes, aiding in troubleshooting. However, attackers can exploit this by enabling dumps system-wide to capture sensitive data, such as credentials, from processes like LSASS. The detection rule identifies unauthorized registry changes that enable this feature, excluding legitimate system processes, to flag potential credential dumping activities.
-
-### Possible investigation steps
-
-- Verify the registry path and data values by checking if the registry key `HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType` is set to "2" or "0x00000002", which indicates full user-mode dumps are enabled.
-- Identify the process that made the registry change by reviewing recent logs for any process activity related to registry modifications at the specified path.
-- Check for any recent application crashes or error reports that might have triggered the creation of a dump file, focusing on processes that handle sensitive data like LSASS.
-- Investigate the user account associated with the registry change by examining the `user.id` field to determine if it matches any known administrative or service accounts.
-- Review the process executable path to ensure it is not a legitimate system process like `?:\\Windows\\system32\\svchost.exe` running under system accounts (S-1-5-18, S-1-5-19, S-1-5-20).
-- Use Osquery to gather more information about the system's registry settings with a query like: `SELECT * FROM registry WHERE path = 'HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType';` to confirm the current state and any recent changes.
-- Analyze network activity logs for any unusual outbound connections that might indicate data exfiltration attempts following the registry change.
-- Cross-reference the alert with other security events or alerts in the same timeframe to identify any correlated suspicious activities or patterns.
-- Check for the presence of any unauthorized or suspicious software installations that might have been used to enable full user-mode dumps.
-- Review system and security logs for any signs of privilege escalation or lateral movement that could be related to the registry change and potential credential dumping activities.
-
-### False positive analysis
-
-- Legitimate software installations or updates may enable full user-mode dumps temporarily for debugging purposes, leading to false positives. Users can handle this by monitoring the installation or update process and temporarily excluding these activities from detection.
-- System administrators or IT support teams might enable full user-mode dumps for troubleshooting application crashes, which can be mistaken for malicious activity. To manage this, organizations can maintain a list of authorized personnel and processes that are allowed to make such changes and exclude them from the detection rule.
-- Some enterprise applications may require full user-mode dumps for regular operation or diagnostics, which could trigger the rule. Users should identify these applications and create exceptions for their specific registry changes to prevent false alerts.
-- Automated system management tools might modify registry settings as part of routine maintenance or configuration tasks. Users can address this by verifying the legitimacy of these tools and excluding their known benign activities from the detection criteria.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Verify the registry changes by checking the specified registry path for unauthorized modifications and revert any changes to their default state.
-- Conduct a thorough investigation to identify any unauthorized access or suspicious activity, focusing on processes interacting with LSASS.
-- Review system logs and security events to trace the origin of the registry change and identify potential threat actors or compromised accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed information on registry changes and process executions, particularly those involving LSASS.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security configurations are set to best practices.
-- Conduct a security audit of the affected system and network to identify and remediate any other vulnerabilities or misconfigurations.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and using multi-factor authentication to reduce the risk of credential dumping attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_iis_connectionstrings_dumping.toml b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
index 88a4b763d51..127e86d766f 100644
--- a/rules/windows/credential_access_iis_connectionstrings_dumping.toml
+++ b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,52 +57,6 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : "aspnet_regiis.exe" or ?process.pe.original_file_name == "aspnet_regiis.exe") and
   process.args : "connectionStrings" and process.args : "-pdf"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft IIS Connection Strings Decryption
-
-Microsoft IIS often stores sensitive data like database credentials in encrypted connection strings. The `aspnet_regiis` tool is used to manage these encryptions. Adversaries with access to the IIS server can exploit this tool to decrypt and extract credentials, potentially leading to unauthorized database access. The detection rule identifies suspicious use of `aspnet_regiis` by monitoring process execution with specific arguments, flagging potential credential dumping activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `aspnet_regiis.exe` execution with the arguments `connectionStrings` and `-pdf`, as these are indicative of potential credential dumping activities.
-- Verify the legitimacy of the process by checking the user account under which `aspnet_regiis.exe` was executed. Determine if this account should have the necessary permissions to perform such actions.
-- Investigate the parent process of `aspnet_regiis.exe` to understand how it was initiated. This can help identify if it was triggered by a legitimate application or a malicious script.
-- Examine the process execution timeline to identify any other suspicious activities occurring around the same time, such as the creation or modification of webshells or unauthorized access attempts.
-- Use Osquery to gather additional context about the process execution. For example, run the following query to list recent executions of `aspnet_regiis.exe`:
-  ```sql
-  SELECT pid, path, cmdline, time FROM processes WHERE name = 'aspnet_regiis.exe' ORDER BY time DESC LIMIT 5;
-  ```
-- Check the IIS server logs for any unusual access patterns or errors that might correlate with the time of the `aspnet_regiis.exe` execution.
-- Investigate any network connections established by the IIS server around the time of the alert to identify potential data exfiltration attempts.
-- Review the system's security event logs for any signs of privilege escalation or unauthorized access that could have facilitated the execution of `aspnet_regiis.exe`.
-- Analyze any recent changes to the IIS configuration files or application code that might indicate tampering or the introduction of malicious scripts.
-- Correlate the findings with other security alerts or incidents in the environment to determine if this activity is part of a broader attack campaign.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use `aspnet_regiis` for legitimate purposes such as updating or managing connection strings during regular maintenance. These activities can trigger the detection rule but are not malicious.
-- Automated deployment scripts: Some deployment processes might include scripts that use `aspnet_regiis` to configure or update application settings, including connection strings, as part of a continuous integration/continuous deployment (CI/CD) pipeline.
-- Development and testing environments: Developers might frequently use `aspnet_regiis` in non-production environments to test configurations or troubleshoot issues, leading to benign alerts.
-- To manage false positives, users can create exceptions for known administrative accounts or specific scripts that are verified as non-threatening. This can be done by excluding certain user accounts or process hashes from triggering the alert.
-- Implementing a baseline of normal behavior for `aspnet_regiis` usage in the environment can help distinguish between legitimate and suspicious activities, allowing for more accurate alerting.
-
-### Response and remediation
-
-- Immediately isolate the affected IIS server from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any unauthorized access to the server and potential data breaches.
-- Review IIS server logs and Windows Event Logs for any suspicious activity, particularly around the time the `aspnet_regiis` command was executed.
-- Change all credentials that may have been exposed, including database credentials and any other sensitive information stored in connection strings.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems may be affected.
-- Implement enhanced logging and monitoring on the IIS server to detect future unauthorized use of `aspnet_regiis` or similar tools.
-- Apply security patches and updates to the IIS server and related software to mitigate known vulnerabilities.
-- Conduct a security review of the IIS server configuration and apply hardening measures, such as restricting access to the `aspnet_regiis` tool and ensuring least privilege access controls.
-- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities.
-- Restore the IIS server to its operational state by verifying the integrity of the system and ensuring all security measures are in place before reconnecting to the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
index 77e420808f6..b1bcc5351d1 100644
--- a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
+++ b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,50 +54,6 @@ not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid
           "?:\\Windows\\System32\\DriverStore\\FileRepository\\*")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Untrusted DLL Loaded by Azure AD Sync Service
-
-Azure AD Sync Service facilitates identity synchronization between on-premises directories and Azure AD. Adversaries may exploit this by loading untrusted DLLs to capture credentials. The detection rule identifies such activities by monitoring DLL loads lacking valid signatures, excluding known safe paths, thus highlighting potential unauthorized persistence or credential access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "AzureADConnectAuthenticationAgentService.exe" and verify the event category and action to ensure it matches either "library" with "load" or "process" with "Image loaded*".
-- Check the DLL path and file path against the exclusion list to confirm it is not a known safe path, such as those under "?:\\Windows\\assembly\\NativeImages*", "?:\\Windows\\Microsoft.NET\\*", "?:\\Windows\\WinSxS\\*", or "?:\\Windows\\System32\\DriverStore\\FileRepository\\*".
-- Investigate the DLL's code signature status to determine if it is indeed untrusted or invalid, and gather details about the publisher if available.
-- Use Osquery to list all loaded DLLs by the Azure AD Sync Service process to identify any other potentially suspicious or untrusted DLLs. Example query: `SELECT path, pid, name FROM processes JOIN process_open_sockets USING (pid) WHERE name = 'AzureADConnectAuthenticationAgentService.exe';`
-- Cross-reference the untrusted DLL's hash with threat intelligence databases to check for known malicious activity or associations.
-- Analyze the creation and modification timestamps of the untrusted DLL to determine when it was introduced to the system and correlate with other system events or changes.
-- Review recent system and security logs for any unusual activities or errors around the time the untrusted DLL was loaded, focusing on user logins, privilege escalations, or other process executions.
-- Investigate the parent process of the Azure AD Sync Service to determine if it was started by an unexpected or unauthorized user or process.
-- Check for any network connections initiated by the Azure AD Sync Service process that could indicate data exfiltration or communication with a command and control server.
-- Gather context on the system's role and any recent changes or deployments that could explain the presence of the untrusted DLL, such as software updates or configuration changes.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate software updates or installations that temporarily load unsigned DLLs, especially during system or application updates.
-- Some third-party applications may use custom DLLs that are not signed but are necessary for their operation, leading to false alerts.
-- In environments with custom-developed software, unsigned DLLs might be loaded as part of normal operations, which could trigger this rule.
-- To manage these false positives, users can create exceptions for specific DLL paths or hashes that are known to be safe and frequently used in their environment.
-- Regularly review and update the list of excluded paths or hashes to ensure that only legitimate and necessary exceptions are maintained.
-- Collaborate with IT and security teams to verify the legitimacy of unsigned DLLs and adjust the detection rule accordingly to minimize false positives while maintaining security.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the untrusted DLL and determine if any credentials have been compromised.
-- Review recent changes to the Azure AD Sync Service configuration and check for unauthorized modifications.
-- Remove the untrusted DLL and any associated malicious files from the system.
-- Reset credentials for any accounts that may have been exposed or compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for the Azure AD Sync Service to detect similar activities in the future, including enabling detailed process and DLL load logging.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate and analyze suspicious activities.
-- Restore the system to its operational state by verifying the integrity of the Azure AD Sync Service and ensuring all security patches and updates are applied.
-- Harden the system by applying security best practices, such as enforcing strict access controls, using application whitelisting, and regularly reviewing and updating security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_kirbi_file.toml b/rules/windows/credential_access_kirbi_file.toml
index a4f33532ba5..15cc4ea836a 100644
--- a/rules/windows/credential_access_kirbi_file.toml
+++ b/rules/windows/credential_access_kirbi_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 
 [rule]
 author = ["Elastic"]
@@ -28,49 +28,6 @@ type = "eql"
 query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Kirbi File Creation
-
-Kirbi files are associated with Kerberos, a network authentication protocol used to verify user identities. Attackers exploit this by using tools like Mimikatz to extract Kerberos tickets, enabling unauthorized access through techniques like Pass-The-Ticket. The detection rule identifies the creation of these files on Windows systems, signaling potential credential dumping activities.
-
-### Possible investigation steps
-
-- Verify the alert by checking the file creation event details, focusing on the `host.os.type`, `event.type`, and `file.extension` fields to confirm the presence of a `.kirbi` file on a Windows system.
-- Identify the user account associated with the file creation event to determine if it aligns with expected behavior or if it might be compromised.
-- Review recent login activities for the identified user account to detect any unusual or unauthorized access patterns.
-- Examine the process that created the `.kirbi` file by correlating with process creation logs to identify the parent process and command line arguments used.
-- Use Osquery to gather more context about the system by running a query such as: `SELECT * FROM processes WHERE name = 'mimikatz.exe';` to check for the presence of known Kerberos ticket dumping tools.
-- Investigate the timeline of events leading up to the file creation by reviewing other security logs and alerts from the same host for any signs of suspicious activity.
-- Check for any network connections initiated by the host around the time of the file creation to identify potential lateral movement or data exfiltration attempts.
-- Analyze the file path and directory where the `.kirbi` file was created to determine if it is a common location for legitimate Kerberos tickets or if it appears suspicious.
-- Review any recent changes to user privileges or group memberships on the host to identify potential privilege escalation activities.
-- Correlate the alert with other security incidents or alerts in the environment to assess if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts that manage Kerberos tickets might create .kirbi files as part of their normal operations. These tools are often used by IT departments for troubleshooting or managing authentication processes.
-- Scheduled tasks or automated processes that involve Kerberos ticket management could also result in the creation of .kirbi files. These tasks might be part of regular system maintenance or security monitoring activities.
-- Security software or endpoint detection and response (EDR) solutions that simulate attacks for testing purposes might generate .kirbi files to evaluate system defenses.
-- To manage these false positives, users can create exceptions for specific processes or directories known to generate .kirbi files as part of legitimate activities. This can be done by updating the detection rule to exclude certain file paths or process names associated with trusted applications.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation to identify the source of the .kirbi file creation, including reviewing recent user activity and system logs.
-- Use forensic tools to analyze the system for additional signs of compromise, such as unauthorized user accounts or suspicious processes.
-- Reset passwords for all potentially compromised accounts, focusing on those with elevated privileges.
-- Remove any unauthorized Kerberos tickets and terminate any suspicious sessions or processes identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed authentication events and file creation activities, ensuring future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze security events in real-time.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security configurations are in place.
-- Harden the environment by implementing least privilege access controls, enabling multi-factor authentication, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_ldap_attributes.toml b/rules/windows/credential_access_ldap_attributes.toml
index 741340c2c4e..0715a53733a 100644
--- a/rules/windows/credential_access_ldap_attributes.toml
+++ b/rules/windows/credential_access_ldap_attributes.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,52 +80,6 @@ any where event.action in ("Directory Service Access", "object-operation-perform
    */
   not winlog.event_data.AccessMask in ("0x0", "0x100")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Access to a Sensitive LDAP Attribute
-
-LDAP (Lightweight Directory Access Protocol) is crucial for managing and accessing directory services in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, potentially leading to credential theft. The detection rule identifies suspicious access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce false positives.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event code is "4662" and the event action is either "Directory Service Access" or "object-operation-performed" to ensure it matches the detection criteria.
-- Verify the SubjectUserSid to ensure it is not "S-1-5-18", which is the SID for the Local System account, to rule out false positives from system processes.
-- Examine the winlog.event_data.Properties field to identify which specific sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, ms-PKI-DPAPIMasterKeys, or msPKI-CredentialRoamingTokens.
-- Check the winlog.event_data.AccessMask to ensure it is not "0x0" or "0x100", which are considered noisy and less indicative of malicious activity.
-- Investigate the user account associated with the access attempt to determine if it has a legitimate reason to access the sensitive attribute.
-- Use Osquery to gather additional context about the system from which the access attempt originated. For example, run the following query to list recent processes executed by the user:
-  ```sql
-  SELECT * FROM processes WHERE user = '<username>';
-  ```
-- Analyze the network traffic logs to identify any unusual connections or data transfers associated with the system or user involved in the alert.
-- Review recent changes in the Active Directory environment to identify any modifications that could have facilitated unauthorized access to sensitive attributes.
-- Correlate the alert with other security events or logs to identify patterns or additional indicators of compromise that may suggest a broader attack.
-- Consult with relevant stakeholders or system owners to verify if the access attempt was part of a legitimate administrative task or if further investigation is warranted.
-
-### False positive analysis
-
-- Access by legitimate administrative accounts: Routine operations by system administrators may trigger the rule due to their need to access sensitive attributes. Users can handle this by creating exceptions for known administrative accounts or service accounts that regularly perform these actions.
-- Scheduled tasks or automated scripts: Automated processes that require access to sensitive attributes for maintenance or updates might be flagged. To manage this, users should identify and exclude these tasks or scripts from the detection rule.
-- Backup and recovery operations: Backup solutions that interact with directory services to secure sensitive data may cause false positives. Users should whitelist these operations by excluding the associated service accounts or processes.
-- Security audits and compliance checks: Regular security assessments that involve accessing sensitive attributes can be mistaken for malicious activity. Users can mitigate this by excluding the accounts or tools used for these audits from the detection rule.
-- Third-party applications: Some third-party applications may require access to sensitive LDAP attributes for functionality. Users should verify the legitimacy of these applications and exclude them if they are deemed non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the breach, focusing on logs related to event code 4662 and the specific LDAP attributes accessed.
-- Change passwords and revoke any potentially compromised credentials associated with the affected accounts, especially those with elevated privileges.
-- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for LDAP access, focusing on sensitive attributes and unusual access patterns, to improve detection of future attempts.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and identify potential indicators of compromise.
-- Restore the affected system to its operational state by applying necessary patches, updates, and security configurations to prevent similar incidents.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train staff on security best practices and the importance of safeguarding sensitive information to reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
index 77c394ba9d7..d2b3ebffb78 100644
--- a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
+++ b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/29"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,49 +50,6 @@ process where host.os.type == "windows" and event.code == "10" and
    /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION */
   winlog.event_data.GrantedAccess == "0x14c0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious LSASS Access via MalSecLogon
-
-The Secondary Logon service, or seclogon, allows users to run processes with different credentials, often used for administrative tasks. Adversaries exploit this by accessing the LSASS process to extract credentials. The detection rule identifies such abuse by monitoring for specific access rights and call traces linked to seclogon.dll, indicating potential credential dumping attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the specific event code "10" and verify that the target image is "?:\\\\WINDOWS\\\\system32\\\\lsass.exe".
-- Check the call trace for the presence of "seclogon.dll" to confirm the involvement of the Secondary Logon service in accessing LSASS.
-- Verify the process name is "svchost.exe" to ensure the alert is triggered by the expected service host process.
-- Examine the granted access value "0x14c0" to confirm it includes PROCESS_CREATE_PROCESS, PROCESS_DUP_HANDLE, and PROCESS_QUERY_INFORMATION, which are indicative of potential credential dumping attempts.
-- Use Osquery to list all processes with open handles to LSASS to identify any other suspicious processes: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = 'lsass.exe');`
-- Investigate the parent process of the suspicious svchost.exe instance to determine if it was spawned by a legitimate process or if it shows signs of compromise.
-- Review recent login events and user activity to identify any unusual or unauthorized access patterns that might correlate with the alert.
-- Check for any recent changes or anomalies in the system's security settings or configurations that could have facilitated the suspicious access.
-- Analyze network traffic from the host for any signs of data exfiltration or communication with known malicious IP addresses.
-- Correlate the alert with other security events or logs from the same timeframe to identify any additional indicators of compromise or related suspicious activities.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts that utilize the Secondary Logon service for credential management tasks may trigger this rule. These tools often access LSASS for valid reasons, such as password management or system maintenance.
-- Scheduled tasks or automated processes that require elevated privileges and use seclogon.dll might also be flagged. These processes typically have predictable patterns and can be identified through regular monitoring.
-- Security software or endpoint management solutions that perform regular system checks or updates might access LSASS as part of their operations. These should be verified with the vendor to ensure they are benign.
-- To manage these false positives, users can create exceptions for known legitimate processes by whitelisting specific process names or paths that are verified to be safe.
-- Regularly review and update the list of exceptions to ensure that only trusted processes are excluded, and conduct periodic audits to confirm that no malicious activity is being overlooked.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further credential access and lateral movement.
-- Conduct a thorough investigation to confirm the presence of malicious activity by analyzing the event logs and correlating with other security alerts.
-- Terminate any suspicious processes associated with the Secondary Logon service and LSASS access to stop ongoing credential dumping attempts.
-- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process creation and access events, focusing on LSASS and seclogon.dll interactions.
-- Integrate endpoint detection and response (EDR) solutions to monitor for similar suspicious activities and improve threat visibility.
-- Restore the system to a known good state by reimaging the affected machine and applying the latest security patches and updates.
-- Conduct a post-incident review to identify gaps in security controls and update the incident response plan accordingly.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and using multi-factor authentication to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_lsass_loaded_susp_dll.toml b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
index 5df55154992..8516179dd5a 100644
--- a/rules/windows/credential_access_lsass_loaded_susp_dll.toml
+++ b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/12/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/10"
 
 [rule]
 author = ["Elastic"]
@@ -102,50 +102,6 @@ any where event.category in ("library", "driver") and host.os.type == "windows"
                  "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb",
                  "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Module Loaded by LSASS
-
-The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and handling user authentication in Windows environments. Adversaries exploit LSASS by loading malicious or untrusted DLLs to access sensitive credentials. The detection rule identifies such threats by monitoring LSASS for non-standard DLLs, focusing on unsigned or untrusted modules, and excluding known safe signatures and hashes.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific DLL file that was loaded by LSASS, focusing on the `dll.code_signature.subject_name` and `dll.hash.sha256` fields to determine if the DLL is unsigned or untrusted.
-- Cross-reference the `dll.hash.sha256` with known threat intelligence databases to check if the hash is associated with any known malicious activity.
-- Use Osquery to list all DLLs currently loaded by the LSASS process to identify any other potentially suspicious modules. Example query: `SELECT path, pid, name FROM processes JOIN process_open_sockets USING (pid) WHERE name = 'lsass.exe';`
-- Investigate the file path and properties of the suspicious DLL using the `dll.path` field to determine its origin and any associated metadata.
-- Check the `dll.code_signature.status` to understand the nature of the signature issue, such as whether it is expired or has a chaining error, which might provide context on the DLL's legitimacy.
-- Analyze recent system logs and events around the time the DLL was loaded to identify any unusual activities or changes in the system that could be related to the suspicious module.
-- Examine the system's startup programs and services to determine if the suspicious DLL is set to load at startup, which could indicate persistence mechanisms.
-- Investigate the parent process of LSASS using the `process.parent.executable` field to identify if there are any anomalies or unexpected parent processes that could suggest process injection or manipulation.
-- Review user account activities and authentication logs to identify any unauthorized access attempts or anomalies that could be linked to credential dumping activities.
-- Conduct a historical search for similar alerts or activities on the same host or across the network to determine if this is an isolated incident or part of a broader pattern.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate software that loads DLLs into LSASS but is not included in the predefined list of trusted signatures or hashes. This can include custom or in-house applications that have not been signed by a recognized certificate authority.
-- Security software updates or new installations might introduce new DLLs that are not immediately recognized as trusted, leading to false positives.
-- Users can manage these false positives by updating the list of trusted code signatures and hashes to include those from verified and legitimate sources.
-- Implementing a process to regularly review and update the exception list based on the organization's software inventory can help minimize false positives.
-- Monitoring for patterns of behavior rather than isolated events can help distinguish between benign and malicious activity, reducing the likelihood of false positives.
-- Engaging with software vendors to verify the legitimacy of their DLLs and obtaining their code signatures can aid in maintaining an accurate exception list.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on the suspicious DLL loaded by LSASS.
-- Utilize forensic tools to capture memory and disk images for detailed analysis and evidence preservation.
-- Remove the malicious or untrusted DLL from the system and replace it with a legitimate version if necessary.
-- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring policies to capture detailed information on DLL loads and process activities in LSASS.
-- Integrate threat intelligence feeds to improve detection capabilities and correlate with known threat actor behaviors.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring all software is up to date."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_posh_relay_tools.toml b/rules/windows/credential_access_posh_relay_tools.toml
index 40540ed760d..c376b490b2d 100644
--- a/rules/windows/credential_access_posh_relay_tools.toml
+++ b/rules/windows/credential_access_posh_relay_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,48 +68,6 @@ event.category:process and host.os.type:windows and
   ) and
   not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential PowerShell Pass-the-Hash/Relay Script
-
-PowerShell, a powerful scripting language in Windows, can be exploited by attackers to perform pass-the-hash (PtH) and relay attacks, leveraging NTLM authentication protocols. These attacks allow adversaries to authenticate as users without knowing their passwords. The detection rule identifies suspicious PowerShell scripts by scanning for specific NTLM negotiation patterns and byte sequences, excluding legitimate system directories, to flag potential credential theft activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific PowerShell script block text that triggered the detection, focusing on the presence of NTLM negotiation patterns and byte sequences.
-- Verify the process details by examining the `event.category:process` field to identify the parent and child processes associated with the suspicious PowerShell activity.
-- Check the `host.os.type:windows` field to confirm the operating system environment and gather additional context about the host involved in the alert.
-- Investigate the script's origin by analyzing the file path and directory, ensuring it does not match the excluded directory "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads".
-- Use Osquery to gather more information about the process and its parent by executing a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND path NOT LIKE 'C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\\\\%'`.
-- Examine the PowerShell script block text for any hardcoded credentials or suspicious commands that could indicate credential theft or lateral movement attempts.
-- Cross-reference the alert with recent authentication logs to identify any unusual or unauthorized access attempts that may correlate with the detected PowerShell activity.
-- Analyze network traffic logs for any signs of NTLM relay attacks or anomalous SMB traffic patterns that align with the time of the alert.
-- Review historical alerts and logs for the same host to determine if there is a pattern of similar suspicious activities, indicating a persistent threat.
-- Consult threat intelligence sources to check if the detected patterns or byte sequences are associated with known malware or attack campaigns.
-
-### False positive analysis
-
-- Legitimate administrative scripts: PowerShell scripts used by IT administrators for legitimate purposes may contain NTLM negotiation patterns similar to those flagged by the rule. Users can handle these by creating exceptions for scripts verified as safe and necessary for operations.
-- Security software operations: Some security tools may use PowerShell scripts that mimic NTLM negotiation patterns for scanning or monitoring purposes. Users should identify these tools and exclude their scripts from detection to prevent false positives.
-- Automated system processes: Certain automated processes or system maintenance tasks might trigger the rule due to their use of NTLM protocols. Users can manage these by reviewing the processes and excluding known benign scripts from detection.
-- Development and testing environments: Developers or testers might run scripts that simulate NTLM authentication for testing purposes. Users should ensure these environments are properly documented and excluded from the detection rule to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation of the PowerShell script execution logs to identify the source and scope of the attack.
-- Analyze the script block text and associated processes to determine if any credentials were compromised.
-- Reset passwords for any accounts that may have been affected, focusing on those with elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and module logging.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore the system from a known good backup to ensure no malicious code remains.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Harden the system by disabling NTLM where possible and enforcing the use of stronger authentication protocols like Kerberos."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_posh_veeam_sql.toml b/rules/windows/credential_access_posh_veeam_sql.toml
index 655052fc20b..65831163c1c 100644
--- a/rules/windows/credential_access_posh_veeam_sql.toml
+++ b/rules/windows/credential_access_posh_veeam_sql.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,48 +62,6 @@ event.category:process and host.os.type:windows and
     "ProtectedStorage]::GetLocalString"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Veeam Credential Access Capabilities
-
-PowerShell scripts can interact with Veeam's stored credentials in MSSQL databases, a feature intended for legitimate backup management. However, attackers exploit this to decrypt credentials, potentially targeting backups in ransomware attacks. The detection rule identifies suspicious script activity by monitoring for specific database interactions and decryption attempts, flagging potential credential access abuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the specific PowerShell script block text that triggered the alert, focusing on the presence of "[dbo].[Credentials]" and "ProtectedStorage]::GetLocalString".
-- Examine the process execution details, such as the process ID, parent process, and user account under which the PowerShell script was executed, to identify any anomalies or unauthorized access.
-- Check the event logs for any preceding or subsequent suspicious activities around the time of the alert, such as unusual login attempts or privilege escalations.
-- Investigate the host from which the alert originated to determine if there are any other signs of compromise, such as unexpected network connections or changes in system configurations.
-- Use Osquery to gather more information about the PowerShell script execution. For example, run the following query to list recent PowerShell script executions: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%[dbo].[Credentials]%' OR cmdline LIKE '%ProtectedStorage]::GetLocalString%';`
-- Analyze the PowerShell script content if available, to understand its purpose and whether it includes any malicious or unauthorized actions.
-- Correlate the alert with other security tools and logs, such as antivirus, endpoint detection and response (EDR), or network monitoring solutions, to gather additional context and evidence.
-- Investigate the MSSQL database logs to identify any unauthorized access attempts or suspicious queries related to Veeam credentials.
-- Check for any recent changes or updates to the Veeam backup configurations that could indicate tampering or unauthorized access.
-- Consult with the database and backup administrators to verify if the access to Veeam credentials was legitimate or if it aligns with any recent administrative activities.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may run PowerShell scripts that interact with Veeam credentials for routine backup management or maintenance tasks. These activities can trigger the detection rule but are non-threatening. Users can manage these by creating exceptions for known administrative scripts or specific user accounts that regularly perform these tasks.
-- Scheduled backup operations: Automated scripts scheduled to run at specific intervals for backup verification or testing purposes might be flagged. To handle these, users can whitelist specific script names or hash values that are verified as part of regular operations.
-- Security audits: Security teams may conduct audits that involve accessing Veeam credentials to ensure compliance and security posture. These activities can be excluded by identifying and allowing specific audit tools or scripts used by the security team.
-- Development and testing environments: In environments where developers or testers are experimenting with backup solutions, similar script activities might occur. Users can exclude these environments from monitoring or set up specific rules that differentiate between production and non-production activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on PowerShell script execution and MSSQL database interactions.
-- Review and analyze logs from the affected system and any associated network devices to trace the attacker's activities and identify any additional compromised systems.
-- Change all Veeam-related credentials and any other potentially exposed credentials to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging and monitoring for PowerShell activities and MSSQL database access to detect similar threats in the future.
-- Restore the affected system from a known good backup, ensuring that the backup is free from any malicious modifications.
-- Apply security patches and updates to the operating system, Veeam software, and any other relevant applications to mitigate known vulnerabilities.
-- Conduct a security review of the Veeam backup environment, ensuring that access controls and encryption settings are properly configured to prevent unauthorized access.
-- Educate and train staff on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
index 219b2656f13..3b9496723a6 100644
--- a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
+++ b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,49 +48,6 @@ process where host.os.type == "windows" and event.code == "10" and
  /* call is coming from an unknown executable region */
  winlog.event_data.CallTrace : "*UNKNOWN*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Credential Access via DuplicateHandle in LSASS
-
-The Local Security Authority Subsystem Service (LSASS) manages security policies and user authentication in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing standard APIs to evade detection and extract credentials. The detection rule identifies anomalies by monitoring LSASS handle access requests with unusual call traces, flagging potential unauthorized memory dumps.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event code "10" and ensure the process name is "lsass.exe" with the GrantedAccess value of "0x40".
-- Examine the call trace information in the alert to identify the presence of "*UNKNOWN*" modules, which may indicate suspicious activity.
-- Cross-reference the timestamp of the alert with other security logs to identify any correlated events or anomalies around the same time.
-- Use Osquery to list all processes with open handles to LSASS by running: `SELECT pid, name, path FROM processes WHERE pid IN (SELECT pid FROM process_open_sockets WHERE remote_address = '127.0.0.1' AND remote_port = 135);`
-- Investigate the parent process of the suspicious LSASS handle access to determine if it is a known and legitimate process or potentially malicious.
-- Check for any recent changes or anomalies in the system's process creation logs that might indicate the introduction of unauthorized software or scripts.
-- Analyze network traffic logs for any unusual outbound connections that coincide with the time of the alert, which might suggest data exfiltration attempts.
-- Review user account activity logs to identify any unauthorized or unusual login attempts or privilege escalations around the time of the alert.
-- Investigate the system for any signs of persistence mechanisms that could indicate a broader compromise, such as scheduled tasks or startup items.
-- Consult threat intelligence sources to determine if there are any known malware campaigns or threat actor tactics that align with the observed behavior.
-
-### False positive analysis
-
-- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. These tools might use similar techniques to access LSASS memory for legitimate reasons, such as antivirus programs or system management software.
-- System administrators or security teams should identify and document any authorized software that accesses LSASS memory. This can be done by reviewing the call traces and verifying the legitimacy of the processes involved.
-- To manage false positives, users can create exceptions for known and trusted software by excluding specific call traces or process names from the detection rule. This helps in reducing noise and focusing on genuine threats.
-- Regularly update the list of exceptions to accommodate new software updates or changes in the environment, ensuring that only verified processes are excluded from monitoring.
-- Collaborate with software vendors to understand the behavior of their applications concerning LSASS access, which can aid in distinguishing between benign and malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the alert by reviewing logs and correlating with other security events to determine the scope and impact.
-- Capture a memory dump of the affected system for forensic analysis to identify any malicious processes or tools used by the adversary.
-- Terminate any suspicious processes identified during the investigation that are attempting to access LSASS memory.
-- Change all potentially compromised credentials, focusing on high-privilege accounts, and enforce a password reset policy.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process creation and handle access events, ensuring visibility into similar activities in the future.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security configurations are hardened.
-- Conduct a post-incident review to identify gaps in the security posture and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
index 481a89364b8..90adf75f13c 100644
--- a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
+++ b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/30"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,52 +62,6 @@ process where host.os.type == "windows" and event.type == "start" and
   /* Access to named pipe via http */
   process.args : ("http*/print/pipe/*", "http*/pipe/spoolss", "http*/pipe/srvsvc")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Local NTLM Relay via HTTP
-
-NTLM, a suite of Microsoft security protocols, is often targeted by adversaries for credential theft. Attackers may exploit the Windows Printer Spooler service to coerce NTLM authentication over HTTP, potentially elevating privileges. The detection rule identifies suspicious rundll32.exe executions invoking WebDAV client DLLs with specific arguments, indicating attempts to access named pipes via HTTP, a hallmark of NTLM relay attacks.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious `rundll32.exe` executions with arguments pointing to `davclnt.dll` and HTTP access patterns, as specified in the detection rule.
-- Verify the process start event to ensure it matches the criteria: `process.name` as "rundll32.exe" and `process.args` containing paths to `davclnt.dll` and HTTP named pipe access.
-- Check the parent process of `rundll32.exe` to determine if it was spawned by a legitimate process or if it indicates malicious activity.
-- Investigate the user account associated with the process execution to determine if it is a privileged account or if there are signs of compromise.
-- Use Osquery to list all processes related to `rundll32.exe` and their network connections to identify any unusual or unauthorized network activity:
-  ```sql
-  SELECT pid, name, path, cmdline, parent, uid, gid FROM processes WHERE name = 'rundll32.exe';
-  ```
-- Examine the system's event logs for any related authentication events or anomalies around the time of the alert to gather additional context.
-- Analyze network traffic logs to identify any external connections made by the system that could indicate data exfiltration or communication with a command and control server.
-- Cross-reference the alert with any recent changes or updates to the system that might explain the behavior, such as software installations or configuration changes.
-- Investigate other systems within the network for similar alerts or suspicious activity to determine if this is an isolated incident or part of a broader attack.
-- Consult threat intelligence sources to check for any known campaigns or threat actors that utilize similar techniques, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate software or system processes may invoke `rundll32.exe` with WebDAV client DLLs for valid operations, such as network file access or synchronization tasks, which can trigger the detection rule.
-- System administrators or automated scripts might use similar command patterns for maintenance or configuration purposes, leading to false positives.
-- To manage these false positives, users can create exceptions for known benign processes or scripts by whitelisting specific command-line arguments or process hashes that are verified as non-threatening.
-- Regularly review and update the exception list to ensure it reflects the current environment and does not inadvertently exclude new or modified malicious activities.
-- Consider implementing additional context checks, such as verifying the source and destination of the HTTP requests, to differentiate between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the NTLM relay attack by reviewing logs and identifying any unauthorized access or changes.
-- Terminate any suspicious rundll32.exe processes that match the detection criteria to stop ongoing malicious activities.
-- Reset credentials for any accounts that may have been compromised during the attack to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on rundll32.exe and NTLM authentication events.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of similar threats in the future.
-- Restore the system to its operational state by applying the latest security patches and updates, particularly for the Windows Printer Spooler service.
-- Conduct a security audit of the network to identify and remediate any other potential vulnerabilities that could be exploited in similar attacks.
-- Implement hardening measures such as disabling unnecessary services, enforcing strong authentication mechanisms, and applying the principle of least privilege to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_saved_creds_vault_winlog.toml b/rules/windows/credential_access_saved_creds_vault_winlog.toml
index ffc866598e4..385a6037a93 100644
--- a/rules/windows/credential_access_saved_creds_vault_winlog.toml
+++ b/rules/windows/credential_access_saved_creds_vault_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,49 +51,6 @@ sequence by winlog.computer_name, winlog.process.pid with maxspan=1s
   not winlog.event_data.SubjectLogonId : "0x3e7" and 
   not winlog.event_data.Resource : "http://localhost/"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Multiple Vault Web Credentials Read
-
-Windows Credential Manager stores credentials for web logins, apps, and networks, simplifying user access. However, adversaries can exploit this by extracting stored credentials, potentially facilitating lateral movement within a network. The detection rule identifies suspicious activity by monitoring consecutive credential access events from the same process, excluding benign actions like local or system account access, thus highlighting potential credential dumping attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of two consecutive vault read events with event code "5382" from the same process ID (winlog.process.pid) within a 1-second span.
-- Verify the winlog.computer_name to identify the affected system and determine if it is a high-value target or contains sensitive information.
-- Check the winlog.event_data.SchemaFriendlyName field to ensure the events are related to "Windows Web Password Credential" and not another type of credential.
-- Examine the winlog.event_data.Resource field to identify the specific web resources accessed, ensuring they are not benign resources like "http://localhost/".
-- Investigate the winlog.event_data.SubjectLogonId to determine the user context under which the process is running, ensuring it is not the local system account "0x3e7".
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <suspicious_pid>;` to gather details like the process path, command line arguments, and parent process.
-- Cross-reference the suspicious process with recent login events to identify any unusual or unauthorized logins around the time of the alert.
-- Check for any recent changes or installations on the affected system that could explain the behavior, such as new software or updates.
-- Review network logs to identify any unusual outbound connections from the affected system that could indicate data exfiltration.
-- Correlate the findings with other security alerts or logs to determine if this activity is part of a larger attack pattern or campaign.
-
-### False positive analysis
-
-- Routine system processes or legitimate applications may trigger the rule if they frequently access web credentials for normal operations, such as automated scripts or background services that require web authentication.
-- Scheduled tasks or maintenance scripts that access web credentials for updates or data synchronization might be misidentified as suspicious activity.
-- Users can manage these false positives by creating exceptions for known benign processes or specific logon IDs that are verified to perform legitimate credential access.
-- Implementing a whitelist of trusted applications or processes that regularly access web credentials can help reduce noise and focus on truly suspicious activities.
-- Monitoring the frequency and context of credential access events can aid in distinguishing between legitimate and potentially malicious activities, allowing for more informed exception handling.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to identify the process and user account associated with the suspicious credential access events.
-- Review the system's event logs to identify any other unusual activities or patterns that may indicate further compromise.
-- Change all potentially compromised credentials, especially those stored in the Windows Credential Manager, and enforce a password reset policy for affected users.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed credential access events and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all software is up to date.
-- Conduct a security audit of the affected system and network to identify and remediate any vulnerabilities that may have been exploited.
-- Educate users on secure credential management practices and the importance of reporting suspicious activities.
-- Implement hardening measures such as disabling unnecessary services, applying the principle of least privilege, and using multi-factor authentication to protect sensitive accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_saved_creds_vaultcmd.toml b/rules/windows/credential_access_saved_creds_vaultcmd.toml
index e77d5f2e782..2e9c04c2ec9 100644
--- a/rules/windows/credential_access_saved_creds_vaultcmd.toml
+++ b/rules/windows/credential_access_saved_creds_vaultcmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,49 +57,6 @@ process where host.os.type == "windows" and event.type == "start" and
   (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and
   process.args:"/list*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Searching for Saved Credentials via VaultCmd
-
-Windows Credential Manager is a tool for managing saved credentials, such as usernames and passwords, for various services. Adversaries may exploit this by using VaultCmd to list or extract these credentials, potentially facilitating unauthorized access or lateral movement within a network. The detection rule identifies such activities by monitoring for the execution of VaultCmd with specific arguments indicative of credential listing attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `vaultcmd.exe` in the `process.name` or `process.pe.original_file_name` fields, and verify the use of the `/list*` argument in `process.args`.
-- Check the `event.type` field to ensure the process start event is accurately captured, indicating the execution of VaultCmd.
-- Identify the user account associated with the process execution by examining the `user.name` or `process.user.name` fields to determine if it aligns with expected behavior or if it is suspicious.
-- Investigate the `host.name` or `host.hostname` fields to determine the machine where the activity occurred and assess if it is a high-value target or a critical system.
-- Examine the `process.parent.name` and `process.parent.pid` fields to understand the parent process that initiated VaultCmd, which may provide context on how the execution was triggered.
-- Utilize Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'vaultcmd.exe';` to retrieve detailed information about the process execution.
-- Check for any recent logins or unusual activity associated with the identified user account by reviewing authentication logs or security events.
-- Investigate any network connections established by the host during the time of the alert to identify potential lateral movement or data exfiltration attempts.
-- Review historical data for any previous instances of VaultCmd execution on the same host or by the same user to identify patterns or repeated attempts.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign or isolated event.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use VaultCmd for legitimate purposes, such as managing user credentials or performing audits. These activities can trigger the detection rule but are not malicious.
-- Automated scripts: Some organizations may have automated scripts that utilize VaultCmd to manage credentials as part of their regular maintenance or security protocols. These scripts can generate alerts that are false positives.
-- Credential management software: Third-party credential management tools might invoke VaultCmd as part of their operations, leading to benign alerts.
-- User training and awareness programs: Security teams might use VaultCmd in training exercises to demonstrate credential management, which could be mistakenly flagged as suspicious activity.
-- To manage these false positives, users can create exceptions for known administrative accounts or scripts that regularly use VaultCmd. This can be done by adding specific user accounts or process hashes to an allowlist, ensuring that only unexpected or unauthorized use of VaultCmd triggers alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been accessed using the compromised credentials.
-- Review the event logs and security logs on the affected system to gather evidence of the VaultCmd execution and any subsequent suspicious activities.
-- Change all potentially compromised credentials, including those stored in the Windows Credential Manager, and enforce a password reset policy for affected users.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments, to improve detection of similar activities in the future.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to provide real-time alerts and context for suspicious activities related to credential access.
-- Restore the affected system to its operational state by reimaging the system or applying a clean backup, ensuring that all malicious artifacts are removed.
-- Apply security hardening measures, such as disabling unnecessary services, applying the principle of least privilege, and ensuring all systems are up to date with security patches.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_generic.toml b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
index 4962a93f389..3d128e0eda8 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_generic.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/22"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/21"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -73,54 +73,6 @@ process where host.os.type == "windows" and event.code == "10" and
   ) and
   not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Lsass Process Access
-
-The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and user authentication in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on potential credential dumping activities. This helps in pinpointing malicious actions while minimizing false positives.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event code is "10" and the target image is "?:\\\\WINDOWS\\\\system32\\\\lsass.exe" to ensure the alert is relevant to LSASS access.
-- Check the process name and executable path against the exclusion list to verify if the process is indeed suspicious and not a known legitimate process.
-- Investigate the process that attempted access by gathering additional details such as process ID, parent process ID, and command line arguments to understand the context of the access attempt.
-- Examine the user account associated with the process to determine if it is a privileged account or if there are any anomalies in its usage patterns.
-- Utilize Osquery to gather more information about the suspicious process. For example, run the following query to list all processes with their parent process and command line:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE '%lsass.exe%';
-  ```
-- Analyze the call trace data to identify any known malicious DLLs or unusual patterns that could indicate tampering or injection attempts.
-- Cross-reference the timestamp of the alert with other security logs, such as authentication logs or network activity, to identify any correlated suspicious activities.
-- Investigate any recent changes or installations on the host that could have introduced the suspicious process, focusing on software updates or new applications.
-- Check for any other alerts or indicators of compromise on the same host or within the same network segment to assess if this is part of a broader attack.
-- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation for future reference and analysis.
-
-### False positive analysis
-
-- Known false positives for the Suspicious Lsass Process Access rule include legitimate software and system processes that access LSASS for valid reasons, such as security software, system management tools, and certain enterprise applications.
-- Security tools like Sysmon, Windows Defender, and other endpoint protection platforms may trigger false positives due to their legitimate access to LSASS for monitoring and protection purposes.
-- System management and monitoring tools, such as those used for software updates or system diagnostics, might also access LSASS, leading to false positives.
-- Enterprise applications, particularly those involved in authentication or system integration, may require access to LSASS, which can be mistaken for suspicious activity.
-- To manage these false positives, users can create exceptions by adding known legitimate processes and executables to the exclusion list within the detection rule.
-- Regularly review and update the exclusion list to include new legitimate processes as they are identified, ensuring that the detection rule remains effective without generating unnecessary alerts.
-- Consider the context of the environment and the specific use cases of the organization to tailor the exclusion list, minimizing the risk of overlooking genuine threats while reducing false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the alert by reviewing logs and correlating with other security events to determine the scope and impact.
-- Capture a memory dump of the affected system for forensic analysis to identify any malicious processes or tools used for credential dumping.
-- Reset passwords for any accounts that may have been compromised, especially those with elevated privileges, and enforce multi-factor authentication.
-- Remove any identified malicious software or tools from the system and ensure that the system is clean before reconnecting it to the network.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and access patterns, focusing on critical system processes like LSASS.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for future investigations.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
index b78a81b0811..b4b6624514c 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/07"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,49 +58,6 @@ process where host.os.type == "windows" and event.code == "10" and
         "?:\\Windows\\System32\\WerFaultSecure.exe"
       )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Credential Access via LSASS Memory Dump
-
-LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and handling user logins. Adversaries exploit this by using tools that leverage the MiniDumpWriteDump API, often exported by libraries like DBGHelp.dll, to extract sensitive credentials from LSASS memory. The detection rule identifies suspicious access patterns to LSASS, excluding legitimate crash handlers, to flag potential credential dumping attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious access to the LSASS handle, focusing on the `winlog.event_data.TargetImage` field to ensure it points to "?:\\\\WINDOWS\\\\system32\\\\lsass.exe".
-- Examine the `winlog.event_data.CallTrace` field to verify if the call trace includes references to "dbghelp" or "dbgcore", indicating potential use of the MiniDumpWriteDump API.
-- Check the process that triggered the alert by analyzing the `process.executable` field to ensure it is not a legitimate crash handler like WerFault.exe or WerFaultSecure.exe.
-- Investigate the parent process of the suspicious activity to determine if it is a known legitimate process or potentially malicious.
-- Use Osquery to list all processes with open handles to LSASS by running: `SELECT pid, name, path FROM processes WHERE path LIKE '%lsass.exe%';` to identify any unexpected processes.
-- Correlate the timestamp of the alert with other security events on the host to identify any concurrent suspicious activities or anomalies.
-- Review recent user logins and account activities on the affected host to detect any unauthorized access attempts.
-- Analyze network connections from the host around the time of the alert to identify any unusual outbound connections that could indicate data exfiltration.
-- Check for any recent changes or installations of software on the host that could have introduced the suspicious behavior.
-- Consult threat intelligence sources to determine if the identified behavior matches any known attack patterns or tools used by adversaries.
-
-### False positive analysis
-
-- Legitimate software debugging tools may trigger this rule if they access LSASS memory for troubleshooting purposes, as they might use the MiniDumpWriteDump API. Users should verify if the process is part of a known debugging or monitoring tool.
-- System crash handlers, other than those explicitly excluded, might access LSASS memory during a crash event. Users can add additional known crash handler executables to the exclusion list to prevent false positives.
-- Security software or endpoint protection solutions may access LSASS memory as part of their normal operations. Users should confirm with their security vendor and consider excluding these processes if they are verified as safe.
-- Custom in-house applications that perform memory dumps for diagnostic purposes could also be flagged. Users should ensure these applications are documented and add them to the exclusion list if necessary.
-- To manage false positives, users can create exceptions by adding specific process executables or paths to the exclusion list, ensuring these are thoroughly vetted to avoid overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further credential access and lateral movement by the adversary.
-- Conduct a thorough investigation to confirm the presence of unauthorized LSASS memory access, reviewing logs and call traces for DBGHelp.dll or DBGCore.dll usage.
-- Capture a memory dump of the affected system for forensic analysis to identify any malicious processes or tools used for credential dumping.
-- If unauthorized access is confirmed, reset passwords for all accounts that may have been compromised, prioritizing high-privilege accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process creation and DLL loading events, ensuring visibility into future suspicious activities.
-- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious access patterns to critical system processes like LSASS.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are hardened.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks of credential dumping and the importance of maintaining strong, unique passwords and enabling multi-factor authentication (MFA)."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
index 9f3f73b6b37..157283aefb3 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,49 +46,6 @@ event.category:process and host.os.type:windows and event.code:10 and
                                  "c:\\Windows\\system32\\lsass.exe" or
                                  "c:\\Windows\\System32\\lsass.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential LSASS Memory Dump via PssCaptureSnapShot
-
-PssCaptureSnapShot is a Windows API used for creating snapshots of processes, which can be leveraged for legitimate debugging and diagnostics. However, adversaries may exploit this to capture LSASS process memory, aiming to extract credentials. The detection rule identifies suspicious behavior by monitoring for repeated access to LSASS by the same process, targeting different LSASS instances, which may suggest an evasion attempt to dump credentials stealthily.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event category is 'process' and the host operating system type is 'windows', ensuring the alert is relevant to the environment.
-- Verify the event code is '10', which indicates a process access event, to confirm the alert is triggered by the correct type of activity.
-- Check the 'winlog.event_data.TargetImage' field to ensure it matches the path of LSASS (e.g., "C:\\\\Windows\\\\system32\\\\lsass.exe"), confirming the target process is indeed LSASS.
-- Identify the process that accessed LSASS by examining the process name and process ID fields in the event data to determine the source of the suspicious activity.
-- Investigate the parent process of the suspicious process to understand the context of how it was launched and whether it is associated with legitimate software or known malicious activity.
-- Use Osquery to gather additional context about the suspicious process. For example, run the query: `SELECT * FROM processes WHERE pid = <suspicious_process_id>;` to retrieve details such as the command line, user, and start time.
-- Check for any recent process creation events involving the suspicious process to identify if it was spawned by another potentially malicious process.
-- Review the system's security logs for any other unusual or related activities around the time of the alert, such as failed login attempts or other process access events.
-- Analyze network logs to determine if the suspicious process has made any outbound connections, which could indicate data exfiltration attempts.
-- Correlate the findings with threat intelligence sources to determine if the behavior matches any known attack patterns or if the process is associated with known malware.
-
-### False positive analysis
-
-- Legitimate software tools used for system diagnostics or debugging may trigger this rule if they access LSASS memory using PssCaptureSnapShot. These tools often perform similar actions for legitimate purposes, such as performance monitoring or troubleshooting.
-- Security software or endpoint protection solutions might also access LSASS memory as part of their routine checks, leading to false positives. These solutions are designed to ensure system integrity and may mimic suspicious behavior unintentionally.
-- To manage these false positives, users can create exceptions for known and trusted software by whitelisting their process names or paths. This can be done by updating the detection rule to exclude specific processes that are verified as non-threatening.
-- Regularly review and update the list of exceptions to ensure that only legitimate processes are excluded, maintaining a balance between security and operational efficiency.
-- Collaborate with IT and security teams to identify and document legitimate processes that require access to LSASS, ensuring that these are accounted for in the exception list.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further credential access and lateral movement by the adversary.
-- Conduct a thorough investigation to confirm the presence of unauthorized LSASS memory access by reviewing security logs and process activity.
-- Terminate any suspicious processes that have accessed LSASS memory and ensure they are not legitimate administrative tools.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access.
-- Restore the system to a known good state by reimaging the affected machine and applying the latest security patches and updates.
-- Implement enhanced logging policies to capture detailed process creation and access events, focusing on LSASS and other critical system processes.
-- Integrate endpoint detection and response (EDR) solutions to monitor for similar suspicious activities and provide real-time alerts.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks of credential dumping and the importance of maintaining strong, unique passwords."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_veeam_backup_dll_imageload.toml b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
index fe51f99a7b8..c22dbdbccee 100644
--- a/rules/windows/credential_access_veeam_backup_dll_imageload.toml
+++ b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -38,48 +38,6 @@ library where host.os.type == "windows" and event.action == "load" and
     process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Veeam Backup Library Loaded by Unusual Process
-
-Veeam Backup software is crucial for data protection, managing backups, and ensuring data recovery. However, attackers may exploit its credential management by loading the Veeam.Backup.Common.dll library through PowerShell or untrusted processes to decrypt credentials, potentially leading to data breaches or ransomware attacks. The detection rule identifies such anomalies by monitoring for the library's loading by suspicious processes, focusing on untrusted or unsigned code signatures and PowerShell activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the Veeam.Backup.Common.dll library loaded by an unusual process, focusing on the process name and code signature status.
-- Verify the process code signature by checking if it is trusted or exists, and identify if the process is PowerShell-related (e.g., powershell.exe, pwsh.exe, powershell_ise.exe).
-- Gather additional context by examining the parent process of the suspicious activity to understand how the process was initiated.
-- Check the user account associated with the process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
-- Investigate recent PowerShell command history on the host to identify any suspicious or unauthorized scripts that may have been executed.
-- Use Osquery to list all processes that have recently loaded the Veeam.Backup.Common.dll library with the following query: `SELECT pid, name, path FROM processes WHERE path LIKE '%Veeam.Backup.Common.dll%';`
-- Analyze network connections from the host to identify any unusual outbound connections that may suggest data exfiltration or communication with a command and control server.
-- Review recent system and security logs for any additional indicators of compromise or related suspicious activities around the time of the alert.
-- Check for any recent changes to Veeam Backup configurations or settings that could indicate tampering or unauthorized access.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative scripts or automation tools may load the Veeam.Backup.Common.dll library using PowerShell for routine backup management tasks, leading to false positives. Users can handle these by creating exceptions for known scripts or tools that are verified and regularly used by the IT department.
-- Some third-party backup management solutions might integrate with Veeam and load the library through unsigned processes. To manage these, users should verify the legitimacy of the third-party software and add it to an allowlist if deemed safe.
-- During software updates or maintenance, Veeam's own processes might temporarily appear unsigned or untrusted, triggering alerts. Users should monitor the timing of these alerts and correlate them with scheduled maintenance activities, excluding them if they match.
-- In environments where PowerShell is heavily used for legitimate administrative tasks, frequent alerts may occur. Users can reduce noise by implementing strict code-signing policies and only allowing signed scripts to execute, thereby minimizing the risk of false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the anomaly, focusing on the processes that loaded the Veeam.Backup.Common.dll library.
-- Review PowerShell logs and any unsigned process activity to determine if there are any unauthorized or suspicious commands executed.
-- Verify the integrity of Veeam Backup credentials and change them if any compromise is suspected.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
-- Integrate security tools with SIEM solutions to automate the detection of similar threats and improve response times.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting PowerShell execution policies, enforcing code signing, and regularly auditing privileged accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_veeam_commands.toml b/rules/windows/credential_access_veeam_commands.toml
index 6e074224e71..9cfdf005e9b 100644
--- a/rules/windows/credential_access_veeam_commands.toml
+++ b/rules/windows/credential_access_veeam_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,48 +56,6 @@ process where host.os.type == "windows" and event.type == "start" and
   ) and
   process.args : "*[VeeamBackup].[dbo].[Credentials]*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Veeam Credential Access Command
-
-Veeam Backup & Replication software stores credentials in MSSQL databases to facilitate backup operations. Adversaries may exploit this by executing specific SQL commands to access and decrypt these credentials, potentially leading to unauthorized access and data destruction, such as in ransomware attacks. The detection rule identifies suspicious processes and arguments indicative of such credential access attempts, focusing on SQL command-line utilities and PowerShell cmdlets that interact with Veeam's credential storage.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious processes such as `sqlcmd.exe` or PowerShell cmdlets like `Invoke-Sqlcmd`, `Invoke-SqlExecute`, `Invoke-DbaQuery`, or `Invoke-SqlQuery` in the process arguments.
-- Verify the process execution context by checking the user account under which the suspicious process was executed to determine if it aligns with expected administrative or service accounts.
-- Examine the command line arguments of the flagged process to identify any references to the `[VeeamBackup].[dbo].[Credentials]` table, which may indicate an attempt to access stored credentials.
-- Check the process creation time and correlate it with any other suspicious activities or alerts around the same timeframe to identify potential lateral movement or privilege escalation attempts.
-- Investigate the parent process of the suspicious command to determine if it was spawned by a legitimate application or a potentially malicious script or executable.
-- Utilize Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name = 'sqlcmd.exe' OR name LIKE 'powershell%' AND cmdline LIKE '%[VeeamBackup].[dbo].[Credentials]%';` to identify other instances of similar activity.
-- Review recent login events and access logs for the database server to identify any unauthorized or unusual access patterns that may correlate with the alert.
-- Analyze network traffic logs to detect any data exfiltration attempts or connections to known malicious IP addresses following the execution of the suspicious process.
-- Check for any recent changes or anomalies in the Veeam Backup & Replication configuration or backup jobs that could indicate tampering or unauthorized access.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors targeting Veeam credentials, and assess if the observed activity matches any known indicators of compromise.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may use SQL command-line utilities or PowerShell cmdlets to manage Veeam Backup & Replication configurations, leading to benign alerts. To manage these, users can create exceptions for known administrator accounts or specific scripts that are regularly used for maintenance.
-- Automated backup scripts: Organizations might have automated scripts that interact with Veeam's credential storage for backup verification or testing purposes. These scripts can be whitelisted by identifying their unique process names or arguments to prevent false positives.
-- Monitoring and auditing tools: Security or compliance tools that perform regular checks on database credentials might trigger this rule. Users can exclude these tools by specifying their process names or paths in the detection rule exceptions.
-- Development and testing environments: In non-production environments, developers might frequently access Veeam credentials for testing purposes. Users can adjust the rule to exclude specific hostnames or IP addresses associated with these environments to reduce noise.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to confirm the presence of unauthorized SQL command execution targeting Veeam credentials, using logs and forensic tools.
-- Review and analyze recent access logs for unusual activity, focusing on SQL command-line utilities and PowerShell cmdlets interacting with Veeam's credential storage.
-- Change all potentially compromised credentials stored in the Veeam Backup & Replication system and any other systems where these credentials might have been reused.
-- Restore affected systems from the most recent clean backup to ensure no malicious changes persist.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate security solutions with SIEM systems to improve detection and correlation of suspicious activities related to credential access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Apply security patches and updates to Veeam Backup & Replication software and underlying systems to mitigate known vulnerabilities.
-- Conduct a security review and harden the environment by implementing least privilege access controls, network segmentation, and regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
index be72d21bcc2..84213f9d53c 100644
--- a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
+++ b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/11/27"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,49 +50,6 @@ process where host.os.type == "windows" and event.code:"4688" and
   process.executable : "?:\\Windows\\System32\\lsass.exe" and
   process.parent.executable : "?:\\Windows\\System32\\lsass.exe"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential LSASS Clone Creation via PssCaptureSnapShot
-
-PssCaptureSnapShot is a Windows API used for creating snapshots of processes, often for debugging or analysis. Adversaries exploit this to clone the LSASS process, aiming to extract credentials without triggering alarms. The detection rule identifies suspicious LSASS clones by monitoring process creation events where both the process and its parent are LSASS, signaling potential credential dumping attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a process creation event with event code 4688, where both the process and its parent are `lsass.exe`.
-- Verify the timestamp of the event to determine when the suspicious LSASS clone was created and correlate it with other security events around the same time.
-- Check the user account context under which the LSASS clone process was created to identify any unusual or unauthorized access.
-- Investigate the command line arguments used during the process creation to identify any anomalies or suspicious parameters.
-- Use Osquery to list all running processes and their parent processes to confirm the presence of any LSASS clones. Example query: `SELECT pid, name, path, parent FROM processes WHERE name = 'lsass.exe';`
-- Examine the network connections and open ports on the host to identify any unusual outbound connections that might indicate data exfiltration.
-- Review recent login events and account activity on the host to identify any unauthorized access attempts or anomalies.
-- Analyze the host for any recent changes to system files or configurations that could indicate tampering or preparation for credential dumping.
-- Check for any other security alerts or logs related to the host or user account to identify potential patterns or repeated attempts.
-- Consult threat intelligence sources to determine if there are any known campaigns or tools that match the observed behavior, providing additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate software or security tools that perform memory analysis or debugging might trigger this rule by creating LSASS process snapshots for non-malicious purposes.
-- System administrators or security teams using authorized tools for system diagnostics or forensic investigations may inadvertently cause LSASS clones, leading to false positives.
-- Exclude known and trusted applications or tools that are verified to perform legitimate LSASS process interactions by adding them to an exception list in the monitoring system.
-- Regularly update the exception list to include new versions or updates of trusted software that interact with LSASS to prevent unnecessary alerts.
-- Collaborate with IT and security teams to identify and document routine maintenance or diagnostic activities that could mimic suspicious behavior, ensuring these are accounted for in the monitoring setup.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further credential access and lateral movement.
-- Conduct a thorough investigation to confirm the presence of unauthorized LSASS process clones using forensic tools and logs.
-- Terminate any suspicious LSASS clone processes identified during the investigation to halt potential credential dumping.
-- Review and analyze security logs, including Windows Event Logs and security information and event management (SIEM) data, to trace the source and scope of the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process creation events and monitor for similar suspicious activities in the future.
-- Integrate endpoint detection and response (EDR) solutions to provide real-time monitoring and automated response capabilities.
-- Restore the affected system from a known good backup to ensure no residual malicious activity remains.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for credential dumping.
-- Strengthen system hardening measures by enforcing least privilege access, enabling Credential Guard, and regularly reviewing user permissions and access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_wbadmin_ntds.toml b/rules/windows/credential_access_wbadmin_ntds.toml
index 1bbaf193932..efc78263512 100644
--- a/rules/windows/credential_access_wbadmin_ntds.toml
+++ b/rules/windows/credential_access_wbadmin_ntds.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,48 +54,6 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and 
      process.args : "recovery" and process.command_line : "*ntds.dit*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 NTDS Dump via Wbadmin
-
-Wbadmin is a Windows utility for managing backups, including system state data like the NTDS.dit file, which stores Active Directory data. Adversaries with sufficient privileges can exploit Wbadmin to extract this file, gaining access to sensitive credentials. The detection rule identifies suspicious Wbadmin usage by monitoring for specific command patterns indicative of NTDS.dit access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `wbadmin.exe` process execution with arguments related to "recovery" and "ntds.dit" in the command line.
-- Verify the user account associated with the process execution to determine if it belongs to privileged groups such as Backup Operators or Domain Admins.
-- Check the event logs for any preceding or subsequent suspicious activities around the time of the wbadmin execution, focusing on privilege escalation or lateral movement attempts.
-- Investigate the source host by examining its recent login history and any unusual access patterns to identify potential unauthorized access.
-- Use Osquery to gather additional context on the process execution. For example, run the following query to list recent wbadmin executions: `SELECT * FROM processes WHERE name = 'wbadmin.exe' AND cmdline LIKE '%ntds.dit%';`
-- Analyze network traffic logs to identify any data exfiltration attempts or connections to suspicious external IP addresses following the wbadmin execution.
-- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or coordinated attack activities.
-- Examine the file system for any unauthorized copies or movements of the NTDS.dit file, especially in non-standard directories or external storage devices.
-- Review any recent changes to user permissions or group memberships that could have facilitated the wbadmin execution.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar wbadmin abuse techniques.
-
-### False positive analysis
-
-- Scheduled or legitimate backup operations: Organizations may have routine backup processes that involve the use of Wbadmin to access system state data, including the NTDS.dit file. These operations are typically performed by IT personnel with appropriate privileges and should be verified against scheduled tasks or backup logs.
-- Testing and maintenance activities: IT departments may conduct tests or maintenance activities that involve accessing the NTDS.dit file using Wbadmin. These activities should be documented and cross-referenced with the detected events to confirm legitimacy.
-- Third-party backup solutions: Some third-party backup solutions may utilize Wbadmin as part of their backup processes. It's important to identify these solutions and create exceptions for their known behaviors to prevent false positives.
-- To manage false positives, users can create exceptions for known legitimate processes by whitelisting specific command lines or process arguments associated with authorized backup activities. Additionally, maintaining an updated list of authorized personnel and scheduled tasks can help in quickly identifying and excluding non-threatening behaviors.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Verify the legitimacy of the wbadmin command execution by checking the user account and context in which it was run. Investigate if the account has been compromised.
-- Review the membership of privileged groups such as Backup Operators and Domain Admins to ensure only authorized personnel have access.
-- Conduct a thorough forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms.
-- Reset passwords for all potentially compromised accounts, especially those with elevated privileges, and enforce multi-factor authentication.
-- Restore the NTDS.dit file and any other affected system components from a known good backup to ensure integrity.
-- Implement enhanced logging and monitoring for wbadmin usage and other sensitive operations, ensuring logs are sent to a centralized security information and event management (SIEM) system.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) for improved detection and response.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Review and update security policies and procedures to include regular audits of privileged accounts and the implementation of least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_cve_2020_0601.toml b/rules/windows/defense_evasion_cve_2020_0601.toml
index f0cbb4db46d..c5462af0a0c 100644
--- a/rules/windows/defense_evasion_cve_2020_0601.toml
+++ b/rules/windows/defense_evasion_cve_2020_0601.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/19"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,48 +34,6 @@ type = "query"
 query = '''
 event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" and host.os.type:windows
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall)
-
-The Windows CryptoAPI is crucial for validating ECC certificates, ensuring secure communications and software authenticity. CVE-2020-0601, known as CurveBall, allows attackers to exploit this by crafting fake certificates, making malicious files appear legitimate. The detection rule identifies such exploits by monitoring specific event logs and messages related to this vulnerability, focusing on defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the event.provider field as "Microsoft-Windows-Audit-CVE" and ensure the message contains "[CVE-2020-0601]" to verify the alert's relevance to the CurveBall vulnerability.
-- Check the host.os.type field to confirm the affected system is running Windows, as this vulnerability specifically targets Windows CryptoAPI.
-- Examine the event logs for any recent entries related to certificate validation failures or anomalies, focusing on the time frame around the alert.
-- Investigate the source of the potentially spoofed certificate by identifying the issuer and subject fields in the certificate details, if available.
-- Use Osquery to gather more information about the affected system. For example, run the following query to list all certificates in the system's certificate store: `SELECT * FROM certificates WHERE common_name LIKE '%CVE-2020-0601%';`
-- Analyze network traffic logs to identify any unusual outbound connections that may have been initiated by the potentially malicious executable.
-- Cross-reference the hash of the suspicious executable with known malware databases to determine if it has been previously identified as malicious.
-- Review recent software installations or updates on the affected system to identify any unauthorized or unexpected changes that could be related to the spoofed certificate.
-- Check for any other alerts or indicators of compromise on the same host that might suggest a broader attack campaign or additional tactics being used.
-- Collaborate with other security teams to gather intelligence on any similar incidents or patterns observed in the network, which could provide additional context or indicators for the investigation.
-
-### False positive analysis
-
-- Legitimate software updates or installations might trigger the detection rule if they use ECC certificates that resemble the characteristics of those exploited in CVE-2020-0601. Users should verify the source of the software and, if confirmed safe, create an exception for these specific certificates.
-- Internal testing environments that utilize self-signed ECC certificates for development purposes may also be flagged. To manage this, users can whitelist these certificates or exclude specific test environments from monitoring.
-- Security tools or applications that perform certificate validation testing might generate alerts. Users should identify these tools and configure the detection rule to ignore their activities by adding them to an exception list.
-- Some enterprise environments may have custom applications that use non-standard ECC certificates, which could be mistaken for malicious activity. In such cases, users should document these applications and adjust the detection parameters to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate affected systems from the network to prevent further exploitation and lateral movement.
-- Validate the presence of the spoofed certificate by checking the event logs for entries matching the detection query.
-- Revoke any identified malicious certificates and update the certificate trust list to prevent future misuse.
-- Apply the latest security patches from Microsoft to address CVE-2020-0601 and ensure all systems are up to date.
-- Conduct a thorough investigation to identify any additional compromised systems or accounts using the MITRE ATT&CK framework, focusing on Defense Evasion and Subvert Trust Controls.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Implement enhanced logging policies to capture detailed cryptographic operations and certificate validation processes.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Restore affected systems from clean backups and verify the integrity of critical files and applications before reconnecting to the network.
-- Strengthen system hardening measures by enforcing strict certificate validation policies and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_disable_nla.toml b/rules/windows/defense_evasion_disable_nla.toml
index 864918db51c..817b3ffbd14 100644
--- a/rules/windows/defense_evasion_disable_nla.toml
+++ b/rules/windows/defense_evasion_disable_nla.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/25"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,48 +48,6 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
     "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication"
   ) and registry.data.strings :  ("0", "0x00000000")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network-Level Authentication (NLA) Disabled
-
-Network-Level Authentication (NLA) enhances security for Remote Desktop Protocol (RDP) by requiring user authentication before establishing a session. Disabling NLA can allow attackers to exploit the Windows sign-in screen for persistence, bypassing authentication. The detection rule identifies registry changes that disable NLA, flagging potential unauthorized modifications indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path and value changes, specifically checking for modifications to `HKLM\\SYSTEM\\ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication` with values set to "0" or "0x00000000".
-- Verify the timestamp of the registry change to determine when the modification occurred and correlate it with other events in the system logs around the same time.
-- Identify the user account and process responsible for the registry modification by examining the event logs for the `event.action` field, ensuring it is not a deletion, and cross-referencing with the `host.os.type` to confirm it is a Windows system.
-- Check for any recent logins or RDP sessions around the time of the registry change to identify potential unauthorized access attempts.
-- Use Osquery to gather additional context on the system by running a query to list all recent registry changes: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\SYSTEM\\ControlSet%\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication';`
-- Investigate any other registry changes made by the same user or process to identify if there are additional unauthorized modifications.
-- Examine the system's security and application logs for any suspicious activities or errors that might indicate an attempt to exploit the disabled NLA.
-- Review network logs for unusual RDP connection attempts or traffic patterns that could suggest an attacker is attempting to exploit the disabled NLA.
-- Check for the presence of known persistence mechanisms, such as modified Accessibility Features, that could be leveraged by an attacker after disabling NLA.
-- Consult threat intelligence sources to determine if there are any known campaigns or malware that specifically target NLA settings for persistence or defense evasion.
-
-### False positive analysis
-
-- Legitimate administrative actions: System administrators may intentionally disable NLA for troubleshooting or compatibility reasons. To manage this, create exceptions for known administrative accounts or scheduled maintenance periods.
-- Software updates or installations: Certain software updates or installations might modify registry settings, including NLA, as part of their process. Users can handle these by monitoring update schedules and excluding known software processes from triggering alerts.
-- Group policy changes: Changes in group policies might inadvertently disable NLA across multiple systems. To address this, ensure that group policy changes are documented and approved, and exclude these changes from detection rules.
-- Virtual machine templates: Cloning or deploying virtual machines from templates where NLA is disabled can trigger false positives. Users should verify template configurations and exclude these specific registry changes during deployment processes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the registry change by checking the specified registry path to confirm if NLA has been disabled.
-- Conduct a thorough investigation to identify any unauthorized access or persistence mechanisms, such as checking for unusual user accounts or scheduled tasks.
-- Restore the registry setting to enable NLA by setting the "UserAuthentication" value to "1" or "0x00000001".
-- Review system and security logs to identify any suspicious activities or patterns that may indicate a broader compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed RDP connection attempts and registry changes for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Conduct a security audit of RDP configurations across the network to ensure compliance with security best practices, such as enforcing strong authentication and using VPNs for remote access.
-- Educate users and administrators on the importance of NLA and other security measures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_dns_over_https_enabled.toml b/rules/windows/defense_evasion_dns_over_https_enabled.toml
index 64eb424f1d1..9bb21c0aa79 100644
--- a/rules/windows/defense_evasion_dns_over_https_enabled.toml
+++ b/rules/windows/defense_evasion_dns_over_https_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,48 +48,6 @@ registry where host.os.type == "windows" and event.type == "change" and
   (registry.path : "*\\SOFTWARE\\Policies\\Mozilla\\Firefox\\DNSOverHTTPS" and
   registry.data.strings : ("1", "0x00000001"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 DNS-over-HTTPS Enabled via Registry
-
-DNS-over-HTTPS (DoH) encrypts DNS queries to enhance privacy and security, preventing eavesdropping and manipulation. However, adversaries can exploit DoH to conceal malicious activities, such as data exfiltration, by bypassing traditional DNS monitoring. The detection rule identifies registry changes enabling DoH in browsers like Edge, Chrome, and Firefox, signaling potential misuse by monitoring specific registry paths and values.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path and value that triggered the alert, focusing on the `registry.path` and `registry.data.strings` fields.
-- Verify the legitimacy of the registry change by checking if the change aligns with any recent software updates or policy changes within the organization.
-- Use Osquery to list recent registry changes on the affected host to identify any other suspicious modifications. Example query: `SELECT * FROM registry WHERE path LIKE '%SOFTWARE\\\\Policies\\\\%' AND mtime > (SELECT datetime('now', '-1 day'));`
-- Investigate the user account associated with the registry change to determine if the account has a history of suspicious activity or if it has been compromised.
-- Check the system's event logs for any unusual activity around the time of the registry change, such as unexpected logins or process executions.
-- Analyze network traffic from the affected host to identify any unusual DNS queries or connections that could indicate data exfiltration or communication with malicious domains.
-- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
-- Review the browser settings and extensions on the affected host to ensure no unauthorized changes or installations have occurred.
-- Consult with the user of the affected host to determine if they made the change intentionally and if so, understand the context and purpose behind it.
-- Document all findings and observations to provide a comprehensive overview of the investigation, which can be used for further analysis or reporting.
-
-### False positive analysis
-
-- Enabling DNS-over-HTTPS for legitimate privacy reasons: Users or IT departments may enable DoH to enhance privacy and security without malicious intent. This can be a common practice in organizations prioritizing data protection.
-- Browser updates or policy changes: Automatic updates or changes in browser policies might enable DoH by default, triggering the detection rule without any malicious activity.
-- Security software configurations: Some security software might enable DoH as part of their protective measures, leading to false positives.
-- Handling false positives: To manage these, users can create exceptions for known legitimate changes by whitelisting specific registry paths or values associated with trusted applications or updates. Regularly review and update these exceptions to ensure they align with current organizational policies and software configurations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential data exfiltration or further malicious activity.
-- Conduct a thorough investigation to determine if the registry changes were authorized or if they indicate malicious intent, focusing on recent user activities and installed software.
-- Review system logs and network traffic for any signs of data exfiltration or communication with known malicious IP addresses, leveraging existing security tools and threat intelligence feeds.
-- If unauthorized changes are confirmed, revert the registry settings to their original state and ensure DNS-over-HTTPS is disabled unless explicitly required for business purposes.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for registry changes and DNS queries to improve detection of similar activities in the future.
-- Integrate threat intelligence platforms and endpoint detection and response (EDR) solutions to provide better visibility and context for future investigations.
-- Educate users on the risks associated with unauthorized changes to system settings and the importance of reporting suspicious activities.
-- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited by attackers.
-- Review and update security policies and procedures to include specific measures for handling DNS-over-HTTPS and registry modifications, ensuring alignment with MITRE ATT&CK framework techniques such as T1112."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
index e929e9fa930..f0b273d90e7 100644
--- a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
+++ b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,48 +52,6 @@ process where host.os.type == "windows" and event.type == "start" and
   process.name : ("csc.exe", "vbc.exe") and
   process.parent.name : ("wscript.exe", "mshta.exe", "cscript.exe", "wmic.exe", "svchost.exe", "rundll32.exe", "cmstp.exe", "regsvr32.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious .NET Code Compilation
-
-.NET compilers like `csc.exe` and `vbc.exe` are essential for converting human-readable code into executable programs on Windows systems. Adversaries exploit these compilers by executing them with unusual parent processes, such as scripting engines or system utilities, to compile malicious code stealthily. The detection rule identifies such anomalies by monitoring compiler executions initiated by atypical parent processes, signaling potential evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a .NET compiler execution (`csc.exe` or `vbc.exe`) with a suspicious parent process (`wscript.exe`, `mshta.exe`, `cscript.exe`, `wmic.exe`, `svchost.exe`, `rundll32.exe`, `cmstp.exe`, `regsvr32.exe`).
-- Examine the process tree to understand the sequence of events leading to the compiler execution, focusing on the parent and grandparent processes.
-- Check the command line arguments used in the suspicious process execution to identify any potentially malicious scripts or commands.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Use Osquery to gather additional context about the process, such as the full command line and environment variables, with a query like: `SELECT * FROM processes WHERE name IN ('csc.exe', 'vbc.exe') AND parent IN (SELECT pid FROM processes WHERE name IN ('wscript.exe', 'mshta.exe', 'cscript.exe', 'wmic.exe', 'svchost.exe', 'rundll32.exe', 'cmstp.exe', 'regsvr32.exe'));`
-- Analyze recent file modifications in directories commonly used for temporary or suspicious file storage to identify any newly compiled executables or scripts.
-- Correlate the event with network activity logs to detect any unusual outbound connections that might indicate data exfiltration or command and control communication.
-- Review system logs for any other suspicious activities or anomalies around the time of the alert, such as privilege escalation attempts or unusual login patterns.
-- Check for any related alerts or incidents in the security information and event management (SIEM) system to identify potential patterns or coordinated attacks.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise (IOCs).
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators may use scripts that invoke .NET compilers for legitimate tasks, such as automating software deployments or configurations. These scripts might be executed by scripting engines like `wscript.exe` or `cscript.exe`, leading to false positives.
-- Software development environments: Developers working on .NET applications might use integrated development environments (IDEs) or build scripts that call `csc.exe` or `vbc.exe` with parent processes that are not typical for production environments, such as `cmd.exe` or `powershell.exe`.
-- Automated build systems: Continuous integration/continuous deployment (CI/CD) systems might trigger .NET compiler executions as part of their build processes, which could be flagged if the parent process is a script or utility.
-- To manage these false positives, users can create exceptions for known benign processes or scripts by adding them to an allowlist. This can be done by identifying the specific parent processes or command lines associated with legitimate activities and excluding them from the detection rule. Regularly reviewing and updating these exceptions is crucial to ensure that only non-threatening behaviors are excluded.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potentially malicious code.
-- Conduct a thorough investigation to identify the source and scope of the suspicious activity, focusing on the parent processes that initiated the .NET compiler execution.
-- Review and analyze logs from the affected system and any associated systems to trace the attacker's activities and identify any additional compromised systems.
-- Remove any malicious code or files identified during the investigation, ensuring that all remnants of the attack are eradicated from the system.
-- Restore the system from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from any compromise.
-- Update and patch all software and systems to the latest versions to mitigate vulnerabilities that could be exploited by similar attacks.
-- Implement enhanced logging policies to capture detailed process execution data, including parent-child process relationships, to aid in future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities for similar threats.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement measures to address these gaps, such as deploying application whitelisting or restricting script execution.
-- Escalate the incident to relevant internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and assistance in preventing future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
index d1c7bdd6f01..24186a5e8cd 100644
--- a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
+++ b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/08"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,49 +62,6 @@ process where host.os.type == "windows" and event.type == "start" and
     "*\\AppData\\Local\\*"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Control Panel Process with Unusual Arguments
-
-The Windows Control Panel, typically used for system settings, can be exploited by adversaries to execute malicious code under the guise of legitimate processes. By manipulating command line arguments, attackers can proxy execution through control.exe, evading detection. The detection rule identifies anomalies by flagging unusual file types and suspicious paths in the command line, indicating potential misuse for malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific command line arguments that triggered the detection, focusing on unusual file types and suspicious paths.
-- Examine the process tree to identify the parent process of control.exe, which may provide context on how the process was initiated.
-- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Investigate the file paths and file types in the command line arguments to verify if they are legitimate or if they could be indicative of malicious activity.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'control.exe' AND cmdline LIKE '%<suspicious_argument>%';` to find other instances of similar command line usage.
-- Analyze recent file modifications in the directories specified in the command line arguments to identify any unauthorized changes or suspicious files.
-- Review system logs for any related events around the time the control.exe process was started to identify any correlated activities or anomalies.
-- Check for any network connections initiated by the control.exe process to determine if there is any suspicious outbound communication.
-- Investigate any scheduled tasks or startup items that might have been used to persistently execute the control.exe process with unusual arguments.
-- Correlate the findings with threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- Users may encounter false positives when legitimate applications or system processes use control.exe with unusual file types or paths for valid purposes, such as custom configuration tools or third-party software that integrates with the Control Panel.
-- Some software installations or updates might temporarily use control.exe with paths like `*/AppData/Local/*` or `*:\\\\Users\\\\Public\\\\*` to manage settings or user data, which could trigger the rule.
-- Multimedia applications might inadvertently use image file extensions in command lines for legitimate reasons, leading to false positives when extensions like `*.jpg*` or `*.png*` are detected.
-- To manage these false positives, users can create exceptions for known benign processes or paths by adding them to an allowlist, ensuring that frequent non-threatening behaviors are not flagged.
-- Regularly review and update the allowlist to accommodate new legitimate applications or changes in system behavior, reducing unnecessary alerts while maintaining security.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation of the process command line arguments to confirm the presence of malicious activity, focusing on unusual file types and suspicious paths.
-- Review recent changes to the system, including installed applications and modified files, to identify any unauthorized or suspicious modifications.
-- Utilize endpoint detection and response (EDR) tools to perform a deep scan of the system for additional indicators of compromise (IOCs) and potential persistence mechanisms.
-- Remove any identified malicious files or processes and restore any altered system files from a known good backup.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution data, including command line arguments, to aid in future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are properly set.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and educating users on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
index 9d01ccc7c40..bb5c221efa9 100755
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,50 +46,6 @@ host.os.type:windows and event.category:process and event.type:start and (
   process.parent.name:("cmd.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "cscript.exe" or
     "wscript.exe" or "mshta.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft Build Engine Started by a Script Process
-
-The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers during software development. However, adversaries can exploit MSBuild to execute malicious code by embedding scripts within build files, leveraging its trusted status to bypass security controls. The detection rule identifies unusual MSBuild invocations initiated by script interpreters, signaling potential misuse for executing unauthorized actions.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of MSBuild.exe being started by a script process, focusing on the `process.name` and `process.parent.name` fields.
-- Examine the `host.os.type` and `event.category` fields to ensure the event pertains to a Windows process start, confirming the context of the alert.
-- Investigate the parent process (`process.parent.name`) to determine if it is a known script interpreter like `cmd.exe`, `powershell.exe`, or others listed in the query.
-- Check the `process.command_line` field to gather more context on the command executed, looking for any suspicious or unexpected arguments.
-- Correlate the event with other recent process creation events on the same host to identify any patterns or related activities.
-- Use Osquery to list all running processes and their parent-child relationships to identify any other unusual process trees. Example query: `SELECT pid, name, path, parent FROM processes WHERE name = 'msbuild.exe';`
-- Investigate the user account associated with the process (`user.name`) to determine if it aligns with expected usage patterns or if it might be compromised.
-- Review recent file modifications or creations in directories commonly used by MSBuild to identify any unauthorized or suspicious build files.
-- Check for any network connections initiated by the MSBuild process using network monitoring tools to identify potential data exfiltration or command and control activity.
-- Analyze historical data for similar events on the same host or across the environment to determine if this is an isolated incident or part of a broader pattern.
-
-### False positive analysis
-
-- Developers and build automation systems may legitimately invoke MSBuild through scripts for continuous integration and deployment processes, leading to false positives. 
-- Automated testing frameworks might use script-based invocations of MSBuild to compile test environments, which can be mistaken for malicious activity.
-- Some development environments or integrated development environments (IDEs) may use scripts to trigger MSBuild as part of their normal operation, causing benign alerts.
-- To manage these false positives, users can create exceptions for known and trusted script processes or parent processes that regularly invoke MSBuild in a non-threatening manner.
-- Implementing a whitelist of specific script paths or parent process hashes that are verified as part of legitimate development workflows can help reduce unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure that only verified and non-malicious activities are excluded from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to determine the scope of the incident, focusing on identifying any additional systems that may have been compromised.
-- Analyze the MSBuild process and its parent script process to understand the nature of the payload and any potential persistence mechanisms.
-- Review and collect relevant logs, including PowerShell logs, command line history, and security event logs, to gather evidence and understand the attack vector.
-- Remove any unauthorized or malicious scripts and build files identified during the investigation to prevent further execution.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Restore the system from a known good backup to ensure the integrity of the operating environment.
-- Implement enhanced logging and monitoring policies to detect similar activities in the future, such as enabling script block logging and command line auditing.
-- Integrate threat intelligence feeds and security solutions to improve detection capabilities and provide context for future investigations.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
index 755e767f9d5..3478af63413 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,48 +53,6 @@ process where host.os.type == "windows" and event.type == "start" and
   process.name : "MSBuild.exe" and
   process.parent.name : ("explorer.exe", "wmiprvse.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft Build Engine Started by a System Process
-
-The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers or integrated development environments. However, adversaries may exploit MSBuild to execute malicious code by disguising it as a legitimate build process. This detection rule identifies unusual MSBuild activity initiated by system processes like Explorer or WMI, which may indicate an attempt to evade defenses by leveraging trusted utilities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "MSBuild.exe" and the parent process is either "explorer.exe" or "wmiprvse.exe" to ensure the rule was triggered correctly.
-- Check the timestamp of the MSBuild.exe process start event to determine when the activity occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the user account associated with the MSBuild.exe process to determine if it is a legitimate user or if the account may have been compromised.
-- Examine the command line arguments used to start MSBuild.exe to identify any unusual or suspicious parameters that could indicate malicious intent.
-- Use Osquery to gather additional context about the MSBuild.exe process. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'MSBuild.exe';`
-- Analyze the parent process (explorer.exe or wmiprvse.exe) to understand its recent activities and determine if it has been involved in any other suspicious behavior.
-- Check for any network connections initiated by MSBuild.exe to identify potential communication with external servers or command and control infrastructure.
-- Review system logs and security events around the time of the alert to identify any other indicators of compromise or related suspicious activities.
-- Investigate any recent changes to the system, such as new software installations or updates, that could explain the unusual MSBuild activity.
-- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize MSBuild.exe in a similar manner, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Known false positives for the Microsoft Build Engine Started by a System Process rule may include legitimate software installations or updates that utilize MSBuild as part of their setup process. These activities might be initiated by system processes like Explorer or WMI, leading to benign triggers of the detection rule.
-- Development environments or automated build systems that integrate with Windows Explorer or WMI for project management tasks can also cause false positives. These systems might start MSBuild as part of their normal operation, which is non-threatening.
-- To manage these false positives, users can create exceptions for specific parent-child process relationships that are known to be safe. This can be done by identifying the hash or path of the legitimate MSBuild instances and excluding them from the detection rule.
-- Users should regularly review and update their exception lists to ensure that only verified and non-malicious activities are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation to confirm the legitimacy of the MSBuild process by reviewing the process tree and any associated scripts or commands executed.
-- Analyze the parent process (explorer.exe or wmiprvse.exe) to determine if it was compromised or used as a proxy for malicious activity.
-- Review system logs and security alerts to identify any other suspicious activities or related incidents on the network.
-- If malicious activity is confirmed, remove any identified malware or unauthorized scripts from the system.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Implement enhanced logging policies to capture detailed process execution and parent-child relationships for future investigations.
-- Integrate threat intelligence feeds and security solutions to detect similar tactics, techniques, and procedures (TTPs) associated with MITRE ATT&CK T1127.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Apply system hardening measures, such as restricting the execution of MSBuild to authorized users and processes, and regularly update security patches and configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
index ac5d2f1d4da..0e0e298687a 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,49 +51,6 @@ query = '''
 host.os.type:windows and event.category:process and event.type:start and process.parent.name:("MSBuild.exe" or "msbuild.exe") and
 process.name:("csc.exe" or "iexplore.exe" or "powershell.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft Build Engine Started an Unusual Process
-
-The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries exploit MSBuild to execute malicious scripts or compile code, bypassing security controls. This detection rule identifies unusual processes initiated by MSBuild, such as PowerShell or C# compiler, which may indicate an attempt to deploy obfuscated or malicious payloads, aligning with known evasion techniques.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of unusual processes initiated by MSBuild, focusing on the `process.parent.name` and `process.name` fields to identify the specific processes involved.
-- Examine the process command line arguments (`process.command_line`) for any suspicious or obfuscated scripts that may indicate malicious intent.
-- Check the user account (`user.name`) associated with the MSBuild process to determine if the activity aligns with expected behavior for that user.
-- Investigate the parent process tree to understand the context in which MSBuild was executed, looking for any preceding suspicious activities.
-- Utilize Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('MSBuild.exe', 'csc.exe', 'powershell.exe');` to identify any related processes and their attributes.
-- Analyze the network connections (`network.connection`) established by the suspicious processes to identify any unusual or unauthorized external communications.
-- Review recent file modifications or creations (`file.path`) on the host to detect any potentially malicious payloads or scripts dropped by the processes.
-- Correlate the event timestamp with other security logs (e.g., firewall, intrusion detection systems) to identify any concurrent suspicious activities.
-- Check for any recent changes in system configurations or scheduled tasks that could be associated with the execution of the unusual processes.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or indicators of compromise (IOCs) related to MSBuild exploitation.
-
-### False positive analysis
-
-- Developers and build servers often use MSBuild to automate the compilation of code, which may legitimately invoke processes like the C# compiler (csc.exe) or PowerShell scripts for build tasks, leading to false positives.
-- Continuous Integration/Continuous Deployment (CI/CD) pipelines might trigger these processes as part of their normal operation, especially in environments where automated testing or deployment scripts are executed.
-- To manage these false positives, users can create exceptions for specific build servers or developer workstations by excluding known, trusted sources or specific process command lines that are frequently observed and verified as non-threatening.
-- Monitoring the frequency and context of these events can help distinguish between legitimate development activities and potential threats, allowing for more informed decisions on exclusions.
-- Implementing a baseline of normal MSBuild activity within the environment can aid in identifying deviations that are more likely to be malicious, thus reducing the likelihood of overlooking genuine threats while managing false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity.
-- Conduct a thorough investigation to identify the scope of the incident, focusing on any unusual processes initiated by MSBuild, such as PowerShell or C# compiler executions.
-- Analyze the scripts or code executed by MSBuild for any signs of obfuscation or malicious intent, leveraging threat intelligence sources and MITRE ATT&CK framework for context.
-- Terminate any malicious processes identified during the investigation to halt ongoing threats.
-- Remove any malicious files or scripts from the system and ensure that any persistence mechanisms are disabled.
-- Restore the system from a known good backup to ensure that no remnants of the attack remain.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution data, focusing on MSBuild and related processes, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Review and update security policies and hardening measures, such as application whitelisting and script execution restrictions, to prevent exploitation of MSBuild in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
index 6f9396434a2..17ca6cfd018 100644
--- a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
+++ b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,48 +55,6 @@ process where host.os.type == "windows" and event.type == "start" and
                                "?:\\Windows\\System32\\inetsrv\\w3wp.exe")
          )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential DLL Side-Loading via Trusted Microsoft Programs
-
-DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs. The detection rule identifies unusual execution paths or renamed instances of known vulnerable programs, flagging potential evasion attempts by checking against expected file names and paths.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and executable path that triggered the alert, focusing on the `process.name` and `process.executable` fields.
-- Verify the legitimacy of the process by checking the `process.pe.original_file_name` against known trusted Microsoft programs such as "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", and "DISM.EXE".
-- Investigate the parent process that initiated the suspicious process using the `process.parent.name` and `process.parent.executable` fields to determine if it is a legitimate or expected parent.
-- Check the file path of the executable using the `process.executable` field to see if it matches any non-standard or unexpected paths that deviate from the typical installation directories.
-- Use Osquery to list all DLLs loaded by the suspicious process to identify any unusual or unauthorized DLLs. Example query: `SELECT pid, name, path FROM processes JOIN process_open_sockets USING (pid) WHERE name = '<suspicious_process_name>';`
-- Examine the file creation and modification timestamps of the suspicious executable and any associated DLLs to identify any recent changes that could indicate tampering.
-- Cross-reference the hash of the suspicious executable and DLLs with known malware databases or threat intelligence sources to check for known malicious signatures.
-- Analyze the network activity associated with the suspicious process using network monitoring tools to identify any unusual or unauthorized connections.
-- Review system logs and security events around the time of the alert to gather additional context and identify any related suspicious activities.
-- Consult with other team members or departments to determine if there are any legitimate reasons for the process to be running from a non-standard path, such as a recent software update or deployment.
-
-### False positive analysis
-
-- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths, triggering false positives. Users can handle these by monitoring update schedules and creating temporary exceptions during known update windows.
-- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes, such as compatibility or integration needs. Users should document these instances and create exceptions for known benign paths or renamed executables.
-- Virtual environments or sandboxed applications may execute trusted programs from non-standard paths as part of their isolation mechanisms. Users can identify these environments and exclude their specific paths from the detection rule.
-- Security or IT administrative tools might leverage renamed or relocated trusted programs for legitimate system management tasks. Users should verify the legitimacy of these tools and add them to an exception list if they are deemed non-threatening.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to confirm the presence of unauthorized DLLs by analyzing the process execution paths and comparing them against known trusted paths.
-- Utilize endpoint detection and response (EDR) tools to identify any additional systems that may exhibit similar suspicious behavior.
-- Remove or quarantine any identified malicious DLLs and restore the original trusted Microsoft program files to their correct paths and names.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor has established persistence or lateral movement.
-- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring that future anomalies can be detected more efficiently.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of known malicious DLLs and associated tactics.
-- Restore the system to its operational state by applying the latest security patches and updates to all software, particularly focusing on the affected Microsoft programs.
-- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
-- Implement hardening measures such as application whitelisting, restricting DLL loading paths, and educating users on recognizing and reporting suspicious activity."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
index 65a8b933af6..c46c13405b5 100644
--- a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
+++ b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/07"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,48 +59,6 @@ process where host.os.type == "windows" and event.type == "start" and
                               "?:\\Program Files (x86)\\Microsoft Security Client\\*.exe"))
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential DLL Side-Loading via Microsoft Antimalware Service Executable
-
-The Microsoft Antimalware Service Executable is a core component of Windows Defender, responsible for real-time protection against malware. Adversaries may exploit its DLL search order vulnerability by renaming or relocating the executable to load malicious DLLs, bypassing security measures. The detection rule identifies anomalies in the executable's path or name, signaling potential side-loading attempts, thus aiding in early threat detection.
-
-### Possible investigation steps
-
-- Verify the alert by checking the process details, focusing on the `process.name` and `process.executable` fields to confirm if the executable is running from a non-standard path or has been renamed.
-- Review the `process.pe.original_file_name` field to ensure it matches the expected original file name "MsMpEng.exe" and investigate any discrepancies.
-- Examine the parent process information to determine how the suspicious process was initiated, which might provide insights into potential exploitation methods.
-- Check for any recent file modifications or creations in the directories where the suspicious executable is located, which could indicate tampering or preparation for side-loading.
-- Use Osquery to list all DLLs loaded by the suspicious process to identify any unexpected or malicious DLLs. Example query: `SELECT * FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name = 'MsMpEng.exe');`
-- Investigate the system's event logs for any related security events or anomalies around the time the suspicious process started, focusing on logs that might indicate privilege escalation or lateral movement.
-- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
-- Cross-reference the hash of the suspicious executable with known malware databases to check for any known malicious signatures.
-- Review user activity and access logs to determine if any unauthorized users or accounts were active around the time of the alert.
-- Conduct a historical search for similar alerts or patterns on the host or across the network to assess if this is an isolated incident or part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate software updates or system maintenance tasks may temporarily alter the path or name of the Microsoft Antimalware Service Executable, triggering false positives. Users should verify if any updates or maintenance activities coincide with the detection.
-- Some third-party security or system optimization tools might interact with Windows Defender in a way that changes the executable's path or name. Users should review the list of installed software to identify any such tools and consider excluding their activities if deemed safe.
-- In enterprise environments, custom scripts or deployment tools might relocate or rename the executable for legitimate reasons. Users should consult with IT administrators to confirm if such practices are in place and create exceptions for these known activities.
-- To manage false positives, users can create exceptions in their security monitoring tools for specific paths or names that are verified as non-threatening. This involves updating the detection rule to exclude these known benign behaviors while ensuring that the core detection capabilities remain intact.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Verify the legitimacy of the Microsoft Antimalware Service Executable by checking its path and name against known safe locations and names.
-- Conduct a thorough investigation to identify any malicious DLLs loaded by the renamed or relocated executable.
-- Utilize endpoint detection and response (EDR) tools to analyze the process tree and identify any suspicious child processes or network connections.
-- Remove any identified malicious DLLs and restore the Microsoft Antimalware Service Executable to its original state and location.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
-- Integrate threat intelligence feeds to correlate the detected activity with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by applying the latest security patches and updates to Windows Defender and the operating system.
-- Harden the system by configuring application whitelisting and ensuring that only trusted executables and DLLs are allowed to run."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_file_creation_mult_extension.toml b/rules/windows/defense_evasion_file_creation_mult_extension.toml
index e495e8c575b..b3b03816550 100644
--- a/rules/windows/defense_evasion_file_creation_mult_extension.toml
+++ b/rules/windows/defense_evasion_file_creation_mult_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,49 +41,6 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten
   not (process.executable : ("?:\\Windows\\System32\\msiexec.exe", "C:\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe") and
        file.path : "?:\\Program Files\\QGIS *\\apps\\grass\\*.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Executable File Creation with Multiple Extensions
-
-In Windows environments, files with multiple extensions can be used by adversaries to disguise malicious executables as benign files, such as documents or images. This technique, known as masquerading, exploits user trust and can bypass security measures. The detection rule identifies suspicious file creations by checking for executables with misleading extensions, excluding known legitimate processes, to uncover potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file name and path that triggered the rule, focusing on the `file.name` and `file.path` fields.
-- Verify the file extension pattern by checking if the file name matches the regex pattern for multiple extensions, particularly looking for `.exe` files masquerading as other types.
-- Examine the `process.executable` field to determine the process responsible for creating the file, ensuring it is not a known legitimate process like `msiexec.exe`.
-- Use Osquery to gather additional context about the file by running a query such as: `SELECT * FROM file WHERE path = 'C:\\\\Path\\\\To\\\\SuspiciousFile.exe';` to retrieve metadata and attributes.
-- Investigate the parent process of the file creation event by examining the `process.parent` field to understand the origin of the executable.
-- Check the file's digital signature and hash against known threat intelligence databases to assess its legitimacy.
-- Analyze recent user activity on the host to identify any unusual behavior or actions that might have led to the file creation.
-- Review system logs for any other suspicious activities or anomalies around the time of the file creation event.
-- Investigate network connections from the host to determine if there are any suspicious outbound connections that could indicate data exfiltration or command and control communication.
-- Correlate the findings with other alerts or incidents in the environment to identify potential patterns or related threats.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate software installations or updates create files with multiple extensions, such as setup or update executables that include additional extensions for versioning or compatibility purposes.
-- Users can handle these false positives by creating exceptions for specific processes or file paths that are known to be safe, such as trusted software installers or update mechanisms.
-- Another potential false positive source is software development environments where developers might create test files with multiple extensions for debugging or testing purposes.
-- To manage these, users can exclude specific directories or processes associated with development tools from the detection rule.
-- It's important to regularly review and update the list of exceptions to ensure that only verified and trusted activities are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to identify the source and scope of the masquerading executable, using endpoint detection and response (EDR) tools.
-- Analyze the file creation event and associated processes to determine if any unauthorized changes or additional malicious activities have occurred.
-- Remove the malicious executable and any associated files or registry entries from the system.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on executable files with multiple extensions.
-- Integrate threat intelligence feeds to improve detection capabilities and correlate with known indicators of compromise (IOCs) related to masquerading techniques.
-- Educate users on the risks of opening files with multiple extensions and the importance of verifying file types before execution.
-- Apply system hardening measures, such as restricting script execution policies and enforcing application whitelisting, to reduce the attack surface and prevent similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
index d9cab01bc42..25ed246466d 100644
--- a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
+++ b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,48 +29,6 @@ registry where host.os.type == "windows" and
 /* update here with encoding combinations */
  registry.data.strings : "TVqQAAMAAAAEAAAA*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Encoded Executable Stored in the Registry
-
-Windows Registry is a critical system database that stores configuration settings and options. Adversaries may exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications by searching for specific encoded patterns, indicating potential defense evasion tactics. This helps analysts pinpoint and investigate hidden threats effectively.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path and key where the encoded executable was detected. This information is crucial for understanding the scope and potential impact.
-- Use the registry path and key information to perform a manual inspection of the registry entry. Verify the presence of the encoded data and assess its legitimacy.
-- Decode the identified encoded string to determine if it corresponds to a known malicious executable or if it appears suspicious. Utilize tools or scripts capable of decoding base64 or other encoding schemes.
-- Cross-reference the decoded executable with known malware signatures or hashes using threat intelligence databases to identify any matches with known threats.
-- Investigate the process that made the registry modification by correlating the timestamp of the registry change with process creation logs. This can help identify the responsible process or user.
-- Utilize Osquery to gather additional context about the system. For example, run the following query to list recent registry modifications: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\%\\\\%';`
-- Check for any associated network activity around the time of the registry modification. Look for unusual outbound connections that might indicate data exfiltration or command and control communication.
-- Examine the system for other indicators of compromise, such as unusual scheduled tasks, startup items, or services that could be related to the encoded executable.
-- Review user activity logs to determine if the registry modification aligns with legitimate user actions or if it appears to be unauthorized or suspicious.
-- Consult with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather additional insights and corroborate findings from the registry investigation.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify the registry with encoded data, which could trigger the detection rule. Users should verify the source and purpose of such modifications to determine if they are benign.
-- Some security tools or system management software might store encoded executables in the registry as part of their normal operation. Users can create exceptions for these known applications to prevent unnecessary alerts.
-- Custom scripts or administrative tools developed in-house may use encoded registry entries for configuration or deployment purposes. It is advisable to document these practices and exclude them from the detection rule if they are verified as non-threatening.
-- Regularly review and update the list of exceptions to ensure that only verified and trusted software is excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the registry modifications to confirm the presence of encoded executables and identify the scope of the compromise.
-- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) related to the identified threat.
-- Remove or revert unauthorized registry changes to eliminate the persistence mechanism used by the adversary.
-- Restore affected systems from known good backups to ensure the removal of any hidden malicious executables.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Implement enhanced logging policies to capture detailed registry activity and monitor for similar suspicious patterns in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for registry-based threats.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
-- Educate users on recognizing and reporting suspicious activities to reduce the risk of future incidents involving registry modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_injection_msbuild.toml b/rules/windows/defense_evasion_injection_msbuild.toml
index 5bcc6479a16..d89f796cde2 100755
--- a/rules/windows/defense_evasion_injection_msbuild.toml
+++ b/rules/windows/defense_evasion_injection_msbuild.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,48 +35,6 @@ query = '''
 process where host.os.type == "windows" and process.name: "MSBuild.exe" and
     event.action:("CreateRemoteThread detected (rule: CreateRemoteThread)", "CreateRemoteThread")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Injection by the Microsoft Build Engine
-
-The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries exploit MSBuild to perform process injection, a technique to execute malicious code within the address space of another process, thereby evading detection and elevating privileges. The detection rule identifies suspicious activity by monitoring MSBuild for actions like creating remote threads, a common indicator of process injection attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the "CreateRemoteThread" event action associated with "MSBuild.exe" to ensure the alert is not a false positive.
-- Check the process tree to identify the parent process of "MSBuild.exe" to determine if it was launched by a legitimate application or a suspicious one.
-- Investigate the command line arguments used to launch "MSBuild.exe" to identify any unusual or unexpected parameters that could indicate malicious activity.
-- Examine the timeline of events leading up to and following the "CreateRemoteThread" event to identify any other suspicious activities or patterns.
-- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'MSBuild.exe';`
-- Check for any network connections initiated by "MSBuild.exe" to external IP addresses, which could indicate data exfiltration or command and control communication.
-- Analyze any files or scripts that "MSBuild.exe" may have accessed or executed to determine if they contain malicious code or payloads.
-- Review the user account context under which "MSBuild.exe" was executed to assess if it aligns with expected user behavior or if it indicates potential credential compromise.
-- Correlate the alert with other security events or logs from the same host or network segment to identify if this is part of a broader attack campaign.
-- Consult threat intelligence sources to determine if there are known attack patterns or campaigns involving MSBuild process injection that match the observed behavior.
-
-### False positive analysis
-
-- Legitimate software development activities: MSBuild is commonly used in development environments, and legitimate processes may create remote threads as part of normal operations. Developers should verify if the activity aligns with known development tasks.
-- Automated build systems: Continuous integration and deployment systems might trigger MSBuild to perform actions that resemble process injection. Users should review the context of the build process to determine if the activity is expected.
-- Debugging tools: Some debugging or profiling tools may interact with processes in a way that mimics process injection. Users should check if such tools are running and exclude their activities if verified as non-threatening.
-- Excluding known safe processes: Users can create exceptions for specific processes or environments where MSBuild's behavior is understood and deemed safe, reducing noise from false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the threat.
-- Conduct a thorough investigation to confirm the presence of process injection by analyzing logs and memory dumps for suspicious activity related to MSBuild.
-- Terminate any malicious processes identified during the investigation to halt ongoing malicious activities.
-- Review and analyze the affected system's startup items, scheduled tasks, and services for unauthorized changes or additions.
-- Restore the system from a known good backup if available, ensuring that the backup is free from any signs of compromise.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process creation and thread injection events for future analysis.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_installutil_beacon.toml b/rules/windows/defense_evasion_installutil_beacon.toml
index d1d47636da7..6abd0388863 100644
--- a/rules/windows/defense_evasion_installutil_beacon.toml
+++ b/rules/windows/defense_evasion_installutil_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,49 +42,6 @@ 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")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 execute malicious code under the guise of legitimate operations, often to bypass security measures. The detection rule identifies suspicious activity by monitoring for outbound network connections initiated by InstallUtil.exe, which is atypical behavior for this utility, thus signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "installutil.exe" and verify the network connection direction is "outgoing" or "egress" as specified in the detection rule.
-- Check the process entity ID to identify the specific instance of InstallUtil.exe that initiated the network connection.
-- Investigate the parent process of InstallUtil.exe to determine how it was launched and assess if this is part of a legitimate operation or potentially malicious activity.
-- Examine the command line arguments used with InstallUtil.exe to identify any unusual or suspicious parameters that could indicate malicious intent.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'installutil.exe';` to retrieve details like process start time, user, and parent process.
-- Analyze the destination IP address and port of the network connection to determine if it is associated with known malicious infrastructure or if it is an expected destination for legitimate operations.
-- Cross-reference the network connection details with threat intelligence sources to identify any known indicators of compromise (IOCs) related to the destination.
-- Review recent system logs and security events for any other suspicious activities or anomalies that occurred around the same time as the InstallUtil.exe network connection.
-- Investigate the user account under which InstallUtil.exe was executed to determine if it has been compromised or if there are any signs of unauthorized access.
-- Check for any recent changes or installations on the system that could explain the use of InstallUtil.exe, such as legitimate software updates or installations, to rule out false positives.
-
-### False positive analysis
-
-- Legitimate software installations or updates: Some legitimate applications may use InstallUtil.exe to perform necessary installations or updates, which could trigger the detection rule. Users should verify if the network connection is associated with a known and trusted software installation or update process.
-- Internal network connections: InstallUtil.exe might be used within an organization's internal network for legitimate administrative tasks. If the network connections are directed towards internal IP addresses or known internal servers, these can be considered for exclusion.
-- Automated deployment tools: Organizations using automated deployment tools or scripts that leverage InstallUtil.exe for legitimate purposes might trigger false positives. Users should identify these tools and consider creating exceptions for known benign activities.
-- Exclude known benign processes: Users can create exceptions for specific processes or scripts that are verified to use InstallUtil.exe for legitimate purposes, ensuring these are documented and regularly reviewed to prevent abuse.
-- Regular monitoring and review: Continuously monitor and review alerts to distinguish between legitimate and suspicious activities, updating exceptions as necessary to minimize false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm the malicious use of InstallUtil.exe by reviewing process execution logs and network connection details.
-- Terminate any suspicious processes associated with InstallUtil.exe to halt ongoing malicious activities.
-- Analyze the network traffic logs to identify any external IP addresses or domains contacted by InstallUtil.exe and block them at the firewall.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Restore the system to a known good state by reimaging the affected machine and applying the latest security patches and updates.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate endpoint detection and response (EDR) solutions to monitor and alert on suspicious use of system binaries like InstallUtil.exe.
-- Educate users and administrators on the risks associated with misuse of legitimate utilities and encourage reporting of unusual system behavior.
-- Review and update security policies to include specific measures against system binary proxy execution techniques as outlined in MITRE ATT&CK T1218."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
index 8e8c267d1cf..ff5cb36de8a 100644
--- a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
+++ b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 
 [rule]
 author = ["Elastic"]
@@ -55,51 +55,6 @@ process where host.os.type == "windows" and event.type == "start" and
         "\\Device\\HarddiskVolume?\\Program Files\\*\\cdb.exe"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution via Windows Command Debugging Utility
-
-The Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. The detection rule identifies suspicious use of cdb.exe by monitoring its execution outside standard installation paths and checking for specific command-line arguments, indicating potential misuse for malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of cdb.exe execution outside the standard installation paths specified in the detection rule.
-- Verify the process arguments used with cdb.exe by examining the `process.args` field to identify any suspicious commands such as `-cf`, `-c`, or `-pd`.
-- Check the `process.executable` field to determine the exact path from which cdb.exe was executed, ensuring it is not within the expected directories.
-- Investigate the parent process of cdb.exe using the `process.parent.name` and `process.parent.executable` fields to understand how cdb.exe was launched and identify potential malicious parent processes.
-- Correlate the event timestamp with other security logs to identify any concurrent suspicious activities or anomalies on the host.
-- Use Osquery to gather additional context about the process and its execution environment. For example, run the following Osquery query to list all processes related to cdb.exe:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'cdb.exe';
-  ```
-- Examine the user account associated with the cdb.exe process using the `process.user.name` field to determine if the account is legitimate and authorized to perform debugging tasks.
-- Investigate network connections established by the host around the time of the alert to identify any unusual outbound connections that may indicate data exfiltration or command-and-control activity.
-- Review recent file modifications and creations on the host to detect any unauthorized changes or the presence of suspicious files that may have been introduced by the execution of cdb.exe.
-- Consult threat intelligence sources to determine if there are known campaigns or threat actors that utilize cdb.exe for malicious purposes, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate software development and debugging activities: Developers and IT professionals may use cdb.exe for legitimate debugging purposes, which can trigger the detection rule. To manage this, users can create exceptions for known development environments or specific user accounts that regularly perform debugging tasks.
-- Automated testing environments: Continuous integration and automated testing setups might utilize cdb.exe as part of their processes. Users should identify these environments and exclude them from the rule to prevent false positives.
-- System administration scripts: Some system administrators might use cdb.exe in scripts for maintenance or monitoring tasks. It's advisable to review these scripts and whitelist them if they are verified as non-threatening.
-- Security tools and forensic analysis: Security teams might employ cdb.exe during forensic investigations or security assessments. Users should document these activities and exclude them from the detection rule to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been affected.
-- Analyze the command-line arguments used with cdb.exe to understand the adversary's intent and actions taken on the system.
-- Review system and security logs to identify any other suspicious activities or anomalies that occurred around the time of the alert.
-- Remove any unauthorized or malicious files and restore any altered system files from a known good backup.
-- Apply patches and updates to the operating system and installed applications to mitigate any exploited vulnerabilities.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks associated with misuse of legitimate tools like cdb.exe and enforce strict access controls to limit their use."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
index 611b69e3384..2aa5a43e6fe 100644
--- a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
+++ b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -71,48 +71,6 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Endpoint Security Parent Process
-
-Endpoint security solutions, like Elastic Endpoint, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes. The detection rule identifies anomalies by flagging unexpected parent processes of endpoint security executables, excluding known benign sources, to uncover potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific parent process executable and its path that triggered the alert, focusing on the `process.parent.executable` field.
-- Verify the legitimacy of the parent process by checking its digital signature and comparing it against known trusted signatures.
-- Investigate the process tree to understand the relationship between the parent and child processes, using the `process.name` and `process.parent.executable` fields to map out the hierarchy.
-- Examine the command-line arguments of the parent process using the `process.args` field to identify any unusual or suspicious commands that may indicate malicious activity.
-- Use Osquery to gather additional context about the parent process. For example, run the following query to retrieve details about the parent process: `SELECT * FROM processes WHERE path = '<parent_process_path>';`.
-- Check the file hash of the parent process executable against threat intelligence databases to determine if it is associated with known malware.
-- Analyze recent system logs and security events for any other anomalies or related activities around the time the suspicious process was started.
-- Investigate the user account associated with the process start event to determine if there are any signs of compromise or unusual behavior.
-- Review network connections initiated by the suspicious process to identify any unexpected or unauthorized external communications.
-- Correlate the findings with other alerts or incidents in the environment to determine if this is part of a larger attack campaign.
-
-### False positive analysis
-
-- Known false positives for the Suspicious Endpoint Security Parent Process rule may include legitimate administrative or system maintenance activities where processes like `cmd.exe` or `powershell.exe` are used to execute benign scripts or commands. These activities might be flagged if they involve endpoint security executables as child processes.
-- Users can manage these false positives by adding exceptions for specific parent processes and command-line arguments that are known to be safe. For instance, if a script regularly uses `powershell.exe` with arguments like "status" or "upgrade" for legitimate purposes, these can be added to the exclusion list to prevent unnecessary alerts.
-- It's important to regularly review and update the list of excluded processes and arguments to ensure that only verified benign activities are excluded, maintaining a balance between security and operational efficiency.
-- Users should also consider the context of the flagged activity, such as the time of execution and the user account involved, to better assess whether an alert is a false positive or a potential threat.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the parent process to determine if it is indeed malicious, using forensic tools to analyze process memory and behavior.
-- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
-- Review and collect relevant logs from the endpoint and network devices to understand the scope and impact of the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Restore the system from a known good backup if the investigation confirms system compromise, ensuring that the backup is free from any malicious code.
-- Apply security patches and updates to the operating system and all installed software to mitigate vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities against similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
index 5601b1148bb..69125b3d1b2 100644
--- a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
+++ b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -163,49 +163,6 @@ process where host.os.type == "windows" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Masquerading as Business App Installer
-
-In Windows environments, executables often mimic legitimate business apps to deceive users into executing malicious software. Adversaries exploit this by distributing fake installers via ads or forums. The detection rule identifies suspicious executables in user download directories that lack proper code signatures from trusted developers, flagging potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific executable name and path that triggered the alert, focusing on the `process.name` and `process.executable` fields.
-- Verify the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to determine if the executable is indeed unsigned or signed by an untrusted entity.
-- Check the download source by examining browser history or download logs to identify how the executable was obtained, focusing on potential malicious ads or forum links.
-- Use Osquery to gather additional context about the executable. For example, run the following query to check the file's metadata and hash: `SELECT path, filename, md5, sha256, size FROM hash WHERE path = 'C:\\\\Users\\\\<username>\\\\Downloads\\\\<executable_name>'`.
-- Investigate the parent process that initiated the download or execution of the suspicious file by examining the `process.parent` field to understand the execution chain.
-- Cross-reference the executable's hash with known malware databases or threat intelligence platforms to check for any known malicious indicators.
-- Analyze the network activity associated with the executable using network logs or tools to identify any suspicious outbound connections or data exfiltration attempts.
-- Check for any persistence mechanisms that the executable might have established by reviewing startup items, scheduled tasks, or registry entries.
-- Review user activity logs around the time of the alert to identify any unusual behavior or actions that might indicate compromise.
-- Consult with the user who downloaded or executed the file to gather additional context and verify if they were expecting the download or if it was unsolicited.
-
-### False positive analysis
-
-- Legitimate software updates or beta versions may not have updated code signatures, leading to false positives. Users can verify the source and version of the software and create exceptions for these specific versions.
-- Custom or internally developed applications that mimic the naming conventions of popular business apps but are not signed by a recognized authority can trigger alerts. Organizations should ensure these applications are signed with a trusted internal certificate or add them to an exception list.
-- Some third-party tools or utilities that integrate with or enhance the functionality of legitimate business applications might not be signed by the original developer. Users should verify the legitimacy of these tools and consider adding them to an exception list if they are deemed safe.
-- In educational or testing environments, users might intentionally download unsigned versions of software for learning purposes. In such cases, exceptions can be made for specific user accounts or directories to prevent unnecessary alerts.
-- Users can manage false positives by regularly reviewing and updating the list of trusted code signatures and ensuring that any exceptions are documented and justified to maintain security integrity.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Verify the legitimacy of the executable by checking its hash against known malware databases and consulting with the software vendor if necessary.
-- Terminate any suspicious processes associated with the masquerading executable to halt any ongoing malicious activity.
-- Conduct a thorough investigation of the system to identify any additional indicators of compromise or lateral movement.
-- Remove the malicious executable and any related files from the system to prevent re-execution.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Update and patch all software and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
-- Implement enhanced logging and monitoring policies to capture detailed process execution and network activity for future investigations.
-- Educate users on recognizing phishing attempts and the risks of downloading executables from untrusted sources.
-- Report the incident to relevant internal teams and, if necessary, escalate to external cybersecurity authorities for further analysis and threat intelligence sharing."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_communication_apps.toml b/rules/windows/defense_evasion_masquerading_communication_apps.toml
index ea8c87169c9..27f59a47cb9 100644
--- a/rules/windows/defense_evasion_masquerading_communication_apps.toml
+++ b/rules/windows/defense_evasion_masquerading_communication_apps.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -90,52 +90,6 @@ process where host.os.type == "windows" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Masquerading as Communication Apps
-
-Communication apps are integral to business operations, facilitating collaboration and information exchange. Adversaries may exploit these apps by masquerading malicious processes as legitimate ones, bypassing security measures and deceiving users. The detection rule identifies suspicious instances by checking for unsigned or improperly signed processes, ensuring they match known trusted signatures, thus flagging potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify which specific communication app process triggered the alert, focusing on the `process.name` field.
-- Verify the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to confirm if the process is unsigned or improperly signed.
-- Check the process's parent process using the `process.parent.name` field to determine if it was spawned by a legitimate application or a suspicious one.
-- Investigate the process's command line arguments using the `process.command_line` field to identify any unusual or unexpected parameters.
-- Use Osquery to gather additional information about the process. For example, run the following query to check for any anomalies in the process's file path or hash:
-  ```sql
-  SELECT path, md5, sha256 FROM processes WHERE name = 'slack.exe' OR name = 'WebexHost.exe' OR name = 'Teams.exe' OR name = 'Discord.exe' OR name = 'Rocket.Chat.exe' OR name = 'Mattermost.exe' OR name = 'WhatsApp.exe' OR name = 'Zoom.exe' OR name = 'outlook.exe' OR name = 'thunderbird.exe';
-  ```
-- Examine the network connections established by the process using the `network.connection` field to identify any suspicious or unauthorized external communications.
-- Check the process's file path and compare it with the expected installation directory for the legitimate application to detect any discrepancies.
-- Review recent system logs and events around the time the process was started to identify any related activities or anomalies.
-- Investigate the user account associated with the process using the `user.name` field to determine if the activity aligns with the user's typical behavior.
-- Correlate the findings with other security alerts or incidents to identify any patterns or connections that may indicate a broader attack campaign.
-
-### False positive analysis
-
-- Unsigned or improperly signed legitimate applications: Some legitimate communication apps may occasionally have unsigned or improperly signed updates or versions, leading to false positives. Users should verify the legitimacy of the application version and consider adding exceptions for known safe versions.
-- Custom or internal communication tools: Organizations may use custom-built communication tools that mimic the names of popular apps for compatibility or user familiarity. These should be reviewed and, if deemed safe, added to an allowlist to prevent false positives.
-- Development or testing environments: In environments where communication apps are frequently modified or tested, unsigned versions may trigger alerts. Users should ensure these environments are isolated and consider excluding them from the rule to avoid unnecessary alerts.
-- Third-party integrations or plugins: Some third-party tools or plugins may interact with communication apps, causing them to appear unsigned or improperly signed. Users should verify these integrations and, if trusted, create exceptions for them.
-- Temporary network issues: Occasional network issues might prevent proper signature verification, leading to false positives. Users should monitor for repeated occurrences and investigate network stability if this becomes a frequent issue.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware.
-- Verify the legitimacy of the detected process by checking the file path, hash, and any associated network activity.
-- Terminate any suspicious processes that are confirmed to be malicious or unauthorized.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware.
-- Review system and security logs to trace the origin and timeline of the suspicious activity, focusing on any unauthorized access or changes.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed or if there is potential for widespread impact.
-- Implement or update application allowlists to ensure only trusted and signed applications can execute on the system.
-- Enhance logging policies to capture detailed process execution and code signing events for future investigations.
-- Restore the system from a known good backup if the integrity of the system is compromised and cannot be remediated.
-- Apply security patches and updates to the operating system and all installed applications to mitigate vulnerabilities that could be exploited by similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
index e6c906234f0..c6e35d6317b 100644
--- a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
+++ b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -60,49 +60,6 @@ process where host.os.type == "windows" and event.type == "start" and
 
   not process.executable : ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious WerFault Child Process
-
-WerFault.exe is a Windows Error Reporting tool that handles application crashes. Adversaries may exploit it by manipulating the SilentProcessExit registry key to stealthily execute malicious processes. The detection rule identifies unusual child processes of WerFault.exe, focusing on specific command-line arguments indicative of this abuse, while excluding known legitimate executables, thus highlighting potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the command line arguments of the suspicious WerFault child process to confirm the presence of "-s", "-t", and "-c" flags, which are indicative of SilentProcessExit abuse.
-- Examine the parent process details, specifically WerFault.exe, to verify its legitimacy and check for any anomalies in its execution context.
-- Investigate the process executable path to ensure it is not one of the known legitimate executables excluded in the detection rule, such as "?:\\\\Windows\\\\SysWOW64\\\\Initcrypt.exe" or "?:\\\\Program Files (x86)\\\\Heimdal\\\\Heimdal.Guard.exe".
-- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
-- Check for any file writes or modifications made by the suspicious process to detect potential data exfiltration or tampering activities.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all child processes of WerFault.exe: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'WerFault.exe');`
-- Correlate the process start event with other security logs to identify any related activities or patterns that might indicate a broader attack.
-- Investigate the user account under which the suspicious process was executed to determine if it has been compromised or is being misused.
-- Review recent changes to the registry, particularly the SilentProcessExit key, to identify unauthorized modifications that could facilitate process masquerading.
-- Cross-reference the suspicious process with threat intelligence sources to determine if it matches any known malicious signatures or behaviors.
-
-### False positive analysis
-
-- Known false positives for the Suspicious WerFault Child Process rule may include legitimate software that uses the SilentProcessExit mechanism for valid purposes, such as certain system utilities or third-party applications that are not widely recognized.
-- Users can handle these false positives by creating exceptions for specific executables that are known to be safe and frequently trigger the rule. This can be done by adding these executables to the exclusion list in the detection rule.
-- It is important to verify the legitimacy of the process by checking the digital signature of the executable and ensuring it matches the expected vendor.
-- Regularly review and update the exclusion list to accommodate new legitimate software that may be introduced into the environment, while ensuring that no malicious processes are inadvertently excluded.
-- Consider implementing additional monitoring for excluded processes to ensure they do not exhibit other suspicious behaviors, such as unexpected network connections or file modifications, which could indicate a compromise.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Investigate the suspicious WerFault child process by reviewing the command line arguments, network connections, and file writes to determine the scope and impact of the incident.
-- Terminate any malicious processes identified during the investigation to stop ongoing threats.
-- Review and analyze the SilentProcessExit registry key for unauthorized modifications and revert any changes to their default state.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional threats.
-- Escalate the incident to the security operations team if the investigation reveals a broader compromise or if assistance is needed for further analysis.
-- Implement enhanced logging policies to capture detailed process execution and registry changes for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are correctly set.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and regularly reviewing security policies to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_trusted_directory.toml b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
index ef084008203..34442a07c20 100644
--- a/rules/windows/defense_evasion_masquerading_trusted_directory.toml
+++ b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -75,49 +75,6 @@ process where host.os.type == "windows" and event.type == "start" and
       )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Program Files Directory Masquerading
-
-The Program Files directories in Windows are trusted locations typically reserved for legitimate software installations. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures that whitelist these paths. The detection rule identifies suspicious executions from directories mimicking these trusted paths, excluding known legitimate locations, to flag potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific executable path that triggered the rule, focusing on the `process.executable` field to understand the masquerading attempt.
-- Verify the legitimacy of the directory by checking for any typos or slight variations in the directory name compared to known trusted paths like `C:\\Program Files` or `C:\\Program Files (x86)`.
-- Use Osquery to list all executables in the suspicious directory. Example query: `SELECT path, name, sha256 FROM file WHERE directory LIKE 'C:\\\\%Program%Files%\\\\%' AND NOT directory LIKE 'C:\\\\Program Files%' AND NOT directory LIKE 'C:\\\\Program Files (x86)%';`
-- Investigate the file metadata, such as creation and modification dates, to determine if the executable was recently added or modified, which might indicate malicious activity.
-- Check the file's digital signature to verify its authenticity and identify the publisher. Unsigned or suspiciously signed files may warrant further investigation.
-- Correlate the process start event with other logs, such as user login events, to identify the user account associated with the execution and assess if the activity aligns with their typical behavior.
-- Analyze the parent process of the suspicious executable to understand how it was launched and if it was initiated by a legitimate process or another potentially malicious one.
-- Search for any network connections initiated by the process to external IP addresses, which could indicate data exfiltration or command and control communication.
-- Review any recent changes to the system, such as software installations or updates, that might explain the presence of the executable in the masquerading directory.
-- Consult threat intelligence sources to check if the file hash or any related indicators of compromise (IOCs) are associated with known malware or adversary campaigns.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate software installations or updates that create temporary directories mimicking the Program Files path structure. These can include software development tools or custom applications that use non-standard installation paths.
-- Users can manage these false positives by creating exceptions for specific executable paths that are verified as legitimate. This can be done by adding these paths to the exclusion list in the detection rule.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate software paths that may trigger the rule.
-- Consider implementing a process to verify the legitimacy of any new paths that trigger the rule before adding them to the exclusion list, ensuring that only trusted software is excluded.
-- Collaborate with IT and security teams to maintain an updated inventory of software installations and their expected paths, which can help in quickly identifying false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation to identify the source and scope of the masquerading attempt, focusing on the suspicious directories and executables.
-- Terminate any malicious processes identified during the investigation to prevent further execution.
-- Remove or quarantine any malicious files found in the masquerading directories to eliminate the threat.
-- Review and update allowlisting policies to ensure only legitimate software can execute from trusted directories.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution data, focusing on directory paths and executable names.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by reinstalling affected software from trusted sources and applying the latest security patches.
-- Conduct a security awareness training session for users to recognize and report suspicious activities, emphasizing the importance of directory integrity."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_mshta_beacon.toml b/rules/windows/defense_evasion_mshta_beacon.toml
index ffe230f6755..e36fa0afdba 100644
--- a/rules/windows/defense_evasion_mshta_beacon.toml
+++ b/rules/windows/defense_evasion_mshta_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,51 +47,6 @@ sequence by process.entity_id with maxspan=10m
      not process.args : "ADSelfService_Enroll.hta"]
   [network where host.os.type == "windows" and process.name : "mshta.exe"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Mshta Making Network Connections
-
-Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, bypassing security measures. The detection rule identifies suspicious network activity by Mshta, excluding known benign processes, to flag potential threats. This helps in identifying unauthorized script execution and network connections, indicating possible malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of Mshta.exe making outbound network connections and verify the process entity ID for correlation.
-- Check the process start event to gather additional context, such as the exact command line arguments used with Mshta.exe, to identify potential malicious scripts.
-- Investigate the parent process of Mshta.exe to determine if it is a known benign process or if it could be part of a suspicious chain of execution.
-- Examine the network connections made by Mshta.exe, including destination IP addresses and ports, to identify any known malicious or suspicious endpoints.
-- Utilize Osquery to gather more information about the Mshta.exe process. For example, run the following query to list all network connections made by Mshta.exe:
-  ```sql
-  SELECT pid, local_address, local_port, remote_address, remote_port, state FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'mshta.exe');
-  ```
-- Cross-reference the network activity with threat intelligence sources to determine if the IP addresses or domains are associated with known threats.
-- Analyze the timeline of events to see if there are any other suspicious activities occurring around the same time as the Mshta.exe execution.
-- Check for any other alerts or logs related to the same process entity ID to identify if this is part of a larger attack pattern.
-- Investigate the user account under which Mshta.exe was executed to determine if it has been compromised or is being used for unauthorized activities.
-- Review system logs and other security tools for any additional indicators of compromise that may correlate with the Mshta.exe activity.
-
-### False positive analysis
-
-- Known false positives for the Mshta Making Network Connections rule include legitimate applications that use mshta.exe for valid purposes, such as software updates or internal scripts executed by IT departments. These can trigger alerts if not properly excluded.
-- Users can manage these false positives by creating exceptions for specific parent processes or command-line arguments that are known to be safe. For instance, if a particular internal application frequently uses mshta.exe, its parent process can be added to the exclusion list.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate use cases for mshta.exe, minimizing unnecessary alerts while maintaining security.
-- Consider implementing a monitoring period to observe mshta.exe activity and identify patterns that are consistently benign, which can then be safely excluded from triggering alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the execution of mshta.exe and any associated scripts or payloads.
-- Terminate any malicious processes associated with mshta.exe and remove any unauthorized scripts or files from the system.
-- Review and analyze logs from security information and event management (SIEM) systems to trace the attack vector and identify any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of known malicious indicators related to mshta.exe abuse.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as application whitelisting and user education on phishing threats.
-- Document the incident and response actions taken, updating incident response plans and playbooks to improve readiness for future incidents involving similar tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
index 1dd30da230c..3ec331c277f 100644
--- a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
+++ b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -48,49 +48,6 @@ sequence by process.entity_id with maxspan=1m
  not (process.name : ("rundll32.exe", "regsvr32.exe") and process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*"))]
 [any where host.os.type == "windows" and event.category in ("network", "dns") and process.name != null]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 MsiExec Service Child Process With Network Connection
-
-MsiExec is a Windows utility for installing, modifying, and removing applications. Adversaries exploit it to execute malicious payloads by spawning child processes that initiate network connections, often bypassing security controls. The detection rule identifies suspicious child processes of MsiExec that engage in network or DNS activities, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific process entity ID and timestamp of the suspicious activity.
-- Verify the parent process by checking if the parent process name is "msiexec.exe" and confirm the presence of the "/v" argument, which may indicate verbose logging or specific installation actions.
-- Examine the child process executable path to ensure it does not match known legitimate paths such as "?:\\\\Windows\\\\System32\\\\msiexec.exe" or "?:\\\\Program Files\\\\*.exe".
-- Investigate the child process name and arguments to identify any unusual or unexpected executables or scripts being executed.
-- Check for any network or DNS activity associated with the child process to identify potential command and control communication or data exfiltration attempts.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE pid = <child_process_id>;` to retrieve detailed information about the process.
-- Analyze the process creation time and compare it with known legitimate software installation or update schedules to rule out false positives.
-- Investigate the user account under which the process was executed to determine if it aligns with expected user behavior or if it indicates potential compromise.
-- Review historical data for similar alerts or patterns involving the same process or user to identify any recurring suspicious activity.
-- Correlate the findings with threat intelligence sources to determine if the activity matches known adversary techniques or campaigns.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule if they involve network connections, as some installers use MsiExec to download additional components or updates from the internet.
-- System administrators or IT personnel performing routine software maintenance or deployment might inadvertently cause alerts when using MsiExec for legitimate purposes.
-- Some enterprise environments use custom scripts or automation tools that leverage MsiExec for software management, which could be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for known and trusted software installations by excluding specific process names or paths that are frequently involved in legitimate activities.
-- Regularly review and update the exclusion list to ensure it reflects the current software landscape and organizational practices, minimizing unnecessary alerts while maintaining security vigilance.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation of the child process spawned by MsiExec to determine if it is part of a legitimate installation or a malicious payload.
-- Review network logs and DNS queries associated with the suspicious process to identify any external connections or data exfiltration attempts.
-- If malicious activity is confirmed, remove any unauthorized software or malware from the system using trusted antivirus or endpoint detection and response (EDR) tools.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process creation, network activity, and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate and detect similar threats in real-time.
-- Apply system hardening measures, such as restricting the use of MsiExec to authorized users and applications, and implementing application whitelisting.
-- Educate users on recognizing phishing attempts and the risks of executing unknown installers to reduce the likelihood of initial access through social engineering."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_msxsl_network.toml b/rules/windows/defense_evasion_msxsl_network.toml
index 4a0ec99a494..513740d35b9 100644
--- a/rules/windows/defense_evasion_msxsl_network.toml
+++ b/rules/windows/defense_evasion_msxsl_network.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,48 +46,6 @@ sequence by process.entity_id
        "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")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Connection via MsXsl
-
-MsXsl.exe is a legitimate Windows utility used to transform XML data using XSLT stylesheets. Adversaries exploit it to execute malicious scripts, bypassing security measures. The detection rule identifies suspicious network activity by MsXsl.exe, focusing on connections to non-local IPs, which may indicate unauthorized data exfiltration or command-and-control communication.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is msxsl.exe and the event type is "start" to ensure the alert is valid.
-- Check the destination IP address in the alert to determine if it falls outside the specified non-local IP ranges, indicating a potential external connection.
-- Investigate the process entity ID to trace the parent process and identify how msxsl.exe was executed, which may provide insight into the initial vector of execution.
-- Use Osquery to gather additional context on the msxsl.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'msxsl.exe';` to retrieve details like process path, command line arguments, and parent process ID.
-- Examine the command line arguments used with msxsl.exe to identify any suspicious or unexpected scripts or files being processed.
-- Correlate the network activity with other logs to identify any additional suspicious connections or data transfers involving the same destination IP.
-- Review recent system changes or user activity logs to identify any anomalies or unauthorized actions that coincide with the msxsl.exe execution.
-- Check for any other alerts or indicators of compromise on the host that may suggest a broader attack or compromise.
-- Analyze historical data to determine if msxsl.exe has been used previously on the host and if similar network connections were made.
-- Consult threat intelligence sources to see if the destination IP or any related indicators are associated with known malicious activity or threat actors.
-
-### False positive analysis
-
-- Legitimate use of MsXsl.exe by IT administrators or software developers for XML data transformation tasks may trigger the rule. Users can handle this by creating exceptions for known and verified internal IP addresses or specific user accounts that regularly perform these tasks.
-- Automated scripts or applications that utilize MsXsl.exe for legitimate data processing or integration purposes might be flagged. To manage this, users can whitelist specific processes or applications that are known to use MsXsl.exe in a non-malicious manner.
-- Network monitoring tools or security software that leverage MsXsl.exe for legitimate network diagnostics or reporting could cause false positives. Users should identify these tools and exclude their network activities from the rule.
-- In environments where MsXsl.exe is part of a standard software deployment or configuration management process, its network activity might be benign. Users can exclude these processes by verifying the source and destination of the network connections and ensuring they align with expected operational patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify any additional compromised systems by reviewing logs and network traffic for similar suspicious activity involving msxsl.exe.
-- Terminate any malicious processes associated with msxsl.exe and remove any unauthorized scripts or files from the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution and network connection data, focusing on msxsl.exe and other potential living-off-the-land binaries (LOLBins).
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar tactics and techniques.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are hardened.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on the risks associated with executing unknown scripts and the importance of reporting suspicious activity.
-- Monitor for any recurrence of the activity and adjust security measures as necessary to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
index b99029c8ced..6cdf87d08fc 100644
--- a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
+++ b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -73,52 +73,6 @@ sequence by host.id, user.id with maxspan=3m
               "?:\\Windows\\SysWOW64\\WerFault.exe")
  ] by process.parent.Ext.real.pid
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Parent Process PID Spoofing
-
-Parent Process ID (PPID) spoofing involves manipulating the PPID of a process to mislead security tools and analysts about the true origin of a process. Adversaries exploit this to evade detection and escalate privileges. The detection rule identifies suspicious processes by monitoring for mismatches between expected and actual PPIDs, focusing on processes with non-system integrity levels and unverified signatures, thus highlighting potential spoofing activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and parent process involved, focusing on `process.pid` and `process.parent.Ext.real.pid` fields.
-- Verify the integrity level of the process using the `process.Ext.token.integrity_level_name` field to determine if it is non-system, which may indicate suspicious activity.
-- Check the `process.pe.original_file_name` and `process.executable` fields to identify if the process is a known application or if it is running from an unusual location.
-- Investigate the code signature status using the `process.code_signature.exists` and `process.code_signature.status` fields to determine if the executable is unsigned or has a bad digest.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list processes with their parent process IDs and names:
-  ```sql
-  SELECT pid, name, parent, path FROM processes WHERE pid = <triggered_process_pid>;
-  ```
-- Cross-reference the parent process ID (`process.parent.Ext.real.pid`) with known legitimate parent processes to identify potential anomalies.
-- Examine the process creation time and compare it with the parent process's start time to identify any discrepancies that might suggest spoofing.
-- Investigate the user context (`user.id`) under which the process is running to determine if it aligns with expected behavior for that user.
-- Review historical data for the host (`host.id`) to identify any patterns or previous instances of similar suspicious activity.
-- Correlate the findings with other security events or logs from the same timeframe to build a comprehensive picture of the potential threat.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate software updates or installations temporarily alter the parent process ID, such as during system updates or software patching. These activities can mimic the behavior of PPID spoofing but are benign.
-- Certain administrative tools or scripts that automate tasks might also trigger the rule if they launch processes with altered PPIDs as part of their normal operation.
-- Users can manage these false positives by creating exceptions for specific processes or directories known to be safe, such as trusted software update paths or administrative scripts.
-- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempted, maintaining a balance between security and operational efficiency.
-- Consider implementing additional context checks, such as verifying the digital signature of the process or cross-referencing with known safe hash values, to further reduce false positives while maintaining robust detection capabilities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Use endpoint detection and response (EDR) tools to gather detailed information about the suspicious process, including its parent process and any child processes it may have spawned.
-- Terminate the malicious process and any associated processes that are identified as part of the attack chain.
-- Conduct a thorough investigation to determine the initial access vector and identify any other systems that may be compromised.
-- Review and analyze security logs to trace the origin of the spoofed process and understand the scope of the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Implement or enhance logging policies to ensure comprehensive monitoring of process creation events and parent-child process relationships.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings into security tools to improve detection capabilities for similar tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan to ensure no remnants of the attack remain.
-- Harden the system by implementing least privilege access controls, enabling application whitelisting, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
index 1d06b158032..e58222e18b6 100644
--- a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
+++ b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,50 +50,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\*\\LocalAccountTokenFilterPolicy"
   ) and registry.data.strings : ("1", "0x00000001")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Local Account TokenFilter Policy Disabled
-
-The Local Account TokenFilter Policy controls how local administrator accounts are treated during remote connections on Windows systems. When enabled, it grants full administrative privileges, potentially bypassing User Account Control (UAC). Adversaries exploit this by modifying the registry to escalate privileges remotely. The detection rule monitors registry changes to identify unauthorized modifications, signaling potential abuse of administrative access.
-
-### Possible investigation steps
-
-- Verify the alert by checking the registry path and value to confirm if the LocalAccountTokenFilterPolicy has been modified. Use the query fields `registry.path` and `registry.data.strings` to ensure the change is unauthorized.
-- Review the event logs around the time of the registry change to identify any associated user accounts or processes that may have initiated the modification.
-- Investigate the source of the remote connection by examining network logs to identify any unusual or unauthorized access attempts from external IP addresses.
-- Check for any recent changes in user account privileges, especially for local administrator accounts, to determine if there have been unauthorized privilege escalations.
-- Use Osquery to gather more information about the system state and user activities. For example, run the following Osquery command to check for recent registry changes: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\%\\\\LocalAccountTokenFilterPolicy';`
-- Analyze the system's security logs for any signs of suspicious activity or patterns that coincide with the registry modification, such as failed login attempts or unusual process executions.
-- Correlate the alert with other security events or alerts in the same timeframe to identify potential indicators of a broader attack or compromise.
-- Review the system's patch and update history to ensure that all security patches have been applied, as unpatched systems may be more vulnerable to exploitation.
-- Investigate any recent software installations or updates that may have inadvertently or maliciously altered the registry settings.
-- Consult threat intelligence sources to determine if there are any known exploits or attack campaigns targeting the LocalAccountTokenFilterPolicy, which could provide additional context for the alert.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts may modify the LocalAccountTokenFilterPolicy registry setting as part of routine system management or configuration tasks, leading to false positives.
-- System administrators might intentionally enable this policy to facilitate remote management tasks, especially in environments where UAC prompts are disruptive to workflow.
-- Security software or compliance tools could alter this registry setting during audits or system checks, triggering the detection rule.
-- To manage these false positives, users can create exceptions for known administrative tools or scripts by excluding specific processes or user accounts from the detection rule.
-- Regularly review and update the list of exceptions to ensure that only trusted activities are excluded, maintaining a balance between security and operational efficiency.
-- Implement logging and alerting mechanisms to monitor the frequency and context of these registry changes, helping to distinguish between benign and potentially malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the registry change by checking the LocalAccountTokenFilterPolicy value and confirm if it was set to 1 without authorization.
-- Conduct a thorough investigation to identify any unauthorized users or processes that may have modified the registry setting.
-- Review system and security logs to trace the origin of the change and identify any other suspicious activities or related events.
-- Restore the registry setting to its default state by removing the LocalAccountTokenFilterPolicy entry or setting it to 0 if necessary.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to monitor registry changes and remote access attempts, ensuring that all critical changes are logged and reviewed regularly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
-- Apply security patches and updates to the affected system and ensure that all systems are configured with the principle of least privilege to minimize potential attack vectors.
-- Conduct a post-incident review to assess the effectiveness of the response and update security policies and procedures to prevent recurrence, including user training on security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_posh_obfuscation.toml b/rules/windows/defense_evasion_posh_obfuscation.toml
index 4c208408a9c..a526da2b50a 100644
--- a/rules/windows/defense_evasion_posh_obfuscation.toml
+++ b/rules/windows/defense_evasion_posh_obfuscation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/03"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,49 +66,6 @@ event.category:process and host.os.type:windows and
     ("rahc" or "ekovin" or "gnirts" or "ecnereferpesobrev" or "ecalper" or "cepsmoc" or "dillehs")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential PowerShell Obfuscated Script
-
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating scripts to evade security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts that attempt to bypass security defenses.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific obfuscation pattern triggered the detection, focusing on the `powershell.file.script_block_text` field.
-- Examine the full script block text associated with the alert to identify any additional obfuscation techniques or suspicious commands not covered by the detection rule.
-- Check the `event.category` and `host.os.type` fields to confirm the context of the alert, ensuring it pertains to a Windows process execution.
-- Investigate the process tree to identify the parent process of the PowerShell script execution, which may provide insights into how the script was launched.
-- Use Osquery to gather more information about the process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND pid = <PID>;` to retrieve details about the PowerShell process, including its command line arguments and parent process.
-- Analyze the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised.
-- Review recent login events and user activity logs for the account in question to identify any anomalies or unauthorized access attempts.
-- Check for any network connections initiated by the PowerShell process to external IP addresses, which could indicate data exfiltration or command-and-control communication.
-- Search for any file modifications or new file creations on the host around the time of the alert to identify potential payloads or artifacts left by the script.
-- Correlate the alert with other security events or alerts from the same host or user account to identify patterns or a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative scripts: PowerShell scripts used by IT administrators for legitimate purposes may contain obfuscation techniques to protect sensitive information or to streamline complex operations. Users should review these scripts to ensure they are not flagged as malicious.
-- Automated deployment tools: Some deployment or configuration management tools may use obfuscation to protect proprietary code or to ensure compatibility across different environments. Users can create exceptions for these tools if they are verified as safe.
-- Security software: Certain security solutions may use obfuscation in their scripts to prevent tampering or reverse engineering. Users should verify the source and purpose of these scripts before excluding them.
-- Development and testing environments: Developers may use obfuscation techniques during the development or testing phases to simulate real-world scenarios. Users should ensure these scripts are confined to controlled environments and are not mistakenly flagged in production.
-- To manage false positives, users can create exceptions for known safe scripts by whitelisting specific script signatures or paths. Regularly updating the list of exceptions based on verified activities can help maintain a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
-- Conduct a thorough investigation of the PowerShell script to determine the extent of obfuscation and potential malicious intent.
-- Utilize endpoint detection and response (EDR) tools to analyze the behavior of the script and identify any additional indicators of compromise (IOCs).
-- Remove or quarantine any identified malicious scripts or files from the system.
-- Review and update PowerShell execution policies to restrict the execution of unauthorized scripts.
-- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging for PowerShell activities, including script block logging and module logging, to improve future detection capabilities.
-- Integrate threat intelligence feeds to correlate detected patterns with known threat actors and techniques.
-- Restore the system from a known good backup to ensure the removal of any persistent threats.
-- Apply system hardening measures, such as disabling unnecessary PowerShell features and enforcing the use of AMSI, to reduce the risk of future obfuscation attempts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
index 9f8a77bcbdf..01bf525400c 100644
--- a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
+++ b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/31"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,51 +52,6 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.pe.original_file_name == "msdt.exe" and not process.executable : ("?:\\Windows\\system32\\msdt.exe", "?:\\Windows\\SysWOW64\\msdt.exe"))
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Microsoft Diagnostics Wizard Execution
-
-The Microsoft Diagnostics Troubleshooting Wizard (MSDT) is a legitimate tool used for diagnosing and resolving issues within Windows environments. However, adversaries can exploit MSDT to execute malicious commands by manipulating its process arguments. This detection rule identifies such abuse by monitoring for unusual execution patterns, such as atypical file paths, unexpected parent processes, and altered executable names, which may indicate an attempt to proxy malicious activities through MSDT.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious MSDT execution, focusing on the `process.name`, `process.args`, and `process.parent.name` fields to understand the context of the execution.
-- Examine the `process.args` field for any unusual or unexpected arguments, such as "IT_RebrowseForFile=*", "ms-msdt:/id", or "*FromBase64*", which may indicate malicious intent.
-- Check the `process.parent.name` field to identify the parent process that initiated the MSDT execution. Look for unusual parent processes that are not typically associated with MSDT, such as `cmd.exe`, `powershell.exe`, or `rundll32.exe`.
-- Investigate the `process.executable` path to ensure it matches the expected locations for MSDT, such as "?:\\\\Windows\\\\system32\\\\msdt.exe" or "?:\\\\Windows\\\\SysWOW64\\\\msdt.exe". Any deviation might suggest tampering or misuse.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with the name "msdt.exe" and their parent processes:
-  ```sql
-  SELECT pid, name, path, parent, cmdline FROM processes WHERE name = 'msdt.exe';
-  ```
-- Analyze the `process.pe.original_file_name` field to verify that the executable is indeed "msdt.exe". If the original file name does not match, it could indicate a masquerading attempt.
-- Correlate the suspicious MSDT execution with other logs or alerts from the same host to identify any related malicious activities or patterns.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Check for any recent file modifications or creations in directories specified in the `process.args`, such as "?:\\\\Users\\\\Public\\\\*" or "?:\\\\Windows\\\\Temp\\\\*", which could indicate payload delivery or staging.
-- Review historical data for similar MSDT execution patterns on the host to determine if this is an isolated incident or part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate troubleshooting activities: Users or IT administrators may legitimately use MSDT for diagnosing system issues, which can trigger the rule. To manage this, consider creating exceptions for known IT maintenance periods or specific user accounts frequently involved in troubleshooting.
-- Automated system diagnostics: Some automated scripts or system management tools might invoke MSDT as part of routine checks. Identify these tools and exclude their execution patterns from the rule to prevent unnecessary alerts.
-- Custom diagnostic tools: Organizations may develop custom diagnostic tools that leverage MSDT, leading to false positives. Review and whitelist these tools by their specific process arguments or parent processes.
-- Software updates or installations: Certain software installations or updates might use MSDT for compatibility checks. Monitor and exclude these processes by correlating them with known update schedules or software deployment activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation of the process tree to identify any additional malicious processes or scripts that may have been executed alongside MSDT.
-- Review the system's event logs and security logs to gather more context on the suspicious MSDT execution, including any associated user accounts and network connections.
-- Terminate any malicious processes identified during the investigation and remove any associated files or scripts from the system.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if sensitive data may have been accessed.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that the system's antivirus and endpoint protection software are up to date.
-- Implement enhanced logging policies to capture detailed process execution data and network activity, which can aid in future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate suspicious activities across the network.
-- Conduct a post-incident review to identify any gaps in security controls and update the organization's incident response plan accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and features, to reduce the attack surface and prevent similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
index e6f89915cf7..e42b52ac964 100644
--- a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
+++ b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,50 +55,6 @@ registry where host.os.type == "windows" and event.type == "change" and
   (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 DNS Global Query Block List Modified or Disabled
-
-The DNS Global Query Block List (GQBL) is a security feature that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling exploitation for privilege escalation. The detection rule identifies such changes by monitoring registry modifications, signaling potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry value that triggered the alert, focusing on `registry.value` and `registry.data.strings` fields.
-- Verify the timestamp of the registry change event to determine when the modification occurred.
-- Identify the user account associated with the registry change event to assess if the account has elevated privileges, such as DNSAdmins.
-- Check the host's recent login history to see if there were any unusual or unauthorized access attempts around the time of the registry modification.
-- Use Osquery to list all current registry settings related to the DNS Global Query Block List on the affected host. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\CurrentControlSet\\\\Services\\\\DNS\\\\Parameters\\\\%';`
-- Investigate any recent changes to user group memberships, especially those related to DNSAdmins, to identify potential privilege escalation.
-- Examine the system's event logs for any other suspicious activities or errors that coincide with the registry change event.
-- Cross-reference the affected host with other security alerts or incidents to determine if it is part of a broader attack pattern.
-- Analyze network traffic logs for any unusual DNS queries or connections from the affected host, particularly those involving WPAD.
-- Consult threat intelligence sources to check for any known campaigns or adversaries that exploit changes to the DNS Global Query Block List.
-
-### False positive analysis
-
-- Changes to the DNS Global Query Block List may occur during legitimate administrative tasks, such as network configuration updates or security policy adjustments, leading to false positives.
-- Organizations using custom DNS configurations might intentionally modify the GQBL to accommodate specific network requirements, which could trigger the detection rule.
-- Security software or network management tools that automatically adjust DNS settings for optimization or compliance purposes might inadvertently alter the GQBL, resulting in false alerts.
-- To manage these false positives, users can create exceptions for known and approved administrative activities by documenting and excluding specific registry changes associated with these tasks.
-- Implementing a whitelist of trusted applications or processes that are allowed to modify the GQBL can help reduce unnecessary alerts while maintaining security oversight.
-- Regularly reviewing and updating the list of exceptions based on changes in network policies or configurations can ensure that only non-threatening behaviors are excluded from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Verify the current state of the DNS Global Query Block List by checking the registry settings to confirm unauthorized changes.
-- Conduct a thorough investigation to identify any unauthorized users or processes that modified the GQBL settings, focusing on accounts with elevated privileges like DNSAdmins.
-- Review system and security logs to trace the origin of the changes and identify any potential indicators of compromise or related suspicious activities.
-- Restore the DNS Global Query Block List to its default settings, ensuring that entries like WPAD are included to prevent spoofing attacks.
-- Apply patches and updates to the operating system and DNS services to mitigate known vulnerabilities that could be exploited.
-- Implement enhanced logging policies to capture detailed registry changes and monitor for any future unauthorized modifications.
-- Integrate security solutions such as SIEM to correlate events and provide real-time alerts for similar incidents.
-- Conduct a security audit of privileged accounts and enforce the principle of least privilege to minimize the risk of future exploitation.
-- Educate and train IT staff on recognizing and responding to DNS-related threats, leveraging MITRE ATT&CK framework for threat context and defense strategies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_root_dir_ads_creation.toml b/rules/windows/defense_evasion_root_dir_ads_creation.toml
index 3f567c11007..3da978e81f0 100644
--- a/rules/windows/defense_evasion_root_dir_ads_creation.toml
+++ b/rules/windows/defense_evasion_root_dir_ads_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,49 +50,6 @@ any where host.os.type == "windows" and event.category in ("file", "process") an
     (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Alternate Data Stream Creation/Execution at Volume Root Directory
-
-Alternate Data Streams (ADS) in Windows allow files to contain multiple streams of data, which can be used to hide information. Adversaries exploit ADS at the volume root to conceal malicious tools, as these streams are not visible through standard file utilities. The detection rule identifies suspicious ADS activity by monitoring file creation and process execution patterns at the root directory, flagging potential attempts to evade defenses.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path or process executable that triggered the alert, focusing on the `file.path` and `process.executable` fields.
-- Verify the legitimacy of the file or process by checking its digital signature and comparing it against known good software lists.
-- Use Osquery to list all alternate data streams on the system with a query like: `SELECT path, name FROM file WHERE path LIKE 'C:\\\\%' AND name LIKE '%:%';` to identify any suspicious streams.
-- Investigate the parent process of the suspicious executable using the `process.parent` field to determine if it was spawned by a legitimate application or a known malicious process.
-- Check the file creation time and compare it with recent user activity logs to identify any correlation with user actions or scheduled tasks.
-- Examine the file or process hash against threat intelligence databases to see if it matches known malware signatures.
-- Review recent system logs for any other unusual activities around the time of the alert, such as unexpected network connections or privilege escalations.
-- Analyze the user account associated with the process or file creation to determine if it has been compromised or is exhibiting unusual behavior.
-- Investigate the system for any other indicators of compromise, such as unauthorized registry changes or new services, that might suggest a broader attack.
-- Consult with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather additional context and corroborate findings.
-
-### False positive analysis
-
-- Legitimate software installations or updates may create Alternate Data Streams at the volume root directory as part of their normal operations, which can trigger false positives. Users can handle these by identifying the specific software responsible and creating exceptions for these known processes or file paths.
-- System maintenance tools or backup software might use ADS for storing metadata or additional information, leading to false positives. To manage this, users should monitor and document regular maintenance activities and exclude these from the detection rule.
-- Some antivirus or security tools may utilize ADS for storing signatures or logs, which could be misinterpreted as malicious activity. Users should verify the source of the ADS and whitelist these tools if they are confirmed to be legitimate.
-- Developers or IT administrators might use ADS for testing or configuration purposes, which can be mistaken for suspicious activity. Users should ensure that these activities are documented and create exceptions for known development or administrative tasks.
-- Certain file system operations or scripts executed by system administrators might inadvertently create ADS, resulting in false positives. Users should review these operations and exclude them from monitoring if they are part of routine administrative tasks.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
-- Use forensic tools to capture a memory dump and collect relevant logs for further analysis of the suspicious ADS activity.
-- Identify and terminate any malicious processes associated with the ADS by analyzing process execution patterns and correlating with known threat indicators.
-- Remove the identified ADS and any associated malicious files from the system to eliminate the immediate threat.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to ensure no other threats are present.
-- Review and enhance logging policies to ensure comprehensive monitoring of file and process activities, particularly at the volume root directory.
-- Implement additional security measures such as application whitelisting and endpoint detection and response (EDR) solutions to detect and prevent future ADS exploitation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign.
-- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied before reconnecting to the network.
-- Educate users on the risks associated with ADS and provide training on recognizing and reporting suspicious activities to enhance overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sc_sdset.toml b/rules/windows/defense_evasion_sc_sdset.toml
index 19e99d6c170..c5be261625f 100644
--- a/rules/windows/defense_evasion_sc_sdset.toml
+++ b/rules/windows/defense_evasion_sc_sdset.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 
 [rule]
 author = ["Elastic"]
@@ -47,48 +47,6 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "sdset" and process.args : "*D;*" and
   process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Service DACL Modification via sc.exe
-
-Service Control Manager (SCM) in Windows manages service configurations, including their Discretionary Access Control Lists (DACLs). Adversaries may exploit `sc.exe` to alter DACLs, restricting access to services, making them unmanageable or hidden. The detection rule identifies such modifications by monitoring `sc.exe` executions with specific arguments indicative of DACL changes, signaling potential defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `sc.exe` execution with the `sdset` argument, which indicates a potential DACL modification attempt.
-- Examine the `process.args` field to identify the specific DACL string used, focusing on patterns like `*D;*` and permissions such as `*;IU*`, `*;SU*`, `*;BA*`, `*;SY*`, and `*;WD*` to understand the intended access changes.
-- Check the `process.name` and `process.pe.original_file_name` fields to ensure the process is indeed `sc.exe` and not a masquerading executable.
-- Investigate the parent process of `sc.exe` to determine if it was launched by a legitimate application or a suspicious process.
-- Correlate the event with user activity by examining the user context under which `sc.exe` was executed to identify potential unauthorized access.
-- Use Osquery to list all services and their current DACLs to identify any discrepancies or unauthorized changes. Example query: `SELECT name, service_type, start_type, status, path, service_dacl FROM services WHERE path LIKE '%sc.exe%';`
-- Review recent system logs and security events around the time of the alert to identify any related activities or anomalies.
-- Investigate any network connections or file modifications made by `sc.exe` during the time of the alert to uncover potential lateral movement or data exfiltration attempts.
-- Check for any other alerts or indicators of compromise on the host that may suggest a broader attack campaign.
-- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the potential security incident.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use `sc.exe` to modify service DACLs for valid reasons, such as configuring service permissions during system setup or maintenance. These actions can trigger the detection rule but are not malicious.
-- Automated scripts and software: Some enterprise management tools or scripts might use `sc.exe` to adjust service permissions as part of their normal operation, leading to false positives.
-- Testing environments: In testing or development environments, developers might frequently modify service DACLs to test application behavior, which can be mistaken for suspicious activity.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that regularly perform these actions. This can be done by excluding certain user accounts or process hashes from the detection rule, ensuring that only unexpected or unauthorized modifications trigger alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
-- Review the security logs to identify the source and scope of the DACL modification, focusing on the user account and process that executed `sc.exe`.
-- Verify the integrity of the service's DACLs and restore them to their default or intended state using backup configurations or system baselines.
-- Conduct a thorough investigation to determine if any other services or system components have been similarly modified or compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team if unauthorized access or malicious intent is confirmed.
-- Implement enhanced logging policies to capture detailed information on service configuration changes, including command-line arguments and user context.
-- Integrate with a Security Information and Event Management (SIEM) system to correlate events and detect similar patterns of behavior across the network.
-- Apply security patches and updates to the operating system and critical applications to mitigate known vulnerabilities.
-- Educate users and administrators on the risks associated with improper DACL configurations and the importance of maintaining secure service settings.
-- Consider deploying endpoint detection and response (EDR) solutions to monitor and alert on suspicious activities related to service management and DACL modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sccm_scnotification_dll.toml b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
index 8aa0bda3a9d..8abfbc3726a 100644
--- a/rules/windows/defense_evasion_sccm_scnotification_dll.toml
+++ b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,52 +36,6 @@ query = '''
 library where host.os.type == "windows" and process.name : "SCNotification.exe" and
   (dll.Ext.relative_file_creation_time < 86400 or dll.Ext.relative_file_name_modify_time <= 500) and dll.code_signature.status != "trusted"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Windows Session Hijacking via CcmExec
-
-CcmExec, part of Microsoft's System Center Configuration Manager, manages client operations. Adversaries may exploit it by loading malicious DLLs into processes like SCNotification.exe to hijack user sessions. The detection rule identifies suspicious DLL activity by checking for recent file modifications and untrusted signatures, signaling potential session hijacking attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is 'SCNotification.exe' and verify the DLL involved has an untrusted code signature.
-- Check the 'dll.Ext.relative_file_creation_time' and 'dll.Ext.relative_file_name_modify_time' fields to determine the recency of the DLL file's creation or modification, indicating potential tampering.
-- Investigate the origin of the untrusted DLL by examining its file path and comparing it against known legitimate paths for SCNotification.exe dependencies.
-- Use Osquery to list all DLLs loaded by SCNotification.exe to identify any other suspicious or untrusted modules:
-  ```sql
-  SELECT path, pid, name FROM processes JOIN process_open_sockets USING (pid) WHERE name = 'SCNotification.exe';
-  ```
-- Cross-reference the untrusted DLL's hash against threat intelligence databases to check for known malicious signatures.
-- Analyze the parent process of SCNotification.exe to determine if it was spawned by a legitimate process or if there are signs of compromise.
-- Review recent system logs and security events around the time of the DLL's creation or modification for any anomalies or unauthorized access attempts.
-- Investigate user accounts active on the system at the time of the alert to identify any unauthorized or suspicious sessions.
-- Examine network connections established by SCNotification.exe to detect any unusual outbound traffic that could indicate data exfiltration or command-and-control communication.
-- Correlate this alert with other security events or alerts in the environment to identify potential patterns or coordinated attack activities.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they involve DLLs with recent file modifications or untrusted signatures. Users should verify the source of the update and consider excluding these specific DLLs if they are confirmed to be safe.
-- Custom or in-house applications that are not signed by a trusted certificate authority might be flagged. Users can create exceptions for these applications by adding their signatures to a trusted list after confirming their legitimacy.
-- Security or system management tools that frequently update their components might cause false positives. Users should monitor these tools and exclude their DLLs from the rule if they are verified as non-malicious.
-- Development environments where DLLs are frequently compiled and modified can also trigger the rule. Developers should ensure that their development directories are excluded from monitoring to prevent unnecessary alerts.
-- In environments with strict security policies, some legitimate administrative actions might be flagged. Users should document these actions and adjust the rule to exclude known administrative processes that are part of regular operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the untrusted DLL and any other potentially malicious files or processes on the system.
-- Review recent user activity and system logs to determine if any unauthorized access or actions have occurred.
-- Remove the malicious DLL and any associated files from the system, ensuring that all traces of the threat are eliminated.
-- Restore the system from a known good backup if available, ensuring that the backup is free from any compromise.
-- Update all system and application software to the latest versions to patch any vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed information on DLL loads and process execution for future investigations.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to improve detection and response capabilities.
-- Escalate the incident to the security team or relevant authorities if the investigation reveals a broader threat or compliance implications.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and stricter access controls, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
index d913233cad9..7d5d97ca9d5 100644
--- a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
+++ b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,50 +45,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt"
   ) and registry.data.strings : ("1", "0x00000001")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Scheduled Tasks AT Command Enabled
-
-The AT command, a legacy tool in Windows, schedules tasks to run at specified times. Despite its deprecation in newer Windows versions, it remains for compatibility, posing a security risk. Attackers exploit this by enabling it via registry changes to maintain persistence or move laterally. The detection rule monitors specific registry paths for changes, identifying when the AT command is enabled, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path involved matches one of the specified paths: `HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt`, `\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt`, or `MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt`.
-- Verify the registry data value change to ensure it was set to "1" or "0x00000001", indicating the AT command was enabled.
-- Check the event logs for the specific host to identify any other registry changes or suspicious activities around the same time as the alert.
-- Investigate the user account associated with the registry change event to determine if it is a legitimate user or potentially compromised.
-- Use Osquery to list all scheduled tasks on the host to identify any unusual or unauthorized tasks. Example query: `SELECT * FROM scheduled_tasks WHERE hidden = 0;`
-- Examine the system's security logs for any recent login attempts or anomalies that could indicate unauthorized access.
-- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
-- Check for any recent software installations or updates that might have inadvertently enabled the AT command.
-- Investigate network logs for any unusual outbound connections from the host that could suggest lateral movement or data exfiltration.
-- Review the host's patch and update status to ensure it is up-to-date, as attackers often exploit outdated systems.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts may modify the registry to enable the AT command for backward compatibility or specific operational needs, leading to false positives.
-- System administrators might enable the AT command temporarily for testing or maintenance purposes, which could trigger the detection rule.
-- Some legacy applications may require the AT command to function correctly, resulting in registry changes that are benign but flagged by the rule.
-- To manage these false positives, users can create exceptions for known and trusted administrative activities by excluding specific user accounts or processes from the detection rule.
-- Implementing a whitelist of approved applications or scripts that are allowed to modify the registry path can help reduce unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded, maintaining the balance between security and operational needs.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
-- Verify the registry change by checking the specified registry path to confirm if the AT command has been enabled.
-- Conduct a thorough investigation to identify any unauthorized scheduled tasks created using the AT command and disable or remove them.
-- Review system logs and security events to identify any suspicious activities or patterns that coincide with the registry change.
-- Restore the registry setting to its original state by disabling the AT command if it was enabled without authorization.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to monitor registry changes and scheduled task creations, ensuring that future unauthorized changes are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Apply system hardening measures, such as disabling legacy tools like the AT command if not required for business operations, to reduce the attack surface.
-- Educate users and administrators on the risks associated with legacy tools and the importance of maintaining updated security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_script_via_html_app.toml b/rules/windows/defense_evasion_script_via_html_app.toml
index b31daa2c7d0..12b49fd1160 100644
--- a/rules/windows/defense_evasion_script_via_html_app.toml
+++ b/rules/windows/defense_evasion_script_via_html_app.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -79,52 +79,6 @@ process where host.os.type == "windows" and event.type == "start" and
       process.args : ("?:\\Users\\*\\Temp\\7z*", "?:\\Users\\*\\Temp\\Rar$*", "?:\\Users\\*\\Temp\\Temp?_*", "?:\\Users\\*\\Temp\\BNZ.*"))
    )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Script Execution via Microsoft HTML Application
-
-Microsoft HTML Applications (HTA) allow HTML code to run as trusted applications, leveraging Windows utilities like `rundll32.exe` and `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns and unusual command-line arguments, flagging potential misuse of these utilities for malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name (`rundll32.exe` or `mshta.exe`) and command-line arguments that triggered the detection.
-- Examine the parent process of the suspicious execution to determine if it is a known legitimate application or an unexpected source, using the `process.parent.executable` field.
-- Check the command-line arguments for any known malicious patterns, such as `*script*eval(*`, `*mshta*http*`, or `*StrReverse*`, which may indicate obfuscation or remote script execution.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Use Osquery to gather additional context about the process execution. For example, run the following query to list all processes executed by the same user within a short time frame:
-  ```sql
-  SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM processes WHERE pid = <suspicious_pid>);
-  ```
-- Analyze network connections made by the suspicious process to identify any unusual or unauthorized external communications.
-- Check for any recent downloads or file modifications in the user's `Downloads` or `Temp` directories, especially `.hta` files, which may indicate the source of the script.
-- Review system logs for any other suspicious activities or errors around the time of the alert to identify potential lateral movement or additional compromise.
-- Correlate the alert with other security events or alerts in the environment to determine if this is part of a larger attack campaign.
-- Consult threat intelligence sources to see if the observed patterns or indicators match known attack techniques or threat actor behaviors.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule if they use `rundll32.exe` or `mshta.exe` with command-line arguments that resemble those used in malicious scripts. Users can handle these by creating exceptions for known software paths or processes.
-- Some enterprise applications, like Citrix or Microsoft Office, may use these utilities in a manner that appears suspicious but is actually benign. Users should exclude these applications by specifying their executable paths in the exception list.
-- Automated scripts or administrative tools that leverage `mshta.exe` for legitimate purposes, such as system configuration or maintenance tasks, might be flagged. Users can manage these by identifying and excluding specific command-line patterns or parent processes associated with these tasks.
-- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users should maintain a list of trusted download locations or file hashes to prevent false positives.
-- Temporary files created during legitimate software extraction or installation processes, especially from archives, may match the rule's criteria. Users can exclude specific temporary directories or file patterns commonly used by trusted applications.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the process execution logs to confirm the presence of malicious activity, focusing on the command-line arguments and parent processes.
-- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
-- Remove any malicious scripts or files identified on the system, ensuring to check common directories such as Downloads and Temp folders.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Update and patch all software and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate alerts with known threat indicators.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Educate users on the risks of downloading and executing files from untrusted sources, emphasizing the importance of verifying the legitimacy of email attachments and links."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sip_provider_mod.toml b/rules/windows/defense_evasion_sip_provider_mod.toml
index ed4036dc3e0..64d6862f7ec 100644
--- a/rules/windows/defense_evasion_sip_provider_mod.toml
+++ b/rules/windows/defense_evasion_sip_provider_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,48 +48,6 @@ registry where host.os.type == "windows" and event.type == "change" and registry
   not (process.name : "msiexec.exe" and registry.data.strings : "mso.dll") and
   not (process.name : "regsvr32.exe" and registry.data.strings == "WINTRUST.DLL")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SIP Provider Modification
-
-Subject Interface Package (SIP) providers are integral to Windows' cryptographic system, ensuring file signature validation. Adversaries may alter these providers to bypass security checks or inject malicious code. The detection rule identifies suspicious registry changes linked to SIP providers, excluding benign processes, to flag potential subversion of trust controls, aligning with MITRE ATT&CK's defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to understand which registry path was modified, focusing on the `registry.path` field to identify the specific SIP provider affected.
-- Examine the `registry.value` and `registry.data.strings` fields to determine the DLL involved in the modification and assess if it is a known or suspicious file.
-- Check the `process.name` field to identify the process responsible for the registry change, and verify if it is a legitimate process or potentially malicious.
-- Investigate the process execution history using endpoint detection and response (EDR) tools to trace the origin and behavior of the process that made the registry change.
-- Use Osquery to list all current SIP providers and their associated DLLs to identify any unauthorized or unexpected entries. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Microsoft\\\\Cryptography\\\\OID\\\\EncodingType 0\\\\CryptSIPDllPutSignedDataMsg\\\\%\\\\Dll';`
-- Cross-reference the modified DLL with known good DLLs or a threat intelligence database to determine if it is associated with known malware or suspicious activity.
-- Analyze recent system logs and security events around the time of the registry change to identify any correlated suspicious activities or anomalies.
-- Investigate the user account context under which the registry change was made to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Review any recent software installations or updates that might have legitimately modified the SIP provider settings to rule out false positives.
-- Conduct a file integrity check on the modified DLL and other critical system files to ensure they have not been tampered with or replaced by malicious versions.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate software installations or updates modify SIP provider registry entries. For example, the installation of Microsoft Office or other trusted software might trigger changes in the registry paths monitored by the rule.
-- To manage these false positives, users can create exceptions for specific processes known to perform legitimate modifications. For instance, excluding `msiexec.exe` when it modifies `mso.dll` or `regsvr32.exe` when it interacts with `WINTRUST.DLL` can reduce noise from trusted activities.
-- Regularly review and update the list of excluded processes and registry paths to ensure that only benign activities are filtered out, maintaining the effectiveness of the detection rule against genuine threats.
-- Consider implementing a monitoring period to observe the behavior of newly installed or updated software, allowing for the identification of any additional benign processes that may need to be excluded.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
-- Conduct a thorough investigation to identify the source of the registry modification, focusing on recent changes and associated processes.
-- Verify the legitimacy of the modified SIP provider DLLs by comparing them against known good versions or using a trusted source.
-- If malicious activity is confirmed, remove or replace the compromised DLLs with clean versions from a trusted backup or installation media.
-- Review and analyze system logs, including security and application logs, to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan.
-- Harden the system by implementing least privilege access controls, enabling secure boot, and regularly auditing critical system configurations to prevent future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
index 1f5f94e20fa..14445099941 100644
--- a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
+++ b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,52 +56,6 @@ registry where host.os.type == "windows" and event.type == "change" and registry
   ) and
   registry.data.strings : ("4", "0x00000004")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SolarWinds Process Disabling Services via Registry
-
-SolarWinds software is integral for network management, often requiring deep system access. Adversaries may exploit this by altering registry settings to disable critical services, evading defenses. The detection rule identifies changes in registry paths linked to service start types, specifically targeting SolarWinds processes. This helps pinpoint unauthorized modifications indicative of potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the specific SolarWinds process involved by checking the `process.name` field against the list of known SolarWinds binaries.
-- Verify the registry path involved in the alert by examining the `registry.path` field to ensure it matches the critical paths associated with service start types.
-- Check the `registry.data.strings` field to confirm if the service start type was set to "4" (disabled), indicating a potential attempt to disable a service.
-- Correlate the timestamp of the registry change event with other logs to identify any concurrent suspicious activities or anomalies on the host.
-- Investigate the user account context under which the SolarWinds process was executed to determine if it aligns with expected administrative activity.
-- Use Osquery to gather additional context on the affected system. For example, run the following query to list all services with a start type of "disabled":
-  ```sql
-  SELECT name, start_type FROM services WHERE start_type = 'disabled';
-  ```
-- Examine recent process execution logs to identify any unusual or unauthorized execution of SolarWinds processes around the time of the alert.
-- Review system and security event logs for any signs of privilege escalation or lateral movement attempts that may coincide with the registry modification.
-- Investigate network logs for any unusual outbound connections from the affected host that could indicate data exfiltration or command-and-control activity.
-- Cross-reference the alert with threat intelligence sources to determine if the activity matches known attack patterns or indicators of compromise related to SolarWinds exploitation.
-
-### False positive analysis
-
-- Routine updates or maintenance activities by SolarWinds software may trigger the detection rule, as legitimate processes might modify registry settings during normal operations.
-- Scheduled tasks or automated scripts that involve SolarWinds processes could also lead to false positives if they alter service start types as part of their function.
-- To manage these false positives, users can create exceptions for known and verified SolarWinds processes that regularly perform such modifications, ensuring these are documented and approved by the security team.
-- Implementing a baseline of expected registry changes during normal operations can help differentiate between legitimate and suspicious activities, allowing for more accurate exclusions.
-- Regularly review and update the list of excluded processes and registry paths to adapt to changes in the network environment and SolarWinds software updates.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
-- Conduct a thorough investigation to confirm the unauthorized registry modification by reviewing system logs and correlating with other security events.
-- Identify and terminate any malicious processes associated with the SolarWinds binaries listed in the detection rule.
-- Restore the registry settings to their original state by referencing system backups or using known good configurations.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed registry changes and process activities, ensuring that future unauthorized modifications are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate similar events and improve detection capabilities.
-- Apply security patches and updates to the SolarWinds software and the operating system to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as restricting registry access permissions, enabling application whitelisting, and conducting regular security audits to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
index 8bae14b6adc..4fbeafb570a 100644
--- a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
+++ b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,49 +51,6 @@ process where host.os.type == "windows" and event.type == "start" and process.ex
   process.name : ("rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe",
                   "cscript.exe", "wscript.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Execution from a Mounted Device
-
-In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when launched by common parent processes like Explorer. This helps in spotting potential evasion tactics where attackers use system binaries to execute malicious scripts stealthily.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and working directory, ensuring they match the criteria specified in the detection rule.
-- Check the parent process name to verify if it is "explorer.exe," as this is a common parent process for user-initiated actions.
-- Investigate the process executable path to ensure it is not a legitimate application running from a non-standard directory.
-- Use Osquery to list all mounted devices and their paths to identify any unusual or unauthorized devices. Example query: `SELECT * FROM mounts WHERE device NOT LIKE '/dev/%';`
-- Examine the process command line arguments for any suspicious or unexpected parameters that could indicate malicious activity.
-- Correlate the process start time with user login sessions to determine if the execution aligns with legitimate user activity.
-- Check for any recent file modifications or creations in the non-standard working directory to identify potential malicious files.
-- Investigate the user account associated with the process to determine if it has a history of suspicious activity or if it has been compromised.
-- Review system logs for any other suspicious activities or alerts around the same time frame to identify potential lateral movement or additional threats.
-- Analyze network connections initiated by the process to detect any communication with known malicious IP addresses or domains.
-
-### False positive analysis
-
-- Legitimate software installations or updates: Some software installations or updates may execute scripts or binaries from mounted devices or external drives. Users should verify the source and purpose of such executions and consider excluding these specific processes if they are deemed safe.
-- Portable applications: Applications that are designed to run without installation, often from USB drives or network shares, may trigger this rule. Users can create exceptions for known and trusted portable applications to prevent false alerts.
-- IT administrative tasks: System administrators might use mounted devices to run scripts for maintenance or configuration purposes. It's important to document these activities and exclude them from the rule if they are part of regular administrative tasks.
-- Backup or recovery operations: Backup software might execute scripts from external drives during backup or recovery processes. Users should identify these operations and exclude them if they are part of a legitimate backup strategy.
-- Development and testing environments: Developers might run scripts from mounted devices during testing phases. It's advisable to differentiate between production and development environments and apply exceptions where necessary to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the execution, including reviewing logs and correlating with other security events.
-- Terminate any suspicious processes identified as being executed from non-standard directories to halt potential malicious activity.
-- Analyze the parent process and any associated files or scripts for signs of tampering or malicious intent.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are removed.
-- Apply system hardening measures, such as restricting script interpreter execution from non-standard directories and enforcing application whitelisting.
-- Conduct a post-incident review to identify gaps in detection and response capabilities, and update security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
index f289e1706d1..ef418dc1c99 100644
--- a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
+++ b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,49 +49,6 @@ file where host.os.type == "windows" and event.type != "deletion" and
                "cmstp.exe.log",
                "regsvr32.exe.log")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Managed Code Hosting Process
-
-Managed code hosting processes like wscript.exe, cscript.exe, and others are integral to executing scripts and managing code in Windows environments. Adversaries exploit these processes for code injection, enabling stealthy execution of malicious payloads. The detection rule identifies anomalies by monitoring specific log files associated with these processes, flagging potential misuse indicative of process injection tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify which specific managed code hosting process log file triggered the alert (e.g., wscript.exe.log, cscript.exe.log).
-- Examine the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events in the same timeframe.
-- Check the parent process of the suspicious managed code hosting process to identify if it was spawned by a legitimate or potentially malicious process.
-- Investigate the command line arguments used by the suspicious process to identify any unusual or unexpected parameters that could indicate malicious activity.
-- Analyze the user account associated with the process execution to determine if it aligns with normal user behavior or if it could be indicative of compromised credentials.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('wscript.exe', 'cscript.exe', 'mshta.exe', 'wmic.exe', 'svchost.exe', 'dllhost.exe', 'cmstp.exe', 'regsvr32.exe');`
-- Cross-reference the process hash with threat intelligence databases to check if it is associated with known malware.
-- Review network connections established by the suspicious process to identify any unusual or unauthorized external communications.
-- Check for any recent changes to the system, such as new software installations or updates, that could explain the process behavior.
-- Investigate any related alerts or logs from other security tools that might provide additional context or corroborate the suspicious activity.
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators often use scripts executed by processes like wscript.exe or cscript.exe for routine maintenance tasks, which can trigger false positives. To manage this, users can create exceptions for known scripts or script paths that are regularly used in their environment.
-- Software updates and installations: Some software installations or updates may use processes like mshta.exe or regsvr32.exe as part of their legitimate operations. Users should monitor these activities and whitelist specific update processes or installation paths that are verified as safe.
-- Automated system tasks: Windows Management Instrumentation (WMI) tasks or other automated system tasks might utilize wmic.exe or svchost.exe, leading to false alerts. Users can exclude these tasks by identifying and documenting regular system operations that are expected to use these processes.
-- Custom applications: In environments where custom applications are developed, these applications might use managed code hosting processes for legitimate purposes. Users should work with development teams to identify and exclude these applications from triggering alerts.
-- Security software: Some security tools may use these processes as part of their scanning or monitoring activities. Users should verify with their security vendors and exclude these processes if they are part of the security software's normal operation.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the flagged process by reviewing the associated log files and any related system events to confirm the presence of malicious activity.
-- Utilize endpoint detection and response (EDR) tools to perform a memory analysis and identify any injected code or anomalous behavior in the process.
-- If malicious activity is confirmed, terminate the suspicious process and remove any associated malicious files or scripts from the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution data and integrate with a security information and event management (SIEM) system for real-time monitoring and alerting.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are up to date.
-- Conduct a post-incident review to identify any gaps in the current security posture and update incident response plans accordingly.
-- Educate users on recognizing and reporting suspicious activities to prevent future incidents.
-- Implement hardening measures such as application whitelisting, disabling unnecessary scripting engines, and enforcing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_scrobj_load.toml b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
index 58fb5fe069b..02c9c309f06 100644
--- a/rules/windows/defense_evasion_suspicious_scrobj_load.toml
+++ b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,49 +57,6 @@ any where host.os.type == "windows" and
        "?:\\Windows\\System32\\wbem\\WMIADAP.exe",
        "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Script Object Execution
-
-The scrobj.dll is a legitimate Windows library used for executing scriptlets, often within trusted processes. Adversaries exploit this by loading scrobj.dll into atypical processes to execute malicious scripts, evading detection. The detection rule identifies such anomalies by monitoring for scrobj.dll in unexpected processes, excluding known safe executables, thus highlighting potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of scrobj.dll in an unexpected process by checking the `process.executable` field against the list of known safe executables.
-- Examine the `event.category` and `event.action` fields to determine if the alert was triggered by a library or driver load event, or a process image load event.
-- Investigate the parent process of the suspicious executable using the `process.parent.executable` field to identify potential sources of the script execution.
-- Check the `host.os.type` field to ensure the alert is relevant to a Windows environment, as the rule is specific to Windows systems.
-- Use Osquery to gather additional context on the suspicious process by running a query such as: `SELECT * FROM processes WHERE name = 'suspicious_process_name';` to retrieve details like process ID, parent process ID, and command line arguments.
-- Analyze the command line arguments of the suspicious process using the `process.command_line` field to identify any potentially malicious script or command being executed.
-- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
-- Investigate the user account associated with the process execution using the `user.name` field to determine if the account has been compromised or is being misused.
-- Review recent changes or anomalies in the system's file system or registry that could indicate the presence of malicious scriptlets or persistence mechanisms.
-- Consult threat intelligence sources to check if the observed behavior or process is associated with known malware or attack techniques, leveraging the MITRE ATT&CK references provided in the alert.
-
-### False positive analysis
-
-- Known false positives for the Suspicious Script Object Execution rule may include legitimate administrative scripts or automation tools that load scrobj.dll for benign purposes. These can occur in environments where custom scripts are used for system management or monitoring.
-- Users can handle these false positives by identifying and documenting regular processes that load scrobj.dll as part of their normal operation. Once identified, these processes can be added to the exclusion list within the detection rule to prevent unnecessary alerts.
-- It is important to regularly review and update the exclusion list to ensure that only verified safe processes are excluded, maintaining a balance between security and operational efficiency.
-- In environments with frequent legitimate use of scriptlets, consider implementing additional monitoring or logging to differentiate between expected and unexpected script object executions, providing context for further analysis.
-- Collaboration with IT and security teams can help in understanding the typical use cases of scrobj.dll within the organization, aiding in the accurate identification of false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to confirm the presence of malicious script execution by analyzing the process tree and associated network connections.
-- Terminate any suspicious processes that have loaded scrobj.dll in an unusual manner, ensuring to capture memory dumps for further analysis.
-- Remove any identified malicious scriptlets or files from the system and perform a full antivirus and anti-malware scan.
-- Review and update security policies to ensure that only trusted processes are allowed to load scrobj.dll, leveraging application whitelisting where possible.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution and DLL loading events, ensuring logs are forwarded to a centralized logging solution for analysis.
-- Integrate threat intelligence feeds to correlate detected anomalies with known threat actor tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
-- Harden the system by disabling unnecessary scripting capabilities and enforcing the principle of least privilege to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_wmi_script.toml b/rules/windows/defense_evasion_suspicious_wmi_script.toml
index 9dd9b75b4c4..3f1cee8f4c1 100644
--- a/rules/windows/defense_evasion_suspicious_wmi_script.toml
+++ b/rules/windows/defense_evasion_suspicious_wmi_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,48 +45,6 @@ sequence by process.entity_id with maxspan = 2m
 [any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and
  (?dll.name : ("jscript.dll", "vbscript.dll") or file.name : ("jscript.dll", "vbscript.dll"))]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious WMIC XSL Script Execution
-
-Windows Management Instrumentation Command-line (WMIC) is a powerful tool for managing Windows systems. Adversaries exploit WMIC to bypass security controls by executing scripts via XSL files, often loading scripting libraries like JScript or VBScript. The detection rule identifies such abuse by monitoring for unusual WMIC command patterns and the loading of specific scripting libraries, indicating potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific WMIC command that triggered the alert, focusing on the `process.args` field to identify the suspicious format pattern used.
-- Examine the `process.command_line` field to gather the full command executed, noting any deviations from typical WMIC usage patterns.
-- Check the `process.entity_id` to correlate this event with other related processes within the 2-minute window specified by the `maxspan` parameter.
-- Investigate the parent process of the WMIC execution to determine if it was initiated by a legitimate application or a potentially malicious process.
-- Analyze the `dll.name` or `file.name` fields to confirm the loading of `jscript.dll` or `vbscript.dll`, which may indicate script execution.
-- Use Osquery to list all processes that have recently loaded `jscript.dll` or `vbscript.dll` with a query like: `SELECT pid, name, path FROM processes WHERE path LIKE '%jscript.dll%' OR path LIKE '%vbscript.dll%';`
-- Cross-reference the process start time with user activity logs to determine if the execution aligns with expected user behavior or if it occurred during off-hours.
-- Investigate the network activity of the host around the time of the alert to identify any suspicious outbound connections that may indicate data exfiltration or command and control communication.
-- Review recent changes to the system's allowlist or security policies that might have permitted the execution of such scripts.
-- Check for any other alerts or indicators of compromise on the same host or associated user account to assess if this event is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use WMIC with XSL scripts for legitimate purposes, such as automating system management tasks. These activities can trigger the rule if they involve loading scripting libraries like JScript or VBScript.
-- Monitoring and management software: Some enterprise monitoring or management tools may use WMIC and scripting libraries to gather system information or perform routine checks, leading to false positives.
-- Custom scripts: Organizations may have custom scripts that utilize WMIC and XSL files for specific operational needs, which could be mistakenly flagged as suspicious.
-- To manage these false positives, users can create exceptions for known legitimate processes by adding them to an allowlist. This can be done by identifying the specific command lines or scripts that are frequently used and excluding them from the detection rule. Additionally, users should regularly review and update the allowlist to ensure it reflects current legitimate activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the execution of WMIC with suspicious XSL script patterns.
-- Review and analyze logs from the affected system and any related systems to trace the adversary's actions and identify any additional compromised systems.
-- Remove any unauthorized scripts or files identified during the investigation, particularly those involving jscript.dll or vbscript.dll.
-- Apply patches and updates to the operating system and all installed software to mitigate vulnerabilities that may have been exploited.
-- Restore the system from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from compromise.
-- Implement enhanced logging policies to capture detailed information on script execution and library loading activities, aiding future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity experts for further analysis and support.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as application whitelisting and stricter execution policies to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_timestomp_sysmon.toml b/rules/windows/defense_evasion_timestomp_sysmon.toml
index d0bb44cc50a..1664fbad7f2 100644
--- a/rules/windows/defense_evasion_timestomp_sysmon.toml
+++ b/rules/windows/defense_evasion_timestomp_sysmon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,49 +54,6 @@ file where host.os.type == "windows" and event.code : "2" and
  not file.extension : ("temp", "tmp", "~tmp", "xml", "newcfg") and not user.name : ("SYSTEM", "Local Service", "Network Service") and
  not file.name : ("LOG", "temp-index", "license.rtf", "iconcache_*.db")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File Creation Time Changed
-
-File creation timestamps are crucial for tracking file history and integrity. Adversaries may alter these timestamps, a tactic known as timestomping, to disguise malicious files as benign by aligning their timestamps with trusted files. The detection rule leverages Sysmon EventID 2 to identify such changes, excluding legitimate processes and file types, thus highlighting suspicious activities that may indicate an attempt to evade detection.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file and process involved in the creation time change, focusing on the `file.name` and `process.executable` fields.
-- Verify the legitimacy of the process by checking the `process.executable` path against known trusted applications and directories.
-- Investigate the user context under which the file creation time was changed by examining the `user.name` field to determine if it aligns with expected user behavior.
-- Cross-reference the file path and name with known benign files and directories to assess if the file is typically found in trusted locations.
-- Utilize Osquery to gather additional context about the file and process. For example, run the following query to check for recent file modifications: `SELECT * FROM file WHERE path = 'C:\\\\path\\\\to\\\\suspicious\\\\file' AND mtime > (SELECT strftime('%s', 'now') - 86400);`
-- Check for any recent changes in the file's hash value to determine if the file content has been altered, which could indicate tampering.
-- Investigate the parent process of the suspicious executable to understand the process hierarchy and identify potential process injection or masquerading.
-- Review system logs and other security events around the time of the file creation time change to identify any correlated suspicious activities or anomalies.
-- Analyze network activity from the host to detect any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
-- Consult threat intelligence sources to determine if the file or process has been associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger file creation time changes, especially for applications that frequently update, such as web browsers or productivity tools. Users can manage these by adding exceptions for known update processes or directories.
-- System maintenance tasks, like disk cleanup or system updates, might alter file timestamps. These can be handled by excluding specific system processes like cleanmgr.exe or msiexec.exe from the detection rule.
-- User-initiated file modifications, such as copying files to different directories, can also result in timestamp changes. To reduce false positives, users can exclude common user directories or specific file types that are often modified.
-- Automated backup or synchronization software may modify file timestamps to ensure data consistency. Users should consider excluding these applications or their associated directories from the rule.
-- Temporary files created by legitimate applications during normal operation might have their timestamps altered. Excluding file extensions like "temp" or "tmp" can help minimize these false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on files with altered timestamps and correlating with other suspicious activities.
-- Review Sysmon logs and other relevant logs to trace the origin of the timestomping activity and identify any associated malicious processes or files.
-- Remove or quarantine any identified malicious files and terminate any associated malicious processes.
-- Restore any altered or deleted files from known good backups to ensure data integrity and system functionality.
-- Escalate the incident to the security operations center (SOC) or incident response team if the scope of the attack is beyond initial containment efforts.
-- Implement or enhance logging policies to ensure comprehensive monitoring of file attribute changes and other critical system events.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by adversaries.
-- Educate users on recognizing and reporting suspicious activities to enhance the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
index a4c2be1e51c..17af2ccdeeb 100644
--- a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
+++ b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -125,50 +125,6 @@ library where host.os.type == "windows" and
 	 /* DLL loaded from the process.executable current directory */
 	 endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unsigned DLL Side-Loading from a Suspicious Folder
-
-DLL side-loading involves loading a malicious DLL into a trusted process to evade detection. Adversaries exploit this by placing unsigned DLLs in directories that mimic legitimate paths. The detection rule identifies trusted processes loading recently modified, unsigned DLLs from suspicious directories, indicating potential malicious activity. This helps in identifying attempts to bypass security measures by masquerading as legitimate software.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific trusted process and the unsigned DLL involved. Pay attention to the `process.code_signature.trusted` and `dll.code_signature.status` fields to confirm the trust status of the process and the unsigned nature of the DLL.
-- Examine the `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` fields to determine how recently the DLL was created or modified, which can indicate recent malicious activity.
-- Investigate the `dll.path` to verify if it matches any of the suspicious directories listed in the detection rule. This can help confirm if the DLL is located in a directory commonly abused for side-loading attacks.
-- Use Osquery to gather additional context about the process and DLL. For example, run the following query to list all DLLs loaded by the process: `SELECT * FROM process_open_sockets WHERE pid = <process_id>;` Replace `<process_id>` with the actual process ID from the alert.
-- Check the file properties and metadata of the unsigned DLL, including its creation and modification timestamps, to identify any anomalies or inconsistencies.
-- Correlate the process and DLL activity with other logs, such as Windows Event Logs, to identify any related suspicious behavior or events around the time of the alert.
-- Investigate the parent process of the trusted process to determine if it was spawned by a legitimate application or if it shows signs of compromise.
-- Analyze network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
-- Review the system's recent changes, such as software installations or updates, that might explain the presence of the unsigned DLL in a suspicious directory.
-- Conduct a file integrity check on the system to identify any other unauthorized or unexpected changes to critical system files and directories.
-
-### False positive analysis
-
-- Legitimate software updates: Some legitimate software may update their DLLs frequently, causing them to appear as recently modified. Users can create exceptions for known software update processes to prevent false positives.
-- Development environments: Developers often compile and test DLLs in directories that might match suspicious paths. Excluding directories used for development can help reduce false alerts.
-- Custom or in-house applications: Organizations may have custom applications that load unsigned DLLs from non-standard directories. Identifying and excluding these applications can prevent unnecessary alerts.
-- Backup or recovery software: Certain backup or recovery tools might temporarily load unsigned DLLs from unusual paths. Users should verify the legitimacy of such tools and consider excluding them if they are trusted.
-- Security software: Some security tools may use unsigned DLLs for legitimate purposes, such as monitoring or scanning. Users should ensure these tools are recognized and excluded from detection rules.
-- Testing or sandbox environments: In testing environments, unsigned DLLs might be used to simulate attacks or test software. Excluding these environments from production detection rules can help avoid false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to identify the source of the unsigned DLL and any associated malicious activity.
-- Use endpoint detection and response (EDR) tools to analyze the behavior of the trusted process and the loaded DLL.
-- Remove the malicious DLL and any other suspicious files from the system, ensuring that legitimate files are not affected.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Update antivirus and anti-malware solutions to ensure they can detect and prevent similar threats in the future.
-- Implement application whitelisting to prevent unauthorized DLLs from being loaded by trusted processes.
-- Enhance logging policies to capture detailed information about DLL loads and process execution for future investigations.
-- Integrate threat intelligence feeds to stay informed about emerging threats and adapt defenses accordingly.
-- Escalate the incident to the security operations center (SOC) or relevant team if the threat is part of a larger attack campaign, referencing MITRE ATT&CK techniques TA0005 and T1036 for context."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_dir_ads.toml b/rules/windows/defense_evasion_unusual_dir_ads.toml
index 95f452ee05b..9d0dc28418d 100644
--- a/rules/windows/defense_evasion_unusual_dir_ads.toml
+++ b/rules/windows/defense_evasion_unusual_dir_ads.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -39,49 +39,6 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.args : "?:\\*:*" and process.args_count == 1
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process Execution Path - Alternate Data Stream
-
-Alternate Data Streams (ADS) in Windows allow files to contain multiple data streams, which can be used to store metadata or additional information. Adversaries exploit ADS to conceal malicious code, making it harder to detect. The detection rule identifies processes initiated from ADS by monitoring specific execution patterns, such as unique argument structures, which are atypical for legitimate processes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a process execution from an Alternate Data Stream (ADS) by checking the `process.args` field for the pattern `?:\\\\*:*`.
-- Verify the `process.args_count` field to ensure it equals 1, indicating the process was initiated with a single argument, which is atypical and may suggest malicious intent.
-- Identify the parent process using the `process.parent.name` and `process.parent.pid` fields to understand the origin of the suspicious process execution.
-- Examine the `process.executable` field to determine the exact executable file path and verify its legitimacy by checking its digital signature and hash against known good values.
-- Use Osquery to list all processes running from ADS by executing a query such as: `SELECT pid, name, path FROM processes WHERE path LIKE '%:%';` to identify any other potentially suspicious processes.
-- Investigate the user context under which the process was executed by reviewing the `user.name` field to determine if it aligns with expected user behavior.
-- Check the `host.name` and `host.ip` fields to identify the affected system and correlate with any other alerts or logs from the same host for additional context.
-- Analyze recent file modifications on the host by querying file creation and modification times to identify any unusual changes that coincide with the process execution.
-- Review network activity associated with the process by examining logs for any unusual outbound connections or data transfers that could indicate exfiltration or command-and-control communication.
-- Cross-reference the process and host information with threat intelligence sources to determine if the behavior matches any known malware or adversary techniques.
-
-### False positive analysis
-
-- Legitimate software installations or updates may use Alternate Data Streams to store metadata or additional information, leading to false positives. Users can create exceptions for known software paths or processes that frequently trigger alerts.
-- Some backup or file synchronization tools might utilize ADS to manage file versions or metadata, which can be mistaken for malicious activity. Identifying these tools and excluding their processes from monitoring can reduce false positives.
-- Certain system utilities or administrative scripts may leverage ADS for legitimate purposes, such as storing configuration data. Users should review and whitelist these utilities if they are known and trusted within their environment.
-- Developers or IT personnel might use ADS for testing or development purposes, which could trigger alerts. Establishing a policy to document and approve such activities can help in creating appropriate exceptions.
-- Security software or forensic tools might interact with ADS as part of their scanning or analysis processes. Users should verify these interactions and exclude them if they are part of routine security operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation to confirm the presence of malicious code within the Alternate Data Stream by analyzing the process execution path and associated files.
-- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) across the network.
-- If malware is confirmed, remove the malicious files and any associated ADS using trusted antivirus or anti-malware software.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution data and monitor for similar suspicious activities in the future.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of tactics, techniques, and procedures (TTPs) associated with Defense Evasion and Hide Artifacts.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and features, to reduce the attack surface and prevent future exploitation of Alternate Data Streams."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
index f28cd23ae0d..0e2c84b0d56 100644
--- a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
+++ b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,49 +50,6 @@ sequence by host.id, process.entity_id with maxspan=1m
     "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")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Network Connection via DllHost
-
-Dllhost.exe is a legitimate Windows process responsible for managing DLL-based applications. Adversaries may exploit it to execute malicious code under the guise of a trusted process, often for Command and Control (C2) activities. The detection rule identifies suspicious outbound connections by dllhost.exe, focusing on connections to non-local IP addresses, which may indicate unauthorized network activity. This helps in identifying potential misuse of system binaries for evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "dllhost.exe" and verify the process.args_count is 1, as specified in the detection rule.
-- Check the destination IP address of the outbound connection to determine if it falls outside the specified non-local IP ranges, indicating a potential external connection.
-- Correlate the process.entity_id and host.id with other logs to identify any related processes or activities on the same host around the time of the alert.
-- Use Osquery to gather additional context about the dllhost.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'dllhost.exe' AND pid = <process_id>;` to retrieve details like parent process, command line arguments, and execution path.
-- Investigate the parent process of dllhost.exe to determine if it was spawned by a legitimate application or a potentially malicious one.
-- Examine historical network activity from the same host to identify any patterns or repeated connections to suspicious IP addresses.
-- Check for any recent changes or anomalies in the system's configuration or installed software that could explain the unusual network activity.
-- Review any related security alerts or incidents involving the same host or IP address to identify potential patterns or ongoing threats.
-- Analyze the network traffic associated with the suspicious connection using packet captures or network logs to identify any data exfiltration or command and control communication.
-- Consult threat intelligence sources to determine if the destination IP address or any related indicators are associated with known malicious activity or threat actors.
-
-### False positive analysis
-
-- Legitimate software updates or cloud services may cause dllhost.exe to make outbound connections to non-local IP addresses, which can be mistaken for malicious activity.
-- Some enterprise applications may use dllhost.exe for legitimate network communications, especially in environments with custom or legacy software.
-- Users can handle these false positives by creating exceptions for known IP addresses or domains associated with trusted software updates and services.
-- Regularly review and update the list of exceptions to ensure it reflects current legitimate network activities and does not inadvertently allow malicious traffic.
-- Collaborate with IT and security teams to identify and document legitimate use cases of dllhost.exe network connections within the organization.
-
-### Response and remediation
-
-- Isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
-- Conduct a thorough investigation of the dllhost.exe process to determine if it is executing unauthorized or malicious code, using tools like process explorers or endpoint detection and response (EDR) solutions.
-- Analyze network traffic logs to identify any unusual outbound connections made by dllhost.exe and correlate them with known malicious IP addresses or domains.
-- Terminate any suspicious instances of dllhost.exe and remove any associated malicious files or scripts from the system.
-- Restore the system from a known good backup if malicious activity is confirmed and cannot be remediated through other means.
-- Update and patch the operating system and all installed software to mitigate vulnerabilities that could be exploited by adversaries.
-- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
-- Integrate threat intelligence feeds to automatically update detection rules with known indicators of compromise (IOCs) related to dllhost.exe misuse.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or advanced persistent threat (APT) activity.
-- Conduct a post-incident review to identify gaps in detection and response capabilities and implement hardening measures such as application whitelisting and least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
index 3c1590b0543..f2dc01c3942 100644
--- a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
+++ b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,48 +46,6 @@ process where host.os.type == "windows" and event.type == "start" and
   process.parent.pid == 4 and process.executable : "?*" and
   not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Child Process from a System Virtual Process
-
-In Windows environments, the System process (PID 4) is a critical component responsible for managing system-level operations. Adversaries may exploit this by injecting malicious code to spawn unauthorized child processes, evading detection. The detection rule identifies anomalies by flagging unexpected child processes of the System process, excluding known legitimate executables, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process executable and parent PID match the criteria: process.parent.pid == 4 and process.executable : "?*".
-- Cross-reference the process executable against known legitimate system processes to ensure it is not a false positive.
-- Use Osquery to gather additional context about the suspicious process. Example query: `SELECT * FROM processes WHERE pid = <suspicious_process_pid>;`
-- Investigate the command line arguments of the suspicious process to identify any unusual or malicious patterns.
-- Check the process creation time and correlate it with other system events or logs to identify any related activities.
-- Examine the parent process tree to understand the lineage and determine if there are any other suspicious processes involved.
-- Analyze network connections initiated by the suspicious process to identify any unusual or unauthorized communication.
-- Review recent changes to the system, such as software installations or updates, that might explain the presence of the process.
-- Investigate the user account context under which the process is running to determine if it aligns with expected behavior.
-- Consult threat intelligence sources to see if the process executable or related indicators have been associated with known threats.
-
-### False positive analysis
-
-- Known false positives for the Unusual Child Process from a System Virtual Process rule may include legitimate system maintenance or update processes that are not typically associated with malicious activity. These can include certain third-party security or system management tools that interact with the System process for legitimate purposes.
-- Users can handle these false positives by creating exceptions for specific executables that are verified as non-threatening. This can be done by adding these executables to the exclusion list in the detection rule, ensuring they are not flagged in future scans.
-- It is important to regularly review and update the list of excluded executables to ensure that only verified and trusted processes are excluded, maintaining a balance between security and operational efficiency.
-- Users should also consider the context of the flagged process, such as the time of execution and the associated user account, to determine if the activity aligns with expected behavior or scheduled tasks, which can help in distinguishing false positives from genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation to confirm the presence of malicious code injection by analyzing the suspicious child process and its parent process.
-- Terminate any unauthorized processes spawned by the System process (PID 4) to halt malicious activity.
-- Review and collect relevant logs, including process creation logs and security event logs, to understand the scope and impact of the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
-- Implement enhanced logging policies to capture detailed process creation and termination events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities against similar threats.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for process injection.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_windows_filtering_platform.toml b/rules/windows/defense_evasion_windows_filtering_platform.toml
index 3adf5226b1a..a409ebe9849 100644
--- a/rules/windows/defense_evasion_windows_filtering_platform.toml
+++ b/rules/windows/defense_evasion_windows_filtering_platform.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -97,49 +97,6 @@ sequence by winlog.computer_name with maxspan=1m
         "splunk.exe", "sysmon.exe", "sysmon64.exe", "taniumclient.exe"
     )] with runs=5
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Evasion via Windows Filtering Platform
-
-The Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for network filtering and packet processing. Adversaries may exploit WFP by creating malicious rules to block security software from sending telemetry, thus evading detection. The detection rule identifies multiple blocked network events linked to security processes, indicating potential tampering with WFP rules to impair defenses.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `winlog.computer_name` and `process.name` involved in the blocked network events.
-- Check the frequency and pattern of the blocked events to determine if they are consistent with normal operations or indicative of tampering.
-- Correlate the `process.name` with known security software to confirm if it is legitimate and expected on the system.
-- Use event logs to trace back any recent changes to the Windows Filtering Platform rules on the affected system.
-- Investigate the user accounts and processes that have modified WFP rules recently to identify any unauthorized changes.
-- Utilize Osquery to gather more information about the network configuration and WFP rules. Example query: `SELECT * FROM wfp_filters WHERE name LIKE '%<process_name>%';` to list any WFP rules associated with the suspicious process.
-- Examine the system for any signs of compromise, such as unusual processes, services, or scheduled tasks that could indicate malicious activity.
-- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns.
-- Investigate the network traffic from the affected system to determine if there are any anomalies or connections to known malicious IPs.
-- Consult threat intelligence sources to check if the identified process or behavior is associated with known evasion techniques or threat actors.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they temporarily block network traffic for security processes, leading to false positives.
-- Network congestion or misconfigurations in firewall settings can cause legitimate security software to appear as if it's being blocked, resulting in false positives.
-- Users can handle these false positives by creating exceptions for known and trusted software update processes or installation activities that are frequently flagged.
-- Regularly review and update the list of process names in the detection rule to ensure it aligns with the current security software deployed in the environment, reducing unnecessary alerts.
-- Implement a monitoring period to observe the behavior of flagged processes and determine if they consistently result in false positives, allowing for informed decisions on exclusions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
-- Conduct a thorough investigation to identify any unauthorized WFP rules and remove or correct them to restore normal security software operations.
-- Review and analyze logs from the affected system and network devices to trace the source and scope of the attack, focusing on any anomalies related to the processes listed in the detection query.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Restore the system to its operational state by reinstalling or updating endpoint security software and ensuring all security patches are applied.
-- Implement enhanced logging policies to capture detailed network and process activity, ensuring that future incidents can be detected and analyzed more effectively.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
-- Conduct a review of firewall and WFP configurations to ensure they are aligned with security best practices and do not allow unauthorized modifications.
-- Educate users and administrators on recognizing signs of potential evasion techniques and the importance of reporting suspicious activity promptly.
-- Consider implementing network segmentation and access controls to limit the potential impact of compromised systems and prevent lateral movement by adversaries."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_bash_exec.toml b/rules/windows/defense_evasion_wsl_bash_exec.toml
index 87369355226..28b232f3d9d 100644
--- a/rules/windows/defense_evasion_wsl_bash_exec.toml
+++ b/rules/windows/defense_evasion_wsl_bash_exec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,52 +66,6 @@ process where host.os.type == "windows" and event.type : "start" and
   ) and 
     not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Execution via Windows Subsystem for Linux
-
-Windows Subsystem for Linux (WSL) allows users to run Linux binaries on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process executable path and command-line arguments that triggered the alert, focusing on paths like `?:\\Windows\\System32\\bash.exe` and command-line deviations from typical usage.
-- Examine the parent-child process relationship, particularly if the parent process is `wsl.exe` and the child process is not `wslhost.exe`, to understand the context of the execution.
-- Investigate the command-line arguments used with `wsl.exe`, especially if they include suspicious commands like `curl`, `cat`, or access to sensitive files such as `/etc/shadow` or `/etc/passwd`.
-- Check for any exclusions in the command-line arguments that might indicate legitimate use, such as `wsl-bootstrap`, `docker-desktop-data`, or `*.vscode-server*`.
-- Verify the parent process executable path to ensure it is not a known legitimate application like Docker, which might indicate a false positive.
-- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes related to WSL:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE '%\\\\Windows\\\\System32\\\\bash.exe%' OR path LIKE '%\\\\Users\\\\%\\\\AppData\\\\Local\\\\Packages\\\\%\\\\rootfs\\\\usr\\\\bin\\\\bash%';
-  ```
-- Analyze the network activity associated with the suspicious process to identify any unusual outbound connections or data exfiltration attempts.
-- Review the user account context under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Check the system's security logs for any related events or anomalies around the time of the alert to gather additional context.
-- Correlate the findings with other security tools and logs to determine if this activity is part of a broader attack pattern or an isolated incident.
-
-### False positive analysis
-
-- **Development Tools Usage**: Developers using WSL for legitimate purposes, such as running development environments or testing scripts, may trigger alerts. To manage this, users can create exceptions for specific user accounts or processes frequently involved in development activities.
-- **System Administration Tasks**: System administrators might use WSL for routine maintenance tasks, which could be flagged as suspicious. Excluding known administrative scripts or commands from the detection rule can help reduce false positives.
-- **Docker Integration**: Docker Desktop for Windows uses WSL 2 as its backend, which might generate alerts. Users can exclude Docker-related processes by adding exceptions for Docker executable paths or specific command-line arguments associated with Docker operations.
-- **VSCode Remote Development**: Visual Studio Code's remote development feature may utilize WSL, leading to potential false positives. Users can exclude processes or command-line arguments related to VSCode's remote server operations to mitigate this.
-- **Custom Scripts**: Organizations may have custom scripts that run via WSL for automation or integration purposes. Identifying and excluding these scripts from the detection rule can help prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the alert by reviewing the process execution details, including command-line arguments and parent-child process relationships, to confirm malicious activity.
-- Capture and preserve relevant logs and artifacts, such as WSL execution logs, system event logs, and network traffic, for further analysis and evidence collection.
-- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to monitor WSL activity, including command execution and file access, to improve detection capabilities.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to identify and respond to similar threats in the future.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and conducting a full system scan to ensure no residual threats remain.
-- Harden the system by disabling WSL if not required, or by configuring strict access controls and monitoring for WSL usage.
-- Review and update security policies and procedures to address gaps identified during the incident and to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_child_process.toml b/rules/windows/defense_evasion_wsl_child_process.toml
index 7cbc976b497..eb1713f9cfb 100644
--- a/rules/windows/defense_evasion_wsl_child_process.toml
+++ b/rules/windows/defense_evasion_wsl_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -70,50 +70,6 @@ process where host.os.type == "windows" and event.type : "start" and
       )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution via Windows Subsystem for Linux
-
-Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, bridging the gap between Windows and Linux environments. Adversaries may exploit WSL to execute malicious Linux binaries, bypassing traditional Windows security measures. The detection rule identifies suspicious executions initiated by WSL processes, excluding known legitimate paths, to flag potential misuse while minimizing false positives.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process was executed and its parent process, focusing on the `process.parent.name` field to confirm it was initiated by `wsl.exe` or `wslhost.exe`.
-- Examine the `process.executable` field to identify the exact path of the executed binary and determine if it is a known legitimate application or potentially malicious.
-- Check the `event.type` field to confirm the event is a process start, ensuring the alert is relevant to execution attempts.
-- Investigate the user context under which the process was executed by reviewing the user account details associated with the process to identify any anomalies or unauthorized access.
-- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'wsl.exe' OR name = 'wslhost.exe';` to list all instances and their command-line arguments.
-- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
-- Analyze network connections initiated by the suspicious process using network monitoring tools or logs to detect any unauthorized data exfiltration or communication with known malicious IPs.
-- Review the system's WSL configuration and installed distributions to ensure they are legitimate and have not been tampered with by running: `wsl --list --verbose` to list all installed distributions and their states.
-- Check for any recent changes to the WSL configuration files or related registry keys that could indicate tampering or unauthorized modifications.
-- Investigate the timeline of events on the host to identify any other suspicious activities or changes that coincide with the execution attempt, providing a broader context for the alert.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate software development activities where developers use WSL to compile or test code, as these processes can mimic adversarial behavior.
-- System administrators or IT professionals might use WSL for routine maintenance tasks, which could trigger the detection rule if not properly excluded.
-- Automated scripts or scheduled tasks that leverage WSL for legitimate operations can also be flagged as suspicious.
-- To manage these false positives, users can create exceptions for specific processes or paths that are known to be safe and frequently used in their environment.
-- Regularly review and update the exclusion list to ensure it reflects the current operational needs and legitimate use cases of WSL within the organization.
-- Consider implementing a logging and alerting system to monitor excluded activities, ensuring that any changes in behavior are promptly investigated.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the WSL installation and any associated processes by cross-referencing with known software inventories.
-- Conduct a thorough investigation of the executed processes to determine if they are part of a legitimate application or a potential threat.
-- Review system logs and WSL-specific logs to identify any unusual or unauthorized activities that may indicate compromise.
-- Remove any unauthorized or malicious Linux binaries identified during the investigation from the WSL environment.
-- Update antivirus and endpoint detection and response (EDR) solutions to ensure they can detect and block similar threats in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution data, especially for WSL-related activities.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities for similar threats.
-- Apply system hardening measures, such as restricting WSL usage to authorized users and regularly updating WSL components, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_filesystem.toml b/rules/windows/defense_evasion_wsl_filesystem.toml
index 4ba60069530..eb37721421f 100644
--- a/rules/windows/defense_evasion_wsl_filesystem.toml
+++ b/rules/windows/defense_evasion_wsl_filesystem.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,52 +46,6 @@ sequence by process.entity_id with maxspan=5m
   process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"]
  [file where host.os.type == "windows" and process.name : "dllhost.exe" and not file.path : "?:\\Users\\*\\Downloads\\*"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Host Files System Changes via Windows Subsystem for Linux
-
-Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute commands and modify files on the host system, bypassing traditional security measures. The detection rule identifies suspicious file operations initiated by WSL processes, specifically monitoring for unusual activity by the Plan9FileSystem, which is responsible for file system interactions, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the process.entity_id and the timestamp of the event to correlate with other logs.
-- Verify the process start event for "dllhost.exe" with the specific Plan9FileSystem CLSID in the command line to confirm the use of WSL for file operations.
-- Check the file path involved in the alert to determine if it is a legitimate location or if it deviates from normal user behavior, especially outside the Downloads directory.
-- Investigate the parent process of "dllhost.exe" to identify how it was initiated and if it correlates with any known legitimate or suspicious activities.
-- Use Osquery to list all running WSL instances and their associated processes to identify any unusual or unauthorized WSL usage:
-  ```sql
-  SELECT name, state, version FROM wsl_instances;
-  ```
-- Examine recent file creation and modification events on the host system to identify any unauthorized changes or anomalies in file paths and names.
-- Correlate the event with user activity logs to determine if the file operations align with expected user behavior or if they indicate potential misuse.
-- Check for any recent changes in WSL configuration or installation logs to identify if WSL was recently enabled or modified, which could indicate an attempt to bypass security.
-- Review network logs for any unusual outbound connections from the host that could suggest data exfiltration attempts following the file system changes.
-- Investigate other security alerts or logs from the same host around the time of the alert to identify any additional indicators of compromise or related suspicious activities.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use WSL for legitimate purposes such as running scripts or managing files, which could trigger the detection rule. To handle this, users can create exceptions for known administrative accounts or specific scripts that are regularly executed.
-- Development activities: Developers often use WSL for software development, which involves frequent file creation and modification. Users can exclude specific development environments or directories from monitoring to reduce false positives.
-- Automated processes: Scheduled tasks or automated processes that interact with the file system via WSL might be flagged. Identifying and excluding these processes based on their command lines or execution patterns can help minimize false alerts.
-- Backup operations: Some backup solutions may utilize WSL to access and copy files, leading to potential false positives. Users should identify these backup processes and configure exceptions for them to prevent unnecessary alerts.
-- Security tools: Certain security tools or monitoring solutions might use WSL for scanning or analysis purposes. Users can whitelist these tools by their process names or command lines to avoid false detections.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on WSL processes and any unusual file modifications.
-- Review and analyze logs from WSL and Plan9FileSystem activities to understand the adversary's actions and entry points.
-- Remove any unauthorized WSL installations or configurations that were not approved or are deemed suspicious.
-- Restore any modified or deleted files from known good backups to ensure data integrity and system functionality.
-- Apply security patches and updates to both Windows and WSL to mitigate any known vulnerabilities that could be exploited.
-- Implement enhanced logging policies to capture detailed WSL activity, including process creation, file access, and network connections.
-- Integrate security solutions with SIEM systems to improve detection capabilities and automate alerting for suspicious WSL activities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks associated with WSL and provide training on secure configuration and usage practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_kalilinux.toml b/rules/windows/defense_evasion_wsl_kalilinux.toml
index 100441808ae..5e45f738e56 100644
--- a/rules/windows/defense_evasion_wsl_kalilinux.toml
+++ b/rules/windows/defense_evasion_wsl_kalilinux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,50 +61,6 @@ process where host.os.type == "windows" and event.type == "start" and
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Install Kali Linux via WSL
-
-Windows Subsystem for Linux (WSL) allows users to run Linux distributions on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to install distributions like Kali Linux, leveraging its capabilities for stealthy operations and evading traditional Windows security measures. The detection rule identifies suspicious activities by monitoring specific process executions and arguments related to Kali Linux installation, helping to uncover potential misuse of WSL for malicious purposes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious process executions related to Kali Linux installation via WSL, focusing on the `process.name` and `process.args` fields.
-- Check the `process.executable` path to verify if it matches known paths for Kali Linux installations, such as those in `AppData` or `Program Files`.
-- Use Osquery to list all installed WSL distributions on the host to confirm the presence of Kali Linux. Example query: `SELECT name FROM wsl_distributions;`
-- Investigate the parent process of `wsl.exe` to determine how the installation was initiated and identify any associated user accounts.
-- Examine the user account associated with the suspicious process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
-- Review recent login events for the user account to identify any unusual access patterns or times that could suggest unauthorized activity.
-- Analyze network activity from the host around the time of the alert to detect any connections to known malicious IPs or domains associated with Kali Linux usage.
-- Check for any additional processes or scripts executed by the user that could indicate further malicious activity or attempts to leverage Kali Linux tools.
-- Investigate any file modifications or creations in the directories associated with the Kali Linux installation paths to identify potential tampering or unauthorized changes.
-- Correlate the findings with other security alerts or logs from the same host to build a comprehensive picture of the potential threat and its scope.
-
-### False positive analysis
-
-- Users or administrators may intentionally install Kali Linux via WSL for legitimate purposes such as development, testing, or educational activities, which can trigger the detection rule.
-- Automated scripts or deployment tools that configure development environments might include steps to install Kali Linux on WSL, leading to benign alerts.
-- Security researchers or IT professionals might use Kali Linux on WSL for vulnerability assessments or penetration testing within a controlled environment, which should be considered non-threatening.
-- To manage these false positives, users can create exceptions for known and authorized users or systems that regularly perform these installations.
-- Implementing a whitelist of approved processes or users who are allowed to install Kali Linux via WSL can help reduce unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from detection, maintaining a balance between security and operational needs.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the WSL installation by checking with the user or system owner and reviewing recent changes or installations.
-- Conduct a thorough investigation of the system to identify any additional malicious activities or unauthorized access, focusing on processes and files related to Kali Linux.
-- Remove any unauthorized or suspicious WSL distributions, particularly Kali Linux, and ensure that WSL is configured according to organizational policies.
-- Review and update security policies to restrict the installation of unauthorized WSL distributions and enforce application whitelisting where possible.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging and monitoring for WSL activities, including process execution and network connections, to improve detection of similar threats in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate WSL-related alerts with other security events.
-- Restore the system to its operational state by reinstalling necessary software and applying security patches, ensuring that no unauthorized changes remain.
-- Apply system hardening measures, such as disabling WSL if not needed, enforcing least privilege access, and regularly reviewing user permissions and installed software."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_active_directory_webservice.toml b/rules/windows/discovery_active_directory_webservice.toml
index 3f3e952d1c2..e43e63aa66c 100644
--- a/rules/windows/discovery_active_directory_webservice.toml
+++ b/rules/windows/discovery_active_directory_webservice.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -44,49 +44,6 @@ sequence by process.entity_id with maxspan=3m
  [network where host.os.type == "windows" and destination.port == 9389 and source.port >= 49152 and
   network.direction == "egress" and network.transport == "tcp" and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Enumeration via Active Directory Web Service
-
-Active Directory Web Service (ADWS) facilitates querying Active Directory (AD) over a network, providing a web-based interface for directory services. Adversaries may exploit ADWS to enumerate network resources and user accounts, gaining insights into the environment. The detection rule identifies suspicious activity by monitoring processes loading specific AD-related modules and making network connections to the ADWS port, which may indicate unauthorized enumeration attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process entity ID that triggered the rule, focusing on the process loading the AD-related modules.
-- Examine the process executable path to determine if it matches any known legitimate applications or if it appears suspicious based on the exclusion list in the query.
-- Check the user ID associated with the process to verify if it belongs to a legitimate system account or an unexpected user, as the query excludes well-known service accounts.
-- Investigate the network connection details, particularly the destination IP and port 9389, to confirm if the connection was made to a legitimate ADWS server or an unexpected destination.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE pid = <process_id>;` to retrieve command-line arguments and other process details.
-- Analyze the source port used in the network connection to determine if it falls within the expected ephemeral port range, as specified in the query.
-- Cross-reference the destination IP address with known internal ADWS servers or external threat intelligence sources to assess its legitimacy.
-- Review recent login events and user activity logs for the user associated with the process to identify any unusual behavior or patterns.
-- Check for any other recent alerts or logs related to the same process entity ID or user ID to identify potential patterns or repeated attempts.
-- Investigate any other network connections made by the same process to determine if there are additional suspicious activities or connections to other critical services.
-
-### False positive analysis
-
-- Legitimate administrative tools and scripts may load Active Directory-related modules and connect to the ADWS port as part of routine operations, leading to false positives. 
-- Scheduled tasks or automated processes that query Active Directory for system management or monitoring purposes might trigger the rule.
-- Security software or monitoring agents that perform regular checks on Active Directory services could be mistakenly flagged.
-- To manage these false positives, users can create exceptions for known benign processes by excluding specific executables or user accounts that are verified as non-threatening.
-- Regularly review and update the list of excluded processes and users to ensure that only legitimate activities are exempted, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the enumeration attempt, including reviewing logs and correlating with other security events.
-- Verify the legitimacy of the process and user account involved in the suspicious activity to determine if it is a false positive or a genuine threat.
-- If malicious activity is confirmed, terminate the suspicious process and disable the associated user account to prevent further access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Review and enhance logging policies to ensure comprehensive monitoring of Active Directory-related activities, including module loads and network connections.
-- Implement additional security controls, such as network segmentation and access controls, to limit exposure of the Active Directory Web Service.
-- Restore the system to its operational state by applying necessary patches, updating security configurations, and conducting a full system scan for malware.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks associated with Active Directory enumeration and the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_high_number_ad_properties.toml b/rules/windows/discovery_high_number_ad_properties.toml
index 201a96a97e8..0b6dad34e2a 100644
--- a/rules/windows/discovery_high_number_ad_properties.toml
+++ b/rules/windows/discovery_high_number_ad_properties.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,48 +49,6 @@ any where event.action in ("Directory Service Access", "object-operation-perform
  event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and
  winlog.event_data.AccessMaskDescription == "Read Property" and length(winlog.event_data.Properties) >= 2000
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Access to LDAP Attributes
-
-LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to read numerous object attributes, seeking vulnerabilities or sensitive data. The detection rule identifies unusual read access patterns, excluding system accounts, by monitoring specific event codes and access descriptions, flagging potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the event logs to confirm the alert by checking for event code 4662 and ensuring the AccessMaskDescription is "Read Property".
-- Verify the SubjectUserSid to ensure it is not the system account (S-1-5-18) and identify the actual user or service account involved.
-- Analyze the winlog.event_data.Properties field to understand which attributes were accessed and assess their sensitivity or relevance to potential vulnerabilities.
-- Cross-reference the identified user or service account with recent changes in user permissions or roles to determine if the access is legitimate or part of a broader pattern.
-- Investigate the source IP address or host from which the LDAP access was initiated to determine if it aligns with expected network behavior for the identified user or service account.
-- Use Osquery to gather additional context on the host involved. For example, run the query: `SELECT * FROM processes WHERE name LIKE '%ldap%' AND user = '<identified_user>';` to identify any suspicious processes related to LDAP access.
-- Check for any correlated alerts or logs that might indicate lateral movement or privilege escalation attempts by the same user or from the same host.
-- Review historical access patterns for the identified user or service account to determine if this level of access is typical or anomalous.
-- Consult with the directory services team to verify if there were any legitimate administrative tasks or audits that could explain the high volume of attribute reads.
-- Document all findings and observations, including any unusual patterns or discrepancies, to support further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators or automated scripts may perform legitimate bulk reads of LDAP attributes as part of regular maintenance or audits. These activities can trigger the rule but are non-threatening.
-- Monitoring and compliance tools: Security and compliance software often access a large number of LDAP attributes to ensure policy adherence and system health, which can be mistaken for suspicious activity.
-- Application service accounts: Some applications require extensive access to LDAP attributes for functionality, such as user provisioning or authentication services, which may appear as suspicious reads.
-- To manage false positives, users can create exceptions for known administrative accounts, service accounts, or specific tools that regularly perform high-volume LDAP reads. This can be done by adding these accounts to an exclusion list or adjusting the rule to ignore specific access patterns associated with legitimate activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Conduct a thorough investigation to identify the source and scope of the suspicious LDAP access, focusing on the user accounts and systems involved.
-- Review and analyze logs from the affected system and related network devices to gather evidence and understand the attack vector.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Reset passwords and review permissions for any accounts that were involved in the suspicious activity to prevent further unauthorized access.
-- Implement enhanced logging policies to capture detailed LDAP access events, ensuring that all read operations on sensitive attributes are monitored.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate LDAP access patterns with known threat indicators.
-- Restore the affected system to its operational state by applying necessary patches, updates, and configuration changes to address any identified vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting LDAP access to only necessary accounts, enabling multi-factor authentication, and regularly auditing directory permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
index e0d4c6ae29a..6c49a43316c 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -35,48 +35,6 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
   "c4e9ed3e-55a2-4309-a012-bc3c78dad10a" or "51176ed2-2d90-49f2-9f3d-17196428b169"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Discovery Signal Alert with Unusual Process Command Line
-
-In Windows environments, adversaries often exploit command-line tools to gather system information stealthily. This detection rule identifies anomalies by monitoring unique combinations of host, user, and command-line entries. By correlating these with known discovery tactics, it flags potential misuse, alerting analysts to investigate further.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific host.id, user.id, and process.command_line that triggered the alert. This will provide context on the potentially suspicious activity.
-- Cross-reference the command line entry with known legitimate processes and commands to determine if the activity is expected or unusual for the given host and user.
-- Check the event logs on the affected host for any related events around the time of the alert to gather additional context on the process execution.
-- Investigate the user.id associated with the alert to determine if the user has a history of executing similar commands or if this behavior is atypical.
-- Utilize Osquery to gather more information about the process and its parent process. For example, run the following Osquery query to list processes with their parent processes: `SELECT pid, name, path, parent FROM processes WHERE pid = <suspicious_pid>;`
-- Examine the network activity from the host during the time of the alert to identify any unusual outbound connections that may correlate with the command line activity.
-- Review any recent changes or updates to the host that might explain the unusual command line activity, such as software installations or configuration changes.
-- Check for any other alerts or signals from the same host or user within a similar timeframe to identify potential patterns or related activities.
-- Consult threat intelligence sources to determine if the command line or process is associated with known malicious activity or threat actor techniques.
-- Document all findings and observations during the investigation to provide a comprehensive overview of the incident and support any further analysis or escalation.
-
-### False positive analysis
-
-- Known false positives for the Unusual Discovery Signal Alert with Unusual Process Command Line rule often arise from legitimate administrative tasks or automated scripts that use command-line tools for system management or monitoring. These activities can mimic adversarial discovery techniques but are benign in nature.
-- Users can manage these false positives by identifying and documenting regular administrative processes and scripts that trigger the alert. Once identified, these can be excluded from the alerting criteria by creating exceptions based on specific host.id, user.id, or process.command_line patterns that are known to be safe.
-- It is important to regularly review and update these exceptions to ensure they remain relevant and do not inadvertently exclude new or modified legitimate processes that could be exploited by adversaries.
-- Collaboration with IT and security teams can help in distinguishing between legitimate and suspicious activities, ensuring that the rule remains effective in detecting genuine threats while minimizing noise from false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the unusual process command line to determine if it aligns with known malicious patterns or behaviors.
-- Review user activity and permissions associated with the alert to identify any unauthorized access or privilege escalation.
-- Utilize endpoint detection and response (EDR) tools to perform a detailed analysis of the affected system, focusing on any additional indicators of compromise (IOCs).
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a confirmed threat or if the scope of the attack is unclear.
-- Apply patches and updates to the operating system and any vulnerable applications to mitigate known vulnerabilities.
-- Restore the system from a clean backup if malicious activity is confirmed and ensure that the backup is free from compromise.
-- Implement enhanced logging and monitoring policies to capture detailed command-line activity and user actions for future investigations.
-- Integrate threat intelligence feeds to correlate alerts with known threat actor tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
index c0f04a97115..b39b57e1999 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -30,48 +30,6 @@ type = "new_terms"
 query = '''
 host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:"1d72d014-e2ab-4707-b056-9b96abe7b511"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Discovery Signal Alert with Unusual Process Executable
-
-This detection rule focuses on identifying anomalies in Windows environments by monitoring signals with atypical host, user, and process attributes. Adversaries often exploit legitimate discovery tools to gather system information stealthily. The rule flags unusual process executions, which may indicate unauthorized reconnaissance activities, by leveraging unique identifiers and alert data to pinpoint suspicious behavior.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the unique `host.id`, `user.id`, and `process.executable` involved in the alert.
-- Verify the legitimacy of the `process.executable` by checking its digital signature and comparing it against known good executables.
-- Cross-reference the `host.id` with asset management systems to gather information about the host, such as its role, owner, and recent changes or updates.
-- Investigate the `user.id` to determine if the user has a history of executing similar processes or if there are any anomalies in their recent activity.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes executed by the user on the host: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<user.id>') AND host = '<host.id>';`
-- Check for any recent logins or access attempts on the host that might correlate with the alert, focusing on unusual times or locations.
-- Analyze network traffic from the host around the time of the alert to identify any suspicious outbound connections or data exfiltration attempts.
-- Review historical alerts and logs to determine if there have been previous instances of similar unusual process executions on the same host or by the same user.
-- Consult threat intelligence sources to see if the `process.executable` or any related indicators have been associated with known threat actors or campaigns.
-- Document all findings and observations in a case management system to maintain a comprehensive record of the investigation for future reference.
-
-### False positive analysis
-
-- Known false positives for the Unusual Discovery Signal Alert with Unusual Process Executable rule may include legitimate administrative tools or scripts that perform system discovery tasks as part of routine operations. These can be flagged due to their atypical execution patterns or unique identifiers.
-- Users can manage these false positives by creating exceptions for known and trusted processes, users, or hosts that frequently trigger alerts. This can be done by adding specific host.id, user.id, or process.executable entries to an allowlist within the rule configuration.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness in detecting genuine threats.
-- Consider implementing a baseline of normal activity for your environment to better distinguish between legitimate and suspicious discovery activities, reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on unusual process executions and correlating with other security alerts.
-- Review user activity logs to determine if any legitimate user accounts have been compromised and reset passwords as necessary.
-- Analyze the unusual process executable to understand its origin and functionality, using threat intelligence sources to identify any known malicious signatures.
-- Remove any unauthorized or malicious software identified during the investigation from the affected systems.
-- Restore the system from a known good backup to ensure all traces of the compromise are removed.
-- Implement enhanced logging policies to capture detailed process execution and user activity data for future investigations.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and detection capabilities.
-- Escalate the incident to the appropriate internal teams and, if necessary, external authorities or cybersecurity partners for further analysis and response.
-- Review and update security policies and procedures to address any gaps identified during the incident, including implementing stricter access controls and regular security training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
index dce23e455c0..e80673b2bbd 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,48 +62,6 @@ process.parent.name: (
      "SolarwindsDiagnostics*.exe"
      )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Command Execution via SolarWinds Process
-
-SolarWinds is a suite of network and system management tools widely used in IT environments. Adversaries may exploit SolarWinds processes to execute unauthorized commands by spawning child processes like Cmd.exe or Powershell.exe, leveraging trusted SolarWinds executables to evade detection. The detection rule identifies suspicious activity by monitoring the initiation of these child processes from specific SolarWinds parent processes, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) using the `process.parent.name` field.
-- Check the `process.command_line` field for the suspicious child process to understand the exact command or script executed, which can provide insights into the intent of the execution.
-- Investigate the user account associated with the process execution by examining the `user.name` field to determine if the activity aligns with expected behavior for that account.
-- Correlate the timestamp of the event with other security logs to identify any concurrent suspicious activities or anomalies in the network or system.
-- Use Osquery to gather additional context about the parent process by running a query such as: `SELECT * FROM processes WHERE name LIKE 'SolarWinds%' AND pid = <parent_process_id>;` to retrieve details about the process state and its environment.
-- Examine historical data to determine if similar command executions have occurred previously from the same SolarWinds parent process, indicating a potential pattern or ongoing issue.
-- Analyze network traffic logs around the time of the event to identify any unusual outbound connections that may suggest data exfiltration or command-and-control communication.
-- Check for any recent changes or updates to the SolarWinds software that might explain the execution of the child process as part of legitimate operations.
-- Investigate the system for any signs of compromise, such as unauthorized changes to system files or configurations, which could indicate a broader security incident.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with exploiting SolarWinds processes in a similar manner.
-
-### False positive analysis
-
-- Routine administrative tasks: SolarWinds administrators may use Cmd.exe or Powershell.exe for legitimate configuration or maintenance tasks, leading to false positives. Users can create exceptions for known administrative activities by whitelisting specific user accounts or time frames.
-- Automated scripts: Scheduled scripts or automated processes that utilize Cmd.exe or Powershell.exe for system checks or updates might trigger alerts. To manage these, users can exclude specific scripts or processes by identifying their unique command-line arguments or execution patterns.
-- Software updates: During SolarWinds software updates, legitimate child processes may be spawned, which could be mistaken for suspicious activity. Users should monitor update schedules and temporarily adjust detection rules to accommodate these updates.
-- Third-party integrations: Some third-party tools integrated with SolarWinds may invoke Cmd.exe or Powershell.exe for data collection or reporting. Users can handle these by verifying the legitimacy of the third-party tool and excluding its known processes from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been affected.
-- Analyze the suspicious child processes (Cmd.exe or Powershell.exe) to understand the commands executed and assess potential damage or data exfiltration.
-- Review and collect relevant logs from SolarWinds and other security tools to gather evidence and understand the attack vector.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response coordination.
-- Remove any unauthorized or malicious scripts or executables identified during the investigation from the affected systems.
-- Apply patches and updates to SolarWinds and other software to mitigate known vulnerabilities and prevent similar attacks.
-- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate alerts.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and least privilege access, to strengthen defenses against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
index 65d99284cb2..1d85e3cce88 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -58,49 +58,6 @@ process where host.os.type == "windows" and event.type == "start" and
  ) and
  not process.executable : ("?:\\Windows\\SysWOW64\\ARP.EXE", "?:\\Windows\\SysWOW64\\lodctr.exe", "?:\\Windows\\SysWOW64\\unlodctr.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious SolarWinds Child Process
-
-SolarWinds is a widely used IT management software that operates critical network functions. Adversaries may exploit its trusted processes to execute unauthorized programs, bypassing security measures. The detection rule identifies unusual child processes spawned by SolarWinds' core executables, excluding known legitimate ones, to flag potential malicious activity. This approach leverages process behavior and code signature verification to detect anomalies indicative of compromise.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific child process was spawned by SolarWinds and verify if it matches any known legitimate processes.
-- Check the process code signature to determine if it is trusted or untrusted, focusing on the `process.code_signature.trusted` field.
-- Investigate the parent process details, specifically `SolarWinds.BusinessLayerHost.exe` or `SolarWinds.BusinessLayerHostx64.exe`, to confirm its legitimacy and recent activity.
-- Examine the process executable path using the `process.executable` field to ensure it is not located in suspicious directories.
-- Utilize Osquery to gather additional context on the suspicious process. Example query: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve detailed information about the process.
-- Cross-reference the suspicious process with known threat intelligence sources to identify if it is associated with any known malicious activity.
-- Analyze the process command line arguments to identify any unusual or unexpected parameters that could indicate malicious intent.
-- Review recent system logs and events around the time of the alert to identify any correlated activities or anomalies.
-- Investigate network connections initiated by the suspicious process to detect any unauthorized or suspicious outbound communication.
-- Check for any recent changes or updates to the SolarWinds software that could explain the unusual child process behavior, ensuring it aligns with legitimate updates or patches.
-
-### False positive analysis
-
-- Known false positives may include legitimate SolarWinds processes that are not yet included in the exclusion list. These can occur when new SolarWinds updates introduce additional child processes that are not recognized by the current rule.
-- Users can handle these false positives by monitoring the detected processes and verifying their legitimacy through process code signature checks. If a process is confirmed to be non-threatening, it can be added to the exclusion list to prevent future alerts.
-- Another potential false positive source is third-party integrations or plugins that interact with SolarWinds processes. Users should verify these integrations and, if deemed safe, update the rule to exclude these specific child processes.
-- Regularly review and update the exclusion list to include new legitimate processes as SolarWinds software evolves. This proactive approach helps minimize false positives while maintaining security vigilance.
-- Consider implementing a logging mechanism to track and review all flagged processes over time. This can help identify patterns and refine the exclusion criteria to better distinguish between benign and suspicious activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the suspicious child process to determine its origin and intent, using forensic tools to analyze process execution and network connections.
-- Verify the integrity of SolarWinds software and its components by checking for unauthorized modifications or tampering.
-- Terminate any unauthorized or suspicious processes identified during the investigation to contain the threat.
-- Review and update security policies to ensure that only legitimate child processes are allowed to execute under SolarWinds parent processes.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger campaign.
-- Implement enhanced logging and monitoring for SolarWinds processes and related network activity to detect future anomalies.
-- Restore the system to its operational state by applying clean backups and ensuring all software is up to date with the latest security patches.
-- Conduct a post-incident review to identify gaps in security controls and improve response strategies.
-- Harden the environment by implementing least privilege access controls, regular software audits, and continuous security awareness training for staff."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_com_object_xwizard.toml b/rules/windows/execution_com_object_xwizard.toml
index ade95978e37..d0f0f60ae02 100644
--- a/rules/windows/execution_com_object_xwizard.toml
+++ b/rules/windows/execution_com_object_xwizard.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,49 +66,6 @@ process where host.os.type == "windows" and event.type == "start" and
    )
  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution of COM object via Xwizard
-
-The Windows Component Object Model (COM) facilitates communication between software components. Adversaries exploit this by using Xwizard to execute COM objects, bypassing security measures. The detection rule identifies suspicious Xwizard executions by checking for unusual arguments or non-standard executable paths, indicating potential misuse for malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `xwizard.exe` in the process name or original file name fields, as this is the primary indicator of potential misuse.
-- Examine the process arguments to check for the presence of "RunWizard" and GUID-like patterns (e.g., "{*}"), which may indicate an attempt to execute a COM object.
-- Verify the executable path of `xwizard.exe` to determine if it deviates from standard paths such as "C:\\Windows\\SysWOW64\\xwizard.exe" or "C:\\Windows\\System32\\xwizard.exe", which could suggest tampering or unauthorized use.
-- Investigate the parent process of `xwizard.exe` to understand how it was launched and identify any potentially malicious parent processes.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'xwizard.exe';` to retrieve details like process ID, parent process ID, and command line arguments.
-- Check the system's event logs for any related entries around the time of the alert to identify other suspicious activities or corroborating evidence.
-- Analyze the registry for any unusual or unauthorized COM objects that may have been created or modified, focusing on recent changes.
-- Investigate network connections initiated by `xwizard.exe` to identify any suspicious outbound communication that could indicate data exfiltration or command-and-control activity.
-- Review the user account associated with the `xwizard.exe` process to determine if it has been compromised or is being used in an unauthorized manner.
-- Correlate the findings with other security alerts or incidents in the environment to identify potential patterns or coordinated attacks.
-
-### False positive analysis
-
-- Legitimate administrative tasks: Xwizard.exe may be used by system administrators for legitimate configuration tasks, which can trigger the detection rule. Users should verify the context of the execution to determine if it aligns with routine administrative activities.
-- Software installations or updates: Some software installations or updates might invoke Xwizard.exe as part of their setup process. Users can create exceptions for known software that frequently triggers this rule during installation or updates.
-- System maintenance scripts: Automated scripts for system maintenance might use Xwizard.exe to perform legitimate operations. Users should review these scripts and whitelist them if they are verified as non-threatening.
-- Custom enterprise applications: In some environments, custom applications may use Xwizard.exe for inter-process communication. Users should document these applications and exclude their known behaviors from triggering the rule.
-- To manage false positives, users can create exceptions in their detection systems for specific processes or paths that are verified as safe. This can be done by adding these known benign activities to an allowlist or exclusion list, ensuring that only truly suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on the execution of the COM object via Xwizard and any associated processes or files.
-- Terminate any suspicious processes related to Xwizard that are not running from standard executable paths.
-- Review and analyze the Windows Event Logs and any available security logs for additional indicators of compromise or related suspicious activities.
-- Restore the system from a known good backup if the investigation confirms malicious activity and system integrity is compromised.
-- Update and apply security patches to the operating system and all installed software to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on recognizing and reporting suspicious activities to prevent future incidents and improve overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_command_shell_started_by_unusual_process.toml b/rules/windows/execution_command_shell_started_by_unusual_process.toml
index 29e787c3804..437d881b36d 100644
--- a/rules/windows/execution_command_shell_started_by_unusual_process.toml
+++ b/rules/windows/execution_command_shell_started_by_unusual_process.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -58,48 +58,6 @@ process where host.os.type == "windows" and event.type == "start" and
                          "wlanext.exe" ) and
   not (process.parent.name : "dllhost.exe" and process.parent.args : "/Processid:{CA8C87C1-929D-45BA-94DB-EF8E6CB346AD}")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Parent Process for cmd.exe
-
-The cmd.exe process is a command-line interpreter in Windows environments, often used for legitimate administrative tasks. However, adversaries can exploit it by launching it from atypical parent processes to execute malicious commands stealthily. The detection rule identifies such anomalies by flagging cmd.exe instances spawned by uncommon parent processes, which may indicate unauthorized or suspicious activity, thus helping analysts pinpoint potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of cmd.exe being spawned by an unusual parent process as specified in the detection rule.
-- Verify the legitimacy of the parent process by checking its usual behavior and purpose within the environment. Cross-reference with known software documentation or internal process baselines.
-- Examine the command-line arguments used by the parent process to launch cmd.exe, if available, to identify any suspicious or unexpected commands.
-- Investigate the user account associated with the process execution to determine if it aligns with expected usage patterns or if it might be compromised.
-- Check the process creation time and correlate it with other security events or logs to identify any concurrent suspicious activities.
-- Utilize Osquery to gather additional context about the parent process. For example, run the following query to list details about the parent process: `SELECT * FROM processes WHERE name = 'unusual_parent_process_name';`
-- Analyze network connections initiated by the cmd.exe process to identify any unusual or unauthorized external communications.
-- Review recent changes or updates to the system that might have introduced new or altered processes, potentially explaining the unusual parent-child relationship.
-- Investigate any file modifications or registry changes made by the cmd.exe process to assess potential malicious actions.
-- Consult threat intelligence sources to determine if the unusual parent process is associated with known malware or attack techniques.
-
-### False positive analysis
-
-- Certain legitimate applications or system processes may occasionally spawn cmd.exe for valid reasons, leading to false positives. For example, software updates or system maintenance tasks might trigger cmd.exe from processes like GoogleUpdate.exe or FlashPlayerUpdateService.exe.
-- Automated scripts or administrative tools that are scheduled to run at specific times might also cause cmd.exe to be launched by processes such as taskhostw.exe or sppsvc.exe, which are typically benign.
-- Users can manage these false positives by creating exceptions for known and verified processes that frequently trigger cmd.exe in a non-threatening manner. This can be done by adding specific process names or command-line arguments to an exclusion list within the detection rule.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and any changes in legitimate software behavior, thus minimizing the risk of overlooking genuine threats while reducing noise from false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the unusual parent process that spawned cmd.exe.
-- Review and analyze logs from the affected system and any related systems to trace the attacker's actions and identify any additional compromised systems.
-- Terminate any malicious processes and remove any unauthorized files or scripts identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Implement enhanced logging policies to capture detailed process creation events and parent-child process relationships for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as application whitelisting, least privilege access, and regular security awareness training to reduce the risk of similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_command_shell_via_rundll32.toml b/rules/windows/execution_command_shell_via_rundll32.toml
index 4f2fe2dfc1b..f19d1e775db 100644
--- a/rules/windows/execution_command_shell_via_rundll32.toml
+++ b/rules/windows/execution_command_shell_via_rundll32.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,50 +42,6 @@ process where host.os.type == "windows" and event.type == "start" and
   not process.parent.args : ("C:\\Windows\\System32\\SHELL32.dll,RunAsNewUser_RunDLL",
                              "C:\\WINDOWS\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Command Shell Activity Started via RunDLL32
-
-RunDLL32 is a Windows utility that executes functions within DLLs, often used for legitimate purposes. However, attackers exploit it to run malicious scripts or commands by invoking command shells like cmd.exe or PowerShell. The detection rule identifies suspicious activity by monitoring processes initiated by RunDLL32, excluding known benign patterns, to flag potential misuse aligned with MITRE ATT&CK's execution tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `cmd.exe` or `powershell.exe` processes initiated by `rundll32.exe` and verify that the `process.parent.command_line` is not null.
-- Examine the `process.parent.command_line` field to understand the context in which `rundll32.exe` was executed, looking for any unusual or suspicious command-line arguments.
-- Check the `process.parent.args` field to ensure that the command line does not match known benign patterns, such as those involving `SHELL32.dll` or temporary files.
-- Investigate the parent process of `rundll32.exe` to determine how it was launched and whether it was initiated by a legitimate application or user action.
-- Use Osquery to gather additional context about the process tree. For example, run the following query to list processes related to the suspicious activity:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cmd.exe', 'powershell.exe') AND parent IN (SELECT pid FROM processes WHERE name = 'rundll32.exe');
-  ```
-- Analyze the timeline of events leading up to the alert to identify any preceding activities that might indicate compromise, such as suspicious file downloads or registry changes.
-- Correlate the alert with other security events or logs, such as network traffic or file access logs, to identify any related indicators of compromise.
-- Check for any recent changes in the system, such as new software installations or updates, that might explain the execution of `rundll32.exe` with command shells.
-- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised.
-- Review historical data to see if similar alerts have been triggered in the past, which could indicate a recurring issue or persistent threat.
-
-### False positive analysis
-
-- Known false positives for the Command Shell Activity Started via RunDLL32 rule include legitimate system or application processes that invoke command shells for routine operations. For example, certain software installations or updates may use RunDLL32 to execute scripts as part of their setup process.
-- Users can manage these false positives by identifying and excluding frequent non-threatening behaviors. This can be done by adding exceptions to the detection rule for specific command line arguments or parent process command lines that are known to be safe. For instance, excluding command lines that match patterns like "C:\\\\Windows\\\\System32\\\\SHELL32.dll,RunAsNewUser_RunDLL" or "C:\\\\WINDOWS\\\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc" can help reduce noise from benign activities.
-- It is important to regularly review and update these exceptions to ensure they align with the current environment and do not inadvertently allow malicious activity to go undetected.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the rundll32.exe process and its command line arguments to determine if the activity is malicious.
-- Review recent system changes and user activity logs to identify any unauthorized access or modifications.
-- If malicious activity is confirmed, terminate the suspicious processes and remove any associated malicious files or scripts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process creation events and command line arguments for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics and techniques.
-- Restore the system to its operational state by applying the latest security patches and updates, and conducting a full system scan with updated antivirus software.
-- Educate users on recognizing and reporting suspicious activities to prevent future incidents.
-- Implement system hardening measures, such as restricting the use of rundll32.exe to authorized applications and users, and applying application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
index 47e464e0ffb..1fe398d770d 100644
--- a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
+++ b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -63,49 +63,6 @@ sequence by process.parent.entity_id with maxspan=1m
                      "?:\\Users\\*\\AppData\\Local\\Temp\\QBTools\\"))
     ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Delayed Execution via Ping
-
-Ping is a network utility used to test connectivity and measure response times. Adversaries exploit it for delayed execution by using it to introduce pauses in scripts, often to evade detection. The detection rule identifies suspicious use of ping with specific arguments, followed by execution of potentially malicious utilities, indicating an attempt to stealthily execute harmful payloads.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the specific process names and arguments involved, such as "ping.exe" with the "-n" argument and the subsequent execution of suspicious utilities like "rundll32.exe" or "powershell.exe".
-- Examine the parent process information, particularly focusing on "cmd.exe", to determine how the ping command was initiated and whether it aligns with typical user behavior or automated scripts.
-- Investigate the user account associated with the process execution, especially if the user ID is not "S-1-5-18", to assess whether the activity is expected for that user or indicative of compromised credentials.
-- Check the process execution timeline to identify any patterns or sequences that suggest a coordinated attack, using the maxspan=1m parameter to focus on closely timed events.
-- Utilize Osquery to gather additional context on the involved processes. For example, run the following query to list all processes executed by the same user within a short timeframe: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE user = '<user_id>' AND start_time > datetime('now', '-5 minutes');`
-- Analyze the command line arguments of the suspicious processes to identify any encoded or obfuscated commands that may indicate malicious intent.
-- Investigate the file paths and code signatures of the executed processes, especially those in user directories like "?:\\\\Users\\\\*\\\\AppData\\\\*.exe", to determine if they are trusted or potentially malicious.
-- Review the system's event logs for any additional indicators of compromise or related suspicious activity, such as failed login attempts or unusual network connections.
-- Cross-reference the alert with known threat intelligence sources to identify if the observed behavior matches any known attack patterns or malware signatures.
-- Document all findings and observations, including any anomalies or deviations from normal behavior, to support further analysis and potential escalation.
-
-### False positive analysis
-
-- Scheduled tasks or legitimate administrative scripts may use ping for delay purposes, leading to false positives. Users can handle this by identifying and excluding these specific scripts or tasks from the detection rule.
-- Software installers or updaters might use ping to introduce delays during installation processes. Users should monitor and whitelist these known installers to prevent unnecessary alerts.
-- Network troubleshooting tools or scripts executed by IT personnel could trigger the rule. It's advisable to create exceptions for these tools when used by trusted users or within specific environments.
-- Automated testing environments might use ping to simulate network conditions, which could be mistaken for malicious activity. Users can exclude these environments or specific test scripts from the rule.
-- Some legitimate applications might use ping as part of their normal operation, especially in network-heavy applications. Users should identify these applications and adjust the rule to exclude them based on their process signatures or paths.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise, focusing on the processes and files executed after the ping command.
-- Terminate any malicious processes identified during the investigation to stop ongoing threats.
-- Remove or quarantine any malicious files or scripts found on the system to prevent re-execution.
-- Review and analyze logs from the affected system and network devices to understand the scope and timeline of the attack, leveraging MITRE ATT&CK T1059 for context on command and scripting interpreter techniques.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger campaign or if sensitive data may have been compromised.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring that security configurations align with best practices to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_downloaded_shortcut_files.toml b/rules/windows/execution_downloaded_shortcut_files.toml
index 00d1470d608..43fbff23e7a 100644
--- a/rules/windows/execution_downloaded_shortcut_files.toml
+++ b/rules/windows/execution_downloaded_shortcut_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/06"
 
 [rule]
 author = ["Elastic"]
@@ -31,49 +31,6 @@ type = "eql"
 query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension == "lnk" and file.Ext.windows.zone_identifier > 1
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Downloaded Shortcut Files
-
-Shortcut files (.lnk) are used in Windows environments to link to executable files or scripts, streamlining user access. Adversaries exploit this by embedding malicious commands in .lnk files, often delivered via phishing, to execute unauthorized actions. The detection rule identifies .lnk files created on Windows systems with a zone identifier indicating they were downloaded, flagging potential phishing attempts.
-
-### Possible investigation steps
-
-- Verify the alert by checking the file creation event details, focusing on the `file.extension` and `file.Ext.windows.zone_identifier` fields to confirm the presence of a downloaded .lnk file.
-- Examine the file path and name to determine if it matches known malicious patterns or if it appears suspicious or unusual for the user or system.
-- Review the user account associated with the file creation event to assess if the activity aligns with their typical behavior or if it appears anomalous.
-- Investigate the source of the download by analyzing network logs or browser history to identify the URL or IP address from which the .lnk file was downloaded.
-- Use Osquery to gather additional context about the .lnk file. For example, run the following query to list all .lnk files in the user's Downloads directory: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%.lnk';`
-- Check the file hash against threat intelligence databases or a service like VirusTotal to determine if the .lnk file is associated with known malware.
-- Analyze the contents of the .lnk file to identify any embedded commands or scripts that could indicate malicious intent.
-- Review recent email logs for the user to identify any phishing emails that may have delivered the .lnk file as an attachment or link.
-- Correlate the event with other security alerts or logs from the same timeframe to identify any related suspicious activities or patterns.
-- Consult with the user to verify if they recall downloading the file and if they can provide any context or details about its origin.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they include .lnk files downloaded from trusted sources. Users should verify the source and context of the download to determine if it is a false positive.
-- Corporate environments often use remote desktop or file-sharing services that might download .lnk files as part of routine operations. Users can create exceptions for known and trusted services to reduce noise.
-- Some web browsers or email clients may download .lnk files as part of their normal operation, especially if configured to save shortcuts for frequently accessed sites or applications. Users should review browser or email client settings and consider excluding these specific applications if they are known to be safe.
-- Automated scripts or tools that download and create .lnk files for legitimate purposes, such as system maintenance or monitoring, can be excluded by identifying the specific processes or scripts involved and adding them to an exception list.
-- Users should regularly review and update their exception lists to ensure that only verified and non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Analyze the .lnk file to determine the embedded command or script and assess its impact.
-- Check for any unauthorized changes or execution of malicious payloads on the system.
-- Remove the malicious .lnk file and any associated malware or unauthorized software.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools.
-- Review user activity logs to identify how the .lnk file was downloaded and if any other systems are affected.
-- Escalate the incident to the security team if the threat is part of a larger campaign or if multiple systems are compromised.
-- Implement or update email filtering and web proxy rules to block similar phishing attempts in the future.
-- Enhance logging policies to capture detailed file creation and execution events for better future detection.
-- Restore the system from a clean backup if necessary and apply security patches and updates to harden the system against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_downloaded_url_file.toml b/rules/windows/execution_downloaded_url_file.toml
index fa688e40028..8b72e8d4a46 100644
--- a/rules/windows/execution_downloaded_url_file.toml
+++ b/rules/windows/execution_downloaded_url_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/06"
 
 [rule]
 author = ["Elastic"]
@@ -32,48 +32,6 @@ query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension == "url"
    and file.Ext.windows.zone_identifier > 1 and not process.name : "explorer.exe"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Downloaded URL Files
-URL shortcut files, typically used to link to web resources, can be exploited by adversaries in phishing attacks to execute malicious content. These files, when downloaded from external sources, may bypass traditional security measures. The detection rule identifies such files created on Windows systems, excluding those initiated by the Explorer process, and flags them if they originate from non-local zones, indicating potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file extension is ".url" and verify the event type is "creation" on a Windows host.
-- Check the file.Ext.windows.zone_identifier field to determine the zone from which the file was downloaded, ensuring it is greater than 1, indicating a non-local source.
-- Investigate the process that created the .url file by examining the process.name field, ensuring it is not "explorer.exe" to rule out legitimate user activity.
-- Use Osquery to list all .url files on the system with the following query: `SELECT path, filename, size, atime, mtime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%.url';` to identify any other potentially suspicious files.
-- Correlate the creation time of the .url file with user activity logs to determine if the file was created during normal working hours or during unusual times.
-- Analyze network logs to identify any outbound connections made by the system around the time the .url file was created, focusing on connections to unfamiliar or suspicious domains.
-- Check the file's metadata and properties to gather additional context, such as the target URL and any embedded scripts or commands.
-- Investigate the user account associated with the creation of the .url file to determine if there are any signs of compromise or unusual behavior.
-- Review email logs or web browsing history to identify potential phishing emails or websites that could have led to the download of the .url file.
-- Cross-reference the identified URL with threat intelligence sources to determine if it is associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- Legitimate software updates or installations may download .url files as part of their process, which could trigger the rule. Users should verify the source and context of these files to determine if they are part of a trusted application.
-- Corporate environments might use .url files for internal shortcuts or links to intranet resources. These should be reviewed and, if deemed safe, added to an exception list to prevent future alerts.
-- Some web browsers or download managers may create .url files as part of their download process. Users can monitor these applications and exclude them if they consistently generate non-malicious .url files.
-- Automated scripts or tools that interact with web resources might inadvertently create .url files. Users should assess these scripts and, if they are part of routine operations, consider excluding them from the detection rule.
-- To manage false positives, users can create exceptions based on file paths, specific processes, or known safe sources, ensuring that only unexpected or suspicious .url file creations are flagged.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Analyze the .url file to determine its origin and the URL it points to, checking for known malicious domains or IP addresses.
-- Review user activity logs to identify any execution of the .url file and any subsequent suspicious behavior.
-- Remove the .url file and any associated malicious files or processes from the system.
-- Conduct a full antivirus and anti-malware scan on the affected system to ensure no additional threats are present.
-- Restore the system from a known good backup if any critical system files or configurations have been altered.
-- Report the incident to the security team and escalate to management if the threat is part of a larger campaign or if sensitive data may have been compromised.
-- Implement enhanced logging policies to capture detailed file creation and process execution events for future investigations.
-- Integrate threat intelligence feeds to automatically update detection rules with known malicious URLs and domains.
-- Educate users on recognizing phishing attempts and the risks associated with downloading and executing files from untrusted sources."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_enumeration_via_wmiprvse.toml b/rules/windows/execution_enumeration_via_wmiprvse.toml
index 900bdac5f56..dce7b4392db 100644
--- a/rules/windows/execution_enumeration_via_wmiprvse.toml
+++ b/rules/windows/execution_enumeration_via_wmiprvse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,56 +61,6 @@ process where host.os.type == "windows" and event.type == "start" and process.co
   ) and
   not process.args : "tenable_mw_scan"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Enumeration Command Spawned via WMIPrvSE
-
-Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute enumeration commands stealthily, leveraging the WMI Provider Service (WMIPrvSE) to gather system and network information. The detection rule identifies suspicious processes initiated by WMIPrvSE, focusing on common enumeration tools, while excluding benign operations, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and command line arguments that triggered the alert, focusing on the `process.name` and `process.command_line` fields.
-- Verify the parent process by examining the `process.parent.name` field to ensure it is indeed `wmiprvse.exe`, confirming the use of WMI for process execution.
-- Check the timestamp of the event to determine when the suspicious process was started, which can help correlate with other activities on the system.
-- Investigate the user context under which the process was executed by reviewing the `user.name` field to identify if it was run under a privileged account.
-- Examine the network connections and activities around the time of the alert to identify any unusual outbound connections or data exfiltration attempts.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list processes with their parent process details:
-  ```sql
-  SELECT p.pid, p.name, p.cmdline, p.parent, pp.name AS parent_name, pp.cmdline AS parent_cmdline 
-  FROM processes p 
-  JOIN processes pp ON p.parent = pp.pid 
-  WHERE p.name IN ("arp.exe", "dsquery.exe", "dsget.exe", "gpresult.exe", "hostname.exe", "ipconfig.exe", "nbtstat.exe", "net.exe", "net1.exe", "netsh.exe", "netstat.exe", "nltest.exe", "ping.exe", "qprocess.exe", "quser.exe", "qwinsta.exe", "reg.exe", "sc.exe", "systeminfo.exe", "tasklist.exe", "tracert.exe", "whoami.exe") 
-  AND pp.name = "wmiprvse.exe";
-  ```
-- Correlate the event with other security logs, such as Windows Event Logs, to identify any related suspicious activities or anomalies.
-- Investigate the system's recent changes or configurations that might have allowed the execution, such as new software installations or changes in WMI settings.
-- Check for any known vulnerabilities or exploits related to WMI that might have been used by adversaries to execute the command.
-- Document all findings and observations to build a comprehensive understanding of the incident, which can aid in further analysis and reporting.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use WMI to execute legitimate enumeration commands for system management and troubleshooting, which can trigger this rule. To manage this, users can create exceptions for known administrative accounts or specific command patterns that are regularly used in their environment.
-- Monitoring and management software: Some security and network management tools use WMI to gather system information, which may appear as suspicious activity. Users should identify these tools and exclude their processes or command lines from the rule to prevent false positives.
-- Automated scripts and scheduled tasks: Scripts or scheduled tasks that perform regular system checks or updates might use WMI for enumeration. Users can handle these by excluding specific scripts or task names that are verified as non-threatening.
-- Software updates and installations: Certain software installations or updates might use WMI to check system compatibility or network settings. Users should monitor these activities and exclude known update processes to avoid unnecessary alerts.
-- Security scans: Security tools like vulnerability scanners may use WMI to collect data, which can be mistaken for malicious activity. Users should whitelist these tools by excluding their specific command lines or process names from the detection rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on processes initiated by WMIPrvSE and any suspicious enumeration activity.
-- Terminate any malicious processes identified during the investigation to halt ongoing adversary actions.
-- Review and analyze logs from the affected system and related network devices to trace the adversary's activities and identify any additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process creation events and WMI activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting WMI access to authorized users only and disabling unnecessary WMI components to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_initial_access_foxmail_exploit.toml b/rules/windows/execution_initial_access_foxmail_exploit.toml
index 26bdda59cff..7a82513cf24 100644
--- a/rules/windows/execution_initial_access_foxmail_exploit.toml
+++ b/rules/windows/execution_initial_access_foxmail_exploit.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "m3
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 
 [rule]
 author = ["Elastic"]
@@ -53,48 +53,6 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and 
  process.parent.name : "Foxmail.exe" and process.args : ("?:\\Users\\*\\AppData\\*", "\\\\*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Foxmail Exploitation
-
-Foxmail, a popular email client, manages emails and attachments, storing temporary files in specific directories. Adversaries may exploit vulnerabilities in Foxmail to execute malicious payloads by manipulating these temp files. The detection rule identifies suspicious child processes initiated by Foxmail, focusing on those accessing temp directories, which may indicate exploitation attempts for unauthorized execution.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a child process spawned by Foxmail.exe, focusing on the process arguments that point to the temp directories (e.g., `?:\\Users\\*\\AppData\\*`).
-- Verify the legitimacy of the parent process by checking the hash and signature of Foxmail.exe to ensure it hasn't been tampered with.
-- Use Osquery to list all processes spawned by Foxmail.exe to identify any unusual or unexpected child processes. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'Foxmail.exe');`
-- Investigate the specific child process identified in the alert by examining its command line arguments and execution path for any anomalies or suspicious patterns.
-- Check the file creation and modification times in the temp directories accessed by the suspicious process to identify any recent changes that coincide with the alert.
-- Analyze the network activity of the suspicious process to detect any unusual outbound connections that could indicate data exfiltration or command and control communication.
-- Correlate the alert with other security events or logs, such as email gateway logs, to determine if a malicious email was received around the time of the alert.
-- Review the user account associated with the Foxmail process to determine if there are any signs of compromise or unauthorized access.
-- Examine the system for any additional indicators of compromise, such as registry changes, scheduled tasks, or persistence mechanisms that may have been established by the malicious process.
-- Consult threat intelligence sources to identify if the observed behavior matches any known exploitation techniques or campaigns targeting Foxmail vulnerabilities.
-
-### False positive analysis
-
-- Routine software updates or legitimate plugins for Foxmail may trigger the detection rule by spawning child processes that access temporary directories. These updates or plugins often require temporary file storage and execution, which can mimic the behavior of exploitation attempts.
-- Automated backup or synchronization tools that interact with Foxmail's temporary files might also be flagged as suspicious. These tools often access and modify files in the temp directories as part of their normal operation.
-- Users can manage these false positives by creating exceptions for known legitimate processes or tools that frequently interact with Foxmail's temp directories. This can be done by identifying the specific process names or paths and excluding them from the detection rule.
-- Monitoring the frequency and context of the alerts can help distinguish between benign and potentially malicious activities. If a process consistently triggers alerts but is verified as safe, it can be added to an allowlist to prevent future false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential exploitation.
-- Conduct a thorough investigation of the affected system to identify any malicious processes or files, focusing on the Foxmail temp directories.
-- Terminate any suspicious child processes spawned by Foxmail and delete any malicious files identified during the investigation.
-- Review email logs and quarantine any suspicious emails that may have been the source of the exploitation attempt.
-- Apply the latest security patches and updates to Foxmail and the operating system to mitigate known vulnerabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and file access events, particularly for email clients and temp directories.
-- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging threats related to email client vulnerabilities.
-- Restore the system to its operational state by reinstalling Foxmail and restoring any affected files from clean backups.
-- Conduct a security awareness training session for users to recognize and report suspicious emails, reducing the risk of future exploitation attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_initial_access_wps_dll_exploit.toml b/rules/windows/execution_initial_access_wps_dll_exploit.toml
index 05f3e7a5cc4..499d310019c 100644
--- a/rules/windows/execution_initial_access_wps_dll_exploit.toml
+++ b/rules/windows/execution_initial_access_wps_dll_exploit.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,49 +50,6 @@ any where host.os.type == "windows" and process.name : "promecefpluginhost.exe"
       "\\Device\\Mup\\**", "\\\\*"))
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WPS Office Exploitation via DLL Hijack
-
-DLL hijacking in WPS Office involves adversaries exploiting the ksoqing protocol handler to load malicious libraries via the promecefpluginhost.exe process. Attackers may leverage this to execute arbitrary code by placing a rogue DLL in specific directories or network paths. The detection rule identifies suspicious library loads and process actions, focusing on paths indicative of exploitation attempts, thus alerting analysts to potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `promecefpluginhost.exe` process and verify the suspicious DLL path matches the patterns specified in the detection rule.
-- Check the event category to determine if the alert was triggered by a library load or a process action, as this will guide the focus of the investigation.
-- Investigate the specific DLL path involved in the alert, especially if it matches `?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*`, `\\Device\\Mup\\**`, or `\\\\*`, to identify any unauthorized or unexpected files.
-- Use Osquery to list all DLLs loaded by `promecefpluginhost.exe` to identify any anomalies. Example query: `SELECT path FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE name = 'promecefpluginhost.exe';`
-- Examine the network connections of `promecefpluginhost.exe` to identify any unusual or suspicious external communications that may indicate data exfiltration or command-and-control activity.
-- Correlate the alert with other security events or logs to identify any related activities or patterns, such as other processes or files accessed around the same time.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Check for any recent changes or updates to WPS Office that might have introduced vulnerabilities or been exploited by attackers.
-- Analyze the system for any other signs of compromise, such as unexpected registry changes, scheduled tasks, or startup items that could indicate persistence mechanisms.
-- Review historical data to determine if similar alerts have been triggered in the past, which could indicate a recurring issue or ongoing attack campaign.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they temporarily load libraries from network paths or temporary directories, which are common behaviors for some applications.
-- Network drives or shared folders accessed by WPS Office for legitimate purposes might be flagged, especially in environments where network resources are frequently used for document storage and collaboration.
-- Users can manage these false positives by creating exceptions for known safe directories or network paths that are regularly accessed by WPS Office, ensuring these paths are documented and monitored for any changes in behavior.
-- Regularly review and update the list of exceptions to accommodate new legitimate software or changes in network infrastructure, maintaining a balance between security and operational efficiency.
-- Consider implementing additional context checks, such as verifying the digital signature of loaded libraries, to differentiate between legitimate and potentially malicious activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to confirm the presence of malicious DLLs in the specified directories or network paths.
-- Utilize endpoint detection and response (EDR) tools to analyze the behavior of the promecefpluginhost.exe process and identify any additional malicious activities.
-- Remove any identified malicious DLLs and associated files from the system to prevent further execution.
-- Apply patches or updates to WPS Office to address vulnerabilities CVE-2024-7262 and CVE-2024-7263, ensuring the software is up to date.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process and library load events, focusing on suspicious paths and activities.
-- Integrate threat intelligence feeds to improve detection capabilities and stay informed about emerging threats related to DLL hijacking.
-- Restore the system to its operational state by verifying the integrity of system files and ensuring no unauthorized changes have been made.
-- Harden the system by restricting write permissions to critical directories and implementing application whitelisting to prevent unauthorized DLL loads."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_mofcomp.toml b/rules/windows/execution_mofcomp.toml
index 89077b148fb..be4fb305278 100644
--- a/rules/windows/execution_mofcomp.toml
+++ b/rules/windows/execution_mofcomp.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "m365_defender", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 
 [rule]
 author = ["Elastic"]
@@ -47,48 +47,6 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Mofcomp Activity
-
-Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and instances for Windows Management Instrumentation (WMI). Adversaries exploit this by creating malicious MOF files to manipulate WMI for persistence or execution. The detection rule identifies suspicious mofcomp.exe executions, excluding legitimate system processes, to flag potential misuse by attackers.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "mofcomp.exe" and verify the presence of suspicious arguments matching "*.mof".
-- Check the user ID associated with the process execution to ensure it is not "S-1-5-18", which corresponds to the Local System account, indicating potential misuse by a non-system user.
-- Investigate the parent process of "mofcomp.exe" to determine if it is "ScenarioEngine.exe" and verify if the arguments match any of the known legitimate paths, such as "*\\\\MSSQL\\\\Binn\\\\*.mof", to rule out false positives.
-- Examine the timeline of events leading up to the mofcomp.exe execution to identify any preceding suspicious activities or processes.
-- Utilize Osquery to gather additional context on the mofcomp.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'mofcomp.exe';` to retrieve details like process ID, parent process ID, and command line arguments.
-- Cross-reference the mofcomp.exe execution with recent changes in the WMI repository to identify any new or modified namespaces and classes.
-- Analyze the network activity of the host around the time of the mofcomp.exe execution to detect any unusual outbound connections that might indicate data exfiltration or command and control communication.
-- Review the security logs for any recent login attempts or privilege escalation activities that could be related to the mofcomp.exe execution.
-- Check for any scheduled tasks or WMI Event Subscriptions that might have been created or modified around the time of the alert to establish persistence.
-- Investigate other hosts within the same network segment for similar mofcomp.exe activity to determine if the threat is isolated or part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use mofcomp.exe for legitimate purposes, such as compiling MOF files for system management or configuration tasks. These activities can be mistaken for malicious behavior.
-- SQL Server installations: During the installation or maintenance of Microsoft SQL Server, mofcomp.exe may be executed to compile MOF files related to SQL Server components. This is a common and expected behavior.
-- ScenarioEngine.exe interactions: Processes initiated by ScenarioEngine.exe that involve MOF files in specific directories related to SQL Server or OLAP services are typically benign and should be excluded from alerts.
-- To manage false positives, users can create exceptions in the detection rule by specifying known benign parent processes or directories associated with legitimate MOF file compilations. This helps in reducing noise and focusing on truly suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any malicious MOF files and determine the scope of the compromise, focusing on WMI namespaces and classes.
-- Terminate any suspicious processes related to mofcomp.exe that are not part of legitimate system operations.
-- Remove any unauthorized MOF files and restore the WMI repository to a known good state using backups or system restore points.
-- Review and update security policies to restrict the execution of mofcomp.exe to only trusted administrators and processes.
-- Implement enhanced logging for WMI activities and mofcomp.exe executions to improve detection of future suspicious activities.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze related threat indicators.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited by similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update the incident response plan to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_posh_hacktool_authors.toml b/rules/windows/execution_posh_hacktool_authors.toml
index 86da75fd610..40c31c3be42 100644
--- a/rules/windows/execution_posh_hacktool_authors.toml
+++ b/rules/windows/execution_posh_hacktool_authors.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/08"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,50 +80,6 @@ host.os.type:windows and event.category:process and
       "splinter_code"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential PowerShell HackTool Script by Author
-
-PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities to execute malicious scripts, often leveraging well-known offensive tools without altering author identifiers. The detection rule identifies these scripts by scanning for specific author names linked to popular hacking tools, thus flagging potential misuse of PowerShell for malicious activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific author name detected in the PowerShell script, as this can provide insight into the potential tool or script being used.
-- Examine the `powershell.file.script_block_text` field in the event logs to analyze the script content for any suspicious or malicious commands.
-- Check the `event.category:process` field to identify the process that executed the PowerShell script, including the parent process, to understand the context of execution.
-- Investigate the `host.os.type:windows` field to confirm the affected host and gather additional system information such as hostname, IP address, and user context.
-- Use Osquery to gather more information about the process and its parent process. Example query: `SELECT * FROM processes WHERE name = 'powershell.exe';`
-- Correlate the detected author name with known offensive tools and techniques to assess the potential impact and intent of the script.
-- Review recent login events and user activity on the affected host to identify any unauthorized access or anomalies around the time the script was executed.
-- Check for any network connections initiated by the PowerShell process to external IP addresses, which may indicate data exfiltration or command-and-control communication.
-- Analyze other security logs and alerts from the same timeframe to identify any related or supporting indicators of compromise.
-- Consult threat intelligence sources to determine if the detected author or script is associated with any known threat actors or campaigns.
-
-### False positive analysis
-
-- Legitimate security researchers or IT administrators may use PowerShell scripts authored by well-known security experts for educational purposes or internal security assessments, leading to false positives.
-- Organizations that conduct regular red team exercises might have authorized scripts containing these author identifiers, which could be mistakenly flagged as malicious.
-- PowerShell scripts used in penetration testing environments may include these author names, as they are often part of widely accepted testing frameworks.
-- To manage false positives, users can create exceptions for specific scripts or processes that are known to be safe and are used regularly within their environment.
-- Implementing a whitelist of approved scripts or author names that are recognized as non-threatening can help reduce unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure that only trusted scripts are excluded from detection, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential malicious activity.
-- Conduct a thorough investigation of the PowerShell script to confirm if it is indeed malicious by analyzing the script content and its execution context.
-- Review system logs and PowerShell execution logs to identify any additional indicators of compromise or related activities.
-- If confirmed malicious, remove the script and any associated files or processes from the system.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed PowerShell execution logs and script block logging for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in the future.
-- Apply security patches and updates to the system and ensure that all software is up to date to mitigate vulnerabilities.
-- Educate users and administrators on the risks of using unverified scripts and the importance of maintaining security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_powershell_susp_args_via_winscript.toml b/rules/windows/execution_powershell_susp_args_via_winscript.toml
index 5a48be483a7..146ff0b2c9b 100644
--- a/rules/windows/execution_powershell_susp_args_via_winscript.toml
+++ b/rules/windows/execution_powershell_susp_args_via_winscript.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -98,50 +98,6 @@ process where host.os.type == "windows" and event.action == "start" and
    not (process.parent.name : "wscript.exe" and
         ?process.parent.args : "C:\\Program Files (x86)\\Telivy\\Telivy Agent\\telivy.js")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious PowerShell Execution via Windows Scripts
-
-Windows Script Host (WSH) allows scripts to be executed directly on Windows systems, often using cscript or wscript. Adversaries exploit this by launching PowerShell scripts from WSH to execute malicious payloads, leveraging PowerShell's powerful capabilities. The detection rule identifies such abuse by monitoring PowerShell processes initiated by WSH, focusing on suspicious command patterns and excluding known legitimate activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and parent process name, focusing on `powershell.exe`, `pwsh.exe`, `wscript.exe`, `cscript.exe`, and `mshta.exe`.
-- Examine the `process.command_line` field for suspicious patterns such as encoded commands, use of `Invoke-Expression`, or downloading scripts from external sources.
-- Check the `process.args_count` to determine if the command line arguments are unusually minimal, which might indicate obfuscation.
-- Investigate the parent process's command line (`process.parent.command_line`) to understand the context in which the PowerShell script was executed.
-- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes with their parent processes: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name IN ('powershell.exe', 'pwsh.exe') AND parent IN (SELECT pid FROM processes WHERE name IN ('wscript.exe', 'cscript.exe', 'mshta.exe'));`
-- Cross-reference the `process.args` with known legitimate activities to rule out false positives, especially those excluded in the detection rule.
-- Investigate network connections initiated by the suspicious PowerShell process to identify any external communications, using tools like Osquery: `SELECT * FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name IN ('powershell.exe', 'pwsh.exe'));`
-- Check for any file modifications or creations by the PowerShell process, which might indicate payload delivery or execution.
-- Review the system's event logs for any additional context or related activities around the time of the alert, focusing on security and application logs.
-- Correlate the findings with other alerts or logs from the same host or user to identify potential patterns or repeated suspicious behavior.
-
-### False positive analysis
-
-- Legitimate PowerShell commands often use non-shortened execution flags, which can trigger false positives. Users can manage these by excluding specific command patterns, such as those involving "-EncodedCommand" and "Import-Module", while ensuring they are paired with "-ExecutionPolicy" to filter out benign activities.
-- Third-party installation scripts, like those related to Microsoft System Center or WebLogic, may inadvertently match suspicious patterns. Users should identify and exclude these specific scripts by adding exceptions for known file paths or command line arguments.
-- Some enterprise applications, such as those involving network information gathering or ICMP probes, may execute PowerShell scripts in a manner that appears suspicious. Users can handle these by excluding the specific parent script names or arguments associated with these applications.
-- Scripts related to software updates or system management, such as those for Microsoft Office or AppxPackage management, might trigger alerts. Users should create exceptions for these known processes by specifying the exact command line patterns or arguments used.
-- Custom scripts or tools, like those for speed tests or KMS activation, may also be flagged. Users can manage these by excluding the specific URLs or script names involved, ensuring that only recognized and trusted scripts are allowed.
-- In cases where specific applications, such as Telivy Agent, use PowerShell in a controlled manner, users should exclude these by identifying the parent script or application path, ensuring that only legitimate instances are permitted.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the PowerShell script execution to determine the scope and intent of the activity, focusing on the command patterns identified in the detection rule.
-- Review and analyze logs from Windows Event Viewer, especially PowerShell and Script Block Logging, to gather more context on the execution and any related activities.
-- If malicious activity is confirmed, remove any identified malicious scripts or payloads from the system and ensure no persistence mechanisms are in place.
-- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a larger attack campaign or if sensitive data is at risk.
-- Implement or enhance logging policies to include detailed PowerShell logging and Windows Script Host activity to improve future detection and investigation capabilities.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance visibility and detection of similar threats in the future.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
-- Educate users on the risks of executing unknown scripts and reinforce the importance of reporting suspicious activities to the IT department."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_scheduled_task_powershell_source.toml b/rules/windows/execution_scheduled_task_powershell_source.toml
index 366bc63be00..443716555aa 100644
--- a/rules/windows/execution_scheduled_task_powershell_source.toml
+++ b/rules/windows/execution_scheduled_task_powershell_source.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,49 +46,6 @@ sequence by host.id, process.entity_id with maxspan = 5s
   (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")]
  [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not destination.address in ("127.0.0.1", "::1")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Outbound Scheduled Task Activity via PowerShell
-
-PowerShell is a powerful scripting language and automation framework in Windows environments, often used for task automation and configuration management. Adversaries may exploit PowerShell to create scheduled tasks for executing malicious payloads or conducting lateral movement. The detection rule identifies suspicious activity by monitoring PowerShell processes that load the Task Scheduler DLL and initiate outbound RPC connections, which may indicate unauthorized task scheduling for malicious purposes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the host.id and process.entity_id associated with the suspicious PowerShell activity.
-- Check the timestamp of the alert to determine the exact time window of the activity and correlate it with any other suspicious events on the same host.
-- Investigate the specific PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) that loaded the taskschd.dll by examining the process command line arguments and parent process to understand the context of execution.
-- Analyze the network connection details, focusing on the destination port 135, to identify the target system of the outbound RPC connection and verify if it is a legitimate communication.
-- Use Osquery to list all scheduled tasks on the host to identify any newly created or modified tasks around the time of the alert. Example query: `SELECT * FROM scheduled_tasks WHERE name LIKE '%task%' AND last_run_time > 'YYYY-MM-DD HH:MM:SS';`
-- Cross-reference the destination.address with known internal IP addresses to determine if the connection was made to a trusted or expected endpoint.
-- Examine the user account under which the PowerShell process was executed to assess if it has the necessary privileges to create scheduled tasks and if the activity aligns with the user's typical behavior.
-- Review recent login events on the host to identify any unusual or unauthorized access that might have preceded the PowerShell activity.
-- Check for any other alerts or logs related to the same host or user account to identify patterns or additional indicators of compromise.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, particularly those involving scheduled tasks and PowerShell exploitation.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often use PowerShell to automate routine tasks, which may involve loading the Task Scheduler DLL and making outbound RPC connections. To manage this, users can create exceptions for known administrative scripts or processes by whitelisting specific script paths or process hashes.
-- Software updates and installations: Some software update mechanisms or installation processes may use PowerShell to schedule tasks for updates, triggering the detection rule. Users can handle these by identifying and excluding specific update processes or trusted software vendors from the rule.
-- Monitoring and management tools: Certain IT management or monitoring tools may use PowerShell to schedule tasks for system checks or data collection. Users should review and whitelist these tools by verifying their legitimacy and adding them to an exclusion list based on process names or network addresses.
-- Development and testing environments: Developers may use PowerShell scripts to test scheduled tasks or network connections in a controlled environment. To prevent false positives, users can exclude specific development machines or IP ranges from the detection rule.
-- Backup and recovery operations: Backup solutions might use PowerShell to schedule tasks for regular data backups, which could be mistaken for suspicious activity. Users can manage this by identifying backup processes and excluding them from the rule based on known backup software signatures or network patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on recent scheduled tasks and PowerShell activity.
-- Terminate any suspicious PowerShell processes and remove unauthorized scheduled tasks identified during the investigation.
-- Review and analyze logs from the affected system and any connected systems to trace the origin and timeline of the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed PowerShell activity and scheduled task creation events for future monitoring.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system from a known good backup to ensure all malicious changes are removed and the system is returned to a secure operational state.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the adversary.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing application whitelisting to prevent unauthorized PowerShell execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_suspicious_cmd_wmi.toml b/rules/windows/execution_suspicious_cmd_wmi.toml
index 11c924cccb7..1e55aa7ab0d 100644
--- a/rules/windows/execution_suspicious_cmd_wmi.toml
+++ b/rules/windows/execution_suspicious_cmd_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,54 +55,6 @@ process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "WmiPrvSE.exe" and process.name : "cmd.exe" and
  process.args : "\\\\127.0.0.1\\*" and process.args : ("2>&1", "1>")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Cmd Execution via WMI
-
-Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing commands remotely, often using the command prompt (cmd.exe). The detection rule identifies such activity by monitoring for cmd.exe processes initiated by WMI, especially those with arguments indicating potential redirection or network access, signaling possible malicious intent.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of cmd.exe execution initiated by WmiPrvSE.exe, focusing on the process arguments, especially those indicating network access or redirection (e.g., "\\\\\\\\127.0.0.1\\\\*", "2>&1", "1>").
-- Check the event logs on the affected host for any additional context around the time of the alert, particularly looking for other WMI-related activities or unusual process creations.
-- Investigate the parent process WmiPrvSE.exe to determine if it was started by a legitimate user or process, and verify its command line arguments and execution history.
-- Use Osquery to gather more information about the cmd.exe process. For example, run the following query to list all processes with their parent process IDs and command line arguments:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'cmd.exe';
-  ```
-- Examine network connections on the host to identify any suspicious outbound connections that may correlate with the cmd.exe execution, using tools like netstat or Osquery:
-  ```sql
-  SELECT pid, local_address, local_port, remote_address, remote_port FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name = 'cmd.exe');
-  ```
-- Correlate the alert with other security events or alerts in your environment to identify if this activity is part of a broader attack pattern or campaign.
-- Check for any recent changes in user accounts or permissions on the affected host that could indicate unauthorized access or privilege escalation.
-- Investigate the user account associated with the WMI activity to determine if it has been compromised or is being misused.
-- Review any recent software installations or updates on the host that could have introduced vulnerabilities or backdoors exploited by the adversary.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) of specific threat actors or malware families.
-
-### False positive analysis
-
-- Scheduled administrative tasks: Routine administrative scripts executed via WMI for system maintenance or updates may trigger this rule. Users can create exceptions for known scripts or scheduled tasks by identifying their specific command patterns and excluding them from the detection criteria.
-- Monitoring and management tools: Some legitimate monitoring or management software may use WMI to execute commands remotely, which could be flagged as suspicious. Users should identify these tools and whitelist their processes or specific command arguments to prevent false alerts.
-- Internal IT operations: IT departments may use WMI for legitimate remote command execution as part of their daily operations. Users should document these operations and adjust the detection rule to exclude known internal IP addresses or specific command patterns associated with these activities.
-- Automated scripts: Automated scripts that perform network diagnostics or system checks might use WMI and cmd.exe, leading to false positives. Users can refine the detection rule by excluding specific script names or command arguments that are consistently used in these benign operations.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Verify the legitimacy of the WMI activity by checking the source and context of the command execution.
-- Conduct a thorough investigation of the cmd.exe process and its arguments to determine if the activity is malicious.
-- Review recent WMI activity logs to identify any other suspicious or unauthorized actions.
-- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Implement enhanced logging policies to capture detailed WMI and cmd.exe activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor behaviors and tactics.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Apply security hardening measures, such as restricting WMI access to authorized users and systems, to prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
index 80cebecba22..dc17bde0562 100644
--- a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
+++ b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,48 +50,6 @@ any where host.os.type == "windows" and
   process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE") and
   (?dll.name : "wmiutils.dll" or file.name : "wmiutils.dll")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious WMI Image Load from MS Office
-
-Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute code stealthily, bypassing traditional security measures by spawning processes indirectly. The detection rule identifies unusual loading of the `wmiutils.dll` library by Microsoft Office applications, signaling potential misuse of WMI for malicious activities. This rule focuses on monitoring specific Office processes for suspicious library loads, which may indicate adversarial attempts to execute code covertly.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `wmiutils.dll` being loaded by one of the specified Microsoft Office processes (`WINWORD.EXE`, `EXCEL.EXE`, `POWERPNT.EXE`, `MSPUB.EXE`, `MSACCESS.EXE`).
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities on the system around the same time.
-- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
-- Examine the parent process of the Office application to identify if it was launched by a legitimate user action or another process that might indicate malicious activity.
-- Use Osquery to gather additional context about the process and DLL load. Example query: `SELECT * FROM processes WHERE name IN ('WINWORD.EXE', 'EXCEL.EXE', 'POWERPNT.EXE', 'MSPUB.EXE', 'MSACCESS.EXE') AND pid IN (SELECT pid FROM process_open_sockets WHERE remote_address IS NOT NULL);`
-- Analyze network connections established by the Office process to identify any suspicious or unexpected external communications.
-- Review recent changes to the system, such as new software installations or updates, that might explain the unusual DLL load.
-- Check for any other security alerts or logs that might indicate a broader attack pattern or campaign targeting the system or network.
-- Investigate the system for any signs of persistence mechanisms that might have been established by an adversary using WMI or other techniques.
-- Consult threat intelligence sources to determine if there are known campaigns or threat actors that utilize similar techniques involving WMI and Office applications.
-
-### False positive analysis
-
-- Legitimate software updates or plugins for Microsoft Office applications may load `wmiutils.dll` as part of their normal operation, leading to false positives. Users should verify the source and purpose of the update or plugin to determine if it is benign.
-- Some enterprise environments use custom scripts or automation tools that leverage WMI for legitimate administrative tasks, which might trigger this rule. Users can create exceptions for known scripts or tools by excluding specific process hashes or command lines associated with these tasks.
-- Security software or monitoring tools that integrate with Microsoft Office for enhanced protection or data analysis might also load `wmiutils.dll` as part of their functionality. Users should confirm the legitimacy of such software and consider excluding it from the rule if it is verified as safe.
-- To manage false positives, users can implement a whitelist of known safe applications or processes that are allowed to load `wmiutils.dll`, ensuring that only unexpected or unknown instances trigger alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm the presence of malicious activity by analyzing the process tree and any associated network connections.
-- Terminate any suspicious processes that are identified as part of the malicious activity, particularly those involving WMI and Microsoft Office applications.
-- Review and collect relevant logs, including Windows Event Logs and security logs, to gather evidence and understand the scope of the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement or enhance logging policies to ensure detailed monitoring of WMI activities and Microsoft Office processes, focusing on unusual DLL loads.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and conducting a full system scan.
-- Harden the system by disabling unnecessary WMI services and applying least privilege principles to limit the execution of unauthorized scripts and processes.
-- Educate users on recognizing phishing attempts and suspicious activities, as these are common vectors for initiating such attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_via_mmc_console_file_unusual_path.toml b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
index 34768aaed32..5e8bd3c2454 100644
--- a/rules/windows/execution_via_mmc_console_file_unusual_path.toml
+++ b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 
 [rule]
 author = ["Elastic"]
@@ -50,49 +50,6 @@ process where host.os.type == "windows" and event.type == "start" and
         "?:\\Program Files (x86)\\*.msc"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft Management Console File from Unusual Path
-
-Microsoft Management Console (MMC) is a Windows utility that provides a framework for system management tools. Adversaries may exploit MMC by executing .msc files from non-standard directories to bypass security controls. The detection rule identifies such anomalies by monitoring the execution of MMC files from paths outside trusted directories, flagging potential unauthorized access or execution attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific .msc file and the unusual path from which it was executed.
-- Verify the legitimacy of the process by checking the user account associated with the execution and correlating it with known user activity.
-- Examine the parent process of the mmc.exe execution to determine if it was initiated by a legitimate or suspicious process.
-- Use Osquery to list all running processes and their command-line arguments to identify any other unusual or unauthorized executions. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE name = 'mmc.exe';`
-- Investigate the file path of the .msc file to determine if it is a known or expected location for such files. Check for any recent changes or modifications to the directory.
-- Check the file hash of the .msc file against known good hashes or threat intelligence databases to identify any known malicious files.
-- Review recent system logs and security events for any other suspicious activities or anomalies around the time of the alert.
-- Analyze network traffic from the host to identify any unusual outbound connections that may indicate data exfiltration or command and control activity.
-- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or coordinated attacks.
-- Consult with the user or system owner to verify if the execution was intentional and authorized, and gather any additional context or information.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may execute .msc files from non-standard directories for legitimate purposes, such as custom scripts or tools stored in user-specific directories. To manage these, users can create exceptions for known administrative accounts or specific directories frequently used for legitimate tasks.
-- Software installations and updates: Some software installations or updates might temporarily execute .msc files from non-standard paths. Users can handle these by monitoring installation or update activities and creating temporary exceptions during these periods.
-- Development and testing environments: Developers or IT staff might run .msc files from unusual paths during testing or development phases. To reduce false positives, users can exclude specific development machines or user accounts from the rule.
-- Third-party management tools: Certain third-party management tools might use .msc files from non-standard locations. Users should identify these tools and add their execution paths to the exception list to prevent false alerts.
-- User-specific customizations: Advanced users might create custom .msc files for personal use, stored in non-standard directories. Users can manage these by allowing exceptions for specific user profiles or directories known to contain custom .msc files.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the execution of .msc files from untrusted paths.
-- Review system logs and security alerts to gather evidence of the attack vector and any associated malicious activity.
-- Remove any unauthorized .msc files and related malicious software from the system.
-- Restore the system from a known good backup to ensure all malicious changes are reverted.
-- Update and patch the operating system and all installed software to mitigate known vulnerabilities.
-- Implement application whitelisting to restrict the execution of .msc files to trusted directories only.
-- Enhance logging and monitoring policies to include detailed process execution and file access events for early detection of similar threats.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_windows_cmd_shell_susp_args.toml b/rules/windows/execution_windows_cmd_shell_susp_args.toml
index 24a9502453e..d6bb9f17af1 100644
--- a/rules/windows/execution_windows_cmd_shell_susp_args.toml
+++ b/rules/windows/execution_windows_cmd_shell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -104,49 +104,6 @@ process where host.os.type == "windows" and event.type == "start" and
   not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and 
   not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Windows Command Shell Arguments
-
-The Windows Command Shell (cmd.exe) is a critical component for executing commands and scripts. Adversaries exploit it to execute malicious scripts, download payloads, or manipulate system settings. The detection rule identifies unusual command-line arguments and patterns indicative of such abuse, while excluding known benign processes, to flag potential threats effectively.
-
-### Possible investigation steps
-
-- Review the full command line of the cmd.exe process to understand the context and intent of the suspicious arguments.
-- Check the parent process of cmd.exe to determine if it is a known benign process or if it might be part of a malicious chain of execution.
-- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
-- Examine the network connections made by the host during the time of the alert to identify any suspicious outbound connections or data exfiltration attempts.
-- Use Osquery to list all running processes on the host to identify any other suspicious activities or processes. Example query: `SELECT name, path, cmdline FROM processes WHERE name = 'cmd.exe';`
-- Analyze the file system for any newly created or modified files that could be related to the suspicious command execution.
-- Check for any scheduled tasks or startup items that might have been created or modified to persist malicious activities.
-- Review the Windows Event Logs, particularly Security and System logs, for any additional indicators of compromise or related events.
-- Investigate any registry changes that might have been made by the cmd.exe process to alter system settings or establish persistence.
-- Correlate the alert with other security events or alerts from the same host or user to identify patterns or broader attack campaigns.
-
-### False positive analysis
-
-- The rule excludes processes with known benign parent executables such as Perl, Node.js, and PostgreSQL, which are often used in legitimate scripting and database operations. Users should ensure these paths are correctly specified to avoid unnecessary alerts.
-- Specific command-line patterns related to software like NetBeans, Citrix Secure Access Client, and npm installations are excluded to prevent false positives from common development and IT management tasks. Users should verify these patterns align with their environment's typical usage.
-- Processes originating from Spiceworks and other IT management tools are excluded to prevent alerts from routine network monitoring and management activities. Users can add similar exclusions for other trusted IT tools in their environment.
-- The rule excludes certain command-line arguments and parent processes associated with known benign applications like PRTG Network Monitor and Tripwire Agent. Users should review and update these exclusions based on the specific software versions and configurations in use.
-- Users can manage false positives by adding exceptions for specific command-line patterns or parent processes that are frequently observed in their environment but are known to be non-threatening. This can be done by updating the exclusion list with paths or patterns unique to their trusted applications.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation of the suspicious command-line activity to determine the scope and impact, using available logs and forensic tools.
-- Identify and terminate any malicious processes associated with the suspicious command-line arguments.
-- Remove any malicious files or scripts identified during the investigation from the affected system.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Restore the system from a clean backup if the integrity of the system is compromised beyond repair.
-- Implement enhanced logging policies to capture detailed command-line activity and integrate with a centralized logging solution for future analysis.
-- Review and update security policies and procedures to include detection and response to similar threats, leveraging MITRE ATT&CK framework for guidance.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
-- Escalate the incident to the appropriate internal or external cybersecurity team if the threat is beyond the organization's capability to handle."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_windows_powershell_susp_args.toml b/rules/windows/execution_windows_powershell_susp_args.toml
index 2f71d9313bd..190e0bee76c 100644
--- a/rules/windows/execution_windows_powershell_susp_args.toml
+++ b/rules/windows/execution_windows_powershell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 
 [rule]
 author = ["Elastic"]
@@ -106,49 +106,6 @@ process where host.os.type == "windows" and event.type == "start" and
        process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*"))
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Windows Powershell Arguments
-
-PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, which are common in malware activities.
-
-### Possible investigation steps
-
-- Review the full command line captured in the alert to understand the context and intent of the PowerShell execution, focusing on any encoded or obfuscated segments.
-- Check the parent process of the PowerShell execution to determine if it was launched by a legitimate process like explorer.exe or cmd.exe, which might indicate user interaction, or by a suspicious process.
-- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Examine the network connections made by the host around the time of the alert to identify any suspicious outbound connections, especially those involving known malicious IPs or domains.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%encodedCommand%' OR cmdline LIKE '%Invoke-webrequest%' OR cmdline LIKE '%WebClient%' OR cmdline LIKE '%Reflection.Assembly%';`
-- Analyze any downloaded files or payloads referenced in the command line for malicious content using a sandbox or antivirus tools.
-- Correlate the alert with other security events or logs from the same host or user to identify patterns or repeated suspicious activities.
-- Check for any recent changes to the system, such as new scheduled tasks, services, or startup items, that might indicate persistence mechanisms.
-- Review the system's security patches and updates to ensure it is not vulnerable to known exploits that could have been leveraged in the attack.
-- Investigate any additional alerts or anomalies from the same timeframe to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative scripts: PowerShell is commonly used by IT administrators for legitimate automation tasks, which may include encoded commands or downloading files. Users should review the context of the script execution and consider excluding known administrative scripts from the detection rule.
-- Software installations and updates: Some software installations or updates may use PowerShell scripts with arguments that match suspicious patterns. Users can create exceptions for specific software processes or installation paths that are verified as safe.
-- Security tools and monitoring solutions: Certain security tools or monitoring solutions may use PowerShell to perform checks or gather system information, potentially triggering the rule. Users should identify and exclude these tools from the detection criteria.
-- Development and testing environments: Developers and testers might use PowerShell to simulate attacks or test scripts, which could be flagged as suspicious. Users should consider excluding processes running in designated development or testing environments.
-- Automated backup or maintenance scripts: Scheduled tasks or automated scripts for backup and maintenance may use PowerShell with arguments that appear suspicious. Users should verify these scripts and exclude them if they are part of routine operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation of the PowerShell command line arguments and scripts executed to identify the scope and intent of the activity.
-- Review and analyze logs from the affected system and any associated systems to trace the origin and timeline of the suspicious activity.
-- Remove any identified malicious scripts or payloads from the system and ensure that no unauthorized changes have been made to system configurations.
-- Update antivirus and endpoint protection solutions to the latest definitions and perform a full system scan to detect and remove any remaining threats.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a larger attack campaign or if sensitive data may have been compromised.
-- Implement enhanced logging policies to capture detailed PowerShell execution events, including command line arguments and script block logging.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and correlation of suspicious activities.
-- Restore the system to its operational state by applying verified clean backups and ensuring all security patches and updates are applied.
-- Harden the system by disabling unnecessary PowerShell features, enforcing script execution policies, and implementing application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/exfiltration_smb_rare_destination.toml b/rules/windows/exfiltration_smb_rare_destination.toml
index 0e2bd02b538..4d605159cf9 100644
--- a/rules/windows/exfiltration_smb_rare_destination.toml
+++ b/rules/windows/exfiltration_smb_rare_destination.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -79,50 +79,6 @@ event.category:network and host.os.type:windows and process.pid:4 and
     "FF00::/8"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Rare SMB Connection to the Internet
-
-Server Message Block (SMB) is a protocol used for sharing files and printers within local networks. Adversaries exploit SMB to exfiltrate data by injecting rogue paths to capture NTLM credentials. The detection rule identifies unusual SMB traffic from internal IPs to external networks, flagging potential exfiltration attempts by monitoring specific ports and excluding known safe IP ranges.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the source IP address falls within the internal IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and the destination IP is external.
-- Verify the destination port is either 139 or 445, as these are the ports associated with SMB traffic, to ensure the alert is relevant.
-- Check the process ID (PID) 4 on the host, which typically corresponds to the System process, to confirm the legitimacy of the SMB connection.
-- Use network logs to trace the SMB connection path and identify any unusual patterns or repeated attempts to connect to the same external IP.
-- Investigate the external IP address to determine if it is associated with known malicious activity or if it belongs to a legitimate service.
-- Utilize Osquery to gather more information about the host's network connections. Example query: `SELECT * FROM process_open_sockets WHERE pid = 4 AND remote_port IN (139, 445);` to identify all active connections from the System process.
-- Examine recent changes or updates on the host that might have triggered the unusual SMB connection, such as new software installations or configuration changes.
-- Review user activity logs on the host to identify any suspicious behavior or unauthorized access attempts around the time of the alert.
-- Correlate the alert with other security events or alerts in the network to determine if this is part of a larger attack pattern.
-- Consult threat intelligence sources to check for any recent campaigns or tactics involving SMB exfiltration that match the observed behavior.
-
-### False positive analysis
-
-- Known false positives may include legitimate SMB traffic to external cloud services or remote offices that are part of the organization's infrastructure but not included in the safe IP ranges.
-- Regularly scheduled backups or file synchronization tasks that use SMB to connect to external storage solutions can trigger alerts.
-- Users can handle these false positives by identifying and documenting legitimate external SMB connections and updating the detection rule to exclude these specific IP addresses or IP ranges.
-- Implementing a whitelist of known and trusted external IPs or domains that require SMB access can help reduce false positives.
-- Monitoring and reviewing the frequency and context of flagged connections can assist in distinguishing between legitimate and suspicious activities.
-- Collaborate with network and security teams to ensure that any changes in infrastructure or external partnerships are reflected in the detection rule's exceptions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the SMB connection, including reviewing logs and network traffic for any signs of unauthorized access or data transfer.
-- Reset credentials for any accounts that may have been compromised, particularly those using NTLM authentication.
-- Remove any unauthorized SMB shares or rogue UNC paths identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed network traffic and SMB activity, ensuring that logs are stored securely and monitored regularly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify that all security controls are functioning correctly.
-- Conduct a post-incident review to identify any gaps in the security posture and update incident response plans accordingly.
-- Implement hardening measures such as disabling SMBv1, enforcing strong password policies, and using network segmentation to limit the exposure of critical systems."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
index 362aa1dfbce..9833b3ed3e6 100644
--- a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
+++ b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/08"
 
 [rule]
 author = ["Elastic"]
@@ -15,51 +15,7 @@ index = ["logs-endpoint.events.process-*", "logs-endpoint.events.file-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious HTML File Creation"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious HTML File Creation
-
-HTML files, often used for web content, can be exploited by adversaries to smuggle malicious payloads past security filters. Attackers may embed harmful data within HTML files, leveraging browsers to execute these files. The detection rule identifies such threats by monitoring HTML file creation with high entropy or large size in common directories, coupled with browser processes accessing these files. This approach helps pinpoint potential phishing attempts or unauthorized data transfers.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file extension and size, ensuring it matches the criteria of high entropy or large size as specified in the detection rule.
-- Check the file path to verify if it is located in common download or temporary directories, such as `?:\\Users\\*\\Downloads\\*` or `?:\\Users\\*\\AppData\\Local\\Temp\\*`.
-- Investigate the user account associated with the file creation event to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the process details to identify which browser was used to open the HTML file, focusing on processes like `chrome.exe`, `msedge.exe`, or `firefox.exe`.
-- Analyze the process arguments to confirm if the browser was launched with a single argument or specific URL, which may indicate an attempt to execute the HTML file directly.
-- Utilize Osquery to gather additional context about the file and process. For example, run the following query to list recent file modifications in the user's Downloads directory: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%' ORDER BY mtime DESC LIMIT 10;`.
-- Cross-reference the file hash with threat intelligence databases to check for known malicious indicators.
-- Review recent email activity for the user to identify any potential phishing emails that may have delivered the suspicious HTML file.
-- Check for any network connections initiated by the browser process after opening the HTML file, which could indicate data exfiltration or communication with a command and control server.
-- Investigate any other alerts or logs related to the same user or system to identify patterns or additional suspicious activities that may correlate with the HTML file creation event.
-
-### False positive analysis
-
-- Legitimate software updates or installations may create large HTML files in temporary directories, triggering the rule. Users can exclude specific software update processes by identifying their unique file paths or process names.
-- Some web development tools or environments might generate high entropy HTML files during normal operations. Users should monitor and whitelist these tools if they are known and trusted within their environment.
-- Automated scripts or applications that download or generate HTML files for reporting purposes could be flagged. Users can create exceptions for these scripts by specifying their file paths or associated process names.
-- Browsers opening HTML files from email clients or collaboration tools might be misidentified as suspicious. Users should consider excluding known safe email client directories or specific browser processes when they are part of a trusted workflow.
-- Large HTML files used for legitimate data visualization or documentation purposes may be mistakenly flagged. Users can manage this by excluding specific directories or file names associated with these legitimate files.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the HTML file to determine if it contains malicious payloads, using tools like antivirus or sandbox analysis.
-- Review browser history and recent downloads to identify any suspicious activity or unauthorized access attempts.
-- Remove any identified malicious files and clean the system using updated antivirus or anti-malware software.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Implement enhanced logging policies to capture detailed file creation and process execution events for future investigations.
-- Integrate security solutions with threat intelligence platforms to improve detection capabilities and response times.
-- Educate users on recognizing phishing attempts and safe browsing practices to reduce the risk of future incidents.
-- Apply security patches and updates to browsers and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
-
-This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence."""
+note = "This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence."
 risk_score = 47
 rule_id = "f0493cb4-9b15-43a9-9359-68c23a7f2cf3"
 setup = """## Setup
diff --git a/rules/windows/initial_access_execution_from_inetcache.toml b/rules/windows/initial_access_execution_from_inetcache.toml
index 287dd3ba901..78d9de0f304 100644
--- a/rules/windows/initial_access_execution_from_inetcache.toml
+++ b/rules/windows/initial_access_execution_from_inetcache.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,49 +61,6 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Execution from INET Cache
-
-The INetCache folder stores temporary internet files, which can be exploited by adversaries to execute malicious payloads. Attackers may use this cache to deliver harmful content via web interactions, often leveraging phishing techniques. The detection rule identifies suspicious processes initiated from this cache, especially those spawned by common file explorers, signaling potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments, focusing on the `process.parent.name` field to verify if the process was spawned by `explorer.exe`, `winrar.exe`, `7zFM.exe`, or `Bandizip.exe`.
-- Examine the `process.args` field to identify the specific file path within the INetCache that was executed, noting any unusual or suspicious file names or extensions.
-- Check the `process.executable` field to determine the exact executable path and verify if it matches known legitimate software or if it appears suspicious.
-- Use Osquery to list all files in the INetCache directory for the affected user to identify any other potentially malicious files. Example query: `SELECT path, filename, size, atime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Local\\\\Microsoft\\\\Windows\\\\INetCache\\\\IE\\\\%';`
-- Investigate the parent process tree to understand the sequence of events leading to the execution, focusing on any unusual or unexpected parent-child process relationships.
-- Correlate the event timestamp with user activity logs to determine if the execution aligns with legitimate user actions or if it occurred during a period of inactivity.
-- Analyze network logs for any outbound connections made by the suspicious process to identify potential command and control communication or data exfiltration attempts.
-- Review email logs or web browsing history for the affected user to identify any recent phishing attempts or suspicious downloads that could have led to the execution.
-- Check for any recent changes or anomalies in the user's system configuration or installed software that could indicate compromise or unauthorized access.
-- Consult threat intelligence sources to determine if the identified file or behavior is associated with known malware or attack campaigns, providing additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they temporarily store files in the INetCache folder during the process. Users should verify the source and purpose of the process to determine if it is benign.
-- Web browsers or file explorers might cache legitimate files in the INetCache folder, leading to false positives when these files are executed. Users can create exceptions for known safe processes or applications that frequently use this cache.
-- Automated scripts or tools that interact with web content and store temporary files in the INetCache folder could be flagged. Users should review these scripts and whitelist them if they are part of routine operations.
-- Some enterprise applications may use the INetCache folder for temporary storage during normal operations. Users should identify these applications and configure the rule to exclude them from triggering alerts.
-- To manage false positives, users can adjust the detection rule to exclude specific processes or paths that are consistently identified as non-threatening, ensuring that only genuine threats are flagged.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to identify the source of the suspicious execution, focusing on recent web interactions and email communications.
-- Terminate any malicious processes identified as originating from the INetCache folder.
-- Remove any malicious files found in the INetCache directory and perform a full antivirus scan on the system.
-- Review and analyze logs from the affected system to identify any additional indicators of compromise or lateral movement.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat appears to be part of a larger campaign or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds to improve detection capabilities and correlate with known phishing and initial access techniques.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security software is up to date.
-- Harden the system by implementing security best practices, such as disabling unnecessary services, enforcing strong password policies, and educating users on recognizing phishing attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_from_removable_media.toml b/rules/windows/initial_access_execution_from_removable_media.toml
index a3d134b3775..495c84b76fd 100644
--- a/rules/windows/initial_access_execution_from_removable_media.toml
+++ b/rules/windows/initial_access_execution_from_removable_media.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -39,49 +39,6 @@ sequence by process.entity_id with maxspan=5m
   not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")]
  [network where host.os.type == "windows" and event.action == "connection_attempted"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution from a Removable Media with Network Connection
-
-Removable media, like USB drives, facilitate data transfer but can be exploited by adversaries to introduce malware into isolated systems. Attackers may leverage autorun features to execute malicious code upon media insertion. The detection rule identifies suspicious process executions from USBs, especially those lacking valid code signatures, and correlates them with network connection attempts, signaling potential unauthorized access or data exfiltration efforts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process entity ID and timestamp of the suspicious execution from the removable media.
-- Verify the process details, including the process name, path, and command line arguments, to determine if it aligns with known legitimate applications or if it appears suspicious.
-- Check the code signature status of the process to confirm if it is indeed untrusted or unsigned, as indicated by the alert.
-- Investigate the USB device details, such as the device bus type and product ID, to identify the specific removable media used and its history of usage on the system.
-- Correlate the process execution with network connection attempts by examining the network event details, including the destination IP addresses and ports, to identify any unusual or unauthorized connections.
-- Use Osquery to gather additional context on the process and USB device. For example, run the following query to list processes executed from USB devices: `SELECT * FROM processes WHERE path LIKE 'E:\\\\%' OR path LIKE 'F:\\\\%';`
-- Analyze the user account associated with the process execution to determine if it aligns with expected user behavior or if it indicates potential compromise.
-- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may be related.
-- Investigate the history of the USB device on the system by checking for previous insertions and any other processes executed from it.
-- Cross-reference the alert with threat intelligence sources to determine if the process or network activity matches known indicators of compromise or attack patterns.
-
-### False positive analysis
-
-- Legitimate software installations or updates from USB drives may trigger the rule if the software lacks a valid code signature. Users can create exceptions for known software vendors or specific USB devices used for updates.
-- IT personnel using USB drives for system maintenance or diagnostics might cause false positives. To manage this, organizations can whitelist specific USB devices or processes associated with IT operations.
-- Educational or training environments where software is frequently distributed via USB may also generate alerts. In such cases, users can exclude specific processes or devices commonly used in these settings.
-- Developers or testers using unsigned applications from USB drives for testing purposes might inadvertently trigger the rule. Exceptions can be made for specific development environments or devices.
-- In environments where USB devices are used for legitimate data transfer between isolated systems, users can establish a list of trusted devices or processes to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on the processes executed from the removable media and any network connections attempted.
-- Quarantine the removable media to prevent further use and analyze it for malware or unauthorized files.
-- Remove any identified malicious software from the affected system using trusted antivirus or anti-malware tools.
-- Review and update the system's autorun settings to disable automatic execution of programs from removable media.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems may be affected.
-- Implement enhanced logging policies to capture detailed information on process executions and network connections, particularly those involving removable media.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors or campaigns, leveraging MITRE ATT&CK framework for context.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
-- Strengthen security measures by enforcing strict access controls, conducting regular security awareness training, and implementing endpoint protection solutions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_remote_via_msiexec.toml b/rules/windows/initial_access_execution_remote_via_msiexec.toml
index d20c7a1b069..054e39cfd39 100644
--- a/rules/windows/initial_access_execution_remote_via_msiexec.toml
+++ b/rules/windows/initial_access_execution_remote_via_msiexec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -61,53 +61,6 @@ sequence with maxspan=1m
   not (process.name : "rundll32.exe" and process.args : "printui.dll,PrintUIEntry")
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Remote File Execution via MSIEXEC
-
-MSIEXEC is a Windows utility for installing and managing software packages. Adversaries may exploit it to execute remote files, potentially bypassing security controls. The detection rule identifies suspicious MSIEXEC activity by monitoring for specific command-line arguments, network connections, and unusual child processes, filtering out known legitimate behaviors to highlight potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific command-line arguments used with `msiexec.exe`, focusing on the presence of the `/V` flag, which indicates verbose logging and potential remote execution.
-- Examine the network connections associated with `msiexec.exe` to identify any unusual or unauthorized remote IP addresses or domains that the process attempted to connect to.
-- Investigate the parent process of `msiexec.exe` to determine if it was launched by a legitimate process or if it was spawned by a suspicious or unexpected parent.
-- Check the user account associated with the `msiexec.exe` process, focusing on user IDs like "S-1-5-21-*" and "S-1-5-12-1-*", to verify if the activity aligns with normal user behavior or if it indicates potential compromise.
-- Analyze the child processes spawned by `msiexec.exe` to identify any unusual or unauthorized executables, especially those not located in typical directories like `?:\\Windows\\System32` or `?:\\Program Files`.
-- Verify the code signature of any executables involved in the alert to ensure they are from trusted sources, paying particular attention to any discrepancies in the signature's subject name or trust status.
-- Use Osquery to gather additional context on the system. For example, run the following query to list recent processes executed by `msiexec.exe`:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'msiexec.exe');
-  ```
-- Cross-reference the alert with any recent phishing attempts or suspicious emails received by the user to determine if the `msiexec.exe` activity could be linked to a phishing attack.
-- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that might correlate with the `msiexec.exe` execution.
-- Consult threat intelligence sources to check if the IP addresses or domains contacted by `msiexec.exe` are associated with known malicious activities or threat actors.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule if they use msiexec.exe with remote packages, especially in enterprise environments where software deployment is automated.
-- Network administrators using msiexec.exe for remote installations across the network might be flagged; consider excluding these activities by identifying the specific network paths or IP addresses used.
-- Some IT management tools and scripts that automate software installations could mimic the behavior of adversaries; these should be reviewed and potentially excluded by process name or signature.
-- Exclude processes with trusted code signatures from known vendors, such as Citrix Systems, Inc., to reduce false positives from legitimate software.
-- Regularly review and update the list of excluded executables and paths to ensure that new legitimate software is not mistakenly flagged.
-- Consider the context of the user ID and integrity level; system administrators or automated service accounts might frequently trigger this rule during routine operations.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the MSIEXEC command and the source of the remote package by reviewing logs and network connections.
-- Terminate any suspicious processes initiated by msiexec.exe that are not part of known legitimate software installations.
-- Conduct a thorough investigation to identify any additional compromised systems or accounts, focusing on the MITRE ATT&CK tactic of Initial Access and technique of Phishing.
-- Remove any unauthorized software or files installed via the suspicious MSIEXEC activity and restore affected files from backups if necessary.
-- Update and apply security patches to the affected system to mitigate vulnerabilities that may have been exploited.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that MSIEXEC usage is closely monitored.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Educate users on recognizing phishing attempts and the importance of reporting suspicious emails or activities to reduce the risk of initial access through social engineering.
-- Review and strengthen endpoint protection configurations, including application whitelisting and execution restrictions, to prevent unauthorized use of system utilities like msiexec.exe."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_via_office_addins.toml b/rules/windows/initial_access_execution_via_office_addins.toml
index 2551c4201aa..4faad5dfbcf 100644
--- a/rules/windows/initial_access_execution_via_office_addins.toml
+++ b/rules/windows/initial_access_execution_via_office_addins.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -81,52 +81,6 @@ process where
          process.parent.args : "?:\\WINDOWS\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc") and
     not (process.name : "VSTOInstaller.exe" and process.args : "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Execution via Microsoft Office Add-Ins
-
-Microsoft Office Add-Ins enhance productivity by allowing custom functionalities within Office applications. However, adversaries can exploit this by embedding malicious code in add-ins, often delivered via phishing. The detection rule identifies unusual execution patterns, such as Office apps launching add-ins from atypical paths or with unexpected parent processes, signaling potential malicious activity. It filters out known benign processes to reduce false positives, focusing on genuine threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Microsoft Office application involved (e.g., WINWORD.EXE, EXCEL.EXE) and the suspicious add-in file path or parent process.
-- Examine the process arguments to determine the type of add-in file executed (e.g., .wll, .xll, .ppa) and verify if the path is listed as suspicious in the detection rule.
-- Check the parent process name to see if it matches any unusual or suspicious processes such as cmd.exe or powershell.exe, which could indicate script-based execution.
-- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous.
-- Utilize Osquery to gather additional context about the process execution. For example, run the following query to list recent processes executed by the user:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'target_username');
-  ```
-- Correlate the process execution time with any known phishing attempts or suspicious email activity targeting the user to assess potential initial access vectors.
-- Analyze network logs to identify any outbound connections made by the process, especially to external IPs or domains, which could indicate data exfiltration or command-and-control communication.
-- Review system logs for any additional suspicious activities or errors around the time of the alert, such as failed logins or unusual file access patterns.
-- Check for any recent changes or installations on the system that could have introduced the suspicious add-in, such as new software installations or updates.
-- Consult threat intelligence sources to determine if the identified add-in file or associated domains/IPs are known to be associated with malicious activity or campaigns.
-
-### False positive analysis
-
-- The rule may trigger on legitimate installations or updates of Microsoft Office Add-Ins, particularly those involving Logitech software, as these processes can mimic suspicious behavior. Users can manage this by excluding processes with arguments like "*.vsto" and parent executables from Logitech directories, such as "?:\\\\Program Files\\\\Logitech\\\\LogiOptions\\\\PlugInInstallerUtility*.exe".
-- Another potential false positive involves the VSTOInstaller.exe process when it is used for legitimate purposes, such as uninstalling add-ins. Users can exclude processes with arguments like "/Uninstall" and the process name "VSTOInstaller.exe" to prevent unnecessary alerts.
-- The rule might also flag processes initiated by "rundll32.exe" with specific arguments related to Windows Installer temporary files. Users can exclude these by specifying the parent name "rundll32.exe" and parent arguments like "?:\\\\WINDOWS\\\\Installer\\\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc".
-- To avoid false positives related to the Sidekick add-in for Outlook, users can exclude the process name "VSTOInstaller.exe" with arguments pointing to "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto".
-- Users should regularly review and update their exclusion lists to ensure that only non-threatening behaviors are filtered out, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the suspicious Office Add-In by analyzing the file path, parent process, and any associated network activity.
-- Use endpoint detection and response (EDR) tools to identify and terminate any malicious processes or scripts running on the system.
-- Remove the malicious Office Add-In and any associated files from the system, ensuring that all remnants are deleted.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Update antivirus and anti-malware solutions to ensure they can detect and prevent similar threats in the future.
-- Implement logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds to enhance detection capabilities and stay informed about emerging threats.
-- Escalate the incident to the security operations center (SOC) or relevant team if the threat is part of a larger attack campaign.
-- Review and update security policies and user training programs to reduce the risk of phishing attacks and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
index 4ef622c631f..288d91f4f02 100644
--- a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
+++ b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funne
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 
 [rule]
 author = ["Elastic"]
@@ -49,46 +49,6 @@ type = "new_terms"
 query = '''
 event.category:"registry" and host.os.type:"windows" and registry.value:"FriendlyName" and registry.path:*USBSTOR*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Time Seen Removable Device
-
-Removable devices, like USB drives, are commonly used for data transfer. However, adversaries can exploit them for unauthorized data exfiltration or malware distribution. The detection rule monitors registry changes related to new removable devices on Windows systems, focusing on the device's friendly name. By identifying first-time-seen devices, analysts can spot potential threats linked to unauthorized access or data replication activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a new removable device by checking the `registry.value` field for the "FriendlyName" of the device.
-- Verify the `registry.path` field to ensure it includes "USBSTOR," indicating the device is a USB storage device.
-- Cross-reference the `host.os.type` field to confirm the operating system is Windows, as the rule is specific to Windows systems.
-- Check the event timestamp to determine when the device was first seen and correlate it with any other suspicious activities around the same time.
-- Investigate the user account associated with the event to determine if the user has a history of using removable devices or if this is unusual behavior.
-- Use Osquery to gather more information about the device. For example, run the following query to list all USB devices connected to the system: `SELECT * FROM usb_devices WHERE serial NOT IN (SELECT serial FROM usb_devices WHERE last_seen < (SELECT MAX(last_seen) FROM usb_devices) - 86400);`
-- Examine the system's recent file access logs to identify any files that may have been copied to or from the removable device.
-- Check for any other registry changes or system modifications that occurred around the same time as the device connection to identify potential malicious activity.
-- Review network logs for any unusual outbound traffic that might indicate data exfiltration attempts following the device's connection.
-- Consult with the user or system owner to verify if the device usage was authorized and legitimate, and gather any additional context about the device's purpose.
-
-### False positive analysis
-
-- Known false positives for the First Time Seen Removable Device rule include legitimate use cases such as employees using personal USB drives for work purposes, IT staff deploying new hardware, or routine backups involving external drives. These activities can trigger alerts despite being non-threatening.
-- To manage these false positives, users can create exceptions for specific devices by whitelisting their friendly names or serial numbers if they are frequently used and verified as safe. Additionally, implementing a policy to register and approve certain removable devices can help reduce unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential data exfiltration or further spread of malware.
-- Conduct a thorough investigation to identify the source and intent of the removable device usage, checking for any unauthorized data transfers or suspicious files.
-- Review and analyze registry modification events to confirm the presence of unauthorized or malicious activity linked to the newly seen removable device.
-- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system using trusted antivirus or anti-malware tools.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat level is beyond initial containment capabilities or if it involves sensitive data.
-- Implement enhanced logging policies to capture detailed events related to removable device usage, including file transfers and registry changes, for future investigations.
-- Integrate security solutions such as Data Loss Prevention (DLP) and Endpoint Detection and Response (EDR) to monitor and control data transfers to removable devices.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are correctly set.
-- Educate users on the risks associated with removable devices and enforce policies that restrict their use to authorized personnel only.
-- Apply hardening measures such as disabling USB ports where possible, or using endpoint management tools to control device access, in line with the MITRE ATT&CK framework's guidance on mitigating replication through removable media (T1091)."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
index 433b259a9f3..bd42e3ff3ef 100644
--- a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
+++ b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -72,49 +72,6 @@ process where host.os.type == "windows" and event.type == "start" and
  not (process.name : "powershell.exe" and process.args : "-ExecutionPolicy" and process.args : "?:\\TeamCity\\buildAgent\\work\\*.ps1") and
  not (process.name : "cmd.exe" and process.args : "dir" and process.args : "/-c")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious JetBrains TeamCity Child Process
-
-JetBrains TeamCity is a continuous integration and deployment server used to automate software development processes. Adversaries may exploit vulnerabilities in TeamCity to execute unauthorized code, potentially spawning malicious child processes. The detection rule identifies unusual child processes initiated by TeamCity's Java executable, flagging potential exploitation attempts by monitoring for known suspicious executables and excluding benign operations.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific child process was spawned by the TeamCity Java executable and note the process name and path.
-- Verify the parent process by checking the path of the Java executable to ensure it matches one of the expected TeamCity paths: `?:\\TeamCity\\jre\\bin\\java.exe`, `?:\\Program Files\\TeamCity\\jre\\bin\\java.exe`, `?:\\Program Files (x86)\\TeamCity\\jre\\bin\\java.exe`, or `?:\\TeamCity\\BuildAgent\\jre\\bin\\java.exe`.
-- Examine the command-line arguments of the suspicious child process to identify any potentially malicious or unusual commands being executed.
-- Cross-reference the suspicious process name against known legitimate processes and common malicious tools to assess the likelihood of malicious activity.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<suspicious_process_name>';`.
-- Investigate the user account under which the suspicious process is running to determine if it aligns with expected usage patterns or if it indicates potential compromise.
-- Check for any recent changes or updates to the TeamCity server configuration or plugins that might explain the unexpected process behavior.
-- Review network connections initiated by the suspicious process using network monitoring tools or logs to identify any unusual or unauthorized external communications.
-- Analyze system logs for any other suspicious activities or anomalies around the time the alert was triggered to identify potential indicators of compromise.
-- Consult threat intelligence sources to determine if there are any known vulnerabilities or exploits related to the specific version of TeamCity in use that could explain the suspicious activity.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate scripts or applications are executed as part of regular TeamCity operations, such as build scripts or deployment tasks that use command-line tools like `cmd.exe` or `powershell.exe`.
-- Exclude specific scripts or applications by adding exceptions for known benign processes, such as those with specific arguments or paths, to prevent them from being flagged.
-- Regularly review and update the exclusion list to accommodate changes in the build or deployment processes that may introduce new legitimate child processes.
-- Consider the context of the flagged process, such as the timing and frequency of execution, to determine if it aligns with expected TeamCity activities.
-- Collaborate with development and operations teams to identify and document routine processes that may trigger false positives, ensuring these are accounted for in the detection rule exceptions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm the nature of the suspicious process, using forensic tools to analyze logs and system changes.
-- Terminate any malicious processes identified and remove any unauthorized files or executables from the system.
-- Review and update the TeamCity server and any related software to the latest versions to patch known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process execution data, focusing on child processes spawned by TeamCity.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for early detection of similar threats.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Restore the system from a known good backup, ensuring that the backup is free from any malicious modifications.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting execution policies, applying least privilege principles, and using application whitelisting to prevent unauthorized code execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_rdp_file_mail_attachment.toml b/rules/windows/initial_access_rdp_file_mail_attachment.toml
index d18e7035e0d..87b45b1a35b 100644
--- a/rules/windows/initial_access_rdp_file_mail_attachment.toml
+++ b/rules/windows/initial_access_rdp_file_mail_attachment.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/05"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/05"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,49 +59,6 @@ process where host.os.type == "windows" and event.type == "start" and
                  "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*.rdp",
                  "C:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\Content.Outlook\\*.rdp")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Remote Desktop File Opened from Suspicious Path
-
-Remote Desktop Protocol (RDP) enables users to connect to and control remote computers over a network. Adversaries exploit RDP files, which store connection settings, by placing them in suspicious directories to gain unauthorized access. The detection rule identifies when RDP files are opened from unusual paths, indicating potential phishing attempts or initial access tactics, by monitoring specific file locations and process activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the process `mstsc.exe` starting with arguments pointing to suspicious RDP file paths.
-- Verify the user account associated with the process to determine if it aligns with expected behavior or if it is an unusual account for RDP usage.
-- Check the file creation and modification timestamps of the suspicious RDP file to understand when it was placed in the directory.
-- Investigate the source of the RDP file by examining recent downloads or email attachments that may have been saved to the suspicious path.
-- Use Osquery to list all RDP files in the user's Downloads and Temp directories with the query: `SELECT path, size, atime, mtime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\Downloads\\\\%.rdp' OR path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Local\\\\Temp\\\\%.rdp';`
-- Analyze the network connections made by `mstsc.exe` to identify any unusual or unauthorized remote IP addresses.
-- Correlate the event with other security logs to identify any additional suspicious activities around the same timeframe, such as failed login attempts or unusual file access patterns.
-- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
-- Review endpoint security logs for any alerts or detections related to the execution of `mstsc.exe` or the handling of RDP files.
-- Investigate the presence of any other suspicious processes or files on the host that could indicate a broader compromise or lateral movement attempts.
-
-### False positive analysis
-
-- Users may frequently download legitimate RDP files from trusted sources, such as corporate emails or internal portals, which could be flagged if stored in monitored directories like Downloads or Temp folders.
-- Automated scripts or software updates might temporarily store RDP files in these paths for legitimate purposes, triggering false alerts.
-- Employees working remotely might use RDP files sent via email or collaboration tools, which could be saved in the INetCache directory, leading to false positives.
-- To manage these false positives, consider creating exceptions for known safe sources or paths by whitelisting specific directories or file hashes associated with trusted RDP files.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and usability.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Conduct a thorough investigation to identify the source of the suspicious RDP file and determine if any other systems are compromised.
-- Analyze the RDP file and associated processes to understand the adversary's tactics and potential objectives.
-- Remove any unauthorized RDP files and terminate any suspicious processes related to the incident.
-- Reset credentials for any accounts that may have been compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
-- Integrate threat intelligence feeds to identify and block known malicious RDP file signatures and related indicators of compromise (IOCs).
-- Restore the system to its operational state by applying the latest security patches and updates, and verifying system integrity.
-- Harden the system by enforcing strict access controls, disabling unnecessary services, and educating users on recognizing phishing attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_scripts_process_started_via_wmi.toml b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
index 77ee1fc334f..23c41341535 100644
--- a/rules/windows/initial_access_scripts_process_started_via_wmi.toml
+++ b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/27"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -69,50 +69,6 @@ sequence by host.id with maxspan = 5s
      )
     ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows Script Interpreter Executing Process via WMI
-
-Windows Management Instrumentation (WMI) is a powerful feature in Windows that allows for system management and automation. Adversaries may exploit WMI to execute scripts using interpreters like cscript.exe or wscript.exe, often bypassing traditional security measures. The detection rule identifies suspicious script execution via WMI by monitoring for specific processes initiated by WMI, which may indicate malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and executable path that triggered the alert, focusing on `process.name` and `process.executable` fields.
-- Check the `host.id` and `host.os.type` fields to confirm the affected host and ensure it is a Windows system.
-- Investigate the parent process `wmiprvse.exe` to determine if it has any unusual or unexpected child processes, using the `process.parent.name` field.
-- Examine the `user.domain` field to identify the user context under which the suspicious process was executed, paying attention to any non-standard domains.
-- Use Osquery to list all processes currently running on the host and identify any other suspicious activities. Example query: `SELECT name, path, pid, parent, uid FROM processes WHERE name IN ('cscript.exe', 'wscript.exe', 'PowerShell.EXE', 'Cmd.Exe');`
-- Analyze the `event.category` and `event.action` fields to understand the nature of the event, especially focusing on "Image loaded" actions that might indicate DLL loading.
-- Investigate the presence and usage of `wmiutils.dll` by checking the `dll.name` or `file.name` fields to confirm if it was loaded during the suspicious activity.
-- Correlate the alert with other recent alerts or logs from the same host to identify patterns or repeated suspicious behavior.
-- Review historical data for the same `process.name` and `process.executable` to determine if this is a recurring event or a one-time occurrence.
-- Check for any recent changes or anomalies in the system's configuration or user accounts that might explain the suspicious activity, using system logs and configuration management tools.
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators often use scripts executed via WMI for legitimate purposes such as system maintenance, software deployment, or configuration management. These activities can trigger the detection rule, leading to false positives.
-- Monitoring and management tools: Some enterprise monitoring and management tools use WMI to execute scripts for gathering system information or performing routine tasks, which may be flagged by the rule.
-- Automated software updates: Certain software update mechanisms might use WMI to execute scripts as part of their update process, potentially causing false alerts.
-- To manage these false positives, users can create exceptions for known legitimate scripts or processes by whitelisting specific script names, paths, or user accounts that are verified as non-threatening.
-- Implementing a baseline of normal WMI activity within the organization can help distinguish between expected and suspicious behavior, reducing the likelihood of false positives.
-- Regularly review and update the list of exceptions to ensure that only verified and necessary activities are excluded from detection, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional systems that may have been affected.
-- Analyze the script executed via WMI to understand its purpose and potential impact, and check for any persistence mechanisms it may have established.
-- Terminate any malicious processes identified during the investigation and remove any unauthorized scripts or files from the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and WMI activity, ensuring that future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting WMI access, using application whitelisting, and enforcing the principle of least privilege to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
index cdf660f4773..cfc6a035f4e 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,53 +82,6 @@ process where host.os.type == "windows" and event.type == "start" and
           "\\Device\\HarddiskVolume?\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe"
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft Exchange Server UM Spawning Suspicious Processes
-
-Microsoft Exchange Server's Unified Messaging (UM) integrates voicemail and email, enhancing communication efficiency. However, adversaries can exploit vulnerabilities, such as CVE-2021-26857, to execute unauthorized processes. The detection rule identifies unusual processes initiated by UM services, excluding known legitimate executables, to flag potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and executable path that triggered the alert, focusing on the `process.parent.name` and `process.executable` fields.
-- Verify the legitimacy of the process by checking the parent process `UMService.exe` or `UMWorkerProcess.exe` against known legitimate executables listed in the detection rule.
-- Cross-reference the process executable path with known Exchange Server installation paths to identify any anomalies or deviations.
-- Use Osquery to list all processes spawned by `UMService.exe` or `UMWorkerProcess.exe` to identify any unexpected or suspicious processes:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name IN ('UMService.exe', 'UMWorkerProcess.exe'));
-  ```
-- Investigate the command line arguments (`cmdline`) of the suspicious process to gather more context about its execution.
-- Check the process creation time and correlate it with any known suspicious activity or anomalies in the system logs.
-- Examine the user account context under which the suspicious process was executed to determine if it aligns with expected behavior.
-- Review recent security patches and updates applied to the Exchange Server to ensure CVE-2021-26857 and other vulnerabilities are addressed.
-- Analyze network traffic logs for any unusual outbound connections initiated by the suspicious process to external IP addresses.
-- Consult threat intelligence sources to determine if the identified process or behavior is associated with known threat actors or campaigns exploiting Exchange Server vulnerabilities.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate administrative tools or scripts are executed by the UM services, which are not included in the predefined list of known executables. 
-- Scheduled maintenance tasks or updates that involve UM services might trigger alerts if they spawn processes not recognized by the detection rule.
-- Custom scripts or third-party applications integrated with Exchange Server for enhanced functionality could also be flagged if they initiate processes through UM services.
-- To manage these false positives, users can create exceptions by adding the specific executable paths of these legitimate processes to the exclusion list within the detection rule.
-- Regularly review and update the exclusion list to accommodate any new legitimate processes that are part of routine operations or maintenance activities.
-- Collaborate with IT and security teams to identify and document any custom or third-party applications that interact with UM services to ensure they are accounted for in the detection rule.
-
-### Response and remediation
-
-- Isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify any unauthorized processes or changes made by exploiting CVE-2021-26857, using forensic tools to analyze logs and system changes.
-- Terminate any suspicious processes spawned by the UM service that are not part of the known legitimate executables list.
-- Apply the latest security patches and updates from Microsoft to address CVE-2021-26857 and other known vulnerabilities.
-- Restore the system from a clean backup taken before the compromise, ensuring that the backup is free from any malicious alterations.
-- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) and Intrusion Detection Systems (IDS) to monitor for similar threats.
-- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.
-- Review and update firewall and access control policies to restrict unnecessary exposure of the Exchange Server to the internet.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
index 62cdb4671a5..24a7a35c94a 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/08"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,51 +46,6 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") or
   ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft Exchange Worker Spawning Suspicious Processes
-
-Microsoft Exchange Server uses the worker process (w3wp.exe) to handle web requests, often running under specific application pools. Adversaries exploit this by executing malicious scripts or commands, potentially through web shells, to gain unauthorized access. The detection rule identifies unusual child processes like command-line interpreters spawned by w3wp, signaling possible exploitation or backdoor activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious child processes spawned by `w3wp.exe`, focusing on processes like `cmd.exe`, `powershell.exe`, `pwsh.exe`, and `powershell_ise.exe`.
-- Examine the command-line arguments (`process.parent.args`) associated with the `w3wp.exe` process to identify the specific application pool (`MSExchange*AppPool`) involved, which may provide context on the targeted service.
-- Check the process creation time (`event.type == "start"`) to correlate with any known suspicious activity or incidents reported around the same timeframe.
-- Investigate the parent process (`process.parent.name`) to ensure it is indeed `w3wp.exe` and verify its legitimacy by checking its file path and hash against known good values.
-- Use Osquery to gather additional context on the suspicious processes. For example, run the following query to list all child processes of `w3wp.exe`:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'w3wp.exe');
-  ```
-- Analyze the network connections and traffic associated with the `w3wp.exe` process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control activity.
-- Review the system and security event logs for any additional indicators of compromise or related suspicious activity around the time the alert was triggered.
-- Investigate the user accounts and privileges associated with the `w3wp.exe` process to determine if any unauthorized access or privilege escalation has occurred.
-- Check for any recent changes or anomalies in the Microsoft Exchange Server configuration or application pool settings that could have facilitated the suspicious activity.
-- Correlate the findings with threat intelligence sources to determine if the activity matches any known attack patterns or campaigns targeting Microsoft Exchange Servers.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use command-line tools like cmd.exe or PowerShell for legitimate maintenance activities on the Exchange server, which could trigger the rule. To manage this, create exceptions for known administrative accounts or scheduled tasks that regularly perform these actions.
-- Monitoring and management tools: Some third-party monitoring or management tools might spawn processes from w3wp.exe as part of their normal operation. Identify these tools and exclude their specific process names or hashes from the rule to prevent false alerts.
-- Automated scripts: Legitimate automated scripts running under the MSExchangeAppPool may occasionally invoke command-line interpreters. Review and whitelist these scripts by their specific command-line arguments or script paths to reduce false positives.
-- Software updates: During software updates or patches, certain processes might be temporarily spawned by w3wp.exe. Temporarily disable the rule or adjust its sensitivity during scheduled maintenance windows to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on logs and alerts related to the suspicious processes spawned by w3wp.exe.
-- Terminate any malicious processes identified during the investigation to halt ongoing exploitation activities.
-- Review and analyze web server logs to identify any web shells or unauthorized scripts that may have been uploaded or executed.
-- Apply the latest security patches and updates to the Microsoft Exchange Server to mitigate known vulnerabilities, particularly those related to public-facing applications.
-- Restore the system from a known good backup taken before the compromise, ensuring that any backdoors or malicious modifications are removed.
-- Implement enhanced logging and monitoring policies to capture detailed process creation events and network activity, aiding in future detection and investigation efforts.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate alerts and improve detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train IT staff on the latest threat tactics, techniques, and procedures (TTPs) related to web shell exploitation and public-facing application attacks, leveraging MITRE ATT&CK framework insights."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
index c36ab2d1dc2..3f33d06e360 100644
--- a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
+++ b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/29"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,50 +51,6 @@ process where host.os.type == "windows" and event.type == "start" and
             "/factory,{ceff45ee-c862-41de-aee2-a022c81eda92}"
           )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Explorer Child Process
-
-Windows Explorer, a core component of the Windows operating system, manages file and folder navigation. Adversaries exploit its trusted status to launch malicious scripts or executables, often using it as a parent process to execute harmful payloads via child processes like PowerShell or cmd.exe. The detection rule identifies such anomalies by monitoring for specific child processes initiated by Explorer, excluding benign operations, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a suspicious child process initiated by explorer.exe, focusing on the process names and original file names such as "powershell.exe", "cmd.exe", and others listed in the query.
-- Check the process command line arguments for any unusual or suspicious patterns, especially those not matching the excluded COM Class IDs.
-- Investigate the parent process explorer.exe to determine if it was started with the "-Embedding" argument, which may indicate an attempt to exploit DCOM for malicious purposes.
-- Correlate the event with user activity logs to identify the user account associated with the suspicious process execution and determine if the activity aligns with their typical behavior.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cscript.exe', 'wscript.exe', 'powershell.exe', 'rundll32.exe', 'cmd.exe', 'mshta.exe', 'regsvr32.exe');`
-- Examine the network connections established by the suspicious process using network monitoring tools or logs to identify any unusual or unauthorized external communications.
-- Check for any recent file modifications or creations in directories commonly used by the suspicious process, which may indicate payload delivery or execution.
-- Analyze the system's security logs for any other related events or anomalies around the time of the suspicious process execution, such as failed login attempts or privilege escalation activities.
-- Investigate the system for any known vulnerabilities or misconfigurations that could have been exploited to launch the suspicious process.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, providing additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule as they often use scripts or command-line tools like PowerShell or cmd.exe, which are flagged by the detection rule.
-- System administrators or IT personnel executing scripts for maintenance or configuration purposes might inadvertently match the rule criteria, especially if using remote management tools.
-- Some enterprise applications may use explorer.exe to launch necessary components or scripts, which could be misidentified as suspicious activity.
-- Users can manage these false positives by creating exceptions for known and verified processes or scripts that are frequently executed in their environment.
-- Implementing a whitelist of trusted applications or scripts that are known to use explorer.exe as a parent process can help reduce noise.
-- Regularly review and update the exclusion list to ensure it reflects the current operational environment and any new legitimate software deployments.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the suspicious child process to determine if it is indeed malicious, using endpoint detection and response (EDR) tools.
-- Terminate any malicious processes identified during the investigation to stop ongoing malicious activity.
-- Analyze the parent process (explorer.exe) and its command-line arguments to understand how the malicious process was initiated.
-- Review and collect relevant logs, such as Windows Event Logs and security logs, to gather evidence and understand the scope of the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Implement or enhance logging policies to ensure detailed process creation logs are captured for future investigations.
-- Integrate threat intelligence feeds to correlate detected threats with known attack patterns and adversary tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by removing any malicious files, registry entries, or scheduled tasks, and apply security patches and updates.
-- Harden the system by implementing application whitelisting, disabling unnecessary scripting engines, and enforcing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_webshell_screenconnect_server.toml b/rules/windows/initial_access_webshell_screenconnect_server.toml
index c7f8f3af7f7..c00dfc3018e 100644
--- a/rules/windows/initial_access_webshell_screenconnect_server.toml
+++ b/rules/windows/initial_access_webshell_screenconnect_server.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,48 +54,6 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or
   ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 ScreenConnect Server Spawning Suspicious Processes
-
-ScreenConnect, a remote support tool, allows administrators to control systems remotely. Adversaries may exploit this by executing unauthorized commands or scripts, potentially using it as a vector for deploying web shell backdoors. The detection rule identifies unusual child processes initiated by the ScreenConnect service, flagging potential exploitation or misuse by monitoring for specific command-line utilities and scripting engines.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the parent process is "ScreenConnect.Service.exe" and identify the suspicious child process name and command-line arguments.
-- Check the timestamp of the event to determine when the suspicious process was spawned and correlate it with any known activities or changes in the environment.
-- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
-- Examine the network connections established by the suspicious process to identify any unusual or unauthorized external communications.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'cmd.exe' OR name = 'powershell.exe' AND parent = (SELECT pid FROM processes WHERE name = 'ScreenConnect.Service.exe');`
-- Analyze the command-line arguments of the suspicious process to identify any potentially malicious scripts or commands being executed.
-- Review the system's event logs for any additional indicators of compromise or related suspicious activities around the same timeframe.
-- Check for any recent changes or updates to the ScreenConnect application that could explain the spawning of the suspicious process.
-- Investigate any other alerts or incidents involving the same host or user account to identify patterns or repeated attempts of exploitation.
-- Consult threat intelligence sources to determine if there are any known vulnerabilities or exploits associated with the specific version of ScreenConnect in use.
-
-### False positive analysis
-
-- Routine administrative tasks: ScreenConnect may legitimately spawn processes like cmd.exe or powershell.exe during regular maintenance or updates. Users should verify if these activities align with scheduled tasks or known administrative actions.
-- Automated scripts: Organizations using automated scripts for system management might see these processes triggered by ScreenConnect. It's important to cross-reference with scheduled automation tasks to confirm legitimacy.
-- Software updates: During software updates, ScreenConnect might execute scripts or commands that appear suspicious. Users should check if the timing of these processes coincides with known update schedules.
-- Exclusion methods: To manage false positives, users can create exceptions for known benign activities by whitelisting specific parent-child process relationships or by excluding processes executed during certain time frames associated with legitimate tasks.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or changes made through the ScreenConnect service.
-- Review logs and alerts to identify any additional systems that may have been accessed or compromised using similar methods.
-- Terminate any suspicious processes spawned by ScreenConnect.Service.exe and remove any unauthorized scripts or tools found on the system.
-- Change all credentials associated with the compromised system and any other systems that may have been accessed using the same credentials.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed.
-- Implement enhanced logging and monitoring for ScreenConnect activities, including command-line auditing and process creation events, to detect future suspicious activities.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework mappings to improve detection capabilities and contextual understanding of similar threats.
-- Restore the system from a known good backup to ensure all malicious changes are removed and the system is returned to a secure operational state.
-- Apply security hardening measures, such as restricting ScreenConnect access to authorized users and implementing multi-factor authentication, to reduce the risk of future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_xsl_script_execution_via_com.toml b/rules/windows/initial_access_xsl_script_execution_via_com.toml
index e52ec50672d..4b35a4ed939 100644
--- a/rules/windows/initial_access_xsl_script_execution_via_com.toml
+++ b/rules/windows/initial_access_xsl_script_execution_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -42,48 +42,6 @@ sequence with maxspan=1m
          "?:\\Program Files\\*.exe",
          "?:\\Program Files (x86)\\*exe")] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Remote XSL Script Execution via COM
-
-The Microsoft.XMLDOM COM interface allows applications to parse and transform XML documents using XSL scripts. Adversaries exploit this by embedding malicious scripts in Office documents, triggering execution via Office processes like Word or Excel. The detection rule identifies suspicious activity by monitoring for the loading of specific DLLs and the execution of unexpected child processes, indicating potential script execution abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `msxml3.dll` loaded by Office processes such as `winword.exe`, `excel.exe`, `powerpnt.exe`, or `mspub.exe`, as this indicates potential XSL script execution.
-- Examine the parent process information, specifically the `process.entity_id` and `process.parent.entity_id`, to trace the origin of the suspicious activity and understand the process hierarchy.
-- Check the `process.executable` path of the child processes started by the Office applications to identify any unusual or unexpected executables that do not match known safe paths.
-- Investigate the command line arguments of the suspicious child processes to gather more context on the nature of the execution and any potential scripts or payloads involved.
-- Utilize Osquery to list all running processes and their parent-child relationships to verify the alert findings. Example query: `SELECT pid, name, path, parent FROM processes WHERE name IN ('winword.exe', 'excel.exe', 'powerpnt.exe', 'mspub.exe');`
-- Analyze recent file modifications and creations in directories commonly used by Office applications to identify any new or altered files that could be related to the suspicious activity.
-- Review the system's event logs, particularly security and application logs, for any additional indicators of compromise or related suspicious activities around the time of the alert.
-- Check network logs for any unusual outbound connections initiated by the Office processes, which could indicate data exfiltration or command and control communication.
-- Correlate the alert with any other recent alerts or incidents on the same host to determine if this is part of a broader attack campaign.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors associated with similar techniques, leveraging the MITRE ATT&CK tactic and technique identifiers (TA0001, T1566) for context.
-
-### False positive analysis
-
-- Legitimate business applications or custom scripts that utilize the Microsoft.XMLDOM COM interface for XML parsing and transformation may trigger this detection rule. Users should identify and document these applications to differentiate them from malicious activity.
-- Automated document processing systems that rely on Office applications to handle XML data might also cause false positives. It's important to review these systems and consider creating exceptions for known, safe processes.
-- Some enterprise environments may have scheduled tasks or scripts that execute Office applications with XML processing capabilities. These should be cataloged, and exceptions should be configured to prevent unnecessary alerts.
-- Users can manage false positives by creating exceptions for specific process paths or executable names that are verified as non-malicious. This can be done by updating the detection rule to exclude these known safe processes from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the malicious script.
-- Conduct a thorough investigation to identify the source of the malicious document and any other potentially affected systems.
-- Terminate any suspicious processes identified in the alert, particularly those spawned by Office applications.
-- Remove any malicious files or scripts found on the system, ensuring to check common persistence locations.
-- Restore the system from a known good backup if the integrity of the system is in question.
-- Update antivirus and endpoint protection solutions to ensure they can detect and block similar threats in the future.
-- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze similar threats.
-- Educate users on recognizing phishing attempts and the risks of opening unsolicited Office documents.
-- Review and apply security patches and hardening measures for Microsoft Office and Windows systems to mitigate exploitation risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_alternate_creds_pth.toml b/rules/windows/lateral_movement_alternate_creds_pth.toml
index ec8db41f831..b8afff146d2 100644
--- a/rules/windows/lateral_movement_alternate_creds_pth.toml
+++ b/rules/windows/lateral_movement_alternate_creds_pth.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,49 +32,6 @@ event.category : "authentication" and event.action : "logged-in" and
 winlog.logon.type : "NewCredentials" and event.outcome : "success" and 
 user.id : (S-1-5-21-* or S-1-12-1-*) and winlog.event_data.LogonProcessName : "seclogo"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Pass-the-Hash (PtH) Attempt
-
-Pass-the-Hash (PtH) exploits authentication processes by using stolen password hashes to gain unauthorized access, bypassing the need for plaintext passwords. Adversaries leverage this to move laterally across systems. The detection rule identifies suspicious logins on Windows systems, focusing on successful authentications using specific logon types and processes, indicating potential PtH activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the specific logon type "NewCredentials" and the logon process name "seclogo" to ensure it matches the criteria for a potential PtH attempt.
-- Correlate the user ID (S-1-5-21-* or S-1-12-1-*) with known user accounts to determine if the account is legitimate and if the activity aligns with expected behavior for that user.
-- Examine the source and destination IP addresses associated with the login event to identify if the access originated from an unusual or unauthorized location.
-- Check the timestamp of the event to determine if the login occurred during non-business hours, which could indicate suspicious activity.
-- Investigate the host from which the login attempt was made using Osquery to gather additional context. For example, run the following Osquery query to list recent logon sessions: `SELECT * FROM logged_in_users WHERE user = '<username>';`
-- Analyze the event logs on the involved systems for any preceding or subsequent suspicious activities, such as failed login attempts or unusual process executions.
-- Review any recent changes to user account privileges or group memberships that could have facilitated the PtH attempt.
-- Investigate any other authentication events involving the same user ID across the network to identify patterns or additional instances of suspicious logins.
-- Check for any known vulnerabilities or misconfigurations on the involved systems that could have been exploited to facilitate the PtH attempt.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently using PtH techniques that match the observed behavior.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts that automate tasks may trigger the rule if they use the "NewCredentials" logon type and "seclogo" process, as these can mimic PtH behavior. Users should review the context of such logins to determine if they are part of routine administrative operations.
-- Scheduled tasks or services that require authentication using stored credentials might appear as PtH attempts. To manage these, users can create exceptions for known and verified tasks or services by excluding specific user IDs or hostnames.
-- Security software or network monitoring tools that perform regular checks or audits on systems might generate false positives. Users should identify these tools and exclude their associated processes or user IDs from the detection rule.
-- In environments with single sign-on (SSO) solutions, certain authentication processes might resemble PtH activity. Users should ensure that SSO-related logins are recognized and excluded from the rule by verifying the legitimacy of the logon process and user IDs involved.
-- To handle false positives effectively, users can maintain a whitelist of known non-threatening behaviors, regularly update it based on observed patterns, and apply it to the detection rule to minimize unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to identify the source of the hash theft, reviewing recent changes and access logs for anomalies.
-- Reset passwords for all accounts that were potentially compromised, ensuring that new passwords are strong and unique.
-- Analyze the event logs for other instances of the "seclogo" logon process to identify additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed authentication events, including logon types and processes.
-- Integrate threat intelligence feeds to correlate detected PtH attempts with known threat actor tactics and techniques.
-- Restore the affected system from a known good backup to ensure no malicious code remains.
-- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for hash theft.
-- Implement network segmentation and least privilege access controls to limit the potential impact of future PtH attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_cmd_service.toml b/rules/windows/lateral_movement_cmd_service.toml
index 2a143a6d184..6bc844d0c45 100644
--- a/rules/windows/lateral_movement_cmd_service.toml
+++ b/rules/windows/lateral_movement_cmd_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,49 +43,6 @@ sequence by process.entity_id with maxspan = 1m
       process.args : ("create", "config", "failure", "start")]
   [network where host.os.type == "windows" and process.name : "sc.exe" and destination.ip != "127.0.0.1"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Service Command Lateral Movement
-
-The `sc.exe` utility in Windows is used for managing services, including creating, modifying, or starting them on remote systems. While essential for administrative tasks, adversaries can exploit it for lateral movement by executing malicious services on remote hosts. The detection rule identifies suspicious use of `sc.exe` by monitoring for specific command patterns and network activity, flagging potential unauthorized service manipulations.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `process.entity_id` and `process.name` involved in the suspicious activity.
-- Examine the `process.args` to determine the exact command executed, focusing on arguments like `binPath=*`, `create`, `config`, `failure`, and `start` to understand the service manipulation intent.
-- Check the `destination.ip` field to identify the remote host targeted by the `sc.exe` command and verify if it is a legitimate administrative action or an unauthorized attempt.
-- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior.
-- Correlate the timestamp of the event with other security logs to identify any concurrent suspicious activities or anomalies on the involved systems.
-- Use Osquery to gather additional context on the involved systems. For example, run the following query to list services recently created or modified: `SELECT name, path, start_type, status FROM services WHERE timestamp > (SELECT MAX(timestamp) - 3600 FROM services);`
-- Analyze network logs to trace any unusual connections or data transfers between the source and destination IPs around the time of the alert.
-- Review historical data for similar patterns of `sc.exe` usage across the network to identify potential trends or repeated unauthorized access attempts.
-- Check for any related alerts or incidents involving the same `process.entity_id` or `destination.ip` to assess if this is part of a larger attack campaign.
-- Consult with system administrators to verify if the detected activity was part of routine maintenance or an expected operation, ensuring alignment with organizational policies.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use `sc.exe` for legitimate purposes such as configuring services on remote systems, which can trigger false positives. To manage this, users can create exceptions for known administrative accounts or specific IP addresses frequently used for these tasks.
-- Automated scripts and management tools: Automated processes or management tools that rely on `sc.exe` for service management across multiple machines may also be flagged. Users should identify these scripts or tools and exclude their associated processes or network patterns from the detection rule.
-- Monitoring and management software: Some enterprise monitoring or management software may use `sc.exe` to interact with services on remote hosts. Users can whitelist these applications by their process names or digital signatures to reduce noise.
-- Internal IT operations: Regular IT operations, such as software updates or system maintenance, might involve the use of `sc.exe` across the network. Users should document these operations and adjust the detection rule to exclude them based on time windows or specific network segments.
-- Testing and development environments: In environments where frequent testing or development occurs, `sc.exe` might be used extensively. Users can create exceptions for specific environments or subnets to prevent false positives in these areas.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to confirm the unauthorized use of sc.exe, reviewing logs and correlating with other security events.
-- Identify and terminate any malicious services created or modified by the adversary using sc.exe on the affected and remote systems.
-- Change credentials for any accounts that were used to execute the sc.exe commands, as they may be compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed service creation and modification events, including command-line arguments and network connections.
-- Integrate threat intelligence feeds to correlate detected activity with known adversary tactics, techniques, and procedures (TTPs) from MITRE ATT&CK.
-- Restore the system to its operational state by reinstalling or repairing the operating system and applications, ensuring all patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
-- Harden systems by disabling unnecessary services, enforcing least privilege access, and implementing network segmentation to limit lateral movement opportunities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_hta.toml b/rules/windows/lateral_movement_dcom_hta.toml
index 853c6bd44c4..17625556c65 100644
--- a/rules/windows/lateral_movement_dcom_hta.toml
+++ b/rules/windows/lateral_movement_dcom_hta.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,49 +47,6 @@ sequence with maxspan=1m
      source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1"
   ] by host.id, process.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Incoming DCOM Lateral Movement via MSHTA
-
-DCOM allows software components to communicate over a network, enabling remote execution of applications like MSHTA, which runs HTML applications. Adversaries exploit this by executing commands remotely, bypassing traditional security measures. The detection rule identifies such abuse by monitoring for MSHTA processes initiated with specific arguments and network activity indicative of lateral movement, focusing on unusual port usage and non-local IP addresses.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `mshta.exe` process execution with the `-Embedding` argument, as this is a key indicator of potential DCOM abuse.
-- Verify the source and destination IP addresses involved in the network activity. Ensure that the source IP is not a local address (i.e., not `127.0.0.1` or `::1`) and assess whether the IP is known or expected within the network.
-- Check the source and destination ports used in the network connection. Ports greater than 49151 are typically dynamic and may indicate unusual activity.
-- Correlate the `host.id` and `process.entity_id` from the alert with other logs to identify any related processes or activities on the same host.
-- Use Osquery to gather additional context on the `mshta.exe` process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, parent, path, cmdline FROM processes WHERE name = 'mshta.exe';`
-- Investigate the parent process of `mshta.exe` to determine if it was spawned by a legitimate application or if it is part of a suspicious chain of execution.
-- Examine recent login events on the affected host to identify any unusual or unauthorized access attempts that may correlate with the alert.
-- Review any recent changes to the system's DCOM configuration or related registry keys that could indicate tampering or preparation for lateral movement.
-- Analyze network traffic logs for any other unusual or unexpected connections originating from or targeting the affected host around the time of the alert.
-- Consult threat intelligence sources to determine if the observed IP addresses or behavior patterns are associated with known threat actors or campaigns.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts that utilize MSHTA for remote management tasks may trigger this rule. Users should identify and document these tools to differentiate them from malicious activity.
-- Automated software deployment or update processes that use MSHTA for executing scripts across the network can be mistaken for lateral movement. Exclude these processes by creating exceptions based on known source IP addresses and process arguments.
-- Internal network scanning or monitoring tools that simulate lateral movement for security assessments might be flagged. Ensure these tools are whitelisted by their specific network and process characteristics.
-- Developers or IT personnel testing applications that involve remote execution via MSHTA could inadvertently trigger alerts. Establish a list of authorized personnel and their associated activities to prevent false positives.
-- In environments where MSHTA is used for legitimate inter-process communication, especially in legacy systems, consider excluding specific host IDs or process entity IDs that are known to engage in benign activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation to identify the source of the DCOM abuse, including reviewing logs for unusual MSHTA activity and correlating with other security events.
-- Terminate any suspicious MSHTA processes identified during the investigation to halt any ongoing malicious activity.
-- Reset credentials for any accounts that may have been compromised during the attack to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on DCOM and MSHTA usage.
-- Integrate threat intelligence feeds to improve detection capabilities for known indicators of compromise related to DCOM lateral movement.
-- Restore the affected system from a known good backup to ensure it is free from any malicious modifications.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for DCOM abuse.
-- Review and update security policies and configurations to harden systems against similar attacks, including disabling unnecessary DCOM components and restricting MSHTA usage."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_mmc20.toml b/rules/windows/lateral_movement_dcom_mmc20.toml
index e592a0a39db..fd2ad45bc02 100644
--- a/rules/windows/lateral_movement_dcom_mmc20.toml
+++ b/rules/windows/lateral_movement_dcom_mmc20.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,51 +47,6 @@ sequence by host.id with maxspan=1m
  [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe"
  ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Incoming DCOM Lateral Movement with MMC
-
-Distributed Component Object Model (DCOM) allows software components to communicate over a network, often used in Windows environments for remote management. Adversaries exploit DCOM to execute commands remotely, leveraging applications like MMC20. The detection rule identifies suspicious activity by monitoring network traffic and process creation patterns, focusing on remote command execution via MMC, which may indicate lateral movement attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious network activity involving `mmc.exe` with high source and destination ports (>= 49152), indicating potential DCOM exploitation.
-- Verify the source and destination IP addresses involved in the alert to determine if the source IP is external or internal, and assess the legitimacy of the connection.
-- Check the process creation logs to identify the parent process of `mmc.exe` and ensure it aligns with expected behavior; unexpected parent processes may indicate malicious activity.
-- Investigate the timeline of events by correlating the `process.entity_id` and `process.parent.entity_id` to understand the sequence of process creation and network activity.
-- Use Osquery to gather additional context on the host by running a query to list all processes related to `mmc.exe`:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'mmc.exe';
-  ```
-- Examine the command line arguments of `mmc.exe` to identify any unusual or unauthorized commands that may have been executed.
-- Analyze the network traffic logs to identify any other suspicious connections or patterns that coincide with the alert timeframe, focusing on the `network.direction` and `network.transport` fields.
-- Cross-reference the alert with other security logs, such as Windows Event Logs, to identify any related authentication attempts or anomalies around the same time.
-- Investigate the user account associated with the `mmc.exe` process to determine if it has been compromised or is being used in an unauthorized manner.
-- Review historical data for similar alerts or patterns involving `mmc.exe` to assess if this is an isolated incident or part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use MMC for legitimate remote management tasks, which can trigger the rule. To manage this, users can create exceptions for known administrator accounts or specific IP addresses that regularly perform these tasks.
-- Automated scripts or management tools: Some organizations use automated scripts or third-party management tools that leverage DCOM and MMC for routine operations. Users can exclude these processes by identifying their unique characteristics, such as specific command-line arguments or process hashes.
-- Software updates and patches: Certain software updates or patches might use DCOM and MMC to apply changes across the network. Users should monitor update schedules and exclude related activities during these periods to avoid false positives.
-- Internal network scanning tools: Security teams might use network scanning tools that interact with MMC for vulnerability assessments. Users can whitelist these tools by their source IP addresses or specific network ranges to prevent false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation of the affected host to identify any unauthorized access or changes, focusing on the processes initiated by mmc.exe.
-- Review network logs and traffic patterns to identify other potentially compromised systems or lateral movement attempts.
-- Terminate any suspicious processes associated with the DCOM exploitation and remove any unauthorized scheduled tasks or services.
-- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited via DCOM.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process creation and network activity, ensuring that future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by reinstalling the operating system if necessary and restoring data from verified backups.
-- Harden the environment by disabling unnecessary DCOM services and configuring firewall rules to restrict high-numbered ports used for DCOM communication."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
index ff221416a8e..0ae4173fb6c 100644
--- a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
+++ b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,52 +47,6 @@ sequence by host.id with maxspan=5s
   process.parent.name : "explorer.exe"
  ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows
-
-DCOM allows software components to communicate over a network, enabling remote execution of applications. Adversaries exploit this by using ShellBrowserWindow or ShellWindows to execute commands stealthily on remote systems. The detection rule identifies such activity by monitoring network traffic and process creation patterns, specifically looking for remote command execution initiated by explorer.exe, which may indicate lateral movement attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of network traffic and process creation patterns that match the rule criteria, focusing on the involvement of `explorer.exe` and the specified port range.
-- Verify the source IP address to determine if it is an expected or known entity within the network, ensuring it is not a loopback address like `127.0.0.1` or `::1`.
-- Check the destination IP address and port to identify the target system and service involved in the potential lateral movement attempt.
-- Investigate the process tree for `explorer.exe` to identify any unusual child processes that may have been spawned, indicating potential malicious activity.
-- Use Osquery to gather additional context on the involved processes. For example, run the following query to list processes with `explorer.exe` as the parent:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'explorer.exe');
-  ```
-- Examine the network traffic logs for any other suspicious connections or patterns that coincide with the time of the alert, focusing on the `source.port` and `destination.port` fields.
-- Correlate the alert with other security events or logs from the same time period to identify any additional indicators of compromise or related activities.
-- Check for any recent changes or anomalies in user accounts or permissions on the involved systems that could facilitate lateral movement.
-- Review historical data for similar alerts or patterns involving the same source or destination IP addresses to assess if this is part of a broader attack campaign.
-- Consult threat intelligence sources to determine if there are any known threats or campaigns that match the observed behavior, leveraging the MITRE ATT&CK framework references (TA0008, T1021) for context.
-
-### False positive analysis
-
-- Legitimate administrative tools or software updates may trigger the rule if they use DCOM for remote management or updates, as these processes can mimic the behavior of lateral movement attempts.
-- Network monitoring solutions or security software that perform regular scans or updates across the network might also cause false positives by initiating connections that resemble the described pattern.
-- Users can manage these false positives by creating exceptions for known and trusted IP addresses or specific process names that are verified to be part of legitimate operations.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-- Consider implementing additional context checks, such as verifying the source of the network traffic or correlating with other security events, to differentiate between benign and malicious activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation to identify the source of the DCOM exploitation, including reviewing network logs and process creation events.
-- Terminate any suspicious processes that were initiated by explorer.exe and are not part of normal operations.
-- Reset credentials for any accounts that were used during the lateral movement attempt to prevent unauthorized access.
-- Apply patches and updates to the operating system and any vulnerable applications to mitigate the exploited vulnerability.
-- Implement enhanced logging policies to capture detailed network and process activity, focusing on DCOM-related events and explorer.exe executions.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system from a known good backup to ensure no malicious artifacts remain on the system.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Harden the environment by disabling unnecessary DCOM components and configuring firewalls to restrict high-numbered ports used in the attack."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
index 40032b4ffe0..74e5284a1ad 100644
--- a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
+++ b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,49 +48,6 @@ registry.path : (
 ) and length(registry.data.strings) > 0 and
 not registry.data.strings : "(empty)"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 NullSessionPipe Registry Modification
-
-The NullSessionPipe registry setting in Windows environments defines which named pipes can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to allow unauthorized access, aiding lateral movement within a network. The detection rule identifies changes to this registry path, focusing on non-empty modifications, to flag potential misuse indicative of adversarial activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path matches one of the specified paths in the query: "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes", "\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes", or "MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes".
-- Check the event type to ensure it is a "change" event, indicating a modification to the registry.
-- Examine the registry data strings to identify which named pipes have been added or modified, ensuring they are not empty or marked as "(empty)".
-- Correlate the timestamp of the registry change event with other logs to identify any suspicious activities or patterns around the same time, such as unusual logins or file access.
-- Investigate the user account or process responsible for the registry modification to determine if it is a known and authorized entity.
-- Use Osquery to further investigate the registry modification by running a query such as: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\services\\\\LanmanServer\\\\Parameters\\\\NullSessionPipes';` to gather more details about the current state of the registry key.
-- Analyze network traffic logs to detect any unusual or unauthorized access attempts to the named pipes specified in the registry modification.
-- Review historical data to determine if similar registry modifications have occurred in the past and assess if there is a pattern or recurring threat actor involved.
-- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or evidence of lateral movement attempts.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors that commonly exploit NullSessionPipe modifications for lateral movement.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify the NullSessionPipe registry setting to facilitate necessary communication between components, which can trigger false positives. Users should verify if the modification aligns with recent software changes or updates.
-- Network management tools or legitimate administrative scripts might alter the NullSessionPipe settings to enable specific functionalities, leading to benign registry changes. Users can create exceptions for known tools or scripts that are part of regular network operations.
-- Certain enterprise applications may require anonymous access to specific named pipes for proper functionality. Users should document and exclude these applications from triggering alerts by adding them to an exception list.
-- Regular audits and reviews of registry changes can help identify patterns of benign modifications, allowing users to refine detection rules and reduce false positives by excluding these patterns.
-- Collaboration with IT and security teams to maintain an updated list of approved applications and tools that interact with the NullSessionPipe registry can help in managing exceptions effectively.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized modifications to the NullSessionPipe registry setting and determine the scope of the compromise.
-- Review recent changes in the registry and correlate them with user activity logs to identify potential malicious actors or compromised accounts.
-- Restore the NullSessionPipe registry setting to its default state to eliminate unauthorized anonymous access.
-- Implement enhanced logging and monitoring for registry changes, focusing on critical paths like NullSessionPipes, to detect future unauthorized modifications.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Review and update access controls and permissions for sensitive systems to ensure that only authorized users have access to modify critical registry settings.
-- Conduct a security audit of the network to identify and remediate other potential vulnerabilities that could be exploited for lateral movement.
-- Implement network segmentation to limit the spread of threats and reduce the attack surface for lateral movement.
-- Educate users and administrators on the risks associated with unauthorized registry modifications and the importance of maintaining secure configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
index f4a52a9f0e9..1e1e22abd20 100644
--- a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
+++ b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/12"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,53 +66,6 @@ any where host.os.type == "windows" and
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Remote Desktop Shadowing Activity
-
-Remote Desktop Shadowing allows administrators to view or control active RDP sessions, aiding in support and troubleshooting. However, adversaries can exploit this feature to monitor or hijack user sessions without consent. The detection rule identifies suspicious registry changes and process executions linked to shadowing, flagging potential unauthorized access attempts by monitoring specific registry paths and process activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the specific registry path or process that triggered the alert, focusing on the `registry.path` and `process.name` fields.
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
-- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the source IP address and hostname of the machine where the activity was detected to identify if it is a known and trusted device.
-- Use Osquery to list all current RDP sessions on the host to identify any active shadowing sessions:
-  ```sql
-  SELECT * FROM rdp_connections;
-  ```
-- Query the Windows Event Logs for any related events around the time of the alert, focusing on Event ID 1149 (RDP connection) and Event ID 4624 (successful logon).
-- Investigate the parent process `svchost.exe` to determine if it has any unusual child processes or command-line arguments that could indicate malicious activity.
-- Check for any recent changes to the registry path `HKLM\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow` to identify unauthorized modifications.
-- Review the process execution history on the host to identify any instances of `mstsc.exe` with the `/shadow:*` argument, which could indicate shadowing attempts.
-- Analyze network traffic logs to identify any unusual outbound connections from the host that could suggest data exfiltration or communication with a command and control server.
-
-### False positive analysis
-
-- Legitimate administrative activities: System administrators may use Remote Desktop Shadowing for valid support and troubleshooting purposes, leading to benign registry changes or process executions. 
-- Scheduled maintenance tasks: Automated scripts or scheduled tasks might trigger similar registry modifications or process starts as part of routine system maintenance.
-- Third-party remote support tools: Some remote support applications may mimic RDP shadowing behavior, causing similar registry and process activity.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific maintenance windows where such activities are expected.
-- Implementing a whitelist for trusted third-party remote support tools can help reduce unnecessary alerts.
-- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the unauthorized RDP shadowing activity by reviewing logs and correlating with other security events.
-- Terminate any suspicious RDP sessions and processes identified during the investigation to stop ongoing unauthorized access.
-- Change passwords for all accounts that were active during the suspicious RDP sessions to prevent further unauthorized access.
-- Review and update the RDP configuration settings to ensure that shadowing requires user consent and is logged appropriately.
-- Implement enhanced logging policies to capture detailed RDP session activities, including shadowing attempts, for future investigations.
-- Integrate security solutions such as SIEM and EDR to provide real-time monitoring and alerting on suspicious RDP activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Restore the system to its operational state by applying the latest security patches and updates, and conducting a full malware scan.
-- Harden the system by disabling unnecessary RDP features, enforcing strong authentication mechanisms, and regularly reviewing user access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
index 2e610cce520..d5fa197c1de 100644
--- a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
+++ b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,48 +53,6 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.executable : "\\Device\\Mup\\tsclient\\*.exe"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution via TSClient Mountpoint
-
-The TSClient mountpoint is a feature of the Remote Desktop Protocol (RDP) that allows users to access local drives from a remote session. Adversaries can exploit this by executing malicious binaries from the shared mountpoint, facilitating lateral movement within a network. The detection rule identifies such activities by monitoring for process executions originating from the TSClient path, indicating potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process execution path matches the pattern `\\\\Device\\\\Mup\\\\tsclient\\\\*.exe`, indicating execution from the TSClient mountpoint.
-- Identify the user account associated with the process execution to determine if it aligns with expected user behavior or if it might be compromised.
-- Check the timestamp of the process execution to correlate with any other suspicious activities or anomalies in the network around the same time.
-- Investigate the parent process of the executed binary to understand how the execution was initiated and if it was part of a legitimate workflow.
-- Use Osquery to list all processes executed from the TSClient mountpoint with a query like: `SELECT pid, name, path, cmdline, start_time FROM processes WHERE path LIKE '\\\\Device\\\\Mup\\\\tsclient\\\\%';` to gather more context on the execution.
-- Examine the network connections from the host at the time of the alert to identify any unusual outbound connections that might indicate data exfiltration or further lateral movement.
-- Review the security logs on the host for any failed login attempts or other authentication anomalies that could suggest unauthorized access.
-- Check for any recent changes to user permissions or group memberships that might have facilitated the execution from the TSClient mountpoint.
-- Analyze any related file modifications or creations on the host to identify if the executed binary made any unauthorized changes to the system.
-- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to build a comprehensive picture of the potential threat.
-
-### False positive analysis
-
-- Legitimate administrative activities: System administrators may use the TSClient mountpoint to execute scripts or administrative tools for maintenance and troubleshooting purposes. These activities can be mistaken for malicious behavior.
-- Software updates and installations: IT personnel might deploy software updates or install applications via the TSClient path, triggering the detection rule.
-- Automated backup or synchronization tools: Some organizations use automated tools that access local drives through RDP for backup or file synchronization, which could be flagged as suspicious.
-- To manage these false positives, users can create exceptions for known and verified administrative accounts or specific executable paths that are frequently used for legitimate purposes. This can be done by updating the detection rule to exclude certain user accounts or executable names that are identified as non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Verify the execution of any suspicious binaries from the TSClient path and terminate any malicious processes identified.
-- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise or persistence mechanisms.
-- Review RDP access logs to identify unauthorized access attempts and determine the source of the intrusion.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed RDP session activities and process execution events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by removing any malicious files, applying security patches, and ensuring system integrity.
-- Harden RDP configurations by enforcing strong authentication methods, limiting access to trusted IP addresses, and disabling unnecessary features.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans based on lessons learned."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
index 8759b59f806..f3a096eded1 100644
--- a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
+++ b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,49 +48,6 @@ sequence by host.id with maxspan=30s
    [process where host.os.type == "windows" and 
     event.type == "start" and process.parent.name : "winrshost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Incoming Execution via WinRM Remote Shell
-
-Windows Remote Management (WinRM) facilitates remote command execution and management, crucial for system administration. However, adversaries exploit it for lateral movement by executing commands on remote systems. The detection rule identifies such abuse by monitoring network traffic for incoming connections on WinRM ports and subsequent suspicious process starts, indicating potential unauthorized remote shell activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of incoming network connections on WinRM ports (5985, 5986) and verify the network direction is "incoming" or "ingress".
-- Check the source IP address of the incoming connection to determine if it is from a known or trusted source. Investigate any unfamiliar or suspicious IP addresses.
-- Examine the process start event to identify the process that was initiated by "winrshost.exe". Pay attention to the process name and executable path to determine if it is expected or potentially malicious.
-- Use Osquery to list all processes currently running on the host to identify any unusual or unexpected processes. Example query: `SELECT pid, name, path FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'winrshost.exe');`
-- Investigate the parent-child process relationship to understand the context of the process execution. Look for any anomalies in the process tree that could indicate malicious activity.
-- Analyze the network traffic logs to identify any additional connections from the same source IP or to the same destination port that could indicate further lateral movement attempts.
-- Check the Windows Event Logs, particularly Security and System logs, for any related events around the time of the alert to gather more context on the activity.
-- Review the host's security configuration and WinRM settings to ensure they are in line with best practices and have not been altered to allow unauthorized access.
-- Investigate any recent changes or updates on the host that could have introduced vulnerabilities or misconfigurations exploited by the adversary.
-- Correlate the findings with other alerts or incidents in the environment to determine if this activity is part of a larger attack campaign or isolated incident.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often use WinRM for legitimate remote management tasks, which can trigger the rule. To manage this, users can create exceptions for known administrative IP addresses or user accounts frequently performing these tasks.
-- Automated scripts and tools: Automated scripts or management tools that utilize WinRM for routine operations may also cause false positives. Users should identify these scripts and tools and exclude their associated processes or IP addresses from the rule.
-- Monitoring and security software: Some security and monitoring solutions use WinRM to gather data from remote systems, potentially triggering the rule. Users can whitelist these solutions by excluding their process names or network traffic patterns.
-- Internal network scans: Internal network scans or vulnerability assessments that interact with WinRM ports might be flagged. Users should coordinate with IT teams to recognize these activities and exclude them from detection.
-- Testing environments: In testing or development environments, frequent use of WinRM for testing purposes can lead to false positives. Users can exclude these environments by specifying their IP ranges or hostnames.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation to identify the source of the WinRM connection, including reviewing logs for unusual login attempts or unauthorized access.
-- Terminate any suspicious processes associated with the WinRM remote shell activity, particularly those not originating from legitimate administrative tasks.
-- Change credentials for any accounts that were used during the unauthorized WinRM session to prevent further unauthorized access.
-- Review and enhance logging policies to ensure detailed monitoring of WinRM activities, including successful and failed login attempts, and process creation events.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate WinRM activity with known threat indicators.
-- Restore the system to its operational state by applying the latest security patches and updates, and verifying the integrity of critical system files.
-- Implement network segmentation to limit the ability of adversaries to move laterally within the network using remote services like WinRM.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on secure remote management practices and the risks associated with improper use of WinRM."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_incoming_wmi.toml b/rules/windows/lateral_movement_incoming_wmi.toml
index 6d3c8704351..0c695c6002d 100644
--- a/rules/windows/lateral_movement_incoming_wmi.toml
+++ b/rules/windows/lateral_movement_incoming_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,50 +59,6 @@ sequence by host.id with maxspan = 2s
    not (process.executable : "?:\\Windows\\System32\\inetsrv\\appcmd.exe" and process.args : "uninstall")
    ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WMI Incoming Lateral Movement
-
-Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing processes remotely, often bypassing traditional security controls. The detection rule identifies suspicious WMI activity by monitoring specific network connections and process executions, while filtering out common false positives, to flag potential unauthorized lateral movements.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host.id and timestamp of the suspicious activity to establish a timeline.
-- Examine the network connection details, focusing on the source.ip and destination.port, to determine if the connection originated from a known or trusted source.
-- Check the process.name and process.parent.name fields to verify if the svchost.exe and WmiPrvSE.exe processes are behaving as expected or if they are associated with any known malicious activity.
-- Investigate the user.id associated with the process execution to determine if it aligns with expected administrative activity or if it could indicate unauthorized access.
-- Analyze the process.executable path to identify any unusual or unexpected executables being launched, especially those not excluded by the rule.
-- Utilize Osquery to gather additional context on the host by running a query such as: `SELECT * FROM processes WHERE name = 'WmiPrvSE.exe' OR name = 'svchost.exe';` to list all instances and their command-line arguments.
-- Cross-reference the source.ip with known threat intelligence feeds to check for any history of malicious activity associated with the IP address.
-- Review recent security logs and events on the affected host to identify any other suspicious activities or anomalies around the time of the alert.
-- Check for any recent changes in user permissions or group memberships that could explain the unexpected WMI activity.
-- Consult with system administrators to confirm if the detected WMI activity aligns with any legitimate remote management tasks or scheduled maintenance activities.
-
-### False positive analysis
-
-- Known false positives for the WMI Incoming Lateral Movement rule include legitimate administrative activities where WMI is used for remote management, such as software deployment or system configuration tasks.
-- Common tools that may trigger false positives include Nessus and SCCM, which are often used for network scanning and system management, respectively.
-- To manage these false positives, users can create exceptions for specific processes or user accounts that are known to perform legitimate WMI activities. This can be done by excluding certain process executables or user IDs from the detection rule.
-- Users should regularly review and update their exclusion lists to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-- It is important to monitor the integrity level of processes, as legitimate administrative tasks typically run with higher integrity levels, which can be used as a criterion for exclusion.
-- By understanding the context of WMI usage within their environment, users can better distinguish between legitimate and suspicious activities, reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Isolate the affected host from the network to prevent further lateral movement and contain the threat.
-- Verify the legitimacy of the WMI activity by checking if it aligns with known administrative tasks or scheduled jobs.
-- Conduct a thorough investigation of the affected host to identify any unauthorized changes or additional malicious activity.
-- Review and analyze network logs and WMI logs to trace the source of the lateral movement and identify other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed to be malicious.
-- Remove any unauthorized accounts or processes identified during the investigation and reset credentials for affected accounts.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Implement enhanced logging policies to capture detailed WMI activity and network connections for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Apply hardening measures such as restricting WMI access to only necessary accounts and implementing network segmentation to limit lateral movement opportunities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
index 4edf203b40a..9f0ca208eae 100644
--- a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
+++ b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/02"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,49 +57,6 @@ process where host.os.type == "windows" and event.type == "start" and
  /* excluding shares deletion operation */
  not process.args : "/d*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Mounting Hidden or WebDav Remote Shares
-
-WebDav and hidden remote shares facilitate file sharing and collaboration over networks, often used in enterprise environments. Adversaries exploit these to move laterally or exfiltrate data by mounting shares using tools like net.exe. The detection rule identifies suspicious use of net.exe to mount such shares, focusing on patterns indicative of hidden or WebDav shares, while excluding benign operations like share deletions.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `net.exe` or `net1.exe` in the process name or original file name, as this is crucial for identifying the suspicious activity.
-- Examine the process arguments to verify the use of the "use" command, which indicates an attempt to mount a share.
-- Check for the presence of patterns in the process arguments that match hidden or WebDav shares, such as `\\\\*\\\\*$*`, `\\\\*@SSL\\\\*`, or `http*`, to confirm the nature of the share being accessed.
-- Investigate the parent process of `net1.exe` to ensure it is not `net.exe`, as this could indicate a legitimate operation.
-- Look for any exclusion patterns in the process arguments, such as `/d*`, to rule out share deletion operations.
-- Use Osquery to gather additional context about the process by running a query like: `SELECT * FROM processes WHERE name = 'net.exe' OR name = 'net1.exe';` to obtain details such as process ID, parent process, and command line arguments.
-- Correlate the event with other logs to identify any preceding or subsequent suspicious activities, such as unusual network connections or file access patterns.
-- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
-- Check for any recent changes in user permissions or group memberships that could facilitate unauthorized access to remote shares.
-- Review network traffic logs to identify any data exfiltration attempts or connections to known malicious IP addresses associated with the mounted shares.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use net.exe to mount hidden or WebDav shares for routine maintenance or configuration tasks. To manage these, users can create exceptions for known administrative accounts or specific time windows when such activities are expected.
-- Automated scripts and tools: Some enterprise environments use automated scripts or third-party tools that rely on net.exe to manage network shares. Users should identify these scripts and tools and exclude their associated processes or command patterns from the detection rule.
-- Backup and synchronization software: Applications like backup solutions or file synchronization services (e.g., OneDrive) might use similar commands to access remote shares. Users can handle these by excluding processes associated with these applications or by specifying known safe network paths.
-- Testing and development environments: In environments where testing of network configurations or software development occurs, net.exe might be used frequently. Users should consider excluding specific development machines or user accounts from the detection rule to reduce noise.
-- User training and awareness: Educating users about the legitimate use of network shares and monitoring for unusual patterns can help distinguish between benign and suspicious activities, allowing for more accurate tuning of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on recent use of net.exe and net1.exe for mounting shares.
-- Review and analyze logs from the affected system and any connected systems to trace the adversary's activities and identify any additional compromised systems.
-- Remove any unauthorized mounted shares and terminate any suspicious processes related to net.exe or net1.exe.
-- Change all potentially compromised credentials and enforce multi-factor authentication to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring visibility into future suspicious activities.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for future incidents.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
-- Harden the environment by disabling unnecessary services, enforcing least privilege access, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_powershell_remoting_target.toml b/rules/windows/lateral_movement_powershell_remoting_target.toml
index 1f1d148d748..d819cf2f387 100644
--- a/rules/windows/lateral_movement_powershell_remoting_target.toml
+++ b/rules/windows/lateral_movement_powershell_remoting_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,52 +52,6 @@ sequence by host.id with maxspan = 30s
    [process where host.os.type == "windows" and 
     event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Incoming Execution via PowerShell Remoting
-
-PowerShell Remoting enables administrators to execute commands on remote Windows systems, facilitating efficient management. However, adversaries can exploit this for lateral movement by executing commands on compromised machines. The detection rule identifies such abuse by monitoring network traffic on specific ports and correlating it with suspicious process activities, indicating potential unauthorized remote command execution.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host.id and timestamp of the suspicious activity to focus the investigation on the relevant system and timeframe.
-- Examine network logs to verify the presence of incoming network traffic on ports 5985 or 5986, which are used for PowerShell Remoting, and confirm the source IP address is external and not a known or trusted internal IP.
-- Check for any recent process start events on the affected host where the parent process is "wsmprovhost.exe" and the child process is not "conhost.exe", indicating potential unauthorized command execution.
-- Use Osquery to list all processes on the affected host that have "wsmprovhost.exe" as a parent process to identify any unusual or unexpected child processes:
-  ```sql
-  SELECT pid, name, path, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'wsmprovhost.exe');
-  ```
-- Investigate the source IP address by checking if it is associated with any known malicious activity or if it belongs to an external network that should not have access to the internal systems.
-- Correlate the timing of the network activity with any user logins or scheduled tasks on the affected host to determine if the activity aligns with legitimate administrative actions.
-- Review Windows Event Logs on the affected host for any additional context around the time of the alert, focusing on security and system logs for any anomalies or related events.
-- Check for any recent changes in user accounts or permissions on the affected host that could indicate unauthorized access or privilege escalation.
-- Analyze any command-line arguments or scripts executed by the suspicious processes to understand the intent and potential impact of the activity.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Scheduled administrative tasks: Regularly scheduled tasks by IT administrators using PowerShell Remoting for legitimate system management can trigger this rule. Users can handle these by creating exceptions for known administrative IP addresses or specific time windows when these tasks are expected to occur.
-- Automated scripts: Automated scripts that use PowerShell Remoting for system monitoring or maintenance might be flagged. To manage this, users can whitelist specific scripts or processes that are verified as non-threatening.
-- Internal security tools: Some security tools use PowerShell Remoting for scanning or compliance checks. Users should identify these tools and exclude their activities from triggering alerts by specifying their process names or executable paths.
-- Development and testing environments: In environments where developers frequently use PowerShell Remoting for testing purposes, these activities might be mistaken for lateral movement. Users can exclude specific development machines or user accounts from the rule to reduce false positives.
-- Remote management software: Software that relies on PowerShell Remoting for remote management might be misinterpreted as suspicious activity. Users should identify such software and configure exceptions based on the software's known network behavior or process characteristics.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Verify the legitimacy of the PowerShell remoting activity by contacting the system owner or administrator to confirm if the activity was authorized.
-- Conduct a thorough investigation of the affected system to identify any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
-- Review network logs and endpoint detection logs to trace the source of the unauthorized access and identify any other potentially compromised systems.
-- If unauthorized access is confirmed, reset credentials for affected accounts and implement multi-factor authentication to prevent future unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the breach.
-- Restore the affected system from a known good backup to ensure that any malicious changes are removed.
-- Implement enhanced logging policies to capture detailed PowerShell activity and network traffic for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Apply system hardening measures, such as disabling unnecessary services and ports, to reduce the attack surface and prevent exploitation of remote services."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_rdp_sharprdp_target.toml b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
index d155d4aeed9..ea6733fab44 100644
--- a/rules/windows/lateral_movement_rdp_sharprdp_target.toml
+++ b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -51,48 +51,6 @@ sequence by host.id with maxspan=1m
    not process.name : "conhost.exe"
    ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential SharpRDP Behavior
-
-Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement within a network, using tools like SharpRDP to execute commands on remote machines. The detection rule identifies suspicious RDP activity by monitoring for specific registry changes and process executions, indicating potential misuse of RDP for unauthorized access.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host.id where the suspicious activity was detected, as this will be the focal point of the investigation.
-- Examine the network event logs to confirm the presence of incoming RDP connections on port 3389, noting the source IP address and ensuring it is not a loopback address (127.0.0.1 or ::1).
-- Investigate the registry change event to verify the modification of the RunMRU registry key by the process explorer.exe, focusing on the presence of suspicious strings such as cmd.exe, powershell.exe, taskmgr, or \\\\tsclient\\\\*.exe.
-- Analyze the process execution logs to identify any processes started with parent processes cmd.exe, powershell.exe, or taskmgr.exe, and ensure that conhost.exe is not the process name.
-- Correlate the timestamps of the network, registry, and process events to confirm they occurred within the specified 1-minute window, indicating a sequence of potentially malicious actions.
-- Use Osquery to gather additional context on the affected host by running a query to list recent RDP sessions: `SELECT * FROM rdp_connections WHERE state = 'active';` to identify any unusual or unauthorized sessions.
-- Investigate the user account associated with the RDP session to determine if it is a legitimate user or potentially compromised, checking for any anomalies in login patterns or privileges.
-- Check for any additional registry changes or process executions on the host that might indicate further malicious activity or persistence mechanisms.
-- Review historical data for the source IP address to determine if it has been involved in previous suspicious activities or if it is known to be associated with malicious behavior.
-- Consult threat intelligence sources to gather information on SharpRDP and similar tools, assessing if there are any known indicators of compromise (IOCs) that match the observed activity.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use RDP for routine maintenance and troubleshooting, which can trigger the detection rule if they execute commands like cmd, powershell, or taskmgr. To manage this, users can create exceptions for known administrator accounts or specific IP addresses that regularly perform these tasks.
-- Automated scripts: Some organizations use automated scripts that remotely execute commands via RDP for software updates or system checks. These scripts might mimic SharpRDP behavior. Users can exclude these scripts by identifying their unique process names or command-line arguments and adding them to an exception list.
-- Remote support tools: Third-party remote support tools may use similar mechanisms to SharpRDP for legitimate remote assistance. Users should identify these tools and exclude their associated processes or network activities from the detection rule.
-- Testing environments: In environments where security testing or penetration testing is conducted, SharpRDP or similar tools might be used intentionally. Users can exclude specific testing IP ranges or hostnames to prevent false positives during these activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement and unauthorized access.
-- Conduct a thorough investigation to confirm the presence of SharpRDP or similar tools by analyzing logs and system artifacts.
-- Terminate any suspicious processes identified during the investigation, particularly those related to cmd.exe, powershell.exe, taskmgr.exe, or tsclient.
-- Review and restore any altered registry settings to their original state to prevent unauthorized command execution.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed RDP session activities, registry changes, and process executions for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
-- Educate users and administrators on secure RDP practices and the risks associated with unauthorized remote access tools.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
index a6157ad447a..232552123a3 100644
--- a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
+++ b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,49 +55,6 @@ process where host.os.type == "windows" and event.type == "start" and
     process.name : "robocopy.exe"
   ) and process.args : "*\\\\*\\*$*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Remote File Copy to a Hidden Share
-
-In Windows environments, hidden network shares are often used for legitimate administrative tasks, allowing file transfers without user visibility. However, adversaries exploit these shares for lateral movement or data exfiltration by copying files remotely. The detection rule identifies suspicious activities by monitoring command-line tools like cmd.exe and powershell.exe for file operations targeting hidden shares, flagging potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name (e.g., cmd.exe, powershell.exe, xcopy.exe, robocopy.exe) and arguments used, focusing on those that match the query criteria such as "copy*", "move*", "cp", "mv", and paths containing "*\\\\\\\\*\\\\*$*".
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time for additional context.
-- Identify the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
-- Investigate the source and destination IP addresses involved in the file copy operation to assess if they are part of the organization's network or if they are external and potentially malicious.
-- Examine the parent process of the flagged process to understand how the suspicious process was initiated and if it was part of a larger chain of events.
-- Use Osquery to gather additional context about the system involved. For example, run the following query to list all network shares on the system: `SELECT * FROM shares WHERE name LIKE '%$';`
-- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized access to hidden shares.
-- Review system logs for any other unusual activities or errors that coincide with the time of the alert, which might indicate a broader attack or misconfiguration.
-- Investigate any recent login attempts or authentication failures on the involved systems to identify potential unauthorized access attempts.
-- Cross-reference the event with known threat intelligence sources to determine if the IP addresses, file paths, or user accounts have been associated with known malicious activities.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often use hidden shares for routine maintenance and file transfers, which can trigger the rule. To manage this, users can create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks.
-- Backup operations: Automated backup processes may use hidden shares to store data, leading to false positives. Users can exclude backup software processes or designate specific time windows when these operations are expected.
-- Software updates and deployments: IT departments might deploy software updates or patches using hidden shares. To handle these, users can whitelist certain deployment tools or scripts that are verified and regularly used.
-- Monitoring and security tools: Some security and monitoring tools might access hidden shares for log collection or system checks. Users should identify and exclude these tools from triggering the rule by specifying their process names or paths.
-- Development and testing environments: In environments where developers frequently test applications, file operations to hidden shares might be common. Users can create exceptions for specific development machines or user accounts to reduce noise.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on recent file transfers and access logs.
-- Review and analyze the command-line history and process execution details to understand the adversary's actions and objectives.
-- Remove any unauthorized accounts or access permissions that may have been established during the intrusion.
-- Restore the system from a known good backup to ensure no malicious modifications persist.
-- Implement enhanced logging policies to capture detailed command-line activity and network share access for future monitoring.
-- Integrate security solutions with SIEM systems to correlate events and improve detection capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Apply security patches and updates to all systems to mitigate known vulnerabilities that could be exploited for lateral movement.
-- Educate users and administrators on the risks associated with hidden shares and enforce strict access controls and monitoring."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_remote_service_installed_winlog.toml b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
index 562262e9a1e..52e69a456f1 100644
--- a/rules/windows/lateral_movement_remote_service_installed_winlog.toml
+++ b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -63,50 +63,6 @@ event.outcome=="success" and source.ip != null and source.ip != "127.0.0.1" and
                 "?:\\Windows\\SysWOW64\\NwxExeSvc\\NwxExeSvc.exe",
                 "?:\\Windows\\System32\\taskhostex.exe")]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Remote Windows Service Installed
-
-Windows services are background processes that can be configured to start automatically, manually, or be triggered by specific events. Adversaries may exploit this by installing malicious services remotely to maintain persistence or facilitate lateral movement within a network. The detection rule identifies suspicious service installations following a network logon, excluding known legitimate services, to flag potential unauthorized activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `winlog.logon.id` and `winlog.computer_name` associated with the suspicious service installation.
-- Verify the `source.ip` address from the authentication event to determine if it is from a known or trusted source within the network.
-- Check the `winlog.event_data.ServiceFileName` to identify the installed service's executable path and compare it against known legitimate services.
-- Use Osquery to list all services on the affected machine and identify any unfamiliar or suspicious services. Example query: `SELECT name, path, start_type FROM services WHERE path LIKE '%<suspicious_service_name>%';`
-- Investigate the user account associated with the `winlog.logon.id` to determine if it has a history of legitimate administrative actions or if it might be compromised.
-- Correlate the timestamp of the service installation with other logs to identify any concurrent suspicious activities, such as file modifications or registry changes.
-- Examine the service's executable file for any signs of tampering or unusual attributes, such as recent modification dates or unexpected file sizes.
-- Check for any recent changes in user permissions or group memberships that might have facilitated the unauthorized service installation.
-- Review network logs to identify any unusual outbound connections from the affected machine following the service installation.
-- Consult threat intelligence sources to determine if the service name or executable path is associated with known malware or adversary techniques.
-
-### False positive analysis
-
-- Known false positives for the Remote Windows Service Installed rule often arise from legitimate administrative activities, such as IT staff installing or updating software remotely, which can trigger service creation events.
-- Frequent non-threatening behaviors may include automated deployment tools or scripts that install services as part of routine maintenance or software updates.
-- To manage these false positives, users can create exceptions for specific service file paths or LogonIds that are known to be associated with legitimate administrative tasks.
-- Users should regularly review and update the list of excluded service file paths to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats.
-- Implementing a whitelist of trusted IP addresses or user accounts that are known to perform legitimate service installations can help reduce noise in the detection rule.
-- Monitoring and correlating these events with other security logs can provide additional context to distinguish between benign and malicious activities, aiding in the refinement of exceptions.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Verify the legitimacy of the installed service by checking its origin, digital signature, and associated files.
-- Terminate any malicious services identified and remove associated files from the system.
-- Conduct a thorough investigation of the source IP address to determine if it is part of a larger attack campaign.
-- Review recent logon events and network activity to identify any other compromised accounts or systems.
-- Reset credentials for any accounts that were used in the suspicious logon events to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed information on service installations and network logons for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
index 0185455a4fe..d6bf620d013 100644
--- a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
+++ b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,48 +68,6 @@ any where host.os.type == "windows" and
     "?:\\Windows\\System32\\hvsirdpclient.exe"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious RDP ActiveX Client Loaded
-
-The Remote Desktop Services ActiveX Client, mstscax.dll, facilitates remote desktop connections, enabling users to access and control remote systems. Adversaries may exploit this by loading the DLL in unauthorized contexts to perform lateral movement within a network. The detection rule identifies unusual loading of mstscax.dll outside typical system paths, flagging potential misuse indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `mstscax.dll` being loaded from an unusual path, as indicated by the `process.executable` field.
-- Verify the legitimacy of the process by checking the `process.executable` path against known safe paths and any additional paths specific to your environment.
-- Examine the `host.os.type` field to ensure the alert pertains to a Windows system, as this rule is specific to Windows environments.
-- Investigate the parent process of the suspicious activity using the `event.category` and `event.action` fields to determine if the process was initiated by a legitimate user or application.
-- Use Osquery to gather more information about the process and its parent. For example, run the following query to list processes with their parent process IDs and paths: `SELECT pid, name, path, parent FROM processes WHERE path LIKE '%mstscax.dll%';`
-- Check the `file.name` field to confirm the file involved is indeed `mstscax.dll` and not a similarly named file that could be used to obfuscate malicious activity.
-- Analyze the network activity associated with the process to identify any unusual remote connections that could indicate lateral movement attempts.
-- Review recent user activity on the affected host to determine if any legitimate user actions could explain the loading of `mstscax.dll` from an unexpected location.
-- Correlate the alert with other security events or logs from the same host or network segment to identify any patterns or additional indicators of compromise.
-- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize similar techniques involving `mstscax.dll` for lateral movement.
-
-### False positive analysis
-
-- Known false positives for the Suspicious RDP ActiveX Client Loaded rule may include legitimate applications or system processes that load mstscax.dll for valid remote desktop functionalities. These can occur in environments where remote desktop services are frequently used for administrative purposes.
-- Users can handle these false positives by identifying and excluding specific processes or paths that are known to be safe. This can be done by adding exceptions to the detection rule for processes that are verified as non-threatening, such as those associated with trusted remote management tools or internal IT operations.
-- To manage false positives effectively, users should monitor the frequency and context of alerts. If a particular process or path consistently triggers alerts but is confirmed to be legitimate, it should be added to the exclusion list in the detection rule.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and operational needs, minimizing unnecessary alerts while maintaining security vigilance.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation to confirm the unauthorized loading of mstscax.dll, reviewing logs and correlating with other security events.
-- Terminate any suspicious processes associated with the unauthorized mstscax.dll loading to halt any ongoing malicious activity.
-- Remove any unauthorized or malicious files and restore the system to a known good state using backups or system restore points.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed information on DLL loads, process executions, and network connections for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited for lateral movement.
-- Conduct a review of user access permissions and implement least privilege principles to reduce the risk of unauthorized access.
-- Educate users on recognizing phishing attempts and other social engineering tactics that adversaries may use to gain initial access to the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
index 53def153720..1694f8e9ad5 100644
--- a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
+++ b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,49 +47,6 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
    file.path : ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
                 "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Lateral Movement via Startup Folder
-
-The Windows Startup folder is a mechanism that allows programs to run automatically upon user logon or system reboot. Adversaries exploit this by placing malicious files in the Startup folder of a remote system, often accessed via RDP or SMB, to ensure persistence and facilitate lateral movement. The detection rule identifies suspicious file activities in these folders, focusing on processes like mstsc.exe, which may indicate unauthorized access and file creation, signaling potential lateral movement attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process name involved in the suspicious activity, focusing on the `file.path` and `process.name` fields.
-- Verify the legitimacy of the process by checking the `process.name` and `process.pid` fields to determine if `mstsc.exe` or a process with PID 4 was involved, as these are indicative of RDP or SMB activity.
-- Use Osquery to list all files in the Startup folder to identify any unexpected or unauthorized files. Example query: `SELECT path, filename, md5 FROM file WHERE directory LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\%' OR directory LIKE 'C:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\%';`
-- Investigate the file creation or modification time to determine if it aligns with known user activity or if it occurred during unusual hours.
-- Check the file hash against known malware databases to identify if the file is a known threat.
-- Review recent RDP or SMB connection logs to identify any unusual or unauthorized access attempts that coincide with the file creation or modification event.
-- Analyze the user account associated with the process to determine if it has been compromised or if it has unusual permissions or activity.
-- Correlate the event with other security alerts or logs to identify if there are additional indicators of compromise or related suspicious activities.
-- Investigate the parent process of `mstsc.exe` or the process with PID 4 to understand the origin of the connection and whether it was initiated by a legitimate user or process.
-- Conduct a historical search for similar file creation events in the Startup folder to determine if this is an isolated incident or part of a broader pattern of activity.
-
-### False positive analysis
-
-- Legitimate software installations or updates may create files in the Startup folder, triggering the detection rule. Users can handle this by verifying the software's authenticity and adding it to an exception list if deemed safe.
-- System administrators might use scripts or tools that modify the Startup folder for maintenance or configuration purposes. These activities should be documented, and exceptions can be created for known administrative processes.
-- Remote desktop management tools or services that utilize mstsc.exe for legitimate purposes might inadvertently match the rule's criteria. Users should ensure these tools are authorized and consider excluding their specific file paths or process names.
-- Automated backup or synchronization software that interacts with the Startup folder could cause false positives. Users should verify the software's legitimacy and exclude its activities if they are part of routine operations.
-- In environments where shared systems are common, multiple users might have legitimate reasons to modify the Startup folder. Organizations should establish a baseline of expected behavior and create exceptions for known, non-threatening activities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement and contain the threat.
-- Verify the presence of unauthorized files in the Startup folder and remove any malicious scripts or executables identified.
-- Conduct a thorough investigation to determine the source of the unauthorized access, focusing on RDP and SMB logs to identify potential entry points.
-- Change credentials for any accounts that may have been compromised, especially those with administrative privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed file creation and modification events, particularly in critical directories like the Startup folder.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting RDP access to trusted IP addresses, enabling multi-factor authentication, and regularly auditing user permissions and access rights."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_via_wsus_update.toml b/rules/windows/lateral_movement_via_wsus_update.toml
index d88800ca44e..bd697c08064 100644
--- a/rules/windows/lateral_movement_via_wsus_update.toml
+++ b/rules/windows/lateral_movement_via_wsus_update.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 
 [rule]
 author = ["Elastic"]
@@ -46,48 +46,6 @@ process.executable : (
 ) and
 (process.name : "psexec64.exe" or ?process.pe.original_file_name : "psexec.c")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential WSUS Abuse for Lateral Movement
-
-Windows Server Update Services (WSUS) is a system that manages updates for Microsoft products, ensuring that only trusted, signed binaries are executed. However, adversaries can exploit WSUS to execute Microsoft-signed tools like PsExec for lateral movement within a network. The detection rule identifies suspicious processes initiated by WSUS, specifically targeting the execution of PsExec, which is indicative of potential abuse for unauthorized lateral movement.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the suspicious process execution, focusing on the `process.parent.name` field to verify if `wuauclt.exe` is the parent process.
-- Examine the `process.executable` path to ensure it matches the specified paths in the query, indicating potential abuse of the WSUS download directory.
-- Check the `process.name` and `process.pe.original_file_name` fields to confirm the execution of `psexec64.exe` or `psexec.c`, which are indicative of lateral movement attempts.
-- Investigate the timeline of events leading up to the alert by reviewing related process creation events to identify any preceding suspicious activities.
-- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name = 'psexec64.exe' OR name = 'psexec.c';` to identify other instances of these processes running on the host.
-- Analyze network logs to identify any unusual outbound connections from the affected host that may indicate lateral movement attempts.
-- Review user account activity on the affected host to determine if any unauthorized or unexpected accounts were used to execute the suspicious processes.
-- Check for any recent changes or updates to the WSUS configuration that could have been exploited to facilitate the execution of unauthorized binaries.
-- Correlate the alert with other security events or alerts in the environment to identify potential patterns or coordinated attack activities.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors associated with similar WSUS abuse techniques.
-
-### False positive analysis
-
-- Legitimate administrative activities: In some environments, system administrators may use PsExec for legitimate purposes, such as deploying software or performing maintenance tasks. These activities can trigger the detection rule, leading to false positives.
-- Automated update scripts: Organizations may have automated scripts that utilize PsExec for deploying updates or patches across the network. These scripts, if executed by WSUS, can be mistaken for malicious activity.
-- Testing and development environments: In testing or development environments, PsExec might be used frequently for testing purposes, which could lead to false positives if these environments are not properly excluded from monitoring.
-- To manage these false positives, users can create exceptions for known legitimate activities by excluding specific processes or scripts that are regularly used for administrative tasks. Additionally, users can refine the detection rule to exclude certain hosts or environments, such as development or testing servers, where PsExec usage is expected and non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to confirm the presence of PsExec execution initiated by WSUS and identify any other potentially compromised systems.
-- Review and analyze logs from WSUS, endpoint detection and response (EDR) tools, and network traffic to trace the adversary's activities and entry points.
-- Remove unauthorized PsExec binaries and any other malicious tools or scripts found on the affected systems.
-- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
-- Reset credentials for accounts that were accessed or potentially compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on WSUS and related services.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection of similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and apply hardening measures, such as restricting WSUS permissions and monitoring for unusual process executions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ad_adminsdholder.toml b/rules/windows/persistence_ad_adminsdholder.toml
index ad1a243d54b..943a4663f0c 100644
--- a/rules/windows/persistence_ad_adminsdholder.toml
+++ b/rules/windows/persistence_ad_adminsdholder.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/31"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,50 +43,6 @@ query = '''
 event.action:("Directory Service Changes" or "directory-service-object-modified") and event.code:5136 and
   winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AdminSDHolder Backdoor
-
-The AdminSDHolder object in Active Directory is crucial for maintaining consistent permissions across privileged accounts. It ensures that any changes to these accounts are reverted to match the AdminSDHolder's settings. Adversaries exploit this by modifying the AdminSDHolder to create persistent backdoors, allowing unauthorized access. The detection rule identifies such modifications by monitoring specific directory service events, signaling potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event.action field includes "Directory Service Changes" or "directory-service-object-modified" and the event.code is 5136, indicating a modification to the directory service object.
-- Verify the winlog.event_data.ObjectDN field to ensure it matches CN=AdminSDHolder,CN=System*, confirming the specific object of interest.
-- Check the timestamp of the event to determine when the modification occurred and correlate it with any other suspicious activities or alerts around the same time.
-- Identify the user account associated with the modification by examining the event data for the user who initiated the change, and assess whether this account has a legitimate reason to modify the AdminSDHolder object.
-- Investigate the source IP address or host from which the modification was made to determine if it is a known and trusted system within the network.
-- Use Osquery to gather additional context on the system involved. For example, run the following query to list recent changes to Active Directory objects: `SELECT * FROM ad_config WHERE distinguished_name LIKE 'CN=AdminSDHolder,CN=System%' AND last_modified > DATE_SUB(NOW(), INTERVAL 1 DAY);`
-- Review the history of changes to the AdminSDHolder object by querying the security logs for previous event.code 5136 entries related to this object to identify any patterns or repeated unauthorized modifications.
-- Cross-reference the user account and system involved with known threat intelligence sources to check for any indicators of compromise or known malicious activity.
-- Analyze any related logs or alerts from endpoint detection and response (EDR) tools to identify potential lateral movement or privilege escalation attempts following the modification.
-- Document all findings and maintain a timeline of events to support further investigation and potential escalation to incident response teams if necessary.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or changes made by authorized IT personnel to the AdminSDHolder object can trigger alerts. These are often part of legitimate maintenance activities.
-- Scheduled security audits: Automated scripts or tools used during security audits may modify or access the AdminSDHolder object, leading to false positives.
-- Software updates: Certain software updates, especially those related to security or directory services, might involve changes to the AdminSDHolder object.
-- To manage these false positives, users can create exceptions for known and verified administrative actions by whitelisting specific user accounts or processes that are authorized to make changes.
-- Implementing a review process for alerts can help distinguish between legitimate changes and potential threats, ensuring that only suspicious activities are flagged.
-- Regularly updating the list of authorized personnel and tools that interact with the AdminSDHolder object can help in maintaining accurate exceptions and reducing false positives.
-
-### Response and remediation
-
-- Immediately isolate affected systems from the network to prevent further unauthorized access.
-- Review recent changes to the AdminSDHolder object and identify any unauthorized modifications.
-- Revert any unauthorized changes to the AdminSDHolder object to restore original permissions.
-- Conduct a thorough investigation to identify the source of the modification, including reviewing logs and correlating with other security events.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging for Active Directory changes, focusing on critical objects like AdminSDHolder, to improve detection of future unauthorized modifications.
-- Integrate security information and event management (SIEM) solutions with Active Directory to automate detection and alerting of suspicious activities.
-- Review and update access controls and permissions for privileged accounts to ensure they adhere to the principle of least privilege.
-- Conduct a security audit of the Active Directory environment to identify and remediate any other potential vulnerabilities or misconfigurations.
-- Educate and train IT staff and administrators on the risks associated with AdminSDHolder modifications and the importance of monitoring privileged account activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_app_compat_shim.toml b/rules/windows/persistence_app_compat_shim.toml
index 0be8a5e0563..888afb2ac42 100644
--- a/rules/windows/persistence_app_compat_shim.toml
+++ b/rules/windows/persistence_app_compat_shim.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,48 +48,6 @@ registry where host.os.type == "windows" and event.type == "change" and
                          "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", 
                          "?:\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Installation of Custom Shim Databases
-
-Application Compatibility Shim databases are used in Windows to ensure older applications run smoothly on newer OS versions by applying compatibility fixes. However, attackers can exploit this feature to maintain persistence and execute arbitrary code by installing malicious custom shim databases. The detection rule identifies changes in specific registry paths associated with these databases, excluding known legitimate processes, to flag potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path involved matches one of the specified paths in the detection rule, focusing on paths like "HKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\AppCompatFlags\\\\Custom\\\\*.sdb".
-- Check the process executable that triggered the alert to ensure it is not one of the known legitimate processes listed in the exclusion list, such as "NwSapSetup.exe" or "kavfs.exe".
-- Investigate the timestamp of the registry change event to correlate with any other suspicious activities or changes on the system around the same time.
-- Use Osquery to list all custom shim databases installed on the system with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\AppCompatFlags\\\\Custom\\\\%'`.
-- Examine the contents and metadata of the identified custom shim database files to determine their origin and purpose.
-- Cross-reference the identified shim database files with known good or bad hashes using threat intelligence sources or a file reputation service.
-- Investigate the user account context under which the registry change was made to determine if it aligns with expected administrative activity.
-- Review system logs and security events for any signs of privilege escalation or unauthorized access that could have led to the installation of the custom shim database.
-- Check for any recent software installations or updates that might have legitimately introduced new shim databases, ensuring they align with organizational policies.
-- Analyze network activity from the host around the time of the registry change for any unusual outbound connections that could indicate data exfiltration or command and control communication.
-
-### False positive analysis
-
-- Known false positives for the Installation of Custom Shim Databases rule include legitimate software installations or updates that modify the registry paths associated with shim databases. These can include software from vendors like SAP and Kaspersky, which are known to use these registry paths during their installation or update processes.
-- Users can handle these false positives by creating exceptions for specific processes that are known to be legitimate. This can be done by adding the executable paths of these trusted applications to the exclusion list in the detection rule, ensuring that these processes do not trigger alerts.
-- It is important to regularly review and update the list of excluded processes to ensure that only verified and trusted applications are excluded, minimizing the risk of overlooking potential threats.
-- Users should also monitor for any new software installations or updates that might interact with the registry paths in question, and assess whether these should be added to the exclusion list based on their legitimacy and frequency of occurrence.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the custom shim database installation, focusing on recent changes and unauthorized access.
-- Review and analyze the process execution logs to determine if any known malicious executables were involved in the shim database installation.
-- Remove any unauthorized or suspicious shim databases from the registry paths identified in the detection rule.
-- Restore the system to a known good state using backups or system restore points, ensuring that no malicious changes persist.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by attackers.
-- Educate users and administrators on the risks associated with shim databases and the importance of monitoring for unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_appcertdlls_registry.toml b/rules/windows/persistence_appcertdlls_registry.toml
index 9a9cdac8f64..8ced36769d3 100644
--- a/rules/windows/persistence_appcertdlls_registry.toml
+++ b/rules/windows/persistence_appcertdlls_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -40,49 +40,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Registry Persistence via AppCert DLL
-
-AppCert DLLs are dynamic link libraries that can be configured to load into every process that uses certain API functions, providing a mechanism for legitimate software to extend or modify process behavior. However, adversaries exploit this by inserting malicious DLLs into the registry path associated with AppCert DLLs, ensuring their code executes whenever a process is created. The detection rule identifies changes to specific registry paths linked to AppCert DLLs, signaling potential unauthorized persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path that triggered the alert, focusing on the `registry.path` field to determine which AppCert DLL path was modified.
-- Check the `event.type` field to confirm that the change event is indeed related to a modification, as this indicates a potential persistence attempt.
-- Use Osquery to list all DLLs currently configured in the AppCertDLLs registry path with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\%'`.
-- Investigate the timestamp of the registry change to correlate it with other system events or user activities that occurred around the same time.
-- Examine the system's event logs, particularly the Security and System logs, for any suspicious activities or anomalies that coincide with the registry change.
-- Identify the user account associated with the registry change by reviewing the `user.name` field in the alert, and investigate the user's recent activities and access patterns.
-- Check for any known malicious or suspicious DLLs by comparing the modified DLLs against threat intelligence databases or using a malware analysis tool.
-- Investigate the parent process that initiated the registry change by correlating process creation events with the timestamp of the registry modification.
-- Review network activity logs for any unusual outbound connections or data transfers that might suggest communication with a command and control server.
-- Conduct a historical search for similar registry changes on the host or across the network to determine if this is an isolated incident or part of a broader pattern.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify the AppCert DLL registry paths as part of their normal operation, leading to false positives. Users should verify if the changes coincide with known software updates or installations.
-- Security software or system management tools might also interact with these registry paths to enhance security or manage system configurations, which can trigger alerts. Users can create exceptions for these trusted applications to reduce noise.
-- Custom enterprise applications developed in-house may use AppCert DLLs for legitimate process management purposes. It's important to document these applications and exclude their known behaviors from triggering alerts.
-- Regular audits of the registry changes can help identify patterns of benign activity, allowing users to refine detection rules and exclude non-threatening behaviors from being flagged.
-- Users should maintain a whitelist of known good DLLs and their associated registry paths to quickly identify and exclude them from false positive alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation to confirm the presence of unauthorized AppCert DLLs by reviewing the registry paths specified in the detection rule.
-- Utilize endpoint detection and response (EDR) tools to identify any additional indicators of compromise (IOCs) related to the AppCert DLL persistence technique.
-- Remove any unauthorized or suspicious DLLs found in the AppCertDLLs registry path and restore the registry to its previous state if possible.
-- Perform a comprehensive malware scan on the affected system to identify and remove any additional malicious software.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to monitor changes to critical registry paths and integrate with a security information and event management (SIEM) system for real-time alerts.
-- Review and update endpoint protection policies to prevent unauthorized modifications to the registry and ensure that all systems are running the latest security patches.
-- Educate users on recognizing and reporting suspicious activities to reduce the risk of future incidents.
-- Consider implementing application whitelisting to prevent unauthorized DLLs from being loaded into processes, thereby hardening the system against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_browser_extension_install.toml b/rules/windows/persistence_browser_extension_install.toml
index c8d2bf7290e..7bcc2ade5b5 100644
--- a/rules/windows/persistence_browser_extension_install.toml
+++ b/rules/windows/persistence_browser_extension_install.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,49 +61,6 @@ file where host.os.type == "windows" and event.type : "creation" and
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Browser Extension Install
-
-Browser extensions enhance functionality in web browsers but can be exploited by adversaries to gain persistence or execute malicious activities. Attackers may disguise harmful extensions as legitimate or use compromised systems to install them. The detection rule identifies suspicious extension installations by monitoring specific file creation patterns in user directories, focusing on Firefox and Chromium-based browsers, while excluding known safe processes.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file name and path involved in the suspicious extension installation, focusing on the `file.name` and `file.path` fields.
-- Verify the process responsible for the file creation by checking the `process.name` field to ensure it is not a known safe process like `firefox.exe` with legitimate extension names.
-- Cross-reference the file path with known directories for Firefox and Chromium-based browsers to confirm the legitimacy of the extension installation location.
-- Use Osquery to list all installed extensions for the affected browser. For Firefox, run: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\%\\\\Profiles\\\\%\\\\Extensions\\\\%' AND path LIKE '%.xpi';`
-- For Chromium-based browsers, use Osquery to query installed extensions: `SELECT * FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Local\\\\%\\\\User Data\\\\Webstore Downloads\\\\%' AND path LIKE '%.crx';`
-- Investigate the origin of the extension by checking the browser's extension management interface or settings to see if the extension is listed and if it provides any additional information about its source.
-- Check the browser's history and download logs to identify any recent downloads or installations that coincide with the alert timestamp.
-- Analyze the system for any signs of compromise that could have led to unauthorized extension installation, such as unusual network activity or other suspicious file creations.
-- Consult threat intelligence sources to determine if the extension name or hash is associated with known malicious activity.
-- Document findings and gather all relevant evidence, including file hashes, paths, and process details, to support further analysis or escalation if needed.
-
-### False positive analysis
-
-- Known false positives may occur when legitimate browser extensions are installed or updated, especially if they are not from the official browser stores but are still safe and necessary for business operations.
-- Language packs and dictionary extensions for Firefox, such as those from `firefox.mozilla.org` and `dictionaries.addons.mozilla.org`, are common false positives and should be excluded from alerts.
-- Users can manage false positives by creating exceptions for specific processes or file paths that are verified as safe, ensuring that these are regularly reviewed and updated to reflect any changes in legitimate extension usage.
-- Regularly update the list of known safe processes and file paths to include any new legitimate extensions that are frequently used within the organization, reducing unnecessary alerts.
-- Consider implementing a whitelist of approved extensions and processes, which can be cross-referenced during the detection process to minimize false positives while maintaining security vigilance.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the malicious extension.
-- Verify the legitimacy of the detected browser extension by checking its source and comparing it against known malicious extensions.
-- Remove the suspicious browser extension from the affected browser to eliminate the immediate threat.
-- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats.
-- Review system and browser logs to trace the origin of the extension installation and identify any potential security breaches.
-- Escalate the incident to the security team if the extension is confirmed to be part of a larger attack or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed browser activity and file creation events for future investigations.
-- Integrate threat intelligence feeds to automatically update and block known malicious extensions and sources.
-- Restore the system to its operational state by ensuring all security patches and updates are applied to the operating system and browsers.
-- Harden the system by enforcing strict browser extension policies, such as allowing only extensions from trusted sources and regularly reviewing installed extensions."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_evasion_registry_ifeo_injection.toml b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
index 92d5cfcfe95..783c763a025 100644
--- a/rules/windows/persistence_evasion_registry_ifeo_injection.toml
+++ b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,51 +58,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     /* add FPs here */
   not registry.data.strings regex~ ("""C:\\Program Files( \(x86\))?\\ThinKiosk\\thinkiosk\.exe""", """.*\\PSAppDeployToolkit\\.*""")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Image File Execution Options Injection
-
-Image File Execution Options (IFEO) is a Windows feature that allows developers to debug applications by specifying an alternative executable to run instead of the original. Adversaries exploit this by setting a debugger to execute malicious code, achieving persistence. The detection rule identifies changes to specific registry keys associated with IFEO, flagging potential misuse by monitoring for suspicious executables being set as debuggers.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path and value that triggered the alert, focusing on the `registry.path` and `registry.value` fields.
-- Verify the legitimacy of the executable set as the debugger by examining the `registry.data.strings` field to identify any suspicious or unknown executables.
-- Cross-reference the suspicious executable with known malicious file hashes or signatures using threat intelligence sources.
-- Use Osquery to list all entries under the Image File Execution Options registry key to identify any other potentially malicious configurations:
-  ```sql
-  SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Image File Execution Options\\\\%';
-  ```
-- Investigate the process creation history on the host to determine if the suspicious executable has been executed, using event logs or endpoint detection and response (EDR) tools.
-- Check for any recent changes to the registry keys by reviewing the `event.type` field for "change" events and correlating with user activity logs to identify the responsible user or process.
-- Analyze the system's startup and scheduled tasks to ensure no additional persistence mechanisms are in place that could be related to the suspicious executable.
-- Review network activity logs for any unusual outbound connections initiated by the suspicious executable, which could indicate command and control communication.
-- Examine the file properties and metadata of the suspicious executable to gather information about its origin, such as creation date, digital signature, and file path.
-- Consult with the system owner or user to verify if the executable was intentionally installed or configured, and gather any additional context about recent software installations or updates.
-
-### False positive analysis
-
-- Known false positives for the Image File Execution Options Injection rule include legitimate software that uses the IFEO feature for debugging or monitoring purposes, such as ThinKiosk and PSAppDeployToolkit. These applications may set themselves as debuggers or monitor processes, which can trigger the detection rule.
-- To manage these false positives, users can create exceptions in the detection rule by adding specific paths or patterns to the exclusion list. For example, the rule already excludes paths like `C:\\Program Files\\ThinKiosk\\thinkiosk.exe` and any path containing `PSAppDeployToolkit`.
-- Users should regularly review and update the exclusion list to include other known benign applications that utilize IFEO for legitimate purposes, ensuring that the detection rule remains effective without generating unnecessary alerts.
-- It is important to maintain a balance between excluding known false positives and ensuring that the rule still detects potential malicious activity. Users should conduct thorough testing and validation before adding new exclusions to avoid missing genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation to identify the malicious executable set as a debugger by reviewing the registry changes and correlating with known threat intelligence.
-- Remove or revert any unauthorized changes to the registry keys associated with Image File Execution Options and SilentProcessExit.
-- Perform a comprehensive malware scan on the affected system using updated antivirus or endpoint detection and response (EDR) tools.
-- Review system and security logs to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if multiple systems are affected.
-- Implement enhanced logging policies to monitor registry changes and process executions, ensuring that future suspicious activities are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and contextual analysis.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Harden the system by implementing least privilege principles, disabling unnecessary services, and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_group_modification_by_system.toml b/rules/windows/persistence_group_modification_by_system.toml
index e29ff57d98f..a652ef77e0b 100644
--- a/rules/windows/persistence_group_modification_by_system.toml
+++ b/rules/windows/persistence_group_modification_by_system.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,48 +40,6 @@ winlog.event_data.SubjectUserSid : "S-1-5-18" and
 /* DOMAIN_USERS and local groups */
 not group.id : "S-1-5-21-*-513"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Active Directory Group Modification by SYSTEM
-
-Active Directory (AD) is a critical component in many enterprise environments, managing user and group permissions. SYSTEM, a highly privileged account, should not typically modify AD groups. Adversaries gaining SYSTEM privileges on a domain controller can exploit this to escalate privileges by adding users to sensitive groups. The detection rule identifies such anomalies by monitoring specific event codes and user SIDs, flagging unauthorized group modifications by SYSTEM, thus alerting to potential security breaches.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event code "4728" and the SubjectUserSid "S-1-5-18" to ensure it matches the criteria for SYSTEM account modifications.
-- Check the specific group ID involved in the modification to determine if it is a sensitive group, excluding known safe groups like "S-1-5-21-*-513".
-- Correlate the timestamp of the event with other logs to identify any preceding or subsequent suspicious activities on the domain controller.
-- Investigate the source IP address and hostname from which the SYSTEM account modification was initiated to identify potential unauthorized access points.
-- Examine recent changes in user privileges or group memberships on the domain controller to identify any unusual patterns or unauthorized escalations.
-- Utilize Osquery to gather additional context on the domain controller. For example, run the following query to list recent group modifications: `SELECT * FROM ad_group_membership WHERE action = 'add' AND user_sid = 'S-1-5-18';`
-- Analyze the event logs for any signs of privilege escalation techniques, such as the exploitation of vulnerabilities or abuse of default group privileges.
-- Review the security patches and configurations on the domain controller to ensure they are up-to-date and not susceptible to known vulnerabilities.
-- Check for any recent changes in the domain controller's security policies or configurations that could have inadvertently allowed SYSTEM account modifications.
-- Consult with the IT team to verify if there were any legitimate administrative tasks performed that could explain the SYSTEM account's involvement in group modifications.
-
-### False positive analysis
-
-- Scheduled tasks or automated processes running under the SYSTEM account may legitimately modify AD groups, leading to false positives. Users can handle these by identifying and documenting such tasks, then creating exceptions in the detection rule to exclude these specific activities.
-- Certain security or management software might operate under the SYSTEM account and perform group modifications as part of their normal operations. Users should verify the legitimacy of these software actions and adjust the detection rule to exclude these known benign activities.
-- During system maintenance or updates, administrators might temporarily use SYSTEM privileges to modify groups. Users should ensure that such activities are logged and approved, and consider temporarily disabling the rule or adding exceptions during these periods to prevent false alerts.
-- In environments where SYSTEM account usage is more common due to legacy applications or configurations, users should conduct a thorough review to understand the context and adjust the detection rule to accommodate these specific scenarios without compromising security.
-
-### Response and remediation
-
-- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or changes.
-- Verify the legitimacy of the group modification by reviewing recent changes in Active Directory and cross-referencing with authorized change requests.
-- Conduct a thorough investigation to identify how SYSTEM privileges were obtained, focusing on potential vulnerabilities or misconfigurations that could have been exploited.
-- Reset passwords and review permissions for any accounts added to sensitive groups to ensure they have not been compromised.
-- Escalate the incident to the security operations center (SOC) and relevant IT management teams for further analysis and decision-making.
-- Implement enhanced logging and monitoring for Active Directory, ensuring that all group modifications and privilege escalations are logged and reviewed regularly.
-- Integrate security information and event management (SIEM) solutions to correlate events and detect similar anomalies in the future.
-- Restore the domain controller to a known good state using backups, ensuring that all unauthorized changes are reverted.
-- Apply security patches and updates to the domain controller and related systems to mitigate known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence, including hardening measures such as restricting SYSTEM account usage and reviewing group membership policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_local_scheduled_job_creation.toml b/rules/windows/persistence_local_scheduled_job_creation.toml
index dd17603012b..e771f3d2d8e 100644
--- a/rules/windows/persistence_local_scheduled_job_creation.toml
+++ b/rules/windows/persistence_local_scheduled_job_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -42,51 +42,6 @@ file where host.os.type == "windows" and event.type != "deletion" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via Scheduled Job Creation
-
-Scheduled jobs in Windows allow users to automate the execution of tasks at specified times. Adversaries exploit this feature to maintain persistence by scheduling malicious scripts or programs to run automatically. The detection rule identifies suspicious job files in the Windows Tasks directory, excluding known legitimate processes, to flag potential abuse of this functionality for unauthorized persistence.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and process executable involved in the scheduled job creation.
-- Verify the legitimacy of the file path by checking if it matches any known legitimate processes or paths excluded in the detection rule.
-- Use Osquery to list all scheduled tasks on the host to identify any other potentially suspicious tasks:
-  ```sql
-  SELECT * FROM scheduled_tasks WHERE path LIKE 'C:\\\\Windows\\\\Tasks\\\\%';
-  ```
-- Investigate the process executable associated with the scheduled job to determine if it is a known legitimate application or potentially malicious.
-- Check the creation and modification timestamps of the suspicious job file to understand when it was created and if it aligns with any known user activity or system changes.
-- Correlate the scheduled job creation with other security events or logs from the same timeframe to identify any related suspicious activity.
-- Examine the user account context under which the scheduled job was created to determine if it was created by an authorized user or potentially compromised account.
-- Investigate the parent process of the executable that created the scheduled job to trace back the origin of the job creation.
-- Review any network connections or external communications initiated by the process executable to identify potential command and control activity.
-- Consult threat intelligence sources to determine if the process executable or file path is associated with known malware or adversary techniques.
-
-### False positive analysis
-
-- Scheduled jobs created by legitimate software such as CCleaner and ManageEngine UEMS Agent can trigger false positives. These applications are known to create job files in the Windows Tasks directory for routine maintenance and updates.
-- To manage these false positives, users can implement exceptions in the detection rule. For instance, exclude job files associated with CCleanerCrashReporting.job and DCAgentUpdater.job by specifying their respective process executables in the exclusion criteria.
-- Regularly review and update the exclusion list to include any new legitimate applications that may create scheduled jobs, ensuring that the detection rule remains effective without flagging benign activities.
-- Consider the context of the environment and the presence of known software that utilizes scheduled tasks for legitimate purposes, adjusting the rule to accommodate these scenarios while maintaining security vigilance.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Review the scheduled job details, including the script or program being executed, to determine if it is malicious or unauthorized.
-- Terminate any malicious processes associated with the suspicious scheduled job to stop further execution.
-- Delete the unauthorized scheduled job from the Windows Tasks directory to remove persistence.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
-- Investigate the source of the scheduled job creation by reviewing system logs and user activity to identify potential compromise vectors.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if additional expertise is required.
-- Implement enhanced logging policies to capture detailed information on scheduled task creation and modification events for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in the future.
-- Apply system hardening measures, such as restricting user permissions and implementing application whitelisting, to prevent unauthorized task scheduling and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_local_scheduled_task_creation.toml b/rules/windows/persistence_local_scheduled_task_creation.toml
index e9bd05836b1..b16d94cda6a 100644
--- a/rules/windows/persistence_local_scheduled_task_creation.toml
+++ b/rules/windows/persistence_local_scheduled_task_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,50 +53,6 @@ sequence with maxspan=1m
     not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System")
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Local Scheduled Task Creation
-
-Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, or privilege escalation. They may create tasks using command-line tools like `schtasks.exe`. The detection rule identifies suspicious task creation by monitoring processes linked to task creation, especially when initiated by non-system users, indicating potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process that triggered the rule, focusing on the `process.name` and `process.args` fields to understand the context of the task creation.
-- Check the `process.entity_id` and `process.parent.entity_id` to trace the parent-child relationship of the processes involved, which can help identify the origin of the task creation.
-- Investigate the user account associated with the task creation by examining the `process.args` for `/RU` to determine if it aligns with expected user behavior or if it is a non-system user.
-- Verify the integrity level of the process using `?process.Ext.token.integrity_level_name` or `?winlog.event_data.IntegrityLevel` to confirm that the task was created by a non-SYSTEM user, which could indicate suspicious activity.
-- Use Osquery to list all scheduled tasks on the host and identify any recently created or modified tasks. Example query: `SELECT * FROM scheduled_tasks WHERE hidden = 0;`
-- Cross-reference the scheduled task name and path from the alert with known legitimate tasks to identify any anomalies or unauthorized tasks.
-- Examine the command or script specified in the task's `/TR` argument to determine if it contains any suspicious or unexpected actions.
-- Review the task's schedule specified by `/SC` to assess if the timing aligns with typical user activity or if it appears to be set for persistence.
-- Check for any recent changes in the system's environment or configuration that could explain the task creation, such as software updates or new application installations.
-- Correlate the findings with other security events or logs from the same timeframe to identify any related activities or patterns that could indicate a broader attack campaign.
-
-### False positive analysis
-
-- Scheduled tasks created by legitimate administrative tools or scripts can trigger false positives, especially in environments with automated maintenance or deployment processes.
-- Regularly scheduled tasks by IT management software, such as patch management or system monitoring tools, may appear suspicious but are benign.
-- Users can manage these false positives by creating exceptions for known administrative tools or scripts that frequently create scheduled tasks.
-- Exclude specific user accounts or processes that are known to perform legitimate task creation, ensuring they are documented and verified as non-threatening.
-- Implement a review process to regularly update and refine exceptions based on changes in the environment or new legitimate task creation patterns.
-- Consider the context of task creation, such as the time of day or associated user activity, to differentiate between legitimate and suspicious behavior.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
-- Review the scheduled task details, including the user account that created it, the command executed, and the timing of the task, to understand the scope and intent of the task.
-- Terminate any malicious processes associated with the scheduled task and remove the task from the system.
-- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise or persistence mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team if the task is part of a broader attack campaign or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed process creation events and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as restricting the use of administrative tools and enforcing least privilege principles.
-- Educate users on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security policies and procedures."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ms_office_addins_file.toml b/rules/windows/persistence_ms_office_addins_file.toml
index 51b20c440c1..040eb7fed6e 100644
--- a/rules/windows/persistence_ms_office_addins_file.toml
+++ b/rules/windows/persistence_ms_office_addins_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/16"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,48 +42,6 @@ file where host.os.type == "windows" and event.type != "deletion" and
     "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*"
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via Microsoft Office AddIns
-
-Microsoft Office add-ins enhance functionality by allowing custom code execution when Office applications start. Adversaries exploit this by placing malicious add-ins in specific directories, ensuring their code runs whenever the application launches, thus achieving persistence. The detection rule identifies suspicious files with extensions like .xll or .xlam in these directories, signaling potential abuse for persistence.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and extension that triggered the detection, focusing on the `file.path` and `file.extension` fields.
-- Verify the legitimacy of the file by checking its creation and modification timestamps to determine if it aligns with known user activity or software updates.
-- Examine the file's metadata and properties to identify the publisher or author, which may provide clues about its legitimacy.
-- Use Osquery to list all files in the suspicious directories to identify any other potentially malicious add-ins. Example query: `SELECT path, filename, extension, size, atime, mtime FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\Microsoft\\\\%\\\\%' AND extension IN ('wll', 'xll', 'ppa', 'ppam', 'xla', 'xlam');`
-- Check the file's hash against known malware databases or threat intelligence sources to determine if it is a known threat.
-- Investigate the user account associated with the file path to determine if there is any unusual or unauthorized activity linked to that account.
-- Review recent system logs and events for any signs of suspicious activity or anomalies around the time the file was created or modified.
-- Analyze network traffic from the affected endpoint to identify any unusual outbound connections that may indicate data exfiltration or command-and-control communication.
-- Correlate the alert with other security events or alerts from the same endpoint to identify potential patterns or related incidents.
-- Consult with the user or system owner to verify if the add-in was intentionally installed and if they have experienced any unusual behavior with their Office applications.
-
-### False positive analysis
-
-- Legitimate add-ins: Users may have legitimate Microsoft Office add-ins installed that match the detection criteria, such as productivity tools or custom scripts developed by IT departments. These can trigger false positives if they reside in the monitored directories.
-- Frequent updates: Some legitimate add-ins may update frequently, causing repeated alerts. This is common with add-ins that receive regular feature enhancements or security patches.
-- User-specific add-ins: In environments where users are allowed to install their own add-ins, personal productivity tools or educational add-ins might be flagged as suspicious.
-- Handling false positives: To manage these, users can create exceptions for known legitimate add-ins by excluding specific file paths or hashes from the detection rule. Regularly review and update the list of exceptions to ensure it reflects the current environment and does not inadvertently exclude new threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the malicious add-in.
-- Conduct a thorough investigation to identify the source of the malicious add-in, checking for any recent downloads or email attachments that may have been the initial vector.
-- Remove the identified malicious add-in files from the specified directories to eliminate the persistence mechanism.
-- Perform a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats.
-- Review user account activity for any unauthorized access or changes, and reset passwords if necessary to secure accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on the directories used for Office add-ins.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
-- Restore the system to its operational state by ensuring all legitimate add-ins are intact and the system is fully patched and updated.
-- Apply hardening measures such as restricting write access to Office add-in directories and educating users on the risks of downloading and opening untrusted files."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ms_outlook_vba_template.toml b/rules/windows/persistence_ms_outlook_vba_template.toml
index 038959bac3d..3cec5159564 100644
--- a/rules/windows/persistence_ms_outlook_vba_template.toml
+++ b/rules/windows/persistence_ms_outlook_vba_template.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,48 +40,6 @@ query = '''
 file where host.os.type == "windows" and event.type != "deletion" and
  file.path : "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via Microsoft Outlook VBA
-
-Microsoft Outlook supports VBA scripting to automate tasks, which can be exploited by adversaries to maintain persistence. By embedding malicious scripts in the Outlook VBA environment, attackers can execute code each time Outlook is launched. The detection rule identifies suspicious activity by monitoring for unauthorized modifications to the VBA project file, a common indicator of such persistence techniques.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path matches "C:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Outlook\\\\VbaProject.OTM" and ensure the event type is not a deletion.
-- Verify the timestamp of the modification event to determine when the unauthorized change occurred.
-- Identify the user account associated with the file path to understand which user's Outlook environment was potentially compromised.
-- Check the system's event logs for any unusual login activities or privilege escalations around the time of the modification.
-- Use Osquery to list all processes running under the user's context to identify any suspicious or unexpected processes. Example query: `SELECT name, pid, path FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'target_username');`
-- Investigate the contents of the VbaProject.OTM file to identify any suspicious or malicious VBA code.
-- Cross-reference the identified VBA code with known malicious scripts or indicators of compromise (IOCs) from threat intelligence sources.
-- Examine the user's Outlook rules and settings for any unauthorized changes that could indicate further persistence mechanisms.
-- Review network logs for any outbound connections initiated by the user's machine that could suggest data exfiltration or command and control communication.
-- Consult with other security tools or logs to identify any correlated alerts or anomalies on the same endpoint or user account.
-
-### False positive analysis
-
-- Legitimate use of VBA scripts by power users or IT administrators for automating routine tasks in Microsoft Outlook can trigger the detection rule. These scripts might be used for tasks like email sorting, auto-replies, or calendar management.
-- Some third-party Outlook add-ins or plugins may modify the VBA project file as part of their normal operation, leading to false positives.
-- Users can manage these false positives by creating exceptions for known and trusted scripts or applications. This can be done by maintaining a whitelist of approved VBA scripts or by verifying the digital signatures of trusted add-ins.
-- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from detection, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm unauthorized modifications to the VbaProject.OTM file and identify any additional compromised systems.
-- Remove or disable the malicious VBA script from the Outlook environment to prevent further execution.
-- Restore the VbaProject.OTM file from a known good backup if available, or recreate it to ensure no malicious code remains.
-- Review and update endpoint protection solutions to detect and block similar persistence techniques in the future.
-- Implement enhanced logging policies to monitor changes to critical files and directories, focusing on the AppData and Outlook directories.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious activities related to Office applications.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
-- Educate users on the risks of enabling macros and VBA scripts, emphasizing the importance of vigilance against phishing attacks that may deliver such payloads.
-- Apply hardening measures by configuring Outlook security settings to restrict the execution of unauthorized scripts and macros, aligning with best practices and organizational policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
index 9b66056fd9b..446ca449b00 100644
--- a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
+++ b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,49 +56,6 @@ query = '''
 iam where event.action == "modified-user-account" and event.code == "4738" and
   winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 KRBTGT Delegation Backdoor
-
-In Active Directory, the KRBTGT account is crucial for Kerberos ticket granting. Adversaries may exploit this by altering delegation settings, allowing them to request tickets for KRBTGT, thus maintaining domain persistence. The detection rule identifies such modifications by monitoring specific event actions and codes, flagging unauthorized changes to the delegation attributes linked to KRBTGT.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event code is "4738" and the event action is "modified-user-account" to ensure it aligns with the KRBTGT Delegation Backdoor rule.
-- Examine the `winlog.event_data.AllowedToDelegateTo` field to verify if it contains any entries related to "krbtgt" to confirm unauthorized delegation settings.
-- Check the timestamp of the event to determine when the modification occurred and correlate it with other suspicious activities in the same timeframe.
-- Identify the user account that performed the modification by reviewing the `winlog.event_data.SubjectUserName` and `winlog.event_data.SubjectUserSid` fields to assess if the account has a legitimate reason for such changes.
-- Investigate the source machine from which the modification was made by examining the `winlog.event_data.SubjectLogonId` and `winlog.event_data.IpAddress` fields to trace the origin of the activity.
-- Use Osquery to gather additional context on the KRBTGT account by running a query such as: `SELECT * FROM ad_users WHERE name = 'krbtgt';` to check for any unusual attributes or changes.
-- Cross-reference the modification event with recent login activities of the involved user account to identify any anomalies or patterns of suspicious behavior.
-- Analyze the Active Directory logs for any other recent changes to critical accounts or delegation settings that might indicate a broader compromise.
-- Review historical data to determine if similar modifications have occurred in the past, which could suggest a recurring pattern of unauthorized access attempts.
-- Consult with the IT team to verify if there were any legitimate administrative tasks or changes scheduled that could explain the modification to the KRBTGT delegation settings.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate changes to the msDS-AllowedToDelegateTo attribute for service accounts might trigger the rule. Administrators should verify if the modification aligns with scheduled maintenance or updates.
-- Service account updates: Updates or changes to service accounts that require delegation might be flagged. Users can create exceptions for known service accounts that regularly undergo such changes.
-- Automated scripts: Scripts that manage or update delegation settings across multiple accounts could cause false positives. Ensure these scripts are documented and create exceptions for their activity.
-- Third-party software: Some software solutions that integrate with Active Directory may modify delegation settings as part of their operation. Verify the software's behavior and exclude its actions if deemed non-threatening.
-- Regular audits: Security audits or compliance checks might involve reviewing and updating delegation settings, potentially triggering alerts. Document these activities and consider excluding them from the rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or ticket requests.
-- Conduct a thorough investigation to determine the extent of the compromise, focusing on recent changes to the KRBTGT account and related delegation settings.
-- Revert any unauthorized changes to the msDS-AllowedToDelegateTo attribute for the KRBTGT account to its original state.
-- Reset the KRBTGT account password twice to invalidate any existing Kerberos tickets that may have been issued using the compromised account.
-- Review and analyze security logs to identify any other suspicious activities or accounts that may have been compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed audit logs of account modifications and delegation changes for future investigations.
-- Integrate with security information and event management (SIEM) systems to automate detection and alerting of similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
-- Apply hardening measures such as implementing least privilege access, regular account audits, and continuous monitoring to protect against similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msi_installer_task_startup.toml b/rules/windows/persistence_msi_installer_task_startup.toml
index 3343f7e061c..6c41a97a039 100644
--- a/rules/windows/persistence_msi_installer_task_startup.toml
+++ b/rules/windows/persistence_msi_installer_task_startup.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/05"
 
 [rule]
 author = ["Elastic"]
@@ -48,52 +48,6 @@ any where host.os.type == "windows" and
                     "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*"))
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via a Windows Installer
-
-Windows Installer, through msiexec.exe, facilitates software installation and configuration. Adversaries exploit this by creating persistence mechanisms, such as scheduled tasks or startup entries, to maintain access. The detection rule identifies suspicious activity by monitoring msiexec.exe for file creations in startup directories or registry modifications linked to auto-run keys, signaling potential persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `msiexec.exe` in the process name or effective process name fields, indicating the Windows Installer was involved.
-- Examine the event category and action fields to determine if the alert was triggered by a file creation or registry modification event.
-- If the alert is related to file creation, check the file path to see if it matches known startup directories such as `?:\\Windows\\System32\\Tasks\\*` or user-specific startup paths.
-- For registry modification alerts, verify the registry path to see if it aligns with auto-run keys like `HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*`.
-- Use Osquery to list all scheduled tasks on the system to identify any suspicious or newly created tasks:
-  ```sql
-  SELECT * FROM scheduled_tasks WHERE path LIKE '%\\\\Windows\\\\System32\\\\Tasks\\\\%';
-  ```
-- Investigate the parent process of `msiexec.exe` to understand how it was initiated and whether it was triggered by a legitimate application or script.
-- Check the timestamp of the event to correlate with any known user activity or other suspicious events occurring around the same time.
-- Review the user context under which `msiexec.exe` was executed to determine if it aligns with expected user behavior or privileges.
-- Analyze any associated network activity from the host around the time of the alert to identify potential command and control communication.
-- Gather additional context by reviewing system logs and other security tools for any related alerts or anomalies that could indicate a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate software installations or updates: Many legitimate applications use msiexec.exe to install or update software, which may create entries in startup directories or modify registry auto-run keys. Users should verify if the activity corresponds to known software installations or updates.
-- System maintenance tasks: Some system maintenance tools or scripts may use msiexec.exe to schedule tasks or modify startup settings as part of their normal operation. Users can create exceptions for these known tools to prevent false alerts.
-- IT administrative actions: IT administrators might use msiexec.exe to deploy software across multiple systems, which can trigger the detection rule. Users should ensure that such activities are documented and create exceptions for these administrative actions.
-- Software deployment tools: Tools like SCCM or other deployment solutions might use msiexec.exe to manage software installations, leading to false positives. Users can exclude these tools from the detection rule by identifying their specific process names or paths.
-- Regular system updates: Windows updates or other system updates might involve msiexec.exe, resulting in registry or file changes. Users should correlate the timing of these updates with the detected events to determine if they are benign.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the persistence mechanism by reviewing logs and identifying any unauthorized scheduled tasks or startup entries created by msiexec.exe.
-- Remove any identified malicious scheduled tasks or startup entries and restore legitimate configurations.
-- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software.
-- Review and modify user permissions to ensure that only authorized personnel have the ability to create or modify scheduled tasks and startup entries.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process creation and registry modification events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of critical system files.
-- Harden the system by disabling unnecessary services, applying the principle of least privilege, and ensuring that security configurations align with best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msoffice_startup_registry.toml b/rules/windows/persistence_msoffice_startup_registry.toml
index 6a68f4c7771..4565aedddf2 100644
--- a/rules/windows/persistence_msoffice_startup_registry.toml
+++ b/rules/windows/persistence_msoffice_startup_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -42,48 +42,6 @@ query = '''
 registry where host.os.type == "windows" and event.action != "deletion" and
     registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Office Test Registry Persistence
-
-The Office Test Registry key in Windows environments allows specifying a DLL to execute whenever an Office application launches, intended for legitimate testing purposes. Adversaries exploit this by inserting malicious DLLs, ensuring persistence on compromised systems. The detection rule monitors modifications to this registry path, excluding deletions, to identify potential abuse by tracking unauthorized changes.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path that was modified, focusing on the `registry.path` field to understand which DLL might be involved.
-- Check the `event.action` field to confirm the type of modification that occurred, ensuring it wasn't a deletion, as deletions are excluded from the rule.
-- Investigate the timestamp of the modification to determine when the change occurred and correlate it with other events on the system.
-- Use Osquery to list all DLLs specified in the Office Test Registry path with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_CURRENT_USER\\\\Software\\\\Microsoft\\\\Office Test\\\\Special\\\\Perf\\\\%' OR path LIKE 'HKEY_LOCAL_MACHINE\\\\Software\\\\Microsoft\\\\Office Test\\\\Special\\\\Perf\\\\%';`
-- Examine the DLL file's properties, such as its creation and modification dates, to assess if it aligns with known legitimate software updates or installations.
-- Check the file hash of the DLL against known malware databases to determine if it is a known malicious file.
-- Review recent user activity on the host to identify any suspicious behavior or unauthorized access that might have led to the registry modification.
-- Investigate other registry changes around the same time to identify if there are additional persistence mechanisms being established.
-- Analyze network logs for any unusual outbound connections from the host that might indicate data exfiltration or command and control communication.
-- Cross-reference the host's security logs for any other alerts or anomalies that could provide additional context to the registry modification event.
-
-### False positive analysis
-
-- Legitimate software testing: Developers or IT personnel may use the Office Test Registry key for legitimate testing purposes, leading to benign modifications. Users can handle this by identifying and documenting authorized testing activities and excluding these from alerts.
-- Software updates: Some legitimate software updates might modify the registry key as part of their installation or update process. Users should verify the source of the update and, if confirmed as safe, create exceptions for these specific update activities.
-- Security tools: Certain security or monitoring tools might interact with the registry key as part of their normal operations. Users should review the behavior of these tools and, if deemed non-threatening, exclude them from triggering alerts.
-- Custom scripts or automation: Organizations may have custom scripts or automation processes that modify the registry key for operational purposes. Users should ensure these scripts are documented and create exceptions for their known activities to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the threat.
-- Conduct a thorough investigation to identify the malicious DLL and any associated processes or files. Use endpoint detection and response (EDR) tools to gather detailed information.
-- Remove the unauthorized DLL from the specified Office Test Registry path and any other locations where it may have been copied.
-- Restore the registry to its previous state using backups or system restore points, ensuring no unauthorized changes remain.
-- Perform a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats.
-- Review and enhance logging policies to ensure detailed monitoring of registry changes, particularly focusing on the Office Test Registry path.
-- Implement additional security measures such as application whitelisting to prevent unauthorized DLLs from executing.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Update security policies and conduct user awareness training to prevent similar incidents, emphasizing the risks associated with unauthorized software installations.
-- Consider integrating threat intelligence feeds and MITRE ATT&CK framework mappings into security tools to improve detection and response capabilities for persistence techniques like T1137."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_netsh_helper_dll.toml b/rules/windows/persistence_netsh_helper_dll.toml
index 9eb573494f3..b024cd12e5b 100644
--- a/rules/windows/persistence_netsh_helper_dll.toml
+++ b/rules/windows/persistence_netsh_helper_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,48 +43,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\Software\\Microsoft\\netsh\\*"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Netsh Helper DLL
-
-Netsh Helper DLLs are extensions for the netsh.exe utility, enhancing its capabilities in Windows environments. While legitimate, adversaries can exploit this by adding malicious DLLs, ensuring their payloads execute whenever netsh runs, often via admin actions or scheduled tasks. The detection rule monitors registry changes in specific paths, flagging unauthorized DLL additions to thwart such persistence tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path that triggered the alert, focusing on paths like "HKLM\\\\Software\\\\Microsoft\\\\netsh\\\\*".
-- Verify the legitimacy of the DLL by checking its file path and comparing it against known good DLLs or a whitelist of approved Netsh Helper DLLs.
-- Use Osquery to list all DLLs associated with Netsh by executing: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\Software\\\\Microsoft\\\\netsh\\\\%';`.
-- Investigate the file properties of the suspicious DLL, including its creation and modification dates, using tools like PowerShell or the command line.
-- Check the digital signature of the DLL to ensure it is signed by a trusted publisher.
-- Correlate the timestamp of the registry change event with other logs, such as user login events or scheduled task executions, to identify potential responsible users or processes.
-- Search for any related scheduled tasks that might execute netsh.exe, using commands like `schtasks` or reviewing Task Scheduler logs.
-- Analyze network activity around the time of the registry change to detect any unusual outbound connections that might indicate data exfiltration or command and control communication.
-- Review system logs for any other suspicious activities or errors that coincide with the time of the registry modification.
-- Consult threat intelligence sources to determine if the DLL or its associated file path has been reported in any known attack campaigns or malware signatures.
-
-### False positive analysis
-
-- Legitimate software installations or updates may add or modify Netsh Helper DLLs, triggering the detection rule. Users should verify the source and purpose of the DLL changes to determine if they are part of a trusted application.
-- System administrators might intentionally add custom Netsh Helper DLLs to enhance network management capabilities. In such cases, these changes should be documented and excluded from the detection rule to prevent unnecessary alerts.
-- Some network management tools or scripts may programmatically modify the Netsh registry paths as part of their normal operation. Users should identify these tools and create exceptions for their known behaviors to avoid false positives.
-- Regular audits of the Netsh Helper DLL registry paths can help distinguish between expected changes and potential threats. Users should maintain a baseline of known good DLLs and update their detection rules to exclude these from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized Netsh Helper DLLs by reviewing recent registry changes and correlating them with known malicious indicators.
-- Remove any unauthorized or suspicious DLLs from the registry paths specified in the detection rule to prevent further execution of malicious payloads.
-- Perform a comprehensive malware scan on the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats.
-- Review and analyze system logs, including Windows Event Logs and security logs, to trace the origin of the unauthorized changes and identify potential entry points or compromised accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if additional expertise is required.
-- Implement enhanced logging policies to capture detailed registry changes and process execution events, ensuring better visibility for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to correlate alerts and improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying clean backups, ensuring all security patches and updates are installed, and verifying the integrity of critical system files.
-- Harden the system by implementing least privilege principles, disabling unnecessary services, and regularly auditing user permissions and scheduled tasks to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
index 43893c386f1..35c401eed9e 100644
--- a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
+++ b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/31"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,48 +56,6 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name: ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and process.args : "Set-CASMailbox*ActiveSyncAllowedDeviceIDs*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 New ActiveSyncAllowedDeviceID Added via PowerShell
-
-ActiveSync is a protocol enabling mobile devices to synchronize with Exchange mailboxes. The Set-CASMailbox cmdlet can modify mailbox settings, including allowed devices. Adversaries may exploit this to add unauthorized devices, gaining persistent access to sensitive emails. The detection rule identifies suspicious PowerShell activity by monitoring for specific cmdlet usage, helping to flag potential account manipulation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user account and device involved in the Set-CASMailbox cmdlet execution.
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
-- Investigate the source IP address and host from which the PowerShell command was executed to determine if it is a known or trusted source.
-- Examine the user account's recent activity logs to identify any other unusual or unauthorized actions, such as login attempts from unfamiliar locations or devices.
-- Use Osquery to gather more information about the process execution. For example, run the following query to list recent PowerShell executions: `SELECT * FROM processes WHERE name IN ('powershell.exe', 'pwsh.exe', 'powershell_ise.exe') AND cmdline LIKE '%Set-CASMailbox%ActiveSyncAllowedDeviceIDs%';`
-- Check for any recent changes to the user's mailbox settings, including other cmdlets that may have been executed, to identify potential account manipulation.
-- Review the organization's change management records to verify if the addition of the ActiveSyncAllowedDeviceID was authorized or part of a legitimate change request.
-- Analyze the PowerShell script or command used to execute the Set-CASMailbox cmdlet to understand its intent and whether it contains any malicious or suspicious elements.
-- Investigate any other alerts or incidents related to the same user account or device to determine if this is part of a broader attack or compromise.
-- Consult with the user or their manager to confirm whether they recognize the device and if they authorized its addition to the ActiveSync allowed list.
-
-### False positive analysis
-
-- Routine administrative tasks: IT administrators may regularly use the Set-CASMailbox cmdlet to manage and update ActiveSyncAllowedDeviceIDs for legitimate purposes, such as onboarding new employees or updating device policies. To manage these, consider creating exceptions for known administrative accounts or specific time windows when these tasks are typically performed.
-- Automated scripts: Organizations might have automated scripts that run periodically to update mailbox settings, including ActiveSyncAllowedDeviceIDs. These scripts can trigger false positives. To handle this, identify and exclude these scripts by their unique process arguments or execution paths.
-- Device policy updates: Changes in organizational device policies may require bulk updates to ActiveSyncAllowedDeviceIDs, leading to multiple detections. In such cases, coordinate with the IT team to whitelist these activities during policy rollout periods.
-- Testing and development environments: In environments where Exchange settings are frequently tested or developed, the Set-CASMailbox cmdlet might be used often. Exclude these environments from the detection rule by filtering based on hostnames or IP ranges associated with testing and development.
-
-### Response and remediation
-
-- Immediately isolate the affected user account to prevent further unauthorized access to sensitive emails.
-- Review the PowerShell logs and audit logs to identify the source and scope of the unauthorized Set-CASMailbox cmdlet usage.
-- Verify the legitimacy of the newly added ActiveSyncAllowedDeviceID by contacting the user and checking device enrollment records.
-- Remove any unauthorized devices from the ActiveSyncAllowedDeviceID list to cut off adversary access.
-- Reset the credentials of the compromised account and enforce multi-factor authentication to enhance security.
-- Conduct a thorough investigation to determine if any other accounts or systems have been compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed PowerShell activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Educate users on recognizing phishing attempts and secure handling of credentials to prevent future account manipulation.
-- Apply security hardening measures such as restricting PowerShell usage to administrative accounts and using Just Enough Administration (JEA) to limit cmdlet access."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_registry_uncommon.toml b/rules/windows/persistence_registry_uncommon.toml
index 5a7bfeae050..dba7ca9b4e9 100644
--- a/rules/windows/persistence_registry_uncommon.toml
+++ b/rules/windows/persistence_registry_uncommon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -115,49 +115,6 @@ registry where host.os.type == "windows" and event.type == "change" and
       )
      )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Uncommon Registry Persistence Change
-
-Windows Registry is a critical system database that stores configuration settings. Adversaries exploit registry keys for persistence by adding or modifying entries to execute malicious code during system events like startup or user logon. The detection rule identifies unusual changes in specific registry paths often targeted for stealthy persistence, filtering out common legitimate modifications to highlight potential threats.
-
-### Possible investigation steps
-
-- Review the specific registry path and value that triggered the alert to understand the context of the change. Focus on paths listed in the query, such as `HKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Winlogon\\\\Userinit`.
-- Check the `registry.data.strings` field to identify the new or modified data associated with the registry change. This can provide clues about the potential payload or command being executed.
-- Investigate the process that made the registry change by examining the `process.name` and `process.executable` fields. Determine if the process is legitimate or potentially malicious.
-- Use Osquery to gather additional context about the process that made the change. For example, run the following query to list processes with their command-line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE name = '<process_name>';`.
-- Cross-reference the process information with known good and bad processes to assess the likelihood of malicious activity. Utilize threat intelligence sources if available.
-- Examine the system's event logs around the time of the registry change for any related events, such as user logons or other system changes, to build a timeline of activity.
-- Check for any network connections initiated by the process that made the registry change. This can help identify potential command and control communication.
-- Investigate the user account context under which the registry change was made. Determine if the account has a history of suspicious activity or if it was compromised.
-- Review any recent software installations or updates that might have legitimately modified the registry. This can help rule out false positives.
-- If the registry change is associated with a known persistence technique, research the specific technique to understand its implications and how it might be leveraged by an adversary.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify registry keys for legitimate persistence purposes, such as adding entries to the Run or RunOnce keys. Users can handle these by monitoring installation activities and correlating them with registry changes.
-- System administrators might use scripts or group policies that modify registry keys for configuration management. These should be documented and excluded from alerts by creating exceptions for known administrative processes.
-- Security software, like antivirus or endpoint protection solutions, may alter registry settings as part of their normal operation. Users should identify these processes and exclude them from detection by specifying their executable paths in the exception list.
-- Windows system processes, such as `msiexec.exe` or `svchost.exe`, may trigger registry changes during normal operations like updates or system maintenance. Users can manage these by excluding these processes from detection when they are associated with known benign registry paths or values.
-- Custom scripts or applications developed in-house that require registry modifications for functionality might trigger false positives. Users should document these applications and create specific exceptions based on their known behaviors and registry paths.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential threats.
-- Conduct a thorough investigation of the registry changes to identify any unauthorized or malicious entries.
-- Utilize endpoint detection and response (EDR) tools to analyze the processes and executables associated with the registry changes.
-- Remove or revert any unauthorized registry modifications to their original state to restore system integrity.
-- Scan the system with updated antivirus and anti-malware tools to detect and remove any associated threats.
-- Review and enhance logging policies to ensure comprehensive monitoring of registry changes and related system activities.
-- Implement additional security measures such as application whitelisting and user access controls to prevent unauthorized registry modifications.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is determined to be part of a larger attack campaign.
-- Document the incident, including the root cause analysis and remediation steps, to improve future response efforts.
-- Consider deploying threat intelligence integrations to stay informed about emerging threats and tactics related to registry persistence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_remote_password_reset.toml b/rules/windows/persistence_remote_password_reset.toml
index d6c14a40a56..c0698e0647d 100644
--- a/rules/windows/persistence_remote_password_reset.toml
+++ b/rules/windows/persistence_remote_password_reset.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -18,50 +18,7 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Account Password Reset Remotely"
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Account Password Reset Remotely
-
-Remote password resets are crucial for managing user access in distributed environments. However, adversaries exploit this by resetting passwords of privileged accounts to maintain unauthorized access or bypass security policies. The detection rule identifies such activities by monitoring successful network logins followed by password resets on accounts with administrative-like names or specific security identifiers, flagging potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific account involved in the password reset by examining the `winlog.event_data.TargetUserName` field.
-- Check the `source.ip` field to determine the origin of the network login and assess if it is from a known or suspicious location.
-- Investigate the `winlog.computer_name` to identify the system where the password reset was initiated and verify if it is a legitimate administrative system.
-- Correlate the `winlog.event_data.TargetLogonId` and `winlog.event_data.SubjectLogonId` fields to trace the session and user context of the login and password reset events.
-- Use Osquery to gather additional context on the involved system. For example, run the following query to list recent logins on the system: `SELECT * FROM logged_in_users WHERE user = '<TargetUserName>';`.
-- Examine historical login patterns for the `winlog.event_data.TargetUserName` to identify any anomalies or deviations from normal behavior.
-- Check for any recent changes in group memberships or privileges for the account using the `winlog.event_data.TargetSid` to ensure no unauthorized privilege escalation has occurred.
-- Review any related security logs or alerts around the time of the event to identify potential lateral movement or other suspicious activities.
-- Investigate any other accounts accessed from the same `source.ip` to determine if there is a broader compromise.
-- Consult with the account owner or relevant personnel to verify if the password reset was authorized and gather any additional context or concerns they might have.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular password resets by IT staff for maintenance or user support can trigger false positives. To manage this, exclude known IT staff accounts or specific IP addresses from the rule.
-- Automated system processes: Scheduled tasks or scripts that reset passwords for service accounts might be flagged. Identify and exclude these accounts by adding their specific naming conventions to the exception list.
-- Third-party management tools: Tools used for account management that perform password resets as part of their operation can cause alerts. Whitelist these tools by excluding their associated IP addresses or account names.
-- Frequent password policy changes: Organizations with strict password policies may have frequent legitimate resets. Adjust the rule to account for these by excluding accounts that follow a predictable reset pattern.
-- Shared administrative accounts: In environments where shared accounts are used, legitimate resets by different users can appear suspicious. Consider excluding these accounts or implementing additional monitoring to verify legitimate use.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Verify the legitimacy of the password reset by contacting the account owner or reviewing recent activity logs.
-- If unauthorized access is confirmed, reset the compromised account's password and any other accounts that may have been affected.
-- Conduct a thorough investigation to identify the source of the breach, including reviewing network logs, authentication logs, and any other relevant security logs.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement additional monitoring and alerting for suspicious account activities, focusing on privileged accounts.
-- Review and enhance logging policies to ensure comprehensive coverage of authentication and account management events.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actors and tactics.
-- Restore the system to its operational state by applying security patches, updating configurations, and ensuring all security controls are functioning correctly.
-- Implement hardening measures such as enforcing strong password policies, enabling multi-factor authentication, and restricting remote access to privileged accounts.
-
+note = """
 ## Performance
 This rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity.
 """
diff --git a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
index ef781e850cf..ddc19d2048d 100644
--- a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
+++ b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,49 +51,6 @@ sequence by host.id, user.name with maxspan=1m
     process.args : ("C:\\Users\\*", "C:\\ProgramData\\*", "C:\\Windows\\Temp\\*", "C:\\Windows\\Tasks\\*", "C:\\PerfLogs\\*", "C:\\Intel\\*")
    ]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution of Persistent Suspicious Program
-
-Persistent programs, often legitimate, can be exploited by adversaries to maintain access to a system. By leveraging process lineage and command line analysis, attackers may execute scripts or utilities like PowerShell or rundll32 to persist malicious activities. The detection rule identifies such abuse by monitoring the sequence of process executions post-login, flagging early child processes of explorer.exe that are unlikely to be user-initiated, and scrutinizing their command line arguments and file paths for suspicious patterns.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host and user involved, using the `host.id` and `user.name` fields from the query.
-- Examine the process lineage to confirm the sequence of `userinit.exe`, `explorer.exe`, and the suspicious child process. Verify the `process.name` and `process.parent.name` fields to ensure the sequence matches the alert criteria.
-- Analyze the command line arguments of the suspicious process using the `process.args` field to identify any unusual or potentially malicious commands or scripts being executed.
-- Check the file path of the suspicious process using the `process.args` field to determine if it matches any of the known suspicious paths, such as `C:\\Users\\*`, `C:\\ProgramData\\*`, or `C:\\Windows\\Temp\\*`.
-- Investigate the parent process `explorer.exe` to determine if it has any other unusual child processes that may indicate further suspicious activity.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following Osquery query to list all processes with their parent process IDs and command line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cscript.exe', 'wscript.exe', 'PowerShell.EXE', 'MSHTA.EXE', 'RUNDLL32.EXE', 'REGSVR32.EXE', 'RegAsm.exe', 'MSBuild.exe', 'InstallUtil.exe');`
-- Check the system's startup items and scheduled tasks to identify any persistent mechanisms that may have been used to execute the suspicious program.
-- Review recent login events on the host to correlate the timing of the suspicious process execution with user activity, using event logs or security information and event management (SIEM) tools.
-- Investigate any network connections initiated by the suspicious process to identify potential command and control (C2) communication or data exfiltration attempts.
-- Consult threat intelligence sources to determine if the identified process or command line patterns are associated with known malware or adversary techniques.
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators often use scripts for maintenance tasks, which may trigger the rule if they are executed shortly after login. To manage this, users can create exceptions for known administrative scripts by specifying their file paths or command line arguments.
-- Software updates and installations: Some software updates or installations may use processes like PowerShell or rundll32, which could be flagged as suspicious. Users can handle these by excluding specific update or installation processes that are known to be safe.
-- Automated tasks and scheduled jobs: Certain automated tasks or scheduled jobs may run shortly after login and use processes listed in the detection rule. Users can exclude these tasks by identifying their specific command line patterns or file paths.
-- Development tools: Developers might use tools like MSBuild or InstallUtil during their workflow, which could be misidentified as malicious. Users can create exceptions for these tools when used in known development environments or by specific user accounts.
-- Security software: Some security software may use similar processes to perform legitimate actions, such as scanning or updating. Users should identify and exclude these processes by verifying their source and purpose.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the flagged processes and their command line arguments to confirm malicious activity.
-- Terminate any suspicious processes identified during the investigation to halt ongoing malicious activities.
-- Review and analyze the process lineage to understand the scope of the compromise and identify any additional affected systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and command line activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by removing any malicious files and ensuring all software is up to date with the latest security patches.
-- Harden the system by disabling unnecessary services and implementing application whitelisting to prevent unauthorized execution of scripts and utilities.
-- Conduct a post-incident review to identify gaps in detection and response capabilities and update security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_scheduled_task_creation_winlog.toml b/rules/windows/persistence_scheduled_task_creation_winlog.toml
index b018a814c6d..6fa9f59b94f 100644
--- a/rules/windows/persistence_scheduled_task_creation_winlog.toml
+++ b/rules/windows/persistence_scheduled_task_creation_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,48 +44,6 @@ iam where event.action == "scheduled-task-created" and
               "\\OneDrive Standalone Update Task-S-1-12-1-*"
  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 A scheduled task was created
-
-Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, and privilege escalation. Malicious actors may create tasks to execute harmful scripts or programs at specific times. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats that align with known attack techniques.
-
-### Possible investigation steps
-
-- Review the event logs to confirm the creation of the scheduled task by checking the `event.action` field for "scheduled-task-created".
-- Verify the `user.name` field to identify the user account that created the task, ensuring it is not a system account or a known service account.
-- Examine the `winlog.event_data.TaskName` field to determine the name of the scheduled task and check if it matches any known malicious patterns or unusual naming conventions.
-- Cross-reference the `winlog.event_data.TaskName` with a list of known benign tasks to ensure it is not mistakenly flagged.
-- Use Osquery to list all scheduled tasks on the system and identify any discrepancies or unknown tasks. Example query: `SELECT * FROM scheduled_tasks WHERE name = '<TaskName>';`.
-- Investigate the `winlog.event_data.TaskContent` if available, to understand the script or program that the task is set to execute.
-- Check the creation time of the task to determine if it aligns with any known suspicious activity or outside of normal business hours.
-- Analyze the system's recent login events to correlate the task creation with any unusual login activity or unauthorized access attempts.
-- Review any associated network activity around the time of task creation to identify potential lateral movement or data exfiltration attempts.
-- Consult threat intelligence sources to see if the task name or associated user account has been linked to any known attack campaigns or threat actors.
-
-### False positive analysis
-
-- Scheduled tasks created by legitimate software updates or system maintenance can trigger false positives. For example, tasks related to HP device checks or Microsoft Visual Studio updates are common and benign.
-- Tasks initiated by OneDrive updates are also frequent and typically non-threatening, as they are part of regular software maintenance.
-- To manage these false positives, users can exclude specific task names from the detection rule, as shown in the provided query. This involves adding known benign task names to the exclusion list to prevent unnecessary alerts.
-- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the detection rule remains effective without generating excessive false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Review the details of the scheduled task creation event, including the user account involved and the task's payload, to assess the potential impact and scope of the compromise.
-- Terminate any malicious processes associated with the scheduled task and delete the task itself to prevent further execution.
-- Conduct a thorough investigation of the affected system and related systems to identify any additional indicators of compromise or persistence mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team if the task is linked to known advanced persistent threat (APT) groups or if the scope of the attack is beyond initial containment efforts.
-- Implement enhanced logging policies to capture detailed information on scheduled task creation and execution, including command-line arguments and user context.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting scheduled task creation to authorized users only and using application whitelisting to prevent unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_scheduled_task_updated.toml b/rules/windows/persistence_scheduled_task_updated.toml
index 2f08831bc42..6983c1da7a1 100644
--- a/rules/windows/persistence_scheduled_task_updated.toml
+++ b/rules/windows/persistence_scheduled_task_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,49 +48,6 @@ iam where event.action == "scheduled-task-updated" and
            "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload") and 
   not winlog.event_data.SubjectUserSid :  ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 A scheduled task was updated
-
-Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this by modifying tasks to maintain persistence, often altering legitimate tasks to avoid detection. The detection rule identifies suspicious updates by filtering out benign changes, such as those by system accounts or known safe tasks, focusing on anomalies that suggest malicious intent.
-
-### Possible investigation steps
-
-- Review the event logs to confirm the occurrence of the "scheduled-task-updated" event and identify the specific task that was modified.
-- Examine the `user.name` field to determine the account responsible for the task update and verify if it is a legitimate user or potentially compromised account.
-- Investigate the `winlog.event_data.TaskName` field to identify the name of the scheduled task that was updated and assess if it is a known legitimate task or an unusual one.
-- Check the `winlog.event_data.SubjectUserSid` field to ensure the task update was not performed by system accounts (e.g., S-1-5-18, S-1-5-19, S-1-5-20) which are typically benign.
-- Use Osquery to gather more information about the scheduled task by running a query such as: `SELECT * FROM scheduled_tasks WHERE name = '<TaskName>'` to retrieve details about the task's configuration and recent changes.
-- Cross-reference the task name and user account with known safe lists or previous incidents to determine if this is a recurring issue or a new anomaly.
-- Analyze the timing of the task update to see if it coincides with other suspicious activities or known attack patterns.
-- Investigate the system's security logs for any other unusual activities or alerts around the time of the task update to identify potential lateral movement or privilege escalation.
-- Review the system's network logs to check for any outbound connections or data exfiltration attempts following the task update.
-- Consult threat intelligence sources to see if the task name or user account has been associated with known malware or attack campaigns.
-
-### False positive analysis
-
-- Scheduled tasks updated by legitimate software updates or system maintenance activities can trigger false positives. These often involve tasks related to system or software updates, such as those by Microsoft or other trusted vendors.
-- Tasks modified by IT administrators for maintenance or operational purposes may also appear suspicious. These changes are typically routine and part of regular system management.
-- To manage these false positives, users can create exceptions for known benign tasks by adding them to the exclusion list in the detection rule. This involves identifying the specific task names or user accounts responsible for legitimate updates and excluding them from triggering alerts.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate tasks that may have been introduced.
-- Collaborate with IT and security teams to understand the context of scheduled task updates and distinguish between legitimate administrative actions and potential threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Review the specific scheduled task changes in the event logs to identify unauthorized modifications and determine the scope of the compromise.
-- Verify the legitimacy of the user account that made the changes to the scheduled task, checking for signs of account compromise.
-- Restore the scheduled task to its original configuration using backups or by manually resetting it to a known good state.
-- Conduct a thorough malware scan on the affected system to identify and remove any malicious software that may have been introduced.
-- Escalate the incident to the security operations center (SOC) or incident response team if the task modification is linked to a broader attack campaign.
-- Implement enhanced logging policies to capture detailed information on scheduled task changes, including user actions and timestamps.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of similar threats in the future.
-- Educate users on the importance of using strong, unique passwords and enable multi-factor authentication to reduce the risk of account compromise.
-- Regularly review and update security policies and procedures to ensure they align with the latest threat intelligence and best practices for system hardening."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_service_dll_unsigned.toml b/rules/windows/persistence_service_dll_unsigned.toml
index 468ac20d93b..63ce6c7c0e4 100644
--- a/rules/windows/persistence_service_dll_unsigned.toml
+++ b/rules/windows/persistence_service_dll_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/23"
 
 [rule]
 author = ["Elastic"]
@@ -126,49 +126,6 @@ library where host.os.type == "windows" and
              "23aa95b637a1bf6188b386c21c4e87967ede80242327c55447a5bb70d9439244", 
              "5050b025909e81ae5481db37beb807a80c52fc6dd30c8aa47c9f7841e2a31be7")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unsigned DLL Loaded by Svchost
-
-Svchost.exe is a critical Windows process that hosts multiple services, allowing efficient resource management. Adversaries exploit this by loading unsigned DLLs to gain persistence or elevated privileges. The detection rule identifies such threats by monitoring DLLs recently created and loaded by svchost, focusing on untrusted signatures and unusual file paths, thus flagging potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of an unsigned DLL loaded by svchost.exe, focusing on the `dll.code_signature.trusted` field to verify the signature status.
-- Check the `dll.Ext.relative_file_creation_time` to determine if the DLL was created within 5 minutes of being loaded, indicating potential malicious activity.
-- Investigate the `dll.path` to identify if the DLL is located in any unusual or suspicious directories listed in the query, which could suggest unauthorized placement.
-- Examine the `dll.hash.sha256` to ensure it is not part of the known benign hashes excluded in the query, which could indicate a false positive.
-- Use Osquery to gather more information about the DLL file. For example, run the following query to list details about the DLL: `SELECT * FROM file WHERE path = '<DLL_PATH>';` replacing `<DLL_PATH>` with the actual path of the DLL.
-- Cross-reference the DLL's hash with threat intelligence databases to check for any known associations with malware or suspicious activity.
-- Analyze the parent process of svchost.exe to determine if it was spawned by a legitimate process or if there are any anomalies in its process tree.
-- Investigate recent system changes or installations that might have introduced the unsigned DLL, focusing on any unusual or unauthorized software installations.
-- Review system logs and event logs around the time of the DLL creation and loading to identify any related suspicious activities or errors.
-- Conduct a network analysis to check for any unusual outbound connections or data exfiltration attempts that might be associated with the loaded DLL.
-
-### False positive analysis
-
-- Some legitimate software may load unsigned DLLs as part of their normal operation, especially older applications or those developed by smaller vendors who may not sign their libraries. Users should verify the legitimacy of such software and consider excluding these specific DLLs from the detection rule.
-- System administrators might deploy custom scripts or tools that load unsigned DLLs for maintenance or monitoring purposes. These should be reviewed and, if deemed safe, added to an exception list to prevent false alerts.
-- Certain security or system management tools might intentionally load unsigned DLLs to perform specific functions. Users should confirm the source and purpose of these tools and exclude them if they are verified as non-malicious.
-- In some cases, software updates or patches might temporarily load unsigned DLLs before a signature is applied. Users should monitor update cycles and exclude these DLLs if they are confirmed to be part of a legitimate update process.
-- To manage false positives, users can create exceptions based on the hash of known non-malicious DLLs, the file path, or the specific software involved, ensuring that only verified and trusted instances are excluded from detection.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the unsigned DLL's legitimacy by checking its hash against known malware databases and analyzing its behavior.
-- Terminate the svchost process that loaded the unsigned DLL if it is confirmed to be malicious.
-- Remove the malicious DLL from the system and any associated registry entries or scheduled tasks that may have been created for persistence.
-- Conduct a full antivirus and antimalware scan on the affected system to identify and remove any additional threats.
-- Review and enhance logging policies to ensure detailed monitoring of DLL loads, process creations, and network connections.
-- Implement application whitelisting to prevent unauthorized DLLs from being loaded by svchost or other critical processes.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
-- Educate users on recognizing suspicious activities and reinforce security awareness to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_services_registry.toml b/rules/windows/persistence_services_registry.toml
index 473c59cec07..7225410023f 100644
--- a/rules/windows/persistence_services_registry.toml
+++ b/rules/windows/persistence_services_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -65,49 +65,6 @@ registry where host.os.type == "windows" and event.type == "change" and
       "?:\\Windows\\System32\\WaaSMedicAgent.exe"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Persistence via Services Registry
-
-Windows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path and value that triggered the alert, focusing on the `registry.path` and `registry.value` fields.
-- Check the `process.name` and `process.executable` fields to determine which process made the registry change and assess if it is a known legitimate process or potentially malicious.
-- Investigate the parent process of the identified process to understand the process tree and determine if the process was spawned by a legitimate application or a suspicious one.
-- Use Osquery to list all services and their associated executables to identify any discrepancies or unusual entries. Example query: `SELECT name, display_name, path FROM services WHERE path LIKE '%ServiceDLL%' OR path LIKE '%ImagePath%';`
-- Examine the `registry.data.strings` field to see the new data written to the registry and assess if it points to a legitimate or suspicious file path.
-- Cross-reference the file path in `registry.data.strings` with known good files and directories to identify any anomalies or unauthorized files.
-- Check the file hash of the executable involved in the registry change against threat intelligence databases to determine if it is associated with known malware.
-- Review recent system logs and events around the time of the registry change to identify any other suspicious activities or related events.
-- Investigate the user account context under which the process ran to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Analyze network connections made by the process to identify any unusual or unauthorized external communications that could suggest malicious activity.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify service registry keys directly, leading to false positives. Users can handle these by identifying the specific software involved and creating exceptions for its processes.
-- System maintenance tools, such as those used for driver updates or system optimizations, might also trigger this rule. Users should verify the legitimacy of these tools and exclude their processes if deemed safe.
-- Custom scripts or administrative tools that modify service configurations for legitimate purposes can be mistaken for malicious activity. Users should document these scripts and add them to the exclusion list to prevent false alerts.
-- Certain enterprise applications may have unique installation or update mechanisms that interact with the registry in non-standard ways. Users should work with their IT departments to identify these applications and configure exceptions accordingly.
-- Security software or monitoring tools that perform deep system scans or modifications might be flagged. Users should ensure these tools are from trusted vendors and exclude their processes to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the process responsible for the registry modification by analyzing logs and correlating with known malicious indicators.
-- Terminate any suspicious processes identified during the investigation to halt potential malicious activity.
-- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries.
-- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Apply security patches and updates to the operating system and installed software to mitigate vulnerabilities that could be exploited for persistence.
-- Review and strengthen access controls and user permissions to limit the ability of unauthorized users to modify critical system settings."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
index 5a7ae86c030..a593685c0f5 100644
--- a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
+++ b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,52 +80,6 @@ process where host.os.type == "windows" and event.type == "start" and
      not (process.name : "powershell.exe" and process.args : ("-File", "-PSConsoleFile") and user.id : "S-1-5-18") and
      not (process.name : "msiexec.exe" and user.id : "S-1-5-18")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Execution via Scheduled Task
-
-Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence by executing malicious programs. They may use common utilities like PowerShell or scripts in unusual directories. The detection rule identifies such abuse by analyzing process lineage, command line usage, and excluding known benign activities, focusing on suspicious programs and paths.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific process triggered the rule, focusing on the `process.pe.original_file_name` and `process.args` fields to identify the suspicious program and its execution path.
-- Examine the `process.parent.name` and `process.parent.args` fields to confirm the parent process is `svchost.exe` with the "Schedule" argument, indicating the use of scheduled tasks.
-- Check the `event.type` field to ensure the event is a process start, confirming the execution of the suspicious program.
-- Investigate the user context by reviewing the `user.id` field to determine if the process was executed under a privileged account or a service account.
-- Use Osquery to gather additional context about the scheduled task. For example, run the following query to list all scheduled tasks and their associated actions:
-  ```sql
-  SELECT * FROM scheduled_tasks WHERE action LIKE '%cscript.exe%' OR action LIKE '%wscript.exe%' OR action LIKE '%PowerShell.EXE%' OR action LIKE '%Cmd.Exe%' OR action LIKE '%MSHTA.EXE%' OR action LIKE '%RUNDLL32.EXE%' OR action LIKE '%REGSVR32.EXE%' OR action LIKE '%MSBuild.exe%' OR action LIKE '%InstallUtil.exe%' OR action LIKE '%RegAsm.exe%' OR action LIKE '%RegSvcs.exe%' OR action LIKE '%msxsl.exe%' OR action LIKE '%CONTROL.EXE%' OR action LIKE '%EXPLORER.EXE%' OR action LIKE '%Microsoft.Workflow.Compiler.exe%' OR action LIKE '%msiexec.exe%';
-  ```
-- Analyze the command line arguments (`process.args`) for any encoded or obfuscated commands that may indicate malicious intent.
-- Cross-reference the suspicious paths (`process.args`) with known legitimate software installations or temporary file usage to rule out false positives.
-- Review recent system changes or installations that might have introduced the suspicious program or scheduled task.
-- Check for any network connections initiated by the suspicious process to identify potential command and control communication.
-- Correlate the findings with other security alerts or logs to determine if this activity is part of a broader attack campaign.
-
-### False positive analysis
-
-- Scheduled tasks created by legitimate software updates or system maintenance tools can trigger false positives. These tasks often use common utilities like PowerShell or cmd.exe, which are also used by malicious actors.
-- System administrators may use scheduled tasks to run scripts for routine maintenance or monitoring, which can appear suspicious if they use paths or programs listed in the detection rule.
-- Some enterprise applications may use scheduled tasks to perform legitimate background operations, especially if they are installed in non-standard directories like C:\\ProgramData or C:\\Windows\\Temp.
-- To manage these false positives, users can create exceptions for known benign activities by excluding specific process names, paths, or user IDs that are frequently involved in legitimate scheduled tasks.
-- Regularly review and update the list of excluded processes and paths to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Investigate the scheduled task to determine the origin and purpose of the suspicious execution, focusing on the process lineage and command line arguments.
-- Terminate any malicious processes identified during the investigation to stop ongoing threats.
-- Remove or disable the malicious scheduled task to prevent future execution.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
-- Review and analyze system logs, including Windows Event Logs and security logs, to trace the attack vector and identify any other compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and command line arguments for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate suspicious activities.
-- Apply system hardening measures, such as restricting the use of scripting engines and enforcing least privilege access, to reduce the attack surface and prevent similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_suspicious_service_created_registry.toml b/rules/windows/persistence_suspicious_service_created_registry.toml
index 72058869b24..491958437d6 100644
--- a/rules/windows/persistence_suspicious_service_created_registry.toml
+++ b/rules/windows/persistence_suspicious_service_created_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,49 +45,6 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* add suspicious registry ImagePath values here */
   registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious ImagePath Service Creation
-
-Windows services are crucial for running background processes. Adversaries may exploit the ImagePath registry value to persist or escalate privileges by pointing it to malicious executables or scripts. The detection rule monitors changes to this registry path, focusing on unusual patterns like command shells or named pipes, which often indicate malicious intent. This helps identify potential threats early in the attack lifecycle.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path and data that triggered the alert, focusing on the `registry.path` and `registry.data.strings` fields.
-- Check the `host.os.type` to ensure the alert is relevant to a Windows system, as the rule is designed for Windows environments.
-- Investigate the `event.type` to verify that the change event is consistent with a suspicious modification, indicating a potential threat.
-- Use Osquery to list all services and their ImagePath values on the affected host to identify any other unusual entries. Example query: `SELECT name, image_path FROM services WHERE image_path LIKE '%\\\\pipe\\\\%' OR image_path LIKE '%COMSPEC%';`
-- Examine the process creation logs around the time of the registry change to identify any processes that might have been responsible for the modification.
-- Correlate the suspicious ImagePath with any known malicious executables or scripts by checking threat intelligence sources or databases.
-- Investigate the user account context under which the registry change was made to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Review recent login events on the affected host to identify any unusual or unauthorized access patterns that could be related to the suspicious service creation.
-- Check for any network connections initiated by the suspicious service, especially those involving named pipes, to identify potential lateral movement or data exfiltration attempts.
-- Analyze any related file modifications or creations in the system directories that could be associated with the suspicious ImagePath, looking for signs of tampering or unauthorized files.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify the ImagePath registry value, triggering the rule. Users should verify if the change aligns with recent software activities.
-- System administrators might create or modify services for maintenance or configuration purposes, which could be flagged. It's important to confirm if these actions were authorized and expected.
-- Some security tools or monitoring software may use command shells or named pipes in their operations, leading to false positives. Users can create exceptions for these known tools by specifying their paths or signatures.
-- Automated scripts or deployment tools that configure services might also be detected. Users should review these scripts and, if deemed safe, exclude them from monitoring by adding their specific patterns to the exception list.
-- Regularly review and update the exception list to ensure it reflects the current environment and excludes only verified non-threatening behaviors.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent lateral movement and further compromise.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the suspicious ImagePath registry changes.
-- Review recent service creations and modifications in the registry to identify any unauthorized or malicious entries.
-- Remove or disable any malicious services identified during the investigation to prevent further execution.
-- Restore the system to a known good state using backups or system restore points, ensuring that no malicious services are reintroduced.
-- Implement enhanced logging policies to capture detailed registry changes and service creation events for future analysis.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents.
-- Apply system hardening measures, such as restricting permissions on critical registry paths and disabling unnecessary services, to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_sysmon_wmi_event_subscription.toml b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
index 98df1eb92e5..3a2b3cca798 100644
--- a/rules/windows/persistence_sysmon_wmi_event_subscription.toml
+++ b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/02/02"
 integration = ["windows", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/23"
 min_stack_version = "8.15.0"
 min_stack_comments = "Elastic Defend WMI events were added in Elastic Defend 8.15.0."
 
@@ -45,49 +45,6 @@ any where
     process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer"))
  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious WMI Event Subscription Created
-
-Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this by creating malicious event subscriptions to maintain persistence or execute code with elevated privileges. The detection rule identifies such abuse by monitoring specific event creation patterns linked to suspicious consumer types, indicating potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of event code 21 from the "windows.sysmon_operational" dataset, indicating a WMI event subscription creation.
-- Examine the `winlog.event_data.Operation` field to ensure it specifies "Created," confirming the creation of a new event subscription.
-- Analyze the `winlog.event_data.Consumer` field to identify if it matches suspicious patterns like "*subscription:CommandLineEventConsumer*" or "*subscription:ActiveScriptEventConsumer*," which are commonly used in malicious activities.
-- Check the timestamp of the event to determine when the suspicious WMI event subscription was created and correlate it with other events or activities on the system around the same time.
-- Investigate the user account associated with the event to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior.
-- Use Osquery to gather more information about the WMI subscriptions on the affected system. For example, run the query: `SELECT * FROM wmi_event_subscriptions WHERE consumer LIKE '%CommandLineEventConsumer%' OR consumer LIKE '%ActiveScriptEventConsumer%';` to identify all similar subscriptions.
-- Cross-reference the system's process creation logs to identify any processes that were spawned as a result of the WMI event subscription, focusing on unusual or unexpected processes.
-- Review the system's security logs for any signs of privilege escalation or lateral movement attempts that might be associated with the WMI event subscription.
-- Investigate any network connections initiated by the system around the time of the event to identify potential communication with external or suspicious IP addresses.
-- Consult threat intelligence sources to determine if the identified WMI event subscription patterns are associated with known malware or threat actor tactics.
-
-### False positive analysis
-
-- Legitimate administrative tools and scripts may create WMI event subscriptions for system monitoring or automation purposes, which can trigger this detection rule. 
-- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes, leading to benign alerts.
-- System management software, such as configuration management tools or monitoring solutions, often utilize WMI event subscriptions to track system changes or performance metrics.
-- To manage these false positives, users can create exceptions for known and trusted applications or scripts by identifying their specific event patterns and excluding them from the detection rule.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule against genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Use endpoint detection and response (EDR) tools to collect and analyze forensic data from the affected system, focusing on the WMI event subscription details.
-- Identify and terminate any malicious processes or scripts associated with the suspicious WMI event subscription.
-- Review and remove any unauthorized WMI event subscriptions, particularly those linked to CommandLineEventConsumer or ActiveScriptEventConsumer.
-- Conduct a thorough investigation to determine if the attacker has established additional persistence mechanisms or compromised other systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to assess the scope of the breach.
-- Implement enhanced logging policies to capture detailed WMI activity and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Restore the system to a known good state using backups or reimaging, ensuring all malicious artifacts are removed.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Strengthen system hardening measures by disabling unnecessary WMI features and enforcing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_temp_scheduled_task.toml b/rules/windows/persistence_temp_scheduled_task.toml
index 27e2c69e87c..a23aede04b4 100644
--- a/rules/windows/persistence_temp_scheduled_task.toml
+++ b/rules/windows/persistence_temp_scheduled_task.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,49 +37,6 @@ sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m
    [iam where event.action == "scheduled-task-created" and not user.name : "*$"]
    [iam where event.action == "scheduled-task-deleted" and not user.name : "*$"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Temporarily Scheduled Task Creation
-
-Scheduled tasks in Windows environments automate routine tasks, but adversaries exploit them for persistence and stealthy execution. By creating and quickly deleting tasks, they can execute malicious code while evading detection. The detection rule identifies this behavior by tracking task creation and deletion events within a short timeframe, flagging potential misuse by excluding system accounts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the `winlog.computer_name` and `winlog.event_data.TaskName` fields to determine which system and task are involved.
-- Check the timestamp of the task creation and deletion events to confirm they occurred within the specified `maxspan=5m` timeframe.
-- Investigate the user account associated with the task creation and deletion events, ensuring it is not a system account (i.e., does not end with `$`).
-- Use Osquery to list all scheduled tasks on the affected system to verify if the task still exists or if it was indeed deleted. Example query: `SELECT * FROM scheduled_tasks WHERE name = '<TaskName>';`
-- Examine the command or script associated with the scheduled task to identify any potentially malicious code or unusual behavior.
-- Cross-reference the task name and associated command with known indicators of compromise (IOCs) or threat intelligence feeds.
-- Analyze the system's event logs around the time of the task creation and deletion for any other suspicious activities or related events.
-- Check for any recent changes in user privileges or group memberships that might have allowed the creation of the scheduled task.
-- Investigate network logs for any unusual outbound connections from the affected system around the time of the task execution.
-- Review historical data to determine if similar scheduled task creation and deletion patterns have occurred on the same or other systems within the network.
-
-### False positive analysis
-
-- Scheduled tasks created and deleted by legitimate software updates or system maintenance tools can trigger false positives. These tasks often run under non-system accounts but are benign in nature.
-- Automated scripts or administrative tools used by IT departments for routine maintenance might create and delete tasks within a short timeframe, mimicking the behavior flagged by the rule.
-- Users can manage these false positives by identifying and documenting known legitimate task creation and deletion patterns, then creating exceptions for these specific tasks or user accounts.
-- Implementing a whitelist of trusted applications and scripts that are known to create and delete tasks can help reduce noise and focus on truly suspicious activities.
-- Regularly review and update the list of exceptions to ensure it reflects current legitimate activities, especially after software updates or changes in IT processes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity.
-- Review the scheduled task creation and deletion logs to confirm the presence of suspicious activity and identify any associated user accounts.
-- Conduct a thorough investigation to determine if any malicious payloads were executed and assess the scope of the compromise.
-- Remove any unauthorized scheduled tasks and ensure no remnants of the malicious activity remain on the system.
-- Reset credentials for any compromised user accounts and enforce strong password policies to prevent future unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed information on scheduled task activities and user actions for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify system integrity.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_user_account_creation_event_logs.toml b/rules/windows/persistence_user_account_creation_event_logs.toml
index 24061159a2e..316984f9db8 100644
--- a/rules/windows/persistence_user_account_creation_event_logs.toml
+++ b/rules/windows/persistence_user_account_creation_event_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["system", "windows"]
 maturity = "development"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,48 +34,6 @@ query = '''
 event.module:("system" or "security") and winlog.api:"wineventlog" and
   (event.code:"4720" or event.action:"added-user-account")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows User Account Creation
-
-Windows user accounts are essential for managing access and permissions within systems and domains. Adversaries may exploit this by creating unauthorized accounts to maintain persistence or escalate privileges. The detection rule leverages event logs, specifically targeting account creation events, to identify suspicious activities indicative of such abuse, aligning with MITRE ATT&CK's persistence tactics.
-
-### Possible investigation steps
-
-- Review the event logs for the specific event codes 4720 or actions labeled as "added-user-account" to confirm the account creation event.
-- Identify the user account that was created and note the username and any associated details such as the domain or system where it was created.
-- Check the timestamp of the account creation event to determine when the account was created and correlate it with other events around the same time for additional context.
-- Investigate the source of the account creation by identifying the user or process that initiated the event, using fields such as event.module and winlog.api.
-- Examine the system or domain where the account was created to determine if there are any other suspicious activities or anomalies present.
-- Use Osquery to gather more information about the newly created account. For example, run the query: `SELECT * FROM users WHERE username = '<newly_created_username>';` to retrieve details about the account.
-- Analyze the privileges and group memberships of the newly created account to assess if it has elevated permissions that could pose a security risk.
-- Cross-reference the account creation event with other security alerts or logs to identify any patterns or indicators of compromise.
-- Investigate any recent changes to user account policies or configurations that could have facilitated unauthorized account creation.
-- Consult with relevant personnel or teams to verify if the account creation was authorized or part of any legitimate administrative activities.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate system administrators often create user accounts as part of their daily responsibilities. These actions can trigger the detection rule, leading to false positives. To manage this, users can create exceptions for known administrator accounts or specific times when account creation is expected.
-- Automated account creation: Some organizations use scripts or automated processes to create user accounts in bulk, such as during onboarding. These activities can be mistaken for suspicious behavior. Users can exclude these processes by identifying and whitelisting the scripts or automation tools involved.
-- Software installations: Certain software installations may create service accounts or user accounts as part of their setup process. To handle these, users should document and exclude known software-related account creation events.
-- Testing environments: In testing or development environments, frequent account creation may occur as part of testing procedures. Users can exclude these environments from monitoring or create specific rules to differentiate between test and production systems.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Verify the legitimacy of the newly created user account by cross-referencing with authorized account creation requests and contacting the account requester if necessary.
-- If the account is unauthorized, disable or delete the account to prevent its use for persistence or privilege escalation.
-- Conduct a thorough investigation of the system and network logs to identify any additional unauthorized accounts or suspicious activities linked to the same threat actor.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Review and enhance logging policies to ensure comprehensive coverage of account creation events, including enabling detailed auditing for user account management.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying any necessary patches, updates, and security configurations to prevent exploitation of known vulnerabilities.
-- Implement hardening measures such as enforcing strong password policies, enabling multi-factor authentication, and restricting account creation privileges to minimize the risk of unauthorized account creation.
-- Conduct a post-incident review to identify gaps in the response process and update incident response plans and security policies accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_application_shimming.toml b/rules/windows/persistence_via_application_shimming.toml
index d7aa980b125..bd2dc22911a 100644
--- a/rules/windows/persistence_via_application_shimming.toml
+++ b/rules/windows/persistence_via_application_shimming.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,49 +53,6 @@ process where host.os.type == "windows" and event.type == "start" and process.na
   not (process.args : "-m" and process.args : "-bg") and
   not process.args : "-mm"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Application Shimming via Sdbinst
-
-Application shimming is a Windows feature designed to ensure software compatibility across different OS versions. However, attackers exploit this by using the sdbinst.exe tool to execute malicious code under the guise of legitimate processes, achieving persistence. The detection rule identifies suspicious sdbinst.exe executions by filtering out benign arguments, flagging potential misuse indicative of adversarial activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious `sdbinst.exe` execution, focusing on the `process.args` field to identify any unusual or unexpected arguments.
-- Check the process tree to understand the parent-child relationship of the `sdbinst.exe` process, identifying the parent process that initiated the execution.
-- Investigate the user account associated with the `sdbinst.exe` process to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Examine the timestamp of the `sdbinst.exe` execution to correlate with other suspicious activities or events on the host.
-- Utilize Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = 'sdbinst.exe';` to retrieve detailed information about the process execution.
-- Search for any recent file modifications or creations in directories commonly associated with application shimming, such as the AppCompat folder, to identify potential malicious SDB files.
-- Analyze the network activity of the host around the time of the `sdbinst.exe` execution to detect any unusual outbound connections or data exfiltration attempts.
-- Review system logs for any other indicators of compromise or related suspicious activities that occurred around the same time as the alert.
-- Investigate any other alerts or detections involving the same host or user account to identify patterns or a broader attack campaign.
-- Consult threat intelligence sources to determine if there are known campaigns or threat actors that commonly use application shimming techniques similar to those detected.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger sdbinst.exe with arguments that appear suspicious but are benign, such as custom software deployment scripts or enterprise software updates that use sdbinst.exe for compatibility reasons.
-- System administrators or IT personnel might use sdbinst.exe intentionally for legitimate application compatibility testing or deployment, which could be misidentified as malicious activity.
-- To manage these false positives, users can create exceptions for known and verified software installations by whitelisting specific command-line arguments or paths associated with trusted applications.
-- Regularly review and update the list of exceptions to ensure that only verified and necessary processes are excluded, minimizing the risk of overlooking genuine threats.
-- Implement logging and monitoring to track the frequency and context of sdbinst.exe executions, allowing for better differentiation between legitimate and potentially malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the sdbinst.exe process execution, including reviewing the command-line arguments and correlating with known malicious patterns.
-- Analyze the system for additional indicators of compromise (IOCs) related to application shimming and persistence mechanisms.
-- Terminate any suspicious processes associated with the malicious use of sdbinst.exe and remove any unauthorized application compatibility databases.
-- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Review and update security policies and procedures to include specific measures against application shimming and related persistence techniques.
-- Conduct a post-incident review to identify gaps in detection and response, and apply lessons learned to strengthen the overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_bits_job_notify_command.toml b/rules/windows/persistence_via_bits_job_notify_command.toml
index 23e91a5c868..42a345b965a 100644
--- a/rules/windows/persistence_via_bits_job_notify_command.toml
+++ b/rules/windows/persistence_via_bits_job_notify_command.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 
 [rule]
 author = ["Elastic"]
@@ -40,52 +40,6 @@ process where host.os.type == "windows" and event.type == "start" and
                "?:\\Windows\\System32\\wermgr.exe",
                "?:\\WINDOWS\\system32\\directxdatabaseupdater.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via BITS Job Notify Cmdline
-
-The Background Intelligent Transfer Service (BITS) is a Windows component that facilitates asynchronous, prioritized, and throttled transfer of files between machines. Adversaries exploit BITS by using the SetNotifyCmdLine method to execute malicious programs post-transfer, achieving persistence. The detection rule identifies suspicious processes initiated by BITS, excluding legitimate executables, to flag potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process was initiated by `svchost.exe` with arguments containing "BITS" and verify the process executable is not among the known legitimate ones listed in the detection rule.
-- Gather additional context by identifying the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Check the process creation time and correlate it with any known scheduled tasks or user activity to identify if the execution was expected or anomalous.
-- Investigate the command line arguments of the suspicious process to understand its intended function and assess if it aligns with typical BITS job activities.
-- Use Osquery to list all BITS jobs on the system and their associated notify command lines to identify any other potentially malicious jobs:
-  ```sql
-  SELECT job_id, notify_cmd_path, notify_cmd_arguments FROM bits_jobs;
-  ```
-- Examine the network connections established by the suspicious process to identify any unusual or unauthorized external communications.
-- Review the system's event logs around the time of the process execution for any additional indicators of compromise or related activities.
-- Investigate the parent process `svchost.exe` to ensure it is legitimate and not a masqueraded or compromised instance.
-- Check for any recent changes to the system's BITS configuration or related registry keys that could indicate tampering or persistence mechanisms.
-- Cross-reference the findings with threat intelligence sources to determine if the observed behavior matches any known threat actor techniques or campaigns.
-
-### False positive analysis
-
-- Legitimate software updates or system maintenance tasks may trigger the BITS Job Notify Cmdline rule, as some applications use BITS for downloading updates or patches, leading to false positives.
-- System administrators might use BITS for deploying software or updates across a network, which could be flagged by the rule if the executables are not in the exclusion list.
-- To manage these false positives, users can create exceptions for known legitimate processes that frequently trigger the rule by adding them to the exclusion list in the detection query.
-- Regularly review and update the exclusion list to include new legitimate processes that are identified as false positives, ensuring that the detection rule remains effective without generating unnecessary alerts.
-- Collaborate with IT and security teams to identify and document legitimate use cases of BITS within the organization, which can then be used to refine the detection rule and minimize false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on processes initiated by BITS and any associated files or network connections.
-- Terminate any suspicious processes that were initiated by BITS and remove any malicious files identified during the investigation.
-- Review and analyze the BITS job configurations to identify any unauthorized or suspicious jobs and remove them.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process creation events, including command-line arguments, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
-- Educate users and administrators about the risks associated with BITS abuse and provide training on recognizing and reporting suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_hidden_run_key_valuename.toml b/rules/windows/persistence_via_hidden_run_key_valuename.toml
index 5992490ebfa..88ed115ee77 100644
--- a/rules/windows/persistence_via_hidden_run_key_valuename.toml
+++ b/rules/windows/persistence_via_hidden_run_key_valuename.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,49 +62,6 @@ registry where host.os.type == "windows" and event.type == "change" and length(r
                   "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\",
                   "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via Hidden Run Key Detected
-
-Windows systems use registry keys to manage startup programs, a feature adversaries exploit to maintain persistence. By leveraging the NtSetValueKey API, attackers can create hidden registry entries that evade standard tools like regedit. The detection rule identifies changes in specific registry paths, focusing on entries with null-terminated keys, signaling potential stealthy persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path and key that triggered the detection, focusing on paths ending with a backslash as indicated in the query.
-- Verify the host information from the alert to determine the affected system and gather additional context about its role and importance within the network.
-- Use a tool like Osquery to list all registry keys under the specified path to identify any null-terminated keys. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_USERS\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE 'HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE 'HKLM\\\\Software\\\\WOW6432Node\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE 'HKEY_USERS\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE 'HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\USER\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\WOW6432Node\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\USER\\\\%\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%' OR path LIKE '\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\Explorer\\\\Run\\\\%'`.
-- Check the timestamp of the registry change event to correlate it with other system activities or logs, such as user logins or software installations, to identify potential sources or related events.
-- Investigate the process that made the registry change by reviewing process creation logs or using endpoint detection and response (EDR) tools to trace the process lineage and command-line arguments.
-- Examine the registry key value data to determine if it points to a legitimate application or a suspicious executable, and verify the file's existence and properties on the disk.
-- Cross-reference the registry key value data with known good baselines or threat intelligence sources to identify any known malicious indicators or patterns.
-- Analyze network logs or traffic from the affected host around the time of the registry change to detect any unusual outbound connections or data exfiltration attempts.
-- Review user activity logs to determine if the registry change was made by a legitimate user or if there are signs of compromised credentials or unauthorized access.
-- Document all findings and evidence collected during the investigation to support further analysis or potential escalation to incident response teams.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify registry keys in the specified paths, leading to false positives. Users should verify if the changes coincide with known software activities.
-- System administrators may use scripts or management tools that alter registry keys for configuration purposes. These should be documented and excluded from alerts if verified as non-malicious.
-- Some security software may create or modify registry entries in these paths as part of their normal operation. Users should identify these applications and create exceptions for them.
-- Group Policy Objects (GPOs) applied in enterprise environments might result in registry changes that trigger the detection rule. Administrators should review GPO settings and exclude expected changes.
-- Users can handle false positives by creating exceptions for specific registry paths or values that are known to be safe, ensuring these exceptions are regularly reviewed and updated as necessary.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Use a trusted tool to inspect the registry paths identified in the alert for any suspicious or unauthorized entries.
-- Remove any unauthorized or suspicious registry entries found in the specified paths to eliminate persistence mechanisms.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any associated malware.
-- Review recent system changes and user activity logs to identify how the persistence mechanism was introduced and assess the scope of the compromise.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
-- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
-- Apply hardening measures such as restricting registry editing permissions, enforcing least privilege principles, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
index aaca3df5a6f..7a3c8569eb7 100644
--- a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
+++ b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,48 +47,6 @@ registry where host.os.type == "windows" and event.type == "change" and
    ) and
    not process.executable : ("C:\\Windows\\System32\\msiexec.exe", "C:\\Windows\\SysWOW64\\msiexec.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Installation of Security Support Provider
-
-Security Support Providers (SSPs) in Windows are crucial for handling authentication requests. They are configured via specific registry paths. Adversaries may exploit SSPs to gain persistence by modifying these registry entries to load malicious code at system startup. The detection rule identifies unauthorized changes to these registry paths, excluding legitimate processes, to flag potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path that was modified, focusing on paths related to "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\Security Packages*" and "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\OSConfig\\\\Security Packages*".
-- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other events in the system logs around the same time.
-- Investigate the process that made the registry change by examining the process ID and executable path, ensuring it is not one of the excluded legitimate processes like "C:\\\\Windows\\\\System32\\\\msiexec.exe".
-- Use Osquery to list all current entries in the Security Packages registry key to identify any unfamiliar or suspicious entries. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%\\\\Control\\\\Lsa\\\\Security Packages';`
-- Cross-reference the process that made the change with known malicious processes or hash values using threat intelligence sources.
-- Analyze the user account context under which the registry change was made to determine if it was performed by an unauthorized or compromised account.
-- Review recent login events and user activity for the account associated with the registry change to identify any anomalies or unauthorized access.
-- Check for any recent software installations or updates that might have legitimately modified the Security Support Provider configuration.
-- Investigate network activity from the host around the time of the registry change for any signs of data exfiltration or communication with known malicious IP addresses.
-- Examine other systems in the network for similar registry changes to assess if this is an isolated incident or part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger registry changes in the Security Support Provider paths, particularly when using installers like msiexec.exe. These are typically benign and can be excluded from alerts.
-- System administrators or security tools may intentionally modify SSP registry entries as part of routine maintenance or security hardening, which could be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for known and trusted processes or executables that frequently modify these registry paths, ensuring they are not flagged by the detection rule.
-- Regularly review and update the list of excluded processes to reflect changes in the environment, such as new software deployments or updates to existing applications, to maintain an accurate and effective detection strategy.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or spread of malicious code.
-- Review the registry changes to confirm unauthorized modifications and identify any malicious SSPs that have been added.
-- Terminate any suspicious processes associated with the unauthorized registry changes to halt potential malicious activity.
-- Restore the registry entries to their original state using a known good backup or by manually removing the unauthorized entries.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
-- Review system and security logs to trace the source of the unauthorized changes and identify any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and response.
-- Implement enhanced logging policies to capture detailed information on registry changes and process executions for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Apply security hardening measures, such as restricting registry access permissions and implementing application whitelisting, to prevent similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
index 7bbe784167b..93aef1c28b4 100644
--- a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
+++ b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,49 +58,6 @@ process where host.os.type == "windows" and event.type == "start" and
                       "rundll32.exe",
                       "powershell.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via TelemetryController Scheduled Task Hijack
-
-The Microsoft Compatibility Appraiser, part of Windows telemetry, uses scheduled tasks to assess system compatibility. Adversaries may hijack these tasks to gain persistent, high-integrity access by executing unauthorized processes. The detection rule identifies anomalies by monitoring process executions initiated by the telemetry task, excluding known legitimate processes, to flag potential hijacks.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments that triggered the detection, focusing on the `process.parent.name` and `process.args` fields.
-- Verify the legitimacy of the process by checking the process hash against known good hashes or threat intelligence databases.
-- Investigate the parent process `CompatTelRunner.exe` to determine if it has been tampered with or replaced by a malicious version.
-- Examine the command line arguments (`process.args`) used by the suspicious process to understand its intended actions and potential impact.
-- Use Osquery to list all scheduled tasks on the system and identify any modifications or unusual entries related to the Microsoft Compatibility Appraiser. Example query: `SELECT * FROM scheduled_tasks WHERE name LIKE '%CompatTelRunner%';`
-- Check the system's event logs for any recent changes to scheduled tasks, especially those involving `CompatTelRunner.exe`, to identify potential unauthorized modifications.
-- Analyze the timeline of events leading up to the alert to identify any preceding suspicious activities or related alerts that might indicate a broader attack campaign.
-- Investigate the user account context under which the suspicious process was executed to determine if it has been compromised or misused.
-- Review network connections initiated by the suspicious process to identify any unusual or unauthorized external communications.
-- Correlate the findings with other security tools and logs, such as endpoint detection and response (EDR) solutions, to gather additional context and confirm the scope of the potential compromise.
-
-### False positive analysis
-
-- Known false positives may include legitimate processes that are not part of the predefined exclusion list but are still initiated by the Microsoft Compatibility Appraiser task. These could be custom scripts or applications that organizations have integrated into their system maintenance routines.
-- Users can handle these false positives by reviewing the flagged processes to determine if they are part of legitimate operations. If confirmed as non-threatening, these processes can be added to the exclusion list to prevent future alerts.
-- Another potential false positive scenario involves system administrators using custom tools or scripts that mimic the behavior of excluded processes for maintenance or monitoring purposes. These should be documented and excluded accordingly.
-- Regularly updating the exclusion list to reflect changes in legitimate system processes or newly introduced applications can help minimize false positives.
-- It is important to maintain a balance between security and operational efficiency by ensuring that only verified non-threatening processes are excluded, thus maintaining the integrity of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the hijack by reviewing the process execution logs and identifying any unauthorized processes initiated by the telemetry task.
-- Terminate any malicious processes identified during the investigation to halt any ongoing unauthorized activities.
-- Restore the scheduled task to its original state by reconfiguring it to execute only legitimate processes, ensuring the integrity of the Microsoft Compatibility Appraiser.
-- Perform a comprehensive scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats or malware.
-- Review and update the system's scheduled tasks and permissions to ensure only authorized users and processes can modify them.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed telemetry task execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate similar events across the network.
-- Apply system hardening measures, such as disabling unnecessary services and applying the principle of least privilege, to reduce the attack surface and prevent future hijacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
index d707ae79add..c174b2eed5e 100644
--- a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
+++ b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,49 +55,6 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "create" and
   process.args : ("ActiveScriptEventConsumer", "CommandLineEventConsumer")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Persistence via WMI Event Subscription
-
-Windows Management Instrumentation (WMI) allows for system management and monitoring through event subscriptions, which can be exploited by adversaries to maintain persistence. By creating event filters and consumers, attackers can execute code in response to system events. The detection rule identifies suspicious use of `wmic.exe` to create event consumers, signaling potential abuse for persistence.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `wmic.exe` in the process name or `process.pe.original_file_name` fields, indicating the use of Windows Management Instrumentation Command-line.
-- Examine the `process.args` field to verify the presence of "create" along with "ActiveScriptEventConsumer" or "CommandLineEventConsumer", which suggests the creation of event consumers.
-- Check the `event.type` field to ensure it is marked as "start", indicating the initiation of a process that could be related to persistence mechanisms.
-- Investigate the parent process of `wmic.exe` to determine if it was spawned by a legitimate or suspicious process, which could provide context on how the execution was initiated.
-- Use Osquery to list all WMI event consumers on the system with a query like: `SELECT * FROM wmi_event_consumers;` to identify any suspicious or unauthorized consumers.
-- Cross-reference the timestamp of the alert with other logs or events on the system to identify any correlated activities or anomalies around the same time.
-- Analyze the user account context under which `wmic.exe` was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Review system logs for any additional WMI-related activities or errors that could provide further insight into the persistence mechanism being established.
-- Investigate any network connections or external communications initiated by `wmic.exe` or its parent process to identify potential command and control activities.
-- Check for any recent changes in system configurations or scheduled tasks that might have been altered to facilitate persistence through WMI event subscriptions.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators may use `wmic.exe` to create event consumers for legitimate monitoring and automation purposes. These activities can trigger the detection rule but are not malicious.
-- Software installations and updates: Some software installations or updates might use WMI event subscriptions as part of their setup or configuration processes, leading to false positives.
-- Monitoring and management tools: Certain IT management tools may utilize WMI event subscriptions to monitor system events, which can be mistaken for malicious activity.
-- To manage false positives, users can create exceptions for known legitimate processes or activities by whitelisting specific command lines or process hashes associated with trusted software and administrative tasks.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on WMI event subscriptions and any associated scripts or commands.
-- Terminate any malicious processes identified, particularly those related to `wmic.exe` and suspicious event consumers.
-- Remove unauthorized WMI event subscriptions by using tools like `wevtutil` or PowerShell to list and delete suspicious filters and consumers.
-- Restore the system to a known good state using backups or system restore points, ensuring that all malicious changes are reverted.
-- Implement enhanced logging policies to monitor WMI activity, including event subscription creation and execution, to detect future abuse.
-- Integrate security solutions with SIEM systems to correlate WMI activity with other security events for comprehensive threat detection.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Review and update security policies and procedures to include regular audits of WMI configurations and event subscriptions.
-- Apply system hardening measures, such as restricting WMI access to authorized users and implementing application whitelisting to prevent unauthorized execution of `wmic.exe`."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_werfault_reflectdebugger.toml b/rules/windows/persistence_werfault_reflectdebugger.toml
index 311aeb5ec2d..b798b066051 100644
--- a/rules/windows/persistence_werfault_reflectdebugger.toml
+++ b/rules/windows/persistence_werfault_reflectdebugger.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,48 +43,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Werfault ReflectDebugger Persistence
-
-Werfault, the Windows Error Reporting service, aids in diagnosing application crashes. Attackers can exploit its ReflectDebugger registry key to persistently execute malicious code by configuring it to trigger on error reports. The detection rule monitors changes to specific registry paths, identifying unauthorized modifications that suggest adversaries are setting up persistence mechanisms through this method.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path involved matches one of the specified paths in the detection rule: "HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\Hangs\\\\ReflectDebugger", "\\\\REGISTRY\\\\MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\Hangs\\\\ReflectDebugger", or "MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\Hangs\\\\ReflectDebugger".
-- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other events or activities on the system around the same time.
-- Identify the user account or process that made the registry change by examining the event logs for user or process information associated with the change event.
-- Investigate the system for any recent application crashes or error reports that could have triggered the Werfault service, potentially executing the malicious payload.
-- Use Osquery to list all current registry keys under the Windows Error Reporting path to identify any other suspicious entries: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\Software\\\\Microsoft\\\\Windows\\\\Windows Error Reporting\\\\%';`
-- Examine the system for any unusual or unauthorized processes running, especially those that may have been initiated around the time of the registry change.
-- Review network logs for any suspicious outbound connections from the host that could indicate data exfiltration or command and control activity.
-- Check for any recent software installations or updates that could have introduced the registry change, focusing on software that interacts with error reporting or debugging.
-- Analyze the system for any additional persistence mechanisms that may have been established, such as scheduled tasks or startup items, which could indicate a broader compromise.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, providing additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify the ReflectDebugger registry key as part of their error reporting configuration, leading to false positives. Users should verify the source of the change and consider excluding known trusted software from triggering alerts.
-- System administrators or IT management tools might intentionally configure the ReflectDebugger key for monitoring or debugging purposes. In such cases, document these changes and create exceptions for these specific registry modifications to prevent unnecessary alerts.
-- Some security or diagnostic tools may interact with the ReflectDebugger registry key as part of their normal operation. Users should identify these tools and whitelist their activities to avoid false positives.
-- Regular audits of registry changes by authorized personnel might trigger alerts. Ensure that these activities are logged and recognized as non-threatening, and adjust the detection rule to exclude these known activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm unauthorized modifications to the ReflectDebugger registry key and identify any associated malicious payloads.
-- Review recent system and application logs to trace the origin of the unauthorized changes and gather additional context on the attack vector.
-- Remove or revert any unauthorized changes to the ReflectDebugger registry key to eliminate the persistence mechanism.
-- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to monitor registry changes and other critical system activities for early detection of similar threats in the future.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
-- Restore the system to its operational state by applying verified clean backups and ensuring all security patches and updates are installed.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_create_process_as_different_user.toml b/rules/windows/privilege_escalation_create_process_as_different_user.toml
index 327451454a3..ffaaf3a68b9 100644
--- a/rules/windows/privilege_escalation_create_process_as_different_user.toml
+++ b/rules/windows/privilege_escalation_create_process_as_different_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,49 +46,6 @@ sequence by winlog.computer_name with maxspan=1m
 
 [process where event.type == "start"] by winlog.event_data.TargetLogonId
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Creation via Secondary Logon
-
-The Secondary Logon service allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process initiations, linking them through unique logon identifiers.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, focusing on the `winlog.computer_name` and `winlog.event_data.TargetLogonId` to identify the affected system and session.
-- Verify the `user.id` involved in the event to determine if the account is known and if it has legitimate reasons to use the Secondary Logon service.
-- Check the `source.ip` field to confirm if the login originated from a local source (`::1`) and assess if this is expected behavior for the user or system.
-- Investigate the `process.name` to ensure it is indeed `svchost.exe` and not a masquerading process, which could indicate malicious activity.
-- Correlate the `winlog.event_data.LogonProcessName` with "seclogo*" to confirm the use of the Secondary Logon service.
-- Use Osquery to list all processes started by the identified `winlog.event_data.TargetLogonId` to gather more context on what actions were taken post-login. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>');`
-- Examine the timeline of events around the alert to identify any unusual patterns or sequences of actions that deviate from normal user behavior.
-- Cross-reference the `event.action` and `event.outcome` fields with other authentication logs to identify any anomalies or repeated patterns of successful logins using alternate credentials.
-- Investigate any other security alerts or logs related to the same `winlog.computer_name` or `user.id` to determine if this event is part of a larger attack pattern.
-- Consult with the user or system owner to verify if the use of the Secondary Logon service was authorized and necessary, and gather any additional context that may explain the activity.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often use the Secondary Logon service to perform tasks requiring elevated privileges, which can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific tasks that are regularly performed.
-- Scheduled tasks and maintenance scripts: Automated scripts or scheduled tasks that require elevated privileges might also use the Secondary Logon service. Users can handle these by identifying and excluding specific scripts or task names that are part of routine maintenance.
-- Software updates and installations: Some software updates or installations may use alternate credentials to execute necessary processes. Users should monitor and whitelist known update processes or installation packages to prevent false positives.
-- Internal security tools: Certain security tools may use the Secondary Logon service for legitimate monitoring or scanning activities. Users can exclude these tools by identifying their process names or associated logon identifiers.
-- Testing and development environments: In environments where frequent testing or development occurs, processes may be created with alternate credentials for testing purposes. Users can manage these by excluding specific environments or user accounts associated with development activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Verify the legitimacy of the user account involved in the alert by checking recent activity and cross-referencing with known user behavior.
-- Investigate the process tree associated with the suspicious process creation to identify any malicious or unauthorized processes.
-- Terminate any malicious processes identified during the investigation to prevent further execution of unauthorized actions.
-- Reset the credentials of the compromised user account and any other accounts that may have been affected.
-- Conduct a thorough review of system and security logs to identify any additional indicators of compromise or related suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader compromise or if assistance is needed.
-- Implement enhanced logging policies to capture detailed authentication and process creation events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access controls, to reduce the attack surface and prevent future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
index efc451df324..ffd8fd02012 100644
--- a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
+++ b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,49 +58,6 @@ process where host.os.type == "windows" and event.action == "start" and
  not (process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe" and 
       process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\msiexec.exe", "?:\\Windows\\twain_32\\*.exe"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Created with a Duplicated Token
-
-In Windows environments, tokens are used to represent user credentials and permissions. Adversaries may duplicate tokens to create processes with elevated privileges, bypassing security controls. The detection rule identifies suspicious process creation by examining token impersonation patterns, process origins, and anomalies in executable paths, helping to uncover potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process was created and the associated user ID, focusing on the `process.name` and `user.id` fields.
-- Examine the `process.Ext.effective_parent.executable` field to determine the origin of the parent process and assess if it is a known legitimate source or potentially malicious.
-- Check the `process.command_line` for any suspicious or unexpected command-line arguments that could indicate malicious intent.
-- Investigate the `process.Ext.relative_file_creation_time` and `process.Ext.relative_file_name_modify_time` to identify if the process was recently created or modified, which could suggest tampering.
-- Verify the `process.code_signature.status` to determine if the executable is signed and trusted, which can help differentiate between legitimate and potentially malicious processes.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following query to list processes with their parent details: `SELECT pid, name, path, parent, uid FROM processes WHERE name = '<suspicious_process_name>';`
-- Cross-reference the `process.parent.name` and `process.Ext.effective_parent.name` fields to identify any discrepancies or unusual parent-child relationships that could indicate token manipulation.
-- Analyze the `process.parent.executable` to ensure it aligns with expected behavior for the parent process, checking for any anomalies or unexpected paths.
-- Review historical data for the `user.id` to identify any patterns of unusual activity or previous alerts that could suggest a compromised account.
-- Correlate the alert with other security events or logs from the same timeframe to build a comprehensive timeline of activities and identify any additional indicators of compromise.
-
-### False positive analysis
-
-- Legitimate administrative tools: Processes like "powershell.exe" or "cmd.exe" may be flagged when used by IT administrators for routine tasks. Users can create exceptions for these processes when executed by known administrative accounts.
-- Software updates and installations: During software updates or installations, processes such as "msiexec.exe" or "svchost.exe" might trigger alerts. Users can exclude these processes when they originate from trusted software update paths.
-- System maintenance tasks: Scheduled tasks or system maintenance activities might involve processes like "tasklist.exe" or "reg.exe". Users should monitor the context and frequency of these tasks and consider excluding them if they align with regular maintenance schedules.
-- Custom scripts and automation: Organizations using custom scripts for automation might see false positives with processes like "rundll32.exe" or "bitsadmin.exe". Users can whitelist these scripts by verifying their source and ensuring they are signed or located in trusted directories.
-- Third-party security tools: Some security tools may mimic adversarial behavior for testing purposes, triggering false positives. Users should identify these tools and exclude their processes from detection rules, ensuring they are from a trusted vendor.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the token duplication, examining logs and correlating events to determine the adversary's entry point and actions.
-- Terminate any suspicious processes identified as running with duplicated tokens to halt any ongoing malicious activity.
-- Review and analyze user account activity to identify any unauthorized access or privilege escalation attempts, focusing on accounts associated with the duplicated tokens.
-- Reset passwords for compromised accounts and enforce multi-factor authentication to enhance account security.
-- Restore the system to a known good state using backups, ensuring that the backup is free from any compromise.
-- Implement enhanced logging policies to capture detailed process creation and token usage events, aiding in future detection and investigation efforts.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to provide real-time monitoring and automated response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate users and administrators on the risks of token manipulation and privilege escalation, emphasizing the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_credroaming_ldap.toml b/rules/windows/privilege_escalation_credroaming_ldap.toml
index 49fee5b8584..2595cb73e58 100644
--- a/rules/windows/privilege_escalation_credroaming_ldap.toml
+++ b/rules/windows/privilege_escalation_credroaming_ldap.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,49 +60,6 @@ event.action:("Directory Service Changes" or "directory-service-object-modified"
   winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and winlog.event_data.OperationType:"%%14674" and
   not winlog.event_data.SubjectUserSid : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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. Attackers may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service change events, focusing on unauthorized user actions, thus helping to thwart privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of event code "5136" and ensure the modification pertains to the "msPKIAccountCredentials" attribute.
-- Verify the "event.action" field to determine if the action was logged as "Directory Service Changes" or "directory-service-object-modified" to confirm the type of change.
-- Check the "winlog.event_data.SubjectUserSid" field to identify the user who initiated the change and ensure it is not the system account "S-1-5-18".
-- Investigate the "winlog.event_data.OperationType" field for the value "%%14674" to understand the nature of the operation performed on the attribute.
-- Correlate the timestamp of the event with other logs to identify any concurrent suspicious activities or anomalies in the network.
-- Use Osquery to gather additional context on the affected system. For example, run the following query to list recent changes to Active Directory objects: `SELECT * FROM ad_config WHERE attribute = 'msPKIAccountCredentials' AND action = 'MODIFY';`
-- Examine the history of changes to the "msPKIAccountCredentials" attribute for the affected user object to identify any patterns or repeated unauthorized modifications.
-- Cross-reference the user account involved with known threat intelligence sources to check for any history of malicious activity or compromise.
-- Analyze network traffic logs around the time of the event to detect any unusual outbound connections or data exfiltration attempts.
-- Consult with the Active Directory team to verify if the change was part of any legitimate administrative activity or if it was unauthorized.
-
-### False positive analysis
-
-- Routine administrative tasks: Regular updates or maintenance activities by authorized IT personnel may trigger the rule. To manage this, create exceptions for known administrative accounts or specific maintenance windows.
-- Automated system processes: Scheduled tasks or automated scripts that interact with Active Directory objects might modify the msPKIAccountCredentials attribute. Identify these processes and exclude them from the rule to prevent unnecessary alerts.
-- Software updates: Certain software updates or installations may require modifications to credential attributes. Monitor and document these updates, and consider excluding them if they are verified as non-threatening.
-- Legitimate credential management: Tools or services that manage user credentials, such as password managers or enterprise credential management systems, may cause changes to the attribute. Verify these tools and exclude their actions if they are deemed safe.
-- User account migrations: During user account migrations or domain consolidations, the msPKIAccountCredentials attribute might be modified. Recognize these events and exclude them from the rule to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the modification, including reviewing logs for any unauthorized access or changes to the msPKIAccountCredentials attribute.
-- Verify the integrity of the affected Active Directory objects and restore them from a known good backup if necessary.
-- Reset passwords and revoke any potentially compromised certificates or keys associated with the affected accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring for Active Directory changes, focusing on sensitive attributes like msPKIAccountCredentials, to detect future unauthorized modifications.
-- Integrate security information and event management (SIEM) solutions to correlate events and provide real-time alerts for suspicious activities related to privilege escalation attempts.
-- Review and update access controls and permissions for Active Directory objects to ensure the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement necessary improvements to prevent similar incidents.
-- Educate and train IT staff and users on recognizing and reporting suspicious activities, emphasizing the importance of maintaining secure credentials and adhering to security policies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
index fafd16ce93b..a6e2874c53a 100644
--- a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
+++ b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,50 +43,6 @@ any where host.os.type == "windows" and event.category : ("library", "process")
   not ?dll.code_signature.trusted == true and
   not file.code_signature.status == "Valid"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unsigned DLL loaded by DNS Service
-
-The DNS service on Windows systems is crucial for resolving domain names to IP addresses. It uses DLLs to extend its functionality. Adversaries may exploit this by loading malicious, unsigned DLLs into the DNS service, potentially gaining elevated privileges and executing arbitrary code. The detection rule identifies such threats by monitoring for DLLs loaded by the DNS process that lack valid signatures, indicating possible tampering or unauthorized modifications.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process executable is "?:\\\\windows\\\\system32\\\\dns.exe" and verify the DLL in question is indeed unsigned.
-- Check the event logs for any recent changes or unusual activity around the time the unsigned DLL was loaded, focusing on event categories "library" and "process" with event types "start" and "change".
-- Investigate the file path and name of the unsigned DLL to determine if it is known or expected within the environment.
-- Use Osquery to list all DLLs currently loaded by the DNS service with the following query: `SELECT path, name, pid FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE path LIKE '%dns.exe%';`
-- Examine the file metadata of the unsigned DLL, including creation and modification timestamps, to identify any anomalies or recent changes.
-- Cross-reference the unsigned DLL's hash against threat intelligence databases to check for known malicious signatures.
-- Analyze the parent process and any associated child processes of the DNS service to identify potential lateral movement or further exploitation attempts.
-- Review user and system activity logs around the time of the DLL load event to identify any suspicious behavior or unauthorized access attempts.
-- Investigate network connections initiated by the DNS service to detect any unusual or unauthorized external communications.
-- Consult with the system owner or administrator to verify if the unsigned DLL is part of a legitimate application or recent update that may not yet be signed.
-
-### False positive analysis
-
-- Some legitimate software may load unsigned DLLs into the DNS service for valid reasons, such as custom network management tools or legacy applications that do not have signed components. 
-- Security software or monitoring tools might inject unsigned DLLs for tracking or analysis purposes, which could be mistaken for malicious activity.
-- In environments with custom or in-house developed applications, these applications might not have signed DLLs, leading to false positives when they interact with the DNS service.
-- To manage these false positives, users can create exceptions for known and trusted applications by whitelisting their DLLs or processes in the security monitoring tool.
-- Regularly update the list of trusted software and their components to ensure that legitimate updates or changes do not trigger false alerts.
-- Collaborate with IT and security teams to maintain an inventory of authorized software and their expected behaviors, which can help in quickly identifying and excluding benign activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the unsigned DLLs loaded by the DNS service.
-- Verify the integrity of the DNS service and its associated files by comparing them against known good versions or using a trusted source.
-- Remove any unauthorized or malicious DLLs identified during the investigation and replace them with legitimate versions.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed information on DLL loads and process activities, ensuring future incidents can be detected more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and conducting a full system scan to ensure no residual threats remain.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and ensuring all software is up-to-date.
-- Review and update security policies and procedures to incorporate lessons learned from the incident, enhancing the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_expired_driver_loaded.toml b/rules/windows/privilege_escalation_expired_driver_loaded.toml
index fe544837b92..5026c5b0606 100644
--- a/rules/windows/privilege_escalation_expired_driver_loaded.toml
+++ b/rules/windows/privilege_escalation_expired_driver_loaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,49 +36,6 @@ query = '''
 driver where host.os.type == "windows" and process.pid == 4 and
   dll.code_signature.status : ("errorExpired", "errorRevoked")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Expired or Revoked Driver Loaded
-
-In Windows environments, drivers facilitate communication between the OS and hardware. Adversaries exploit vulnerabilities in outdated drivers or misuse revoked certificates to execute malicious code in kernel mode, gaining elevated privileges. The detection rule identifies such threats by monitoring for drivers with expired or revoked signatures, specifically targeting processes with system-level access.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a driver with an expired or revoked signature, focusing on the `dll.code_signature.status` field for values "errorExpired" or "errorRevoked".
-- Verify the process ID (`process.pid`) to ensure it matches the system process (PID 4), which indicates a driver loaded at the system level.
-- Identify the specific driver file involved by examining the associated file path and name, if available, in the alert details.
-- Check the driver file's digital signature details to confirm its expiration or revocation status using tools like Sigcheck.
-- Investigate the driver file's origin and history by checking its creation and modification timestamps to determine if it was recently introduced to the system.
-- Use Osquery to gather additional context about the driver file. Example query: `SELECT * FROM kernel_modules WHERE name = '<driver_name>';` to retrieve details about the loaded driver.
-- Cross-reference the driver file's hash against known malware databases or threat intelligence sources to identify any known malicious activity associated with it.
-- Examine system logs and security events around the time the driver was loaded to identify any suspicious activities or related alerts.
-- Investigate any recent changes or updates to the system that might have introduced the driver, such as software installations or updates.
-- Collaborate with other security teams or stakeholders to gather additional context or insights about the driver and its potential impact on the system.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they involve drivers with expired or revoked signatures, especially if the vendor has not updated their certificates promptly.
-- Some older hardware devices may rely on drivers that are no longer supported or updated, leading to false positives when these drivers are loaded.
-- Security or system management tools that interact with kernel mode might use drivers with expired signatures for legitimate purposes, causing alerts.
-- To manage these false positives, users can create exceptions for specific drivers or processes known to be safe by adding them to an allowlist within the monitoring system.
-- Regularly review and update the list of exceptions to ensure that only verified non-threatening drivers are excluded, maintaining a balance between security and operational needs.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Verify the legitimacy of the driver by checking its source and intended use; remove any unauthorized or malicious drivers.
-- Conduct a thorough investigation to identify how the expired or revoked driver was loaded, focusing on potential vulnerabilities or misconfigurations.
-- Utilize endpoint detection and response (EDR) tools to scan for additional signs of compromise or related malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and containment measures.
-- Apply patches or updates to the operating system and all drivers to mitigate known vulnerabilities.
-- Implement strict driver signing policies and enforce the use of only trusted and verified drivers.
-- Enhance logging and monitoring to capture detailed information on driver loads and process activities, integrating with SIEM solutions for real-time alerts.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on the risks associated with outdated or unauthorized drivers and the importance of maintaining up-to-date systems."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_exploit_cve_202238028.toml b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
index 3a7d532fb8c..3d234029f7e 100644
--- a/rules/windows/privilege_escalation_exploit_cve_202238028.toml
+++ b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,48 +43,6 @@ file where host.os.type == "windows" and event.type != "deletion" and
         "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js"
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential privilege escalation via CVE-2022-38028
-
-CVE-2022-38028 targets the Windows Print Spooler service, a core component managing print jobs. Adversaries exploit this by manipulating specific JavaScript files within system directories to gain elevated privileges. The detection rule identifies unauthorized modifications to these files, signaling potential exploitation attempts, thus enabling timely intervention.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file name and path match those specified in the detection query: "MPDW-constraints.js" within the specified system directories.
-- Verify the event type to ensure it is not a deletion event, as the query excludes such events.
-- Check the file modification timestamps to determine when the unauthorized changes occurred and correlate with any known user activity or scheduled tasks.
-- Investigate the user account associated with the file modification event to assess if it has the necessary permissions and if the activity aligns with their typical behavior.
-- Use Osquery to gather additional context on the file by running a query such as: `SELECT * FROM file WHERE path LIKE 'C:\\\\Windows\\\\system32\\\\DriVerStoRe\\\\FiLeRePoSiToRy\\\\%\\\\MPDW-constraints.js' OR path LIKE 'C:\\\\Windows\\\\WinSxS\\\\amd64_microsoft-windows-printing-printtopdf_%\\\\MPDW-constraints.js';` to verify file attributes and metadata.
-- Examine recent system logs for any unusual or suspicious activities around the time of the file modification, focusing on print spooler service logs and security logs.
-- Cross-reference the event with any other alerts or incidents involving the same host to identify potential patterns or related activities.
-- Investigate any network connections or external communications from the host around the time of the event to detect possible data exfiltration or command and control activities.
-- Check for any recent software installations or updates on the host that might have inadvertently or maliciously modified the file.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors currently exploiting CVE-2022-38028, which could provide additional context or indicators of compromise.
-
-### False positive analysis
-
-- Routine system updates or legitimate software installations may modify the `MPDW-constraints.js` file, triggering the detection rule. Users should verify if these changes coincide with scheduled updates or trusted software installations.
-- Security software or system maintenance tools might access or modify the `MPDW-constraints.js` file as part of their normal operations. Users can create exceptions for these known tools to prevent false alerts.
-- Custom scripts or administrative tasks that interact with the print spooler service or related files could inadvertently trigger the rule. Users should document and exclude these scripts if they are verified as non-threatening.
-- To manage false positives, users can implement a whitelist of known, legitimate processes or applications that are allowed to modify the `MPDW-constraints.js` file, ensuring that only unauthorized changes are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to confirm unauthorized modifications to the specified JavaScript files and identify any other compromised files or services.
-- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) related to CVE-2022-38028.
-- Revert any unauthorized changes to the JavaScript files by restoring them from a known good backup or reinstalling the affected components.
-- Apply the latest security patches and updates from Microsoft to address CVE-2022-38028 and other known vulnerabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging and monitoring policies to capture detailed file access and modification events, focusing on critical system directories.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Strengthen system hardening measures by disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
index 68c4e946e9f..1b27f5b2e7c 100644
--- a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
+++ b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,48 +45,6 @@ file where host.os.type == "windows" and event.type != "deletion" and event.acti
   ) and
   not process.executable : "C:\\Windows\\System32\\dfsrs.exe"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation or Modification of a new GPO Scheduled Task or Service
-
-Group Policy Objects (GPOs) are crucial for centralized management in Windows environments, allowing administrators to configure settings across domain-joined machines. Adversaries with domain admin rights can exploit GPOs to deploy malicious tasks or services, executing harmful payloads network-wide. The detection rule identifies suspicious changes to specific XML files associated with GPO tasks and services, excluding legitimate system processes, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific XML file involved, either "ScheduledTasks.xml" or "Services.xml", and note the file path to determine which GPO was modified.
-- Verify the timestamp of the event to establish when the modification occurred and correlate it with any known changes or maintenance activities.
-- Identify the user account associated with the modification event to determine if it was performed by a legitimate administrator or a potentially compromised account.
-- Check the process executable that triggered the event, ensuring it is not "C:\\\\Windows\\\\System32\\\\dfsrs.exe", which is excluded as a legitimate process.
-- Use Active Directory logs to trace any recent changes in domain admin group membership that might indicate unauthorized access.
-- Investigate the source host from which the modification was made to determine if it is a known administrative workstation or an unusual source.
-- Utilize Osquery to gather additional context on the host involved. For example, run the following query to list recent changes to scheduled tasks: `SELECT * FROM scheduled_tasks WHERE path LIKE '%\\\\SYSVOL\\\\domain\\\\Policies\\\\%\\\\MACHINE\\\\Preferences\\\\ScheduledTasks\\\\ScheduledTasks.xml';`
-- Examine recent network activity from the source host to identify any suspicious connections or data transfers that could indicate lateral movement or data exfiltration.
-- Review historical alerts and logs for any previous suspicious activity associated with the same user account or host to identify patterns or repeated attempts.
-- Consult with the IT team to confirm if the change was part of a planned update or deployment, and cross-reference with change management records for validation.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often create or modify GPO scheduled tasks or services for routine maintenance or updates. These actions can trigger the detection rule, leading to false positives.
-- Automated system management tools: Tools like Microsoft System Center Configuration Manager (SCCM) or other third-party management solutions may modify GPO tasks or services as part of their normal operation, which can be mistaken for malicious activity.
-- Software updates and patches: Some software updates or patches may alter GPO scheduled tasks or services, causing the rule to flag these legitimate changes.
-- To manage false positives, users can create exceptions for known legitimate processes or tools by adding them to the exclusion list in the detection rule. This can be done by identifying the process executable paths or specific file changes that are known to be safe and adding them to the 'not process.executable' or 'not file.name' conditions in the query.
-
-### Response and remediation
-
-- Immediately isolate affected systems from the network to prevent further spread of potential malicious tasks or services.
-- Conduct a thorough investigation to identify the source of the GPO modification, focusing on recent changes and the accounts used to make these changes.
-- Review and verify the legitimacy of the scheduled tasks and services created or modified in the GPO, comparing them against known baselines.
-- Revoke domain admin privileges from any accounts that are not actively required for administrative tasks to limit potential misuse.
-- Restore any unauthorized changes to the GPO by reverting to a known good configuration or using backups.
-- Implement enhanced logging and monitoring for GPO changes, ensuring that all modifications are tracked and alerts are generated for suspicious activities.
-- Integrate security information and event management (SIEM) systems to correlate events and provide a comprehensive view of potential threats.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent future occurrences.
-- Apply hardening measures such as enforcing the principle of least privilege, using multi-factor authentication, and regularly auditing privileged accounts to reduce the risk of similar attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
index 9ddbe7bf7b2..c2ba7fc2038 100644
--- a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
+++ b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,49 +54,6 @@ sequence by winlog.computer_name with maxspan=5m
    /* event 4697 need to be logged */
    event.action : "service-installed"] by winlog.event_data.SubjectLogonId
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Service Creation via Local Kerberos Authentication
-
-Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. In a Windows environment, it is often used for authenticating domain users. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating unauthorized services. The detection rule identifies suspicious local logins using Kerberos, followed by service creation, indicating possible misuse of Kerberos for privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a successful local logon event (event ID 4624) with the Logon Package set to "Kerberos" and the source IP address within the loopback range (127.0.0.0/8 or ::1).
-- Verify the timestamp and LogonId of the suspicious logon event to ensure it aligns with the subsequent service creation event (event ID 4697).
-- Check the winlog.computer_name field to identify the affected host and determine if it is a domain-joined machine.
-- Investigate the winlog.event_data.TargetLogonId and winlog.event_data.SubjectLogonId fields to confirm that the same LogonId is used in both the logon and service creation events, indicating a potential Kerberos relay attack.
-- Use Osquery to list all services created or modified recently on the affected host with the following query: `SELECT name, path, start_type, status FROM services WHERE timestamp >= (SELECT MAX(timestamp) FROM services) - 300;`
-- Examine the source.port field in the logon event to identify any unusual or high-numbered ports that might indicate non-standard communication.
-- Correlate the alert with other security events or logs from the same timeframe to identify any additional suspicious activities or anomalies on the host.
-- Check for any known vulnerabilities or misconfigurations in the Kerberos setup on the affected host that could have been exploited.
-- Review user account activity associated with the logon event to determine if the account has been involved in any other suspicious activities or if it has been compromised.
-- Consult threat intelligence sources to identify if there are any known Kerberos relay attack variants or indicators of compromise that match the observed behavior.
-
-### False positive analysis
-
-- Scheduled tasks or legitimate software updates may trigger local Kerberos authentication followed by service creation, as these processes often use network logon types and may appear similar to malicious activity.
-- System administrators performing routine maintenance or deploying new services might inadvertently match the detection criteria, especially if they use scripts or tools that authenticate locally.
-- Security software or monitoring tools that perform regular checks or updates could also generate events that resemble the described pattern, leading to false positives.
-- To manage these false positives, users can create exceptions for known and trusted processes or accounts that frequently trigger the rule, ensuring that these are well-documented and regularly reviewed to maintain security integrity.
-- Implementing a whitelist of approved service creation activities or specific logon IDs associated with legitimate administrative tasks can help reduce noise and focus on truly suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the presence of a Kerberos relay attack by reviewing relevant logs, including event IDs 4624 and 4697, and correlating them with the suspicious activity.
-- Identify and terminate any unauthorized services created during the attack to prevent further exploitation.
-- Reset passwords for affected accounts and consider implementing multi-factor authentication to enhance security.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the attack.
-- Restore the system to its operational state by removing any malicious software and ensuring all security patches and updates are applied.
-- Implement enhanced logging policies to capture detailed authentication and service creation events, ensuring that event IDs 4624 and 4697 are consistently logged.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities for similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Apply hardening measures such as disabling unused services, enforcing least privilege access, and regularly auditing user permissions to reduce the risk of future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_lsa_auth_package.toml b/rules/windows/privilege_escalation_lsa_auth_package.toml
index eed25abfc5a..73c5572df3c 100644
--- a/rules/windows/privilege_escalation_lsa_auth_package.toml
+++ b/rules/windows/privilege_escalation_lsa_auth_package.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,49 +40,6 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* exclude SYSTEM SID - look for changes by non-SYSTEM user */
   not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential LSA Authentication Package Abuse
-
-The Local Security Authority (LSA) in Windows manages authentication and security policies. Adversaries may exploit LSA by modifying registry paths to load malicious binaries during system authentication, gaining elevated privileges or persistence. The detection rule identifies unauthorized registry changes to LSA authentication packages by non-SYSTEM users, signaling potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path involved is "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\Authentication Packages" or "\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Lsa\\\\Authentication Packages".
-- Verify the user ID associated with the registry change to ensure it is not "S-1-5-18" (SYSTEM), indicating a non-SYSTEM user made the change.
-- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other suspicious activities.
-- Investigate the user account that made the change to assess if it has a history of unusual behavior or if it has been compromised.
-- Use Osquery to list all current LSA authentication packages by running: `SELECT name, data FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Lsa\\\\Authentication Packages';` to identify any unauthorized binaries.
-- Examine the binary referenced in the registry change for known malicious signatures or unusual characteristics using a threat intelligence platform or antivirus tools.
-- Review system logs around the time of the registry change for any related events, such as process creation logs, to identify potential execution of the malicious binary.
-- Check for any recent privilege escalation attempts or successful escalations on the host to determine if the registry change was part of a broader attack.
-- Investigate network activity from the host around the time of the registry change to identify any suspicious outbound connections or data exfiltration attempts.
-- Consult with other security tools or logs, such as endpoint detection and response (EDR) solutions, to gather additional context and corroborate findings related to the suspicious registry change.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify the LSA authentication packages registry path, leading to false positives. Users should verify if the change coincides with a known software update or installation.
-- Security software or system management tools might alter the registry path as part of their normal operations. Users can create exceptions for these trusted applications by identifying their specific user IDs or process names.
-- System administrators performing maintenance or configuration changes might trigger the rule. To manage this, users can exclude specific administrator accounts or scheduled maintenance windows from the detection rule.
-- In environments with custom authentication solutions, legitimate changes to the LSA authentication packages might occur. Users should document these solutions and adjust the rule to exclude known benign modifications.
-- Regular audits and baselining of the registry path can help identify expected changes, allowing users to refine the detection rule to focus on truly anomalous activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify any unauthorized registry changes and determine the scope of the compromise, focusing on the LSA authentication packages registry path.
-- Review recent user activity and system logs to identify the non-SYSTEM user responsible for the registry modification and assess their access level and actions.
-- Remove any unauthorized binaries referenced in the LSA authentication packages registry path to prevent malicious execution during system authentication.
-- Restore the registry to its previous state using backups or system restore points, ensuring that only legitimate authentication packages are loaded.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed registry changes and user activities, ensuring that future unauthorized modifications are detected promptly.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Conduct a security review of user permissions and access controls, ensuring that only authorized personnel have the ability to modify critical registry paths.
-- Apply system hardening measures, such as enabling Windows Defender Credential Guard, to protect LSA processes and prevent unauthorized access to sensitive authentication data."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_make_token_local.toml b/rules/windows/privilege_escalation_make_token_local.toml
index 992e9bfc506..087a566beff 100644
--- a/rules/windows/privilege_escalation_make_token_local.toml
+++ b/rules/windows/privilege_escalation_make_token_local.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,49 +50,6 @@ authentication where
              "?:\\Windows\\System32\\inetsrv\\w3wp.exe", 
              "?:\\Windows\\SysWOW64\\msiexec.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Interactive Logon by an Unusual Process
-
-Interactive logons in Windows environments typically involve processes like winlogon.exe, which handle user authentication. Adversaries may exploit this by using alternate processes to create tokens, escalating privileges and bypassing controls. The detection rule identifies anomalies by flagging logons initiated by unexpected processes, especially those not originating from standard system directories, indicating potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process executable path that triggered the alert, ensuring it matches the criteria of being outside standard system directories.
-- Verify the legitimacy of the process executable by checking its digital signature and comparing it against known good hashes or software inventories.
-- Examine the `winlog.event_data.LogonProcessName` field to determine if the process name "Advapi*" is expected or if it indicates potential misuse.
-- Investigate the `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetUserSid` fields to identify the user accounts involved in the logon attempt and assess if they are legitimate or potentially compromised.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE path = 'C:\\\\path\\\\to\\\\suspicious\\\\executable.exe';` to retrieve details like process start time, parent process, and command-line arguments.
-- Check the system's security and application logs for any related events around the time of the alert to identify any preceding or subsequent suspicious activities.
-- Investigate the host's network connections during the time of the alert to identify any unusual outbound or inbound connections that could indicate lateral movement or data exfiltration.
-- Analyze the process tree to understand the parent-child relationship of the suspicious process and identify any other processes that may have been spawned as part of the activity.
-- Review recent changes to the system, such as software installations or updates, that could explain the presence of the unusual process.
-- Consult threat intelligence sources to determine if the process or behavior matches any known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- Legitimate administrative tools or scripts that initiate logons from non-standard directories may trigger this rule. Users should review the source and purpose of these tools to determine if they are authorized.
-- Custom applications or services that require interactive logons and are installed in non-standard directories can also be flagged. Users can create exceptions for these applications by adding their executable paths to the exclusion list.
-- Automated processes or scheduled tasks that perform logons for maintenance or updates might be misidentified. Users should verify these tasks and, if legitimate, exclude their associated processes.
-- Developers or IT personnel using remote desktop or other remote management tools from non-standard locations may cause false positives. Users should ensure these activities are documented and consider excluding known safe processes.
-- To manage false positives, users can refine the detection rule by adding specific process paths or user SIDs to the exclusion criteria, ensuring that only unexpected or unauthorized activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the unusual process and determine if it is malicious or unauthorized, using endpoint detection and response (EDR) tools.
-- Review recent changes to user accounts and permissions to identify any unauthorized privilege escalations or account creations.
-- Terminate any suspicious processes and remove any unauthorized accounts or permissions identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation confirms malicious activity or if the scope of the incident is unclear.
-- Implement enhanced logging policies to capture detailed authentication and process execution events, ensuring logs are stored securely for future analysis.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are compliant with organizational policies.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as enforcing least privilege access, using multi-factor authentication, and regularly auditing user accounts and permissions to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
index 62bce7ccc9b..61ad9c71af4 100644
--- a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
+++ b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel", "m365_defender", "window
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 
 [rule]
 author = ["Elastic"]
@@ -51,52 +51,6 @@ process where event.type == "start" and host.os.type == "windows" and
                         "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and
  process.parent.command_line : "*go.microsoft.com*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Escalation via Vulnerable MSI Repair
-
-Windows Installer (MSI) is a service used for the installation, maintenance, and removal of software. Adversaries may exploit vulnerabilities in MSI repair processes to gain elevated privileges. This detection rule identifies suspicious activity by monitoring browser processes that access Microsoft Help pages and subsequently initiate elevated processes, indicating potential exploitation attempts for privilege escalation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a browser process accessing Microsoft Help pages, as indicated by the `process.parent.command_line` field containing "*go.microsoft.com*".
-- Verify the parent process name using the `process.parent.name` field to ensure it matches one of the specified browsers (e.g., "chrome.exe", "msedge.exe", etc.).
-- Check the user domain in the `user.domain` field to confirm if the process is running under a system account like "NT AUTHORITY", which may indicate an attempt to gain elevated privileges.
-- Investigate the child process that was spawned by the browser to determine if it is an elevated process, using the `process` field to identify the process name and command line.
-- Correlate the timing of the browser navigation to the Microsoft Help page with the start time of the elevated process to assess if they are closely linked.
-- Use Osquery to gather additional context on the processes involved. For example, run the following Osquery query to list processes with elevated privileges:
-  ```sql
-  SELECT pid, name, path, cmdline, uid, gid FROM processes WHERE uid = 0;
-  ```
-- Examine the system's event logs for any additional indicators of privilege escalation attempts or anomalies around the time of the alert.
-- Investigate any recent software installations or updates that might have triggered the MSI repair process, potentially leading to the exploitation attempt.
-- Check for any known vulnerabilities or patches related to Windows Installer that might be relevant to the alert.
-- Gather information on the network activity of the involved processes to identify any suspicious outbound connections or data exfiltration attempts.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger this rule if they involve accessing Microsoft Help pages and subsequently launching elevated processes. Users should verify if the process is part of a known update or installation routine.
-- Automated scripts or system management tools that access Microsoft Help pages for documentation or troubleshooting purposes might also cause false positives. Users can create exceptions for these tools by identifying their specific command lines or process names.
-- Browsers with extensions or plugins that automatically navigate to Microsoft Help pages for support or information gathering could be flagged. Users should review the extensions in use and whitelist trusted ones.
-- IT support activities where technicians access Microsoft Help pages to assist users and then perform administrative tasks might be misidentified. Organizations can exclude known IT support tools or processes from triggering the rule.
-- Users can manage false positives by maintaining a list of known safe processes and command lines that frequently interact with Microsoft Help pages and ensuring these are excluded from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Conduct a thorough investigation to confirm the exploitation by reviewing logs and identifying any unauthorized elevated processes initiated by browser activity.
-- Terminate any suspicious elevated processes that were spawned following the browser's access to Microsoft Help pages.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Apply the latest security patches and updates to the Windows Installer service to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar exploitation attempts.
-- Restore the system to its operational state by verifying the integrity of system files and reinstalling any compromised software.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege principles, and conducting regular security audits to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
index eda15a8dbfc..77e4e70c55a 100644
--- a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
+++ b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -28,49 +28,6 @@ type = "new_terms"
 query = '''
 event.category:"authentication" and host.os.type:"windows" and winlog.logon.type:"NewCredentials" and winlog.event_data.LogonProcessName:(Advapi* or "Advapi  ") and not winlog.event_data.SubjectUserName:*$ and not process.executable :???\\Program?Files*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Time Seen NewCredentials Logon Process
-
-The NewCredentials logon type in Windows allows a user to create a new security context using different credentials without logging off. Adversaries exploit this by forging access tokens to escalate privileges or bypass controls. The detection rule identifies unusual processes initiating such logons, excluding known system paths, to flag potential misuse indicative of token manipulation tactics.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process triggered the NewCredentials logon type and note the `process.executable` path for further analysis.
-- Verify the `winlog.event_data.SubjectUserName` to identify the user account involved and check if it aligns with expected behavior or known user activity.
-- Investigate the `winlog.event_data.LogonProcessName` to confirm if it is indeed an unusual process initiating the logon, focusing on processes like "Advapi" that are commonly used in token manipulation.
-- Cross-reference the `host.os.type` to ensure the alert pertains to a Windows system, as this context is crucial for understanding the environment.
-- Use Osquery to gather more information about the suspicious process. For example, run the query: `SELECT * FROM processes WHERE path = '<process.executable path>'` to gather details such as process start time, parent process, and command line arguments.
-- Check the event logs for any preceding or subsequent suspicious activities related to the same `SubjectUserName` or `process.executable` to identify potential patterns or additional indicators of compromise.
-- Investigate the system's recent authentication logs to identify any other unusual logon types or failed logon attempts that might correlate with the alert.
-- Analyze network logs to determine if there was any unusual outbound or inbound traffic from the host around the time of the alert, which might indicate lateral movement or data exfiltration attempts.
-- Review any recent changes or updates to the system that might explain the new process behavior, such as software installations or configuration changes.
-- Consult threat intelligence sources to check if the `process.executable` or any related indicators have been associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- Scheduled tasks or automated scripts that use the NewCredentials logon type for legitimate purposes may trigger false positives. These tasks often run under specific service accounts or known user accounts.
-- Administrative tools or software that require elevated privileges and use the NewCredentials logon type can also be flagged. These tools might be part of regular IT operations or maintenance activities.
-- Users can manage these false positives by creating exceptions for specific processes or user accounts that are known to perform legitimate NewCredentials logons. This can be done by adding these processes or accounts to an allowlist within the detection rule.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
-- Consider monitoring the frequency and context of NewCredentials logons to distinguish between normal operational patterns and potential threats, adjusting the detection criteria as necessary.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Review the event logs to identify the source and scope of the NewCredentials logon activity, focusing on unusual processes and user accounts involved.
-- Terminate any suspicious processes identified during the investigation to halt potential malicious activity.
-- Change passwords for any compromised accounts and enforce multi-factor authentication to enhance security.
-- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software.
-- Restore the system from a known good backup if malicious activity has compromised system integrity.
-- Implement enhanced logging policies to capture detailed authentication and process execution events for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response if necessary.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by adversaries."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
index 6752731d19c..a7cba94a807 100644
--- a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
+++ b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/10"
 
 [rule]
 author = ["Elastic"]
@@ -43,49 +43,6 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* exclude SYSTEM SID - look for changes by non-SYSTEM user */
   not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Port Monitor or Print Processor Registration Abuse
-
-Port monitors and print processors are components in Windows that manage print jobs and data formatting. Adversaries exploit these by modifying registry paths to load malicious DLLs during system boot, gaining SYSTEM-level privileges. The detection rule identifies unauthorized registry changes to these paths, excluding those made by the SYSTEM user, to flag potential abuse for privilege escalation or persistence.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path that was modified, focusing on paths related to port monitors and print processors as specified in the query.
-- Verify the user account associated with the registry change by examining the `user.id` field to ensure it is not the SYSTEM user (S-1-5-18), which is excluded in the detection rule.
-- Check the timestamp of the registry modification event to determine when the change occurred and correlate it with other system activities or logs around the same time.
-- Investigate the DLL file specified in the `registry.data.strings` field to determine its legitimacy by checking its file path, digital signature, and any known associations with malicious activity.
-- Use Osquery to list all DLLs currently registered as port monitors or print processors with a query like: `SELECT * FROM registry WHERE path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Print\\\\Monitors\\\\%' OR path LIKE 'HKEY_LOCAL_MACHINE\\\\SYSTEM\\\\%ControlSet%\\\\Control\\\\Print\\\\Environments\\\\Windows%\\\\Print Processors\\\\%';`
-- Cross-reference the identified DLL with threat intelligence databases or malware repositories to check for any known indicators of compromise.
-- Analyze the system's event logs, particularly the Security and System logs, for any suspicious activities or anomalies around the time of the registry change.
-- Investigate the system's startup programs and services to identify any unauthorized or unusual entries that could indicate persistence mechanisms.
-- Conduct a historical review of similar registry changes on the affected host to determine if this is an isolated incident or part of a recurring pattern.
-- If possible, perform a memory analysis on the affected system to detect any in-memory threats or anomalies associated with the suspicious DLL.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify print processor or port monitor registry paths, leading to false positives. Users should verify if the changes coincide with known software updates or installations.
-- Printer driver updates or installations can also trigger this rule. Users should check if the registry changes align with recent printer-related activities.
-- Some enterprise environments may have custom print solutions that modify these registry paths as part of their normal operation. Users can create exceptions for these known applications by identifying their specific user IDs or paths.
-- System administrators performing maintenance or configuration changes might inadvertently cause registry modifications. Users should ensure that such activities are documented and can be correlated with the detected changes.
-- To manage false positives, users can implement exceptions by excluding specific user IDs, paths, or known benign DLLs from the detection rule, ensuring that these exceptions are regularly reviewed and updated as necessary.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Verify the unauthorized registry changes by comparing with a known good baseline and identify the malicious DLLs involved.
-- Terminate any suspicious processes associated with the malicious DLLs to prevent further execution.
-- Remove or revert the unauthorized registry changes to their original state to disable the persistence mechanism.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
-- Review user accounts and permissions to ensure that only authorized users have the necessary privileges to modify critical registry paths.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to monitor registry changes and DLL loads, ensuring that logs are forwarded to a centralized logging solution for analysis.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) for improved detection and response.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege principles, to reduce the attack surface and prevent similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
index 8f00c7b892e..c27dff3ffb8 100644
--- a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
+++ b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,52 +53,6 @@ sequence by host.id with maxspan=30s
     ) and
  registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4\\*"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Print Spooler Point and Print DLL
-
-The Windows Print Spooler service manages print jobs and related tasks, often requiring elevated privileges. Adversaries exploit vulnerabilities like CVE-2020-1030 to load malicious DLLs, gaining SYSTEM-level access. The detection rule identifies registry changes linked to unauthorized DLL loading paths, signaling potential exploitation attempts by monitoring specific registry keys and values associated with the print spooler.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry paths involved, specifically checking for changes in `HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\SpoolDirectory` and `HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\CopyFiles\\Payload\\Module`.
-- Verify the `registry.data.strings` value to ensure it matches the suspicious path `C:\\Windows\\System32\\spool\\drivers\\x64\\4` or any subdirectory, indicating potential unauthorized DLL loading.
-- Cross-reference the host.id from the alert with recent logs to identify any other suspicious activities or anomalies on the same host.
-- Use Osquery to list all DLLs currently loaded by the print spooler process to identify any unexpected or unauthorized modules:
-  ```sql
-  SELECT pid, name, path FROM processes JOIN process_open_sockets ON processes.pid = process_open_sockets.pid WHERE name LIKE '%spoolsv%';
-  ```
-- Investigate the process tree for the print spooler service to identify any unusual parent or child processes that could indicate exploitation.
-- Check for any recent privilege escalation attempts or successful escalations on the host by reviewing security event logs, particularly those related to user privilege changes.
-- Analyze network traffic logs from the host around the time of the alert to detect any outbound connections that could suggest data exfiltration or command and control activity.
-- Review recent changes to the system, including software installations or updates, that could have introduced vulnerabilities or been exploited.
-- Examine the timeline of registry changes to determine if they coincide with known attack patterns or other suspicious activities.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors currently exploiting CVE-2020-1030, which could provide additional context or indicators of compromise.
-
-### False positive analysis
-
-- Legitimate software installations or updates may modify the registry paths monitored by the rule, leading to false positives. Users should verify if any authorized software changes align with the detected activity.
-- Printer driver updates or installations can trigger the rule due to legitimate changes in the spool directory or module paths. Users should cross-reference the timing of these updates with the alerts to determine if they are benign.
-- Network administrators performing routine maintenance or configuration changes on print servers might inadvertently cause registry modifications that match the rule's criteria. Users should document and exclude these known maintenance windows to reduce false positives.
-- To manage false positives, users can create exceptions for specific registry paths or values that are known to be safe and frequently modified by trusted processes. This can be done by updating the detection rule to exclude these paths or by using a security information and event management (SIEM) system to filter out non-threatening alerts.
-- Regularly review and update the list of exceptions to ensure that only verified and non-malicious activities are excluded, maintaining the balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to confirm the presence of unauthorized DLLs and identify any other compromised systems by reviewing registry changes and system logs.
-- Remove any unauthorized DLLs and restore legitimate DLLs from a known good backup or installation media.
-- Apply the latest security patches and updates from Microsoft to address CVE-2020-1030 and other known vulnerabilities.
-- Reset all credentials and passwords for accounts that have been accessed or could potentially be compromised, especially those with elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging and monitoring policies to capture detailed information on registry changes, DLL loads, and print spooler activities for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide real-time alerts on suspicious activities.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, ensuring no backdoors or persistence mechanisms remain.
-- Harden the system by disabling unnecessary services, enforcing least privilege principles, and regularly reviewing and updating security configurations to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
index ab507a91f1d..f43288f064e 100644
--- a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
+++ b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,48 +51,6 @@ query = '''
 event.category : "file" and host.os.type : "windows" and event.type : "creation" and
   process.name : "spoolsv.exe" and file.extension : "dll"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious PrintSpooler Service Executable File Creation
-
-The Print Spooler service manages print jobs in Windows environments, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies suspicious DLL file creation by monitoring file events linked to the spooler process, helping to flag potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the suspicious DLL file creation event, focusing on the `event.category`, `host.os.type`, `event.type`, `process.name`, and `file.extension` fields.
-- Verify the file path and name of the created DLL to determine if it matches known malicious patterns or if it is located in an unusual directory.
-- Check the timestamp of the DLL creation event to correlate it with other suspicious activities or known attack timelines.
-- Investigate the parent process of `spoolsv.exe` to identify any unusual or unauthorized processes that may have initiated the DLL creation.
-- Use Osquery to list all DLL files in the spooler directory and their creation times with a query like: `SELECT path, ctime FROM file WHERE directory = 'C:\\\\Windows\\\\System32\\\\spool\\\\drivers\\\\' AND extension = 'dll';`
-- Examine recent login events and user activities around the time of the DLL creation to identify any unauthorized access or privilege escalation attempts.
-- Analyze network traffic logs for any unusual outbound connections from the host around the time of the event, which may indicate data exfiltration or command and control communication.
-- Check for any recent patches or updates applied to the system to ensure that vulnerabilities like CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 have been addressed.
-- Review security logs for any other alerts or anomalies related to the Print Spooler service or the affected host to build a comprehensive picture of the incident.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns targeting the Print Spooler service.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they involve creating DLL files through the Print Spooler service. Users should verify the source and context of the file creation to determine if it is part of a trusted update or installation process.
-- Some printer drivers or management software might create DLL files as part of their normal operation. Users can create exceptions for specific file paths or hashes associated with known and trusted printer software to reduce false positives.
-- In environments with custom scripts or administrative tools that interact with the Print Spooler service, these might inadvertently trigger the rule. Users should review and whitelist these scripts or tools if they are verified to be safe and necessary for operations.
-- To manage false positives, users can implement a monitoring period to identify patterns of benign activity and adjust the detection rule to exclude these patterns, ensuring that only truly suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Conduct a thorough investigation to confirm the presence of malicious DLL files and identify any other compromised components.
-- Utilize endpoint detection and response (EDR) tools to analyze the spoolsv.exe process and associated file creation events for further indicators of compromise.
-- Apply the latest security patches for the Print Spooler service, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to mitigate known vulnerabilities.
-- Remove any unauthorized or suspicious DLL files and restore legitimate versions from a trusted backup or installation media.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed file creation events and process activities related to the Print Spooler service for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats proactively.
-- Restore the system to its operational state by verifying the integrity of critical system files and ensuring all security patches are applied.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly reviewing security configurations to reduce the attack surface."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
index 9cb198cb66c..65e8bd0d499 100644
--- a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
+++ b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,49 +47,6 @@ file where host.os.type == "windows" and event.type == "deletion" and
   file.extension : "dll" and file.path : "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.dll" and
   not process.name : ("spoolsv.exe", "dllhost.exe", "explorer.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Print Spooler File Deletion
-
-The Print Spooler service manages print jobs in Windows environments, crucial for handling print requests. Adversaries exploit vulnerabilities in this service to escalate privileges, often deleting driver files to cover tracks post-exploitation. The detection rule identifies unusual deletions of these files by monitoring for non-standard processes performing such actions, signaling potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path and extension match the suspicious criteria: `?:\\\\Windows\\\\System32\\\\spool\\\\drivers\\\\x64\\\\3\\\\*.dll`.
-- Identify the process responsible for the deletion by examining the `process.name` field and verify it is not one of the expected processes: `spoolsv.exe`, `dllhost.exe`, or `explorer.exe`.
-- Check the `host.os.type` to ensure the event occurred on a Windows system, as the rule is specific to Windows environments.
-- Investigate the parent process of the suspicious process to understand the context of how it was initiated.
-- Use Osquery to gather more information about the suspicious process. Example query: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';`.
-- Examine recent login events on the affected host to identify any unusual or unauthorized access patterns around the time of the file deletion.
-- Review the system's event logs for any related security events or anomalies that coincide with the time of the file deletion.
-- Check for any recent changes or updates to the Print Spooler service or related drivers that could explain the file deletion.
-- Investigate network activity from the affected host to identify any suspicious outbound connections or data exfiltration attempts.
-- Correlate the event with other alerts or incidents in the environment to determine if this is part of a larger attack campaign.
-
-### False positive analysis
-
-- Routine administrative tasks or software updates may trigger the deletion of print driver files by legitimate processes not included in the exclusion list, such as custom scripts or third-party management tools.
-- Security software or system optimization tools might delete or modify these files as part of their regular operations, leading to false positives.
-- Users can manage these false positives by identifying and documenting legitimate processes that interact with print driver files and adding them to the exclusion list in the detection rule.
-- Regularly review and update the exclusion list to include any new legitimate processes that are introduced into the environment, ensuring that only non-threatening behaviors are excluded.
-- Collaborate with IT and security teams to understand the context of each alert, verifying whether the process involved is part of a known and safe operation.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the process responsible for the deletion, using endpoint detection and response (EDR) tools to trace the process lineage and gather forensic evidence.
-- Verify the integrity of the Print Spooler service and associated files by comparing them against known good baselines or using file integrity monitoring tools.
-- Restore any deleted or altered print driver files from a trusted backup to ensure the Print Spooler service can function correctly.
-- Apply the latest security patches and updates to the Windows operating system and specifically to the Print Spooler service to mitigate known vulnerabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of privilege escalation or further compromise.
-- Implement enhanced logging and monitoring for the Print Spooler service and related processes to detect future anomalies, ensuring logs are sent to a centralized logging solution for analysis.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) to enhance detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly, focusing on improving detection and response times.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and implementing application whitelisting to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
index 73a812de142..fb45da30925 100644
--- a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
+++ b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -87,49 +87,6 @@ registry where host.os.type == "windows" and event.type == "change" and process.
         )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privilege Escalation via Service ImagePath Modification
-
-Windows services run with elevated privileges, often as SYSTEM, making them targets for privilege escalation. Adversaries may modify the ImagePath registry key of a service to execute malicious code with these privileges. The detection rule identifies changes to the ImagePath of critical services, excluding legitimate paths, to spot unauthorized modifications indicative of an attack.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific service whose ImagePath registry key was modified, using the `registry.key` field from the query.
-- Check the `process.executable` field to determine which process was responsible for the registry modification, and verify if it is a known legitimate process or potentially malicious.
-- Investigate the `registry.data.strings` field to see the new value of the ImagePath and assess if it points to a suspicious or unauthorized executable.
-- Use Osquery to list all services and their ImagePaths on the affected host to identify any other unusual modifications. Example query: `SELECT name, path FROM services WHERE path NOT LIKE 'C:\\\\Windows\\\\system32\\\\%';`
-- Cross-reference the modified ImagePath with known malicious file hashes or paths using threat intelligence sources.
-- Examine the event logs on the affected host for any additional context around the time of the modification, focusing on user activity and other system changes.
-- Check for any recent logins or privilege escalations on the host that could indicate how the attacker gained the necessary permissions to modify the registry.
-- Investigate the user account associated with the modification event to determine if it has been compromised or if it has legitimate reasons for making such changes.
-- Look for any other alerts or anomalies on the same host or network segment that might correlate with the suspicious activity, indicating a broader attack.
-- Review historical data to see if similar modifications have occurred in the past, which could suggest a recurring issue or persistent threat actor.
-
-### False positive analysis
-
-- Legitimate software updates or installations may modify the ImagePath of services, triggering the rule. Users can handle these by verifying the source and purpose of the change and adding exceptions for trusted software vendors.
-- System administrators may intentionally modify service configurations for maintenance or optimization purposes. To manage this, document and approve such changes through a change management process and exclude these specific modifications from the rule.
-- Some security tools or monitoring solutions might alter service paths as part of their operation. Identify these tools and create exceptions for their known behaviors to prevent false alerts.
-- Custom scripts or automation tasks that modify service configurations for legitimate reasons can also trigger the rule. Review these scripts, ensure they are secure, and exclude their actions from the detection rule.
-- In environments with frequent legitimate service modifications, consider implementing a baseline of expected service configurations and use it to differentiate between authorized and unauthorized changes.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the modification, including reviewing recent user activity and process execution logs.
-- Verify the integrity of the modified service by comparing its current ImagePath with a known good configuration or baseline.
-- Restore the ImagePath registry key to its original, legitimate value using a backup or by manually correcting it.
-- Scan the system for additional signs of compromise, such as unauthorized user accounts or scheduled tasks, using endpoint detection and response (EDR) tools.
-- Escalate the incident to the security operations center (SOC) or incident response team if the modification is part of a broader attack campaign.
-- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) from the MITRE ATT&CK framework.
-- Apply system hardening measures, such as restricting service modification permissions to only trusted administrators and enabling Windows Defender Application Control (WDAC) to prevent unauthorized executables.
-- Conduct a post-incident review to identify gaps in detection and response capabilities and update security policies and procedures accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
index 3e093e74b5f..c87668f25ff 100644
--- a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
+++ b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,49 +52,6 @@ registry.path : (
     ) and
  not registry.data.strings : ("C:\\windows", "%SystemRoot%")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privilege Escalation via Windir Environment Variable
-
-The Windir environment variable in Windows specifies the directory where system files reside. Adversaries may manipulate this variable to redirect processes to malicious directories, thereby gaining elevated privileges. The detection rule identifies changes to this variable in user registry paths, flagging deviations from expected values like "C:\\windows" to detect potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the registry path and value that triggered the alert, focusing on the `registry.path` and `registry.data.strings` fields to identify deviations from expected values like "C:\\windows" or "%SystemRoot%".
-- Check the user account associated with the registry change by examining the `HKEY_USERS` or `HKCU` path to determine if the change was made under a specific user profile.
-- Investigate recent login activity for the user account identified in the previous step to determine if there were any unusual or unauthorized access attempts.
-- Use Osquery to list all environment variables for the affected user to identify any other suspicious modifications. Example query: `SELECT * FROM registry WHERE path LIKE 'HKEY_USERS\\\\%\\\\Environment\\\\%' OR path LIKE 'HKCU\\\\%\\\\Environment\\\\%';`
-- Examine the process creation logs around the time of the registry change to identify any suspicious processes that might have been executed with elevated privileges.
-- Correlate the registry change event with any recent software installations or updates that might have altered environment variables, checking for legitimate changes.
-- Search for any other registry changes made by the same user or process to identify patterns or additional indicators of compromise.
-- Review system and security event logs for any anomalies or errors that coincide with the time of the registry change, which might provide additional context or evidence of exploitation.
-- Investigate network activity from the affected host to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
-- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with privilege escalation or other malicious activities.
-
-### False positive analysis
-
-- Changes to the Windir environment variable may occur during legitimate software installations or updates, where applications temporarily modify environment variables to point to custom directories. Users should verify if the change coincides with a known software update or installation.
-- Some enterprise environments may have custom scripts or administrative tools that modify the Windir variable for specific operational needs. Users should document and whitelist these known scripts or tools to prevent false positives.
-- Virtual environments or sandboxed applications might alter the Windir variable to redirect system calls within the virtualized context. Users should identify and exclude these environments from triggering alerts.
-- In development environments, developers might intentionally change the Windir variable for testing purposes. Users should establish a policy to track and approve such changes, allowing exceptions for known development activities.
-- To manage false positives, users can create exceptions in the detection rule for specific user accounts or systems where these changes are expected and verified as non-malicious.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized changes to the Windir environment variable and determine the source of the modification.
-- Review system logs and security events to identify any additional indicators of compromise or related suspicious activities.
-- Restore the Windir environment variable to its default value, typically "C:\\windows", and verify the integrity of system files.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to monitor changes to critical environment variables and registry paths, ensuring that all modifications are logged and reviewed.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar threats in the future.
-- Apply security patches and updates to address any vulnerabilities that may have been exploited in conjunction with the Windir manipulation.
-- Educate users and administrators on the risks associated with environment variable manipulation and provide training on recognizing potential security threats.
-- Consider implementing application whitelisting and endpoint protection solutions to prevent unauthorized changes to system configurations and environment variables."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
index 5cf5047467b..74ffe84b293 100644
--- a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
+++ b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/12"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,52 +55,6 @@ iam where event.action == "renamed-user-account" and
   /* machine account name renamed to user like account name */
   winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Privileged Escalation via SamAccountName Spoofing
-
-In Active Directory environments, the `samAccountName` attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to rename computer accounts, mimicking domain controllers and gaining elevated privileges. The detection rule identifies suspicious renaming events where a machine account is altered to resemble a user account, signaling potential privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a `renamed-user-account` event action, focusing on the `winlog.event_data.OldTargetUserName` and `winlog.event_data.NewTargetUserName` fields to verify if a machine account was renamed to resemble a user account.
-- Cross-reference the `OldTargetUserName` and `NewTargetUserName` with known domain controller and user account naming conventions to identify any anomalies or patterns that suggest spoofing.
-- Check the event timestamp to determine when the renaming occurred and correlate it with other security events or logs around the same time for additional context.
-- Investigate the source of the renaming event by identifying the user or process that initiated the change, using the `winlog.event_data.SubjectUserName` and `winlog.event_data.SubjectUserSid` fields.
-- Utilize Osquery to gather more information about the system where the renaming event originated. For example, run the following Osquery query to list recent account changes on the system:
-  ```sql
-  SELECT * FROM users WHERE last_change > (SELECT MAX(last_change) - 86400 FROM users);
-  ```
-- Examine the system logs and security logs on the originating machine for any signs of unauthorized access or suspicious activity leading up to the renaming event.
-- Check for any recent changes in group memberships, especially those involving privileged groups like Domain Admins, to identify potential privilege escalation.
-- Analyze network traffic logs to detect any unusual communication patterns between the affected machine and other domain controllers or critical servers.
-- Review any recent patches or updates applied to the system to ensure that CVE-2021-42278 and related vulnerabilities have been addressed.
-- Consult with other security team members or stakeholders to gather additional insights or context that may aid in understanding the scope and impact of the potential privilege escalation attempt.
-
-### False positive analysis
-
-- Routine administrative tasks: In some environments, IT administrators may regularly rename computer accounts as part of maintenance or reorganization efforts. These legitimate activities can trigger the detection rule, leading to false positives. To manage this, create exceptions for known administrative actions by excluding specific administrator accounts or scheduled maintenance periods from the rule.
-- Automated scripts or tools: Some organizations use automated scripts or third-party tools to manage Active Directory accounts, which might include renaming operations. These can be mistaken for malicious activity. Identify and exclude these scripts or tools by their unique identifiers or execution context to reduce false positives.
-- Migrations or upgrades: During system migrations or software upgrades, bulk renaming of accounts might occur, which can be flagged by the rule. To handle this, temporarily disable the rule during planned migrations or add exceptions for the duration of the upgrade process.
-- Testing environments: In test or development environments, frequent renaming of accounts for testing purposes can trigger alerts. Consider excluding these environments from the rule or setting up a separate monitoring policy that accounts for the higher volume of changes.
-- Known service accounts: Some service accounts may have legitimate reasons to change their names, such as aligning with new naming conventions. Document these accounts and create exceptions to prevent them from being flagged as suspicious.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the exploitation of CVE-2021-42278 by reviewing logs and identifying any unauthorized changes to the samAccountName attribute.
-- Revert any unauthorized changes to the samAccountName attribute to restore the original state of the affected accounts.
-- Reset passwords for any accounts that were potentially compromised during the incident to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the full scope of the breach.
-- Implement enhanced logging policies to capture detailed events related to account management and privilege escalation attempts for future investigations.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze security events across the network for improved threat detection.
-- Apply security patches and updates to all systems to mitigate known vulnerabilities, including CVE-2021-42278, and prevent similar attacks.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate and train IT staff and users on recognizing and responding to potential security threats, emphasizing the importance of maintaining strong security hygiene."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
index 381165b6e37..100d963e6e4 100644
--- a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
+++ b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/11"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,50 +48,6 @@ iam where event.action == "changed-computer-account" and user.id : ("S-1-5-21-*"
     /* exclude FPs where DnsHostName starts with the ComputerName that was changed */
     not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Remote Computer Account DnsHostName Update
-
-In Active Directory environments, the DnsHostName attribute is crucial for identifying and locating computers within the network. Adversaries may exploit this by altering a computer account's DnsHostName to mimic a domain controller, potentially leveraging vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, while filtering out false positives.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific computer account and the new DnsHostName value that triggered the alert.
-- Verify if the new DnsHostName matches any known domain controller DNS hostnames within the network to assess the likelihood of malicious intent.
-- Check the user.id field to determine which user account initiated the change and assess if this account has a history of similar activities or elevated privileges.
-- Investigate the winlog.event_data.TargetUserName to confirm the original computer account name and compare it with the new DnsHostName for any suspicious similarities.
-- Use Osquery to gather additional context on the affected computer account by running a query such as: `SELECT * FROM users WHERE uid = '<user_id_from_alert>';` to retrieve user details and recent activities.
-- Examine recent login events and changes associated with the user.id to identify any unusual patterns or unauthorized access attempts.
-- Cross-reference the event.action field with other logs to determine if there are additional changes or anomalies related to the same computer account or user.
-- Analyze network traffic logs to detect any unusual communication patterns from the affected computer account, especially towards domain controllers.
-- Consult Active Directory logs to verify if there are any other recent changes to the DnsHostName attribute across different computer accounts that might indicate a broader attack.
-- Collaborate with IT and security teams to gather insights on any recent network changes or incidents that could provide context to the alert.
-
-### False positive analysis
-
-- False positives may occur when legitimate administrative tasks involve updating the DnsHostName attribute of computer accounts, especially during network reconfigurations or migrations.
-- Routine maintenance activities by IT staff, such as renaming computers or updating DNS records, can trigger the detection rule if the new hostname coincidentally resembles a domain controller's.
-- Automated scripts or tools used for bulk updates to computer accounts might inadvertently match the detection criteria, especially in large environments with frequent changes.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific time windows when legitimate changes are expected.
-- Implementing a whitelist of authorized scripts or tools that perform bulk updates can help reduce unnecessary alerts.
-- Regularly review and update the detection rule's filters to align with the organization's operational patterns and reduce noise from expected activities.
-
-### Response and remediation
-
-- Immediately isolate the affected computer from the network to prevent further unauthorized access or potential lateral movement.
-- Verify the legitimacy of the DnsHostName change by cross-referencing with recent administrative activities and change management records.
-- Conduct a thorough investigation to determine if CVE-2022-26923 or any other vulnerabilities were exploited, using endpoint detection and response (EDR) tools to gather forensic evidence.
-- Revert the DnsHostName to its original value if the change is confirmed to be unauthorized, and ensure that the computer account is not impersonating a domain controller.
-- Reset passwords for any accounts that may have been compromised during the incident, focusing on privileged accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed events related to Active Directory changes, including DnsHostName updates, and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify critical attributes like DnsHostName.
-- Conduct a post-incident review to identify gaps in security controls and processes, and apply lessons learned to improve future incident response efforts.
-- Apply hardening measures such as patching known vulnerabilities, enforcing least privilege principles, and conducting regular security audits to prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
index e1c202781c5..b661cf23c54 100644
--- a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
+++ b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -70,52 +70,6 @@ any where host.os.type == "windows" and event.provider: "Microsoft-Windows-Secur
           "?:\\Windows\\System32\\wbem\\WmiPrvSe.exe",
           "?:\\Windows\\SysWOW64\\wbem\\WmiPrvSe.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 SeDebugPrivilege Enabled by a Suspicious Process
-
-SeDebugPrivilege allows processes to debug and modify other processes, a capability often reserved for system-level tasks. Adversaries exploit this by creating processes with elevated privileges to bypass security controls. The detection rule identifies suspicious processes enabling SeDebugPrivilege by filtering out legitimate system processes and focusing on unusual privilege escalations, helping analysts spot potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process triggered the SeDebugPrivilege and note the timestamp, process name, and user context.
-- Verify the `winlog.event_data.SubjectUserSid` to determine the user account associated with the suspicious process and check if it deviates from expected system accounts.
-- Examine the `winlog.event_data.ProcessName` to identify the executable path and assess if it matches any known legitimate applications or if it appears unusual.
-- Cross-reference the process name and path against the exclusion list in the detection rule to confirm it is not a false positive from a known system process.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list processes with SeDebugPrivilege:
-  ```sql
-  SELECT pid, name, path, uid, gid, on_disk FROM processes WHERE name = '<suspicious_process_name>';
-  ```
-- Investigate the parent process of the suspicious process to understand the process lineage and identify any potential anomalies in process creation.
-- Check for any recent changes in user privileges or group memberships that might explain the unexpected privilege escalation.
-- Analyze the system's security logs around the time of the alert for any other suspicious activities or related events that could provide additional context.
-- Review network activity logs to identify any unusual outbound connections or data transfers initiated by the suspicious process.
-- Consult threat intelligence sources to determine if the process name or behavior is associated with known malware or adversary techniques.
-
-### False positive analysis
-
-- Legitimate administrative tools: Some legitimate administrative tools and processes, such as certain system maintenance or monitoring applications, may require SeDebugPrivilege to function correctly. These tools might trigger the detection rule if they are not included in the exclusion list. Users can handle these by identifying and adding these tools to the exclusion list based on their file paths or process names.
-- Software updates and installations: During software updates or installations, processes like msiexec.exe may temporarily enable SeDebugPrivilege. These processes are typically benign and can be excluded by ensuring their paths are included in the exclusion list.
-- System maintenance tasks: Scheduled tasks or system maintenance activities, such as those performed by cleanmgr.exe or MRT.exe, might also enable SeDebugPrivilege. Users should verify the legitimacy of these tasks and exclude them if they are part of routine system operations.
-- Custom scripts or applications: In environments where custom scripts or applications are used for system management, these might require elevated privileges. Users should review these scripts or applications and, if deemed safe, add them to the exclusion list to prevent false positives.
-- Security software: Some security software may use SeDebugPrivilege to perform deep system scans or other protective measures. Users should confirm the legitimacy of such software and exclude it from the detection rule if necessary.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Investigate the process that enabled SeDebugPrivilege by reviewing logs and identifying the parent process and any associated files or network connections.
-- Terminate any suspicious processes that have been identified as enabling SeDebugPrivilege without legitimate justification.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious software.
-- Review and analyze security logs to determine if there are any other systems that may have been compromised or are exhibiting similar suspicious behavior.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process creation and privilege escalation events for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and improve detection capabilities.
-- Restore the system to its operational state by applying the latest security patches, updating software, and ensuring all security configurations are hardened.
-- Educate users and administrators on the importance of maintaining least privilege principles and regularly reviewing privilege assignments to prevent unauthorized privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
index 895078f3548..fc2f865bcc9 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/28"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,48 +43,6 @@ process where host.os.type == "windows" and event.type == "start" and process.na
   /* CLSID of the Elevated COM Interface IEditionUpgradeManager */
   process.parent.args : "/Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface
-
-User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. The IEditionUpgradeManager COM interface can be exploited by attackers to bypass UAC, allowing them to execute code with elevated privileges without user consent. This detection rule identifies such attempts by monitoring for the execution of the ClipUp program from non-standard paths, initiated by a specific COM interface process, indicating potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the ClipUp.exe process execution from a non-standard path, as indicated by the process.executable field.
-- Verify the parent process information to ensure it matches dllhost.exe, and check the process.parent.args for the specific CLSID {BD54C901-076B-434E-B6C7-17C531F4AB41} to confirm the use of the IEditionUpgradeManager COM interface.
-- Use Osquery to list all running processes and identify any suspicious processes that may have been spawned by ClipUp.exe. Example query: `SELECT pid, name, path, parent FROM processes WHERE name = 'Clipup.exe';`
-- Investigate the origin of the ClipUp.exe file by checking its file properties, such as creation date and digital signature, to determine if it is a legitimate or potentially malicious file.
-- Examine the system's event logs, particularly the Security and Application logs, for any related events around the time of the alert to gather additional context on the activity.
-- Check for any recent changes in user account privileges or group memberships that could indicate an attempt to escalate privileges.
-- Investigate any network connections initiated by ClipUp.exe or its parent process to identify potential command and control communication or data exfiltration.
-- Review the system's scheduled tasks and startup items to identify any persistence mechanisms that may have been established by the attacker.
-- Analyze any recent software installations or updates that could have introduced the rogue ClipUp.exe file, focusing on software installed around the time of the alert.
-- Correlate this alert with other security alerts or incidents in the environment to determine if this is part of a larger attack campaign.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger this detection if they use the ClipUp program from non-standard paths as part of their process. Users should verify the source and purpose of such installations to determine if they are benign.
-- System administrators or IT personnel might use scripts or tools that inadvertently mimic the behavior of a UAC bypass attempt. In such cases, ensure these activities are documented and authorized.
-- Some enterprise environments may have custom applications that utilize the ClipUp program for legitimate purposes. These should be reviewed and, if deemed safe, added to an exception list to prevent false alarms.
-- To manage false positives, users can create exceptions in their monitoring tools for known safe processes or paths that frequently trigger this rule. This can be done by specifying trusted parent processes or executable paths in the detection rule configuration.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing logs and identifying any unauthorized changes or suspicious activities.
-- Terminate any malicious processes associated with the ClipUp program running from non-standard paths.
-- Remove any unauthorized or malicious files and restore any altered system files from a known good backup.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
-- Implement enhanced logging policies to capture detailed process execution and COM interface usage, ensuring future attempts are detected promptly.
-- Integrate security information and event management (SIEM) solutions to correlate events and provide comprehensive threat visibility.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for UAC bypass.
-- Educate users on the importance of UAC prompts and encourage reporting of any unexpected or suspicious prompts.
-- Review and update security policies and hardening measures, such as restricting COM interface access and enforcing least privilege principles, to prevent similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
index 20a5a5ec323..216891dbd73 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,51 +45,6 @@ process where host.os.type == "windows" and event.type == "start" and
  /* uncomment once in winlogbeat */
  /* and not (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) */
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer
-
-User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. Adversaries exploit elevated COM interfaces, like the Internet Explorer Add-On Installer, to bypass UAC and execute malicious code with higher privileges. The detection rule identifies such attempts by monitoring specific process behaviors, such as the execution of temporary files with a parent process linked to the installer, indicating potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a process execution event where the executable path matches the pattern `C:\\\\*\\\\AppData\\\\*\\\\Temp\\\\IDC*.tmp\\\\*.exe` and the parent process is `ieinstal.exe` with arguments `-Embedding`.
-- Verify the legitimacy of the parent process `ieinstal.exe` by checking its file path and hash against known good values or threat intelligence databases.
-- Investigate the process tree to understand the sequence of events leading to the execution of the suspicious temporary executable. Look for any unusual parent or sibling processes.
-- Examine the command-line arguments of the parent process `ieinstal.exe` to identify any anomalies or unexpected parameters that could indicate malicious intent.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command-line arguments:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE 'C:\\\\%\\\\AppData\\\\%\\\\Temp\\\\IDC%.tmp\\\\%.exe';
-  ```
-- Check the code signature of the suspicious executable and its parent process to determine if they are signed by a trusted entity. If the signature is missing or untrusted, it may indicate malicious activity.
-- Investigate the network activity associated with the suspicious process to identify any external connections or data exfiltration attempts. Use network logs or tools like Wireshark for deeper analysis.
-- Review recent system changes or user activities that might have led to the execution of the suspicious process, such as software installations or updates.
-- Correlate the alert with other security events or logs from the same host or user account to identify any patterns or additional indicators of compromise.
-- Consult with threat intelligence sources or community forums to determine if the observed behavior matches any known UAC bypass techniques or malware campaigns.
-
-### False positive analysis
-
-- Legitimate software installations or updates that use the Internet Explorer Add-On Installer may trigger this detection rule, as they can create temporary executable files in the specified directory. Users should verify the legitimacy of the software being installed or updated to determine if it is a false positive.
-- System administrators may encounter false positives when deploying software through automated scripts or management tools that utilize the same COM interface for legitimate purposes. In such cases, adding exceptions for known and trusted software deployment tools can help reduce noise.
-- Some enterprise environments may have custom applications that interact with the Internet Explorer Add-On Installer for legitimate reasons. Identifying these applications and excluding their specific process signatures can prevent unnecessary alerts.
-- To manage false positives, users can create exceptions by adding specific process paths or signatures to an allowlist, ensuring that only verified and trusted processes are excluded from detection. This approach helps maintain security while reducing false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing the process execution details and correlating with other security logs.
-- Terminate any suspicious processes identified during the investigation, particularly those matching the pattern of temporary files executed with "ieinstal.exe" as the parent process.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Remove any unauthorized or malicious software identified during the investigation and ensure the system is free from malware.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify the integrity of system files.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate security solutions such as endpoint detection and response (EDR) tools to improve visibility and detection capabilities.
-- Educate users on the risks of UAC bypass techniques and encourage reporting of any suspicious activity.
-- Review and update security policies and hardening measures, such as restricting the use of elevated COM interfaces and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
index 323b94b0b42..1f75e4522af 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,48 +41,6 @@ process where host.os.type == "windows" and event.type == "start" and
  process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and
  process.pe.original_file_name != "WerFault.exe"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 UAC Bypass via ICMLuaUtil Elevated COM Interface
-
-The ICMLuaUtil Elevated COM Interface is a component in Windows that facilitates certain processes to run with elevated privileges, bypassing User Account Control (UAC) prompts. Adversaries exploit this by invoking specific COM objects to execute code stealthily with higher permissions. The detection rule identifies such bypass attempts by monitoring processes initiated by `dllhost.exe` with specific arguments, excluding legitimate system processes, to flag potential privilege escalation activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the specific `dllhost.exe` process with the arguments `/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}` or `/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}` to ensure it matches the UAC bypass signature.
-- Check the process tree to identify the parent process of `dllhost.exe` to understand the origin of the execution and determine if it is a legitimate system process or a suspicious one.
-- Investigate the user account under which the `dllhost.exe` process was executed to determine if it aligns with expected user behavior or if it indicates potential compromise.
-- Use Osquery to gather additional context about the `dllhost.exe` process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'dllhost.exe';`
-- Examine the command-line arguments of the `dllhost.exe` process to identify any unusual or unexpected parameters that could indicate malicious activity.
-- Cross-reference the `process.pe.original_file_name` field to ensure it is not `WerFault.exe`, which is excluded from the detection rule, to validate the alert.
-- Analyze recent system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that could be related to the UAC bypass attempt.
-- Check for any recent changes or installations on the system that could have introduced the potential for UAC bypass, such as new software or updates.
-- Investigate network activity from the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
-- Review historical alerts and incidents involving the same host or user account to identify patterns or repeated attempts of privilege escalation or other suspicious activities.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the detection rule as they sometimes use the ICMLuaUtil Elevated COM Interface for necessary elevated operations. Users should verify the source and purpose of the process to determine if it is benign.
-- System maintenance tools or scripts that require elevated permissions might also be flagged. Users can create exceptions for these tools by adding them to an allowlist based on their file hash or specific command-line arguments.
-- Certain administrative tasks performed by IT personnel, such as system configuration changes, may inadvertently match the detection criteria. Organizations can manage these by documenting and excluding known administrative activities from the rule.
-- Automated system processes that are part of the operating system's normal functioning could occasionally be misidentified. Users should monitor these processes and, if consistently identified as false positives, adjust the detection rule to exclude them by specifying additional conditions or exceptions.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing logs and correlating with other security events.
-- Terminate any suspicious processes initiated by dllhost.exe that match the identified arguments to stop potential malicious activity.
-- Escalate the incident to the security operations team for a deeper analysis and to determine if other systems are affected.
-- Review and enhance logging policies to ensure comprehensive monitoring of COM object invocations and UAC bypass attempts.
-- Implement additional security controls, such as application whitelisting, to prevent unauthorized execution of elevated processes.
-- Restore the system to its operational state by removing any malicious code or unauthorized changes and applying necessary security patches.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on the risks of UAC bypass techniques and the importance of adhering to security best practices.
-- Consider integrating threat intelligence feeds and security information and event management (SIEM) solutions to improve detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
index c2802e39231..b967a003284 100644
--- a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/02"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,49 +60,6 @@ process where host.os.type == "windows" and event.type == "start" and
         "\\Device\\HarddiskVolume?\\Windows\\System32\\taskhostw.exe"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 UAC Bypass via DiskCleanup Scheduled Task Hijack
-
-User Account Control (UAC) is a security feature in Windows that helps prevent unauthorized changes by prompting for permission or an administrator password. Adversaries may exploit scheduled tasks like DiskCleanup to bypass UAC, executing code with elevated privileges. The detection rule identifies suspicious processes using specific arguments and executables, excluding legitimate system paths, to flag potential UAC bypass attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious process arguments `/autoclean` and `/d` in conjunction with the process start event.
-- Verify the executable path of the process to ensure it does not match any of the legitimate system paths listed in the detection rule.
-- Check the parent process of the suspicious executable to understand how it was initiated and assess if it aligns with expected behavior.
-- Investigate the user account under which the suspicious process was executed to determine if it has administrative privileges or a history of unusual activity.
-- Use Osquery to list all scheduled tasks on the system and identify any modifications or unusual entries related to DiskCleanup. Example query: `SELECT * FROM scheduled_tasks WHERE name LIKE '%DiskCleanup%';`
-- Examine the system's event logs, particularly the Security and System logs, for any related entries that might provide additional context or corroborate the suspicious activity.
-- Analyze the file hash of the suspicious executable using threat intelligence sources to determine if it is associated with known malicious activity.
-- Investigate any network connections initiated by the suspicious process to identify potential command and control communication or data exfiltration.
-- Review recent changes to the system, such as software installations or updates, that might explain the presence of the suspicious executable.
-- Correlate the findings with other alerts or incidents in the environment to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Legitimate software updates or maintenance tools may trigger the detection rule if they use similar command-line arguments and executables not listed in the exclusion paths. Users should verify the source and purpose of such processes to determine if they are benign.
-- Custom scripts or administrative tools developed in-house that automate disk cleanup tasks might also be flagged. Users can manage these by adding the specific executable paths of trusted scripts to the exclusion list.
-- Scheduled tasks created by IT departments for routine maintenance that mimic the DiskCleanup process could be misidentified. To handle this, users should document and exclude these known tasks from the detection rule.
-- Security software or system optimization tools that perform disk cleanup operations might inadvertently match the rule's criteria. Users should confirm the legitimacy of these tools and consider excluding their executables if they are verified as safe.
-- In environments with non-standard system configurations, legitimate system processes might reside in different paths. Users should adjust the exclusion list to accommodate these variations by adding the correct paths for their specific setup.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify any unauthorized changes or additional malicious activities on the system, focusing on processes and scheduled tasks.
-- Terminate any suspicious processes identified during the investigation that are not part of legitimate system operations.
-- Review and restore any altered scheduled tasks to their default configurations, ensuring no unauthorized tasks remain.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and scheduled task changes, aiding in future detection and investigation efforts.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze potential threats in real-time.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for UAC bypass.
-- Educate users on the importance of UAC prompts and the risks associated with bypassing them, reinforcing security awareness.
-- Consider deploying application whitelisting and endpoint detection and response (EDR) solutions to prevent unauthorized code execution and improve threat visibility."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
index 4832780b218..8e26acb0697 100644
--- a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/27"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,50 +46,6 @@ file where host.os.type == "windows" and event.type : "change" and process.name
   /* has no impact on rule logic just to avoid OS install related FPs */
   not file.path : ("C:\\Windows\\SoftwareDistribution\\*", "C:\\Windows\\WinSxS\\*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 UAC Bypass Attempt via Privileged IFileOperation COM Interface
-
-The IFileOperation COM interface is a Windows component that facilitates file operations with elevated privileges. Adversaries exploit this by side-loading malicious DLLs into processes like dllhost.exe, which run with high integrity levels, to bypass User Account Control (UAC). The detection rule identifies such attempts by monitoring changes in specific DLLs known for side-loading, excluding benign paths to reduce false positives.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a UAC bypass attempt by checking if the process name is "dllhost.exe" and the file name matches any of the known side-loaded modules such as "wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", or "Accessibility.ni.dll".
-- Verify the file path to ensure it does not match benign paths like "C:\\\\Windows\\\\SoftwareDistribution\\\\*" or "C:\\\\Windows\\\\WinSxS\\\\*" to rule out false positives related to OS installations.
-- Use process monitoring tools to trace the parent process of "dllhost.exe" to identify how it was initiated and whether it was spawned by a legitimate process or a suspicious one.
-- Check the integrity level of the "dllhost.exe" process to confirm it is running with high or system integrity, which is necessary for a successful UAC bypass.
-- Investigate recent file modifications or creations in the directories where the suspicious DLLs were detected to identify any unauthorized changes or additions.
-- Utilize Osquery to gather more context about the system state and running processes. For example, run the following Osquery query to list all processes with high integrity levels: `SELECT pid, name, path, uid, gid FROM processes WHERE integrity_level = 'high';`
-- Examine the system's event logs, particularly the Security and Application logs, for any unusual activity or errors around the time the alert was triggered.
-- Check for any network connections initiated by "dllhost.exe" to external IP addresses, which could indicate data exfiltration or command and control communication.
-- Review the system's scheduled tasks and startup items to identify any persistent mechanisms that could be used to reinitiate the UAC bypass.
-- Correlate the findings with other security alerts or incidents in the environment to determine if this is part of a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate software updates or installations that modify DLLs in monitored paths, such as Windows updates or third-party software installations.
-- System maintenance tasks, like disk cleanup or system restore operations, might also trigger alerts due to changes in DLLs, especially in directories like `C:\\Windows\\SoftwareDistribution\\` or `C:\\Windows\\WinSxS\\`.
-- To manage these false positives, users can create exceptions for specific file paths or processes known to perform legitimate operations, ensuring these are well-documented and reviewed regularly.
-- Implementing a whitelist for trusted software that frequently updates or modifies DLLs can help reduce unnecessary alerts while maintaining security.
-- Regularly updating the detection rule to include new benign paths or processes identified during routine monitoring can further minimize false positives.
-- Users should ensure that any exclusions do not inadvertently allow malicious activity by carefully analyzing the context and behavior of the processes involved.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to confirm the UAC bypass attempt by reviewing security logs and identifying any unauthorized changes or suspicious activities associated with the identified DLLs.
-- Terminate any suspicious processes, particularly those involving dllhost.exe with the identified side-loaded DLLs, to stop the execution of potentially malicious code.
-- Remove any unauthorized or malicious DLLs from the system and restore legitimate versions from a trusted source or backup.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed file and process activity, focusing on high-integrity processes and known side-loading DLLs.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar UAC bypass attempts in the future.
-- Review and update user account control (UAC) settings and policies to ensure they are configured to the highest security level appropriate for the environment.
-- Conduct a security audit of the system to identify and address any other vulnerabilities or misconfigurations that could be exploited for privilege escalation.
-- Educate users and administrators on the risks of UAC bypass techniques and the importance of maintaining secure configurations and practices."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unquoted_service_path.toml b/rules/windows/privilege_escalation_unquoted_service_path.toml
index 3efe2d4556b..a5d975e7816 100644
--- a/rules/windows/privilege_escalation_unquoted_service_path.toml
+++ b/rules/windows/privilege_escalation_unquoted_service_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/13"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,49 +43,6 @@ process where host.os.type == "windows" and event.type == "start" and
     process.executable regex """(C:\\Program Files \(x86\)\\|C:\\Program Files\\)\w+.exe"""
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Exploitation of an Unquoted Service Path Vulnerability
-
-Unquoted service paths in Windows can be exploited by adversaries to gain elevated privileges. When a service path lacks quotes and contains spaces, Windows may execute a malicious executable placed in a higher-level directory. The detection rule identifies suspicious process executions by monitoring for executables named "Program.exe" or those in common program directories, indicating potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific executable path that triggered the alert, focusing on the `process.executable` field.
-- Verify the existence of the suspicious executable (e.g., "Program.exe") in the specified directory by manually navigating to the path on the affected host.
-- Use Osquery to list all services with unquoted paths on the host to identify potential vulnerabilities. Example query: `SELECT name, path FROM services WHERE path LIKE '% %' AND path NOT LIKE '"%"';`
-- Check the file creation and modification timestamps of the suspicious executable to determine when it was placed in the directory.
-- Investigate the parent process of the suspicious executable using the `process.parent` field to understand how it was initiated.
-- Examine the user account context under which the suspicious process was executed to assess potential privilege escalation.
-- Review recent system logs and security events around the time of the alert for any anomalous activities or related events.
-- Conduct a file integrity check on the directory containing the suspicious executable to identify any unauthorized changes.
-- Analyze network connections initiated by the suspicious process to detect any potential communication with external hosts.
-- Cross-reference the alert with other security tools and logs to gather additional context and corroborate findings.
-
-### False positive analysis
-
-- Known false positives may include legitimate applications that are poorly configured with unquoted service paths but do not pose a security threat. These applications might inadvertently trigger the detection rule due to their executable names or locations.
-- System administrators can handle these false positives by creating exceptions for specific executables that are known to be safe. This can be done by adding these executables to an allowlist or by modifying the detection rule to exclude certain paths or executable names.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening applications are excluded, maintaining a balance between security and operational efficiency.
-- Consider monitoring the behavior of excluded applications to ensure they do not exhibit any unexpected or malicious activity over time, as threat landscapes can change.
-- Engage with application vendors to address unquoted service path issues in their software, reducing the potential for false positives and improving overall security posture.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
-- Conduct a thorough investigation to identify any malicious executables named "Program.exe" or located in common program directories, as indicated by the detection rule.
-- Review the service paths of all services on the affected system to identify any unquoted paths and correct them by adding quotes around the executable paths.
-- Remove any unauthorized or malicious executables found during the investigation to prevent further execution.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and parent-child process relationships, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all services have correctly quoted paths.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update security policies and procedures accordingly.
-- Educate users and administrators on the importance of secure service configurations and the risks associated with unquoted service paths to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
index 2ac94219cc2..99d0b03ae20 100644
--- a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
+++ b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,52 +64,6 @@ process where host.os.type == "windows" and event.type == "start" and
     "?:\\Program Files (x86)\\GPLGS\\gswin32c.exe"
  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Print Spooler Child Process
-
-The Print Spooler service, integral to Windows environments, manages print jobs by interacting with printer hardware. Adversaries exploit this service to escalate privileges, leveraging vulnerabilities to execute unauthorized processes. The detection rule identifies anomalies by monitoring child processes spawned by the spooler, excluding known benign activities, and focusing on those with elevated integrity levels, signaling potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific child process of `spoolsv.exe` was flagged, focusing on the `process.name` and `process.command_line` fields.
-- Verify the integrity level of the process using the `process.Ext.token.integrity_level_name` or `winlog.event_data.IntegrityLevel` fields to confirm if it is running with elevated privileges.
-- Cross-reference the `process.name` and `process.command_line` against known benign processes and command lines to rule out false positives.
-- Check the parent process details to ensure that `spoolsv.exe` is the legitimate parent and not a masqueraded process.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all child processes of `spoolsv.exe`:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'spoolsv.exe');
-  ```
-- Investigate the file path and hash of the executable using the `process.executable` field to determine if it matches known malicious files or has been altered.
-- Examine the system's event logs around the time of the alert for any related suspicious activities or anomalies.
-- Check for any recent changes or installations on the system that could have introduced the unusual process, focusing on software updates or new applications.
-- Review network activity from the host to identify any unusual outbound connections that might indicate data exfiltration or command and control communication.
-- Consult threat intelligence sources to see if the process or command line has been associated with known attack patterns or campaigns.
-
-### False positive analysis
-
-- Known false positives include legitimate processes that are commonly spawned by the Print Spooler service but are not associated with malicious activity. These include processes like "splwow64.exe", "PDFCreator.exe", "acrodist.exe", "spoolsv.exe", "msiexec.exe", "route.exe", and "WerFault.exe".
-- Exclusions are in place for command lines that involve typical system paths or operations, such as those involving the Windows system drivers directory or common network and system configuration commands.
-- Users can manage false positives by adding exceptions for specific processes or command lines that are known to be safe in their environment. This can be done by modifying the detection rule to include additional exclusions based on observed benign behavior.
-- It is important to regularly review and update the list of exclusions to ensure that new legitimate processes are not mistakenly flagged as threats, especially after system updates or changes in the environment.
-- Users should also consider the context of the detected process, such as the time of execution and the user account under which it was run, to better assess whether it is likely to be a false positive.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the compromise, focusing on the unusual child processes spawned by spoolsv.exe.
-- Review system logs and security events to gather evidence and understand the attack vector, leveraging MITRE ATT&CK framework details for T1068 to identify exploitation patterns.
-- Terminate any unauthorized or suspicious processes identified during the investigation to contain the threat.
-- Apply the latest security patches and updates to the Windows operating system and Print Spooler service to mitigate known vulnerabilities.
-- Restore the system from a clean backup if available, ensuring that the backup is free from compromise.
-- Implement enhanced logging policies to capture detailed process creation events and integrity level changes for future investigations.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to improve threat detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on secure printing practices and the importance of applying security updates promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
index 010c24ed347..12e5a8b5448 100644
--- a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
+++ b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,48 +64,6 @@ process where host.os.type == "windows" and event.type == "start" and
     ) and process.parent.args : "imgsvc"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Service Host Child Process - Childless Service
-
-Service Host (svchost.exe) is a critical Windows process that hosts multiple services. Some services, known as "childless," typically do not spawn child processes. Adversaries may exploit this by injecting malicious code into these services to escalate privileges or evade detection. The detection rule identifies anomalies by monitoring for unexpected child processes from these "childless" services, flagging potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific child process and parent service involved, focusing on the `process.name` and `process.parent.args` fields.
-- Verify the legitimacy of the parent service by checking the `process.parent.args` against known childless services to confirm if the service should indeed be childless.
-- Examine the command-line arguments of the child process using the `process.args` field to identify any suspicious or unusual parameters that may indicate malicious activity.
-- Check the executable path of the child process using the `process.executable` field to determine if it resides in a legitimate directory, such as `?:\\Windows\\System32\\` or `?:\\Program Files\\`.
-- Investigate the process creation time and user context to determine if the process was created during unusual hours or by an unexpected user.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes with their parent process IDs and command-line arguments: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = '<child_process_name>';`.
-- Cross-reference the child process with known good or bad hashes using threat intelligence sources to determine if the executable is known to be malicious.
-- Analyze recent system logs and events around the time of the alert to identify any other suspicious activities or related events.
-- Check for any network connections initiated by the child process using network monitoring tools to identify potential C2 communication.
-- Review the system's security and application logs for any signs of exploitation or privilege escalation attempts that may correlate with the alert.
-
-### False positive analysis
-
-- **WerFault.exe, WerFaultSecure.exe, wermgr.exe**: These processes are related to Windows Error Reporting and may occasionally be spawned by svchost.exe during legitimate error handling scenarios. Users can exclude these processes from triggering alerts by adding them to the exception list.
-- **RelPost.exe with WdiSystemHost**: This executable may be launched by the WdiSystemHost service under certain conditions, such as system diagnostics or performance data collection. Users should monitor the context of these executions and consider excluding them if they are part of routine system operations.
-- **rundll32.exe with winethc.dll and WdiServiceHost**: This combination might occur during legitimate network configuration changes or diagnostics. Users can exclude this specific execution pattern if it is verified as part of normal system behavior.
-- **Executables under Program Files or Kodak directories with imgsvc**: These may be legitimate processes related to image processing or Kodak software operations. Users should verify the legitimacy of these processes and exclude them if they are consistently identified as non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation to identify the source of the unusual child process, focusing on recent changes or suspicious activities.
-- Utilize forensic tools to capture memory and disk images for deeper analysis of potential code injection or exploitation.
-- Terminate any suspicious processes identified as child processes of svchost.exe that are not typically expected.
-- Review and analyze security logs to trace the origin of the attack and identify any other potentially compromised systems.
-- Apply patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Restore the system from a known good backup if malicious activity is confirmed and cannot be remediated.
-- Implement enhanced logging policies to capture detailed process creation events and network activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as disabling unnecessary services and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_ppid_spoofing.toml b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
index 2bb8025781e..57c9603c900 100644
--- a/rules/windows/privilege_escalation_via_ppid_spoofing.toml
+++ b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -95,53 +95,6 @@ process where host.os.type == "windows" and event.action == "start" and
     )
  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privileges Elevation via Parent Process PID Spoofing
-
-Parent Process ID (PPID) spoofing is a technique where attackers manipulate the PPID of a process to disguise its origin, often to gain elevated privileges or evade detection. By altering the PPID, adversaries can make malicious processes appear as if they were spawned by legitimate, trusted processes. The detection rule identifies such spoofing by monitoring process creation events, specifically looking for anomalies in parent-child process relationships and excluding known legitimate processes and signatures to reduce false positives. This helps in identifying unauthorized privilege escalation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process triggered the rule, focusing on the `process.name`, `process.executable`, and `process.parent.executable` fields to identify the suspicious process and its parent.
-- Check the `process.parent.Ext.real.pid` field to verify if the parent process ID has been spoofed and assess the legitimacy of the parent process.
-- Investigate the `user.id` field to determine if the process is attempting to escalate privileges to SYSTEM, which could indicate malicious intent.
-- Examine the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to verify the authenticity of the process's digital signature and identify any discrepancies.
-- Cross-reference the `process.executable` and `process.parent.executable` paths against known legitimate software paths to rule out false positives.
-- Utilize Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and user IDs:
-  ```sql
-  SELECT pid, name, path, parent, uid FROM processes WHERE pid = <suspicious_process_pid>;
-  ```
-- Analyze historical process creation events to identify any patterns or anomalies in parent-child relationships that could suggest further spoofing attempts.
-- Investigate any network connections initiated by the suspicious process using network monitoring tools to identify potential command and control communication.
-- Review system logs for any other unusual activities or errors around the time the alert was triggered, which might provide additional context or evidence of compromise.
-- Consult threat intelligence sources to determine if the process or its parent is associated with known malware or attack campaigns, providing further insight into the potential threat.
-
-### False positive analysis
-
-- The rule may trigger false positives when legitimate processes are involved in activities that resemble PPID spoofing, such as software updates or system utilities that spawn processes with elevated privileges. 
-- Common false positives include processes related to Windows Error Reporting (WerFault.exe, Wermgr.exe) and Windows Update (MpSigStub.exe, wuauclt.exe) which are known to exhibit behavior similar to PPID spoofing during normal operations.
-- Third-party software like remote support tools (TeamViewer, LogMeIn) and accessibility utilities (Utilman.exe spawning osk.exe, Narrator.exe, Magnify.exe) can also generate false positives due to their legitimate use of elevated privileges.
-- To manage these false positives, users can create exceptions by excluding specific process paths or code signatures from the detection rule. This involves adding known legitimate processes and their parent-child relationships to the exclusion list.
-- Users should regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate software that may trigger the rule.
-- It is crucial to verify the trustworthiness of the code signatures associated with excluded processes to prevent adversaries from exploiting these exceptions.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the PPID spoofing, including reviewing process creation logs and correlating with known attack patterns.
-- Terminate any malicious processes identified during the investigation to stop ongoing threats.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if sensitive data may have been compromised.
-- Restore the system to a known good state using backups or system restore points, ensuring that all malicious changes are removed.
-- Implement enhanced logging policies to capture detailed process creation events and parent-child process relationships for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Review and update security policies and access controls to minimize the risk of privilege escalation through PPID spoofing.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users and administrators on recognizing signs of privilege escalation and the importance of reporting suspicious activities promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
index 248d51aa7d6..05672066a7b 100644
--- a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
+++ b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/13"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,52 +51,6 @@ file where host.os.type == "windows" and event.action : "Pipe Created*" and
  /* normal sysmon named pipe creation events truncate the pipe keyword */
   file.name : "\\*\\Pipe\\*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Privilege Escalation via Rogue Named Pipe Impersonation
-
-Named pipes facilitate inter-process communication in Windows environments, allowing data exchange between processes. Adversaries exploit this by creating rogue named pipes, tricking privileged processes into connecting and escalating privileges. The detection rule identifies suspicious named pipe creation events, focusing on patterns indicative of impersonation attempts, thus flagging potential privilege escalation activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a named pipe creation event with the pattern "\\\\*\\\\Pipe\\\\*" on a Windows host, as indicated by the query.
-- Correlate the event with the specific host and timestamp to identify the process that created the named pipe. Check for any unusual or unauthorized processes running on the host.
-- Investigate the parent process of the named pipe creation event to determine if it is a legitimate process or potentially malicious. Use process lineage data to trace back the process tree.
-- Examine the user context under which the named pipe was created. Verify if the user has legitimate reasons to perform such actions or if there are signs of compromised credentials.
-- Utilize Osquery to gather additional context about the processes involved. For example, run the following Osquery query to list all named pipes and their associated processes:
-  ```sql
-  SELECT name, pid, path FROM pipes WHERE path LIKE '\\\\%\\\\Pipe\\\\%';
-  ```
-- Check for any recent privilege escalation attempts or access token manipulation activities on the host, as these may be related to the named pipe impersonation.
-- Analyze network activity from the host around the time of the event to identify any suspicious connections or data exfiltration attempts.
-- Review system logs and security events for any other indicators of compromise or related suspicious activities on the host.
-- Investigate any other alerts or anomalies associated with the same host or user account to determine if this is part of a broader attack campaign.
-- Document all findings and maintain a timeline of events to assist in understanding the scope and impact of the potential privilege escalation attempt.
-
-### False positive analysis
-
-- Legitimate software and system processes may create named pipes that match the detection pattern, leading to false positives. For example, certain enterprise applications or system management tools might use named pipes for legitimate inter-process communication.
-- Regularly occurring named pipe creation by trusted applications can be excluded by creating exceptions in the detection rule. This involves identifying the specific named pipes or processes that are known to be safe and adding them to an allowlist.
-- System administrators should monitor and document normal named pipe activity within their environment to distinguish between benign and suspicious behavior. This documentation can help refine detection rules and reduce false positives.
-- Consider the context of the named pipe creation event, such as the user account and process involved. If the event is associated with a known and trusted process, it may be safe to exclude it from alerts.
-- Implement a review process for flagged events to ensure that legitimate activities are not being incorrectly classified as threats, which can help in adjusting the detection parameters over time.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to identify the source of the rogue named pipe and determine if any other systems are compromised.
-- Terminate any suspicious processes associated with the rogue named pipe to stop ongoing malicious activities.
-- Review and analyze logs from Sysmon and other security tools to gather evidence and understand the scope of the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited.
-- Implement enhanced logging policies to capture detailed named pipe creation events and other relevant security events for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all malicious artifacts are removed.
-- Harden the system by disabling unnecessary services, applying least privilege principles, and conducting regular security audits to prevent future attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_token_theft.toml b/rules/windows/privilege_escalation_via_token_theft.toml
index f7d7f5de92f..4e4c0049a82 100644
--- a/rules/windows/privilege_escalation_via_token_theft.toml
+++ b/rules/windows/privilege_escalation_via_token_theft.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -98,53 +98,6 @@ not (process.parent.executable : "?\\Windows\\System32\\spoolsv.exe" and
                  "Cisco WebEx LLC", 
                  "Dell Inc"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Created with an Elevated Token
-
-In Windows environments, processes can be created with elevated tokens to perform tasks requiring higher privileges. Adversaries exploit this by impersonating system-level processes to escalate privileges and bypass security controls. The detection rule identifies suspicious process creations by monitoring for processes running as SYSTEM, excluding known legitimate activities, and focusing on potential token theft scenarios. This helps in identifying unauthorized privilege escalations.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process was created with an elevated token, focusing on the `process.executable` and `process.parent.executable` fields.
-- Verify the `user.id` field to confirm the process is running as SYSTEM (S-1-5-18), indicating potential privilege escalation.
-- Examine the `process.Ext.effective_parent.executable` field to identify the parent process and determine if it is a known target for token theft.
-- Check the `process.code_signature.trusted` and `process.code_signature.subject_name` fields to assess if the process has a trusted signature, which might indicate a false positive.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with elevated tokens:
-  ```sql
-  SELECT pid, name, path, uid, gid, on_disk, wired_size FROM processes WHERE uid = 0;
-  ```
-- Investigate the command-line arguments of the process using the `process.parent.args` field to identify any unusual or suspicious parameters.
-- Correlate the process creation event with other logs, such as authentication logs, to identify any anomalous user activity around the time of the alert.
-- Check for any recent changes or updates in the system that might explain the process creation, focusing on the `process.parent.executable` paths.
-- Review historical data to determine if this process creation pattern has occurred previously and if it correlates with any known malicious activity.
-- Consult threat intelligence sources to see if the process or its parent is associated with known adversary techniques or campaigns.
-
-### False positive analysis
-
-- Known false positives include processes initiated by legitimate system maintenance tasks or software updates that require elevated privileges, such as Windows Update processes or system diagnostics tools.
-- Processes related to Windows core binaries like `Utilman.exe` in debug mode or `spoolsv.exe` associated with Access Intelligent Form can trigger false positives.
-- Windows error reporting tools like `WerFault.exe` and `WerMgr.exe` may also be flagged, despite being legitimate.
-- Software installations or updates using `msiexec.exe` or processes under `DriverStore` can be mistakenly identified as threats.
-- Trusted applications with valid code signatures from known vendors such as TeamViewer, Cisco WebEx, or Dell may be incorrectly flagged.
-- Users can manage these false positives by creating exceptions for known legitimate processes and paths in their monitoring tools, ensuring that frequent non-threatening behaviors are excluded from triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to confirm the legitimacy of the process creation and identify any unauthorized privilege escalation attempts.
-- Review system logs and security alerts to gather evidence of the attack vector and any associated malicious activities.
-- Terminate any suspicious processes running with elevated privileges that are not part of legitimate system operations.
-- Change all potentially compromised credentials, especially those with administrative privileges, to prevent further unauthorized access.
-- Restore the system from a known good backup if malicious activity is confirmed and the system integrity is compromised.
-- Implement enhanced logging policies to capture detailed process creation events and access token manipulations for future investigations.
-- Integrate security solutions with threat intelligence feeds to improve detection capabilities and correlate alerts with known threat actors.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Apply system hardening measures, such as enforcing least privilege access, enabling multi-factor authentication, and regularly updating software to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
index 0f0dfff831d..758b1a47d47 100644
--- a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
+++ b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/02/07"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,49 +64,6 @@ configuration where host.os.type == "windows" and
     "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" "
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows Service Installed via an Unusual Client
-
-Windows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges, often from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations from atypical client processes, excluding known legitimate services, to spot potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand which client process triggered the service installation and note the `winlog.event_data.ClientProcessId` and `winlog.event_data.ParentProcessId` fields for further context.
-- Verify the legitimacy of the client process by checking its file path, hash, and digital signature to ensure it is not a known malicious or suspicious executable.
-- Use Osquery to list all services on the host and identify any newly created or modified services. Example query: `SELECT name, display_name, path, start_type, status FROM services WHERE path LIKE '%<suspicious_path>%';`
-- Investigate the parent process using the `winlog.event_data.ParentProcessId` to determine if it is a known legitimate process or if it has any suspicious characteristics.
-- Cross-reference the `winlog.event_data.ServiceFileName` with known legitimate service paths to ensure it is not a false positive.
-- Check the system's event logs for any additional activities around the time of the service installation, focusing on process creation, network connections, and user logins.
-- Analyze the timeline of events leading up to and following the service installation to identify any patterns or anomalies in user or process behavior.
-- Investigate the user account associated with the service installation to determine if it has been compromised or is exhibiting unusual activity.
-- Review any recent changes to the system's configuration or installed software that could explain the unusual service installation.
-- Consult threat intelligence sources to determine if the client process or service file name is associated with known malware or attack campaigns.
-
-### False positive analysis
-
-- Known false positives for this rule include legitimate software installations or updates that create services using atypical client processes. Examples include software deployment tools or system management utilities that may not follow standard service installation procedures.
-- Users can handle these false positives by creating exceptions for known legitimate services. This can be done by adding the specific service file paths or client process identifiers to the exclusion list within the detection rule.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new legitimate services that may trigger the rule.
-- Consider implementing a process to verify the legitimacy of flagged services by cross-referencing with software inventory or change management records to distinguish between benign and potentially malicious activities.
-- Engage with IT and security teams to identify any new software deployments or updates that could result in false positives, ensuring these are documented and accounted for in the rule configuration.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the service by checking the service name, file path, and associated process against known software and threat intelligence databases.
-- Terminate any suspicious processes associated with the unusual client process that installed the service.
-- Remove the malicious service and any associated files from the system to prevent re-execution.
-- Conduct a thorough investigation of the system to identify any additional indicators of compromise or persistence mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process creation and service installation events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Harden the system by enforcing least privilege principles, disabling unnecessary services, and implementing application whitelisting to prevent unauthorized service installations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_wpad_exploitation.toml b/rules/windows/privilege_escalation_wpad_exploitation.toml
index b86f393f1d8..4ce6d2b03c5 100644
--- a/rules/windows/privilege_escalation_wpad_exploitation.toml
+++ b/rules/windows/privilege_escalation_wpad_exploitation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "development"
-updated_date = "2025/01/08"
+updated_date = "2024/04/08"
 
 [rule]
 author = ["Elastic"]
@@ -38,49 +38,6 @@ sequence with maxspan=5s
   [process where host.os.type == "windows" and event.type == "start" and
      process.parent.name : "svchost.exe"] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WPAD Service Exploit
-
-The Web Proxy Auto-Discovery Protocol (WPAD) helps devices on a network automatically find a proxy server. Adversaries can exploit WPAD by injecting malicious scripts into the service, potentially compromising systems. The detection rule identifies suspicious WPAD activity by monitoring specific processes and network behaviors, such as DNS queries and unauthorized script execution, to flag potential exploits.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the WPAD Service Exploit by checking the sequence of events, particularly focusing on the `process.entity_id` and `process.parent.entity_id` fields to trace the process lineage.
-- Examine the DNS queries for the "wpad" domain by analyzing the `dns.question.name` field to identify any unusual or unauthorized requests that could indicate malicious activity.
-- Investigate the network activity associated with `svchost.exe` by reviewing the `network.direction` and `destination.port` fields to ensure that the outgoing traffic on port 80 is legitimate and expected.
-- Check the execution of `jscript.dll` by `svchost.exe` using the `dll.name` field to determine if there is any unauthorized script execution that could be part of the exploit.
-- Use Osquery to gather additional context on the `svchost.exe` process. Example query: `SELECT pid, name, path, cmdline FROM processes WHERE name = 'svchost.exe';` to verify the command line arguments and path for any anomalies.
-- Correlate the `user.domain` and `user.name` fields to ensure that the process is running under the expected user context, specifically "NT AUTHORITY\\LOCAL SERVICE", and investigate any deviations.
-- Analyze the parent-child process relationship using the `process.parent.name` field to identify any unusual process spawning from `svchost.exe` that could indicate exploitation.
-- Review historical logs for similar patterns of activity involving `svchost.exe` and `jscript.dll` to determine if this is an isolated incident or part of a broader attack pattern.
-- Investigate any other network connections initiated by `svchost.exe` around the time of the alert to identify potential command and control communication or data exfiltration attempts.
-- Cross-reference the alert with other security tools and logs to gather additional context and corroborate findings, focusing on any indicators of compromise related to privilege escalation or exploitation attempts.
-
-### False positive analysis
-
-- Legitimate network configurations may trigger the WPAD Service Exploit rule, such as environments where WPAD is used for legitimate proxy configuration. In such cases, frequent DNS queries for "wpad" and subsequent network activity may be normal and not indicative of an exploit.
-- Automated software updates or network management tools that utilize WPAD for configuration purposes can also generate similar patterns of activity, leading to false positives.
-- To manage these false positives, users can create exceptions for known benign processes or network behaviors by whitelisting specific DNS queries or network traffic patterns associated with trusted applications.
-- Monitoring and logging should be adjusted to differentiate between expected WPAD traffic and potentially malicious activity, ensuring that only suspicious deviations from the norm are flagged.
-- Regularly review and update the exclusion list to accommodate changes in network infrastructure or software updates that may alter legitimate WPAD usage patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation and lateral movement.
-- Conduct a thorough investigation to confirm the exploitation by reviewing DNS logs, network traffic, and process execution details related to WPAD activity.
-- Terminate any suspicious processes associated with svchost.exe that are not part of legitimate system operations.
-- Remove any unauthorized scripts or injected code found within the WPAD service or related processes.
-- Apply security patches and updates to the operating system and any vulnerable services to mitigate the exploitation risk.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging and monitoring for DNS queries, network traffic, and process execution to detect similar threats in the future.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore the system to its operational state by reinstalling affected services and verifying the integrity of system files.
-- Harden the network by disabling WPAD if not needed, enforcing strict access controls, and educating users on the risks associated with automatic proxy discovery."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_archive_data_zip_imageload.toml b/rules_building_block/collection_archive_data_zip_imageload.toml
index fbca435582b..445af055e36 100644
--- a/rules_building_block/collection_archive_data_zip_imageload.toml
+++ b/rules_building_block/collection_archive_data_zip_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -52,52 +52,6 @@ library where host.os.type == "windows" and event.action == "load" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Compression DLL Loaded by Unusual Process
-
-Compression DLLs, like those in the .NET framework, facilitate data compression and decompression, crucial for efficient storage and transfer. Adversaries exploit these DLLs to compress data before exfiltration, masking their activities. The detection rule identifies unusual processes loading these DLLs, excluding trusted applications, to flag potential misuse indicative of data exfiltration attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process that triggered the rule, focusing on the `process.executable` and `process.name` fields to understand which application attempted to load the compression DLL.
-- Verify the legitimacy of the process by checking the `process.code_signature.trusted` field. If the signature is not trusted, prioritize this alert for further investigation.
-- Investigate the user context under which the process was executed by examining the `user.id` field. Determine if the user is expected to run such processes and if their activity aligns with their role.
-- Cross-reference the process path with known trusted applications and environments. If the path is unusual or not listed in the exclusion criteria, it may warrant further scrutiny.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes that have loaded the specified DLLs:
-  ```sql
-  SELECT pid, name, path FROM processes WHERE path LIKE '%System.IO.Compression%';
-  ```
-- Check the process's parent process to understand the chain of execution. This can provide insights into whether the process was spawned by a legitimate application or a potentially malicious one.
-- Analyze recent file modifications and network connections initiated by the process to identify any suspicious data exfiltration activities.
-- Review system logs and other security tools for any correlated alerts or anomalies around the same timeframe to build a comprehensive picture of the event.
-- Investigate any recent changes or updates to the system that might explain the unusual process behavior, such as new software installations or updates.
-- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or DLLs in question, which could provide additional context for the alert.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate applications that are not included in the predefined exclusion list but still load compression DLLs as part of their normal operations. These could include custom or third-party applications that use .NET compression libraries for legitimate data processing tasks.
-- Users can handle these false positives by identifying and documenting the legitimate applications that trigger the rule. Once identified, these applications can be added to the exclusion list by specifying their executable paths and ensuring their code signatures are trusted.
-- Another potential false positive source is system maintenance or administrative scripts that utilize compression DLLs for routine data management tasks. Users should verify the legitimacy of these scripts and, if deemed safe, exclude them from the rule.
-- Regularly review and update the exclusion list to accommodate new trusted applications or changes in existing applications' behavior, ensuring that only genuine threats are flagged while minimizing false positives.
-- Consider the context of the flagged event, such as the user account involved and the process's typical behavior, to determine if the activity is expected or warrants further investigation.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further data exfiltration and lateral movement.
-- Conduct a thorough investigation to identify the source of the unusual process loading the compression DLL, focusing on recent changes or suspicious activities.
-- Review and analyze logs from the affected system and any associated network traffic to identify potential data exfiltration attempts.
-- Terminate any suspicious processes identified during the investigation that are not part of the trusted applications list.
-- Remove any unauthorized or malicious software discovered during the investigation and ensure all security patches are up to date.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat actor is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process execution and DLL loading events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensure that all security controls are re-enabled.
-- Apply system hardening measures, such as restricting DLL loading paths and enforcing application whitelisting, to reduce the attack surface and prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_common_compressed_archived_file.toml b/rules_building_block/collection_common_compressed_archived_file.toml
index ff8372ed089..8cbf9f55494 100644
--- a/rules_building_block/collection_common_compressed_archived_file.toml
+++ b/rules_building_block/collection_common_compressed_archived_file.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = "endpoint"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -110,51 +110,6 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
    )
  )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File Compressed or Archived into Common Format
-
-File compression and archiving are essential for efficient data storage and transfer, using formats like ZIP, RAR, and 7-Zip. However, adversaries exploit these technologies to obfuscate malicious files or stage data for exfiltration. The detection rule identifies suspicious compression activities by monitoring file creation or modification events, excluding trusted processes, and analyzing file headers for known compression signatures.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file and process involved, focusing on fields like `file.name`, `file.path`, and `process.name`.
-- Verify the legitimacy of the process by checking the `process.code_signature.subject_name` and `process.code_signature.trusted` fields to ensure the process is signed and trusted.
-- Investigate the user context by examining the `user.id` field to determine if the activity was performed by a legitimate user or a system account.
-- Check the file header bytes (`file.Ext.header_bytes`) to confirm the type of compression or archive format used and cross-reference with known malicious signatures.
-- Use Osquery to gather additional context about the file and process. For example, run the following query to list recent file modifications by the process:
-  ```sql
-  SELECT path, size, atime, mtime FROM file WHERE path = 'C:\\\\Path\\\\To\\\\Suspicious\\\\File' OR path LIKE 'C:\\\\Path\\\\To\\\\Suspicious\\\\Directory\\\\%';
-  ```
-- Investigate the parent process of the suspicious activity by examining `process.parent.name` and `process.parent.executable` to understand the process lineage.
-- Analyze network activity associated with the process using network monitoring tools to identify any potential data exfiltration attempts.
-- Cross-reference the file path and process name with known indicators of compromise (IOCs) from threat intelligence sources.
-- Review system logs and security events around the time of the alert to identify any correlated suspicious activities or anomalies.
-- If applicable, check for any recent changes in the system or application configurations that might explain the compression activity, such as scheduled tasks or software updates.
-
-### False positive analysis
-
-- Trusted applications like Mozilla Firefox, Wazuh Agent, Microsoft Office Suite (Excel, Word, PowerPoint), OneDrive, Dropbox, Dell SupportAssist, and IIS may trigger false positives when they perform legitimate compression or archiving activities. These applications are often involved in routine operations that involve file compression, such as saving documents in compressed formats or creating temporary compressed files for performance optimization.
-- To manage these false positives, users can create exceptions for these trusted processes by verifying their code signatures and ensuring they are from recognized and trusted publishers. This can be done by adding specific conditions to exclude these processes from triggering alerts, as shown in the detection rule.
-- Users should regularly review and update the list of trusted applications and processes to ensure that new legitimate applications are not mistakenly flagged. This involves monitoring for any changes in application behavior or updates that might affect how files are compressed or archived.
-- It is important to maintain a balance between security and usability by carefully selecting which processes to exclude, ensuring that only well-known and verified applications are exempted from the rule to prevent potential security risks.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further data exfiltration or lateral movement.
-- Verify the legitimacy of the process that triggered the alert by checking its code signature and cross-referencing with known trusted applications.
-- Conduct a thorough investigation of the compressed or archived files to determine if they contain malicious content or sensitive data staged for exfiltration.
-- Review recent file creation and modification events on the system to identify any unauthorized or suspicious activities.
-- If malicious files are confirmed, remove them and any associated processes or services from the system.
-- Restore any affected files from a known good backup to ensure system integrity and operational continuity.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is determined to be part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed file and process activities, aiding in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface and prevent similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
index bbaea2c1f5c..9ac96708907 100644
--- a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
+++ b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,49 +41,6 @@ file where host.os.type == "windows" and event.type == "creation" and
   not file.path : "?:\\$RECYCLE.BIN\\*\\*" and
   not file.name : "desktop.ini"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File Staged in Root Folder of Recycle Bin
-
-The Recycle Bin in Windows is designed to temporarily store deleted files, allowing users to recover them if needed. Adversaries may exploit this by placing files directly in the root of the Recycle Bin to prepare for data exfiltration or to bypass security measures. The detection rule identifies such suspicious activity by monitoring file creation events in the root directory, excluding typical system files, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file creation event in the root of the Recycle Bin, focusing on the `file.path` and `file.name` fields to identify the suspicious file.
-- Verify the timestamp of the file creation event to determine when the activity occurred and correlate it with other events on the system.
-- Check the user account associated with the file creation event to identify who might have created or moved the file to the Recycle Bin.
-- Investigate the file's origin by examining recent file access and modification events on the system to trace back its source.
-- Use Osquery to list all files in the Recycle Bin, including their metadata, to gather more context about the file. Example query: `SELECT path, filename, size, atime, mtime FROM file WHERE directory LIKE 'C:\\\\$RECYCLE.BIN\\\\%' AND NOT directory LIKE 'C:\\\\$RECYCLE.BIN\\\\%\\\\%';`
-- Analyze the file's content and metadata to determine its nature and potential sensitivity, using file hashing and comparison against known malicious signatures if necessary.
-- Cross-reference the file's hash with threat intelligence databases to check for known malicious files.
-- Review system logs and security events around the time of the file creation for any signs of suspicious activity or anomalies.
-- Investigate any network connections or data transfers initiated by the host around the time of the file creation to identify potential exfiltration attempts.
-- Consult with the user or system owner to verify if the file placement was intentional or authorized, and gather any additional context they might provide.
-
-### False positive analysis
-
-- System or application updates may temporarily create files in the root of the Recycle Bin, leading to false positives. Users can monitor update schedules and correlate these events to rule out threats.
-- Certain backup or recovery software might use the Recycle Bin for temporary storage, triggering the detection rule. Identifying and excluding these specific software behaviors can reduce false alerts.
-- User actions such as manually moving files to the Recycle Bin root for organizational purposes can be mistaken for malicious activity. Educating users on proper file management practices can help minimize these occurrences.
-- Automated scripts or maintenance tasks that interact with the Recycle Bin might inadvertently place files in the root directory. Reviewing and adjusting these scripts to use subdirectories can prevent false positives.
-- To manage these false positives, users can create exceptions in the detection rule for known benign file paths or processes, ensuring that only genuinely suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential data exfiltration.
-- Verify the legitimacy of the file by checking its origin, creation time, and associated user account.
-- Conduct a thorough investigation to determine if the file is part of a larger attack, using endpoint detection and response (EDR) tools.
-- Remove the suspicious file from the Recycle Bin and perform a full system scan using updated antivirus and anti-malware software.
-- Review recent user activity and access logs to identify any unauthorized access or anomalies.
-- Escalate the incident to the security operations center (SOC) or incident response team if the file is confirmed to be malicious or part of a targeted attack.
-- Implement enhanced logging policies to capture detailed file creation and modification events, especially in sensitive directories.
-- Integrate threat intelligence feeds to improve detection capabilities and correlate with known indicators of compromise (IOCs).
-- Restore the system to its operational state by ensuring all security patches are applied and verifying system integrity.
-- Harden the system by enforcing least privilege access, disabling unnecessary services, and regularly reviewing security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_outlook_email_archive.toml b/rules_building_block/collection_outlook_email_archive.toml
index 4c08108c07c..921f2861096 100644
--- a/rules_building_block/collection_outlook_email_archive.toml
+++ b/rules_building_block/collection_outlook_email_archive.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,49 +44,6 @@ process where host.os.type == "windows" and event.type == "start" and process.ar
         process.args : "*davclnt.dll,DavSetCookie*"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Accessing Outlook Data Files
-
-Outlook data files, such as OST and PST, store emails and other data locally on Windows systems. Adversaries may target these files to collect sensitive information, bypassing email server security. The detection rule identifies suspicious processes accessing these files, excluding legitimate Outlook operations, to flag potential unauthorized access or data exfiltration attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process triggered the rule, focusing on the `process.name` and `process.args` fields to identify the suspicious activity.
-- Check the `host.os.type` to confirm the operating system is Windows, as the rule is specific to Windows systems.
-- Investigate the `event.type` to ensure it is a "start" event, indicating the initiation of a process that accessed the Outlook data files.
-- Examine the `process.args` field to identify the specific OST or PST files being accessed and determine if they contain sensitive or critical information.
-- Verify the legitimacy of the process by checking the `process.name` against known legitimate applications that might access Outlook data files, excluding "outlook.exe" and the specific "rundll32.exe" with "davclnt.dll,DavSetCookie" arguments.
-- Use Osquery to gather more context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve details like process path, parent process, and user context.
-- Investigate the parent process of the suspicious activity to determine if it was spawned by a legitimate application or another potentially malicious process.
-- Check the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised.
-- Review recent system logs and security events for any other suspicious activities or anomalies around the time the alert was triggered.
-- Correlate the findings with other alerts or incidents in the environment to identify any patterns or potential indicators of a broader attack campaign.
-
-### False positive analysis
-
-- Known false positives may include legitimate applications or scripts that access Outlook data files for backup or synchronization purposes, such as third-party email clients or backup software.
-- System administrators can handle these false positives by creating exceptions for known and trusted applications that regularly access OST and PST files, ensuring these are documented and reviewed periodically.
-- Users should monitor for any unusual patterns or unexpected applications accessing these files, as this could indicate a potential security risk despite being initially classified as a false positive.
-- Regularly update the list of exceptions to include new legitimate applications as they are identified, while ensuring that these exceptions do not inadvertently allow malicious activity.
-- Consider implementing additional monitoring or logging for processes that frequently trigger the rule to better understand their behavior and confirm their legitimacy.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access to OST and PST files.
-- Review system and security logs to trace the origin of the suspicious process and identify any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Remove any malicious software or unauthorized tools found on the system, ensuring that all traces of the threat actor's presence are eradicated.
-- Restore the system from a known good backup, ensuring that all security patches and updates are applied before reconnecting to the network.
-- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Educate users on the importance of email security and the risks associated with unauthorized access to email data files.
-- Review and update access controls and permissions related to email data files, ensuring that only authorized personnel have access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_posh_compression.toml b/rules_building_block/collection_posh_compression.toml
index 3e58fd4d9aa..5b1150f75d0 100644
--- a/rules_building_block/collection_posh_compression.toml
+++ b/rules_building_block/collection_posh_compression.toml
@@ -5,7 +5,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 
 
 [rule]
@@ -70,48 +70,6 @@ not powershell.file.script_block_text : (
 ) and
 not file.directory : "C:\Program Files\Microsoft Dependency Agent\plugins\lib"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Archive Compression Capabilities
-
-PowerShell, a powerful scripting language in Windows, includes capabilities for file compression using various .NET classes and cmdlets. Adversaries exploit these to compress and encrypt data for exfiltration. The detection rule identifies suspicious use of compression methods and cmdlets, excluding known legitimate activities, to flag potential data exfiltration attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific PowerShell script block text triggered the alert, focusing on the use of compression methods like "IO.Compression.ZipFile" or cmdlets like "Compress-Archive".
-- Check the event logs for the process category to identify the user account and host involved in the activity, using the `event.category:process` and `host.os.type:windows` fields.
-- Investigate the script block text to determine if the compression activity is part of a known legitimate process or if it appears suspicious, especially if it involves unusual directories or file paths.
-- Examine the command line arguments and script content for any signs of obfuscation or attempts to hide the true intent of the script.
-- Use Osquery to gather more context about the process by running a query like: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%IO.Compression%'`.
-- Cross-reference the timestamp of the alert with other security events on the host to identify any correlated activities, such as network connections or file modifications.
-- Check for any recent changes in the file system, especially in directories not excluded by the rule, to identify any compressed files that may have been created.
-- Investigate the network activity from the host around the time of the alert to detect any potential data exfiltration attempts.
-- Review the history of PowerShell execution on the host to identify any patterns or repeated use of compression methods that could indicate malicious behavior.
-- Consult threat intelligence sources to determine if the observed behavior matches any known tactics, techniques, or procedures (TTPs) associated with adversaries using PowerShell for data exfiltration.
-
-### False positive analysis
-
-- Legitimate software updates or system maintenance tasks may trigger the rule, such as Lenovo diagnostics using compression for log files. Users can handle these by adding specific paths or script block text to the exclusion list.
-- Backup solutions like Ansible may use compression methods for routine operations. Users should identify and exclude these by recognizing specific script block text patterns associated with these tools.
-- Microsoft Dependency Agent plugins might use compression for legitimate purposes. Excluding the directory "C:\\Program Files\\Microsoft Dependency Agent\\plugins\\lib" can prevent false positives related to this activity.
-- Regularly review and update exclusion lists to ensure they reflect current legitimate activities, minimizing the risk of overlooking genuine threats while reducing false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration.
-- Conduct a thorough investigation of the PowerShell script logs to identify the source and scope of the compression activity.
-- Verify if any unauthorized data access or exfiltration has occurred by reviewing network logs and data transfer records.
-- Remove any malicious scripts or files identified during the investigation from the affected system.
-- Apply security patches and updates to the operating system and any vulnerable applications to prevent exploitation of known vulnerabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and module logging, for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and detect similar threats in real-time.
-- Restore the system to its operational state by reinstalling the operating system if necessary and restoring data from verified clean backups.
-- Harden the system by disabling unnecessary PowerShell features, enforcing the principle of least privilege, and implementing application whitelisting to prevent unauthorized script execution."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/command_and_control_bitsadmin_activity.toml b/rules_building_block/command_and_control_bitsadmin_activity.toml
index 9b117091f60..2b54cbba541 100644
--- a/rules_building_block/command_and_control_bitsadmin_activity.toml
+++ b/rules_building_block/command_and_control_bitsadmin_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,48 +49,6 @@ process where host.os.type == "windows" and event.type == "start" and
    )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Bitsadmin Activity
-
-Windows Background Intelligent Transfer Service (BITS) facilitates low-bandwidth file transfers, often used for updates. Adversaries exploit BITS to persistently download and execute malicious payloads, leveraging its ability to operate in the background. The detection rule identifies suspicious BITS usage by monitoring specific command-line arguments in processes like `bitsadmin.exe` and `powershell.exe`, which are indicative of potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name (`bitsadmin.exe` or `powershell.exe`) and the command-line arguments that triggered the alert. This will help determine the nature of the suspicious activity.
-- Check the process start time and correlate it with other events on the system to identify any unusual patterns or activities around the same time.
-- Investigate the parent process of the suspicious `bitsadmin.exe` or `powershell.exe` process to understand how it was initiated. This can provide insights into whether the process was started by a legitimate application or a potentially malicious script.
-- Examine the user account associated with the process to determine if the activity aligns with the user's typical behavior or if it might indicate compromised credentials.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all BITS jobs on the system: `SELECT * FROM bits_jobs;` This can help identify any ongoing or completed BITS transfers that may be related to the alert.
-- Analyze network connections established by the suspicious process to identify any unusual or unauthorized external communications. This can help determine if data exfiltration or command and control activity is occurring.
-- Review the system's event logs for any additional indicators of compromise or related activities, such as failed login attempts, privilege escalation, or other suspicious processes.
-- Check for any recent file modifications or new files created on the system that could be associated with the suspicious BITS activity, indicating potential payloads or scripts.
-- Investigate any scheduled tasks or startup items that might have been created or modified to persist the malicious activity, especially if the `SetNotifyCmdLine` argument was used.
-- Consult threat intelligence sources to determine if the observed command-line arguments or network indicators match known malicious campaigns or tools, providing further context for the investigation.
-
-### False positive analysis
-
-- Legitimate software updates or patch management systems may trigger the Bitsadmin Activity rule, as they often use BITS for downloading updates, which can be mistaken for malicious activity.
-- System administrators or IT personnel using scripts to automate file transfers or system maintenance tasks might inadvertently match the rule's criteria, leading to false positives.
-- To manage these false positives, users can create exceptions for known and trusted processes or scripts by whitelisting specific command-line arguments or process names that are frequently used in legitimate operations.
-- Regularly review and update the list of exceptions to ensure that only verified and non-threatening activities are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Analyze the process tree and command-line arguments associated with the suspicious BITS activity to understand the scope and intent of the attack.
-- Terminate any malicious processes identified, such as those initiated by bitsadmin.exe or powershell.exe with suspicious arguments.
-- Remove any unauthorized or malicious BITS jobs using the bitsadmin tool or PowerShell cmdlets to prevent further execution.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
-- Review and enhance logging policies to ensure detailed monitoring of BITS activities and PowerShell executions, including command-line arguments.
-- Implement application whitelisting to prevent unauthorized use of bitsadmin.exe and restrict PowerShell script execution to signed scripts only.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
-- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied.
-- Educate users on recognizing and reporting suspicious activities, and consider conducting a security awareness training session focused on phishing and social engineering tactics."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
index 0d7927fcf41..1eed992f989 100644
--- a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
+++ b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
@@ -5,7 +5,7 @@ integration = ["endpoint", "windows", "system"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 
 [rule]
 author = ["Elastic"]
@@ -47,48 +47,6 @@ process where host.os.type == "windows" and event.type == "start" and
    (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and
    process.args : "list" and process.args : "/text*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft IIS Service Account Password Dumped
-
-Microsoft IIS is a web server technology that uses service accounts for application pools, which can be managed via the AppCmd command-line tool. Adversaries with access to the server might exploit AppCmd to extract and decrypt these service account passwords, potentially leading to unauthorized access. The detection rule identifies suspicious use of AppCmd by monitoring for specific command-line arguments indicative of password dumping activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the `appcmd.exe` process with the specific arguments `list` and `/text*` to ensure the alert is not a false positive.
-- Check the process execution context, including the user account under which `appcmd.exe` was executed, to determine if it aligns with expected administrative activity.
-- Investigate the parent process of `appcmd.exe` to identify how it was initiated and whether it was triggered by a legitimate administrative tool or a suspicious script or process.
-- Examine the host's security logs for any recent login events or anomalies around the time `appcmd.exe` was executed to identify potential unauthorized access.
-- Use Osquery to gather additional context on the process execution by running a query such as: `SELECT * FROM processes WHERE name = 'appcmd.exe' AND cmdline LIKE '%list%/text*%';` to verify the command-line arguments and execution details.
-- Analyze network logs to identify any unusual outbound connections from the host that might indicate data exfiltration following the password dump.
-- Review recent changes to IIS configuration files and application pool settings to detect any unauthorized modifications that could be related to the alert.
-- Check for the presence of web shells or other malicious files on the IIS server that could have been used to execute `appcmd.exe`.
-- Correlate the alert with other security events or alerts from the same host or network segment to identify potential lateral movement or coordinated attacks.
-- Consult threat intelligence sources to determine if there are known campaigns or threat actors associated with similar tactics, techniques, and procedures (TTPs) involving IIS and `appcmd.exe`.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use AppCmd to manage IIS configurations, including listing application pools and their properties, which can trigger the rule. To handle this, identify and document regular maintenance schedules and exclude these activities from alerts during those times.
-- Automated scripts: Some organizations use automated scripts for IIS management that might include commands similar to those flagged by the rule. Review and whitelist these scripts by creating exceptions based on specific command-line arguments or script paths.
-- Monitoring and auditing tools: Security and monitoring tools might execute AppCmd commands as part of their regular checks. Verify the legitimacy of these tools and exclude their known processes from triggering alerts.
-- Development and testing environments: In non-production environments, developers might frequently use AppCmd for testing purposes. Consider excluding these environments from the rule or adjusting the sensitivity of alerts based on the environment type.
-
-### Response and remediation
-
-- Immediately isolate the affected server from the network to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the extent of the compromise, focusing on identifying any additional compromised accounts or systems.
-- Review server logs and AppCmd usage history to identify unauthorized access patterns and potential entry points.
-- Change all service account passwords associated with the IIS server and ensure they follow strong password policies.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for IIS servers, including command-line activity and access logs, to detect future unauthorized actions.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze security events across the network.
-- Apply security patches and updates to the IIS server and related software to mitigate known vulnerabilities.
-- Conduct a security review of the IIS server configuration and apply hardening measures, such as disabling unnecessary services and enforcing least privilege access.
-- Educate and train IT staff on recognizing and responding to similar threats, leveraging MITRE ATT&CK framework details for context on credential dumping techniques."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_mdmp_file_creation.toml b/rules_building_block/credential_access_mdmp_file_creation.toml
index 69041206444..938d4cba5ab 100644
--- a/rules_building_block/credential_access_mdmp_file_creation.toml
+++ b/rules_building_block/credential_access_mdmp_file_creation.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -76,50 +76,6 @@ file where host.os.type == "windows" and event.type == "creation" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Credential Access via Memory Dump File Creation
-
-Memory dump files capture the state of a process's memory, often used for debugging. Adversaries exploit this by creating dumps to extract sensitive data, like credentials. The detection rule identifies suspicious dump file creation on Windows systems, focusing on files with specific headers and sizes, while excluding trusted processes and paths, to flag potential credential access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the "4d444d50" header in the file, indicating a memory dump file.
-- Verify the file size to ensure it meets the threshold of 30,000 bytes or more, which aligns with the rule's criteria for medium-sized dumps.
-- Check the process name and executable path to determine if the process is listed as a trusted process or path in the exclusion list.
-- Investigate the process code signature to confirm whether it is marked as trusted, which might indicate a false positive.
-- Examine the file path to see if it matches any of the excluded directories, such as "?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\WER\\\\*" or "?:\\\\Users\\\\*\\\\AppData\\\\*\\\\CrashDumps\\\\*".
-- Use Osquery to gather additional context about the process that created the dump file. For example, run the following query to list processes with their command line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE path LIKE 'C:\\\\Windows\\\\System32\\\\%' OR path LIKE 'C:\\\\Program Files\\\\%';`
-- Check the system's event logs for any related events around the time of the dump file creation to identify any suspicious activities or anomalies.
-- Investigate the user account associated with the process to determine if it has the necessary privileges to create memory dumps and if the activity aligns with normal behavior.
-- Analyze network activity from the host to identify any unusual outbound connections that might suggest data exfiltration attempts.
-- Correlate the alert with other security events or alerts from the same host or user to identify patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Memory dump files created by legitimate system processes such as Windows Error Reporting (WER) can trigger false positives. These processes are often involved in crash reporting and diagnostics, which are benign activities.
-- Trusted third-party applications, like Zoom, may generate memory dumps for crash analysis, leading to false positives. These applications are typically signed and can be verified through their code signatures.
-- System administrators or developers might intentionally create memory dumps for debugging purposes, which should be considered non-threatening if performed by authorized personnel.
-- To manage these false positives, users can refine the detection rule by adding exceptions for known trusted processes and paths, ensuring that only suspicious activities are flagged.
-- Regularly update the list of trusted applications and paths based on organizational needs and software updates to minimize unnecessary alerts.
-- Implement a review process for flagged events to verify the legitimacy of the memory dump creation, allowing for the adjustment of rules and exceptions as needed.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the memory dump file creation, focusing on any untrusted processes or unusual activity.
-- Review the process and file paths involved in the alert to determine if they align with known malicious behaviors or anomalies.
-- If malicious activity is confirmed, remove any unauthorized software or malware from the system using trusted antivirus or endpoint detection and response tools.
-- Change all potentially compromised credentials, especially those with administrative privileges, to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process creation, file access, and network activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate alerts and improve detection capabilities.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are properly set.
-- Harden the system by disabling unnecessary services, enforcing least privilege access, and regularly reviewing security policies to mitigate future risks."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
index 9e13f5bf925..666c28d4f06 100644
--- a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
+++ b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -48,52 +48,6 @@ file where host.os.type == "windows" and event.type == "creation" and
     process.name : "System" and file.extension : "tmpscan"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Memory Dump File with Unusual Extension
-
-Memory dumps capture the contents of system memory, often used for debugging or forensic analysis. Adversaries may disguise these files with atypical extensions to evade detection, potentially hiding credential dumping activities. The detection rule identifies such anomalies by checking for specific memory dump signatures and filtering out known benign processes and extensions, thus highlighting suspicious file creations.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the file path, file name, and the unusual extension used for the memory dump file.
-- Verify the file header bytes to confirm the presence of the "MDMP" signature, ensuring it matches the expected pattern "4d444d50*".
-- Check the process that created the file by examining the `process.executable` and `process.name` fields to determine if it is a known or trusted application.
-- Investigate the parent process of the file creation event to understand the process hierarchy and identify any potentially malicious parent processes.
-- Use Osquery to list all running processes and their associated command lines to identify any suspicious activities or processes that may have interacted with the memory dump file:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE path LIKE 'C:\\\\%';
-  ```
-- Examine the file creation time and correlate it with other system events or logs to identify any unusual activities or patterns around that time.
-- Check for any recent changes in the system's security settings or configurations that might have allowed the creation of such files.
-- Investigate the user account context under which the file was created to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Review network logs for any outbound connections from the host around the time of the file creation to detect potential data exfiltration attempts.
-- Cross-reference the alert with other security tools or logs to gather additional context and corroborate findings, such as endpoint detection and response (EDR) solutions or SIEM logs.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate software that generates memory dumps with non-standard extensions for internal use or debugging purposes. 
-- Security tools or monitoring software might create memory dumps with unusual extensions as part of their normal operation, which could trigger the rule.
-- Developers or IT personnel might intentionally use non-standard extensions for memory dumps during testing or troubleshooting to avoid overwriting existing files.
-- To manage these false positives, users can create exceptions for specific processes or file paths known to generate benign memory dumps with unusual extensions.
-- Users should regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the source of the memory dump file creation, focusing on processes and users involved.
-- Analyze the memory dump file to determine if sensitive information, such as credentials, has been compromised.
-- Remove any unauthorized or suspicious files and processes identified during the investigation.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Review and enhance logging policies to ensure comprehensive monitoring of file creation events and process activities.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to improve threat detection and response capabilities.
-- Restore the system from a known good backup if necessary, ensuring that the backup is free from compromise.
-- Implement hardening measures, such as enforcing least privilege access and disabling unnecessary services, to reduce the attack surface.
-- Escalate the incident to the security team or relevant authorities if the investigation reveals a significant breach or ongoing threat."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_win_private_key_access.toml b/rules_building_block/credential_access_win_private_key_access.toml
index 7c04039a85b..5cb1e8fc4d8 100644
--- a/rules_building_block/credential_access_win_private_key_access.toml
+++ b/rules_building_block/credential_access_win_private_key_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,50 +54,6 @@ process where host.os.type == "windows" and event.type == "start" and
     "?:\\Windows\\System32\\OpenSSH\\*"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Attempted Private Key Access
-
-Private keys are critical for secure authentication in environments, often used in SSH for encrypted communication. Adversaries may target these keys to gain unauthorized access. The detection rule identifies suspicious processes on Windows systems attempting to access files typically associated with private keys, while excluding legitimate applications. This helps in pinpointing potential credential access threats by filtering out benign activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process and arguments that triggered the rule, focusing on the `process.args` field to understand what files were accessed.
-- Check the `process.executable` field to determine the exact executable that attempted to access the private key files and verify if it is a known or expected application in the environment.
-- Investigate the parent process of the suspicious executable using process lineage data to understand how the process was initiated and if it was spawned by a legitimate application.
-- Use Osquery to list all processes currently running on the host that match the suspicious executable path. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE 'C:\\\\Path\\\\To\\\\Suspicious\\\\Executable\\\\%'`.
-- Examine the user context under which the suspicious process was executed by reviewing the `user.name` field to determine if it aligns with expected user behavior.
-- Analyze recent login events on the host to identify any unusual or unauthorized access patterns that might correlate with the attempted private key access.
-- Check for any recent file modifications or access events on the private key files by reviewing file system audit logs or using Osquery to query file access times.
-- Investigate network connections initiated by the suspicious process to identify any potential exfiltration attempts or communication with known malicious IP addresses.
-- Review historical data for any previous alerts or activities associated with the same executable or user to identify patterns or repeated attempts.
-- Correlate the findings with threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- Known false positives may include legitimate software or system processes that access private key files for valid reasons, such as automated updates or system maintenance tasks.
-- Applications like LogiLuUpdater.exe, osqueryd.exe, and various Guardicore agents are known to access files that match private key patterns but are typically benign.
-- Users can manage these false positives by creating exceptions for these known legitimate processes in the detection rule, ensuring they are not flagged as suspicious.
-- Regularly review and update the list of excluded executables to include any new legitimate applications that may trigger the rule.
-- Consider the context of the process execution, such as the user account under which the process runs and the frequency of access, to better assess the legitimacy of the activity.
-- Implement logging and monitoring to track any changes in behavior of these processes, which might indicate a shift from benign to potentially malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access.
-- Conduct a thorough investigation to identify the source and scope of the attempted access, focusing on the processes and files involved.
-- Review system logs and security alerts to gather additional context and evidence of the intrusion attempt.
-- Change all potentially compromised credentials, including SSH keys and any other authentication mechanisms used on the affected system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and file access events for future investigations.
-- Integrate threat intelligence feeds and security tools to improve detection capabilities and correlate alerts with known threat actors.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Implement hardening measures such as restricting access to private key files, using multi-factor authentication, and regularly rotating keys."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
index e8b14ff3105..f825349247d 100644
--- a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
+++ b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/06/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/06/25"
 
 [rule]
 author = ["Elastic"]
@@ -45,48 +45,6 @@ query = '''
 event.dataset: "aws.cloudtrail" and event.provider: "rds.amazonaws.com" 
     and event.action: ("CreateDBSnapshot" or "CreateDBClusterSnapshot") and event.outcome: "success" 
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS RDS DB Snapshot Created
-
-AWS RDS DB Snapshots are backups of databases that ensure data recovery and continuity. Adversaries may exploit this by creating snapshots to bypass access controls or revert changes, masking their activities. The detection rule monitors successful snapshot creation events in AWS CloudTrail, serving as a foundation for identifying potential misuse when correlated with other suspicious activities.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to identify the user or role associated with the `CreateDBSnapshot` or `CreateDBClusterSnapshot` event by examining the `userIdentity` field.
-- Check the `sourceIPAddress` field in the CloudTrail logs to determine the origin of the request and assess if it aligns with known IP addresses or locations for your organization.
-- Investigate the `eventTime` field to establish a timeline and correlate it with other activities or alerts that occurred around the same time.
-- Examine the `requestParameters` field to identify the specific database instance or cluster for which the snapshot was created, and assess its criticality or sensitivity.
-- Cross-reference the `userAgent` field to identify the tool or service used to initiate the snapshot creation and determine if it matches expected patterns.
-- Utilize Osquery to query AWS RDS instances and snapshots for additional context. For example, use the following Osquery query to list all RDS snapshots: `SELECT * FROM aws_rds_snapshots WHERE snapshot_create_time > 'YYYY-MM-DD HH:MM:SS';` replacing the timestamp with the relevant timeframe.
-- Investigate any recent changes to IAM policies or roles that might have granted new permissions related to RDS snapshot creation.
-- Check for any unusual or unauthorized access patterns in the AWS Management Console or API calls that could indicate compromised credentials.
-- Correlate the snapshot creation event with any recent alerts or anomalies in your security monitoring tools to identify potential patterns of malicious activity.
-- Review historical data to determine if there is a pattern of frequent snapshot creation by the same user or role, which could indicate an ongoing attempt to evade detection or maintain persistence.
-
-### False positive analysis
-
-- Routine database maintenance or backup operations by authorized personnel can trigger the AWS RDS DB Snapshot Created rule, leading to false positives. These activities are typically scheduled and documented, making them identifiable.
-- Automated backup solutions or scripts that create snapshots as part of a disaster recovery plan may also result in false positives. These should be reviewed and whitelisted if they align with organizational policies.
-- Development and testing environments often involve frequent snapshot creation for testing purposes. These environments should be monitored separately, and known non-threatening behaviors can be excluded by setting exceptions for specific user accounts or roles.
-- To manage false positives, users can create exceptions in the detection rule for specific AWS accounts, IAM roles, or IP addresses associated with legitimate snapshot creation activities. This helps in focusing on truly suspicious activities while reducing noise from expected operations.
-
-### Response and remediation
-
-- Immediately review the AWS CloudTrail logs to identify the source and context of the snapshot creation, including the user or service account involved.
-- Contain the potential threat by revoking access for the identified user or service account and reviewing their permissions to ensure least privilege.
-- Investigate any other suspicious activities associated with the same user or service account, such as unauthorized access attempts or changes to security groups.
-- If unauthorized snapshot creation is confirmed, delete the snapshot to prevent any rollback to a compromised state.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data have been affected.
-- Implement enhanced logging and monitoring for AWS RDS and related services to detect similar activities in the future, ensuring logs are retained for an appropriate period.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to correlate events and improve threat detection capabilities.
-- Restore the database to a known good state if any unauthorized changes were made, using verified snapshots or backups.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent recurrence.
-- Apply hardening measures such as enabling multi-factor authentication (MFA) for all users, regularly reviewing access permissions, and implementing network segmentation to limit access to critical resources."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
index 6b450bac8c8..45e62b40635 100644
--- a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
+++ b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,49 +40,6 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.args : "type" and process.args : (">", ">>")) or
     (process.args : "copy" and process.args : "/b"))
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Binary Content Copy via Cmd.exe
-
-Cmd.exe, a command-line interpreter on Windows, can be exploited by attackers to reconstruct binary files from fragments using commands like 'type' and 'copy' with specific arguments. This technique allows adversaries to evade detection by assembling malicious payloads directly on the target system. The detection rule identifies suspicious cmd.exe activity by monitoring for specific command patterns indicative of binary reassembly, thus alerting analysts to potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of cmd.exe activity with arguments related to 'type' and 'copy' commands, specifically looking for the use of '>' or '>>' with 'type' and '/b' with 'copy'.
-- Examine the process tree to identify the parent process of cmd.exe to understand how it was initiated and assess if it was launched by a legitimate application or script.
-- Check the user account associated with the cmd.exe process to determine if it aligns with expected user behavior or if it might be indicative of compromised credentials.
-- Investigate the file paths and names involved in the 'type' and 'copy' commands to identify if they correspond to known or suspicious binary files.
-- Utilize Osquery to gather additional context on the cmd.exe process by running a query such as: `SELECT * FROM processes WHERE name = 'cmd.exe' AND (cmdline LIKE '%type%' OR cmdline LIKE '%copy%');` to retrieve detailed command-line arguments and process metadata.
-- Analyze recent file creation and modification events on the system to identify any new or altered binaries that may have resulted from the cmd.exe activity.
-- Correlate the cmd.exe activity with network logs to check for any outbound connections that might indicate data exfiltration or command-and-control communication.
-- Review system logs for any other suspicious activities or anomalies around the time of the cmd.exe execution to identify potential lateral movement or privilege escalation attempts.
-- Check for any scheduled tasks or startup items that might have been created or modified to persist the malicious payload on the system.
-- Consult threat intelligence sources to determine if the observed cmd.exe activity matches known attack patterns or indicators of compromise associated with specific threat actors or malware families.
-
-### False positive analysis
-
-- Routine administrative tasks may trigger this rule, such as system administrators using cmd.exe to concatenate log files or other benign data files using 'type' and 'copy' commands. 
-- Automated scripts or batch files that perform legitimate file operations using cmd.exe might also be flagged, especially if they involve binary files or use the '/b' switch with 'copy'.
-- Developers or IT personnel testing or deploying software might use similar command patterns to assemble application components, leading to false positives.
-- To manage these false positives, users can create exceptions for known safe scripts or processes by whitelisting specific command patterns or file paths that are regularly used in non-threatening contexts.
-- Implementing a review process for flagged activities can help distinguish between legitimate administrative actions and potential threats, allowing for more accurate tuning of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the cmd.exe process activity, focusing on the specific command patterns identified in the detection rule.
-- Review system logs and security alerts to identify any additional indicators of compromise or related suspicious activities.
-- Utilize forensic tools to capture and analyze memory and disk images from the affected system to understand the scope and impact of the attack.
-- Remove any identified malicious binaries or payloads from the system and ensure that all associated processes are terminated.
-- Apply security patches and updates to the operating system and any vulnerable applications to mitigate exploitation risks.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging and monitoring policies to capture detailed command-line activity and process execution for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and response times.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_cmstp_execution.toml b/rules_building_block/defense_evasion_cmstp_execution.toml
index b68e35b4cb6..5e901e34f2b 100644
--- a/rules_building_block/defense_evasion_cmstp_execution.toml
+++ b/rules_building_block/defense_evasion_cmstp_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,49 +42,6 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name : "cmstp.exe" and process.args == "/s"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Defense Evasion via CMSTP.exe
-
-CMSTP.exe is a Windows utility for installing network profiles using INF files. Adversaries exploit it to execute malicious code by crafting INF files with harmful commands, bypassing security measures. The detection rule identifies suspicious activity by monitoring the execution of CMSTP.exe with specific arguments, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of CMSTP.exe execution with the "/s" argument, as this indicates a silent installation which could be suspicious.
-- Check the parent process of CMSTP.exe to determine if it was launched by a legitimate application or a potentially malicious process.
-- Investigate the user account associated with the CMSTP.exe process to verify if the activity aligns with their typical behavior or if it appears anomalous.
-- Examine the command line arguments used with CMSTP.exe to identify any unusual or unexpected parameters that could indicate malicious intent.
-- Use Osquery to list recent processes executed by the user associated with the alert to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
-- Analyze the INF file associated with the CMSTP.exe execution to check for any embedded malicious commands or scripts.
-- Review recent file modifications in directories commonly used for storing INF files to identify any unauthorized changes or suspicious files.
-- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
-- Check network logs for any unusual outbound connections initiated around the time of the CMSTP.exe execution, which could suggest data exfiltration or command and control activity.
-- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns involving CMSTP.exe.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule if they use CMSTP.exe with the "/s" argument for silent installations, which is a common practice for deploying network profiles or VPN configurations.
-- System administrators might use CMSTP.exe in scripts or automated tasks for deploying or updating network settings across multiple machines, leading to benign alerts.
-- To manage these false positives, users can create exceptions for known and trusted software installations by whitelisting specific INF files or directories from which these files are executed.
-- Monitoring the context of CMSTP.exe execution, such as the parent process or the source of the INF file, can help differentiate between legitimate and suspicious activities.
-- Regularly review and update the list of exceptions to ensure that only verified and necessary activities are excluded from alerts, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source of the malicious INF file and any other potentially compromised systems.
-- Analyze the execution context of CMSTP.exe, including the command-line arguments and associated files, to understand the scope of the attack.
-- Review and collect relevant logs, such as Windows Event Logs and security software logs, to gather evidence and trace the attacker's actions.
-- Remove any malicious files or scripts identified during the investigation and ensure that no unauthorized changes remain on the system.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
-- Implement enhanced logging and monitoring policies to detect similar activities in the future, focusing on process execution and command-line arguments.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities and correlate events.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
index 9d101bf4284..e59ad5a89c1 100644
--- a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
+++ b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -53,51 +53,6 @@ file where host.os.type == "windows" and event.action != "deletion" and
 
   not (process.executable : "?:\\Windows\\System32\\inetsrv\\w3wp.exe" and file.path : "?:\\inetpub\\temp\\IIS Temporary Compressed Files\\*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Archive File with Unusual Extension
-In computing environments, archive files are used to compress and bundle data for efficient storage and transfer. Adversaries exploit this by disguising archives with extensions typical of benign file types like images or documents, evading detection. The detection rule identifies such anomalies by checking for archive file signatures paired with unusual extensions, flagging potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific file path and extension that triggered the alert, focusing on the `file.path` and `file.extension` fields.
-- Verify the file header bytes using the `file.Ext.header_bytes` field to confirm the file is indeed an archive, despite its unusual extension.
-- Check the file creation timestamp and compare it with recent user activity to determine if the file creation aligns with legitimate user actions.
-- Investigate the process that created the file by examining the `process.executable` field to identify any suspicious or unexpected processes.
-- Use Osquery to list all files in the directory where the suspicious file was found, which can help identify other potentially malicious files:
-  ```sql
-  SELECT path, filename, extension FROM file WHERE directory = 'C:\\\\path\\\\to\\\\suspicious\\\\file\\\\directory';
-  ```
-- Analyze recent network activity from the host to detect any unusual outbound connections that might indicate data exfiltration.
-- Check the user account associated with the file creation for any signs of compromise, such as unusual login times or locations.
-- Review system logs for any recent changes or installations that could be related to the creation of the suspicious file.
-- Investigate any other alerts or incidents involving the same host or user to identify potential patterns or related activities.
-- Consult threat intelligence sources to determine if the file's characteristics match known malicious patterns or campaigns.
-
-### False positive analysis
-
-- Files generated by legitimate software that use non-standard extensions for archives, such as backup or compression tools, may trigger false positives. Users can handle these by identifying the specific software and excluding its file creation activities from the rule.
-- Web server operations, particularly those involving temporary file storage, might produce files with unusual extensions that match archive signatures. Excluding known server processes and paths, such as IIS temporary files, can reduce false positives.
-- Some enterprise applications may use custom file extensions for archives as part of their normal operation. Identifying these applications and creating exceptions for their file extensions can help minimize false alerts.
-- Multimedia editing software might save project files with extensions that resemble common media types but contain embedded archives. Users should identify these applications and exclude their specific file types from the rule.
-- Automated scripts or batch processes that generate files with non-standard extensions for internal use might be flagged. Users can manage this by excluding specific directories or processes known to produce such files.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread or data exfiltration.
-- Verify the alert by checking the file's header and extension to confirm it is a masqueraded archive file.
-- Conduct a thorough investigation to identify the source of the file and any associated processes or network connections.
-- Remove the suspicious file and any related malicious files or processes from the system.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and threat intelligence correlation.
-- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on unusual file extensions and headers.
-- Integrate threat intelligence feeds to update detection rules and improve the identification of similar threats in the future.
-- Review and update endpoint protection and intrusion detection systems to recognize and block similar masquerading attempts.
-- Conduct a security awareness training session for users to recognize and report suspicious files and activities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
index 2ef1f5c5fd3..60798ca9d0f 100644
--- a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
+++ b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -253,50 +253,6 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Communication App Child Process
-
-Communication apps like Slack, WebEx, and Teams are integral to modern workflows, facilitating seamless interaction. However, adversaries can exploit these apps by spawning unauthorized child processes, potentially masquerading as legitimate ones or exploiting vulnerabilities to execute malicious code. The detection rule identifies such anomalies by monitoring child processes of these apps, ensuring they are trusted and signed by recognized entities. This helps in spotting deviations that could indicate malicious activity, such as unexpected command executions or unsanctioned software launches, thereby safeguarding against potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific communication app and child process involved, using fields like `process.parent.name` and `process.name`.
-- Verify the legitimacy of the child process by checking the `process.executable` path and `process.code_signature.trusted` status to ensure it matches known trusted paths and signatures.
-- Examine the `process.command_line` and `process.args` fields for any unusual or unexpected command executions that could indicate malicious activity.
-- Cross-reference the `process.code_signature.subject_name` with known legitimate entities to confirm the authenticity of the process.
-- Utilize Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with their parent process IDs and command lines: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'suspicious_process_name';`
-- Investigate the parent process (`process.parent.name`) to determine if it has been compromised or if it is behaving unexpectedly.
-- Check for any recent changes or updates to the communication app that might have introduced vulnerabilities or unauthorized modifications.
-- Analyze network activity associated with the suspicious process to identify any unusual outbound connections or data exfiltration attempts.
-- Review system logs and event history around the time of the alert to identify any correlated events or anomalies that could provide additional context.
-- Consult threat intelligence sources to determine if there are any known threats or vulnerabilities associated with the specific communication app or process involved in the alert.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they spawn child processes from communication apps, as these processes might not be recognized or signed by trusted entities at the time of the update.
-- Custom scripts or automation tools that interact with communication apps could be flagged if they execute commands or launch processes that are not explicitly whitelisted.
-- Users running communication apps in non-standard directories or using portable versions might see false positives due to the rule's reliance on specific file paths for trusted executables.
-- To manage these false positives, users can create exceptions for known and verified processes by adding them to the list of trusted executables or code signatures.
-- Regularly review and update the list of trusted entities and executable paths to accommodate new software versions or organizational changes in software deployment practices.
-- Consider implementing a logging mechanism to track and analyze flagged processes, allowing for a more informed decision when creating exceptions.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation of the suspicious child process, including reviewing process trees and command-line arguments to identify any malicious behavior.
-- Verify the code signatures of the involved processes to ensure they are from trusted sources and have not been tampered with.
-- If malicious activity is confirmed, terminate the suspicious processes and remove any associated files or executables from the system.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution data and network activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected anomalies with known threat indicators and improve detection capabilities.
-- Restore the system to its operational state by applying the latest security patches and updates to the operating system and communication applications.
-- Conduct a security review of the affected applications and implement hardening measures, such as application whitelisting and least privilege access controls.
-- Educate users on recognizing and reporting suspicious activity to improve the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_dll_hijack.toml b/rules_building_block/defense_evasion_dll_hijack.toml
index 8cde72f8f6c..68d23e22874 100644
--- a/rules_building_block/defense_evasion_dll_hijack.toml
+++ b/rules_building_block/defense_evasion_dll_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -79,49 +79,6 @@ library where host.os.type == "windows" and
         "553451008520a5f0110d84192cba40208fb001c27454f946e85e6fb2e6553292"
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unsigned DLL Loaded by a Trusted Process
-
-In Windows environments, DLLs are essential for modularizing code, allowing trusted processes to load necessary functions dynamically. Adversaries exploit this by placing malicious, unsigned DLLs in directories of trusted applications, causing them to execute under the guise of legitimate processes. The detection rule identifies such anomalies by checking for unsigned DLLs loaded by trusted processes, focusing on recent file modifications and excluding known safe hashes, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the trusted process that loaded the unsigned DLL, focusing on the `process.executable` and `dll.path` fields.
-- Verify the digital signature status of the process using the `process.code_signature.status` field to confirm it is indeed trusted.
-- Check the `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` fields to determine if the DLL was recently created or modified, which could indicate suspicious activity.
-- Investigate the `dll.hash.sha256` field to see if the hash is known to be associated with malicious activity by cross-referencing with threat intelligence databases.
-- Use Osquery to list all DLLs loaded by the process in question, focusing on unsigned ones. Example query: `SELECT path, name, pid FROM processes JOIN process_open_sockets USING (pid) WHERE path LIKE '%<process_name>%' AND path NOT LIKE '%.dll';`
-- Examine the directory from which the DLL was loaded to identify any other suspicious files or recent changes, using the `dll.path` field for context.
-- Check the `user.id` field to determine which user account was associated with the process execution, looking for unusual or unauthorized accounts.
-- Investigate the `dll.Ext.device.product_id` field to see if the DLL was loaded from a virtual device, which might indicate an attempt to bypass security controls.
-- Review system logs and other security alerts around the time of the DLL loading to identify any correlated suspicious activities or patterns.
-- Consult with the application owner or system administrator to verify if the unsigned DLL is expected or part of a legitimate update or installation.
-
-### False positive analysis
-
-- Known false positives may include legitimate software updates or installations where unsigned DLLs are temporarily loaded by trusted processes. These scenarios can occur when software vendors release updates that have not yet been signed or when installation processes involve unsigned components.
-- Another potential false positive is the use of custom or in-house developed applications that may not have signed DLLs but are still trusted within the organization. These applications might load unsigned DLLs as part of their normal operation.
-- To manage these false positives, users can create exceptions for specific DLL hashes that are known to be safe but unsigned. This can be done by adding these hashes to the exclusion list in the detection rule.
-- Users can also exclude specific processes or directories from monitoring if they are known to frequently load unsigned DLLs as part of their legitimate function. This helps in reducing noise and focusing on truly suspicious activities.
-- Regularly updating the list of known safe hashes and maintaining a whitelist of trusted applications can help in minimizing false positives while ensuring that legitimate activities are not flagged as threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Verify the legitimacy of the unsigned DLL by checking its origin and purpose; if malicious, remove it from the system.
-- Conduct a thorough investigation to identify how the unsigned DLL was introduced, focusing on recent file modifications and access logs.
-- Review and update the list of known safe hashes to ensure that legitimate DLLs are not mistakenly flagged in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution and DLL loading activities for future investigations.
-- Integrate threat intelligence feeds to automatically update detection rules with the latest known malicious hashes and signatures.
-- Restore the system to its operational state by reinstalling affected applications and applying the latest security patches.
-- Conduct a security audit of the application directories to ensure no other unauthorized files are present.
-- Implement hardening measures such as application whitelisting and enforcing strict code-signing policies to prevent unauthorized DLL loading."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
index de0f1b0adde..79332fc5371 100644
--- a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
+++ b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,52 +36,6 @@ sequence by user.id with maxspan=5s
   process.name : "rundll32.exe" and process.command_line : ("*dfshim*ShOpenVerbApplication*", "*dfshim*#*")]
  [network where host.os.type == "windows" and process.name : "dfsvc.exe"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution via Microsoft DotNet ClickOnce Host
-
-Microsoft DotNet ClickOnce is a deployment technology that allows users to install and run applications by clicking a link in a web browser. Adversaries can exploit this by using trusted processes like Dfsvc.exe to execute malicious payloads, bypassing security measures. The detection rule identifies suspicious activity by monitoring for specific process executions and network activities associated with ClickOnce misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the process `rundll32.exe` with command lines containing `dfshim` and `ShOpenVerbApplication` or `#`, as these are indicative of ClickOnce misuse.
-- Check the process tree to identify the parent process of `rundll32.exe` to understand how it was initiated and if it was spawned by a legitimate application or script.
-- Investigate the network activity associated with `dfsvc.exe` to identify any unusual or unauthorized connections, focusing on external IP addresses or domains that are not typically accessed by the organization.
-- Use endpoint detection and response (EDR) tools to gather additional context on the `dfsvc.exe` process, such as its execution path, command line arguments, and any related file modifications.
-- Examine the user account (`user.id`) associated with the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Utilize Osquery to further investigate the execution context of `dfsvc.exe`. For example, run the following query to list all processes related to `dfsvc.exe`:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name = 'dfsvc.exe';
-  ```
-- Check for any recent changes or installations of ClickOnce applications on the affected host that could explain the execution of `dfsvc.exe`.
-- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may correlate with the ClickOnce execution.
-- Investigate any downloaded files or payloads associated with the ClickOnce execution to determine if they are malicious or unauthorized.
-- Correlate the findings with threat intelligence sources to identify if the observed behavior matches known attack patterns or indicators of compromise (IOCs) related to ClickOnce exploitation.
-
-### False positive analysis
-
-- Legitimate software updates or installations using ClickOnce technology may trigger the detection rule, as they often involve the execution of Dfsvc.exe and network activities similar to those of malicious payloads.
-- Internal applications deployed via ClickOnce within an organization can cause false positives if they are not properly documented or recognized by the security monitoring system.
-- Users can manage these false positives by creating exceptions for known and trusted ClickOnce applications, ensuring that their command lines and network behaviors are documented and whitelisted.
-- Regularly review and update the list of trusted ClickOnce applications to include any new internal or third-party software that is verified as safe.
-- Implement a process to verify the legitimacy of ClickOnce activities flagged by the detection rule, such as cross-referencing with software deployment schedules or consulting with IT departments.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the malicious payload.
-- Conduct a thorough investigation to identify the source of the ClickOnce misuse, focusing on recent downloads and executed applications.
-- Analyze the process tree and network connections associated with Dfsvc.exe and rundll32.exe to identify any additional malicious activities or payloads.
-- Remove any unauthorized or suspicious applications installed via ClickOnce, and ensure that all legitimate applications are up to date.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on ClickOnce-related events.
-- Integrate threat intelligence feeds to identify known indicators of compromise (IOCs) related to ClickOnce exploitation.
-- Restore the system to its operational state by reinstalling the operating system or restoring from a clean backup, ensuring all security patches are applied.
-- Educate users on the risks associated with downloading and executing applications from untrusted sources, emphasizing the importance of verifying application legitimacy.
-- Harden the environment by configuring application whitelisting policies to restrict the execution of unauthorized applications and by monitoring for unusual ClickOnce activities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_download_susp_extension.toml b/rules_building_block/defense_evasion_download_susp_extension.toml
index aa4d93a62b1..0e65e8b4c34 100644
--- a/rules_building_block/defense_evasion_download_susp_extension.toml
+++ b/rules_building_block/defense_evasion_download_susp_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -57,48 +57,6 @@ file where host.os.type == "windows" and event.type == "creation" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File with Suspicious Extension Downloaded
-
-In Windows environments, certain file extensions can be leveraged for executing code, often bypassing traditional security measures. Adversaries exploit these extensions to execute malicious payloads under the guise of legitimate files. The detection rule identifies downloads of such files from external sources, excluding known safe paths and processes, to flag potential threats. This helps in early detection of attempts to evade defenses using system binary proxy execution techniques.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file extension and path involved, focusing on the `file.extension` and `file.path` fields to determine if the file is indeed suspicious.
-- Check the `file.Ext.windows.zone_identifier` field to understand the origin of the file and confirm it was downloaded from an external source.
-- Investigate the process that created the file using the `process.name` field to determine if it is a known and trusted application.
-- Verify the digital signature of the process using the `process.code_signature.trusted` field to ensure it is from a legitimate source.
-- Cross-reference the file path against known safe paths listed in the query to rule out false positives.
-- Use Osquery to gather additional context about the file. For example, run the following query to check for recent file modifications: `SELECT * FROM file WHERE path = 'C:\\\\Path\\\\To\\\\Suspicious\\\\File';`
-- Examine the file's metadata and properties to identify any anomalies or inconsistencies that could indicate tampering or malicious intent.
-- Analyze network logs to trace the download source and determine if it is a known malicious domain or IP address.
-- Review user activity logs around the time of the file download to identify any unusual behavior or patterns that could suggest compromise.
-- Consult threat intelligence sources to check if the file hash or associated domains/IPs are linked to known threats or campaigns.
-
-### False positive analysis
-
-- **Microsoft Winget Source Files**: Downloads of files with the "msix" extension from the Microsoft Winget Source paths are known false positives. These files are part of legitimate package management operations. Users can handle these by adding exceptions for the specified paths in the detection rule.
-- **Microsoft Teams Temporary Files**: Files with the "msix" extension downloaded by the trusted "Teams.exe" process into its temporary directory are also false positives. These are typically updates or temporary files used by Microsoft Teams. Users should exclude this specific process and path combination to prevent unnecessary alerts.
-- **Legitimate Software Installations**: Some legitimate software installations may use extensions like "appinstaller" or "appx" for their setup files. Users should verify the source and context of such downloads and consider excluding known safe software sources or processes from the detection rule.
-- **System Updates and Configurations**: Files with extensions like "manifest" or "theme" may be part of system updates or user-initiated configuration changes. Users should assess the origin and purpose of these files and exclude them if they are part of routine system operations.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Conduct a thorough investigation of the downloaded file using a sandbox environment to determine its behavior and potential impact.
-- Check for any unauthorized changes or suspicious activities in the system logs and file integrity monitoring systems.
-- Remove the suspicious file and any associated malicious processes or scheduled tasks identified during the investigation.
-- Restore the system from a known good backup if any unauthorized changes or damages are detected.
-- Update antivirus and endpoint protection solutions to ensure they can detect and block similar threats in the future.
-- Implement enhanced logging policies to capture detailed file creation and modification events, especially for the identified suspicious extensions.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of similar threats.
-- Educate users on the risks of downloading files from untrusted sources and the importance of verifying file origins.
-- Review and update security policies to include hardening measures such as application whitelisting and restricting the execution of files with suspicious extensions."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
index 6437782436f..2eecbdb9c35 100644
--- a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
+++ b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -74,53 +74,6 @@ sequence with maxspan=1m
                    "*Common\\..\\..\\BuildTools\\*"))
   ] by process.parent.entity_id
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution via MS VisualStudio Pre/Post Build Events
-
-Microsoft Visual Studio allows developers to automate tasks using pre/post build events, which execute commands during the build process. Adversaries can exploit this by injecting malicious commands into these events, executing them under the guise of legitimate development activities. The detection rule identifies suspicious command executions linked to Visual Studio builds, focusing on unusual parent-child process relationships and command arguments, while excluding known benign patterns, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific process and parent process involved, focusing on `process.name`, `process.parent.name`, and `process.args` fields to identify the command executed and its context.
-- Examine the `process.entity_id` and `process.parent.entity_id` to trace the process lineage and determine if there are any unusual or unexpected parent-child relationships.
-- Check the `process.command_line` for any suspicious or unexpected command arguments that could indicate malicious activity.
-- Investigate the file path in `process.args` to verify if it matches known temporary file patterns or if it appears suspicious, such as residing in unusual directories.
-- Use Osquery to gather additional context about the processes involved. For example, run the following query to list all processes executed by MSBuild.exe:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'MSBuild.exe');
-  ```
-- Analyze the execution history of the involved processes by reviewing logs or using endpoint detection tools to identify any patterns or anomalies in their behavior.
-- Cross-reference the involved executable paths against known good or whitelisted paths to identify any deviations that could suggest tampering or unauthorized modifications.
-- Investigate the user account associated with the process execution to determine if it aligns with expected usage patterns or if it could be compromised.
-- Review any recent changes or commits to the Visual Studio project files to identify potential unauthorized modifications to pre/post build events.
-- Correlate the alert with other security events or alerts in the environment to identify if this is part of a broader attack campaign or isolated incident.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate development activities where Visual Studio projects use pre/post build events for automation, such as running scripts for deployment or configuration tasks.
-- Developers often use scripts like PowerShell or batch files in build events for tasks like copying files, setting environment variables, or generating resources, which can trigger the detection rule.
-- Frequent non-threatening behaviors include executing scripts related to version control operations, package management, or custom build tools that are part of the development workflow.
-- Users can handle these false positives by creating exceptions for specific command patterns or script paths that are known to be safe and part of the regular build process.
-- Excluding known benign patterns, such as those involving common development tools or scripts, can reduce noise and focus on truly suspicious activities.
-- It's important to regularly review and update the list of exceptions to ensure that new legitimate activities are not mistakenly flagged as threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on the Visual Studio project files and build scripts for unauthorized modifications.
-- Review and analyze the process execution logs to trace the origin of the malicious commands and identify any additional compromised systems.
-- Remove any unauthorized or suspicious pre/post build event scripts from the Visual Studio projects and restore them from a known good backup if necessary.
-- Apply patches and updates to Visual Studio and related development tools to mitigate any known vulnerabilities that could be exploited.
-- Implement strict access controls and permissions for Visual Studio projects to limit the ability to modify build scripts to authorized personnel only.
-- Enhance logging and monitoring by enabling detailed process creation and command-line logging to detect similar activities in the future.
-- Integrate security tools with SIEM solutions to correlate alerts and automate responses to suspicious activities related to build processes.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate developers and IT staff on secure coding practices and the risks associated with build process manipulation to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_file_permission_modification.toml b/rules_building_block/defense_evasion_file_permission_modification.toml
index de6fd0901ba..f58bdff58c1 100644
--- a/rules_building_block/defense_evasion_file_permission_modification.toml
+++ b/rules_building_block/defense_evasion_file_permission_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -43,49 +43,6 @@ not (
   process.args : ("C:\\ProgramData\\Lenovo\\*", "C:\\ProgramData\\Adobe\\*", "C:\\ProgramData\\ASUS\\ASUS*")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File and Directory Permissions Modification
-
-File and directory permissions in Windows environments control access and modification rights, crucial for maintaining system integrity. Adversaries exploit utilities like `icacls`, `cacls`, `takeown`, and `attrib` to alter permissions, enabling unauthorized file access or deletion. The detection rule identifies suspicious permission changes by monitoring these utilities' execution, filtering out benign processes, and focusing on potential threats, excluding known safe operations.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
-- Check the user context by examining the `user.id` field to determine if the action was performed by a legitimate user or a potential adversary.
-- Investigate the parent process using `process.parent.name` to understand the origin of the suspicious process execution.
-- Correlate the timestamp of the event with other security events to identify any related activities or anomalies around the same time.
-- Use Osquery to list recent file permission changes on the system with a query like: `SELECT path, mode, uid, gid FROM file WHERE path LIKE 'C:\\\\%' AND mode != '0644';` to identify unauthorized modifications.
-- Examine the command line arguments (`process.args`) for any unusual or unauthorized permission changes, such as granting full control (`*:F`) or resetting permissions.
-- Verify if the file or directory targeted by the permission change is critical or sensitive, which could indicate a higher risk.
-- Check for any exclusions in the query, such as known safe operations, to ensure the alert is not a false positive.
-- Investigate the system's recent login history and user activity to identify any unauthorized access attempts.
-- Review historical data for similar alerts on the same host to determine if this is part of a recurring pattern or isolated incident.
-
-### False positive analysis
-
-- Routine administrative tasks often trigger the execution of utilities like `icacls`, `cacls`, `takeown`, and `attrib`, leading to false positives. For instance, system administrators may use these tools to manage permissions during software installations or updates.
-- Automated scripts or system management tools from trusted vendors, such as Lenovo, Adobe, or ASUS, may execute these utilities as part of their normal operations, which can be safely excluded from alerts.
-- To manage these false positives, users can create exceptions by excluding specific processes or directories known to be safe, such as those related to trusted software vendors or internal IT scripts.
-- Regularly review and update the exclusion list to ensure it reflects the current environment and includes any new trusted processes or directories that may have been added.
-- Consider implementing a whitelist approach for known safe operations, allowing only specific, verified processes to execute these utilities without triggering alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
-- Conduct a thorough investigation to determine the scope of the permissions modification, identifying all affected files and directories.
-- Review system logs and security events to trace the origin of the suspicious activity, focusing on the execution of utilities like `icacls`, `cacls`, `takeown`, and `attrib`.
-- Verify the legitimacy of the user account involved in the permission changes and reset credentials if necessary to prevent further unauthorized access.
-- Restore original file and directory permissions from backups or use system restore points to revert changes, ensuring system integrity.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is determined to be part of a larger attack or if sensitive data is involved.
-- Implement enhanced logging policies to capture detailed information on file and directory permission changes, including user actions and process executions.
-- Integrate security solutions such as endpoint detection and response (EDR) tools to monitor and alert on suspicious permission changes in real-time.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
-- Apply hardening measures by restricting the use of permission-altering utilities to authorized personnel only and implementing least privilege access controls."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_generic_deletion.toml b/rules_building_block/defense_evasion_generic_deletion.toml
index 4b59dc4b229..845c9e5546e 100644
--- a/rules_building_block/defense_evasion_generic_deletion.toml
+++ b/rules_building_block/defense_evasion_generic_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -48,48 +48,6 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name: "powershell.exe" and process.args: ("*rmdir", "rm", "rd", "*Remove-Item*", "del", "*]::Delete(*"))
 ) and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 File or Directory Deletion Command
-
-In Windows environments, commands like `rundll32.exe`, `reg.exe`, `cmd.exe`, and `powershell.exe` are integral for system management, allowing users to delete files or directories. However, adversaries exploit these to erase logs or malware traces, hindering forensic analysis. The detection rule identifies suspicious deletions by monitoring these command executions, excluding benign paths, and flagging non-system user activities, thus highlighting potential malicious actions.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on `process.name` and `process.args` fields.
-- Check the `user.id` field to determine which user account executed the command and assess if this account has a history of suspicious activity.
-- Investigate the parent process of the flagged command using the `process.parent.name` and `process.parent.args` fields to understand the context in which the deletion command was executed.
-- Examine the timestamp of the event to correlate with other activities on the system, such as logins or other process executions, to identify any patterns or anomalies.
-- Use Osquery to list recent file deletions on the system with a query like: `SELECT * FROM file_events WHERE action = 'DELETE' AND datetime >= 'YYYY-MM-DD HH:MM:SS';` to gather more context around the deletion activity.
-- Cross-reference the paths in `process.args` with known benign paths to ensure the exclusion list is comprehensive and verify if any new paths should be considered suspicious.
-- Analyze the network activity around the time of the event to identify any potential data exfiltration attempts or connections to known malicious IPs.
-- Review system logs for any other suspicious activities or errors that occurred around the same time as the deletion command execution.
-- Check for any recent changes in system configurations or installed software that might explain the use of deletion commands.
-- Investigate the presence of any known malware or indicators of compromise on the system using threat intelligence sources and compare them with the command arguments and user activity.
-
-### False positive analysis
-
-- Routine system maintenance tasks or software updates may trigger the rule, as they often involve deleting temporary files or old logs, which can be mistaken for malicious activity.
-- Automated scripts or scheduled tasks that clean up directories or manage file storage can also be flagged, especially if they use command-line tools like `cmd.exe` or `powershell.exe`.
-- Users can manage these false positives by creating exceptions for known benign processes or paths, such as excluding specific user accounts or directories frequently involved in legitimate deletions.
-- It's important to regularly review and update the exclusion list to ensure that new legitimate activities are not mistakenly flagged, while still maintaining the integrity of the detection rule against genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
-- Conduct a thorough investigation to identify the scope of the deletion, focusing on critical files such as logs, browser history, or potential malware traces.
-- Utilize forensic tools to recover deleted files if possible, and analyze them for indicators of compromise or further malicious activity.
-- Escalate the incident to the security operations center (SOC) or incident response team if the deletion is linked to a broader attack or if sensitive data is involved.
-- Implement enhanced logging policies to capture detailed command execution and file access activities, ensuring that future deletions are detected promptly.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and correlate with known threat actor behaviors.
-- Restore the system to its operational state by reinstalling affected applications and restoring data from verified backups.
-- Apply system hardening measures, such as restricting the use of command-line tools to authorized personnel and implementing application whitelisting.
-- Review and update security policies and procedures to address gaps identified during the investigation and ensure compliance with best practices.
-- Conduct a post-incident review to learn from the event, improve response strategies, and prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
index ca67a27d2a2..68ad590b53a 100644
--- a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
+++ b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,51 +42,6 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.parent.name : ("pcalua.exe", "forfiles.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Indirect Command Execution via Forfiles/Pcalua
-
-Forfiles and pcalua.exe are legitimate Windows utilities. Forfiles is used for batch processing files, while pcalua.exe is part of the Program Compatibility Assistant, aiding in application compatibility. Adversaries exploit these tools to execute commands indirectly, bypassing security controls. The detection rule identifies suspicious activity by monitoring process initiations with these utilities as parents, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of "pcalua.exe" or "forfiles.exe" as the parent process in the event logs.
-- Examine the command line arguments used with "pcalua.exe" or "forfiles.exe" to identify any suspicious or unexpected commands being executed.
-- Check the user account associated with the process initiation to determine if it aligns with expected behavior or if it might be compromised.
-- Investigate the child processes spawned by "pcalua.exe" or "forfiles.exe" to identify any potentially malicious activities or anomalies.
-- Utilize Osquery to gather additional context on the processes. For example, run the following query to list processes with "pcalua.exe" or "forfiles.exe" as the parent:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE parent IN (SELECT pid FROM processes WHERE name IN ('pcalua.exe', 'forfiles.exe'));
-  ```
-- Analyze the file paths and locations associated with the executed commands to determine if they are legitimate or potentially harmful.
-- Cross-reference the event timestamp with other security logs (e.g., network, authentication) to identify any correlated suspicious activities.
-- Investigate any recent changes to the system or software installations that might have triggered the use of these utilities.
-- Check for any known vulnerabilities or exploits related to the applications or scripts executed via "pcalua.exe" or "forfiles.exe".
-- Document findings and gather evidence to support further analysis or escalation if necessary.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use forfiles.exe for legitimate batch processing tasks, such as file cleanup or automated maintenance scripts. These activities can trigger the detection rule but are typically non-threatening.
-- Software installations and updates: pcalua.exe is frequently invoked during legitimate software installations or updates to ensure compatibility, which can be mistakenly flagged as suspicious activity.
-- Automated scripts: Some organizations use automated scripts that leverage forfiles.exe for file management across multiple systems, which can lead to false positives if these scripts are not accounted for in the detection logic.
-- To manage false positives, users can create exceptions for known benign activities by whitelisting specific scripts or processes that regularly use forfiles.exe or pcalua.exe. This can be done by adding conditions to the detection rule to exclude these known processes or by using a centralized management system to maintain a list of approved activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to determine the scope of the incident, focusing on identifying any additional compromised systems or accounts.
-- Review the process execution logs to confirm the misuse of forfiles.exe or pcalua.exe and identify any commands executed indirectly.
-- Terminate any malicious processes identified during the investigation to halt ongoing threats.
-- Remove any unauthorized or malicious files and restore any altered system configurations to their original state.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities exploited by the adversary.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate related events.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required.
-- Educate users on recognizing and reporting suspicious activities to prevent future incidents and reinforce security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_injection_from_msoffice.toml b/rules_building_block/defense_evasion_injection_from_msoffice.toml
index 6dcbf018ffd..6d1c96172e8 100644
--- a/rules_building_block/defense_evasion_injection_from_msoffice.toml
+++ b/rules_building_block/defense_evasion_injection_from_msoffice.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -48,49 +48,6 @@ process where host.os.type == "windows" and event.action == "start" and
     "?:\\Windows\\Sys*\\ctfmon.exe",
     "?:\\Windows\\System32\\notepad.exe")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Process Injection from Malicious Document
-
-Microsoft Office applications are often targeted by adversaries who exploit vulnerabilities or use malicious macros to execute unauthorized code. This can lead to process injection, where malicious code is executed within legitimate processes, evading detection. The detection rule identifies unusual child processes spawned by Office apps, focusing on atypical arguments and paths, to flag potential injection attempts. By monitoring these anomalies, the rule helps in identifying and mitigating threats associated with process injection tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the parent process is one of the targeted Microsoft Office applications: excel.exe, powerpnt.exe, or winword.exe.
-- Examine the child process executable path to verify if it matches the suspicious paths: "?:\\\\Windows\\\\SysWOW64\\\\*.exe" or "?:\\\\Windows\\\\system32\\\\*.exe".
-- Check the process arguments count to ensure it is exactly one, as specified in the detection rule.
-- Investigate the process code signature to determine if it is untrusted or if the subject name does not start with "Microsoft".
-- Cross-reference the child process executable against known legitimate processes to rule out false positives, focusing on exclusions like Taskmgr.exe, ctfmon.exe, and notepad.exe.
-- Use Osquery to gather additional context about the suspicious process. Example query: `SELECT * FROM processes WHERE name = '<suspicious_process_name>' AND path LIKE 'C:\\\\Windows\\\\SysWOW64\\\\%' OR path LIKE 'C:\\\\Windows\\\\system32\\\\%';`
-- Analyze the parent process's recent activity, including any network connections or file modifications, to identify potential malicious behavior.
-- Review the document or macro that initiated the Office application to identify any embedded scripts or suspicious content.
-- Check for any recent patches or vulnerabilities related to the Office application version in use, which might have been exploited.
-- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Known false positives may include legitimate applications or scripts that are executed with minimal arguments from Office applications, such as internal automation tools or scripts used by IT departments for maintenance tasks.
-- System administrators might run diagnostic or monitoring tools that match the rule's criteria, especially if these tools are executed from common system directories like SysWOW64 or system32.
-- Users can handle these false positives by creating exceptions for specific processes that are known to be safe and frequently triggered, such as internal scripts or tools that have been verified and are necessary for business operations.
-- To manage false positives, users can refine the detection rule by adding exclusions for specific executable paths or process names that are consistently identified as non-threatening, ensuring these are well-documented and reviewed regularly to maintain security integrity.
-- It is important to monitor the frequency and context of these alerts to distinguish between benign and potentially malicious activities, adjusting the rule's parameters as needed to reduce noise without compromising detection capabilities.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Analyze the suspicious process and its parent Office application to confirm if it is indeed a malicious activity.
-- Terminate any identified malicious processes and remove any associated files or executables from the system.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to ensure no other threats are present.
-- Review and collect relevant logs, including process creation and network activity, to understand the scope and impact of the incident.
-- Escalate the incident to the security operations team for further investigation and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network connections for future incidents.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities.
-- Restore the system from a known good backup if necessary, ensuring that all security patches and updates are applied.
-- Apply hardening measures such as disabling macros by default in Office applications and enforcing strict application whitelisting policies."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_installutil_command_activity.toml b/rules_building_block/defense_evasion_installutil_command_activity.toml
index 17279604699..f0718951b7f 100644
--- a/rules_building_block/defense_evasion_installutil_command_activity.toml
+++ b/rules_building_block/defense_evasion_installutil_command_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,49 +46,6 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name : "installutil.exe" and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Activity
-
-InstallUtil is a legitimate Windows utility used for installing and uninstalling .NET applications by executing installer components. However, adversaries can exploit it to execute malicious code under the guise of a trusted process, bypassing security measures. The detection rule identifies suspicious InstallUtil activity by monitoring process starts on Windows systems, specifically flagging instances not initiated by the system account, which may indicate unauthorized use.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "installutil.exe" and verify the user ID is not "S-1-5-18" to ensure it matches the detection criteria.
-- Check the parent process of "installutil.exe" to determine how it was initiated and assess if the parent process is legitimate or suspicious.
-- Investigate the user account associated with the process start to determine if the activity aligns with their typical behavior or if the account may be compromised.
-- Examine the command-line arguments used with "installutil.exe" to identify any unusual or malicious parameters that could indicate misuse.
-- Correlate the timestamp of the InstallUtil activity with other security events or logs to identify any related suspicious activities or anomalies.
-- Use Osquery to gather additional context about the system state at the time of the alert. For example, run the following query to list recent processes executed by the same user: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<suspicious_user>') ORDER BY start_time DESC LIMIT 10;`
-- Check for any recent changes to the system, such as new software installations or modifications to critical files, that could be associated with the InstallUtil activity.
-- Investigate network connections made by the system around the time of the alert to identify any unusual outbound traffic that could suggest data exfiltration or command-and-control communication.
-- Review historical data for any previous instances of InstallUtil activity on the same host or by the same user to identify patterns or repeated attempts.
-- Consult threat intelligence sources to determine if the observed InstallUtil activity matches known tactics, techniques, and procedures (TTPs) used by adversaries.
-
-### False positive analysis
-
-- Legitimate software installations: Some enterprise applications may use InstallUtil for legitimate installation processes, which could trigger the detection rule. Users should verify the source and context of the InstallUtil execution to determine if it is part of a sanctioned software deployment.
-- Developer activities: Developers might use InstallUtil during the development and testing of .NET applications. Organizations should consider excluding known developer machines or user accounts from the rule to reduce noise.
-- Automated scripts and maintenance tasks: Scheduled tasks or scripts that utilize InstallUtil for routine maintenance or updates can also be flagged. Users can create exceptions for these tasks by identifying the specific user accounts or scripts involved.
-- System administration tools: Certain administrative tools or scripts may leverage InstallUtil for legitimate purposes. Administrators should document and exclude these known tools from the detection rule to prevent false positives.
-- To manage false positives, users can create exceptions based on user accounts, specific hostnames, or known benign command-line arguments associated with InstallUtil executions. This approach helps maintain the effectiveness of the detection rule while minimizing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the InstallUtil activity by checking the source and context of the process initiation, focusing on user accounts and associated tasks.
-- Conduct a thorough investigation of the system to identify any additional indicators of compromise, such as unusual network connections or file modifications.
-- Review and analyze security logs to trace the origin and timeline of the malicious activity, ensuring that all related events are captured.
-- Remove any unauthorized or malicious software identified during the investigation, using trusted antivirus or endpoint detection and response tools.
-- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning.
-- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that future suspicious activities are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze security events more effectively.
-- Escalate the incident to the appropriate internal or external cybersecurity teams if the scope of the attack is beyond initial containment and remediation efforts.
-- Apply system hardening measures, such as restricting the use of system utilities like InstallUtil to authorized users only, and regularly update security policies to mitigate similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
index d78e756d328..2017bffb2fb 100644
--- a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
+++ b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -40,50 +40,6 @@ library where host.os.type == "windows" and event.action == "load" and
     "?:\\Windows\\System32\\DriverStore\\FileRepository\\*"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Image Loaded with Invalid Signature
-
-In Windows environments, code signing ensures the integrity and authenticity of binaries. Adversaries may exploit this by loading binaries with invalid signatures to masquerade as legitimate software, evading detection. The detection rule identifies such anomalies by checking for invalid signatures, recent file modifications, and mismatches between DLL and process names, excluding trusted system paths. This helps in pinpointing potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which binary triggered the alert, focusing on the `dll.name` and `process.name` fields to identify potential mismatches.
-- Check the `dll.code_signature.status` field to determine the specific signature error, such as "errorUntrustedRoot" or "errorBadDigest," to assess the nature of the invalid signature.
-- Investigate the `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` fields to determine if the binary was recently created or modified, which could indicate suspicious activity.
-- Verify the `dll.path` to ensure it is not located in a trusted system path, as the rule excludes paths like "?:\\\\Windows\\\\System32\\\\DriverStore\\\\FileRepository\\\\*".
-- Use Osquery to gather additional context about the binary. For example, run the following query to list details about the binary: `SELECT path, sha256, signature_status FROM file WHERE path = '<dll.path>';`.
-- Cross-reference the hash of the binary (obtained from the Osquery result) with known threat intelligence databases to check for any known malicious activity.
-- Examine the parent process of the binary using the `process.name` field to understand the context in which the binary was loaded and identify any unusual parent-child process relationships.
-- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised.
-- Review recent system logs and events around the time the binary was loaded to identify any other suspicious activities or anomalies.
-- Consult with other security tools or logs to gather additional information about the network activity or other system changes that occurred around the time of the alert.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate software that uses self-signed certificates or certificates from less common certificate authorities, which may not be recognized by the system, leading to an "errorUntrustedRoot" status.
-- Software updates or patches can temporarily result in mismatches between DLL and process names, especially if the update process involves temporary files or renaming during installation.
-- Development or testing environments often load unsigned or self-signed binaries, which can trigger this rule due to the nature of the software being tested.
-- Users can manage these false positives by creating exceptions for known and trusted software that frequently triggers the rule, ensuring that these exceptions are well-documented and reviewed regularly to maintain security integrity.
-- Implementing a whitelist for specific paths or binaries that are known to be safe, even if they occasionally show invalid signatures, can help reduce noise in the detection system.
-- Regularly updating the list of trusted certificate authorities and ensuring that legitimate software is using up-to-date certificates can also help minimize false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potentially malicious activity.
-- Verify the invalid signature by cross-referencing with known trusted certificates and check for any recent unauthorized changes to the system.
-- Conduct a thorough investigation to identify the source of the invalid binary, including reviewing recent file modifications and process execution logs.
-- Remove or quarantine the suspicious binary and any associated files to prevent execution.
-- Escalate the incident to the security operations team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Restore the system using a clean backup or reinstall the operating system if necessary to ensure all malicious components are removed.
-- Implement enhanced logging policies to capture detailed information on file creation, modification, and execution events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Conduct a security audit of the system and network to identify and remediate any vulnerabilities that may have been exploited.
-- Educate users on recognizing and reporting suspicious activities to improve overall security awareness and reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_browsers.toml b/rules_building_block/defense_evasion_masquerading_browsers.toml
index d18448e7409..3ad0df05445 100644
--- a/rules_building_block/defense_evasion_masquerading_browsers.toml
+++ b/rules_building_block/defense_evasion_masquerading_browsers.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -157,52 +157,6 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Masquerading as Browser Process
-
-Browsers are integral to accessing web content, often running with elevated privileges and trusted by users. Adversaries exploit this by masquerading malicious processes as legitimate browser processes to evade detection, bypass security measures, or deceive users. The detection rule identifies anomalies in browser processes, such as unexpected signatures or paths, to flag potential masquerading attempts, thereby enhancing security posture against such tactics.
-
-### Possible investigation steps
-
-- Review the process name and executable path to determine if it matches known legitimate browser paths or if it appears suspicious or unusual.
-- Check the process code signature details, including the subject name and trust status, to verify if the process is signed by a recognized and trusted entity.
-- Investigate the parent process to understand how the suspicious process was initiated and whether it was spawned by a legitimate application or a potentially malicious one.
-- Examine the command-line arguments used to start the process for any unusual or suspicious flags that might indicate malicious behavior.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list processes with their parent process and command-line arguments:
-  ```sql
-  SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('chrome.exe', 'msedge.exe', 'firefox.exe', 'brave.exe', 'opera.exe', 'whale.exe');
-  ```
-- Cross-reference the process executable path with known software installation directories to determine if the executable is located in an expected location.
-- Analyze recent system logs and events around the time the process was started to identify any related activities or anomalies.
-- Investigate the network connections established by the process to identify any suspicious or unexpected external communications.
-- Check for any recent changes to the system, such as software installations or updates, that might explain the presence of the process.
-- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process name or signature details.
-
-### False positive analysis
-
-- Legitimate software that uses browser processes for automation or testing, such as Selenium or Puppeteer, may trigger false positives. Users can handle these by adding exceptions for known automation tools in the detection rule.
-- Security software or monitoring tools that utilize browser processes for sandboxing or analysis, like HP Sure Click or Dynatrace, may be flagged. Users should exclude these processes by verifying their code signatures and adding them to an allowlist.
-- Custom or enterprise-specific applications that embed browser components might be misidentified. Users should ensure these applications are signed with trusted certificates and add them to exceptions if necessary.
-- Updates or beta versions of browsers that have not yet been recognized by the detection rule may cause false positives. Users can manage this by temporarily excluding these versions until the rule is updated.
-- Non-standard installations of browsers, such as portable versions, might not match expected paths or signatures. Users should verify the legitimacy of these installations and adjust the rule to accommodate them.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware.
-- Verify the legitimacy of the suspicious browser process by checking the process's executable path and code signature against known trusted sources.
-- Terminate any identified malicious processes to stop ongoing malicious activity.
-- Conduct a thorough investigation of the system to identify any additional indicators of compromise or persistence mechanisms.
-- Review and analyze system logs to trace the origin and timeline of the suspicious activity, leveraging MITRE ATT&CK framework for context on masquerading techniques.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Update and patch all software and operating systems to mitigate vulnerabilities that could be exploited by similar threats.
-- Implement enhanced logging policies to capture detailed process execution and code signature verification for future incidents.
-- Integrate threat intelligence feeds and security solutions to improve detection capabilities and reduce response times.
-- Escalate the incident to the appropriate internal or external cybersecurity team if the threat level is beyond current handling capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
index b8a42671c1f..7df37c1057b 100644
--- a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
+++ b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -50,49 +50,6 @@ file where host.os.type == "windows" and event.action != "deletion" and
   not process.pid == 4 and
   not process.executable : "?:\\Program Files (x86)\\Trend Micro\\Client Server Security Agent\\Ntrtscan.exe"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Executable File with Unusual Extension
-
-Executable files are typically identified by specific extensions, but attackers may disguise them using extensions associated with benign file types like images or documents to evade detection. This detection rule identifies such anomalies by checking for executable headers in files with unexpected extensions, excluding known safe processes, thus highlighting potential masquerading attempts for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file's extension and header bytes, ensuring they match the criteria specified in the detection rule (e.g., MZ header with unexpected extensions like jpg, mp3, etc.).
-- Check the file creation or modification timestamp to determine when the suspicious activity occurred and correlate it with other events on the system.
-- Identify the user account associated with the file creation or modification event to assess if the activity aligns with their typical behavior or role.
-- Investigate the parent process that created or modified the file by examining the process ID and executable path, ensuring it is not a known safe process like Ntrtscan.exe.
-- Use Osquery to gather additional context about the file and its associated process. For example, run the following query to list processes with the suspicious file as an argument: `SELECT * FROM processes WHERE path LIKE '%<suspicious_file_name>%'`.
-- Examine the file's metadata and properties, such as its size, hash, and digital signature, to determine if it matches known malicious files or legitimate software.
-- Search for any network connections or communications initiated by the process that created or modified the file to identify potential command and control activity.
-- Review system logs and security events around the time of the alert to identify any other suspicious activities or anomalies that may be related.
-- Check for any recent changes in system configurations or installed software that could explain the presence of the executable file with an unusual extension.
-- Consult threat intelligence sources to determine if the file or its characteristics are associated with known malware campaigns or threat actors.
-
-### False positive analysis
-
-- Files with executable headers but benign extensions may be generated by legitimate software installations or updates, which often use temporary files with non-standard extensions during the process.
-- Some software development tools may create or modify files with executable headers and unexpected extensions as part of their normal operation, especially during compilation or packaging processes.
-- Security or system management tools might scan or modify files, resulting in temporary files with executable headers and non-standard extensions, which are not malicious.
-- Users can manage these false positives by creating exceptions for known safe processes or directories where such legitimate activities occur frequently.
-- Regularly review and update the list of excluded processes or directories to ensure that only non-threatening behaviors are excluded, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
-- Conduct a thorough investigation to identify the source and scope of the incident, focusing on the file's origin, associated processes, and any network connections.
-- Use endpoint detection and response (EDR) tools to analyze the behavior of the suspicious file and any related processes.
-- Remove or quarantine the suspicious file and any associated malicious software identified during the investigation.
-- Review and update antivirus and anti-malware signatures to ensure they can detect similar threats in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if additional expertise is required.
-- Implement enhanced logging policies to capture detailed file creation and modification events, focusing on unusual file extensions and executable headers.
-- Integrate threat intelligence feeds to improve detection capabilities and provide context on known masquerading techniques and associated threat actors.
-- Restore the system to its operational state by applying clean backups and verifying the integrity of critical system files and applications.
-- Harden the system by applying security patches, disabling unnecessary services, and enforcing strict access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
index 3cb7e0f2082..63f9383bbda 100644
--- a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -41,49 +41,6 @@ library where host.os.type == "windows" and event.action == "load" and
     and dll.code_signature.trusted == true
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Masquerading as VLC DLL
-
-Dynamic Link Libraries (DLLs) are crucial for modularizing code in Windows environments, allowing applications like VLC to function efficiently. Adversaries exploit this by crafting malicious DLLs with names mimicking legitimate VLC components, aiming to evade detection. The detection rule identifies such threats by flagging unsigned or improperly signed DLLs masquerading as VLC, focusing on specific filenames and verifying their digital signatures against trusted sources.
-
-### Possible investigation steps
-
-- Verify the alert details by checking the specific DLL name that triggered the alert, focusing on "libvlc.dll", "libvlccore.dll", or "axvlc.dll".
-- Confirm the digital signature status of the DLL by examining the `dll.code_signature.subject_name` and `dll.code_signature.trusted` fields to ensure they do not match trusted sources like "VideoLAN".
-- Use Osquery to list all loaded DLLs on the affected host and their signature status with a query such as: `SELECT path, name, signer FROM processes JOIN signature ON processes.path = signature.path WHERE name IN ('libvlc.dll', 'libvlccore.dll', 'axvlc.dll');`.
-- Investigate the file path and location of the suspicious DLL to determine if it resides in a directory typically used by VLC or if it is in an unusual location.
-- Check the file creation and modification timestamps of the DLL to identify any anomalies or recent changes that could indicate tampering.
-- Review the process that loaded the DLL by examining the `event.action` field to understand the context in which the DLL was used.
-- Analyze the parent process and any associated child processes of the application that loaded the DLL to identify any suspicious activity or process lineage.
-- Gather additional context by reviewing recent system logs and events around the time the DLL was loaded to identify any related activities or anomalies.
-- Cross-reference the hash of the suspicious DLL against known malware databases or threat intelligence sources to check for any known malicious indicators.
-- Consult with the user or system owner to verify if there have been any recent installations or updates that could explain the presence of the unsigned DLL.
-
-### False positive analysis
-
-- Some legitimate software may use custom or modified versions of VLC DLLs that are not signed by VideoLAN, leading to false positives. Users should verify the source and purpose of these DLLs before excluding them.
-- In corporate environments, IT departments might deploy VLC with custom configurations or additional plugins that are unsigned. Users can create exceptions for these known internal deployments by verifying their origin and ensuring they are part of the organization's standard software package.
-- Security tools or software that integrate VLC functionalities might include their own versions of VLC DLLs, which could trigger the rule. Users should confirm the legitimacy of these tools and whitelist them if they are verified as safe.
-- To manage false positives, users can maintain a list of known and trusted unsigned DLLs that are regularly used in their environment and configure the detection system to exclude these from alerts.
-- Regularly review and update the list of exceptions to ensure that only verified and necessary DLLs are excluded, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat.
-- Verify the legitimacy of the detected DLLs by checking their digital signatures and comparing them against known good signatures from VideoLAN.
-- Conduct a thorough investigation to identify any other systems that may have loaded the same or similar unsigned DLLs.
-- Remove any identified malicious DLLs and replace them with legitimate versions from a trusted source.
-- Perform a full system scan using updated antivirus and anti-malware tools to detect and remove any additional threats.
-- Review and update endpoint protection policies to ensure that only signed and trusted DLLs are allowed to load.
-- Implement enhanced logging policies to capture detailed DLL load events and code signature verification results for future investigations.
-- Integrate threat intelligence feeds to automatically update detection rules with the latest known malicious DLL signatures and behaviors.
-- Restore the system to its operational state by applying any necessary patches and updates, and verifying system integrity.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and stricter execution policies, to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_windows_dll.toml b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
index 41927e72ae2..f64458b81cf 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -104,55 +104,6 @@ library where event.action == "load" and dll.Ext.relative_file_creation_time <=
       )
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Masquerading as System32 DLL
-
-System32 DLLs are critical components of Windows, providing essential functions for applications. Adversaries may exploit this by replacing or hijacking these DLLs to execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies by checking for unsigned or non-Microsoft signed DLLs, recent file creation, and specific DLL names, helping to uncover potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific DLL name and path that triggered the alert. Pay attention to the `dll.name` and `dll.path` fields.
-- Check the `dll.code_signature.subject_name` and `dll.code_signature.trusted` fields to determine if the DLL is signed by a trusted entity or if there are any anomalies in the signature.
-- Investigate the `dll.Ext.relative_file_creation_time` to understand how recently the DLL was created. A creation time within the last hour could indicate suspicious activity.
-- Use Osquery to list all DLLs loaded by the process that triggered the alert. Example query: `SELECT path, name, signed, sign_info FROM processes JOIN signature ON processes.path = signature.path WHERE name = '<process_name>';`
-- Examine the process that loaded the suspicious DLL using the `process.name` field. Determine if the process is legitimate and expected to load such DLLs.
-- Cross-reference the `dll.path` with known safe directories and check if it matches any of the excluded paths in the query to rule out false positives.
-- Investigate the parent process of the process that loaded the DLL to understand the process hierarchy and identify any unusual parent-child relationships.
-- Check for any recent changes or installations on the system that might have introduced the DLL, using system logs or software inventory tools.
-- Analyze network activity associated with the process to identify any suspicious connections or data exfiltration attempts.
-- Review historical data to determine if the same DLL or process has triggered alerts in the past, indicating a recurring issue or persistent threat.
-
-### False positive analysis
-
-- **Valve and Adobe Inc. DLLs**: The rule may flag `icuuc.dll` signed by Valve, Valve Corp., Avanquest Software, or Adobe Inc. as suspicious. These are known false positives and can be excluded by verifying the signature and adding exceptions for these trusted entities.
-- **VMware DLLs**: `timeSync.dll` and `appInfo.dll` signed by VMware Inc. or VMware, Inc. may trigger alerts. Users can handle these by confirming the signature and excluding these DLLs from the rule.
-- **NoMachine and Oculus VR DLLs**: `libcrypto.dll` signed by NoMachine S.a.r.l. or Oculus VR, LLC is a known false positive. Users should verify the signature and add exceptions for these trusted sources.
-- **Bitdefender DLLs**: `libcrypto.dll`, `wmi.dll`, `geolocation.dll`, and `kerberos.dll` signed by Bitdefender SRL may be flagged. These can be excluded by confirming the signature and adding them to the exception list.
-- **Paessler AG DLL**: `ICMP.dll` signed by Paessler AG is a known false positive. Users should verify the signature and exclude it from the rule.
-- **Adobe Inc. DirectML DLL**: `DirectML.dll` signed by Adobe Inc. may trigger alerts. Users can handle this by confirming the signature and excluding it.
-- **Dell Technologies DLL**: `icsvc.dll` signed by Dell Inc or Dell Technologies Inc. is a known false positive. Users should verify the signature and add exceptions for these trusted entities.
-- **Malwarebytes DLL**: `offreg.dll` signed by Malwarebytes Inc. may be flagged. Users can exclude this by confirming the signature and adding it to the exception list.
-- **Autodesk DLL**: `AppMgr.dll` signed by Autodesk, Inc is a known false positive. Users should verify the signature and exclude it.
-- **DismHost.exe Process**: DLLs like `SsShim.dll`, `Msi.dll`, and `wdscore.dll` in the `C:\\Windows\\Temp\\` directory when associated with the `DismHost.exe` process may trigger alerts. Users can exclude these by confirming the process and path context.
-- **Specific Paths**: DLLs located in paths such as `?:\\Windows\\SystemApps\\*\\dxgi.dll`, `?:\\Windows\\SystemApps\\*\\wincorlib.dll`, `?:\\Windows\\dxgi.dll`, and `?:\\Users\\*\\AppData\\Local\\LINE\\bin\\current\\dbghelp.dll` are known false positives. Users should verify the path and exclude these from the rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Verify the legitimacy of the detected DLLs by checking their digital signatures and comparing them against known good versions.
-- Conduct a thorough investigation of recent file creation and modification activities to identify any unauthorized changes.
-- Utilize endpoint detection and response (EDR) tools to scan for additional indicators of compromise (IOCs) across the network.
-- Remove or replace any identified malicious or unauthorized DLLs with legitimate versions from a trusted source.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed information on DLL loads and process executions for future investigations.
-- Integrate threat intelligence feeds to stay updated on emerging threats and incorporate them into detection mechanisms.
-- Restore the system to its operational state by applying the latest security patches and updates to prevent exploitation of known vulnerabilities.
-- Harden the system by implementing application whitelisting, restricting administrative privileges, and ensuring regular security audits."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
index f66e05b473e..96aa94f8133 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/31"
 
 [rule]
 author = ["Elastic"]
@@ -78,53 +78,6 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Masquerading as System32 Executable
-
-System32 executables are critical components of Windows, often targeted by adversaries for masquerading attacks to evade detection. Attackers may replace or backdoor these executables with malicious versions, often altering their signatures. The detection rule identifies suspicious executions of these files by checking for non-Microsoft signatures or unsigned executables, while excluding known trusted exceptions, to flag potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the process name and executable path to confirm if it matches any known legitimate System32 executables or if it appears suspicious or out of place.
-- Check the process code signature status and subject name to determine if the executable is signed by a trusted Microsoft certificate or if it is unsigned or signed by a non-Microsoft entity.
-- Investigate the parent process to understand how the suspicious executable was launched and if it was initiated by a legitimate process or a potentially malicious one.
-- Examine the process creation time to see if it aligns with any known user activity or scheduled tasks, which might provide context for its execution.
-- Use Osquery to gather additional details about the process. For example, run the following query to check for any anomalies in the process's file attributes:
-  ```sql
-  SELECT * FROM processes WHERE name = 'suspicious_executable_name.exe';
-  ```
-- Analyze the network activity associated with the process to identify any unusual connections or data transfers that could indicate malicious behavior.
-- Check the file hash of the executable against known malware databases to see if it matches any known threats.
-- Review recent system changes or updates that might have affected the executable, such as software installations or patches, to determine if they could explain the signature anomaly.
-- Investigate any other alerts or logs from the same host around the time of the alert to identify potential patterns or related activities.
-- Consult threat intelligence sources to see if there are any known campaigns or techniques that match the observed behavior, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- **Git for Windows**: The rule may flag executables like `hostname.exe` and `find.exe` located in the Git for Windows installation path. Users can handle this by adding exceptions for these specific paths.
-- **Temporary Files**: Executables such as `taskkill.exe` in temporary directories may trigger alerts. Users should consider excluding these paths if they are part of legitimate processes.
-- **Windows Upgrade**: During Windows upgrades, executables like `ie4ushowIE.exe` in the `$WINDOWS.~BT` directory might be flagged. Users can exclude this path during known upgrade periods.
-- **Third-party Software**: Some third-party software, such as Axence nVision Agent, may use executables like `certutil.exe` that are flagged. Users should verify the software's legitimacy and add exceptions for these specific paths.
-- **Trusted Vendors**: Executables signed by trusted vendors like Wellbia.com Co., Ltd., Lenovo, HP Inc., Dell Inc., ImageMagick Studio LLC, Arctic Wolf Networks, Intel, Fortinet, and Cisco may be flagged. Users can add exceptions for these vendors if the signatures are verified as trusted.
-- **Custom Software**: Organizations using custom or less common software that mimics system32 executables should verify the software's legitimacy and add necessary exceptions to avoid false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware.
-- Verify the legitimacy of the suspicious executable by checking its hash against known good versions or using a trusted source.
-- If the executable is confirmed malicious, remove or replace it with a clean version from a trusted source.
-- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or changes to system settings.
-- Review and analyze logs from the affected system and any associated network devices to trace the origin and scope of the attack.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is beyond the current team's capabilities.
-- Implement enhanced logging policies to capture detailed process execution and code signing events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security controls are functioning correctly.
-- Harden the system by implementing least privilege access, disabling unnecessary services, and ensuring all software is up to date to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
index ce9d8f444db..1c7efb230f7 100644
--- a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
+++ b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,49 +57,6 @@ process where host.os.type == "windows" and event.action == "start" and
     "ftp://*"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Troubleshooting Pack Cabinet Execution
-
-The Microsoft Diagnostic Wizard, often invoked via `msdt.exe`, is a legitimate tool used for troubleshooting and diagnostics in Windows environments. However, adversaries can exploit it to execute malicious files, particularly when these files are disguised as troubleshooting packs (`.diagcab`). The detection rule identifies unusual executions of `msdt.exe` from suspicious paths or with atypical parent processes, such as web browsers or email clients, which may indicate an attempt to misuse this tool for malicious purposes. By monitoring these specific conditions, the rule helps in identifying potential threats that leverage system binary proxy execution for defense evasion.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `msdt.exe` execution with `/cab` argument, ensuring it matches the suspicious criteria outlined in the detection rule.
-- Identify and document the parent process of `msdt.exe` from the alert, focusing on unusual parent processes such as web browsers or email clients, which may indicate a phishing attempt or drive-by download.
-- Examine the full command line arguments used in the `msdt.exe` execution to gather more context about the potential source and nature of the `.diagcab` file.
-- Investigate the file path from which the `.diagcab` file was executed, especially if it originates from user directories, network shares, or URLs, to assess the legitimacy of the file.
-- Use Osquery to list recent processes executed by the user associated with the alert to identify any other suspicious activities. Example query: `SELECT * FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspected_user') ORDER BY start_time DESC LIMIT 10;`
-- Check the network connections established by `msdt.exe` or its parent process to identify any suspicious outbound connections that may indicate data exfiltration or command and control communication.
-- Analyze the `.diagcab` file itself, if accessible, using static and dynamic analysis tools to determine if it contains any malicious payloads or scripts.
-- Review the security logs for any other alerts or events related to the same user or system around the time of the alert to identify potential patterns or additional indicators of compromise.
-- Investigate the user's email and web browsing history to determine if they interacted with any suspicious emails or websites that could have led to the execution of the `.diagcab` file.
-- Correlate the findings with threat intelligence sources to check if the observed behavior or indicators match any known threat actor tactics, techniques, or procedures.
-
-### False positive analysis
-
-- Legitimate troubleshooting activities: Users or IT administrators may legitimately use `msdt.exe` to open `.diagcab` files for troubleshooting purposes. If these activities are frequent and known to be safe, they can be excluded by creating exceptions for specific user accounts or paths.
-- Software updates and installations: Some software installations or updates might invoke `msdt.exe` as part of their process. Monitoring these activities and correlating them with known update schedules or installation logs can help identify and exclude these benign events.
-- Remote support tools: IT support tools that remotely troubleshoot or diagnose issues might trigger this rule. Identifying and excluding these tools by their parent process or specific command-line arguments can reduce false positives.
-- Custom scripts or automation: Organizations may have custom scripts or automation that utilize `msdt.exe` for legitimate purposes. Documenting these scripts and excluding their specific execution patterns can help manage false positives.
-- Frequent use by specific applications: If certain applications are known to frequently invoke `msdt.exe` in a non-malicious manner, consider excluding these applications by their parent process name or path to reduce noise in the detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation to identify the source of the diagcab file and determine if any other systems have been affected.
-- Analyze the process tree and command-line arguments to confirm the execution path and parent process, ensuring it aligns with the detection rule criteria.
-- If malicious activity is confirmed, remove any unauthorized diagcab files and associated malicious binaries from the system.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are at risk.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds to correlate detected activity with known threat actor tactics, techniques, and procedures (TTPs) related to MITRE ATT&CK T1218.
-- Educate users on the risks of opening files from untrusted sources, particularly those received via email or downloaded from the internet.
-- Apply system hardening measures, such as restricting the execution of diagcab files to trusted directories and implementing application whitelisting to prevent unauthorized software execution."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
index b898930a60c..2627af83080 100644
--- a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
+++ b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/08/05"
 
 [rule]
 author = ["Elastic"]
@@ -47,49 +47,6 @@ sequence with maxspan=1m
     not process.name : "msiexec.exe" and
     not (process.executable : ("?:\\Program Files (x86)\\*.exe", "?:\\Program Files\\*.exe") and process.code_signature.trusted == true)]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows Installer with Suspicious Properties
-
-Windows Installer, a core component for application deployment on Windows, can be exploited by adversaries to bypass security measures. Attackers may misuse `msiexec.exe` to execute malicious MSI files, often sourced from archives like ZIP or RAR, or disguised with deceptive names. The detection rule identifies such activities by monitoring registry changes and process executions linked to `msiexec.exe`, flagging untrusted or unusual sources and executables.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific registry changes and process executions that triggered the alert, focusing on the `msiexec.exe` process and associated registry values like `InstallSource`, `DisplayName`, and `ProductName`.
-- Check the source of the MSI file by examining the `registry.data.strings` field to determine if it originated from a suspicious archive path, such as a ZIP, 7z, or RAR file in a user's temporary directory.
-- Investigate the parent process of `msiexec.exe` to identify how the installer was launched, ensuring it aligns with expected user or system behavior.
-- Verify the legitimacy of the executed process by checking its path and code signature status, especially if it is not located in the trusted `Program Files` directories.
-- Use Osquery to gather additional context about the suspicious process. For example, run the following query to list all processes with `msiexec.exe` as the parent: `SELECT pid, name, path, cmdline FROM processes WHERE parent = (SELECT pid FROM processes WHERE name = 'msiexec.exe');`
-- Examine recent user activity on the host to identify any actions that might have led to the execution of the suspicious installer, such as downloading files from the internet or opening email attachments.
-- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
-- Check for any network connections initiated by the suspicious process to determine if it is communicating with external or potentially malicious servers.
-- Review the system's application whitelisting policies to assess if there are any gaps or misconfigurations that could have allowed the execution of the suspicious installer.
-- Consult threat intelligence sources to determine if the suspicious installer or its components are associated with known malware or adversary techniques.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule if they are executed from compressed archives or temporary directories, especially during software development or testing phases.
-- Automated deployment tools or scripts that utilize `msiexec.exe` to install software from network locations or temporary paths might be flagged as suspicious.
-- Users can manage these false positives by creating exceptions for known and trusted software sources, such as specific directories or network paths frequently used for legitimate installations.
-- Exclude processes with verified code signatures from trusted vendors to reduce false positives while maintaining security.
-- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, minimizing the risk of overlooking genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation to identify the source of the suspicious MSI file, checking for any unauthorized downloads or email attachments.
-- Review the registry changes and process execution logs to confirm the presence of malicious activity linked to msiexec.exe.
-- If malware is confirmed, use a trusted antivirus or endpoint detection and response (EDR) tool to remove the malicious files and any associated threats.
-- Restore the system from a known good backup if the integrity of the system is compromised and cannot be cleaned effectively.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and registry changes, focusing on msiexec.exe activities.
-- Integrate threat intelligence feeds to improve detection capabilities and correlate with known indicators of compromise (IOCs) related to msiexec.exe abuse.
-- Educate users on the risks of downloading and executing files from untrusted sources, emphasizing the dangers of opening email attachments from unknown senders.
-- Apply system hardening measures, such as application whitelisting and restricting msiexec.exe execution to trusted sources only, to prevent future exploitation attempts."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_posh_defender_tampering.toml b/rules_building_block/defense_evasion_posh_defender_tampering.toml
index bb36b59fdc9..d512e623895 100644
--- a/rules_building_block/defense_evasion_posh_defender_tampering.toml
+++ b/rules_building_block/defense_evasion_posh_defender_tampering.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/09/11"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,48 +60,6 @@ event.category: "process" and host.os.type:windows and
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Windows Defender Tampering Capabilities
-
-PowerShell is a powerful scripting language in Windows environments, often used for automation and configuration. However, adversaries exploit its capabilities to disable Windows Defender features, reducing detection risks. The detection rule identifies scripts using specific cmdlets and parameters that modify Defender settings, signaling potential tampering attempts aimed at impairing system defenses.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of suspicious PowerShell activity, focusing on the `powershell.file.script_block_text` field for any of the specified cmdlets and parameters.
-- Check the `event.category` field to ensure the event is categorized as a "process" and verify the `host.os.type` is "windows" to confirm the environment context.
-- Investigate the user account associated with the PowerShell process to determine if it is a known or privileged account, which could indicate a higher risk if compromised.
-- Examine the process tree to identify the parent process of the PowerShell script, which may provide insights into how the script was executed and whether it was initiated by a legitimate application or a suspicious source.
-- Use Osquery to gather additional context on the PowerShell process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%Set-MpPreference%';` to identify all instances of PowerShell with similar command lines.
-- Analyze recent login events and user activity on the host to identify any unusual patterns or unauthorized access attempts that could correlate with the PowerShell activity.
-- Review the system's security logs for any other related events, such as changes to security settings or other tampering attempts, to build a timeline of suspicious activities.
-- Check for any network connections initiated by the PowerShell process to external IP addresses, which could indicate data exfiltration or command-and-control communication.
-- Investigate any file modifications or new files created around the time of the PowerShell execution to identify potential payloads or additional scripts dropped by the attacker.
-- Correlate the findings with threat intelligence sources to determine if the observed behavior matches known attack patterns or indicators of compromise associated with specific threat actors.
-
-### False positive analysis
-
-- Legitimate administrative scripts: System administrators may use PowerShell scripts to configure or troubleshoot Windows Defender settings as part of routine maintenance or system optimization. These scripts might include cmdlets and parameters that resemble tampering attempts.
-- Security software updates: Some security software or system updates might temporarily adjust Windows Defender settings to ensure compatibility or performance, triggering the detection rule.
-- Automated deployment tools: Tools used for automated deployment and configuration management might execute scripts that modify Defender settings, which could be mistaken for malicious activity.
-- To manage false positives, users can create exceptions for known legitimate scripts by whitelisting specific script paths or hashes. Additionally, monitoring the context of script execution, such as the user account and process lineage, can help differentiate between benign and malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further tampering or spread of malicious activities.
-- Conduct a thorough investigation of the PowerShell script execution logs to identify the source and scope of the tampering attempt.
-- Review and analyze Windows Event Logs, especially Security and PowerShell logs, to gather more context on the attack and identify any additional compromised systems.
-- Remove any unauthorized or malicious scripts and restore Windows Defender settings to their default state using the Set-MpPreference cmdlet.
-- Update all antivirus and endpoint protection signatures to ensure the latest threat intelligence is applied.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and module logging, to improve future detection capabilities.
-- Integrate security information and event management (SIEM) systems with threat intelligence feeds to enhance detection and response to similar threats.
-- Restore the system to its operational state by applying the latest security patches and updates, and verify that all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as application whitelisting and restricting PowerShell execution policies, to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
index 1181d955639..ed5067dbc9e 100644
--- a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
+++ b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ event.category:process and host.os.type:windows and
   ) and
   not file.directory : "C:\Program Files\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.Configuration"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Log Clear Capabilities
-
-PowerShell, a powerful scripting language in Windows, enables automation and configuration management. Adversaries exploit its capabilities to clear event logs, erasing traces of their activities to evade detection. The detection rule identifies suspicious PowerShell commands linked to log deletion, excluding benign scripts and known directories, thus highlighting potential malicious actions.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific PowerShell command or method triggered the detection, focusing on the `powershell.file.script_block_text` field.
-- Examine the `event.category:process` field to identify the process that executed the suspicious PowerShell command, noting the process ID and parent process ID for further context.
-- Check the `host.os.type:windows` field to confirm the operating system and ensure the alert pertains to a Windows environment.
-- Investigate the user account associated with the execution of the PowerShell script to determine if it aligns with expected behavior or if it indicates potential compromise.
-- Analyze the execution context by reviewing the `file.directory` field to verify if the script was executed from a known or suspicious directory, excluding benign directories like "C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration".
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE pid = <process_id>;` to retrieve details about the process that executed the PowerShell command.
-- Investigate recent login events for the user account involved to identify any unusual login patterns or anomalies that could suggest unauthorized access.
-- Review other security logs and alerts around the same timeframe to identify any correlated activities or additional indicators of compromise.
-- Check for any recent changes to system configurations or scheduled tasks that might have been used to facilitate the execution of the PowerShell script.
-- Document all findings and maintain a timeline of events to assist in understanding the scope and potential impact of the activity.
-
-### False positive analysis
-
-- Known false positives may arise from legitimate administrative tasks where system administrators use PowerShell scripts to manage event logs as part of routine maintenance or troubleshooting. These activities might include clearing logs to free up space or reset logs after resolving issues.
-- Scripts executed from trusted directories, such as those used by Windows Admin Center, may trigger alerts if not properly excluded. Ensure that directories like "C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration" are added to exclusion lists to prevent unnecessary alerts.
-- To manage false positives, users can create exceptions for specific scripts or directories known to perform legitimate log management tasks. This can be done by updating the detection rule to exclude these benign activities, ensuring that only suspicious or unknown scripts trigger alerts.
-- Regularly review and update exclusion lists to reflect changes in administrative practices or new trusted scripts, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the attack, focusing on recent PowerShell activities and event log modifications.
-- Review and analyze other systems for similar PowerShell script executions to determine if the attack has spread.
-- Restore cleared event logs from backups if available to aid in forensic analysis and understanding of the attack timeline.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed PowerShell execution data, including script block logging and module logging.
-- Integrate with a security information and event management (SIEM) system to correlate and analyze PowerShell activities across the network.
-- Apply security patches and updates to the affected system to mitigate vulnerabilities exploited by the attacker.
-- Educate users and administrators on the risks of PowerShell misuse and enforce the principle of least privilege to limit script execution capabilities.
-- Consider deploying application whitelisting or PowerShell Constrained Language Mode to restrict unauthorized script execution."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
index de8e08b4a67..c5e63bbb893 100644
--- a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
+++ b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -38,49 +38,6 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name : "* "
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Processes with Trailing Spaces
-
-In computing environments, process names are crucial for identifying and managing running applications. Adversaries exploit this by appending trailing spaces to process names, making them appear legitimate while evading detection. This tactic leverages the masquerading technique to bypass security measures. The detection rule identifies such anomalies by flagging processes with unexpected trailing spaces, thus uncovering potential evasion attempts.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of trailing spaces in the process name by examining the `process.name` field.
-- Cross-reference the `process.name` with known legitimate processes to identify any discrepancies or unusual patterns.
-- Investigate the `event.type` and `event.action` fields to understand the context of the process start event and confirm it aligns with typical execution patterns.
-- Check the parent process using the `process.parent.name` field to determine if the process was spawned by a legitimate or suspicious parent.
-- Utilize Osquery to gather additional context on the suspicious process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '% ';`
-- Examine the `process.executable` field to verify the file path and ensure it matches the expected location for legitimate processes.
-- Analyze the `user.name` field to identify the user account under which the process was executed, and assess if this aligns with normal user behavior.
-- Investigate any network connections or file modifications associated with the process using relevant logs or monitoring tools to identify potential malicious activity.
-- Review historical data for similar process names with trailing spaces to determine if this is part of a broader pattern or isolated incident.
-- Collaborate with other security teams or use threat intelligence sources to assess if the process name with trailing spaces is associated with known adversary techniques or campaigns.
-
-### False positive analysis
-
-- Known false positives for the Processes with Trailing Spaces rule may include legitimate applications or scripts that unintentionally have trailing spaces in their process names due to coding errors or formatting issues.
-- System administrators and developers might create scripts or batch files with trailing spaces for testing purposes, which can trigger the detection rule.
-- To manage these false positives, users can create exceptions for specific processes that are known to be safe and frequently exhibit trailing spaces, ensuring they are not flagged by the detection rule.
-- Regularly review and update the list of exceptions to accommodate changes in legitimate software behavior while maintaining security vigilance.
-- Implement logging and monitoring to track the frequency and context of trailing space occurrences, helping to distinguish between benign and potentially malicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Conduct a thorough investigation to identify the source and scope of the intrusion, focusing on processes with trailing spaces and any associated files or network activity.
-- Terminate any suspicious processes identified with trailing spaces to halt any ongoing malicious activity.
-- Review and analyze system logs to trace the adversary's actions and identify any additional compromised systems or accounts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Implement enhanced logging policies to capture detailed process creation events, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for masquerading techniques.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary services, enforcing strong authentication mechanisms, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_service_disabled_registry.toml b/rules_building_block/defense_evasion_service_disabled_registry.toml
index 9657068c3d5..c1f1d49dab7 100644
--- a/rules_building_block/defense_evasion_service_disabled_registry.toml
+++ b/rules_building_block/defense_evasion_service_disabled_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -44,49 +44,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     )
   and not registry.path : "HKLM\\SYSTEM\\ControlSet001\\Services\\MrxSmb10\\Start"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Service Disabled via Registry Modification
-
-Windows services are crucial for system operations, often configured via the registry. Adversaries may alter service start settings to disable security tools, evading detection. This detection rule identifies unauthorized registry changes to service start values, excluding legitimate modifications by services.exe. It focuses on changes indicating potential tampering, alerting analysts to possible defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path and data strings involved in the modification, focusing on paths like "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Services\\\\*\\\\Start".
-- Verify the process responsible for the registry change by examining the process name and user ID, ensuring it is not "services.exe" with user ID "S-1-5-18".
-- Check the event logs for any recent changes to the registry path "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Services\\\\*\\\\Start" to identify patterns or repeated attempts.
-- Investigate the user account associated with the registry change to determine if it has a history of suspicious activity or if it has been compromised.
-- Use Osquery to gather more information about the service in question. For example, run the query: `SELECT name, start_type, path FROM services WHERE name = '<ServiceName>';` to check the current configuration and status of the service.
-- Cross-reference the timestamp of the registry change with other security events or logs to identify any correlated activities, such as logins or file modifications.
-- Analyze the system for any other unauthorized registry changes or anomalies that might indicate broader tampering or compromise.
-- Investigate the network activity from the host around the time of the registry change to identify any suspicious outbound connections or data exfiltration attempts.
-- Review any recent software installations or updates on the host that might have inadvertently or maliciously altered service configurations.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware campaigns.
-
-### False positive analysis
-
-- Legitimate software updates or installations may modify service start settings, triggering the rule. Users can handle these by identifying the specific update processes and adding them to an exception list.
-- System administrators may intentionally change service configurations for maintenance or optimization purposes. To manage this, document and exclude these known administrative activities from triggering alerts.
-- Some third-party management tools might alter service start values as part of their normal operation. Users should verify these tools' behavior and exclude them if they are deemed non-threatening.
-- Automated scripts or scheduled tasks that modify service settings for legitimate reasons can also cause false positives. Users should review these scripts and tasks, ensuring they are authorized, and exclude them from detection.
-- In environments with custom security policies, certain service modifications might be routine. Users should map these policies and create exceptions for expected changes to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized changes or potential lateral movement by the adversary.
-- Conduct a thorough investigation to identify the process responsible for the registry modification, focusing on any suspicious processes other than services.exe.
-- Review recent changes in the registry and correlate them with known malicious patterns or behaviors using threat intelligence sources.
-- Restore the modified registry settings to their original state, ensuring that critical security and monitoring services are re-enabled.
-- Escalate the incident to the security operations center (SOC) or incident response team if the modification is linked to a known threat actor or campaign.
-- Implement enhanced logging policies to capture detailed registry changes and process activities, ensuring that future unauthorized modifications are detected promptly.
-- Integrate additional security tools, such as endpoint detection and response (EDR) solutions, to improve visibility and response capabilities.
-- Conduct a security audit of the affected system to identify and remediate any other potential vulnerabilities or misconfigurations.
-- Educate users and administrators on the importance of maintaining secure configurations and monitoring for unauthorized changes.
-- Apply hardening measures, such as restricting registry access to authorized processes and users, to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_service_path_registry.toml b/rules_building_block/defense_evasion_service_path_registry.toml
index 53c35880bc7..d8411c0a57f 100644
--- a/rules_building_block/defense_evasion_service_path_registry.toml
+++ b/rules_building_block/defense_evasion_service_path_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,49 +49,6 @@ registry where host.os.type == "windows" and event.type == "change" and
     )
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Service Path Modification
-
-In Windows environments, services are crucial for running background processes. The service path, stored in the registry, dictates the executable a service runs. Adversaries may alter this path to execute malicious code, achieving persistence or privilege escalation. The detection rule identifies changes to service paths by monitoring registry modifications, excluding trusted executables, thus highlighting suspicious activity by unusual processes.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific registry path that was modified, focusing on the `registry.path` field to understand which service's executable path was altered.
-- Examine the `process.executable` field to determine the process responsible for the modification, noting any unusual or untrusted executables that do not match the excluded paths.
-- Check the `host.os.type` field to confirm the operating system is Windows, ensuring the context of the alert is accurate.
-- Investigate the parent process of the modifying executable to understand the process hierarchy and identify potential sources of compromise.
-- Use Osquery to list all services and their current executable paths to verify if other services have been similarly modified. Example query: `SELECT name, path FROM services WHERE path LIKE '%\\\\ImagePath';`
-- Cross-reference the timestamp of the registry change event with other logs, such as security or application logs, to identify any correlated suspicious activities.
-- Analyze recent user logins and account activities on the affected host to determine if the modification was performed by a legitimate user or through compromised credentials.
-- Investigate network connections from the host around the time of the modification to identify any unusual outbound or inbound connections that could indicate lateral movement or data exfiltration.
-- Review any recent software installations or updates on the host that could have inadvertently or maliciously altered the service path.
-- Check for any known vulnerabilities or exploits associated with the modified service or the process that made the change, which could provide further context on the attack vector used.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger service path modifications, as they often update registry entries to point to new or updated executables. Users can handle these by monitoring the update schedules of trusted software and creating exceptions for known update processes.
-- IT administrative tools or scripts that modify service paths for legitimate configuration changes can also be flagged. To manage this, users should identify and document these tools, then create exceptions for their associated processes.
-- Custom in-house applications that are not widely recognized may be flagged if they modify service paths during normal operations. Users should ensure these applications are signed and trusted, then add them to the exclusion list to prevent false positives.
-- Security software or endpoint protection solutions might modify service paths as part of their protective measures. Users should verify the legitimacy of these actions and exclude the corresponding processes if they are deemed safe.
-- During system maintenance or troubleshooting, administrators might manually change service paths, which could be flagged by the rule. Users should document these activities and temporarily disable the rule or add exceptions for the duration of the maintenance.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the process that modified the service path, using endpoint detection and response (EDR) tools to trace the process lineage and identify any associated malicious files or activities.
-- Review recent changes in the registry and restore the service path to its original state using backup data or system restore points if available.
-- Scan the system with updated antivirus and anti-malware tools to detect and remove any additional threats that may have been introduced.
-- Escalate the incident to the security operations center (SOC) or incident response team if the modification is linked to a known threat actor or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed registry changes and process execution events for future investigations.
-- Integrate threat intelligence feeds to correlate the detected activity with known indicators of compromise (IOCs) and threat actor tactics, techniques, and procedures (TTPs).
-- Apply security patches and updates to the operating system and installed software to mitigate vulnerabilities that could be exploited for similar attacks.
-- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of maintaining strong security hygiene.
-- Consider deploying application whitelisting and enforcing least privilege principles to reduce the risk of unauthorized modifications to critical system components."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_services_exe_path.toml b/rules_building_block/defense_evasion_services_exe_path.toml
index 868b8a6b7ac..f31ea296712 100644
--- a/rules_building_block/defense_evasion_services_exe_path.toml
+++ b/rules_building_block/defense_evasion_services_exe_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,48 +40,6 @@ query = '''
 process where event.type == "start" and process.name : "sc.exe" and
   process.args : "*config*" and process.args : "*binPath*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Service Path Modification via sc.exe
-
-The `sc.exe` utility is a command-line tool used to manage Windows services, including configuring service paths. Adversaries may exploit this by altering service paths to execute malicious binaries, achieving persistence or privilege escalation. The detection rule identifies suspicious modifications by monitoring for `sc.exe` executions with specific arguments related to service configuration, signaling potential unauthorized changes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `sc.exe` execution with arguments containing `*config*` and `*binPath*`, indicating a service path modification attempt.
-- Correlate the timestamp of the `sc.exe` execution with other logs to identify any preceding or subsequent suspicious activities, such as file modifications or network connections.
-- Identify the user account associated with the `sc.exe` process execution to determine if it aligns with expected administrative activity or if it might be compromised.
-- Examine the parent process of `sc.exe` to understand how it was initiated, which could provide insights into whether the execution was automated or manually triggered.
-- Use Osquery to list all services and their current binary paths to identify any discrepancies or unexpected changes. Example query: `SELECT name, path FROM services WHERE path LIKE '%suspicious_binary%'`.
-- Investigate the modified service's purpose and typical behavior to assess the potential impact of the path change and whether it aligns with legitimate operations.
-- Check for any recent changes to the system's registry, particularly in areas related to service configurations, to identify unauthorized modifications.
-- Analyze network logs for any unusual outbound connections from the host around the time of the `sc.exe` execution, which might indicate data exfiltration or command-and-control activity.
-- Review historical logs for previous instances of `sc.exe` usage by the same user or on the same host to identify patterns or repeated attempts at service path modification.
-- Consult threat intelligence sources to determine if the modified service path or associated binary is linked to known malware or adversary techniques.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use `sc.exe` to legitimately modify service paths during maintenance or configuration changes. To manage these, users can create exceptions for known administrative accounts or specific time windows when such tasks are expected.  
-- Software updates: Some software installations or updates might modify service paths using `sc.exe` as part of their setup process. Users can exclude these by identifying and whitelisting the associated software update processes or vendors.  
-- Automated scripts: Organizations may have automated scripts that use `sc.exe` for service management. To handle these, users can exclude specific scripts or processes by their hash or command line patterns.  
-- Monitoring tools: Certain monitoring or management tools might invoke `sc.exe` for legitimate service checks or configurations. Users should identify these tools and create exceptions based on their known behavior or signatures.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify the scope of the compromise, focusing on recent changes to service paths and any unauthorized binaries.
-- Review system logs and security events to trace the origin of the `sc.exe` command execution and identify any associated user accounts or processes.
-- Restore the original service path configurations from backups or system documentation to ensure legitimate service operation.
-- Remove any unauthorized binaries or scripts that were introduced as part of the service path modification.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future monitoring.
-- Integrate endpoint detection and response (EDR) solutions to provide real-time alerts and automated responses to suspicious service modifications.
-- Conduct a security audit of all services and their configurations to identify and remediate any other potential vulnerabilities.
-- Apply system hardening measures, such as restricting administrative privileges and implementing application whitelisting, to prevent unauthorized service modifications in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
index 39c26822ed0..6928b4187a8 100644
--- a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
+++ b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,49 +68,6 @@ process where host.os.type == "windows" and event.action == "start" and
 
   not process.args : ("?:\\Program Files (x86)\\*", "?:\\Program Files\\*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Execution via MSIEXEC
-
-MSIEXEC is a Windows Installer utility used for installing, maintaining, and removing software. Adversaries exploit it to execute malicious MSI files, often bypassing security controls. The detection rule identifies unusual MSIEXEC activity by scrutinizing execution paths, parent processes, and command-line arguments, flagging deviations from typical usage patterns to uncover potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific conditions of the detection rule were met, focusing on the process name, parent process, and command-line arguments.
-- Examine the `process.parent.executable` field to identify the parent process that initiated `msiexec.exe`. Determine if this parent process is commonly associated with legitimate software installations.
-- Investigate the `process.args` field to analyze the command-line arguments used with `msiexec.exe`, paying particular attention to the presence of `/i`, `/q`, or `/quiet` flags, which may indicate silent installations.
-- Check the `process.args_count` to ensure it aligns with typical usage patterns. An unusual count may suggest additional, potentially malicious arguments.
-- Analyze the `process.working_directory` to verify if the execution path is consistent with standard software installation directories or if it points to suspicious locations.
-- Use Osquery to gather more context about the process and its parent. For example, run the following query to list processes with their parent details: `SELECT pid, name, path, parent, cmdline FROM processes WHERE name = 'msiexec.exe';`
-- Investigate the `user.id` field to determine the user account under which `msiexec.exe` was executed. Check if this account has a history of performing software installations.
-- Cross-reference the `process.parent.name` with known legitimate processes like `explorer.exe` or `wmiprvse.exe` to assess if the parent process is expected or unusual.
-- Look into the `process.parent.command_line` length, especially if the parent process is `powershell.exe` or `cmd.exe`, to identify potentially obfuscated or complex command lines.
-- Review historical data for similar alerts involving the same `process.parent.executable` or `process.args` to identify patterns or repeated suspicious behavior.
-
-### False positive analysis
-
-- Legitimate software installations or updates may trigger the rule if they use msiexec.exe with command-line arguments that match the suspicious patterns, such as silent installations using "/q" or "/quiet" switches.
-- System administrators or automated deployment tools might use msiexec.exe to install software across multiple systems, which could be flagged if the parent process or execution path is unusual.
-- Custom scripts or third-party management tools that leverage msiexec.exe for software management tasks could be misidentified as malicious if they execute from non-standard directories or with uncommon parent processes.
-- To manage these false positives, users can create exceptions for known benign processes or paths by adding them to the exclusion list in the detection rule, ensuring that frequent non-threatening behaviors are not flagged.
-- Regularly review and update the exclusion list to accommodate changes in legitimate software deployment practices or new trusted applications that may trigger the rule.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential threats.
-- Analyze the suspicious msiexec.exe process and its parent process to determine if it is part of a known attack pattern or a false positive.
-- Terminate any malicious processes identified during the investigation to stop ongoing malicious activity.
-- Review and collect relevant logs, including Windows Event Logs and security software logs, to gather evidence and understand the scope of the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Remove any malicious MSI files and associated artifacts from the system to ensure complete remediation.
-- Restore the system from a known good backup if the integrity of the system is compromised.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) solutions to improve detection capabilities.
-- Apply system hardening measures, such as restricting the execution of msiexec.exe to authorized users and paths, to reduce the risk of similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unsigned_bits_client.toml b/rules_building_block/defense_evasion_unsigned_bits_client.toml
index f3abf25d95c..84012c3b2d4 100644
--- a/rules_building_block/defense_evasion_unsigned_bits_client.toml
+++ b/rules_building_block/defense_evasion_unsigned_bits_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -40,49 +40,6 @@ library where dll.name : "Bitsproxy.dll" and process.executable != null and
 not process.code_signature.trusted == true and
 not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unsigned BITS Service Client Process
-
-The Background Intelligent Transfer Service (BITS) is a Windows component that facilitates asynchronous, prioritized, and throttled transfer of files between machines. While beneficial for legitimate updates and data transfers, adversaries can exploit BITS to stealthily download or upload malicious payloads. The detection rule identifies suspicious BITS activity by flagging processes using the BITS library that lack a valid code signature, indicating potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of an unsigned BITS client process by checking the `process.executable` field for the specific executable path.
-- Verify the `dll.name` field to ensure that "Bitsproxy.dll" is indeed being used by the process, as this is a key indicator of BITS activity.
-- Examine the `process.code_signature.trusted` field to confirm that the process lacks a valid code signature, which is crucial for identifying potentially malicious activity.
-- Investigate the `process.code_signature.status` field to ensure that the status does not indicate a known error like "errorExpired" or "errorCode_endpoint*", which could explain the unsigned status.
-- Use Osquery to gather more information about the process by running a query such as: `SELECT pid, name, path, cmdline FROM processes WHERE path = '<process.executable>';` to retrieve details about the process execution.
-- Check the process's parent process ID and lineage to determine how the unsigned BITS client process was initiated, which can provide insights into potential compromise vectors.
-- Analyze network activity associated with the process to identify any suspicious data transfers or connections that could indicate malicious use of BITS.
-- Review recent file modifications and creations in directories associated with the process to detect any unauthorized changes or payloads.
-- Correlate the findings with other security alerts or logs to identify patterns or related activities that could suggest a broader attack campaign.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware families.
-
-### False positive analysis
-
-- Some legitimate software may use the BITS service without a valid code signature, especially older or custom-developed applications. These can trigger false positives if they are unsigned but not malicious.
-- System administrators should identify and document any known legitimate applications that use BITS and lack a valid code signature. These applications can be added to an exception list to prevent them from being flagged.
-- Regularly review and update the exception list to ensure it reflects the current environment and includes any new legitimate applications that may trigger the rule.
-- Consider the context of the flagged activity, such as the source and destination of the file transfers, to determine if the behavior aligns with expected and benign operations.
-- Collaborate with software vendors to verify the legitimacy of unsigned applications and encourage them to provide properly signed versions to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and data exfiltration.
-- Verify the unsigned BITS client process by checking the process details and associated files for any known malicious indicators.
-- Terminate the suspicious BITS process and remove any associated files that are identified as malicious.
-- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
-- Review system and security logs to trace the origin of the unsigned BITS process and identify any lateral movement or additional compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on BITS-related events.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection of similar threats in the future.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all software is from trusted sources.
-- Harden the system by disabling unnecessary services, enforcing strict application whitelisting, and regularly reviewing and updating security configurations."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unusual_process_extension.toml b/rules_building_block/defense_evasion_unusual_process_extension.toml
index 356440873c5..62072e9e4ed 100644
--- a/rules_building_block/defense_evasion_unusual_process_extension.toml
+++ b/rules_building_block/defense_evasion_unusual_process_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -59,48 +59,6 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.name: "AGSRunner.bin" and process.code_signature.subject_name: "Intel Corporation")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process Extension
-
-In Windows environments, processes typically run with standard executable extensions like .exe or .com. Adversaries may exploit this by using non-standard extensions to disguise malicious executables, evading detection. The 'Unusual Process Extension' rule identifies such anomalies by flagging processes with atypical extensions, excluding known legitimate cases, thus highlighting potential masquerading attempts.
-
-### Possible investigation steps
-
-- Review the process name and executable path to determine if the extension is indeed unusual and not a false positive by checking against known legitimate cases.
-- Verify the process's code signature details, such as the subject name, to confirm if the process is signed by a trusted entity or if it lacks a valid signature.
-- Cross-reference the process name and executable path with threat intelligence sources to identify if they are associated with known malicious activities.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes with unusual extensions: `SELECT pid, name, path, cmdline, cwd, uid, gid FROM processes WHERE path LIKE '%.%' AND path NOT LIKE '%.exe' AND path NOT LIKE '%.com' AND path NOT LIKE '%.scr' AND path NOT LIKE '%.tmp' AND path NOT LIKE '%.dat';`
-- Investigate the parent process of the flagged process to understand how it was spawned and if the parent process is legitimate.
-- Check the process's command line arguments for any suspicious or unexpected parameters that could indicate malicious behavior.
-- Analyze the process's network activity to identify any unusual or unauthorized connections that could suggest data exfiltration or command and control communication.
-- Examine the process's file creation and modification activities to detect any unauthorized changes to critical system files or directories.
-- Review system logs and security events around the time the process was started to identify any correlated suspicious activities or anomalies.
-- Consult with other team members or departments to gather additional insights or context about the process, especially if it is related to a specific application or business function.
-
-### False positive analysis
-
-- Certain legitimate processes may run with unusual extensions due to specific software requirements or configurations, such as those from Dell, Bloomberg LP, Adobe Inc., McAfee, LLC, The Document Foundation, Veeam Software Group GmbH, LLC 1C-Soft, and Intel Corporation. These are already accounted for in the rule's exceptions.
-- Users may encounter false positives from custom or proprietary software that uses non-standard extensions for executable files. In such cases, users should verify the legitimacy of the process and consider adding it to the exclusion list if it is deemed safe.
-- Processes related to software development or testing environments might also trigger false positives due to the use of unique or temporary extensions. Users should assess the context and, if necessary, exclude these processes to reduce noise.
-- To manage false positives, users can update the rule's exclusion list by adding specific process names or paths that are verified as non-threatening, ensuring that these are regularly reviewed and updated to maintain security integrity.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malware.
-- Conduct a thorough investigation of the flagged process to determine if it is indeed malicious, using tools like antivirus scans and behavioral analysis.
-- Review the process's parent-child relationship to identify any other potentially malicious processes or scripts that may have initiated the unusual process.
-- If confirmed malicious, terminate the process and delete any associated files or registry entries to prevent re-execution.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if this is part of a larger attack.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent process information, to aid in future investigations.
-- Integrate threat intelligence feeds to correlate the unusual process with known threat actor tactics, techniques, and procedures (TTPs) for better context and response.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security software is up to date.
-- Conduct a post-incident review to identify gaps in the current security posture and update security policies and procedures accordingly.
-- Implement hardening measures such as application whitelisting, disabling unnecessary services, and enforcing least privilege access to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
index fac2f4d190a..f5ab763eba2 100644
--- a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
+++ b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,48 +53,6 @@ process where host.os.type == "windows" and event.type == "start" and
     "wmiprvse.exe"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process Execution on WBEM Path
-
-The Windows Management Instrumentation (WMI) is a core component for managing data and operations on Windows systems. It typically runs processes from the WBEM directory. Adversaries may exploit WMI to execute malicious processes under the guise of legitimate WMI activity, evading detection. The detection rule identifies non-standard processes executing from the WBEM path, flagging potential misuse by excluding known legitimate WMI executables.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process executable path and name that triggered the alert, focusing on the `process.executable` and `process.name` fields.
-- Verify the legitimacy of the process by checking the file hash against known good hashes or threat intelligence databases to identify any known malicious files.
-- Investigate the parent process using the `process.parent.name` and `process.parent.executable` fields to determine if the process was spawned by a legitimate or suspicious parent.
-- Examine the user context under which the process was executed using the `user.name` field to assess if the execution aligns with typical user behavior.
-- Check the process command line arguments with the `process.command_line` field to identify any suspicious or unusual parameters that may indicate malicious intent.
-- Utilize Osquery to gather additional context about the process. For example, run the following query to list all processes running from the WBEM directory: `SELECT pid, name, path, cmdline, parent FROM processes WHERE path LIKE 'C:\\\\Windows\\\\System32\\\\wbem\\\\%' OR path LIKE 'C:\\\\Windows\\\\SysWow64\\\\wbem\\\\%';`
-- Investigate recent file modifications in the WBEM directory to identify any unauthorized changes or additions that could be related to the suspicious process.
-- Analyze network connections initiated by the process using network monitoring tools or logs to detect any unusual outbound connections that may indicate data exfiltration or command and control activity.
-- Review system logs for any related events or anomalies around the time of the process execution to gather additional context or identify other potentially related suspicious activities.
-- Consult with other security team members or stakeholders to determine if there are any ongoing investigations or incidents that might be related to the alert, ensuring a coordinated response.
-
-### False positive analysis
-
-- Some legitimate third-party applications may occasionally execute processes from the WBEM path for monitoring or management purposes, which could be flagged as unusual. Users should verify the legitimacy of these applications and consider adding them to an exclusion list if they are deemed safe.
-- System administrators might run custom scripts or tools that interact with WMI for system management tasks. These scripts could trigger the detection rule if they execute processes from the WBEM directory. To handle this, administrators can document and exclude these known scripts from the detection rule.
-- During software updates or installations, certain applications might temporarily execute processes from the WBEM path. Users should monitor these activities and, if they are part of a legitimate update process, add them to the exclusion list to prevent future false positives.
-- Security tools or monitoring solutions that integrate with WMI might also execute processes from the WBEM path as part of their normal operation. Users should identify these tools and exclude them from the detection rule to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the process by checking the process hash against known malware databases and reviewing the process's parent-child relationship.
-- Terminate any suspicious processes identified as running from the WBEM path that are not part of the known legitimate WMI executables.
-- Conduct a thorough investigation of the system to identify any additional indicators of compromise, such as unusual network connections or file modifications.
-- Review system and security logs to trace the origin of the malicious process execution and identify any potential persistence mechanisms.
-- Restore the system to a known good state using backups or system restore points, ensuring that all malicious artifacts are removed.
-- Implement enhanced logging policies to capture detailed process execution and WMI activity for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for alerts.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if additional expertise is required.
-- Apply system hardening measures, such as restricting WMI access to authorized users and processes, and regularly updating and patching systems to mitigate vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_write_dac_access.toml b/rules_building_block/defense_evasion_write_dac_access.toml
index 1cefc72efcf..de838caec6d 100644
--- a/rules_building_block/defense_evasion_write_dac_access.toml
+++ b/rules_building_block/defense_evasion_write_dac_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,49 +61,6 @@ query = '''
 host.os.type: "windows" and event.action : ("Directory Service Access" or "object-operation-performed") and
   event.code : "4662" and winlog.event_data.AccessMask:"0x40000"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WRITEDAC Access on Active Directory Object
-
-WRITEDAC permissions allow modification of an object's access control list in Active Directory, crucial for managing access rights. Adversaries exploit this by altering permissions to escalate privileges or maintain persistence. The detection rule identifies suspicious WRITEDAC activities by monitoring specific Windows event codes and access masks, signaling potential unauthorized access modifications.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of event code "4662" and AccessMask "0x40000" to verify that the alert is related to WRITEDAC access.
-- Identify the user account associated with the WRITEDAC event by examining the event data fields such as `winlog.event_data.SubjectUserName` and `winlog.event_data.SubjectUserSid`.
-- Determine the target object of the WRITEDAC operation by reviewing `winlog.event_data.ObjectName` and `winlog.event_data.ObjectType` to understand what was potentially modified.
-- Check the timestamp of the event to establish a timeline and correlate it with other suspicious activities or alerts in the same timeframe.
-- Investigate the source machine from which the WRITEDAC operation was performed using `winlog.event_data.IpAddress` and `winlog.event_data.WorkstationName`.
-- Use Osquery to gather additional context on the involved user account and machine. For example, run the following query to list recent logins for the user: `SELECT * FROM logged_in_users WHERE user = '<username>';`.
-- Examine the user's recent activities and access patterns in Active Directory to identify any anomalies or deviations from their normal behavior.
-- Cross-reference the WRITEDAC event with other security logs and alerts to identify potential lateral movement or privilege escalation attempts.
-- Review the access control list (ACL) changes on the target object to determine what specific permissions were altered and assess the potential impact.
-- Consult with relevant stakeholders or system owners to verify if the WRITEDAC operation was authorized or part of a legitimate administrative task.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate system administrators may perform WRITEDAC operations as part of their regular duties, such as updating permissions for user accounts or groups. These actions can be excluded by creating exceptions for known administrator accounts or specific times when these tasks are scheduled.
-- Automated scripts and tools: Some organizations use automated scripts or third-party tools to manage Active Directory permissions, which may trigger the WRITEDAC rule. Users can handle these by identifying and excluding the specific scripts or tools from the detection rule.
-- Software updates and installations: Certain software updates or installations may require temporary changes to access control lists, resulting in WRITEDAC events. Users should monitor and document these activities, creating exceptions for known software processes or during maintenance windows.
-- Group policy updates: Changes to group policies can sometimes involve WRITEDAC operations. Users can manage these by correlating the events with scheduled group policy updates and excluding them from the detection rule.
-- Service account activities: Service accounts with legitimate access to modify permissions may trigger false positives. Users should identify these accounts and exclude their activities from the rule, ensuring they are monitored separately for any unusual behavior.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Review the event logs, specifically Windows Event ID 4662, to identify the source of the WRITEDAC access and any associated accounts or systems.
-- Verify the integrity of the access control lists (ACLs) on the affected Active Directory objects and revert any unauthorized changes.
-- Conduct a thorough investigation to determine if any other systems or accounts have been compromised, focusing on privilege escalation and persistence techniques.
-- Reset passwords and review permissions for any accounts involved in the incident to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed access and modification events in Active Directory for future investigations.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze security events across the network.
-- Restore the system to its operational state by applying verified backups and ensuring all security patches and updates are installed.
-- Harden the Active Directory environment by applying least privilege principles, regularly reviewing permissions, and conducting security awareness training for administrators."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_capnetraw_capability.toml b/rules_building_block/discovery_capnetraw_capability.toml
index 98be470a1aa..7fd2ca5a2a7 100644
--- a/rules_building_block/discovery_capnetraw_capability.toml
+++ b/rules_building_block/discovery_capnetraw_capability.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/01/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -65,48 +65,6 @@ event.category:"process" and host.os.type:"linux" and event.type:"start" and eve
 (process.thread.capabilities.effective:"CAP_NET_RAW" or process.thread.capabilities.permitted:"CAP_NET_RAW") and
 not user.id:"0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Network Traffic Capture via CAP_NET_RAW
-
-CAP_NET_RAW is a Linux capability that allows processes to create raw sockets, enabling them to capture and manipulate network traffic. While useful for legitimate network diagnostics, adversaries can exploit it to intercept data, bypass controls, or tamper with communications. The detection rule identifies non-root processes with this capability, flagging potential unauthorized network sniffing activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and user ID associated with the CAP_NET_RAW capability, focusing on the `process.name` and `user.id` fields.
-- Verify the legitimacy of the process by checking the process's path and hash against known good software inventories or threat intelligence databases.
-- Investigate the user account (`user.id`) that initiated the process to determine if it is a legitimate user or potentially compromised.
-- Use Osquery to list all processes with CAP_NET_RAW capabilities by executing: `SELECT pid, name, path FROM processes WHERE capabilities LIKE '%CAP_NET_RAW%';` to identify any other suspicious processes.
-- Examine the command line arguments (`process.command_line`) used to start the process for any unusual or suspicious parameters that might indicate malicious intent.
-- Check the parent process (`process.parent.name`) to understand the process hierarchy and determine if the process was spawned by a legitimate application or a potentially malicious one.
-- Analyze recent login events for the user account in question to identify any unusual login times or sources that could indicate unauthorized access.
-- Review network connections initiated by the process using tools like `netstat` or `ss` to identify any suspicious external communications.
-- Correlate the event with other security logs, such as firewall or intrusion detection system logs, to identify any related suspicious activities or anomalies.
-- Investigate the host's network configuration and firewall settings to ensure that they are properly configured to prevent unauthorized network traffic capture and manipulation.
-
-### False positive analysis
-
-- Legitimate network diagnostic tools: Some network diagnostic tools used by system administrators or network engineers may require CAP_NET_RAW capabilities to function correctly. These tools, while non-root, are not malicious and should be reviewed to determine if they are part of regular network maintenance activities. Users can handle these by creating exceptions for known diagnostic tools that are frequently used in their environment.
-- Containerized applications: In environments using containerization, certain applications may be granted CAP_NET_RAW capabilities to manage network traffic within the container. These applications should be verified to ensure they are part of the expected container setup. Users can exclude these applications by identifying and documenting the containers that require such capabilities for legitimate purposes.
-- Security monitoring tools: Some security tools designed to monitor network traffic for anomalies may also require CAP_NET_RAW capabilities. These tools should be assessed to confirm they are part of the organization's security infrastructure. Users can manage these by maintaining an updated list of approved security tools and excluding them from the detection rule.
-- Development and testing environments: Developers may use CAP_NET_RAW capabilities in non-production environments for testing network-related features. These activities should be monitored to ensure they do not inadvertently transition to production environments. Users can handle these by setting up separate rules or exceptions for development and testing environments, ensuring they are clearly distinguished from production systems.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to identify the process and user associated with the CAP_NET_RAW capability, focusing on non-root users.
-- Review system logs and network traffic to determine the scope of the activity and identify any other potentially compromised systems.
-- Terminate any unauthorized processes identified during the investigation that are using CAP_NET_RAW capabilities.
-- Change credentials and review user permissions for any accounts involved in the incident to prevent further misuse.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack.
-- Implement enhanced logging and monitoring for network traffic and process execution to detect similar activities in the future.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection and response capabilities for network sniffing and related tactics.
-- Restore the system to its operational state by applying patches, updating configurations, and ensuring all security controls are in place.
-- Harden the system by reviewing and restricting capabilities like CAP_NET_RAW to only trusted processes and users, and ensure firewalls are configured to limit packet types and contents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_account_groups.toml b/rules_building_block/discovery_generic_account_groups.toml
index e6b1c3fd522..eb8dadcd502 100644
--- a/rules_building_block/discovery_generic_account_groups.toml
+++ b/rules_building_block/discovery_generic_account_groups.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -60,48 +60,6 @@ process where host.os.type == "windows" and event.type == "start" and
 ) and not process.parent.args: "C:\\Program Files (x86)\\Microsoft Intune Management Extension\\Content\\DetectionScripts\\*.ps1"
 and not process.parent.name : "LTSVC.exe" and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows Account or Group Discovery
-
-Windows environments utilize built-in tools to manage and query user and group information, essential for system administration. Adversaries exploit these tools to gather intelligence on user accounts and group memberships, aiding in privilege escalation and lateral movement. The detection rule identifies suspicious use of these tools by monitoring specific command executions and arguments, filtering out benign activities to highlight potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command and arguments that triggered the rule, focusing on the `process.name` and `process.args` fields.
-- Check the `user.id` field to determine which user account executed the suspicious command and assess if this account has a history of similar activities.
-- Investigate the `process.parent.name` and `process.parent.args` fields to understand the parent process that initiated the command, which can provide context on whether the execution was part of a legitimate script or application.
-- Examine the `host.os.type` and `event.type` fields to confirm the environment and nature of the event, ensuring it aligns with the expected Windows system behavior.
-- Utilize Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('net.exe', 'dsquery.exe', 'whoami.exe');` to identify other related processes running on the host.
-- Cross-reference the `process.args` with known benign scripts or administrative tasks to rule out false positives, especially focusing on arguments like "accounts", "group", "user", and "localgroup".
-- Check for any recent changes in user permissions or group memberships on the system that could correlate with the suspicious command execution.
-- Review system logs and security events around the time of the alert to identify any other anomalous activities or patterns that could indicate a broader attack.
-- Investigate the network activity from the host to see if there are any unusual outbound connections or data transfers that might suggest data exfiltration or lateral movement.
-- Consult with the user associated with the `user.id` to verify if they were performing legitimate administrative tasks or if their credentials might have been compromised.
-
-### False positive analysis
-
-- Scheduled administrative tasks: Routine system administration tasks often involve querying user and group information, which can trigger this rule. Users can create exceptions for known administrative scripts or scheduled tasks by excluding specific process names or command arguments.
-- Software management tools: Applications like Microsoft Intune or other endpoint management solutions may execute similar commands for inventory or compliance checks. Exclude these processes by specifying their parent process names or paths in the rule.
-- Legitimate user queries: Users may use command-line tools to check their own account information. To reduce noise, consider excluding processes initiated by specific user IDs or those with known benign parent processes.
-- Custom scripts: Organizations may have custom scripts that perform account or group enumeration as part of their operations. Identify these scripts and exclude them by their file paths or specific command-line arguments to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized accounts or group memberships created or modified.
-- Review the execution logs of the identified commands to understand the adversary's actions and objectives.
-- Remove any unauthorized accounts or group memberships identified during the investigation to prevent privilege escalation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed command execution and user activity, ensuring that future suspicious activities are detected promptly.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze potential threats more effectively.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are hardened according to best practices.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness and reduce the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_process_discovery.toml b/rules_building_block/discovery_generic_process_discovery.toml
index f66ae49eb51..5cd753d8699 100644
--- a/rules_building_block/discovery_generic_process_discovery.toml
+++ b/rules_building_block/discovery_generic_process_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,48 +51,6 @@ process where host.os.type == "windows" and event.type == "start" and
    (process.name : "query.exe" and process.args : "process")
   ) and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Discovery Using Built-in Tools
-
-Process discovery tools, like PsList, qprocess, and PowerShell commands, are integral for system management, allowing administrators to monitor active processes. However, adversaries exploit these tools to identify running applications and security defenses, aiding in further attacks. The detection rule identifies suspicious use of these tools by monitoring specific command executions and excluding known system accounts, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command and process name that triggered the alert, focusing on the `process.name` and `process.args` fields.
-- Check the `user.id` field to determine which user account executed the command and verify if it is a known or expected user for such activities.
-- Investigate the `host.os.type` and `event.type` fields to confirm the environment and context in which the command was executed.
-- Correlate the timestamp of the alert with other security events or logs to identify any concurrent suspicious activities.
-- Use Osquery to gather additional context about the processes running on the host. For example, execute the following query to list all running processes: `SELECT pid, name, path, cmdline FROM processes WHERE name IN ('PsList.exe', 'qprocess.exe', 'powershell.exe', 'wmic.exe', 'tasklist.exe', 'query.exe');`
-- Examine the command line arguments (`process.args`) for any unusual or unexpected parameters that could indicate malicious intent.
-- Investigate the parent process of the suspicious command to understand how it was initiated and whether it was spawned by a legitimate application or another suspicious process.
-- Check for any recent changes in user permissions or group memberships that could have allowed unauthorized execution of these commands.
-- Review historical data to determine if this behavior is part of a recurring pattern or a one-time event.
-- Consult threat intelligence sources to see if there are any known campaigns or adversaries that utilize similar techniques, focusing on the MITRE ATT&CK technique T1057 for Process Discovery.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use built-in tools like PsList, qprocess, and PowerShell commands for legitimate process monitoring and management, which can trigger the rule. To manage this, create exceptions for known administrative accounts or specific time frames when these tasks are performed.
-- Automated scripts: Scheduled scripts or maintenance tasks that utilize these commands for system health checks or inventory purposes may also be flagged. Identify and exclude these scripts by their unique user accounts or specific command patterns.
-- Monitoring software: Some security or monitoring software may use similar commands to gather system information, leading to false positives. Review and whitelist these applications by their process names or associated user accounts.
-- Testing environments: In environments where security tools or processes are being tested, these commands might be executed frequently. Exclude these environments by filtering based on hostnames or IP ranges associated with testing labs.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to identify any unauthorized access or changes made to the system, focusing on the processes identified by the detection rule.
-- Terminate any suspicious processes identified during the investigation to halt any ongoing malicious activity.
-- Review and analyze logs from the affected system and related network devices to trace the adversary's actions and identify potential entry points.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement hardening measures such as restricting the use of built-in tools to authorized users only and employing application whitelisting to prevent unauthorized execution of processes."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_registry_query.toml b/rules_building_block/discovery_generic_registry_query.toml
index 876f56ba08b..4370465eb15 100644
--- a/rules_building_block/discovery_generic_registry_query.toml
+++ b/rules_building_block/discovery_generic_registry_query.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/19"
 
 [rule]
 author = ["Elastic"]
@@ -52,49 +52,6 @@ host.os.type:windows and event.category:process and event.type:start and
     "reg  query \"HKLM\\Software\\WOW6432Node\\Npcap\" /ve  "
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Query Registry using Built-in Tools
-
-The Windows Registry is a critical database for system configuration and application settings. Adversaries exploit built-in tools like `reg.exe` and PowerShell to query the registry, seeking information on installed software and system configurations. The detection rule identifies suspicious registry queries by monitoring specific command executions, filtering out benign activities, and focusing on potential misuse patterns, thus aiding in early threat detection.
-
-### Possible investigation steps
-
-- Review the alert details to understand which process triggered the rule, focusing on `process.name` and `process.args` to identify the specific command executed.
-- Check the `process.command_line` field to see the full command executed, which can provide context on the intent and scope of the registry query.
-- Investigate the parent process using `process.parent.name` and `process.parent.args` to determine if the registry query was initiated by a legitimate application or script.
-- Examine the user context under which the process was executed by reviewing the `user.name` field to assess if the activity aligns with the user's role and responsibilities.
-- Correlate the event timestamp with other logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'reg.exe' OR name LIKE 'powershell%';` to list all instances of these processes and their command lines.
-- Investigate the network activity associated with the process using network logs to determine if there was any data exfiltration or communication with known malicious IPs.
-- Check for any recent changes in the registry keys queried by the process to identify unauthorized modifications or configurations.
-- Review historical data to determine if similar registry queries have been executed in the past, which might indicate a persistent threat or recurring reconnaissance activity.
-- Consult threat intelligence sources to see if the specific command or pattern matches known attack techniques or campaigns, providing further context on the potential threat actor.
-
-### False positive analysis
-
-- Routine administrative tasks often involve querying the registry using `reg.exe` or PowerShell, which can trigger false positives. System administrators frequently use these tools for legitimate purposes such as checking software installations or system configurations.
-- Automated scripts and software management tools may execute registry queries as part of their normal operations, leading to benign alerts. For example, inventory management systems might query registry keys to gather information about installed applications.
-- Security software updates or checks might involve registry queries to verify settings or configurations, which can be mistaken for suspicious activity.
-- To manage these false positives, users can create exceptions for known benign processes by excluding specific command lines or process arguments that are regularly used in their environment.
-- Regularly review and update the exclusion list to ensure it reflects current legitimate activities, minimizing unnecessary alerts while maintaining effective threat detection.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the registry query activity, identifying any unauthorized access or changes.
-- Review the process execution details and command line arguments to confirm if the activity aligns with known malicious patterns or legitimate administrative tasks.
-- If malicious activity is confirmed, remove any unauthorized software or scripts that may have been installed or executed as a result of the registry query.
-- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed.
-- Implement enhanced logging policies to capture detailed process execution and command line activity for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate registry query activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is part of a broader attack campaign or if additional expertise is required.
-- Apply security patches and updates to the operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries.
-- Educate users and administrators on the risks associated with registry queries and the importance of adhering to security best practices to prevent unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_hosts_file_access.toml b/rules_building_block/discovery_hosts_file_access.toml
index c63ae32c035..8a3177bf266 100644
--- a/rules_building_block/discovery_hosts_file_access.toml
+++ b/rules_building_block/discovery_hosts_file_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -38,52 +38,6 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name in ("vi", "nano", "cat", "more", "less") and process.args == "/etc/hosts"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 System Hosts File Access
-
-The system hosts file maps hostnames to IP addresses, facilitating local network navigation. Adversaries exploit this by accessing the file to identify potential targets for lateral movement. The detection rule monitors the initiation of processes like 'vi', 'nano', or 'cat' accessing '/etc/hosts', signaling potential reconnaissance activities by unauthorized users.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments, ensuring they match the query criteria: process.name in ("vi", "nano", "cat", "more", "less") and process.args == "/etc/hosts".
-- Check the user account associated with the process initiation to determine if it is a known and authorized user.
-- Investigate the timestamp of the event to correlate with any other suspicious activities or anomalies in the system logs around the same time.
-- Examine the parent process of the alerted process to understand how the process was initiated and if it was part of a legitimate workflow.
-- Use Osquery to list recent processes executed by the user to identify any other potentially suspicious activities:
-  ```sql
-  SELECT pid, name, path, cmdline, start_time FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');
-  ```
-- Analyze network logs to identify any unusual outbound connections or data transfers that might indicate lateral movement attempts following the hosts file access.
-- Review system access logs to check for any unauthorized login attempts or successful logins around the time of the alert.
-- Investigate any recent changes to the /etc/hosts file by checking file modification times and comparing with known baselines or backups.
-- Cross-reference the alert with any other security alerts or incidents involving the same user or system to identify patterns or coordinated attacks.
-- Consult threat intelligence sources to determine if there are any known campaigns or adversaries that use similar tactics, techniques, and procedures (TTPs) as identified in the alert.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often access the '/etc/hosts' file using tools like 'vi', 'nano', or 'cat' for legitimate purposes such as updating host entries or troubleshooting network issues. These activities can trigger false positives.
-- Automated scripts: Some automated maintenance or monitoring scripts may read the '/etc/hosts' file to verify or log network configurations, leading to benign alerts.
-- Software installations or updates: Certain software installations or updates may access the '/etc/hosts' file to configure network settings, which can be mistaken for suspicious activity.
-- User education: Educate users about the importance of the '/etc/hosts' file and encourage them to report any legitimate access they perform, which can help in distinguishing between normal and suspicious activities.
-- Exception handling: Implement exceptions for known administrative accounts or specific scripts that regularly access the '/etc/hosts' file, reducing unnecessary alerts while maintaining security oversight.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to determine if unauthorized access to the '/etc/hosts' file was part of a larger attack, checking for other signs of compromise.
-- Review system logs and process execution history to identify any additional suspicious activities or processes initiated by unauthorized users.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals a broader threat or if sensitive data may have been accessed.
-- Restore the system to its operational state by reverting any unauthorized changes to the '/etc/hosts' file and ensuring all system configurations are secure.
-- Implement enhanced logging policies to capture detailed process execution and file access events, ensuring future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and identify potential threats in real-time.
-- Apply system hardening measures, such as restricting access to critical files like '/etc/hosts' to only authorized users and processes.
-- Educate users and administrators on the importance of maintaining secure configurations and recognizing signs of potential reconnaissance activities.
-- Regularly review and update security policies and procedures to align with the latest MITRE ATT&CK framework tactics and techniques, ensuring comprehensive threat coverage."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_internet_capabilities.toml b/rules_building_block/discovery_internet_capabilities.toml
index 8b619a83f2c..2ae9e761e72 100644
--- a/rules_building_block/discovery_internet_capabilities.toml
+++ b/rules_building_block/discovery_internet_capabilities.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -37,49 +37,6 @@ host.os.type:windows and event.category:process and event.type:start and
 process.name.caseless:("ping.exe" or "tracert.exe" or "pathping.exe") and
 not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Discovery of Internet Capabilities via Built-in Tools
-
-Built-in network diagnostic tools like ping, tracert, and pathping are essential for assessing connectivity and network paths. Adversaries exploit these tools to verify internet access and map network routes, aiding in C2 communication. The detection rule identifies suspicious use of these tools by monitoring process starts and filtering out benign local addresses, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand which built-in tool (ping.exe, tracert.exe, or pathping.exe) was used and the specific arguments passed to the process.
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other events around the same time.
-- Investigate the user account associated with the process start event to determine if it is a legitimate user or potentially compromised.
-- Examine the source IP address and destination IP addresses involved in the process arguments to identify any external or unusual network connections.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('ping.exe', 'tracert.exe', 'pathping.exe');` to list all instances of these processes and their command-line arguments.
-- Analyze the parent process of the suspicious activity to understand how the built-in tool was executed and if it was initiated by another suspicious process.
-- Check for any related network activity logs that might indicate data exfiltration or communication with known malicious IP addresses.
-- Investigate any recent changes to the system's network configuration that could have facilitated the use of these tools for malicious purposes.
-- Review historical data to determine if there have been previous instances of similar activity on the same host or by the same user account.
-- Cross-reference the identified IP addresses with threat intelligence sources to check for any known associations with malicious activity or C2 servers.
-
-### False positive analysis
-
-- Routine network diagnostics by IT personnel can trigger false positives, as they often use tools like ping, tracert, and pathping for legitimate troubleshooting. To manage this, create exceptions for known IT user accounts or specific IP addresses associated with IT operations.
-- Automated monitoring systems or scripts that regularly check network connectivity might also cause false positives. Exclude these processes by identifying their unique command-line arguments or execution patterns.
-- Scheduled tasks or maintenance scripts that include network diagnostics as part of their operation can be mistaken for malicious activity. Document and exclude these tasks by their scheduled times or specific hostnames.
-- Software updates or installations that perform network checks to verify connectivity can be flagged. Identify and exclude these processes by their parent process names or associated software update services.
-- Remote management tools that use these network diagnostic commands as part of their functionality can lead to false positives. Whitelist these tools by their process hashes or digital signatures to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further communication with potential C2 servers.
-- Conduct a thorough investigation of the process execution logs to identify any unauthorized use of network diagnostic tools and determine the scope of the compromise.
-- Review and analyze network traffic logs to identify any suspicious outbound connections that may indicate C2 communication.
-- Remove any malicious software or scripts identified during the investigation from the affected system.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if other systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and network activity for future investigations.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by reimaging the affected machine and restoring data from verified backups.
-- Implement network segmentation and access controls to limit the use of built-in network diagnostic tools to authorized personnel only."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
index 9a07dc1d95d..e6ea704526d 100644
--- a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
+++ b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/12"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -58,49 +58,6 @@ query = '''
 host.os.type:linux and event.category:file and event.action:"opened-file" and file.path:"/proc/modules" and
 not process.name:(python* or chef-client)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Enumeration of Kernel Modules via Proc
-
-Loadable Kernel Modules (LKMs) enhance kernel functionality dynamically. The `/proc/modules` file lists these modules, aiding utilities like `lsmod` in module management. Adversaries exploit this by querying `/proc/modules` to gather system insights, potentially identifying security weaknesses. The detection rule flags unauthorized access attempts to this file, excluding benign processes, to identify suspicious enumeration activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the event category is 'file' and the action is 'opened-file', ensuring it matches the rule criteria.
-- Verify the file path is indeed '/proc/modules' to confirm the alert is related to kernel module enumeration.
-- Check the process name that triggered the alert. Ensure it is not a benign process like 'python*' or 'chef-client', which are excluded in the rule.
-- Investigate the user account associated with the process to determine if it has legitimate reasons to access '/proc/modules'.
-- Examine the process's parent process to understand the context in which the access attempt was made.
-- Use Osquery to gather more information about the process. For example, run the query: `SELECT * FROM processes WHERE name = '<process_name>';` to get details about the process that accessed '/proc/modules'.
-- Check the system's recent login history to identify any unusual or unauthorized access patterns that might correlate with the alert.
-- Review system logs for any other suspicious activities around the time of the alert, such as failed login attempts or other file access anomalies.
-- Investigate any network connections established by the process to determine if there is any communication with known malicious IPs or domains.
-- Correlate this alert with other security events in the environment to identify if this is part of a broader attack pattern or isolated incident.
-
-### False positive analysis
-
-- System management tools and scripts that regularly check kernel module status for legitimate purposes may trigger false positives. These include automated monitoring tools or configuration management systems like Ansible or Puppet.
-- Scheduled maintenance scripts that verify system integrity by accessing `/proc/modules` can also be mistaken for suspicious activity.
-- Developers and system administrators using custom scripts to monitor or log kernel module changes might inadvertently cause false positives.
-- To manage these false positives, users can create exceptions for known benign processes by adding them to the exclusion list in the detection rule, similar to the existing exclusion for `python*` or `chef-client`.
-- Regularly review and update the exclusion list to include any new legitimate processes that frequently access `/proc/modules` to ensure accurate detection without compromising security.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
-- Conduct a thorough investigation to identify the process or user responsible for accessing /proc/modules, focusing on any unauthorized or suspicious activity.
-- Review system logs and security alerts to gather additional context and determine if the access was part of a broader attack pattern.
-- If malicious activity is confirmed, remove any unauthorized kernel modules and restore the system to a known good state using backups or system snapshots.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed access attempts to critical files like /proc/modules, ensuring that logs are stored securely and monitored regularly.
-- Integrate threat intelligence feeds to correlate the activity with known attack patterns and adversary tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
-- Apply system hardening measures, such as restricting access to /proc/modules to only trusted processes and users, and regularly updating and patching the system to mitigate vulnerabilities.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users and administrators on the importance of monitoring and securing kernel modules to prevent future unauthorized access attempts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_modprobe_enumeration.toml b/rules_building_block/discovery_linux_modprobe_enumeration.toml
index 40648ebaf93..1a41af5ad2f 100644
--- a/rules_building_block/discovery_linux_modprobe_enumeration.toml
+++ b/rules_building_block/discovery_linux_modprobe_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/08"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -61,48 +61,6 @@ file.path : ("/etc/modprobe.conf" or "/etc/modprobe.d" or /etc/modprobe.d/*) and
   aide or modprobe or python*
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Modprobe File Event
-
-Modprobe manages Linux kernel modules, essential for system functionality. Adversaries may exploit modprobe configurations to load unauthorized modules, potentially bypassing security, escalating privileges, or concealing activities. The detection rule identifies suspicious file access in modprobe directories, excluding benign processes, to flag potential tampering attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific file path triggered the event, focusing on `/etc/modprobe.conf` or files within `/etc/modprobe.d`.
-- Identify the process that accessed the modprobe file by examining the `process.name` field in the alert. Determine if the process is expected or potentially malicious.
-- Check the `host.os.type` field to confirm the operating system is Linux, ensuring the alert is relevant to the environment.
-- Investigate the `event.action` field to verify that the action was indeed "opened-file," indicating potential unauthorized access.
-- Use Osquery to list all processes that have accessed modprobe files recently. Example query: `SELECT pid, name, path FROM processes WHERE path LIKE '/etc/modprobe%' ORDER BY start_time DESC;`
-- Cross-reference the process ID and name with known benign processes to rule out false positives.
-- Examine system logs for any additional file access or modification events around the same time as the alert to identify patterns or repeated access attempts.
-- Investigate the user account associated with the process that accessed the modprobe file to determine if it has the necessary permissions and if the access was legitimate.
-- Review recent changes to the modprobe files by checking file modification timestamps and comparing them with known change management records.
-- Analyze network activity from the host to identify any suspicious outbound connections that may correlate with the timing of the modprobe file access.
-
-### False positive analysis
-
-- Routine system maintenance tasks or updates may trigger the rule, as legitimate processes might access modprobe files during these operations. For example, package managers like `apt` or `yum` could access these files when installing or updating software.
-- Custom scripts or administrative tools that interact with kernel modules for legitimate purposes might also be flagged. These could include backup scripts or system monitoring tools that are not part of the default exclusion list.
-- Users can manage these false positives by reviewing the processes that are accessing the modprobe files and determining if they are part of regular system operations. If so, they can be added to the exclusion list in the detection rule to prevent future alerts.
-- It's important to regularly review and update the exclusion list to ensure that new legitimate processes are not mistakenly flagged, while also ensuring that potentially malicious activities are not overlooked.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker.
-- Conduct a thorough investigation to identify the source of the suspicious modprobe file event, examining logs and system changes to determine if unauthorized kernel modules were loaded.
-- Verify the integrity of the modprobe configuration files and compare them against known good baselines to identify any unauthorized modifications.
-- Remove any unauthorized or malicious kernel modules identified during the investigation to restore the system's integrity.
-- Restore the modprobe configuration files from a trusted backup if any tampering is detected, ensuring that only legitimate modules are loaded.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
-- Implement enhanced logging and monitoring for modprobe-related activities, ensuring that all file access and modifications are captured for future investigations.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework data to improve detection capabilities and contextual understanding of similar threats.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as restricting access to modprobe directories and enforcing strict user permissions.
-- Educate system administrators and security personnel on the risks associated with kernel module manipulation and the importance of maintaining secure configurations."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_sysctl_enumeration.toml b/rules_building_block/discovery_linux_sysctl_enumeration.toml
index cdb86c65dfe..4da1313644c 100644
--- a/rules_building_block/discovery_linux_sysctl_enumeration.toml
+++ b/rules_building_block/discovery_linux_sysctl_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/08"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -60,49 +60,6 @@ file.path : ("/etc/sysctl.conf" or "/etc/sysctl.d" or /etc/sysctl.d/*) and not p
   dpkg or dockerd or unattended-upg or systemd-sysctl or python* or auditbeat or dpkg or pool*
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Sysctl File Event
-
-Sysctl configuration files in Linux systems manage kernel parameters, crucial for system performance and security. Adversaries may exploit these files to alter system behavior, potentially destabilizing or compromising the system. The detection rule identifies unauthorized access or changes to these files by monitoring file events and excluding legitimate processes, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to understand which sysctl configuration file was accessed or modified, focusing on the `file.path` field to identify the specific file involved.
-- Examine the `event.action` field to determine the type of file operation (e.g., "opened-file", "read-file", "wrote-to-file") that triggered the alert.
-- Identify the process responsible for the file event by reviewing the `process.name` field, and cross-reference it with known legitimate processes to confirm if it is indeed suspicious.
-- Check the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is specifically designed for Linux environments.
-- Investigate the user account associated with the process by examining the `user.name` field to determine if the access was performed by a legitimate or suspicious user.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name = '<suspicious_process_name>';` to retrieve details like process ID, parent process, and command line arguments.
-- Review recent system logs for any unusual activity around the time of the alert, focusing on authentication logs and other security-related logs.
-- Analyze the system's process tree to understand the parent-child relationship of the suspicious process, which can provide insights into how the process was initiated.
-- Check for any recent changes to the sysctl configuration files by comparing the current file contents with a known good baseline or backup, if available.
-- Investigate any network connections established by the suspicious process using Osquery: `SELECT * FROM socket_events WHERE pid = <suspicious_process_pid>;` to identify potential external communication.
-
-### False positive analysis
-
-- Routine system maintenance tasks can trigger false positives. For example, legitimate system updates or package installations may access sysctl files, especially if not all relevant processes are excluded in the detection rule.
-- Automated configuration management tools like Ansible, Puppet, or Chef might access sysctl files to ensure system configurations are consistent, leading to benign alerts.
-- Backup or monitoring software that reads system configuration files for integrity checks or data collection purposes can also cause false positives.
-- To manage these false positives, users can update the detection rule to exclude additional known legitimate processes by adding them to the `not process.name` list. This can include specific maintenance scripts or tools that are regularly used in the environment.
-- Regularly review and update the exclusion list to reflect changes in system management practices or new tools introduced into the environment, ensuring that only non-threatening behaviors are excluded.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
-- Conduct a thorough investigation to identify the source of the unauthorized access, focusing on recent changes to sysctl configuration files and correlating with process activity.
-- Review system logs and security alerts to determine if any other systems have been targeted or compromised.
-- Restore the sysctl configuration files from a known good backup to ensure system stability and security.
-- Apply patches and updates to the operating system and applications to mitigate any known vulnerabilities that may have been exploited.
-- Implement stricter access controls and permissions on sysctl configuration files to limit who can read or modify them.
-- Enhance logging and monitoring by integrating with a Security Information and Event Management (SIEM) system to detect future unauthorized access attempts.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate and train staff on recognizing and responding to suspicious activities related to system configuration files.
-- Consider deploying additional security measures such as intrusion detection systems (IDS) and endpoint detection and response (EDR) solutions to improve threat detection capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_system_information_discovery.toml b/rules_building_block/discovery_linux_system_information_discovery.toml
index 3cc11e5edc1..431c60f4301 100644
--- a/rules_building_block/discovery_linux_system_information_discovery.toml
+++ b/rules_building_block/discovery_linux_system_information_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/10"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -37,50 +37,6 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
   )
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Linux System Information Discovery
-
-Linux system information discovery involves commands like `uname`, `cat`, `more`, and `less` to gather system details such as kernel version, hardware, and configuration files. Adversaries exploit these to understand the environment and tailor their attacks. The detection rule identifies suspicious use of these commands, focusing on process initiation events and specific arguments that suggest system probing, thus flagging potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific command triggered the detection, focusing on the `process.name` and `process.args` fields.
-- Examine the `event.type` and `event.action` fields to confirm the nature of the process initiation and ensure it aligns with typical reconnaissance activities.
-- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised.
-- Investigate the parent process of the suspicious command to identify if it was spawned by a legitimate application or script.
-- Analyze the command execution context by reviewing the `process.args` field to understand the specific system information being queried.
-- Correlate the timing of the alert with other security events or logs to identify any related suspicious activities or patterns.
-- Use Osquery to gather additional context on the system. For example, run the following query to list recent commands executed by the user: `SELECT * FROM shell_history WHERE uid = (SELECT uid FROM users WHERE username = 'suspicious_user');`
-- Investigate network connections at the time of the alert to identify any unusual outbound connections that may indicate data exfiltration.
-- Review system logs for any anomalies or errors around the time of the alert that could provide additional context or evidence of compromise.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) of specific threat actors.
-
-### False positive analysis
-
-- Routine administrative tasks often involve the use of commands like `uname`, `cat`, `more`, and `less` to check system configurations, kernel versions, or hardware details, which can trigger false positives.
-- Automated scripts or monitoring tools that regularly check system status or configurations may also generate alerts, as they frequently execute these commands with arguments that match the detection criteria.
-- Developers and system administrators might use these commands during troubleshooting or system audits, leading to benign process initiation events being flagged.
-- To manage these false positives, users can create exceptions for known scripts or processes that are verified as non-threatening, ensuring they are excluded from triggering alerts.
-- Implementing a whitelist of trusted users or processes that regularly perform these actions can help reduce noise and focus on genuinely suspicious activities.
-- Regularly review and update the list of exceptions to adapt to changes in system administration practices or new tools that might be introduced into the environment.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the process events to confirm the nature and scope of the suspicious activity, focusing on the commands and arguments used.
-- Review user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the activity is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed command-line activity and process execution events for future investigations.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework into security monitoring tools to improve detection of similar tactics and techniques.
-- Restore the system to its operational state by applying necessary patches, updating configurations, and ensuring all security controls are active.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Implement system hardening measures, such as disabling unnecessary services, enforcing strong authentication mechanisms, and applying least privilege principles.
-- Educate users and administrators on recognizing and reporting suspicious activities to enhance organizational security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_linux_system_owner_user_discovery.toml b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
index a346df9537a..2e2c8d3def8 100644
--- a/rules_building_block/discovery_linux_system_owner_user_discovery.toml
+++ b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/10"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -37,49 +37,6 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and 
 process.name : ("whoami", "w", "who", "users", "id")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 System Owner/User Discovery Linux
-
-In Linux environments, commands like `whoami`, `w`, `who`, `users`, and `id` are used to identify the current user and other logged-in users. Adversaries exploit these tools to gather information about system ownership and user activity, aiding in privilege escalation and lateral movement. The detection rule monitors the execution of these commands, flagging potential misuse by correlating process start events with specific command executions, thus alerting analysts to suspicious user enumeration activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the specific command that triggered the alert by examining the `process.name` field.
-- Check the `user.name` field to identify the user account that executed the command and determine if it aligns with expected user behavior.
-- Investigate the `process.parent.name` field to understand the parent process that initiated the command, which may provide context on whether the execution was part of a legitimate workflow or potentially malicious activity.
-- Analyze the `host.name` field to determine if the activity occurred on a critical or sensitive system, which may elevate the priority of the investigation.
-- Examine the `process.command_line` field to see the full command executed, which can provide additional context or reveal if the command was part of a script or automated task.
-- Utilize Osquery to gather more information about the user and system context by running a query such as: `SELECT * FROM logged_in_users WHERE user = '<suspicious_user>';` to identify all sessions associated with the user.
-- Cross-reference the `event.timestamp` with other security logs (e.g., authentication logs, network logs) to identify any correlated suspicious activities around the same time.
-- Check for any recent changes in user privileges or group memberships that might indicate privilege escalation attempts.
-- Review historical data for similar command executions by the same user or on the same host to identify patterns or repeated suspicious behavior.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or campaigns.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use commands like `whoami`, `w`, `who`, `users`, and `id` as part of their regular system management activities. These legitimate uses can trigger false positives. To manage this, create exceptions for known administrator accounts or specific times when these tasks are typically performed.
-- Automated scripts: Some automated scripts or monitoring tools may execute these commands to gather system information for performance monitoring or auditing purposes. Identify and whitelist these scripts or processes to prevent unnecessary alerts.
-- Scheduled jobs: Cron jobs or other scheduled tasks might run these commands for reporting or maintenance purposes. Review and exclude these scheduled tasks from triggering alerts by specifying the exact command patterns and associated user accounts.
-- Development and testing environments: In environments where frequent testing and development occur, developers might use these commands to verify user permissions or system states. Consider excluding specific user groups or environments from the detection rule to reduce noise.
-- Security tools: Some security tools or agents might use these commands as part of their normal operation to collect user and system data. Verify the legitimacy of these tools and exclude their processes from the detection criteria.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or privilege escalation attempts.
-- Review system logs and security alerts to correlate the execution of user discovery commands with other suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team if the investigation reveals signs of a broader attack or advanced persistent threat (APT) activity.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and user context, to aid in future investigations.
-- Integrate threat intelligence feeds and MITRE ATT&CK framework data to enrich alerts with context about known adversary tactics and techniques.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in security controls and processes, and implement hardening measures such as disabling unnecessary services and enforcing least privilege access.
-- Educate users on recognizing and reporting suspicious activities to improve the organization's overall security posture.
-- Continuously monitor for any signs of re-infection or further malicious activity, adjusting detection rules and response strategies as necessary."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_net_share_discovery_winlog.toml b/rules_building_block/discovery_net_share_discovery_winlog.toml
index 27fae038da8..3194c52904e 100644
--- a/rules_building_block/discovery_net_share_discovery_winlog.toml
+++ b/rules_building_block/discovery_net_share_discovery_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/14"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,49 +42,6 @@ sequence by user.name, source.port, source.ip with maxspan=15s
   winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and 
   source.ip != null and source.ip != "0.0.0.0" and source.ip != "::1" and source.ip != "::" and source.ip != "127.0.0.1"]
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Network Share Discovery
-
-Network shares allow users to access files and resources across systems, facilitating collaboration. However, adversaries exploit this by scanning for shared folders, especially administrative shares, to gather intelligence or move laterally within a network. The detection rule identifies suspicious access attempts to default administrative shares from non-local IPs, signaling potential reconnaissance or lateral movement activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the `user.name`, `source.ip`, and `source.port` involved in the suspicious access attempt to the administrative shares.
-- Verify the legitimacy of the `source.ip` by checking if it belongs to a known and trusted network segment or if it is an external or unexpected internal IP address.
-- Cross-reference the `user.name` with organizational records to determine if the user should have access to the targeted network shares.
-- Check historical logs for previous access attempts from the same `source.ip` or `user.name` to identify patterns or repeated suspicious behavior.
-- Use Osquery to gather more information about the system associated with the `source.ip`. For example, run the following query to list active network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<source.ip>';`
-- Investigate the system associated with the `source.ip` for signs of compromise, such as unusual processes or services running, by using endpoint detection and response (EDR) tools.
-- Analyze the timing and frequency of the access attempts to determine if they align with normal user activity or if they occur at unusual times.
-- Check for any recent changes or updates to the system or network configuration that might explain the access attempt.
-- Review any related alerts or logs from other security tools that might provide additional context or corroborate the suspicious activity.
-- Consult with the user associated with the `user.name` to verify if they initiated the access attempt and if they are aware of any potential security issues.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate IT administrators may access administrative shares for maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known administrator IP addresses or user accounts.
-- Automated backup or monitoring systems: These systems often access network shares to perform regular backups or health checks. Identify and exclude these systems by their IP addresses or service accounts to prevent false positives.
-- Software updates and patch management: Some update services may access administrative shares to deploy patches. Recognize these services and exclude their IPs or associated user accounts from triggering the rule.
-- Internal security scans: Security tools that perform vulnerability assessments or compliance checks might access network shares. Document these tools and exclude their IPs or user accounts to avoid unnecessary alerts.
-- Development and testing environments: Developers or automated testing scripts might access network shares as part of their workflow. Identify these environments and exclude relevant IPs or user accounts to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to identify the source of the suspicious access attempts, focusing on the non-local IP addresses involved.
-- Review and analyze logs from the affected system and network devices to gather more context on the access attempts and identify any other potentially compromised systems.
-- Change passwords for accounts that were used to access the administrative shares, especially if they have elevated privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement stricter access controls and permissions on network shares, ensuring that only authorized users have access to administrative shares.
-- Enhance logging policies to include detailed auditing of network share access and integrate with a security information and event management (SIEM) system for real-time monitoring.
-- Apply security patches and updates to all systems to mitigate known vulnerabilities that could be exploited for lateral movement.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users on recognizing and reporting suspicious activities to improve the organization's overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
index 213c9d24bb1..534e6b19c1c 100644
--- a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
+++ b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -40,50 +40,6 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
   (process.name == "getent" and process.args in ("passwd", "group"))
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Account or Group Discovery via Built-In Tools
-
-Built-in tools like `groups`, `id`, `dscl`, and `getent` are essential for managing and querying user and group information in Unix-like systems. Adversaries exploit these tools to enumerate accounts and groups, gaining insights into system configurations and potential targets. The detection rule identifies suspicious use of these tools by monitoring process execution patterns and specific arguments, flagging potential unauthorized discovery activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the alert, focusing on fields like `process.name` and `process.args`.
-- Check the `event.timestamp` to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
-- Investigate the `user.name` and `user.id` fields to identify the user account associated with the process execution and assess if the account has a legitimate reason to perform such actions.
-- Examine the `host.name` or `host.ip` fields to determine which system the activity originated from and assess its role within the network.
-- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('groups', 'id', 'dscl', 'dscacheutil', 'getent');` to identify any other related processes that may have been executed.
-- Analyze the `parent.process.name` and `parent.process.id` fields to understand the parent process that initiated the suspicious activity, which might provide insights into the origin of the command.
-- Review historical logs for the same `process.name` and `process.args` to determine if this is a recurring pattern or an isolated incident.
-- Check for any recent changes in user permissions or group memberships that might explain the use of these tools, focusing on the `process.args` that reference user or group files.
-- Investigate any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration attempts.
-- Correlate the findings with other security alerts or incidents to determine if this activity is part of a larger attack campaign or an isolated event.
-
-### False positive analysis
-
-- Routine administrative tasks can trigger this rule, as system administrators often use tools like `groups`, `id`, `dscl`, and `getent` for legitimate purposes such as user account management and system maintenance. 
-- Automated scripts or scheduled jobs that perform regular system audits or backups may also execute these commands, leading to false positives.
-- Security software or monitoring tools that periodically check system configurations and user permissions might invoke these commands, resulting in benign alerts.
-- To manage these false positives, users can create exceptions for known administrative accounts or specific scripts that are verified as non-threatening.
-- Implementing a baseline of normal system behavior can help distinguish between legitimate use and potential threats, allowing for more accurate filtering of alerts.
-- Regularly updating the list of approved processes and arguments in the detection rule can reduce the occurrence of false positives by excluding recognized safe activities.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying all accounts and groups accessed by the adversary.
-- Review system logs and security alerts to trace the adversary's activities and identify any additional compromised systems or accounts.
-- Change passwords for all potentially compromised accounts and enforce multi-factor authentication to enhance security.
-- Remove any unauthorized accounts or groups created by the adversary and ensure all legitimate accounts have appropriate permissions.
-- Restore the system from a known good backup to ensure no malicious changes persist.
-- Implement enhanced logging and monitoring policies to capture detailed information on account and group access activities.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Educate users and administrators on recognizing and reporting suspicious activities to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_of_domain_groups.toml b/rules_building_block/discovery_of_domain_groups.toml
index de68c61530b..6a1122dd0d6 100644
--- a/rules_building_block/discovery_of_domain_groups.toml
+++ b/rules_building_block/discovery_of_domain_groups.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -39,48 +39,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   process.name in ("ldapsearch", "dscacheutil") or (process.name == "dscl" and process.args : "*-list*")
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Discovery of Domain Groups
-
-In Linux environments, commands like `ldapsearch`, `dscacheutil`, and `dscl` are used for querying domain group information, aiding system administrators in managing user permissions. Adversaries exploit these commands to gather intelligence on group memberships, which can inform privilege escalation strategies. The detection rule identifies suspicious use of these commands by monitoring process execution patterns, helping to flag potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command executed, focusing on the `process.name` and `process.args` fields to understand the context of the command usage.
-- Check the `host.os.type` field to confirm the operating system is Linux, ensuring the alert is relevant to the environment.
-- Investigate the `event.type` and `event.action` fields to verify the nature of the process execution and ensure it aligns with the suspicious activity pattern.
-- Examine the user account associated with the process execution to determine if the activity is expected or if the account has a history of similar actions.
-- Cross-reference the timestamp of the event with other logs to identify any correlated activities or anomalies around the same time.
-- Use Osquery to gather additional context on the system by running a query such as: `SELECT * FROM processes WHERE name IN ('ldapsearch', 'dscacheutil', 'dscl');` to list all instances of these processes and their arguments.
-- Analyze the network connections at the time of the event to identify any unusual outbound connections that may indicate data exfiltration or further reconnaissance.
-- Review historical data for patterns of similar command executions to determine if this is part of a broader trend or a one-off event.
-- Check for any recent changes in user permissions or group memberships that could be related to the suspicious command execution.
-- Consult threat intelligence sources to see if there are any known campaigns or adversaries that use similar techniques, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use commands like `ldapsearch`, `dscacheutil`, and `dscl` for legitimate purposes such as managing user accounts and permissions. These activities can trigger the detection rule, leading to false positives.
-- Automated scripts: Scheduled scripts or cron jobs that perform regular checks or updates on user and group information may execute these commands, resulting in benign alerts.
-- Monitoring and auditing tools: Security and compliance tools that audit system configurations and user permissions might use these commands as part of their normal operations, causing false positives.
-- To manage false positives, users can create exceptions for known administrative accounts or specific scripts that frequently execute these commands. This can be done by adding filters to exclude processes initiated by trusted users or scripts from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the activity, including identifying all systems and accounts accessed by the adversary.
-- Review logs and alerts to identify any additional suspicious activities or related incidents, focusing on the use of `ldapsearch`, `dscacheutil`, and `dscl` commands.
-- Change passwords and review permissions for any accounts that may have been compromised or accessed during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for command execution and process creation events to detect similar activities in the future.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs).
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are applied.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures accordingly.
-- Implement hardening measures such as restricting the use of domain enumeration commands to authorized personnel only and using multi-factor authentication (MFA) for sensitive accounts."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_posh_generic.toml b/rules_building_block/discovery_posh_generic.toml
index e7e1c09a9b1..99cc4afdb5d 100644
--- a/rules_building_block/discovery_posh_generic.toml
+++ b/rules_building_block/discovery_posh_generic.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 
 
 [rule]
@@ -140,49 +140,6 @@ event.category:process and host.os.type:windows and
   ) and
   not user.id : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Discovery Capabilities
-
-PowerShell is a powerful scripting language and automation framework used in Windows environments for system administration. Adversaries exploit its capabilities to gather information about the system, network, and domain, such as user accounts, network configurations, and installed software. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and methods indicative of reconnaissance efforts, while excluding benign processes and trusted user accounts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific PowerShell cmdlet or method triggered the detection, focusing on the `powershell.file.script_block_text` field for context.
-- Check the `user.id` field to identify the user account associated with the PowerShell activity and determine if it is a known or trusted account.
-- Investigate the `event.category:process` to gather information about the parent process and any related child processes to understand the context of the PowerShell execution.
-- Examine the `host.os.type:windows` field to confirm the operating system and ensure the environment aligns with expected configurations.
-- Use Osquery to gather additional context about the system. For example, run the following query to list all running processes and their command-line arguments: `SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%powershell%';`
-- Cross-reference the PowerShell script block text with known benign scripts or administrative tasks to rule out false positives.
-- Analyze network logs to identify any unusual outbound connections or data exfiltration attempts that may correlate with the PowerShell activity.
-- Review recent changes to the system, such as new software installations or updates, that might explain the PowerShell activity.
-- Check for any other security alerts or logs related to the same user or system to identify potential patterns or additional suspicious behavior.
-- Consult threat intelligence sources to determine if the detected PowerShell activity matches known attack patterns or indicators of compromise.
-
-### False positive analysis
-
-- **System Administration Tasks**: Legitimate system administrators often use PowerShell cmdlets for routine tasks such as checking system configurations, user accounts, and network settings. These activities can trigger the rule. To manage this, create exceptions for known administrator accounts or specific cmdlets used in regular maintenance.
-- **Automated Scripts and Tools**: Some automated scripts or third-party tools may use PowerShell for legitimate discovery activities, such as inventory management or system monitoring. Identify these scripts and tools, and exclude their specific processes or user accounts from the rule.
-- **Security Software Operations**: Security software may use PowerShell to gather system information for protection purposes. Exclude processes associated with trusted security software to prevent false positives.
-- **Software Updates and Installations**: During software updates or installations, PowerShell may be used to check system compatibility or configurations, which can be mistaken for reconnaissance. Exclude known update processes or installation scripts from the rule.
-- **Development and Testing Environments**: Developers and testers might use PowerShell to simulate various scenarios, including discovery activities. Consider excluding user accounts or processes associated with development and testing environments to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the PowerShell script execution to determine the scope and intent of the activity, focusing on the cmdlets and methods used.
-- Review user account activity and permissions to identify any unauthorized access or privilege escalation attempts.
-- Remove any malicious scripts or files identified during the investigation and ensure that all unauthorized changes are reverted.
-- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed PowerShell activity, including script block logging and transcription.
-- Integrate security solutions such as SIEM or EDR to improve detection and response capabilities for similar threats in the future.
-- Educate users on recognizing phishing attempts and suspicious activities to reduce the risk of initial compromise.
-- Restore the system to its operational state by verifying the integrity of critical system files and configurations.
-- Harden the system by disabling unnecessary services, enforcing strong password policies, and implementing network segmentation to limit lateral movement."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/discovery_posh_password_policy.toml b/rules_building_block/discovery_posh_password_policy.toml
index 6a532ee0eb5..3178120fd4f 100644
--- a/rules_building_block/discovery_posh_password_policy.toml
+++ b/rules_building_block/discovery_posh_password_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -91,50 +91,6 @@ event.category: "process" and host.os.type:windows and
   )
   and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Password Policy Discovery Capabilities
-
-PowerShell is a powerful scripting language used for automating tasks in Windows environments, including querying Active Directory for password policies. Adversaries exploit this by executing scripts to discover password policies, aiding in lateral movement and privilege escalation. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and script patterns associated with password policy queries, while excluding known benign scripts and system accounts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific PowerShell cmdlet or script pattern triggered the alert, focusing on fields like `powershell.file.script_block_text`.
-- Check the `user.id` field to identify the user account associated with the suspicious activity, ensuring it is not a known system account like "S-1-5-18".
-- Investigate the `event.category` and `host.os.type` fields to confirm the activity occurred on a Windows host and is categorized as a process event.
-- Examine the script block text for any of the specific cmdlets or methods such as "Get-ADDefaultDomainPasswordPolicy" or "ActiveDirectory.DirectorySearcher" to determine the nature of the password policy query.
-- Cross-reference the `powershell.file.script_block_text` with known benign scripts or exclusions, such as "sentinelbreakpoints" or "43c15630-959c-49e4-a977-758c5cc93408", to rule out false positives.
-- Use Osquery to gather additional context on the process execution. For example, run the following query to list recent PowerShell executions: `SELECT * FROM processes WHERE name = 'powershell.exe';`
-- Investigate the parent process of the PowerShell execution to determine if it was initiated by a legitimate application or a potentially malicious process.
-- Check for any network connections or remote execution attempts associated with the PowerShell process, particularly if WinRM is involved, to assess potential lateral movement.
-- Review historical logs for any previous similar activities by the same user or on the same host to identify patterns or repeated attempts.
-- Correlate the findings with other security alerts or logs from the same timeframe to build a comprehensive picture of the potential threat actor's activities.
-
-### False positive analysis
-
-- Known false positives may include legitimate administrative scripts that query Active Directory for password policies as part of routine security audits or compliance checks. These scripts often use the same cmdlets and methods flagged by the detection rule.
-- System administrators using PowerShell to manage password policies across multiple domains might trigger the rule, especially if they use custom scripts that resemble the patterns identified in the detection rule.
-- Security tools or monitoring solutions that perform regular checks on password policies for reporting purposes can also generate false positives if they utilize PowerShell scripts with similar characteristics.
-- To manage these false positives, users can create exceptions for specific script block texts that are known to be benign, such as those used by trusted administrative tools or scripts.
-- Excluding specific user accounts, such as those belonging to system administrators or service accounts that regularly perform these tasks, can help reduce false positives. This can be done by adding their user IDs to the exclusion list.
-- Regularly reviewing and updating the exclusion list to include new benign scripts or accounts as they are identified can help maintain the balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation to identify the source of the PowerShell script execution, including reviewing logs for suspicious user activity and correlating with known threat intelligence.
-- Terminate any malicious PowerShell processes identified during the investigation to halt ongoing unauthorized activities.
-- Reset passwords for any compromised accounts and enforce a password policy that includes complexity requirements and regular expiration.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging for PowerShell activities, including script block logging and transcription, to improve future detection and investigation capabilities.
-- Integrate security information and event management (SIEM) solutions with threat intelligence feeds to identify and respond to similar threats more effectively.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure that all security configurations are in place.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary services like WinRM, applying least privilege principles, and conducting regular security awareness training for users."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_potential_memory_seeking_activity.toml b/rules_building_block/discovery_potential_memory_seeking_activity.toml
index 63791094020..5da12a7bb77 100644
--- a/rules_building_block/discovery_potential_memory_seeking_activity.toml
+++ b/rules_building_block/discovery_potential_memory_seeking_activity.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/18"
 
 [rule]
 author = ["Elastic"]
@@ -49,49 +49,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   process.args like "/var/tmp/dracut*"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Memory Seeking Activity
-
-In Unix-based systems, utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` are used for legitimate data processing tasks, including reading and comparing file contents. However, adversaries can exploit these tools to probe memory addresses, potentially setting the stage for further exploitation. The detection rule identifies suspicious executions of these utilities, filtering out benign use cases by examining process arguments and parent processes, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific utility and arguments that triggered the alert, focusing on the `process.name` and `process.args` fields.
-- Examine the `process.parent.name` and `process.parent.args` fields to understand the context in which the utility was executed and determine if it aligns with known benign processes or scripts.
-- Check the `process.parent.executable` and `process.parent.command_line` fields to identify the full path and command line of the parent process, which may provide additional context about the execution environment.
-- Investigate the user account associated with the process by examining the `user.name` field to determine if the activity is consistent with the user's typical behavior or role.
-- Use Osquery to gather additional context about the process and its parent. For example, run the following Osquery query to list recent processes executed by the same user: `SELECT pid, name, path, cmdline, parent FROM processes WHERE uid = (SELECT uid FROM users WHERE username = '<username>') ORDER BY start_time DESC LIMIT 10;`
-- Analyze system logs and other security tools for any related or preceding suspicious activity involving the same user or process, which might indicate a broader attack pattern.
-- Check for any network connections initiated by the process or its parent using network monitoring tools or logs to identify potential data exfiltration or command-and-control activity.
-- Review file system changes around the time of the alert, focusing on any files accessed or modified by the process, to identify potential data tampering or reconnaissance.
-- Correlate the alert with other security events or alerts from the same host or network segment to identify potential coordinated or multi-stage attacks.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware families.
-
-### False positive analysis
-
-- Legitimate system maintenance scripts: Some system maintenance scripts may use utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` for routine tasks such as log file analysis or data processing. These scripts can trigger the rule if they match the specified arguments. Users can handle these by identifying the specific scripts and adding their parent process names or command lines to the exclusion list.
-- Backup and data migration processes: Automated backup or data migration processes might use these utilities to read or compare large data sets. If these processes are known and trusted, users can exclude them by specifying the parent executable paths or command lines in the exclusion criteria.
-- Security and monitoring tools: Some security tools or monitoring agents might use these utilities to perform legitimate checks on system files or memory. Users should verify the legitimacy of these tools and exclude their parent processes or command lines if they are frequently triggering the rule.
-- Development and testing environments: Developers or testers might use these utilities during debugging or testing phases, especially when working with memory dumps or binary files. Users can exclude specific development tools or scripts by adding their parent process details to the exclusion list.
-- Custom scripts and automation: Organizations often have custom scripts that utilize these utilities for various automation tasks. Users should review these scripts and, if deemed non-threatening, add their parent process names or command lines to the exclusion list to prevent false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the suspicious process executions to determine if they were part of a legitimate operation or a potential attack. Review process arguments and parent processes for anomalies.
-- Analyze system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary.
-- If malicious activity is confirmed, terminate any unauthorized processes and remove any malicious files or scripts identified during the investigation.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships, to aid in future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for potential threats.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are in place.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Implement hardening measures such as disabling unnecessary utilities, enforcing least privilege access, and conducting regular security audits to reduce the attack surface and prevent similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
index c06105be566..d3826371012 100644
--- a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
+++ b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -36,49 +36,6 @@ process where event.type == "start" and event.action in ("exec", "exec_event") a
 ) and 
 not process.parent.name in ("amazon-ssm-agent", "snap")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Process Discovery via Built-In Applications
-
-Built-in applications like `ps`, `pstree`, `htop`, and `pgrep` are essential for system administrators to monitor and manage processes on endpoints. However, adversaries exploit these tools to gain insights into running processes, aiding in lateral movement or privilege escalation. The detection rule identifies suspicious use of these tools by monitoring process start events, filtering out benign parent processes like system management agents, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name matches one of the built-in tools: `ps`, `pstree`, `htop`, or `pgrep`.
-- Check the `event.type` and `event.action` fields to ensure the event corresponds to a process start with actions like "exec" or "exec_event".
-- Investigate the `process.parent.name` to verify it is not a benign process like "amazon-ssm-agent" or "snap", which are filtered out in the detection rule.
-- Examine the timestamp of the event to determine if it coincides with any known scheduled tasks or maintenance windows.
-- Correlate the event with user activity by checking the user account associated with the process start event to identify if it aligns with expected behavior.
-- Use Osquery to gather additional context about the process. For example, run the query: `SELECT * FROM processes WHERE name IN ('ps', 'pstree', 'htop', 'pgrep');` to list all instances of these processes and their details.
-- Investigate the command line arguments used with the process to identify any unusual or suspicious parameters that could indicate malicious intent.
-- Check for any network connections or file modifications initiated by the process to assess if it is part of a larger attack chain.
-- Review historical data to determine if there have been previous instances of similar process discovery activities on the endpoint.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors associated with the use of these tools in a malicious context.
-
-### False positive analysis
-
-- System administrators and automated scripts often use built-in tools like `ps`, `pstree`, `htop`, and `pgrep` for legitimate monitoring and management tasks, which can trigger false positives in the detection rule.
-- Regularly scheduled maintenance tasks or health checks performed by IT teams may also appear as suspicious activity if they involve these tools.
-- To manage these false positives, users can create exceptions for known benign parent processes or specific user accounts that frequently execute these commands as part of their routine operations.
-- Implementing a whitelist for certain processes or users that are verified to perform legitimate activities can help reduce noise and focus on truly suspicious events.
-- Monitoring the frequency and context of these tool executions can aid in distinguishing between normal administrative use and potential malicious activity.
-
-### Response and remediation
-
-- Immediately isolate the affected endpoint from the network to prevent further lateral movement by the adversary.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or privilege escalation attempts.
-- Review process execution logs to identify any unusual patterns or anomalies that could indicate malicious activity.
-- Terminate any suspicious processes identified during the investigation to prevent further exploitation.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is confirmed to be part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process execution data, including command-line arguments and parent-child process relationships.
-- Integrate threat intelligence feeds to correlate detected activities with known threat actor tactics, techniques, and procedures (TTPs) as outlined in the MITRE ATT&CK framework.
-- Restore the system to its operational state by applying security patches, updating antivirus definitions, and ensuring all security controls are functioning correctly.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures such as disabling unnecessary built-in tools or restricting their use to authorized personnel only.
-- Provide training and awareness sessions for system administrators and users to recognize signs of process discovery attempts and report suspicious activities promptly."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_signal_unusual_user_host.toml b/rules_building_block/discovery_signal_unusual_user_host.toml
index 524063c3552..ac2bc337f90 100644
--- a/rules_building_block/discovery_signal_unusual_user_host.toml
+++ b/rules_building_block/discovery_signal_unusual_user_host.toml
@@ -2,7 +2,7 @@
 bypass_bbr_timing = true
 creation_date = "2023/10/10"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/01"
 
 [rule]
 author = ["Elastic"]
@@ -39,48 +39,6 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
   "1d72d014-e2ab-4707-b056-9b96abe7b511"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Discovery Activity by User
-
-The 'Unusual Discovery Activity by User' detection rule identifies atypical behavior by monitoring alert data for unique host and user identifiers. This technology is crucial in environments to detect when adversaries exploit discovery techniques to gather system information. By correlating signals from multiple sources, the rule flags potential reconnaissance activities, helping analysts preemptively address threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the specific host.id and user.id involved in the unusual activity.
-- Cross-reference the host.os.type field to confirm the operating system is Windows, as specified in the query.
-- Examine the event.kind field to ensure the alert is based on a signal, indicating potential reconnaissance activity.
-- Investigate the specific Discovery building block rule IDs (e.g., "d68e95ad-1c82-4074-a12a-125fe10ac8ba") that triggered the alert to understand the context and type of discovery technique used.
-- Check historical data for the same host.id and user.id to determine if this activity is part of a pattern or a one-time occurrence.
-- Use Osquery to gather additional system information. For example, run the query: `SELECT * FROM processes WHERE user = '<user.id>' AND host = '<host.id>';` to identify any unusual processes initiated by the user on the host.
-- Analyze network logs for any unusual outbound connections from the host that might indicate data exfiltration or further reconnaissance.
-- Review user activity logs to identify any recent changes in behavior or access patterns that could correlate with the alert.
-- Correlate the alert with other security events or alerts from the same timeframe to identify potential lateral movement or coordinated attacks.
-- Consult threat intelligence sources to determine if the observed activity matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors.
-
-### False positive analysis
-
-- Known false positives for the 'Unusual Discovery Activity by User' rule often arise from legitimate administrative tasks or automated scripts that perform system discovery operations. These activities can mimic reconnaissance techniques but are non-threatening.
-- Frequent system scans by IT management tools or security software can trigger alerts. These should be reviewed and, if deemed safe, excluded from future alerts by adding them to an exception list.
-- Users can manage false positives by identifying and documenting regular maintenance activities that align with the rule's detection criteria. Once identified, these activities can be excluded by creating exceptions based on specific host.id and user.id combinations.
-- It's important to regularly review and update exception lists to ensure that new legitimate activities are accounted for while maintaining the rule's effectiveness in detecting genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary.
-- Conduct a thorough investigation of the alert by reviewing the associated host.id and user.id to determine the scope and impact of the unusual activity.
-- Analyze logs and signals from the identified host to identify any unauthorized access or data exfiltration attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed to be malicious or if it involves sensitive systems or data.
-- Remediate the affected system by removing any discovered malware or unauthorized tools and patching any vulnerabilities that may have been exploited.
-- Restore the system to its operational state by verifying the integrity of system files and configurations, and ensuring all security controls are re-enabled.
-- Implement enhanced logging policies to capture detailed information on user and host activities, focusing on discovery and reconnaissance techniques.
-- Integrate additional security tools and threat intelligence feeds to improve detection capabilities and provide context for future investigations.
-- Review and update access controls and user permissions to minimize the risk of unauthorized discovery activities.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as disabling unnecessary services and enforcing least privilege principles."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_suspicious_proc_enumeration.toml b/rules_building_block/discovery_suspicious_proc_enumeration.toml
index 3006da567c8..5416dfa0a22 100644
--- a/rules_building_block/discovery_suspicious_proc_enumeration.toml
+++ b/rules_building_block/discovery_suspicious_proc_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/09"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -58,49 +58,6 @@ file.path : (/proc/*/cmdline or /proc/*/stat or /proc/*/exe) and not process.nam
   ps or netstat or landscape-sysin or w or pgrep or pidof or needrestart or apparmor_status
 ) and not process.parent.pid : 1
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Suspicious Proc Pseudo File System Enumeration
-
-The proc pseudo file system in Linux provides a window into the kernel and running processes, offering critical insights for system management. Adversaries exploit this by rapidly accessing multiple proc files to gather intelligence on active processes, potentially for reconnaissance or privilege escalation. The detection rule identifies such behavior by monitoring for unusual access patterns to specific proc files, excluding benign processes, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific proc files were accessed and by which process, focusing on the `file.path` and `process.name` fields.
-- Check the `process.parent.pid` to identify the parent process of the suspicious activity, as this can provide context on how the process was initiated.
-- Investigate the timeline of events leading up to the alert by examining logs for any related file access or process creation events.
-- Use Osquery to gather more information about the suspicious process. For example, run the query: `SELECT pid, name, path, cmdline, parent FROM processes WHERE pid = <suspicious_pid>;` to get details about the process and its parent.
-- Analyze the command line arguments (`cmdline`) of the suspicious process to determine its intended actions and whether they align with legitimate activities.
-- Cross-reference the `process.name` and `process.parent.pid` with known benign processes to rule out false positives.
-- Check for any recent changes or anomalies in user accounts or permissions that could be related to the suspicious process.
-- Investigate network activity associated with the suspicious process to identify any external connections or data exfiltration attempts.
-- Review historical data to determine if similar patterns of proc file enumeration have occurred in the past, indicating a persistent threat.
-- Consult threat intelligence sources to see if the process name or behavior matches any known malicious activity or indicators of compromise.
-
-### False positive analysis
-
-- System monitoring tools and legitimate administrative scripts may trigger the rule by accessing multiple proc files in a short period, as part of their normal operation. These tools often perform routine checks on system processes and should be reviewed to determine if they are benign.
-- Automated backup or system management software might also exhibit similar access patterns to the proc file system, especially during scheduled tasks. Identifying these processes and adding them to an exception list can help reduce false positives.
-- Developers and system administrators running diagnostic or performance analysis scripts may inadvertently trigger the rule. These scripts should be evaluated for their necessity and frequency, and exceptions can be made for known safe scripts.
-- Security software performing regular scans or checks on system processes might access proc files rapidly. It's important to verify the legitimacy of such software and consider excluding it from the rule if it is deemed safe.
-- To manage false positives, users can create exceptions by adding known benign process names or parent process IDs to the exclusion list in the detection rule. Regularly updating this list based on observed patterns and operational needs will help maintain the accuracy of threat detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary.
-- Conduct a thorough investigation to identify the process responsible for the suspicious enumeration by analyzing logs and process details.
-- Terminate any malicious or unauthorized processes identified during the investigation to halt further malicious activity.
-- Review and analyze the system's recent activity and changes to identify any additional indicators of compromise or persistence mechanisms.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Implement enhanced logging policies to capture detailed process and file access activities, ensuring future suspicious behaviors are detected promptly.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by applying necessary patches, updates, and verifying the integrity of critical system files.
-- Conduct a post-incident review to identify gaps in security controls and update security policies and procedures accordingly.
-- Implement system hardening measures, such as disabling unnecessary services, enforcing least privilege access, and regularly auditing system configurations to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_network_connections.toml b/rules_building_block/discovery_system_network_connections.toml
index 11b6cc0d189..146fae92b45 100644
--- a/rules_building_block/discovery_system_network_connections.toml
+++ b/rules_building_block/discovery_system_network_connections.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -35,49 +35,6 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name in ("netstat", "lsof", "who", "w")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 System Network Connections Discovery
-
-System network connections discovery involves tools like `netstat` and `lsof` to list active connections, aiding in network diagnostics. Adversaries exploit this to map network topology and identify potential targets. The detection rule monitors process initiation events for these tools, flagging suspicious activity indicative of reconnaissance efforts, aligning with MITRE ATT&CK's discovery tactics.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name involved is either "netstat", "lsof", "who", or "w" and verify the event type is "start" with actions like "exec", "exec_event", "executed", or "process_started".
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with any other unusual activities around the same time.
-- Identify the user account associated with the process initiation to determine if it aligns with expected behavior or if it might be a compromised account.
-- Investigate the parent process of the flagged process to understand how it was initiated and if it was spawned by a legitimate or suspicious application.
-- Examine the command line arguments used with the process to gather more context on what specific network information the adversary might be targeting.
-- Utilize Osquery to further investigate by running a query such as `SELECT * FROM process_open_sockets WHERE pid = (SELECT pid FROM processes WHERE name = 'netstat' OR name = 'lsof');` to identify active network connections associated with the suspicious process.
-- Cross-reference the network connections discovered with known malicious IP addresses or domains to identify potential communication with threat actors.
-- Analyze historical data to determine if there have been previous instances of similar process executions and if they correlate with any known attack patterns.
-- Review system logs and network traffic logs for any anomalies or indicators of compromise that coincide with the time of the alert.
-- Consult threat intelligence sources to check for any recent campaigns or tactics involving the use of these tools for reconnaissance purposes.
-
-### False positive analysis
-
-- Routine administrative tasks often involve the use of `netstat` and `lsof` for legitimate network diagnostics, which can trigger false positives. System administrators frequently use these tools to monitor network performance and troubleshoot issues.
-- Automated scripts and monitoring tools may execute `netstat` or `lsof` as part of regular system health checks, leading to benign process initiation events being flagged.
-- Security software and network management applications might utilize these commands to gather network statistics, which can be mistaken for adversarial reconnaissance.
-- To manage false positives, users can create exceptions for known administrative accounts or specific scripts that regularly execute these commands. This can be done by excluding certain user accounts or process paths from the detection rule.
-- Implementing a baseline of normal network diagnostic activities can help differentiate between legitimate use and potential threats, allowing for more accurate detection and fewer false alarms.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary.
-- Conduct a thorough investigation of the process initiation events to confirm whether the use of tools like netstat or lsof was authorized or indicative of malicious activity.
-- Review system logs and network traffic to identify any unauthorized access or data exfiltration attempts that may have occurred.
-- If unauthorized activity is confirmed, perform a full malware scan and remove any identified threats from the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Implement enhanced logging policies to capture detailed process execution and network connection data for future investigations.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate events and detect similar reconnaissance activities.
-- Restore the system to its operational state by applying the latest security patches and updates, and ensure all security configurations are hardened.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_service_discovery.toml b/rules_building_block/discovery_system_service_discovery.toml
index 9e37bb40288..c70601ed3a0 100644
--- a/rules_building_block/discovery_system_service_discovery.toml
+++ b/rules_building_block/discovery_system_service_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/01/24"
 integration = ["windows", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,48 +52,6 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : "psservice.exe" or process.pe.original_file_name == "psservice.exe")
   ) and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 System Service Discovery through built-in Windows Utilities
-
-System service discovery is a technique used to enumerate services running on a Windows system, often leveraging built-in utilities like `net.exe`, `sc.exe`, and `tasklist.exe`. Adversaries exploit these tools to gather information about the system's services, which can aid in privilege escalation or lateral movement. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and process behaviors, excluding known benign system accounts, to flag potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name and arguments that triggered the detection, focusing on `process.name` and `process.args`.
-- Check the `user.id` associated with the process to determine if it is a known or unknown user, and verify if it deviates from normal behavior.
-- Investigate the parent process of the suspicious activity using `process.parent.name` to understand the context in which the utility was executed.
-- Examine the `host.os.type` and `event.type` fields to confirm the environment and nature of the event, ensuring it aligns with the detection criteria.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE name IN ('net.exe', 'sc.exe', 'tasklist.exe', 'psservice.exe');`
-- Analyze recent login events and user activity on the host to identify any unusual patterns or unauthorized access attempts.
-- Correlate the event with other logs, such as network or authentication logs, to identify any related suspicious activities or lateral movement attempts.
-- Check for any recent changes in system services or configurations that could indicate tampering or unauthorized modifications.
-- Investigate the timeline of events leading up to and following the alert to identify any potential precursor or follow-up activities.
-- Review historical data for similar alerts on the same host or user to determine if this is part of a recurring pattern or isolated incident.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use utilities like `net.exe`, `sc.exe`, and `tasklist.exe` for legitimate purposes such as service management and system monitoring. These activities can trigger false positives. To manage this, create exceptions for known administrative accounts or specific command-line patterns that are part of regular maintenance activities.
-- Automated scripts and management tools: Organizations may deploy scripts or third-party management tools that utilize these utilities for system checks and reporting. Identify and whitelist these scripts or tools by their process names or specific command-line arguments to reduce false positives.
-- Software updates and installations: Some software installations or updates may invoke these utilities to configure or verify services. Monitor installation logs and correlate with detection events to identify benign activities, then exclude these specific processes or arguments from triggering alerts.
-- Security software operations: Certain security solutions might use these utilities as part of their scanning or monitoring processes. Verify with the security software vendor and exclude these operations by process name or user account to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized access or changes to system services.
-- Review the command-line arguments and process behaviors flagged by the detection rule to confirm malicious activity and gather intelligence on the adversary's tactics.
-- Escalate the incident to the security operations center (SOC) or incident response team if the activity is confirmed as malicious, providing them with all relevant logs and findings.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments for future investigations, ensuring that all relevant data is retained for analysis.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats in the future.
-- Restore the system to its operational state by removing any unauthorized services or changes made by the adversary, and apply security patches to address any vulnerabilities exploited during the attack.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update security policies and procedures accordingly.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and using application whitelisting to reduce the attack surface.
-- Educate users and administrators on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security best practices."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_time_discovery.toml b/rules_building_block/discovery_system_time_discovery.toml
index f3d41b88e55..d58b327e2a1 100644
--- a/rules_building_block/discovery_system_time_discovery.toml
+++ b/rules_building_block/discovery_system_time_discovery.toml
@@ -5,7 +5,7 @@ integration = ["windows", "endpoint", "system"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 
 [rule]
 author = ["Elastic"]
@@ -52,47 +52,6 @@ process where host.os.type == "windows" and event.type == "start" and
  (process.name: "tzutil.exe" and process.args: "/g")
 ) and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 System Time Discovery
-System time discovery involves querying a system's time settings, often used by attackers to synchronize their activities or evade detection. Adversaries may exploit commands like `net time`, `w32tm`, or `tzutil` to gather time-related information. The detection rule identifies suspicious use of these commands, excluding legitimate system accounts, to flag potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name and arguments that triggered the alert, focusing on `process.name` and `process.args` fields.
-- Check the `user.id` field to identify the user account associated with the process execution and verify if it is a known or expected user.
-- Investigate the `process.parent.name` to understand the parent process that initiated the suspicious command, which might provide context on how the command was executed.
-- Examine the `host.os.type` to ensure the alert is relevant to a Windows system, as the rule is designed for Windows environments.
-- Correlate the event timestamp with other logs to identify any concurrent suspicious activities or patterns that might indicate a broader attack.
-- Use Osquery to gather additional context on the system's time settings and recent changes. For example, run the query: `SELECT * FROM time;` to retrieve current system time details.
-- Investigate any recent logins or user activity around the time of the alert to determine if there was unauthorized access or unusual behavior.
-- Check for any recent changes to system time settings or configurations that could indicate tampering, using system logs or configuration management tools.
-- Review network logs for any outbound connections around the time of the alert that could suggest data exfiltration or communication with a command and control server.
-- Consult threat intelligence sources to determine if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or campaigns.
-
-### False positive analysis
-
-- Scheduled tasks or scripts that regularly check system time settings for synchronization purposes may trigger false positives. Users can handle these by identifying and excluding specific scripts or task names from the detection rule.
-- IT administrative tools or monitoring software that perform routine checks on system time settings might be flagged. To manage this, users should whitelist these tools by adding their process names or user IDs to the exception list.
-- Legitimate software updates or installations that require time synchronization could also be mistakenly identified. Users can mitigate this by monitoring the context of these activities and excluding known update processes.
-- In environments where time synchronization is critical, such as financial institutions, frequent legitimate use of time-related commands may occur. Users should document these use cases and adjust the detection rule to exclude them, ensuring that only unexpected or unusual activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activities and lateral movement.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any additional indicators of compromise (IOCs) related to system time discovery.
-- Review and analyze logs from the affected system and any associated systems to trace the attacker's activities and identify any other compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the attack is part of a larger campaign.
-- Remediate the affected system by removing any malicious software or unauthorized changes, and restore the system to a known good state using backups if necessary.
-- Implement enhanced logging policies to capture detailed process execution and command-line arguments to improve future detection capabilities.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to enhance monitoring and detection of similar threats.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Apply system hardening measures, such as disabling unnecessary services and enforcing least privilege access, to reduce the attack surface.
-- Educate users and administrators on recognizing and reporting suspicious activities to improve overall security awareness and response readiness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
index c42f45b852a..86698b83778 100644
--- a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
+++ b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/14"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/07/23"
 
 [rule]
 author = ["Elastic"]
@@ -43,48 +43,6 @@ event.dataset:aws.cloudtrail
     and event.action:DescribeInstanceAttribute
     and aws.cloudtrail.request_parameters:(*attribute=userData* and *instanceId*)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Retrieve User Data from AWS EC2 Instance
-
-AWS EC2 instances can store sensitive configuration data in user data scripts, which are executed at launch. Adversaries may exploit the `DescribeInstanceAttribute` API call to access this data, potentially exposing vulnerabilities or sensitive information. The detection rule monitors AWS CloudTrail logs for this API call targeting user data, signaling potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the `DescribeInstanceAttribute` API call with `attribute=userData` and `instanceId` was executed, ensuring the event dataset is `aws.cloudtrail`.
-- Identify the source IP address and user agent associated with the API call to determine if it aligns with known or expected activity.
-- Check the AWS IAM user or role that initiated the API call to verify if it has legitimate access to the EC2 instance.
-- Investigate the time and frequency of the API call to assess if it coincides with any scheduled tasks or known maintenance activities.
-- Cross-reference the `instanceId` with your asset inventory to determine the sensitivity and criticality of the EC2 instance involved.
-- Examine the AWS CloudTrail logs for any other suspicious activities or API calls made by the same IAM user or role around the same timeframe.
-- Utilize Osquery to gather additional context from the EC2 instance by running a query such as: `SELECT * FROM ec2_instance_metadata WHERE key = 'user-data';` to verify if any unauthorized changes or access attempts have been made.
-- Analyze any recent changes to the IAM policies or roles associated with the EC2 instance to identify potential misconfigurations or privilege escalations.
-- Review the security group and network ACL configurations for the EC2 instance to ensure they are not overly permissive and align with security best practices.
-- Consult with the instance owner or relevant stakeholders to validate if the API call was part of an authorized operation or if further investigation is warranted.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators or automated scripts may regularly use the `DescribeInstanceAttribute` API call to check or update configurations, leading to benign occurrences of this event. Users can handle these by creating exceptions for known administrative accounts or scripts that frequently perform this action.
-- Monitoring and auditing tools: Security and compliance tools might invoke the `DescribeInstanceAttribute` API call as part of their regular monitoring activities. To manage these, users can whitelist specific tools or services that are known to perform legitimate monitoring.
-- Cloud management platforms: Third-party cloud management solutions may use this API call to gather information about EC2 instances for inventory or management purposes. Users should identify and exclude these platforms from triggering alerts by adding them to an exception list.
-- Development and testing environments: In environments where developers frequently launch and configure EC2 instances, the `DescribeInstanceAttribute` call may be part of normal operations. Users can reduce false positives by excluding specific development accounts or environments from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected EC2 instance to prevent further unauthorized access and data exfiltration.
-- Review AWS CloudTrail logs to identify the source of the DescribeInstanceAttribute API call and determine if it was authorized or part of a larger attack.
-- Revoke any suspicious or unauthorized access keys and credentials associated with the compromised instance.
-- Conduct a thorough investigation to assess the extent of the data exposure and identify any other potentially affected resources.
-- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are required.
-- Implement enhanced logging and monitoring policies to capture detailed API activity, focusing on sensitive operations like DescribeInstanceAttribute.
-- Integrate AWS GuardDuty or similar threat detection services to provide real-time alerts on suspicious activities within your AWS environment.
-- Restore the EC2 instance from a known good backup if necessary, ensuring that all security patches and updates are applied.
-- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have access to sensitive operations.
-- Conduct a post-incident review to identify gaps in the current security posture and implement hardening measures, such as network segmentation and multi-factor authentication, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_win_network_connections.toml b/rules_building_block/discovery_win_network_connections.toml
index d50f53e8710..dc1f9d25751 100644
--- a/rules_building_block/discovery_win_network_connections.toml
+++ b/rules_building_block/discovery_win_network_connections.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -48,49 +48,6 @@ process where event.type == "start" and
   (process.name : "nbtstat.exe" and process.args : "-s*")
 ) and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows System Network Connections Discovery
-
-Windows systems provide utilities like `netstat`, `net`, and `nbtstat` to manage and monitor network connections. Adversaries exploit these tools to map network connections, identifying potential targets. The detection rule flags unusual use of these commands, especially when executed by non-system users, to uncover unauthorized network enumeration attempts, thereby helping analysts identify potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific command executed, including the process name and arguments, to understand the context of the network enumeration attempt.
-- Check the user ID associated with the process execution to determine if it was initiated by a non-system user, as indicated by the exclusion of user ID "S-1-5-18".
-- Investigate the parent process of the suspicious command to identify if it was spawned by a legitimate process or potentially malicious activity.
-- Examine the process start time to correlate with other events or activities on the system that might indicate a broader attack pattern.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name IN ('netstat.exe', 'net.exe', 'net1.exe', 'nbtstat.exe');` to retrieve details about the process execution.
-- Analyze network logs to identify any unusual outbound or inbound connections that coincide with the execution of the flagged command.
-- Check for any recent changes in user permissions or group memberships that might have allowed unauthorized users to execute network discovery commands.
-- Review system logs for any other suspicious activities or anomalies around the time of the alert to identify potential lateral movement or privilege escalation attempts.
-- Investigate the system for any signs of compromise, such as unexpected files, scheduled tasks, or registry changes, that could indicate a broader intrusion.
-- Correlate the findings with threat intelligence sources to determine if the activity matches known tactics, techniques, and procedures (TTPs) of adversaries targeting similar environments.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators often use `netstat`, `net`, and `nbtstat` for legitimate network management and troubleshooting, which can trigger the rule. To manage this, create exceptions for specific user accounts or processes known to perform these tasks regularly.
-- Automated scripts: Scheduled scripts or automated tools that perform network diagnostics or inventory checks may execute these commands. Identify and exclude these scripts by their process names or paths to reduce false positives.
-- Monitoring software: Network monitoring or security software might use these commands to gather network data. Verify the legitimacy of such software and exclude its processes from the rule.
-- System updates or patches: Some system updates or patches might temporarily use these commands as part of their installation process. Monitor update schedules and exclude related processes during these times.
-- Training or testing environments: In environments where users are trained on network management or security testing, these commands might be used frequently. Consider excluding specific user IDs or machine names associated with these environments.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation of the system to identify any additional signs of compromise, focusing on unusual processes, network connections, and user activities.
-- Review the execution context of the flagged commands, including the user account and associated processes, to determine if the activity was authorized or malicious.
-- Escalate the incident to the security operations center (SOC) or incident response team if unauthorized network enumeration is confirmed, providing them with detailed logs and findings.
-- Implement enhanced logging policies to capture detailed process execution and network activity, ensuring that future incidents can be detected and analyzed more effectively.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for similar threats.
-- Restore the system to its operational state by removing any malicious software, resetting compromised credentials, and applying necessary security patches.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
-- Implement network segmentation and access controls to limit the ability of adversaries to move laterally within the environment.
-- Educate users on recognizing and reporting suspicious activities, emphasizing the importance of adhering to security policies and procedures."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_windows_system_information_discovery.toml b/rules_building_block/discovery_windows_system_information_discovery.toml
index 3aa17611d62..af6dab02a4d 100644
--- a/rules_building_block/discovery_windows_system_information_discovery.toml
+++ b/rules_building_block/discovery_windows_system_information_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/06"
 integration = ["windows", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,49 +54,6 @@ process.parent.executable : (
     "?:\\ProgramData\\*"
 ) and not user.id : "S-1-5-18"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Windows System Information Discovery
-
-Windows System Information Discovery involves using built-in commands to gather system details, aiding attackers in understanding the environment post-compromise. Adversaries exploit tools like `cmd.exe`, `systeminfo.exe`, and `wmic.exe` to extract OS and hardware data. The detection rule identifies suspicious use of these commands, excluding legitimate processes and system accounts, to flag potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific command triggered the detection, focusing on the `process.name` and `process.args` fields.
-- Check the `process.parent.executable` field to identify the parent process that initiated the suspicious command, which can provide context on whether the execution was part of a legitimate process chain.
-- Investigate the `user.id` associated with the process to determine if the activity was performed by a legitimate user or a potentially compromised account.
-- Examine the `host.os.type` and `event.type` fields to confirm the environment and nature of the event, ensuring it aligns with the detection rule's focus on Windows systems and process start events.
-- Correlate the timestamp of the alert with other security events or logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
-- Use Osquery to gather additional context about the system and processes. For example, run the following Osquery query to list recent processes executed on the system: `SELECT pid, name, path, cmdline, parent FROM processes WHERE name IN ('cmd.exe', 'systeminfo.exe', 'wmic.exe');`
-- Investigate the network activity around the time of the alert to identify any unusual outbound connections that might suggest data exfiltration or command-and-control communication.
-- Review historical data for similar alerts on the same host or user account to determine if this is an isolated incident or part of a recurring pattern.
-- Check for any recent changes in user permissions or system configurations that could have facilitated the execution of the suspicious command.
-- Consult threat intelligence sources to see if the observed behavior matches known tactics, techniques, and procedures (TTPs) associated with specific threat actors or malware campaigns.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger the rule if they use `cmd.exe`, `systeminfo.exe`, or `wmic.exe` to check system compatibility or gather system information. Users can handle these by adding specific update or installation executables to the exclusion list.
-- System management tools or scripts that regularly run to gather system information for inventory or monitoring purposes might be flagged. To manage these, users should identify and exclude the specific scripts or management tools from the detection rule.
-- Automated tasks or scheduled jobs that use these commands for legitimate system maintenance or reporting can also cause false positives. Users can exclude these tasks by specifying the parent executable paths or user accounts associated with these jobs.
-- Developers or IT personnel running diagnostic commands during troubleshooting or system checks may inadvertently trigger the rule. Organizations can create exceptions for known user accounts or specific development environments to reduce false positives.
-- Security software or endpoint protection solutions that perform regular system scans and use these commands might be mistakenly flagged. Users should verify and exclude these security tools from the detection criteria to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement by the attacker.
-- Conduct a thorough investigation to confirm the legitimacy of the detected activity by reviewing process execution details and correlating with known user behavior.
-- If malicious activity is confirmed, terminate any suspicious processes and remove any unauthorized tools or scripts found on the system.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Review and enhance logging policies to ensure comprehensive monitoring of command-line activities and process executions, focusing on the use of system information discovery tools.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for future investigations.
-- Restore the system to its operational state by applying clean backups and ensuring all security patches and updates are installed.
-- Implement hardening measures such as disabling unnecessary services, enforcing least privilege access, and applying application whitelisting to prevent unauthorized execution of system discovery tools.
-- Conduct a post-incident review to identify gaps in the security posture and update incident response plans accordingly.
-- Educate users on recognizing and reporting suspicious activities to enhance the organization's overall security awareness."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_aws_lambda_function_updated.toml b/rules_building_block/execution_aws_lambda_function_updated.toml
index 15fa498aa34..773ea2fdede 100644
--- a/rules_building_block/execution_aws_lambda_function_updated.toml
+++ b/rules_building_block/execution_aws_lambda_function_updated.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/01"
 
 [rule]
 author = ["Elastic"]
@@ -54,50 +54,6 @@ event.dataset: "aws.cloudtrail"
     and event.outcome: "success"
     and event.action: (CreateFunction* or UpdateFunctionCode*)
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS Lambda Function Created or Updated
-
-AWS Lambda allows execution of code without server management, streamlining deployment. However, adversaries may exploit this by creating or updating functions to run harmful code, steal data, or gain unauthorized access. The detection rule monitors successful creation or updates of Lambda functions, flagging potential misuse by identifying specific actions within AWS CloudTrail logs.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to identify the specific Lambda function that was created or updated by examining the `event.action` field for "CreateFunction" or "UpdateFunctionCode".
-- Check the `event.userIdentity` field to determine the identity of the user or service that performed the action, and verify if this aligns with expected behavior or known accounts.
-- Analyze the `event.time` field to understand when the function was created or updated, and correlate this with other activities in the environment to identify any suspicious patterns.
-- Investigate the `event.sourceIPAddress` field to determine the origin of the request, and assess if the IP address is known or associated with any previous suspicious activities.
-- Examine the `event.requestParameters` field to gather details about the function, such as its name, runtime, and any environment variables that might have been set.
-- Utilize Osquery to further investigate by running a query to list all AWS Lambda functions and their configurations, for example: `SELECT * FROM aws_lambda_functions WHERE function_name = 'suspicious_function_name';`
-- Cross-reference the Lambda function's ARN (Amazon Resource Name) with IAM policies and roles to ensure that permissions are appropriate and have not been overly permissive.
-- Review the function's code or any associated S3 buckets for signs of malicious code or scripts that could indicate tampering or unauthorized changes.
-- Check for any recent changes in the AWS environment that might coincide with the Lambda function creation or update, such as new IAM roles or changes to security groups.
-- Investigate any related alerts or logs from other security tools that might provide additional context or corroborate suspicious activity related to the Lambda function.
-
-### False positive analysis
-
-- Routine updates or deployments by authorized personnel can trigger the rule, as legitimate development and maintenance activities often involve creating or updating Lambda functions.
-- Automated deployment tools or CI/CD pipelines that frequently update Lambda functions as part of regular operations may also cause false positives.
-- Scheduled updates or function optimizations performed by DevOps teams can be mistaken for suspicious activity.
-- To manage these false positives, users can create exceptions for known, trusted accounts or roles that regularly perform these actions.
-- Implementing a whitelist of specific Lambda function names or tags associated with routine updates can help reduce noise.
-- Monitoring the context of the changes, such as the source IP address or the IAM user making the changes, can assist in distinguishing between legitimate and suspicious activities.
-
-### Response and remediation
-
-- Immediately isolate the affected AWS Lambda function by disabling it to prevent further execution of potentially malicious code.
-- Review AWS CloudTrail logs to identify unauthorized access patterns or suspicious activities related to the Lambda function creation or update.
-- Conduct a thorough code review of the affected Lambda function to identify and remove any malicious code or unauthorized changes.
-- Revert the Lambda function to a known good state using version control or backups, ensuring that only authorized code is deployed.
-- Implement AWS Identity and Access Management (IAM) policies to restrict permissions for creating or updating Lambda functions to only trusted users and roles.
-- Enable detailed logging and monitoring for AWS Lambda and related services to detect future unauthorized changes or executions.
-- Integrate AWS CloudTrail with a Security Information and Event Management (SIEM) system to enhance real-time threat detection and response capabilities.
-- Escalate the incident to the security team if evidence of broader compromise or data exfiltration is found, following the organization's incident response plan.
-- Conduct a post-incident review to identify gaps in security controls and update policies and procedures to prevent similar incidents in the future.
-- Apply hardening measures such as enabling AWS Lambda function environment variable encryption and using AWS Key Management Service (KMS) for sensitive data protection."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_event_action_for_pat.toml b/rules_building_block/execution_github_new_event_action_for_pat.toml
index 7870f906daf..e8ab2101ae1 100644
--- a/rules_building_block/execution_github_new_event_action_for_pat.toml
+++ b/rules_building_block/execution_github_new_event_action_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,49 +35,6 @@ event.dataset:"github.audit" and event.category:"configuration" and
 event.action:* and github.hashed_token:* and 
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence GitHub Event for a Personal Access Token (PAT)
-
-Personal Access Tokens (PATs) in GitHub provide a way to authenticate programmatic access to repositories, enabling automation and integration. Adversaries may exploit PATs to gain unauthorized access, execute code, or exfiltrate data. The detection rule identifies new PAT events not seen in the past 14 days, flagging potential misuse by monitoring specific GitHub audit logs and access patterns.
-
-### Possible investigation steps
-
-- Review the GitHub audit logs to identify the specific event details, focusing on the `event.dataset:"github.audit"` and `event.category:"configuration"` fields to understand the context of the PAT usage.
-- Examine the `event.action` field to determine the specific action that triggered the alert, which can provide insights into the nature of the access or configuration change.
-- Investigate the `github.hashed_token` field to identify the specific PAT involved and check if it matches any known tokens or patterns associated with legitimate users or applications.
-- Analyze the `github.programmatic_access_type` field to determine whether the access was through an "OAuth access token" or a "Fine-grained personal access token," which can help assess the level of access granted.
-- Cross-reference the PAT event with recent user activity logs to identify any unusual patterns or anomalies in user behavior that might indicate misuse or compromise.
-- Use Osquery to gather additional context on the system or environment where the PAT was used. For example, run the following Osquery query to list recent network connections that might correlate with the PAT usage: `SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL;`
-- Check for any recent changes in repository permissions or settings that might have coincided with the PAT event, which could indicate an attempt to escalate privileges or exfiltrate data.
-- Investigate any associated IP addresses or geolocations from which the PAT was used to determine if they align with expected user locations or if they suggest unauthorized access.
-- Review any recent changes to the repositories accessed using the PAT to identify potential unauthorized modifications or data exfiltration attempts.
-- Collaborate with the user or team associated with the PAT to verify the legitimacy of the token and understand the intended use case, which can help determine if the alert is a false positive or a genuine security concern.
-
-### False positive analysis
-
-- Frequent legitimate automation scripts or integrations may trigger false positives if they generate new PATs regularly. Users can manage these by creating exceptions for known scripts or applications that are verified as non-threatening.
-- Developers or teams who rotate their PATs as part of a security best practice might also cause false positives. To handle this, users can maintain a list of accounts or tokens that are expected to rotate frequently and exclude them from alerts.
-- Testing environments or sandbox accounts that frequently generate and revoke PATs for testing purposes can be another source of false positives. Users should consider excluding these environments from the detection rule or setting up specific monitoring that accounts for their unique behavior.
-- In organizations with high developer turnover, new developers may frequently create PATs, leading to false positives. Implementing a process to quickly verify new developer accounts and their associated PATs can help mitigate this issue.
-- Users can also adjust the detection rule to include additional context, such as IP address or user agent, to better differentiate between legitimate and suspicious activity, reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Immediately revoke the identified Personal Access Token (PAT) to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying any repositories accessed using the compromised PAT.
-- Review GitHub audit logs for any suspicious activities or anomalies associated with the compromised PAT.
-- Notify the affected repository owners and stakeholders about the potential breach and actions taken.
-- Escalate the incident to the security team for further analysis and to determine if additional systems or data were affected.
-- Implement enhanced logging and monitoring for GitHub activities to detect similar incidents in the future.
-- Educate users on secure PAT management practices, including regular rotation and using fine-grained permissions.
-- Integrate security tools with GitHub to automate the detection of anomalous PAT usage and other security events.
-- Restore any affected systems or repositories to their last known good state, ensuring no malicious code or data remains.
-- Apply hardening measures such as enforcing multi-factor authentication (MFA) for all GitHub accounts and restricting PAT usage to specific IP addresses or environments."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
index 23ee919a82f..af1fe749b4a 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -36,48 +36,6 @@ 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
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT)
-
-GitHub Personal Access Tokens (PATs) enable programmatic access to repositories, facilitating automation and integration. However, adversaries can exploit compromised PATs to access private repositories, potentially exfiltrating sensitive data. This detection rule identifies unusual private repo interactions by monitoring for PAT activity not observed in the past 14 days, signaling potential unauthorized access attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific GitHub Personal Access Token (PAT) involved, using the `github.hashed_token` field for reference.
-- Check the `event.dataset` and `event.category` fields to confirm the event is related to GitHub audit logs and configuration changes, ensuring the alert is valid.
-- Investigate the `github.repo` field to determine which private repository was accessed and assess the sensitivity of the data within.
-- Verify the `github.programmatic_access_type` to understand the type of access token used, distinguishing between "OAuth access token" and "Fine-grained personal access token."
-- Examine the user or service account associated with the PAT to determine if the access was expected or authorized.
-- Cross-reference the PAT activity with recent user activity logs to identify any anomalies or patterns that could indicate unauthorized access.
-- Utilize Osquery to gather additional context on the system where the PAT might have been used. Example query: `SELECT * FROM processes WHERE name LIKE '%git%' AND cmdline LIKE '%<hashed_token_value>%';` to find processes using the token.
-- Check for any recent changes in the repository's access permissions or settings that could have facilitated unauthorized access.
-- Investigate any other recent alerts or incidents involving the same PAT or repository to identify potential patterns or related threats.
-- Collaborate with the repository owner or relevant stakeholders to verify if the access was legitimate and gather additional context on the PAT's intended use.
-
-### False positive analysis
-
-- Regularly scheduled automated tasks or scripts using GitHub PATs may trigger this rule if they interact with private repositories infrequently, such as once a month. Users can manage this by creating exceptions for known, trusted scripts or automation tools that are expected to access private repositories periodically.
-- Developers or team members who rotate their PATs for security reasons might cause false positives when accessing private repositories with a new token. To handle this, maintain a list of authorized personnel and their expected access patterns, and update the monitoring system to recognize these changes as non-threatening.
-- Integration tools or third-party services that use PATs for legitimate access to private repositories might be flagged if they have not interacted with the repository in the past 14 days. Users should document and whitelist these services to prevent unnecessary alerts.
-- Temporary access granted to contractors or external collaborators using PATs could be misidentified as unauthorized access. Ensure that any temporary access is logged and that exceptions are in place for the duration of their engagement to avoid false positives.
-
-### Response and remediation
-
-- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access.
-- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized changes or data exfiltration.
-- Notify the affected repository owners and stakeholders about the potential breach and advise them to review their repositories for any suspicious activity.
-- Escalate the incident to the security team for a comprehensive investigation and to determine the scope of the breach.
-- Implement enhanced logging and monitoring for all PAT activities to detect unusual patterns and potential threats in the future.
-- Integrate security tools with GitHub to automate the detection of anomalous activities and improve response times.
-- Review and update access controls and permissions for all repositories to ensure the principle of least privilege is enforced.
-- Conduct a security awareness session for developers and repository managers on the importance of securing PATs and recognizing phishing attempts.
-- Restore any affected systems or repositories to their last known good state, ensuring that all unauthorized changes are reverted.
-- Implement additional security measures such as multi-factor authentication (MFA) for accessing sensitive repositories and resources."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_user.toml b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
index 6fe2af7c8b1..5aabab32d3c 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_user.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,48 +35,6 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.repo:* and user.name:* and 
 github.repository_public:false
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of GitHub User Interaction with Private Repo
-
-GitHub is a platform for version control and collaboration, often hosting private repositories for sensitive projects. Adversaries may exploit unauthorized access to these private repos to exfiltrate data or inject malicious code. The detection rule identifies unusual user interactions with private repos by flagging users who haven't accessed them in the past 14 days, helping to spot potential breaches early.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user (`user.name`) and repository (`github.repo`) involved in the interaction.
-- Verify the user's access history to confirm that this is indeed the first interaction with the private repository in the last 14 days.
-- Check the user's recent activity logs on GitHub to identify any other unusual behavior or access patterns.
-- Investigate the repository's access logs to determine if there have been any other unusual access attempts or changes.
-- Cross-reference the user's access with known project timelines or team assignments to assess if the access is legitimate.
-- Use Osquery to gather additional context on the user's machine. For example, run the following query to check for recent GitHub-related processes: `SELECT * FROM processes WHERE name LIKE '%git%' OR path LIKE '%github%';`
-- Examine any recent changes or commits made to the repository to identify if any unauthorized modifications have occurred.
-- Check for any recent changes in the repository's access permissions or settings that might explain the new interaction.
-- Review the organization's GitHub audit logs for any other anomalies or patterns that coincide with the user's access.
-- Consult with the repository owner or project manager to verify if the user was expected to access the repository and if any recent changes in team roles might explain the access.
-
-### False positive analysis
-
-- Users who are part of a rotating team or have roles that require infrequent but legitimate access to private repositories may trigger false positives. These users can be added to an exception list to prevent unnecessary alerts.
-- Automated systems or scripts that interact with private repositories on a schedule longer than 14 days might be flagged. Identifying these systems and excluding them from the rule can reduce false positives.
-- Temporary contractors or consultants who have legitimate access for specific projects may appear as new interactions. Their access patterns should be reviewed and, if deemed non-threatening, can be excluded from the detection rule.
-- Users returning from extended leave or vacation might trigger alerts upon their first interaction with a private repo. These cases can be managed by temporarily adjusting the rule parameters or adding exceptions for known absences.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by revoking access to the private repository to prevent further unauthorized actions.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying any data exfiltrated or malicious code injected.
-- Review the user's recent activity logs to identify any other suspicious actions or access to additional repositories.
-- Escalate the incident to the security operations team for a deeper analysis and to determine if the breach is part of a larger attack.
-- Notify the repository owner and relevant stakeholders about the incident and the steps being taken to address it.
-- Implement enhanced logging policies to capture detailed user activity on private repositories for future monitoring and investigations.
-- Integrate security tools with GitHub, such as anomaly detection systems, to automatically flag unusual user behavior.
-- Restore the system to its operational state by ensuring all unauthorized changes are reverted and verifying the integrity of the repository.
-- Conduct a post-incident review to identify gaps in security controls and update policies to prevent similar incidents.
-- Apply hardening measures such as enforcing multi-factor authentication, regular access reviews, and least privilege principles for repository access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_repo_created.toml b/rules_building_block/execution_github_repo_created.toml
index f9a79861435..40ab0a8d88b 100644
--- a/rules_building_block/execution_github_repo_created.toml
+++ b/rules_building_block/execution_github_repo_created.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,49 +33,6 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "repo.create"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Repo Created
-GitHub repositories are essential for code collaboration and version control, enabling developers to manage and share projects. However, adversaries may exploit this by creating repositories to host malicious code or scripts for serverless execution, aligning with MITRE ATT&CK tactics. The detection rule monitors GitHub audit logs for repository creation events, helping identify unauthorized or suspicious activities that could indicate potential threats.
-
-### Possible investigation steps
-
-- Review the GitHub audit log entry to confirm the event details, focusing on the `event.dataset` and `event.action` fields to ensure it matches "github.audit" and "repo.create".
-- Identify the user associated with the repository creation by examining the `actor` field in the audit log to determine if the action was performed by an authorized individual.
-- Check the `repository.name` and `repository.url` fields to gather information about the newly created repository, including its name and location.
-- Investigate the `repository.visibility` field to determine if the repository is public or private, as public repositories may pose a higher risk if they contain sensitive information.
-- Cross-reference the `actor` field with known user accounts and roles within the organization to assess if the user has the appropriate permissions to create repositories.
-- Use Osquery to gather additional context about the user's recent activities. For example, run the following query to list recent GitHub actions by the user: `SELECT * FROM github_events WHERE actor_login = '<actor_login>' ORDER BY created_at DESC LIMIT 10;`.
-- Examine the commit history of the new repository, if available, to identify any suspicious or unauthorized code changes that may indicate malicious intent.
-- Review any associated pull requests or issues linked to the repository to detect any unusual or unexpected activity that could suggest a security concern.
-- Analyze the repository's description and README files for any indications of malicious intent or unauthorized project objectives.
-- Collaborate with the repository owner or the user who created the repository to verify the legitimacy of the creation and gather additional context if necessary.
-
-### False positive analysis
-
-- Frequent repository creation by trusted developers or automated systems can trigger false positives. These activities are often part of regular development workflows and not indicative of malicious intent.
-- Internal projects or sandbox environments where repositories are created and deleted frequently for testing purposes may also lead to false positives.
-- To manage these, users can create exceptions for specific users or teams known to regularly create repositories as part of their job functions.
-- Implementing a whitelist of known safe IP addresses or user accounts can help reduce noise from expected repository creation events.
-- Regularly review and update the list of exceptions to ensure it reflects current organizational practices and personnel changes.
-- Consider integrating additional context, such as repository names or descriptions, to better assess the intent behind repository creation events.
-
-### Response and remediation
-
-- Immediately review the newly created GitHub repository to determine if it contains any malicious or unauthorized content.
-- Revoke access to the repository for any suspicious users or accounts to prevent further unauthorized actions.
-- Conduct a thorough investigation of the audit logs to identify any other suspicious activities or related events.
-- Notify the security team and relevant stakeholders about the potential threat and findings for further analysis and decision-making.
-- If malicious content is confirmed, remove the repository and any associated files from the GitHub platform.
-- Implement stricter access controls and permissions for repository creation to limit the ability of unauthorized users to create repositories.
-- Enhance logging policies to ensure comprehensive monitoring of all repository-related activities, including creation, modification, and deletion events.
-- Integrate GitHub with a Security Information and Event Management (SIEM) system to enable real-time alerting and correlation with other security events.
-- Conduct a post-incident review to identify gaps in the current security posture and update policies and procedures accordingly.
-- Educate developers and users on secure coding practices and the importance of reporting suspicious activities to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
index 426f7f15e5e..46e625fe8c3 100644
--- a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
+++ b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,51 +35,6 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and github.repo:* and 
 github.repository_public:false
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of GitHub Repo Interaction From a New IP
-
-GitHub repositories are crucial for code collaboration and storage, often containing sensitive information. Adversaries may exploit unauthorized access to private repositories by interacting from unfamiliar IPs, potentially leading to data breaches or code tampering. This detection rule identifies such anomalies by flagging interactions from IPs not seen in recent activity, helping to mitigate unauthorized access risks.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific IP address involved in the interaction and the exact timestamp of the event.
-- Cross-reference the IP address with known IP addresses in your organization's network to determine if it is an internal or external IP.
-- Check the GitHub audit logs for any other activities associated with the same IP address to identify patterns or additional unauthorized access attempts.
-- Investigate the GitHub actor associated with the event to verify if the user account has a history of accessing the repository from different IPs or if this is an anomaly.
-- Examine the specific repository accessed to assess the sensitivity of the data and determine the potential impact of unauthorized access.
-- Utilize Osquery to gather additional context on the system that may have been used for the interaction. For example, run the following Osquery query to check for recent network connections from the suspicious IP:
-  ```sql
-  SELECT * FROM process_open_sockets WHERE remote_address = '<suspicious_ip>';
-  ```
-- Analyze any recent changes or commits made to the repository around the time of the alert to identify any unauthorized modifications.
-- Check for any recent changes in user permissions or access levels within the GitHub organization that could explain the new IP access.
-- Investigate any other security alerts or incidents that occurred around the same time to determine if this event is part of a larger attack pattern.
-- Consult threat intelligence sources to see if the IP address has been associated with known malicious activity or threat actors.
-
-### False positive analysis
-
-- Employees working remotely or traveling may trigger false positives when accessing GitHub repositories from new IP addresses. To manage this, maintain a list of known employee IPs or use a VPN to standardize IP addresses.
-- Automated systems or CI/CD pipelines that interact with GitHub repositories from dynamic IP addresses can also cause false positives. Consider whitelisting IP ranges associated with these systems or using static IPs for such interactions.
-- Third-party services or contractors with legitimate access to repositories might access from unfamiliar IPs. Establish a process to verify and document these IPs, and create exceptions for trusted partners.
-- Changes in corporate network infrastructure, such as new VPN endpoints or proxy servers, can result in new IP addresses being flagged. Regularly update the list of internal IPs to reflect these changes and prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected repository by restricting access to known, trusted IP addresses to prevent further unauthorized interactions.
-- Conduct a thorough investigation to identify the source and intent of the interaction, focusing on the new IP address and any associated user accounts.
-- Review recent changes in the repository for any unauthorized modifications or suspicious activity, and revert any unauthorized changes if necessary.
-- Notify the security team and relevant stakeholders about the incident, providing details of the IP address and any potential impact on the repository.
-- Implement enhanced logging and monitoring for GitHub interactions, ensuring that all access attempts, especially from new IPs, are logged and reviewed regularly.
-- Integrate threat intelligence feeds to correlate the new IP address with known malicious actors or activities, leveraging MITRE ATT&CK framework for context.
-- Update access controls and authentication mechanisms, such as enabling multi-factor authentication (MFA) for all users accessing private repositories.
-- Conduct a security awareness session for developers and repository maintainers to reinforce best practices for securing code repositories.
-- Restore the repository to its last known good state if any unauthorized changes were detected, ensuring that all code and data integrity is maintained.
-- Review and update incident response and recovery plans to incorporate lessons learned from the incident, enhancing future readiness and resilience."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_linux_segfault.toml b/rules_building_block/execution_linux_segfault.toml
index cef4de382b0..e1d006ca679 100644
--- a/rules_building_block/execution_linux_segfault.toml
+++ b/rules_building_block/execution_linux_segfault.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/26"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -53,48 +53,6 @@ type = "query"
 query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:segfault
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Segfault Detected
-Segmentation faults occur when a program accesses restricted memory, often causing it to crash. While typically a sign of programming errors, adversaries can exploit these faults to execute unauthorized code, leveraging vulnerabilities like buffer overflows. The 'Segfault Detected' rule monitors Linux kernel logs for segfault messages, identifying potential exploitation attempts by correlating specific log patterns.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a segmentation fault by examining the `message` field for specific segfault patterns.
-- Verify the `host.os.type` field to ensure the alert pertains to a Linux system, as the rule is designed for Linux kernel logs.
-- Check the `event.dataset` field to confirm that the log source is `system.syslog`, ensuring the data is from the expected log source.
-- Identify the process that caused the segfault by examining the `process.name` field and gather additional context about this process.
-- Use Osquery to list recent processes that have experienced segmentation faults with a query like: `SELECT pid, name, path, cmdline FROM processes WHERE name = 'kernel' AND cmdline LIKE '%segfault%';`
-- Investigate the history of the process by reviewing logs or using Osquery to determine if this process has a history of segfaults or other anomalies.
-- Correlate the timing of the segfault with other system events to identify any preceding suspicious activities or changes in the system.
-- Examine the system for any recent updates or changes that might have introduced vulnerabilities, focusing on software related to the segfaulting process.
-- Analyze the system for signs of exploitation attempts, such as buffer overflow patterns, by reviewing logs and using tools like Osquery to check for unusual memory usage.
-- Gather additional context by checking for any related alerts or anomalies on the same host or network segment that might indicate a broader attack pattern.
-
-### False positive analysis
-
-- Routine software crashes: Some applications may crash frequently due to bugs or compatibility issues, leading to repeated segfault messages in the logs. These are not necessarily indicative of malicious activity but rather poor software stability.
-- Debugging activities: Developers often intentionally cause segfaults during debugging to test error handling or to identify vulnerabilities. These activities can generate false positives in the monitoring system.
-- Kernel module testing: Testing or development of kernel modules can result in segfaults as part of normal operations, especially when modules are being loaded or unloaded frequently.
-- Legacy software: Older software that is not fully compatible with current systems may cause segfaults due to outdated code practices, which are not necessarily security threats.
-- To manage these false positives, users can create exceptions or filters for known non-threatening processes or applications that frequently cause segfaults. This can be done by updating the monitoring rule to exclude specific process names or paths associated with benign activities. Additionally, maintaining an updated list of trusted applications and regularly reviewing and adjusting the exceptions can help minimize unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
-- Conduct a thorough investigation of the kernel logs and any associated application logs to identify the source and nature of the segfault.
-- Analyze recent changes or updates to the system that might have introduced vulnerabilities, focusing on software known for buffer overflow issues.
-- Utilize memory analysis tools to detect any unauthorized code execution or memory manipulation attempts.
-- If malicious activity is confirmed, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Restore the system from a known good backup to ensure that any malicious code or corrupted data is removed.
-- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities.
-- Implement enhanced logging policies to capture detailed information on process execution and memory access patterns for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats.
-- Conduct a post-incident review to identify gaps in security controls and update the incident response plan to address these weaknesses."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_settingcontent_ms_file_creation.toml b/rules_building_block/execution_settingcontent_ms_file_creation.toml
index 0b94cd745e1..e359ebfef9c 100644
--- a/rules_building_block/execution_settingcontent_ms_file_creation.toml
+++ b/rules_building_block/execution_settingcontent_ms_file_creation.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,48 +44,6 @@ file where host.os.type == "windows" and event.type == "creation" and
     "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\amd64_microsoft-windows-s..*\\*.settingcontent-ms"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation of SettingContent-ms Files
-
-SettingContent-ms files are XML-based shortcuts used in Windows to link to specific settings pages. While legitimate in function, adversaries exploit them to execute malicious code by embedding harmful scripts. The detection rule identifies unusual creation of these files outside typical directories, flagging potential misuse by checking file creation events and paths, thus helping analysts spot and mitigate threats effectively.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file creation event, focusing on the `file.path` and `file.extension` fields to ensure it matches the suspicious criteria outlined in the detection rule.
-- Check the `host.os.type` to verify that the event occurred on a Windows system, as this rule is specific to Windows environments.
-- Investigate the `file.path` to determine if the SettingContent-ms file was created in an unusual or unauthorized directory, which could indicate malicious activity.
-- Use Osquery to list all SettingContent-ms files on the system with the following query: `SELECT path FROM file WHERE path LIKE '%.settingcontent-ms';` to identify any other potentially suspicious files.
-- Examine the file creation timestamp to correlate with other system events or user activities that occurred around the same time, which might provide additional context.
-- Analyze the user account associated with the file creation event to determine if it aligns with expected behavior or if it might be compromised.
-- Investigate any associated processes or command-line activities that occurred around the time of the file creation to identify potential malicious scripts or commands.
-- Check for any recent changes in system settings or installed applications that might explain the creation of the SettingContent-ms file.
-- Review system logs for any other unusual activities or alerts that coincide with the file creation event, which could indicate a broader attack.
-- Consult threat intelligence sources to determine if there are any known campaigns or malware that utilize SettingContent-ms files for execution, which could provide additional context for the investigation.
-
-### False positive analysis
-
-- Legitimate software installations or updates may create SettingContent-ms files in non-standard directories, triggering false positives. Users should verify the source of the file creation and consider excluding these paths if they are consistently associated with trusted software.
-- System administrators or IT management tools might generate these files during configuration changes or system maintenance tasks. Users can create exceptions for these activities by identifying the responsible processes and excluding them from the detection rule.
-- Custom scripts or automation tools used within an organization might inadvertently create SettingContent-ms files as part of their operations. Users should review these scripts and, if deemed safe, add them to an allowlist to prevent unnecessary alerts.
-- In environments with multiple users, shared systems might see SettingContent-ms files created in unusual locations due to user-specific settings adjustments. Users can monitor these patterns and exclude paths that are consistently associated with benign user activity.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potential malicious activity.
-- Conduct a thorough investigation to identify the source and scope of the SettingContent-ms file creation, examining recent file creation events and user activity.
-- Remove any malicious SettingContent-ms files identified during the investigation to prevent further execution of harmful scripts.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if multiple systems are affected.
-- Implement enhanced logging policies to capture detailed file creation events and user actions, ensuring comprehensive monitoring of SettingContent-ms file activities.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the system to its operational state by applying clean backups and verifying the integrity of system files and settings.
-- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats.
-- Educate users on the risks associated with executing unknown files and scripts, emphasizing the importance of reporting suspicious activities.
-- Review and update security policies and configurations to harden the system against future attacks, focusing on restricting the creation and execution of SettingContent-ms files outside of legitimate directories."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_unsigned_service_executable.toml b/rules_building_block/execution_unsigned_service_executable.toml
index 7bca37b54c7..e6c2b4816cc 100644
--- a/rules_building_block/execution_unsigned_service_executable.toml
+++ b/rules_building_block/execution_unsigned_service_executable.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -38,49 +38,6 @@ process.parent.executable:"C:\\Windows\\System32\\services.exe" and
 (process.code_signature.exists:false or process.code_signature.trusted:false) and
 not process.code_signature.status : (errorCode_endpoint* or "errorChaining")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Execution of an Unsigned Service
-
-The Service Control Manager (SCM) in Windows manages the execution of system services. Adversaries exploit SCM to run unsigned executables, potentially deploying malware or gaining elevated privileges. The detection rule identifies such activities by monitoring processes initiated by SCM, specifically those lacking valid code signatures, thus flagging potential security threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand the context, including the timestamp, host information, and the specific unsigned executable that was initiated.
-- Verify the parent process by checking if `process.parent.executable` is indeed "C:\\\\Windows\\\\System32\\\\services.exe" to confirm the involvement of the Service Control Manager.
-- Examine the `process.code_signature.exists` and `process.code_signature.trusted` fields to determine if the executable lacks a signature or if the signature is untrusted.
-- Investigate the process's command line arguments and execution path to identify any anomalies or suspicious patterns.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all running services and their associated executables: `SELECT name, path, state FROM services WHERE path LIKE 'C:\\\\Windows\\\\System32\\\\%' AND NOT signed;`
-- Check the system's event logs for any related entries around the time of the alert to identify any preceding or subsequent suspicious activities.
-- Investigate the network connections of the host during the time of the alert to identify any unusual outbound or inbound traffic.
-- Review the user account context under which the unsigned service was executed to assess if it aligns with expected behavior or if it indicates potential privilege escalation.
-- Correlate the alert with other security events or alerts from the same host to identify patterns or a broader attack campaign.
-- Consult threat intelligence sources to determine if the unsigned executable or its hash is associated with known malware or threat actors.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger this rule if the executable lacks a valid code signature. Users should verify the source and purpose of the executable before excluding it.
-- Custom or in-house applications often lack code signatures. Organizations should maintain a list of trusted internal applications and exclude them from the rule.
-- Some open-source or freeware applications may not be signed. Users should assess the risk and consider excluding these applications if they are deemed safe and necessary for business operations.
-- In development environments, unsigned executables are common. Users can create exceptions for specific development machines or directories to reduce noise.
-- To manage false positives, users can create exceptions by adding specific hashes, paths, or process names to an allowlist, ensuring that only verified and trusted unsigned executables are excluded.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of potential malware.
-- Verify the unsigned service's legitimacy by cross-referencing with known software inventories and contacting the software vendor if necessary.
-- Terminate the suspicious process and any related processes to halt malicious activity.
-- Conduct a thorough investigation of the system to identify any additional indicators of compromise, such as unusual network connections or file modifications.
-- Review system logs and security alerts to determine the initial vector of compromise and assess the scope of the incident.
-- Restore the system from a known good backup if the integrity of the system is compromised and ensure all patches and updates are applied.
-- Implement enhanced logging policies to capture detailed process execution and service creation events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities and provide context for alerts.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if sensitive data is at risk.
-- Apply system hardening measures, such as enforcing strict code signing policies, disabling unnecessary services, and implementing least privilege access controls to reduce the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_wmi_wbemtest.toml b/rules_building_block/execution_wmi_wbemtest.toml
index e305b0d35df..7e05911003e 100644
--- a/rules_building_block/execution_wmi_wbemtest.toml
+++ b/rules_building_block/execution_wmi_wbemtest.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,49 +44,6 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.name : "wbemtest.exe"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WMI WBEMTEST Utility Execution
-
-Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. The WBEMTEST utility is a diagnostic tool that allows users to interact with WMI, often used for querying and managing system configurations. However, adversaries can exploit this tool to execute unauthorized commands or gather sensitive information from local or remote systems. The detection rule identifies suspicious activity by monitoring the initiation of the wbemtest.exe process, which may indicate potential misuse of WMI for malicious purposes.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "wbemtest.exe" and the event type is "start" to ensure the alert is valid.
-- Check the timestamp of the wbemtest.exe process initiation to determine when the activity occurred.
-- Identify the user account associated with the wbemtest.exe process to assess if the activity aligns with expected user behavior.
-- Investigate the parent process of wbemtest.exe to understand how it was launched and if it was initiated by a legitimate application or script.
-- Examine the command line arguments used with wbemtest.exe to identify any specific WMI queries or operations that were executed.
-- Use Osquery to gather additional context about the system state at the time of execution. Example query: `SELECT * FROM processes WHERE name = 'wbemtest.exe';`
-- Correlate the wbemtest.exe execution with other security events or logs from the same timeframe to identify any related suspicious activities.
-- Check for any network connections initiated by wbemtest.exe to determine if it was used to interact with remote systems.
-- Review historical data to see if wbemtest.exe has been executed previously on the system and if there is a pattern or increase in frequency.
-- Consult threat intelligence sources to determine if there are any known campaigns or threat actors that commonly use wbemtest.exe for malicious purposes.
-
-### False positive analysis
-
-- The WMI WBEMTEST utility is often used by system administrators and IT professionals for legitimate purposes such as troubleshooting, system monitoring, and configuration management, which can lead to false positives when monitoring for suspicious activity.
-- Automated scripts or management tools that rely on WMI for regular system checks or inventory tasks may trigger the detection rule, as they might initiate the wbemtest.exe process as part of their operations.
-- To manage these false positives, users can create exceptions for known and trusted sources, such as specific user accounts or systems that regularly perform legitimate WMI operations.
-- Implementing a baseline of normal WMI activity within the organization can help distinguish between routine use and potential misuse, allowing for more accurate detection and fewer false positives.
-- Regularly reviewing and updating the list of exceptions based on changes in IT operations or personnel can help maintain the effectiveness of the detection rule while minimizing unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the activity, including identifying any additional compromised systems or accounts.
-- Review system and security logs to trace the origin of the wbemtest.exe execution and identify any associated suspicious activities or anomalies.
-- Terminate any unauthorized processes or sessions initiated by wbemtest.exe to halt potential malicious operations.
-- Change credentials for any accounts that may have been compromised during the incident to prevent further unauthorized access.
-- Restore the system from a known good backup to ensure that any malicious changes are reverted and the system is returned to a secure state.
-- Implement enhanced logging and monitoring for WMI activities, including the execution of wbemtest.exe, to detect future misuse attempts.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to correlate and analyze WMI-related alerts more effectively.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional response actions are necessary.
-- Apply security hardening measures, such as restricting WMI access to authorized users and systems only, to reduce the attack surface and prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_member_removed_from_organization.toml b/rules_building_block/impact_github_member_removed_from_organization.toml
index 85e3ea7d152..7153494eaa4 100644
--- a/rules_building_block/impact_github_member_removed_from_organization.toml
+++ b/rules_building_block/impact_github_member_removed_from_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,49 +33,6 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.remove_member"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Member Removed From GitHub Organization
-
-GitHub Organizations manage collaborative projects, controlling member access to repositories. Adversaries might exploit this by removing members to disrupt operations or conceal unauthorized changes. The detection rule monitors audit logs for member removal actions, identifying potential misuse by correlating these events with known threat tactics, ensuring timely alerts for security teams.
-
-### Possible investigation steps
-
-- Review the audit logs to confirm the event details, focusing on the `event.dataset` and `event.action` fields to ensure the alert corresponds to a member removal action.
-- Identify the user who performed the removal by examining the `actor` field in the audit logs to determine if the action was authorized or suspicious.
-- Check the `target` field to identify the member who was removed and assess their role and access level within the organization.
-- Investigate the timing of the removal by analyzing the `timestamp` field to see if it coincides with any other suspicious activities or known threat patterns.
-- Correlate the removal event with other recent audit log entries to identify any unusual patterns or sequences of actions that might indicate malicious intent.
-- Use Osquery to gather additional context on the system from which the removal action was performed. Example query: `SELECT * FROM processes WHERE name = 'git' AND user = '<actor_username>';`
-- Examine any recent changes to critical repositories or settings that the removed member had access to, ensuring no unauthorized modifications were made.
-- Cross-reference the removal event with any recent security alerts or incidents to determine if it is part of a broader attack or compromise.
-- Verify if there were any recent changes to the organization's membership policies or permissions that could explain the removal action.
-- Consult with the organization's team members or administrators to validate the legitimacy of the removal and gather any additional context or insights.
-
-### False positive analysis
-
-- Routine administrative actions: Regular maintenance or restructuring of a GitHub Organization may involve removing members who no longer need access. These actions are typically non-threatening and can be identified by correlating with scheduled administrative tasks.
-- Employee offboarding: When employees leave a company, their access to the GitHub Organization is often removed as part of the offboarding process. This is a standard security practice and can be excluded by verifying against HR records.
-- Temporary project access: Members might be removed after completing their work on a temporary project. These removals can be considered non-threatening if they align with project timelines and deliverables.
-- Automated account management: Some organizations use automated tools to manage GitHub access, which might include removing inactive or unnecessary accounts. These actions can be excluded by identifying and trusting the automation tools in use.
-- To manage false positives, users can create exceptions for known non-threatening behaviors by maintaining a whitelist of expected member removal actions, such as those associated with specific administrative or HR processes.
-
-### Response and remediation
-
-- Immediately verify the legitimacy of the member removal by contacting the organization owner or admin to confirm if the action was authorized.
-- Review the audit logs for any suspicious activities or patterns around the time of the member removal to identify potential unauthorized access or changes.
-- If unauthorized removal is confirmed, temporarily restrict access to critical repositories and resources to prevent further unauthorized actions.
-- Restore the removed member's access if the removal was unauthorized and ensure they are informed of the incident.
-- Escalate the incident to the security team for a thorough investigation and to determine if any sensitive data or systems were compromised.
-- Implement additional logging and monitoring to capture detailed events related to member access and changes within the organization.
-- Integrate alerts with a Security Information and Event Management (SIEM) system to enhance real-time monitoring and correlation with other security events.
-- Conduct a review of current access policies and permissions to ensure they follow the principle of least privilege and adjust as necessary.
-- Educate organization members on security best practices and the importance of reporting suspicious activities promptly.
-- Consider implementing multi-factor authentication (MFA) and regular access reviews to strengthen account security and prevent unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_pat_access_revoked.toml b/rules_building_block/impact_github_pat_access_revoked.toml
index 3c9b3aa8969..4dd48492420 100644
--- a/rules_building_block/impact_github_pat_access_revoked.toml
+++ b/rules_building_block/impact_github_pat_access_revoked.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,49 +33,6 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "personal_access_token.access_revoked"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PAT Access Revoked
-
-GitHub Personal Access Tokens (PATs) are used to authenticate API requests without a password, granting access to private resources. Adversaries may exploit compromised PATs to access sensitive data or disrupt operations. The detection rule monitors audit logs for revoked PAT access, signaling potential unauthorized use or security policy enforcement, aligning with MITRE ATT&CK's account access removal technique.
-
-### Possible investigation steps
-
-- Review the audit logs to identify the specific user associated with the revoked PAT by examining the `user.name` and `user.id` fields.
-- Check the `event.time` field to determine when the PAT access was revoked and correlate this with any other suspicious activities around the same time.
-- Investigate the `source.ip` field to identify the IP address from which the PAT was used before revocation, and assess if it is a known or trusted source.
-- Examine the `repository.name` and `organization.name` fields to understand which repositories and organizations were potentially accessed using the revoked PAT.
-- Use Osquery to gather additional context on the system from which the PAT was used. For example, run the following query to list recent network connections: `SELECT * FROM process_open_sockets WHERE remote_address = '<source.ip>';`
-- Analyze the `event.outcome` field to confirm whether the revocation was successful and if there were any failed attempts to use the PAT after revocation.
-- Cross-reference the `user.email` field with internal HR or user management systems to verify the user's current status and any recent changes in their role or access levels.
-- Investigate any recent changes to the user's account settings or permissions in GitHub that might indicate unauthorized access or privilege escalation.
-- Review any recent commits or changes made by the user in the repositories accessed by the PAT to identify any unauthorized or suspicious modifications.
-- Check for any other alerts or incidents related to the same user or IP address in your security information and event management (SIEM) system to identify potential patterns or broader threats.
-
-### False positive analysis
-
-- Routine administrative actions: Revocation of PATs as part of regular security audits or policy updates can trigger false positives. Users can manage this by creating exceptions for known administrative activities.
-- User-initiated revocations: Developers or team members may revoke their own PATs when rotating credentials or leaving a project. To handle these, users can exclude events associated with specific user actions that are documented and expected.
-- Automated security tools: Some security tools automatically revoke PATs if they detect potential security issues. Users should identify and exclude these tools' actions from the detection rule to prevent false alerts.
-- Organizational policy changes: Changes in organizational security policies that require revocation of all existing PATs can lead to multiple false positives. Users can temporarily adjust the detection rule to account for these policy-driven actions.
-- Test environments: PATs used in test or development environments may be revoked frequently as part of testing processes. Users can exclude these environments from the detection rule to reduce noise.
-
-### Response and remediation
-
-- Immediately revoke any remaining access for the compromised PAT to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying any accessed or modified resources.
-- Notify affected stakeholders and teams about the incident and potential data exposure.
-- Review audit logs and other security logs to trace the adversary's actions and identify any additional compromised accounts or tokens.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging and monitoring for GitHub activities to detect similar incidents in the future.
-- Integrate security tools with GitHub to automate the detection and revocation of compromised tokens.
-- Educate users on secure token management practices, including regular rotation and minimal permissions.
-- Restore any affected systems or data to their last known good state, ensuring integrity and availability.
-- Apply hardening measures such as enforcing multi-factor authentication (MFA) for all GitHub accounts and regularly reviewing access permissions."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_user_blocked_from_organization.toml b/rules_building_block/impact_github_user_blocked_from_organization.toml
index e368bb2645f..60fb77cb60d 100644
--- a/rules_building_block/impact_github_user_blocked_from_organization.toml
+++ b/rules_building_block/impact_github_user_blocked_from_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,50 +33,6 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.block_user"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 User Blocked From Organization
-
-GitHub is a platform for version control and collaboration, crucial for software development. Organizations use it to manage access to repositories. Adversaries might exploit account access to exfiltrate data or disrupt operations. The detection rule monitors audit logs for user blocks, signaling potential unauthorized access removal, aligning with MITRE ATT&CK's account access removal technique.
-
-### Possible investigation steps
-
-- Review the audit log entry to confirm the event dataset is "github.audit" and the action is "org.block_user" to ensure the alert is valid.
-- Identify the user who was blocked by examining the relevant fields in the audit log, such as "actor" and "target" fields, to understand who initiated the block and who was blocked.
-- Check the timestamp of the event to determine when the block occurred and correlate it with any other suspicious activities around the same time.
-- Investigate the user's recent activity within the organization by reviewing their commit history, pull requests, and any other interactions with repositories to identify any unusual behavior.
-- Examine the organization's access control policies and recent changes to understand if the block aligns with any policy updates or if it was an unexpected action.
-- Cross-reference the blocked user's access permissions with other users in the organization to determine if there were any anomalies or deviations in their access level.
-- Utilize Osquery to gather additional context on the user's activity. For example, run a query to list recent login attempts or access patterns: `SELECT * FROM github_user_events WHERE user = 'blocked_user' AND action = 'login';`
-- Check for any recent security alerts or incidents reported within the organization that might have prompted the user block.
-- Review communication logs or messages within the organization to see if there was any discussion or decision-making process regarding the block.
-- Investigate any third-party integrations or applications the blocked user had access to, ensuring no unauthorized data access or exfiltration occurred through those channels.
-
-### False positive analysis
-
-- Routine administrative actions: Sometimes, users are blocked as part of regular administrative tasks, such as removing access for former employees or contractors. These actions are not malicious but can trigger the detection rule.
-- Temporary access restrictions: Users might be blocked temporarily due to policy changes or during security audits, which are non-threatening but can appear as suspicious activity.
-- Automated security tools: Some organizations use automated tools to block users based on predefined criteria, which might not always indicate a security threat.
-- To manage these false positives, organizations can create exceptions for known administrative actions by maintaining a list of expected user blocks and excluding them from alerts.
-- Implementing a review process for user blocks can help differentiate between legitimate administrative actions and potential security threats, reducing unnecessary alerts.
-- Regularly updating the list of users with temporary access can help in excluding these cases from triggering false positives.
-
-### Response and remediation
-
-- Verify the legitimacy of the block by reviewing the audit logs and confirming the action with the organization’s admin team.
-- Contain the potential threat by ensuring the blocked user no longer has access to any other organization resources or repositories.
-- Investigate the blocked user's recent activities to identify any unauthorized access or data exfiltration attempts.
-- Remediate any unauthorized changes or data breaches by restoring affected repositories from backups and revoking any compromised credentials.
-- Escalate the incident to the organization's security team if malicious intent is suspected, providing them with detailed logs and findings.
-- Enhance logging policies to ensure comprehensive audit trails for all user actions within the organization.
-- Implement additional security integrations, such as multi-factor authentication and anomaly detection tools, to prevent future unauthorized access.
-- Conduct a security review of the organization's GitHub settings and permissions to ensure they align with best practices.
-- Restore the system to its operational state by verifying that all legitimate users have appropriate access and that no unauthorized changes remain.
-- Harden the organization's security posture by regularly updating access controls and conducting security awareness training for all users."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_cross_site_scripting.toml b/rules_building_block/initial_access_cross_site_scripting.toml
index b14228c0a02..0ed9fe480fb 100644
--- a/rules_building_block/initial_access_cross_site_scripting.toml
+++ b/rules_building_block/initial_access_cross_site_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/01"
 
 [rule]
 author = ["Elastic"]
@@ -31,52 +31,6 @@ any where processor.name == "transaction" and
 url.fragment : ("<iframe*", "*prompt(*)*", "<script*>", "<svg*>", "*onerror=*", "*javascript*alert*", "*eval*(*)*", "*onclick=*",
 "*alert(document.cookie)*", "*alert(document.domain)*","*onresize=*","*onload=*","*onmouseover=*")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Cross Site Scripting (XSS)
-
-Cross-Site Scripting (XSS) exploits vulnerabilities in web applications by injecting malicious scripts into trusted sites, often targeting users' browsers. Adversaries leverage this to execute harmful scripts, potentially stealing data or hijacking sessions. The detection rule identifies suspicious script patterns in web transactions, such as script tags or event handlers, signaling potential XSS attempts.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific pattern from the query triggered the alert, such as "<script*>", "*onerror=*", or "*alert(document.cookie)*".
-- Examine the URL and URL fragment fields in the alert to identify the source and context of the suspicious script injection.
-- Check the HTTP request and response headers for any anomalies or indications of script injection attempts.
-- Analyze the user agent string to determine if the request originated from a legitimate browser or a potentially malicious source.
-- Investigate the referrer field to trace back the navigation path that led to the suspicious request, which might reveal the attack vector.
-- Use Osquery to gather additional context on the affected system. For example, run the following query to list all running browser processes and their command-line arguments:
-  ```sql
-  SELECT pid, name, path, cmdline FROM processes WHERE name LIKE '%chrome%' OR name LIKE '%firefox%' OR name LIKE '%edge%';
-  ```
-- Correlate the alert with other logs, such as web server logs or application logs, to identify any patterns or repeated attempts of similar XSS payloads.
-- Check for any recent changes or deployments in the web application that might have introduced new vulnerabilities or bypassed existing security controls.
-- Investigate the affected user's session details to determine if any unauthorized actions were performed or if sensitive data was accessed.
-- Review historical alerts and incidents to see if this is part of a larger pattern or campaign targeting the organization.
-
-### False positive analysis
-
-- Certain legitimate web applications may use script tags or event handlers for benign purposes, such as loading external resources or enhancing user interaction, which can trigger false positives in the detection rule.
-- Web development tools and frameworks often include inline scripts or event handlers for debugging or functionality testing, which might be mistakenly flagged as XSS attempts.
-- User-generated content platforms, like forums or comment sections, may allow HTML or script-like syntax for formatting or embedding media, leading to false positives if not properly sanitized.
-- To manage these false positives, users can create exceptions for known safe scripts or domains by updating the detection rule to exclude specific patterns or URLs that are verified as non-threatening.
-- Regularly reviewing and updating the list of exceptions based on the evolving web application landscape and user behavior can help minimize unnecessary alerts while maintaining security.
-
-### Response and remediation
-
-- Immediately isolate affected systems from the network to prevent further exploitation and data exfiltration.
-- Conduct a thorough investigation to identify the source and scope of the XSS attack, focusing on logs and user activity around the time of the alert.
-- Remove any injected scripts or malicious code from the affected web applications and databases.
-- Reset credentials and session tokens for users who may have been affected to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement or enhance web application firewalls (WAF) to detect and block XSS attempts in real-time.
-- Review and update input validation and output encoding practices in web applications to prevent future XSS vulnerabilities.
-- Enable comprehensive logging of web application activities and integrate with a security information and event management (SIEM) system for continuous monitoring.
-- Conduct a security awareness training session for developers and users to recognize and prevent XSS attacks.
-- Apply security patches and updates to web applications and underlying systems to mitigate known vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
index 76e69b50b21..173fa693fb1 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,49 +35,6 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and github.hashed_token:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of IP Address For GitHub Personal Access Token (PAT)
-
-GitHub Personal Access Tokens (PATs) facilitate secure API interactions, but adversaries can exploit them to gain unauthorized access. By monitoring for new IP addresses accessing PATs, this detection rule identifies potential misuse, as attackers often use unfamiliar IPs. It leverages GitHub audit logs to flag unusual activity, aligning with MITRE ATT&CK's focus on detecting valid account abuse.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific `github.actor_ip` and `github.hashed_token` involved in the suspicious activity.
-- Cross-reference the `github.actor_ip` with known IP addresses in your organization's network to determine if it is a recognized or expected IP.
-- Check the `github.audit` logs for any other activities associated with the same `github.hashed_token` to identify any patterns or additional suspicious behavior.
-- Investigate the user account associated with the `github.hashed_token` to verify if the access was legitimate or if the account may have been compromised.
-- Use Osquery to gather more information about the system from which the suspicious IP address originated. Example query: `SELECT * FROM osquery_info WHERE uuid = '<system_uuid>';` to identify the system details.
-- Analyze the `github.programmatic_access_type` to understand the scope of access granted by the token and assess the potential impact of its misuse.
-- Look for any recent changes in the `event.category:"configuration"` logs that might indicate unauthorized modifications to the GitHub account settings.
-- Check for any other alerts or incidents involving the same IP address or token in the past 14 days to identify potential patterns of attack.
-- Review the geographical location and ISP information of the `github.actor_ip` to assess if it aligns with the expected locations for your organization.
-- Collaborate with the user associated with the token to confirm if they recognize the IP address and if they have recently accessed GitHub from a new location or device.
-
-### False positive analysis
-
-- Frequent travel or remote work by legitimate users can trigger false positives when accessing GitHub from new IP addresses. Users can manage this by maintaining a list of known IP ranges associated with trusted locations and excluding them from alerts.
-- Use of VPNs or dynamic IP addresses by authorized personnel may result in new IP detections. To handle this, organizations can implement a process to regularly update and whitelist IP addresses associated with these services.
-- Automated systems or CI/CD pipelines that rotate IP addresses might be flagged. Users should document and exclude these systems' IP ranges from the detection rule to prevent unnecessary alerts.
-- Changes in corporate network infrastructure, such as new proxies or gateways, can lead to new IP addresses being flagged. It's advisable to update the detection rule with these new IP addresses as they become part of the trusted network.
-- Legitimate third-party integrations or services that access GitHub using PATs from different IP addresses can be mistaken for threats. Users should verify and whitelist these services' IP addresses to avoid false positives.
-
-### Response and remediation
-
-- Immediately revoke the compromised GitHub Personal Access Token to prevent further unauthorized access.
-- Conduct a thorough investigation to determine the scope of the breach, including identifying any unauthorized changes or data exfiltration.
-- Cross-reference the new IP address with known threat intelligence sources to assess if it is associated with malicious activity.
-- Notify the affected user and relevant stakeholders about the potential compromise and provide guidance on securing their accounts.
-- Implement multi-factor authentication (MFA) for all GitHub accounts to enhance security and prevent unauthorized access.
-- Review and update access controls and permissions to ensure the principle of least privilege is enforced across all GitHub repositories.
-- Integrate GitHub audit logs with a Security Information and Event Management (SIEM) system for continuous monitoring and alerting on suspicious activities.
-- Develop and enforce a logging policy that ensures all access and modification events are captured and retained for a sufficient period.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users on recognizing phishing attempts and the importance of safeguarding their access tokens and credentials."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_user.toml b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
index d1b33ed3c6c..b9e80d855c5 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_user.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,49 +34,6 @@ query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and user.name:*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of IP Address For GitHub User
-
-The detection rule monitors GitHub audit logs for new IP addresses associated with user accounts, flagging those not seen in the past 14 days. This helps identify potential unauthorized access attempts, as adversaries may exploit compromised credentials to gain initial access from unfamiliar IPs. By correlating IP changes with user activity, the rule aids in detecting suspicious behavior indicative of account misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of a new IP address associated with the GitHub user account, focusing on the `github.actor_ip` and `user.name` fields.
-- Verify the legitimacy of the IP address by checking its geolocation and ASN information to determine if it aligns with the user's usual activity patterns.
-- Cross-reference the new IP address with known malicious IP databases to identify any potential threats.
-- Examine the user's recent activity logs in the GitHub audit dataset to identify any unusual or unauthorized actions, such as repository access or changes in configuration.
-- Check for any recent changes in the user's account settings, such as password changes or the addition of new SSH keys, which could indicate account compromise.
-- Investigate any other users who have logged in from the same IP address to determine if there is a broader issue affecting multiple accounts.
-- Use Osquery to gather additional context on the user's machine, such as running processes or network connections, with a query like: `SELECT * FROM processes WHERE user = '<username>';`
-- Review any recent email notifications sent to the user regarding suspicious activity or login attempts from unfamiliar locations.
-- Collaborate with the user to verify if they recognize the IP address or if they have recently traveled or used a VPN service that could explain the new IP.
-- Document all findings and observations in the investigation report to maintain a comprehensive record of the analysis process.
-
-### False positive analysis
-
-- Users frequently accessing GitHub from dynamic IP addresses, such as those assigned by ISPs, may trigger false positives. To manage this, consider creating exceptions for known user accounts with dynamic IPs by maintaining a list of trusted IP ranges.
-- Employees traveling or working remotely from different locations can result in new IP addresses being flagged. Implement a process to verify travel schedules or remote work arrangements and exclude these IPs from alerts.
-- Use of VPNs or proxy services by legitimate users can cause IP address changes. Establish a list of approved VPN or proxy IP addresses and configure the rule to ignore these.
-- Automated systems or scripts that access GitHub from various cloud environments might generate alerts. Identify and whitelist IP addresses associated with these systems to prevent unnecessary alerts.
-- Regularly review and update the list of exceptions to ensure it reflects current organizational practices and does not inadvertently allow unauthorized access.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by temporarily disabling access to prevent further unauthorized actions.
-- Conduct a thorough investigation of the flagged IP address to determine its origin and assess whether it is associated with known malicious activity.
-- Review recent user activity logs to identify any unauthorized actions or changes made from the new IP address.
-- Reset the compromised user's credentials and enforce multi-factor authentication (MFA) to enhance account security.
-- Notify the affected user and relevant stakeholders about the potential security incident and provide guidance on recognizing phishing attempts and securing their accounts.
-- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if multiple accounts are affected.
-- Implement enhanced logging and monitoring policies to capture detailed user activity and IP address changes for future investigations.
-- Integrate threat intelligence feeds to correlate IP addresses with known threat actors and improve detection capabilities.
-- Restore the system to its operational state by verifying that no unauthorized changes persist and that all security measures are in place.
-- Conduct a post-incident review to identify gaps in security controls and implement hardening measures, such as regular security training and periodic access reviews, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
index a741e8e76d1..de9956f7246 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,48 +35,6 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.user_agent:* and github.hashed_token:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of User Agent For a GitHub Personal Access Token (PAT)
-
-GitHub Personal Access Tokens (PATs) facilitate programmatic access to repositories, enabling automation and integration. Adversaries may exploit PATs to gain unauthorized access, leveraging new user agents to mask their activities. This detection rule identifies anomalies by flagging unfamiliar user agents associated with PATs, indicating potential misuse or compromise, thus aiding in early threat detection and response.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific user agent and GitHub Personal Access Token (PAT) involved in the anomaly.
-- Cross-reference the user agent with known legitimate user agents used within the organization to determine if it is expected or potentially malicious.
-- Examine the `event.dataset` and `event.category` fields to confirm the event is related to GitHub audit and configuration changes, ensuring the context of the alert is accurate.
-- Investigate the `github.user_agent` field to gather more information about the new user agent, including its origin and any associated IP addresses.
-- Check the `github.hashed_token` field to identify the specific PAT involved and determine its owner or associated user account.
-- Analyze the `github.programmatic_access_type` field to understand the type of access granted by the PAT, focusing on whether it is an OAuth access token or a fine-grained personal access token.
-- Use Osquery to gather additional context on the system or environment where the new user agent was first observed. Example query: `SELECT * FROM processes WHERE name = 'github' AND user_agent = '<new_user_agent>';`
-- Review recent activity logs for the associated user account to identify any unusual or unauthorized actions that may correlate with the new user agent usage.
-- Investigate any recent changes in repository access or permissions that might have been made using the PAT, focusing on any unauthorized modifications.
-- Collaborate with the user or team associated with the PAT to verify if the new user agent usage was intentional and authorized, or if it indicates a potential compromise.
-
-### False positive analysis
-
-- Frequent updates or changes in legitimate automation tools or scripts may introduce new user agents, triggering false positives. Users should maintain an updated list of known and trusted user agents associated with their automation tools to minimize these alerts.
-- Developers or teams using multiple environments or devices for testing and development might inadvertently cause new user agents to appear. It's advisable to document and whitelist user agents from these environments if they are verified as non-threatening.
-- Integration of third-party services or plugins that access GitHub repositories using PATs can result in new user agents. Users should verify the legitimacy of these services and consider adding them to an exception list if they are deemed safe.
-- Regularly rotating or regenerating PATs as part of security best practices can lead to new user agents being flagged. Users should ensure that any new user agents resulting from such practices are reviewed and, if necessary, added to a whitelist to prevent unnecessary alerts.
-
-### Response and remediation
-
-- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access.
-- Investigate the source of the new user agent by reviewing logs to determine if it aligns with known or expected activity.
-- Conduct a thorough review of recent repository changes and access logs to identify any unauthorized actions or data exfiltration.
-- Notify the affected user and relevant security teams about the potential compromise and provide guidance on securing their accounts.
-- Escalate the incident to the security operations center (SOC) if unauthorized access or data breach is confirmed.
-- Implement enhanced logging and monitoring for GitHub activities, focusing on user agent changes and PAT usage.
-- Integrate security information and event management (SIEM) tools to correlate GitHub events with other security data for comprehensive threat detection.
-- Educate users on the importance of using strong, unique PATs and regularly rotating them to minimize the risk of compromise.
-- Restore any affected repositories or systems to their last known good state, ensuring that all unauthorized changes are reverted.
-- Apply security hardening measures, such as enforcing multi-factor authentication (MFA) for all GitHub accounts and restricting PAT scopes to the minimum necessary permissions."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_user.toml b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
index 2f338eb691b..15d3b4dfcf7 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_user.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,49 +34,6 @@ query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
 github.user_agent:* and user.name:*
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of User-Agent For a GitHub User
-User-Agent strings identify the software acting on behalf of a user, such as browsers or scripts, in GitHub environments. Adversaries may exploit this by using unfamiliar User-Agents to mask unauthorized access. The detection rule identifies new User-Agents associated with GitHub users, flagging potential unauthorized access attempts by comparing against a 14-day history.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific GitHub user and the new User-Agent string that triggered the alert.
-- Cross-reference the User-Agent string with known legitimate User-Agents to determine if it is commonly associated with authorized applications or browsers.
-- Check the GitHub audit logs for any other recent activities associated with the same user to identify any unusual patterns or anomalies.
-- Investigate the IP address associated with the new User-Agent to determine its geolocation and assess if it aligns with the user's typical access patterns.
-- Examine the event timestamps to see if the new User-Agent coincides with any known maintenance or deployment activities that could explain the change.
-- Utilize Osquery to gather additional context from the user's machine, such as running processes or network connections. Example query: `SELECT * FROM processes WHERE name LIKE '%github%' OR path LIKE '%github%';`
-- Review any recent changes in the user's access permissions or roles within the GitHub organization to assess if there have been unauthorized modifications.
-- Check for any recent password changes or multi-factor authentication (MFA) events for the user to determine if there have been attempts to secure the account.
-- Analyze any other security alerts or incidents involving the same user or User-Agent to identify potential correlations or patterns.
-- Consult with the user or relevant team members to verify if the new User-Agent is expected and authorized, documenting any findings for future reference.
-
-### False positive analysis
-
-- Frequent legitimate changes in User-Agent strings can occur due to updates in browsers or scripts used by GitHub users, leading to false positives. 
-- Automated tools or CI/CD systems that regularly update their User-Agent strings might trigger alerts despite being authorized and non-threatening.
-- Users accessing GitHub from different devices or networks may have varying User-Agent strings, which could be mistakenly flagged as suspicious.
-- To manage these false positives, users can create exceptions for known and trusted User-Agent strings that frequently change but are verified as non-malicious.
-- Implementing a whitelist of User-Agent strings associated with specific automated tools or scripts can help reduce unnecessary alerts.
-- Regularly reviewing and updating the list of exceptions based on user behavior and tool updates can help maintain the balance between security and usability.
-
-### Response and remediation
-
-- Immediately isolate the affected user account by disabling access to prevent further unauthorized actions.
-- Conduct a thorough investigation of the new User-Agent string to determine if it is associated with known malicious activity or legitimate changes.
-- Review recent activity logs for the affected user account to identify any suspicious actions or unauthorized access attempts.
-- Reset the credentials for the affected user account and enforce multi-factor authentication to enhance security.
-- Escalate the incident to the security operations team if the investigation reveals signs of a broader compromise or if multiple accounts are affected.
-- Implement enhanced logging policies to capture detailed User-Agent information and other relevant metadata for future analysis.
-- Integrate threat intelligence feeds to correlate User-Agent strings with known threat actors or attack patterns.
-- Restore the system to its operational state by ensuring all unauthorized changes are reverted and security controls are re-enabled.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Apply hardening measures such as regular audits of user access permissions and continuous monitoring of user activity to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_at.toml b/rules_building_block/lateral_movement_at.toml
index 31745de4cfb..7d63c514bbc 100644
--- a/rules_building_block/lateral_movement_at.toml
+++ b/rules_building_block/lateral_movement_at.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,49 +44,6 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.name : "at.exe" and process.args : "\\\\*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 At.exe Command Lateral Movement
-
-The `at.exe` utility is a legacy Windows command-line tool used to schedule tasks on local or remote systems. Adversaries may exploit this tool to execute tasks on remote hosts, facilitating lateral movement within a network. The detection rule identifies suspicious use of `at.exe` by monitoring for its execution with network paths, which may indicate attempts to schedule tasks on remote systems, a common tactic in lateral movement.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `at.exe` execution with network paths in the `process.args` field, indicating potential remote task scheduling.
-- Verify the `host.os.type` field to ensure the event occurred on a Windows system, as `at.exe` is specific to Windows environments.
-- Examine the `event.type` field to confirm the process start event, ensuring that the alert is triggered by the execution of `at.exe`.
-- Investigate the source host by checking the hostname or IP address to determine if it is a known or trusted system within the network.
-- Analyze the destination network path in the `process.args` field to identify the target host and assess if it is a legitimate target for task scheduling.
-- Check the user account associated with the `at.exe` execution to determine if it is a privileged account and if the activity aligns with the user's typical behavior.
-- Use Osquery to gather additional context on the source host by running a query such as: `SELECT * FROM processes WHERE name = 'at.exe';` to identify any related processes or anomalies.
-- Review historical logs and previous alerts for similar `at.exe` executions to identify patterns or repeated attempts of lateral movement.
-- Correlate the `at.exe` activity with other network or host-based alerts to determine if it is part of a larger attack campaign or isolated incident.
-- Consult with system administrators or the user associated with the alert to verify if the `at.exe` execution was authorized or part of a legitimate task scheduling activity.
-
-### False positive analysis
-
-- Scheduled administrative tasks: Legitimate IT operations may use `at.exe` to schedule routine maintenance or updates on remote systems, which can trigger the detection rule. Users should identify and document these tasks to differentiate them from malicious activity.
-- Backup operations: Some backup solutions might use `at.exe` to initiate backup processes on remote machines. Users can create exceptions for known backup operations by specifying the associated network paths or process arguments.
-- Software deployment: Organizations deploying software across multiple systems might use `at.exe` for task scheduling. Users should maintain a list of authorized deployment activities and exclude these from alerts.
-- Testing and development: Developers or IT staff might use `at.exe` in test environments to simulate task scheduling. Users can exclude specific test environments or user accounts from triggering alerts.
-- To manage false positives, users can implement exceptions by creating allowlists for known benign network paths or specific user accounts frequently associated with non-threatening `at.exe` usage. This helps in reducing noise and focusing on genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Verify the legitimacy of the scheduled tasks created by at.exe by reviewing the task details and the user account that initiated them.
-- Terminate any unauthorized or suspicious tasks that were scheduled using at.exe to halt potential malicious activities.
-- Conduct a thorough investigation to identify any other systems that may have been targeted or compromised using similar tactics.
-- Review and analyze logs from the affected system and any connected systems to trace the adversary's actions and identify their entry point.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and network activity, focusing on remote task scheduling attempts.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
-- Restore the affected system to its operational state by removing any malicious artifacts and applying necessary security patches and updates.
-- Harden the environment by disabling legacy tools like at.exe if not needed, and enforce strict access controls and network segmentation to limit lateral movement opportunities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_posh_winrm_activity.toml b/rules_building_block/lateral_movement_posh_winrm_activity.toml
index 238782d47b1..1ab4424ae66 100644
--- a/rules_building_block/lateral_movement_posh_winrm_activity.toml
+++ b/rules_building_block/lateral_movement_posh_winrm_activity.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 
 [rule]
 author = ["Elastic"]
@@ -64,48 +64,6 @@ event.category:process and host.os.type:windows and
     "function Invoke-Command {"
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 PowerShell Script with Remote Execution Capabilities via WinRM
-
-Windows Remote Management (WinRM) facilitates remote command execution and management, leveraging PowerShell for automation. Adversaries exploit this by using cmdlets like `Invoke-Command` to move laterally across networks. The detection rule identifies suspicious PowerShell scripts executing remotely via WinRM, excluding benign processes, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific PowerShell cmdlet triggered the alert, focusing on `Invoke-WmiMethod`, `Invoke-Command`, or `Enter-PSSession` with the `ComputerName` parameter.
-- Check the `event.category:process` and `host.os.type:windows` fields to confirm the event is related to a Windows process execution.
-- Investigate the user context by examining the `user.id` field to determine if the activity was performed by a non-system account, as the rule excludes the system account `S-1-5-18`.
-- Analyze the `powershell.file.script_block_text` to understand the script's intent and identify any potentially malicious commands or patterns.
-- Verify the file path in `file.directory` to ensure the script did not originate from a known benign directory like `C:\\\\Program Files\\\\LogicMonitor\\\\Agent\\\\tmp`.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'powershell.exe' AND path NOT LIKE 'C:\\\\Program Files\\\\LogicMonitor\\\\Agent\\\\tmp\\\\%' AND user_id != 'S-1-5-18';`
-- Cross-reference the alert with recent login events to identify any unusual or unauthorized access patterns that might correlate with the PowerShell activity.
-- Examine network logs for connections to the `ComputerName` specified in the PowerShell command to identify any unexpected or unauthorized remote connections.
-- Review historical data for the involved user account and host to identify any previous suspicious activities or patterns that might indicate a broader compromise.
-- Consult threat intelligence sources to determine if the observed PowerShell script or its components are associated with known malicious campaigns or threat actors.
-
-### False positive analysis
-
-- Legitimate administrative tasks: System administrators often use PowerShell cmdlets like `Invoke-Command` and `Enter-PSSession` for routine management tasks across multiple machines. These activities can trigger the detection rule, leading to false positives. To manage this, users can create exceptions for specific user accounts or IP addresses known to perform these tasks regularly.
-- Monitoring and management software: Some software solutions, such as monitoring tools, may use similar PowerShell commands to gather data or perform actions on remote systems. These benign processes can be excluded by adding their file directories or specific script block texts to the exception list.
-- Automated scripts: Organizations may have automated scripts that utilize WinRM for legitimate purposes, such as deploying updates or configurations. Identifying these scripts and excluding their specific characteristics, like script names or execution paths, can help reduce false positives.
-- Service accounts: Service accounts that are used for legitimate remote management tasks might trigger alerts. Users can exclude these accounts by adding their user IDs to the exception list, ensuring that only unexpected or unauthorized use is flagged.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
-- Conduct a thorough investigation to identify the source of the PowerShell script execution, including reviewing logs for any unauthorized access or changes.
-- Terminate any suspicious PowerShell processes running on the affected system to halt ongoing malicious activities.
-- Reset credentials for any compromised accounts to prevent further unauthorized access.
-- Review and update firewall rules to restrict WinRM access to only trusted hosts and networks.
-- Implement enhanced logging for PowerShell activities, including script block logging and module logging, to improve future detection capabilities.
-- Integrate security information and event management (SIEM) solutions to correlate and analyze logs for suspicious activities across the network.
-- Restore the system from a known good backup to ensure the removal of any persistent threats or unauthorized changes.
-- Apply security patches and updates to the operating system and applications to mitigate known vulnerabilities.
-- Educate users and administrators on secure practices for remote management and the risks associated with improper use of WinRM and PowerShell."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
index 02280db35de..c6ca1947e93 100644
--- a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
+++ b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/09/01"
 
 [rule]
 author = ["Elastic"]
@@ -49,49 +49,6 @@ network where host.os.type == "windows" and
     ) and process.code_signature.trusted == true
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Potential Outgoing RDP Connection by Unusual Process
-
-Remote Desktop Protocol (RDP) enables users to connect to other systems over a network, facilitating remote management and troubleshooting. However, adversaries can exploit RDP for lateral movement within a network, often bypassing detection by using non-standard processes. The detection rule identifies unusual processes attempting RDP connections, excluding known legitimate applications, to flag potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to identify the unusual process attempting the RDP connection, focusing on the `process.executable` field to determine the exact path and name of the executable.
-- Verify the `process.code_signature.trusted` field to check if the process is signed and trusted, which might indicate a false positive if the signature is valid.
-- Examine the `destination.ip` field to identify the target of the RDP connection and determine if it is an internal or external IP address, which can provide context on the potential risk.
-- Investigate the `host.os.type` field to confirm the operating system is Windows, as the rule is specifically designed for Windows environments.
-- Use Osquery to gather additional context about the process by running a query such as: `SELECT * FROM processes WHERE path = '<path_to_unusual_process>';` to retrieve details like process ID, parent process, and command line arguments.
-- Check the process's parent process to understand the process hierarchy and determine if the parent process is legitimate or potentially malicious.
-- Analyze network logs to identify any other unusual network activity originating from the same host, focusing on other connection attempts or data transfers.
-- Review recent system logs and security events on the host to identify any other suspicious activities or anomalies that coincide with the RDP connection attempt.
-- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of account compromise.
-- Correlate the findings with threat intelligence sources to check if the unusual process or IP address is associated with known malicious activity or campaigns.
-
-### False positive analysis
-
-- Known false positives may include legitimate applications or scripts that are not part of the predefined exclusion list but are used for remote management or monitoring purposes. These could be custom IT management tools or scripts developed in-house.
-- Users can handle these false positives by identifying and documenting any legitimate processes that frequently trigger the rule. Once identified, these processes can be added to the exclusion list, ensuring they are signed and trusted.
-- Another potential false positive source is automated tasks or scheduled jobs that use RDP for legitimate purposes. Users should review scheduled tasks and automation scripts to determine if they are causing alerts and consider excluding them if they are verified as non-threatening.
-- It's important to regularly review and update the exclusion list to accommodate changes in the organization's software landscape, ensuring that new legitimate tools are not mistakenly flagged.
-- Users should also consider the context of the network environment, such as known IP addresses or subnets that are part of regular operations, and adjust the rule to exclude these from triggering alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further lateral movement by the adversary.
-- Verify the legitimacy of the process attempting the RDP connection by checking its executable path and code signature.
-- Conduct a thorough investigation of the system to identify any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
-- Review recent RDP connection logs to identify any other unusual or unauthorized access attempts.
-- If malicious activity is confirmed, remove any identified malware or unauthorized software from the system.
-- Reset credentials for any accounts that may have been compromised during the incident.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed process execution and network connection events for future investigations.
-- Integrate threat intelligence feeds and endpoint detection and response (EDR) solutions to improve detection capabilities.
-- Apply system hardening measures, such as disabling RDP if not needed, enforcing strong password policies, and ensuring all systems are up to date with security patches."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
index 66445e92336..dbc9fce692a 100644
--- a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
+++ b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -74,49 +74,6 @@ process where event.type == "start" and host.os.type == "windows" and
     (process.name : "cmd.exe" and process.parent.name : "forfiles.exe" and process.command_line : "/c echo *")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Unusual Process For MSSQL Service Accounts
-
-MSSQL service accounts are integral to managing SQL Server operations, executing processes necessary for database management. Adversaries may exploit these accounts to execute unauthorized processes, gaining initial access or moving laterally within a network. The detection rule identifies atypical processes initiated by MSSQL service accounts, excluding known legitimate activities, to flag potential exploitation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific MSSQL service account and process that triggered the alert, focusing on the `user.name` and `process.name` fields.
-- Verify the legitimacy of the process by checking the `process.executable` path and comparing it against known legitimate paths for MSSQL-related processes.
-- Examine the `process.code_signature` fields to determine if the process is signed by a trusted entity, such as "Microsoft Corporation," and if the signature is valid.
-- Investigate the parent process using the `process.parent.name` field to understand the process hierarchy and identify any unusual parent-child relationships.
-- Check the `process.command_line` field for any suspicious or unexpected command-line arguments that could indicate malicious activity.
-- Use Osquery to gather additional context about the process. For example, run the following query to list all processes started by the MSSQL service account: `SELECT pid, name, path, cmdline FROM processes WHERE uid = (SELECT uid FROM users WHERE username = 'MSSQLSERVER');`
-- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
-- Investigate the network activity associated with the process to identify any unusual connections or data transfers that could indicate lateral movement or data exfiltration.
-- Review recent changes or updates to the SQL Server configuration or environment that could explain the unusual process execution.
-- Consult with the database administration team to verify if the process execution aligns with any recent maintenance tasks or legitimate administrative activities.
-
-### False positive analysis
-
-- Scheduled tasks or maintenance scripts that run under MSSQL service accounts may trigger false positives if they execute processes not typically associated with SQL operations. Users should review these tasks and consider excluding them if they are verified as legitimate.
-- Custom monitoring or backup solutions that interact with SQL Server and use service accounts might be flagged. Users can create exceptions for these processes by adding them to the exclusion list if they are confirmed to be safe.
-- Third-party applications that integrate with SQL Server and require execution of specific processes under MSSQL service accounts could be mistakenly identified as threats. Users should validate these applications and exclude their processes if they are deemed non-threatening.
-- In environments with custom SQL Server configurations or extensions, legitimate processes might not be recognized by the rule. Users should document these configurations and adjust the detection criteria to prevent unnecessary alerts.
-- Users can manage false positives by regularly reviewing the list of excluded processes and ensuring that only verified, non-malicious activities are exempted from detection.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying any unauthorized processes initiated by MSSQL service accounts.
-- Review and analyze logs from the affected system and related network devices to trace the attacker's activities and identify any additional compromised systems.
-- Terminate any unauthorized processes and remove any malicious files or scripts found on the system.
-- Reset credentials for all MSSQL service accounts and any other potentially compromised accounts to prevent further unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging policies to capture detailed process execution and user activity, ensuring that future anomalies can be detected more effectively.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities and correlate events across the network.
-- Restore the system to its operational state by applying the latest security patches, updating antivirus definitions, and ensuring all security configurations are in place.
-- Harden the environment by implementing network segmentation, restricting MSSQL service account permissions, and applying the principle of least privilege to minimize the attack surface."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_wmic_remote.toml b/rules_building_block/lateral_movement_wmic_remote.toml
index f26e3a63b0c..0125b3949d9 100644
--- a/rules_building_block/lateral_movement_wmic_remote.toml
+++ b/rules_building_block/lateral_movement_wmic_remote.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,49 +43,6 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : ("call", "set", "get") and
   not process.args : ("*/node:localhost*", "*/node:\"127.0.0.1\"*", "/node:127.0.0.1")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 WMIC Remote Command
-
-WMIC (Windows Management Instrumentation Command-line) is a powerful tool for managing Windows systems, allowing administrators to execute commands on remote hosts. However, attackers can exploit WMIC for lateral movement by executing commands on other systems within a network. The detection rule identifies suspicious WMIC usage by monitoring command executions targeting remote nodes, excluding local addresses, to flag potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of `WMIC.exe` in the `process.name` field and ensure the `process.args` include remote node specifications.
-- Verify the `host.os.type` is "windows" and the `event.type` is "start" to ensure the alert is relevant to the rule.
-- Examine the `process.args` field to identify the specific command executed (e.g., "call", "set", "get") and the targeted remote node.
-- Check for any exclusion patterns in `process.args` to ensure the command was not targeting local addresses like "localhost" or "127.0.0.1".
-- Correlate the alert with other logs or alerts from the same host to identify any patterns or sequences of suspicious activities.
-- Investigate the user account associated with the process execution to determine if it is a legitimate administrative account or potentially compromised.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'WMIC.exe';` to retrieve details like process ID, parent process, and execution path.
-- Analyze network logs to identify any unusual connections or data transfers between the source and target nodes around the time of the alert.
-- Review historical data to determine if there have been previous instances of similar WMIC usage from the same host or user account.
-- Consult threat intelligence sources to check if the remote node or any associated IP addresses have been flagged for malicious activity.
-
-### False positive analysis
-
-- Legitimate administrative tasks: Administrators often use WMIC for routine management tasks across multiple systems, which can trigger the detection rule. To manage this, users can create exceptions for known administrative accounts or specific command patterns that are regularly used for maintenance.
-- Automated scripts and management tools: Some automated scripts or third-party management tools may utilize WMIC to perform legitimate operations on remote hosts. Users should identify these scripts or tools and exclude their specific command patterns or originating accounts from the detection rule.
-- Monitoring and alerting systems: Certain monitoring solutions might use WMIC to gather system information from remote hosts. Users can handle these false positives by excluding the IP addresses or hostnames of known monitoring systems from the rule.
-- Scheduled tasks: Scheduled tasks that use WMIC for legitimate purposes, such as system updates or health checks, can also be excluded by identifying the specific task names or associated user accounts.
-- Testing and development environments: In environments where WMIC is used frequently for testing or development purposes, users can exclude specific IP ranges or hostnames associated with these environments to reduce noise in alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
-- Conduct a thorough investigation to determine the scope of the compromise, focusing on identifying other systems that may have been targeted or affected.
-- Review WMIC logs and other relevant system logs to gather evidence of unauthorized access and command execution.
-- Change all credentials that may have been exposed or used during the attack, especially those with administrative privileges.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
-- Implement enhanced logging policies to capture detailed information on WMIC usage and other remote command executions.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection capabilities for similar threats in the future.
-- Restore the affected system from a known good backup to ensure it is free from any malicious modifications.
-- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for lateral movement.
-- Implement network segmentation and access controls to limit the ability of attackers to move laterally within the network."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
index 125e8722286..f4aaaef461d 100644
--- a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
+++ b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -39,48 +39,6 @@ query = '''
 event.dataset: aws.cloudtrail and event.provider: "iam.amazonaws.com"
     and event.action: "CreateLoginProfile" and event.outcome: success
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS IAM Login Profile Added to User
-
-AWS IAM login profiles enable console access for users, typically reserved for programmatic access. Adversaries may exploit this by adding a login profile to maintain access even if access keys are changed. The detection rule monitors AWS CloudTrail logs for successful login profile creations, aiding in identifying unauthorized persistence attempts by correlating with other suspicious activities.
-
-### Possible investigation steps
-
-- Review the AWS CloudTrail logs to confirm the `CreateLoginProfile` event by filtering logs with `event.dataset: aws.cloudtrail` and `event.provider: "iam.amazonaws.com"`.
-- Verify the `event.action: "CreateLoginProfile"` and `event.outcome: success` fields to ensure the login profile creation was successful.
-- Identify the IAM user associated with the login profile creation by examining the `userIdentity.arn` field in the CloudTrail logs.
-- Check the `sourceIPAddress` and `userAgent` fields to determine the origin of the request and assess if it aligns with expected activity.
-- Investigate the `eventTime` field to establish a timeline and correlate with other activities or alerts around the same time.
-- Use Osquery to gather additional context on the IAM user by running a query such as: `SELECT * FROM aws_iam_users WHERE user_name = '<IAM User Name>';` to retrieve details about the user.
-- Examine the IAM user's activity history to identify any unusual or unauthorized actions by querying for recent events involving the user.
-- Review the IAM policies attached to the user to assess their permissions and determine if they have been modified recently.
-- Cross-reference the login profile creation with other security alerts or logs to identify potential patterns or indicators of compromise.
-- Consult with relevant stakeholders or teams to verify if the login profile creation was authorized and aligns with any ongoing projects or changes.
-
-### False positive analysis
-
-- Routine administrative actions: Legitimate IAM administrators may create login profiles for users as part of regular account management or onboarding processes. To handle these, identify and document such activities and consider excluding them from alerts by creating exceptions for specific IAM administrator accounts or known maintenance periods.
-- Automated provisioning tools: Some organizations use automated tools or scripts to manage IAM users, which may include creating login profiles as part of their workflow. To manage these false positives, review and whitelist actions performed by these tools, ensuring they are recognized as non-threatening.
-- User role changes: Users transitioning from programmatic access to console access may require a login profile. In such cases, verify the legitimacy of the role change and exclude these events from alerts by correlating them with approved change management records.
-- Training and testing environments: In environments where IAM configurations are frequently modified for training or testing purposes, these actions may trigger false positives. To mitigate this, exclude specific environments or accounts used for training and testing from the detection rule.
-
-### Response and remediation
-
-- Immediately disable the newly created login profile to prevent unauthorized access.
-- Review CloudTrail logs to identify the source IP and user agent associated with the login profile creation for further investigation.
-- Correlate the event with other suspicious activities, such as unusual login attempts or changes to IAM policies, to assess the scope of the potential compromise.
-- Verify the IAM user's intended use and confirm with the account owner if the login profile creation was authorized.
-- Rotate and reissue access keys for the affected IAM user to ensure no unauthorized access persists.
-- Implement multi-factor authentication (MFA) for all IAM users to enhance security and prevent unauthorized access.
-- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further action is required.
-- Review and update IAM policies to enforce the principle of least privilege and restrict unnecessary permissions.
-- Enhance logging and monitoring by enabling AWS CloudTrail and AWS Config to track changes and maintain a history of AWS account activity.
-- Conduct a security awareness session for users to educate them on the importance of securing IAM credentials and recognizing potential security threats."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
index 61e13fe0b16..6da7d3f2bff 100644
--- a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
+++ b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/01/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -65,48 +65,6 @@ event.category:"process" and host.os.type:"linux" and event.type:"start" and eve
 (process.thread.capabilities.effective:"CAP_SYS_ADMIN" or process.thread.capabilities.permitted:"CAP_SYS_ADMIN") and
 not user.id:"0"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 CAP_SYS_ADMIN Assigned to Binary
-
-In Linux, the CAP_SYS_ADMIN capability grants extensive system administration privileges, enabling processes to perform critical operations like mounting filesystems and configuring networks. Adversaries may exploit binaries with this capability to escalate privileges. The detection rule identifies non-root processes executing with CAP_SYS_ADMIN, signaling potential misuse or misconfiguration.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of CAP_SYS_ADMIN in the effective or permitted capabilities of the process, ensuring the process is not running as root (user.id:"0").
-- Identify the process name and path (process.name) to determine if it is a known or expected binary on the system.
-- Check the process's parent process (process.parent.name) to understand the context of how the process was initiated.
-- Investigate the user account (user.id) associated with the process to determine if it is a legitimate user or potentially compromised.
-- Use Osquery to list all processes with CAP_SYS_ADMIN capabilities by running: `SELECT pid, name, path, uid, gid FROM processes WHERE capabilities LIKE '%CAP_SYS_ADMIN%';` to gather more context on other processes with similar capabilities.
-- Examine recent system logs and audit logs for any unusual activity or errors related to the process or user account.
-- Investigate the binary's file integrity and permissions to ensure it has not been tampered with or improperly configured.
-- Cross-reference the process's hash or signature against known malware databases to rule out any known threats.
-- Analyze network activity associated with the process to identify any suspicious connections or data transfers.
-- Consult with system administrators or application owners to verify if the process and its capabilities are expected and authorized within the environment.
-
-### False positive analysis
-
-- Known false positives for the CAP_SYS_ADMIN Assigned to Binary rule may include legitimate administrative tools or scripts that require CAP_SYS_ADMIN capabilities for routine operations, such as backup software, monitoring agents, or container management tools.
-- Users can handle these false positives by creating exceptions for specific processes or users that are known to require CAP_SYS_ADMIN capabilities for legitimate purposes. This can be done by adding exclusions in the detection rule for specific process names or user IDs that are verified to be non-threatening.
-- It is important to regularly review and update these exceptions to ensure they remain relevant and do not inadvertently allow malicious activity. This involves monitoring the behavior of excluded processes to confirm they continue to operate within expected parameters.
-- Additionally, users should consider the context of the system and its typical usage patterns. For example, a development server may have different legitimate uses of CAP_SYS_ADMIN compared to a production server, and exceptions should be tailored accordingly.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
-- Conduct a thorough investigation to identify the source of the CAP_SYS_ADMIN capability assignment, reviewing recent changes and user activities.
-- Terminate any suspicious processes running with CAP_SYS_ADMIN capabilities that are not associated with legitimate system administration tasks.
-- Review and audit user accounts and permissions to ensure no unauthorized privilege escalations have occurred.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement enhanced logging for process execution and capability changes to improve detection of similar incidents in the future.
-- Integrate security tools with SIEM solutions to automate the detection of CAP_SYS_ADMIN misuse and generate alerts for security teams.
-- Restore the system to a known good state using backups, ensuring that any unauthorized changes are reverted.
-- Apply system hardening measures, such as restricting the use of capabilities and employing the principle of least privilege for user accounts.
-- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_creation_of_kernel_module.toml b/rules_building_block/persistence_creation_of_kernel_module.toml
index 8e1226c7d98..4ba49615de2 100644
--- a/rules_building_block/persistence_creation_of_kernel_module.toml
+++ b/rules_building_block/persistence_creation_of_kernel_module.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -35,48 +35,6 @@ file.extension == "ko" and not process.name : (
   "dpkg", "systemd", "falcon-sensor*", "dnf", "yum", "rpm", "cp"
 )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Creation of Kernel Module
-
-Kernel modules are dynamic components that extend the functionality of the Linux kernel, often used for hardware drivers or system enhancements. Adversaries may exploit this by loading malicious modules to gain persistence or execute unauthorized actions at a low level. The detection rule identifies suspicious module creation by monitoring changes in the kernel module directory, excluding known legitimate processes, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific kernel module file was created or changed, focusing on the file path and extension, particularly looking for ".ko" files in "/lib/modules/*".
-- Identify the process responsible for the creation or modification of the kernel module by examining the process name and ensuring it is not one of the excluded legitimate processes like "dpkg", "systemd", "falcon-sensor*", "dnf", "yum", "rpm", or "cp".
-- Check the timestamp of the event to determine when the suspicious activity occurred and correlate it with other system activities or logs around the same time.
-- Use Osquery to list all currently loaded kernel modules and compare them against known legitimate modules. Example query: `SELECT * FROM kernel_modules;`
-- Investigate the parent process of the process that created or modified the kernel module to understand the origin of the activity and whether it was initiated by a user or another process.
-- Examine system logs, such as syslog or dmesg, for any related entries that might provide additional context or indicate other suspicious activities around the time of the module creation.
-- Verify the integrity and authenticity of the suspicious kernel module file by checking its hash against known good hashes or using a tool to analyze its contents for malicious code.
-- Investigate the user account associated with the process that created or modified the kernel module to determine if it has been compromised or is exhibiting unusual behavior.
-- Review recent system changes or updates that might have legitimately introduced new kernel modules, ensuring they align with expected maintenance or deployment activities.
-- Cross-reference the alert with threat intelligence sources to determine if the kernel module or associated process is linked to known malware or adversary techniques.
-
-### False positive analysis
-
-- Routine system updates or package installations can trigger false positives as legitimate processes like `dpkg`, `dnf`, `yum`, and `rpm` may create or modify kernel modules during their operations. These processes are already excluded in the detection rule, but additional package managers or custom scripts might need to be added to the exclusion list.
-- Security or monitoring tools such as `falcon-sensor` may also create or modify kernel modules as part of their normal operation. If other similar tools are in use, consider adding them to the exclusion list to prevent false positives.
-- Custom scripts or administrative tasks that involve kernel module management might inadvertently trigger the rule. Users should review these scripts and, if deemed safe, add them to the exclusion list to avoid unnecessary alerts.
-- To handle these false positives, users can update the detection rule to include additional known legitimate processes or paths in the exclusion list, ensuring that only truly suspicious activities are flagged.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the legitimacy of the kernel module by checking the file's origin, creation time, and associated processes.
-- Use forensic tools to capture a memory dump and disk image of the affected system for further analysis.
-- Review system logs and audit trails to identify any unauthorized access or changes made around the time of the kernel module creation.
-- Remove the suspicious kernel module and any associated files or processes from the system.
-- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to detect and remove any additional threats.
-- Restore the system from a known good backup if the integrity of the system cannot be assured.
-- Implement enhanced logging policies to monitor kernel module directories and critical system files for unauthorized changes.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and response capabilities.
-- Review and update security policies and procedures to include kernel module monitoring and ensure compliance with best practices for system hardening and threat mitigation."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_github_new_pat_for_user.toml b/rules_building_block/persistence_github_new_pat_for_user.toml
index b2a91b7f812..1e6f93f050b 100644
--- a/rules_building_block/persistence_github_new_pat_for_user.toml
+++ b/rules_building_block/persistence_github_new_pat_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,52 +35,6 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.hashed_token:* and user.name:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 First Occurrence of Personal Access Token (PAT) Use For a GitHub User
-
-Personal Access Tokens (PATs) in GitHub provide a way to authenticate programmatic access to repositories, enabling automation and integration. However, adversaries can exploit PATs to maintain persistent access or manipulate accounts. The detection rule identifies unusual PAT usage by flagging tokens not seen in the past 14 days, helping to uncover potential unauthorized access or account manipulation attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific GitHub user and the hashed token involved in the alert.
-- Verify the legitimacy of the GitHub user by cross-referencing with internal user directories or HR records to ensure the account is valid and active.
-- Check the event timestamp to determine when the PAT was first used and correlate it with any known user activities or changes.
-- Investigate the `event.dataset` and `event.category` fields to confirm the event is related to GitHub audit and configuration changes, ensuring the alert is not a false positive.
-- Examine the `github.programmatic_access_type` field to understand the type of token used (OAuth access token or Fine-grained personal access token) and assess the potential risk level.
-- Analyze the user's recent activity logs in GitHub to identify any unusual or unauthorized actions that may have occurred around the time of the PAT usage.
-- Use Osquery to gather additional context on the system where the PAT was used. For example, run the following query to list recent network connections that might indicate where the token was used:
-  ```sql
-  SELECT * FROM process_open_sockets WHERE remote_address IS NOT NULL;
-  ```
-- Investigate any recent changes to the user's account settings or permissions in GitHub that could indicate account manipulation.
-- Cross-reference the hashed token with any known compromised tokens or security incidents to determine if it matches any previously identified threats.
-- Collaborate with the user or their manager to verify if the PAT usage was authorized and part of a legitimate automation or integration process.
-
-### False positive analysis
-
-- Frequent legitimate use of new PATs by developers or automation scripts can trigger false positives. Developers often create new tokens for different projects or environments, which may not indicate malicious activity.
-- Automated systems or CI/CD pipelines that generate new PATs for each deployment cycle can also be flagged. These systems might use tokens for short-lived tasks, leading to frequent new token appearances.
-- To manage these false positives, users can create exceptions for known developers or systems that regularly generate new PATs. This can be done by maintaining a whitelist of user accounts or systems that are expected to exhibit such behavior.
-- Implementing a monitoring period longer than 14 days for specific users or systems can help differentiate between normal and suspicious activity, reducing the likelihood of false positives.
-- Regularly reviewing and updating the list of exceptions based on changes in team members or system configurations can ensure that only non-threatening behaviors are excluded from alerts.
-
-### Response and remediation
-
-- Immediately revoke the suspicious Personal Access Token (PAT) to prevent further unauthorized access.
-- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized changes or data access.
-- Notify the affected user and relevant security teams about the incident and provide guidance on securing their account, including changing passwords and enabling two-factor authentication.
-- Investigate the source of the PAT compromise by reviewing logs and identifying any potential phishing attempts or credential leaks.
-- Escalate the incident to the security operations center (SOC) if there is evidence of broader compromise or if multiple accounts are affected.
-- Implement enhanced logging and monitoring for GitHub activities to detect unusual patterns or unauthorized access attempts in the future.
-- Integrate security tools with GitHub to automate the detection and alerting of suspicious PAT usage.
-- Review and update access controls and permissions for GitHub repositories to ensure the principle of least privilege is enforced.
-- Conduct a post-incident review to identify gaps in the current security posture and update incident response plans accordingly.
-- Educate users on the importance of securing their PATs and recognizing phishing attempts to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_github_new_user_added_to_organization.toml b/rules_building_block/persistence_github_new_user_added_to_organization.toml
index ef599c0edbc..70bec844ae0 100644
--- a/rules_building_block/persistence_github_new_user_added_to_organization.toml
+++ b/rules_building_block/persistence_github_new_user_added_to_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/12/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,48 +33,6 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.add_member"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 New User Added To GitHub Organization
-
-GitHub organizations manage collaborative projects, where adding users is routine for access control. However, adversaries may exploit this by adding unauthorized users to maintain persistence or manipulate accounts. The detection rule monitors GitHub audit logs for specific actions indicating new user additions, aligning with MITRE ATT&CK's account manipulation tactics, to identify potential security breaches.
-
-### Possible investigation steps
-
-- Review the GitHub audit log entry to confirm the `event.action` is "org.add_member" and verify the `event.dataset` is "github.audit" to ensure the alert is valid.
-- Identify the `user.name` and `user.email` fields in the audit log to determine who added the new user to the organization.
-- Check the `target.user` field to identify the new user added to the organization and gather their profile information.
-- Investigate the `organization.name` field to understand which organization the user was added to and assess the potential impact.
-- Review recent activity logs for the `user.name` who added the new member to identify any unusual or unauthorized actions.
-- Use Osquery to query the system for any recent changes in user accounts or permissions. Example query: `SELECT * FROM users WHERE username = '<new_user>' OR username = '<user_who_added>';`
-- Cross-reference the new user's email and username with known employees or contractors to verify their legitimacy.
-- Check for any recent changes in the organization's repositories or settings that might correlate with the new user addition.
-- Investigate any other alerts or incidents involving the same `user.name` or `target.user` to identify patterns or repeated suspicious behavior.
-- Consult with the organization's team leads or project managers to confirm if the new user addition was expected and authorized.
-
-### False positive analysis
-
-- Routine administrative actions: Regularly scheduled additions of new team members or collaborators by authorized personnel can trigger this rule. To manage this, organizations can maintain a list of known administrators whose actions are considered non-threatening and exclude their activities from triggering alerts.
-- Onboarding processes: Large organizations may have automated scripts or workflows that add new users as part of their onboarding process. These can be excluded by identifying and filtering out actions performed by these specific automation accounts.
-- Temporary project collaborations: Short-term projects may require adding external collaborators, which can be mistaken for unauthorized access. Organizations can create exceptions for specific projects or timeframes to prevent false positives.
-- Organizational restructuring: Changes in team structures or mergers may lead to a spike in user additions. Monitoring these events and temporarily adjusting the rule's sensitivity can help manage false positives during such periods.
-
-### Response and remediation
-
-- Verify the legitimacy of the new user addition by contacting the organization owner or admin to confirm if the addition was authorized.
-- Temporarily restrict the new user's access to sensitive repositories and resources until their legitimacy is confirmed.
-- Review the audit logs for any suspicious activities associated with the new user account, such as unusual repository access or changes.
-- If unauthorized access is confirmed, remove the user from the organization and reset credentials for any affected accounts.
-- Escalate the incident to the security team for further investigation and to determine if additional accounts or systems have been compromised.
-- Implement multi-factor authentication (MFA) for all organization members to enhance account security and prevent unauthorized access.
-- Update and enforce strict access control policies, ensuring that only necessary permissions are granted to users based on their roles.
-- Integrate GitHub audit logs with a Security Information and Event Management (SIEM) system for real-time monitoring and alerting of suspicious activities.
-- Conduct a security awareness training session for organization members to recognize and report potential security threats.
-- Regularly review and update the organization's security policies and procedures to align with best practices and emerging threats."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
index 20101b8d9fc..e4a2ed6fd5e 100644
--- a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
+++ b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/11/07"
 
 [rule]
 author = ["Elastic"]
@@ -63,49 +63,6 @@ any where event.dataset == "aws.cloudtrail"
             or startsWith(event.action, "Tag")
     )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 AWS EC2 Instance Interaction with IAM Service
-
-AWS EC2 instances can assume IAM roles to access resources securely, using their instance ID as a session identifier. While this is standard for legitimate operations, attackers may exploit this by assuming roles to manipulate IAM settings, such as creating users or altering permissions. The detection rule identifies unusual role assumptions by EC2 instances, focusing on actions like creating or modifying resources, which may indicate malicious activity.
-
-### Possible investigation steps
-
-- Review the CloudTrail logs to identify the specific EC2 instance involved by examining the `user.id` field for the pattern ":i-" which indicates an assumed role session by an EC2 instance.
-- Check the `event.action` field to determine the specific IAM actions attempted by the EC2 instance, such as "CreateUser" or "AttachRolePolicy", to understand the potential impact.
-- Investigate the `aws.cloudtrail.user_identity.arn` field to identify the assumed role and verify if it aligns with expected roles for the EC2 instance.
-- Analyze the `event.time` field to establish a timeline of events and correlate with other activities in the environment to identify any patterns or anomalies.
-- Use Osquery to gather additional context on the EC2 instance by running a query like `SELECT * FROM ec2_instance_metadata WHERE instance_id = '<instance_id>';` to retrieve metadata about the instance.
-- Cross-reference the `aws.cloudtrail.source_ip_address` field to determine the origin of the request and verify if it matches known IP addresses associated with the EC2 instance.
-- Examine the `aws.cloudtrail.recipient_account_id` field to ensure the actions were performed within the expected AWS account and not across multiple accounts.
-- Check for any recent changes to IAM policies or roles that might have inadvertently allowed the EC2 instance to perform these actions.
-- Review the `aws.cloudtrail.error_code` field for any failed attempts that might indicate probing or unauthorized access attempts.
-- Correlate this event with other security alerts or logs to identify if this activity is part of a larger attack pattern or isolated incident.
-
-### False positive analysis
-
-- EC2 instances that are part of automated workflows or deployment pipelines may frequently assume roles to interact with IAM services for legitimate purposes, such as updating configurations or managing resources. These actions can trigger the rule but are not indicative of malicious activity.
-- Scheduled maintenance tasks or automated scripts that require role assumption to perform routine updates or resource management can also generate false positives. These tasks often involve actions like "Update" or "Create" that match the rule's criteria.
-- Users can manage these false positives by creating exceptions for known EC2 instance IDs or specific IAM roles that are part of regular operations. This can be done by maintaining a list of trusted instance IDs or roles and excluding them from the rule's scope.
-- Another approach is to refine the rule by adding additional context checks, such as verifying the source IP address or the time of the action, to differentiate between expected and unexpected behavior.
-- Regularly reviewing and updating the list of exceptions based on changes in the environment or operational requirements can help minimize false positives while maintaining effective threat detection.
-
-### Response and remediation
-
-- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized actions.
-- Review CloudTrail logs to identify the scope of the activity, focusing on the specific actions taken by the assumed role.
-- Revoke any newly created IAM users or roles and remove any unauthorized permissions or policies that were added.
-- Conduct a thorough investigation to determine how the credentials were compromised, including checking for any other affected resources.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.
-- Implement enhanced logging and monitoring for IAM activities, ensuring that all role assumptions and privilege changes are logged and reviewed regularly.
-- Integrate AWS GuardDuty and AWS Config to provide continuous monitoring and compliance checks for IAM activities.
-- Restore the EC2 instance to its operational state by applying the latest security patches and ensuring that only necessary permissions are granted.
-- Harden the environment by enforcing the principle of least privilege, using IAM policies to restrict access based on roles and responsibilities.
-- Educate users and administrators on security best practices, including the importance of using strong, unique credentials and enabling multi-factor authentication (MFA) for all accounts."""
 
 [rule.investigation_fields]
 field_names = [
diff --git a/rules_building_block/persistence_startup_folder_lnk.toml b/rules_building_block/persistence_startup_folder_lnk.toml
index d2a67877663..0cfb8ff93eb 100644
--- a/rules_building_block/persistence_startup_folder_lnk.toml
+++ b/rules_building_block/persistence_startup_folder_lnk.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -44,50 +44,6 @@ file where host.os.type == "windows" and event.type != "deletion" and file.exten
     (process.name : "APPServerClient.exe" and process.code_signature.status: "trusted" and file.name : "Parallels Client.lnk")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Shortcut File Written or Modified on Startup Folder
-
-In Windows environments, the Startup folder is used to launch programs automatically when a user logs in. Adversaries exploit this by placing or altering shortcut files (.lnk) in this folder to achieve persistence. The detection rule identifies such activities by monitoring for non-deletion events involving .lnk files in the Startup folder, excluding trusted processes, thus highlighting potential unauthorized persistence attempts.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific .lnk file path and name that triggered the alert, focusing on the `file.path` and `file.name` fields.
-- Check the `process.name` field to determine which process was responsible for writing or modifying the shortcut file, and verify if it is a known or trusted application.
-- Investigate the `process.code_signature.status` to confirm whether the process is signed and trusted, which might indicate a false positive if the process is legitimate.
-- Use Osquery to list all .lnk files in the Startup folder to identify any other potentially unauthorized shortcuts:
-  ```sql
-  SELECT path, filename FROM file WHERE path LIKE 'C:\\\\Users\\\\%\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\%' OR path LIKE 'C:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\StartUp\\\\%';
-  ```
-- Examine the file creation and modification timestamps to determine when the shortcut was created or altered, which can provide context on the timing of the suspicious activity.
-- Cross-reference the user account associated with the `file.path` to determine if the activity aligns with the user's normal behavior or if it appears suspicious.
-- Check the system's event logs for any related login or process execution events around the time the shortcut was modified to gather additional context.
-- Investigate the parent process of the process that created or modified the shortcut to understand the origin of the activity and whether it was initiated by a legitimate application or script.
-- Review any recent changes or installations on the system that might explain the presence of the new or modified shortcut, such as software updates or new applications.
-- If applicable, correlate the findings with network activity logs to identify any external connections or data transfers that coincide with the shortcut file modification, which might indicate a broader compromise.
-
-### False positive analysis
-
-- Known false positives for the Shortcut File Written or Modified on Startup Folder rule include legitimate software installations or updates that create or modify shortcut files in the Startup folder. These can include applications like OneNote, Okta Verify, OneLaunch, and Parallels Client, which are often trusted and not indicative of malicious activity.
-- To manage these false positives, users can create exceptions in the detection rule for processes with verified code signatures that are known to create shortcuts in the Startup folder. This can be done by adding specific conditions to exclude these trusted processes and their associated shortcut files, as demonstrated in the existing rule with exceptions for ONENOTE.EXE, OktaVerifySetup.exe, OneLaunch.exe, and APPServerClient.exe.
-- Regularly review and update the list of trusted processes and their associated shortcut files to ensure that new legitimate applications are not flagged as potential threats. This helps maintain the balance between security and usability by reducing unnecessary alerts while still monitoring for unauthorized persistence attempts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or persistence.
-- Investigate the source of the .lnk file creation or modification by reviewing process execution logs and identifying the responsible process.
-- Verify the legitimacy of the process that created or modified the .lnk file by checking its code signature and cross-referencing with known trusted applications.
-- Remove any unauthorized .lnk files from the Startup folder to eliminate persistence mechanisms.
-- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional malicious software.
-- Restore the system to a known good state using backups or system restore points if available and necessary.
-- Implement logging policies to capture detailed file and process activity, focusing on the Startup folder and related processes.
-- Integrate security solutions such as Endpoint Detection and Response (EDR) tools to enhance monitoring and detection capabilities.
-- Escalate the incident to the security operations center (SOC) or incident response team if the threat is part of a larger attack campaign or if further expertise is required.
-- Review and update security policies and user awareness training to prevent similar incidents in the future, emphasizing the risks of unauthorized software installations and persistence mechanisms."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_transport_agent_exchange.toml b/rules_building_block/persistence_transport_agent_exchange.toml
index e1158d13ab7..d4a1efd3be7 100644
--- a/rules_building_block/persistence_transport_agent_exchange.toml
+++ b/rules_building_block/persistence_transport_agent_exchange.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/10/28"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,48 +64,6 @@ event.category: "process" and host.os.type:windows and
     ("scriptCmd.GetSteppablePipeline" and "ForwardHelpTargetName Install-TransportAgent")
   )
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Microsoft Exchange Transport Agent Install Script
-
-Microsoft Exchange Transport Agents are components that process email messages as they move through the transport pipeline. Adversaries may exploit these agents to execute malicious tasks, achieving persistence by installing or enabling rogue agents. The detection rule identifies suspicious use of PowerShell cmdlets related to transport agents, excluding benign activities, to flag potential abuse.
-
-### Possible investigation steps
-
-- Review the alert details to understand which specific PowerShell cmdlet was used, focusing on "Install-TransportAgent" or "Enable-TransportAgent" as indicated in the query.
-- Check the user ID associated with the event to determine if it deviates from the expected system account (S-1-5-18), which could indicate unauthorized activity.
-- Analyze the script block text captured in the alert to identify any unusual or suspicious patterns that might suggest malicious intent.
-- Investigate the process execution context by examining the parent process and any child processes spawned by the PowerShell command to identify potential lateral movement or further exploitation.
-- Use Osquery to gather additional context on the host by running a query to list all installed transport agents: `SELECT name, version, enabled FROM exchange_transport_agents;` to verify if any unauthorized agents are present.
-- Correlate the event with other logs, such as Windows Event Logs, to identify any related activities or anomalies around the same timeframe, such as failed login attempts or unusual network connections.
-- Check for any recent changes in the Exchange server configuration or permissions that could have facilitated the installation or enabling of a rogue transport agent.
-- Review historical data to determine if similar activities have been observed in the past, which could indicate a recurring threat or persistent adversary.
-- Consult threat intelligence sources to see if there are any known campaigns or threat actors that utilize similar techniques involving Microsoft Exchange Transport Agents.
-- Engage with the system owner or administrator to verify if the activity was authorized or part of a legitimate administrative task, ensuring that any benign activities are accounted for.
-
-### False positive analysis
-
-- Routine administrative tasks: Legitimate administrators may use PowerShell cmdlets like "Install-TransportAgent" or "Enable-TransportAgent" during regular maintenance or updates, which can trigger false positives. To manage this, users can create exceptions for known administrative accounts or specific maintenance windows.
-- Monitoring and diagnostic scripts: Some monitoring tools or diagnostic scripts might invoke these cmdlets as part of their operations. Users should identify these tools and exclude their associated processes or script signatures from the detection rule.
-- Automated deployment scripts: Organizations using automated scripts for deploying or configuring Exchange environments might inadvertently trigger the rule. Users can handle this by whitelisting specific script hashes or deployment accounts.
-- Testing environments: In test or development environments, frequent changes and installations might cause false positives. Users can exclude these environments from the rule or adjust the sensitivity of the detection in these contexts.
-
-### Response and remediation
-
-- Immediately isolate the affected Exchange server from the network to prevent further malicious activity and lateral movement.
-- Conduct a thorough investigation to identify any unauthorized transport agents installed on the server by reviewing PowerShell logs and Exchange server logs.
-- Remove any identified malicious transport agents using the Remove-TransportAgent cmdlet and disable any suspicious agents using the Disable-TransportAgent cmdlet.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the compromise.
-- Review and update the PowerShell logging policy to ensure that all script block logging and module logging are enabled for enhanced visibility into future activities.
-- Implement additional security measures such as application whitelisting and endpoint detection and response (EDR) solutions to detect and prevent unauthorized changes to the Exchange server.
-- Restore the Exchange server from a known good backup if necessary, ensuring that all patches and updates are applied to prevent exploitation of known vulnerabilities.
-- Conduct a post-incident review to identify gaps in security controls and processes, and update incident response plans accordingly.
-- Educate and train IT staff and users on recognizing and reporting suspicious activities related to Exchange server operations.
-- Monitor for any signs of persistence or re-infection, and ensure that all security measures are continuously updated and tested."""
 
 
 [[rule.filters]]
diff --git a/rules_building_block/privilege_escalation_trap_execution.toml b/rules_building_block/privilege_escalation_trap_execution.toml
index d182472c531..52787ad90e8 100644
--- a/rules_building_block/privilege_escalation_trap_execution.toml
+++ b/rules_building_block/privilege_escalation_trap_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2024/05/21"
 
 [rule]
 author = ["Elastic"]
@@ -38,48 +38,6 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name == "trap" and process.args : "SIG*"
 '''
-note = """## Triage and analysis
-
-### Disclaimer
-
-This investigation guide was generated 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 Trap Signals Execution
-Trap signals in Unix-like systems allow processes to execute specific commands when receiving interrupt signals, such as SIGINT or SIGTERM. Adversaries exploit this by embedding malicious commands in trap handlers, enabling unauthorized actions upon signal reception. The detection rule identifies such abuse by monitoring process initiation events where the 'trap' command is executed with signal-related arguments, indicating potential misuse.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'trap' command execution with signal-related arguments, focusing on the fields `process.name` and `process.args`.
-- Examine the `event.type` and `event.action` fields to verify that the process initiation aligns with suspicious activity, such as "exec" or "process_started".
-- Identify the parent process of the 'trap' command using process lineage data to understand the context in which the trap was set.
-- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential privilege escalation.
-- Investigate the command history of the user associated with the process to identify any unusual or unauthorized commands executed prior to the trap setup.
-- Use Osquery to gather additional context on the process by running a query such as: `SELECT * FROM processes WHERE name = 'trap';` to retrieve detailed information about the process.
-- Analyze the system logs for any preceding or subsequent signals (e.g., SIGINT, SIGTERM) that may have triggered the trap, indicating potential misuse.
-- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign.
-- Review network activity logs to detect any outbound connections or data exfiltration attempts following the trap execution.
-- Consult threat intelligence sources to determine if similar trap execution techniques have been reported in recent attacks, providing additional context for the investigation.
-
-### False positive analysis
-
-- Routine administrative scripts: System administrators often use trap commands in scripts to handle signals gracefully during maintenance tasks. These scripts may trigger the detection rule but are typically benign.
-- Development and testing environments: Developers might use trap commands to test signal handling in applications, leading to false positives in environments where such activities are common.
-- Backup and cleanup scripts: Automated scripts for backups or cleanup operations may include trap commands to ensure proper termination and resource release, which can be mistaken for malicious activity.
-- To manage these false positives, users can create exceptions for known scripts or processes by whitelisting specific command paths or user accounts associated with legitimate activities.
-- Implementing a baseline of normal behavior for processes using trap commands can help distinguish between expected and suspicious activities, reducing the likelihood of false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized actions and lateral movement.
-- Conduct a thorough investigation to identify the source and scope of the trap signal abuse, focusing on recent changes to trap handlers and associated processes.
-- Review and analyze logs from the affected system to identify any unauthorized commands executed via trap signals, correlating with known MITRE ATT&CK techniques.
-- Remove or disable any malicious trap handlers identified during the investigation to prevent further exploitation.
-- Restore the system to a known good state using backups or system snapshots, ensuring that all malicious modifications are removed.
-- Implement enhanced logging policies to capture detailed process execution events, including command-line arguments and signal handling activities.
-- Integrate threat intelligence feeds and security information and event management (SIEM) systems to improve detection and correlation of similar threats in the future.
-- Conduct a post-incident review to identify gaps in security controls and processes, using insights from the MITRE ATT&CK framework to strengthen defenses against event-triggered execution techniques.
-- Escalate the incident to relevant internal teams and, if necessary, external partners or authorities, providing detailed findings and context for further action.
-- Apply system hardening measures, such as restricting the use of trap commands to trusted users and processes, and regularly updating security patches to mitigate vulnerabilities."""
 
 
 [[rule.threat]]

From c6b823992d205b26c65d27c620c9a9ad3a2ba9fd Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Fri, 10 Jan 2025 21:10:57 -0600
Subject: [PATCH 04/16] regenerate guides

---
 rules/apm/apm_403_response_to_a_post.toml     | 36 +++++++++++++++-
 .../apm_405_response_method_not_allowed.toml  | 36 +++++++++++++++-
 rules/apm/apm_sqlmap_user_agent.toml          | 37 +++++++++++++++-
 ..._google_drive_malicious_file_download.toml | 37 +++++++++++++++-
 ...and_and_control_non_standard_ssh_port.toml | 36 +++++++++++++++-
 ...s_cookies_chromium_browsers_debugging.toml | 37 +++++++++++++++-
 ...al_access_forced_authentication_pipes.toml | 36 +++++++++++++++-
 ..._evasion_agent_spoofing_mismatched_id.toml | 37 +++++++++++++++-
 ...evasion_agent_spoofing_multiple_hosts.toml | 36 +++++++++++++++-
 ...e_evasion_deleting_websvr_access_logs.toml | 36 +++++++++++++++-
 ...deletion_of_bash_command_line_history.toml | 36 +++++++++++++++-
 ...sion_elastic_agent_service_terminated.toml | 37 +++++++++++++++-
 ..._evasion_encoding_rot13_python_script.toml | 36 +++++++++++++++-
 ...ion_masquerading_space_after_filename.toml | 36 +++++++++++++++-
 .../defense_evasion_timestomp_touch.toml      | 35 ++++++++++++++-
 ...y_virtual_machine_fingerprinting_grep.toml | 35 ++++++++++++++-
 ...m_sendcommand_with_command_parameters.toml | 37 +++++++++++++++-
 ...on_pentest_eggshell_remote_admin_tool.toml | 36 +++++++++++++++-
 ...otential_widespread_malware_infection.toml | 37 +++++++++++++++-
 ...tion_suspicious_java_netcon_childproc.toml | 35 ++++++++++++++-
 .../guided_onboarding_sample_rule.toml        | 36 +++++++++++++++-
 ..._access_zoom_meeting_with_no_passcode.toml | 36 +++++++++++++++-
 ...ultiple_alerts_different_tactics_host.toml | 37 +++++++++++++++-
 .../multiple_alerts_involving_user.toml       | 38 +++++++++++++++-
 ...l_access_modify_auth_module_or_config.toml | 37 +++++++++++++++-
 ...ersistence_shell_profile_modification.toml | 37 +++++++++++++++-
 ...ence_ssh_authorized_keys_modification.toml | 38 +++++++++++++++-
 ...lege_escalation_echo_nopasswd_sudoers.toml | 36 +++++++++++++++-
 ...ation_setuid_setgid_bit_set_via_chmod.toml | 36 +++++++++++++++-
 ...ilege_escalation_sudo_buffer_overflow.toml | 37 +++++++++++++++-
 ...privilege_escalation_sudoers_file_mod.toml | 36 +++++++++++++++-
 ...collection_cloudtrail_logging_created.toml | 39 ++++++++++++++++-
 ...cess_aws_getpassword_for_ec2_instance.toml |  4 +-
 ...keyquarantine_policy_attached_to_user.toml | 12 +++---
 ...ieve_secure_string_parameters_via_ssm.toml |  4 +-
 ...cess_root_console_failure_brute_force.toml | 39 ++++++++++++++++-
 ...vasion_configuration_recorder_stopped.toml | 39 ++++++++++++++++-
 ...ense_evasion_ec2_network_acl_deletion.toml | 40 ++++++++++++++++-
 ...n_elasticache_security_group_creation.toml | 40 ++++++++++++++++-
 ...he_security_group_modified_or_deleted.toml | 40 ++++++++++++++++-
 ...e_evasion_guardduty_detector_deletion.toml | 40 ++++++++++++++++-
 ...defense_evasion_rds_instance_restored.toml | 37 +++++++++++++++-
 ...53_dns_query_resolver_config_deletion.toml |  4 +-
 ...sion_s3_bucket_configuration_deletion.toml | 39 ++++++++++++++++-
 ..._s3_bucket_lifecycle_expiration_added.toml |  4 +-
 ...bucket_server_access_logging_disabled.toml | 10 ++---
 ...ense_evasion_sts_get_federation_token.toml | 35 ++++++++++++++-
 ...ess_rule_added_for_remote_connections.toml |  4 +-
 .../aws/defense_evasion_waf_acl_deletion.toml | 39 ++++++++++++++++-
 ...asion_waf_rule_or_rule_group_deletion.toml | 40 ++++++++++++++++-
 ...y_ec2_multi_region_describe_instances.toml |  4 +-
 ..._multiple_discovery_api_calls_via_cli.toml |  4 +-
 ...s_multi_region_service_quota_requests.toml | 36 +++++++++++++++-
 ...mbda_external_layer_added_to_function.toml |  4 +-
 ..._new_terms_cloudformation_createstack.toml | 37 +++++++++++++++-
 ...command_document_created_by_rare_user.toml |  4 +-
 ...xecution_ssm_sendcommand_by_rare_user.toml |  4 +-
 ..._ec2_ami_shared_with_separate_account.toml |  4 +-
 ..._snapshot_shared_with_another_account.toml |  4 +-
 ..._full_network_packet_capture_detected.toml | 40 ++++++++++++++++-
 .../exfiltration_ec2_vm_export_failure.toml   | 38 +++++++++++++++-
 .../aws/exfiltration_rds_snapshot_export.toml | 39 ++++++++++++++++-
 ..._snapshot_shared_with_another_account.toml |  6 +--
 ...icy_added_for_external_account_access.toml |  4 +-
 ...bucket_replicated_to_external_account.toml |  8 ++--
 ...n_sns_email_subscription_by_rare_user.toml |  4 +-
 ..._eventbridge_rule_disabled_or_deleted.toml | 40 ++++++++++++++++-
 .../impact_ec2_disable_ebs_encryption.toml    | 39 ++++++++++++++++-
 ...mpact_efs_filesystem_or_mount_deleted.toml | 40 ++++++++++++++++-
 .../aws/impact_iam_group_deletion.toml        | 39 ++++++++++++++++-
 ...mk_disabled_or_scheduled_for_deletion.toml | 40 ++++++++++++++++-
 .../aws/impact_rds_group_deletion.toml        | 38 +++++++++++++++-
 .../impact_rds_instance_cluster_deletion.toml | 39 ++++++++++++++++-
 ..._cluster_deletion_protection_disabled.toml |  6 +--
 .../impact_rds_instance_cluster_stoppage.toml | 40 ++++++++++++++++-
 .../aws/impact_rds_snapshot_deleted.toml      | 36 +++++++++++++++-
 ...object_uploaded_with_ransom_extension.toml |  4 +-
 ...3_object_encryption_with_external_key.toml |  4 +-
 .../impact_s3_object_versioning_disabled.toml | 10 ++---
 .../aws/initial_access_password_recovery.toml | 39 ++++++++++++++++-
 ...al_access_signin_console_login_no_mfa.toml | 37 +++++++++++++++-
 ...aws_ssm_start_session_to_ec2_instance.toml |  4 +-
 ...l_movement_ec2_instance_console_login.toml | 38 +++++++++++++++-
 .../persistence_ec2_network_acl_creation.toml | 40 ++++++++++++++++-
 ..._group_configuration_change_detection.toml | 39 ++++++++++++++++-
 ...nce_iam_create_login_profile_for_root.toml | 38 +++++++++++++++-
 ...user_via_assumed_role_on_ec2_instance.toml |  4 +-
 .../aws/persistence_iam_group_creation.toml   | 40 ++++++++++++++++-
 ...ce_iam_roles_anywhere_profile_created.toml |  4 +-
 ...usted_anchor_created_with_external_ca.toml |  4 +-
 ...oor_invoke_function_for_any_principal.toml |  4 +-
 .../aws/persistence_rds_cluster_creation.toml | 40 ++++++++++++++++-
 ...nce_rds_db_instance_password_modified.toml |  6 +--
 .../aws/persistence_rds_group_creation.toml   | 39 ++++++++++++++++-
 .../persistence_rds_instance_creation.toml    | 40 ++++++++++++++++-
 .../persistence_rds_instance_made_public.toml |  8 ++--
 ...ersistence_redshift_instance_creation.toml | 39 ++++++++++++++++-
 ...oute_53_domain_transfer_lock_disabled.toml | 39 ++++++++++++++++-
 ...domain_transferred_to_another_account.toml | 39 ++++++++++++++++-
 ..._53_hosted_zone_associated_with_a_vpc.toml | 38 +++++++++++++++-
 .../aws/persistence_route_table_created.toml  | 40 ++++++++++++++++-
 ...tence_route_table_modified_or_deleted.toml | 40 ++++++++++++++++-
 ...sistence_sts_assume_role_with_new_mfa.toml | 40 ++++++++++++++++-
 ...tance_connect_ssh_public_key_uploaded.toml |  4 +-
 ...tomer_managed_policy_attached_to_role.toml |  4 +-
 ..._escalation_iam_saml_provider_updated.toml | 39 ++++++++++++++++-
 ...escalation_role_assumption_by_service.toml |  4 +-
 ...ge_escalation_role_assumption_by_user.toml |  4 +-
 ...oot_from_rare_user_and_member_account.toml |  4 +-
 ..._escalation_sts_getsessiontoken_abuse.toml | 39 ++++++++++++++++-
 ...rivilege_escalation_sts_role_chaining.toml | 40 ++++++++++++++++-
 ...collection_update_event_hub_auth_rule.toml | 39 ++++++++++++++++-
 ...azure_entra_totp_brute_force_attempts.toml |  4 +-
 ..._full_network_packet_capture_detected.toml | 39 ++++++++++++++++-
 ...d_device_code_auth_with_broker_client.toml | 37 +++++++++++++++-
 ...ntra_signin_brute_force_microsoft_365.toml | 40 ++++++++++++++++-
 ...ute_force_microsoft_365_repeat_source.toml | 40 ++++++++++++++++-
 ...cess_first_time_seen_device_code_auth.toml | 36 +++++++++++++++-
 .../credential_access_key_vault_modified.toml | 39 ++++++++++++++++-
 ...ccess_storage_account_key_regenerated.toml | 39 ++++++++++++++++-
 ...e_application_credential_modification.toml | 40 ++++++++++++++++-
 ...sion_azure_automation_runbook_deleted.toml | 39 ++++++++++++++++-
 ...asion_azure_blob_permissions_modified.toml | 39 ++++++++++++++++-
 ...on_azure_diagnostic_settings_deletion.toml | 40 ++++++++++++++++-
 .../defense_evasion_event_hub_deletion.toml   | 40 ++++++++++++++++-
 ...ense_evasion_firewall_policy_deletion.toml | 40 ++++++++++++++++-
 ...on_frontdoor_firewall_policy_deletion.toml | 39 ++++++++++++++++-
 ...nse_evasion_kubernetes_events_deleted.toml | 40 ++++++++++++++++-
 ...ense_evasion_network_watcher_deletion.toml | 38 +++++++++++++++-
 ...ense_evasion_suppression_rule_created.toml | 40 ++++++++++++++++-
 .../discovery_blob_container_access_mod.toml  | 39 ++++++++++++++++-
 .../execution_command_virtual_machine.toml    | 40 ++++++++++++++++-
 ...e_service_principal_credentials_added.toml | 40 ++++++++++++++++-
 .../azure/impact_kubernetes_pod_deleted.toml  | 39 ++++++++++++++++-
 .../azure/impact_resource_group_deletion.toml | 40 ++++++++++++++++-
 ...mpact_virtual_network_device_modified.toml | 40 ++++++++++++++++-
 ...ial_access_external_guest_user_invite.toml | 40 ++++++++++++++++-
 ...ence_azure_automation_account_created.toml | 38 +++++++++++++++-
 ...utomation_runbook_created_or_modified.toml | 40 ++++++++++++++++-
 ...ence_azure_automation_webhook_created.toml | 39 ++++++++++++++++-
 ...re_conditional_access_policy_modified.toml | 39 ++++++++++++++++-
 ...re_global_administrator_role_assigned.toml | 39 ++++++++++++++++-
 ...nce_azure_pim_user_added_global_admin.toml | 40 ++++++++++++++++-
 ..._added_as_owner_for_azure_application.toml | 39 ++++++++++++++++-
 ..._as_owner_for_azure_service_principal.toml | 39 ++++++++++++++++-
 ..._azure_kubernetes_rolebinding_created.toml | 39 ++++++++++++++++-
 .../command_and_control_beaconing.toml        | 37 +++++++++++++++-
 ...and_control_beaconing_high_confidence.toml | 38 +++++++++++++++-
 .../container_workload_protection.toml        | 37 +++++++++++++++-
 ...s_aws_creds_search_inside_a_container.toml | 36 +++++++++++++++-
 ..._files_compression_inside_a_container.toml | 37 +++++++++++++++-
 ...r_passwords_search_inside_a_container.toml | 37 +++++++++++++++-
 ...ed_object_modified_inside_a_container.toml | 37 +++++++++++++++-
 ...work_tool_launched_inside_a_container.toml | 36 +++++++++++++++-
 ...nt_binary_launched_inside_a_container.toml | 37 +++++++++++++++-
 ...ecutable_via_chmod_inside_a_container.toml | 37 +++++++++++++++-
 ...ecution_interactive_exec_to_container.toml | 38 +++++++++++++++-
 ...shell_spawned_from_inside_a_container.toml | 36 +++++++++++++++-
 ...stener_established_inside_a_container.toml | 36 +++++++++++++++-
 ...ection_established_inside_a_container.toml | 37 +++++++++++++++-
 ...h_process_launched_inside_a_container.toml | 37 +++++++++++++++-
 ..._keys_modification_inside_a_container.toml | 37 +++++++++++++++-
 ...aunched_inside_a_privileged_container.toml | 36 +++++++++++++++-
 ...aunched_inside_a_privileged_container.toml | 37 +++++++++++++++-
 ...e_via_modified_notify_on_release_file.toml | 37 +++++++++++++++-
 ...scape_via_modified_release_agent_file.toml | 37 +++++++++++++++-
 ...ytes_destination_geo_country_iso_code.toml | 37 +++++++++++++++-
 ...ltration_ml_high_bytes_destination_ip.toml | 36 +++++++++++++++-
 ...ration_ml_high_bytes_destination_port.toml | 37 +++++++++++++++-
 ...ml_high_bytes_destination_region_name.toml | 37 +++++++++++++++-
 ...high_bytes_written_to_external_device.toml | 37 +++++++++++++++-
 ...es_written_to_external_device_airdrop.toml | 37 +++++++++++++++-
 ...re_process_writing_to_external_device.toml | 37 +++++++++++++++-
 ...ml_dga_activity_using_sunburst_domain.toml | 37 +++++++++++++++-
 ...d_control_ml_dga_high_sum_probability.toml | 35 ++++++++++++++-
 ...l_ml_dns_request_high_dga_probability.toml | 36 +++++++++++++++-
 ..._request_predicted_to_be_a_dga_domain.toml | 37 +++++++++++++++-
 .../endpoint/elastic_endpoint_security.toml   | 37 +++++++++++++++-
 ...istence_suspicious_file_modifications.toml | 37 +++++++++++++++-
 ...ion_gcp_pub_sub_subscription_creation.toml | 38 +++++++++++++++-
 ...collection_gcp_pub_sub_topic_creation.toml | 41 +++++++++++++++++-
 ...nse_evasion_gcp_firewall_rule_created.toml | 41 +++++++++++++++++-
 ...nse_evasion_gcp_firewall_rule_deleted.toml | 39 ++++++++++++++++-
 ...se_evasion_gcp_firewall_rule_modified.toml | 41 +++++++++++++++++-
 ...e_evasion_gcp_logging_bucket_deletion.toml | 39 ++++++++++++++++-
 ...nse_evasion_gcp_logging_sink_deletion.toml | 38 +++++++++++++++-
 ...ion_gcp_pub_sub_subscription_deletion.toml | 39 ++++++++++++++++-
 ...se_evasion_gcp_pub_sub_topic_deletion.toml | 40 ++++++++++++++++-
 ...storage_bucket_configuration_modified.toml | 41 +++++++++++++++++-
 ...p_storage_bucket_permissions_modified.toml | 40 ++++++++++++++++-
 ...virtual_private_cloud_network_deleted.toml | 39 ++++++++++++++++-
 ...p_virtual_private_cloud_route_created.toml | 40 ++++++++++++++++-
 ...p_virtual_private_cloud_route_deleted.toml | 40 ++++++++++++++++-
 ...tration_gcp_logging_sink_modification.toml | 41 +++++++++++++++++-
 .../gcp/impact_gcp_iam_role_deletion.toml     | 40 ++++++++++++++++-
 .../impact_gcp_service_account_deleted.toml   | 39 ++++++++++++++++-
 .../impact_gcp_service_account_disabled.toml  | 39 ++++++++++++++++-
 .../impact_gcp_storage_bucket_deleted.toml    | 39 ++++++++++++++++-
 ...l_access_gcp_iam_custom_role_creation.toml | 39 ++++++++++++++++-
 ..._gcp_iam_service_account_key_deletion.toml | 39 ++++++++++++++++-
 ...e_gcp_key_created_for_service_account.toml | 39 ++++++++++++++++-
 ...rsistence_gcp_service_account_created.toml | 38 +++++++++++++++-
 ...hub_protected_branch_settings_changed.toml | 36 +++++++++++++++-
 .../github/execution_github_app_deleted.toml  | 37 +++++++++++++++-
 ..._high_number_of_cloned_repos_from_pat.toml | 36 +++++++++++++++-
 ...multiple_behavior_alerts_from_account.toml | 37 +++++++++++++++-
 .../execution_new_github_app_installed.toml   | 36 +++++++++++++++-
 .../impact_github_repository_deleted.toml     | 35 ++++++++++++++-
 .../persistence_github_org_owner_added.toml   | 37 +++++++++++++++-
 ...tence_organization_owner_role_granted.toml | 35 ++++++++++++++-
 ...yption_key_accessed_by_anonymous_user.toml | 40 ++++++++++++++++-
 ...th_login_from_third_party_application.toml | 39 ++++++++++++++++-
 ...ogle_workspace_suspended_user_renewed.toml | 37 +++++++++++++++-
 ...covery_denied_service_account_request.toml | 40 ++++++++++++++++-
 ...covery_suspicious_self_subject_review.toml | 39 ++++++++++++++++-
 .../execution_user_exec_to_pod.toml           | 39 ++++++++++++++++-
 ...l_access_anonymous_request_authorized.toml | 39 ++++++++++++++++-
 ...ed_service_created_with_type_nodeport.toml | 40 ++++++++++++++++-
 ...e_escalation_pod_created_with_hostipc.toml | 40 ++++++++++++++++-
 ...calation_pod_created_with_hostnetwork.toml | 38 +++++++++++++++-
 ...e_escalation_pod_created_with_hostpid.toml | 40 ++++++++++++++++-
 ...reated_with_sensitive_hostpath_volume.toml | 40 ++++++++++++++++-
 ...ege_escalation_privileged_pod_created.toml | 38 +++++++++++++++-
 ...ignment_of_controller_service_account.toml | 40 ++++++++++++++++-
 ...ovement_ml_high_mean_rdp_process_args.toml | 36 +++++++++++++++-
 ...ent_ml_high_mean_rdp_session_duration.toml | 37 +++++++++++++++-
 ...ral_movement_ml_high_remote_file_size.toml | 36 +++++++++++++++-
 ...ml_high_variance_rdp_session_duration.toml | 37 +++++++++++++++-
 ...ovement_ml_rare_remote_file_directory.toml | 37 +++++++++++++++-
 ...ovement_ml_rare_remote_file_extension.toml | 37 +++++++++++++++-
 ...spike_in_connections_from_a_source_ip.toml | 37 +++++++++++++++-
 ...ke_in_connections_to_a_destination_ip.toml | 36 +++++++++++++++-
 ...al_movement_ml_spike_in_rdp_processes.toml | 36 +++++++++++++++-
 ...ent_ml_spike_in_remote_file_transfers.toml | 37 +++++++++++++++-
 ...nt_ml_unusual_time_for_an_rdp_session.toml | 37 +++++++++++++++-
 ...llection_microsoft_365_new_inbox_rule.toml | 40 ++++++++++++++++-
 ..._365_brute_force_user_account_attempt.toml | 37 +++++++++++++++-
 ...65_potential_password_spraying_attack.toml | 38 +++++++++++++++-
 ...ccess_user_excessive_sso_logon_errors.toml | 40 ++++++++++++++++-
 ...osoft_365_exchange_dlp_policy_removed.toml | 39 ++++++++++++++++-
 ...change_malware_filter_policy_deletion.toml | 40 ++++++++++++++++-
 ..._365_exchange_malware_filter_rule_mod.toml | 39 ++++++++++++++++-
 ...65_exchange_safe_attach_rule_disabled.toml | 39 ++++++++++++++++-
 ...oft_365_mailboxauditbypassassociation.toml | 40 ++++++++++++++++-
 ..._365_exchange_transport_rule_creation.toml | 39 ++++++++++++++++-
 ...osoft_365_exchange_transport_rule_mod.toml | 39 ++++++++++++++++-
 ...ft_365_mass_download_by_a_single_user.toml | 39 ++++++++++++++++-
 ...oft_365_potential_ransomware_activity.toml | 41 +++++++++++++++++-
 ...t_365_unusual_volume_of_file_deletion.toml | 40 ++++++++++++++++-
 ...5_exchange_anti_phish_policy_deletion.toml | 40 ++++++++++++++++-
 ...soft_365_exchange_anti_phish_rule_mod.toml | 40 ++++++++++++++++-
 ...osoft_365_exchange_safelinks_disabled.toml | 39 ++++++++++++++++-
 ...rosoft_365_impossible_travel_activity.toml | 40 ++++++++++++++++-
 ...t_365_impossible_travel_portal_logins.toml | 37 +++++++++++++++-
 ...t_365_portal_login_from_rare_location.toml | 38 +++++++++++++++-
 ...65_user_restricted_from_sending_email.toml | 39 ++++++++++++++++-
 ...cess_o365_user_reported_phish_malware.toml | 40 ++++++++++++++++-
 ...al_movement_malware_uploaded_onedrive.toml | 41 +++++++++++++++++-
 ..._movement_malware_uploaded_sharepoint.toml | 40 ++++++++++++++++-
 ...e_suspicious_mailbox_right_delegation.toml | 39 ++++++++++++++++-
 ...exchange_dkim_signing_config_disabled.toml | 39 ++++++++++++++++-
 ...5_exchange_management_role_assignment.toml | 40 ++++++++++++++++-
 ..._365_global_administrator_role_assign.toml | 40 ++++++++++++++++-
 ..._teams_custom_app_interaction_allowed.toml | 41 +++++++++++++++++-
 ...oft_365_teams_external_access_enabled.toml | 40 ++++++++++++++++-
 ...rosoft_365_teams_guest_access_enabled.toml | 39 ++++++++++++++++-
 ...ion_new_or_modified_federation_domain.toml | 40 ++++++++++++++++-
 ..._app_client_credential_token_exchange.toml | 36 +++++++++++++++-
 ...ta_attempt_to_delete_okta_application.toml | 39 ++++++++++++++++-
 ...ta_attempt_to_modify_okta_application.toml | 39 ++++++++++++++++-
 .../okta/impact_possible_okta_dos_attack.toml | 39 ++++++++++++++++-
 ...initial_access_okta_fastpass_phishing.toml | 39 ++++++++++++++++-
 ...ta_user_attempted_unauthorized_access.toml | 40 ++++++++++++++++-
 ...cation_sso_from_unknown_client_device.toml | 37 +++++++++++++++-
 ...icious_activity_reported_by_okta_user.toml | 40 ++++++++++++++++-
 ...ent_multiple_sessions_for_single_user.toml | 40 ++++++++++++++++-
 ...tor_privileges_assigned_to_okta_group.toml | 39 ++++++++++++++++-
 ...inistrator_role_assigned_to_okta_user.toml | 39 ++++++++++++++++-
 ...ence_attempt_to_create_okta_api_token.toml | 39 ++++++++++++++++-
 ...set_mfa_factors_for_okta_user_account.toml | 39 ++++++++++++++++-
 ..._or_delete_application_sign_on_policy.toml | 40 ++++++++++++++++-
 ...se_evasion_ml_rare_process_for_a_host.toml | 36 +++++++++++++++-
 ..._ml_rare_process_for_a_parent_process.toml | 38 +++++++++++++++-
 ...se_evasion_ml_rare_process_for_a_user.toml | 37 +++++++++++++++-
 ...icious_windows_event_high_probability.toml | 37 +++++++++++++++-
 ...picious_windows_event_low_probability.toml | 37 +++++++++++++++-
 ...ous_windows_process_cluster_from_host.toml | 37 +++++++++++++++-
 ...s_process_cluster_from_parent_process.toml | 37 +++++++++++++++-
 ...ous_windows_process_cluster_from_user.toml | 37 +++++++++++++++-
 .../collection_linux_clipboard_activity.toml  | 37 +++++++++++++++-
 ...and_control_aws_cli_endpoint_url_used.toml | 36 +++++++++++++++-
 ...and_control_curl_socks_proxy_detected.toml | 37 +++++++++++++++-
 ...nd_and_control_ip_forwarding_activity.toml | 37 +++++++++++++++-
 ...mand_and_control_linux_kworker_netcon.toml | 36 +++++++++++++++-
 ...ial_access_collection_sensitive_files.toml | 36 +++++++++++++++-
 .../credential_access_credential_dumping.toml | 36 +++++++++++++++-
 ...ntial_access_gdb_init_process_hooking.toml | 36 +++++++++++++++-
 ...credential_access_gdb_process_hooking.toml | 37 +++++++++++++++-
 ...ential_linux_local_account_bruteforce.toml | 35 ++++++++++++++-
 ...ntial_successful_linux_ftp_bruteforce.toml | 35 ++++++++++++++-
 ...ntial_successful_linux_rdp_bruteforce.toml | 36 +++++++++++++++-
 ...ential_access_proc_credential_dumping.toml | 38 +++++++++++++++-
 .../credential_access_ssh_backdoor_log.toml   | 37 +++++++++++++++-
 ...instance_metadata_service_api_request.toml | 36 +++++++++++++++-
 ..._evasion_acl_modification_via_setfacl.toml | 35 ++++++++++++++-
 ...ion_attempt_to_disable_auditd_service.toml | 35 ++++++++++++++-
 ...tempt_to_disable_iptables_or_firewall.toml | 37 +++++++++++++++-
 ...ion_attempt_to_disable_syslog_service.toml | 36 +++++++++++++++-
 ..._base32_encoding_or_decoding_activity.toml | 37 +++++++++++++++-
 ...binary_copied_to_suspicious_directory.toml | 36 +++++++++++++++-
 ...defense_evasion_chattr_immutable_file.toml | 36 +++++++++++++++-
 ...ense_evasion_clear_kernel_ring_buffer.toml | 35 ++++++++++++++-
 ..._creation_of_hidden_files_directories.toml | 37 +++++++++++++++-
 ...nse_evasion_directory_creation_in_bin.toml | 36 +++++++++++++++-
 ...ense_evasion_disable_apparmor_attempt.toml | 37 +++++++++++++++-
 ...fense_evasion_disable_selinux_attempt.toml | 36 +++++++++++++++-
 ...doas_configuration_creation_or_rename.toml | 36 +++++++++++++++-
 ..._evasion_dynamic_linker_file_creation.toml | 36 +++++++++++++++-
 ...asion_esxi_suspicious_timestomp_touch.toml | 37 +++++++++++++++-
 ...fense_evasion_file_deletion_via_shred.toml | 36 +++++++++++++++-
 ...defense_evasion_file_mod_writable_dir.toml | 36 +++++++++++++++-
 ...defense_evasion_hex_payload_execution.toml | 37 +++++++++++++++-
 ...nse_evasion_hidden_directory_creation.toml | 37 +++++++++++++++-
 .../defense_evasion_hidden_file_dir_tmp.toml  | 37 +++++++++++++++-
 .../defense_evasion_hidden_shared_object.toml | 36 +++++++++++++++-
 ...on_interactive_shell_from_system_user.toml | 38 +++++++++++++++-
 ...defense_evasion_kernel_module_removal.toml | 37 +++++++++++++++-
 ...defense_evasion_kthreadd_masquerading.toml | 36 +++++++++++++++-
 .../linux/defense_evasion_ld_so_creation.toml | 38 +++++++++++++++-
 .../defense_evasion_log_files_deleted.toml    | 37 +++++++++++++++-
 .../defense_evasion_mount_execution.toml      | 37 +++++++++++++++-
 ...ense_evasion_potential_proot_exploits.toml | 35 ++++++++++++++-
 .../defense_evasion_rename_esxi_files.toml    | 37 +++++++++++++++-
 ...efense_evasion_rename_esxi_index_file.toml | 37 +++++++++++++++-
 ...evasion_root_certificate_installation.toml | 37 +++++++++++++++-
 ...ux_configuration_creation_or_renaming.toml | 38 +++++++++++++++-
 ...ense_evasion_ssl_certificate_deletion.toml | 36 +++++++++++++++-
 ...s_utility_executed_via_tmux_or_screen.toml | 36 +++++++++++++++-
 ...ense_evasion_unusual_preload_env_vars.toml | 37 +++++++++++++++-
 .../discovery_dynamic_linker_via_od.toml      | 35 ++++++++++++++-
 .../discovery_esxi_software_via_find.toml     | 36 +++++++++++++++-
 .../discovery_esxi_software_via_grep.toml     | 35 ++++++++++++++-
 .../discovery_kernel_module_enumeration.toml  | 36 +++++++++++++++-
 .../linux/discovery_linux_hping_activity.toml | 37 +++++++++++++++-
 .../linux/discovery_linux_nping_activity.toml | 37 +++++++++++++++-
 .../discovery_pam_version_discovery.toml      | 36 +++++++++++++++-
 .../linux/discovery_ping_sweep_detected.toml  | 37 +++++++++++++++-
 ...ivate_key_password_searching_activity.toml | 36 +++++++++++++++-
 rules/linux/discovery_proc_maps_read.toml     | 36 +++++++++++++++-
 .../linux/discovery_process_capabilities.toml | 36 +++++++++++++++-
 ...very_pspy_process_monitoring_detected.toml | 37 +++++++++++++++-
 ...curity_file_access_via_common_utility.toml | 37 +++++++++++++++-
 ...very_sudo_allowed_command_enumeration.toml | 35 ++++++++++++++-
 .../discovery_suid_sguid_enumeration.toml     | 35 ++++++++++++++-
 ...overy_suspicious_memory_grep_activity.toml | 37 +++++++++++++++-
 ...ry_suspicious_which_command_execution.toml | 36 +++++++++++++++-
 ...overy_unusual_user_enumeration_via_id.toml | 36 +++++++++++++++-
 ...covery_virtual_machine_fingerprinting.toml | 37 +++++++++++++++-
 .../discovery_yum_dnf_plugin_detection.toml   | 35 ++++++++++++++-
 ...ion_curl_cve_2023_38545_heap_overflow.toml | 35 ++++++++++++++-
 ...nnection_from_entrypoint_in_container.toml | 36 +++++++++++++++-
 ...n_file_execution_followed_by_deletion.toml | 37 +++++++++++++++-
 .../execution_interpreter_tty_upgrade.toml    | 35 ++++++++++++++-
 .../execution_nc_listener_via_rlwrap.toml     | 36 +++++++++++++++-
 ...ion_netcon_from_rwx_mem_region_binary.toml | 37 +++++++++++++++-
 ...cution_network_event_post_compilation.toml | 37 +++++++++++++++-
 rules/linux/execution_perl_tty_shell.toml     | 36 +++++++++++++++-
 ...xecution_potential_hack_tool_executed.toml | 37 +++++++++++++++-
 ..._overly_permissive_container_creation.toml | 43 ++++++++++++++++++-
 ...ss_started_in_shared_memory_directory.toml | 38 +++++++++++++++-
 rules/linux/execution_python_tty_shell.toml   | 36 +++++++++++++++-
 .../execution_python_webserver_spawned.toml   | 37 +++++++++++++++-
 ..._remote_code_execution_via_postgresql.toml | 36 +++++++++++++++-
 ...cution_shell_openssl_client_or_server.toml | 36 +++++++++++++++-
 ...xecution_shell_via_background_process.toml | 37 +++++++++++++++-
 ...ion_shell_via_child_tcp_utility_linux.toml | 37 +++++++++++++++-
 ...ecution_shell_via_java_revshell_linux.toml | 35 ++++++++++++++-
 ...on_shell_via_lolbin_interpreter_linux.toml | 37 +++++++++++++++-
 ...execution_shell_via_meterpreter_linux.toml | 36 +++++++++++++++-
 ...execution_shell_via_suspicious_binary.toml | 37 +++++++++++++++-
 ...ution_shell_via_tcp_cli_utility_linux.toml | 37 +++++++++++++++-
 ...ution_shell_via_udp_cli_utility_linux.toml | 37 +++++++++++++++-
 ...traction_or_decrompression_via_funzip.toml | 36 +++++++++++++++-
 ...us_executable_running_system_commands.toml | 37 +++++++++++++++-
 ...icious_mining_process_creation_events.toml | 36 +++++++++++++++-
 rules/linux/execution_tc_bpf_filter.toml      | 36 +++++++++++++++-
 .../execution_unix_socket_communication.toml  | 37 +++++++++++++++-
 ...nknown_rwx_mem_region_binary_executed.toml | 37 +++++++++++++++-
 ...ntial_data_splitting_for_exfiltration.toml | 37 +++++++++++++++-
 .../impact_data_encrypted_via_openssl.toml    | 36 +++++++++++++++-
 rules/linux/impact_esxi_process_kill.toml     | 36 +++++++++++++++-
 .../impact_memory_swap_modification.toml      | 37 +++++++++++++++-
 ...ential_linux_ransomware_note_detected.toml | 38 +++++++++++++++-
 ...lateral_movement_ssh_it_worm_download.toml | 36 +++++++++++++++-
 ...ment_telnet_network_activity_external.toml | 36 +++++++++++++++-
 ...ment_telnet_network_activity_internal.toml | 37 +++++++++++++++-
 ...istence_apt_package_manager_execution.toml | 37 +++++++++++++++-
 ...nce_apt_package_manager_file_creation.toml | 37 +++++++++++++++-
 ...ersistence_apt_package_manager_netcon.toml | 37 +++++++++++++++-
 rules/linux/persistence_at_job_creation.toml  | 37 +++++++++++++++-
 ..._package_manager_plugin_file_creation.toml | 38 +++++++++++++++-
 ...kage_installation_from_unusual_parent.toml | 37 +++++++++++++++-
 .../persistence_dpkg_unusual_execution.toml   | 35 ++++++++++++++-
 .../linux/persistence_git_hook_execution.toml | 37 +++++++++++++++-
 .../persistence_git_hook_file_creation.toml   | 37 +++++++++++++++-
 rules/linux/persistence_git_hook_netcon.toml  | 38 +++++++++++++++-
 ...ersistence_git_hook_process_execution.toml | 37 +++++++++++++++-
 .../linux/persistence_kernel_driver_load.toml | 37 +++++++++++++++-
 ...stence_kernel_driver_load_by_non_root.toml | 37 +++++++++++++++-
 ...rsistence_kernel_object_file_creation.toml | 37 +++++++++++++++-
 ...tence_lkm_configuration_file_creation.toml | 38 +++++++++++++++-
 ...ggable_authentication_module_creation.toml | 37 +++++++++++++++-
 ...cation_module_creation_in_unusual_dir.toml | 37 +++++++++++++++-
 ...authentication_module_source_download.toml | 36 +++++++++++++++-
 ...persistence_script_executable_bit_set.toml | 36 +++++++++++++++-
 ...nce_process_capability_set_via_setcap.toml | 35 ++++++++++++++-
 ...persistence_rc_local_error_via_syslog.toml | 35 ++++++++++++++-
 ...ence_rc_local_service_already_running.toml | 35 ++++++++++++++-
 ...kage_installation_from_unusual_parent.toml | 36 +++++++++++++++-
 .../persistence_shadow_file_modification.toml | 36 +++++++++++++++-
 ...ence_shell_configuration_modification.toml | 37 +++++++++++++++-
 ...simple_web_server_connection_accepted.toml | 37 +++++++++++++++-
 ...ersistence_simple_web_server_creation.toml | 37 +++++++++++++++-
 .../linux/persistence_ssh_key_generation.toml | 37 +++++++++++++++-
 rules/linux/persistence_ssh_netcon.toml       | 35 ++++++++++++++-
 ...stence_ssh_via_backdoored_system_user.toml | 37 +++++++++++++++-
 ...suspicious_file_opened_through_editor.toml | 37 +++++++++++++++-
 ...e_suspicious_ssh_execution_xzbackdoor.toml | 36 +++++++++++++++-
 ...ersistence_systemd_generator_creation.toml | 36 +++++++++++++++-
 rules/linux/persistence_systemd_netcon.toml   | 37 +++++++++++++++-
 ...ersistence_tainted_kernel_module_load.toml | 36 +++++++++++++++-
 ...ainted_kernel_module_out_of_tree_load.toml | 37 +++++++++++++++-
 .../linux/persistence_udev_rule_creation.toml | 38 +++++++++++++++-
 .../persistence_unusual_pam_grantor.toml      | 36 +++++++++++++++-
 ...ersistence_unusual_sshd_child_process.toml | 35 ++++++++++++++-
 ...ser_or_group_creation_or_modification.toml | 36 +++++++++++++++-
 .../persistence_xdg_autostart_netcon.toml     | 36 +++++++++++++++-
 ..._package_manager_plugin_file_creation.toml | 37 +++++++++++++++-
 ...on_chown_chmod_unauthorized_file_read.toml | 36 +++++++++++++++-
 ...ation_container_util_misconfiguration.toml | 35 ++++++++++++++-
 .../privilege_escalation_dac_permissions.toml | 37 +++++++++++++++-
 ..._escalation_docker_escape_via_nsenter.toml | 37 +++++++++++++++-
 ..._docker_mount_chroot_container_escape.toml | 37 +++++++++++++++-
 ...calation_enlightenment_window_manager.toml | 37 +++++++++++++++-
 ...e_escalation_gdb_sys_ptrace_elevation.toml | 37 +++++++++++++++-
 ...lege_escalation_gdb_sys_ptrace_netcon.toml | 37 +++++++++++++++-
 ...lege_escalation_kworker_uid_elevation.toml | 35 ++++++++++++++-
 ...lation_ld_preload_shared_object_modif.toml | 37 +++++++++++++++-
 ...lation_linux_suspicious_symbolic_link.toml | 37 +++++++++++++++-
 ...lege_escalation_linux_uid_int_max_bug.toml | 36 +++++++++++++++-
 ...n_load_and_unload_of_kernel_via_kexec.toml | 37 +++++++++++++++-
 ...alation_looney_tunables_cve_2023_4911.toml | 37 +++++++++++++++-
 ...ege_escalation_netcon_via_sudo_binary.toml | 35 ++++++++++++++-
 ...ge_escalation_overlayfs_local_privesc.toml | 37 +++++++++++++++-
 ...vilege_escalation_pkexec_envar_hijack.toml | 37 +++++++++++++++-
 ...ation_potential_bufferoverflow_attack.toml | 38 +++++++++++++++-
 ...tion_potential_suid_sgid_exploitation.toml | 37 +++++++++++++++-
 ...lation_potential_wildcard_shell_spawn.toml | 37 +++++++++++++++-
 ...ge_escalation_sda_disk_mount_non_root.toml | 36 +++++++++++++++-
 ...privilege_escalation_shadow_file_read.toml | 36 +++++++++++++++-
 ...vilege_escalation_sudo_cve_2019_14287.toml | 37 +++++++++++++++-
 .../privilege_escalation_sudo_hijacking.toml  | 37 +++++++++++++++-
 ...tion_sudo_token_via_process_injection.toml | 37 +++++++++++++++-
 ...uspicious_cap_setuid_python_execution.toml | 37 +++++++++++++++-
 ...ion_suspicious_chown_fowner_elevation.toml | 36 +++++++++++++++-
 ...calation_suspicious_passwd_file_write.toml | 36 +++++++++++++++-
 ...alation_suspicious_uid_guid_elevation.toml | 37 +++++++++++++++-
 ...scalation_uid_change_post_compilation.toml | 38 +++++++++++++++-
 ...uid_elevation_from_unknown_executable.toml | 38 +++++++++++++++-
 ...lation_unshare_namespace_manipulation.toml | 35 ++++++++++++++-
 ...ege_escalation_writable_docker_socket.toml | 36 +++++++++++++++-
 ...edential_access_credentials_keychains.toml | 35 ++++++++++++++-
 ...dential_access_dumping_hashes_bi_cmds.toml | 35 ++++++++++++++-
 ...tial_access_dumping_keychain_security.toml | 36 +++++++++++++++-
 .../credential_access_kerberosdump_kcc.toml   | 36 +++++++++++++++-
 ...s_keychain_pwd_retrieval_security_cmd.toml | 36 +++++++++++++++-
 ...ential_access_mitm_localhost_webproxy.toml | 37 +++++++++++++++-
 ...access_potential_macos_ssh_bruteforce.toml | 37 +++++++++++++++-
 ...al_access_promt_for_pwd_via_osascript.toml | 37 +++++++++++++++-
 ...ous_web_browser_sensitive_file_access.toml | 36 +++++++++++++++-
 .../credential_access_systemkey_dumping.toml  | 36 +++++++++++++++-
 ...vasion_apple_softupdates_modification.toml | 36 +++++++++++++++-
 ...evasion_attempt_del_quarantine_attrib.toml | 36 +++++++++++++++-
 ...evasion_attempt_to_disable_gatekeeper.toml | 37 +++++++++++++++-
 ...ense_evasion_install_root_certificate.toml | 35 ++++++++++++++-
 ..._evasion_modify_environment_launchctl.toml | 36 +++++++++++++++-
 ...cy_controls_tcc_database_modification.toml | 37 +++++++++++++++-
 ...tion_privacy_pref_sshd_fulldiskaccess.toml | 37 +++++++++++++++-
 .../defense_evasion_safari_config_change.toml | 36 +++++++++++++++-
 ...dboxed_office_app_suspicious_zip_file.toml | 36 +++++++++++++++-
 ...vasion_tcc_bypass_mounted_apfs_access.toml | 35 ++++++++++++++-
 ..._evasion_unload_endpointsecurity_kext.toml | 36 +++++++++++++++-
 ...covery_users_domain_built_in_commands.toml | 37 +++++++++++++++-
 ...vasion_electron_app_childproc_node_js.toml | 37 +++++++++++++++-
 ...l_access_suspicious_browser_childproc.toml | 37 +++++++++++++++-
 ...staller_package_spawned_network_event.toml | 37 +++++++++++++++-
 ...cution_script_via_automator_workflows.toml | 35 ++++++++++++++-
 ...ing_osascript_exec_followed_by_netcon.toml | 37 +++++++++++++++-
 ...n_shell_execution_via_apple_scripting.toml | 37 +++++++++++++++-
 ...uspicious_mac_ms_office_child_process.toml | 37 +++++++++++++++-
 ...ential_access_kerberos_bifrostconsole.toml | 36 +++++++++++++++-
 .../lateral_movement_mounting_smb_share.toml  | 36 +++++++++++++++-
 ...ral_movement_remote_ssh_login_enabled.toml | 35 ++++++++++++++-
 ...teral_movement_vpn_connection_attempt.toml | 36 +++++++++++++++-
 ...stence_account_creation_hide_at_logon.toml | 36 +++++++++++++++-
 ...ce_creation_change_launch_agents_file.toml | 36 +++++++++++++++-
 ..._creation_hidden_login_item_osascript.toml | 36 +++++++++++++++-
 ...creation_modif_launch_deamon_sequence.toml | 37 +++++++++++++++-
 ..._access_authorization_plugin_creation.toml | 36 +++++++++++++++-
 rules/macos/persistence_crontab_creation.toml | 36 +++++++++++++++-
 ...launch_agent_deamon_logonitem_process.toml | 37 +++++++++++++++-
 ...rectory_services_plugins_modification.toml | 36 +++++++++++++++-
 ...e_docker_shortcuts_plist_modification.toml | 37 +++++++++++++++-
 ...persistence_emond_rules_file_creation.toml | 35 ++++++++++++++-
 ...istence_emond_rules_process_execution.toml | 37 +++++++++++++++-
 .../persistence_enable_root_account.toml      | 35 ++++++++++++++-
 ...n_hidden_launch_agent_deamon_creation.toml | 37 +++++++++++++++-
 ...sistence_finder_sync_plugin_pluginkit.toml | 37 +++++++++++++++-
 ...istence_folder_action_scripts_runtime.toml | 36 +++++++++++++++-
 ...rsistence_login_logout_hooks_defaults.toml | 37 +++++++++++++++-
 ...fication_sublime_app_plugin_or_script.toml | 37 +++++++++++++++-
 ...ersistence_periodic_tasks_file_mdofiy.toml | 36 +++++++++++++++-
 ...ence_suspicious_calendar_modification.toml | 35 ++++++++++++++-
 ...tence_via_atom_init_file_modification.toml | 36 +++++++++++++++-
 ...calation_applescript_with_admin_privs.toml | 36 +++++++++++++++-
 ...calation_explicit_creds_via_scripting.toml | 37 +++++++++++++++-
 ...alation_exploit_adobe_acrobat_updater.toml | 36 +++++++++++++++-
 ..._escalation_local_user_added_to_admin.toml | 36 +++++++++++++++-
 ...ilege_escalation_root_crontab_filemod.toml | 36 +++++++++++++++-
 ...d_control_ml_packetbeat_dns_tunneling.toml | 36 +++++++++++++++-
 ...ntrol_ml_packetbeat_rare_dns_question.toml | 36 +++++++++++++++-
 ...d_and_control_ml_packetbeat_rare_urls.toml | 37 +++++++++++++++-
 ...control_ml_packetbeat_rare_user_agent.toml | 37 +++++++++++++++-
 ..._access_ml_auth_spike_in_logon_events.toml | 36 +++++++++++++++-
 ...s_ml_linux_anomalous_metadata_process.toml | 37 +++++++++++++++-
 ...cess_ml_linux_anomalous_metadata_user.toml | 38 +++++++++++++++-
 ...l_access_ml_suspicious_login_activity.toml | 36 +++++++++++++++-
 ...ml_windows_anomalous_metadata_process.toml | 36 +++++++++++++++-
 ...ss_ml_windows_anomalous_metadata_user.toml | 38 +++++++++++++++-
 ...ml_linux_system_information_discovery.toml | 37 +++++++++++++++-
 ...ystem_network_configuration_discovery.toml | 37 +++++++++++++++-
 ...x_system_network_connection_discovery.toml | 37 +++++++++++++++-
 ...ery_ml_linux_system_process_discovery.toml | 37 +++++++++++++++-
 ...covery_ml_linux_system_user_discovery.toml | 36 +++++++++++++++-
 ...execution_ml_windows_anomalous_script.toml | 37 +++++++++++++++-
 ...ess_ml_auth_rare_source_ip_for_a_user.toml | 36 +++++++++++++++-
 rules/ml/ml_high_count_network_denies.toml    | 36 +++++++++++++++-
 rules/ml/ml_high_count_network_events.toml    | 36 +++++++++++++++-
 ...linux_anomalous_network_port_activity.toml | 38 +++++++++++++++-
 .../ml/ml_packetbeat_rare_server_domain.toml  | 36 +++++++++++++++-
 rules/ml/ml_rare_destination_country.toml     | 37 +++++++++++++++-
 ...ce_ml_windows_anomalous_path_activity.toml | 37 +++++++++++++++-
 ...sistence_ml_windows_anomalous_service.toml | 37 +++++++++++++++-
 ...tion_ml_linux_anomalous_sudo_activity.toml | 37 +++++++++++++++-
 ...tion_ml_windows_rare_user_runas_event.toml | 37 +++++++++++++++-
 ..._ml_linux_anomalous_compiler_activity.toml | 37 +++++++++++++++-
 ...cepted_default_telnet_port_connection.toml | 37 +++++++++++++++-
 ...mand_and_control_cobalt_strike_beacon.toml | 40 ++++++++++++++++-
 ...cobalt_strike_default_teamserver_cert.toml | 39 ++++++++++++++++-
 ...download_rar_powershell_from_internet.toml | 40 ++++++++++++++++-
 .../command_and_control_halfbaked_beacon.toml | 39 ++++++++++++++++-
 ...d_control_nat_traversal_port_activity.toml | 37 +++++++++++++++-
 .../command_and_control_port_26_activity.toml | 36 +++++++++++++++-
 ...te_desktop_protocol_from_the_internet.toml | 36 +++++++++++++++-
 ...l_network_computing_from_the_internet.toml | 36 +++++++++++++++-
 ...ual_network_computing_to_the_internet.toml | 37 +++++++++++++++-
 ...very_potential_network_sweep_detected.toml | 43 ++++++++++++++++++-
 ...iscovery_potential_port_scan_detected.toml | 37 +++++++++++++++-
 ...very_potential_syn_port_scan_detected.toml | 35 +++++++++++++++
 ...mote_procedure_call_from_the_internet.toml | 36 +++++++++++++++-
 ...remote_procedure_call_to_the_internet.toml | 36 +++++++++++++++-
 ...file_sharing_activity_to_the_internet.toml | 37 +++++++++++++++-
 ...al_access_unsecure_elasticsearch_node.toml | 39 ++++++++++++++++-
 ..._access_endgame_cred_dumping_detected.toml | 38 +++++++++++++++-
 ...access_endgame_cred_dumping_prevented.toml | 37 +++++++++++++++-
 .../endgame_adversary_behavior_detected.toml  | 37 +++++++++++++++-
 .../promotions/endgame_malware_detected.toml  | 37 +++++++++++++++-
 .../promotions/endgame_malware_prevented.toml | 38 +++++++++++++++-
 .../endgame_ransomware_detected.toml          | 36 +++++++++++++++-
 .../endgame_ransomware_prevented.toml         | 37 +++++++++++++++-
 .../execution_endgame_exploit_detected.toml   | 36 +++++++++++++++-
 .../execution_endgame_exploit_prevented.toml  | 38 +++++++++++++++-
 rules/promotions/external_alerts.toml         | 37 +++++++++++++++-
 ...on_endgame_cred_manipulation_detected.toml | 37 +++++++++++++++-
 ...n_endgame_cred_manipulation_prevented.toml | 37 +++++++++++++++-
 ...ion_endgame_permission_theft_detected.toml | 37 +++++++++++++++-
 ...on_endgame_permission_theft_prevented.toml | 37 +++++++++++++++-
 ...on_endgame_process_injection_detected.toml | 38 +++++++++++++++-
 ...n_endgame_process_injection_prevented.toml | 37 +++++++++++++++-
 .../threat_intel_indicator_match_address.toml |  4 +-
 .../threat_intel_indicator_match_hash.toml    |  4 +-
 ...threat_intel_indicator_match_registry.toml |  4 +-
 .../threat_intel_indicator_match_url.toml     |  4 +-
 .../threat_intel_rapid7_threat_command.toml   |  4 +-
 ...lection_email_outlook_mailbox_via_com.toml | 37 +++++++++++++++-
 .../collection_posh_webcam_video_capture.toml | 36 +++++++++++++++-
 ...control_encrypted_channel_freesslcert.toml | 36 +++++++++++++++-
 .../command_and_control_iexplore_via_com.toml | 37 +++++++++++++++-
 ...command_and_control_outlook_home_page.toml | 36 +++++++++++++++-
 ...d_and_control_screenconnect_childproc.toml | 37 +++++++++++++++-
 .../command_and_control_tunnel_vscode.toml    | 37 +++++++++++++++-
 .../credential_access_adidns_wildcard.toml    | 37 +++++++++++++++-
 .../credential_access_adidns_wpad_record.toml | 37 +++++++++++++++-
 ...redential_access_dcsync_user_backdoor.toml | 40 ++++++++++++++++-
 .../credential_access_dnsnode_creation.toml   | 37 +++++++++++++++-
 ...redential_access_dollar_account_relay.toml | 37 +++++++++++++++-
 .../credential_access_generic_localdumps.toml | 36 +++++++++++++++-
 ..._access_iis_connectionstrings_dumping.toml | 37 +++++++++++++++-
 ...ccess_imageload_azureadconnectauthsvc.toml | 37 +++++++++++++++-
 .../windows/credential_access_kirbi_file.toml | 37 +++++++++++++++-
 .../credential_access_ldap_attributes.toml    | 37 +++++++++++++++-
 ...l_access_lsass_handle_via_malseclogon.toml | 36 +++++++++++++++-
 ...edential_access_lsass_loaded_susp_dll.toml | 37 +++++++++++++++-
 .../credential_access_posh_relay_tools.toml   | 37 +++++++++++++++-
 .../credential_access_posh_veeam_sql.toml     | 36 +++++++++++++++-
 ..._potential_lsa_memdump_via_mirrordump.toml | 36 +++++++++++++++-
 ...cess_relay_ntlm_auth_via_http_spoolss.toml | 37 +++++++++++++++-
 ...ntial_access_saved_creds_vault_winlog.toml | 37 +++++++++++++++-
 ...redential_access_saved_creds_vaultcmd.toml | 36 +++++++++++++++-
 ...ccess_suspicious_lsass_access_generic.toml | 37 +++++++++++++++-
 ...ccess_suspicious_lsass_access_memdump.toml | 37 +++++++++++++++-
 ..._suspicious_lsass_access_via_snapshot.toml | 36 +++++++++++++++-
 ...ial_access_veeam_backup_dll_imageload.toml | 36 +++++++++++++++-
 .../credential_access_veeam_commands.toml     | 37 +++++++++++++++-
 ...ess_via_snapshot_lsass_clone_creation.toml | 37 +++++++++++++++-
 .../credential_access_wbadmin_ntds.toml       | 36 +++++++++++++++-
 .../defense_evasion_cve_2020_0601.toml        | 36 +++++++++++++++-
 .../windows/defense_evasion_disable_nla.toml  | 35 ++++++++++++++-
 ...efense_evasion_dns_over_https_enabled.toml | 35 ++++++++++++++-
 ...vasion_dotnet_compiler_parent_process.toml | 37 +++++++++++++++-
 ...ecution_control_panel_suspicious_args.toml | 37 +++++++++++++++-
 ...n_execution_msbuild_started_by_script.toml | 37 +++++++++++++++-
 ...ion_msbuild_started_by_system_process.toml | 37 +++++++++++++++-
 ...cution_msbuild_started_unusal_process.toml | 37 +++++++++++++++-
 ...execution_suspicious_explorer_winword.toml | 37 +++++++++++++++-
 ...sion_execution_windefend_unusual_path.toml | 35 ++++++++++++++-
 ..._evasion_file_creation_mult_extension.toml | 36 +++++++++++++++-
 ...sion_hide_encoded_executable_registry.toml | 36 +++++++++++++++-
 .../defense_evasion_injection_msbuild.toml    | 38 +++++++++++++++-
 .../defense_evasion_installutil_beacon.toml   | 37 +++++++++++++++-
 ...efense_evasion_lolbas_win_cdb_utility.toml | 36 +++++++++++++++-
 ...querading_as_elastic_endpoint_process.toml | 37 +++++++++++++++-
 ..._masquerading_business_apps_installer.toml | 38 +++++++++++++++-
 ...asion_masquerading_communication_apps.toml | 37 +++++++++++++++-
 ...erading_suspicious_werfault_childproc.toml | 36 +++++++++++++++-
 ...vasion_masquerading_trusted_directory.toml | 37 +++++++++++++++-
 .../windows/defense_evasion_mshta_beacon.toml | 35 ++++++++++++++-
 ...nse_evasion_msiexec_child_proc_netcon.toml | 37 +++++++++++++++-
 .../defense_evasion_msxsl_network.toml        | 36 +++++++++++++++-
 ...e_evasion_parent_process_pid_spoofing.toml | 38 +++++++++++++++-
 ...persistence_account_tokenfilterpolicy.toml | 36 +++++++++++++++-
 .../defense_evasion_posh_obfuscation.toml     | 37 +++++++++++++++-
 ...ense_evasion_proxy_execution_via_msdt.toml | 37 +++++++++++++++-
 ...eg_disable_enableglobalqueryblocklist.toml | 36 +++++++++++++++-
 ...defense_evasion_root_dir_ads_creation.toml | 37 +++++++++++++++-
 rules/windows/defense_evasion_sc_sdset.toml   | 38 +++++++++++++++-
 ...fense_evasion_sccm_scnotification_dll.toml | 35 ++++++++++++++-
 ...ion_scheduledjobs_at_protocol_enabled.toml | 36 +++++++++++++++-
 .../defense_evasion_script_via_html_app.toml  | 35 ++++++++++++++-
 .../defense_evasion_sip_provider_mod.toml     | 36 +++++++++++++++-
 ...ackdoor_service_disabled_via_registry.toml | 37 +++++++++++++++-
 ...picious_execution_from_mounted_device.toml | 37 +++++++++++++++-
 ...n_suspicious_managedcode_host_process.toml | 37 +++++++++++++++-
 ...efense_evasion_suspicious_scrobj_load.toml | 36 +++++++++++++++-
 ...defense_evasion_suspicious_wmi_script.toml | 37 +++++++++++++++-
 .../defense_evasion_timestomp_sysmon.toml     | 37 +++++++++++++++-
 ...sion_unsigned_dll_loaded_from_suspdir.toml | 36 +++++++++++++++-
 .../defense_evasion_unusual_dir_ads.toml      | 37 +++++++++++++++-
 ...nusual_network_connection_via_dllhost.toml | 35 ++++++++++++++-
 ...asion_unusual_system_vp_child_program.toml | 38 +++++++++++++++-
 ...se_evasion_windows_filtering_platform.toml | 38 +++++++++++++++-
 .../defense_evasion_wsl_bash_exec.toml        | 36 +++++++++++++++-
 .../defense_evasion_wsl_child_process.toml    | 37 +++++++++++++++-
 .../defense_evasion_wsl_filesystem.toml       | 36 +++++++++++++++-
 .../defense_evasion_wsl_kalilinux.toml        | 36 +++++++++++++++-
 ...discovery_active_directory_webservice.toml | 36 +++++++++++++++-
 .../discovery_high_number_ad_properties.toml  | 36 +++++++++++++++-
 ...unusual_discovery_signal_proc_cmdline.toml | 37 +++++++++++++++-
 ...sual_discovery_signal_proc_executable.toml | 37 +++++++++++++++-
 ...arwinds_backdoor_child_cmd_powershell.toml | 37 +++++++++++++++-
 ...inds_backdoor_unusual_child_processes.toml | 37 +++++++++++++++-
 .../windows/execution_com_object_xwizard.toml | 36 +++++++++++++++-
 ...mand_shell_started_by_unusual_process.toml | 38 +++++++++++++++-
 .../execution_command_shell_via_rundll32.toml | 37 +++++++++++++++-
 ...tion_delayed_via_ping_lolbas_unsigned.toml | 37 +++++++++++++++-
 .../execution_downloaded_shortcut_files.toml  | 36 +++++++++++++++-
 .../execution_downloaded_url_file.toml        | 37 +++++++++++++++-
 .../execution_enumeration_via_wmiprvse.toml   | 37 +++++++++++++++-
 ...cution_initial_access_foxmail_exploit.toml | 37 +++++++++++++++-
 ...cution_initial_access_wps_dll_exploit.toml | 37 +++++++++++++++-
 rules/windows/execution_mofcomp.toml          | 34 ++++++++++++++-
 .../execution_posh_hacktool_authors.toml      | 36 +++++++++++++++-
 ...on_powershell_susp_args_via_winscript.toml | 36 +++++++++++++++-
 ...tion_scheduled_task_powershell_source.toml | 35 ++++++++++++++-
 .../windows/execution_suspicious_cmd_wmi.toml | 37 +++++++++++++++-
 ...n_suspicious_image_load_wmi_ms_office.toml | 36 +++++++++++++++-
 ...ion_via_mmc_console_file_unusual_path.toml | 36 +++++++++++++++-
 ...execution_windows_cmd_shell_susp_args.toml | 37 +++++++++++++++-
 ...xecution_windows_powershell_susp_args.toml | 37 +++++++++++++++-
 .../exfiltration_smb_rare_destination.toml    | 37 +++++++++++++++-
 ..._evasion_suspicious_htm_file_creation.toml | 40 ++++++++++++++++-
 ...itial_access_execution_from_inetcache.toml | 37 +++++++++++++++-
 ...access_execution_from_removable_media.toml | 38 +++++++++++++++-
 ...l_access_execution_remote_via_msiexec.toml | 37 +++++++++++++++-
 ...al_access_execution_via_office_addins.toml | 36 +++++++++++++++-
 ...cess_exfiltration_first_time_seen_usb.toml | 36 +++++++++++++++-
 ...ial_access_exploit_jetbrains_teamcity.toml | 37 +++++++++++++++-
 ...itial_access_rdp_file_mail_attachment.toml | 37 +++++++++++++++-
 ...ccess_scripts_process_started_via_wmi.toml | 36 +++++++++++++++-
 ...access_suspicious_ms_exchange_process.toml | 37 +++++++++++++++-
 ...ious_ms_exchange_worker_child_process.toml | 38 +++++++++++++++-
 ...explorer_suspicious_child_parent_args.toml | 37 +++++++++++++++-
 ..._access_webshell_screenconnect_server.toml | 37 +++++++++++++++-
 ...l_access_xsl_script_execution_via_com.toml | 37 +++++++++++++++-
 .../lateral_movement_alternate_creds_pth.toml | 37 +++++++++++++++-
 .../windows/lateral_movement_cmd_service.toml | 36 +++++++++++++++-
 rules/windows/lateral_movement_dcom_hta.toml  | 37 +++++++++++++++-
 .../windows/lateral_movement_dcom_mmc20.toml  | 36 +++++++++++++++-
 ...t_dcom_shellwindow_shellbrowserwindow.toml | 37 +++++++++++++++-
 ...n_lanman_nullsessionpipe_modification.toml | 36 +++++++++++++++-
 ...ateral_movement_evasion_rdp_shadowing.toml | 36 +++++++++++++++-
 ..._movement_execution_from_tsclient_mup.toml | 37 +++++++++++++++-
 ...vement_incoming_winrm_shell_execution.toml | 37 +++++++++++++++-
 .../lateral_movement_incoming_wmi.toml        | 37 +++++++++++++++-
 ...ment_mount_hidden_or_webdav_share_net.toml | 36 +++++++++++++++-
 ...l_movement_powershell_remoting_target.toml | 37 +++++++++++++++-
 .../lateral_movement_rdp_sharprdp_target.toml | 36 +++++++++++++++-
 ...ovement_remote_file_copy_hidden_share.toml | 37 +++++++++++++++-
 ...ement_remote_service_installed_winlog.toml | 37 +++++++++++++++-
 ...ement_suspicious_rdp_client_imageload.toml | 36 +++++++++++++++-
 ...l_movement_via_startup_folder_rdp_smb.toml | 36 +++++++++++++++-
 .../lateral_movement_via_wsus_update.toml     | 36 +++++++++++++++-
 .../windows/persistence_ad_adminsdholder.toml | 37 +++++++++++++++-
 .../windows/persistence_app_compat_shim.toml  | 37 +++++++++++++++-
 .../persistence_appcertdlls_registry.toml     | 37 +++++++++++++++-
 ...persistence_browser_extension_install.toml | 36 +++++++++++++++-
 ...tence_evasion_registry_ifeo_injection.toml | 36 +++++++++++++++-
 ...sistence_group_modification_by_system.toml | 37 +++++++++++++++-
 ...sistence_local_scheduled_job_creation.toml | 36 +++++++++++++++-
 ...istence_local_scheduled_task_creation.toml | 37 +++++++++++++++-
 .../persistence_ms_office_addins_file.toml    | 37 +++++++++++++++-
 .../persistence_ms_outlook_vba_template.toml  | 38 +++++++++++++++-
 ...istence_msds_alloweddelegateto_krbtgt.toml | 36 +++++++++++++++-
 ...ersistence_msi_installer_task_startup.toml | 38 +++++++++++++++-
 ...persistence_msoffice_startup_registry.toml | 36 +++++++++++++++-
 .../windows/persistence_netsh_helper_dll.toml | 35 ++++++++++++++-
 ...ll_exch_mailbox_activesync_add_device.toml | 37 +++++++++++++++-
 .../persistence_registry_uncommon.toml        | 37 +++++++++++++++-
 .../persistence_remote_password_reset.toml    | 38 +++++++++++++++-
 ...ce_runtime_run_key_startup_susp_procs.toml | 37 +++++++++++++++-
 ...stence_scheduled_task_creation_winlog.toml | 35 ++++++++++++++-
 .../persistence_scheduled_task_updated.toml   | 35 ++++++++++++++-
 .../persistence_service_dll_unsigned.toml     | 38 +++++++++++++++-
 .../persistence_services_registry.toml        | 37 +++++++++++++++-
 ...nce_suspicious_scheduled_task_runtime.toml | 37 +++++++++++++++-
 ...e_suspicious_service_created_registry.toml | 37 +++++++++++++++-
 ...istence_sysmon_wmi_event_subscription.toml | 36 +++++++++++++++-
 .../persistence_temp_scheduled_task.toml      | 36 +++++++++++++++-
 ...ence_user_account_creation_event_logs.toml | 37 +++++++++++++++-
 .../persistence_via_application_shimming.toml | 37 +++++++++++++++-
 ...rsistence_via_bits_job_notify_command.toml | 38 +++++++++++++++-
 ...sistence_via_hidden_run_key_valuename.toml | 37 +++++++++++++++-
 ...sa_security_support_provider_registry.toml | 37 +++++++++++++++-
 ...emetrycontroller_scheduledtask_hijack.toml | 37 +++++++++++++++-
 ...nt_instrumentation_event_subscription.toml | 35 ++++++++++++++-
 .../persistence_werfault_reflectdebugger.toml | 36 +++++++++++++++-
 ...tion_create_process_as_different_user.toml | 36 +++++++++++++++-
 ...tion_create_process_with_token_unpriv.toml | 37 +++++++++++++++-
 ...privilege_escalation_credroaming_ldap.toml | 37 +++++++++++++++-
 ...e_escalation_dns_serverlevelplugindll.toml | 38 +++++++++++++++-
 ...lege_escalation_expired_driver_loaded.toml | 36 +++++++++++++++-
 ...lege_escalation_exploit_cve_202238028.toml | 37 +++++++++++++++-
 ...calation_gpo_schtask_service_creation.toml | 37 +++++++++++++++-
 ...scalation_krbrelayup_service_creation.toml | 35 ++++++++++++++-
 ...privilege_escalation_lsa_auth_package.toml | 36 +++++++++++++++-
 ...privilege_escalation_make_token_local.toml | 35 ++++++++++++++-
 ...escalation_msi_repair_via_mshelp_link.toml | 36 +++++++++++++++-
 ...scalation_newcreds_logon_rare_process.toml | 36 +++++++++++++++-
 ...ion_port_monitor_print_pocessor_abuse.toml | 37 +++++++++++++++-
 ...ation_printspooler_registry_copyfiles.toml | 36 +++++++++++++++-
 ..._printspooler_service_suspicious_file.toml | 36 +++++++++++++++-
 ...printspooler_suspicious_file_deletion.toml | 36 +++++++++++++++-
 ..._escalation_reg_service_imagepath_mod.toml | 37 +++++++++++++++-
 ...calation_rogue_windir_environment_var.toml | 38 +++++++++++++++-
 ...lation_samaccountname_spoofing_attack.toml | 36 +++++++++++++++-
 ...alation_suspicious_dnshostname_update.toml | 37 +++++++++++++++-
 ...lation_tokenmanip_sedebugpriv_enabled.toml | 37 +++++++++++++++-
 ...lege_escalation_uac_bypass_com_clipup.toml | 37 +++++++++++++++-
 ...ge_escalation_uac_bypass_com_ieinstal.toml | 38 +++++++++++++++-
 ...n_uac_bypass_com_interface_icmluautil.toml | 37 +++++++++++++++-
 ...alation_uac_bypass_diskcleanup_hijack.toml | 38 +++++++++++++++-
 ...escalation_uac_bypass_dll_sideloading.toml | 38 +++++++++++++++-
 ...lege_escalation_unquoted_service_path.toml | 37 +++++++++++++++-
 ...ion_unusual_printspooler_childprocess.toml | 39 ++++++++++++++++-
 ...n_unusual_svchost_childproc_childless.toml | 38 +++++++++++++++-
 ...rivilege_escalation_via_ppid_spoofing.toml | 37 +++++++++++++++-
 ...ilege_escalation_via_rogue_named_pipe.toml | 36 +++++++++++++++-
 .../privilege_escalation_via_token_theft.toml | 38 +++++++++++++++-
 ...on_windows_service_via_unusual_client.toml | 37 +++++++++++++++-
 ...rivilege_escalation_wpad_exploitation.toml | 36 +++++++++++++++-
 ...collection_archive_data_zip_imageload.toml | 37 +++++++++++++++-
 ...ction_common_compressed_archived_file.toml | 36 +++++++++++++++-
 ...tion_files_staged_in_recycle_bin_root.toml | 36 +++++++++++++++-
 .../collection_outlook_email_archive.toml     | 36 +++++++++++++++-
 .../collection_posh_compression.toml          | 36 +++++++++++++++-
 ...ommand_and_control_bitsadmin_activity.toml | 37 +++++++++++++++-
 ...ntial_access_iis_apppoolsa_pwd_appcmd.toml | 36 +++++++++++++++-
 .../credential_access_mdmp_file_creation.toml | 37 +++++++++++++++-
 ...al_access_mdmp_file_unusual_extension.toml | 37 +++++++++++++++-
 ...dential_access_win_private_key_access.toml | 37 +++++++++++++++-
 ...ense_evasion_aws_rds_snapshot_created.toml | 36 +++++++++++++++-
 ...ense_evasion_cmd_copy_binary_contents.toml | 36 +++++++++++++++-
 .../defense_evasion_cmstp_execution.toml      | 36 +++++++++++++++-
 ...rading_unusual_archive_file_extension.toml | 37 +++++++++++++++-
 ...ication_apps_suspicious_child_process.toml | 37 +++++++++++++++-
 .../defense_evasion_dll_hijack.toml           | 36 +++++++++++++++-
 ...evasion_dotnet_clickonce_dfsvc_netcon.toml | 37 +++++++++++++++-
 ...fense_evasion_download_susp_extension.toml | 36 +++++++++++++++-
 ...cution_via_visualstudio_prebuildevent.toml | 36 +++++++++++++++-
 ..._evasion_file_permission_modification.toml | 38 +++++++++++++++-
 .../defense_evasion_generic_deletion.toml     | 36 +++++++++++++++-
 ...indirect_command_exec_pcalua_forfiles.toml | 36 +++++++++++++++-
 ...fense_evasion_injection_from_msoffice.toml | 37 +++++++++++++++-
 ..._evasion_installutil_command_activity.toml | 36 +++++++++++++++-
 ...se_evasion_invalid_codesign_imageload.toml | 37 +++++++++++++++-
 ...defense_evasion_masquerading_browsers.toml | 37 +++++++++++++++-
 ...squerading_unusual_exe_file_extension.toml | 36 +++++++++++++++-
 .../defense_evasion_masquerading_vlc_dll.toml | 37 +++++++++++++++-
 ...ense_evasion_masquerading_windows_dll.toml | 39 ++++++++++++++++-
 ...ion_masquerading_windows_system32_exe.toml | 37 +++++++++++++++-
 ...fense_evasion_msdt_suspicious_diagcab.toml | 36 +++++++++++++++-
 ...on_msiexec_installsource_archive_file.toml | 36 +++++++++++++++-
 ...fense_evasion_posh_defender_tampering.toml | 36 +++++++++++++++-
 ..._evasion_powershell_clear_logs_script.toml | 36 +++++++++++++++-
 ...vasion_processes_with_trailing_spaces.toml | 36 +++++++++++++++-
 ...nse_evasion_service_disabled_registry.toml | 37 +++++++++++++++-
 ...defense_evasion_service_path_registry.toml | 35 ++++++++++++++-
 .../defense_evasion_services_exe_path.toml    | 37 +++++++++++++++-
 ..._evasion_suspicious_msiexec_execution.toml | 37 +++++++++++++++-
 .../defense_evasion_unsigned_bits_client.toml | 36 +++++++++++++++-
 ...nse_evasion_unusual_process_extension.toml | 37 +++++++++++++++-
 ...nse_evasion_unusual_process_path_wbem.toml | 38 +++++++++++++++-
 .../defense_evasion_write_dac_access.toml     | 36 +++++++++++++++-
 .../discovery_capnetraw_capability.toml       | 37 +++++++++++++++-
 .../discovery_generic_account_groups.toml     | 36 +++++++++++++++-
 .../discovery_generic_process_discovery.toml  | 37 +++++++++++++++-
 .../discovery_generic_registry_query.toml     | 37 +++++++++++++++-
 .../discovery_hosts_file_access.toml          | 35 ++++++++++++++-
 .../discovery_internet_capabilities.toml      | 35 ++++++++++++++-
 ...ry_kernel_module_enumeration_via_proc.toml | 36 +++++++++++++++-
 .../discovery_linux_modprobe_enumeration.toml | 37 +++++++++++++++-
 .../discovery_linux_sysctl_enumeration.toml   | 37 +++++++++++++++-
 ...ry_linux_system_information_discovery.toml | 37 +++++++++++++++-
 ...ery_linux_system_owner_user_discovery.toml | 37 +++++++++++++++-
 .../discovery_net_share_discovery_winlog.toml | 36 +++++++++++++++-
 ..._accounts_or_groups_via_builtin_tools.toml | 36 +++++++++++++++-
 .../discovery_of_domain_groups.toml           | 37 +++++++++++++++-
 .../discovery_posh_generic.toml               | 36 +++++++++++++++-
 .../discovery_posh_password_policy.toml       | 35 ++++++++++++++-
 ...ery_potential_memory_seeking_activity.toml | 35 ++++++++++++++-
 ...y_process_discovery_via_builtin_tools.toml | 36 +++++++++++++++-
 .../discovery_signal_unusual_user_host.toml   | 36 +++++++++++++++-
 ...discovery_suspicious_proc_enumeration.toml | 36 +++++++++++++++-
 .../discovery_system_network_connections.toml | 36 +++++++++++++++-
 .../discovery_system_service_discovery.toml   | 36 +++++++++++++++-
 .../discovery_system_time_discovery.toml      | 36 +++++++++++++++-
 ...ry_userdata_request_from_ec2_instance.toml | 36 +++++++++++++++-
 .../discovery_win_network_connections.toml    | 35 ++++++++++++++-
 ..._windows_system_information_discovery.toml | 35 ++++++++++++++-
 ...execution_aws_lambda_function_updated.toml | 36 +++++++++++++++-
 ...ution_github_new_event_action_for_pat.toml | 37 +++++++++++++++-
 ...n_github_new_repo_interaction_for_pat.toml | 37 +++++++++++++++-
 ..._github_new_repo_interaction_for_user.toml | 37 +++++++++++++++-
 .../execution_github_repo_created.toml        | 36 +++++++++++++++-
 ...n_github_repo_interaction_from_new_ip.toml | 36 +++++++++++++++-
 .../execution_linux_segfault.toml             | 36 +++++++++++++++-
 ...ution_settingcontent_ms_file_creation.toml | 36 +++++++++++++++-
 ...execution_unsigned_service_executable.toml | 37 +++++++++++++++-
 .../execution_wmi_wbemtest.toml               | 37 +++++++++++++++-
 ...thub_member_removed_from_organization.toml | 35 ++++++++++++++-
 .../impact_github_pat_access_revoked.toml     | 35 ++++++++++++++-
 ...github_user_blocked_from_organization.toml | 36 +++++++++++++++-
 .../initial_access_cross_site_scripting.toml  | 37 +++++++++++++++-
 ..._access_github_new_ip_address_for_pat.toml | 37 +++++++++++++++-
 ...access_github_new_ip_address_for_user.toml | 37 +++++++++++++++-
 ..._access_github_new_user_agent_for_pat.toml | 37 +++++++++++++++-
 ...access_github_new_user_agent_for_user.toml | 37 +++++++++++++++-
 rules_building_block/lateral_movement_at.toml | 36 +++++++++++++++-
 .../lateral_movement_posh_winrm_activity.toml | 36 +++++++++++++++-
 ...ral_movement_rdp_conn_unusual_process.toml | 35 ++++++++++++++-
 ...movement_unusual_process_sql_accounts.toml | 36 +++++++++++++++-
 .../lateral_movement_wmic_remote.toml         | 36 +++++++++++++++-
 ...e_aws_iam_login_profile_added_to_user.toml | 36 +++++++++++++++-
 ...nce_cap_sys_admin_added_to_new_binary.toml | 37 +++++++++++++++-
 ...persistence_creation_of_kernel_module.toml | 36 +++++++++++++++-
 .../persistence_github_new_pat_for_user.toml  | 36 +++++++++++++++-
 ...github_new_user_added_to_organization.toml | 37 +++++++++++++++-
 ...e_iam_instance_request_to_iam_service.toml | 36 +++++++++++++++-
 .../persistence_startup_folder_lnk.toml       | 37 +++++++++++++++-
 .../persistence_transport_agent_exchange.toml | 36 +++++++++++++++-
 .../privilege_escalation_trap_execution.toml  | 36 +++++++++++++++-
 901 files changed, 30998 insertions(+), 1115 deletions(-)

diff --git a/rules/apm/apm_403_response_to_a_post.toml b/rules/apm/apm_403_response_to_a_post.toml
index d8010b71afc..72a90b2e67b 100644
--- a/rules/apm/apm_403_response_to_a_post.toml
+++ b/rules/apm/apm_403_response_to_a_post.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -32,4 +32,38 @@ type = "query"
 query = '''
 http.response.status_code:403 and http.request.method:post
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Web Application Suspicious Activity: POST Request Declined
+
+Web applications often use POST requests to handle data submissions securely. However, adversaries may exploit this by attempting unauthorized actions, triggering a 403 error when access is denied. The detection rule identifies such anomalies by flagging POST requests that receive a 403 response, indicating potential misuse or probing attempts, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the source IP address and user agent associated with the POST request to identify any patterns or known malicious actors.
+- Examine the URL or endpoint targeted by the POST request to determine if it is a sensitive or restricted resource.
+- Check the timestamp of the request to see if it coincides with other suspicious activities or known attack patterns.
+- Analyze the frequency and volume of similar 403 POST requests from the same source to assess if this is part of a larger probing or attack attempt.
+- Investigate any recent changes or updates to the web application that might have inadvertently triggered legitimate requests to be denied.
+
+### False positive analysis
+
+- Legitimate API interactions may trigger 403 responses if the API endpoint is accessed without proper authentication or authorization. Review API access logs to identify and whitelist known applications or users that frequently interact with the API.
+- Web application firewalls (WAFs) might block certain POST requests due to predefined security rules, resulting in 403 errors. Analyze WAF logs to determine if specific rules are causing false positives and adjust the ruleset accordingly.
+- Automated scripts or bots performing routine tasks might inadvertently trigger 403 responses. Identify these scripts and ensure they are configured with the necessary permissions or exclude their IP addresses from the detection rule.
+- User error, such as incorrect form submissions or missing required fields, can lead to 403 responses. Educate users on proper form usage and consider implementing client-side validation to reduce these occurrences.
+- Maintenance or configuration changes in the web application might temporarily cause 403 errors. Coordinate with the development or operations team to understand scheduled changes and adjust monitoring rules during these periods.
+
+### Response and remediation
+
+- Immediately review the logs associated with the 403 POST requests to identify the source IP addresses and user agents involved. Block any suspicious IP addresses at the firewall or web application firewall (WAF) to prevent further unauthorized attempts.
+- Conduct a thorough review of the web application's access control policies and permissions to ensure that they are correctly configured to prevent unauthorized actions.
+- Check for any recent changes or updates to the web application that might have inadvertently altered access controls or introduced vulnerabilities, and roll back or patch as necessary.
+- Notify the security operations team to monitor for any additional suspicious activity from the identified IP addresses or similar patterns, and escalate to incident response if further malicious activity is detected.
+- Implement additional logging and monitoring for POST requests that result in 403 responses to enhance detection capabilities and gather more context for future incidents.
+- Review and update the web application firewall (WAF) rules to better detect and block unauthorized POST requests, ensuring that legitimate traffic is not affected.
+- If applicable, engage with the development team to conduct a security review of the application code to identify and fix any potential vulnerabilities that could be exploited by attackers."""
 
diff --git a/rules/apm/apm_405_response_method_not_allowed.toml b/rules/apm/apm_405_response_method_not_allowed.toml
index bedc96ade16..2a9367dd263 100644
--- a/rules/apm/apm_405_response_method_not_allowed.toml
+++ b/rules/apm/apm_405_response_method_not_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -32,4 +32,38 @@ type = "query"
 query = '''
 http.response.status_code:405
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Web Application Suspicious Activity: Unauthorized Method
+
+Web applications often restrict HTTP methods to protect resources, allowing only specific actions like GET or POST. Adversaries may exploit misconfigurations by attempting unauthorized methods, potentially revealing vulnerabilities or sensitive data. The detection rule identifies such attempts by flagging HTTP 405 responses, indicating a method is not permitted, thus highlighting potential misuse or probing activities.
+
+### Possible investigation steps
+
+- Review the web server logs to identify the source IP address associated with the HTTP 405 response to determine if the request originated from a known or suspicious source.
+- Analyze the request headers and payload associated with the 405 response to understand what unauthorized method was attempted and if there are any patterns or anomalies.
+- Check the application configuration to verify which HTTP methods are allowed for the resource in question and assess if there are any misconfigurations that could be exploited.
+- Investigate if there are multiple 405 responses from the same source IP or user agent, which could indicate probing or automated scanning activity.
+- Correlate the 405 response events with other security alerts or logs to identify any related suspicious activities or potential attack vectors.
+
+### False positive analysis
+
+- Routine API calls using unsupported methods may trigger 405 responses. Review API documentation to ensure correct methods are used and adjust monitoring to exclude these known patterns.
+- Automated tools or scripts might inadvertently use incorrect HTTP methods, leading to false positives. Identify and update these tools to use appropriate methods, or whitelist their IP addresses if they are known and trusted.
+- Web crawlers or bots might attempt unsupported methods as part of their scanning process. Configure your monitoring system to recognize and exclude these benign activities based on user-agent strings or IP ranges.
+- Development and testing environments often experiment with various HTTP methods, resulting in 405 responses. Implement rules to exclude these environments from production monitoring to reduce noise.
+- Legacy systems or applications might not support certain HTTP methods, causing frequent 405 errors. Document these systems and create exceptions in your monitoring to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately review the web server and application logs to identify the source IP address and user agent associated with the 405 response. Block the IP address if it is determined to be malicious or part of a known attack pattern.
+- Conduct a security assessment of the web application's configuration to ensure that only necessary HTTP methods are enabled for each resource. Disable any methods that are not required for the application's functionality.
+- Implement or update web application firewall (WAF) rules to block unauthorized HTTP methods and monitor for repeated attempts from the same source.
+- Notify the security operations team to monitor for any additional suspicious activity from the identified source or similar patterns, and escalate to incident response if further malicious activity is detected.
+- Review and update the application's security policies and access controls to ensure they align with best practices and prevent unauthorized method usage.
+- Conduct a vulnerability assessment of the web application to identify and remediate any potential security weaknesses that could be exploited by unauthorized HTTP methods.
+- Document the incident, including the response actions taken, and update the incident response plan to improve future detection and response capabilities for similar threats."""
 
diff --git a/rules/apm/apm_sqlmap_user_agent.toml b/rules/apm/apm_sqlmap_user_agent.toml
index c8ba5b28669..570ea7d28b5 100644
--- a/rules/apm/apm_sqlmap_user_agent.toml
+++ b/rules/apm/apm_sqlmap_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -32,4 +32,39 @@ type = "query"
 query = '''
 user_agent.original:"sqlmap/1.3.11#stable (http://sqlmap.org)"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Web Application Suspicious Activity: sqlmap User Agent
+
+Sqlmap is a widely-used open-source tool designed to automate the detection and exploitation of SQL injection vulnerabilities in web applications. Adversaries may exploit sqlmap to extract sensitive data or manipulate databases. The detection rule identifies suspicious activity by monitoring for specific user agent strings associated with sqlmap, flagging potential unauthorized testing or attacks on web applications.
+
+### Possible investigation steps
+
+- Review the logs to identify the source IP address associated with the user agent string "sqlmap/1.3.11#stable (http://sqlmap.org)" to determine the origin of the suspicious activity.
+- Check for any other user agent strings or unusual activity from the same IP address to assess if there are additional signs of probing or attacks.
+- Investigate the targeted web application endpoints to understand which parts of the application were accessed and if any SQL injection attempts were successful.
+- Correlate the timestamp of the detected activity with other security logs or alerts to identify any concurrent suspicious activities or anomalies.
+- Assess the potential impact by reviewing database logs or application logs for any unauthorized data access or modifications during the time of the detected activity.
+- Consider blocking or monitoring the identified IP address to prevent further unauthorized access attempts, if deemed malicious.
+
+### False positive analysis
+
+- Development and testing environments may use sqlmap for legitimate security testing. To handle this, create exceptions for known IP addresses or user agents associated with internal security teams.
+- Automated security scanners or vulnerability assessment tools might mimic sqlmap's user agent for testing purposes. Identify and whitelist these tools to prevent unnecessary alerts.
+- Some web application firewalls or intrusion detection systems may simulate sqlmap activity to test their own detection capabilities. Coordinate with your security infrastructure team to recognize and exclude these activities.
+- Educational institutions or training environments might use sqlmap for teaching purposes. Establish a list of authorized users or networks to exclude from alerts.
+- Ensure that any third-party security service providers are recognized and their activities are documented to avoid misidentification as threats.
+
+### Response and remediation
+
+- Immediately block the IP address associated with the sqlmap user agent activity to prevent further unauthorized access attempts.
+- Review and analyze web server logs to identify any additional suspicious activity or patterns that may indicate further exploitation attempts.
+- Conduct a thorough assessment of the affected web application to identify and patch any SQL injection vulnerabilities that may have been exploited.
+- Reset credentials and enforce strong password policies for any database accounts that may have been compromised.
+- Implement web application firewall (WAF) rules to detect and block SQL injection attempts, including those using sqlmap.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Document the incident details and response actions taken for future reference and to enhance incident response procedures."""
 
diff --git a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
index cde6a30ffa4..e00be1244c6 100644
--- a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
+++ b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/19"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2024/08/09"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,41 @@ process where
     /* Look for Google Drive download URL with AV flag skipping */
     (process.command_line : "*drive.google.com*" and process.command_line : "*export=download*" and process.command_line : "*confirm=no_antivirus*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious File Downloaded from Google Drive
+
+Google Drive is a widely-used cloud storage service that allows users to store and share files. Adversaries may exploit its trusted nature to distribute malicious files, bypassing security measures by using download links with antivirus checks disabled. The detection rule identifies such activities by monitoring browser processes for specific Google Drive download patterns, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process command line details to confirm the presence of the Google Drive download URL with the "export=download" and "confirm=no_antivirus" parameters, which indicate an attempt to bypass antivirus checks.
+- Identify the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Check the file downloaded from the Google Drive URL for any known malicious signatures or behaviors using a reputable antivirus or malware analysis tool.
+- Investigate the source of the download link to determine if it was shared via email, messaging, or another communication channel, and assess the legitimacy of the source.
+- Analyze network logs to identify any additional suspicious activity or connections related to the IP address or domain associated with the download.
+- Review historical data for any previous similar alerts or activities involving the same user or device to identify potential patterns or repeated attempts.
+
+### False positive analysis
+
+- Legitimate file sharing activities from Google Drive may trigger alerts if users frequently download files for business purposes. To manage this, create exceptions for specific users or departments known to use Google Drive extensively for legitimate work.
+- Automated scripts or tools that download files from Google Drive for regular data processing tasks might be flagged. Identify these scripts and whitelist their associated processes or command lines to prevent unnecessary alerts.
+- Educational institutions or research organizations often share large datasets via Google Drive, which could be mistakenly flagged. Implement exceptions for known educational or research-related Google Drive URLs to reduce false positives.
+- Internal IT or security teams may use Google Drive to distribute software updates or patches. Recognize these activities and exclude them by specifying trusted internal Google Drive links or user accounts.
+- Collaboration with external partners who use Google Drive for file sharing can lead to false positives. Establish a list of trusted partners and their associated Google Drive URLs to minimize unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Quarantine the downloaded file and perform a detailed malware analysis using a sandbox environment to determine its behavior and potential impact.
+- If malware is confirmed, initiate a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Review and analyze the process command line logs to identify any other suspicious activities or downloads that may have occurred concurrently.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement network-level blocking of the specific Google Drive URL or domain if it is confirmed to be malicious, to prevent future access.
+- Update endpoint detection and response (EDR) systems with indicators of compromise (IOCs) identified during the analysis to enhance detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
index 7e90f0a3dc5..639840ec937 100644
--- a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
+++ b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,40 @@ sequence by process.entity_id with maxspan=1m
    )
   ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Non-Standard Port SSH connection
+
+SSH is a protocol used for secure remote access and management of systems. Typically, it operates over port 22. However, adversaries may exploit non-standard ports to evade detection and bypass network filters. The detection rule identifies unusual SSH activity by monitoring processes and network connections on ports other than 22, excluding common benign use cases, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details, including process.entity_id and process.name, to confirm the execution of SSH or SSHD processes and identify any unusual parent processes not listed in the exclusion list.
+- Examine the network connection details, focusing on destination.port to verify the use of non-standard ports for SSH connections and assess if these ports are commonly used within the organization.
+- Analyze the destination.ip to determine if the connection is being made to an external or potentially malicious IP address, especially if it falls outside the specified CIDR ranges.
+- Investigate the context of the SSH connection attempt by checking for any recent changes in network configurations or firewall rules that might explain the use of non-standard ports.
+- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity.
+
+### False positive analysis
+
+- Legitimate administrative tools like rsync, git, and ansible-playbook may use SSH over non-standard ports for valid operations. Ensure these tools are included in the process.parent.name exclusion list to prevent false positives.
+- Backup and synchronization applications such as pyznap and pgbackrest might use SSH on non-standard ports. Add these applications to the exclusion list to avoid unnecessary alerts.
+- Development and deployment tools like Sourcetree and git-lfs may establish SSH connections on non-standard ports during routine operations. Verify these tools are part of the exclusion criteria to minimize false positives.
+- Custom scripts or automation tasks that use SSH on non-standard ports for internal processes should be reviewed and, if deemed safe, added to the exclusion list to reduce noise.
+- Internal network traffic to non-public IP ranges might be flagged if not properly excluded. Ensure that internal IP ranges are correctly specified in the cidrmatch exclusion to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious SSH processes identified on non-standard ports to halt potential malicious activity.
+- Conduct a thorough review of the system's SSH configuration files to identify unauthorized changes, such as modifications to the SSH port settings, and revert them to the standard configuration.
+- Reset credentials for any accounts accessed via the non-standard port to prevent further unauthorized access.
+- Implement network-level controls to block SSH traffic on non-standard ports unless explicitly required and documented for legitimate use cases.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Enhance monitoring and alerting for SSH connections on non-standard ports across the network to improve early detection of similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
index 3a940510079..3e89eb92165 100644
--- a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
+++ b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/05/28"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,41 @@ process where event.type in ("start", "process_started", "info") and
                    "--remote-debugging-pipe=*") and
    process.args : "--user-data-dir=*" and not process.args:"--remote-debugging-port=0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Cookies Theft via Browser Debugging
+
+Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate cookie theft attempts, by monitoring specific process names and arguments across different operating systems.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious debugging arguments such as "--remote-debugging-port=*", "--remote-debugging-targets=*", or "--remote-debugging-pipe=*". Check if these arguments were used in conjunction with "--user-data-dir=*" and ensure "--remote-debugging-port=0" is not present.
+- Identify the user account associated with the suspicious browser process to determine if it aligns with expected behavior or if it might be compromised.
+- Investigate the source IP address and network activity associated with the process to identify any unusual or unauthorized access patterns.
+- Check for any recent changes or anomalies in the user's account activity, such as unexpected logins or access to sensitive applications.
+- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign.
+- If possible, capture and analyze the network traffic associated with the process to detect any data exfiltration attempts or communication with known malicious IP addresses.
+
+### False positive analysis
+
+- Development and testing activities may trigger the rule when developers use debugging features for legitimate purposes. To manage this, create exceptions for known developer machines or user accounts frequently involved in web application development.
+- Automated testing frameworks that utilize browser debugging for testing web applications can also cause false positives. Identify and exclude processes initiated by these frameworks by specifying their unique process names or user accounts.
+- Browser extensions or tools that rely on debugging ports for functionality might be flagged. Review and whitelist these extensions or tools if they are verified as safe and necessary for business operations.
+- Remote support or troubleshooting sessions using debugging features can be mistaken for suspicious activity. Implement a policy to log and review such sessions, allowing exceptions for recognized support tools or personnel.
+- Continuous integration/continuous deployment (CI/CD) pipelines that involve browser automation may inadvertently match the rule criteria. Exclude these processes by identifying and filtering based on the CI/CD system's user accounts or process identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious browser processes identified with debugging arguments to stop potential cookie theft in progress.
+- Conduct a thorough review of access logs for the affected web applications or services to identify any unauthorized access attempts using stolen cookies.
+- Invalidate all active sessions for the affected user accounts and force a re-authentication to ensure that any stolen session cookies are rendered useless.
+- Implement stricter browser security policies, such as disabling remote debugging features in production environments, to prevent similar exploitation in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Enhance monitoring and alerting for similar suspicious browser activities by refining detection rules and incorporating additional threat intelligence."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/credential_access_forced_authentication_pipes.toml b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
index db0ec420cba..261a87ce870 100644
--- a/rules/cross-platform/credential_access_forced_authentication_pipes.toml
+++ b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/23"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2024/10/01"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ sequence with maxspan=15s
 [network where host.os.type == "linux" and event.action == "connection_attempted" and destination.port == 445 and not startswith~(string(destination.ip), string(host.ip))] by host.ip, data_stream.namespace
 [file where host.os.type == "windows" and event.code == "5145" and file.name : ("Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc")] by source.ip, data_stream.namespace
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Active Directory Forced Authentication from Linux Host - SMB Named Pipes
+
+Active Directory (AD) and SMB named pipes facilitate network resource access and inter-process communication. Adversaries exploit these by forcing authentication from a Linux host to capture credentials or perform relay attacks. The detection rule identifies suspicious SMB connection attempts from Linux to Windows hosts, focusing on specific named pipes indicative of forced authentication attempts, thus highlighting potential credential access threats.
+
+### Possible investigation steps
+
+- Review the network logs to identify the Linux host IP address that attempted the SMB connection on port 445 and verify if this activity is expected or authorized.
+- Check the Windows host logs for event code 5145 to determine which named pipes were accessed and assess if these accesses align with normal operations or indicate suspicious activity.
+- Investigate the source IP address from the Windows logs to determine if it matches the Linux host IP and evaluate if this connection is part of a known and legitimate process.
+- Analyze historical data for any previous similar connection attempts from the same Linux host to identify patterns or repeated unauthorized access attempts.
+- Consult with system administrators to confirm if there have been any recent changes or updates in the network configuration that could explain the connection attempts.
+
+### False positive analysis
+
+- Routine administrative tasks from Linux hosts may trigger alerts. Identify and document these tasks to create exceptions for known IP addresses or hostnames involved in regular operations.
+- Automated backup or monitoring systems that connect to Windows hosts using SMB may cause false positives. Review and whitelist these systems by their IP addresses or specific named pipes they access.
+- Development or testing environments where Linux hosts frequently interact with Windows systems can generate alerts. Establish a separate monitoring policy or exclude these environments from the rule to reduce noise.
+- Security tools or scripts that perform network scans or audits might mimic suspicious behavior. Verify these tools and exclude their activities by specifying their source IPs or associated user accounts.
+- Cross-platform file sharing services that use SMB for legitimate purposes may be flagged. Identify these services and adjust the rule to ignore their specific connection patterns or named pipes.
+
+### Response and remediation
+
+- Isolate the affected Linux host from the network to prevent further unauthorized SMB connection attempts and potential credential capture.
+- Conduct a thorough review of the Linux host's network activity logs to identify any unauthorized access or data exfiltration attempts.
+- Reset passwords for any accounts that may have been exposed or compromised during the forced authentication attempt to mitigate the risk of credential misuse.
+- Implement network segmentation to limit SMB traffic between Linux and Windows hosts, reducing the attack surface for similar threats.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional hosts or systems are affected.
+- Deploy enhanced monitoring on the identified named pipes and associated network traffic to detect and respond to future forced authentication attempts promptly.
+- Review and update firewall rules to restrict unnecessary SMB traffic and ensure only authorized systems can communicate over port 445."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
index 0387b769dc3..c7671e0e134 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,41 @@ type = "query"
 query = '''
 event.agent_id_status:(agent_id_mismatch or mismatch)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Agent Spoofing - Mismatched Agent ID
+
+In security environments, agent IDs uniquely identify software agents that report events. Adversaries may spoof these IDs to disguise unauthorized activities, evading detection systems. The detection rule identifies discrepancies between expected and actual agent IDs, flagging potential spoofing attempts. By monitoring for mismatches, it helps uncover efforts to masquerade malicious actions as legitimate.
+
+### Possible investigation steps
+
+- Review the event logs to identify the specific events where the agent_id_status is marked as "agent_id_mismatch" or "mismatch" to understand the scope and frequency of the issue.
+- Correlate the mismatched agent IDs with the associated API keys to determine if there are any patterns or commonalities that could indicate a targeted spoofing attempt.
+- Investigate the source IP addresses and user accounts associated with the mismatched events to identify any unauthorized access or suspicious activity.
+- Check for any recent changes or anomalies in the configuration or deployment of agents that could explain the mismatches, such as updates or reassignments.
+- Analyze historical data to determine if similar mismatches have occurred in the past and whether they were resolved or linked to known issues or threats.
+- Consult with the IT or security team to verify if there are any legitimate reasons for the agent ID discrepancies, such as testing or maintenance activities.
+
+### False positive analysis
+
+- Legitimate software updates or patches may temporarily cause agent ID mismatches. Users should verify if the mismatches coincide with scheduled updates and consider excluding these events if confirmed.
+- Network configuration changes, such as IP address reassignments, can lead to mismatches. Ensure that network changes are documented and correlate with the mismatched events before excluding them.
+- Virtual machine snapshots or clones might result in duplicate agent IDs. Users should track virtual machine activities and exclude events from known snapshot or cloning operations.
+- Load balancing or failover processes in high-availability environments can cause agent ID discrepancies. Review the infrastructure setup and exclude events that align with these processes.
+- Testing environments often simulate various agent activities, leading to mismatches. Clearly separate test environments from production in monitoring systems and exclude test-related events.
+
+### Response and remediation
+
+- Immediately isolate the affected systems to prevent further unauthorized access or data exfiltration. This can be done by disconnecting the system from the network or using network segmentation techniques.
+- Conduct a thorough review of the logs and events associated with the mismatched agent ID to identify any unauthorized changes or activities. Focus on the specific events flagged by the detection rule.
+- Revoke and reissue API keys associated with the compromised agent ID to prevent further misuse. Ensure that new keys are distributed securely and only to authorized personnel.
+- Implement additional monitoring on the affected systems and related network segments to detect any further attempts at agent ID spoofing or other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat actor has compromised other parts of the network.
+- Review and update access controls and authentication mechanisms to ensure that only legitimate agents can report events. Consider implementing multi-factor authentication for added security.
+- Document the incident, including all actions taken, and conduct a post-incident review to identify any gaps in detection or response. Use this information to enhance future threat detection and response capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
index 0a5ee5c15a7..309dd1326ac 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2024/06/14"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,40 @@ type = "threshold"
 query = '''
 event.agent_id_status:* and not tags:forwarded
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Agent Spoofing - Multiple Hosts Using Same Agent
+
+In network environments, agents are deployed on hosts to monitor and report activities. Adversaries may exploit these agents by hijacking their IDs to inject false data, masking malicious actions. The detection rule identifies anomalies where multiple hosts report using the same agent ID, signaling potential spoofing attempts. By focusing on unique agent ID usage, it helps uncover evasion tactics aimed at concealing unauthorized activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific agent ID that is being reported by multiple hosts.
+- Cross-reference the agent ID with the list of known and authorized agents to determine if it has been compromised or misconfigured.
+- Examine the network logs and host activity for each host reporting the same agent ID to identify any unusual or unauthorized activities.
+- Check for any recent changes or updates to the agent software on the affected hosts that could explain the anomaly.
+- Investigate the timeline of events to determine when the agent ID started being used by multiple hosts and correlate this with any known incidents or changes in the network environment.
+- Assess the potential impact of the spoofing attempt on the network's security posture and consider isolating affected hosts if necessary to prevent further malicious activity.
+
+### False positive analysis
+
+- Legitimate load balancing or failover scenarios where multiple hosts are configured to use the same agent ID for redundancy can trigger false positives. Users should identify and document these configurations, then create exceptions in the detection rule to exclude these known non-threatening behaviors.
+- Virtualized environments where snapshots or clones of a host are created might result in multiple instances reporting the same agent ID. Users should ensure that each virtual instance is assigned a unique agent ID or adjust the rule to account for these scenarios.
+- Testing or development environments where agents are intentionally duplicated for testing purposes can also lead to false positives. Users should tag these environments appropriately and modify the rule to exclude events from these tags.
+- In cases where agents are temporarily reassigned to different hosts for maintenance or troubleshooting, users should maintain a log of these activities and adjust the detection rule to ignore these temporary changes.
+
+### Response and remediation
+
+- Isolate affected hosts immediately to prevent further spread of potentially malicious activities across the network.
+- Revoke and reissue new agent IDs for the affected hosts to ensure that compromised IDs are no longer in use.
+- Conduct a thorough forensic analysis on the isolated hosts to identify any unauthorized changes or malicious software that may have been introduced.
+- Review and update access controls and authentication mechanisms for agent deployment to prevent unauthorized access and hijacking of agent IDs.
+- Monitor network traffic and logs closely for any signs of continued spoofing attempts or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders to ensure awareness and coordinated response efforts.
+- Implement enhanced logging and alerting for agent ID anomalies to improve detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
index 27c9ce51e5b..2c42306a998 100644
--- a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
+++ b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,40 @@ file where event.type == "deletion" and
                "/var/log/httpd/access_log",
                "/var/www/*/logs/access.log")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WebServer Access Logs Deleted
+
+Web server access logs are crucial for monitoring and analyzing web traffic, providing insights into user activity and potential security incidents. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies log deletions across various operating systems by monitoring specific file paths, signaling potential attempts at evasion or evidence destruction.
+
+### Possible investigation steps
+
+- Review the specific file path where the deletion event was detected to determine which web server's logs were affected, using the file.path field from the alert.
+- Check for any recent access or modification events on the affected web server to identify potential unauthorized access or suspicious activity prior to the log deletion.
+- Investigate user accounts and processes that had access to the deleted log files around the time of the deletion event to identify potential malicious actors or compromised accounts.
+- Correlate the log deletion event with other security alerts or anomalies in the same timeframe to identify patterns or related incidents.
+- Examine backup logs or alternative logging mechanisms, if available, to recover deleted information and assess the impact of the log deletion on forensic capabilities.
+
+### False positive analysis
+
+- Routine log rotation or maintenance scripts may delete old web server logs. To handle this, identify and exclude these scheduled tasks from triggering alerts by specifying their execution times or associated process names.
+- Automated backup processes that move or delete logs after archiving can trigger false positives. Exclude these processes by adding exceptions for the backup software or scripts used.
+- Development or testing environments where logs are frequently cleared to reset the environment can cause alerts. Consider excluding these environments by specifying their IP addresses or hostnames.
+- System administrators manually deleting logs as part of regular maintenance can be mistaken for malicious activity. Implement a policy to log and approve such actions, and exclude these approved activities from detection.
+- Temporary log deletions during server migrations or upgrades might trigger alerts. Document these events and create temporary exceptions during the migration period.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of recent user activity and system changes to identify any unauthorized access or modifications that may have led to the log deletion.
+- Restore the deleted web server access logs from backups, if available, to aid in further forensic analysis and investigation.
+- Implement enhanced monitoring on the affected system to detect any further attempts at log deletion or other suspicious activities.
+- Review and tighten access controls and permissions on log files to ensure only authorized personnel can modify or delete them.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Document the incident, including all actions taken, and update incident response plans to improve future detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
index d741251924d..4f7ff590fac 100644
--- a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
+++ b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,40 @@ process where event.action in ("exec", "exec_event", "executed", "process_starte
   (process.args : "set" and process.args : "history" and process.args : "+o")
  )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Tampering of Shell Command-Line History
+
+Shell command-line history is a crucial feature in Unix-like systems, recording user commands for convenience and auditing. Adversaries may manipulate this history to hide their tracks, using commands to delete or redirect history files, clear history buffers, or disable history logging. The detection rule identifies such tampering by monitoring for suspicious command patterns and arguments indicative of history manipulation attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the user account associated with the suspicious command, focusing on the process.args field to determine the specific command and arguments used.
+- Check the process execution timeline to correlate the suspicious activity with other events on the system, such as logins or file modifications, to understand the context of the tampering attempt.
+- Investigate the command history files (.bash_history, .zsh_history) for the affected user accounts to assess the extent of tampering and identify any commands that may have been executed prior to the history manipulation.
+- Examine system logs and audit records for any additional indicators of compromise or related suspicious activities, such as unauthorized access attempts or privilege escalation events.
+- Verify the current configuration of the HISTFILE and HISTFILESIZE environment variables for the affected user accounts to ensure they have not been altered to disable history logging.
+
+### False positive analysis
+
+- System administrators or automated scripts may clear command-line history as part of routine maintenance or privacy measures. To handle this, identify and whitelist known scripts or user accounts that perform these actions regularly.
+- Developers or power users might redirect or unset history files to manage disk space or for personal preference. Consider excluding specific user accounts or directories from monitoring if these actions are verified as non-malicious.
+- Security tools or compliance scripts may execute commands that resemble history tampering to ensure systems are in a desired state. Review and exclude these tools from triggering alerts by adding them to an exception list.
+- Temporary testing environments or sandboxed systems might frequently clear history as part of their reset processes. Exclude these environments from the rule to prevent unnecessary alerts.
+- Users with privacy concerns might intentionally disable history logging. Engage with these users to understand their needs and adjust monitoring policies accordingly, possibly by excluding their sessions from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further tampering or data exfiltration.
+- Conduct a thorough review of the affected user's recent command history and system logs to identify any unauthorized or suspicious activities that may have occurred prior to the tampering.
+- Restore the tampered history files from a secure backup, if available, to aid in further forensic analysis and ensure continuity of auditing.
+- Re-enable and secure shell history logging by resetting the HISTFILE and HISTFILESIZE environment variables to their default values and ensuring they are not set to null or zero.
+- Implement stricter access controls and monitoring on the affected system to prevent unauthorized users from modifying shell history files in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may have been compromised.
+- Review and update endpoint detection and response (EDR) configurations to enhance monitoring for similar tampering attempts, ensuring alerts are generated for any future suspicious command patterns."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
index 655695f3cae..9bd55b5a8e5 100644
--- a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
+++ b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ or
     process.args : "com.apple.iokit.EndpointSecurity" and
     event.action : "end"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Elastic Agent Service Terminated
+
+The Elastic Agent is a crucial component for monitoring and securing endpoints across various operating systems. It ensures continuous security oversight by collecting and analyzing data. Adversaries may attempt to disable this agent to evade detection, compromising system defenses. The detection rule identifies suspicious termination activities by monitoring specific processes and commands across Windows, Linux, and macOS, flagging potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the event logs to identify the exact process and command used to terminate the Elastic Agent, focusing on the process names and arguments such as "net.exe", "sc.exe", "systemctl", and "pkill" with arguments like "stop", "uninstall", or "disable".
+- Check the timeline of events around the termination to identify any preceding suspicious activities or anomalies that might indicate an adversary's presence or actions.
+- Investigate the user account associated with the process termination to determine if it was authorized or if there are signs of account compromise.
+- Examine the host for any other signs of tampering or compromise, such as unauthorized changes to system configurations or the presence of other malicious processes.
+- Verify the current status of the Elastic Agent on the affected host and attempt to restart it if it is not running, ensuring that security monitoring is restored.
+- Correlate this event with other alerts or logs from the same host or network to identify potential patterns or coordinated attack activities.
+
+### False positive analysis
+
+- Routine maintenance activities may trigger the rule if administrators use commands like systemctl or service to stop the Elastic Agent for updates or configuration changes. To manage this, create exceptions for known maintenance windows or authorized personnel.
+- Automated scripts or deployment tools that temporarily disable the Elastic Agent during software installations or updates can cause false positives. Identify these scripts and whitelist their execution paths or specific arguments.
+- Testing environments where Elastic Agent is frequently started and stopped for development purposes might generate alerts. Exclude these environments by specifying their hostnames or IP addresses in the rule exceptions.
+- Security tools or processes that interact with the Elastic Agent, such as backup solutions or system monitoring tools, might inadvertently stop the service. Review these interactions and adjust the rule to ignore specific process names or arguments associated with these tools.
+- User-initiated actions, such as troubleshooting or system performance optimization, may involve stopping the Elastic Agent. Educate users on the impact of these actions and establish a protocol for notifying the security team when such actions are necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by adversaries.
+- Verify the status of the Elastic Agent on the affected host and attempt to restart the service. If the service fails to restart, investigate potential causes such as corrupted files or missing dependencies.
+- Conduct a thorough review of recent process execution logs on the affected host to identify any unauthorized or suspicious activities that may have led to the termination of the Elastic Agent.
+- If malicious activity is confirmed, perform a comprehensive malware scan and remove any identified threats. Ensure that the host is clean before reconnecting it to the network.
+- Review and update endpoint security configurations to prevent unauthorized termination of security services. This may include implementing stricter access controls or using application whitelisting.
+- Escalate the incident to the security operations team for further analysis and to determine if additional hosts are affected or if there is a broader security incident underway.
+- Document the incident, including all actions taken and findings, to enhance future response efforts and update incident response plans as necessary."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
index 81c67c2d202..12f23a5ee47 100644
--- a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
+++ b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,40 @@ sequence by process.entity_id with maxspan=1m
  [file where host.os.type in ("windows", "macos") and
   event.action != "deletion" and process.name : "python*" and file.name : "rot_??.cpython-*.pyc*"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 ROT Encoded Python Script Execution
+
+ROT encoding, a simple letter substitution cipher, is often used to obfuscate Python scripts, making them harder to analyze. Adversaries exploit this by embedding ROT-encoded scripts within legitimate packages to evade detection. The detection rule identifies such activities by monitoring Python script executions and the presence of ROT-encoded compiled files, flagging potential misuse on Windows and macOS systems.
+
+### Possible investigation steps
+
+- Review the process entity ID to identify the specific Python process that triggered the alert and gather details such as the process start time and command line arguments.
+- Examine the file path and name of the ROT-encoded compiled file (e.g., "rot_??.cpython-*.pyc") to determine its origin and whether it is part of a legitimate package or potentially malicious.
+- Check the parent process of the Python script to understand how it was initiated and whether it was executed by a legitimate application or user.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Analyze any network connections or file modifications made by the Python process to identify potential data exfiltration or further malicious activity.
+- Correlate this alert with other security events or logs from the same host to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Legitimate development activities may trigger the rule if developers use ROT encoding for testing or educational purposes. To manage this, create exceptions for known development environments or specific user accounts involved in such activities.
+- Automated scripts or tools that use ROT encoding for legitimate data processing tasks can be flagged. Identify these scripts and whitelist their execution paths or associated process names to prevent false alerts.
+- Some security tools or software may use ROT encoding as part of their normal operations. Review and document these tools, then configure the detection system to exclude their known file paths or process identifiers.
+- Regularly scheduled tasks or cron jobs that involve ROT-encoded files for non-malicious purposes can cause false positives. Exclude these tasks by specifying their unique identifiers or execution schedules in the detection rule settings.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious activity.
+- Terminate any running Python processes that are identified as executing ROT-encoded scripts to halt the execution of obfuscated code.
+- Conduct a thorough review of the affected system to identify and remove any ROT-encoded Python files, specifically targeting files matching the pattern "rot_??.cpython-*.pyc*".
+- Restore any affected systems from a known good backup to ensure the removal of any persistent threats.
+- Implement application whitelisting to prevent unauthorized Python scripts from executing, focusing on blocking scripts with ROT encoding patterns.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Update detection mechanisms to monitor for similar ROT-encoded script activities, enhancing the ability to detect and respond to future threats."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
index 4b46332364f..ba427f0d623 100644
--- a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
+++ b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,40 @@ process.executable regex~ """/[a-z0-9\s_\-\\./]+\s""" and not (
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Masquerading Space After Filename
+
+In Linux and macOS environments, file execution is determined by the file's true type rather than its extension. Adversaries exploit this by appending a space to filenames, misleading users into executing malicious files disguised as benign. The detection rule identifies such anomalies by monitoring process creation events with filenames ending in a space, excluding known safe processes and paths, thus highlighting potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the process creation event details to identify the full path and name of the executable with a space appended. This can help determine if the file is located in a suspicious or unusual directory.
+- Check the process.parent.args field to understand the parent process that initiated the execution. This can provide context on whether the execution was part of a legitimate process chain or potentially malicious activity.
+- Investigate the user account associated with the process creation event to determine if the account has a history of executing similar files or if it has been compromised.
+- Examine the file's true type and hash to verify its legitimacy and check against known malicious file databases or threat intelligence sources.
+- Look for any additional process events or network activity associated with the suspicious executable to identify potential lateral movement or data exfiltration attempts.
+- Cross-reference the event with any recent alerts or incidents involving the same host or user to identify patterns or ongoing threats.
+
+### False positive analysis
+
+- Processes like "ls", "find", "grep", and "xkbcomp" are known to be safe and can be excluded from triggering the rule by adding them to the exception list.
+- Executables located in directories such as "/opt/nessus_agent/*", "/opt/gitlab/sv/gitlab-exporter/*", and "/tmp/ansible-admin/*" are typically non-threatening and should be excluded to prevent false positives.
+- Parent processes with arguments like "./check_rubrik", "/usr/bin/check_mk_agent", "/etc/rubrik/start_stop_bootstrap.sh", and "/etc/rubrik/start_stop_agent.sh" are generally safe and can be added to the exclusion list to avoid unnecessary alerts.
+- Regularly review and update the exception list to ensure that only verified safe processes and paths are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution or spread of the potentially malicious file.
+- Terminate any suspicious processes identified by the detection rule to halt any ongoing malicious activity.
+- Conduct a forensic analysis of the file with the appended space to determine its true file type and origin, using tools like file command or hex editors.
+- Remove the malicious file from the system and any other locations it may have been copied to, ensuring complete eradication.
+- Review and update endpoint protection settings to block execution of files with suspicious naming conventions, such as those ending with a space.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess potential impacts on other systems.
+- Implement additional monitoring for similar masquerading attempts by enhancing logging and alerting mechanisms to detect files with unusual naming patterns."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/cross-platform/defense_evasion_timestomp_touch.toml b/rules/cross-platform/defense_evasion_timestomp_touch.toml
index 36d4a8ca911..c38092ddf24 100644
--- a/rules/cross-platform/defense_evasion_timestomp_touch.toml
+++ b/rules/cross-platform/defense_evasion_timestomp_touch.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,39 @@ process where event.type == "start" and
    "/usr/lib/go-*/bin/go", "/usr/lib/dracut/dracut-functions.sh", "/tmp/KSInstallAction.*/m/.patch/*"
 ) and not process.parent.name in ("pmlogger_daily", "pmlogger_janitor", "systemd")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Timestomping using Touch Command
+
+Timestomping is a technique used by adversaries to alter file timestamps, making malicious files blend with legitimate ones. The 'touch' command, prevalent in Linux and macOS, can modify access and modification times. Attackers exploit this to evade detection. The detection rule identifies suspicious 'touch' usage by non-root users, focusing on specific arguments and excluding benign processes, thus highlighting potential timestomping activities.
+
+### Possible investigation steps
+
+- Review the process details to identify the user who executed the 'touch' command, focusing on the user.id field to determine if the user is legitimate and authorized to perform such actions.
+- Examine the process.args field to understand the specific arguments used with the 'touch' command, particularly looking for the use of "-r", "-t", "-a*", or "-m*" which indicate potential timestomping activity.
+- Investigate the parent process of the 'touch' command by checking the process.parent.name field to determine if it was initiated by a suspicious or unexpected process, excluding known benign processes like "pmlogger_daily", "pmlogger_janitor", and "systemd".
+- Cross-reference the file paths and names involved in the 'touch' command with known system files and directories to assess if the files are legitimate or potentially malicious.
+- Check for any recent alerts or logs related to the same user or process to identify patterns or repeated attempts at timestomping or other suspicious activities.
+
+### False positive analysis
+
+- Non-root users running legitimate scripts or applications that use the touch command with similar arguments may trigger false positives. To mitigate this, identify and whitelist these specific scripts or applications by adding their paths to the exclusion list.
+- Automated system maintenance tasks that involve file timestamp modifications can be mistaken for malicious activity. Review and exclude known maintenance processes by adding them to the exclusion criteria, ensuring they do not match the suspicious argument patterns.
+- Development tools or environments that utilize the touch command for file management during build processes might be flagged. Analyze these tools and exclude their typical usage patterns by specifying their paths or parent processes in the exclusion list.
+- User-initiated file management activities, such as organizing or backing up files, can inadvertently match the rule's criteria. Educate users on the implications of using touch with specific arguments and consider excluding common user directories from the rule if they are frequently involved in such activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker.
+- Conduct a thorough review of the affected system's file system to identify and document any files with suspicious timestamp modifications, focusing on those altered by non-root users.
+- Restore any critical files with altered timestamps from known good backups to ensure data integrity and system reliability.
+- Revoke or reset credentials for any non-root users involved in the suspicious 'touch' command activity to prevent unauthorized access.
+- 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 enhanced monitoring on the affected system and similar environments to detect any further attempts at timestomping or related suspicious activities.
+- Review and update access controls and permissions to ensure that only authorized users have the ability to modify file timestamps, reducing the risk of future timestomping attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
index 2ef727a4d0a..1cc57c63f10 100644
--- a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
+++ b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,39 @@ process where event.type == "start" and
  process.args : ("parallels*", "vmware*", "virtualbox*") and process.args : "Manufacturer*" and
  not process.parent.executable in ("/Applications/Docker.app/Contents/MacOS/Docker", "/usr/libexec/kcare/virt-what")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Virtual Machine Fingerprinting via Grep
+
+Virtual machine fingerprinting involves identifying virtualized environments by querying system details. Adversaries exploit tools like `grep` to extract information about virtual machine hardware, aiding in evasion or targeting. The detection rule identifies non-root users executing `grep` with arguments linked to virtual machine identifiers, flagging potential reconnaissance activities while excluding benign processes.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the non-root user who initiated the `grep` or `egrep` command and assess their typical behavior and access rights.
+- Examine the command-line arguments used with `grep` to identify specific virtual machine identifiers such as "parallels", "vmware", or "virtualbox" and determine if these align with known reconnaissance patterns.
+- Investigate the parent process of the `grep` command to understand the context in which it was executed, ensuring it is not a benign process like Docker or kcare.
+- Check for any additional suspicious activities or commands executed by the same user around the same time to identify potential lateral movement or further reconnaissance.
+- Correlate this event with other security alerts or logs to determine if it is part of a broader attack pattern or campaign, particularly looking for connections to known malware like Pupy RAT.
+
+### False positive analysis
+
+- Non-root users running legitimate scripts or applications that query virtual machine identifiers for system management or inventory purposes may trigger the rule. To handle this, identify and whitelist these specific scripts or applications by excluding their parent executable paths.
+- Developers or IT personnel using grep to troubleshoot or gather system information on virtual machines might be flagged. Create exceptions for known user accounts or specific directories where these activities are expected.
+- Automated monitoring tools that check virtual machine environments for compliance or performance metrics could cause false positives. Exclude these tools by adding their process names or parent executables to the exception list.
+- Some virtualization management software might use grep internally to gather system information. Identify these applications and exclude their processes to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further reconnaissance or data exfiltration by the adversary.
+- Terminate any suspicious processes identified by the alert, specifically those involving `grep` or `egrep` with arguments related to virtual machine identifiers.
+- Conduct a thorough review of the affected system's user accounts and permissions, focusing on non-root users, to identify any unauthorized access or privilege escalation.
+- Analyze system logs and network traffic for any signs of lateral movement or additional compromise, paying close attention to connections initiated by the affected system.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise.
+- Implement stricter access controls and monitoring for systems running virtual machines, including enhanced logging and alerting for similar reconnaissance activities.
+- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
index ee87869d33c..21b713c7133 100644
--- a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
+++ b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/03"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -86,6 +86,41 @@ and process.args: (
     and ("AWS-RunShellScript" or "AWS-RunPowerShellScript")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS SSM `SendCommand` with Run Shell Command Parameters
+
+AWS Systems Manager (SSM) allows remote command execution on EC2 instances via the `SendCommand` API, using scripts like `AWS-RunShellScript` or `AWS-RunPowerShellScript`. Adversaries may exploit this to execute unauthorized commands without direct access. The detection rule identifies unusual command executions by monitoring process activities, flagging first-time occurrences within a week to spot potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific EC2 instance and the user account associated with the `SendCommand` API call.
+- Check the AWS CloudTrail logs for the `SendCommand` event to gather additional context, such as the source IP address, user agent, and any associated IAM roles or policies.
+- Investigate the command parameters used in the `SendCommand` API call, focusing on the `commands` field to determine the nature and intent of the executed script.
+- Examine the process execution history on the affected host to identify any unusual or unauthorized processes that may have been initiated as a result of the command.
+- Assess the recent activity of the user account involved in the alert to identify any other suspicious actions or deviations from normal behavior.
+- Verify the integrity and security posture of the affected EC2 instance, checking for any signs of compromise or unauthorized changes.
+
+### False positive analysis
+
+- Routine administrative tasks using AWS SSM SendCommand may trigger alerts. Identify and document regular maintenance scripts and exclude them from detection to reduce noise.
+- Automated deployment processes often use AWS-RunShellScript or AWS-RunPowerShellScript. Review deployment logs and whitelist these processes if they are verified as non-threatening.
+- Monitoring or compliance checks that utilize SSM for gathering system information can be mistaken for malicious activity. Confirm these activities with the relevant teams and create exceptions for known benign operations.
+- Scheduled tasks or cron jobs that execute commands via SSM should be reviewed. If they are part of standard operations, consider excluding them from the rule to prevent false positives.
+- Development and testing environments frequently use SSM for testing scripts. Ensure these environments are well-documented and apply exceptions to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution and potential lateral movement.
+- Review the AWS CloudTrail logs to identify the source of the `SendCommand` API call, including the IAM user or role that initiated the command, and assess whether the access was legitimate or compromised.
+- Revoke or rotate the credentials of the IAM user or role involved in the suspicious activity to prevent further unauthorized access.
+- Conduct a thorough examination of the affected EC2 instance to identify any unauthorized changes or installed malware, and restore the instance from a known good backup if necessary.
+- Implement stricter IAM policies and permissions to limit the use of the `SendCommand` API to only trusted users and roles, ensuring the principle of least privilege is enforced.
+- Enable multi-factor authentication (MFA) for all IAM users with permissions to execute commands on EC2 instances to add an additional layer of security.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources have been compromised."""
 
 [rule.investigation_fields]
 field_names = [
diff --git a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
index f97739824da..984a176abde 100644
--- a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
+++ b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,40 @@ type = "query"
 query = '''
 event.category:process and event.type:(process_started or start) and process.name:espl and process.args:eyJkZWJ1ZyI6*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 EggShell Backdoor Execution
+
+EggShell is a post-exploitation tool used on macOS and Linux systems, allowing adversaries to execute commands and scripts remotely. It leverages command and scripting interpreters to gain control over compromised systems. Attackers exploit this by executing malicious payloads, maintaining persistence, and exfiltrating data. The detection rule identifies suspicious process activities, specifically targeting the execution patterns and arguments associated with EggShell, to alert analysts of potential backdoor usage.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the process name 'espl' and check if the process arguments start with 'eyJkZWJ1ZyI6', which indicates potential EggShell activity.
+- Investigate the parent process of 'espl' to understand how it was initiated and identify any associated suspicious activities or processes.
+- Examine the user account under which the 'espl' process was executed to determine if it aligns with expected behavior or if it indicates a compromised account.
+- Check for any network connections or data exfiltration attempts associated with the 'espl' process to assess if data has been sent to an external source.
+- Review system logs and other security alerts around the time of the 'espl' process execution to identify any correlated events or anomalies.
+- Assess the persistence mechanisms on the affected system to determine if the EggShell backdoor has established any means to survive reboots or user logouts.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools that use similar command patterns to EggShell may trigger false positives. Review the process arguments and context to determine if the activity is expected and authorized.
+- Development or testing environments where EggShell or similar tools are used for legitimate purposes can cause alerts. Implement exceptions for these environments by excluding specific user accounts or process paths.
+- Automated scripts or monitoring tools that mimic EggShell's execution patterns might be flagged. Identify these scripts and create exceptions based on their unique identifiers or execution context.
+- Regularly update the detection rule to refine the criteria based on observed false positives, ensuring that legitimate activities are not continuously flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further command execution and data exfiltration.
+- Terminate any suspicious processes associated with the EggShell backdoor, specifically those matching the process name 'espl' and arguments starting with 'eyJkZWJ1ZyI6'.
+- Conduct a thorough examination of the system to identify any additional malicious payloads or persistence mechanisms that may have been deployed by the attacker.
+- Remove any unauthorized user accounts or access credentials that may have been created or compromised during the exploitation.
+- Restore the system from a known good backup to ensure all traces of the backdoor and any associated malware are eradicated.
+- Update and patch all software and systems to close any vulnerabilities that may have been exploited by the attacker.
+- Enhance monitoring and detection capabilities to identify similar threats in the future, focusing on command and scripting interpreter activities as outlined in MITRE ATT&CK technique T1059."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_potential_widespread_malware_infection.toml b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
index 99d34658172..0654843e9bf 100644
--- a/rules/cross-platform/execution_potential_widespread_malware_infection.toml
+++ b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/08"
 maturity = "production"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
 
@@ -38,6 +38,41 @@ from logs-endpoint.alerts-*
 | stats hosts = count_distinct(host.id) by rule.name, event.code
 | where hosts >= 3
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Widespread Malware Infection Across Multiple Hosts
+
+Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific rule.name and event.code that triggered the alert, focusing on those with a high count of distinct host.id values.
+- Correlate the identified rule.name with known malware signatures or recent threat intelligence reports to understand the potential impact and behavior of the malware.
+- Examine the affected host.id entries to determine if there are any commonalities, such as shared network segments, user accounts, or software versions, that could indicate the initial infection vector.
+- Investigate the timeline of events for each affected host to identify any suspicious activities or anomalies preceding the alert, such as unusual file downloads or execution of unknown processes.
+- Check for any additional alerts or logs related to the same host.id entries to assess if there are other indicators of compromise or related malicious activities.
+- Coordinate with IT and security teams to isolate affected hosts if necessary, and initiate containment and remediation procedures based on the findings.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger malware signatures, especially if they involve new or uncommon software. Users can create exceptions for known software update processes to prevent these alerts from being flagged as potential threats.
+- Security testing tools or penetration testing activities might mimic malware behavior, leading to false positives. Analysts should coordinate with IT and security teams to whitelist these activities during scheduled tests.
+- Custom scripts or administrative tools that perform automated tasks across multiple hosts can be mistaken for malicious activity. Identifying and excluding these scripts from the rule can reduce unnecessary alerts.
+- Frequent use of remote management tools that execute scripts or commands on multiple hosts may trigger alerts. Users should ensure these tools are recognized and excluded from the rule to avoid false positives.
+- Known benign applications that use shellcode or memory manipulation techniques for legitimate purposes should be reviewed and added to an exception list to prevent them from being flagged.
+
+### Response and remediation
+
+- Isolate affected hosts immediately to prevent further spread of the malware across the network. This can be done by disconnecting them from the network or using network segmentation techniques.
+- Conduct a thorough scan of the isolated hosts using updated antivirus or endpoint detection and response (EDR) tools to identify and remove the malicious files or processes associated with the detected signatures.
+- Analyze the identified malware to understand its behavior and entry points. This will help in determining if additional hosts may be compromised and require similar remediation actions.
+- Apply security patches and updates to all affected systems to close any vulnerabilities that the malware may have exploited.
+- Restore affected systems from clean backups if the malware has caused significant damage or if the integrity of the system cannot be assured after cleaning.
+- Monitor network traffic and endpoint activities closely for any signs of persistence or re-infection, using enhanced detection rules and updated threat intelligence feeds.
+- Escalate the incident to the appropriate internal or external cybersecurity teams if the infection appears to be part of a larger coordinated attack, ensuring that all relevant data and findings are shared for further investigation and response."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
index 877e4ced8fd..95e7b4b9534 100644
--- a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
+++ b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,39 @@ sequence by host.id with maxspan=1m
                    "php*",
                    "wget")] by process.parent.pid
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential JAVA/JNDI Exploitation Attempt
+
+Java Naming and Directory Interface (JNDI) is a Java API that provides naming and directory functionality, allowing Java applications to discover and look up data and resources via a directory service. Adversaries exploit JNDI by injecting malicious payloads that trigger outbound connections to LDAP, RMI, or DNS services, potentially leading to remote code execution. The detection rule identifies such exploitation attempts by monitoring Java processes making suspicious outbound connections followed by the execution of potentially harmful child processes, such as shell scripts or scripting languages, indicating a possible compromise.
+
+### Possible investigation steps
+
+- Review the network logs to confirm the outbound connection attempt by the Java process to the specified ports (1389, 389, 1099, 53, 5353) and identify the destination IP addresses to determine if they are known malicious or suspicious entities.
+- Examine the process tree to verify the parent-child relationship between the Java process and any suspicious child processes such as shell scripts or scripting languages (e.g., sh, bash, curl, python).
+- Check the command line arguments and environment variables of the suspicious child processes to identify any potentially malicious payloads or commands being executed.
+- Investigate the host's recent activity and logs for any other indicators of compromise or unusual behavior that might correlate with the suspected exploitation attempt.
+- Assess the system for any unauthorized changes or new files that may have been introduced as a result of the exploitation attempt, focusing on directories commonly used by Java applications.
+
+### False positive analysis
+
+- Development and testing environments may trigger false positives when developers use Java applications to test connections to LDAP, RMI, or DNS services. To mitigate this, exclude known development servers or IP ranges from the detection rule.
+- Automated scripts or maintenance tasks that involve Java applications making legitimate outbound connections to the specified ports can be mistaken for exploitation attempts. Identify and whitelist these scripts or tasks by their process names or hashes.
+- Legitimate Java-based applications that require frequent updates or data retrieval from external services might generate similar network patterns. Monitor and document these applications, then create exceptions for their specific network behaviors.
+- Security tools or monitoring solutions that use Java for network scanning or analysis might inadvertently match the rule's criteria. Ensure these tools are recognized and excluded by their process identifiers or network activity profiles.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further outbound connections and potential lateral movement.
+- Terminate any suspicious Java processes identified in the alert, especially those making outbound connections to LDAP, RMI, or DNS ports.
+- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious processes, focusing on child processes like shell scripts or scripting languages.
+- Restore the affected system from a known good backup if unauthorized changes or malware are detected.
+- Update and patch Java and any related applications to the latest versions to mitigate known vulnerabilities.
+- Implement network-level controls to block outbound connections to suspicious or unauthorized LDAP, RMI, or DNS services from Java processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/guided_onboarding_sample_rule.toml b/rules/cross-platform/guided_onboarding_sample_rule.toml
index 90163be7f7e..2006b978127 100644
--- a/rules/cross-platform/guided_onboarding_sample_rule.toml
+++ b/rules/cross-platform/guided_onboarding_sample_rule.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/09/22"
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,39 @@ language = "kuery"
 license = "Elastic License v2"
 max_signals = 1
 name = "My First Rule"
-note = """This is a test alert.
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 My First Rule
+Elastic Security leverages event data to monitor and alert on potential security incidents. The "My First Rule" is a foundational rule designed for onboarding, focusing on event data without indicating a specific threat. Adversaries might exploit event logging to obscure their tracks or trigger false alerts. This rule helps analysts familiarize themselves with event-based alerts, ensuring they can identify and respond to genuine threats effectively.
+
+### Possible investigation steps
+
+- Review the event data associated with the alert to understand the context and source of the event.kind:event.
+- Check the timestamp of the event to determine when the activity occurred and correlate it with other events around the same time.
+- Identify the host or user associated with the event to assess if there is any unusual or unauthorized activity.
+- Examine related logs or events from the same source to identify any patterns or anomalies that could indicate suspicious behavior.
+- Consult with team members or use internal resources to determine if the event is part of normal operations or if it requires further investigation.
+
+### False positive analysis
+
+- Routine system events can trigger alerts, as the rule monitors all event data without filtering for specific threats.
+- Identify and document common non-threatening events that frequently trigger alerts, such as regular system updates or scheduled tasks.
+- Use exceptions to exclude these documented non-threatening events from triggering alerts, reducing noise and focusing on genuine threats.
+- Regularly review and update the list of exceptions to ensure it remains relevant and does not inadvertently exclude new potential threats.
+- Collaborate with IT and operations teams to understand normal event patterns and adjust the rule's exceptions accordingly.
+
+### Response and remediation
+
+- Verify the legitimacy of the event by cross-referencing with known benign activities or scheduled tasks to rule out false positives.
+- Contain any potential threat by isolating affected systems or accounts if suspicious activity is confirmed, preventing further unauthorized access or damage.
+- Remediate by reviewing and adjusting logging configurations to ensure accurate event capture and reduce the risk of adversaries exploiting logging mechanisms.
+- Escalate the incident to the appropriate security team or management if the event correlates with other suspicious activities or if it indicates a potential breach.
+- Enhance detection capabilities by updating alerting rules to include additional context or indicators observed during the investigation, ensuring better identification of similar threats in the future.
+
+This is a test alert.
 
 This alert does not show threat activity. Elastic created this alert to help you understand how alerts work.
 
diff --git a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
index c335de8be23..19ec10d0a00 100644
--- a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
+++ b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/09/14"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,40 @@ query = '''
 event.type:creation and event.module:zoom and event.dataset:zoom.webhook and
   event.action:meeting.created and not zoom.meeting.password:*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Zoom Meeting with no Passcode
+
+Zoom meetings without passcodes are vulnerable to unauthorized access, known as Zoombombing, where intruders disrupt sessions with inappropriate content. Adversaries exploit this by joining unsecured meetings to cause chaos or gather sensitive information. The detection rule identifies such meetings by monitoring Zoom event logs for sessions created without a passcode, helping to mitigate potential security breaches.
+
+### Possible investigation steps
+
+- Review the Zoom event logs to identify the specific meeting details, including the meeting ID and the organizer's information, using the fields event.type, event.module, event.dataset, and event.action.
+- Contact the meeting organizer to verify if the meeting was intentionally created without a passcode and understand the context or purpose of the meeting.
+- Check for any unusual or unauthorized participants who joined the meeting by examining the participant logs associated with the meeting ID.
+- Assess if any sensitive information was discussed or shared during the meeting that could have been exposed to unauthorized participants.
+- Evaluate the need to implement additional security measures, such as enabling passcodes for all future meetings or using waiting rooms to control participant access.
+
+### False positive analysis
+
+- Internal team meetings may be scheduled without a passcode for convenience, especially if all participants are within a secure network. To handle this, create exceptions for meetings initiated by trusted internal users or within specific IP ranges.
+- Recurring meetings with a consistent group of participants might not use passcodes to simplify access. Consider excluding these meetings by identifying and whitelisting their unique meeting IDs.
+- Training sessions or webinars intended for a broad audience might be set up without passcodes to ease access. Implement a policy to review and approve such meetings in advance, ensuring they are legitimate and necessary.
+- Meetings created by automated systems or bots for integration purposes may not require passcodes. Identify these systems and exclude their meeting creation events from triggering alerts.
+- In some cases, meetings may be intentionally left without passcodes for public access, such as community events. Establish a process to verify and document these events, allowing them to be excluded from the rule.
+
+### Response and remediation
+
+- Immediately terminate any ongoing Zoom meetings identified without a passcode to prevent further unauthorized access or disruption.
+- Notify the meeting host and relevant stakeholders about the security incident, advising them to reschedule the meeting with appropriate security measures, such as enabling a passcode or waiting room.
+- Review and update Zoom account settings to enforce mandatory passcodes for all future meetings, ensuring compliance with security policies.
+- Conduct a security audit of recent Zoom meetings to identify any other sessions that may have been created without a passcode and take corrective actions as necessary.
+- Escalate the incident to the IT security team for further investigation and to assess any potential data breaches or information leaks resulting from the unauthorized access.
+- Implement enhanced monitoring and alerting for Zoom meeting creation events to quickly detect and respond to any future instances of meetings being set up without passcodes.
+- Coordinate with the communications team to prepare a response plan for any potential public relations issues arising from the incident, ensuring clear and consistent messaging."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/multiple_alerts_different_tactics_host.toml b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
index 676a9a892e7..d21057298e0 100644
--- a/rules/cross-platform/multiple_alerts_different_tactics_host.toml
+++ b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,41 @@ type = "threshold"
 query = '''
 signal.rule.name:* and kibana.alert.rule.threat.tactic.id:*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Multiple Alerts in Different ATT&CK Tactics on a Single Host
+
+The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts.
+- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
+- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
+- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
+- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
+- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
+
+### False positive analysis
+
+- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
+- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
+- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
+- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
+- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
+- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
+- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
+- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
+- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
+- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""
 
 
 
diff --git a/rules/cross-platform/multiple_alerts_involving_user.toml b/rules/cross-platform/multiple_alerts_involving_user.toml
index 076a1096ea5..ae53897aa33 100644
--- a/rules/cross-platform/multiple_alerts_involving_user.toml
+++ b/rules/cross-platform/multiple_alerts_involving_user.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -33,6 +33,42 @@ type = "threshold"
 query = '''
 signal.rule.name:* and user.name:* and not user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Multiple Alerts Involving a User
+
+In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user.
+- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions.
+- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.
+- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.
+- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
+- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.
+- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.
+
+### False positive analysis
+
+- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.
+- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.
+- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.
+- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.
+- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.
+
+### Response and remediation
+
+- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.
+- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.
+- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.
+- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.
+- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.
+- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.
+- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied."""
 
 
 
diff --git a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
index 85d4432c091..ffb6a09f9be 100644
--- a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
+++ b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ event.category:file and event.type:change and
            systemd or containerd or pacman
          )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Standard Authentication Module or Configuration
+
+Authentication modules, such as PAM (Pluggable Authentication Modules), are crucial for managing user authentication in Linux and macOS environments. Adversaries may exploit these by altering module files or configurations to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to these modules, excluding legitimate processes and paths, to flag potential unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the specific file that triggered the alert by examining the file.name and file.path fields to determine if it is a known authentication module or configuration file.
+- Investigate the process that made the change by analyzing the process.executable field to identify if it is a legitimate process or potentially malicious.
+- Check the process.name field to see if the process is one of the excluded legitimate processes, which might indicate a false positive.
+- Look into recent system changes or updates that might have affected authentication modules, focusing on the time frame around the alert.
+- Correlate the alert with other security events or logs to identify any related suspicious activities or patterns, such as unauthorized access attempts or privilege escalation.
+- Verify the integrity of the affected authentication module or configuration file by comparing it with a known good version or using file integrity monitoring tools.
+
+### False positive analysis
+
+- Package management operations such as updates or installations can trigger false positives. Exclude processes like yum, dnf, rpm, and dpkg from the detection rule to prevent these benign activities from being flagged.
+- System maintenance tasks often involve legitimate changes to authentication modules. Exclude processes like authconfig, pam-auth-update, and pam-config to avoid false alerts during routine maintenance.
+- Development and testing environments may frequently modify authentication modules for testing purposes. Consider excluding paths like /tmp/snap.rootfs_*/pam_*.so and /tmp/newroot/lib/*/pam_*.so to reduce noise from these environments.
+- Backup and synchronization tools such as rsync can cause false positives when they interact with authentication module files. Exclude rsync from the detection rule to prevent these non-threatening activities from being flagged.
+- Containerized environments may have different paths and processes that interact with authentication modules. Exclude processes like containerd and paths like /tmp/newroot/usr/lib64/security/pam_*.so to account for these variations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Conduct a thorough review of the modified authentication module or configuration file to identify unauthorized changes and revert them to their original state using a known good backup.
+- Reset passwords for all user accounts on the affected system, prioritizing accounts with elevated privileges, to mitigate potential credential compromise.
+- Perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts found.
+- 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 enhanced monitoring on the affected system and similar environments to detect any future unauthorized modifications to authentication modules or configurations.
+- Review and update access controls and authentication policies to strengthen security measures and reduce the risk of similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/persistence_shell_profile_modification.toml b/rules/cross-platform/persistence_shell_profile_modification.toml
index 60a1afc60aa..00a694158ac 100644
--- a/rules/cross-platform/persistence_shell_profile_modification.toml
+++ b/rules/cross-platform/persistence_shell_profile_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,41 @@ event.category:file and event.type:change and
              /Users/*/.bash_profile or
              /Users/*/.zshenv)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Bash Shell Profile Modification
+
+Bash shell profiles, such as `.bash_profile` and `.bashrc`, are scripts that configure user environments upon login. Adversaries exploit these by inserting malicious commands to ensure persistence, executing harmful scripts whenever a user initiates a shell session. The detection rule identifies unauthorized modifications by monitoring file changes and filtering out benign processes, focusing on unusual executables and paths to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path that was modified, focusing on paths like /home/*/.bash_profile or /home/*/.bashrc.
+- Examine the process name and executable that triggered the alert to determine if it is an unusual or unauthorized process, as specified in the query.
+- Check the modification timestamp of the affected file to correlate with any known user activity or scheduled tasks.
+- Investigate the contents of the modified Bash shell profile file to identify any suspicious or unexpected commands or scripts.
+- Cross-reference the user account associated with the modified file to determine if the activity aligns with their typical behavior or if the account may be compromised.
+- Look for any related alerts or logs around the same timeframe that might indicate a broader attack or persistence mechanism.
+
+### False positive analysis
+
+- Frequent use of text editors like vim or nano may trigger alerts when users legitimately modify their shell profiles. To mitigate this, consider excluding these processes from the detection rule if they are commonly used in your environment.
+- Automated system updates or configuration management tools like dnf or yum might modify shell profiles as part of their operations. Exclude these processes if they are verified as part of routine maintenance.
+- Development tools such as git or platform-python may alter shell profiles during setup or updates. If these tools are regularly used, add them to the exclusion list to prevent false positives.
+- User-specific applications located in directories like /Applications or /usr/local may be flagged if they modify shell profiles. Verify these applications and exclude their paths if they are trusted and frequently used.
+- Consider excluding specific user directories from monitoring if they are known to contain benign scripts that modify shell profiles, ensuring these exclusions are well-documented and reviewed regularly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified in the alert that are not part of the allowed list, such as unauthorized executables modifying shell profiles.
+- Restore the modified shell profile files (.bash_profile, .bashrc) from a known good backup to remove any malicious entries.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- Implement file integrity monitoring on critical shell profile files to detect and alert on future unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Review and update endpoint protection policies to enhance detection capabilities for similar persistence techniques, leveraging MITRE ATT&CK framework references for T1546."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
index 71edbff424d..2846a2cfd73 100644
--- a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
+++ b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,42 @@ event.category:file and event.type:(change or creation) and
               /usr/bin/chef-client
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SSH Authorized Keys File Modification
+
+SSH authorized_keys files are crucial for secure, password-less authentication, allowing users to log into servers using public keys. Adversaries exploit this by adding their keys, ensuring persistent access. The detection rule identifies unauthorized changes to these files, excluding benign processes, to flag potential threats, focusing on persistence and lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file that was modified, focusing on "authorized_keys", "authorized_keys2", "/etc/ssh/sshd_config", or "/root/.ssh".
+- Examine the process that triggered the alert by checking the process executable path to ensure it is not one of the benign processes listed in the exclusion criteria.
+- Investigate the user account associated with the modification to determine if it is a legitimate user or potentially compromised.
+- Check the timestamp of the file modification to correlate with any known user activity or scheduled tasks that might explain the change.
+- Analyze recent login attempts and SSH connections to the server to identify any suspicious activity or unauthorized access.
+- Review the contents of the modified authorized_keys file to identify any unfamiliar or unauthorized public keys that have been added.
+- If unauthorized keys are found, remove them and consider resetting credentials or keys for affected accounts to prevent further unauthorized access.
+
+### False positive analysis
+
+- Development tools like git and maven may modify SSH authorized_keys files during legitimate operations. To prevent these from triggering alerts, add their paths to the exclusion list in the detection rule.
+- System utilities such as vim and touch are often used by administrators to manually update authorized_keys files. Consider excluding these processes if they are part of regular maintenance activities.
+- Automation tools like puppet and chef-client might update SSH configurations as part of their deployment scripts. Verify these changes are expected and exclude these processes if they are part of routine operations.
+- Docker-related processes may alter SSH configurations when containers are being managed. If these changes are part of standard container operations, include the relevant paths in the exclusion list.
+- Google Guest Agent and JumpCloud Agent might modify SSH settings as part of their management tasks. Confirm these actions are legitimate and exclude these processes if they align with normal system management activities.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Review the SSH authorized_keys file and remove any unauthorized or suspicious public keys that have been added.
+- Change the passwords for all user accounts on the affected host to prevent adversaries from regaining access using compromised credentials.
+- Conduct a thorough review of user accounts and permissions on the affected host to identify and disable any unauthorized accounts or privilege escalations.
+- Restore the affected system from a known good backup if unauthorized changes are extensive or if the integrity of the system is in question.
+- Implement additional monitoring on the affected host and network to detect any further unauthorized access attempts or suspicious activities.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
index d6509cbfe32..0645d57187d 100644
--- a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
+++ b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -33,6 +33,40 @@ type = "query"
 query = '''
 event.category:process and event.type:start and process.args:(echo and *NOPASSWD*ALL*)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via Sudoers File Modification
+
+The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by modifying the file to allow unauthorized privilege escalation, often using the NOPASSWD directive to bypass password prompts. The detection rule identifies suspicious process activities, such as attempts to alter sudoers configurations, by monitoring specific command patterns indicative of such exploits.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process that triggered the alert, focusing on the process.args field to confirm the presence of the *NOPASSWD*ALL* pattern.
+- Examine the process execution context, including the user account under which the process was initiated, to determine if it aligns with expected behavior or if it indicates potential misuse.
+- Check the system's sudoers file for recent modifications, especially looking for unauthorized entries or changes that include the NOPASSWD directive.
+- Investigate the command history of the user associated with the alert to identify any suspicious activities or commands executed around the time of the alert.
+- Correlate the event with other logs or alerts from the same host or user to identify any patterns or additional indicators of compromise that might suggest a broader attack.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule if administrators frequently update the sudoers file to add legitimate NOPASSWD entries for automation purposes. To manage this, create exceptions for known administrative scripts or processes that are regularly reviewed and approved.
+- Configuration management tools like Ansible or Puppet might modify the sudoers file as part of their normal operation. Exclude these tools from triggering alerts by identifying their specific process names or paths and adding them to an exception list.
+- Development environments where developers are granted temporary elevated privileges for testing purposes can cause false positives. Implement a policy to log and review these changes separately, ensuring they are reverted after use.
+- Automated scripts that require passwordless sudo access for operational efficiency might be flagged. Document these scripts and their usage, and configure the detection system to ignore these specific, well-documented cases.
+- System updates or patches that modify sudoers configurations as part of their installation process can be mistaken for malicious activity. Monitor update schedules and correlate them with alerts to identify and exclude these benign changes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Review and revert any unauthorized changes to the sudoers file by restoring it from a known good backup or manually correcting the entries to remove any NOPASSWD directives added by the adversary.
+- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege assignments.
+- Reset passwords for all accounts with elevated privileges on the affected system to ensure that compromised credentials cannot be reused.
+- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify the sudoers file across the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Implement additional logging and alerting for changes to the sudoers file and other critical configuration files to enhance detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
index d23c490865c..78471f68c8f 100644
--- a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
+++ b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SUID/SGID Bit Set
+
+The SUID/SGID bits in Unix-like systems allow files to execute with the privileges of the file owner or group, enabling necessary elevated permissions for certain applications. However, adversaries can exploit these bits to escalate privileges by modifying files to run with higher access rights. The detection rule identifies suspicious use of commands like `chmod` or `install` to set these bits, excluding known safe paths, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the user who executed the command, focusing on the process.name and process.args fields to understand the specific command and arguments used.
+- Check the process.parent.executable field to determine the parent process and assess whether it is a known legitimate process or potentially malicious.
+- Investigate the file or directory targeted by the SUID/SGID bit modification by examining the process.args field for any unusual or sensitive paths that could indicate privilege escalation attempts.
+- Correlate the event with other recent activities from the same user or system to identify any patterns or anomalies that could suggest malicious behavior.
+- Verify if the file or directory with modified SUID/SGID bits is part of a known safe path as listed in the exclusion criteria, and assess whether the modification is expected or authorized.
+
+### False positive analysis
+
+- System package installations or updates may trigger the rule when legitimate processes like package managers set SUID/SGID bits. To handle this, exclude paths related to package management, such as "/var/lib/dpkg/info*".
+- Docker or container-related operations might set these bits during normal operations. Exclude paths like "/var/lib/docker/*" to prevent false positives from container management activities.
+- Temporary directories used during system operations, such as "/tmp/newroot/*", can cause false alerts. Exclude these paths to avoid unnecessary alerts from temporary system processes.
+- Specific system services or applications, like "/usr/bin/ssh-agent", may require SUID/SGID bits for legitimate functionality. Exclude these known safe executables to reduce false positives.
+- Custom scripts or applications that are known to require elevated permissions should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Identify and terminate any suspicious processes associated with the use of `chmod` or `install` commands that have set the SUID/SGID bits, especially those not in the excluded safe paths.
+- Review and revert any unauthorized changes to file permissions, specifically those with SUID/SGID bits set, to their original state.
+- Conduct a thorough audit of user accounts and privileges on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
+- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID bits, focusing on the specific commands and arguments identified in the detection query.
+- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms that may have been established by the adversary.
+- Apply patches and updates to the affected system and any vulnerable applications to mitigate known vulnerabilities that could be exploited in conjunction with SUID/SGID bit abuse."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
index 0fa03093486..8d0b1cbdadd 100644
--- a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
+++ b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,41 @@ event.category:process and event.type:start and
   process.name:(sudo or sudoedit) and
   process.args:(*\\ and ("-i" or "-s"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Sudo Heap-Based Buffer Overflow Attempt
+
+Sudo is a critical utility in Unix-like systems, allowing users to execute commands with elevated privileges. A heap-based buffer overflow in Sudo (CVE-2021-3156) can be exploited by attackers to gain root access. Adversaries may craft specific command-line arguments to trigger this vulnerability. The detection rule identifies suspicious Sudo or Sudoedit invocations with particular argument patterns, signaling potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of suspicious Sudo or Sudoedit invocations with the specific argument patterns: process.args containing a backslash followed by either "-i" or "-s".
+- Examine the process execution context by gathering additional details such as the user account associated with the process, the parent process, and the command line used.
+- Check the system logs for any other unusual or unauthorized activities around the time of the alert to identify potential lateral movement or further exploitation attempts.
+- Investigate the history of the user account involved to determine if there have been any previous suspicious activities or privilege escalation attempts.
+- Assess the system for any signs of compromise or unauthorized changes, such as new user accounts, modified files, or unexpected network connections.
+- Verify the current version of Sudo installed on the system to determine if it is vulnerable to CVE-2021-3156 and consider applying patches or updates if necessary.
+
+### False positive analysis
+
+- Routine administrative tasks using sudo or sudoedit with interactive or shell options may trigger the rule. Review the context of these commands and consider excluding specific user accounts or scripts that are known to perform legitimate administrative functions.
+- Automated scripts or cron jobs that use sudo with the -i or -s options for legitimate purposes can be flagged. Identify these scripts and add them to an exception list to prevent unnecessary alerts.
+- Development or testing environments where users frequently test commands with elevated privileges might generate false positives. Implement a separate monitoring policy for these environments or exclude known test accounts.
+- Security tools or monitoring solutions that simulate attacks for testing purposes may inadvertently trigger the rule. Ensure these tools are recognized and excluded from triggering alerts by adding them to an exception list.
+- Users with legitimate reasons to frequently switch to root using sudo -i or sudo -s should be identified, and their activities should be monitored separately to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker.
+- Terminate any suspicious sudo or sudoedit processes identified by the detection rule to halt ongoing exploitation attempts.
+- Apply the latest security patches and updates to the Sudo utility on all affected systems to remediate the vulnerability (CVE-2021-3156).
+- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or privilege escalation activities.
+- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach.
+- Implement enhanced monitoring and alerting for sudo and sudoedit command executions across the network to detect similar exploitation attempts in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
index b0d2ae7d57e..dabefa210d6 100644
--- a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
+++ b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,40 @@ event.category:file and event.type:change and file.path:(/etc/sudoers* or /priva
 not process.name:(dpkg or platform-python or puppet or yum or dnf) and 
 not process.executable:(/opt/chef/embedded/bin/ruby or /opt/puppetlabs/puppet/bin/ruby or /usr/bin/dockerd)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Sudoers File Modification
+
+The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path that triggered the alert, focusing on /etc/sudoers* or /private/etc/sudoers*.
+- Examine the process information associated with the change event, particularly the process.name and process.executable fields, to determine if the modification was made by a suspicious or unauthorized process.
+- Check the user account associated with the process that made the change to the sudoers file to assess if the account has a legitimate reason to modify the file.
+- Investigate recent login activity and user behavior for the account involved in the modification to identify any anomalies or signs of compromise.
+- Review system logs around the time of the alert to gather additional context on what other activities occurred on the system, which might indicate a broader attack or compromise.
+- Assess the current state of the sudoers file to identify any unauthorized or suspicious entries that could indicate privilege escalation attempts.
+
+### False positive analysis
+
+- System updates and package installations can trigger changes to the sudoers file. Exclude processes like dpkg, yum, dnf, and platform-python from triggering alerts as they are commonly involved in legitimate updates.
+- Configuration management tools such as Puppet and Chef may modify the sudoers file as part of their normal operations. Exclude process executables like /opt/chef/embedded/bin/ruby and /opt/puppetlabs/puppet/bin/ruby to prevent false positives.
+- Docker daemon processes might interact with the sudoers file during container operations. Exclude /usr/bin/dockerd to avoid unnecessary alerts related to Docker activities.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and operational tools, minimizing false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Review the recent changes to the sudoers file to identify unauthorized modifications and revert them to the last known good configuration.
+- Conduct a thorough examination of system logs to identify any unauthorized access or actions performed using elevated privileges, focusing on the time frame of the detected change.
+- Reset passwords and review access permissions for all users with sudo privileges to ensure no unauthorized accounts have been added or existing accounts have been compromised.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify the sudoers file or other privilege escalation activities.
+- Review and update security policies and configurations to prevent similar incidents, ensuring that only authorized processes can modify the sudoers file."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/collection_cloudtrail_logging_created.toml b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
index f4c31b3d257..694363bb9e4 100644
--- a/rules/integrations/aws/collection_cloudtrail_logging_created.toml
+++ b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS CloudTrail Log Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS CloudTrail Log Created
+
+AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. The detection rule identifies successful trail creation, signaling potential unauthorized activity, aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the CreateTrail event by examining the user identity information in the event logs.
+- Check the time and date of the CreateTrail event to determine if it aligns with any known maintenance or administrative activities.
+- Investigate the configuration of the newly created trail to understand what specific log data it is set to capture and where it is being delivered.
+- Assess whether the trail creation was authorized by cross-referencing with change management records or by contacting relevant personnel.
+- Analyze other recent AWS CloudTrail events associated with the same user or role to identify any suspicious or unusual activities that may indicate malicious intent.
+- Evaluate the permissions and access policies of the user or role involved in the event to ensure they align with the principle of least privilege.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate trail creation activities to differentiate them from unauthorized actions.
+- Automated processes or scripts that create trails for compliance or monitoring purposes may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Third-party security tools or services that integrate with AWS and create trails for enhanced logging might be mistaken for suspicious activity. Verify these integrations and exclude them from the rule if they are part of your security strategy.
+- Changes in organizational policy or structure that require new trail creation can lead to false positives. Ensure that such changes are communicated to the security team to adjust the rule settings accordingly.
+
+### Response and remediation
+
+- Immediately review the newly created CloudTrail log to verify its legitimacy. Check the user or service account that initiated the trail creation and confirm if it aligns with expected administrative activities.
+- If the trail creation is unauthorized, disable or delete the trail to prevent further data capture by potential adversaries.
+- Conduct a thorough audit of recent API calls and user activities associated with the account that created the trail to identify any other suspicious actions or configurations.
+- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised.
+- Implement additional monitoring and alerting for any future unauthorized CloudTrail modifications or creations to enhance early detection capabilities.
+- Review and tighten IAM policies and permissions to ensure that only authorized personnel have the ability to create or modify CloudTrail configurations.
+- Consider enabling AWS CloudTrail log file integrity validation to ensure that log files have not been altered or deleted, providing an additional layer of security.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
index cbb1e5613fc..d27a455dd09 100644
--- a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
+++ b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Admin Credential Fetch via Assumed Role"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS EC2 Admin Credential Fetch via Assumed Role
 
diff --git a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
index e8549d773a8..a15d92086ad 100644
--- a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
+++ b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/20"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,12 +21,12 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS IAM CompromisedKeyQuarantine Policy Attached to User"
 note = """
-## Triage and Analysis
+## 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. 
+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
 
@@ -70,9 +70,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
+any where event.dataset == "aws.cloudtrail"
    and event.action == "AttachUserPolicy"
-   and event.outcome == "success" 
+   and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine")
 '''
 
diff --git a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
index b77b7bdd90c..ef65515d597 100644
--- a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
+++ b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -28,7 +28,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS Systems Manager SecureString Parameter Request with Decryption Flag"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag
 
diff --git a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
index e8cfdda99fe..6f841ec6401 100644
--- a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
+++ b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Management Console Brute Force of Root User Identity"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Management Console Brute Force of Root User Identity
+
+The AWS Management Console is a web-based interface for accessing and managing AWS services. The root user identity has unrestricted access, making it a prime target for adversaries seeking unauthorized control. Attackers may attempt brute force attacks to guess the root password. The detection rule identifies such attempts by monitoring failed login events specifically for the root user, flagging potential credential access threats.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific time frame of the failed login attempts to identify patterns or anomalies in the source IP addresses or user agents.
+- Check the geographical location of the IP addresses involved in the failed login attempts to determine if they are consistent with known or expected locations for legitimate access.
+- Investigate any successful login attempts from the same IP addresses or user agents to assess if the brute force attempt was successful at any point.
+- Analyze the frequency and timing of the failed login attempts to determine if they align with typical brute force attack patterns, such as rapid or sequential attempts.
+- Correlate the failed login events with other security events or alerts in the AWS environment to identify any concurrent suspicious activities that may indicate a broader attack campaign.
+- Review AWS CloudTrail logs for any changes in IAM policies or unusual activity following the failed login attempts to ensure no unauthorized access was gained.
+
+### False positive analysis
+
+- Legitimate users may forget their password and repeatedly attempt to log in, triggering the rule. To manage this, monitor for patterns of failed logins followed by successful ones and consider excluding these from alerts if they originate from known IP addresses.
+- Automated scripts or applications using outdated credentials can cause repeated failed login attempts. Identify and update these credentials or exclude the associated IP addresses from the rule.
+- Security testing or penetration testing activities might simulate brute force attacks. Coordinate with your security team to whitelist IP addresses or timeframes associated with these activities to prevent false positives.
+- Shared accounts or environments where multiple users attempt to access the root account can lead to multiple failed attempts. Implement stricter access controls and consider excluding known internal IP ranges from the rule.
+
+### Response and remediation
+
+- Immediately disable the root user account to prevent further unauthorized access attempts. This can be done through the AWS Management Console by navigating to the IAM section and selecting the root user account.
+- Review the CloudTrail logs to identify the source IP addresses of the failed login attempts. Block these IP addresses using AWS security groups or network ACLs to prevent further access attempts from these locations.
+- Reset the root user password and ensure it is strong and unique. Use a password manager to generate and store the new password securely.
+- Enable multi-factor authentication (MFA) for the root user account to add an additional layer of security. This can be configured in the AWS Management Console under the IAM section.
+- Conduct a thorough audit of recent account activity to ensure no unauthorized changes have been made. Pay special attention to IAM roles, policies, and permissions.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Provide them with details of the attempted breach and actions taken.
+- Implement additional monitoring and alerting for unusual login patterns or failed login attempts to the root account to enhance early detection of similar threats in the future.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
diff --git a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
index c0cd38ab247..3d79fb84154 100644
--- a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
+++ b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Configuration Recorder Stopped"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Configuration Recorder Stopped
+
+AWS Config records and evaluates configurations of AWS resources, ensuring compliance and security. Stopping the configuration recorder can hinder visibility into resource changes, aiding adversaries in evading detection. The detection rule identifies successful attempts to stop the recorder, signaling potential defense evasion by monitoring specific AWS CloudTrail events related to configuration changes.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.action:StopConfigurationRecorder to identify the user or role that initiated the action.
+- Check the event.outcome:success field to confirm the action was successfully executed and correlate it with any other suspicious activities around the same timeframe.
+- Investigate the IAM permissions and roles associated with the user or entity that stopped the configuration recorder to determine if they have the necessary permissions and if those permissions are appropriate.
+- Analyze the context of the event by examining other recent AWS CloudTrail events from the same event.provider:config.amazonaws.com to identify any related configuration changes or anomalies.
+- Assess the potential impact on compliance and security by identifying which resources were affected by the stopped configuration recorder and evaluating the risk of undetected changes during the period it was inactive.
+- Review any recent changes in AWS Config settings or policies that might explain the legitimate need to stop the configuration recorder, ensuring there is a valid business justification.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel can trigger the rule. To manage this, create exceptions for specific IAM roles or users known to perform these tasks regularly.
+- Automated scripts or tools used for configuration management might stop the recorder as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using their unique identifiers or tags.
+- Scheduled configuration changes during non-peak hours may involve stopping the recorder temporarily. Document these schedules and adjust the rule to ignore events during these periods.
+- Testing environments often mimic production changes, including stopping the recorder. Exclude events from known testing accounts or environments to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately re-enable the AWS Config recorder to restore visibility into resource changes and ensure compliance monitoring is active.
+- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized or suspicious activities that occurred during the period when the configuration recorder was stopped.
+- Verify the IAM roles and permissions associated with the AWS account to ensure that only authorized personnel have the ability to stop the configuration recorder. Adjust permissions as necessary to follow the principle of least privilege.
+- Implement additional monitoring and alerting for any future attempts to stop the AWS Config recorder, ensuring that such actions trigger immediate notifications to the security team.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the action was part of a broader attack or misconfiguration.
+- Review and update incident response plans to include specific procedures for handling AWS Config recorder stoppage events, ensuring rapid response and containment in future occurrences.
+- Consider enabling AWS Config rules to automatically remediate unauthorized changes, such as stopping the configuration recorder, to enhance the security posture and prevent recurrence.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
index fb2e47ad909..673aa1fe03f 100644
--- a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/26"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Network Access Control List Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 Network Access Control List Deletion
+
+AWS EC2 Network ACLs are essential for controlling inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion events of ACLs or their entries, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the specific user or role associated with the deletion event by examining the user identity information in the logs.
+- Check the time and date of the deletion event to determine if it coincides with any other suspicious activities or known maintenance windows.
+- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous.
+- Examine the AWS account activity around the time of the event to identify any other unusual actions or changes, such as the creation of new resources or modifications to existing ones.
+- Assess the impact of the deleted Network ACL or entries by identifying the affected subnets and evaluating the potential exposure or risk to the network.
+- Review any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to users or services, allowing them to delete Network ACLs.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may trigger deletion events. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts.
+- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation might delete and recreate ACLs as part of normal operations. Identify these tools and exclude their actions from triggering alerts.
+- Changes in network architecture or security policy updates can lead to legitimate ACL deletions. Document these changes and adjust the detection rule to ignore such planned modifications.
+- Ensure that the AWS accounts involved in the deletion events are recognized and trusted. Exclude actions from these accounts if they are part of regular administrative tasks.
+- Collaborate with the security team to establish a baseline of normal ACL deletion activities and refine the detection rule to minimize false positives based on this baseline.
+
+### Response and remediation
+
+- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration. This can be done by applying a restrictive security group or temporarily removing the subnet from the VPC.
+- Review AWS CloudTrail logs to identify the source of the deletion event, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger compromise.
+- Recreate the deleted Network ACL or its entries using the most recent backup or configuration documentation to restore intended security controls.
+- Implement a temporary monitoring solution to track any further unauthorized changes to network ACLs or related security configurations.
+- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, including potential lateral movement or data exfiltration.
+- Revoke or rotate credentials for any compromised IAM users or roles involved in the deletion event to prevent further unauthorized actions.
+- Enhance detection capabilities by configuring alerts for any future unauthorized changes to network ACLs, ensuring rapid response to similar threats.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
index d39dcc0b035..26b2b6f5578 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS ElastiCache Security Group Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS ElastiCache Security Group Created
+
+AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential defense evasion tactics by identifying unusual or unauthorized configurations.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.action "Create Cache Security Group" to identify the user or role that initiated the creation of the ElastiCache security group.
+- Examine the event.provider field to confirm that the event is associated with elasticache.amazonaws.com, ensuring the alert is relevant to ElastiCache services.
+- Check the event.outcome field to verify that the security group creation was successful, confirming the alert's validity.
+- Investigate the IAM permissions and roles associated with the user or entity that created the security group to determine if they have legitimate access and reasons for this action.
+- Analyze the configuration of the newly created ElastiCache security group to identify any overly permissive rules or unusual configurations that could indicate malicious intent.
+- Correlate this event with other recent activities in the AWS account, such as changes to IAM policies or unusual login attempts, to assess if this is part of a broader attack pattern.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate security group creation activities to differentiate them from suspicious actions.
+- Automated processes or scripts that create security groups as part of normal operations may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Infrastructure as Code (IaC) tools like Terraform or CloudFormation might create security groups during deployments. Ensure these tools and their actions are well-documented and consider excluding their known patterns from triggering alerts.
+- Development and testing environments often involve frequent creation and deletion of resources, including security groups. Establish separate monitoring rules or exceptions for these environments to reduce noise.
+- Scheduled maintenance or updates that involve security group modifications should be communicated to the security team in advance, allowing them to temporarily adjust monitoring rules or expectations.
+
+### Response and remediation
+
+- Immediately review the newly created ElastiCache security group to verify its necessity and ensure it aligns with organizational security policies. If unauthorized, proceed to delete the security group to prevent potential misuse.
+- Conduct a thorough audit of recent IAM activity to identify any unauthorized access or privilege escalation that may have led to the creation of the security group. Pay special attention to any anomalies in user behavior or access patterns.
+- Isolate any affected ElastiCache instances by temporarily restricting access to them until a full assessment is completed. This helps prevent any potential data exfiltration or unauthorized access.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Implement additional monitoring on the AWS account to detect any further unauthorized changes to security groups or other critical configurations, enhancing the detection capabilities for similar threats.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized security group creation in the future.
+- If the incident is confirmed as malicious, escalate to the incident response team for a comprehensive investigation and to determine if further actions, such as legal or regulatory reporting, are necessary.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
index a496a341a8c..dcf14818d03 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS ElastiCache Security Group Modified or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS ElastiCache Security Group Modified or Deleted
+
+AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, flagging successful modifications or deletions as potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.provider: elasticache.amazonaws.com to identify the user or role that initiated the security group modification or deletion.
+- Examine the event.action field to determine the exact action taken, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress", and assess the potential impact on security posture.
+- Check the event.outcome field to confirm the success of the action and correlate it with any other suspicious activities in the same timeframe.
+- Investigate the source IP address and location associated with the event to determine if it aligns with expected administrative activity.
+- Review the AWS IAM policies and permissions associated with the user or role to ensure they are appropriate and have not been overly permissive.
+- Assess the affected ElastiCache clusters to determine if any unauthorized access or data exfiltration attempts have occurred following the security group change.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel can trigger alerts when they modify security groups for legitimate reasons. To manage this, create exceptions for known maintenance windows or specific user actions.
+- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
+- Changes made by cloud management platforms or third-party services that integrate with AWS may also result in false positives. Review and whitelist these services if they are verified as non-threatening.
+- Regular updates or deployments that require temporary security group modifications can be mistaken for suspicious activity. Document these processes and adjust the detection rule to account for these expected changes.
+- Ensure that any changes made by trusted IP addresses or within a specific network range are reviewed and potentially excluded from alerting, as they may represent internal, authorized activities.
+
+### Response and remediation
+
+- Immediately isolate the affected ElastiCache instance by applying restrictive security group rules to prevent further unauthorized access.
+- Review CloudTrail logs to identify any unauthorized API calls related to the security group modifications and determine the source of the changes.
+- Revert any unauthorized changes to the ElastiCache security groups by restoring them to their previous state using backups or documented configurations.
+- Conduct a thorough investigation to identify any data exfiltration or unauthorized access that may have occurred due to the security group changes.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are required.
+- Implement additional monitoring and alerting for changes to ElastiCache security groups to ensure rapid detection of similar threats in the future.
+- Review and update IAM policies to ensure that only authorized personnel have permissions to modify ElastiCache security groups, reducing the risk of future unauthorized changes.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html"]
diff --git a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
index d0f4ad05d7d..ec4f02bff24 100644
--- a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS GuardDuty Detector Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS GuardDuty Detector Deletion
+
+AWS GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior in AWS environments. Deleting a GuardDuty detector halts this monitoring, potentially concealing malicious actions. Adversaries may exploit this by deleting detectors to evade detection. The detection rule identifies successful deletion events, signaling potential defense evasion attempts, and is crucial for maintaining security visibility.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.provider:guardduty.amazonaws.com and event.action:DeleteDetector to identify the user or role responsible for the deletion.
+- Check the event.outcome:success to confirm the deletion was successful and not an attempted action.
+- Investigate the IAM permissions and recent activity of the user or role identified to determine if the deletion was authorized or potentially malicious.
+- Examine any recent GuardDuty findings prior to the deletion to assess if there were any critical alerts that might have prompted the deletion.
+- Correlate the timing of the detector deletion with other security events or anomalies in the AWS environment to identify potential patterns or coordinated actions.
+- Review AWS CloudTrail logs for any other suspicious activities or changes in the environment around the time of the detector deletion.
+
+### False positive analysis
+
+- Routine maintenance or administrative actions may lead to the deletion of a GuardDuty detector. Verify if the deletion aligns with scheduled maintenance or administrative tasks.
+- Automated scripts or tools used for environment cleanup might inadvertently delete detectors. Review and adjust automation scripts to prevent unintended deletions.
+- Organizational policy changes or restructuring could result in detector deletions. Ensure that policy changes are communicated and understood by all relevant teams to avoid unnecessary deletions.
+- Exclude known and authorized users or roles from triggering alerts by creating exceptions for specific IAM roles or user accounts that are responsible for legitimate detector deletions.
+- Implement logging and alerting for detector deletions to quickly identify and verify the legitimacy of the action, allowing for rapid response to potential false positives.
+
+### Response and remediation
+
+- Immediately re-enable GuardDuty in the affected AWS account to restore monitoring capabilities and ensure continuous threat detection.
+- Conduct a thorough review of CloudTrail logs to identify any unauthorized access or suspicious activities that occurred during the period when GuardDuty was disabled.
+- Isolate any compromised resources identified during the log review to prevent further unauthorized access or damage.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional access controls and monitoring on the AWS account to prevent unauthorized deletion of GuardDuty detectors in the future.
+- Review and update IAM policies to ensure that only authorized personnel have permissions to delete GuardDuty detectors.
+- Consider enabling AWS Config rules to monitor and alert on changes to GuardDuty configurations for proactive detection of similar incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
index 4a584d3a37c..9f5408d461d 100644
--- a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
+++ b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/06/20"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer", "Elastic"]
@@ -46,6 +46,41 @@ any where event.dataset == "aws.cloudtrail"
     and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3") 
     and event.outcome == "success"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS DB Instance Restored
+
+Amazon RDS (Relational Database Service) allows users to set up, operate, and scale databases in the cloud. Adversaries may exploit RDS by restoring DB instances from snapshots or S3 to access sensitive data or bypass security controls. The detection rule identifies successful restoration attempts, signaling potential unauthorized access or data exfiltration activities, by monitoring specific API operations and outcomes.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the user or role associated with the successful `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API call by examining the `user.identity` field.
+- Check the source IP address and location from which the API call was made using the `sourceIPAddress` field to determine if it aligns with expected or known locations.
+- Investigate the timing of the restoration event by looking at the `@timestamp` field to see if it coincides with any other suspicious activities or anomalies in the environment.
+- Examine the specific DB instance details restored, such as the DB instance identifier, to assess the sensitivity of the data involved and potential impact.
+- Verify if there are any associated alerts or logs indicating unauthorized access or data exfiltration attempts around the same time frame.
+- Contact the user or team responsible for the credentials used, if legitimate, to confirm whether the restoration was authorized and intended.
+
+### False positive analysis
+
+- Routine database maintenance or testing activities may trigger the rule. Organizations should identify and document regular restoration activities performed by authorized personnel and exclude these from alerts.
+- Automated backup and restore processes used for disaster recovery or data migration can result in false positives. Users should configure exceptions for known automated processes by filtering based on specific user accounts or roles.
+- Development and staging environments often involve frequent restoration of databases for testing purposes. Exclude these environments by identifying and filtering out specific instance identifiers or tags associated with non-production environments.
+- Scheduled tasks or scripts that restore databases as part of regular operations can be mistaken for unauthorized activity. Ensure these tasks are well-documented and create exceptions based on the source IP or IAM role used for these operations.
+- Third-party services or integrations that require database restoration for functionality may trigger alerts. Verify these services and exclude their associated actions by identifying their unique user agents or API keys.
+
+### Response and remediation
+
+- Immediately isolate the restored RDS instance to prevent unauthorized access. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Conduct a thorough review of CloudTrail logs to identify the source of the compromised credentials and any other suspicious activities associated with the same user or account.
+- Revoke the compromised credentials and issue new credentials for the affected user or service account. Ensure that multi-factor authentication (MFA) is enabled for all accounts.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized restoration and any potential data exposure.
+- Perform a security assessment of the restored RDS instance to identify any unauthorized changes or data exfiltration. This includes checking for unusual queries or data exports.
+- Implement additional monitoring and alerting for similar API operations to detect future unauthorized restoration attempts promptly.
+- Review and update IAM policies to ensure that only authorized users have the necessary permissions to restore RDS instances, reducing the risk of future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
index 0df31df63c9..942e042e88b 100644
--- a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "Route53 Resolver Query Log Configuration Deleted"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating Route53 Resolver Query Log Configuration Deleted
 
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
index ceb62849c0d..d26d92a11af 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Configuration Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS S3 Bucket Configuration Deletion
+
+Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. Adversaries may delete these configurations to evade defenses, disrupt data protection, or conceal malicious activities. The detection rule monitors successful deletions of these configurations, signaling potential defense evasion attempts by correlating specific CloudTrail events.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.provider:s3.amazonaws.com and event.action values to identify the user or role responsible for the deletion actions.
+- Examine the event.outcome:success field to confirm that the deletion actions were completed successfully and not attempted or failed.
+- Investigate the IAM policies and permissions associated with the user or role identified to determine if they have legitimate access to perform such deletions.
+- Check for any recent changes in IAM roles or policies that might have inadvertently granted excessive permissions.
+- Correlate the timing of the deletion events with other suspicious activities or alerts in the AWS environment to identify potential patterns or coordinated actions.
+- Assess the impact of the deleted configurations on data security and compliance, and determine if any critical data protection mechanisms were affected.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel may trigger alerts when they update or remove bucket configurations as part of regular maintenance. To manage this, create exceptions for specific user roles or IAM users known to perform these tasks regularly.
+- Automated scripts or tools used for infrastructure management might delete and recreate bucket configurations as part of their operation. Identify these scripts and exclude their associated actions from triggering alerts by using specific identifiers or tags.
+- Scheduled policy updates or compliance checks that involve temporary removal of configurations can also result in false positives. Implement time-based exceptions for these known activities to prevent unnecessary alerts.
+- Development and testing environments often undergo frequent configuration changes, which can mimic suspicious behavior. Exclude these environments from the rule by using environment-specific tags or identifiers.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized access to the affected S3 bucket by reviewing and updating the bucket's access policies and permissions.
+- Restore the deleted configurations by applying the latest known good configuration settings for policies, replication, encryption, and other affected components.
+- Conduct a thorough audit of recent IAM activity to identify any unauthorized or suspicious actions related to the S3 bucket configurations.
+- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources or accounts have been compromised.
+- Implement additional monitoring and alerting for any future unauthorized configuration changes to S3 buckets, focusing on the specific actions identified in the detection rule.
+- Review and enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to modify S3 bucket configurations.
+- Coordinate with the incident response team to assess the impact of the configuration deletions on data security and compliance, and take necessary steps to mitigate any identified risks.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
index 00d6eb47dfd..97a1cb932da 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Expiration Lifecycle Configuration Added"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added
 
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
index 6815557fb75..7918b0463a1 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/12"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ license = "Elastic License v2"
 name = "AWS S3 Bucket Server Access Logging Disabled"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Server Access Logging Disabled
 
@@ -80,9 +80,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
-   and event.action == "PutBucketLogging" 
-   and event.outcome == "success" 
+any where event.dataset == "aws.cloudtrail"
+   and event.action == "PutBucketLogging"
+   and event.outcome == "success"
    and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled")
 '''
 
diff --git a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
index 5d042038e21..bf54ed3f4bd 100644
--- a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
+++ b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/08/19"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,39 @@ event.dataset: "aws.cloudtrail"
     and event.provider: sts.amazonaws.com
     and event.action: GetFederationToken
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of STS GetFederationToken Request by User
+
+AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user within a 10-day window, helping to uncover potential misuse aimed at evading defenses.
+
+### Possible investigation steps
+
+- Review the specific user account associated with the GetFederationToken request to determine if the activity aligns with their typical behavior and role within the organization.
+- Examine the AWS CloudTrail logs for additional context around the time of the GetFederationToken request, looking for any other unusual or suspicious activities by the same user or related accounts.
+- Check the source IP address and geolocation of the GetFederationToken request to identify if it originates from an expected or unexpected location.
+- Investigate the resources accessed using the temporary credentials obtained from the GetFederationToken request to assess if there was any unauthorized or suspicious access.
+- Consult with the user or their manager to verify if the GetFederationToken request was legitimate and necessary for their work tasks.
+
+### False positive analysis
+
+- Routine administrative tasks by cloud administrators may trigger the rule if they are using `GetFederationToken` for legitimate purposes. To manage this, create exceptions for known administrative accounts that regularly perform these actions.
+- Automated scripts or applications that use `GetFederationToken` for legitimate operations might be flagged. Identify these scripts and exclude their associated user accounts from the rule to prevent unnecessary alerts.
+- Third-party services integrated with AWS that require temporary credentials might cause false positives. Review and whitelist these services if they are verified and trusted to avoid repeated alerts.
+- New employees or contractors accessing AWS resources for the first time may trigger the rule. Implement a process to verify their access requirements and exclude their accounts if their actions are deemed non-threatening.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the `GetFederationToken` request to prevent unauthorized access to AWS resources.
+- Review CloudTrail logs to identify any suspicious activities performed using the temporary credentials and assess the potential impact on AWS resources.
+- Isolate the affected user account by disabling it temporarily to prevent further unauthorized actions until a thorough investigation is completed.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Conduct a root cause analysis to determine how the `GetFederationToken` request was initiated and identify any potential security gaps or misconfigurations.
+- Implement additional monitoring and alerting for `GetFederationToken` requests to detect and respond to similar activities promptly in the future.
+- Review and update IAM policies and permissions to ensure that only authorized users have the ability to request temporary credentials, reducing the risk of misuse."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
index 305ae622ff5..026f16032f2 100644
--- a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
+++ b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Insecure AWS EC2 VPC Security Group Ingress Rule Added"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added
 
diff --git a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
index 33ddcf3751a..33c6d1d5575 100644
--- a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS WAF Access Control List Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS WAF Access Control List Deletion
+
+AWS Web Application Firewall (WAF) protects web applications by controlling access based on defined rules. Deleting an Access Control List (ACL) can expose applications to threats by removing these protective rules. Adversaries may exploit this to bypass defenses, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful ACL deletions, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.action:DeleteWebACL to identify the user or role that initiated the deletion. Check the event.userIdentity field for details.
+- Examine the event.time field to determine when the deletion occurred and correlate it with any other suspicious activities or alerts around the same timeframe.
+- Investigate the event.sourceIPAddress to identify the origin of the request and assess if it aligns with known IP addresses or locations associated with your organization.
+- Check the AWS WAF configuration history to understand the context of the deleted ACL, including its rules and the applications it was protecting.
+- Assess the impact of the ACL deletion by reviewing access logs for the affected applications to identify any unusual or unauthorized access attempts following the deletion.
+- Verify if there are any recent changes in IAM policies or permissions that could have allowed unauthorized users to delete the ACL.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may trigger ACL deletions. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts.
+- Automated scripts or tools used for infrastructure management might delete and recreate ACLs as part of their normal operation. Identify these scripts and whitelist their actions to prevent unnecessary alerts.
+- Changes in security policies or architecture might necessitate the removal of certain ACLs. Ensure that such changes are documented and approved, and exclude these events from monitoring if they are part of a planned update.
+- Test environments often undergo frequent configuration changes, including ACL deletions. Differentiate between production and test environments and adjust monitoring rules to reduce false positives in non-production settings.
+
+### Response and remediation
+
+- Immediately revoke any access keys or credentials associated with the user or role that performed the ACL deletion to prevent further unauthorized actions.
+- Restore the deleted AWS WAF Access Control List from a backup or recreate it using documented configurations to re-establish protective rules.
+- Conduct a thorough review of recent access logs and CloudTrail events to identify any unauthorized access or data exfiltration attempts that may have occurred following the ACL deletion.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for any future attempts to delete or modify AWS WAF ACLs, ensuring rapid detection and response.
+- Review and tighten IAM policies to ensure that only authorized personnel have permissions to delete or modify AWS WAF configurations.
+- Consider enabling AWS Config rules to continuously monitor and alert on changes to critical AWS resources, including WAF ACLs, to prevent similar incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
index 1206af84945..5583b5235ed 100644
--- a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/09"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS WAF Rule or Rule Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS WAF Rule or Rule Group Deletion
+
+AWS Web Application Firewall (WAF) protects web applications by filtering and monitoring HTTP requests. Adversaries may delete WAF rules or groups to disable security measures, facilitating attacks like SQL injection or cross-site scripting. The detection rule monitors AWS CloudTrail logs for successful deletion actions, signaling potential defense evasion attempts by identifying unauthorized or suspicious deletions.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the deletion action by examining the userIdentity field.
+- Check the event.time field in the CloudTrail logs to determine when the deletion occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the source IP address and user agent from the CloudTrail logs to assess if the request originated from a known or expected location and device.
+- Verify if the deleted WAF rule or rule group was part of a critical security configuration by reviewing the AWS WAF setup and any associated documentation.
+- Contact the user or team responsible for AWS WAF management to confirm if the deletion was authorized and understand the rationale behind it.
+- Examine any recent changes in IAM policies or permissions that might have allowed unauthorized users to perform the deletion action.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger rule deletions. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts.
+- Automated scripts or tools used for infrastructure management might delete and recreate WAF rules as part of their normal operation. Identify these scripts and whitelist their actions to prevent unnecessary alerts.
+- Changes in security policies or architecture might necessitate the removal of certain WAF rules. Ensure that such changes are documented and approved, and exclude these documented actions from triggering alerts.
+- Temporary rule deletions for testing purposes by security teams can be mistaken for malicious activity. Coordinate with the security team to log these activities and exclude them from detection rules.
+- Ensure that IAM roles or users with permissions to delete WAF rules are reviewed regularly. Exclude actions performed by trusted roles or users after confirming their legitimacy.
+
+### Response and remediation
+
+- Immediately review AWS CloudTrail logs to confirm the unauthorized deletion of WAF rules or rule groups and identify the source of the action, including the IAM user or role involved.
+- Reapply the deleted WAF rules or rule groups to restore the intended security posture and prevent potential attacks such as SQL injection or cross-site scripting.
+- Temporarily restrict or revoke permissions for the identified IAM user or role to prevent further unauthorized actions until a thorough investigation is completed.
+- Conduct a security review of the affected AWS environment to identify any other potential security gaps or unauthorized changes that may have occurred.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for AWS WAF configuration changes to detect and respond to similar unauthorized actions promptly in the future.
+- Consider enabling AWS Config rules to continuously monitor and enforce compliance with WAF configurations, ensuring any unauthorized changes are automatically flagged.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
index ac33fffcfe4..b44db7e2dc0 100644
--- a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
+++ b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/26"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS EC2 Multi-Region DescribeInstances API Calls"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS EC2 Multi-Region DescribeInstances API Calls
 
diff --git a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
index a3e05953da5..8b82b3bac15 100644
--- a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
+++ b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS Discovery API Calls via CLI from a Single Resource"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS Discovery API Calls via CLI from a Single Resource
 
diff --git a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
index e0fa48aacb1..a64df95e82b 100644
--- a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
+++ b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/08/26"
 maturity = "production"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ from logs-aws.cloudtrail-*
 // sort the results by time windows in descending order
 | sort target_time_window desc
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Service Quotas Multi-Region `GetServiceQuota` Requests
+
+AWS Service Quotas manage resource limits across AWS services, crucial for maintaining operational boundaries. Adversaries may exploit `GetServiceQuota` API calls to probe AWS infrastructure, seeking vulnerabilities for deploying threats like cryptocurrency miners. The detection rule identifies unusual multi-region queries for EC2 quotas, signaling potential credential compromise or unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the specific user or role associated with the `aws.cloudtrail.user_identity.arn` field that triggered the alert. Determine if this user or role should have access to multiple regions.
+- Examine the `cloud.region` field to identify which regions were accessed and verify if these regions are typically used by your organization. Investigate any unfamiliar regions for unauthorized activity.
+- Check the AWS IAM policies and permissions associated with the identified user or role to ensure they align with the principle of least privilege. Look for any recent changes or anomalies in permissions.
+- Investigate the source IP addresses and locations from which the `GetServiceQuota` API calls were made to determine if they match expected patterns for your organization. Look for any unusual or suspicious IP addresses.
+- Review recent activity logs for the identified user or role to detect any other unusual or unauthorized actions, such as attempts to launch EC2 instances or access other AWS services.
+- If a compromise is suspected, consider rotating the credentials for the affected user or role and implementing additional security measures, such as multi-factor authentication (MFA) and enhanced monitoring.
+
+### False positive analysis
+
+- Legitimate multi-region operations: Organizations with a global presence may have legitimate reasons for querying EC2 service quotas across multiple regions. To handle this, users can create exceptions for known accounts or roles that regularly perform such operations.
+- Automated infrastructure management tools: Some tools or scripts designed for infrastructure management might perform multi-region `GetServiceQuota` requests as part of their normal operation. Users should identify these tools and exclude their activity from triggering alerts by whitelisting their associated user identities or ARNs.
+- Testing and development activities: Developers or testers might intentionally perform multi-region queries during testing phases. Users can mitigate false positives by setting up temporary exceptions for specific time frames or user identities involved in testing.
+- Cloud service providers or partners: Third-party services or partners managing AWS resources on behalf of an organization might generate similar patterns. Users should establish trust relationships and exclude these entities from detection by verifying their activities and adding them to an exception list.
+
+### Response and remediation
+
+- Immediately isolate the AWS account or IAM user identified in the alert to prevent further unauthorized access. This can be done by disabling the access keys or suspending the account temporarily.
+- Conduct a thorough review of the AWS CloudTrail logs for the identified user or resource to determine the extent of the unauthorized activity and identify any other potentially compromised resources.
+- Rotate all access keys and passwords associated with the compromised account or IAM user to prevent further unauthorized access.
+- Implement additional security measures such as enabling multi-factor authentication (MFA) for all IAM users and roles to enhance account security.
+- Notify the security operations team and relevant stakeholders about the potential compromise and the steps being taken to remediate the issue.
+- If evidence of compromise is confirmed, consider engaging AWS Support or a third-party incident response team for further investigation and assistance.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of future unauthorized access attempts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
index edd6adb3742..e41ca5a755c 100644
--- a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
+++ b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS Lambda Layer Added to Existing Function"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS Lambda Layer Added to Existing Function
 
diff --git a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
index 6dcc33f9728..11ebc853d10 100644
--- a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
+++ b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,41 @@ query = '''
 event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and
     event.action: (CreateStack or CreateStackSet) and event.outcome:success
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Time AWS Cloudformation Stack Creation by User
+
+AWS CloudFormation automates the setup of cloud resources using templates, streamlining infrastructure management. Adversaries with access can exploit this to deploy malicious resources, escalating their control. The detection rule identifies unusual activity by flagging the initial use of stack creation APIs by a user, helping to spot potential unauthorized actions early.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com to identify the user or role that initiated the CreateStack or CreateStackSet action.
+- Verify the IAM permissions of the user or role involved in the event to ensure they have the appropriate level of access and determine if the action aligns with their typical responsibilities.
+- Examine the stack template used in the CreateStack or CreateStackSet action to identify any unusual or unauthorized resources being provisioned.
+- Check the event.outcome:success field to confirm the stack creation was successful and investigate any related resources that were deployed as part of the stack.
+- Correlate the timing of the stack creation with other logs or alerts to identify any suspicious activity or patterns that might indicate malicious intent.
+- Investigate the account's recent activity history to determine if there have been any other first-time or unusual actions by the same user or role.
+
+### False positive analysis
+
+- Routine infrastructure updates by authorized users may trigger the rule. To manage this, maintain a list of users or roles that regularly perform these updates and create exceptions for them.
+- Automated deployment tools or scripts that use CloudFormation for legitimate purposes can cause false positives. Identify these tools and exclude their associated IAM roles or users from the rule.
+- New team members or roles onboarding into cloud management tasks might be flagged. Implement a process to review and whitelist these users after verifying their activities.
+- Scheduled or periodic stack creations for testing or development environments can be mistaken for suspicious activity. Document these schedules and exclude the relevant users or roles from the rule.
+- Third-party services or integrations that require stack creation permissions could be misidentified. Ensure these services are documented and their actions are excluded from triggering the rule.
+
+### Response and remediation
+
+- Immediately isolate the IAM user or role that initiated the stack creation to prevent further unauthorized actions. This can be done by revoking permissions or disabling the account temporarily.
+- Review the created stack and stack set for any unauthorized or suspicious resources. Identify and terminate any resources that are not part of the expected infrastructure.
+- Conduct a thorough audit of recent IAM activity to identify any other unusual or unauthorized actions that may indicate further compromise.
+- If malicious activity is confirmed, escalate the incident to the security operations team for a full investigation and potential involvement of incident response teams.
+- Implement additional monitoring and alerting for the affected account to detect any further unauthorized attempts to use CloudFormation or other critical AWS services.
+- Review and tighten IAM policies and permissions to ensure that only necessary privileges are granted, reducing the risk of exploitation by adversaries.
+- Consider enabling AWS CloudTrail logging and AWS Config rules to maintain a detailed record of all API activity and configuration changes for ongoing monitoring and compliance."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
index 6062fe1ad86..d3dc371b5c1 100644
--- a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
+++ b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SSM Command Document Created by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS SSM Command Document Created by Rare User
 
diff --git a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
index 4f860173b1c..e1b47b34a84 100644
--- a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
+++ b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/05"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SSM `SendCommand` Execution by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS SSM `SendCommand` Execution by Rare User
 
diff --git a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
index bc1ecf1dadb..83092ce7ae9 100644
--- a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "EC2 AMI Shared with Another Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating EC2 AMI Shared with Another Account
 
diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
index 926072b8026..dc5a7b6745e 100644
--- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2024/10/02"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ license = "Elastic License v2"
 name = "AWS EC2 EBS Snapshot Shared with Another Account"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS EC2 EBS Snapshot Shared with Another Account
 
diff --git a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
index e809fcaf22f..0d076751b11 100644
--- a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
+++ b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -24,7 +24,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Full Network Packet Capture Detected"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 Full Network Packet Capture Detected
+
+Traffic Mirroring in AWS EC2 allows copying of network traffic for monitoring and analysis, crucial for security and performance insights. However, adversaries can exploit this by capturing unencrypted data, leading to potential data exfiltration. The detection rule identifies successful creation of traffic mirroring components, signaling possible misuse for unauthorized data collection.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event actions: CreateTrafficMirrorFilter, CreateTrafficMirrorFilterRule, CreateTrafficMirrorSession, and CreateTrafficMirrorTarget to identify the user or role that initiated these actions.
+- Check the event.outcome field to confirm the success of the traffic mirroring setup and gather details about the time and source IP address of the request.
+- Investigate the associated Elastic Network Interface (ENI) to determine which EC2 instance is involved and assess its role and importance within the network.
+- Analyze the network traffic patterns and data flow from the mirrored traffic to identify any signs of data exfiltration or unusual data transfer activities.
+- Verify the encryption status of the network traffic being mirrored to assess the risk of sensitive data exposure.
+- Cross-reference the involved AWS account and IAM roles with known threat actor profiles or previous security incidents to identify potential insider threats or compromised accounts.
+
+### False positive analysis
+
+- Routine network monitoring activities may trigger the rule if legitimate traffic mirroring is set up for performance analysis. To manage this, identify and document authorized traffic mirroring configurations and exclude them from alerts.
+- Security audits or compliance checks might involve creating traffic mirroring sessions. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods.
+- Development and testing environments often use traffic mirroring for debugging purposes. Maintain a list of such environments and apply exceptions to avoid unnecessary alerts.
+- Automated infrastructure management tools might create traffic mirroring components as part of their operations. Review and whitelist these tools to prevent false positives.
+- Ensure that any third-party services with access to your AWS environment are vetted and their activities are monitored to distinguish between legitimate and suspicious traffic mirroring actions.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance to prevent further data exfiltration. This can be done by removing the instance from any network access or security groups that allow outbound traffic.
+- Review and terminate any unauthorized Traffic Mirroring sessions, filters, or targets that were created. Ensure that only legitimate and necessary mirroring configurations are active.
+- Conduct a thorough audit of the AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts related to Traffic Mirroring or other sensitive operations.
+- Rotate and update any credentials or access keys that may have been exposed or compromised during the incident to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Escalate to higher management if the data exfiltration involves sensitive or critical data.
+- Implement additional network monitoring and intrusion detection measures to enhance visibility and detect similar threats in the future. Consider using AWS GuardDuty or similar services for continuous threat detection.
+- Review and update security policies and access controls to ensure that Traffic Mirroring and other sensitive features are only accessible to authorized personnel with a legitimate need.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
index 6b99a4eed46..deef65a43ee 100644
--- a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
+++ b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,7 +23,41 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 VM Export Failure"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 VM Export Failure
+
+AWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, thereby alerting security teams to investigate further.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.action: CreateInstanceExportTask with event.outcome: failure to gather details about the failed export attempt, including timestamps, source IP addresses, and user identities involved.
+- Investigate the IAM user or role associated with the failed export attempt to determine if the action was authorized or if there are any signs of compromised credentials.
+- Check the AWS account's export policies and permissions to ensure they are configured correctly and restrict unauthorized export attempts.
+- Analyze any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could be related to the failed export attempt.
+- Correlate the failed export attempt with other security events or alerts in the environment to identify any patterns or potential coordinated activities indicating a broader threat.
+
+### False positive analysis
+
+- Routine backup operations may trigger the rule if they involve failed export attempts. To manage this, identify and whitelist specific IAM roles or users that regularly perform legitimate backup tasks.
+- Development and testing environments often involve frequent export attempts for non-production instances. Exclude these environments by tagging instances appropriately and adjusting the detection rule to ignore these tags.
+- Misconfigured export tasks due to incorrect permissions or settings can lead to false positives. Regularly review and update IAM policies and export configurations to ensure they align with intended operations.
+- Automated scripts or tools that manage EC2 instances might occasionally fail due to transient issues, causing false alerts. Monitor and log these scripts' activities to distinguish between expected failures and potential threats.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account to prevent further unauthorized export attempts. This can be done by restricting permissions or temporarily suspending the account.
+- Review and revoke any suspicious or unauthorized IAM roles or policies that may have been used to initiate the failed export attempt.
+- Conduct a thorough audit of recent AWS CloudTrail logs to identify any other unusual activities or patterns that may indicate a broader compromise.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation.
+- Implement additional monitoring and alerting for successful and failed VM export attempts to ensure rapid detection of similar activities in the future.
+- Enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export EC2 instances.
+- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices related to EC2 instance exports.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance"]
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
index 3acc55c151f..29f9a59228b 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,7 +20,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Snapshot Export"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS Snapshot Export
+
+Amazon RDS Snapshot Export allows users to export Aurora database snapshots to Amazon S3, facilitating data analysis and backup. However, adversaries may exploit this feature to exfiltrate sensitive data by exporting snapshots without authorization. The detection rule monitors successful export tasks in AWS CloudTrail logs, flagging potential misuse by identifying unexpected or unauthorized snapshot exports.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.action:StartExportTask to identify the user or role that initiated the export task.
+- Check the event.provider:rds.amazonaws.com logs to verify the source IP address and location from which the export task was initiated, looking for any anomalies or unexpected locations.
+- Investigate the event.dataset:aws.cloudtrail logs to determine the specific database snapshot that was exported and assess its sensitivity or criticality.
+- Cross-reference the event.outcome:success with IAM policies and permissions to ensure the user or role had legitimate access to perform the export task.
+- Analyze any recent changes in IAM roles or policies that might have inadvertently granted export permissions to unauthorized users.
+- Contact the data owner or relevant stakeholders to confirm whether the export task was authorized and aligns with business needs.
+
+### False positive analysis
+
+- Routine data exports for legitimate business purposes may trigger alerts. Users should review export tasks to confirm they align with expected business operations and consider whitelisting known, authorized export activities.
+- Automated backup processes that regularly export snapshots to S3 can be mistaken for unauthorized actions. Identify and document these processes, then create exceptions in the monitoring system to prevent false alerts.
+- Development and testing environments often involve frequent snapshot exports for testing purposes. Ensure these environments are clearly identified and excluded from alerts by setting up specific rules or tags that differentiate them from production environments.
+- Exports initiated by third-party services or integrations that have been granted access to RDS snapshots might be flagged. Verify these integrations and adjust the detection rule to recognize and exclude these trusted services.
+
+### Response and remediation
+
+- Immediately revoke access to the AWS account or IAM role that initiated the unauthorized snapshot export to prevent further data exfiltration.
+- Conduct a thorough review of AWS CloudTrail logs to identify any other unauthorized activities associated with the same account or IAM role, and assess the scope of the potential data breach.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized export and any other suspicious activities discovered.
+- Restore the affected database from a known good backup if data integrity is suspected to be compromised, ensuring that the restored data is free from unauthorized changes.
+- Implement stricter IAM policies and permissions to limit who can perform snapshot exports, ensuring that only authorized personnel have the necessary permissions.
+- Enhance monitoring and alerting mechanisms to detect any future unauthorized snapshot export attempts, ensuring timely response to similar threats.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve readiness for future incidents.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartExportTask.html"]
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
index 20d686e65be..5851cc6b77b 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Snapshot Shared with Another Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Snapshot Shared with Another Account
 
@@ -81,7 +81,7 @@ query = '''
 any where event.dataset == "aws.cloudtrail"
     and event.provider == "rds.amazonaws.com"
     and event.outcome == "success"
-    and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute") 
+    and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute")
     and stringContains(aws.cloudtrail.request_parameters, "attributeName=restore")
     and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]")
 '''
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
index 814222060d1..c70cf9217fa 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Policy Added to Share with External Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Policy Change to Share with External Account
 
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
index 1939fa0d9ec..27d30ee7048 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/12"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS S3 Bucket Replicated to Another Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Bucket Replicated to Another Account
 
@@ -73,9 +73,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
+any where event.dataset == "aws.cloudtrail"
    and event.action == "PutBucketReplication"
-   and event.outcome == "success" 
+   and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "Account")
 '''
 
diff --git a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
index 256caac2f0b..ec60aad4466 100644
--- a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
+++ b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SNS Email Subscription by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS SNS Email Subscription by Rare User
 
diff --git a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
index 4dced14d748..8b067da8dd0 100644
--- a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
+++ b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EventBridge Rule Disabled or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EventBridge Rule Disabled or Deleted
+
+AWS EventBridge is a serverless event bus service that enables applications to respond to changes in data. Disabling or deleting rules can disrupt event-driven workflows, potentially masking malicious activities. Adversaries might exploit this by halting security alerts or data flows. The detection rule monitors successful disable or delete actions on EventBridge rules, flagging potential misuse that could impact system visibility and integrity.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the user or role associated with the DeleteRule or DisableRule action by examining the user identity information in the event logs.
+- Check the event time and correlate it with other activities in the AWS account to determine if there are any related suspicious actions or patterns.
+- Investigate the specific EventBridge rule that was disabled or deleted to understand its purpose and the potential impact on workflows or security monitoring.
+- Assess the permissions and roles of the user who performed the action to determine if they had legitimate access and reasons for modifying the EventBridge rule.
+- Look for any recent changes in IAM policies or roles that might have granted new permissions to the user or role involved in the action.
+- Contact the user or team responsible for the action to verify if the change was intentional and authorized, and document their response for future reference.
+
+### False positive analysis
+
+- Routine maintenance or updates by administrators can lead to the disabling or deletion of EventBridge rules. To manage this, create exceptions for known maintenance windows or specific user actions that are documented and approved.
+- Automated scripts or tools used for infrastructure management might disable or delete rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
+- Testing environments often involve frequent changes to EventBridge rules, including disabling or deleting them. Exclude actions within these environments by filtering based on environment tags or specific resource identifiers.
+- Scheduled tasks that involve disabling rules temporarily for performance reasons can be a source of false positives. Document these schedules and configure the detection rule to ignore actions during these periods.
+- Changes made by trusted third-party services or integrations that manage EventBridge rules should be reviewed and, if deemed non-threatening, excluded by identifying the service accounts or API keys used.
+
+### Response and remediation
+
+- Immediately re-enable or recreate the disabled or deleted EventBridge rule to restore the intended event-driven workflows and ensure continuity of operations.
+- Conduct a review of CloudTrail logs to identify the user or service account responsible for the action, and verify if the action was authorized and legitimate.
+- If unauthorized activity is detected, revoke access for the compromised account and initiate a password reset or key rotation for the affected credentials.
+- Notify the security operations team to assess the potential impact on system visibility and integrity, and to determine if further investigation is required.
+- Implement additional monitoring and alerting for changes to EventBridge rules to detect similar activities in the future.
+- Escalate the incident to the incident response team if there is evidence of malicious intent or if the activity aligns with known threat patterns, such as those described in MITRE ATT&CK technique T1489 (Service Stop).
+- Review and update IAM policies to ensure that only authorized users have the necessary permissions to modify EventBridge rules, reducing the risk of unauthorized changes.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
index 06305eb8968..3c67566be9f 100644
--- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
+++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Encryption Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 Encryption Disabled
+
+Amazon EC2's EBS encryption ensures data at rest is secure by default. Disabling this feature can expose sensitive data, making it vulnerable to unauthorized access. Adversaries might exploit this by disabling encryption to access or manipulate data without detection. The detection rule monitors CloudTrail logs for successful attempts to disable EBS encryption, alerting security teams to potential misuse.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.action: DisableEbsEncryptionByDefault to identify the user or role that initiated the action.
+- Check the event.provider: ec2.amazonaws.com logs to gather additional context about the environment and any related activities around the time of the event.
+- Investigate the IAM policies and permissions associated with the user or role to determine if they have the necessary permissions to disable EBS encryption and if those permissions are appropriate.
+- Assess the event.outcome: success to confirm that the action was completed successfully and identify any subsequent actions taken by the same user or role.
+- Examine the AWS account's security settings and configurations to ensure that no other security features have been altered or disabled.
+- Contact the user or team responsible for the action to understand the rationale behind disabling EBS encryption and verify if it aligns with organizational policies.
+
+### False positive analysis
+
+- Routine administrative actions may trigger alerts if encryption is disabled for testing or configuration purposes. To manage this, create exceptions for specific IAM roles or users known to perform these tasks regularly.
+- Automated scripts or tools that disable encryption for specific workflows might cause false positives. Identify these scripts and exclude their associated actions from triggering alerts by using specific tags or identifiers.
+- Changes in regional settings or policies that temporarily disable encryption could be misinterpreted as threats. Monitor these changes and adjust the detection rule to account for legitimate policy updates.
+- Scheduled maintenance or updates that require temporary encryption disabling should be documented and excluded from alerts by setting time-based exceptions during known maintenance windows.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instances to prevent further unauthorized access or data manipulation. This can be done by modifying security group rules or network ACLs to restrict access.
+- Re-enable EBS encryption by default in the affected region to ensure that all new volumes are encrypted. This can be done through the AWS Management Console or AWS CLI.
+- Conduct a thorough review of recent changes in the AWS environment to identify any unauthorized modifications or access patterns. Focus on CloudTrail logs for any suspicious activity related to EBS encryption settings.
+- Notify the security operations team and relevant stakeholders about the incident, providing them with details of the alert and any initial findings.
+- Implement additional monitoring and alerting for any future attempts to disable EBS encryption by default, ensuring that security teams are promptly notified of similar activities.
+- Review and update IAM policies to ensure that only authorized personnel have the necessary permissions to modify EBS encryption settings, reducing the risk of accidental or malicious changes.
+- If any data manipulation is detected, initiate data recovery procedures to restore affected data from backups, ensuring data integrity and availability.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
index 289a125097f..255a0ae64a7 100644
--- a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
+++ b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,7 +24,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EFS File System or Mount Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EFS File System or Mount Deleted
+
+Amazon Elastic File System (EFS) provides scalable file storage for use with AWS cloud services and on-premises resources. Adversaries may target EFS by deleting file systems or mount targets, disrupting applications reliant on these resources. The detection rule monitors AWS CloudTrail logs for successful deletion events, signaling potential malicious activity aimed at data destruction or service disruption.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the deletion event by examining the user identity information in the logs.
+- Check the event time and correlate it with other activities in the AWS environment to determine if there are any related suspicious actions or patterns.
+- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous.
+- Verify if there were any recent changes to IAM policies or roles that might have inadvertently granted permissions to delete EFS resources.
+- Assess the impact of the deletion by identifying which applications or services were using the deleted EFS file system or mount target and determine if there are any disruptions.
+- Contact the user or team responsible for the AWS account to confirm if the deletion was intentional and authorized, or if it was potentially malicious.
+
+### False positive analysis
+
+- Routine maintenance activities by system administrators may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or cloud management tools that manage EFS resources might delete mounts or file systems as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts.
+- Development or testing environments often involve frequent creation and deletion of resources. Exclude these environments from the rule to prevent unnecessary alerts.
+- Scheduled cleanup jobs that remove unused or temporary file systems can cause false positives. Document these jobs and configure exceptions based on their execution schedule.
+- Ensure that any third-party services or integrations with AWS that manage EFS resources are accounted for, and their actions are excluded if they are part of expected behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected EFS file system to prevent further unauthorized deletions or access. This can be done by modifying the security group rules to deny all traffic temporarily.
+- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the action was authorized.
+- Revoke or adjust permissions for the identified IAM user or role to prevent further unauthorized actions. Ensure that least privilege principles are applied.
+- Restore the deleted EFS file system or mount from the most recent backup, if available, to minimize data loss and service disruption.
+- Notify the incident response team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Conduct a post-incident review to identify any gaps in security controls or processes that allowed the unauthorized deletion, and implement necessary improvements.
+- Enhance monitoring and alerting for similar events by ensuring that all critical AWS resources have appropriate logging and alerting configured, focusing on deletion and modification actions.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml
index 97463e97775..06e9523fd17 100644
--- a/rules/integrations/aws/impact_iam_group_deletion.toml
+++ b/rules/integrations/aws/impact_iam_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS IAM Group Deletion
+
+AWS IAM groups facilitate user management by organizing users with similar permissions. Adversaries might exploit group deletion to disrupt access controls, potentially leading to unauthorized access or service disruption. The detection rule monitors successful group deletions via AWS CloudTrail, flagging potential misuse by correlating specific IAM actions and outcomes, thus aiding in timely threat identification.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role that performed the DeleteGroup action by examining the userIdentity field.
+- Check the event time to determine when the group deletion occurred and correlate it with any other suspicious activities around the same timeframe.
+- Investigate the specific IAM group that was deleted to understand its purpose and the permissions it granted by reviewing historical IAM policies and group membership.
+- Assess the impact of the group deletion by identifying any users or services that might have been affected due to the loss of group-based permissions.
+- Verify if the group deletion was authorized by cross-referencing with change management records or contacting the responsible team or individual.
+- Look for any patterns or repeated occurrences of similar actions in the logs to identify potential malicious behavior or misconfigurations.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when IAM groups are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known maintenance periods or specific administrative accounts.
+- Automated scripts or tools that manage IAM resources might delete groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
+- Temporary groups created for short-term projects or testing purposes might be deleted frequently. Document these groups and exclude their deletion from monitoring by using naming conventions or tags.
+- Changes in organizational structure or policy might necessitate the deletion of certain groups. Coordinate with relevant teams to anticipate these changes and adjust monitoring rules accordingly.
+
+### Response and remediation
+
+- Immediately revoke any active sessions and access keys for users who were part of the deleted IAM group to prevent unauthorized access.
+- Restore the deleted IAM group from a backup or recreate it with the same permissions to ensure continuity of access for legitimate users.
+- Conduct a review of recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded the group deletion.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring on IAM activities, especially focusing on group management actions, to detect similar threats in the future.
+- Review and tighten IAM policies and permissions to ensure that only authorized personnel can delete IAM groups.
+- If malicious intent is suspected, escalate the incident to the incident response team for a comprehensive investigation and potential legal action.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
index 11c2d13335e..1bfd869dcc6 100644
--- a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
+++ b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Xavier Pich"]
@@ -25,7 +25,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS KMS Customer Managed Key Disabled or Scheduled for Deletion
+
+AWS Key Management Service (KMS) allows users to create and manage cryptographic keys for data encryption. Customer Managed Keys (CMKs) are crucial for securing sensitive data. Adversaries may disable or schedule deletion of CMKs to render encrypted data inaccessible, causing data loss. The detection rule monitors successful disablement or deletion attempts, alerting analysts to potential data destruction activities.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role that initiated the DisableKey or ScheduleKeyDeletion action.
+- Check the event.provider:kms.amazonaws.com logs to gather additional context about the KMS key involved, including its key ID and any associated metadata.
+- Investigate the event.action:("DisableKey" or "ScheduleKeyDeletion") to determine if the action was authorized and aligns with recent changes or requests within the organization.
+- Analyze the event.outcome:success to confirm the success of the action and assess the potential impact on encrypted data.
+- Cross-reference the timing of the event with any known incidents or maintenance activities to rule out false positives or expected behavior.
+- Contact the user or team responsible for the action to verify the intent and ensure it was a legitimate operation.
+
+### False positive analysis
+
+- Routine key management activities by authorized personnel can trigger alerts. Regularly review and document key management procedures to differentiate between legitimate and suspicious activities.
+- Automated scripts or tools used for key rotation or lifecycle management might disable or schedule deletion of keys as part of their process. Identify and whitelist these scripts or tools to prevent unnecessary alerts.
+- Testing environments where keys are frequently created and deleted for development purposes can generate false positives. Exclude these environments from monitoring or adjust the rule to focus on production environments.
+- Scheduled maintenance or compliance audits may involve disabling keys temporarily. Coordinate with relevant teams to schedule these activities and temporarily adjust monitoring rules to avoid false alerts.
+- Misconfigured alerts due to incorrect tagging or categorization of keys can lead to false positives. Ensure that all keys are correctly tagged and categorized to align with monitoring rules.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the disablement or deletion action by contacting the key owner or relevant stakeholders to confirm if the action was intentional.
+- If the action was unauthorized, revoke any access credentials or permissions associated with the user or service that performed the action to prevent further unauthorized activities.
+- Restore access to encrypted data by identifying any backup keys or data recovery options available, and initiate data recovery procedures if possible.
+- Escalate the incident to the security operations team and relevant management to assess the impact and coordinate a broader response if necessary.
+- Implement additional monitoring and alerting for any further attempts to disable or delete KMS keys, ensuring that alerts are sent to the appropriate personnel for rapid response.
+- Review and tighten IAM policies and permissions related to KMS key management to ensure that only authorized personnel have the ability to disable or delete keys.
+- Conduct a post-incident review to identify any gaps in the current security posture and update incident response plans to address similar threats in the future.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_group_deletion.toml b/rules/integrations/aws/impact_rds_group_deletion.toml
index 989081659af..127e2b4031c 100644
--- a/rules/integrations/aws/impact_rds_group_deletion.toml
+++ b/rules/integrations/aws/impact_rds_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,41 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Security Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS Security Group Deletion
+
+Amazon RDS Security Groups control access to RDS instances, acting as a virtual firewall. Adversaries may delete these groups to disrupt database access or cover their tracks. The detection rule monitors AWS CloudTrail logs for successful deletion events of RDS Security Groups, signaling potential unauthorized activity. This helps security analysts quickly identify and respond to suspicious deletions.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup fields to ensure the deletion event is accurately captured.
+- Identify the user or role associated with the event by examining the user identity information in the CloudTrail logs to determine if the action was performed by an authorized entity.
+- Check the event time and correlate it with other security events or alerts to identify any suspicious activity patterns or sequences that might indicate a broader attack.
+- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as modifications to IAM policies or unusual login attempts, to assess if the deletion is part of a larger unauthorized access attempt.
+- Contact the relevant database or cloud infrastructure team to verify if the deletion was intentional and authorized, ensuring that it aligns with any ongoing maintenance or decommissioning activities.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
+- Automated scripts or tools used for infrastructure management might delete security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
+- Changes in security group configurations during scheduled updates or migrations can result in deletions. Document these events and adjust the detection rule to ignore deletions during these planned activities.
+- Testing environments often involve frequent creation and deletion of resources, including security groups. Exclude these environments from monitoring by using environment-specific tags or identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected RDS instance by modifying its security group settings to restrict all inbound and outbound traffic, preventing further unauthorized access.
+- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the credentials have been compromised.
+- Recreate the deleted RDS Security Group with the appropriate rules and reassign it to the affected RDS instance to restore normal operations.
+- Conduct a thorough audit of IAM permissions to ensure that only authorized personnel have the ability to delete RDS Security Groups, and revoke any unnecessary permissions.
+- Implement multi-factor authentication (MFA) for all IAM users with permissions to modify RDS Security Groups to enhance security and prevent unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
+- Update incident response plans and security policies based on the findings to prevent similar incidents in the future and improve overall cloud security posture.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html"]
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
index 8648fe43465..63645111abb 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Deletion of RDS Instance or Cluster"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Deletion of RDS Instance or Cluster
+
+Amazon RDS simplifies database management by automating tasks like setup and scaling. However, adversaries can exploit this by deleting RDS instances or clusters, causing data loss and service disruption. The detection rule monitors AWS CloudTrail logs for successful deletion actions, alerting security teams to potential malicious activity aimed at data destruction.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider as rds.amazonaws.com and event.action values such as DeleteDBCluster, DeleteGlobalCluster, or DeleteDBInstance.
+- Identify the user or role responsible for the deletion by examining the user identity information in the CloudTrail logs, and verify if the action aligns with their typical behavior or responsibilities.
+- Check the event time and correlate it with any other suspicious activities or alerts in the AWS environment to determine if the deletion is part of a broader attack pattern.
+- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as IAM policy changes or unusual login attempts, to assess if the account may have been compromised.
+- Assess the impact of the deletion by identifying the specific RDS instance or cluster affected and determining the potential data loss or service disruption caused by the action.
+- Contact the responsible team or individual to verify if the deletion was intentional and authorized, and if not, initiate incident response procedures to mitigate further risk.
+
+### False positive analysis
+
+- Routine maintenance activities by database administrators can trigger alerts when they intentionally delete RDS instances or clusters. To manage this, create exceptions for known maintenance windows or specific administrator actions.
+- Automated scripts or tools used for testing and development purposes might delete RDS resources as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
+- Scheduled decommissioning of outdated or unused RDS instances can also result in false positives. Maintain an updated list of decommissioning schedules and exclude these from the detection rule.
+- CloudFormation stack deletions that include RDS resources can lead to alerts. Monitor CloudFormation activities and correlate them with RDS deletions to differentiate between legitimate and suspicious actions.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account to prevent further unauthorized actions. This can be done by revoking access keys and disabling any suspicious IAM user accounts or roles involved in the deletion.
+- Initiate a recovery process for the deleted RDS instance or cluster using available backups or snapshots. Ensure that the restoration is performed in a secure environment to prevent further compromise.
+- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the deletion event. This will help in understanding the scope of the breach and identifying potential entry points.
+- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data were affected.
+- Implement enhanced monitoring and alerting for AWS RDS and other critical resources to detect similar deletion attempts in the future. This includes setting up alerts for any unauthorized changes to IAM policies or roles.
+- Review and strengthen IAM policies to ensure the principle of least privilege is enforced, reducing the risk of unauthorized deletions by limiting permissions to only those necessary for specific roles.
+- Communicate with stakeholders and affected parties about the incident, outlining the steps taken for recovery and measures implemented to prevent future occurrences.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
index 26419ea1c3a..99cd9388f84 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/06/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment. 
+Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment.
 """
 false_positives = [
     """
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Deletion Protection Disabled"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled
 
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
index ecdf99bd422..6ff6240159b 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Instance/Cluster Stoppage"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS Instance/Cluster Stoppage
+
+Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, potentially causing data unavailability or loss. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS resources, alerting analysts to potential unauthorized disruptions aligned with impact tactics.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the StopDBCluster or StopDBInstance action to determine if the action was authorized.
+- Check the event time and correlate it with any scheduled maintenance or known operational activities to rule out legitimate stoppage.
+- Investigate the source IP address and location from which the stop action was initiated to identify any anomalies or unauthorized access.
+- Examine the AWS IAM policies and permissions associated with the user or role to ensure they align with the principle of least privilege.
+- Look for any related alerts or logs around the same timeframe that might indicate a broader security incident or unauthorized access attempt.
+- Contact the relevant database or application owner to confirm whether the stoppage was planned or expected.
+
+### False positive analysis
+
+- Routine maintenance activities may trigger stop actions on RDS instances or clusters. To manage this, create exceptions for scheduled maintenance windows by excluding events occurring during these times.
+- Development and testing environments often involve frequent stopping and starting of RDS instances. Identify and exclude these environments from alerts by using tags or specific instance identifiers.
+- Automated scripts or tools used for cost-saving measures might stop RDS instances during off-peak hours. Review and whitelist these scripts by verifying their source and purpose.
+- User-initiated stop actions for legitimate reasons, such as troubleshooting or configuration changes, can be excluded by maintaining a list of authorized personnel and their activities.
+- CloudFormation or other infrastructure-as-code tools may stop RDS instances as part of deployment processes. Exclude these actions by identifying and filtering events associated with these tools.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the stop action by reviewing the associated CloudTrail logs, focusing on the user identity, source IP, and time of the event to determine if the action was authorized.
+- If unauthorized, isolate the affected RDS instance or cluster by disabling any associated IAM user or role that performed the stop action to prevent further unauthorized access.
+- Restore the RDS instance or cluster from the latest backup or snapshot to minimize data unavailability and ensure service continuity.
+- Conduct a root cause analysis to identify how the unauthorized stop action was executed, focusing on potential security gaps in IAM policies or network configurations.
+- Implement additional security measures, such as enabling multi-factor authentication (MFA) for all IAM users and roles with permissions to stop RDS instances or clusters.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
+- Update the incident response plan to include lessons learned from this event, ensuring quicker and more effective responses to similar threats in the future.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/impact_rds_snapshot_deleted.toml b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
index ff2c665c4c9..bb09e40ec69 100644
--- a/rules/integrations/aws/impact_rds_snapshot_deleted.toml
+++ b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,40 @@ any where event.dataset == "aws.cloudtrail"
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS Snapshot Deleted
+
+AWS RDS snapshots are critical for data recovery, capturing full backups of database instances. Adversaries may delete these snapshots to prevent data restoration, effectively causing data loss. The detection rule monitors AWS CloudTrail logs for successful deletion actions or modifications that disable automated backups, signaling potential malicious activity aimed at data destruction.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the event.action values "DeleteDBSnapshot" or "DeleteDBClusterSnapshot" to determine if the action was authorized or expected.
+- Check the timestamp of the deletion event to correlate with any known maintenance activities or incidents that might explain the snapshot deletion.
+- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or unauthorized access patterns.
+- Examine the AWS IAM policies and permissions associated with the user or role to ensure they have the appropriate level of access and to identify any potential over-permissioning.
+- Look for any recent changes in the AWS environment, such as modifications to IAM roles or policies, that could have allowed unauthorized snapshot deletions.
+- If the event.action is "ModifyDBInstance" with "backupRetentionPeriod=0", verify if there was a legitimate reason for disabling automated backups and assess the impact on data recovery capabilities.
+
+### False positive analysis
+
+- Routine maintenance activities by database administrators may involve deleting old or unnecessary snapshots. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or tools used for database management might delete snapshots as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated IAM roles or user accounts.
+- Testing environments often involve frequent creation and deletion of snapshots. Consider excluding specific RDS instances or environments used solely for testing purposes to reduce noise in alerts.
+- Scheduled cleanup jobs that remove outdated snapshots to manage storage costs can trigger false positives. Document these jobs and adjust the detection rule to ignore actions performed by these jobs' IAM roles.
+
+### Response and remediation
+
+- Immediately revoke access to AWS accounts or roles suspected of unauthorized activity to prevent further malicious actions.
+- Restore the deleted RDS snapshots from any available backups or replicas to ensure data recovery and continuity.
+- Enable and configure automated backups for the affected RDS instances to prevent future data loss, ensuring the backupRetentionPeriod is set to a non-zero value.
+- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the snapshot deletion.
+- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources were compromised.
+- Implement stricter IAM policies and multi-factor authentication for accessing AWS RDS resources to enhance security and prevent unauthorized deletions.
+- Update and test the incident response plan to include specific procedures for handling AWS RDS snapshot deletions, ensuring rapid response in future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
index b6452e68392..7ecd7e47d37 100644
--- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
+++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ license = "Elastic License v2"
 name = "Potential AWS S3 Bucket Ransomware Note Uploaded"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded
 
diff --git a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
index 7c80014e43c..297134d25bd 100644
--- a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
+++ b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,7 @@ license = "Elastic License v2"
 name = "AWS S3 Object Encryption Using External KMS Key"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Object Encryption Using External KMS Key
 
diff --git a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
index 3e5550fa6ec..bcf3e6b7a20 100644
--- a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
+++ b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/08/02"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. 
+Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted.
 """
 false_positives = [
     """
@@ -21,7 +21,7 @@ license = "Elastic License v2"
 name = "AWS S3 Object Versioning Suspended"
 note = """
 
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS S3 Object Versioning Suspended
 
@@ -76,9 +76,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
+any where event.dataset == "aws.cloudtrail"
    and event.action == "PutBucketVersioning"
-   and event.outcome == "success" 
+   and event.outcome == "success"
    and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended")
 '''
 
diff --git a/rules/integrations/aws/initial_access_password_recovery.toml b/rules/integrations/aws/initial_access_password_recovery.toml
index 76273e283f6..da0af803ed0 100644
--- a/rules/integrations/aws/initial_access_password_recovery.toml
+++ b/rules/integrations/aws/initial_access_password_recovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Password Recovery Requested"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS IAM Password Recovery Requested
+
+AWS Identity and Access Management (IAM) facilitates secure access control to AWS resources. Password recovery requests are legitimate processes for users to regain access. However, adversaries may exploit this by initiating unauthorized recovery attempts to gain access. The detection rule monitors successful password recovery requests within AWS CloudTrail logs, focusing on initial access tactics, to identify potential misuse and unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.action:PasswordRecoveryRequested to identify the user account involved in the password recovery request.
+- Check the event.provider:signin.amazonaws.com logs to determine the source IP address and geolocation associated with the password recovery request to assess if it aligns with known user activity.
+- Investigate the event.outcome:success logs to confirm if the password recovery was completed and if there were any subsequent successful logins from the same or different IP addresses.
+- Analyze the user account's recent activity and permissions to identify any unusual or unauthorized actions that may indicate compromise.
+- Cross-reference the event with any other security alerts or incidents involving the same user account to identify potential patterns or coordinated attacks.
+- Contact the user associated with the password recovery request to verify if they initiated the request and to ensure their account security.
+
+### False positive analysis
+
+- Routine password recovery by legitimate users can trigger this rule. To manage this, identify users who frequently request password recovery and consider adding them to an exception list if their behavior is verified as non-threatening.
+- Automated password recovery processes used by internal IT support or helpdesk teams may also cause false positives. Coordinate with these teams to understand their workflows and exclude their activities from triggering alerts.
+- Users with known issues accessing their accounts due to technical problems might repeatedly request password recovery. Monitor these cases and exclude them once confirmed as non-malicious.
+- Scheduled security drills or training exercises that involve password recovery can generate alerts. Ensure these activities are documented and excluded from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the password recovery request by contacting the user associated with the request. Ensure they initiated the recovery process and are aware of the request.
+- Temporarily disable the affected IAM user account to prevent any unauthorized access until the situation is fully assessed and resolved.
+- Review AWS CloudTrail logs for any additional suspicious activities associated with the IAM user account, such as unusual login attempts or changes to permissions, to identify potential compromise.
+- If unauthorized access is confirmed, reset the IAM user's password and any associated access keys. Ensure the new credentials are communicated securely to the legitimate user.
+- Implement multi-factor authentication (MFA) for the affected IAM user account to enhance security and prevent future unauthorized access attempts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or resources have been compromised.
+- Update and enhance monitoring rules to detect similar unauthorized password recovery attempts in the future, ensuring timely alerts and responses.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"]
diff --git a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
index 7b3b75e46ad..551b1603889 100644
--- a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
+++ b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ['aws']
 maturity = "production"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
 
@@ -46,6 +46,41 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index
 | where mfa_used == "No"
 | keep @timestamp, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Signin Single Factor Console Login with Federated User
+
+Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. The detection rule identifies instances where federated users log in without MFA, flagging potential security risks by analyzing specific AWS CloudTrail events and dissecting login data to check for the absence of MFA, thus helping to mitigate unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider, event.action, and aws.cloudtrail.user_identity.type fields to ensure the alert corresponds to a federated user login without MFA.
+- Identify the federated user involved by examining the aws.cloudtrail.user_identity.arn field to determine which user or service is associated with the login attempt.
+- Check the aws.cloudtrail.additional_eventdata field to verify the mfa_used value is "No" and assess if this is expected behavior for the identified user or service.
+- Investigate the source IP address and location of the login attempt to determine if it aligns with typical access patterns for the federated user.
+- Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event.
+- Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users.
+
+### False positive analysis
+
+- Federated users with specific roles or permissions may frequently log in without MFA due to operational requirements. Review these roles and consider adding them to an exception list if they are deemed non-threatening.
+- Automated processes or scripts using federated credentials might trigger this rule if they are not configured to use MFA. Verify these processes and, if legitimate, exclude them from the rule to prevent unnecessary alerts.
+- Temporary testing or development accounts might be set up without MFA for convenience. Ensure these accounts are monitored and, if necessary, excluded from the rule to avoid false positives.
+- Third-party integrations or services that rely on federated access without MFA could be flagged. Assess these integrations and whitelist them if they are secure and necessary for business operations.
+- Users accessing AWS from secure, controlled environments might not use MFA as part of a risk-based authentication strategy. Evaluate the security of these environments and consider excluding them if they meet your organization's security standards.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the federated user account to prevent further unauthorized access.
+- Conduct a thorough review of AWS CloudTrail logs to identify any suspicious activities or unauthorized access attempts associated with the federated user account.
+- Notify the security team and relevant stakeholders about the potential security breach to ensure coordinated response efforts.
+- Implement or enforce multi-factor authentication (MFA) for all federated user accounts to enhance security and prevent similar incidents in the future.
+- Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege.
+- Escalate the incident to the incident response team if any malicious activities are detected, and initiate a full security investigation to assess the impact and scope of the breach.
+- Monitor AWS CloudTrail and other relevant logs closely for any further unauthorized access attempts or anomalies related to federated user accounts."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
index a32e91109c9..766039eb3d3 100644
--- a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
+++ b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "SSM Session Started to EC2 Instance"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating SSM Session Started to EC2 Instance
 
diff --git a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
index 153db90dc33..2b289fdefa6 100644
--- a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
+++ b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,42 @@ any where event.dataset == "aws.cloudtrail"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
    and stringContains (user.id, ":i-")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 Instance Console Login via Assumed Role
+
+AWS EC2 instances can assume roles to access resources securely, using temporary credentials. This mechanism, while essential for legitimate operations, can be exploited by adversaries who gain access to EC2 credentials, allowing them to assume roles and perform unauthorized actions. The detection rule identifies unusual console login activities by EC2 instances, flagging potential misuse by checking for specific session patterns and successful login events, thus helping to uncover lateral movement or credential access attempts.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event where event.dataset is "aws.cloudtrail" and event.provider is "signin.amazonaws.com" to gather more details about the login event.
+- Identify the EC2 instance associated with the session by examining the user.id field for the pattern ":i-" and correlate it with known EC2 instance IDs in your environment.
+- Check the AWS CloudTrail logs for any other activities performed by the same assumed role session to identify any unauthorized actions or lateral movement attempts.
+- Investigate the source IP address and geolocation of the login event to determine if it aligns with expected access patterns for your organization.
+- Verify the IAM role policies and permissions associated with the assumed role to assess the potential impact of the unauthorized access.
+- Review recent changes to the IAM roles and policies to identify any unauthorized modifications that could have facilitated the assumed role access.
+- Contact the instance owner or relevant team to confirm if the login activity was expected or authorized, and take appropriate action if it was not.
+
+### False positive analysis
+
+- Routine administrative tasks: EC2 instances may assume roles for legitimate administrative purposes, such as automated deployments or maintenance tasks. To manage this, identify and whitelist known administrative session patterns or specific instance IDs that regularly perform these tasks.
+- Monitoring and logging services: Some monitoring or logging services might use assumed roles to access AWS resources for data collection. Review and exclude these services by identifying their specific session patterns or instance IDs.
+- Scheduled jobs or scripts: Automated scripts or scheduled jobs running on EC2 instances might assume roles for resource access. Document these jobs and create exceptions for their session patterns to prevent false alerts.
+- Development and testing environments: Instances in development or testing environments might frequently assume roles for testing purposes. Consider excluding these environments from the rule or creating specific exceptions for known testing activities.
+- Third-party integrations: Some third-party tools or integrations might require EC2 instances to assume roles for functionality. Verify these integrations and exclude their session patterns or instance IDs from triggering alerts.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the compromised EC2 instance to prevent further unauthorized access.
+- Isolate the affected EC2 instance from the network to contain any potential lateral movement by the attacker.
+- Conduct a thorough review of CloudTrail logs to identify any unauthorized actions performed using the assumed role and assess the extent of the compromise.
+- Reset and rotate all credentials and access keys associated with the compromised EC2 instance and any other potentially affected resources.
+- Implement stricter IAM policies and role permissions to limit the scope of access for EC2 instances, ensuring the principle of least privilege is enforced.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to initiate any necessary legal or compliance procedures.
+- Enhance monitoring and alerting mechanisms to detect similar patterns of unusual console login activities in the future, ensuring rapid response to potential threats."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
index 0ec4ba8c4a3..ebe7c1ed629 100644
--- a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
+++ b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Network Access Control List Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 Network Access Control List Creation
+
+AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential unauthorized modifications that align with persistence tactics, aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role (event.user) that initiated the CreateNetworkAcl or CreateNetworkAclEntry actions.
+- Examine the event.provider:ec2.amazonaws.com logs to determine the IP addresses and locations associated with the request to assess if they are expected or suspicious.
+- Check the event.action details to understand the specific rules created in the Network ACL, focusing on any overly permissive rules that could indicate a security risk.
+- Investigate the event.outcome:success entries to confirm the successful creation of the ACL or ACL entry and correlate with any other suspicious activities in the AWS environment.
+- Cross-reference the event with other security alerts or logs to identify any patterns or anomalies that could suggest malicious intent or unauthorized access.
+- Assess the impact of the new ACL rules on the network security posture, ensuring they do not inadvertently allow unauthorized access or data exfiltration.
+
+### False positive analysis
+
+- Routine infrastructure updates or deployments may trigger the creation of new network ACLs or entries. To manage this, establish a baseline of expected changes during scheduled maintenance windows and exclude these from alerts.
+- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation can create network ACLs as part of normal operations. Identify and whitelist these automated processes to prevent unnecessary alerts.
+- Changes made by trusted administrators or security teams for legitimate purposes can be mistaken for suspicious activity. Implement a process to log and review approved changes, allowing you to exclude these from detection.
+- Temporary ACLs created for troubleshooting or testing purposes can generate alerts. Document and track these activities, and use tags or naming conventions to easily identify and exclude them from monitoring.
+- Third-party services or integrations that require specific network configurations might create ACLs. Review and validate these services, and if deemed safe, add them to an exception list to reduce false positives.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to confirm the creation of the Network ACL or entry and identify the IAM user or role responsible for the action. This helps determine if the action was authorized or potentially malicious.
+- Revoke any suspicious or unauthorized IAM credentials associated with the creation of the Network ACL or entry to prevent further unauthorized access.
+- Modify or delete the newly created Network ACL or entry if it is determined to be unauthorized or overly permissive, ensuring that it aligns with your organization's security policies.
+- Conduct a security review of the affected AWS environment to identify any other unauthorized changes or indicators of compromise, focusing on persistence mechanisms.
+- Implement additional monitoring and alerting for changes to Network ACLs and other critical AWS resources to enhance detection of similar threats in the future.
+- Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional containment or remediation actions are necessary.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized changes to network configurations.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
index c01a4fe6b96..8041dde9f4c 100644
--- a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
+++ b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Security Group Configuration Change"
-note = """
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 Security Group Configuration Change
+
+AWS EC2 Security Groups act as virtual firewalls, controlling inbound and outbound traffic to instances. Adversaries may exploit changes in these configurations to gain unauthorized access, maintain persistence, or exfiltrate data. The detection rule monitors successful modifications to security group settings, such as rule changes or new group creation, to identify potential security breaches and unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.dataset "aws.cloudtrail" to identify the exact changes made to the security group configuration.
+- Examine the event.provider "ec2.amazonaws.com" and event.action fields to determine the type of action performed, such as "AuthorizeSecurityGroupEgress" or "ModifySecurityGroupRules", to understand the nature of the change.
+- Check the event.outcome field to confirm the success of the action and correlate it with any suspicious activity or unauthorized access attempts.
+- Investigate the IAM user or role associated with the change to verify if the action aligns with their typical behavior and permissions.
+- Analyze the timing and context of the change to see if it coincides with any other unusual activities or alerts in the AWS environment.
+- Assess the impact of the security group change on the overall security posture, including potential exposure of sensitive resources or data.
+- If necessary, consult with the responsible team or individual to validate the legitimacy of the change and ensure it was authorized.
+
+### False positive analysis
+
+- Routine administrative changes to security groups by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who regularly perform these tasks and create exceptions for their activities.
+- Automated scripts or tools used for infrastructure management may frequently modify security group settings. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers or tags.
+- Scheduled updates or deployments that involve security group modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these expected changes during specific time windows.
+- Changes made by cloud service providers as part of their maintenance or updates might be flagged. Verify these changes through official communication from the provider and consider excluding them if they are part of standard operations.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instances by removing them from the compromised security group to prevent further unauthorized access.
+- Revert any unauthorized changes to the security group configurations by restoring them to their last known good state using AWS CloudTrail logs for reference.
+- Conduct a thorough review of IAM roles and permissions associated with the affected security groups to ensure that only authorized personnel have the ability to modify security group settings.
+- Implement additional monitoring and alerting for any future changes to security group configurations, focusing on the specific actions identified in the detection rule.
+- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related threats within the AWS environment.
+- Review and update the AWS security group policies to enforce stricter rules and minimize the attack surface, ensuring that only necessary ports and protocols are allowed.
+- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing logging and monitoring capabilities or applying stricter access controls.
+
 ### Investigating AWS EC2 Security Group Configuration Change
 
 This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.
diff --git a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
index 447c69c9399..76e29a4de1b 100644
--- a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
+++ b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL available in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/12/02"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,41 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS IAM Login Profile Added for Root"
-note = """
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS IAM Login Profile Added for Root
+
+AWS IAM allows management of user access and permissions within AWS environments. A login profile enables console access using a password. Adversaries may exploit temporary root access to create a login profile, ensuring persistent access even if keys are rotated. The detection rule identifies such actions by monitoring specific API calls and conditions, flagging unauthorized profile additions to root accounts.
+
+### Possible investigation steps
+
+- Review the @timestamp field to determine when the CreateLoginProfile action occurred and correlate it with any other suspicious activities around the same time.
+- Examine the aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id fields to identify the specific root account and access key involved in the action.
+- Investigate the source.address field to trace the IP address from which the CreateLoginProfile request originated, checking for any unusual or unauthorized locations.
+- Analyze the aws.cloudtrail.request_parameters and aws.cloudtrail.response_elements fields to understand the specifics of the login profile creation and verify if any unexpected parameters were used.
+- Check the cloud.account.id to confirm which AWS account was affected and assess if there are any other security incidents or alerts associated with this account.
+- Review the event.action field to ensure that no other unauthorized actions were performed by the root account around the same time.
+
+### False positive analysis
+
+- Administrative actions by trusted personnel may trigger the rule if they are performing legitimate maintenance or security tasks. To manage this, create exceptions for known administrative accounts by filtering their access key IDs.
+- Automated scripts or tools used for account management might inadvertently match the rule's conditions. Identify these scripts and exclude their specific access key IDs or user agents from the detection criteria.
+- Testing environments where root access is used for simulation or development purposes can cause false positives. Implement a tagging system for test environments and exclude logs with these tags from triggering the rule.
+- Third-party integrations that require root access for initial setup or configuration might be flagged. Document these integrations and adjust the rule to recognize and exclude their specific access patterns.
+
+### Response and remediation
+
+- Immediately revoke any active sessions and access keys associated with the root account to prevent further unauthorized access.
+- Reset the root account password and ensure that multi-factor authentication (MFA) is enabled for the root user to enhance security.
+- Review AWS CloudTrail logs to identify any other suspicious activities or changes made by the root account during the time of the incident.
+- Conduct a thorough audit of IAM policies and permissions to ensure that no other unauthorized changes have been made and that least privilege principles are enforced.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization.
+- Implement additional monitoring and alerting for root account activities to detect any future unauthorized access attempts promptly.
+- Consider engaging AWS Support or a third-party security expert if the incident's scope is beyond internal capabilities or if further forensic analysis is required.
+
 ## Investigating AWS IAM Login Profile Added for Root
 
 This rule detects when a login profile is added to the AWS root account. Adding a login profile to the root account, especially if self-assigned, is highly suspicious as it might indicate an adversary trying to establish persistence in the environment.
diff --git a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
index 787afc8f6ad..c5ae7aec9a1 100644
--- a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
+++ b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Create User via Assumed Role on EC2 Instance"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS IAM User Creation via Assumed Role on an EC2 Instance
 
diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml
index 5d678c72d7c..ca23bbb4585 100644
--- a/rules/integrations/aws/persistence_iam_group_creation.toml
+++ b/rules/integrations/aws/persistence_iam_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS IAM Group Creation
+
+AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. The detection rule monitors successful group creation events, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.provider: iam.amazonaws.com and event.action: CreateGroup to identify the user or service that initiated the group creation.
+- Check the event.dataset: aws.cloudtrail logs for any associated event.outcome: success entries to confirm the successful creation of the group.
+- Investigate the permissions assigned to the newly created group to assess if they include any sensitive or high-privilege permissions that could pose a security risk.
+- Identify and review the IAM user or role that created the group to determine if they have a legitimate reason for this action and if their activity aligns with their typical behavior.
+- Cross-reference the group creation event with other recent IAM activities, such as user additions to the group or changes to group policies, to detect any suspicious patterns or anomalies.
+- Consult with relevant stakeholders or the user responsible for the group creation to verify the legitimacy of the action and gather additional context if necessary.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate group creation activities to differentiate them from unauthorized actions.
+- Automated scripts or tools used for infrastructure management may create groups as part of their normal operation. Identify and whitelist these scripts to prevent unnecessary alerts.
+- Temporary groups created for short-term projects or testing purposes might be flagged. Implement a naming convention for such groups and exclude them from alerts based on this pattern.
+- Scheduled tasks or maintenance activities that involve group creation should be logged and approved in advance. Use these logs to create exceptions in the detection rule.
+- Third-party integrations or services that require group creation for functionality can cause false positives. Verify these integrations and adjust the rule to exclude their known actions.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the IAM group and identify the user or service responsible for the action.
+- Revoke any permissions associated with the newly created IAM group to prevent further unauthorized access or actions.
+- Temporarily disable or delete the unauthorized IAM group to contain the threat and prevent any potential misuse.
+- Conduct a thorough audit of recent IAM changes to identify any other unauthorized activities or anomalies that may indicate further compromise.
+- Escalate the incident to the security operations team for a detailed investigation and to assess the potential impact on the organization's security posture.
+- Implement additional monitoring and alerting for IAM group creation events to enhance detection capabilities and prevent similar incidents in the future.
+- Review and update IAM policies and permissions to ensure they follow the principle of least privilege, reducing the risk of unauthorized access.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
index 1d800bd6854..9bcc42842a8 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Roles Anywhere Profile Creation"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS IAM Roles Anywhere Profile Creation
 
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
index d55e1007ae7..bdaf5811c53 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA
 
diff --git a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
index 7bc76bfde42..d81faf28ac5 100644
--- a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
+++ b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Lambda Function Policy Updated to Allow Public Invocation"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation
 
diff --git a/rules/integrations/aws/persistence_rds_cluster_creation.toml b/rules/integrations/aws/persistence_rds_cluster_creation.toml
index 352fd7c484b..8bc74a442ed 100644
--- a/rules/integrations/aws/persistence_rds_cluster_creation.toml
+++ b/rules/integrations/aws/persistence_rds_cluster_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Cluster Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS Cluster Creation
+
+Amazon RDS facilitates database management by automating tasks like hardware provisioning and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes, thus aiding in identifying unauthorized activities.
+
+### Possible investigation steps
+
+- Review the event details in AWS CloudTrail to confirm the event.dataset is 'aws.cloudtrail' and the event.provider is 'rds.amazonaws.com', ensuring the alert is based on the correct data source.
+- Verify the identity of the user or service account that initiated the CreateDBCluster or CreateGlobalCluster action by examining the user identity information in the event logs.
+- Check the event time and correlate it with any other suspicious activities or alerts in the same timeframe to identify potential patterns or coordinated actions.
+- Investigate the source IP address and geolocation associated with the event to determine if it aligns with expected access patterns or if it indicates unauthorized access.
+- Assess the configuration and settings of the newly created RDS cluster, including security groups, network settings, and any associated IAM roles, to identify potential security misconfigurations or vulnerabilities.
+- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse.
+
+### False positive analysis
+
+- Routine maintenance or testing activities by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly.
+- Automated scripts or tools used for infrastructure management might create RDS clusters as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers.
+- Scheduled deployments or updates that involve creating new RDS clusters can be mistaken for unauthorized activity. Document these schedules and configure the detection rule to ignore events during these timeframes.
+- Development or staging environments often involve frequent creation and deletion of RDS clusters. Exclude these environments from monitoring by filtering based on environment-specific tags or naming conventions.
+- Partner or third-party integrations that require creating RDS clusters should be reviewed and whitelisted if deemed non-threatening, ensuring that their actions do not generate false positives.
+
+### Response and remediation
+
+- Immediately isolate the newly created RDS cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review CloudTrail logs to identify the IAM user or role responsible for the creation of the RDS cluster. Verify if the action was authorized and if the credentials have been compromised.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
+- Conduct a thorough audit of the RDS cluster configuration and data to assess any potential data exposure or integrity issues. If sensitive data is involved, consider notifying relevant stakeholders and following data breach protocols.
+- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.
+- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized RDS cluster creation in the future.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
index ac4bbc343f9..203d1936cff 100644
--- a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
+++ b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml
@@ -2,12 +2,12 @@
 creation_date = "2024/06/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation. 
+Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation.
 """
 false_positives = [
     """
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance or Cluster Password Modified"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Instance or Cluster Password Modified
 
diff --git a/rules/integrations/aws/persistence_rds_group_creation.toml b/rules/integrations/aws/persistence_rds_group_creation.toml
index 1140f4e4ef5..6e7b4f6e201 100644
--- a/rules/integrations/aws/persistence_rds_group_creation.toml
+++ b/rules/integrations/aws/persistence_rds_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,7 +20,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Security Group Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS Security Group Creation
+
+Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group.
+- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group.
+- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities.
+- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns.
+- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations.
+- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them.
+- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions.
+- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames.
+- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action.
+- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration.
+- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence.
+- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats.
+- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html"]
diff --git a/rules/integrations/aws/persistence_rds_instance_creation.toml b/rules/integrations/aws/persistence_rds_instance_creation.toml
index ba167a1cb93..8cc4d38b7fc 100644
--- a/rules/integrations/aws/persistence_rds_instance_creation.toml
+++ b/rules/integrations/aws/persistence_rds_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -20,7 +20,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS RDS Instance Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS Instance Creation
+
+Amazon RDS simplifies database management by automating tasks like provisioning and scaling. However, adversaries may exploit this by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creations, focusing on specific AWS CloudTrail events, to identify potential misuse and ensure asset visibility.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific event.action:CreateDBInstance to gather details about the RDS instance creation, including the timestamp, user identity, and source IP address.
+- Verify the user identity associated with the event to determine if the action was performed by an authorized user or service account. Check for any anomalies in user behavior or access patterns.
+- Investigate the source IP address to identify if it is associated with known internal or external entities, and assess if it aligns with expected network activity.
+- Examine the AWS account and region where the RDS instance was created to ensure it aligns with organizational policies and expected usage patterns.
+- Check for any related events or activities in CloudTrail logs around the same timeframe, such as modifications to security groups or IAM policies, which might indicate further unauthorized actions.
+- Assess the configuration and settings of the newly created RDS instance, including database engine, instance class, and network settings, to ensure they comply with security and compliance standards.
+
+### False positive analysis
+
+- Routine maintenance or testing activities by authorized personnel may trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts involved in these activities.
+- Automated scripts or tools used for legitimate database provisioning can cause false positives. Identify these scripts and exclude their associated user accounts or roles from triggering alerts.
+- Development or staging environments often have frequent instance creations that are non-threatening. Exclude these environments by filtering based on tags or specific resource identifiers.
+- Third-party integrations or services that require RDS instance creation might be flagged. Review and whitelist these services by their IAM roles or API calls.
+- Scheduled scaling operations that automatically create instances can be mistaken for unauthorized activity. Document and exclude these operations by their specific time frames or automation identifiers.
+
+### Response and remediation
+
+- Immediately isolate the newly created RDS instance to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review the CloudTrail logs to identify the IAM user or role responsible for the RDS instance creation. Verify if the action was authorized and if the credentials have been compromised.
+- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions.
+- Conduct a thorough audit of the RDS instance configuration, including database parameters and access controls, to ensure no sensitive data has been exposed or altered.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to determine if additional systems have been affected.
+- Implement additional monitoring and alerting for unusual RDS activities, such as unexpected instance creations or modifications, to enhance detection capabilities.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have the necessary permissions to create RDS instances.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html"]
diff --git a/rules/integrations/aws/persistence_rds_instance_made_public.toml b/rules/integrations/aws/persistence_rds_instance_made_public.toml
index 8c40eeebabd..9257864e236 100644
--- a/rules/integrations/aws/persistence_rds_instance_made_public.toml
+++ b/rules/integrations/aws/persistence_rds_instance_made_public.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "AWS RDS DB Instance Made Public"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS RDS DB Instance Made Public
 
@@ -42,7 +42,7 @@ This rule identifies when an RDS DB instance is created or modified to enable pu
 
 ### Response and Remediation
 
-- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes. 
+- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes.
 - **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
 - **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege.
 - **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access.
@@ -81,7 +81,7 @@ any where event.dataset == "aws.cloudtrail"
     and event.outcome == "success"
     and (
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true"))
-        or 
+        or
         (event.action in ("CreateDBInstance", "CreateDBCluster") and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true"))
     )
 '''
diff --git a/rules/integrations/aws/persistence_redshift_instance_creation.toml b/rules/integrations/aws/persistence_redshift_instance_creation.toml
index ee4a8e87d42..2164a87333c 100644
--- a/rules/integrations/aws/persistence_redshift_instance_creation.toml
+++ b/rules/integrations/aws/persistence_redshift_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Redshift Cluster Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Redshift Cluster Creation
+
+Amazon Redshift is a data warehousing service that allows for scalable data storage and analysis. In a secure environment, only authorized users should create Redshift clusters. Adversaries might exploit misconfigured permissions to create clusters, potentially leading to data exfiltration or unauthorized data processing. The detection rule monitors for successful cluster creation events, especially by non-admin users, to identify potential misuse or misconfigurations.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the event.dataset:aws.cloudtrail and event.provider:redshift.amazonaws.com to confirm the details of the CreateCluster event, including the timestamp and the user who initiated the action.
+- Identify the IAM role or user associated with the event.action:CreateCluster and verify if this user is expected to have permissions to create Redshift clusters. Check for any recent changes to their permissions or roles.
+- Investigate the event.outcome:success to ensure that the cluster creation was indeed successful and determine the region and account where the cluster was created.
+- Examine the configuration of the newly created Redshift cluster to ensure it adheres to security best practices, such as encryption settings, VPC configurations, and access controls.
+- Cross-reference the user activity with other logs or alerts to identify any unusual patterns or behaviors that might indicate misuse or compromise, such as multiple cluster creation attempts or access from unfamiliar IP addresses.
+- Contact the user or team responsible for the account to verify if the cluster creation was intentional and authorized, and document their response for future reference.
+
+### False positive analysis
+
+- Routine maintenance or testing activities by non-admin users can trigger alerts. To manage this, create exceptions for specific users or roles known to perform these tasks regularly.
+- Automated scripts or third-party tools that create clusters as part of their normal operation may cause false positives. Identify these tools and exclude their associated user accounts or roles from the detection rule.
+- Development or staging environments where non-admin users are permitted to create clusters for testing purposes can lead to alerts. Implement environment-specific exclusions to prevent unnecessary alerts.
+- Temporary permissions granted to non-admin users for specific projects can result in cluster creation alerts. Monitor and document these permissions, and adjust the detection rule to account for these temporary changes.
+
+### Response and remediation
+
+- Immediately isolate the Redshift cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic.
+- Review the IAM roles and permissions associated with the user who created the cluster. Revoke any unnecessary permissions and ensure that the principle of least privilege is enforced.
+- Conduct a thorough audit of recent CloudTrail logs to identify any other unauthorized activities or anomalies associated with the same user or related accounts.
+- If data exfiltration is suspected, initiate a data integrity check and consider restoring from a known good backup to ensure no data tampering has occurred.
+- Notify the security team and relevant stakeholders about the incident for further investigation and to determine if additional security measures are needed.
+- Implement additional monitoring and alerting for Redshift cluster creation events, especially focusing on non-administrative users, to quickly detect similar activities in the future.
+- Consider enabling multi-factor authentication (MFA) for all users with permissions to create or modify Redshift clusters to add an extra layer of security.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateCluster.html"]
diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
index 3adaff849fd..034fb0b3227 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -23,7 +23,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route 53 Domain Transfer Lock Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Route 53 Domain Transfer Lock Disabled
+
+AWS Route 53's domain transfer lock is a security feature that prevents unauthorized domain transfers. Disabling this lock can expose domains to hijacking risks. Adversaries might exploit this by transferring domains to gain control over web traffic or disrupt services. The detection rule monitors successful lock disablement events, alerting analysts to potential unauthorized actions, thereby aiding in maintaining domain integrity.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.action: DisableDomainTransferLock to identify the user or service account responsible for the action.
+- Check the event.provider: route53.amazonaws.com logs to gather additional context about the domain affected and any related activities around the time of the lock disablement.
+- Verify the event.outcome: success to confirm that the lock was indeed successfully disabled and not just attempted.
+- Investigate the account activity of the user identified in the logs to determine if there are any other suspicious actions or patterns that could indicate unauthorized access.
+- Assess whether there was a legitimate business need for the domain transfer lock to be disabled, such as a planned domain transfer, by consulting with relevant stakeholders or reviewing change management records.
+- Evaluate the current security posture of the affected domain, ensuring that other security measures are in place to mitigate potential risks from the lock being disabled.
+
+### False positive analysis
+
+- Routine domain management activities by authorized personnel can trigger alerts when they intentionally disable the transfer lock for legitimate domain transfers. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list.
+- Scheduled domain transfers as part of business operations may result in false positives. Implement a process to document and pre-approve such transfers, allowing security teams to quickly verify and dismiss these alerts.
+- Automated scripts or tools used for domain management might inadvertently disable the transfer lock during updates or maintenance. Ensure these tools are configured correctly and include logging to track their actions, allowing for quick identification and exclusion of benign activities.
+- Changes in domain ownership or restructuring within the organization can lead to legitimate transfer lock disablement. Establish a communication protocol between IT and security teams to notify them of such changes in advance, reducing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the domain transfer request by contacting the domain owner or the responsible team to confirm if the action was intentional.
+- If the transfer lock was disabled without authorization, re-enable the transfer lock on the affected domain to prevent any unauthorized transfer attempts.
+- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access or suspicious activities related to the domain management account.
+- Reset credentials and enforce multi-factor authentication (MFA) for all accounts with access to AWS Route 53 to prevent further unauthorized actions.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response.
+- Escalate the incident to higher management and legal teams if there is evidence of malicious intent or if the domain is critical to business operations.
+- Implement additional monitoring and alerting for any future changes to domain transfer locks to ensure rapid detection and response to similar threats.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
index 758c5f25b39..ee78e5e193b 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route 53 Domain Transferred to Another Account"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Route 53 Domain Transferred to Another Account
+
+AWS Route 53 is a scalable domain name system (DNS) web service designed to route end-user requests to internet applications. Transferring a domain to another AWS account can be legitimate but may also indicate unauthorized access or account manipulation. Adversaries might exploit this to gain persistent control over a domain. The detection rule monitors successful domain transfer requests, flagging potential misuse by correlating specific AWS CloudTrail events, thus aiding in identifying unauthorized domain transfers.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the specific event with event.action:TransferDomainToAnotherAwsAccount and event.outcome:success to gather details about the domain transfer request.
+- Verify the identity of the AWS account to which the domain was transferred by examining the event details, including the account ID and any associated user or role information.
+- Check the AWS account's activity history for any unusual or unauthorized access patterns around the time of the domain transfer event.
+- Contact the domain's original owner or administrator to confirm whether the transfer was authorized and legitimate.
+- Investigate any recent changes in IAM policies or permissions that might have allowed unauthorized users to initiate the domain transfer.
+- Assess the potential impact of the domain transfer on your organization's operations and security posture, considering the domain's role in your infrastructure.
+
+### False positive analysis
+
+- Routine domain transfers between accounts within the same organization can trigger alerts. To manage this, create exceptions for known internal account transfers by whitelisting specific account IDs involved in regular transfers.
+- Scheduled domain management activities by IT teams may result in false positives. Coordinate with IT to document and schedule these activities, then exclude them from alerts during these periods.
+- Automated scripts or tools used for domain management might inadvertently trigger alerts. Identify these scripts and their associated user accounts, and configure exceptions for these known, benign activities.
+- Transfers related to mergers or acquisitions can be mistaken for unauthorized actions. Ensure that such events are communicated to the security team in advance, allowing them to temporarily adjust monitoring rules to accommodate these legitimate transfers.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized access to the AWS account by changing the credentials and access keys associated with the account where the domain was transferred.
+- Contact AWS Support to report the unauthorized domain transfer and request assistance in reversing the transfer if it was not authorized.
+- Review AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts around the time of the domain transfer.
+- Implement multi-factor authentication (MFA) for all AWS accounts to enhance security and prevent unauthorized access.
+- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to transfer domains.
+- Notify relevant stakeholders, including IT security teams and domain administrators, about the incident and the steps being taken to remediate it.
+- Enhance monitoring and alerting for similar events by configuring additional AWS CloudWatch alarms or integrating with a Security Information and Event Management (SIEM) system to detect future unauthorized domain transfer attempts.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html"]
diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
index 50c7b0fa2ed..6bc5d1a3a35 100644
--- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
+++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -20,7 +20,41 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route53 private hosted zone associated with a VPC"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Route53 private hosted zone associated with a VPC
+
+AWS Route53 private hosted zones allow for DNS management within a Virtual Private Cloud (VPC), ensuring internal resources are accessible only within the VPC. Adversaries might exploit this by associating unauthorized VPCs to intercept or reroute traffic. The detection rule identifies successful associations of VPCs with hosted zones, signaling potential misuse or unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the event.dataset:aws.cloudtrail and event.provider:route53.amazonaws.com to gather details about the AssociateVPCWithHostedZone action, including the time of the event and the identity of the user or role that performed the action.
+- Verify the event.outcome:success to confirm that the association was successful and identify the specific VPC and hosted zone involved in the association.
+- Check the AWS IAM policies and permissions of the user or role that initiated the association to ensure they have the appropriate level of access and determine if the action aligns with their expected responsibilities.
+- Investigate the associated VPC to determine if it is authorized and expected to be linked with the private hosted zone. Look for any unusual or unauthorized VPCs that may indicate potential misuse.
+- Review recent changes or activities in the AWS account to identify any other suspicious actions or patterns that could suggest a broader security incident or compromise.
+
+### False positive analysis
+
+- Routine infrastructure changes may trigger this rule when legitimate VPCs are associated with private hosted zones during regular operations. To manage this, maintain an updated list of authorized VPCs and compare them against the detected associations.
+- Automated deployment tools or scripts that frequently associate VPCs with hosted zones can cause false positives. Identify these tools and create exceptions for their known activities to reduce noise.
+- Development and testing environments often involve frequent changes and associations of VPCs with hosted zones. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds.
+- Scheduled maintenance or updates might involve temporary associations of VPCs with hosted zones. Document these schedules and incorporate them into the monitoring system to prevent false alerts during these periods.
+
+### Response and remediation
+
+- Immediately isolate the VPC associated with the unauthorized Route53 private hosted zone to prevent further unauthorized access or data exfiltration.
+- Review CloudTrail logs to identify the source and method of the unauthorized VPC association, focusing on the user or role that performed the action.
+- Revoke any unauthorized access or permissions identified during the log review, particularly those related to the IAM roles or users involved in the incident.
+- Conduct a security review of the affected VPC and associated resources to ensure no other configurations have been tampered with or compromised.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation.
+- Implement additional monitoring and alerting for similar events in the future, ensuring that any unauthorized associations are detected promptly.
+- Review and update IAM policies and security group rules to enforce the principle of least privilege, reducing the risk of similar incidents occurring.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html"]
diff --git a/rules/integrations/aws/persistence_route_table_created.toml b/rules/integrations/aws/persistence_route_table_created.toml
index c254309c058..97f6c434e2c 100644
--- a/rules/integrations/aws/persistence_route_table_created.toml
+++ b/rules/integrations/aws/persistence_route_table_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route Table Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Route Table Created
+
+AWS Route Tables are crucial components in managing network traffic within AWS environments, directing data between subnets and internet gateways. Adversaries may exploit route tables to reroute traffic for data exfiltration or to establish persistence by creating unauthorized routes. The detection rule monitors successful creation events of route tables, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized network configuration changes.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.provider:ec2.amazonaws.com and event.action values (CreateRoute or CreateRouteTable) to identify the user or role that initiated the route table creation.
+- Check the event.outcome:success field to confirm the successful creation of the route table and gather additional context such as timestamps and source IP addresses.
+- Investigate the associated AWS account and IAM user or role to determine if the action aligns with expected behavior and permissions.
+- Examine the newly created route table's configuration to identify any unauthorized or suspicious routes that could indicate potential misuse or data exfiltration attempts.
+- Correlate the event with other network security monitoring data to identify any unusual traffic patterns or anomalies that coincide with the route table creation.
+- Assess the environment for any recent changes or incidents that might explain the creation of the route table, such as new deployments or infrastructure modifications.
+
+### False positive analysis
+
+- Routine infrastructure updates or deployments may trigger route table creation events. To manage this, establish a baseline of expected behavior during scheduled maintenance windows and exclude these from alerts.
+- Automated cloud management tools often create route tables as part of their operations. Identify these tools and create exceptions for their known activities to reduce noise.
+- Development and testing environments frequently undergo changes, including the creation of route tables. Consider excluding these environments from alerts or applying a different set of monitoring rules.
+- Legitimate changes by authorized personnel can be mistaken for suspicious activity. Implement a process to verify and document authorized changes, allowing for quick exclusion of these events from alerts.
+- Multi-account AWS setups might have centralized networking teams that create route tables across accounts. Coordinate with these teams to understand their activities and exclude them from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS account or VPC to prevent further unauthorized network changes and potential data exfiltration.
+- Review the newly created route table and any associated routes to identify unauthorized entries. Remove any routes that are not part of the expected network configuration.
+- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to create or modify route tables. Revoke any excessive permissions identified.
+- Implement network monitoring to detect unusual traffic patterns that may indicate data exfiltration or other malicious activities.
+- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised.
+- Review AWS CloudTrail logs for any other suspicious activities around the time of the route table creation to identify potential indicators of compromise.
+- Update security policies and procedures to include specific guidelines for monitoring and responding to unauthorized route table modifications, ensuring rapid detection and response in the future.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
index 8829dc1659b..b6f0f019f77 100644
--- a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
+++ b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS Route Table Modified or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Route Table Modified or Deleted
+
+AWS Route Tables are crucial for directing network traffic within a VPC. Adversaries may exploit these by altering or deleting routes to disrupt services or reroute traffic for data exfiltration. The detection rule monitors AWS CloudTrail logs for specific actions like route replacement or deletion, signaling potential unauthorized modifications that could indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the specific user or role associated with the event.provider:ec2.amazonaws.com actions such as ReplaceRoute, ReplaceRouteTableAssociation, DeleteRouteTable, DeleteRoute, or DisassociateRouteTable.
+- Check the event.time field in the CloudTrail logs to determine the exact time of the modification or deletion and correlate it with any other suspicious activities or alerts around the same timeframe.
+- Investigate the source IP address and location from which the changes were made to assess if they align with expected administrative access patterns.
+- Examine the AWS IAM policies and permissions associated with the user or role to determine if they have legitimate access to modify or delete route tables.
+- Review recent changes in the AWS environment, such as new deployments or updates, to understand if the route table modifications were part of planned activities.
+- Contact the user or team responsible for the changes to verify if the actions were authorized and intended as part of routine operations.
+
+### False positive analysis
+
+- Routine infrastructure updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
+- Automated scripts or tools used for infrastructure management might modify route tables as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user agent strings or IAM roles.
+- Changes made by cloud service providers during updates or optimizations can also appear as modifications. Monitor communications from AWS for scheduled changes and temporarily adjust detection rules to accommodate these events.
+- Development and testing environments often undergo frequent changes that are non-threatening. Consider excluding these environments from the rule or applying a different risk threshold to reduce noise.
+- Multi-account setups where centralized management tools modify route tables across accounts can lead to false positives. Implement account-specific exclusions or adjust the rule to recognize these centralized actions.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC to prevent further unauthorized access or data exfiltration. This can be done by temporarily modifying security group rules to restrict inbound and outbound traffic.
+- Review the AWS CloudTrail logs to identify the source of the unauthorized modifications. Focus on the user identity, IP address, and time of the event to understand the scope and origin of the threat.
+- Revert any unauthorized changes to the route tables by restoring them to their last known good configuration. This may involve manually recreating deleted routes or associations.
+- Implement IAM policies to restrict permissions for modifying route tables to only essential personnel. Ensure that the principle of least privilege is enforced.
+- Enable AWS Config to continuously monitor and record configuration changes to route tables, providing an audit trail for future incidents.
+- Set up CloudWatch Alarms to alert on any future unauthorized modifications to route tables, ensuring rapid detection and response.
+- If the incident is confirmed as malicious, escalate to the security operations team for further investigation and potential involvement of AWS support or legal authorities.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
index c4dcc60e1a5..bee33bee0ab 100644
--- a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
+++ b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/10/25"
+updated_date = "2025/01/10"
 
 
 [rule]
@@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS AssumeRole with New MFA Device"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS STS AssumeRole with New MFA Device
+
+AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the user.id field to determine if the user is legitimate and authorized to use the new MFA device.
+- Check the serialNumber in the aws.cloudtrail.flattened.request_parameters to verify the registration and legitimacy of the new MFA device associated with the role assumption.
+- Investigate the context of the AssumeRole action by examining the event.action field to understand if it was part of a legitimate workflow or an unusual activity.
+- Analyze the event.outcome field to confirm the success of the role assumption and cross-reference with any recent changes in user permissions or MFA device registrations.
+- Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe.
+- Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized.
+
+### False positive analysis
+
+- New employee onboarding processes may trigger this rule when new MFA devices are issued. To manage this, create exceptions for known onboarding activities by correlating with HR records or onboarding schedules.
+- Routine device replacements or upgrades can result in new MFA devices being registered. Implement a process to track and verify device changes through IT support tickets or asset management systems.
+- Users with multiple roles or responsibilities might frequently switch roles using different MFA devices. Establish a baseline of normal behavior for these users and create exceptions for their typical activity patterns.
+- Organizational policy changes that require MFA updates can lead to multiple new MFA device registrations. Coordinate with security teams to whitelist these events during policy rollout periods.
+- Temporary contractors or third-party vendors may use new MFA devices when accessing AWS resources. Ensure that their access is logged and reviewed, and create temporary exceptions for their known access periods.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the assumed role to prevent unauthorized access to AWS resources.
+- Verify the legitimacy of the new MFA device by contacting the user or administrator associated with the role assumption. Confirm whether the device was intentionally registered and used.
+- If the new MFA device is determined to be unauthorized, disable or remove it from the user's account to prevent further misuse.
+- Conduct a review of recent AWS CloudTrail logs to identify any suspicious activities or patterns associated with the user or role in question, focusing on privilege escalation or lateral movement attempts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.
+- Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future.
+- Review and update IAM policies and MFA device management procedures to ensure they align with best practices for security and access control.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
index 1e152b855ff..54083cbcec8 100644
--- a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
+++ b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Instance Connect SSH Public Key Uploaded"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS EC2 Instance Connect SSH Public Key Uploaded
 
diff --git a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
index 0e20b0ca5e4..edba032c682 100644
--- a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Customer-Managed Policy Attached to Role by Rare User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS IAM Customer-Managed Policy Attachment to Role by Unusual User
 
diff --git a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
index 7d54a01401c..6ed6e68ae9c 100644
--- a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/16"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -19,7 +19,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM SAML Provider Updated"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS IAM SAML Provider Updated
+
+AWS IAM SAML providers facilitate federated access, allowing users to authenticate via external identity providers. Adversaries may exploit this by updating SAML providers to gain unauthorized access or escalate privileges. The detection rule monitors successful updates to SAML providers, flagging potential privilege escalation attempts by correlating specific AWS CloudTrail events.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role associated with the UpdateSAMLProvider event. Check for any unusual or unauthorized users making changes.
+- Examine the context of the UpdateSAMLProvider event, including the time of the event and any associated IP addresses or locations, to identify any anomalies or suspicious patterns.
+- Investigate the history of changes to the specific SAML provider to determine if there have been any recent unauthorized or unexpected modifications.
+- Check for any other related AWS CloudTrail events around the same timeframe, such as changes to IAM roles or policies, which might indicate a broader privilege escalation attempt.
+- Assess the permissions and access levels of the user or role that performed the update to ensure they align with expected privileges and responsibilities.
+- If suspicious activity is confirmed, consider revoking or limiting access for the involved user or role and review the security posture of the AWS environment to prevent future incidents.
+
+### False positive analysis
+
+- Routine administrative updates to SAML providers by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their expected activities, and create exceptions for these users in the detection rule.
+- Scheduled updates or maintenance activities involving SAML providers may also result in false positives. Document these activities and adjust the detection rule to exclude events occurring during these scheduled times.
+- Automated scripts or tools used for managing SAML providers can generate alerts if they perform updates. Identify these scripts and their expected behavior, then configure the detection rule to recognize and exclude these specific actions.
+- Changes made by trusted third-party services integrated with AWS IAM might be flagged. Verify the legitimacy of these services and consider adding them to an allowlist to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized changes to the SAML provider by restoring the previous configuration from backups or logs.
+- Conduct a thorough review of recent IAM activity logs to identify any unauthorized access or privilege escalation attempts associated with the updated SAML provider.
+- Temporarily disable the affected SAML provider to prevent further unauthorized access while the investigation is ongoing.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for any future changes to SAML providers to ensure rapid detection of unauthorized modifications.
+- Review and tighten IAM policies and permissions to ensure that only authorized personnel can update SAML providers.
+- Consider implementing multi-factor authentication (MFA) for all users with permissions to modify IAM configurations to enhance security.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
index c23ae37fbfb..7da0d23fada 100644
--- a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
+++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS Role Assumption by Service"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS STS Role Assumption by Service
 
diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
index da41ca73b82..b5c3eb59cee 100644
--- a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
+++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS Role Assumption by User"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating AWS STS Role Assumption by User
 
diff --git a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
index 3bb48c3b9a7..36cb87e2ac7 100644
--- a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/24"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS AssumeRoot by Rare User and Member Account"
 note = """
-## Triage and Analysis
+## Triage and analysis
 
 ### Investigating AWS STS AssumeRoot by Rare User and Member Account
 
diff --git a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
index 7bde75f679e..f39eaf92ea8 100644
--- a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS GetSessionToken Abuse"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS STS GetSessionToken Abuse
+
+AWS Security Token Service (STS) provides temporary credentials for AWS resources, crucial for managing access without long-term credentials. Adversaries may exploit GetSessionToken to create temporary credentials, enabling lateral movement and privilege escalation. The detection rule identifies successful GetSessionToken requests by IAM users, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs for the specific GetSessionToken event to gather details about the IAM user involved, including the time of the request and the source IP address.
+- Check the IAM user's activity history to identify any unusual patterns or deviations from their normal behavior, such as accessing resources they typically do not use.
+- Investigate the source IP address from which the GetSessionToken request originated to determine if it is associated with known malicious activity or if it is an unexpected location for the user.
+- Examine the permissions and roles associated with the temporary credentials issued by the GetSessionToken request to assess the potential impact of their misuse.
+- Correlate the GetSessionToken event with other security events or alerts in the same timeframe to identify any related suspicious activities or potential indicators of compromise.
+
+### False positive analysis
+
+- Routine administrative tasks by IAM users can trigger GetSessionToken requests. To manage this, identify and whitelist IAM users or roles that regularly perform these tasks as part of their job functions.
+- Automated scripts or applications that use GetSessionToken for legitimate purposes may cause false positives. Review and document these scripts, then create exceptions for their activity in the detection rule.
+- Scheduled jobs or services that require temporary credentials for periodic tasks might be flagged. Ensure these are documented and excluded from alerts by adjusting the rule to recognize their specific patterns.
+- Development and testing environments often generate GetSessionToken requests during normal operations. Consider excluding these environments from the rule or adjusting the risk score to reflect their lower threat level.
+- Cross-account access scenarios where users from one account access resources in another using temporary credentials can appear suspicious. Verify these access patterns and exclude them if they are part of regular operations.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the suspicious GetSessionToken request to prevent further unauthorized access.
+- Conduct a thorough review of the IAM user's activity logs to identify any unauthorized actions or access patterns that may indicate lateral movement or privilege escalation.
+- Isolate any affected resources or accounts to contain potential threats and prevent further exploitation.
+- Reset the credentials of the IAM user involved and enforce multi-factor authentication (MFA) to enhance security.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for unusual GetSessionToken requests to detect similar activities in the future.
+- Review and tighten IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of privilege escalation.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html"]
diff --git a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
index 8fad43bd2ff..eaf83a850fa 100644
--- a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/23"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/10/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,43 @@ from = "now-6m"
 language = "esql"
 license = "Elastic License v2"
 name = "AWS STS Role Chaining"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS STS Role Chaining
+
+AWS Security Token Service (STS) allows temporary, limited-privilege credentials for AWS resources. Role chaining involves using one temporary role to assume another, potentially escalating privileges. Adversaries exploit this by gaining elevated access or persistence. The detection rule identifies such activity by monitoring specific API calls and access patterns within a single account, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the source of the AssumeRole API call by examining the aws.cloudtrail.user_identity.arn field to determine which user or service initiated the role chaining.
+- Check the cloud.region field to understand the geographical context of the activity and assess if it aligns with expected operational regions for your organization.
+- Investigate the aws.cloudtrail.resources.account_id and aws.cloudtrail.recipient_account_id fields to confirm that the role chaining activity occurred within the same account, as cross-account role chaining is not flagged by this rule.
+- Analyze the aws.cloudtrail.user_identity.access_key_id to verify that the access key used is a temporary token starting with "ASIA", indicating the use of temporary credentials.
+- Assess the permissions associated with the roles involved in the chaining to determine if the subsequent role provides elevated privileges that could be exploited for privilege escalation or persistence.
+- Correlate the timing of the AssumeRole events with other security events or alerts to identify any suspicious patterns or activities that may indicate malicious intent.
+
+### False positive analysis
+
+- Cross-account role assumptions are common in many AWS environments and can generate false positives. To mitigate this, ensure the rule is configured to only monitor role chaining within a single account, as specified in the rule description.
+- Automated processes or applications that frequently assume roles for legitimate purposes may trigger false positives. Identify these processes and create exceptions for their specific access patterns or user identities.
+- Scheduled tasks or scripts that use temporary credentials for routine operations might be flagged. Review these tasks and whitelist their access key IDs if they consistently follow a predictable and secure pattern.
+- Development and testing environments often involve frequent role assumptions for testing purposes. Exclude these environments from monitoring or adjust the rule to account for their unique access behaviors.
+- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately revoke the temporary credentials associated with the detected AssumeRole activity to prevent further unauthorized access.
+- Conduct a thorough review of the AWS CloudTrail logs to identify any additional suspicious activities or roles assumed using the compromised credentials.
+- Isolate the affected AWS resources and accounts to prevent lateral movement and further privilege escalation within the environment.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement stricter IAM policies and role permissions to limit the ability to assume roles unnecessarily, reducing the risk of privilege escalation.
+- Enhance monitoring and alerting for AssumeRole activities, especially those involving temporary credentials, to detect similar threats in the future.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts.
+
+## Setup
 
 The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
index b3ffe646b7d..06c916b8ae7 100644
--- a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
+++ b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Event Hub Authorization Rule Created or Updated"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Event Hub Authorization Rule Created or Updated
+
+Azure Event Hub Authorization Rules manage access to Event Hubs via cryptographic keys, akin to administrative credentials. Adversaries may exploit these rules to gain unauthorized access or escalate privileges, potentially exfiltrating data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal associated with the operation by examining the `azure.activitylogs.operation_name` and `event.outcome` fields.
+- Check the timestamp of the event to determine when the authorization rule was created or updated, and correlate this with any other suspicious activities around the same time.
+- Investigate the specific Event Hub namespace affected by the rule change to understand its role and importance within the organization.
+- Verify if the `RootManageSharedAccessKey` or any other high-privilege authorization rule was involved, as these carry significant risk if misused.
+- Assess the necessity and legitimacy of the rule change by contacting the user or team responsible for the Event Hub namespace to confirm if the change was authorized and aligns with operational needs.
+- Examine any subsequent access patterns or data transfers from the affected Event Hub to detect potential data exfiltration or misuse following the rule change.
+
+### False positive analysis
+
+- Routine administrative updates to authorization rules by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or deployment tools that update authorization rules as part of regular operations may cause false positives. Identify these scripts and exclude their activity from alerts by filtering based on their service principal or user identity.
+- Changes made by trusted third-party services integrated with Azure Event Hub might be flagged. Verify these services and exclude their operations by adding them to an allowlist.
+- Frequent updates during development or testing phases can lead to false positives. Consider setting up separate monitoring profiles for development environments to reduce noise.
+- Legitimate changes made by users with appropriate permissions might be misinterpreted as threats. Regularly review and update the list of authorized users to ensure only necessary personnel have access, and exclude their actions from alerts.
+
+### Response and remediation
+
+- Immediately revoke or rotate the cryptographic keys associated with the affected Event Hub Authorization Rule to prevent unauthorized access.
+- Review the Azure Activity Logs to identify any unauthorized access or data exfiltration attempts that may have occurred using the compromised authorization rule.
+- Implement conditional access policies to restrict access to Event Hub Authorization Rules based on user roles and network locations.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Conduct a security review of all Event Hub Authorization Rules to ensure that only necessary permissions are granted and that the RootManageSharedAccessKey is not used in applications.
+- Enhance monitoring and alerting for changes to authorization rules by integrating with a Security Information and Event Management (SIEM) system to detect similar threats in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-shared-access-signature"]
diff --git a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
index 8bb0b88fad1..4a01d6cdd80 100644
--- a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
+++ b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/12/11"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "Azure Entra MFA TOTP Brute Force Attempts"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Azure Entra MFA TOTP Brute Force Attempts
 
diff --git a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
index 92c23e47a2b..285b3ba6b92 100644
--- a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
+++ b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Full Network Packet Capture Detected"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Full Network Packet Capture Detected
+
+Azure's Packet Capture is a feature of Network Watcher that allows for the inspection of network traffic, useful for diagnosing network issues. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to access credentials or other sensitive information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure activity logs for successful operations, helping to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific user or service principal associated with the packet capture operation by examining the `azure.activitylogs.operation_name` and `event.dataset` fields.
+- Check the timestamp of the detected packet capture activity to determine the exact time frame of the event and correlate it with any other suspicious activities or changes in the environment.
+- Investigate the source and destination IP addresses involved in the packet capture to understand the scope and potential impact, focusing on any unencrypted traffic that might have been captured.
+- Verify the legitimacy of the packet capture request by contacting the user or team responsible for the operation to confirm if it was authorized and necessary for troubleshooting or other legitimate purposes.
+- Assess the risk of exposed sensitive data by identifying any critical systems or services that were part of the captured network traffic, especially those handling credentials or personal information.
+
+### False positive analysis
+
+- Routine network diagnostics by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular diagnostics.
+- Automated network monitoring tools might initiate packet captures as part of their normal operations. Identify these tools and exclude their activities from triggering alerts.
+- Scheduled maintenance activities often involve packet captures for performance analysis. Document these schedules and configure the rule to ignore captures during these periods.
+- Development and testing environments may frequently use packet capture for debugging purposes. Exclude these environments by filtering based on resource tags or environment identifiers.
+- Legitimate security audits may involve packet capture to assess network security. Coordinate with the audit team to whitelist their activities during the audit period.
+
+### Response and remediation
+
+- Immediately isolate the affected network segment to prevent further unauthorized packet capture and potential data exfiltration.
+- Revoke any suspicious or unauthorized access to Azure Network Watcher and related resources to prevent further misuse.
+- Conduct a thorough review of the captured network traffic logs to identify any sensitive data exposure and assess the potential impact.
+- Reset credentials and access tokens for any accounts or services that may have been compromised due to exposed unencrypted traffic.
+- Implement network encryption protocols to protect sensitive data in transit and reduce the risk of future packet capture exploitation.
+- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary.
+- Enhance monitoring and alerting for Azure Network Watcher activities to detect and respond to similar threats more effectively in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"]
diff --git a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
index 65b062f0ebf..543222f945f 100644
--- a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
+++ b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/06/26"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,41 @@ query = '''
         azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e
         and azure.activitylogs.properties.authentication_protocol:deviceCode)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Entra ID Device Code Auth with Broker Client
+
+Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the sign-in logs to confirm the use of device code authentication by checking the field azure.signinlogs.properties.authentication_protocol for the value deviceCode.
+- Verify the application ID involved in the sign-in attempt by examining azure.signinlogs.properties.conditional_access_audiences.application_id and ensure it matches 29d9ed98-a469-4536-ade2-f981bc1d605e.
+- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious.
+- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise.
+- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.
+- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.
+
+### False positive analysis
+
+- Legitimate device code authentication by trusted applications or users may trigger the rule. Review the application ID and user context to confirm legitimacy.
+- Frequent access by automated scripts or services using device code authentication can be mistaken for unauthorized access. Identify and document these services, then create exceptions for known application IDs.
+- Shared devices in environments with multiple users may cause false positives if device code authentication is used regularly. Implement user-specific logging to differentiate between legitimate and suspicious activities.
+- Regular maintenance or updates by IT teams using device code authentication might be flagged. Coordinate with IT to schedule these activities and temporarily adjust monitoring rules if necessary.
+- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or application usage patterns.
+
+### Response and remediation
+
+- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions.
+- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.
+- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse.
+- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.
+- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats.
+- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
index 32a179c5ecd..eac8b2ce8d6 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,43 @@ language = "esql"
 interval = "10m"
 license = "Elastic License v2"
 name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts"
-note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
+
+Azure Entra ID, integral to Microsoft 365, manages user identities and access. Adversaries exploit this by attempting numerous login attempts to breach accounts, targeting services like Exchange and Teams. The detection rule identifies such threats by analyzing failed login patterns within a 30-minute window, flagging unusual activity from multiple sources or excessive failed attempts, thus highlighting potential brute-force attacks.
+
+### Possible investigation steps
+
+- Review the `azure.signinlogs.properties.user_principal_name` to identify the specific user account targeted by the brute-force attempts.
+- Examine the `source.ip` field to determine the origin of the failed login attempts and assess if multiple IP addresses are involved, indicating a distributed attack.
+- Check the `azure.signinlogs.properties.resource_display_name` to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted during the login attempts.
+- Analyze the `target_time_window` to confirm the timeframe of the attack and correlate it with other security events or alerts that may have occurred simultaneously.
+- Investigate the `azure.signinlogs.properties.status.error_code` for specific error codes that might provide additional context on the nature of the failed login attempts.
+- Assess the user's recent activity and any changes in behavior or access patterns that could indicate a compromised account or insider threat.
+
+### False positive analysis
+
+- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery processes. To mitigate this, consider excluding known IP addresses associated with IT support or helpdesk operations.
+- Automated scripts or applications that frequently access Microsoft 365 services using non-interactive logins may be misidentified as brute force attempts. Identify and whitelist these applications by their user principal names or IP addresses.
+- Users traveling or working remotely may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exclusions for known travel patterns or use conditional access policies to manage these scenarios.
+- Bulk operations performed by administrators, such as batch account updates or migrations, can result in numerous failed logins. Exclude these activities by recognizing the specific user principal names or IP addresses involved in such operations.
+- Frequent logins from shared IP addresses, such as those from corporate VPNs or proxy servers, might be flagged. Consider excluding these IP ranges if they are known and trusted within the organization.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access.
+- Conduct a password reset for the compromised accounts, ensuring the new passwords are strong and unique.
+- Review and block the IP addresses associated with the failed login attempts to prevent further access attempts from these sources.
+- Enable multi-factor authentication (MFA) for the affected accounts and any other accounts that do not have it enabled to add an additional layer of security.
+- Monitor the affected accounts and related services for any unusual activity or signs of compromise post-remediation.
+- Escalate the incident to the security operations team for further investigation and to determine if there are broader implications or related threats.
+- Update and enhance detection rules and monitoring to identify similar brute-force attempts in the future, ensuring quick response to any new threats.
+
+This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
 references = [
     "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
     "https://github.com/0xZDH/o365spray"
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
index 0517b3b14f8..c32823290dd 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,43 @@ language = "esql"
 interval = "10m"
 license = "Elastic License v2"
 name = "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source"
-note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source
+
+Azure Entra ID, integral to Microsoft 365, manages identity and access, ensuring secure authentication. Adversaries exploit this by attempting numerous failed logins to breach accounts. The detection rule identifies such brute-force attempts by monitoring failed logins from a single IP within a short timeframe, flagging potential unauthorized access efforts.
+
+### Possible investigation steps
+
+- Review the source IP address identified in the alert to determine if it is associated with known malicious activity or if it belongs to a legitimate user or organization.
+- Examine the list of user principal names targeted by the failed login attempts to identify any patterns or specific users that may be at higher risk.
+- Check the azure.signinlogs.properties.resource_display_name to understand which Microsoft 365 services were targeted, such as Exchange, SharePoint, or Teams, and assess the potential impact on those services.
+- Investigate the error codes in azure.signinlogs.properties.status.error_code for additional context on why the login attempts failed, which may provide insights into the attacker's methods.
+- Correlate the failed login attempts with any successful logins from the same source IP or user accounts to identify potential unauthorized access.
+- Assess the risk and exposure of the affected user accounts and consider implementing additional security measures, such as multi-factor authentication, if not already in place.
+
+### False positive analysis
+
+- High volume of legitimate login attempts from a single IP, such as a corporate proxy or VPN, can trigger false positives. To mitigate, exclude known IP addresses of trusted network infrastructure from the rule.
+- Automated scripts or applications performing frequent login operations on behalf of users may be misidentified as brute force attempts. Identify and whitelist these applications by their source IPs or user agents.
+- Shared workstations or kiosks where multiple users log in from the same IP address can result in false positives. Implement user-based exclusions for these environments to prevent unnecessary alerts.
+- Frequent password resets or account recovery processes can generate multiple failed login attempts. Monitor and exclude these activities by correlating with password reset logs or helpdesk tickets.
+- Training or testing environments where multiple failed logins are expected should be excluded by identifying and filtering out the associated IP ranges or user accounts.
+
+### Response and remediation
+
+- Immediately block the source IP address identified in the alert to prevent further unauthorized access attempts.
+- Reset passwords for all affected user accounts that experienced failed login attempts from the flagged IP address to ensure account security.
+- Enable multi-factor authentication (MFA) for the affected accounts if not already in place, to add an additional layer of security against unauthorized access.
+- Review and update conditional access policies to restrict access from suspicious or untrusted locations, enhancing security posture.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Monitor the affected accounts and source IP for any additional suspicious activity, ensuring no further attempts are made.
+- Document the incident details, including the source IP, affected accounts, and actions taken, for future reference and compliance purposes.
+
+This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources."""
 references = [
     "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying",
     "https://github.com/0xZDH/o365spray"
diff --git a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
index 76341ee2959..ad00781c91a 100644
--- a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
+++ b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/10/14"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Matteo Potito Giorgio"]
@@ -38,6 +38,40 @@ query = '''
  event.dataset:(azure.activitylogs or azure.signinlogs) and 
      (azure.signinlogs.properties.authentication_protocol:deviceCode or azure.activitylogs.properties.authentication_protocol:deviceCode) and event.outcome:success
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of Entra ID Auth via DeviceCode Protocol
+
+The DeviceCode protocol facilitates authentication for devices lacking keyboards, streamlining user access without manual credential entry. However, attackers can exploit this by phishing users to capture access tokens, enabling unauthorized access. The detection rule identifies new instances of this protocol use, flagging potential misuse by monitoring successful authentications within a 14-day window, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the event logs to confirm the presence of the deviceCode protocol in the authentication process by checking the fields azure.signinlogs.properties.authentication_protocol or azure.activitylogs.properties.authentication_protocol.
+- Verify the event outcome by examining the event.outcome field to ensure the authentication was successful.
+- Identify the user associated with the authentication attempt and review their recent activity for any anomalies or signs of compromise.
+- Check the device information to determine if the authentication was performed on a device that typically lacks a keyboard, which would justify the use of the deviceCode protocol.
+- Investigate any recent phishing attempts or suspicious communications that could have targeted the user to capture their access tokens.
+- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+
+### False positive analysis
+
+- Legitimate device setup activities may trigger alerts when new devices without keyboards are being configured. To manage this, maintain a list of known devices and exclude their initial setup from triggering alerts.
+- Regular use of shared devices in environments like conference rooms or kiosks can result in repeated alerts. Implement a policy to track and whitelist these shared devices to prevent unnecessary alerts.
+- Automated scripts or applications using the deviceCode protocol for legitimate purposes might be flagged. Identify and document these scripts, then create exceptions for their activity to avoid false positives.
+- Users who frequently travel and use different devices may trigger alerts. Monitor and verify these users' travel patterns and device usage, and consider excluding their known travel-related activities from the rule.
+
+### Response and remediation
+
+- Immediately revoke the access tokens associated with the suspicious deviceCode authentication to prevent further unauthorized access.
+- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred.
+- Reset the credentials of the affected user and enforce multi-factor authentication (MFA) to enhance account security.
+- Isolate any devices that were authenticated using the deviceCode protocol to prevent potential lateral movement within the network.
+- Notify the security operations team and escalate the incident to ensure a coordinated response and further investigation into potential phishing attempts.
+- Implement additional monitoring for anomalous deviceCode protocol usage across the organization to detect similar threats in the future.
+- Review and update access policies to restrict the use of the deviceCode protocol to only those devices and scenarios where it is absolutely necessary."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/azure/credential_access_key_vault_modified.toml b/rules/integrations/azure/credential_access_key_vault_modified.toml
index b58c6dfac3f..fdef9ad5f15 100644
--- a/rules/integrations/azure/credential_access_key_vault_modified.toml
+++ b/rules/integrations/azure/credential_access_key_vault_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Key Vault Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Key Vault Modified
+
+Azure Key Vault is a critical service for managing sensitive information like encryption keys and secrets. It ensures that only authorized users and applications can access these resources. However, adversaries may attempt to modify Key Vault settings to gain unauthorized access to credentials. The detection rule monitors for successful write operations to Key Vaults, flagging potential unauthorized modifications that could indicate credential access attempts.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific user or application that performed the write operation on the Key Vault by examining the user identity and application ID fields.
+- Check the timestamp of the write operation to determine if it aligns with expected maintenance windows or known changes, which could indicate legitimate activity.
+- Investigate the specific changes made to the Key Vault by reviewing the operation details to understand what was modified, such as access policies or secret values.
+- Correlate the activity with other security logs or alerts to identify any related suspicious behavior, such as failed login attempts or unusual access patterns from the same user or application.
+- Verify if the user or application that performed the write operation had legitimate access and permissions to modify the Key Vault by reviewing their role assignments and access policies.
+- Assess the potential impact of the modification by determining if any sensitive keys or secrets were exposed or altered, and evaluate the risk to the organization.
+
+### False positive analysis
+
+- Routine administrative updates to Key Vault configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrative accounts and exclude their activities from triggering alerts.
+- Automated scripts or applications that regularly update Key Vault settings as part of normal operations may cause false positives. Identify these scripts and whitelist their operations to prevent unnecessary alerts.
+- Scheduled maintenance activities that involve updating Key Vault settings can be mistaken for unauthorized modifications. Document these activities and create exceptions for the time frames during which they occur.
+- Integration with third-party services that require periodic updates to Key Vault settings might generate alerts. Verify these integrations and exclude their operations if they are deemed secure and necessary.
+
+### Response and remediation
+
+- Immediately revoke access to the affected Key Vault for any unauthorized users or applications identified during the investigation to prevent further unauthorized access.
+- Rotate all secrets, keys, and certificates stored in the compromised Key Vault to ensure that any potentially exposed credentials are no longer valid.
+- Conduct a thorough review of the Key Vault's access policies and permissions to ensure that only authorized users and applications have the necessary access, and implement stricter access controls if needed.
+- Enable logging and monitoring for the Key Vault to capture detailed access and modification events, ensuring that any future unauthorized attempts are quickly detected.
+- Notify the security team and relevant stakeholders about the incident, providing them with details of the unauthorized modifications and actions taken to remediate the issue.
+- If the unauthorized access is suspected to be part of a larger breach, escalate the incident to the incident response team for further investigation and potential involvement of law enforcement if necessary.
+- Review and update incident response plans and playbooks to incorporate lessons learned from this incident, ensuring a more effective response to similar threats in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
index 5f1e83dabbf..a18025787ae 100644
--- a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
+++ b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Storage Account Key Regenerated"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Storage Account Key Regenerated
+
+Azure Storage Account keys are critical credentials that grant access to storage resources. They are often used by applications and services to authenticate and interact with Azure Storage. Adversaries may regenerate these keys to gain unauthorized access, potentially disrupting services or exfiltrating data. The detection rule monitors for key regeneration events, flagging successful operations as potential indicators of credential misuse, thus enabling timely investigation and response.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific storage account associated with the key regeneration event by examining the operation_name field for "MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION".
+- Check the event.outcome field to confirm the success of the key regeneration and gather details about the user or service principal that initiated the action.
+- Investigate the user or service principal's recent activities in Azure to determine if there are any other suspicious actions or patterns that could indicate unauthorized access or misuse.
+- Assess the impact on applications and services that rely on the affected storage account key by identifying dependencies and checking for any service disruptions or anomalies.
+- Review access policies and permissions for the storage account to ensure they are appropriately configured and consider implementing additional security measures, such as Azure Key Vault, to manage and rotate keys securely.
+
+### False positive analysis
+
+- Routine key rotation by administrators or automated scripts can trigger alerts. To manage this, identify and document regular key rotation schedules and exclude these events from alerts.
+- Development and testing environments often regenerate keys frequently. Exclude these environments from alerts by filtering based on environment tags or resource names.
+- Third-party integrations or services that require periodic key regeneration might cause false positives. Work with service owners to understand these patterns and create exceptions for known, legitimate services.
+- Azure policies or compliance checks that enforce key rotation can also lead to false positives. Coordinate with compliance teams to align detection rules with policy schedules and exclude these events.
+- Ensure that any automated processes that regenerate keys are logged and documented. Use this documentation to create exceptions for these processes in the detection rule.
+
+### Response and remediation
+
+- Immediately revoke the regenerated storage account keys to prevent unauthorized access. This can be done through the Azure portal or using Azure CLI commands.
+- Identify and update all applications and services that rely on the compromised storage account keys with new, secure keys to restore functionality and prevent service disruption.
+- Conduct a thorough review of access logs and audit trails to identify any unauthorized access or data exfiltration attempts that may have occurred using the regenerated keys.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised.
+- Implement conditional access policies and multi-factor authentication (MFA) for accessing Azure resources to enhance security and prevent similar incidents.
+- Review and update the storage account's access policies and permissions to ensure that only authorized users and applications have the necessary access.
+- Enhance monitoring and alerting mechanisms to detect future unauthorized key regeneration attempts promptly, ensuring timely response to potential threats.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
index e6d6c3ef2b1..e9f7a68124e 100644
--- a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
+++ b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Application Credential Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Application Credential Modification
+
+Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. The detection rule monitors audit logs for successful updates to application credentials, flagging potential misuse by identifying unauthorized credential modifications.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to identify the specific application that had its credentials updated, focusing on entries with the operation name "Update application - Certificates and secrets management" and a successful outcome.
+- Determine the identity of the user or service principal that performed the credential modification by examining the associated user or principal ID in the audit log entry.
+- Investigate the context of the credential modification by checking for any recent changes or unusual activities related to the application, such as modifications to permissions or roles.
+- Assess the legitimacy of the new credential by verifying if it aligns with expected operational procedures or if it was authorized by a known and trusted entity.
+- Check for any additional suspicious activities in the audit logs around the same timeframe, such as failed login attempts or other modifications to the application, to identify potential indicators of compromise.
+- Contact the application owner or relevant stakeholders to confirm whether the credential addition was expected and authorized, and gather any additional context or concerns they might have.
+
+### False positive analysis
+
+- Routine credential updates by authorized personnel can trigger alerts. Regularly review and document credential management activities to distinguish between legitimate and suspicious actions.
+- Automated processes or scripts that update application credentials as part of maintenance or deployment cycles may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Credential updates during application scaling or migration might be flagged. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring thresholds or exclusions.
+- Third-party integrations that require periodic credential updates can be mistaken for unauthorized changes. Maintain an inventory of such integrations and establish baseline behaviors to filter out benign activities.
+- Frequent updates by specific service accounts could be part of normal operations. Monitor these accounts separately and consider creating exceptions for known, non-threatening patterns.
+
+### Response and remediation
+
+- Immediately revoke the unauthorized credentials by accessing the Azure portal and removing any suspicious certificates or secret strings associated with the affected application.
+- Conduct a thorough review of the application's access logs to identify any unauthorized access or actions performed using the compromised credentials.
+- Reset and update all legitimate credentials for the affected application to ensure no further unauthorized access can occur.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential modification and any potential impact.
+- Implement additional monitoring on the affected application to detect any further unauthorized changes or access attempts.
+- Review and tighten access controls and permissions for managing application credentials to prevent unauthorized modifications in the future.
+- If necessary, escalate the incident to higher-level security management or external cybersecurity experts for further investigation and response.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
index 50ea493d443..3e08bd09d05 100644
--- a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Runbook Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Automation Runbook Deleted
+
+Azure Automation Runbooks automate repetitive tasks in cloud environments, enhancing operational efficiency. Adversaries may exploit this by deleting runbooks to disrupt operations or conceal malicious activities. The detection rule monitors Azure activity logs for successful runbook deletions, signaling potential defense evasion tactics, and alerts analysts to investigate further.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE" and ensure the event outcome is marked as Success.
+- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs.
+- Investigate the timeline of events leading up to and following the runbook deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or changes to other resources.
+- Check for any recent modifications or unusual activities in the affected Azure Automation account to determine if there are other signs of compromise or tampering.
+- Assess the impact of the deleted runbook on business operations and determine if any critical automation processes were disrupted.
+- If applicable, review any available backup or version history of the deleted runbook to restore it and mitigate operational disruptions.
+
+### False positive analysis
+
+- Routine maintenance activities by IT staff may lead to legitimate runbook deletions. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
+- Automated scripts or third-party tools that manage runbooks might trigger deletions as part of their normal operation. Identify these tools and exclude their activity from alerts by filtering based on their service accounts or IP addresses.
+- Organizational policy changes or cloud environment restructuring can result in planned runbook deletions. Document these changes and adjust the detection rule to exclude these events by correlating with change management records.
+- Test environments often involve frequent creation and deletion of runbooks. Exclude these environments from alerts by using tags or specific resource group identifiers associated with non-production environments.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Automation account to prevent further unauthorized deletions or modifications of runbooks.
+- Review the Azure activity logs to identify the user or service principal responsible for the deletion and revoke their access if unauthorized.
+- Restore the deleted runbook from backups or version control if available, ensuring that the restored version is free from any malicious modifications.
+- Conduct a security review of all remaining runbooks to ensure they have not been tampered with or contain malicious code.
+- Implement stricter access controls and auditing for Azure Automation accounts, ensuring that only authorized personnel have the ability to delete runbooks.
+- Escalate the incident to the security operations team for further investigation and to determine if additional malicious activities have occurred.
+- Enhance monitoring and alerting for similar activities by integrating additional context or indicators from the MITRE ATT&CK framework related to defense evasion tactics.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
index 7802a541aa0..409247055d7 100644
--- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
+++ b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Blob Permissions Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Blob Permissions Modification
+
+Azure Blob Storage is a service for storing large amounts of unstructured data. It uses Azure RBAC to manage access, ensuring only authorized users can modify or access data. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt operations. The detection rule monitors specific Azure activity logs for successful permission changes, alerting analysts to potential security breaches or misconfigurations.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal associated with the permission modification event by examining the relevant fields such as `event.dataset` and `azure.activitylogs.operation_name`.
+- Check the `event.outcome` field to confirm the success of the permission modification and gather details on the specific permissions that were altered.
+- Investigate the context of the modification by reviewing recent activities of the identified user or service principal to determine if the change aligns with their typical behavior or role.
+- Assess the potential impact of the permission change on the affected Azure Blob by evaluating the sensitivity of the data and the new access levels granted.
+- Cross-reference the modification event with any recent security alerts or incidents to identify if this change is part of a broader attack pattern or misconfiguration issue.
+- Consult with the relevant data owners or administrators to verify if the permission change was authorized and necessary, and if not, take corrective actions to revert the changes.
+
+### False positive analysis
+
+- Routine administrative changes to Azure Blob permissions by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that frequently perform legitimate permission modifications.
+- Automated scripts or tools used for regular maintenance or deployment might modify permissions as part of their operation. Identify these scripts and exclude their activity from triggering alerts by using specific identifiers or tags associated with the scripts.
+- Scheduled updates or policy changes that involve permission modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these timeframes, reducing unnecessary alerts.
+- Integration with third-party services that require permission changes might cause alerts. Review and whitelist these services if they are verified and necessary for operations, ensuring they do not trigger false positives.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized permissions identified in the Azure Blob Storage to prevent further unauthorized access or data exposure.
+- Conduct a thorough review of the Azure Activity Logs to identify any other suspicious activities or permission changes that may have occurred around the same time.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and any potential data exposure.
+- Implement additional monitoring on the affected Azure Blob Storage accounts to detect any further unauthorized access attempts or permission modifications.
+- Escalate the incident to the incident response team if there is evidence of a broader security breach or if sensitive data has been compromised.
+- Review and update Azure RBAC policies to ensure that only necessary permissions are granted, and consider implementing more granular access controls to minimize the risk of future unauthorized modifications.
+- Conduct a post-incident analysis to identify the root cause of the permission change and implement measures to prevent similar incidents in the future, such as enhancing logging and alerting capabilities.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles"]
diff --git a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
index 3d1aed02314..0b463b5a617 100644
--- a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Diagnostic Settings Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Diagnostic Settings Deletion
+
+Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" and ensuring the event outcome is marked as Success.
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.
+- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.
+- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.
+- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel may trigger the rule. Ensure that maintenance schedules are documented and align with the detected events.
+- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.
+- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.
+- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.
+- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations.
+
+### Response and remediation
+
+- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.
+- Review the Azure activity logs to identify the source of the deletion request, including the user account and IP address involved. This will help determine if the action was authorized or malicious.
+- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.
+- Conduct a thorough investigation of the user account involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
+- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.
+- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.
+- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings"]
diff --git a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
index b94eb74a53b..406d260880d 100644
--- a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Event Hub Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Event Hub Deletion
+
+Azure Event Hub is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may target Event Hubs to delete them, aiming to disrupt data flow and evade detection by erasing evidence of their activities. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential defense evasion attempts by identifying unauthorized or suspicious deletions.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and ensure the event outcome is marked as Success.
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- Investigate the context of the deletion by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious actions.
+- Check for any recent changes in permissions or roles assigned to the user or service principal to assess if the deletion was authorized or if there was a potential privilege escalation.
+- Correlate the deletion event with other security alerts or incidents in the environment to identify if this action is part of a larger attack pattern or campaign.
+- Communicate with relevant stakeholders or teams to verify if the deletion was part of a planned operation or maintenance activity.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger deletion logs. Verify if the deletion aligns with scheduled maintenance activities and exclude these operations from alerts.
+- Automated scripts or tools used for managing Azure resources might delete Event Hubs as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives.
+- Test environments often involve frequent creation and deletion of resources, including Event Hubs. Exclude known test environments from monitoring to reduce noise.
+- Changes in organizational policies or restructuring might lead to legitimate deletions. Ensure that such policy-driven deletions are documented and excluded from alerts.
+- Misconfigured automation or deployment processes can inadvertently delete Event Hubs. Regularly review and update configurations to ensure they align with intended operations and exclude these from alerts if verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Event Hub namespace to prevent further unauthorized deletions or modifications. This can be done by restricting access through Azure Role-Based Access Control (RBAC) and network security groups.
+- Review and revoke any suspicious or unauthorized access permissions associated with the deleted Event Hub. Ensure that only authorized personnel have the necessary permissions to manage Event Hubs.
+- Restore the deleted Event Hub from backups if available, or reconfigure it to resume normal operations. Verify the integrity and completeness of the restored data.
+- Conduct a thorough audit of recent Azure activity logs to identify any other unauthorized actions or anomalies that may indicate further compromise.
+- Escalate the incident to the security operations team for a detailed investigation into the root cause and to assess the potential impact on other Azure resources.
+- Implement additional monitoring and alerting for Azure Event Hub operations to detect and respond to similar unauthorized activities promptly.
+- Review and update security policies and access controls for Azure resources to prevent recurrence, ensuring adherence to the principle of least privilege.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
index f0c701c2cb6..450856efaa3 100644
--- a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Firewall Policy Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Firewall Policy Deletion
+
+Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and ensuring the event outcome is "Success".
+- Identify the user or service principal responsible for the deletion by examining the 'caller' field in the activity logs.
+- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events or alerts around the same time.
+- Investigate the context of the deletion by reviewing any related activities performed by the same user or service principal, such as modifications to other security settings or unusual login patterns.
+- Assess the impact of the deletion by identifying which resources or networks were protected by the deleted firewall policy and evaluating the potential exposure or risk introduced by its removal.
+- Contact the responsible user or team to verify if the deletion was authorized and part of a planned change or if it was unexpected and potentially malicious.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger the deletion event. Ensure that such activities are logged and verified by cross-referencing with change management records.
+- Automated scripts or tools used for infrastructure management might delete and recreate firewall policies as part of their operation. Identify these scripts and exclude their activity from alerts by using specific identifiers or tags.
+- Test environments often undergo frequent changes, including policy deletions. Consider excluding activity from known test environments by filtering based on resource group or subscription IDs.
+- Scheduled policy updates or rotations might involve temporary deletions. Document these schedules and adjust monitoring rules to account for these expected changes.
+- Ensure that any third-party integrations or services with permissions to modify firewall policies are accounted for, and their actions are reviewed and whitelisted if necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure resources to prevent further unauthorized access or data exfiltration. This can be done by applying restrictive network security group (NSG) rules or using Azure Security Center to quarantine resources.
+- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts or credentials.
+- Restore the deleted firewall policy from backups or recreate it using predefined templates to ensure that network security rules are reinstated promptly.
+- Implement conditional access policies to enforce multi-factor authentication (MFA) for all users with permissions to modify or delete firewall policies, reducing the risk of unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional resources or systems have been compromised.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future.
+- Enhance monitoring by configuring alerts for any future attempts to delete or modify critical security policies, ensuring rapid detection and response to potential threats.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/firewall-manager/policy-overview"]
diff --git a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
index acea8b019f8..7b208a2f0e0 100644
--- a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Frontdoor Web Application Firewall (WAF) Policy Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Frontdoor Web Application Firewall (WAF) Policy Deleted
+
+Azure Frontdoor WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and ensure the event outcome is marked as Success.
+- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs.
+- Check the timestamp of the deletion event to determine if it coincides with any other suspicious activities or alerts in the environment.
+- Investigate the context of the deletion by reviewing any recent changes or incidents involving the affected Azure Frontdoor instance or related resources.
+- Assess the impact of the deletion by identifying which web applications were protected by the deleted WAF policy and evaluating their current exposure to threats.
+- Review access logs and network traffic for the affected web applications to detect any unusual or unauthorized access attempts following the policy deletion.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may lead to the deletion of WAF policies. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for infrastructure management might delete and recreate WAF policies as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts.
+- Changes in organizational policy or architecture could necessitate the removal of certain WAF policies. Document these changes and adjust the detection rule to account for them by excluding specific policy names or identifiers.
+- Test environments may frequently add and remove WAF policies as part of development cycles. Consider excluding activity from test environments by filtering based on resource group names or tags associated with non-production environments.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Frontdoor instance to prevent further unauthorized access or data exfiltration.
+- Review Azure activity logs to identify the user or service principal responsible for the deletion and assess their access permissions.
+- Recreate the deleted WAF policy using the latest backup or configuration template to restore security controls.
+- Implement conditional access policies to restrict access to Azure management operations, ensuring only authorized personnel can modify WAF policies.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and monitoring.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Enhance monitoring by setting up alerts for any future deletions of critical security policies to ensure rapid detection and response.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
index 12782cf9cb0..a355e7da7a1 100644
--- a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Events Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Kubernetes Events Deleted
+
+Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and ensure the event outcome is marked as "Success".
+- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs.
+- Investigate the timeline of events leading up to and following the deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or configuration changes.
+- Check for any other related alerts or anomalies in the Azure environment that might indicate a broader attack or compromise.
+- Assess the impact of the deleted events by determining which Kubernetes resources or operations were affected and if any critical logs were lost.
+- Review access controls and permissions for the user or service principal involved to ensure they align with the principle of least privilege and adjust if necessary.
+- Consider implementing additional monitoring or alerting for similar deletion activities to enhance detection and response capabilities.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for log rotation or cleanup might delete events as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses.
+- Misconfigured applications or services that inadvertently delete logs can cause false positives. Review application configurations and adjust them to prevent unnecessary deletions, and exclude these applications from alerts if they are verified as non-threatening.
+- Test environments often generate log deletions during setup or teardown processes. Exclude these environments from monitoring or create specific rules that differentiate between production and test environments to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Kubernetes cluster to prevent further unauthorized access or tampering with logs.
+- Conduct a thorough review of recent activity logs and access permissions for the affected cluster to identify any unauthorized access or privilege escalation.
+- Restore deleted Kubernetes events from backups or snapshots if available, to ensure continuity in monitoring and auditing.
+- Implement stricter access controls and audit logging for Kubernetes event deletion operations to prevent unauthorized deletions in the future.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of broader compromise or if the deletion is part of a larger attack campaign.
+- Review and update incident response plans to incorporate lessons learned from this event, ensuring quicker detection and response to similar threats in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
index 4bf9be6b02e..db35de4128f 100644
--- a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,41 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Network Watcher Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Network Watcher Deletion
+
+Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments. It provides insights and logging capabilities crucial for maintaining network security. Adversaries may delete Network Watchers to disable these monitoring functions, thereby evading detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, flagging successful attempts as potential security threats.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and ensuring the event outcome is marked as "Success" or "success".
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- Investigate the timeline of events leading up to the deletion by reviewing related activity logs for any unusual or unauthorized access patterns or changes in permissions.
+- Assess the impact of the deletion by determining which resources were being monitored by the deleted Network Watcher and evaluating the potential security implications.
+- Check for any other suspicious activities or alerts in the Azure environment that may indicate a broader attack or compromise, focusing on defense evasion tactics.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel may trigger the deletion alert. Verify if the deletion aligns with scheduled maintenance and consider excluding these operations from alerts.
+- Automated scripts or tools used for infrastructure management might delete Network Watchers as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives.
+- Changes in network architecture or resource reallocation can lead to legitimate deletions. Review change management logs to confirm if the deletion was planned and adjust the detection rule to exclude these scenarios.
+- Test environments often undergo frequent changes, including the deletion of Network Watchers. If these environments are known to generate false positives, consider creating exceptions for specific resource groups or subscriptions associated with testing.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure resources to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules.
+- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts.
+- Restore the deleted Network Watcher by redeploying it in the affected regions to resume monitoring and logging capabilities.
+- Conduct a security review of the affected Azure environment to identify any other potential misconfigurations or unauthorized changes.
+- Implement stricter access controls and auditing for Azure resources, ensuring that only authorized personnel have the ability to delete critical monitoring tools like Network Watchers.
+- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary.
+- Enhance detection capabilities by ensuring that alerts for similar deletion activities are configured to notify the security team immediately.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview"]
diff --git a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
index 5adfd45abdd..cc2c5eb4fa9 100644
--- a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
+++ b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Alert Suppression Rule Created or Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Alert Suppression Rule Created or Modified
+
+Azure Alert Suppression Rules are used to manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to hide malicious activities by suppressing legitimate security alerts. The detection rule monitors Azure activity logs for successful operations related to suppression rule changes, helping identify potential misuse that could lead to defense evasion and reduced security visibility.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific suppression rule that was created or modified by filtering logs with the operation name "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and ensuring the event outcome is "success".
+- Determine the identity of the user or service principal that performed the operation by examining the associated user or service account details in the activity logs.
+- Investigate the context and justification for the creation or modification of the suppression rule by checking any related change management records or communications.
+- Assess the impact of the suppression rule on security visibility by identifying which alerts are being suppressed and evaluating whether these alerts are critical for detecting potential threats.
+- Cross-reference the suppression rule changes with recent security incidents or alerts to determine if there is any correlation or if the rule could have been used to hide malicious activity.
+- Verify the legitimacy of the suppression rule by consulting with relevant stakeholders, such as security operations or cloud management teams, to confirm if the change was authorized and aligns with security policies.
+
+### False positive analysis
+
+- Routine maintenance activities by IT staff may trigger alerts when legitimate suppression rules are created or modified. To manage this, establish a baseline of expected changes and create exceptions for known maintenance periods or personnel.
+- Automated processes or scripts that regularly update suppression rules for operational efficiency can generate false positives. Identify these processes and exclude their activity from alerting by using specific identifiers or tags associated with the automation.
+- Changes made by trusted third-party security services that integrate with Azure might be flagged. Verify the legitimacy of these services and whitelist their operations to prevent unnecessary alerts.
+- Frequent updates to suppression rules due to evolving security policies can lead to false positives. Document these policy changes and adjust the alerting criteria to accommodate expected modifications.
+- Temporary suppression rules created during incident response to manage alert noise can be mistaken for malicious activity. Ensure these rules are documented and time-bound, and exclude them from alerting during the response period.
+
+### Response and remediation
+
+- Immediately review the Azure activity logs to confirm the creation or modification of the suppression rule and identify the user or service account responsible for the change.
+- Temporarily disable the suspicious suppression rule to restore visibility into potential security alerts that may have been suppressed.
+- Conduct a thorough investigation of recent alerts that were suppressed by the rule to determine if any malicious activities were overlooked.
+- If malicious activity is confirmed, initiate incident response procedures to contain and remediate the threat, including isolating affected resources and accounts.
+- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture.
+- Implement additional monitoring and alerting for changes to suppression rules to ensure any future modifications are promptly detected and reviewed.
+- Review and update access controls and permissions for creating or modifying suppression rules to ensure only authorized personnel can make such changes.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/discovery_blob_container_access_mod.toml b/rules/integrations/azure/discovery_blob_container_access_mod.toml
index 61d9adf1f1c..aae1449665d 100644
--- a/rules/integrations/azure/discovery_blob_container_access_mod.toml
+++ b/rules/integrations/azure/discovery_blob_container_access_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Blob Container Access Level Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Blob Container Access Level Modification
+
+Azure Blob Storage is a service for storing large amounts of unstructured data, where access levels can be configured to control data visibility. Adversaries may exploit misconfigured access levels to gain unauthorized access to sensitive data. The detection rule monitors changes in container access settings, focusing on successful modifications, to identify potential security risks associated with unauthorized access level changes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific storage account and container where the access level modification occurred, using the operation name "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE".
+- Verify the identity of the user or service principal that performed the modification by examining the associated user information in the activity logs.
+- Check the timestamp of the modification to determine if it aligns with any known maintenance windows or authorized changes.
+- Investigate the previous access level settings of the container to assess the potential impact of the change, especially if it involved enabling anonymous public read access.
+- Correlate the event with any other recent suspicious activities or alerts in the Azure environment to identify potential patterns or coordinated actions.
+- Contact the owner of the storage account or relevant stakeholders to confirm whether the change was authorized and aligns with organizational policies.
+
+### False positive analysis
+
+- Routine administrative changes to container access levels by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that regularly perform these tasks.
+- Automated scripts or tools used for managing storage configurations may cause false positives. Identify and exclude these scripts or tools from monitoring if they are verified as non-threatening.
+- Scheduled updates or maintenance activities that involve access level modifications can be mistaken for unauthorized changes. Document and schedule these activities to align with monitoring rules, allowing for temporary exclusions during these periods.
+- Changes made by trusted third-party services integrated with Azure Blob Storage might be flagged. Verify these services and exclude their operations from triggering alerts if they are deemed secure and necessary for business operations.
+
+### Response and remediation
+
+- Immediately revoke public read access to the affected Azure Blob container to prevent unauthorized data exposure.
+- Review the access logs to identify any unauthorized access or data exfiltration attempts during the period when the access level was modified.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access level change and any potential data exposure.
+- Conduct a thorough audit of all Azure Blob containers to ensure that access levels are configured according to the organization's security policies and that no other containers are misconfigured.
+- Implement additional monitoring and alerting for changes to access levels on Azure Blob containers to ensure rapid detection of any future unauthorized modifications.
+- If sensitive data was exposed, initiate a data breach response plan, including notifying affected parties and regulatory bodies as required by law.
+- Review and update access management policies and procedures to prevent recurrence, ensuring that only authorized personnel can modify container access levels.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent"]
diff --git a/rules/integrations/azure/execution_command_virtual_machine.toml b/rules/integrations/azure/execution_command_virtual_machine.toml
index 6913c697a2e..b8126b62705 100644
--- a/rules/integrations/azure/execution_command_virtual_machine.toml
+++ b/rules/integrations/azure/execution_command_virtual_machine.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Command Execution on Virtual Machine"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Command Execution on Virtual Machine
+
+Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they typically can't access them directly. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute unauthorized commands. The detection rule monitors Azure activity logs for command execution events, flagging successful operations to identify potential misuse.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION".
+- Check the event.outcome field to confirm the success of the command execution and gather details about the command executed.
+- Investigate the role and permissions of the user or service principal involved to determine if they have legitimate reasons to execute commands on the VM.
+- Analyze the context of the command execution, including the time and frequency of the events, to identify any unusual patterns or anomalies.
+- Correlate the command execution event with other logs or alerts from the same time period to identify any related suspicious activities or potential lateral movement.
+- If unauthorized access is suspected, review the VM's security settings and access controls to identify and mitigate any vulnerabilities or misconfigurations.
+
+### False positive analysis
+
+- Routine maintenance tasks executed by IT administrators can trigger the rule. To manage this, create exceptions for known maintenance scripts or scheduled tasks that are regularly executed.
+- Automated deployment processes that use PowerShell scripts to configure or update VMs may be flagged. Identify these processes and exclude them from the rule to prevent unnecessary alerts.
+- Security tools or monitoring solutions that perform regular checks on VMs might execute commands that are benign. Whitelist these tools by identifying their specific command patterns and excluding them from detection.
+- Development and testing environments often involve frequent command executions for testing purposes. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds.
+- Ensure that any exclusion or exception is documented and reviewed periodically to maintain security posture and adapt to any changes in the environment or processes.
+
+### Response and remediation
+
+- Immediately isolate the affected virtual machine from the network to prevent further unauthorized command execution and potential lateral movement.
+- Review the Azure activity logs to identify the source of the command execution and determine if it was authorized or part of a larger attack pattern.
+- Revoke any unnecessary permissions from users or roles that have the ability to execute commands on virtual machines, focusing on those with Virtual Machine Contributor roles.
+- Conduct a thorough investigation of the executed commands to assess any changes or impacts on the system, and restore the VM to a known good state if necessary.
+- Implement additional monitoring and alerting for similar command execution activities, ensuring that any future unauthorized attempts are detected promptly.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data may have been compromised.
+- Review and update access control policies and role assignments to ensure that only necessary permissions are granted, reducing the risk of similar incidents in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
index d66662ddb29..2080ff09347 100644
--- a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
+++ b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -25,7 +25,43 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Service Principal Credentials Added"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Service Principal Credentials Added
+
+Azure Service Principals are identities used by applications or services to access Azure resources securely. They are typically granted specific permissions, and credentials are rarely updated. Adversaries may exploit this by adding unauthorized credentials, gaining access to sensitive data without triggering MFA. The detection rule monitors audit logs for successful additions of service principal credentials, flagging potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to identify the specific service principal for which credentials were added, focusing on entries with the operation name "Add service principal credentials" and a successful outcome.
+- Determine the identity of the user or application that performed the credential addition by examining the associated user or application ID in the audit log entry.
+- Investigate the permissions and roles assigned to the affected service principal to assess the potential impact of unauthorized access.
+- Check for any recent changes or unusual activity associated with the service principal, such as modifications to permissions or unexpected resource access patterns.
+- Correlate the event with other security logs and alerts to identify any related suspicious activities or potential indicators of compromise within the environment.
+- Contact the owner or responsible team for the service principal to verify if the credential addition was authorized and legitimate.
+
+### False positive analysis
+
+- Routine credential updates for service principals used in automated deployment processes can trigger alerts. To manage this, identify and document these processes, then create exceptions for known service principals involved in regular updates.
+- Credential additions by authorized IT personnel during scheduled maintenance or upgrades may be flagged. Implement a change management process to log and verify these activities, allowing you to exclude them from triggering alerts.
+- Integration of new third-party applications that require service principal credentials might cause false positives. Maintain an inventory of approved third-party integrations and exclude their credential additions from monitoring.
+- Development and testing environments often see frequent credential changes. Segregate these environments from production in your monitoring setup to reduce unnecessary alerts.
+- Credential rotations as part of security best practices can be mistaken for unauthorized additions. Establish a schedule for credential rotations and configure your monitoring to recognize these as legitimate activities.
+
+### Response and remediation
+
+- Immediately revoke the newly added credentials for the affected Azure Service Principal to prevent unauthorized access.
+- Conduct a thorough review of the audit logs to identify any unauthorized activities performed using the compromised Service Principal credentials.
+- Reset and update the credentials for the affected Service Principal, ensuring they are stored securely and access is restricted to authorized personnel only.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential addition and any potential data access.
+- Implement additional monitoring on the affected Service Principal and related resources to detect any further suspicious activities.
+- Review and tighten the permissions granted to the Service Principal to ensure they follow the principle of least privilege.
+- Consider enabling conditional access policies or additional security measures, such as IP whitelisting, to enhance protection against similar threats in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://www.fireeye.com/content/dam/collateral/en/wp-m-unc2452.pdf"]
diff --git a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
index 791f2c8c25a..2fc1b2879ed 100644
--- a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
+++ b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Pods Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Kubernetes Pods Deleted
+
+Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the details of the pod deletion event, focusing on the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and ensuring the event outcome is marked as "Success".
+- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs.
+- Check the timeline of events leading up to the pod deletion to identify any unusual or unauthorized access patterns or activities.
+- Investigate the specific Kubernetes cluster and namespace where the pod deletion occurred to assess the potential impact on services and applications.
+- Cross-reference the deleted pod's details with recent changes or deployments in the environment to determine if the deletion was part of a legitimate maintenance or deployment activity.
+- Consult with the relevant application or infrastructure teams to verify if the pod deletion was authorized and necessary, or if it indicates a potential security incident.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can lead to legitimate pod deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scaling operations might delete pods as part of normal scaling activities. Identify and exclude these operations by correlating with scaling events or using tags that indicate automated processes.
+- Development and testing environments often experience frequent pod deletions as part of normal operations. Consider excluding these environments from alerts by using environment-specific identifiers or tags.
+- Scheduled job completions may result in pod deletions once tasks are finished. Implement rules to recognize and exclude these scheduled operations by matching them with known job schedules or identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules temporarily.
+- Review the Azure activity logs to identify the source of the deletion request, including the user or service principal involved, and verify if the action was authorized.
+- Recreate the deleted pods using the latest known good configuration to restore services and minimize downtime.
+- Conduct a thorough security assessment of the affected cluster to identify any additional unauthorized changes or indicators of compromise.
+- Implement stricter access controls and role-based access management to ensure only authorized personnel can delete pods in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected.
+- Enhance monitoring and alerting for similar activities by integrating with a Security Information and Event Management (SIEM) system to detect and respond to unauthorized pod deletions promptly.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_resource_group_deletion.toml b/rules/integrations/azure/impact_resource_group_deletion.toml
index 6ccdd075ad5..07c2a1a10df 100644
--- a/rules/integrations/azure/impact_resource_group_deletion.toml
+++ b/rules/integrations/azure/impact_resource_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Resource Group Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Resource Group Deletion
+
+Azure Resource Groups are containers that hold related resources for an Azure solution, enabling efficient management and organization. Adversaries may exploit this by deleting entire groups to disrupt services or erase data, causing significant impact. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential malicious actions for further investigation.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and ensure the event outcome is marked as "Success" or "success".
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- Check the timestamp of the deletion event to determine when the resource group was deleted and correlate this with any other suspicious activities around the same time.
+- Investigate the resources contained within the deleted resource group to assess the potential impact, including any critical services or data that may have been affected.
+- Review any recent changes in permissions or roles assigned to the user or service principal involved in the deletion to identify potential privilege escalation or misuse.
+- Examine any related alerts or logs for unusual activities or patterns that might indicate a broader attack or compromise within the Azure environment.
+
+### False positive analysis
+
+- Routine maintenance activities by IT teams may trigger alerts when resource groups are intentionally deleted as part of regular updates or infrastructure changes. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or deployment tools that manage resource lifecycles might delete resource groups as part of their normal operation. Identify these scripts and exclude their activity from alerts by filtering based on the service principal or automation account used.
+- Testing environments often involve frequent creation and deletion of resource groups. Exclude these environments from alerts by tagging them appropriately and configuring the detection rule to ignore actions on tagged resources.
+- Mergers or organizational restructuring can lead to legitimate resource group deletions. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring rules to prevent false positives.
+- Ensure that any third-party services or consultants with access to your Azure environment are accounted for, as their activities might include resource group deletions. Establish clear communication channels to verify their actions and adjust monitoring rules accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure subscription to prevent further unauthorized actions. This can be done by temporarily disabling access or applying strict access controls.
+- Review and revoke any suspicious or unauthorized access permissions associated with the affected resource group to prevent further exploitation.
+- Restore the deleted resources from backups if available. Ensure that backup and recovery processes are validated and functioning correctly.
+- Conduct a thorough audit of recent Azure activity logs to identify any other potentially malicious actions or compromised accounts.
+- Escalate the incident to the security operations team for a detailed investigation and to determine if there are broader implications or related threats.
+- Implement additional monitoring and alerting for similar deletion activities across all Azure subscriptions to enhance early detection of such threats.
+- Review and strengthen access management policies, ensuring that only authorized personnel have the necessary permissions to delete resource groups.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/impact_virtual_network_device_modified.toml b/rules/integrations/azure/impact_virtual_network_device_modified.toml
index f1e9e003e68..7c1c87f45e2 100644
--- a/rules/integrations/azure/impact_virtual_network_device_modified.toml
+++ b/rules/integrations/azure/impact_virtual_network_device_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Virtual Network Device Modified or Deleted"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Virtual Network Device Modified or Deleted
+
+Azure virtual network devices, such as network interfaces, virtual hubs, and routers, are crucial for managing network traffic and connectivity in cloud environments. Adversaries may target these devices to disrupt services or reroute traffic for malicious purposes. The detection rule monitors specific Azure activity logs for operations indicating modifications or deletions of these devices, helping identify potential unauthorized changes that could signify an attack.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific operation that triggered the alert, focusing on the operation_name field to determine whether it was a WRITE or DELETE action.
+- Check the event.outcome field to confirm the success of the operation, ensuring that the modification or deletion was completed.
+- Investigate the user or service principal responsible for the action by examining the identity information in the activity logs to determine if the change was authorized.
+- Assess the impact of the modification or deletion by identifying the affected virtual network device, such as a network interface, virtual hub, or virtual router, and evaluate its role in the network architecture.
+- Cross-reference the time of the alert with any other suspicious activities or alerts in the environment to identify potential patterns or coordinated actions.
+- Consult with relevant stakeholders or system owners to verify if the change was planned or expected, and gather additional context if necessary.
+
+### False positive analysis
+
+- Routine maintenance activities by network administrators can trigger alerts when they modify or delete virtual network devices. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or tools used for network management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags.
+- Changes made by authorized third-party services or integrations that manage network configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts.
+- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only.
+- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods.
+
+### Response and remediation
+
+- Immediately isolate the affected virtual network device to prevent further unauthorized access or changes. This can be done by disabling the network interface or applying restrictive network security group rules.
+- Review the Azure activity logs to identify the source of the modification or deletion. Correlate this with user activity logs to determine if the action was performed by an authorized user or a compromised account.
+- If a compromised account is suspected, reset the credentials for the affected account and any other accounts that may have been exposed. Implement multi-factor authentication if not already in place.
+- Restore the modified or deleted virtual network device from a known good backup or configuration snapshot to ensure continuity of services.
+- Conduct a thorough security assessment of the affected Azure environment to identify any additional unauthorized changes or indicators of compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.
+- Implement enhanced monitoring and alerting for similar activities in the future, ensuring that any modifications or deletions of virtual network devices are promptly detected and reviewed.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"]
diff --git a/rules/integrations/azure/initial_access_external_guest_user_invite.toml b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
index ec46d414b1e..cc5902ae290 100644
--- a/rules/integrations/azure/initial_access_external_guest_user_invite.toml
+++ b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure External Guest User Invitation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure External Guest User Invitation
+
+Azure Active Directory (AD) facilitates collaboration by allowing external users to be invited as guest users, enhancing flexibility in cloud environments. However, adversaries may exploit this feature to gain unauthorized access, posing security risks. The detection rule monitors audit logs for successful external user invitations, flagging potential misuse by identifying unusual or unnecessary guest account creations.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the details of the invitation event, focusing on the operation name "Invite external user" and ensuring the event outcome is marked as Success.
+- Identify the inviter by examining the properties of the audit log entry, such as the initiator's user ID or email, to determine if the invitation was expected or authorized.
+- Check the display name and other attributes of the invited guest user to assess if they align with known business needs or if they appear suspicious or unnecessary.
+- Investigate the inviter's recent activity in Azure AD to identify any unusual patterns or deviations from their typical behavior that might indicate compromised credentials.
+- Consult with relevant business units or stakeholders to verify if there was a legitimate business requirement for the guest user invitation and if it aligns with current projects or collaborations.
+- Review the access permissions granted to the guest user to ensure they are limited to the minimum necessary for their role and do not expose sensitive resources.
+
+### False positive analysis
+
+- Invitations for legitimate business partners or vendors may trigger alerts. Regularly review and whitelist known partners to prevent unnecessary alerts.
+- Internal users with dual roles or responsibilities that require external access might be flagged. Maintain a list of such users and update it periodically to exclude them from alerts.
+- Automated systems or applications that require guest access for integration purposes can cause false positives. Identify these systems and configure exceptions in the monitoring rules.
+- Temporary projects or collaborations often involve inviting external users. Document these projects and set expiration dates for guest access to minimize false positives.
+- Frequent invitations from specific departments, such as HR or Marketing, for events or collaborations can be common. Establish a process to verify and approve these invitations to reduce false alerts.
+
+### Response and remediation
+
+- Immediately disable the guest user account identified in the alert to prevent any unauthorized access or activities.
+- Review the audit logs to determine the source and context of the invitation, identifying the user or system that initiated the guest invitation.
+- Notify the security team and relevant stakeholders about the unauthorized guest invitation for further investigation and potential escalation.
+- Conduct a security assessment of the affected Azure AD environment to identify any other unauthorized guest accounts or suspicious activities.
+- Implement conditional access policies to restrict guest user invitations to authorized personnel only, reducing the risk of future unauthorized invitations.
+- Enhance monitoring and alerting for guest user invitations by integrating with a Security Information and Event Management (SIEM) system to ensure timely detection and response.
+- Review and update the organization's Azure AD guest user policies to ensure they align with security best practices and business needs, minimizing unnecessary guest access.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/governance/policy/samples/cis-azure-1-1-0"]
diff --git a/rules/integrations/azure/persistence_azure_automation_account_created.toml b/rules/integrations/azure/persistence_azure_automation_account_created.toml
index 114f1210d26..63f187ee4d4 100644
--- a/rules/integrations/azure/persistence_azure_automation_account_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,41 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Account Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Automation Account Created
+
+Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud environments, enhancing operational efficiency. However, adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule monitors the creation of these accounts by analyzing specific Azure activity logs, focusing on successful operations, to identify potential unauthorized or suspicious account creations.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the creation of the Automation account by checking for the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and ensure the event outcome is marked as Success.
+- Identify the user or service principal that initiated the creation of the Automation account by examining the associated user identity information in the activity logs.
+- Investigate the context of the Automation account creation by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious or unauthorized actions.
+- Check the configuration and permissions of the newly created Automation account to ensure it does not have excessive privileges that could be exploited for persistence or lateral movement.
+- Correlate the Automation account creation event with other security alerts or logs to identify any patterns or indicators of compromise that may suggest malicious intent.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when legitimate users create Azure Automation accounts for operational purposes. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list.
+- Automated deployment scripts or infrastructure-as-code tools might create automation accounts as part of their normal operation. Identify these scripts and exclude their associated activities from triggering alerts by using specific identifiers or tags.
+- Scheduled maintenance or updates by cloud service providers could result in the creation of automation accounts. Verify the timing and context of the account creation against known maintenance schedules and exclude these from alerts if they match.
+- Development and testing environments often involve frequent creation and deletion of resources, including automation accounts. Implement separate monitoring rules or environments for these non-production areas to reduce noise in alerts.
+
+### Response and remediation
+
+- Immediately review the Azure activity logs to confirm the creation of the Automation account and identify the user or service principal responsible for the action.
+- Disable the newly created Azure Automation account to prevent any potential malicious automation tasks from executing.
+- Conduct a thorough investigation of the user or service principal that created the account to determine if their credentials have been compromised or if they have acted maliciously.
+- Reset credentials and enforce multi-factor authentication for the identified user or service principal to prevent unauthorized access.
+- Review and adjust Azure role-based access control (RBAC) policies to ensure that only authorized personnel have the ability to create Automation accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised.
+- Implement enhanced monitoring and alerting for future Automation account creations to quickly detect and respond to similar threats.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
index 94aa992de20..9a6a3e5d00b 100644
--- a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
+++ b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Runbook Created or Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Automation Runbook Created or Modified
+
+Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code and maintain persistence. The detection rule monitors specific Azure activity logs for runbook creation or modification events, flagging successful operations to identify potential misuse. This helps in early detection of malicious activities, ensuring cloud security.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific runbook that was created or modified, focusing on the operation names: "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE", "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE", or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION".
+- Check the event.outcome field to confirm the operation was successful, as indicated by the values "Success" or "success".
+- Identify the user or service principal that performed the operation by examining the relevant user identity fields in the activity logs.
+- Investigate the content and purpose of the runbook by reviewing its script or configuration to determine if it contains any unauthorized or suspicious code.
+- Correlate the runbook activity with other security events or alerts in the environment to identify any patterns or related malicious activities.
+- Verify if the runbook changes align with recent legitimate administrative activities or if they were unexpected, which could indicate potential misuse.
+
+### False positive analysis
+
+- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
+- Automated deployment processes that include runbook creation or modification might be flagged. Identify and exclude these processes by tagging them with specific identifiers in the logs.
+- Integration with third-party tools that modify runbooks as part of their normal operation can result in false positives. Work with your IT team to whitelist these tools or their associated accounts.
+- Frequent testing or development activities in non-production environments may cause alerts. Consider setting up separate monitoring rules or thresholds for these environments to reduce noise.
+- Scheduled runbook updates for compliance or policy changes can be mistaken for suspicious activity. Document these schedules and adjust the detection rule to account for them, possibly by excluding specific operation names during these times.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions. This can be done by disabling the account or restricting its permissions temporarily.
+- Review the modified or newly created runbooks to identify any malicious code or unauthorized changes. Remove or revert any suspicious modifications to ensure the integrity of the automation scripts.
+- Conduct a thorough audit of recent activities associated with the affected Azure Automation account, focusing on identifying any unauthorized access or changes made by adversaries.
+- Reset credentials and update access controls for the affected Azure Automation account to prevent further unauthorized access. Ensure that only authorized personnel have the necessary permissions to create or modify runbooks.
+- Implement additional monitoring and alerting for Azure Automation activities, specifically focusing on runbook creation and modification events, to enhance early detection of similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised.
+- Document the incident, including all actions taken and findings, to improve response strategies and update incident response plans for future reference.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
index 370c2d78c7c..625aae8b651 100644
--- a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Automation Webhook Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Automation Webhook Created
+
+Azure Automation webhooks enable automated task execution via HTTP requests, integrating with external systems. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts, maintaining persistence. The detection rule identifies webhook creation events, focusing on specific operation names and successful outcomes, to flag potential misuse in cloud environments.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal that initiated the webhook creation by examining the `event.dataset` and `azure.activitylogs.operation_name` fields.
+- Check the associated runbook linked to the created webhook to determine its purpose and inspect its content for any potentially malicious scripts or commands.
+- Investigate the source IP address and location from which the webhook creation request originated to identify any unusual or unauthorized access patterns.
+- Verify the legitimacy of the webhook by contacting the owner of the Azure Automation account or the relevant team to confirm if the webhook creation was expected and authorized.
+- Assess the broader context of the activity by reviewing recent changes or activities in the Azure Automation account to identify any other suspicious actions or configurations.
+
+### False positive analysis
+
+- Routine webhook creations for legitimate automation tasks can trigger false positives. Review the context of the webhook creation, such as the associated runbook and its purpose, to determine if it aligns with expected operations.
+- Frequent webhook creations by trusted users or service accounts may not indicate malicious activity. Consider creating exceptions for these users or accounts to reduce noise in alerts.
+- Automated deployment processes that involve creating webhooks as part of their workflow can be mistaken for suspicious activity. Document these processes and exclude them from triggering alerts if they are verified as safe.
+- Integration with third-party services that require webhook creation might generate alerts. Verify these integrations and whitelist them if they are part of approved business operations.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks.
+- Review the runbook associated with the webhook for any unauthorized or malicious scripts and remove or quarantine any identified threats.
+- Conduct a thorough audit of recent changes in the Azure Automation account to identify any unauthorized access or modifications.
+- Revoke any compromised credentials and enforce multi-factor authentication (MFA) for all accounts with access to Azure Automation.
+- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness of potential threats.
+- Implement enhanced monitoring and alerting for webhook creation and execution activities to detect similar threats in the future.
+- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
index fda5b5dbbe4..a7b14c9b569 100644
--- a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
+++ b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Conditional Access Policy Modified"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Conditional Access Policy Modified
+
+Azure Conditional Access policies are critical for managing secure access to resources by enforcing specific conditions, such as requiring multi-factor authentication. Adversaries may exploit this by altering policies to weaken security, potentially bypassing authentication measures. The detection rule monitors logs for successful modifications to these policies, flagging potential unauthorized changes that could indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the Azure activity and audit logs to identify the specific user account associated with the "Update conditional access policy" action and verify if the modification was authorized.
+- Examine the details of the modified Conditional Access policy to understand the changes made, focusing on any alterations that could weaken security, such as the removal of multi-factor authentication requirements.
+- Check the event.outcome field to confirm the success of the policy modification and correlate it with any recent access attempts or suspicious activities involving the affected resources.
+- Investigate the history of changes to the Conditional Access policies to identify any patterns or repeated unauthorized modifications that could indicate persistent malicious activity.
+- Assess the user's role and permissions to determine if they have legitimate access to modify Conditional Access policies, and review any recent changes to their account or role assignments.
+
+### False positive analysis
+
+- Routine administrative updates to Conditional Access policies by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system.
+- Scheduled policy reviews and updates as part of regular security audits may also result in false positives. Document these activities and schedule them during known maintenance windows to differentiate them from unauthorized changes.
+- Automated scripts or tools used for policy management might generate alerts if they modify policies. Ensure these tools are properly documented and their actions are logged separately to distinguish them from potential threats.
+- Changes made during the onboarding or offboarding of employees can appear as suspicious activity. Implement a process to log these events separately and cross-reference them with HR records to verify legitimacy.
+- Integration with third-party security solutions that modify policies for compliance or optimization purposes can lead to false positives. Establish a clear change management process and whitelist these integrations to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately review the modified Conditional Access policy to understand the changes made and assess the potential impact on security controls.
+- Revert any unauthorized or suspicious changes to the Conditional Access policy to restore the original security posture.
+- Conduct a thorough investigation to identify the source of the modification, including reviewing audit logs for unusual activity or unauthorized access attempts.
+- Temporarily increase monitoring and logging of Conditional Access policy changes to detect any further unauthorized modifications.
+- Notify the security team and relevant stakeholders about the incident and the steps taken to mitigate the risk.
+- If malicious activity is confirmed, initiate an incident response process, including isolating affected accounts and conducting a full security assessment.
+- Implement additional security measures, such as stricter access controls or enhanced multi-factor authentication requirements, to prevent similar incidents in the future.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview"]
diff --git a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
index d3509a4a043..64cd238b79b 100644
--- a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
+++ b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure AD Global Administrator Role Assigned"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure AD Global Administrator Role Assigned
+
+Azure AD's Global Administrator role grants comprehensive access to manage Azure AD and associated services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit logs for role changes, focusing on the addition of members to the Global Administrator role, thus helping to mitigate potential security breaches.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to identify the user account that performed the "Add member to role" operation, focusing on the specific event dataset and operation name.
+- Verify the identity of the user added to the Global Administrator role by examining the modified properties in the audit logs, specifically the new_value field indicating "Global Administrator".
+- Check the history of role assignments for the identified user to determine if this is a recurring pattern or a one-time event.
+- Investigate the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
+- Review any recent changes or activities performed by the newly assigned Global Administrator to identify any suspicious actions or configurations that may have been altered.
+- Consult with the organization's IT or security team to confirm if the role assignment was authorized and aligns with current administrative needs or projects.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role temporarily for maintenance or configuration purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
+- Automated scripts or third-party applications that require elevated permissions might be flagged if they are configured to add users to the Global Administrator role. Review and whitelist these scripts or applications if they are verified as safe and necessary for operations.
+- Organizational changes, such as mergers or restructuring, can lead to legitimate role assignments that appear suspicious. Implement a review process to verify these changes and exclude them from triggering alerts if they align with documented organizational changes.
+- Training or onboarding sessions for new IT staff might involve temporary assignment to the Global Administrator role. Establish a protocol to document and exclude these training-related assignments from detection alerts.
+
+### Response and remediation
+
+- Immediately remove any unauthorized users from the Global Administrator role to prevent further unauthorized access and control over Azure AD resources.
+- Conduct a thorough review of recent audit logs to identify any additional unauthorized changes or suspicious activities associated with the compromised account or role assignments.
+- Reset the credentials of the affected accounts and enforce multi-factor authentication (MFA) to enhance security and prevent further unauthorized access.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement conditional access policies to restrict Global Administrator role assignments to specific, trusted locations or devices.
+- Review and update role assignment policies to ensure that only a limited number of trusted personnel have the ability to assign Global Administrator roles.
+- Enhance monitoring and alerting mechanisms to detect similar unauthorized role assignments in the future, ensuring timely response to potential threats.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
index c27d826a2e9..8944eed62e2 100644
--- a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
+++ b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,43 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Global Administrator Role Addition to PIM User"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Global Administrator Role Addition to PIM User
+
+Azure AD's Global Administrator role grants extensive access, allowing users to modify any administrative setting. Privileged Identity Management (PIM) helps manage and monitor such access. Adversaries may exploit this by adding themselves or others to this role, gaining persistent control. The detection rule identifies suspicious role additions by monitoring specific audit logs, focusing on successful role assignments to PIM users, thus helping to flag potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to confirm the details of the role addition event, focusing on the event.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement fields.
+- Identify the user account that was added to the Global Administrator role by examining the azure.auditlogs.properties.target_resources.*.display_name field.
+- Check the event.outcome field to ensure the role addition was successful and not a failed attempt.
+- Investigate the user account's recent activities and login history to determine if there are any anomalies or signs of compromise.
+- Verify if the role addition aligns with any recent administrative changes or requests within the organization to rule out legitimate actions.
+- Assess the potential impact of the role addition by reviewing the permissions and access levels granted to the user.
+- If suspicious activity is confirmed, initiate a response plan to remove unauthorized access and secure the affected accounts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
+- Automated scripts or tools used for role assignments can cause false positives if they frequently add users to the Global Administrator role. Consider excluding these automated processes from monitoring or adjusting the detection rule to account for their activity.
+- Temporary project-based role assignments might be flagged as suspicious. Implement a process to document and pre-approve such assignments, allowing for their exclusion from alerts.
+- Training or onboarding sessions where new administrators are temporarily granted elevated access can result in false positives. Establish a protocol to notify the monitoring team of these events in advance, so they can be excluded from the detection rule.
+
+### Response and remediation
+
+- Immediately revoke the Global Administrator role from any unauthorized PIM user identified in the alert to prevent further unauthorized access.
+- Conduct a thorough review of recent changes made by the affected account to identify any unauthorized modifications or suspicious activities.
+- Reset the credentials of the compromised account and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities.
+- Review and update access policies and role assignments in Azure AD to ensure that only necessary personnel have elevated privileges.
+- Document the incident and response actions taken for future reference and to improve incident response procedures.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
index 1da8d4b0099..5df04014061 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "User Added as Owner for Azure Application"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 User Added as Owner for Azure Application
+
+Azure applications often require specific permissions for functionality, managed by assigning user roles. An adversary might exploit this by adding themselves or a compromised account as an owner, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to confirm the operation by filtering for event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" with a successful outcome.
+- Identify the user account that was added as an owner and the account that performed the operation to determine if they are legitimate or potentially compromised.
+- Check the history of activities associated with both the added owner and the account that performed the operation to identify any suspicious behavior or patterns.
+- Verify the application's current configuration and permissions to assess any changes made after the new owner was added.
+- Contact the legitimate owner or administrator of the Azure application to confirm whether the addition of the new owner was authorized.
+- Investigate any recent changes in the organization's user access policies or roles that might explain the addition of a new owner.
+
+### False positive analysis
+
+- Routine administrative actions: Regular maintenance or updates by IT staff may involve adding users as application owners. To manage this, create a list of authorized personnel and exclude their actions from triggering alerts.
+- Automated processes: Some applications may have automated scripts or services that add users as owners for operational purposes. Identify these processes and configure exceptions for their activities.
+- Organizational changes: During mergers or restructuring, there may be legitimate reasons for adding multiple users as application owners. Temporarily adjust the rule to accommodate these changes and review the audit logs manually.
+- Testing and development: In development environments, users may be added as owners for testing purposes. Exclude these environments from the rule or set up a separate monitoring policy with adjusted thresholds.
+
+### Response and remediation
+
+- Immediately revoke the added user's owner permissions from the Azure application to prevent further unauthorized access or configuration changes.
+- Conduct a thorough review of recent activity logs for the affected application to identify any unauthorized changes or data access that may have occurred since the user was added as an owner.
+- Reset credentials and enforce multi-factor authentication for the compromised or suspicious account to prevent further misuse.
+- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals broader compromise.
+- Implement additional monitoring on the affected application and related accounts to detect any further unauthorized access attempts or privilege escalations.
+- Review and update access control policies to ensure that only authorized personnel can modify application ownership, and consider implementing stricter approval processes for such changes.
+- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 21
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
index cdb7081845a..46faa2c238f 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "User Added as Owner for Azure Service Principal"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 User Added as Owner for Azure Service Principal
+
+Azure service principals are crucial for managing application permissions within a tenant, defining access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over application permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity.
+
+### Possible investigation steps
+
+- Review the audit log entry to confirm the event dataset is 'azure.auditlogs' and the operation name is "Add owner to service principal" with a successful outcome.
+- Identify the user account that was added as an owner and gather information about this account, including recent activity and any associated alerts.
+- Determine the service principal involved by reviewing its details, such as the application it is associated with and the permissions it holds.
+- Check the history of changes to the service principal to identify any other recent modifications or suspicious activities.
+- Investigate the context and necessity of the ownership change by contacting the user or team responsible for the service principal to verify if the change was authorized.
+- Assess the potential impact of the ownership change on the tenant's security posture, considering the permissions and access granted to the service principal.
+
+### False positive analysis
+
+- Routine administrative changes may trigger alerts when legitimate IT staff add themselves or others as owners for maintenance purposes. To manage this, create exceptions for known administrative accounts that frequently perform these actions.
+- Automated processes or scripts that manage service principal ownership as part of regular operations can cause false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags.
+- Organizational changes, such as team restructuring, might lead to multiple legitimate ownership changes. During these periods, temporarily adjust the rule sensitivity or create temporary exceptions for specific user groups involved in the transition.
+- Third-party applications that require ownership changes for integration purposes can also trigger alerts. Verify these applications and whitelist their associated service principal changes to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke the added user's ownership from the Azure service principal to prevent unauthorized access and control.
+- Conduct a thorough review of the affected service principal's permissions and access logs to identify any unauthorized changes or access attempts.
+- Reset credentials and update any secrets or keys associated with the compromised service principal to mitigate potential misuse.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement conditional access policies to restrict who can add owners to service principals, ensuring only authorized personnel have this capability.
+- Enhance monitoring and alerting for similar activities by increasing the sensitivity of alerts related to changes in service principal ownership.
+- Document the incident and response actions taken to improve future incident response and refine security policies.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
index c57337e5f17..d1d537c3f86 100644
--- a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
+++ b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -17,7 +17,42 @@ index = ["filebeat-*", "logs-azure*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Azure Kubernetes Rolebindings Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Azure Kubernetes Rolebindings Created
+Azure Kubernetes role bindings are crucial for managing access control within Kubernetes clusters, allowing specific permissions to be assigned to users, groups, or service accounts. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others high-level roles, such as cluster-admin. The detection rule monitors Azure activity logs for successful creation events of role or cluster role bindings, signaling potential unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service account associated with the role binding creation event. Focus on the `event.dataset` and `azure.activitylogs.operation_name` fields to confirm the specific operation.
+- Check the `event.outcome` field to ensure the operation was successful and not a failed attempt, which might indicate a misconfiguration or testing.
+- Investigate the permissions and roles assigned to the identified user or service account to determine if they have legitimate reasons to create role bindings or cluster role bindings.
+- Examine the context of the role binding creation, such as the time of the event and any related activities, to identify any unusual patterns or correlations with other suspicious activities.
+- Verify if the role binding grants elevated privileges, such as cluster-admin, and assess the potential impact on the cluster's security posture.
+- Cross-reference the event with any recent changes in the cluster's configuration or access policies to understand if the role binding creation aligns with authorized administrative actions.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when legitimate users create role bindings for operational purposes. To manage this, identify and whitelist specific user accounts or service accounts that regularly perform these tasks.
+- Automated deployment tools or scripts that configure Kubernetes clusters might create role bindings as part of their normal operation. Exclude these tools by filtering out known service accounts or IP addresses associated with these automated processes.
+- Scheduled maintenance or updates to the Kubernetes environment can result in multiple role binding creation events. Establish a maintenance window and suppress alerts during this period to avoid unnecessary noise.
+- Development and testing environments often have frequent role binding changes. Consider creating separate monitoring rules with adjusted thresholds or risk scores for these environments to reduce false positives.
+- Collaboration with the DevOps team can help identify expected role binding changes, allowing for preemptive exclusion of these events from triggering alerts.
+
+### Response and remediation
+
+- Immediately revoke any newly created role bindings or cluster role bindings that are unauthorized or suspicious to prevent further privilege escalation.
+- Isolate the affected Kubernetes cluster from the network to prevent potential lateral movement or further exploitation by the adversary.
+- Conduct a thorough review of recent activity logs to identify any unauthorized access or changes made by the adversary, focusing on the time frame around the alert.
+- Reset credentials and access tokens for any compromised accounts or service accounts involved in the unauthorized role binding creation.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected.
+- Implement additional monitoring and alerting for any future role binding or cluster role binding creation events to ensure rapid detection and response.
+- Review and tighten role-based access control (RBAC) policies to ensure that only necessary permissions are granted to users, groups, and service accounts, minimizing the risk of privilege escalation.
+
+## Setup
 
 The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/beaconing/command_and_control_beaconing.toml b/rules/integrations/beaconing/command_and_control_beaconing.toml
index 9d4a5ba44d8..6a1620b73f2 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,41 @@ not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "
                    "agentbeat" or "dnf" or "yum" or "apt"
                   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity
+
+Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic used by attackers to maintain covert communication with compromised systems. Adversaries exploit this by sending periodic signals to C2 servers, often mimicking legitimate traffic. The detection rule leverages statistical analysis to flag unusual beaconing while excluding known benign processes, thus highlighting potential threats without overwhelming analysts with false positives.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the statistical model.
+- Cross-reference the identified IP addresses with threat intelligence databases to determine if they are associated with known malicious C2 servers.
+- Analyze the frequency and pattern of the beaconing signals to assess whether they mimic legitimate traffic or exhibit characteristics typical of C2 communication.
+- Investigate the processes running on the source system to identify any suspicious or unauthorized applications that may be responsible for the beaconing activity.
+- Check for any recent changes or anomalies in the system's configuration or installed software that could indicate a compromise.
+- Examine the historical network activity of the source system to identify any other unusual patterns or connections that may suggest a broader compromise.
+
+### False positive analysis
+
+- The rule may flag legitimate processes that exhibit periodic network communication patterns similar to C2 beaconing. Processes like "metricbeat.exe" and "packetbeat.exe" are known to generate regular network traffic for monitoring purposes.
+- Users can manage these false positives by adding exceptions for these known benign processes in the detection rule, ensuring they are not flagged as threats.
+- Regularly review and update the list of excluded processes to include any new legitimate applications that may mimic beaconing behavior, reducing unnecessary alerts.
+- Consider implementing a whitelist approach for processes that are verified as non-threatening, allowing the statistical model to focus on truly anomalous activities.
+- Engage with network and security teams to understand the normal traffic patterns of your environment, which can help in refining the detection rule and minimizing false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with the C2 server and limit potential data exfiltration.
+- Terminate any suspicious processes identified by the alert that are not part of the known benign list, ensuring that any malicious activity is halted.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software or files.
+- Review and analyze network logs to identify any other systems that may have communicated with the same C2 server, and apply similar containment measures to those systems.
+- Restore the affected system from a known good backup to ensure that any persistent threats are removed, and verify the integrity of the restored system.
+- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure and sensitive data.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional measures are needed to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
index aaef19e8d11..91d1a58c882 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,42 @@ type = "query"
 query = '''
 beacon_stats.beaconing_score: 3
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity with High Confidence
+
+Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic where attackers maintain covert communication with compromised systems. Adversaries exploit this to issue commands, exfiltrate data, and sustain network presence. The detection rule leverages a high beaconing score to flag potential threats, aiding analysts in pinpointing suspicious activities linked to C2 operations.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the beacon_stats.beaconing_score of 3.
+- Correlate the identified IP addresses with known malicious IP databases or threat intelligence feeds to determine if they are associated with known C2 servers.
+- Analyze the frequency and pattern of the beaconing activity to assess whether it aligns with typical C2 communication patterns, such as regular intervals or specific time frames.
+- Investigate the domain names involved in the communication to check for any associations with malicious activities or suspicious registrations.
+- Examine the payloads or data transferred during the flagged communication sessions to identify any potential exfiltration of sensitive information or receipt of malicious instructions.
+- Cross-reference the involved systems with internal asset inventories to determine if they are critical assets or have been previously flagged for suspicious activities.
+- Consult with the incident response team to decide on containment or remediation actions if the investigation confirms malicious C2 activity.
+
+### False positive analysis
+
+- Regularly scheduled software updates or patch management systems may generate network traffic patterns similar to C2 beaconing. Users can create exceptions for known update servers to reduce false positives.
+- Automated backup systems that frequently communicate with cloud storage services might be flagged. Identifying and excluding these backup services from the analysis can help mitigate this issue.
+- Network monitoring tools that periodically check connectivity or system health can mimic beaconing activity. Whitelisting these monitoring tools can prevent them from being incorrectly flagged.
+- Internal applications that use polling mechanisms to check for updates or status changes may trigger alerts. Documenting and excluding these applications from the rule can minimize false positives.
+- Frequent communication with trusted third-party services, such as content delivery networks, may appear as beaconing. Establishing a list of trusted domains and excluding them from the analysis can help manage this.
+
+### Response and remediation
+
+- Isolate the affected systems from the network to prevent further communication with the C2 server and contain the threat.
+- Conduct a thorough analysis of the network traffic logs to identify any additional compromised systems or lateral movement within the network.
+- Remove any malicious software or scripts identified on the compromised systems, ensuring all traces of the C2 communication channels are eradicated.
+- Apply security patches and updates to all affected systems to close any vulnerabilities exploited by the attackers.
+- Change all credentials and authentication tokens associated with the compromised systems to prevent unauthorized access.
+- Monitor the network for any signs of re-infection or continued C2 activity, using enhanced detection rules and updated threat intelligence.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to assess the potential impact on the organization."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/container_workload_protection.toml b/rules/integrations/cloud_defend/container_workload_protection.toml
index af8cc879b82..e3fc2fe05fa 100644
--- a/rules/integrations/cloud_defend/container_workload_protection.toml
+++ b/rules/integrations/cloud_defend/container_workload_protection.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/05"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -37,4 +37,39 @@ type = "query"
 query = '''
 event.kind:alert and event.module:cloud_defend
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Container Workload Protection
+
+Container Workload Protection is crucial for securing containerized environments by monitoring and defending against threats. Adversaries may exploit vulnerabilities in container orchestration or escape isolation to access host systems. The detection rule leverages alerts from cloud defense modules, focusing on suspicious activities within container domains, enabling timely triage and investigation of potential security incidents.
+
+### Possible investigation steps
+
+- Review the alert details to confirm it matches the query criteria, specifically checking for event.kind:alert and event.module:cloud_defend.
+- Examine the context of the alert to identify any suspicious activities or anomalies within the container environment.
+- Investigate the source and destination of the alert to determine if there are any unauthorized access attempts or lateral movement within the container infrastructure.
+- Check for any recent changes or updates in the container orchestration system that might have introduced vulnerabilities.
+- Correlate the alert with other security events or logs to identify patterns or repeated attempts that could indicate a larger attack campaign.
+- Assess the impact of the alert on the containerized environment and determine if any immediate remediation actions are necessary to protect the host systems.
+
+### False positive analysis
+
+- Alerts triggered by routine maintenance tasks in container environments can be false positives. Users can create exceptions for known maintenance activities to reduce unnecessary alerts.
+- Automated deployment processes might generate alerts due to rapid changes in container states. Exclude these processes by identifying and whitelisting their specific event patterns.
+- Frequent updates to container images can cause alerts. Implement rules to recognize and exclude these updates if they match expected patterns and sources.
+- Legitimate administrative actions within container orchestration platforms may be flagged. Document and exclude these actions by correlating them with authorized user activities.
+- Network scanning tools used for security assessments might trigger alerts. Ensure these tools are recognized and excluded by defining their IP ranges and expected behaviors.
+
+### Response and remediation
+
+- Isolate the affected container to prevent lateral movement and further exploitation. This can be done by stopping the container or disconnecting it from the network.
+- Analyze the container's logs and configurations to identify any unauthorized changes or suspicious activities that align with the alert.
+- Patch any identified vulnerabilities in the container image or orchestration platform to prevent similar exploits.
+- Restore the container from a known good backup or rebuild it using a secure and updated image to ensure no residual threats remain.
+- Implement network segmentation and access controls to limit the exposure of containerized environments to potential threats.
+- Escalate the incident to the security operations team if the threat appears to have impacted the host system or other critical infrastructure.
+- Enhance monitoring and alerting rules to detect similar suspicious activities in the future, ensuring timely response to potential threats."""
 
diff --git a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
index da057f623e1..3dac6dc3a37 100644
--- a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/28"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,40 @@ process where event.module == "cloud_defend" and
 (process.name : ("grep", "egrep", "fgrep", "find", "locate", "mlocate") or process.args : ("grep", "egrep", "fgrep", "find", "locate", "mlocate")) and 
 process.args : ("*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", "*access_key*", "*.aws/credentials*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Credentials Searched For Inside A Container
+
+Containers often house applications that interact with AWS services, necessitating the storage of AWS credentials. Adversaries may exploit this by using search utilities to locate these credentials, potentially leading to unauthorized access. The detection rule identifies suspicious use of search tools within containers, flagging attempts to locate AWS credentials by monitoring specific process names and arguments, thus helping to prevent credential theft and subsequent attacks.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific search utility used (e.g., grep, find) and the arguments passed, focusing on those related to AWS credentials such as aws_access_key_id or aws_secret_access_key.
+- Examine the container's metadata and environment to determine the context of the process, including the container ID, image name, and any associated labels or tags that might indicate the container's purpose or sensitivity.
+- Check the user context under which the suspicious process was executed to assess whether it aligns with expected behavior for that user or role within the container.
+- Investigate the source of the container image to ensure it is from a trusted repository and has not been tampered with, which could indicate a supply chain compromise.
+- Analyze recent activity logs for the container to identify any other suspicious behavior or anomalies that might correlate with the search for AWS credentials, such as unexpected network connections or file modifications.
+- Review access logs for AWS services to detect any unauthorized or unusual access patterns that might suggest the use of compromised credentials.
+
+### False positive analysis
+
+- Routine maintenance scripts or automated processes may use search utilities to verify the presence of AWS credentials for legitimate configuration checks. To handle this, identify and whitelist these specific scripts or processes by their unique identifiers or execution paths.
+- Developers or system administrators might manually search for AWS credentials during debugging or configuration tasks. Implement a policy to log and review these activities, and consider excluding known user accounts or roles from triggering alerts during specific time windows or in designated environments.
+- Security audits or compliance checks often involve searching for sensitive information, including AWS credentials, to ensure proper security measures are in place. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods, or exclude specific audit tools from detection.
+- Continuous integration and deployment (CI/CD) pipelines might include steps that search for AWS credentials to validate environment configurations. Identify these pipelines and exclude their associated processes or container environments from triggering alerts, ensuring that only authorized CI/CD tools are used.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network.
+- Revoke any AWS credentials that were potentially exposed or accessed. This includes rotating keys and updating any services or applications that rely on these credentials.
+- Conduct a thorough review of the container's file system to identify any unauthorized changes or additional malicious files that may have been introduced.
+- Implement stricter access controls and monitoring on AWS credentials within containers, ensuring they are stored securely and accessed only by authorized processes.
+- Escalate the incident to the cloud security team to assess the potential impact on the broader cloud environment and determine if further investigation or response is needed.
+- Enhance logging and monitoring for similar activities across other containers and cloud environments to detect and respond to future attempts promptly.
+- Review and update container security policies to include best practices for credential management and access control, reducing the risk of similar incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
index ad37dcc18f5..e4a7b35c05e 100644
--- a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,41 @@ and process.args: (
 "/etc/shadow",
 "/etc/gshadow")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Sensitive Files Compression Inside A Container
+
+Containers are lightweight, portable environments used to run applications consistently across different systems. Adversaries may exploit compression utilities within containers to gather and exfiltrate sensitive files, such as credentials and configuration files. The detection rule identifies suspicious compression activities by monitoring for specific utilities and file paths, flagging potential unauthorized data collection attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of compression utilities such as zip, tar, gzip, hdiutil, or 7z within the container environment, focusing on the process.name and process.args fields.
+- Examine the specific file paths listed in the process.args to determine if they include sensitive files like SSH keys, AWS credentials, or Docker configurations, which could indicate unauthorized data collection.
+- Identify the container.id associated with the alert to gather more context about the container's purpose, owner, and any recent changes or deployments that might explain the activity.
+- Check the event.type field for "start" to verify the timing of the process initiation and correlate it with any known legitimate activities or scheduled tasks within the container.
+- Investigate the user or service account under which the process was executed to assess whether it has the necessary permissions and if the activity aligns with expected behavior for that account.
+- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity within the same container or across other containers in the environment.
+
+### False positive analysis
+
+- Routine backup operations may trigger the rule if they involve compressing sensitive files for storage. To handle this, identify and exclude backup processes or scripts that are known and trusted.
+- Automated configuration management tools might compress configuration files as part of their normal operation. Exclude these tools by specifying their process names or paths in the exception list.
+- Developers or system administrators might compress sensitive files during legitimate troubleshooting or maintenance activities. Establish a process to log and review these activities, and exclude them if they are verified as non-threatening.
+- Continuous integration and deployment pipelines could involve compressing configuration files for deployment purposes. Identify these pipelines and exclude their associated processes to prevent false positives.
+- Security tools that perform regular audits or scans might compress files for analysis. Ensure these tools are recognized and excluded from triggering the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further data exfiltration or unauthorized access. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure. Focus on the specific file paths identified in the alert.
+- Change credentials and keys that may have been compromised, including SSH keys, AWS credentials, and Docker configurations. Ensure that new credentials are distributed securely.
+- Review and update access controls and permissions for sensitive files within containers to minimize exposure. Ensure that only necessary processes and users have access to these files.
+- Implement monitoring and alerting for similar compression activities in other containers to detect potential threats early. Use the identified process names and arguments as indicators.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
+- Conduct a post-incident review to identify gaps in security controls and update container security policies to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
index dc8fd0b0b06..1dc5c0c213c 100644
--- a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,41 @@ or
     and process.args : ("*id_rsa*", "*id_dsa*")
 ))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Sensitive Keys Or Passwords Searched For Inside A Container
+
+Containers encapsulate applications, providing isolated environments. Adversaries may exploit search utilities like grep or find to locate sensitive credentials within containers, potentially leading to unauthorized access or container escape. The detection rule identifies suspicious searches for private keys or passwords, flagging potential credential access attempts by monitoring process activities and arguments.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific container where the search activity occurred, using the container.id field to gather context about the environment.
+- Examine the process.name and process.args fields to determine the exact command executed and assess whether it aligns with typical usage patterns or indicates malicious intent.
+- Check the user context under which the process was executed to understand if the activity was performed by a legitimate user or an unauthorized entity.
+- Investigate the container's recent activity logs to identify any other suspicious behavior or anomalies that might correlate with the search for sensitive keys or passwords.
+- Assess the potential impact by determining if any sensitive files, such as private keys or password files, were accessed or exfiltrated following the search activity.
+- If possible, correlate the event with network logs to identify any outbound connections that might suggest data exfiltration attempts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators use grep or find to audit or manage SSH keys and passwords within containers. To mitigate this, create exceptions for known administrative scripts or processes that regularly perform these tasks.
+- Automated backup or configuration management tools might search for sensitive files as part of their normal operation. Identify these tools and exclude their process IDs or specific command patterns from triggering the rule.
+- Security scanning tools that check for the presence of sensitive files could be flagged. Whitelist these tools by their process names or arguments to prevent false positives.
+- Developers or DevOps personnel might use search utilities during debugging or development processes. Establish a list of trusted users or roles and exclude their activities from the rule to reduce noise.
+- Continuous integration/continuous deployment (CI/CD) pipelines may include steps that search for keys or passwords for validation purposes. Exclude these pipeline processes by identifying their unique process arguments or container IDs.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential container escape to the host system. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the container's logs and process activities to identify any unauthorized access or data exfiltration attempts. Pay special attention to the processes and arguments flagged by the detection rule.
+- Rotate any potentially compromised credentials, including SSH keys and passwords, that were stored or accessed within the container. Ensure that new credentials are securely stored and managed.
+- Assess the container's configuration and access controls to identify and rectify any security misconfigurations that may have allowed the unauthorized search for sensitive information.
+- Implement additional monitoring and alerting for similar suspicious activities across other containers and the host environment to detect and respond to potential threats promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread beyond the initial container.
+- Review and update container security policies and practices to prevent recurrence, including enforcing least privilege access and using secrets management solutions to handle sensitive information securely."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
index 14581165c8e..21eddfa9402 100644
--- a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/06"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,41 @@ type = "eql"
 query = '''
 file where event.module== "cloud_defend" and event.type != "deletion" and file.path== "/etc/ld.so.preload"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Dynamic Linker Preload Shared Object Inside A Container
+
+The dynamic linker in Linux loads necessary libraries for programs at runtime, with the `ld.so.preload` file specifying libraries to load first. Adversaries exploit this by redirecting it to malicious libraries, gaining unauthorized access and evading detection. The detection rule identifies suspicious modifications to this file within containers, signaling potential hijacking attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is "/etc/ld.so.preload" and the event type is not "deletion", as specified in the query.
+- Examine the container's metadata and context to identify the specific container where the modification occurred, including container ID, image, and host details.
+- Investigate recent changes to the "/etc/ld.so.preload" file within the container by checking the file's modification history and identifying the user or process responsible for the change.
+- Analyze the contents of the modified "/etc/ld.so.preload" file to determine if it references any suspicious or unauthorized libraries.
+- Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns, such as unauthorized access attempts or execution of unknown processes within the container.
+- Assess the potential impact of the modification by evaluating the libraries listed in the preload file and their potential to grant unauthorized access or evade detection.
+- Consider isolating the affected container to prevent further unauthorized access or malicious activity while the investigation is ongoing.
+
+### False positive analysis
+
+- Routine system updates or maintenance activities may modify the ld.so.preload file. Users should verify if the changes coincide with scheduled updates and consider excluding these events if they are confirmed to be benign.
+- Some containerized applications might legitimately modify the ld.so.preload file to optimize performance or load specific libraries. Users should identify these applications and create exceptions for their known behaviors to prevent false alerts.
+- Automated configuration management tools might alter the ld.so.preload file as part of their normal operations. Users should review the tool's activity logs and whitelist these actions if they are consistent with expected behavior.
+- Development or testing environments often involve frequent changes to system files, including ld.so.preload. Users should differentiate between production and non-production environments and apply more lenient rules to the latter to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or execution of malicious code. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the `/etc/ld.so.preload` file within the container to identify any unauthorized or malicious entries. Remove any entries that are not recognized or are confirmed to be malicious.
+- Verify the integrity of the container's base image and all installed libraries to ensure no other components have been tampered with. Rebuild the container from a trusted image if necessary.
+- Implement monitoring and alerting for any future modifications to the `/etc/ld.so.preload` file across all containers to detect similar threats promptly.
+- Review and tighten access controls and permissions for container environments to minimize the risk of unauthorized modifications to critical system files.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other parts of the infrastructure.
+- Document the incident, including the steps taken for containment and remediation, to improve response strategies and update incident response plans for future reference."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
index bb9fab55b3f..7606594d94a 100644
--- a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,40 @@ process where container.id: "*" and event.type== "start" and
 (process.args: ("nc", "ncat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab"))
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Network Tool Launched Inside A Container
+
+Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries exploit network tools within containers for reconnaissance or lateral movement, leveraging utilities like `nc` or `nmap` to map networks or intercept traffic. The detection rule identifies these tools' execution by monitoring process starts and arguments, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the container ID and process name from the alert to identify which container and network tool triggered the alert.
+- Examine the process arguments to understand the specific command or options used, which may provide insight into the intent of the tool's execution.
+- Check the container's creation and modification timestamps to determine if the container was recently deployed or altered, which could indicate suspicious activity.
+- Investigate the user or service account associated with the process start event to assess if it aligns with expected behavior or if it might be compromised.
+- Analyze network logs and traffic patterns from the container to identify any unusual outbound connections or data exfiltration attempts.
+- Correlate the alert with other security events or logs from the same container or host to identify potential lateral movement or further malicious activity.
+
+### False positive analysis
+
+- Development and testing environments often use network tools for legitimate purposes such as debugging or network configuration. To manage this, create exceptions for containers identified as part of these environments by tagging them appropriately and excluding them from the rule.
+- Automated scripts or orchestration tools may trigger network utilities for routine checks or maintenance tasks. Identify these scripts and whitelist their associated container IDs or process names to prevent false alerts.
+- Some monitoring solutions deploy containers with built-in network tools for performance analysis. Verify the legitimacy of these containers and exclude them from the rule by using specific labels or container IDs.
+- Containers used for educational or training purposes might intentionally run network tools. Ensure these containers are marked and excluded from detection by setting up rules based on their unique identifiers or labels.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further network reconnaissance or lateral movement. This can be done by restricting its network access or stopping the container entirely.
+- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data exfiltration attempts. Focus on the execution of the flagged network utilities.
+- Remove any unauthorized or suspicious network tools from the container to prevent further misuse. Ensure that only necessary and approved utilities are present.
+- Patch and update the container image to address any vulnerabilities that may have been exploited. Rebuild and redeploy the container using the updated image.
+- Implement network segmentation to limit the container's access to sensitive resources and reduce the potential impact of similar threats in the future.
+- Enhance monitoring and alerting for the execution of network utilities within containers, ensuring that any future occurrences are detected promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
index 24a7ee25a08..802e409051a 100644
--- a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,41 @@ query = '''
 process where container.id: "*" and event.type== "start" 
   and process.name: ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "runc", "systemd", "crictl")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Container Management Utility Run Inside A Container
+
+Container management utilities like Docker and Kubernetes are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types.
+
+### Possible investigation steps
+
+- Review the specific container ID where the suspicious process was executed to determine its purpose and origin.
+- Examine the process name and command line arguments to understand the context of the execution and identify any anomalies or unauthorized commands.
+- Check the user and permissions associated with the process to assess if it aligns with expected roles and access levels for container management tasks.
+- Investigate the container's creation and deployment history to identify any recent changes or deployments that could explain the presence of the management utility.
+- Analyze network activity associated with the container to detect any unusual connections or data transfers that might indicate malicious activity.
+- Correlate the event with other security alerts or logs to identify patterns or related incidents that could provide additional context or evidence of compromise.
+
+### False positive analysis
+
+- Routine maintenance tasks within containers can trigger the rule. Exclude known maintenance scripts or processes by adding them to an allowlist if they frequently execute container management utilities.
+- Development and testing environments often run container management commands for legitimate purposes. Consider excluding these environments from monitoring or adjust the rule to focus on production environments only.
+- Automated deployment tools may execute container management commands as part of their workflow. Identify these tools and create exceptions for their activities to prevent false positives.
+- System updates or patches might involve running container management utilities. Monitor update schedules and temporarily adjust the rule to avoid unnecessary alerts during these periods.
+- Legitimate administrative actions by authorized personnel can trigger the rule. Implement user-based exceptions for known administrators to reduce false positives while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or execution of commands. This can be done by stopping the container or disconnecting it from the network.
+- Review the container's configuration and access controls to identify any misconfigurations or unauthorized access permissions that may have allowed the execution of container management utilities.
+- Conduct a thorough analysis of the container's logs and process activities to determine the extent of the compromise and identify any additional malicious activities or lateral movement attempts.
+- Remove any unauthorized or suspicious binaries and scripts from the container to prevent further exploitation.
+- Patch and update the container image and underlying host system to address any known vulnerabilities that may have been exploited.
+- Implement stricter access controls and monitoring on container management utilities to ensure they are only accessible by authorized users and processes.
+- Escalate the incident to the security operations team for further investigation and to assess the need for broader security measures across the container environment."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
index 64fb497ec44..8d6d75577e3 100644
--- a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,41 @@ file where container.id: "*" and event.type in ("change", "creation") and
 (process.name : "chmod" or process.args : "chmod") and 
 process.args : ("*x*", "777", "755", "754", "700") and not process.args: "-x"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File Made Executable via Chmod Inside A Container
+
+Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers.
+
+### Possible investigation steps
+
+- Review the container ID associated with the alert to identify the specific container where the `chmod` command was executed.
+- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable.
+- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior.
+- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions.
+- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code.
+- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack.
+
+### False positive analysis
+
+- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations.
+- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise.
+- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities.
+- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening.
+- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary.
+- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities.
+- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance.
+- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
index 16de26f880e..f3ed4d5f336 100644
--- a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,42 @@ process.entry_leader.same_as_process== true and
 /* interactive process */
 process.interactive == true
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Interactive Exec Command Launched Against A Running Container
+
+In containerized environments, the 'exec' command is used to run processes inside a running container, often for debugging or administrative tasks. Adversaries may exploit this to gain shell access, potentially leading to further compromise or container escape. The detection rule identifies such activities by monitoring for interactive 'exec' sessions, focusing on initial processes within containers, and flagging high-risk interactions.
+
+### Possible investigation steps
+
+- Review the container.id to identify which specific container the interactive exec command was executed against and gather information about its purpose and criticality.
+- Examine the process.entry_leader.entry_meta.type to confirm that the process was indeed initiated within a container environment, ensuring the context of the alert is accurate.
+- Investigate the process.entry_leader.same_as_process field to verify that the process in question is the initial process run in the container, which may indicate a new or unexpected session.
+- Analyze the process.interactive field to understand the nature of the interaction and determine if it aligns with expected administrative activities or if it suggests unauthorized access.
+- Check for any recent changes or deployments in the container environment that might explain the interactive session, such as updates or debugging activities.
+- Correlate the event with user activity logs to identify the user or service account responsible for initiating the exec command and assess their access permissions and recent actions.
+- Investigate any subsequent actions or commands executed within the container following the interactive session to identify potential malicious activities or attempts at container breakout.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators use 'kubectl exec' for legitimate maintenance or debugging. To manage this, create exceptions for known administrator accounts or specific maintenance windows.
+- Automated scripts or monitoring tools that use 'exec' for health checks or logging purposes can also cause false positives. Identify these scripts and exclude their associated processes or user accounts from triggering the rule.
+- Development and testing activities often involve frequent use of 'exec' commands for container interaction. Consider excluding specific development environments or user roles from the rule to reduce noise.
+- Continuous integration/continuous deployment (CI/CD) pipelines might use 'exec' to deploy or test applications within containers. Exclude these pipeline processes or service accounts to prevent false alerts.
+- If certain containers are known to require frequent interactive access for legitimate reasons, consider tagging these containers and configuring the rule to ignore interactions with them.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the environment. This can be done by pausing or stopping the container.
+- Review and terminate any unauthorized or suspicious interactive sessions identified by the alert to cut off the adversary's access.
+- Conduct a thorough analysis of the container's filesystem and running processes to identify any malicious scripts or binaries that may have been introduced during the interactive session.
+- Revert the container to a known good state by redeploying it from a trusted image, ensuring that any potential backdoors or malicious modifications are removed.
+- Implement network segmentation and access controls to limit the ability of users to execute 'exec' commands on containers, especially for high-risk or production environments.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containers or systems have been compromised.
+- Enhance monitoring and alerting for similar activities by ensuring that all interactive 'exec' commands are logged and reviewed, and consider implementing stricter access controls for container management tools like kubectl."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
index 55c5ccec6c3..3582617b6ba 100644
--- a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,40 @@ event.action in ("fork", "exec") and event.action != "end"
 process.args: "*/*sh"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Interactive Shell Spawned From Inside A Container
+
+Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries may exploit containers by spawning interactive shells to execute unauthorized commands, potentially leading to container escape and host compromise. The detection rule identifies such threats by monitoring for shell processes initiated within containers, focusing on specific process actions and arguments indicative of interactive sessions.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific container ID where the interactive shell was spawned. This will help in isolating the affected container for further analysis.
+- Examine the process executable and arguments, particularly looking for shell types and interactive flags (e.g., "-i", "-it"), to understand the nature of the shell session initiated.
+- Check the process entry leader to determine if the shell process is part of a larger process tree, which might indicate a more complex attack chain or script execution.
+- Investigate the user context under which the shell was spawned to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
+- Analyze recent logs and events from the container and host to identify any preceding suspicious activities or anomalies that might have led to the shell spawning.
+- Correlate the event with other security alerts or incidents to determine if this is part of a broader attack pattern or campaign targeting the environment.
+
+### False positive analysis
+
+- Development and testing activities may trigger this rule when developers intentionally spawn interactive shells within containers for debugging or configuration purposes. To manage this, create exceptions for specific user accounts or container IDs frequently used in development environments.
+- Automated scripts or orchestration tools that use interactive shells for legitimate tasks can also cause false positives. Identify these scripts and exclude their associated process names or arguments from the rule.
+- Some container management platforms might use interactive shells as part of their normal operations. Review the processes and arguments used by these platforms and add them to an exception list if they are known to be safe.
+- Regular maintenance tasks that require interactive shell access, such as system updates or configuration changes, can be excluded by scheduling these tasks during known maintenance windows and temporarily adjusting the rule settings.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential container escape. This can be done by stopping the container or disconnecting it from the network.
+- Capture and preserve forensic data from the container, including logs, process lists, and network activity, to aid in further investigation and understanding of the attack vector.
+- Conduct a thorough review of the container's configuration and permissions to identify and rectify any misconfigurations or vulnerabilities that may have been exploited.
+- Patch and update the container image and any associated software to address known vulnerabilities that could have been leveraged by the attacker.
+- Implement stricter access controls and monitoring on container environments to prevent unauthorized shell access, such as using role-based access controls and enabling audit logging.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other parts of the infrastructure.
+- Review and enhance detection capabilities to identify similar threats in the future, ensuring that alerts are tuned to detect unauthorized shell access attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
index c739bdcdcbf..50baf63647d 100644
--- a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,40 @@ process.args: ("nc","ncat","netcat","netcat.openbsd","netcat.traditional")
           or process.args:("-*l*", "--listen", "-*p*", "--source-port")
           )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Netcat Listener Established Inside A Container
+
+Netcat is a versatile networking tool used for reading and writing data across network connections, often employed for legitimate purposes like debugging and network diagnostics. However, adversaries can exploit Netcat to establish unauthorized backdoors or exfiltrate data from containers. The detection rule identifies suspicious Netcat activity by monitoring process events within containers, focusing on specific arguments that indicate a listening state, which is a common trait of malicious use. This proactive detection helps mitigate potential threats by flagging unusual network behavior indicative of compromise.
+
+### Possible investigation steps
+
+- Review the container ID associated with the alert to identify the specific container where the Netcat listener was established. This can help in understanding the context and potential impact.
+- Examine the process name and arguments to confirm the presence of Netcat and its listening state. Look for arguments like "-l", "--listen", "-p", or "--source-port" to verify the listener setup.
+- Check the parent process of the Netcat instance to determine how it was initiated. This can provide insights into whether it was started by a legitimate application or a potentially malicious script.
+- Investigate the network connections associated with the container to identify any unusual or unauthorized connections that may indicate data exfiltration or communication with a command and control server.
+- Analyze the container's recent activity and logs to identify any other suspicious behavior or anomalies that could be related to the Netcat listener, such as unexpected file modifications or other process executions.
+- Assess the container's security posture and configuration to determine if there are any vulnerabilities or misconfigurations that could have been exploited to establish the Netcat listener.
+
+### False positive analysis
+
+- Development and testing activities within containers may trigger the rule if Netcat is used for legitimate debugging or network diagnostics. Users can create exceptions for specific container IDs or process names associated with known development environments.
+- Automated scripts or tools that utilize Netcat for routine network checks or health monitoring might be flagged. To mitigate this, users can whitelist these scripts by identifying their unique process arguments or execution patterns.
+- Containers running network services that rely on Netcat for legitimate communication purposes could be mistakenly identified. Users should document and exclude these services by specifying their container IDs and associated process arguments.
+- Security tools or monitoring solutions that incorporate Netcat for legitimate scanning or testing purposes may cause false positives. Users can manage this by excluding these tools based on their known process names and arguments.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data transfers that may have occurred.
+- Remove any unauthorized Netcat binaries or scripts found within the container to eliminate the backdoor.
+- Rebuild the container from a known good image to ensure no residual malicious artifacts remain.
+- Update container images and underlying host systems with the latest security patches to mitigate vulnerabilities that could be exploited by similar threats.
+- Implement network segmentation and firewall rules to restrict unauthorized outbound connections from containers, reducing the risk of data exfiltration.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other containers or systems within the environment."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
index d4cdae3dcc6..dd3a14b5e6e 100644
--- a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,41 @@ process.entry_leader.entry_meta.type: "sshd"  and
 /* interactive process*/
 process.interactive== true
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SSH Connection Established Inside A Running Container
+
+SSH (Secure Shell) is a protocol used to securely access and manage systems remotely. In containerized environments, running an SSH daemon is generally discouraged due to security risks. Adversaries may exploit SSH to gain unauthorized access or maintain persistence within a compromised container. The detection rule identifies SSH connections initiated within containers by monitoring for SSH daemon processes that start new sessions, indicating potential unauthorized access attempts. This rule is crucial for identifying and mitigating threats related to initial access and lateral movement within containerized environments.
+
+### Possible investigation steps
+
+- Review the container ID associated with the alert to identify the specific container where the SSH connection was established.
+- Examine the process details, particularly focusing on the entry leader and session leader fields, to determine if the SSH daemon process is the initial process or part of a new session within the container.
+- Check for any interactive sessions initiated by the SSH daemon to confirm if the connection was actively used for interaction.
+- Investigate the source of the SSH connection by analyzing network logs or connection details to identify the originating IP address and assess if it is known or suspicious.
+- Correlate the event with user activity logs to determine if the SSH connection aligns with expected user behavior or if it indicates potential unauthorized access.
+- Assess the container's configuration and security posture to understand why an SSH daemon is running and evaluate if it is necessary or a security oversight.
+- Review any recent changes or deployments related to the container to identify potential vulnerabilities or misconfigurations that could have been exploited.
+
+### False positive analysis
+
+- Legitimate administrative access to containers via SSH may trigger the rule. To manage this, create exceptions for known administrative IP addresses or user accounts that regularly access containers for maintenance.
+- Automated scripts or tools that use SSH for legitimate purposes, such as configuration management or deployment, can cause false positives. Identify these tools and exclude their specific process signatures or user accounts from the rule.
+- Development or testing environments where SSH is used for debugging or monitoring may also trigger alerts. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags.
+- Containers running legacy applications that require SSH for functionality might be flagged. Document these applications and create exceptions based on their specific container IDs or hostnames.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
+- Terminate the SSH daemon process running inside the container to cut off any active unauthorized sessions.
+- Conduct a thorough review of access logs and container activity to identify any unauthorized access attempts or suspicious behavior.
+- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent further unauthorized access.
+- Deploy updated container images without SSH daemons and ensure that future container deployments adhere to security best practices.
+- Implement network segmentation to limit access to containerized environments and reduce the attack surface for similar threats.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
index 5ed644ebed5..a0e12e805cb 100644
--- a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,41 @@ process where container.id: "*" and event.type== "start" and
 event.action in ("fork", "exec") and event.action != "end" and 
 process.name: ("sshd", "ssh", "autossh")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SSH Process Launched From Inside A Container
+
+SSH (Secure Shell) is a protocol used for secure remote access and management of systems. Within container environments, SSH usage is atypical and can signal potential security risks. Adversaries may exploit SSH to move laterally between containers or escape to the host system. The detection rule identifies SSH processes initiated within containers, flagging potential unauthorized access or persistence attempts by monitoring process events and container identifiers.
+
+### Possible investigation steps
+
+- Review the container identifier (container.id) associated with the SSH process to determine which container initiated the process and assess its intended function.
+- Examine the process start event details, including the process name (sshd, ssh, autossh) and event actions (fork, exec), to understand the context and nature of the SSH activity.
+- Check for any recent changes or deployments related to the container to identify if the SSH process aligns with expected behavior or recent updates.
+- Investigate the source and destination of the SSH connection to determine if it involves unauthorized or suspicious endpoints, potentially indicating lateral movement or an attempt to access the host system.
+- Analyze user accounts and credentials used in the SSH session to verify if they are legitimate and authorized for container access, looking for signs of compromised credentials.
+- Correlate the SSH activity with other security events or alerts to identify patterns or additional indicators of compromise within the container environment.
+
+### False positive analysis
+
+- Development and testing environments may intentionally use SSH for debugging or administrative tasks. Users can create exceptions for specific container IDs or hostnames associated with these environments to reduce noise.
+- Automated scripts or orchestration tools might use SSH to manage containers. Identify these tools and exclude their process IDs or user accounts from triggering the rule.
+- Some legacy applications might rely on SSH for internal communication. Review these applications and whitelist their specific process names or container images to prevent false alerts.
+- Containers running SSH for legitimate remote access purposes, such as maintenance, should be documented. Exclude these containers by their unique identifiers or labels to avoid unnecessary alerts.
+- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent potential lateral movement or further unauthorized access. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the container's logs and environment to identify any unauthorized access or changes. Pay special attention to SSH-related logs and any anomalies in user activity.
+- Revoke any SSH keys or credentials that may have been compromised. Ensure that all SSH keys used within the container environment are rotated and that access is restricted to only necessary personnel.
+- Assess the container image and configuration for vulnerabilities or misconfigurations that may have allowed the SSH process to be initiated. Patch any identified vulnerabilities and update the container image accordingly.
+- Implement network segmentation to limit the ability of containers to communicate with each other and the host system, reducing the risk of lateral movement.
+- Enhance monitoring and alerting for SSH activity within container environments to ensure rapid detection of similar threats in the future. This includes setting up alerts for any SSH process initiation within containers.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been affected."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
index 30220e18f92..edd4637f770 100644
--- a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ query = '''
 file where container.id:"*" and
   event.type in ("change", "creation") and file.name: ("authorized_keys", "authorized_keys2", "sshd_config")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SSH Authorized Keys File Modified Inside a Container
+
+In containerized environments, SSH keys facilitate secure access, but adversaries can exploit this by altering the authorized_keys file to gain unauthorized access. This detection rule identifies suspicious changes to SSH configuration files within containers, signaling potential persistence tactics. By monitoring file modifications, it helps detect unauthorized SSH usage, a common indicator of compromise.
+
+### Possible investigation steps
+
+- Review the container ID associated with the alert to identify the specific container where the modification occurred.
+- Examine the timestamp of the event to determine when the file change or creation took place and correlate it with any known activities or changes in the environment.
+- Investigate the user account or process that made the modification to the authorized_keys or sshd_config file to assess if it was an authorized action.
+- Check for any recent SSH connections to the container, especially those using public key authentication, to identify potential unauthorized access.
+- Analyze the contents of the modified authorized_keys or sshd_config file to identify any suspicious or unauthorized keys or configurations.
+- Review the container's logs and any related network activity around the time of the modification for signs of compromise or lateral movement attempts.
+
+### False positive analysis
+
+- Routine updates or deployments within containers may modify SSH configuration files, leading to false positives. To manage this, create exceptions for known update processes or deployment scripts that regularly alter these files.
+- Automated configuration management tools like Ansible or Puppet might change SSH files as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process IDs or user accounts.
+- Development or testing environments often see frequent changes to SSH keys for legitimate reasons. Consider excluding these environments from the rule or setting up a separate, less sensitive monitoring profile for them.
+- Scheduled maintenance tasks that involve SSH key rotation can trigger alerts. Document these tasks and schedule exceptions during their execution windows to prevent unnecessary alerts.
+- Container orchestration systems might modify SSH configurations as part of scaling or updating services. Recognize these patterns and adjust the rule to ignore changes made by these systems.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
+- Revoke any unauthorized SSH keys found in the authorized_keys file to cut off the adversary's access.
+- Conduct a thorough review of all SSH configuration files within the container to ensure no additional unauthorized modifications have been made.
+- Restore the container from a known good backup if available, ensuring that the backup does not contain the unauthorized changes.
+- Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if other containers or systems have been compromised.
+- Update detection and alerting mechanisms to include additional indicators of compromise related to SSH key manipulation and unauthorized access attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
index 84a94f11ed9..b8300c89e9b 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,40 @@ process where event.module == "cloud_defend" and
   process.args : "/dev/sd*" and not process.args == "-R" and
   container.security_context.privileged == true
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File System Debugger Launched Inside a Privileged Container
+
+DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in privileged containers, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "debugfs" and check the specific arguments used, particularly looking for "/dev/sd*" to identify potential access to host file systems.
+- Verify the container's security context to ensure it is indeed privileged, as this increases the risk of host-level access.
+- Investigate the origin of the container image and deployment configuration to determine if the use of a privileged container was intentional or necessary.
+- Check the user or service account that initiated the process to assess if it aligns with expected behavior or if it indicates potential unauthorized access.
+- Examine recent logs and events from the container and host to identify any unusual activities or patterns that coincide with the alert.
+- Assess the potential impact by identifying any sensitive files or directories that may have been accessed or modified by the debugfs process.
+
+### False positive analysis
+
+- Routine maintenance tasks using DebugFS in privileged containers can trigger alerts. To manage this, identify and document regular maintenance processes and create exceptions for these specific processes.
+- Automated scripts or tools that utilize DebugFS for legitimate monitoring or debugging purposes may cause false positives. Review these scripts and whitelist them by excluding their specific process arguments or execution contexts.
+- Development and testing environments often run privileged containers with DebugFS for debugging purposes. Establish a separate set of rules or exceptions for these environments to prevent unnecessary alerts.
+- Backup or recovery operations that involve direct disk access might use DebugFS. Ensure these operations are well-documented and create exceptions based on their unique process signatures or execution schedules.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or removing its network access.
+- Conduct a thorough review of the container's security context and capabilities to ensure it does not have unnecessary privileges. Adjust the container's configuration to remove privileged access if not required.
+- Analyze the container's logs and process history to identify any unauthorized access or actions taken by the DebugFS utility. This will help determine the extent of the potential breach.
+- If unauthorized access to host files is confirmed, perform a security assessment of the host system to identify any changes or breaches. This may include checking for new user accounts, modified files, or unexpected network connections.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. Provide them with all relevant logs and findings.
+- Implement additional monitoring and alerting for similar activities across other containers and hosts to detect any recurrence of this threat.
+- Review and update container deployment policies to enforce the principle of least privilege, ensuring containers only have the necessary permissions to perform their intended functions."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
index b8ce04a318a..1a68d5bfeb2 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,41 @@ query = '''
 process where event.module == "cloud_defend" and  event.type== "start" and 
 (process.name== "mount" or process.args== "mount") and container.security_context.privileged == true
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Mount Launched Inside a Privileged Container
+
+In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm that the process name or arguments include "mount" and that the container's security context is marked as privileged.
+- Identify the container involved in the alert by examining the container ID or name, and gather information about its purpose and the applications it runs.
+- Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function.
+- Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity.
+- Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed.
+- Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation.
+
+### False positive analysis
+
+- Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns.
+- Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions.
+- Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise.
+- Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts.
+- Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network.
+- Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary.
+- Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files.
+- If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts.
+- Patch and update the container image and host system to address any vulnerabilities that may have been exploited.
+- Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like `mount`.
+- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
index e02c4778a14..f6de548d46d 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,41 @@ query = '''
 file where event.module == "cloud_defend" and event.action == "open" and 
 event.type == "change" and file.name : "notify_on_release"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Container Escape via Modified notify_on_release File
+
+In containerized environments, the `notify_on_release` file in cgroups can trigger host-level commands when a cgroup becomes empty. Adversaries exploit this by modifying the file from privileged containers, potentially executing unauthorized commands on the host. The detection rule monitors changes to `notify_on_release` files, flagging suspicious modifications indicative of privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file involved is indeed the "notify_on_release" file and verify the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
+- Identify the container from which the modification attempt originated by examining the associated metadata, such as container ID or name, to understand the context of the alert.
+- Check the privileges and capabilities assigned to the container, specifically looking for SYS_ADMIN capabilities, which could allow modification of cgroup settings.
+- Investigate the release_agent file associated with the cgroup to determine if any unauthorized or suspicious commands are configured to execute upon cgroup release.
+- Review recent activity logs and command history within the container to identify any anomalous behavior or commands that could indicate an attempt to exploit the notify_on_release mechanism.
+- Assess the potential impact on the host system by determining if any unauthorized commands have been executed as a result of the modification, and evaluate the need for containment or remediation actions.
+
+### False positive analysis
+
+- Routine maintenance tasks in containerized environments may involve legitimate modifications to the notify_on_release file. Users should verify if such changes align with scheduled maintenance activities.
+- Automated container orchestration tools might modify cgroup settings, including the notify_on_release file, as part of their normal operations. Users can create exceptions for known orchestration tools by identifying their specific process IDs or user accounts.
+- Some containerized applications may require modifications to cgroup settings for performance tuning or resource management. Users should document these applications and exclude their expected behavior from triggering alerts.
+- Development and testing environments often involve frequent changes to container configurations, including cgroup files. Users can reduce noise by applying the rule only to production environments or by setting up separate monitoring profiles for non-production systems.
+- If a specific container consistently triggers alerts without malicious intent, users can whitelist the container by its unique identifier or image name, ensuring that only unexpected changes are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized actions. This can be done by stopping the container or disconnecting it from the network.
+- Review and revoke any unnecessary privileges or capabilities, such as SYS_ADMIN, from the container to minimize the risk of exploitation.
+- Inspect the release_agent file associated with the cgroup to identify any unauthorized commands or scripts that may have been set for execution.
+- Remove or reset any malicious or unauthorized entries in the release_agent file to prevent further execution of host-level commands.
+- Conduct a thorough audit of the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the alert.
+- Patch and update the container runtime and host operating system to address any known vulnerabilities that could facilitate container escapes.
+- Enhance monitoring and alerting for similar activities by ensuring that all cgroup modifications are logged and reviewed regularly, and consider implementing additional security controls such as AppArmor or SELinux to restrict container capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
index 8c44e8b3c60..0c03015586e 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,41 @@ query = '''
 file where event.module == "cloud_defend" and event.action == "open" and 
 event.type == "change" and file.name : "release_agent"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Container Escape via Modified release_agent File
+
+In containerized environments, the release_agent file in CGroup directories can execute scripts upon process termination. Adversaries exploit this by modifying the file from privileged containers, potentially escalating privileges or escaping to the host. The detection rule monitors changes to the release_agent file, flagging unauthorized modifications indicative of such exploits.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file involved is the release_agent file and that the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
+- Identify the container from which the modification attempt originated, focusing on whether it has SYS_ADMIN capabilities, which could indicate a privileged container.
+- Check the history of the release_agent file for any recent changes or modifications, including timestamps and user accounts involved, to understand the context of the modification.
+- Investigate the processes running within the container at the time of the alert to identify any suspicious or unauthorized activities that could be related to privilege escalation attempts.
+- Examine the network activity and connections from the container to detect any unusual outbound traffic that might suggest an attempt to communicate with external systems or exfiltrate data.
+- Review system logs and audit logs on the host for any signs of unauthorized access or privilege escalation attempts that coincide with the alert timestamp.
+- Assess the security posture of the container environment, including the configuration of CGroup directories and permissions, to identify potential vulnerabilities that could be exploited for container escape.
+
+### False positive analysis
+
+- Routine maintenance scripts or system updates may modify the release_agent file without malicious intent. Users can create exceptions for known maintenance activities by identifying the specific processes or scripts involved and excluding them from the rule.
+- Automated container management tools might access and modify the release_agent file as part of their normal operations. Users should verify the legitimacy of these tools and whitelist their actions to prevent unnecessary alerts.
+- Custom container orchestration solutions could interact with the release_agent file for legitimate reasons. Users should document these interactions and configure the rule to ignore changes made by these trusted solutions.
+- Development and testing environments often involve frequent changes to container configurations, including the release_agent file. Users can reduce false positives by setting up separate monitoring profiles for these environments, allowing more lenient detection thresholds.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized actions or potential spread to other containers or the host system.
+- Revoke SYS_ADMIN capabilities from the container to limit its ability to modify critical system files and directories.
+- Conduct a thorough review of the modified release_agent file to identify any malicious scripts or commands that may have been inserted.
+- Restore the release_agent file to its original state from a known good backup to ensure no unauthorized scripts are executed.
+- Investigate the source of the privilege escalation to determine how the adversary gained SYS_ADMIN capabilities and address any security gaps.
+- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the host system.
+- Implement additional monitoring and alerting for changes to critical files and directories within privileged containers to enhance detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
index fc951b330cb..adf915df75f 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual ISO Code
+
+Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to unexpected geo-locations. Adversaries exploit command and control channels to exfiltrate data to these unusual regions. The detection rule leverages ML to flag deviations from normal traffic, indicating potential exfiltration activities, thus aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unusual ISO code and geo-location involved in the data transfer.
+- Analyze network logs to determine the volume and frequency of data transfers to the identified geo-location, comparing it against baseline traffic patterns.
+- Investigate the source IP addresses and devices involved in the data transfer to assess whether they are legitimate or potentially compromised.
+- Check for any recent changes or anomalies in user behavior or access patterns associated with the source devices or accounts.
+- Correlate the alert with other security events or logs, such as authentication logs or endpoint detection alerts, to identify any related suspicious activities.
+- Consult threat intelligence sources to determine if the unusual geo-location is associated with known malicious activities or threat actors.
+
+### False positive analysis
+
+- Legitimate business operations involving data transfers to new or infrequent geo-locations may trigger false positives. Users should review these activities and whitelist known safe destinations.
+- Regularly scheduled data backups or transfers to international offices or cloud services can be mistaken for exfiltration. Implement exceptions for these routine operations by updating the model's baseline.
+- Temporary projects or collaborations with partners in unusual regions might cause alerts. Document these activities and adjust the detection parameters to accommodate such temporary changes.
+- Changes in business operations, such as expansion into new markets, can alter normal traffic patterns. Update the model to reflect these changes to prevent unnecessary alerts.
+- Use historical data to identify patterns of benign traffic to unusual regions and adjust the model's sensitivity to reduce false positives while maintaining security vigilance.
+
+### Response and remediation
+
+- Immediately isolate the affected systems from the network to prevent further data exfiltration.
+- Conduct a thorough analysis of the network traffic logs to identify the source and destination of the unusual data transfer, focusing on the specific geo-location flagged by the alert.
+- Block the identified IP addresses or domains associated with the unusual ISO code in the organization's firewall and intrusion prevention systems.
+- Review and update access controls and permissions to ensure that only authorized personnel have access to sensitive data, reducing the risk of unauthorized data transfers.
+- Restore any compromised systems from clean backups, ensuring that all security patches and updates are applied before reconnecting to the network.
+- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data were affected.
+- Implement enhanced monitoring and alerting for similar anomalies in network traffic to improve early detection of potential exfiltration activities in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
index 350448b6a9b..a7001a580c4 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,40 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual IP Address
+
+Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical geo-locations. Adversaries exploit command and control channels to exfiltrate data to these unusual IP addresses. This detection rule leverages ML to flag deviations from normal traffic, indicating potential exfiltration activities, thus aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the alert details to identify the unusual IP address and geo-location involved in the potential exfiltration activity.
+- Cross-reference the identified IP address with threat intelligence databases to determine if it is associated with known malicious activities or threat actors.
+- Analyze historical network traffic logs to determine if there have been previous connections to the same IP address or geo-location, and assess the volume and frequency of these connections.
+- Investigate the source device or user account associated with the alert to identify any unauthorized access or suspicious behavior leading up to the alert.
+- Check for any recent changes in network configurations or security policies that might have inadvertently allowed the data transfer to the unusual IP address.
+- Collaborate with the IT team to isolate the affected systems, if necessary, and prevent further data exfiltration while the investigation is ongoing.
+
+### False positive analysis
+
+- Legitimate business operations involving data transfers to new or infrequent geo-locations may trigger false positives. Users should review these activities and, if deemed non-threatening, add exceptions for these IP addresses.
+- Regularly scheduled data backups or transfers to cloud services located in different regions can be misidentified as exfiltration. Users can whitelist these services to prevent unnecessary alerts.
+- Remote work scenarios where employees connect from various locations might cause false positives. Implementing a policy to recognize and exclude known employee IP addresses can mitigate this issue.
+- Partner or vendor data exchanges that occur outside typical patterns should be evaluated. If these are routine and secure, users can create exceptions for these specific IP addresses to reduce false alerts.
+
+### Response and remediation
+
+- Isolate the affected systems immediately to prevent further data exfiltration. Disconnect them from the network to stop any ongoing communication with the unusual IP address.
+- Conduct a thorough analysis of the affected systems to identify any malicious software or unauthorized access points. Remove any identified threats and patch vulnerabilities.
+- Change all credentials and access keys that may have been compromised during the exfiltration activity. Ensure that new credentials follow best practices for security.
+- Review and update firewall rules and network access controls to block the identified unusual IP address and similar suspicious IP ranges.
+- Monitor network traffic closely for any signs of continued exfiltration attempts or communication with command and control channels. Use enhanced logging and alerting to detect any anomalies.
+- Escalate the incident to the organization's cybersecurity response team and, if necessary, report the breach to relevant authorities or regulatory bodies as per compliance requirements.
+- Conduct a post-incident review to identify gaps in the current security posture and implement measures to prevent recurrence, such as improving network segmentation and enhancing threat detection capabilities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
index 119651afe53..00f61eea102 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -51,6 +51,41 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual Destination Port
+
+Machine learning models analyze network traffic to identify anomalies, such as data transfers to uncommon destination ports, which may suggest exfiltration via command and control channels. Adversaries exploit these channels to stealthily siphon data. This detection rule leverages ML to flag deviations from normal traffic patterns, aiding in early identification of potential threats.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the source IP address associated with the unusual destination port activity. Determine if this IP is known or expected within the organization's network.
+- Analyze the destination port and associated IP address to assess whether it is commonly used for legitimate purposes or if it is known for malicious activity. Cross-reference with threat intelligence databases if necessary.
+- Examine the volume and frequency of data transferred to the unusual destination port to identify any patterns or anomalies that deviate from normal behavior.
+- Investigate the user or system account associated with the source IP to determine if there are any signs of compromise or unauthorized access.
+- Check for any recent changes or updates in the network configuration or security policies that might explain the anomaly.
+- Correlate this event with other security alerts or logs to identify any related suspicious activities or patterns that could indicate a broader threat.
+
+### False positive analysis
+
+- Routine data transfers to external services using uncommon ports may trigger false positives. Identify and document these services to create exceptions in the monitoring system.
+- Internal applications that use non-standard ports for legitimate data transfers can be mistaken for exfiltration attempts. Regularly update the list of approved applications and their associated ports to minimize false alerts.
+- Scheduled data backups to cloud services or remote servers might use unusual ports. Verify these activities and configure the system to recognize them as non-threatening.
+- Development and testing environments often use non-standard ports for various operations. Ensure these environments are well-documented and excluded from exfiltration alerts when appropriate.
+- Collaborate with network administrators to maintain an updated inventory of all legitimate network activities and their corresponding ports, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat.
+- Conduct a thorough analysis of the network traffic logs to identify the scope of the exfiltration and determine if other systems are affected.
+- Block the identified unusual destination port at the network perimeter to prevent further unauthorized data transfers.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block similar exfiltration attempts in the future.
+- Notify the incident response team and relevant stakeholders about the potential data breach for further investigation and escalation.
+- Perform a comprehensive scan of the affected system for malware or unauthorized software that may have facilitated the exfiltration.
+- Implement enhanced monitoring on the affected system and network segment to detect any further suspicious activity."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
index b66d2fcbc9f..c801849735d 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Data Exfiltration Activity to an Unusual Region
+
+Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical regions. Adversaries exploit command and control channels to exfiltrate data to these regions, bypassing traditional security measures. This detection rule leverages ML to flag unusual geo-locations, indicating potential exfiltration activities, thus aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the geo-location details flagged by the alert to determine if the region is indeed unusual for the organization's typical network traffic patterns.
+- Analyze the network traffic logs associated with the alert to identify the volume and type of data being transferred to the unusual region.
+- Cross-reference the IP addresses involved in the data transfer with threat intelligence databases to check for any known malicious activity or associations.
+- Investigate the user accounts and devices involved in the data transfer to assess if they have been compromised or are exhibiting other suspicious behaviors.
+- Check for any recent changes in network configurations or security policies that might have inadvertently allowed data transfers to atypical regions.
+- Collaborate with the organization's IT and security teams to verify if there are legitimate business reasons for the data transfer to the flagged region.
+
+### False positive analysis
+
+- Legitimate business operations involving data transfers to new or infrequent regions may trigger false positives. Users should review and whitelist these regions if they are part of regular business activities.
+- Scheduled data backups or transfers to cloud services located in atypical regions can be mistaken for exfiltration. Identify and exclude these services from the rule's scope.
+- Remote work scenarios where employees connect from different regions might cause alerts. Maintain an updated list of remote work locations to prevent unnecessary alerts.
+- Partner or vendor data exchanges that occur outside usual geographic patterns should be documented and excluded if they are verified as non-threatening.
+- Temporary projects or collaborations with international teams may result in unusual data flows. Ensure these are accounted for in the rule's configuration to avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected systems immediately to prevent further data exfiltration. Disconnect them from the network to stop ongoing communication with the unusual geo-location.
+- Conduct a thorough analysis of the network traffic logs to identify the scope of the exfiltration and determine which data was accessed or transferred.
+- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent unauthorized access.
+- Implement geo-blocking measures to restrict data transfers to the identified unusual region, ensuring that only approved regions can communicate with the network.
+- Review and update firewall and intrusion detection system (IDS) rules to detect and block similar command and control traffic patterns in the future.
+- Escalate the incident to the security operations center (SOC) and relevant stakeholders, providing them with detailed findings and actions taken for further investigation and response.
+- Conduct a post-incident review to assess the effectiveness of the response and identify any gaps in the security posture, implementing necessary improvements to prevent recurrence."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
index 39917340b0a..36b9d7ff333 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -51,6 +51,41 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Bytes Sent to an External Device
+
+The detection rule leverages machine learning to identify anomalies in data transfer patterns to external devices, which typically follow predictable trends. Adversaries may exploit this by transferring large volumes of data to external media for exfiltration. The rule detects deviations from normal behavior, flagging potential illicit data transfers for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific external device involved and the volume of data transferred.
+- Correlate the time of the anomaly with user activity logs to determine if the data transfer aligns with any known or authorized user actions.
+- Check historical data transfer patterns for the involved device to assess whether the detected spike is truly anomalous or part of a legitimate operational change.
+- Investigate the user account associated with the data transfer for any signs of compromise or unusual behavior, such as recent password changes or failed login attempts.
+- Examine the content and type of data transferred, if possible, to assess the sensitivity and potential impact of the data exfiltration.
+- Cross-reference the device and user activity with other security alerts or incidents to identify any related suspicious activities or patterns.
+
+### False positive analysis
+
+- Regular backups to external devices can trigger false positives. Users should identify and exclude backup operations from the rule's scope by specifying known backup software or devices.
+- Software updates or installations that involve large data transfers to external media may be misclassified. Users can create exceptions for these activities by defining specific update processes or installation paths.
+- Data archiving processes that periodically transfer large volumes of data to external storage can be mistaken for exfiltration. Users should whitelist these scheduled archiving tasks by recognizing the associated patterns or schedules.
+- Media content creation or editing, such as video production, often involves significant data transfers. Users can exclude these activities by identifying and excluding the relevant applications or file types.
+- Temporary data transfers for legitimate business purposes, like transferring project files to a client, can be flagged. Users should document and exclude these known business processes by specifying the involved devices or file types.
+
+### Response and remediation
+
+- Immediately isolate the affected device from the network to prevent further data exfiltration.
+- Conduct a forensic analysis of the device to identify the source and scope of the data transfer, focusing on the files transferred and any associated processes or applications.
+- Review and revoke any unnecessary permissions or access rights that may have facilitated the data transfer to the external device.
+- Notify the security operations center (SOC) and relevant stakeholders about the incident for awareness and potential escalation.
+- Implement additional monitoring on similar devices and network segments to detect any further anomalous data transfer activities.
+- Update and enforce data transfer policies to restrict unauthorized use of external devices, ensuring compliance with organizational security standards.
+- Consider deploying endpoint detection and response (EDR) solutions to enhance visibility and control over data movements to external devices."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
index 9236fbdd189..242528144a1 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Bytes Sent to an External Device via Airdrop
+
+Airdrop facilitates seamless file sharing between Apple devices, leveraging Bluetooth and Wi-Fi. While convenient, adversaries can exploit it for unauthorized data exfiltration by transferring large volumes of sensitive data. The detection rule employs machine learning to identify anomalies in data transfer patterns, flagging unusual spikes in bytes sent as potential exfiltration attempts, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific device and user involved in the data transfer. Check for any known associations with previous incidents or suspicious activities.
+- Analyze the volume of data transferred and compare it to typical usage patterns for the device and user. Determine if the spike is significantly higher than usual.
+- Investigate the time and context of the data transfer. Correlate with other logs or alerts to identify any concurrent suspicious activities or anomalies.
+- Check the destination device's details to verify if it is a recognized and authorized device within the organization. Investigate any unknown or unauthorized devices.
+- Contact the user associated with the alert to verify the legitimacy of the data transfer. Gather information on the nature of the files transferred and the purpose of the transfer.
+- Review any recent changes in the user's access privileges or roles that might explain the increased data transfer activity.
+
+### False positive analysis
+
+- Regular large file transfers for legitimate business purposes, such as media companies transferring video files, can trigger false positives. Users can create exceptions for specific devices or user accounts known to perform these tasks regularly.
+- Software updates or backups that involve transferring large amounts of data to external devices may be misidentified as exfiltration attempts. Users should whitelist these activities by identifying the associated processes or applications.
+- Educational institutions or creative teams often share large files for collaborative projects. Establishing a baseline for expected data transfer volumes and excluding these from alerts can reduce false positives.
+- Devices used for testing or development purposes might frequently send large data volumes. Users can exclude these devices from monitoring by adding them to an exception list.
+- Personal use of Airdrop for transferring large media files, such as photos or videos, can be mistaken for suspicious activity. Users can mitigate this by setting thresholds that account for typical personal use patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected device from the network to prevent further data exfiltration.
+- Verify the identity and permissions of the user associated with the anomalous Airdrop activity to ensure they are authorized to transfer data.
+- Conduct a forensic analysis of the device to identify any unauthorized applications or processes that may have facilitated the data transfer.
+- Review and revoke any unnecessary permissions or access rights for the user or device involved in the incident.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the activity is part of a larger threat campaign.
+- Implement additional monitoring on the affected device and similar devices to detect any further anomalous Airdrop activities.
+- Update security policies and controls to restrict Airdrop usage to only trusted devices and networks, reducing the risk of future unauthorized data transfers."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
index ea9d9ea5633..c57048c344a 100644
--- a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -51,6 +51,41 @@ tags = [
     "Tactic: Exfiltration",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process Writing Data to an External Device
+
+In modern environments, processes may write data to external devices for legitimate reasons, such as backups or data transfers. However, adversaries can exploit this by using seemingly harmless processes to exfiltrate sensitive data. The detection rule leverages machine learning to identify rare processes engaging in such activities, flagging potential exfiltration attempts by analyzing deviations from typical behavior patterns.
+
+### Possible investigation steps
+
+- Review the process name and path to determine if it is commonly associated with legitimate activities or known software.
+- Check the user account associated with the process to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Analyze the external device's details, such as its type and connection history, to assess if it is a recognized and authorized device within the organization.
+- Investigate the volume and type of data being written to the external device to identify any sensitive or unusual data transfers.
+- Correlate the process activity with other security events or logs to identify any concurrent suspicious activities or anomalies.
+- Consult with the user or department associated with the process to confirm if the data transfer was authorized and necessary.
+
+### False positive analysis
+
+- Backup processes may trigger alerts when writing data to external devices. Users should identify and whitelist legitimate backup applications to prevent false positives.
+- Data transfer applications used for legitimate business purposes can be flagged. Regularly review and approve these applications to ensure they are not mistakenly identified as threats.
+- Software updates or installations that involve writing data to external devices might be detected. Establish a list of known update processes and exclude them from triggering alerts.
+- IT maintenance activities, such as system diagnostics or hardware testing, can cause false positives. Document and exclude these routine processes to avoid unnecessary alerts.
+- User-initiated file transfers for legitimate reasons, such as moving large datasets for analysis, should be monitored and approved to prevent misclassification.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat.
+- Identify and terminate the suspicious process writing data to the external device to stop any ongoing exfiltration activities.
+- Conduct a forensic analysis of the affected system to determine the scope of the data exfiltration, including what data was accessed or transferred.
+- Review and revoke any compromised credentials or access permissions associated with the affected process to prevent unauthorized access.
+- 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 additional monitoring on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities.
+- Update security policies and controls to prevent similar exfiltration attempts, such as restricting process permissions to write to external devices and enhancing endpoint protection measures."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
index 8fd4b2d3054..d7c944dca7e 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,41 @@ type = "query"
 query = '''
 ml_is_dga.malicious_prediction:1 and dns.question.registered_domain:avsvmcloud.com
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Machine Learning Detected DGA activity using a known SUNBURST DNS domain
+
+Domain Generation Algorithms (DGAs) are used by adversaries to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. The SUNBURST malware utilized such techniques. The detection rule leverages machine learning to identify DNS queries linked to these generated domains, specifically targeting those associated with SUNBURST, by analyzing patterns and predicting malicious activity, thus aiding in early threat detection and mitigation.
+
+### Possible investigation steps
+
+- Review the DNS logs to identify the source IP address associated with the DNS query for avsvmcloud.com to determine the affected host within the network.
+- Check historical DNS query logs for the identified host to see if there are additional queries to other suspicious or known malicious domains, indicating further compromise.
+- Investigate the network traffic from the identified host around the time of the alert to detect any unusual patterns or connections to external IP addresses that may suggest command and control activity.
+- Examine endpoint security logs and alerts for the affected host to identify any signs of SUNBURST malware or other related malicious activity.
+- Correlate the alert with other security events in the environment to determine if there are any related incidents or patterns that could indicate a broader attack campaign.
+- Assess the risk and impact of the detected activity on the organization and determine if immediate containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Legitimate software updates or network services may occasionally use domain generation algorithms for load balancing or redundancy, leading to false positives. Users should monitor and whitelist these known benign services.
+- Internal testing environments or security tools that simulate DGA behavior for research or training purposes might trigger alerts. Exclude these environments by adding them to an exception list.
+- Some cloud services might use dynamic DNS techniques that resemble DGA patterns. Identify and document these services, then configure exceptions to prevent unnecessary alerts.
+- Frequent legitimate access to avsvmcloud.com by security researchers or analysts could be misclassified. Ensure these activities are logged and reviewed, and create exceptions for known research IPs or user accounts.
+- Regularly review and update the exception list to ensure it reflects current network behavior and does not inadvertently allow new threats.
+
+### Response and remediation
+
+- Isolate the affected systems immediately to prevent further communication with the malicious domain avsvmcloud.com and halt potential data exfiltration or lateral movement.
+- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove any SUNBURST malware or related malicious files.
+- Review and block any outbound traffic to the domain avsvmcloud.com at the network perimeter to prevent future connections from other potentially compromised systems.
+- Analyze network logs and DNS query records to identify any other systems that may have communicated with the domain, and apply the same isolation and scanning procedures to those systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the compromise.
+- Implement enhanced monitoring and alerting for any DNS queries or network traffic patterns indicative of DGA activity, particularly those resembling SUNBURST characteristics, to detect and respond to similar threats promptly.
+- Review and update incident response and recovery plans to incorporate lessons learned from this incident, ensuring faster and more effective responses to future threats."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
index 5f43ccebc1a..08eaf51c9bf 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -60,6 +60,39 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential DGA Activity
+Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. Adversaries exploit this by frequently changing domains to evade detection. The 'Potential DGA Activity' detection rule leverages machine learning to analyze DNS requests from source IPs, identifying patterns indicative of DGA usage, thus flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address identified in the alert to determine if it belongs to a known or trusted entity within the organization.
+- Analyze the DNS request patterns from the source IP to identify any unusual or suspicious domain names that may indicate DGA activity.
+- Cross-reference the flagged domains with threat intelligence feeds to check for known malicious domains or patterns associated with DGAs.
+- Investigate the network traffic associated with the source IP to identify any additional indicators of compromise or communication with known malicious IPs.
+- Check for any recent changes or anomalies in the system or network configurations that could explain the detected activity.
+- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response efforts.
+
+### False positive analysis
+
+- Legitimate software updates or cloud services may generate high volumes of DNS requests that resemble DGA patterns. Users can create exceptions for known update servers or cloud service domains to reduce false positives.
+- Content delivery networks (CDNs) often use dynamically generated subdomains for load balancing and distribution, which can trigger DGA alerts. Identifying and excluding these CDN domains from analysis can help mitigate false positives.
+- Large organizations with complex internal networks might have internal applications that generate DNS requests similar to DGA activity. Conducting a thorough review of internal DNS traffic and whitelisting known internal domains can prevent these false positives.
+- Some security tools or network appliances may perform DNS lookups as part of their normal operation, which could be misclassified as DGA activity. Identifying these tools and excluding their IP addresses from the analysis can help manage false positives.
+
+### Response and remediation
+
+- Isolate the affected systems: Immediately disconnect any systems identified as making suspicious DNS requests from the network to prevent further communication with potential C2 servers.
+- Block identified domains: Use firewall and DNS filtering solutions to block the domains flagged by the detection rule, preventing any further communication attempts.
+- Conduct a thorough system scan: Use updated antivirus and anti-malware tools to scan the isolated systems for any signs of infection or malicious software.
+- Analyze network traffic: Review network logs to identify any additional suspicious activity or other systems that may be affected, focusing on unusual DNS requests and connections.
+- Patch and update systems: Ensure all systems, especially those identified in the alert, are fully patched and updated to mitigate vulnerabilities that could be exploited by malware.
+- Restore from backups: If malware is confirmed, restore affected systems from clean backups to ensure no remnants of the infection remain.
+- Escalate to incident response team: If the threat is confirmed and widespread, escalate the incident to the organization's incident response team for further investigation and coordinated response efforts."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
index c144bd2ddb0..48a8202ef98 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,40 @@ type = "query"
 query = '''
 ml_is_dga.malicious_probability > 0.98
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Machine Learning Detected a DNS Request With a High DGA Probability Score
+
+Machine learning models analyze DNS requests to identify patterns indicative of Domain Generation Algorithms (DGAs), often used by attackers to establish command and control channels. These algorithms generate numerous domain names, making detection challenging. The detection rule leverages a model to flag DNS queries with high DGA probability, aiding in identifying potential malicious activity.
+
+### Possible investigation steps
+
+- Review the DNS query logs to identify the specific domain name associated with the high DGA probability score and gather additional context about the request, such as the timestamp and the source IP address.
+- Cross-reference the identified domain name with threat intelligence databases to determine if it is a known malicious domain or associated with any known threat actors or campaigns.
+- Investigate the source IP address to determine if it belongs to a legitimate user or system within the network, and check for any unusual or suspicious activity associated with this IP address.
+- Analyze network traffic logs to identify any additional communication attempts to the flagged domain or other suspicious domains, which may indicate further command and control activity.
+- Check endpoint security logs for any signs of compromise or suspicious behavior on the device that initiated the DNS request, such as unexpected processes or connections.
+- Consider isolating the affected system from the network if there is strong evidence of compromise, to prevent further potential malicious activity while conducting a deeper forensic analysis.
+
+### False positive analysis
+
+- Legitimate software updates or services may use domain generation techniques for load balancing or redundancy, leading to false positives. Users can create exceptions for known update services or trusted software to reduce these alerts.
+- Content delivery networks (CDNs) often use dynamically generated domains to optimize content delivery, which might be flagged. Identifying and whitelisting these CDN domains can help minimize unnecessary alerts.
+- Some security tools and applications use DGA-like patterns for legitimate purposes, such as generating unique identifiers. Users should verify the source and purpose of these requests and consider excluding them if they are confirmed to be non-threatening.
+- Internal testing environments or development tools might generate domains that resemble DGA activity. Users can exclude these environments from monitoring or adjust the rule to ignore specific internal IP ranges or domain patterns.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further potential command and control communication.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and block the identified suspicious domain names at the network perimeter to prevent any further communication attempts.
+- Analyze network traffic logs to identify any other systems that may have communicated with the flagged domains and apply similar containment measures.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring on the affected system and network segment to detect any signs of persistence or further malicious activity.
+- Update and reinforce endpoint protection measures, ensuring all systems have the latest security patches and configurations to prevent similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
index 9bdf80ef78a..bc817ee6848 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,41 @@ type = "query"
 query = '''
 ml_is_dga.malicious_prediction:1 and not dns.question.registered_domain:avsvmcloud.com
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Machine Learning Detected a DNS Request Predicted to be a DGA Domain
+
+Machine learning models can identify patterns in DNS requests that suggest the use of Domain Generation Algorithms (DGAs), which adversaries use to dynamically generate domain names for command and control (C2) communication. This detection rule leverages such models to flag DNS queries likely generated by DGAs, excluding known benign domains, thus helping to identify potential C2 activity.
+
+### Possible investigation steps
+
+- Review the DNS query logs to identify the specific domain flagged by the machine learning model as a potential DGA domain. Focus on the field ml_is_dga.malicious_prediction:1 to confirm the prediction.
+- Cross-reference the flagged domain with threat intelligence sources to determine if it is associated with known malicious activity or threat actors.
+- Investigate the source IP address of the DNS request to identify the device or user responsible for the query. This can help determine if the activity is isolated or part of a larger pattern.
+- Analyze network traffic logs for any additional suspicious activity originating from the same source IP, such as unusual outbound connections or data transfers.
+- Check for any recent changes or anomalies in the endpoint's behavior or configuration that could indicate compromise or unauthorized software installation.
+- If the domain is confirmed to be malicious, initiate containment procedures to block further communication with the domain and prevent potential data exfiltration or further compromise.
+
+### False positive analysis
+
+- DNS requests to content delivery networks or cloud service providers can be flagged as DGA domains due to their dynamic nature. Users should review these domains and consider adding them to an exception list if they are verified as legitimate.
+- Internal applications that generate dynamic DNS requests for load balancing or failover purposes might trigger false positives. Identify these applications and exclude their domains from the rule to prevent unnecessary alerts.
+- Automated testing environments often generate numerous DNS requests that can appear suspicious. Regularly update the exception list with domains used by these environments to minimize false alerts.
+- Frequent updates or patches from software vendors may involve dynamic DNS requests. Verify these domains and exclude them if they are confirmed to be part of legitimate update processes.
+- Consider monitoring the frequency and pattern of flagged DNS requests. If a domain is consistently flagged but verified as non-threatening, it may be a candidate for exclusion from the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further potential command and control communication.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and block the identified DGA domain and any associated IP addresses at the network perimeter to prevent further access.
+- Analyze network traffic logs to identify any other systems that may have communicated with the DGA domain and apply similar containment measures.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.
+- Implement enhanced monitoring for similar DGA patterns and update detection capabilities to quickly identify future occurrences.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known DGA patterns and suspicious DNS activity."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/endpoint/elastic_endpoint_security.toml b/rules/integrations/endpoint/elastic_endpoint_security.toml
index 37be3ddc9b9..5a00cedc190 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "New fields added: required_fields, related_integrations, setup"
 min_stack_version = "8.3.0"
 promotion = true
-updated_date = "2024/11/27"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,41 @@ type = "query"
 query = '''
 event.kind:alert and event.module:(endpoint and not endgame)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Endpoint Security (Elastic Defend)
+
+Elastic Defend is a robust endpoint security solution that monitors and protects systems by analyzing events and generating alerts for suspicious activities. Adversaries may exploit endpoints by executing unauthorized code or manipulating system processes. The detection rule leverages event data to identify alerts from Elastic Defend, focusing on potential threats while excluding non-relevant modules, thus enabling timely investigation of endpoint anomalies.
+
+### Possible investigation steps
+
+- Review the alert details to understand the specific event.kind:alert and event.module: endpoint that triggered the alert, ensuring it is not related to the excluded endgame module.
+- Examine the timeline of events leading up to the alert to identify any unusual or unauthorized activities, such as unexpected process executions or system changes.
+- Correlate the alert with other security events or logs from the same endpoint to gather additional context and determine if there is a pattern of suspicious behavior.
+- Investigate the source and destination of any network connections associated with the alert to identify potential command and control activity or data exfiltration attempts.
+- Check for any recent changes or updates to the endpoint's software or configuration that could explain the alert, ensuring they are legitimate and authorized.
+- Assess the risk score and severity of the alert in conjunction with other alerts from the same endpoint to prioritize the investigation and response efforts.
+
+### False positive analysis
+
+- Alerts triggered by routine software updates can be false positives. Users can create exceptions for known update processes to prevent unnecessary alerts.
+- System maintenance activities, such as scheduled scans or backups, may generate alerts. Exclude these activities by identifying their specific event signatures and adding them to the exception list.
+- Legitimate administrative actions, like remote desktop sessions or script executions by IT staff, might be flagged. Define exceptions for these actions by correlating them with authorized user accounts or IP addresses.
+- Frequent alerts from non-malicious applications that interact with system processes can be excluded by whitelisting these applications based on their hash or path.
+- Network monitoring tools that simulate attack patterns for testing purposes may trigger alerts. Exclude these tools by specifying their known behaviors and IP ranges in the exception settings.
+
+### Response and remediation
+
+- Isolate the affected endpoint immediately to prevent further unauthorized access or lateral movement within the network.
+- Analyze the alert details to identify the specific unauthorized code or process manipulation involved, and terminate any malicious processes identified.
+- Remove any unauthorized code or files from the affected endpoint, ensuring that all traces of the threat are eradicated.
+- Conduct a thorough review of system logs and event data to identify any additional indicators of compromise or related suspicious activities.
+- Update endpoint security configurations and signatures to prevent similar threats from exploiting the same vulnerabilities in the future.
+- Restore the affected endpoint from a known good backup if necessary, ensuring that the system is free from any residual threats.
+- Escalate the incident to the security operations center (SOC) or relevant team for further analysis and to determine if additional systems may be affected."""
 
 
 [[rule.exceptions_list]]
diff --git a/rules/integrations/fim/persistence_suspicious_file_modifications.toml b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
index 3d4d2b5e806..931cfa939bd 100644
--- a/rules/integrations/fim/persistence_suspicious_file_modifications.toml
+++ b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["fim"]
 maturity = "production"
-updated_date = "2024/12/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -133,6 +133,41 @@ file.path : (
   file.extension in ("dpkg-new", "dpkg-remove", "SEQ")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Persistence via File Modification
+
+File Integrity Monitoring (FIM) is crucial for detecting unauthorized changes to critical files, often targeted by adversaries for persistence. Attackers may modify cron jobs, systemd services, or shell configurations to maintain access or escalate privileges. The detection rule monitors these files for updates, flagging potential persistence attempts by identifying suspicious modifications outside normal operations.
+
+### Possible investigation steps
+
+- Review the file path from the alert to determine which specific file was modified and assess its role in the system, focusing on paths commonly used for persistence such as cron jobs, systemd services, or shell configurations.
+- Check the timestamp of the modification event to correlate it with any known legitimate changes or scheduled maintenance activities, ensuring the modification was not part of normal operations.
+- Investigate the user or process responsible for the modification by examining the associated user ID or process ID, and verify if the user or process has legitimate reasons to alter the file.
+- Analyze recent login and session activity for the user or process involved in the modification to identify any unusual patterns or unauthorized access attempts.
+- Cross-reference the modification event with other security logs or alerts to identify any related suspicious activities, such as privilege escalation attempts or unauthorized access to sensitive files.
+- If the modified file is a configuration file, review its contents for any unauthorized or suspicious entries that could indicate persistence mechanisms, such as new cron jobs or altered systemd service configurations.
+
+### False positive analysis
+
+- Routine system updates or package installations may modify files monitored by the rule, such as those in /etc/cron.d or /etc/systemd/system. To manage these, consider excluding specific file paths or extensions like dpkg-new and dpkg-remove during known maintenance windows.
+- User-specific configuration changes, such as updates to shell profiles in /home/*/.bashrc, can trigger alerts. Implement exceptions for user directories where frequent legitimate changes occur, ensuring these are well-documented and reviewed regularly.
+- Automated scripts or management tools that update system configurations, like /etc/ssh/sshd_config, can cause false positives. Identify these tools and create exceptions for their expected file modification patterns.
+- Temporary files created during system operations, such as /var/spool/cron/crontabs/tmp.*, may be flagged. Exclude these temporary paths to reduce noise while maintaining security oversight.
+- Regular updates to known_hosts files in /home/*/.ssh/known_hosts can be mistaken for suspicious activity. Exclude these files from monitoring to prevent unnecessary alerts while ensuring SSH configurations are still monitored.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Review the specific file modifications flagged by the alert to determine if they are unauthorized or malicious. Restore any altered files to their last known good state using backups or system snapshots.
+- Change all passwords and SSH keys associated with the affected system to prevent unauthorized access using compromised credentials.
+- Conduct a thorough scan of the system for additional indicators of compromise, such as unauthorized user accounts or unexpected running processes, and remove any malicious artifacts found.
+- 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 on the affected system and similar systems to detect any further unauthorized file modifications or suspicious activities.
+- Review and update access controls and permissions on critical files and directories to minimize the risk of unauthorized modifications in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
index 3d33d2ee993..ce3f2e6a451 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,41 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Subscription Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Pub/Sub Subscription Creation
+
+Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between applications by decoupling event producers and consumers. Adversaries might exploit this by creating unauthorized subscriptions to intercept or exfiltrate sensitive data streams. The detection rule monitors audit logs for successful subscription creation events, helping identify potential misuse by flagging unexpected or suspicious activity.
+
+### Possible investigation steps
+
+- Review the audit log entry associated with the alert to identify the user or service account responsible for the subscription creation by examining the `event.dataset` and `event.action` fields.
+- Verify the legitimacy of the subscription by checking the associated project and topic details to ensure they align with expected configurations and business needs.
+- Investigate the history of the user or service account involved in the subscription creation to identify any unusual or unauthorized activities, focusing on recent changes or access patterns.
+- Assess the permissions and roles assigned to the user or service account to determine if they have the necessary privileges for subscription creation and whether these permissions are appropriate.
+- Consult with relevant stakeholders or application owners to confirm whether the subscription creation was authorized and necessary for operational purposes.
+
+### False positive analysis
+
+- Routine subscription creation by automated deployment tools or scripts can trigger false positives. Identify and whitelist these tools by excluding their service accounts from the detection rule.
+- Development and testing environments often create and delete subscriptions frequently. Exclude these environments by filtering out specific project IDs associated with non-production use.
+- Scheduled maintenance or updates might involve creating new subscriptions temporarily. Coordinate with the operations team to understand regular maintenance schedules and adjust the rule to ignore these activities during known maintenance windows.
+- Internal monitoring or logging services that create subscriptions for legitimate data collection purposes can be excluded by identifying their specific patterns or naming conventions and adding them to an exception list.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the unauthorized subscription creation and identify the source, including the user or service account responsible for the action.
+- Revoke access for the identified user or service account to prevent further unauthorized actions. Ensure that the principle of least privilege is enforced.
+- Delete the unauthorized subscription to stop any potential data interception or exfiltration.
+- Conduct a thorough review of all existing subscriptions to ensure no other unauthorized subscriptions exist.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for subscription creation events to detect similar activities in the future.
+- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any broader implications or vulnerabilities.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
index 701fd52c77f..49aebb40751 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Topic Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Pub/Sub Topic Creation
+
+Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between independent applications. It uses topics to route messages from publishers to subscribers. Adversaries might exploit this by creating unauthorized topics to exfiltrate data or disrupt services. The detection rule monitors successful topic creation events, helping identify potential misuse by flagging unexpected or suspicious activity.
+
+### Possible investigation steps
+
+- Review the event details to confirm the presence of the event.action field with the value google.pubsub.v*.Publisher.CreateTopic and ensure the event.outcome is success.
+- Identify the user or service account associated with the topic creation by examining the actor information in the event logs.
+- Check the project and resource details to determine the context and environment where the topic was created, including the project ID and resource name.
+- Investigate the purpose and necessity of the newly created topic by consulting with relevant stakeholders or reviewing documentation related to the project.
+- Analyze historical logs to identify any unusual patterns or anomalies in topic creation activities by the same user or within the same project.
+- Assess the permissions and roles assigned to the user or service account to ensure they align with the principle of least privilege.
+- If suspicious activity is confirmed, consider implementing additional monitoring or access controls to prevent unauthorized topic creation in the future.
+
+### False positive analysis
+
+- Routine topic creation by automated processes or scripts can trigger false positives. Identify and document these processes to create exceptions in the monitoring system.
+- Development and testing environments often involve frequent topic creation. Exclude these environments from alerts by using environment-specific tags or labels.
+- Scheduled maintenance or updates by cloud administrators may result in legitimate topic creation. Coordinate with the operations team to whitelist these activities during known maintenance windows.
+- Third-party integrations or services that rely on Pub/Sub for communication might create topics as part of their normal operation. Review and approve these integrations to prevent unnecessary alerts.
+- Internal applications with dynamic topic creation as part of their workflow should be assessed and, if deemed non-threatening, added to an exception list to reduce noise.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the unauthorized creation of the Pub/Sub topic and identify the user or service account responsible for the action.
+- Revoke or limit permissions for the identified user or service account to prevent further unauthorized actions, ensuring that only necessary permissions are granted.
+- Delete the unauthorized Pub/Sub topic to prevent any potential data exfiltration or disruption of services.
+- Conduct a thorough review of other Pub/Sub topics and related resources to ensure no additional unauthorized topics have been created.
+- Notify the security team and relevant stakeholders about the incident for further investigation and to assess potential impacts on the organization.
+- Implement additional monitoring and alerting for Pub/Sub topic creation events to detect and respond to similar threats more quickly in the future.
+- Consider enabling organization-wide policies that restrict who can create Pub/Sub topics to reduce the risk of unauthorized actions.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/admin"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
index bf65a769bb5..8441afaca40 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Firewall Rule Creation
+
+In GCP, firewall rules manage network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may exploit this by creating rules that permit unauthorized access, bypassing security measures. The detection rule monitors audit logs for specific actions indicating new rule creation, flagging potential defense evasion attempts to ensure timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:gcp.audit entries to identify the source of the firewall rule creation, focusing on the event.action fields: *.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule.
+- Identify the user or service account responsible for the action by examining the actor information in the audit logs, such as the principalEmail field.
+- Determine the network or application affected by the new firewall rule by analyzing the target resources, such as the VPC or App Engine application, to understand the potential impact.
+- Assess the rule's configuration details, including the allowed or denied IP ranges, protocols, and ports, to evaluate if it introduces any security risks or deviates from established security policies.
+- Check for any recent changes in permissions or roles assigned to the user or service account involved, which might indicate privilege escalation or misuse.
+- Correlate the firewall rule creation event with other security events or alerts in the same timeframe to identify any suspicious patterns or activities that might suggest a coordinated attack.
+- Consult with relevant stakeholders or teams to verify if the firewall rule creation was authorized and aligns with current operational requirements or projects.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel can trigger alerts when they create or update firewall rules for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these actions and create exceptions for them in the detection rule.
+- Automated processes or scripts that regularly update firewall configurations as part of normal operations may also cause false positives. Identify these processes and adjust the rule to exclude their specific actions or service accounts.
+- Changes made during scheduled maintenance windows might be flagged as suspicious. Implement time-based exceptions to ignore rule creation events during these predefined periods.
+- Integration with third-party security tools or services that modify firewall rules for enhanced protection can be mistaken for unauthorized activity. Verify these integrations and whitelist their actions to prevent unnecessary alerts.
+- Development and testing environments often require frequent firewall rule changes, which can lead to false positives. Differentiate these environments from production by tagging them appropriately and excluding their events from the detection rule.
+
+### Response and remediation
+
+- Immediately review the newly created firewall rule to determine its source and intent. Verify if the rule aligns with organizational security policies and intended network configurations.
+- Temporarily disable or delete the suspicious firewall rule to prevent unauthorized access while further investigation is conducted.
+- Conduct a thorough audit of recent firewall rule changes in the affected GCP project to identify any other unauthorized modifications.
+- Isolate affected systems or applications that may have been exposed due to the unauthorized firewall rule to prevent further exploitation.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further action.
+- Implement additional monitoring on the affected VPC or App Engine environment to detect any further unauthorized changes or suspicious activities.
+- Review and update access controls and permissions for creating and modifying firewall rules to ensure only authorized personnel have the necessary privileges.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
index 2bd5d930541..71669e06d5d 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Firewall Rule Deletion
+
+In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors audit logs for deletion actions, flagging potential defense evasion attempts by identifying specific deletion events in VPC or App Engine environments.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:gcp.audit to confirm the deletion action and gather details such as the timestamp, user identity, and source IP address associated with the event.
+- Investigate the event.action field to determine whether the deletion occurred in the VPC or App Engine environment, and identify the specific firewall rule that was deleted.
+- Check the user or service account activity around the time of the deletion to identify any suspicious behavior or unauthorized access attempts.
+- Assess the impact of the deleted firewall rule by reviewing the network traffic patterns and security posture before and after the deletion.
+- Collaborate with the network security team to determine if the deletion was part of a legitimate change management process or if it indicates a potential security incident.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may trigger firewall rule deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for infrastructure management might delete and recreate firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service accounts or tags associated with these tools.
+- Changes in application deployment processes, especially in environments like App Engine, can lead to legitimate firewall rule deletions. Review deployment logs and processes to identify patterns and exclude these from alerts.
+- Organizational policy changes that involve restructuring network security may result in bulk deletions of firewall rules. Coordinate with network security teams to understand planned changes and temporarily adjust detection rules during these periods.
+- Test environments often have dynamic configurations where firewall rules are frequently added and removed. Exclude specific projects or environments designated for testing from the detection rule to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate affected VM instances or applications by applying restrictive firewall rules to prevent further unauthorized access or data exfiltration.
+- Review audit logs to identify the source of the deletion action, including user accounts and IP addresses involved, and verify if the action was authorized.
+- Recreate the deleted firewall rules based on the last known good configuration to restore security controls and prevent unauthorized access.
+- Conduct a security review of the affected environment to identify any additional unauthorized changes or indicators of compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
+- Implement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future.
+- Review and update access controls and permissions for users and service accounts to ensure that only authorized personnel can modify firewall rules.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
index ae5126fc5fb..24f35e7261f 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Firewall Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Firewall Rule Modification
+
+In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential defense evasion attempts by flagging suspicious changes in network configurations.
+
+### Possible investigation steps
+
+- Review the audit logs for entries with the event.dataset field set to gcp.audit to confirm the source of the alert.
+- Examine the event.action field for values such as *.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule to identify the specific type of firewall rule modification.
+- Identify the user or service account responsible for the modification by checking the actor information in the audit logs.
+- Assess the changes made to the firewall rule, including the before and after states, to determine if the modification allows more permissive ingress or egress traffic.
+- Investigate the context of the modification by reviewing related activities in the audit logs around the same time to identify any suspicious patterns or sequences of actions.
+- Check for any recent security incidents or alerts involving the affected VPC or App Engine application to understand potential motives or impacts of the rule change.
+- If unauthorized or suspicious activity is confirmed, initiate incident response procedures to mitigate any potential security risks.
+
+### False positive analysis
+
+- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known IP addresses or user accounts that regularly perform these tasks.
+- Automated scripts or tools used for infrastructure management might modify firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
+- Changes made during scheduled maintenance windows can be considered non-threatening. Implement time-based exceptions to ignore modifications during these periods.
+- Modifications related to scaling operations in App Engine or VPCs might be legitimate. Review and whitelist specific actions associated with scaling events to prevent unnecessary alerts.
+- Regular audits or compliance checks might involve temporary rule changes. Document these activities and exclude them from detection by correlating with audit logs or change management records.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC or App Engine application by applying a restrictive firewall rule to prevent further unauthorized access or data exfiltration.
+- Review the audit logs to identify the source of the modification, including user accounts and IP addresses involved, and revoke any suspicious credentials or access.
+- Restore the firewall rule to its previous secure state using backup configurations or documented baselines to ensure the network is protected.
+- Conduct a thorough security assessment of the affected environment to identify any additional unauthorized changes or indicators of compromise.
+- Notify the security operations team and relevant stakeholders about the incident, providing details of the modification and actions taken.
+- Implement enhanced monitoring and alerting for future firewall rule changes to detect and respond to similar threats more quickly.
+- Consider engaging with Google Cloud support or a third-party security expert if the incident scope is beyond internal capabilities or if further expertise is required.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
index a9e9ba23557..65a080279fb 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Bucket Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Logging Bucket Deletion
+
+In GCP, log buckets are essential for storing and organizing log data, crucial for monitoring and auditing activities. Adversaries may delete these buckets to obscure their tracks and evade detection. The detection rule identifies successful deletion events by monitoring specific audit logs, focusing on actions that indicate bucket removal. This helps security analysts quickly spot and respond to potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteBucket to confirm the deletion event and gather details such as the timestamp, user identity, and source IP address.
+- Investigate the user account associated with the event to determine if the action was authorized or if there are any signs of compromise, such as unusual login locations or times.
+- Check for any recent changes to log sinks that might indicate an attempt to stop log routing to the deleted bucket, which could suggest intentional evasion.
+- Assess the impact of the bucket deletion by identifying which logs were being routed to the bucket and determining if any critical log data might be lost or compromised.
+- Look for any correlated events or alerts around the same timeframe that might indicate a broader attack or unauthorized activity within the GCP environment.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may trigger bucket deletion events. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for log management might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on their service accounts or specific identifiers.
+- Testing environments often involve the creation and deletion of resources, including log buckets. Exclude events from these environments by using labels or project identifiers to differentiate them from production environments.
+- Scheduled cleanup jobs that remove old or unused buckets can generate false positives. Document these jobs and adjust the detection rule to ignore deletions occurring within their scheduled time frames.
+- Misconfigured log sinks that inadvertently delete buckets should be reviewed. Regularly audit and adjust sink configurations to ensure they align with intended log routing and retention policies.
+
+### Response and remediation
+
+- Immediately halt any ongoing log routing to the deleted bucket by deleting or modifying the log sinks associated with it to prevent further data loss.
+- Restore the deleted log bucket from its pending deletion state within the 7-day window to recover any logs that may still be routed to it.
+- Conduct a thorough review of IAM permissions and roles to ensure that only authorized personnel have the ability to delete log buckets, reducing the risk of unauthorized deletions.
+- Implement additional logging and monitoring for any changes to log sinks and bucket configurations to detect and respond to similar activities promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if the deletion was part of a broader attack strategy.
+- Review and update incident response plans to include specific procedures for handling log bucket deletions and similar defense evasion tactics.
+- Consider enabling alerts for any future attempts to delete log buckets, ensuring rapid detection and response to potential threats.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/buckets", "https://cloud.google.com/logging/docs/storage"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
index 3b91941b1cc..8e2fc2b8f38 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,41 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Sink Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Logging Sink Deletion
+
+In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and storage. Adversaries may delete these sinks to prevent logs from being exported, thereby evading detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteSink to identify the user or service account responsible for the deletion.
+- Check the event.dataset:gcp.audit logs for any preceding or subsequent suspicious activities by the same user or service account, which might indicate a pattern of malicious behavior.
+- Investigate the event.outcome:success to confirm the deletion was successful and determine the impact on log monitoring and export capabilities.
+- Assess the context and timing of the deletion event to see if it coincides with other security alerts or incidents, which might suggest a coordinated attack.
+- Verify the permissions and roles assigned to the user or service account involved in the deletion to ensure they align with the principle of least privilege and identify any potential misconfigurations.
+
+### False positive analysis
+
+- Routine maintenance or configuration changes by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for managing logging configurations might inadvertently delete sinks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or service accounts.
+- Changes in project ownership or restructuring within the organization can lead to legitimate sink deletions. Document these organizational changes and adjust the monitoring rules to account for them, ensuring that alerts are only generated for unexpected deletions.
+- Test environments often undergo frequent changes, including sink deletions, which can result in false positives. Implement separate monitoring rules or exceptions for test environments to reduce noise in alerting.
+
+### Response and remediation
+
+- Immediately revoke access to the affected GCP project for any suspicious or unauthorized users identified in the audit logs to prevent further malicious activity.
+- Restore the deleted logging sink by recreating it with the original configuration to ensure that log entries are once again exported to the designated destination.
+- Conduct a thorough review of recent log entries and audit logs to identify any other unauthorized changes or suspicious activities that may have occurred around the time of the sink deletion.
+- Implement additional monitoring and alerting for any future attempts to delete logging sinks, focusing on the specific event action and outcome fields used in the detection query.
+- Escalate the incident to the security operations team for further investigation and to determine if the sink deletion is part of a larger attack campaign.
+- Review and update access controls and permissions for logging sink management to ensure that only authorized personnel have the ability to modify or delete sinks.
+- Consider enabling additional security features such as VPC Service Controls or Organization Policy constraints to provide an extra layer of protection against unauthorized modifications to logging configurations.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/export"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
index d81d4f1c70e..41f038e2c2e 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Subscription Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Pub/Sub Subscription Deletion
+
+Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between event producers and consumers. Subscriptions in Pub/Sub are crucial for message delivery to applications. Adversaries may delete subscriptions to disrupt communication, evade detection, or impair defenses. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.pubsub.v*.Subscriber.DeleteSubscription to identify the user or service account responsible for the deletion.
+- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity.
+- Investigate the context of the deleted subscription by examining the associated project and any related resources to understand the potential impact on the application or service.
+- Verify if the deletion aligns with any recent changes or maintenance activities within the organization to rule out legitimate actions.
+- Assess the permissions and roles assigned to the user or service account to ensure they are appropriate and not overly permissive, which could indicate a security risk.
+- Consult with the relevant application or service owners to confirm whether the subscription deletion was authorized and necessary.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may lead to subscription deletions that are not malicious. To manage this, create exceptions for known maintenance windows or specific admin accounts.
+- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers.
+- Development and testing environments often involve frequent creation and deletion of subscriptions. Exclude these environments from alerts by filtering based on project IDs or environment tags.
+- Subscription deletions as part of a resource cleanup process can be non-threatening. Document and exclude these processes by identifying patterns in the audit logs, such as specific user agents or IP addresses associated with cleanup operations.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the subscription deletion by contacting the responsible team or individual to confirm if the action was authorized.
+- If unauthorized, revoke access for the user or service account involved in the deletion to prevent further unauthorized actions.
+- Restore the deleted subscription from backup or recreate it if necessary, ensuring that message delivery to the application is resumed.
+- Conduct a thorough review of audit logs to identify any other suspicious activities or patterns that may indicate further compromise.
+- Implement additional access controls and monitoring for Pub/Sub resources to prevent unauthorized deletions in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were affected.
+- Update incident response plans and playbooks to include specific procedures for handling Pub/Sub subscription deletions and similar threats.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
index b0c2ba3b66a..a4c66e3681a 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Pub/Sub Topic Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Pub/Sub Topic Deletion
+
+Google Cloud Platform's Pub/Sub service facilitates asynchronous messaging, allowing applications to communicate by publishing messages to topics. Deleting a topic can disrupt this communication, potentially as a tactic for defense evasion. Adversaries might exploit this by deleting topics to impair defenses or hide their tracks. The detection rule monitors audit logs for successful topic deletions, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.pubsub.v*.Publisher.DeleteTopic to identify the exact time and user or service account responsible for the deletion.
+- Investigate the event.dataset:gcp.audit logs around the same timeframe to identify any related activities or anomalies that might indicate malicious intent or unauthorized access.
+- Check the event.outcome:success to confirm the deletion was completed successfully and correlate it with any reported service disruptions or issues in the affected applications.
+- Assess the permissions and roles of the user or service account involved in the deletion to determine if they had legitimate access and reasons for performing this action.
+- Contact the user or team responsible for the deletion to verify if the action was intentional and authorized, and gather any additional context or justification for the deletion.
+- Review any recent changes in IAM policies or configurations that might have inadvertently allowed unauthorized topic deletions.
+
+### False positive analysis
+
+- Routine maintenance or updates by administrators can lead to legitimate topic deletions. To manage this, create exceptions for known maintenance periods or specific admin accounts.
+- Automated scripts or tools that manage Pub/Sub topics might delete topics as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers.
+- Development and testing environments often involve frequent topic creation and deletion. Exclude these environments from monitoring by filtering based on project IDs or environment tags.
+- Scheduled clean-up jobs that remove unused or temporary topics can trigger false positives. Document these jobs and adjust the detection rule to ignore deletions occurring during their execution times.
+- Changes in project requirements or architecture might necessitate topic deletions. Ensure that such changes are communicated and documented, allowing for temporary exceptions during the transition period.
+
+### Response and remediation
+
+- Immediately assess the impact of the topic deletion by identifying affected services and applications that rely on the deleted topic for message flow.
+- Restore the deleted topic from backup if available, or recreate the topic with the same configuration to resume normal operations.
+- Notify relevant stakeholders, including application owners and security teams, about the incident and potential service disruptions.
+- Review access logs and permissions to identify unauthorized access or privilege escalation that may have led to the topic deletion.
+- Implement stricter access controls and permissions for Pub/Sub topics to prevent unauthorized deletions in the future.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the deletion is part of a larger attack pattern.
+- Enhance monitoring and alerting for Pub/Sub topic deletions to ensure rapid detection and response to similar incidents in the future.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/pubsub/docs/overview"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
index 58c3e161484..6133b2d43d1 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,44 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Configuration Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Storage Bucket Configuration Modification
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. Adversaries may alter bucket configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful configuration changes, flagging potential defense evasion attempts by identifying suspicious modifications to storage settings.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "storage.buckets.update" to identify the user or service account responsible for the configuration change.
+- Examine the event.outcome field to confirm the success of the configuration modification and gather details on what specific changes were made to the storage bucket settings.
+- Investigate the context of the change by checking the timestamp of the event to determine if it aligns with any known maintenance or deployment activities.
+- Assess the permissions and roles of the user or service account involved in the modification to ensure they have the appropriate level of access and determine if any privilege escalation occurred.
+- Cross-reference the modified bucket's configuration with security policies and best practices to identify any potential security weaknesses introduced by the change.
+- Check for any other recent suspicious activities or alerts related to the same user or service account to identify patterns of potentially malicious behavior.
+- If unauthorized changes are suspected, initiate a response plan to revert the configuration to its previous state and strengthen access controls to prevent future incidents.
+
+### False positive analysis
+
+- Routine administrative updates to storage bucket configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their typical activities, and create exceptions for these actions in the monitoring system.
+- Automated processes or scripts that regularly update bucket configurations for maintenance or compliance purposes may cause false positives. Identify these processes and exclude their actions from triggering alerts by using service accounts or specific identifiers.
+- Changes made by cloud management tools or third-party services integrated with GCP might be flagged. Review and whitelist these tools if they are verified and necessary for operations.
+- Scheduled updates or configuration changes as part of regular security audits can appear suspicious. Document these schedules and incorporate them into the monitoring system to prevent unnecessary alerts.
+- Temporary configuration changes for testing or development purposes might be misinterpreted as threats. Ensure that such activities are logged and communicated to the security team to adjust monitoring rules accordingly.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized access to the affected GCP storage bucket by reviewing and adjusting IAM policies to ensure only legitimate users have access.
+- Conduct a thorough review of recent bucket configuration changes to identify any unauthorized modifications and revert them to their original secure state.
+- Isolate the affected storage bucket from the network if suspicious activity is detected, to prevent further unauthorized access or data exfiltration.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts.
+- Implement additional logging and monitoring on the affected bucket to detect any further unauthorized access attempts or configuration changes.
+- Review and update security policies and access controls for all GCP storage buckets to prevent similar incidents in the future.
+- Escalate the incident to the cloud security team for a comprehensive analysis and to determine if further action is required, such as involving legal or compliance teams.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
index 5aa2543b2d8..eb749c4a286 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Permissions Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Storage Bucket Permissions Modification
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. IAM permissions control access to these buckets, ensuring data security. Adversaries may alter these permissions to bypass security measures, leading to unauthorized data access or exposure. The detection rule identifies successful permission changes, signaling potential misuse or accidental misconfigurations, aiding in timely security audits and responses.
+
+### Possible investigation steps
+
+- Review the event logs for the specific action "storage.setIamPermissions" to identify which IAM permissions were modified and by whom.
+- Check the event.outcome field to confirm the success of the permission change and correlate it with any recent access attempts or data access patterns.
+- Investigate the identity of the user or service account that performed the permission change to determine if it aligns with expected administrative activities.
+- Assess the current IAM policy of the affected storage bucket to understand the new permissions and evaluate any potential security risks or exposure.
+- Cross-reference the timing of the permission change with other security events or alerts to identify any suspicious activity or patterns.
+- Consult with the bucket owner or relevant stakeholders to verify if the permission change was authorized and necessary for operational purposes.
+
+### False positive analysis
+
+- Routine administrative updates to IAM permissions can trigger alerts. To manage this, create exceptions for known maintenance windows or specific administrative accounts that regularly perform these updates.
+- Automated scripts or tools that adjust permissions as part of their normal operation may cause false positives. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
+- Changes made by trusted third-party services integrated with GCP might be flagged. Review and whitelist these services if they are verified and necessary for business operations.
+- Temporary permission changes for troubleshooting or testing purposes can be mistaken for malicious activity. Document and schedule these changes, and exclude them from alerts during the specified timeframes.
+- Permissions modified by cloud management platforms or orchestration tools should be reviewed. If these tools are part of standard operations, consider excluding their actions from the detection rule.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized IAM permissions changes by restoring the previous known good configuration for the affected GCP storage bucket.
+- Conduct a thorough review of the IAM policy change logs to identify the source and nature of the modification, focusing on the user or service account responsible for the change.
+- Isolate the affected storage bucket from external access until the permissions are verified and secured to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and the steps taken to mitigate the risk.
+- Implement additional monitoring on the affected storage bucket and related IAM policies to detect any further unauthorized changes or suspicious activities.
+- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of similar incidents in the future.
+- If the incident is suspected to be part of a larger attack, escalate to incident response teams for a comprehensive investigation and potential involvement of law enforcement if necessary.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/access-control/iam-permissions"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
index ae837651b9c..c163e2a2b85 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Network Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Virtual Private Cloud Network Deletion
+
+Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, flagging potential malicious activity by correlating specific event actions and outcomes.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action value "v*.compute.networks.delete" to identify the exact time and user account associated with the VPC network deletion.
+- Check the event.outcome field to confirm the success of the deletion and correlate it with any other suspicious activities around the same timeframe.
+- Investigate the user account or service account that performed the deletion to determine if it was authorized and if there are any signs of compromise or misuse.
+- Examine the project and network configurations to assess the impact of the VPC deletion on the organization's operations and identify any critical resources that were affected.
+- Look for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete the VPC network.
+- Cross-reference the deletion event with other security alerts or incidents to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Routine maintenance activities may involve the deletion of VPC networks as part of infrastructure updates or reconfigurations. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for environment cleanup might trigger false positives if they delete VPC networks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags associated with these tools.
+- Development and testing environments often undergo frequent changes, including VPC deletions. Consider excluding these environments from alerts by filtering based on project IDs or environment tags to reduce noise.
+- Organizational policy changes might lead to the intentional deletion of VPC networks. Ensure that such policy-driven actions are documented and that the responsible teams are excluded from triggering alerts by using role-based access controls or specific user identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected project by restricting network access to prevent further unauthorized deletions or modifications.
+- Review the audit logs to identify the source of the deletion request, including the user account and IP address, and verify if it was authorized.
+- Recreate the deleted VPC network using the latest backup or configuration snapshot to restore network operations and minimize downtime.
+- Implement additional access controls, such as multi-factor authentication and least privilege principles, to prevent unauthorized access to VPC management.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to Google Cloud Platform support if necessary, especially if there are indications of a broader compromise or if assistance is needed in recovery.
+- Enhance monitoring and alerting for VPC-related activities to detect and respond to similar threats more effectively in the future.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/vpc"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
index 14e579912ce..27707e415c6 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Route Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Virtual Private Cloud Route Creation
+
+In Google Cloud Platform, VPC routes dictate the network paths for traffic from VM instances to various destinations, both within and outside the VPC. Adversaries may exploit this by creating routes to reroute or intercept traffic, potentially disrupting or spying on network communications. The detection rule identifies such activities by monitoring specific audit events related to route creation, aiding in the early detection of unauthorized network modifications.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:gcp.audit and event.action values (v*.compute.routes.insert or "beta.compute.routes.insert") to identify the exact time and user account associated with the route creation.
+- Examine the details of the newly created route, including the destination IP range and next hop, to determine if it aligns with expected network configurations or if it appears suspicious.
+- Check the IAM permissions and roles of the user account that created the route to assess if they had the necessary privileges and if those privileges are appropriate for their role.
+- Investigate any recent changes in the environment that might explain the route creation, such as new deployments or changes in network architecture.
+- Correlate the route creation event with other security events or alerts in the same timeframe to identify potential patterns or coordinated activities that could indicate malicious intent.
+- Consult with the network or cloud infrastructure team to verify if the route creation was part of an authorized change or if it was unexpected.
+
+### False positive analysis
+
+- Routine network configuration changes by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who frequently make legitimate changes and exclude their activities from triggering alerts.
+- Automated deployment tools that create or modify routes as part of their normal operation may cause false positives. Identify these tools and their associated service accounts, then configure exceptions for these accounts in the monitoring system.
+- Scheduled maintenance activities often involve creating or updating routes. Document these activities and set temporary exceptions during the maintenance window to prevent unnecessary alerts.
+- Integration with third-party services might require route creation. Verify these integrations and whitelist the associated actions to avoid false positives.
+- Development and testing environments may have frequent route changes. Consider applying different monitoring thresholds or rules for these environments to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected VM instances by removing or disabling the suspicious route to prevent further unauthorized traffic redirection.
+- Conduct a thorough review of recent route creation activities in the GCP environment to identify any other unauthorized or suspicious routes.
+- Revoke any unauthorized access or permissions that may have allowed the adversary to create the route, focusing on IAM roles and service accounts with route creation privileges.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement network monitoring and logging to detect any future unauthorized route creation attempts, ensuring that alerts are configured for similar activities.
+- Review and update the GCP VPC network security policies to enforce stricter controls on route creation and modification, limiting these actions to trusted administrators only.
+- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any additional security measures or advisories.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
index b0b775a5f06..dbeccf5e981 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Virtual Private Cloud Route Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Virtual Private Cloud Route Deletion
+
+In GCP, VPC routes dictate network traffic paths between VM instances and other destinations. Adversaries may delete these routes to disrupt traffic flow, potentially evading defenses or impairing network operations. The detection rule monitors audit logs for successful route deletions, flagging potential misuse by identifying specific actions linked to route removal, thus aiding in timely threat response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:gcp.audit and event.action:v*.compute.routes.delete to identify the exact time and user account associated with the route deletion.
+- Check the event.outcome:success field to confirm the deletion was successful and not an attempted action.
+- Investigate the user account or service account that performed the deletion to determine if it was authorized to make such changes, including reviewing recent activity and permissions.
+- Assess the impact of the route deletion by identifying which VPC and network traffic paths were affected, and determine if any critical services were disrupted.
+- Correlate the route deletion event with other security events or alerts around the same timeframe to identify potential coordinated actions or broader attack patterns.
+- Contact the relevant stakeholders or system owners to verify if the route deletion was intentional and part of a planned change or if it was unauthorized.
+
+### False positive analysis
+
+- Routine maintenance activities by network administrators can trigger route deletions. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or tools used for network configuration updates may delete and recreate routes as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts.
+- Cloud infrastructure changes during deployment processes might involve temporary route deletions. Document these processes and exclude related events from detection during deployment periods.
+- Scheduled network reconfigurations that involve route deletions should be logged and excluded from alerts by correlating with change management records.
+- Test environments often undergo frequent network changes, including route deletions. Exclude events from test environments by filtering based on project or environment tags.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC to prevent further unauthorized network traffic disruptions. This can be done by temporarily disabling external access or applying restrictive firewall rules.
+- Review the audit logs to identify the user or service account responsible for the route deletion. Verify if the action was authorized and investigate any anomalies in user behavior or access patterns.
+- Restore the deleted route using the latest backup or configuration management tools to re-establish normal network traffic flow. Ensure that the restored route aligns with the intended network architecture.
+- Implement additional access controls and monitoring for the affected VPC, such as enabling more granular IAM roles and setting up alerts for any future route modifications.
+- Conduct a security review of the affected environment to identify any other potential misconfigurations or vulnerabilities that could be exploited in a similar manner.
+- Escalate the incident to the security operations team for further investigation and to determine if the route deletion was part of a larger attack campaign.
+- Document the incident, including the root cause analysis and remediation steps taken, to enhance organizational knowledge and improve future incident response efforts.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
diff --git a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
index c1b0254c4f0..000bd8e4d33 100644
--- a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
+++ b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Logging Sink Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Logging Sink Modification
+
+In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule identifies successful modifications to logging sinks, signaling potential misuse by monitoring specific audit events related to sink updates.
+
+### Possible investigation steps
+
+- Review the event details for the specific `event.action` field value `google.logging.v*.ConfigServiceV*.UpdateSink` to confirm the type of modification made to the logging sink.
+- Check the `event.outcome` field to ensure the modification was successful, as indicated by the value `success`.
+- Identify the user or service account responsible for the modification by examining the `actor` or `principalEmail` fields in the audit log.
+- Investigate the `resource` field to determine which logging sink was modified and assess its intended purpose and usual configuration.
+- Analyze the `destination` field in the sink configuration to verify if the new export destination is authorized and aligns with organizational policies.
+- Review historical logs for any previous modifications to the same logging sink to identify patterns or repeated unauthorized changes.
+- Correlate this event with other security alerts or anomalies in the environment to assess if this modification is part of a broader attack or data exfiltration attempt.
+
+### False positive analysis
+
+- Routine updates to logging sinks by authorized personnel can trigger alerts. To manage this, maintain a list of known and trusted users who regularly perform these updates and create exceptions for their actions.
+- Automated processes or scripts that update logging sinks as part of regular maintenance or deployment activities may cause false positives. Identify these processes and exclude their specific actions from triggering alerts.
+- Changes to logging sinks during scheduled maintenance windows can be mistaken for unauthorized modifications. Define and exclude these time periods from monitoring to reduce unnecessary alerts.
+- Integration with third-party tools that require sink modifications for functionality might generate false positives. Document these integrations and adjust the detection rule to account for their expected behavior.
+- Frequent changes in a dynamic environment, such as development or testing environments, can lead to false positives. Consider applying the rule more stringently in production environments while relaxing it in non-production settings.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the unauthorized modification of the logging sink and identify the source of the change, including the user account and IP address involved.
+- Revert the logging sink configuration to its original state to ensure logs are directed to the intended, secure destination.
+- Temporarily disable or restrict access to the user account or service account that made the unauthorized change to prevent further unauthorized actions.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized modification and initial containment actions taken.
+- Conduct a thorough investigation to determine if any data was exfiltrated and assess the potential impact on the organization.
+- Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future.
+- Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/logging/docs/export#how_sinks_work"]
diff --git a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
index c999c7eebe1..da66408034c 100644
--- a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
+++ b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Role Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP IAM Role Deletion
+
+Google Cloud Platform's IAM roles define permissions for actions on resources, crucial for managing access. Adversaries might delete roles to disrupt legitimate user access, hindering operations. The detection rule monitors audit logs for successful role deletions, signaling potential unauthorized access removal, thus aiding in identifying and mitigating such security threats.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteRole to identify the exact role that was deleted and the associated project or resource.
+- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs.
+- Check the event.timestamp to determine when the role deletion occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the event.outcome:success to confirm that the role deletion was completed successfully and assess the potential impact on access and operations.
+- Analyze the context of the deletion by reviewing recent changes or activities in the project or organization to understand if the deletion was part of a legitimate change or an unauthorized action.
+- Contact the user or team responsible for the project to verify if the role deletion was intentional and authorized, and gather additional context if needed.
+
+### False positive analysis
+
+- Routine administrative actions may trigger alerts when roles are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or tools that manage IAM roles might cause false positives if they delete roles as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
+- Deletion of temporary or test roles used in development environments can be mistaken for malicious activity. Implement filters to exclude actions within designated development projects or environments.
+- Changes in organizational structure or policy might necessitate role deletions, which could be misinterpreted as threats. Document and communicate these changes to the security team to adjust monitoring rules accordingly.
+- Third-party integrations or services that manage IAM roles could inadvertently cause false positives. Ensure these services are properly documented and their actions are whitelisted if deemed non-threatening.
+
+### Response and remediation
+
+- Immediately revoke any active sessions and credentials associated with the deleted IAM role to prevent unauthorized access.
+- Restore the deleted IAM role from a backup or recreate it with the same permissions to ensure legitimate users regain access.
+- Conduct a thorough review of recent IAM activity logs to identify any unauthorized changes or suspicious activities related to IAM roles.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring on IAM role changes to detect and alert on any future unauthorized deletions promptly.
+- Review and tighten IAM role permissions to ensure the principle of least privilege is enforced, reducing the risk of similar incidents.
+- Consider enabling additional security features such as multi-factor authentication (MFA) for accounts with permissions to modify IAM roles.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/understanding-roles"]
diff --git a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
index 7f30b45a128..d99fd367405 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Service Account Deletion
+
+In Google Cloud Platform, service accounts are crucial for enabling applications and VMs to perform authorized actions without user intervention. Adversaries may exploit this by deleting service accounts to disrupt operations or remove access. The detection rule monitors audit logs for successful service account deletions, flagging potential malicious activity to ensure timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteServiceAccount to identify the exact time and source of the deletion.
+- Identify the user or service account that initiated the deletion by examining the actor information in the audit logs.
+- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity.
+- Investigate the context of the deleted service account, including its permissions and the resources it had access to, to assess the potential impact of its deletion.
+- Contact the relevant team or individual responsible for the service account to verify if the deletion was authorized and intentional.
+- If unauthorized, review access controls and consider implementing additional security measures to prevent future unauthorized deletions.
+
+### False positive analysis
+
+- Routine maintenance or updates may involve the deletion and recreation of service accounts. To manage this, create exceptions for known maintenance activities by excluding specific service account names or associated project IDs during these periods.
+- Automated scripts or deployment tools might delete and recreate service accounts as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on the user or service account executing the script.
+- Organizational policy changes or restructuring can lead to legitimate service account deletions. Coordinate with the IT or security team to document these changes and adjust the detection rule to exclude these known events.
+- Test environments often involve frequent creation and deletion of service accounts. Exclude test project IDs or environments from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke any permissions associated with the deleted service account to prevent unauthorized access or actions by adversaries exploiting the deletion.
+- Restore the deleted service account if possible, using GCP's undelete feature, to minimize disruption to business operations and restore normal functionality.
+- Review and audit recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded or followed the service account deletion.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and facilitate coordinated response efforts.
+- Implement additional monitoring on critical service accounts to detect and alert on any further unauthorized deletion attempts.
+- Conduct a root cause analysis to determine how the service account deletion was initiated and address any security gaps or misconfigurations that allowed it.
+- Enhance access controls and consider implementing multi-factor authentication for actions involving service account management to prevent similar incidents in the future.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
index 034f249af9b..b88c8aac57e 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Service Account Disabled
+
+In Google Cloud Platform, service accounts are crucial for applications and VMs to perform authorized actions without user intervention. Adversaries may disable these accounts to disrupt services, impacting business operations. The detection rule identifies successful disablement actions in audit logs, signaling potential malicious activity by correlating specific event actions and outcomes, thus enabling timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.DisableServiceAccount to identify the exact time and source of the disablement action.
+- Identify the user or service account that performed the disablement by examining the actor information in the audit logs.
+- Check for any recent changes or unusual activities associated with the disabled service account, such as modifications to permissions or roles.
+- Investigate any related events or actions in the audit logs around the same timeframe to identify potential patterns or additional suspicious activities.
+- Assess the impact of the disabled service account on business operations by determining which applications or services were using the account.
+- Contact relevant stakeholders or application owners to verify if the disablement was authorized or if it was an unexpected action.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may involve disabling service accounts temporarily. To manage this, create exceptions for known maintenance periods or specific administrator actions.
+- Automated scripts or tools used for testing or deployment might disable service accounts as part of their process. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
+- Organizational policy changes or restructuring might lead to intentional service account disablement. Document these changes and update the detection rule to recognize these legitimate actions.
+- Service accounts associated with deprecated or retired applications may be disabled as part of cleanup efforts. Maintain an updated list of such applications and exclude related disablement actions from alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected service account by revoking its permissions to prevent further unauthorized actions.
+- Review the audit logs to identify any other suspicious activities associated with the disabled service account and assess the potential impact on business operations.
+- Re-enable the service account if it is determined to be legitimate and necessary for business functions, ensuring that it is secured with appropriate permissions and monitoring.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly.
+- Conduct a root cause analysis to understand how the service account was disabled and address any security gaps or misconfigurations that allowed the incident to occur.
+- Consider implementing additional security measures such as multi-factor authentication and least privilege access to enhance the protection of service accounts.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
index cfc19dbb136..795577a9a02 100644
--- a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Storage Bucket Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Storage Bucket Deletion
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in cloud environments. Adversaries may target these buckets to delete critical data, causing operational disruptions. The detection rule monitors audit logs for deletion actions, identifying potential malicious activity by flagging events where storage buckets are removed, thus enabling timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "storage.buckets.delete" to identify the user or service account responsible for the deletion.
+- Check the timestamp of the deletion event to determine when the bucket was deleted and correlate it with any other suspicious activities around that time.
+- Investigate the IP address and location from which the deletion request originated to assess if it aligns with expected access patterns.
+- Examine the permissions and roles assigned to the user or service account involved in the deletion to determine if they had legitimate access.
+- Look for any recent changes in IAM policies or permissions that might have allowed unauthorized access to the storage bucket.
+- Contact the relevant stakeholders or data owners to confirm if the deletion was authorized or if it was unexpected.
+
+### False positive analysis
+
+- Routine maintenance or scheduled deletions by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or applications that manage storage lifecycle policies might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers.
+- Development or testing environments often involve frequent creation and deletion of storage buckets. Exclude these environments from monitoring by filtering based on project IDs or environment tags.
+- Organizational policy changes that involve restructuring storage resources can lead to legitimate bucket deletions. Coordinate with relevant teams to update detection rules temporarily during such changes.
+
+### Response and remediation
+
+- Immediately isolate the affected GCP project to prevent further unauthorized access or actions. This can be done by revoking access keys and permissions for any suspicious accounts identified in the audit logs.
+- Restore the deleted storage bucket from the most recent backup to minimize data loss and operational disruption. Ensure that the backup is clean and free from any malicious alterations.
+- Conduct a thorough review of IAM roles and permissions associated with the affected storage bucket to ensure that only authorized users have the necessary access. Implement the principle of least privilege.
+- Enable versioning on critical storage buckets to protect against accidental or malicious deletions in the future, allowing for easier recovery of deleted objects.
+- Set up alerts for any future deletion actions on storage buckets to ensure immediate awareness and response to similar threats.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were compromised.
+- Document the incident, including actions taken and lessons learned, to improve response strategies and update incident response plans for future reference.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
diff --git a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
index fbf52054537..b73a99e175e 100644
--- a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
+++ b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Custom Role Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP IAM Custom Role Creation
+
+Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role.
+- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations.
+- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions.
+- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies.
+- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior.
+- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern.
+- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly.
+- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action.
+- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization.
+- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege.
+- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation.
+- Implement additional monitoring on the identified user or service account to detect any further suspicious activities.
+- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles.
+- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/understanding-custom-roles"]
diff --git a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
index 18048b305d9..3091a47ed2f 100644
--- a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
+++ b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP IAM Service Account Key Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP IAM Service Account Key Deletion
+
+In GCP, IAM service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries might delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aiding in timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.iam.admin.v*.DeleteServiceAccountKey to identify the service account key that was deleted.
+- Check the event.outcome: success to confirm the key deletion was successful and not an attempted action.
+- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs.
+- Investigate the context around the deletion event, including the timestamp and any preceding or subsequent actions in the logs, to understand the sequence of events.
+- Verify if the key deletion aligns with the organization's key rotation policy or if it appears suspicious or unauthorized.
+- Assess the impact of the key deletion on applications or services that rely on the affected service account for authentication.
+- If unauthorized activity is suspected, initiate a broader investigation into potential unauthorized access or other malicious activities involving the affected service account.
+
+### False positive analysis
+
+- Routine key rotation activities by administrators can trigger alerts. To manage this, establish a baseline of expected key rotation schedules and exclude these from alerts.
+- Automated scripts or tools that perform regular maintenance and key management might cause false positives. Identify these scripts and whitelist their actions in the monitoring system.
+- Service account keys associated with non-critical or test environments may be deleted frequently as part of normal operations. Consider excluding these environments from the alerting criteria to reduce noise.
+- Temporary service accounts used for short-term projects or testing may have keys deleted as part of their lifecycle. Document these accounts and adjust the detection rule to ignore deletions from these specific accounts.
+
+### Response and remediation
+
+- Immediately revoke any remaining access for the compromised service account to prevent further unauthorized access to Google Cloud resources.
+- Investigate the audit logs to identify any unauthorized actions performed using the deleted key and assess the impact on affected resources.
+- Recreate the deleted service account key if necessary, ensuring that the new key is securely stored and access is restricted to authorized personnel only.
+- Implement additional monitoring on the affected service account to detect any further suspicious activities or unauthorized access attempts.
+- Escalate the incident to the security operations team for a comprehensive review and to determine if further investigation or response is required.
+- Review and update the key rotation policy to ensure that service account keys are rotated more frequently and securely managed to prevent similar incidents in the future.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
index 07b969e6a80..5d1bd27a06c 100644
--- a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
+++ b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Key Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Service Account Key Creation
+
+In GCP, service accounts are crucial for applications to authenticate and interact with Google services securely. They use cryptographic keys for API access, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. The detection rule monitors audit logs for new key creations, flagging potential misuse by identifying successful key generation events, thus helping to mitigate risks associated with unauthorized access.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation.
+- Check the event.dataset:gcp.audit logs to determine the user or process that initiated the key creation and verify if it aligns with expected behavior or scheduled tasks.
+- Investigate the permissions and roles assigned to the service account to assess the potential impact of the new key being used maliciously.
+- Examine the event.outcome:success logs to confirm the successful creation of the key and cross-reference with any recent changes or deployments that might justify the key creation.
+- Contact the owner or responsible team for the service account to verify if the key creation was authorized and necessary for their operations.
+- Review any recent alerts or incidents related to the service account to identify patterns or repeated unauthorized activities.
+
+### False positive analysis
+
+- Routine key rotations by automated processes can trigger alerts. To manage this, identify and whitelist these processes by their service account names or associated metadata.
+- Development and testing environments often generate new keys frequently. Exclude these environments from alerts by using environment-specific tags or labels.
+- Scheduled maintenance activities by cloud administrators may involve key creation. Document these activities and create exceptions based on the timing and user accounts involved.
+- Third-party integrations that require periodic key updates can cause false positives. Maintain a list of trusted third-party services and exclude their key creation events from alerts.
+- Internal tools or scripts that programmatically create keys for operational purposes should be reviewed and, if deemed safe, added to an exception list based on their execution context.
+
+### Response and remediation
+
+- Immediately revoke the newly created service account key to prevent unauthorized access. This can be done through the GCP Console or using the gcloud command-line tool.
+- Conduct a thorough review of the service account's permissions to ensure they are aligned with the principle of least privilege. Remove any unnecessary permissions that could be exploited.
+- Investigate the source of the key creation event by reviewing audit logs to identify the user or process responsible for the action. Determine if the action was authorized or if it indicates a potential compromise.
+- If unauthorized access is suspected, rotate all keys associated with the affected service account and any other potentially compromised accounts to mitigate further risk.
+- Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future.
+- Escalate the incident to the security team for further investigation and to determine if additional containment or remediation actions are necessary, including notifying affected stakeholders if a breach is confirmed.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/gcp/persistence_gcp_service_account_created.toml b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
index b929f9b69a2..0a1640f1e17 100644
--- a/rules/integrations/gcp/persistence_gcp_service_account_created.toml
+++ b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,41 @@ index = ["filebeat-*", "logs-gcp*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "GCP Service Account Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 GCP Service Account Creation
+
+In GCP, service accounts enable applications and VMs to interact with APIs securely. While essential for automation, they can be exploited if improperly managed. Adversaries might create service accounts to gain persistent access without detection. The detection rule monitors audit logs for successful service account creations, flagging potential unauthorized activities for further investigation.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateServiceAccount to identify the time and source of the service account creation.
+- Check the identity of the user or service that initiated the service account creation to determine if it aligns with expected administrative activities.
+- Investigate the permissions and roles assigned to the newly created service account to assess if they are excessive or unusual for its intended purpose.
+- Correlate the service account creation event with other recent activities in the environment to identify any suspicious patterns or anomalies.
+- Verify if the service account is being used by any unauthorized applications or VMs by reviewing recent API calls and access logs associated with the account.
+
+### False positive analysis
+
+- Routine service account creation by automated deployment tools or scripts can trigger false positives. Identify and document these tools, then create exceptions in the monitoring system to exclude these known activities.
+- Service accounts created by trusted internal teams for legitimate projects may also be flagged. Establish a process for these teams to notify security personnel of planned service account creations, allowing for pre-approval and exclusion from alerts.
+- Scheduled maintenance or updates that involve creating temporary service accounts can result in false positives. Coordinate with IT operations to understand their schedules and adjust monitoring rules to accommodate these activities.
+- Third-party integrations that require service accounts might be mistakenly flagged. Maintain an inventory of authorized third-party services and their associated service accounts to quickly verify and exclude these from alerts.
+
+### Response and remediation
+
+- Immediately disable the newly created service account to prevent any unauthorized access or actions.
+- Review the IAM policy and permissions associated with the service account to ensure no excessive privileges were granted.
+- Conduct a thorough audit of recent activities performed by the service account to identify any suspicious or unauthorized actions.
+- Notify the security team and relevant stakeholders about the potential security incident for further investigation and coordination.
+- Implement additional monitoring and alerting for service account creations to detect similar activities in the future.
+- If malicious activity is confirmed, follow incident response procedures to contain and remediate any impact, including revoking access and conducting a security review of affected resources.
+- Document the incident and response actions taken to improve future detection and response capabilities.
+
+## Setup
 
 The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://cloud.google.com/iam/docs/service-accounts"]
diff --git a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
index 9b43b940301..e818ff1d14f 100644
--- a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
+++ b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -30,6 +30,40 @@ query = '''
 configuration where event.dataset == "github.audit"
   and github.category == "protected_branch" and event.type == "change"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Protected Branch Settings Changed
+
+GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to identify the specific changes made to the protected branch settings, focusing on entries where event.dataset is "github.audit" and github.category is "protected_branch".
+- Determine the user account responsible for the changes by examining the audit log details, and verify if the account has a legitimate reason to modify branch protection settings.
+- Check the timing of the changes to see if they coincide with any other suspicious activities or known incidents within the organization.
+- Investigate the context of the change by reviewing recent pull requests or commits to the affected branch to assess if the changes align with ongoing development activities.
+- Communicate with the repository owner or relevant team members to confirm if the changes were authorized and necessary for current project requirements.
+- Evaluate the impact of the changes on the repository's security posture and consider reverting the changes if they were unauthorized or pose a security risk.
+
+### False positive analysis
+
+- Routine updates by trusted team members may trigger alerts. To manage this, create exceptions for specific users or teams who regularly update branch protection settings as part of their role.
+- Automated tools or scripts that modify branch settings for legitimate reasons can cause false positives. Identify these tools and whitelist their activities in the monitoring system.
+- Scheduled maintenance or policy updates might lead to expected changes in branch protection settings. Document these events and adjust the detection rule to ignore changes during these periods.
+- Changes made by administrators during onboarding or offboarding processes can be mistaken for unauthorized activity. Ensure these processes are well-documented and communicated to the security team to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revert any unauthorized changes to the protected branch settings to restore the original security posture.
+- Conduct a review of recent commits and merges to the affected branch to identify any unauthorized code changes that may have occurred during the period of altered settings.
+- Temporarily restrict access to the repository for users who made unauthorized changes until a full investigation is completed.
+- Notify the security team and relevant stakeholders about the incident for further analysis and to determine if additional security measures are needed.
+- Implement additional monitoring on the affected repository to detect any further unauthorized changes or suspicious activities.
+- Review and update access controls and permissions for the repository to ensure that only authorized personnel can modify branch protection settings.
+- Document the incident, including the timeline of events and actions taken, to improve future response efforts and update incident response plans."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_app_deleted.toml b/rules/integrations/github/execution_github_app_deleted.toml
index 7bced445fa9..c6f0da2a2b8 100644
--- a/rules/integrations/github/execution_github_app_deleted.toml
+++ b/rules/integrations/github/execution_github_app_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -24,6 +24,41 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 App Deleted
+
+GitHub Apps are integrations that extend GitHub's functionality, often used to automate workflows or manage repositories. Adversaries might delete these apps to disrupt operations or remove security controls. The detection rule monitors audit logs for app deletions, flagging potential unauthorized actions. By focusing on specific event types and categories, it helps identify suspicious deletions that could indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event type "deletion" within the "integration_installation" category to identify the exact GitHub app that was deleted.
+- Determine the user or account responsible for the deletion by examining the associated user information in the audit logs.
+- Check the timing of the deletion event to see if it coincides with any other suspicious activities or anomalies in the repository or organization.
+- Investigate the role and permissions of the user who performed the deletion to assess if they had legitimate access and authorization to delete the app.
+- Look into the history of the deleted GitHub app to understand its purpose, usage, and any dependencies it might have had within the organization or repository.
+- Communicate with the team or organization members to verify if the deletion was intentional and authorized, or if it was unexpected and potentially malicious.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger app deletions. Verify with the team responsible for GitHub app management to confirm if the deletion was planned.
+- Automated scripts or tools used for managing GitHub apps might inadvertently delete apps during updates or reconfigurations. Review the scripts and ensure they have proper safeguards to prevent accidental deletions.
+- Organizational policy changes might lead to the removal of certain apps. Check if there have been recent policy updates that could explain the deletion.
+- Exclude specific users or service accounts known to perform legitimate app deletions regularly by creating exceptions in the detection rule.
+- Monitor for patterns of deletions that align with scheduled maintenance windows and adjust the rule to ignore these timeframes if they consistently result in false positives.
+
+### Response and remediation
+
+- Immediately revoke any compromised credentials or tokens associated with the deleted GitHub app to prevent unauthorized access.
+- Restore the deleted GitHub app from a backup or re-install it to ensure continuity of operations and security controls.
+- Conduct a thorough review of recent changes and activities in the affected repositories or organization to identify any unauthorized actions or data alterations.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
+- Implement additional monitoring on the affected repositories or organization to detect any further suspicious activities or attempts to delete apps.
+- Review and tighten permissions for GitHub apps to ensure only authorized personnel have the ability to delete or modify app installations.
+- Escalate the incident to higher-level security management if there is evidence of a broader compromise or if the deletion is part of a larger attack campaign."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
index 1d14e096df7..a73ab195a5d 100644
--- a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
+++ b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,40 @@ event.dataset:"github.audit" and event.category:"configuration" and event.action
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and
 github.repository_public:false
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 High Number of Cloned GitHub Repos From PAT
+
+Personal Access Tokens (PATs) facilitate automated access to GitHub repositories, enabling seamless integration and management. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive code. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the specific personal access token (PAT) involved in the alert to determine its owner and associated user account.
+- Analyze the event logs for the PAT to identify the number and names of private repositories cloned, focusing on any unusual or unauthorized access patterns.
+- Check the access history of the PAT to see if there are any other suspicious activities or anomalies, such as access from unfamiliar IP addresses or locations.
+- Contact the owner of the PAT to verify if the cloning activity was authorized and to gather additional context about the usage of the token.
+- Investigate the security posture of the affected repositories, including reviewing access permissions and recent changes to repository settings.
+- Consider revoking the compromised PAT and issuing a new one if unauthorized access is confirmed, and ensure the user updates any systems or scripts using the old token.
+
+### False positive analysis
+
+- Legitimate automated processes or CI/CD pipelines may trigger multiple clone events. Review and whitelist known IP addresses or tokens associated with these processes to prevent false alerts.
+- Developers working on multiple projects might clone several private repositories in a short period. Identify and exclude these users or their tokens from triggering alerts by maintaining a list of frequent cloners.
+- Organizational scripts or tools that require cloning multiple repositories for updates or backups can cause false positives. Document these scripts and create exceptions for their associated tokens.
+- Scheduled maintenance or migration activities involving repository cloning can be mistaken for suspicious activity. Coordinate with relevant teams to anticipate such events and temporarily adjust detection thresholds or exclude specific tokens.
+
+### Response and remediation
+
+- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access to private repositories.
+- Notify the repository owners and relevant stakeholders about the potential breach to assess the impact and initiate internal incident response procedures.
+- Conduct a thorough review of the cloned repositories to identify any sensitive or proprietary information that may have been exposed.
+- Implement additional access controls, such as IP whitelisting or two-factor authentication, to enhance security for accessing private repositories.
+- Monitor for any unusual activity or further unauthorized access attempts using other PATs or credentials.
+- Escalate the incident to the security team for a comprehensive investigation and to determine if any other systems or data have been compromised.
+- Update and enforce policies regarding the creation, usage, and management of PATs to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
index aeefde947c4..a83a83e5b2e 100644
--- a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
+++ b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/14"
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,41 @@ type = "threshold"
 query = '''
 signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 UEBA - Multiple Alerts from a GitHub Account
+
+User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify unusual patterns that may indicate compromised accounts or tokens. Adversaries might exploit GitHub by executing multiple unauthorized actions within a short period. This detection rule flags such anomalies by monitoring for multiple alerts from the same user within an hour, aiding in prioritizing potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details in the security dashboard to identify the specific user account associated with the multiple alerts.
+- Check the recent activity logs for the identified user in GitHub to determine the nature and frequency of actions performed within the alert timeframe.
+- Investigate any recent changes to the user's permissions or access levels that might have facilitated unusual activity.
+- Correlate the alert data with other security tools or logs to identify any additional suspicious behavior or related alerts involving the same user.
+- Contact the user to verify if the actions were legitimate or if they suspect their account or personal access token (PAT) might be compromised.
+- If a compromise is suspected, initiate a password reset and revoke any active PATs for the user, and monitor for any further suspicious activity.
+
+### False positive analysis
+
+- High-frequency automated workflows or CI/CD pipelines may trigger multiple alerts within an hour. Review these workflows to ensure they are legitimate and consider adding exceptions for known, non-threatening automation.
+- Developers or teams working on time-sensitive projects might perform numerous actions in a short period, leading to false positives. Identify these users or teams and create exceptions to prevent unnecessary alerts.
+- Scheduled tasks or scripts that interact with GitHub repositories can generate multiple alerts. Verify the legitimacy of these tasks and exclude them from the rule if they are deemed safe.
+- Frequent use of GitHub Actions or bots that perform repetitive tasks could be misinterpreted as suspicious activity. Confirm their purpose and add them to an allowlist if they are part of normal operations.
+- Consider implementing a review process for alerts that involve known trusted users or service accounts to quickly dismiss false positives without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected GitHub account by revoking all active sessions and tokens to prevent further unauthorized actions.
+- Conduct a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security.
+- Review recent activity logs for the affected account to identify any unauthorized changes or data exfiltration, and revert any malicious modifications.
+- Notify the account owner and relevant security teams about the potential compromise to ensure awareness and coordinated response efforts.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional accounts or systems are affected.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
+- Update and refine access controls and permissions for the affected account to minimize the risk of future unauthorized actions."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/execution_new_github_app_installed.toml b/rules/integrations/github/execution_new_github_app_installed.toml
index 10754ac939c..0cd5b02d081 100644
--- a/rules/integrations/github/execution_new_github_app_installed.toml
+++ b/rules/integrations/github/execution_new_github_app_installed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -30,6 +30,40 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "integration_installation.create"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 New GitHub App Installed
+
+GitHub Apps enhance functionality by integrating with repositories and organization data, requiring careful scrutiny upon installation. Adversaries may exploit these apps to gain unauthorized access or manipulate data. The detection rule monitors audit logs for new app installations, flagging potential threats by identifying unauthorized or suspicious integrations, thus safeguarding organizational security.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset "github.audit" and event.action "integration_installation.create" to identify the newly installed GitHub App.
+- Verify the identity of the user or service account that performed the installation to ensure it aligns with expected behavior and authorized personnel.
+- Check the permissions requested by the newly installed app to assess the level of access it has to your repositories and organization data.
+- Cross-reference the app with a list of approved or trusted applications within your organization to determine if it is authorized.
+- Investigate the app's developer or vendor to ensure they are reputable and have a history of secure and reliable applications.
+- Communicate with the team or individual responsible for the installation to confirm the app's purpose and necessity within the organization.
+
+### False positive analysis
+
+- Frequent installations of trusted internal apps may trigger alerts. To manage this, maintain a list of approved internal apps and create exceptions for these in the detection rule.
+- Automated deployment tools that integrate with GitHub might cause false positives. Identify these tools and exclude their installation events from triggering alerts.
+- Regular updates or re-installations of existing apps can be mistaken for new installations. Track app version updates separately and adjust the rule to differentiate between updates and new installations.
+- Development or testing environments often install and remove apps frequently. Consider excluding these environments from the rule or setting up a separate monitoring process for them.
+
+### Response and remediation
+
+- Immediately revoke the permissions of the newly installed GitHub App to prevent any unauthorized access or data manipulation.
+- Notify the security team and relevant stakeholders about the unauthorized app installation for awareness and further investigation.
+- Conduct a review of recent repository and organization changes to identify any unauthorized modifications or data access that may have occurred.
+- If malicious activity is detected, initiate a rollback of affected repositories to a secure state prior to the app installation.
+- Escalate the incident to higher-level security management if the app installation is linked to a broader security breach or if sensitive data has been compromised.
+- Implement stricter access controls and approval processes for future GitHub App installations to prevent unauthorized installations.
+- Update detection mechanisms to include additional indicators of compromise related to GitHub App installations, enhancing future threat detection capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/impact_github_repository_deleted.toml b/rules/integrations/github/impact_github_repository_deleted.toml
index da383c6b1d6..e63c22d1281 100644
--- a/rules/integrations/github/impact_github_repository_deleted.toml
+++ b/rules/integrations/github/impact_github_repository_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,39 @@ type = "eql"
 query = '''
 configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Repository Deleted
+GitHub repositories are essential for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase critical data, potentially indicating a security breach. The detection rule monitors GitHub audit logs for repository deletion events, enabling analysts to swiftly identify and investigate unauthorized actions, thereby mitigating potential data loss and compromise.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to confirm the repository deletion event by checking for entries where event.module is "github", event.dataset is "github.audit", and event.action is "repo.destroy".
+- Identify the user account associated with the deletion event and verify their access permissions and recent activity to determine if the action was authorized.
+- Contact the user or team responsible for the repository to confirm whether the deletion was intentional and documented.
+- Check for any recent changes in user access or permissions that could indicate a compromised account or unauthorized access.
+- Investigate any other suspicious activities or alerts related to the same user or repository around the time of the deletion event to identify potential patterns of malicious behavior.
+- Assess the impact of the repository deletion on ongoing projects and data availability, and initiate recovery procedures if necessary.
+
+### False positive analysis
+
+- Routine repository clean-up activities by authorized personnel may trigger alerts. To manage this, maintain a list of users or teams responsible for such tasks and create exceptions for their actions.
+- Automated scripts or tools used for repository management might delete repositories as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
+- Test or temporary repositories that are frequently created and deleted during development cycles can cause false positives. Implement naming conventions for these repositories and configure the rule to ignore deletions matching these patterns.
+- Scheduled repository deletions as part of a lifecycle management policy can be mistaken for unauthorized actions. Document these schedules and adjust the detection rule to accommodate these planned activities.
+
+### Response and remediation
+
+- Immediately revoke access for any user account associated with the unauthorized repository deletion to prevent further malicious actions.
+- Restore the deleted repository from backups or snapshots, if available, to recover lost data and minimize operational disruption.
+- Conduct a thorough review of recent access logs and user activities to identify any other suspicious actions or potential indicators of compromise.
+- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and awareness.
+- Implement additional access controls, such as multi-factor authentication and role-based access, to prevent unauthorized deletions in the future.
+- Escalate the incident to higher management and legal teams if intellectual property theft or significant data loss is suspected.
+- Enhance monitoring and alerting mechanisms to detect similar unauthorized actions promptly, leveraging the MITRE ATT&CK framework for guidance on potential threat vectors."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/persistence_github_org_owner_added.toml b/rules/integrations/github/persistence_github_org_owner_added.toml
index 3046b5e72be..05fc5a2f233 100644
--- a/rules/integrations/github/persistence_github_org_owner_added.toml
+++ b/rules/integrations/github/persistence_github_org_owner_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,41 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 New GitHub Owner Added
+
+GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to identify the specific user account that was added as an owner, focusing on the event.action "org.add_member" and github.permission "admin".
+- Verify the identity and role of the newly added owner by cross-referencing with internal HR or user management systems to confirm if the addition was authorized.
+- Check the activity history of the newly added owner account for any suspicious actions or changes made to repositories or settings since their addition.
+- Contact the individual or team responsible for managing GitHub organization permissions to confirm if they were aware of and approved the new owner addition.
+- Investigate any recent changes in the organization's membership or access policies that might explain the addition of a new owner.
+- Assess the potential impact of the new owner's access by reviewing the repositories and sensitive data they now have administrative control over.
+
+### False positive analysis
+
+- Legitimate organizational changes: New owners may be added during legitimate restructuring or team expansions. Regularly review and document organizational changes to differentiate between authorized and unauthorized additions.
+- Automated processes: Some organizations use automated scripts or tools to manage GitHub permissions, which might trigger this rule. Identify and whitelist these processes to prevent unnecessary alerts.
+- Temporary access requirements: Occasionally, temporary owner access might be granted for specific projects or tasks. Implement a process to track and review these temporary changes, ensuring they are reverted once the task is completed.
+- Onboarding of new senior staff: When new senior staff members join, they might be added as owners. Establish a clear onboarding process that includes notifying the security team to avoid false positives.
+- Cross-functional team collaborations: In some cases, cross-functional teams may require owner-level access for collaboration. Maintain a list of such collaborations and review them periodically to ensure they remain necessary and authorized.
+
+### Response and remediation
+
+- Immediately revoke the admin privileges of the newly added GitHub owner to prevent further unauthorized access.
+- Conduct a thorough review of recent changes and activities performed by the unauthorized owner to identify any potential data breaches or malicious actions.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
+- Reset credentials and enforce multi-factor authentication for all existing GitHub organization owners to enhance security.
+- Review and update access control policies to ensure that owner roles are granted only to verified and necessary personnel.
+- Implement additional monitoring and alerting for any future changes to GitHub organization roles to detect similar threats promptly.
+- If evidence of compromise is found, consider engaging with a digital forensics team to assess the full impact and scope of the breach."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/github/persistence_organization_owner_role_granted.toml b/rules/integrations/github/persistence_organization_owner_role_granted.toml
index fae3507ce48..43877014ef6 100644
--- a/rules/integrations/github/persistence_organization_owner_role_granted.toml
+++ b/rules/integrations/github/persistence_organization_owner_role_granted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,39 @@ type = "eql"
 query = '''
 iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Owner Role Granted To User
+
+In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating privileges to maintain persistence or exfiltrate data. The detection rule monitors audit logs for changes in member roles to 'admin', signaling potential unauthorized access or privilege escalation attempts, thus aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event where the member's role was changed to 'admin' to identify the user who made the change and the user who received the new role.
+- Verify the legitimacy of the role change by contacting the user who was granted the owner role and the user who performed the action to confirm if the change was authorized.
+- Check the organization's recent activity logs for any unusual or suspicious actions performed by the user who was granted the owner role, such as changes to repository settings or data access.
+- Investigate any recent changes in the organization's membership or permissions that could indicate a broader compromise or unauthorized access.
+- Assess the potential impact of the role change by identifying sensitive repositories or data that the new owner role could access, and determine if any data exfiltration or unauthorized changes have occurred.
+
+### False positive analysis
+
+- Role changes due to organizational restructuring or legitimate promotions can trigger alerts. Regularly update the list of expected role changes to minimize unnecessary alerts.
+- Automated scripts or integrations that manage user roles might inadvertently trigger the rule. Identify and whitelist these scripts to prevent false positives.
+- Temporary role assignments for project-specific tasks can be mistaken for unauthorized access. Implement a process to document and pre-approve such temporary changes.
+- Changes made by trusted administrators during routine audits or maintenance may be flagged. Maintain a log of scheduled maintenance activities to cross-reference with alerts.
+- Onboarding processes that involve granting admin roles to new employees can generate alerts. Ensure that onboarding procedures are documented and known exceptions are configured in the detection system.
+
+### Response and remediation
+
+- Immediately revoke the owner role from the user account identified in the alert to prevent further unauthorized access or changes.
+- Conduct a thorough review of recent activities performed by the user with the elevated privileges to identify any unauthorized changes or data access.
+- Reset the credentials and enforce multi-factor authentication for the affected user account to secure it against further compromise.
+- Notify the security team and relevant stakeholders about the potential breach and involve them in the investigation and remediation process.
+- Review and update access control policies to ensure that owner roles are granted only through a formal approval process and are regularly audited.
+- Implement additional monitoring and alerting for changes to high-privilege roles within the organization to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
index 5af838db9fc..8e0711f0156 100644
--- a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
+++ b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/21"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,43 @@ interval = "10m"
 language = "eql"
 license = "Elastic License v2"
 name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
+
+Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If shared improperly, these keys can be accessed by unauthorized users, potentially leading to data breaches. Adversaries exploit links with open access to obtain these keys. The detection rule identifies suspicious activities, such as anonymous access to key files, by monitoring file actions and link visibility settings.
+
+### Possible investigation steps
+
+- Review the file activity logs to identify the specific file(s) accessed by the anonymous user, focusing on actions such as "copy", "view", or "download" and the file extensions listed in the query.
+- Check the sharing settings of the accessed file(s) to confirm if they are set to "people_with_link" and assess whether this level of access is appropriate for the file's sensitivity.
+- Investigate the source of the rogue access link by examining any recent changes to the file's sharing settings or any unusual activity in the file's access history.
+- Identify and contact the file owner or relevant stakeholders to verify if the sharing of the file was intentional and authorized.
+- Assess the potential impact of the accessed encryption key(s) by determining what systems or data they protect and evaluate the risk of unauthorized access.
+- Consider revoking or changing the encryption keys if unauthorized access is confirmed to mitigate potential security risks.
+
+### False positive analysis
+
+- Shared project files with encryption keys may trigger alerts if accessed by external collaborators. To manage this, ensure that only trusted collaborators have access and consider using Google Workspace's sharing settings to restrict access to specific users.
+- Automated backup systems that access encryption keys for legitimate purposes might be flagged. Verify the source of access and, if legitimate, create an exception for the backup system's IP address or service account.
+- Internal users accessing encryption keys via shared links for routine tasks could be misidentified as anonymous users. Encourage users to access files through authenticated sessions and adjust monitoring rules to recognize internal IP ranges or user accounts.
+- Third-party integrations that require access to encryption keys might cause false positives. Review the integration's access patterns and whitelist known, secure integrations to prevent unnecessary alerts.
+- Temporary access links for external audits or compliance checks can be mistaken for unauthorized access. Use time-bound access links and document these activities to differentiate them from potential threats.
+
+### Response and remediation
+
+- Immediately revoke access to the specific Google Workspace Drive file by changing its sharing settings to restrict access to only authorized users.
+- Conduct a thorough review of the file's access history to identify any unauthorized access and determine the scope of potential data exposure.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and any potential data compromise.
+- Rotate and replace any encryption keys that were accessed or potentially compromised to prevent unauthorized use.
+- Implement additional monitoring and alerting for similar file types and sharing settings to detect future unauthorized access attempts.
+- Escalate the incident to senior management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
+- Review and update access policies and sharing settings within Google Workspace to ensure that sensitive files are not shared with open access links.
+
+## Setup
 
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
index 35730889fc6..70ede72ca9c 100644
--- a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
+++ b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/30"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "First Time Seen Google Workspace OAuth Login from Third-Party Application"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Time Seen Google Workspace OAuth Login from Third-Party Application
+
+OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access, mimicking legitimate users. The detection rule identifies unusual OAuth logins by monitoring authorization events linked to new third-party applications, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the event details to identify the specific third-party application involved by examining the google_workspace.token.client.id field.
+- Check the google_workspace.token.scope.data field to understand the scope of permissions granted to the third-party application and assess if they align with expected usage.
+- Investigate the user account associated with the OAuth authorization event to determine if there are any signs of compromise or unusual activity.
+- Correlate the timestamp of the OAuth login event with other security logs to identify any concurrent suspicious activities or anomalies.
+- Verify if the third-party application is known and authorized within the organization by consulting with relevant stakeholders or reviewing application whitelists.
+- Assess the risk and impact of the OAuth login by considering the privileges of the user account and the sensitivity of the accessed resources.
+
+### False positive analysis
+
+- New legitimate third-party applications: Users may frequently integrate new third-party applications for productivity or collaboration. To manage this, maintain a whitelist of known and trusted applications and exclude them from triggering alerts.
+- Regular updates to existing applications: Some applications may update their OAuth client IDs during version upgrades. Monitor application update logs and adjust the detection rule to exclude these known updates.
+- Internal development and testing: Organizations developing their own applications may trigger this rule during testing phases. Coordinate with development teams to identify and exclude these internal applications from alerts.
+- Frequent use of service accounts: Service accounts used for automation or integration purposes might appear as new logins. Document and exclude these service accounts from the detection rule to prevent false positives.
+
+### Response and remediation
+
+- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access.
+- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred.
+- Reset the credentials of the affected user and any other users who may have been compromised, ensuring that strong, unique passwords are used.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Implement additional monitoring for the affected user and similar OAuth authorization events to detect any further suspicious activity.
+- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or data exfiltration.
+- Review and update OAuth application permissions and policies to ensure that only trusted applications have access to sensitive data and services.
+
+## Setup
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 ### Important Information Regarding Google Workspace Event Lag Times
 - As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
diff --git a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
index a1022b5fa15..652ba565ac7 100644
--- a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
+++ b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,40 @@ interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Google Workspace Suspended User Account Renewed"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Google Workspace Suspended User Account Renewed
+
+Google Workspace manages user identities and access, crucial for organizational security. Adversaries may exploit the renewal of suspended accounts to regain unauthorized access, bypassing security measures. The detection rule identifies such events by monitoring specific administrative actions, helping analysts spot potential misuse and maintain secure access controls.
+
+### Possible investigation steps
+
+- Review the event logs for the specific action `UNSUSPEND_USER` to identify the user account that was renewed and gather details about the timing and context of the action.
+- Check the identity of the administrator or service account that performed the `UNSUSPEND_USER` action to determine if the action was authorized or if there are signs of account compromise.
+- Investigate the history of the suspended user account to understand why it was initially suspended and assess any potential risks associated with its renewal.
+- Examine recent activity logs for the renewed user account to identify any suspicious behavior or unauthorized access attempts following the account's reactivation.
+- Cross-reference the event with other security alerts or incidents to determine if the renewal is part of a broader pattern of suspicious activity within the organization.
+
+### False positive analysis
+
+- Routine administrative actions may trigger the rule when IT staff unsuspend accounts for legitimate reasons, such as resolving a temporary issue. To manage this, create exceptions for known IT personnel or specific administrative actions that are part of regular account maintenance.
+- Automated processes or scripts that unsuspend accounts as part of a workflow can also lead to false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags associated with the automation.
+- User accounts that are temporarily suspended due to policy violations or inactivity and later reinstated can cause false positives. Implement a review process to verify the legitimacy of these reinstatements and adjust the rule to exclude such cases when they are part of a documented policy.
+
+### Response and remediation
+
+- Immediately review the user account activity logs to determine if any unauthorized actions were taken after the account was unsuspended. Focus on sensitive data access and changes to security settings.
+- Temporarily suspend the user account again to prevent further unauthorized access while the investigation is ongoing.
+- Notify the security team and relevant stakeholders about the potential security incident to ensure coordinated response efforts.
+- Conduct a thorough review of the account's permissions and access levels to ensure they align with the user's current role and responsibilities. Adjust as necessary to follow the principle of least privilege.
+- If malicious activity is confirmed, initiate a password reset for the affected account and any other accounts that may have been compromised.
+- Implement additional monitoring on the affected account and similar accounts to detect any further suspicious activity.
+- Review and update security policies and procedures related to account suspension and reactivation to prevent similar incidents in the future.
+
+## Setup
 
 The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
index 50e54311ef7..ffe59981ec8 100644
--- a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
+++ b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Denied Service Account Request"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Denied Service Account Request
+
+Kubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations.
+
+### Possible investigation steps
+
+- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used.
+- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request.
+- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated.
+- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior.
+- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations.
+- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request.
+
+### False positive analysis
+
+- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use.
+- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities.
+- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions.
+- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities.
+- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests.
+- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account.
+- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation.
+- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required.
+- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents.
+- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
index d0589a903d9..db03c051d9e 100644
--- a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
+++ b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/30"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Suspicious Self-Subject Review"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Suspicious Self-Subject Review
+
+Kubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields.
+- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews.
+- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source.
+- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior.
+- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered.
+- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise.
+
+### False positive analysis
+
+- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls.
+- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule.
+- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts.
+- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors.
+
+### Response and remediation
+
+- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster.
+- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts.
+- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely.
+- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
+- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts.
+- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
index 1c134a8e0b8..9506fe0ac92 100644
--- a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
+++ b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/17"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,42 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes User Exec into Pod"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes User Exec into Pod
+
+Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for "kubernetes.audit_logs".
+- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access.
+- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource.
+- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access.
+- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address.
+- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment.
+
+### False positive analysis
+
+- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly.
+- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses.
+- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows.
+- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod.
+- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized.
+- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege.
+- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod.
+- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised.
+- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
index 2fd9df0a9e0..4b2aabf0160 100644
--- a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
+++ b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Anonymous Request Authorized"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Anonymous Request Authorized
+
+Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request.
+- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts.
+- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity.
+- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns.
+- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.
+
+### False positive analysis
+
+- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives.
+- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts.
+- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe.
+- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.
+- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.
+- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.
+- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.
+- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.
+- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.
+- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
index 84e57ae7e00..5c3537f5e6e 100644
--- a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
+++ b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,43 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Exposed Service Created With Type NodePort"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Exposed Service Created With Type NodePort
+
+Kubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is "services" and kubernetes.audit.verb is "create", "update", or "patch".
+- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized.
+- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name.
+- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally.
+- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception.
+- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent.
+
+### False positive analysis
+
+- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly.
+- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters.
+- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts.
+- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms.
+- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period.
+
+### Response and remediation
+
+- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception.
+- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service.
+- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service.
+- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed.
+- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture.
+- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited.
+- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
index 6b67122e530..76d953a1684 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,43 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostIPC"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Pod Created With HostIPC
+
+Kubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs".
+- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request.
+- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation.
+- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list.
+- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk.
+- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited.
+
+### False positive analysis
+
+- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function.
+- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening.
+- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts.
+- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process.
+- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary.
+- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications.
+- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification.
+- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms.
+- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred.
+- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved.
+- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
index e1e7005a68c..1cae4551d6b 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,41 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostNetwork"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Pod Created With HostNetwork
+
+Kubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action.
+- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like "docker.elastic.co/beats/elastic-agent:8.4.0".
+- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts.
+- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged.
+- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks.
+
+### False positive analysis
+
+- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule.
+- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces.
+- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios.
+- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one.
+- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access.
+- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities.
+- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network.
+- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated.
+- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats.
+- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
index 49a1dec6249..0ac43d24b60 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,43 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod Created With HostPID"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Pod Created With HostPID
+
+Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action.
+- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed.
+- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision.
+- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved.
+- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set.
+- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered.
+
+### False positive analysis
+
+- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list.
+- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts.
+- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames.
+- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria.
+- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary.
+- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods.
+- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry.
+- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities.
+- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker.
+- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
index 20c8c18652f..8ef13294ac4 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/11"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,43 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Pod created with a Sensitive hostPath Volume"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Pod created with a Sensitive hostPath Volume
+
+Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs".
+- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path.
+- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision.
+- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories.
+- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment.
+- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data.
+
+### False positive analysis
+
+- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads.
+- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image.
+- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening.
+- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods.
+- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary.
+- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources.
+- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise.
+- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image.
+- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod.
+- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities.
+- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
index f1f93659d1d..2b97c237a44 100644
--- a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,41 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Privileged Pod Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Privileged Pod Created
+
+Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats.
+
+### Possible investigation steps
+
+- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields.
+- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious.
+- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation.
+- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments.
+- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod.
+
+### False positive analysis
+
+- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts.
+- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production.
+- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list.
+- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods.
+- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis.
+- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges.
+- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources.
+- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod.
+- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement.
+- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
index 051c4b214e9..c8cabc87d9b 100644
--- a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,43 @@ index = ["logs-kubernetes.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Suspicious Assignment of Controller Service Account"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kubernetes Suspicious Assignment of Controller Service Account
+
+Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller".
+- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.
+- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.
+- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.
+- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.
+- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies.
+
+### False positive analysis
+
+- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates.
+- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts.
+- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments.
+- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening.
+- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing.
+- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.
+- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts.
+- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.
+- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.
+- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly.
+
+## Setup
 
 The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
index 34ee5a28519..8b31089d5c9 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,40 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 High Mean of Process Arguments in an RDP Session
+
+Remote Desktop Protocol (RDP) facilitates remote access to systems, often targeted by adversaries for lateral movement. Attackers may exploit RDP by executing complex commands with numerous arguments to obfuscate their actions. The detection rule leverages machine learning to identify anomalies in process arguments, flagging potential misuse indicative of sophisticated attacks.
+
+### Possible investigation steps
+
+- Review the specific RDP session details, including the source and destination IP addresses, to identify any unusual or unauthorized access patterns.
+- Analyze the process arguments flagged by the machine learning model to determine if they include known malicious commands or patterns indicative of obfuscation or redirection.
+- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or login attempts from unusual locations.
+- Correlate the alert with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities or lateral movement attempts.
+- Investigate the historical behavior of the involved systems and users to determine if the high number of process arguments is an anomaly or part of a regular pattern.
+
+### False positive analysis
+
+- Routine administrative tasks may generate a high number of process arguments, such as batch scripts or automated maintenance operations. Users can create exceptions for known scripts or processes that are regularly executed by trusted administrators.
+- Software updates or installations often involve complex commands with multiple arguments. To mitigate false positives, users should whitelist update processes from trusted vendors.
+- Monitoring and management tools that perform extensive logging or diagnostics can trigger this rule. Users should identify and exclude these tools if they are verified as non-threatening.
+- Custom applications or scripts developed in-house may use numerous arguments for configuration purposes. Users should document and exclude these applications if they are part of normal business operations.
+- Scheduled tasks that run during off-hours might appear suspicious due to their complexity. Users can adjust the rule to ignore these tasks if they are part of a regular, approved schedule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious RDP sessions and associated processes that exhibit high numbers of arguments to halt ongoing malicious activities.
+- Conduct a thorough review of the affected system's event logs and process execution history to identify any unauthorized access or changes made during the RDP session.
+- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent unauthorized access using compromised credentials.
+- Apply security patches and updates to the affected system and any other systems within the network to mitigate vulnerabilities that could be exploited for similar attacks.
+- Enhance monitoring and logging for RDP sessions across the network to detect and respond to similar anomalies more quickly in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
index 0b13d9e762e..817f0cf6740 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 High Mean of RDP Session Duration
+
+Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session lengths.
+- Correlate the flagged RDP session with user activity logs to determine if the session aligns with expected user behavior or if it deviates from normal patterns.
+- Check for any concurrent or subsequent suspicious activities, such as file transfers or command executions, that might indicate lateral movement or data exfiltration.
+- Investigate the source and destination IP addresses involved in the RDP session to identify if they are known, trusted, or associated with any previous security incidents.
+- Analyze the user account involved in the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access patterns.
+- Review any recent changes in the network or system configurations that might have affected RDP session durations or security settings.
+
+### False positive analysis
+
+- Extended RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.
+- Scheduled maintenance or software updates often require prolonged RDP sessions. Exclude these activities by setting time-based exceptions during known maintenance windows.
+- Remote support sessions from trusted third-party vendors may appear as anomalies. Create exceptions for these vendors by verifying their IP addresses and adding them to an allowlist.
+- Training sessions or demonstrations using RDP can result in longer session durations. Document and exclude these events by correlating them with scheduled training times and user accounts involved.
+- Automated scripts or processes that maintain RDP sessions for monitoring purposes can be mistaken for threats. Identify these scripts and exclude their associated user accounts or machine names from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious or unauthorized RDP sessions to cut off potential adversary access.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Monitor network traffic and logs for any signs of further exploitation attempts or related suspicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
index 910d0e198f5..8dfcae92b72 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -53,6 +53,40 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Remote File Size
+Machine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule leverages ML to flag these anomalies, aiding in early detection of potential data exfiltration activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific remote host and file size involved in the anomaly.
+- Check the historical file transfer patterns of the identified remote host to determine if this large file size is truly unusual.
+- Investigate the contents and purpose of the large file, if accessible, to assess whether it contains sensitive or valuable information.
+- Analyze network logs to trace the origin and destination of the file transfer, looking for any unauthorized or suspicious connections.
+- Correlate the event with other security alerts or logs to identify any concurrent suspicious activities that might indicate lateral movement or data exfiltration.
+- Verify the user account associated with the file transfer to ensure it has not been compromised or misused.
+
+### False positive analysis
+
+- Large file transfers related to legitimate business operations, such as backups or data migrations, can trigger false positives. Users should identify and whitelist these routine activities to prevent unnecessary alerts.
+- Software updates or patches distributed across the network may also appear as unusually large file transfers. Establishing a baseline for expected file sizes during these updates can help in distinguishing them from potential threats.
+- Remote file sharing services used for collaboration might generate alerts if large files are shared frequently. Monitoring and excluding these services from the rule can reduce false positives.
+- Automated data processing tasks that involve transferring large datasets between systems should be documented and excluded from the rule to avoid false alarms.
+- Regularly review and update the list of known safe hosts and services that are permitted to transfer large files, ensuring that only legitimate activities are excluded from detection.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat.
+- Conduct a thorough analysis of the large file transfer to determine its contents and origin. Verify if sensitive data was included and assess the potential impact.
+- Review and terminate any unauthorized remote sessions or connections identified during the investigation to prevent further exploitation.
+- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of compromised credentials being used for further attacks.
+- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of similar incidents in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation actions are taken.
+- Enhance monitoring and logging for unusual file transfer activities and remote access attempts to improve early detection of similar threats in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
index 9002606a3a3..05052fda4e6 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 High Variance in RDP Session Duration
+
+Remote Desktop Protocol (RDP) enables remote access to systems, facilitating legitimate administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, often for lateral movement within networks. The detection rule leverages machine learning to identify anomalies in session duration, flagging potential misuse by highlighting sessions with unusually high variance, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session length.
+- Correlate the flagged RDP session with user activity logs to determine if the session aligns with known user behavior or scheduled administrative tasks.
+- Investigate the source and destination IP addresses involved in the RDP session to identify any unusual or unauthorized access points.
+- Check for any concurrent alerts or logs indicating lateral movement or other suspicious activities originating from the same source or targeting the same destination.
+- Analyze the user account associated with the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access times.
+- Review the network traffic during the RDP session for any signs of data exfiltration or communication with known malicious IP addresses.
+
+### False positive analysis
+
+- Long RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.
+- Scheduled maintenance or updates often require extended RDP sessions. Exclude these sessions by setting time-based exceptions during known maintenance windows.
+- Automated scripts or tools that require prolonged RDP access for monitoring or data collection can be mistaken for anomalies. Document and exclude these processes by recognizing their unique session patterns.
+- Remote support sessions from trusted third-party vendors may appear as high variance. Establish a list of trusted vendor IPs or accounts to prevent these from being flagged.
+- Training or demonstration sessions that involve extended RDP use should be accounted for by creating exceptions for specific user groups or departments involved in such activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate the suspicious RDP session to disrupt any ongoing unauthorized activities.
+- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, installed software, and changes to system configurations.
+- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent further unauthorized access.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on RDP connections and lateral movement patterns.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
index 95486b7b141..0252319a055 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Remote File Directory
+
+The 'Unusual Remote File Directory' detection leverages machine learning to identify atypical file transfers in directories not commonly monitored, which may indicate lateral movement by adversaries. Attackers exploit these less scrutinized paths to evade detection, often using remote services to transfer malicious payloads. This rule flags such anomalies, aiding in early detection of potential breaches.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unusual directory involved in the file transfer and note any associated file names or types.
+- Check the source and destination IP addresses involved in the transfer to determine if they are known or trusted entities within the network.
+- Investigate the user account associated with the file transfer to verify if the activity aligns with their typical behavior or role within the organization.
+- Examine recent logs or events from the host to identify any other suspicious activities or anomalies that may correlate with the file transfer.
+- Cross-reference the detected activity with known threat intelligence sources to determine if the file transfer or directory is associated with any known malicious campaigns or tactics.
+- Assess the potential impact of the file transfer by evaluating the sensitivity of the data involved and the criticality of the systems affected.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts if they involve file transfers to directories not typically monitored. Users can create exceptions for known administrative activities to prevent unnecessary alerts.
+- Automated backup processes might be flagged if they store files in uncommon directories. Identifying and excluding these backup operations can reduce false positives.
+- Software updates or patches that deploy files to less common directories could be mistaken for suspicious activity. Users should whitelist these update processes to avoid false alerts.
+- Development or testing environments often involve file transfers to non-standard directories. Users can configure exceptions for these environments to minimize false positives.
+- Legitimate remote services used for file transfers, such as cloud storage synchronization, may be flagged. Users should identify and exclude these trusted services from monitoring.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat. Disconnect it from the network to stop any ongoing malicious activity.
+- Conduct a thorough analysis of the unusual directory and any files transferred to identify malicious payloads. Use endpoint detection and response (EDR) tools to scan for known malware signatures and behaviors.
+- Remove any identified malicious files and artifacts from the affected directory and host. Ensure that all traces of the threat are eradicated to prevent re-infection.
+- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of unauthorized access. Ensure that least privilege principles are enforced.
+- Monitor network traffic and logs for any signs of further lateral movement or exploitation attempts. Pay special attention to remote service connections and unusual directory access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are compromised.
+- Update detection mechanisms and rules to enhance monitoring of less common directories and improve the detection of similar threats in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
index e652d49aef9..dccf3526e38 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -51,6 +51,41 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Remote File Extension
+
+The detection of unusual remote file extensions leverages machine learning to identify anomalies in file transfers, which may suggest lateral movement by adversaries. Attackers often exploit remote services to transfer files with uncommon extensions, bypassing standard security measures. This rule flags such anomalies, aiding in early detection of potential threats by correlating rare file extensions with known lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file extension and the source and destination of the file transfer.
+- Check the historical data for the identified file extension to determine if it has been used previously in legitimate activities or if it is indeed rare.
+- Investigate the source host to identify any recent changes or suspicious activities, such as new user accounts or unusual login patterns.
+- Examine the destination host for any signs of compromise or unauthorized access, focusing on recent file modifications or unexpected processes.
+- Correlate the file transfer event with other security alerts or logs to identify potential patterns of lateral movement or exploitation of remote services.
+- Consult threat intelligence sources to determine if the rare file extension is associated with known malware or adversary tactics.
+
+### False positive analysis
+
+- Common internal file transfers with rare extensions may trigger false positives. Review and whitelist known benign file extensions used by internal applications or processes.
+- Automated backup or synchronization tools might use uncommon file extensions. Identify these tools and create exceptions for their typical file extensions to prevent unnecessary alerts.
+- Development environments often generate files with unique extensions. Collaborate with development teams to understand these patterns and exclude them from detection if they are verified as non-threatening.
+- Security tools or scripts that transfer diagnostic or log files with unusual extensions can be mistaken for lateral movement. Document these tools and adjust the rule to ignore their specific file extensions.
+- Regularly review and update the list of excluded extensions to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat.
+- Review and terminate any suspicious remote sessions or connections identified on the host to cut off unauthorized access.
+- Conduct a thorough scan of the affected system for malware or unauthorized software that may have been transferred using the unusual file extension.
+- Restore the affected system from a known good backup if any malicious activity or compromise is confirmed.
+- Update and patch all software and systems on the affected host to close any vulnerabilities that may have been exploited.
+- Monitor network traffic for any further unusual file transfers or connections, focusing on rare file extensions and remote service exploitation patterns.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
index f2f1c672314..72ccbba305d 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Number of Connections Made from a Source IP
+
+Remote Desktop Protocol (RDP) is a common tool for remote management, but adversaries exploit it for lateral movement within networks. By establishing numerous connections from a single IP, attackers seek to expand their access. This detection rule leverages machine learning to identify unusual spikes in RDP connections, signaling potential unauthorized access attempts, and aids in early threat identification.
+
+### Possible investigation steps
+
+- Review the source IP address to determine if it is a known or trusted entity within the network.
+- Analyze the list of destination IPs to identify any unusual or unauthorized systems being accessed.
+- Check the timestamps of the connections to see if they align with expected activity patterns or occur during unusual hours.
+- Investigate the user account associated with the RDP connections to verify if it has been compromised or is being misused.
+- Correlate the spike in connections with any recent changes or incidents in the network that might explain the activity.
+- Examine network logs and RDP session logs for any signs of suspicious behavior or anomalies during the connection attempts.
+
+### False positive analysis
+
+- Routine administrative tasks can trigger spikes in RDP connections. Regularly scheduled maintenance or software updates may cause a high number of connections from a single IP. To manage this, identify and whitelist IPs associated with known administrative activities.
+- Automated scripts or tools used for network management might establish multiple RDP connections. Review and document these tools, then create exceptions for their IP addresses to prevent false alerts.
+- Load balancers or proxy servers can appear as a single source IP making numerous connections. Verify the network architecture and exclude these IPs from the rule to avoid misidentification.
+- Security scans or vulnerability assessments conducted by internal teams can result in a spike of connections. Coordinate with security teams to recognize these activities and exclude their IPs from triggering the rule.
+- Remote work solutions or VPNs might centralize connections through a single IP, leading to false positives. Identify these IPs and adjust the rule to accommodate legitimate remote access patterns.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or place it in a quarantine VLAN.
+- Terminate any unauthorized RDP sessions originating from the identified source IP to halt ongoing unauthorized access attempts.
+- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, changes in system configurations, and the presence of malware or suspicious files.
+- Reset credentials for any accounts accessed via the compromised system to prevent further unauthorized access using stolen credentials.
+- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for lateral movement.
+- 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.
+- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes, ensuring early detection of future attempts."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
index b155d1cd313..aa4363695b3 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,40 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Number of Connections Made to a Destination IP
+
+Remote Desktop Protocol (RDP) is crucial for remote management and troubleshooting in IT environments. However, adversaries exploit RDP by using multiple compromised IPs to overwhelm a target, ensuring persistence even if some IPs are blocked. The detection rule leverages machine learning to identify unusual spikes in RDP connections to a single IP, signaling potential lateral movement attempts by attackers.
+
+### Possible investigation steps
+
+- Review the list of source IPs that have established RDP connections to the destination IP to identify any known malicious or suspicious IP addresses.
+- Check historical data for the destination IP to determine if it has been targeted in previous attacks or if it is a high-value asset within the network.
+- Analyze the timing and frequency of the RDP connections to identify any unusual patterns or spikes that could indicate coordinated activity.
+- Investigate the user accounts associated with the RDP connections to ensure they are legitimate and have not been compromised.
+- Correlate the detected activity with any other security alerts or logs to identify potential lateral movement or further exploitation attempts within the network.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger false positives if multiple IT staff connect to a server for maintenance. Consider creating exceptions for known administrative IPs.
+- Automated scripts or monitoring tools that frequently connect to servers for health checks can cause spikes. Identify and exclude these IPs from the rule.
+- Load balancers or proxy servers that aggregate connections from multiple clients might appear as a spike. Exclude these devices from the detection rule.
+- Scheduled software updates or deployments that require multiple connections to a server can be mistaken for an attack. Whitelist the IPs involved in these processes.
+- Internal network scans or vulnerability assessments conducted by security teams can generate high connection counts. Ensure these activities are recognized and excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected destination IP from the network to prevent further unauthorized RDP connections and potential lateral movement.
+- Conduct a thorough review of the logs and network traffic associated with the destination IP to identify all source IPs involved in the spike and assess the scope of the compromise.
+- Block all identified malicious source IPs at the firewall or network perimeter to prevent further connections to the destination IP.
+- Reset credentials and enforce multi-factor authentication for accounts that were accessed via RDP to mitigate unauthorized access.
+- Perform a security assessment of the affected systems to identify any signs of compromise or unauthorized changes, and restore systems from clean backups if necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or networks are affected.
+- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes in the future, ensuring quick identification and response to potential threats."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
index 6da8b35fb4b..1881a7cc400 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -51,6 +51,40 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Number of Processes in an RDP Session
+
+Remote Desktop Protocol (RDP) allows users to connect to other computers over a network, facilitating remote work and administration. However, adversaries can exploit RDP for lateral movement by executing numerous processes on a target machine. The detection rule leverages machine learning to identify anomalies in process activity during RDP sessions, flagging potential exploitation attempts indicative of lateral movement tactics.
+
+### Possible investigation steps
+
+- Review the specific RDP session details, including the source and destination IP addresses, to identify the involved machines and users.
+- Analyze the list of processes that were started during the RDP session to identify any unusual or suspicious processes that are not typically associated with legitimate remote work activities.
+- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or unusual login times.
+- Correlate the detected spike in processes with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities.
+- Investigate the network traffic between the source and destination machines during the RDP session to detect any anomalies or unauthorized data transfers.
+- Review historical data for the involved user and machines to determine if similar spikes in process activity have occurred in the past, which could indicate a pattern of malicious behavior.
+
+### False positive analysis
+
+- High-volume automated tasks or scripts executed during RDP sessions can trigger false positives. Identify and document these tasks, then create exceptions in the detection rule to exclude them from analysis.
+- Routine administrative activities, such as software updates or system maintenance, may result in a spike in processes. Regularly review and whitelist these activities to prevent unnecessary alerts.
+- Scheduled batch jobs or data processing tasks that run during RDP sessions can be mistaken for lateral movement. Ensure these are logged and excluded from the rule's scope by setting up appropriate filters.
+- Development or testing environments where multiple processes are frequently started as part of normal operations can lead to false positives. Clearly define these environments and adjust the rule to ignore such sessions.
+
+### Response and remediation
+
+- Isolate the affected machine from the network to prevent further lateral movement and contain the threat.
+- Terminate any suspicious or unauthorized processes identified during the RDP session to halt potential malicious activity.
+- Conduct a thorough review of the affected machine's security logs to identify any additional indicators of compromise or related suspicious activity.
+- Reset credentials for any accounts that were used during the suspicious RDP session to prevent unauthorized access.
+- Apply security patches and updates to the affected machine and any other vulnerable systems to mitigate exploitation of known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Enhance monitoring and detection capabilities for RDP sessions by implementing stricter access controls and logging to detect similar anomalies in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
index 793014dff2b..4ac117d38c3 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -53,6 +53,41 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Remote File Transfers
+
+Remote file transfer technologies facilitate data sharing across networks, essential for collaboration and operations. However, adversaries exploit these to move laterally within a network, often transferring data stealthily to avoid detection. The 'Spike in Remote File Transfers' detection rule leverages machine learning to identify unusual transfer volumes, signaling potential malicious activity by comparing against established network baselines.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and time frame associated with the abnormal file transfer activity.
+- Analyze network logs and remote file transfer logs to determine the source and destination of the transfers, focusing on any unusual or unauthorized endpoints.
+- Cross-reference the identified host with known assets and user accounts to verify if the activity aligns with expected behavior or if it involves unauthorized access.
+- Investigate any associated user accounts for signs of compromise, such as unusual login times or locations, by reviewing authentication logs.
+- Check for any recent changes or anomalies in the network baseline that could explain the spike in file transfers, such as new software deployments or legitimate large data migrations.
+- Correlate the detected activity with other security alerts or incidents to identify potential patterns or coordinated attacks within the network.
+
+### False positive analysis
+
+- Regularly scheduled data backups or synchronization tasks can trigger false positives. Identify these tasks and create exceptions to prevent them from being flagged.
+- Automated software updates or patch management systems may cause spikes in file transfers. Exclude these systems from the rule to reduce false alerts.
+- Internal data sharing between departments for legitimate business purposes might be misidentified. Establish a baseline for these activities and adjust the detection thresholds accordingly.
+- High-volume data transfers during specific business operations, such as end-of-month reporting, can be mistaken for malicious activity. Temporarily adjust the rule settings during these periods to accommodate expected increases in transfer volumes.
+- Frequent file transfers from trusted external partners or vendors should be monitored and, if consistently benign, added to an allowlist to minimize unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat.
+- Conduct a thorough analysis of the transferred files to determine if sensitive data was involved and assess the potential impact of the data exposure.
+- Review and terminate any unauthorized remote access sessions or services on the affected host to prevent further exploitation.
+- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access.
+- Apply security patches and updates to the affected systems to address any vulnerabilities that may have been exploited by the attackers.
+- Monitor network traffic for any additional unusual remote file transfer activities, using enhanced logging and alerting to detect similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
index 91706bb4f63..46c9a8e41c7 100644
--- a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 70
@@ -52,6 +52,41 @@ tags = [
     "Tactic: Lateral Movement",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Time or Day for an RDP Session
+
+Remote Desktop Protocol (RDP) enables remote access to systems, crucial for IT management but also a target for adversaries seeking unauthorized access. Attackers exploit RDP by initiating sessions at odd hours to avoid detection. The detection rule leverages machine learning to identify atypical RDP session timings, flagging potential lateral movement attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the timestamp of the RDP session to determine the specific unusual time or day it was initiated, and correlate it with known business hours or scheduled maintenance windows.
+- Identify the source and destination IP addresses involved in the RDP session to determine if they are internal or external, and check for any known associations with previous security incidents.
+- Examine the user account used to initiate the RDP session, verifying if it is a legitimate account and if the login aligns with the user's typical behavior or role within the organization.
+- Check for any additional suspicious activities or alerts involving the same user account or IP addresses around the time of the unusual RDP session, such as failed login attempts or access to sensitive files.
+- Investigate any recent changes or anomalies in the network or system configurations that could have facilitated the unusual RDP session, such as newly opened ports or modified firewall rules.
+- Consult logs from other security tools or systems, such as SIEM or endpoint detection and response (EDR) solutions, to gather more context on the RDP session and any related activities.
+
+### False positive analysis
+
+- Regular maintenance activities by IT staff during off-hours can trigger false positives. Identify and document these activities to create exceptions in the detection rule.
+- Scheduled automated tasks or scripts that initiate RDP sessions at unusual times may be misclassified. Review and whitelist these tasks to prevent unnecessary alerts.
+- Time zone differences for remote employees accessing systems outside of standard business hours can lead to false positives. Adjust detection parameters to account for these time zone variations.
+- Third-party vendors or contractors who require access at non-standard times should be documented and their access patterns reviewed to establish exceptions.
+- Emergency access situations where IT staff need to respond to critical incidents outside normal hours should be logged and considered when analyzing alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate the suspicious RDP session to halt any ongoing unauthorized activities.
+- Conduct a thorough review of the affected system's logs and processes to identify any malicious activities or changes made during the session.
+- Reset credentials for any accounts accessed during the unusual RDP session to prevent further unauthorized use.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement enhanced monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at unauthorized access."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
index 9cd9d0b4429..9860dbe73d5 100644
--- a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
+++ b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/29"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Gary Blackwell", "Austin Songer"]
@@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Inbox Forwarding Rule Created"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Inbox Forwarding Rule Created
+
+Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to secretly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation of such forwarding rules, focusing on successful events that specify forwarding parameters, thus identifying potential unauthorized email redirection activities.
+
+### Possible investigation steps
+
+- Review the event details to identify the user account associated with the creation of the forwarding rule by examining the o365.audit.Parameters.
+- Check the destination email address specified in the forwarding rule (ForwardTo, ForwardAsAttachmentTo, or RedirectTo) to determine if it is an external or suspicious address.
+- Investigate the user's recent activity logs in Microsoft 365 to identify any unusual or unauthorized actions, focusing on event.dataset:o365.audit and event.provider:Exchange.
+- Verify if the user has a legitimate reason to create such a forwarding rule by consulting with their manager or reviewing their role and responsibilities.
+- Assess if there have been any recent security incidents or alerts related to the user or the destination email address to identify potential compromise.
+- Consider disabling the forwarding rule temporarily and notifying the user and IT security team if the rule appears suspicious or unauthorized.
+
+### False positive analysis
+
+- Legitimate forwarding rules set by users for convenience or workflow purposes may trigger alerts. Review the context of the rule creation, such as the user and the destination address, to determine if it aligns with normal business operations.
+- Automated systems or third-party applications that integrate with Microsoft 365 might create forwarding rules as part of their functionality. Identify these systems and consider excluding their associated accounts from the rule.
+- Temporary forwarding rules set during user absence, such as vacations or leaves, can be mistaken for malicious activity. Implement a process to document and approve such rules, allowing for their exclusion from monitoring during the specified period.
+- Internal forwarding to trusted domains or addresses within the organization might not pose a security risk. Establish a list of trusted internal addresses and configure exceptions for these in the detection rule.
+- Frequent rule changes by specific users, such as IT administrators or support staff, may be part of their job responsibilities. Monitor these accounts separately and adjust the rule to reduce noise from expected behavior.
+
+### Response and remediation
+
+- Immediately disable the forwarding rule by accessing the affected user's mailbox settings in Microsoft 365 and removing any unauthorized forwarding rules.
+- Conduct a thorough review of the affected user's email account for any signs of compromise, such as unusual login activity or unauthorized changes to account settings.
+- Reset the password for the affected user's account and enforce multi-factor authentication (MFA) to prevent further unauthorized access.
+- Notify the user and relevant IT security personnel about the incident, providing details of the unauthorized rule and any potential data exposure.
+- Escalate the incident to the security operations team for further investigation and to determine if other accounts may have been targeted or compromised.
+- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activity or rule changes.
+- Review and update email security policies and configurations to prevent similar incidents, ensuring that forwarding rules are monitored and restricted as necessary.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
index ceb1b377150..a1fb6bacac4 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
@@ -4,7 +4,7 @@ integration = ["o365"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2024/10/09"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Willem D'Haese", "Austin Songer"]
@@ -86,6 +86,41 @@ from logs-o365.audit-*
 // filter for users with more than 20 login sources or failed login attempts
 | where (login_source_count >= 20 or failed_login_count >= 20)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Attempts to Brute Force a Microsoft 365 User Account
+
+Microsoft 365 is a cloud-based service that provides productivity tools and services. Adversaries may attempt to gain unauthorized access by brute-forcing user accounts, exploiting weak passwords. The detection rule identifies such attempts by analyzing audit logs for numerous failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific user identified by o365.audit.UserId to gather additional context on the failed login attempts, including timestamps and source IP addresses.
+- Analyze the source.ip field to identify any unusual or suspicious IP addresses, such as those originating from unexpected geographic locations or known malicious sources.
+- Check the o365.audit.LogonError field for any patterns or specific errors that might provide insight into the nature of the failed login attempts.
+- Investigate the o365.audit.ExtendedProperties.RequestType to determine if the login attempts were consistent with typical user behavior or if they suggest automated or scripted activity.
+- Correlate the findings with other security events or alerts in the environment to assess if the brute-force attempts are part of a larger attack campaign or isolated incidents.
+- Contact the affected user to verify if they experienced any issues accessing their account and to ensure they are aware of the potential security threat.
+
+### False positive analysis
+
+- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery. To mitigate, consider excluding specific users or IP ranges known for such activities.
+- Automated scripts or applications performing frequent logins for legitimate purposes may be misidentified as brute-force attempts. Identify and whitelist these scripts or applications by their user IDs or IP addresses.
+- Users traveling or using VPNs may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exceptions for known travel patterns or VPN IP addresses.
+- Shared accounts accessed by multiple users from different locations can appear as multiple login sources. Limit monitoring on shared accounts or establish a baseline of expected behavior to differentiate between normal and suspicious activity.
+- Temporary spikes in login attempts due to system maintenance or updates can be mistaken for brute-force attacks. Schedule monitoring exclusions during planned maintenance windows to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access attempts.
+- Notify the user and relevant IT security personnel about the potential compromise and provide guidance on secure password creation.
+- Conduct a password reset for the affected user account, ensuring the new password adheres to strong password policies.
+- Review and analyze the source IP addresses involved in the failed login attempts to identify any patterns or known malicious sources.
+- Implement conditional access policies to restrict login attempts from suspicious or untrusted locations and devices.
+- Monitor the affected account and related accounts for any unusual activity or further unauthorized access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional accounts or systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
index 7b2baeefe60..2f554d1dadf 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/01"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/09/05"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,41 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Deprecated - Potential Password Spraying of Microsoft 365 User Accounts"
-note = """This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Deprecated - Potential Password Spraying of Microsoft 365 User Accounts
+
+Microsoft 365 is a cloud-based suite offering productivity and collaboration tools. Adversaries may exploit its authentication mechanisms through password spraying, a technique involving multiple login attempts with common passwords across many accounts. This detection rule identifies such attempts by monitoring failed logins from a single IP, flagging potential unauthorized access efforts.
+
+### Possible investigation steps
+
+- Review the IP address associated with the failed login attempts to determine if it is known or has been flagged in previous incidents.
+- Analyze the event logs for the specific event.dataset:o365.audit to identify patterns or anomalies in the failed login attempts, such as the frequency and timing of the attempts.
+- Check the user accounts targeted by the failed login attempts to assess if they have been compromised or if there are any unusual activities associated with them.
+- Investigate the event.provider field to determine if the attempts were made through Exchange or AzureActiveDirectory, which may provide additional context on the attack vector.
+- Correlate the failed login attempts with other security events or alerts to identify if this is part of a larger attack campaign or if there are other related security incidents.
+
+### False positive analysis
+
+- High volume of legitimate login attempts from a single IP address can trigger false positives, such as when a large organization uses a centralized proxy or VPN. To mitigate, exclude known IP addresses of trusted proxies or VPNs from the rule.
+- Automated scripts or applications performing frequent login checks for service accounts may cause false positives. Identify and whitelist these service accounts to prevent unnecessary alerts.
+- Users with incorrect password storage in password managers may repeatedly attempt logins with outdated credentials. Encourage users to update their stored passwords and consider excluding these accounts if they are known to cause frequent alerts.
+- Security testing or penetration testing activities might mimic password spraying behavior. Coordinate with security teams to schedule these activities and temporarily adjust the rule to avoid false positives during testing periods.
+
+### Response and remediation
+
+- Immediately block the IP address identified in the alert to prevent further unauthorized login attempts.
+- Reset passwords for all user accounts targeted by the failed login attempts to ensure any compromised credentials are no longer valid.
+- Enable multi-factor authentication (MFA) for all affected accounts to add an additional layer of security against unauthorized access.
+- Review and update conditional access policies to restrict login attempts from suspicious or untrusted locations.
+- Notify the security operations team to monitor for any further suspicious activity related to the identified IP address or user accounts.
+- Escalate the incident to the IT security manager for further investigation and to determine if additional resources are needed for a comprehensive response.
+- Conduct a post-incident review to identify any gaps in the current security posture and implement measures to prevent similar attacks in the future.
+
+This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
 risk_score = 73
 rule_id = "3efee4f0-182a-40a8-a835-102c68a4175d"
 severity = "high"
diff --git a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
index f74a123e361..280d82071c7 100644
--- a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
+++ b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Excessive Single Sign-On Logon Errors"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 O365 Excessive Single Sign-On Logon Errors
+
+Single Sign-On (SSO) in O365 streamlines user access by allowing one set of credentials for multiple applications. However, adversaries may exploit this by attempting brute force attacks to gain unauthorized access. The detection rule monitors for frequent SSO logon errors, signaling potential abuse, and helps identify compromised accounts by flagging unusual authentication patterns.
+
+### Possible investigation steps
+
+- Review the specific account(s) associated with the excessive SSO logon errors by examining the event logs filtered by the query fields, particularly focusing on the o365.audit.LogonError field with the value "SsoArtifactInvalidOrExpired".
+- Analyze the timestamps of the logon errors to determine if there is a pattern or specific time frame when the errors are occurring, which might indicate a targeted attack.
+- Check for any recent changes or unusual activities in the affected account(s), such as password changes, unusual login locations, or device changes, to assess if the account might be compromised.
+- Investigate the source IP addresses associated with the logon errors to identify if they are from known malicious sources or unusual locations for the user.
+- Correlate the logon error events with other security alerts or logs from the same time period to identify any related suspicious activities or potential indicators of compromise.
+- Contact the user(s) of the affected account(s) to verify if they experienced any issues with their account access or if they recognize the logon attempts, which can help determine if the activity is legitimate or malicious.
+
+### False positive analysis
+
+- High volume of legitimate user logins: Users who frequently log in and out of multiple O365 applications may trigger excessive logon errors. To manage this, create exceptions for known high-activity accounts.
+- Automated scripts or applications: Some automated processes may use outdated or incorrect credentials, leading to repeated logon errors. Identify and update these scripts to prevent false positives.
+- Password changes: Users who recently changed their passwords might experience logon errors if they have not updated their credentials across all devices and applications. Encourage users to update their credentials promptly.
+- Network issues: Temporary network disruptions can cause authentication errors. Monitor network stability and consider excluding errors during known network maintenance periods.
+- Multi-factor authentication (MFA) misconfigurations: Incorrect MFA settings can lead to logon errors. Verify and correct MFA configurations for affected users to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected account by disabling it to prevent further unauthorized access attempts.
+- Conduct a password reset for the compromised account and enforce a strong password policy to mitigate the risk of future brute force attacks.
+- Review and analyze the account's recent activity logs to identify any unauthorized access or data exfiltration attempts.
+- Implement multi-factor authentication (MFA) for the affected account and other high-risk accounts to add an additional layer of security.
+- Notify the user of the affected account about the incident and provide guidance on recognizing phishing attempts and securing their credentials.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised.
+- Update and enhance monitoring rules to detect similar patterns of excessive SSO logon errors, ensuring early detection of potential brute force attempts.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 73
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
index 77bc6a6dfa9..4df4f2a67dc 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange DLP Policy Removed"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange DLP Policy Removed
+
+Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "Remove-DlpPolicy" to identify the user account responsible for the action.
+- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs.
+- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies.
+- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal.
+- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate.
+- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy.
+
+### False positive analysis
+
+- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy.
+- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window.
+- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities.
+- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions.
+
+### Response and remediation
+
+- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration.
+- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts.
+- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring.
+- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary.
+- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations.
+- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
index ec5a1d9bbc5..e5ade4558ae 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Malware Filter Policy Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Malware Filter Policy Deletion
+
+Microsoft 365 Exchange uses malware filter policies to detect and alert administrators about malware in emails, crucial for maintaining security. Adversaries may delete these policies to bypass detection, facilitating undetected malware distribution. The detection rule monitors audit logs for successful deletions of these policies, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "Remove-MalwareFilterPolicy" to identify the user account responsible for the deletion.
+- Investigate the event.outcome to confirm the success of the policy deletion and gather additional context from related logs.
+- Check the event.provider "Exchange" and event.category "web" to ensure the activity is consistent with expected administrative actions.
+- Assess the recent activity of the identified user account for any unusual behavior or signs of compromise, such as unexpected login locations or times.
+- Examine other security alerts or incidents involving the same user account or related systems to identify potential patterns or coordinated attacks.
+- Verify if there are any recent changes in permissions or roles for the user account that could explain the ability to delete the malware filter policy.
+- Coordinate with IT and security teams to determine if the deletion was authorized or if immediate remediation actions are necessary to restore security controls.
+
+### False positive analysis
+
+- Administrative maintenance activities may trigger the rule if administrators are legitimately updating or removing outdated malware filter policies. To manage this, maintain a log of scheduled maintenance activities and cross-reference with alerts to verify legitimacy.
+- Automated scripts or third-party tools used for policy management might inadvertently delete policies, leading to false positives. Ensure these tools are configured correctly and consider excluding their actions from the rule if they are verified as non-threatening.
+- Changes in organizational policy or security strategy might necessitate the removal of certain malware filter policies. Document these changes and create exceptions in the detection rule for these specific actions to prevent unnecessary alerts.
+- User error during policy management could result in accidental deletions. Implement additional verification steps or approval processes for policy deletions to reduce the likelihood of such errors triggering false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected account or system to prevent further unauthorized actions or malware distribution.
+- Recreate the deleted malware filter policy to restore the email security posture and prevent further evasion attempts.
+- Conduct a thorough review of recent audit logs to identify any other suspicious activities or policy changes that may indicate a broader compromise.
+- Reset passwords and enforce multi-factor authentication for the affected account to secure access and prevent further unauthorized actions.
+- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals a larger threat.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities or attempts to bypass security measures.
+- Review and update security policies and configurations to ensure they are robust against similar evasion tactics in the future.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
index 3a8e0b5063c..49f1d59e2d5 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Malware Filter Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Malware Filter Rule Modification
+
+Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to disable or remove these rules to bypass security measures and facilitate attacks. The detection rule monitors audit logs for successful actions that alter these rules, signaling potential defense evasion tactics. This helps security analysts quickly identify and respond to unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the rule modification.
+- Identify the user account associated with the event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and verify if the action was authorized or expected.
+- Check the event.category:web logs for any related activities around the same timeframe to identify potential patterns or additional suspicious actions.
+- Investigate the event.outcome:success to ensure that the modification was indeed successful and assess the impact on the organization's security posture.
+- Correlate the identified actions with any recent security incidents or alerts to determine if this modification is part of a larger attack or threat campaign.
+- Review the user's recent activity and access logs to identify any other unusual or unauthorized actions that may indicate compromised credentials or insider threat behavior.
+
+### False positive analysis
+
+- Routine administrative changes to malware filter rules by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system.
+- Scheduled maintenance or updates to Microsoft 365 configurations might involve temporary disabling of certain rules. Document these activities and adjust the monitoring system to recognize these as non-threatening.
+- Automated scripts or third-party tools used for system management may perform actions that resemble rule modifications. Ensure these tools are properly documented and their actions are whitelisted if verified as safe.
+- Changes made during incident response or troubleshooting can appear as rule modifications. Coordinate with the incident response team to log these activities and exclude them from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts and systems to prevent further unauthorized modifications to the malware filter rules.
+- Re-enable or recreate the disabled or removed malware filter rules to restore the intended security posture of the Microsoft 365 environment.
+- Conduct a thorough review of recent email traffic and logs to identify any potential malicious content that may have bypassed the filters during the period of rule modification.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised.
+- Implement enhanced monitoring and alerting for any future attempts to modify malware filter rules, ensuring rapid detection and response.
+- Review and update access controls and permissions for administrative actions within Microsoft 365 to limit the ability to modify security configurations to only essential personnel.
+- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
index 9d9933ff325..716701f4dc1 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Safe Attachment Rule Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Safe Attachment Rule Disabled
+
+Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect unknown malware. Disabling this rule can expose organizations to threats by allowing potentially harmful attachments to bypass scrutiny. Adversaries may exploit this to exfiltrate data or avoid detection. The detection rule monitors audit logs for successful attempts to disable this feature, signaling potential defense evasion activities.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "Disable-SafeAttachmentRule" to identify the user or account responsible for the action.
+- Check the event.outcome field to confirm the success of the rule being disabled and gather additional context from related logs around the same timestamp.
+- Investigate the event.provider "Exchange" to determine if there are any other recent suspicious activities or changes made by the same user or account.
+- Assess the event.category "web" to understand if there were any web-based interactions or anomalies that coincide with the disabling of the safe attachment rule.
+- Evaluate the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+- Cross-reference the identified user or account with known insider threat indicators or previous security incidents to assess the likelihood of malicious intent.
+
+### False positive analysis
+
+- Routine administrative changes can trigger alerts when IT staff disable Safe Attachment rules for legitimate reasons, such as testing or maintenance. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or third-party tools used for email management might disable Safe Attachment rules as part of their operations. Identify these tools and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses.
+- Changes in organizational policy or security configurations might necessitate temporary disabling of Safe Attachment rules. Document these policy changes and adjust the monitoring rules to account for these temporary exceptions.
+- Training or onboarding sessions for new IT staff might involve disabling Safe Attachment rules as part of learning exercises. Ensure these activities are logged and excluded from alerts by setting up temporary exceptions for training periods.
+
+### Response and remediation
+
+- Immediately re-enable the Safe Attachment Rule in Microsoft 365 to restore the security posture and prevent further exposure to potentially harmful attachments.
+- Conduct a thorough review of recent email logs and quarantine any suspicious attachments that were delivered during the period the rule was disabled.
+- Isolate any systems or accounts that interacted with suspicious attachments to prevent potential malware spread or data exfiltration.
+- Escalate the incident to the security operations team for further investigation and to determine if there was any unauthorized access or data compromise.
+- Implement additional monitoring on the affected accounts and systems to detect any signs of ongoing or further malicious activity.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify security rules and configurations.
+- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing alerting mechanisms for critical security rule changes.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
index c702bee9a9c..1eab3695794 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/13"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Mailbox Audit Logging Bypass"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 O365 Mailbox Audit Logging Bypass
+
+In Microsoft 365 environments, mailbox audit logging is crucial for tracking user activities like accessing or deleting emails. However, administrators can exempt certain accounts from logging to reduce noise, which attackers might exploit to hide their actions. The detection rule identifies successful attempts to create such exemptions, signaling potential misuse of this bypass mechanism.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the presence of the Set-MailboxAuditBypassAssociation action.
+- Identify the account associated with the event.action Set-MailboxAuditBypassAssociation and verify if it is a known and authorized account for creating audit bypass associations.
+- Check the event.outcome field to ensure the action was successful and determine if there are any other related unsuccessful attempts that might indicate trial and error by an attacker.
+- Investigate the history of the account involved in the bypass association to identify any unusual or suspicious activities, such as recent changes in permissions or unexpected login locations.
+- Cross-reference the account with any known third-party tools or lawful monitoring accounts to determine if the bypass is legitimate or potentially malicious.
+- Assess the risk and impact of the bypass by evaluating the types of activities that would no longer be logged for the account in question, considering the organization's security policies and compliance requirements.
+
+### False positive analysis
+
+- Authorized third-party tools may generate a high volume of mailbox audit log entries, leading to bypass associations being set. Review and document these tools to ensure they are legitimate and necessary for business operations.
+- Accounts used for lawful monitoring might be exempted from logging to reduce noise. Verify that these accounts are properly documented and that their activities align with organizational policies.
+- Regularly review the list of accounts with bypass associations to ensure that only necessary and approved accounts are included. Remove any accounts that no longer require exemptions.
+- Implement a process for periodically auditing bypass associations to detect any unauthorized changes or additions, ensuring that only intended accounts are exempted from logging.
+- Consider setting up alerts for any new bypass associations to quickly identify and investigate potential misuse or unauthorized changes.
+
+### Response and remediation
+
+- Immediately isolate the account associated with the successful Set-MailboxAuditBypassAssociation event to prevent further unauthorized actions.
+- Review and revoke any unauthorized mailbox audit bypass associations to ensure all relevant activities are logged.
+- Conduct a thorough audit of recent activities performed by the affected account to identify any suspicious or malicious actions that may have been concealed.
+- Reset credentials for the compromised account and any other accounts that may have been affected to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring for similar bypass attempts to enhance detection capabilities and prevent recurrence.
+- Consider escalating the incident to a higher security tier or external cybersecurity experts if the scope of the breach is extensive or if internal resources are insufficient to handle the threat.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://twitter.com/misconfig/status/1476144066807140355"]
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
index b000de68c75..7c3d6863c66 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Transport Rule Creation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Transport Rule Creation
+
+Microsoft 365 Exchange transport rules automate email handling, applying actions like forwarding or blocking based on conditions. While beneficial for managing communications, adversaries can exploit these rules to redirect emails externally, facilitating data exfiltration. The detection rule monitors successful creation of new transport rules, flagging potential misuse by identifying specific actions and outcomes in audit logs.
+
+### Possible investigation steps
+
+- Review the audit logs for the event.dataset:o365.audit to identify the user account responsible for creating the new transport rule.
+- Examine the event.provider:Exchange and event.category:web fields to confirm the context and source of the rule creation.
+- Investigate the event.action:"New-TransportRule" to understand the specific conditions and actions defined in the newly created transport rule.
+- Check the event.outcome:success to ensure the rule creation was completed successfully and assess if it aligns with expected administrative activities.
+- Analyze the transport rule settings to determine if it includes actions that forward emails to external domains, which could indicate potential data exfiltration.
+- Correlate the findings with other security events or alerts to identify any patterns or anomalies that might suggest malicious intent.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when IT staff create or modify transport rules for legitimate purposes. To manage this, establish a baseline of expected rule creation activities and exclude these from alerts.
+- Automated systems or third-party applications that integrate with Microsoft 365 might create transport rules as part of their normal operation. Identify these systems and create exceptions for their known actions.
+- Changes in organizational policies or email handling procedures can lead to legitimate rule creations. Document these changes and update the monitoring system to recognize them as non-threatening.
+- Regular audits or compliance checks might involve creating temporary transport rules. Coordinate with audit teams to schedule these activities and temporarily adjust alert thresholds or exclusions during these periods.
+
+### Response and remediation
+
+- Immediately disable the newly created transport rule to prevent further unauthorized email forwarding or data exfiltration.
+- Conduct a thorough review of the audit logs to identify any other suspicious transport rules or related activities that may indicate a broader compromise.
+- Isolate the affected user accounts or systems associated with the creation of the transport rule to prevent further unauthorized access or actions.
+- Reset passwords and enforce multi-factor authentication for the affected accounts to secure access and prevent recurrence.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of a broader compromise or if sensitive data has been exfiltrated.
+- Implement enhanced monitoring and alerting for transport rule changes to detect and respond to similar threats more effectively in the future.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
index 1d3f8d6595f..143915de013 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Transport Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Transport Rule Modification
+
+Microsoft 365 Exchange transport rules manage email flow by setting conditions and actions for messages. Adversaries may exploit these rules to disable or delete them, facilitating data exfiltration or bypassing security measures. The detection rule monitors audit logs for successful execution of commands that alter these rules, signaling potential misuse and enabling timely investigation.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the "Remove-TransportRule" or "Disable-TransportRule" actions.
+- Identify the user account associated with the event by examining the user information in the audit logs to determine if the action was performed by an authorized individual or a potential adversary.
+- Check the event.category:web context to understand if the action was performed through a web interface, which might indicate a compromised account or unauthorized access.
+- Investigate the event.outcome:success to ensure that the rule modification was indeed successful and not an attempted action.
+- Correlate the timing of the rule modification with other security events or alerts to identify any concurrent suspicious activities that might suggest a broader attack or data exfiltration attempt.
+- Assess the impact of the rule modification by reviewing the affected transport rules to determine if they were critical for security or compliance, and evaluate the potential risk to the organization.
+
+### False positive analysis
+
+- Routine administrative changes to transport rules by IT staff can trigger alerts. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these users in the monitoring system.
+- Scheduled maintenance or updates to transport rules may result in false positives. Document these activities and adjust the monitoring system to temporarily exclude these events during known maintenance windows.
+- Automated scripts or third-party tools that manage transport rules might cause alerts. Identify these tools and their typical behavior, then configure the monitoring system to recognize and exclude these benign actions.
+- Changes made as part of compliance audits or security assessments can be mistaken for malicious activity. Coordinate with audit teams to log these activities separately and adjust the monitoring system to account for these legitimate changes.
+
+### Response and remediation
+
+- Immediately disable any compromised accounts identified in the audit logs to prevent further unauthorized modifications to transport rules.
+- Revert any unauthorized changes to transport rules by restoring them to their previous configurations using backup data or logs.
+- Conduct a thorough review of all transport rules to ensure no additional unauthorized modifications have been made, and confirm that all rules align with organizational security policies.
+- Implement additional monitoring on the affected accounts and transport rules to detect any further suspicious activities or attempts to modify rules.
+- Escalate the incident to the security operations team for a deeper investigation into potential data exfiltration activities and to assess the scope of the breach.
+- Coordinate with legal and compliance teams to determine if any regulatory reporting is required due to potential data exfiltration.
+- Enhance security measures by enabling multi-factor authentication (MFA) for all administrative accounts and reviewing access permissions to ensure the principle of least privilege is enforced.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
index ad5ac070602..84c109beb45 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2023/06/22"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -13,7 +13,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Mass download by a single user"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Mass download by a single user
+
+Microsoft 365 provides cloud-based productivity tools, enabling users to access and download data efficiently. However, adversaries can exploit this by performing mass downloads to exfiltrate sensitive information. The detection rule identifies suspicious activity by flagging instances where a user downloads an unusually high volume of data in a short period, indicating potential data exfiltration attempts. This helps security analysts quickly respond to and mitigate potential threats.
+
+### Possible investigation steps
+
+- Review the user's activity logs in Microsoft 365 to confirm the mass download event, focusing on the event.dataset:o365.audit and event.provider:SecurityComplianceCenter fields to ensure the event is accurately captured.
+- Check the user's recent login history and IP addresses to identify any unusual access patterns or locations that could indicate unauthorized access.
+- Analyze the specific files or data downloaded by the user to assess the sensitivity and potential impact of the data exfiltration.
+- Contact the user to verify if the downloads were legitimate and authorized, and gather any additional context or explanations for the activity.
+- Investigate any recent changes to the user's account permissions or roles that might have facilitated the mass download, ensuring that access controls are appropriately configured.
+- Review any related alerts or incidents in the security information and event management (SIEM) system to identify potential correlations or patterns with other suspicious activities.
+
+### False positive analysis
+
+- High-volume legitimate business operations may trigger the rule. Identify and whitelist users or departments known for frequent large data transfers, such as data analysts or IT personnel, to prevent unnecessary alerts.
+- Automated backup or synchronization tools can cause mass downloads. Review and exclude these activities by identifying the specific user accounts or applications involved in regular backup processes.
+- Software updates or deployments might result in mass downloads. Monitor and exclude these events by correlating them with scheduled maintenance windows or deployment activities.
+- Training or onboarding sessions that require downloading large amounts of data can be mistaken for suspicious activity. Coordinate with HR or training departments to anticipate and exclude these events from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further data exfiltration. This can be done by disabling the account or changing the password.
+- Review the downloaded files to assess the sensitivity and potential impact of the data exfiltrated. This will help in understanding the scope of the breach.
+- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and compliance with any regulatory requirements.
+- Conduct a thorough investigation to determine if the mass download was authorized or if it indicates a compromised account. This may involve checking for unusual login locations or times.
+- If the account is confirmed to be compromised, perform a full security audit of the affected user's activities and any other potentially impacted systems.
+- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activities.
+- Review and update access controls and data download policies to prevent similar incidents in the future, ensuring that only necessary permissions are granted to users.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
index d249e245d1a..d693a90178b 100644
--- a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
+++ b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -21,7 +21,44 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Potential ransomware activity"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Potential ransomware activity
+
+Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics.
+
+### Possible investigation steps
+
+- Review the event details in the Microsoft Cloud App Security console to confirm the specific files and user involved in the "Potential ransomware activity" alert.
+- Check the event.dataset field for o365.audit logs to gather additional context about the user's recent activities and any other related events.
+- Investigate the event.provider field to ensure the alert originated from the SecurityComplianceCenter, confirming the source of the detection.
+- Analyze the event.category field to verify that the activity is categorized as web, which may indicate the method of file upload.
+- Assess the user's recent activity history and permissions to determine if the upload was intentional or potentially malicious.
+- Contact the user to verify the legitimacy of the uploaded files and gather any additional context or explanations for the activity.
+- If the files are confirmed or suspected to be malicious, initiate a response plan to contain and remediate any potential ransomware threat, including isolating affected systems and notifying relevant stakeholders.
+
+### False positive analysis
+
+- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files.
+- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses.
+- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives.
+- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening activities are excluded, maintaining the balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment.
+- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution.
+- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity.
+- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity, leveraging MITRE ATT&CK techniques for guidance.
+- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware.
+- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents.
+- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
index 91ff9f58844..75a2ac3f0fe 100644
--- a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
+++ b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -13,7 +13,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Unusual Volume of File Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Unusual Volume of File Deletion
+
+Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:"Unusual volume of file deletion" and event.outcome:success.
+- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times.
+- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities.
+- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise.
+- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity.
+- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files.
+
+### False positive analysis
+
+- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame.
+- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts.
+- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly.
+- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes.
+- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password.
+- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available.
+- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach.
+- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities.
+- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions.
+- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
index 19722674349..65239ea08fc 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Anti-Phish Policy Deletion"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Anti-Phish Policy Deletion
+
+Microsoft 365's anti-phishing policies enhance security by fine-tuning detection settings to thwart phishing attacks. Adversaries may delete these policies to weaken defenses, facilitating unauthorized access. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity by identifying specific actions and outcomes associated with policy removal.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "Remove-AntiPhishPolicy" to identify the user account responsible for the deletion.
+- Check the event.outcome field to confirm the success of the policy deletion and gather additional context from related logs around the same timestamp.
+- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies, such as unusual login locations or times.
+- Assess whether the user account has been compromised by checking for any unauthorized access attempts or changes in account settings.
+- Evaluate the impact of the deleted anti-phishing policy by reviewing the organization's current phishing protection measures and any recent phishing incidents.
+- Coordinate with the IT security team to determine if the policy deletion was authorized or part of a legitimate change management process.
+
+### False positive analysis
+
+- Routine administrative actions may trigger the rule if IT staff regularly update or remove outdated anti-phishing policies. To manage this, create exceptions for known administrative accounts performing these actions.
+- Scheduled policy reviews might involve the removal of policies as part of a legitimate update process. Document these schedules and exclude them from triggering alerts by setting time-based exceptions.
+- Automated scripts used for policy management can inadvertently cause false positives. Identify and whitelist these scripts to prevent unnecessary alerts.
+- Changes in organizational policy that require the removal of certain anti-phishing policies can be mistaken for malicious activity. Ensure that such changes are communicated and logged, and adjust the rule to recognize these legitimate actions.
+- Test environments where policies are frequently added and removed for validation purposes can generate false positives. Exclude these environments from the rule to avoid confusion.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts and systems to prevent further unauthorized access or data exfiltration.
+- Recreate the deleted anti-phishing policy using the latest security guidelines and ensure it is applied across all relevant user groups.
+- Conduct a thorough review of recent email activity and logs for the affected accounts to identify any phishing emails that may have bypassed security measures.
+- Reset passwords for affected accounts and enforce multi-factor authentication (MFA) to enhance account security.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of broader compromise or if sensitive data has been accessed.
+- Implement enhanced monitoring and alerting for similar actions in the future to quickly detect and respond to any further attempts to delete security policies.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
index 71db20bf46d..cf514c9ade5 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Anti-Phish Rule Modification"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Anti-Phish Rule Modification
+
+Microsoft 365's anti-phishing rules are crucial for safeguarding users against phishing attacks by enhancing detection and prevention settings. Adversaries may attempt to modify or disable these rules to facilitate phishing campaigns, gaining unauthorized access. The detection rule monitors for successful modifications or disabling of anti-phishing rules, signaling potential malicious activity by tracking specific actions within the Exchange environment.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the context of the alert.
+- Check the event.action field for "Remove-AntiPhishRule" or "Disable-AntiPhishRule" to identify the specific action taken on the anti-phishing rule.
+- Verify the event.outcome field to ensure the action was successful, indicating a potential security concern.
+- Identify the user or account associated with the modification by examining the relevant user fields in the event log.
+- Investigate the user's recent activity and access patterns to determine if there are any other suspicious actions or anomalies.
+- Assess the impact of the rule modification by reviewing any subsequent phishing attempts or security incidents that may have occurred.
+- Consider reverting the changes to the anti-phishing rule and implementing additional security measures if unauthorized access is confirmed.
+
+### False positive analysis
+
+- Administrative changes: Legitimate administrative tasks may involve modifying or disabling anti-phishing rules for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Security audits: Regular security audits might require temporary adjustments to anti-phishing rules. Document these activities and exclude them from alerts by correlating with audit logs.
+- Third-party integrations: Some third-party security tools may interact with Microsoft 365 settings, triggering rule modifications. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers.
+- Policy updates: Organizational policy changes might necessitate updates to anti-phishing rules. Ensure these changes are documented and exclude them from alerts by associating them with approved change management processes.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access and potential spread of phishing attacks.
+- Revert any unauthorized changes to the anti-phishing rules by restoring them to their previous configurations using backup or documented settings.
+- Conduct a thorough review of recent email logs and user activity to identify any potential phishing emails that may have bypassed the modified rules and take steps to quarantine or delete them.
+- Notify the security team and relevant stakeholders about the incident, providing details of the rule modification and any identified phishing attempts.
+- Escalate the incident to the incident response team for further investigation and to determine if additional systems or data have been compromised.
+- Implement enhanced monitoring and alerting for any further attempts to modify anti-phishing rules, ensuring that similar activities are detected promptly.
+- Review and update access controls and permissions for administrative actions within Microsoft 365 to ensure that only authorized personnel can modify security settings.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
index c0734782b56..72e6d898831 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Safe Link Policy Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Safe Link Policy Disabled
+
+Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats, even post-delivery. Disabling these policies can expose users to phishing attacks. Adversaries might exploit this by disabling Safe Links to facilitate malicious link delivery. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event.dataset:o365.audit and event.provider:Exchange to confirm the occurrence of the "Disable-SafeLinksRule" action with a successful outcome.
+- Identify the user account associated with the event.action:"Disable-SafeLinksRule" to determine if the action was performed by an authorized individual or if the account may have been compromised.
+- Check the recent activity of the identified user account for any unusual or unauthorized actions that could indicate a broader security incident.
+- Investigate any recent changes to Safe Link policies in the Microsoft 365 environment to understand the scope and impact of the policy being disabled.
+- Assess whether there have been any recent phishing attempts or suspicious emails delivered to users, which could exploit the disabled Safe Link policy.
+- Coordinate with the IT security team to re-enable the Safe Link policy and implement additional monitoring to prevent future unauthorized changes.
+
+### False positive analysis
+
+- Administrative changes: Legitimate administrative actions may involve disabling Safe Link policies temporarily for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Third-party integrations: Some third-party security tools or integrations might require Safe Link policies to be disabled for compatibility reasons. Identify and document these tools, and set up exceptions for their associated actions.
+- Policy updates: During policy updates or migrations, Safe Link policies might be disabled as part of the process. Monitor and document these events, and exclude them from alerts if they match known update patterns.
+- User training sessions: Safe Link policies might be disabled during user training or demonstrations to showcase potential threats. Schedule these sessions and exclude related activities from triggering alerts.
+
+### Response and remediation
+
+- Immediately re-enable the Safe Link policy in Microsoft 365 to restore phishing protection for hyperlinks in documents.
+- Conduct a thorough review of recent email and document deliveries to identify any potentially malicious links that may have been delivered while the Safe Link policy was disabled.
+- Isolate any identified malicious links or documents and notify affected users to prevent interaction with these threats.
+- Investigate the account or process that disabled the Safe Link policy to determine if it was compromised or misused, and take appropriate actions such as password resets or privilege revocation.
+- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are needed to prevent similar incidents.
+- Implement additional monitoring and alerting for changes to Safe Link policies to ensure rapid detection of any future unauthorized modifications.
+- Review and update access controls and permissions related to Safe Link policy management to ensure only authorized personnel can make changes.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
index 50b93ea0d00..d449f41bc45 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2024/09/05"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -16,7 +16,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Impossible travel activity"
-note = """
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Impossible travel activity
+
+Microsoft 365's security features monitor user sign-ins to detect anomalies like impossible travel, where a user appears to log in from geographically distant locations in a short time. Adversaries may exploit compromised credentials to access accounts from unexpected locations. The detection rule identifies such suspicious logins by analyzing audit logs for successful sign-ins flagged as impossible travel, helping to mitigate unauthorized access.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:o365.audit to gather details about the sign-in attempt, including the timestamp, IP addresses, and user account involved.
+- Cross-reference the event.provider:SecurityComplianceCenter logs to identify any additional security alerts or anomalies associated with the same user account or IP addresses.
+- Analyze the event.category:web logs to determine the geographical locations of the sign-ins and assess the feasibility of the travel between these locations within the given timeframe.
+- Investigate the user account's recent activity to identify any other suspicious behavior or unauthorized access attempts, focusing on event.action:"Impossible travel activity".
+- Check the event.outcome:success to confirm that the sign-in was successful and assess the potential impact of the unauthorized access.
+- Contact the user to verify if they were traveling or if they recognize the sign-in activity, and advise them to change their password if the activity is deemed suspicious.
+- Consider implementing additional security measures, such as multi-factor authentication, for the affected user account to prevent future unauthorized access.
+
+### False positive analysis
+
+- Frequent travel by users can trigger false positives. Implement a policy to whitelist known travel patterns for specific users who often travel between the same locations.
+- Use of VPNs or proxy services can result in logins appearing from different geographic locations. Identify and exclude IP addresses associated with trusted VPN services used by your organization.
+- Remote work scenarios where users log in from multiple locations in a short time can be misinterpreted. Establish a baseline for remote work patterns and adjust the rule to accommodate these behaviors.
+- Shared accounts accessed by multiple users from different locations can cause false positives. Consider implementing stricter access controls or transitioning to individual accounts to reduce this risk.
+- Regularly review and update the list of known safe locations and IP addresses to ensure that legitimate activities are not flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security.
+- Review the audit logs for the affected account to identify any unauthorized access or data exfiltration activities and document findings for further analysis.
+- Notify the user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their credentials.
+- Escalate the incident to the security operations team for a thorough investigation to determine the root cause and potential impact.
+- Implement geo-blocking policies to restrict access from high-risk locations that are not relevant to the organization's operations.
+- Update and refine security monitoring rules to enhance detection capabilities for similar suspicious activities in the future.
+
 ## Important
 
 This rule is no longer applicable based on changes to Microsoft Defender for Office 365. Please refer to the following rules for similar detections:
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
index 2f593839be0..adc57f78674 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/09/25"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,41 @@ event.dataset: "o365.audit"
     and not o365.audit.UserId: "Not Available"
     and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Portal Logins from Impossible Travel Locations
+
+Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the login events associated with the specific UserId flagged in the alert to confirm the occurrence of logins from different countries within a short time frame.
+- Check the IP addresses associated with the login events to determine if they are from known or suspicious sources, and verify if they are consistent with the user's typical login behavior.
+- Investigate the user's recent activity in Microsoft 365 to identify any unusual or unauthorized actions that may indicate account compromise.
+- Contact the user to verify if they were traveling or using a VPN service that could explain the login from an unexpected location.
+- Examine any recent changes to the user's account settings or permissions that could suggest unauthorized access or tampering.
+- Review the organization's security logs and alerts for any other suspicious activities or patterns that might correlate with the detected anomaly.
+
+### False positive analysis
+
+- Frequent business travelers may trigger false positives due to legitimate logins from different countries within short time frames. To manage this, create exceptions for users with known travel patterns by whitelisting their accounts or using conditional access policies.
+- Use of VPNs or proxy services can result in logins appearing from different geographic locations. Identify and exclude IP ranges associated with trusted VPN services to reduce false positives.
+- Employees working remotely from different countries may cause alerts. Implement user-based exceptions for remote workers who regularly log in from multiple locations.
+- Automated systems or services that log in from various locations for legitimate reasons can be mistaken for suspicious activity. Exclude these service accounts from the rule to prevent unnecessary alerts.
+- Consider time zone differences that might affect the perceived timing of logins. Adjust the rule's sensitivity to account for legitimate time zone shifts that could appear as impossible travel.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security.
+- Review recent login activity and audit logs for the affected account to identify any unauthorized access or data exfiltration attempts.
+- Notify the user of the suspicious activity and advise them to verify any recent changes or actions taken on their account.
+- Escalate the incident to the security operations team for further investigation and to determine if other accounts or systems have been compromised.
+- Implement geo-blocking for high-risk countries or regions where the organization does not typically conduct business to prevent similar unauthorized access attempts.
+- Update and refine security monitoring rules to enhance detection of similar anomalous login patterns in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
index 7edab168de5..9179fefe59d 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/09/25"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,42 @@ event.dataset: "o365.audit"
     and not o365.audit.UserId: "Not Available"
     and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Portal Login from Rare Location
+
+Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon locations, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access attempts by analyzing login events and user location patterns.
+
+### Possible investigation steps
+
+- Review the login event details from the o365.audit dataset to confirm the user's identity and the timestamp of the login.
+- Analyze the location data associated with the login event to determine if it is indeed rare or unusual for the user's typical access patterns.
+- Check the user's recent login history to identify any other logins from the same rare location or any other unusual locations.
+- Investigate the IP address used during the login to determine if it is associated with known VPN services or suspicious activity.
+- Contact the user to verify if they initiated the login from the rare location or if they are aware of any unauthorized access attempts.
+- Examine any recent changes to the user's account settings or permissions that could indicate compromise or unauthorized access.
+- Correlate this event with other security alerts or logs to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Users traveling frequently may trigger alerts due to logins from new locations. Implement a process to update known travel patterns for these users to reduce false positives.
+- Employees using VPNs for legitimate purposes might appear to log in from rare locations. Maintain a list of approved VPN IP addresses and exclude them from triggering alerts.
+- Remote workers who occasionally connect from different locations can cause false positives. Establish a baseline of expected locations for these users and adjust the detection rule accordingly.
+- Shared accounts accessed by multiple users from different locations can lead to false alerts. Consider monitoring these accounts separately and applying stricter access controls.
+- Temporary relocations, such as business trips or remote work arrangements, may result in unusual login locations. Communicate with users to anticipate these changes and adjust the detection parameters temporarily.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Notify the user and relevant IT security personnel about the suspicious login activity to ensure awareness and initiate further investigation.
+- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) if not already enabled to enhance account security.
+- Review and analyze recent activity logs for the affected account to identify any unauthorized actions or data access that may have occurred.
+- If unauthorized access is confirmed, initiate a security incident response plan, including data breach notification procedures if necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or accounts are compromised.
+- Implement geo-blocking or conditional access policies to restrict access from rare or high-risk locations, reducing the likelihood of similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
index 9eb423152f7..48b799580c2 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 User Restricted from Sending Email"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 User Restricted from Sending Email
+
+Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic.
+
+### Possible investigation steps
+
+- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly.
+- Identify the user account that was restricted by examining the event.action:"User restricted from sending email" and event.outcome:success fields to understand which account triggered the alert.
+- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing.
+- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts.
+- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack.
+
+### False positive analysis
+
+- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns.
+- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits.
+- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate.
+- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed.
+- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions.
+
+### Response and remediation
+
+- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam.
+- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access.
+- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised.
+- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence.
+- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
diff --git a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
index 0b96dcaff21..3d6fbb4b873 100644
--- a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
+++ b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/12"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Email Reported by User as Malware or Phish"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 O365 Email Reported by User as Malware or Phish
+
+Microsoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution.
+
+### Possible investigation steps
+
+- Review the details of the alert triggered by the rule "Email reported by user as malware or phish" in the SecurityComplianceCenter to understand the context and specifics of the reported email.
+- Examine the event dataset from o365.audit to gather additional information about the email, such as sender, recipient, subject line, and any attachments or links included.
+- Correlate the reported email with other security events or alerts to identify any patterns or related incidents that might indicate a broader phishing campaign or malware distribution attempt.
+- Check the user's report against known phishing or malware indicators, such as suspicious domains or IP addresses, using threat intelligence sources to assess the credibility of the threat.
+- Investigate the user's activity following the receipt of the email to determine if any actions were taken that could have compromised the system, such as clicking on links or downloading attachments.
+- Assess the effectiveness of current security controls and awareness training by analyzing how the email bypassed existing defenses and was reported by the user.
+
+### False positive analysis
+
+- User-reported emails from trusted internal senders can trigger false positives. Encourage users to verify the sender's identity before reporting and consider adding these senders to an allowlist if they are consistently flagged.
+- Automated system notifications or newsletters may be mistakenly reported as phishing. Educate users on recognizing legitimate automated communications and exclude these sources from triggering alerts.
+- Emails containing marketing or promotional content from known vendors might be reported as suspicious. Train users to differentiate between legitimate marketing emails and phishing attempts, and create exceptions for verified vendors.
+- Frequent reports of emails from specific domains that are known to be safe can lead to unnecessary alerts. Implement domain-based exceptions for these trusted domains to reduce false positives.
+- Encourage users to provide detailed reasons for reporting an email as suspicious, which can help in refining detection rules and reducing false positives over time.
+
+### Response and remediation
+
+- Isolate the affected email account to prevent further interaction with potentially malicious content and to stop any ongoing unauthorized access.
+- Quarantine the reported email and any similar emails identified in the system to prevent other users from accessing them.
+- Conduct a thorough scan of the affected user's device and network for any signs of malware or unauthorized access, using endpoint detection and response tools.
+- Reset the credentials of the affected user account and any other accounts that may have been compromised to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, to ensure coordinated response efforts.
+- Review and update email filtering and security policies to address any identified gaps that allowed the malicious email to bypass existing controls.
+- Monitor for any further suspicious activity related to the incident, using enhanced logging and alerting mechanisms to detect similar threats in the future.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
index 1e179228799..4f91024caab 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,44 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "OneDrive Malware File Upload"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 OneDrive Malware File Upload
+
+OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement within a network. The detection rule identifies such threats by monitoring OneDrive activities for malware detection events, focusing on file operations flagged by Microsoft's security engine. This proactive approach helps in identifying and mitigating potential breaches.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event dataset is 'o365.audit' and the event provider is 'OneDrive' to ensure the alert is relevant to OneDrive activities.
+- Examine the specific file operation flagged by the event code 'SharePointFileOperation' and action 'FileMalwareDetected' to identify the file in question and understand the nature of the detected malware.
+- Identify the user account associated with the file upload to determine if the account has been compromised or if the user inadvertently uploaded the malicious file.
+- Check the sharing settings of the affected file to assess the extent of exposure and identify any other users or systems that may have accessed the file.
+- Investigate the file's origin and history within the organization to trace how it was introduced into the environment and whether it has been shared or accessed by other users.
+- Review any additional security alerts or logs related to the user account or file to identify potential patterns of malicious activity or further compromise.
+- Coordinate with IT and security teams to isolate the affected file and user account, and initiate remediation steps to prevent further spread of the malware.
+
+### False positive analysis
+
+- Legitimate software updates or patches may be flagged as malware if they are not yet recognized by the security engine. Users should verify the source and integrity of the file and consider adding it to an exception list if confirmed safe.
+- Files containing scripts or macros used for automation within the organization might trigger false positives. Review the file's purpose and origin, and whitelist it if it is a known and trusted internal tool.
+- Shared files from trusted partners or vendors could be mistakenly identified as threats. Establish a process to verify these files with the sender and use exceptions for recurring, verified files.
+- Archived or compressed files that contain known safe content might be flagged due to their format. Decompress and scan the contents separately to confirm their safety before adding exceptions.
+- Files with unusual or encrypted content used for legitimate business purposes may be misclassified. Ensure these files are documented and approved by IT security before excluding them from alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected OneDrive account to prevent further file sharing and potential spread of malware within the organization.
+- Notify the user associated with the account about the detected malware and instruct them to cease any file sharing activities until further notice.
+- Conduct a thorough scan of the affected files using an updated antivirus or endpoint detection and response (EDR) solution to confirm the presence of malware and identify any additional infected files.
+- Remove or quarantine the identified malicious files from OneDrive and any other locations they may have been shared to prevent further access or execution.
+- Review and revoke any shared links or permissions associated with the infected files to ensure no unauthorized access is possible.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if any lateral movement or additional compromise has occurred.
+- Implement enhanced monitoring and alerting for similar OneDrive activities to quickly detect and respond to any future malware uploads or related threats.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
index 4ba15633da1..c9b01a46066 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "SharePoint Malware File Upload"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SharePoint Malware File Upload
+
+SharePoint, a collaborative platform, facilitates file sharing and storage within organizations. Adversaries exploit this by uploading malware, leveraging the platform's sharing capabilities to propagate threats laterally. The detection rule identifies when SharePoint's file scanning engine flags an upload as malicious, focusing on specific audit events to alert security teams of potential lateral movement threats.
+
+### Possible investigation steps
+
+- Review the specific event details in the alert, focusing on the event.dataset, event.provider, event.code, and event.action fields to confirm the alert is related to a SharePoint file upload flagged as malware.
+- Identify the user account associated with the file upload by examining the audit logs and determine if the account has a history of suspicious activity or if it has been compromised.
+- Analyze the file metadata, including the file name, type, and size, to gather more context about the nature of the uploaded file and assess its potential impact.
+- Check the file's sharing permissions and access history to identify other users or systems that may have interacted with the file, assessing the risk of lateral movement.
+- Investigate the source of the file upload, such as the originating IP address or device, to determine if it aligns with known malicious activity or if it is an anomaly for the user.
+- Coordinate with the IT team to isolate affected systems or accounts if necessary, and initiate a response plan to mitigate any potential spread of the malware within the organization.
+
+### False positive analysis
+
+- Legitimate software updates or patches uploaded to SharePoint may be flagged as malware. To handle this, create exceptions for known update files by verifying their source and hash.
+- Internal security tools or scripts used for testing purposes might trigger false positives. Maintain a list of these tools and exclude them from alerts after confirming their legitimacy.
+- Files with encrypted content, such as password-protected documents, can be mistakenly identified as malicious. Implement a process to review and whitelist these files if they are from trusted sources.
+- Large batch uploads from trusted departments, like IT or HR, may occasionally be flagged. Establish a review protocol for these uploads and whitelist them if they are verified as safe.
+- Files with macros or executable content used in legitimate business processes might be detected. Work with relevant departments to identify and exclude these files from alerts after thorough validation.
+
+### Response and remediation
+
+- Immediately isolate the affected SharePoint site or library to prevent further access and sharing of the malicious file. This can be done by restricting permissions or temporarily disabling access to the site.
+- Notify the security operations team and relevant stakeholders about the detected malware to ensure awareness and initiate a coordinated response.
+- Quarantine the identified malicious file to prevent it from being accessed or executed by users. Use SharePoint's built-in capabilities or integrated security tools to move the file to a secure location.
+- Conduct a thorough scan of the affected SharePoint site and connected systems to identify any additional malicious files or indicators of compromise. Use advanced threat detection tools to ensure comprehensive coverage.
+- Review and revoke any unauthorized access or sharing permissions that may have been granted to the malicious file, ensuring that only legitimate users have access to sensitive data.
+- Escalate the incident to the incident response team if there are signs of lateral movement or if the malware has spread to other parts of the network, following the organization's escalation protocols.
+- Implement enhanced monitoring and logging for SharePoint and related services to detect any future attempts to upload or share malicious files, leveraging the specific query fields used in the detection rule.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
index 348964efd89..3d196114b69 100644
--- a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
+++ b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "O365 Exchange Suspicious Mailbox Right Delegation"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 O365 Exchange Suspicious Mailbox Right Delegation
+
+Microsoft 365 Exchange allows users to delegate mailbox access, enabling collaboration by granting permissions like FullAccess, SendAs, or SendOnBehalf. However, adversaries can exploit this by assigning these rights to compromised accounts, facilitating unauthorized access and message manipulation. The detection rule identifies successful permission assignments, excluding system accounts, to flag potential misuse and maintain security integrity.
+
+### Possible investigation steps
+
+- Review the event logs to identify the user account that was granted mailbox permissions, focusing on the user.id field to determine if the account is legitimate or potentially compromised.
+- Examine the o365.audit.Parameters.AccessRights field to confirm the specific permissions granted (FullAccess, SendAs, or SendOnBehalf) and assess the potential impact of these permissions.
+- Investigate the history of the user account that was granted permissions, including recent login activity and any unusual behavior, to identify signs of compromise.
+- Check for any recent changes or anomalies in the mailbox that received the permissions, such as unexpected email forwarding rules or unusual email activity.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns that might indicate a broader security incident.
+
+### False positive analysis
+
+- Delegation for administrative purposes: Regular delegation of mailbox rights for administrative tasks can trigger alerts. To manage this, create exceptions for known administrative accounts that frequently require such permissions.
+- Shared mailbox access: Organizations often use shared mailboxes for collaborative purposes. Identify and exclude these shared mailboxes from the rule to prevent false positives.
+- Temporary project-based access: Temporary access granted for specific projects can be mistaken for suspicious activity. Implement a process to document and whitelist these temporary permissions.
+- Automated system processes: Some automated processes may require mailbox access rights. Review and exclude these processes from the rule to avoid unnecessary alerts.
+- Frequent delegation by specific roles: Certain roles, like executive assistants, may regularly delegate mailbox access. Identify these roles and adjust the rule to accommodate their typical behavior.
+
+### Response and remediation
+
+- Immediately revoke the delegated permissions identified in the alert to prevent further unauthorized access to the mailbox.
+- Conduct a thorough review of the affected mailbox and any associated accounts to identify any unauthorized changes or suspicious activities, such as unexpected email forwarding rules or message deletions.
+- Reset the passwords for the compromised account and any other accounts that may have been affected to prevent further unauthorized access.
+- Notify the affected user(s) and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised.
+- Implement additional monitoring on the affected accounts and mailboxes to detect any further suspicious activities or attempts to re-establish unauthorized access.
+- Review and update access control policies and permissions settings to ensure that only necessary permissions are granted and that they are regularly audited.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 risk_score = 21
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
index 90ef1163536..ebb283e18d1 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange DKIM Signing Configuration Disabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange DKIM Signing Configuration Disabled
+
+DomainKeys Identified Mail (DKIM) is a security protocol that ensures email authenticity by allowing recipients to verify that messages are sent from authorized servers. Disabling DKIM can expose organizations to email spoofing, where attackers impersonate legitimate domains to conduct phishing attacks. The detection rule identifies when DKIM is disabled in Microsoft 365, signaling potential unauthorized changes that could facilitate persistent threats.
+
+### Possible investigation steps
+
+- Review the audit logs in Microsoft 365 to identify the user or service account associated with the event.action "Set-DkimSigningConfig" where o365.audit.Parameters.Enabled is False. This will help determine who or what initiated the change.
+- Check the event.timestamp to establish when the DKIM signing configuration was disabled and correlate this with any other suspicious activities or changes in the environment around the same time.
+- Investigate the event.outcome field to confirm that the action was successful and not a failed attempt, which could indicate a misconfiguration or unauthorized access attempt.
+- Examine the event.provider and event.category fields to ensure that the event is specifically related to Exchange and web actions, confirming the context of the alert.
+- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+- Look into any recent changes in administrative roles or permissions that could have allowed unauthorized users to disable DKIM signing, focusing on persistence tactics as indicated by the MITRE ATT&CK framework reference.
+
+### False positive analysis
+
+- Routine administrative changes: Sometimes, DKIM signing configurations may be disabled temporarily during routine maintenance or updates by authorized IT personnel. To manage this, establish a process to document and approve such changes, and create exceptions in the monitoring system for these documented events.
+- Testing and troubleshooting: IT teams may disable DKIM as part of testing or troubleshooting email configurations. Ensure that these activities are logged and approved, and consider setting up alerts that differentiate between test environments and production environments to reduce noise.
+- Configuration migrations: During migrations to new email systems or configurations, DKIM may be disabled as part of the transition process. Implement a change management protocol that includes notifying the security team of planned migrations, allowing them to temporarily adjust monitoring rules.
+- Third-party integrations: Some third-party email services may require DKIM to be disabled temporarily for integration purposes. Maintain a list of approved third-party services and create exceptions for these specific cases, ensuring that the security team is aware of and has approved the integration.
+
+### Response and remediation
+
+- Immediately re-enable DKIM signing for the affected domain in Microsoft 365 to restore email authenticity and prevent potential spoofing attacks.
+- Conduct a review of recent administrative activities in Microsoft 365 to identify any unauthorized changes or suspicious behavior that may have led to the DKIM configuration being disabled.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized change and potential risks associated with it.
+- Implement additional monitoring on the affected domain and related accounts to detect any further unauthorized changes or suspicious activities.
+- Review and update access controls and permissions for administrative accounts in Microsoft 365 to ensure that only authorized personnel can modify DKIM settings.
+- Escalate the incident to the organization's incident response team for further investigation and to determine if any additional security measures are necessary.
+- Consider implementing additional email security measures, such as SPF and DMARC, to complement DKIM and enhance overall email security posture.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
index d445e6723d7..4c6ac6ae501 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Exchange Management Group Role Assignment"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Exchange Management Group Role Assignment
+
+Microsoft 365 Exchange Management roles define permissions for managing Exchange environments. Adversaries may exploit this by assigning roles to unauthorized users, ensuring persistent access. The detection rule monitors successful role assignments within Exchange, flagging potential unauthorized changes that align with persistence tactics, thus aiding in identifying and mitigating unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the event details to confirm the event.action is "New-ManagementRoleAssignment" and the event.outcome is "success" to ensure the alert is valid.
+- Identify the user account associated with the role assignment by examining the event.dataset and event.provider fields, and verify if the account is authorized to make such changes.
+- Check the history of role assignments for the identified user to determine if there are any patterns of unauthorized or suspicious activity.
+- Investigate the specific management role that was assigned to understand its permissions and potential impact on the environment.
+- Correlate this event with other recent activities from the same user or IP address to identify any additional suspicious behavior or anomalies.
+- Consult with the relevant IT or security teams to verify if the role assignment was part of a legitimate administrative task or change request.
+
+### False positive analysis
+
+- Routine administrative role assignments can trigger alerts. Regularly review and document legitimate role changes to differentiate them from unauthorized activities.
+- Automated scripts or tools used for role management may cause false positives. Identify and whitelist these tools to prevent unnecessary alerts.
+- Changes made during scheduled maintenance windows might be flagged. Establish a process to temporarily suppress alerts during these periods while ensuring post-maintenance reviews.
+- Role assignments related to onboarding or offboarding processes can appear suspicious. Implement a verification step to confirm these changes align with HR records and expected activities.
+- Frequent role changes by specific users with administrative privileges may not indicate malicious intent. Monitor these users' activities and establish a baseline to identify deviations from normal behavior.
+
+### Response and remediation
+
+- Immediately revoke the newly assigned management role from the unauthorized user to prevent further unauthorized access or changes.
+- Conduct a thorough review of recent activity logs for the affected account to identify any suspicious actions taken since the role assignment.
+- Reset the credentials of the compromised account and enforce multi-factor authentication to enhance security.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring on the affected account and similar high-privilege accounts to detect any further unauthorized attempts.
+- Review and update access control policies to ensure that only authorized personnel can assign management roles in Microsoft 365.
+- Consider conducting a security awareness session for administrators to reinforce the importance of monitoring and managing role assignments securely.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
index 821b0bf2f8c..c7e9e7b27b1 100644
--- a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Global Administrator Role Assigned"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Global Administrator Role Assigned
+
+The Microsoft 365 Global Administrator role grants comprehensive administrative access across Azure AD and associated services, enabling full control over resources and settings. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent access and control. The detection rule identifies such unauthorized assignments by monitoring specific audit events, focusing on role changes to "Global Administrator," thus alerting security teams to potential misuse.
+
+### Possible investigation steps
+
+- Review the audit logs for the event dataset "o365.audit" with the event code "AzureActiveDirectory" to identify the specific user who was added to the Global Administrator role.
+- Examine the "event.action" field to confirm the action "Add member to role" and verify the "o365.audit.ModifiedProperties.Role_DisplayName.NewValue" to ensure it is "Global Administrator."
+- Identify the user account that performed the role assignment and assess their recent activities and login history for any signs of compromise or unusual behavior.
+- Check the timestamp of the role assignment event to determine if it aligns with any known maintenance windows or authorized administrative activities.
+- Investigate any associated IP addresses or devices used during the role assignment to determine if they are consistent with the user's typical access patterns or if they indicate potential unauthorized access.
+- Review any recent changes to user permissions or roles within Azure AD to identify if there are other suspicious modifications that could indicate broader unauthorized access attempts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role temporarily for maintenance or configuration changes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
+- Automated scripts or third-party applications that require elevated permissions might be flagged if they are set to assign the Global Administrator role as part of their operation. Review and whitelist these scripts or applications if they are verified as safe and necessary.
+- Organizational changes such as mergers or acquisitions can lead to legitimate role assignments that appear suspicious. Implement a review process for role changes during such periods to differentiate between legitimate and unauthorized assignments.
+- Training or onboarding processes for new IT staff might involve temporary Global Administrator access, which could be misinterpreted as a threat. Establish a protocol for temporary access that includes logging and approval to prevent false positives.
+- Changes in role assignments due to policy updates or compliance requirements can also trigger alerts. Ensure that these changes are documented and communicated to the security team to avoid unnecessary investigations.
+
+### Response and remediation
+
+- Immediately remove the unauthorized user from the Global Administrator role to prevent further unauthorized access and control over resources.
+- Conduct a thorough review of recent changes in Azure AD to identify any other unauthorized role assignments or suspicious activities linked to the compromised account.
+- Reset the credentials of the affected account and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and actions taken to mitigate the threat.
+- Implement conditional access policies to restrict administrative role assignments to trusted locations and devices, reducing the risk of unauthorized changes.
+- Review and update access logs and monitoring configurations to ensure comprehensive visibility into role changes and other critical activities in Azure AD.
+- Conduct a post-incident analysis to identify the root cause of the breach and implement additional security measures to prevent similar incidents in the future.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
index a8da34138b9..830d693b3ac 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams Custom Application Interaction Allowed"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Teams Custom Application Interaction Allowed
+
+Microsoft Teams allows organizations to enhance functionality by integrating custom applications, which can be developed and uploaded beyond the standard app store offerings. While beneficial for tailored solutions, this capability can be exploited by adversaries to maintain unauthorized access. The detection rule monitors changes in tenant settings that permit custom app interactions, flagging successful modifications as potential persistence threats.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: TeamsTenantSettingChanged to identify when the change was made and by whom.
+- Verify the identity of the user or account associated with the event to determine if the change was authorized or if the account may have been compromised.
+- Check the o365.audit.Name field for "Allow sideloading and interaction of custom apps" to confirm that the alert corresponds to enabling custom app interactions.
+- Investigate the o365.audit.NewValue field to ensure it is set to True, indicating that the setting was indeed changed to allow custom apps.
+- Assess the event.outcome field to confirm the change was successful and not a failed attempt, which could indicate a different type of issue.
+- Examine any recent custom applications uploaded to Microsoft Teams to ensure they are legitimate and not potentially malicious.
+- Cross-reference with other security alerts or logs to identify any unusual activity around the time of the setting change that might suggest malicious intent.
+
+### False positive analysis
+
+- Routine administrative changes to Microsoft Teams settings can trigger this rule. If a known and authorized administrator frequently updates tenant settings to allow custom apps, consider creating an exception for their user account to reduce noise.
+- Organizations that regularly develop and deploy custom applications for internal use may see frequent alerts. In such cases, establish a process to document and approve these changes, and use this documentation to create exceptions for specific application deployment activities.
+- Scheduled updates or maintenance activities that involve enabling custom app interactions might be misidentified as threats. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods.
+- If a third-party service provider is authorized to manage Teams settings, their actions might trigger alerts. Verify their activities and, if consistent and legitimate, add their actions to an exception list to prevent unnecessary alerts.
+- Changes made during a known testing or development phase can be mistaken for unauthorized access. Clearly define and communicate these phases to the security team, and consider temporary rule adjustments to accommodate expected changes.
+
+### Response and remediation
+
+- Immediately disable the custom application interaction setting in Microsoft Teams to prevent further unauthorized access or persistence by adversaries.
+- Conduct a thorough review of all custom applications currently uploaded to Microsoft Teams to identify any unauthorized or suspicious applications. Remove any that are not recognized or approved by the organization.
+- Analyze the audit logs for any recent changes to the Teams settings and identify the user account responsible for enabling custom application interactions. Investigate the account for signs of compromise or misuse.
+- Reset the credentials and enforce multi-factor authentication for the account(s) involved in the unauthorized change to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident and the actions taken. Escalate to higher management if the breach is suspected to have wider implications.
+- Implement additional monitoring and alerting for changes to Microsoft Teams settings to quickly detect and respond to similar threats in the future.
+- Review and update the organization's security policies and procedures regarding the use of custom applications in Microsoft Teams to ensure they align with best practices and mitigate the risk of similar incidents.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/deploy-and-publish/apps-upload"]
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
index a47f63526f6..6698454c34a 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams External Access Enabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Teams External Access Enabled
+
+Microsoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "Set-CsTenantFederationConfiguration" to identify when and by whom the external access was enabled.
+- Examine the o365.audit.Parameters.AllowFederatedUsers field to confirm that it is set to True, indicating that external access was indeed enabled.
+- Investigate the user account associated with the event to determine if the action was authorized and if the account has a history of suspicious activity.
+- Check the event.provider field to see if the change was made through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used.
+- Assess the event.outcome field to ensure the action was successful and not a failed attempt, which could indicate a potential security threat.
+- Look into any recent changes in the list of allowed domains to identify if any unauthorized or suspicious domains have been added.
+
+### False positive analysis
+
+- Routine administrative changes to federation settings can trigger alerts. Regularly review and document these changes to differentiate between legitimate and suspicious activities.
+- Organizations with frequent collaboration with external partners may see increased alerts. Consider creating exceptions for known trusted domains to reduce noise.
+- Scheduled updates or policy changes by IT teams might enable external access temporarily. Coordinate with IT to log these activities and exclude them from triggering alerts.
+- Automated scripts or tools used for configuration management can inadvertently enable external access. Ensure these tools are properly documented and monitored to prevent false positives.
+- Changes made during mergers or acquisitions can appear suspicious. Maintain a record of such events and adjust monitoring rules accordingly to account for expected changes.
+
+### Response and remediation
+
+- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains.
+- Review and remove any unauthorized or suspicious domains added to the allowed list in the Teams federation settings.
+- Conduct a thorough audit of recent changes in the Teams configuration to identify any other unauthorized modifications or suspicious activities.
+- Reset credentials and enforce multi-factor authentication for accounts involved in the configuration change to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of data exfiltration or if the scope of the breach is unclear.
+- Implement enhanced monitoring and alerting for changes in Teams federation settings to detect similar threats in the future.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = ["https://docs.microsoft.com/en-us/microsoftteams/manage-external-access"]
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
index cad302f3660..a4a4bcbe761 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Microsoft 365 Teams Guest Access Enabled"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft 365 Teams Guest Access Enabled
+
+Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches.
+
+### Possible investigation steps
+
+- Review the audit logs to confirm the event.action "Set-CsTeamsClientConfiguration" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True.
+- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action.
+- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times.
+- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies.
+- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users.
+- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference.
+
+### False positive analysis
+
+- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access.
+- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts.
+- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts.
+- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives.
+
+### Response and remediation
+
+- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access.
+- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings.
+- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation.
+- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms.
+- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings.
+- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary.
+- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
index 273f81c599d..bf5f8f2bf76 100644
--- a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
+++ b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Austin Songer"]
@@ -14,7 +14,43 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "New or Modified Federation Domain"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 New or Modified Federation Domain
+
+Federation domains enable trust between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions like domain modifications, signaling potential privilege escalation attempts, and alerts analysts to investigate these changes.
+
+### Possible investigation steps
+
+- Review the event logs for the specific actions listed in the query, such as "Set-AcceptedDomain" or "Add-FederatedDomain", to identify the exact changes made to the federation domain settings.
+- Identify the user account associated with the event by examining the event logs, and verify if the account has the necessary permissions to perform such actions.
+- Check the event.outcome field to confirm the success of the action and cross-reference with any recent administrative changes or requests to validate legitimacy.
+- Investigate the event.provider and event.category fields to ensure the actions were performed through legitimate channels and not via unauthorized or suspicious methods.
+- Analyze the timing and frequency of the federation domain changes to detect any unusual patterns or repeated attempts that could indicate malicious activity.
+- Correlate the detected changes with any recent alerts or incidents involving privilege escalation or unauthorized access attempts to assess potential links or broader security implications.
+
+### False positive analysis
+
+- Routine administrative changes to federation domains by IT staff can trigger alerts. To manage this, create exceptions for known and scheduled maintenance activities by trusted administrators.
+- Automated scripts or tools used for domain management may cause false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses.
+- Integration of new services or applications that require federation domain modifications can be mistaken for suspicious activity. Document these integrations and adjust the rule to recognize these legitimate changes.
+- Changes made during organizational restructuring, such as mergers or acquisitions, might appear as unauthorized modifications. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring thresholds or exclusions.
+- Regular audits or compliance checks that involve domain settings adjustments can lead to false positives. Schedule these audits and inform the security team to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately disable any newly added or modified federation domains to prevent unauthorized access. This can be done using the appropriate administrative tools in Office 365.
+- Review and revoke any suspicious or unauthorized access tokens or sessions that may have been issued through the compromised federation domain.
+- Conduct a thorough audit of recent administrative actions and access logs to identify any unauthorized changes or access patterns related to the federation domain modifications.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.
+- Implement additional monitoring on federation domain settings to detect any further unauthorized changes promptly.
+- Communicate with affected stakeholders and provide guidance on any immediate actions they need to take, such as password resets or additional authentication steps.
+- Review and update federation domain policies and configurations to ensure they align with best practices and reduce the risk of similar incidents in the future.
+
+## Setup
 
 The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
index 7feaeba1c62..5678e743fdd 100644
--- a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
+++ b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/11"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -51,6 +51,40 @@ event.dataset: okta.system
     and not okta.debug_context.debug_data.flattened.requestedScopes: ("okta.logs.read" or "okta.eventHooks.read" or "okta.inlineHooks.read")
     and okta.outcome.reason: "no_matching_scope"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials
+
+OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of users. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token grants due to scope mismatches, signaling potential misuse of client credentials.
+
+### Possible investigation steps
+
+- Review the `okta.actor.display_name` field to identify the public client app involved in the failed token grant attempt and determine if it is a known or expected application.
+- Examine the `okta.debug_context.debug_data.flattened.requestedScopes` field to understand which unauthorized scopes were requested and assess their potential impact if accessed.
+- Investigate the `okta.actor.type` field to confirm that the actor is indeed a public client app, which lacks secure storage, and evaluate the risk of compromised credentials.
+- Check the `okta.outcome.reason` field for "no_matching_scope" to verify that the failure was due to a scope mismatch, indicating an attempt to access unauthorized resources.
+- Analyze the `okta.client.user_agent.raw_user_agent` field to ensure the request did not originate from known Okta integrations, which are excluded from the rule, to rule out false positives.
+- Correlate the event with other security logs or alerts to identify any patterns or additional suspicious activities related to the same client credentials or IP address.
+
+### False positive analysis
+
+- Frequent legitimate access attempts by known public client apps may trigger false positives. To manage this, consider creating exceptions for specific `okta.actor.display_name` values that are known to frequently request scopes without malicious intent.
+- Automated processes or integrations that use client credentials might occasionally request scopes not typically associated with their function. Review these processes and, if deemed non-threatening, exclude their `okta.client.user_agent.raw_user_agent` from triggering the rule.
+- Development or testing environments often simulate various OAuth 2.0 token grant scenarios, which can result in false positives. Identify and exclude these environments by their `okta.actor.display_name` or other distinguishing attributes.
+- Regularly review and update the list of non-threatening scopes in `okta.debug_context.debug_data.flattened.requestedScopes` to ensure that legitimate scope requests are not flagged as unauthorized.
+
+### Response and remediation
+
+- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts.
+- Conduct a thorough review of the affected public client app's access logs to identify any successful unauthorized access or data exfiltration attempts.
+- Notify the application owner and relevant security teams about the incident to ensure coordinated response efforts.
+- Implement additional monitoring on the affected app and associated user accounts to detect any further suspicious activities.
+- Update and enforce stricter access controls and scope permissions for public client apps to minimize the risk of unauthorized scope requests.
+- Consider implementing multi-factor authentication (MFA) for accessing sensitive resources to add an additional layer of security.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if broader organizational impacts exist."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
index 816c943f532..a3e7bef86ba 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Delete an Okta Application"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Delete an Okta Application
+
+Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to disrupt operations or weaken security by attempting deletions. The detection rule monitors system events for deletion actions, flagging potential threats with a low-risk score, aiding analysts in identifying and mitigating unauthorized attempts.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.delete to confirm the attempted deletion action.
+- Identify the user account associated with the deletion attempt and verify their role and permissions within the organization to assess if the action was authorized.
+- Check the timestamp of the event to determine if the deletion attempt coincides with any known maintenance windows or authorized changes.
+- Investigate the specific Okta application targeted for deletion to understand its importance and potential impact on business operations if it were successfully deleted.
+- Examine any recent changes or unusual activities associated with the user account or the targeted application to identify potential indicators of compromise.
+- Correlate this event with other security alerts or logs to determine if it is part of a broader attack or isolated incident.
+
+### False positive analysis
+
+- Routine maintenance activities by IT staff may trigger the rule when they legitimately delete or modify applications. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for application lifecycle management might generate false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated user accounts or service accounts.
+- Testing environments where applications are frequently created and deleted for development purposes can lead to false positives. Exclude these environments from monitoring or adjust the rule to ignore actions within specific test domains.
+- Changes in application configurations by authorized personnel for legitimate business needs may be flagged. Implement a process to log and approve such changes, allowing for easy identification and exclusion from alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Okta application to prevent further unauthorized actions. This can be done by temporarily disabling the application or restricting access to it.
+- Review the audit logs and event details associated with the deletion attempt to identify the source of the action, including user accounts and IP addresses involved.
+- Revoke access for any compromised or suspicious user accounts identified in the investigation to prevent further unauthorized actions.
+- Restore the deleted application from backup if applicable, ensuring that all configurations and settings are intact.
+- Notify the security team and relevant stakeholders about the incident, providing details of the attempted deletion and actions taken.
+- Conduct a root cause analysis to determine how the unauthorized attempt was made and implement additional security controls to prevent similar incidents in the future.
+- Enhance monitoring and alerting for Okta application lifecycle events to ensure rapid detection and response to any future unauthorized modification or deletion attempts.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
index 79b5c489099..05c6149972e 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Modify an Okta Application"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Modify an Okta Application
+
+Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to alter, deactivate, or delete them, aiming to compromise security controls or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to preempt potential security breaches.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.update to identify the specific application and user involved in the modification attempt.
+- Verify the user's role and permissions within Okta to determine if they have legitimate access to modify the application.
+- Check for any recent changes in user permissions or roles that might explain the modification attempt.
+- Investigate the history of the application in question to see if there have been any previous unauthorized modification attempts or related security incidents.
+- Correlate the event timestamp with other security logs and alerts to identify any concurrent suspicious activities or patterns that might indicate a broader attack.
+
+### False positive analysis
+
+- Routine administrative updates to Okta applications by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform regular maintenance.
+- Scheduled application updates or maintenance activities may be flagged. Document these activities and adjust the monitoring schedule to avoid unnecessary alerts during these periods.
+- Integration or testing environments often undergo frequent changes. Exclude these environments from monitoring or adjust the rule to focus on production environments only.
+- Automated scripts or tools used for application management might generate false positives. Identify these tools and whitelist their actions to prevent unnecessary alerts.
+- Changes made by third-party vendors or partners with legitimate access can be mistaken for unauthorized attempts. Ensure these entities are properly documented and their actions are accounted for in the monitoring setup.
+
+### Response and remediation
+
+- Immediately isolate the affected Okta application to prevent further unauthorized modifications. This can be done by temporarily disabling the application or restricting access to it.
+- Review and revoke any unauthorized changes made to the application settings. Restore the application to its last known good configuration using backup or audit logs.
+- Conduct a thorough audit of recent access logs to identify any unauthorized users or suspicious activities related to the application lifecycle updates.
+- Escalate the incident to the security operations team for further investigation and to determine if there are any broader security implications or related incidents.
+- Implement additional monitoring on the affected application and similar applications to detect any further unauthorized modification attempts.
+- Review and update access controls and permissions for Okta applications to ensure that only authorized personnel have the ability to modify application settings.
+- Communicate with relevant stakeholders, including IT and security teams, to inform them of the incident and any changes made to the application settings as part of the remediation process.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/impact_possible_okta_dos_attack.toml b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
index 6300d7e24df..203da221f31 100644
--- a/rules/integrations/okta/impact_possible_okta_dos_attack.toml
+++ b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Possible Okta DoS Attack"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Possible Okta DoS Attack
+
+Okta, a leading identity management service, is crucial for managing user access in organizations. Adversaries may exploit Okta by overwhelming it with requests, causing service disruptions. The detection rule identifies potential DoS attacks by monitoring specific Okta system events that indicate rate limit violations, signaling attempts to degrade service availability.
+
+### Possible investigation steps
+
+- Review the specific Okta system events that triggered the alert, focusing on event.action values such as application.integration.rate_limit_exceeded, system.org.rate_limit.warning, system.org.rate_limit.violation, and core.concurrency.org.limit.violation to understand the nature of the rate limit violations.
+- Analyze the frequency and pattern of the triggered events to determine if there is a consistent or unusual spike in requests that could indicate a DoS attack.
+- Identify the source IP addresses or user accounts associated with the excessive requests to determine if they are legitimate users or potential adversaries.
+- Check for any recent changes or updates in the Okta configuration or integrations that might have inadvertently caused an increase in request rates.
+- Correlate the Okta events with other network or application logs to identify any broader patterns or simultaneous attacks on other services that might suggest a coordinated effort.
+
+### False positive analysis
+
+- High-volume legitimate user activity can trigger rate limit warnings. Monitor for patterns of normal usage spikes, such as during company-wide meetings or product launches, and consider setting exceptions for these events.
+- Automated processes or integrations that frequently interact with Okta may cause rate limit violations. Identify these processes and adjust their request rates or set exceptions to prevent false positives.
+- Scheduled batch jobs that access Okta services might exceed rate limits. Review and optimize the scheduling of these jobs to distribute the load more evenly or whitelist them if they are essential and non-disruptive.
+- Third-party applications integrated with Okta could inadvertently cause rate limit issues. Work with vendors to ensure their applications are optimized for Okta's rate limits or create exceptions for trusted applications.
+- Temporary spikes in user activity due to password resets or account provisioning can lead to false positives. Implement monitoring to distinguish between these benign activities and potential threats, and adjust the rule to accommodate expected spikes.
+
+### Response and remediation
+
+- Immediately assess the impact on business operations by checking the availability and performance of Okta services. Coordinate with IT teams to ensure critical services remain operational.
+- Contain the attack by implementing rate limiting or IP blocking for the identified sources of excessive requests. Use network security tools to enforce these restrictions.
+- Notify the security operations center (SOC) and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response efforts.
+- Review and adjust Okta's rate limit settings to mitigate the risk of future DoS attempts, ensuring they align with the organization's typical usage patterns.
+- Escalate the incident to Okta support for further investigation and assistance in mitigating the attack, providing them with relevant logs and event details.
+- Conduct a post-incident analysis to identify any gaps in the current security posture and update incident response plans accordingly.
+- Enhance monitoring and alerting for similar threats by refining detection rules and ensuring they are tuned to capture early indicators of rate limit violations.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
index 7b3bfb33839..0b6e86b3b9b 100644
--- a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
+++ b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -13,7 +13,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Okta FastPass Phishing Detection"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Okta FastPass Phishing Detection
+
+Okta FastPass is a passwordless authentication solution that enhances security by verifying user identity without traditional credentials. Adversaries may attempt to exploit this by directing users to phishing sites mimicking legitimate services. The detection rule identifies failed authentication attempts where FastPass blocks access, indicating a phishing attempt, by analyzing specific event patterns and outcomes.
+
+### Possible investigation steps
+
+- Review the event details to confirm the presence of the specific outcome reason "FastPass declined phishing attempt" to ensure the alert is related to a phishing attempt.
+- Identify the user associated with the failed authentication attempt and gather additional context about their recent activities and access patterns.
+- Investigate the source IP address and geolocation of the failed authentication attempt to determine if it aligns with the user's typical access locations or if it appears suspicious.
+- Check for any other recent authentication attempts from the same user or IP address to identify potential patterns or repeated phishing attempts.
+- Communicate with the affected user to verify if they received any suspicious communications or if they attempted to access any unfamiliar websites around the time of the alert.
+- Review any additional logs or alerts from other security systems that might provide further context or corroborate the phishing attempt.
+
+### False positive analysis
+
+- Legitimate third-party applications that mimic the behavior of phishing sites may trigger false positives. Users can create exceptions for these applications by whitelisting their domains in the Okta FastPass settings.
+- Internal testing environments that simulate phishing scenarios for training purposes might be flagged. To prevent this, ensure that these environments are registered and recognized within the Okta system to avoid unnecessary alerts.
+- Users accessing legitimate services through unusual network paths or VPNs may be mistakenly identified as phishing attempts. Regularly review and update network configurations and trusted IP addresses to minimize these occurrences.
+- Frequent failed authentication attempts due to user error, such as incorrect device settings or outdated software, can be mistaken for phishing. Educate users on maintaining their devices and software to align with Okta FastPass requirements to reduce these false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access attempts. This can be done by temporarily disabling the accounts or enforcing additional authentication measures.
+- Notify the affected users about the phishing attempt and instruct them to avoid interacting with suspicious emails or websites. Provide guidance on recognizing phishing attempts.
+- Conduct a thorough review of the affected users' recent activities to identify any potential data exposure or unauthorized access to sensitive information.
+- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related incidents.
+- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activities or attempts to bypass security controls.
+- Review and update security policies and configurations related to Okta FastPass to ensure they are optimized for detecting and preventing similar phishing attempts in the future.
+- Coordinate with the IT team to ensure that all systems and applications are patched and up-to-date to mitigate any vulnerabilities that could be exploited in conjunction with phishing attacks.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 
diff --git a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
index 1dcfb9ddfb6..8e66bf1f037 100644
--- a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
+++ b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/14"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -13,7 +13,43 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Unauthorized Access to an Okta Application"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unauthorized Access to an Okta Application
+
+Okta is a widely used identity management service that facilitates secure user authentication and access to applications. Adversaries may exploit valid credentials to gain unauthorized access, bypassing security controls. The detection rule monitors specific Okta system events for unauthorized access attempts, leveraging event datasets and actions to identify potential breaches, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:app.generic.unauth_app_access_attempt to identify the specific unauthorized access attempts.
+- Identify the user accounts involved in the unauthorized access attempts and check for any unusual activity or patterns associated with these accounts.
+- Investigate the source IP addresses associated with the unauthorized access attempts to determine if they are known or suspicious, and check for any geolocation anomalies.
+- Examine the timestamps of the unauthorized access attempts to see if they coincide with any other suspicious activities or known incidents.
+- Check for any recent changes in user permissions or configurations in the Okta system that might have facilitated the unauthorized access attempts.
+- Contact the affected users to verify if they were aware of the access attempts and to ensure their credentials have not been compromised.
+
+### False positive analysis
+
+- Employees accessing applications from new devices or locations may trigger alerts. Regularly update the list of known devices and locations to minimize these false positives.
+- Automated scripts or tools used for application testing might mimic unauthorized access attempts. Identify and whitelist these scripts to prevent unnecessary alerts.
+- Users with multiple accounts accessing the same application can be mistaken for unauthorized access. Maintain an updated list of legitimate multi-account users to reduce false positives.
+- Changes in user roles or permissions might lead to temporary access issues. Coordinate with HR or IT departments to ensure role changes are reflected promptly in the system.
+- Scheduled maintenance or updates to applications can generate access attempts that appear unauthorized. Exclude these events by aligning detection rules with maintenance schedules.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Review and reset the credentials for the compromised account, ensuring the new password adheres to strong security policies.
+- Conduct a thorough audit of recent activities associated with the compromised account to identify any unauthorized changes or data access.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised.
+- Implement multi-factor authentication (MFA) for the affected account and any other accounts that do not currently have it enabled to enhance security.
+- Update and refine monitoring rules to detect similar unauthorized access attempts in the future, ensuring quick identification and response.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
index 2da36ae59b4..8d3ccc843e3 100644
--- a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
+++ b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -40,6 +40,41 @@ event.dataset: "okta.system"
     and event.outcome: "success"
     and okta.client.device: ("Unknown" or "unknown")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Successful Application SSO from Rare Unknown Client Device
+
+Single sign-on (SSO) streamlines user access across applications by using a single set of credentials. However, adversaries can exploit vulnerabilities in SSO systems, like Okta's, to bypass security policies using stolen credentials. The detection rule identifies unusual SSO events from unknown devices, signaling potential unauthorized access attempts, thus helping to mitigate risks associated with credential theft.
+
+### Possible investigation steps
+
+- Review the event details in the alert to confirm the presence of the "Unknown" or "unknown" client device in the okta.client.device field.
+- Check the user-agent string associated with the event to gather more information about the unknown device and assess if it matches any known legitimate devices used by the user.
+- Investigate the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior, such as unusual login times or locations.
+- Verify if there have been any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, which could indicate account compromise.
+- Cross-reference the IP address associated with the SSO event against known malicious IP databases or internal threat intelligence to identify potential threats.
+- Contact the user to confirm whether they recognize the login activity and the device used, ensuring it was an authorized access attempt.
+
+### False positive analysis
+
+- Employees using new or updated devices may trigger false positives. Regularly update the list of recognized devices to include these changes.
+- Legitimate users accessing applications from different locations or networks, such as while traveling, can appear as unknown devices. Implement geolocation checks and allow exceptions for known travel patterns.
+- Software updates or changes in user-agent strings can cause devices to be misidentified. Monitor for consistent patterns and adjust the rule to accommodate these variations.
+- Shared devices in environments like conference rooms or labs may not have unique identifiers. Establish a process to register these shared devices to prevent them from being flagged.
+- Temporary network issues causing devices to appear as unknown can lead to false positives. Correlate with network logs to verify if the device is indeed unknown or if it was a transient issue.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Conduct a thorough review of the affected user's recent activity across all Okta-integrated applications to identify any unauthorized actions or data access.
+- Reset the affected user's credentials and enforce a password change, ensuring the new password adheres to strong security policies.
+- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Review and update Okta's device recognition policies to improve detection of unknown or rare devices, reducing the risk of similar incidents.
+- Monitor for any further suspicious SSO activities from unknown devices and escalate to the incident response team if additional alerts are triggered."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
index 12c7bfaf265..e106d1ee33a 100644
--- a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
+++ b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -17,7 +17,43 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Suspicious Activity Reported by Okta User"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Activity Reported by Okta User
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit compromised credentials to gain unauthorized access, posing a threat to network security. The detection rule monitors for user-reported suspicious activity, signaling potential unauthorized access attempts. By analyzing these alerts, security teams can swiftly identify and mitigate threats, leveraging Okta's logging capabilities to trace and respond to malicious actions.
+
+### Possible investigation steps
+
+- Review the specific event details in the Okta logs where event.dataset is okta.system and event.action is user.account.report_suspicious_activity_by_enduser to gather initial context about the reported activity.
+- Identify the user who reported the suspicious activity and check their recent login history and access patterns for any anomalies or deviations from their typical behavior.
+- Correlate the reported suspicious activity with other security logs and alerts to determine if there are any related incidents or patterns indicating a broader attack.
+- Verify if there are any known vulnerabilities or compromised credentials associated with the user's account that could have been exploited.
+- Contact the user to gather additional information about the suspicious activity they observed and confirm whether they recognize any recent access attempts or changes to their account.
+- Assess the risk and potential impact of the suspicious activity on the network and determine if any immediate containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Users frequently accessing their accounts from new devices or locations may trigger false positives. Implement geofencing or device recognition to reduce these alerts.
+- Routine administrative actions, such as password resets or account updates, might be misinterpreted as suspicious. Exclude these actions from alerts if they are performed by known administrators.
+- Automated scripts or applications using service accounts can generate alerts if not properly configured. Ensure these accounts are whitelisted or have appropriate permissions set.
+- Employees using VPNs or proxy services for remote work can cause location-based false positives. Consider marking known VPN IP addresses as safe.
+- High-volume login attempts from legitimate users, such as during password recovery, can be mistaken for suspicious activity. Monitor for patterns and adjust thresholds accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access.
+- Notify the user and relevant stakeholders about the suspicious activity and the actions being taken to secure the account.
+- Conduct a password reset for the affected user account and enforce multi-factor authentication (MFA) if not already enabled.
+- Review recent login activity and access logs for the affected account to identify any unauthorized access or data exfiltration attempts.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other accounts or systems have been compromised.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
+- Update security policies and procedures based on findings to prevent similar incidents in the future, ensuring alignment with MITRE ATT&CK framework recommendations for Initial Access and Valid Accounts.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
index 9d015d679b8..a5a28d81aca 100644
--- a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
+++ b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -20,7 +20,43 @@ interval = "30m"
 language = "kuery"
 license = "Elastic License v2"
 name = "Multiple Okta Sessions Detected for a Single User"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Multiple Okta Sessions Detected for a Single User
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by hijacking session cookies, allowing unauthorized access to user accounts from different locations. The detection rule identifies anomalies by flagging multiple session initiations with distinct session IDs for the same user, excluding legitimate Okta system actors, thus highlighting potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the Okta logs to identify the specific user account associated with the multiple session initiations and note the distinct session IDs.
+- Check the geographic locations and IP addresses associated with each session initiation to determine if there are any unusual or unexpected locations.
+- Investigate the timestamps of the session initiations to see if they align with the user's typical login patterns or if they suggest simultaneous logins from different locations.
+- Examine the okta.actor.id and okta.actor.display_name fields to ensure that the sessions were not initiated by legitimate Okta system actors.
+- Contact the user to verify if they recognize the session activity and if they have recently logged in from multiple devices or locations.
+- Assess if there are any other related security alerts or incidents involving the same user account that could indicate a broader compromise.
+
+### False positive analysis
+
+- Legitimate multiple device usage: Users may legitimately access their accounts from multiple devices, leading to multiple session initiations. To handle this, create exceptions for users who frequently use multiple devices for work.
+- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing Okta from various locations. Consider setting up location-based exceptions for these users.
+- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Implement policies to discourage account sharing or create exceptions for known shared accounts.
+- Automated scripts or integrations: Some users may have automated processes that initiate multiple sessions. Identify these scripts and exclude them from the rule by their specific session patterns.
+- Testing and development environments: Users involved in testing or development may generate multiple sessions as part of their work. Exclude these environments from the rule to prevent false positives.
+
+### Response and remediation
+
+- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access.
+- Reset the user's password and invalidate any existing session cookies to ensure that any stolen session cookies are rendered useless.
+- Conduct a thorough review of recent login activity and session logs for the affected user to identify any suspicious or unauthorized access patterns.
+- Notify the user of the potential compromise and advise them to verify any recent account activity for unauthorized actions.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems may be affected.
+- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security against unauthorized access.
+- Update and enhance monitoring rules to detect similar anomalies in the future, focusing on unusual session patterns and access from unexpected locations.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
index 0260f558495..4d714f8edb2 100644
--- a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
+++ b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Administrator Privileges Assigned to an Okta Group"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Administrator Privileges Assigned to an Okta Group
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. Administrator privileges in Okta allow users to manage settings and permissions, making them a target for adversaries seeking persistent access. Malicious actors may exploit these privileges by assigning them to groups, thereby extending elevated access to compromised accounts. The detection rule monitors system events for privilege grants to groups, flagging potential unauthorized privilege escalations.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:group.privilege.grant to identify the specific group and administrator role assigned.
+- Identify the user account that initiated the privilege grant action and verify if the account has a history of suspicious activity or if it has been compromised.
+- Check the membership of the affected Okta group to determine which user accounts have gained elevated privileges and assess if any of these accounts are unauthorized or compromised.
+- Investigate recent activities of the affected group members to identify any unusual or unauthorized actions that may indicate malicious intent.
+- Review the organization's change management records to confirm if the privilege assignment was part of an approved change request or if it was unauthorized.
+- If unauthorized activity is confirmed, initiate incident response procedures to revoke the unauthorized privileges and secure the affected accounts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when legitimate IT staff assign administrator roles to groups for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
+- Organizational changes such as mergers or department restructuring might require temporary privilege escalations. Document these changes and adjust the detection rule to exclude these specific events during the transition period.
+- Automated scripts or third-party integrations that manage group permissions could inadvertently trigger false positives. Identify these scripts and whitelist their actions within the monitoring system to prevent unnecessary alerts.
+- Training or onboarding sessions where temporary admin access is granted to groups for demonstration purposes can cause alerts. Ensure these sessions are logged and recognized as non-threatening to avoid false positives.
+
+### Response and remediation
+
+- Immediately revoke the administrator privileges assigned to the Okta group to prevent further unauthorized access or privilege escalation.
+- Conduct a thorough review of recent group membership changes and privilege assignments in Okta to identify any other unauthorized modifications.
+- Isolate and investigate any user accounts that were part of the affected group to determine if they have been compromised.
+- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were part of the affected group to secure them against further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
+- Implement additional monitoring on the affected group and related user accounts to detect any further suspicious activities.
+- Review and update access control policies to ensure that only necessary groups and users have administrative privileges, reducing the risk of similar incidents in the future.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
index 65649731dde..7a466c94fe8 100644
--- a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
+++ b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Administrator Role Assigned to an Okta User"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Administrator Role Assigned to an Okta User
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. In environments using Okta, assigning an administrator role grants elevated permissions, which can be exploited by adversaries to maintain unauthorized access. The detection rule monitors system events for privilege grants, flagging suspicious role assignments to mitigate potential abuse.
+
+### Possible investigation steps
+
+- Review the event details to confirm the presence of the event.dataset:okta.system and event.action:user.account.privilege.grant fields, ensuring the alert is triggered by the correct conditions.
+- Identify the user account that was assigned the administrator role and gather information about their recent activities and login history to assess any unusual behavior.
+- Check the timestamp of the role assignment event to determine if it coincides with any other suspicious activities or known incidents.
+- Investigate the source IP address and location associated with the role assignment event to verify if it aligns with the user's typical access patterns.
+- Review the change history for the affected user account to identify any other recent modifications or privilege escalations that may indicate malicious intent.
+- Consult with the user or their manager to verify if the role assignment was authorized and legitimate, documenting any discrepancies or unauthorized actions.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when legitimate IT staff assign administrator roles for maintenance or onboarding purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
+- Automated scripts or integrations that require elevated permissions might cause false positives. Identify these scripts and whitelist their associated accounts to prevent unnecessary alerts.
+- Organizational changes such as mergers or department restructuring can lead to multiple legitimate role assignments. During these periods, temporarily adjust the rule sensitivity or increase monitoring to differentiate between expected and suspicious activities.
+- Training or testing environments where roles are frequently assigned for simulation purposes can generate false positives. Exclude these environments from the rule or set up a separate monitoring profile for them.
+
+### Response and remediation
+
+- Immediately revoke the administrator role from the affected Okta user account to prevent further unauthorized access or privilege escalation.
+- Conduct a thorough review of recent activity logs for the affected user account to identify any unauthorized actions or changes made while the elevated privileges were active.
+- Reset the password and enforce multi-factor authentication (MFA) for the affected user account to secure it against potential compromise.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized role assignment and any identified malicious activities.
+- Implement additional monitoring for the affected user account and similar accounts to detect any further suspicious activities or attempts to reassign elevated privileges.
+- Review and update access control policies to ensure that administrator role assignments require additional verification or approval processes to prevent unauthorized changes.
+- If evidence of broader compromise is found, initiate a full security incident response process, including forensic analysis and potential involvement of external cybersecurity experts.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
index babed655d21..99b2c26aea0 100644
--- a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
+++ b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Create Okta API Token"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Create Okta API Token
+
+Okta API tokens are crucial for automating and managing identity and access tasks within an organization. However, if compromised, these tokens can be exploited by adversaries to gain persistent access, manipulate user accounts, or alter security settings. The detection rule identifies suspicious token creation activities by monitoring specific Okta system events, helping to thwart unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:system.api_token.create to identify the specific instance of API token creation.
+- Identify the user account associated with the token creation event to determine if the action aligns with their typical behavior or role within the organization.
+- Check the timestamp of the event to correlate with other security events or anomalies that occurred around the same time.
+- Investigate the IP address and location from which the API token creation request originated to assess if it matches the user's usual access patterns.
+- Examine any recent changes to user accounts or security settings that may have been executed using the newly created API token.
+- Review the organization's policy on API token creation to ensure compliance and determine if the action was authorized.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when legitimate IT staff create API tokens for automation or integration purposes. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these known users.
+- Scheduled system maintenance or updates might involve creating API tokens, leading to false positives. Document these events and adjust the monitoring window or create temporary exceptions during these periods.
+- Third-party integrations that require API tokens for functionality can also trigger alerts. Identify and whitelist these integrations by verifying their necessity and security compliance.
+- Development and testing environments often involve frequent token creation for testing purposes. Exclude these environments from the rule or set up separate monitoring with adjusted thresholds to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke the suspicious Okta API token to prevent any unauthorized access or actions within the organization's network.
+- Conduct a thorough review of recent activities associated with the compromised token to identify any unauthorized changes or access attempts.
+- Reset credentials and enforce multi-factor authentication for any accounts that were accessed or potentially compromised using the API token.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response.
+- Implement additional monitoring on Okta API token creation events to detect and respond to any further unauthorized attempts promptly.
+- Review and update access controls and permissions related to API token creation to ensure they align with the principle of least privilege.
+- Escalate the incident to senior security management if there is evidence of broader compromise or if the threat actor's objectives are unclear.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
index a615d4a5740..93af9c676ae 100644
--- a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
+++ b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Attempt to Reset MFA Factors for an Okta User Account"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Reset MFA Factors for an Okta User Account
+
+Okta is a widely used identity management service that provides multi-factor authentication (MFA) to enhance security. Adversaries may attempt to reset MFA factors to register their own, gaining unauthorized access while appearing legitimate. The detection rule identifies such attempts by monitoring specific Okta system events, helping to flag potential account manipulation activities.
+
+### Possible investigation steps
+
+- Review the Okta system logs for the specific event.action:user.mfa.factor.reset_all to identify the user account involved in the MFA reset attempt.
+- Check the timestamp of the event to determine when the reset attempt occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the IP address and location associated with the event to assess if it aligns with the user's typical access patterns or if it appears unusual.
+- Examine the user account's recent activity history for any anomalies or unauthorized access attempts that might indicate compromise.
+- Verify if there have been any recent changes to the user's account settings or permissions that could suggest account manipulation.
+- Contact the affected user to confirm whether they initiated the MFA reset or if it was unauthorized, and advise them on securing their account if necessary.
+
+### False positive analysis
+
+- Routine administrative actions may trigger the rule if IT staff reset MFA factors for legitimate reasons such as assisting users who have lost access to their MFA devices. To manage this, create exceptions for known IT personnel or specific administrative actions.
+- User-initiated resets due to lost or changed devices can also appear as suspicious activity. Implement a process to verify user requests and document these instances to differentiate them from malicious attempts.
+- Automated scripts or tools used for account management might reset MFA factors as part of their operations. Identify and whitelist these tools to prevent false positives.
+- Scheduled security audits or compliance checks that involve resetting MFA factors should be documented and excluded from triggering alerts by setting up time-based exceptions during these activities.
+
+### Response and remediation
+
+- Immediately disable the affected Okta user account to prevent further unauthorized access.
+- Review recent login activity and MFA changes for the affected account to identify any unauthorized access or suspicious behavior.
+- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices.
+- Notify the legitimate user of the account compromise and advise them to change their password and review their account activity.
+- Conduct a security review of the affected user's permissions and access to sensitive resources to ensure no unauthorized changes were made.
+- Escalate the incident to the security operations team for further investigation and to determine if other accounts may be affected.
+- Update security monitoring and alerting to enhance detection of similar MFA reset attempts, leveraging the MITRE ATT&CK framework for guidance on persistence and account manipulation tactics.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
index 7373dae2b31..78582f3a80a 100644
--- a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
+++ b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/01"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-okta*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Modification or Removal of an Okta Application Sign-On Policy"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 or Removal of an Okta Application Sign-On Policy
+
+Okta's sign-on policies are crucial for enforcing authentication controls within an organization. Adversaries may target these policies to weaken security by modifying or removing them, thus bypassing authentication measures. The detection rule monitors system events for updates or deletions of sign-on policies, flagging potential unauthorized changes to maintain security integrity.
+
+### Possible investigation steps
+
+- Review the event logs for entries with the dataset field set to okta.system to confirm the source of the alert.
+- Examine the event.action field for values application.policy.sign_on.update or application.policy.sign_on.rule.delete to identify the specific action taken.
+- Identify the user or system account associated with the event to determine if the action was performed by an authorized individual.
+- Check the timestamp of the event to correlate with any other suspicious activities or changes in the system around the same time.
+- Investigate the history of changes to the affected sign-on policy to understand the context and frequency of modifications or deletions.
+- Assess the impact of the policy change on the organization's security posture and determine if any immediate remediation is necessary.
+- If unauthorized activity is suspected, initiate a security incident response to contain and mitigate potential threats.
+
+### False positive analysis
+
+- Routine administrative updates to sign-on policies by authorized personnel can trigger alerts. To manage this, establish a list of trusted users or roles and create exceptions for their actions.
+- Scheduled maintenance or policy reviews may involve legitimate modifications or deletions. Document these activities and adjust the detection rule to exclude events during known maintenance windows.
+- Automated scripts or tools used for policy management might cause false positives. Identify these tools and configure the rule to recognize and exclude their expected actions.
+- Changes due to integration with third-party applications can be mistaken for unauthorized modifications. Verify these integrations and whitelist their associated actions to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Okta application to prevent further unauthorized access or changes. This can be done by disabling the application temporarily until the issue is resolved.
+- Review the audit logs to identify the source of the modification or deletion attempt, focusing on the user account and IP address associated with the event.
+- Revert any unauthorized changes to the sign-on policy by restoring it to the last known good configuration. Ensure that all security controls are reinstated.
+- Conduct a thorough review of user accounts with administrative privileges in Okta to ensure they are legitimate and have not been compromised. Reset passwords and enforce multi-factor authentication (MFA) for these accounts.
+- Notify the security team and relevant stakeholders about the incident, providing details of the attempted policy modification or deletion and the steps taken to contain the threat.
+- Escalate the incident to higher-level security management if the source of the threat is internal or if there is evidence of a broader compromise.
+- Implement additional monitoring and alerting for any future attempts to modify or delete sign-on policies, ensuring that similar threats are detected and addressed promptly.
+
+## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 references = [
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
index d3ae5ec27f7..caffb0df060 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/19"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,40 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process Spawned by a Host
+
+The detection rule leverages machine learning to identify atypical processes on Windows systems, focusing on those that deviate from normal behavior. Adversaries often exploit legitimate system tools, known as LOLbins, to evade detection. This rule uses the ProblemChild ML model to flag processes that are both statistically unusual and potentially malicious, enhancing detection of stealthy attacks that bypass traditional methods.
+
+### Possible investigation steps
+
+- Review the process details flagged by the ProblemChild ML model, including the process name, path, and command line arguments, to understand its nature and potential purpose.
+- Check the parent process of the flagged process to determine if it was spawned by a legitimate application or a known LOLbin, which might indicate a Living off the Land attack.
+- Investigate the host's historical activity to assess whether this process or similar ones have been executed previously, focusing on any patterns of unusual behavior.
+- Correlate the process activity with user logins and network connections to identify any suspicious user behavior or external communications that coincide with the process execution.
+- Examine the system's security logs for any related alerts or anomalies around the time the process was detected, which might provide additional context or evidence of malicious activity.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger false positives if they involve unusual processes or tools not commonly used on the host. Users can create exceptions for these known tasks to prevent unnecessary alerts.
+- Software updates or installations can spawn processes that are atypical but benign. Identifying and excluding these processes during known maintenance windows can reduce false positives.
+- Custom scripts or automation tools that mimic LOLbins behavior might be flagged. Users should document and whitelist these scripts if they are verified as safe and necessary for operations.
+- Legitimate third-party applications that use system binaries in uncommon ways may be misclassified. Regularly review and update the list of approved applications to ensure they are not mistakenly flagged.
+- Temporary spikes in unusual processes due to legitimate business activities, such as end-of-quarter reporting, can be managed by adjusting the detection thresholds or temporarily disabling the rule during these periods.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers.
+- Terminate the suspicious process identified by the ProblemChild ML model to halt any ongoing malicious activity.
+- Conduct a thorough review of the process's parent and child processes to identify any additional malicious activity or persistence mechanisms.
+- Remove any identified LOLbins or unauthorized tools used by the adversary from the system to prevent further exploitation.
+- Restore the affected system from a known good backup if any system integrity issues are detected.
+- Update endpoint protection and monitoring tools to ensure they can detect similar threats in the future, focusing on the specific techniques used in this incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
index 479bddbead7..814d60c96cd 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,42 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process Spawned by a Parent Process
+
+In Windows environments, processes are often spawned by parent processes to perform legitimate tasks. However, adversaries can exploit this by using legitimate tools, known as LOLbins, to execute malicious activities stealthily. The detection rule leverages machine learning to identify anomalies in process creation patterns, flagging processes that deviate from typical behavior, thus uncovering potential threats that evade traditional detection methods.
+
+### Possible investigation steps
+
+- Review the parent process and child process names to determine if they are known legitimate applications or if they are commonly associated with LOLbins or other malicious activities.
+- Check the process creation time and correlate it with any known user activity or scheduled tasks to identify if the process execution aligns with expected behavior.
+- Investigate the command line arguments used by the suspicious process to identify any unusual or potentially malicious commands or scripts being executed.
+- Analyze the network activity associated with the process to detect any suspicious outbound connections or data exfiltration attempts.
+- Examine the file path and hash of the executable to verify its legitimacy and check against known malware databases or threat intelligence sources.
+- Review any recent changes to the system, such as software installations or updates, that might explain the unusual process behavior.
+- Consult endpoint detection and response (EDR) logs or other security tools to gather additional context and evidence related to the process and its activities.
+
+### False positive analysis
+
+- Legitimate administrative tools like PowerShell or command prompt may be flagged when used for routine tasks. Users can create exceptions for these tools when executed by known and trusted parent processes.
+- Software updates or installations often spawn processes that might appear unusual. Exclude these processes by identifying their typical parent-child relationships during updates.
+- Custom scripts or automation tools used within the organization might trigger alerts. Document these scripts and their expected behavior to create exceptions for them.
+- Frequent use of remote management tools can lead to false positives. Ensure these tools are whitelisted when used by authorized personnel.
+- Regularly review and update the list of exceptions to accommodate changes in legitimate process behaviors over time.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the suspicious process identified by the alert to stop any ongoing malicious actions.
+- Conduct a thorough analysis of the process and its parent to understand the scope of the compromise and identify any additional malicious activities or files.
+- Remove any malicious files or artifacts associated with the process from the system to ensure complete remediation.
+- Restore the system from a known good backup if the integrity of the system is compromised beyond repair.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
index 14b9364879e..529f4d0e6ce 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,41 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process Spawned by a User
+
+The detection of unusual processes spawned by users leverages machine learning to identify anomalies in user behavior and process execution. Adversaries often exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag processes that deviate from typical user activity, indicating potential misuse or masquerading tactics.
+
+### Possible investigation steps
+
+- Review the user context associated with the alert to determine if the user has a history of spawning unusual processes or if this is an isolated incident.
+- Examine the specific process flagged by the alert, including its command line arguments, parent process, and any associated network activity, to identify potential indicators of compromise.
+- Check for the presence of known LOLbins or other legitimate tools that may have been exploited, as indicated by the alert's focus on defense evasion tactics.
+- Investigate any recent changes in the user's behavior or system configuration that could explain the anomaly, such as software updates or new application installations.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns.
+- Assess the risk score and severity level in the context of the organization's threat landscape to prioritize the response and determine if further action is needed.
+
+### False positive analysis
+
+- Legitimate administrative tools may trigger false positives if they are used in atypical contexts. Users should review the context of the process execution and, if deemed safe, add these tools to an exception list to prevent future alerts.
+- Scheduled tasks or scripts that run infrequently might be flagged as unusual. Verify the legitimacy of these tasks and consider excluding them if they are part of regular maintenance or updates.
+- Software updates or installations can spawn processes that appear anomalous. Confirm the source and purpose of these updates, and if they are routine, create exceptions for these specific processes.
+- Developers or IT personnel using command-line tools for legitimate purposes may trigger alerts. Evaluate the necessity of these tools in their workflow and whitelist them if they are consistently used in a non-malicious manner.
+- New or infrequently used applications might be flagged due to lack of historical data. Assess the application's legitimacy and, if appropriate, add it to a list of known safe applications to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate the suspicious process identified by the alert to halt any ongoing malicious activity.
+- Conduct a thorough review of the user's recent activity and access logs to identify any unauthorized actions or data access.
+- Reset the credentials of the affected user account to prevent further unauthorized access, ensuring that strong, unique passwords are used.
+- Scan the system for additional indicators of compromise, such as other unusual processes or modifications to system files, and remove any identified threats.
+- Restore the system from a known good backup if any critical system files or configurations have been altered.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
index 6e6e84e73d4..88951083683 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,41 @@ query = '''
 process where ((problemchild.prediction == 1 and problemchild.prediction_probability > 0.98) or
 blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
+
+The detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit legitimate processes to evade detection, often using techniques like masquerading. This rule flags high-risk events by focusing on processes with a high malicious probability score or those identified by a blocklist, excluding known benign activities.
+
+### Possible investigation steps
+
+- Review the process details flagged by the ProblemChild model, focusing on those with a prediction probability greater than 0.98 or identified by the blocklist.
+- Examine the command-line arguments of the suspicious process to identify any unusual or unexpected patterns, excluding those matching known benign patterns like "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.txt*" or "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.tmp*".
+- Check the parent process of the flagged event to determine if it is a legitimate process or if it has been potentially compromised.
+- Investigate the user account associated with the process to assess if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited.
+- Correlate the event with other security alerts or logs to identify any related activities or patterns that could indicate a broader attack campaign.
+- Consult threat intelligence sources to determine if the process or its associated indicators are linked to known malicious activities or threat actors.
+
+### False positive analysis
+
+- Nessus scan files in the Windows temp directory may trigger false positives due to their temporary nature and frequent legitimate use. Users can mitigate this by adding exceptions for file paths like C:\\WINDOWS\\temp\\nessus_*.txt and C:\\WINDOWS\\temp\\nessus_*.tmp.
+- Legitimate software updates or installations might be flagged if they mimic known malicious patterns. Users should review the process details and whitelist trusted software update processes.
+- System administration tools that perform actions similar to those used in attacks could be misidentified. Users should verify the legitimacy of these tools and exclude them from the rule if they are part of regular administrative tasks.
+- Custom scripts or automation tools that are not widely recognized might be flagged. Users should ensure these scripts are secure and add them to an allowlist if they are part of routine operations.
+- Frequent false positives from specific processes can be managed by adjusting the threshold of the machine learning model or refining the blocklist to better distinguish between benign and malicious activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate the suspicious process identified by the ProblemChild model to halt any ongoing malicious actions.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Review and analyze the process execution history and associated files to understand the scope of the compromise and identify any persistence mechanisms.
+- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware.
+- 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 enhanced monitoring and logging for similar processes and activities to detect and respond to future attempts at masquerading or defense evasion."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
index 12ba9cd1c50..a518558c9d1 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint"]
 maturity = "production"
-updated_date = "2024/08/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,41 @@ query = '''
 process where ((problemchild.prediction == 1 and problemchild.prediction_probability <= 0.98) or
 blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a Low Malicious Probability Score
+
+The detection leverages a machine learning model to identify potentially suspicious Windows processes with a low likelihood of being malicious, focusing on defense evasion tactics like masquerading. Adversaries may exploit legitimate processes to bypass security measures. This rule flags such events, excluding known benign patterns, to highlight potential threats for further analysis.
+
+### Possible investigation steps
+
+- Review the process details where the problemchild.prediction is 1 and the prediction_probability is less than or equal to 0.98 to understand why the process was flagged as suspicious.
+- Check if the process is listed in the blocklist_label as 1, indicating it has been identified as malicious by the model's blocklist.
+- Investigate the command-line arguments of the process to identify any unusual or unexpected patterns, excluding known benign patterns such as those involving "C:\\WINDOWS\\temp\\nessus_*.txt" or "C:\\WINDOWS\\temp\\nessus_*.tmp".
+- Correlate the flagged process with other system events or logs to determine if it is part of a larger pattern of suspicious activity, focusing on defense evasion tactics like masquerading.
+- Assess the parent process and any child processes spawned by the suspicious process to identify potential lateral movement or further malicious activity.
+- Consult threat intelligence sources to see if the process or its associated indicators have been reported in recent threat reports or advisories.
+
+### False positive analysis
+
+- Nessus scan files in the Windows temp directory may trigger false positives. Exclude paths like C:\\WINDOWS\\temp\\nessus_*.txt and C:\\WINDOWS\\temp\\nessus_*.tmp to prevent these benign events from being flagged.
+- Legitimate software updates or installations might mimic suspicious behavior. Monitor and document regular update schedules to differentiate between expected and unexpected activities.
+- System administration scripts that automate tasks can appear suspicious. Identify and whitelist these scripts if they are part of routine operations to avoid unnecessary alerts.
+- Custom in-house applications may not be recognized by the model. Work with IT to catalog these applications and create exceptions where necessary to reduce false positives.
+- Regularly review and update the blocklist and exception rules to ensure they reflect the current environment and known benign activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement by the adversary exploiting the masquerading technique.
+- Terminate the suspicious process identified by the machine learning model to halt any ongoing malicious activity.
+- Conduct a thorough review of the process's parent and child processes to identify any additional suspicious activities or related processes that may require termination.
+- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for similar masquerading attempts by adjusting alert thresholds or adding specific indicators of compromise (IOCs) related to the detected event.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
index 0b7e329bef3..0b38e523181 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,41 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Host
+
+The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion.
+
+### Possible investigation steps
+
+- Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts.
+- Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading.
+- Check the timeline of the process execution to see if it coincides with any known scheduled tasks or user activity that could explain the anomaly.
+- Investigate the parent-child relationship of the processes to identify any unexpected or unauthorized process spawning patterns.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activity.
+- Assess the network activity associated with the host during the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses.
+
+### False positive analysis
+
+- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may be flagged as suspicious due to their dual-use nature. Users can create exceptions for these tools when used by trusted administrators or during scheduled maintenance.
+- Automated scripts or scheduled tasks that perform routine system checks or updates might trigger alerts. Review these processes and whitelist them if they are verified as part of regular operations.
+- Software updates or installations that involve multiple processes spawning in a short time frame can be mistaken for malicious clusters. Ensure that these activities are documented and create exceptions for known update processes.
+- Development or testing environments where new or experimental software is frequently executed may generate false positives. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these specific hosts.
+- Frequent use of remote desktop or remote management tools by IT staff can appear suspicious. Implement user-based exceptions for known IT personnel to reduce unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further spread of potential malicious activity. Disconnect it from the network to contain the threat.
+- Terminate the suspicious processes identified by the alert. Use task management tools or scripts to ensure all instances of the processes are stopped.
+- Conduct a thorough review of the host's system logs and process history to identify any additional indicators of compromise or related malicious activity.
+- Restore the host from a known good backup if available, ensuring that the backup is free from any signs of compromise.
+- Update and patch the host's operating system and all installed software to close any vulnerabilities that may have been exploited.
+- Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional hosts are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
index 7e06990450b..5ab53fcfe3d 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,41 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Parent Process
+
+In Windows environments, processes are often spawned by parent processes, forming a hierarchy. Adversaries exploit this by using legitimate processes to launch malicious ones, often leveraging Living off the Land Binaries (LOLBins) to evade detection. The detection rule employs machine learning to identify clusters of processes with high malicious probability, focusing on those sharing a common parent process. This approach helps uncover stealthy attacks that traditional methods might miss, enhancing defense against tactics like masquerading.
+
+### Possible investigation steps
+
+- Review the parent process name associated with the suspicious process cluster to identify if it is a known legitimate process or a potential masquerading attempt.
+- Examine the command line arguments and execution context of the suspicious processes to identify any use of LOLBins or unusual patterns that could indicate malicious activity.
+- Check the process creation timestamps and correlate them with any known events or user activities to determine if the process execution aligns with expected behavior.
+- Investigate the network activity of the suspicious processes to identify any unusual outbound connections or data exfiltration attempts.
+- Analyze the user account context under which the suspicious processes were executed to determine if there is any indication of compromised credentials or privilege escalation.
+- Cross-reference the detected processes with threat intelligence sources to identify any known indicators of compromise or related threat actor activity.
+
+### False positive analysis
+
+- Legitimate administrative tools may trigger false positives if they frequently spawn processes that resemble malicious activity. Users can create exceptions for known safe tools by whitelisting their parent process names.
+- Software updates or installations often generate clusters of processes that might be flagged as suspicious. Users should monitor these activities and exclude them if they are verified as legitimate.
+- Automated scripts or batch jobs that run regularly and spawn multiple processes can be mistaken for malicious clusters. Identifying these scripts and excluding their parent processes can reduce false positives.
+- Security software or monitoring tools that perform regular scans or updates might mimic malicious behavior. Users should ensure these tools are recognized and excluded from the rule's scope.
+- Custom business applications that are not widely recognized might be flagged. Users should document and exclude these applications if they are confirmed to be safe and necessary for operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
+- Terminate the suspicious processes identified by the alert to stop any malicious actions they may be performing.
+- Conduct a thorough review of the parent process and its associated binaries to ensure they have not been tampered with or replaced by malicious versions.
+- Restore any affected files or system components from a known good backup to ensure system integrity and functionality.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary, focusing on those related to LOLBins and masquerading techniques.
+- Monitor the system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
index a010cb7e723..d289a466c6f 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,41 @@ tags = [
     "Tactic: Defense Evasion",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a User
+
+The detection leverages machine learning to identify clusters of Windows processes with high malicious probability, often linked to tactics like masquerading. Adversaries exploit legitimate tools (LOLBins) to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters, focusing on user-associated anomalies to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the list of processes flagged by the alert to identify any known legitimate applications or tools that might have been misclassified.
+- Investigate the user account associated with the suspicious process cluster to determine if there is any history of unusual activity or if the account has been compromised.
+- Examine the parent-child relationship of the processes to understand the execution chain and identify any potential masquerading attempts or use of LOLBins.
+- Check for any recent changes or updates to the system that might explain the unusual process behavior, such as software installations or updates.
+- Correlate the detected processes with any known indicators of compromise (IOCs) or threat intelligence feeds to assess if they are linked to known malicious activity.
+- Analyze the network activity associated with the processes to identify any suspicious outbound connections or data exfiltration attempts.
+
+### False positive analysis
+
+- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may trigger false positives due to their frequent use in system management. Users can create exceptions for these tools when used by trusted administrators.
+- Software updates or installations often involve processes that mimic suspicious behavior. Exclude these processes by identifying and whitelisting update-related activities from known software vendors.
+- Automated scripts or scheduled tasks that perform routine maintenance can be misclassified as malicious. Review and whitelist these tasks if they are part of regular system operations.
+- Development environments may spawn multiple processes that resemble malicious clusters. Developers should document and exclude these processes when they are part of legitimate development activities.
+- Security software or monitoring tools might generate process clusters that appear suspicious. Ensure these tools are recognized and excluded from analysis to prevent false alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate the suspicious processes identified by the alert to halt any ongoing malicious actions.
+- Conduct a thorough review of the affected user's account for any unauthorized access or changes, and reset credentials if necessary.
+- Analyze the use of any identified LOLBins to determine if they were used maliciously and restrict their execution through application whitelisting or policy adjustments.
+- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope of the incident.
+- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and detection rules to identify similar patterns of behavior in the future, focusing on the specific tactics and techniques used in this incident."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/linux/collection_linux_clipboard_activity.toml b/rules/linux/collection_linux_clipboard_activity.toml
index ab497282884..026edae82d9 100644
--- a/rules/linux/collection_linux_clipboard_activity.toml
+++ b/rules/linux/collection_linux_clipboard_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ event.action:("exec" or "exec_event" or "executed" or "process_started") and
 process.name:("xclip" or "xsel" or "wl-clipboard" or "clipman" or "copyq") and
 not process.parent.name:("bwrap" or "micro")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Linux Clipboard Activity Detected
+
+Clipboard utilities on Linux, such as xclip and xsel, facilitate data transfer between applications by storing copied content temporarily. Adversaries exploit this by capturing sensitive data copied by users. The detection rule identifies unusual clipboard activity by monitoring processes that start these utilities, excluding common parent processes, to flag potential misuse. This helps in identifying unauthorized data collection attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name that triggered the alert, focusing on clipboard utilities like xclip, xsel, wl-clipboard, clipman, or copyq.
+- Examine the parent process of the detected clipboard utility to understand the context of its execution, ensuring it is not a common parent process like bwrap or micro.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Check the timing and frequency of the clipboard utility's execution to assess if it coincides with any known user activities or if it suggests automated or unauthorized access.
+- Analyze any related process events or logs around the time of the alert to identify potential data exfiltration attempts or other malicious activities.
+- Consider correlating this alert with other security events or alerts to identify patterns or broader attack campaigns targeting clipboard data.
+
+### False positive analysis
+
+- Frequent use of clipboard utilities by legitimate applications or scripts can trigger false positives. Identify and document these applications to create exceptions in the detection rule.
+- Developers and system administrators often use clipboard utilities in automated scripts. Review and whitelist these scripts to prevent unnecessary alerts.
+- Some desktop environments or window managers may use clipboard utilities as part of their normal operation. Monitor and exclude these processes if they are verified as non-threatening.
+- Regular user activities involving clipboard utilities for productivity tasks can be mistaken for suspicious behavior. Educate users on safe practices and adjust the rule to exclude known benign parent processes.
+- Consider the context of the clipboard utility usage, such as time of day or user role, to refine detection criteria and reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential data exfiltration or further unauthorized access.
+- Terminate any suspicious processes identified as running clipboard utilities without a common parent process, such as xclip or xsel, to stop potential data capture.
+- Conduct a thorough review of recent clipboard activity logs to identify any sensitive data that may have been captured and assess the potential impact.
+- Change passwords and rotate any credentials that may have been copied to the clipboard recently to mitigate the risk of credential theft.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system to detect any further unauthorized clipboard activity or related suspicious behavior.
+- Review and update endpoint security configurations to ensure that only authorized processes can access clipboard utilities, reducing the risk of future exploitation."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
index 67bd077656d..3ace9cf2077 100644
--- a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
+++ b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,40 @@ timestamp_override = "event.ingested"
 query = '''
 host.os.type: "linux" and event.category: "process" and process.name: "aws" and process.args:  "--endpoint-url"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS CLI Command with Custom Endpoint URL
+
+The AWS CLI allows users to interact with AWS services via command-line, offering flexibility in managing cloud resources. The `--endpoint-url` option lets users specify alternative endpoints, which can be exploited by adversaries to reroute requests to malicious servers, bypassing security controls. The detection rule identifies such misuse by monitoring for the `--endpoint-url` argument in process logs, flagging potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the process logs to identify the specific command line that triggered the alert, focusing on the presence of the --endpoint-url argument.
+- Investigate the custom endpoint URL specified in the command to determine if it is a known malicious or unauthorized domain.
+- Check the user account associated with the process to assess if it has a history of suspicious activity or if it has been compromised.
+- Analyze network logs to trace any outbound connections to the custom endpoint URL and evaluate the data being transmitted.
+- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise related to the same user or endpoint.
+- Verify if the AWS credentials used in the command have been exposed or misused in other contexts, potentially indicating credential theft or abuse.
+
+### False positive analysis
+
+- Internal testing environments may use custom endpoint URLs for development purposes. To manage this, create exceptions for known internal IP addresses or domain names associated with these environments.
+- Organizations using AWS CLI with custom endpoints for legitimate third-party integrations might trigger this rule. Identify and whitelist these specific integrations by their endpoint URLs to prevent false positives.
+- Automated scripts or tools that interact with AWS services through custom endpoints for monitoring or backup purposes can be flagged. Review and document these scripts, then exclude them from detection by process name or specific endpoint URL.
+- Some organizations may use proxy servers that require custom endpoint URLs for AWS CLI operations. Verify these configurations and exclude the associated endpoint URLs from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Review process logs and network traffic to identify any data that may have been redirected to unauthorized endpoints and assess the extent of potential data exposure.
+- Revoke any AWS credentials or access keys used on the affected system to prevent further misuse and rotate them with new credentials.
+- Conduct a thorough investigation to determine if any other systems have been compromised or if similar unauthorized endpoint usage has occurred elsewhere in the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment or remediation actions are necessary.
+- Implement network-level controls to block known malicious endpoints and enhance monitoring for unusual AWS CLI usage patterns across the environment.
+- Update security policies and endpoint protection configurations to detect and alert on the use of custom endpoint URLs in AWS CLI commands, ensuring rapid response to future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/command_and_control_curl_socks_proxy_detected.toml b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
index 24109e074a5..7d3c4d99ca3 100644
--- a/rules/linux/command_and_control_curl_socks_proxy_detected.toml
+++ b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,41 @@ process.name == "curl" and (
   process.env_vars like ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Activity from Unusual Parent
+
+Curl is a versatile command-line tool used for transferring data with URLs, often employed for legitimate data retrieval. However, adversaries can exploit its SOCKS proxy capabilities to bypass network restrictions, facilitating covert data exfiltration or communication with command and control servers. The detection rule identifies suspicious curl executions initiated by atypical parent processes, such as those from temporary directories or shell environments, combined with SOCKS proxy arguments, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the parent process details to understand the context of the curl execution, focusing on unusual directories like /dev/shm, /tmp, or shell environments such as bash or zsh.
+- Examine the command-line arguments used with curl, specifically looking for SOCKS proxy options like --socks5-hostname or -x, to determine the intent and destination of the network request.
+- Investigate the environment variables set for the process, such as http_proxy or HTTPS_PROXY, to identify any proxy configurations that might indicate an attempt to bypass network restrictions.
+- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Analyze network logs to trace the destination IP addresses or domains contacted via the SOCKS proxy to assess if they are known malicious or suspicious entities.
+- Correlate this activity with other alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Development environments may frequently use curl with SOCKS proxy options for legitimate testing purposes. To manage this, consider excluding specific development directories or user accounts from the rule.
+- Automated scripts or cron jobs running from shell environments might use curl with SOCKS proxies for routine data retrieval. Identify these scripts and exclude their parent processes or specific arguments from triggering the rule.
+- System administrators might use curl with SOCKS proxies for network diagnostics or maintenance tasks. Document these activities and create exceptions for known administrative accounts or specific command patterns.
+- Web applications hosted in directories like /var/www/html may use curl for backend operations involving SOCKS proxies. Review these applications and whitelist their specific processes or arguments if they are verified as non-threatening.
+- Temporary directories such as /tmp or /dev/shm might be used by legitimate software for transient operations involving curl. Monitor these occurrences and exclude known benign software from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further data exfiltration or communication with command and control servers.
+- Terminate any suspicious curl processes identified by the detection rule to halt potential malicious activity.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or additional malicious processes.
+- Review and clean up any unauthorized or suspicious files in temporary directories or other unusual locations, such as /dev/shm, /tmp, or /var/tmp, to remove potential threats.
+- Reset credentials and review access logs for any accounts that may have been compromised or used in conjunction with the detected activity.
+- Implement network monitoring to detect and block any further attempts to use SOCKS proxy connections from unauthorized sources.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_ip_forwarding_activity.toml b/rules/linux/command_and_control_ip_forwarding_activity.toml
index 442f15c5872..d22f4c5d8ef 100644
--- a/rules/linux/command_and_control_ip_forwarding_activity.toml
+++ b/rules/linux/command_and_control_ip_forwarding_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,41 @@ process.parent.executable != null and process.command_line like (
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 IPv4/IPv6 Forwarding Activity
+
+IPv4/IPv6 forwarding allows a Linux system to route traffic between network interfaces, facilitating network communication. While essential for legitimate network operations, adversaries can exploit this capability to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on specific command patterns and processes, thus highlighting potential misuse.
+
+### Possible investigation steps
+
+- Review the process command line details to understand the context in which IP forwarding was enabled, focusing on the specific command patterns identified in the alert.
+- Identify the parent process of the suspicious command execution using the process.parent.executable field to determine if it was initiated by a legitimate or potentially malicious process.
+- Check the user account associated with the process execution to assess if the action was performed by an authorized user or if there are signs of compromised credentials.
+- Investigate recent network activity on the host to identify any unusual traffic patterns or connections that could indicate data exfiltration or lateral movement.
+- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns.
+- Assess the system's current configuration and network topology to determine if enabling IP forwarding could have been part of a legitimate administrative task or if it poses a security risk.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators enable IP forwarding for legitimate network configuration purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions.
+- Automated scripts or configuration management tools like Ansible or Puppet might execute commands that match the rule's criteria. Identify these tools and exclude their processes from the rule to prevent false alerts.
+- Network testing or troubleshooting activities often require temporary enabling of IP forwarding. Document and exclude these activities when performed by trusted users or during scheduled maintenance windows.
+- Virtualization or container orchestration platforms may enable IP forwarding as part of their normal operations. Recognize these platforms and adjust the rule to ignore their specific processes or command patterns.
+- Security tools or network monitoring solutions might also enable IP forwarding for analysis purposes. Verify these tools and exclude their processes to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, particularly those enabling IP forwarding, to halt potential lateral movement or data exfiltration.
+- Conduct a thorough review of network traffic logs to identify any unusual or unauthorized connections that may indicate command and control activity.
+- Revert any unauthorized changes to system configurations, specifically those related to IP forwarding settings, to restore the system to its secure state.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Implement network segmentation to limit the ability of attackers to pivot between networks in the future.
+- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/command_and_control_linux_kworker_netcon.toml b/rules/linux/command_and_control_linux_kworker_netcon.toml
index cebba118b0b..8ec9f67cd27 100644
--- a/rules/linux/command_and_control_linux_kworker_netcon.toml
+++ b/rules/linux/command_and_control_linux_kworker_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,40 @@ process.name:kworker* and not destination.ip:(
   "FF00::/8"
 ) and not destination.port:("2049" or "111" or "892" or "597")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Activity Detected via Kworker
+
+Kworker processes are integral to Linux systems, handling kernel tasks like interrupts and background activities. Adversaries may exploit these processes to mask malicious network activities, evading detection by blending in with legitimate kernel operations. The detection rule identifies suspicious network connections initiated by kworker processes, excluding trusted IP ranges and ports, to uncover potential command and control activities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the kworker process is indeed initiating network connections, focusing on the process.name field.
+- Examine the destination IP address and port to determine if the connection is to an untrusted or suspicious external network, as the rule excludes trusted IP ranges and ports.
+- Check historical data for any previous alerts or network activity involving the same kworker process to identify patterns or repeated behavior.
+- Investigate the source host for any signs of compromise or unusual activity, such as unauthorized access attempts or unexpected process executions.
+- Correlate the network activity with other security events or logs from the same timeframe to identify potential indicators of compromise or related malicious activities.
+
+### False positive analysis
+
+- Network monitoring tools or legitimate applications may occasionally use kworker processes for routine checks or updates, leading to false positives. Users can create exceptions for these specific applications by identifying their typical IP ranges and ports.
+- Internal network scanning or monitoring activities might trigger alerts. To mitigate this, users should exclude known internal IP ranges and ports used by these activities from the detection rule.
+- Automated backup or synchronization services that operate in the background could be mistaken for suspicious activity. Users should identify these services and adjust the rule to exclude their associated network traffic.
+- Some system updates or maintenance tasks might temporarily use kworker processes for network communication. Users can whitelist the IP addresses and ports associated with these tasks to prevent false alerts.
+- If a specific kworker process consistently triggers alerts without any malicious intent, users should investigate the process's behavior and, if deemed safe, add it to an exception list to avoid future false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker.
+- Terminate any suspicious kworker processes identified as initiating unauthorized network connections to halt ongoing malicious activities.
+- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized files or processes, and remove them.
+- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Monitor network traffic for any further suspicious activity originating from other systems, indicating potential spread or persistence of the threat.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and logging for kworker processes and network activities to improve detection of similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/credential_access_collection_sensitive_files.toml b/rules/linux/credential_access_collection_sensitive_files.toml
index b4def3d777d..43cf85a3c34 100644
--- a/rules/linux/credential_access_collection_sensitive_files.toml
+++ b/rules/linux/credential_access_collection_sensitive_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -106,6 +106,40 @@ event.category:process and host.os.type:linux and event.type:start and
       /etc/gshadow
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Sensitive Files Compression
+
+Compression utilities like zip, tar, and gzip are essential for efficiently managing and transferring files. However, adversaries can exploit these tools to compress and exfiltrate sensitive data, such as SSH keys and configuration files. The detection rule identifies suspicious compression activities by monitoring process executions involving these utilities and targeting known sensitive file paths, thereby flagging potential data collection and credential access attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the user account associated with the compression activity, focusing on the process.name and process.args fields.
+- Examine the command line arguments (process.args) to determine which specific sensitive files were targeted for compression.
+- Check the event.timestamp to establish a timeline and correlate with other potentially suspicious activities on the host.
+- Investigate the host's recent login history and user activity to identify any unauthorized access attempts or anomalies.
+- Analyze network logs for any outbound connections from the host around the time of the event to detect potential data exfiltration attempts.
+- Assess the integrity and permissions of the sensitive files involved to determine if they have been altered or accessed inappropriately.
+
+### False positive analysis
+
+- Routine system backups or administrative tasks may trigger the rule if they involve compressing sensitive files for legitimate purposes. Users can create exceptions for known backup scripts or administrative processes by excluding specific process names or command-line arguments associated with these tasks.
+- Developers or system administrators might compress configuration files during development or deployment processes. To handle this, users can whitelist specific user accounts or directories commonly used for development activities, ensuring these actions are not flagged as suspicious.
+- Automated scripts or cron jobs that regularly archive logs or configuration files could be mistakenly identified as threats. Users should review and exclude these scheduled tasks by identifying their unique process identifiers or execution patterns.
+- Security tools or monitoring solutions that periodically compress and transfer logs for analysis might be misinterpreted as malicious. Users can exclude these tools by specifying their process names or paths in the detection rule exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration and unauthorized access.
+- Terminate any suspicious processes identified by the detection rule to halt ongoing compression and potential data exfiltration activities.
+- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure and determine if any data has been exfiltrated.
+- Change all credentials associated with the compromised files, such as SSH keys and AWS credentials, to prevent unauthorized access using stolen credentials.
+- Restore any altered or deleted configuration files from a known good backup to ensure system integrity and functionality.
+- 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 enhanced monitoring and logging for compression utilities and sensitive file access to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_credential_dumping.toml b/rules/linux/credential_access_credential_dumping.toml
index 8f23688749d..f7ae74be81c 100644
--- a/rules/linux/credential_access_credential_dumping.toml
+++ b/rules/linux/credential_access_credential_dumping.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,40 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name == "unshadow" and process.args_count >= 3
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Linux Credential Dumping via Unshadow
+
+Unshadow is a utility within the John the Ripper suite, used to merge `/etc/shadow` and `/etc/passwd` files, making them vulnerable to password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of Unshadow by monitoring process activities, focusing on specific execution patterns and argument counts, thus flagging potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the unshadow utility by checking the process name and arguments, ensuring that the process.args_count is 3 or more.
+- Investigate the user account under which the unshadow process was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access.
+- Examine the command line arguments used with the unshadow process to identify the specific files targeted, such as /etc/shadow and /etc/passwd, and verify if these files were accessed or modified.
+- Check for any subsequent processes or activities that might indicate password cracking attempts, such as the execution of John the Ripper or similar tools, following the unshadow execution.
+- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
+- Assess the risk and impact by determining if any sensitive credentials were potentially exposed and consider implementing additional monitoring or access controls to prevent future incidents.
+
+### False positive analysis
+
+- System administrators or security teams may use the unshadow utility for legitimate auditing or recovery purposes. To handle this, create exceptions for known administrative accounts or specific maintenance windows.
+- Automated scripts or backup processes might invoke unshadow as part of routine operations. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts.
+- Security testing or penetration testing activities could involve the use of unshadow. Coordinate with the testing team to whitelist their activities during the testing period to avoid false positives.
+- Development or testing environments might have unshadow executed as part of security tool evaluations. Exclude these environments from monitoring or adjust the rule to focus on production systems only.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes related to the unshadow utility to halt ongoing credential dumping activities.
+- Conduct a thorough review of the affected system's `/etc/shadow` and `/etc/passwd` files to identify any unauthorized modifications or access.
+- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of compromised credentials.
+- Review and update access controls and permissions for sensitive files, ensuring that only authorized users have access to `/etc/shadow` and `/etc/passwd`.
+- 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 enhanced monitoring and logging for similar activities across the network to detect and respond to future credential dumping attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_gdb_init_process_hooking.toml b/rules/linux/credential_access_gdb_init_process_hooking.toml
index 316c22a5392..5bd4090db10 100644
--- a/rules/linux/credential_access_gdb_init_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_init_process_hooking.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,40 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
 process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Linux init (PID 1) Secret Dump via GDB
+
+In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1".
+- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system.
+- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script.
+- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack.
+- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections.
+- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated.
+
+### False positive analysis
+
+- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions.
+- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe.
+- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources.
+- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities.
+- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts.
+- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems.
+- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required.
+- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_gdb_process_hooking.toml b/rules/linux/credential_access_gdb_process_hooking.toml
index 25ac63aca2f..2636a3a4f98 100644
--- a/rules/linux/credential_access_gdb_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_process_hooking.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 /* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
 process.args != "1"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Linux Process Hooking via GDB
+
+GDB, the GNU Debugger, is a powerful tool used for debugging applications by inspecting their memory and execution flow. Adversaries can exploit GDB to attach to running processes, potentially extracting sensitive information like credentials. The detection rule identifies suspicious use of GDB by monitoring process initiation with specific arguments, flagging potential unauthorized memory access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of GDB by checking if the process name is "gdb" and the arguments include "--pid" or "-p".
+- Identify the target process that GDB is attempting to attach to by examining the process arguments and cross-referencing the process ID.
+- Investigate the user account under which the GDB process is running to determine if it is authorized to perform debugging tasks on the target process.
+- Check the system logs and audit logs for any unusual activity or prior attempts to access sensitive processes or data around the time the GDB process was initiated.
+- Correlate the event with other security alerts or anomalies in the environment to assess if this is part of a broader attack pattern or isolated incident.
+- Evaluate the necessity and legitimacy of the GDB usage in the context of the system's normal operations and the user's role.
+- If unauthorized access is suspected, consider isolating the affected system and conducting a deeper forensic analysis to prevent potential data exfiltration.
+
+### False positive analysis
+
+- Development and debugging activities may trigger the rule when developers use GDB for legitimate purposes. To manage this, create exceptions for specific user accounts or development environments where GDB usage is expected.
+- Automated scripts or maintenance tasks that utilize GDB for process inspection can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule.
+- Security tools or monitoring solutions that use GDB for legitimate process analysis might be flagged. Verify these tools and whitelist their processes or execution contexts to prevent unnecessary alerts.
+- Training or educational environments where GDB is used for learning purposes can lead to false positives. Consider excluding these environments or specific user groups from the rule to avoid interference with educational activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the GDB process if it is confirmed to be unauthorized, using process management tools to stop the process safely.
+- Conduct a memory dump analysis of the affected system to identify any potential data leakage or extraction of sensitive information.
+- Review system logs and audit trails to identify any additional unauthorized access attempts or related suspicious activities.
+- Change credentials for any accounts that may have been exposed or accessed during the incident to prevent unauthorized use.
+- Implement stricter access controls and monitoring for systems that handle sensitive information to prevent similar incidents.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
index c53f414129c..0a91adfb2a8 100644
--- a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
+++ b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,39 @@ sequence by host.id, process.parent.executable, user.id with maxspan=1s
    )
   ] with runs=10
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Linux Local Account Brute Force Detected
+
+In Linux environments, the 'su' command is used to switch user accounts, often requiring a password. Adversaries exploit this by attempting numerous logins with various passwords to gain unauthorized access. The detection rule identifies suspicious activity by monitoring rapid, repeated 'su' command executions from a single process, excluding common legitimate parent processes, indicating potential brute force attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the parent process of the 'su' command, focusing on any unusual or unauthorized parent processes not listed in the exclusion list.
+- Analyze the frequency and pattern of the 'su' command executions from the identified process to determine if they align with typical user behavior or indicate a brute force attempt.
+- Check the user account targeted by the 'su' command attempts to assess if it is a high-value or sensitive account that might be of interest to adversaries.
+- Investigate the source host (host.id) to determine if there are any other suspicious activities or anomalies associated with it, such as unusual network connections or other security alerts.
+- Correlate the event timestamps with other logs or alerts to identify any concurrent suspicious activities that might indicate a coordinated attack effort.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools may trigger the rule if they execute the 'su' command frequently. To mitigate this, identify and whitelist these scripts or tools by adding their parent process names to the exclusion list.
+- Scheduled tasks or cron jobs that require switching users might be misidentified as brute force attempts. Review and exclude these tasks by specifying their parent process names in the exclusion criteria.
+- Development or testing environments where frequent user switching is part of normal operations can generate false positives. Consider excluding these environments from monitoring or adjust the detection threshold to better fit the operational context.
+- Continuous integration or deployment systems that use the 'su' command for user context switching can be mistaken for brute force attempts. Add these systems' parent process names to the exclusion list to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network.
+- Terminate the suspicious process identified by the detection rule to stop ongoing brute force attempts.
+- Reset passwords for the targeted user accounts to prevent unauthorized access using potentially compromised credentials.
+- Review and update the password policy to enforce strong, complex passwords and consider implementing account lockout mechanisms after a certain number of failed login attempts.
+- Conduct a thorough review of the affected system for any signs of successful unauthorized access or additional malicious activity, such as new user accounts or scheduled tasks.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Enhance monitoring and logging on the affected host and similar systems to detect and respond to future brute force attempts more effectively."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
index 936f72da6b4..f07dd8fda75 100644
--- a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,39 @@ sequence by host.id, auditd.data.addr, related.user with maxspan=5s
    auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and
    auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Successful Linux FTP Brute Force Attack Detected
+
+FTP is a protocol used for transferring files between systems, often requiring authentication. Adversaries exploit this by attempting numerous username-password combinations to gain unauthorized access, potentially leading to data breaches. The detection rule identifies a pattern of repeated failed login attempts from a single source, followed by a successful login, indicating a possible brute force attack.
+
+### Possible investigation steps
+
+- Review the source IP address (auditd.data.addr) involved in the failed and successful login attempts to determine if it is known or associated with previous malicious activity.
+- Analyze the timeline of the failed login attempts followed by the successful login to assess the likelihood of a brute force attack, considering the maxspan of 5 seconds.
+- Check the user account (related.user) targeted by the login attempts to determine if it is a high-value account or has been involved in previous security incidents.
+- Investigate the host (host.id) where the login attempts occurred to identify any other suspicious activities or anomalies around the time of the alert.
+- Correlate the detected activity with other logs or alerts from the same time period to identify potential lateral movement or further compromise within the network.
+
+### False positive analysis
+
+- Repeated failed logins from automated scripts or monitoring tools can trigger false positives. Identify and whitelist IP addresses of known internal systems or services that perform regular FTP checks.
+- Users with incorrect credentials saved in FTP clients may cause multiple failed attempts before a successful login. Educate users on updating saved credentials and consider excluding specific user accounts from the rule if they frequently trigger alerts.
+- Scheduled tasks or cron jobs that attempt to connect with outdated credentials can result in false positives. Review and update scheduled tasks to ensure they use current credentials, and exclude these tasks from monitoring if they are non-threatening.
+- High-volume legitimate FTP traffic from trusted partners or vendors might mimic brute force patterns. Establish a list of trusted external IP addresses and exclude them from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Reset the compromised user account's password and any other accounts that may have been accessed using the same credentials.
+- Review and analyze the logs from the affected system to identify any unauthorized changes or data access that occurred during the breach.
+- Implement IP blocking or rate limiting for the source address identified in the alert to prevent further brute force attempts from the same origin.
+- Conduct a thorough security assessment of the FTP server configuration to ensure it adheres to best practices, such as disabling anonymous access and enforcing strong password policies.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems were affected.
+- Enhance monitoring and alerting for similar brute force patterns by ensuring that detection rules are tuned to capture variations in attack techniques."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
index f4c9c353808..50aec20ada2 100644
--- a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,40 @@ sequence by host.id, related.user with maxspan=5s
   [authentication where host.os.type == "linux" and event.action  == "authenticated" and
    auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Successful Linux RDP Brute Force Attack Detected
+
+Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, often used for administrative tasks. Adversaries exploit RDP by attempting numerous login attempts to gain unauthorized access, potentially leading to data breaches or further network infiltration. The detection rule identifies a pattern of failed login attempts followed by a successful one, indicating a possible brute force attack, thus alerting security teams to investigate and mitigate the threat.
+
+### Possible investigation steps
+
+- Review the authentication logs on the affected Linux host to identify the specific user account targeted by the failed and successful login attempts, focusing on entries with event.action as "authenticated" and auditd.data.terminal containing "*rdp*".
+- Analyze the source IP addresses associated with the failed and successful login attempts to determine if they originate from known or suspicious locations.
+- Check for any unusual activity or changes on the compromised system following the successful login, such as new user accounts, modified files, or unexpected network connections.
+- Correlate the timestamps of the authentication events with other security logs to identify any concurrent suspicious activities or anomalies within the network.
+- Investigate the user account's recent activity and permissions to assess potential impacts and determine if the account has been used for unauthorized access or lateral movement within the network.
+- Evaluate the risk score and severity of the alert in the context of the organization's security posture and prioritize response actions accordingly.
+
+### False positive analysis
+
+- Legitimate administrative activities may trigger the rule if administrators frequently log in using RDP for system management. To handle this, create exceptions for known administrator accounts or IP addresses that regularly perform these tasks.
+- Automated scripts or services that use RDP for routine operations can cause false positives. Identify these scripts and whitelist their associated user accounts or IPs to prevent unnecessary alerts.
+- Scheduled tasks or cron jobs that involve RDP connections might be misinterpreted as brute force attempts. Exclude these tasks by specifying their user accounts or terminal identifiers in the rule configuration.
+- Security testing or penetration testing activities can mimic brute force patterns. Coordinate with security teams to exclude these activities during testing periods by temporarily adjusting the rule parameters or adding exceptions for testing IP ranges.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Reset the compromised user account's password and any other accounts that may have been accessed using the same credentials to prevent further unauthorized access.
+- Conduct a thorough review of the affected system for any signs of additional compromise, such as unauthorized software installations or changes to system configurations, and remove any malicious artifacts.
+- Implement multi-factor authentication (MFA) for RDP access to enhance security and reduce the risk of future brute force attacks.
+- Review and tighten firewall rules to restrict RDP access to only trusted IP addresses and consider using a VPN for remote access.
+- Monitor the network for any unusual activity or further attempts to exploit RDP, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation and recovery actions are taken."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_proc_credential_dumping.toml b/rules/linux/credential_access_proc_credential_dumping.toml
index d6efb4506b7..e9e86e781aa 100644
--- a/rules/linux/credential_access_proc_credential_dumping.toml
+++ b/rules/linux/credential_access_proc_credential_dumping.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,42 @@ sequence by host.id, process.parent.name with maxspan=1m
   [process where host.os.type == "linux" and process.name == "strings" and event.action in ("exec", "start", "exec_event")
    and process.args : "/tmp/*"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Linux Credential Dumping via Proc Filesystem
+
+The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved.
+- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query.
+- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'.
+- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks.
+- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity.
+- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections.
+- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident.
+
+### False positive analysis
+
+- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands.
+- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths.
+- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts.
+- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods.
+- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments.
+- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts.
+- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse.
+- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation.
+- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_ssh_backdoor_log.toml b/rules/linux/credential_access_ssh_backdoor_log.toml
index bbd78ee7232..d5ff14b489a 100644
--- a/rules/linux/credential_access_ssh_backdoor_log.toml
+++ b/rules/linux/credential_access_ssh_backdoor_log.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -111,6 +111,41 @@ file where host.os.type == "linux" and event.type == "change" and process.execut
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential OpenSSH Backdoor Logging Activity
+
+OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches.
+
+### Possible investigation steps
+
+- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth".
+- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions.
+- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised.
+- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting.
+- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity.
+- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services.
+
+### False positive analysis
+
+- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts.
+- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious.
+- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations.
+- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise.
+- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity.
+- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes.
+- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications.
+- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials.
+- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
index f333f48428b..e34757ffb3d 100644
--- a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
+++ b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ sequence by host.id,  process.parent.entity_id with maxspan=1s
   and event.action == "connection_attempted"
   and destination.ip == "169.254.169.254"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Instance Metadata Service (IMDS) API Request
+
+The Instance Metadata Service (IMDS) API provides essential instance-specific data, including configuration details and temporary credentials, to applications running on cloud instances. Adversaries exploit this by using scripts or tools to access sensitive data, potentially leading to unauthorized access. The detection rule identifies suspicious access attempts by monitoring specific processes and network activities, excluding known legitimate paths, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process details such as process.name and process.command_line to identify the tool or script used to access the IMDS API and determine if it aligns with known malicious behavior.
+- Examine the process.executable and process.working_directory fields to verify if the execution path is unusual or suspicious, especially if it originates from directories like /tmp/* or /var/tmp/*.
+- Check the process.parent.entity_id and process.parent.executable to understand the parent process and its legitimacy, which might provide context on how the suspicious process was initiated.
+- Investigate the network event details, particularly the destination.ip field, to confirm if there was an attempted connection to the IMDS API endpoint at 169.254.169.254.
+- Correlate the host.id with other security events or logs to identify any additional suspicious activities or patterns on the same host that might indicate a broader compromise.
+- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+
+### False positive analysis
+
+- Security and monitoring tools like Rapid7, Nessus, and Amazon SSM Agent may trigger false positives due to their legitimate access to the IMDS API. Users can exclude these by adding their working directories to the exception list.
+- Automated scripts or processes running from known directories such as /opt/rumble/bin or /usr/share/ec2-instance-connect may also cause false positives. Exclude these directories or specific executables from the rule to prevent unnecessary alerts.
+- System maintenance or configuration scripts that access the IMDS API for legitimate purposes might be flagged. Identify these scripts and add their paths or parent executables to the exclusion list to reduce noise.
+- Regular network monitoring tools that attempt connections to the IMDS IP address for health checks or status updates can be excluded by specifying their process names or executable paths in the exception criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected instance from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified in the alert that are attempting to access the IMDS API, especially those using tools like curl, wget, or python.
+- Revoke any temporary credentials that may have been exposed or accessed through the IMDS API to prevent unauthorized use.
+- Conduct a thorough review of the instance's security groups and IAM roles to ensure that only necessary permissions are granted and that there are no overly permissive policies.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources are affected.
+- Implement network monitoring to detect and alert on any future attempts to access the IMDS API from unauthorized processes or locations.
+- Review and update the instance's security configurations and apply any necessary patches or updates to mitigate vulnerabilities that could be exploited in similar attacks."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
index 14a99c7acf8..7cc08446c53 100644
--- a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
+++ b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,39 @@ process.name == "setfacl" and not (
   process.args == "/var/log/journal/"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Access Control List Modification via setfacl
+
+Access Control Lists (ACLs) in Linux enhance file permission management by allowing more granular access control. The `setfacl` command modifies these ACLs, potentially altering who can access or modify files. Adversaries may exploit `setfacl` to stealthily change permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of the setfacl command, focusing on the process.name and event.type fields to ensure the alert is valid.
+- Examine the process.command_line to understand the specific ACL modifications attempted and identify any unusual or unauthorized changes.
+- Investigate the user account associated with the process execution to determine if the action aligns with their typical behavior or role.
+- Check the process's parent process to identify how the setfacl command was initiated and assess if it was part of a legitimate workflow or a potential compromise.
+- Correlate the event with other security logs or alerts from the same host to identify any related suspicious activities or patterns that might indicate a broader attack.
+
+### False positive analysis
+
+- Routine system maintenance tasks may trigger the rule if they involve legitimate use of setfacl. To manage this, identify and document regular maintenance scripts or processes that use setfacl and create exceptions for these specific command lines.
+- Backup operations that restore ACLs using setfacl can be mistaken for suspicious activity. Exclude these by adding exceptions for command lines that match known backup procedures, such as those using the --restore option.
+- Automated log management tools might use setfacl to manage permissions on log directories like /var/log/journal/. To prevent false positives, exclude these specific directory paths from triggering the rule.
+- Custom applications or services that require dynamic permission changes using setfacl could be flagged. Review these applications and, if deemed safe, add their specific command patterns to the exception list to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
+- Review the process execution logs to identify any unauthorized users or processes that executed the `setfacl` command.
+- Revert any unauthorized ACL changes by restoring the original file permissions from a known good backup or configuration.
+- Conduct a thorough scan of the system for any additional signs of compromise, such as unauthorized user accounts or unexpected processes.
+- Update and patch the system to address any vulnerabilities that may have been exploited to gain access.
+- Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
index 581929efea0..8a51b79be43 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and
 process.args in ("auditd", "auditd.service")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Disable Auditd Service
+
+Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args.
+- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts.
+- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed.
+- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured.
+- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns.
+
+### False positive analysis
+
+- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts.
+- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment.
+- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions.
+- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities.
+- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert.
+- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
index 3d423f932de..df8a5967c54 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Disable IPTables or Firewall
+
+Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these firewalls to bypass security measures and facilitate malicious activities. The detection rule identifies suspicious processes that attempt to disable or stop firewall services, such as using commands to flush IPTables rules or halt firewall services, indicating potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details, including process.name and process.args, to confirm if the command was intended to disable or stop firewall services.
+- Check the process.parent.args to understand the context in which the suspicious process was executed, especially if it was triggered by a parent process with arguments like "force-stop".
+- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised.
+- Examine the host's recent activity logs for any other suspicious behavior or anomalies around the time of the alert, focusing on event.type "start" and event.action "exec" or "exec_event".
+- Assess the network traffic logs to identify any unusual inbound or outbound connections that might have occurred after the firewall was disabled or stopped.
+- Correlate this event with other alerts or incidents involving the same host or user to identify potential patterns or coordinated attack attempts.
+
+### False positive analysis
+
+- Routine system maintenance or updates may trigger the rule when legitimate processes like systemctl or service are used to stop or restart firewall services. To manage this, create exceptions for known maintenance scripts or scheduled tasks that perform these actions.
+- Network troubleshooting activities often involve temporarily disabling firewalls to diagnose connectivity issues. Users can exclude specific user accounts or IP addresses associated with network administrators from triggering the rule during these activities.
+- Automated deployment scripts that configure or reconfigure firewall settings might match the rule's criteria. Identify and whitelist these scripts by their process names or execution paths to prevent false positives.
+- Security software updates or installations may require temporary firewall adjustments, which could be flagged by the rule. Consider excluding processes associated with trusted security software vendors during update windows.
+- Development or testing environments often have different security requirements, leading to frequent firewall changes. Implement environment-specific exceptions to avoid false positives in these contexts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert, such as those attempting to disable or stop firewall services, to halt ongoing malicious activities.
+- Review and restore the firewall configurations to their last known good state to ensure that network traffic is properly controlled and unauthorized access is blocked.
+- Conduct a thorough examination of the affected system for any signs of compromise or additional malicious activity, focusing on logs and system changes around the time of the alert.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable firewall services promptly.
+- Review and update firewall policies and configurations to enhance security measures and prevent similar defense evasion tactics in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
index 11b15107458..afa53a4a986 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,40 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event",
    (process.name == "systemctl" and process.args in ("disable", "stop", "kill"))
  ) and process.args in ("syslog", "rsyslog", "syslog-ng", "syslog.service", "rsyslog.service", "syslog-ng.service")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Disable Syslog Service
+
+Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses.
+
+### Possible investigation steps
+
+- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious.
+- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted.
+- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script.
+- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack.
+- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack.
+
+### False positive analysis
+
+- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks.
+- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts.
+- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes.
+- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening.
+- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality.
+- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`.
+- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled.
+- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms.
+- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
index aa3acf071d1..22399510f46 100644
--- a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
+++ b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -80,6 +80,41 @@ process where host.os.type == "linux" and event.type == "start" and
  process.name in ("base16", "base32", "base32plain", "base32hex") and
 not process.args in ("--help", "--version")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Base16 or Base32 Encoding/Decoding Activity
+
+Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks.
+
+### Possible investigation steps
+
+- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks.
+- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program.
+- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns.
+- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains.
+- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly.
+- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths.
+- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems.
+- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts.
+- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments.
+- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes.
+- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity.
+- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
index b2a6a079cf5..be0c8087b9d 100644
--- a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
+++ b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,40 @@ file.Ext.original.path : (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 System Binary Moved or Copied
+
+System binaries are essential executables in Linux environments, crucial for system operations. Adversaries may move or copy these binaries to alternate locations to evade detection, often renaming them to blend in with legitimate processes. The detection rule identifies unusual movements or copies of these binaries, excluding common system processes and paths, to flag potential malicious activity. This helps in identifying attempts at masquerading, a tactic used to bypass security measures.
+
+### Possible investigation steps
+
+- Review the file path and name in the alert to determine if the binary was moved or copied to a suspicious or unusual location, which could indicate an attempt to masquerade.
+- Examine the process name and executable path that triggered the alert to identify if it is associated with known legitimate processes or if it appears suspicious or unexpected.
+- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user, which could suggest malicious intent.
+- Investigate the historical activity of the process and user involved to identify any patterns or previous suspicious behavior that might correlate with the current alert.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related activities or anomalies that could provide additional context or evidence of malicious activity.
+
+### False positive analysis
+
+- System updates and package installations often involve legitimate movement or copying of binaries. Exclude processes like dpkg, rpm, and apt-get from triggering alerts by adding them to the exception list.
+- Development and testing environments may frequently rename or move binaries for testing purposes. Consider excluding paths like /tmp or /dev/fd from monitoring if they are commonly used for non-malicious activities.
+- Automated scripts or configuration management tools such as Puppet or Chef may move binaries as part of their normal operations. Add these tools to the exception list to prevent unnecessary alerts.
+- Temporary files created during software installations or updates, such as those with extensions like .tmp or .dpkg-new, can trigger false positives. Exclude these extensions from monitoring to reduce noise.
+- Custom scripts or applications that mimic system processes for legitimate reasons might be flagged. Review and whitelist these specific scripts or applications if they are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are associated with the unauthorized movement or copying of system binaries.
+- Restore any altered or moved system binaries to their original locations and verify their integrity using known good backups or checksums.
+- Conduct a thorough review of system logs and the alert details to identify any additional indicators of compromise or related malicious activity.
+- 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 additional monitoring on the affected system and similar environments to detect any recurrence of the activity, focusing on the specific paths and processes identified in the alert.
+- Review and update access controls and permissions to ensure that only authorized users and processes can modify or move system binaries, reducing the risk of similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_chattr_immutable_file.toml b/rules/linux/defense_evasion_chattr_immutable_file.toml
index 6d5ba1837fd..cf939f21519 100644
--- a/rules/linux/defense_evasion_chattr_immutable_file.toml
+++ b/rules/linux/defense_evasion_chattr_immutable_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,40 @@ process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and n
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File made Immutable by Chattr
+
+The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args.
+- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd.
+- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious.
+- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files.
+- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors.
+
+### False positive analysis
+
+- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule.
+- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule.
+- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts.
+- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications.
+- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
index 92f07b4a59a..5a92e1e3792 100644
--- a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
+++ b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,39 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "dmesg" and process.args == "-c"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Clear Kernel Ring Buffer
+
+The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid.
+- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised.
+- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt.
+- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise.
+- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent.
+
+### False positive analysis
+
+- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command.
+- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts.
+- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts.
+- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found.
+- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed.
+- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`.
+- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
index ca6700c78de..339bbe54094 100644
--- a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
+++ b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Hidden Files and Directories via Hidden Flag
+
+In Unix-like systems, the 'hidden' flag can be set on files to conceal them from standard directory listings, a feature often exploited by adversaries to obscure malicious files. Attackers may use commands like `chflags` to apply this flag, making detection challenging. The detection rule targets file creation events involving `chflags`, helping identify potential misuse by monitoring for suspicious activity on Linux and macOS systems.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host operating system is Linux, as specified by the query field `host.os.type == "linux"`.
+- Examine the process execution details to verify that the `chflags` command was used, as indicated by `process.name == "chflags"`.
+- Investigate the file creation event to identify the specific file or directory that had the 'hidden' flag applied, focusing on the `event.type == "creation"` field.
+- Check the user account associated with the `chflags` command execution to determine if it aligns with expected user behavior or if it might indicate unauthorized access.
+- Analyze recent system logs and user activity on the affected host to identify any other suspicious behavior or anomalies that could suggest malicious intent.
+- Correlate this event with other alerts or indicators of compromise on the same host to assess if this is part of a larger attack pattern or isolated incident.
+
+### False positive analysis
+
+- System maintenance scripts may use the chflags command to manage file visibility for legitimate purposes. Review scheduled tasks and scripts to identify benign uses and create exceptions for these processes.
+- Backup and recovery operations might employ the hidden flag to protect critical files from accidental deletion. Verify backup software configurations and exclude these operations from triggering alerts.
+- Development environments could use hidden files to manage version control or configuration settings. Collaborate with development teams to understand their workflows and whitelist known development-related activities.
+- Security tools and utilities may use the hidden flag as part of their normal operation to protect sensitive files. Identify these tools and add them to an exception list to prevent unnecessary alerts.
+- User customization scripts might apply the hidden flag to personalize the user environment. Engage with users to document these customizations and exclude them from detection rules.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes associated with `chflags` to halt any ongoing attempts to hide files.
+- Conduct a thorough review of recently created files and directories on the affected system to identify and assess any hidden files for malicious content.
+- Restore any critical files that may have been hidden or altered from known good backups to ensure system integrity.
+- Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden flag, on critical systems.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_directory_creation_in_bin.toml b/rules/linux/defense_evasion_directory_creation_in_bin.toml
index a38e54d6203..3721241207a 100644
--- a/rules/linux/defense_evasion_directory_creation_in_bin.toml
+++ b/rules/linux/defense_evasion_directory_creation_in_bin.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,40 @@ process where host.os.type == "linux" and event.type == "start" and
   process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
 not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Directory Creation in /bin directory
+
+The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin.
+- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one.
+- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack.
+- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level.
+- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise.
+
+### False positive analysis
+
+- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm.
+- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule.
+- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts.
+- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity.
+- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts.
+- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality.
+- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_disable_apparmor_attempt.toml b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
index 3c61939ffe3..a5ca2b34d3e 100644
--- a/rules/linux/defense_evasion_disable_apparmor_attempt.toml
+++ b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,41 @@ process where host.os.type == "linux" and event.type == "start" and
   (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Disabling of AppArmor
+
+AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses.
+
+### Possible investigation steps
+
+- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor.
+- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered.
+- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security.
+- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign.
+- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways.
+
+### False positive analysis
+
+- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts.
+- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts.
+- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities.
+- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities.
+- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
+- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
+- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_disable_selinux_attempt.toml b/rules/linux/defense_evasion_disable_selinux_attempt.toml
index 491a0e169ca..543966a140a 100644
--- a/rules/linux/defense_evasion_disable_selinux_attempt.toml
+++ b/rules/linux/defense_evasion_disable_selinux_attempt.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,40 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name == "setenforce" and process.args == "0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Disabling of SELinux
+
+SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for the execution of the 'setenforce 0' command, which switches SELinux to permissive mode, effectively disabling its enforcement capabilities. This rule leverages process monitoring to alert security teams of potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the 'setenforce 0' command, ensuring that the process name is 'setenforce' and the argument is '0'.
+- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential compromised account.
+- Investigate the timeline of events leading up to and following the execution of the 'setenforce 0' command to identify any related suspicious activities or processes.
+- Examine system logs and audit logs for any other unusual or unauthorized changes to SELinux settings or other security configurations.
+- Assess the system for any signs of compromise or malicious activity, such as unexpected network connections, file modifications, or the presence of known malware indicators.
+- Verify the current SELinux status and configuration to ensure it has been restored to enforcing mode if it was indeed set to permissive mode.
+
+### False positive analysis
+
+- System administrators may execute the 'setenforce 0' command during routine maintenance or troubleshooting, leading to false positives. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Some automated scripts or configuration management tools might temporarily set SELinux to permissive mode for deployment purposes. Identify these scripts and exclude their execution context from triggering alerts.
+- Development environments might require SELinux to be set to permissive mode for testing purposes. Consider excluding specific development hosts or environments from the rule to prevent unnecessary alerts.
+- In certain cases, SELinux might be disabled as part of a controlled security audit or penetration test. Coordinate with security teams to whitelist these activities during the audit period.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Verify the current SELinux status on the affected system using the command `sestatus` to confirm if it has been switched to permissive mode.
+- If SELinux is in permissive mode, re-enable it by executing `setenforce 1` and ensure that the SELinux policy is correctly enforced.
+- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or suspicious activities that occurred while SELinux was disabled.
+- Scan the affected system for malware or unauthorized software installations using a trusted antivirus or endpoint detection and response (EDR) tool.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement additional monitoring and alerting for similar SELinux-related events to enhance detection capabilities and prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
index 1b325e4f75f..05fce5c3b7d 100644
--- a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
+++ b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,40 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and event.type != "deletion" and file.path == "/etc/doas.conf"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Defense Evasion via Doas
+
+Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or escalate privileges, bypassing security measures. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential misuse aimed at evading defenses.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion", as specified in the query.
+- Check the timestamp of the alert to determine when the configuration file was created or modified, and correlate this with any known scheduled changes or maintenance activities.
+- Investigate the user account associated with the event to determine if they have legitimate reasons to modify the Doas configuration file, and verify their access permissions.
+- Examine system logs and command history around the time of the alert to identify any suspicious activities or commands executed by the user.
+- Assess the current Doas configuration file for unauthorized changes or entries that could indicate privilege escalation attempts.
+- Cross-reference the alert with other security events or alerts from the same host to identify potential patterns or related activities that could suggest a broader attack.
+
+### False positive analysis
+
+- Routine administrative updates to the Doas configuration file can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for legitimate updates.
+- Automated configuration management tools may modify the Doas configuration file as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process names or user accounts.
+- System backups or restoration processes might involve creating or renaming the Doas configuration file. Exclude these processes by identifying the backup software and adding it to the exception list.
+- Development or testing environments where frequent changes to the Doas configuration file are expected can generate false positives. Consider excluding these environments from monitoring or adjusting the rule to account for their unique activity patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Review and revert any unauthorized changes to the Doas configuration file located at /etc/doas.conf to its last known good state.
+- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege escalations.
+- Implement additional monitoring on the affected system to detect any further attempts to modify the Doas configuration file or other critical system files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
+- Review and enhance access controls and authentication mechanisms to prevent unauthorized privilege escalation attempts in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
index 2e7b12d950d..a0b6027a4e1 100644
--- a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
+++ b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -80,6 +80,40 @@ not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Dynamic Linker Creation or Modification
+
+The dynamic linker in Linux systems is crucial for loading shared libraries needed by programs at runtime. Adversaries may exploit this by altering linker configuration files to hijack program execution, enabling persistence or evasion. The detection rule identifies suspicious creation or renaming of these files, excluding benign processes and extensions, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the file path involved in the alert to determine if it matches any of the critical dynamic linker configuration files such as /etc/ld.so.preload, /etc/ld.so.conf.d/*, or /etc/ld.so.conf.
+- Identify the process that triggered the alert by examining the process.executable field and verify if it is listed as a benign process in the exclusion list. If not, investigate the legitimacy of the process.
+- Check the file extension and file.Ext.original.extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like swp, swpx, swx, or dpkg-new.
+- Investigate the process.name field to determine if the process is a known system utility like java, sed, or perl, and assess if its usage in this context is typical or suspicious.
+- Gather additional context by reviewing recent system logs and other security alerts to identify any related or preceding suspicious activities that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- Package management operations can trigger false positives when legitimate package managers like dpkg, rpm, or yum modify linker configuration files. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts.
+- System updates or software installations often involve temporary file modifications with extensions like swp or dpkg-new. Exclude these extensions to reduce false positives.
+- Automated system management tools such as Puppet or Chef may modify linker files as part of their configuration management tasks. Add these tools to the exclusion list to avoid false alerts.
+- Virtualization and containerization platforms like Docker or VMware may alter linker configurations during normal operations. Verify these processes and exclude them if they are part of routine system behavior.
+- Custom scripts or applications that use common names like sed or perl might be flagged if they interact with linker files. Review these scripts and consider excluding them if they are verified as safe.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Review and restore the original dynamic linker configuration files from a known good backup to ensure the integrity of the system's execution flow.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or scripts.
+- Analyze system logs and the process execution history to identify the source of the unauthorized changes and determine if any other systems may be compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the organization.
+- Implement additional monitoring on the affected system and similar systems to detect any future attempts to modify dynamic linker configuration files.
+- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify critical system files, reducing the risk of similar incidents in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
index 6bf55b5f216..81ee59285f9 100644
--- a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
+++ b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,41 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name == "touch" and process.args == "-r" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 ESXI Timestomping using Touch Command
+
+VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*".
+- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account.
+- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities.
+- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies.
+- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
+- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor.
+
+### False positive analysis
+
+- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions.
+- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
+- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows.
+- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives.
+- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files.
+- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities.
+- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations.
+- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot.
+- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited.
+- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_file_deletion_via_shred.toml b/rules/linux/defense_evasion_file_deletion_via_shred.toml
index e942a964e63..7989ced7ec0 100644
--- a/rules/linux/defense_evasion_file_deletion_via_shred.toml
+++ b/rules/linux/defense_evasion_file_deletion_via_shred.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,40 @@ process where host.os.type == "linux" and event.type == "start" and process.name
   "-u", "--remove", "-z", "--zero"
 ) and not process.parent.name == "logrotate"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File Deletion via Shred
+
+The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero".
+- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user.
+- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious.
+- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications.
+- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise.
+- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security.
+
+### False positive analysis
+
+- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts.
+- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts.
+- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management.
+- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration.
+- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion.
+- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary.
+- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source.
+- 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 enhanced monitoring on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools.
+- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_file_mod_writable_dir.toml b/rules/linux/defense_evasion_file_mod_writable_dir.toml
index 7c4265bf95b..13646f48834 100644
--- a/rules/linux/defense_evasion_file_mod_writable_dir.toml
+++ b/rules/linux/defense_evasion_file_mod_writable_dir.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,40 @@ host.os.type:linux and event.category:process and event.type:start and
 process.name:(chattr or chgrp or chmod or chown) and process.working_directory:(/dev/shm or /tmp or /var/tmp) and
 not process.parent.name:(apt-key or update-motd-updates-available or apt-get)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File Permission Modification in Writable Directory
+
+In Linux environments, writable directories like /tmp or /var/tmp are often used for temporary file storage. Adversaries exploit these by modifying file permissions to execute malicious payloads. The detection rule identifies non-root users altering permissions in these directories using commands like chmod or chown, excluding benign processes, to flag potential threats. This helps in identifying unauthorized permission changes indicative of defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to identify the non-root user who executed the permission modification command (chattr, chgrp, chmod, or chown) in the specified writable directories (/dev/shm, /tmp, or /var/tmp).
+- Examine the parent process of the detected command to determine if it is associated with any known malicious activity or if it deviates from typical user behavior, ensuring it is not one of the excluded benign processes (apt-key, update-motd-updates-available, apt-get).
+- Investigate the specific file or directory whose permissions were altered to assess its legitimacy and check for any associated suspicious files or payloads.
+- Analyze recent activities by the identified user to detect any other anomalous behavior or unauthorized access attempts that could indicate a broader compromise.
+- Cross-reference the event with other security logs and alerts to identify any correlated incidents or patterns that might suggest a coordinated attack or persistent threat.
+
+### False positive analysis
+
+- System updates and maintenance scripts may trigger permission changes in writable directories. Exclude processes like apt-key, update-motd-updates-available, and apt-get to reduce noise from legitimate system activities.
+- Development and testing environments often involve frequent permission changes by non-root users. Consider excluding specific user accounts or processes known to be part of regular development workflows.
+- Automated backup or synchronization tools might modify file permissions as part of their operations. Identify and exclude these tools if they are verified to be non-threatening.
+- Custom scripts or applications that require permission changes for functionality should be reviewed and, if deemed safe, added to an exception list to prevent false alerts.
+- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified in the alert that are associated with unauthorized permission changes.
+- Revert any unauthorized file permission changes in the writable directories to their original state to prevent execution of malicious payloads.
+- Conduct a thorough scan of the affected directories (/dev/shm, /tmp, /var/tmp) for any malicious files or payloads and remove them.
+- Review user accounts and permissions to ensure that only authorized users have access to modify file permissions in sensitive directories.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for file permission changes in writable directories to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_hex_payload_execution.toml b/rules/linux/defense_evasion_hex_payload_execution.toml
index 2077dd5f76e..becce22f8b1 100644
--- a/rules/linux/defense_evasion_hex_payload_execution.toml
+++ b/rules/linux/defense_evasion_hex_payload_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,41 @@ process where host.os.type == "linux" and event.type == "start" and
     (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Hex Payload Execution
+
+Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities.
+- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow.
+- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised.
+- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses.
+- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further.
+- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity.
+
+### False positive analysis
+
+- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule.
+- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts.
+- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious.
+- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule.
+- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious payloads.
+- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants.
+- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
+- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_directory_creation.toml b/rules/linux/defense_evasion_hidden_directory_creation.toml
index 621d5aa8d1d..8418391f3e1 100644
--- a/rules/linux/defense_evasion_hidden_directory_creation.toml
+++ b/rules/linux/defense_evasion_hidden_directory_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,41 @@ process.name == "mkdir" and process.parent.executable like (
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Hidden Directory Creation via Unusual Parent
+
+In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files but can be exploited by attackers to conceal malicious activities. Adversaries may create these directories using unexpected parent processes in sensitive locations. The detection rule identifies such anomalies by monitoring directory creation commands executed by unusual parent executables, focusing on specific directories and excluding known benign patterns.
+
+### Possible investigation steps
+
+- Review the process.parent.executable field to identify the parent process that initiated the directory creation and assess its legitimacy based on its typical behavior and location.
+- Examine the process.args field to understand the specific arguments used with the mkdir command, focusing on the directory path and any patterns that may indicate malicious intent.
+- Check the process.command_line field for any unusual or suspicious command-line patterns that might suggest an attempt to evade detection.
+- Investigate the context of the parent process by reviewing recent activities or logs associated with it, especially if it originates from sensitive directories like /dev/shm, /tmp, or /var/tmp.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise.
+- Consult threat intelligence sources or databases to determine if the parent executable or directory path has been associated with known malicious activities or threat actors.
+
+### False positive analysis
+
+- Temporary directories used by legitimate applications can trigger false positives. Exclude known benign parent executables like those in "/tmp/newroot/*" or "/run/containerd/*" to reduce noise.
+- Automated build processes may create hidden directories during software compilation. Add exceptions for parent executables such as "/var/tmp/buildah*" or "/tmp/python-build.*" to prevent unnecessary alerts.
+- Development tools and scripts might create hidden directories for caching or temporary storage. Consider excluding parent executables like "/tmp/pear/temp/*" or "/tmp/cliphist-wofi-img" if they are part of regular development activities.
+- Ensure that the command line patterns like "mkdir -p ." or "mkdir ./*" are excluded, as these are common in scripts and do not typically indicate malicious intent.
+- Regularly review and update the list of excluded patterns and parent executables to align with changes in the environment and reduce false positives effectively.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with the unusual parent executable identified in the alert to halt potential malicious operations.
+- Conduct a thorough review of the hidden directory and its contents to identify and remove any malicious files or tools.
+- Restore any affected files or configurations from a known good backup to ensure system integrity.
+- Implement stricter access controls and monitoring on sensitive directories to prevent unauthorized directory creation.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
index f013e542b90..efd76398391 100644
--- a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
+++ b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,41 @@ not process.name in (
   "command-not-found"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation of Hidden Files and Directories via CommandLine
+
+In Linux environments, files and directories prefixed with a dot (.) are hidden by default, a feature often exploited by adversaries to conceal malicious activities. Attackers may create hidden files in writable directories like /tmp to evade detection. The detection rule identifies suspicious processes creating such hidden files, excluding benign commands, to flag potential threats. This helps in uncovering stealthy persistence and defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to identify the command executed, focusing on the process.working_directory field to confirm if the hidden file was created in a common writable directory like /tmp, /var/tmp, or /dev/shm.
+- Examine the process.args field to determine the specific hidden file or directory name created, and assess if it matches known malicious patterns or naming conventions.
+- Check the process lineage by investigating the parent process to understand the context of how the hidden file creation was initiated and identify any potential malicious parent processes.
+- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised, and review recent activities by this user for any anomalies.
+- Search for any additional hidden files or directories created around the same time or by the same process to identify further suspicious activities or artifacts.
+- Correlate this event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise.
+
+### False positive analysis
+
+- System maintenance scripts may create hidden files in directories like /tmp for temporary storage. Review these scripts and consider excluding them if they are verified as non-threatening.
+- Development tools and processes, such as version control systems or build scripts, might generate hidden files for configuration or state tracking. Identify these tools and add them to the exclusion list if they are part of regular operations.
+- Monitoring and logging tools may use hidden files to store temporary data or logs. Verify these tools and exclude them if they are essential for system monitoring.
+- User-specific applications or scripts might create hidden files for legitimate purposes. Conduct a review of user activities and exclude known benign applications to reduce noise.
+- Automated backup or synchronization services could generate hidden files as part of their operation. Confirm these services and exclude them if they are part of the expected environment setup.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes identified by the detection rule that are creating hidden files in the specified directories.
+- Remove any hidden files or directories created by unauthorized processes in the /tmp, /var/tmp, and /dev/shm directories to eliminate potential persistence mechanisms.
+- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
+- Restore any affected files or system components from a known good backup to ensure system integrity.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for similar activities to improve detection and response capabilities for future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_hidden_shared_object.toml b/rules/linux/defense_evasion_hidden_shared_object.toml
index 3f6201d9255..8bb847f64f2 100644
--- a/rules/linux/defense_evasion_hidden_shared_object.toml
+++ b/rules/linux/defense_evasion_hidden_shared_object.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,40 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and file.extension == "so" and file.name : ".*.so" and
 not process.name == "dockerd"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation of Hidden Shared Object File
+
+Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename.
+- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious.
+- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation.
+- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise.
+- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities.
+- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism.
+
+### False positive analysis
+
+- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows.
+- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts.
+- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening.
+- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker.
+- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts.
+- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise.
+- 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 enhanced monitoring and alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
index caeffc29de3..43691835f98 100644
--- a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
+++ b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/04"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,42 @@ event.category:process and host.os.type:linux and event.type:start and event.act
   (user.name:daemon and process.name:at)
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Interactive Shell Launched from System User
+
+In Linux environments, system users are typically non-interactive and serve specific system functions. Adversaries may exploit these accounts to launch interactive shells, bypassing security measures and evading detection. The detection rule identifies such anomalies by monitoring process activities linked to system users, excluding legitimate processes, and flagging unexpected interactive shell launches, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific interactive shell that was launched, focusing on the process.interactive:true field.
+- Examine the user.name field to determine which system user account was used to launch the shell and assess whether this account should have interactive shell access.
+- Investigate the process.parent.executable and process.parent.name fields to understand the parent process that initiated the shell, checking for any unusual or unauthorized parent processes.
+- Analyze the process.args field for any suspicious or unexpected command-line arguments that might indicate malicious intent.
+- Cross-reference the event.timestamp with other security logs to identify any correlated activities or anomalies around the same time frame.
+- Check for any recent changes or anomalies in the system user's account settings or permissions that could have facilitated the shell launch.
+- Assess the risk and impact of the activity by considering the context of the system and the potential for further malicious actions.
+
+### False positive analysis
+
+- System maintenance tasks may trigger interactive shells from system users like 'daemon' or 'systemd-timesync'. To handle these, review the specific maintenance scripts and add exceptions for known benign processes.
+- Automated backup or update processes might launch interactive shells under system users such as 'backup' or 'apt'. Identify these processes and exclude them by adding their parent process names or arguments to the exception list.
+- Some monitoring or logging tools may use system accounts like 'messagebus' or 'dbus' to execute interactive shells. Verify these tools and exclude their activities if they are legitimate and necessary for system operations.
+- Custom scripts or applications running under system users for specific tasks could be misidentified. Document these scripts and add their process names to the exclusion criteria to prevent false alerts.
+- In environments where certain system users are repurposed for non-standard tasks, ensure these tasks are documented and create exceptions for their associated processes to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious interactive shell sessions initiated by system users to halt potential malicious activities.
+- Conduct a thorough review of the affected system's logs and processes to identify any additional indicators of compromise or unauthorized changes.
+- Reset credentials for the compromised system user accounts and any other accounts that may have been accessed or affected.
+- Implement stricter access controls and monitoring for system user accounts to prevent unauthorized interactive shell launches in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update detection mechanisms and rules to enhance monitoring for similar threats, ensuring that any future attempts are quickly identified and addressed."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
diff --git a/rules/linux/defense_evasion_kernel_module_removal.toml b/rules/linux/defense_evasion_kernel_module_removal.toml
index 3b7b0ffd12f..fb12c921d8f 100644
--- a/rules/linux/defense_evasion_kernel_module_removal.toml
+++ b/rules/linux/defense_evasion_kernel_module_removal.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,41 @@ process where host.os.type == "linux" and event.type == "start" and
   ) and
   process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kernel Module Removal
+
+Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria.
+- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated.
+- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
+- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics.
+- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted.
+- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly.
+- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
+- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening.
+- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise.
+- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact.
+- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_kthreadd_masquerading.toml b/rules/linux/defense_evasion_kthreadd_masquerading.toml
index af5551a5132..bd3a8116434 100644
--- a/rules/linux/defense_evasion_kthreadd_masquerading.toml
+++ b/rules/linux/defense_evasion_kthreadd_masquerading.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,40 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name : ("kworker*", "kthread*") and process.executable != null
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Executable Masquerading as Kernel Process
+
+In Linux environments, kernel processes like `kthreadd` and `kworker` typically run without associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes with non-empty executable fields, indicating potential masquerading attempts. This helps in uncovering stealthy threats that mimic legitimate system activities.
+
+### Possible investigation steps
+
+- Review the process details for the flagged process, focusing on the process.executable field to identify the path and name of the executable. This can provide initial insights into whether the executable is legitimate or potentially malicious.
+- Check the process's parent process (process.parent) to understand the context in which the process was started. This can help determine if the process was spawned by a legitimate system process or a suspicious one.
+- Investigate the file at the path specified in the process.executable field. Verify its legitimacy by checking its hash against known malware databases or using a file reputation service.
+- Examine the process's command line arguments (process.command_line) for any unusual or suspicious parameters that might indicate malicious activity.
+- Review recent system logs and events around the time the process was started to identify any related activities or anomalies that could provide additional context or evidence of compromise.
+- If available, use threat intelligence sources to check for any known indicators of compromise (IOCs) related to the process name or executable path.
+
+### False positive analysis
+
+- Custom scripts or administrative tools may be named similarly to kernel processes for convenience or organizational standards. Review these scripts and tools to ensure they are legitimate and consider adding them to an exception list if verified.
+- Some legitimate software or monitoring tools might use kernel-like names for their processes to integrate closely with system operations. Verify the source and purpose of these processes and exclude them if they are confirmed to be non-malicious.
+- System updates or patches might temporarily create processes with kernel-like names that have executable paths. Monitor these occurrences and exclude them if they are part of a verified update process.
+- Development or testing environments may intentionally use kernel-like names for process simulation. Ensure these environments are isolated and add exceptions for these processes if they are part of controlled testing scenarios.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the suspicious process immediately to stop any ongoing malicious actions. Use process management tools to kill the process identified by the alert.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the intrusion.
+- Remove any malicious executables or files associated with the masquerading process from the system to ensure complete remediation.
+- Restore the system from a known good backup if the integrity of the system is compromised, ensuring that the backup is free from any malicious artifacts.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker, ensuring all software and security tools are up to date.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_ld_so_creation.toml b/rules/linux/defense_evasion_ld_so_creation.toml
index e7cda7b8898..0cee4f4a0ab 100644
--- a/rules/linux/defense_evasion_ld_so_creation.toml
+++ b/rules/linux/defense_evasion_ld_so_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,42 @@ file where host.os.type == "linux" and event.type == "creation" and process.exec
 file.path like~ ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and
 not process.name in ("dockerd", "yum", "dnf", "microdnf", "pacman")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Dynamic Linker (ld.so) Creation
+
+The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, achieving persistence or evading defenses. The detection rule identifies suspicious creation of ld.so files, excluding benign processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process that triggered the alert by examining the process.executable field to understand which application attempted to create the ld.so file.
+- Check the process.name field to ensure the process is not one of the benign processes listed in the exclusion criteria, such as "dockerd", "yum", "dnf", "microdnf", or "pacman".
+- Investigate the file.path to confirm the location of the newly created ld.so file and verify if it matches any of the specified directories like "/lib", "/lib64", "/usr/lib", or "/usr/lib64".
+- Analyze the parent process of the suspicious executable to determine if it was initiated by a legitimate or potentially malicious source.
+- Look for any recent changes or anomalies in the system logs around the time of the file creation event to identify any related suspicious activities.
+- Cross-reference the event with other security tools or logs, such as Elastic Defend or SentinelOne, to gather additional context or corroborating evidence of malicious activity.
+- Assess the risk and impact of the event by considering the system's role and the potential consequences of a compromised dynamic linker on that system.
+
+### False positive analysis
+
+- Package managers like yum, dnf, microdnf, and pacman can trigger false positives when they update or install packages that involve the dynamic linker. These processes are already excluded in the rule, but ensure any custom package managers or scripts are also considered for exclusion.
+- Container management tools such as dockerd may create or modify ld.so files during container operations. If you use other container tools, consider adding them to the exclusion list to prevent false positives.
+- System updates or maintenance scripts that involve library updates might create ld.so files. Review these scripts and add them to the exclusion list if they are verified as non-threatening.
+- Custom administrative scripts or automation tools that interact with shared libraries could inadvertently trigger the rule. Identify these scripts and exclude them if they are part of regular, secure operations.
+- Development environments where ld.so files are frequently created or modified during testing and compilation processes may need specific exclusions for development tools or environments to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the integrity of the dynamic linker (ld.so) on the affected system by comparing it with a known good version from a trusted source or repository.
+- If the dynamic linker has been tampered with, replace it with the verified version and ensure all system binaries are intact.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious files or processes.
+- Review system logs and the process creation history to identify the source of the unauthorized ld.so creation and any associated malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Implement additional monitoring and alerting for similar suspicious activities, such as unauthorized file creations in critical system directories, to enhance future detection capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_log_files_deleted.toml b/rules/linux/defense_evasion_log_files_deleted.toml
index 4004647cc05..1f258e11a0a 100644
--- a/rules/linux/defense_evasion_log_files_deleted.toml
+++ b/rules/linux/defense_evasion_log_files_deleted.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,41 @@ file where host.os.type == "linux" and event.type == "deletion" and
     ) and
     not process.name in ("gzip", "executor", "dockerd")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 System Log File Deletion
+
+System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions.
+
+### Possible investigation steps
+
+- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert.
+- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity.
+- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available.
+- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised.
+- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise.
+- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file.
+
+### False positive analysis
+
+- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule.
+- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening.
+- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts.
+- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature.
+- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.
+- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity.
+- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach.
+- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies.
+- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_mount_execution.toml b/rules/linux/defense_evasion_mount_execution.toml
index 9d6d2c01c6b..321677f4be1 100644
--- a/rules/linux/defense_evasion_mount_execution.toml
+++ b/rules/linux/defense_evasion_mount_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,41 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and
   not process.parent.command_line like "/opt/cloudlinux/*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Hidden Process via Mount Hidepid
+
+The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'.
+- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary.
+- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script.
+- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert.
+- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'.
+- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert.
+
+### False positive analysis
+
+- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs.
+- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
+- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection.
+- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts.
+- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes.
+- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed.
+- Terminate any identified malicious processes and remove any associated files or scripts from the system.
+- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_potential_proot_exploits.toml b/rules/linux/defense_evasion_potential_proot_exploits.toml
index d5a8be6b691..37a3fa35661 100644
--- a/rules/linux/defense_evasion_potential_proot_exploits.toml
+++ b/rules/linux/defense_evasion_potential_proot_exploits.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,39 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.parent.name == "proot"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Defense Evasion via PRoot
+
+PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent.
+- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed.
+- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent.
+- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe.
+
+### False positive analysis
+
+- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes.
+- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts.
+- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope.
+- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources.
+- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes.
+- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot.
+- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise.
+- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_rename_esxi_files.toml b/rules/linux/defense_evasion_rename_esxi_files.toml
index 114e0492005..464795fc2cb 100644
--- a/rules/linux/defense_evasion_rename_esxi_files.toml
+++ b/rules/linux/defense_evasion_rename_esxi_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ file where host.os.type == "linux" and event.action == "rename" and
 file.Ext.original.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
 and not file.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Renaming of ESXI Files
+
+VMware ESXi files are critical for virtual machine operations, storing configurations and states. Adversaries may rename these files to evade detection or disrupt services, a tactic known as masquerading. The detection rule identifies renaming events of specific VMware file types on Linux systems, flagging potential malicious activity by monitoring deviations from expected file extensions.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file that was renamed, including its original and new name, to understand the nature of the change.
+- Check the timestamp of the rename event to correlate it with other activities on the system, such as user logins or other file operations, to identify potential patterns or anomalies.
+- Investigate the user account or process responsible for the rename action by examining system logs or user activity to determine if the action was authorized or suspicious.
+- Analyze the system for any other recent rename events involving VMware-related files to assess if this is an isolated incident or part of a broader pattern.
+- Examine the system for signs of compromise or unauthorized access, such as unexpected processes, network connections, or changes in system configurations, to identify potential threats.
+- Consult with relevant stakeholders, such as system administrators or security teams, to verify if the rename action was part of a legitimate maintenance or operational task.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may involve renaming VMware ESXi files for organizational purposes. To manage this, identify and exclude specific users or processes that regularly perform these tasks from triggering alerts.
+- Automated backup or snapshot processes might rename files temporarily as part of their operation. Review and whitelist these processes to prevent unnecessary alerts.
+- Development or testing environments often involve frequent renaming of virtual machine files for configuration testing. Consider excluding these environments from the rule or setting up a separate monitoring profile with adjusted thresholds.
+- System updates or patches might include scripts that rename files as part of the update process. Verify and exclude these scripts if they are known and trusted.
+- Custom scripts or tools used by IT teams for managing virtual machines may rename files as part of their functionality. Ensure these scripts are documented and excluded from triggering the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or potential spread of malicious activity.
+- Verify the integrity of the renamed VMware ESXi files by comparing them with known good backups or snapshots, and restore any altered files from a secure backup if necessary.
+- Conduct a thorough review of recent system logs and user activity to identify any unauthorized access or actions that may have led to the file renaming.
+- Revert any unauthorized changes to system configurations or permissions that may have facilitated the renaming of critical files.
+- 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 additional monitoring on the affected system and similar environments to detect any further attempts at file masquerading or other suspicious activities.
+- Review and update access controls and permissions for VMware ESXi files to ensure only authorized users have the ability to rename or modify these files."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_rename_esxi_index_file.toml b/rules/linux/defense_evasion_rename_esxi_index_file.toml
index c9061d947da..f8f22fb3ac7 100644
--- a/rules/linux/defense_evasion_rename_esxi_index_file.toml
+++ b/rules/linux/defense_evasion_rename_esxi_index_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ query = '''
 file where host.os.type == "linux" and event.action == "rename" and file.name : "index.html" and
 file.Ext.original.path : "/usr/lib/vmware/*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Renaming of ESXI index.html File
+
+VMware ESXi hosts use the index.html file within their web interface for management tasks. Adversaries may rename this file to evade detection or to replace it with a malicious version, facilitating unauthorized access or data exfiltration. The detection rule monitors Linux systems for renaming actions targeting this file in the VMware directory, flagging potential defense evasion attempts by correlating file path and event actions.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path and event action, ensuring the "rename" action occurred on the "index.html" file within the "/usr/lib/vmware/*" directory.
+- Check the timestamp of the rename event to determine when the activity occurred and correlate it with any other suspicious activities or alerts around the same time.
+- Identify the user or process responsible for the rename action by examining the associated user account and process details in the event logs.
+- Investigate the system's recent login history and user activity to identify any unauthorized access or anomalies that could be linked to the rename event.
+- Analyze the renamed file and any new files in the directory for signs of tampering or malicious content, using file integrity monitoring tools or antivirus scans.
+- Review network logs for any unusual outbound connections from the affected host that could indicate data exfiltration or communication with a command and control server.
+- Consider isolating the affected host from the network to prevent further potential malicious activity while the investigation is ongoing.
+
+### False positive analysis
+
+- Routine maintenance or updates on VMware ESXi hosts may involve renaming the index.html file temporarily. Users can create exceptions for known maintenance windows to prevent unnecessary alerts.
+- Automated scripts or backup processes might rename the index.html file as part of their operations. Identify and whitelist these scripts or processes to avoid false positives.
+- System administrators may manually rename the index.html file for legitimate customization or troubleshooting purposes. Document and exclude these actions by specific user accounts or during specific time frames.
+- Security tools or monitoring solutions might trigger renaming actions as part of their scanning or remediation tasks. Verify and exclude these tools from the rule to reduce false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected VMware ESXi host from the network to prevent further unauthorized access or data exfiltration.
+- Verify the integrity of the index.html file by comparing it with a known good version from a trusted source to determine if it has been tampered with or replaced.
+- Restore the original index.html file from a secure backup if it has been altered or replaced, ensuring that the backup is from a time before the suspicious activity was detected.
+- Conduct a thorough review of recent access logs and system changes on the affected host to identify any unauthorized access or modifications that may have occurred.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be compromised.
+- Implement additional monitoring on the affected host and similar systems to detect any further attempts to rename or modify critical files.
+- Review and update access controls and permissions on the VMware ESXi host to ensure that only authorized personnel have the ability to modify critical system files."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/defense_evasion_root_certificate_installation.toml b/rules/linux/defense_evasion_root_certificate_installation.toml
index c462f2c7dab..6ba56e5ca95 100644
--- a/rules/linux/defense_evasion_root_certificate_installation.toml
+++ b/rules/linux/defense_evasion_root_certificate_installation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,41 @@ process.name in ("update-ca-trust", "update-ca-certificates") and not (
   (process.parent.name in ("sh", "bash", "zsh") and process.args == "-e")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Root Certificate Installation
+
+Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of entities. Adversaries exploit this by installing rogue root certificates on compromised Linux systems, thus bypassing security warnings and facilitating undetected command and control communications. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of "update-ca-trust" or "update-ca-certificates" on the Linux host, focusing on the event type "start" and action "exec" or "exec_event".
+- Examine the parent process name and arguments to ensure they do not match any of the legitimate exclusions such as "ca-certificates.postinst", "pacman", or "/var/tmp/rpm*".
+- Investigate the user account associated with the process to determine if it is a known or expected user for such operations.
+- Check the system logs and recent changes to identify any unauthorized modifications or installations that coincide with the alert.
+- Correlate the alert with other security events or logs to identify any potential command and control communications or other suspicious activities on the host.
+- Assess the network connections from the host around the time of the alert to detect any unusual or unauthorized outbound traffic.
+
+### False positive analysis
+
+- Legitimate system updates or package installations may trigger the rule when processes like "update-ca-trust" or "update-ca-certificates" are executed by trusted package managers such as "pacman" or "pamac-daemon". To mitigate this, ensure these parent processes are included in the exclusion list.
+- Automated scripts or system maintenance tasks that use shell scripts (e.g., "sh", "bash", "zsh") to update certificates might be flagged. If these scripts are verified as safe, consider adding specific script names or paths to the exclusion criteria.
+- Custom applications or services that require certificate updates and are known to be safe can be excluded by adding their parent process names to the exclusion list, ensuring they do not trigger false alerts.
+- Security tools or agents like "kesl" or "execd" that manage certificates as part of their operations may cause false positives. Verify their activities and include them in the exclusion list if they are part of legitimate security operations.
+- Temporary files or scripts located in directories like "/var/tmp/rpm*" used during legitimate installations should be reviewed and excluded if they are part of routine system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further unauthorized communications with potential command and control servers.
+- Revoke any unauthorized root certificates installed on the system by removing them from the trusted certificate store to restore the integrity of the system's trust chain.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or changes made by the adversary.
+- Restore the system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary.
+- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process executions related to certificate management.
+- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
index 46d5a10dc28..3b1a3fbcc78 100644
--- a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
+++ b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.16.2 for the SentinelOne Integration."
 min_stack_version = "8.16.2"
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,42 @@ query = '''
 file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event")
 and file.path : "/etc/selinux/config"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SELinux Configuration Creation or Renaming
+
+SELinux, a Linux kernel security module, enforces access control policies to protect systems. Adversaries may target the SELinux configuration file to disable or alter these defenses, facilitating unauthorized access or evasion of security measures. The detection rule identifies suspicious activities like file creation or renaming in the SELinux configuration path, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event action is either "creation", "file_create_event", "rename", or "file_rename_event" and that the file path is "/etc/selinux/config".
+- Check the timestamp of the event to determine when the SELinux configuration file was created or renamed.
+- Identify the user account and process responsible for the action by examining the event logs for associated user and process information.
+- Investigate the history of changes to the SELinux configuration file to determine if there have been any recent unauthorized modifications.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns on the host.
+- Assess the current state of SELinux on the affected system to ensure it is configured correctly and has not been disabled or altered inappropriately.
+- If unauthorized changes are confirmed, initiate a response plan to mitigate potential security risks, which may include restoring the original configuration and conducting a broader security assessment of the system.
+
+### False positive analysis
+
+- Routine system updates or administrative tasks may trigger file creation or renaming events in the SELinux configuration path. Users can create exceptions for known update processes or trusted administrative scripts to prevent unnecessary alerts.
+- Automated configuration management tools like Ansible, Puppet, or Chef might modify the SELinux configuration file as part of their normal operations. Users should identify and whitelist these tools to reduce false positives.
+- Initial system setup or reconfiguration activities often involve legitimate changes to the SELinux configuration. Users can temporarily disable the rule during planned maintenance windows or add exceptions for specific time frames to avoid false alerts.
+- Security audits or compliance checks may involve accessing or modifying SELinux settings. Users should coordinate with audit teams to recognize these activities and adjust the rule settings accordingly.
+- Custom scripts or applications developed in-house that interact with SELinux settings should be reviewed and, if deemed safe, added to an exception list to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Verify the integrity of the SELinux configuration file by comparing it with a known good backup. If discrepancies are found, restore the file from a trusted backup.
+- Conduct a thorough review of recent user and process activity on the affected system to identify any unauthorized changes or suspicious behavior that may have led to the SELinux configuration modification.
+- Re-enable SELinux enforcement if it has been disabled, and ensure that the correct security policies are applied to maintain system protection.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify SELinux configurations or other critical security settings.
+- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify SELinux configurations, reducing the risk of future unauthorized changes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_ssl_certificate_deletion.toml b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
index 861b9a5dd90..c3bba78eae9 100644
--- a/rules/linux/defense_evasion_ssl_certificate_deletion.toml
+++ b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,40 @@ query = '''
 file where host.os.type == "linux" and event.type == "deletion" and file.path : "/etc/ssl/certs/*" and
 file.extension in ("pem", "crt") and not process.name in ("dockerd", "pacman")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SSL Certificate Deletion
+SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path and extension of the deleted SSL certificate, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt".
+- Identify the process responsible for the deletion by examining the process name and compare it against the exclusion list (e.g., "dockerd", "pacman") to determine if the process is potentially malicious.
+- Investigate the user account associated with the process that performed the deletion to assess if the account has a history of suspicious activity or unauthorized access.
+- Check system logs and audit trails around the time of the deletion event to identify any related activities or anomalies that could indicate a broader attack or compromise.
+- Assess the impact of the certificate deletion on system operations and security, including any disruptions to secure communications or trust relationships.
+- If the deletion is deemed suspicious, consider restoring the deleted certificate from backups and implementing additional monitoring to detect further unauthorized deletions.
+
+### False positive analysis
+
+- Routine system updates or package installations may trigger certificate deletions. Exclude processes like package managers or update services that are known to perform these actions.
+- Automated certificate renewal services might delete old certificates as part of their renewal process. Identify and exclude these services to prevent false alerts.
+- Custom scripts or maintenance tasks that manage SSL certificates could be flagged. Review and whitelist these scripts if they are verified as non-malicious.
+- Backup or cleanup operations that involve certificate files might cause false positives. Ensure these operations are recognized and excluded from monitoring.
+- Development or testing environments where certificates are frequently added and removed can generate alerts. Consider excluding these environments if they are isolated and secure.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or damage.
+- Verify the deletion of SSL certificates by checking the specified directories and confirm the absence of expected certificate files.
+- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls.
+- Conduct a thorough review of system logs and process activity to identify the source of the deletion and any associated malicious activity.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar environments to detect any further unauthorized deletions or related suspicious activities.
+- Review and update access controls and permissions to ensure only authorized processes and users can modify or delete SSL certificates."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
index 86b5173a792..e50e1d9f09f 100644
--- a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
+++ b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,40 @@ process where host.os.type == "linux" and event.type == "start" and
     "openssl", "telnet", "wget", "curl", "id"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potentially Suspicious Process Started via tmux or screen
+
+Tmux and screen are terminal multiplexers that allow users to manage multiple terminal sessions from a single window, facilitating multitasking and session persistence. Adversaries may exploit these tools to execute commands stealthily, detaching sessions to run processes in the background. The detection rule identifies suspicious processes initiated by tmux or screen, focusing on potentially malicious commands, to uncover attempts at evading security measures.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific command executed by tmux or screen, focusing on the process.name field to determine if it matches any known suspicious commands like "nmap", "nc", "wget", etc.
+- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Check the parent process information, specifically process.parent.name, to confirm that the process was indeed initiated by tmux or screen, and assess if this behavior is expected for the user or system.
+- Investigate the network activity associated with the process, especially if the command involves network utilities like "curl" or "ping", to identify any unusual or unauthorized connections.
+- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- System administrators or developers may use tmux or screen to run legitimate maintenance scripts or development tools like Java, PHP, or Perl. To manage these, create exceptions for known scripts or processes that are regularly executed by trusted users.
+- Automated monitoring or testing tools might utilize tmux or screen to execute network diagnostic commands such as ping or nmap. Identify and whitelist these tools if they are part of routine operations.
+- Some backup or data transfer processes might use wget or curl to fetch resources. Verify the source and destination of these processes and exclude them if they are part of scheduled tasks.
+- Developers might use tmux or screen to run interactive sessions with languages like Ruby or Lua for debugging purposes. Establish a list of trusted users and exclude their sessions from triggering alerts.
+- In environments where remote management is common, tools like ngrok might be used for legitimate purposes. Ensure that these tools are configured securely and exclude them if they are part of authorized workflows.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as being initiated by tmux or screen, especially those matching the query criteria.
+- Conduct a thorough review of the affected system's process tree and logs to identify any additional malicious activity or persistence mechanisms.
+- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Implement network monitoring to detect any unusual outbound connections or data exfiltration attempts from the affected host.
+- Update and enhance detection rules to include additional suspicious command patterns or behaviors observed during the investigation."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/defense_evasion_unusual_preload_env_vars.toml b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
index 06cc415ae7d..725077a44dc 100644
--- a/rules/linux/defense_evasion_unusual_preload_env_vars.toml
+++ b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,41 @@ type = "new_terms"
 query = '''
 event.category:process and host.os.type:linux and event.type:start and event.action:exec and process.env_vars:*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Preload Environment Variable Process Execution
+
+In Linux environments, preload environment variables can dictate which libraries are loaded into a process, potentially altering its behavior. Adversaries exploit this by injecting malicious libraries to hijack execution flow, achieving persistence or evasion. The detection rule identifies atypical environment variables during process execution, signaling potential misuse by attackers.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process name, command line, and any unusual environment variables listed in process.env_vars.
+- Investigate the parent process to understand the context of how the process was initiated and whether it aligns with expected behavior.
+- Check the history of the process and its associated user account to identify any recent changes or suspicious activities that might indicate compromise.
+- Analyze the libraries or binaries specified in the environment variables to determine if they are legitimate or potentially malicious.
+- Cross-reference the process and environment variables with known threat intelligence sources to identify any matches with known malicious activity.
+- Examine system logs and other related alerts around the same timeframe to identify any correlated or supporting evidence of malicious activity.
+
+### False positive analysis
+
+- Development and testing environments often use custom preload variables to test new libraries, which can trigger false positives. Users should identify and whitelist these known variables to prevent unnecessary alerts.
+- Some legitimate software applications may use uncommon preload environment variables for performance optimization or compatibility reasons. Users can create exceptions for these applications by verifying their source and behavior.
+- System administrators might employ preload variables for system tuning or debugging purposes. Documenting and excluding these specific cases can help reduce false positives.
+- Security tools and monitoring solutions might use preload variables as part of their operation. Ensure these tools are recognized and excluded from triggering alerts by maintaining an updated list of their known behaviors.
+- Regularly review and update the list of excluded variables and processes to adapt to changes in the environment and software updates, ensuring that only non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified with unusual preload environment variables to halt potential malicious execution.
+- Conduct a thorough review of the affected system's environment variables and loaded libraries to identify and remove any unauthorized or malicious entries.
+- Restore the affected system from a known good backup to ensure all malicious modifications are removed.
+- Update and patch the system to the latest security standards to mitigate vulnerabilities that could be exploited for similar attacks.
+- Monitor the network and system logs for any signs of re-infection or similar suspicious activity, focusing on process execution patterns.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml
index cb335926989..bcd8322402a 100644
--- a/rules/linux/discovery_dynamic_linker_via_od.toml
+++ b/rules/linux/discovery_dynamic_linker_via_od.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Dynamic Linker Discovery via od
+
+The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files.
+- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs.
+- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities.
+- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts.
+- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives.
+- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation.
+- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts.
+- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files.
+- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity.
+- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign.
+- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml
index b5f479b5766..40215439bb0 100644
--- a/rules/linux/discovery_esxi_software_via_find.toml
+++ b/rules/linux/discovery_esxi_software_via_find.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,40 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and 
   not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 ESXI Discovery via Find
+
+VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*".
+- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process.
+- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks.
+- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns.
+- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system.
+- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings.
+
+### False positive analysis
+
+- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks.
+- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule.
+- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts.
+- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities.
+- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files.
+- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity.
+- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities.
+- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml
index ab1ce5793f0..03e20db0f7b 100644
--- a/rules/linux/discovery_esxi_software_via_grep.toml
+++ b/rules/linux/discovery_esxi_software_via_grep.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,39 @@ process where host.os.type == "linux" and event.type == "start" and
   process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and
   not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 ESXI Discovery via Grep
+
+In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem".
+- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init".
+- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous.
+- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host.
+- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity.
+
+### False positive analysis
+
+- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts.
+- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts.
+- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities.
+- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule.
+
+### Response and remediation
+
+- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions.
+- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files.
+- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity.
+- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_kernel_module_enumeration.toml b/rules/linux/discovery_kernel_module_enumeration.toml
index e57a6d27d55..d9c2f985ffa 100644
--- a/rules/linux/discovery_kernel_module_enumeration.toml
+++ b/rules/linux/discovery_kernel_module_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,40 @@ not (
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Enumeration of Kernel Modules
+
+Loadable Kernel Modules (LKMs) enhance a Linux kernel's capabilities dynamically, without requiring a system reboot. Adversaries may exploit this by enumerating kernel modules to gather system information or identify vulnerabilities. The detection rule identifies suspicious enumeration activities by monitoring specific processes and arguments associated with module listing commands, while excluding benign parent processes to reduce false positives.
+
+### Possible investigation steps
+
+- Review the process details in the alert to identify the specific command used for kernel module enumeration, such as lsmod, modinfo, kmod with list argument, or depmod with --all or -a arguments.
+- Examine the process parent name to ensure it is not one of the benign processes listed in the exclusion criteria, such as mkinitramfs, dracut, or systemd, which could indicate a false positive.
+- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it might indicate unauthorized access.
+- Check the timing and frequency of the enumeration activity to assess whether it is part of routine system operations or an anomaly that warrants further investigation.
+- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that could suggest a broader attack or compromise.
+
+### False positive analysis
+
+- System maintenance tools like mkinitramfs and dracut may trigger the rule during legitimate operations. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts.
+- Backup and recovery processes such as rear and casper can cause false positives when they interact with kernel modules. Verify these processes are part of the exclusion criteria to avoid misidentification.
+- Disk management and storage tools like lvm2 and mdadm might enumerate kernel modules as part of their normal function. Add these to the exclusion list to reduce false positives.
+- Virtualization and container management tools such as vz-start and overlayroot may also enumerate modules. Confirm these are excluded to maintain focus on genuine threats.
+- Kernel update and management utilities like dkms and kernel-install can trigger alerts during updates. Ensure these are accounted for in the exclusion list to minimize false alarms.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized use of lsmod, modinfo, kmod, or depmod commands.
+- Conduct a thorough review of recent system logs and process execution history to identify any unauthorized access or changes made to the system.
+- Restore the system from a known good backup if any unauthorized modifications to kernel modules or system files are detected.
+- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could be exploited through kernel modules.
+- Implement stricter access controls and monitoring for kernel module management, ensuring only authorized personnel can load or unload modules.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_linux_hping_activity.toml b/rules/linux/discovery_linux_hping_activity.toml
index 526bdb48d37..e978852c1f7 100644
--- a/rules/linux/discovery_linux_hping_activity.toml
+++ b/rules/linux/discovery_linux_hping_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -83,6 +83,41 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name in ("hping", "hping2", "hping3")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Hping Process Activity
+
+Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3".
+- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user.
+- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities.
+- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous.
+- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization.
+- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns.
+- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation.
+
+### False positive analysis
+
+- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits.
+- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule.
+- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles.
+- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary.
+- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities.
+- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping.
+- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files.
+- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_linux_nping_activity.toml b/rules/linux/discovery_linux_nping_activity.toml
index 5d217c0f4fb..b1a6e1627ad 100644
--- a/rules/linux/discovery_linux_nping_activity.toml
+++ b/rules/linux/discovery_linux_nping_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -83,6 +83,41 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name == "nping"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Nping Process Activity
+
+Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping".
+- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns.
+- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types.
+- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns.
+- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed.
+- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns.
+
+### False positive analysis
+
+- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing.
+- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes.
+- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests.
+- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments.
+- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks.
+- Terminate the Nping process on the affected host to stop any ongoing malicious activity.
+- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts.
+- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms.
+- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only.
+- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign.
+- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml
index e4c58f72f89..825d5c74454 100644
--- a/rules/linux/discovery_pam_version_discovery.toml
+++ b/rules/linux/discovery_pam_version_discovery.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,40 @@ process where host.os.type == "linux" and event.type == "start" and
     (process.name == "rpm" and process.args == "pam")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 (PAM) Version Discovery
+
+Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam".
+- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior.
+- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts.
+- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts.
+- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context.
+- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts.
+- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods.
+- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM.
+- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications.
+- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process.
+- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_ping_sweep_detected.toml b/rules/linux/discovery_ping_sweep_detected.toml
index 0fa247325c9..56eff74834c 100644
--- a/rules/linux/discovery_ping_sweep_detected.toml
+++ b/rules/linux/discovery_ping_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ query = '''
 event.category:process and host.os.type:linux and event.action:(exec or exec_event or executed or process_started) and
 event.type:start and process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Network Scan Executed From Host
+
+In Linux environments, utilities like ping, netcat, and socat are essential for network diagnostics and communication. However, adversaries can exploit these tools to perform network scans, identifying active hosts and services for further exploitation. The detection rule identifies rapid execution of these utilities, signaling potential misuse for network reconnaissance, by monitoring process initiation events linked to these tools.
+
+### Possible investigation steps
+
+- Review the process initiation events to confirm the rapid execution of utilities like ping, netcat, or socat by examining the process.name field in the alert.
+- Identify the user account associated with the process execution by checking the user information in the event data to determine if the activity aligns with expected behavior.
+- Analyze the command line arguments used with the executed utilities by inspecting the process.command_line field to understand the scope and intent of the network scan.
+- Correlate the alert with other recent events on the host by reviewing event timestamps and related process activities to identify any patterns or additional suspicious behavior.
+- Check network logs or firewall logs for any unusual outbound connections or traffic patterns originating from the host to assess the potential impact of the network scan.
+- Investigate the host's recent login history and user activity to determine if there are signs of unauthorized access or compromise that could explain the network scan activity.
+
+### False positive analysis
+
+- Routine network diagnostics by system administrators can trigger alerts. To manage this, create exceptions for known administrator accounts or specific IP addresses frequently used for legitimate network diagnostics.
+- Automated monitoring scripts that use these utilities for health checks or performance monitoring may cause false positives. Identify and exclude these scripts by their process names or execution paths.
+- Scheduled tasks or cron jobs that involve network utilities for maintenance purposes can be mistaken for network scans. Exclude these tasks by their specific scheduling patterns or associated user accounts.
+- Security tools that perform regular network sweeps as part of their functionality might be flagged. Whitelist these tools by their process names or hash values to prevent unnecessary alerts.
+- Development or testing environments where network utilities are used for testing purposes can generate false positives. Implement exclusions based on environment-specific identifiers or network segments.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, such as those involving ping, netcat, or socat, to halt ongoing network scans.
+- Conduct a thorough review of the host's process logs and network activity to identify any additional indicators of compromise or related malicious activity.
+- Reset credentials and review access permissions for accounts that were active on the compromised host to prevent unauthorized access.
+- Apply patches and updates to the host's operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries.
+- Enhance network monitoring and logging to detect similar reconnaissance activities in the future, ensuring that alerts are configured to notify security teams promptly.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml
index 13ef862b2a7..32c338e367e 100644
--- a/rules/linux/discovery_private_key_password_searching_activity.toml
+++ b/rules/linux/discovery_private_key_password_searching_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,40 @@ process where host.os.type == "linux" and event.type == "start" and
   process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
   process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Private Key Searching Activity
+
+In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key files in sensitive directories, signaling potential malicious intent. This proactive monitoring helps mitigate risks associated with unauthorized key access.
+
+### Possible investigation steps
+
+- Review the process details to confirm the 'find' command was executed with parameters targeting private key files, as indicated by the command line containing patterns like "*id_dsa*", "*id_rsa*", etc., and directories such as "/home/", "/etc/ssh", or "/root/".
+- Identify the user account associated with the process to determine if the activity aligns with expected behavior for that user or if it suggests potential compromise.
+- Check the process's parent process to understand the context in which the 'find' command was executed, which may provide insights into whether this was part of a legitimate script or an unauthorized action.
+- Investigate any recent login activity or changes in user privileges for the account involved to assess if there has been any unauthorized access or privilege escalation.
+- Examine system logs and other security alerts around the time of the event to identify any correlated suspicious activities or anomalies that might indicate a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the 'find' command to locate private keys for legitimate maintenance tasks. To handle this, create exceptions for known administrative accounts or scripts that regularly perform these actions.
+- Backup processes might search for private keys as part of routine data protection activities. Identify and exclude these processes by specifying their unique command-line patterns or process IDs.
+- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place. Exclude these activities by recognizing the specific tools or scripts used during audits.
+- Developers or DevOps teams may search for private keys during application deployment or configuration. Establish a list of trusted users or processes involved in these operations and exclude them from triggering alerts.
+- Automated configuration management tools like Ansible or Puppet might search for keys as part of their operations. Identify these tools and exclude their specific command-line patterns to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'find' command searching for private keys.
+- Conduct a thorough review of access logs and process execution history to identify any unauthorized access or privilege escalation attempts.
+- Change all potentially compromised private keys and associated credentials, ensuring new keys are securely generated and stored.
+- Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_proc_maps_read.toml b/rules/linux/discovery_proc_maps_read.toml
index fa5cc29d2ef..f723c431069 100644
--- a/rules/linux/discovery_proc_maps_read.toml
+++ b/rules/linux/discovery_proc_maps_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ process.name in ("cat", "grep") and process.args : "/proc/*/maps" and process.en
   "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious /proc/maps Discovery
+
+In Linux environments, the `/proc/*/maps` files provide detailed memory mapping of processes, crucial for system diagnostics. However, adversaries exploit this by reading these files to pinpoint memory addresses for malicious activities like code injection. The detection rule identifies suspicious reads of these files by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, flagging potential reconnaissance attempts.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and arguments, to confirm if the access to /proc/*/maps was initiated by a legitimate user or application. Pay special attention to the process.name and process.args fields.
+- Check the process.entry_leader.name to determine the shell environment from which the command was executed, and assess if this aligns with typical user behavior or known scripts.
+- Investigate the user account associated with the process to determine if there are any signs of compromise or unusual activity, such as recent logins from unfamiliar IP addresses or changes in user permissions.
+- Examine the parent process and any related child processes to understand the broader context of the command execution, looking for any signs of a script or automated task that might have triggered the alert.
+- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or sequences of suspicious activities that could indicate a larger attack or reconnaissance effort.
+
+### False positive analysis
+
+- System diagnostics tools may read /proc/*/maps files as part of routine checks. Identify these tools and create exceptions for their processes to avoid unnecessary alerts.
+- Developers and system administrators might manually inspect /proc/*/maps during debugging or performance tuning. Establish a list of known users and processes that perform these actions regularly and exclude them from triggering the rule.
+- Automated scripts for monitoring or logging purposes could access /proc/*/maps files. Review these scripts and whitelist them if they are verified to be non-malicious.
+- Security software might access these files as part of its scanning operations. Confirm the legitimacy of such software and add it to an exception list to prevent false positives.
+- Consider the context of the process entry leader. If certain shell environments are used predominantly for legitimate administrative tasks, adjust the rule to reduce sensitivity for those specific environments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as reading the `/proc/*/maps` files using commands like `cat` or `grep` from unauthorized shell environments.
+- Conduct a memory analysis on the affected system to identify any injected code or unauthorized modifications in the process memory.
+- Review and audit user accounts and permissions on the affected system to ensure that only authorized users have access to sensitive files and directories.
+- Implement stricter access controls and monitoring on `/proc/*/maps` files to limit exposure and detect unauthorized access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_process_capabilities.toml b/rules/linux/discovery_process_capabilities.toml
index cb11c2facc4..d7c4f6674f1 100644
--- a/rules/linux/discovery_process_capabilities.toml
+++ b/rules/linux/discovery_process_capabilities.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name == "getcap" and process.args == "-r" and process.args == "/" and
   process.args_count == 3 and user.id != "0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Capability Enumeration
+
+In Linux environments, the `getcap` command is used to list file capabilities, which define specific privileges for executables. Adversaries may exploit this by recursively scanning the filesystem to identify and manipulate capabilities, potentially escalating privileges. The detection rule identifies suspicious use of `getcap` by monitoring for its execution with specific arguments, especially by non-root users, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the execution of the `getcap` command with the arguments `-r` and `/`, ensuring the process was initiated by a non-root user (user.id != "0").
+- Identify the user account associated with the process execution to determine if the user has a legitimate reason to perform such actions.
+- Examine the process execution history for the identified user to check for any other suspicious activities or commands executed around the same time.
+- Investigate the system logs for any signs of privilege escalation attempts or unauthorized access following the execution of the `getcap` command.
+- Check for any recent changes to file capabilities on the system that could indicate manipulation by the adversary.
+- Assess the system for any other indicators of compromise or related alerts that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the getcap command for legitimate auditing purposes. To handle this, create exceptions for known administrative accounts or scripts that regularly perform capability checks.
+- Security tools or monitoring solutions might trigger the rule during routine scans. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
+- Developers or testing environments may execute getcap as part of software testing or development processes. Exclude specific user IDs or groups associated with these environments to prevent unnecessary alerts.
+- Scheduled maintenance tasks might involve capability enumeration. Document and exclude these tasks by specifying the time frames or user accounts involved in the maintenance activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any unauthorized or suspicious processes associated with the `getcap` command to halt potential privilege escalation activities.
+- Conduct a thorough review of the system's file capabilities using a trusted method to identify any unauthorized changes or suspicious capabilities that may have been set.
+- Revert any unauthorized capability changes to their original state to ensure that no elevated privileges are retained by malicious users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement monitoring for similar `getcap` command executions across the environment to detect and respond to future attempts promptly.
+- Review and update access controls and user permissions to ensure that only authorized users have the necessary privileges to execute potentially sensitive commands like `getcap`."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_pspy_process_monitoring_detected.toml b/rules/linux/discovery_pspy_process_monitoring_detected.toml
index a61e6a1a297..1af81c74158 100644
--- a/rules/linux/discovery_pspy_process_monitoring_detected.toml
+++ b/rules/linux/discovery_pspy_process_monitoring_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,41 @@ sequence by process.pid, host.id with maxspan=5s
    not process.name == "agentbeat"
   ] with runs=10
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Pspy Process Monitoring Detected
+
+Auditd is a Linux auditing system that tracks system calls, providing insights into process activities. Adversaries exploit tools like pspy to monitor processes via the /proc directory, seeking privilege escalation opportunities without root access. The detection rule identifies suspicious openat syscalls targeting /proc, excluding benign processes, to flag potential misuse of pspy for process discovery.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process.pid and process.name fields to identify the process attempting to access the /proc directory.
+- Investigate the host.id to determine if this activity is isolated to a single host or part of a broader pattern across multiple systems.
+- Examine the process tree and parent processes of the flagged process to understand how it was initiated and if it is part of a legitimate workflow or potentially malicious activity.
+- Check for any recent changes or installations on the host that might explain the presence of a tool like pspy, such as new software installations or updates.
+- Correlate the timing of the alert with any other suspicious activities or alerts on the same host to identify potential lateral movement or privilege escalation attempts.
+- Verify if the process name is a known benign process that might have been mistakenly excluded from the query, ensuring that the exclusion list is up-to-date and accurate.
+
+### False positive analysis
+
+- Frequent scanning by legitimate monitoring tools can trigger the rule. Identify and whitelist these tools by adding their process names to the exclusion list.
+- System management scripts that regularly access the /proc directory may cause false positives. Review these scripts and exclude their process names if they are verified as non-threatening.
+- Automated backup or security software that interacts with the /proc directory might be flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts.
+- Custom applications developed in-house that require access to the /proc directory for performance monitoring should be reviewed and excluded if they are deemed safe.
+- Regularly update the exclusion list to reflect changes in legitimate software and tools used within the organization to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as using the pspy utility to halt further unauthorized process monitoring.
+- Conduct a thorough review of the affected system's /proc directory access logs to identify any other unauthorized access attempts or anomalies.
+- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited for privilege escalation.
+- Enhance monitoring and logging on the affected host to detect any future attempts to access the /proc directory using similar methods.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_security_file_access_via_common_utility.toml b/rules/linux/discovery_security_file_access_via_common_utility.toml
index fdb6eb3c908..0827780f6df 100644
--- a/rules/linux/discovery_security_file_access_via_common_utility.toml
+++ b/rules/linux/discovery_security_file_access_via_common_utility.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,41 @@ process where host.os.type == "linux" and event.type == "start" and
     "/home/*/.azure/azureProfile.json"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Security File Access via Common Utilities
+
+In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to gather system and security configuration data. The detection rule identifies suspicious use of these utilities by monitoring process execution patterns and arguments, flagging attempts to access critical security files, thus helping to thwart potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the specific utility used (e.g., cat, grep, less) and the exact file path accessed, as indicated by the process.name and process.args fields.
+- Check the user account associated with the process execution to determine if the access was performed by a legitimate user or a potentially compromised account.
+- Investigate the timing and frequency of the access attempt to assess whether it aligns with normal user behavior or indicates suspicious activity.
+- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities, such as unauthorized logins or privilege escalation attempts.
+- Examine the host's recent changes or updates to security configurations or user permissions that might explain the access attempt.
+- If possible, contact the user or system owner to verify whether the access was intentional and authorized, providing additional context for the investigation.
+
+### False positive analysis
+
+- System administrators or automated scripts may frequently access security files for legitimate maintenance or configuration purposes. To handle this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions.
+- Security monitoring tools or compliance checks might trigger the rule when scanning security files. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
+- Backup processes that involve copying or reading security files can be mistaken for suspicious activity. Exclude backup software processes or scheduled tasks that are known to perform these operations.
+- Developers or DevOps personnel accessing configuration files for application deployment or troubleshooting might trigger the rule. Establish a list of trusted users or roles and exclude their access patterns from detection.
+- Regular system updates or package management operations may involve accessing security-related files. Recognize these update processes and exclude them to avoid false positives during routine maintenance.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule to halt potential reconnaissance activities.
+- Conduct a thorough review of the accessed files to determine if any sensitive information was exposed or altered.
+- Change credentials and access tokens for any compromised accounts, especially those related to AWS, GCP, or Azure, to prevent unauthorized access.
+- Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network.
+- Enhance monitoring and logging for similar activities to improve detection and response times for future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_sudo_allowed_command_enumeration.toml b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
index e0ec108809d..3fb1447da08 100644
--- a/rules/linux/discovery_sudo_allowed_command_enumeration.toml
+++ b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,39 @@ process where host.os.type == "linux" and event.type == "start" and
   process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
   not process.args == "dpkg"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Sudo Command Enumeration Detected
+
+The sudo command in Linux environments allows users to execute commands with elevated privileges, typically as the root user. Attackers may exploit this by using the `sudo -l` command to list permissible commands, potentially identifying paths to escalate privileges. The detection rule identifies this behavior by monitoring for the execution of `sudo -l` from common shell environments, flagging potential misuse for privilege escalation.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `sudo -l` command, ensuring the process name is "sudo" and the arguments include "-l" with an argument count of 2.
+- Identify the parent process of the `sudo` command to determine the shell environment used, checking if it matches any of the specified shells like "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", or "fish".
+- Investigate the user account that executed the `sudo -l` command to assess if the activity aligns with their typical behavior or if it appears suspicious.
+- Check for any recent changes in user permissions or sudoers configuration that might indicate unauthorized modifications.
+- Correlate this event with other logs or alerts to identify any subsequent suspicious activities that might suggest privilege escalation attempts.
+
+### False positive analysis
+
+- System administrators frequently use the sudo -l command to verify their permissions. To reduce noise, consider excluding specific user accounts or groups known for legitimate use.
+- Automated scripts or configuration management tools may execute sudo -l as part of routine checks. Identify these scripts and exclude their execution paths or parent processes from the rule.
+- Some software installations or updates might invoke sudo -l to check permissions. Monitor and document these processes, then create exceptions for known benign software.
+- Developers or testers might use sudo -l during debugging or testing phases. Coordinate with development teams to identify and exclude these activities when they are part of approved workflows.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Review the sudoers file on the affected system to identify any unauthorized or suspicious entries that may have been added or modified, and revert any changes to their original state.
+- Terminate any suspicious processes initiated by the user who executed the `sudo -l` command, especially if they are not part of normal operations.
+- Reset the password of the user account involved in the alert to prevent further unauthorized access.
+- Conduct a thorough review of system logs to identify any additional suspicious activity or commands executed by the user, and assess the scope of potential compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement additional monitoring and alerting for similar `sudo -l` command executions across the environment to enhance detection and response capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_suid_sguid_enumeration.toml b/rules/linux/discovery_suid_sguid_enumeration.toml
index 131a1e897c6..810fecf6686 100644
--- a/rules/linux/discovery_suid_sguid_enumeration.toml
+++ b/rules/linux/discovery_suid_sguid_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/24"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,39 @@ process.name == "find" and process.args : "-perm" and process.args : (
   (process.args : "/usr/bin/pkexec" and process.args : "-xdev" and process.args_count == 7)
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SUID/SGUID Enumeration Detected
+
+In Linux, SUID and SGID permissions allow programs to execute with elevated privileges, potentially exposing systems to privilege escalation if misconfigured. Adversaries exploit this by searching for binaries with these permissions to gain unauthorized access. The detection rule identifies suspicious use of the "find" command to locate such binaries, flagging potential misuse by monitoring specific command arguments and execution contexts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the "find" command with SUID/SGID permission arguments by checking the process.name and process.args fields.
+- Identify the user and group context in which the command was executed by examining the user.Ext.real.id and group.Ext.real.id fields to determine if the command was run by a non-root user.
+- Analyze the command's arguments to understand the scope of the search, focusing on the process.args field to see if specific directories or files were targeted.
+- Check for any other suspicious activities or commands executed by the same user or process around the same time to identify potential follow-up actions or privilege escalation attempts.
+- Investigate the system for any newly created or modified files with SUID/SGID permissions that could indicate successful privilege escalation or preparation for future attacks.
+
+### False positive analysis
+
+- System administrators or security tools may use the find command with SUID/SGID arguments for legitimate audits. To handle this, create exceptions for known administrative users or specific scripts that regularly perform these checks.
+- Automated scripts or cron jobs might execute the find command with these arguments as part of routine maintenance tasks. Identify these scripts and exclude them from monitoring by specifying their process paths or user IDs.
+- Some legitimate software installations or updates might temporarily use the find command with SUID/SGID arguments. Monitor installation logs and exclude these processes by correlating them with known software update activities.
+- Developers or testers might use the find command in development environments to test security configurations. Exclude these environments from the rule by specifying their hostnames or IP addresses in the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the "find" command with SUID/SGID arguments.
+- Conduct a thorough review of the system's SUID/SGID binaries to identify any misconfigurations or unauthorized changes. Remove or correct permissions on any binaries that are not required to have elevated privileges.
+- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID binaries, focusing on process execution and permission changes.
+- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any other affected systems.
+- Apply patches and updates to the system and any vulnerable applications to mitigate known vulnerabilities that could be exploited through SUID/SGID binaries.
+- Review and enhance access controls and privilege management policies to minimize the risk of privilege escalation through misconfigured binaries in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml
index 83efd842f34..cc556ba4db0 100644
--- a/rules/linux/discovery_suspicious_memory_grep_activity.toml
+++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,41 @@ process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
   process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Memory grep Activity
+
+In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for debugging but exploitable by attackers for malicious activities like code injection. Adversaries may use tools like `grep` to scan these memory maps for specific segments, aiding in process manipulation. The detection rule identifies such suspicious `grep` usage by monitoring process initiation events, focusing on arguments that indicate potential memory mapping exploration.
+
+### Possible investigation steps
+
+- Review the process initiation event details to confirm the presence of grep or its variants (egrep, fgrep, rgrep) in the process name field.
+- Examine the process arguments to verify if they include memory segments like [stack], [vdso], or [heap], which could indicate an attempt to explore memory mappings.
+- Identify the user or service account associated with the suspicious process to determine if the activity aligns with expected behavior or if it might be unauthorized.
+- Check the parent process of the suspicious grep activity to understand the context in which it was executed and assess if it was initiated by a legitimate application or script.
+- Investigate any recent changes or anomalies in the system logs around the time of the alert to identify potential indicators of compromise or related suspicious activities.
+- Correlate this event with other security alerts or logs from the same host to identify patterns or a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or developers may use grep to inspect memory maps for legitimate debugging or performance tuning. To handle this, create exceptions for known user accounts or specific scripts that perform these tasks regularly.
+- Automated monitoring tools might use grep to check memory usage patterns as part of routine health checks. Identify these tools and exclude their process IDs or command patterns from triggering alerts.
+- Security software or intrusion detection systems could use grep to scan memory maps as part of their normal operations. Verify these processes and whitelist them to prevent unnecessary alerts.
+- Developers running test scripts that include memory map analysis might trigger this rule. Document these scripts and add them to an exception list to avoid false positives.
+- Some legitimate applications may use grep to read memory maps for configuration or optimization purposes. Monitor these applications and adjust the rule to exclude their specific command-line arguments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving `grep` or its variants accessing memory maps.
+- Conduct a memory dump and forensic analysis of the affected system to identify any injected code or unauthorized modifications.
+- Review and audit access logs to determine if there was unauthorized access to the `/proc/*/maps` files and identify any potential data exfiltration.
+- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for similar attacks.
+- Implement stricter access controls and monitoring on sensitive files and directories, such as `/proc/*/maps`, to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_suspicious_which_command_execution.toml b/rules/linux/discovery_suspicious_which_command_execution.toml
index a480c04a7ae..bcaa43b910d 100644
--- a/rules/linux/discovery_suspicious_which_command_execution.toml
+++ b/rules/linux/discovery_suspicious_which_command_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,40 @@ and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g+
 process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 */
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious which Enumeration
+
+The `which` command in Linux environments is typically used to locate the executable path of a command. Adversaries may exploit this utility to identify installed software that can aid in privilege escalation or lateral movement. The detection rule flags unusual usage patterns, such as excessive arguments, which may indicate malicious enumeration. It filters out benign scenarios, focusing on potential threats by examining process attributes and parent-child relationships.
+
+### Possible investigation steps
+
+- Review the process details to confirm the command line arguments used with the which command, focusing on whether the args_count is unusually high and if the arguments are related to known enumeration or exploitation tools.
+- Examine the parent process of the which command to determine if it is a legitimate process or if it is associated with suspicious activity, especially if it is not one of the excluded parent names or paths.
+- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations.
+- Check for any other recent alerts or logs related to the same host or user that might indicate a broader attack pattern or ongoing compromise.
+- Assess the network activity from the host to identify any connections to known malicious IP addresses or unusual outbound traffic that could suggest lateral movement or data exfiltration.
+
+### False positive analysis
+
+- Processes initiated by the 'jem' parent process may trigger false positives. To handle this, add 'jem' to the list of exceptions in the rule configuration.
+- Executions within containerized environments, such as those under '/vz/root/' or '/var/lib/docker/', are often benign. Exclude these paths from the rule to reduce noise.
+- The '--tty-only' argument is typically used in legitimate scenarios. Consider adding this argument to the exception list to prevent unnecessary alerts.
+- If the rule is noisy due to common utilities like 'nmap', 'nc', 'gcc', or 'socat' being used with shell interpreters like 'bash' or 'zsh', refine the rule by excluding these combinations.
+- Regularly review and update the list of exceptions based on the evolving environment and usage patterns to maintain an effective balance between detection and false positive reduction.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the `which` command that have an unusually high number of arguments, as identified by the detection rule.
+- Conduct a thorough review of the system's installed software and utilities to identify any unauthorized or suspicious installations that could be leveraged for privilege escalation.
+- Analyze the process tree and parent-child relationships of the flagged `which` command execution to identify potential malicious scripts or binaries that initiated the command.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement enhanced monitoring and logging for the `which` command and similar enumeration tools to detect future misuse.
+- Review and update access controls and permissions to ensure that only authorized users have the ability to execute potentially sensitive commands and utilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_unusual_user_enumeration_via_id.toml b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
index 860c3e226b4..379b03f4a52 100644
--- a/rules/linux/discovery_unusual_user_enumeration_via_id.toml
+++ b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,40 @@ sequence by host.id, process.parent.entity_id with maxspan=1s
    process.name == "id" and process.args_count == 2 and 
    not (process.parent.name == "rpm" or process.parent.args : "/var/tmp/rpm-tmp*")] with runs=20
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual User Privilege Enumeration via id
+
+The `id` command in Linux environments is used to display user identity information, including user and group IDs. Adversaries may exploit this command in enumeration scripts to gather extensive user privilege data rapidly, which can aid in lateral movement or privilege escalation. The detection rule identifies suspicious activity by flagging rapid, repeated executions of the `id` command, suggesting potential misuse by scripts like LinPEAS or LinEnum.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity.
+- Examine the parent process of the 'id' command executions to determine if it is a known or legitimate process, and check for any unusual or unexpected parent process names or arguments.
+- Investigate the timeline of events on the affected host around the time of the alert to identify any other suspicious activities or related processes that may indicate a broader attack or script execution.
+- Check the user account associated with the process executions to verify if it has legitimate access and if there are any signs of compromise or misuse.
+- Look for any additional indicators of compromise on the host, such as unauthorized file modifications, network connections, or other unusual command executions, to assess the scope of potential malicious activity.
+
+### False positive analysis
+
+- System management scripts or automated tasks may execute the id command frequently for legitimate purposes. Review the parent process to determine if it is a known management tool or script.
+- Software installation or update processes might trigger the rule if they use the id command to verify user permissions. Consider excluding processes with parent names like rpm or similar package managers.
+- Custom scripts developed in-house for system monitoring or auditing could inadvertently match the rule's criteria. Identify these scripts and add exceptions for their parent process entity IDs.
+- Security tools or compliance checks that perform regular user enumeration might cause false positives. Verify the source of these tools and exclude them if they are part of a trusted security suite.
+- In environments with high user account turnover, scripts that manage user accounts might execute the id command in rapid succession. Evaluate these scripts and exclude them if they are part of routine account management.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the parent process identified in the alert to halt further enumeration activities.
+- Conduct a thorough review of the parent process and its associated scripts to determine if they are legitimate or malicious.
+- If malicious activity is confirmed, perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or altered system files.
+- Reset credentials for any user accounts that may have been exposed or compromised during the enumeration activity.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.
+- Implement enhanced monitoring and logging for similar enumeration activities to improve detection and response capabilities for future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_virtual_machine_fingerprinting.toml b/rules/linux/discovery_virtual_machine_fingerprinting.toml
index 62990271aa5..b3683e3aff7 100644
--- a/rules/linux/discovery_virtual_machine_fingerprinting.toml
+++ b/rules/linux/discovery_virtual_machine_fingerprinting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -82,6 +82,41 @@ event.category:process and host.os.type:linux and event.type:(start or process_s
                 "/proc/ide/hd0/model") and
   not user.name:root
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Virtual Machine Fingerprinting
+
+Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field.
+- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted.
+- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity.
+- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting.
+- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats.
+- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary.
+
+### False positive analysis
+
+- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior.
+- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe.
+- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations.
+- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user.
+- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise.
+- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced.
+- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions.
+- 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 additional monitoring and alerting for the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml
index 751c8c67492..0cac6758ff0 100644
--- a/rules/linux/discovery_yum_dnf_plugin_detection.toml
+++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,39 @@ process where host.os.type == "linux" and event.type == "start" and
     "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Yum/DNF Plugin Status Discovery
+
+Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands to identify active plugins, potentially altering them for malicious purposes. The detection rule identifies suspicious use of the `grep` command to search for plugin configurations, signaling possible reconnaissance or tampering attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `grep` command with arguments related to plugin configurations, such as `/etc/yum.conf` or `/etc/dnf/dnf.conf`, to verify the alert's accuracy.
+- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account.
+- Check the system's command history for any preceding or subsequent commands executed by the same user to identify potential patterns or further suspicious activity.
+- Investigate any recent changes to the plugin configuration files located in directories like `/etc/yum/pluginconf.d/` or `/etc/dnf/plugins/` to detect unauthorized modifications.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related malicious activity.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the grep command to verify plugin configurations during routine maintenance. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these checks.
+- Security audits or compliance checks might involve scanning for plugin configurations to ensure they are correctly set up. Exclude these activities by identifying and whitelisting the specific processes or tools used for such audits.
+- Developers or IT staff might search for plugin configurations while troubleshooting or developing new features. Consider excluding processes initiated by trusted development environments or specific user groups involved in these activities.
+- Monitoring tools that perform regular checks on system configurations could trigger this rule. Identify these tools and add them to an exclusion list to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Terminate any suspicious processes related to the `grep` command that are actively searching for YUM/DNF plugin configurations.
+- Conduct a thorough review of the YUM and DNF plugin configuration files and directories for unauthorized changes or additions, specifically in the paths `/etc/yum.conf`, `/usr/lib/yum-plugins/*`, `/etc/yum/pluginconf.d/*`, `/usr/lib/python*/site-packages/dnf-plugins/*`, `/etc/dnf/plugins/*`, and `/etc/dnf/dnf.conf`.
+- Restore any altered plugin configurations from a known good backup to ensure system integrity.
+- Implement file integrity monitoring on the YUM and DNF configuration directories to detect future unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Review and update access controls and permissions for users and processes interacting with YUM and DNF configurations to minimize the risk of unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
index e07e6d73e79..31cc81b317c 100644
--- a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
+++ b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -86,6 +86,39 @@ and (
   process.parent.executable like ("/vz/root/*", "/var/rudder/*")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential curl CVE-2023-38545 Exploitation
+
+Curl is a command-line tool used for transferring data with URLs, often employed in scripts and automation. A vulnerability in versions up to 8.3 allows a buffer overflow during SOCKS5 proxy handshakes, potentially leading to arbitrary code execution. Adversaries might exploit this by crafting specific command lines or environment variables. The detection rule identifies suspicious curl usage patterns, such as unusual command lengths and specific proxy settings, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process command line arguments and environment variables to confirm the presence of SOCKS5 proxy settings, such as "--socks5-hostname", "--proxy", "--preproxy", or environment variables like "http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", and "ALL_PROXY=socks5h://*".
+- Check the length of the command line to ensure it exceeds 255 characters, as this is a key indicator of potential exploitation attempts.
+- Investigate the parent process of the curl execution to determine if it is one of the known benign processes like "cf-agent", "agent-run", "agent-check", "rudder", "agent-inventory", or "cf-execd", or if it originates from directories like "/opt/rudder/*", "/vz/root/*", or "/var/rudder/*".
+- Examine the network activity associated with the curl process to identify any unusual or unauthorized data transfers, especially those involving SOCKS5 proxies.
+- Cross-reference the alert with other security logs and alerts to identify any correlated suspicious activities or patterns that might indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tools like cf-agent, agent-run, and rudder may trigger the rule due to their use of curl with SOCKS5 proxies. To mitigate this, add these tools to the exception list in the rule configuration.
+- Automated scripts running in environments like /opt/rudder or /var/rudder might be flagged. Exclude these paths from the rule to prevent false positives.
+- Processes executed within virtualized environments, such as those under /vz/root, can be mistakenly identified. Consider excluding these directories if they are known to host benign activities.
+- Regularly review and update the list of known safe parent processes and directories to ensure that legitimate operations are not disrupted by the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious curl processes identified by the detection rule to halt potential exploitation activities.
+- Upgrade curl to version 8.4 or later on all affected systems to patch the vulnerability and prevent future exploitation attempts.
+- Review and reset any potentially compromised environment variables, such as http_proxy, HTTPS_PROXY, and ALL_PROXY, to ensure they are not being used maliciously.
+- Conduct a thorough investigation of the affected system for signs of further compromise, such as unauthorized access or changes to critical files, and take appropriate remediation actions.
+- Notify the security team and relevant stakeholders about the incident for awareness and further analysis, ensuring that any findings are documented for future reference.
+- Enhance monitoring and logging for curl usage and SOCKS5 proxy connections to improve detection capabilities for similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
index 63d52d93d78..0958a57f9ee 100644
--- a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
+++ b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/10"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,40 @@ sequence by host.id with maxspan=3s
        )
     )] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Egress Connection from Entrypoint in Container
+
+Containers, often used for deploying applications, start with an entrypoint script that initializes the environment. Adversaries may exploit this by embedding malicious commands to initiate unauthorized network connections, potentially breaching security boundaries. The detection rule monitors for processes named `entrypoint.sh` followed by suspicious network activity, flagging attempts to connect to external IPs, thus identifying potential threats.
+
+### Possible investigation steps
+
+- Review the process details for the `entrypoint.sh` script execution, focusing on the `process.entity_id` and `host.id` to understand the context of the container where the script was executed.
+- Examine the network connection attempt details, particularly the `destination.ip`, to determine if the IP address is known to be malicious or associated with suspicious activity.
+- Check the container's Dockerfile or image configuration to verify if the `entrypoint.sh` script is expected and whether it contains any unauthorized modifications or additions.
+- Investigate the parent process of the network connection attempt using `process.parent.entity_id` to identify if there are any other suspicious processes or activities linked to the same parent.
+- Correlate the event with other logs or alerts from the same `host.id` to identify any additional indicators of compromise or related suspicious activities within the same timeframe.
+
+### False positive analysis
+
+- Legitimate application updates or installations may trigger the rule if they involve network connections from the entrypoint script. To handle this, identify and whitelist specific applications or update processes that are known to perform such actions.
+- Automated configuration management tools might execute scripts that initiate network connections as part of their normal operations. Exclude these tools by specifying their process names or parent entity IDs in the rule exceptions.
+- Containers designed to perform network diagnostics or monitoring could naturally attempt connections to external IPs. Review and exclude these containers by their image names or specific entrypoint scripts.
+- Development or testing environments often run scripts that connect to external services for integration testing. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags.
+- Scheduled maintenance scripts that run periodically and require network access might be flagged. Document these scripts and create exceptions based on their execution schedule or specific network destinations.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized network connections. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the `entrypoint.sh` script within the container to identify and remove any malicious commands or scripts that may have been injected.
+- Analyze the network traffic logs to identify any external IP addresses that the container attempted to connect to. Block these IPs at the firewall level to prevent future connections.
+- Check for any signs of lateral movement or attempts to escape the container to the host system. If detected, escalate to the security team for a comprehensive investigation.
+- Restore the container from a known good backup if available, ensuring that the restored version is free from any malicious modifications.
+- Implement additional monitoring on the affected host and container environment to detect any similar suspicious activities in the future.
+- Report the incident to the appropriate internal security team or incident response team for further analysis and to update threat intelligence databases."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_file_execution_followed_by_deletion.toml b/rules/linux/execution_file_execution_followed_by_deletion.toml
index 4547501ded4..9793c814549 100644
--- a/rules/linux/execution_file_execution_followed_by_deletion.toml
+++ b/rules/linux/execution_file_execution_followed_by_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ sequence by host.id, user.id with maxspan=1m
    file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*",
      "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File Creation, Execution and Self-Deletion in Suspicious Directory
+
+In Linux environments, temporary directories like `/tmp` and `/var/tmp` are often used for storing transient files. Adversaries exploit these directories to execute malicious payloads and erase traces by creating, running, and deleting files swiftly. The detection rule identifies this pattern by monitoring file creation, execution, and deletion events within these directories, flagging suspicious activities that align with common malware behaviors.
+
+### Possible investigation steps
+
+- Review the file creation event details, focusing on the file path and name to determine if it matches known malicious patterns or if it is a legitimate file.
+- Examine the process execution event, paying attention to the process name and parent process name to identify if the execution was initiated by a suspicious or unauthorized shell.
+- Investigate the user.id and host.id associated with the events to determine if the activity aligns with expected user behavior or if it indicates potential compromise.
+- Check for any network activity or connections initiated by the process to identify potential data exfiltration or communication with command and control servers.
+- Analyze the deletion event to confirm whether the file was removed by a legitimate process or if it was part of a self-deletion mechanism used by malware.
+- Correlate these events with any other alerts or logs from the same host or user to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Development and testing activities in temporary directories can trigger false positives. Exclude specific paths or processes related to known development tools or scripts that frequently create, execute, and delete files in these directories.
+- Automated system maintenance scripts may perform similar actions. Identify and whitelist these scripts by their process names or paths to prevent unnecessary alerts.
+- Backup or deployment tools like Veeam or Spack may use temporary directories for legitimate operations. Add exceptions for these tools by specifying their executable paths or process names.
+- Temporary file operations by legitimate applications such as web servers or database services might be flagged. Monitor and exclude these applications by their known behaviors or specific file paths they use.
+- Regular system updates or package installations can involve temporary file handling. Recognize and exclude these activities by identifying the associated package manager processes or update scripts.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further spread of the potential malware. Disconnect it from the network to contain the threat.
+- Terminate any suspicious processes identified in the alert, especially those executed from temporary directories, to stop any ongoing malicious activity.
+- Conduct a thorough examination of the affected directories (/tmp, /var/tmp, etc.) to identify and remove any remaining malicious files or scripts.
+- Restore any affected systems from a known good backup to ensure that no remnants of the malware remain.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the threat actor.
+- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of this behavior, focusing on file creation, execution, and deletion events in temporary directories.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml
index 3df209bbcc9..5019e5be9ec 100644
--- a/rules/linux/execution_interpreter_tty_upgrade.toml
+++ b/rules/linux/execution_interpreter_tty_upgrade.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,39 @@ process where host.os.type == "linux" and event.type == "start" and
     process.args_count == 4)
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Upgrade of Non-interactive Shell
+
+In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging potential misuse indicative of an upgrade attempt.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of `stty` or `script` commands with the specific arguments outlined in the detection rule, such as `stty raw -echo` or `script -qc /dev/null`.
+- Examine the parent process of the flagged `stty` or `script` command to determine how the shell was initially spawned and identify any potentially malicious scripts or binaries.
+- Check the user account associated with the process execution to assess if it aligns with expected user behavior or if it indicates potential compromise.
+- Investigate the network connections associated with the host at the time of the alert to identify any suspicious remote connections that could be indicative of a reverse shell.
+- Review historical process execution and login records for the user and host to identify any patterns of suspicious activity or previous attempts to establish a reverse shell.
+
+### False positive analysis
+
+- System administrators or legitimate users may use stty or script commands for routine maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known user accounts or specific maintenance windows.
+- Automated scripts or cron jobs that utilize stty or script for legitimate purposes might be flagged. Review these scripts and whitelist them by process hash or command line pattern to prevent false positives.
+- Development environments where developers frequently use stty or script for testing purposes can generate alerts. Consider excluding specific development machines or user groups from the rule to reduce noise.
+- Monitoring tools or security solutions that simulate shell upgrades for testing or auditing purposes may inadvertently trigger the rule. Identify these tools and add them to an exception list based on their process name or execution path.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving `stty` or `script` with the flagged arguments, to disrupt the attacker's attempt to upgrade the shell.
+- Conduct a thorough review of the affected system's logs and process history to identify any additional malicious activities or compromised accounts.
+- Reset credentials for any user accounts that were active during the time of the alert to prevent unauthorized access using potentially compromised credentials.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker.
+- Enhance monitoring and logging on the affected host and similar systems to detect any future attempts to upgrade non-interactive shells or other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml
index 9298d4d3de7..36b6dd20033 100644
--- a/rules/linux/execution_nc_listener_via_rlwrap.toml
+++ b/rules/linux/execution_nc_listener_via_rlwrap.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,40 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and
   process.args : "*l*" and process.args_count >= 4
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Netcat Listener Established via rlwrap
+
+Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring rlwrap's execution with netcat-related arguments, signaling potential unauthorized activity.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of rlwrap with netcat-related arguments by examining the process.name and process.args fields.
+- Check the process start time and correlate it with any known scheduled tasks or user activity to determine if the execution was expected or authorized.
+- Investigate the source IP address and port used in the netcat connection to identify potential external connections or data exfiltration attempts.
+- Analyze the user account associated with the process execution to verify if the account has a history of similar activities or if it has been compromised.
+- Examine any related network traffic logs to identify unusual patterns or connections that coincide with the alert, focusing on the host where the process was executed.
+- Look for any additional processes spawned by the netcat listener to detect further malicious activity or persistence mechanisms.
+
+### False positive analysis
+
+- Development and testing environments may frequently use rlwrap with netcat for legitimate purposes, such as testing network applications or scripts. To manage this, create exceptions for specific user accounts or IP addresses known to be involved in development activities.
+- System administrators might use rlwrap with netcat for troubleshooting or network diagnostics. Identify and exclude these activities by setting up rules that recognize the specific command patterns or user roles associated with administrative tasks.
+- Automated scripts or cron jobs that utilize rlwrap and netcat for routine maintenance or monitoring can trigger false positives. Review and whitelist these scripts by their unique process identifiers or command structures to prevent unnecessary alerts.
+- Educational or training environments where rlwrap and netcat are used for learning purposes can generate alerts. Implement exceptions based on the environment's network segment or user group to reduce noise from these benign activities.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the rlwrap and netcat processes on the affected host to disrupt the reverse shell connection.
+- Conduct a forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms.
+- Review and secure any compromised accounts or credentials that may have been used or accessed during the incident.
+- Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities.
+- Enhance monitoring and logging on the affected host and network to detect similar activities in the future.
+- Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
index 4caaf8cd36e..b2a0eb82410 100644
--- a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
+++ b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ sample by host.id, process.pid, process.name
   [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
    not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Connection from Binary with RWX Memory Region
+
+In Linux environments, the `mprotect()` system call adjusts memory permissions, potentially enabling read, write, and execute (RWX) access. Adversaries exploit this to execute malicious code in memory, often followed by network connections to exfiltrate data or communicate with command-and-control servers. The detection rule identifies such behavior by monitoring for RWX memory changes and subsequent network activity, flagging suspicious processes for further analysis.
+
+### Possible investigation steps
+
+- Review the process details using the process.pid and process.name fields to identify the binary that requested RWX memory permissions.
+- Investigate the context of the mprotect() syscall by examining the process's command line arguments and parent process to understand its origin and purpose.
+- Analyze the network connection details, focusing on the destination.ip field, to determine if the connection was made to a known malicious IP or an unusual external server.
+- Check the process's execution history and any associated files or scripts to identify potential malicious payloads or scripts that may have been executed.
+- Correlate the event with other security logs or alerts from the same host.id to identify any related suspicious activities or patterns.
+- Assess the risk and impact by determining if any sensitive data was accessed or exfiltrated during the network connection attempt.
+
+### False positive analysis
+
+- Legitimate software updates or patches may temporarily use RWX memory regions. Monitor the specific process names and verify if they are associated with known update mechanisms. Consider adding these processes to an exception list if they are verified as safe.
+- Development tools and environments often require RWX permissions for debugging or testing purposes. Identify these tools and exclude them from the rule if they are part of a controlled and secure development environment.
+- Certain system services or daemons, like custom web servers or network services, might use RWX memory regions for legitimate reasons. Review the process names and network destinations to determine if they are part of expected system behavior, and exclude them if confirmed.
+- Security software or monitoring tools may exhibit this behavior as part of their normal operation. Validate these processes and consider excluding them if they are recognized as part of your security infrastructure.
+- Custom scripts or automation tasks that require dynamic code execution might trigger this rule. Ensure these scripts are reviewed and approved, then exclude them if they are deemed non-threatening.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further data exfiltration or communication with potential command-and-control servers.
+- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity.
+- Conduct a memory dump of the affected system to capture the current state for forensic analysis, focusing on the RWX memory regions.
+- Review and analyze the network logs to identify any external IP addresses or domains the process attempted to connect to, and block these on the network firewall.
+- Patch and update the affected system to the latest security updates to mitigate any known vulnerabilities that could have been exploited.
+- Implement stricter memory protection policies to prevent processes from obtaining RWX permissions unless absolutely necessary.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if this is part of a larger attack campaign."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_network_event_post_compilation.toml b/rules/linux/execution_network_event_post_compilation.toml
index 366caed4d72..0883155d452 100644
--- a/rules/linux/execution_network_event_post_compilation.toml
+++ b/rules/linux/execution_network_event_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,41 @@ sequence by host.id with maxspan=1m
      process.name in ("simpleX", "conftest", "ssh", "python", "ispnull", "pvtui")
    )] by process.name
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Connection via Recently Compiled Executable
+
+In Linux environments, compiling and executing programs is routine for development. However, adversaries exploit this by compiling malicious code to establish reverse shells, enabling remote control. The detection rule identifies this threat by monitoring sequences of compilation, execution, and network activity, flagging unusual connections that deviate from typical patterns, thus indicating potential compromise.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the compiler used (e.g., gcc, g++, cc) and examine the arguments passed during the compilation to understand the nature of the compiled code.
+- Investigate the file creation event associated with the linker (ld) to determine the output executable file and its location on the system.
+- Analyze the subsequent process execution to identify the newly compiled executable and verify its legitimacy by checking its hash against known malware databases.
+- Examine the network connection attempt details, focusing on the destination IP address, to determine if it is associated with known malicious activity or command-and-control servers.
+- Check the process name involved in the network connection attempt to ensure it is not a commonly used legitimate process, as specified in the query exclusions (e.g., simpleX, conftest, ssh, python, ispnull, pvtui).
+- Correlate the timing of the compilation, execution, and network connection events to assess if they align with typical user behavior or indicate suspicious activity.
+
+### False positive analysis
+
+- Development activities involving frequent compilation and execution of new code can trigger false positives. To manage this, exclude specific user accounts or directories commonly used for legitimate development work.
+- Automated build systems or continuous integration pipelines may compile and execute code regularly. Identify and exclude these processes or IP addresses from monitoring to prevent false alerts.
+- Legitimate software updates or installations that involve compiling source code can be mistaken for malicious activity. Exclude known update processes or package managers from the rule.
+- Network connections to internal or trusted IP addresses that are not part of the typical exclusion list might be flagged. Update the exclusion list to include these trusted IP ranges.
+- Certain legitimate applications that compile and execute code as part of their normal operation, such as IDEs or scripting environments, should be identified and excluded from the rule to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified in the alert, especially those related to the recently compiled executable and any associated network connections.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or scheduled tasks.
+- Remove any malicious executables or scripts identified during the investigation from the system to prevent re-execution.
+- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_perl_tty_shell.toml b/rules/linux/execution_perl_tty_shell.toml
index e8399decc4a..2aefc2e52ef 100644
--- a/rules/linux/execution_perl_tty_shell.toml
+++ b/rules/linux/execution_perl_tty_shell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,40 @@ query = '''
 event.category:process and host.os.type:linux and event.type:(start or process_started) and process.name:perl and
   process.args:("exec \"/bin/sh\";" or "exec \"/bin/dash\";" or "exec \"/bin/bash\";")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Interactive Terminal Spawned via Perl
+
+Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as "exec \\"/bin/sh\\";", "exec \\"/bin/dash\\";", or "exec \\"/bin/bash\\";".
+- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access.
+- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise.
+- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers.
+- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity.
+- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign.
+
+### False positive analysis
+
+- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments.
+- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule.
+- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories.
+- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity.
+- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity.
+- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack.
+- Restore the affected system from a known good backup to ensure any malicious changes are removed.
+- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_potential_hack_tool_executed.toml b/rules/linux/execution_potential_hack_tool_executed.toml
index c1c2f7c4f02..1f10787bfc8 100644
--- a/rules/linux/execution_potential_hack_tool_executed.toml
+++ b/rules/linux/execution_potential_hack_tool_executed.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -81,6 +81,41 @@ process.name in~ (
   "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Linux Hack Tool Launched
+
+Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap".
+- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised.
+- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity.
+- Examine the command line arguments used during the process execution to understand the intent and scope of the activity.
+- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities.
+- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives.
+
+### False positive analysis
+
+- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments.
+- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill.
+- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior.
+- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts.
+- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities.
+- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts.
+- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed.
+- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools.
+- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_potentially_overly_permissive_container_creation.toml b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
index d70d112d89b..5c3b93f27ec 100644
--- a/rules/linux/execution_potentially_overly_permissive_container_creation.toml
+++ b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,47 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:docker and
 process.args:(run and --privileged)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privileged Docker Container Creation
+
+Docker containers are lightweight, portable units that package applications and their dependencies. The `--privileged` flag grants containers extensive host access, posing security risks. Adversaries exploit this to escalate privileges or escape containers. The detection rule identifies unusual privileged container creation by monitoring specific process actions and arguments, helping to flag potential threats early.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the `--privileged` flag in the process arguments, as indicated by the query field `process.args:(run and --privileged)`.
+- Identify the parent process of the Docker command by examining the `event.category:process` and `event.type:start` fields to determine if it originates from an unusual or unauthorized source.
+- Check the user account associated with the Docker process to verify if it has legitimate access and permissions to create privileged containers.
+- Investigate the timeline of events leading up to the container creation by reviewing related logs and events around the `event.action:exec` to identify any suspicious activities or patterns.
+- Assess the container's configuration and running processes to determine if any unauthorized or potentially harmful applications are being executed within the container.
+- Correlate the alert with other security events or alerts in the environment to identify potential indicators of compromise or broader attack patterns.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule if system administrators use the --privileged flag for legitimate container management. To handle this, identify and document these tasks, then create exceptions for known administrative processes.
+- Automated deployment scripts that require elevated privileges might also cause false positives. Review these scripts and whitelist them by specifying the parent process or script name in the exclusion criteria.
+- Development environments often use privileged containers for testing purposes. To reduce noise, exclude processes originating from known development machines or user accounts.
+- Some monitoring or security tools may use privileged containers for legitimate purposes. Verify these tools and add them to the exception list to prevent unnecessary alerts.
+- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further interaction with the host system. This can be done by stopping the container using `docker stop <container_id>`.
+
+- Review and revoke any unnecessary permissions or access rights granted to the container. Ensure that the `--privileged` flag is not used unless absolutely necessary.
+
+- Conduct a thorough investigation of the container's filesystem and running processes to identify any malicious activity or unauthorized changes. Use tools like `docker exec` to inspect the container's environment.
+
+- Check for any signs of container escape or host compromise by reviewing system logs and monitoring for unusual activity on the host machine.
+
+- If a compromise is confirmed, initiate a full incident response procedure, including forensic analysis and system restoration from clean backups.
+
+- Update and patch the Docker daemon and any related software to the latest versions to mitigate known vulnerabilities that could be exploited.
+
+- Enhance monitoring and alerting for privileged container creation by integrating additional security tools or services that provide real-time threat intelligence and anomaly detection."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_process_started_in_shared_memory_directory.toml b/rules/linux/execution_process_started_in_shared_memory_directory.toml
index f3f896a29d3..357478ce610 100644
--- a/rules/linux/execution_process_started_in_shared_memory_directory.toml
+++ b/rules/linux/execution_process_started_in_shared_memory_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,42 @@ user.id == "0" and process.executable : ("/dev/shm/*", "/run/shm/*", "/var/run/*
 not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", 
 "/var/run/argo/argoexec") and not process.parent.command_line : "/usr/bin/runc init"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Binary Executed from Shared Memory Directory
+
+Shared memory directories in Linux, such as /dev/shm and /run/shm, are designed for efficient inter-process communication. However, adversaries exploit these directories to execute binaries stealthily, often as root, bypassing traditional security measures. The detection rule identifies such anomalies by monitoring for root-executed binaries in these directories, excluding known legitimate processes, thus flagging potential backdoor activities.
+
+### Possible investigation steps
+
+- Review the process executable path to confirm it resides in a shared memory directory such as /dev/shm, /run/shm, /var/run, or /var/lock, and verify it is not part of the known exclusions like /var/run/docker or /var/run/utsns.
+- Investigate the parent process of the suspicious executable to understand the context of its execution, focusing on the command line used, especially if it does not match the exclusion pattern /usr/bin/runc init.
+- Check the process's creation time and correlate it with any other suspicious activities or alerts around the same timeframe to identify potential patterns or related incidents.
+- Analyze the binary file in question for any known malicious signatures or unusual characteristics using tools like file integrity checkers or antivirus solutions.
+- Review system logs and audit logs for any unauthorized access or privilege escalation attempts that might have led to the execution of the binary as root.
+- Investigate the user account activity associated with user.id "0" to ensure there are no signs of compromise or misuse of root privileges.
+- If possible, isolate the affected system to prevent further potential malicious activity while the investigation is ongoing.
+
+### False positive analysis
+
+- Docker-related processes can trigger false positives when binaries are executed from shared memory directories. To mitigate this, exclude paths like /var/run/docker/* from the detection rule.
+- Processes related to container orchestration tools such as Kubernetes might also cause false positives. Exclude paths like /var/run/utsns/* and /var/run/s6/* to prevent these.
+- Cloudera services may execute binaries from shared memory directories as part of their normal operations. Exclude /var/run/cloudera-scm-agent/* to avoid false alerts.
+- Argo workflows might execute binaries in these directories. Exclude /var/run/argo/argoexec to reduce false positives.
+- Legitimate use of /usr/bin/runc init as a parent process can be excluded to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the threat actor.
+- Terminate any suspicious processes running from the shared memory directories (/dev/shm, /run/shm, /var/run, /var/lock) to halt potential malicious activity.
+- Conduct a thorough review of the system's process tree and logs to identify any additional malicious binaries or scripts that may have been executed or are scheduled to run.
+- Remove any unauthorized binaries or scripts found in the shared memory directories and other critical system paths to eliminate persistence mechanisms.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation.
+- Implement enhanced monitoring and alerting for any future execution of binaries from shared memory directories, ensuring that legitimate processes are whitelisted appropriately.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml
index 5dd00e41674..fd3e8ca50c8 100644
--- a/rules/linux/execution_python_tty_shell.toml
+++ b/rules/linux/execution_python_tty_shell.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
    "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1)
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Interactive Terminal Spawned via Python
+
+Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh).
+- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal.
+- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious.
+- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network.
+- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events.
+- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event.
+
+### False positive analysis
+
+- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks.
+- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration.
+- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships.
+- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control.
+- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files.
+- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml
index 9f0f14b0134..3420984428c 100644
--- a/rules/linux/execution_python_webserver_spawned.toml
+++ b/rules/linux/execution_python_webserver_spawned.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ process where host.os.type == "linux" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Web Server Spawned via Python
+
+Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer".
+- Investigate the user account associated with the process to determine if it is a known or expected user for running such services.
+- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server".
+- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration.
+- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts.
+- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server.
+
+### False positive analysis
+
+- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses.
+- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule.
+- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods.
+- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts.
+- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement.
+- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server.
+- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector.
+- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident.
+- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited.
+- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_remote_code_execution_via_postgresql.toml b/rules/linux/execution_remote_code_execution_via_postgresql.toml
index 67ad46d0a1e..86eb35a058e 100644
--- a/rules/linux/execution_remote_code_execution_via_postgresql.toml
+++ b/rules/linux/execution_remote_code_execution_via_postgresql.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,40 @@ event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "p
   process.parent.command_line like "*BECOME-SUCCESS-*"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Code Execution via Postgresql
+
+PostgreSQL, a robust open-source database system, can be exploited by attackers to execute arbitrary code if they gain unauthorized access or exploit vulnerabilities like SQL injection. Adversaries may leverage command execution capabilities to perform malicious actions. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions that resemble command injection patterns, while excluding legitimate operations, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious shell executions by the PostgreSQL user, focusing on processes with arguments containing "*sh" and "echo*".
+- Check the parent process information to determine if the process was initiated by a known legitimate service, such as "puppet", or if it includes "BECOME-SUCCESS-" in the command line, which are excluded from the rule.
+- Investigate the source of the PostgreSQL access to identify if it originated from an unauthorized or unusual IP address or user account.
+- Analyze the timeline of events leading up to and following the alert to identify any patterns or additional suspicious activities that may indicate a broader attack.
+- Correlate the alert with other security events or logs from the same host or network segment to assess if there are related indicators of compromise or ongoing threats.
+
+### False positive analysis
+
+- Puppet processes may trigger false positives due to their legitimate use of shell commands. To mitigate this, ensure that puppet-related processes are excluded by verifying that process.parent.name is set to "puppet".
+- Automation tools that use shell scripts for configuration management might be flagged. Review and exclude these by checking for specific command patterns that are known to be safe, such as those containing "BECOME-SUCCESS".
+- Scheduled maintenance scripts executed by the postgres user could be misidentified as threats. Identify these scripts and add them to an exclusion list based on their command line patterns.
+- Regular database backup operations that involve shell commands might be mistakenly flagged. Document these operations and exclude them by matching their specific command line arguments.
+- Custom monitoring scripts that execute shell commands under the postgres user should be reviewed and excluded if they are verified as non-malicious.
+
+### Response and remediation
+
+- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or malicious actions.
+- Terminate any suspicious processes identified by the detection rule to halt potential malicious activities.
+- Conduct a thorough review of the PostgreSQL server logs to identify any unauthorized access attempts or successful exploitations, focusing on the timeframes around the detected events.
+- Reset credentials for the PostgreSQL user and any other potentially compromised accounts to prevent further unauthorized access.
+- Apply the latest security patches and updates to the PostgreSQL server to mitigate known vulnerabilities that could be exploited.
+- Implement network segmentation to limit access to the PostgreSQL server, ensuring only authorized systems and users can connect.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml
index 4333ff0ccd9..3ae5383ced2 100644
--- a/rules/linux/execution_shell_openssl_client_or_server.toml
+++ b/rules/linux/execution_shell_openssl_client_or_server.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   ) and
   not process.parent.executable in ("/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Openssl Client or Server Activity
+
+OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port".
+- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert").
+- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious.
+- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity.
+- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications.
+
+### False positive analysis
+
+- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment.
+- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes.
+- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening.
+- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion.
+- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities.
+- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access.
+- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity.
+- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml
index 1b18cd14333..1785aac5b1c 100644
--- a/rules/linux/execution_shell_via_background_process.toml
+++ b/rules/linux/execution_shell_via_background_process.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,41 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and 
   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Reverse Shell via Background Process
+
+In Linux environments, background processes can be manipulated to establish reverse shells, allowing adversaries to gain remote access. By exploiting shell commands to open network sockets, attackers can create backdoor connections. The detection rule identifies suspicious executions of background processes, like 'setsid' or 'nohup', with arguments indicating socket activity in '/dev/tcp', often initiated by common shell interpreters. This helps in flagging potential reverse shell activities for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious arguments, specifically looking for '/dev/tcp' in the process.args field, which indicates an attempt to open a network socket.
+- Identify the parent process by examining the process.parent.name field to determine if it is one of the common shell interpreters like 'bash', 'dash', 'sh', etc., which could suggest a script-based execution.
+- Check the user context under which the process was executed to assess if it aligns with expected user behavior or if it indicates potential compromise of a user account.
+- Investigate the network activity associated with the host to identify any unusual outbound connections that could correlate with the reverse shell attempt.
+- Correlate the event with other security alerts or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Review historical data for similar process executions on the host to determine if this is an isolated incident or part of a recurring pattern.
+
+### False positive analysis
+
+- Legitimate administrative scripts may use background processes with network socket activity for maintenance tasks. Review the script's purpose and source to determine if it is authorized.
+- Automated monitoring tools might execute commands that match the rule's criteria. Identify these tools and consider excluding their specific process names or paths from the rule.
+- Development environments often run test scripts that open network connections. Verify the development context and exclude known development-related processes to reduce noise.
+- Backup or synchronization software may use similar techniques to transfer data. Confirm the software's legitimacy and add exceptions for its processes if necessary.
+- System updates or package management tools might trigger alerts when installing or updating software. Monitor these activities and whitelist trusted update processes.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious background processes identified by the alert, specifically those involving 'setsid' or 'nohup' with '/dev/tcp' in their arguments.
+- Conduct a thorough review of the affected system's process and network activity logs to identify any additional indicators of compromise or lateral movement.
+- Reset credentials for any accounts that were active on the affected system to prevent unauthorized access using potentially compromised credentials.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
index dcbcb5da900..ffb033bbdd6 100644
--- a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
+++ b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,41 @@ sequence by host.id, process.entity_id with maxspan=5s
        (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*")
    )]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Reverse Shell via Child
+
+Reverse shells are a technique where attackers gain remote access to a system by initiating a connection from the target back to the attacker's machine. This is often achieved using shell processes like bash or socat. Adversaries exploit this by executing commands remotely, bypassing firewalls. The detection rule identifies such activity by monitoring for network events followed by suspicious shell process executions, focusing on unusual command-line arguments and parent-child process relationships.
+
+### Possible investigation steps
+
+- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network.
+- Examine the process execution details, focusing on the command-line arguments used by the shell process. Look for unusual or suspicious arguments such as "-i" or "-l" that may indicate interactive or login shells.
+- Investigate the parent-child process relationship, especially if the parent process is "socat" with arguments containing "exec". This could suggest an attempt to execute a reverse shell.
+- Check the timeline of events to determine if the network event and shell process execution occurred within a short time frame (maxspan=5s), which may indicate a coordinated attack.
+- Correlate the alert with any other recent suspicious activities on the host, such as unauthorized access attempts or changes in system configurations, to assess the broader context of the potential threat.
+- Verify the legitimacy of the involved processes and connections by consulting with system owners or reviewing system documentation to rule out any false positives due to legitimate administrative activities.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools that use shell processes with interactive flags may trigger the rule. To manage this, identify and document these scripts, then create exceptions for their specific command-line arguments or parent processes.
+- Automated maintenance tasks or cron jobs that involve shell execution with similar command-line arguments can be mistaken for reverse shell activity. Review these tasks and exclude them by specifying their unique process names or arguments.
+- Development or testing environments where developers frequently use shell processes for debugging or testing purposes might cause false positives. Consider excluding these environments by filtering based on host identifiers or specific user accounts.
+- Network monitoring tools or legitimate applications that use socat for network connections may appear suspicious. Identify these applications and exclude their specific process names or parent-child relationships from the detection rule.
+- Custom scripts or applications that mimic reverse shell behavior for legitimate purposes should be reviewed and excluded by adding their specific process names or command-line patterns to the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by or involving the listed shell programs (e.g., bash, socat).
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files.
+- Review and reset credentials for any accounts that may have been compromised, ensuring the use of strong, unique passwords.
+- Apply relevant security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Monitor network traffic for any further suspicious activity, particularly outgoing connections to unknown or suspicious IP addresses.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_java_revshell_linux.toml b/rules/linux/execution_shell_via_java_revshell_linux.toml
index 8294a0bd405..c900b422fd8 100644
--- a/rules/linux/execution_shell_via_java_revshell_linux.toml
+++ b/rules/linux/execution_shell_via_java_revshell_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,39 @@ sequence by host.id with maxspan=5s
      "/usr/lib64/NetExtender.jar", "/usr/lib/jenkins/jenkins.war"
    )] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Reverse Shell via Java
+
+Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts.
+
+### Possible investigation steps
+
+- Review the network connection details, focusing on the destination IP address to determine if it is external or potentially malicious, as the rule excludes common internal and reserved IP ranges.
+- Examine the Java process that initiated the network connection, including its executable path and arguments, to identify any unusual or unauthorized JAR files being executed.
+- Investigate the child shell process spawned by the Java application, checking its command-line arguments and execution context to assess if it aligns with known reverse shell patterns.
+- Cross-reference the parent Java process and the child shell process with known benign applications or services, such as Jenkins or NetExtender, to rule out false positives.
+- Analyze historical data for the host to identify any previous similar activities or patterns that might indicate a persistent threat or repeated exploitation attempts.
+
+### False positive analysis
+
+- Java-based administrative tools like Jenkins may trigger false positives when executing shell commands. Exclude known benign Java applications such as Jenkins by adding their specific JAR paths to the exception list.
+- Automated scripts or maintenance tasks that use Java to execute shell commands can be mistaken for reverse shell activity. Identify and exclude these scripts by specifying their unique process arguments or executable paths.
+- Development environments where Java applications frequently execute shell commands for testing purposes can generate false alerts. Consider excluding these environments by filtering based on specific host identifiers or network segments.
+- Security tools that utilize Java for network operations and shell executions might be flagged. Verify and exclude these tools by adding their process names or executable paths to the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious Java processes identified in the alert to stop potential reverse shell activity.
+- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or lateral movement attempts.
+- Remove any unauthorized or malicious Java JAR files and associated scripts from the system.
+- Apply security patches and updates to the Java environment and any other vulnerable software on the affected host.
+- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
index 4d5cb20854a..3171d79f636 100644
--- a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
+++ b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,41 @@ sequence by host.id, process.entity_id with maxspan=1s
     process.name : ("python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk") and 
     destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Reverse Shell via Suspicious Child Process
+
+Reverse shells are a common technique used by attackers to gain remote access to a compromised system. They exploit scripting languages and utilities like Python, Perl, and Netcat to execute commands remotely. The detection rule identifies suspicious process chains and network activities, such as unexpected shell spawns and outbound connections, to flag potential reverse shell attempts, leveraging process and network event analysis to detect anomalies.
+
+### Possible investigation steps
+
+- Review the process chain to identify the parent process and determine if it is expected behavior for the system. Check the process.parent.name field for any unusual or unauthorized parent processes.
+- Analyze the process arguments captured in the alert, such as process.args, to understand the command being executed and assess if it aligns with known reverse shell patterns.
+- Investigate the network connection details, focusing on the destination.ip field, to determine if the connection is to a known malicious IP or an unexpected external address.
+- Check the process.name field to identify the specific utility used (e.g., python, perl, nc) and verify if its usage is legitimate or if it indicates a potential compromise.
+- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that may indicate a broader attack.
+- Consult threat intelligence sources to gather information on any identified IP addresses or domains involved in the network connection to assess their reputation and potential threat level.
+
+### False positive analysis
+
+- Development and testing environments may frequently execute scripts using languages like Python, Perl, or Ruby, which can trigger the rule. To manage this, consider excluding specific host IDs or process names associated with known development activities.
+- Automated scripts or cron jobs that utilize network connections for legitimate purposes, such as data backups or updates, might be flagged. Identify these processes and add them to an exception list based on their parent process names or specific arguments.
+- System administrators might use tools like Netcat or OpenSSL for troubleshooting or monitoring network connections. If these activities are routine and verified, exclude them by specifying the administrator's user ID or the specific command patterns used.
+- Security tools or monitoring solutions that simulate attack scenarios for testing purposes can also trigger this rule. Ensure these tools are recognized and excluded by their process names or associated network activities.
+- Custom scripts that use shell commands to interact with remote systems for maintenance tasks may appear suspicious. Review these scripts and exclude them by their unique process arguments or parent process names.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving scripting languages or utilities like Python, Perl, or Netcat.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files.
+- Review and reset credentials for any accounts that may have been accessed or compromised during the incident.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Monitor network traffic for any signs of further suspicious activity, focusing on outbound connections from the affected host.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_meterpreter_linux.toml b/rules/linux/execution_shell_via_meterpreter_linux.toml
index c279ac88981..b0c80532b4d 100644
--- a/rules/linux/execution_shell_via_meterpreter_linux.toml
+++ b/rules/linux/execution_shell_via_meterpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,40 @@ sample by host.id, process.pid, user.id
   [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"]
   [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Meterpreter Reverse Shell
+
+Meterpreter is a sophisticated payload within the Metasploit framework, enabling attackers to execute commands and scripts on compromised systems. Adversaries exploit it to perform system reconnaissance and data exfiltration. The detection rule identifies suspicious file access patterns typical of Meterpreter's system fingerprinting activities, such as reading key system files, indicating a potential reverse shell connection.
+
+### Possible investigation steps
+
+- Review the process associated with the alert by examining the process ID (process.pid) and user ID (user.id) to determine if the process is legitimate or potentially malicious.
+- Check the host ID (host.id) to identify the specific system where the suspicious activity was detected and assess if it is a high-value target or has been previously compromised.
+- Investigate the command history and running processes on the affected host to identify any unusual or unauthorized activities that may indicate a Meterpreter session.
+- Analyze network connections from the host to detect any suspicious outbound connections that could suggest a reverse shell communication.
+- Examine the file access patterns, particularly the access to files like /etc/machine-id, /etc/passwd, /proc/net/route, /proc/net/ipv6_route, and /proc/net/if_inet6, to understand the context and purpose of these reads and whether they align with normal system operations.
+- Correlate the alert with other security events or logs from the same timeframe to identify any additional indicators of compromise or related malicious activities.
+
+### False positive analysis
+
+- System administration scripts or tools that perform regular checks on system files like /etc/machine-id or /etc/passwd may trigger this rule. To manage this, identify and whitelist these legitimate processes by their process ID or user ID.
+- Backup or monitoring software that accesses network configuration files such as /proc/net/route or /proc/net/ipv6_route can cause false positives. Exclude these applications by adding exceptions for their specific file access patterns.
+- Security tools that perform network diagnostics or inventory checks might read files like /proc/net/if_inet6. Review these tools and exclude their known benign activities from triggering the rule.
+- Custom scripts used for system health checks or inventory management that access the flagged files should be reviewed. If deemed safe, add them to an exception list based on their host ID or user ID.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further data exfiltration or lateral movement by the attacker.
+- Terminate any suspicious processes identified by the detection rule, particularly those associated with the process IDs flagged in the alert.
+- Conduct a thorough review of the affected system's logs and file access history to identify any additional unauthorized access or data exfiltration attempts.
+- Change all credentials and keys that may have been exposed or compromised on the affected system, especially those related to user accounts identified in the alert.
+- Restore the affected system from a known good backup to ensure any malicious changes are removed, and verify the integrity of the restored system.
+- Implement network segmentation to limit the potential impact of future attacks and enhance monitoring of critical systems for similar suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_suspicious_binary.toml b/rules/linux/execution_shell_via_suspicious_binary.toml
index 3e79f5cfac4..eb806766a74 100644
--- a/rules/linux/execution_shell_via_suspicious_binary.toml
+++ b/rules/linux/execution_shell_via_suspicious_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,41 @@ sequence by host.id, process.entity_id with maxspan=1s
   process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
   process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Reverse Shell via Suspicious Binary
+
+Reverse shells are a common technique used by attackers to gain persistent access to a compromised system. They exploit legitimate shell environments to execute commands remotely. Adversaries often deploy binaries in unusual directories to evade detection. The detection rule identifies suspicious binaries executed in these locations, followed by network activity and shell spawning, indicating potential reverse shell activity. This approach helps in identifying unauthorized access attempts on Linux systems.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the suspicious binary's path and name, focusing on the directories specified in the query such as /tmp, /var/tmp, and /dev/shm.
+- Examine the parent process of the suspicious binary to determine if it was spawned by a legitimate shell process like bash or sh, as indicated in the query.
+- Analyze the network activity associated with the suspicious binary, paying attention to the destination IP address to identify any external connections that are not local (i.e., not 127.0.0.1 or ::1).
+- Check the process tree to see if a new shell was spawned following the network activity, which could indicate a reverse shell attempt.
+- Investigate the user account under which the suspicious process was executed to assess if it aligns with expected behavior or if it might be compromised.
+- Correlate the event timestamps to understand the sequence of actions and verify if they align with typical reverse shell behavior patterns.
+
+### False positive analysis
+
+- Legitimate administrative scripts or binaries may be executed from directories like /tmp or /var/tmp during maintenance tasks. To handle this, create exceptions for known scripts or binaries used by trusted administrators.
+- Automated deployment tools might temporarily use directories such as /dev/shm or /run for staging files. Identify these tools and exclude their processes from triggering the rule.
+- Custom monitoring or backup scripts could initiate network connections from non-standard directories. Review these scripts and whitelist their activities if they are verified as safe.
+- Development or testing environments might involve executing binaries from unusual locations. Ensure these environments are well-documented and exclude their processes from the detection rule.
+- Some legitimate applications may spawn shells as part of their normal operation. Identify these applications and add them to an exception list to prevent false alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving shell spawning.
+- Conduct a thorough review of the system's scheduled tasks, startup scripts, and cron jobs to identify and remove any unauthorized entries that may have been added by the attacker.
+- Analyze network logs to identify any external IP addresses involved in the suspicious network activity and block these IPs at the firewall to prevent further connections.
+- Restore the affected system from a known good backup to ensure that any malicious changes are reverted.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
index 56c51e0f506..1ff31372e2e 100644
--- a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,41 @@ sequence by host.id with maxspan=5s
        (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*")
    )] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Reverse Shell
+
+Reverse shells are tools that adversaries use to gain remote access to a system by initiating a connection from the target back to the attacker. This detection rule identifies such activity by monitoring for network events followed by shell process creation on Linux systems. It flags suspicious patterns, such as shell processes with interactive flags or spawned by tools like socat, indicating potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network ranges.
+- Examine the process tree to understand the parent-child relationship, focusing on the shell process creation following the network event. Verify if the shell process was spawned by a known tool like socat.
+- Check the process arguments for interactive flags such as "-i" or "-l" to determine if the shell was intended to be interactive, which could indicate malicious intent.
+- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations.
+- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns that might indicate a broader attack campaign.
+- Assess the risk and impact of the potential reverse shell by determining if any sensitive data or critical systems could have been accessed or compromised.
+
+### False positive analysis
+
+- Legitimate administrative tasks using interactive shells may trigger this rule. System administrators often use shells with interactive flags for maintenance. To mitigate, create exceptions for known administrator accounts or specific IP addresses.
+- Automated scripts or cron jobs that use shell commands with interactive flags can be mistaken for reverse shells. Review and whitelist these scripts by process name or parent process ID to prevent false alerts.
+- Tools like socat are used in legitimate network troubleshooting and testing. If socat is frequently used in your environment, consider excluding specific command patterns or user accounts associated with its legitimate use.
+- Development environments may spawn shell processes as part of testing or deployment workflows. Identify and exclude these environments by host ID or process name to reduce noise.
+- Internal network connections that match the rule's criteria but are part of normal operations can be excluded by specifying internal IP ranges or known service accounts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by socat or with interactive flags.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified files.
+- Review and secure network configurations to ensure that only authorized IP addresses can initiate connections to critical systems.
+- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited.
+- Implement enhanced monitoring and logging on the affected host and network to detect any further attempts at reverse shell activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
index e4c42a2a178..832d4bf4277 100644
--- a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -87,6 +87,41 @@ sample by host.id, process.pid, process.parent.pid
     ) and network.direction == "egress" and destination.ip != null and
    not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Reverse Shell via UDP
+
+Reverse shells over UDP can be exploited by attackers to bypass firewalls and gain unauthorized access to systems. This technique leverages UDP's connectionless nature, making it harder to detect. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies suspicious processes executing network-related syscalls and egress connections, flagging potential reverse shell activity.
+
+### Possible investigation steps
+
+- Review the process details such as process.pid, process.parent.pid, and process.name to identify the specific process that triggered the alert and its parent process.
+- Examine the command line arguments and environment variables associated with the suspicious process to understand its intended function and origin.
+- Check the network connection details, including destination.ip and network.direction, to determine the external entity the process attempted to connect to and assess if it is a known malicious IP or domain.
+- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access.
+- Analyze historical logs for any previous instances of similar process executions or network connections to identify patterns or repeated attempts.
+- Correlate the alert with other security events or alerts from the same host.id to gather additional context and assess the scope of potential compromise.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools may trigger the rule if they use UDP for valid network operations. Users can create exceptions for specific scripts or processes that are known to perform routine administrative tasks.
+- Automated monitoring or network management tools that use UDP for health checks or status updates might be flagged. Identify these tools and exclude their process names or network patterns from the rule.
+- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes can cause false positives. Consider excluding specific host IDs or process names associated with these environments.
+- Custom applications that use UDP for communication, especially if they are developed in-house, may be mistakenly identified. Review these applications and whitelist their process names or network behaviors if they are verified as safe.
+- Network scanning or diagnostic tools that use UDP for troubleshooting can be misinterpreted as malicious. Ensure these tools are recognized and excluded from the detection rule if they are part of regular network maintenance activities.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, particularly those associated with known reverse shell tools or scripting languages.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files.
+- Review and update firewall rules to block outbound UDP traffic from unauthorized applications or processes, ensuring legitimate traffic is not disrupted.
+- Reset credentials for any accounts accessed from the affected host, especially if they have administrative privileges.
+- 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 enhanced monitoring and logging for similar suspicious activities, focusing on the execution of network-related syscalls and egress connections from scripting languages or network tools."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
index 5ad64dc7846..58d138fcefb 100644
--- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
+++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,40 @@ not process.args : "/var/log/messages" and
 not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and
 not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Content Extracted or Decompressed via Funzip
+
+Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution.
+- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut".
+- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions.
+- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages".
+- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise.
+- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections.
+
+### False positive analysis
+
+- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner.
+- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern.
+- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes.
+- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential malware.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence.
+- 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.
+- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred.
+- Restore any compromised files or systems from known good backups to ensure integrity and availability of data.
+- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_suspicious_executable_running_system_commands.toml b/rules/linux/execution_suspicious_executable_running_system_commands.toml
index 799dfcc7778..8f1506333dc 100644
--- a/rules/linux/execution_suspicious_executable_running_system_commands.toml
+++ b/rules/linux/execution_suspicious_executable_running_system_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,41 @@ process.parent.executable:(
   process.executable:(/run/containerd/* or /srv/snp/docker/* or /tmp/.criu*)
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious System Commands Executed by Previously Unknown Executable
+
+In Linux environments, system commands are essential for managing processes and configurations. Adversaries exploit this by executing commands via unknown executables in vulnerable directories, aiming to run unauthorized code. The detection rule identifies such anomalies by monitoring command executions from unfamiliar sources, excluding known safe processes, thus highlighting potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process.executable path to determine if it is located in a commonly abused directory such as /tmp, /dev/shm, or /var/tmp, which may indicate malicious intent.
+- Examine the process.args to identify which specific system command was executed (e.g., hostname, id, ifconfig) and assess whether its execution is typical for the system's normal operations.
+- Check the process.parent.executable to understand the parent process that initiated the suspicious command execution, ensuring it is not a known safe process or a legitimate system service.
+- Investigate the user account associated with the process to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that may indicate a broader compromise.
+- Assess the risk score and severity in the context of the environment to prioritize the investigation and response efforts accordingly.
+
+### False positive analysis
+
+- System maintenance scripts or automated tasks may trigger alerts if they execute common system commands from directories like /tmp or /var/tmp. To handle this, identify these scripts and add their executables to the exclusion list.
+- Custom user scripts that perform routine checks using commands like ls or ps might be flagged. Review these scripts and consider adding their paths to the known safe processes to prevent unnecessary alerts.
+- Development or testing environments often use temporary executables in directories such as /dev/shm. If these are known and non-threatening, include their paths in the exception list to reduce false positives.
+- Some monitoring tools or agents might execute commands like uptime or whoami from non-standard locations. Verify these tools and update the exclusion criteria to include their executables or parent processes.
+- In environments with containerized applications, processes running from /run/containerd or similar paths might be incorrectly flagged. Ensure these paths are accounted for in the exclusion settings if they are part of legitimate operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the alert, especially those originating from unknown executables in commonly abused directories.
+- Conduct a thorough review of the affected directories (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any unauthorized or malicious files or executables.
+- Restore any altered system configurations or files from a known good backup to ensure system integrity.
+- Implement stricter access controls and permissions on the directories identified in the alert to prevent unauthorized executable placement.
+- Monitor the system for any signs of persistence mechanisms, such as cron jobs or startup scripts, and remove any that are unauthorized.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be compromised."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml
index 98437b758b5..1c301462255 100644
--- a/rules/linux/execution_suspicious_mining_process_creation_events.toml
+++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and 
 file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Mining Process Creation Event
+
+Cryptomining exploits system resources to mine cryptocurrency, often without user consent, impacting performance and security. Adversaries may deploy mining services on Linux systems, disguising them as legitimate processes. The detection rule identifies the creation of known mining service files, signaling potential unauthorized mining activity. By monitoring these specific file creation events, security teams can swiftly respond to and mitigate cryptomining threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify which specific mining service file was created, focusing on the file names listed in the query such as "aliyun.service" or "moneroocean_miner.service".
+- Check the creation timestamp of the suspicious file to determine when the potential unauthorized mining activity began.
+- Investigate the process that created the file by examining system logs or using process monitoring tools to identify the parent process and any associated command-line arguments.
+- Analyze the system for additional indicators of compromise, such as unexpected network connections or high CPU usage, which may suggest active cryptomining.
+- Verify the legitimacy of the file by comparing it against known hashes of legitimate services or using threat intelligence sources to identify known malicious files.
+- Assess the system for any other suspicious activities or anomalies that may indicate further compromise or persistence mechanisms.
+
+### False positive analysis
+
+- Legitimate administrative scripts or services may create files with names similar to known mining services. Verify the origin and purpose of such files before taking action.
+- System administrators might deploy custom monitoring or management services that inadvertently match the file names in the detection rule. Review and whitelist these services if they are confirmed to be non-threatening.
+- Automated deployment tools or scripts could create service files as part of routine operations. Ensure these tools are properly documented and exclude them from the detection rule if they are verified as safe.
+- Some legitimate software installations might use generic service names that overlap with those flagged by the rule. Cross-check with software documentation and exclude these from alerts if they are confirmed to be benign.
+
+### Response and remediation
+
+- Isolate the affected Linux system from the network to prevent further unauthorized mining activity and potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the identified mining services, such as aliyun.service, moneroocean_miner.service, or others listed in the detection query.
+- Remove the malicious service files from the system to prevent them from being restarted or reused by the attacker.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Review and update system and application patches to close any vulnerabilities that may have been exploited to deploy the mining services.
+- Monitor network traffic for unusual outbound connections that may indicate communication with mining pools or command and control servers, and block these connections if detected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml
index fbd2b0989e1..334b24c3239 100644
--- a/rules/linux/execution_tc_bpf_filter.toml
+++ b/rules/linux/execution_tc_bpf_filter.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,40 @@ process where host.os.type == "linux" and event.type != "end" and process.execut
 process.args == "filter" and process.args == "add" and process.args == "bpf" and
 not process.parent.executable == "/usr/sbin/libvirtd"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 BPF filter applied using TC
+
+BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive.
+- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`.
+- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior.
+- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity.
+- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat.
+- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context.
+
+### False positive analysis
+
+- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule.
+- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities.
+- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule.
+- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary.
+- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application.
+- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses.
+- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist.
+- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
+- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml
index 561bf0c43b6..cc20572a207 100644
--- a/rules/linux/execution_unix_socket_communication.toml
+++ b/rules/linux/execution_unix_socket_communication.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,41 @@ process where host.os.type == "linux" and event.type == "start" and
 ) and
 not process.args == "/var/run/libvirt/libvirt-sock"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unix Socket Connection
+
+Unix sockets facilitate efficient inter-process communication (IPC) on the same host, crucial for system operations. However, adversaries can exploit them to probe applications, identify weaknesses, or establish covert channels. The detection rule identifies suspicious use of tools like netcat and socat with specific arguments, signaling potential misuse of Unix sockets for unauthorized communication or privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of netcat or socat with the specified arguments, focusing on the process name and arguments fields to verify the suspicious activity.
+- Investigate the source and destination of the Unix socket connection by examining the process.args field to determine if the connection is legitimate or potentially malicious.
+- Check the user context under which the process was executed to assess if there is any indication of privilege escalation attempts.
+- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack.
+- Examine the process lineage to understand the parent process and any child processes spawned, which might provide insights into how the suspicious process was initiated.
+- Verify if the process is part of any known legitimate application or service by cross-referencing with system documentation or application inventories.
+
+### False positive analysis
+
+- Legitimate administrative tasks using netcat or socat for system maintenance or monitoring can trigger alerts. To manage this, identify and whitelist specific scripts or commands used regularly by system administrators.
+- Automated backup or monitoring tools that use Unix sockets for communication may be flagged. Review these tools and add them to an exception list if they are verified as safe and necessary for operations.
+- Certain applications may use Unix sockets for legitimate inter-process communication, such as database services or web servers. Monitor these applications and exclude their typical behavior from the rule to prevent unnecessary alerts.
+- Development environments where developers frequently use netcat or socat for testing purposes can generate false positives. Establish a policy to differentiate between development and production environments and apply exceptions accordingly.
+- System services like libvirt, which are known to use Unix sockets, should be excluded from the rule as indicated by the exception for /var/run/libvirt/libvirt-sock. Regularly update this list to include other known benign services.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving netcat or socat with the flagged arguments.
+- Conduct a thorough review of the affected system's logs to identify any unauthorized access or data manipulation that may have occurred.
+- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack.
+- Apply patches or configuration changes to address any vulnerabilities or misconfigurations identified during the investigation.
+- Monitor the affected system and network for any signs of recurring suspicious activity, focusing on Unix socket connections.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
index 72ddcdf21c0..0894eb6a47c 100644
--- a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
+++ b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,41 @@ event.category:process and host.os.type:linux and auditd.data.syscall:mprotect a
   process.name:httpd
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unknown Execution of Binary with RWX Memory Region
+
+In Linux environments, the `mprotect()` system call is crucial for managing memory permissions, allowing processes to modify access rights of memory pages. Adversaries exploit this by granting read, write, and execute (RWX) permissions to inject and execute malicious code. The detection rule identifies suspicious RWX memory allocations by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process.executable and process.name fields to identify the binary that triggered the alert.
+- Investigate the command line arguments and parent process of the suspicious binary to understand its origin and purpose.
+- Check the process's hash against known threat intelligence databases to determine if it is associated with any known malicious activity.
+- Analyze the network activity of the process to identify any suspicious connections or data exfiltration attempts.
+- Examine the user account under which the process is running to assess if it has been compromised or is being used for unauthorized activities.
+- Review recent system logs and audit records for any other anomalies or related suspicious activities around the time of the alert.
+
+### False positive analysis
+
+- Known safe binaries like Node.js, Java, and Apache may trigger the rule due to their legitimate use of RWX memory regions. These are already excluded in the rule, but additional similar applications might need to be added to the exclusion list.
+- Custom or in-house developed applications that require RWX permissions for legitimate functionality can also cause false positives. Identify these applications and add them to the exclusion list to prevent unnecessary alerts.
+- Development environments or testing frameworks that dynamically generate and execute code might be flagged. Consider excluding these environments if they are known and trusted within your organization.
+- Security tools or monitoring software that perform memory analysis or manipulation could be mistakenly identified. Verify their behavior and exclude them if they are part of your security infrastructure.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and any new applications that are introduced.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the malicious code.
+- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity.
+- Conduct a forensic analysis of the affected system to identify the source and scope of the compromise, focusing on the unknown binary and its origin.
+- Remove any malicious binaries or scripts identified during the forensic analysis to prevent further execution.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches are applied post-restoration.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
index e227515767a..f82e1c70c48 100644
--- a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
+++ b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,41 @@ process where host.os.type == "linux" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Data Splitting Detected
+
+Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'.
+- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule.
+- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'.
+- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised.
+- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections.
+- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list.
+- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria.
+- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns.
+- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts.
+- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments.
+- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts.
+- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations.
+- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
+- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/impact_data_encrypted_via_openssl.toml b/rules/linux/impact_data_encrypted_via_openssl.toml
index 2e7a762d6bc..48107a6d53b 100644
--- a/rules/linux/impact_data_encrypted_via_openssl.toml
+++ b/rules/linux/impact_data_encrypted_via_openssl.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,40 @@ sequence by host.id, user.name, process.parent.entity_id with maxspan=5s
     /* excluding base64 encoding options and including encryption password or key params */
     not process.args in ("-d", "-a", "-A", "-base64", "-none", "-nosalt") ] with runs=10
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Data Encryption via OpenSSL Utility
+
+OpenSSL is a widely-used command-line tool for secure data encryption and decryption. Adversaries may exploit OpenSSL to encrypt files rapidly across systems, aiming to disrupt data availability or demand ransom. The detection rule identifies suspicious OpenSSL usage by monitoring rapid file encryption activities, focusing on specific command patterns and excluding benign operations, thus highlighting potential malicious behavior.
+
+### Possible investigation steps
+
+- Review the process execution details on the host identified by host.id to confirm the presence of the openssl command and its associated arguments, ensuring they match the suspicious pattern specified in the query.
+- Examine the user.name associated with the process to determine if the activity aligns with expected behavior for that user or if it indicates potential unauthorized access.
+- Investigate the parent process identified by process.parent.entity_id to understand the context in which the openssl command was executed, checking for any unusual or unexpected parent processes.
+- Check for any recent file modifications or creations on the host that coincide with the time window of the alert to assess the impact of the encryption activity.
+- Look for additional related alerts or logs from the same host or user within a similar timeframe to identify any patterns or further suspicious activities that could indicate a broader attack.
+
+### False positive analysis
+
+- Legitimate batch encryption operations by system administrators or automated scripts may trigger the rule. To handle this, identify and whitelist specific scripts or user accounts that perform regular encryption tasks.
+- Backup processes that use OpenSSL for encrypting data before storage can be mistaken for malicious activity. Exclude known backup processes by specifying their parent process names or paths.
+- Developers or security teams testing encryption functionalities might inadvertently match the rule's criteria. Create exceptions for development environments or specific user accounts involved in testing.
+- Automated data transfer services that encrypt files for secure transmission could be flagged. Identify these services and exclude their associated processes or user accounts from the rule.
+- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further spread of the encryption activity and potential lateral movement by the adversary.
+- Terminate any suspicious OpenSSL processes identified on the host to halt ongoing encryption activities.
+- Conduct a forensic analysis of the affected host to identify the scope of the encryption, including which files were encrypted and any potential data exfiltration.
+- Restore encrypted files from the most recent clean backup to ensure data availability and integrity, ensuring that the backup is free from any malicious alterations.
+- Change all credentials and keys that may have been exposed or used on the affected host to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/impact_esxi_process_kill.toml b/rules/linux/impact_esxi_process_kill.toml
index bc58c8a9c8c..3145071f6a1 100644
--- a/rules/linux/impact_esxi_process_kill.toml
+++ b/rules/linux/impact_esxi_process_kill.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,40 @@ query = '''
 process where host.os.type == "linux" and event.type == "end" and process.name in ("vmware-vmx", "vmx")
 and process.parent.name == "kill"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Termination of ESXI Process
+
+VMware ESXi is a hypervisor used to create and manage virtual machines on a host system. Adversaries may target ESXi processes like "vmware-vmx" to disrupt virtual environments, often using the "kill" command to terminate these processes. The detection rule identifies such terminations by monitoring for specific process events, helping to uncover potential threats to virtualized infrastructures.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is either "vmware-vmx" or "vmx" and that the parent process is "kill" on a Linux host.
+- Check the timeline of events leading up to the termination to identify any preceding suspicious activities or commands executed by the same user or process.
+- Investigate the user account associated with the "kill" command to determine if it is authorized to manage VMware processes and if there are any signs of compromise.
+- Examine system logs and audit trails for any unauthorized access attempts or anomalies around the time of the process termination.
+- Assess the impact on the virtual environment by verifying the status of affected virtual machines and any potential service disruptions.
+- Correlate this event with other security alerts or incidents to identify if it is part of a larger attack pattern targeting the virtual infrastructure.
+
+### False positive analysis
+
+- Routine maintenance or administrative tasks may involve terminating VMware processes using the kill command. To manage this, create exceptions for known maintenance scripts or administrative user accounts that regularly perform these actions.
+- Automated scripts or monitoring tools might inadvertently terminate VMware processes as part of their operations. Identify and exclude these tools from the detection rule by specifying their process names or user accounts.
+- System updates or patches could lead to the termination of VMware processes as part of the update procedure. Exclude these events by correlating them with known update schedules or specific update-related process names.
+- Testing environments where VMware processes are frequently started and stopped for development purposes can trigger false positives. Implement exclusions for these environments by using hostnames or IP addresses associated with test systems.
+
+### Response and remediation
+
+- Immediately isolate the affected host system from the network to prevent further malicious activity and potential spread to other systems.
+- Terminate any unauthorized or suspicious processes that are still running on the affected host, especially those related to VMware ESXi, to halt any ongoing disruption.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms that may have been deployed by the threat actor.
+- Restore any terminated VMware processes from a known good backup to ensure the virtual environment is returned to its operational state.
+- Review and update access controls and permissions on the affected host to ensure that only authorized personnel can execute critical commands like "kill" on VMware processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced monitoring and alerting for similar suspicious activities across the virtualized infrastructure to detect and respond to future threats more effectively."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/impact_memory_swap_modification.toml b/rules/linux/impact_memory_swap_modification.toml
index 7b01fd5d3c7..ab83bbb439c 100644
--- a/rules/linux/impact_memory_swap_modification.toml
+++ b/rules/linux/impact_memory_swap_modification.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,41 @@ process.name in ("swapon", "swapoff") or (
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Memory Swap Modification
+
+Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process.
+- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness.
+- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user.
+- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage.
+- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig.
+- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications.
+
+### False positive analysis
+
+- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts.
+- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts.
+- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts.
+- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities.
+- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware.
+- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness".
+- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig.
+- Review and restore swap settings to their default or secure configurations to ensure system stability and performance.
+- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly.
+- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack.
+- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/impact_potential_linux_ransomware_note_detected.toml b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
index 73956314421..8cd905eeed3 100644
--- a/rules/linux/impact_potential_linux_ransomware_note_detected.toml
+++ b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,42 @@ sequence by process.entity_id, host.id with maxspan=1s
    file.name : ("*restore*", "*lock*", "*recovery*", "*read*", "*instruction*", "*how_to*", "*ransom*")
   ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Linux Ransomware Note Creation Detected
+
+Ransomware encrypts files, demanding payment for decryption. Adversaries exploit Linux systems by executing mass file renaming and creating ransom notes. This detection rule identifies such behavior by monitoring rapid file changes and the creation of text files with ransom-related keywords, indicating potential ransomware activity. It focuses on unusual file operations in critical directories, excluding benign processes, to flag suspicious activities.
+
+### Possible investigation steps
+
+- Review the process.entity_id and host.id to identify the specific process and host involved in the alert. This will help in understanding the scope and potential impact of the activity.
+- Examine the process.executable path to determine if the executable is located in a suspicious directory such as /tmp, /var/tmp, or /dev/shm, which are commonly used by adversaries for malicious activities.
+- Analyze the file paths involved in the rename events to assess if critical directories like /home/*/Documents, /root, or /var/www are affected, indicating a higher risk of data compromise.
+- Check the process.name against the list of excluded benign processes to ensure the activity is not a false positive caused by legitimate software updates or installations.
+- Investigate the content and metadata of the created .txt files with names containing keywords like *restore*, *lock*, or *ransom* to confirm if they contain ransom notes or instructions, which would indicate a ransomware attack.
+- Correlate the timing of the file rename and creation events to verify if they occurred within the 1-second timespan, supporting the hypothesis of a rapid mass encryption event typical of ransomware behavior.
+- Assess the risk score and severity level to prioritize the response and determine if immediate containment actions are necessary to prevent further damage.
+
+### False positive analysis
+
+- Frequent software updates or installations can trigger the rule due to mass file renaming in critical directories. Exclude processes like dpkg, yum, dnf, and rpm if they are part of regular system maintenance.
+- Development activities involving compilers or interpreters such as go, java, python, and node may cause false positives. Consider excluding these processes if they are part of routine development work.
+- Automated backup or logging processes might create files with names similar to ransom notes. Exclude directories or processes associated with legitimate backup or logging activities to reduce false alerts.
+- System administration tasks using tools like ansible-galaxy or semodule can mimic ransomware behavior. Exclude these processes if they are part of scheduled or known administrative operations.
+- Web server operations in directories like /var/www/* might involve file creation and renaming. Exclude specific web server processes if they are identified as non-threatening and part of regular operations.
+
+### Response and remediation
+
+- Isolate the affected Linux system from the network immediately to prevent further spread of the ransomware and protect other systems.
+- Identify and terminate the malicious process responsible for the mass file renaming and ransom note creation using the process.entity_id and host.id from the alert.
+- Backup any unencrypted files and critical data from the affected system to a secure location to prevent data loss.
+- Conduct a forensic analysis of the affected system to determine the entry point and scope of the ransomware attack, focusing on the directories and processes identified in the alert.
+- Restore the affected system from a known good backup prior to the ransomware attack to ensure system integrity and data recovery.
+- Apply security patches and updates to the affected system and any other vulnerable systems to close any exploited vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to enhance detection capabilities for similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/lateral_movement_ssh_it_worm_download.toml b/rules/linux/lateral_movement_ssh_it_worm_download.toml
index b356618ce41..8e88a53a6af 100644
--- a/rules/linux/lateral_movement_ssh_it_worm_download.toml
+++ b/rules/linux/lateral_movement_ssh_it_worm_download.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,40 @@ process where host.os.type == "linux" and event.type == "start" and
   "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential SSH-IT SSH Worm Downloaded
+
+SSH-IT is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query.
+- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account.
+- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement.
+- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts.
+- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved.
+- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat.
+
+### False positive analysis
+
+- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators.
+- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts.
+- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise.
+- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm.
+- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm.
+- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm.
+- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA).
+- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/lateral_movement_telnet_network_activity_external.toml b/rules/linux/lateral_movement_telnet_network_activity_external.toml
index 4e1372c9e34..b155af91730 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_external.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_external.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -88,6 +88,40 @@ sequence by process.entity_id
     )
   ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Connection to External Network via Telnet
+
+Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection.
+- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services.
+- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session.
+- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection.
+- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts.
+
+### False positive analysis
+
+- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections.
+- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts.
+- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives.
+- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts.
+- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity.
+- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts.
+- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/lateral_movement_telnet_network_activity_internal.toml b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
index 2f57dba3856..cd1412d6b2b 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_internal.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -88,6 +88,41 @@ sequence by process.entity_id
     )
   ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Connection to Internal Network via Telnet
+
+Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet.
+- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt.
+- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection.
+- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt.
+- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts.
+- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat.
+
+### False positive analysis
+
+- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks.
+- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts.
+- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives.
+- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives.
+- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration.
+- Terminate any active Telnet sessions on the affected host to stop unauthorized access.
+- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed.
+- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access.
+- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation.
+- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_execution.toml b/rules/linux/persistence_apt_package_manager_execution.toml
index 89411c0d829..ccdb27615e9 100644
--- a/rules/linux/persistence_apt_package_manager_execution.toml
+++ b/rules/linux/persistence_apt_package_manager_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,41 @@ sequence by host.id with maxspan=5s
    )
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious APT Package Manager Execution
+
+The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument.
+- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands.
+- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution.
+- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited.
+- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities.
+- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution.
+
+### False positive analysis
+
+- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands.
+- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names.
+- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities.
+- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule.
+- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network.
+- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria.
+- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications.
+- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured.
+- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary.
+- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_file_creation.toml b/rules/linux/persistence_apt_package_manager_file_creation.toml
index a9d7f872d29..4585a2e22ed 100644
--- a/rules/linux/persistence_apt_package_manager_file_creation.toml
+++ b/rules/linux/persistence_apt_package_manager_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -88,6 +88,41 @@ file.path : "/etc/apt/apt.conf.d/*" and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 APT Package Manager Configuration File Creation
+
+APT is a crucial tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by inserting malicious scripts into its configuration files, ensuring persistent access. The detection rule monitors for unauthorized file creation or renaming in APT's configuration directory, excluding legitimate processes, to identify potential tampering.
+
+### Possible investigation steps
+
+- Review the file creation or renaming event details, focusing on the file path to confirm it is within the APT configuration directory (/etc/apt/apt.conf.d/).
+- Identify the process responsible for the file creation or renaming by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the query.
+- Investigate the origin and purpose of the newly created or renamed file by checking its contents for any suspicious or unauthorized scripts or configurations.
+- Correlate the event with recent system activity to determine if there are any other related alerts or anomalies, such as unusual user logins or network connections, that could indicate a broader attack.
+- Check the file's metadata, such as timestamps and ownership, to identify any discrepancies or signs of tampering that could suggest malicious activity.
+- If the process responsible for the event is unknown or suspicious, conduct a deeper analysis of the process, including its parent process, command-line arguments, and any associated network activity.
+
+### False positive analysis
+
+- Legitimate package management operations by system tools like dpkg or apt-get can trigger alerts. To manage this, ensure these processes are included in the exclusion list within the detection rule.
+- Temporary files created during package updates or installations, such as those with extensions like swp or dpkg-new, may cause false positives. Exclude these file extensions from triggering alerts.
+- Automated system maintenance scripts or tools like puppet or chef-client might modify APT configuration files as part of their normal operations. Add these processes to the exclusion list to prevent unnecessary alerts.
+- Custom scripts or administrative tasks that involve renaming or creating files in the APT configuration directory should be reviewed. If deemed safe, add these specific scripts or processes to the exclusion criteria.
+- Processes running from directories like /nix/store or /var/lib/dpkg may be part of legitimate system operations. Consider excluding these paths if they are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Conduct a thorough review of the newly created or renamed files in the /etc/apt/apt.conf.d/ directory to identify any malicious scripts or unauthorized changes.
+- Remove any identified malicious files or scripts from the APT configuration directory to eliminate the persistence mechanism.
+- Restore any legitimate configuration files from a known good backup to ensure the integrity of the APT configuration.
+- Perform a comprehensive scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or unauthorized changes.
+- 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 enhanced monitoring and logging for the APT configuration directory and related processes to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_apt_package_manager_netcon.toml b/rules/linux/persistence_apt_package_manager_netcon.toml
index 4fbac8005de..9e6715bb68f 100644
--- a/rules/linux/persistence_apt_package_manager_netcon.toml
+++ b/rules/linux/persistence_apt_package_manager_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,41 @@ sequence by host.id with maxspan=5s
    ) and not process.executable == "/usr/bin/apt-listbugs"
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious APT Package Manager Network Connection
+
+The APT package manager is crucial for managing software on Debian-based Linux systems. Adversaries may exploit APT by injecting malicious scripts, gaining persistence and control. The detection rule identifies suspicious APT-triggered shell executions followed by unusual network connections, flagging potential backdoor activities and unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the parent process is indeed 'apt' and check the command-line arguments for any unusual or unauthorized scripts being executed.
+- Investigate the network connection details, focusing on the destination IP address to determine if it is known to be malicious or associated with suspicious activity. Cross-reference with threat intelligence sources.
+- Examine the process tree to identify any child processes spawned by the suspicious shell execution, which may provide further insight into the attacker's actions or intentions.
+- Check the system logs for any other recent unusual activities or alerts that might correlate with the suspicious APT activity, such as unauthorized user logins or file modifications.
+- Assess the system for any signs of persistence mechanisms that may have been established, such as cron jobs or modified startup scripts, which could indicate a backdoor installation.
+- If possible, capture and analyze network traffic to and from the destination IP to understand the nature of the communication and identify any data exfiltration or command and control activities.
+
+### False positive analysis
+
+- Legitimate administrative scripts executed by APT may trigger the rule if they involve shell commands followed by network connections. Users can create exceptions for known scripts by specifying their paths or hashes.
+- Automated system updates or package installations that involve network connections might be flagged. Users should monitor and whitelist these routine operations by identifying the specific processes and network destinations involved.
+- Network connections to internal or trusted IP addresses not covered by the existing CIDR exclusions could be mistakenly flagged. Users can expand the CIDR list to include additional trusted IP ranges specific to their environment.
+- Use of alternative shell environments or custom scripts that invoke APT with network operations may cause false positives. Users should document and exclude these specific use cases by process name or command-line arguments.
+- Non-standard APT configurations or third-party tools that interact with APT and initiate network connections might be misidentified. Users should review and whitelist these tools by their executable paths or process names.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further unauthorized network connections and potential lateral movement within the network.
+- Terminate any suspicious processes identified as being executed by the APT package manager, especially those involving shell executions.
+- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications.
+- Revert any unauthorized changes to the system or software packages by restoring from a known good backup, ensuring the integrity of the system.
+- Update all system packages and apply security patches to close any vulnerabilities that may have been exploited by the attacker.
+- Monitor network traffic for any further suspicious connections or activities originating from the affected host, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised, ensuring a comprehensive response."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_at_job_creation.toml b/rules/linux/persistence_at_job_creation.toml
index cebef39e692..1989bb05cc7 100644
--- a/rules/linux/persistence_at_job_creation.toml
+++ b/rules/linux/persistence_at_job_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,41 @@ event.action in ("rename", "creation") and file.path : "/var/spool/cron/atjobs/*
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 At Job Created or Modified
+
+The 'at' command in Linux schedules tasks for future execution, aiding system admins in automating routine jobs. However, attackers can exploit this for persistence, privilege escalation, or executing unauthorized commands. The detection rule identifies suspicious 'at' job creations or modifications by monitoring specific file paths and excluding benign processes, helping to flag potential malicious activities.
+
+### Possible investigation steps
+
+- Review the file path of the created or modified 'at' job to confirm it is within the monitored directory: /var/spool/cron/atjobs/*. Determine if the file path is expected or unusual for the system's typical operations.
+- Identify the process that triggered the alert by examining the process.executable field. Check if the process is known and expected in the context of the system's normal operations.
+- Investigate the user account associated with the process that created or modified the 'at' job. Determine if the account has legitimate reasons to schedule tasks or if it might be compromised.
+- Check the contents of the 'at' job file to understand the commands or scripts scheduled for execution. Look for any suspicious or unauthorized commands that could indicate malicious intent.
+- Correlate the event with other recent alerts or logs from the same host to identify any patterns or additional indicators of compromise, such as privilege escalation attempts or unauthorized access.
+- Verify if there are any known vulnerabilities or exploits associated with the processes or commands involved in the alert, which could provide further context on the potential threat.
+
+### False positive analysis
+
+- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify at jobs during software installations or updates. To manage this, ensure these processes are included in the exclusion list within the detection rule.
+- Automated system management tools such as Puppet and Chef may also create or modify at jobs as part of their routine operations. Add these tools to the exclusion list to prevent unnecessary alerts.
+- Temporary files with extensions like swp or dpkg-remove can be mistakenly flagged. Exclude these file extensions from the rule to reduce false positives.
+- Processes running from directories like /nix/store or /snap can be benign and should be considered for exclusion if they are part of regular system operations.
+- If the process executable is null, it might indicate a benign system process that lacks a defined executable path. Consider reviewing these cases to determine if they are legitimate and adjust the rule accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks.
+- Terminate any suspicious processes associated with the creation or modification of 'at' jobs that are not part of the excluded benign processes.
+- Review and remove any unauthorized 'at' jobs found in the /var/spool/cron/atjobs/ directory to eliminate persistence mechanisms.
+- Conduct a thorough examination of the system for additional indicators of compromise, such as unauthorized user accounts or unexpected network connections.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for 'at' job activities to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
index 8ebf2a224c5..880d9d8a8bc 100644
--- a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -88,6 +88,42 @@ file.path : ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 DNF Package Manager Plugin File Creation
+
+DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities.
+
+### Possible investigation steps
+
+- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*".
+- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria.
+- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx".
+- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior.
+- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates.
+- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise.
+- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule.
+- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list.
+- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria.
+- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives.
+- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes.
+- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager.
+- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots.
+- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker.
+- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
index b55731cca6e..72a34f4a85d 100644
--- a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,41 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:dpkg and
 process.args:("-i" or "--install")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 DPKG Package Installed by Unusual Parent Process
+
+DPKG is a core utility for managing Debian packages on Linux systems, crucial for software installation and maintenance. Adversaries may exploit DPKG to install malicious packages, leveraging unusual parent processes to evade detection. The detection rule identifies such anomalies by monitoring DPKG executions initiated by atypical parent processes, signaling potential unauthorized package installations.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent process of the dpkg execution. Determine if the parent process is legitimate or unusual for package installations.
+- Examine the command-line arguments used with the dpkg command, specifically looking for the "-i" or "--install" flags, to understand what package was being installed.
+- Check the source and integrity of the package being installed to ensure it is from a trusted repository or source.
+- Investigate the user account under which the dpkg command was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Correlate the event with other logs or alerts around the same timeframe to identify any related suspicious activities or patterns.
+- Assess the system for any signs of compromise or unauthorized changes following the package installation.
+
+### False positive analysis
+
+- System updates or maintenance scripts may trigger the rule when legitimate administrative tools or scripts use dpkg to install updates. To handle this, identify and whitelist known maintenance scripts or processes that regularly perform package installations.
+- Automated deployment tools like Ansible or Puppet might use dpkg for software deployment, leading to false positives. Exclude these tools by adding their process names to an exception list if they are part of your standard operations.
+- Custom internal applications or scripts that manage software installations could also cause alerts. Review these applications and, if verified as safe, configure exceptions for their parent processes.
+- Developers or system administrators using dpkg for testing or development purposes might inadvertently trigger the rule. Establish a policy for such activities and exclude known development environments or user accounts from triggering alerts.
+- Backup or recovery operations that reinstall packages as part of their process can be mistaken for malicious activity. Identify these operations and exclude their associated processes from the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized package installations or lateral movement by the adversary.
+- Terminate the dpkg process if it is still running to stop any ongoing malicious package installation.
+- Identify and remove any suspicious or unauthorized packages installed by the dpkg command using the package management tools available on the system.
+- Conduct a thorough review of the system's package installation logs and history to identify any other potentially malicious packages or unusual installation activities.
+- Restore the system from a known good backup if malicious packages have altered critical system components or configurations.
+- Implement stricter access controls and monitoring on systems to prevent unauthorized use of package management utilities by non-administrative users or processes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring a coordinated response to the threat."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_dpkg_unusual_execution.toml b/rules/linux/persistence_dpkg_unusual_execution.toml
index 63beaf41029..9a96c8bd1b7 100644
--- a/rules/linux/persistence_dpkg_unusual_execution.toml
+++ b/rules/linux/persistence_dpkg_unusual_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,39 @@ process.group_leader.name != null and not (
   process.parent.executable in ("/usr/share/debconf/frontend", "/usr/bin/unattended-upgrade")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual DPKG Execution
+
+DPKG is a core utility in Debian-based Linux systems for managing software packages. While essential for legitimate software management, adversaries can exploit DPKG to install or manipulate packages for malicious purposes, potentially gaining persistence or executing unauthorized code. The detection rule identifies anomalies by flagging DPKG executions initiated by unexpected processes, which may indicate unauthorized package management activities.
+
+### Possible investigation steps
+
+- Review the process details to identify the unexpected process that initiated the DPKG execution. Pay attention to the process.executable field to understand which script or binary was executed.
+- Examine the process.parent.name and process.parent.executable fields to determine the parent process that launched the DPKG command. This can provide insights into whether the execution was part of a legitimate process chain or potentially malicious.
+- Investigate the process.session_leader.name and process.group_leader.name fields to understand the broader context of the session and group leaders involved in the execution. This can help identify if the execution was part of a larger, coordinated activity.
+- Check the system logs and any available audit logs around the time of the alert to gather additional context on the activities occurring on the system. Look for any other suspicious or related events.
+- Assess the system for any unauthorized or unexpected package installations or modifications that may have occurred as a result of the DPKG execution. This can help determine if the system has been compromised.
+
+### False positive analysis
+
+- System maintenance scripts may trigger the rule if they execute DPKG commands outside of typical package management processes. To handle this, identify and whitelist these scripts by adding their parent process names or executables to the exception list.
+- Automated software update tools, other than the ones specified in the rule, might cause false positives. Review the tools used in your environment and consider adding their executables to the exclusion criteria if they are verified as safe.
+- Custom administrative scripts that manage packages could be flagged. Ensure these scripts are reviewed for legitimacy and then exclude their process names or paths from the rule to prevent unnecessary alerts.
+- Development or testing environments where package manipulation is frequent might generate alerts. In such cases, consider creating environment-specific exceptions to reduce noise while maintaining security in production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized package installations or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as executing the DPKG command from unexpected sources to halt any ongoing malicious activities.
+- Conduct a thorough review of recently installed or modified packages on the affected system to identify and remove any unauthorized or malicious software.
+- Restore the system from a known good backup if malicious packages have been installed and cannot be safely removed without compromising system integrity.
+- Update and patch the affected system to ensure all software is up-to-date, reducing the risk of exploitation through known vulnerabilities.
+- Implement stricter access controls and monitoring on package management utilities to prevent unauthorized use, ensuring only trusted processes can execute DPKG commands.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_git_hook_execution.toml b/rules/linux/persistence_git_hook_execution.toml
index 02a845525d1..19784470d1a 100644
--- a/rules/linux/persistence_git_hook_execution.toml
+++ b/rules/linux/persistence_git_hook_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,41 @@ sequence by host.id with maxspan=3s
   [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Git Hook Command Execution
+
+Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields.
+- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated.
+- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise.
+- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command.
+- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise.
+- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms.
+
+### False positive analysis
+
+- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes.
+- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious.
+- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them.
+- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions.
+- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.
+- Restore any modified or deleted files from a known good backup to ensure system integrity.
+- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_git_hook_file_creation.toml b/rules/linux/persistence_git_hook_file_creation.toml
index 240262b8807..8a11a5b3597 100644
--- a/rules/linux/persistence_git_hook_file_creation.toml
+++ b/rules/linux/persistence_git_hook_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -84,6 +84,41 @@ file.extension == null and process.executable != null and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Git Hook Created or Modified
+
+Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system.
+- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query.
+- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook.
+- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes.
+- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule.
+- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts.
+- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria.
+- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts.
+- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code.
+- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule.
+- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes.
+- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms.
+- Implement file integrity monitoring on the .git/hooks directory to detect unauthorized changes in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Review and update access controls and permissions for Git repositories to limit the ability to modify hook scripts to only trusted users."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_git_hook_netcon.toml b/rules/linux/persistence_git_hook_netcon.toml
index 9e7e71207fd..f74e5ac390b 100644
--- a/rules/linux/persistence_git_hook_netcon.toml
+++ b/rules/linux/persistence_git_hook_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,42 @@ sequence by host.id with maxspan=3s
    )
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Git Hook Egress Network Connection
+
+Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries can exploit these hooks to execute unauthorized commands, maintain persistence, or initiate network connections for data exfiltration. The detection rule identifies suspicious network activities by monitoring script executions from Git hooks and subsequent egress connections to non-local IPs, flagging potential misuse.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the specific Git hook script that triggered the alert. Check the process.args field for the exact script path within the .git/hooks directory.
+- Investigate the parent process details to confirm the legitimacy of the Git operation. Verify the process.parent.name is "git" and assess whether the Git activity aligns with expected user or system behavior.
+- Analyze the destination IP address involved in the network connection attempt. Use the destination.ip field to determine if the IP is known, trusted, or associated with any malicious activity.
+- Check for any additional network connections from the same host around the time of the alert to identify potential patterns or additional suspicious activity.
+- Correlate the alert with any recent changes in the repository or system that might explain the execution of the Git hook, such as recent commits or updates.
+- Review user activity logs to determine if the Git operation was performed by an authorized user and if their actions align with their typical behavior.
+- If suspicious activity is confirmed, isolate the affected system to prevent further unauthorized access or data exfiltration and initiate a deeper forensic analysis.
+
+### False positive analysis
+
+- Legitimate automated scripts or CI/CD pipelines may trigger Git hooks to perform network operations. Review the source and purpose of these scripts and consider excluding them if they are verified as non-threatening.
+- Development environments often use Git hooks for tasks like fetching dependencies or updating remote services. Identify these common operations and create exceptions for known safe IP addresses or domains.
+- Internal tools or services that rely on Git hooks for communication with other internal systems might be flagged. Ensure these tools are documented and whitelist their network activities if they are deemed secure.
+- Frequent updates or deployments that involve Git hooks could lead to repeated alerts. Monitor the frequency and context of these alerts to determine if they are part of regular operations and adjust the rule to reduce noise.
+- Consider the context of the network connection, such as the destination IP or domain. If the destination is a known and trusted entity, it may be appropriate to exclude it from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized egress connections and potential data exfiltration.
+- Terminate any suspicious processes identified as originating from Git hooks, particularly those executing shell scripts like bash, dash, or zsh.
+- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.
+- Reset credentials and access tokens associated with the affected Git repository to prevent further unauthorized access.
+- Restore any modified or deleted files from a known good backup to ensure system integrity.
+- Implement network monitoring to detect and block any future unauthorized egress connections from Git hooks or similar scripts.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems or repositories."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_git_hook_process_execution.toml b/rules/linux/persistence_git_hook_process_execution.toml
index ca62a6fc067..21f2c8c1fd1 100644
--- a/rules/linux/persistence_git_hook_process_execution.toml
+++ b/rules/linux/persistence_git_hook_process_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,41 @@ process where host.os.type == "linux" and event.type == "start" and
   ) and
   not process.name in ("git", "dirname")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Git Hook Child Process
+
+Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process.
+- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed.
+- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful.
+- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner.
+- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise.
+- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks.
+
+### False positive analysis
+
+- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers.
+- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows.
+- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening.
+- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities.
+- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
+- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables.
+- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts.
+- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations.
+- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks.
+- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_driver_load.toml b/rules/linux/persistence_kernel_driver_load.toml
index 97ba74fa43d..aa11744f286 100644
--- a/rules/linux/persistence_kernel_driver_load.toml
+++ b/rules/linux/persistence_kernel_driver_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,41 @@ query = '''
 driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and
 auditd.data.syscall in ("init_module", "finit_module")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kernel Driver Load
+
+Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers and other components. Adversaries exploit this by loading malicious modules, or rootkits, to gain stealthy control over systems. The 'Kernel Driver Load' detection rule leverages auditd to monitor system calls like `init_module`, identifying unauthorized module loads indicative of potential rootkit activity, thus enhancing threat detection and system integrity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host where the kernel module was loaded, focusing on the host.os.type field to confirm it is a Linux system.
+- Examine the event.action field to verify that the action was indeed "loaded-kernel-module" and check the auditd.data.syscall field for the specific system call used, either "init_module" or "finit_module".
+- Investigate the timeline of events on the affected host around the time of the alert to identify any suspicious activities or changes, such as new user accounts, unexpected network connections, or file modifications.
+- Check the system logs and audit logs on the affected host for any additional context or anomalies that coincide with the module load event.
+- Identify the source and legitimacy of the loaded kernel module by examining the module's file path, signature, and associated metadata, if available.
+- Assess the potential impact and scope of the incident by determining if similar alerts have been triggered on other hosts within the environment, indicating a broader campaign or attack.
+
+### False positive analysis
+
+- Legitimate kernel module updates or installations can trigger alerts. Regularly scheduled updates or installations by trusted administrators should be documented and excluded from monitoring to reduce noise.
+- System utilities that load kernel modules as part of their normal operation may cause false positives. Identify these utilities and create exceptions for their expected behavior.
+- Automated configuration management tools that deploy or update kernel modules can generate alerts. Ensure these tools are recognized and their activities are whitelisted.
+- Development environments where kernel modules are frequently compiled and tested may lead to frequent alerts. Exclude specific development hosts or processes from monitoring to avoid unnecessary alerts.
+- Security software that loads kernel modules for protection purposes might be flagged. Verify and exclude these modules if they are from trusted vendors.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement.
+- Verify the legitimacy of the loaded kernel module by checking its source and integrity. If the module is unauthorized or suspicious, unload it using appropriate system commands.
+- Conduct a thorough scan of the system using updated antivirus or anti-malware tools to identify and remove any additional malicious components or rootkits.
+- Review and analyze system logs, especially those related to auditd, to identify any unauthorized access or changes made by the adversary. This can help in understanding the scope of the compromise.
+- Restore the system from a known good backup if the integrity of the system is in question and if the malicious activity cannot be fully remediated.
+- Implement stricter access controls and monitoring on kernel module loading activities to prevent unauthorized actions in the future. This may include restricting module loading to trusted users or processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_driver_load_by_non_root.toml b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
index 216b6be53ed..dc31b699233 100644
--- a/rules/linux/persistence_kernel_driver_load_by_non_root.toml
+++ b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ query = '''
 driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and
 auditd.data.syscall in ("init_module", "finit_module") and user.id != "0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kernel Driver Load by non-root User
+
+Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers or features. Typically, only root users can load these modules due to their potential to alter system behavior. Adversaries may exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies non-root users attempting to load modules, signaling potential unauthorized activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the non-root user (user.id) involved in the kernel module loading attempt.
+- Check the system logs and audit logs for any additional context around the time of the event, focusing on the specific system calls (init_module, finit_module) used.
+- Investigate the source and legitimacy of the kernel module being loaded by examining the module's file path and associated metadata.
+- Assess the user's recent activity and permissions to determine if there are any signs of privilege escalation or unauthorized access.
+- Correlate this event with other security alerts or anomalies on the same host to identify potential patterns of malicious behavior.
+- Verify the integrity and security posture of the affected system by running a comprehensive malware and rootkit scan.
+
+### False positive analysis
+
+- Legitimate software or system utilities may occasionally load kernel modules as part of their normal operation. Identify these applications and verify their behavior to ensure they are not malicious.
+- Development environments or testing scenarios might involve non-root users loading kernel modules for legitimate purposes. Consider creating exceptions for these specific users or processes after thorough validation.
+- Some system management tools or scripts executed by non-root users might trigger this rule. Review these tools and, if deemed safe, add them to an exception list to prevent unnecessary alerts.
+- In environments where non-root users are granted specific permissions to load kernel modules, ensure these permissions are documented and monitored. Adjust the rule to exclude these known and authorized activities.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the integrity of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the non-root user attempting to load the kernel module to halt any ongoing malicious activity.
+- Conduct a thorough review of the loaded kernel modules on the affected system to identify and remove any unauthorized or malicious modules.
+- Reset credentials and review permissions for the non-root user involved in the alert to prevent further unauthorized actions.
+- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any additional affected systems.
+- Implement enhanced monitoring and logging for kernel module loading activities across all systems to detect similar threats in the future.
+- Review and update security policies to ensure that only authorized users have the necessary permissions to load kernel modules, reducing the risk of unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_kernel_object_file_creation.toml b/rules/linux/persistence_kernel_object_file_creation.toml
index 4d95f4e8f37..495da198dd3 100644
--- a/rules/linux/persistence_kernel_object_file_creation.toml
+++ b/rules/linux/persistence_kernel_object_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,41 @@ event.category:file and host.os.type:linux and event.type:creation and file.exte
   file.path:/var/tmp/mkinitramfs_* or process.executable:/snap/* or process.name:cpio
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kernel Object File Creation
+
+Kernel object files (.ko) are loadable modules that extend the functionality of the Linux kernel, often used for adding drivers or system features. Adversaries exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies suspicious .ko file creation, excluding benign paths, to flag potential threats while minimizing false positives.
+
+### Possible investigation steps
+
+- Review the file path of the created .ko file to determine if it is located in a suspicious or unusual directory that is not excluded by the rule, such as /var/tmp or /usr/local.
+- Examine the process that created the .ko file by checking the process.executable and process.name fields to identify if it is a known legitimate process or potentially malicious.
+- Investigate the parent process of the process that created the .ko file to understand the context of how the file was created and if it was initiated by a legitimate user action or a script.
+- Check for any recent system changes or anomalies around the time of the .ko file creation, such as new user accounts, changes in system configurations, or other suspicious file activities.
+- Look for any associated network activity from the host around the time of the .ko file creation to identify potential command and control communications or data exfiltration attempts.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.
+
+### False positive analysis
+
+- Kernel updates and system maintenance activities can generate .ko files in legitimate scenarios. Users should monitor for these activities and consider excluding paths related to official update processes.
+- Custom kernel module development by developers or system administrators may trigger this rule. Establish a process to whitelist known development environments or specific user accounts involved in module creation.
+- Automated system recovery tools, such as those using mkinitramfs, may create .ko files. Ensure these paths are excluded as indicated in the rule to prevent unnecessary alerts.
+- Snap package installations might involve .ko file creation. Exclude the /snap/ directory to avoid false positives from legitimate package installations.
+- Backup and restoration processes using tools like cpio can lead to .ko file creation. Verify these processes and exclude them if they are part of routine system operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes associated with the creation of the .ko file, especially those not originating from known benign paths.
+- Remove the suspicious .ko file from the system to prevent it from being loaded into the kernel.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components.
+- Review system logs and audit trails to identify any unauthorized access or changes made around the time of the .ko file creation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring and alerting for similar activities, ensuring that any future attempts to create or load unauthorized .ko files are promptly detected and addressed."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_lkm_configuration_file_creation.toml b/rules/linux/persistence_lkm_configuration_file_creation.toml
index ba7808de531..b1ca34adf35 100644
--- a/rules/linux/persistence_lkm_configuration_file_creation.toml
+++ b/rules/linux/persistence_lkm_configuration_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,42 @@ file.path like~ (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Loadable Kernel Module Configuration File Creation
+
+Loadable Kernel Modules (LKMs) are components that can be dynamically loaded into the Linux kernel to extend its functionality without rebooting. Adversaries exploit this by creating or altering LKM configuration files to ensure their malicious modules load at startup, achieving persistence. The detection rule identifies suspicious file creation or renaming activities in key directories, excluding benign processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the file path and name to determine if it matches any known or expected LKM configuration files, focusing on paths like /etc/modules, /etc/modprobe.d/*, and others specified in the query.
+- Examine the process executable responsible for the file creation or renaming to identify if it is a known or trusted application, especially if it is not in the list of excluded executables.
+- Check the process name and executable path for any anomalies or signs of masquerading, particularly if they are not in the list of excluded names or paths.
+- Investigate the user account associated with the process to determine if it has legitimate access or if it might be compromised.
+- Correlate the event with other recent system activities to identify any patterns or additional suspicious behavior, such as other file modifications or network connections.
+- Review system logs for any related entries that might provide additional context or evidence of malicious activity.
+- Assess the risk and impact of the detected activity on the system's security posture and determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- System package managers like dpkg, rpm, and yum may trigger false positives when they update or install legitimate kernel modules. To handle this, exclude these processes by adding them to the exception list in the detection rule.
+- Automated system management tools such as Puppet, Chef, and Ansible can create or modify LKM configuration files during routine operations. Exclude these processes by specifying their executables in the exception criteria.
+- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for suspicious activity. Exclude these file extensions to reduce false positives.
+- Processes running from specific directories like /nix/store or /snap may be part of legitimate software installations. Add these paths to the exclusion list to prevent unnecessary alerts.
+- Scheduled tasks or cron jobs that involve file operations in the monitored directories might be flagged. Identify and exclude these processes by their names or paths to minimize false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further propagation of the malicious loadable kernel module.
+- Terminate any suspicious processes identified in the alert that are associated with the creation or modification of LKM configuration files.
+- Remove or revert any unauthorized changes to LKM configuration files in the specified directories to prevent the malicious module from loading on reboot.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components.
+- Review system logs and the history of executed commands to identify the initial vector of compromise and any other affected systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement additional monitoring and alerting for similar suspicious activities to enhance detection and response capabilities for future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation.toml b/rules/linux/persistence_pluggable_authentication_module_creation.toml
index fd3e0bb6fd6..6e3b3b33a1a 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,41 @@ process.executable != null and (
   (process.name == "perl" and file.name like~ "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation or Modification of Pluggable Authentication Module or Configuration
+
+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."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
index be09d78657f..8490fb0ed03 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,41 @@ file where host.os.type == "linux" and event.type == "creation" and file.name li
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 (PAM) Creation in Unusual Directory
+
+Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the file creation event details, focusing on the file path and name to determine the exact location and nature of the PAM shared object file created.
+- Investigate the process that created the file by examining the process name and its parent process to understand the context and legitimacy of the file creation.
+- Check the user account associated with the process that created the file to assess if it has the necessary permissions and if the activity aligns with typical user behavior.
+- Analyze recent system logs and command history for any suspicious activities or commands that might indicate an attempt to compile or move PAM modules.
+- Correlate the event with other security alerts or anomalies on the system to identify potential patterns or coordinated actions that could indicate a broader compromise.
+- If possible, retrieve and analyze the contents of the PAM shared object file to identify any malicious code or indicators of compromise.
+
+### False positive analysis
+
+- Development and testing environments may compile PAM modules in temporary directories. To manage this, exclude paths commonly used for development, such as "/tmp/dev/*" or "/var/tmp/test/*".
+- Containerized applications might create PAM modules in non-standard directories. Exclude processes like "dockerd" and "containerd" to prevent false positives from container operations.
+- Package managers or system update tools may temporarily store PAM modules in unusual directories during updates. Exclude paths like "/var/cache/pacman/pkg/*" or "/var/lib/dpkg/tmp.ci/*" to avoid alerts during legitimate system updates.
+- Custom scripts or automation tools might generate PAM modules in user-specific directories. Identify and exclude these specific scripts or paths if they are known to be safe and necessary for operations.
+- Temporary backup or recovery operations might involve copying PAM modules to non-standard locations. Exclude paths used for backups, such as "/backup/*" or "/recovery/*", if these operations are verified as secure.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Conduct a thorough review of the unusual directory where the PAM file was created to identify any other suspicious files or activities, and remove any malicious files found.
+- Analyze the process that created the PAM file to determine if it was initiated by a legitimate user or process, and terminate any malicious processes.
+- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges or access to sensitive systems.
+- Restore the affected system from a known good backup to ensure that no malicious modifications persist.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create PAM files in unusual directories.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_pluggable_authentication_module_source_download.toml b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
index c80244fef6e..afd726f6743 100644
--- a/rules/linux/persistence_pluggable_authentication_module_source_download.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name in ("curl", "wget") and
 process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 (PAM) Source Download
+
+Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by downloading its source code to insert backdoors, compromising authentication. The detection rule identifies suspicious downloads of PAM source files using tools like `curl` or `wget`, flagging potential threats to system integrity and user credentials.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of `curl` or `wget` for downloading the PAM source file, focusing on the `process.name` and `process.args` fields to verify the URL pattern matches the suspicious download.
+- Check the user account associated with the process execution to determine if the activity was initiated by a legitimate user or a potential adversary.
+- Investigate the system's command history and logs to identify any preceding or subsequent commands that might indicate further malicious activity or attempts to compile and install the downloaded PAM source.
+- Examine network logs for any unusual outbound connections or data exfiltration attempts following the download, which could suggest further compromise.
+- Assess the integrity of existing PAM modules on the system to ensure no unauthorized modifications or backdoors have been introduced.
+- Correlate this event with other alerts or anomalies on the same host to identify patterns or a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate system administrators or developers may download PAM source files for testing or development purposes. To handle this, create exceptions for known user accounts or IP addresses that regularly perform such downloads.
+- Automated scripts or configuration management tools might use `curl` or `wget` to download PAM source files as part of routine updates or system setups. Identify these scripts and whitelist their activities to prevent false positives.
+- Security researchers or auditors may download PAM source files to conduct security assessments. Establish a process to verify and approve these activities, allowing exceptions for recognized research teams or individuals.
+- Educational institutions or training environments might download PAM source files for instructional purposes. Implement a policy to exclude these environments from triggering alerts, ensuring they are recognized as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active `curl` or `wget` processes identified in the alert to stop the download of potentially malicious PAM source files.
+- Conduct a thorough review of PAM configuration files and shared object files on the affected system to identify and remove any unauthorized modifications or backdoors.
+- Restore the affected system from a known good backup if unauthorized changes to PAM files are detected and cannot be easily reversed.
+- Implement stricter access controls and monitoring on systems handling PAM configurations to prevent unauthorized downloads or modifications in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.
+- Update detection mechanisms to monitor for similar download attempts and unauthorized modifications to critical authentication components."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
index 20152cf97b1..9281e909bcd 100644
--- a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
+++ b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,40 @@ process.args : (
   (process.name == "install" and process.args : "-m*" and process.args : ("7*", "5*", "3*", "1*"))
 ) and not process.parent.executable : "/var/lib/dpkg/*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Executable Bit Set for Potential Persistence Script
+
+In Linux environments, scripts with executable permissions can be used to automate tasks, including system start-up processes. Adversaries exploit this by setting executable bits on scripts in directories typically used for persistence, allowing malicious code to run automatically. The detection rule identifies such activities by monitoring for changes in executable permissions in these directories, signaling potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific script or file that had its executable bit set, focusing on the process.args field to determine the exact file path.
+- Examine the process.parent.executable field to understand the parent process that initiated the permission change, which can provide context on whether the action was part of a legitimate process or potentially malicious activity.
+- Check the user account associated with the process to determine if the action was performed by a legitimate user or a compromised account.
+- Investigate the history of the file in question, including recent modifications and the creation date, to assess if it aligns with known system changes or updates.
+- Analyze the contents of the script or file to identify any suspicious or unauthorized code that could indicate malicious intent.
+- Correlate this event with other recent alerts or logs from the same host to identify patterns or additional indicators of compromise that may suggest a broader persistence mechanism.
+
+### False positive analysis
+
+- System administrators or automated scripts may legitimately change executable permissions in directories like /etc/init.d or /etc/cron* for maintenance or updates. To handle these, create exceptions for known administrative scripts or processes that regularly perform these actions.
+- Software installations or updates might trigger this rule when they modify startup scripts or configuration files. Users can mitigate this by excluding processes originating from trusted package managers or installation paths, such as /var/lib/dpkg.
+- Custom user scripts in home directories, especially in /home/*/.config/autostart, may be flagged if users set them to run at startup. To reduce false positives, maintain a whitelist of user scripts that are known and approved for startup execution.
+- Security tools or monitoring solutions might adjust permissions as part of their operations. Identify these tools and exclude their processes from triggering the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are associated with unauthorized script execution.
+- Remove or disable the executable permissions on the identified scripts to prevent further unauthorized execution.
+- Conduct a thorough review of the affected directories to identify and remove any additional unauthorized scripts or files.
+- Restore any modified system files or configurations from a known good backup to ensure system integrity.
+- Monitor the system for any signs of re-infection or further unauthorized changes, focusing on the directories and processes highlighted in the alert.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_process_capability_set_via_setcap.toml b/rules/linux/persistence_process_capability_set_via_setcap.toml
index b7312ca0f94..3b4231f225d 100644
--- a/rules/linux/persistence_process_capability_set_via_setcap.toml
+++ b/rules/linux/persistence_process_capability_set_via_setcap.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,39 @@ process.name == "setcap" and not (
   process.parent.name in ("jem", "vzctl")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Capability Set via setcap Utility
+
+The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit this to maintain persistence or escalate privileges by misconfiguring capabilities. The detection rule identifies suspicious `setcap` usage by monitoring process execution patterns, excluding benign parent processes, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the setcap utility, focusing on the process name and event action fields to ensure the alert is not a false positive.
+- Investigate the parent process executable and name to determine if the setcap command was executed by a potentially malicious or unexpected process, especially if it is not among the excluded benign parent processes.
+- Check the capabilities that were set by the setcap command to assess if they could allow privilege escalation or persistence, and determine if they align with normal operational requirements.
+- Examine the timeline of events around the setcap execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that could suggest a coordinated attack.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule when package managers like dpkg or Docker set capabilities during their processes. To handle this, exclude paths such as /var/lib/dpkg/* and /var/lib/docker/* from the detection rule.
+- Development environments or containerized applications might use setcap for testing purposes. Exclude processes originating from /tmp/newroot/* and /var/tmp/newroot/* to reduce noise from these environments.
+- Custom scripts or administrative tools that use setcap for legitimate configuration tasks can be excluded by identifying their parent process names and adding them to the exclusion list, similar to the existing exclusions for jem and vzctl.
+- Regular audits of the exclusion list should be conducted to ensure that no malicious processes are inadvertently whitelisted, maintaining a balance between reducing false positives and ensuring security.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Terminate any suspicious processes associated with the `setcap` utility that are not part of legitimate administrative tasks.
+- Review and remove any unnecessary capabilities set on executables using the `setcap` utility to prevent privilege escalation.
+- Conduct a thorough audit of the system to identify any backdoors or unauthorized changes made by the attacker, and remove them.
+- Restore affected systems from a known good backup if unauthorized changes or persistent threats are detected.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and logging for `setcap` usage and similar privilege escalation attempts to improve future detection capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_rc_local_error_via_syslog.toml b/rules/linux/persistence_rc_local_error_via_syslog.toml
index 6a62b00b786..e85ddb3e683 100644
--- a/rules/linux/persistence_rc_local_error_via_syslog.toml
+++ b/rules/linux/persistence_rc_local_error_via_syslog.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,39 @@ query = '''
 host.os.type:linux and event.dataset:system.syslog and process.name:rc.local and
 message:("Connection refused" or "No such file or directory" or "command not found")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious rc.local Error Message
+
+The rc.local script is crucial in Linux systems, executing commands at boot. Adversaries may exploit this by inserting malicious scripts to gain persistence. The detection rule monitors syslog for specific error messages linked to rc.local, such as "Connection refused," indicating potential tampering. This proactive monitoring helps identify unauthorized modifications, mitigating persistent threats.
+
+### Possible investigation steps
+
+- Review the syslog entries for the specific error messages "Connection refused," "No such file or directory," or "command not found" associated with the rc.local process to understand the context and frequency of these errors.
+- Check the rc.local file for any recent modifications or unusual entries that could indicate tampering or unauthorized changes.
+- Investigate the source of the error messages by identifying any related processes or network connections that might have triggered the "Connection refused" error.
+- Examine the system's boot logs and startup scripts to identify any anomalies or unauthorized scripts that may have been introduced.
+- Cross-reference the timestamps of the error messages with other system logs to identify any correlated suspicious activities or changes in the system.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify the rc.local file, triggering error messages. Users can create exceptions for known update processes by identifying the specific software and excluding its related syslog entries.
+- Custom scripts or administrative tasks that intentionally modify rc.local for legitimate purposes might cause false alerts. Document these scripts and add them to an exclusion list to prevent unnecessary alerts.
+- Network configuration changes can lead to temporary "Connection refused" errors. If these changes are expected, users should temporarily adjust the monitoring rule to ignore these specific messages during the maintenance window.
+- System misconfigurations or missing dependencies might result in "No such file or directory" or "command not found" errors. Regularly audit system configurations and ensure all necessary files and commands are correctly installed to minimize these false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
+- Review the rc.local file for unauthorized modifications and restore it from a known good backup if tampering is confirmed.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software.
+- Check for additional persistence mechanisms by reviewing other boot or logon initialization scripts and scheduled tasks.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems are affected.
+- Implement enhanced monitoring on the affected system and similar systems to detect any future unauthorized changes to boot scripts.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system files like rc.local."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_rc_local_service_already_running.toml b/rules/linux/persistence_rc_local_service_already_running.toml
index 0027fc21226..54ee65cd6ff 100644
--- a/rules/linux/persistence_rc_local_service_already_running.toml
+++ b/rules/linux/persistence_rc_local_service_already_running.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,39 @@ query = '''
 process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and 
 process.parent.args == "/etc/rc.local" and process.parent.args == "start"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Execution of rc.local Script
+
+The `/etc/rc.local` script is a legacy Linux initialization script executed at the end of the boot process. While not enabled by default, attackers can exploit it to persistently run malicious commands upon system reboot. The detection rule identifies potential misuse by monitoring for the `already_running` event action linked to `rc-local.service`, indicating the script's execution, thus alerting to possible persistence tactics.
+
+### Possible investigation steps
+
+- Review the system logs to identify any recent changes or modifications to the /etc/rc.local file, focusing on timestamps and user accounts involved in the changes.
+- Examine the contents of the /etc/rc.local file to identify any suspicious or unauthorized commands or scripts that may have been added.
+- Investigate the process tree and parent processes associated with the rc-local.service to determine if there are any unusual or unexpected parent processes that could indicate compromise.
+- Check for any other persistence mechanisms or indicators of compromise on the system, such as unauthorized user accounts or scheduled tasks, to assess the broader impact of the potential threat.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or related activities that could provide additional context or evidence of malicious behavior.
+
+### False positive analysis
+
+- System maintenance scripts: Some Linux distributions or administrators may use the rc.local script for legitimate system maintenance tasks. Review the script's content to verify its purpose and consider excluding these known benign scripts from triggering alerts.
+- Custom startup configurations: Organizations might have custom startup configurations that utilize rc.local for non-malicious purposes. Document these configurations and create exceptions in the detection rule to prevent unnecessary alerts.
+- Legacy applications: Certain legacy applications might rely on rc.local for initialization. Identify these applications and assess their necessity. If deemed safe, exclude their execution from the rule to reduce false positives.
+- Testing environments: In testing or development environments, rc.local might be used for various non-threatening experiments. Clearly label these environments and adjust the rule to ignore alerts originating from them.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit the attacker's access.
+- Review the contents of the `/etc/rc.local` file on the affected system to identify any unauthorized or suspicious commands or scripts. Remove any malicious entries found.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms.
+- Restore the system from a known good backup if the integrity of the system is in question and if malicious activity is confirmed.
+- Implement monitoring for changes to the `/etc/rc.local` file and other critical system files to detect unauthorized modifications in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected.
+- Review and update security policies and configurations to disable the execution of the `/etc/rc.local` script by default on all systems, unless explicitly required for legitimate purposes."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
index ae85b369470..7af8ea3ef22 100644
--- a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,40 @@ query = '''
 host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:rpm and
 process.args:("-i" or "--install")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 RPM Package Installed by Unusual Parent Process
+
+RPM is a package management system crucial for managing software on Linux distributions like Red Hat and CentOS. Adversaries may exploit RPM by installing backdoored or malicious packages to gain persistence or initial access. The detection rule identifies anomalies by flagging RPM installations initiated by atypical parent processes, which could indicate unauthorized or suspicious activity. This helps in early detection of potential threats by monitoring process execution patterns.
+
+### Possible investigation steps
+
+- Review the parent process of the RPM installation to determine if it is a known and legitimate process. Investigate any unusual or unexpected parent processes that initiated the RPM command.
+- Examine the command-line arguments used with the RPM process, specifically looking for the "-i" or "--install" flags, to confirm the installation action and gather more context about the package being installed.
+- Check the timestamp of the event to correlate it with other activities on the system, such as user logins or other process executions, to identify any suspicious patterns or anomalies.
+- Investigate the user account under which the RPM installation was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access.
+- Analyze the network activity around the time of the RPM installation to identify any external connections that could suggest data exfiltration or communication with a command and control server.
+- Review system logs and other security alerts from the same timeframe to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- System administrators or automated scripts may frequently install RPM packages as part of routine maintenance or updates. To manage this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions.
+- Some legitimate software deployment tools might use non-standard parent processes to install RPM packages. Identify and whitelist these tools to prevent unnecessary alerts.
+- Development environments might trigger RPM installations through unusual parent processes during testing or software builds. Exclude these environments or specific processes from the rule to reduce false positives.
+- Custom or third-party management tools that are not widely recognized might also cause alerts. Review and whitelist these tools if they are verified as safe and necessary for operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further compromise.
+- Terminate any suspicious processes related to the RPM installation that were initiated by unusual parent processes.
+- Conduct a thorough review of the installed RPM packages to identify and remove any unauthorized or malicious software.
+- Restore the system from a known good backup if malicious packages have been confirmed and system integrity is compromised.
+- Update and patch the system to ensure all software is up-to-date, reducing the risk of exploitation through known vulnerabilities.
+- Implement stricter access controls and monitoring on systems to prevent unauthorized RPM installations, focusing on unusual parent processes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_shadow_file_modification.toml b/rules/linux/persistence_shadow_file_modification.toml
index ae90763ce34..ef0246a60ce 100644
--- a/rules/linux/persistence_shadow_file_modification.toml
+++ b/rules/linux/persistence_shadow_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ query = '''
 file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and
 file.path == "/etc/shadow" and file.Ext.original.path != null
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Shadow File Modification
+
+The Linux shadow file is crucial for storing hashed user passwords, ensuring system security. Adversaries may exploit this by altering the file to add users or change passwords, thus gaining unauthorized access or maintaining persistence. The detection rule identifies suspicious modifications by monitoring changes and renames of the shadow file, flagging potential unauthorized access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event type is "change" and the action is "rename" for the file path "/etc/shadow".
+- Check the file.Ext.original.path to identify the original location of the shadow file before the rename event.
+- Investigate recent user account changes or additions by examining system logs and user management commands executed around the time of the alert.
+- Analyze the history of commands executed by users with elevated privileges to identify any unauthorized or suspicious activities.
+- Correlate the event with other security alerts or logs to determine if there are additional indicators of compromise or persistence tactics being employed.
+- Verify the integrity of the shadow file by comparing its current state with a known good backup to detect unauthorized modifications.
+
+### False positive analysis
+
+- System updates or package installations may trigger legitimate changes to the shadow file. Users can create exceptions for known update processes or package managers to prevent these from being flagged.
+- Administrative tasks performed by authorized personnel, such as password changes or user management, can also result in shadow file modifications. Implementing a whitelist for specific user accounts or processes that are known to perform these tasks can reduce false positives.
+- Backup or restoration processes that involve the shadow file might cause rename events. Users should identify and exclude these processes if they are part of regular system maintenance.
+- Automated scripts or configuration management tools that manage user accounts could lead to expected changes in the shadow file. Users should ensure these tools are recognized and excluded from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Verify the integrity of the /etc/shadow file by comparing it with a known good backup to identify unauthorized changes or additions.
+- Reset passwords for all user accounts on the affected system, ensuring the use of strong, unique passwords to mitigate the risk of compromised credentials.
+- Review and remove any unauthorized user accounts that may have been added to the system, ensuring that only legitimate users have access.
+- Conduct a thorough audit of system logs and user activity to identify any additional signs of compromise or persistence mechanisms employed by the threat actor.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement enhanced monitoring and alerting for future modifications to the /etc/shadow file to quickly detect and respond to similar threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_shell_configuration_modification.toml b/rules/linux/persistence_shell_configuration_modification.toml
index 95de3e6a32b..f6285354aca 100644
--- a/rules/linux/persistence_shell_configuration_modification.toml
+++ b/rules/linux/persistence_shell_configuration_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -98,6 +98,41 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Shell Configuration Creation or Modification
+
+Shell configuration files in Unix-like systems are crucial for setting up user environments by defining variables, aliases, and startup scripts. Adversaries exploit these files to execute malicious code persistently. The detection rule identifies suspicious creation or modification of these files, excluding benign processes, to flag potential threats, aligning with tactics like persistence and event-triggered execution.
+
+### Possible investigation steps
+
+- Review the specific file path involved in the alert to determine if it is a system-wide or user-specific shell configuration file, as listed in the query.
+- Identify the process executable that triggered the alert and verify if it is part of the excluded benign processes. If not, investigate the process's origin and purpose.
+- Check the modification or creation timestamp of the file to correlate with any known user activities or scheduled tasks that might explain the change.
+- Examine the contents of the modified or newly created shell configuration file for any suspicious or unauthorized entries, such as unexpected scripts or commands.
+- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if the account may have been compromised.
+- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- System package managers like dpkg, rpm, and yum often modify shell configuration files during software installations or updates. To handle these, exclude processes with executables such as /bin/dpkg or /usr/bin/rpm from triggering alerts.
+- Automated system management tools like Puppet and Chef may alter shell configuration files as part of their routine operations. Exclude these processes by adding exceptions for executables like /opt/puppetlabs/puppet/bin/puppet or /usr/bin/chef-client.
+- User account management activities, such as adding new users, can lead to shell configuration file modifications. Exclude processes like /usr/sbin/adduser or /sbin/useradd to prevent false positives in these scenarios.
+- Temporary files created by text editors (e.g., .swp files) during editing sessions can trigger alerts. Exclude file extensions such as swp, swpx, and swx to avoid these false positives.
+- Virtualization and containerization tools like Docker and Podman may modify shell configuration files as part of their operations. Exclude executables like /usr/bin/dockerd or /usr/bin/podman to manage these cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Review the modified or newly created shell configuration files to identify and remove any unauthorized or malicious code.
+- Restore the affected shell configuration files from a known good backup to ensure the system's environment is clean and secure.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Monitor the system and network for any signs of re-infection or related suspicious activity, focusing on the indicators of compromise (IOCs) associated with the Kaiji malware family.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring and alerting for changes to shell configuration files to enhance detection of similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_simple_web_server_connection_accepted.toml b/rules/linux/persistence_simple_web_server_connection_accepted.toml
index 47c99c850ca..88b39906e10 100644
--- a/rules/linux/persistence_simple_web_server_connection_accepted.toml
+++ b/rules/linux/persistence_simple_web_server_connection_accepted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ network where host.os.type == "linux" and event.type == "start" and event.action
   (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*"))
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Simple HTTP Web Server Connection
+
+Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields.
+- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections.
+- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access.
+- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies.
+- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload.
+- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule.
+- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list.
+- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities.
+- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts.
+- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity.
+- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded.
+- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access.
+- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated.
+- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_simple_web_server_creation.toml b/rules/linux/persistence_simple_web_server_creation.toml
index 34d6e9c307b..c7478e060ef 100644
--- a/rules/linux/persistence_simple_web_server_creation.toml
+++ b/rules/linux/persistence_simple_web_server_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ process where host.os.type == "linux" and event.type == "start" and
     (process.name like "python*" and process.args in ("--cgi", "CGIHTTPServer"))
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Simple HTTP Web Server Creation
+
+Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised Linux systems. By deploying a web server, they can upload malicious payloads, such as reverse shells, to maintain remote access. The detection rule identifies suspicious server creation by monitoring process executions that match specific patterns, such as PHP or Python commands indicative of server setup, thereby alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of PHP or Python commands with arguments matching the patterns specified in the query, such as PHP with the "-S" argument or Python with "--cgi" or "CGIHTTPServer".
+- Identify the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Examine the network activity associated with the process to identify any unusual connections or data transfers that could suggest malicious intent or data exfiltration.
+- Check the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads, such as reverse shells.
+- Investigate the parent process of the suspicious server creation to understand how the process was initiated and whether it was triggered by another potentially malicious activity.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Development and testing environments often use simple HTTP servers for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development directories or user accounts frequently involved in these activities.
+- Automated scripts or cron jobs may start simple HTTP servers for routine tasks like file distribution or internal data sharing. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts.
+- Educational or training sessions might involve setting up simple HTTP servers as part of learning exercises. Exclude specific IP ranges or user groups associated with training environments to prevent false positives.
+- System administrators might use simple HTTP servers for quick troubleshooting or system maintenance tasks. Document these activities and create exceptions based on the administrator's user accounts or specific server names.
+- Continuous integration and deployment pipelines may temporarily start HTTP servers during build or deployment processes. Identify these pipelines and exclude their associated processes or execution contexts from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious PHP or Python processes identified by the detection rule to halt the operation of the unauthorized web server.
+- Conduct a thorough examination of the web server's root directory to identify and remove any malicious payloads, such as reverse shells or unauthorized scripts.
+- Review system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary.
+- Restore the system from a known good backup if any critical system files or configurations have been altered by the adversary.
+- Implement stricter access controls and monitoring on the affected system to prevent similar unauthorized server setups in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_ssh_key_generation.toml b/rules/linux/persistence_ssh_key_generation.toml
index e391a1b9c89..2745eef79ff 100644
--- a/rules/linux/persistence_ssh_key_generation.toml
+++ b/rules/linux/persistence_ssh_key_generation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,41 @@ file where host.os.type == "linux" and event.action in ("creation", "file_create
 process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and
 not file.name : "known_hosts.*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SSH Key Generated via ssh-keygen
+
+SSH keys, created using the ssh-keygen tool, are essential for secure authentication in Linux environments. While typically used for legitimate access to remote systems, adversaries can exploit this by generating unauthorized keys, enabling lateral movement or persistence. The detection rule identifies suspicious key creation by monitoring specific directories and actions, helping to flag potential misuse by threat actors.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and name where the SSH key was created, focusing on directories like "/home/*/.ssh/*", "/root/.ssh/*", and "/etc/ssh/*".
+- Check the user account associated with the SSH key creation event to determine if the action aligns with expected behavior for that user.
+- Investigate the process execution context by examining the process tree and parent processes of "/usr/bin/ssh-keygen" to identify any potentially suspicious activity leading to the key generation.
+- Analyze recent login and access logs for the user and system involved to detect any unusual or unauthorized access patterns.
+- Correlate the event with other security alerts or logs to identify if there are signs of lateral movement or persistence tactics being employed by a threat actor.
+- Verify the legitimacy of the SSH key by consulting with the system owner or user to confirm if the key creation was authorized and necessary.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators generate SSH keys for legitimate purposes. To manage this, create exceptions for specific user accounts or directories known to be used by trusted administrators.
+- Automated scripts or configuration management tools that regularly generate SSH keys for system provisioning or maintenance can cause false positives. Identify these scripts and exclude their associated processes or file paths from the rule.
+- Development environments where developers frequently create SSH keys for testing or deployment purposes might be flagged. Consider excluding directories or user accounts associated with these environments to reduce noise.
+- Backup or recovery processes that involve SSH key generation can also trigger alerts. Review these processes and exclude relevant file paths or processes to prevent unnecessary alerts.
+- Security tools or monitoring solutions that simulate SSH key generation for testing or validation purposes may be mistakenly flagged. Identify these tools and add exceptions for their activities to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Revoke any unauthorized SSH keys found in the monitored directories (/home/*/.ssh/*, /root/.ssh/*, /etc/ssh/*) to cut off access for threat actors.
+- Conduct a thorough review of user accounts and SSH key pairs on the affected system to identify and remove any unauthorized accounts or keys.
+- Reset passwords and regenerate SSH keys for legitimate users to ensure that compromised credentials are not reused.
+- Monitor network traffic and system logs for any signs of further unauthorized access attempts or suspicious activity related to SSH.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring and alerting for SSH key generation activities across the network to enhance detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_ssh_netcon.toml b/rules/linux/persistence_ssh_netcon.toml
index 44b2a2d4a20..2cbd286a171 100644
--- a/rules/linux/persistence_ssh_netcon.toml
+++ b/rules/linux/persistence_ssh_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,39 @@ sequence by host.id with maxspan=1s
     )
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Connection Initiated by SSHD Child Process
+
+The SSH Daemon (SSHD) facilitates secure remote logins and command execution on Linux systems. Adversaries may exploit SSHD by modifying shell configurations or backdooring the daemon to establish unauthorized connections, often for persistence or data exfiltration. The detection rule identifies suspicious outbound connections initiated by SSHD child processes, excluding benign processes and internal IP ranges, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process details of the SSHD child process that initiated the network connection, focusing on the process.entity_id and process.parent.entity_id to understand the process hierarchy and parent-child relationship.
+- Examine the destination IP address of the network connection attempt to determine if it is associated with known malicious activity or suspicious external entities, especially since it is not within the excluded internal IP ranges.
+- Investigate the executable path of the process that initiated the connection to ensure it is not a known benign process like "/bin/yum" or "/usr/bin/yum", and verify if the process name is not among the excluded ones such as "login_duo", "ssh", "sshd", or "sshd-session".
+- Check the timing and frequency of the SSHD child process executions and network connection attempts to identify any patterns or anomalies that could indicate unauthorized or persistent access attempts.
+- Correlate the alert with other security events or logs from the same host.id to gather additional context and determine if there are other indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Internal administrative scripts or tools that initiate network connections upon SSH login can trigger false positives. To manage this, identify and whitelist these specific scripts or tools by their process names or executable paths.
+- Automated software updates or package management processes like yum may occasionally initiate network connections. Exclude these processes by adding them to the exception list using their executable paths.
+- Security tools such as login_duo or other authentication mechanisms that establish network connections during SSH sessions can be mistaken for malicious activity. Exclude these tools by specifying their process names in the exception list.
+- Custom monitoring or logging solutions that connect to external servers for data aggregation might be flagged. Identify these processes and exclude them by their executable paths or process names to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified as child processes of SSHD that are attempting unauthorized network connections.
+- Conduct a thorough review of SSHD configuration files and shell configuration files for unauthorized modifications or backdoors, and restore them from a known good backup if necessary.
+- Change all credentials associated with the affected system, especially those that may have been exposed or used during the unauthorized SSH sessions.
+- Apply security patches and updates to the SSH daemon and related software to mitigate known vulnerabilities that could be exploited for persistence or unauthorized access.
+- Monitor network traffic for any further suspicious outbound connections from other systems, indicating potential lateral movement or additional compromised hosts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_ssh_via_backdoored_system_user.toml b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
index 9be325eed2b..ae091309e82 100644
--- a/rules/linux/persistence_ssh_via_backdoored_system_user.toml
+++ b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ user.name in (
   "avahi", "sshd", "dnsmasq"
 ) and event.outcome == "success"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Login via Unusual System User
+
+In Linux environments, system users typically have restricted login capabilities to prevent unauthorized access. These accounts, often set with `nologin`, are not meant for interactive sessions. Adversaries may exploit these accounts by altering their configurations to enable SSH access, thus bypassing standard security measures. The detection rule identifies successful logins by these uncommon system users, flagging potential unauthorized access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the login event details to identify the specific system user account involved in the successful login, focusing on the user.name field.
+- Check the system logs for any recent changes to the user account's configuration, particularly modifications that might have enabled SSH access for accounts typically set with nologin.
+- Investigate the source IP address associated with the login event to determine if it is known or suspicious, and assess whether it aligns with expected access patterns.
+- Examine the timeline of events leading up to and following the login to identify any unusual activities or patterns that could indicate malicious behavior.
+- Verify if there are any other successful login attempts from the same source IP or involving other system user accounts, which could suggest a broader compromise.
+- Consult with system administrators to confirm whether any legitimate changes were made to the system user account's login capabilities and document any authorized modifications.
+
+### False positive analysis
+
+- System maintenance tasks may require temporary login access for system users. Verify if the login corresponds with scheduled maintenance and consider excluding these events during known maintenance windows.
+- Automated scripts or services might use system accounts for legitimate purposes. Identify these scripts and whitelist their associated activities to prevent false alerts.
+- Some system users might be configured for specific applications that require login capabilities. Review application requirements and exclude these users if their access is deemed necessary and secure.
+- In environments with custom configurations, certain system users might be intentionally modified for operational needs. Document these changes and adjust the detection rule to exclude these known modifications.
+- Regularly review and update the list of system users in the detection rule to ensure it reflects the current environment and operational requirements, minimizing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any active sessions associated with the unusual system user accounts identified in the alert to disrupt ongoing unauthorized access.
+- Review and revert any unauthorized changes to the system user accounts, such as modifications to the shell configuration that enabled login capabilities.
+- Conduct a thorough audit of the system for any additional unauthorized changes or backdoors, focusing on SSH configurations and user account settings.
+- Reset passwords and update authentication mechanisms for all system user accounts to prevent further exploitation.
+- Implement additional monitoring and alerting for any future login attempts by system users, ensuring rapid detection and response to similar threats.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_suspicious_file_opened_through_editor.toml b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
index fecb6235a8a..7203330663a 100644
--- a/rules/linux/persistence_suspicious_file_opened_through_editor.toml
+++ b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,41 @@ file.path : (
   "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Suspicious File Edit
+
+In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query.
+- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update.
+- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role.
+- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies.
+- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories.
+- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd.
+
+### False positive analysis
+
+- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel.
+- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives.
+- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives.
+- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences.
+- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity.
+- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes.
+- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access.
+- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
index 5590ed91078..00dd46c4b65 100644
--- a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
+++ b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,40 @@ sequence by host.id, user.id with maxspan=1s
  [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.pid, process.entity_id
  [network where host.os.type == "linux" and event.type == "end" and event.action == "disconnect_received" and process.name == "sshd"] by process.pid, process.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Execution via XZBackdoor
+
+The XZBackdoor leverages SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity.
+
+### Possible investigation steps
+
+- Review the SSH session logs on the affected host to identify any unusual or unauthorized access attempts, focusing on sessions that match the process.pid and process.entity_id from the alert.
+- Examine the command history and executed commands for the user associated with the user.id in the alert to identify any suspicious or unexpected activities.
+- Investigate the non-standard executables invoked by the SSH session by checking the process.executable field to determine if they are legitimate or potentially malicious.
+- Analyze the network activity associated with the SSH session, particularly any disconnect_received events, to identify any unusual patterns or connections to suspicious IP addresses.
+- Check the exit codes of the SSH processes, especially those with a non-zero process.exit_code, to understand the reason for the abrupt termination and whether it aligns with typical error codes or indicates malicious activity.
+
+### False positive analysis
+
+- Legitimate administrative SSH sessions may trigger the rule if they involve non-standard executables. To manage this, create exceptions for known administrative scripts or tools that are frequently used in your environment.
+- Automated processes or scripts that use SSH for routine tasks might mimic the behavior of the XZBackdoor. Identify these processes and exclude them by specifying their executable paths or command-line patterns in the rule exceptions.
+- Security tools or monitoring solutions that perform SSH-based checks could be mistaken for malicious activity. Review these tools and add their signatures to the exclusion list to prevent false alerts.
+- Custom applications that use SSH for communication might be flagged. Document these applications and adjust the rule to recognize their specific execution patterns as non-threatening.
+- Temporary network issues causing abrupt SSH session terminations could be misinterpreted as suspicious behavior. Monitor network stability and consider excluding known transient disconnections from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious SSH sessions identified by the detection rule to stop ongoing malicious activity.
+- Conduct a thorough review of the affected host's SSH configuration and logs to identify unauthorized changes or access patterns.
+- Reset credentials for any user accounts involved in the suspicious SSH activity to prevent further unauthorized access.
+- Restore the affected system from a known good backup if any unauthorized changes or malware are detected.
+- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_systemd_generator_creation.toml b/rules/linux/persistence_systemd_generator_creation.toml
index ac5ff2677bd..1f1ec52c970 100644
--- a/rules/linux/persistence_systemd_generator_creation.toml
+++ b/rules/linux/persistence_systemd_generator_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -83,6 +83,40 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
   process.executable == null
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Systemd Generator Created
+
+Systemd generators are scripts that systemd runs at boot or during configuration reloads to convert non-native configurations into unit files. Adversaries can exploit this by creating malicious generators to execute arbitrary code, ensuring persistence or escalating privileges. The detection rule identifies suspicious generator file creations or renames, excluding benign processes and file types, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the file path where the generator was created or renamed to determine if it is located in a standard systemd generator directory, such as /run/systemd/system-generators/ or /etc/systemd/user-generators/.
+- Identify the process that created or renamed the generator file by examining the process.executable field, and determine if it is a known benign process or potentially malicious.
+- Check the file extension and original extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like "swp" or "dpkg-new".
+- Investigate the history and behavior of the process that created the generator file, including any associated network connections or file modifications, to assess if it exhibits signs of malicious activity.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest persistence or privilege escalation attempts.
+
+### False positive analysis
+
+- Package managers like dpkg, rpm, and yum can trigger false positives when they create or rename files in systemd generator directories during software installations or updates. To handle these, exclude processes associated with these package managers as specified in the rule.
+- Automated system management tools such as Puppet and Chef may also create or modify generator files as part of their configuration management tasks. Exclude these processes by adding them to the exception list if they are part of your environment.
+- Temporary files with extensions like swp, swpx, and swx, often created by text editors, can be mistakenly flagged. Ensure these extensions are included in the exclusion list to prevent unnecessary alerts.
+- System updates or maintenance scripts that run as part of regular operations might create or modify generator files. Identify these scripts and add their executables to the exclusion list to reduce false positives.
+- Custom scripts or tools that are part of legitimate administrative tasks may also trigger alerts. Review these scripts and consider excluding their executables if they are verified as non-malicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement.
+- Terminate any suspicious processes associated with the creation or modification of systemd generator files to halt any ongoing malicious activity.
+- Conduct a thorough review of the systemd generator directories to identify and remove any unauthorized or suspicious generator files.
+- Restore any modified or deleted legitimate systemd generator files from a known good backup to ensure system integrity.
+- Implement file integrity monitoring on systemd generator directories to detect unauthorized changes in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Review and update access controls and permissions for systemd generator directories to limit the ability to create or modify files to authorized users only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_systemd_netcon.toml b/rules/linux/persistence_systemd_netcon.toml
index ca08b619167..641a6a506f5 100644
--- a/rules/linux/persistence_systemd_netcon.toml
+++ b/rules/linux/persistence_systemd_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,41 @@ sequence by host.id with maxspan=5s
   [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
    not process.executable == "/tmp/newroot/bin/curl"] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Network Connection via systemd
+
+Systemd is a critical component in Linux, managing system processes and services. Adversaries exploit it by altering unit files or replacing binaries to ensure malicious scripts run at startup, achieving persistence. The detection rule identifies unusual network activities initiated by systemd, flagging potential backdoor usage by monitoring specific processes and network attempts, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific script or command executed by systemd, focusing on the process names such as "python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk".
+- Examine the parent process information to confirm that the suspicious process was indeed initiated by systemd, ensuring the parent process name is "systemd".
+- Investigate the network connection attempt details, including the destination IP address and port, to determine if the connection is to a known malicious or suspicious endpoint.
+- Check the process executable path to ensure it is not a known legitimate path, especially looking for unusual paths that might indicate a compromised binary, excluding "/tmp/newroot/bin/curl".
+- Analyze the systemd unit files on the host to identify any unauthorized modifications or additions that could indicate persistence mechanisms.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+- Consult threat intelligence sources to gather more context on the IP addresses or domains involved in the network connection attempt.
+
+### False positive analysis
+
+- Legitimate administrative scripts or maintenance tasks that use scripting languages like Python, PHP, or Perl may trigger the rule. To handle this, identify and document these scripts, then create exceptions for their specific process names or paths.
+- Automated system monitoring tools that perform network checks using utilities like netcat or telnet might be flagged. Review these tools and whitelist their process names or executable paths to prevent false alerts.
+- Custom applications or services that are legitimately started by systemd and initiate network connections could be misidentified. Verify these applications and add them to an allowlist based on their process names or parent entity IDs.
+- Development or testing environments where developers frequently use scripting languages for network operations may cause false positives. Consider excluding these environments from monitoring or creating specific rules that account for their unique behaviors.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified in the alert, particularly those initiated by systemd that match the specified process names (e.g., python, php, perl).
+- Review and restore any modified or suspicious systemd unit files to their original state, ensuring no unauthorized scripts or commands are set to execute at startup.
+- Conduct a thorough scan of the affected system for additional indicators of compromise, focusing on persistence mechanisms and unauthorized network connections.
+- Reinstall or verify the integrity of systemd binaries to ensure they have not been replaced or tampered with by malicious actors.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for systemd-related activities and network connections to detect similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_tainted_kernel_module_load.toml b/rules/linux/persistence_tainted_kernel_module_load.toml
index 6cabc894a4d..e07ec7f9272 100644
--- a/rules/linux/persistence_tainted_kernel_module_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/23"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,40 @@ query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
 message:"module verification failed: signature and/or required key missing - tainting kernel"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Tainted Kernel Module Load
+
+Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of code. While beneficial, they can be exploited by adversaries to introduce malicious code, bypassing security measures. Attackers may load unsigned or improperly signed modules, leading to a "tainted" kernel state. The detection rule identifies such events by monitoring syslog for specific error messages, signaling potential unauthorized module loads, thus aiding in early threat detection and system integrity maintenance.
+
+### Possible investigation steps
+
+- Review the syslog entries around the time of the alert to gather additional context and identify any other suspicious activities or related events.
+- Investigate the specific kernel module mentioned in the syslog message to determine its origin, legitimacy, and whether it is expected on the system.
+- Check the system for any recent changes or installations that could have introduced the unsigned or improperly signed module, including software updates or new applications.
+- Analyze the system for signs of compromise, such as unexpected network connections, unusual process activity, or unauthorized user accounts, which may indicate a broader security incident.
+- Consult with system administrators or relevant personnel to verify if the module load was authorized or part of a legitimate operation, and document any findings or justifications provided.
+
+### False positive analysis
+
+- Custom kernel modules: Organizations often use custom or proprietary kernel modules that may not be signed. These can trigger false positives. To manage this, maintain a list of known, trusted custom modules and create exceptions for them in the monitoring system.
+- Outdated or unsupported hardware drivers: Some older hardware drivers may not have signed modules, leading to false positives. Regularly update drivers and, if necessary, exclude specific drivers that are known to be safe but unsigned.
+- Development and testing environments: In environments where kernel module development occurs, unsigned modules may be loaded frequently. Implement separate monitoring rules or exceptions for these environments to avoid unnecessary alerts.
+- Vendor-provided modules: Certain vendors may provide modules that are not signed. Verify the legitimacy of these modules with the vendor and consider excluding them if they are confirmed to be safe.
+- Temporary testing modules: During troubleshooting or testing, temporary modules might be loaded without proper signing. Ensure these are removed after testing and consider temporary exceptions during the testing phase.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Verify the integrity of the kernel and loaded modules by comparing them against known good versions or using a trusted baseline.
+- Unload the suspicious kernel module if possible, and replace it with a verified, signed version to restore system integrity.
+- Conduct a thorough forensic analysis of the affected system to identify any additional signs of compromise or persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Implement enhanced monitoring and logging for kernel module loads and other critical system activities to detect similar threats in the future.
+- Review and update system and network access controls to ensure only authorized personnel can load kernel modules, reducing the risk of unauthorized changes."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
index 57ff1986c23..ab0d59ff5c9 100644
--- a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,41 @@ query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
 message:"loading out-of-tree module taints kernel."
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Tainted Out-Of-Tree Kernel Module Load
+
+Kernel modules extend the functionality of the Linux kernel without rebooting the system. While beneficial, out-of-tree modules, not included in the official kernel source, can taint the kernel, posing security risks. Adversaries exploit this by loading malicious modules to evade detection and maintain persistence. The detection rule monitors syslog for specific messages indicating such module loads, helping identify potential threats early.
+
+### Possible investigation steps
+
+- Review the syslog entries around the time of the alert to gather additional context about the module load event, focusing on messages with "loading out-of-tree module taints kernel."
+- Identify the specific out-of-tree kernel module that was loaded by examining the syslog message details and cross-reference with known legitimate modules.
+- Check the system for any recent changes or installations that might have introduced the out-of-tree module, such as software updates or new applications.
+- Investigate the source and integrity of the module by verifying its origin and comparing its hash against known good or malicious hashes.
+- Assess the system for any signs of compromise or unauthorized access, focusing on persistence mechanisms and defense evasion tactics, as indicated by the MITRE ATT&CK framework references.
+- Consult with system administrators or relevant stakeholders to determine if the module load was authorized or expected as part of normal operations.
+
+### False positive analysis
+
+- Legitimate third-party drivers or hardware support modules may trigger alerts when loaded as out-of-tree modules. Users should verify the source and purpose of these modules to ensure they are not malicious.
+- Custom-built modules for specific applications or hardware optimizations can also cause false positives. Users can create exceptions for these modules by adding them to an allowlist if they are verified as safe and necessary for system operations.
+- Development and testing environments often load experimental or custom modules that are not part of the official kernel. In such cases, users should document these modules and exclude them from alerts to avoid unnecessary noise.
+- Regularly updated or patched modules from trusted vendors might not be immediately recognized as safe. Users should maintain a list of trusted vendors and update their exception lists accordingly to prevent false positives.
+- Some security tools or monitoring solutions may use out-of-tree modules for enhanced functionality. Users should ensure these tools are from reputable sources and exclude their modules from detection rules if they are confirmed to be secure.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Identify and unload the suspicious out-of-tree kernel module using the `rmmod` command to remove it from the kernel.
+- Conduct a thorough review of the system's kernel module load history and verify the legitimacy of all loaded modules.
+- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software.
+- Restore the system from a known good backup if the integrity of the system cannot be assured after module removal.
+- Implement stricter access controls and monitoring for kernel module loading to prevent unauthorized module loads in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_udev_rule_creation.toml b/rules/linux/persistence_udev_rule_creation.toml
index aa3b26fe2c2..dd4c053842e 100644
--- a/rules/linux/persistence_udev_rule_creation.toml
+++ b/rules/linux/persistence_udev_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -83,6 +83,42 @@ file.path : (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Systemd-udevd Rule File Creation
+
+Systemd-udevd manages device nodes and handles kernel device events in Linux, using rule files to automate responses to hardware changes. Adversaries can exploit this by creating malicious rules that execute commands when specific devices are connected. The detection rule monitors the creation of these rule files, excluding legitimate processes, to identify potential abuse and ensure system integrity.
+
+### Possible investigation steps
+
+- Review the file path and name to determine if the rule file is located in a directory commonly used for udev rules, such as /etc/udev/rules.d/ or /lib/udev/.
+- Examine the process executable that created or renamed the rule file to identify if it is a known legitimate process or an unexpected one, as specified in the query.
+- Check the file extension and ensure it is .rules, confirming it is intended for udev rule configuration.
+- Investigate the process name and path to determine if it matches any of the excluded legitimate processes or paths, which could indicate a false positive.
+- Analyze the contents of the newly created or modified rule file to identify any suspicious or malicious commands that could be executed when a device is connected.
+- Correlate the event with other system logs to identify any related activities or anomalies around the time of the rule file creation or modification.
+- Assess the risk and impact of the rule file creation by considering the context of the system and any potential persistence mechanisms it might enable for an adversary.
+
+### False positive analysis
+
+- System updates and package installations can trigger rule file creations. Exclude processes like dpkg, rpm, and yum by adding them to the exception list to prevent false positives during legitimate system maintenance.
+- Container management tools such as Docker and Podman may create or modify udev rules. Exclude these processes to avoid alerts when containers are being managed.
+- Automated system configuration tools like Puppet and Chef can modify udev rules as part of their operations. Add these tools to the exception list to reduce noise from routine configuration changes.
+- Snap package installations and updates can lead to rule file changes. Exclude snapd and related processes to prevent false positives during snap operations.
+- Netplan and systemd processes may generate or modify udev rules as part of network configuration or system initialization. Exclude these processes to avoid unnecessary alerts during legitimate system activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of malicious udev rules and potential lateral movement.
+- Identify and review the newly created or modified udev rule files in the specified directories to determine if they contain malicious commands or payloads.
+- Remove any unauthorized or malicious udev rule files to prevent them from executing on device connection events.
+- Restore any affected system configurations or files from a known good backup to ensure system integrity.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms.
+- Monitor the system for any further suspicious activity or attempts to recreate malicious udev rules, adjusting detection mechanisms as necessary.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring comprehensive threat containment and remediation."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_unusual_pam_grantor.toml b/rules/linux/persistence_unusual_pam_grantor.toml
index 2fee0dc96ad..4b0461200e5 100644
--- a/rules/linux/persistence_unusual_pam_grantor.toml
+++ b/rules/linux/persistence_unusual_pam_grantor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,40 @@ query = '''
 event.category:authentication and host.os.type:linux and event.action:authenticated and event.outcome:success and
 auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Authentication via Unusual PAM Grantor
+
+Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit uncommon PAM grantors to escalate privileges or maintain persistence by altering default configurations. The detection rule identifies successful authentications using atypical PAM grantors, signaling potential unauthorized access or configuration tampering.
+
+### Possible investigation steps
+
+- Review the specific PAM grantor involved in the authentication event to determine if it is known or expected in your environment.
+- Check the user account associated with the authentication event for any signs of compromise or unusual activity, such as recent changes in permissions or unexpected login times.
+- Investigate the source IP address and hostname of the authentication event to verify if it is a recognized and authorized system within your network.
+- Examine recent changes to the PAM configuration files on the affected host to identify any unauthorized modifications or additions.
+- Correlate this event with other security alerts or logs from the same host or user to identify potential patterns of malicious activity.
+- Consult with system administrators or relevant personnel to confirm if the use of the unusual PAM grantor was part of a legitimate change or update.
+
+### False positive analysis
+
+- Custom PAM modules: Organizations may use custom PAM modules for specific applications or security policies. Review these modules to ensure they are legitimate and add them to an exception list if they are frequently triggering alerts.
+- Administrative scripts: Some administrative scripts might use non-standard PAM grantors for automation purposes. Verify the scripts' legitimacy and consider excluding them from the rule if they are part of routine operations.
+- Third-party software: Certain third-party software may install or use uncommon PAM grantors as part of their authentication process. Validate the software's authenticity and add its grantors to an exception list if they are known to be safe.
+- Development environments: In development or testing environments, developers might experiment with different PAM configurations. Ensure these environments are properly isolated and consider excluding them from the rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Review the PAM configuration files on the affected system to identify and revert any unauthorized changes to the grantors. Ensure only legitimate PAM modules are in use.
+- Terminate any suspicious or unauthorized processes that may have been initiated by the attacker to maintain persistence or escalate privileges.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or newly created accounts. Revoke any unauthorized access.
+- Restore the affected system from a known good backup if unauthorized changes cannot be easily reverted or if the system's integrity is in question.
+- 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 enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_unusual_sshd_child_process.toml b/rules/linux/persistence_unusual_sshd_child_process.toml
index 83eae707d3b..941a739b76b 100644
--- a/rules/linux/persistence_unusual_sshd_child_process.toml
+++ b/rules/linux/persistence_unusual_sshd_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/16"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,39 @@ event.category:process and host.os.type:linux and event.type:start and event.act
 process.parent.name:(ssh or sshd) and process.args_count:2 and
 not process.command_line:(-bash or -zsh or -sh)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual SSHD Child Process
+
+Secure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, focusing on atypical command-line arguments, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the process command line arguments for the unusual SSHD child process to identify any suspicious or unexpected commands that could indicate malicious activity.
+- Check the user account associated with the SSHD child process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations.
+- Investigate the parent process (SSH or SSHD) to understand the context of the connection, including the source IP address and any associated user activity, to assess if it aligns with expected behavior.
+- Examine the process tree to identify any subsequent processes spawned by the unusual SSHD child process, which may provide further insight into the attacker's actions or objectives.
+- Correlate the event with other security logs and alerts from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools may trigger this rule if they execute commands with SSH or SSHD as the parent process. To handle this, identify and document these scripts, then create exceptions for their specific command-line patterns.
+- System maintenance tasks or updates that involve SSH connections might appear as unusual child processes. Regularly review and whitelist these known maintenance activities to prevent unnecessary alerts.
+- Custom user environments or shell configurations that deviate from standard shells like bash, zsh, or sh could be flagged. Analyze these configurations and exclude them if they are verified as non-threatening.
+- Monitoring tools or security solutions that interact with SSH sessions for logging or auditing purposes might generate alerts. Verify these tools' behavior and exclude their processes if they are part of legitimate monitoring activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious SSHD child processes identified by the alert to halt potential malicious activities.
+- Conduct a thorough review of SSH configuration files and access logs to identify unauthorized changes or access patterns, and revert any unauthorized modifications.
+- Change all SSH keys and credentials associated with the compromised system to prevent further unauthorized access.
+- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to re-establish persistence.
+- 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.
+- Review and update firewall rules and access controls to restrict SSH access to only trusted IP addresses and users, reducing the attack surface for future incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/persistence_user_or_group_creation_or_modification.toml b/rules/linux/persistence_user_or_group_creation_or_modification.toml
index 3c1f2b7696b..a41d35802fc 100644
--- a/rules/linux/persistence_user_or_group_creation_or_modification.toml
+++ b/rules/linux/persistence_user_or_group_creation_or_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,40 @@ query = '''
 iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and 
 event.action in ("changed-password", "added-user-account", "added-group-account-to")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 User or Group Creation/Modification
+
+In Linux environments, user and group management is crucial for access control and system administration. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes audit logs to monitor successful user or group changes, flagging potential persistence tactics by correlating specific actions with known threat behaviors.
+
+### Possible investigation steps
+
+- Review the audit logs to identify the specific user or group account that was created or modified, focusing on the event.action field values such as "changed-password", "added-user-account", or "added-group-account-to".
+- Check the timestamp of the event to determine when the account change occurred and correlate it with any other suspicious activities or alerts around the same time.
+- Investigate the source of the event by examining the host information, particularly the host.os.type field, to understand which system the changes were made on.
+- Identify the user or process that initiated the account change by reviewing the associated user information in the audit logs, which may provide insights into whether the action was authorized or potentially malicious.
+- Cross-reference the identified user or group changes with known threat actor behaviors or recent incidents to assess if the activity aligns with any known persistence tactics.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when system administrators create or modify user or group accounts as part of regular maintenance. To manage this, consider creating exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or configuration management tools that manage user accounts can generate false positives. Identify these tools and exclude their actions from triggering alerts by whitelisting their processes or user accounts.
+- System updates or software installations that require user or group modifications might be flagged. Review the context of these changes and exclude specific update processes or installation scripts from the rule.
+- Temporary user accounts created for short-term projects or testing purposes can be mistaken for unauthorized access attempts. Implement a naming convention for temporary accounts and exclude them from the rule to reduce noise.
+- Changes made by trusted third-party services or applications that integrate with the system may appear suspicious. Verify these services and add them to an exception list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Review the audit logs to identify the specific user or group accounts that were created or modified, and disable or remove any unauthorized accounts.
+- Reset passwords for any compromised or suspicious accounts to prevent further unauthorized access.
+- Conduct a thorough review of system and application logs to identify any additional unauthorized changes or suspicious activities that may have occurred.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized account activities.
+- Review and update access control policies and procedures to prevent similar incidents in the future, ensuring that only authorized personnel have the ability to create or modify user and group accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_xdg_autostart_netcon.toml b/rules/linux/persistence_xdg_autostart_netcon.toml
index f9a8948444a..43530e9dd43 100644
--- a/rules/linux/persistence_xdg_autostart_netcon.toml
+++ b/rules/linux/persistence_xdg_autostart_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -97,6 +97,40 @@ sequence by host.id, process.entity_id with maxspan=1s
      )
   ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Connections Initiated Through XDG Autostart Entry
+
+XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges.
+
+### Possible investigation steps
+
+- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry.
+- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session.
+- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query.
+- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry.
+- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism.
+- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives.
+
+### False positive analysis
+
+- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule.
+- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts.
+- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening.
+- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement.
+- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity.
+- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker.
+- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation.
+- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
+- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
index d382a433ebc..3b68e2dcebf 100644
--- a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,41 @@ file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Yum Package Manager Plugin File Creation
+
+The Yum package manager is integral to managing software on Fedora-based Linux systems, utilizing plugins to extend its functionality. Adversaries may exploit this by inserting malicious code into these plugins, ensuring persistent access whenever Yum is executed. The detection rule identifies suspicious file creation in plugin directories, excluding legitimate processes and temporary files, to flag potential unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the file creation event details, focusing on the file path to confirm if it matches the plugin directories "/usr/lib/yum-plugins/*" or "/etc/yum/pluginconf.d/*".
+- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria.
+- Check the file extension and name to ensure it is not a temporary or excluded file type, such as those with extensions "swp", "swpx", "swx", or names starting with ".ansible".
+- Investigate the origin and legitimacy of the process by correlating with other system logs or using threat intelligence to determine if the process is known to be associated with malicious activity.
+- Assess the file content for any signs of malicious code or unauthorized modifications, especially if the file is a script or configuration file.
+- Determine if there have been any recent changes or updates to the system that could explain the file creation, such as legitimate software installations or updates.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger file creation events in Yum plugin directories. To handle these, users can create exceptions for known package management processes like rpm, dnf, and yum, which are already included in the rule's exclusion list.
+- Temporary files created by text editors or system processes, such as those with extensions like swp, swpx, or swx, can be safely excluded as they are typically non-threatening. Ensure these extensions are part of the exclusion criteria.
+- Automation tools like Ansible may generate temporary files in the plugin directories. Users can exclude file names starting with .ansible or .ansible_tmp to prevent false positives from these operations.
+- Processes running from specific directories like /nix/store or /var/lib/dpkg are often part of legitimate system operations. Users should verify these paths and include them in the exclusion list if they are part of regular system behavior.
+- System maintenance scripts or tools like sed and perl may create temporary files during their execution. Users can exclude these specific process names and file patterns to reduce false alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes that may be running as a result of the malicious plugin modification to halt any ongoing malicious activity.
+- Restore the compromised plugin files from a known good backup to ensure the integrity of the Yum package manager's functionality.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify and remove any unauthorized access or privilege escalations.
+- Implement file integrity monitoring on the Yum plugin directories to detect any future unauthorized modifications promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited by the adversary."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
index 4937bae0038..637e0c26c33 100644
--- a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
+++ b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,40 @@ process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
   process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Unauthorized Access via Wildcard Injection Detected
+
+In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse aimed at privilege escalation or unauthorized data access.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the "chown" or "chmod" command with the "-R" flag and wildcard usage in the arguments, as indicated by the query fields process.name, process.args, and event.action.
+- Examine the user account associated with the process execution to determine if it has the necessary permissions to perform such operations and assess if the account has been compromised.
+- Check the command execution history and related logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or unauthorized access attempts.
+- Investigate the source and destination of the command execution by analyzing network logs and connections to determine if the activity originated from a known or unknown IP address or host.
+- Correlate this event with other alerts or anomalies in the system to identify potential patterns or coordinated attacks, focusing on privilege escalation or credential access attempts as suggested by the rule's tags and threat information.
+
+### False positive analysis
+
+- Routine administrative tasks using chown or chmod with recursive flags may trigger the rule. To manage this, identify and whitelist specific scripts or users that regularly perform these tasks without security risks.
+- Automated system maintenance processes that involve changing file permissions or ownership across directories can be mistaken for malicious activity. Exclude these processes by specifying their command patterns or associated user accounts in the monitoring system.
+- Backup operations that involve copying and setting permissions on large sets of files might be flagged. To prevent this, configure exceptions for known backup tools or scripts that use these commands in a controlled manner.
+- Development environments where developers frequently change file permissions for testing purposes can generate false positives. Implement user-based exceptions for development teams to reduce unnecessary alerts.
+- System updates or package installations that modify file permissions as part of their normal operation may be detected. Create exceptions for trusted package managers or update processes to avoid false alarms.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified as running the `chown` or `chmod` commands with wildcard injections to halt potential privilege escalation activities.
+- Conduct a thorough review of system logs and command histories to identify any unauthorized changes made to file permissions or ownership and revert them to their original state.
+- Reset credentials and review access permissions for users on the affected system to ensure no unauthorized access persists.
+- Implement file integrity monitoring to detect unauthorized changes to critical files and directories in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update and patch the affected system to address any vulnerabilities that may have been exploited during the attack, ensuring all security updates are applied."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_container_util_misconfiguration.toml b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
index b5167a53e88..caab0b19d49 100644
--- a/rules/linux/privilege_escalation_container_util_misconfiguration.toml
+++ b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and 
 process.interactive == true and process.parent.interactive == true
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via Container Misconfiguration
+
+Containers, managed by tools like runc and ctr, isolate applications for security and efficiency. Misconfigurations can allow attackers to exploit these tools, running containers with elevated privileges or accessing sensitive host resources. The detection rule identifies suspicious use of these utilities by non-root users in interactive sessions, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific non-root user and group involved in the suspicious activity, as indicated by the user.Ext.real.id and group.Ext.real.id fields.
+- Examine the process tree to understand the parent-child relationship of the processes, focusing on the interactive nature of both the process and its parent, as indicated by process.interactive and process.parent.interactive fields.
+- Investigate the command-line arguments used with the runc or ctr utilities, particularly looking for the use of "run" and any potentially dangerous flags like "--privileged" or "--mount" that could indicate an attempt to escalate privileges.
+- Check the system logs and audit logs for any additional context around the time of the alert, focusing on any other suspicious activities or anomalies involving the same user or process.
+- Assess the configuration and access controls of the container management tools on the host to identify any misconfigurations or vulnerabilities that could have been exploited.
+
+### False positive analysis
+
+- Non-root users in development environments may frequently use runc or ctr for legitimate container management tasks. To mitigate this, consider creating exceptions for specific user IDs or groups known to perform these actions regularly.
+- Automated scripts or CI/CD pipelines might execute container commands interactively without root permissions. Identify these scripts and exclude their associated user accounts or process names from triggering the rule.
+- Some system administrators may operate with non-root accounts for security reasons but still require access to container management tools. Document these users and adjust the rule to exclude their activities by user ID or group ID.
+- Training or testing environments where users are encouraged to experiment with container configurations might trigger false positives. Implement a separate monitoring policy for these environments to reduce noise in production alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system.
+- Terminate any suspicious container processes identified by the detection rule to halt any ongoing privilege escalation attempts.
+- Conduct a thorough review of container configurations and permissions, specifically focusing on the use of runc and ctr utilities, to identify and rectify any misconfigurations that allow non-root users to execute privileged operations.
+- Implement strict access controls and enforce the principle of least privilege for container management utilities to ensure only authorized users can execute privileged commands.
+- Monitor for any additional signs of compromise or unusual activity on the host system, particularly focusing on processes initiated by non-root users with elevated privileges.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment.
+- Update and enhance detection capabilities to include additional indicators of compromise related to container misconfigurations and privilege escalation attempts, ensuring timely alerts for similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_dac_permissions.toml b/rules/linux/privilege_escalation_dac_permissions.toml
index 3cf2729319a..ba4a168dd39 100644
--- a/rules/linux/privilege_escalation_dac_permissions.toml
+++ b/rules/linux/privilege_escalation_dac_permissions.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,41 @@ process.command_line:(*sudoers* or *passwd* or *shadow* or */root/*) and not (
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via Linux DAC permissions
+
+Linux Discretionary Access Control (DAC) allows file owners to set permissions, potentially leading to privilege escalation if misconfigured. Adversaries exploit DAC by using processes with capabilities like CAP_DAC_OVERRIDE to bypass permission checks. The detection rule identifies suspicious processes accessing sensitive files, excluding benign activities, to flag potential misuse of DAC permissions.
+
+### Possible investigation steps
+
+- Review the process command line to identify the specific command executed and determine if it involves sensitive files like sudoers, passwd, shadow, or directories under /root/.
+- Check the user ID associated with the process to verify if it is a non-root user attempting to access or modify sensitive files.
+- Investigate the process name and executable path to ensure it is not part of the excluded benign processes or paths, such as tar, getent, or /usr/lib/*/lxc/rootfs/*.
+- Analyze the parent process name to determine if it is a known benign parent like dpkg or gnome-shell, which might indicate a legitimate operation.
+- Examine the process thread capabilities, specifically CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH, to understand the level of access the process has and assess if it aligns with expected behavior for the user or application.
+- Correlate the event with other logs or alerts to identify any patterns or sequences of activities that might indicate a broader attack or misconfiguration issue.
+
+### False positive analysis
+
+- Processes like "tar", "getent", "su", and others listed in the rule are known to perform legitimate operations on sensitive files. Exclude these processes from triggering alerts by adding them to the exception list in the detection rule.
+- System management tools such as "dpkg" and "podman" may access sensitive files during routine operations. Consider excluding these tools if they are part of regular system maintenance activities.
+- Processes running under user ID "0" (root) are often legitimate and necessary for system operations. Ensure that these are excluded from alerts to avoid unnecessary noise.
+- Executables located in paths like /usr/lib/*/lxc/rootfs/* are typically part of containerized environments and may not pose a threat. Exclude these paths if they are part of your standard infrastructure.
+- Parent processes such as "java" or those with names ending in "postinst" may be involved in legitimate software installations or updates. Review and exclude these if they are part of expected system behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, especially those with CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH capabilities accessing sensitive files.
+- Conduct a thorough review of the affected system's user accounts and permissions to identify and revoke any unauthorized privilege escalations.
+- Restore any modified or compromised sensitive files, such as /etc/passwd or /etc/shadow, from a known good backup.
+- Implement additional monitoring on the affected system to detect any further attempts at privilege escalation or unauthorized access.
+- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and potential impact.
+- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could be exploited for privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
index ea2de502b4b..1b74bc06fb3 100644
--- a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
+++ b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/10"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,41 @@ process where host.os.type == "linux" and event.type == "change" and event.actio
 process.entry_leader.entry_meta.type == "container" and process.args == "nsenter" and
 process.args in ("-t", "--target") and process.args_count >= 4
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Docker Escape via Nsenter
+
+Docker containers use namespaces to isolate processes, ensuring they operate independently from the host system. The `nsenter` command allows users to access these namespaces, which is essential for managing containerized environments. However, adversaries can exploit `nsenter` to break out of a container, gaining unauthorized access to the host system. The detection rule identifies suspicious UID changes involving `nsenter`, signaling potential container escapes and privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a UID change event involving the nsenter command, as indicated by the query fields.
+- Identify the container from which the nsenter command was executed by examining the process.entry_leader.entry_meta.type field.
+- Investigate the process arguments to verify the use of nsenter with the -t or --target options, ensuring the process.args_count is 4 or more, which may indicate an attempt to target a specific namespace.
+- Check the user and process context before and after the UID change to understand the potential impact and scope of the privilege escalation.
+- Analyze the container's logs and any associated host logs around the time of the event to gather additional context and identify any suspicious activities or patterns.
+- Assess the container's configuration and security settings to determine if there are any vulnerabilities or misconfigurations that could have been exploited.
+- If unauthorized access is confirmed, initiate incident response procedures to contain and remediate the threat, including reviewing other containers and systems for similar activities.
+
+### False positive analysis
+
+- Routine administrative tasks using nsenter can trigger false positives, especially when system administrators use it for legitimate container management. To mitigate this, create exceptions for known administrative scripts or processes that frequently use nsenter.
+- Automated monitoring tools or scripts that perform health checks or maintenance on containers might use nsenter, leading to false alerts. Identify these tools and whitelist their specific processes or user accounts to reduce noise.
+- Development environments where developers frequently enter containers for debugging purposes can cause false positives. Consider excluding specific development user accounts or container IDs from the rule to prevent unnecessary alerts.
+- Continuous integration and deployment pipelines that interact with containers might use nsenter as part of their operations. Review these pipelines and exclude their associated processes or user accounts to avoid false detections.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access to the host system. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the container's logs and processes to identify any unauthorized changes or suspicious activities that occurred before and after the UID change event.
+- Revoke any unauthorized access or credentials that may have been compromised during the container escape attempt. Ensure that all access keys and passwords are rotated.
+- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. Ensure that the latest security updates are applied.
+- Implement stricter namespace and capability restrictions for containers to minimize the risk of privilege escalation. Consider using security tools like AppArmor or SELinux to enforce these restrictions.
+- Monitor for any further suspicious activity on the host system and other containers, focusing on similar UID change events or unauthorized use of `nsenter`.
+- Escalate the incident to the security operations team for a comprehensive investigation and to assess the potential impact on the broader network and systems."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
index fac9264d2f0..3f263b94bf4 100644
--- a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
+++ b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,41 @@ sequence by host.id, process.parent.entity_id with maxspan=5m
   [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.name == "chroot"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Chroot Container Escape via Mount
+
+Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved.
+- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes.
+- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks.
+- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations.
+- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior.
+- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule.
+- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users.
+- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users.
+- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe.
+- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system.
+- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts.
+- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits.
+- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity.
+- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure.
+- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape.
+- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_enlightenment_window_manager.toml b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
index facebb25242..b9bd1974e83 100644
--- a/rules/linux/privilege_escalation_enlightenment_window_manager.toml
+++ b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ sequence by host.id, process.parent.entity_id with maxspan=5s
     process.name == "enlightenment_sys" and process.args in ("/bin/mount/", "-o","noexec","nosuid","nodev","uid=*") ]
   [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via Enlightenment
+
+Enlightenment, a Linux window manager, can be exploited for privilege escalation due to a flaw in its setuid root configuration. Attackers may exploit this by manipulating pathnames, gaining unauthorized root access. The detection rule identifies suspicious execution of 'enlightenment_sys' with specific arguments and subsequent UID changes to root, flagging potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the process "enlightenment_sys" with the specified arguments ("/bin/mount/", "-o", "noexec", "nosuid", "nodev", "uid=*") on a Linux host.
+- Check the process execution timeline to verify if the suspicious "enlightenment_sys" execution was followed by a UID change to root (user.id == "0") within a 5-second window.
+- Investigate the host.id and process.parent.entity_id to identify the parent process and determine if it was initiated by a legitimate user or service.
+- Examine the system logs around the time of the alert to identify any other unusual activities or related processes that might indicate a broader attack or exploitation attempt.
+- Assess the affected system for any unauthorized changes or signs of compromise, focusing on privilege escalation indicators and potential persistence mechanisms.
+- Review user access logs and permissions to determine if the user associated with the process had legitimate reasons to execute "enlightenment_sys" with elevated privileges.
+- Consider isolating the affected system to prevent further exploitation and begin remediation steps, such as applying patches or configuration changes to mitigate the vulnerability.
+
+### False positive analysis
+
+- Legitimate administrative tasks using enlightenment_sys may trigger the rule. Review the context of the execution, such as the user and the specific arguments used, to determine if the activity is authorized.
+- Automated scripts or system maintenance processes that involve enlightenment_sys with similar arguments might be flagged. Identify these scripts and consider excluding them by specifying their process hashes or paths in the detection rule.
+- System updates or package installations that temporarily change UID to root could be misinterpreted as exploitation attempts. Monitor these activities and whitelist known update processes to prevent false alerts.
+- Custom user applications that interact with enlightenment_sys for legitimate purposes may cause false positives. Evaluate these applications and, if deemed safe, add them to an exception list based on their unique identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes related to 'enlightenment_sys' that are running with elevated privileges to stop ongoing exploitation.
+- Conduct a thorough review of system logs to identify any unauthorized changes or access patterns, focusing on UID changes to root.
+- Revoke any unauthorized access or privileges granted during the exploitation, ensuring that only legitimate users have root access.
+- Apply the latest security patches and updates to the Enlightenment package, specifically upgrading to version 0.25.4 or later to mitigate the vulnerability.
+- Implement file integrity monitoring to detect unauthorized changes to critical system files and configurations in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
index 10697c46f3a..0c7533b9bd6 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,41 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=1m
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.name != null and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privilege Escalation via GDB CAP_SYS_PTRACE
+
+The CAP_SYS_PTRACE capability in Linux allows processes to trace and control other processes, a feature primarily used for debugging. Adversaries can exploit this by using GDB with this capability to inject code into processes running as root, thereby escalating privileges. The detection rule identifies such abuse by monitoring sequences where GDB is executed with CAP_SYS_PTRACE, followed by a process running as root, indicating potential privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process entity ID where the GDB execution with CAP_SYS_PTRACE was detected.
+- Examine the process tree on the affected host to determine the parent process of GDB and any child processes it may have spawned, focusing on any processes running as root.
+- Check the user account associated with the GDB execution to verify if it is a legitimate user and assess if there are any indications of compromise or misuse.
+- Investigate the timeline of events around the alert to identify any preceding or subsequent suspicious activities, such as unauthorized access attempts or changes in user privileges.
+- Analyze system logs and audit records for any signs of unauthorized access or privilege escalation attempts, particularly focusing on the time window specified by the maxspan of 1 minute in the query.
+- Correlate the findings with other security alerts or incidents on the same host to determine if this event is part of a larger attack campaign.
+
+### False positive analysis
+
+- Development environments where GDB is frequently used for legitimate debugging purposes may trigger false positives. To mitigate this, consider excluding specific user accounts or processes that are known to use GDB regularly for debugging.
+- Automated testing systems that utilize GDB for testing applications with elevated privileges might be flagged. Implement exceptions for these systems by identifying and excluding their specific process names or user IDs.
+- Security tools or monitoring solutions that use GDB with CAP_SYS_PTRACE for legitimate monitoring or analysis tasks can cause false alerts. Review and whitelist these tools by their process names or associated user accounts.
+- System administrators or developers who have legitimate reasons to use GDB with elevated capabilities should be identified, and their activities should be excluded from the rule to prevent unnecessary alerts.
+- Scheduled maintenance scripts that involve GDB for system diagnostics or performance tuning may be misinterpreted as malicious. Exclude these scripts by their execution schedule or specific identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified as running with elevated privileges, especially those involving GDB with CAP_SYS_PTRACE.
+- Revoke CAP_SYS_PTRACE capability from non-essential users and processes to limit potential abuse.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized privilege escalations have occurred.
+- Restore the affected system from a known good backup if any unauthorized changes or code injections are detected.
+- Monitor the affected and related systems for any signs of persistence mechanisms or further malicious activity.
+- Report the incident to the appropriate internal security team or authority for further investigation and potential escalation if necessary."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
index 68dcaefd123..e747f01af6f 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,41 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=30s
   [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
    process.name != null and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Root Network Connection via GDB CAP_SYS_PTRACE
+
+GDB, a debugger, can be granted the CAP_SYS_PTRACE capability, allowing it to trace and control processes, a feature often exploited by attackers. By injecting code into root processes, adversaries can execute malicious payloads, such as reverse shells. The detection rule identifies suspicious sequences where GDB is used with this capability, followed by a root-initiated network connection, signaling potential privilege escalation or command and control activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of GDB with CAP_SYS_PTRACE capability by examining the process name, capabilities, and user ID fields in the alert.
+- Investigate the network connection attempt by analyzing the process name and user ID fields to determine if the connection was initiated by a root process.
+- Check the timeline of events to ensure the sequence of GDB execution followed by a network connection attempt occurred within the specified maxspan of 30 seconds.
+- Identify the destination IP address and port of the network connection to assess if it is known for malicious activity or associated with command and control servers.
+- Examine the host system for any signs of compromise or unauthorized changes, focusing on processes and files that may have been affected by the potential privilege escalation.
+- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that may indicate a broader attack.
+
+### False positive analysis
+
+- Development environments may trigger this rule when developers use GDB with CAP_SYS_PTRACE for legitimate debugging purposes. To mitigate, create exceptions for specific user IDs or processes known to be involved in development activities.
+- Automated testing frameworks that utilize GDB for testing applications with root privileges can cause false positives. Identify and exclude these processes or testing environments from the rule.
+- System maintenance scripts that require debugging of root processes might inadvertently match the rule criteria. Review and whitelist these scripts or the specific time frames they run to prevent unnecessary alerts.
+- Security tools that perform legitimate process tracing as part of their monitoring activities could be mistaken for malicious behavior. Ensure these tools are recognized and excluded from the detection rule.
+- Custom administrative scripts that use GDB for process management under root privileges should be documented and excluded to avoid false alarms.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
+- Terminate any suspicious processes associated with GDB that have been granted the CAP_SYS_PTRACE capability, especially those initiated by non-root users.
+- Conduct a thorough review of the affected system's logs to identify any unauthorized changes or additional malicious activities that may have occurred.
+- Reset credentials and review permissions for any accounts that may have been compromised, particularly those with elevated privileges.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network monitoring to detect and block any further unauthorized outbound connections from root processes.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_kworker_uid_elevation.toml b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
index f17fb467fd1..0fcddb3fbe2 100644
--- a/rules/linux/privilege_escalation_kworker_uid_elevation.toml
+++ b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,39 @@ query = '''
 process where host.os.type == "linux" and event.action == "session_id_change" and process.name : "kworker*" and
 user.id == "0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Kworker UID Elevation
+
+Kworker processes are integral to Linux, handling tasks like interrupts and background activities within the kernel. Adversaries may exploit these processes by disguising malicious activities as legitimate kernel operations, often using rootkits to hijack execution flow and gain root access. The detection rule identifies anomalies by monitoring for kworker processes that unexpectedly change session IDs and elevate privileges to root, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the process details for the kworker process with a session ID change and user ID of 0 to confirm the legitimacy of the process and its parent process.
+- Check the system logs around the time of the session ID change event for any unusual activities or errors that might indicate tampering or exploitation attempts.
+- Investigate any recent changes to the system, such as new software installations or updates, that could have introduced vulnerabilities or unauthorized modifications.
+- Analyze the system for signs of rootkit presence, such as hidden files or processes, by using rootkit detection tools or manual inspection techniques.
+- Correlate the event with other security alerts or anomalies in the network to determine if this is part of a broader attack campaign or isolated incident.
+
+### False positive analysis
+
+- Regular system updates or maintenance activities may trigger session ID changes in kworker processes. Users can monitor scheduled maintenance windows and exclude these time frames from triggering alerts.
+- Custom kernel modules or legitimate software that interacts with kernel processes might cause kworker to change session IDs. Identify and whitelist these known modules or software to prevent false positives.
+- Automated scripts or tools that require elevated privileges for legitimate tasks could inadvertently cause kworker processes to appear suspicious. Review and document these scripts, then create exceptions for their expected behavior.
+- Certain system configurations or optimizations might lead to benign kworker session ID changes. Conduct a baseline analysis of normal system behavior and adjust the detection rule to accommodate these patterns without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate the suspicious kworker process identified in the alert to stop any ongoing malicious activity.
+- Conduct a thorough review of system logs and process trees to identify any additional compromised processes or indicators of rootkit installation.
+- Restore the system from a known good backup if rootkit presence is confirmed, as rootkits can deeply embed themselves into the system.
+- Change all credentials and keys that may have been exposed or used on the compromised system to prevent unauthorized access using stolen credentials.
+- Implement enhanced monitoring and logging for kworker processes and session ID changes to detect similar activities in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
index c1188e26d75..91ca9f05d23 100644
--- a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
+++ b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,41 @@ query = '''
 host.os.type:linux and event.category:file and event.action:(updated or renamed or rename or file_rename_event) and 
 not event.type:deletion and file.path:/etc/ld.so.preload and not process.name:(wine or oneagentinstallaction)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Dynamic Linker Preload Shared Object
+
+The dynamic linker preload mechanism in Linux, via `/etc/ld.so.preload`, allows preloading of shared libraries, influencing how executables load dependencies. Adversaries exploit this by inserting malicious libraries, hijacking execution flow for privilege escalation. The detection rule monitors changes to this file, excluding benign processes, to identify unauthorized modifications indicative of such abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is /etc/ld.so.preload and verify the event action is one of the specified actions: updated, renamed, or file_rename_event.
+- Identify the process responsible for the modification by examining the process.name field, ensuring it is not one of the excluded processes (wine or oneagentinstallaction).
+- Investigate the process that triggered the alert by gathering additional context such as process ID, command line arguments, and parent process to understand its origin and purpose.
+- Check the modification timestamp and correlate it with other system events or logs to identify any suspicious activity or patterns around the time of the modification.
+- Analyze the contents of /etc/ld.so.preload to determine if any unauthorized or suspicious libraries have been added, and assess their potential impact on the system.
+- Review user accounts and permissions associated with the process to determine if there has been any unauthorized access or privilege escalation attempt.
+- If malicious activity is confirmed, isolate the affected system and follow incident response procedures to mitigate the threat and prevent further exploitation.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify /etc/ld.so.preload. To handle this, monitor the process names associated with these activities and consider adding them to the exclusion list if they are verified as benign.
+- System management tools like configuration management software might update /etc/ld.so.preload as part of routine operations. Identify these tools and exclude their process names from the detection rule to prevent false alerts.
+- Custom scripts or administrative tasks executed by trusted users could inadvertently trigger the rule. Review these scripts and, if necessary, exclude their process names or user accounts from the detection criteria.
+- Security agents or monitoring tools that interact with system files might cause false positives. Verify these tools' activities and exclude their process names if they are known to be safe and necessary for system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious processes that are not part of the baseline or known benign applications, especially those related to the modification of `/etc/ld.so.preload`.
+- Restore the `/etc/ld.so.preload` file from a known good backup to ensure no malicious libraries are preloaded.
+- Conduct a thorough review of recent system changes and installed packages to identify any unauthorized software or modifications that may have facilitated the attack.
+- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any additional affected systems.
+- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify the dynamic linker preload file.
+- Review and enhance access controls and permissions on critical system files like `/etc/ld.so.preload` to prevent unauthorized modifications in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
index f1192e1a86d..a2a5a3ec4f0 100644
--- a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
+++ b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/30"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,41 @@ process.name == "ln" and process.args in ("-s", "-sf") and
   process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
   not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Symbolic Link Created
+
+Symbolic links in Linux are shortcuts that point to files or directories, facilitating easy access. Adversaries may exploit these links to redirect privileged processes to sensitive files, potentially escalating privileges or accessing restricted data. The detection rule identifies suspicious link creation by monitoring the execution of the 'ln' command with specific arguments and targets, especially when initiated by non-root users, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of the 'ln' command with suspicious arguments such as "-s" or "-sf" and verify the target files or directories listed in the query, like "/etc/shadow" or "/bin/bash".
+- Check the user and group IDs associated with the process to ensure they are not root (ID "0"), as the rule specifically targets non-root users.
+- Investigate the parent process name to determine if it is one of the shell processes listed in the query, such as "bash" or "zsh", which might indicate a user-initiated action.
+- Examine the working directory and arguments to identify if the symbolic link creation is targeting sensitive locations like "/etc/cron.d/*" or "/home/*/.ssh/*".
+- Analyze the user's recent activity and command history to understand the context and intent behind the symbolic link creation.
+- Correlate this event with other security alerts or logs to identify any patterns or additional suspicious activities involving the same user or system.
+
+### False positive analysis
+
+- Non-root users creating symbolic links for legitimate administrative tasks may trigger the rule. To manage this, identify and whitelist specific users or groups who regularly perform these tasks without malicious intent.
+- Automated scripts or applications that use symbolic links for configuration management or software deployment might be flagged. Review these processes and exclude them by specifying the script or application names in the detection rule.
+- Development environments where symbolic links are used to manage dependencies or version control can cause false positives. Exclude directories or processes associated with these environments to prevent unnecessary alerts.
+- Backup or synchronization tools that create symbolic links as part of their operation may be mistakenly identified. Identify these tools and add exceptions for their typical execution patterns.
+- System maintenance activities that involve symbolic link creation, such as linking to shared libraries or binaries, should be reviewed and excluded if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker.
+- Terminate any suspicious processes related to the 'ln' command that are identified in the alert to stop any ongoing malicious activity.
+- Conduct a thorough review of the symbolic links created, especially those pointing to sensitive files or directories, and remove any unauthorized or suspicious links.
+- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack, focusing on those with elevated privileges.
+- Restore any altered or compromised files from a known good backup to ensure system integrity and prevent further exploitation.
+- Implement additional monitoring and logging for symbolic link creation and other related activities to detect similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
index d628bd94d5b..2eb616dc5c8 100644
--- a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
+++ b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,40 @@ process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "ProcessRollup2") and
   process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via UID INT_MAX Bug Detected
+
+In certain Linux environments, systemd-run is a utility that allows users to create and start a transient service or scope unit. A bug in older Linux versions permits users with a UID exceeding INT_MAX to exploit this utility for privilege escalation, potentially gaining unauthorized access. The detection rule identifies suspicious executions of systemd-run by monitoring for processes initiated by users with unusually high UIDs, signaling potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a user with a UID greater than INT_MAX, as indicated by the user.id field in the query.
+- Examine the process execution context, including the process.args and process.args_count fields, to verify the use of systemd-run with the specified arguments, which may indicate an exploitation attempt.
+- Check the system logs for any other suspicious activities or anomalies around the time of the alert, focusing on processes initiated by the same user or related to systemd-run.
+- Investigate the history and purpose of the user account with the high UID to determine if it was intentionally created or if it appears to be an anomaly.
+- Assess the affected system's Linux version to determine if it is one of the older versions known to be vulnerable to this bug, and consider updating or patching if necessary.
+- Look for any additional indicators of compromise or privilege escalation attempts on the system, such as unauthorized access to sensitive files or changes in user permissions.
+
+### False positive analysis
+
+- High UID service accounts: Some legitimate service accounts may have UIDs exceeding INT_MAX for specific operational purposes. Review these accounts and, if verified as non-threatening, add them to an exception list to prevent unnecessary alerts.
+- Custom scripts or automation tools: Organizations may use scripts or tools that invoke systemd-run with high UID accounts for legitimate tasks. Identify these scripts and whitelist their execution paths or specific user IDs to reduce false positives.
+- Testing environments: In testing or development environments, users might intentionally create accounts with high UIDs to test system behavior. Ensure these environments are isolated and consider excluding them from monitoring to avoid false alerts.
+- Legacy systems: Older systems might have configurations that inadvertently trigger this rule. Conduct a thorough review of these systems and apply exceptions where the behavior is deemed safe and necessary for operational continuity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes initiated by users with UIDs exceeding INT_MAX, especially those involving systemd-run, to halt potential privilege escalation.
+- Conduct a thorough review of user accounts on the affected system to identify and disable any accounts with UIDs greater than INT_MAX.
+- Apply available patches or updates to the Linux operating system to address the specific bug related to UID handling in systemd-run.
+- Review and adjust user account creation policies to ensure no new accounts are created with UIDs exceeding the standard range.
+- Monitor for any further attempts to exploit this vulnerability by setting up alerts for similar suspicious activities, focusing on high UID values and systemd-run usage.
+- Report the incident to the appropriate internal security team or external authorities if necessary, providing details of the exploit and actions taken."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
index 57cab49ea6a..825eaad5774 100644
--- a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
+++ b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,41 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name == "kexec" and process.args in ("--exec", "-e", "--load", "-l", "--unload", "-u") and
   not process.parent.name in ("kdumpctl", "unload.sh")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kernel Load or Unload via Kexec Detected
+
+Kexec is a Linux feature allowing a new kernel to load without rebooting, streamlining updates and recovery. However, attackers can exploit kexec to bypass security, escalate privileges, or hide activities by loading malicious kernels. The detection rule identifies suspicious kexec usage by monitoring process actions and arguments, excluding benign parent processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of the kexec command with suspicious arguments such as "--exec", "-e", "--load", "-l", "--unload", or "-u".
+- Investigate the parent process of the kexec command to ensure it is not a benign process like "kdumpctl" or "unload.sh", which are excluded from the detection rule.
+- Check the user account associated with the kexec process to determine if it has the necessary privileges and if the activity aligns with their typical behavior.
+- Analyze recent system logs and security events for any signs of privilege escalation or unauthorized kernel modifications around the time the kexec command was executed.
+- Examine the system for any signs of persistence mechanisms or other indicators of compromise that may suggest a broader attack campaign.
+- Correlate this event with other alerts or anomalies in the environment to assess if this is part of a larger attack pattern or isolated incident.
+
+### False positive analysis
+
+- Kdump operations may trigger false positives as kdumpctl is a benign parent process for kexec. Ensure kdumpctl is included in the exclusion list to prevent unnecessary alerts.
+- Custom scripts for kernel unloading, such as unload.sh, can cause false positives. Verify these scripts are legitimate and add them to the exclusion list if they are frequently used in your environment.
+- Routine administrative tasks involving kernel updates or testing may involve kexec. Confirm these activities are authorized and consider excluding specific administrative accounts or processes from detection.
+- Automated system recovery processes that utilize kexec might be flagged. Identify these processes and exclude them if they are part of a known and secure recovery mechanism.
+- Security tools or monitoring solutions that use kexec for legitimate purposes should be reviewed and excluded to avoid false alerts, ensuring they are recognized as trusted applications.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker.
+- Terminate any suspicious kexec processes identified by the detection rule to halt any ongoing malicious kernel loading activities.
+- Conduct a thorough review of system logs and process histories to identify any unauthorized kernel loads or modifications, and revert to a known good state if necessary.
+- Restore the system from a clean backup taken before the suspicious activity was detected to ensure system integrity and remove any potential backdoors or malicious kernels.
+- Update and patch the system to the latest security standards to mitigate any vulnerabilities that could be exploited by similar attacks in the future.
+- Implement strict access controls and monitoring on systems with kexec capabilities to prevent unauthorized usage and ensure only trusted personnel can perform kernel operations.
+- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
index 75d12aa5a97..21c1ee0eebb 100644
--- a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
+++ b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,41 @@ sequence by host.id, process.parent.entity_id, process.executable with maxspan=5
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
   process.env_vars : "*GLIBC_TUNABLES=glibc.*=glibc.*=*"] with runs=5
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via CVE-2023-4911
+
+CVE-2023-4911 exploits a buffer overflow in the GNU C Library's dynamic loader, specifically targeting the GLIBC_TUNABLES environment variable. Adversaries can manipulate this to gain elevated privileges on Linux systems. The detection rule identifies suspicious activity by monitoring processes with specific environment variables, flagging repeated execution attempts within a short timeframe, indicating potential exploitation efforts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity.
+- Examine the process.executable path to determine if it is a legitimate application or potentially malicious.
+- Check the process.env_vars for any unusual or unexpected GLIBC_TUNABLES values that could indicate manipulation attempts.
+- Investigate the host's recent process execution history to identify any patterns or anomalies, focusing on processes with the GLIBC_TUNABLES environment variable set.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
+- Assess the system for any signs of privilege escalation or unauthorized access, such as new user accounts or changes in user privileges.
+
+### False positive analysis
+
+- Frequent legitimate use of GLIBC_TUNABLES environment variable by system administrators or automated scripts can trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts.
+- Some Linux distributions or specific applications may use GLIBC_TUNABLES for performance tuning or compatibility reasons. Review and document these cases, and create exceptions for these processes to avoid false alarms.
+- Development environments where GLIBC_TUNABLES is used for testing purposes might also cause false positives. Implement a policy to exclude these environments from monitoring or adjust the rule to account for these specific use cases.
+- Scheduled tasks or cron jobs that utilize GLIBC_TUNABLES for legitimate purposes can be mistaken for exploitation attempts. Ensure these tasks are recognized and excluded from the rule's scope to reduce noise.
+- If a particular user or group frequently triggers the rule due to their role or activities, consider creating a user-based exception to minimize false positives while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious processes identified with the GLIBC_TUNABLES environment variable to halt ongoing exploitation attempts.
+- Apply the latest security patches and updates to the GNU C Library on all affected systems to remediate the buffer overflow vulnerability.
+- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or additional indicators of compromise.
+- Restore affected systems from a known good backup taken before the exploitation attempt, ensuring that the backup is free from any malicious modifications.
+- Implement enhanced monitoring and alerting for unusual process executions and environment variable manipulations to detect similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
index 19d9e7e5aa4..ad16310ddfe 100644
--- a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
+++ b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,39 @@ event.action in ("connection_attempted", "ipv4_connection_attempt_event") and pr
   )
 ) 
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Connection via Sudo Binary
+
+The 'sudo' command in Linux allows users to execute commands with elevated privileges, typically as the root user. Adversaries may exploit this by injecting malicious shellcode into processes running with these privileges, potentially establishing unauthorized network connections. The detection rule identifies unusual network activity initiated by 'sudo', excluding common internal IP ranges, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific destination IP address involved in the network connection attempt. Cross-reference this IP with known malicious IP databases or threat intelligence sources to assess potential risk.
+- Examine the process tree and command line arguments associated with the 'sudo' process to determine if there are any unusual or unexpected commands being executed that could indicate malicious activity.
+- Check the user account that initiated the 'sudo' command to verify if it is a legitimate user and if there have been any recent changes to user permissions or roles that could explain the activity.
+- Investigate any recent login attempts or authentication logs for the user account involved to identify any suspicious access patterns or failed login attempts that could suggest a compromised account.
+- Analyze network traffic logs around the time of the alert to identify any other unusual outbound connections or data exfiltration attempts that may correlate with the 'sudo' network connection event.
+
+### False positive analysis
+
+- Internal network monitoring tools may trigger this rule if they use the sudo command to initiate legitimate network connections. To handle this, identify the specific tools and processes involved and create exceptions for their known IP addresses.
+- Automated scripts or cron jobs running with elevated privileges might occasionally establish network connections for updates or data transfers. Review these scripts and whitelist their expected behavior to prevent false positives.
+- System administrators using sudo for remote management tasks could inadvertently trigger the rule. Document and exclude the IP addresses and processes associated with routine administrative tasks.
+- Security software or agents that require elevated permissions to perform network diagnostics or reporting may cause alerts. Verify these applications and add them to an exception list if they are deemed safe and necessary for operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes associated with the 'sudo' command that are attempting to establish network connections.
+- Conduct a thorough review of system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts.
+- Reset credentials for any accounts that may have been compromised, particularly those with elevated privileges.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
index a62129ec619..6a3b3f4f2e0 100644
--- a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
+++ b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,41 @@ sequence by process.parent.entity_id, host.id with maxspan=5s
   [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
     user.id == "0"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via OverlayFS
+
+OverlayFS is a union filesystem used in Linux environments to overlay one filesystem on top of another, allowing for efficient file management and updates. Adversaries exploit vulnerabilities in Ubuntu's OverlayFS modifications to execute crafted executables that escalate privileges to root. The detection rule identifies suspicious sequences involving the 'unshare' command with specific arguments and subsequent UID changes to root, indicating potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'unshare' command with the specific arguments '-r', '-rm', 'm', and '*cap_setuid*' as indicated in the query. This will help verify if the command execution aligns with the known exploitation pattern.
+- Check the process tree and parent process information using the process.parent.entity_id to understand the context in which the 'unshare' command was executed. This can provide insights into whether the command was part of a legitimate operation or a potential attack.
+- Investigate the user account associated with the process execution (user.id != "0") to determine if the account has a history of suspicious activity or if it has been compromised.
+- Examine the host.id and host.os.type fields to identify the specific Linux host involved and assess its vulnerability status regarding CVE-2023-2640 and CVE-2023-32629. This can help determine if the host is susceptible to the exploitation attempt.
+- Analyze any subsequent UID changes to root (user.id == "0") to confirm if the privilege escalation was successful and identify any unauthorized access or actions taken by the elevated process.
+- Review system logs and other security alerts around the time of the event to identify any additional indicators of compromise or related suspicious activities that might corroborate the exploitation attempt.
+
+### False positive analysis
+
+- Legitimate administrative tasks using the 'unshare' command with similar arguments may trigger the rule. Review the context of the command execution and verify if it aligns with routine system maintenance or configuration changes.
+- Automated scripts or system management tools that utilize 'unshare' for containerization or namespace isolation might cause false positives. Identify these scripts and consider excluding their specific process names or paths from the rule.
+- Development environments where developers frequently test applications with elevated privileges could inadvertently match the rule criteria. Implement user-based exceptions for known developer accounts to reduce noise.
+- Security tools or monitoring solutions that simulate privilege escalation scenarios for testing purposes may be flagged. Whitelist these tools by their process hash or signature to prevent unnecessary alerts.
+- Custom applications that require temporary privilege elevation for legitimate operations should be reviewed. If deemed safe, add these applications to an exception list based on their unique identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'unshare' command with the specified arguments.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized changes have been made, especially focusing on accounts with root access.
+- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2023-2640 and CVE-2023-32629, to mitigate the vulnerability in OverlayFS.
+- Monitor for any further attempts to exploit the vulnerability by setting up alerts for similar sequences of commands and UID changes.
+- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and impact of the exploitation attempt.
+- Implement additional security measures, such as enhanced logging and monitoring, to detect and respond to privilege escalation attempts more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
index 6b29e1b8b63..3435ff3037b 100644
--- a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
+++ b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ type = "eql"
 query = '''
 file where host.os.type == "linux" and file.path : "/*GCONV_PATH*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via PKEXEC
+
+Polkit's pkexec is a command-line utility that allows an authorized user to execute commands as another user, typically root, in Linux environments. Adversaries exploit vulnerabilities like CVE-2021-4034 by injecting unsecure environment variables, enabling unauthorized privilege escalation. The detection rule identifies suspicious file paths indicative of such exploitation attempts, focusing on environment variable manipulation to preemptively flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the file path pattern "/*GCONV_PATH*" on a Linux host, as this is indicative of the potential exploitation attempt.
+- Examine the process execution history on the affected host to identify any instances of pkexec being executed around the time of the alert. Look for unusual or unauthorized command executions.
+- Check the environment variables set during the pkexec execution to identify any suspicious or unauthorized modifications that could indicate an exploitation attempt.
+- Investigate the user account associated with the alert to determine if it has a history of privilege escalation attempts or other suspicious activities.
+- Analyze system logs and security events for any additional indicators of compromise or related suspicious activities that occurred before or after the alert.
+- Assess the patch status of the affected system to determine if it is vulnerable to CVE-2021-4034 and ensure that appropriate security updates have been applied.
+
+### False positive analysis
+
+- Routine administrative tasks involving pkexec may trigger alerts if they involve environment variable manipulation. Review the context of the command execution to determine if it aligns with expected administrative behavior.
+- Custom scripts or applications that legitimately use environment variables in their execution paths might be flagged. Identify these scripts and consider adding them to an exception list if they are verified as non-threatening.
+- Automated system management tools that modify environment variables for legitimate purposes could cause false positives. Monitor these tools and exclude their known safe operations from the detection rule.
+- Development environments where developers frequently test applications with varying environment variables might generate alerts. Establish a baseline of normal activity and exclude these patterns if they are consistent and verified as safe.
+- Scheduled tasks or cron jobs that involve environment variable changes should be reviewed. If they are part of regular system maintenance, document and exclude them from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker.
+- Terminate any suspicious processes associated with pkexec or unauthorized privilege escalation attempts to halt ongoing exploitation.
+- Conduct a thorough review of system logs and file access records to identify any unauthorized changes or access patterns, focusing on the presence of GCONV_PATH in file paths.
+- Revert any unauthorized changes made by the attacker, such as modifications to critical system files or configurations, to restore system integrity.
+- Apply the latest security patches and updates to the polkit package to address CVE-2021-4034 and prevent future exploitation.
+- Implement enhanced monitoring and alerting for similar privilege escalation attempts, ensuring that any future attempts are detected and responded to promptly.
+- Report the incident to relevant internal security teams and, if necessary, escalate to external authorities or cybersecurity partners for further investigation and support."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
index d0bdbf799f4..022e3639240 100644
--- a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
+++ b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/11"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,42 @@ type = "threshold"
 query = '''
 kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.type:linux and event.kind:signal
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Buffer Overflow Attack Detected
+
+Buffer overflow attacks exploit vulnerabilities in software to execute arbitrary code, often leading to privilege escalation. Adversaries may trigger numerous segmentation faults (segfaults) on Linux systems as they attempt to exploit these vulnerabilities. The detection rule identifies potential attacks by monitoring for a surge in segfault alerts, indicating possible exploitation attempts, and correlates them with known threat tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a surge in segfault alerts, focusing on the host.os.type:linux field to ensure the affected systems are Linux-based.
+- Correlate the timestamps of the segfault alerts to identify any patterns or specific timeframes when the surge occurred, which might indicate the start of an exploitation attempt.
+- Investigate the affected host(s) by examining system logs and application logs around the time of the segfault alerts to identify any suspicious activities or anomalies.
+- Check for any recent changes or updates to the software running on the affected host(s) that might have introduced vulnerabilities.
+- Look for any known vulnerabilities or exploits associated with the software or services running on the affected host(s) that could be targeted by a buffer overflow attack.
+- Assess the network traffic to and from the affected host(s) during the time of the alerts to identify any unusual or unauthorized connections that could indicate an attack vector.
+- Consult threat intelligence sources to determine if there are any ongoing campaigns or known threat actors targeting similar vulnerabilities or systems.
+
+### False positive analysis
+
+- High-volume legitimate application crashes can trigger false positives, especially during software testing or development phases. Users should identify and exclude these applications from the rule by creating exceptions for specific processes known to cause frequent segfaults without malicious intent.
+- System updates or patches may cause temporary spikes in segfault alerts as applications restart or reconfigure. Users can mitigate this by setting a temporary exception during scheduled maintenance windows.
+- Custom scripts or automated tasks that interact with system memory in non-standard ways might generate segfaults. Review these scripts and, if verified as safe, exclude them from the rule to prevent false alerts.
+- Certain security tools or monitoring software may intentionally cause segfaults as part of their operation. Identify these tools and add them to the exception list to avoid unnecessary alerts.
+- Legacy applications with known stability issues might frequently cause segfaults. Consider updating or replacing these applications, or create exceptions if updates are not feasible.
+
+### Response and remediation
+
+- Isolate the affected Linux host immediately to prevent further exploitation and lateral movement within the network.
+- Terminate any suspicious processes identified on the affected host that are associated with the segfault alerts to halt potential malicious activity.
+- Conduct a thorough analysis of the affected application or service to identify and patch the specific vulnerability being exploited, ensuring all software is updated to the latest secure versions.
+- Review and enhance system and application logging to capture detailed information on segfault occurrences and related activities for future analysis and detection.
+- Implement additional security controls such as application whitelisting and memory protection mechanisms (e.g., DEP, ASLR) to mitigate the risk of buffer overflow attacks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Document the incident, including all actions taken and findings, to improve future response efforts and update incident response plans accordingly."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
index c5e85063fdc..6e684157679 100644
--- a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
+++ b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   )
 ) and not process.parent.name == "spine"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privilege Escalation via SUID/SGID
+
+SUID/SGID are Unix/Linux permissions that allow users to execute files with the file owner's or group's privileges, often root. Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. The detection rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions.
+
+### Possible investigation steps
+
+- Review the process details, including process.name and process.args, to understand the nature of the executed command and its intended function.
+- Check the process.real_user.id and process.real_group.id to identify the non-root user or group that initiated the process, and assess whether this user should have access to execute such commands.
+- Investigate the parent process (process.parent.name) to determine the origin of the execution and whether it aligns with expected behavior or indicates potential compromise.
+- Examine the system logs and user activity around the time of the alert to identify any suspicious actions or patterns that could suggest privilege escalation attempts.
+- Verify the SUID/SGID permissions of the flagged binary to ensure they are correctly configured and assess whether they have been altered or misconfigured.
+- Cross-reference the process with known vulnerabilities or exploits associated with the specific binary or command to determine if it is being targeted for privilege escalation.
+
+### False positive analysis
+
+- Processes initiated by legitimate system maintenance tasks or scripts may trigger the rule. Review scheduled tasks and scripts to identify benign activities and consider excluding them from the rule.
+- Some system utilities or applications may inherently require SUID/SGID permissions for normal operation. Verify the necessity of these permissions and exclude known safe applications from the rule.
+- Development or testing environments often run processes with elevated privileges for debugging purposes. Identify these environments and apply exceptions to avoid false positives.
+- Administrative tools or scripts executed by system administrators might appear as privilege escalation attempts. Ensure these are documented and excluded if they are part of routine administrative tasks.
+- Processes with the parent name "spine" are already excluded, indicating a known benign pattern. Review similar patterns in your environment and apply similar exclusions where applicable.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate any suspicious processes identified by the detection rule that are running with elevated privileges but were initiated by non-root users.
+- Conduct a thorough review of the SUID/SGID binaries on the affected system to identify and remove any unnecessary or misconfigured binaries that could be exploited for privilege escalation.
+- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack to ensure they do not retain unauthorized elevated privileges.
+- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities that could be exploited for privilege escalation.
+- Implement enhanced monitoring and logging for SUID/SGID execution and privilege escalation attempts to detect and respond to similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
index 656f678d771..520a966e8bb 100644
--- a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
+++ b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,41 @@ sequence by host.id with maxspan=1s
      process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Shell via Wildcard Injection Detected
+
+Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries leverage this to escalate privileges or execute arbitrary code. The detection rule identifies suspicious use of vulnerable binaries like `tar`, `rsync`, and `zip` followed by shell execution, indicating potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific command executed, focusing on the process name and arguments, especially those involving `tar`, `rsync`, or `zip` with suspicious flags like `--checkpoint=*`, `-e*`, or `--unzip-command`.
+- Examine the parent process information to determine if a shell process (e.g., `bash`, `sh`, `zsh`) was spawned, indicating potential exploitation.
+- Check the process execution path to ensure it does not match the exclusion pattern `/tmp/newroot/*`, which might indicate a benign operation.
+- Investigate the host's recent activity logs to identify any other suspicious or related events that might indicate a broader attack or compromise.
+- Correlate the alert with any other security events or alerts from the same host to assess if this is part of a larger attack pattern or campaign.
+- Assess the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with expected behavior for that account.
+
+### False positive analysis
+
+- Legitimate use of tar, rsync, or zip with wildcard-related flags in automated scripts or backup processes can trigger false positives. Review the context of these processes and consider excluding specific scripts or directories from monitoring if they are verified as safe.
+- System administrators or maintenance scripts may use shell commands following tar, rsync, or zip for legitimate purposes. Identify these routine operations and create exceptions for known safe parent processes or specific command patterns.
+- Development environments or testing scenarios might involve intentional use of wildcard characters for testing purposes. Exclude these environments from the rule or adjust the rule to ignore specific user accounts or process paths associated with development activities.
+- Scheduled tasks or cron jobs that involve the use of these binaries with wildcard flags can be mistaken for malicious activity. Verify the legitimacy of these tasks and exclude them based on their schedule or specific command line arguments.
+- Security tools or monitoring solutions that simulate attacks for testing or validation purposes might trigger this rule. Ensure these tools are recognized and excluded from monitoring to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified in the alert, particularly those involving the execution of shell commands following the use of `tar`, `rsync`, or `zip`.
+- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or unauthorized access attempts.
+- Restore the affected system from a known good backup if any unauthorized changes or malicious activities are confirmed.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement file integrity monitoring on critical systems to detect unauthorized changes to system binaries or configuration files.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
index 1ed28663043..db1ee3aa243 100644
--- a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
+++ b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/07/30"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.name == "debugfs" and process.args : "/dev/sd*" and not process.args == "-R" and 
 not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Suspicious DebugFS Root Device Access
+
+DebugFS is a Linux utility that provides a low-level interface to access and manipulate file systems, typically used for debugging purposes. It can be exploited by adversaries with "disk" group privileges to access sensitive files without root permissions, potentially leading to privilege escalation. The detection rule identifies non-root users executing DebugFS on disk devices, flagging potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the non-root user and group involved in the DebugFS execution by examining the user.Ext.real.id and group.Ext.real.id fields.
+- Check the command-line arguments (process.args) to determine which specific disk device was accessed and assess if the access was legitimate or necessary for the user's role.
+- Investigate the user's recent activity and login history to identify any unusual patterns or unauthorized access attempts that might indicate malicious intent.
+- Verify the user's group memberships, particularly focusing on the "disk" group, to understand if the user should have such privileges and if any recent changes were made to their group assignments.
+- Examine system logs and other security alerts around the time of the DebugFS execution to identify any correlated suspicious activities or potential indicators of compromise.
+- Assess the system for any unauthorized changes or access to sensitive files, such as the shadow file or root SSH keys, which could indicate privilege escalation attempts.
+
+### False positive analysis
+
+- Non-root system administrators or maintenance scripts may use DebugFS for legitimate disk diagnostics or recovery tasks. To handle this, identify and whitelist specific users or scripts that are known to perform these tasks regularly.
+- Automated backup or monitoring tools might invoke DebugFS as part of their operations. Review and exclude these tools by adding their process identifiers or user accounts to an exception list.
+- Developers or testers with disk group privileges might use DebugFS during development or testing phases. Establish a policy to document and approve such activities, and exclude these users from triggering alerts.
+- Educational or training environments where DebugFS is used for learning purposes can generate false positives. Create exceptions for these environments by specifying the associated user accounts or groups.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Revoke "disk" group privileges from non-essential users to limit access to disk devices and prevent misuse of DebugFS.
+- Conduct a thorough review of user accounts and group memberships to ensure only authorized personnel have "disk" group privileges.
+- Check for unauthorized access to sensitive files such as the shadow file or root SSH private keys and reset credentials if necessary.
+- Monitor for any additional suspicious activity on the affected system and related systems, focusing on privilege escalation attempts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced logging and monitoring for DebugFS usage and access to disk devices to detect similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_shadow_file_read.toml b/rules/linux/privilege_escalation_shadow_file_read.toml
index 327e52480d6..57159b1cce3 100644
--- a/rules/linux/privilege_escalation_shadow_file_read.toml
+++ b/rules/linux/privilege_escalation_shadow_file_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,40 @@ host.os.type : "linux" and event.category : "process" and event.action : ("exec"
   process.parent.name:(gen_passwd_sets or scc_* or wazuh-modulesd)
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Shadow File Read via Command Line Utilities
+
+In Linux environments, the `/etc/shadow` file stores hashed passwords, making it a prime target for attackers seeking credential access. Adversaries with elevated privileges may exploit command-line utilities to read this file, aiming to extract credentials for lateral movement. The detection rule identifies suspicious access attempts by monitoring process activities related to the file, excluding legitimate operations, thus highlighting potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the executable and arguments used, focusing on the process.args field to confirm access attempts to /etc/shadow.
+- Check the process.parent.name field to determine the parent process and assess if it is associated with known legitimate activities or suspicious behavior.
+- Investigate the user context under which the process was executed to verify if the user had legitimate reasons to access the /etc/shadow file.
+- Examine the host's recent activity logs for any privilege escalation events that might have preceded the access attempt, indicating potential unauthorized privilege elevation.
+- Correlate the event with other alerts or logs from the same host to identify patterns or sequences of actions that suggest lateral movement or further credential access attempts.
+- Assess the environment for any recent changes or deployments that might explain the access attempt, such as updates or configuration changes involving user management.
+
+### False positive analysis
+
+- System maintenance tasks may trigger alerts when legitimate processes like chown or chmod access the /etc/shadow file. To handle these, consider excluding these specific processes when they are executed by trusted system administrators during scheduled maintenance.
+- Containerized environments might generate false positives if processes within containers access the /etc/shadow file. Exclude paths such as /var/lib/docker/* or /run/containerd/* to reduce noise from container operations.
+- Security tools like wazuh-modulesd or custom scripts (e.g., gen_passwd_sets) that legitimately interact with the /etc/shadow file for monitoring or compliance checks can be excluded by adding them to the process.parent.name exclusion list.
+- Automated scripts or cron jobs that perform routine checks or updates on system files, including /etc/shadow, should be reviewed and, if deemed safe, excluded from triggering alerts by specifying their process names or paths in the exclusion criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified in the alert that are attempting to access the /etc/shadow file.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized privilege escalations or account creations.
+- Change all passwords for accounts on the affected system, especially those with elevated privileges, to mitigate the risk of credential compromise.
+- Review and update access controls and permissions for sensitive files like /etc/shadow to ensure they are restricted to only necessary users and processes.
+- Monitor for any further attempts to access the /etc/shadow file across the network, using enhanced logging and alerting mechanisms to detect similar threats.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
index 005178403d9..b413bea81c5 100644
--- a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
+++ b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
   process.name == "sudo" and process.args == "-u#-1"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Sudo Privilege Escalation via CVE-2019-14287
+
+CVE-2019-14287 exploits a flaw in certain sudo versions, allowing users to execute commands as root by bypassing user ID verification. Attackers can misuse this to gain unauthorized root access, posing significant security risks. The detection rule identifies suspicious sudo commands indicative of this exploit, focusing on specific command patterns that translate to root execution, thereby alerting security teams to potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the suspicious command pattern "sudo -u#-1" in the process arguments, as this is indicative of the CVE-2019-14287 exploit attempt.
+- Identify the user account associated with the process execution to determine if the user should have legitimate access to execute commands with elevated privileges.
+- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise.
+- Check the version of sudo installed on the affected system to verify if it is vulnerable to CVE-2019-14287, specifically versions prior to v1.28.
+- Investigate the source IP address and hostname of the affected system to assess if it is part of a larger attack pattern or if there are other systems potentially compromised.
+- Review system logs and audit trails for any additional unauthorized access attempts or privilege escalation activities around the time of the alert.
+- If possible, isolate the affected system to prevent further unauthorized access while conducting a more thorough forensic analysis.
+
+### False positive analysis
+
+- Legitimate administrative tasks using sudo with unconventional user ID arguments may trigger the rule. Review the context of the command execution to determine if it aligns with expected administrative activities.
+- Automated scripts or maintenance tools that use sudo with arbitrary user IDs for testing or configuration purposes might be flagged. Identify and document these scripts, then create exceptions in the monitoring system to exclude them from alerts.
+- Development environments where developers have elevated privileges for testing purposes could generate false positives. Ensure that such environments are well-documented and consider excluding them from this specific rule if they consistently trigger alerts.
+- Security tools or monitoring systems that simulate attacks for testing detection capabilities may inadvertently trigger this rule. Coordinate with security teams to whitelist these tools or adjust their configurations to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate any suspicious processes identified with the command pattern "sudo -u#-1" to halt any ongoing unauthorized activities.
+- Conduct a thorough review of system logs and sudo logs to identify any additional unauthorized access attempts or successful privilege escalations.
+- Reset passwords and review user accounts on the affected system to ensure no unauthorized accounts have been created or existing accounts have been compromised.
+- Apply patches or upgrade sudo to a version later than v1.28 to mitigate the vulnerability exploited by CVE-2019-14287.
+- Monitor the network for any signs of data exfiltration or further exploitation attempts, using enhanced logging and alerting mechanisms.
+- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and actions taken."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_sudo_hijacking.toml b/rules/linux/privilege_escalation_sudo_hijacking.toml
index c188f2396b4..6b06eaaadf6 100644
--- a/rules/linux/privilege_escalation_sudo_hijacking.toml
+++ b/rules/linux/privilege_escalation_sudo_hijacking.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,41 @@ file.path in ("/usr/bin/sudo", "/bin/sudo") and not (
   (process.name == "sed" and file.name : "sed*")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Sudo Hijacking
+
+Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts.
+
+### Possible investigation steps
+
+- Review the file creation or rename event details to confirm the file path is either /usr/bin/sudo or /bin/sudo, as these are critical locations for the sudo binary.
+- Check the process executable that triggered the event to ensure it is not part of the legitimate package management processes listed in the query, such as /bin/dpkg or /usr/bin/yum.
+- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the system logs around the time of the event for any unusual activity or errors that might indicate tampering or unauthorized access.
+- Verify the integrity of the current sudo binary by comparing its hash with a known good version to detect any unauthorized modifications.
+- Assess the system for any additional signs of compromise, such as unexpected network connections or new user accounts, which may indicate broader malicious activity.
+
+### False positive analysis
+
+- Package management processes can trigger false positives when legitimate updates or installations occur. To handle this, ensure that processes like dpkg, rpm, yum, and apt are included in the exclusion list as they are common package managers.
+- Custom scripts or automation tools that modify the sudo binary for legitimate reasons may cause alerts. Review these scripts and consider adding their paths to the exclusion list if they are verified as safe.
+- Temporary files or directories used during legitimate software installations or updates, such as those in /var/lib/dpkg or /tmp, can lead to false positives. Exclude these paths if they are part of a known and safe process.
+- Development or testing environments where sudo binaries are frequently modified for testing purposes might trigger alerts. In such cases, consider excluding these environments from monitoring or adding specific exclusions for known safe modifications.
+- Ensure that any process or executable that is known to interact with the sudo binary in a non-malicious way is added to the exclusion list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source. If compromised, replace it with the legitimate binary.
+- Conduct a thorough review of system logs and the process execution history to identify any unauthorized changes or suspicious activities related to the sudo binary.
+- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential theft.
+- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify critical binaries or escalate privileges.
+- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems may be affected.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system binaries."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
index ce6f74cdf9b..2c6a878801c 100644
--- a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
+++ b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,41 @@ sequence by host.id, process.session_leader.entity_id with maxspan=15s
 [ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
   process.name == "sudo" and process.user.id == "0" and process.group.id == "0" ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Sudo Token Manipulation via Process Injection
+
+In Linux environments, process injection can be exploited by adversaries to manipulate sudo tokens, allowing unauthorized privilege escalation. Attackers may use debugging tools like gdb to inject code into processes with valid sudo tokens, leveraging ptrace capabilities. The detection rule identifies this threat by monitoring for gdb execution followed by a uid change in the sudo process, indicating potential token manipulation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process session leader entity ID involved in the potential sudo token manipulation.
+- Examine the process tree on the affected host to trace the parent and child processes of the gdb execution, focusing on any unusual or unauthorized processes.
+- Check the system logs for any recent sudo commands executed by the user associated with the gdb process to determine if there were any unauthorized privilege escalations.
+- Investigate the user account associated with the gdb process to verify if it has legitimate reasons to use debugging tools and if it has been compromised.
+- Analyze the timing and context of the uid change event in the sudo process to assess if it aligns with legitimate administrative activities or if it appears suspicious.
+- Review the system's ptrace settings to ensure they are configured securely and assess if there have been any recent changes that could have enabled this attack vector.
+
+### False positive analysis
+
+- Debugging activities by developers or system administrators using gdb for legitimate purposes can trigger this rule. To manage this, create exceptions for specific user IDs or groups known to perform regular debugging tasks.
+- Automated scripts or maintenance tools that utilize gdb for process analysis might cause false positives. Identify these scripts and exclude their associated process names or paths from the rule.
+- System monitoring or security tools that perform uid changes as part of their normal operation could be mistaken for malicious activity. Review and whitelist these tools by their process names or specific user IDs.
+- Training or testing environments where sudo and gdb are used frequently for educational purposes may generate alerts. Consider excluding these environments by host ID or network segment to reduce noise.
+- Scheduled tasks or cron jobs that involve gdb and sudo processes might inadvertently match the rule criteria. Analyze these tasks and exclude them based on their execution times or specific process attributes.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or privilege escalation.
+- Terminate any suspicious gdb and sudo processes identified in the alert to stop ongoing process injection attempts.
+- Conduct a thorough review of the affected system's process and user activity logs to identify any unauthorized changes or access patterns.
+- Reset credentials and sudo tokens for all users on the affected system to prevent further exploitation using compromised tokens.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Re-enable ptrace restrictions if they were previously disabled, to limit the ability of attackers to perform process injection.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
index 099c3d7462e..47da076e06d 100644
--- a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
+++ b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,41 @@ sequence by host.id, process.entity_id with maxspan=1s
   [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and 
    (user.id == "0" or group.id == "0")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via Python cap_setuid
+
+In Unix-like systems, setuid and setgid allow processes to execute with elevated privileges, often exploited by adversaries to gain unauthorized root access. Attackers may use Python scripts to invoke system commands with these capabilities, followed by changing user or group IDs to root. The detection rule identifies this sequence by monitoring Python processes executing system commands with setuid/setgid, followed by a root user or group ID change, signaling potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details, including process.entity_id and process.args, to confirm the execution of a Python script with setuid or setgid capabilities.
+- Check the user.id and group.id fields to verify if there was an unauthorized change to root (user.id == "0" or group.id == "0").
+- Investigate the host.id to determine if other suspicious activities or alerts have been associated with the same host.
+- Examine the timeline of events to see if the uid_change or gid_change occurred immediately after the Python process execution, indicating a potential privilege escalation attempt.
+- Look into the source of the Python script or command executed to identify if it was a known or unknown script, and assess its legitimacy.
+- Analyze any related network activity or connections from the host around the time of the alert to identify potential lateral movement or data exfiltration attempts.
+
+### False positive analysis
+
+- Development and testing environments may trigger this rule when developers use Python scripts to test setuid or setgid functionalities. To manage this, exclude specific user accounts or host IDs associated with development activities.
+- Automated scripts or maintenance tasks that require temporary privilege escalation might be flagged. Identify and whitelist these scripts by their process names or paths to prevent false positives.
+- System administrators using Python scripts for legitimate administrative tasks could inadvertently trigger the rule. Consider excluding known administrator accounts or specific scripts used for routine maintenance.
+- Security tools or monitoring solutions that simulate attacks for testing purposes may cause alerts. Exclude these tools by their process signatures or host IDs to avoid unnecessary alerts.
+- Custom applications that use Python for legitimate privilege management should be reviewed and, if safe, added to an exception list based on their unique process identifiers or execution paths.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious Python processes identified by the detection rule to halt potential privilege escalation activities.
+- Review and revoke any unauthorized setuid or setgid permissions on binaries or scripts to prevent exploitation.
+- Conduct a thorough investigation of the affected system to identify any additional signs of compromise or persistence mechanisms.
+- Reset credentials and review access permissions for any accounts that may have been affected or used in the attack.
+- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
index 438d47ec204..0a59d73c983 100644
--- a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,40 @@ sequence by host.id, process.pid with maxspan=1s
    ) and user.id != "0"
   ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privilege Escalation via CAP_CHOWN/CAP_FOWNER Capabilities
+
+In Linux, CAP_CHOWN and CAP_FOWNER are capabilities that allow processes to change file ownership and bypass file permission checks, respectively. Adversaries exploit these to gain unauthorized access to sensitive files, such as password or configuration files. The detection rule identifies suspicious processes with these capabilities that alter ownership of critical files, signaling potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details, including process.name and process.command_line, to understand the context of the executed process and its intended function.
+- Check the user.id associated with the process to determine if the process was executed by a non-root user, which could indicate unauthorized privilege escalation attempts.
+- Investigate the file.path that had its ownership changed to assess the potential impact, focusing on critical files like /etc/passwd, /etc/shadow, /etc/sudoers, and /root/.ssh/*.
+- Analyze the sequence of events by examining the host.id and process.pid to identify any related processes or activities that occurred within the maxspan=1s timeframe.
+- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- System administration scripts or automated processes may legitimately use CAP_CHOWN or CAP_FOWNER capabilities to manage file permissions or ownership. Review and whitelist these processes if they are verified as non-malicious.
+- Backup or restoration operations often require changing file ownership and permissions. Identify and exclude these operations from triggering alerts by specifying known backup tools or scripts.
+- Software installation or update processes might alter file ownership as part of their normal operation. Monitor and exclude these processes if they are part of a trusted software management system.
+- Development or testing environments may have scripts that modify file ownership for testing purposes. Ensure these environments are properly segmented and exclude known development scripts from detection.
+- Custom user scripts that require elevated permissions for legitimate tasks should be reviewed and, if deemed safe, added to an exception list to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified with CAP_CHOWN or CAP_FOWNER capabilities that are altering file ownership, especially those targeting critical files like /etc/passwd or /etc/shadow.
+- Revert any unauthorized changes to file ownership or permissions on critical files to their original state to restore system integrity.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify and disable any unauthorized accounts or privilege escalations.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement additional monitoring on the affected host and similar systems to detect any further attempts to exploit CAP_CHOWN or CAP_FOWNER capabilities.
+- Review and update security policies and configurations to restrict the assignment of CAP_CHOWN and CAP_FOWNER capabilities to only trusted and necessary processes."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
index 0b8d920fccf..582adc7bff4 100644
--- a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
+++ b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/22"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,40 @@ sequence by host.id, process.parent.pid with maxspan=1m
   [file where host.os.type == "linux" and file.path == "/etc/passwd" and process.parent.pid != 1 and
    not auditd.data.a2 == "80000" and event.outcome == "success" and user.id != "0"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Passwd File Event Action
+
+In Linux environments, the `/etc/passwd` file is crucial for managing user accounts. Adversaries may exploit vulnerabilities or misconfigurations to add unauthorized entries, potentially gaining root access. The detection rule monitors for the use of `openssl` to generate password entries and subsequent unauthorized modifications to the `/etc/passwd` file, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of 'openssl' with the 'passwd' argument by a non-root user (user.id != "0"). This can help identify the user attempting to generate a password entry.
+- Examine the process tree to understand the parent process of the 'openssl' command and determine if it was initiated by a legitimate or suspicious process.
+- Check the file modification event on '/etc/passwd' to verify if the file was altered by a non-root user (user.id != "0") and ensure the process.parent.pid is not 1, indicating it wasn't initiated by the init process.
+- Investigate the context of the file write event by reviewing recent logs and system changes to identify any unauthorized modifications or anomalies in user account management.
+- Correlate the event with other security alerts or logs to determine if there are additional indicators of compromise or related suspicious activities on the host.
+
+### False positive analysis
+
+- System administrators or automated scripts may use openssl to manage user passwords without malicious intent. To handle this, identify and whitelist known administrative scripts or processes that perform legitimate password management tasks.
+- Some legitimate software installations or updates might temporarily modify the /etc/passwd file. Monitor and document these activities to distinguish them from unauthorized changes, and consider creating exceptions for known software processes.
+- Developers or testers might use openssl for password generation in non-production environments. Establish a policy to differentiate between production and non-production systems, and apply the rule more strictly in production environments.
+- Scheduled maintenance tasks might involve legitimate modifications to the /etc/passwd file. Coordinate with IT teams to schedule these tasks and temporarily adjust monitoring rules during these periods to prevent false positives.
+- In environments with multiple administrators, ensure that all legitimate administrative actions are logged and reviewed. Implement a process for administrators to report their activities, allowing for the creation of exceptions for known, non-threatening actions.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or privilege escalation attempts.
+- Terminate any suspicious processes related to `openssl` or unauthorized modifications to the `/etc/passwd` file to halt ongoing malicious activities.
+- Conduct a thorough review of the `/etc/passwd` file to identify and remove any unauthorized entries, especially those with root privileges.
+- Reset passwords for all user accounts on the affected system to ensure no compromised credentials are used for further attacks.
+- Restore the `/etc/passwd` file from a known good backup if unauthorized changes are detected and cannot be manually rectified.
+- Escalate the incident to the security operations team for a comprehensive investigation into potential system vulnerabilities or misconfigurations that allowed the attack.
+- Implement enhanced monitoring and alerting for similar activities, focusing on unauthorized use of `openssl` and modifications to critical system files like `/etc/passwd`."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
index 81d2c3ef6c1..cb8416751ae 100644
--- a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,41 @@ sequence by host.id, process.entity_id with maxspan=1s
    (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID")
    and user.id == "0"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privilege Escalation via CAP_SETUID/SETGID Capabilities
+
+In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process details such as process.name and process.executable to identify the specific application or script that triggered the alert. This can help determine if the process is expected or potentially malicious.
+- Examine the process.parent.executable and process.parent.name fields to understand the parent process that initiated the suspicious process. This can provide context on whether the parent process is legitimate or part of a known attack vector.
+- Check the user.id field to confirm the user context under which the process was executed. If the user is not expected to have elevated privileges, this could indicate a potential compromise.
+- Investigate the process.command_line to analyze the command executed. Look for any unusual or unexpected command patterns that could suggest malicious intent.
+- Correlate the alert with other security events or logs from the same host.id to identify any related suspicious activities or patterns that could indicate a broader attack.
+- Assess the environment for any recent changes or misconfigurations that could have inadvertently granted CAP_SETUID or CAP_SETGID capabilities to unauthorized processes.
+
+### False positive analysis
+
+- Processes related to system management tools like VMware, SolarWinds, and language tools may trigger false positives. Exclude these by adding their executables to the exception list.
+- Scheduled tasks or system updates that involve processes like update-notifier or dbus-daemon can cause false alerts. Consider excluding these parent process names from the detection rule.
+- Automation tools such as Ansible or scripts executed by Python may inadvertently match the rule. Exclude command lines that match known automation patterns.
+- Legitimate use of sudo or pkexec for administrative tasks can be misinterpreted as privilege escalation. Exclude these executables if they are part of regular administrative operations.
+- Monitoring tools like osqueryd or saposcol might trigger the rule during normal operations. Add these process names to the exception list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified with CAP_SETUID or CAP_SETGID capabilities that have escalated privileges to root, ensuring no further exploitation occurs.
+- Conduct a thorough review of the affected system's user and group configurations to identify and correct any misconfigurations that allowed the privilege escalation.
+- Revoke unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users that do not require them, reducing the attack surface for future exploitation.
+- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is returned to a secure state.
+- Monitor the system and network for any signs of continued or attempted exploitation, using enhanced logging and alerting to detect similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_uid_change_post_compilation.toml b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
index 64e954706a1..347a870770c 100644
--- a/rules/linux/privilege_escalation_uid_change_post_compilation.toml
+++ b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,42 @@ sequence by host.id with maxspan=1m
   [process where host.os.type == "linux" and event.action in ("uid_change", "guid_change") and event.type == "change" and 
    user.id == "0"] by process.name
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via Recently Compiled Executable
+
+In Linux environments, compiling and executing programs is a routine operation. However, adversaries can exploit this by compiling malicious code to escalate privileges. This detection rule identifies suspicious sequences where a non-root user compiles and executes a program, followed by a UID change to root, indicating potential privilege escalation attempts. By monitoring these patterns, the rule helps in identifying and mitigating exploitation risks.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific non-root user involved in the compilation and execution sequence. Check the user.id field to gather more information about the user's activities and permissions.
+- Examine the process.args field from the initial compilation event to understand the source code or script being compiled. This can provide insights into whether the code has malicious intent.
+- Investigate the file.name field associated with the creation event to determine the nature of the executable file created. Check its location and any associated metadata for anomalies.
+- Analyze the process.name field from the execution event to identify the program that was run. Cross-reference this with known malicious binaries or scripts.
+- Check the process.name field in the UID change event to identify the process responsible for the privilege escalation. Determine if this process is known to exploit vulnerabilities for privilege escalation.
+- Review system logs and other security tools for any additional suspicious activities or anomalies around the time of the alert to gather more context on the potential threat.
+- Assess the system for any signs of compromise or unauthorized changes, such as new user accounts, altered configurations, or unexpected network connections, to evaluate the impact and scope of the incident.
+
+### False positive analysis
+
+- Development activities by legitimate users can trigger this rule when compiling and testing new software. To manage this, consider creating exceptions for specific users or groups known to perform regular development tasks.
+- Automated build systems or continuous integration pipelines may compile and execute code as part of their normal operation. Exclude these systems by identifying their user accounts or host identifiers.
+- System administrators performing maintenance or updates might compile and execute programs, leading to false positives. Implement exceptions for these users or specific maintenance windows.
+- Educational environments where students frequently compile and execute code for learning purposes can generate alerts. Exclude these activities by setting up exceptions for student user accounts or specific lab environments.
+- Security testing and research activities that involve compiling and executing exploit code in a controlled manner can be mistaken for malicious behavior. Exclude these activities by identifying the user accounts or systems involved in such testing.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified in the alert, especially those associated with the compiled executable and any processes running with elevated privileges.
+- Revert any unauthorized changes to user permissions, particularly any UID changes to root, to restore the system to its secure state.
+- Conduct a thorough review of the affected system for additional indicators of compromise, such as unauthorized file modifications or new user accounts, and remove any malicious artifacts.
+- Apply relevant security patches and updates to the system to address any vulnerabilities that may have been exploited for privilege escalation.
+- Monitor the affected system and network for any signs of recurring or related suspicious activity, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring comprehensive remediation across the environment."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
index 6d8b2ad4a2c..f606057e0ba 100644
--- a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
+++ b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,42 @@ and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or
   process.args:/usr/bin/python*
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 UID Elevation from Previously Unknown Executable
+
+In Linux environments, UID elevation is a process where a user's permissions are increased, often to root level, allowing full system control. Adversaries exploit this by using unknown executables to hijack execution flow, often via rootkits, to gain unauthorized root access. The detection rule identifies such activities by monitoring for UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the unknown executable that triggered the alert, focusing on the process.executable field to determine its path and origin.
+- Examine the parent process information using process.parent.name to understand the context in which the unknown executable was launched, checking for any unusual or unexpected shell activity.
+- Investigate the user account associated with the UID change by analyzing the user.id field to determine if the account has a history of privilege escalation attempts or if it has been compromised.
+- Check the system logs for any recent changes or installations that might have introduced the unknown executable, focusing on the time frame around the event.action:"uid_change".
+- Assess the network activity around the time of the alert to identify any potential external connections or data exfiltration attempts that might correlate with the privilege escalation.
+- Cross-reference the executable path and name against known threat intelligence databases to determine if it is associated with any known malicious activity or rootkits.
+- If possible, perform a forensic analysis of the executable to understand its behavior and potential impact on the system, looking for signs of function or syscall hooking as indicated in the rule description.
+
+### False positive analysis
+
+- Executables in custom directories may trigger false positives if they are legitimate but not included in the known safe paths. Users can mitigate this by adding these directories to the exclusion list in the detection rule.
+- Scripts or binaries executed by system administrators from non-standard locations for maintenance or deployment purposes might be flagged. To handle this, users should document and exclude these specific processes or paths if they are verified as safe.
+- Development or testing environments where new executables are frequently introduced can cause alerts. Users should consider creating exceptions for these environments or paths to reduce noise while ensuring they are monitored separately for any unusual activity.
+- Automated scripts or tools that perform legitimate UID changes but are not part of the standard system paths can be excluded by adding their specific executable paths or names to the rule's exception list.
+- Temporary or ephemeral processes that are part of containerized applications might be flagged. Users should review and exclude these processes if they are confirmed to be part of normal operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule that are not part of the known safe paths or processes.
+- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or related suspicious activities.
+- Remove any unauthorized or unknown executables found on the system, especially those involved in the UID elevation attempt.
+- Restore the system from a known good backup if any rootkits or persistent threats are detected that cannot be easily removed.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
index bb29544825f..885b6f42f07 100644
--- a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
+++ b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -80,6 +80,39 @@ process.executable: "/usr/bin/unshare" and
 not process.parent.executable: ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") and
 not process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Namespace Manipulation Using Unshare
+
+The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse.
+
+### Possible investigation steps
+
+- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare.
+- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised.
+- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls.
+- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts.
+- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign.
+
+### False positive analysis
+
+- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables.
+- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts.
+- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives.
+- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network.
+- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query.
+- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution.
+- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted.
+- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected.
+- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/linux/privilege_escalation_writable_docker_socket.toml b/rules/linux/privilege_escalation_writable_docker_socket.toml
index be6a9360a51..d91ea4df4dd 100644
--- a/rules/linux/privilege_escalation_writable_docker_socket.toml
+++ b/rules/linux/privilege_escalation_writable_docker_socket.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock"))
 ) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation through Writable Docker Socket
+
+Docker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. Adversaries with write access can exploit these sockets to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious activities by monitoring processes like Docker and Socat for unauthorized socket interactions, focusing on non-root users attempting to execute commands, thus flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (either "docker" or "socat") and the associated arguments that triggered the alert, focusing on the use of "unix://*/docker.sock" or "unix://*/dockershim.sock".
+- Check the user and group IDs associated with the process to confirm they are non-root, as indicated by the exclusion of user.Ext.real.id and group.Ext.real.id being "0".
+- Investigate the user account involved in the alert to determine if they should have access to Docker sockets and whether their permissions have been misconfigured or compromised.
+- Examine the system logs and Docker daemon logs for any additional context or anomalies around the time of the alert to identify any unauthorized or suspicious activities.
+- Assess the current state of the system for any unauthorized containers that may have been started, and inspect their configurations and running processes for signs of privilege escalation attempts.
+- Verify the integrity and permissions of the Docker socket files to ensure they have not been altered to allow unauthorized access.
+
+### False positive analysis
+
+- Legitimate administrative tasks by non-root users with elevated permissions can trigger the rule. To manage this, identify trusted users or groups who regularly perform such tasks and create exceptions for their activities.
+- Automated scripts or services that require Docker socket access for legitimate operations may be flagged. Review these scripts or services and whitelist their specific process names or arguments to prevent false positives.
+- Development environments where developers frequently use Docker for testing might cause alerts. Consider creating a separate monitoring policy for development environments or exclude known development user accounts from this rule.
+- Continuous integration/continuous deployment (CI/CD) pipelines that interact with Docker sockets can be mistakenly identified as threats. Ensure that these pipelines are running under specific service accounts and exclude these accounts from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any unauthorized Docker containers that were started by non-root users, especially those interacting with Docker sockets.
+- Review and revoke any unnecessary write permissions to Docker sockets for non-root users and groups, ensuring only trusted users have access.
+- Conduct a thorough audit of user accounts and group memberships on the affected system to identify and remove any unauthorized or suspicious accounts.
+- Restore the system from a known good backup if unauthorized changes or access to sensitive data are detected.
+- Implement monitoring and alerting for any future unauthorized access attempts to Docker sockets, focusing on non-root user activities.
+- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_credentials_keychains.toml b/rules/macos/credential_access_credentials_keychains.toml
index 10a16206576..c4cceff5fdb 100644
--- a/rules/macos/credential_access_credentials_keychains.toml
+++ b/rules/macos/credential_access_credentials_keychains.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -94,6 +94,39 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                    "/usr/local/jamf/bin/jamf",
                                                    "/Applications/Microsoft Defender.app/Contents/MacOS/wdavdaemon")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Access to Keychain Credentials Directories
+
+macOS keychains securely store user credentials, such as passwords and certificates, essential for system and application authentication. Adversaries may target these directories to extract sensitive information, potentially compromising user accounts and system integrity. The detection rule identifies suspicious access attempts by monitoring process activities related to keychain directories, excluding known legitimate processes and actions, thus highlighting potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the process details that triggered the alert, focusing on the process.args field to identify the specific keychain directory accessed and the nature of the access attempt.
+- Examine the process.parent.executable and process.executable fields to determine the origin of the process and assess whether it is a known or potentially malicious application.
+- Investigate the process.Ext.effective_parent.executable field to trace the parent process chain and identify any unusual or unauthorized parent processes that may have initiated the access.
+- Check for any recent changes or installations on the system that could explain the access attempt, such as new software or updates that might interact with keychain directories.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional suspicious activities that could indicate a broader compromise.
+
+### False positive analysis
+
+- Processes related to legitimate security applications like Microsoft Defender, JumpCloud Agent, and Rapid7 IR Agent may trigger false positives. Users can mitigate this by ensuring these applications are included in the exclusion list for process executables and effective parent executables.
+- Routine administrative tasks involving keychain management, such as setting keychain settings or importing certificates, might be flagged. To handle this, users should add these specific actions to the exclusion list for process arguments.
+- Applications like OpenVPN Connect and JAMF management tools that interact with keychain directories for legitimate purposes can cause false alerts. Users should verify these applications are part of the exclusion list for parent executables to prevent unnecessary alerts.
+- Regular system maintenance or updates that involve keychain access might be misinterpreted as suspicious. Users should monitor these activities and adjust the exclusion criteria as needed to accommodate known maintenance processes.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule that are attempting to access keychain directories without legitimate reasons.
+- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access or modifications to keychain files.
+- Change all passwords and credentials stored in the keychain on the affected system to prevent potential misuse of compromised credentials.
+- Restore the system from a known good backup if unauthorized access has led to system integrity issues or data corruption.
+- Implement additional monitoring on the affected system to detect any further unauthorized access attempts, focusing on the keychain directories and related processes.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
index 4eea3dcd5ff..1cd6d1b1e40 100644
--- a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
+++ b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,39 @@ query = '''
 event.category:process and host.os.type:macos and event.type:start and
  process.name:(defaults or mkpassdb) and process.args:(ShadowHashData or "-dump")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Dumping Account Hashes via Built-In Commands
+
+In macOS environments, built-in commands like `defaults` and `mkpassdb` can be exploited by adversaries to extract user account hashes, which are crucial for credential access. These hashes, once obtained, can be cracked to reveal passwords or used for lateral movement within a network. The detection rule identifies suspicious process executions involving these commands and specific arguments, signaling potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `defaults` or `mkpassdb` commands with arguments like `ShadowHashData` or `-dump`, as these are indicative of credential dumping attempts.
+- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious.
+- Check the historical activity of the involved user account and the host to identify any patterns or anomalies that could suggest unauthorized access or lateral movement.
+- Investigate any network connections or subsequent processes initiated by the suspicious process to assess potential data exfiltration or further malicious actions.
+- Correlate the event with other security alerts or logs from the same host or user account to build a comprehensive timeline of the activity and assess the scope of the potential compromise.
+
+### False positive analysis
+
+- System administrators or security tools may legitimately use the `defaults` or `mkpassdb` commands for system maintenance or auditing purposes. To manage these, create exceptions for known administrative accounts or tools that regularly execute these commands.
+- Automated scripts or management software might invoke these commands as part of routine operations. Identify and whitelist these scripts or software to prevent unnecessary alerts.
+- Developers or IT personnel might use these commands during testing or development phases. Establish a process to temporarily exclude these activities by setting up time-bound exceptions for specific user accounts or devices.
+- Security assessments or penetration tests could trigger this rule. Coordinate with security teams to schedule and document these activities, allowing for temporary rule adjustments during the testing period.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further lateral movement or data exfiltration.
+- Terminate any suspicious processes identified as using the `defaults` or `mkpassdb` commands with the specified arguments to halt ongoing credential dumping activities.
+- Conduct a thorough review of user accounts on the affected system to identify any unauthorized access or changes, focusing on accounts with elevated privileges.
+- Reset passwords for all potentially compromised accounts, especially those with administrative access, and enforce strong password policies.
+- Analyze system logs and network traffic to identify any additional systems that may have been accessed using the compromised credentials, and apply similar containment measures.
+- 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 enhanced monitoring and alerting for similar suspicious activities across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_dumping_keychain_security.toml b/rules/macos/credential_access_dumping_keychain_security.toml
index e9e879c94a9..cae91ee2ae2 100644
--- a/rules/macos/credential_access_dumping_keychain_security.toml
+++ b/rules/macos/credential_access_dumping_keychain_security.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,40 @@ type = "eql"
 query = '''
 process where host.os.type == "macos" and event.type in ("start", "process_started") and process.args : "dump-keychain" and process.args : "-d"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Dumping of Keychain Content via Security Command
+
+Keychains in macOS securely store user credentials, including passwords and certificates. Adversaries exploit this by using commands to extract keychain data, aiming to access sensitive information. The detection rule identifies suspicious activity by monitoring processes that initiate keychain dumps, specifically looking for command-line arguments associated with this malicious behavior, thus alerting analysts to potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the parent process and determine if the keychain dump was initiated by a legitimate application or user.
+- Examine the user account associated with the process to verify if the activity aligns with their typical behavior or if the account may be compromised.
+- Check the timestamp of the event to correlate with any other suspicious activities or anomalies on the system around the same time.
+- Investigate the command-line arguments used in the process to confirm if they match known patterns of malicious keychain dumping attempts.
+- Analyze any network connections or data transfers initiated by the process to identify potential exfiltration of the dumped keychain data.
+- Look for additional alerts or logs from the same host or user to assess if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tasks or system maintenance activities may trigger the rule if they involve keychain access. Users should review the context of the process initiation to determine if it aligns with routine administrative operations.
+- Security or IT tools that perform regular audits or backups of keychain data might be flagged. Users can create exceptions for these tools by identifying their specific process names or paths and excluding them from the rule.
+- Developers or advanced users testing applications that require keychain access might inadvertently trigger the rule. Users should document these activities and consider temporary exclusions during development phases.
+- Automated scripts or workflows that interact with keychain data for legitimate purposes could be mistaken for malicious activity. Users should ensure these scripts are well-documented and consider adding them to an allowlist if they are frequently used.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the "dump-keychain" command, to halt ongoing credential theft attempts.
+- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access or export of credentials and determine the scope of the compromise.
+- Change all credentials stored in the keychain, including passwords for Wi-Fi, websites, and any other services, to mitigate the risk of unauthorized access using stolen credentials.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup predates the compromise.
+- Escalate the incident to the security operations team for further investigation and to assess whether additional systems may be affected.
+- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on keychain access and command-line arguments related to credential dumping, to prevent future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_kerberosdump_kcc.toml b/rules/macos/credential_access_kerberosdump_kcc.toml
index ef37c8198c4..324d23880f3 100644
--- a/rules/macos/credential_access_kerberosdump_kcc.toml
+++ b/rules/macos/credential_access_kerberosdump_kcc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   process.name:kcc and
   process.args:copy_cred_cache
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kerberos Cached Credentials Dumping
+
+Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. It uses tickets to allow nodes to prove their identity in a secure manner. Adversaries may exploit tools like the Kerberos credential cache utility to extract these tickets, enabling unauthorized access and lateral movement within a network. The detection rule identifies suspicious activity by monitoring for specific processes and arguments on macOS systems, flagging potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the process name 'kcc' and the argument 'copy_cred_cache' in the process execution logs on macOS systems.
+- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
+- Examine the timeline of the process execution to identify any preceding or subsequent suspicious activities, such as unusual login attempts or lateral movement within the network.
+- Check for any other alerts or logs related to the same host or user account to assess if this is part of a broader attack pattern.
+- Investigate the source and destination of any network connections made by the process to identify potential data exfiltration or communication with known malicious IP addresses.
+- Consult with the user or system owner to verify if the use of the 'kcc' utility was legitimate or if it requires further investigation.
+
+### False positive analysis
+
+- Routine administrative tasks using the kcc utility may trigger the rule. Identify and document these tasks to create exceptions for known benign activities.
+- Automated scripts or maintenance processes that involve copying Kerberos credential caches can be mistaken for malicious activity. Review and whitelist these scripts if they are verified as safe.
+- Developers or IT personnel testing Kerberos configurations might use the kcc utility in a non-malicious context. Establish a process to log and approve such activities to prevent false alarms.
+- Security tools or monitoring solutions that interact with Kerberos tickets for legitimate purposes may inadvertently trigger the rule. Coordinate with security teams to ensure these tools are recognized and excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Terminate the suspicious process identified as 'kcc' with the argument 'copy_cred_cache' to stop any ongoing credential dumping activity.
+- Conduct a thorough review of the system's Kerberos ticket cache to identify any unauthorized access or anomalies, and invalidate any compromised tickets.
+- Reset passwords and regenerate Kerberos tickets for any accounts that may have been affected to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the credential dumping activity.
+- Review and update access controls and Kerberos configurations to enhance security and reduce the risk of similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
index fc4b71083a3..c7d8b30169b 100644
--- a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
+++ b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,40 @@ process where host.os.type == "macos" and event.action == "exec" and
  process.command_line : ("*Chrome*", "*Chromium*", "*Opera*", "*Safari*", "*Brave*", "*Microsoft Edge*", "*Firefox*") and
  not process.parent.executable : "/Applications/Keeper Password Manager.app/Contents/Frameworks/Keeper Password Manager Helper*/Contents/MacOS/Keeper Password Manager Helper*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Keychain Password Retrieval via Command Line
+
+Keychain is macOS's secure storage system for managing user credentials, including passwords and certificates. Adversaries may exploit command-line tools to extract sensitive data from Keychain, targeting browsers like Chrome and Safari. The detection rule identifies suspicious command executions involving Keychain access, focusing on specific arguments and excluding legitimate applications, to flag potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the 'security' command with arguments '-wa' or '-ga' and 'find-generic-password' or 'find-internet-password', as these indicate attempts to access Keychain data.
+- Examine the command line for references to browsers such as Chrome, Safari, or others specified in the rule to determine if the target was browser-related credentials.
+- Investigate the parent process of the suspicious command to ensure it is not a legitimate application, specifically checking that it is not the Keeper Password Manager, as this is excluded in the rule.
+- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it suggests unauthorized access.
+- Review recent login and access logs for the system to identify any unusual or unauthorized access patterns that could correlate with the suspicious Keychain access attempt.
+- Assess the system for any additional indicators of compromise or related suspicious activities that might suggest a broader security incident.
+
+### False positive analysis
+
+- Legitimate password managers like Keeper Password Manager may trigger the rule due to their access to Keychain for managing user credentials. To handle this, ensure that the process parent executable path for such applications is added to the exclusion list.
+- System maintenance or administrative scripts that access Keychain for legitimate purposes might be flagged. Review these scripts and, if verified as safe, add their specific command patterns to the exception list.
+- Development or testing tools that interact with browsers and require Keychain access could cause false positives. Identify these tools and exclude their specific process names or command-line arguments if they are part of regular operations.
+- Automated backup or synchronization services that access browser credentials stored in Keychain may be mistakenly identified. Confirm these services' legitimacy and exclude their associated processes from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'security' command with the specified arguments targeting browsers.
+- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access attempts and determine the scope of the compromise.
+- Change all potentially compromised credentials stored in the keychain, including browser passwords and Wi-Fi credentials, and ensure they are updated across all relevant services.
+- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts to access keychain data using command-line tools.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.
+- Review and update endpoint security configurations to restrict unauthorized access to keychain data and enhance logging for keychain-related activities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_mitm_localhost_webproxy.toml b/rules/macos/credential_access_mitm_localhost_webproxy.toml
index 6e915a16c92..8351ac8e2ac 100644
--- a/rules/macos/credential_access_mitm_localhost_webproxy.toml
+++ b/rules/macos/credential_access_mitm_localhost_webproxy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,41 @@ event.category:process and host.os.type:macos and event.type:start and
                                   "/usr/libexec/xpcproxy") and
  not process.Ext.effective_parent.executable : ("/Applications/Proxyman.app/Contents/MacOS/Proxyman" or "/Applications/Incoggo.app/Contents/MacOS/Incoggo.app")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WebProxy Settings Modification
+
+Web proxy settings in macOS manage how web traffic is routed, often used to enhance security or manage network traffic. Adversaries may exploit these settings to redirect or intercept web traffic, potentially capturing sensitive data like credentials. The detection rule identifies suspicious use of the `networksetup` command to alter proxy settings, excluding known legitimate applications, thus highlighting potential unauthorized modifications indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of the networksetup command with arguments like -setwebproxy, -setsecurewebproxy, or -setautoproxyurl, which indicate an attempt to modify web proxy settings.
+- Check the parent process information to ensure it is not one of the known legitimate applications such as /Library/PrivilegedHelperTools/com.80pct.FreedomHelper or /Applications/Fiddler Everywhere.app/Contents/Resources/app/out/WebServer/Fiddler.WebUi.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine recent network traffic logs for unusual patterns or connections that could suggest traffic redirection or interception.
+- Look for any additional alerts or logs related to the same host or user that might indicate a broader pattern of suspicious activity.
+- Assess the system for any signs of compromise or unauthorized access, such as unexpected user accounts or changes to system configurations.
+
+### False positive analysis
+
+- Legitimate applications like FreedomHelper, Fiddler Everywhere, and xpcproxy may trigger the rule when they modify proxy settings. To prevent these from being flagged, ensure they are included in the exclusion list of known applications.
+- Network management tools such as Proxyman and Incoggo might also be detected. Add these to the exclusion list to avoid unnecessary alerts.
+- Regular system updates or configurations by IT administrators can sometimes involve proxy setting changes. Coordinate with IT to identify these activities and consider adding them to the exclusion criteria if they are routine and verified as safe.
+- Automated scripts or maintenance tasks that adjust proxy settings for legitimate reasons should be reviewed and, if deemed non-threatening, excluded from detection to reduce false positives.
+- Monitor for any new applications or processes that may need to be added to the exclusion list as part of ongoing security management to ensure the rule remains effective without generating excessive false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes related to the `networksetup` command that are not associated with known legitimate applications.
+- Review and reset the web proxy settings on the affected device to their default or intended configuration to ensure no malicious redirection is in place.
+- Conduct a thorough scan of the affected system using updated security tools to identify and remove any malware or unauthorized software that may have been installed.
+- Analyze logs and network traffic to identify any data that may have been intercepted or exfiltrated, focusing on sensitive information such as credentials.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
index 40b3b2d181e..983de60efa6 100644
--- a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
+++ b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,41 @@ type = "threshold"
 query = '''
 event.category:process and host.os.type:macos and event.type:start and process.name:"sshd-keygen-wrapper" and process.parent.name:launchd
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential macOS SSH Brute Force Detected
+
+SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-keygen-wrapper` process is involved in SSH key generation. Adversaries may exploit this by repeatedly attempting to generate keys to gain unauthorized access, a tactic known as brute force. The detection rule identifies unusual activity by monitoring for excessive executions of this process, indicating potential brute force attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the host and process information, specifically checking for the host.os.type as macos and the process.name as sshd-keygen-wrapper.
+- Examine the frequency and timing of the sshd-keygen-wrapper process executions to determine if they align with normal user activity or if they suggest an automated brute force attempt.
+- Investigate the parent process, launchd, to ensure it is legitimate and not being used maliciously to spawn the sshd-keygen-wrapper process.
+- Check for any recent successful or failed login attempts on the affected host to identify potential unauthorized access.
+- Correlate the activity with any other alerts or logs from the same host to identify patterns or additional indicators of compromise.
+- Review user account activity on the host to determine if any accounts have been accessed or modified unexpectedly.
+
+### False positive analysis
+
+- Legitimate administrative tasks may trigger the rule if an administrator is performing routine maintenance or updates that involve generating SSH keys. To handle this, create an exception for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or applications that require frequent SSH key generation for legitimate purposes can cause false positives. Identify these scripts or applications and exclude their associated processes or hosts from the detection rule.
+- Development environments where SSH keys are frequently generated for testing purposes might trigger the rule. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.
+- Continuous integration/continuous deployment (CI/CD) systems that automate SSH key generation as part of their workflow can be a source of false positives. Exclude these systems or their specific processes from the detection rule to avoid disruption.
+- If a known security tool or monitoring system is configured to test SSH key generation as part of its checks, it may trigger the rule. Verify the tool's activity and exclude its processes if deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS host from the network to prevent further unauthorized access attempts.
+- Terminate any suspicious or unauthorized `sshd-keygen-wrapper` processes running on the affected host to halt ongoing brute force attempts.
+- Review and reset SSH credentials for all user accounts on the affected host to ensure no unauthorized access has been achieved.
+- Implement IP blocking or rate limiting on the SSH service to prevent further brute force attempts from the same source.
+- Conduct a thorough review of the affected host's SSH configuration and logs to identify any unauthorized changes or access.
+- Escalate the incident to the security operations team for further investigation and to determine if additional hosts are affected.
+- Enhance monitoring and alerting for similar SSH brute force patterns across the network to improve early detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
index ac83ec10af5..4d362912e8f 100644
--- a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
+++ b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ process where event.action == "exec" and host.os.type == "macos" and
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon",
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Prompt for Credentials with OSASCRIPT
+
+OSASCRIPT is a macOS utility that allows the execution of AppleScript and other OSA language scripts. Adversaries may exploit it to display deceptive dialogs prompting users for credentials, mimicking legitimate requests. The detection rule identifies suspicious OSASCRIPT usage by monitoring specific command patterns and excluding known legitimate processes, thereby flagging potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the process command line to confirm if the osascript command includes suspicious patterns like "display dialog" with "password" or "passphrase" to determine if it is attempting to prompt for credentials.
+- Check the parent process executable to see if it matches any known legitimate applications or services, such as those listed in the exclusion criteria, to rule out false positives.
+- Investigate the user account associated with the process to determine if it is a privileged account or if there is any unusual activity associated with it.
+- Examine the process execution context, including the effective parent executable, to identify if the osascript was executed by a legitimate management tool or script.
+- Look for any other related alerts or logs around the same timeframe to identify if this is part of a broader attack or isolated incident.
+- Assess the risk and impact by determining if any credentials were potentially compromised and if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Legitimate administrative scripts using osascript may trigger alerts if they include dialog prompts for passwords or passphrases. To manage this, identify and exclude these scripts by adding their specific command lines or parent executables to the exception list.
+- Processes initiated by trusted applications like JAMF or Karabiner-Elements can be mistakenly flagged. Ensure these applications are included in the exclusion list to prevent unnecessary alerts.
+- Scheduled maintenance tasks that use osascript for legitimate purposes might be misidentified. Review and exclude these tasks by specifying their user IDs or command line patterns in the detection rule exceptions.
+- Custom scripts executed by system administrators for routine operations may appear suspicious. Document these scripts and add them to the exclusion criteria to avoid false positives.
+- Terminal-based automation tools that interact with osascript could be incorrectly flagged. Verify these tools and include their paths in the exclusion list to reduce false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious osascript process identified by the alert to stop any ongoing credential theft attempts.
+- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized access or changes made during the incident.
+- Reset credentials for any accounts that may have been compromised, ensuring that new passwords are strong and unique.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat.
+- Review and update endpoint security configurations to block unauthorized script execution and enhance detection capabilities for similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
index 6bbf5dbfbe9..3bea0df0a6b 100644
--- a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
+++ b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,40 @@ file where event.action == "open" and host.os.type == "macos" and process.execut
  not process.code_signature.signing_id : "org.mozilla.firefox" and
  not Effective_process.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Web Browser Sensitive File Access
+
+Web browsers store sensitive data like cookies and login credentials in specific files. Adversaries exploit this by accessing these files using untrusted or unsigned processes, potentially stealing credentials. The detection rule identifies such unauthorized access on macOS by monitoring file access events, focusing on untrusted processes or scripts, and excluding known safe executables, thus flagging potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the process executable path and name to determine if it is a known legitimate application or script, focusing on those not signed by trusted entities or identified as osascript.
+- Check the process code signature details to verify if the process is unsigned or untrusted, which could indicate malicious activity.
+- Investigate the user account associated with the process to determine if there is any unusual or unauthorized activity, such as unexpected logins or privilege escalations.
+- Examine the file access event details, including the specific sensitive file accessed (e.g., cookies.sqlite, logins.json), to assess the potential impact on credential security.
+- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader compromise.
+- Verify if the process executable path matches any known safe paths, such as the excluded path for the Elastic Endpoint, to rule out false positives.
+
+### False positive analysis
+
+- Access by legitimate applications: Some legitimate applications may access browser files for valid reasons, such as backup or synchronization tools. Users can create exceptions for these applications by adding their code signatures to the exclusion list.
+- Developer or testing scripts: Developers might use scripts like osascript for testing purposes, which could trigger the rule. To manage this, users can whitelist specific scripts or processes used in development environments.
+- Security software interactions: Security tools might access browser files as part of their scanning or monitoring activities. Users should verify the legitimacy of these tools and add them to the exclusion list if they are trusted.
+- System maintenance tasks: Automated system maintenance tasks might access browser files. Users can identify these tasks and exclude them if they are part of routine system operations and deemed safe.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any untrusted or unsigned processes identified in the alert, especially those accessing sensitive browser files.
+- Conduct a thorough review of the affected system's recent activity logs to identify any additional suspicious behavior or potential lateral movement.
+- Change all potentially compromised credentials, focusing on those stored in the affected web browsers, and enforce multi-factor authentication where possible.
+- Restore any altered or deleted sensitive files from a known good backup to ensure data integrity.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Update endpoint protection and monitoring tools to enhance detection capabilities for similar unauthorized access attempts in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/credential_access_systemkey_dumping.toml b/rules/macos/credential_access_systemkey_dumping.toml
index 01434aa4c83..64cf3ac5134 100644
--- a/rules/macos/credential_access_systemkey_dumping.toml
+++ b/rules/macos/credential_access_systemkey_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   process.args:("/private/var/db/SystemKey" or "/var/db/SystemKey") and
   not process.Ext.effective_parent.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SystemKey Access via Command Line
+
+macOS keychains securely store user credentials, including passwords and certificates. Adversaries may exploit command-line access to extract keychain data, gaining unauthorized credentials. The detection rule identifies suspicious process activities targeting SystemKey paths, excluding legitimate security processes, to flag potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the executable that attempted to access the SystemKey paths, focusing on the process.args field to confirm the presence of "/private/var/db/SystemKey" or "/var/db/SystemKey".
+- Investigate the parent process using process.Ext.effective_parent.executable to determine if the process chain is suspicious or if it might be a legitimate process that was not excluded by the rule.
+- Check the timestamp of the event to correlate with other system activities or user actions that might explain the access attempt.
+- Analyze the user account associated with the process to determine if it aligns with expected behavior or if it might indicate a compromised account.
+- Review recent system logs and security alerts for any other unusual activities or patterns that might suggest a broader compromise or targeted attack.
+- If possible, conduct a forensic analysis of the system to identify any unauthorized changes or additional indicators of compromise related to credential theft.
+
+### False positive analysis
+
+- Security software updates or scans may trigger the rule by accessing SystemKey paths. Users can create exceptions for known security applications that frequently access these paths, ensuring they are not flagged as threats.
+- System maintenance scripts or backup processes might access SystemKey paths as part of routine operations. Identify these processes and add them to an exclusion list to prevent false alerts.
+- Administrative tools used by IT departments for legitimate credential management could be mistakenly flagged. Verify these tools and configure the rule to exclude them from detection.
+- Custom scripts developed for internal use that interact with keychain data should be reviewed and, if deemed safe, added to the list of exceptions to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule that are accessing the SystemKey paths, ensuring no further credential extraction occurs.
+- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access attempts and determine the scope of the compromise.
+- Change all credentials stored in the keychain that may have been accessed, including Wi-Fi passwords, website credentials, and any other sensitive information.
+- Restore the system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is free from compromise.
+- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts to access keychain data, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures, such as notifying affected users or stakeholders."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_apple_softupdates_modification.toml b/rules/macos/defense_evasion_apple_softupdates_modification.toml
index 44a47192117..914473c3efa 100644
--- a/rules/macos/defense_evasion_apple_softupdates_modification.toml
+++ b/rules/macos/defense_evasion_apple_softupdates_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.name:defaults and
  process.args:(write and "-bool" and (com.apple.SoftwareUpdate or /Library/Preferences/com.apple.SoftwareUpdate.plist) and not (TRUE or true))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SoftwareUpdate Preferences Modification
+
+In macOS environments, the SoftwareUpdate preferences manage system updates, crucial for maintaining security. Adversaries may exploit the 'defaults' command to alter these settings, potentially disabling updates to evade defenses. The detection rule identifies such modifications by monitoring specific command executions that attempt to change update preferences without enabling them, signaling potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the 'defaults' command with arguments attempting to modify SoftwareUpdate preferences, specifically looking for 'write', '-bool', and the targeted preferences file paths.
+- Check the user account associated with the process execution to determine if it aligns with expected administrative activity or if it might be indicative of unauthorized access.
+- Investigate the host's recent activity for any other suspicious processes or commands that may suggest a broader attempt to impair system defenses or evade detection.
+- Examine system logs and security alerts around the time of the detected event to identify any correlated activities or anomalies that could provide additional context or evidence of malicious intent.
+- Assess the current state of the SoftwareUpdate preferences on the affected host to verify if updates have been disabled or altered, and take corrective actions if necessary.
+
+### False positive analysis
+
+- System administrators may use the defaults command to configure SoftwareUpdate settings during routine maintenance. To handle this, create exceptions for known administrative scripts or processes that frequently execute these commands.
+- Automated configuration management tools might alter SoftwareUpdate preferences as part of their standard operations. Identify these tools and exclude their process identifiers from triggering the rule.
+- Some legitimate applications may require specific update settings and modify preferences accordingly. Monitor and whitelist these applications to prevent unnecessary alerts.
+- User-initiated changes to update settings for personal preferences can trigger false positives. Educate users on the implications of such changes and consider excluding user-specific processes if they are consistently non-threatening.
+- During system setup or reconfiguration, defaults commands may be used to establish baseline settings. Temporarily disable the rule or set up a temporary exception during these periods to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential spread or further unauthorized changes.
+- Review the process execution logs to confirm the unauthorized use of the 'defaults' command and identify any associated user accounts or processes.
+- Revert any unauthorized changes to the SoftwareUpdate preferences by resetting them to their default state using the 'defaults' command with appropriate parameters.
+- Conduct a thorough scan of the affected system for additional signs of compromise, such as malware or unauthorized access attempts, using endpoint security tools.
+- Change passwords and review permissions for any user accounts involved in the incident to prevent further unauthorized access.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement enhanced monitoring for similar command executions across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
index 651cb2eae28..cb04d29b5e0 100644
--- a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
+++ b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,40 @@ process.executable : ("/usr/bin/xattr",
                       "/Applications/.com.bomgar.scc.*/Remote Support Customer Client.app/Contents/MacOS/sdcust") and not
 file.path : "/private/var/folders/*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Quarantine Attrib Removed by Unsigned or Untrusted Process
+
+In macOS, files downloaded from the internet are tagged with a quarantine attribute, which is checked by Gatekeeper to ensure safety before execution. Adversaries may remove this attribute to bypass security checks, allowing potentially harmful applications to run unchecked. The detection rule identifies such actions by monitoring for the removal of this attribute by processes that are either unsigned or untrusted, flagging unusual activity that deviates from expected behavior.
+
+### Possible investigation steps
+
+- Review the process executable path that triggered the alert to determine if it is a known or expected application on the system. Check if it matches any legitimate software that might not be properly signed.
+- Investigate the parent process of the flagged executable to understand the context of its execution. This can help identify if the process was spawned by a legitimate application or a potentially malicious one.
+- Examine the file path from which the quarantine attribute was removed to assess if it is a common location for downloaded files or if it appears suspicious.
+- Check the system for any recent downloads or installations that might correlate with the time of the alert to identify potential sources of the file.
+- Look into the user account under which the process was executed to determine if it aligns with expected user behavior or if it might indicate unauthorized access.
+- Search for any other alerts or logs related to the same process or file path to identify patterns or repeated attempts to bypass security measures.
+
+### False positive analysis
+
+- System processes or legitimate applications may occasionally remove the quarantine attribute as part of their normal operation. Users can create exceptions for known safe processes by adding them to the exclusion list in the detection rule.
+- Software updates or installations from trusted vendors might trigger the rule if they are not properly signed. Verify the legitimacy of the software and consider adding the specific executable path to the exclusion list if it is deemed safe.
+- Custom scripts or automation tools used within an organization might remove the quarantine attribute as part of their workflow. Review these scripts to ensure they are secure and add their paths to the exclusion list to prevent false positives.
+- Temporary files or directories, such as those in /private/var/folders, are already excluded to reduce noise. Ensure that any additional temporary paths used by trusted applications are similarly excluded if they are known to cause false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further compromise.
+- Terminate any untrusted or unsigned processes identified in the alert that are responsible for removing the quarantine attribute.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software.
+- Restore any affected files from a known good backup if they have been altered or compromised.
+- Review system logs and the specific file paths involved in the alert to identify any additional unauthorized changes or suspicious activity.
+- 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 additional monitoring and alerting for similar activities on other macOS systems to enhance detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
index 9cf185bb72a..aa9061e92dc 100644
--- a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
+++ b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
   process.args:(spctl and "--master-disable")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Disable Gatekeeper
+
+Gatekeeper is a macOS security feature that ensures only trusted software runs by verifying app signatures. Adversaries may attempt to disable it to execute unauthorized code, bypassing security checks. The detection rule identifies such attempts by monitoring process events for specific commands used to disable Gatekeeper, flagging potential defense evasion activities.
+
+### Possible investigation steps
+
+- Review the process event details to confirm the presence of the command `spctl --master-disable` in the `process.args` field, which indicates an attempt to disable Gatekeeper.
+- Identify the user account associated with the process event to determine if the action was initiated by a legitimate user or an unauthorized actor.
+- Check the `event.category` and `event.type` fields to ensure the event is categorized as a process start, which aligns with the rule's detection criteria.
+- Investigate the parent process of the flagged event to understand the context in which the Gatekeeper disabling attempt was made, looking for any suspicious or unexpected parent processes.
+- Examine recent process events on the same host to identify any subsequent or preceding suspicious activities that might indicate a broader attack or compromise.
+- Review system logs and other security alerts on the host for additional indicators of compromise or related malicious activities.
+- Assess the risk and impact of the event by considering the host's role, the sensitivity of data it handles, and any potential exposure resulting from the attempted Gatekeeper disablement.
+
+### False positive analysis
+
+- System administrators or IT personnel may intentionally disable Gatekeeper for legitimate software installations or troubleshooting. To manage this, create exceptions for known administrative accounts or specific maintenance windows.
+- Some legitimate applications may require Gatekeeper to be disabled temporarily for installation. Identify these applications and whitelist their installation processes to prevent false alerts.
+- Development environments on macOS might disable Gatekeeper to test unsigned applications. Consider excluding processes initiated by development tools or specific user accounts associated with development activities.
+- Automated scripts or management tools that configure macOS settings might trigger this rule. Review and adjust these scripts to ensure they are recognized as non-threatening, or exclude them from monitoring if they are verified as safe.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS device from the network to prevent potential lateral movement or further execution of unauthorized code.
+- Terminate any suspicious processes associated with the attempt to disable Gatekeeper, specifically those involving the 'spctl --master-disable' command.
+- Conduct a thorough review of recent system changes and installed applications on the affected device to identify and remove any unauthorized or malicious software.
+- Restore Gatekeeper settings to their default state to ensure that only trusted software can be executed on the device.
+- Escalate the incident to the security operations team for further analysis and to determine if additional devices or systems may be affected.
+- Implement additional monitoring on the affected device and similar systems to detect any further attempts to disable Gatekeeper or other security features.
+- Review and update endpoint security policies to enhance protection against similar threats, ensuring that all macOS devices are configured to prevent unauthorized changes to security settings."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_install_root_certificate.toml b/rules/macos/defense_evasion_install_root_certificate.toml
index c4d2d688080..126239ed7b4 100644
--- a/rules/macos/defense_evasion_install_root_certificate.toml
+++ b/rules/macos/defense_evasion_install_root_certificate.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,39 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
   not process.parent.executable:("/Library/Bitdefender/AVP/product/bin/BDCoreIssues" or "/Applications/Bitdefender/SecurityNetworkInstallerApp.app/Contents/MacOS/SecurityNetworkInstallerApp"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Install Root Certificate
+
+Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of digital certificates. Adversaries exploit this by installing unauthorized root certificates on compromised macOS systems, thereby bypassing security warnings and facilitating covert command and control communications. The detection rule identifies such activities by monitoring specific process executions related to certificate management, excluding known legitimate applications, thus highlighting potential malicious attempts to subvert trust controls.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the "security" process with the "add-trusted-cert" argument, as this indicates an attempt to add a root certificate.
+- Check the parent process of the suspicious activity to ensure it is not one of the known legitimate applications, such as Bitdefender, as specified in the exclusion list.
+- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Examine recent system logs and network activity for any signs of unauthorized access or communication with known malicious command and control servers.
+- Assess the system for any other indicators of compromise or unusual behavior that may suggest further malicious activity beyond the root certificate installation attempt.
+
+### False positive analysis
+
+- Security software installations or updates may trigger the rule as they often involve legitimate root certificate installations. Users can handle this by adding exceptions for known security software paths, such as Bitdefender, to prevent unnecessary alerts.
+- System administrators performing routine maintenance or updates might install root certificates as part of their tasks. To mitigate this, create exceptions for processes executed by trusted admin accounts or during scheduled maintenance windows.
+- Some enterprise applications may require the installation of root certificates for internal communications. Identify these applications and exclude their processes from the rule to avoid false positives.
+- Development environments on macOS systems might involve testing with self-signed certificates, which could trigger the rule. Developers can be instructed to use designated test environments or have their processes excluded during development phases.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized communications and potential data exfiltration.
+- Revoke any unauthorized root certificates installed on the system by accessing the Keychain Access application and removing the suspicious certificates from the System Roots keychain.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized changes or suspicious activities that may have occurred alongside the root certificate installation.
+- Restore the system to a known good state using backups or system snapshots taken prior to the compromise, ensuring that any malicious changes are reverted.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems in the network may be affected.
+- Implement enhanced monitoring and alerting for similar activities by refining detection capabilities to include additional indicators of compromise (IOCs) related to unauthorized certificate installations.
+- Review and update security policies and configurations to prevent unauthorized certificate installations, such as enforcing stricter access controls and requiring administrative approval for certificate management actions."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_modify_environment_launchctl.toml b/rules/macos/defense_evasion_modify_environment_launchctl.toml
index 4cd4dfee4f8..5df2a7a4be7 100644
--- a/rules/macos/defense_evasion_modify_environment_launchctl.toml
+++ b/rules/macos/defense_evasion_modify_environment_launchctl.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,40 @@ event.category:process and host.os.type:macos and event.type:start and
                                   /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or 
                                   /usr/local/bin/kr)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Environment Variable via Unsigned or Untrusted Parent
+
+Environment variables in macOS are crucial for configuring system and application behavior. Adversaries may exploit these by using the `launchctl` command to alter variables, enabling malicious payload execution or bypassing restrictions. The detection rule identifies suspicious modifications initiated by untrusted or unsigned parent processes, focusing on atypical environment variables and excluding known safe executables, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent process of the `launchctl` command, focusing on whether the parent process is unsigned or untrusted, as indicated by the absence or lack of trust in the `process.parent.code_signature`.
+- Examine the command-line arguments used with `launchctl`, specifically looking for the `setenv` command and any unusual or suspicious environment variables that are not part of the known safe list (e.g., ANT_HOME, DBUS_LAUNCHD_SESSION_BUS_SOCKET).
+- Check the execution path of the parent process to determine if it matches any known safe executables, such as those listed in the exclusion criteria (e.g., /Applications/IntelliJ IDEA CE.app/Contents/jbr/Contents/Home/lib/jspawnhelper).
+- Investigate the user account under which the `launchctl` command was executed to determine if it aligns with expected behavior or if it might indicate a compromised account.
+- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest a broader attack or intrusion attempt.
+
+### False positive analysis
+
+- Development tools like IntelliJ IDEA may trigger false positives when using the jspawnhelper executable. To mitigate this, add the executable path to the exclusion list if it is a known and trusted application in your environment.
+- NoMachine software can cause false positives due to its use of nxserver.bin. If this software is regularly used and trusted, consider excluding its executable path from the detection rule.
+- The kr tool located at /usr/local/bin/kr might be flagged as a false positive. If this tool is part of your standard operations, ensure its path is excluded to prevent unnecessary alerts.
+- Review any other unsigned or untrusted parent processes that are part of legitimate software installations or operations. If they are verified as safe, add them to the exclusion list to reduce false positives.
+- Regularly update the list of known safe executables and environment variables to reflect changes in your software inventory, ensuring that legitimate processes are not mistakenly flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further exploitation.
+- Terminate any suspicious processes associated with the untrusted or unsigned parent process that initiated the `launchctl` command to halt any ongoing malicious activity.
+- Conduct a thorough review of the environment variables modified by the `launchctl` command to identify any unauthorized changes and revert them to their original state.
+- Analyze the parent process that triggered the alert to determine its origin and purpose, and remove any malicious or unauthorized software identified during this analysis.
+- Restore the system from a known good backup if any critical system components or configurations have been compromised.
+- Implement additional monitoring and logging for `launchctl` usage and environment variable modifications to detect similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
index 044d6b27ab3..6db47ecdccb 100644
--- a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
+++ b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
  process.args : "/*/Application Support/com.apple.TCC/TCC.db" and
  not process.parent.executable : "/Library/Bitdefender/AVP/product/bin/*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privacy Control Bypass via TCCDB Modification
+
+The Transparency, Consent, and Control (TCC) database in macOS manages app permissions for accessing sensitive resources. Adversaries may exploit this by using tools like sqlite3 to alter the TCC database, bypassing privacy controls. The detection rule identifies such attempts by monitoring for suspicious sqlite3 activity targeting the TCC database, excluding legitimate processes, to flag potential privacy control bypasses.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of sqlite3, focusing on the process name and arguments to ensure they match the pattern "sqlite*" and include the path "/*/Application Support/com.apple.TCC/TCC.db".
+- Investigate the parent process of the sqlite3 activity to determine if it is a known legitimate process or if it appears suspicious, especially if it is not from "/Library/Bitdefender/AVP/product/bin/*".
+- Check the timestamp of the sqlite3 activity to correlate it with any other unusual system behavior or alerts that occurred around the same time.
+- Examine the user account associated with the process to determine if it has a history of legitimate administrative actions or if it might be compromised.
+- Look for any recent changes or anomalies in the TCC database permissions that could indicate unauthorized modifications.
+- Assess the system for other signs of compromise, such as unexpected network connections or additional unauthorized processes running, to determine if the sqlite3 activity is part of a larger attack.
+
+### False positive analysis
+
+- Security software like Bitdefender may legitimately access the TCC database for scanning purposes. To prevent these from being flagged, ensure that the process parent executable path for such software is added to the exclusion list.
+- System maintenance tools that perform regular checks or backups might access the TCC database. Identify these tools and add their process paths to the exclusion list to avoid false alerts.
+- Developer tools used for testing applications may interact with the TCC database. If these tools are frequently used in your environment, consider excluding their process paths to reduce noise.
+- Administrative scripts that automate system configurations might modify the TCC database. Review these scripts and, if deemed safe, exclude their process paths from the detection rule.
+- Regular system updates or patches could trigger access to the TCC database. Monitor these events and, if consistent with update schedules, adjust the rule to exclude these specific update processes.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious sqlite3 processes identified in the alert to stop ongoing unauthorized modifications to the TCC database.
+- Restore the TCC database from a known good backup to ensure that all privacy settings are reverted to their legitimate state.
+- Conduct a thorough review of recent changes to the TCC database to identify any unauthorized access or modifications to sensitive resources.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system to detect any further attempts to modify the TCC database or other unauthorized activities.
+- Review and update access controls and permissions for the TCC database to ensure only authorized processes can make changes, reducing the risk of future bypass attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
index 0e9e1000b8e..4c65154d179 100644
--- a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
+++ b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
  process.command_line:("scp *localhost:/*", "scp *127.0.0.1:/*") and
  not process.args:"vagrant@*127.0.0.1*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privacy Control Bypass via Localhost Secure Copy
+
+Secure Copy Protocol (SCP) is used for secure file transfers over SSH. On macOS, SSH daemon inclusion in the Full Disk Access list can be exploited to bypass privacy controls. Adversaries may misuse SCP to locally copy files, evading security measures. The detection rule identifies such activity by monitoring SCP commands targeting localhost, excluding benign uses like Vagrant, to flag potential privacy control bypass attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of SCP commands targeting localhost or 127.0.0.1, as indicated by the process.command_line field.
+- Check the process.args field for the presence of "StrictHostKeyChecking=no" to verify if the SCP command was executed with potentially insecure settings.
+- Investigate the user account associated with the SCP command to determine if it is a legitimate user or potentially compromised.
+- Examine the timing and frequency of the SCP command execution to identify any unusual patterns or repeated attempts that may indicate malicious activity.
+- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or anomalies around the same timeframe.
+- Assess the system for any unauthorized changes or access to sensitive files that may have occurred as a result of the SCP command execution.
+
+### False positive analysis
+
+- Vagrant usage can trigger false positives due to its legitimate use of SCP for local file transfers. To mitigate this, ensure that Vagrant-related SCP commands are excluded by refining the detection rule to ignore processes with arguments containing "vagrant@*127.0.0.1*".
+- Development and testing environments may frequently use SCP to localhost for legitimate purposes. Consider creating exceptions for known development tools or scripts that regularly perform these actions to reduce noise.
+- Automated backup solutions might use SCP to copy files locally as part of their routine operations. Identify and whitelist these processes to prevent them from being flagged as potential threats.
+- System administrators may use SCP for local file management tasks. Establish a list of trusted administrator accounts or specific command patterns that can be safely excluded from triggering alerts.
+- Continuous integration and deployment pipelines might involve SCP commands to localhost. Review and exclude these processes if they are part of a controlled and secure workflow.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious SCP processes identified in the alert to halt ongoing unauthorized file transfers.
+- Conduct a thorough review of the system's Full Disk Access list to identify and remove any unauthorized applications, including the SSH daemon if it was added without proper authorization.
+- Analyze the system's SSH configuration and logs to identify any unauthorized changes or access patterns, and revert any suspicious modifications.
+- Reset credentials for any accounts that may have been compromised, focusing on those with SSH access, and enforce the use of strong, unique passwords.
+- Implement network monitoring to detect and alert on any future SCP commands targeting localhost, especially those bypassing host key checks.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on sensitive data, ensuring compliance with organizational incident response protocols."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_safari_config_change.toml b/rules/macos/defense_evasion_safari_config_change.toml
index 599eef17f93..1a588fb6a96 100644
--- a/rules/macos/defense_evasion_safari_config_change.toml
+++ b/rules/macos/defense_evasion_safari_config_change.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,40 @@ event.category:process and host.os.type:macos and event.type:start and
       )
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Safari Settings via Defaults Command
+
+The 'defaults' command in macOS is a utility that allows users to read, write, and manage macOS application preferences, including Safari settings. Adversaries may exploit this command to alter Safari configurations, potentially enabling harmful features like JavaScript from Apple Events, which can facilitate browser hijacking. The detection rule monitors for suspicious 'defaults' command usage targeting Safari settings, excluding benign preference changes, to identify potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the 'defaults' command with arguments targeting Safari settings, specifically looking for any suspicious or unauthorized changes.
+- Check the user account associated with the process execution to determine if the action was performed by a legitimate user or an unauthorized entity.
+- Investigate the system's recent activity logs to identify any other unusual or suspicious behavior around the time the 'defaults' command was executed.
+- Examine the Safari settings before and after the change to assess the impact and identify any potentially harmful configurations, such as enabling JavaScript from Apple Events.
+- Correlate the event with other security alerts or incidents to determine if this action is part of a broader attack or compromise attempt.
+
+### False positive analysis
+
+- Changes to Safari settings for legitimate user preferences can trigger alerts, such as enabling or disabling search suggestions. Users can create exceptions for these specific settings by excluding them from the detection rule.
+- System administrators may use the defaults command to configure Safari settings across multiple devices for compliance or user experience improvements. These actions can be whitelisted by identifying the specific process arguments used in these administrative tasks.
+- Automated scripts or management tools that adjust Safari settings as part of routine maintenance or updates may cause false positives. Users should identify these scripts and exclude their specific process arguments from the detection rule.
+- Developers testing Safari configurations might frequently change settings using the defaults command. Excluding known developer machines or user accounts from the rule can help reduce false positives.
+- Educational or training environments where users are instructed to modify Safari settings for learning purposes can lead to alerts. Identifying and excluding these environments or sessions can mitigate unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS device from the network to prevent further malicious activity or data exfiltration.
+- Terminate any suspicious processes related to the 'defaults' command that are currently running on the affected device.
+- Revert any unauthorized changes made to Safari settings by restoring them to their default or previously known safe state.
+- Conduct a thorough scan of the affected device using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or malicious scripts.
+- Review and update the device's security settings to prevent unauthorized changes, including disabling unnecessary Apple Events and restricting the use of the 'defaults' command to authorized personnel only.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other devices in the network are affected.
+- Implement enhanced monitoring and alerting for similar 'defaults' command usage across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
index 0c821e217e4..a3072ad7fef 100644
--- a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
+++ b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ type = "query"
 query = '''
 event.category:file and host.os.type:(macos and macos) and not event.type:deletion and file.name:~$*.zip
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Microsoft Office Sandbox Evasion
+
+Microsoft Office applications on macOS operate within a sandbox to limit potential damage from malicious files. However, adversaries can exploit this by creating zip files with special character prefixes, bypassing sandbox restrictions. The detection rule identifies such files, focusing on non-deletion events with specific naming patterns, to flag potential evasion attempts and mitigate risks.
+
+### Possible investigation steps
+
+- Review the file creation event details to confirm the presence of a zip file with a name starting with special characters, as indicated by the file.name field.
+- Examine the file path and location to determine if it aligns with known AutoStart locations, which could indicate an attempt to achieve persistence.
+- Investigate the user account associated with the event to assess if the activity is expected or if the account may have been compromised.
+- Check for any related events or activities on the same host around the time of the alert, such as other file creations or modifications, to identify potential patterns or additional suspicious behavior.
+- Analyze the host's recent network activity to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server.
+- Correlate the event with other alerts or logs from the same host or user to build a comprehensive timeline of activities and assess the broader impact or intent.
+
+### False positive analysis
+
+- Files with special character prefixes created by legitimate applications or processes, such as temporary files generated by Microsoft Office during normal operations, may trigger the rule. Users can create exceptions for known benign applications that frequently generate such files.
+- Automated backup or synchronization tools that compress files into zip archives with special character prefixes might be flagged. Identify these tools and exclude their file creation events from the rule.
+- Development or testing environments where zip files with special character prefixes are used for legitimate purposes can cause false positives. Implement exclusions for these environments to prevent unnecessary alerts.
+- User-generated zip files with special character prefixes for personal organization or naming conventions may be mistakenly identified. Educate users on naming conventions and adjust the rule to exclude specific user directories if needed.
+
+### Response and remediation
+
+- Isolate the affected macOS system from the network to prevent further potential spread or data exfiltration.
+- Quarantine the suspicious zip file to prevent execution and further analysis.
+- Conduct a thorough scan of the system using updated antivirus and endpoint detection tools to identify and remove any additional malicious files or processes.
+- Review and secure AutoStart locations on the affected system to prevent unauthorized applications from executing at startup.
+- Restore any affected files from a known good backup to ensure system integrity and continuity.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems may be affected.
+- Update security policies and endpoint protection configurations to block the creation and execution of files with suspicious naming patterns, enhancing future detection and prevention capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
index 8accc83b579..5dae1f3e625 100644
--- a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
+++ b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,39 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:mount_apfs and
   process.args:(/System/Volumes/Data and noowners)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 TCC Bypass via Mounted APFS Snapshot Access
+
+Apple's TCC framework safeguards user data by controlling app access to sensitive files. Adversaries exploit APFS snapshots, mounting them with specific flags to bypass these controls, gaining unauthorized access to protected data. The detection rule identifies this misuse by monitoring the execution of the `mount_apfs` command with parameters indicative of such bypass attempts, flagging potential security breaches.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `mount_apfs` command with the specific arguments `/System/Volumes/Data` and `noowners` to verify the alert's accuracy.
+- Investigate the user account associated with the process execution to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
+- Examine the timeline of events leading up to and following the alert to identify any related suspicious activities or processes that may indicate a broader attack or compromise.
+- Check for any recent changes or anomalies in system configurations or user permissions that could have facilitated the bypass attempt.
+- Correlate the alert with other security logs or alerts to assess if this is part of a larger pattern of malicious behavior or an isolated incident.
+
+### False positive analysis
+
+- System maintenance tools or backup software may legitimately use the mount_apfs command with the noowners flag for routine operations. Users can create exceptions for these specific tools by identifying their process names or paths and excluding them from the detection rule.
+- Developers or IT administrators might use the mount_apfs command during testing or troubleshooting. To prevent these activities from triggering false positives, users can whitelist specific user accounts or IP addresses associated with these roles.
+- Automated scripts or scheduled tasks that require access to APFS snapshots for legitimate purposes might trigger the rule. Users should review these scripts and, if deemed safe, add them to an exclusion list based on their unique identifiers or execution context.
+- Security software or monitoring tools that perform regular checks on file system integrity might inadvertently match the rule's criteria. Users can mitigate this by identifying these tools and excluding their specific process signatures from the detection parameters.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes related to the `mount_apfs` command to halt ongoing unauthorized access attempts.
+- Conduct a thorough review of system logs and user activity to identify any data accessed or exfiltrated during the breach.
+- Restore any compromised files from a known good backup to ensure data integrity and security.
+- Update macOS and all installed applications to the latest versions to patch any vulnerabilities that may have been exploited.
+- Implement stricter access controls and monitoring for APFS snapshot usage to prevent similar bypass attempts in the future.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for additional security measures."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
index 332860d1f4b..e5436e0a571 100644
--- a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
+++ b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,40 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:kextunload and process.args:("/System/Library/Extensions/EndpointSecurity.kext" or "EndpointSecurity.kext")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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]]
diff --git a/rules/macos/discovery_users_domain_built_in_commands.toml b/rules/macos/discovery_users_domain_built_in_commands.toml
index bc38d1d3874..4e494cdbc57 100644
--- a/rules/macos/discovery_users_domain_built_in_commands.toml
+++ b/rules/macos/discovery_users_domain_built_in_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                  "/Applications/NoMAD.app/Contents/MacOS/NoMAD",
                                                  "/Applications/ESET Management Agent.app/Contents/MacOS/ERAAgent")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Enumeration of Users or Groups via Built-in Commands
+
+Built-in macOS commands like `ldapsearch`, `dsmemberutil`, and `dscl` are essential for managing and querying user and group information. Adversaries exploit these to gather insights into system accounts and groups, aiding in lateral movement or privilege escalation. The detection rule identifies suspicious use of these commands, especially when executed from non-standard parent processes, excluding known legitimate applications, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific command executed, focusing on the process name and arguments, such as "ldapsearch", "dsmemberutil", or "dscl" with specific arguments like "read", "list", or "search".
+- Examine the parent process information, including the executable path and name, to determine if the command was launched from a non-standard or suspicious parent process.
+- Check the exclusion list of known legitimate applications to ensure the alert was not triggered by a benign process, such as those from QualysCloudAgent, Kaspersky, or ESET.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
+- Correlate the event with other logs or alerts to identify any patterns of suspicious activity, such as repeated enumeration attempts or other discovery tactics.
+- Assess the system's recent activity for signs of lateral movement or privilege escalation attempts that may follow the enumeration of users or groups.
+
+### False positive analysis
+
+- Security and management tools like QualysCloudAgent, Kaspersky Anti-Virus, and ESET Endpoint Security may trigger false positives due to their legitimate use of built-in commands for system monitoring. To mitigate this, add these applications to the exclusion list in the detection rule.
+- Development environments such as Xcode might execute these commands during normal operations. If Xcode is frequently triggering alerts, consider excluding its executable path from the rule.
+- VPN and network management applications like NordVPN and Zscaler may use these commands for network configuration and user management. Exclude these applications if they are known to be safe and frequently used in your environment.
+- Parallels Desktop and similar virtualization software might access user and group information as part of their functionality. If these applications are trusted, add their executable paths to the exclusion list.
+- Regular administrative tasks performed by IT personnel using NoMAD or similar tools can also cause false positives. Ensure these tools are excluded if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving `ldapsearch`, `dsmemberutil`, or `dscl` commands executed from non-standard parent processes.
+- Conduct a thorough review of user and group accounts on the affected system to identify any unauthorized changes or additions, and revert any suspicious modifications.
+- Reset passwords for all user accounts on the affected system, prioritizing those with administrative privileges, to mitigate potential unauthorized access.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement additional monitoring on the affected system and network to detect any further unauthorized enumeration attempts or related suspicious activities.
+- Review and update endpoint security configurations to ensure that legitimate applications are properly whitelisted and that unauthorized applications are blocked from executing enumeration commands."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
index 37396801ec4..4da73c928c5 100644
--- a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
+++ b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ type = "query"
 query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and process.args:("-e" and const*require*child_process*)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution via Electron Child Process Node.js Module
+
+Electron applications, built on Node.js, can execute child processes using the `child_process` module, inheriting parent process permissions. Adversaries exploit this to execute unauthorized commands, bypassing security controls. The detection rule identifies suspicious process starts on macOS, focusing on command-line arguments indicative of such abuse, aiding in threat detection and mitigation.
+
+### Possible investigation steps
+
+- Review the process arguments captured in the alert to confirm the presence of suspicious patterns, such as the use of "-e" and the inclusion of "require('child_process')".
+- Identify the parent Electron application process to determine if it is a legitimate application or potentially malicious.
+- Check the user account associated with the process to assess if it has elevated privileges that could be exploited.
+- Investigate the command executed by the child process to understand its purpose and potential impact on the system.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
+- Examine the network activity of the host around the time of the alert to detect any unauthorized data exfiltration or communication with known malicious IPs.
+
+### False positive analysis
+
+- Legitimate Electron applications may use the child_process module for valid operations, such as launching helper scripts or tools. Users should identify and whitelist these known applications to prevent unnecessary alerts.
+- Development environments often execute scripts using child_process during testing or debugging. Exclude processes originating from development directories or environments to reduce false positives.
+- Automated build or deployment tools running on macOS might invoke child processes as part of their workflow. Recognize and exclude these tools by their process names or paths.
+- Some Electron-based applications might use command-line arguments that match the detection pattern for legitimate reasons. Review and adjust the detection rule to exclude these specific argument patterns when associated with trusted applications.
+- Regularly review and update the exclusion list to accommodate new legitimate use cases as they arise, ensuring that the detection rule remains effective without generating excessive false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized command execution and potential lateral movement.
+- Terminate any suspicious child processes identified as being spawned by the Electron application to halt any ongoing malicious activity.
+- Conduct a thorough review of the Electron application's code and configuration to identify and remove any unauthorized or malicious scripts or modules, particularly those involving the `child_process` module.
+- Revoke and reset any credentials or tokens that may have been exposed or compromised due to the unauthorized execution, ensuring that new credentials are distributed securely.
+- Apply security patches and updates to the Electron application and underlying Node.js environment to mitigate any known vulnerabilities that could be exploited in a similar manner.
+- Enhance monitoring and logging on the affected system and similar environments to detect any future attempts to exploit the `child_process` module, focusing on command-line arguments and process creation events.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been impacted, ensuring a comprehensive response to the threat."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
index a0c384dc8ef..637fd295c85 100644
--- a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
+++ b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -82,6 +82,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
       "/usr/local/*brew*"
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Browser Child Process
+
+Web browsers are integral to user interaction with the internet, often serving as gateways for adversaries to exploit vulnerabilities. Attackers may execute malicious scripts or commands by spawning child processes from browsers, leveraging scripting languages or command-line tools. The detection rule identifies unusual child processes initiated by browsers on macOS, filtering out known benign activities to highlight potential threats, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the process command line to understand the context of the execution and identify any potentially malicious scripts or commands.
+- Check the parent process name to confirm it is one of the specified browsers (e.g., Google Chrome, Safari) and verify if the browser was expected to be running at the time of the alert.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if the account may have been compromised.
+- Examine the network activity around the time of the alert to identify any suspicious connections or data transfers that may indicate further malicious activity.
+- Look for any related alerts or logs that might provide additional context or evidence of a broader attack or compromise.
+- Assess the risk and impact of the detected activity by considering the severity and risk score provided, and determine if immediate response actions are necessary.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they use shell scripts or command-line tools. Users can create exceptions for known update paths, such as those related to Microsoft AutoUpdate or Google Chrome installations, to prevent these from being flagged.
+- Development or testing activities involving scripting languages like Python or shell scripts may be mistakenly identified as threats. Users should consider excluding specific development directories or command patterns that are frequently used in their workflows.
+- Automated scripts or tools that interact with web browsers for legitimate purposes, such as web scraping or data collection, might be detected. Users can whitelist these processes by specifying their command-line arguments or paths to avoid false positives.
+- System administration tasks that involve remote management or configuration changes via command-line tools could be misinterpreted as suspicious. Users should identify and exclude these routine administrative commands to reduce unnecessary alerts.
+- Browser extensions or plugins that execute scripts for enhanced functionality might trigger the rule. Users should review and whitelist trusted extensions that are known to execute benign scripts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement by the adversary.
+- Terminate the suspicious child process identified in the alert to halt any ongoing malicious execution.
+- Conduct a thorough review of the browser's recent activity and history to identify any potentially malicious websites or downloads that may have triggered the alert.
+- Remove any malicious files or scripts that were executed by the suspicious child process to prevent further exploitation.
+- Apply the latest security patches and updates to the affected browser and macOS system to mitigate known vulnerabilities that could be exploited.
+- Monitor the system for any signs of persistence mechanisms or additional suspicious activity, ensuring that no backdoors or unauthorized access points remain.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_installer_package_spawned_network_event.toml b/rules/macos/execution_installer_package_spawned_network_event.toml
index 2e53cc22289..d80066cf445 100644
--- a/rules/macos/execution_installer_package_spawned_network_event.toml
+++ b/rules/macos/execution_installer_package_spawned_network_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,41 @@ sequence by host.id with maxspan=15s
 [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and process.parent.name : ("installer", "package_script_service") and process.name : ("bash", "sh", "zsh", "python", "osascript", "tclsh*")] by process.entity_id
 [network where host.os.type == "macos" and event.type == "start" and process.name : ("curl", "osascript", "wget", "python", "java", "ruby", "node")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 MacOS Installer Package Spawns Network Event
+
+MacOS installer packages, often with a .pkg extension, are used to distribute software. Adversaries exploit this by embedding scripts to execute additional commands or download malicious payloads. The detection rule identifies suspicious behavior by monitoring for installer packages spawning shell processes followed by network activity, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process details to identify the parent process name and entity ID, focusing on processes like "installer" or "package_script_service" that initiated the suspicious activity.
+- Examine the child process that was spawned, such as "bash", "sh", or "python", to determine the commands executed and assess if they align with typical installation behavior or appear malicious.
+- Investigate the network activity associated with the suspicious process, particularly looking at processes like "curl" or "wget", to identify any external connections made and the destination IP addresses or domains.
+- Check the timestamp and sequence of events to confirm if the network activity closely followed the process execution, indicating a potential download or data exfiltration attempt.
+- Analyze any downloaded files or payloads for malicious content using threat intelligence tools or sandbox environments to determine their intent and potential impact.
+- Correlate the findings with known threat actor tactics or campaigns, leveraging threat intelligence sources to assess if the activity matches any known patterns or indicators of compromise.
+
+### False positive analysis
+
+- Legitimate software installations may trigger this rule if they use scripts to configure network settings or download updates. Users can create exceptions for known safe software by whitelisting specific installer package names or hashes.
+- System administrators often use scripts to automate software deployment and updates, which might involve network activity. To reduce false positives, exclude processes initiated by trusted administrative tools or scripts.
+- Development environments on macOS might execute scripts that connect to the internet for dependencies or updates. Users can mitigate this by excluding processes associated with known development tools or environments.
+- Some security tools or monitoring software may use scripts to perform network checks or updates. Identify and exclude these processes if they are verified as non-threatening.
+- Frequent updates from trusted software vendors might trigger this rule. Users should maintain an updated list of trusted vendors and exclude their processes from triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected MacOS system from the network immediately to prevent further malicious activity or data exfiltration.
+- Terminate any suspicious processes identified in the alert, such as those initiated by the installer package, to halt ongoing malicious actions.
+- Conduct a thorough review of the installed applications and remove any unauthorized or suspicious software, especially those with a .pkg extension.
+- Restore the system from a known good backup if available, ensuring that the backup predates the installation of the malicious package.
+- Update and patch the MacOS system and all installed applications to the latest versions to mitigate vulnerabilities that could be exploited by similar threats.
+- Monitor network traffic for any signs of command and control communication or data exfiltration attempts, using the indicators identified in the alert.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_script_via_automator_workflows.toml b/rules/macos/execution_script_via_automator_workflows.toml
index 55faccc4136..d9b13b3205c 100644
--- a/rules/macos/execution_script_via_automator_workflows.toml
+++ b/rules/macos/execution_script_via_automator_workflows.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,39 @@ sequence by host.id with maxspan=30s
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "automator"]
  [network where host.os.type == "macos" and process.name:"com.apple.automator.runner"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Automator Workflows Execution
+
+Automator, a macOS utility, allows users to automate repetitive tasks through workflows. Adversaries can exploit this by embedding malicious JavaScript for Automation (JXA) in custom workflows, executing harmful scripts. The detection rule identifies this threat by monitoring the Automator process and subsequent network activity, flagging potential misuse when these actions occur in quick succession.
+
+### Possible investigation steps
+
+- Review the process execution details for the Automator process on the affected host, focusing on the timestamp and user context to determine if the execution was expected or authorized.
+- Examine the network activity associated with the com.apple.automator.runner process to identify any unusual or suspicious external connections, including destination IP addresses and domains.
+- Check for any recent changes or additions to Automator workflows on the host, especially those containing JavaScript for Automation (JXA) code, to identify potential malicious modifications.
+- Investigate the user account associated with the Automator process execution to determine if there are any signs of compromise or unauthorized access.
+- Correlate the alert with other security events or logs from the same host around the same timeframe to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Legitimate Automator workflows: Users may have legitimate workflows that trigger network connections, such as automated data uploads or API calls. To handle these, identify and document known safe workflows and create exceptions for them in the detection rule.
+- Frequent developer activity: Developers using Automator for testing or development purposes might frequently trigger this rule. Consider excluding specific user accounts or development environments from the rule to reduce noise.
+- System maintenance tasks: Some system maintenance or administrative tasks might use Automator workflows that connect to the network. Review and whitelist these tasks if they are verified as non-threatening.
+- Third-party applications: Certain third-party applications may use Automator workflows as part of their normal operation. Identify these applications and exclude their processes from the rule if they are deemed safe.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS host from the network to prevent further malicious activity and potential lateral movement.
+- Terminate the Automator process and any associated XPC services, such as "com.apple.automator.runner," to stop the execution of the malicious workflow.
+- Conduct a thorough review of the affected system to identify and remove any malicious JavaScript for Automation (JXA) scripts or custom workflow templates that may have been dropped by the adversary.
+- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
+- Implement additional monitoring on the affected host and similar systems to detect any recurrence of suspicious Automator activity, focusing on process and network activity patterns.
+- Update endpoint protection and intrusion detection systems to recognize and block similar threats in the future, leveraging the MITRE ATT&CK framework details for enhanced detection capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
index d643bd904f1..798da4ac8b2 100644
--- a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
+++ b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,41 @@ sequence by host.id, process.entity_id with maxspan=30s
     "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")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Apple Script Execution followed by Network Connection
+
+AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries exploit it to execute scripts that establish unauthorized network connections, facilitating command and control activities. The detection rule identifies such abuse by monitoring the osascript process for script execution followed by network activity, excluding local and private IP ranges, within a short timeframe.
+
+### Possible investigation steps
+
+- Review the process details for the osascript execution event, focusing on the process.entity_id and host.id to understand the context of the script execution.
+- Examine the network connection details associated with the osascript process, particularly the destination IP address, to determine if it is known or suspicious, and check if it falls outside the excluded IP ranges.
+- Investigate the script content or command line arguments used in the osascript execution to identify any potentially malicious or unexpected behavior.
+- Check the timeline of events to see if there are any other related or suspicious activities occurring on the same host around the time of the osascript execution and network connection.
+- Correlate the osascript activity with any other alerts or logs from the same host to identify patterns or additional indicators of compromise.
+- Assess the user account associated with the osascript process to determine if it is a legitimate user or if there are signs of account compromise.
+
+### False positive analysis
+
+- Legitimate automation scripts may trigger the rule if they execute osascript and establish network connections. Review the script's purpose and source to determine if it is authorized.
+- System management tools that use AppleScript for remote administration can cause false positives. Identify these tools and consider creating exceptions for their known processes.
+- Software updates or applications that use AppleScript for network communication might be flagged. Verify the application's legitimacy and update the rule to exclude these specific processes or IP addresses.
+- Development environments that utilize AppleScript for testing or deployment may inadvertently match the rule. Ensure these environments are recognized and excluded from monitoring if they are trusted.
+- Regularly review and update the list of excluded IP ranges and processes to ensure they reflect the current network and application landscape, minimizing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the osascript process identified in the alert to stop any ongoing malicious activity.
+- Conduct a thorough review of the executed AppleScript to identify any malicious commands or payloads and remove any associated files or scripts from the system.
+- Reset credentials for any accounts that were accessed or could have been compromised during the incident.
+- Apply security patches and updates to the macOS system to address any vulnerabilities that may have been exploited.
+- Monitor network traffic for any further suspicious activity originating from the affected host or similar patterns across other systems.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/execution_shell_execution_via_apple_scripting.toml b/rules/macos/execution_shell_execution_via_apple_scripting.toml
index c0c517e9ea0..fdb677c6d47 100644
--- a/rules/macos/execution_shell_execution_via_apple_scripting.toml
+++ b/rules/macos/execution_shell_execution_via_apple_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ sequence by host.id with maxspan=5s
  [process where host.os.type == "macos" and event.type in ("start", "process_started", "info") and process.name == "osascript" and process.args : "-e"] by process.entity_id
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : ("sh", "bash", "zsh") and process.args == "-c" and process.args : ("*curl*", "*pbcopy*", "*http*", "*chmod*")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Shell Execution via Apple Scripting
+
+AppleScript and JXA are scripting languages used in macOS to automate tasks and control applications. Adversaries exploit these by executing shell commands through functions like `doShellScript`, enabling unauthorized actions such as data exfiltration or system modification. The detection rule identifies suspicious shell processes initiated by AppleScript, focusing on specific command patterns and rapid sequence execution, indicating potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and process.entity_id involved in the suspicious activity.
+- Examine the process arguments for osascript to determine the exact AppleScript command executed, focusing on the presence of the "-e" flag which indicates script execution.
+- Investigate the parent process of the shell (sh, bash, zsh) to understand the context in which the shell command was executed, using process.parent.entity_id for correlation.
+- Analyze the shell command arguments, particularly looking for potentially malicious patterns such as "*curl*", "*pbcopy*", "*http*", or "*chmod*", which may indicate data exfiltration or system modification attempts.
+- Check the sequence and timing of the processes to assess if the execution pattern aligns with typical user behavior or if it suggests automated or rapid execution indicative of a script.
+- Correlate the findings with any other security alerts or logs from the same host to identify if this activity is part of a broader attack or isolated incident.
+- If necessary, escalate the investigation by capturing additional forensic data from the affected host, such as network traffic or file system changes, to further understand the impact and scope of the activity.
+
+### False positive analysis
+
+- Routine administrative scripts may trigger the rule if they use AppleScript or JXA to automate tasks involving shell commands. To manage this, identify and whitelist these scripts by their specific command patterns or execution context.
+- Software updates or legitimate application installations might execute shell commands through AppleScript, appearing suspicious. Monitor and document these activities, and create exceptions for known update processes.
+- Development tools and environments that rely on scripting for building or testing applications can generate false positives. Exclude these processes by verifying their source and ensuring they align with expected development activities.
+- User-initiated automation tasks, such as custom scripts for personal productivity, may be flagged. Educate users on safe scripting practices and establish a process for reviewing and approving such scripts to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious shell processes identified by the detection rule, specifically those initiated by `osascript` executing shell commands.
+- Conduct a thorough review of the affected system's logs and process history to identify any additional unauthorized activities or persistence mechanisms.
+- Remove any unauthorized scripts or files that were executed or created as part of the malicious activity.
+- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for similar patterns of behavior, focusing on the use of `osascript` and shell command execution, to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
index c6fe7a360a3..f64f88d5407 100644
--- a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
+++ b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -124,6 +124,41 @@ process where event.action == "exec" and host.os.type == "macos" and
         "/usr/sbin/networksetup"
       )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious macOS MS Office Child Process
+
+Microsoft Office applications on macOS can be exploited by adversaries to execute malicious child processes, often through malicious macros or document exploits. These child processes may include scripting languages or utilities that can be leveraged for unauthorized actions. The detection rule identifies such suspicious activity by monitoring for unexpected child processes spawned by Office apps, while filtering out known benign behaviors and false positives, thus helping to pinpoint potential threats.
+
+### Possible investigation steps
+
+- Review the parent process name and executable path to confirm if the Office application is legitimate and expected on the host.
+- Examine the child process name and command line arguments to identify any potentially malicious or unexpected behavior, such as the use of scripting languages or network utilities like curl or nscurl.
+- Check the process arguments for any indicators of compromise or suspicious patterns that are not filtered out by the rule, such as unexpected network connections or file modifications.
+- Investigate the effective parent executable path to ensure it is not associated with known benign applications or services that are excluded by the rule.
+- Correlate the alert with any recent phishing attempts or suspicious email activity that might have led to the execution of malicious macros or document exploits.
+- Analyze the host's recent activity and system logs to identify any other anomalies or related alerts that could provide additional context or evidence of compromise.
+
+### False positive analysis
+
+- Product version discovery commands can trigger false positives. Exclude processes with arguments like "ProductVersion" and "ProductBuildVersion" to reduce noise.
+- Office error reporting may cause alerts. Exclude paths related to Microsoft Error Reporting to prevent unnecessary alerts.
+- Network setup and management tools such as "/usr/sbin/networksetup" can be benign. Exclude these executables if they are part of regular system operations.
+- Third-party applications like ToDesk and JumpCloud Agent might be flagged. Exclude their executables if they are verified as safe and part of normal operations.
+- Zotero integration can cause false positives with shell processes. Exclude specific command lines involving "$CFFIXED_USER_HOME/.zoteroIntegrationPipe" to avoid these alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS device from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious child processes identified by the alert, such as those involving scripting languages or utilities like curl, bash, or osascript.
+- Conduct a thorough review of the parent Microsoft Office application and associated documents to identify and remove any malicious macros or document exploits.
+- Restore the affected system from a known good backup if malicious activity has compromised system integrity or data.
+- Update all Microsoft Office applications to the latest version to patch any known vulnerabilities that could be exploited by similar threats.
+- Implement application whitelisting to restrict the execution of unauthorized scripts and utilities, reducing the risk of exploitation through Office applications.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
index 9013d41a7ab..fb586259560 100644
--- a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
+++ b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,40 @@ query = '''
 event.category:process and host.os.type:macos and event.type:start and
  process.args:("-action" and ("-kerberoast" or askhash or asktgs or asktgt or s4u or ("-ticket" and ptt) or (dump and (tickets or keytab))))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Kerberos Attack via Bifrost
+
+Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. Adversaries exploit tools like Bifrost on macOS to extract Kerberos tickets or perform unauthorized authentications, such as pass-the-ticket attacks. The detection rule identifies suspicious process activities linked to Bifrost's known attack methods, focusing on specific command-line arguments indicative of credential access and lateral movement attempts.
+
+### Possible investigation steps
+
+- Review the process start event details to identify the specific command-line arguments used, focusing on those that match the suspicious patterns such as "-action", "-kerberoast", "askhash", "asktgs", "asktgt", "s4u", "-ticket ptt", or "dump tickets/keytab".
+- Correlate the process execution with user activity logs to determine if the process was initiated by a legitimate user or an unauthorized account.
+- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
+- Investigate the source and destination of any network connections made by the process to identify potential lateral movement or data exfiltration.
+- Analyze historical data for similar process executions or patterns to assess if this is an isolated incident or part of a broader attack campaign.
+- Review endpoint security logs for any additional indicators of compromise or related suspicious activities around the time of the alert.
+
+### False positive analysis
+
+- Legitimate administrative tasks on macOS systems may trigger the rule if they involve Kerberos ticket management. To handle this, identify and document routine administrative processes that use similar command-line arguments and create exceptions for these specific activities.
+- Security tools or scripts designed for Kerberos ticket management or testing may mimic Bifrost's behavior. Review and whitelist these tools if they are part of authorized security assessments or IT operations.
+- Automated system processes that interact with Kerberos for legitimate authentication purposes might be flagged. Monitor these processes and exclude them from the rule if they are verified as non-threatening and essential for system operations.
+- Developers or IT personnel testing Kerberos configurations in a controlled environment could inadvertently trigger the rule. Ensure that such environments are well-documented and excluded from monitoring to prevent false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving Bifrost command-line arguments.
+- Conduct a thorough review of Kerberos ticket logs and authentication attempts to identify any unauthorized access or anomalies.
+- Revoke and reissue Kerberos tickets for affected users and services to ensure no compromised tickets are in use.
+- Update and patch the macOS system and any related software to mitigate vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for Kerberos-related activities, focusing on unusual patterns or command-line arguments similar to those used by Bifrost.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_mounting_smb_share.toml b/rules/macos/lateral_movement_mounting_smb_share.toml
index 567c47b2457..f2f6e0a55dc 100644
--- a/rules/macos/lateral_movement_mounting_smb_share.toml
+++ b/rules/macos/lateral_movement_mounting_smb_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,40 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
   ) and
   not process.parent.executable : "/Applications/Google Drive.app/Contents/MacOS/Google Drive"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Mount SMB Share via Command Line
+
+SMB (Server Message Block) is a protocol used for network file sharing, allowing applications to read and write to files and request services from server programs in a computer network. Adversaries exploit SMB to move laterally within a network by accessing shared resources using valid credentials. The detection rule identifies suspicious command-line activities on macOS, such as using built-in commands to mount SMB shares, which may indicate unauthorized access attempts. It filters out benign processes, like those from Google Drive, to reduce false positives, focusing on potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of commands like "mount_smbfs", "open", "mount", or "osascript" with arguments indicating an attempt to mount an SMB share.
+- Check the user account associated with the process to determine if it is a valid and authorized user for accessing SMB shares.
+- Investigate the source and destination IP addresses involved in the SMB connection attempt to identify if they are known and trusted within the network.
+- Examine the parent process of the suspicious activity to understand the context and origin of the command execution, ensuring it is not a benign process like Google Drive.
+- Look for any other related alerts or logs that might indicate lateral movement or unauthorized access attempts within the network.
+- Assess the risk and impact of the activity by correlating it with other security events or incidents involving the same user or system.
+
+### False positive analysis
+
+- Google Drive operations can trigger this rule due to its use of SMB for file synchronization. To manage this, exclude processes originating from the Google Drive application by using the provided exception for its executable path.
+- Legitimate user activities involving manual mounting of SMB shares for accessing network resources may be flagged. To handle this, identify and whitelist specific user accounts or devices that regularly perform these actions as part of their normal workflow.
+- Automated backup solutions that utilize SMB for network storage access might be detected. Review and exclude these processes by identifying their specific command-line patterns or parent processes.
+- Development or testing environments where SMB shares are frequently mounted for application testing can cause alerts. Implement exceptions for these environments by specifying known IP addresses or hostnames associated with the test servers.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further lateral movement by the adversary.
+- Verify the credentials used in the SMB mount attempt to determine if they have been compromised. Reset passwords and revoke access if necessary.
+- Conduct a thorough review of recent login activities and access logs on the affected system and any connected SMB shares to identify unauthorized access or data exfiltration.
+- Remove any unauthorized SMB mounts and ensure that no persistent connections remain active.
+- Update and patch the macOS system and any related software to mitigate known vulnerabilities that could be exploited for lateral movement.
+- Enhance monitoring and logging on the network to detect future unauthorized SMB mount attempts, focusing on the specific command-line patterns identified in the alert.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network infrastructure."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
index c312d9699ad..d9dbf21089b 100644
--- a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
+++ b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,39 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.args:("-setremotelogin" and on) and
  not process.parent.executable : /usr/local/jamf/bin/jamf
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Remote SSH Login Enabled via systemsetup Command
+
+The `systemsetup` command in macOS is a utility that allows administrators to configure system settings, including enabling remote SSH login, which facilitates remote management and access. Adversaries may exploit this to gain unauthorized access and move laterally within a network. The detection rule identifies suspicious use of `systemsetup` to enable SSH, excluding legitimate administrative tools, by monitoring process execution patterns and arguments.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the systemsetup command with the arguments "-setremotelogin" and "on" to ensure the alert is not a false positive.
+- Check the parent process of the systemsetup command to identify if it was executed by a known administrative tool or script, excluding /usr/local/jamf/bin/jamf as per the rule.
+- Investigate the user account associated with the process execution to determine if it is a legitimate administrator or a potentially compromised account.
+- Examine recent login events and SSH access logs on the host to identify any unauthorized access attempts or successful logins following the enabling of remote SSH login.
+- Correlate this event with other security alerts or logs from the same host or network segment to identify potential lateral movement or further malicious activity.
+
+### False positive analysis
+
+- Legitimate administrative tools like Jamf may trigger this rule when enabling SSH for authorized management purposes. To handle this, ensure that the process parent executable path for Jamf is correctly excluded in the detection rule.
+- Automated scripts used for system configuration and maintenance might enable SSH as part of their routine operations. Review these scripts and, if verified as safe, add their parent process paths to the exclusion list.
+- IT support activities that require temporary SSH access for troubleshooting can also cause false positives. Document these activities and consider scheduling them during known maintenance windows to reduce alerts.
+- Security software or management tools that periodically check or modify system settings could inadvertently trigger this rule. Identify these tools and exclude their specific process paths if they are confirmed to be non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious or unauthorized SSH sessions that are currently active on the affected system.
+- Review and revoke any unauthorized SSH keys or credentials that may have been added to the system.
+- Conduct a thorough examination of the system logs to identify any additional unauthorized activities or changes made by the adversary.
+- Restore the system to a known good state from a backup taken before the unauthorized SSH access was enabled, if possible.
+- Implement network segmentation to limit SSH access to only trusted administrative systems and users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/lateral_movement_vpn_connection_attempt.toml b/rules/macos/lateral_movement_vpn_connection_attempt.toml
index 6388074a40d..70d1cff6132 100644
--- a/rules/macos/lateral_movement_vpn_connection_attempt.toml
+++ b/rules/macos/lateral_movement_vpn_connection_attempt.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,40 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
     (process.name : "osascript" and process.command_line : "osascript*set VPN to service*")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Virtual Private Network Connection Attempt
+
+Virtual Private Networks (VPNs) are used to securely connect to remote networks, encrypting data and masking IP addresses. Adversaries may exploit VPNs to move laterally within a network, gaining unauthorized access to systems. The detection rule identifies suspicious VPN connection attempts on macOS by monitoring specific command executions, helping to flag potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the legitimacy of the VPN connection attempt by examining the process name and arguments, such as "networksetup" with "-connectpppoeservice", "scutil" with "--nc start", or "osascript" with "osascript*set VPN to service*".
+- Check the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Investigate the source IP address and destination network to assess if the connection is to a known and trusted network or if it is unusual for the environment.
+- Analyze historical data for similar VPN connection attempts from the same user or device to identify patterns or repeated unauthorized access attempts.
+- Correlate the VPN connection attempt with other security events or alerts to identify potential lateral movement or further malicious activity within the network.
+
+### False positive analysis
+
+- Legitimate VPN usage by IT staff or network administrators may trigger the rule. To manage this, create exceptions for known user accounts or specific times when VPN maintenance is scheduled.
+- Automated scripts or applications that use macOS built-in commands for VPN connections can cause false positives. Identify these scripts and whitelist their process names or command lines.
+- Frequent VPN connections from trusted devices or IP addresses might be flagged. Exclude these devices or IPs from the rule to reduce noise.
+- Users who frequently travel and connect to corporate networks via VPN may trigger alerts. Consider excluding these users or implementing a separate monitoring strategy for their activities.
+- Regularly review and update the exclusion list to ensure it reflects current network policies and user behaviors, minimizing unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS device from the network to prevent further lateral movement by the adversary.
+- Terminate any suspicious VPN connections identified by the detection rule to cut off unauthorized access.
+- Conduct a thorough review of the affected system's VPN configuration and logs to identify any unauthorized changes or connections.
+- Reset credentials and update authentication methods for VPN access to ensure that compromised credentials are not reused.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if other systems have been affected.
+- Implement additional monitoring on the network for unusual VPN connection attempts or related suspicious activities to enhance detection capabilities.
+- Review and update VPN access policies to ensure they align with current security best practices and limit access to only necessary users and systems."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_account_creation_hide_at_logon.toml b/rules/macos/persistence_account_creation_hide_at_logon.toml
index 88551bdc5f7..02aa30b4b6e 100644
--- a/rules/macos/persistence_account_creation_hide_at_logon.toml
+++ b/rules/macos/persistence_account_creation_hide_at_logon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,40 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:dscl and process.args:(IsHidden and create and (true or 1 or yes))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Hidden Local User Account Creation
+
+In macOS environments, the `dscl` command-line utility manages directory services, including user accounts. Adversaries may exploit this to create hidden local accounts, evading detection while maintaining persistence. The detection rule monitors for `dscl` processes attempting to set accounts as hidden, flagging suspicious activity indicative of potential misuse.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of the `dscl` command with arguments related to account creation and hiding, specifically checking for `IsHidden`, `create`, and values like `true`, `1`, or `yes`.
+- Identify the user account under which the `dscl` command was executed to determine if it was initiated by an authorized user or a potential adversary.
+- Check the system logs for any additional suspicious activity around the time the `dscl` command was executed, such as other unauthorized account modifications or unusual login attempts.
+- Investigate the newly created account details, if available, to assess its purpose and legitimacy, including checking for any associated files or processes that might indicate malicious intent.
+- Correlate the event with other security alerts or anomalies on the host to determine if this activity is part of a broader attack pattern or isolated incident.
+
+### False positive analysis
+
+- System administrators may use the dscl command to create hidden accounts for legitimate purposes such as maintenance or automated tasks. To manage this, create exceptions for known administrator accounts or scripts that regularly perform these actions.
+- Some third-party applications or management tools might use hidden accounts for functionality or security purposes. Identify these applications and whitelist their processes to prevent unnecessary alerts.
+- During system setup or configuration, hidden accounts might be created as part of the initial setup process. Exclude these initial setup activities by correlating them with known installation or configuration events.
+- Regular audits of user accounts and their creation processes can help distinguish between legitimate and suspicious account creation activities, allowing for more informed exception handling.
+- If a specific user or group frequently triggers this rule due to their role, consider creating a role-based exception to reduce noise while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Use administrative privileges to review and remove any unauthorized hidden user accounts created using the `dscl` command. Ensure that legitimate accounts are not affected.
+- Change passwords for all local accounts on the affected system to prevent unauthorized access using potentially compromised credentials.
+- Conduct a thorough review of system logs and security alerts to identify any additional suspicious activities or indicators of compromise related to the hidden account creation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced monitoring for `dscl` command usage across all macOS systems in the environment to detect and respond to similar threats promptly.
+- Update and reinforce endpoint security measures, such as ensuring all systems have the latest security patches and antivirus definitions, to prevent exploitation of known vulnerabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_change_launch_agents_file.toml b/rules/macos/persistence_creation_change_launch_agents_file.toml
index 043c9618c04..04cf4141e09 100644
--- a/rules/macos/persistence_creation_change_launch_agents_file.toml
+++ b/rules/macos/persistence_creation_change_launch_agents_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,40 @@ sequence by host.id with maxspan=1m
  ]
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Launch Agent Creation or Modification and Immediate Loading
+
+Launch Agents in macOS are used to execute scripts or applications automatically at user login, providing a mechanism for persistence. Adversaries exploit this by creating or modifying Launch Agents to execute malicious payloads. The detection rule identifies such activities by monitoring file changes in Launch Agent directories and subsequent immediate loading via `launchctl`, indicating potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the file path where the modification or creation of the Launch Agent occurred to determine if it is in a system directory (e.g., /System/Library/LaunchAgents/) or a user directory (e.g., /Users/*/Library/LaunchAgents/). This can help assess the potential impact and scope of the change.
+- Examine the contents of the newly created or modified plist file to identify the script or application it is configured to execute. Look for any suspicious or unexpected entries that could indicate malicious activity.
+- Check the timestamp of the file modification event to correlate it with any known user activities or other system events that might explain the change.
+- Investigate the process execution details of the launchctl command, including the user account under which it was executed and any associated parent processes, to determine if it aligns with legitimate administrative actions or if it appears suspicious.
+- Search for any additional related alerts or logs around the same timeframe that might indicate further malicious behavior or corroborate the persistence attempt, such as other process executions or network connections initiated by the suspicious process.
+
+### False positive analysis
+
+- System or application updates may create or modify Launch Agents as part of their installation or update process. Users can create exceptions for known and trusted applications by whitelisting their specific file paths or process names.
+- User-installed applications that require background processes might use Launch Agents for legitimate purposes. Identify these applications and exclude their associated Launch Agent paths from monitoring.
+- Administrative scripts or tools used by IT departments for system management might trigger this rule. Coordinate with IT to document these scripts and exclude their activities from detection.
+- Development tools or environments that automatically configure Launch Agents for testing purposes can cause false positives. Developers should be aware of these activities and can exclude their specific development directories.
+- Backup or synchronization software that uses Launch Agents to schedule tasks may be flagged. Verify these applications and exclude their Launch Agent paths if they are deemed safe.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes associated with the unauthorized Launch Agent using Activity Monitor or the `kill` command in Terminal.
+- Remove the malicious Launch Agent plist file from the affected directories: `/System/Library/LaunchAgents/`, `/Library/LaunchAgents/`, or `/Users/*/Library/LaunchAgents/`.
+- Review and restore any system or application settings that may have been altered by the malicious Launch Agent.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
+- Monitor the system for any signs of re-infection or further unauthorized changes to Launch Agents, ensuring that logging and alerting are configured to detect similar activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_hidden_login_item_osascript.toml b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
index 1b48ca3d708..a7b73e789bc 100644
--- a/rules/macos/persistence_creation_hidden_login_item_osascript.toml
+++ b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,40 @@ query = '''
 process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : "osascript" and
  process.command_line : "osascript*login item*hidden:true*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation of Hidden Login Item via Apple Script
+
+AppleScript is a scripting language for automating tasks on macOS, including managing login items. Adversaries exploit this by creating hidden login items to maintain persistence without detection. The detection rule identifies suspicious use of `osascript` to create such items, focusing on command patterns that specify hidden attributes, thus flagging potential stealthy persistence attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of 'osascript' in the command line, specifically looking for patterns like "login item" and "hidden:true" to verify the alert's accuracy.
+- Investigate the parent process of the 'osascript' execution to determine if it was initiated by a legitimate application or a potentially malicious source.
+- Check the user account associated with the process to assess whether the activity aligns with typical user behavior or if it suggests unauthorized access.
+- Examine recent login items and system logs to identify any new or unusual entries that could indicate persistence mechanisms being established.
+- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns.
+- If possible, retrieve and analyze the AppleScript code executed to understand its purpose and potential impact on the system.
+
+### False positive analysis
+
+- Legitimate applications or scripts that automate login item management may trigger this rule. Review the process command line details to verify if the application is trusted.
+- System administrators or IT management tools might use AppleScript for legitimate configuration tasks. Confirm if the activity aligns with scheduled maintenance or deployment activities.
+- Users with advanced scripting knowledge might create custom scripts for personal use. Check if the script is part of a known user workflow and consider excluding it if verified as non-threatening.
+- Frequent triggers from the same source could indicate a benign automation process. Implement exceptions for specific scripts or processes after thorough validation to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration.
+- Terminate the suspicious osascript process identified in the alert to halt any ongoing malicious activity.
+- Remove the hidden login item created by the osascript to eliminate the persistence mechanism. This can be done by accessing the user's login items and deleting any unauthorized entries.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
+- Review system logs and the user's recent activity to identify any other signs of compromise or related suspicious behavior.
+- 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 enhanced monitoring for osascript usage and login item modifications across the network to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
index 0c3009d0cc4..d85e84512f1 100644
--- a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
+++ b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ sequence by host.id with maxspan=1m
  [file where host.os.type == "macos" and event.type != "deletion" and file.path : ("/System/Library/LaunchDaemons/*", "/Library/LaunchDaemons/*")]
  [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 LaunchDaemon Creation or Modification and Immediate Loading
+
+LaunchDaemons in macOS are system-level services that start at boot and run in the background, often used for legitimate system tasks. However, adversaries can exploit this by creating or modifying LaunchDaemons to ensure persistent execution of malicious payloads. The detection rule identifies such activities by monitoring for new or altered LaunchDaemon files followed by their immediate loading using `launchctl`, indicating potential misuse for persistence.
+
+### Possible investigation steps
+
+- Review the file path of the newly created or modified LaunchDaemon to determine if it is located in a legitimate system directory such as /System/Library/LaunchDaemons/ or /Library/LaunchDaemons/.
+- Examine the contents of the LaunchDaemon file to identify any suspicious or unexpected configurations or scripts that may indicate malicious intent.
+- Investigate the process execution details of the launchctl command, including the user account that initiated it, to assess whether it aligns with expected administrative activities.
+- Check the timestamp of the LaunchDaemon file creation or modification against known system updates or legitimate software installations to rule out false positives.
+- Correlate the event with other security alerts or logs from the same host to identify any additional indicators of compromise or related malicious activities.
+- Consult threat intelligence sources to determine if the identified LaunchDaemon or associated scripts are known to be used by specific threat actors or malware campaigns.
+
+### False positive analysis
+
+- System updates or software installations may create or modify LaunchDaemons as part of legitimate processes. Users can monitor the timing of these activities and correlate them with known update schedules to identify benign occurrences.
+- Some third-party applications may use LaunchDaemons for legitimate background tasks. Users should maintain a list of trusted applications and their associated LaunchDaemons to quickly identify and exclude these from alerts.
+- Administrative scripts or IT management tools might use launchctl to load LaunchDaemons for system management purposes. Users can create exceptions for known management tools by specifying their process names or paths in the monitoring system.
+- Regular system maintenance tasks might involve the creation or modification of LaunchDaemons. Users should document routine maintenance activities and adjust monitoring rules to exclude these known tasks.
+- Users can implement a baseline of normal LaunchDaemon activity on their systems to distinguish between expected and unexpected changes, allowing for more accurate identification of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS host from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with the newly created or modified LaunchDaemon using the `launchctl` command to unload the daemon.
+- Review and remove any unauthorized or suspicious LaunchDaemon files from the directories `/System/Library/LaunchDaemons/` and `/Library/LaunchDaemons/`.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads.
+- Restore any altered system files or configurations from a known good backup to ensure system integrity.
+- 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 enhanced monitoring and logging for LaunchDaemon activities and `launchctl` usage to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
index 86b2ab22a1b..077c52f5f3b 100644
--- a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
+++ b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,40 @@ event.category:file and host.os.type:macos and not event.type:deletion and
   not (/Library/Security/SecurityAgentPlugins/KandjiPassport.bundle/* or /Library/Security/SecurityAgentPlugins/TeamViewerAuthPlugin.bundle/*)) and
   not (process.name:shove and process.code_signature.trusted:true)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Authorization Plugin Modification
+
+Authorization plugins in macOS extend authentication capabilities, enabling features like third-party multi-factor authentication. Adversaries may exploit these plugins to maintain persistence or capture credentials by modifying or adding unauthorized plugins. The detection rule identifies suspicious modifications by monitoring changes in specific plugin directories, excluding known legitimate plugins and trusted processes, thus highlighting potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the file path of the modified plugin to determine if it is located in the /Library/Security/SecurityAgentPlugins/ directory and verify if it is not among the known legitimate plugins like KandjiPassport.bundle or TeamViewerAuthPlugin.bundle.
+- Examine the process name associated with the modification event to ensure it is not 'shove' with a trusted code signature, as these are excluded from the detection rule.
+- Investigate the history of the modified plugin file to identify when it was created or last modified and by which user or process, to assess if the change aligns with expected administrative activities.
+- Check for any recent user logon events that might correlate with the timing of the plugin modification to identify potential unauthorized access attempts.
+- Analyze any associated network activity or connections from the host around the time of the modification to detect possible data exfiltration or communication with external command and control servers.
+- Review system logs for any other suspicious activities or anomalies that occurred around the same time as the plugin modification to gather additional context on the potential threat.
+
+### False positive analysis
+
+- Known legitimate plugins such as KandjiPassport.bundle and TeamViewerAuthPlugin.bundle may trigger alerts if they are updated or modified. Users can handle these by ensuring these plugins are included in the exclusion list within the detection rule.
+- Trusted processes like those signed by a verified code signature, such as the process named 'shove', might be flagged if they interact with the plugin directories. Users should verify the code signature and add these processes to the trusted list to prevent false positives.
+- System updates or legitimate software installations may cause temporary changes in the plugin directories. Users should monitor for these events and temporarily adjust the detection rule to exclude these known activities during the update period.
+- Custom or in-house developed plugins that are not widely recognized may be flagged. Users should ensure these plugins are properly documented and added to the exclusion list if they are verified as safe and necessary for business operations.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further unauthorized access.
+- Review and terminate any suspicious processes associated with unauthorized plugins, especially those not signed by a trusted code signature.
+- Remove any unauthorized or suspicious plugins from the /Library/Security/SecurityAgentPlugins/ directory to eliminate persistence mechanisms.
+- Conduct a thorough credential audit for any accounts that may have been compromised, and enforce a password reset for affected users.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar endpoints to detect any further unauthorized plugin modifications.
+- Review and update security policies to ensure only authorized personnel can modify or add authorization plugins, and consider implementing stricter access controls."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_crontab_creation.toml b/rules/macos/persistence_crontab_creation.toml
index b8396765b58..25ef125f347 100644
--- a/rules/macos/persistence_crontab_creation.toml
+++ b/rules/macos/persistence_crontab_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,40 @@ query = '''
 file where host.os.type == "macos" and event.type != "deletion" and process.name != null and
   file.path : "/private/var/at/tabs/*" and not process.executable == "/usr/bin/crontab"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious CronTab Creation or Modification
+
+Cron is a time-based job scheduler in Unix-like operating systems, including macOS, used to automate repetitive tasks. Adversaries may exploit cron to maintain persistence by scheduling malicious scripts or commands. The detection rule identifies unusual crontab modifications by non-standard processes, flagging potential misuse by threat actors seeking to establish persistence.
+
+### Possible investigation steps
+
+- Review the process name and executable path that triggered the alert to determine if it is a known legitimate application or a potentially malicious one.
+- Examine the file path "/private/var/at/tabs/*" to identify any recent changes or additions to crontab entries that could indicate unauthorized scheduling of tasks.
+- Investigate the user account associated with the process to determine if it has a history of legitimate crontab modifications or if it might be compromised.
+- Check for any related alerts or logs around the same timeframe that might indicate additional suspicious activity or corroborate the use of cron for persistence.
+- Analyze the command or script scheduled in the crontab entry to assess its purpose and potential impact on the system, looking for signs of malicious intent.
+
+### False positive analysis
+
+- System maintenance scripts or legitimate administrative tools may modify crontabs using non-standard processes. Review the process name and executable path to determine if the activity is part of routine maintenance.
+- Development or testing environments might use scripts or automation tools that modify crontabs for legitimate purposes. Identify and document these processes to create exceptions in the detection rule.
+- Some third-party applications may use cron jobs for updates or scheduled tasks. Verify the legitimacy of these applications and consider excluding their processes if they are known and trusted.
+- User-initiated scripts that automate personal tasks could trigger this rule. Educate users on the implications of using cron for personal automation and establish a process for approving such scripts.
+- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempt from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious tasks.
+- Terminate any suspicious processes identified as modifying the crontab, especially those not typically associated with crontab modifications, such as python or osascript.
+- Review and remove any unauthorized or suspicious entries in the crontab file located at /private/var/at/tabs/* to eliminate persistence mechanisms established by the threat actor.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or malicious scripts.
+- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches and updates are applied.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for crontab modifications and related processes to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
index 66941650995..aea47236444 100644
--- a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
+++ b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,41 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:.* and process.parent.executable:/sbin/launchd
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Hidden Child Process of Launchd
+
+Launchd is a key macOS system process responsible for managing system and user services. Adversaries may exploit it by creating hidden child processes to maintain persistence or evade defenses. The detection rule identifies unusual child processes of launchd, focusing on hidden files, which are often indicative of malicious activity. By monitoring process initiation events, it helps uncover potential threats linked to persistence and defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to identify the hidden child process, focusing on the process.name field to determine if it matches known malicious patterns or unusual names.
+- Examine the process.parent.executable field to confirm that the parent process is indeed /sbin/launchd, ensuring the alert is not a false positive.
+- Investigate the file path and attributes of the hidden file associated with the child process to determine its origin and legitimacy.
+- Check the user account associated with the process initiation event to assess if it aligns with expected user behavior or if it indicates potential compromise.
+- Correlate the event with other recent process initiation events on the same host to identify any patterns or additional suspicious activities.
+- Review system logs and other security alerts for the host to gather more context on the potential threat and assess the scope of the activity.
+
+### False positive analysis
+
+- System updates or legitimate software installations may trigger hidden child processes of launchd. Users can create exceptions for known update processes or trusted software installations to prevent unnecessary alerts.
+- Some legitimate applications may use hidden files for configuration or temporary data storage, which could be misidentified as suspicious. Users should identify these applications and whitelist their processes to reduce false positives.
+- Development tools or scripts that run as background processes might appear as hidden child processes. Developers can exclude these tools by specifying their process names or paths in the detection rule exceptions.
+- Automated backup or synchronization services might create hidden files as part of their normal operation. Users should verify these services and add them to an exclusion list if they are deemed safe.
+- Custom scripts or automation tasks scheduled to run at login could be flagged. Users should review these scripts and, if legitimate, configure the rule to ignore these specific processes.
+
+### Response and remediation
+
+- Isolate the affected macOS system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate the suspicious hidden child process of launchd to stop any ongoing malicious activity.
+- Conduct a thorough review of all launch agents, daemons, and logon items on the affected system to identify and remove any unauthorized or malicious entries.
+- Restore the system from a known good backup if available, ensuring that the backup predates the initial compromise.
+- Update the macOS system and all installed applications to the latest versions to patch any vulnerabilities that may have been exploited.
+- Monitor the system for any signs of re-infection or further suspicious activity, focusing on process initiation events and hidden files.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_directory_services_plugins_modification.toml b/rules/macos/persistence_directory_services_plugins_modification.toml
index 6212dfc742d..1fc57c0777b 100644
--- a/rules/macos/persistence_directory_services_plugins_modification.toml
+++ b/rules/macos/persistence_directory_services_plugins_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,40 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:deletion and
   file.path:/Library/DirectoryServices/PlugIns/*.dsplug
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via DirectoryService Plugin Modification
+
+DirectoryService PlugIns on macOS are integral for managing directory-based services, automatically executing on system boot. Adversaries exploit this by modifying or creating malicious plugins to ensure persistent access. The detection rule identifies suspicious activity by monitoring non-deletion events involving dsplug files in the PlugIns directory, flagging potential unauthorized modifications indicative of persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path matches /Library/DirectoryServices/PlugIns/*.dsplug, indicating a potential unauthorized modification or creation of a DirectoryService plugin.
+- Check the file creation or modification timestamp to determine when the suspicious activity occurred and correlate it with other system events or user activities around that time.
+- Investigate the file's origin by examining the file's metadata, such as the creator or modifying user, and cross-reference with known user accounts and their typical behavior.
+- Analyze the contents of the modified or newly created dsplug file to identify any malicious code or unusual configurations that could indicate adversarial activity.
+- Review system logs and other security alerts around the time of the event to identify any related suspicious activities or patterns that could suggest a broader compromise.
+- Assess the risk and impact of the modification by determining if the plugin is actively being used for persistence or if it has been executed by the DirectoryService daemon.
+
+### False positive analysis
+
+- Routine system updates or legitimate software installations may modify dsplug files, triggering alerts. Users can create exceptions for known update processes or trusted software installations to reduce noise.
+- Administrative tasks performed by IT personnel, such as configuring directory services, might involve legitimate modifications to dsplug files. Implementing a whitelist for actions performed by verified IT accounts can help minimize false positives.
+- Security software or system management tools that interact with directory services might cause benign modifications. Identifying and excluding these tools from monitoring can prevent unnecessary alerts.
+- Automated scripts or maintenance tasks that regularly check or update directory service configurations could be flagged. Documenting and excluding these scripts from detection can help maintain focus on genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Conduct a thorough review of the identified dsplug file(s) in the /Library/DirectoryServices/PlugIns/ directory to confirm unauthorized modifications or creations. Compare against known good configurations or backups.
+- Remove any unauthorized or malicious dsplug files and restore legitimate versions from a trusted backup if available.
+- Restart the DirectoryService daemon to ensure it is running only legitimate plugins. This can be done by executing `sudo launchctl stop com.apple.DirectoryServices` followed by `sudo launchctl start com.apple.DirectoryServices`.
+- Perform a comprehensive scan of the system using updated security tools to identify any additional malicious files or indicators of compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring on the DirectoryServices PlugIns directory to detect future unauthorized changes promptly, ensuring alerts are configured to notify the security team immediately."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_docker_shortcuts_plist_modification.toml b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
index 25ac05e33e9..74d1f6b4e10 100644
--- a/rules/macos/persistence_docker_shortcuts_plist_modification.toml
+++ b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ event.category:file and host.os.type:macos and event.action:modification and
  not process.name:(xpcproxy or cfprefsd or plutil or jamf or PlistBuddy or InstallerRemotePluginService) and
  not process.executable:(/Library/Addigy/download-cache/* or "/Library/Kandji/Kandji Agent.app/Contents/MacOS/kandji-library-manager")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via Docker Shortcut Modification
+
+Docker shortcuts on macOS are managed through dock property lists, which define application launch behaviors. Adversaries may exploit this by altering these lists to redirect shortcuts to malicious applications, thus achieving persistence. The detection rule identifies unauthorized modifications to these property lists, excluding legitimate processes, to flag potential threats. This approach helps in pinpointing suspicious activities that could indicate persistence mechanisms being established by attackers.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and process name involved in the modification of the com.apple.dock.plist file.
+- Examine the process that triggered the alert by checking its parent process, command line arguments, and execution history to determine if it is associated with known malicious activity.
+- Investigate the user account associated with the file modification to determine if there are any signs of compromise or unauthorized access.
+- Check for any recent changes or anomalies in the user's environment, such as new applications installed or unexpected network connections, that could indicate further malicious activity.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+- If possible, restore the original com.apple.dock.plist file from a backup to ensure the system's integrity and prevent the execution of any malicious applications.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify the dock property list. Users can create exceptions for known update processes like software management tools to prevent false alerts.
+- System maintenance tasks performed by macOS utilities might trigger the rule. Exclude processes such as cfprefsd and plutil, which are involved in regular system operations, to reduce noise.
+- Custom scripts or automation tools that modify user preferences could be flagged. Identify and whitelist these scripts if they are part of routine administrative tasks.
+- Security or IT management tools like Jamf or Kandji may interact with dock property lists. Ensure these tools are included in the exclusion list to avoid unnecessary alerts.
+- User-initiated changes to dock settings can also be mistaken for malicious activity. Educate users on the implications of modifying dock settings and monitor for patterns that deviate from normal behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes identified as modifying the dock property list, especially those not matching legitimate process names or executables.
+- Restore the original com.apple.dock.plist file from a known good backup to ensure the dock shortcuts are not redirecting to malicious applications.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious software.
+- Review and audit user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- Implement monitoring for any future unauthorized modifications to dock property lists, ensuring alerts are configured for quick response.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_emond_rules_file_creation.toml b/rules/macos/persistence_emond_rules_file_creation.toml
index e6bbcdc0bd2..b29aef9323c 100644
--- a/rules/macos/persistence_emond_rules_file_creation.toml
+++ b/rules/macos/persistence_emond_rules_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,39 @@ query = '''
 file where host.os.type == "macos" and event.type != "deletion" and
  file.path : ("/private/etc/emond.d/rules/*.plist", "/etc/emon.d/rules/*.plist", "/private/var/db/emondClients/*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Emond Rules Creation or Modification
+
+The Event Monitor Daemon (emond) on macOS is a service that executes commands based on specific system events. Adversaries can exploit this by crafting rules to trigger malicious actions during events like startup or login. The detection rule monitors for new or altered emond rule files, signaling potential unauthorized modifications that could indicate persistence tactics.
+
+### Possible investigation steps
+
+- Review the file path of the modified or newly created emond rule to determine if it matches known legitimate configurations or if it appears suspicious, focusing on paths like "/private/etc/emond.d/rules/*.plist" and "/private/var/db/emondClients/*".
+- Check the timestamp of the file creation or modification to correlate with any known user activity or scheduled tasks that could explain the change.
+- Analyze the contents of the modified or newly created plist file to identify any commands or scripts that are set to execute, looking for signs of malicious intent or unauthorized actions.
+- Investigate the user account associated with the file modification event to determine if the activity aligns with their typical behavior or if it suggests potential compromise.
+- Cross-reference the event with other security alerts or logs from the same timeframe to identify any related suspicious activities or patterns that could indicate a broader attack.
+
+### False positive analysis
+
+- System or application updates may modify emond rule files as part of legitimate maintenance activities. Users can create exceptions for known update processes by identifying the associated process names or hashes and excluding them from alerts.
+- Administrative tasks performed by IT personnel, such as configuring new system policies or settings, might involve legitimate changes to emond rules. To handle these, maintain a list of authorized personnel and their activities, and exclude these from triggering alerts.
+- Security software or management tools that automate system configurations could also modify emond rules. Identify these tools and their expected behaviors, and configure exceptions based on their typical file paths or process identifiers.
+- Scheduled maintenance scripts that interact with emond rules for system health checks or optimizations should be documented. Exclude these scripts by verifying their signatures or paths to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious rules.
+- Review and back up the current emond rule files located in the specified directories to understand the scope of modifications and preserve evidence for further analysis.
+- Remove or revert any unauthorized or suspicious emond rule files to their original state to stop any malicious actions triggered by these rules.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms.
+- Restore the system from a known good backup if the integrity of the system is in question and unauthorized changes cannot be fully reversed.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected by similar unauthorized emond rule modifications.
+- Implement enhanced monitoring and alerting for changes to emond rule files to quickly detect and respond to future unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_emond_rules_process_execution.toml b/rules/macos/persistence_emond_rules_process_execution.toml
index ba4a84be2bd..24576b9df2a 100644
--- a/rules/macos/persistence_emond_rules_process_execution.toml
+++ b/rules/macos/persistence_emond_rules_process_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
    "base64",
    "launchctl")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Emond Child Process
+
+The Event Monitor Daemon (emond) on macOS is a service that executes commands based on system events, like startup or user login. Adversaries exploit emond by crafting rules that trigger malicious scripts or commands during these events, enabling persistence. The detection rule identifies unusual child processes spawned by emond, such as shell scripts or command-line utilities, which are indicative of potential abuse.
+
+### Possible investigation steps
+
+- Review the process details to confirm the parent process is indeed emond and check the specific child process name against the list of suspicious processes such as bash, python, or curl.
+- Investigate the command line arguments used by the suspicious child process to identify any potentially malicious commands or scripts being executed.
+- Check the timing of the event to see if it coincides with known system events like startup or user login, which could indicate an attempt to establish persistence.
+- Examine the user account associated with the process to determine if it is a legitimate user or potentially compromised account.
+- Look for any recent changes to emond rules or configuration files that could have been modified to trigger the suspicious process execution.
+- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- System maintenance scripts may trigger the rule if they use shell scripts or command-line utilities. Review scheduled tasks or maintenance scripts and exclude them if they are verified as non-threatening.
+- Legitimate software installations or updates might spawn processes like bash or curl. Monitor installation logs and exclude these processes if they align with known software updates.
+- User-initiated scripts for automation or customization can cause alerts. Verify the user's intent and exclude these processes if they are part of regular user activity.
+- Administrative tasks performed by IT staff, such as using launchctl for service management, may trigger the rule. Confirm these activities with IT staff and exclude them if they are part of routine administration.
+- Development environments on macOS might use interpreters like Python or Perl. Validate the development activities and exclude these processes if they are consistent with the developer's workflow.
+
+### Response and remediation
+
+- Isolate the affected macOS system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious child processes spawned by emond, such as shell scripts or command-line utilities, to halt ongoing malicious actions.
+- Review and remove any unauthorized or suspicious emond rules that may have been added to execute malicious commands during system events.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Restore any altered or deleted system files from a known good backup to ensure system integrity.
+- 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 enhanced monitoring and logging for emond and related processes to detect similar threats in the future, ensuring alerts are configured for unusual child processes."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_enable_root_account.toml b/rules/macos/persistence_enable_root_account.toml
index 47a4bdcfee6..b5a0359fc54 100644
--- a/rules/macos/persistence_enable_root_account.toml
+++ b/rules/macos/persistence_enable_root_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,39 @@ query = '''
 event.category:process and host.os.type:macos and event.type:(start or process_started) and
  process.name:dsenableroot and not process.args:"-d"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Enable the Root Account
+
+In macOS environments, the root account is typically disabled to enhance security. However, adversaries may attempt to enable it using the `dsenableroot` command to gain persistent, elevated access. The detection rule identifies such attempts by monitoring process events for the execution of `dsenableroot` without the disable flag, indicating potential misuse for persistence.
+
+### Possible investigation steps
+
+- Review the process event logs to confirm the execution of the dsenableroot command without the disable flag, as indicated by the absence of process.args:"-d".
+- Identify the user account associated with the process event to determine if the action was initiated by a legitimate user or a potential adversary.
+- Check for any recent changes in user account permissions or configurations that might indicate unauthorized access or privilege escalation.
+- Investigate any other suspicious activities or process executions around the same time as the dsenableroot command to identify potential lateral movement or further persistence mechanisms.
+- Correlate the event with other security alerts or logs from the same host to assess if this is part of a broader attack campaign.
+
+### False positive analysis
+
+- System administrators may legitimately enable the root account for maintenance or troubleshooting. To handle this, create exceptions for known administrator accounts or specific maintenance windows.
+- Automated scripts or management tools might use the dsenableroot command as part of their operations. Identify these tools and exclude their process signatures from triggering alerts.
+- Educational or testing environments may require enabling the root account for instructional purposes. Implement exclusions for these environments by tagging relevant systems or user accounts.
+- Ensure that any exclusion rules are regularly reviewed and updated to reflect changes in administrative practices or tool usage to maintain security integrity.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent any potential lateral movement by the adversary.
+- Terminate any unauthorized processes associated with the `dsenableroot` command to halt further misuse of elevated privileges.
+- Review system logs and user activity to identify any unauthorized changes or access that occurred after the root account was enabled.
+- Reset the root account password and disable the root account to prevent further unauthorized access.
+- Conduct a thorough scan of the system for any additional signs of compromise or persistence mechanisms that may have been installed.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for any future attempts to enable the root account, ensuring rapid detection and response."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
index 0b84f1c374e..072dad48df0 100644
--- a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
+++ b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ file where host.os.type == "macos" and event.type != "deletion" and
     "/Library/LaunchDaemons/.*.plist"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation of Hidden Launch Agent or Daemon
+
+Launch agents and daemons in macOS are background services that start at login or system boot, respectively, to perform various tasks. Adversaries exploit this by creating hidden agents or daemons to maintain persistence and evade defenses. The detection rule identifies suspicious creation of these services by monitoring specific system paths for new entries, alerting analysts to potential unauthorized persistence mechanisms.
+
+### Possible investigation steps
+
+- Review the file path of the newly created launch agent or daemon to determine if it matches any known legitimate software installations or updates.
+- Check the file creation timestamp to correlate with any recent user activities or system changes that might explain the creation of the file.
+- Investigate the contents of the .plist file to identify the program or script it is set to execute, and assess whether it is a known or potentially malicious application.
+- Examine the user account associated with the file path, especially if it is located in a user's Library directory, to determine if the user has a history of installing unauthorized software.
+- Cross-reference the file path and associated executable with threat intelligence sources to identify any known indicators of compromise or malicious behavior.
+- Look for any other recent file modifications or creations in the same directory that might indicate additional persistence mechanisms or related malicious activity.
+
+### False positive analysis
+
+- System or application updates may create or modify launch agents or daemons as part of legitimate processes. Users can monitor update schedules and correlate alerts with known update activities to verify legitimacy.
+- Some third-party applications install launch agents or daemons to provide background services or updates. Users should maintain an inventory of installed applications and their expected behaviors to identify benign entries.
+- User-created scripts or automation tools might use launch agents or daemons for personal productivity tasks. Users can document and exclude these known scripts from monitoring to reduce noise.
+- Administrative tools or security software might create temporary launch agents or daemons during scans or system maintenance. Users should verify the source and purpose of these entries and consider excluding them if they are part of routine operations.
+- Regularly review and update exclusion lists to ensure they reflect current system configurations and software installations, minimizing the risk of overlooking new threats.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Identify and terminate any suspicious processes associated with the newly created launch agent or daemon using Activity Monitor or command-line tools like `launchctl`.
+- Remove the unauthorized launch agent or daemon by deleting the corresponding `.plist` file from the identified path. Ensure the file is not recreated by monitoring the directory for changes.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred.
+- Restore the system from a known good backup if the integrity of the system is in question and further compromise is suspected.
+- Escalate the incident to the security operations team for a deeper forensic analysis to determine the root cause and scope of the intrusion.
+- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar persistence mechanisms in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
index 9d39f3a9d97..ea48a5b6337 100644
--- a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
+++ b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
                                                  "/Library/Application Support/Checkpoint/Endpoint Security/AMFinderExtensions.app/Contents/MacOS/AMFinderExtensions",
                                                  "/Applications/pCloud Drive.app/Contents/MacOS/pCloud Drive")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Finder Sync Plugin Registered and Enabled
+
+Finder Sync plugins enhance macOS Finder by allowing third-party applications to integrate and modify its interface. While beneficial for legitimate software, adversaries can exploit this feature to maintain persistence by registering malicious plugins. The detection rule identifies suspicious plugin registrations by monitoring the `pluginkit` process, filtering out known safe applications, and flagging unusual activity, thus helping analysts spot potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of the `pluginkit` process with the specific arguments `-e`, `use`, and `-i`, which indicate the registration of a Finder Sync plugin.
+- Cross-reference the plugin identifier found in the process arguments against the list of known safe applications to determine if it is potentially malicious.
+- Investigate the parent process of the `pluginkit` execution to identify any unusual or unauthorized parent processes that might suggest malicious activity.
+- Check the system for any recent installations or updates of applications that might have introduced the suspicious Finder Sync plugin.
+- Analyze the behavior and origin of the executable associated with the suspicious plugin to assess its legitimacy and potential threat level.
+- Review system logs and other security alerts around the time of the plugin registration to identify any correlated suspicious activities or anomalies.
+
+### False positive analysis
+
+- Known safe applications like Google Drive, Boxcryptor, Adobe, Microsoft OneDrive, Insync, and Box are already excluded from triggering false positives. Ensure these applications are up-to-date to maintain their exclusion status.
+- If a legitimate application not listed in the exclusions is causing false positives, consider adding its specific Finder Sync plugin identifier to the exclusion list after verifying its safety.
+- Monitor the parent process paths of legitimate applications. If a trusted application frequently triggers alerts, add its executable path to the exclusion list to prevent unnecessary alerts.
+- Regularly review and update the exclusion list to accommodate new versions or additional legitimate applications that may introduce Finder Sync plugins.
+- Educate users on the importance of installing applications from trusted sources to minimize the risk of false positives and ensure that only legitimate plugins are registered.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the malicious Finder Sync plugin.
+- Terminate the suspicious `pluginkit` process to stop the execution of the rogue Finder Sync plugin and prevent further persistence.
+- Remove the malicious Finder Sync plugin by unregistering it using the `pluginkit` command with appropriate flags to ensure it cannot be re-enabled.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads or artifacts.
+- Review system logs and the Finder Sync plugin registration history to identify any unauthorized changes or additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced monitoring for `pluginkit` activity and similar persistence mechanisms to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_folder_action_scripts_runtime.toml b/rules/macos/persistence_folder_action_scripts_runtime.toml
index 18b114cfaf4..fa26986610a 100644
--- a/rules/macos/persistence_folder_action_scripts_runtime.toml
+++ b/rules/macos/persistence_folder_action_scripts_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ query = '''
 process where host.os.type == "macos" and event.type : "start" and process.name in ("osascript", "python", "tcl", "node", "perl", "ruby", "php", "bash", "csh", "zsh", "sh") and
   process.parent.name == "com.apple.foundation.UserScriptService" and not process.args : ("/Users/*/Library/Application Support/iTerm2/Scripts/AutoLaunch/*.scpt", "/Users/*/Library/Application Scripts/com.microsoft.*/FoxitUtils.applescript")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via Folder Action Script
+
+Folder Action scripts on macOS automate tasks by executing scripts when folder contents change. Adversaries exploit this by attaching malicious scripts to folders, ensuring execution upon folder events, thus achieving persistence. The detection rule identifies suspicious script executions by monitoring specific processes initiated by the UserScriptService, excluding known benign scripts, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of a script by checking the process name and arguments, ensuring it matches the suspicious criteria outlined in the detection rule.
+- Investigate the parent process, com.apple.foundation.UserScriptService, to understand the context of the script execution and identify any unusual behavior or anomalies.
+- Examine the specific folder associated with the Folder Action script to determine if it has been modified recently or contains any unauthorized or unexpected scripts.
+- Check the user account associated with the script execution to verify if the activity aligns with normal user behavior or if it indicates potential compromise.
+- Look for any additional related alerts or logs that might provide further context or evidence of malicious activity, such as other script executions or file modifications around the same time.
+
+### False positive analysis
+
+- Scripts associated with legitimate applications like iTerm2 and Microsoft Office may trigger alerts. These are known benign scripts and can be excluded by adding their paths to the exception list in the detection rule.
+- Custom user scripts that automate routine tasks might be flagged. Users should review these scripts and, if verified as safe, add their specific paths to the exclusion criteria.
+- Development environments that frequently execute scripts for testing purposes can cause false positives. Developers should ensure that these scripts are executed in a controlled environment and consider excluding their paths if they are consistently flagged.
+- System maintenance scripts that are scheduled to run during folder events might be detected. Users should verify these scripts' legitimacy and exclude them if they are part of regular system operations.
+- Backup or synchronization tools that use scripts to manage file changes in folders could be mistakenly identified. Confirm these tools' activities and exclude their script paths if they are part of trusted operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further execution of the malicious script and potential lateral movement.
+- Terminate any suspicious processes identified by the detection rule, particularly those initiated by the UserScriptService that match the query criteria.
+- Remove or disable the malicious Folder Action script from the affected folder to prevent future execution.
+- Conduct a thorough review of the affected system's folder action scripts to identify and remove any additional unauthorized or suspicious scripts.
+- Restore any affected files or system components from a known good backup to ensure system integrity.
+- Monitor the system for any signs of re-infection or further suspicious activity, focusing on processes and scripts similar to those identified in the alert.
+- Escalate the incident to the security team for further investigation and to determine if additional systems are affected, ensuring a comprehensive response to the threat."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_login_logout_hooks_defaults.toml b/rules/macos/persistence_login_logout_hooks_defaults.toml
index b0ef9cdda7d..69654c92891 100644
--- a/rules/macos/persistence_login_logout_hooks_defaults.toml
+++ b/rules/macos/persistence_login_logout_hooks_defaults.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,41 @@ process where host.os.type == "macos" and event.type == "start" and
          "/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh"
        )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via Login or Logout Hook
+
+In macOS environments, login and logout hooks are scripts executed automatically during user login or logout, often used for system management tasks. Adversaries exploit this by inserting malicious scripts to maintain persistence. The detection rule identifies suspicious use of the `defaults` command to set these hooks, excluding known legitimate scripts, thus highlighting potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the "defaults" command with "write" arguments targeting "LoginHook" or "LogoutHook".
+- Check the process execution history for the user account associated with the alert to identify any unusual or unauthorized activity.
+- Investigate the source and content of the script specified in the "defaults" command to determine if it contains malicious or unauthorized code.
+- Cross-reference the script path against known legitimate scripts to ensure it is not mistakenly flagged.
+- Analyze recent system changes or installations that might have introduced the suspicious script or process.
+- Review system logs around the time of the alert for any additional indicators of compromise or related suspicious activity.
+
+### False positive analysis
+
+- Known false positives include legitimate scripts used by system management tools like JAMF, which are often set as login or logout hooks.
+- To handle these, users can create exceptions for known legitimate scripts by adding their paths to the exclusion list in the detection rule.
+- Regularly review and update the exclusion list to ensure it includes all authorized scripts used in your environment.
+- Monitor for any changes in the behavior of these scripts to ensure they remain non-threatening and authorized.
+- Collaborate with IT and security teams to identify any new legitimate scripts that should be excluded from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes associated with the unauthorized login or logout hooks to halt any ongoing malicious activity.
+- Remove the unauthorized login or logout hooks by using the `defaults delete` command to ensure the persistence mechanism is dismantled.
+- Conduct a thorough review of system logs and recent changes to identify any additional unauthorized modifications or indicators of compromise.
+- Restore any affected system files or configurations from a known good backup to ensure system integrity and functionality.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for similar unauthorized use of the `defaults` command to improve detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
index 4023d557e1d..e043648e2e8 100644
--- a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
+++ b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,41 @@ file where host.os.type == "macos" and event.type in ("change", "creation") and
       "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper"
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Sublime Plugin or Application Script Modification
+
+Sublime Text, a popular text editor, supports plugins and scripts written in Python to enhance functionality. Adversaries may exploit this by altering these scripts to execute malicious code whenever the application launches, achieving persistence. The detection rule identifies suspicious modifications or creations of Python files in specific Sublime directories on macOS, excluding legitimate processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the file path and name of the modified or created Python file to determine if it aligns with known Sublime Text plugin directories, specifically checking paths like "/Users/*/Library/Application Support/Sublime Text*/Packages/*.py" and "/Applications/Sublime Text.app/Contents/MacOS/sublime.py".
+- Examine the process that triggered the file change or creation event, ensuring it is not one of the excluded legitimate processes such as those from "/Applications/Sublime Text*.app/Contents/*" or "/usr/local/Cellar/git/*/bin/git".
+- Analyze the contents of the modified or newly created Python file for any suspicious or unauthorized code, focusing on scripts that may execute commands or connect to external networks.
+- Check the modification or creation timestamp of the file to correlate with any known user activity or other security events that occurred around the same time.
+- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if it might indicate compromised credentials.
+- Look for any additional indicators of compromise on the host, such as unusual network connections or other file modifications, to assess the broader impact of the potential threat.
+
+### False positive analysis
+
+- Legitimate Sublime Text updates or installations may trigger the rule by modifying or creating Python files in the specified directories. Users can mitigate this by temporarily disabling the rule during known update periods or by verifying the update source.
+- Development activities involving Sublime Text plugins or scripts can cause false positives. Developers should consider excluding their specific user paths or processes from the rule to prevent unnecessary alerts.
+- Automated backup or synchronization tools that modify Sublime Text configuration files might be flagged. Users can exclude these tools' processes from the rule to avoid false positives.
+- System maintenance or cleanup scripts that interact with Sublime Text directories could trigger alerts. Identifying and excluding these scripts from the rule can help manage false positives.
+- Version control operations, such as those involving git, may modify files in the monitored directories. Users should ensure that legitimate git processes are included in the exclusion list to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity.
+- Terminate any suspicious processes related to Sublime Text that are not part of the legitimate process list provided in the detection rule.
+- Restore the modified or newly created Python files in the specified Sublime directories from a known good backup to ensure no malicious code persists.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malicious payloads.
+- Review system logs and the history of file changes to identify any unauthorized access or modifications, and document findings for further analysis.
+- Escalate the incident to the security operations team for a deeper investigation into potential compromise vectors and to assess the need for broader organizational response.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat, ensuring enhanced logging for the specified directories and processes."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
index fda11158c76..1e8be3c147b 100644
--- a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
+++ b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:"deletion" and
  file.path:(/private/etc/periodic/* or /private/etc/defaults/periodic.conf or /private/etc/periodic.conf)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Persistence via Periodic Tasks
+
+Periodic tasks in macOS are scheduled operations that automate system maintenance and other routine activities. Adversaries may exploit these tasks to execute unauthorized code or maintain persistence by altering task configurations. The detection rule identifies suspicious file activities related to periodic task configurations, excluding deletions, to flag potential misuse. This helps in early detection of persistence mechanisms employed by attackers.
+
+### Possible investigation steps
+
+- Review the file path specified in the alert to determine which configuration file was created or modified. Focus on paths like /private/etc/periodic/*, /private/etc/defaults/periodic.conf, or /private/etc/periodic.conf.
+- Examine the contents of the modified or newly created configuration file to identify any unauthorized or suspicious entries that could indicate malicious activity.
+- Check the timestamp of the file modification or creation to correlate with any known suspicious activities or other alerts in the same timeframe.
+- Investigate the user account and process responsible for the file modification to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Look for any related events in the system logs that might provide additional context or evidence of unauthorized access or persistence attempts.
+- Assess the risk and impact of the changes by determining if the modified periodic task could execute malicious code or provide persistence for an attacker.
+
+### False positive analysis
+
+- Routine system updates or maintenance scripts may trigger alerts when they modify periodic task configurations. Users can create exceptions for known update processes by identifying their specific file paths or process names.
+- Administrative tools or scripts used by IT departments for legitimate system management might alter periodic task settings. To mitigate this, users should whitelist these tools by verifying their source and ensuring they are part of authorized IT operations.
+- Custom user scripts for personal automation tasks could be flagged if they modify periodic task configurations. Users should document and exclude these scripts by adding them to an exception list, ensuring they are reviewed and approved for legitimate use.
+- Security software or monitoring tools that adjust system settings for protection purposes might inadvertently trigger the rule. Users should verify these tools' activities and exclude them if they are confirmed to be part of the security infrastructure.
+
+### Response and remediation
+
+- Isolate the affected macOS system from the network to prevent potential lateral movement or further execution of unauthorized code.
+- Review the identified periodic task configuration files for unauthorized modifications or additions. Restore any altered files to their original state using known good backups.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious code that may have been executed through the periodic tasks.
+- Check for any additional persistence mechanisms that may have been established by the adversary, such as other scheduled tasks or startup items, and remove them.
+- Monitor the system and network for any signs of continued unauthorized activity or attempts to re-establish persistence.
+- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected.
+- Implement enhanced monitoring and alerting for changes to periodic task configurations to quickly detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_suspicious_calendar_modification.toml b/rules/macos/persistence_suspicious_calendar_modification.toml
index d9e648f11f1..a3ae669c25c 100644
--- a/rules/macos/persistence_suspicious_calendar_modification.toml
+++ b/rules/macos/persistence_suspicious_calendar_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,39 @@ event.category:file and host.os.type:macos and event.action:modification and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Calendar File Modification
+
+Calendar files on macOS can be manipulated to trigger events, potentially allowing adversaries to execute malicious programs at set intervals, thus achieving persistence. This detection rule identifies unusual processes modifying calendar files, excluding known legitimate applications. By focusing on unexpected executables altering these files, it helps uncover potential threats exploiting calendar notifications for malicious purposes.
+
+### Possible investigation steps
+
+- Review the process executable path that triggered the alert to determine if it is a known or unknown application, focusing on paths not excluded by the rule.
+- Examine the modification timestamp of the calendar file to correlate with any known user activity or scheduled tasks that might explain the change.
+- Check the user account associated with the file modification to assess if the activity aligns with typical user behavior or if it suggests unauthorized access.
+- Investigate any recent installations or updates of applications on the system that might have introduced new or unexpected executables.
+- Look for additional indicators of compromise on the host, such as unusual network connections or other file modifications, to assess if the calendar file change is part of a broader attack.
+
+### False positive analysis
+
+- Legitimate third-party calendar applications may modify calendar files as part of their normal operation. Users can create exceptions for these known applications by adding their executable paths to the exclusion list.
+- Automated backup or synchronization tools might access and modify calendar files. Identify these tools and exclude their processes to prevent false alerts.
+- User scripts or automation workflows that interact with calendar files for personal productivity purposes can trigger this rule. Review and whitelist these scripts if they are verified as non-malicious.
+- System updates or maintenance tasks occasionally modify calendar files. Monitor the timing of such events and correlate them with known update schedules to differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious programs.
+- Terminate any suspicious processes identified as modifying calendar files that are not part of the known legitimate applications list.
+- Restore the calendar files from a known good backup to ensure no malicious events are scheduled.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software.
+- Review and audit user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- 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 unusual calendar file modifications across the network to enhance detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/persistence_via_atom_init_file_modification.toml b/rules/macos/persistence_via_atom_init_file_modification.toml
index f281678818e..16a3f109e70 100644
--- a/rules/macos/persistence_via_atom_init_file_modification.toml
+++ b/rules/macos/persistence_via_atom_init_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,40 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:"deletion" and
  file.path:/Users/*/.atom/init.coffee and not process.name:(Atom or xpcproxy) and not user.name:root
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Persistence via Atom Init Script Modification
+
+Atom, a popular text editor, allows customization via the `init.coffee` script, which executes JavaScript upon startup. Adversaries exploit this by embedding malicious code, ensuring persistence each time Atom launches. The detection rule identifies suspicious modifications to this script on macOS, excluding benign processes and root user actions, thus highlighting potential unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the file modification details for /Users/*/.atom/init.coffee to identify the exact changes made to the script.
+- Investigate the process that modified the init.coffee file by examining the process name and user associated with the modification, ensuring it is not Atom, xpcproxy, or the root user.
+- Check the user account involved in the modification for any unusual activity or recent changes, such as new software installations or privilege escalations.
+- Analyze the content of the modified init.coffee file for any suspicious or unfamiliar JavaScript code that could indicate malicious intent.
+- Correlate the modification event with other security alerts or logs from the same host to identify any related suspicious activities or patterns.
+- If malicious code is found, isolate the affected system and conduct a deeper forensic analysis to determine the scope and impact of the potential compromise.
+
+### False positive analysis
+
+- Frequent legitimate updates to the init.coffee file by developers or power users can trigger alerts. To manage this, create exceptions for specific user accounts known to regularly modify this file for legitimate purposes.
+- Automated scripts or tools that modify the init.coffee file as part of a legitimate configuration management process may cause false positives. Identify these processes and exclude them from the rule by adding their process names to the exception list.
+- Non-malicious third-party Atom packages that require modifications to the init.coffee file for functionality can be mistaken for threats. Review and whitelist these packages if they are verified as safe and necessary for user workflows.
+- System maintenance or administrative tasks performed by non-root users that involve changes to the init.coffee file might be flagged. Consider adding exceptions for these specific maintenance activities if they are routine and verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code.
+- Review the contents of the `init.coffee` file to identify and document any unauthorized or suspicious code modifications.
+- Remove any malicious code found in the `init.coffee` file and restore it to a known good state, either by reverting to a backup or by manually cleaning the file.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Change the credentials of the user account associated with the modified `init.coffee` file to prevent unauthorized access.
+- 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 monitoring for future unauthorized changes to the `init.coffee` file and similar persistence mechanisms, enhancing detection capabilities to quickly identify and respond to similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
index b47455ab7a1..eb8b45f415a 100644
--- a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
+++ b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
   not process.Ext.effective_parent.executable : ("/Applications/Visual Studio Code.app/Contents/MacOS/Electron",
                                                  "/Applications/OpenVPN Connect/Uninstall OpenVPN Connect.app/Contents/MacOS/uninstaller")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Apple Scripting Execution with Administrator Privileges
+
+AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries may exploit it to execute scripts with elevated privileges, bypassing password prompts, to gain unauthorized access or escalate privileges. The detection rule identifies such misuse by monitoring the execution of AppleScript with admin rights, excluding benign parent processes like Electron, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of 'osascript' with administrator privileges, focusing on the command line arguments to understand the script's intent.
+- Investigate the parent process of 'osascript' to determine if it is a known and trusted application, ensuring it is not 'Electron' or any other excluded parent processes.
+- Check the user account associated with the 'osascript' execution to verify if it is a legitimate account and assess if there are any signs of compromise or unauthorized access.
+- Analyze recent system logs and user activity to identify any unusual behavior or patterns that coincide with the time of the alert.
+- Correlate this event with other security alerts or incidents to determine if it is part of a broader attack or isolated incident.
+
+### False positive analysis
+
+- Known false positives may arise from legitimate applications that use AppleScript with administrator privileges for valid operations, such as software installers or system management tools.
+- Exclude processes with benign parent applications like Electron, as specified in the rule, to reduce false positives from common development environments.
+- Consider adding exceptions for other trusted applications that frequently use AppleScript with elevated privileges, ensuring they are verified and necessary for business operations.
+- Regularly review and update the list of excluded applications to adapt to changes in software usage and maintain effective threat detection.
+- Monitor the frequency and context of alerts to identify patterns that may indicate false positives, adjusting the detection rule as needed to minimize unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious osascript processes running with administrator privileges that were not initiated by known, legitimate applications.
+- Review system logs and process execution history to identify any unauthorized changes or access that occurred during the incident.
+- Revoke any compromised credentials or accounts that may have been used to execute the AppleScript with elevated privileges.
+- Restore the system to a known good state from a backup taken before the unauthorized script execution, if necessary.
+- Implement application whitelisting to prevent unauthorized scripts from executing with elevated privileges in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the need for additional security controls or monitoring enhancements."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
index b05b7f04238..11354d8bf3c 100644
--- a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
+++ b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,41 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
  process.name:"security_authtrampoline" and
  process.parent.name:(osascript or com.apple.automator.runner or sh or bash or dash or zsh or python* or Python or perl* or php* or ruby or pwsh)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution with Explicit Credentials via Scripting
+
+In macOS environments, the `security_authtrampoline` process is used to execute programs with elevated privileges via scripting interpreters. Adversaries may exploit this by using explicit credentials to run unauthorized scripts, gaining root access. The detection rule identifies such activities by monitoring the initiation of `security_authtrampoline` through common scripting languages, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the parent process name matches one of the specified scripting interpreters (e.g., osascript, bash, python) to verify the context of the alert.
+- Examine the command line arguments of the security_authtrampoline process to identify the script or program being executed and assess its legitimacy.
+- Investigate the user account associated with the process to determine if the credentials used are valid and expected for executing such scripts.
+- Check the historical activity of the involved user account and associated processes to identify any patterns of unusual or unauthorized behavior.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
+- Assess the system for any signs of compromise or unauthorized changes, such as unexpected new files, altered configurations, or additional unauthorized processes running.
+
+### False positive analysis
+
+- Legitimate administrative tasks using scripting languages may trigger this rule. Users should review the context of the script execution to determine if it aligns with expected administrative activities.
+- Automated scripts or scheduled tasks that require elevated privileges might be flagged. Consider creating exceptions for known scripts by specifying their hash or path in the monitoring system.
+- Development or testing environments where developers frequently use scripting languages to test applications with elevated privileges can cause false positives. Implement a policy to exclude these environments from the rule or adjust the risk score to reflect the lower threat level.
+- Security tools or software updates that use scripting interpreters to perform legitimate actions with elevated privileges may be mistakenly identified. Verify the source and purpose of such processes and whitelist them if they are deemed safe.
+- User-initiated scripts for personal productivity that require elevated access could be misinterpreted as threats. Educate users on safe scripting practices and establish a process for them to report and document legitimate use cases for exclusion.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
+- Terminate the `security_authtrampoline` process if it is still running to stop any ongoing unauthorized activities.
+- Review and revoke any compromised credentials used in the execution of the unauthorized script to prevent further misuse.
+- Conduct a thorough examination of the system for any additional unauthorized scripts or malware that may have been deployed using the compromised credentials.
+- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected.
+- Implement stricter access controls and monitoring for the use of scripting interpreters and the `security_authtrampoline` process to prevent similar privilege escalation attempts.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
index 2fbd033a24f..21e1494c56e 100644
--- a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
+++ b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
                            /usr/sbin/installer or
                            /usr/bin/csrutil)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Child Process of Adobe Acrobat Reader Update Service
+
+Adobe Acrobat Reader's update service on macOS uses a privileged helper tool to manage updates, running with elevated permissions. Adversaries may exploit vulnerabilities in this service to escalate privileges by spawning unauthorized child processes. The detection rule identifies such anomalies by monitoring for unexpected child processes initiated by the update service, especially those not matching known legitimate executables, thus flagging potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the parent process is com.adobe.ARMDC.SMJobBlessHelper and the user is root, as these are key indicators of potential exploitation.
+- Identify the child process executable that triggered the alert and determine if it is known or expected in the context of Adobe Acrobat Reader updates.
+- Check the system for any recent updates or patches related to Adobe Acrobat Reader to ensure they are up to date, particularly concerning CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613.
+- Investigate the process tree to understand the sequence of events leading to the suspicious child process, looking for any unusual or unauthorized activities.
+- Examine system logs and other security tools for additional indicators of compromise or related suspicious activities around the time of the alert.
+- Assess the system for any signs of privilege escalation or unauthorized access, focusing on changes made by the suspicious process.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they spawn child processes not listed in the known legitimate executables. Users can mitigate this by monitoring update schedules and temporarily excluding these processes during known update windows.
+- Custom scripts or administrative tools executed by system administrators with root privileges might be flagged. To handle this, users can create exceptions for these specific scripts or tools if they are verified as safe and necessary for operations.
+- Security or system management tools that perform integrity checks or system modifications could be misidentified as suspicious. Users should review these tools and, if deemed safe, add them to the exclusion list to prevent false alerts.
+- Development or testing environments where new or experimental software is frequently run may generate false positives. In such cases, users can establish a separate monitoring profile with adjusted rules to accommodate the unique activities of these environments.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious child processes identified by the detection rule that do not match known legitimate executables, ensuring that no unauthorized processes are running.
+- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or unauthorized changes made by the suspicious process.
+- Apply the latest security patches and updates to Adobe Acrobat Reader and the macOS system to address vulnerabilities CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613, ensuring the system is not susceptible to known exploits.
+- Restore any affected files or system configurations from a known good backup to ensure system integrity and remove any potential backdoors or malicious modifications.
+- Enhance monitoring and logging on the affected system to detect any future unauthorized process executions or privilege escalation attempts, ensuring quick detection and response.
+- Report the incident to the appropriate internal security team or external authorities if required, providing detailed information about the threat and actions taken for further investigation and compliance."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_local_user_added_to_admin.toml b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
index 8e00d539268..b7076cfbe18 100644
--- a/rules/macos/privilege_escalation_local_user_added_to_admin.toml
+++ b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
                                                 "/opt/jc/bin/jumpcloud-agent" or
                                                 "/Library/Addigy/go-agent")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Admin Group Account Addition
+
+In macOS environments, tools like `dscl` and `dseditgroup` manage user group memberships, including admin groups. Adversaries may exploit these tools to escalate privileges by adding accounts to admin groups, gaining unauthorized access. The detection rule identifies such attempts by monitoring process activities related to these tools, excluding legitimate management services, to flag potential privilege escalation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of `dscl` or `dseditgroup` with arguments indicating an attempt to add an account to the admin group, such as "/Groups/admin" and "-a" or "-append".
+- Check the process's parent executable path to ensure it is not one of the legitimate management services excluded in the query, such as JamfDaemon, JamfManagementService, jumpcloud-agent, or Addigy go-agent.
+- Investigate the user account associated with the process to determine if it has a history of legitimate administrative actions or if it appears suspicious.
+- Examine recent login events and user activity on the host to identify any unusual patterns or unauthorized access attempts.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or potential indicators of compromise.
+- Assess the risk and impact of the account addition by determining if the account has been successfully added to the admin group and if any unauthorized changes have been made.
+
+### False positive analysis
+
+- Legitimate management services like JAMF and JumpCloud may trigger false positives when they manage user group memberships. These services are already excluded in the rule, but ensure any additional management tools used in your environment are similarly excluded.
+- Automated scripts or maintenance tasks that require temporary admin access might be flagged. Review these scripts and consider adding them to the exclusion list if they are verified as safe.
+- System updates or software installations that modify group memberships could be misidentified. Monitor these activities and adjust the rule to exclude known update processes if they are consistently flagged.
+- User-initiated actions that are part of normal IT operations, such as adding a new admin for legitimate purposes, may appear as false positives. Ensure that such actions are documented and communicated to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or privilege escalation.
+- Review the process execution logs to confirm unauthorized use of `dscl` or `dseditgroup` for adding accounts to the admin group, ensuring the activity is not part of legitimate administrative tasks.
+- Remove any unauthorized accounts from the admin group to restore proper access controls and prevent further misuse of elevated privileges.
+- Conduct a thorough review of all admin group memberships on the affected system to ensure no other unauthorized accounts have been added.
+- Reset passwords for any accounts that were added to the admin group without authorization to prevent further unauthorized access.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future privilege escalation attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/macos/privilege_escalation_root_crontab_filemod.toml b/rules/macos/privilege_escalation_root_crontab_filemod.toml
index 3e51714cdd2..86405b2e937 100644
--- a/rules/macos/privilege_escalation_root_crontab_filemod.toml
+++ b/rules/macos/privilege_escalation_root_crontab_filemod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,40 @@ query = '''
 event.category:file and host.os.type:macos and not event.type:deletion and
  file.path:/private/var/at/tabs/root and not process.executable:/usr/bin/crontab
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privilege Escalation via Root Crontab File Modification
+
+Crontab files in macOS are used to schedule tasks, often requiring elevated privileges for execution. Adversaries exploit this by modifying the root crontab file, enabling unauthorized code execution with root access. The detection rule identifies suspicious modifications to this file, excluding legitimate crontab processes, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is /private/var/at/tabs/root, as this is the specific file path targeted by the rule.
+- Examine the process that modified the root crontab file by checking the process executable path. Ensure it is not /usr/bin/crontab, which is excluded as a legitimate process.
+- Investigate the user account associated with the process that made the modification to determine if it has legitimate access or if it might be compromised.
+- Check for any recent changes or anomalies in user account activity or permissions that could indicate unauthorized access or privilege escalation attempts.
+- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
+- Assess the risk and impact of the modification by determining if any unauthorized or malicious tasks have been scheduled in the crontab file.
+
+### False positive analysis
+
+- System maintenance tasks or updates may modify the root crontab file. To handle these, users can create exceptions for known maintenance processes that are verified as safe.
+- Administrative scripts that require scheduled tasks might trigger this rule. Users should document and exclude these scripts if they are part of regular, authorized operations.
+- Backup or monitoring software that interacts with crontab files could cause false positives. Verify these applications and exclude their processes if they are legitimate and necessary for system operations.
+- Custom automation tools used by IT departments might modify crontab files. Ensure these tools are reviewed and whitelisted if they are part of approved workflows.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks.
+- Review the modified root crontab file to identify any unauthorized or suspicious entries and remove them to stop any malicious scheduled tasks.
+- Conduct a thorough investigation to determine how the crontab file was modified, focusing on identifying any exploited vulnerabilities or unauthorized access points.
+- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access.
+- Apply security patches and updates to the operating system and any vulnerable applications to close exploited vulnerabilities.
+- Monitor the system and network for any signs of continued unauthorized activity or attempts to modify crontab files, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the threat persists or if there is evidence of a broader compromise."""
 
 
 [[rule.threat]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
index debaac79b06..dbc28783f8a 100644
--- a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -79,6 +79,40 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 DNS Tunneling
+
+DNS tunneling exploits the DNS protocol to covertly transmit data between a compromised system and an attacker-controlled server. Adversaries use it for stealthy command-and-control, persistence, or data exfiltration by embedding data within DNS queries. The detection rule leverages machine learning to identify anomalies, such as an unusually high volume of DNS queries to a single domain, indicating potential tunneling activity.
+
+### Possible investigation steps
+
+- Review the DNS query logs to identify the specific top-level domain generating the unusually high volume of queries. This can help pinpoint the potential source of tunneling activity.
+- Analyze the source IP addresses associated with the DNS queries to determine if they originate from known or suspicious hosts within the network.
+- Check for any recent changes or anomalies in the network traffic patterns related to the identified domain, which might indicate tunneling or exfiltration attempts.
+- Investigate the history of the identified domain to assess its reputation and any known associations with malicious activities or threat actors.
+- Correlate the DNS query activity with other security events or alerts in the network to identify any related suspicious behavior or indicators of compromise.
+
+### False positive analysis
+
+- High volume of DNS queries from legitimate software updates or patch management systems can trigger false positives. Users should identify and whitelist domains associated with trusted update services.
+- Content delivery networks (CDNs) often generate numerous DNS queries due to their distributed nature. Exclude known CDN domains from the analysis to reduce false positives.
+- Internal network monitoring tools that rely on DNS for service discovery may cause an increase in DNS queries. Consider excluding these internal domains if they are verified as non-threatening.
+- Some cloud services use DNS for load balancing and may result in high query volumes. Users should review and whitelist these domains if they are confirmed to be safe.
+- Automated scripts or applications that frequently query DNS for legitimate purposes can be excluded by identifying their specific patterns and adding them to an exception list.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration or command-and-control communication.
+- Conduct a thorough analysis of DNS logs to identify the specific domain involved in the tunneling activity and block it at the network perimeter.
+- Review and terminate any suspicious processes or services running on the compromised system that may be associated with the tunneling activity.
+- Reset credentials and review access permissions for accounts that were active on the compromised system to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring for DNS traffic to detect similar tunneling activities in the future, focusing on high-frequency queries to single domains.
+- Coordinate with IT and security teams to apply necessary patches and updates to the affected system to close any vulnerabilities exploited by the attacker."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
index 57cef36eac2..86494e4517b 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -82,6 +82,40 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual DNS Activity
+DNS is crucial for translating domain names into IP addresses, enabling network communication. Adversaries exploit DNS by using rare domains for malicious activities like phishing or command-and-control. The 'Unusual DNS Activity' detection rule leverages machine learning to identify atypical DNS queries, signaling potential threats such as unauthorized access or data exfiltration.
+
+### Possible investigation steps
+
+- Review the DNS query logs to identify the specific rare domain that triggered the alert and determine its reputation using threat intelligence sources.
+- Analyze the source IP address associated with the unusual DNS query to identify the device or user responsible for the activity.
+- Check for any recent changes or anomalies in the network activity of the identified device or user, such as unusual login times or access to sensitive data.
+- Investigate any related alerts or logs that might indicate a broader pattern of suspicious activity, such as multiple rare domain queries or connections to known malicious IP addresses.
+- Examine endpoint security logs on the affected device for signs of malware or unauthorized software that could be responsible for the unusual DNS activity.
+- Assess whether the unusual DNS activity aligns with known tactics, techniques, and procedures (TTPs) associated with command-and-control or data exfiltration, referencing the MITRE ATT&CK framework for guidance.
+
+### False positive analysis
+
+- Legitimate software updates may trigger unusual DNS queries as they contact uncommon domains for downloading updates. Users can create exceptions for known update servers to reduce false positives.
+- Internal applications using dynamic DNS services might generate rare DNS queries. Identifying and whitelisting these services can help in minimizing false alerts.
+- Third-party security tools or monitoring solutions may use unique DNS queries for their operations. Verify and exclude these tools from the detection rule to prevent unnecessary alerts.
+- Cloud services often use diverse and uncommon domains for legitimate operations. Regularly review and update the list of trusted cloud service domains to avoid false positives.
+- New or infrequently accessed legitimate websites may appear as unusual. Users should monitor and whitelist these domains if they are confirmed to be safe and necessary for business operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with the suspicious DNS domain and potential data exfiltration.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and block the identified unusual DNS domain at the network perimeter to prevent other systems from communicating with it.
+- Analyze logs and network traffic to identify any other systems that may have communicated with the same unusual DNS domain and apply similar containment measures.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Restore the affected system from a known good backup if malware removal is not possible or if system integrity is in question.
+- Update and enhance DNS monitoring rules to detect similar unusual DNS activity in the future, ensuring rapid identification and response to potential threats."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
index 7e7f50eccfe..82e617c6c58 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -85,6 +85,41 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Web Request
+The 'Unusual Web Request' detection leverages machine learning to identify rare URLs that deviate from typical web activity, potentially signaling malicious actions like initial access or data exfiltration. Adversaries exploit trusted sites by embedding uncommon URLs for payload delivery or command-and-control. This rule flags such anomalies, aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific rare URL that triggered the detection and note any associated IP addresses or domains.
+- Check historical logs to determine if the rare URL has been accessed previously and identify any patterns or trends in its usage.
+- Investigate the source of the request by examining the user agent, referrer, and originating IP address to assess whether it aligns with known legitimate traffic or appears suspicious.
+- Analyze the destination of the URL to determine if it is associated with known malicious activity or if it has been flagged in threat intelligence databases.
+- Correlate the unusual web request with other security events or alerts to identify potential connections to broader attack campaigns or ongoing threats.
+- Assess the impacted systems or users to determine if there are any signs of compromise, such as unexpected processes, network connections, or data exfiltration attempts.
+- Consider reaching out to the user or system owner to verify if the access to the rare URL was intentional and legitimate, providing additional context for the investigation.
+
+### False positive analysis
+
+- Web scraping tools and bots can trigger false positives by making requests to uncommon URLs as part of routine internet background traffic.
+- Legitimate web scanning or enumeration activities by security teams may be flagged; these should be reviewed and whitelisted if verified as non-threatening.
+- Automated processes or scripts that access rare URLs for legitimate business purposes can be excluded by identifying and documenting these activities.
+- Frequent access to uncommon URLs by trusted internal applications or services should be monitored and added to exception lists to prevent unnecessary alerts.
+- Regularly review and update the list of excluded URLs to ensure it reflects current legitimate activities and does not inadvertently allow malicious traffic.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with the suspicious URL and potential data exfiltration.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or software.
+- Review and block the identified unusual URL at the network perimeter to prevent other systems from accessing it.
+- Analyze network logs to identify any other systems that may have communicated with the suspicious URL and apply similar containment measures.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced monitoring for similar unusual web requests across the network to detect and respond to potential threats more quickly in the future.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to better detect and block uncommon URLs associated with command-and-control activities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
index 92fe092fe32..1ec179e39c8 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -83,6 +83,41 @@ tags = [
     "Tactic: Command and Control",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Web User Agent
+
+User agents identify applications interacting with web servers, typically browsers. Adversaries exploit this by using non-standard user agents for malicious activities like data exfiltration or command-and-control. The 'Unusual Web User Agent' detection rule leverages machine learning to identify rare user agents, flagging potential threats from atypical processes, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the specific user agent string that triggered the alert to determine if it matches known malicious patterns or tools like Burp or SQLmap.
+- Identify the source and destination IP addresses involved in the alert to assess whether they are associated with known malicious activity or unusual geographic locations.
+- Check the process that generated the unusual user agent to determine if it is a legitimate application or potentially malicious software.
+- Analyze network traffic logs for additional context around the time of the alert to identify any related suspicious activities or patterns.
+- Investigate any recent changes or installations on the system that could explain the presence of the unusual user agent, such as new software or updates.
+- Correlate the alert with other security events or logs to see if there are any related indicators of compromise or ongoing threats.
+
+### False positive analysis
+
+- Non-malicious applications like weather monitoring or stock-trading programs may use uncommon user agents. Regularly review and whitelist these applications to prevent them from triggering false positives.
+- Automated tools such as web scrapers or bots can generate unusual user agents. Identify and document these tools if they are part of legitimate business operations, and create exceptions for them in the detection rule.
+- Internal scanners or monitoring tools might use non-standard user agents. Ensure these tools are recognized and excluded from alerts by updating the rule's exception list.
+- Regularly update the list of known benign user agents to reflect changes in legitimate software and tools used within the organization, reducing unnecessary alerts.
+- Collaborate with IT and security teams to maintain an up-to-date inventory of authorized applications and their user agents, ensuring that only truly suspicious activities are flagged.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration or command-and-control communication.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and analyze the logs of the affected system and network traffic to identify the source and scope of the unusual user agent activity.
+- Block the identified malicious IP addresses or domains associated with the unusual user agent in the firewall and intrusion prevention systems.
+- Update and patch all software and systems to close any vulnerabilities that may have been exploited by the adversary.
+- Restore the affected system from a clean backup if malware removal is not feasible or if the system integrity is compromised.
+- Report the incident to the appropriate internal teams and, if necessary, escalate to external cybersecurity authorities or partners for further investigation and support."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
index 7c9569ca0b5..6e0b05c6e0f 100644
--- a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
+++ b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -98,6 +98,40 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Logon Events
+The 'Spike in Logon Events' detection leverages machine learning to identify anomalies in authentication patterns, signaling potential threats like password spraying or brute force attacks. Adversaries exploit these methods to gain unauthorized access by overwhelming systems with login attempts. This rule detects unusual surges in successful logins, indicating possible credential access tactics, and aids in preemptive threat mitigation.
+
+### Possible investigation steps
+
+- Review the timestamp and source of the spike in logon events to determine the time frame and systems affected.
+- Analyze the user accounts involved in the spike to identify any patterns or anomalies, such as accounts with multiple logins from different locations or IP addresses.
+- Check for any recent changes in user permissions or roles that could explain the increase in logon events.
+- Investigate the IP addresses associated with the logon events to identify any known malicious sources or unusual geographic locations.
+- Correlate the logon events with other security alerts or logs, such as failed login attempts, to identify potential password spraying or brute force activities.
+- Assess whether there are any concurrent alerts or indicators of compromise that could suggest a broader attack campaign.
+
+### False positive analysis
+
+- High-volume legitimate logins from automated systems or scripts can trigger false positives. Identify and whitelist these systems to prevent unnecessary alerts.
+- Scheduled batch processes or system maintenance activities may cause spikes in logon events. Exclude these known activities by setting up exceptions based on time and source.
+- Users with roles that require frequent logins, such as IT administrators or customer support agents, might be flagged. Create user-based exceptions for these roles to reduce false positives.
+- Integration with third-party services that authenticate frequently can lead to detection triggers. Review and exclude these services from the rule to avoid misclassification.
+- Consider adjusting the sensitivity of the machine learning model if certain patterns are consistently flagged as anomalies but are verified as legitimate.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access. This can be done by disabling the accounts or resetting passwords.
+- Conduct a thorough review of recent authentication logs to identify any other accounts that may have been compromised or targeted.
+- Implement multi-factor authentication (MFA) for all user accounts to add an additional layer of security against unauthorized access.
+- Notify the security operations team to monitor for any further suspicious logon activities and to ensure that the threat is contained.
+- Escalate the incident to the incident response team if there is evidence of a broader attack or if sensitive data may have been accessed.
+- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their roles.
+- Enhance monitoring and alerting mechanisms to detect similar spikes in logon events in the future, ensuring rapid response to potential threats."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
index 25165dddda5..b74e9c8a20a 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -84,6 +84,41 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux Process Calling the Metadata Service
+
+In cloud environments, the metadata service provides essential instance-specific data, including credentials and configuration scripts. Adversaries may exploit this service by using atypical processes to access sensitive information, potentially leading to credential theft. The detection rule leverages machine learning to identify anomalous process behavior, flagging unusual access patterns indicative of malicious intent.
+
+### Possible investigation steps
+
+- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity.
+- Check the user account under which the process is running to determine if it has legitimate access to the metadata service.
+- Investigate the process's parent process to understand the context of how it was initiated and whether it aligns with expected behavior.
+- Analyze network logs to verify if the process made any outbound connections to the metadata service and assess the volume and frequency of these requests.
+- Cross-reference the process and user information with recent changes or deployments in the environment to rule out any legitimate use cases.
+- Examine system logs for any other suspicious activities or anomalies around the time the alert was triggered, such as unauthorized access attempts or privilege escalations.
+
+### False positive analysis
+
+- Routine system updates or maintenance scripts may access the metadata service, triggering false positives. Users can create exceptions for known update processes to prevent unnecessary alerts.
+- Automated backup or monitoring tools might interact with the metadata service as part of their normal operations. Identify these tools and whitelist their processes to reduce false alarms.
+- Custom scripts developed in-house for configuration management might access the metadata service. Review these scripts and add them to an exception list if they are verified as non-threatening.
+- Cloud management agents provided by the cloud service provider may access the metadata service for legitimate purposes. Verify these agents and exclude them from the detection rule to avoid false positives.
+- Development or testing environments often have processes that mimic production behavior, including metadata service access. Ensure these environments are accounted for in the rule configuration to minimize false alerts.
+
+### Response and remediation
+
+- Isolate the affected instance immediately to prevent further unauthorized access to the metadata service and potential lateral movement within the network.
+- Terminate the unusual process accessing the metadata service to stop any ongoing data exfiltration or credential harvesting.
+- Conduct a thorough review of access logs and process execution history on the affected instance to identify any additional unauthorized activities or compromised credentials.
+- Rotate all credentials and secrets that may have been exposed through the metadata service to mitigate the risk of credential theft and unauthorized access.
+- Implement network segmentation and access controls to restrict access to the metadata service, ensuring only authorized processes and users can interact with it.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or services have been compromised.
+- Update and enhance monitoring rules to detect similar anomalous behaviors in the future, focusing on unusual process activities and access patterns to the metadata service."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
index 1e960dc1f49..3277fec81e1 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -84,6 +84,42 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux User Calling the Metadata Service
+
+Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using unusual Linux users to query the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalous access patterns, focusing on credential access tactics, thus alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Linux user account that accessed the metadata service and the timestamp of the activity.
+- Check the user's login history and recent activity on the system to determine if the access pattern is consistent with their normal behavior or if it appears suspicious.
+- Investigate the source IP address and geolocation associated with the metadata service access to identify any anomalies or unexpected locations.
+- Examine system logs and audit trails for any additional unauthorized or unusual access attempts around the same time frame.
+- Verify if the user account has legitimate reasons to access the metadata service, such as running specific applications or scripts that require metadata information.
+- Assess whether there have been any recent changes to user permissions or roles that could explain the access, and ensure that these changes were authorized.
+- If suspicious activity is confirmed, consider isolating the affected instance and user account to prevent further unauthorized access while conducting a deeper investigation.
+
+### False positive analysis
+
+- Routine administrative scripts may access the metadata service for legitimate configuration purposes. To handle this, identify and whitelist these scripts to prevent unnecessary alerts.
+- Automated backup or monitoring tools might query the metadata service as part of their normal operations. Exclude these tools by adding them to an exception list based on their user accounts or process identifiers.
+- Scheduled tasks or cron jobs that require metadata access for updates or maintenance can trigger false positives. Review and document these tasks, then configure the rule to ignore these specific access patterns.
+- Development or testing environments often simulate metadata service access to mimic production scenarios. Ensure these environments are recognized and excluded from the rule to avoid false alerts.
+- Temporary user accounts created for specific projects or tasks may access the metadata service. Regularly audit these accounts and adjust the rule to exclude them if their access is deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux instance from the network to prevent further unauthorized access or data exfiltration.
+- Revoke any credentials or tokens that may have been exposed or accessed through the metadata service to prevent misuse.
+- Conduct a thorough review of the instance's user accounts and permissions, removing any unauthorized or suspicious accounts and tightening access controls.
+- Analyze system logs and metadata service access logs to identify the source and scope of the breach, focusing on the unusual user activity.
+- Restore the affected instance from a known good backup if any unauthorized changes or malware are detected.
+- Implement additional monitoring and alerting for metadata service access, particularly for unusual user accounts, to detect similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or services are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_suspicious_login_activity.toml b/rules/ml/credential_access_ml_suspicious_login_activity.toml
index ee7a91db756..fa4ca3023ec 100644
--- a/rules/ml/credential_access_ml_suspicious_login_activity.toml
+++ b/rules/ml/credential_access_ml_suspicious_login_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -95,6 +95,40 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Login Activity
+The 'Unusual Login Activity' detection leverages machine learning to identify anomalies in authentication patterns, flagging potential brute force attacks. Adversaries exploit credential access by attempting numerous logins to gain unauthorized entry. This rule assesses login frequency and patterns, alerting analysts to deviations indicative of credential abuse, thus enhancing threat detection and identity audit processes.
+
+### Possible investigation steps
+
+- Review the source IP addresses associated with the unusual login attempts to determine if they are known or suspicious.
+- Check the user accounts involved in the alert for any recent changes or unusual activity, such as password resets or privilege escalations.
+- Analyze the timestamps of the login attempts to identify patterns or timeframes that may indicate automated or scripted attacks.
+- Correlate the login attempts with other security events or logs to identify any concurrent suspicious activities, such as failed login attempts or access to sensitive resources.
+- Investigate the geographic locations of the login attempts to see if they align with the user's typical login behavior or if they suggest potential compromise.
+- Assess the risk score and severity of the alert in the context of the organization's security posture and any ongoing threats or incidents.
+
+### False positive analysis
+
+- High login activity from automated scripts or scheduled tasks can trigger false positives. Identify and whitelist these known scripts to prevent unnecessary alerts.
+- Employees using shared accounts may cause an increase in login attempts. Implement user-specific accounts and monitor shared account usage to reduce false positives.
+- Frequent logins from IT personnel conducting routine maintenance can be misinterpreted as unusual activity. Exclude these users or adjust thresholds for specific roles to minimize false alerts.
+- Users with legitimate reasons for high login frequency, such as customer support staff, should be identified and their activity patterns analyzed to adjust detection parameters accordingly.
+- Remote workers using VPNs or accessing systems from multiple locations might trigger alerts. Consider location-based exceptions for known remote access points to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access and contain the threat.
+- Reset passwords for the compromised accounts and enforce multi-factor authentication (MFA) to enhance security.
+- Conduct a thorough review of recent login activity and access logs to identify any unauthorized access or data exfiltration.
+- Notify the security operations team to monitor for any further suspicious activity and ensure continuous surveillance of the affected systems.
+- Escalate the incident to the incident response team if there is evidence of data compromise or if the attack persists despite initial containment efforts.
+- Implement additional monitoring rules to detect similar brute force attempts in the future, focusing on login frequency and patterns.
+- Review and update access controls and authentication policies to prevent recurrence, ensuring they align with best practices for credential security."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
index 33d8ed7590e..2338c7c899c 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,40 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Windows Process Calling the Metadata Service
+
+In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries may exploit this by using atypical Windows processes to access the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalies in process behavior, flagging potential credential access attempts by unusual processes.
+
+### Possible investigation steps
+
+- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity.
+- Check the parent process of the flagged process to understand the context of how it was initiated and assess if it aligns with expected behavior.
+- Investigate the user account under which the process was executed to determine if it has legitimate access to the metadata service or if it has been compromised.
+- Analyze network logs to identify any outbound connections to the metadata service from the flagged process, noting any unusual patterns or destinations.
+- Cross-reference the process and user activity with recent changes or deployments in the environment to rule out false positives related to legitimate administrative actions.
+- Consult threat intelligence sources to see if the process or command line arguments have been associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- Routine system updates or maintenance scripts may trigger the rule. Review the process details and verify if they align with scheduled maintenance activities. If confirmed, consider adding these processes to an exception list.
+- Legitimate software or security tools that access the metadata service for configuration purposes might be flagged. Identify these tools and create exceptions for their known processes to prevent future alerts.
+- Automated backup or monitoring solutions that interact with the metadata service could be misidentified as threats. Validate these processes and exclude them if they are part of authorized operations.
+- Custom scripts developed in-house for cloud management tasks may access the metadata service. Ensure these scripts are documented and, if safe, add them to the list of exceptions to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the unusual process accessing the metadata service to stop any ongoing credential harvesting attempts.
+- Conduct a thorough review of the system's event logs and process history to identify any additional indicators of compromise or related malicious activity.
+- Change all credentials that may have been exposed or accessed through the metadata service to mitigate the risk of unauthorized access.
+- Implement network segmentation to limit access to the metadata service, ensuring only authorized processes and users can interact with it.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger attack campaign.
+- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar anomalous process behaviors in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
index 2e6b058293f..fb921e5d0a6 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,42 @@ tags = [
     "Tactic: Credential Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Windows User Calling the Metadata Service
+
+Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using compromised Windows accounts to query the service, aiming to harvest sensitive information. The detection rule leverages machine learning to identify atypical access patterns by Windows users, flagging potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Windows user account involved in the unusual access to the metadata service.
+- Check the timestamp of the access attempt to correlate with any known scheduled tasks or legitimate user activities.
+- Investigate the source IP address and device from which the metadata service was accessed to determine if it aligns with expected user behavior or known assets.
+- Examine recent login and access logs for the identified user account to detect any other suspicious activities or anomalies.
+- Assess whether there have been any recent changes to the user's permissions or roles that could explain the access attempt.
+- Look for any other alerts or incidents involving the same user account or device to identify potential patterns of malicious behavior.
+- Consult with the user or their manager to verify if the access was legitimate or if the account may have been compromised.
+
+### False positive analysis
+
+- Routine administrative tasks by IT personnel may trigger alerts. Review access logs to confirm legitimate administrative actions and consider whitelisting specific user accounts or IP addresses.
+- Automated scripts or scheduled tasks that query the metadata service for configuration updates can be mistaken for suspicious activity. Identify these scripts and exclude them from the rule by adding them to an exception list.
+- Cloud management tools that regularly access the metadata service for monitoring or configuration purposes might be flagged. Verify these tools and create exceptions for their known access patterns.
+- Instances where legitimate software updates or patch management processes access the metadata service should be reviewed. Document these processes and exclude them from triggering alerts.
+- Temporary access by third-party vendors or consultants may appear unusual. Ensure their access is documented and create temporary exceptions during their engagement period.
+
+### Response and remediation
+
+- Immediately isolate the affected Windows system from the network to prevent further unauthorized access to the metadata service.
+- Revoke any potentially compromised credentials identified during the investigation and issue new credentials to affected users.
+- Conduct a thorough review of access logs to identify any unauthorized data access or exfiltration attempts from the metadata service.
+- Implement additional monitoring on the affected system and similar systems to detect any further anomalous access attempts.
+- Escalate the incident to the security operations center (SOC) for a deeper investigation into potential lateral movement or other compromised systems.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Review and enhance access controls and permissions for the metadata service to ensure only authorized users can access sensitive information."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_information_discovery.toml b/rules/ml/discovery_ml_linux_system_information_discovery.toml
index 2e06a27dba8..c19ac969748 100644
--- a/rules/ml/discovery_ml_linux_system_information_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_information_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -86,6 +86,41 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux System Information Discovery Activity
+
+In Linux environments, system information discovery involves commands that reveal details about system configuration and software versions. While typically used for legitimate troubleshooting, adversaries exploit this to gather intelligence for further attacks, such as privilege escalation. The detection rule leverages machine learning to identify atypical usage patterns, flagging potential misuse by compromised accounts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and the command executed that triggered the alert. Focus on any unusual or unexpected user context.
+- Check the user's activity history to determine if this type of command execution is typical for the user or if it deviates from their normal behavior.
+- Investigate the source IP address and hostname associated with the alert to verify if they are consistent with the user's usual access patterns or if they indicate potential unauthorized access.
+- Examine system logs for any additional suspicious activities or anomalies around the time of the alert, such as failed login attempts or other unusual commands executed.
+- Assess whether the command executed could be part of a legitimate troubleshooting process or if it aligns with known tactics for privilege escalation or persistence.
+- If the account is suspected to be compromised, consider resetting the user's credentials and conducting a broader investigation into potential lateral movement or data exfiltration activities.
+
+### False positive analysis
+
+- Routine administrative tasks by system administrators may trigger alerts. To manage this, create exceptions for known admin accounts performing regular maintenance.
+- Automated scripts for system monitoring or inventory management can be flagged. Identify and whitelist these scripts to prevent unnecessary alerts.
+- Scheduled jobs or cron tasks that gather system information for legitimate purposes might be detected. Review and exclude these tasks from the rule to reduce false positives.
+- Development or testing environments where frequent system information queries are normal can cause alerts. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these contexts.
+- Security tools that perform regular system scans may be misidentified. Ensure these tools are recognized and excluded from triggering the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified as part of the unusual system information discovery activity.
+- Review and reset credentials for the potentially compromised account to prevent further misuse.
+- Conduct a thorough examination of system logs and command history to identify any additional malicious activities or indicators of compromise.
+- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could be exploited for privilege escalation.
+- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of unusual system information discovery activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
index eae2bbef640..1a179b9740e 100644
--- a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 25
@@ -86,6 +86,41 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux Network Configuration Discovery
+
+In Linux environments, network configuration tools are essential for managing and troubleshooting network settings. Adversaries may exploit these tools to gather network details, aiding in lateral movement or further reconnaissance. The detection rule leverages machine learning to identify atypical usage patterns of network commands by unexpected users, signaling potential account compromise or unauthorized network probing.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific network configuration commands executed and the user account involved. Focus on commands that are typically used for network discovery, such as `ifconfig`, `ip`, `netstat`, or `route`.
+- Check the user's login history and session details to determine if the account activity aligns with the user's normal behavior or if there are signs of unauthorized access, such as logins from unusual IP addresses or at odd times.
+- Investigate the user's role and responsibilities to assess whether they have a legitimate reason to perform network configuration discovery. This can help determine if the activity is expected or suspicious.
+- Examine recent changes in user permissions or group memberships that might have allowed the execution of network configuration commands by an unexpected user.
+- Correlate the alert with other security events or logs, such as authentication logs, to identify any related suspicious activities, such as failed login attempts or privilege escalation attempts.
+- If the account is suspected to be compromised, initiate a password reset and review the system for any signs of further compromise or malicious activity, such as unauthorized software installations or data exfiltration attempts.
+
+### False positive analysis
+
+- Routine administrative tasks by system administrators may trigger the rule. To manage this, create exceptions for known admin accounts performing regular network configuration checks.
+- Automated scripts or cron jobs that perform network diagnostics can be mistaken for unusual activity. Identify and whitelist these scripts to prevent false alerts.
+- Network monitoring tools running under specific service accounts might be flagged. Ensure these service accounts are documented and excluded from the rule.
+- Developers or IT staff conducting legitimate troubleshooting in non-production environments may cause alerts. Establish a process to temporarily exclude these users during known maintenance windows.
+- New employees or contractors performing onboarding tasks might trigger the rule. Implement a review process to quickly assess and exclude these cases if they are verified as non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes or sessions initiated by the unusual user to halt ongoing reconnaissance activities.
+- Conduct a thorough review of the affected user's account for signs of compromise, such as unauthorized access attempts or changes in user privileges.
+- Reset the credentials of the compromised account and enforce multi-factor authentication to prevent future unauthorized access.
+- Analyze network logs and system activity to identify any additional systems that may have been accessed or probed by the adversary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary.
+- Update detection mechanisms to include newly identified indicators of compromise (IOCs) and enhance monitoring for similar unusual network configuration discovery activities."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
index 83d47f0cbe2..0d47bac1398 100644
--- a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 25
@@ -86,6 +86,41 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux Network Connection Discovery
+
+In Linux environments, network connection discovery tools help administrators understand system connectivity. Adversaries exploit these tools to map networks, aiding in lateral movement and further attacks. The detection rule leverages machine learning to identify atypical usage patterns by unusual users, signaling potential account compromise or unauthorized network probing activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and the command executed that triggered the alert.
+- Check the user's activity history to determine if this behavior is consistent with their normal usage patterns or if it is anomalous.
+- Investigate the source IP address and hostname associated with the command execution to verify if they are known and trusted within the network.
+- Examine system logs for any additional suspicious activities or commands executed by the same user account around the time of the alert.
+- Assess the user's access permissions and recent changes to their account to identify any unauthorized modifications or potential compromise.
+- Correlate the alert with other security events or alerts to determine if this activity is part of a larger attack pattern or campaign.
+
+### False positive analysis
+
+- Routine administrative tasks by system administrators can trigger alerts. Regularly review and whitelist known administrator accounts performing legitimate network discovery.
+- Automated scripts or monitoring tools that perform network checks may be flagged. Identify and exclude these scripts from triggering alerts by adding them to an exception list.
+- Uncommon troubleshooting activities by support teams might be misidentified. Document and approve these activities to prevent false positives.
+- Scheduled maintenance activities involving network discovery should be accounted for. Create a schedule-based exception to avoid unnecessary alerts during these periods.
+- New employees or contractors performing legitimate network discovery as part of their onboarding process can be mistaken for threats. Ensure their activities are monitored and approved by the IT department.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes or sessions initiated by the unusual user to halt ongoing network discovery activities.
+- Conduct a thorough review of the affected user's account activity and permissions to identify any unauthorized changes or access patterns.
+- Reset the credentials of the compromised account and enforce multi-factor authentication to prevent further unauthorized access.
+- Analyze network logs and system logs to identify any additional systems that may have been accessed or probed by the threat actor.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts are compromised.
+- Update and enhance network monitoring and alerting rules to detect similar unauthorized network discovery activities in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_process_discovery.toml b/rules/ml/discovery_ml_linux_system_process_discovery.toml
index 9eadd5f1c4b..693a4307405 100644
--- a/rules/ml/discovery_ml_linux_system_process_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_process_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -86,6 +86,41 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux Process Discovery Activity
+
+In Linux environments, process discovery commands help users and administrators understand active processes, aiding in system management and troubleshooting. However, adversaries can exploit these commands to map running applications, potentially identifying vulnerabilities for privilege escalation or persistence. The detection rule leverages machine learning to identify atypical usage patterns, flagging potential threats when process discovery occurs from unexpected user contexts, thus helping to preemptively mitigate risks associated with compromised accounts.
+
+### Possible investigation steps
+
+- Review the user context from which the process discovery command was executed to determine if the user account is expected to perform such actions.
+- Check the command history for the user account to identify any other unusual or unauthorized commands executed around the same time.
+- Analyze the process discovery command details, including the specific command used and its parameters, to understand the intent and scope of the activity.
+- Investigate the source IP address and host from which the command was executed to verify if it aligns with known and authorized devices for the user.
+- Examine recent authentication logs for the user account to identify any suspicious login attempts or anomalies in login patterns.
+- Correlate the activity with any other alerts or logs that might indicate a broader attack pattern or compromise, such as privilege escalation attempts or lateral movement.
+
+### False positive analysis
+
+- System administrators performing routine maintenance or troubleshooting may trigger the rule. To manage this, create exceptions for known administrator accounts or specific maintenance windows.
+- Automated scripts or monitoring tools that regularly check system processes can be mistaken for unusual activity. Identify these scripts and whitelist their execution context to prevent false alerts.
+- New software installations or updates might involve process discovery commands as part of their setup. Monitor installation activities and temporarily adjust the rule sensitivity during these periods.
+- Developers or power users who frequently use process discovery commands for legitimate purposes can be excluded by adding their user accounts to an exception list, ensuring their activities do not trigger false positives.
+- Training or testing environments where process discovery is part of normal operations should be configured with separate rules or exceptions to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the threat actor.
+- Terminate any suspicious processes identified during the investigation to halt potential malicious activity.
+- Change passwords for the compromised account and any other accounts that may have been accessed using the same credentials to prevent further unauthorized access.
+- Conduct a thorough review of system logs and user activity to identify any additional signs of compromise or unauthorized access attempts.
+- Restore the system from a known good backup if any malicious modifications or persistence mechanisms are detected.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of unusual process discovery activity.
+- Escalate the incident to the security operations team for further analysis and to determine if broader organizational impacts need to be addressed."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/discovery_ml_linux_system_user_discovery.toml b/rules/ml/discovery_ml_linux_system_user_discovery.toml
index c7ce566570c..1d34ad725d6 100644
--- a/rules/ml/discovery_ml_linux_system_user_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_user_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -86,6 +86,40 @@ tags = [
     "Tactic: Discovery",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux User Discovery Activity
+
+In Linux environments, user discovery commands help identify active users and system owners, crucial for system management. However, adversaries exploit this by executing these commands from atypical user contexts, often indicating account compromise. The detection rule leverages machine learning to identify anomalies in user discovery activities, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific user account and the command executed that triggered the alert.
+- Check the login history and session details for the identified user account to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Investigate the source IP address and hostname associated with the user session to verify if they are known and trusted within the organization.
+- Examine recent changes to user permissions or group memberships for the identified account to detect any unauthorized modifications.
+- Look for any additional unusual or unexpected commands executed by the same user account around the time of the alert to identify potential follow-up malicious activities.
+- Correlate the alert with other security events or logs, such as authentication logs or network traffic, to gather more context and assess the scope of the potential compromise.
+
+### False positive analysis
+
+- System administrators performing routine checks may trigger the rule. To manage this, create exceptions for known admin accounts executing user discovery commands during regular maintenance windows.
+- Automated scripts or monitoring tools that run user discovery commands can cause false positives. Identify these scripts and whitelist their execution paths or user accounts.
+- Developers or IT staff conducting legitimate troubleshooting might be flagged. Document these activities and exclude specific user accounts or IP addresses from the rule.
+- Scheduled tasks or cron jobs that include user discovery commands could be misinterpreted as threats. Review and exclude these tasks from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes associated with the unusual user discovery activity to halt potential malicious actions.
+- Conduct a thorough review of the affected user account's recent activities and access logs to identify any unauthorized changes or access.
+- Reset the credentials of the compromised account and any other accounts that may have been accessed using the compromised credentials.
+- Implement additional monitoring on the affected system and user accounts to detect any further suspicious activities or attempts to regain access.
+- Escalate the incident to the security operations team for a deeper investigation into potential related threats, such as credential dumping or privilege escalation attempts.
+- Review and update access controls and permissions to ensure that only authorized users have access to sensitive systems and data, reducing the risk of future compromises."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/execution_ml_windows_anomalous_script.toml b/rules/ml/execution_ml_windows_anomalous_script.toml
index 43a98b856eb..f79b1eace2c 100644
--- a/rules/ml/execution_ml_windows_anomalous_script.toml
+++ b/rules/ml/execution_ml_windows_anomalous_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -84,6 +84,41 @@ tags = [
     "Tactic: Execution",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Powershell Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries often exploit its capabilities to execute malicious scripts, leveraging obfuscation to evade detection. The 'Suspicious Powershell Script' detection rule employs machine learning to identify unusual script characteristics, such as obfuscation, indicating potential threats. By analyzing these anomalies, the rule aids in early threat detection and mitigation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific PowerShell script or command that triggered the detection, focusing on any obfuscated elements.
+- Examine the source endpoint and user account associated with the alert to determine if the activity aligns with expected behavior or if it appears suspicious.
+- Check the execution history on the affected endpoint for any other unusual or unauthorized PowerShell commands or scripts executed around the same time.
+- Investigate the network activity from the source endpoint to identify any connections to known malicious IP addresses or domains.
+- Correlate the alert with other security events or logs, such as antivirus alerts or firewall logs, to gather additional context and assess the potential impact.
+- Consult threat intelligence sources to determine if the detected script or its components are associated with known malware or attack campaigns.
+
+### False positive analysis
+
+- Legitimate administrative scripts may trigger the rule due to obfuscation techniques used for efficiency or security. Review the script's purpose and source to determine its legitimacy.
+- Automated deployment tools often use PowerShell scripts that appear obfuscated. Identify and whitelist these tools to prevent unnecessary alerts.
+- Security software updates might use obfuscated scripts for protection against tampering. Verify the update source and add exceptions for known trusted vendors.
+- Custom scripts developed in-house for specific tasks may use obfuscation for intellectual property protection. Document and exclude these scripts after confirming their safety.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening scripts are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate any suspicious PowerShell processes identified on the affected system to halt the execution of potentially harmful scripts.
+- Conduct a thorough review of the PowerShell script logs and execution history on the affected system to identify any unauthorized or malicious commands executed.
+- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise.
+- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for PowerShell activity across the network, focusing on detecting obfuscation and unusual script characteristics.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
index f6b95127b55..0208ddf41a7 100644
--- a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
+++ b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -95,6 +95,40 @@ tags = [
     "Tactic: Initial Access",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Source IP for a User to Logon from
+Machine learning models analyze login patterns to identify atypical IP addresses for users, which may indicate compromised accounts or lateral movement by threat actors. Adversaries exploit valid credentials to access systems from unexpected locations. This detection rule flags such anomalies, aiding in early identification of unauthorized access attempts, thereby enhancing security posture.
+
+### Possible investigation steps
+
+- Review the login details to identify the unusual source IP address and compare it with the user's typical login locations and times.
+- Check the geolocation of the unusual IP address to determine if it aligns with any known travel or business activities of the user.
+- Analyze the user's recent activity logs to identify any other suspicious behavior or anomalies that might indicate account compromise.
+- Investigate if there are any other users or systems that have logged in from the same unusual IP address, which could suggest lateral movement.
+- Contact the user to verify if they recognize the login activity and if they have recently traveled or used a VPN that might explain the unusual IP address.
+- Cross-reference the unusual IP address with threat intelligence sources to determine if it is associated with known malicious activity.
+
+### False positive analysis
+
+- Users frequently traveling or working remotely may trigger false positives due to legitimate logins from various locations. To manage this, create exceptions for known travel patterns or remote work IP ranges.
+- Employees using VPNs or proxy services can appear to log in from unusual IP addresses. Identify and whitelist IP ranges associated with company-approved VPNs or proxies.
+- Shared accounts used by multiple users across different locations can generate alerts. Implement stricter access controls or assign unique credentials to each user to reduce false positives.
+- Automated systems or scripts that log in from different IP addresses might be flagged. Document and exclude these systems from the rule if they are verified as non-threatening.
+- Regularly review and update the list of excluded IP addresses to ensure that only legitimate exceptions are maintained, reducing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Conduct a password reset for the compromised account and ensure the new password adheres to strong security policies.
+- Review and terminate any active sessions associated with the unusual IP address to cut off any ongoing unauthorized access.
+- Analyze logs to identify any lateral movement or additional compromised accounts and isolate those accounts as necessary.
+- Notify the user of the suspicious activity and verify if they recognize the unusual IP address or if they have recently traveled.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been affected.
+- Implement IP whitelisting or geofencing rules to restrict access from unexpected locations, enhancing future detection and prevention."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/ml_high_count_network_denies.toml b/rules/ml/ml_high_count_network_denies.toml
index c0f5fc17b56..bdabd7f7dd9 100644
--- a/rules/ml/ml_high_count_network_denies.toml
+++ b/rules/ml/ml_high_count_network_denies.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -76,4 +76,38 @@ rule_id = "eaa77d63-9679-4ce3-be25-3ba8b795e5fa"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Firewall Denies
+
+Firewalls and ACLs are critical in controlling network traffic, blocking unauthorized access. Adversaries may exploit misconfigurations or launch attacks like reconnaissance or denial-of-service to overwhelm these defenses. The 'Spike in Firewall Denies' detection rule leverages machine learning to identify unusual surges in denied traffic, signaling potential misconfigurations or malicious activities.
+
+### Possible investigation steps
+
+- Review the time frame and source IP addresses associated with the spike in denied traffic to identify any patterns or anomalies.
+- Check the firewall and ACL logs for any recent changes or misconfigurations that could have led to the increase in denied traffic.
+- Investigate the destination IP addresses and ports targeted by the denied traffic to determine if they are associated with known malicious activity or if they are legitimate services.
+- Analyze the volume and frequency of the denied requests to assess whether they align with typical denial-of-service attack patterns or reconnaissance activities.
+- Correlate the denied traffic with other security alerts or logs to identify any related suspicious activities or potential indicators of compromise within the network.
+
+### False positive analysis
+
+- Routine network scans by security tools or IT teams may trigger spikes in denied traffic. Regularly review and whitelist known IP addresses or tools to prevent these from being flagged.
+- Misconfigured applications that frequently attempt unauthorized access can cause false positives. Identify and correct these configurations to reduce unnecessary alerts.
+- Legitimate but high-volume business applications might generate traffic patterns similar to reconnaissance activities. Monitor and document these applications, and create exceptions for their traffic patterns.
+- Scheduled maintenance or updates can lead to temporary spikes in denied traffic. Coordinate with IT teams to anticipate these events and adjust monitoring rules accordingly.
+- Internal network changes, such as new device deployments or network architecture updates, might cause unexpected traffic patterns. Ensure these changes are communicated and accounted for in the firewall rules to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate affected systems or segments of the network to prevent further unauthorized access or potential spread of malicious activity.
+- Analyze the denied traffic logs to identify the source IP addresses and block them at the firewall or ACL level to prevent further attempts.
+- Review and correct any misconfigurations in firewall rules or ACLs that may have contributed to the spike in denied traffic.
+- Conduct a thorough investigation to determine if the spike is related to a denial-of-service attack and, if confirmed, engage with your internet service provider (ISP) for additional support and mitigation strategies.
+- If malicious activity is suspected, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response.
+- Implement additional monitoring and alerting for similar patterns of denied traffic to enhance early detection of potential threats.
+- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly."""
 
diff --git a/rules/ml/ml_high_count_network_events.toml b/rules/ml/ml_high_count_network_events.toml
index edc03f65057..12799e14053 100644
--- a/rules/ml/ml_high_count_network_events.toml
+++ b/rules/ml/ml_high_count_network_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -75,4 +75,38 @@ rule_id = "b240bfb8-26b7-4e5e-924e-218144a3fa71"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Spike in Network Traffic
+Machine learning models analyze network traffic patterns to identify anomalies, such as unexpected spikes. These spikes may indicate malicious activities like data exfiltration or denial-of-service attacks. Adversaries exploit network vulnerabilities to flood traffic or extract data. The 'Spike in Network Traffic' rule leverages ML to flag unusual traffic surges, aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the timestamp and duration of the traffic spike to determine if it correlates with any scheduled business activities or known events.
+- Analyze the source and destination IP addresses involved in the traffic spike to identify any unfamiliar or suspicious entities.
+- Examine the types of network protocols and services involved in the spike to assess if they align with typical network usage patterns.
+- Check for any recent changes in network configurations or security policies that might explain the unusual traffic patterns.
+- Investigate any associated user accounts or devices to determine if they have been compromised or are exhibiting unusual behavior.
+- Cross-reference the spike with other security alerts or logs to identify potential patterns or related incidents.
+
+### False positive analysis
+
+- Business-related traffic surges: Regular spikes due to legitimate business activities, such as marketing campaigns or software updates, can trigger false positives. Users should analyze historical traffic patterns and create exceptions for known business events.
+- Scheduled data backups: Routine data backups can cause significant network traffic. Users can exclude these by identifying backup schedules and configuring the rule to ignore traffic during these times.
+- Software updates and patches: Large-scale updates from software vendors can lead to temporary traffic spikes. Users should maintain a list of update schedules and whitelist these events to prevent false alerts.
+- Internal network scans: Regular security scans or inventory checks within the organization may cause traffic spikes. Users should document these activities and adjust the rule to recognize them as non-threatening.
+- Cloud service synchronization: Synchronization activities with cloud services can generate high traffic volumes. Users should identify and exclude these regular sync patterns to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further data exfiltration or traffic flooding.
+- Conduct a thorough analysis of network logs to identify the source and destination of the traffic spike, focusing on any unauthorized or suspicious IP addresses.
+- Block identified malicious IP addresses and domains at the firewall and update intrusion prevention systems to prevent further access.
+- If data exfiltration is suspected, perform a data integrity check to assess any potential data loss or compromise.
+- Notify the incident response team to assess the situation and determine if further escalation is necessary, including potential involvement of law enforcement if data theft is confirmed.
+- Review and update network access controls and permissions to ensure only authorized users and devices have access to sensitive data and systems.
+- Implement enhanced monitoring and alerting for similar traffic patterns to improve early detection and response to future incidents."""
 
diff --git a/rules/ml/ml_linux_anomalous_network_port_activity.toml b/rules/ml/ml_linux_anomalous_network_port_activity.toml
index 140a8bc735f..c1a96071828 100644
--- a/rules/ml/ml_linux_anomalous_network_port_activity.toml
+++ b/rules/ml/ml_linux_anomalous_network_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -80,4 +80,40 @@ tags = [
     "Rule Type: Machine Learning",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Linux Network Port Activity
+
+In Linux environments, network ports facilitate communication between applications and services. Adversaries may exploit rarely used ports for covert command-and-control, persistence, or data exfiltration, bypassing standard monitoring. The 'Unusual Linux Network Port Activity' detection rule leverages machine learning to identify anomalies in port usage, flagging potential unauthorized access or threat actor activity by highlighting deviations from typical network behavior.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific unusual destination port and the associated source and destination IP addresses.
+- Check historical network logs to determine if the identified port has been used previously and assess the frequency and context of its usage.
+- Investigate the source IP address to determine if it is associated with known internal systems or if it is an external or unexpected source.
+- Analyze the destination IP address to verify if it is a legitimate endpoint within the network or an external entity that requires further scrutiny.
+- Correlate the unusual port activity with any recent changes or updates in the network environment that might explain the anomaly.
+- Examine any related process or application logs on the involved Linux systems to identify the application or service responsible for the network activity.
+- Consider reaching out to the system owner or administrator for additional context or to verify if the activity is expected or authorized.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when using non-standard ports for legitimate purposes. Users can create exceptions for known administrative tools and scripts that consistently use these ports.
+- Internal applications or services might use uncommon ports for inter-service communication. Identify these applications and whitelist their port usage to prevent unnecessary alerts.
+- Security tools and monitoring solutions sometimes scan or probe network ports as part of their operations. Recognize these tools and exclude their activities from the rule to avoid false positives.
+- Development and testing environments often experiment with various port configurations. Establish a separate monitoring profile for these environments to reduce noise in production alerts.
+- Custom or legacy applications may operate on non-standard ports due to historical configurations. Document these applications and adjust the rule to accommodate their expected behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of the system's network connections and terminate any suspicious or unauthorized connections.
+- Analyze system logs to identify any malicious processes or scripts that may have been executed, and remove or quarantine any identified threats.
+- Change all credentials associated with the affected system, especially if there is any indication of credential compromise.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Implement network segmentation to limit the exposure of critical systems to potential threats and reduce the risk of lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
diff --git a/rules/ml/ml_packetbeat_rare_server_domain.toml b/rules/ml/ml_packetbeat_rare_server_domain.toml
index 653e4cc3226..57fe994f004 100644
--- a/rules/ml/ml_packetbeat_rare_server_domain.toml
+++ b/rules/ml/ml_packetbeat_rare_server_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -83,4 +83,38 @@ rule_id = "17e68559-b274-4948-ad0b-f8415bb31126"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Network Destination Domain Name
+
+Machine learning models analyze network traffic to identify atypical domain names, which may indicate malicious activities like phishing or malware communication. Adversaries exploit uncommon domains for initial access or command-and-control. This detection rule leverages ML to flag these anomalies, aiding analysts in identifying potential threats early.
+
+### Possible investigation steps
+
+- Review the domain name flagged by the alert to determine if it is known for malicious activity or if it is newly registered, using threat intelligence sources and domain reputation services.
+- Analyze the network traffic associated with the domain to identify the source IP address and any related communication patterns, such as frequency and data volume.
+- Check the user or system that initiated the connection to the unusual domain for any recent changes or suspicious activities, such as software installations or configuration changes.
+- Investigate any related alerts or logs that might provide additional context, such as other unusual domain requests or failed login attempts, to identify potential patterns or correlations.
+- Assess the endpoint security logs for signs of malware or unauthorized access attempts that could be linked to the unusual domain activity.
+
+### False positive analysis
+
+- Legitimate software updates or downloads from uncommon domains can trigger false positives. Users should maintain a list of known software vendors and their associated domains to exclude these from alerts.
+- Internal testing or development environments may use non-standard domain names. Organizations should document these domains and configure exceptions to prevent unnecessary alerts.
+- Newly registered domains for legitimate business purposes might be flagged. Regularly update the list of approved domains as new business initiatives arise.
+- Third-party services or APIs that use unique domain names can cause false positives. Identify and whitelist these services to reduce noise in alerts.
+- Temporary or one-time use domains for events or campaigns should be monitored and excluded as needed to avoid repeated false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with the suspicious domain and potential spread of malware.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
+- Review and analyze network logs to identify any other systems that may have communicated with the unusual domain and apply similar isolation and scanning procedures to those systems.
+- Change passwords and credentials associated with the affected system and any potentially compromised accounts to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary.
+- Implement network-level blocking of the identified unusual domain across the organization to prevent future access attempts.
+- Update threat intelligence feeds and detection systems with indicators of compromise (IOCs) related to the unusual domain to enhance future detection capabilities."""
 
diff --git a/rules/ml/ml_rare_destination_country.toml b/rules/ml/ml_rare_destination_country.toml
index 3f293cd15f6..196e8ff5677 100644
--- a/rules/ml/ml_rare_destination_country.toml
+++ b/rules/ml/ml_rare_destination_country.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -79,4 +79,39 @@ rule_id = "35f86980-1fb1-4dff-b311-3be941549c8d"
 severity = "low"
 tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Traffic to Rare Destination Country
+
+Machine learning models analyze network logs to identify traffic to uncommon destination countries, which may indicate malicious activities like unauthorized access or data exfiltration. Adversaries exploit this by directing traffic to servers in atypical locations, often linked to command-and-control operations. The detection rule flags such anomalies, aiding in early threat identification and response.
+
+### Possible investigation steps
+
+- Review the network logs to identify the specific destination country flagged as rare and assess its historical presence in the network traffic.
+- Analyze the source IP addresses and user accounts associated with the flagged traffic to determine if they are legitimate or potentially compromised.
+- Investigate the nature of the traffic, such as the protocols and ports used, to identify any unusual patterns or connections to known malicious infrastructure.
+- Check for any recent phishing attempts or suspicious emails that may have led to the initiation of this traffic, focusing on links or attachments that could have been used to download malicious payloads.
+- Correlate the flagged traffic with any other security alerts or incidents to identify potential patterns or coordinated attacks involving the rare destination country.
+- Consult threat intelligence sources to determine if the destination country or specific IP addresses are associated with known threat actors or command-and-control servers.
+
+### False positive analysis
+
+- Legitimate business communications with partners or clients in rare destination countries may trigger alerts. Users should review and whitelist these known entities to prevent future false positives.
+- Routine software updates or patches from international vendors might be flagged. Identify and exclude these update servers from the detection rule to avoid unnecessary alerts.
+- Employees traveling abroad and accessing company resources can generate alerts. Implement a process to temporarily whitelist these destinations based on travel schedules.
+- Cloud services with global data centers may route traffic through uncommon countries. Verify the service's IP ranges and exclude them if they are part of normal operations.
+- Research or market expansion activities targeting new regions might cause alerts. Document and exclude these activities if they align with business objectives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough scan of the isolated system for malware or unauthorized software, focusing on identifying any command-and-control (C2) communication channels.
+- Block network traffic to and from the identified rare destination country at the firewall or proxy level to prevent further communication with potential malicious servers.
+- Review and analyze logs from the affected system and network devices to identify any additional indicators of compromise or related suspicious activities.
+- If malware is detected, remove it using appropriate tools and techniques, ensuring that all persistence mechanisms are eradicated.
+- Restore the affected system from a clean backup if necessary, ensuring that all security patches and updates are applied.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
diff --git a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
index cc7adf6f4f9..6b2036b68d4 100644
--- a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -85,6 +85,41 @@ tags = [
     "Tactic: Execution",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Windows Path Activity
+
+In corporate Windows environments, software is typically managed centrally, making execution from user or temporary directories uncommon. Adversaries exploit this by running malware from these atypical paths, bypassing standard security measures. The 'Unusual Windows Path Activity' detection rule leverages machine learning to identify such anomalies, flagging potential persistence or execution tactics used by attackers.
+
+### Possible investigation steps
+
+- Review the process name and path to determine if it is a known legitimate application or a suspicious executable.
+- Check the parent process to understand how the process was initiated and if it correlates with expected user behavior or known software installations.
+- Investigate the user account associated with the process execution to verify if the activity aligns with their typical usage patterns or if it appears anomalous.
+- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged by any threat intelligence sources.
+- Look into recent file modifications or creations in the directory from which the process was executed to identify any additional suspicious files or scripts.
+- Analyze network connections initiated by the process to detect any unusual or unauthorized external communications.
+
+### False positive analysis
+
+- Software updates or installations by IT staff can trigger alerts when executed from temporary directories. To manage this, create exceptions for known IT processes or scripts that are regularly used for legitimate software deployment.
+- Some legitimate applications may temporarily execute components from user directories during updates or initial setup. Identify these applications and add them to an allowlist to prevent unnecessary alerts.
+- Developers or power users might run scripts or applications from non-standard directories for testing purposes. Establish a policy to document and approve such activities, and configure exceptions for these known cases.
+- Automated tasks or scripts that are scheduled to run from user directories can be mistaken for malicious activity. Review and document these tasks, then configure the detection rule to exclude them from triggering alerts.
+- Security tools or monitoring software might execute diagnostic or remediation scripts from temporary paths. Verify these activities and add them to an exception list to avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware and unauthorized access.
+- Terminate any suspicious processes identified as running from atypical directories to halt malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files.
+- Review and restore any modified system processes or configurations to their original state to ensure system integrity.
+- Collect and preserve relevant logs and evidence for further analysis and potential escalation to the incident response team.
+- Escalate the incident to the security operations center (SOC) or incident response team if the threat persists or if there is evidence of broader compromise.
+- Implement application whitelisting to prevent unauthorized execution of software from user or temporary directories in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/persistence_ml_windows_anomalous_service.toml b/rules/ml/persistence_ml_windows_anomalous_service.toml
index 63938309c94..0d07a56d34f 100644
--- a/rules/ml/persistence_ml_windows_anomalous_service.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,6 +82,41 @@ tags = [
     "Tactic: Persistence",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Windows Service
+
+Windows services are crucial for running background processes and applications. Adversaries exploit this by creating or modifying services to maintain persistence or execute unauthorized actions. The 'Unusual Windows Service' detection rule leverages machine learning to identify atypical services, flagging potential threats by comparing against known service patterns, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the details of the detected unusual Windows service, including the service name, path, and any associated executables, to determine if it aligns with known legitimate services or appears suspicious.
+- Check the creation and modification timestamps of the service to identify if it was recently added or altered, which could indicate unauthorized activity.
+- Investigate the user account under which the service is running to assess if it has the necessary permissions and if the account has been compromised or misused.
+- Cross-reference the service with known threat intelligence databases to see if it matches any known malware or persistence mechanisms.
+- Analyze the network activity and connections associated with the service to identify any unusual or unauthorized communication patterns.
+- Examine the host's event logs for any related entries that could provide additional context or evidence of malicious activity, such as failed login attempts or privilege escalation events.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create new services that are flagged as unusual. Users should verify the source and purpose of the service before excluding it.
+- Custom in-house applications often run unique services that can trigger alerts. Document these services and create exceptions to prevent future false positives.
+- IT administrative tools might install services for management purposes. Confirm these tools are authorized and add them to an exception list if they are frequently flagged.
+- Temporary services used for troubleshooting or testing can be mistaken for threats. Ensure these are removed after use or excluded if they are part of regular operations.
+- Scheduled tasks that create services for specific operations might be flagged. Review these tasks and exclude them if they are part of normal business processes.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration by the unauthorized service.
+- Terminate the unusual Windows service identified by the alert to stop any ongoing malicious activity.
+- Conduct a thorough analysis of the service's executable and associated files to determine if they are malicious. Use endpoint detection and response (EDR) tools to assist in this analysis.
+- Remove any malicious files or executables associated with the service from the system to ensure complete eradication of the threat.
+- Restore the affected system from a known good backup if the service has caused significant changes or damage to the system.
+- Monitor the system and network for any signs of re-infection or similar unusual service activity, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
index 6d718fc767f..6ca5a51357e 100644
--- a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
+++ b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 75
@@ -84,6 +84,41 @@ tags = [
     "Tactic: Privilege Escalation",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Sudo Activity
+
+Sudo is a command in Unix-like systems that allows permitted users to execute commands as a superuser, providing necessary privileges for administrative tasks. Adversaries may exploit this by using compromised credentials to gain elevated access, potentially bypassing security controls. The 'Unusual Sudo Activity' detection rule leverages machine learning to identify deviations from normal sudo usage patterns, flagging potential privilege escalation attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the user account associated with the unusual sudo activity to determine if it aligns with known administrative roles or if it is typically associated with non-privileged tasks.
+- Check the timestamp of the sudo activity to see if it coincides with any known maintenance windows or reported troubleshooting activities.
+- Analyze the command executed with sudo to assess whether it is a common administrative command or if it appears suspicious or unnecessary for the user's role.
+- Investigate the source IP address or hostname from which the sudo command was executed to verify if it is a recognized and authorized device.
+- Look into recent login activity for the user account to identify any unusual access patterns or locations that could indicate compromised credentials.
+- Cross-reference the alert with any other security events or logs around the same time to identify potential indicators of compromise or related malicious activity.
+
+### False positive analysis
+
+- Administrative troubleshooting activities can trigger false positives. Regularly review and document legitimate administrative tasks that require sudo access to differentiate them from potential threats.
+- Developers or IT staff performing routine maintenance may cause alerts. Create exceptions for known maintenance windows or specific user accounts that frequently require elevated privileges.
+- Automated scripts or scheduled tasks using sudo might be flagged. Identify and whitelist these scripts or tasks if they are verified as safe and necessary for operations.
+- New employees or role changes can lead to unusual sudo activity. Update user roles and permissions promptly to reflect their current responsibilities and reduce unnecessary alerts.
+- Temporary access granted for specific projects can appear suspicious. Ensure that temporary access is well-documented and set to expire automatically to prevent lingering false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Revoke or reset the compromised credentials to prevent further misuse and ensure that the affected user account is secured.
+- Conduct a thorough review of recent sudo logs and system activity to identify any unauthorized changes or actions taken by the adversary.
+- Restore any altered or deleted files from backups, ensuring that the system is returned to its last known good state.
+- Apply any necessary security patches or updates to the affected system to close vulnerabilities that may have been exploited.
+- Enhance monitoring and logging for sudo activities across all systems to detect similar anomalies in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
index e996d8761c8..13ce443332b 100644
--- a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
+++ b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,6 +82,41 @@ tags = [
     "Tactic: Privilege Escalation",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Windows User Privilege Elevation Activity
+
+In Windows environments, privilege elevation tools like 'runas' allow users to execute programs with different user credentials, typically used by administrators. Adversaries exploit this to gain elevated access, often indicating account compromise. The detection rule leverages machine learning to identify atypical usage patterns of such tools, flagging potential unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the specific user account involved in the alert to determine if it is a regular user or an administrator, as privilege elevation is more common among administrators.
+- Check the timestamp of the alert to correlate with any known scheduled tasks or administrative activities that might explain the use of privilege elevation tools.
+- Investigate the source IP address and device from which the privilege elevation attempt was made to verify if it aligns with the user's typical access patterns.
+- Examine recent login activity for the user account to identify any unusual or unauthorized access attempts that could indicate account compromise.
+- Look for any other security alerts or logs related to the same user or device around the time of the alert to gather additional context on potential malicious activity.
+- Assess whether there have been any recent changes to user permissions or group memberships that could have facilitated the privilege elevation.
+
+### False positive analysis
+
+- Regular administrative tasks by domain or network administrators can trigger false positives. To manage this, create exceptions for known administrator accounts frequently using the runas command.
+- Scheduled tasks or scripts that require privilege elevation might be flagged. Identify and exclude these tasks from monitoring if they are verified as safe and necessary for operations.
+- Software updates or installations that require elevated privileges can also cause alerts. Maintain a list of approved software and update processes to exclude them from triggering the rule.
+- Training or testing environments where privilege elevation is part of routine operations may generate false positives. Exclude these environments from the rule's scope to prevent unnecessary alerts.
+- Third-party applications that use privilege elevation for legitimate purposes should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Revoke any elevated privileges granted to the compromised account and reset its password to prevent further misuse.
+- Conduct a thorough review of recent activity logs for the affected account to identify any unauthorized actions or data access.
+- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation.
+- Restore any altered or compromised system configurations to their original state using backups or system snapshots.
+- Implement additional monitoring on the affected system and account to detect any further suspicious activity.
+- Review and update access controls and privilege management policies to minimize the risk of similar incidents in the future."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
diff --git a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
index e3878144a51..527bb6093cb 100644
--- a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
+++ b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/10"
 
 [rule]
 anomaly_threshold = 50
@@ -85,6 +85,41 @@ tags = [
     "Tactic: Resource Development",
 ]
 type = "machine_learning"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Anomalous Linux Compiler Activity
+
+Compilers transform source code into executable programs, a crucial step in software development. In Linux environments, unexpected compiler use by atypical users may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit this by deploying malicious code or exploits. The detection rule leverages machine learning to identify unusual compiler activity, flagging potential threats by analyzing user behavior patterns and deviations from normal operations.
+
+### Possible investigation steps
+
+- Review the user account associated with the anomalous compiler activity to determine if the user typically engages in software development or has a history of using compilers.
+- Check the specific compiler and version used in the activity to identify if it is a known or legitimate tool within the organization.
+- Analyze the source and destination of the compiler activity, including the IP addresses and hostnames, to identify any unusual or unauthorized access patterns.
+- Investigate recent changes or deployments on the system where the compiler activity was detected to identify any unauthorized software installations or modifications.
+- Examine system logs and audit trails for any signs of privilege escalation attempts or other suspicious activities around the time of the compiler usage.
+- Cross-reference the detected activity with known threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise.
+
+### False positive analysis
+
+- Development environments where multiple users compile code can trigger false positives. Regularly update the list of authorized users who are expected to use compilers to prevent unnecessary alerts.
+- Automated build systems or continuous integration pipelines may be flagged. Exclude these systems from monitoring or adjust the rule to recognize their activity as normal.
+- Educational or training sessions involving compilers might cause alerts. Temporarily adjust the rule settings or add exceptions for the duration of the training.
+- Users compiling open-source software for personal use can be mistaken for threats. Implement a process for users to notify the security team of legitimate compiler use to preemptively adjust monitoring rules.
+- System administrators performing maintenance or updates that involve compiling software may trigger alerts. Maintain a log of scheduled maintenance activities and adjust the rule to account for these periods.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement or further exploitation.
+- Terminate any suspicious processes associated with the anomalous compiler activity to halt any ongoing malicious operations.
+- Conduct a thorough review of recent user activity and permissions to identify unauthorized access or privilege escalation attempts.
+- Remove any unauthorized or malicious software identified during the investigation to prevent further compromise.
+- Restore the system from a known good backup if malicious code execution is confirmed, ensuring that the backup is free from compromise.
+- Implement stricter access controls and monitoring for compiler usage, ensuring only authorized users can execute compilers.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 [[rule.threat.technique]]
diff --git a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
index d30f431fda5..4a6ac7d9ae5 100644
--- a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
+++ b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,41 @@ query = '''
         flow_terminated or timeout or Reject or network_flow)
     and destination.port:23
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Accepted Default Telnet Port Connection
+
+Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization.
+- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes.
+- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack.
+- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access.
+- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers.
+- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access.
+- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts.
+
+### False positive analysis
+
+- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems.
+- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts.
+- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise.
+- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities.
+- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred.
+- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges.
+- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet.
+- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_cobalt_strike_beacon.toml b/rules/network/command_and_control_cobalt_strike_beacon.toml
index be14096630a..a893732e175 100644
--- a/rules/network/command_and_control_cobalt_strike_beacon.toml
+++ b/rules/network/command_and_control_cobalt_strike_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -22,7 +22,43 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Cobalt Strike Command and Control Beacon"
-note = """## Threat intel
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Cobalt Strike Command and Control Beacon
+
+Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using common protocols like HTTP or TLS. The detection rule identifies suspicious network patterns, such as specific domain naming conventions, indicative of Cobalt Strike's C2 activity, helping analysts pinpoint potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific domain that triggered the rule, focusing on the pattern [a-z]{3}.stage.[0-9]{8}\\..* to determine if it matches known malicious domains.
+- Analyze the network traffic logs associated with the alert, specifically looking at events categorized under network or network_traffic with types tls or http, to gather more context about the communication.
+- Investigate the source IP address and destination domain involved in the alert to determine if they have been associated with previous malicious activities or are listed in threat intelligence databases.
+- Examine the timeline of the network activity to identify any patterns or anomalies that could indicate a larger campaign or coordinated attack.
+- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader compromise.
+- Assess the affected endpoint for any signs of compromise, such as unusual processes or connections, to determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Legitimate software updates or patch management systems may use similar domain naming conventions. Review and whitelist known update servers to prevent false alerts.
+- Internal development or testing environments might mimic Cobalt Strike's domain patterns for legitimate purposes. Identify and exclude these environments from the rule.
+- Automated scripts or tools that generate network traffic with similar domain structures can trigger false positives. Monitor and document these tools, then create exceptions for their activity.
+- Some content delivery networks (CDNs) might use domain patterns that match the rule's criteria. Verify and exclude trusted CDNs to reduce unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness.
+
+### Response and remediation
+
+- Isolate the affected systems immediately to prevent further communication with the Cobalt Strike C2 server. This can be done by disconnecting the network or using network segmentation techniques.
+- Conduct a thorough forensic analysis of the compromised systems to identify the extent of the breach and any additional payloads or backdoors that may have been installed.
+- Remove any identified Cobalt Strike beacons or related malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools.
+- Change all credentials and access tokens that may have been exposed or used on the compromised systems to prevent unauthorized access.
+- Monitor network traffic for any signs of re-infection or communication attempts with known Cobalt Strike C2 domains, using updated threat intelligence feeds.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised.
+- Implement network-level controls, such as blocking known malicious domains and IP addresses associated with Cobalt Strike, to prevent future attacks.
+
+## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
index 6086b36e1b0..d36c34d32d5 100644
--- a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
+++ b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/05"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,42 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Default Cobalt Strike Team Server Certificate"
-note = """## Threat intel
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Default Cobalt Strike Team Server Certificate
+
+Cobalt Strike is a tool used for simulating advanced cyber threats, often employed by security teams to test defenses. However, adversaries can exploit its default server certificate to establish covert command and control channels. The detection rule identifies this misuse by monitoring network traffic for specific cryptographic hashes associated with the default certificate, flagging potential unauthorized Cobalt Strike activity.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify any connections associated with the specific cryptographic hashes: MD5 (950098276A495286EB2A2556FBAB6D83), SHA1 (6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C), or SHA256 (87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C).
+- Identify the source and destination IP addresses involved in the flagged network traffic to determine the potential origin and target of the Cobalt Strike activity.
+- Correlate the identified IP addresses with known assets in the network to assess if any internal systems are potentially compromised.
+- Check for any other suspicious or anomalous network activities around the same time as the alert to identify potential lateral movement or additional command and control channels.
+- Investigate any associated processes or user accounts on the involved systems to determine if there are signs of compromise or unauthorized access.
+- Review historical data to see if there have been previous alerts or similar activities involving the same cryptographic hashes or IP addresses, which might indicate a persistent threat.
+
+### False positive analysis
+
+- Legitimate security testing activities by internal teams using Cobalt Strike may trigger the rule. Coordinate with security teams to whitelist known testing IP addresses or certificate hashes.
+- Some commercial penetration testing services may use Cobalt Strike with default certificates. Verify the legitimacy of such services and exclude their traffic from detection by adding their certificate hashes to an exception list.
+- Network appliances or security tools that simulate adversary behavior for training purposes might use similar certificates. Identify these tools and configure exceptions for their specific network traffic patterns.
+- In environments where Cobalt Strike is used for authorized red team exercises, ensure that the default certificate is replaced with a custom one to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further communication with the potential Cobalt Strike server.
+- Conduct a thorough forensic analysis of the isolated system to identify any malicious payloads or additional indicators of compromise.
+- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent unauthorized access.
+- Update and patch all systems to the latest security standards to mitigate vulnerabilities that could be exploited by similar threats.
+- Implement network segmentation to limit the lateral movement of threats within the network.
+- Enhance monitoring and logging to capture detailed network traffic and endpoint activity, focusing on the identified cryptographic hashes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and coordination with external threat intelligence sources if necessary.
+
+## Threat intel
 
 While Cobalt Strike is intended to be used for penetration tests and IR training, it is frequently used by actual threat actors (TA) such as APT19, APT29, APT32, APT41, FIN6, DarkHydrus, CopyKittens, Cobalt Group, Leviathan, and many other unnamed criminal TAs. This rule uses high-confidence atomic indicators, so alerts should be investigated rapidly."""
 references = [
diff --git a/rules/network/command_and_control_download_rar_powershell_from_internet.toml b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
index 353a1460eec..77756541be6 100644
--- a/rules/network/command_and_control_download_rar_powershell_from_internet.toml
+++ b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,43 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*",
 language = "kuery"
 license = "Elastic License v2"
 name = "Roshal Archive (RAR) or PowerShell File Downloaded from the Internet"
-note = """## Threat intel
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet
+
+RAR files and PowerShell scripts are powerful tools in IT environments, used for data compression and task automation, respectively. However, adversaries exploit these for malicious purposes, such as downloading encrypted tools to evade detection. The detection rule identifies unusual downloads of these files from external sources, flagging potential threats by monitoring network traffic and excluding trusted internal IP ranges.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the internal host that initiated the download, focusing on the source IP addresses within the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
+- Examine the destination IP address of the download to determine if it is associated with known malicious activity or if it is an unusual external IP not typically accessed by the organization.
+- Analyze the downloaded file's URL extension or path to confirm if it matches .ps1 or .rar, and assess whether this is expected behavior for the identified host or user.
+- Check the internal host's recent activity for any signs of lateral movement or further suspicious downloads, which could indicate a broader compromise.
+- Investigate the user account associated with the internal host to verify if the download aligns with their typical usage patterns and permissions.
+- Utilize threat intelligence sources to gather additional context on the downloaded file or the external IP address to assess potential risks or known threats.
+
+### False positive analysis
+
+- Internal software updates or legitimate administrative scripts may trigger the rule. To manage this, create exceptions for known internal update servers or trusted administrative IP addresses.
+- Automated backup processes that use RAR files for compression can be mistaken for threats. Exclude IP addresses or domains associated with these backup services from the rule.
+- Development environments often download scripts for testing purposes. Identify and exclude IP ranges or specific hosts associated with development activities to prevent false positives.
+- Security tools that download threat intelligence or updates in RAR format might be flagged. Whitelist the IP addresses of these security tools to avoid unnecessary alerts.
+- Regularly review and update the list of trusted internal IP ranges to ensure that legitimate traffic is not incorrectly flagged as suspicious.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further lateral movement or data exfiltration.
+- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious files or scripts.
+- Review and analyze network logs to identify any other potentially compromised systems or unusual outbound connections that may indicate further compromise.
+- Reset credentials and access tokens for the affected host and any other systems that may have been accessed using the compromised host.
+- Restore the affected system from a known good backup if malware removal is not feasible or if the system's integrity is in question.
+- Implement network segmentation to limit the ability of threats to move laterally within the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts.
+
+## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_halfbaked_beacon.toml b/rules/network/command_and_control_halfbaked_beacon.toml
index db956efc006..596e6fc33f4 100644
--- a/rules/network/command_and_control_halfbaked_beacon.toml
+++ b/rules/network/command_and_control_halfbaked_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Halfbaked Command and Control Beacon"
-note = """## Threat intel
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Halfbaked Command and Control Beacon
+
+Halfbaked malware exploits common network protocols to maintain persistence and facilitate command and control (C2) operations within compromised networks. Adversaries leverage HTTP and TLS protocols to disguise malicious traffic as legitimate, often targeting specific ports like 53, 80, 8080, and 443. The detection rule identifies suspicious network patterns, such as unusual URL structures and specific transport protocols, to flag potential C2 beaconing activities.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify any connections to IP addresses matching the pattern specified in the query (e.g., http://[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/cd) and determine if these IPs are known or suspicious.
+- Analyze the destination ports (53, 80, 8080, 443) used in the flagged traffic to assess if they align with typical usage patterns for the affected systems or if they indicate potential misuse.
+- Examine the HTTP and TLS traffic details to identify any unusual URL structures or anomalies in the network.protocol field that could suggest malicious activity.
+- Correlate the detected network activity with endpoint logs to identify any associated processes or applications that may have initiated the suspicious traffic.
+- Investigate any related alerts or historical data for patterns of similar activity, which could indicate a persistent threat or ongoing compromise within the network.
+
+### False positive analysis
+
+- Legitimate software updates or patch management systems may use similar URL structures and ports, leading to false positives. Users can create exceptions for known update servers by whitelisting their IP addresses or domain names.
+- Internal web applications or services that use non-standard ports like 8080 for HTTP traffic might trigger the rule. Identify these applications and exclude their traffic from the rule by specifying their IP addresses or domain names.
+- Network monitoring tools or security appliances that perform regular scans or health checks over HTTP or TLS might mimic the detected patterns. Exclude these tools by adding their IP addresses to an exception list.
+- Content delivery networks (CDNs) often use IP-based URLs for load balancing and might be mistaken for malicious activity. Verify the legitimacy of the CDN traffic and exclude it by whitelisting the associated IP ranges.
+- Automated scripts or bots within the network that access external resources using IP-based URLs could trigger alerts. Review these scripts and, if deemed safe, exclude their traffic by specifying their source IP addresses.
+
+### Response and remediation
+
+- Isolate the affected systems from the network immediately to prevent further communication with the command and control server.
+- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove the Halfbaked malware.
+- Analyze network traffic logs to identify other potentially compromised systems by looking for similar suspicious network patterns and URL structures.
+- Block the identified malicious IP addresses and domains at the network perimeter to prevent further communication attempts.
+- Apply security patches and updates to all systems and applications to close vulnerabilities exploited by the malware.
+- Restore affected systems from clean backups, ensuring that the backups are free from any signs of compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach.
+
+## Threat intel
 
 This activity has been observed in FIN7 campaigns."""
 references = [
diff --git a/rules/network/command_and_control_nat_traversal_port_activity.toml b/rules/network/command_and_control_nat_traversal_port_activity.toml
index f61786952a2..2ef50d5c32a 100644
--- a/rules/network/command_and_control_nat_traversal_port_activity.toml
+++ b/rules/network/command_and_control_nat_traversal_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,41 @@ type = "query"
 query = '''
 (event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and network.transport:udp and destination.port:4500
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 IPSEC NAT Traversal Port Activity
+
+IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC packets in UDP, typically using port 4500. While essential for legitimate encrypted traffic, adversaries exploit this to mask malicious activities, bypassing network defenses. The detection rule identifies unusual UDP traffic on port 4500, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the source and destination IP addresses associated with the UDP traffic on port 4500 to determine if they are known or expected within your network environment.
+- Analyze the volume and frequency of the detected traffic to assess whether it aligns with typical IPSEC NAT Traversal usage or if it appears anomalous.
+- Check for any associated network traffic events in the same timeframe that might indicate a pattern of suspicious activity, such as unusual data transfer volumes or connections to known malicious IP addresses.
+- Investigate the endpoint or device generating the traffic to verify if it is authorized to use IPSEC NAT Traversal and if it has any history of security incidents or vulnerabilities.
+- Correlate the detected activity with any recent changes in network configurations or security policies that might explain the traffic pattern.
+- Consult threat intelligence sources to determine if the destination IP address or domain has been associated with known threat actors or command and control infrastructure.
+
+### False positive analysis
+
+- Legitimate VPN traffic using IPSEC NAT Traversal can trigger alerts. Regularly review and whitelist known IP addresses or subnets associated with authorized VPN connections to reduce false positives.
+- Network devices or services that rely on IPSEC for secure communication may generate expected traffic on port 4500. Identify and document these devices, then create exceptions in the detection rule to prevent unnecessary alerts.
+- Automated backup or synchronization services that use IPSEC for secure data transfer might be flagged. Monitor these services and exclude their traffic patterns if they are verified as non-threatening.
+- Some enterprise applications may use IPSEC NAT Traversal for secure communication. Conduct an inventory of such applications and adjust the rule to exclude their traffic after confirming their legitimacy.
+- Regularly update the list of known safe IP addresses and services to ensure that new legitimate sources of IPSEC NAT Traversal traffic are promptly excluded from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further potential malicious activity and lateral movement.
+- Conduct a thorough analysis of the isolated system to identify any signs of compromise, such as unauthorized access or data exfiltration, focusing on logs and network traffic related to UDP port 4500.
+- Block all suspicious IP addresses associated with the detected traffic on port 4500 at the network perimeter to prevent further communication with potential threat actors.
+- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to ensure they effectively block unauthorized IPSEC NAT Traversal traffic, particularly on UDP port 4500.
+- Restore the affected system from a known good backup if any signs of compromise are confirmed, ensuring that all security patches and updates are applied before reconnecting to the network.
+- 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 enhanced monitoring and logging for UDP traffic on port 4500 to detect and respond to any future suspicious activity promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_port_26_activity.toml b/rules/network/command_and_control_port_26_activity.toml
index 2a01401278b..efb432dd0ca 100644
--- a/rules/network/command_and_control_port_26_activity.toml
+++ b/rules/network/command_and_control_port_26_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,40 @@ type = "query"
 query = '''
 (event.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:26
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SMTP on Port 26/TCP
+
+SMTP, typically operating on port 25, is crucial for email transmission. However, port 26 is often used to avoid conflicts or restrictions on port 25. Adversaries exploit this by using port 26 for covert command and control, as seen with the BadPatch malware. The detection rule identifies suspicious SMTP activity on port 26 by analyzing network traffic patterns, helping to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify any unusual patterns or anomalies associated with TCP port 26, focusing on the event.dataset fields such as network_traffic.flow or zeek.smtp.
+- Analyze the source and destination IP addresses involved in the alert to determine if they are known or associated with any previous suspicious activities.
+- Check for any additional alerts or logs related to the same source or destination IP addresses to identify potential patterns or repeated attempts of communication on port 26.
+- Investigate the context of the communication by examining the payload data, if available, to identify any indicators of compromise or malicious content.
+- Correlate the findings with threat intelligence sources to determine if the IP addresses or domains are associated with known threat actors or malware, such as BadPatch.
+- Assess the risk and impact on the affected systems by determining if any sensitive data or critical systems are involved in the communication on port 26.
+
+### False positive analysis
+
+- Legitimate mail transfer agents may use port 26 to avoid conflicts with port 25. Identify these agents and create exceptions in the detection rule to prevent unnecessary alerts.
+- Some network configurations might reroute SMTP traffic to port 26 for load balancing or security reasons. Verify these configurations and whitelist known IP addresses or domains to reduce false positives.
+- Internal testing or development environments might use port 26 for non-malicious purposes. Document these environments and exclude their traffic from triggering alerts.
+- Certain email service providers may use port 26 as an alternative to port 25. Confirm these providers and adjust the rule to recognize their traffic as benign.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further command and control communication via port 26.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove the BadPatch malware or any other malicious software.
+- Review and analyze network logs to identify any other systems that may have communicated with the same command and control server, and isolate those systems as well.
+- Change all passwords and credentials that may have been compromised or accessed by the affected system to prevent unauthorized access.
+- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation by similar threats.
+- Monitor network traffic for any further suspicious activity on port 26 and other non-standard ports, adjusting firewall rules to block unauthorized SMTP traffic.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to ensure comprehensive threat eradication."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
index e9e59ab3aeb..b18ea2517f5 100644
--- a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
+++ b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,40 @@ query = '''
     192.168.0.0/16
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 RDP (Remote Desktop Protocol) from the Internet
+
+RDP allows administrators to remotely manage systems, but exposing it to the internet poses security risks. Adversaries exploit RDP for unauthorized access, often using it as an entry point for attacks. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from external IPs, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address flagged in the alert to determine if it is known or associated with any previous malicious activity. Check threat intelligence sources for any reported malicious behavior.
+- Analyze the destination IP address to confirm it belongs to your internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and identify the specific system targeted by the RDP connection.
+- Examine network logs for any unusual or unexpected RDP traffic patterns from the source IP, such as repeated connection attempts or connections at odd hours, which may indicate brute force attempts or unauthorized access.
+- Check for any recent changes or updates to firewall rules or security policies that might have inadvertently exposed RDP to the internet.
+- Investigate the user accounts involved in the RDP session to ensure they are legitimate and have not been compromised. Look for any signs of unauthorized access or privilege escalation.
+- Correlate the RDP traffic with other security events or alerts to identify any potential lateral movement or further malicious activity within the network.
+
+### False positive analysis
+
+- Internal testing or maintenance activities may trigger the rule if RDP is temporarily exposed to the internet. To manage this, create exceptions for known internal IP addresses or scheduled maintenance windows.
+- Legitimate third-party vendors or partners accessing systems via RDP for support purposes can be mistaken for threats. Establish a list of trusted external IP addresses and exclude them from the rule.
+- Misconfigured network devices or security tools might inadvertently expose RDP to the internet, leading to false positives. Regularly audit network configurations and update the rule to exclude known benign sources.
+- Cloud-based services or remote work solutions that use RDP over the internet can be flagged. Identify and whitelist these services' IP ranges to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately block the external IP address identified in the alert from accessing the network to prevent further unauthorized RDP connections.
+- Isolate the affected system from the network to contain any potential compromise and prevent lateral movement by the threat actor.
+- Conduct a thorough review of the affected system for signs of compromise, such as unauthorized user accounts, changes in system configurations, or the presence of malware.
+- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
+- Apply security patches and updates to the affected system and any other systems with RDP enabled to mitigate known vulnerabilities.
+- Implement network segmentation to restrict RDP access to only trusted internal IP addresses and consider using a VPN for secure remote access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
index db915e0a059..f54e7110307 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,40 @@ query = '''
     192.168.0.0/16
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 VNC (Virtual Network Computing) from the Internet
+
+VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC for initial access or as a backdoor. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out trusted IP ranges, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address of the alert to determine if it is from an untrusted or suspicious location, as the rule filters out known trusted IP ranges.
+- Check the destination IP address to confirm it belongs to an internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and verify if the system is authorized to receive VNC traffic.
+- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or repeated access attempts that could indicate malicious activity.
+- Investigate the context of the event by correlating it with other security alerts or logs to determine if there are signs of a broader attack or compromise.
+- Assess the risk and impact of the potential threat by evaluating the criticality of the affected system and any sensitive data it may contain.
+
+### False positive analysis
+
+- Internal testing or maintenance activities may trigger the rule if VNC is used for legitimate purposes within a controlled environment. To manage this, create exceptions for known internal IP addresses that frequently use VNC for authorized tasks.
+- Automated systems or scripts that utilize VNC for routine operations might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent unnecessary alerts.
+- Remote workers using VPNs that route traffic through public IPs could be mistakenly identified as threats. Ensure that VPN IP ranges are included in the trusted IP list to avoid false positives.
+- Misconfigured network devices that inadvertently expose VNC ports to the Internet can cause alerts. Regularly audit network configurations to ensure VNC ports are not exposed and adjust the rule to exclude known safe configurations.
+- Third-party service providers accessing systems via VNC for support purposes might be flagged. Establish a list of trusted IPs for these providers and update the rule to exclude them from detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active VNC sessions originating from untrusted IP addresses to cut off potential attacker access.
+- Conduct a thorough review of system logs and network traffic to identify any unauthorized changes or data access that may have occurred during the VNC session.
+- Reset credentials for any accounts that were accessed or could have been compromised during the unauthorized VNC session.
+- Apply security patches and updates to the VNC software and any other potentially vulnerable applications on the affected system.
+- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the Internet.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
index f7f629214dd..b090c72300a 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,41 @@ query = '''
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 VNC (Virtual Network Computing) to the Internet
+
+VNC is a tool that allows remote control of computers, often used by administrators for maintenance. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC to establish backdoors or gain initial access. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out internal IP addresses, flagging potential threats when VNC is accessed from external networks.
+
+### Possible investigation steps
+
+- Review the source IP address to determine if it belongs to a known internal asset or user, and verify if the access was authorized.
+- Check the destination IP address to confirm if it is an external address and investigate its reputation or any known associations with malicious activity.
+- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or volumes of VNC traffic.
+- Correlate the VNC traffic event with other security events or logs to identify any related suspicious activities or anomalies.
+- Investigate the user account associated with the VNC session to ensure it has not been compromised or misused.
+- Assess the system or application logs on the destination machine for any signs of unauthorized access or changes during the time of the VNC connection.
+
+### False positive analysis
+
+- Internal maintenance activities may trigger the rule if VNC is used for legitimate remote administration. To manage this, create exceptions for known internal IP addresses that frequently use VNC for maintenance.
+- Automated scripts or tools that use VNC for legitimate purposes might be flagged. Identify these tools and whitelist their IP addresses to prevent unnecessary alerts.
+- Testing environments that simulate external access to VNC for security assessments can cause false positives. Exclude IP ranges associated with these environments to avoid confusion.
+- Cloud-based services that use VNC for remote management might be misidentified as threats. Verify these services and add their IP addresses to an exception list if they are trusted.
+- Temporary remote access setups for troubleshooting or support can be mistaken for unauthorized access. Document these instances and apply temporary exceptions to reduce false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active VNC sessions that are identified as originating from external networks to cut off potential attacker access.
+- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data transfer that may have occurred during the VNC exposure.
+- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials.
+- Apply necessary patches and updates to the VNC software and any other vulnerable applications on the affected system to mitigate known vulnerabilities.
+- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the internet.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_network_sweep_detected.toml b/rules/network/discovery_potential_network_sweep_detected.toml
index 1f4a3572f07..7a820bdef70 100644
--- a/rules/network/discovery_potential_network_sweep_detected.toml
+++ b/rules/network/discovery_potential_network_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,47 @@ query = '''
 destination.port : (21 or 22 or 23 or 25 or 139 or 445 or 3389 or 5985 or 5986) and
 source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Network Sweep Detected
+
+Network sweeps are reconnaissance techniques where attackers scan networks to identify active hosts and services, often targeting common ports. This activity helps adversaries map out network vulnerabilities for future exploitation. The detection rule identifies such sweeps by monitoring connection attempts from a single source to multiple destinations on key ports, flagging potential reconnaissance activities for further investigation.
+
+### Possible investigation steps
+
+- Review the source IP address to determine if it belongs to a known or trusted entity within the network, focusing on the private IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
+- Analyze the destination IP addresses to identify any patterns or commonalities, such as specific subnets or devices, that could indicate targeted reconnaissance.
+- Check historical logs for previous connection attempts from the same source IP to see if there is a pattern of repeated scanning behavior or if this is an isolated incident.
+- Investigate the specific ports targeted (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) to determine if they are associated with critical services or known vulnerabilities within the network.
+- Correlate the detected activity with any recent changes or incidents in the network environment that might explain the behavior, such as new device deployments or configuration changes.
+- Consult threat intelligence sources to determine if the source IP or similar scanning patterns have been associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Internal network scans by IT teams can trigger the rule. Regularly scheduled scans for security assessments should be documented and their source IPs added to an exception list to prevent false alerts.
+- Automated monitoring tools that check network health might cause false positives. Identify these tools and exclude their IP addresses from the rule to avoid unnecessary alerts.
+- Load balancers or network devices that perform health checks across multiple hosts can be mistaken for network sweeps. Exclude these devices by adding their IPs to a whitelist.
+- Development or testing environments where multiple connections are made for legitimate purposes can trigger the rule. Ensure these environments are recognized and their IP ranges are excluded from monitoring.
+- Misconfigured devices that repeatedly attempt to connect to multiple hosts can appear as network sweeps. Investigate and correct the configuration, then exclude these devices if necessary.
+
+### Response and remediation
+
+- Isolate the source IP: Immediately isolate the source IP address identified in the alert from the network to prevent further reconnaissance or potential exploitation of identified vulnerabilities.
+
+- Block suspicious ports: Implement firewall rules to block incoming and outgoing traffic on the commonly targeted ports (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) from the source IP to mitigate further scanning attempts.
+
+- Conduct a network-wide scan: Perform a comprehensive scan of the network to identify any unauthorized access or changes that may have occurred as a result of the network sweep.
+
+- Review and update access controls: Ensure that access controls and permissions are appropriately configured to limit exposure of critical services and sensitive data.
+
+- Monitor for recurrence: Set up enhanced monitoring and alerting for any future connection attempts from the source IP or similar patterns of network sweep activity.
+
+- Escalate to security operations: Notify the security operations team to conduct a deeper investigation into the source of the network sweep and assess any potential threats or breaches.
+
+- Document and report: Record all findings, actions taken, and lessons learned in an incident report to inform future response strategies and improve network defenses."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_port_scan_detected.toml b/rules/network/discovery_potential_port_scan_detected.toml
index 718b4ef6da1..d7027d60f63 100644
--- a/rules/network/discovery_potential_port_scan_detected.toml
+++ b/rules/network/discovery_potential_port_scan_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,41 @@ type = "threshold"
 query = '''
 destination.port : * and event.action : "network_flow" and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Network Scan Detected
+
+Network scanning is a technique used to identify open ports and services on a network, often exploited by attackers to find vulnerabilities. Adversaries may use this method to map out a network's structure and identify weak points for further exploitation. The detection rule identifies suspicious activity by monitoring for multiple connection attempts from a single source to numerous destination ports, indicating a potential scan. This helps in early detection and mitigation of reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the source IP address involved in the alert to determine if it belongs to a known or trusted entity within the organization. Check if the IP falls within the specified ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
+- Analyze the network flow logs to identify the specific destination ports that were targeted by the source IP. Determine if these ports are associated with critical services or known vulnerabilities.
+- Correlate the detected activity with any recent changes or updates in the network infrastructure that might explain the scanning behavior, such as new devices or services being deployed.
+- Investigate if there are any other alerts or logs indicating similar scanning activities from the same source IP or other IPs within the same subnet, which might suggest a coordinated scanning effort.
+- Check for any historical data or past incidents involving the source IP to assess if this behavior is part of a recurring pattern or a new anomaly.
+- Consult with network administrators to verify if the detected activity aligns with any scheduled network assessments or security tests that might have been conducted without prior notification.
+
+### False positive analysis
+
+- Internal network scanning tools used for legitimate security assessments can trigger this rule. To manage this, create exceptions for known IP addresses of authorized scanning tools.
+- Automated network monitoring systems that check service availability across multiple ports may be flagged. Exclude these systems by identifying their IP addresses and adding them to an exception list.
+- Load balancers and network devices that perform health checks on various services might cause false positives. Identify these devices and configure the rule to ignore their IP addresses.
+- Development and testing environments where frequent port scanning is part of routine operations can be mistakenly flagged. Implement exceptions for these environments by specifying their IP ranges.
+- Regularly scheduled vulnerability assessments conducted by internal security teams can appear as network scans. Document these activities and exclude the associated IPs from triggering the rule.
+
+### Response and remediation
+
+- Isolate the affected host: Immediately disconnect the source IP from the network to prevent further scanning or potential exploitation of identified vulnerabilities.
+- Conduct a thorough investigation: Analyze the source IP's activity logs to determine if any unauthorized access or data exfiltration has occurred. This will help assess the extent of the threat.
+- Update firewall rules: Implement stricter access controls to limit the number of open ports and restrict unnecessary inbound and outbound traffic from the affected IP range.
+- Patch and update systems: Ensure all systems and services identified during the scan are up-to-date with the latest security patches to mitigate known vulnerabilities.
+- Monitor for recurrence: Set up enhanced monitoring for the source IP and similar scanning patterns to quickly detect and respond to any future scanning attempts.
+- Escalate to security operations: If the scan is part of a larger attack or if sensitive data is at risk, escalate the incident to the security operations team for further analysis and response.
+- Review and enhance detection capabilities: Evaluate the effectiveness of current detection mechanisms and consider integrating additional threat intelligence sources to improve early detection of similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/network/discovery_potential_syn_port_scan_detected.toml b/rules/network/discovery_potential_syn_port_scan_detected.toml
index 7a85fc4e8c0..769793bfc66 100644
--- a/rules/network/discovery_potential_syn_port_scan_detected.toml
+++ b/rules/network/discovery_potential_syn_port_scan_detected.toml
@@ -37,6 +37,41 @@ type = "threshold"
 query = '''
 destination.port : * and network.packets <= 2 and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential SYN-Based Port Scan Detected
+
+SYN-based port scanning is a reconnaissance technique where attackers send SYN packets to multiple ports to identify open services. This method helps adversaries map network vulnerabilities for potential exploitation. The detection rule identifies such scans by flagging connection attempts from internal IPs to multiple ports with minimal packet exchange, indicating a low-risk reconnaissance activity.
+
+### Possible investigation steps
+
+- Review the source IP address involved in the alert to determine if it belongs to a known or authorized device within the network. Check for any recent changes or unusual activity associated with this IP.
+- Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker. Determine if these ports are associated with critical or vulnerable services.
+- Examine historical logs to identify any previous scanning activity from the same source IP or similar patterns of behavior. This can help establish whether the activity is part of a larger reconnaissance effort.
+- Correlate the alert with other security events or alerts to assess if there is a broader attack campaign underway. Look for related alerts that might indicate subsequent exploitation attempts.
+- Investigate the timing and frequency of the scan attempts to understand if they coincide with other suspicious activities or known attack windows. This can provide context on the attacker's intent and urgency.
+- Assess the network's current security posture and ensure that appropriate defenses, such as firewalls and intrusion detection systems, are configured to mitigate potential exploitation of identified open ports.
+
+### False positive analysis
+
+- Internal network scanning tools or scripts used by IT teams for legitimate network mapping can trigger this rule. To manage this, create exceptions for known internal IP addresses or subnets used by IT for network discovery.
+- Automated monitoring systems or security appliances that perform regular port checks might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent false positives.
+- Software updates or patch management systems that check multiple ports for service availability can be mistaken for a SYN-based port scan. Whitelist these systems to avoid unnecessary alerts.
+- Load balancers or network devices that perform health checks across multiple ports may trigger the rule. Exclude these devices from the rule to ensure accurate detection.
+- Development or testing environments where multiple port scans are part of routine operations can cause false positives. Implement exceptions for these environments to maintain focus on genuine threats.
+
+### Response and remediation
+
+- Isolate the affected internal IP address to prevent further reconnaissance or potential exploitation of identified open ports.
+- Conduct a thorough review of firewall and network access control lists to ensure that only necessary ports are open and accessible from internal networks.
+- Implement rate limiting on SYN packets to reduce the risk of successful port scanning and reconnaissance activities.
+- Monitor the network for any unusual outbound traffic from the affected IP address, which may indicate further malicious activity or data exfiltration attempts.
+- Escalate the incident to the security operations team for further analysis and to determine if additional network segments or systems are affected.
+- Update intrusion detection and prevention systems to enhance detection capabilities for similar SYN-based port scanning activities.
+- Review and update network segmentation policies to limit the exposure of critical services and systems to internal reconnaissance activities."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
index ddaf50fd579..15dc1128feb 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ query = '''
     192.168.0.0/16
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 RPC (Remote Procedure Call) from the Internet
+
+RPC enables remote management and resource sharing, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, flagging potential threats from external sources.
+
+### Possible investigation steps
+
+- Review the source IP address of the alert to determine if it is from a known malicious actor or if it has been flagged in previous incidents.
+- Check the destination IP address to confirm it belongs to a critical internal system that should not be exposed to the Internet.
+- Analyze network traffic logs to identify any unusual patterns or volumes of traffic associated with the source IP, focusing on TCP port 135.
+- Investigate any related alerts or logs from the same source IP or destination IP to identify potential patterns or repeated attempts.
+- Assess the potential impact on the affected system by determining if any unauthorized access or changes have occurred.
+- Consult threat intelligence sources to gather additional context on the source IP or any related indicators of compromise.
+
+### False positive analysis
+
+- Internal testing or development environments may generate RPC traffic that appears to originate from external sources. To manage this, add the IP addresses of these environments to the exception list in the detection rule.
+- Legitimate remote management activities by trusted third-party vendors could trigger the rule. Verify the IP addresses of these vendors and include them in the exception list if they are known and authorized.
+- Misconfigured network devices or proxies might route internal RPC traffic through external IP addresses. Review network configurations to ensure proper routing and add any necessary exceptions for known devices.
+- Cloud-based services or applications that use RPC for legitimate purposes might be flagged. Identify these services and adjust the rule to exclude their IP ranges if they are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Conduct a thorough examination of the system logs and network traffic to identify any unauthorized access or data exfiltration attempts.
+- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Change all administrative and user credentials on the affected system and any other systems that may have been accessed using the same credentials.
+- Implement network segmentation to limit the exposure of critical systems and services, ensuring that RPC services are not accessible from the Internet.
+- Monitor the network for any signs of re-infection or further suspicious activity, focusing on traffic patterns similar to those identified in the initial alert.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
index 765d3d433c4..c8e3273c24b 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,40 @@ query = '''
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 RPC (Remote Procedure Call) to the Internet
+
+RPC enables remote management and resource sharing across networks, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic from internal IPs to external networks, flagging potential exploitation attempts by monitoring specific ports and IP ranges.
+
+### Possible investigation steps
+
+- Review the source IP address from the alert to identify the internal system initiating the RPC traffic. Check if this IP belongs to a known or authorized device within the network.
+- Examine the destination IP address to determine if it is a known or suspicious external entity. Use threat intelligence sources to assess if the IP has been associated with malicious activity.
+- Analyze the network traffic logs for the specific event.dataset values (network_traffic.flow or zeek.dce_rpc) to gather more context about the nature and volume of the RPC traffic.
+- Investigate the destination port, specifically port 135, to confirm if the traffic is indeed RPC-related and assess if there are any legitimate reasons for this communication.
+- Check for any recent changes or anomalies in the network configuration or system settings of the source IP that might explain the unexpected RPC traffic.
+- Correlate this alert with other security events or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- Internal testing environments may generate RPC traffic to external IPs for legitimate purposes. Identify and document these environments, then create exceptions in the detection rule to prevent unnecessary alerts.
+- Cloud-based services or applications that require RPC communication for integration or management might trigger false positives. Review these services and whitelist their IP addresses if they are verified as non-threatening.
+- VPN or remote access solutions that use RPC for secure connections can be mistaken for suspicious activity. Ensure that the IP ranges of these solutions are excluded from the rule to avoid false alerts.
+- Automated backup or synchronization tools that use RPC to communicate with external servers could be flagged. Verify these tools and add their destination IPs to an exception list if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough analysis of the affected system to identify any unauthorized changes or installed backdoors, focusing on processes and services related to RPC.
+- Revoke any compromised credentials and enforce a password reset for all accounts that may have been accessed or used during the incident.
+- Apply necessary patches and updates to the affected system and any other systems with similar vulnerabilities to mitigate the risk of exploitation.
+- Monitor network traffic for any signs of lateral movement or additional suspicious activity, particularly focusing on RPC-related traffic.
+- 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 enhanced logging and monitoring for RPC traffic to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
index ec784917be1..bbabffd04b1 100644
--- a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
+++ b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,41 @@ query = '''
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SMB (Windows File Sharing) Activity to the Internet
+
+SMB, a protocol for sharing files and resources within trusted networks, is vulnerable when exposed to the Internet. Adversaries exploit it for unauthorized access or data theft. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges.
+
+### Possible investigation steps
+
+- Review the source IP address from the alert to identify the internal system initiating the SMB traffic. Check if this IP belongs to a known device or user within the organization.
+- Investigate the destination IP address to determine if it is associated with any known malicious activity or if it belongs to a legitimate external service that might require SMB access.
+- Analyze network logs to identify any patterns or anomalies in the SMB traffic, such as unusual data transfer volumes or repeated access attempts, which could indicate malicious activity.
+- Check for any recent changes or updates on the source system that might explain the SMB traffic, such as new software installations or configuration changes.
+- Correlate the alert with other security events or logs, such as authentication logs or endpoint security alerts, to gather additional context and determine if this is part of a broader attack or isolated incident.
+- Consult threat intelligence sources to see if there are any known vulnerabilities or exploits related to the SMB traffic observed, which could provide insight into potential attack vectors.
+
+### False positive analysis
+
+- Internal testing environments may generate SMB traffic to external IPs for legitimate reasons. Identify and whitelist these IPs to prevent false positives.
+- Cloud services or remote backup solutions might use SMB for data transfer. Verify these services and add their IP ranges to the exception list if they are trusted.
+- VPN connections can sometimes appear as external traffic. Ensure that VPN IP ranges are included in the list of known safe IPs to avoid misclassification.
+- Misconfigured network devices might inadvertently route SMB traffic externally. Regularly audit network configurations and update the rule exceptions to include any legitimate device IPs.
+- Some third-party applications may use SMB for updates or data synchronization. Confirm the legitimacy of these applications and exclude their associated IPs from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of firewall and network configurations to ensure SMB traffic is not allowed to the Internet, and block any unauthorized outbound SMB traffic on ports 139 and 445.
+- Perform a comprehensive scan of the isolated system for malware or unauthorized access tools, focusing on identifying any backdoors or persistence mechanisms.
+- Reset credentials and review access permissions for any accounts that may have been compromised or used in the suspicious activity.
+- Notify the security operations center (SOC) and relevant stakeholders about the incident for further analysis and potential escalation.
+- Implement additional monitoring and logging for SMB traffic to detect any future unauthorized attempts to access the Internet.
+- Review and update security policies and procedures to prevent similar incidents, ensuring that SMB services are only accessible within trusted network segments."""
 
 
 [[rule.threat]]
diff --git a/rules/network/initial_access_unsecure_elasticsearch_node.toml b/rules/network/initial_access_unsecure_elasticsearch_node.toml
index 8f51cb76b9c..2e9b1b4b6f2 100644
--- a/rules/network/initial_access_unsecure_elasticsearch_node.toml
+++ b/rules/network/initial_access_unsecure_elasticsearch_node.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/11"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,42 @@ index = ["packetbeat-*", "logs-network_traffic.*"]
 language = "lucene"
 license = "Elastic License v2"
 name = "Inbound Connection to an Unsecure Elasticsearch Node"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Inbound Connection to an Unsecure Elasticsearch Node
+
+Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources.
+- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity.
+- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs.
+- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls.
+- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access.
+- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents.
+
+### False positive analysis
+
+- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise.
+- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments.
+- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule.
+- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers.
+- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only.
+- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat.
+- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats.
+- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts.
+
+## Setup
 
 This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation."""
 references = [
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
index a438cc58550..50bca42993e 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,42 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Credential Dumping - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential dumping, which is a technique used by adversaries to extract sensitive authentication data. Attackers exploit this to gain unauthorized access to systems. The detection rule identifies such threats by analyzing alerts and specific event actions related to credential theft, ensuring timely threat detection and response.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to the Elastic Endgame detection.
+- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft activity detected.
+- Check the associated host and user information to identify the potentially compromised system and user accounts.
+- Investigate the timeline of events leading up to and following the alert to identify any suspicious activities or patterns that may indicate further compromise.
+- Correlate the alert with other security events or logs to determine if this is part of a larger attack or isolated incident.
+- Assess the risk score and severity to prioritize the response and determine if immediate action is required to contain the threat.
+- Consult the MITRE ATT&CK framework for additional context on the T1003 technique to understand potential attacker methods and improve defensive measures.
+
+### False positive analysis
+
+- Routine administrative tasks that involve legitimate credential access tools may trigger alerts. Users can create exceptions for known administrative accounts or tools that are frequently used in these tasks.
+- Security software updates or scans that access credential stores might be flagged. Exclude these processes by identifying their specific event actions and adding them to the exception list.
+- Automated scripts for system maintenance that require credential access could be misidentified. Review and whitelist these scripts by their unique identifiers or execution paths.
+- Legitimate software installations that require elevated privileges may cause alerts. Monitor and exclude these installation processes by verifying their source and purpose.
+- Regularly scheduled backups that access credential data might be detected. Ensure these backup processes are recognized and excluded by specifying their event actions in the rule configuration.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further unauthorized access and lateral movement within the network.
+- Terminate any suspicious processes identified as part of the credential dumping activity to halt ongoing malicious actions.
+- Change all potentially compromised credentials, prioritizing those with elevated privileges, to mitigate unauthorized access risks.
+- Conduct a thorough review of access logs and system events to identify any additional compromised accounts or systems.
+- Restore affected systems from a known good backup to ensure the integrity of the system and data.
+- Implement enhanced monitoring on the affected systems and accounts to detect any signs of recurring or related malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
index 54622033143..5e548712540 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Credential Dumping - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution that proactively prevents credential dumping, a technique where attackers extract sensitive authentication data from systems. Adversaries exploit this to gain unauthorized access to networks. The detection rule identifies prevention alerts by monitoring specific event actions and metadata, signaling attempts to steal credentials, thus enabling timely threat mitigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention of credential dumping.
+- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft attempt that was prevented.
+- Investigate the source and destination systems involved in the alert to identify potential points of compromise or targeted systems.
+- Check for any related alerts or events in the same timeframe that might indicate a coordinated attack or further attempts at credential access.
+- Assess the user accounts involved in the alert to determine if they have been compromised or if there are any unauthorized access attempts.
+- Review the risk score and severity to prioritize the investigation and response actions based on the potential impact on the organization.
+
+### False positive analysis
+
+- Routine administrative tools or scripts that access credential stores may trigger alerts. Review and whitelist these tools if they are verified as non-threatening.
+- Security software performing legitimate credential checks can be mistaken for credential dumping. Identify and exclude these processes from alert generation.
+- Automated backup systems accessing credential data for legitimate purposes might be flagged. Ensure these systems are recognized and excluded from the rule.
+- Regular system maintenance activities that involve credential verification could cause false positives. Document and exclude these activities if they are part of standard operations.
+- User behavior analytics might misinterpret legitimate user actions as credential theft. Implement user behavior baselines to reduce such false positives.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network.
+- Terminate any suspicious processes identified as part of the credential dumping attempt to halt ongoing malicious activities.
+- Change all potentially compromised credentials, especially those with elevated privileges, to prevent unauthorized access using stolen credentials.
+- Conduct a thorough review of access logs and event data to identify any additional systems that may have been targeted or compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.
+- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at credential theft.
+- Review and update endpoint protection configurations to ensure that similar threats are detected and prevented in the future, leveraging insights from the MITRE ATT&CK framework."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/endgame_adversary_behavior_detected.toml b/rules/promotions/endgame_adversary_behavior_detected.toml
index 37dae90c425..1fb53f5e198 100644
--- a/rules/promotions/endgame_adversary_behavior_detected.toml
+++ b/rules/promotions/endgame_adversary_behavior_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,39 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and (event.action:behavior_protection_event or endgame.event_subtype_full:behavior_protection_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Adversary Behavior - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution designed to detect and prevent adversarial actions by monitoring system behaviors. Adversaries may exploit system vulnerabilities or execute unauthorized actions to compromise environments. This detection rule identifies suspicious behavior by analyzing alerts and specific event actions, flagging potential threats for further investigation. The rule's medium severity and risk score highlight its importance in maintaining security posture.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected behavior.
+- Analyze the event.action and endgame.event_subtype_full fields to understand the specific behavior protection event that triggered the alert.
+- Correlate the alert with other recent alerts or logs from the same host or user to identify any patterns or additional suspicious activities.
+- Investigate the affected system for any signs of compromise or unauthorized changes, focusing on the timeframe around the alert.
+- Check for any known vulnerabilities or misconfigurations in the affected system that could have been exploited by the adversary.
+- Consult with the IT or security team to determine if any recent changes or updates could have triggered the alert as a false positive.
+
+### False positive analysis
+
+- Routine software updates or installations may trigger alerts due to behavior resembling adversarial actions. Users can create exceptions for known update processes to reduce false positives.
+- Legitimate administrative tasks, such as system configuration changes, might be flagged. Identifying and excluding these tasks from monitoring can help minimize unnecessary alerts.
+- Security tools or scripts that perform regular scans or maintenance can mimic adversary behavior. Whitelisting these tools in the detection rule settings can prevent them from being flagged.
+- Automated backup processes that access multiple files or systems simultaneously may be misinterpreted as suspicious. Users should ensure these processes are recognized and excluded from triggering alerts.
+- Custom applications with unique behaviors might be incorrectly identified as threats. Users should document and exclude these behaviors if they are verified as non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further unauthorized actions or potential lateral movement by the adversary.
+- Review the specific event.action and endgame.event_subtype_full fields to understand the nature of the detected behavior and identify any compromised accounts or processes.
+- Terminate any unauthorized processes or sessions identified during the investigation to halt adversary activities.
+- Apply security patches or updates to address any exploited vulnerabilities that may have been used by the adversary.
+- Conduct a thorough scan of the affected system and network to identify and remove any malicious artifacts or backdoors left by the adversary.
+- Restore affected systems from a known good backup if necessary, ensuring that the backup is free from compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
diff --git a/rules/promotions/endgame_malware_detected.toml b/rules/promotions/endgame_malware_detected.toml
index cbf07ce6b21..516eb518a45 100644
--- a/rules/promotions/endgame_malware_detected.toml
+++ b/rules/promotions/endgame_malware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,39 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Malware - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that provides endpoint protection by monitoring and analyzing system activities to detect malicious behavior. Adversaries may exploit this technology by attempting to bypass its detection capabilities or by executing malware that mimics legitimate processes. The detection rule identifies suspicious file classification events, flagging potential malware activities with a high-risk score, thus enabling swift investigation and response.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected malware.
+- Examine the specific file classification event by checking the event.action or endgame.event_subtype_full fields to understand the nature of the suspicious file activity.
+- Analyze the endpoint's recent activity logs to identify any unusual behavior or patterns that coincide with the time of the alert.
+- Investigate the source and destination of the file involved in the alert to determine if it is part of a known legitimate process or if it has been flagged in previous incidents.
+- Check for any additional alerts or related events from the same endpoint or user to assess if this is part of a broader attack or isolated incident.
+- Consult threat intelligence sources to see if the file or behavior matches known malware signatures or tactics, techniques, and procedures (TTPs).
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger file classification events. Users can create exceptions for known update processes to prevent these from being flagged as malware.
+- System maintenance tasks, such as disk cleanup or defragmentation, might mimic suspicious file activities. Exclude these routine tasks by identifying their specific processes and adding them to the exception list.
+- Security tools or antivirus software performing scans can generate alerts. Identify these tools and configure the rule to ignore their activities to reduce false positives.
+- Custom scripts or automation tools used within the organization may be misclassified. Review these scripts and whitelist them if they are verified as safe and necessary for business operations.
+- Frequent alerts from specific directories known to store temporary or cache files can be excluded by specifying these directories in the rule settings.
+
+### Response and remediation
+
+- Isolate the affected endpoint immediately to prevent further spread of the detected malware across the network.
+- Terminate any suspicious processes identified by Elastic Endgame that are associated with the file classification event.
+- Quarantine the suspicious files flagged by the detection rule to prevent execution and further analysis.
+- Conduct a thorough scan of the isolated endpoint using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Restore the affected system from a known good backup if malware removal is not feasible or if system integrity is compromised.
+- Review and update endpoint protection policies to ensure they are configured to detect similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
diff --git a/rules/promotions/endgame_malware_prevented.toml b/rules/promotions/endgame_malware_prevented.toml
index d00be854558..c2758e826b3 100644
--- a/rules/promotions/endgame_malware_prevented.toml
+++ b/rules/promotions/endgame_malware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,40 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Malware - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent malware by analyzing and classifying files in real-time. Adversaries may attempt to bypass such defenses by disguising malicious files to evade detection. The detection rule identifies prevention events where Elastic Endgame has successfully blocked a file classified as malware, focusing on alerts generated by file classification activities. This helps security analysts quickly respond to and investigate potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to the Elastic Endgame prevention mechanism.
+- Examine the endgame.metadata.type field to verify it is 'prevention', indicating that the alert pertains to a successfully blocked malware attempt.
+- Investigate the event.action or endgame.event_subtype_full fields to understand the specific file classification event that triggered the alert.
+- Gather additional context by checking the file path, hash, and any associated metadata to identify the potentially malicious file and its origin.
+- Cross-reference the alert with other security logs and alerts to determine if there are related events or patterns that could indicate a broader attack campaign.
+- Assess the risk score and severity to prioritize the investigation and response efforts, considering the high severity and risk score of 73.
+- Utilize the Elastic Endgame interface or provided links for further information and context about the specific prevention event and any recommended remediation actions.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve file classification activities. To manage this, create exceptions for known and trusted software update processes.
+- Security tools or system processes that perform file scanning or classification might be flagged. Identify these processes and add them to an exception list to prevent unnecessary alerts.
+- Custom scripts or applications developed in-house that perform file operations similar to malware can be mistaken for threats. Review these scripts and whitelist them if they are verified as safe.
+- Frequent alerts from specific directories known to contain non-malicious files, such as temporary or backup folders, can be excluded by specifying these paths in the rule exceptions.
+- If certain file types are consistently misclassified as threats, consider adjusting the rule to exclude these file types after confirming they are not harmful.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent the spread of malware to other parts of the network. Disconnect the system from the network and any shared drives.
+- Verify the alert by cross-referencing the blocked file details with known malware signatures or threat intelligence sources to confirm the threat.
+- Remove the malicious file from the system using a trusted antivirus or endpoint protection tool. Ensure that the file is quarantined or deleted to prevent re-execution.
+- Conduct a thorough scan of the affected system and any connected devices to identify and remove any additional malicious files or remnants.
+- Restore any affected files or systems from a clean backup, ensuring that the backup is free from malware before restoration.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised.
+- Review and update security policies and endpoint protection configurations to enhance detection and prevention capabilities against similar threats in the future."""
 
diff --git a/rules/promotions/endgame_ransomware_detected.toml b/rules/promotions/endgame_ransomware_detected.toml
index 917f0ab088b..379a8492e7d 100644
--- a/rules/promotions/endgame_ransomware_detected.toml
+++ b/rules/promotions/endgame_ransomware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,38 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Ransomware - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution designed to detect and respond to threats like ransomware by analyzing system events and behaviors. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activity by monitoring specific alert types and event actions, flagging critical threats for immediate investigation.
+
+### Possible investigation steps
+
+- Review the alert details in Elastic Endgame by clicking the icon in the event.module column or the link in the rule.reference column to gather more context about the detected ransomware event.
+- Analyze the event.kind:alert and event.module:endgame fields to confirm the alert's origin and ensure it aligns with known ransomware activity.
+- Examine the event.action:ransomware_event and endgame.event_subtype_full:ransomware_event fields to identify the specific actions or behaviors that triggered the alert.
+- Investigate the affected systems and endpoints to determine the scope of the ransomware impact, focusing on any encrypted files or unusual system behaviors.
+- Check for any additional alerts or related events in the Elastic Endgame logs that might indicate lateral movement or further malicious activity associated with the ransomware.
+
+### False positive analysis
+
+- Routine backup operations can sometimes mimic ransomware behavior by accessing and modifying large numbers of files. Users should review backup schedules and processes to ensure they are not triggering alerts.
+- Legitimate software updates or installations may be flagged as ransomware events due to their file modification activities. Users can create exceptions for trusted software update processes to prevent false positives.
+- Automated file encryption tools used for legitimate purposes, such as data protection, might trigger ransomware alerts. Users should whitelist these tools if they are verified and necessary for business operations.
+- Security testing or penetration testing activities that simulate ransomware attacks can be mistaken for real threats. Ensure that these activities are coordinated with the security team and excluded from detection rules during testing periods.
+- Frequent alerts from specific non-critical systems or applications that are known to exhibit similar behaviors should be reviewed and, if deemed safe, added to an exception list to reduce noise.
+
+### Response and remediation
+
+- Isolate the affected systems immediately to prevent the spread of ransomware to other networked devices. Disconnect them from the network and any shared storage.
+- Identify and terminate any malicious processes associated with the ransomware event using endpoint detection and response tools.
+- Restore encrypted files from the most recent clean backup. Ensure backups are scanned for malware before restoration to avoid reinfection.
+- Conduct a thorough forensic analysis to determine the initial point of entry and the scope of the compromise. This will help in understanding how the ransomware was deployed.
+- Apply security patches to address any vulnerabilities exploited by the ransomware. Ensure all systems are updated to prevent similar attacks.
+- Enhance monitoring and detection capabilities by configuring alerts for similar event patterns and behaviors identified in the query fields.
+- Report the incident to relevant authorities and stakeholders as per organizational policy and legal requirements, ensuring compliance with any regulatory obligations."""
 
diff --git a/rules/promotions/endgame_ransomware_prevented.toml b/rules/promotions/endgame_ransomware_prevented.toml
index d6e5e4b7667..fe30012c226 100644
--- a/rules/promotions/endgame_ransomware_prevented.toml
+++ b/rules/promotions/endgame_ransomware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,4 +36,39 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Ransomware - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent ransomware by monitoring and analyzing system events. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activities by analyzing alerts and prevention events, focusing on specific actions and event types, thus enabling timely intervention and threat mitigation.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the specific prevention event.
+- Examine the event.kind field to confirm that the alert is indeed an alert type and verify the event.module is set to endgame, ensuring the alert is generated by the Elastic Endgame module.
+- Check the endgame.metadata.type field to ensure it is marked as prevention, indicating that the ransomware activity was successfully blocked.
+- Investigate the event.action and endgame.event_subtype_full fields to identify the specific ransomware event that triggered the alert, which can provide insights into the type of ransomware activity that was attempted.
+- Correlate the alert with other security events and logs from the same timeframe to identify any related activities or anomalies that might indicate a broader attack attempt or compromise.
+- Assess the affected system(s) for any signs of compromise or residual malicious activity, ensuring that the ransomware prevention was comprehensive and no other threats remain.
+
+### False positive analysis
+
+- Routine software updates or installations may trigger alerts as they can mimic ransomware behavior. Users should review these events and create exceptions for trusted software update processes.
+- Backup operations that involve large-scale file modifications or encryptions might be misidentified as ransomware activities. Exclude known backup software and processes from triggering alerts.
+- Security testing tools or scripts designed to simulate ransomware for training or assessment purposes can cause false positives. Ensure these tools are whitelisted and their activities are documented.
+- Automated file encryption services used for legitimate purposes, such as data protection, may be flagged. Identify and exclude these services from the rule to prevent unnecessary alerts.
+- Frequent alerts from specific applications or processes that are known to be safe should be analyzed, and exceptions should be created to reduce noise and focus on genuine threats.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further spread of the ransomware. Disconnect it from the network and any shared drives.
+- Use Elastic Endgame to identify and terminate any malicious processes associated with the ransomware event to halt encryption activities.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to remove any remaining malicious files or components.
+- Restore encrypted files from the most recent clean backup to ensure data integrity and minimize data loss.
+- Review and update endpoint protection settings and policies in Elastic Endgame to enhance detection and prevention capabilities against similar ransomware threats.
+- Notify the IT security team and relevant stakeholders about the incident for awareness and further investigation into potential vulnerabilities exploited.
+- Document the incident details, including the response actions taken, to improve future incident response strategies and facilitate any necessary reporting or compliance requirements."""
 
diff --git a/rules/promotions/execution_endgame_exploit_detected.toml b/rules/promotions/execution_endgame_exploit_detected.toml
index 891c48a3e07..ceddf21428d 100644
--- a/rules/promotions/execution_endgame_exploit_detected.toml
+++ b/rules/promotions/execution_endgame_exploit_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,40 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:exploit_event or endgame.event_subtype_full:exploit_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Exploit - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that monitors and detects exploit attempts within an environment. Adversaries exploit vulnerabilities to execute unauthorized code or escalate privileges. The detection rule identifies alerts from the Endgame module, focusing on exploit-related events. It leverages metadata and event actions to flag high-risk activities, aiding in swift threat detection and response.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to the Elastic Endgame detection.
+- Examine the event.action and endgame.event_subtype_full fields to determine the specific exploit event type, which can provide insight into the nature of the exploit attempt.
+- Investigate the endgame.metadata.type field to gather additional context about the detection, such as the source and target of the exploit attempt.
+- Check the associated risk score and severity level to prioritize the investigation and response efforts, focusing on high-risk activities.
+- Correlate the alert with other related events in the environment to identify potential patterns or additional indicators of compromise.
+- Consult the MITRE ATT&CK framework for the Execution tactic (TA0002) to understand potential techniques that might have been used and to guide further investigation steps.
+
+### False positive analysis
+
+- Routine software updates or patches may trigger exploit detection alerts. Users can create exceptions for known update processes by identifying their unique metadata or event actions.
+- Legitimate administrative tools that perform actions similar to exploits might be flagged. Users should whitelist these tools by specifying their event.module or event.action attributes.
+- Automated scripts used for system maintenance could mimic exploit behavior. To prevent false positives, users can exclude these scripts by defining their specific endgame.event_subtype_full.
+- Security testing activities, such as penetration tests, may generate alerts. Users can manage these by setting temporary exceptions during the testing period, based on the event.kind or event.module.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further exploitation or lateral movement within the network.
+- Terminate any unauthorized processes identified as part of the exploit event to halt malicious activity.
+- Apply relevant security patches or updates to the affected system to address the exploited vulnerability and prevent recurrence.
+- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or secondary payloads.
+- Restore the system from a known good backup if necessary, ensuring that the backup is free from any malicious artifacts.
+- Monitor the network for any signs of similar exploit attempts, using enhanced logging and alerting based on the identified threat indicators.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/execution_endgame_exploit_prevented.toml b/rules/promotions/execution_endgame_exploit_prevented.toml
index 8d924b7e725..e7c52fc16f1 100644
--- a/rules/promotions/execution_endgame_exploit_prevented.toml
+++ b/rules/promotions/execution_endgame_exploit_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,42 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:exploit_event or endgame.event_subtype_full:exploit_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Exploit - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution designed to prevent exploits by monitoring and analyzing system behaviors. Adversaries often exploit vulnerabilities to execute unauthorized code or escalate privileges. This detection rule identifies prevention events where an exploit attempt was blocked, focusing on alerts from the Endgame module. By analyzing specific event actions and metadata, it helps security analysts quickly identify and respond to potential threats, ensuring system integrity and security.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to the Elastic Endgame module.
+- Examine the endgame.metadata.type field to verify it is marked as 'prevention', indicating that the exploit attempt was successfully blocked.
+- Analyze the event.action and endgame.event_subtype_full fields to determine the specific type of exploit event that was attempted, such as 'exploit_event'.
+- Investigate the source and destination IP addresses, user accounts, and hostnames involved in the alert to identify potential points of compromise or targets.
+- Check for any related alerts or logs within the same timeframe to identify patterns or additional indicators of compromise that may suggest a broader attack campaign.
+- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+- Document findings and any actions taken in response to the alert to maintain a comprehensive record for future reference and analysis.
+
+### False positive analysis
+
+- Routine software updates or patches may trigger prevention alerts as they modify system files or configurations. Review the update schedule and correlate alerts with known maintenance windows to verify legitimacy.
+- Legitimate administrative tools or scripts that perform actions similar to exploit techniques can be flagged. Identify these tools and create exceptions for their known behaviors to reduce noise.
+- Security testing or vulnerability scanning activities might mimic exploit attempts. Coordinate with IT and security teams to whitelist these activities during scheduled assessments.
+- Custom applications with unique behaviors may be misidentified as threats. Work with development teams to understand these behaviors and adjust detection rules or create exceptions accordingly.
+- Frequent alerts from specific systems or users could indicate a misconfiguration. Investigate these patterns and adjust system settings or user permissions to align with security policies.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Verify the integrity of critical system files and applications on the affected system to ensure no unauthorized changes have been made.
+- Apply the latest security patches and updates to the affected system to address any known vulnerabilities that may have been targeted.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized access or privilege escalation.
+- Restore the affected system from a known good backup if any unauthorized changes or exploit attempts have compromised system integrity.
+- Monitor the network and system logs for any signs of similar exploit attempts or related suspicious activities to ensure no further threats are present.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be at risk."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/external_alerts.toml b/rules/promotions/external_alerts.toml
index 1eb2d1a0d7d..87fd3f60609 100644
--- a/rules/promotions/external_alerts.toml
+++ b/rules/promotions/external_alerts.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/08"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,41 @@ type = "query"
 query = '''
 event.kind:alert and not event.module:(endgame or endpoint or cloud_defend)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 External Alerts
+
+External alerts are crucial for identifying potential threats across diverse environments like Windows, macOS, and Linux. These alerts are generated from various sources, excluding specific modules like endpoint or cloud defend, to focus on broader threat landscapes. Adversaries may exploit vulnerabilities in these systems to execute unauthorized actions. The 'External Alerts' detection rule filters and highlights such activities by focusing on alert events, enabling analysts to swiftly investigate and mitigate risks.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific event.kind:alert that triggered the detection, ensuring it is not associated with the excluded modules (endgame, endpoint, or cloud_defend).
+- Examine the source and context of the alert by checking the associated tags, such as 'OS: Windows', 'OS: macOS', or 'OS: Linux', to understand the environment affected.
+- Gather additional context by correlating the alert with other logs or events from the same time frame or system to identify any related suspicious activities.
+- Assess the risk score and severity level to prioritize the investigation and determine the potential impact on the organization.
+- Investigate the origin of the alert by identifying the source IP, user account, or process involved, and check for any known vulnerabilities or exploits associated with them.
+- Consult threat intelligence sources to determine if the alert corresponds to any known threat actors or campaigns targeting similar environments.
+
+### False positive analysis
+
+- Alerts from benign third-party applications may trigger false positives. Review and identify these applications, then create exceptions to exclude them from future alerts.
+- Routine system updates or patches can generate alerts. Monitor update schedules and create exceptions for known update activities to reduce noise.
+- Network monitoring tools might produce alerts due to their scanning activities. Verify these tools and exclude their activities if deemed non-threatening.
+- Alerts from internal security testing or penetration testing exercises can be mistaken for threats. Coordinate with security teams to whitelist these activities during scheduled tests.
+- Certain administrative scripts or automation tasks may trigger alerts. Evaluate these scripts and exclude them if they are part of regular operations and pose no risk.
+
+### Response and remediation
+
+- Isolate affected systems immediately to prevent further unauthorized actions and contain the threat.
+- Conduct a thorough review of the alert details to identify any specific vulnerabilities or exploits used by the adversary.
+- Apply relevant patches or updates to the affected systems to remediate any identified vulnerabilities.
+- Restore systems from a known good backup if unauthorized changes or actions have been detected.
+- Monitor network traffic and system logs closely for any signs of further suspicious activity or attempts to exploit similar vulnerabilities.
+- Escalate the incident to the appropriate security team or management if the threat appears to be part of a larger attack campaign or if additional resources are needed for remediation.
+- Enhance detection capabilities by updating security tools and configurations to better identify similar threats in the future."""
 
 
 [[rule.risk_score_mapping]]
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
index 8155bb2f92e..85c5e0d063b 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Credential Manipulation - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential manipulation, which adversaries exploit to escalate privileges by altering access tokens. This detection rule identifies such threats by analyzing alerts for token manipulation events, leveraging its high-risk score and severity to prioritize investigation. The rule aligns with MITRE ATT&CK's framework, focusing on privilege escalation tactics.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to Elastic Endgame's detection capabilities.
+- Examine the event.action and endgame.event_subtype_full fields for token_manipulation_event to understand the specific type of credential manipulation detected.
+- Check the associated user account and system involved in the alert to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
+- Investigate the timeline of events leading up to and following the token manipulation event to identify any additional suspicious activities or patterns.
+- Correlate the alert with other security events or logs to assess if this incident is part of a broader attack or isolated.
+- Evaluate the risk score and severity to prioritize the response and determine if immediate action is required to mitigate potential threats.
+
+### False positive analysis
+
+- Routine administrative tasks involving token manipulation can trigger alerts. Review the context of the event to determine if it aligns with expected administrative behavior.
+- Automated scripts or software updates that require token changes might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for operations.
+- Security tools or monitoring solutions that interact with access tokens for legitimate purposes may cause false positives. Ensure these tools are recognized and excluded from triggering alerts.
+- User behavior analytics might misinterpret legitimate user actions as suspicious. Regularly update user profiles and behavior baselines to minimize these occurrences.
+- Scheduled maintenance activities that involve access token modifications should be documented and excluded from detection rules during their execution time.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network.
+- Revoke and reset any compromised credentials or access tokens identified in the alert to prevent further misuse.
+- Conduct a thorough review of recent access logs and token usage to identify any unauthorized access or actions taken by the adversary.
+- Apply security patches and updates to the affected system and any related systems to close vulnerabilities that may have been exploited.
+- Implement enhanced monitoring on the affected system and related accounts to detect any further suspicious activity or attempts at credential manipulation.
+- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, and escalate to higher management if the threat level increases.
+- Review and update access control policies and token management practices to prevent similar incidents in the future, ensuring that least privilege principles are enforced."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
index 3d28513a582..0473c9c728b 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Credential Manipulation - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution that prevents unauthorized credential manipulation, a tactic often used by adversaries to escalate privileges by altering access tokens. Attackers exploit this to gain elevated access within a system. The detection rule identifies such attempts by monitoring alerts for token manipulation events, leveraging Elastic Endgame's prevention capabilities to thwart these threats effectively.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention capabilities.
+- Examine the event.action and endgame.event_subtype_full fields to identify the specific type of token manipulation event that was prevented.
+- Investigate the source and destination of the alert by analyzing associated IP addresses, user accounts, and hostnames to determine if the attempt was internal or external.
+- Check for any related alerts or logs around the same timeframe to identify potential patterns or coordinated attempts at credential manipulation.
+- Assess the impacted system's current security posture and review recent changes or anomalies in user behavior that might have led to the attempted manipulation.
+- Consult the MITRE ATT&CK framework for additional context on Access Token Manipulation (T1134) to understand potential adversary techniques and improve defensive measures.
+
+### False positive analysis
+
+- Routine administrative tasks involving legitimate token manipulation can trigger alerts. Review the context of the event to determine if it aligns with expected administrative activities.
+- Automated scripts or software updates that modify access tokens as part of their normal operation may cause false positives. Identify these processes and consider adding them to an exception list if they are verified as non-threatening.
+- Security tools or monitoring solutions that interact with access tokens for legitimate purposes might be flagged. Validate these tools and exclude them from the rule if they are confirmed to be safe.
+- User behavior that involves frequent token changes, such as developers testing applications, can lead to false positives. Monitor these activities and create exceptions for known users or groups performing these tasks regularly.
+- Ensure that the rule is not overly broad by refining the query to focus on specific actions or contexts that are more indicative of malicious behavior, reducing the likelihood of false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network.
+- Revoke and reset any potentially compromised credentials associated with the affected system to mitigate unauthorized access.
+- Conduct a thorough review of access logs and token usage to identify any unauthorized access or privilege escalation attempts.
+- Restore the affected system from a known good backup to ensure the integrity of the system and its credentials.
+- Implement additional monitoring on the affected system and related accounts to detect any further suspicious activity.
+- Escalate the incident to the security operations team for a detailed investigation and to assess the potential impact on other systems.
+- Review and update access control policies to ensure that only necessary permissions are granted, reducing the risk of privilege escalation."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
index 2e8870a4bed..3313a4fe13d 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Permission Theft - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that monitors and detects unauthorized access attempts, focusing on privilege escalation tactics like access token manipulation. Adversaries exploit this by stealing or forging tokens to gain elevated permissions. The detection rule identifies suspicious token-related events, flagging high-risk activities indicative of permission theft, thus enabling timely threat response.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's detection capabilities.
+- Examine the event.action and endgame.event_subtype_full fields for token_protection_event to identify the specific token manipulation activity that triggered the alert.
+- Investigate the source and destination user accounts involved in the alert to determine if there are any unauthorized access attempts or privilege escalations.
+- Check for any recent changes or anomalies in the permissions or roles associated with the affected accounts to assess potential impact.
+- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.
+- Consult the MITRE ATT&CK framework for additional context on the Access Token Manipulation technique (T1134) to understand potential adversary behaviors and mitigation strategies.
+
+### False positive analysis
+
+- Routine administrative tasks involving token management can trigger alerts. Review and document these tasks to create exceptions for known safe activities.
+- Automated scripts or services that frequently access tokens for legitimate purposes may be flagged. Identify these scripts and whitelist them to prevent unnecessary alerts.
+- Software updates or installations that require elevated permissions might be detected as suspicious. Monitor these events and adjust detection rules to accommodate regular update schedules.
+- Internal security tools that perform token manipulation for testing or monitoring purposes can cause false positives. Ensure these tools are recognized and excluded from detection rules.
+- User behavior analytics might misinterpret legitimate user actions as threats. Regularly update user profiles and behavior baselines to minimize false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Revoke any compromised or suspicious access tokens identified in the alert to prevent further misuse of elevated permissions.
+- Conduct a thorough review of recent account activities associated with the compromised tokens to identify any unauthorized actions or changes.
+- Reset passwords and enforce multi-factor authentication for accounts involved in the incident to enhance security and prevent future unauthorized access.
+- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been affected.
+- Implement enhanced monitoring and logging for token-related activities to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
index 24e914d7863..8348b3462d7 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Permission Theft - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution that prevents unauthorized access by monitoring and blocking attempts to manipulate access tokens, a common privilege escalation tactic. Adversaries exploit token manipulation to gain elevated permissions without detection. The detection rule identifies and alerts on prevention events related to token protection, leveraging specific event types and actions to flag suspicious activities, thus mitigating potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to Elastic Endgame's token protection.
+- Examine the event.action and endgame.event_subtype_full fields to determine if the alert was triggered by a 'token_protection_event', which indicates an attempt to manipulate access tokens.
+- Investigate the source and destination of the alert by analyzing associated IP addresses, user accounts, and hostnames to identify potential unauthorized access attempts.
+- Check the endgame.metadata.type field to verify that the event type is 'prevention', confirming that the attempted permission theft was successfully blocked.
+- Correlate the alert with other recent alerts or logs to identify patterns or repeated attempts that might indicate a persistent threat actor.
+- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+
+### False positive analysis
+
+- Routine administrative tasks involving legitimate token manipulation may trigger alerts. Review the context of the event to determine if it aligns with expected administrative activities.
+- Scheduled scripts or automated processes that require token access might be flagged. Identify these processes and consider creating exceptions for known, safe operations.
+- Software updates or installations that involve token changes can generate alerts. Verify the source and purpose of the update to ensure it is authorized, and exclude these events if they are part of regular maintenance.
+- Security tools or monitoring solutions that interact with tokens for legitimate purposes may cause false positives. Cross-reference with known tool activities and whitelist these actions if they are verified as non-threatening.
+- User behavior analytics might misinterpret legitimate user actions as suspicious. Analyze user activity patterns and adjust the detection thresholds or rules to better align with normal user behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system to prevent further unauthorized access or privilege escalation attempts.
+- Revoke any potentially compromised access tokens and force re-authentication for affected accounts to ensure that only legitimate users regain access.
+- Conduct a thorough review of recent access logs and token usage to identify any unauthorized access or actions taken by the adversary.
+- Apply patches or updates to the affected systems and applications to address any vulnerabilities that may have been exploited for token manipulation.
+- Implement enhanced monitoring on the affected systems to detect any further attempts at access token manipulation or privilege escalation.
+- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, and escalate to higher management if the threat level increases.
+- Review and update access control policies and token management practices to prevent similar incidents in the future, ensuring that only necessary permissions are granted and regularly audited."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
index 1eea20d6f70..e63e54f280a 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,42 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Injection - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that monitors and detects suspicious activities like process injection, a technique often used by adversaries to execute malicious code within the address space of another process, thereby evading detection. This detection rule identifies such threats by analyzing alerts and specific event actions related to kernel shellcode, indicating potential privilege escalation attempts. By leveraging MITRE ATT&CK frameworks, it effectively flags high-risk activities, aiding analysts in mitigating threats.
+
+### Possible investigation steps
+
+- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected process injection.
+- Examine the specific event.action and endgame.event_subtype_full fields to confirm the presence of kernel_shellcode_event, which indicates potential malicious activity.
+- Analyze the process tree and parent-child relationships of the affected process to identify any unusual or unauthorized processes that may have initiated the injection.
+- Check for any recent privilege escalation attempts or suspicious activities associated with the affected process by correlating with other alerts or logs in the system.
+- Investigate the source and destination IP addresses, if available, to determine if there is any external communication that could suggest a command and control connection.
+- Assess the risk and impact of the detected activity by considering the risk score and severity level, and prioritize response actions accordingly.
+- If necessary, isolate the affected system to prevent further malicious activity and begin remediation efforts based on the findings.
+
+### False positive analysis
+
+- Legitimate software updates or patches may trigger process injection alerts. Users can create exceptions for known update processes by identifying their unique process names or hashes.
+- Security tools or monitoring software that use process injection for legitimate purposes might be flagged. Users should whitelist these tools by specifying their process identifiers or paths.
+- Custom scripts or automation tasks that interact with system processes could be misidentified as threats. Users can exclude these scripts by defining their execution context or command-line arguments.
+- Debugging or development activities involving process manipulation might cause false positives. Users should consider excluding these activities during known development periods or within specific environments.
+- Virtualization or sandboxing solutions that mimic process injection techniques for isolation purposes may be detected. Users can create exceptions for these solutions by recognizing their specific signatures or behaviors.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further spread of the malicious code. Disconnect it from the network and any shared resources.
+- Terminate the malicious process identified by the alert to stop the execution of injected code. Use process management tools to safely end the process.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack.
+- Review and analyze system logs and the specific event details from the alert to understand the scope of the intrusion and identify any other potentially compromised systems.
+- Apply security patches and updates to the operating system and all software applications on the affected system to close any vulnerabilities exploited by the attacker.
+- Restore the system from a known good backup taken before the incident occurred, ensuring that the backup is free from any malicious code.
+- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed information about the attack and the steps taken for remediation."""
 
 
 [[rule.threat]]
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
index 8b96514519b..e2a0b0b86ca 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ type = "query"
 query = '''
 event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Injection - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution that prevents malicious activities like process injection, a technique often used by adversaries to execute code within the address space of another process, enabling privilege escalation. This detection rule identifies attempts by monitoring alerts for specific kernel shellcode events, indicating potential injection attempts, and helps mitigate threats by leveraging prevention capabilities.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention capabilities.
+- Examine the event.action and endgame.event_subtype_full fields for kernel_shellcode_event to identify the specific type of process injection attempt.
+- Investigate the source process and target process involved in the injection attempt to understand the context and potential impact on the system.
+- Check for any associated alerts or logs around the same timeframe to identify if this is part of a larger attack pattern or isolated incident.
+- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+- Consult the MITRE ATT&CK framework for additional context on the T1055 Process Injection technique to understand common methods and potential mitigations.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger kernel shellcode events. Users can create exceptions for known update processes by identifying their unique process identifiers or paths.
+- Security tools or monitoring software that perform deep system scans might mimic process injection behavior. Exclude these tools by specifying their executable names or hashes in the exception list.
+- Custom scripts or automation tools that interact with system processes could be flagged. Review these scripts and whitelist them if they are verified as safe and necessary for operations.
+- Development environments or debugging tools that inject code for testing purposes may cause alerts. Establish exceptions for these environments by defining rules based on the development tools' signatures or process names.
+- Virtualization software that uses process injection techniques for managing virtual machines can be mistakenly identified. Add these applications to the exclusion list by recognizing their specific process attributes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified by the alert, particularly those associated with the kernel shellcode event, to halt ongoing malicious actions.
+- Conduct a thorough analysis of the affected system to identify any additional indicators of compromise or secondary payloads that may have been deployed.
+- Restore the affected system from a known good backup to ensure any injected code or malicious modifications are removed.
+- Apply security patches and updates to the operating system and all installed software to close any vulnerabilities that may have been exploited.
+- Monitor the network and systems for any signs of similar process injection attempts, using enhanced logging and alerting based on the identified threat indicators.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/threat_intel/threat_intel_indicator_match_address.toml b/rules/threat_intel/threat_intel_indicator_match_address.toml
index 6026f6f265d..b371aa40afd 100644
--- a/rules/threat_intel/threat_intel_indicator_match_address.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_address.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel IP Address Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel IP Address Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_hash.toml b/rules/threat_intel/threat_intel_indicator_match_hash.toml
index 236fb01db80..cb02712e3b2 100644
--- a/rules/threat_intel/threat_intel_indicator_match_hash.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_hash.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel Hash Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel Hash Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_registry.toml b/rules/threat_intel/threat_intel_indicator_match_registry.toml
index 5612c34e435..6406191a8fb 100644
--- a/rules/threat_intel/threat_intel_indicator_match_registry.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_registry.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel Windows Registry Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel Windows Registry Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_url.toml b/rules/threat_intel/threat_intel_indicator_match_url.toml
index 1f829b8c28c..7a16b72ecf2 100644
--- a/rules/threat_intel/threat_intel_indicator_match_url.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_url.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2024/06/10"
+updated_date = "2025/01/10"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +41,7 @@ interval = "1h"
 language = "kuery"
 license = "Elastic License v2"
 name = "Threat Intel URL Indicator Match"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Threat Intel URL Indicator Match
 
diff --git a/rules/threat_intel/threat_intel_rapid7_threat_command.toml b/rules/threat_intel/threat_intel_rapid7_threat_command.toml
index 28bd096da4b..bab9e900435 100644
--- a/rules/threat_intel/threat_intel_rapid7_threat_command.toml
+++ b/rules/threat_intel/threat_intel_rapid7_threat_command.toml
@@ -4,7 +4,7 @@ integration = ["ti_rapid7_threat_command"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for Rapid7 Threat Command Integration"
 min_stack_version = "8.13.0"
-updated_date = "2024/08/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ language = "kuery"
 license = "Elastic License v2"
 max_signals = 10000
 name = "Rapid7 Threat Command CVEs Correlation"
-note = """## Triage and Analysis
+note = """## Triage and analysis
 
 ### Investigating Rapid7 Threat Command CVEs Correlation
 
diff --git a/rules/windows/collection_email_outlook_mailbox_via_com.toml b/rules/windows/collection_email_outlook_mailbox_via_com.toml
index feb34e149a7..4d304d8e496 100644
--- a/rules/windows/collection_email_outlook_mailbox_via_com.toml
+++ b/rules/windows/collection_email_outlook_mailbox_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/06/20"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,41 @@ sequence with maxspan=1m
 [process where host.os.type == "windows" and event.action == "start" and process.name : "OUTLOOK.EXE" and
   process.Ext.effective_parent.name != null] by process.Ext.effective_parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Inter-Process Communication via Outlook
+
+Outlook's integration with the Component Object Model (COM) allows processes to automate tasks like sending emails. Adversaries exploit this by using unusual processes to interact with Outlook, potentially to exfiltrate data or send unauthorized emails. The detection rule identifies such anomalies by monitoring for unexpected processes initiating communication with Outlook, especially those lacking trusted signatures or recently modified, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process entity ID to identify the specific process that initiated communication with Outlook and determine if it is one of the unusual processes listed, such as rundll32.exe, mshta.exe, or powershell.exe.
+- Check the code signature status of the initiating process. If the process is unsigned or has an untrusted signature, investigate the source and legitimacy of the executable.
+- Analyze the relative file creation and modification times of the initiating process. If the process was created or modified recently (within 500 seconds), it may indicate a newly introduced or altered executable, warranting further scrutiny.
+- Investigate the effective parent process of OUTLOOK.EXE to understand the context of how Outlook was launched. Determine if the parent process is expected or if it is an unusual or suspicious process.
+- Correlate the alert with any recent user activity or changes on the host to identify potential user actions or system changes that could explain the process behavior.
+- Examine any network activity associated with the initiating process to identify potential data exfiltration or unauthorized email sending attempts.
+- Review any additional alerts or logs related to the host or user account to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools may trigger the rule if they use processes like PowerShell or cmd.exe to automate tasks involving Outlook. To manage this, identify and whitelist these scripts or tools by their specific file paths or hashes.
+- Software updates or installations might cause processes to appear as recently modified, leading to false positives. Regularly update the list of trusted software and exclude these known update processes from triggering alerts.
+- Custom in-house applications that interact with Outlook for business purposes may be flagged. Ensure these applications are signed with a trusted certificate or add them to an exception list based on their unique identifiers.
+- Security tools or monitoring software that perform regular checks on Outlook might be misidentified. Verify these tools and exclude them by their process names or signatures to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified in the alert, particularly those interacting with Outlook, such as rundll32.exe, mshta.exe, or powershell.exe.
+- Conduct a thorough review of the email account associated with the affected Outlook process to identify any unauthorized access or email activity. Reset the account credentials if necessary.
+- Analyze the process code signatures and file modification times to determine if any legitimate applications have been compromised. Reinstall or update these applications as needed.
+- 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 additional monitoring on the affected system and similar endpoints to detect any recurrence of the suspicious activity.
+- Review and update endpoint protection policies to ensure that similar threats are detected and blocked in the future, leveraging the MITRE ATT&CK framework for guidance on email collection techniques."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/collection_posh_webcam_video_capture.toml b/rules/windows/collection_posh_webcam_video_capture.toml
index a0006542832..cd4c2eed179 100644
--- a/rules/windows/collection_posh_webcam_video_capture.toml
+++ b/rules/windows/collection_posh_webcam_video_capture.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/18"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -67,6 +67,40 @@ event.category:process and host.os.type:windows and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Webcam Video Capture Capabilities
+
+PowerShell, a powerful scripting language in Windows, can interface with system components like webcams for legitimate tasks such as video conferencing. However, adversaries exploit this by crafting scripts to covertly record video, infringing on privacy. The detection rule identifies suspicious script patterns and API calls linked to webcam access, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or API calls, such as "NewFrameEventHandler" or "VideoCaptureDevice".
+- Check the process execution details, including the parent process, to determine how the PowerShell script was initiated and if it was part of a legitimate application or task.
+- Investigate the user account under which the PowerShell script was executed to assess if the account has a history of suspicious activity or if it has been compromised.
+- Examine the host's recent activity logs for any other unusual behavior or alerts that might correlate with the webcam access attempt, such as unauthorized access attempts or data exfiltration.
+- Verify if the host has any legitimate applications that might use webcam access, and cross-reference with the script's behavior to rule out false positives.
+
+### False positive analysis
+
+- Legitimate video conferencing applications may trigger the detection rule due to their use of similar API calls and script patterns. Users can create exceptions for known and trusted applications by whitelisting their process names or script signatures.
+- Security testing tools that simulate webcam access for vulnerability assessments might be flagged. To handle this, users should exclude these tools from monitoring during scheduled testing periods.
+- System diagnostics or maintenance scripts that access webcam components for hardware checks can be mistaken for malicious activity. Users should document and exclude these scripts if they are part of routine system operations.
+- Educational or training software that uses webcam access for interactive sessions may be incorrectly identified. Users can mitigate this by adding these applications to an allowlist after verifying their legitimacy.
+- Custom scripts developed in-house for specific business needs that involve webcam access should be reviewed and, if deemed safe, excluded from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the detection rule to stop ongoing webcam recording activities.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software.
+- Review and revoke any unauthorized access permissions or credentials that may have been compromised during the incident.
+- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious script.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for PowerShell activities across the network to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
index 915c09f4456..213e3703679 100644
--- a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
+++ b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,40 @@ network where host.os.type == "windows" and network.protocol == "dns" and
   /* Insert noisy false positives here */
   not process.name : ("svchost.exe", "MicrosoftEdge*.exe", "msedge.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Connection to Commonly Abused Free SSL Certificate Providers
+
+Free SSL certificates, like those from Let's Encrypt, enable secure web traffic encryption. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities.
+
+### Possible investigation steps
+
+- Review the process executable path to confirm if it is a native Windows process and assess the legitimacy of its network activity. Focus on paths like "C:\\Windows\\System32\\*.exe" and "C:\\Windows\\SysWOW64\\*.exe".
+- Investigate the specific domain accessed by the process, such as those ending in "*.letsencrypt.org" or "*.sslforfree.com", to determine if it is associated with known malicious activity or if it is a legitimate service.
+- Check the process name against the list of excluded false positives, ensuring it is not "svchost.exe", "MicrosoftEdge*.exe", or "msedge.exe", which are common and typically benign.
+- Analyze the network traffic associated with the process to identify any unusual patterns or anomalies that could indicate command and control activity.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Windows system processes like svchost.exe and MicrosoftEdge.exe are common false positives due to their legitimate network activities. These can be excluded from the detection rule to reduce noise.
+- Regularly update the list of excluded processes to include any new system processes that are verified to have legitimate reasons for accessing domains with free SSL certificates.
+- Monitor and analyze network traffic patterns to identify any additional processes that consistently generate false positives, and consider adding them to the exclusion list if they are deemed non-threatening.
+- Use process whitelisting to allow known safe applications that frequently access these domains, ensuring they do not trigger alerts unnecessarily.
+- Implement a review process to periodically reassess the exclusion list, ensuring it remains relevant and does not inadvertently allow malicious activities to go undetected.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement.
+- Terminate any suspicious processes identified in the alert that are not typically associated with network activity, such as those running from unusual paths or with unexpected network connections.
+- Conduct a thorough review of the system's recent activity logs to identify any unauthorized changes or additional indicators of compromise.
+- Remove any malicious files or executables found on the system, ensuring that all remnants of the threat are eradicated.
+- Restore the system from a known good backup if any critical system files or configurations have been altered.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_iexplore_via_com.toml b/rules/windows/command_and_control_iexplore_via_com.toml
index 79424244132..9bafb1266ca 100644
--- a/rules/windows/command_and_control_iexplore_via_com.toml
+++ b/rules/windows/command_and_control_iexplore_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,41 @@ sequence by host.id, user.name with maxspan = 5s
     )
   ] /* with runs=5 */
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Command and Control via Internet Explorer
+
+Internet Explorer can be manipulated via the Component Object Model (COM) to initiate network connections, potentially bypassing security measures. Adversaries exploit this by embedding IE in processes like rundll32.exe, making it appear benign. The detection rule identifies unusual DNS queries from IE, excluding common Microsoft domains, to flag suspicious activity indicative of command and control attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and user associated with the suspicious activity, focusing on the host.id and user.name fields.
+- Examine the process tree on the affected host to confirm if Internet Explorer (iexplore.exe) was indeed started via COM, specifically looking for the parent process rundll32.exe or regsvr32.exe with IEProxy.dll loaded.
+- Analyze the DNS queries made by Internet Explorer to identify any unusual or suspicious domains that are not part of the common Microsoft or OCSP-related domains listed in the exclusion list.
+- Check the network connections initiated by Internet Explorer to determine if there are any unexpected or unauthorized external IP addresses or domains being contacted.
+- Investigate the context and timing of the alert by correlating it with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise.
+- Assess the risk and potential impact of the detected activity by considering the severity of the alert and any additional findings from the investigation steps above.
+
+### False positive analysis
+
+- Internet Explorer may make legitimate DNS queries to domains not listed in the exclusion list, such as those related to third-party services or internal company resources. Users should monitor and identify these domains and consider adding them to the exclusion list if they are verified as non-threatening.
+- Some enterprise environments may use custom applications that leverage Internet Explorer via COM for legitimate purposes. In such cases, users should identify these applications and create exceptions for their associated processes to prevent false positives.
+- Regular updates or patches from non-Microsoft sources might trigger alerts if they use Internet Explorer for network connections. Users should verify the legitimacy of these updates and adjust the exclusion list accordingly.
+- Internal network monitoring tools or scripts that use Internet Explorer for testing or monitoring purposes could be flagged. Users should document these tools and exclude their associated network activities from the detection rule.
+- If a specific user or department frequently triggers alerts due to legitimate use of Internet Explorer, consider creating user or department-specific exceptions to reduce noise while maintaining security oversight.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further command and control communication and potential data exfiltration.
+- Terminate the Internet Explorer process (iexplore.exe) and any associated processes like rundll32.exe or regsvr32.exe that are identified as suspicious.
+- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software or scripts.
+- Review and analyze the DNS query logs to identify any other potentially compromised hosts within the network that may have communicated with the same suspicious domains.
+- Restore the affected system from a known good backup if malware is confirmed and cannot be fully removed, ensuring that the backup is free from compromise.
+- Implement network-level controls to block the identified suspicious domains and IP addresses to prevent future communication attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_outlook_home_page.toml b/rules/windows/command_and_control_outlook_home_page.toml
index e91e82eb0d6..8524784e187 100644
--- a/rules/windows/command_and_control_outlook_home_page.toml
+++ b/rules/windows/command_and_control_outlook_home_page.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/01"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,40 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
         "USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL"
     ) and registry.data.strings : "*http*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Outlook Home Page Registry Modification
+
+The Outlook Home Page feature allows users to set a webpage as the default view for folders, leveraging registry keys to store URL configurations. Adversaries exploit this by modifying these keys to redirect to malicious sites, enabling command and control or persistence. The detection rule identifies suspicious registry changes, focusing on URL entries within specific paths, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the registry path and value to confirm the presence of a suspicious URL entry in the specified registry paths, such as "HKCU\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL".
+- Investigate the URL found in the registry data strings to determine if it is known to be malicious or associated with suspicious activity.
+- Check the modification history of the registry key to identify when the change occurred and which user or process made the modification.
+- Correlate the registry modification event with other security events on the host, such as network connections or process executions, to identify potential malicious activity.
+- Assess the affected system for signs of compromise, including unusual network traffic or unauthorized access attempts, to determine the scope of the incident.
+- Consult threat intelligence sources to see if the URL or related indicators are associated with known threat actors or campaigns.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify the registry keys associated with Outlook's Home Page feature. Users can create exceptions for known software update processes to prevent unnecessary alerts.
+- Custom scripts or administrative tools used by IT departments to configure Outlook settings across multiple machines might trigger this rule. Identifying and excluding these trusted scripts or tools can reduce false positives.
+- Some third-party Outlook add-ins or plugins may alter the registry keys for legitimate purposes. Users should verify the legitimacy of these add-ins and whitelist them if they are deemed safe.
+- Automated backup or recovery solutions that restore Outlook settings might cause registry changes. Users can exclude these processes if they are part of a regular and secure backup routine.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further communication with potentially malicious sites.
+- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the modified registry keys.
+- Restore the modified registry keys to their default values to remove the malicious URL configuration.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Review and analyze network logs to identify any outbound connections to suspicious domains or IP addresses, and block these at the firewall.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems are affected.
+- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and network activity."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_screenconnect_childproc.toml b/rules/windows/command_and_control_screenconnect_childproc.toml
index 890ac2e7d0f..078062cd8f7 100644
--- a/rules/windows/command_and_control_screenconnect_childproc.toml
+++ b/rules/windows/command_and_control_screenconnect_childproc.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,41 @@ process where host.os.type == "windows" and event.type == "start" and
                    "ssh.exe", "scp.exe", "wevtutil.exe", "wget.exe", "wmic.exe")
    )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious ScreenConnect Client Child Process
+
+ScreenConnect, a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. Malicious actors may spawn processes like PowerShell or cmd.exe via ScreenConnect to perform harmful activities. The detection rule identifies such suspicious child processes, focusing on unusual arguments and process names, indicating potential abuse of remote access capabilities.
+
+### Possible investigation steps
+
+- Review the parent process name to confirm it is one of the ScreenConnect client processes listed in the query, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, to verify the source of the suspicious activity.
+- Examine the child process name and arguments, such as powershell.exe with encoded commands or cmd.exe with /c, to identify potentially malicious actions or commands being executed.
+- Check the network activity associated with the suspicious process, especially if the process arguments include network-related terms like *http* or *downloadstring*, to determine if there is any unauthorized data exfiltration or command and control communication.
+- Investigate the user account under which the suspicious process was executed to assess if the account has been compromised or is being misused.
+- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activities.
+- Review the system's recent activity and changes, such as new scheduled tasks or services created by schtasks.exe or sc.exe, to identify any persistence mechanisms that may have been established by the attacker.
+
+### False positive analysis
+
+- Legitimate IT support activities using ScreenConnect may trigger the rule when executing scripts or commands for maintenance. To manage this, identify and whitelist specific IT support accounts or IP addresses that regularly perform these actions.
+- Automated scripts or scheduled tasks that use ScreenConnect for routine operations might be flagged. Review and document these scripts, then create exceptions for known benign processes and arguments.
+- Software updates or installations initiated through ScreenConnect can appear suspicious. Maintain a list of approved software and update processes, and exclude these from the rule.
+- Internal security tools or monitoring solutions that leverage ScreenConnect for legitimate purposes may be detected. Verify these tools and add them to an exclusion list to prevent false positives.
+- Training sessions or demonstrations using ScreenConnect to showcase command-line tools could be misinterpreted as threats. Ensure these sessions are logged and recognized as non-threatening, and adjust the rule to accommodate these scenarios.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity.
+- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe.
+- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker.
+- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised.
+- 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 enhanced monitoring and logging for ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/command_and_control_tunnel_vscode.toml b/rules/windows/command_and_control_tunnel_vscode.toml
index d40001f8bc6..e2e6141f8a4 100644
--- a/rules/windows/command_and_control_tunnel_vscode.toml
+++ b/rules/windows/command_and_control_tunnel_vscode.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,41 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and 
   not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Establish VScode Remote Tunnel
+
+Visual Studio Code (VScode) offers a remote tunnel feature enabling developers to connect to remote environments seamlessly. While beneficial for legitimate remote development, adversaries can exploit this to establish unauthorized access or control over systems. The detection rule identifies suspicious use of VScode's tunnel command, focusing on specific command-line arguments and process behaviors, to flag potential misuse indicative of command and control activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of the "tunnel" argument in the command line, which indicates an attempt to establish a remote tunnel session.
+- Check the parent process name to ensure it is not "Code.exe" when the process name is "code-tunnel.exe" with the "status" argument, as this is an exception in the rule.
+- Investigate the origin of the process by examining the user account and machine from which the process was initiated to determine if it aligns with expected usage patterns.
+- Analyze network logs to identify any unusual or unauthorized connections to GitHub or remote VScode instances that may suggest malicious activity.
+- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context on the activity.
+- Assess the risk and impact by determining if the system or user account has been involved in previous suspicious activities or if there are any indicators of compromise.
+
+### False positive analysis
+
+- Legitimate remote development activities using VScode's tunnel feature may trigger the rule. Users can create exceptions for known developer machines or specific user accounts frequently using this feature for authorized purposes.
+- Automated scripts or deployment tools that utilize VScode's remote tunnel for legitimate operations might be flagged. Consider excluding these processes by identifying their unique command-line arguments or parent processes.
+- Scheduled tasks or system maintenance activities that involve VScode's remote capabilities could be misidentified as threats. Review and whitelist these tasks by their specific execution times or associated service accounts.
+- Development environments that frequently update or test VScode extensions might inadvertently match the rule's criteria. Exclude these environments by setting up exceptions based on their network segments or IP addresses.
+- Training or demonstration sessions using VScode's remote features for educational purposes can be mistaken for suspicious activity. Implement exclusions for these sessions by tagging them with specific event identifiers or user roles.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious VScode processes identified by the detection rule to halt potential command and control activities.
+- Conduct a thorough review of system logs and process histories to identify any additional indicators of compromise or lateral movement attempts.
+- Reset credentials and access tokens associated with the affected system and any connected services to mitigate unauthorized access.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Implement network segmentation to limit the ability of similar threats to spread across the environment.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_adidns_wildcard.toml b/rules/windows/credential_access_adidns_wildcard.toml
index 7b42d66d267..246b3c1e8fc 100644
--- a/rules/windows/credential_access_adidns_wildcard.toml
+++ b/rules/windows/credential_access_adidns_wildcard.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,41 @@ query = '''
 any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and
     event.code == "5137" and startsWith(winlog.event_data.ObjectDN, "DC=*,")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential ADIDNS Poisoning via Wildcard Record Creation
+
+Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions allow authenticated users to create DNS records, which adversaries can exploit by adding wildcard records. This enables them to redirect traffic and perform Man-in-the-Middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes indicative of wildcard record creation.
+
+### Possible investigation steps
+
+- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification.
+- Examine the ObjectDN field in the event data to identify the specific DNS zone where the wildcard record was created, ensuring it starts with "DC=*," to confirm the wildcard nature.
+- Check the user account associated with the event to determine if it is a legitimate account or potentially compromised, focusing on any unusual or unauthorized activity.
+- Investigate recent changes in the DNS zone to identify any other suspicious modifications or patterns that could indicate further malicious activity.
+- Correlate the event with network traffic logs to detect any unusual or redirected traffic patterns that could suggest a Man-in-the-Middle attack.
+- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users.
+
+### False positive analysis
+
+- Routine administrative changes to DNS records by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or specific ObjectDN patterns that correspond to legitimate changes.
+- Automated systems or scripts that update DNS records as part of regular maintenance may cause false positives. Identify these systems and exclude their activity from triggering alerts by filtering based on their unique identifiers or event sources.
+- Software installations or updates that modify DNS settings might be flagged. Monitor and document these activities, and consider excluding them if they are part of a recognized and secure process.
+- Changes made by trusted third-party services that integrate with ADIDNS could be misinterpreted as threats. Verify these services and whitelist their actions to prevent unnecessary alerts.
+- Temporary testing environments that mimic production settings might generate alerts. Ensure these environments are clearly documented and excluded from monitoring if they are known to perform non-threatening wildcard record creations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or data exfiltration.
+- Revoke any potentially compromised credentials associated with the affected system or user accounts involved in the alert.
+- Conduct a thorough review of DNS records in the affected zone to identify and remove any unauthorized wildcard entries.
+- Implement stricter access controls on DNS record creation, limiting permissions to only necessary administrative accounts.
+- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections.
+- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems.
+- Update detection mechanisms to include additional indicators of compromise related to ADIDNS abuse, enhancing future threat detection capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_adidns_wpad_record.toml b/rules/windows/credential_access_adidns_wpad_record.toml
index 94388242ee5..891d1c9a237 100644
--- a/rules/windows/credential_access_adidns_wpad_record.toml
+++ b/rules/windows/credential_access_adidns_wpad_record.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -63,6 +63,41 @@ query = '''
 any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and
     event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential WPAD Spoofing via DNS Record Creation
+
+Web Proxy Auto-Discovery (WPAD) helps devices automatically detect proxy settings, crucial for network efficiency. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule identifies suspicious DNS record changes, specifically targeting WPAD entries, to flag potential spoofing attempts, aiding in early threat detection and mitigation.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code "5137" to identify the creation or modification of the "wpad" DNS record. Focus on the details provided in the winlog.event_data.ObjectDN field to confirm the presence of "DC=wpad,*".
+- Check the Active Directory change history to determine who made the changes to the DNS records and whether these changes were authorized.
+- Investigate the user account associated with the directory service change event to assess if it has been compromised or if there are any signs of unauthorized access.
+- Analyze network traffic to and from the "wpad" DNS record to identify any suspicious activity or connections to rogue proxy servers.
+- Verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, which could allow unauthorized WPAD entries.
+- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate network changes may trigger alerts if a new WPAD DNS record is created intentionally for network configuration. Verify with network administrators if such changes were planned.
+- Automated scripts or software updates that modify DNS records can cause false positives. Review the source of the change and consider excluding known benign scripts or update processes.
+- Test environments often simulate DNS changes, including WPAD entries, for development purposes. Exclude these environments from monitoring if they are known to generate non-threatening alerts.
+- Some organizations may have legacy systems that rely on WPAD configurations. Document these systems and create exceptions for their DNS changes to avoid unnecessary alerts.
+- Regular audits of the Global Query Block List settings can help identify and exclude expected changes, reducing false positives related to WPAD record creation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data interception or lateral movement by the rogue proxy.
+- Verify and restore the integrity of the DNS records by removing any unauthorized "wpad" entries and re-enabling the Global Query Block List (GQBL) if it was disabled.
+- Conduct a thorough review of Active Directory logs to identify any unauthorized changes or suspicious activities related to directory service modifications.
+- Reset credentials for any accounts that may have been compromised or accessed during the incident to prevent unauthorized access.
+- Implement network segmentation to limit the exposure of critical systems to potential WPAD spoofing attacks.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or data were affected.
+- Update and enhance monitoring rules to detect similar WPAD spoofing attempts in the future, ensuring timely alerts and responses."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_dcsync_user_backdoor.toml b/rules/windows/credential_access_dcsync_user_backdoor.toml
index 409b70d352e..34eb9d57106 100644
--- a/rules/windows/credential_access_dcsync_user_backdoor.toml
+++ b/rules/windows/credential_access_dcsync_user_backdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -17,7 +17,43 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Potential Active Directory Replication Account Backdoor"
-note = """## Setup
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Active Directory Replication Account Backdoor
+
+Active Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to gain replication rights, allowing them to extract sensitive credential data. The detection rule identifies suspicious changes to security descriptors, specifically targeting attributes that grant replication capabilities, which could indicate an attempt to establish a backdoor for credential access.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code 5136 to identify the exact changes made to the nTSecurityDescriptor attribute and the account involved.
+- Examine the winlog.event_data.AttributeValue to determine if the changes include the specific GUIDs (*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, *89e95b76-444d-4c62-991a-0facbeda640c) that indicate replication rights were granted.
+- Identify the user or computer account (S-1-5-21-*) that was granted these rights and assess whether this account should have such permissions.
+- Check the account's recent activity and login history to identify any unusual or unauthorized access patterns.
+- Investigate any recent changes or anomalies in the directory service that could correlate with the suspicious modification event.
+- Consult with the Active Directory administrators to verify if the changes were authorized and part of any legitimate administrative tasks.
+
+### False positive analysis
+
+- Changes made by authorized administrators during legitimate security audits or system maintenance can trigger the rule. To manage this, create exceptions for known administrative accounts performing regular audits.
+- Automated scripts or tools used for Active Directory management might modify security descriptors as part of their normal operation. Identify these scripts and exclude their associated accounts from triggering alerts.
+- Scheduled tasks or system processes that require replication rights for synchronization purposes may also cause false positives. Review and whitelist these processes if they are verified as non-threatening.
+- Third-party applications with legitimate replication needs might alter security descriptors. Ensure these applications are documented and their actions are excluded from the rule.
+- Temporary changes during system migrations or upgrades can be mistaken for suspicious activity. Monitor these events closely and apply temporary exceptions as needed.
+
+### Response and remediation
+
+- Immediately isolate the affected user or computer account from the network to prevent further unauthorized access or data exfiltration.
+- Revoke any unauthorized permissions or changes made to the nTSecurityDescriptor attribute for the affected account to remove replication rights.
+- Conduct a thorough review of recent changes to the AD environment, focusing on accounts with elevated privileges, to identify any other unauthorized modifications.
+- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative or sensitive access.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.
+- Review and update access control policies and security descriptors in Active Directory to prevent similar unauthorized changes in the future.
+
+## Setup
 
 The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
 Steps to implement the logging policy with Advanced Audit Configuration:
diff --git a/rules/windows/credential_access_dnsnode_creation.toml b/rules/windows/credential_access_dnsnode_creation.toml
index 912a7da74cc..4befb35a940 100644
--- a/rules/windows/credential_access_dnsnode_creation.toml
+++ b/rules/windows/credential_access_dnsnode_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -67,6 +67,41 @@ any where host.os.type == "windows" and event.action in ("Directory Service Chan
     event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
     not winlog.event_data.SubjectUserName : "*$"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation of a DNS-Named Record
+
+Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp.
+- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account.
+- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities.
+- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes.
+- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts.
+- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network.
+
+### False positive analysis
+
+- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks.
+- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts.
+- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening.
+- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise.
+- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks.
+- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD.
+- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
+- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.
+- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_dollar_account_relay.toml b/rules/windows/credential_access_dollar_account_relay.toml
index 38245c9dbb2..e6ee0d8a771 100644
--- a/rules/windows/credential_access_dollar_account_relay.toml
+++ b/rules/windows/credential_access_dollar_account_relay.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,41 @@ authentication where host.os.type == "windows" and event.code in ("4624", "4625"
     not endswith(string(source.ip), string(host.ip)) and
     source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Relay Attack against a Domain Controller
+
+Domain Controllers (DCs) are critical in managing authentication within Windows environments. Adversaries exploit this by capturing and relaying DC credentials, often using NTLM authentication, to gain unauthorized access. The detection rule identifies anomalies in authentication events, such as machine accounts logging in from unexpected hosts, indicating potential relay attacks. By analyzing network logon types and mismatched IP addresses, it flags suspicious activities, aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the authentication events with event codes 4624 and 4625 to identify any anomalies in logon attempts, focusing on those using NTLM authentication.
+- Examine the source IP addresses of the suspicious authentication events to determine if they are external or unexpected within the network environment.
+- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies.
+- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts.
+- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity.
+- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack.
+
+### False positive analysis
+
+- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes.
+- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames.
+- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule.
+- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected domain controller from the network to prevent further unauthorized access and potential lateral movement by the attacker.
+- Conduct a password reset for the domain controller's machine account and any other accounts that may have been compromised or are at risk, ensuring the use of strong, unique passwords.
+- Review and analyze recent authentication logs and network traffic to identify any other potentially compromised systems or accounts, focusing on the source IP addresses flagged in the alert.
+- Implement network segmentation to limit the ability of attackers to relay credentials between systems, particularly between domain controllers and other critical infrastructure.
+- 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.
+- Deploy additional monitoring and detection mechanisms to identify similar relay attack patterns in the future, enhancing the detection capabilities for NTLM relay attacks.
+- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_generic_localdumps.toml b/rules/windows/credential_access_generic_localdumps.toml
index ec951d94d75..fab82cacb2f 100644
--- a/rules/windows/credential_access_generic_localdumps.toml
+++ b/rules/windows/credential_access_generic_localdumps.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/28"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,40 @@ registry where host.os.type == "windows" and
     registry.data.strings : ("2", "0x00000002") and
     not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Full User-Mode Dumps Enabled System-Wide
+
+Full user-mode dumps are a diagnostic feature in Windows that captures detailed information about application crashes, aiding in troubleshooting. However, attackers can exploit this by triggering dumps of sensitive processes like LSASS to extract credentials. The detection rule identifies registry changes enabling this feature system-wide, flagging potential misuse by excluding legitimate system processes, thus alerting analysts to suspicious activity.
+
+### Possible investigation steps
+
+- Review the registry path HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType to confirm if the value is set to "2" or "0x00000002", indicating full user-mode dumps are enabled.
+- Check for any recent changes to the registry key by examining the modification timestamps and identifying the user or process responsible for the change.
+- Investigate the context of the alert by reviewing recent process execution logs to identify any suspicious processes that may have triggered the dump, especially those not matching the legitimate svchost.exe process with user IDs S-1-5-18, S-1-5-19, or S-1-5-20.
+- Analyze any generated dump files for sensitive information, such as credentials, and determine if they were accessed or exfiltrated by unauthorized users or processes.
+- Correlate the alert with other security events or logs, such as Sysmon or Microsoft Defender for Endpoint, to identify any related suspicious activities or patterns that could indicate a broader attack.
+
+### False positive analysis
+
+- Legitimate system processes like svchost.exe may trigger the rule if they are not properly excluded. Ensure that the exclusion for svchost.exe is correctly configured by verifying the process executable path and user IDs.
+- Custom applications that require full user-mode dumps for legitimate debugging purposes might be flagged. Identify these applications and create specific registry subkey exclusions to prevent false positives.
+- System administrators performing routine maintenance or diagnostics might enable full user-mode dumps temporarily. Document these activities and consider creating temporary exceptions during maintenance windows.
+- Security tools or monitoring software that simulate crash scenarios for testing purposes could trigger the rule. Verify the legitimacy of these tools and add them to an exclusion list if they are part of regular security operations.
+- Updates or patches from software vendors that modify registry settings for error reporting might be misinterpreted as suspicious. Monitor update schedules and correlate any rule triggers with known update activities to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the attacker.
+- Terminate any unauthorized processes that are generating full user-mode dumps, especially those related to LSASS, to stop further credential dumping.
+- Conduct a thorough review of the registry settings on the affected system to ensure that the full user-mode dumps feature is disabled unless explicitly required for legitimate purposes.
+- Change all credentials that may have been exposed, particularly those associated with high-privilege accounts, to mitigate the risk of unauthorized access.
+- 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 enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly.
+- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar credential dumping techniques."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_iis_connectionstrings_dumping.toml b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
index 127e86d766f..0dd24585fda 100644
--- a/rules/windows/credential_access_iis_connectionstrings_dumping.toml
+++ b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,41 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : "aspnet_regiis.exe" or ?process.pe.original_file_name == "aspnet_regiis.exe") and
   process.args : "connectionStrings" and process.args : "-pdf"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft IIS Connection Strings Decryption
+
+Microsoft IIS often stores sensitive connection strings in encrypted form to secure database credentials. The `aspnet_regiis` tool can decrypt these strings, a feature intended for legitimate administrative tasks. However, attackers with access to the IIS server, possibly via a webshell, can exploit this to extract credentials. The detection rule identifies suspicious use of `aspnet_regiis` by monitoring process execution with specific arguments, flagging potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of aspnet_regiis.exe with the specific arguments "connectionStrings" and "-pdf" to ensure the alert is not a false positive.
+- Check the user account associated with the process execution to determine if it is a legitimate administrative account or a potentially compromised one.
+- Investigate the source of the process initiation by examining the parent process and any related processes to identify if a webshell or unauthorized script triggered the execution.
+- Analyze recent login activities and access logs on the IIS server to identify any unusual or unauthorized access patterns that could indicate a compromise.
+- Review the server's security logs and any available network traffic data to detect any signs of data exfiltration or further malicious activity following the decryption attempt.
+- Assess the integrity and security of the IIS server by checking for any unauthorized changes or suspicious files that may have been introduced by an attacker.
+
+### False positive analysis
+
+- Routine administrative tasks using aspnet_regiis for legitimate configuration changes can trigger the rule. To manage this, create exceptions for known maintenance windows or specific administrator accounts performing these tasks.
+- Automated deployment scripts that include aspnet_regiis for setting up or updating IIS configurations may cause false positives. Exclude these scripts by identifying their unique process arguments or execution paths.
+- Scheduled tasks or services that periodically run aspnet_regiis for configuration validation or updates might be flagged. Document these tasks and exclude them based on their scheduled times or associated service accounts.
+- Development environments where developers frequently use aspnet_regiis for testing purposes can generate alerts. Consider excluding specific development servers or user accounts from the rule to reduce noise.
+- Security tools or monitoring solutions that simulate attacks for testing purposes may inadvertently trigger the rule. Coordinate with security teams to whitelist these tools or their specific test scenarios.
+
+### Response and remediation
+
+- Immediately isolate the affected IIS server from the network to prevent further unauthorized access and potential data exfiltration.
+- Terminate any suspicious processes related to aspnet_regiis.exe to halt any ongoing decryption attempts.
+- Conduct a thorough review of IIS server logs and webshell activity to identify the source of the compromise and any other affected systems.
+- Change all credentials associated with the decrypted connection strings, including database passwords and service account credentials, to prevent unauthorized access.
+- Restore the IIS server from a known good backup taken before the compromise, ensuring that any webshells or malicious scripts are removed.
+- Implement enhanced monitoring and alerting for any future unauthorized use of aspnet_regiis.exe, focusing on the specific arguments used in the detection query.
+- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the broader impact on the organization."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
index b1bcc5351d1..548a4e17b7b 100644
--- a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
+++ b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,41 @@ not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid
           "?:\\Windows\\System32\\DriverStore\\FileRepository\\*")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Untrusted DLL Loaded by Azure AD Sync Service
+
+Azure AD Sync Service facilitates identity synchronization between on-premises directories and Azure AD, crucial for seamless authentication. Adversaries may exploit this by loading malicious DLLs to intercept credentials. The detection rule identifies untrusted DLLs loaded by the Azure AD Sync process, focusing on those lacking valid signatures and excluding known safe paths, thus highlighting potential credential access threats.
+
+### Possible investigation steps
+
+- Review the process details for AzureADConnectAuthenticationAgentService.exe to confirm its legitimacy and check for any unusual behavior or anomalies.
+- Examine the specific DLL file path that triggered the alert to determine if it is located in an unexpected or suspicious directory.
+- Investigate the code signature status of the DLL to understand why it is untrusted, and verify if the DLL should have a valid signature.
+- Check the system for any recent changes or installations that could have introduced the untrusted DLL, focusing on the timeframe around the alert.
+- Analyze the event logs for any other suspicious activities or related alerts that might indicate a broader compromise or attack pattern.
+- Correlate the alert with other security tools or logs to gather additional context and determine if this is part of a larger attack campaign.
+
+### False positive analysis
+
+- DLLs from legitimate software updates or installations may trigger alerts if they are not yet recognized as trusted. Users can monitor these occurrences and verify the legitimacy of the software source before adding exceptions.
+- Custom or in-house developed applications might load DLLs that lack valid signatures. Users should ensure these applications are from a trusted source and consider signing them or adding their paths to the exclusion list.
+- DLLs located in non-standard directories that are part of legitimate software operations can be flagged. Users should verify the software's legitimacy and update the exclusion list with these specific paths if necessary.
+- Temporary files or DLLs created during software installation or updates might be flagged. Users should confirm the installation process and temporarily exclude these paths during the update period.
+- Security or monitoring tools that dynamically load DLLs for legitimate purposes may be misidentified. Users should verify the tool's activity and add it to the exclusion list if it is deemed safe.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure AD Sync server from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the AzureADConnectAuthenticationAgentService.exe process to stop the execution of the untrusted DLL and prevent potential credential dumping.
+- Conduct a thorough review of the loaded DLLs on the affected server to identify and remove any malicious or unauthorized files.
+- Restore the server from a known good backup taken before the incident to ensure the system is free from compromise.
+- Change all credentials that may have been exposed or compromised, focusing on those related to Azure AD and on-premises directory services.
+- Implement application whitelisting to prevent unauthorized DLLs from being loaded by critical processes like Azure AD Sync.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_kirbi_file.toml b/rules/windows/credential_access_kirbi_file.toml
index 15cc4ea836a..d1d1abc06c9 100644
--- a/rules/windows/credential_access_kirbi_file.toml
+++ b/rules/windows/credential_access_kirbi_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,41 @@ type = "eql"
 query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Kirbi File Creation
+
+Kirbi files are associated with Kerberos, a network authentication protocol used in Windows environments to verify user identities. Adversaries exploit this by using tools like Mimikatz to extract Kerberos tickets, enabling unauthorized access through techniques like Pass-The-Ticket. The detection rule identifies the creation of these files, signaling potential credential dumping activities, by monitoring file creation events with a specific extension on Windows systems.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host where the .kirbi file was created, focusing on the host.os.type field to confirm it is a Windows system.
+- Examine the file creation event logs to determine the exact timestamp of the .kirbi file creation and correlate it with other security events around the same time.
+- Investigate the user account associated with the file creation event to determine if it is a legitimate user or potentially compromised, using the event data to identify the user.
+- Check for any recent logins or authentication attempts on the affected host that may indicate unauthorized access, focusing on unusual or unexpected activity.
+- Analyze the process tree and parent processes related to the file creation event to identify any suspicious or unauthorized processes that may have led to the creation of the .kirbi file.
+- Look for additional indicators of compromise on the host, such as other suspicious file creations, modifications, or network connections, to assess the scope of the potential breach.
+- Consult threat intelligence sources or internal threat databases to determine if the detected activity matches known attack patterns or threat actor behaviors associated with Kerberos ticket dumping.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that manage Kerberos tickets may create .kirbi files as part of their normal operations. Review the context of the file creation event to determine if it aligns with expected administrative activities.
+- Scheduled tasks or automated processes that involve Kerberos ticket management might trigger this rule. Identify and document these processes, and consider creating exceptions for known, benign activities.
+- Security software or monitoring tools that interact with Kerberos tickets for auditing or compliance purposes could generate .kirbi files. Verify the source of the file creation and whitelist trusted applications or processes.
+- Development or testing environments where Kerberos authentication is being simulated or tested may produce .kirbi files. Ensure these environments are well-documented and apply exclusions where necessary to avoid false alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate any suspicious processes associated with Mimikatz or other credential dumping tools to halt ongoing malicious activities.
+- Conduct a thorough review of recent authentication logs and Kerberos ticket activity to identify any unauthorized access or ticket usage.
+- Reset passwords for all potentially compromised accounts, prioritizing those with elevated privileges, to mitigate the risk of further exploitation.
+- Revoke all active Kerberos tickets and force re-authentication for all users to ensure that any stolen tickets are rendered useless.
+- 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 enhanced monitoring and logging for Kerberos-related activities to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_ldap_attributes.toml b/rules/windows/credential_access_ldap_attributes.toml
index 0715a53733a..0b6cb2794cc 100644
--- a/rules/windows/credential_access_ldap_attributes.toml
+++ b/rules/windows/credential_access_ldap_attributes.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,41 @@ any where event.action in ("Directory Service Access", "object-operation-perform
    */
   not winlog.event_data.AccessMask in ("0x0", "0x100")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Access to a Sensitive LDAP Attribute
+
+LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats.
+
+### Possible investigation steps
+
+- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes.
+- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System).
+- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.
+- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities.
+- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies.
+- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks.
+- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation.
+
+### False positive analysis
+
+- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule.
+- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign.
+- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts.
+- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes.
+- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes.
+- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel.
+- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
index d2b3ebffb78..075d2a89f4b 100644
--- a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
+++ b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/29"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,40 @@ process where host.os.type == "windows" and event.code == "10" and
    /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION */
   winlog.event_data.GrantedAccess == "0x14c0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious LSASS Access via MalSecLogon
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and user authentication in Windows environments. Adversaries may exploit the Secondary Logon service to gain unauthorized access to LSASS, aiming to extract sensitive credentials. The detection rule identifies this threat by monitoring for unusual access patterns involving LSASS, specifically when the seclogon.dll is involved, indicating potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code "10" to gather more details about the process that triggered the alert, focusing on the time of occurrence and any associated user accounts.
+- Examine the process details for "svchost.exe" to determine if it is running under an expected service or if there are any anomalies in its execution context, such as unusual parent processes or command-line arguments.
+- Investigate the call trace involving "seclogon.dll" to understand the sequence of events leading to the LSASS access, and check for any other suspicious modules or DLLs loaded in the process.
+- Analyze the granted access value "0x14c0" to confirm if it aligns with typical access patterns for legitimate processes interacting with LSASS, and identify any deviations that could indicate malicious intent.
+- Correlate the alert with other security events or logs from the same host or user account to identify any patterns or additional indicators of compromise, such as failed login attempts or other suspicious process activities.
+- Check for any recent changes or updates to the system that might explain the unusual behavior, such as software installations, patches, or configuration changes that could affect the Secondary Logon service or LSASS.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that require access to LSASS for system management tasks may trigger this rule. Users can create exceptions for known tools by excluding specific process names or paths that are verified as safe.
+- Security software or endpoint protection solutions that perform regular scans and require access to LSASS might be flagged. Coordinate with security vendors to identify these processes and exclude them from the rule.
+- System updates or patches that involve the Secondary Logon service could cause temporary access patterns that mimic suspicious behavior. Monitor update schedules and temporarily adjust the rule to prevent false alerts during these periods.
+- Custom enterprise applications that utilize the Secondary Logon service for legitimate purposes may inadvertently match the rule criteria. Work with application developers to understand these access patterns and whitelist the associated processes.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes associated with svchost.exe that are accessing LSASS with the identified suspicious access rights.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or access.
+- Reset passwords for all accounts that may have been compromised, focusing on high-privilege accounts first.
+- Collect and preserve relevant logs and forensic data from the affected system for further analysis and potential legal action.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.
+- Implement additional monitoring and alerting for similar suspicious activities involving LSASS and seclogon.dll to enhance detection capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_lsass_loaded_susp_dll.toml b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
index 8516179dd5a..2dc2414c9ee 100644
--- a/rules/windows/credential_access_lsass_loaded_susp_dll.toml
+++ b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/12/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -102,6 +102,41 @@ any where event.category in ("library", "driver") and host.os.type == "windows"
                  "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb",
                  "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Module Loaded by LSASS
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and handling user authentication in Windows environments. Adversaries exploit LSASS by loading malicious or untrusted DLLs to access sensitive credentials. The detection rule identifies such threats by monitoring LSASS for unsigned or untrusted DLLs, excluding known safe signatures and hashes, thus flagging potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the process details for lsass.exe to confirm the presence of any unsigned or untrusted DLLs loaded into the process. Pay particular attention to the DLL's code signature status and hash values.
+- Cross-reference the identified DLL's hash against known malicious hashes in threat intelligence databases to determine if it is associated with any known threats.
+- Investigate the source and path of the suspicious DLL to understand how it was introduced into the system. This may involve checking recent file creation or modification events in the system directories.
+- Analyze the system's event logs for any related activities or anomalies around the time the suspicious DLL was loaded, such as unusual user logins or privilege escalation attempts.
+- Check for any recent changes in the system's security settings or policies that might have allowed the loading of untrusted DLLs into LSASS.
+- If the DLL is confirmed to be malicious, isolate the affected system to prevent further credential access or lateral movement within the network.
+
+### False positive analysis
+
+- Legitimate software from trusted vendors not included in the exclusion list may trigger false positives. Users can update the exclusion list with additional trusted signatures or hashes from verified vendors to prevent these alerts.
+- Custom or in-house developed DLLs used within the organization might be flagged as suspicious. Organizations should ensure these DLLs are signed with a trusted certificate and add their signatures to the exclusion list if necessary.
+- Security software updates or patches from vendors not currently listed may cause false positives. Regularly review and update the exclusion list to include new trusted signatures from security software providers.
+- Temporary or expired certificates for legitimate DLLs can result in false positives. Users should verify the legitimacy of these DLLs and update the exclusion list with their signatures if they are confirmed safe.
+- DLLs from newly installed software that are not yet recognized as trusted may be flagged. Users should validate the software's source and add its signatures to the exclusion list if it is deemed secure.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the LSASS process if it is confirmed to be running a malicious or untrusted DLL, ensuring that this action does not disrupt critical services.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.
+- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges.
+- Implement application whitelisting to prevent unauthorized DLLs from being loaded into critical processes like LSASS in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update security monitoring tools to enhance detection capabilities for similar threats, ensuring that alerts are generated for any future attempts to load untrusted DLLs into LSASS."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_posh_relay_tools.toml b/rules/windows/credential_access_posh_relay_tools.toml
index c376b490b2d..4d8f8b6150a 100644
--- a/rules/windows/credential_access_posh_relay_tools.toml
+++ b/rules/windows/credential_access_posh_relay_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,6 +68,41 @@ event.category:process and host.os.type:windows and
   ) and
   not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential PowerShell Pass-the-Hash/Relay Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell to perform pass-the-hash attacks, where they use stolen hashed credentials to authenticate without knowing the actual password. The detection rule identifies scripts attempting to execute such attacks by monitoring for specific NTLM negotiation patterns and hex sequences indicative of credential relay activities, while excluding legitimate system processes.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or hex sequences, such as "NTLMSSPNegotiate" or specific hex values like "4E544C4D53535000".
+- Check the process execution details, including the parent process and command line arguments, to determine if the script was executed by a legitimate user or process.
+- Investigate the source and destination IP addresses involved in the NTLM negotiation to identify any unusual or unauthorized network activity.
+- Examine the user account associated with the process to verify if it has been compromised or if there are any signs of unauthorized access.
+- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify potential lateral movement or further compromise.
+- Assess the file directory from which the script was executed, ensuring it is not a known safe location like "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads", which is excluded in the query.
+
+### False positive analysis
+
+- Legitimate system processes may occasionally trigger the rule if they perform operations that mimic NTLM negotiation patterns. To manage this, users can create exceptions for specific processes known to be safe by excluding their file paths or hashes.
+- Security tools or network monitoring solutions that perform NTLM authentication checks might generate false positives. Users should identify these tools and exclude their associated scripts or directories from the detection rule.
+- Automated scripts for system administration that involve NTLM authentication could be flagged. Review these scripts and, if verified as safe, add them to an exclusion list based on their directory or script block text.
+- PowerShell scripts used for legitimate penetration testing or security assessments may trigger alerts. Ensure these activities are documented and exclude the relevant scripts or directories during the testing period.
+- Regular updates or patches from Microsoft might include scripts that temporarily match the detection criteria. Monitor updates and adjust exclusions as necessary to prevent false positives from these legitimate updates.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential relay or unauthorized access.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.
+- Conduct a thorough review of recent authentication logs and network traffic from the isolated system to identify any lateral movement or additional compromised accounts.
+- Reset passwords for any accounts suspected to be compromised, ensuring that new credentials are not reused or easily guessable.
+- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known exploits used in pass-the-hash attacks.
+- Implement network segmentation to limit the spread of similar attacks in the future, focusing on restricting access to critical systems and sensitive data.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_posh_veeam_sql.toml b/rules/windows/credential_access_posh_veeam_sql.toml
index 65831163c1c..b0673ac8b0a 100644
--- a/rules/windows/credential_access_posh_veeam_sql.toml
+++ b/rules/windows/credential_access_posh_veeam_sql.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,40 @@ event.category:process and host.os.type:windows and
     "ProtectedStorage]::GetLocalString"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Veeam Credential Access Capabilities
+
+PowerShell, a powerful scripting language in Windows environments, can be exploited by attackers to access and decrypt sensitive credentials, such as those stored by Veeam in MSSQL databases. Adversaries may leverage this to compromise backup data, facilitating ransomware attacks. The detection rule identifies suspicious script activity by monitoring specific database interactions and decryption attempts, flagging potential credential access threats.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any references to "[dbo].[Credentials]" and "Veeam" or "VeeamBackup" to confirm potential credential access attempts.
+- Check the event logs for the specific host where the alert was triggered to gather additional context about the process execution, including the user account involved and the script's origin.
+- Investigate any recent changes or access to the MSSQL database containing Veeam credentials to determine if there were unauthorized access attempts or modifications.
+- Analyze the use of "ProtectedStorage]::GetLocalString" within the script to understand if it was used to decrypt or access sensitive information.
+- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack.
+
+### False positive analysis
+
+- Routine administrative scripts that query MSSQL databases for maintenance purposes may trigger the rule. To manage this, identify and whitelist specific scripts or processes that are known to be safe and regularly executed by trusted administrators.
+- Scheduled tasks or automated backup verification processes that access Veeam credentials for legitimate reasons can be mistaken for malicious activity. Exclude these tasks by specifying their unique identifiers or execution paths in the monitoring system.
+- Security audits or compliance checks that involve accessing credential information for validation purposes might be flagged. Coordinate with the audit team to document these activities and create exceptions for their scripts.
+- Development or testing environments where PowerShell scripts are used to simulate credential access for testing purposes can generate false positives. Implement environment-specific exclusions to prevent these from being flagged in production monitoring.
+- Third-party monitoring tools that interact with Veeam credentials for health checks or performance monitoring may inadvertently trigger alerts. Work with the tool vendors to understand their access patterns and exclude them if they are verified as non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing credential access attempts.
+- Change all Veeam-related credentials and any other potentially compromised credentials stored in the MSSQL database to prevent further unauthorized access.
+- Conduct a thorough review of backup integrity and ensure that no unauthorized modifications or deletions have occurred.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring for PowerShell activity and MSSQL database access to detect similar threats in the future.
+- Review and update access controls and permissions for Veeam and MSSQL databases to ensure they follow the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
index 3b9496723a6..7ad975bb7e7 100644
--- a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
+++ b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,40 @@ process where host.os.type == "windows" and event.code == "10" and
  /* call is coming from an unknown executable region */
  winlog.event_data.CallTrace : "*UNKNOWN*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Credential Access via DuplicateHandle in LSASS
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user credentials in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing traditional API calls to avoid detection. The detection rule identifies suspicious LSASS handle access attempts from unknown modules, flagging potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code "10" to gather more details about the suspicious activity, focusing on the process name "lsass.exe" and the granted access "0x40".
+- Investigate the call trace details where the event data indicates "*UNKNOWN*" to identify any unknown or suspicious modules that may have initiated the DuplicateHandle request.
+- Correlate the suspicious activity with other security events or alerts on the same host to determine if there are additional indicators of compromise or related malicious activities.
+- Check the process tree and parent-child relationships of the lsass.exe process to identify any unusual or unauthorized processes that may have interacted with LSASS.
+- Analyze the timeline of events to understand the sequence of actions leading up to and following the alert, which may help in identifying the adversary's objectives or next steps.
+- Review recent changes or updates to the system that might have introduced the unknown module or altered the behavior of legitimate processes.
+
+### False positive analysis
+
+- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent unnecessary alerts.
+- System management or administrative scripts that perform legitimate operations on LSASS might be flagged. Review these scripts and, if verified as safe, add them to an exception list to reduce false positives.
+- Custom in-house applications that require access to LSASS for valid reasons could be mistakenly identified. Conduct a thorough review of these applications and exclude them from the rule if they are deemed non-threatening.
+- Security testing or penetration testing activities may mimic malicious behavior. Coordinate with security teams to recognize these activities and temporarily adjust the rule settings during testing periods to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes associated with the unknown executable region accessing LSASS to halt potential credential dumping activities.
+- Conduct a thorough memory analysis of the affected system to identify any malicious artifacts or indicators of compromise related to the DuplicateHandle exploitation.
+- Reset credentials for all accounts that may have been accessed or compromised, prioritizing high-privilege accounts.
+- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future.
+- 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 enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
index 90adf75f13c..46a3947dd1e 100644
--- a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
+++ b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/30"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,41 @@ process where host.os.type == "windows" and event.type == "start" and
   /* Access to named pipe via http */
   process.args : ("http*/print/pipe/*", "http*/pipe/spoolss", "http*/pipe/srvsvc")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Local NTLM Relay via HTTP
+
+NTLM, a suite of Microsoft security protocols, is often targeted by adversaries for credential theft. Attackers may exploit the Windows Printer Spooler service to coerce NTLM authentication over HTTP, potentially elevating privileges. The detection rule identifies suspicious rundll32.exe executions invoking WebDAV client DLLs with specific arguments, signaling attempts to access named pipes via HTTP, indicative of NTLM relay attacks.
+
+### Possible investigation steps
+
+- Review the process execution details for rundll32.exe, focusing on the specific arguments related to davclnt.dll and DavSetCookie, to confirm the presence of suspicious WebDAV client activity.
+- Investigate the network connections initiated by the rundll32.exe process to identify any HTTP requests targeting named pipes, such as those containing "/print/pipe/", "/pipe/spoolss", or "/pipe/srvsvc".
+- Check the system's event logs for any related authentication attempts or failures around the time of the alert to identify potential NTLM relay activity.
+- Analyze the history of the Windows Printer Spooler service on the affected host to determine if it has been recently manipulated or exploited.
+- Correlate the alert with other security events or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+- Assess the user account associated with the NTLM authentication attempt to determine if it has been compromised or is being used in an unauthorized manner.
+
+### False positive analysis
+
+- Legitimate administrative tasks using rundll32.exe with WebDAV client DLLs may trigger the rule. Review the context of the execution, such as the user account and the timing, to determine if it aligns with expected administrative activities.
+- Automated software deployment or update processes might use similar rundll32.exe calls. Verify if the process is part of a scheduled or known deployment task and consider excluding these specific processes from the rule.
+- Some third-party applications may use WebDAV for legitimate purposes, which could mimic the behavior detected by the rule. Identify these applications and create exceptions for their known processes to prevent false alerts.
+- System maintenance scripts or tools that interact with network resources via HTTP might inadvertently match the rule's criteria. Ensure these scripts are documented and exclude them if they are verified as non-threatening.
+- Regularly review and update the exclusion list to accommodate changes in legitimate software behavior, ensuring that only verified false positives are excluded to maintain the rule's effectiveness.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious rundll32.exe processes identified in the alert to stop ongoing malicious activity.
+- Conduct a thorough review of the affected system's event logs and network traffic to identify any additional indicators of compromise or related malicious activity.
+- Reset credentials for any accounts that may have been exposed or compromised during the attack to prevent unauthorized access.
+- Apply the latest security patches and updates to the Windows Printer Spooler service and related components to mitigate known vulnerabilities.
+- Implement network segmentation to limit the exposure of critical services and reduce the risk of similar attacks in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_saved_creds_vault_winlog.toml b/rules/windows/credential_access_saved_creds_vault_winlog.toml
index 385a6037a93..694a6b35566 100644
--- a/rules/windows/credential_access_saved_creds_vault_winlog.toml
+++ b/rules/windows/credential_access_saved_creds_vault_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,41 @@ sequence by winlog.computer_name, winlog.process.pid with maxspan=1s
   not winlog.event_data.SubjectLogonId : "0x3e7" and 
   not winlog.event_data.Resource : "http://localhost/"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Multiple Vault Web Credentials Read
+
+Windows Credential Manager stores credentials for web logins, apps, and networks, facilitating seamless user access. Adversaries exploit this by extracting stored credentials, potentially aiding lateral movement within networks. The detection rule identifies suspicious activity by flagging consecutive credential reads from the same process, excluding benign actions like localhost access, thus highlighting potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the process associated with the flagged PID to determine if it is a legitimate application or potentially malicious. Check for known software or unusual executables.
+- Investigate the source and destination of the web credentials read by examining the winlog.event_data.Resource field to identify any suspicious or unexpected URLs.
+- Check the winlog.computer_name to identify the affected system and assess whether it is a high-value target or has been involved in previous suspicious activities.
+- Analyze the timeline of events around the alert to identify any preceding or subsequent suspicious activities that may indicate a broader attack pattern.
+- Verify the user context by examining the winlog.event_data.SubjectLogonId to ensure the activity was not performed by a privileged or administrative account without proper authorization.
+- Cross-reference the event with other security logs or alerts to identify any correlated activities that might suggest a coordinated attack or compromise.
+
+### False positive analysis
+
+- Localhost access is a common false positive since the rule excludes localhost reads. Ensure that any legitimate applications accessing credentials via localhost are properly whitelisted to prevent unnecessary alerts.
+- Automated scripts or applications that frequently access web credentials for legitimate purposes may trigger the rule. Identify these processes and create exceptions for them to reduce noise.
+- System maintenance or updates might involve credential reads that are benign. Coordinate with IT teams to schedule these activities and temporarily adjust the rule sensitivity or add exceptions during these periods.
+- Security tools or monitoring software that perform regular checks on credential integrity could be flagged. Verify these tools and add them to an exception list if they are part of the organization's security infrastructure.
+- User behavior such as frequent password changes or credential updates might cause alerts. Educate users on the impact of their actions and consider adjusting the rule to accommodate expected behavior patterns.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate the suspicious process identified by the process ID (pid) involved in the credential reads to stop further credential access.
+- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
+- Change passwords for any accounts that may have been exposed, focusing on those stored in the Windows Credential Manager.
+- Implement network segmentation to limit access to critical systems and data, reducing the risk of lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Enhance monitoring and logging on the affected system and similar endpoints to detect any future attempts at credential dumping or unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_saved_creds_vaultcmd.toml b/rules/windows/credential_access_saved_creds_vaultcmd.toml
index 2e9c04c2ec9..e23cf5e7953 100644
--- a/rules/windows/credential_access_saved_creds_vaultcmd.toml
+++ b/rules/windows/credential_access_saved_creds_vaultcmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,40 @@ process where host.os.type == "windows" and event.type == "start" and
   (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and
   process.args:"/list*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Searching for Saved Credentials via VaultCmd
+
+Windows Credential Manager stores credentials for websites, applications, and networks. Adversaries exploit this by using VaultCmd to list or extract these credentials, aiding in lateral movement. The detection rule identifies such abuse by monitoring the execution of VaultCmd with specific arguments, flagging potential credential access attempts. This helps in early detection of unauthorized credential access activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of vaultcmd.exe with the /list* argument, as this indicates an attempt to list saved credentials.
+- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious.
+- Investigate the parent process of vaultcmd.exe to understand how it was initiated and whether it was triggered by a legitimate application or script.
+- Examine recent login activity and network connections from the host to identify any signs of lateral movement or unauthorized access attempts.
+- Correlate this event with other security alerts or logs from the same host or user to identify potential patterns of malicious behavior.
+- Review endpoint security logs from tools like Microsoft Defender for Endpoint or Crowdstrike for additional context or corroborating evidence of credential access attempts.
+
+### False positive analysis
+
+- Routine administrative tasks using VaultCmd for legitimate credential management can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled tasks that regularly use VaultCmd with the /list argument.
+- Security software or system management tools that perform regular audits of stored credentials might also cause false positives. Identify these tools and exclude their processes from triggering the rule.
+- Automated scripts or backup processes that access Credential Manager for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening.
+- User-initiated credential management activities, such as listing credentials for personal use, can be mistaken for malicious behavior. Educate users on the implications of using VaultCmd and consider excluding specific user accounts if necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement and further credential access.
+- Terminate any suspicious processes associated with VaultCmd.exe to halt unauthorized credential dumping activities.
+- Conduct a thorough review of the affected system's event logs and process execution history to identify any additional malicious activities or compromised accounts.
+- Reset passwords for any accounts that may have been exposed or accessed through the Credential Manager to mitigate unauthorized access.
+- Implement enhanced monitoring on the affected system and similar endpoints for any further attempts to use VaultCmd.exe or other credential dumping tools.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach.
+- Review and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future, leveraging threat intelligence and MITRE ATT&CK framework insights."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_generic.toml b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
index 3d128e0eda8..a54cf39d632 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_generic.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/22"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/21"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -73,6 +73,41 @@ process where host.os.type == "windows" and event.code == "10" and
   ) and
   not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Lsass Process Access
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities.
+
+### Possible investigation steps
+
+- Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious.
+- Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns.
+- Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly.
+- Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications.
+- Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with.
+
+### False positive analysis
+
+- Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list.
+- Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts.
+- System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts.
+- Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives.
+- Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted.
+- Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process.
+- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
+- Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
index b4b6624514c..fbb03c918e6 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/07"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.code == "10" and
         "?:\\Windows\\System32\\WerFaultSecure.exe"
       )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Credential Access via LSASS Memory Dump
+
+LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and storing sensitive data like user credentials. Adversaries exploit this by using tools that leverage MiniDumpWriteDump from libraries like DBGHelp.dll to extract credentials. The detection rule identifies suspicious LSASS access by monitoring for these libraries in call traces, excluding legitimate crash handlers, thus flagging potential credential theft attempts.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process name, executable path, and parent process to determine if the process accessing LSASS is legitimate or suspicious.
+- Examine the call trace details to confirm the presence of DBGHelp.dll or DBGCore.dll, which are indicative of potential credential dumping attempts.
+- Check for any recent crash reports or legitimate use of WerFault.exe, WerFaultSecure.exe, or similar processes that might explain the LSASS access as a non-malicious event.
+- Investigate the user account context under which the suspicious process is running to assess if it aligns with expected behavior or if it indicates potential compromise.
+- Correlate the event with other security logs or alerts to identify any related suspicious activities, such as unauthorized access attempts or lateral movement within the network.
+- Assess the risk and impact by determining if any sensitive credentials could have been exposed, and consider isolating the affected system to prevent further compromise.
+
+### False positive analysis
+
+- Legitimate crash handlers like WerFault.exe may access LSASS during system crashes. To prevent these from being flagged, ensure that the rule excludes processes such as WerFault.exe, WerFaultSecure.exe, and their SysWOW64 counterparts.
+- Debugging tools used by developers or IT administrators might trigger this rule if they access LSASS for legitimate purposes. Consider creating exceptions for known and trusted debugging tools within your environment.
+- Security software or endpoint protection solutions may perform similar actions as part of their normal operations. Verify with your security vendor and exclude these processes if they are confirmed to be benign.
+- Automated system diagnostics or maintenance scripts that interact with LSASS for health checks could be misidentified. Review and whitelist these scripts if they are part of routine system management tasks.
+- Ensure that any custom or third-party applications that require access to LSASS for legitimate reasons are documented and excluded from the rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the adversary.
+- Terminate any suspicious processes that are accessing the LSASS memory, especially those involving DBGHelp.dll or DBGCore.dll, to stop the credential dumping activity.
+- Conduct a thorough review of the affected system's security logs to identify any unauthorized access or changes, focusing on event code "10" and call traces involving LSASS.
+- Change passwords for all accounts that were active on the affected system, prioritizing high-privilege accounts, to mitigate the risk of compromised credentials being used.
+- Restore the affected system from a known good backup to ensure that any malicious changes or tools are removed.
+- 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 enhanced monitoring and alerting for similar suspicious activities, focusing on LSASS access and the use of MiniDumpWriteDump, to improve detection and response capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
index 157283aefb3..948c585db92 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,40 @@ event.category:process and host.os.type:windows and event.code:10 and
                                  "c:\\Windows\\system32\\lsass.exe" or
                                  "c:\\Windows\\System32\\lsass.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential LSASS Memory Dump via PssCaptureSnapShot
+
+PssCaptureSnapShot is a Windows feature used for capturing process snapshots, aiding in diagnostics and debugging. Adversaries exploit this to access LSASS memory, aiming to extract credentials. The detection rule identifies suspicious behavior by monitoring for repeated access to LSASS by the same process, targeting different instances, which may indicate an evasion attempt to dump credentials stealthily.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code 10 to gather details about the process that accessed the LSASS handle, including the process name, process ID, and the time of access.
+- Check the process execution history on the host to determine if the process accessing LSASS is legitimate or potentially malicious. Look for any unusual or unexpected processes that might have been executed around the time of the alert.
+- Investigate the parent process of the suspicious process to understand how it was initiated and whether it was spawned by a legitimate application or a known malicious process.
+- Analyze the network activity of the host around the time of the alert to identify any suspicious outbound connections that might indicate data exfiltration attempts.
+- Correlate the alert with other security events or alerts from the same host or user account to identify any patterns or additional indicators of compromise.
+- Verify the integrity and security posture of the host by checking for any unauthorized changes to system files or configurations, especially those related to security settings.
+
+### False positive analysis
+
+- Legitimate diagnostic tools or software that utilize PssCaptureSnapShot for debugging purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent false positives.
+- System administrators or security tools performing regular health checks on LSASS might access LSASS memory in a non-malicious manner. Exclude these known processes by creating exceptions based on their process names or hashes.
+- Automated scripts or maintenance tasks that interact with LSASS for legitimate reasons could be flagged. Review and document these tasks, then configure the rule to ignore these specific activities.
+- Security software updates or patches that temporarily access LSASS for validation or configuration purposes may cause alerts. Monitor update schedules and adjust the rule to accommodate these temporary accesses.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified as accessing LSASS memory using PssCaptureSnapShot to halt potential credential dumping activities.
+- Conduct a thorough review of the affected system's event logs, focusing on event code 10, to identify any additional instances of suspicious LSASS access and determine the scope of the compromise.
+- Change all potentially compromised credentials, especially those with administrative privileges, to mitigate the risk of unauthorized access using dumped credentials.
+- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Enhance monitoring and detection capabilities by ensuring that similar suspicious activities are logged and alerted on, using the specific query fields and threat indicators identified in this alert."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_veeam_backup_dll_imageload.toml b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
index c22dbdbccee..9cd0afc27bc 100644
--- a/rules/windows/credential_access_veeam_backup_dll_imageload.toml
+++ b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,40 @@ library where host.os.type == "windows" and event.action == "load" and
     process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Veeam Backup Library Loaded by Unusual Process
+
+Veeam Backup software is crucial for data protection, enabling secure backup and recovery operations. However, adversaries may exploit its credential storage by loading the Veeam.Backup.Common.dll library through unauthorized processes like PowerShell, aiming to decrypt and misuse credentials. The detection rule identifies such anomalies by flagging untrusted or unsigned processes loading this library, indicating potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the untrusted or unsigned process that loaded the Veeam.Backup.Common.dll library, focusing on the process.name field to determine if it is PowerShell or another suspicious executable.
+- Check the process execution history and command line arguments to understand the context of the process activity, especially if the process.name is powershell.exe, pwsh.exe, or powershell_ise.exe.
+- Investigate the source and integrity of the process by examining the process.code_signature fields to determine if the process is expected or potentially malicious.
+- Analyze the timeline of events on the host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or lateral movement.
+- Correlate the alert with other security events or logs from the same host or network to identify any related indicators of compromise or additional affected systems.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tasks using PowerShell may trigger the rule. Review the script's purpose and source, and if verified as safe, consider adding an exception for the specific script or process.
+- Scheduled tasks or maintenance operations that involve Veeam Backup operations might load the library through unsigned processes. Validate these tasks and exclude them if they are part of routine, secure operations.
+- Custom or third-party backup solutions that integrate with Veeam may load the library in a non-standard way. Confirm the legitimacy of these solutions and whitelist them to prevent unnecessary alerts.
+- Development or testing environments where Veeam components are frequently loaded by various processes for testing purposes can generate false positives. Implement process exclusions for these environments to reduce noise.
+- Ensure that any exclusions or exceptions are documented and reviewed regularly to maintain security posture and adapt to any changes in the environment.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified as loading the Veeam.Backup.Common.dll library, especially those that are unsigned or involve PowerShell.
+- Conduct a thorough review of the system's event logs and process history to identify any additional unauthorized access or actions taken by the adversary.
+- Change all credentials stored within the Veeam Backup software and any other potentially compromised accounts to prevent misuse.
+- Restore any affected systems or data from a known good backup to ensure integrity and availability.
+- 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 enhanced monitoring and alerting for similar activities, focusing on unauthorized process executions and DLL loads, to improve early detection of future threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_veeam_commands.toml b/rules/windows/credential_access_veeam_commands.toml
index 9cfdf005e9b..c78ad2b384f 100644
--- a/rules/windows/credential_access_veeam_commands.toml
+++ b/rules/windows/credential_access_veeam_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,41 @@ process where host.os.type == "windows" and event.type == "start" and
   ) and
   process.args : "*[VeeamBackup].[dbo].[Credentials]*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Veeam Credential Access Command
+
+Veeam credentials stored in MSSQL databases are crucial for managing backup operations. Attackers may exploit tools like `sqlcmd.exe` or PowerShell commands to access and decrypt these credentials, potentially leading to data breaches or ransomware attacks. The detection rule identifies suspicious command executions targeting Veeam credentials, focusing on specific processes and arguments, to alert analysts of potential credential access attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of sqlcmd.exe or PowerShell commands like Invoke-Sqlcmd, focusing on the process.name and process.args fields.
+- Examine the command line arguments for any references to [VeeamBackup].[dbo].[Credentials] to determine if there was an attempt to access or decrypt Veeam credentials.
+- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised.
+- Investigate the source host for any signs of unauthorized access or suspicious activity, such as unusual login times or failed login attempts.
+- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related malicious activities or patterns.
+- Assess the risk and impact by determining if any Veeam credentials were successfully accessed or exfiltrated, and evaluate the potential for data breaches or ransomware attacks.
+
+### False positive analysis
+
+- Routine database maintenance tasks may trigger the rule if they involve accessing Veeam credentials for legitimate purposes. To manage this, identify and document regular maintenance schedules and exclude these activities from triggering alerts.
+- Automated scripts used for backup verification or testing might use similar commands. Review and whitelist these scripts by their process names or specific arguments to prevent unnecessary alerts.
+- Internal security audits or compliance checks that involve credential access could be mistaken for malicious activity. Coordinate with audit teams to schedule these activities and create exceptions for known audit processes.
+- Development or testing environments where Veeam credentials are accessed for non-production purposes can generate false positives. Implement environment-specific exclusions to differentiate between production and non-production activities.
+- Legitimate use of PowerShell commands for database management by authorized personnel may be flagged. Maintain a list of authorized users and their typical command patterns to refine the detection rule and reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the alert, such as `sqlcmd.exe` or PowerShell commands accessing Veeam credentials.
+- Change all Veeam-related credentials stored in the MSSQL database to prevent further unauthorized access using compromised credentials.
+- Conduct a thorough review of recent backup operations and logs to identify any unauthorized access or modifications.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring on systems storing Veeam credentials to detect similar suspicious activities in the future.
+- Review and update access controls and permissions for MSSQL databases to ensure only authorized personnel have access to Veeam credentials."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
index 84213f9d53c..96278b34ea3 100644
--- a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
+++ b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/11/27"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,41 @@ process where host.os.type == "windows" and event.code:"4688" and
   process.executable : "?:\\Windows\\System32\\lsass.exe" and
   process.parent.executable : "?:\\Windows\\System32\\lsass.exe"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential LSASS Clone Creation via PssCaptureSnapShot
+
+PssCaptureSnapShot is a Windows API used for creating snapshots of processes, often for debugging. Adversaries exploit this to clone the LSASS process, aiming to extract credentials without detection. The detection rule identifies suspicious LSASS clones by monitoring process creation events where both the process and its parent are LSASS, signaling potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the process creation event logs for the specific event code 4688 to confirm the creation of an LSASS process clone. Verify that both the process and its parent have the executable path "?:\\Windows\\System32\\lsass.exe".
+- Check the timeline of events to determine if there are any preceding or subsequent suspicious activities related to the LSASS process, such as unusual access patterns or modifications.
+- Investigate the user account and privileges associated with the process creation event to assess if the account has legitimate reasons to interact with LSASS or if it might be compromised.
+- Analyze network activity from the host to identify any potential data exfiltration attempts or connections to known malicious IP addresses following the LSASS clone creation.
+- Correlate this event with other security alerts or logs from the same host to identify if this is part of a broader attack pattern or isolated incident.
+- Examine the host for any signs of malware or tools commonly used for credential dumping, such as Mimikatz, that might have been used in conjunction with the LSASS clone creation.
+
+### False positive analysis
+
+- Legitimate security software or system management tools may create LSASS process snapshots for monitoring or debugging purposes. Identify these tools and create exceptions for their process creation events to avoid false positives.
+- System administrators or IT personnel might use authorized scripts or tools that interact with LSASS for legitimate reasons. Verify these activities and whitelist the associated processes to prevent unnecessary alerts.
+- During system updates or patches, certain processes might temporarily mimic suspicious behavior. Monitor these updates and temporarily adjust detection rules to accommodate expected changes in process behavior.
+- Some enterprise environments may have custom applications that interact with LSASS for performance monitoring. Document these applications and exclude their process creation events from triggering alerts.
+- Regularly review and update the list of known benign processes and tools that interact with LSASS to ensure that the detection rule remains effective without generating excessive false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further credential access or lateral movement by the adversary.
+- Terminate any suspicious LSASS clone processes identified by the detection rule to halt ongoing credential dumping activities.
+- Conduct a thorough memory analysis of the affected system to identify any additional malicious activities or tools used by the adversary.
+- Change all potentially compromised credentials, especially those with administrative privileges, to mitigate the risk of unauthorized access.
+- Review and enhance endpoint security configurations to ensure that LSASS process memory is protected from unauthorized access, such as enabling Credential Guard if applicable.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring and alerting for similar suspicious activities, focusing on process creation events involving LSASS, to improve early detection of future attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/credential_access_wbadmin_ntds.toml b/rules/windows/credential_access_wbadmin_ntds.toml
index efc78263512..600faf981a8 100644
--- a/rules/windows/credential_access_wbadmin_ntds.toml
+++ b/rules/windows/credential_access_wbadmin_ntds.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,40 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and 
      process.args : "recovery" and process.command_line : "*ntds.dit*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 NTDS Dump via Wbadmin
+
+Wbadmin is a Windows utility for backup and recovery, often used by administrators to safeguard critical data. However, adversaries with sufficient privileges, such as those in the Backup Operators group, can exploit it to access the NTDS.dit file on domain controllers, which contains sensitive credential information. The detection rule identifies suspicious use of wbadmin by monitoring for its execution with specific arguments related to NTDS.dit, helping to flag potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of wbadmin.exe with the specific arguments related to NTDS.dit, as indicated by the process.command_line field.
+- Check the user account associated with the process execution to determine if it belongs to a privileged group such as Backup Operators, which could indicate potential misuse of privileges.
+- Investigate the source host identified by host.os.type to determine if it is a domain controller, as this would be a critical factor in assessing the risk of the activity.
+- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+- Examine recent changes or access attempts to the NTDS.dit file on the domain controller to identify any unauthorized access or modifications.
+- Assess the risk score and severity level to prioritize the investigation and determine if immediate response actions are necessary.
+
+### False positive analysis
+
+- Scheduled backups by legitimate IT staff can trigger the rule. Verify the identity and role of the user executing wbadmin and consider excluding known backup schedules from detection.
+- Automated recovery processes in disaster recovery plans might use wbadmin with similar arguments. Review and whitelist these processes if they are part of approved recovery procedures.
+- Security audits or compliance checks may involve accessing NTDS.dit for validation purposes. Confirm the legitimacy of these activities and exclude them if they are part of regular audits.
+- Test environments that mimic production setups might execute similar commands. Ensure these environments are properly documented and excluded from detection if they are used for testing purposes.
+
+### Response and remediation
+
+- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or data exfiltration.
+- Revoke any suspicious or unauthorized accounts from the Backup Operators group and review all accounts with elevated privileges for legitimacy.
+- Conduct a thorough review of recent backup and recovery operations on the affected domain controller to identify any unauthorized access or data manipulation.
+- Change all domain administrator and service account passwords to mitigate potential credential compromise.
+- Restore the NTDS.dit file from a known good backup if any unauthorized modifications are detected.
+- Implement enhanced monitoring and logging for wbadmin.exe usage across all domain controllers to detect future unauthorized access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_cve_2020_0601.toml b/rules/windows/defense_evasion_cve_2020_0601.toml
index c5462af0a0c..8b967a1007c 100644
--- a/rules/windows/defense_evasion_cve_2020_0601.toml
+++ b/rules/windows/defense_evasion_cve_2020_0601.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/19"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,40 @@ type = "query"
 query = '''
 event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" and host.os.type:windows
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall)
+
+The Windows CryptoAPI is crucial for validating ECC certificates, ensuring secure communications and software authenticity. CVE-2020-0601, known as CurveBall, exposes a flaw where attackers can craft fake certificates, misleading systems into trusting malicious software. The detection rule identifies exploitation attempts by monitoring specific event logs and messages linked to this vulnerability, focusing on defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the event logs filtered by event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" to identify the specific instances of the vulnerability being triggered.
+- Analyze the host.os.type:windows field to determine which Windows systems are affected and prioritize them based on their criticality and exposure.
+- Examine the details of the spoofed certificates involved in the alert to understand the scope and potential impact of the attack.
+- Investigate any associated processes or executables that were signed with the spoofed certificates to assess if malicious software was executed.
+- Check for any recent changes or updates to Crypt32.dll on the affected systems to ensure they are patched against CVE-2020-0601.
+- Correlate the findings with other security events or alerts to identify any patterns or additional indicators of compromise related to defense evasion tactics.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger alerts if they use ECC certificates similar to those exploited in the vulnerability. Users can create exceptions for known trusted software vendors to reduce noise.
+- Internal testing environments that simulate certificate validation processes might generate false positives. Exclude these environments from monitoring or adjust the rule to ignore specific test-related events.
+- Security tools or scripts that perform certificate validation checks could inadvertently match the detection criteria. Identify and whitelist these tools to prevent unnecessary alerts.
+- Regular system maintenance activities involving certificate updates might be flagged. Schedule these activities during known maintenance windows and temporarily adjust monitoring rules to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further exploitation or spread of malicious software.
+- Revoke any certificates identified as spoofed or compromised and update the certificate trust list to prevent future misuse.
+- Apply the latest security patches from Microsoft to all affected systems to address the CVE-2020-0601 vulnerability.
+- Conduct a thorough scan of the isolated systems using updated antivirus and endpoint detection tools to identify and remove any malicious software.
+- Review and update endpoint protection configurations to ensure they are set to detect and block similar spoofing attempts.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems may be affected.
+- Implement enhanced monitoring for signs of defense evasion tactics, focusing on event logs and messages related to certificate validation processes."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_disable_nla.toml b/rules/windows/defense_evasion_disable_nla.toml
index 817b3ffbd14..15c618a2f52 100644
--- a/rules/windows/defense_evasion_disable_nla.toml
+++ b/rules/windows/defense_evasion_disable_nla.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/25"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,39 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
     "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication"
   ) and registry.data.strings :  ("0", "0x00000000")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network-Level Authentication (NLA) Disabled
+
+Network-Level Authentication (NLA) enhances security for Remote Desktop Protocol (RDP) by requiring user authentication before establishing a session. Adversaries may disable NLA to exploit vulnerabilities at the Windows sign-in screen, bypassing authentication for persistence tactics. The detection rule identifies registry changes that disable NLA, signaling potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the registry event logs to confirm the modification of the UserAuthentication value in the specified registry paths, ensuring the change was not part of a legitimate administrative action.
+- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information.
+- Check for any recent Remote Desktop Protocol (RDP) connection attempts or sessions on the affected host to determine if unauthorized access was achieved following the NLA disablement.
+- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections.
+- Assess the host for signs of persistence mechanisms, particularly those leveraging Accessibility Features like Sticky Keys, which may have been enabled following the NLA disablement.
+- Evaluate the security posture of the affected system, including patch levels and existing security controls, to identify potential vulnerabilities that could have been exploited.
+
+### False positive analysis
+
+- Administrative changes to RDP settings can trigger false positives when IT personnel intentionally modify registry settings for legitimate purposes. To handle this, create exceptions for known administrative activities by documenting and excluding these specific registry changes from alerts.
+- Software updates or installations that modify RDP settings might be flagged as false positives. To mitigate this, maintain a list of trusted software and their expected registry changes, and configure the detection system to ignore these during update windows.
+- Automated scripts or management tools that adjust RDP configurations for compliance or performance reasons can also cause false positives. Identify these tools and their expected behavior, then set up exclusions for their registry modifications to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Re-enable Network-Level Authentication (NLA) on the affected system by modifying the registry value back to its secure state, ensuring that "UserAuthentication" is set to "1" or "0x00000001".
+- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled.
+- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise.
+- 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 enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities.
+- Review and update endpoint security policies to ensure that registry changes related to NLA are monitored and alerts are generated for any unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_dns_over_https_enabled.toml b/rules/windows/defense_evasion_dns_over_https_enabled.toml
index 9bb21c0aa79..6d5021af34f 100644
--- a/rules/windows/defense_evasion_dns_over_https_enabled.toml
+++ b/rules/windows/defense_evasion_dns_over_https_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,39 @@ registry where host.os.type == "windows" and event.type == "change" and
   (registry.path : "*\\SOFTWARE\\Policies\\Mozilla\\Firefox\\DNSOverHTTPS" and
   registry.data.strings : ("1", "0x00000001"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 DNS-over-HTTPS Enabled via Registry
+
+DNS-over-HTTPS (DoH) encrypts DNS queries to enhance privacy and security, preventing eavesdropping and manipulation. However, adversaries can exploit DoH to conceal malicious activities, such as data exfiltration, by bypassing traditional DNS monitoring. The detection rule identifies registry changes enabling DoH in browsers like Edge, Chrome, and Firefox, signaling potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the registry path and data values from the alert to determine which browser and setting were modified. Check if the change aligns with known user activity or policy.
+- Investigate the user account associated with the registry change to assess if the activity is expected or if the account has a history of suspicious behavior.
+- Examine recent network traffic from the host to identify any unusual or unauthorized DNS queries that could indicate data exfiltration or other malicious activities.
+- Check for any other recent registry changes or system modifications on the host that might suggest further attempts at defense evasion or persistence.
+- Correlate the alert with other security events or logs from the same host or user to identify patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Legitimate software updates or installations may enable DNS-over-HTTPS settings in browsers. Monitor software update schedules and correlate registry changes with known update events to identify benign changes.
+- Organizational policies might require DNS-over-HTTPS for privacy compliance. Document these policies and create exceptions in the detection rule for systems where this is a known requirement.
+- User-initiated privacy settings changes can trigger the rule. Educate users on the implications of enabling DNS-over-HTTPS and establish a process for them to report intentional changes, allowing for exclusion of these events.
+- Security tools or privacy-focused applications may enable DNS-over-HTTPS as part of their functionality. Identify these tools within the organization and adjust the detection rule to exclude registry changes associated with their operation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential data exfiltration or further malicious activity.
+- Review and revert any unauthorized registry changes related to DNS-over-HTTPS settings in Edge, Chrome, and Firefox to restore standard DNS monitoring capabilities.
+- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any malicious software or scripts.
+- Analyze network traffic logs to identify any unusual or unauthorized DNS queries or data transfers that may have occurred during the period of DoH activation.
+- 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 enhanced monitoring for registry changes related to DNS settings across the organization to detect similar threats in the future.
+- Review and update security policies to ensure that DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
index f0b273d90e7..dc3a7a6f4c6 100644
--- a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
+++ b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,41 @@ process where host.os.type == "windows" and event.type == "start" and
   process.name : ("csc.exe", "vbc.exe") and
   process.parent.name : ("wscript.exe", "mshta.exe", "cscript.exe", "wmic.exe", "svchost.exe", "rundll32.exe", "cmstp.exe", "regsvr32.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious .NET Code Compilation
+
+.NET compilers like `csc.exe` and `vbc.exe` are integral to compiling C# and VB.NET code, respectively, in Windows environments. Adversaries exploit these compilers by executing them with unusual parent processes, such as scripting engines or system utilities, to compile malicious code stealthily. The detection rule identifies such anomalies by monitoring compiler executions initiated by suspicious parent processes, signaling potential evasion or execution tactics.
+
+### Possible investigation steps
+
+- Review the process tree to understand the relationship between the suspicious parent process (e.g., wscript.exe, mshta.exe) and the .NET compiler process (csc.exe or vbc.exe) to determine if the execution flow is typical or anomalous.
+- Examine the command-line arguments used by the .NET compiler process to identify any potentially malicious code or scripts being compiled.
+- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
+- Investigate the source and integrity of the parent process executable to ensure it has not been tampered with or replaced by a malicious version.
+- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise.
+- Analyze network activity from the host around the time of the alert to detect any suspicious outbound connections that may indicate data exfiltration or command-and-control communication.
+
+### False positive analysis
+
+- Legitimate software development activities may trigger this rule if developers use scripting engines or system utilities to automate the compilation of .NET code. To manage this, identify and whitelist known development environments or scripts that frequently compile code using these methods.
+- System administrators might use scripts or automation tools that invoke .NET compilers for maintenance tasks. Review and document these processes, then create exceptions for recognized administrative scripts to prevent unnecessary alerts.
+- Some enterprise applications may use .NET compilers as part of their normal operation, especially if they dynamically generate or compile code. Investigate these applications and exclude their processes from the rule if they are verified as non-threatening.
+- Security tools or monitoring solutions might simulate suspicious behavior for testing purposes, which could trigger this rule. Coordinate with your security team to identify such tools and exclude their activities from detection.
+- In environments where custom scripts are frequently used for deployment or configuration, ensure these scripts are reviewed and, if safe, added to an exclusion list to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution or spread of potentially malicious code.
+- Terminate any suspicious processes identified, such as `csc.exe` or `vbc.exe`, that are running with unusual parent processes.
+- Conduct a thorough scan of the isolated system using updated antivirus and endpoint detection tools to identify and remove any malicious files or remnants.
+- Review and analyze the execution logs to determine the source and scope of the threat, focusing on the parent processes like `wscript.exe` or `mshta.exe` that initiated the compiler execution.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning.
+- Implement application whitelisting to prevent unauthorized execution of compilers and scripting engines by non-standard parent processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
index 24186a5e8cd..d5221ca2f18 100644
--- a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
+++ b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/08"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,41 @@ process where host.os.type == "windows" and event.type == "start" and
     "*\\AppData\\Local\\*"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Control Panel Process with Unusual Arguments
+
+The Control Panel in Windows is a system utility that allows users to view and adjust system settings. Adversaries may exploit this by using control.exe to execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies in command-line arguments, such as unexpected file types or suspicious paths, which may indicate an attempt to evade defenses or execute unauthorized actions.
+
+### Possible investigation steps
+
+- Review the command line arguments of the control.exe process to identify any unusual file types or suspicious paths, such as image file extensions or paths like */AppData/Local/*.
+- Check the parent process of control.exe to determine if it was spawned by a legitimate application or a potentially malicious one.
+- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine recent file modifications or creations in directories like \\AppData\\Local\\ or \\Users\\Public\\ to identify any unauthorized or unexpected changes.
+- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context on the potential threat.
+- Assess the network activity of the host during the time of the alert to identify any unusual outbound connections that may indicate data exfiltration or command and control communication.
+
+### False positive analysis
+
+- Image file paths in command-line arguments may trigger false positives if users or applications are legitimately accessing image files through control.exe. To mitigate this, create exceptions for known applications or user activities that frequently access image files.
+- Paths involving AppData or Users\\Public directories might be flagged if legitimate software installations or updates use these locations. Review and whitelist specific software processes that are known to use these directories for legitimate purposes.
+- Relative path traversal patterns like ../../.. could be used by legitimate scripts or applications for configuration purposes. Identify and exclude these scripts or applications from the detection rule if they are verified as non-malicious.
+- Frequent use of control.exe with specific command-line arguments by system administrators or IT personnel for legitimate system management tasks can be excluded by creating user-based exceptions for these roles.
+- If certain security tools or monitoring software are known to trigger this rule due to their operational behavior, consider excluding these tools after confirming their legitimacy and necessity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the suspicious control.exe process to stop any ongoing malicious execution.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.
+- Review and clean up any unauthorized changes or files in the directories specified in the alert, such as AppData/Local or Users/Public, to ensure no persistence mechanisms remain.
+- Restore any affected files or system settings from a known good backup to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement additional monitoring and alerting for similar command-line anomalies to enhance detection and prevent recurrence of this threat."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
index bb5c221efa9..e251faec73c 100755
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,41 @@ host.os.type:windows and event.category:process and event.type:start and (
   process.parent.name:("cmd.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "cscript.exe" or
     "wscript.exe" or "mshta.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft Build Engine Started by a Script Process
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit its ability to execute inline tasks, using it as a proxy for executing malicious code. The detection rule identifies unusual MSBuild invocations initiated by script interpreters, signaling potential misuse for stealthy execution or defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on the parent process names such as cmd.exe, powershell.exe, pwsh.exe, powershell_ise.exe, cscript.exe, wscript.exe, or mshta.exe, which initiated the msbuild.exe process.
+- Examine the command line arguments used to start msbuild.exe to identify any suspicious or unusual inline tasks or scripts that may indicate malicious activity.
+- Check the user account associated with the msbuild.exe process to determine if it aligns with expected usage patterns or if it might be compromised.
+- Investigate the timing and frequency of the msbuild.exe execution to see if it coincides with known legitimate build activities or if it appears anomalous.
+- Look for any related network activity or file modifications around the time of the msbuild.exe execution to identify potential data exfiltration or further malicious actions.
+- Cross-reference the alert with other security events or logs to identify any correlated indicators of compromise or additional suspicious behavior.
+
+### False positive analysis
+
+- Development environments where scripts are used to automate builds may trigger this rule. To manage this, identify and whitelist specific script processes or directories commonly used by developers.
+- Automated testing frameworks that utilize scripts to initiate builds can cause false positives. Exclude these processes by creating exceptions for known testing tools and their associated scripts.
+- Continuous integration/continuous deployment (CI/CD) pipelines often use scripts to invoke MSBuild. Consider excluding the parent processes associated with these pipelines from the rule.
+- Administrative scripts that perform legitimate system maintenance tasks might start MSBuild. Review and exclude these scripts if they are verified as non-threatening.
+- Custom scripts developed in-house for specific business functions may also trigger alerts. Conduct a review of these scripts and exclude them if they are deemed safe and necessary for operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the suspicious MSBuild process and any associated script interpreter processes (e.g., cmd.exe, powershell.exe) to stop the execution of potentially malicious code.
+- 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 artifacts.
+- Review and analyze the parent script or command that initiated the MSBuild process to understand the scope and intent of the attack, and identify any additional compromised systems or accounts.
+- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access.
+- 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 enhanced monitoring and logging for MSBuild and script interpreter activities across the network to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
index 3478af63413..664cec790d5 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,41 @@ process where host.os.type == "windows" and event.type == "start" and
   process.name : "MSBuild.exe" and
   process.parent.name : ("explorer.exe", "wmiprvse.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft Build Engine Started by a System Process
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit it to execute malicious code, leveraging its trusted status to bypass security measures. The detection rule identifies unusual MSBuild activity initiated by system processes like Explorer or WMI, which may indicate an attempt to evade defenses and execute unauthorized actions.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on instances where MSBuild.exe is started by explorer.exe or wmiprvse.exe.
+- Check the command line arguments used to start MSBuild.exe for any suspicious or unusual parameters that could indicate malicious activity.
+- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised.
+- Examine recent file modifications or creations in directories commonly used by MSBuild to identify any unauthorized or unexpected files.
+- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context on the activity.
+- Assess the network activity of the host during the time of the alert to identify any potential data exfiltration or communication with known malicious IP addresses.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger MSBuild.exe to start from Explorer or WMI. Monitor these events and verify if they coincide with known software changes.
+- Development environments where MSBuild is frequently used might see this behavior as part of normal operations. Identify and document these environments to create exceptions for known development machines.
+- Automated scripts or administrative tools that leverage MSBuild for legitimate tasks can cause false positives. Review and whitelist these scripts or tools if they are verified as non-malicious.
+- System maintenance tasks initiated by IT personnel might use MSBuild in a manner that appears suspicious. Coordinate with IT to understand routine maintenance activities and exclude them from alerts.
+- Security software or monitoring tools that interact with MSBuild for scanning or analysis purposes should be identified and excluded from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the MSBuild.exe process if it is confirmed to be executing unauthorized or malicious code.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or associated files.
+- Review and analyze the parent processes (explorer.exe or wmiprvse.exe) to determine if they have been compromised or are executing other suspicious activities.
+- Restore the system from a known good backup if any critical system files or applications have been altered or corrupted.
+- 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 enhanced monitoring and logging for MSBuild.exe and related processes to detect similar activities in the future, ensuring alerts are configured for rapid response."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
index 0e0e298687a..79a9580145d 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,41 @@ query = '''
 host.os.type:windows and event.category:process and event.type:start and process.parent.name:("MSBuild.exe" or "msbuild.exe") and
 process.name:("csc.exe" or "iexplore.exe" or "powershell.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft Build Engine Started an Unusual Process
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries may exploit MSBuild to execute malicious scripts or compile code, bypassing security controls. The detection rule identifies unusual processes initiated by MSBuild, such as PowerShell or C# compiler, signaling potential misuse for executing unauthorized or harmful actions.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on MSBuild.exe or msbuild.exe as the parent process and any unusual child processes like csc.exe, iexplore.exe, or powershell.exe.
+- Examine the command line arguments used by the unusual process to identify any suspicious or malicious scripts or commands being executed.
+- Check the user account associated with the process to determine if it aligns with expected usage patterns or if it might be compromised.
+- Investigate the source and integrity of the MSBuild project file (.proj or .sln) to ensure it hasn't been tampered with or used to execute unauthorized code.
+- Analyze recent changes or deployments in the environment that might explain the unusual process execution, such as new software installations or updates.
+- Correlate this event with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack.
+
+### False positive analysis
+
+- Development environments often use MSBuild to execute legitimate PowerShell scripts or compile C# code. Regularly review and whitelist known development processes to prevent unnecessary alerts.
+- Automated build systems may trigger this rule when running scripts or compiling code as part of their normal operation. Identify and exclude these systems by their hostnames or IP addresses.
+- Some software installations or updates might use MSBuild to execute scripts. Monitor and document these activities, and create exceptions for recognized software vendors.
+- Internal tools or scripts that rely on MSBuild for execution should be cataloged. Establish a baseline of expected behavior and exclude these from triggering alerts.
+- Collaborate with development teams to understand their use of MSBuild and adjust the detection rule to accommodate their workflows without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of potentially malicious processes and lateral movement.
+- Terminate any suspicious processes initiated by MSBuild, such as PowerShell or the C# compiler, to halt any ongoing malicious activity.
+- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious files, focusing on scripts or executables that may have been deployed.
+- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring and logging for MSBuild and related processes to detect any future misuse or anomalies promptly.
+- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats, ensuring that security controls are effectively blocking unauthorized script execution."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
index 17ca6cfd018..1779dcff668 100644
--- a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
+++ b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,41 @@ process where host.os.type == "windows" and event.type == "start" and
                                "?:\\Windows\\System32\\inetsrv\\w3wp.exe")
          )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential DLL Side-Loading via Trusted Microsoft Programs
+
+DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs, evading detection. The detection rule identifies unusual execution paths or renamed instances of these programs, signaling potential misuse and enabling timely threat response.
+
+### Possible investigation steps
+
+- Review the process details to confirm the original file name and the path from which the process was executed. Check if the process.pe.original_file_name matches any of the specified trusted programs like "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", or "DISM.EXE".
+- Investigate the process execution path to determine if it deviates from the standard paths listed in the query, such as "?:\\Windows\\explorer.exe" or "?:\\Program Files\\Microsoft Office\\root\\Office*\\WINWORD.EXE".
+- Examine the process creation history and parent process to identify any unusual or suspicious parent-child relationships that might indicate malicious activity.
+- Check for any recent file modifications or creations in the directory from which the process was executed, which could suggest the presence of a malicious DLL.
+- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify potential patterns of malicious behavior.
+- Assess the risk and impact of the event by considering the risk score and severity level provided, and determine if immediate containment or further investigation is necessary.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths. Users can create exceptions for known update processes to prevent false alerts.
+- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes. Identify and whitelist these specific applications to avoid unnecessary alerts.
+- Virtual environments or sandboxed applications may execute trusted programs from unusual paths as part of their normal operation. Review and exclude these environments if they are known and trusted.
+- Security or IT administrative tools might mimic trusted Microsoft programs for monitoring or management tasks. Verify these tools and add them to an exception list if they are part of standard operations.
+- Development or testing environments often involve renamed or relocated executables for debugging purposes. Ensure these environments are recognized and excluded from the detection rule to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and unauthorized access.
+- Terminate the suspicious process identified by the detection rule to stop any ongoing malicious activity.
+- Conduct a forensic analysis of the affected system to identify any malicious DLLs or additional compromised files, and remove them.
+- Restore the affected system from a known good backup to ensure all malicious changes are reverted.
+- Update and patch all software on the affected system, focusing on the trusted Microsoft programs identified in the alert, to mitigate vulnerabilities exploited by DLL side-loading.
+- Monitor the network for any signs of lateral movement or additional compromised systems, using the indicators of compromise identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or data have been affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
index c46c13405b5..cccb6701f31 100644
--- a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
+++ b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/07"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,39 @@ process where host.os.type == "windows" and event.type == "start" and
                               "?:\\Program Files (x86)\\Microsoft Security Client\\*.exe"))
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential DLL Side-Loading via Microsoft Antimalware Service Executable
+
+The Microsoft Antimalware Service Executable, a core component of Windows Defender, is crucial for real-time protection against malware. Adversaries exploit its trust by renaming it or executing it from non-standard paths to load malicious DLLs, bypassing security measures. The detection rule identifies such anomalies by monitoring process names and paths, flagging deviations from expected behavior to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm if the process name is MsMpEng.exe but is executing from a non-standard path. Check the process.executable field to identify the exact path and verify if it deviates from the expected directories.
+- Investigate the parent process of the suspicious MsMpEng.exe instance to determine how it was initiated. This can provide insights into whether the process was started by a legitimate application or a potentially malicious one.
+- Examine the system for any recent file modifications or creations in the directory where the suspicious MsMpEng.exe is located. This can help identify if a malicious DLL was recently placed in the same directory.
+- Check for any network connections or communications initiated by the suspicious MsMpEng.exe process. This can help determine if the process is attempting to communicate with external servers, which may indicate malicious activity.
+- Look for any other processes or activities on the host that may indicate compromise, such as unusual user account activity or other processes running from unexpected locations. This can help assess the broader impact of the potential threat.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily rename or relocate the Microsoft Antimalware Service Executable. Users should verify if any software updates or installations occurred around the time of the alert and consider excluding these paths if they are known and trusted.
+- Custom security or IT management tools might execute the executable from non-standard paths for monitoring or testing purposes. Confirm with IT or security teams if such tools are in use and add these paths to the exclusion list if they are verified as safe.
+- Virtualization or sandbox environments may replicate the executable in different locations for testing or analysis. Check if the environment is part of a controlled setup and exclude these paths if they are part of legitimate operations.
+- Backup or recovery processes might involve copying the executable to alternate locations. Ensure these processes are legitimate and consider excluding these paths if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving MsMpEng.exe running from non-standard paths.
+- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious DLLs or other malware.
+- Review and restore any altered or deleted system files from a known good backup to ensure system integrity.
+- Investigate the source of the DLL side-loading attempt to determine if it was part of a broader attack campaign, and gather forensic evidence for further analysis.
+- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to assess the need for further containment measures.
+- Implement additional monitoring and alerting for similar anomalies in process execution paths to enhance detection capabilities and prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_file_creation_mult_extension.toml b/rules/windows/defense_evasion_file_creation_mult_extension.toml
index b3b03816550..62a852d1053 100644
--- a/rules/windows/defense_evasion_file_creation_mult_extension.toml
+++ b/rules/windows/defense_evasion_file_creation_mult_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,40 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten
   not (process.executable : ("?:\\Windows\\System32\\msiexec.exe", "C:\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe") and
        file.path : "?:\\Program Files\\QGIS *\\apps\\grass\\*.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Executable File Creation with Multiple Extensions
+
+In Windows environments, adversaries may exploit file extensions to disguise malicious executables as benign files, such as documents or images, by appending multiple extensions. This tactic, known as masquerading, aims to deceive users and evade security measures. The detection rule identifies suspicious file creations by monitoring for executables with misleading extensions, excluding known legitimate processes, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the file creation event details to identify the full file path and name, focusing on the extensions used to determine if they match the suspicious pattern outlined in the query.
+- Investigate the process that created the file by examining the process.executable field to determine if it is a known legitimate process or potentially malicious.
+- Check the file's origin by analyzing the user account and network activity associated with the file creation event to identify any unusual or unauthorized access patterns.
+- Utilize threat intelligence sources to assess if the file hash or any related indicators of compromise (IOCs) are known to be associated with malicious activity.
+- Examine the file's metadata and properties to verify its authenticity and check for any signs of tampering or unusual characteristics.
+- Conduct a behavioral analysis of the file in a controlled environment to observe any malicious actions or network communications it may attempt.
+
+### False positive analysis
+
+- Legitimate software installations may create executables with multiple extensions during setup processes. Users can exclude these by adding exceptions for known installer paths, such as "C:\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe".
+- System updates or patches might temporarily create files with multiple extensions. Monitor and verify these activities, and if confirmed as legitimate, add exceptions for the specific update processes.
+- Development environments or script-based applications may generate files with multiple extensions for testing purposes. Identify these environments and exclude their specific file paths or processes to prevent false positives.
+- Security tools or administrative scripts might use multiple extensions for legitimate purposes. Review and whitelist these tools by their executable paths or process names to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate any suspicious processes associated with the masquerading executable files to halt any ongoing malicious actions.
+- Quarantine the identified files with multiple extensions to prevent execution and further analysis.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats.
+- Review and restore any altered system configurations or files to their original state to ensure system integrity.
+- 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 enhanced monitoring and logging for similar file creation activities to improve detection and response capabilities for future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
index 25ed246466d..34404a28ec3 100644
--- a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
+++ b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,40 @@ registry where host.os.type == "windows" and
 /* update here with encoding combinations */
  registry.data.strings : "TVqQAAMAAAAEAAAA*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Encoded Executable Stored in the Registry
+
+Windows Registry is a hierarchical database storing low-level settings for the OS and applications. Adversaries exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications, specifically targeting encoded patterns indicative of hidden executables, thus flagging potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the registry path and key where the modification was detected to understand the context and potential impact on the system.
+- Analyze the encoded data string "TVqQAAMAAAAEAAAA*" to determine if it corresponds to a known malicious executable or pattern.
+- Check the modification timestamp to correlate with any other suspicious activities or events on the system around the same time.
+- Investigate the process or user account responsible for the registry modification to assess if it is associated with legitimate activity or known threats.
+- Cross-reference the alert with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne for additional context or corroborating evidence of malicious behavior.
+- Evaluate the system's network activity and connections during the time of the registry modification to identify any potential command and control communications or data exfiltration attempts.
+
+### False positive analysis
+
+- Legitimate software installations or updates may write encoded executables to the registry as part of their normal operation. Users can create exceptions for known software by identifying their specific registry paths and excluding them from the detection rule.
+- Security tools and system management software might store encoded data in the registry for legitimate purposes. Review the registry paths and data associated with these tools and exclude them if they are verified as non-threatening.
+- Custom scripts or enterprise applications developed in-house may use encoded executables in the registry for deployment or configuration purposes. Work with development teams to identify these scripts and add exceptions for their registry modifications.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking potential threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the encoded executable.
+- Remove the malicious registry entry by using a trusted registry editor or automated script to ensure the encoded executable is no longer stored in the registry.
+- Conduct a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning.
+- Monitor the system and network for any signs of re-infection or similar registry modifications, adjusting detection rules if necessary to enhance future threat identification.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_injection_msbuild.toml b/rules/windows/defense_evasion_injection_msbuild.toml
index d89f796cde2..41c8747ec4d 100755
--- a/rules/windows/defense_evasion_injection_msbuild.toml
+++ b/rules/windows/defense_evasion_injection_msbuild.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,42 @@ query = '''
 process where host.os.type == "windows" and process.name: "MSBuild.exe" and
     event.action:("CreateRemoteThread detected (rule: CreateRemoteThread)", "CreateRemoteThread")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Injection by the Microsoft Build Engine
+
+The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries exploit MSBuild to perform process injection, a technique to execute malicious code within the address space of another process, thereby evading detection and potentially escalating privileges. The detection rule identifies suspicious MSBuild activity by monitoring for thread creation in other processes, leveraging Sysmon data to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the alert details to confirm that the process name is "MSBuild.exe" and the event action is "CreateRemoteThread detected (rule: CreateRemoteThread)".
+- Examine the parent process of MSBuild.exe to determine if it was launched by a legitimate application or user, which could indicate whether the activity is expected or suspicious.
+- Check the timeline of events to see if there are any other related alerts or activities around the same time, such as unusual network connections or file modifications, which could provide additional context.
+- Investigate the target process where the thread was created to assess its normal behavior and determine if it is a common target for injection or if it has been compromised.
+- Analyze the command line arguments used to launch MSBuild.exe to identify any unusual or suspicious parameters that could indicate malicious intent.
+- Review the user account associated with the MSBuild.exe process to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Consult threat intelligence sources to check if there are any known campaigns or malware that utilize MSBuild for process injection, which could help in understanding the potential threat actor or objective.
+
+### False positive analysis
+
+- Development environments often use MSBuild for legitimate purposes, which can trigger false positives. Users should monitor and establish a baseline of normal MSBuild activity to differentiate between benign and suspicious behavior.
+- Automated build systems may frequently invoke MSBuild, leading to false positives. Consider excluding known build server IP addresses or specific user accounts associated with these systems from the detection rule.
+- Some legitimate software may use MSBuild for plugin or extension loading, which could appear as process injection. Identify and whitelist these applications by their process hashes or paths to reduce noise.
+- Regular updates or installations of software development tools might cause MSBuild to create threads in other processes. Temporarily disable the rule during scheduled maintenance windows to prevent unnecessary alerts.
+- Collaborate with development teams to understand their use of MSBuild and adjust the detection rule to exclude known safe operations, ensuring that only unexpected or unauthorized uses are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the MSBuild.exe process if it is confirmed to be involved in unauthorized thread creation, using task management tools or scripts.
+- Conduct a memory analysis on the affected system to identify and extract any injected code or payloads for further investigation.
+- Review and restore any altered or compromised system files and configurations to their original state using known good backups.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the intrusion.
+- Implement application whitelisting to prevent unauthorized execution of MSBuild.exe or similar tools in non-development environments.
+- Enhance monitoring and detection capabilities by ensuring Sysmon is configured to log detailed process creation and thread injection events across the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_installutil_beacon.toml b/rules/windows/defense_evasion_installutil_beacon.toml
index 6abd0388863..b32862e2dcf 100644
--- a/rules/windows/defense_evasion_installutil_beacon.toml
+++ b/rules/windows/defense_evasion_installutil_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,41 @@ 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")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
index ff5cb36de8a..4aca06bb77a 100644
--- a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
+++ b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,40 @@ process where host.os.type == "windows" and event.type == "start" and
         "\\Device\\HarddiskVolume?\\Program Files\\*\\cdb.exe"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution via Windows Command Debugging Utility
+
+The Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. The detection rule identifies suspicious use of cdb.exe by monitoring its execution outside standard installation paths and specific command-line arguments, indicating potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of cdb.exe running from non-standard paths, as specified in the query.
+- Examine the command-line arguments used with cdb.exe, particularly looking for "-cf", "-c", or "-pd", to understand the potential actions or scripts being executed.
+- Investigate the parent process of cdb.exe to determine how it was launched and identify any associated suspicious activity or processes.
+- Check the user account associated with the cdb.exe execution to assess if it aligns with expected behavior or if it indicates potential compromise.
+- Analyze recent system logs and security alerts for any related or preceding suspicious activities that might correlate with the execution of cdb.exe.
+- Review network activity from the host to identify any unusual outbound connections that could suggest data exfiltration or command-and-control communication.
+
+### False positive analysis
+
+- Legitimate debugging activities by developers or IT staff using cdb.exe outside standard paths can trigger alerts. To manage this, create exceptions for known user accounts or specific machines frequently used for development.
+- Automated testing environments may execute cdb.exe with command-line arguments for legitimate purposes. Identify these environments and exclude their processes from triggering alerts.
+- Software installations or updates might temporarily use cdb.exe in non-standard paths. Monitor installation logs and exclude these specific instances if they are verified as part of legitimate software deployment.
+- Security tools or scripts that leverage cdb.exe for monitoring or analysis can be mistaken for malicious activity. Document these tools and add them to the exclusion list to prevent false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
+- Terminate any suspicious instances of cdb.exe running outside the standard installation paths to halt potential malicious activity.
+- Conduct a forensic analysis of the affected system to identify any unauthorized changes or additional malicious payloads that may have been executed.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is clean and uncompromised.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement application whitelisting to prevent unauthorized execution of cdb.exe from non-standard paths.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
index 2aa5a43e6fe..b6177118795 100644
--- a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
+++ b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -71,6 +71,41 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Endpoint Security Parent Process
+
+Endpoint security solutions, like Elastic and Microsoft Defender, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes to evade detection. The detection rule identifies anomalies by flagging unexpected parent processes of security executables, excluding known benign paths and arguments, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process details for the flagged executable (e.g., esensor.exe or elastic-endpoint.exe) to understand its expected behavior and any recent changes in its configuration or deployment.
+- Examine the parent process executable path and name to determine if it is a known legitimate process or potentially malicious. Pay special attention to paths not listed in the known benign paths, such as those outside "?:\\Program Files\\Elastic\\*" or "?:\\Windows\\System32\\*".
+- Investigate the command-line arguments used by the parent process to identify any unusual or suspicious patterns that could indicate malicious activity, especially if they do not match the benign arguments like "test", "version", or "status".
+- Check the historical activity of the parent process to see if it has been involved in other suspicious activities or if it has a history of spawning security-related processes.
+- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender for Endpoint, or Sysmon to gather additional context and identify any related suspicious activities.
+- Assess the risk and impact of the alert by considering the environment, the criticality of the affected systems, and any potential data exposure or operational disruption.
+
+### False positive analysis
+
+- Security tools or scripts that automate tasks may trigger false positives if they launch endpoint security processes with unexpected parent processes. To manage this, identify and document these tools, then add their parent executable paths to the exclusion list.
+- System administrators or IT personnel may use command-line tools like PowerShell or cmd.exe for legitimate maintenance tasks. If these tasks frequently trigger alerts, consider adding specific command-line arguments used in these tasks to the exclusion list.
+- Software updates or installations might temporarily cause unexpected parent processes for security executables. Monitor these activities and, if they are routine and verified, add the associated parent executable paths to the exclusion list.
+- Custom scripts or third-party applications that interact with security processes can also lead to false positives. Review these scripts or applications, and if they are deemed safe, include their parent executable paths in the exclusion list.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and operational practices, minimizing the risk of overlooking new legitimate processes.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity and prevent further code execution.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized changes or additional malicious files.
+- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised.
+- Update endpoint security solutions and apply any available patches to address vulnerabilities that may have been exploited by the adversary.
+- Monitor the network and systems for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting based on the identified threat indicators.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
index 69125b3d1b2..9baf3de0d59 100644
--- a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
+++ b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -163,6 +163,42 @@ process where host.os.type == "windows" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Masquerading as Business App Installer
+
+Business applications are integral to productivity, often downloaded and installed by users. Adversaries exploit this by creating malicious executables with names mimicking legitimate apps, tricking users into installing them. The detection rule identifies such threats by checking for unsigned executables in download directories, ensuring they don't masquerade as trusted applications.
+
+### Possible investigation steps
+
+- Review the process name and executable path to confirm if it matches any known legitimate business application names listed in the rule, such as Slack, WebEx, or Teams, and verify if it was executed from a typical download directory.
+- Check the process code signature status and subject name to determine if the executable is unsigned or signed by an untrusted entity, which could indicate a masquerading attempt.
+- Investigate the source of the download by examining browser history, email attachments, or any recent file transfers to identify potential phishing attempts or malicious download sources.
+- Analyze the process execution context, including parent processes and command-line arguments, to understand how the executable was launched and if it aligns with typical user behavior.
+- Look for any network connections initiated by the process to identify suspicious outbound traffic or connections to known malicious IP addresses or domains.
+- Cross-reference the executable's hash with threat intelligence databases to check for known malware signatures or previous reports of malicious activity.
+- If the executable is determined to be suspicious, isolate the affected system and perform a full malware scan to prevent further compromise.
+
+### False positive analysis
+
+- Unsigned executables from legitimate developers may trigger alerts if they are not properly signed or if the signature is not recognized. Users can create exceptions for specific executables by verifying the developer's authenticity and adding them to a trusted list.
+- Custom or in-house developed applications that mimic business app names but are unsigned can cause false positives. Organizations should ensure these applications are signed with a trusted certificate or add them to an exclusion list after verifying their safety.
+- Software updates or beta versions of legitimate applications might not have updated signatures, leading to false positives. Users should verify the source of the update and, if legitimate, temporarily exclude these versions from the rule.
+- Applications installed in non-standard directories that match the naming patterns but are legitimate can be excluded by specifying trusted paths or directories in the rule configuration.
+- Third-party tools or utilities that integrate with business applications and use similar naming conventions might be flagged. Users should verify these tools and, if safe, add them to an exception list to prevent future alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the suspicious process identified by the alert to stop any ongoing malicious actions.
+- Quarantine the executable file flagged by the detection rule to prevent execution and further analysis.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants.
+- Review and analyze the process execution logs and any related network activity to understand the scope of the intrusion and identify any other potentially compromised systems.
+- 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 application whitelisting to prevent unauthorized executables from running, ensuring only trusted and signed applications are allowed to execute."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_communication_apps.toml b/rules/windows/defense_evasion_masquerading_communication_apps.toml
index 27f59a47cb9..6a8fa9e23ad 100644
--- a/rules/windows/defense_evasion_masquerading_communication_apps.toml
+++ b/rules/windows/defense_evasion_masquerading_communication_apps.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -90,6 +90,41 @@ process where host.os.type == "windows" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Masquerading as Communication Apps
+
+Communication apps are integral to modern workflows, facilitating seamless interaction. However, adversaries can exploit these apps by masquerading malicious processes as legitimate ones, bypassing security measures and deceiving users. The detection rule identifies suspicious instances by checking for unsigned or improperly signed processes, ensuring they match known trusted signatures. This helps in flagging potential threats that mimic trusted communication tools, aiding in defense evasion detection.
+
+### Possible investigation steps
+
+- Review the process name and code signature details to confirm if the process is indeed masquerading as a legitimate communication app. Check if the process name matches any of the specified apps like slack.exe, WebexHost.exe, etc., and verify the code signature subject name and trust status.
+- Investigate the origin of the executable file by checking its file path and creation date. Determine if it was recently added or modified, which might indicate suspicious activity.
+- Analyze the parent process to understand how the suspicious process was initiated. This can provide insights into whether it was launched by a legitimate application or a potentially malicious script or program.
+- Check for any network connections initiated by the suspicious process. Look for unusual or unauthorized external connections that might suggest data exfiltration or command and control communication.
+- Review recent system logs and security alerts for any related activities or anomalies that coincide with the start of the suspicious process. This can help identify if the process is part of a larger attack pattern.
+- Consult threat intelligence sources to see if there are any known indicators of compromise (IOCs) associated with the process or its hash value, which can help in assessing the threat level.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily result in unsigned or improperly signed processes. Users can create exceptions for known update processes to prevent false positives during these periods.
+- Custom or internally developed communication tools that mimic the names of popular apps might trigger alerts. Ensure these tools are properly signed and add them to an allowlist if they are trusted.
+- Some third-party security or monitoring tools may interact with communication apps in a way that alters their signature status. Verify the legitimacy of these tools and consider excluding them from the rule if they are deemed safe.
+- In environments where communication apps are deployed via non-standard methods, such as portable versions, ensure these versions are signed correctly or add them to an exception list if they are verified as safe.
+- Temporary network issues or system misconfigurations might cause legitimate apps to appear unsigned. Regularly audit and correct any network or system issues to minimize these occurrences.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Terminate any suspicious processes identified by the detection rule that are masquerading as communication apps, ensuring they are not legitimate processes.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software.
+- Review and validate the code signatures of all communication apps on the affected system to ensure they are properly signed by trusted entities.
+- Restore any compromised systems from a known good backup to ensure the integrity of the system and data.
+- Monitor network traffic and system logs for any signs of lateral movement or further attempts to exploit communication apps.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
index c6e35d6317b..fc8a23b75c6 100644
--- a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
+++ b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ process where host.os.type == "windows" and event.type == "start" and
 
   not process.executable : ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious WerFault Child Process
+
+WerFault.exe is a Windows error reporting tool that handles application crashes. Adversaries may exploit it by manipulating the SilentProcessExit registry key to execute malicious processes stealthily. The detection rule identifies unusual child processes of WerFault.exe, focusing on specific command-line arguments indicative of this abuse, while excluding known legitimate executables, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the command line arguments of the suspicious child process to confirm the presence of "-s", "-t", and "-c" flags, which indicate potential abuse of the SilentProcessExit mechanism.
+- Examine the process executable path to ensure it is not one of the known legitimate executables ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe") that are excluded from the detection rule.
+- Investigate the network connections established by the suspicious process to identify any unusual or unauthorized external communications.
+- Analyze file writes and modifications made by the process to detect any unauthorized changes or potential indicators of compromise.
+- Check the parent process tree to understand the context of how WerFault.exe was invoked and identify any preceding suspicious activities or processes.
+- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Microsoft Defender for Endpoint, Sysmon, or SentinelOne to gather additional context and assess the scope of the potential threat.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger WerFault.exe with command-line arguments similar to those used in the SilentProcessExit mechanism. Users should verify the digital signature of the executable and check if it aligns with known update processes.
+- Security software or system management tools might use WerFault.exe for legitimate purposes. Users can create exceptions for these known tools by adding their executables to the exclusion list in the detection rule.
+- Custom scripts or enterprise applications that utilize WerFault.exe for error handling could be flagged. Review the process details and, if verified as non-threatening, add these scripts or applications to the exclusion list.
+- Frequent occurrences of the same process being flagged can indicate a benign pattern. Users should monitor these patterns and, if consistently verified as safe, update the rule to exclude these specific processes.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further potential malicious activity and lateral movement.
+- Terminate the suspicious child process of WerFault.exe immediately to halt any ongoing malicious actions.
+- Conduct a thorough review of the SilentProcessExit registry key to identify and remove any unauthorized entries that may have been used to execute the malicious process.
+- Restore any altered or deleted files from a known good backup to ensure system integrity and recover any lost data.
+- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats or remnants of the attack.
+- Monitor network traffic and system logs for any signs of persistence mechanisms or further attempts to exploit the SilentProcessExit mechanism.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_masquerading_trusted_directory.toml b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
index 34442a07c20..29e6592ece3 100644
--- a/rules/windows/defense_evasion_masquerading_trusted_directory.toml
+++ b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -75,6 +75,41 @@ process where host.os.type == "windows" and event.type == "start" and
       )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Program Files Directory Masquerading
+
+The Program Files directories in Windows are trusted locations for legitimate software. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures. The detection rule identifies suspicious executions from these masquerading paths, excluding known legitimate directories, to flag potential threats. This helps in identifying defense evasion tactics used by attackers.
+
+### Possible investigation steps
+
+- Review the process executable path to confirm if it matches any known masquerading patterns, such as unexpected directories containing "Program Files" in their path.
+- Check the parent process of the suspicious executable to determine how it was launched and assess if the parent process is legitimate or potentially malicious.
+- Investigate the user account associated with the process execution to determine if it has low privileges and if the activity aligns with typical user behavior.
+- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged in threat intelligence databases.
+- Assess the network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create temporary directories resembling Program Files paths. Users can monitor installation logs and exclude these specific paths if they are verified as part of a legitimate process.
+- Some enterprise applications may use custom directories that mimic Program Files for compatibility reasons. IT administrators should document these paths and add them to the exclusion list to prevent false alerts.
+- Development environments might create test directories with similar naming conventions. Developers should ensure these paths are excluded during active development phases to avoid unnecessary alerts.
+- Security tools or scripts that perform regular checks or updates might execute from non-standard directories. Verify these tools and add their execution paths to the exception list if they are confirmed safe.
+- Backup or recovery software might temporarily use directories that resemble Program Files for storing executable files. Confirm the legitimacy of these operations and exclude the paths if they are part of routine backup processes.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate any suspicious processes identified as executing from masquerading directories to halt 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 files or remnants.
+- Review and restore any altered system configurations or settings to their original state to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat or similar tactics.
+- Update security policies and access controls to prevent unauthorized creation of directories that mimic trusted paths, enhancing defenses against similar masquerading attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_mshta_beacon.toml b/rules/windows/defense_evasion_mshta_beacon.toml
index e36fa0afdba..975894325db 100644
--- a/rules/windows/defense_evasion_mshta_beacon.toml
+++ b/rules/windows/defense_evasion_mshta_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,39 @@ sequence by process.entity_id with maxspan=10m
      not process.args : "ADSelfService_Enroll.hta"]
   [network where host.os.type == "windows" and process.name : "mshta.exe"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Mshta Making Network Connections
+
+Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, leveraging its trusted status to bypass security measures. The detection rule identifies suspicious network activity by Mshta.exe, excluding known benign processes, to flag potential threats. This approach helps in identifying unauthorized network connections indicative of malicious intent.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship of mshta.exe, focusing on any unusual or unexpected parent processes that are not excluded by the rule, such as Microsoft.ConfigurationManagement.exe or known benign executables.
+- Analyze the command-line arguments used by mshta.exe to identify any suspicious or unexpected scripts being executed, especially those not matching the excluded ADSelfService_Enroll.hta.
+- Examine the network connections initiated by mshta.exe, including destination IP addresses, domains, and ports, to identify any connections to known malicious or suspicious endpoints.
+- Check for any related alerts or logs from the same host around the time of the mshta.exe activity to identify potential lateral movement or additional malicious behavior.
+- Investigate the user account associated with the mshta.exe process to determine if it has been compromised or is exhibiting unusual activity patterns.
+
+### False positive analysis
+
+- Mshta.exe may be triggered by legitimate software updates or installations, such as those from Microsoft Configuration Management. To handle this, add exceptions for processes with parent names like Microsoft.ConfigurationManagement.exe.
+- Certain applications like Amazon Assistant and TeamViewer may use Mshta.exe for legitimate purposes. Exclude these by specifying their executable paths, such as C:\\Amazon\\Amazon Assistant\\amazonAssistantService.exe and C:\\TeamViewer\\TeamViewer.exe.
+- Custom scripts or internal tools that utilize HTA files for automation might cause false positives. Identify these scripts and exclude them by their specific arguments, such as ADSelfService_Enroll.hta.
+- Regularly review and update the list of exceptions to ensure that only verified benign activities are excluded, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the mshta.exe process if it is confirmed to be making unauthorized network connections.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files.
+- Review and analyze the process tree and network connections associated with mshta.exe to identify any additional compromised processes or systems.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
+- Implement application whitelisting to prevent unauthorized execution of mshta.exe and similar system binaries.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
index 3ec331c277f..1e6d83350b5 100644
--- a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
+++ b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,41 @@ sequence by process.entity_id with maxspan=1m
  not (process.name : ("rundll32.exe", "regsvr32.exe") and process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*"))]
 [any where host.os.type == "windows" and event.category in ("network", "dns") and process.name != null]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 MsiExec Service Child Process With Network Connection
+
+MsiExec is a Windows utility for installing, maintaining, and removing software. Adversaries exploit it to execute malicious payloads by disguising them as legitimate installations. The detection rule identifies suspicious child processes spawned by MsiExec that initiate network activity, which is atypical for standard installations. By focusing on unusual executable paths and network connections, the rule helps uncover potential misuse indicative of malware delivery or initial access attempts.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent and child processes of the suspicious MsiExec activity, focusing on the process.entity_id and process.parent.name fields to understand the execution flow.
+- Examine the process.executable path to determine if it deviates from typical installation paths, as specified in the query, to assess the likelihood of malicious activity.
+- Analyze the network or DNS activity associated with the process by reviewing the event.category field for network or dns events, and correlate these with the process.name to identify any unusual or unauthorized connections.
+- Check the process.args for any unusual or suspicious command-line arguments that might indicate an attempt to execute malicious payloads or scripts.
+- Investigate the host's recent activity and security logs to identify any other indicators of compromise or related suspicious behavior, leveraging data sources like Elastic Defend, Sysmon, or SentinelOne as mentioned in the rule's tags.
+- Assess the risk and impact of the detected activity by considering the context of the alert, such as the host's role in the network and any potential data exposure or system compromise.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they involve network activity. Users can create exceptions for known software update processes that are verified as safe.
+- Custom enterprise applications that use MsiExec for deployment and require network access might be flagged. Identify these applications and exclude their specific executable paths from the rule.
+- Automated deployment tools that utilize MsiExec and perform network operations could be misidentified. Review these tools and whitelist their processes to prevent false alerts.
+- Security software or system management tools that leverage MsiExec for legitimate purposes may cause false positives. Confirm these tools' activities and add them to an exclusion list if necessary.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate software that may interact with MsiExec.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement.
+- Terminate the suspicious child process spawned by MsiExec to halt any ongoing malicious operations.
+- 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 remnants.
+- Review and analyze the process execution and network activity logs to identify any additional indicators of compromise (IOCs) and assess the scope of the intrusion.
+- Reset credentials and review access permissions for any accounts that may have been compromised or used during the attack.
+- 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 enhanced monitoring and detection rules to identify similar threats in the future, focusing on unusual MsiExec activity and network connections."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_msxsl_network.toml b/rules/windows/defense_evasion_msxsl_network.toml
index 513740d35b9..da8423c925e 100644
--- a/rules/windows/defense_evasion_msxsl_network.toml
+++ b/rules/windows/defense_evasion_msxsl_network.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,40 @@ sequence by process.entity_id
        "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")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Connection via MsXsl
+
+MsXsl.exe is a legitimate Windows utility used to transform XML data using XSLT stylesheets. Adversaries exploit it to execute malicious scripts, bypassing security measures. The detection rule identifies suspicious network activity by MsXsl.exe, focusing on connections to non-local IPs, which may indicate unauthorized data exfiltration or command-and-control communication.
+
+### Possible investigation steps
+
+- Review the process execution details for msxsl.exe, focusing on the process.entity_id and event.type fields to confirm the process start event and gather initial context.
+- Analyze the network connection details, particularly the destination.ip field, to identify the external IP address msxsl.exe attempted to connect to and assess its reputation or any known associations with malicious activity.
+- Check for any related alerts or logs involving the same process.entity_id to determine if msxsl.exe has been involved in other suspicious activities or if there are patterns of behavior indicating a broader attack.
+- Investigate the parent process of msxsl.exe to understand how it was launched and whether it was initiated by a legitimate application or a potentially malicious script.
+- Examine the system for any additional indicators of compromise, such as unusual file modifications or other processes making unexpected network connections, to assess the scope of potential adversarial activity.
+
+### False positive analysis
+
+- Legitimate use of msxsl.exe for XML transformations in enterprise applications may trigger alerts. Users should identify and whitelist known applications or processes that use msxsl.exe for legitimate purposes.
+- Automated scripts or scheduled tasks that utilize msxsl.exe for data processing can cause false positives. Review and document these tasks, then create exceptions for their network activity.
+- Development or testing environments where msxsl.exe is used for debugging or testing XML transformations might be flagged. Ensure these environments are recognized and excluded from monitoring if they are verified as non-threatening.
+- Internal network tools or monitoring solutions that leverage msxsl.exe for legitimate network communications should be identified. Add these tools to an exception list to prevent unnecessary alerts.
+- Regularly review and update the list of excluded IP addresses to ensure that only trusted and verified internal IPs are exempt from triggering the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized data exfiltration or command-and-control communication.
+- Terminate the msxsl.exe process if it is still running to stop any ongoing malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files associated with msxsl.exe.
+- Review and analyze the network logs to identify any other systems that may have been targeted or compromised by similar activity.
+- Restore the affected system from a known good backup if any critical system files or configurations have been altered.
+- Implement network segmentation to limit the ability of msxsl.exe or similar utilities to make unauthorized external connections in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been impacted."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
index 6cdf87d08fc..a877b60cf48 100644
--- a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
+++ b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,42 @@ sequence by host.id, user.id with maxspan=3m
               "?:\\Windows\\SysWOW64\\WerFault.exe")
  ] by process.parent.Ext.real.pid
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Parent Process PID Spoofing
+
+Parent Process PID Spoofing involves manipulating the parent process identifier to disguise the origin of a process, often to bypass security measures or gain elevated privileges. Adversaries exploit this by launching processes with falsified parent PIDs, making them appear benign. The detection rule identifies such anomalies by monitoring process creation events, focusing on unexpected parent-child relationships and unsigned executables, thus flagging potential spoofing attempts.
+
+### Possible investigation steps
+
+- Review the process creation event details to identify the specific executable and its path that triggered the alert. Pay attention to the process.executable field to determine if it matches any suspicious patterns like "?:\\\\Users\\\\*.exe" or "?:\\\\Windows\\\\Temp\\\\*.exe".
+- Check the process.parent.Ext.real.pid field to confirm if the parent process PID has been spoofed. Investigate the legitimacy of the parent process by examining its name and executable path.
+- Analyze the process.code_signature.status field to determine if the executable is unsigned or has a bad digest, which could indicate tampering or a lack of authenticity.
+- Investigate the user context by reviewing the user.id field to understand which user account was associated with the process creation. This can help determine if the activity aligns with expected user behavior.
+- Correlate the process creation event with other related events on the same host.id within the maxspan of 3 minutes to identify any additional suspicious activities or patterns.
+- Examine the integrity level of the process using the process.Ext.token.integrity_level_name field to assess if the process is running with elevated privileges unexpectedly.
+- Cross-reference the process with known legitimate applications by checking if the process.pe.original_file_name matches common applications like "winword.exe" or "powershell.exe" to rule out false positives.
+
+### False positive analysis
+
+- Processes like msedge.exe with sihost.exe as the parent may trigger false positives. Consider adding exceptions for these specific parent-child relationships if they are common in your environment.
+- Executables located in user directories or temporary folders may be flagged if they lack valid code signatures. Regularly review and whitelist known benign applications that operate from these paths.
+- Processes with a parent PID mismatch due to legitimate software updates or installations can be mistaken for spoofing. Monitor and document such activities to refine detection rules and reduce false alerts.
+- WerFault.exe and its variants are excluded by default, but if other legitimate system processes are frequently flagged, consider expanding the exclusion list to include them.
+- Regularly update the list of known safe executables and their expected parent processes to ensure the rule remains effective without generating unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further spread of the threat. Disconnect the host from the network to contain any potential malicious activity.
+- Terminate any suspicious processes identified by the alert, especially those with spoofed parent PIDs or unsigned executables, to halt any ongoing malicious actions.
+- Conduct a thorough review of the affected system's process tree and logs to identify any additional malicious processes or indicators of compromise that may have been missed.
+- Restore the affected system from a known good backup if any critical system files or configurations have been altered by the threat.
+- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary.
+- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of the threat, focusing on process creation events and parent-child process relationships.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
index e58222e18b6..7e006d0bd06 100644
--- a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
+++ b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,40 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\*\\LocalAccountTokenFilterPolicy"
   ) and registry.data.strings : ("1", "0x00000001")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Local Account TokenFilter Policy Disabled
+
+The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled, allows remote connections from local administrators to use full high-integrity tokens. Adversaries may exploit this to bypass User Account Control (UAC) and gain elevated privileges remotely. The detection rule monitors changes to this registry setting, identifying potential unauthorized modifications that could indicate an attempt to facilitate lateral movement or evade defenses.
+
+### Possible investigation steps
+
+- Review the registry event logs to confirm the change to the LocalAccountTokenFilterPolicy setting, specifically looking for entries where the registry.value is "LocalAccountTokenFilterPolicy" and registry.data.strings is "1" or "0x00000001".
+- Identify the user account and process responsible for the registry modification by examining the associated event logs for user and process information.
+- Check for any recent remote connections to the affected system, focusing on connections initiated by local administrator accounts, to determine if the change was exploited for lateral movement.
+- Investigate any other recent registry changes on the host to identify potential patterns of unauthorized modifications that could indicate broader malicious activity.
+- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and assess the scope of the potential threat.
+- Assess the system for signs of compromise or malicious activity, such as unusual processes, network connections, or file modifications, that may have occurred around the time of the registry change.
+
+### False positive analysis
+
+- Administrative tools or scripts that modify the LocalAccountTokenFilterPolicy for legitimate configuration purposes may trigger alerts. To manage this, identify and document these tools, then create exceptions for their known registry changes.
+- System updates or patches that adjust registry settings as part of their installation process can cause false positives. Monitor update schedules and correlate alerts with these activities to determine if they are benign.
+- Security software or management solutions that enforce policy changes across endpoints might modify this registry setting. Verify these actions with your IT or security team and consider excluding these processes from triggering alerts.
+- Custom scripts or automation tasks used for system hardening or configuration management may alter this setting. Review these scripts and whitelist their expected changes to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Revert the registry setting for LocalAccountTokenFilterPolicy to its default state if it was modified without authorization.
+- Conduct a thorough review of recent administrative activities and access logs on the affected system to identify any unauthorized access or changes.
+- Reset passwords for all local administrator accounts on the affected system to prevent potential misuse of compromised credentials.
+- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify registry settings.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional network segmentation and access controls to limit administrative access to critical systems and reduce the risk of similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_posh_obfuscation.toml b/rules/windows/defense_evasion_posh_obfuscation.toml
index a526da2b50a..ee546d65188 100644
--- a/rules/windows/defense_evasion_posh_obfuscation.toml
+++ b/rules/windows/defense_evasion_posh_obfuscation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/03"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,41 @@ event.category:process and host.os.type:windows and
     ("rahc" or "ekovin" or "gnirts" or "ecnereferpesobrev" or "ecalper" or "cepsmoc" or "dillehs")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential PowerShell Obfuscated Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its flexibility to obfuscate scripts, evading security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts, aiding in defense evasion detection.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text captured in the alert to identify any suspicious patterns or obfuscation techniques, such as string manipulation or encoding methods like "[string]::join" or "-Join".
+- Check the process execution details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed.
+- Investigate the source and destination of the script execution by examining the host and user details to determine if the activity aligns with expected behavior or if it originates from an unusual or unauthorized source.
+- Analyze any network connections or file modifications associated with the PowerShell process to identify potential data exfiltration or lateral movement activities.
+- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify any related suspicious activities.
+- Assess the risk and impact of the detected activity by considering the severity and risk score provided in the alert, and determine if immediate remediation actions are necessary.
+
+### False positive analysis
+
+- Legitimate administrative scripts may use string manipulation and encoding techniques for benign purposes, such as data processing or configuration management. Review the context of the script execution and verify the source and intent before flagging it as malicious.
+- Scripts that automate complex tasks might use obfuscation-like patterns to handle data securely or efficiently. Consider whitelisting known scripts or trusted sources to reduce false positives.
+- Development and testing environments often run scripts with obfuscation patterns for testing purposes. Exclude these environments from the rule or create exceptions for specific users or groups involved in development.
+- Security tools and monitoring solutions might generate PowerShell scripts with obfuscation patterns as part of their normal operation. Identify these tools and exclude their activities from triggering the rule.
+- Regularly update the list of exceptions and whitelisted scripts to ensure that new legitimate scripts are not mistakenly flagged as threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activity.
+- Conduct a thorough review of the PowerShell script block logs to identify and remove any obfuscated scripts or malicious code remnants.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Update and patch the affected system to ensure all security vulnerabilities are addressed, reducing the risk of exploitation.
+- Monitor the system and network for any signs of re-infection or similar obfuscation patterns to ensure the threat has been fully mitigated.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
index 01bf525400c..d2cffe567b0 100644
--- a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
+++ b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/31"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,41 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.pe.original_file_name == "msdt.exe" and not process.executable : ("?:\\Windows\\system32\\msdt.exe", "?:\\Windows\\SysWOW64\\msdt.exe"))
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Microsoft Diagnostics Wizard Execution
+
+The Microsoft Diagnostics Troubleshooting Wizard (MSDT) is a legitimate tool used for diagnosing and resolving issues within Windows environments. However, adversaries can exploit MSDT to execute malicious commands by manipulating its process arguments, effectively using it as a proxy for harmful activities. The detection rule identifies such abuse by monitoring for unusual execution patterns, such as atypical file paths, unexpected parent processes, and non-standard executable locations, which are indicative of potential misuse. This proactive detection helps in mitigating risks associated with defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process arguments to identify any suspicious patterns, such as "IT_RebrowseForFile=*", "ms-msdt:/id", "ms-msdt:-id", or "*FromBase64*", which may indicate malicious intent.
+- Examine the parent process of msdt.exe to determine if it was launched by an unexpected or potentially malicious process like cmd.exe, powershell.exe, or mshta.exe.
+- Check the file path of the msdt.exe executable to ensure it matches the standard locations (?:\\Windows\\system32\\msdt.exe or ?:\\Windows\\SysWOW64\\msdt.exe) and investigate any deviations.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related malicious activities or patterns.
+- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
+
+### False positive analysis
+
+- Legitimate troubleshooting activities by IT staff using MSDT may trigger alerts. To manage this, create exceptions for known IT user accounts or specific machines frequently used for diagnostics.
+- Automated scripts or software updates that utilize MSDT for legitimate purposes can cause false positives. Identify these scripts and whitelist their execution paths or parent processes.
+- Custom diagnostic tools that leverage MSDT might be flagged. Review these tools and exclude their specific process arguments or executable paths if they are verified as safe.
+- Non-standard installations of MSDT in custom environments could be misidentified. Ensure that any legitimate non-standard paths are documented and excluded from monitoring.
+- Frequent use of MSDT in virtualized environments for testing purposes may lead to alerts. Consider excluding these environments or specific virtual machines from the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the suspicious msdt.exe process to stop any ongoing malicious execution.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
+- Review and analyze the process arguments and parent processes associated with the msdt.exe execution to identify potential entry points or related malicious activities.
+- Restore any affected files or system components from a known good backup to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and logging for msdt.exe and related processes to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
index e42b52ac964..04f0884e0e9 100644
--- a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
+++ b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,40 @@ registry where host.os.type == "windows" and event.type == "change" and
   (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 DNS Global Query Block List Modified or Disabled
+
+The DNS Global Query Block List (GQBL) is a security feature in Windows environments that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling them to exploit default settings for privilege escalation. The detection rule monitors registry changes indicating such modifications, flagging potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the registry event logs to confirm the specific changes made to the DNS Global Query Block List, focusing on the registry values "EnableGlobalQueryBlockList" and "GlobalQueryBlockList".
+- Identify the user account associated with the registry change event to determine if the account has elevated privileges, such as DNSAdmins, which could indicate potential misuse.
+- Check for any recent changes in user permissions or group memberships that might have granted the necessary privileges to modify the GQBL.
+- Investigate any other suspicious activities or alerts related to the same user or host around the time of the registry change to identify potential lateral movement or privilege escalation attempts.
+- Correlate the event with network traffic logs to detect any unusual DNS queries or attempts to resolve WPAD or other blocked names, which could suggest exploitation attempts.
+- Review system and security logs for any signs of unauthorized access or other indicators of compromise on the affected host.
+
+### False positive analysis
+
+- Legitimate administrative changes to DNS settings by IT staff can trigger the rule. To manage this, create exceptions for known maintenance windows or authorized personnel making these changes.
+- Automated scripts or software updates that modify DNS settings might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for system operations.
+- Changes made by security tools or network management software that adjust DNS settings for legitimate reasons can be mistaken for threats. Review and exclude these tools from monitoring if they are part of the organization's approved security infrastructure.
+- In environments where WPAD is intentionally used, the absence of "wpad" in the GlobalQueryBlockList might be a normal configuration. Document and exclude these cases if they align with the organization's network design and security policies.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.
+- Revert any unauthorized changes to the DNS Global Query Block List by restoring the registry settings to their default state, ensuring WPAD and other critical entries are included.
+- Conduct a thorough review of user accounts with elevated privileges, such as DNSAdmins, to identify any unauthorized access or privilege escalation. Revoke unnecessary privileges and reset credentials as needed.
+- Deploy endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise or malicious activity, focusing on defense evasion techniques.
+- Monitor network traffic for signs of WPAD spoofing or other related attacks, and implement network segmentation to limit the impact of potential threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List, ensuring rapid detection and response to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_root_dir_ads_creation.toml b/rules/windows/defense_evasion_root_dir_ads_creation.toml
index 3da978e81f0..0d05950312b 100644
--- a/rules/windows/defense_evasion_root_dir_ads_creation.toml
+++ b/rules/windows/defense_evasion_root_dir_ads_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,41 @@ any where host.os.type == "windows" and event.category in ("file", "process") an
     (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Alternate Data Stream Creation/Execution at Volume Root Directory
+
+Alternate Data Streams (ADS) in Windows allow files to contain multiple streams of data, which can be exploited by adversaries to conceal malicious tools or data. By creating or executing ADS at the root of a volume, attackers can evade detection by standard system utilities. The detection rule identifies suspicious ADS activity by monitoring file creation and process execution patterns at the volume root, flagging potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path or process executable that triggered the alert, focusing on the volume root directory pattern [A-Z]:\\\\:.
+- Check the file or process creation timestamp to determine when the suspicious activity occurred and correlate it with other events or activities on the system around the same time.
+- Investigate the file or process owner and the user account associated with the activity to assess if it aligns with expected behavior or if it indicates potential unauthorized access.
+- Examine the file or process for known indicators of compromise (IOCs) or signatures of malicious activity using threat intelligence sources or antivirus tools.
+- Analyze the system for additional signs of compromise, such as unexpected network connections, registry changes, or other suspicious files, to determine if the ADS activity is part of a larger attack.
+- Review system logs and security tools for any related alerts or anomalies that could provide further context or evidence of malicious intent.
+
+### False positive analysis
+
+- System utilities or legitimate applications may create ADS at the volume root for benign purposes, such as storing metadata or configuration data. Review the source of the ADS creation to determine if it is associated with known safe applications.
+- Backup or disk management software might use ADS to store additional information about files. Verify if the detected activity aligns with scheduled backup operations or disk management tasks.
+- Some security tools or system monitoring applications may use ADS for logging or tracking purposes. Cross-reference the process or file path with known security tools to rule out false positives.
+- If a specific application is consistently triggering alerts due to its use of ADS, consider creating an exception for that application's process or file path in your monitoring solution to reduce noise.
+- Regularly update your list of known safe applications and processes that interact with ADS to ensure that legitimate activities are not flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the identified ADS activity.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any hidden malicious files or tools.
+- Review and delete any unauthorized or suspicious ADS found at the volume root directory to eliminate potential hiding places for malware.
+- Restore affected files from a known good backup to ensure system integrity and remove any compromised data.
+- Monitor network traffic for unusual patterns or connections that may indicate ongoing malicious activity or data exfiltration attempts.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sc_sdset.toml b/rules/windows/defense_evasion_sc_sdset.toml
index c5be261625f..cda6a7fb1c3 100644
--- a/rules/windows/defense_evasion_sc_sdset.toml
+++ b/rules/windows/defense_evasion_sc_sdset.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,42 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "sdset" and process.args : "*D;*" and
   process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Service DACL Modification via sc.exe
+
+The `sc.exe` utility in Windows is used to manage services, including modifying their Discretionary Access Control Lists (DACLs). Adversaries may exploit this to alter service permissions, making them unmanageable or hidden. The detection rule identifies such modifications by monitoring for specific command patterns that indicate DACL changes, focusing on access denial to key user groups, thus flagging potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of "sc.exe" with the "sdset" argument, indicating a potential DACL modification attempt.
+- Examine the specific arguments used with "sc.exe" to identify which user groups (e.g., IU, SU, BA, SY, WD) were targeted for access denial.
+- Check the process execution timeline to determine if this activity coincides with other suspicious behavior or unauthorized access attempts.
+- Investigate the user account associated with the process execution to assess if it has the necessary privileges and if the activity aligns with their typical behavior.
+- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to identify potential patterns or related incidents.
+- Assess the impact on the affected service by verifying its current state and functionality, ensuring it is not hidden or unmanageable.
+- If necessary, consult with system administrators to understand the legitimate need for such modifications and confirm if the activity was authorized.
+
+### False positive analysis
+
+- Routine administrative tasks using sc.exe to modify service permissions may trigger the rule. Review the context of the command and verify if it aligns with standard IT maintenance activities.
+- Automated scripts or software deployment tools that adjust service DACLs for legitimate configuration purposes can cause false positives. Identify these scripts and consider excluding their specific command patterns from the rule.
+- Security software updates or patches that modify service permissions as part of their installation process might be flagged. Confirm the legitimacy of the update and exclude the associated process arguments if necessary.
+- Custom applications that require specific service permissions for functionality may inadvertently match the detection criteria. Validate the application's behavior and create exceptions for its known safe operations.
+- Regular audits or compliance checks that involve service DACL modifications could be misinterpreted as malicious. Document these activities and adjust the rule to ignore them when performed by authorized personnel.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or changes to service permissions.
+- Terminate any suspicious processes related to sc.exe that are actively modifying service DACLs to stop ongoing malicious activity.
+- Restore the original DACL settings for the affected services using a known good configuration or backup to ensure proper access control is reinstated.
+- Conduct a thorough review of user accounts and permissions to identify and revoke any unauthorized access that may have been granted during the attack.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify service DACLs, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign.
+- Review and update endpoint protection policies to prevent similar threats in the future, ensuring that all systems are equipped with the latest security patches and configurations."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sccm_scnotification_dll.toml b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
index 8abfbc3726a..e08c10a7bac 100644
--- a/rules/windows/defense_evasion_sccm_scnotification_dll.toml
+++ b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,39 @@ query = '''
 library where host.os.type == "windows" and process.name : "SCNotification.exe" and
   (dll.Ext.relative_file_creation_time < 86400 or dll.Ext.relative_file_name_modify_time <= 500) and dll.code_signature.status != "trusted"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Windows Session Hijacking via CcmExec
+
+CcmExec, part of Microsoft's System Center Configuration Manager, manages client configurations and software updates. Adversaries may exploit it by loading malicious DLLs into SCNotification.exe, a process associated with user notifications. This detection rule identifies suspicious DLL activity, such as recent file creation or modification and untrusted signatures, indicating potential session hijacking attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm that the process name is SCNotification.exe and check the associated DLL file's creation or modification times to ensure they match the query conditions.
+- Investigate the untrusted DLL by examining its file path, hash, and any available metadata to determine its origin and legitimacy.
+- Check the code signature status of the DLL to understand why it is marked as untrusted and verify if it has been tampered with or is from an unknown publisher.
+- Analyze recent system logs and user activity around the time the DLL was loaded to identify any suspicious behavior or unauthorized access attempts.
+- Correlate the alert with other security events or alerts from the same host to identify potential patterns or related incidents that could indicate a broader attack.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve recent DLL file creation or modification. Users can create exceptions for known software update processes to prevent unnecessary alerts.
+- System maintenance activities, such as patch management or configuration changes, might cause SCNotification.exe to load new DLLs. Exclude these activities by identifying and whitelisting trusted maintenance operations.
+- Custom or in-house applications that are not signed by a recognized authority may be flagged. Ensure these applications are signed with a trusted certificate or add them to an allowlist to avoid false positives.
+- Security tools or monitoring software that interact with SCNotification.exe could be mistakenly identified. Verify these tools and exclude them from the rule if they are deemed safe and necessary for operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate the SCNotification.exe process to stop the execution of the untrusted DLL and prevent further malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software.
+- Review and restore any modified or corrupted system files from a known good backup to ensure system integrity.
+- Investigate the source of the untrusted DLL and remove any unauthorized software or scripts that may have facilitated its introduction.
+- Implement application whitelisting to prevent unauthorized DLLs from being loaded by SCNotification.exe or other critical processes in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
index 7d5d97ca9d5..ed84b7eb9db 100644
--- a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
+++ b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,40 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt"
   ) and registry.data.strings : ("1", "0x00000001")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Scheduled Tasks AT Command Enabled
+
+The AT command, a legacy Windows utility, schedules tasks for execution, often used for automation. Despite its deprecation post-Windows 8, it remains for compatibility, posing a security risk. Attackers exploit it to maintain persistence or move laterally. The detection rule monitors registry changes enabling this command, flagging potential misuse by checking specific registry paths and values indicative of enabling the AT command.
+
+### Possible investigation steps
+
+- Review the registry event logs to confirm the change in the registry path "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt" and verify if the value was set to "1" or "0x00000001".
+- Identify the user account and process responsible for the registry change by examining the event logs for associated user and process information.
+- Check for any scheduled tasks created or modified around the time of the registry change to determine if the AT command was used to schedule any tasks.
+- Investigate the system for any signs of lateral movement or persistence mechanisms that may have been established using the AT command.
+- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and assess the scope of potential malicious activity.
+
+### False positive analysis
+
+- System administrators or IT management tools may enable the AT command for legacy support or compatibility testing. Verify if the change aligns with scheduled maintenance or updates.
+- Some enterprise environments might have legacy applications that rely on the AT command for task scheduling. Confirm with application owners if such dependencies exist and document them.
+- Security software or monitoring tools might trigger registry changes as part of their normal operation. Cross-reference with logs from these tools to ensure the change is benign.
+- If a specific user or system frequently triggers this alert without malicious intent, consider creating an exception for that user or system in your monitoring solution to reduce noise.
+- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or persistence by the attacker.
+- Review the registry changes identified in the alert to confirm unauthorized enabling of the AT command. Revert the registry setting to its secure state by setting the value to "0" or "0x00000000".
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or scripts.
+- Investigate user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords for any compromised accounts.
+- Monitor network traffic and logs for any signs of data exfiltration or communication with known malicious IP addresses or domains.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_script_via_html_app.toml b/rules/windows/defense_evasion_script_via_html_app.toml
index 12b49fd1160..b3853ec371a 100644
--- a/rules/windows/defense_evasion_script_via_html_app.toml
+++ b/rules/windows/defense_evasion_script_via_html_app.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,39 @@ process where host.os.type == "windows" and event.type == "start" and
       process.args : ("?:\\Users\\*\\Temp\\7z*", "?:\\Users\\*\\Temp\\Rar$*", "?:\\Users\\*\\Temp\\Temp?_*", "?:\\Users\\*\\Temp\\BNZ.*"))
    )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Script Execution via Microsoft HTML Application
+
+Microsoft HTML Applications (HTA) allow scripts to run in a trusted environment, often using utilities like `rundll32.exe` or `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns, such as unusual command lines or execution from common download locations, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the process command line details to identify any suspicious patterns or indicators of malicious activity, such as the presence of script execution commands like "eval", "GetObject", or "WScript.Shell".
+- Check the parent process executable path to determine if the process was spawned by a known legitimate application or if it deviates from expected behavior, especially if it is not from the specified exceptions like Citrix, Microsoft Office, or Quokka.Works GTInstaller.
+- Investigate the origin of the HTA file, particularly if it was executed from common download locations like the Downloads folder or temporary archive extraction paths, to assess if it was downloaded from the internet or extracted from an archive.
+- Analyze the process arguments and count to identify any unusual or unexpected parameters that could indicate malicious intent, especially if the process name is "mshta.exe" and the command line does not include typical HTA or HTM file references.
+- Correlate the event with other security logs and alerts from data sources like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and determine if this activity is part of a broader attack pattern.
+
+### False positive analysis
+
+- Execution of legitimate scripts by enterprise applications like Citrix, Microsoft Office, or Quokka.Works GTInstaller can trigger false positives. Users can mitigate this by adding these applications to the exclusion list in the detection rule.
+- Scripts executed by mshta.exe that do not involve malicious intent, such as internal web applications or administrative scripts, may be flagged. Users should review these scripts and, if deemed safe, exclude them based on specific command line patterns or parent processes.
+- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users can create exceptions for these sources by specifying trusted download paths or file hashes.
+- Temporary files created by legitimate software installations or updates in user temp directories can be misinterpreted as malicious. Users should monitor these activities and exclude known safe processes or directories from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the malicious script or unauthorized access.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving `rundll32.exe` or `mshta.exe` with unusual command lines.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts.
+- Review and analyze the command lines and scripts executed to understand the scope and intent of the attack, and identify any additional compromised systems.
+- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
+- Implement network segmentation to limit the ability of similar threats to propagate across the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_sip_provider_mod.toml b/rules/windows/defense_evasion_sip_provider_mod.toml
index 64d6862f7ec..f729e670df1 100644
--- a/rules/windows/defense_evasion_sip_provider_mod.toml
+++ b/rules/windows/defense_evasion_sip_provider_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,40 @@ registry where host.os.type == "windows" and event.type == "change" and registry
   not (process.name : "msiexec.exe" and registry.data.strings : "mso.dll") and
   not (process.name : "regsvr32.exe" and registry.data.strings == "WINTRUST.DLL")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SIP Provider Modification
+
+Subject Interface Package (SIP) providers are integral to Windows' cryptographic system, ensuring file signature validation. Adversaries may modify SIP providers to bypass these checks, facilitating unauthorized code execution. The detection rule identifies suspicious registry changes linked to SIP providers, excluding benign processes, to flag potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the registry path and value changes to confirm if they match the suspicious patterns specified in the query, such as modifications under the paths related to CryptSIPDllPutSignedDataMsg or Trust FinalPolicy.
+- Identify the process responsible for the registry change by examining the process name and compare it against the exclusions in the query, ensuring it is not a benign process like msiexec.exe or regsvr32.exe.
+- Investigate the DLL file specified in the registry change to determine its legitimacy, checking its digital signature and origin.
+- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns.
+- Assess the risk context by considering the host's role and any recent changes or incidents that might explain the registry modification, ensuring it aligns with expected behavior or authorized changes.
+
+### False positive analysis
+
+- Installation or update processes like msiexec.exe may trigger registry changes as part of legitimate software installations. Exclude these by adding exceptions for msiexec.exe when registry data strings include mso.dll.
+- System maintenance tasks using regsvr32.exe might modify SIP provider-related registry entries. Exclude regsvr32.exe when registry data strings match WINTRUST.DLL to prevent false alerts.
+- Regular updates or patches from trusted software vendors may alter SIP provider registry entries. Monitor and document these changes to establish a baseline of expected behavior, allowing for informed exclusions.
+- Security software or endpoint protection solutions might interact with SIP provider settings as part of their normal operation. Identify and whitelist these processes to reduce unnecessary alerts.
+- Custom enterprise applications with legitimate needs to modify cryptographic settings should be reviewed and, if verified as safe, added to an exclusion list to prevent disruption.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or code execution.
+- Terminate any suspicious processes identified in the alert, such as those not typically associated with legitimate SIP provider modifications.
+- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the SIP providers.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced.
+- Review and update endpoint protection policies to ensure that similar unauthorized modifications are detected and blocked in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
index 14445099941..e7a1d34f75c 100644
--- a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
+++ b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,41 @@ registry where host.os.type == "windows" and event.type == "change" and registry
   ) and
   registry.data.strings : ("4", "0x00000004")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SolarWinds Process Disabling Services via Registry
+
+SolarWinds software is integral for network management, often requiring deep system access. Adversaries may exploit this by altering registry settings to disable critical services, evading detection. The detection rule identifies changes to service start types by specific SolarWinds processes, flagging potential misuse aimed at disabling security defenses. This proactive monitoring helps mitigate risks associated with unauthorized registry modifications.
+
+### Possible investigation steps
+
+- Review the process name involved in the alert to confirm it matches one of the specified SolarWinds processes, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe".
+- Examine the registry path in the alert to ensure it corresponds to the critical service start type locations, such as "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Services\\\\*\\\\Start".
+- Check the registry data value to verify if it has been set to "4" (disabled), indicating a potential attempt to disable a service.
+- Investigate the timeline of the registry change event to identify any preceding or subsequent suspicious activities on the host.
+- Correlate the alert with other security logs or alerts from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related malicious activities or patterns.
+- Assess the impacted service to determine its role in security operations and evaluate the potential impact of it being disabled.
+- Contact the system owner or administrator to verify if the registry change was authorized or part of a legitimate maintenance activity.
+
+### False positive analysis
+
+- Routine updates or maintenance by SolarWinds software may trigger registry changes. Verify if the process corresponds to a scheduled update or maintenance task and consider excluding these specific processes during known maintenance windows.
+- Legitimate configuration changes by IT administrators using SolarWinds tools can appear as registry modifications. Confirm with the IT team if the changes align with authorized configuration activities and create exceptions for these known activities.
+- Automated scripts or tools that utilize SolarWinds processes for legitimate network management tasks might cause false positives. Review the scripts or tools in use and whitelist them if they are verified as safe and necessary for operations.
+- Temporary service modifications for troubleshooting purposes by SolarWinds processes can be mistaken for malicious activity. Ensure that any troubleshooting activities are documented and create temporary exceptions during these periods.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized registry modifications and potential lateral movement by the adversary.
+- Terminate any suspicious SolarWinds processes identified in the alert, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe", to halt any ongoing malicious activity.
+- Restore the registry settings for the affected services to their original state, ensuring that critical security services are re-enabled and configured to start automatically.
+- Conduct a thorough review of the affected system for additional signs of compromise, including unauthorized user accounts, scheduled tasks, or other persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized registry changes, leveraging data sources like Sysmon and Microsoft Defender for Endpoint.
+- Review and update access controls and permissions for SolarWinds processes to limit their ability to modify critical system settings, reducing the risk of future exploitation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
index 4fbeafb570a..db9d7220038 100644
--- a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
+++ b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,41 @@ process where host.os.type == "windows" and event.type == "start" and process.ex
   process.name : ("rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe",
                   "cscript.exe", "wscript.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Execution from a Mounted Device
+
+In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when triggered by common parent processes like explorer.exe, thus flagging potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the executable path and working directory, ensuring they match the criteria of being launched from a non-standard directory (e.g., not from "C:\\\\").
+- Investigate the parent process, explorer.exe, to determine if there are any unusual activities or user actions that might have triggered the suspicious execution.
+- Check the user account associated with the process to verify if the activity aligns with their typical behavior or if the account might be compromised.
+- Analyze the command line arguments used by the suspicious process to identify any potentially malicious scripts or commands being executed.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+- Examine the mounted device from which the process was executed to determine its origin, legitimacy, and any associated files that might be malicious.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they are executed from a mounted device. Users can create exceptions for known software update processes that are verified as safe.
+- Portable applications running from USB drives or external storage can be flagged. To mitigate this, users should whitelist specific applications that are frequently used and deemed non-threatening.
+- IT administrative scripts executed from network shares or mounted drives for maintenance tasks might be detected. Users can exclude these scripts by specifying trusted network paths or script names.
+- Development environments where scripts are tested from non-standard directories can cause alerts. Developers should ensure their working directories are recognized as safe or use designated development machines with adjusted monitoring rules.
+- Backup or recovery operations that utilize mounted devices for script execution may be misidentified. Users should identify and exclude these operations by defining exceptions for known backup tools and processes.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified by the detection rule, such as those initiated by script interpreters or signed binaries from non-standard directories.
+- Conduct a forensic analysis of the mounted device and the affected system to identify any malicious payloads or scripts and remove them.
+- Review and restore any altered system configurations or registry settings to their original state to ensure system integrity.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker.
+- Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
index ef418dc1c99..34412f928c2 100644
--- a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
+++ b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,41 @@ file where host.os.type == "windows" and event.type != "deletion" and
                "cmstp.exe.log",
                "regsvr32.exe.log")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Managed Code Hosting Process
+
+Managed code hosting processes like wscript.exe, cscript.exe, and others are integral to executing scripts and managing code in Windows environments. Adversaries exploit these processes for code injection or executing malicious scripts, often evading detection. The detection rule identifies anomalies by monitoring specific process logs, flagging high-risk activities that deviate from normal operations, thus alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the process logs for the specific file names flagged in the alert, such as wscript.exe.log or cscript.exe.log, to identify any unusual or unauthorized script executions.
+- Correlate the suspicious process activity with user account activity to determine if the actions were performed by a legitimate user or potentially compromised account.
+- Examine the parent process of the flagged managed code hosting process to identify if it was spawned by a legitimate application or a known malicious process.
+- Check for any recent changes or modifications to the scripts or executables associated with the flagged process to identify potential tampering or unauthorized updates.
+- Investigate network connections initiated by the suspicious process to detect any communication with known malicious IP addresses or domains.
+- Utilize threat intelligence sources to cross-reference any identified indicators of compromise (IOCs) such as file hashes or IP addresses associated with the suspicious process.
+
+### False positive analysis
+
+- Legitimate administrative scripts may trigger alerts when executed by IT personnel using wscript.exe or cscript.exe. To manage this, create exceptions for known scripts and trusted user accounts.
+- Automated system maintenance tasks using mshta.exe or wmic.exe can be flagged as suspicious. Identify and whitelist these tasks if they are part of regular system operations.
+- Software updates or installations might use svchost.exe or dllhost.exe, leading to false positives. Monitor and document these activities, then exclude them from alerts if they are verified as safe.
+- Custom applications that rely on cmstp.exe or regsvr32.exe for legitimate purposes can be mistaken for threats. Validate these applications and add them to an exception list to prevent unnecessary alerts.
+- Regularly review and update the exception list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate the suspicious process identified in the alert, such as wscript.exe, cscript.exe, or any other flagged process, to stop any ongoing malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or scripts.
+- Review and restore any system or application configurations that may have been altered by the malicious process to ensure system integrity.
+- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope and impact of the incident.
+- Notify the security operations center (SOC) or incident response team to escalate the incident for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring and detection rules to enhance visibility and prevent similar threats in the future, focusing on the specific processes and behaviors identified in the alert."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_scrobj_load.toml b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
index 02c9c309f06..b85cf9342dd 100644
--- a/rules/windows/defense_evasion_suspicious_scrobj_load.toml
+++ b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,40 @@ any where host.os.type == "windows" and
        "?:\\Windows\\System32\\wbem\\WMIADAP.exe",
        "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Script Object Execution
+
+The scrobj.dll is a legitimate Windows library used for executing scriptlets, often in automation tasks. However, adversaries can exploit it to run malicious scripts within trusted processes, evading detection. The detection rule identifies unusual loading of scrobj.dll in non-standard processes, flagging potential misuse. By excluding common executables, it focuses on anomalous activity, aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the process executable path to confirm if it is indeed non-standard for loading scrobj.dll, as specified in the query.
+- Check the parent process of the flagged executable to understand how it was initiated and assess if it aligns with typical behavior.
+- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Analyze recent activity on the host for any other suspicious behavior or anomalies that might correlate with the alert.
+- Examine network connections from the host to identify any unusual or unauthorized external communications that could indicate malicious activity.
+- Review historical data for similar alerts on the same host to identify patterns or repeated suspicious behavior.
+
+### False positive analysis
+
+- Legitimate administrative scripts may trigger the rule if they are executed using non-standard processes. To handle this, identify and document regular administrative tasks that use scriptlets and exclude these specific processes from the rule.
+- Custom enterprise applications that utilize scrobj.dll for legitimate automation purposes might be flagged. Review these applications and add them to the exclusion list if they are verified as safe.
+- Scheduled tasks or maintenance scripts that load scrobj.dll in non-standard processes can cause false positives. Regularly audit scheduled tasks and exclude known safe processes from the detection rule.
+- Development or testing environments where scriptlets are frequently used for automation may generate alerts. Consider creating a separate rule set for these environments to reduce noise while maintaining security monitoring.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement.
+- Terminate any suspicious processes identified as loading scrobj.dll in non-standard executables to halt malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious scripts or files.
+- Review and restore any altered system configurations or settings to their default state to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the processes identified in the detection rule.
+- Update detection mechanisms to monitor for similar activities across the network, ensuring that any future attempts to exploit scrobj.dll are promptly identified and addressed."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_suspicious_wmi_script.toml b/rules/windows/defense_evasion_suspicious_wmi_script.toml
index 3f1cee8f4c1..fbfd68fdc08 100644
--- a/rules/windows/defense_evasion_suspicious_wmi_script.toml
+++ b/rules/windows/defense_evasion_suspicious_wmi_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,41 @@ sequence by process.entity_id with maxspan = 2m
 [any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and
  (?dll.name : ("jscript.dll", "vbscript.dll") or file.name : ("jscript.dll", "vbscript.dll"))]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious WMIC XSL Script Execution
+
+Windows Management Instrumentation Command-line (WMIC) is a powerful tool for managing Windows systems. Adversaries exploit WMIC to bypass security measures by executing scripts via XSL files, often loading scripting libraries like jscript.dll or vbscript.dll. The detection rule identifies such suspicious activities by monitoring WMIC executions with atypical arguments and the loading of specific libraries, indicating potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of WMIC.exe or wmic.exe with suspicious arguments such as "format*:*", "/format*:*", or "*-format*:*" that deviate from typical usage patterns.
+- Examine the command line used in the process execution to identify any unusual or unexpected parameters that could indicate malicious intent, excluding known benign patterns like "* /format:table *".
+- Investigate the sequence of events to determine if there was a library or process event involving the loading of jscript.dll or vbscript.dll, which may suggest script execution through XSL files.
+- Correlate the process.entity_id with other related events within the 2-minute window to identify any additional suspicious activities or processes that may have been spawned as a result of the initial execution.
+- Check the parent process of the suspicious WMIC execution to understand the context and origin of the activity, which may provide insights into whether it was initiated by a legitimate application or a potentially malicious actor.
+- Analyze the host's recent activity and security logs for any other indicators of compromise or related suspicious behavior that could be part of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tasks using WMIC with custom scripts may trigger alerts. Review the command line arguments and context to determine if the execution is part of routine system management.
+- Automated scripts or software updates that utilize WMIC for legitimate purposes might load scripting libraries like jscript.dll or vbscript.dll. Identify these processes and consider adding them to an allowlist to prevent future false positives.
+- Security tools or monitoring solutions that use WMIC for system checks can be mistaken for suspicious activity. Verify the source and purpose of the execution and exclude these known tools from triggering alerts.
+- Scheduled tasks or maintenance scripts that use WMIC with non-standard arguments could be flagged. Document these tasks and create exceptions for their specific command line patterns to reduce noise.
+- Custom applications developed in-house that rely on WMIC for functionality may inadvertently match the detection criteria. Work with development teams to understand these applications and adjust the detection rule to accommodate their legitimate use cases.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious WMIC processes identified by the alert to stop ongoing malicious script execution.
+- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related malicious activities.
+- Remove any unauthorized or suspicious XSL files and associated scripts from the system to prevent re-execution.
+- Restore the system from a known good backup if any critical system files or configurations have been altered.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_timestomp_sysmon.toml b/rules/windows/defense_evasion_timestomp_sysmon.toml
index 1664fbad7f2..e9b6a211fcf 100644
--- a/rules/windows/defense_evasion_timestomp_sysmon.toml
+++ b/rules/windows/defense_evasion_timestomp_sysmon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,41 @@ file where host.os.type == "windows" and event.code : "2" and
  not file.extension : ("temp", "tmp", "~tmp", "xml", "newcfg") and not user.name : ("SYSTEM", "Local Service", "Network Service") and
  not file.name : ("LOG", "temp-index", "license.rtf", "iconcache_*.db")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File Creation Time Changed
+File creation timestamps are crucial for tracking file history and integrity. Adversaries may alter these timestamps, a tactic known as timestomping, to disguise malicious files as benign. This detection rule leverages Sysmon logs to identify suspicious changes in file creation times, excluding trusted processes and file types, thus highlighting potential evasion attempts by attackers.
+
+### Possible investigation steps
+
+- Review the Sysmon logs to confirm the event code 2, which indicates a file creation time change, and verify the associated process and file details.
+- Identify the process executable path that triggered the alert and determine if it is outside the list of trusted paths specified in the query.
+- Check the file extension and name to ensure they are not part of the excluded types such as "temp", "tmp", or "LOG".
+- Investigate the user account associated with the event to determine if it is a non-system account, as the query excludes "SYSTEM", "Local Service", and "Network Service".
+- Correlate the file creation time change event with other security events or logs to identify any related suspicious activities or patterns.
+- Assess the file's location and context to determine if it is in a sensitive or unusual directory that could indicate malicious intent.
+- If necessary, perform a deeper forensic analysis on the file and process to identify any potential malicious behavior or indicators of compromise.
+
+### False positive analysis
+
+- Trusted software updates or installations may alter file creation times. Exclude known update processes like msiexec.exe from detection to reduce noise.
+- System maintenance tasks, such as disk cleanup, can modify timestamps. Exclude cleanmgr.exe to prevent these benign changes from triggering alerts.
+- User-initiated actions in trusted applications like Chrome or Firefox might change file creation times. Exclude these applications to avoid unnecessary alerts.
+- Temporary files created by legitimate processes may have altered timestamps. Exclude file extensions like temp and tmp to minimize false positives.
+- System accounts such as SYSTEM or Local Service may perform legitimate file operations. Exclude these user names to focus on suspicious activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement by the adversary.
+- Conduct a thorough review of the file in question to determine if it is malicious. Use a combination of antivirus scans and manual analysis to assess the file's behavior and origin.
+- If the file is confirmed to be malicious, remove it from the system and any other locations it may have been copied to. Ensure that all associated processes are terminated.
+- Restore any affected files from a known good backup to ensure data integrity and continuity.
+- Review and update endpoint protection settings to ensure that similar threats are detected and blocked in the future. This may include adjusting Sysmon configurations to enhance logging and detection capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.
+- Document the incident, including all actions taken, to improve future response efforts and update threat intelligence databases with any new indicators of compromise (IOCs) identified."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
index 17af2ccdeeb..c8602abe2bd 100644
--- a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
+++ b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -125,6 +125,40 @@ library where host.os.type == "windows" and
 	 /* DLL loaded from the process.executable current directory */
 	 endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unsigned DLL Side-Loading from a Suspicious Folder
+
+DLL side-loading exploits the trust of signed executables to load malicious DLLs, often from suspicious directories. Adversaries use this to bypass security measures by placing unsigned DLLs in locations mimicking legitimate paths. The detection rule identifies this by checking for trusted programs loading recently modified, unsigned DLLs from atypical directories, signaling potential evasion tactics.
+
+### Possible investigation steps
+
+- Review the process code signature to confirm the legitimacy of the trusted program that loaded the DLL. Check if the process is expected to run from the identified directory.
+- Examine the DLL's path and creation or modification time to determine if it aligns with typical user or system activity. Investigate why the DLL was recently modified or created.
+- Analyze the DLL's code signature status to understand why it is unsigned or has an error status. This can help identify if the DLL is potentially malicious.
+- Investigate the parent process and any associated child processes to understand the context of the DLL loading event. This can provide insights into how the DLL was introduced.
+- Check for any recent changes or anomalies in the system or user activity logs around the time the DLL was created or modified to identify potential indicators of compromise.
+- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack or isolated incident.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily load unsigned DLLs from atypical directories. Users can create exceptions for known update processes by verifying the source and ensuring the process is part of a legitimate update.
+- Custom or in-house applications might load unsigned DLLs from non-standard directories. Users should verify the application's behavior and, if deemed safe, exclude these specific paths or processes from the rule.
+- Development environments often involve testing unsigned DLLs in various directories. Developers can exclude these environments by specifying the directories or processes involved in the development workflow.
+- Some third-party security or system management tools may use unsigned DLLs for legitimate purposes. Users should confirm the tool's legitimacy and add exceptions for these tools to prevent false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the process associated with the unsigned DLL to stop any ongoing malicious operations.
+- Quarantine the suspicious DLL file and any related files for further analysis to understand the scope and nature of the threat.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants.
+- Review and restore any altered system configurations or settings to their original state to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has impacted other systems.
+- Implement additional monitoring and logging on the affected system and network to detect any recurrence or similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_dir_ads.toml b/rules/windows/defense_evasion_unusual_dir_ads.toml
index 9d0dc28418d..08fb59cfba8 100644
--- a/rules/windows/defense_evasion_unusual_dir_ads.toml
+++ b/rules/windows/defense_evasion_unusual_dir_ads.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -39,6 +39,41 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.args : "?:\\*:*" and process.args_count == 1
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process Execution Path - Alternate Data Stream
+
+Alternate Data Streams (ADS) in Windows allow files to contain multiple data streams, which can be exploited by adversaries to conceal malicious code. This technique is often used for defense evasion, as it hides malware within legitimate files. The detection rule identifies processes initiated from ADS by monitoring specific execution patterns, such as unique argument structures, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and path, to determine if it is a known legitimate application or potentially malicious.
+- Examine the process arguments, specifically looking for the pattern "?:\\\\*:*", to understand the context of the execution and identify any suspicious or unusual characteristics.
+- Check the parent process of the flagged process to assess if it was initiated by a legitimate or expected source.
+- Investigate the user account associated with the process execution to determine if the activity aligns with the user's typical behavior or if it appears anomalous.
+- Correlate the event with other security logs or alerts from data sources like Sysmon, Microsoft Defender for Endpoint, or Crowdstrike to gather additional context and identify any related suspicious activities.
+- Search for any known indicators of compromise (IOCs) related to the process or file path in threat intelligence databases to assess if the activity is associated with known threats.
+
+### False positive analysis
+
+- Legitimate software installations or updates may use alternate data streams to execute processes. Users can create exceptions for known software update paths to prevent unnecessary alerts.
+- Some backup or file synchronization tools might utilize alternate data streams for metadata storage. Identify these tools and exclude their execution paths from the detection rule.
+- Certain system administration scripts or tools may leverage alternate data streams for legitimate purposes. Review and whitelist these scripts if they are verified as non-threatening.
+- Developers might use alternate data streams during software development for testing purposes. Ensure development environments are accounted for in the exception list to avoid false positives.
+- Security tools themselves may use alternate data streams for scanning or monitoring activities. Verify and exclude these tools from the detection rule to reduce noise.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware.
+- Terminate any suspicious processes identified as running from an Alternate Data Stream to halt malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any hidden malware.
+- Examine the file system for any additional Alternate Data Streams and remove or quarantine any suspicious files.
+- Restore any affected files or systems from known good backups to ensure system integrity.
+- Monitor the network for any unusual outbound traffic from the affected system that may indicate data exfiltration attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
index 0e2c84b0d56..746be96af71 100644
--- a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
+++ b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,39 @@ sequence by host.id, process.entity_id with maxspan=1m
     "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")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Network Connection via DllHost
+
+Dllhost.exe is a legitimate Windows process used to host DLL services. Adversaries may exploit it for stealthy command and control by initiating unauthorized network connections. The detection rule identifies suspicious dllhost.exe activity by monitoring outbound connections to non-local IPs, which may indicate malicious intent. This approach helps in identifying potential threats by focusing on unusual network behaviors associated with this process.
+
+### Possible investigation steps
+
+- Review the process start event for dllhost.exe to confirm its legitimacy by checking the process arguments and the parent process that initiated it.
+- Analyze the destination IP addresses involved in the network connections to determine if they are known malicious or suspicious entities, using threat intelligence sources.
+- Check the timeline of events to see if there are any other unusual activities on the host around the time of the dllhost.exe network connection, such as other process executions or file modifications.
+- Investigate the user account associated with the dllhost.exe process to determine if there are any signs of compromise or unauthorized access.
+- Examine the network traffic patterns from the host to identify any other unusual outbound connections that might indicate broader malicious activity.
+
+### False positive analysis
+
+- Legitimate software updates or system maintenance tasks may cause dllhost.exe to make outbound connections. Users can monitor and whitelist known update servers to prevent these from being flagged.
+- Certain enterprise applications might use dllhost.exe for legitimate network communications. Identify and document these applications, then create exceptions for their known IP addresses.
+- Automated scripts or administrative tools that leverage dllhost.exe for network tasks can trigger false positives. Review and exclude these scripts or tools by specifying their associated IP ranges.
+- Cloud-based services or virtual environments might route traffic through dllhost.exe. Verify these services and exclude their IP addresses from the detection rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected host from the network immediately to prevent further unauthorized communications and potential lateral movement.
+- Terminate the suspicious dllhost.exe process to stop any ongoing malicious activity and prevent further outbound connections.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts.
+- Review and analyze the network logs to identify any other systems that may have been targeted or compromised, and apply similar containment measures if necessary.
+- Restore the affected system from a known good backup to ensure that any potential backdoors or persistent threats are removed.
+- Implement network segmentation to limit the ability of similar threats to spread across the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional organizational measures are required."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
index f2dc01c3942..2321bdd1cd9 100644
--- a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
+++ b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,42 @@ process where host.os.type == "windows" and event.type == "start" and
   process.parent.pid == 4 and process.executable : "?*" and
   not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Child Process from a System Virtual Process
+
+In Windows environments, the System process (PID 4) is a critical component responsible for managing system-level operations. Adversaries may exploit this by injecting malicious code to spawn unauthorized child processes, evading detection. The detection rule identifies anomalies by flagging unexpected child processes originating from the System process, excluding known legitimate executables, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process details of the suspicious child process, including the executable path and command line arguments, to determine if it matches known malicious patterns or anomalies.
+- Check the parent process (PID 4) to confirm it is indeed the System process and verify if any legitimate processes are excluded as per the rule (e.g., Registry, MemCompression, smss.exe).
+- Investigate the timeline of events leading up to the process start event to identify any preceding suspicious activities or anomalies that might indicate process injection or exploitation.
+- Correlate the alert with other security telemetry from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related alerts or indicators of compromise.
+- Examine the network activity associated with the suspicious process to detect any unauthorized connections or data exfiltration attempts.
+- Consult threat intelligence sources to determine if the process executable or its behavior is associated with known malware or threat actor techniques.
+- If necessary, isolate the affected system to prevent further potential malicious activity and conduct a deeper forensic analysis.
+
+### False positive analysis
+
+- Legitimate system maintenance tools may occasionally spawn child processes from the System process. Users should monitor and verify these tools and add them to the exclusion list if they are confirmed to be safe.
+- Some security software might create child processes from the System process as part of their normal operation. Identify these processes and configure exceptions to prevent unnecessary alerts.
+- Windows updates or system patches can sometimes trigger unexpected child processes. Ensure that these processes are part of a legitimate update cycle and exclude them if they are verified.
+- Custom scripts or administrative tools used for system management might also cause false positives. Review these scripts and tools, and if they are deemed safe, add them to the exclusion list.
+- Virtualization software or sandbox environments may mimic or interact with the System process in ways that trigger alerts. Validate these interactions and exclude them if they are part of normal operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
+- Terminate any suspicious child processes identified as originating from the System process (PID 4) that are not part of the known legitimate executables.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code.
+- Review recent system changes and installed software to identify any unauthorized modifications or installations that could have facilitated the process injection.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through other means.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for the affected system and similar environments to detect any recurrence of the threat, focusing on process creation events and anomalies related to the System process."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_windows_filtering_platform.toml b/rules/windows/defense_evasion_windows_filtering_platform.toml
index a409ebe9849..ba8acd7b348 100644
--- a/rules/windows/defense_evasion_windows_filtering_platform.toml
+++ b/rules/windows/defense_evasion_windows_filtering_platform.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -97,6 +97,42 @@ sequence by winlog.computer_name with maxspan=1m
         "splunk.exe", "sysmon.exe", "sysmon64.exe", "taniumclient.exe"
     )] with runs=5
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Evasion via Windows Filtering Platform
+
+The Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for network filtering and packet processing. Adversaries may exploit WFP by creating malicious rules to block endpoint security processes, hindering their ability to send telemetry data. The detection rule identifies patterns of blocked network events linked to security software processes, signaling potential evasion tactics.
+
+### Possible investigation steps
+
+- Review the specific network events that triggered the alert, focusing on the event.action values "windows-firewall-packet-block" and "windows-firewall-packet-drop" to understand which processes were blocked.
+- Identify the process names involved in the alert from the process.name field and verify if they are related to known endpoint security software, as listed in the query.
+- Check the winlog.computer_name field to determine which systems are affected and assess if multiple systems are involved, indicating a broader issue.
+- Investigate the recent changes to the Windows Filtering Platform rules on the affected systems to identify any unauthorized or suspicious modifications.
+- Correlate the blocked events with any recent security incidents or alerts to determine if there is a pattern or ongoing attack.
+- Consult system logs and security software logs on the affected systems for additional context or anomalies around the time of the alert.
+- Engage with the system or network administrators to verify if any legitimate changes were made to the WFP rules that could explain the blocked events.
+
+### False positive analysis
+
+- Security software updates or installations can trigger multiple block events as they modify network configurations. Users should monitor for these events during known update windows and consider excluding them from alerts.
+- Legitimate network troubleshooting or diagnostic tools may temporarily block network traffic as part of their operation. Identify these tools and create exceptions for their processes to prevent false alerts.
+- Custom security configurations or policies in enterprise environments might intentionally block certain network activities. Review and document these configurations to differentiate between expected behavior and potential threats.
+- Temporary network disruptions or misconfigurations can cause legitimate security processes to be blocked. Regularly audit network settings and ensure they align with security policies to minimize these occurrences.
+- Scheduled maintenance or testing of security systems might result in blocked events. Coordinate with IT teams to whitelist these activities during planned maintenance periods.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration.
+- Terminate any suspicious processes identified in the alert, particularly those related to endpoint security software, to restore normal security operations.
+- Review and remove any unauthorized or suspicious Windows Filtering Platform rules that may have been added to block security processes.
+- Conduct a thorough scan of the affected system using a trusted antivirus or endpoint detection and response (EDR) tool to identify and remove any malware or persistent threats.
+- Restore any affected security software to its default configuration and ensure it is fully operational and updated.
+- Monitor network traffic and system logs for any signs of continued evasion tactics or re-infection attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_bash_exec.toml b/rules/windows/defense_evasion_wsl_bash_exec.toml
index 28b232f3d9d..79a1da37f21 100644
--- a/rules/windows/defense_evasion_wsl_bash_exec.toml
+++ b/rules/windows/defense_evasion_wsl_bash_exec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,40 @@ process where host.os.type == "windows" and event.type : "start" and
   ) and 
     not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Execution via Windows Subsystem for Linux
+
+Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats.
+
+### Possible investigation steps
+
+- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question.
+- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe.
+- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl.
+- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns.
+- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender for Endpoint, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident.
+
+### False positive analysis
+
+- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise.
+- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes.
+- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts.
+- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list.
+- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments.
+- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations.
+- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment.
+- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed.
+- 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 enhanced monitoring and logging for WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_child_process.toml b/rules/windows/defense_evasion_wsl_child_process.toml
index eb1713f9cfb..f072aac0692 100644
--- a/rules/windows/defense_evasion_wsl_child_process.toml
+++ b/rules/windows/defense_evasion_wsl_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -70,6 +70,41 @@ process where host.os.type == "windows" and event.type : "start" and
       )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution via Windows Subsystem for Linux
+
+Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables.
+- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks.
+- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised.
+- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host.
+- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or SentinelOne to identify any related suspicious activities or patterns.
+- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly.
+
+### False positive analysis
+
+- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL.
+- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts.
+- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives.
+- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations.
+- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list.
+- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations.
+- Remove any unauthorized or malicious scripts and binaries found within the WSL environment.
+- Restore the system from a known good backup if malicious activity has compromised system integrity.
+- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_filesystem.toml b/rules/windows/defense_evasion_wsl_filesystem.toml
index eb37721421f..29f11f5ca87 100644
--- a/rules/windows/defense_evasion_wsl_filesystem.toml
+++ b/rules/windows/defense_evasion_wsl_filesystem.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,40 @@ sequence by process.entity_id with maxspan=5m
   process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"]
  [file where host.os.type == "windows" and process.name : "dllhost.exe" and not file.path : "?:\\Users\\*\\Downloads\\*"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Host Files System Changes via Windows Subsystem for Linux
+
+Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows, facilitating seamless file access between systems. Adversaries may exploit WSL to modify host files stealthily, bypassing traditional security measures. The detection rule identifies suspicious file operations initiated by WSL processes, particularly those involving the Plan9FileSystem, to flag potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the process details for the "dllhost.exe" instance that triggered the alert, focusing on the command line arguments to confirm the presence of the Plan9FileSystem CLSID "{DFB65C4C-B34F-435D-AFE9-A86218684AA8}".
+- Examine the file paths involved in the alert to determine if any sensitive or critical files were accessed or modified outside of typical user directories, excluding the Downloads folder.
+- Investigate the parent process of "dllhost.exe" to understand the context of its execution and identify any potentially malicious parent processes.
+- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or related alerts that may indicate a broader attack pattern.
+- Correlate the alert with user activity logs to determine if the actions were performed by a legitimate user or if there are signs of compromised credentials or unauthorized access.
+
+### False positive analysis
+
+- Routine file operations by legitimate applications using WSL may trigger alerts. Identify and whitelist these applications to prevent unnecessary alerts.
+- Development activities involving WSL, such as compiling code or running scripts, can generate false positives. Exclude specific development directories or processes from monitoring.
+- Automated backup or synchronization tools that interact with WSL might be flagged. Configure exceptions for these tools by specifying their process names or file paths.
+- System maintenance tasks that involve WSL, like updates or system checks, could be mistaken for suspicious activity. Schedule these tasks during known maintenance windows and adjust monitoring rules accordingly.
+- Frequent downloads or file transfers to directories outside the typical user download paths may appear suspicious. Define clear policies for acceptable file paths and exclude them from alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes associated with "dllhost.exe" that are linked to the Plan9FileSystem CLSID to stop ongoing malicious activities.
+- Conduct a thorough review of recent file changes on the host system to identify and restore any unauthorized modifications or deletions.
+- Revoke any unauthorized access or permissions granted to WSL that may have been exploited by the adversary.
+- Update and patch the Windows Subsystem for Linux and related components to mitigate any known vulnerabilities that could be exploited.
+- Monitor for any recurrence of similar activities by setting up alerts for processes and file operations involving "dllhost.exe" and the Plan9FileSystem.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/defense_evasion_wsl_kalilinux.toml b/rules/windows/defense_evasion_wsl_kalilinux.toml
index 5e45f738e56..f9a8bc1091e 100644
--- a/rules/windows/defense_evasion_wsl_kalilinux.toml
+++ b/rules/windows/defense_evasion_wsl_kalilinux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,40 @@ process where host.os.type == "windows" and event.type == "start" and
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Install Kali Linux via WSL
+
+Windows Subsystem for Linux (WSL) allows users to run Linux distributions on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to install Kali Linux, a penetration testing distribution, to evade detection by traditional Windows security tools. The detection rule identifies suspicious processes and file paths associated with Kali Linux installations, flagging potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of "wsl.exe" with arguments indicating an attempt to install or use Kali Linux, such as "-d", "--distribution", "-i", or "--install".
+- Check the file paths associated with the Kali Linux installation, such as "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*" or "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe", to verify if the installation files exist on the system.
+- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+- Assess the risk and impact of the detected activity by considering the context of the environment and any potential threats posed by the use of Kali Linux on the system.
+
+### False positive analysis
+
+- Legitimate use of Kali Linux for development or educational purposes may trigger the rule. Users can create exceptions for specific user accounts or groups known to use Kali Linux for authorized activities.
+- Automated scripts or deployment tools that install or configure Kali Linux as part of a legitimate IT process might be flagged. Consider whitelisting these scripts or processes by their hash or path.
+- Security researchers or IT professionals conducting penetration testing on a Windows machine may cause false positives. Implement user-based exclusions for these professionals to prevent unnecessary alerts.
+- System administrators testing WSL features with various Linux distributions, including Kali, could inadvertently trigger the rule. Establish a policy to document and approve such activities, then exclude them from detection.
+- Training environments where Kali Linux is used to teach cybersecurity skills might be mistakenly flagged. Set up environment-specific exclusions to avoid disrupting educational activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent any potential lateral movement or data exfiltration.
+- Terminate any suspicious processes related to the Kali Linux installation attempt, specifically those involving `wsl.exe` with arguments indicating a Kali distribution.
+- Remove any unauthorized installations of Kali Linux by deleting associated files and directories, such as those found in `AppData\\\\Local\\\\packages\\\\kalilinux*` or `Program Files*\\\\WindowsApps\\\\KaliLinux.*`.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- 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 additional monitoring and alerting for similar activities across the network, focusing on WSL usage and installation attempts of known penetration testing tools.
+- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats, leveraging data sources like Microsoft Defender for Endpoint and Sysmon."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_active_directory_webservice.toml b/rules/windows/discovery_active_directory_webservice.toml
index e43e63aa66c..7b899f87244 100644
--- a/rules/windows/discovery_active_directory_webservice.toml
+++ b/rules/windows/discovery_active_directory_webservice.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,40 @@ sequence by process.entity_id with maxspan=3m
  [network where host.os.type == "windows" and destination.port == 9389 and source.port >= 49152 and
   network.direction == "egress" and network.transport == "tcp" and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Enumeration via Active Directory Web Service
+
+Active Directory Web Service (ADWS) facilitates querying Active Directory (AD) over a network, providing a web-based interface for directory services. Adversaries may exploit ADWS to enumerate network resources and user accounts, gaining insights into the environment. The detection rule identifies suspicious activity by monitoring processes that load AD-related modules and establish network connections to the ADWS port, indicating potential unauthorized enumeration attempts.
+
+### Possible investigation steps
+
+- Review the process entity ID to identify the specific process that triggered the alert and gather details such as the process name, executable path, and user context.
+- Examine the user ID associated with the process to determine if it belongs to a legitimate user or service account, and verify if the user has a history of accessing Active Directory resources.
+- Investigate the network connection details, focusing on the destination IP address and port 9389, to identify the target server and assess if it is a legitimate Active Directory Web Service endpoint.
+- Check for any recent changes or unusual activity on the host machine, such as new software installations or configuration changes, that could explain the loading of Active Directory-related modules.
+- Correlate the alert with other security events or logs from the same timeframe to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts may load Active Directory-related modules and connect to the ADWS port. To handle this, create exceptions for known administrative processes that regularly perform these actions.
+- Scheduled tasks or automated scripts running under service accounts might trigger the rule. Identify these tasks and exclude their associated user IDs or process paths from the detection rule.
+- Security or monitoring software that queries Active Directory for legitimate purposes can cause false positives. Review and whitelist these applications by adding their executable paths to the exclusion list.
+- Development or testing environments where developers frequently interact with Active Directory services may generate alerts. Consider excluding specific user IDs or process paths associated with these environments to reduce noise.
+- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or administrative practices.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified in the alert that are loading Active Directory-related modules and making network connections to the ADWS port.
+- Conduct a thorough review of the affected system's user accounts and permissions to identify any unauthorized changes or access.
+- Reset credentials for any accounts that were potentially compromised or used in the suspicious activity.
+- Implement network segmentation to limit access to the ADWS port (9389) to only trusted systems and users.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update and enhance monitoring rules to detect similar enumeration attempts in the future, focusing on unusual process behavior and network connections to critical services."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_high_number_ad_properties.toml b/rules/windows/discovery_high_number_ad_properties.toml
index 0b6dad34e2a..980639372cd 100644
--- a/rules/windows/discovery_high_number_ad_properties.toml
+++ b/rules/windows/discovery_high_number_ad_properties.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,40 @@ any where event.action in ("Directory Service Access", "object-operation-perform
  event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and
  winlog.event_data.AccessMaskDescription == "Read Property" and length(winlog.event_data.Properties) >= 2000
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Access to LDAP Attributes
+
+LDAP (Lightweight Directory Access Protocol) is crucial for querying and modifying directory services like Active Directory, which stores user credentials and permissions. Adversaries exploit LDAP to enumerate directory attributes, seeking vulnerabilities or sensitive data. The detection rule identifies unusual read access patterns, such as excessive attribute queries, which may indicate reconnaissance or privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code 4662 to gather details about the suspicious read access, focusing on the winlog.event_data.Properties field to understand which attributes were accessed.
+- Identify the user associated with the suspicious activity by examining the winlog.event_data.SubjectUserSid field, and determine if this user has a legitimate reason to access a high number of Active Directory object attributes.
+- Check the user's recent activity and login history to identify any unusual patterns or anomalies that could indicate compromised credentials or unauthorized access.
+- Investigate the source machine from which the LDAP queries originated to determine if it is a known and trusted device or if it shows signs of compromise or unauthorized use.
+- Correlate this event with other security alerts or logs to identify if this activity is part of a larger pattern of reconnaissance or privilege escalation attempts within the network.
+
+### False positive analysis
+
+- Regular system maintenance or updates may trigger high attribute read access. Exclude known maintenance accounts from the rule to prevent false alerts.
+- Automated scripts or applications that query Active Directory for legitimate purposes can cause excessive attribute reads. Identify and whitelist these scripts or applications to reduce noise.
+- Security audits or compliance checks often involve extensive directory queries. Coordinate with IT and security teams to recognize these activities and adjust the rule to exclude them.
+- Service accounts with legitimate high-volume access patterns should be reviewed and, if deemed non-threatening, added to an exception list to avoid unnecessary alerts.
+- Consider the context of the access, such as time of day or associated user activity, to differentiate between normal and suspicious behavior. Adjust the rule to account for these patterns where applicable.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of the user account associated with the suspicious LDAP access to determine if it has been compromised. Reset the account credentials and enforce multi-factor authentication.
+- Analyze the event logs to identify any other systems or accounts that may have been accessed using similar methods, and apply the same containment measures.
+- 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 LDAP queries and Active Directory access to detect similar patterns of excessive attribute queries in the future.
+- Review and tighten access controls and permissions within Active Directory to ensure that only necessary attributes are accessible to users based on their roles.
+- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence of similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
index 6c49a43316c..19bd22e270b 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,41 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
   "c4e9ed3e-55a2-4309-a012-bc3c78dad10a" or "51176ed2-2d90-49f2-9f3d-17196428b169"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Discovery Signal Alert with Unusual Process Command Line
+
+This detection rule identifies anomalies in process command lines on Windows systems, which may indicate adversarial reconnaissance activities. Attackers often exploit legitimate discovery tools to gather system information stealthily. By monitoring unique combinations of host, user, and command line data, the rule flags deviations from normal behavior, helping analysts pinpoint potential threats early.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id, user.id, and process.command_line that triggered the alert. This will help in understanding the context of the anomaly.
+- Check the historical activity of the identified host.id and user.id to determine if the process.command_line has been executed previously and assess if this behavior is truly unusual.
+- Investigate the process.command_line for any known malicious patterns or suspicious commands that could indicate reconnaissance or other adversarial activities.
+- Correlate the alert with other security events or logs from the same host or user around the same time to identify any additional suspicious activities or patterns.
+- Consult threat intelligence sources to see if the process.command_line or any associated indicators have been reported in recent threat campaigns or advisories.
+- If necessary, isolate the affected host to prevent potential lateral movement or further compromise while the investigation is ongoing.
+
+### False positive analysis
+
+- Legitimate administrative tools may trigger alerts when used by IT staff for routine system checks. To manage this, create exceptions for known safe tools and processes frequently used by trusted users.
+- Automated scripts or scheduled tasks that perform regular system audits can be flagged as unusual. Identify these scripts and add them to an allowlist to prevent unnecessary alerts.
+- Software updates or installations that involve system discovery commands might be misidentified as threats. Monitor update schedules and exclude related processes during these times.
+- Security software performing scans or inventory checks can mimic adversarial reconnaissance. Verify the processes associated with these tools and configure the rule to ignore them.
+- New software deployments or changes in system configurations may temporarily alter normal command line behavior. Document these changes and adjust the rule settings to accommodate expected deviations.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement or data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis.
+- Terminate any suspicious processes identified by the alert, especially those with unusual command lines, to halt any ongoing malicious activity.
+- Conduct a thorough review of the affected user's account for any unauthorized access or privilege escalation. Reset passwords and revoke any unnecessary permissions.
+- Analyze the command line arguments and process execution context to understand the scope and intent of the reconnaissance activity. This may involve reviewing logs and correlating with other security events.
+- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected. Ensure the backup is free from compromise.
+- Update endpoint protection and intrusion detection systems with the latest threat intelligence to enhance detection capabilities against similar reconnaissance activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the activity is part of a larger attack campaign."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
index b39b57e1999..a9003d91c7e 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,41 @@ type = "new_terms"
 query = '''
 host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:"1d72d014-e2ab-4707-b056-9b96abe7b511"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Discovery Signal Alert with Unusual Process Executable
+
+In Windows environments, discovery activities often involve querying system information, which adversaries exploit to gather intelligence for further attacks. They may use uncommon processes to evade detection. This detection rule identifies anomalies by flagging signals with rare host, user, and process combinations, indicating potential misuse of discovery tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id, user.id, and process.executable involved in the alert to understand the context of the unusual activity.
+- Check the historical activity of the identified host.id and user.id to determine if this combination has been seen before and assess if the behavior is truly anomalous.
+- Investigate the process.executable to verify its legitimacy, including checking its file path, digital signature, and any known associations with legitimate or malicious software.
+- Correlate the alert with other security events or logs from the same host or user to identify any additional suspicious activities or patterns that may indicate a broader threat.
+- Consult threat intelligence sources to determine if the process.executable or any related indicators are associated with known threat actors or campaigns.
+- Assess the potential impact and risk of the activity by considering the host's role within the network and the user's access level to sensitive data or systems.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts if they involve uncommon processes. Identify these tasks and create exceptions for known benign activities to prevent unnecessary alerts.
+- Software updates or installations can generate unusual process executions. Monitor and document these events, and exclude them from alerts if they are verified as legitimate.
+- Custom scripts or tools used by IT staff for system management might be flagged. Review these scripts and whitelist them if they are part of regular operations.
+- Automated processes or scheduled tasks that run under specific user accounts may appear suspicious. Verify these tasks and exclude them if they are part of normal system behavior.
+- Third-party security or monitoring tools might use unique processes for legitimate discovery activities. Validate these tools and add them to the exception list to avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement or data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis.
+- Terminate the unusual process executable identified in the alert to halt any ongoing malicious activity. Use task management tools or scripts to ensure the process is stopped.
+- Conduct a thorough review of the user account associated with the alert. Reset the account credentials and enforce multi-factor authentication to prevent unauthorized access.
+- Analyze the process executable and its origin. Check for any associated files or scripts that may have been dropped on the system and remove them.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring on the affected host and user account to detect any further suspicious activities. Use enhanced logging and alerting to capture detailed information.
+- Review and update endpoint protection policies to block similar unusual processes in the future, ensuring that the security tools are configured to detect and respond to such anomalies."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
index e80673b2bbd..d72891b5a05 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,41 @@ process.parent.name: (
      "SolarwindsDiagnostics*.exe"
      )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Command Execution via SolarWinds Process
+
+SolarWinds is a widely used IT management tool that can be targeted by adversaries to execute unauthorized commands. Attackers may exploit SolarWinds processes to launch command-line interpreters like Cmd.exe or Powershell.exe, potentially leading to system compromise. The detection rule identifies suspicious child processes initiated by specific SolarWinds executables, flagging potential misuse by correlating process start events with known SolarWinds parent processes. This helps in early detection of malicious activities leveraging SolarWinds for command execution.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) and note the exact executable name and path.
+- Examine the timeline of events around the process start event to identify any preceding or subsequent suspicious activities, such as unusual network connections or file modifications.
+- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
+- Investigate the command line arguments used by the child process to assess if they contain any malicious or unexpected commands.
+- Correlate the event with other security logs and alerts from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and identify potential patterns of malicious behavior.
+- Assess the system's current state for any indicators of compromise, such as unauthorized changes to system configurations or the presence of known malware signatures.
+
+### False positive analysis
+
+- Routine administrative tasks using SolarWinds may trigger the rule when legitimate scripts are executed via Cmd.exe or Powershell.exe. Users can create exceptions for known maintenance scripts or tasks that are regularly scheduled and verified as safe.
+- Automated updates or patches initiated by SolarWinds processes might be flagged. To mitigate this, users should whitelist specific update processes or scripts that are part of the regular update cycle.
+- Monitoring or diagnostic activities performed by IT staff using SolarWinds tools can result in false positives. Establish a baseline of normal activities and exclude these from alerts by identifying and documenting regular diagnostic commands.
+- Custom scripts developed for internal use that leverage SolarWinds processes could be misidentified as threats. Ensure these scripts are reviewed and approved, then add them to an exception list to prevent unnecessary alerts.
+- Third-party integrations with SolarWinds that require command execution might be mistakenly flagged. Verify the legitimacy of these integrations and exclude their associated processes from detection rules.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement.
+- Terminate any suspicious child processes such as Cmd.exe or Powershell.exe that were initiated by the identified SolarWinds parent processes.
+- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise.
+- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed.
+- Update and patch the SolarWinds software and any other vulnerable applications on the affected system to mitigate known vulnerabilities.
+- Implement application whitelisting to prevent unauthorized execution of command-line interpreters from SolarWinds processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
index 1d85e3cce88..4d76d9499b7 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.type == "start" and
  ) and
  not process.executable : ("?:\\Windows\\SysWOW64\\ARP.EXE", "?:\\Windows\\SysWOW64\\lodctr.exe", "?:\\Windows\\SysWOW64\\unlodctr.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious SolarWinds Child Process
+
+SolarWinds is a widely used IT management software that operates critical network and system monitoring functions. Adversaries may exploit its trusted processes to execute unauthorized programs, leveraging its elevated privileges to bypass security controls. The detection rule identifies unusual child processes spawned by SolarWinds' core services, excluding known legitimate operations, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the details of the triggered alert to identify the specific child process name and executable path that caused the alert.
+- Check the parent process details, specifically SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, to confirm its legitimacy and ensure it is running from the expected directory.
+- Investigate the child process's code signature to determine if it is trusted or if there are any anomalies in the signature that could indicate tampering.
+- Analyze the historical activity of the suspicious child process on the host to identify any patterns or previous instances of execution that could provide context.
+- Correlate the suspicious process activity with other security events or logs from the same host to identify any related malicious behavior or indicators of compromise.
+- Consult threat intelligence sources to determine if the suspicious process or executable path is associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate SolarWinds updates or patches may trigger the rule. Ensure that the process code signature is verified as trusted and matches known update signatures.
+- Custom scripts or tools integrated with SolarWinds for automation purposes might be flagged. Review these processes and add them to the exclusion list if they are verified as safe and necessary for operations.
+- Third-party plugins or extensions that interact with SolarWinds could be misidentified. Validate these plugins and consider excluding them if they are from a trusted source and essential for functionality.
+- Scheduled tasks or maintenance activities that involve SolarWinds processes may appear suspicious. Confirm these tasks are part of regular operations and exclude them if they are consistent with expected behavior.
+- Temporary diagnostic or troubleshooting tools used by IT staff might be detected. Ensure these tools are authorized and add them to the exclusion list if they are frequently used and pose no threat.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious child processes identified that are not part of the known legitimate operations list, ensuring that no malicious programs continue to execute.
+- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or unauthorized changes.
+- Restore the affected system from a known good backup to ensure that any potential malware or unauthorized changes are removed.
+- Update all SolarWinds software and related components to the latest versions to patch any known vulnerabilities that could be exploited.
+- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of suspicious activity, focusing on unusual child processes spawned by SolarWinds services.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts need to be addressed."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_com_object_xwizard.toml b/rules/windows/execution_com_object_xwizard.toml
index d0f0f60ae02..bfaaa10fd00 100644
--- a/rules/windows/execution_com_object_xwizard.toml
+++ b/rules/windows/execution_com_object_xwizard.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,40 @@ process where host.os.type == "windows" and event.type == "start" and
    )
  )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution of COM object via Xwizard
+
+The Windows Component Object Model (COM) facilitates communication between software components. Adversaries exploit this by using Xwizard to execute COM objects, bypassing security measures. The detection rule identifies suspicious Xwizard executions by monitoring process starts, checking for unusual arguments, and verifying executable paths, thus flagging potential misuse of COM objects for malicious activities.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the presence of xwizard.exe execution, focusing on the process.name and process.pe.original_file_name fields.
+- Examine the process.args field to identify any unusual or suspicious arguments, particularly looking for the "RunWizard" command and any GUIDs or patterns that may indicate malicious activity.
+- Verify the process.executable path to ensure it matches the expected system paths (C:\\Windows\\SysWOW64\\xwizard.exe or C:\\Windows\\System32\\xwizard.exe). Investigate any deviations from these paths as potential indicators of compromise.
+- Check the parent process of xwizard.exe to understand the context of its execution and identify any potentially malicious parent processes.
+- Correlate the event with other security data sources such as Microsoft Defender for Endpoint or Sysmon logs to gather additional context and identify any related suspicious activities or patterns.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential unauthorized access or privilege escalation.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they use Xwizard to execute COM objects. Users can create exceptions for known software update processes by verifying the executable paths and arguments.
+- System administrators might use Xwizard for legitimate configuration tasks. To handle this, identify and document regular administrative activities and exclude these from the rule by specifying the expected process arguments and executable paths.
+- Automated scripts or management tools that utilize Xwizard for system management tasks can cause false positives. Review and whitelist these scripts or tools by ensuring their execution paths and arguments are consistent with known safe operations.
+- Some security tools or monitoring solutions might use Xwizard as part of their normal operations. Confirm these activities with the tool's documentation and exclude them by adding their specific execution patterns to the exception list.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious xwizard.exe processes identified by the detection rule to halt potential malicious execution.
+- Conduct a thorough review of the system's registry for unauthorized COM objects and remove any entries that are not recognized or are deemed malicious.
+- Restore the system from a known good backup if unauthorized changes or persistent threats are detected.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Monitor the network for any signs of similar activity or related threats, ensuring that detection systems are tuned to identify variations of this attack.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_command_shell_started_by_unusual_process.toml b/rules/windows/execution_command_shell_started_by_unusual_process.toml
index 437d881b36d..e36ce13cb64 100644
--- a/rules/windows/execution_command_shell_started_by_unusual_process.toml
+++ b/rules/windows/execution_command_shell_started_by_unusual_process.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,42 @@ process where host.os.type == "windows" and event.type == "start" and
                          "wlanext.exe" ) and
   not (process.parent.name : "dllhost.exe" and process.parent.args : "/Processid:{CA8C87C1-929D-45BA-94DB-EF8E6CB346AD}")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Parent Process for cmd.exe
+
+Cmd.exe is a command-line interpreter on Windows systems, often used for legitimate administrative tasks. However, adversaries can exploit it by launching it from atypical parent processes to execute malicious commands stealthily. The detection rule identifies such anomalies by flagging cmd.exe instances spawned by uncommon parent processes, which may indicate unauthorized or suspicious activity, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the process tree to understand the context in which cmd.exe was launched, focusing on the parent process identified in the alert.
+- Investigate the parent process by examining its command-line arguments, start time, and any associated network activity to determine if it is behaving anomalously.
+- Check the historical behavior of the parent process to see if it has previously spawned cmd.exe or if this is an unusual occurrence.
+- Analyze any child processes spawned by the cmd.exe instance to identify potentially malicious activities or commands executed.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns.
+- Assess the user account associated with the cmd.exe process to determine if it has been compromised or is exhibiting unusual behavior.
+- Consult threat intelligence sources to see if the parent process or its behavior is associated with known malware or attack techniques.
+
+### False positive analysis
+
+- Cmd.exe instances spawned by legitimate system maintenance tools like Windows Update or system indexing services can trigger false positives. Users can create exceptions for processes like SearchIndexer.exe or WUDFHost.exe if they are verified as part of routine system operations.
+- Software updates or installations that use cmd.exe for scripting purposes might be flagged. If GoogleUpdate.exe or FlashPlayerUpdateService.exe are known to be part of regular update processes, consider excluding them after confirming their legitimacy.
+- Administrative scripts or tools that are scheduled to run via Task Scheduler might use cmd.exe and be flagged. If taskhostw.exe is a known parent process for these tasks, verify and exclude it to prevent unnecessary alerts.
+- Certain third-party applications might use cmd.exe for legitimate background tasks. If applications like jusched.exe or jucheck.exe are identified as part of trusted software, they can be excluded after validation.
+- System recovery or diagnostic tools that interact with cmd.exe could be misidentified. If WerFault.exe or wermgr.exe are part of these processes, ensure they are legitimate and exclude them accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate the suspicious cmd.exe process and its parent process to halt any ongoing malicious activity.
+- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized changes or additional compromised processes.
+- Restore any altered or deleted files from a known good backup to ensure system integrity.
+- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats.
+- 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 enhanced monitoring and logging for cmd.exe and its parent processes to detect similar anomalies in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_command_shell_via_rundll32.toml b/rules/windows/execution_command_shell_via_rundll32.toml
index f19d1e775db..46d47e879fb 100644
--- a/rules/windows/execution_command_shell_via_rundll32.toml
+++ b/rules/windows/execution_command_shell_via_rundll32.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,41 @@ process where host.os.type == "windows" and event.type == "start" and
   not process.parent.args : ("C:\\Windows\\System32\\SHELL32.dll,RunAsNewUser_RunDLL",
                              "C:\\WINDOWS\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Command Shell Activity Started via RunDLL32
+
+RunDLL32 is a legitimate Windows utility used to execute functions in DLLs, often leveraged by attackers to run malicious code stealthily. Adversaries exploit it to launch command shells like cmd.exe or PowerShell, bypassing security controls. The detection rule identifies such abuse by monitoring for command shells initiated by RunDLL32, excluding known benign patterns, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the parent-child relationship between rundll32.exe and the command shell (cmd.exe or powershell.exe) to ensure the alert is not a false positive.
+- Examine the command line arguments of rundll32.exe to identify any suspicious or unusual DLLs or functions being executed, excluding known benign patterns.
+- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Investigate the source and destination network connections associated with the process to identify any suspicious or unauthorized communication.
+- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise.
+- Review recent changes or activities on the host, such as software installations or updates, that might explain the execution of rundll32.exe with command shells.
+
+### False positive analysis
+
+- Known false positives include command shells initiated by RunDLL32 for legitimate administrative tasks or software installations.
+- Exclude command lines that match common benign patterns, such as those involving SHELL32.dll or temporary files used by trusted applications.
+- Regularly update the list of exceptions to include new benign patterns identified through monitoring and analysis.
+- Collaborate with IT and security teams to identify and document legitimate use cases of RunDLL32 in your environment.
+- Use process monitoring tools to verify the legitimacy of command shells started by RunDLL32, ensuring they align with expected behavior.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as cmd.exe or powershell.exe that were initiated by rundll32.exe to halt potential 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 files or remnants.
+- Review and analyze the rundll32.exe command line arguments to understand the scope and intent of the activity, and identify any additional compromised systems or accounts.
+- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access.
+- 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 enhanced monitoring and logging for rundll32.exe and related processes to detect similar activities in the future and improve response times."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
index 1fe398d770d..7dcd6f690f9 100644
--- a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
+++ b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,41 @@ sequence by process.parent.entity_id with maxspan=1m
                      "?:\\Users\\*\\AppData\\Local\\Temp\\QBTools\\"))
     ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Delayed Execution via Ping
+
+Ping, a network utility, can be misused by attackers to delay execution of malicious commands, aiding in evasion. Adversaries may use ping to introduce pauses, allowing them to execute harmful scripts or binaries stealthily. The detection rule identifies suspicious ping usage followed by execution of known malicious utilities, flagging potential threats by monitoring specific command patterns and excluding benign processes.
+
+### Possible investigation steps
+
+- Review the process tree to understand the sequence of events, focusing on the parent-child relationship between cmd.exe, ping.exe, and any subsequent suspicious processes like rundll32.exe or powershell.exe.
+- Examine the command line arguments used with ping.exe to determine the delay introduced and assess if it aligns with typical malicious behavior.
+- Investigate the user account associated with the process execution, especially if the user.id is not S-1-5-18, to determine if the account has been compromised or is being misused.
+- Check the file path and code signature of any executables launched from the user's AppData directory to verify if they are trusted or potentially malicious.
+- Analyze the command line arguments and working directory of any suspicious processes to identify any known malicious patterns or scripts being executed.
+- Correlate the alert with any other recent alerts or logs from the same host or user to identify potential patterns or ongoing malicious activity.
+
+### False positive analysis
+
+- Legitimate administrative scripts or maintenance tasks may use ping to introduce delays, especially in batch files executed by system administrators. To handle this, identify and exclude specific scripts or command lines that are known to be safe.
+- Software installations or updates might use ping for timing purposes. Review the command lines and parent processes involved, and create exceptions for trusted software paths or signatures.
+- Automated testing environments may use ping to simulate network latency or wait for services to start. Exclude these processes by identifying the testing framework or environment and adding it to the exception list.
+- Some legitimate applications might use ping as part of their normal operation. Monitor these applications and, if verified as safe, exclude their specific command patterns or executable paths.
+- Regularly review and update the exception list to ensure it reflects the current environment and any new legitimate use cases that arise.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified in the alert, such as those involving ping.exe followed by the execution of known malicious utilities.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software.
+- Review and analyze the command history and logs of the affected system to understand the scope of the attack and identify any additional compromised systems.
+- Restore the system from a known good backup if malware removal is not feasible or if the system's integrity is in question.
+- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the alert.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_downloaded_shortcut_files.toml b/rules/windows/execution_downloaded_shortcut_files.toml
index 43fbff23e7a..ed5486f4fe6 100644
--- a/rules/windows/execution_downloaded_shortcut_files.toml
+++ b/rules/windows/execution_downloaded_shortcut_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,40 @@ type = "eql"
 query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension == "lnk" and file.Ext.windows.zone_identifier > 1
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Downloaded Shortcut Files
+
+Shortcut files (.lnk) are used in Windows environments to link to executable files or scripts, streamlining user access. Adversaries exploit this by embedding malicious commands in these files, often distributing them via phishing. The detection rule identifies suspicious .lnk files created on Windows systems, especially those downloaded from external sources, indicating potential phishing attempts. This is achieved by monitoring file creation events and zone identifiers, which help trace the file's origin.
+
+### Possible investigation steps
+
+- Review the file creation event details to identify the specific .lnk file and its associated metadata, such as the file path and creation timestamp.
+- Examine the zone identifier value to confirm that the file was indeed downloaded from an external source, as indicated by a value greater than 1.
+- Investigate the source of the download by checking network logs or browser history to identify the URL or IP address from which the .lnk file was downloaded.
+- Analyze the contents of the .lnk file to detect any embedded commands or scripts that may indicate malicious intent.
+- Check for any related alerts or events on the same host around the time of the .lnk file creation to identify potential follow-up actions or additional threats.
+- Assess the user account associated with the file creation event to determine if the account has been compromised or if the user was targeted in a phishing campaign.
+
+### False positive analysis
+
+- Corporate software deployments may trigger the rule when legitimate .lnk files are distributed across the network. Users can create exceptions for known software distribution servers to prevent these false positives.
+- Automated backup or synchronization tools that create .lnk files as part of their normal operation can be mistaken for threats. Identifying and excluding these tools from the rule can reduce unnecessary alerts.
+- User-created shortcuts for frequently accessed network resources might be flagged. Monitoring and excluding specific user activities or directories where these shortcuts are commonly created can help manage these false positives.
+- Some legitimate applications may download .lnk files as part of their update process. Identifying these applications and adding them to an exception list can prevent false alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat.
+- Quarantine the suspicious .lnk file to prevent execution and further analysis.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
+- Review and remove any unauthorized or suspicious user accounts or privileges that may have been created or altered as a result of the phishing attempt.
+- Restore the system from a known good backup if any critical system files or configurations have been compromised.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Update security policies and rules to block similar phishing attempts in the future, such as restricting the execution of .lnk files from untrusted sources."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_downloaded_url_file.toml b/rules/windows/execution_downloaded_url_file.toml
index 8b72e8d4a46..77fedd4cb3c 100644
--- a/rules/windows/execution_downloaded_url_file.toml
+++ b/rules/windows/execution_downloaded_url_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/06"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,41 @@ query = '''
 file where host.os.type == "windows" and event.type == "creation" and file.extension == "url"
    and file.Ext.windows.zone_identifier > 1 and not process.name : "explorer.exe"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Downloaded URL Files
+
+URL shortcut files, typically used for quick access to web resources, can be exploited by attackers in phishing schemes to execute malicious content. These files, when downloaded from non-local sources, may bypass traditional security measures. The detection rule identifies such files by monitoring their creation events on Windows systems, focusing on those not initiated by standard processes like Explorer, and flags them based on their network origin, aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the file creation event details to confirm the file extension is ".url" and verify the zone identifier is greater than 1, indicating a non-local source.
+- Investigate the process that created the .url file, ensuring it was not initiated by "explorer.exe" and identify the actual process responsible for the creation.
+- Check the network origin of the downloaded .url file to determine if it is from a known malicious domain or IP address.
+- Analyze the contents of the .url file to identify the target URL and assess its reputation and potential risk.
+- Correlate the event with other security alerts or logs from the same host to identify any additional suspicious activities or patterns.
+- Contact the user associated with the alert to verify if they intentionally downloaded the file and gather any additional context regarding their actions.
+
+### False positive analysis
+
+- Corporate applications that generate .url files for legitimate purposes may trigger alerts. Identify these applications and create exceptions for their processes to prevent unnecessary alerts.
+- Automated scripts or system management tools that download .url files as part of routine operations can be mistaken for threats. Review these tools and whitelist their activities if they are verified as safe.
+- User-initiated downloads from trusted internal web portals might be flagged. Educate users on safe downloading practices and consider excluding specific trusted domains from monitoring.
+- Security software updates or patches that include .url files could be misidentified. Verify the source of these updates and adjust the rule to exclude known safe update processes.
+- Collaboration platforms that share .url files for internal use may cause false positives. Evaluate the platform's behavior and exclude its processes if they are deemed secure.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of any potential malicious activity.
+- Terminate any suspicious processes that are not initiated by standard processes like Explorer, especially those related to the creation of .url files.
+- Delete the identified .url files from the system to remove the immediate threat.
+- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats.
+- Review and analyze the network logs to identify any other systems that may have downloaded similar .url files and apply the same containment measures.
+- Escalate the incident to the security operations team for further investigation and to determine if there is a broader campaign targeting the organization.
+- Update security policies and endpoint protection configurations to block the download and execution of .url files from untrusted sources in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_enumeration_via_wmiprvse.toml b/rules/windows/execution_enumeration_via_wmiprvse.toml
index dce7b4392db..df8dd1c0616 100644
--- a/rules/windows/execution_enumeration_via_wmiprvse.toml
+++ b/rules/windows/execution_enumeration_via_wmiprvse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,41 @@ process where host.os.type == "windows" and event.type == "start" and process.co
   ) and
   not process.args : "tenable_mw_scan"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Enumeration Command Spawned via WMIPrvSE
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute enumeration commands stealthily, leveraging the WMI Provider Service (WMIPrvSE) to gather system and network information. The detection rule identifies suspicious command executions initiated by WMIPrvSE, focusing on common enumeration tools while excluding benign use cases, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process command line details to understand the specific enumeration command executed and its arguments, focusing on the process.command_line field.
+- Investigate the parent process to confirm it is indeed WMIPrvSE by examining the process.parent.name field, ensuring the execution context aligns with potential misuse of WMI.
+- Check the user context under which the process was executed to determine if it aligns with expected administrative activity or if it suggests unauthorized access.
+- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities, such as lateral movement or privilege escalation attempts.
+- Assess the network activity from the host around the time of the alert to identify any unusual outbound connections or data exfiltration attempts.
+- Verify if the process execution is part of a known and legitimate administrative task or script by consulting with system administrators or reviewing change management records.
+
+### False positive analysis
+
+- Routine administrative tasks using WMI may trigger the rule, such as network configuration checks or system diagnostics. To manage this, identify and exclude specific command patterns or arguments that are part of regular maintenance.
+- Security tools like Tenable may use WMI for legitimate scans, which can be mistaken for malicious activity. Exclude processes with arguments related to known security tools, such as "tenable_mw_scan".
+- Automated scripts or scheduled tasks that perform system enumeration for inventory or monitoring purposes can cause false positives. Review and whitelist these scripts by excluding their specific command lines or parent processes.
+- Certain enterprise applications may use WMI for legitimate operations, such as querying system information. Identify these applications and create exceptions based on their process names or command line arguments.
+- Regular use of network utilities by IT staff for troubleshooting can be flagged. Implement exclusions for known IT user accounts or specific command line patterns used during these activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified as being spawned by WMIPrvSE, especially those matching the enumeration tools listed in the detection query.
+- Conduct a thorough review of recent WMI activity on the affected system to identify any additional unauthorized or suspicious commands executed.
+- Reset credentials for any accounts that may have been compromised or used in the suspicious activity to prevent further unauthorized access.
+- Restore the system from a known good backup if any malicious activity is confirmed and cannot be remediated through other means.
+- Implement additional monitoring on the affected system and network to detect any recurrence of similar suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_initial_access_foxmail_exploit.toml b/rules/windows/execution_initial_access_foxmail_exploit.toml
index 7a82513cf24..2ebe421b5f4 100644
--- a/rules/windows/execution_initial_access_foxmail_exploit.toml
+++ b/rules/windows/execution_initial_access_foxmail_exploit.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "m3
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,41 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and 
  process.parent.name : "Foxmail.exe" and process.args : ("?:\\Users\\*\\AppData\\*", "\\\\*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Foxmail Exploitation
+
+Foxmail, a popular email client, can be exploited by adversaries to gain initial access and execute malicious payloads. Attackers may leverage vulnerabilities to spawn child processes from Foxmail, directing them to temporary directories where malicious files reside. The detection rule identifies such suspicious activities by monitoring process creation events, specifically when Foxmail spawns processes with arguments pointing to its temp directory, indicating potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process creation event details to confirm that Foxmail.exe is the parent process and check the specific child process that was spawned.
+- Examine the arguments of the spawned process to verify if they point to a suspicious temporary directory, as indicated by the query pattern (e.g., paths under "?:\\Users\\*\\AppData\\*").
+- Investigate the contents of the identified temporary directory for any unusual or malicious files that may have been executed.
+- Check the email logs and Foxmail client activity to identify any recent emails that could have contained malicious attachments or links leading to the exploitation attempt.
+- Correlate the event with other security alerts or logs from data sources like Elastic Defend, Sysmon, or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns.
+- Assess the risk and impact on the affected system by determining if any unauthorized changes or additional malicious processes have been initiated following the initial alert.
+
+### False positive analysis
+
+- Routine software updates or installations may cause Foxmail to spawn child processes in the temp directory. Users can create exceptions for known update processes to prevent false alerts.
+- Legitimate plugins or extensions for Foxmail might execute processes from the temp directory. Verify the legitimacy of these plugins and exclude them if they are trusted.
+- Automated scripts or backup software interacting with Foxmail could trigger the rule. Identify these scripts and add them to an exclusion list if they are verified as safe.
+- User-initiated actions such as importing or exporting data in Foxmail might result in temporary process creation. Monitor these activities and exclude them if they are part of regular operations.
+- Security software performing scans or checks on Foxmail's temp directory can be mistaken for exploitation attempts. Confirm these activities and whitelist the security software processes involved.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
+- Terminate any suspicious processes spawned by Foxmail that are identified in the alert to stop the execution of potentially malicious payloads.
+- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious files or remnants.
+- Review and analyze email logs and quarantine any suspicious emails that may have been the source of the exploit to prevent further exploitation attempts.
+- Apply any available security patches or updates to Foxmail and the operating system to mitigate known vulnerabilities and prevent future exploitation.
+- Monitor the network and systems for any signs of lateral movement or additional compromise, using indicators of compromise (IOCs) identified during the investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required based on the scope and impact of the threat."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_initial_access_wps_dll_exploit.toml b/rules/windows/execution_initial_access_wps_dll_exploit.toml
index 499d310019c..a07b115da36 100644
--- a/rules/windows/execution_initial_access_wps_dll_exploit.toml
+++ b/rules/windows/execution_initial_access_wps_dll_exploit.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,41 @@ any where host.os.type == "windows" and process.name : "promecefpluginhost.exe"
       "\\Device\\Mup\\**", "\\\\*"))
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WPS Office Exploitation via DLL Hijack
+
+DLL hijacking exploits the way applications load dynamic link libraries (DLLs), allowing adversaries to execute malicious code. In WPS Office, attackers may exploit vulnerabilities by loading a rogue DLL via the promecefpluginhost.exe process, leveraging the ksoqing protocol. The detection rule identifies suspicious DLL loads from temporary or network paths, signaling potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is promecefpluginhost.exe and check if the event category is either "library" or "process" with the action "Image loaded*".
+- Examine the DLL or file path involved in the alert to determine if it matches suspicious paths such as those in the user's Temp directory or network paths like \\\\Device\\\\Mup\\\\** or \\\\*.
+- Investigate the source of the DLL by checking the file's origin, creation date, and any associated network activity to identify potential malicious downloads or transfers.
+- Analyze the process tree to understand the parent and child processes of promecefpluginhost.exe, looking for any unusual or unexpected behavior that might indicate exploitation.
+- Check for any other alerts or logs related to the same host or user account to identify patterns or repeated attempts of exploitation.
+- Correlate the findings with known vulnerabilities CVE-2024-7262 and CVE-2024-7263 to assess if the observed activity aligns with known exploitation techniques.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily load DLLs from network paths or temporary directories. Users can create exceptions for known update processes or trusted software installations to prevent false alerts.
+- Some enterprise environments use network-based storage solutions that may trigger alerts when legitimate DLLs are loaded from these paths. Administrators can whitelist specific network paths or devices that are known to host trusted libraries.
+- Custom scripts or automation tools that interact with WPS Office might inadvertently load DLLs from temporary directories. Identifying and excluding these scripts or tools from monitoring can reduce false positives.
+- Security software or system maintenance tools may perform scans or operations that mimic the behavior of DLL hijacking. Users should verify and exclude these tools if they are known to cause benign alerts.
+- In environments where WPS Office is heavily used, consider monitoring the frequency and context of alerts to distinguish between normal usage patterns and potential threats, adjusting the rule parameters accordingly.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the attacker.
+- Terminate the promecefpluginhost.exe process to stop any ongoing malicious activity and prevent further DLL hijacking attempts.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious DLLs or other malware.
+- Review and clean up the temporary and network paths identified in the detection query, specifically focusing on the AppData\\Local\\Temp\\wps\\INetCache directory and any suspicious network shares.
+- Apply patches or updates for WPS Office to address the vulnerabilities CVE-2024-7262 and CVE-2024-7263, ensuring that the software is up to date and less susceptible to exploitation.
+- Monitor for any further suspicious activity related to the ksoqing protocol or similar DLL hijacking attempts, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_mofcomp.toml b/rules/windows/execution_mofcomp.toml
index be4fb305278..6f848848ccf 100644
--- a/rules/windows/execution_mofcomp.toml
+++ b/rules/windows/execution_mofcomp.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "m365_defender", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,38 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Mofcomp Activity
+Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and namespaces in the Windows Management Instrumentation (WMI) repository. Adversaries exploit this by creating malicious WMI scripts for persistence or execution. The detection rule identifies suspicious mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of mofcomp.exe and verify the command-line arguments used, focusing on any unusual or unexpected MOF file paths.
+- Investigate the user account associated with the process execution, especially if it is not the system account (S-1-5-18), to determine if the account has been compromised or is being misused.
+- Examine the parent process of mofcomp.exe to ensure it is not a known safe process like ScenarioEngine.exe, and assess whether the parent process is legitimate or potentially malicious.
+- Check for any recent changes or additions to the WMI repository, including new namespaces or classes, which could indicate malicious activity or persistence mechanisms.
+- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Crowdstrike to identify any related suspicious activities or patterns.
+
+### False positive analysis
+
+- Legitimate SQL Server operations may trigger the rule when SQL Server components compile MOF files. To handle this, exclude processes with parent names like ScenarioEngine.exe and specific MOF file paths related to SQL Server.
+- System maintenance tasks executed by trusted system accounts can cause false positives. Exclude activities initiated by the system account with user ID S-1-5-18 to reduce noise.
+- Regular administrative tasks involving WMI may appear suspicious. Identify and document these tasks, then create exceptions for known safe parent processes or specific MOF file paths to prevent unnecessary alerts.
+- Software installations or updates that involve MOF file compilation might be flagged. Monitor installation logs and exclude these processes if they are verified as part of legitimate software updates.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the mofcomp.exe process if it is confirmed to be executing malicious MOF files.
+- Conduct a thorough review of the WMI repository to identify and remove any unauthorized namespaces or classes that may have been created by the attacker.
+- Remove any malicious MOF files from the system to prevent re-execution.
+- Restore the system from a known good backup if unauthorized changes to the WMI repository or system files are detected.
+- Monitor for any recurrence of similar activity by setting up alerts for unusual mofcomp.exe executions and unauthorized WMI modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_posh_hacktool_authors.toml b/rules/windows/execution_posh_hacktool_authors.toml
index 40c31c3be42..dffddb67d7b 100644
--- a/rules/windows/execution_posh_hacktool_authors.toml
+++ b/rules/windows/execution_posh_hacktool_authors.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/08"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,40 @@ host.os.type:windows and event.category:process and
       "splinter_code"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential PowerShell HackTool Script by Author
+
+PowerShell is a powerful scripting language and automation framework used in Windows environments for task automation and configuration management. Adversaries exploit PowerShell's capabilities to execute malicious scripts, often leveraging well-known offensive tools without altering the original code. The detection rule identifies scripts containing specific author names linked to these tools, flagging potential misuse by recognizing unmodified author artifacts in the script block text.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify the specific author name that triggered the detection. This can provide insight into the potential tool or script being used.
+- Examine the process details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed. This can help determine if the execution was part of a legitimate task or a suspicious activity.
+- Check the host's recent activity logs for any other unusual or related events, such as network connections, file modifications, or other process executions, to identify potential lateral movement or data exfiltration attempts.
+- Investigate the user account under which the PowerShell script was executed to determine if it has been compromised or if the activity aligns with the user's typical behavior.
+- Correlate the alert with other security tools and logs, such as antivirus or endpoint detection and response (EDR) solutions, to gather additional context and confirm whether the activity is malicious.
+
+### False positive analysis
+
+- Scripts used in legitimate red team exercises may trigger the rule due to the presence of known author names. To manage this, create exceptions for scripts verified as part of authorized security assessments.
+- PowerShell scripts from open-source security tools used for internal testing or training might be flagged. Ensure these tools are documented and approved, then exclude them from the rule.
+- Automated scripts for system administration that include code snippets from well-known authors could be mistakenly identified. Review and whitelist these scripts if they are part of routine operations.
+- Security research and development activities using sample scripts from recognized authors may cause alerts. Maintain a list of such activities and exclude them from detection to avoid unnecessary alerts.
+- Internal development teams using PowerShell scripts for legitimate purposes might inadvertently use code from popular authors. Conduct regular reviews and exclude these scripts if they are deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement.
+- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.
+- Conduct a thorough review of the PowerShell script block text to confirm the presence of known offensive tool author names and assess the potential impact.
+- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and restored from a clean backup.
+- Update endpoint protection and antivirus signatures to detect and block the specific PowerShell scripts and associated indicators of compromise (IOCs) identified in the alert.
+- 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 enhanced monitoring and logging for PowerShell activity across the network to detect similar threats in the future, leveraging the MITRE ATT&CK framework for guidance on relevant techniques and tactics."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_powershell_susp_args_via_winscript.toml b/rules/windows/execution_powershell_susp_args_via_winscript.toml
index 146ff0b2c9b..acbeeb7993f 100644
--- a/rules/windows/execution_powershell_susp_args_via_winscript.toml
+++ b/rules/windows/execution_powershell_susp_args_via_winscript.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -98,6 +98,40 @@ process where host.os.type == "windows" and event.action == "start" and
    not (process.parent.name : "wscript.exe" and
         ?process.parent.args : "C:\\Program Files (x86)\\Telivy\\Telivy Agent\\telivy.js")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious PowerShell Execution via Windows Scripts
+
+PowerShell, a powerful scripting language in Windows, is often targeted by adversaries for executing malicious scripts. Attackers exploit Windows Script Host processes like cscript or wscript to launch PowerShell with obfuscated commands, evading detection. The detection rule identifies such suspicious activity by monitoring PowerShell executions with specific patterns and parent processes, while filtering out known legitimate use cases to reduce false positives.
+
+### Possible investigation steps
+
+- Review the process command line and arguments to identify any obfuscation patterns or suspicious commands, such as Base64 encoding or web requests, that match the query's suspicious patterns.
+- Examine the parent process details, specifically focusing on wscript.exe, cscript.exe, or mshta.exe, to determine if the PowerShell execution was initiated by a legitimate script or a potentially malicious one.
+- Check the process execution context, including the user account and host, to assess if the activity aligns with expected behavior for that user or system.
+- Investigate any network connections or file downloads initiated by the PowerShell process, especially those involving external IP addresses or domains, to identify potential data exfiltration or further malicious activity.
+- Correlate the alert with other security events or logs from the same host or user to identify any preceding or subsequent suspicious activities that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate PowerShell commands using non-shortened execution flags may trigger false positives. To manage this, exclude processes with arguments like "-EncodedCommand", "Import-Module*", and "-NonInteractive" unless they are associated with suspicious activity.
+- Third-party installation scripts, such as those related to Microsoft System Center or WebLogic, can cause false positives. Exclude these by filtering out specific parent process arguments or command lines, such as "Microsoft.SystemCenter.ICMPProbe.WithConsecutiveSamples.vbs" and "WEBLOGIC_ARGS_CURRENT_1.DATA".
+- Routine administrative tasks, like gathering network information, may be flagged. Exclude known scripts like "gatherNetworkInfo.vbs" from detection to prevent unnecessary alerts.
+- Exclude specific user scripts or tools that are known to be safe, such as those located in user directories like "C:\\Users\\Prestige\\AppData\\Local\\Temp\\Rar$*\\KMS_VL_ALL_AIO.cmd" if they are verified as non-malicious.
+- Regularly review and update exclusion lists to ensure they reflect current legitimate activities and do not inadvertently allow new threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious execution.
+- Conduct a thorough review of the affected system's PowerShell execution logs to identify any additional malicious scripts or commands that may have been executed.
+- Remove any malicious scripts or files identified during the investigation from the system to prevent re-execution.
+- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious activity.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_scheduled_task_powershell_source.toml b/rules/windows/execution_scheduled_task_powershell_source.toml
index 443716555aa..e9fa85b6bf9 100644
--- a/rules/windows/execution_scheduled_task_powershell_source.toml
+++ b/rules/windows/execution_scheduled_task_powershell_source.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,39 @@ sequence by host.id, process.entity_id with maxspan = 5s
   (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")]
  [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not destination.address in ("127.0.0.1", "::1")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Outbound Scheduled Task Activity via PowerShell
+
+PowerShell, a powerful scripting language in Windows, can automate tasks via the Task Scheduler. Adversaries exploit this by creating scheduled tasks to execute malicious scripts, facilitating lateral movement or remote discovery. The detection rule identifies suspicious PowerShell activity by monitoring for the Task Scheduler DLL load and subsequent outbound RPC connections, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and process.entity_id associated with the suspicious activity.
+- Examine the process execution history on the affected host to determine if the PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) has executed any unexpected or unauthorized scripts.
+- Check the network logs for the host to identify any unusual or unauthorized outbound RPC connections, particularly those targeting port 135, and verify if the destination addresses are legitimate and expected.
+- Investigate the context of the taskschd.dll library load by reviewing recent scheduled tasks on the host to identify any newly created or modified tasks that could be linked to the alert.
+- Correlate the alert with other security events or logs from the same host or network segment to identify any patterns or additional indicators of compromise that may suggest lateral movement or remote discovery attempts.
+
+### False positive analysis
+
+- Legitimate administrative tasks using PowerShell may trigger the rule if they involve loading the Task Scheduler DLL and making RPC connections. To manage this, identify and whitelist specific scripts or processes that are known to perform these actions regularly.
+- Automated system maintenance or monitoring tools might also load the Task Scheduler DLL and establish RPC connections. Review these tools and exclude their process IDs or hashes from the detection rule to prevent false alerts.
+- Software updates or installations that use PowerShell scripts could mimic the behavior detected by the rule. Monitor update schedules and temporarily disable the rule during these periods if necessary, or create exceptions for known update processes.
+- Developers or IT staff using PowerShell for legitimate remote management tasks may inadvertently trigger the rule. Implement user-based exceptions for trusted personnel or restrict the rule to non-administrative accounts to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further lateral movement or data exfiltration.
+- Terminate the suspicious PowerShell process identified in the alert to stop any ongoing malicious activity.
+- Conduct a forensic analysis of the affected system to identify any additional malicious scheduled tasks or scripts and remove them.
+- Review and clean up any unauthorized scheduled tasks created on the system to ensure no persistence mechanisms remain.
+- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the attack.
+- Implement enhanced monitoring for similar PowerShell and scheduled task activities across the network to detect and respond to future threats promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_suspicious_cmd_wmi.toml b/rules/windows/execution_suspicious_cmd_wmi.toml
index 1e55aa7ab0d..6825f682e8f 100644
--- a/rules/windows/execution_suspicious_cmd_wmi.toml
+++ b/rules/windows/execution_suspicious_cmd_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,41 @@ process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "WmiPrvSE.exe" and process.name : "cmd.exe" and
  process.args : "\\\\127.0.0.1\\*" and process.args : ("2>&1", "1>")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Cmd Execution via WMI
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing commands remotely, often using cmd.exe. The detection rule identifies such activity by monitoring for cmd.exe processes initiated by WmiPrvSE.exe with specific arguments, indicating potential misuse for executing commands on remote hosts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the parent-child relationship between WmiPrvSE.exe and cmd.exe, ensuring that cmd.exe was indeed initiated by WmiPrvSE.exe.
+- Examine the command-line arguments used by cmd.exe, specifically looking for the presence of "\\\\\\\\127.0.0.1\\\\*" and redirection operators like "2>&1" or "1>", to understand the nature of the command executed.
+- Investigate the source and destination IP addresses involved in the WMI activity to determine if the remote host is legitimate or potentially compromised.
+- Check for any related alerts or logs from the same host or user account around the same timeframe to identify any patterns or additional suspicious activities.
+- Correlate the event with user activity logs to determine if the command execution aligns with expected user behavior or if it appears anomalous.
+- Consult threat intelligence sources to see if the command or pattern matches known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Legitimate administrative tasks using WMI may trigger this rule. System administrators often use WMI for remote management, which can include executing scripts or commands. To handle this, identify and whitelist known administrative accounts or specific scripts that are regularly used for maintenance.
+- Automated scripts or software that rely on WMI for legitimate operations might also cause false positives. Review and document these processes, then create exceptions for them in the detection rule to prevent unnecessary alerts.
+- Security software or monitoring tools that utilize WMI for system checks can inadvertently match the rule's criteria. Verify these tools and exclude their specific processes or arguments from the rule to reduce noise.
+- Scheduled tasks or system updates that use WMI for execution might be flagged. Regularly review scheduled tasks and update the rule to exclude these known benign activities.
+- Internal network monitoring or testing tools that simulate attacks for security assessments may trigger alerts. Ensure these activities are logged and excluded from the rule to avoid confusion during security evaluations.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis.
+- Terminate any suspicious cmd.exe processes initiated by WmiPrvSE.exe to halt any ongoing malicious activities.
+- Conduct a thorough review of the affected system's WMI subscriptions and scripts to identify and remove any unauthorized or malicious entries.
+- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Enhance monitoring and logging for WMI activities across the network to detect similar threats in the future, ensuring that logs are retained for an adequate period for forensic purposes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
index dc17bde0562..f76e6b136e1 100644
--- a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
+++ b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,40 @@ any where host.os.type == "windows" and
   process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE") and
   (?dll.name : "wmiutils.dll" or file.name : "wmiutils.dll")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious WMI Image Load from MS Office
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute code stealthily, bypassing traditional security measures by spawning processes indirectly. The detection rule identifies unusual loading of the `wmiutils.dll` library by Microsoft Office applications, signaling potential misuse of WMI for malicious execution. This rule leverages event categories and process names to pinpoint suspicious activity, aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the specific Microsoft Office process involved (e.g., WINWORD.EXE, EXCEL.EXE) and the associated event category (library, driver, or process).
+- Check the process execution history to determine if the process has a legitimate reason to load the wmiutils.dll library, such as recent updates or legitimate automation tasks.
+- Investigate the parent process of the flagged Microsoft Office application to identify any unusual or unexpected parent-child process relationships that could indicate malicious activity.
+- Analyze recent user activity on the affected system to identify any suspicious behavior or unauthorized access that might correlate with the alert.
+- Examine network connections and data transfers initiated by the flagged process to detect any potential data exfiltration or communication with known malicious IP addresses.
+- Cross-reference the alert with other security logs and alerts to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate use of WMI by Microsoft Office applications for automation tasks or system management can trigger the rule. Users should verify if the activity aligns with expected administrative tasks.
+- Some third-party plugins or add-ins for Microsoft Office may load wmiutils.dll for legitimate purposes. Users can create exceptions for these known plugins after confirming their benign nature.
+- Scheduled tasks or scripts that utilize WMI for legitimate business processes might cause false positives. Review and document these processes, then exclude them from the rule if they are verified as non-threatening.
+- Security or monitoring tools that interact with Office applications and use WMI for data collection could be flagged. Ensure these tools are recognized and excluded from the rule after validation.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious Microsoft Office processes identified in the alert that are loading the `wmiutils.dll` library.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious code or files.
+- Review and analyze the system's WMI repository and scripts for unauthorized or suspicious entries, and remove any that are identified as malicious.
+- Restore the system from a known good backup if malicious activity has compromised system integrity or data.
+- 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 enhanced monitoring and logging for WMI activity and Microsoft Office processes to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_via_mmc_console_file_unusual_path.toml b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
index 5e8bd3c2454..9bce81762f0 100644
--- a/rules/windows/execution_via_mmc_console_file_unusual_path.toml
+++ b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,40 @@ process where host.os.type == "windows" and event.type == "start" and
         "?:\\Program Files (x86)\\*.msc"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft Management Console File from Unusual Path
+
+Microsoft Management Console (MMC) is a Windows utility that provides a framework for system management. Adversaries may exploit MMC by executing .msc files from non-standard directories to bypass security controls. The detection rule identifies such anomalies by monitoring the execution of mmc.exe with .msc files from untrusted paths, flagging potential unauthorized access or execution attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the path of the mmc.exe and the .msc file being executed. Check if the path is indeed non-standard or untrusted as per the query criteria.
+- Investigate the origin of the .msc file by examining file creation and modification timestamps, and check for any recent changes or unusual activity in the directory where the file resides.
+- Analyze the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Check for any related alerts or logs around the same timeframe that might indicate lateral movement or other malicious activities, such as unusual network connections or file access patterns.
+- Correlate the event with other data sources mentioned in the rule, such as Microsoft Defender for Endpoint or Crowdstrike, to gather additional context or corroborating evidence of potential malicious activity.
+- Assess the risk and impact of the execution by determining if the .msc file has any known malicious signatures or if it attempts to perform unauthorized actions on the system.
+
+### False positive analysis
+
+- Legitimate administrative tasks may trigger this rule if system administrators execute .msc files from custom directories. To manage this, create exceptions for known administrative scripts or tools that are regularly used from non-standard paths.
+- Software installations or updates might involve executing .msc files from temporary or installation directories. Monitor these activities and whitelist specific installation paths if they are verified as safe and part of routine operations.
+- Automated scripts or third-party management tools could execute .msc files from non-standard locations as part of their normal operation. Identify these tools and add their execution paths to the exception list to prevent unnecessary alerts.
+- Development or testing environments may involve running .msc files from various directories for testing purposes. Establish a separate monitoring policy for these environments or exclude known development paths to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes related to mmc.exe executing from untrusted paths to halt potential malicious activity.
+- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related suspicious activities.
+- Remove any unauthorized .msc files found in non-standard directories and ensure they are not reintroduced.
+- Restore the system from a known good backup if any unauthorized changes or damage is detected.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_windows_cmd_shell_susp_args.toml b/rules/windows/execution_windows_cmd_shell_susp_args.toml
index d6bb9f17af1..f7b239b8f3b 100644
--- a/rules/windows/execution_windows_cmd_shell_susp_args.toml
+++ b/rules/windows/execution_windows_cmd_shell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -104,6 +104,41 @@ process where host.os.type == "windows" and event.type == "start" and
   not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and 
   not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Windows Command Shell Arguments
+
+The Windows Command Shell (cmd.exe) is a critical component for executing commands and scripts. Adversaries exploit it to execute malicious scripts, download payloads, or manipulate system settings. The detection rule identifies unusual command-line arguments and patterns indicative of such abuse, filtering out known benign processes to minimize false positives. This helps in early detection of potential threats by monitoring for suspicious command executions.
+
+### Possible investigation steps
+
+- Review the command line arguments associated with the cmd.exe process to identify any suspicious patterns or keywords such as "curl", "regsvr32", "wscript", or "Invoke-WebRequest" that may indicate malicious activity.
+- Check the parent process of the cmd.exe execution to determine if it is a known benign process or if it is associated with potentially malicious activity, especially if the parent process is explorer.exe or other unusual executables.
+- Investigate the user account associated with the cmd.exe process to determine if the activity aligns with the user's typical behavior or if it appears anomalous.
+- Examine the network activity of the host to identify any unusual outbound connections or data transfers that may correlate with the suspicious command execution.
+- Cross-reference the alert with other security logs or alerts from tools like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and corroborate findings.
+- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate response actions are necessary.
+
+### False positive analysis
+
+- Processes related to Spiceworks and wmiprvse.exe can trigger false positives. Exclude these by adding exceptions for process arguments containing "%TEMP%\\\\Spiceworks\\\\*" when the parent process is wmiprvse.exe.
+- Development tools like Perl, Node.js, and NetBeans may cause false alerts. Exclude these by specifying their executable paths in the exception list.
+- Citrix Secure Access Client initiated by userinit.exe can be a false positive. Exclude this by adding an exception for process arguments containing "?:\\\\Program Files\\\\Citrix\\\\Secure Access Client\\\\nsauto.exe" with the parent process name as userinit.exe.
+- Scheduled tasks or services like PCPitstopScheduleService.exe may trigger alerts. Exclude these by adding their paths to the exception list.
+- Command-line operations involving npm or Maven commands can be benign. Exclude these by specifying command-line patterns like "\\"cmd\\" /c %NETBEANS_MAVEN_COMMAND_LINE%" in the exception list.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Terminate any suspicious cmd.exe processes identified by the detection rule to halt malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts.
+- Review and restore any altered system settings or configurations to their original state to ensure system integrity.
+- Analyze the command-line arguments and parent processes involved in the alert to understand the scope and origin of the threat, and identify any additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary.
+- Implement additional monitoring and detection rules to identify similar suspicious command-line activities in the future, enhancing the organization's ability to detect and respond to such threats promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/execution_windows_powershell_susp_args.toml b/rules/windows/execution_windows_powershell_susp_args.toml
index 190e0bee76c..a45cfcd0ba0 100644
--- a/rules/windows/execution_windows_powershell_susp_args.toml
+++ b/rules/windows/execution_windows_powershell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -106,6 +106,41 @@ process where host.os.type == "windows" and event.type == "start" and
        process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*"))
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Windows Powershell Arguments
+
+PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent.
+- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source.
+- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString.
+- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised.
+- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise.
+- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected.
+
+### False positive analysis
+
+- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist.
+- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule.
+- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule.
+- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts.
+- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.
+- 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 scripts.
+- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity.
+- Restore any affected files or system components from known good backups to ensure system integrity and functionality.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/exfiltration_smb_rare_destination.toml b/rules/windows/exfiltration_smb_rare_destination.toml
index 4d605159cf9..67542883b04 100644
--- a/rules/windows/exfiltration_smb_rare_destination.toml
+++ b/rules/windows/exfiltration_smb_rare_destination.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -79,6 +79,41 @@ event.category:network and host.os.type:windows and process.pid:4 and
     "FF00::/8"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Rare SMB Connection to the Internet
+
+Server Message Block (SMB) is a protocol used for sharing files and printers within a network. Adversaries exploit SMB to exfiltrate data by injecting rogue paths to capture NTLM credentials. The detection rule identifies unusual SMB traffic from internal IPs to external networks, flagging potential exfiltration attempts by monitoring specific ports and excluding known safe IP ranges.
+
+### Possible investigation steps
+
+- Review the alert details to identify the internal source IP address involved in the SMB connection and verify if it belongs to a known or authorized device within the organization.
+- Check the destination IP address to determine if it is associated with any known malicious activity or if it belongs to an external network that should not be receiving SMB traffic from internal systems.
+- Investigate the process with PID 4 on the source host, which typically corresponds to the Windows System process, to identify any unusual activity or recent changes that could indicate compromise or misuse.
+- Analyze network logs to trace the SMB traffic flow and identify any patterns or additional connections that may suggest data exfiltration attempts.
+- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and determine if this is part of a larger attack campaign.
+- Consult with the IT or network team to verify if there are any legitimate business reasons for the detected SMB traffic to the external network, and if not, consider blocking the connection and conducting a deeper investigation into the source host.
+
+### False positive analysis
+
+- Internal network scanning tools may trigger alerts if they simulate SMB traffic to external IPs. Exclude IPs associated with these tools from the rule to prevent false positives.
+- Legitimate business applications that require SMB connections to external cloud services might be flagged. Identify and whitelist these specific external IPs or domains to avoid unnecessary alerts.
+- Backup solutions that use SMB for data transfer to offsite locations can be mistaken for exfiltration attempts. Ensure these backup service IPs are added to the exception list.
+- Misconfigured network devices that inadvertently route SMB traffic externally could cause false alerts. Regularly audit and correct device configurations to minimize these occurrences.
+- Security testing or penetration testing activities might generate SMB traffic to external IPs. Coordinate with security teams to temporarily disable the rule or add exceptions during testing periods.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement.
+- Conduct a thorough review of the host's network connections and processes to identify any unauthorized SMB traffic or suspicious activities.
+- Reset credentials for any accounts that may have been exposed or compromised, focusing on those with elevated privileges.
+- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known SMB vulnerabilities.
+- Implement network segmentation to limit SMB traffic to only necessary internal communications, reducing the risk of external exposure.
+- Enhance monitoring and logging for SMB traffic, particularly for connections to external IPs, to detect and respond to future anomalies more effectively.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
index 9833b3ed3e6..931cf623700 100644
--- a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
+++ b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,43 @@ index = ["logs-endpoint.events.process-*", "logs-endpoint.events.file-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious HTML File Creation"
-note = "This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence."
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious HTML File Creation
+
+HTML files, typically used for web content, can be exploited by adversaries to smuggle malicious payloads past security filters. By embedding harmful data within seemingly benign HTML files, attackers can bypass traditional defenses. The detection rule identifies such threats by monitoring the creation of HTML files with unusual characteristics, such as high entropy or large size, in common download and temporary directories. It also tracks browser processes that open these files, ensuring that any suspicious activity is flagged for further investigation. This approach helps in identifying potential phishing attempts and other initial access tactics used by attackers.
+
+### Possible investigation steps
+
+- Review the file creation or rename event details to confirm the file extension is .htm or .html and check if the file's entropy is 5 or higher or if the file size is 150,000 bytes or more.
+- Verify the file path to ensure it is located in one of the common download or temporary directories specified in the rule, such as "?:\\Users\\*\\Downloads\\*" or "?:\\Users\\*\\AppData\\Local\\Temp\\*".
+- Examine the process start event to identify the browser process involved, ensuring it matches one of the specified browsers like chrome.exe or firefox.exe, and check if the process arguments align with the rule's conditions.
+- Investigate the user.id associated with the sequence to determine if the activity aligns with the user's typical behavior or if it appears suspicious.
+- Check for any recent phishing attempts or suspicious emails received by the user that could have led to the download and execution of the HTML file.
+- Analyze the content of the HTML file for any embedded scripts or links that could indicate malicious intent or payload delivery.
+
+### False positive analysis
+
+- Legitimate large HTML files downloaded from trusted sources may trigger the rule. Users can create exceptions for specific trusted domains or file hashes to prevent these from being flagged.
+- HTML files generated by certain applications or services, such as email clients or document converters, might have high entropy due to embedded data. Identify these applications and exclude their file creation paths from monitoring.
+- Temporary HTML files created during software updates or installations in the AppData or Temp directories can be mistaken for suspicious activity. Monitor and whitelist known update processes to reduce false positives.
+- Browser extensions or plugins that save web content locally might create HTML files with characteristics similar to those flagged by the rule. Review and whitelist extensions that are known to be safe and necessary for business operations.
+- Automated scripts or tools that process web content and save it as HTML files could be misidentified. Ensure these scripts are documented and their file paths are excluded from the rule's scope.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate any suspicious browser processes identified in the alert to stop the execution of potentially harmful HTML files.
+- Quarantine the suspicious HTML files detected in the specified directories to prevent accidental execution or further access by users.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or malicious payloads.
+- Review and analyze the system and network logs to identify any lateral movement or additional compromised systems, escalating findings to the security team for further investigation.
+- Restore any affected files or systems from known good backups to ensure the integrity and availability of data and services.
+- Implement additional monitoring and alerting for similar activities, focusing on high entropy and large HTML files in common download and temporary directories to enhance detection capabilities.
+
+This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence."""
 risk_score = 47
 rule_id = "f0493cb4-9b15-43a9-9359-68c23a7f2cf3"
 setup = """## Setup
diff --git a/rules/windows/initial_access_execution_from_inetcache.toml b/rules/windows/initial_access_execution_from_inetcache.toml
index 78d9de0f304..9a49917fbe7 100644
--- a/rules/windows/initial_access_execution_from_inetcache.toml
+++ b/rules/windows/initial_access_execution_from_inetcache.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,41 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Execution from INET Cache
+
+The INetCache folder stores temporary internet files, which can be exploited by adversaries to execute malicious payloads delivered via WININET. Attackers may disguise malware as legitimate files cached during browsing. The detection rule identifies suspicious processes initiated from this cache, especially when launched by common file explorers, signaling potential initial access or command and control activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the executable path and arguments match the INetCache folder pattern specified in the query.
+- Identify the parent process, such as explorer.exe, winrar.exe, 7zFM.exe, or Bandizip.exe, to determine if the process launch is consistent with typical user behavior or potentially malicious activity.
+- Check the user account associated with the process to assess if the activity aligns with the user's normal behavior or if the account may be compromised.
+- Investigate the file in the INetCache directory for known malware signatures or anomalies using antivirus or endpoint detection tools.
+- Analyze network activity from the host to identify any suspicious connections that may indicate command and control communication.
+- Correlate the event with other security alerts or logs to identify patterns or additional indicators of compromise related to the initial access or command and control tactics.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily use the INetCache folder for storing executable files. Users can create exceptions for known update processes by identifying their specific executable paths and excluding them from the rule.
+- Some browser extensions or plugins might cache executable files in the INetCache folder during normal operations. Users should monitor and whitelist these extensions if they are verified as safe and frequently trigger alerts.
+- Automated scripts or tools that interact with web content might inadvertently store executables in the INetCache folder. Users can adjust the rule to exclude these scripts by specifying their parent process names or paths.
+- Certain enterprise applications may use the INetCache folder for legitimate purposes. Users should collaborate with IT departments to identify these applications and configure exceptions based on their unique process signatures.
+- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempt from triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with potential command and control servers.
+- Terminate any suspicious processes identified as originating from the INetCache folder to halt any ongoing malicious activity.
+- Delete any malicious files found within the INetCache directory to remove the immediate threat.
+- Conduct a full antivirus and antimalware scan on the affected system to identify and remove any additional threats.
+- Review and analyze recent email logs and web browsing history to identify potential phishing attempts or malicious downloads that may have led to the initial compromise.
+- 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 enhanced monitoring and logging for the INetCache directory and related processes to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_from_removable_media.toml b/rules/windows/initial_access_execution_from_removable_media.toml
index 495c84b76fd..e9438f064b5 100644
--- a/rules/windows/initial_access_execution_from_removable_media.toml
+++ b/rules/windows/initial_access_execution_from_removable_media.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,42 @@ sequence by process.entity_id with maxspan=5m
   not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")]
  [network where host.os.type == "windows" and event.action == "connection_attempted"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution from a Removable Media with Network Connection
+
+Removable media, like USB drives, are often used for data transfer but can be exploited by adversaries to introduce malware into isolated systems. Attackers may leverage autorun features to execute malicious code upon insertion. The detection rule identifies suspicious process executions from USB devices, especially those lacking valid code signatures, and correlates them with network connection attempts, signaling potential unauthorized access efforts.
+
+### Possible investigation steps
+
+- Review the process execution details, focusing on the process.entity_id to identify the specific process that was executed from the USB device.
+- Check the process.Ext.device.bus_type and process.Ext.device.product_id fields to confirm the involvement of a USB device and gather information about the specific device used.
+- Investigate the process.code_signature fields to determine if the process lacks a valid code signature, which could indicate malicious intent.
+- Correlate the process execution with network connection attempts by examining the network event logs, particularly looking for any unusual or unauthorized connection attempts.
+- Assess the context of the network connection attempt, including the destination IP address and port, to evaluate the potential risk and intent of the connection.
+- Gather additional context by reviewing recent activity on the host, such as other process executions or file modifications, to identify any further signs of compromise.
+- If necessary, isolate the affected system to prevent further unauthorized access or data exfiltration while continuing the investigation.
+
+### False positive analysis
+
+- Legitimate software installations from USB drives may trigger the rule. To manage this, create exceptions for known software installers by verifying their code signatures and adding them to an allowlist.
+- IT administrators often use USB devices for system updates or maintenance. Identify and exclude these activities by correlating them with known administrator accounts or devices.
+- Some organizations use USB devices for regular data transfers. Establish a baseline of normal USB activity and exclude these patterns from triggering alerts.
+- Devices with expired but previously trusted code signatures might be flagged. Regularly update the list of trusted certificates and exclude processes with known expired signatures that are still considered safe.
+- Network connection attempts by legitimate applications running from USB drives can be mistaken for threats. Monitor and document these applications, then configure exceptions based on their process names and network behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Disable autorun features on all systems to prevent automatic execution of potentially malicious code from removable media.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware.
+- Review and block any suspicious network connections originating from the affected system to prevent communication with potential command and control servers.
+- Collect and preserve relevant logs and forensic evidence from the affected system and removable media for further analysis and potential legal action.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if other systems may be affected.
+- Implement enhanced monitoring and alerting for similar activities, focusing on process executions from removable media and unauthorized network connection attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_remote_via_msiexec.toml b/rules/windows/initial_access_execution_remote_via_msiexec.toml
index 054e39cfd39..c98affc9b30 100644
--- a/rules/windows/initial_access_execution_remote_via_msiexec.toml
+++ b/rules/windows/initial_access_execution_remote_via_msiexec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ sequence with maxspan=1m
   not (process.name : "rundll32.exe" and process.args : "printui.dll,PrintUIEntry")
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Remote File Execution via MSIEXEC
+
+MSIEXEC, the Windows Installer, facilitates software installation, modification, and removal. Adversaries exploit it to execute remote MSI files, bypassing security controls. The detection rule identifies suspicious MSIEXEC activity by monitoring process starts, network connections, and child processes, filtering out known benign signatures and paths, thus highlighting potential misuse for initial access or defense evasion.
+
+### Possible investigation steps
+
+- Review the process start event for msiexec.exe to identify the command-line arguments used, focusing on the presence of the "/V" flag, which indicates a remote installation attempt.
+- Examine the network connection attempts associated with msiexec.exe to determine the remote IP addresses or domains being contacted, and assess their reputation or any known associations with malicious activity.
+- Investigate the child processes spawned by msiexec.exe, especially those not matching known benign executables or paths, to identify any suspicious or unexpected activity.
+- Check the user ID associated with the msiexec.exe process to verify if it aligns with expected user behavior or if it indicates potential compromise, especially focusing on user IDs like "S-1-5-21-*" or "S-1-5-12-1-*".
+- Analyze the code signature of any child processes to ensure they are trusted and expected, paying particular attention to any unsigned or untrusted executables.
+- Correlate the alert with any recent phishing attempts or suspicious emails received by the user, as the MITRE ATT&CK technique T1566 (Phishing) is associated with this rule.
+
+### False positive analysis
+
+- Legitimate software installations using msiexec.exe may trigger the rule. To manage this, create exceptions for known software update processes that use msiexec.exe with trusted code signatures.
+- System maintenance tasks that involve msiexec.exe, such as Windows updates or system repairs, can be excluded by identifying and allowing specific system paths and executables involved in these processes.
+- Enterprise software deployment tools that utilize msiexec.exe for remote installations might cause false positives. Exclude these by verifying the code signature and adding exceptions for trusted deployment tools.
+- Administrative scripts or automation tools that invoke msiexec.exe for legitimate purposes should be reviewed and, if verified as safe, excluded based on their execution context and code signature.
+- Network monitoring tools or security software that simulate msiexec.exe activity for testing or monitoring purposes can be excluded by identifying their specific signatures and paths.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. This can be done by disabling network interfaces or moving the system to a quarantine VLAN.
+- Terminate the msiexec.exe process if it is still running to stop any ongoing malicious activity. Use task management tools or scripts to ensure the process is completely stopped.
+- Conduct a thorough review of the system for any unauthorized changes or installations. Check for newly installed software or modifications to system files that could indicate further compromise.
+- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. Ensure the backup is clean and free from any malicious alterations.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. This includes applying all relevant Windows updates and security patches.
+- Enhance monitoring and logging on the affected system and network to detect any similar future attempts. Ensure that all relevant security events are being captured and analyzed.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. Provide them with all relevant logs and findings for a comprehensive analysis."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_execution_via_office_addins.toml b/rules/windows/initial_access_execution_via_office_addins.toml
index 4faad5dfbcf..dabf610c6f9 100644
--- a/rules/windows/initial_access_execution_via_office_addins.toml
+++ b/rules/windows/initial_access_execution_via_office_addins.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -81,6 +81,40 @@ process where
          process.parent.args : "?:\\WINDOWS\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc") and
     not (process.name : "VSTOInstaller.exe" and process.args : "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Execution via Microsoft Office Add-Ins
+
+Microsoft Office Add-Ins enhance productivity by integrating additional features into Office applications. However, adversaries can exploit this by embedding malicious code within add-ins, often delivered through phishing. The detection rule identifies unusual execution patterns, such as Office apps launching add-ins from suspicious paths or with atypical parent processes, signaling potential threats. It filters out known benign activities to minimize false positives, focusing on genuine anomalies indicative of malicious intent.
+
+### Possible investigation steps
+
+- Review the process name and arguments to confirm if the execution involves a Microsoft Office application launching an add-in from a suspicious path, as indicated by the process.name and process.args fields.
+- Check the parent process name to determine if the Office application was launched by an unusual or potentially malicious parent process, such as cmd.exe or powershell.exe, using the process.parent.name field.
+- Investigate the file path from which the add-in was executed to assess if it matches any of the suspicious paths listed in the query, such as the Temp or Downloads directories, using the process.args field.
+- Examine the host's recent activity logs to identify any related events or patterns that might indicate a broader attack or compromise, focusing on the host.os.type and event.type fields.
+- Correlate the alert with any recent phishing attempts or suspicious emails received by the user to determine if the execution is part of a phishing campaign, leveraging the MITRE ATT&CK tactic and technique information provided.
+- Verify if the execution is a false positive by checking against the known benign activities excluded in the query, such as specific VSTOInstaller.exe paths or arguments, to rule out legitimate software installations or updates.
+
+### False positive analysis
+
+- Logitech software installations can trigger false positives when VSTO files are executed by Logitech's PlugInInstallerUtility. To mitigate this, exclude processes with paths related to Logitech installations from the detection rule.
+- The VSTOInstaller.exe process may be flagged when uninstalling applications. Exclude processes with the /Uninstall argument to prevent these false positives.
+- Rundll32.exe executing with specific arguments related to MSI temporary files can be benign. Exclude these specific rundll32.exe executions to avoid false alerts.
+- Sidekick.vsto installations from the specified URL can be legitimate. Exclude this specific VSTOInstaller.exe process with the Sidekick.vsto argument to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
+- Terminate any suspicious processes identified by the detection rule, such as those involving unusual parent processes or originating from suspicious paths.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious add-ins or related malware.
+- Review and clean up any unauthorized or suspicious Office add-ins from the affected applications to ensure no malicious code remains.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning alone.
+- 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 additional monitoring and alerting for similar suspicious activities to enhance detection and response capabilities for future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
index 288d91f4f02..2597f2957a8 100644
--- a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
+++ b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funne
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,40 @@ type = "new_terms"
 query = '''
 event.category:"registry" and host.os.type:"windows" and registry.value:"FriendlyName" and registry.path:*USBSTOR*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Time Seen Removable Device
+
+Removable devices, like USB drives, are common in Windows environments for data transfer. Adversaries exploit these to introduce malware or exfiltrate data, leveraging their plug-and-play nature. The detection rule monitors registry changes for new device names, signaling potential unauthorized access. By focusing on first-time-seen devices, it helps identify suspicious activities linked to data exfiltration or initial access attempts.
+
+### Possible investigation steps
+
+- Review the registry event details to confirm the presence of a new device by checking the registry.value for "FriendlyName" and registry.path for USBSTOR.
+- Correlate the timestamp of the registry event with user activity logs to identify which user was logged in at the time of the device connection.
+- Check for any subsequent file access or transfer events involving the new device to assess potential data exfiltration.
+- Investigate the device's history by searching for any previous connections to other systems within the network to determine if it has been used elsewhere.
+- Analyze any related alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint for additional context or suspicious activities linked to the device.
+
+### False positive analysis
+
+- Frequent use of company-issued USB drives for legitimate data transfer can trigger alerts. Maintain a list of approved devices and create exceptions for these in the monitoring system.
+- Software updates or installations via USB drives may be flagged. Identify and whitelist known update devices or processes to prevent unnecessary alerts.
+- IT department activities involving USB devices for maintenance or troubleshooting can appear suspicious. Coordinate with IT to log and exclude these routine operations from triggering alerts.
+- Devices used for regular backups might be detected as new. Ensure backup devices are registered and excluded from the rule to avoid false positives.
+- Personal USB devices used by employees for non-work-related purposes can cause alerts. Implement a policy for registering personal devices and exclude them if deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential data exfiltration or further spread of malware.
+- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software introduced via the removable device.
+- Review and analyze the registry changes logged by the detection rule to confirm the legitimacy of the device and assess any unauthorized access attempts.
+- If malicious activity is confirmed, collect and preserve relevant logs and evidence for further forensic analysis and potential legal action.
+- Notify the security team and relevant stakeholders about the incident, providing details of the device and any identified threats.
+- Implement a temporary block on the use of removable devices across the network until the threat is fully contained and remediated.
+- Enhance monitoring and detection capabilities by updating security tools and rules to better identify similar threats in the future, focusing on registry changes and device connections."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
index bd42e3ff3ef..a718f46c188 100644
--- a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
+++ b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -72,6 +72,41 @@ process where host.os.type == "windows" and event.type == "start" and
  not (process.name : "powershell.exe" and process.args : "-ExecutionPolicy" and process.args : "?:\\TeamCity\\buildAgent\\work\\*.ps1") and
  not (process.name : "cmd.exe" and process.args : "dir" and process.args : "/-c")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious JetBrains TeamCity Child Process
+
+JetBrains TeamCity is a continuous integration and deployment server used to automate software development processes. Adversaries may exploit vulnerabilities in TeamCity to execute unauthorized code, potentially spawning malicious child processes. The detection rule identifies unusual child processes initiated by TeamCity's Java executable, flagging potential exploitation attempts by monitoring for known suspicious executables, while excluding legitimate operations.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent and child processes associated with the suspicious activity, focusing on the parent executable paths like "?:\\TeamCity\\jre\\bin\\java.exe".
+- Examine the command-line arguments of the suspicious child processes, especially those involving "cmd.exe" or "powershell.exe", to understand the actions being executed.
+- Check for any recent vulnerabilities or patches related to JetBrains TeamCity that might explain the suspicious behavior.
+- Investigate the user account under which the suspicious processes were executed to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Correlate the alert with other security events or logs from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related malicious activity or indicators of compromise.
+- Assess network activity from the host to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server.
+
+### False positive analysis
+
+- Legitimate build scripts may invoke command-line utilities like cmd.exe or powershell.exe. To handle these, create exceptions for specific scripts by matching known safe arguments or paths.
+- Automated tasks or maintenance scripts might use network utilities such as ping.exe or netstat.exe. Exclude these by identifying and allowing specific scheduled tasks or maintenance windows.
+- System monitoring tools could trigger processes like tasklist.exe or systeminfo.exe. Whitelist these tools by verifying their source and ensuring they are part of authorized monitoring solutions.
+- Development or testing environments may frequently use utilities like explorer.exe or control.exe. Establish exceptions for these environments by defining specific hostnames or IP ranges where such activity is expected.
+- Custom scripts or applications might use msiexec.exe for legitimate software installations. Allow these by confirming the source and purpose of the installations, and excluding them based on known safe paths or signatures.
+
+### Response and remediation
+
+- Immediately isolate the affected TeamCity server from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious child processes identified by the detection rule, such as cmd.exe or powershell.exe, to halt potential malicious activities.
+- Conduct a thorough review of recent changes and deployments in TeamCity to identify any unauthorized modifications or suspicious activities.
+- Apply the latest security patches and updates to TeamCity and its underlying Java runtime environment to mitigate known vulnerabilities.
+- Restore the affected system from a clean backup taken before the suspicious activity was detected, ensuring no remnants of the exploit remain.
+- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on the indicators identified in the detection rule.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for additional security measures."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_rdp_file_mail_attachment.toml b/rules/windows/initial_access_rdp_file_mail_attachment.toml
index 87b45b1a35b..1e27db0f462 100644
--- a/rules/windows/initial_access_rdp_file_mail_attachment.toml
+++ b/rules/windows/initial_access_rdp_file_mail_attachment.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/05"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/11/05"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,41 @@ process where host.os.type == "windows" and event.type == "start" and
                  "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*.rdp",
                  "C:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\Content.Outlook\\*.rdp")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Remote Desktop File Opened from Suspicious Path
+
+Remote Desktop Protocol (RDP) allows users to connect to and control a computer remotely, facilitating remote work and administration. However, adversaries can exploit RDP files, which store connection settings, to gain unauthorized access. They may distribute malicious RDP files via phishing, placing them in suspicious directories. The detection rule identifies when RDP files are opened from unusual paths, signaling potential misuse and enabling analysts to investigate further.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of "mstsc.exe" and verify the suspicious path from which the RDP file was opened, as specified in the query.
+- Check the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Investigate the source of the RDP file by examining recent email activity or downloads to identify potential phishing attempts or unauthorized file transfers.
+- Analyze the system's event logs for any other unusual activities or processes that occurred around the same time as the RDP file execution.
+- Assess the network connections established by the system during the time of the alert to identify any suspicious or unauthorized remote connections.
+- Consult threat intelligence sources to determine if the identified path or file name pattern is associated with known malicious campaigns or threat actors.
+
+### False positive analysis
+
+- Users frequently download legitimate RDP files from trusted sources like corporate emails or internal portals. To manage this, create exceptions for known safe domains or email addresses in your security tools.
+- Temporary directories often store RDP files during legitimate software installations or updates. Monitor these activities and whitelist specific processes or software that are known to use RDP files during their operations.
+- Employees working remotely may use RDP files stored in their Downloads folder for legitimate access to company resources. Implement a policy to educate users on safe RDP file handling and consider excluding the Downloads folder from alerts if it is a common practice.
+- Some business applications may generate RDP files in temporary directories as part of their normal operation. Identify these applications and configure your detection systems to exclude their specific file paths or process names.
+- Automated scripts or IT management tools might use RDP files for routine administrative tasks. Document these scripts and tools, and adjust your detection rules to ignore their specific activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any active RDP sessions initiated from the suspicious paths identified in the alert to cut off potential attacker access.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software.
+- Review and remove any unauthorized RDP files from the suspicious directories listed in the detection query to prevent future misuse.
+- Reset credentials for any accounts that were used to open the suspicious RDP files, ensuring that new passwords are strong and unique.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and logging for RDP activities across the network to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_scripts_process_started_via_wmi.toml b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
index 23c41341535..f195d33108e 100644
--- a/rules/windows/initial_access_scripts_process_started_via_wmi.toml
+++ b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/27"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -69,6 +69,40 @@ sequence by host.id with maxspan = 5s
      )
     ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows Script Interpreter Executing Process via WMI
+
+Windows Management Instrumentation (WMI) is a powerful Windows feature that allows for system management and automation. Adversaries exploit WMI to execute scripts or processes stealthily, often using script interpreters like cscript.exe or wscript.exe. The detection rule identifies suspicious activity by monitoring for these interpreters executing processes via WMI, especially when initiated by non-system accounts, indicating potential malicious intent.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific script interpreter (cscript.exe or wscript.exe) and the process it executed. Check the process name and executable path for any anomalies or known malicious indicators.
+- Examine the user account associated with the process execution. Verify if the user domain is not "NT AUTHORITY" and assess whether the account is expected to perform such actions. Investigate any unusual or unauthorized account activity.
+- Investigate the parent process wmiprvse.exe to determine how it was initiated. Look for any preceding suspicious activities or processes that might have triggered the WMI execution.
+- Check the system for any additional indicators of compromise, such as unexpected network connections, changes in system configurations, or other alerts related to the same host or user.
+- Correlate the event with other security logs and alerts to identify any patterns or related incidents that might indicate a broader attack campaign or persistent threat.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tasks may trigger this rule if they use cscript.exe or wscript.exe via WMI. To handle this, identify and document these scripts, then create exceptions for their specific execution paths or user accounts.
+- Software installations or updates that utilize script interpreters through WMI can be mistaken for malicious activity. Monitor and whitelist known installation processes or update mechanisms that are frequently used in your environment.
+- Custom applications or internal tools that rely on WMI for process execution might be flagged. Review these applications and exclude their specific process names or executable paths from the rule.
+- Scheduled tasks or system maintenance scripts executed by non-system accounts could generate alerts. Verify these tasks and exclude them by specifying the user accounts or domains that are authorized to perform such actions.
+- Security tools or monitoring solutions that leverage WMI for legitimate purposes may also be detected. Identify these tools and add them to the exception list based on their process names or executable locations.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified in the alert, such as cscript.exe or wscript.exe, that are running under non-system accounts.
+- Conduct a thorough review of the affected host's scheduled tasks, startup items, and services to identify and remove any persistence mechanisms.
+- Analyze the parent process wmiprvse.exe and its command-line arguments to understand the scope of the attack and identify any additional compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger campaign.
+- Implement additional monitoring and alerting for similar activities across the network, focusing on WMI-based script execution and non-standard process launches.
+- Review and update endpoint protection policies to block or alert on the execution of high-risk processes like those listed in the detection query, especially when initiated by non-system accounts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
index cfc6a035f4e..1a9f7b3e2a8 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,6 +82,41 @@ process where host.os.type == "windows" and event.type == "start" and
           "\\Device\\HarddiskVolume?\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe"
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft Exchange Server UM Spawning Suspicious Processes
+
+Microsoft Exchange Server's Unified Messaging (UM) integrates voice messaging with email, allowing users to access voicemails via their inbox. Adversaries exploit vulnerabilities like CVE-2021-26857 to execute unauthorized processes, potentially leading to system compromise. The detection rule identifies unusual processes initiated by UM services, excluding known legitimate executables, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process parent name is either "UMService.exe" or "UMWorkerProcess.exe" and verify the process executable path is not among the known legitimate paths listed in the exclusion criteria.
+- Gather additional context by checking the process command line arguments and the user account under which the suspicious process was executed to identify any anomalies or unauthorized access.
+- Investigate the historical activity of the host by reviewing recent logs for any other unusual or unauthorized processes, especially those related to the Microsoft Exchange Server.
+- Check for any recent patches or updates applied to the Microsoft Exchange Server to ensure that vulnerabilities like CVE-2021-26857 have been addressed.
+- Correlate the alert with other security tools and data sources such as Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or indicators of compromise.
+- Assess the network activity from the host to detect any potential lateral movement or data exfiltration attempts that might be associated with the suspicious process.
+
+### False positive analysis
+
+- Legitimate UM service updates or patches may trigger the rule. Regularly update the list of known legitimate executables to include new or updated UM service files.
+- Custom scripts or monitoring tools that interact with UM services might be flagged. Identify these scripts and add their executables to the exclusion list if they are verified as safe.
+- Non-standard installation paths for Exchange Server can cause false positives. Ensure that all legitimate installation paths are included in the exclusion list to prevent unnecessary alerts.
+- Administrative tasks performed by IT staff using command-line tools may be misidentified. Document these tasks and consider excluding the associated executables if they are part of routine maintenance.
+- Third-party integrations with Exchange Server that spawn processes could be flagged. Verify these integrations and exclude their executables if they are deemed secure and necessary for business operations.
+
+### Response and remediation
+
+- Isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified as being spawned by the UM service that are not part of the known legitimate executables list.
+- Apply the latest security patches and updates to the Microsoft Exchange Server to address CVE-2021-26857 and any other known vulnerabilities.
+- Conduct a thorough review of the server's security logs and network traffic to identify any additional indicators of compromise or unauthorized access attempts.
+- Restore the server from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from compromise.
+- Implement enhanced monitoring and alerting for any future suspicious processes spawned by the UM service, using the detection rule as a baseline.
+- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
index 24a7a35c94a..7f6d60614bf 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/08"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,42 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") or
   ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft Exchange Worker Spawning Suspicious Processes
+
+Microsoft Exchange Server uses the worker process (w3wp.exe) to handle web requests, often running under specific application pools. Adversaries exploit this by executing malicious scripts or commands, potentially via web shells, to gain unauthorized access or execute arbitrary code. The detection rule identifies unusual child processes like command-line interpreters spawned by w3wp.exe, signaling possible exploitation or backdoor activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the parent process is w3wp.exe and check if the process arguments include "MSExchange*AppPool" to ensure the alert is relevant to Microsoft Exchange.
+- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity.
+- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity.
+- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers.
+- Review recent changes or access logs on the affected Exchange server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell.
+- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and corroborate findings.
+- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule if administrators use command-line tools like cmd.exe or powershell.exe for legitimate maintenance. To manage this, create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks.
+- Scheduled tasks or scripts that run under the MSExchangeAppPool context might spawn command-line interpreters as part of their normal operation. Identify these tasks and exclude them by specifying their unique process arguments or command lines.
+- Monitoring or backup software that interacts with Exchange Server could inadvertently trigger the rule. Review the software's documentation to confirm its behavior and exclude its processes by name or hash if they are verified as safe.
+- Custom applications or integrations that interact with Exchange Server and use command-line tools for automation may also cause false positives. Work with application developers to understand these interactions and exclude them based on process names or specific command-line patterns.
+- If a known security tool or script is used to test Exchange Server's security posture, it might mimic suspicious behavior. Document these tools and exclude their processes during scheduled testing periods to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity.
+- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts.
+- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity.
+- Apply the latest security patches and updates to the Microsoft Exchange Server to mitigate known vulnerabilities and prevent exploitation.
+- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
index 3f33d06e360..2a5918ab9dc 100644
--- a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
+++ b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/29"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,41 @@ process where host.os.type == "windows" and event.type == "start" and
             "/factory,{ceff45ee-c862-41de-aee2-a022c81eda92}"
           )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Explorer Child Process
+
+Windows Explorer, a core component of the Windows OS, manages file and folder navigation. Adversaries exploit its trusted status to launch malicious scripts or executables, often using DCOM to start processes like PowerShell or cmd.exe. The detection rule identifies such anomalies by monitoring child processes of Explorer with specific characteristics, excluding known benign activities, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the suspicious child process was indeed started by explorer.exe with the specific parent arguments indicating DCOM usage, such as "-Embedding".
+- Check the process command line arguments and execution context to identify any potentially malicious scripts or commands being executed by the child process.
+- Investigate the parent process explorer.exe to determine if it was started by a legitimate user action or if there are signs of compromise, such as unusual user activity or recent phishing attempts.
+- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+- Examine the network activity associated with the suspicious process to detect any unauthorized data exfiltration or communication with known malicious IP addresses.
+- Assess the system for any additional indicators of compromise, such as unexpected changes in system files or registry keys, which might suggest a broader attack.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule when they use scripts or executables like PowerShell or cmd.exe. Users can create exceptions for known software update processes by identifying their specific command-line arguments or parent process details.
+- System administrators often use scripts for maintenance tasks that might be flagged by this rule. To prevent false positives, administrators should document and exclude these routine scripts by specifying their unique process arguments or execution times.
+- Some enterprise applications may use DCOM to launch processes for legitimate purposes. Users should identify these applications and exclude their specific process signatures or parent-child process relationships from the rule.
+- Automated testing environments might execute scripts or commands that resemble suspicious activity. Users can mitigate false positives by excluding processes that are part of known testing frameworks or environments.
+- Certain security tools or monitoring software may use similar techniques to gather system information. Users should verify and exclude these tools by confirming their process names and execution patterns.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the suspicious child process identified in the alert, such as cscript.exe, wscript.exe, powershell.exe, rundll32.exe, cmd.exe, mshta.exe, or regsvr32.exe, 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 additional malicious files or processes.
+- Review and analyze the parent process explorer.exe and its command-line arguments to understand how the malicious process was initiated and to identify any potential persistence mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring and alerting for similar suspicious activities involving explorer.exe to enhance detection capabilities and prevent recurrence.
+- Review and update endpoint security policies to restrict the execution of potentially malicious scripts or executables from explorer.exe, especially when initiated via DCOM."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_webshell_screenconnect_server.toml b/rules/windows/initial_access_webshell_screenconnect_server.toml
index c00dfc3018e..05073737ac9 100644
--- a/rules/windows/initial_access_webshell_screenconnect_server.toml
+++ b/rules/windows/initial_access_webshell_screenconnect_server.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,41 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or
   ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 ScreenConnect Server Spawning Suspicious Processes
+
+ScreenConnect, a remote support tool, allows administrators to control systems remotely. Adversaries may exploit this by executing unauthorized commands or scripts, potentially using it as a backdoor. The detection rule identifies unusual child processes like command shells spawned by the ScreenConnect service, signaling possible exploitation or web shell activity, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the parent process is ScreenConnect.Service.exe and identify the suspicious child process name, such as cmd.exe or powershell.exe.
+- Check the timestamp of the process start event to determine when the suspicious activity occurred and correlate it with any other unusual activities or alerts around the same time.
+- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Examine the command line arguments of the spawned process to identify any malicious or unauthorized commands being executed.
+- Review network logs for any unusual outbound connections initiated by the ScreenConnect service or the suspicious child process, which may indicate data exfiltration or communication with a command and control server.
+- Analyze the system for any additional indicators of compromise, such as unexpected file modifications or the presence of web shells, to assess the extent of the potential breach.
+
+### False positive analysis
+
+- Legitimate administrative tasks using command shells or scripting tools like cmd.exe or powershell.exe may trigger the rule. To manage this, create exceptions for known administrative scripts or tasks that are regularly executed by trusted users.
+- Automated maintenance scripts that utilize ScreenConnect for legitimate purposes can be mistaken for suspicious activity. Identify these scripts and whitelist their execution paths or specific process names to prevent false alerts.
+- Software updates or installations that require command line execution through ScreenConnect might be flagged. Document these processes and exclude them from the rule by specifying the associated process names or hashes.
+- Security tools or monitoring solutions that interact with ScreenConnect for legitimate scanning or logging purposes may inadvertently trigger the rule. Verify these tools and add them to an exception list based on their process identifiers or parent-child process relationships.
+- Training or demonstration sessions using ScreenConnect to showcase command line features could be misinterpreted as threats. Schedule these sessions and temporarily adjust the rule sensitivity or disable it during the known timeframes to avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified as being spawned by ScreenConnect.Service.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity.
+- Conduct a thorough review of recent ScreenConnect session logs to identify unauthorized access or unusual activity patterns, and revoke any compromised credentials.
+- Scan the affected system for additional indicators of compromise, such as web shells or other malware, using endpoint detection and response tools.
+- Apply security patches and updates to the ScreenConnect server and any other vulnerable applications to mitigate exploitation risks.
+- Restore the system from a known good backup if evidence of compromise is confirmed, ensuring that the backup is free from malicious artifacts.
+- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and evidence for further investigation."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/initial_access_xsl_script_execution_via_com.toml b/rules/windows/initial_access_xsl_script_execution_via_com.toml
index 4b35a4ed939..f145ce6612a 100644
--- a/rules/windows/initial_access_xsl_script_execution_via_com.toml
+++ b/rules/windows/initial_access_xsl_script_execution_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,41 @@ sequence with maxspan=1m
          "?:\\Program Files\\*.exe",
          "?:\\Program Files (x86)\\*exe")] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Remote XSL Script Execution via COM
+
+The Microsoft.XMLDOM COM interface allows applications to parse and transform XML documents using XSL scripts. Adversaries exploit this by embedding malicious scripts in Office documents, triggering execution via Office processes like Word or Excel. The detection rule identifies suspicious activity by monitoring for the loading of specific DLLs and the execution of unexpected child processes, indicating potential script execution attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Office process (e.g., winword.exe, excel.exe) that triggered the alert and note the process entity ID for further investigation.
+- Check the process tree to identify any unexpected child processes spawned by the Office application, focusing on those not matching typical system executables like WerFault.exe or conhost.exe.
+- Investigate the loaded DLLs, specifically msxml3.dll, to confirm its legitimate use and check for any anomalies or unusual patterns in its loading sequence.
+- Analyze the parent and child process relationships to determine if the execution flow aligns with typical user activity or if it suggests malicious behavior.
+- Gather additional context by reviewing recent user activity and document interactions to identify any potential phishing attempts or suspicious document handling that could have led to the alert.
+- Correlate the findings with other security events or alerts in the environment to assess if this activity is part of a broader attack pattern or isolated incident.
+
+### False positive analysis
+
+- Legitimate use of Microsoft Office applications for XML processing can trigger the rule. Users should identify and whitelist known applications or scripts that regularly perform XML transformations using the Microsoft.XMLDOM COM interface.
+- Automated document processing systems that utilize Office applications to handle XML data might cause false positives. Exclude these systems by specifying their process names or executable paths in the detection rule.
+- Software updates or installations that involve Office applications may load the msxml3.dll and start child processes. Temporarily disable the rule during scheduled maintenance or update windows to prevent false alerts.
+- Custom Office add-ins or macros that interact with XML files could be misidentified as threats. Review and approve these add-ins, then adjust the rule to exclude their specific behaviors.
+- Regular business processes that involve document conversion or data extraction using Office tools might be flagged. Document these processes and create exceptions based on their unique characteristics, such as specific file paths or process names.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the malicious script execution.
+- Terminate any suspicious processes identified as child processes of Office applications, such as winword.exe or excel.exe, that are not part of the standard executable paths.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious scripts or files.
+- Review and restore any altered or deleted files from secure backups to ensure data integrity and system functionality.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement application whitelisting to restrict the execution of unauthorized scripts and executables, particularly those not located in standard directories.
+- Enhance monitoring and alerting for similar activities by ensuring that the detection rule is actively deployed and that alerts are configured to notify the appropriate personnel promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_alternate_creds_pth.toml b/rules/windows/lateral_movement_alternate_creds_pth.toml
index b8afff146d2..d3b22ba5c4f 100644
--- a/rules/windows/lateral_movement_alternate_creds_pth.toml
+++ b/rules/windows/lateral_movement_alternate_creds_pth.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,41 @@ event.category : "authentication" and event.action : "logged-in" and
 winlog.logon.type : "NewCredentials" and event.outcome : "success" and 
 user.id : (S-1-5-21-* or S-1-12-1-*) and winlog.event_data.LogonProcessName : "seclogo"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Pass-the-Hash (PtH) Attempt
+
+Pass-the-Hash (PtH) is a technique where attackers use stolen password hashes to authenticate and move laterally across systems without needing plaintext passwords. This method exploits the authentication process in Windows environments. The detection rule identifies suspicious logins using specific logon types and processes, indicating potential PtH activity, by monitoring successful authentications with certain user IDs and logon processes.
+
+### Possible investigation steps
+
+- Review the event logs for the specific user IDs (S-1-5-21-* or S-1-12-1-*) to identify any unusual or unauthorized access patterns, focusing on the time and source of the logon events.
+- Examine the winlog.event_data.LogonProcessName field for "seclogo" to determine if this process is commonly used in your environment or if it appears suspicious or unexpected.
+- Correlate the successful authentication events with other security logs to identify any lateral movement or access to sensitive systems that occurred after the initial logon.
+- Investigate the source IP addresses and hostnames associated with the logon events to determine if they are known and trusted within the network or if they originate from unusual or external locations.
+- Check for any recent changes or anomalies in the accounts associated with the suspicious user IDs, such as password resets, privilege escalations, or unusual account activity.
+- Consult threat intelligence sources to see if there are any known campaigns or threat actors using similar techniques or targeting similar environments.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that use the "NewCredentials" logon type for automation or scheduled tasks can trigger false positives. Review and whitelist known benign processes or scripts that are part of regular operations.
+- Security software or monitoring tools that perform regular checks using the "seclogo" logon process may be misidentified. Identify and exclude these tools from the detection rule to prevent unnecessary alerts.
+- Service accounts with user IDs matching the specified patterns (S-1-5-21-* or S-1-12-1-*) might be flagged during routine operations. Ensure these accounts are documented and create exceptions for their expected activities.
+- Regularly scheduled tasks or maintenance activities that involve authentication processes similar to PtH can cause false positives. Document these activities and adjust the detection rule to account for their occurrence.
+- User behavior analytics might incorrectly flag normal user activities as suspicious. Implement user behavior baselining to differentiate between typical and atypical logon patterns, refining the detection criteria accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
+- Revoke any active sessions associated with the compromised user IDs (S-1-5-21-* or S-1-12-1-*) to disrupt the attacker's access.
+- Conduct a password reset for the affected accounts and any other accounts that may have been accessed using the compromised hashes.
+- Review and update access controls and permissions for the affected accounts to ensure they adhere to the principle of least privilege.
+- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activity or attempts to use stolen hashes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional logging and monitoring for the "seclogo" logon process to enhance detection of future pass-the-hash attempts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_cmd_service.toml b/rules/windows/lateral_movement_cmd_service.toml
index 6bc844d0c45..8cb0dca8327 100644
--- a/rules/windows/lateral_movement_cmd_service.toml
+++ b/rules/windows/lateral_movement_cmd_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,40 @@ sequence by process.entity_id with maxspan = 1m
       process.args : ("create", "config", "failure", "start")]
   [network where host.os.type == "windows" and process.name : "sc.exe" and destination.ip != "127.0.0.1"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Service Command Lateral Movement
+
+The Service Control Manager in Windows allows for the management of services, which are crucial for system operations. Adversaries exploit this by using `sc.exe` to manipulate services on remote systems, facilitating lateral movement. The detection rule identifies suspicious `sc.exe` usage by monitoring for service-related commands targeting remote hosts, which may indicate unauthorized access attempts. This rule helps differentiate between legitimate administrative actions and potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of sc.exe, focusing on the process.entity_id and process.args fields to understand the specific service-related actions attempted.
+- Examine the network activity associated with the sc.exe process, particularly the destination.ip field, to identify the remote host targeted by the command and assess if it is a legitimate administrative target.
+- Check the event logs on the remote host for any corresponding service creation, modification, or start events to verify if the actions were successfully executed and to gather additional context.
+- Investigate the user account associated with the sc.exe process to determine if it has the necessary permissions for such actions and if the account usage aligns with expected behavior.
+- Correlate the alert with other recent alerts or logs involving the same process.entity_id or destination.ip to identify any patterns or additional suspicious activities that may indicate a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks using sc.exe on remote systems can trigger false positives. Identify and document regular maintenance schedules and responsible personnel to differentiate these from potential threats.
+- Automated scripts or management tools that use sc.exe for legitimate service management may cause alerts. Review and whitelist these scripts or tools by their process entity IDs to reduce noise.
+- Internal IT operations often involve creating or modifying services remotely. Establish a baseline of normal activity patterns and exclude these from alerts by setting exceptions for known IP addresses or user accounts.
+- Software deployment processes that involve service configuration changes can be mistaken for lateral movement. Coordinate with software deployment teams to understand their processes and exclude these activities from detection.
+- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and unauthorized access to other systems.
+- Terminate any suspicious `sc.exe` processes identified on the affected system to halt any ongoing malicious activity.
+- Review and reset credentials for any accounts that were used in the suspicious `sc.exe` activity to prevent unauthorized access.
+- Conduct a thorough examination of the affected system for any additional signs of compromise, such as unauthorized services or changes to existing services.
+- Restore the affected system from a known good backup if any malicious modifications or persistent threats are detected.
+- Implement network segmentation to limit the ability of adversaries to move laterally across the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_hta.toml b/rules/windows/lateral_movement_dcom_hta.toml
index 17625556c65..4b76978dc12 100644
--- a/rules/windows/lateral_movement_dcom_hta.toml
+++ b/rules/windows/lateral_movement_dcom_hta.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,41 @@ sequence with maxspan=1m
      source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1"
   ] by host.id, process.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Incoming DCOM Lateral Movement via MSHTA
+
+DCOM allows software components to communicate over a network, enabling remote execution of applications like MSHTA, which runs HTML applications. Adversaries exploit this by executing commands remotely, bypassing traditional security measures. The detection rule identifies suspicious MSHTA activity by monitoring process starts and network traffic, focusing on unusual port usage and remote IP addresses, indicating potential lateral movement attempts.
+
+### Possible investigation steps
+
+- Review the process start event for mshta.exe on the affected host to gather details such as the process entity ID, command-line arguments, and parent process information to understand how mshta.exe was executed.
+- Analyze the network traffic associated with the mshta.exe process, focusing on the source and destination IP addresses and ports, to identify any unusual or unauthorized remote connections.
+- Check the source IP address involved in the network event to determine if it is known or associated with any previous suspicious activity or if it belongs to an internal or external network.
+- Investigate the timeline of events on the host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or lateral movement attempts.
+- Correlate the findings with other security logs and alerts from the same host or network segment to identify any additional indicators of compromise or related malicious activities.
+- Assess the risk and impact of the detected activity by considering the host's role within the network and any sensitive data or systems it may have access to.
+
+### False positive analysis
+
+- Legitimate administrative tasks using MSHTA for remote management can trigger the rule. Identify and document these tasks, then create exceptions for known administrative IP addresses or specific user accounts.
+- Automated software updates or deployments that utilize MSHTA may appear as suspicious activity. Monitor and whitelist the IP addresses and ports associated with these updates to prevent false positives.
+- Internal network scanning tools or security assessments might mimic lateral movement behavior. Coordinate with IT and security teams to recognize these activities and exclude them from triggering alerts.
+- Custom applications that leverage MSHTA for inter-process communication could be flagged. Review these applications and exclude their known processes or network patterns from the detection rule.
+- Remote desktop or support tools that use MSHTA for legitimate purposes should be identified. Whitelist these tools by their process names or associated network traffic to reduce unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate the mshta.exe process on the affected host to stop any ongoing malicious activity.
+- Conduct a thorough examination of the affected host to identify any additional malicious files or processes, focusing on those initiated around the time of the alert.
+- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access.
+- Review and restrict DCOM permissions and configurations on the affected host and other critical systems to limit the potential for similar attacks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems have been compromised.
+- Update detection mechanisms and threat intelligence feeds to enhance monitoring for similar DCOM-based lateral movement attempts in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_mmc20.toml b/rules/windows/lateral_movement_dcom_mmc20.toml
index fd2ad45bc02..1bd081e4ee4 100644
--- a/rules/windows/lateral_movement_dcom_mmc20.toml
+++ b/rules/windows/lateral_movement_dcom_mmc20.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,40 @@ sequence by host.id with maxspan=1m
  [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe"
  ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Incoming DCOM Lateral Movement with MMC
+
+Distributed Component Object Model (DCOM) enables software components to communicate over a network, often used in Windows environments for remote management. Adversaries exploit DCOM to execute commands remotely, leveraging applications like MMC20 to move laterally. The detection rule identifies suspicious activity by monitoring network traffic and process creation patterns, flagging potential misuse when MMC initiates remote commands, indicating possible lateral movement or defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the source IP address that initiated the connection to the host running mmc.exe. Verify if this IP address is known and expected within the network environment.
+- Examine the process creation logs to confirm the parent-child relationship between mmc.exe and any suspicious processes. Investigate the child processes for any unusual or unauthorized activities.
+- Check the source and destination ports (both should be >= 49152) involved in the network connection to determine if they align with typical application behavior or if they are indicative of potential misuse.
+- Investigate the timeline of events to see if there are any other related alerts or activities on the same host or originating from the same source IP address, which could provide additional context or indicate a broader attack pattern.
+- Correlate the findings with any existing threat intelligence or known attack patterns related to DCOM abuse and lateral movement to assess the potential risk and impact on the organization.
+
+### False positive analysis
+
+- Legitimate administrative tasks using MMC may trigger the rule. Regularly review and document routine administrative activities to differentiate them from suspicious behavior.
+- Automated scripts or management tools that use MMC for remote management can cause false positives. Identify and whitelist these tools by their process and network patterns.
+- Internal network scanning or monitoring tools might mimic the behavior detected by the rule. Exclude known IP addresses or ranges associated with these tools to reduce noise.
+- Scheduled tasks or maintenance operations that involve MMC could be misinterpreted as lateral movement. Ensure these tasks are logged and recognized as part of normal operations.
+- Software updates or patches that require MMC to execute remote commands might trigger alerts. Maintain an updated list of such activities and exclude them from triggering the rule.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further lateral movement and contain the threat.
+- Terminate any suspicious processes associated with mmc.exe on the affected host to stop any ongoing malicious activity.
+- Conduct a thorough review of the affected host's event logs and network traffic to identify any additional indicators of compromise or other affected systems.
+- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
+- Apply patches and updates to the affected systems and any other vulnerable systems in the network to mitigate known vulnerabilities that could be exploited.
+- Implement network segmentation to limit the ability of threats to move laterally within the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional actions are necessary."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
index 0ae4173fb6c..5648650c87e 100644
--- a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
+++ b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,41 @@ sequence by host.id with maxspan=5s
   process.parent.name : "explorer.exe"
  ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows
+
+DCOM enables software components to communicate over a network, often used in Windows environments for legitimate inter-process communication. Adversaries exploit DCOM, particularly ShellBrowserWindow or ShellWindows, to execute commands remotely, facilitating stealthy lateral movement. The detection rule identifies suspicious network activity and process creation patterns, such as incoming TCP connections to high ports and explorer.exe spawning processes, which may indicate DCOM abuse.
+
+### Possible investigation steps
+
+- Review the network activity to identify the source IP address of the incoming TCP connection. Verify if the source IP is known or expected within the network environment.
+- Examine the process tree for explorer.exe to identify any unusual or unexpected child processes that were spawned. Investigate these processes for any signs of malicious activity.
+- Check the destination port and source port numbers to determine if they are commonly used for legitimate services or if they are unusual for the environment.
+- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns associated with the same source IP or process entity.
+- Investigate the user account associated with the explorer.exe process to determine if there are any signs of compromise or unauthorized access.
+- Review historical data for any previous occurrences of similar network connections or process creations to identify potential patterns or repeated attempts.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule due to the use of DCOM for remote management tasks. Users can create exceptions for known update processes by identifying their specific network and process patterns.
+- Internal IT management tools that utilize DCOM for remote administration might cause false positives. Review and whitelist these tools by confirming their source IP addresses and process behaviors.
+- Automated scripts or scheduled tasks that leverage DCOM for legitimate purposes can be mistaken for lateral movement. Document and exclude these tasks by correlating their execution times and process chains.
+- Network scanning or monitoring tools that generate high-port TCP connections could be misinterpreted as suspicious activity. Validate and exclude these tools by cross-referencing their network traffic with known benign sources.
+- User-initiated remote desktop sessions or file transfers using DCOM may appear as lateral movement. Verify and exclude these activities by checking user authentication logs and session details.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious processes spawned by explorer.exe that are not part of normal operations, focusing on those initiated through high TCP ports.
+- Conduct a thorough review of recent network connections and process creation logs on the affected host to identify any additional compromised systems or lateral movement attempts.
+- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access.
+- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited during the attack.
+- Enhance monitoring and logging on the network to detect similar DCOM abuse attempts, ensuring that alerts are configured for high TCP port activity and unusual process spawning by explorer.exe.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
index 74e5284a1ad..3f1af9489dd 100644
--- a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
+++ b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,40 @@ registry.path : (
 ) and length(registry.data.strings) > 0 and
 not registry.data.strings : "(empty)"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 NullSessionPipe Registry Modification
+
+The NullSessionPipe registry setting in Windows defines which named pipes can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. The detection rule monitors changes to this registry path, flagging modifications that introduce new accessible pipes, which could indicate malicious intent.
+
+### Possible investigation steps
+
+- Review the registry event details to confirm the specific named pipes added or modified in the NullSessionPipes registry path. Focus on the registry.data.strings field to identify any new or suspicious entries.
+- Correlate the timestamp of the registry change event with other security events or logs from the same host to identify any concurrent suspicious activities, such as unusual network connections or process executions.
+- Investigate the user account or process responsible for the registry modification by examining the event data for user context or process identifiers. This can help determine if the change was made by an unauthorized user or malicious process.
+- Check for any recent alerts or logs related to lateral movement or unauthorized access attempts on the network, focusing on the host where the registry change was detected.
+- Assess the risk and impact of the modified named pipes by determining if they are commonly used in legitimate operations or if they are known to be exploited by malware or threat actors.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts may modify the NullSessionPipe registry setting as part of routine network management. Review the source of the change and verify if it aligns with known administrative activities.
+- Some network services or applications might require anonymous access to specific pipes for functionality. Identify these services and document them to differentiate between expected and unexpected modifications.
+- Scheduled tasks or automated deployment scripts could alter the registry setting during updates or installations. Ensure these tasks are documented and verify their legitimacy.
+- Security software or network monitoring tools might adjust the NullSessionPipe settings for scanning purposes. Confirm with your security team if such tools are in use and adjust the detection rule to exclude these known activities.
+- Regularly review and update the list of known exceptions in your detection system to prevent alert fatigue and ensure focus on genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Review the registry changes to identify any unauthorized pipes added to the NullSessionPipes registry key and remove them to restore secure configurations.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software that may have been introduced.
+- Analyze network logs and system event logs to identify any unauthorized access attempts or successful connections made through the modified pipes, and block any suspicious IP addresses or accounts.
+- Reset credentials for any accounts that may have been compromised or used in conjunction with the unauthorized access to ensure they cannot be reused by adversaries.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected.
+- Implement enhanced monitoring and alerting for changes to the NullSessionPipes registry key and similar registry paths to detect and respond to future unauthorized modifications promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
index 1e1e22abd20..591fc4776de 100644
--- a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
+++ b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/12"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -66,6 +66,40 @@ any where host.os.type == "windows" and
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Remote Desktop Shadowing Activity
+
+Remote Desktop Shadowing allows administrators to view or control active RDP sessions, aiding in support and troubleshooting. However, adversaries can exploit this feature to monitor or hijack user sessions without consent. The detection rule identifies suspicious modifications to RDP Shadow registry settings and the execution of specific processes linked to shadowing, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the registry event details to confirm if there was a modification to the RDP Shadow registry path, specifically checking for changes in "HKLM\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow".
+- Investigate the process events to identify if "RdpSaUacHelper.exe" or "RdpSaProxy.exe" were started by "svchost.exe", which could indicate unauthorized shadowing activity.
+- Check for any instances of "mstsc.exe" being executed with the "/shadow:*" argument, as this could signify an attempt to shadow an RDP session.
+- Correlate the identified processes and registry changes with user activity logs to determine if the actions were authorized or expected as part of legitimate administrative tasks.
+- Analyze network logs for any unusual remote connections or lateral movement patterns that coincide with the timing of the detected shadowing activity.
+- Consult endpoint security solutions like Microsoft Defender for Endpoint or SentinelOne for additional context or alerts related to the same host or user account involved in the shadowing activity.
+
+### False positive analysis
+
+- Legitimate administrative activities may trigger alerts when IT staff use RDP Shadowing for support. To manage this, create exceptions for known IT administrator accounts or specific IP addresses.
+- Scheduled maintenance or automated scripts that modify RDP Shadow registry settings can be mistaken for malicious activity. Identify and exclude these processes or scripts from the detection rule.
+- Security software or monitoring tools that interact with RDP sessions might mimic shadowing behavior. Verify these tools and whitelist their processes to prevent false alerts.
+- Training sessions or remote support tools that use RDP Shadowing features can generate alerts. Document and exclude these activities by identifying their unique process names or arguments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified in the alert, such as RdpSaUacHelper.exe, RdpSaProxy.exe, or mstsc.exe with shadowing arguments, to stop potential session hijacking.
+- Revert any unauthorized changes to the RDP Shadow registry settings to their default or secure state to prevent further exploitation.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized changes have been made, and reset passwords for any compromised accounts.
+- 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 enhanced monitoring and logging for RDP activities across the network to detect and respond to similar threats more quickly in the future.
+- Review and update RDP access policies and configurations to ensure they align with best practices, such as enforcing multi-factor authentication and limiting RDP access to only necessary users and systems."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
index d5fa197c1de..b67ca1b496d 100644
--- a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
+++ b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,41 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.executable : "\\Device\\Mup\\tsclient\\*.exe"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution via TSClient Mountpoint
+
+The TSClient mountpoint is a feature of the Remote Desktop Protocol (RDP) that allows users to access local drives from a remote session. Adversaries can exploit this by executing malicious files from the shared mountpoint, facilitating lateral movement within a network. The detection rule identifies such activities by monitoring for process executions originating from the TSClient path, signaling potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process execution path matches the pattern "\\\\Device\\\\Mup\\\\tsclient\\\\*.exe" and verify the host operating system is Windows.
+- Identify the user account associated with the RDP session and check for any unusual or unauthorized access patterns, such as logins from unexpected locations or at odd times.
+- Examine the executed process's hash and compare it against known malicious hashes in threat intelligence databases to determine if the file is potentially harmful.
+- Investigate the source system from which the RDP session originated to identify any signs of compromise or unauthorized access that could indicate lateral movement.
+- Check for any additional suspicious activities on the target host, such as unexpected network connections or file modifications, that may correlate with the execution event.
+- Review the security logs from data sources like Microsoft Defender for Endpoint or Sysmon for any related alerts or anomalies that could provide further context on the incident.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they are executed from a local drive mapped through TSClient. To manage this, create exceptions for known update processes or installation paths that are frequently used in your environment.
+- IT administrative tasks performed via RDP sessions can also cause false positives. Identify and exclude specific administrative tools or scripts that are regularly executed from TSClient paths by trusted personnel.
+- Automated backup or synchronization software that accesses local drives through RDP might be flagged. Review and whitelist these processes if they are part of routine operations.
+- Development or testing activities involving remote execution of scripts or applications from TSClient can be mistaken for threats. Establish a list of approved development tools and paths to exclude from monitoring.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious processes running from the TSClient path to halt any ongoing malicious activity.
+- Conduct a thorough scan of the affected host using endpoint detection and response (EDR) tools to identify and remove any malicious files or artifacts.
+- Review and analyze RDP logs and session details to identify unauthorized access attempts and determine the source of the intrusion.
+- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
+- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for similar threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
index f3a096eded1..f9dae8c38ba 100644
--- a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
+++ b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,41 @@ sequence by host.id with maxspan=30s
    [process where host.os.type == "windows" and 
     event.type == "start" and process.parent.name : "winrshost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Incoming Execution via WinRM Remote Shell
+
+Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. While beneficial for legitimate administrative tasks, adversaries can exploit WinRM for lateral movement by executing commands remotely. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by WinRM, flagging potential unauthorized remote executions.
+
+### Possible investigation steps
+
+- Review the network traffic logs to confirm the presence of incoming connections on ports 5985 or 5986, which are used by WinRM, and verify if these connections are expected or authorized.
+- Identify the source IP address of the incoming connection and determine if it belongs to a known and trusted network or device. Investigate any unfamiliar or suspicious IP addresses.
+- Examine the process tree for the process initiated by winrshost.exe to identify any unusual or unauthorized processes that were started as a result of the remote execution.
+- Check the user account associated with the WinRM session to ensure it is legitimate and has not been compromised. Look for any signs of unauthorized access or privilege escalation.
+- Correlate the event with other security logs, such as authentication logs, to identify any related suspicious activities or patterns that might indicate lateral movement or a broader attack campaign.
+- Investigate the timeline of events to determine if there are any other related alerts or activities occurring around the same time that could provide additional context or evidence of malicious intent.
+
+### False positive analysis
+
+- Legitimate administrative tasks using WinRM can trigger alerts. Regularly review and whitelist known administrative IP addresses or users to reduce false positives.
+- Automated scripts or management tools that use WinRM for routine tasks may be flagged. Identify these scripts and create exceptions for their specific process names or execution paths.
+- Monitoring tools that check system health via WinRM might be misidentified as threats. Exclude these tools by specifying their source IPs or process names in the detection rule.
+- Scheduled tasks that utilize WinRM for updates or maintenance can cause alerts. Document these tasks and adjust the rule to ignore their specific execution patterns.
+- Internal security scans or compliance checks using WinRM should be accounted for. Coordinate with security teams to recognize these activities and exclude them from triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious processes associated with WinRM, particularly those not originating from legitimate administrative tools or known good sources.
+- Review and revoke any unauthorized access credentials or accounts that may have been used to initiate the WinRM session.
+- Conduct a thorough examination of the affected host for any additional signs of compromise, such as unauthorized software installations or changes to system configurations.
+- Restore the affected system from a known good backup if any malicious activity or unauthorized changes are confirmed.
+- Implement network segmentation to limit the ability of threats to move laterally across the network, focusing on restricting access to critical systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_incoming_wmi.toml b/rules/windows/lateral_movement_incoming_wmi.toml
index 0c695c6002d..cc46ebefe0b 100644
--- a/rules/windows/lateral_movement_incoming_wmi.toml
+++ b/rules/windows/lateral_movement_incoming_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -59,6 +59,41 @@ sequence by host.id with maxspan = 2s
    not (process.executable : "?:\\Windows\\System32\\inetsrv\\appcmd.exe" and process.args : "uninstall")
    ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WMI Incoming Lateral Movement
+
+Windows Management Instrumentation (WMI) is a core Windows feature enabling remote management and data collection. Adversaries exploit WMI for lateral movement by executing processes on remote hosts, often bypassing traditional security measures. The detection rule identifies suspicious WMI activity by monitoring specific network connections and process executions, filtering out common false positives to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the source IP address of the incoming RPC connection to determine if it is from a known or trusted network segment, excluding localhost addresses like 127.0.0.1 and ::1.
+- Check the process name and parent process name, specifically looking for svchost.exe and WmiPrvSE.exe, to confirm the execution context and identify any unusual parent-child process relationships.
+- Investigate the user ID associated with the process execution to ensure it is not a system account (S-1-5-18, S-1-5-19, S-1-5-20) and assess if the user has legitimate reasons for remote WMI activity.
+- Examine the process executable path to verify it is not one of the excluded common false positives, such as those related to HPWBEM, SCCM, or other specified system utilities.
+- Analyze the network connection details, including source and destination ports, to identify any patterns or anomalies that could indicate malicious lateral movement.
+- Correlate the alert with other security events or logs from the same host or network segment to gather additional context and identify potential patterns of compromise.
+
+### False positive analysis
+
+- Administrative use of WMI for remote management can trigger alerts. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff.
+- Security tools like Nessus and SCCM may cause false positives. Exclude processes associated with these tools by adding their executables to the exception list.
+- System processes running with high integrity levels might be flagged. Exclude processes with integrity levels marked as "System" to reduce noise.
+- Specific executables such as msiexec.exe and appcmd.exe with certain arguments can be safely excluded if they are part of routine administrative tasks.
+- Regularly review and update the exception list to ensure it aligns with current network management practices and tools.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools.
+- Terminate any suspicious processes identified as being executed via WMI on the affected host. Use task management tools or scripts to stop these processes.
+- Conduct a thorough review of the affected host's WMI logs and process execution history to identify any unauthorized changes or additional malicious activity.
+- Reset credentials for any accounts that were used in the suspicious WMI activity, especially if they have administrative privileges, to prevent further unauthorized access.
+- Apply patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation methods, ensuring that all security updates are current.
+- Enhance monitoring and logging for WMI activity across the network to detect and respond to similar threats more quickly in the future. This includes setting up alerts for unusual WMI usage patterns.
+- If the threat is confirmed to be part of a larger attack, escalate the incident to the appropriate security team or authority for further investigation and potential legal action."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
index 9f0ca208eae..580e0199488 100644
--- a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
+++ b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/02"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,40 @@ process where host.os.type == "windows" and event.type == "start" and
  /* excluding shares deletion operation */
  not process.args : "/d*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Mounting Hidden or WebDav Remote Shares
+
+WebDav and hidden remote shares facilitate file sharing and collaboration across networks, often used in enterprise environments. Adversaries exploit these to move laterally or exfiltrate data by mounting shares using tools like net.exe. The detection rule identifies suspicious share mounts by monitoring specific command patterns, excluding benign operations, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of net.exe or net1.exe for mounting shares, focusing on the process.name and process.pe.original_file_name fields.
+- Examine the process.args field to identify the specific share being accessed, noting any patterns like "\\\\\\\\*\\\\*$*", "\\\\\\\\*@SSL\\\\*", or "http*" that indicate hidden or WebDav shares.
+- Check the parent process information to determine if net1.exe was executed independently or as a child of another suspicious process, which could suggest malicious intent.
+- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears anomalous.
+- Correlate the event with other logs or alerts from the same host or user to identify any patterns of lateral movement or data exfiltration attempts.
+- Assess the network activity around the time of the alert to detect any unusual outbound connections that might indicate data exfiltration.
+
+### False positive analysis
+
+- Legitimate use of net.exe for mounting network drives in enterprise environments can trigger false positives. Users can create exceptions for known internal IP addresses or specific user accounts frequently performing these actions.
+- Automated scripts or system processes that use net.exe to connect to WebDav or hidden shares for legitimate purposes may be flagged. Identify these scripts and processes, and exclude them by their process hash or command line patterns.
+- Regular operations involving OneDrive or other cloud-based services might be misidentified as suspicious. Exclude these by specifying known service URLs or domains in the detection rule.
+- Administrative tasks involving network share management can be mistaken for threats. Document and exclude these tasks by correlating them with scheduled maintenance windows or specific admin user accounts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Terminate any suspicious processes related to net.exe or net1.exe that are actively mounting hidden or WebDav shares.
+- Conduct a thorough review of recent file access and transfer logs to identify any unauthorized data access or exfiltration attempts.
+- Change credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access.
+- Implement network segmentation to limit access to critical systems and sensitive data, reducing the risk of lateral movement.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Enhance monitoring and alerting for similar activities by ensuring that all relevant security tools are configured to detect and alert on suspicious use of net.exe and net1.exe."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_powershell_remoting_target.toml b/rules/windows/lateral_movement_powershell_remoting_target.toml
index d819cf2f387..d144f3dd34e 100644
--- a/rules/windows/lateral_movement_powershell_remoting_target.toml
+++ b/rules/windows/lateral_movement_powershell_remoting_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,41 @@ sequence by host.id with maxspan = 30s
    [process where host.os.type == "windows" and 
     event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Incoming Execution via PowerShell Remoting
+
+PowerShell Remoting enables administrators to execute commands on remote Windows systems, facilitating efficient management. However, adversaries can exploit this feature for lateral movement within a network. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by PowerShell Remoting, flagging potential unauthorized remote executions.
+
+### Possible investigation steps
+
+- Review the network traffic logs to identify the source IP address involved in the alert, ensuring it is not a known or authorized management system.
+- Check the destination port (5985 or 5986) to confirm it aligns with PowerShell Remoting activity and verify if the connection was expected or authorized.
+- Investigate the process tree on the affected host to determine if the process initiated by wsmprovhost.exe is legitimate or if it shows signs of suspicious activity.
+- Examine the parent process of wsmprovhost.exe to identify any unusual or unauthorized processes that may have triggered the PowerShell Remoting session.
+- Correlate the event with user activity logs to determine if the remote execution was performed by a legitimate user or if there are signs of compromised credentials.
+- Assess the risk score and severity in the context of the organization's environment to prioritize the response and determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Legitimate administrative tasks using PowerShell Remoting can trigger the rule. To manage this, identify and whitelist known administrative IP addresses or user accounts that frequently perform remote management tasks.
+- Automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance might be flagged. Review and document these scripts, then create exceptions for their specific process names or execution paths.
+- Security tools or monitoring solutions that leverage PowerShell Remoting for legitimate purposes may cause alerts. Verify these tools and exclude their associated network traffic or processes from the detection rule.
+- Internal IT support activities that involve remote troubleshooting using PowerShell Remoting can be mistaken for threats. Maintain a list of support personnel and their IP addresses to exclude them from triggering alerts.
+- Regular software updates or patch management processes that utilize PowerShell Remoting should be considered. Identify these processes and exclude their network traffic or process executions to prevent false positives.
+
+### Response and remediation
+
+- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary.
+- Terminate any suspicious PowerShell processes identified, especially those initiated by wsmprovhost.exe, to stop unauthorized remote executions.
+- Conduct a thorough review of recent user activity and access logs on the affected host to identify any unauthorized access or changes.
+- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access.
+- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited.
+- Enhance monitoring on the network for unusual activity on ports 5985 and 5986 to detect any future attempts at unauthorized PowerShell Remoting.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_rdp_sharprdp_target.toml b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
index ea6733fab44..5dad77a8d64 100644
--- a/rules/windows/lateral_movement_rdp_sharprdp_target.toml
+++ b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,40 @@ sequence by host.id with maxspan=1m
    not process.name : "conhost.exe"
    ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential SharpRDP Behavior
+
+Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement within a network. SharpRDP, a tool for executing commands on remote systems via RDP, can be misused for unauthorized access. The detection rule identifies suspicious RDP activity by monitoring network connections, registry changes, and process executions, flagging potential misuse indicative of SharpRDP behavior.
+
+### Possible investigation steps
+
+- Review the network logs to confirm the presence of incoming RDP connections on port 3389, specifically looking for connections initiated by IP addresses other than localhost (127.0.0.1 or ::1).
+- Examine the registry changes to identify any new RunMRU string values set to cmd, powershell, taskmgr, or tsclient, which could indicate command execution attempts.
+- Investigate the process execution logs to verify if any processes were started with parent processes like cmd.exe, powershell.exe, or taskmgr.exe, and ensure these are not legitimate administrative actions.
+- Correlate the timestamps of the RDP connection, registry change, and process execution to determine if they align within the 1-minute window specified by the detection rule.
+- Check the source IP address of the RDP connection against known threat intelligence feeds to assess if it is associated with any malicious activity.
+- Analyze user account activity associated with the RDP session to determine if the account was compromised or if the actions were authorized.
+
+### False positive analysis
+
+- Legitimate administrative tasks using RDP may trigger the rule if they involve command execution through cmd, powershell, or taskmgr. To manage this, create exceptions for known administrative IP addresses or user accounts frequently performing these tasks.
+- Automated scripts or software updates that modify the RunMRU registry key with benign commands can be mistaken for SharpRDP behavior. Identify and exclude these processes or scripts from the detection rule.
+- Remote management tools that use RDP and execute commands as part of their normal operation might be flagged. Whitelist these tools by their process names or specific command patterns to prevent false positives.
+- Internal network scanning or monitoring tools that simulate RDP connections for security assessments could be misinterpreted. Exclude these tools by their source IP addresses or network behavior signatures.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement and unauthorized access.
+- Terminate any suspicious processes identified in the alert, such as those initiated by cmd.exe, powershell.exe, or taskmgr.exe, to halt any ongoing malicious activity.
+- Review and revert any unauthorized registry changes, particularly those related to the RunMRU registry path, to restore system integrity.
+- Conduct a thorough examination of the affected host for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any found.
+- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent further unauthorized access.
+- 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 enhanced monitoring and logging for RDP connections and registry changes to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
index 232552123a3..4dd1ff96e5c 100644
--- a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
+++ b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,41 @@ process where host.os.type == "windows" and event.type == "start" and
     process.name : "robocopy.exe"
   ) and process.args : "*\\\\*\\*$*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Remote File Copy to a Hidden Share
+
+In Windows environments, hidden network shares are often used for legitimate administrative tasks, allowing file transfers without user visibility. However, adversaries can exploit these shares for lateral movement or data exfiltration. The detection rule identifies suspicious file copy attempts using common command-line tools like cmd.exe and powershell.exe, focusing on hidden share patterns to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific command-line tool used (cmd.exe, powershell.exe, xcopy.exe, or robocopy.exe) and examine the arguments to understand the nature of the file copy operation.
+- Investigate the source and destination of the file copy by analyzing the network share path in the process arguments, focusing on the hidden share pattern (e.g., \\\\*\\\\*$).
+- Check the user account associated with the process to determine if it has legitimate access to the hidden share and assess if the activity aligns with the user's typical behavior.
+- Correlate the event with other logs or alerts from the same host or user to identify any additional suspicious activities, such as unusual login attempts or privilege escalation.
+- Examine the historical activity of the involved host to identify any previous instances of similar file copy attempts or other indicators of lateral movement.
+- Consult threat intelligence sources to determine if the detected pattern or tools are associated with known adversary techniques or campaigns.
+
+### False positive analysis
+
+- Administrative tasks using hidden shares can trigger alerts. Regularly review and document legitimate administrative activities that involve file transfers to hidden shares.
+- Backup operations often use hidden shares for data storage. Identify and exclude backup processes by specifying known backup software and their typical command-line arguments.
+- Software deployment tools may utilize hidden shares for distributing updates. Create exceptions for recognized deployment tools by listing their process names and associated arguments.
+- IT maintenance scripts might copy files to hidden shares for system updates. Maintain a list of approved maintenance scripts and exclude them from triggering alerts.
+- User-initiated file transfers for legitimate purposes can be mistaken for threats. Educate users on proper file transfer methods and monitor for unusual patterns that deviate from documented procedures.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement or data exfiltration.
+- Terminate any suspicious processes identified in the alert, such as cmd.exe, powershell.exe, xcopy.exe, or robocopy.exe, that are involved in the file copy attempt.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or unauthorized access.
+- Change credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access.
+- Review and restrict permissions on network shares, especially hidden shares, to ensure only authorized users have access.
+- Monitor network traffic for any further suspicious activity related to hidden shares and lateral movement attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_remote_service_installed_winlog.toml b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
index 52e69a456f1..68195e9ac98 100644
--- a/rules/windows/lateral_movement_remote_service_installed_winlog.toml
+++ b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -63,6 +63,41 @@ event.outcome=="success" and source.ip != null and source.ip != "127.0.0.1" and
                 "?:\\Windows\\SysWOW64\\NwxExeSvc\\NwxExeSvc.exe",
                 "?:\\Windows\\System32\\taskhostex.exe")]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Remote Windows Service Installed
+
+Windows services are crucial for running background processes. Adversaries exploit this by installing services remotely to maintain persistence or move laterally within a network. The detection rule identifies suspicious service installations following a network logon, excluding known legitimate services, to flag potential unauthorized activities. This helps in identifying and mitigating threats early.
+
+### Possible investigation steps
+
+- Review the source IP address from the authentication event to determine if it is from a known or trusted network segment. Investigate any unfamiliar or suspicious IP addresses.
+- Check the winlog.logon.id to correlate the logon session with the service installation event, ensuring they are part of the same session.
+- Investigate the user account associated with the logon session to determine if the activity aligns with their typical behavior or role within the organization.
+- Examine the service file path from the service-installed event to identify if it is a known or legitimate application. Pay special attention to any paths not excluded in the query.
+- Look into the history of the computer where the service was installed (winlog.computer_name) for any previous suspicious activities or alerts.
+- Assess the timing and frequency of similar events to determine if this is an isolated incident or part of a broader pattern of suspicious behavior.
+
+### False positive analysis
+
+- Administrative activities can trigger false positives when administrators frequently install or update services remotely. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff.
+- Legitimate software installations or updates may appear as suspicious service installations. Maintain an updated list of authorized software paths and exclude these from the detection rule.
+- Automated deployment tools like PDQ Deploy or Veeam Backup can cause false positives. Identify and exclude the service paths associated with these tools to reduce noise.
+- Scheduled tasks that install or update services as part of routine maintenance can be mistaken for threats. Document and exclude these tasks from the rule to prevent unnecessary alerts.
+- Internal security tools that perform regular checks or updates may also trigger alerts. Ensure these tools are recognized and their service paths are excluded from the detection criteria.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools.
+- Terminate any unauthorized services identified by the alert to stop any malicious processes from running. Use task management tools or command-line utilities to stop and disable these services.
+- Conduct a thorough review of recent logon events and service installations on the affected system to identify any additional unauthorized activities or compromised accounts.
+- Change passwords for any accounts that were used in the unauthorized service installation, especially if they have administrative privileges, to prevent further unauthorized access.
+- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected that cannot be easily remediated.
+- Implement network monitoring and alerting for similar suspicious activities, such as unexpected service installations or network logons, to enhance detection and response capabilities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
index d6bf620d013..f14e56eea50 100644
--- a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
+++ b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,6 +68,40 @@ any where host.os.type == "windows" and
     "?:\\Windows\\System32\\hvsirdpclient.exe"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious RDP ActiveX Client Loaded
+
+The Remote Desktop Services ActiveX Client, mstscax.dll, facilitates remote desktop connections, enabling users to access and control other systems. Adversaries may exploit this by loading the DLL in unauthorized contexts to move laterally within a network. The detection rule identifies unusual loading of mstscax.dll outside typical system paths, flagging potential misuse indicative of lateral movement attempts.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if mstscax.dll was loaded from an unusual or unauthorized location, as specified in the query.
+- Check the associated process and user context to identify who initiated the process and whether it aligns with expected behavior or known user activity.
+- Investigate the network connections associated with the process to identify any suspicious remote connections or lateral movement attempts.
+- Examine recent login events and RDP session logs for the involved user account to detect any unauthorized access or anomalies.
+- Correlate the alert with other security events or logs to identify potential patterns or related suspicious activities within the network.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts that load mstscax.dll from non-standard paths may trigger false positives. To mitigate this, identify and document these tools, then add their paths to the exclusion list in the detection rule.
+- Software updates or installations that temporarily load mstscax.dll from unusual locations can cause false alerts. Monitor and log these activities, and consider excluding these paths if they are consistently flagged during known update periods.
+- Virtualization software or sandbox environments that use mstscax.dll for legitimate purposes might be flagged. Verify the use of such software and exclude their executable paths from the rule to prevent unnecessary alerts.
+- Custom user scripts or automation tasks that involve remote desktop functionalities may load mstscax.dll in unexpected ways. Review these scripts and, if deemed safe, add their execution paths to the exclusion list to reduce noise.
+- Network drive mappings or shared folders that involve remote desktop components could lead to false positives. Ensure these are part of regular operations and exclude their paths if they are frequently flagged without malicious intent.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further lateral movement by the adversary.
+- Terminate any suspicious processes associated with the unauthorized loading of mstscax.dll to halt potential malicious activities.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software.
+- Review and analyze the system and network logs to identify any other systems that may have been accessed or compromised by the adversary.
+- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
+- Implement network segmentation to limit the ability of adversaries to move laterally within the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
index 1694f8e9ad5..ebd46787a54 100644
--- a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
+++ b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,40 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
    file.path : ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*",
                 "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Lateral Movement via Startup Folder
+
+The Windows Startup folder is a mechanism that allows programs to run automatically upon user logon or system reboot. Adversaries exploit this by placing malicious files in the Startup folder of remote systems, often accessed via RDP or SMB, to ensure persistence and facilitate lateral movement. The detection rule identifies suspicious file activities in these folders, focusing on processes like mstsc.exe, which may indicate unauthorized access and file creation, signaling potential lateral movement attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file creation or change event in the specified Startup folder paths, focusing on the file path patterns: "?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*" and "?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*".
+- Check the process information associated with the event, particularly if the process name is "mstsc.exe" or if the process ID is 4, to determine if the activity is linked to remote access via RDP or SMB.
+- Investigate the origin of the remote connection by examining network logs or RDP session logs to identify the source IP address and user account involved in the connection.
+- Analyze the newly created or modified file in the Startup folder for malicious characteristics, such as unusual file names, unexpected file types, or known malware signatures, using antivirus or sandbox analysis tools.
+- Review user account activity and permissions to determine if the account associated with the process has been compromised or is being misused for unauthorized access.
+- Correlate this event with other security alerts or logs from data sources like Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or patterns indicating lateral movement attempts.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create files in the Startup folder, triggering the rule. Users can manage this by maintaining a list of known software that typically modifies the Startup folder and creating exceptions for these processes.
+- System administrators using remote desktop tools like mstsc.exe for legitimate purposes might inadvertently trigger the rule. To handle this, users can exclude specific administrator accounts or known IP addresses from the detection rule.
+- Automated scripts or system management tools that deploy updates or configurations across multiple systems might cause false positives. Users should identify these tools and add them to an exclusion list to prevent unnecessary alerts.
+- Some enterprise applications may use the Startup folder for legitimate operations, especially during system boot or user logon. Users should document these applications and configure the rule to ignore file changes associated with them.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement and potential spread of the threat.
+- Terminate any suspicious processes, particularly those related to mstsc.exe or any unauthorized processes with PID 4, to halt any ongoing malicious activities.
+- Remove any unauthorized files or scripts found in the Startup folder paths specified in the detection query to prevent them from executing on reboot or user logon.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants.
+- Review and reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
+- 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 enhanced monitoring and logging for RDP and SMB activities, focusing on unusual file creation events in Startup folders, to improve detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/lateral_movement_via_wsus_update.toml b/rules/windows/lateral_movement_via_wsus_update.toml
index bd697c08064..6211207ab35 100644
--- a/rules/windows/lateral_movement_via_wsus_update.toml
+++ b/rules/windows/lateral_movement_via_wsus_update.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,40 @@ process.executable : (
 ) and
 (process.name : "psexec64.exe" or ?process.pe.original_file_name : "psexec.c")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential WSUS Abuse for Lateral Movement
+
+Windows Server Update Services (WSUS) is a system that manages updates for Microsoft products, ensuring that only signed binaries are executed. Adversaries may exploit WSUS to run Microsoft-signed tools like PsExec for lateral movement within a network. The detection rule identifies suspicious processes initiated by WSUS, specifically targeting PsExec executions, to flag potential abuse attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the suspicious process execution, specifically checking for the parent process name "wuauclt.exe" and the child process name "psexec64.exe" or original file name "psexec.c".
+- Examine the process execution path to verify if it matches the specified directories: "?:\\Windows\\SoftwareDistribution\\Download\\Install\\*" or "\\Device\\HarddiskVolume?\\Windows\\SoftwareDistribution\\Download\\Install\\*".
+- Investigate the source and destination hosts involved in the alert to determine if there are any unauthorized or unexpected connections, focusing on potential lateral movement activities.
+- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or patterns that may indicate a broader attack.
+- Correlate the alert with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context and confirm the legitimacy of the activity.
+- Assess the user accounts involved in the process execution to ensure they are legitimate and have not been compromised, paying attention to any anomalies in user behavior or access patterns.
+
+### False positive analysis
+
+- Legitimate administrative tasks using PsExec may trigger the rule. To manage this, create exceptions for known administrative accounts or specific times when these tasks are scheduled.
+- Automated scripts or software deployment tools that use PsExec for legitimate purposes can cause false positives. Identify these tools and exclude their process hashes or specific execution paths from the rule.
+- Security software or monitoring tools that utilize PsExec for scanning or remediation might be flagged. Verify these tools and whitelist their activities by excluding their specific process names or parent processes.
+- Test environments where PsExec is used for development or testing purposes can generate alerts. Exclude these environments by specifying their IP ranges or hostnames in the rule exceptions.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or use network segmentation to contain the threat.
+- Terminate any suspicious processes identified as PsExec executions initiated by WSUS, specifically those matching the query criteria, to stop any ongoing malicious activity.
+- Conduct a thorough review of the affected system's update logs and WSUS configuration to identify any unauthorized changes or updates that may have been exploited.
+- Remove any unauthorized or malicious binaries found in the specified directories (e.g., Windows\\SoftwareDistribution\\Download\\Install) to prevent further execution.
+- Reset credentials for any accounts that may have been compromised or used in the lateral movement attempt, especially those with administrative privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected.
+- Implement enhanced monitoring and logging for WSUS activities and PsExec executions to detect and respond to similar threats more effectively in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ad_adminsdholder.toml b/rules/windows/persistence_ad_adminsdholder.toml
index 943a4663f0c..7b0d9b0837b 100644
--- a/rules/windows/persistence_ad_adminsdholder.toml
+++ b/rules/windows/persistence_ad_adminsdholder.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/31"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,41 @@ query = '''
 event.action:("Directory Service Changes" or "directory-service-object-modified") and event.code:5136 and
   winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AdminSDHolder Backdoor
+
+The AdminSDHolder object in Active Directory is crucial for maintaining consistent permissions across privileged accounts. It ensures that any changes to these accounts are reverted to match the AdminSDHolder's settings. Adversaries exploit this by modifying the AdminSDHolder to create persistent backdoors, regaining administrative privileges. The detection rule identifies such abuses by monitoring specific directory service changes, focusing on modifications to the AdminSDHolder object, thus alerting security teams to potential threats.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.code:5136 to identify specific changes made to the AdminSDHolder object.
+- Examine the winlog.event_data.ObjectDN field to confirm the object path is CN=AdminSDHolder,CN=System* and verify the nature of the modifications.
+- Identify the user account responsible for the changes by checking the event logs for the associated user information.
+- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior.
+- Assess the current permissions on the AdminSDHolder object and compare them with the expected baseline to identify unauthorized changes.
+- Check for any recent changes in group memberships or permissions of privileged accounts that could indicate exploitation of the AdminSDHolder backdoor.
+- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment.
+
+### False positive analysis
+
+- Routine administrative changes to the AdminSDHolder object can trigger alerts. To manage this, establish a baseline of expected changes and create exceptions for these known activities.
+- Scheduled maintenance or updates to Active Directory may result in temporary modifications to the AdminSDHolder object. Document these events and exclude them from triggering alerts during the maintenance window.
+- Automated scripts or tools used for Active Directory management might modify the AdminSDHolder object as part of their normal operation. Identify these tools and whitelist their activities to prevent false positives.
+- Changes made by trusted security personnel or systems should be logged and reviewed. Implement a process to verify and exclude these changes from alerting if they are part of approved security operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Revert any unauthorized changes to the AdminSDHolder object by restoring it from a known good backup or manually resetting its permissions to the default secure state.
+- Conduct a thorough review of all privileged accounts and groups to ensure their permissions align with organizational security policies and have not been altered to match the compromised AdminSDHolder settings.
+- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access.
+- Implement additional monitoring on the AdminSDHolder object and other critical Active Directory objects to detect any future unauthorized modifications promptly.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts.
+- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_app_compat_shim.toml b/rules/windows/persistence_app_compat_shim.toml
index 888afb2ac42..2a89370136a 100644
--- a/rules/windows/persistence_app_compat_shim.toml
+++ b/rules/windows/persistence_app_compat_shim.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,41 @@ registry where host.os.type == "windows" and event.type == "change" and
                          "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", 
                          "?:\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Installation of Custom Shim Databases
+
+Application Compatibility Shim databases are used in Windows to ensure older applications run smoothly on newer OS versions by applying compatibility fixes. However, attackers can exploit this feature to maintain persistence and execute arbitrary code by installing malicious shim databases. The detection rule identifies changes in specific registry paths associated with these databases, excluding known legitimate processes, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the registry path changes identified in the alert to confirm the presence of any unexpected or unauthorized .sdb files in the specified registry paths.
+- Investigate the process that made the registry change by examining the process executable path and comparing it against the list of known legitimate processes excluded in the query.
+- Check the historical activity of the process responsible for the change to identify any patterns or anomalies that might indicate malicious behavior.
+- Analyze the context around the time of the registry change, including other system events or alerts, to identify any related suspicious activities.
+- If a suspicious .sdb file is found, conduct a file analysis to determine its purpose and whether it contains any malicious code or configurations.
+- Consult threat intelligence sources to see if there are any known threats or campaigns associated with the identified process or .sdb file.
+
+### False positive analysis
+
+- Known legitimate processes such as SAP and Kaspersky applications may trigger false positives due to their use of shim databases. These processes are already excluded in the detection rule to minimize unnecessary alerts.
+- If additional legitimate applications are identified as causing false positives, users can update the exclusion list by adding the specific process executable paths to the rule.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate applications that may use shim databases.
+- Monitor the frequency and context of alerts to distinguish between benign and potentially malicious activities, adjusting the rule as necessary to reduce noise.
+- Engage with application owners to verify the legitimacy of processes that frequently trigger alerts, ensuring that only trusted applications are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further propagation or communication with potential command and control servers.
+- Terminate any suspicious processes identified as responsible for the installation of the custom shim database, ensuring they are not legitimate processes mistakenly flagged.
+- Remove the malicious shim database entries from the registry paths specified in the detection query to eliminate persistence mechanisms.
+- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any additional malware or unauthorized changes.
+- Review and restore any altered system configurations or files to their original state to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for the specified registry paths and associated processes to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_appcertdlls_registry.toml b/rules/windows/persistence_appcertdlls_registry.toml
index 8ced36769d3..c2edf2ea416 100644
--- a/rules/windows/persistence_appcertdlls_registry.toml
+++ b/rules/windows/persistence_appcertdlls_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,41 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Registry Persistence via AppCert DLL
+
+AppCert DLLs are dynamic link libraries that can be configured to load with every process that uses common API functions to create processes on Windows systems. This feature is intended for legitimate use, such as application compatibility. However, adversaries can exploit this by inserting malicious DLLs into the registry path, ensuring their code executes persistently across system reboots. The detection rule identifies changes to specific registry paths associated with AppCert DLLs, flagging potential unauthorized modifications indicative of persistence or privilege escalation attempts. By monitoring these registry changes, security analysts can detect and respond to such threats effectively.
+
+### Possible investigation steps
+
+- Review the specific registry path changes identified in the alert to confirm if they match the paths specified in the query: "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\*", "\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\*", or "MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\*".
+- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other system activities or logs around the same time.
+- Identify the user account or process responsible for the registry modification by examining the event logs or security logs to determine if it was an authorized change or potentially malicious activity.
+- Investigate the DLL file specified in the registry change for any known malicious signatures or behaviors using threat intelligence sources or antivirus tools.
+- Analyze the system for any additional indicators of compromise or persistence mechanisms, such as unusual scheduled tasks, startup items, or other registry modifications.
+- Review historical data to determine if similar registry changes have occurred in the past, which might indicate a recurring threat or persistent adversary activity.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the AppCert DLL registry paths as part of their setup process. Users can handle these by creating exceptions for known and trusted software vendors.
+- System administrators might intentionally configure AppCert DLLs for application compatibility purposes. To manage this, maintain a list of approved configurations and exclude these from alerts.
+- Security tools or endpoint protection software might interact with these registry paths during routine scans or updates. Identify and whitelist these tools to prevent unnecessary alerts.
+- Custom enterprise applications may use AppCert DLLs for legitimate process monitoring or enhancement. Collaborate with application developers to document these cases and exclude them from detection.
+- Regular system maintenance scripts or group policies might inadvertently trigger changes in these registry paths. Review and adjust these scripts or policies to minimize false positives, or document and exclude them if they are necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious AppCert DLLs identified in the registry paths.
+- Remove the unauthorized AppCert DLL entries from the registry paths: HKLM\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\* to eliminate persistence mechanisms.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants.
+- Review and restore any system files or configurations that may have been altered by the malicious DLLs to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for the specific registry paths and related process creation activities to detect any future unauthorized changes promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_browser_extension_install.toml b/rules/windows/persistence_browser_extension_install.toml
index 7bcc2ade5b5..83ca4bb9d9e 100644
--- a/rules/windows/persistence_browser_extension_install.toml
+++ b/rules/windows/persistence_browser_extension_install.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,40 @@ file where host.os.type == "windows" and event.type : "creation" and
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Browser Extension Install
+Browser extensions enhance functionality in web browsers but can be exploited by adversaries to gain persistence or execute malicious activities. Attackers may disguise harmful extensions as legitimate or use compromised systems to install them. The detection rule identifies suspicious extension installations by monitoring file creation events in typical extension directories, filtering out known safe processes, and focusing on Windows environments.
+
+### Possible investigation steps
+
+- Review the file creation event details to identify the specific browser extension file (e.g., .xpi or .crx) and its path to determine if it aligns with known malicious patterns or locations.
+- Check the process that initiated the file creation event, especially if it is not a known safe process like firefox.exe, to assess if it is a legitimate application or potentially malicious.
+- Investigate the user account associated with the file creation event to determine if the activity is expected or if the account may have been compromised.
+- Examine recent system activity and logs for any signs of social engineering attempts or unauthorized access that could have led to the installation of the extension.
+- Cross-reference the extension file name and path with threat intelligence sources to identify if it is associated with known malicious browser extensions.
+- If applicable, review the browser's extension management interface to verify the presence and legitimacy of the installed extension.
+
+### False positive analysis
+
+- Language pack installations for Firefox can trigger false positives. Exclude files named "langpack-*@firefox.mozilla.org.xpi" from detection to prevent unnecessary alerts.
+- Dictionary add-ons for Firefox may also be flagged. Add exceptions for files named "*@dictionaries.addons.mozilla.org.xpi" to reduce false positives.
+- Regular updates or installations of legitimate browser extensions from trusted sources can be mistaken for malicious activity. Maintain a list of trusted processes and paths to exclude from monitoring.
+- User-initiated installations from official browser stores might be flagged. Educate users on safe installation practices and consider excluding known safe processes like "firefox.exe" when associated with legitimate extension paths.
+- Frequent installations in enterprise environments due to software deployment tools can cause alerts. Coordinate with IT to identify and exclude these routine activities from detection.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes associated with the unauthorized browser extension installation, such as unknown or unexpected instances of browser processes.
+- Remove the malicious browser extension by deleting the associated files from the extension directories identified in the alert.
+- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats or remnants of the malicious extension.
+- Review and reset browser settings to default to ensure no residual configurations or settings are left by the malicious extension.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement application whitelisting to prevent unauthorized browser extensions from being installed in the future, focusing on the directories and file types identified in the detection query."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_evasion_registry_ifeo_injection.toml b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
index 783c763a025..0f6684125d5 100644
--- a/rules/windows/persistence_evasion_registry_ifeo_injection.toml
+++ b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,40 @@ registry where host.os.type == "windows" and event.type == "change" and
     /* add FPs here */
   not registry.data.strings regex~ ("""C:\\Program Files( \(x86\))?\\ThinKiosk\\thinkiosk\.exe""", """.*\\PSAppDeployToolkit\\.*""")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Image File Execution Options Injection
+
+Image File Execution Options (IFEO) is a Windows feature allowing developers to debug applications by specifying an alternative executable to run. Adversaries exploit this by setting a debugger to execute malicious code instead, achieving persistence or evasion. The detection rule identifies changes to specific registry keys associated with IFEO, flagging potential misuse by monitoring for unexpected executables being set as debuggers.
+
+### Possible investigation steps
+
+- Review the registry path and value that triggered the alert to identify the specific executable or process being targeted for debugging or monitoring.
+- Check the registry.data.strings field to determine the unexpected executable set as a debugger or monitor process, and assess its legitimacy.
+- Investigate the origin and purpose of the executable found in the registry.data.strings by checking its file properties, digital signature, and any associated metadata.
+- Correlate the alert with recent system or user activity to identify any suspicious behavior or changes that coincide with the registry modification.
+- Examine the system for additional indicators of compromise, such as unusual network connections, file modifications, or other registry changes, to assess the scope of potential malicious activity.
+- Consult threat intelligence sources to determine if the identified executable or behavior is associated with known malware or threat actors.
+
+### False positive analysis
+
+- ThinKiosk and PSAppDeployToolkit are known to trigger false positives due to their legitimate use of the Debugger registry key. Users can mitigate this by adding exceptions for these applications in the detection rule.
+- Regularly review and update the list of exceptions to include any new legitimate applications that may use the Debugger or MonitorProcess registry keys for valid purposes.
+- Monitor the environment for any new software installations or updates that might interact with the IFEO registry keys and adjust the rule exceptions accordingly to prevent unnecessary alerts.
+- Collaborate with IT and security teams to identify any internal tools or scripts that might be using these registry keys for legitimate reasons and ensure they are accounted for in the rule exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes identified as being executed through the IFEO mechanism to halt any ongoing malicious activity.
+- Revert any unauthorized changes to the registry keys associated with Image File Execution Options and SilentProcessExit to their default or intended state.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Review and restore any altered or deleted system files from a known good backup to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for registry changes related to IFEO to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_group_modification_by_system.toml b/rules/windows/persistence_group_modification_by_system.toml
index a652ef77e0b..c07d73ac3ef 100644
--- a/rules/windows/persistence_group_modification_by_system.toml
+++ b/rules/windows/persistence_group_modification_by_system.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,41 @@ winlog.event_data.SubjectUserSid : "S-1-5-18" and
 /* DOMAIN_USERS and local groups */
 not group.id : "S-1-5-21-*-513"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Active Directory Group Modification by SYSTEM
+
+Active Directory (AD) is a critical component in Windows environments, managing user and group permissions. SYSTEM, a high-privilege account, can modify AD groups, which attackers exploit to gain unauthorized access. By monitoring specific event logs for SYSTEM-initiated group changes, the detection rule identifies potential privilege escalation, signaling an attacker may have compromised a domain controller.
+
+### Possible investigation steps
+
+- Review the event log entry with event code 4728 to confirm the SYSTEM account (S-1-5-18) initiated the group modification.
+- Identify the specific Active Directory group that was modified and determine if it is a sensitive or high-privilege group.
+- Check for any recent changes or anomalies in the domain controller's security logs that might indicate SYSTEM privilege escalation.
+- Investigate the timeline of events leading up to the group modification to identify any suspicious activities or patterns.
+- Correlate this event with other security alerts or logs to assess if there is a broader attack pattern or campaign.
+- Verify if there are any known vulnerabilities or misconfigurations in the domain controller that could have been exploited to gain SYSTEM privileges.
+
+### False positive analysis
+
+- Routine administrative tasks performed by automated scripts or scheduled tasks may trigger this rule. Review and document these tasks, then create exceptions for known benign scripts to prevent unnecessary alerts.
+- System maintenance activities, such as software updates or system reconfigurations, might involve legitimate group modifications by SYSTEM. Coordinate with IT teams to identify and whitelist these activities.
+- Certain security tools or monitoring solutions may perform group modifications as part of their normal operation. Verify these tools' actions and exclude them from triggering alerts if they are confirmed to be safe.
+- In environments with custom applications that require SYSTEM-level access for group management, ensure these applications are documented and their actions are excluded from detection to avoid false positives.
+- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently allow malicious activities to go undetected.
+
+### Response and remediation
+
+- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Revoke any unauthorized group memberships added by the SYSTEM account to prevent privilege escalation and unauthorized access.
+- Conduct a thorough review of recent changes in Active Directory, focusing on group modifications and user account activities, to identify any other potential unauthorized changes.
+- Reset passwords for all accounts that were added to groups by the SYSTEM account to mitigate the risk of compromised credentials being used.
+- Apply security patches and updates to the domain controller to address any vulnerabilities that may have been exploited to gain SYSTEM privileges.
+- Monitor for any further suspicious activities or attempts to modify Active Directory groups, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_local_scheduled_job_creation.toml b/rules/windows/persistence_local_scheduled_job_creation.toml
index e771f3d2d8e..bb95a64c5dc 100644
--- a/rules/windows/persistence_local_scheduled_job_creation.toml
+++ b/rules/windows/persistence_local_scheduled_job_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,40 @@ file where host.os.type == "windows" and event.type != "deletion" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via Scheduled Job Creation
+
+Scheduled jobs in Windows environments allow tasks to be automated by executing scripts or programs at specified times. Adversaries exploit this feature to maintain persistence by scheduling malicious code execution. The detection rule identifies suspicious job creation by monitoring specific file paths and extensions, excluding known legitimate processes, to flag potential abuse while minimizing false positives.
+
+### Possible investigation steps
+
+- Review the file path and extension to confirm the presence of a scheduled job in the "?:\\Windows\\Tasks\\" directory with a ".job" extension, which is indicative of a scheduled task.
+- Examine the process executable path to determine if the job creation is associated with any known legitimate processes, such as CCleaner or ManageEngine, which are excluded in the detection rule.
+- Investigate the origin of the process that created the scheduled job by checking the process execution history and command line arguments to identify any potentially malicious behavior.
+- Analyze the scheduled job's content and associated scripts or programs to identify any suspicious or unauthorized code that may indicate malicious intent.
+- Correlate the event with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activity.
+- Assess the risk and impact of the scheduled job by determining if it aligns with known adversary tactics, techniques, and procedures (TTPs) related to persistence, as outlined in the MITRE ATT&CK framework.
+
+### False positive analysis
+
+- Scheduled jobs created by CCleaner for crash reporting can trigger false positives. Exclude the path "?:\\Windows\\Tasks\\CCleanerCrashReporting.job" when the process executable is "?:\\Program Files\\CCleaner\\CCleaner64.exe".
+- ManageEngine UEMS Agent and DesktopCentral Agent may create scheduled jobs for updates, leading to false positives. Exclude the path "?:\\Windows\\Tasks\\DCAgentUpdater.job" when the process executable is "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\dcagentregister.exe" or "?:\\Program Files (x86)\\DesktopCentral_Agent\\bin\\dcagentregister.exe".
+- Regularly review and update exclusion lists to ensure they reflect the current environment and legitimate software behavior.
+- Consider implementing a whitelist of known legitimate processes and paths to further reduce false positives while maintaining effective threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scheduled jobs and limit lateral movement.
+- Terminate any suspicious processes associated with the identified scheduled job, using tools like Task Manager or PowerShell, to halt any ongoing malicious activity.
+- Delete the suspicious scheduled job file from the system to prevent future execution. This can be done using the Task Scheduler or command-line tools.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) solutions to identify and remove any additional malicious files or remnants.
+- Review and audit other scheduled tasks on the system to ensure no additional unauthorized or suspicious jobs are present.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Implement enhanced monitoring and alerting for scheduled job creation activities across the network to detect similar threats in the future, leveraging the specific query fields used in the detection rule."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_local_scheduled_task_creation.toml b/rules/windows/persistence_local_scheduled_task_creation.toml
index b16d94cda6a..d467331d35e 100644
--- a/rules/windows/persistence_local_scheduled_task_creation.toml
+++ b/rules/windows/persistence_local_scheduled_task_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,41 @@ sequence with maxspan=1m
     not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System")
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Local Scheduled Task Creation
+
+Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, or privilege escalation. They may use command-line tools like `schtasks.exe` to create tasks under non-system accounts. The detection rule identifies suspicious task creation by monitoring specific processes and command-line arguments, excluding those initiated by system-level users, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process entity ID to identify the parent process that initiated the scheduled task creation. This can provide context on whether the task was created by a legitimate application or a potentially malicious one.
+- Examine the command-line arguments used with schtasks.exe, specifically looking for unusual or suspicious parameters that might indicate malicious intent, such as unexpected task names or execution paths.
+- Check the user account associated with the task creation to determine if it is a non-system account and assess whether this account should have the capability to create scheduled tasks.
+- Investigate the integrity level of the process to confirm it is not running with elevated privileges, which could indicate an attempt to bypass security controls.
+- Correlate the event with other recent activities on the host, such as file modifications or network connections, to identify any patterns or additional indicators of compromise.
+- Review the code signature of the initiating process to determine if it is trusted or untrusted, which can help assess the legitimacy of the process creating the task.
+
+### False positive analysis
+
+- Scheduled tasks created by legitimate administrative tools or scripts may trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts.
+- Routine maintenance tasks initiated by IT departments, such as software updates or system checks, can be mistaken for suspicious activity. Exclude these tasks by specifying their unique process names or command-line arguments.
+- Tasks created by trusted third-party applications for legitimate purposes might be flagged. Review and exclude these applications by verifying their code signatures and adding them to an exception list.
+- Automated tasks set up by non-system accounts for regular operations, like backups or monitoring, can be misinterpreted. Document these tasks and exclude them based on their specific parameters or user accounts involved.
+- Consider excluding tasks with a consistent and verified schedule that aligns with organizational policies, as these are less likely to be malicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious scheduled tasks identified by the alert using Task Scheduler or command-line tools like schtasks.exe to stop further execution.
+- Review and remove any unauthorized scheduled tasks created by non-system accounts to eliminate persistence mechanisms.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious artifacts.
+- Analyze the user account involved in the task creation for signs of compromise, and reset credentials if necessary to prevent further unauthorized access.
+- 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 enhanced monitoring and logging for scheduled task creation events to detect similar threats in the future, ensuring alerts are configured to notify the appropriate teams promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ms_office_addins_file.toml b/rules/windows/persistence_ms_office_addins_file.toml
index 040eb7fed6e..5dbd00e8eef 100644
--- a/rules/windows/persistence_ms_office_addins_file.toml
+++ b/rules/windows/persistence_ms_office_addins_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/16"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,41 @@ file where host.os.type == "windows" and event.type != "deletion" and
     "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*"
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via Microsoft Office AddIns
+
+Microsoft Office AddIns enhance productivity by allowing custom functionalities in Office applications. However, adversaries exploit this by placing malicious add-ins in specific startup directories, ensuring execution each time the application launches. The detection rule identifies suspicious files with extensions like .xll or .xlam in these directories, flagging potential persistence mechanisms on Windows systems.
+
+### Possible investigation steps
+
+- Review the file path and extension from the alert to confirm it matches the suspicious directories and extensions specified in the detection rule, such as .xll or .xlam in the Microsoft Office startup directories.
+- Check the file creation and modification timestamps to determine when the suspicious file was added or altered, which can help establish a timeline of potential malicious activity.
+- Investigate the file's origin by examining recent file downloads, email attachments, or network activity that might have introduced the file to the system.
+- Analyze the file's contents or hash against known malware databases to identify if it is a known threat or potentially malicious.
+- Review user activity and system logs around the time the file was created or modified to identify any unusual behavior or processes that could be related to the persistence mechanism.
+- Assess the impacted user's role and access level to determine the potential risk and impact of the persistence mechanism on the organization.
+
+### False positive analysis
+
+- Legitimate add-ins installed by trusted software vendors may trigger alerts. Verify the source and publisher of the add-in to determine its legitimacy.
+- Custom add-ins developed internally for business purposes can be flagged. Maintain a whitelist of known internal add-ins to prevent unnecessary alerts.
+- Frequent updates to legitimate add-ins might cause repeated alerts. Implement version control and update the whitelist accordingly to accommodate these changes.
+- User-specific add-ins for accessibility or productivity tools may be detected. Educate users on safe add-in practices and monitor for any unusual behavior.
+- Temporary add-ins used for specific projects or tasks can be mistaken for threats. Document and review these cases to ensure they are recognized as non-threatening.
+
+### Response and remediation
+
+- Isolate the affected endpoint from the network to prevent further spread of the potential threat.
+- Terminate any suspicious Microsoft Office processes that may be running add-ins from the identified directories.
+- Remove the malicious add-in files from the specified startup directories: "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\", "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\", and "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\".
+- Conduct a full antivirus and antimalware scan on the affected system using tools like Microsoft Defender for Endpoint to ensure no other malicious files are present.
+- Review and restore any altered system configurations or settings to their default state to ensure system integrity.
+- Monitor the affected system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_ms_outlook_vba_template.toml b/rules/windows/persistence_ms_outlook_vba_template.toml
index 3cec5159564..ff72c20da93 100644
--- a/rules/windows/persistence_ms_outlook_vba_template.toml
+++ b/rules/windows/persistence_ms_outlook_vba_template.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,42 @@ query = '''
 file where host.os.type == "windows" and event.type != "deletion" and
  file.path : "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via Microsoft Outlook VBA
+
+Microsoft Outlook supports VBA scripting to automate tasks, which can be exploited by adversaries to maintain persistence. Attackers may install malicious VBA templates in the Outlook environment, triggering scripts upon application startup. The detection rule identifies suspicious activity by monitoring for unauthorized modifications to the VBAProject.OTM file, a common target for such persistence techniques, leveraging various data sources to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path matches the pattern "C:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Outlook\\\\VbaProject.OTM" and ensure the event type is not "deletion".
+- Check the modification timestamp of the VbaProject.OTM file to determine when the unauthorized change occurred.
+- Identify the user account associated with the file path to understand which user profile was potentially compromised.
+- Investigate recent login activities and processes executed by the identified user to detect any anomalies or unauthorized access.
+- Examine the contents of the VbaProject.OTM file for any suspicious or unfamiliar VBA scripts that could indicate malicious intent.
+- Correlate the findings with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context or related events.
+- Assess the risk and impact of the detected activity and determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Routine updates or legitimate changes to the Outlook environment can trigger alerts. Users should verify if recent software updates or administrative changes align with the detected activity.
+- Custom scripts or macros developed by IT departments for legitimate automation tasks may be flagged. Establish a whitelist of known and approved VBA scripts to prevent unnecessary alerts.
+- User-initiated actions such as importing or exporting Outlook settings might modify the VbaProject.OTM file. Educate users on the implications of these actions and consider excluding these specific user actions from triggering alerts.
+- Security software or backup solutions that interact with Outlook files could cause false positives. Identify and exclude these processes if they are known to be safe and necessary for operations.
+- Regularly review and update the exclusion list to ensure it reflects current organizational needs and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Isolate the affected endpoint from the network to prevent further spread of the malicious VBA script and to contain the threat.
+- Terminate any suspicious Outlook processes on the affected machine to stop the execution of potentially harmful scripts.
+- Remove the unauthorized or malicious VbaProject.OTM file from the affected user's Outlook directory to eliminate the persistence mechanism.
+- Restore the VbaProject.OTM file from a known good backup if available, ensuring that it is free from any unauthorized modifications.
+- Conduct a full antivirus and antimalware scan on the affected endpoint using tools like Microsoft Defender for Endpoint to identify and remove any additional threats.
+- Review and update endpoint security policies to restrict unauthorized modifications to Outlook VBA files, leveraging application whitelisting or similar controls.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
index 446ca449b00..017be43d3b3 100644
--- a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
+++ b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,40 @@ query = '''
 iam where event.action == "modified-user-account" and event.code == "4738" and
   winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 KRBTGT Delegation Backdoor
+
+In Active Directory, the KRBTGT account is crucial for Kerberos ticket granting. Adversaries may exploit this by altering the msDS-AllowedToDelegateTo attribute, enabling unauthorized ticket requests and persistent domain access. The detection rule identifies such modifications by monitoring specific event actions and codes, flagging high-risk changes to the KRBTGT delegation settings.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code 4738 to identify the user account that was modified and verify if the msDS-AllowedToDelegateTo attribute includes the KRBTGT service.
+- Investigate the user account that performed the modification by checking their recent activities and login history to determine if the action was authorized or suspicious.
+- Examine the timeline of the modification event to correlate it with any other unusual activities or alerts in the network around the same time.
+- Check for any other modifications to sensitive attributes or accounts in Active Directory that might indicate a broader compromise.
+- Assess the potential impact on the domain by evaluating the access level and permissions of the modified account and any associated systems or services.
+- Consult with the IT security team to determine if there are any known maintenance activities or changes that could explain the modification, ensuring it was not a legitimate administrative action.
+
+### False positive analysis
+
+- Routine administrative tasks involving legitimate changes to the msDS-AllowedToDelegateTo attribute for service accounts may trigger alerts. Review the context of the change and verify with the IT team if it aligns with scheduled maintenance or updates.
+- Automated scripts or tools used for Active Directory management might modify delegation settings as part of their operations. Identify these scripts and exclude their activity from triggering alerts by creating exceptions based on the script's signature or the account used.
+- Changes made by trusted third-party applications that require delegation for functionality can be mistaken for malicious activity. Document these applications and adjust the detection rule to exclude their known and expected behavior.
+- Regular audits or compliance checks that involve modifications to delegation settings should be accounted for. Coordinate with audit teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or ticket requests using the KRBTGT account.
+- Revert any unauthorized changes to the msDS-AllowedToDelegateTo attribute for the KRBTGT account by restoring it to its previous state using a known good backup or manually resetting the attribute.
+- Reset the KRBTGT account password twice to invalidate any existing Kerberos tickets that may have been issued using the compromised delegation settings.
+- Conduct a thorough review of recent changes to user accounts and delegation settings in Active Directory to identify any other potential unauthorized modifications.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.
+- Implement enhanced monitoring for changes to critical accounts and attributes in Active Directory, focusing on the KRBTGT account and similar high-value targets.
+- Review and update access controls and delegation permissions to ensure that only authorized personnel have the ability to modify sensitive attributes like msDS-AllowedToDelegateTo."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msi_installer_task_startup.toml b/rules/windows/persistence_msi_installer_task_startup.toml
index 6c41a97a039..aad57db99ec 100644
--- a/rules/windows/persistence_msi_installer_task_startup.toml
+++ b/rules/windows/persistence_msi_installer_task_startup.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/05"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,42 @@ any where host.os.type == "windows" and
                     "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*"))
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via a Windows Installer
+
+Windows Installer, through msiexec.exe, facilitates software installation and configuration. Adversaries exploit this by creating persistence mechanisms, such as scheduled tasks or startup entries, to maintain access. The detection rule identifies suspicious activity by monitoring msiexec.exe for file creation in startup directories or registry modifications linked to auto-run keys, signaling potential persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path or registry path involved in the suspicious activity, focusing on the paths specified in the query such as "?:\\\\Windows\\\\System32\\\\Tasks\\\\*" or "H*\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\*".
+- Check the creation or modification timestamps of the files or registry entries to determine when the suspicious activity occurred and correlate it with other events or logs around the same time.
+- Investigate the parent process of msiexec.exe to understand how it was executed and whether it was initiated by a legitimate user action or another suspicious process.
+- Examine the contents of the created or modified files or registry entries to identify any scripts, executables, or commands that may indicate malicious intent.
+- Look for any associated network activity or connections initiated by msiexec.exe or related processes to identify potential command and control communication.
+- Cross-reference the involved file or registry paths with known indicators of compromise or threat intelligence sources to assess the risk level and potential threat actor involvement.
+- If applicable, isolate the affected system and perform a deeper forensic analysis to uncover any additional persistence mechanisms or lateral movement within the network.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule when msiexec.exe creates scheduled tasks or startup entries. Users can create exceptions for known software vendors or specific installation paths to reduce noise.
+- System administrators might use msiexec.exe for deploying software across the network, which can appear as suspicious activity. To handle this, exclude specific administrative accounts or IP ranges from the rule.
+- Some enterprise management tools may utilize msiexec.exe for legitimate configuration changes, including registry modifications. Identify and exclude these tools by their process names or associated registry paths.
+- Automated scripts or deployment tools that rely on msiexec.exe for software management can generate false positives. Consider excluding these scripts or tools by their execution context or associated file paths.
+- Regularly review and update the exclusion list to ensure it aligns with the current software deployment and management practices within the organization.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate the msiexec.exe process if it is confirmed to be involved in creating unauthorized persistence mechanisms.
+- Remove any scheduled tasks or startup entries created by msiexec.exe that are identified as malicious or unauthorized.
+- Restore any modified registry keys to their original state if they were altered to establish persistence.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
+- Review and update security policies to restrict the use of msiexec.exe for non-administrative users, reducing the risk of exploitation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_msoffice_startup_registry.toml b/rules/windows/persistence_msoffice_startup_registry.toml
index 4565aedddf2..ad031b63897 100644
--- a/rules/windows/persistence_msoffice_startup_registry.toml
+++ b/rules/windows/persistence_msoffice_startup_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -42,6 +42,40 @@ query = '''
 registry where host.os.type == "windows" and event.action != "deletion" and
     registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Office Test Registry Persistence
+
+The Office Test Registry key in Windows environments allows specifying a DLL to execute whenever an Office application starts, providing a mechanism for legitimate customization. However, adversaries can exploit this for persistence by loading malicious DLLs. The detection rule monitors modifications to this registry path, excluding deletions, to identify potential abuse, leveraging data from various security sources to flag suspicious activity.
+
+### Possible investigation steps
+
+- Review the registry event details to identify the specific DLL path that was added or modified in the Office Test Registry key.
+- Check the file properties and digital signature of the DLL specified in the registry modification to determine its legitimacy.
+- Investigate the source of the registry modification by correlating with user activity logs to identify which user account made the change.
+- Analyze recent process execution logs for any Office applications to detect if the suspicious DLL has been loaded or executed.
+- Cross-reference the DLL and associated registry modification with threat intelligence sources to check for known malicious indicators.
+- Examine the system for additional signs of compromise, such as unusual network connections or other persistence mechanisms, to assess the scope of potential intrusion.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the Office Test Registry key as part of their setup process. Users can create exceptions for known software vendors or specific applications that are frequently updated.
+- System administrators might use scripts or management tools that modify the registry for configuration purposes. Identify and exclude these trusted scripts or tools from triggering alerts.
+- Customization by IT departments for legitimate business needs can lead to registry modifications. Document and whitelist these customizations to prevent false positives.
+- Security software or monitoring tools might interact with the registry as part of their normal operations. Verify and exclude these interactions if they are known to be safe and necessary for system functionality.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further spread or communication with potential command and control servers.
+- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious DLL identified in the registry path.
+- Remove the malicious DLL entry from the Office Test Registry key to prevent it from executing on future Office application startups.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants.
+- Review recent user activity and system logs to identify any unauthorized access or changes that may have led to the registry modification, and reset credentials if necessary.
+- 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 enhanced monitoring and alerting for similar registry modifications across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_netsh_helper_dll.toml b/rules/windows/persistence_netsh_helper_dll.toml
index b024cd12e5b..96831535eb0 100644
--- a/rules/windows/persistence_netsh_helper_dll.toml
+++ b/rules/windows/persistence_netsh_helper_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,39 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\Software\\Microsoft\\netsh\\*"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Netsh Helper DLL
+
+Netsh, a command-line utility in Windows, allows for network configuration and diagnostics. It supports extensibility through Helper DLLs, which can be added to enhance its capabilities. However, attackers can exploit this by adding malicious DLLs, ensuring their code runs whenever netsh is executed. The detection rule monitors registry changes related to netsh DLLs, flagging unauthorized modifications that may indicate persistence tactics.
+
+### Possible investigation steps
+
+- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs under "HKLM\\Software\\Microsoft\\netsh\\".
+- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with any other suspicious activities or events on the system.
+- Investigate the origin of the DLL file by examining its properties, such as the file path, creation date, and digital signature, to assess its legitimacy.
+- Analyze recent user activity and scheduled tasks to identify any potential execution of netsh.exe that could have triggered the malicious DLL.
+- Cross-reference the alert with other security logs and alerts from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and identify any related threats or indicators of compromise.
+
+### False positive analysis
+
+- Legitimate software installations or updates may add or modify Netsh Helper DLLs, triggering the detection rule. Users should verify if recent installations or updates coincide with the registry changes.
+- Network management tools or scripts used by IT departments might legitimately extend netsh functionality. Identify and document these tools to create exceptions in the detection rule.
+- Scheduled tasks or administrative scripts that configure network settings could cause expected changes. Review scheduled tasks and scripts to ensure they are authorized and adjust the rule to exclude these known activities.
+- Security software or network monitoring solutions may interact with netsh for legitimate purposes. Confirm with the software vendor if their product modifies netsh settings and consider excluding these changes from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of the malicious DLL and potential lateral movement.
+- Terminate any suspicious processes associated with netsh.exe to halt the execution of the malicious payload.
+- Remove the unauthorized Netsh Helper DLL entry from the registry path identified in the alert to eliminate the persistence mechanism.
+- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any additional malicious files or artifacts.
+- Review and restore any altered system configurations to their original state to ensure system integrity.
+- 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 enhanced monitoring and logging for registry changes related to Netsh Helper DLLs to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
index 35c401eed9e..f1773f5fd72 100644
--- a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
+++ b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/10/31"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,41 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name: ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and process.args : "Set-CASMailbox*ActiveSyncAllowedDeviceIDs*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 New ActiveSyncAllowedDeviceID Added via PowerShell
+
+ActiveSync is a protocol enabling mobile devices to synchronize with Exchange mailboxes, crucial for accessing emails on-the-go. Adversaries may exploit the Exchange PowerShell cmdlet, Set-CASMailbox, to add unauthorized devices, gaining persistent access to sensitive email data. The detection rule identifies suspicious PowerShell activity by monitoring for specific command patterns, helping to flag potential unauthorized device additions and mitigate risks associated with account manipulation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (e.g., powershell.exe, pwsh.exe, powershell_ise.exe) and the command line arguments used, focusing on the presence of "Set-CASMailbox" and "ActiveSyncAllowedDeviceIDs".
+- Examine the user account associated with the process execution to determine if the account has a history of legitimate administrative actions or if it might be compromised.
+- Check the device ID added to the ActiveSyncAllowedDeviceIDs list to verify if it is recognized and authorized for use within the organization.
+- Investigate the source IP address and host from which the PowerShell command was executed to assess if it aligns with expected administrative activity or if it originates from an unusual or suspicious location.
+- Review recent email access logs for the user account to identify any unusual patterns or access from unfamiliar devices that could indicate unauthorized access.
+- Correlate this event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns.
+
+### False positive analysis
+
+- Legitimate administrative tasks may trigger the rule when IT staff use PowerShell to configure or update ActiveSync settings for users. To manage this, create exceptions for known administrative accounts or specific maintenance windows.
+- Automated scripts for device management that include the Set-CASMailbox cmdlet can cause false positives. Review and whitelist these scripts if they are verified as part of routine operations.
+- Third-party applications that integrate with Exchange and modify ActiveSync settings might be flagged. Identify and exclude these applications if they are trusted and necessary for business operations.
+- Regular audits of device additions by authorized personnel can help distinguish between legitimate and suspicious activities, allowing for more accurate exception handling.
+- Consider the context of the activity, such as the time of day and the user account involved, to refine detection rules and reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access to the mailbox.
+- Revoke the ActiveSync device access by removing the unauthorized device ID from the user's mailbox settings using the Exchange PowerShell cmdlet.
+- Conduct a thorough review of the affected user's mailbox and account activity logs to identify any unauthorized access or data exfiltration attempts.
+- Reset the password for the compromised user account and enforce multi-factor authentication (MFA) to enhance security.
+- Notify the security team and relevant stakeholders about the incident for further investigation and potential escalation.
+- Implement additional monitoring on the affected account and similar accounts for any unusual activity or further attempts to add unauthorized devices.
+- Review and update the organization's security policies and procedures related to mobile device access and PowerShell usage to prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_registry_uncommon.toml b/rules/windows/persistence_registry_uncommon.toml
index dba7ca9b4e9..e92d89a51d0 100644
--- a/rules/windows/persistence_registry_uncommon.toml
+++ b/rules/windows/persistence_registry_uncommon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -115,6 +115,41 @@ registry where host.os.type == "windows" and event.type == "change" and
       )
      )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Uncommon Registry Persistence Change
+
+Windows Registry is a critical system database storing configuration settings. Adversaries exploit registry keys for persistence, ensuring malicious code executes on startup or during specific events. The detection rule identifies unusual modifications to less commonly altered registry keys, which may indicate stealthy persistence attempts. It filters out benign changes by excluding known legitimate processes and paths, focusing on suspicious alterations.
+
+### Possible investigation steps
+
+- Review the specific registry path and value that triggered the alert to understand the context of the change and its potential impact on system behavior.
+- Identify the process responsible for the registry modification by examining the process.name and process.executable fields, and determine if it is a known legitimate process or potentially malicious.
+- Check the registry.data.strings field to see the new data or command being set in the registry key, and assess whether it aligns with known legitimate software or suspicious activity.
+- Investigate the user account associated with the registry change by reviewing the HKEY_USERS path, if applicable, to determine if the change was made by an authorized user or an unexpected account.
+- Correlate the alert with other recent events on the host, such as file modifications or network connections, to identify any additional indicators of compromise or related suspicious activity.
+- Consult threat intelligence sources or databases to see if the registry path or process involved is associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify registry keys for setup or configuration purposes. Users can create exceptions for known software paths like C:\\Program Files\\*.exe to reduce noise.
+- System maintenance processes such as Windows Update might trigger changes in registry keys like SetupExecute. Exclude processes like TiWorker.exe and poqexec.exe when they match known update patterns.
+- Administrative scripts or tools that automate system configurations can alter registry keys. Identify and exclude these scripts by their executable paths or process names to prevent false alerts.
+- Security software, including antivirus or endpoint protection, may interact with registry keys for monitoring purposes. Exclude paths related to these tools, such as C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe, to avoid false positives.
+- User-initiated changes through control panel settings or personalization options can affect registry keys like SCRNSAVE.EXE. Exclude common system paths like %windir%\\system32\\rundll32.exe user32.dll,LockWorkStation to minimize false detections.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate any suspicious processes identified in the alert, particularly those not matching known legitimate executables or paths.
+- Restore any altered registry keys to their original state using a known good backup or by manually resetting them to default values.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes.
+- Review and update endpoint protection policies to ensure that similar registry changes are monitored and alerted on in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Document the incident, including all actions taken, to improve future response efforts and update threat intelligence databases."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_remote_password_reset.toml b/rules/windows/persistence_remote_password_reset.toml
index c0698e0647d..5ff1c295a2e 100644
--- a/rules/windows/persistence_remote_password_reset.toml
+++ b/rules/windows/persistence_remote_password_reset.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -18,7 +18,41 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Account Password Reset Remotely"
-note = """
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Account Password Reset Remotely
+
+Remote password resets are crucial for managing user accounts, especially for privileged users. However, adversaries exploit this by resetting passwords to maintain unauthorized access or bypass security policies. The detection rule identifies suspicious remote password resets by monitoring successful network logins and subsequent password reset actions, focusing on privileged accounts to minimize noise and highlight potential threats.
+
+### Possible investigation steps
+
+- Review the source IP address from the authentication event to determine if it is from a known or trusted network. Investigate any unfamiliar or suspicious IP addresses.
+- Check the winlog.event_data.TargetUserName from the password reset event to confirm if it belongs to a privileged account and verify if the reset was authorized.
+- Correlate the winlog.event_data.SubjectLogonId from both the authentication and password reset events to ensure they are linked and identify the user or process responsible for the actions.
+- Investigate the timing and frequency of similar events to identify patterns or anomalies that may indicate malicious activity.
+- Examine any recent changes or activities associated with the account in question to assess if there are other signs of compromise or unauthorized access.
+
+### False positive analysis
+
+- Routine administrative tasks can trigger false positives when legitimate IT staff reset passwords for maintenance or support. To manage this, create exceptions for known IT personnel or service accounts that frequently perform these actions.
+- Automated scripts or tools used for account management might cause false alerts. Identify and exclude these scripts or tools by their specific account names or IP addresses.
+- Scheduled password resets for compliance or security policies may appear suspicious. Document and exclude these scheduled tasks by their timing and associated accounts.
+- Service accounts with naming conventions similar to privileged accounts might be flagged. Review and adjust the rule to exclude these specific service accounts by refining the naming patterns in the query.
+- Internal network devices or systems that perform regular password resets could be misinterpreted as threats. Whitelist these devices by their IP addresses or hostnames to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Revoke any active sessions associated with the compromised account to disrupt any ongoing malicious activities.
+- Reset the password of the affected account using a secure method, ensuring it is done from a trusted and secure system.
+- Conduct a thorough review of recent account activities and system logs to identify any additional unauthorized changes or access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities.
+- Review and update access controls and privileged account management policies to prevent similar incidents in the future.
+
 ## Performance
 This rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity.
 """
diff --git a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
index ddc19d2048d..8293ddb3d9d 100644
--- a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
+++ b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,41 @@ sequence by host.id, user.name with maxspan=1m
     process.args : ("C:\\Users\\*", "C:\\ProgramData\\*", "C:\\Windows\\Temp\\*", "C:\\Windows\\Tasks\\*", "C:\\PerfLogs\\*", "C:\\Intel\\*")
    ]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution of Persistent Suspicious Program
+
+Persistent programs, like scripts or rundll32, are often used by adversaries to maintain access to a system. These programs can be executed at startup, leveraging process lineage and command line arguments to evade detection. The detection rule identifies suspicious executions by monitoring the sequence of processes initiated after user logon, focusing on known malicious executables and unusual file paths, thus highlighting potential abuse of persistence mechanisms.
+
+### Possible investigation steps
+
+- Review the process lineage to confirm the sequence of userinit.exe, explorer.exe, and the suspicious child process. Verify if the child process was indeed launched shortly after user logon.
+- Examine the command line arguments of the suspicious process to identify any unusual or malicious patterns, especially those involving known suspicious paths like C:\\Users\\*, C:\\ProgramData\\*, or C:\\Windows\\Temp\\*.
+- Check the original file name of the suspicious process against known malicious executables such as cscript.exe, wscript.exe, or PowerShell.EXE to determine if it matches any of these.
+- Investigate the parent process explorer.exe to ensure it was not compromised or manipulated to launch the suspicious child process.
+- Analyze the user account associated with the suspicious process to determine if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited.
+- Review recent system changes or installations that might have introduced the suspicious executable or altered startup configurations.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools may trigger alerts if they are executed from common directories like C:\\Users or C:\\ProgramData. To manage this, create exceptions for known administrative scripts that are regularly used in your environment.
+- Software updates or installations might use processes like PowerShell or RUNDLL32, leading to false positives. Identify and exclude these processes when they are part of a verified update or installation routine.
+- Custom scripts or automation tasks that run at startup could be flagged. Document these tasks and exclude them from the rule if they are part of normal operations.
+- Security or monitoring tools that use similar execution patterns may be mistakenly identified. Verify these tools and add them to an exclusion list to prevent unnecessary alerts.
+- User-initiated actions that mimic suspicious behavior, such as running scripts from the command line, can cause false positives. Educate users on safe practices and adjust the rule to exclude known benign user actions.
+
+### Response and remediation
+
+- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes identified in the alert, such as those executed by cscript.exe, wscript.exe, PowerShell.EXE, MSHTA.EXE, RUNDLL32.EXE, REGSVR32.EXE, RegAsm.exe, MSBuild.exe, or InstallUtil.exe.
+- Remove any unauthorized or suspicious startup entries or scheduled tasks that may have been created to ensure persistence.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants.
+- Review and restore any modified system configurations or registry settings to their default or secure state.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for the affected host and similar systems to detect any recurrence or related suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_scheduled_task_creation_winlog.toml b/rules/windows/persistence_scheduled_task_creation_winlog.toml
index 6fa9f59b94f..77b3f381b52 100644
--- a/rules/windows/persistence_scheduled_task_creation_winlog.toml
+++ b/rules/windows/persistence_scheduled_task_creation_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,39 @@ iam where event.action == "scheduled-task-created" and
               "\\OneDrive Standalone Update Task-S-1-12-1-*"
  )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 A scheduled task was created
+
+Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this feature to maintain persistence, move laterally, or escalate privileges by creating malicious tasks. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. This approach helps security analysts pinpoint unauthorized task creation indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the user account associated with the task creation to determine if it is a known and authorized user, ensuring it is not a system account by checking that the username does not end with a dollar sign.
+- Examine the task name and path in the event data to identify if it matches any known benign tasks or if it appears suspicious or unfamiliar.
+- Investigate the origin of the task creation by checking the source IP address or hostname, if available, to determine if it aligns with expected network activity.
+- Check the task's scheduled actions and triggers to understand what the task is designed to execute and when, looking for any potentially harmful or unexpected actions.
+- Correlate the task creation event with other security events or logs around the same time to identify any related suspicious activities or anomalies.
+
+### False positive analysis
+
+- Scheduled tasks created by system accounts or computer accounts are often benign. These can be excluded by filtering out user names ending with a dollar sign, which typically represent system accounts.
+- Tasks associated with common software updates or maintenance, such as those from Hewlett-Packard or Microsoft Visual Studio, are generally non-threatening. These can be excluded by specifying their full task names in the exclusion list.
+- OneDrive update tasks are frequently triggered and are usually safe. Exclude these by using patterns that match their task names, such as those starting with "OneDrive Standalone Update Task".
+- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the rule remains effective without generating unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious scheduled tasks identified by the alert to halt any ongoing malicious activity.
+- Conduct a thorough review of the system's scheduled tasks to identify and remove any other unauthorized or suspicious tasks.
+- Restore the system from a known good backup if any malicious activity has been confirmed and has potentially compromised system integrity.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Monitor the system and network for any signs of re-infection or further unauthorized scheduled task creation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_scheduled_task_updated.toml b/rules/windows/persistence_scheduled_task_updated.toml
index 6983c1da7a1..0a6deb606a9 100644
--- a/rules/windows/persistence_scheduled_task_updated.toml
+++ b/rules/windows/persistence_scheduled_task_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,39 @@ iam where event.action == "scheduled-task-updated" and
            "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload") and 
   not winlog.event_data.SubjectUserSid :  ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 A scheduled task was updated
+
+Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this by modifying tasks to maintain persistence, often altering legitimate tasks to evade detection. The detection rule identifies suspicious updates by filtering out benign changes, such as those by system accounts or known safe tasks, focusing on anomalies that suggest malicious intent.
+
+### Possible investigation steps
+
+- Review the event logs to identify the specific scheduled task that was updated, focusing on the winlog.event_data.TaskName field to determine if it matches any known malicious patterns.
+- Investigate the user account associated with the update by examining the user.name field to ensure it is not a compromised account or an unauthorized user.
+- Check the winlog.event_data.SubjectUserSid field to verify if the update was made by a system account or a potentially malicious user, as system accounts like S-1-5-18, S-1-5-19, and S-1-5-20 are typically benign.
+- Analyze the history of changes to the scheduled task to identify any unusual or unauthorized modifications that could indicate persistence mechanisms.
+- Correlate the scheduled task update with other security events or alerts to determine if it is part of a broader attack pattern or campaign.
+
+### False positive analysis
+
+- Scheduled tasks updated by system accounts can be false positives. Exclude updates made by system accounts by filtering out user names ending with a dollar sign.
+- Legitimate Microsoft tasks often update automatically. Exclude tasks with names containing "Microsoft" to reduce noise from these updates.
+- Commonly updated tasks like User Feed Synchronization and OneDrive Reporting are typically benign. Exclude these specific task names to avoid unnecessary alerts.
+- Tasks updated by well-known service SIDs such as S-1-5-18, S-1-5-19, and S-1-5-20 are generally safe. Exclude these SIDs to prevent false positives from routine system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Review the specific scheduled task that was updated to determine if it was altered by an unauthorized user or process. Revert any unauthorized changes to their original state.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced.
+- Analyze the user account that made the changes to the scheduled task. If the account is compromised, reset the password and review recent activities for further signs of compromise.
+- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized scheduled task updates or related suspicious activities.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Review and update access controls and permissions related to scheduled tasks to ensure only authorized personnel can make changes, reducing the risk of future unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_service_dll_unsigned.toml b/rules/windows/persistence_service_dll_unsigned.toml
index 63ce6c7c0e4..7b336a0b0f0 100644
--- a/rules/windows/persistence_service_dll_unsigned.toml
+++ b/rules/windows/persistence_service_dll_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -126,6 +126,42 @@ library where host.os.type == "windows" and
              "23aa95b637a1bf6188b386c21c4e87967ede80242327c55447a5bb70d9439244", 
              "5050b025909e81ae5481db37beb807a80c52fc6dd30c8aa47c9f7841e2a31be7")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unsigned DLL Loaded by Svchost
+
+Svchost.exe is a critical Windows process that hosts multiple services, allowing efficient resource management. Adversaries exploit this by loading unsigned DLLs to gain persistence or execute code with elevated privileges. The detection rule identifies such threats by monitoring DLLs recently created and loaded by svchost, focusing on untrusted signatures and unusual file paths, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the specific DLL file path and hash (dll.path and dll.hash.sha256) to determine if it is known to be associated with legitimate software or if it is potentially malicious.
+- Check the creation time of the DLL (dll.Ext.relative_file_creation_time) to understand the timeline of events and correlate it with other activities on the system around the same time.
+- Investigate the process that loaded the DLL (process.executable) to determine if it is a legitimate instance of svchost.exe or if it has been tampered with or replaced.
+- Analyze the code signature status (dll.code_signature.trusted and dll.code_signature.status) to verify if the DLL is unsigned or has an untrusted signature, which could indicate tampering or a malicious origin.
+- Cross-reference the DLL's hash (dll.hash.sha256) against known malware databases or threat intelligence sources to identify if it is associated with known threats.
+- Examine the system for other indicators of compromise, such as unusual network activity or additional suspicious files, to assess the scope of potential malicious activity.
+- Consider isolating the affected system to prevent further potential compromise while conducting a deeper forensic analysis.
+
+### False positive analysis
+
+- System maintenance or updates may trigger the rule by loading legitimate unsigned DLLs. Users can create exceptions for known update processes or maintenance activities to prevent unnecessary alerts.
+- Custom or in-house applications might load unsigned DLLs from unusual paths. Verify the legitimacy of these applications and consider adding their specific paths to the exclusion list if they are deemed safe.
+- Security or monitoring tools might use unsigned DLLs for legitimate purposes. Identify these tools and exclude their associated DLLs by hash or path to reduce false positives.
+- Temporary files created by legitimate software in monitored directories can be mistaken for threats. Regularly review and update the exclusion list to include hashes of these known benign files.
+- Development environments often generate unsigned DLLs during testing phases. Ensure that development paths are excluded from monitoring to avoid false alerts during software development cycles.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the svchost.exe process that loaded the unsigned DLL to stop any ongoing malicious actions.
+- Remove the identified unsigned DLL from the system to eliminate the immediate threat.
+- Conduct a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats.
+- Review and restore any modified system configurations or settings to their original state to ensure system integrity.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for svchost.exe and DLL loading activities to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_services_registry.toml b/rules/windows/persistence_services_registry.toml
index 7225410023f..a9bb55f50e2 100644
--- a/rules/windows/persistence_services_registry.toml
+++ b/rules/windows/persistence_services_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -65,6 +65,41 @@ registry where host.os.type == "windows" and event.type == "change" and
       "?:\\Windows\\System32\\WaaSMedicAgent.exe"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Persistence via Services Registry
+
+Windows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the specific registry paths and values that triggered the alert, focusing on "ServiceDLL" and "ImagePath" within the specified registry paths to identify any unauthorized or suspicious modifications.
+- Examine the process responsible for the registry change, paying attention to the process name and executable path, to determine if it is a known legitimate process or potentially malicious.
+- Cross-reference the process executable path against the list of known legitimate paths excluded in the query to ensure it is not a false positive.
+- Investigate the historical behavior of the process and any associated files or network activity to identify patterns indicative of malicious intent or persistence mechanisms.
+- Check for any recent changes or anomalies in the system's service configurations that could correlate with the registry modifications, indicating potential unauthorized service creation or alteration.
+- Consult threat intelligence sources or databases to determine if the process or registry changes are associated with known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify service registry keys directly. Users can create exceptions for known software update processes by excluding their executables from the detection rule.
+- System maintenance tools like Process Explorer may trigger false positives when they interact with service registry keys. Exclude these tools by adding their process names and paths to the exception list.
+- Drivers installed by trusted hardware peripherals might alter service registry keys. Users should identify and exclude these driver paths if they are known to be safe and frequently updated.
+- Custom enterprise applications that require direct registry modifications for service management can be excluded by specifying their executable paths in the rule exceptions.
+- Regular system processes such as svchost.exe or services.exe are already excluded, but ensure any custom scripts or automation tools that mimic these processes are also accounted for in the exceptions.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are not part of legitimate applications or services.
+- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the service configurations.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts.
+- Review and update endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
index a593685c0f5..ff3c3de7369 100644
--- a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
+++ b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,41 @@ process where host.os.type == "windows" and event.type == "start" and
      not (process.name : "powershell.exe" and process.args : ("-File", "-PSConsoleFile") and user.id : "S-1-5-18") and
      not (process.name : "msiexec.exe" and user.id : "S-1-5-18")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Execution via Scheduled Task
+
+Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence and execution of malicious programs. By examining process lineage and command line usage, the detection rule identifies suspicious executions initiated by scheduled tasks. It flags known malicious executables and unusual file paths, while excluding benign processes, to pinpoint potential threats effectively.
+
+### Possible investigation steps
+
+- Review the process lineage to confirm the parent process is "svchost.exe" with arguments containing "Schedule" to verify the execution was initiated by a scheduled task.
+- Examine the command line arguments and file paths of the suspicious process to identify any unusual or unauthorized file locations, such as those listed in the query (e.g., "C:\\Users\\*", "C:\\ProgramData\\*").
+- Check the original file name of the process against the list of known suspicious executables (e.g., "PowerShell.EXE", "Cmd.Exe") to determine if it matches any commonly abused binaries.
+- Investigate the user context under which the process was executed, especially if it deviates from expected system accounts or known service accounts.
+- Correlate the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack campaign.
+- Assess the risk and impact of the detected activity by considering the severity and risk score provided, and determine if immediate containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Scheduled tasks running legitimate scripts or executables like cmd.exe or cscript.exe in system directories may trigger false positives. To manage this, create exceptions for these processes when they are executed from known safe directories such as C:\\Windows\\System32.
+- PowerShell scripts executed by the system account (S-1-5-18) for administrative tasks can be mistakenly flagged. Exclude these by specifying exceptions for PowerShell executions with arguments like -File or -PSConsoleFile when run by the system account.
+- Legitimate software installations or updates using msiexec.exe by the system account may be incorrectly identified as threats. Mitigate this by excluding msiexec.exe processes initiated by the system account.
+- Regular maintenance tasks or scripts stored in common directories like C:\\ProgramData or C:\\Windows\\Temp might be flagged. Review these tasks and exclude known benign scripts or executables from these paths.
+- Custom scripts or administrative tools that mimic suspicious executables (e.g., PowerShell.EXE, RUNDLL32.EXE) but are part of routine operations should be reviewed and excluded if verified as safe.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity.
+- Terminate any suspicious processes identified by the detection rule, especially those matching the flagged executables and paths.
+- Conduct a thorough review of scheduled tasks on the affected system to identify and disable any unauthorized or suspicious tasks.
+- Remove any malicious files or executables found in the suspicious paths listed in the detection rule.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for scheduled tasks and the flagged executables to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_suspicious_service_created_registry.toml b/rules/windows/persistence_suspicious_service_created_registry.toml
index 491958437d6..7d579168ba3 100644
--- a/rules/windows/persistence_suspicious_service_created_registry.toml
+++ b/rules/windows/persistence_suspicious_service_created_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,41 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* add suspicious registry ImagePath values here */
   registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious ImagePath Service Creation
+
+Windows services are crucial for running background processes. Adversaries exploit this by creating or modifying services with malicious ImagePath values to gain persistence or escalate privileges. The detection rule monitors registry changes to ImagePath entries, flagging unusual patterns like command shells or named pipes, which are often used in stealthy attacks. This helps identify and mitigate potential threats early.
+
+### Possible investigation steps
+
+- Review the registry event logs to identify the specific ImagePath value that triggered the alert, focusing on entries with command shells or named pipes, such as those containing "%COMSPEC%*" or "*\\\\.\\\\pipe\\\\*".
+- Investigate the associated service name and description in the registry path "HKLM\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath" to determine if it is a legitimate service or potentially malicious.
+- Check the creation or modification timestamp of the suspicious ImagePath entry to correlate with other system events or user activities around the same time.
+- Analyze the parent process and user account responsible for the registry change to assess if it aligns with expected behavior or if it indicates unauthorized access.
+- Search for related network activity or connections, especially those involving named pipes, to identify any lateral movement or data exfiltration attempts.
+- Cross-reference the alert with threat intelligence sources to determine if the ImagePath value or associated service is linked to known malware or adversary techniques.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify ImagePath values, triggering alerts. Users can create exceptions for known software update processes to reduce noise.
+- System administrators might intentionally change service configurations for maintenance or optimization. Document and exclude these planned changes to prevent false positives.
+- Some enterprise applications use named pipes for inter-process communication, which could be flagged. Identify and whitelist these applications to avoid unnecessary alerts.
+- Security tools or scripts that automate service management might alter ImagePath values. Ensure these tools are recognized and excluded from monitoring to minimize false alerts.
+- Regularly review and update the list of exceptions to ensure they align with current organizational practices and software environments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with the identified ImagePath values, such as those involving command shells or named pipes.
+- Remove or disable the malicious service by reverting the ImagePath registry entry to its legitimate state or deleting the service if it is not required.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or malware.
+- Review and restore any modified system files or configurations to their original state to ensure system integrity.
+- 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 enhanced monitoring and logging for similar registry changes and suspicious service creations to detect and respond to future threats promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_sysmon_wmi_event_subscription.toml b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
index 3a2b3cca798..6610a755f23 100644
--- a/rules/windows/persistence_sysmon_wmi_event_subscription.toml
+++ b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/02/02"
 integration = ["windows", "endpoint"]
 maturity = "production"
-updated_date = "2024/12/23"
+updated_date = "2025/01/10"
 min_stack_version = "8.15.0"
 min_stack_comments = "Elastic Defend WMI events were added in Elastic Defend 8.15.0."
 
@@ -45,6 +45,40 @@ any where
     process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer"))
  )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious WMI Event Subscription Created
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this for persistence by creating event subscriptions that execute malicious scripts or commands. The detection rule identifies such abuse by monitoring specific event codes and API calls related to the creation of suspicious WMI event consumers, flagging potential threats.
+
+### Possible investigation steps
+
+- Review the event logs for event code 21 in the windows.sysmon_operational dataset to identify the specific WMI event subscription created, focusing on the winlog.event_data.Operation and winlog.event_data.Consumer fields.
+- Examine the process details associated with the IWbemServices::PutInstance API call in the endpoint.events.api dataset, particularly the process.Ext.api.parameters.consumer_type, to determine the nature of the consumer created.
+- Investigate the source and context of the command or script associated with the CommandLineEventConsumer or ActiveScriptEventConsumer to assess its legitimacy and potential malicious intent.
+- Check for any related processes or activities around the time of the event to identify potential lateral movement or further persistence mechanisms.
+- Correlate the findings with other security alerts or logs to determine if this event is part of a broader attack pattern or campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools may create WMI event subscriptions for system monitoring or automation. Review the source and context of the event to determine if it aligns with known administrative activities.
+- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes. Verify if the event coincides with recent software changes and consider excluding these specific events if they are routine.
+- Security software or management tools often use WMI for legitimate purposes. Identify and document these tools in your environment, and create exceptions for their known behaviors to reduce noise.
+- Scheduled tasks or system maintenance scripts may trigger similar events. Cross-reference with scheduled task logs or maintenance windows to confirm if these are expected activities.
+- Custom scripts developed in-house for system management might inadvertently match the detection criteria. Ensure these scripts are documented and consider excluding their specific signatures from the rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with the WMI event subscription, specifically those linked to CommandLineEventConsumer or ActiveScriptEventConsumer.
+- Remove the malicious WMI event subscription by using WMI management tools or scripts to delete the identified event consumer.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Review and reset any compromised credentials, especially if SYSTEM privileges were potentially accessed or escalated.
+- Monitor the network for any signs of similar activity or attempts to recreate the WMI event subscription, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_temp_scheduled_task.toml b/rules/windows/persistence_temp_scheduled_task.toml
index a23aede04b4..42eecac8317 100644
--- a/rules/windows/persistence_temp_scheduled_task.toml
+++ b/rules/windows/persistence_temp_scheduled_task.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,40 @@ sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m
    [iam where event.action == "scheduled-task-created" and not user.name : "*$"]
    [iam where event.action == "scheduled-task-deleted" and not user.name : "*$"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Temporarily Scheduled Task Creation
+
+Scheduled tasks in Windows environments automate routine tasks, but adversaries exploit them for persistence and execution by creating and quickly deleting tasks to mask malicious activity. The detection rule identifies such behavior by tracking task creation and deletion within a short timeframe, flagging potential misuse when these actions occur in rapid succession without typical user patterns.
+
+### Possible investigation steps
+
+- Review the winlog.computer_name field to identify the affected system and determine if it is a critical asset or part of a sensitive network segment.
+- Examine the winlog.event_data.TaskName to understand the nature of the task created and deleted, and assess if it aligns with known legitimate tasks or appears suspicious.
+- Investigate the user.name associated with the task creation and deletion events to determine if the activity was performed by a legitimate user or potentially compromised account.
+- Check for any related events or logs around the same timeframe on the affected system to identify any additional suspicious activities or anomalies.
+- Correlate the task creation and deletion events with other security alerts or incidents to determine if this activity is part of a broader attack campaign or isolated incident.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule if system administrators frequently create and delete scheduled tasks for maintenance purposes. To manage this, create exceptions for known administrative accounts or specific task names that are part of regular operations.
+- Automated scripts or software updates that temporarily create scheduled tasks can also cause false positives. Identify these scripts or update processes and exclude their associated user accounts or task names from the detection rule.
+- Some legitimate applications may use scheduled tasks for temporary operations. Review application documentation to confirm such behavior and exclude these applications by their task names or associated user accounts.
+- In environments with frequent testing or development activities, developers might create and delete tasks as part of their workflow. Consider excluding developer accounts or specific task names used in testing environments to reduce noise.
+- Scheduled tasks created by monitoring or security tools for short-lived operations can be mistaken for malicious activity. Verify these tools' behavior and exclude their task names or user accounts if they are known to be safe.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Review the scheduled task details, including the task name and associated scripts or executables, to identify any malicious payloads or commands.
+- Terminate any malicious processes or executables identified from the scheduled task analysis to stop ongoing threats.
+- Restore any altered or deleted system files from a known good backup to ensure system integrity.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
+- Implement additional monitoring and alerting for similar scheduled task activities to enhance detection and prevent recurrence of this threat."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_user_account_creation_event_logs.toml b/rules/windows/persistence_user_account_creation_event_logs.toml
index 316984f9db8..e9e4ea36162 100644
--- a/rules/windows/persistence_user_account_creation_event_logs.toml
+++ b/rules/windows/persistence_user_account_creation_event_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["system", "windows"]
 maturity = "development"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,41 @@ query = '''
 event.module:("system" or "security") and winlog.api:"wineventlog" and
   (event.code:"4720" or event.action:"added-user-account")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows User Account Creation
+
+Windows user accounts are essential for managing access and permissions within a system or domain. Adversaries may exploit this by creating unauthorized accounts to maintain persistence or escalate privileges. The detection rule leverages event logs, specifically targeting account creation events, to identify suspicious activities. By monitoring these logs, security analysts can detect and respond to potential threats effectively.
+
+### Possible investigation steps
+
+- Review the event logs for event.code "4720" or event.action "added-user-account" to identify the specific account creation event.
+- Determine the source of the account creation by examining the event.module field to see if it originated from the "system" or "security" module.
+- Identify the user account that initiated the account creation by checking the associated user information in the event logs.
+- Investigate the context around the time of the account creation event, such as other related events or anomalies, to assess if it aligns with normal administrative activities.
+- Check for any recent privilege escalation activities or changes in user permissions that might be associated with the newly created account.
+- Correlate the account creation event with other security alerts or logs to identify potential patterns of malicious behavior or persistence tactics.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger account creation events. Regularly review and document legitimate administrative activities to differentiate them from suspicious actions.
+- Automated scripts or software installations that create user accounts can generate false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Temporary accounts for contractors or short-term projects might be flagged. Implement a naming convention for such accounts and exclude them from alerts based on this pattern.
+- System updates or patches that involve account creation could be misinterpreted as threats. Monitor update schedules and correlate them with account creation events to verify legitimacy.
+- Accounts created by trusted third-party management tools should be recognized and excluded. Maintain an updated list of these tools and configure exceptions accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Review the newly created user account details, including the username, creation time, and associated privileges, to assess the potential impact and scope of the threat.
+- Disable or delete the unauthorized user account to eliminate the adversary's persistence mechanism.
+- Conduct a thorough review of recent account creation logs and correlate with other security events to identify any additional unauthorized accounts or related suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and alerting for account creation events, focusing on unusual patterns or deviations from normal behavior to improve early detection of similar threats.
+- Review and update access control policies and user account management procedures to prevent unauthorized account creation and ensure adherence to the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_application_shimming.toml b/rules/windows/persistence_via_application_shimming.toml
index bd2dc22911a..f8ee49d894a 100644
--- a/rules/windows/persistence_via_application_shimming.toml
+++ b/rules/windows/persistence_via_application_shimming.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,41 @@ process where host.os.type == "windows" and event.type == "start" and process.na
   not (process.args : "-m" and process.args : "-bg") and
   not process.args : "-mm"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Application Shimming via Sdbinst
+
+Application shimming is a Windows feature designed to ensure software compatibility across different OS versions. However, attackers exploit this by using the `sdbinst.exe` tool to execute malicious code under the guise of legitimate processes, achieving persistence. The detection rule identifies suspicious invocations of `sdbinst.exe` by filtering out benign arguments, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of sdbinst.exe with suspicious arguments that do not include the benign flags -m, -bg, or -mm.
+- Investigate the parent process of sdbinst.exe to determine if it is a legitimate and expected process or if it is potentially malicious.
+- Check the timeline of events around the execution of sdbinst.exe to identify any related or preceding suspicious activities, such as unusual file modifications or network connections.
+- Analyze the user account associated with the execution of sdbinst.exe to verify if it is a legitimate user and if there are any signs of account compromise.
+- Examine the system for any newly installed or modified application compatibility databases (.sdb files) that could be associated with the suspicious execution of sdbinst.exe.
+- Correlate the alert with other security tools and logs, such as Microsoft Defender for Endpoint or Sysmon, to gather additional context and confirm the presence of malicious activity.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger sdbinst.exe with arguments that are not typically malicious. Users should verify the source and purpose of the software to determine if it is expected behavior.
+- System administrators might use sdbinst.exe for deploying compatibility fixes across an organization. In such cases, document these activities and create exceptions for known administrative tasks.
+- Some enterprise applications may use sdbinst.exe as part of their normal operation. Identify these applications and exclude their specific command-line arguments from triggering alerts.
+- Scheduled tasks or scripts that include sdbinst.exe for maintenance purposes can be a source of false positives. Review these tasks and scripts, and whitelist them if they are part of routine operations.
+- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with `sdbinst.exe` that do not match known legitimate usage patterns.
+- Remove any unauthorized or suspicious application compatibility databases (.sdb files) that may have been installed using `sdbinst.exe`.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or persistence mechanisms.
+- Review and restore any altered system configurations or registry settings to their default or secure state.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for `sdbinst.exe` executions across the network to detect and respond to future attempts at application shimming."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_bits_job_notify_command.toml b/rules/windows/persistence_via_bits_job_notify_command.toml
index 42a345b965a..be0f8640ba2 100644
--- a/rules/windows/persistence_via_bits_job_notify_command.toml
+++ b/rules/windows/persistence_via_bits_job_notify_command.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,42 @@ process where host.os.type == "windows" and event.type == "start" and
                "?:\\Windows\\System32\\wermgr.exe",
                "?:\\WINDOWS\\system32\\directxdatabaseupdater.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via BITS Job Notify Cmdline
+
+Background Intelligent Transfer Service (BITS) is a Windows service that facilitates asynchronous, prioritized, and throttled transfer of files between machines. Adversaries exploit BITS by using the SetNotifyCmdLine method to execute malicious programs post-transfer, achieving persistence. The detection rule identifies suspicious processes initiated by BITS, excluding known legitimate executables, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the process details to confirm the parent process is "svchost.exe" with arguments containing "BITS" to ensure the alert is not a false positive.
+- Examine the process executable path to verify it is not one of the known legitimate executables listed in the exclusion criteria.
+- Investigate the command line arguments of the suspicious process to identify any potentially malicious or unusual commands being executed.
+- Check the file hash and signature of the suspicious executable to determine if it is known malware or a legitimate application.
+- Analyze the network activity associated with the process to identify any suspicious connections or data transfers that may indicate malicious behavior.
+- Review the system's event logs for any additional context or related events that could provide insight into the persistence mechanism or the adversary's actions.
+- Assess the affected system for any other signs of compromise or persistence mechanisms that may have been employed by the adversary.
+
+### False positive analysis
+
+- Legitimate system processes or updates may occasionally trigger the rule if they are not included in the exclusion list. Regularly review and update the exclusion list to include any new legitimate executables that are identified.
+- Some third-party software may use BITS for legitimate purposes, such as software updates or data synchronization. Identify these applications and consider adding their executables to the exclusion list to prevent false positives.
+- Scheduled tasks or scripts that utilize BITS for file transfers might be flagged. Verify the legitimacy of these tasks and, if deemed safe, exclude their associated executables from the detection rule.
+- In environments where custom scripts or administrative tools are used, ensure that these are documented and, if necessary, excluded from the rule to avoid unnecessary alerts.
+- Monitor the frequency and context of alerts to identify patterns that may indicate benign activity. Use this information to refine the rule and reduce false positives without compromising security.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as being initiated by BITS that are not part of the known legitimate executables list.
+- Conduct a thorough review of the BITS job configurations on the affected system to identify and remove any unauthorized or suspicious jobs.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Update and run a full antivirus and anti-malware scan on the affected system to ensure no additional threats are present.
+- Review and enhance endpoint protection policies to prevent unauthorized use of BITS for persistence, ensuring that only trusted applications can create or modify BITS jobs.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_hidden_run_key_valuename.toml b/rules/windows/persistence_via_hidden_run_key_valuename.toml
index 88ed115ee77..03993645c3b 100644
--- a/rules/windows/persistence_via_hidden_run_key_valuename.toml
+++ b/rules/windows/persistence_via_hidden_run_key_valuename.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -62,6 +62,41 @@ registry where host.os.type == "windows" and event.type == "change" and length(r
                   "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\",
                   "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via Hidden Run Key Detected
+
+The Windows Registry is a critical system database that stores configuration settings. Adversaries exploit it for persistence by creating hidden registry keys using native APIs, making them invisible to standard tools like regedit. The detection rule identifies changes in specific registry paths associated with startup programs, flagging null-terminated keys that suggest stealthy persistence tactics.
+
+### Possible investigation steps
+
+- Review the specific registry path where the change was detected to determine if it matches any of the paths listed in the query, such as "HKEY_USERS\\\\*\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\" or "HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\".
+- Check the timestamp of the registry change event to correlate it with other system activities or user actions that occurred around the same time.
+- Investigate the process that made the registry change by examining process creation logs or using tools like Sysmon to identify the responsible process and its parent process.
+- Analyze the content of the registry key value that was modified or created to determine if it points to a legitimate application or a potentially malicious executable.
+- Cross-reference the detected registry change with known threat intelligence sources to identify if the key or value is associated with known malware or adversary techniques.
+- Assess the affected system for additional indicators of compromise, such as unusual network connections, file modifications, or other persistence mechanisms.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create registry keys in the specified paths, leading to false positives. Users can monitor the installation process and temporarily disable the rule during known software updates to prevent unnecessary alerts.
+- System administrators may intentionally configure startup programs for maintenance or monitoring purposes. Document these configurations and create exceptions in the detection rule to avoid flagging them as threats.
+- Some security software may use similar techniques to ensure their components start with the system. Verify the legitimacy of such software and whitelist their registry changes to prevent false alarms.
+- Custom scripts or automation tools used within an organization might modify registry keys for operational reasons. Identify these scripts and exclude their activities from the detection rule to reduce false positives.
+- Regularly review and update the list of known safe applications and processes that interact with the registry paths in question, ensuring that the detection rule remains relevant and accurate.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Use a trusted tool to manually inspect and remove the hidden registry keys identified in the alert from the specified registry paths to eliminate the persistence mechanism.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes associated with the threat.
+- Review recent user activity and system logs to identify any unauthorized access or changes made by the adversary, and reset credentials for any compromised accounts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and process execution.
+- Update and reinforce endpoint security configurations to prevent similar persistence techniques, such as enabling registry auditing and restricting access to critical registry paths."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
index 7a3c8569eb7..6a14303762f 100644
--- a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
+++ b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,41 @@ registry where host.os.type == "windows" and event.type == "change" and
    ) and
    not process.executable : ("C:\\Windows\\System32\\msiexec.exe", "C:\\Windows\\SysWOW64\\msiexec.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Installation of Security Support Provider
+
+Security Support Providers (SSPs) in Windows environments facilitate authentication processes. Adversaries may exploit SSPs by modifying registry entries to maintain persistence or evade defenses. The detection rule identifies suspicious changes to specific registry paths associated with SSPs, excluding legitimate processes like msiexec.exe, to flag potential unauthorized modifications indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the registry change event details to identify the specific registry path that was modified, focusing on paths related to "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Security Packages" and "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages".
+- Investigate the process responsible for the registry modification by examining the process executable path, ensuring it is not a legitimate process like "C:\\Windows\\System32\\msiexec.exe" or "C:\\Windows\\SysWOW64\\msiexec.exe".
+- Check the historical activity of the identified process to determine if it has been involved in other suspicious activities or registry changes.
+- Analyze the user account context under which the process was executed to assess if it aligns with expected behavior or if it indicates potential compromise.
+- Correlate the event with other security alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and identify any related malicious activity.
+- Evaluate the potential impact of the registry change on system security and persistence mechanisms, considering the MITRE ATT&CK tactic of Persistence and technique T1547.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger registry changes in SSP paths. Users can create exceptions for known software installers or updaters that frequently modify these registry entries.
+- System administrators performing routine maintenance or configuration changes might inadvertently cause registry modifications. Document and exclude these activities when they are verified as non-threatening.
+- Security software updates, including those from Microsoft or third-party vendors, may alter SSP configurations as part of their normal operation. Monitor and whitelist these updates to prevent false alerts.
+- Automated deployment tools or scripts that modify system settings could lead to false positives. Ensure these tools are accounted for and excluded if they are part of regular operations.
+- Custom scripts or applications developed in-house that interact with SSP registry paths should be reviewed and excluded if they are deemed safe and necessary for business operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes that are not whitelisted, especially those modifying the registry paths associated with Security Support Providers.
+- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to remove unauthorized changes.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or artifacts.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify critical registry paths related to Security Support Providers.
+- Monitor the affected system and network for any signs of re-infection or further suspicious activity, focusing on registry changes and process executions.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
index 93aef1c28b4..20ed84dce90 100644
--- a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
+++ b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.type == "start" and
                       "rundll32.exe",
                       "powershell.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via TelemetryController Scheduled Task Hijack
+
+The Microsoft Compatibility Appraiser, part of Windows telemetry, uses scheduled tasks to assess system compatibility. Adversaries exploit this by hijacking the task to execute malicious code with system-level privileges, ensuring persistence. The detection rule identifies anomalies by monitoring processes initiated by the Appraiser that deviate from expected behavior, flagging potential hijacks for further investigation.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent process CompatTelRunner.exe and verify if it has spawned any unexpected child processes that match the alert criteria.
+- Examine the command-line arguments of the suspicious process to determine if they include the "-cv*" flag, which may indicate a hijack attempt.
+- Check the execution history of the flagged process to see if it aligns with legitimate system activities or if it appears anomalous.
+- Investigate the user account context under which the suspicious process is running to assess if it has elevated privileges or is associated with unusual user behavior.
+- Correlate the alert with other security logs and telemetry data from sources like Microsoft Defender for Endpoint or Sysmon to identify any related malicious activities or indicators of compromise.
+- Analyze any network connections initiated by the suspicious process to detect potential data exfiltration or communication with known malicious IP addresses.
+- Review recent changes to scheduled tasks on the system to identify unauthorized modifications that could indicate persistence mechanisms.
+
+### False positive analysis
+
+- Legitimate system maintenance tasks may trigger the rule if they involve processes that are not typically associated with the Microsoft Compatibility Appraiser. Users can create exceptions for known maintenance scripts or tools that are verified as safe.
+- Software updates or installations that temporarily use unusual processes under the Appraiser's context might be flagged. Users should monitor and whitelist these processes if they are part of a trusted update or installation routine.
+- Custom scripts or administrative tools that leverage the Appraiser's context for legitimate purposes could be misidentified. Users should document and exclude these scripts from detection if they are part of regular administrative operations.
+- Security tools or monitoring software that interact with the Appraiser process for analysis or logging purposes may cause false positives. Users should ensure these tools are recognized and excluded from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified by the detection rule that are not part of the expected process list, such as those not matching "conhost.exe", "DeviceCensus.exe", "CompatTelRunner.exe", "DismHost.exe", "rundll32.exe", or "powershell.exe".
+- Review and restore the integrity of the Microsoft Compatibility Appraiser scheduled task by resetting it to its default configuration to ensure it is not executing unauthorized code.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software.
+- Analyze the system for any unauthorized changes to user accounts or privileges, and revert any modifications to ensure that only legitimate users have access.
+- 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 enhanced monitoring and logging for the affected system and similar scheduled tasks across the network to detect any future attempts at hijacking or unauthorized modifications."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
index c174b2eed5e..9dec899f8fe 100644
--- a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
+++ b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,39 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : "create" and
   process.args : ("ActiveScriptEventConsumer", "CommandLineEventConsumer")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Persistence via WMI Event Subscription
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI by creating event subscriptions that trigger malicious code execution, ensuring persistence. The detection rule identifies suspicious use of `wmic.exe` to create event consumers, signaling potential abuse of WMI for persistence by monitoring specific process activities and arguments.
+
+### Possible investigation steps
+
+- Review the process execution details for `wmic.exe` to confirm the presence of suspicious arguments such as "create", "ActiveScriptEventConsumer", or "CommandLineEventConsumer" that indicate potential WMI event subscription abuse.
+- Examine the parent process of `wmic.exe` to determine how it was launched and assess whether this aligns with expected behavior or if it suggests malicious activity.
+- Investigate the user account associated with the `wmic.exe` process to determine if it has the necessary privileges to create WMI event subscriptions and whether the account activity is consistent with normal operations.
+- Check for any recent changes or additions to WMI event filters, consumers, or bindings on the affected system to identify unauthorized modifications that could indicate persistence mechanisms.
+- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and identify any related suspicious activities or patterns.
+
+### False positive analysis
+
+- Legitimate administrative tasks using wmic.exe may trigger the rule, such as system monitoring or configuration changes. To handle this, identify and document routine administrative scripts and exclude them from triggering alerts.
+- Software installations or updates that use WMI for legitimate event subscriptions can be mistaken for malicious activity. Maintain a list of trusted software and their expected behaviors to create exceptions in the detection rule.
+- Automated system management tools that rely on WMI for event handling might cause false positives. Review and whitelist these tools by verifying their source and purpose to prevent unnecessary alerts.
+- Security software or monitoring solutions that utilize WMI for legitimate purposes can be flagged. Collaborate with IT and security teams to identify these tools and adjust the rule to exclude their known benign activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes related to `wmic.exe` that are identified as creating event consumers, specifically those involving "ActiveScriptEventConsumer" or "CommandLineEventConsumer".
+- Remove any unauthorized WMI event subscriptions by using tools like `wevtutil` or PowerShell scripts to list and delete suspicious event filters, consumers, and bindings.
+- Conduct a thorough review of the system's WMI repository to ensure no other malicious or unauthorized configurations exist.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation.
+- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/persistence_werfault_reflectdebugger.toml b/rules/windows/persistence_werfault_reflectdebugger.toml
index b798b066051..ee355aab4c6 100644
--- a/rules/windows/persistence_werfault_reflectdebugger.toml
+++ b/rules/windows/persistence_werfault_reflectdebugger.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,40 @@ registry where host.os.type == "windows" and event.type == "change" and
     "MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Werfault ReflectDebugger Persistence
+
+Werfault, the Windows Error Reporting service, can be manipulated by attackers to maintain persistence. By registering a ReflectDebugger, adversaries can execute malicious code whenever Werfault is triggered with specific parameters. The detection rule monitors registry changes in key paths associated with ReflectDebugger, alerting on unauthorized modifications indicative of potential abuse.
+
+### Possible investigation steps
+
+- Review the registry change event details to identify the specific path modified, focusing on the paths listed in the query: "HKLM\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger", "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger", or "MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger".
+- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other suspicious activities or events on the system around the same time.
+- Investigate the user account or process responsible for the registry change to assess whether it is a legitimate action or potentially malicious. Look for unusual or unauthorized accounts making the change.
+- Examine the system for any recent executions of Werfault with the "-pr" parameter, as this could indicate attempts to trigger the malicious payload.
+- Search for any related alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Microsoft Defender for Endpoint, SentinelOne, or Sysmon that might provide additional context or corroborate the suspicious activity.
+- Assess the system for any signs of compromise or persistence mechanisms, such as unexpected startup items, scheduled tasks, or other registry modifications that could indicate a broader attack.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the ReflectDebugger registry key as part of their error reporting configuration. Users can create exceptions for known software vendors by verifying the digital signature of the executable associated with the change.
+- System administrators may intentionally configure the ReflectDebugger for debugging purposes. Document and whitelist these changes in the security monitoring system to prevent unnecessary alerts.
+- Automated system maintenance tools might interact with the ReflectDebugger registry key. Identify and exclude these tools by correlating the registry changes with scheduled maintenance activities.
+- Security software or endpoint protection solutions may alter the ReflectDebugger settings as part of their protective measures. Confirm these changes with the security vendor and add them to the exclusion list if deemed safe.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of malicious code via the Werfault ReflectDebugger.
+- Terminate any suspicious processes associated with Werfault that are running with the "-pr" parameter to halt potential malicious activity.
+- Remove unauthorized entries from the registry path "HKLM\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger" to eliminate persistence mechanisms.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malware or malicious artifacts.
+- Review and restore any system or application configurations that may have been altered by the attacker to their original state.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for registry changes in the specified paths to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_create_process_as_different_user.toml b/rules/windows/privilege_escalation_create_process_as_different_user.toml
index ffaaf3a68b9..9874bd76eec 100644
--- a/rules/windows/privilege_escalation_create_process_as_different_user.toml
+++ b/rules/windows/privilege_escalation_create_process_as_different_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,40 @@ sequence by winlog.computer_name with maxspan=1m
 
 [process where event.type == "start"] by winlog.event_data.TargetLogonId
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Creation via Secondary Logon
+
+The Secondary Logon service in Windows allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process creation, linking them through unique logon identifiers.
+
+### Possible investigation steps
+
+- Review the event logs for the specific TargetLogonId to identify the user account associated with the process creation and verify if the account is authorized to use alternate credentials.
+- Examine the source IP address "::1" to confirm if the process creation originated from the local machine, which might indicate a local privilege escalation attempt.
+- Investigate the process name "svchost.exe" to determine if it is being used legitimately or if it has been exploited for malicious purposes, such as running unauthorized services.
+- Check the sequence of events within the 1-minute maxspan to identify any unusual or suspicious activities that occurred immediately before or after the process creation.
+- Correlate the detected activity with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tasks using the Secondary Logon service can trigger alerts. To manage this, identify and whitelist specific administrative accounts or tasks that frequently use this service for legitimate purposes.
+- Scheduled tasks or automated scripts that use alternate credentials for routine operations may cause false positives. Review and exclude these tasks by creating exceptions for known scripts or scheduled jobs.
+- Internal IT support activities often involve using alternate credentials for troubleshooting or maintenance. Document and exclude these activities by maintaining a list of support personnel and their typical actions.
+- Software updates or installations that require elevated privileges might be flagged. Monitor and exclude these processes by identifying and documenting the update mechanisms used within the organization.
+- Development or testing environments where alternate credentials are used for testing purposes can generate alerts. Exclude these environments by setting up specific rules that recognize and ignore these non-production activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified as being created via the Secondary Logon service, especially those linked to the unique logon identifiers from the alert.
+- Review and revoke any alternate credentials or tokens used in the suspicious process creation to prevent further misuse.
+- Conduct a thorough examination of the affected system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations.
+- 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 stricter access controls and monitoring on the Secondary Logon service to detect and prevent similar privilege escalation attempts in the future.
+- Update and reinforce endpoint detection and response (EDR) solutions to enhance monitoring of process creation events and logon activities, ensuring they are aligned with the latest threat intelligence."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
index ffd8fd02012..a1dabec0a54 100644
--- a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
+++ b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.action == "start" and
  not (process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe" and 
       process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\msiexec.exe", "?:\\Windows\\twain_32\\*.exe"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Created with a Duplicated Token
+
+In Windows environments, tokens are used to represent user credentials and permissions. Adversaries may duplicate tokens to create processes with elevated privileges, bypassing security controls. The detection rule identifies suspicious process creation by examining token usage patterns, process origins, and recent file modifications, while excluding known legitimate behaviors, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process name and executable path to determine if it matches any known legitimate applications or if it is potentially malicious. Pay special attention to processes like powershell.exe, cmd.exe, and rundll32.exe.
+- Examine the parent process and its executable path to understand the process hierarchy and identify any unusual or unexpected parent-child relationships, especially if the parent is not a typical system process.
+- Check the user ID associated with the process to verify if it belongs to a legitimate user or if it appears to be an anomaly, such as a service account being used unexpectedly.
+- Investigate the code signature status of the process to determine if it is trusted or if there are any issues like an expired or untrusted signature, which could indicate tampering or a malicious executable.
+- Analyze the relative file creation and modification times to assess if the process was created or modified recently, which could suggest a recent compromise or unauthorized change.
+- Look for any known exclusions in the query, such as specific command lines or parent processes, to ensure the alert is not a false positive based on legitimate behavior patterns.
+
+### False positive analysis
+
+- Processes initiated by legitimate system maintenance tools like Windows Update or system repair utilities may trigger the rule. Users can create exceptions for these processes by excluding specific parent-child process relationships that are known to be safe.
+- Software installations or updates that involve temporary elevation of privileges might be flagged. Users should consider excluding processes originating from trusted directories like Program Files or Program Files (x86) if they are part of a verified installation or update process.
+- Administrative scripts or automation tools that run with elevated privileges could be misidentified. Users can exclude these by specifying trusted code signatures or known script paths in the rule configuration.
+- Certain legitimate applications that frequently update or modify files within a short time frame may be mistakenly flagged. Users can adjust the relative file creation or modification time thresholds or exclude specific applications by their executable paths.
+- Processes that are part of normal user activity, such as those initiated by explorer.exe, may be incorrectly identified. Users can refine the rule by excluding processes with known benign parent-child relationships involving explorer.exe.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, especially those with duplicated tokens or originating from unexpected parent processes.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or escalations. Revoke any unnecessary or suspicious privileges.
+- Perform a comprehensive scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software or scripts.
+- Review recent file modifications and system logs to identify any additional indicators of compromise or unauthorized activities that may have occurred.
+- Restore any altered or corrupted system files from a known good backup to ensure system integrity and functionality.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_credroaming_ldap.toml b/rules/windows/privilege_escalation_credroaming_ldap.toml
index 2595cb73e58..4499d2c19e9 100644
--- a/rules/windows/privilege_escalation_credroaming_ldap.toml
+++ b/rules/windows/privilege_escalation_credroaming_ldap.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,6 +60,41 @@ event.action:("Directory Service Changes" or "directory-service-object-modified"
   winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and winlog.event_data.OperationType:"%%14674" and
   not winlog.event_data.SubjectUserSid : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
index a6e2874c53a..25df3ece26b 100644
--- a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
+++ b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,42 @@ any where host.os.type == "windows" and event.category : ("library", "process")
   not ?dll.code_signature.trusted == true and
   not file.code_signature.status == "Valid"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unsigned DLL loaded by DNS Service
+
+The DNS service in Windows environments is crucial for resolving domain names to IP addresses. It can be extended via DLLs, which, if unsigned, may indicate tampering. Adversaries exploit this by loading malicious DLLs to gain elevated privileges or execute code with SYSTEM rights. The detection rule identifies such threats by monitoring the DNS process for loading untrusted DLLs, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific DLL file that was loaded by the DNS service and check its file path and name for any known malicious indicators.
+- Examine the file's code signature status and metadata to determine why it is not trusted or valid, and cross-reference with known trusted sources or databases.
+- Investigate the process tree of dns.exe to identify any parent or child processes that may indicate how the unsigned DLL was introduced or executed.
+- Check the system's event logs for any recent changes or anomalies around the time the DLL was loaded, focusing on events related to process creation, file modification, or user account activity.
+- Analyze network traffic logs for any unusual DNS queries or outbound connections that could suggest communication with a command and control server.
+- Assess the system for other signs of compromise, such as unauthorized user accounts, scheduled tasks, or registry changes that could indicate further exploitation or persistence mechanisms.
+- If possible, isolate the affected system to prevent further potential malicious activity and begin remediation steps based on the findings.
+
+### False positive analysis
+
+- Legitimate software updates or patches may introduce new DLLs that are unsigned. Verify the source of the update and, if trusted, create an exception for these DLLs to prevent future alerts.
+- Custom or in-house applications might use unsigned DLLs for specific functionalities. Confirm the legitimacy of these applications and add them to an allowlist to avoid unnecessary alerts.
+- Some third-party security or monitoring tools may load unsigned DLLs as part of their operation. Validate these tools with your security team and configure exceptions for known, safe DLLs.
+- Development or testing environments often use unsigned DLLs during the software development lifecycle. Ensure these environments are properly segmented and consider excluding them from this rule to reduce noise.
+- Legacy systems might rely on older, unsigned DLLs that are still in use. Conduct a risk assessment and, if deemed safe, exclude these DLLs from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate the DNS service process (dns.exe) to stop the execution of the malicious DLL and prevent further potential damage.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software.
+- Restore the DNS service to its original state by replacing the compromised DLL with a legitimate, signed version from a trusted source or backup.
+- Review and update the system's security patches and configurations to address any vulnerabilities that may have been exploited, particularly those related to privilege escalation.
+- Monitor the system and network for any signs of continued or repeated unauthorized activity, focusing on similar indicators of compromise.
+- Report the incident to the appropriate internal security team or external authorities if required, providing details of the threat and actions taken for further investigation and response."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_expired_driver_loaded.toml b/rules/windows/privilege_escalation_expired_driver_loaded.toml
index 5026c5b0606..fcd932fc921 100644
--- a/rules/windows/privilege_escalation_expired_driver_loaded.toml
+++ b/rules/windows/privilege_escalation_expired_driver_loaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,40 @@ query = '''
 driver where host.os.type == "windows" and process.pid == 4 and
   dll.code_signature.status : ("errorExpired", "errorRevoked")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Expired or Revoked Driver Loaded
+In Windows environments, drivers facilitate communication between the OS and hardware. Adversaries exploit vulnerabilities in outdated drivers or misuse revoked certificates to execute malicious code in kernel mode, bypassing security controls. The detection rule identifies such threats by monitoring for drivers with expired or revoked signatures, focusing on processes critical to system integrity, thus flagging potential privilege escalation or defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a driver with an expired or revoked signature, focusing on the process with PID 4, which is typically the System process in Windows.
+- Investigate the specific driver file that triggered the alert by checking its file path, hash, and any associated metadata to determine its origin and legitimacy.
+- Cross-reference the driver file against known vulnerability databases and security advisories to identify any known exploits associated with it.
+- Examine recent system logs and security events for any unusual activities or attempts to load other drivers around the same time as the alert.
+- Assess the system for any signs of privilege escalation or defense evasion, such as unauthorized access attempts or changes to security settings.
+- If the driver is confirmed to be malicious or suspicious, isolate the affected system to prevent further compromise and initiate a detailed forensic analysis.
+
+### False positive analysis
+
+- Legitimate software updates may load drivers with expired or revoked signatures temporarily. Verify the source and purpose of the driver before excluding it.
+- Some older hardware devices may rely on drivers that have expired signatures but are still necessary for functionality. Confirm the device's necessity and consider excluding these drivers if they are from a trusted source.
+- Security software or system management tools might use drivers with expired signatures for legitimate operations. Validate the software's legitimacy and add exceptions for these drivers if they are verified as safe.
+- Custom or in-house developed drivers might not have updated signatures. Ensure these drivers are from a trusted internal source and consider excluding them if they are essential for operations.
+- Test environments may intentionally use expired or revoked drivers for research or development purposes. Clearly document these cases and exclude them to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any processes associated with the expired or revoked driver to halt any ongoing malicious activity.
+- Conduct a thorough review of the system to identify any unauthorized changes or additional malicious drivers that may have been loaded.
+- Revoke any compromised certificates and update the certificate trust list to prevent future misuse.
+- Apply the latest security patches and driver updates to close any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_exploit_cve_202238028.toml b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
index 3d234029f7e..b416904bb8e 100644
--- a/rules/windows/privilege_escalation_exploit_cve_202238028.toml
+++ b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,41 @@ file where host.os.type == "windows" and event.type != "deletion" and
         "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js"
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential privilege escalation via CVE-2022-38028
+
+CVE-2022-38028 targets the Windows Print Spooler service, a core component managing print jobs. Adversaries exploit this by manipulating specific JavaScript files within system directories to gain elevated privileges. The detection rule identifies unauthorized file presence in critical paths, signaling potential exploitation attempts, leveraging multiple data sources for comprehensive threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the file "MPDW-constraints.js" in the specified critical paths: "?:\\\\*\\\\Windows\\\\system32\\\\DriVerStoRe\\\\FiLeRePoSiToRy\\\\*\\\\MPDW-constraints.js" or "?:\\\\*\\\\Windows\\\\WinSxS\\\\amd64_microsoft-windows-printing-printtopdf_*\\\\MPDW-constraints.js".
+- Check the file creation and modification timestamps to determine when the file was placed or altered in the system directories.
+- Investigate the source of the file by examining recent user activity and process execution logs around the time the file appeared, focusing on any suspicious or unauthorized actions.
+- Correlate the event with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or processes that might indicate exploitation attempts.
+- Assess the risk and impact by determining if the affected system has any sensitive roles or access that could be leveraged by an attacker through privilege escalation.
+- If malicious activity is confirmed, initiate containment measures such as isolating the affected system and conducting a full malware scan to prevent further exploitation.
+
+### False positive analysis
+
+- Legitimate software updates or installations may place JavaScript files in the monitored directories. Verify the source and integrity of the software to ensure it is from a trusted vendor.
+- System administrators or automated scripts might deploy or modify JavaScript files in these paths for legitimate configuration purposes. Review change management logs to confirm authorized activities.
+- Security tools or system maintenance processes could temporarily create or modify files in these directories. Cross-reference with scheduled tasks or security tool logs to validate these actions.
+- Exclude known benign applications or processes that frequently interact with the specified file paths by creating exceptions in the detection rule to reduce noise.
+- Regularly update the detection rule to incorporate new intelligence on false positives, ensuring it remains effective and relevant.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious processes related to the Windows Print Spooler service to halt ongoing exploitation attempts.
+- Remove unauthorized JavaScript files, specifically "MPDW-constraints.js", from the identified critical paths to eliminate the immediate threat.
+- Apply the latest security patches and updates from Microsoft to address CVE-2022-38028 and ensure the system is protected against known vulnerabilities.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations.
+- Monitor the network and system logs for any signs of further exploitation attempts or related suspicious activities, using enhanced detection rules.
+- Report the incident to the appropriate internal security team or external authorities if required, providing detailed information about the exploitation attempt and actions taken."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
index 1b27f5b2e7c..3b34bff3439 100644
--- a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
+++ b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,41 @@ file where host.os.type == "windows" and event.type != "deletion" and event.acti
   ) and
   not process.executable : "C:\\Windows\\System32\\dfsrs.exe"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation or Modification of a new GPO Scheduled Task or Service
+
+Group Policy Objects (GPOs) are crucial for centralized management in Windows environments, allowing administrators to configure settings across domain-joined machines. Adversaries with domain admin rights can exploit GPOs to create or modify scheduled tasks or services, deploying malicious payloads network-wide. The detection rule identifies such activities by monitoring specific file changes in GPO paths, excluding legitimate system processes, thus highlighting potential abuse for privilege escalation or persistence.
+
+### Possible investigation steps
+
+- Review the file path and name to confirm if the changes were made to "ScheduledTasks.xml" or "Services.xml" within the specified GPO paths, as these are indicative of potential unauthorized modifications.
+- Check the process that initiated the file change, ensuring it is not "C:\\\\Windows\\\\System32\\\\dfsrs.exe", which is excluded as a legitimate system process.
+- Investigate the user account associated with the file modification event to determine if it has domain admin rights and assess if the activity aligns with their typical behavior or role.
+- Examine recent changes in the GPO settings to identify any new or altered scheduled tasks or services that could be used for malicious purposes.
+- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns.
+- Assess the impact by identifying which domain-joined machines are affected by the GPO changes and determine if any unauthorized tasks or services have been executed.
+
+### False positive analysis
+
+- Legitimate administrative changes to GPOs can trigger alerts. Regularly review and document scheduled administrative tasks to differentiate between expected and unexpected changes.
+- Automated system management tools may modify GPO scheduled tasks or services as part of routine operations. Identify these tools and create exceptions for their processes to reduce noise.
+- Updates or patches from Microsoft or other trusted vendors might alter GPO settings. Monitor update schedules and correlate changes with known update activities to verify legitimacy.
+- Internal IT scripts or processes that manage GPOs for configuration consistency can cause false positives. Ensure these scripts are well-documented and consider excluding their specific actions from monitoring.
+- Temporary changes made by IT staff for troubleshooting or testing purposes can be mistaken for malicious activity. Implement a change management process to log and approve such activities, allowing for easy exclusion from alerts.
+
+### Response and remediation
+
+- Immediately isolate affected systems from the network to prevent further spread of any malicious payloads deployed via the modified GPO scheduled tasks or services.
+- Revoke domain admin privileges from any accounts that are suspected of being compromised to prevent further unauthorized modifications to GPOs.
+- Conduct a thorough review of the modified ScheduledTasks.xml and Services.xml files to identify any unauthorized or malicious entries, and revert them to their previous legitimate state.
+- Utilize endpoint detection and response (EDR) tools to scan for and remove any malicious payloads that may have been executed on domain-joined machines as a result of the GPO modifications.
+- Notify the security operations center (SOC) and escalate the incident to the incident response team for further investigation and to determine the scope of the compromise.
+- Implement additional monitoring on GPO paths and domain admin activities to detect any further unauthorized changes or suspicious behavior.
+- Review and strengthen access controls and auditing policies for GPO management to prevent unauthorized modifications in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
index c2ba7fc2038..f76fee68a41 100644
--- a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
+++ b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,39 @@ sequence by winlog.computer_name with maxspan=5m
    /* event 4697 need to be logged */
    event.action : "service-installed"] by winlog.event_data.SubjectLogonId
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Service Creation via Local Kerberos Authentication
+
+Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event.
+- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system.
+- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious.
+- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity.
+- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance.
+- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule.
+- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening.
+- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation.
+- Terminate any suspicious services created during the incident to halt potential malicious activities.
+- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise.
+- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets.
+- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks.
+- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_lsa_auth_package.toml b/rules/windows/privilege_escalation_lsa_auth_package.toml
index 73c5572df3c..ebffcb765c5 100644
--- a/rules/windows/privilege_escalation_lsa_auth_package.toml
+++ b/rules/windows/privilege_escalation_lsa_auth_package.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,40 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* exclude SYSTEM SID - look for changes by non-SYSTEM user */
   not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential LSA Authentication Package Abuse
+
+The Local Security Authority (LSA) in Windows manages authentication and security policies. Adversaries exploit LSA by modifying registry paths to include malicious binaries, which are executed with SYSTEM privileges during authentication package loading. The detection rule identifies unauthorized registry changes by non-SYSTEM users, signaling potential privilege escalation or persistence attempts.
+
+### Possible investigation steps
+
+- Review the registry change event details to identify the specific binary path added to the LSA Authentication Packages registry key.
+- Investigate the user account associated with the registry change event to determine if it is a legitimate user or potentially compromised.
+- Check the timestamp of the registry modification to correlate with any other suspicious activities or events on the system around the same time.
+- Analyze the binary referenced in the registry change for any known malicious signatures or behaviors using antivirus or threat intelligence tools.
+- Examine system logs and security events for any signs of privilege escalation or persistence techniques used by the adversary.
+- Assess the system for any additional unauthorized changes or indicators of compromise that may suggest further malicious activity.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify the LSA authentication package registry path. Users should verify if recent installations or updates coincide with the detected changes and consider excluding these specific software processes if they are deemed safe.
+- System administrators or IT management tools might perform authorized changes to the registry for maintenance or configuration purposes. Users can create exceptions for known administrative tools or processes that are regularly used for legitimate system management tasks.
+- Security software or endpoint protection solutions may alter the registry as part of their normal operation. Users should identify and whitelist these security applications to prevent unnecessary alerts.
+- Custom scripts or automation tools used within the organization might inadvertently trigger this rule. Users should review and document these scripts, ensuring they are secure, and exclude them if they are confirmed to be non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes associated with the unauthorized registry change to halt potential malicious activity.
+- Restore the modified registry path to its original state by removing any unauthorized entries in the LSA Authentication Packages registry key.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious binaries or remnants.
+- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges.
+- 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 enhanced monitoring and logging for registry changes, particularly those involving LSA authentication packages, to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_make_token_local.toml b/rules/windows/privilege_escalation_make_token_local.toml
index 087a566beff..23552c3d2a7 100644
--- a/rules/windows/privilege_escalation_make_token_local.toml
+++ b/rules/windows/privilege_escalation_make_token_local.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,39 @@ authentication where
              "?:\\Windows\\System32\\inetsrv\\w3wp.exe", 
              "?:\\Windows\\SysWOW64\\msiexec.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Interactive Logon by an Unusual Process
+
+Interactive logons in Windows environments typically involve standard processes like winlogon.exe. Adversaries may exploit alternate processes to create tokens, escalating privileges and bypassing controls. This detection rule identifies anomalies by flagging logons via non-standard executables, focusing on mismatched user SIDs and unusual process paths, thus highlighting potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if it is a known or expected application for interactive logons. Investigate any unfamiliar or suspicious paths.
+- Examine the SubjectUserSid and TargetUserSid to identify the users involved in the logon attempt. Check for any discrepancies or unusual patterns in user activity.
+- Analyze the event logs around the time of the alert to identify any related or preceding events that might indicate how the unusual process was initiated.
+- Investigate the system for any signs of compromise, such as unexpected changes in system files, unauthorized software installations, or other indicators of malicious activity.
+- Check for any recent privilege escalation attempts or access token manipulations that might correlate with the alert, using the MITRE ATT&CK framework references for guidance.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts may trigger this rule if they use non-standard executables for logon processes. To manage this, identify and whitelist these known tools by adding their executable paths to the exception list.
+- Custom applications developed in-house that require interactive logon might be flagged. Review these applications and, if verified as safe, exclude their executable paths from the detection rule.
+- Automated tasks or services that use alternate credentials for legitimate purposes can cause false positives. Analyze these tasks and, if they are part of regular operations, adjust the rule to exclude their specific user SIDs or executable paths.
+- Security software or monitoring tools that perform logon actions for scanning or auditing purposes may be incorrectly flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified as executing from non-standard paths that are not part of the legitimate Windows system processes.
+- Revoke any tokens or credentials associated with the anomalous logon session to prevent further misuse.
+- Conduct a thorough review of user accounts involved, focusing on any unauthorized privilege escalations or changes in permissions, and reset passwords as necessary.
+- Analyze the system for any signs of persistence mechanisms or additional malware, and remove any identified threats.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected that cannot be easily remediated.
+- Report the incident to the appropriate internal security team or management for further investigation and potential escalation to law enforcement if necessary."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
index 61ad9c71af4..21643af5b41 100644
--- a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
+++ b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel", "m365_defender", "window
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,40 @@ process where event.type == "start" and host.os.type == "windows" and
                         "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and
  process.parent.command_line : "*go.microsoft.com*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Escalation via Vulnerable MSI Repair
+
+Windows Installer (MSI) is a service used for software installation and maintenance. Adversaries exploit vulnerabilities in MSI repair functions to gain elevated privileges. This detection rule identifies suspicious activity by monitoring browser processes accessing Microsoft Help pages, followed by elevated process creation, indicating potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific browser process that accessed the Microsoft Help page, noting the process name and command line details.
+- Check the user domain associated with the process to confirm if it matches "NT AUTHORITY", "AUTORITE NT", or "AUTORIDADE NT", which may indicate a system-level account was used.
+- Investigate the parent process of the browser to determine if it was expected or if it shows signs of compromise or unusual behavior.
+- Examine the timeline of events to see if an elevated process was spawned shortly after the browser accessed the Microsoft Help page, indicating potential exploitation.
+- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context or evidence of malicious activity.
+- Assess the risk and impact of the elevated process by identifying its actions and any changes made to the system, such as modifications to critical files or registry keys.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve browser-based help documentation. To manage this, identify and whitelist known software update processes that frequently access Microsoft Help pages.
+- Automated scripts or administrative tools that use browsers to access Microsoft Help for legitimate purposes can cause false positives. Exclude these scripts or tools by specifying their unique command-line patterns or process names.
+- User-initiated troubleshooting or help-seeking behavior that involves accessing Microsoft Help pages might be misinterpreted as suspicious. Educate users on safe browsing practices and consider excluding specific user accounts or domains that are known to frequently engage in such activities.
+- Security tools or monitoring solutions that simulate browser activity for testing purposes may inadvertently trigger the rule. Identify these tools and create exceptions based on their process names or command-line arguments to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious elevated processes that were spawned following the browser's navigation to the Microsoft Help page to halt potential privilege escalation activities.
+- Conduct a thorough review of the affected system's event logs and process creation history to identify any unauthorized changes or additional indicators of compromise.
+- Apply the latest security patches and updates to the Windows Installer service and any other vulnerable components to mitigate the exploited vulnerability.
+- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated.
+- Monitor the network for any signs of similar exploitation attempts or related suspicious activities, using enhanced detection rules and threat intelligence feeds.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
index 77e4e70c55a..1a714ad9b13 100644
--- a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
+++ b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -28,6 +28,40 @@ type = "new_terms"
 query = '''
 event.category:"authentication" and host.os.type:"windows" and winlog.logon.type:"NewCredentials" and winlog.event_data.LogonProcessName:(Advapi* or "Advapi  ") and not winlog.event_data.SubjectUserName:*$ and not process.executable :???\\Program?Files*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Time Seen NewCredentials Logon Process
+
+The NewCredentials logon type in Windows allows processes to impersonate a user without requiring a new logon session, often used for legitimate tasks like network resource access. However, adversaries can exploit this by forging access tokens to escalate privileges and bypass controls. The detection rule identifies unusual processes performing this logon type, excluding known system paths and service accounts, to flag potential misuse indicative of token manipulation attacks.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if it is a known or expected application, especially since the query excludes common system paths like Program Files.
+- Investigate the SubjectUserName to identify the user account associated with the logon event and determine if it is a legitimate user or a potential compromised account.
+- Check the historical activity of the identified process and user account to see if this behavior is consistent with past actions or if it is anomalous.
+- Correlate the event with other security logs to identify any preceding or subsequent suspicious activities, such as failed logon attempts or unusual network connections.
+- Assess the environment for any recent changes or incidents that might explain the unusual logon process, such as software updates or new application deployments.
+- Consult threat intelligence sources to determine if the process or behavior is associated with known malicious activity or threat actors.
+
+### False positive analysis
+
+- Legitimate administrative tools or scripts may trigger this rule if they use the NewCredentials logon type for network resource access. To manage this, identify and whitelist these tools by their process executable paths.
+- Scheduled tasks or automated processes running under service accounts might be flagged. Review these tasks and exclude them by adding exceptions for known service account names.
+- Software updates or installations that require elevated privileges could cause false positives. Monitor these activities and create exceptions for the specific processes involved in regular update cycles.
+- Custom in-house applications that use impersonation for legitimate purposes may be detected. Work with development teams to document these applications and exclude their process paths from the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified as using the NewCredentials logon type that are not part of known system paths or service accounts.
+- Revoke any potentially compromised access tokens and reset credentials for affected user accounts to prevent further misuse.
+- Conduct a thorough review of recent logon events and process executions on the affected system to identify any additional unauthorized activities or compromised accounts.
+- 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 enhanced monitoring for similar suspicious logon activities across the network to detect and respond to potential future attempts promptly.
+- Review and update access control policies and token management practices to mitigate the risk of access token manipulation in the future."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
index a7cba94a807..914e76d5ef2 100644
--- a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
+++ b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/10"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,41 @@ registry where host.os.type == "windows" and event.type == "change" and
   /* exclude SYSTEM SID - look for changes by non-SYSTEM user */
   not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Port Monitor or Print Processor Registration Abuse
+
+Port monitors and print processors are integral to Windows printing, managing data flow and processing print jobs. Adversaries exploit these by registering malicious DLLs, which execute with SYSTEM privileges at boot, enabling persistence and privilege escalation. The detection rule identifies registry changes in specific paths, focusing on non-SYSTEM user modifications, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs in the paths: HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\* and HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\*.
+- Identify the user account associated with the registry change by examining the user.id field, ensuring it is not the SYSTEM account (S-1-5-18), and determine if the account has a legitimate reason to modify these registry paths.
+- Check the file properties and digital signatures of the DLLs found in the registry paths to verify their legitimacy and identify any anomalies or signs of tampering.
+- Investigate the system's event logs around the time of the registry change to gather additional context, such as other activities performed by the same user or related processes that might indicate malicious behavior.
+- Conduct a threat intelligence search on the identified DLLs and any associated file hashes to determine if they are known to be associated with malicious activity or threat actors.
+- Assess the system for any signs of privilege escalation or persistence mechanisms that may have been established as a result of the registry modification, such as new services or scheduled tasks.
+
+### False positive analysis
+
+- Legitimate software installations or updates may modify print processor or port monitor registry paths. Users should verify if recent installations or updates coincide with the detected changes.
+- System administrators performing maintenance or configuration changes might trigger alerts. Ensure that such activities are documented and cross-referenced with the alert timestamps.
+- Some third-party printing solutions may register their own DLLs in these registry paths. Identify and whitelist these known applications to prevent unnecessary alerts.
+- Automated scripts or management tools that modify printer settings could cause false positives. Review and adjust these tools to ensure they operate under expected user accounts or exclude their known behaviors.
+- Regularly review and update the exclusion list to include any new benign applications or processes that interact with the monitored registry paths.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes associated with the malicious DLLs identified in the registry paths to halt their execution.
+- Remove the unauthorized DLL entries from the registry paths: HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\* and HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\* to eliminate persistence mechanisms.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants.
+- Review and reset credentials for any accounts that may have been compromised, especially those with elevated privileges, to prevent unauthorized access.
+- Implement application whitelisting to prevent unauthorized DLLs from executing, focusing on the paths identified in the alert.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected, ensuring comprehensive threat containment and eradication."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
index c27dff3ffb8..1582cf363c6 100644
--- a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
+++ b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,40 @@ sequence by host.id with maxspan=30s
     ) and
  registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4\\*"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Print Spooler Point and Print DLL
+
+The Windows Print Spooler service manages print jobs and is integral to printing operations. Adversaries exploit vulnerabilities like CVE-2020-1030 to escalate privileges by loading malicious DLLs into the spooler process, which runs with SYSTEM-level permissions. The detection rule identifies suspicious registry modifications linked to the Print Spooler, indicating potential exploitation attempts by monitoring specific registry paths and data patterns.
+
+### Possible investigation steps
+
+- Review the registry paths specified in the alert to confirm any unauthorized modifications, focusing on the paths: HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\SpoolDirectory and HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\CopyFiles\\Payload\\Module.
+- Check the registry data strings for any unexpected or suspicious DLLs located in C:\\Windows\\System32\\spool\\drivers\\x64\\4, which may indicate a malicious payload.
+- Investigate the host identified by host.id to determine if there are any other signs of compromise or unusual activity, such as unexpected processes or network connections.
+- Correlate the alert with other security events or logs from the same host to identify any related activities or patterns that could suggest a broader attack.
+- Assess the system's patch level and update status to ensure that all known vulnerabilities, including CVE-2020-1030, have been addressed and mitigated.
+- If a malicious DLL is confirmed, isolate the affected system to prevent further exploitation and begin remediation efforts, such as removing the malicious files and restoring the system to a known good state.
+
+### False positive analysis
+
+- Legitimate printer driver updates or installations may trigger the rule due to registry modifications in the specified paths. Users can create exceptions for known and trusted driver update processes to prevent false alerts.
+- Custom print configurations by IT departments that modify the SpoolDirectory or CopyFiles registry paths might be flagged. Document and exclude these configurations if they are verified as safe and necessary for business operations.
+- Automated scripts or software that manage printer settings and inadvertently modify the monitored registry paths can cause false positives. Identify and whitelist these scripts or applications after confirming their legitimacy.
+- Third-party print management solutions that interact with the Print Spooler service may lead to false detections. Evaluate these solutions and exclude their known benign activities from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate the Print Spooler service on the compromised system to stop any ongoing malicious activity and prevent further DLL loading.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious DLLs or related files.
+- Review and restore the registry paths identified in the detection query to their default values to ensure no malicious configurations remain.
+- Apply the latest security patches and updates from Microsoft to address CVE-2020-1030 and other known vulnerabilities in the Print Spooler service.
+- Monitor the network for any signs of similar exploitation attempts, focusing on the registry paths and data patterns specified in the detection rule.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
index f43288f064e..d9c5a9ac6fb 100644
--- a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
+++ b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,40 @@ query = '''
 event.category : "file" and host.os.type : "windows" and event.type : "creation" and
   process.name : "spoolsv.exe" and file.extension : "dll"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious PrintSpooler Service Executable File Creation
+
+The Print Spooler service in Windows manages print jobs, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies such threats by monitoring file creation events linked to the spooler process, focusing on DLL files, which are common vectors for exploitation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of a file creation event with the extension "dll" associated with the "spoolsv.exe" process on a Windows host.
+- Check the file path and name of the created DLL to determine if it matches known malicious patterns or locations typically used for exploitation.
+- Investigate the source of the spoolsv.exe process by examining the parent process and any associated user accounts to identify potential unauthorized access or activity.
+- Analyze recent system logs and security events for any other suspicious activities or anomalies around the time of the DLL creation, such as unexpected user logins or privilege changes.
+- Verify the patch status of the affected system against the vulnerabilities CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 to ensure it is up to date and not susceptible to known exploits.
+- If the DLL is confirmed to be malicious, isolate the affected system to prevent further exploitation and begin remediation efforts, including removing the malicious file and any associated threats.
+
+### False positive analysis
+
+- Legitimate DLL updates by trusted software can trigger the rule. Users should verify the source of the DLL and, if confirmed safe, add the software's update process to an exception list.
+- System maintenance activities, such as Windows updates, may create DLLs that match the rule's criteria. Users can exclude these activities by identifying the associated update processes and adding them to the exception list.
+- Custom in-house applications that interact with the Print Spooler service might generate DLLs during normal operation. Users should validate these applications and exclude their file creation events if they are deemed non-threatening.
+- Security software or monitoring tools that interact with the Print Spooler service could inadvertently create DLLs. Users should confirm the legitimacy of these tools and configure exceptions for their operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate the spoolsv.exe process if it is confirmed to be executing a malicious DLL, to halt any ongoing malicious activity.
+- Remove the malicious DLL file from the system to prevent re-execution and further exploitation.
+- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to close the vulnerabilities exploited by the adversary.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.
+- Monitor the network for any signs of similar exploitation attempts or related suspicious activity, using enhanced logging and alerting mechanisms.
+- Report the incident to the appropriate internal security team or external authorities if required, providing details of the exploit and actions taken for further investigation and response."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
index 65e8bd0d499..b62efa4f950 100644
--- a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
+++ b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,40 @@ file where host.os.type == "windows" and event.type == "deletion" and
   file.extension : "dll" and file.path : "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.dll" and
   not process.name : ("spoolsv.exe", "dllhost.exe", "explorer.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Print Spooler File Deletion
+
+The Print Spooler service in Windows manages print jobs and interactions with printers. Adversaries exploit vulnerabilities in this service to escalate privileges, often deleting print driver files to cover their tracks. The detection rule identifies unusual deletions of these files by processes other than legitimate ones, signaling potential misuse and aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path and name of the deleted DLL file within "C:\\Windows\\System32\\spool\\drivers\\x64\\3\\".
+- Examine the process responsible for the deletion by checking the process name and its parent process to determine if it is a known legitimate process or a potentially malicious one.
+- Investigate the timeline of events around the deletion to identify any preceding or subsequent suspicious activities, such as privilege escalation attempts or unauthorized access.
+- Check for any recent vulnerabilities or exploits related to the Print Spooler service that might have been leveraged in this context.
+- Correlate the event with other security logs and alerts from data sources like Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and confirm the presence of malicious activity.
+- Assess the affected system for any signs of compromise or persistence mechanisms that may have been established following the deletion event.
+
+### False positive analysis
+
+- System maintenance or updates may trigger legitimate deletions of print driver files. Monitor scheduled maintenance activities and correlate them with detected events to confirm legitimacy.
+- Third-party printer management software might delete or update driver files as part of its normal operation. Identify and whitelist these processes if they are verified as non-threatening.
+- Custom scripts or administrative tools used by IT staff for printer management could inadvertently match the rule's criteria. Review and document these tools, then create exceptions for known safe operations.
+- Automated deployment tools that update or clean up printer drivers across the network might cause false positives. Ensure these tools are recognized and excluded from the detection rule if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified as responsible for the deletion of print driver files, ensuring they are not legitimate system processes.
+- Restore the deleted print driver files from a known good backup to ensure the Print Spooler service functions correctly.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations.
+- Apply the latest security patches and updates to the Print Spooler service and related components to mitigate known vulnerabilities.
+- Monitor the affected system and network for any signs of further suspicious activity, focusing on similar file deletion patterns or privilege escalation attempts.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
index fb45da30925..8953e2de71d 100644
--- a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
+++ b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -87,6 +87,41 @@ registry where host.os.type == "windows" and event.type == "change" and process.
         )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privilege Escalation via Service ImagePath Modification
+
+Windows services are crucial for system operations, often running with high privileges. Adversaries exploit this by altering the ImagePath registry key of services to execute malicious code with elevated privileges. The detection rule identifies suspicious modifications to service ImagePaths, focusing on changes that deviate from standard executable paths, thus flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the specific registry key and value that triggered the alert to confirm it matches one of the monitored service keys, such as those listed in the query (e.g., *\\LanmanServer, *\\Winmgmt).
+- Examine the modified ImagePath value to determine if it points to a non-standard executable path or a suspicious executable, especially those not located in %systemroot%\\system32\\.
+- Check the process.executable field to identify the process responsible for the registry modification and assess its legitimacy.
+- Investigate the user account associated with the modification event to determine if it has elevated privileges, such as membership in the Server Operators group.
+- Correlate the event with other logs or alerts to identify any related suspicious activities, such as unexpected service starts or process executions.
+- Review recent changes or activities on the host to identify any unauthorized access or configuration changes that could indicate a broader compromise.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify service ImagePaths. Users can create exceptions for known update processes or installation paths to prevent false positives.
+- System administrators might intentionally change service configurations for maintenance or troubleshooting. Document and exclude these changes by adding exceptions for specific administrator actions or paths.
+- Custom scripts or automation tools that modify service settings as part of their operation can trigger alerts. Identify and whitelist these scripts or tools to avoid unnecessary alerts.
+- Some third-party security or management software may alter service ImagePaths as part of their functionality. Verify the legitimacy of such software and exclude their known paths from detection.
+- Changes made by trusted IT personnel during system configuration or optimization should be logged and excluded from alerts to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified as running from non-standard executable paths, especially those not originating from the system32 directory.
+- Restore the modified ImagePath registry key to its original state using a known good configuration or backup.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or persistence mechanisms.
+- Review and audit user accounts and group memberships, particularly those with elevated privileges like Server Operators, to ensure no unauthorized changes have been made.
+- 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 enhanced monitoring and alerting for future modifications to service ImagePath registry keys, focusing on deviations from standard paths to detect similar threats promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
index c87668f25ff..3240d6eaba6 100644
--- a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
+++ b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,42 @@ registry.path : (
     ) and
  not registry.data.strings : ("C:\\windows", "%SystemRoot%")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privilege Escalation via Windir Environment Variable
+
+The Windir environment variable points to the Windows directory, crucial for system operations. Adversaries may alter this variable to redirect processes to malicious directories, gaining elevated privileges. The detection rule monitors changes to this variable in the registry, flagging deviations from expected paths like "C:\\windows," thus identifying potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the registry change event details to identify the specific user account associated with the altered Windir or SystemRoot environment variable. This can be done by examining the registry path and user context in the event data.
+- Check the registry data strings to determine the new path set for the Windir or SystemRoot variable. Investigate if this path points to a known malicious directory or an unexpected location.
+- Correlate the event with other recent registry changes or system events on the same host to identify any patterns or additional suspicious activities that might indicate a broader attack.
+- Investigate the process or application that initiated the registry change by reviewing process creation logs or command-line arguments around the time of the event. This can help identify the source of the change.
+- Assess the affected system for any signs of compromise or unauthorized access, such as unusual network connections, unexpected running processes, or new user accounts.
+- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, particularly those involving privilege escalation techniques.
+- If possible, restore the Windir or SystemRoot environment variable to its expected value and monitor the system for any further unauthorized changes.
+
+### False positive analysis
+
+- System updates or patches may temporarily alter the Windir environment variable. Monitor for these events during known maintenance windows and consider excluding them from alerts.
+- Custom scripts or applications that modify environment variables for legitimate purposes can trigger false positives. Identify these scripts and whitelist their activity in the detection rule.
+- User profile migrations or system restorations might change the Windir path. Exclude these operations if they are part of routine IT processes.
+- Virtual environments or sandboxed applications may use different Windir paths. Verify these environments and adjust the detection rule to accommodate their specific configurations.
+- Administrative tools that modify user environments for configuration management can cause alerts. Document these tools and create exceptions for their expected behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Revert the Windir environment variable to its legitimate value, typically "C:\\windows", to restore normal system operations.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software or scripts.
+- Review recent user activity and system logs to identify any unauthorized access or changes, focusing on the time frame around the detected registry change.
+- Reset passwords for any user accounts that may have been compromised, especially those with elevated privileges.
+- 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 enhanced monitoring on the affected system and similar endpoints to detect any further attempts to alter critical environment variables or other suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
index 74ffe84b293..67a5e4854c7 100644
--- a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
+++ b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/12"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,40 @@ iam where event.action == "renamed-user-account" and
   /* machine account name renamed to user like account name */
   winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Privileged Escalation via SamAccountName Spoofing
+
+In Active Directory environments, the samAccountName attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to spoof this attribute, potentially elevating privileges by renaming computer accounts to mimic domain controllers. The detection rule identifies suspicious renaming events, where a machine account is altered to resemble a user account, signaling possible privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the event logs to confirm the occurrence of a "renamed-user-account" action, focusing on entries where the OldTargetUserName ends with a "$" and the NewTargetUserName does not, indicating a potential spoofing attempt.
+- Identify the source of the rename event by examining the event logs for the user or system that initiated the change, and determine if it aligns with expected administrative activity.
+- Check the history of the NewTargetUserName to see if it has been used in any recent authentication attempts or privileged operations, which could indicate malicious intent.
+- Investigate the associated IP address and hostname from which the rename action was performed to determine if it is a known and trusted source within the network.
+- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
+- Assess the potential impact by determining if the renamed account has been granted elevated privileges or access to sensitive resources since the rename event occurred.
+
+### False positive analysis
+
+- Routine administrative tasks involving legitimate renaming of computer accounts can trigger false positives. To manage this, create exceptions for known administrative activities by excluding specific administrator accounts or service accounts from the detection rule.
+- Automated processes or scripts that rename computer accounts as part of regular maintenance or deployment procedures may also cause false alerts. Identify these processes and exclude their associated accounts or event patterns from the rule.
+- Temporary renaming of computer accounts for troubleshooting or testing purposes can be mistaken for suspicious activity. Document and exclude these temporary changes by maintaining a list of authorized personnel and their activities.
+- Changes made by trusted third-party software or management tools that interact with Active Directory should be reviewed and, if deemed safe, excluded from triggering alerts by specifying the tool's account or signature in the rule exceptions.
+
+### Response and remediation
+
+- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain.
+- Revert any unauthorized changes to the samAccountName attribute by renaming the affected computer account back to its original name.
+- Conduct a thorough review of recent changes in Active Directory, focusing on user and computer account modifications, to identify any other potentially compromised accounts.
+- Reset passwords for the affected machine account and any other accounts that may have been accessed or modified during the incident.
+- Apply the latest security patches and updates to all domain controllers and critical systems to mitigate vulnerabilities like CVE-2021-42278.
+- Enhance monitoring and logging for Active Directory events, specifically focusing on account renaming activities, to detect similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
index 100d963e6e4..6b8d0118def 100644
--- a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
+++ b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/11"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,41 @@ iam where event.action == "changed-computer-account" and user.id : ("S-1-5-21-*"
     /* exclude FPs where DnsHostName starts with the ComputerName that was changed */
     not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Remote Computer Account DnsHostName Update
+
+In Active Directory environments, the DnsHostName attribute links computer accounts to their DNS names, crucial for network communication. Adversaries may exploit this by altering a non-domain controller's DnsHostName to mimic a domain controller, potentially exploiting vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, flagging potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the event logs to confirm the occurrence of the "changed-computer-account" action, focusing on the user.id fields ("S-1-5-21-*", "S-1-12-1-*") to identify the user who initiated the change.
+- Verify the new DnsHostName value against the list of legitimate domain controller DNS hostnames to assess if it matches any known domain controllers.
+- Check the winlog.event_data.TargetUserName to ensure that the DnsHostName does not start with the computer name that was changed, which could indicate a false positive.
+- Investigate the account associated with the user.id to determine if it has a history of suspicious activity or if it has been compromised.
+- Examine recent changes or activities on the affected computer account to identify any unauthorized access or configuration changes.
+- Correlate this event with other security alerts or logs to identify potential patterns or coordinated activities that might indicate a broader attack.
+
+### False positive analysis
+
+- Routine maintenance or updates to computer accounts may trigger the rule if the DnsHostName is temporarily set to a domain controller-like name. To manage this, create exceptions for known maintenance periods or specific administrative accounts performing these updates.
+- Automated scripts or tools that update computer account attributes might inadvertently match the rule's conditions. Identify and exclude these scripts or tools by their user IDs or specific patterns in their operations.
+- Legitimate changes in network architecture, such as the promotion of a server to a domain controller, could be flagged. Ensure that such changes are documented and create exceptions for the involved accounts or systems during the transition period.
+- Temporary testing environments where non-domain controllers are configured with domain controller-like hostnames for testing purposes can cause false positives. Exclude these environments by their specific hostnames or network segments.
+- Regularly review and update the list of known domain controller hostnames to ensure that legitimate changes in the network are not mistakenly flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected computer from the network to prevent further unauthorized changes or potential exploitation.
+- Verify the legitimacy of the DnsHostName change by cross-referencing with known domain controller hostnames and authorized change requests.
+- Revert any unauthorized changes to the DnsHostName attribute to its original state to restore proper network communication and prevent misuse.
+- Conduct a thorough review of recent account activities and permissions for the user account involved in the change to identify any unauthorized access or privilege escalation attempts.
+- Escalate the incident to the security operations team for further investigation and to assess potential exploitation of CVE-2022-26923 or other vulnerabilities.
+- Implement additional monitoring on the affected system and similar systems to detect any further suspicious activities or attempts to exploit vulnerabilities.
+- Review and update access controls and permissions for computer accounts in Active Directory to ensure only authorized personnel can make changes to critical attributes like DnsHostName."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
index b661cf23c54..4bf6f7109ee 100644
--- a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
+++ b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -70,6 +70,41 @@ any where host.os.type == "windows" and event.provider: "Microsoft-Windows-Secur
           "?:\\Windows\\System32\\wbem\\WmiPrvSe.exe",
           "?:\\Windows\\SysWOW64\\wbem\\WmiPrvSe.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 SeDebugPrivilege Enabled by a Suspicious Process
+
+SeDebugPrivilege is a powerful Windows privilege allowing processes to debug and modify other processes, typically reserved for system-level tasks. Adversaries exploit this to escalate privileges, bypassing security controls by impersonating system processes. The detection rule identifies suspicious processes enabling SeDebugPrivilege, excluding known legitimate processes, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event.provider "Microsoft-Windows-Security-Auditing" and event.action "Token Right Adjusted Events" to gather more details about the process that enabled SeDebugPrivilege.
+- Identify the process name from winlog.event_data.ProcessName and determine if it is known or expected in the environment. Investigate any unknown or suspicious processes.
+- Check the winlog.event_data.SubjectUserSid to identify the user account associated with the process. Investigate if this account has a history of suspicious activity or if it should have the ability to enable SeDebugPrivilege.
+- Analyze the parent process of the suspicious process to understand how it was initiated and if it was spawned by a legitimate or malicious process.
+- Correlate the timestamp of the event with other security events or alerts to identify any related activities or patterns that could indicate a broader attack or compromise.
+- Investigate the network activity of the suspicious process to determine if it is communicating with any known malicious IP addresses or domains.
+
+### False positive analysis
+
+- Legitimate system maintenance tasks may trigger the rule, such as Windows Update or system diagnostics. Users can monitor the timing of these tasks and correlate them with alerts to determine if they are the cause.
+- Software installations or updates using msiexec.exe might be flagged. Consider excluding msiexec.exe from the rule if it is frequently used in your environment for legitimate purposes.
+- Administrative tools like taskhostw.exe and mmc.exe can sometimes enable SeDebugPrivilege during normal operations. Evaluate the necessity of these tools in your environment and exclude them if they are regularly used by trusted administrators.
+- Temporary files created by legitimate applications, such as DismHost.exe in user temp directories, may be flagged. Review the context of these files and exclude them if they are part of routine application behavior.
+- Regularly review and update the exclusion list to include any new legitimate processes that are identified as false positives, ensuring the rule remains effective without generating unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate the suspicious process identified in the alert to stop any ongoing malicious activity and prevent privilege escalation.
+- Conduct a thorough review of the affected system's event logs, focusing on the "Token Right Adjusted Events" to identify any additional unauthorized privilege changes or suspicious activities.
+- Reset credentials for any accounts that may have been compromised or used by the suspicious process, especially those with elevated privileges.
+- Restore the affected system from a known good backup to ensure any malicious changes are removed and the system is returned to a secure state.
+- Implement additional monitoring on the affected system and similar systems to detect any recurrence of the threat, focusing on processes attempting to enable SeDebugPrivilege.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
index fc2f865bcc9..9d183646630 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/28"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,41 @@ process where host.os.type == "windows" and event.type == "start" and process.na
   /* CLSID of the Elevated COM Interface IEditionUpgradeManager */
   process.parent.args : "/Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface
+
+User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. The IEditionUpgradeManager COM interface can be exploited by attackers to bypass UAC, allowing them to execute code with elevated privileges without user consent. This detection rule identifies such attempts by monitoring for the execution of the ClipUp program from non-standard paths, initiated by a specific COM interface, indicating potential misuse for privilege escalation.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of ClipUp.exe running from a non-standard path, as indicated by the process.executable field not matching "C:\\Windows\\System32\\ClipUp.exe".
+- Investigate the parent process, dllhost.exe, to determine if it was legitimately initiated or if it shows signs of compromise, focusing on the process.parent.args field to verify the use of the specific COM interface CLSID: /Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}.
+- Check the user account context under which ClipUp.exe was executed to assess if it aligns with expected user behavior or if it suggests unauthorized access.
+- Correlate this event with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or patterns.
+- Examine recent changes or anomalies in system configurations or installed software that might indicate preparation for or execution of a UAC bypass attempt.
+- If available, review network activity logs for any unusual outbound connections or data exfiltration attempts following the execution of ClipUp.exe.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they temporarily use non-standard paths for ClipUp.exe. Verify the source and purpose of the process to determine if it is part of a legitimate update or installation.
+- Custom scripts or administrative tools that utilize ClipUp.exe from non-standard paths for legitimate purposes can cause false positives. Review the script or tool usage and consider excluding these specific paths if they are verified as safe.
+- Software testing environments where ClipUp.exe is executed from non-standard paths for testing purposes may trigger the rule. Implement exclusions for known testing environments to prevent unnecessary alerts.
+- Automated deployment tools that use ClipUp.exe from non-standard paths as part of their deployment process can be mistaken for malicious activity. Confirm the deployment tool's behavior and add exceptions for its known operations.
+- In environments where multiple users have administrative privileges, legitimate administrative actions might inadvertently match the rule's criteria. Regularly audit administrative actions and consider excluding known benign activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate the ClipUp.exe process if it is running from a non-standard path to stop any ongoing malicious activity.
+- Conduct a thorough review of the system's recent activity logs to identify any additional unauthorized changes or suspicious behavior.
+- Restore any altered system files or configurations to their original state using known good backups or system restore points.
+- Update and patch the operating system and all installed software to the latest versions to mitigate known vulnerabilities.
+- Implement application whitelisting to prevent unauthorized programs from executing, focusing on blocking non-standard paths for critical system executables.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
index 216891dbd73..ac5454795a3 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,42 @@ process where host.os.type == "windows" and event.type == "start" and
  /* uncomment once in winlogbeat */
  /* and not (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) */
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer
+
+User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. Adversaries may exploit elevated COM interfaces, such as the Internet Explorer Add-On Installer, to bypass UAC and execute malicious code with higher privileges. The detection rule identifies suspicious processes originating from temporary directories, launched by the IE installer with specific arguments, indicating potential UAC bypass attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the executable path matches the pattern "C:\\\\*\\\\AppData\\\\*\\\\Temp\\\\IDC*.tmp\\\\*.exe" and verify if it is expected or known within the environment.
+- Investigate the parent process "ieinstal.exe" to determine if its execution is legitimate, checking for any unusual or unexpected usage patterns.
+- Examine the command-line arguments used by the parent process, specifically looking for the "-Embedding" argument, to understand the context of its execution.
+- Check the code signature of the suspicious process to determine if it is signed by a trusted entity, and assess the trustworthiness of the signature if present.
+- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related malicious activity.
+- Investigate the user account associated with the process to determine if there are any signs of compromise or unauthorized access attempts.
+- Assess the risk and impact of the potential UAC bypass attempt on the system and broader network, and take appropriate containment or remediation actions if necessary.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they temporarily use the specified directory structure. Users can monitor the frequency and context of these alerts to determine if they align with known software behaviors.
+- Development or testing environments might generate alerts due to the execution of scripts or applications from temporary directories. Users can create exceptions for specific environments or processes that are known to be safe.
+- System administrators or IT personnel performing legitimate administrative tasks might inadvertently trigger the rule. Users can exclude specific user accounts or processes from monitoring if they are verified as non-threatening.
+- Automated software deployment tools that use temporary directories for installation processes may cause false positives. Users can whitelist these tools by verifying their code signatures and adding them to an exception list.
+- Regularly review and update the list of trusted applications and processes to ensure that only verified and necessary exceptions are in place, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified by the detection rule, specifically those originating from temporary directories and launched by "ieinstal.exe" with the "-Embedding" argument.
+- Conduct a thorough review of the affected system to identify any additional unauthorized changes or malware installations, focusing on temporary directories and COM interface usage.
+- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed.
+- Update and patch the affected system to the latest security updates to mitigate known vulnerabilities that could be exploited for UAC bypass.
+- Implement application whitelisting to prevent unauthorized executables from running, particularly those in temporary directories.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
index 1f75e4522af..4c4e4fdbd13 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,41 @@ process where host.os.type == "windows" and event.type == "start" and
  process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and
  process.pe.original_file_name != "WerFault.exe"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 UAC Bypass via ICMLuaUtil Elevated COM Interface
+
+The ICMLuaUtil Elevated COM Interface is a Windows component that facilitates User Account Control (UAC) operations, allowing certain processes to execute with elevated privileges. Adversaries exploit this by invoking the interface to bypass UAC, executing malicious code stealthily. The detection rule identifies such attempts by monitoring processes initiated by `dllhost.exe` with specific arguments, excluding legitimate processes like `WerFault.exe`, thus flagging potential privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent and child processes of the flagged `dllhost.exe` instance to understand the context of its execution.
+- Examine the command-line arguments of the `dllhost.exe` process to confirm the presence of the suspicious `/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}` or `/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}` arguments.
+- Check for any recent changes or installations on the system that might have introduced the suspicious behavior, focusing on software that might interact with UAC settings.
+- Investigate the user account under which the `dllhost.exe` process was executed to determine if it has been compromised or if it has elevated privileges.
+- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns.
+- Assess the network activity of the affected system around the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they use the ICMLuaUtil Elevated COM Interface for necessary elevation. Users can monitor the specific software involved and create exceptions for trusted applications.
+- System maintenance tasks initiated by IT administrators might use similar processes for legitimate purposes. Identifying these tasks and excluding them from the rule can reduce false positives.
+- Certain enterprise applications may require elevated privileges and use the same COM interface. Regularly review and whitelist these applications to prevent unnecessary alerts.
+- Automated scripts or tools used for system management that invoke the interface should be evaluated. If deemed safe, they can be added to an exclusion list to avoid repeated false positives.
+- Regularly update the list of excluded processes to reflect changes in the organization's software environment, ensuring that only non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes initiated by `dllhost.exe` with the specified arguments to stop the execution of potentially malicious code.
+- Conduct a thorough review of the affected system to identify any unauthorized changes or additional malicious files, and remove them.
+- Restore the system from a known good backup if any critical system files or configurations have been altered.
+- Update and patch the operating system and all installed software to mitigate any known vulnerabilities that could be exploited for UAC bypass.
+- Implement application whitelisting to prevent unauthorized applications from executing, focusing on blocking the execution of `dllhost.exe` with suspicious arguments.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
index b967a003284..8190711c258 100644
--- a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,6 +60,42 @@ process where host.os.type == "windows" and event.type == "start" and
         "\\Device\\HarddiskVolume?\\Windows\\System32\\taskhostw.exe"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 UAC Bypass via DiskCleanup Scheduled Task Hijack
+
+User Account Control (UAC) is a security feature in Windows that helps prevent unauthorized changes. Adversaries may exploit the DiskCleanup Scheduled Task to bypass UAC, executing code with elevated privileges. The detection rule identifies suspicious processes using specific arguments and executables not matching known safe paths, flagging potential UAC bypass attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious arguments "/autoclean" and "/d" in the process execution.
+- Verify the executable path of the process to ensure it does not match known safe paths such as "C:\\Windows\\System32\\cleanmgr.exe" or "C:\\Windows\\SysWOW64\\cleanmgr.exe".
+- Investigate the parent process to determine how the suspicious process was initiated and assess if it was triggered by a legitimate application or script.
+- Check the user account under which the process was executed to identify if it aligns with expected user behavior or if it indicates potential compromise.
+- Analyze recent system changes or scheduled tasks to identify any unauthorized modifications that could facilitate UAC bypass.
+- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context on the activity.
+- Assess the risk and impact of the event by considering the severity and risk score, and determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Legitimate system maintenance tools or scripts may trigger the rule if they use similar arguments and executables not listed in the safe paths. Review the process origin and context to determine if it is part of routine maintenance.
+- Custom administrative scripts that automate disk cleanup tasks might be flagged. Verify the script's source and purpose, and consider adding it to an exception list if it is deemed safe.
+- Software updates or installations that temporarily use disk cleanup functionalities could be misidentified. Monitor the timing and context of these events, and exclude known update processes from the rule.
+- Third-party disk management tools that mimic or extend Windows disk cleanup features may cause alerts. Validate the tool's legitimacy and add it to the exclusion list if it is a trusted application.
+- Scheduled tasks created by IT departments for system optimization might match the rule's criteria. Confirm the task's legitimacy and adjust the rule to exclude these specific tasks if they are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule that are not using the legitimate DiskCleanup executables.
+- Conduct a thorough review of scheduled tasks on the affected system to identify and remove any unauthorized or malicious tasks that may have been created or modified.
+- Restore any altered system files or configurations to their original state using known good backups or system restore points.
+- Update and patch the affected system to the latest security updates to mitigate any known vulnerabilities that could be exploited for UAC bypass.
+- Monitor the affected system and network for any signs of recurring unauthorized activity or similar UAC bypass attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
index 8e26acb0697..abcd2445f99 100644
--- a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/27"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,42 @@ file where host.os.type == "windows" and event.type : "change" and process.name
   /* has no impact on rule logic just to avoid OS install related FPs */
   not file.path : ("C:\\Windows\\SoftwareDistribution\\*", "C:\\Windows\\WinSxS\\*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 UAC Bypass Attempt via Privileged IFileOperation COM Interface
+
+The IFileOperation COM interface is a Windows component used for file operations with elevated privileges. Adversaries exploit this by side-loading malicious DLLs into processes like dllhost.exe, bypassing UAC to gain elevated permissions stealthily. The detection rule identifies such attempts by monitoring changes in specific DLLs loaded into high-integrity processes, filtering out benign system paths to reduce false positives.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "dllhost.exe" and verify the integrity level of the process to ensure it is running with high or system integrity.
+- Check the file name involved in the alert to see if it matches any of the known malicious DLLs such as "wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", or "Accessibility.ni.dll".
+- Investigate the file path of the loaded DLL to ensure it does not originate from benign system paths like "C:\\Windows\\SoftwareDistribution\\" or "C:\\Windows\\WinSxS\\".
+- Analyze the parent process of "dllhost.exe" to determine how it was initiated and whether it aligns with expected behavior or indicates potential compromise.
+- Review recent system changes or installations that might have introduced the suspicious DLL, focusing on any unauthorized or unexpected software installations.
+- Correlate the event with other security logs or alerts from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or patterns.
+- Assess the risk and impact of the potential UAC bypass attempt and determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- System updates and installations can trigger false positives due to legitimate changes in DLLs. Exclude paths related to Windows updates and installations, such as C:\\Windows\\SoftwareDistribution\\* and C:\\Windows\\WinSxS\\*.
+- Certain legitimate software may use DLLs like comctl32.dll or duser.dll in a manner that mimics side-loading. Identify and whitelist these applications if they are known and trusted within your environment.
+- Security software or system management tools might perform operations that resemble UAC bypass attempts. Review and exclude these tools if they are verified as safe and necessary for your operations.
+- Regularly review and update the list of known benign DLLs and paths to ensure that new legitimate software does not trigger false positives.
+- Monitor for patterns of repeated false positives from specific processes or paths and consider creating exceptions for these scenarios after thorough validation.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate the dllhost.exe process if it is confirmed to be involved in the UAC bypass attempt to stop any ongoing malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious DLLs or associated malware.
+- Review and restore any modified system files or settings to their original state to ensure system integrity.
+- Apply any pending security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
+- Monitor the network for any signs of similar activity or attempts to exploit the IFileOperation COM interface on other systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unquoted_service_path.toml b/rules/windows/privilege_escalation_unquoted_service_path.toml
index a5d975e7816..a48dcfe165d 100644
--- a/rules/windows/privilege_escalation_unquoted_service_path.toml
+++ b/rules/windows/privilege_escalation_unquoted_service_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/13"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,41 @@ process where host.os.type == "windows" and event.type == "start" and
     process.executable regex """(C:\\Program Files \(x86\)\\|C:\\Program Files\\)\w+.exe"""
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Exploitation of an Unquoted Service Path Vulnerability
+
+Unquoted service paths in Windows can be exploited by adversaries to escalate privileges. When a service path lacks quotes, Windows may execute a malicious executable placed in a higher-level directory. The detection rule identifies suspicious processes starting from common unquoted paths, signaling potential exploitation attempts. This helps in early detection and mitigation of privilege escalation threats.
+
+### Possible investigation steps
+
+- Review the process executable path to confirm if it matches the patterns specified in the query, such as "?:\\\\Program.exe" or executables within "C:\\\\Program Files (x86)\\\\" or "C:\\\\Program Files\\\\".
+- Check the parent process of the suspicious executable to determine how it was initiated and assess if it aligns with expected behavior.
+- Investigate the file creation and modification timestamps of the suspicious executable to identify any recent changes that could indicate malicious activity.
+- Analyze the user account associated with the process start event to determine if it has the necessary privileges and if the activity is consistent with the user's typical behavior.
+- Examine the system's event logs for any related activities or anomalies around the time the suspicious process was started, such as other process executions or file modifications.
+- Cross-reference the executable's hash with known threat intelligence databases to identify if it is associated with any known malware or suspicious activity.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they temporarily create executables in common unquoted paths. Users can create exceptions for known software update processes to prevent unnecessary alerts.
+- System administrators might use scripts or tools that inadvertently place executables in unquoted paths for legitimate purposes. Identifying and documenting these tools can help in setting up exclusions.
+- Some enterprise applications may have legitimate executables in unquoted paths due to legacy configurations. Review and verify these applications, then configure exceptions for them to avoid false positives.
+- Regularly scheduled tasks or maintenance scripts that run from unquoted paths can be mistaken for malicious activity. Ensure these tasks are documented and excluded from the rule if they are verified as safe.
+- Security tools or monitoring software might simulate or test unquoted path vulnerabilities as part of their operations. Confirm these activities with the security team and exclude them if they are part of routine security assessments.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those matching the unquoted service path pattern.
+- Conduct a thorough review of the service configurations on the affected system to identify and correct any unquoted service paths. Ensure all service paths are properly quoted to prevent future exploitation.
+- Remove any unauthorized executables found in higher-level directories that could be used to exploit the unquoted service path vulnerability.
+- Restore the affected system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- 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 enhanced monitoring and logging for similar suspicious activities across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
index 99d0b03ae20..6b0325334ab 100644
--- a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
+++ b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,43 @@ process where host.os.type == "windows" and event.type == "start" and
     "?:\\Program Files (x86)\\GPLGS\\gswin32c.exe"
  )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Print Spooler Child Process
+
+The Print Spooler service, integral to Windows environments, manages print jobs and interactions with printers. Adversaries may exploit vulnerabilities in this service to escalate privileges, gaining unauthorized access or control. The detection rule identifies suspicious child processes spawned by the Print Spooler, excluding known legitimate processes, to flag potential exploitation attempts, focusing on unusual command lines and integrity levels.
+
+### Possible investigation steps
+
+- Review the process details to identify the unusual child process spawned by spoolsv.exe, focusing on the process name and command line arguments to understand its purpose and potential malicious intent.
+- Check the integrity level of the process using the fields process.Ext.token.integrity_level_name or winlog.event_data.IntegrityLevel to confirm if it is running with elevated privileges, which could indicate an exploitation attempt.
+- Investigate the parent-child relationship by examining the process tree to determine if there are any other suspicious processes associated with the same parent process, spoolsv.exe.
+- Cross-reference the process executable path against known legitimate software paths to ensure it is not a false positive, especially if the executable is not listed in the exclusion paths.
+- Analyze recent system logs and security events around the time of the alert to identify any other anomalous activities or patterns that could be related to the potential exploitation attempt.
+- If the process is confirmed suspicious, isolate the affected system to prevent further exploitation and conduct a deeper forensic analysis to understand the scope and impact of the incident.
+
+### False positive analysis
+
+- Legitimate print-related processes like splwow64.exe, PDFCreator.exe, and acrodist.exe may trigger alerts. These are excluded in the rule to prevent false positives.
+- System processes such as msiexec.exe, route.exe, and WerFault.exe are known to be legitimate child processes of the Print Spooler and are excluded to reduce false alerts.
+- Commands involving net.exe for starting or stopping services are common in administrative tasks and are excluded to avoid unnecessary alerts.
+- Command-line operations involving cmd.exe or powershell.exe that reference .spl files or system paths are often legitimate and are excluded to minimize false positives.
+- Network configuration changes using netsh.exe, such as adding port openings or rules, are typical in network management and are excluded to prevent false alerts.
+- Registration of PrintConfig.dll via regsvr32.exe is a known legitimate operation and is excluded to avoid false positives.
+- Executables from known paths like CutePDF Writer and GPLGS are excluded to prevent alerts from common, non-threatening applications.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious child processes spawned by the Print Spooler service that do not match known legitimate processes or command lines.
+- Conduct a thorough review of the system's security logs to identify any unauthorized access or privilege escalation attempts related to the Print Spooler service.
+- Apply the latest security patches and updates to the Windows operating system and specifically to the Print Spooler service to mitigate known vulnerabilities.
+- Restore the system from a clean backup if any unauthorized changes or malicious activities are confirmed.
+- Monitor the system closely for any recurrence of similar suspicious activities, ensuring enhanced logging and alerting are in place for spoolsv.exe and its child processes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
index 12e5a8b5448..cb92d3708ce 100644
--- a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
+++ b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,42 @@ process where host.os.type == "windows" and event.type == "start" and
     ) and process.parent.args : "imgsvc"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Service Host Child Process - Childless Service
+
+Service Host (svchost.exe) is a critical Windows process that hosts multiple services to optimize resource usage. Typically, certain services under svchost.exe do not spawn child processes. Adversaries exploit this by injecting malicious code to execute unauthorized processes, evading detection. The detection rule identifies anomalies by monitoring child processes of traditionally childless services, flagging potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process details of the child process, including its name and executable path, to determine if it is a known legitimate process or potentially malicious.
+- Examine the parent process arguments to confirm if the svchost.exe instance is associated with a service that traditionally does not spawn child processes, as listed in the query.
+- Check the process creation time and correlate it with any other suspicious activities or alerts in the system around the same timeframe.
+- Investigate the user account under which the child process was executed to assess if it has the necessary privileges and if the activity aligns with typical user behavior.
+- Analyze any network connections or file modifications made by the child process to identify potential malicious actions or data exfiltration attempts.
+- Cross-reference the child process with known false positives listed in the query to rule out benign activities.
+- Utilize threat intelligence sources to determine if the child process or its executable path is associated with known malware or attack patterns.
+
+### False positive analysis
+
+- Processes like WerFault.exe, WerFaultSecure.exe, and wermgr.exe are known to be legitimate Windows error reporting tools that may occasionally be spawned by svchost.exe. To handle these, add them to the exclusion list in the detection rule to prevent unnecessary alerts.
+- RelPost.exe associated with WdiSystemHost can be a legitimate process in certain environments. If this is a common occurrence, consider adding an exception for this executable when it is spawned by WdiSystemHost.
+- Rundll32.exe executing winethc.dll with ForceProxyDetectionOnNextRun arguments under WdiServiceHost may be a benign operation in some network configurations. If verified as non-malicious, exclude this specific process and argument combination.
+- Processes under the imgsvc service, such as lexexe.exe from Kodak directories, might be legitimate in environments using specific imaging software. Validate these occurrences and exclude them if they are confirmed to be non-threatening.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious child processes spawned by svchost.exe that are not typically associated with legitimate operations, as identified in the alert.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code or associated malware.
+- Review and analyze the process tree and parent-child relationships to understand the scope of the compromise and identify any additional affected processes or systems.
+- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and logging for svchost.exe and related processes to detect similar anomalies in the future, ensuring that alerts are configured to notify the appropriate personnel promptly."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_ppid_spoofing.toml b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
index 57c9603c900..b00731f8421 100644
--- a/rules/windows/privilege_escalation_via_ppid_spoofing.toml
+++ b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -95,6 +95,41 @@ process where host.os.type == "windows" and event.action == "start" and
     )
  )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privileges Elevation via Parent Process PID Spoofing
+
+Parent Process ID (PPID) spoofing is a technique where adversaries manipulate the PPID of a process to disguise its origin, often to bypass security measures or gain elevated privileges. This is particularly concerning in Windows environments where processes can inherit permissions from their parent. The detection rule identifies suspicious process creation patterns, such as unexpected PPID values and elevated user IDs, while filtering out known legitimate processes and trusted signatures, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process creation event details, focusing on the process.parent.Ext.real.pid and user.id fields to confirm if the PPID spoofing led to privilege escalation to SYSTEM.
+- Examine the process.executable and process.parent.executable paths to determine if the process is known or expected in the environment, and check against the list of excluded legitimate processes.
+- Investigate the process.code_signature fields to verify if the process is signed by a trusted entity and if the signature is valid, especially if the process is not excluded by the rule.
+- Check the historical activity of the involved user.id and process.parent.executable to identify any unusual patterns or recent changes in behavior.
+- Correlate the alert with other security events or logs to identify any related suspicious activities or potential lateral movement attempts within the network.
+
+### False positive analysis
+
+- Processes related to Windows Error Reporting such as WerFault.exe and Wermgr.exe can trigger false positives. These are legitimate system processes and can be excluded by verifying their signatures and paths.
+- Logon utilities like Utilman.exe spawning processes such as osk.exe, Narrator.exe, or Magnify.exe may appear suspicious but are often legitimate. Exclude these by confirming their usage context and ensuring they are executed by trusted users.
+- Third-party software like TeamViewer, Cisco WebEx, and Dell Inc. may cause false positives due to their legitimate use of process creation. Verify the code signature and trust status to exclude these processes.
+- Windows Update processes involving MpSigStub.exe and wuauclt.exe can be mistakenly flagged. Confirm these are part of regular update activities and exclude them based on their known paths and parent processes.
+- Remote support and management tools such as LogMeIn, GoToAssist, and Chrome Remote Desktop may be flagged. Ensure these are installed and used by authorized personnel and exclude them by their executable paths.
+- Netwrix Corporation's processes like adcrcpy.exe may be flagged if they are part of legitimate auditing activities. Verify the code signature and exclude these processes if they are part of authorized Netwrix Auditor operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the alert, especially those with spoofed PPIDs or elevated privileges, to stop potential malicious activities.
+- Review and revoke any unauthorized user accounts or privileges that may have been created or escalated during the incident.
+- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms.
+- Restore the system from a known good backup if necessary, ensuring that all malicious artifacts are removed and system integrity is maintained.
+- Implement additional monitoring and logging on the affected system and network to detect any recurrence of similar activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
index 05672066a7b..54db661628b 100644
--- a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
+++ b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/13"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,40 @@ file where host.os.type == "windows" and event.action : "Pipe Created*" and
  /* normal sysmon named pipe creation events truncate the pipe keyword */
   file.name : "\\*\\Pipe\\*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Privilege Escalation via Rogue Named Pipe Impersonation
+
+Named pipes in Windows facilitate inter-process communication, allowing data exchange between processes. Adversaries exploit this by creating rogue named pipes, tricking privileged processes into connecting and executing malicious actions under elevated privileges. The detection rule identifies suspicious named pipe creation events, focusing on patterns indicative of impersonation attempts, thus flagging potential privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the event logs for the specific named pipe creation event identified by the query, focusing on the file.name field to determine the exact named pipe path and assess its legitimacy.
+- Correlate the event with the process that created the named pipe by examining related process creation logs, identifying the process ID and executable responsible for the action.
+- Investigate the user context under which the named pipe was created to determine if it aligns with expected behavior or if it indicates potential misuse of privileges.
+- Check for any recent changes or anomalies in the system's configuration or user accounts that could suggest unauthorized access or privilege escalation attempts.
+- Analyze historical data for similar named pipe creation events to identify patterns or repeated attempts that could indicate a persistent threat or ongoing attack.
+
+### False positive analysis
+
+- Legitimate software or system processes may create named pipes that match the detection pattern. Regularly review and whitelist known benign processes that frequently create named pipes to reduce noise.
+- System management tools and monitoring software might generate named pipe creation events as part of their normal operation. Identify these tools and exclude their events from triggering alerts.
+- Custom in-house applications that use named pipes for inter-process communication can trigger false positives. Work with development teams to document these applications and create exceptions for their activity.
+- Scheduled tasks or scripts that run with elevated privileges and create named pipes could be mistaken for malicious activity. Ensure these tasks are documented and excluded from the detection rule.
+- Security software or endpoint protection solutions may use named pipes for legitimate purposes. Verify these activities and adjust the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes associated with the rogue named pipe to halt any ongoing malicious activities.
+- Conduct a thorough review of the system's event logs, focusing on named pipe creation events, to identify any other potentially compromised processes or systems.
+- Reset credentials for any accounts that may have been exposed or used in the privilege escalation attempt to prevent further unauthorized access.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for named pipe creation events across the network to detect and respond to similar threats in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_via_token_theft.toml b/rules/windows/privilege_escalation_via_token_theft.toml
index 4e4c0049a82..a4a4b6dd1b3 100644
--- a/rules/windows/privilege_escalation_via_token_theft.toml
+++ b/rules/windows/privilege_escalation_via_token_theft.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -98,6 +98,42 @@ not (process.parent.executable : "?\\Windows\\System32\\spoolsv.exe" and
                  "Cisco WebEx LLC", 
                  "Dell Inc"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Created with an Elevated Token
+
+In Windows environments, processes can be created with elevated tokens to perform tasks requiring higher privileges. Adversaries exploit this by impersonating system-level binaries to escalate privileges and bypass security controls. The detection rule identifies such activities by monitoring process creation events, focusing on those initiated by privileged binaries and excluding known benign processes. This helps in identifying unauthorized privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process creation event details to identify the specific executable and its parent process, focusing on the fields process.executable and process.Ext.effective_parent.executable.
+- Check the user.id field to confirm if the process was created with the SYSTEM user ID (S-1-5-18), indicating elevated privileges.
+- Investigate the parent process executable path to determine if it matches any known privileged Microsoft native binaries, which could be targets for token theft.
+- Examine the process code signature details, especially process.code_signature.trusted and process.code_signature.subject_name, to verify if the executable is signed by a trusted entity or if it matches any excluded signatures.
+- Correlate the process creation event with other security logs and alerts to identify any related suspicious activities or patterns that might indicate privilege escalation attempts.
+- Assess the context and timing of the event to determine if it aligns with legitimate administrative tasks or if it appears anomalous in the environment.
+
+### False positive analysis
+
+- Utility Manager in Windows running in debug mode can trigger false positives. To handle this, exclude processes where both the effective parent and parent executables are Utilman.exe with the /debug argument.
+- Windows print spooler service correlated with Access Intelligent Form may cause false alerts. Exclude processes where the parent executable is spoolsv.exe and the process executable is LaunchCreate.exe under Access Intelligent Form.
+- Windows error reporting executables like WerFault.exe can be mistakenly flagged. Exclude these specific executables from the rule to prevent unnecessary alerts.
+- Windows updates initiated by TiWorker.exe running with elevated privileges can be misidentified. Exclude processes where TiWorker.exe is the parent and the process executable matches known update-related paths.
+- Additional parent executables that typically run with elevated privileges, such as AtBroker.exe and svchost.exe, can lead to false positives. Exclude these parent executables from the rule to reduce noise.
+- Trusted Windows binaries with specific signature names, such as those from TeamViewer or Cisco WebEx, may be incorrectly flagged. Exclude processes with a trusted code signature and matching subject names to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule that are running with elevated privileges, especially those not matching known benign processes.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify and disable any unauthorized accounts or privilege escalations.
+- Restore the affected system from a known good backup to ensure any malicious changes are reverted, and verify the integrity of the system post-restoration.
+- Implement additional monitoring on the affected system and network to detect any further attempts at privilege escalation or token manipulation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Review and update endpoint protection and detection capabilities to ensure they are configured to detect similar threats in the future, leveraging the MITRE ATT&CK framework for guidance on Access Token Manipulation (T1134)."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
index 758b1a47d47..39bd669b6fb 100644
--- a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
+++ b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/02/07"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,41 @@ configuration where host.os.type == "windows" and
     "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" "
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows Service Installed via an Unusual Client
+
+Windows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations initiated by atypical processes, excluding known legitimate services. This helps in spotting potential privilege escalation attempts by monitoring unusual client activity.
+
+### Possible investigation steps
+
+- Review the event logs to identify the specific client process that initiated the service installation by examining the winlog.event_data.ClientProcessId and winlog.event_data.ParentProcessId fields.
+- Investigate the parent process associated with the unusual client process to determine if it is a known legitimate application or potentially malicious.
+- Check the winlog.event_data.ServiceFileName to verify the path and name of the service file, ensuring it is not a known legitimate service excluded in the query.
+- Analyze the timeline of events around the service installation to identify any preceding suspicious activities or related alerts that might indicate a broader attack.
+- Conduct a reputation check on the client process and service file using threat intelligence sources to assess if they are associated with known malicious activities.
+- Examine the system for any additional indicators of compromise, such as unexpected network connections or changes to critical system files, that may suggest privilege escalation or lateral movement attempts.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they create services using unusual client processes. To manage this, identify and whitelist these processes in the detection rule to prevent unnecessary alerts.
+- System management tools like Veeam and PDQ Inventory are already excluded, but other similar tools might not be. Regularly review and update the exclusion list to include any additional legitimate tools used in your environment.
+- Custom scripts or administrative tools that create services for maintenance or monitoring purposes can also cause false positives. Document these scripts and consider adding them to the exclusion list if they are verified as safe.
+- Temporary or one-time service installations for troubleshooting or testing can be mistaken for threats. Ensure that such activities are logged and communicated to the security team to avoid confusion and unnecessary alerts.
+- Changes in system configurations or updates to existing software might alter the behavior of legitimate processes, causing them to be flagged. Regularly review and adjust the detection rule to accommodate these changes while maintaining security integrity.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate the suspicious service and any associated processes identified by the alert to stop potential privilege escalation or malicious activity.
+- Conduct a thorough review of the service's configuration and associated files to identify any unauthorized changes or malicious code.
+- Restore any altered or compromised system files from a known good backup to ensure system integrity.
+- Change all administrator and SYSTEM account passwords on the affected system and any connected systems to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring and logging on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules/windows/privilege_escalation_wpad_exploitation.toml b/rules/windows/privilege_escalation_wpad_exploitation.toml
index 4ce6d2b03c5..e331e08f58b 100644
--- a/rules/windows/privilege_escalation_wpad_exploitation.toml
+++ b/rules/windows/privilege_escalation_wpad_exploitation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "development"
-updated_date = "2024/04/08"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,40 @@ sequence with maxspan=5s
   [process where host.os.type == "windows" and event.type == "start" and
      process.parent.name : "svchost.exe"] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WPAD Service Exploit
+
+The Web Proxy Auto-Discovery Protocol (WPAD) helps devices on a network automatically find a proxy server. Adversaries can exploit WPAD by injecting malicious scripts into the service, potentially compromising systems. The detection rule identifies suspicious WPAD activity by monitoring specific processes and network behaviors, such as DNS queries and unusual DLL loads, to flag potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process tree for the svchost.exe instance identified in the alert to understand its parent and child processes, focusing on any unusual or unexpected behavior.
+- Analyze DNS query logs for the domain "wpad" to identify any suspicious or unauthorized requests, and cross-reference with known malicious domains.
+- Examine network traffic logs for outgoing connections on port 80 from the svchost.exe process to detect any unauthorized data exfiltration or communication with suspicious external IP addresses.
+- Investigate the loading of jscript.dll by svchost.exe to determine if there are any anomalies or signs of script execution that could indicate malicious activity.
+- Check for any recent changes or anomalies in the user account associated with the LOCAL SERVICE domain, as this could indicate privilege escalation attempts.
+
+### False positive analysis
+
+- Legitimate network services using WPAD may trigger alerts if they perform DNS queries for "wpad" or communicate over port 80. To manage this, identify and whitelist known benign services that frequently use WPAD.
+- Routine system updates or software installations might cause svchost.exe to load jscript.dll, leading to false positives. Monitor and document regular update schedules and exclude these time frames from triggering alerts.
+- Some enterprise environments use custom scripts or applications that interact with WPAD for legitimate purposes. Review and document these applications, then create exceptions for their known behaviors to prevent unnecessary alerts.
+- In environments with frequent DNS changes or testing, legitimate DNS queries for WPAD might be flagged. Establish a baseline of normal DNS activity and adjust the detection rule to accommodate expected patterns.
+- If svchost.exe is commonly used by other legitimate processes in your network, consider refining the rule to include additional context or attributes that distinguish malicious from benign activity.
+
+### Response and remediation
+
+- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the attacker.
+- Terminate any suspicious svchost.exe processes identified in the alert to stop the execution of potentially malicious scripts.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or scripts.
+- Review and reset any potentially compromised credentials, especially those associated with the LOCAL SERVICE account, to prevent unauthorized access.
+- Apply security patches and updates to the operating system and all software to mitigate known vulnerabilities that could be exploited by similar attacks.
+- Monitor network traffic for any further suspicious DNS queries or unusual outbound connections, particularly those involving the WPAD service, to detect any ongoing or new threats.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to ensure comprehensive remediation and recovery efforts."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_archive_data_zip_imageload.toml b/rules_building_block/collection_archive_data_zip_imageload.toml
index 445af055e36..9a6070c5164 100644
--- a/rules_building_block/collection_archive_data_zip_imageload.toml
+++ b/rules_building_block/collection_archive_data_zip_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,41 @@ library where host.os.type == "windows" and event.action == "load" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Compression DLL Loaded by Unusual Process
+
+Compression DLLs, like those in the .NET framework, facilitate data compression and decompression, crucial for efficient data storage and transfer. Adversaries exploit these DLLs to compress and encrypt data before exfiltration, evading detection. The detection rule identifies unusual processes loading these DLLs, excluding trusted applications, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if it is indeed unusual or potentially malicious, focusing on paths not listed in the exclusion criteria.
+- Check the process code signature to verify if it is trusted or if there are any anomalies in the signature that could indicate tampering.
+- Investigate the user account associated with the process, especially if it is not one of the trusted system accounts (S-1-5-18, S-1-5-20), to assess if the account has been compromised.
+- Analyze the parent process of the flagged process to understand how it was initiated and if there are any suspicious activities leading up to the DLL load.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+- Examine network activity from the host around the time of the DLL load to detect any potential data exfiltration attempts.
+
+### False positive analysis
+
+- Trusted applications not covered by the exclusion list may trigger false positives. Regularly review and update the exclusion list to include additional trusted applications that are known to load compression DLLs.
+- System administrators or developers using custom scripts or tools that load compression DLLs for legitimate purposes might cause alerts. Consider adding these specific processes to the exclusion list if they are verified as non-malicious and signed by a trusted code signature.
+- Automated software updates or installations that temporarily load compression DLLs can be mistaken for suspicious activity. Monitor these events and, if they are routine and verified, adjust the rule to exclude these specific update processes.
+- Security or monitoring tools that perform legitimate data compression as part of their operations may be flagged. Ensure these tools are signed by a trusted code signature and add them to the exclusion list if necessary.
+- User-initiated processes that involve data compression for legitimate business purposes might trigger alerts. Educate users on the types of activities that could cause alerts and adjust the rule to exclude these processes if they are frequent and verified.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration or lateral movement by the adversary.
+- Terminate the suspicious process that loaded the compression DLL to halt any ongoing malicious activity.
+- Conduct a forensic analysis of the affected system to identify any compressed or encrypted files that may have been prepared for exfiltration.
+- Restore any compromised files from a known good backup to ensure data integrity and availability.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary.
+- Monitor network traffic for any signs of data exfiltration attempts or communication with known malicious IP addresses.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_common_compressed_archived_file.toml b/rules_building_block/collection_common_compressed_archived_file.toml
index 8cbf9f55494..149b31b6374 100644
--- a/rules_building_block/collection_common_compressed_archived_file.toml
+++ b/rules_building_block/collection_common_compressed_archived_file.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = "endpoint"
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -110,6 +110,40 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
    )
  )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File Compressed or Archived into Common Format
+
+File compression and archiving are essential for efficient data storage and transfer, using formats like ZIP, RAR, and 7-Zip. However, adversaries exploit these technologies to obfuscate malicious files or stage data for exfiltration. The detection rule identifies suspicious compression activities by monitoring file creation or modification events, excluding trusted processes, and focusing on specific file signatures indicative of compression or archiving.
+
+### Possible investigation steps
+
+- Review the process executable and its code signature details to determine if the process is expected or potentially malicious. Pay attention to processes not listed in the exclusions, such as unknown or untrusted executables.
+- Examine the user ID associated with the event to identify if the activity was performed by a legitimate user or an unauthorized account. Investigate any anomalies in user behavior.
+- Analyze the file path and name to understand the context of the compressed or archived file. Check if the file location is typical for such activities or if it appears suspicious.
+- Investigate the file header bytes to confirm the type of compression or archive format used. This can help identify if the format is commonly used in the environment or if it is unusual.
+- Check for any recent changes or creations of similar files on the host to identify patterns or repeated activities that might indicate malicious intent.
+- Correlate the event with other security alerts or logs from the same host or user to gather additional context and determine if this is part of a larger attack or data exfiltration attempt.
+
+### False positive analysis
+
+- Trusted applications like Firefox, Wazuh Agent, Microsoft Office, OneDrive, Dropbox, Dell SupportAssist, and IIS may trigger false positives when they perform legitimate compression or archiving activities. Users can mitigate these by ensuring the processes are correctly signed and trusted, and by adding exceptions for these applications in the rule configuration.
+- Files with specific extensions or paths, such as those associated with OneDrive logs or IIS temporary compressed files, may be flagged. Users should review these paths and extensions and consider excluding them if they are part of regular, non-malicious operations.
+- Regular updates or operations by trusted software, such as Windows Update or Dell SupportAssist, might be misidentified as suspicious. Users should verify the legitimacy of these operations and adjust the rule to exclude these known, safe activities.
+- If certain processes are frequently involved in legitimate compression activities, users can add these processes to the exception list, provided they are verified as safe and necessary for business operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration or lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are not part of the trusted processes list, especially those involved in file compression or archiving.
+- Conduct a thorough scan of the isolated system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software.
+- Review and analyze the compressed or archived files identified in the alert to determine if they contain sensitive data or malware, and take appropriate action based on the findings.
+- Restore any affected files from a known good backup if they have been altered or corrupted by the malicious activity.
+- 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 additional monitoring and alerting for similar file compression activities across the network to enhance detection and prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
index 9ac96708907..a8adbd20510 100644
--- a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
+++ b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,40 @@ file where host.os.type == "windows" and event.type == "creation" and
   not file.path : "?:\\$RECYCLE.BIN\\*\\*" and
   not file.name : "desktop.ini"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File Staged in Root Folder of Recycle Bin
+
+The Recycle Bin in Windows is designed to temporarily store deleted files, typically organized in subdirectories. Adversaries may exploit this by placing files directly in the root to prepare for data exfiltration or to bypass security measures. The detection rule identifies such anomalies by flagging file creations in the root, excluding typical system files, thus highlighting potential malicious staging activities.
+
+### Possible investigation steps
+
+- Review the file path to confirm it matches the pattern "?:\\\\$RECYCLE.BIN\\\\*" and ensure it is not a typical system file like "desktop.ini".
+- Investigate the file creation event to determine the user account associated with the action, checking for any unusual or unauthorized activity.
+- Examine the file's metadata and properties, such as creation time, size, and file type, to assess its legitimacy and potential risk.
+- Check for any recent or related alerts involving the same user or host to identify patterns or repeated suspicious behavior.
+- Analyze the file's content, if accessible, to determine if it contains sensitive or exfiltration-worthy data.
+- Review system logs and other security tools for any signs of data exfiltration attempts or other malicious activities around the time of the file creation.
+
+### False positive analysis
+
+- System maintenance tools or scripts may create files in the root of the Recycle Bin for temporary storage. Review the source of the file creation and consider excluding known maintenance tools from the detection rule.
+- Backup or recovery software might use the Recycle Bin's root for staging files during operations. Verify the software's behavior and add exceptions for trusted applications.
+- User actions, such as manual file management or organization, can result in files being placed in the root. Educate users on proper file management practices and consider excluding specific user actions if they are verified as non-malicious.
+- Automated processes or scripts that are part of legitimate business operations may inadvertently use the Recycle Bin's root. Identify these processes and create exceptions to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential data exfiltration or further malicious activity.
+- Verify the legitimacy of the file(s) found in the root of the Recycle Bin by cross-referencing with known good files and recent user activity.
+- If the file is confirmed malicious, remove it from the Recycle Bin and perform a full system scan using updated antivirus or endpoint detection and response (EDR) tools to identify and eliminate any additional threats.
+- Review recent user and system activity logs to identify any unauthorized access or actions that may have led to the file's creation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack.
+- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of this activity.
+- Update security policies and access controls to limit the ability of users and processes to write files directly to the root of the Recycle Bin, if feasible."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_outlook_email_archive.toml b/rules_building_block/collection_outlook_email_archive.toml
index 921f2861096..364c3087bc3 100644
--- a/rules_building_block/collection_outlook_email_archive.toml
+++ b/rules_building_block/collection_outlook_email_archive.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,40 @@ process where host.os.type == "windows" and event.type == "start" and process.ar
         process.args : "*davclnt.dll,DavSetCookie*"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Accessing Outlook Data Files
+
+Outlook data files, such as OST and PST, store emails and other data locally on Windows systems. Adversaries may target these files to collect sensitive information, bypassing email server security. The detection rule identifies suspicious processes accessing these files, excluding legitimate Outlook operations, to flag potential unauthorized access or data exfiltration attempts.
+
+### Possible investigation steps
+
+- Review the process details to identify the process name and arguments that triggered the alert, ensuring it matches the criteria of accessing OST or PST files without being a legitimate Outlook operation.
+- Investigate the parent process of the suspicious activity to determine if it was initiated by a legitimate application or a potentially malicious one.
+- Check the user account associated with the process to assess if the activity aligns with the user's typical behavior or if it appears suspicious.
+- Analyze the timeline of events to see if there are any other related alerts or activities around the same time that could indicate a broader attack or data exfiltration attempt.
+- Examine the network activity of the host to identify any unusual outbound connections that might suggest data exfiltration following the access of Outlook data files.
+
+### False positive analysis
+
+- Legitimate backup software may access OST and PST files as part of routine data backup processes. To handle this, identify and exclude these backup processes by adding them to the exception list in the detection rule.
+- Antivirus or endpoint protection software might scan Outlook data files during regular system checks. Review the processes associated with these scans and exclude them if they are verified as non-threatening.
+- System maintenance tools or scripts that perform file indexing or system optimization could trigger the rule. Determine if these tools are part of regular maintenance and exclude them accordingly.
+- Custom scripts or applications developed in-house that interact with Outlook data files for legitimate business purposes should be reviewed and excluded if they are deemed safe.
+- Occasionally, third-party email clients or plugins may access Outlook data files. Verify the legitimacy of these applications and exclude them if they are necessary for business operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule that are accessing Outlook data files, ensuring that legitimate Outlook operations are not disrupted.
+- Conduct a forensic analysis of the affected system to determine the extent of the compromise, focusing on identifying any data that may have been accessed or exfiltrated.
+- Change passwords and review access permissions for any accounts that may have been compromised as a result of the unauthorized access to Outlook data files.
+- Restore any corrupted or compromised Outlook data files from a known good backup to ensure data integrity and continuity of operations.
+- Implement additional monitoring and alerting for similar suspicious activities, focusing on processes accessing OST and PST files, to enhance detection capabilities.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the scope of the threat is beyond the current team's capacity to handle effectively."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/collection_posh_compression.toml b/rules_building_block/collection_posh_compression.toml
index 5b1150f75d0..dec4c7d5506 100644
--- a/rules_building_block/collection_posh_compression.toml
+++ b/rules_building_block/collection_posh_compression.toml
@@ -5,7 +5,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 
 
 [rule]
@@ -70,6 +70,40 @@ not powershell.file.script_block_text : (
 ) and
 not file.directory : "C:\Program Files\Microsoft Dependency Agent\plugins\lib"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Archive Compression Capabilities
+
+PowerShell, a powerful scripting language in Windows, includes capabilities for file compression using various methods like ZipFile and GZipStream. While these are useful for legitimate data management, adversaries exploit them to compress and encrypt data for exfiltration. The detection rule identifies suspicious use of compression-related cmdlets and methods, excluding known benign activities, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify the specific compression methods or cmdlets used, such as "IO.Compression.ZipFile" or "Compress-Archive".
+- Check the process execution details, including the parent process, to understand the context in which the PowerShell script was executed and identify any potentially malicious parent processes.
+- Investigate the user account under which the PowerShell script was executed to determine if it aligns with expected behavior or if it might be compromised.
+- Examine the file paths and directories involved in the compression activity to identify any unusual or sensitive data locations that might indicate data exfiltration attempts.
+- Correlate the alert with other security events or logs, such as network traffic or file access logs, to identify any related suspicious activities or data transfers.
+- Verify if the alert corresponds to any known benign activities or exclusions, such as those specified in the query, to rule out false positives.
+
+### False positive analysis
+
+- Legitimate software updates or diagnostics tools, such as Lenovo's diagnostics, may use compression methods. Exclude these by adding specific paths or script block text to the exception list.
+- Automation tools like Ansible may trigger the rule during routine operations. Identify and exclude these by recognizing unique script block text patterns associated with these tools.
+- System management or monitoring agents, such as the Microsoft Dependency Agent, might perform compression tasks. Exclude their known directories or script block text to prevent false alerts.
+- Regular administrative tasks that involve file compression for backup or archiving purposes can be excluded by identifying and whitelisting specific script block text or directories used by trusted administrators.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration and limit the adversary's access.
+- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activities.
+- Conduct a thorough review of the compressed files and directories mentioned in the alert to determine if sensitive data was involved and assess the extent of potential data loss.
+- Restore any compromised or altered files from backups, ensuring that the restored data is free from malicious modifications.
+- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts at data compression or exfiltration.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats in the future."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/command_and_control_bitsadmin_activity.toml b/rules_building_block/command_and_control_bitsadmin_activity.toml
index 2b54cbba541..6590f57eaf7 100644
--- a/rules_building_block/command_and_control_bitsadmin_activity.toml
+++ b/rules_building_block/command_and_control_bitsadmin_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,41 @@ process where host.os.type == "windows" and event.type == "start" and
    )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Bitsadmin Activity
+
+Windows Background Intelligent Transfer Service (BITS) facilitates low-bandwidth file transfers, often used for updates. Adversaries exploit BITS to persistently download and execute malicious payloads, leveraging its ability to operate in the background. The detection rule identifies suspicious BITS usage by monitoring specific command-line arguments associated with bitsadmin.exe and PowerShell, flagging potential misuse indicative of command and control activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious command-line arguments associated with bitsadmin.exe or powershell.exe, such as "*Transfer*", "*Create*", "AddFile", or "*Start-BitsTransfer*".
+- Check the parent process of bitsadmin.exe or powershell.exe to determine if it was spawned by a legitimate application or a potentially malicious one.
+- Investigate the network connections established by the host during the time of the alert to identify any unusual or unauthorized external communications.
+- Examine the file paths and file names involved in the BITS transfer to assess if they are known or potentially malicious files.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
+- Review the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+
+### False positive analysis
+
+- Routine system updates or legitimate software installations may trigger BITS activity. Users can create exceptions for known update processes or trusted software installations to prevent false alerts.
+- Automated scripts or administrative tasks using PowerShell to manage BITS for legitimate purposes might be flagged. Identify and whitelist these scripts if they are verified as non-malicious.
+- Internal IT operations that utilize BITS for file transfers within the organization could be misidentified as threats. Document and exclude these operations from monitoring if they are part of regular IT maintenance.
+- Software distribution tools that rely on BITS for deploying applications across the network may cause false positives. Ensure these tools are recognized and excluded from the detection rule.
+- Frequent use of BITS for legitimate data synchronization tasks, such as cloud backups, should be reviewed and excluded if they are part of standard business operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further command and control communication and potential lateral movement.
+- Terminate any suspicious BITS jobs using bitsadmin.exe or PowerShell commands identified in the alert to stop ongoing malicious file transfers.
+- 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 remnants.
+- Review and analyze the BITS job history and PowerShell logs to identify any additional indicators of compromise (IOCs) or related malicious activities.
+- Restore the system from a known good backup if malicious activity has compromised system integrity or critical files.
+- Implement network-level controls to block known malicious IP addresses or domains associated with the detected command and control activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
index 1eed992f989..3837808b8c6 100644
--- a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
+++ b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
@@ -5,7 +5,7 @@ integration = ["endpoint", "windows", "system"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,40 @@ process where host.os.type == "windows" and event.type == "start" and
    (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and
    process.args : "list" and process.args : "/text*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft IIS Service Account Password Dumped
+
+Microsoft Internet Information Services (IIS) is a web server platform used to host websites and applications. AppCmd is a command-line tool for managing IIS configurations, including application pools. Adversaries with access to IIS can exploit AppCmd to extract service account passwords, potentially leading to credential theft. The detection rule identifies suspicious use of AppCmd by monitoring process execution patterns indicative of password dumping activities, thereby alerting security teams to potential credential access threats.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of "appcmd.exe" in the process name or original file name, and check if the process arguments include "list" and "/text*".
+- Identify the user account under which the "appcmd.exe" process was executed to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.
+- Examine the source IP address and host from which the "appcmd.exe" process was initiated to assess if it is a known and trusted source or if it requires further scrutiny.
+- Check for any recent changes or anomalies in the IIS configuration or application pools that might suggest tampering or unauthorized access.
+- Investigate any associated web shell activity or other indicators of compromise on the IIS server that could have facilitated the unauthorized use of AppCmd.
+- Correlate this event with other security alerts or logs to identify any patterns or additional suspicious activities that might indicate a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks using AppCmd may trigger alerts. If AppCmd is regularly used for legitimate configuration management, consider excluding these specific process executions by identifying the responsible user accounts or scheduled tasks.
+- Automated scripts that manage IIS configurations and use AppCmd with similar arguments might be flagged. Review and whitelist these scripts by verifying their source and ensuring they are part of authorized operations.
+- Development or testing environments where AppCmd is frequently used for debugging or configuration purposes can generate false positives. Implement exclusions for these environments by filtering based on hostnames or IP addresses.
+- Security tools or monitoring solutions that simulate attacks for testing purposes might mimic the behavior detected by this rule. Coordinate with security teams to identify and exclude these benign activities from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected IIS server from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes related to appcmd.exe that are currently running on the server to halt any ongoing credential dumping activities.
+- Change the passwords for all service accounts associated with the IIS application pools to prevent unauthorized access using potentially compromised credentials.
+- Conduct a thorough review of IIS server logs and other relevant system logs to identify any additional indicators of compromise or unauthorized access attempts.
+- Restore the IIS server from a known good backup taken before the incident, ensuring that all patches and security updates are applied.
+- Implement network segmentation to limit access to the IIS server, allowing only necessary traffic and users to interact with it.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_mdmp_file_creation.toml b/rules_building_block/credential_access_mdmp_file_creation.toml
index 938d4cba5ab..b1fe8349602 100644
--- a/rules_building_block/credential_access_mdmp_file_creation.toml
+++ b/rules_building_block/credential_access_mdmp_file_creation.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,41 @@ file where host.os.type == "windows" and event.type == "creation" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Credential Access via Memory Dump File Creation
+
+Memory dump files capture the state of a process's memory, which can include sensitive information like credentials. Adversaries exploit this by creating or modifying dump files to extract credentials. The detection rule identifies suspicious dump file activities by monitoring file creation events, focusing on specific file headers and sizes, while excluding trusted processes and paths to reduce false positives. This helps in identifying unauthorized attempts to access credentials.
+
+### Possible investigation steps
+
+- Review the file creation event details to confirm the presence of the MDMP header (4d444d50) and verify the file size is 30,000 bytes or larger, as these are key indicators of a suspicious memory dump.
+- Identify the process responsible for creating the dump file by examining the process.name and process.executable fields. Check if the process is listed as a trusted executable in the exclusion list.
+- Investigate the file path where the dump file was created. Ensure it does not match any of the known trusted paths specified in the rule, such as "?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\WER\\\\*" or "?:\\\\Users\\\\*\\\\AppData\\\\*\\\\CrashDumps\\\\*".
+- Check the process.code_signature.trusted field to determine if the process creating the dump file is signed and trusted. If not, this could indicate a higher risk of malicious activity.
+- Correlate the event with other recent alerts or logs from the same host to identify any patterns or additional suspicious activities that might suggest credential dumping attempts.
+- If the process or path is not trusted, consider isolating the host for further forensic analysis to prevent potential credential theft or further compromise.
+
+### False positive analysis
+
+- System processes like WerFault.exe and Wermgr.exe are known to create legitimate memory dump files. To reduce false positives, ensure these processes are marked as trusted in the detection rule.
+- Applications installed in standard directories such as Program Files or Program Files (x86) may generate dump files during normal operations. Consider excluding these paths if the applications are verified and trusted.
+- User applications like Zoom may create crash reports in user-specific directories. If these are frequent and verified as non-malicious, add exceptions for these paths to minimize alerts.
+- Windows Error Reporting (WER) paths are common for legitimate dump file creation. Exclude these paths if the processes involved are trusted and verified to prevent unnecessary alerts.
+- Ensure that any process with a valid and trusted code signature is excluded from triggering alerts, as these are less likely to be associated with malicious activity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified in the alert that are not part of the trusted list, especially those involved in creating or modifying memory dump files.
+- Conduct a thorough review of the affected system's memory dump files to identify any extracted credentials or sensitive information.
+- Change credentials for any accounts potentially exposed through the memory dump, prioritizing high-privilege accounts.
+- Restore the affected system from a known good backup if unauthorized modifications are detected and cannot be easily remediated.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts at credential access via memory dumps.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
index 666c28d4f06..0ee079f1987 100644
--- a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
+++ b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,41 @@ file where host.os.type == "windows" and event.type == "creation" and
     process.name : "System" and file.extension : "tmpscan"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Memory Dump File with Unusual Extension
+
+Memory dumps capture the contents of system memory, often used for debugging or analysis. Adversaries may disguise these files with atypical extensions to evade detection, facilitating credential theft or defense evasion. The detection rule identifies such anomalies by checking for specific memory dump signatures and filtering out known benign processes, alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the file path and name to determine if the unusual extension could be an attempt to disguise the memory dump file.
+- Examine the process that created the file, focusing on the process.executable and process.name fields, to identify if it is a known or trusted application.
+- Check the process code signature status (process.code_signature.trusted) to verify if the process is signed and trusted, which might reduce the likelihood of malicious intent.
+- Investigate the host where the file was created to identify any recent suspicious activities or alerts that might correlate with this event.
+- Analyze the file header bytes (file.Ext.header_bytes) to confirm the presence of the MDMP signature, ensuring the file is indeed a memory dump.
+- Cross-reference the event with other security logs or alerts to identify any related incidents or patterns of behavior that could indicate a broader threat.
+
+### False positive analysis
+
+- Memory dump files created by trusted security software like Endgame's esensor.exe may trigger alerts. To handle this, add an exception for processes with a trusted code signature and no file extension.
+- System processes generating files with the extension "tmpscan" can be benign. Exclude these specific cases to reduce unnecessary alerts.
+- Regularly review and update the list of known benign extensions to ensure that legitimate memory dump activities are not flagged as suspicious.
+- Monitor for any new software installations or updates that might introduce legitimate memory dump activities, and adjust the rule exceptions accordingly.
+- Collaborate with IT and security teams to identify any internal processes or tools that may generate memory dumps with unusual extensions, and whitelist these as needed.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes associated with the creation of the memory dump file, especially those not matching known benign processes.
+- Conduct a thorough review of the system's recent activity logs to identify any unauthorized access or actions that may have led to the creation of the memory dump.
+- Restore the system from a known good backup if any unauthorized changes or data exfiltration are confirmed.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement stricter file monitoring and alerting for unusual file extensions and memory dump activities to enhance future detection capabilities.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/credential_access_win_private_key_access.toml b/rules_building_block/credential_access_win_private_key_access.toml
index 5cb1e8fc4d8..4a3c37f64ce 100644
--- a/rules_building_block/credential_access_win_private_key_access.toml
+++ b/rules_building_block/credential_access_win_private_key_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,41 @@ process where host.os.type == "windows" and event.type == "start" and
     "?:\\Windows\\System32\\OpenSSH\\*"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Attempted Private Key Access
+
+Private keys, such as SSH keys, are critical for secure authentication in environments. Adversaries may attempt to access these keys to gain unauthorized access. The detection rule identifies suspicious processes on Windows systems that attempt to access files typically associated with private keys, while excluding legitimate processes. This helps in identifying potential credential access attempts by filtering out known benign activities.
+
+### Possible investigation steps
+
+- Review the process details to identify the executable that attempted to access private key files, focusing on the process.args field to understand the specific files targeted.
+- Check the process execution context, including the user account under which the process was running, to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Investigate the parent process of the suspicious activity to trace back the origin of the execution and assess if it was initiated by a legitimate application or script.
+- Examine recent login and authentication logs for the user account associated with the process to identify any unusual access patterns or failed login attempts.
+- Correlate the event with other security alerts or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities.
+- Verify if the host has any known vulnerabilities or misconfigurations that could have been exploited to execute the process, and assess the need for remediation.
+
+### False positive analysis
+
+- Processes related to legitimate software updates, such as LogiLuUpdater.exe and LogiBoltUpdater.exe, may trigger false positives. Users can handle these by adding these executables to the exclusion list if they are verified as part of regular update activities.
+- Security tools like osqueryd.exe and various Guardicore agents may access files that match the pattern used in the detection rule. These should be excluded if they are confirmed to be part of authorized security operations.
+- The use of openssl.exe in Splunk installations for legitimate purposes can be mistaken for suspicious activity. Users should verify the context of its use and exclude it if it aligns with expected behavior.
+- Python scripts executed by Schneider Electric EcoStruxure software may access key files as part of their normal operation. If these scripts are verified as non-threatening, they should be added to the exclusion list.
+- The icacls.exe utility in Windows system32 directory may be used in administrative scripts that access key files. Confirm the legitimacy of these scripts and exclude them if they are part of routine administrative tasks.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule that are attempting to access private key files.
+- Conduct a thorough review of the system's access logs to identify any unauthorized access or data exfiltration attempts that may have occurred.
+- Change all potentially compromised private keys and associated credentials immediately to prevent unauthorized access using these keys.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts to access private keys or other sensitive files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Review and update access controls and permissions to ensure that only authorized processes and users have access to private key files, reducing the risk of future unauthorized access attempts."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
index f825349247d..f2a6ddeb46a 100644
--- a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
+++ b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/06/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/06/25"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,40 @@ query = '''
 event.dataset: "aws.cloudtrail" and event.provider: "rds.amazonaws.com" 
     and event.action: ("CreateDBSnapshot" or "CreateDBClusterSnapshot") and event.outcome: "success" 
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS RDS DB Snapshot Created
+AWS RDS DB Snapshots are backups of databases that ensure data recovery and continuity. However, adversaries may exploit this feature to bypass security controls or erase traces by reverting databases to previous states. The detection rule monitors successful snapshot creation events, serving as a foundational element to correlate with other alerts, thereby identifying potential misuse indicative of defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the event details in AWS CloudTrail for the specific snapshot creation event, focusing on the event.provider as "rds.amazonaws.com" and event.action as "CreateDBSnapshot" or "CreateDBClusterSnapshot" to confirm the snapshot creation.
+- Identify the IAM user or role (event.userIdentity) associated with the snapshot creation to determine if the action was performed by an authorized entity or if it appears suspicious.
+- Check the event.sourceIPAddress to verify the origin of the request and assess if it aligns with expected network locations or if it indicates potential unauthorized access.
+- Investigate the timing of the snapshot creation event in relation to other activities in the AWS environment to identify any unusual patterns or sequences that might suggest malicious intent.
+- Correlate this snapshot creation event with other security alerts or logs to identify any concurrent or subsequent actions that could indicate an attempt to evade defenses or cover tracks.
+- Review the AWS RDS instance's recent activity and configuration changes to assess if there have been any unauthorized modifications or access attempts that could be related to the snapshot creation.
+
+### False positive analysis
+
+- Routine database maintenance activities by authorized personnel can trigger snapshot creation events. To manage this, create exceptions for known maintenance schedules or specific user accounts responsible for these tasks.
+- Automated backup solutions may regularly create snapshots as part of their operation. Identify and exclude these automated processes by filtering events based on the source or associated tags.
+- Development and testing environments often involve frequent snapshot creation for testing purposes. Exclude these environments by using environment-specific identifiers or tags in your filtering criteria.
+- Third-party integrations or services that require snapshot creation for functionality can generate false positives. Review and whitelist these services by their unique identifiers or API calls.
+- Ensure that any exclusion rules are regularly reviewed and updated to reflect changes in infrastructure or operational practices to maintain security integrity.
+
+### Response and remediation
+
+- Immediately review the AWS CloudTrail logs to identify the source of the snapshot creation, including the IAM user or role involved, and verify if the action was authorized.
+- Temporarily revoke or restrict permissions for the identified IAM user or role to prevent further unauthorized snapshot creations.
+- Assess the integrity of the database by comparing the current state with the snapshot to ensure no unauthorized changes have been made.
+- If unauthorized activity is confirmed, initiate a rollback to a known good state using a verified snapshot, ensuring that the compromised snapshot is not used.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation.
+- Implement additional monitoring and alerting for unusual snapshot creation activities, focusing on deviations from normal patterns.
+- Review and update IAM policies to enforce the principle of least privilege, ensuring only necessary permissions are granted for snapshot creation."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
index 45e62b40635..ff4306e1095 100644
--- a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
+++ b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,40 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.args : "type" and process.args : (">", ">>")) or
     (process.args : "copy" and process.args : "/b"))
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Binary Content Copy via Cmd.exe
+
+Cmd.exe, a command-line interpreter on Windows, is often exploited by attackers to reconstruct binary files from fragments using commands like 'type' and 'copy /b'. This technique allows adversaries to evade detection by assembling malicious payloads directly on the target system. The detection rule identifies such activities by monitoring for specific command patterns indicative of binary reassembly, thus alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of cmd.exe with arguments related to 'type' and 'copy /b', as these are indicative of binary reassembly attempts.
+- Examine the parent process of the cmd.exe instance to determine if it was spawned by a legitimate application or a suspicious process, which could provide context on how the command was initiated.
+- Check the file paths and names involved in the 'type' and 'copy /b' commands to identify any unusual or unauthorized files being manipulated, which may indicate malicious intent.
+- Investigate the user account associated with the cmd.exe process to assess whether the activity aligns with the user's typical behavior or if the account may be compromised.
+- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise that could suggest a broader attack campaign.
+
+### False positive analysis
+
+- System administrators may use cmd.exe to concatenate log files or other non-malicious binary data. To handle this, create exceptions for known administrative scripts or processes that frequently use the 'type' or 'copy /b' commands.
+- Backup or maintenance scripts might use similar command patterns for legitimate purposes. Identify these scripts and exclude them from triggering alerts by specifying their file paths or process hashes in the monitoring tool.
+- Software installations or updates might involve the use of cmd.exe to manage binary files. Monitor installation logs and whitelist these activities when they are verified as part of legitimate software deployment processes.
+- Developers or IT personnel might use cmd.exe for testing or debugging purposes. Establish a list of trusted users or machines where such activities are expected and exclude them from the rule's scope.
+- Automated tasks or scheduled jobs that involve file manipulation using cmd.exe could trigger false positives. Review scheduled tasks and exclude those that are part of routine operations from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential malicious payload.
+- Terminate any suspicious cmd.exe processes identified by the detection rule to halt ongoing binary reassembly activities.
+- Conduct a forensic analysis of the affected system to identify and remove any malicious binaries that may have been assembled and executed.
+- Review and restore any altered or deleted system files from a known good backup to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other potential threats in the environment.
+- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the binary reassembly activity.
+- Update endpoint protection and intrusion detection systems with the latest threat intelligence to enhance detection capabilities against similar tactics."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_cmstp_execution.toml b/rules_building_block/defense_evasion_cmstp_execution.toml
index 5e901e34f2b..fbe5d758f3b 100644
--- a/rules_building_block/defense_evasion_cmstp_execution.toml
+++ b/rules_building_block/defense_evasion_cmstp_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,40 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name : "cmstp.exe" and process.args == "/s"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Defense Evasion via CMSTP.exe
+
+CMSTP.exe is a legitimate Windows utility used to install network profiles via INF files. However, attackers can exploit it to execute malicious code by crafting INF files with harmful commands. The detection rule identifies suspicious activity by monitoring the execution of CMSTP.exe with specific arguments, flagging potential misuse for defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of CMSTP.exe with the argument "/s" in the event logs, as this matches the suspicious activity pattern.
+- Investigate the parent process of CMSTP.exe to determine if it was launched by a legitimate application or a potentially malicious one.
+- Examine the associated INF file used during the execution to identify any unusual or malicious commands that may have been embedded.
+- Check the user account under which CMSTP.exe was executed to assess if it aligns with expected behavior or if it indicates potential compromise.
+- Analyze recent system changes or installations around the time of the alert to identify any unauthorized or suspicious modifications.
+- Correlate this event with other security alerts or logs to identify patterns or additional indicators of compromise that may suggest a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate network profile installations may trigger the rule if CMSTP.exe is used with the /s argument. To manage this, identify and whitelist specific network profiles or installation scripts that are known and trusted within your organization.
+- Automated system management tools might use CMSTP.exe for legitimate purposes. Review and document these tools, then create exceptions for their known behaviors to prevent unnecessary alerts.
+- Scheduled tasks or scripts that regularly execute CMSTP.exe for maintenance or configuration purposes can be excluded by identifying their specific command-line patterns and adding them to an exception list.
+- User-initiated actions, such as manual network configuration changes, might also cause false positives. Educate users on the implications of using CMSTP.exe and establish a process for reporting legitimate use cases to the security team for review and potential exclusion.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement.
+- Terminate any running instances of CMSTP.exe that are executing with suspicious arguments, such as "/s", to halt any ongoing malicious activity.
+- Conduct a thorough review of the INF files associated with the CMSTP.exe execution to identify and remove any malicious commands or scripts.
+- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
+- Update and patch the operating system and all software to the latest versions to mitigate exploitation of known vulnerabilities.
+- Implement application whitelisting to prevent unauthorized execution of CMSTP.exe and other system binaries that can be abused for proxy execution.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
index e59ad5a89c1..c6bff02aeb7 100644
--- a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
+++ b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,41 @@ file where host.os.type == "windows" and event.action != "deletion" and
 
   not (process.executable : "?:\\Windows\\System32\\inetsrv\\w3wp.exe" and file.path : "?:\\inetpub\\temp\\IIS Temporary Compressed Files\\*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Archive File with Unusual Extension
+
+Archive files are commonly used for data compression and storage, often identified by specific headers. Adversaries may exploit this by disguising archives with extensions typical of images, audio, or documents to bypass security measures. The detection rule identifies such anomalies by checking for archive headers paired with unusual extensions, flagging potential masquerading attempts while excluding legitimate system processes.
+
+### Possible investigation steps
+
+- Review the file path and name to determine if it aligns with typical user or system activity, focusing on unusual directories or naming conventions.
+- Examine the file header bytes to confirm the file type and verify if it matches the expected format for the extension used.
+- Investigate the process that created or modified the file, especially if it is not a known or legitimate system process, to identify potential malicious activity.
+- Check the user account associated with the file creation or modification for any signs of compromise or unusual behavior.
+- Analyze recent network activity from the host to identify any suspicious connections or data exfiltration attempts that may correlate with the file creation.
+- Review historical alerts or logs for the host to identify any patterns or previous incidents that might indicate ongoing malicious activity.
+
+### False positive analysis
+
+- System-generated temporary files may trigger false positives, especially in environments where web servers like IIS are used. To mitigate this, ensure that the rule excludes paths such as "?:\\inetpub\\temp\\IIS Temporary Compressed Files\\*".
+- Legitimate software installations or updates might create archive files with unusual extensions as part of their process. Identify these processes and consider adding them to an exception list if they are verified as non-threatening.
+- Some backup or synchronization tools may use non-standard extensions for archive files. Review the tools in use within your environment and exclude their specific file paths or processes if they are known to be safe.
+- Custom applications developed in-house might use unconventional file extensions for archives. Work with development teams to understand these applications and exclude their file paths or processes as needed.
+- Regularly review and update the list of excluded processes and paths to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes associated with the unusual archive file creation, especially those not originating from legitimate system processes.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software.
+- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from any malicious alterations.
+- Review and update file association settings and policies to prevent unauthorized applications from executing or creating files with mismatched extensions and headers.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring and alerting for similar activities across the network to enhance detection and response capabilities for future attempts."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
index 60798ca9d0f..2a3e248240c 100644
--- a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
+++ b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -253,6 +253,41 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Communication App Child Process
+
+Communication apps like Slack, WebEx, and Teams are integral to modern workflows, facilitating collaboration. However, adversaries can exploit these apps by spawning unauthorized child processes, potentially masquerading as legitimate ones or exploiting vulnerabilities to execute malicious code. The detection rule identifies such anomalies by monitoring child processes of these apps, ensuring they are trusted and signed by recognized entities. This helps in identifying potential threats that deviate from expected behavior, thus safeguarding against unauthorized access and execution.
+
+### Possible investigation steps
+
+- Review the process details, including the parent process name and executable path, to confirm if the child process is expected or unusual for the communication app in question.
+- Check the code signature of the suspicious child process to determine if it is trusted and signed by a recognized entity, as specified in the query.
+- Investigate the command line arguments of the child process to identify any potentially malicious or unexpected commands being executed.
+- Correlate the event with other logs or alerts to identify any related suspicious activities or patterns, such as repeated unauthorized child process executions.
+- Assess the user account associated with the process to determine if it has been compromised or is exhibiting unusual behavior.
+- Examine the network activity of the affected system to identify any suspicious outbound connections that may indicate data exfiltration or communication with a command and control server.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they spawn child processes from communication apps. Users can create exceptions for known update processes by verifying their code signatures and paths.
+- Custom scripts or automation tools that interact with communication apps might be flagged. Users should ensure these scripts are signed and located in trusted directories, then add them to the exception list.
+- Certain administrative tasks, such as using command-line tools like cmd.exe or powershell.exe, may be mistakenly identified as suspicious. Users can whitelist specific command lines or arguments that are regularly used in their environment.
+- Some third-party integrations with communication apps may generate child processes that are not inherently malicious. Users should verify the legitimacy of these integrations and add them to the trusted list if they are deemed safe.
+- Regularly review and update the list of trusted code signatures and executable paths to ensure that legitimate processes are not inadvertently flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious code.
+- Terminate any suspicious child processes identified by the detection rule that are not signed by recognized entities or are executing from unexpected locations.
+- Conduct a thorough review of the affected communication app's logs and configurations to identify any unauthorized changes or access patterns.
+- Restore the affected system from a known good backup if malicious activity is confirmed, ensuring that the backup is free from compromise.
+- Update the communication app and all related software to the latest versions to patch any known vulnerabilities that may have been exploited.
+- Implement application whitelisting to ensure only trusted and signed applications can execute, reducing the risk of similar threats.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on other systems."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_dll_hijack.toml b/rules_building_block/defense_evasion_dll_hijack.toml
index 68d23e22874..f74dc8391fb 100644
--- a/rules_building_block/defense_evasion_dll_hijack.toml
+++ b/rules_building_block/defense_evasion_dll_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,40 @@ library where host.os.type == "windows" and
         "553451008520a5f0110d84192cba40208fb001c27454f946e85e6fb2e6553292"
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unsigned DLL Loaded by a Trusted Process
+
+In Windows environments, trusted processes are often digitally signed to ensure integrity and authenticity. Adversaries exploit this by loading unsigned DLLs into these processes, effectively masking malicious activities. The detection rule identifies such anomalies by checking for unsigned DLLs loaded by trusted processes, focusing on recent file modifications and excluding known safe hashes, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process code signature status to confirm the legitimacy of the trusted process that loaded the unsigned DLL. This can help determine if the process itself has been compromised.
+- Examine the file creation and modification times of the DLL using the fields dll.Ext.relative_file_creation_time and dll.Ext.relative_file_name_modify_time to assess if the DLL was recently altered or created, which might indicate malicious activity.
+- Investigate the path of the DLL and the process executable using the dll.path and process.executable fields to verify if the DLL is located in an expected directory or if it is suspiciously placed in the application's directory.
+- Check the user ID associated with the process using the user.id field to determine if the process was executed by a legitimate user or a system account, excluding the known safe user ID "S-1-5-18".
+- Cross-reference the DLL's SHA-256 hash against known safe hashes to ensure it is not a false positive. If the hash is not listed in the known safe hashes, further analysis of the DLL's behavior and origin is warranted.
+
+### False positive analysis
+
+- Unsigned DLLs from legitimate software updates or installations may trigger alerts. Users can manage this by maintaining an updated list of known safe hashes and excluding them from the rule.
+- Virtual devices like "Virtual DVD-ROM" or "Virtual Disk" may load unsigned DLLs as part of their normal operation. Consider excluding these specific device product IDs if they are frequently used in your environment.
+- System processes running under the local system account (user ID "S-1-5-18") might load unsigned DLLs during legitimate operations. Ensure these are excluded to prevent unnecessary alerts.
+- Frequent modifications to DLLs in development environments can cause false positives. Implement exceptions for directories or processes associated with development activities to reduce noise.
+- Regularly review and update the list of excluded hashes to ensure it reflects the current state of trusted software and system updates, minimizing the risk of overlooking new threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
+- Terminate the trusted process that has loaded the unsigned DLL to stop any malicious actions being executed under its context.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.
+- Review and restore any modified or deleted system files from a known good backup to ensure system integrity and functionality.
+- Analyze the unsigned DLL and its associated process to determine the source and method of compromise, documenting findings for further investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to assess the potential impact on other systems.
+- Implement application whitelisting and enhance monitoring to prevent similar threats, ensuring that only digitally signed and verified DLLs are allowed to load into trusted processes."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
index 79332fc5371..2ae63164fea 100644
--- a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
+++ b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,41 @@ sequence by user.id with maxspan=5s
   process.name : "rundll32.exe" and process.command_line : ("*dfshim*ShOpenVerbApplication*", "*dfshim*#*")]
  [network where host.os.type == "windows" and process.name : "dfsvc.exe"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution via Microsoft DotNet ClickOnce Host
+
+Microsoft DotNet ClickOnce is a deployment technology that allows users to install and run applications by clicking a link in a web browser. Adversaries may exploit this by using trusted processes like Dfsvc.exe to execute malicious payloads, bypassing security measures. The detection rule identifies suspicious activity by monitoring for specific process behaviors and network activities, indicating potential misuse of ClickOnce for defense evasion.
+
+### Possible investigation steps
+
+- Review the process execution details for rundll32.exe, focusing on the command line arguments to confirm the presence of dfshim and ShOpenVerbApplication or dfshim with a hash (#) symbol, which may indicate suspicious activity.
+- Investigate the network activity associated with dfsvc.exe to identify any unusual or unauthorized connections, especially those that might be communicating with external or suspicious IP addresses.
+- Correlate the user.id associated with the alert to determine if the activity aligns with expected behavior for that user or if it appears anomalous.
+- Check the parent process of rundll32.exe to understand how it was initiated and whether it was spawned by a legitimate application or process.
+- Examine recent file modifications or creations in the user's profile or temporary directories that might be related to the ClickOnce deployment, looking for any unexpected or malicious files.
+- Review security logs and alerts for any additional indicators of compromise or related suspicious activities around the same timeframe to assess the broader context of the potential threat.
+
+### False positive analysis
+
+- Legitimate ClickOnce applications may trigger the rule when they are installed or updated. Users can create exceptions for known trusted applications by whitelisting their specific command lines or network behaviors.
+- Software development environments that utilize ClickOnce for deploying applications might frequently trigger this rule. Exclude these environments by identifying and allowing specific user accounts or machines involved in the development process.
+- Automated deployment systems that use ClickOnce for distributing updates can cause false positives. Implement exceptions for these systems by monitoring and excluding their typical network and process patterns.
+- Internal IT tools that leverage ClickOnce for remote installations may be flagged. Identify these tools and exclude their associated processes and network activities from the rule.
+- Regularly review and update the list of exceptions to ensure that only verified and non-threatening activities are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate the suspicious processes, specifically rundll32.exe and dfsvc.exe, to stop the execution of any potentially malicious payloads.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.
+- Review and analyze network logs to identify any unauthorized or suspicious connections initiated by dfsvc.exe, and block any malicious IP addresses or domains.
+- Restore the system from a known good backup if any critical system files or applications have been compromised.
+- 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 application whitelisting to prevent unauthorized applications from executing, and ensure that only trusted ClickOnce applications are allowed to run."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_download_susp_extension.toml b/rules_building_block/defense_evasion_download_susp_extension.toml
index 0e65e8b4c34..82a6f512170 100644
--- a/rules_building_block/defense_evasion_download_susp_extension.toml
+++ b/rules_building_block/defense_evasion_download_susp_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,40 @@ file where host.os.type == "windows" and event.type == "creation" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File with Suspicious Extension Downloaded
+
+In Windows environments, certain file extensions can be exploited for unauthorized code execution. Adversaries may download files with these extensions to bypass security measures and execute malicious payloads. The detection rule identifies such files downloaded from external sources, excluding known safe paths and processes, to flag potential threats. This helps in early detection of defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the file path and extension to determine if the file is located in a known safe directory or if it matches any of the excluded paths in the query.
+- Check the file's zone identifier to confirm it was downloaded from an external source, as indicated by a value greater than 1.
+- Investigate the process that created the file, focusing on whether it is a known and trusted application, especially if the process name is not Teams.exe or lacks a trusted code signature.
+- Analyze the file's metadata and properties to identify any unusual characteristics or discrepancies that could indicate tampering or malicious intent.
+- Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns that could suggest a broader attack campaign.
+- Consult threat intelligence sources to determine if the file extension or any associated indicators of compromise (IOCs) are linked to known malware or threat actors.
+
+### False positive analysis
+
+- Files downloaded by trusted applications like Microsoft Teams may trigger false positives when they use the msix extension. To handle this, ensure that the process name is Teams.exe and the code signature is trusted, then exclude these paths from the rule.
+- Temporary files created by Windows Package Manager (WinGet) in specific directories can be mistakenly flagged. Exclude paths such as AppData\\Local\\Temp\\WinGet and systemprofile\\AppData\\Local\\Microsoft\\WinGet\\State\\defaultState\\Microsoft.PreIndexed.Package\\Microsoft.Winget.Source to prevent these false alerts.
+- Regularly review and update the list of trusted applications and paths to ensure that legitimate activities are not incorrectly identified as threats. This helps maintain the balance between security and operational efficiency.
+- Consider implementing a whitelist for known safe file extensions and paths that are frequently used in your organization to reduce the number of false positives and streamline the detection process.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate any suspicious processes associated with the downloaded file, especially if they match the process names or paths identified in the detection rule.
+- Delete the suspicious file from the system to prevent accidental execution or further exploitation.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats or malware.
+- Review system logs and network traffic to identify any signs of lateral movement or data exfiltration attempts, and take appropriate action to contain any identified threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring and alerting for the specific file extensions and paths identified in the detection rule to enhance detection of similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
index 2eecbdb9c35..8dc8e03a3cf 100644
--- a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
+++ b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,40 @@ sequence with maxspan=1m
                    "*Common\\..\\..\\BuildTools\\*"))
   ] by process.parent.entity_id
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution via MS VisualStudio Pre/Post Build Events
+
+Microsoft Visual Studio allows developers to automate tasks using pre/post build events, which execute commands during the build process. Adversaries can exploit this by injecting malicious commands into these events, executing harmful code under the guise of a legitimate build. The detection rule identifies suspicious command executions linked to Visual Studio builds, focusing on unusual parent-child process relationships and command patterns, while excluding known safe operations, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent-child relationship, focusing on instances where MSBuild.exe spawns cmd.exe or other suspicious processes like powershell.exe or rundll32.exe.
+- Examine the command line arguments of the suspicious process to determine if they match known malicious patterns or if they deviate from typical build operations.
+- Check the file path and content of any scripts or executables in the Temp directory (e.g., tmp*.exec.cmd) to identify potential malicious payloads.
+- Investigate the user account associated with the process execution to determine if it aligns with expected developer activity or if it indicates unauthorized access.
+- Correlate the alert with recent changes in the Visual Studio project files to identify any unauthorized modifications to pre/post build events.
+- Look for additional indicators of compromise on the host, such as unusual network connections or file modifications, that may suggest further malicious activity.
+
+### False positive analysis
+
+- Visual Studio build scripts that legitimately use cmd.exe or powershell.exe for automation tasks may trigger false positives. Users can handle these by adding specific script paths or command patterns to the exclusion list.
+- Developers using MSBuild.exe for legitimate build processes might see false positives if their processes match the suspicious patterns. Exclude known safe MSBuild.exe paths from detection to mitigate this.
+- Automated build systems that utilize tools like vswhere.exe or git log for version control and project management can be mistakenly flagged. Exclude these command lines from the detection rule to prevent unnecessary alerts.
+- Custom scripts or tools that interact with Visual Studio projects, such as applocal.ps1 or MediaCache.ps1, may cause false positives. Users should identify and exclude these specific scripts if they are part of regular, non-malicious operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further execution of malicious commands and potential lateral movement.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving cmd.exe or other flagged executables like powershell.exe, MSHTA.EXE, or rundll32.exe.
+- Conduct a thorough review of the Visual Studio project files and build scripts to identify and remove any unauthorized or malicious pre/post build commands.
+- Restore the affected system from a known good backup to ensure any backdoor or malicious modifications are completely removed.
+- Implement application whitelisting to restrict the execution of unauthorized scripts and executables, focusing on those commonly abused in this context.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Enhance monitoring and logging for Visual Studio build processes and related command executions to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_file_permission_modification.toml b/rules_building_block/defense_evasion_file_permission_modification.toml
index f58bdff58c1..8ecb20c862e 100644
--- a/rules_building_block/defense_evasion_file_permission_modification.toml
+++ b/rules_building_block/defense_evasion_file_permission_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,42 @@ not (
   process.args : ("C:\\ProgramData\\Lenovo\\*", "C:\\ProgramData\\Adobe\\*", "C:\\ProgramData\\ASUS\\ASUS*")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File and Directory Permissions Modification
+
+File and directory permissions in Windows environments control access and modification rights, crucial for maintaining system integrity. Adversaries may exploit utilities like `icacls`, `cacls`, `takeown`, and `attrib` to alter permissions, enabling unauthorized access or deletion. The detection rule identifies suspicious use of these utilities, excluding known legitimate processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific utility used (icacls.exe, cacls.exe, takeown.exe, or attrib.exe) and the arguments passed, as these can indicate the type of permission modification attempted.
+- Check the user ID associated with the process to determine if it is a known or unknown user, especially since the rule excludes the system account (S-1-5-18).
+- Investigate the file or directory path targeted by the permission modification to assess its importance and potential impact on the system.
+- Examine the process execution context, including the parent process and command line, to understand how the utility was invoked and whether it aligns with typical user behavior.
+- Correlate the event with other security alerts or logs around the same timeframe to identify any related suspicious activities or patterns.
+- Verify if the process arguments match any of the excluded paths (e.g., C:\\ProgramData\\Lenovo\\*) to ensure the alert is not a false positive due to legitimate software operations.
+- Assess the risk and potential impact of the permission change on system security and data integrity, considering the severity and risk score provided by the rule.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger permission changes, especially from trusted vendors like Lenovo, Adobe, or ASUS. To manage these, add specific paths to the exclusion list, as shown in the rule.
+- System administrators often use utilities like icacls or takeown for routine maintenance. Identify and exclude these activities by correlating with known administrative tasks or by excluding specific user IDs associated with admin accounts.
+- Automated scripts or scheduled tasks that modify file permissions for backup or system optimization purposes can be mistaken for threats. Review and whitelist these scripts by their execution paths or associated user accounts.
+- Security software or system management tools may alter permissions as part of their normal operation. Verify these tools and exclude their processes or paths to prevent false alerts.
+- Temporary permission changes during software testing or development can be flagged. Coordinate with development teams to identify and exclude these activities during known testing periods.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the threat actor.
+- Terminate any suspicious processes identified in the alert, such as instances of `icacls.exe`, `cacls.exe`, `takeown.exe`, or `attrib.exe` that match the query criteria.
+- Conduct a thorough review of the modified file and directory permissions to assess the extent of unauthorized changes and restore them to their original state.
+- Check for any unauthorized user accounts or changes in user privileges that may have been created or altered during the incident and revert them to their legitimate state.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat, focusing on the specific utilities and arguments used in the attack.
+- Review and update access control policies and permissions to ensure they adhere to the principle of least privilege, reducing the risk of similar attacks in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_generic_deletion.toml b/rules_building_block/defense_evasion_generic_deletion.toml
index 845c9e5546e..d9914104cba 100644
--- a/rules_building_block/defense_evasion_generic_deletion.toml
+++ b/rules_building_block/defense_evasion_generic_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,40 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name: "powershell.exe" and process.args: ("*rmdir", "rm", "rd", "*Remove-Item*", "del", "*]::Delete(*"))
 ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 File or Directory Deletion Command
+
+In Windows environments, commands like `rundll32.exe`, `reg.exe`, `cmd.exe`, and `powershell.exe` are integral for system management, allowing users to delete files or directories. Adversaries exploit these to erase logs or evidence of their activities, aiding in defense evasion. The detection rule identifies suspicious deletions by monitoring these command executions, excluding benign paths, and flagging non-system users, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific command executed, focusing on the process name and arguments, such as "rundll32.exe", "reg.exe", "cmd.exe", or "powershell.exe", and their respective arguments.
+- Check the user ID associated with the process execution to determine if it is a non-system user, as the rule excludes the system user ID "S-1-5-18".
+- Investigate the context of the file or directory targeted for deletion by examining the process arguments, especially if they involve critical directories or files like logs or browser history.
+- Correlate the event with other recent activities on the host to identify any patterns or sequences that suggest malicious intent, such as multiple deletion attempts or other suspicious processes.
+- Assess the risk and impact of the deletion by determining if any important system or application logs were removed, which could hinder further investigation or system functionality.
+
+### False positive analysis
+
+- Routine system maintenance or software updates may trigger file or directory deletions. Users can create exceptions for known maintenance scripts or update processes to prevent false positives.
+- Automated cleanup tools like disk cleanup utilities or third-party software may use similar commands. Identify these tools and exclude their specific paths or user accounts from the rule.
+- User-initiated actions such as clearing browser history or temporary files can be mistaken for malicious activity. Educate users on the implications of these actions and consider excluding common user directories from monitoring.
+- Development environments often involve frequent file deletions during build processes. Exclude directories or processes associated with development tools to reduce noise.
+- Backup or synchronization software might delete files as part of their normal operation. Identify these applications and exclude their operations from the rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, such as those involving `rundll32.exe`, `reg.exe`, `cmd.exe`, or `powershell.exe` with deletion arguments.
+- Conduct a forensic analysis of the affected system to identify any deleted files or directories, focusing on logs, browser history, or other critical data that may have been targeted.
+- Restore any critical files or logs from backups if they were deleted and are necessary for ongoing operations or investigations.
+- Review user account activity, especially for non-system users flagged by the detection rule, to determine if any accounts have been compromised and reset credentials as necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring and alerting for similar command executions to enhance detection and response capabilities for future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
index 68ad590b53a..3f200b71591 100644
--- a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
+++ b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,40 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.parent.name : ("pcalua.exe", "forfiles.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Indirect Command Execution via Forfiles/Pcalua
+
+Forfiles and pcalua.exe are legitimate Windows utilities used for file management and program compatibility tasks. Adversaries exploit these tools to execute commands indirectly, bypassing security controls. The detection rule identifies suspicious activity by monitoring process initiation events where these utilities are the parent process, indicating potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process details to identify the command line arguments used with pcalua.exe or forfiles.exe to understand the intended action and potential impact.
+- Check the parent process of pcalua.exe or forfiles.exe to determine how these utilities were invoked and assess if this aligns with expected behavior.
+- Investigate the user account associated with the process initiation to verify if the activity is consistent with their typical behavior or if the account may be compromised.
+- Examine recent system logs and security events for any related or suspicious activities that occurred around the same time as the alert.
+- Correlate the alert with other security events or alerts to identify if this is part of a larger attack pattern or campaign.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when forfiles.exe or pcalua.exe are used for legitimate file management or compatibility checks. To manage this, identify and document regular administrative scripts or tasks that use these utilities and create exceptions for these known activities.
+- Software installations or updates often invoke pcalua.exe as part of their normal operation. Monitor and whitelist specific software installation processes that are known and trusted within your environment to reduce unnecessary alerts.
+- Scheduled tasks or automated scripts that utilize forfiles.exe for file cleanup or management can generate false positives. Review and exclude these tasks by correlating them with scheduled task logs or known maintenance windows.
+- Some third-party applications may use these utilities as part of their normal functionality. Identify these applications and consider creating exceptions based on the application's path or hash to prevent false alerts.
+- User-initiated actions, such as compatibility troubleshooting, might involve pcalua.exe. Educate users on the implications of using these tools and establish a process for reporting legitimate use cases to security teams for exclusion.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes initiated by pcalua.exe or forfiles.exe to stop potential malicious activity.
+- Conduct a thorough review of recent changes and scheduled tasks on the affected system to identify any unauthorized modifications or persistence mechanisms.
+- Restore any altered or deleted files from a known good backup to ensure system integrity and functionality.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary.
+- Monitor the network for any further suspicious activity related to pcalua.exe or forfiles.exe to detect potential follow-up attacks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_injection_from_msoffice.toml b/rules_building_block/defense_evasion_injection_from_msoffice.toml
index 6d1c96172e8..2f06dbb7516 100644
--- a/rules_building_block/defense_evasion_injection_from_msoffice.toml
+++ b/rules_building_block/defense_evasion_injection_from_msoffice.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,41 @@ process where host.os.type == "windows" and event.action == "start" and
     "?:\\Windows\\Sys*\\ctfmon.exe",
     "?:\\Windows\\System32\\notepad.exe")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Process Injection from Malicious Document
+
+Process injection is a technique used by adversaries to execute malicious code within the address space of another process, often to evade detection. Microsoft Office applications, like Word and Excel, are common targets due to their widespread use and ability to run macros. The detection rule identifies unusual child processes spawned by these applications, focusing on suspicious arguments and executable paths, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the parent process details to confirm if the process name is one of the targeted Microsoft Office applications (excel.exe, powerpnt.exe, winword.exe) and verify the legitimacy of the parent process.
+- Examine the child process executable path to determine if it matches the suspicious paths specified in the rule (e.g., "?:\\Windows\\SysWOW64\\*.exe", "?:\\Windows\\system32\\*.exe") and assess if the executable is expected or known to be used by the organization.
+- Investigate the process arguments to understand the context of the process execution, especially since the rule flags processes with a single argument, which might indicate an attempt to obfuscate or hide malicious activity.
+- Check the code signature of the executable to determine if it is trusted and verify the subject name to ensure it is not a spoofed or untrusted signature.
+- Correlate the alert with any recent activity involving the same user or host to identify patterns or additional indicators of compromise, such as other unusual process executions or network connections.
+- Review any related document files or email attachments that might have been opened around the time of the alert to identify potential sources of the malicious document or macro.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they are executed by Office applications. Users can create exceptions for known update processes by verifying their code signatures and adding them to a trusted list.
+- Automated scripts or administrative tools that interact with Office applications might be flagged. Review these scripts and, if verified as safe, exclude their specific executable paths from the rule.
+- Some enterprise applications may integrate with Office applications and spawn processes with similar characteristics. Identify these applications and exclude their executable paths or signatures to prevent false positives.
+- Users running custom macros that launch legitimate processes could trigger the rule. Educate users on safe macro practices and consider excluding specific macros or processes if they are deemed non-threatening.
+- System maintenance tasks that involve Office applications might be misidentified. Document these tasks and exclude their associated processes if they are confirmed to be safe.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity.
+- Terminate any suspicious processes identified by the alert, particularly those spawned by Microsoft Office applications with unusual arguments or paths.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or files.
+- Review and analyze the parent Office document suspected of containing malicious macros to understand the scope of the threat and to prevent similar future incidents.
+- Restore the affected system from a known good backup if any system integrity issues are detected, ensuring that the backup is free from any malicious code.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update and enhance detection capabilities by reviewing and refining security monitoring rules to better identify similar threats in the future, leveraging insights from the current incident."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_installutil_command_activity.toml b/rules_building_block/defense_evasion_installutil_command_activity.toml
index f0718951b7f..26cb68a3927 100644
--- a/rules_building_block/defense_evasion_installutil_command_activity.toml
+++ b/rules_building_block/defense_evasion_installutil_command_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,40 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
   process.name : "installutil.exe" and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Activity
+
+InstallUtil is a legitimate Windows utility used for installing and uninstalling .NET applications by executing installer components. However, adversaries can exploit it to execute malicious code under the guise of a trusted process, evading security measures. The detection rule identifies suspicious InstallUtil activity by monitoring process starts on Windows systems, specifically flagging instances not initiated by the system account, which may indicate unauthorized use.
+
+### Possible investigation steps
+
+- Review the process details for the triggered alert, focusing on the user ID to identify the account that initiated the InstallUtil process, as it should not be the system account (S-1-5-18).
+- Investigate the parent process of InstallUtil to determine how it was launched and assess if the parent process is legitimate or potentially malicious.
+- Check the command-line arguments used with InstallUtil to identify any suspicious or unexpected parameters that could indicate malicious activity.
+- Analyze the timeline of events around the InstallUtil process start to identify any related or preceding suspicious activities, such as file downloads or other process executions.
+- Review the network activity associated with the user account and the host to identify any unusual outbound connections that could suggest data exfiltration or command-and-control communication.
+- Correlate the alert with other security events or logs from the same host or user account to identify patterns or repeated suspicious behavior.
+
+### False positive analysis
+
+- Legitimate software installations by IT administrators may trigger the rule if InstallUtil is used for deploying .NET applications. To manage this, create exceptions for known administrative accounts or specific installation scripts.
+- Automated deployment tools that utilize InstallUtil for legitimate software updates can cause false positives. Identify these tools and exclude their associated processes or user accounts from the rule.
+- Development environments where developers frequently use InstallUtil for testing purposes might be flagged. Consider excluding specific development machines or user accounts from the rule to reduce noise.
+- Scheduled tasks or scripts that use InstallUtil for routine maintenance or updates can be mistaken for malicious activity. Review and whitelist these tasks or scripts by their unique identifiers or execution paths.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized activity and potential lateral movement by the adversary.
+- Terminate the suspicious InstallUtil process to stop any ongoing malicious activity and prevent further execution of unauthorized code.
+- Conduct a thorough review of the affected system to identify any additional malicious files or processes that may have been introduced by the adversary.
+- Restore the system from a known good backup if any unauthorized changes or malicious software are detected, ensuring that the backup is free from compromise.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary.
+- Monitor for any recurrence of similar activity by setting up alerts for InstallUtil executions not initiated by the system account, ensuring quick detection and response to future threats.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
index 2017bffb2fb..459b67672b0 100644
--- a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
+++ b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,41 @@ library where host.os.type == "windows" and event.action == "load" and
     "?:\\Windows\\System32\\DriverStore\\FileRepository\\*"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Image Loaded with Invalid Signature
+
+In Windows environments, code signing ensures the integrity and authenticity of binaries. Adversaries may exploit this by loading binaries with invalid signatures to masquerade as legitimate software, evading detection. The detection rule identifies such anomalies by scrutinizing signature errors and recent file modifications, excluding trusted system paths, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the specific dll.name and process.name involved in the alert to understand which binary is attempting to load with an invalid signature.
+- Check the dll.code_signature.status to determine the nature of the signature error, such as "errorUntrustedRoot" or "errorBadDigest", to assess the potential risk.
+- Investigate the dll.Ext.relative_file_creation_time and dll.Ext.relative_file_name_modify_time to determine if the file was recently created or modified, which could indicate suspicious activity.
+- Examine the dll.path to ensure it does not fall within trusted system paths, as the rule excludes paths like "?:\\Windows\\System32\\DriverStore\\FileRepository\\*".
+- Correlate the event with other recent alerts or logs from the same host to identify any patterns or additional suspicious activities that might indicate a broader compromise.
+- Consult threat intelligence sources to see if the binary or its signature error has been associated with known malicious activity or campaigns.
+
+### False positive analysis
+
+- System or vendor updates may load binaries with temporary invalid signatures. Monitor update schedules and correlate alerts with known update activities to verify legitimacy.
+- Custom or in-house applications might not have valid signatures but are trusted within the organization. Create exceptions for these applications by specifying their paths or names in the exclusion list.
+- Development or testing environments often use unsigned or self-signed binaries. Consider excluding these environments from the rule or adjusting the risk score to reflect their lower threat level.
+- Security or monitoring tools may load unsigned components as part of their operation. Verify the legitimacy of these tools and exclude their paths if they are known and trusted.
+- Temporary file modifications during legitimate software installations or updates can trigger alerts. Cross-reference with installation logs or schedules to confirm benign activity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the loaded binary to halt any ongoing malicious activity.
+- Verify the integrity of the affected binary by comparing it against a known good version or reinstalling it from a trusted source.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts.
+- Review recent file modifications and system logs to identify any unauthorized changes or access, and restore any altered files from backups if necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring and alerting for similar signature anomalies to enhance detection and response capabilities for future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_browsers.toml b/rules_building_block/defense_evasion_masquerading_browsers.toml
index 3ad0df05445..07be25f7c2d 100644
--- a/rules_building_block/defense_evasion_masquerading_browsers.toml
+++ b/rules_building_block/defense_evasion_masquerading_browsers.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -157,6 +157,41 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Masquerading as Browser Process
+
+Browsers are integral to user interaction with the web, often trusted and whitelisted in security policies. Adversaries exploit this trust by masquerading malicious processes as legitimate browser processes, bypassing security measures and deceiving users. The detection rule identifies anomalies in browser processes, such as unusual or unsigned certificates, to flag potential threats, ensuring that only verified processes are executed.
+
+### Possible investigation steps
+
+- Review the process name and executable path to determine if it matches any known legitimate browser processes or paths listed in the query.
+- Check the process code signature details, specifically the subject name and trust status, to verify if the process is signed by a recognized and trusted entity.
+- Investigate the parent process to understand how the suspicious process was initiated and assess if it aligns with typical browser launch behavior.
+- Analyze the command-line arguments used by the process to identify any unusual or suspicious flags that may indicate malicious activity.
+- Correlate the process start event with other security events or logs from the same host to identify any related suspicious activities or patterns.
+- Consult threat intelligence sources to determine if the process name, executable path, or code signature has been associated with known threats or malware campaigns.
+
+### False positive analysis
+
+- Processes from legitimate software like HP Sure Click, Dynatrace, and Burp Suite may trigger false positives due to their use of Chrome executables. Users can mitigate this by adding exceptions for these specific paths and code signatures.
+- Microsoft Edge WebView2 processes signed by trusted entities like Bromium, Amazon, or Code Systems Corporation might be flagged. To handle this, users should ensure these signatures are included in the allowlist.
+- Firefox's default-browser-agent.exe signed by WATERFOX LIMITED can be a false positive. Users should verify the signature and add it to the trusted list if applicable.
+- Chromium-based browser processes from trusted vendors such as Citrix, AVG, or NortonLifeLock may be incorrectly flagged. Users should confirm the legitimacy of these signatures and update the allowlist accordingly.
+- Regularly review and update the list of trusted code signatures and executable paths to minimize false positives while maintaining security.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Terminate any suspicious processes identified by the detection rule that are masquerading as legitimate browser processes.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software.
+- Review and validate the code signatures of all browser-related processes on the affected system to ensure they are from trusted sources.
+- Restore any compromised systems from a known good backup to ensure system integrity and remove any persistent threats.
+- 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 enhanced monitoring and logging for browser processes across the network to detect similar threats in the future and improve response times."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
index 7df37c1057b..df750959876 100644
--- a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
+++ b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,40 @@ file where host.os.type == "windows" and event.action != "deletion" and
   not process.pid == 4 and
   not process.executable : "?:\\Program Files (x86)\\Trend Micro\\Client Server Security Agent\\Ntrtscan.exe"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Executable File with Unusual Extension
+
+Executable files are crucial for running applications, but adversaries may disguise them with non-executable extensions like images or documents to evade detection. This tactic, known as masquerading, exploits user trust and bypasses security filters. The detection rule identifies such anomalies by inspecting file headers for executable signatures, even if the extension suggests otherwise, thus flagging potential threats.
+
+### Possible investigation steps
+
+- Review the file path and name to determine if it aligns with typical user activity or known software installations, focusing on unusual directories or naming conventions.
+- Examine the file header bytes to confirm the presence of the "MZ" signature, indicating an executable file, despite the non-executable extension.
+- Check the file creation or modification timestamp to correlate with user activity or scheduled tasks, identifying any anomalies or unexpected changes.
+- Investigate the process that created or modified the file, excluding known safe processes like "Ntrtscan.exe", to identify potentially malicious activity.
+- Analyze the user account associated with the file creation or modification to determine if it has been compromised or is exhibiting unusual behavior.
+- Search for any related alerts or logs that might indicate a broader attack pattern or additional compromised files on the system.
+
+### False positive analysis
+
+- Files from legitimate software installations or updates may trigger the rule if they use non-standard extensions. Users can create exceptions for known software paths or specific file hashes to prevent these alerts.
+- Multimedia files with embedded executable content for legitimate purposes, such as self-extracting archives, might be flagged. Users should verify the source and purpose of such files and whitelist them if they are deemed safe.
+- Security or system administration tools that use unconventional file extensions for executables could be mistakenly identified. Users can exclude these tools by specifying their file paths or process names in the rule configuration.
+- Backup or recovery software that temporarily renames executable files with non-standard extensions during operations may cause false positives. Users should identify these processes and add them to the exclusion list to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potentially malicious executable file.
+- Terminate any suspicious processes associated with the identified executable file to halt any ongoing malicious activity.
+- Quarantine the suspicious file to prevent execution and further analysis, ensuring it is not accessible to users or other systems.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats.
+- Review recent file creation and modification logs to identify any other files with unusual extensions that may have been missed and take appropriate action.
+- Restore any affected files or systems from known good backups to ensure integrity and availability of data.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
index 63f9383bbda..2ff4acbe855 100644
--- a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,41 @@ library where host.os.type == "windows" and event.action == "load" and
     and dll.code_signature.trusted == true
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Masquerading as VLC DLL
+
+VLC media player uses specific DLLs for its functionality, typically signed by VideoLAN to ensure authenticity. Adversaries may exploit this by creating malicious DLLs with similar names to blend into systems, bypassing security measures. The detection rule identifies such anomalies by flagging unsigned or improperly signed DLLs mimicking VLC, focusing on defense evasion and persistence tactics.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific DLL name that triggered the alert, focusing on "libvlc.dll", "libvlccore.dll", or "axvlc.dll".
+- Check the code signature details of the flagged DLL to confirm the absence of a valid signature from "VideoLAN" or the specific subject name "716F2E5E-A03A-486B-BC67-9B18474B9D51".
+- Investigate the file path and location of the suspicious DLL to determine if it resides in a directory typically associated with VLC installations or if it is in an unusual location.
+- Analyze the process that loaded the DLL, including the parent process, to understand the context of its execution and identify any potentially malicious activity.
+- Correlate the event with other security logs or alerts to identify any related suspicious activities or patterns, such as recent downloads or installations that could have introduced the DLL.
+- Conduct a reputation check on the DLL file hash using threat intelligence sources to determine if it is known to be associated with malicious activity.
+- If necessary, isolate the affected system to prevent further potential compromise and perform a deeper forensic analysis to uncover any additional indicators of compromise.
+
+### False positive analysis
+
+- Legitimate software updates or installations may temporarily load unsigned or improperly signed VLC-related DLLs. Users can monitor the frequency and context of these events to determine if they align with known update schedules.
+- Custom or third-party applications that integrate VLC components might use their own versions of VLC DLLs. Users should verify the source and purpose of these applications and consider adding them to an exception list if deemed safe.
+- Development or testing environments may intentionally use modified VLC DLLs for debugging or feature testing. Users can exclude these environments from the rule or adjust the rule's scope to focus on production systems only.
+- Security tools or monitoring software might load or interact with VLC DLLs in a way that triggers the rule. Users should review the behavior of these tools and whitelist them if they are confirmed to be non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate any processes associated with the suspicious DLLs to halt any ongoing malicious operations.
+- Remove the identified unsigned or improperly signed DLLs from the system to eliminate the immediate threat.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any additional malicious files or remnants.
+- Restore any affected files or system components from a known good backup to ensure system integrity and functionality.
+- Review and update endpoint protection policies to ensure that only signed and trusted DLLs are allowed to load, enhancing future detection and prevention.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected, ensuring comprehensive threat management."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_windows_dll.toml b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
index f64458b81cf..a9e5951fe78 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -104,6 +104,43 @@ library where event.action == "load" and dll.Ext.relative_file_creation_time <=
       )
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Masquerading as System32 DLL
+
+System32 DLLs are critical components of the Windows operating system, providing essential functions for system operations. Adversaries may exploit this by replacing or mimicking these DLLs to execute malicious code, evade defenses, or maintain persistence. The detection rule identifies anomalies by checking for unsigned or non-Microsoft signed DLLs, recent file creation, and known masquerading patterns, helping to flag potential threats.
+
+### Possible investigation steps
+
+- Review the file creation time of the suspicious DLL to determine if it was recently created, as indicated by the `dll.Ext.relative_file_creation_time` field being less than or equal to 3600 seconds.
+- Check the file path of the DLL using the `dll.path` field to confirm if it resides outside of typical system directories, which might indicate an attempt to masquerade as a legitimate system DLL.
+- Verify the code signature of the DLL by examining the `dll.code_signature.subject_name` and `dll.code_signature.trusted` fields to identify if it is unsigned or signed by a non-Microsoft entity.
+- Investigate the process that loaded the DLL by reviewing the `process.name` field to understand the context in which the DLL was used and assess if the process is legitimate or potentially malicious.
+- Cross-reference the DLL name found in the `dll.name` field with known legitimate system DLLs to determine if the name is being used deceptively.
+- Analyze any related network activity or system changes around the time the DLL was loaded to identify potential malicious behavior or persistence mechanisms.
+
+### False positive analysis
+
+- Certain DLLs like icuuc.dll, timeSync.dll, and appInfo.dll may be signed by trusted vendors such as Valve, VMware, and Adobe. These are often legitimate and can be excluded by adding exceptions for these specific signatures.
+- DLLs like libcrypto.dll and wmi.dll signed by Bitdefender SRL or other trusted entities may trigger false positives. Users can mitigate this by creating exceptions for these trusted signatures.
+- dbghelp.dll is commonly used by various applications and may be signed by trusted entities. Consider excluding this DLL if it is consistently flagged without malicious activity.
+- DirectML.dll signed by Adobe Inc. can be a false positive. Users should verify the signature and exclude it if it is consistently trusted.
+- icsvc.dll signed by Dell Inc. or Dell Technologies Inc. may be legitimate. Users can handle this by adding exceptions for these signatures.
+- offreg.dll signed by Malwarebytes Inc. is often legitimate. Users should verify and exclude this DLL if it is consistently trusted.
+- AppMgr.dll signed by Autodesk, Inc. may be a false positive. Users can exclude this DLL if it is verified as trusted.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate any suspicious processes associated with the unsigned or non-Microsoft signed DLLs identified in the alert.
+- Restore the affected DLLs from a known good backup or reinstall the affected software to ensure integrity.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants.
+- Review and update system access controls and permissions to limit the ability of unauthorized users to modify critical system files.
+- Monitor the system and network for any signs of persistence mechanisms or further attempts to load unauthorized DLLs.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
index 96aa94f8133..8d85435b01d 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,41 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Masquerading as System32 Executable
+
+System32 executables are critical components of Windows, often targeted by adversaries for masquerading attacks. By replacing or mimicking these executables, attackers can execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies by checking for unsigned executables or those signed by non-Microsoft entities, flagging potential masquerading attempts. It excludes known trusted signatures and paths to reduce false positives, focusing on defense evasion and persistence tactics.
+
+### Possible investigation steps
+
+- Review the process name and executable path to determine if it matches any known legitimate applications or if it appears suspicious based on the context of the alert.
+- Check the code signature status and subject name to verify if the executable is signed by a trusted entity or if it is unsigned, which could indicate a potential masquerading attempt.
+- Investigate the parent process to understand how the suspicious process was initiated and if it aligns with expected behavior for the system or user.
+- Examine the process execution history and any associated network activity to identify any unusual patterns or connections that could suggest malicious intent.
+- Cross-reference the executable path and process name against known false positives or exceptions listed in the rule to ensure the alert is not triggered by a benign process.
+- Gather additional context from system logs or endpoint detection tools to corroborate findings and assess the potential impact or scope of the activity.
+
+### False positive analysis
+
+- Executables signed by trusted third-party vendors like Lenovo, HP Inc., Dell Inc., ImageMagick Studio LLC, Arctic Wolf Networks, Intel(R) Online Connect Access, Fortinet Technologies, and Cisco Systems may trigger false positives. Users can mitigate this by adding these vendors to the exception list if their signatures are verified as trusted.
+- Processes running from temporary directories or specific paths such as "?:\\Program Files\\Git\\usr\\bin\\hostname.exe" or "?:\\Users\\*\\AppData\\Local\\Temp\\{*}\\taskkill.exe" might be flagged. Users should verify these paths and exclude them if they are part of legitimate operations.
+- The rule may flag processes like "ucsvc.exe" signed by Wellbia.com Co., Ltd. or "pnputil.exe" signed by Lenovo, HP Inc., or Dell Inc. as false positives. Users should ensure these signatures are trusted and add them to the exception list if necessary.
+- If "certutil.exe" is used by Intel(R) Online Connect Access or Fortinet Technologies, and the signature is trusted, users can exclude these specific instances to prevent false positives.
+- For processes like "sfc.exe" signed by Cisco Systems, users should verify the signature's trust status and exclude them if they are part of legitimate activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate any suspicious processes identified by the alert that are unsigned or signed by non-Microsoft entities.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or executables.
+- Restore any replaced or backdoored system32 executables from a known good backup to ensure system integrity.
+- Review and update the system's security patches and software updates to close any vulnerabilities that may have been exploited.
+- Monitor the system and network for any signs of persistence mechanisms or further unauthorized access attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
index 1c7efb230f7..f4127cfc1dc 100644
--- a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
+++ b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,40 @@ process where host.os.type == "windows" and event.action == "start" and
     "ftp://*"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Troubleshooting Pack Cabinet Execution
+
+The Microsoft Diagnostic Wizard, often invoked via `msdt.exe`, is a legitimate tool used for troubleshooting and diagnostics on Windows systems. Adversaries may exploit this tool to execute malicious files by disguising them as troubleshooting packs, especially from unusual paths or with unexpected parent processes. The detection rule identifies such suspicious executions by monitoring for `msdt.exe` launches with specific arguments and parent processes, indicating potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship of msdt.exe, focusing on the parent process names such as browsers or office applications, to determine if the execution context is unusual or expected.
+- Examine the command-line arguments used with msdt.exe, particularly looking for suspicious paths or URLs (e.g., network paths, HTTP, or FTP links) that could indicate a malicious source.
+- Check the file path and origin of the diagcab file being executed to verify if it is from a trusted source or if it has been downloaded from an untrusted or external location.
+- Investigate the user account under which msdt.exe was executed to determine if the activity aligns with the user's typical behavior or if it appears anomalous.
+- Look for any related network activity or connections initiated around the time of the msdt.exe execution to identify potential data exfiltration or communication with a command and control server.
+- Search for any additional alerts or logs related to the same user or system that might indicate a broader pattern of suspicious activity or compromise.
+
+### False positive analysis
+
+- Legitimate troubleshooting activities by IT staff or automated scripts may trigger this rule. To manage this, identify and whitelist known IT tools or scripts that regularly use msdt.exe for diagnostics.
+- Software updates or installations that use msdt.exe as part of their process can be mistaken for suspicious activity. Monitor and document these processes, and create exceptions for recognized software update paths.
+- Users accessing legitimate troubleshooting packs from network locations or URLs might cause false positives. Review and whitelist trusted network paths or domains frequently used for legitimate troubleshooting purposes.
+- Certain applications, like browsers or email clients, may inadvertently launch msdt.exe during normal operations. Identify these applications and consider excluding them from the parent process list if they are consistently non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further potential spread of malicious activity.
+- Terminate the msdt.exe process if it is confirmed to be executing from a suspicious path or with an unusual parent process.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants.
+- Review and analyze the suspicious diagcab file and its source to determine the extent of the compromise and any additional payloads or scripts that may have been executed.
+- Restore any affected files or system components from known good backups if any legitimate files were altered or deleted during the incident.
+- 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 additional monitoring and alerting for similar msdt.exe executions from unusual paths or with unexpected parent processes to enhance detection and prevent recurrence."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
index 2627af83080..fc4f5b5a55d 100644
--- a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
+++ b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/05"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,40 @@ sequence with maxspan=1m
     not process.name : "msiexec.exe" and
     not (process.executable : ("?:\\Program Files (x86)\\*.exe", "?:\\Program Files\\*.exe") and process.code_signature.trusted == true)]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows Installer with Suspicious Properties
+
+The Windows Installer, or msiexec.exe, is a legitimate system utility used for installing, maintaining, and removing software. Adversaries may exploit it to execute malicious MSI files, bypassing security measures like application whitelisting. The detection rule identifies suspicious installer activity by monitoring registry changes and process executions linked to msiexec.exe, focusing on unusual sources or untrusted signatures.
+
+### Possible investigation steps
+
+- Review the registry change event details to identify the specific registry value and data strings involved, focusing on "InstallSource", "DisplayName", or "ProductName" to determine if they match suspicious patterns like temporary archive paths or "SetupTest".
+- Examine the process execution details to identify the child process started by msiexec.exe, noting its name and executable path, especially if it is not located in trusted directories like "Program Files" or "Program Files (x86)".
+- Check the code signature of the executed process to verify if it is untrusted, which could indicate a potential threat.
+- Investigate the source of the MSI file, whether local or network-based, to determine if it is from a known and trusted source or if it appears suspicious.
+- Correlate the alert with any recent user activity or changes in the system environment that might explain the execution of the installer, such as software updates or installations.
+- Look for any additional alerts or logs related to the same user or system around the time of the alert to identify potential patterns or related suspicious activities.
+
+### False positive analysis
+
+- Legitimate software installations from compressed archives may trigger alerts. Users can create exceptions for known software sources by specifying trusted archive paths in the rule configuration.
+- Internal software testing environments might use temporary or test names like "SetupTest" for legitimate purposes. Exclude these specific registry values or paths if they are part of routine operations.
+- Custom or in-house applications installed from non-standard directories may be flagged. Ensure these applications have trusted code signatures or add their paths to an allowlist to prevent false positives.
+- Frequent updates or installations from network shares within a controlled environment can be mistaken for suspicious activity. Define exceptions for these network paths if they are verified and secure.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential malicious sources.
+- Terminate any suspicious processes initiated by msiexec.exe that are not signed by trusted vendors or originate from unusual directories.
+- Remove any unauthorized or suspicious MSI files identified in the registry paths, especially those originating from temporary or archive directories.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or remnants.
+- Review and restore any altered registry settings to their original state to ensure system integrity and prevent unauthorized software installations.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring and alerting for similar activities, focusing on msiexec.exe executions from untrusted sources or with unusual properties, to enhance future detection capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_posh_defender_tampering.toml b/rules_building_block/defense_evasion_posh_defender_tampering.toml
index d512e623895..830bfd439f3 100644
--- a/rules_building_block/defense_evasion_posh_defender_tampering.toml
+++ b/rules_building_block/defense_evasion_posh_defender_tampering.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/09/11"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -60,6 +60,40 @@ event.category: "process" and host.os.type:windows and
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Windows Defender Tampering Capabilities
+
+PowerShell, a powerful scripting language in Windows, can be exploited by adversaries to disable Windows Defender features, reducing detection risks. Attackers may use specific cmdlets to impair antivirus defenses, facilitating payload execution. The detection rule identifies scripts attempting such tampering by monitoring for key cmdlets and parameters indicative of defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text to identify the specific cmdlets and parameters used, focusing on those related to disabling Windows Defender features such as Set-MpPreference.
+- Check the event logs for the process category to gather additional context about the execution environment, including the user account and host involved.
+- Investigate the timeline of events to determine if the script execution coincides with other suspicious activities, such as unauthorized access attempts or unusual network traffic.
+- Analyze the host's security logs to assess whether any Windows Defender features were successfully disabled and if there are subsequent signs of malware or unauthorized changes.
+- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or indicators of a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts may use cmdlets like Set-MpPreference for valid configuration changes. Review the script's context and purpose to determine if it aligns with expected administrative tasks.
+- Automated system management tools might trigger this rule when configuring Windows Defender settings as part of routine maintenance. Identify and whitelist these tools to prevent unnecessary alerts.
+- Security software updates or patches could temporarily disable certain Windows Defender features, leading to false positives. Monitor update schedules and correlate alerts with known update activities.
+- Custom scripts developed for internal use may include these cmdlets for specific security configurations. Validate the script's origin and intent, and consider excluding them if they are verified as safe.
+- Training or testing environments might intentionally disable certain features for educational purposes. Ensure these environments are properly segmented and documented to avoid confusion with genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further tampering or spread of malicious activities.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing tampering attempts.
+- Conduct a thorough scan of the isolated system using an updated antivirus solution to identify and remove any malicious payloads or scripts.
+- Restore Windows Defender settings to their default state to ensure all protective features are re-enabled.
+- Review and update endpoint protection policies to prevent unauthorized changes to security settings, ensuring only trusted administrators have the necessary permissions.
+- Monitor the network for any additional systems exhibiting similar behavior, indicating a broader compromise.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
index ed5067dbc9e..2f6bb89c504 100644
--- a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
+++ b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,40 @@ event.category:process and host.os.type:windows and
   ) and
   not file.directory : "C:\Program Files\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.Configuration"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Log Clear Capabilities
+
+PowerShell, a powerful scripting language in Windows, enables automation and configuration management. Adversaries exploit its capabilities to clear event logs, erasing traces of their activities to evade detection. The detection rule identifies suspicious PowerShell commands linked to log deletion, excluding benign scripts and known safe directories, thus highlighting potential malicious behavior.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text to confirm the presence of suspicious commands such as "Clear-EventLog" or "Remove-EventLog" and assess whether they are part of legitimate administrative activities or potentially malicious actions.
+- Check the file directory from which the PowerShell script was executed to ensure it is not from a known safe directory like "C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration".
+- Investigate the process execution details, including the parent process, to determine if the PowerShell activity is part of a larger chain of suspicious behavior.
+- Correlate the event with other logs and alerts from the same host to identify any additional indicators of compromise or related suspicious activities.
+- Examine the user account associated with the PowerShell execution to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior or role.
+
+### False positive analysis
+
+- Scripts from trusted directories like C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration may trigger alerts. Exclude these directories in the rule configuration to prevent false positives.
+- Legitimate administrative tasks using PowerShell cmdlets such as Clear-EventLog for routine maintenance can be mistaken for malicious activity. Identify and whitelist these specific scripts or tasks to avoid unnecessary alerts.
+- PowerShell modules exporting benign cmdlets like Add-Content might be flagged. Ensure these modules are recognized and excluded by updating the rule to ignore known safe script block texts.
+- Scheduled tasks or automated scripts that perform log management as part of system health checks can be misinterpreted. Document and exclude these tasks from the detection rule to reduce false positives.
+- Security tools or monitoring solutions that use PowerShell for log management should be reviewed and excluded if they are known to be safe and necessary for operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing log clearing activities.
+- Conduct a thorough review of the affected system's event logs and other forensic data to identify any additional malicious activities or indicators of compromise.
+- Restore cleared event logs from backups if available, to aid in further investigation and maintain historical data integrity.
+- Change all credentials used on the affected system, as attackers may have gained access to sensitive information during their activities.
+- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of log clearing or other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
index c5e63bbb893..1f8d689dba2 100644
--- a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
+++ b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,40 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name : "* "
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Processes with Trailing Spaces
+
+In Linux and macOS environments, processes can be manipulated by appending trailing spaces to their names, a tactic used by adversaries to disguise malicious activities as legitimate processes. This evasion technique exploits default file handling, which often overlooks such anomalies. The detection rule identifies these deceptive processes by monitoring for execution events with names ending in spaces, flagging potential masquerading attempts.
+
+### Possible investigation steps
+
+- Review the process name that triggered the alert to confirm the presence of trailing spaces, which may indicate an attempt to masquerade as a legitimate process.
+- Examine the parent process of the suspicious process to determine if it was spawned by a known legitimate application or a potentially malicious one.
+- Check the user account associated with the process execution to assess if it aligns with expected behavior or if it might be compromised.
+- Investigate the command line arguments used during the process execution to identify any unusual or unexpected parameters that could suggest malicious intent.
+- Correlate the event with other logs or alerts from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader attack.
+
+### False positive analysis
+
+- System utilities or scripts with trailing spaces in their names may trigger alerts. Review these processes to confirm their legitimacy and consider adding them to an exception list if they are verified as non-threatening.
+- Custom applications or development scripts that inadvertently include trailing spaces in their process names can cause false positives. Regularly audit these applications and educate developers to avoid such naming conventions.
+- Automated deployment or configuration management tools might create processes with trailing spaces as part of their operations. Identify these tools and exclude them from monitoring if they are confirmed to be safe.
+- Legacy software that uses unconventional naming practices, including trailing spaces, should be assessed for security risks. If deemed safe, these can be added to an exclusion list to prevent unnecessary alerts.
+- Regularly update and review the exception list to ensure that only verified non-threatening processes are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified with trailing spaces in their names to halt any ongoing malicious activity.
+- Conduct a thorough review of the system's process logs and execution history to identify any additional instances of masquerading or related suspicious activities.
+- Restore the affected system from a known good backup to ensure any malicious modifications are removed.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for process execution events, specifically focusing on anomalies such as trailing spaces in process names, to improve detection capabilities.
+- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_service_disabled_registry.toml b/rules_building_block/defense_evasion_service_disabled_registry.toml
index c1f1d49dab7..9cad11ccc64 100644
--- a/rules_building_block/defense_evasion_service_disabled_registry.toml
+++ b/rules_building_block/defense_evasion_service_disabled_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,41 @@ registry where host.os.type == "windows" and event.type == "change" and
     )
   and not registry.path : "HKLM\\SYSTEM\\ControlSet001\\Services\\MrxSmb10\\Start"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Service Disabled via Registry Modification
+
+Windows services are crucial for system operations, often configured via the registry. Adversaries may alter service start settings to disable security tools, evading detection. This detection rule identifies unauthorized registry changes to service start values, excluding legitimate processes like services.exe. By monitoring specific registry paths and values, it flags potential defense evasion attempts, aiding in timely threat response.
+
+### Possible investigation steps
+
+- Review the registry event details to identify the specific service affected by the registry modification, focusing on the registry.path field.
+- Investigate the process responsible for the change by examining the process.name and process.id fields to determine if it is a known or suspicious application.
+- Check the user.id associated with the event to verify if the change was made by an authorized user or account.
+- Correlate the event with other recent security alerts or logs to identify any patterns or additional suspicious activities on the host.
+- Assess the impact of the service modification by determining if the service is critical for security or monitoring, and evaluate the potential risk to the system.
+- If the service is related to security or monitoring, consider restoring the original registry settings and conducting a full system scan to ensure no further compromise.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify service start settings. Users can create exceptions for known update processes by identifying their process names and user IDs.
+- System administrators may intentionally change service configurations for maintenance or optimization. Document these changes and exclude them by specifying the responsible process names and user IDs.
+- Some third-party management tools might alter service settings as part of their normal operation. Identify these tools and exclude their process names from the detection rule.
+- Custom scripts or automation tasks that modify service settings for legitimate purposes should be reviewed and excluded by adding their process names to the exception list.
+- Regularly review and update the exclusion list to ensure it reflects current legitimate activities while minimizing the risk of overlooking potential threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized changes or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as modifying the registry, especially those not associated with legitimate system operations like services.exe.
+- Restore the modified registry settings to their original state using a known good backup or by manually resetting the service start values to their default configuration.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced.
+- Review and analyze system logs and security alerts to identify any additional indicators of compromise or related suspicious activities that may require further investigation.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if the threat has impacted other systems within the network.
+- Implement enhanced monitoring and alerting for registry changes on critical systems to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_service_path_registry.toml b/rules_building_block/defense_evasion_service_path_registry.toml
index d8411c0a57f..64f93228773 100644
--- a/rules_building_block/defense_evasion_service_path_registry.toml
+++ b/rules_building_block/defense_evasion_service_path_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,39 @@ registry where host.os.type == "windows" and event.type == "change" and
     )
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Service Path Modification
+Service paths in Windows define the executable location for services. Adversaries may alter these paths to execute malicious code, achieving persistence or privilege escalation. The detection rule identifies unusual modifications to service paths by monitoring registry changes, specifically targeting paths not associated with standard system processes, thus flagging potential unauthorized alterations.
+
+### Possible investigation steps
+
+- Review the registry path specified in the alert to confirm the exact service path that was modified, focusing on paths like HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath.
+- Identify the process that made the change by examining the process.executable field in the alert, and determine if it is a known or expected application.
+- Check the modification history of the service path to see if there have been any previous changes and if they were made by legitimate processes.
+- Investigate the executable specified in the modified service path to determine if it is a legitimate application or potentially malicious.
+- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activity or patterns.
+- Assess the risk and impact of the modification by determining if the service is critical and if the change could lead to persistence or privilege escalation.
+
+### False positive analysis
+
+- Legitimate software updates or installations may modify service paths, triggering the rule. Users can create exceptions for known update processes by adding their executables to the exclusion list.
+- Custom or in-house applications installed in non-standard directories might be flagged. Verify these applications and add their paths to the exclusion list if they are deemed safe.
+- Administrative scripts or tools that modify service configurations as part of routine maintenance can cause alerts. Identify these scripts and exclude their execution paths to prevent false positives.
+- Security software or system management tools that alter service paths for legitimate reasons may be detected. Confirm their legitimacy and add them to the exclusion criteria to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified as modifying the service path, especially those not originating from standard system directories.
+- Restore the modified service path to its original, legitimate state using system backups or by manually correcting the registry entry.
+- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious software.
+- Review and audit user accounts and permissions on the affected system to ensure no unauthorized privilege escalations have occurred.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement enhanced monitoring and logging for registry changes and service path modifications to detect similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_services_exe_path.toml b/rules_building_block/defense_evasion_services_exe_path.toml
index f31ea296712..b7ec1dbe8be 100644
--- a/rules_building_block/defense_evasion_services_exe_path.toml
+++ b/rules_building_block/defense_evasion_services_exe_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,41 @@ query = '''
 process where event.type == "start" and process.name : "sc.exe" and
   process.args : "*config*" and process.args : "*binPath*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Service Path Modification via sc.exe
+
+The `sc.exe` utility is a command-line tool used in Windows environments to manage services. Adversaries may exploit this tool to alter service paths, enabling persistence or privilege escalation by redirecting service execution to malicious binaries. The detection rule identifies suspicious modifications by monitoring for `sc.exe` executions that include specific arguments related to service configuration changes, signaling potential unauthorized service path alterations.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of "sc.exe" with arguments containing "config" and "binPath" to verify the alert's legitimacy.
+- Identify the user account associated with the "sc.exe" process execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.
+- Examine the service name and the new binary path specified in the "sc.exe" command to assess if the path points to a known or suspicious executable.
+- Check the modification history of the service in question to identify any recent changes and correlate them with other system events or alerts.
+- Investigate the source and destination of the binary path to ensure it is not linked to known malicious files or locations.
+- Review related system logs and security events around the time of the alert to identify any additional suspicious activities or patterns.
+
+### False positive analysis
+
+- Routine administrative tasks using sc.exe may trigger alerts. System administrators often use sc.exe to configure services during maintenance or updates. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Software installations or updates might modify service paths as part of their setup process. Identify and whitelist trusted software installers or update processes to prevent unnecessary alerts.
+- Automated scripts or management tools that use sc.exe for legitimate service management can cause false positives. Review and exclude these scripts or tools by their process hash or command line patterns.
+- Security software or monitoring tools may use sc.exe to adjust service configurations for protection purposes. Verify and exclude these tools by their digital signatures or known process names to reduce noise.
+- Development environments where services are frequently started, stopped, or reconfigured for testing purposes can generate alerts. Implement exclusions for development machines or specific user accounts involved in testing.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes related to the modified service path to halt potential malicious execution.
+- Restore the original service path configuration by reviewing system logs or backups to identify the legitimate service path and revert any unauthorized changes.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any malicious binaries that may have been introduced.
+- Review user and service account permissions to ensure that only authorized personnel have the ability to modify service configurations, and adjust permissions as necessary.
+- Monitor for any further attempts to modify service paths using sc.exe by setting up alerts for similar command-line patterns to detect and respond to future incidents promptly.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
index 6928b4187a8..0cc93ccecfc 100644
--- a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
+++ b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/26"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,6 +68,41 @@ process where host.os.type == "windows" and event.action == "start" and
 
   not process.args : ("?:\\Program Files (x86)\\*", "?:\\Program Files\\*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Execution via MSIEXEC
+
+MSIEXEC is a Windows Installer utility used for installing, modifying, and removing applications. Adversaries exploit it to execute malicious MSI files, often using silent install options to avoid detection. The detection rule identifies unusual MSIEXEC activity by analyzing execution context, such as unexpected parent processes or atypical file paths, to flag potential misuse indicative of defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the parent process of the msiexec.exe execution to determine if it is an unexpected or suspicious executable, especially if it is not from typical locations like Program Files or Windows directories.
+- Analyze the command line arguments used with msiexec.exe, focusing on the presence of silent install options (/q, /quiet) and the number of arguments to identify potential misuse.
+- Check the file path of the MSI file being executed to ensure it is not from unusual or user-specific directories like Users or ProgramData, which could indicate a malicious file.
+- Investigate the user account associated with the execution, particularly if the user ID matches patterns like S-1-5-21* or S-1-12-*, to assess if the account has been compromised or is being used for unauthorized activities.
+- Examine the working directory and any related files or scripts in the context of the execution to identify any additional indicators of compromise or related malicious activity.
+- Correlate the event with other security alerts or logs to determine if this execution is part of a broader attack pattern or campaign.
+
+### False positive analysis
+
+- Legitimate software installations or updates may trigger the rule if they use msiexec.exe with silent install options. Users can create exceptions for known software paths or parent processes that frequently perform legitimate installations.
+- System administrators using scripts or automation tools like PowerShell or CMD to deploy software across multiple machines might cause false positives. Exclude these specific parent processes or command line patterns if they are part of routine administrative tasks.
+- Some enterprise software management tools may use msiexec.exe in a manner that matches the rule's criteria. Identify these tools and exclude their typical execution paths or parent processes to prevent unnecessary alerts.
+- Temporary files created during legitimate installations in user directories might be flagged. Consider excluding specific temporary directories or known MSI file patterns that are part of regular software deployment processes.
+- Regular updates from trusted software vendors that use msiexec.exe with quiet options can be excluded by identifying and whitelisting their specific update paths or parent processes.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Terminate the suspicious msiexec.exe process to halt any ongoing malicious activity.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software.
+- Review and analyze the parent process and command line arguments associated with the msiexec.exe execution to understand the attack vector and entry point.
+- Restore any affected files or applications from a known good backup to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement additional monitoring and alerting for similar msiexec.exe activities to enhance detection and prevent recurrence of this threat."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unsigned_bits_client.toml b/rules_building_block/defense_evasion_unsigned_bits_client.toml
index 84012c3b2d4..bcaee625048 100644
--- a/rules_building_block/defense_evasion_unsigned_bits_client.toml
+++ b/rules_building_block/defense_evasion_unsigned_bits_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,40 @@ library where dll.name : "Bitsproxy.dll" and process.executable != null and
 not process.code_signature.trusted == true and
 not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unsigned BITS Service Client Process
+
+The Windows Background Intelligent Transfer Service (BITS) facilitates asynchronous, prioritized, and throttled transfer of files between machines, often used for updates. Adversaries exploit BITS to stealthily download or upload data, bypassing traditional security measures. The detection rule identifies anomalies by flagging processes using BITS without a valid code signature, indicating potential misuse for evasion or masquerading tactics.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if it is a known or expected application using BITS. Investigate any unfamiliar or suspicious executables.
+- Check the process code signature details to understand why it is untrusted. Look for any discrepancies or missing signatures that could indicate tampering.
+- Investigate the parent process of the unsigned BITS client process to identify how it was initiated and assess if the parent process is legitimate or potentially malicious.
+- Analyze network activity associated with the process to identify any unusual or unauthorized data transfers, focusing on external connections that could indicate data exfiltration or command and control communication.
+- Cross-reference the process and its associated files with threat intelligence sources to determine if they are linked to known malicious activity or threat actors.
+- Review recent system changes or updates that might have introduced the unsigned process, such as new software installations or updates, to assess if they are legitimate or potentially compromised.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they use BITS without a valid code signature. Users can create exceptions for known software update processes that are verified as safe.
+- Custom or in-house applications that utilize BITS for file transfers might not have a valid code signature. These can be whitelisted by verifying their source and ensuring they are part of the organization's approved software inventory.
+- Development or testing environments often run unsigned applications that use BITS for data transfer. Exclude these environments from the rule to prevent unnecessary alerts, ensuring they are properly isolated from production systems.
+- Some third-party security tools or network management software may use BITS in a way that triggers the rule. Confirm the legitimacy of these tools and add them to an exception list if they are deemed non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further data exfiltration or malicious activity.
+- Terminate the unsigned BITS client process to stop any ongoing unauthorized data transfers.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats.
+- Review and analyze the process execution history and associated files to determine the source and intent of the unsigned BITS client process.
+- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the organization.
+- Implement enhanced monitoring and logging for BITS-related activities to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unusual_process_extension.toml b/rules_building_block/defense_evasion_unusual_process_extension.toml
index 62072e9e4ed..0fdcf0f4bd2 100644
--- a/rules_building_block/defense_evasion_unusual_process_extension.toml
+++ b/rules_building_block/defense_evasion_unusual_process_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,41 @@ process where host.os.type == "windows" and event.type == "start" and
     (process.name: "AGSRunner.bin" and process.code_signature.subject_name: "Intel Corporation")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process Extension
+
+In Windows environments, processes typically run with standard executable extensions like .exe or .com. Adversaries may exploit this by using non-standard extensions to disguise malicious activities, evading detection. The 'Unusual Process Extension' rule identifies such anomalies by flagging processes with uncommon extensions, excluding known legitimate cases, thus helping to uncover potential masquerading tactics.
+
+### Possible investigation steps
+
+- Review the process executable path and name to determine if it matches any known legitimate software or if it appears suspicious or unfamiliar.
+- Check the process code signature details, if available, to verify the authenticity of the process and identify the publisher. Pay special attention to any discrepancies or unsigned executables.
+- Investigate the parent process that initiated the unusual process to understand the context of its execution and assess if the parent process is legitimate or potentially compromised.
+- Search for any related network activity or connections initiated by the process to identify potential communication with malicious or suspicious external hosts.
+- Examine the file creation and modification timestamps of the process executable to determine if it aligns with expected software updates or installations.
+- Cross-reference the process with threat intelligence sources to identify if it is associated with known malware or threat actors.
+- Review system logs and other endpoint data for additional indicators of compromise or related suspicious activities that may provide further context to the alert.
+
+### False positive analysis
+
+- Processes with extensions like .p5x, .bin, or .dep from known software such as Dell SupportAssist, Intel AGS, or Docker may trigger false positives. Users can mitigate this by adding these specific paths to the exclusion list.
+- Signed executables from trusted vendors like Dell Inc, Bloomberg LP, Adobe Inc, and McAfee, LLC may be flagged. Verify the code signature and add these to exceptions if they are legitimate.
+- Processes related to software management or security tools, such as those from Veeam Software Group GmbH or Panda Security, might be incorrectly identified. Confirm their legitimacy and exclude them if necessary.
+- Regularly review and update the exclusion list to include new legitimate software that may use uncommon extensions, ensuring the rule remains effective without generating unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potential malicious activity.
+- Terminate any suspicious processes identified with unusual extensions that do not match known legitimate cases.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files.
+- Review and restore any altered system configurations or files to their original state, ensuring system integrity.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement application whitelisting to prevent execution of unauthorized or unusual file extensions in the future.
+- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar masquerading tactics."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
index f5ab763eba2..076c75ad9e0 100644
--- a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
+++ b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -53,6 +53,42 @@ process where host.os.type == "windows" and event.type == "start" and
     "wmiprvse.exe"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process Execution on WBEM Path
+
+The Windows Management Instrumentation (WMI) is a core component for managing data and operations on Windows systems. It is often targeted by adversaries for executing malicious payloads under the guise of legitimate processes. The detection rule identifies non-standard processes executing from the WBEM directory, a typical location for WMI binaries, by filtering out known legitimate executables, thus highlighting potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process executable path to confirm it matches the WBEM directory paths specified in the query (?:\\Windows\\System32\\wbem\\* or ?:\\Windows\\SysWow64\\wbem\\*).
+- Identify the process name and compare it against the list of known legitimate WMI-related executables to ensure it is not mistakenly flagged.
+- Gather additional context on the process by checking its parent process and command line arguments to understand how it was initiated.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Check for any recent changes or anomalies in the system's WMI configuration or related services that could suggest tampering or misuse.
+- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
+- If suspicious, isolate the host for further forensic analysis and consider running a full malware scan to detect any hidden threats.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools may occasionally execute from the WBEM path, especially in environments with custom management scripts. Review and document any such scripts to determine if they are benign.
+- Scheduled tasks or automated processes that utilize WMI for legitimate purposes might trigger this rule. Identify and whitelist these tasks to prevent unnecessary alerts.
+- Software updates or installations that temporarily use the WBEM directory for execution can be mistaken for unusual activity. Monitor and verify these processes during known update windows.
+- Security or monitoring tools that interact with WMI may execute processes from the WBEM path. Ensure these tools are recognized and excluded from the rule to avoid false positives.
+- In environments with custom WMI providers or extensions, additional executables may be present in the WBEM directory. Validate these custom components and adjust the rule to exclude them if they are verified as safe.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified running from the WBEM path that are not part of the known legitimate executables list.
+- 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 files.
+- Review recent system changes and restore any altered or maliciously modified system files from a known good backup.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and network to detect any further attempts to execute unauthorized processes from the WBEM path.
+- Update security policies and endpoint protection configurations to block execution of unauthorized processes from the WBEM directory in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/defense_evasion_write_dac_access.toml b/rules_building_block/defense_evasion_write_dac_access.toml
index de838caec6d..6624b04b3bf 100644
--- a/rules_building_block/defense_evasion_write_dac_access.toml
+++ b/rules_building_block/defense_evasion_write_dac_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -61,6 +61,40 @@ query = '''
 host.os.type: "windows" and event.action : ("Directory Service Access" or "object-operation-performed") and
   event.code : "4662" and winlog.event_data.AccessMask:"0x40000"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WRITEDAC Access on Active Directory Object
+
+WRITEDAC permissions allow modification of an object's access control list in Active Directory, crucial for managing access rights. Adversaries exploit this to alter permissions, enabling unauthorized access and privilege escalation. The detection rule identifies such abuse by monitoring specific Windows events and access masks, flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the event logs for event code 4662 to identify the specific object and user account involved in the WRITEDAC access attempt.
+- Examine the winlog.event_data.AccessMask field for the value "0x40000" to confirm the modification of the Discretionary Access Control List (DACL).
+- Investigate the user account associated with the WRITEDAC access to determine if it has a history of suspicious activity or if it has been compromised.
+- Check the Active Directory object that was accessed to understand its role and importance within the network, and assess the potential impact of unauthorized access.
+- Analyze recent changes to the object's access control list to identify any unauthorized modifications or privilege escalations.
+- Correlate this event with other security alerts or logs to identify patterns or additional indicators of compromise that may suggest a broader attack campaign.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger WRITEDAC alerts when legitimate users modify access control lists as part of their job. To manage this, create exceptions for known administrative accounts performing regular maintenance.
+- Automated scripts or tools used for Active Directory management might generate false positives if they modify access control lists. Identify these scripts and whitelist their activity to prevent unnecessary alerts.
+- Software installations or updates that require changes to access control lists can also cause false positives. Monitor and document these activities, and consider excluding them from the rule if they are verified as safe.
+- Changes made by security tools that automatically adjust permissions for compliance or security hardening purposes may be flagged. Review these tools' activities and exclude them if they are part of a controlled process.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Revoke any unauthorized permissions or access rights granted through the WRITEDAC abuse by restoring the original Access Control List (ACL) settings on the compromised Active Directory object.
+- Conduct a thorough review of recent changes to the ACLs of critical Active Directory objects to identify any additional unauthorized modifications.
+- Reset passwords and review access rights for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.
+- Implement enhanced monitoring and alerting for similar WRITEDAC access attempts by adjusting logging and alert thresholds to detect future unauthorized access attempts promptly.
+- Review and update security policies and access controls to ensure that only authorized personnel have the necessary permissions to modify ACLs, reducing the risk of similar incidents in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_capnetraw_capability.toml b/rules_building_block/discovery_capnetraw_capability.toml
index 7fd2ca5a2a7..1a0db2aafaa 100644
--- a/rules_building_block/discovery_capnetraw_capability.toml
+++ b/rules_building_block/discovery_capnetraw_capability.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/01/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,41 @@ event.category:"process" and host.os.type:"linux" and event.type:"start" and eve
 (process.thread.capabilities.effective:"CAP_NET_RAW" or process.thread.capabilities.permitted:"CAP_NET_RAW") and
 not user.id:"0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Network Traffic Capture via CAP_NET_RAW
+
+CAP_NET_RAW is a Linux capability that allows processes to create raw sockets, enabling them to send and receive packets directly at the network layer. This capability is crucial for network utilities but can be exploited by adversaries to intercept and manipulate network traffic, bypassing access controls. The detection rule identifies non-root processes with CAP_NET_RAW, flagging potential unauthorized network sniffing activities.
+
+### Possible investigation steps
+
+- Review the process details by examining the process.name field to identify the specific application or service that triggered the alert.
+- Check the user.id field to determine which non-root user is associated with the process, and assess whether this user should have CAP_NET_RAW capabilities.
+- Investigate the event.category and event.type fields to confirm the context of the process start event and ensure it aligns with expected behavior for the identified process.
+- Analyze the host.os.type field to verify the operating system environment and consider any specific configurations or security measures in place on the Linux host.
+- Correlate the event.action field with other recent events on the system to identify any unusual patterns or sequences of actions that might indicate malicious activity.
+- Consult system logs and network traffic data to gather additional context around the time of the alert, looking for signs of unauthorized network sniffing or manipulation.
+
+### False positive analysis
+
+- Network diagnostic tools like tcpdump or Wireshark may trigger this rule when used by non-root users. To manage this, create exceptions for these specific processes if they are part of regular network monitoring activities.
+- Custom scripts or applications developed in-house that require network packet analysis might also be flagged. Review these processes and, if deemed safe, add them to an allowlist to prevent future alerts.
+- Security software or monitoring agents that operate with CAP_NET_RAW for legitimate purposes can be identified as false positives. Verify their legitimacy and configure exceptions to avoid unnecessary alerts.
+- Development or testing environments where non-root users are granted CAP_NET_RAW for specific tasks may cause alerts. Ensure these environments are well-documented and apply exceptions where appropriate to reduce noise.
+- Automated deployment tools that temporarily use CAP_NET_RAW during setup or configuration might be flagged. Confirm their activity is expected and safe, then exclude them from the rule to streamline operations.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized network traffic sniffing and potential data exfiltration.
+- Terminate the suspicious process identified with CAP_NET_RAW capabilities to stop any ongoing malicious activities.
+- Conduct a thorough review of the affected system to identify any unauthorized changes or additional malicious processes that may have been initiated by the same threat actor.
+- Revoke CAP_NET_RAW capabilities from non-essential processes and users to minimize the risk of similar threats in the future.
+- Implement strict firewall rules to limit the types and contents of packets that can be sent and received, reducing the attack surface for network sniffing.
+- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger attack campaign.
+- Enhance monitoring and logging for CAP_NET_RAW capability usage across all systems to improve detection and response times for similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_account_groups.toml b/rules_building_block/discovery_generic_account_groups.toml
index eb8dadcd502..8bff1640ece 100644
--- a/rules_building_block/discovery_generic_account_groups.toml
+++ b/rules_building_block/discovery_generic_account_groups.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,40 @@ process where host.os.type == "windows" and event.type == "start" and
 ) and not process.parent.args: "C:\\Program Files (x86)\\Microsoft Intune Management Extension\\Content\\DetectionScripts\\*.ps1"
 and not process.parent.name : "LTSVC.exe" and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows Account or Group Discovery
+
+Windows environments provide built-in tools for managing and querying user accounts and groups, essential for system administration. However, adversaries exploit these tools to gather information about user accounts and group memberships, aiding in privilege escalation and lateral movement. The detection rule identifies suspicious use of these tools by monitoring specific command executions and arguments, filtering out benign activities to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the process name and arguments to determine if the command execution aligns with typical administrative tasks or if it appears suspicious. Pay particular attention to commands like net.exe, dsquery.exe, and whoami.exe.
+- Check the parent process name and arguments to identify if the command was executed by a legitimate application or script, such as those related to Microsoft Intune Management Extension or LTSVC.exe, which are excluded in the rule.
+- Investigate the user ID associated with the process to determine if it belongs to a legitimate system or service account, especially since the rule excludes the system account S-1-5-18.
+- Analyze the context of the host where the process was executed, including recent login activities, to identify any unusual patterns or unauthorized access attempts.
+- Correlate the alert with other security events or logs from the same host or user to identify potential lateral movement or privilege escalation activities.
+
+### False positive analysis
+
+- Routine administrative tasks using net.exe or net1.exe for legitimate account management may trigger alerts. Exclude these by identifying and whitelisting specific administrative scripts or processes that frequently use these commands.
+- Automated scripts or software updates that query user or group information using dsquery.exe or dsget.exe can be mistaken for threats. Monitor and exclude these processes if they are part of regular maintenance or update routines.
+- Commands executed by cmd.exe to display environment variables like %username% or %userdomain% during login scripts or system checks can be benign. Identify and exclude these scripts if they are part of standard operating procedures.
+- Processes initiated by known management tools such as Microsoft Intune or LTSVC.exe may appear suspicious. Exclude these parent processes to reduce false positives from trusted management software.
+- System accounts, particularly those with user ID S-1-5-18, may execute commands that match the rule criteria. Exclude these system accounts to prevent unnecessary alerts from standard system operations.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, such as those involving net.exe, dsquery.exe, or other flagged applications.
+- Conduct a thorough review of user accounts and group memberships on the affected system to identify any unauthorized changes or additions.
+- Reset passwords for potentially compromised accounts, especially those with elevated privileges, to mitigate the risk of further exploitation.
+- Review and update access controls and permissions to ensure that only authorized users have access to sensitive resources and administrative tools.
+- 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 enhanced monitoring and logging for the affected system and similar environments to detect any recurrence of the threat or related suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_process_discovery.toml b/rules_building_block/discovery_generic_process_discovery.toml
index 5cd753d8699..3addd03e269 100644
--- a/rules_building_block/discovery_generic_process_discovery.toml
+++ b/rules_building_block/discovery_generic_process_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,41 @@ process where host.os.type == "windows" and event.type == "start" and
    (process.name : "query.exe" and process.args : "process")
   ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Discovery Using Built-in Tools
+
+Process discovery tools, like PsList, qprocess, and tasklist, are integral for system administrators to monitor active processes on Windows systems. However, adversaries exploit these tools to identify running applications and security defenses, aiding in further attacks. The detection rule identifies suspicious use of these tools by monitoring specific command executions and arguments, excluding known system accounts, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on processes like PsList.exe, qprocess.exe, powershell.exe, wmic.exe, tasklist.exe, or query.exe.
+- Check the user account associated with the process execution to determine if it is a known or legitimate user, ensuring it is not the system account (S-1-5-18).
+- Investigate the context of the process execution by examining the parent process and any related processes to understand the sequence of events leading to the alert.
+- Analyze the timing and frequency of the process execution to identify any patterns or anomalies that could indicate malicious activity.
+- Correlate the alert with other security events or logs from the same host or user to gather additional context and assess the potential impact or intent of the activity.
+- If necessary, conduct a deeper forensic analysis on the host to identify any signs of compromise or further malicious behavior associated with the process execution.
+
+### False positive analysis
+
+- System maintenance tasks may trigger the rule when administrators use built-in tools for legitimate monitoring or troubleshooting. To manage this, create exceptions for known maintenance scripts or scheduled tasks by excluding specific user accounts or process arguments.
+- Automated monitoring solutions that regularly check system health can cause false positives. Identify these processes and exclude them by specifying their unique process arguments or user IDs in the rule configuration.
+- Software updates or installations might use these tools to verify system compatibility or status, leading to false alerts. Exclude these activities by recognizing the associated user accounts or process names involved in the update procedures.
+- Security software may use similar commands to perform routine checks. Determine which security tools are in use and exclude their known processes or user IDs to prevent unnecessary alerts.
+- Development or testing environments often run scripts that mimic adversarial behavior for testing purposes. Exclude these environments by filtering out specific hostnames or user accounts associated with development activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, such as PsList.exe, qprocess.exe, or unauthorized instances of powershell.exe, wmic.exe, and tasklist.exe.
+- Conduct a thorough review of the system's recent process execution history to identify any additional unauthorized or suspicious activities that may have been missed.
+- Reset credentials for any accounts that were active on the affected system during the time of the alert, especially if they have elevated privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Implement additional monitoring on the affected system and similar systems to detect any recurrence of the suspicious process discovery activities.
+- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar process discovery attempts in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_generic_registry_query.toml b/rules_building_block/discovery_generic_registry_query.toml
index 4370465eb15..c8692fef37a 100644
--- a/rules_building_block/discovery_generic_registry_query.toml
+++ b/rules_building_block/discovery_generic_registry_query.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/12/19"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,41 @@ host.os.type:windows and event.category:process and event.type:start and
     "reg  query \"HKLM\\Software\\WOW6432Node\\Npcap\" /ve  "
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Query Registry using Built-in Tools
+
+The Windows Registry is a critical database for system configuration and application settings. Adversaries exploit built-in tools like `reg.exe` and PowerShell to query the registry, seeking insights into installed software and system configurations. The detection rule identifies suspicious registry queries by monitoring specific command executions, filtering out benign activities, and focusing on potential threats, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the process details, including process.name and process.args, to confirm if the command execution aligns with known legitimate administrative activities or if it appears suspicious.
+- Check the process.command_line field to understand the full context of the command executed and identify any deviations from typical usage patterns.
+- Investigate the user account associated with the process execution to determine if the activity is expected for that user or if it indicates potential unauthorized access.
+- Correlate the event with other recent events involving the same host or user to identify any patterns or sequences that suggest malicious behavior.
+- Examine the host's recent activity logs for any signs of compromise or other suspicious activities that might be related to the registry query.
+- Assess the risk and impact of the queried registry keys, such as HKCU or HKLM, to determine if they contain sensitive information that could be leveraged by an adversary.
+
+### False positive analysis
+
+- Routine system inventory checks by IT management tools may trigger this rule. To handle this, identify and exclude specific command patterns used by these tools from the detection rule.
+- Software update processes often query the registry to verify installation status. Exclude known update processes by adding their command lines to the exception list.
+- Security software may perform regular registry queries as part of its monitoring activities. Review and whitelist these processes to prevent unnecessary alerts.
+- Custom scripts used for system administration might query the registry. Document and exclude these scripts if they are verified as non-threatening.
+- Automated compliance checks that involve registry queries can be excluded by identifying their specific command signatures and adding them to the exception list.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, such as instances of reg.exe or PowerShell executing unauthorized registry queries.
+- Conduct a thorough review of the system's registry to identify any unauthorized changes or entries that may have been made by the adversary.
+- Restore any altered registry settings to their original state using known good configurations or backups.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the suspicious activity.
+- Review and update endpoint protection policies to block unauthorized registry access and enhance detection capabilities for similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_hosts_file_access.toml b/rules_building_block/discovery_hosts_file_access.toml
index 8a3177bf266..f64c5c242ed 100644
--- a/rules_building_block/discovery_hosts_file_access.toml
+++ b/rules_building_block/discovery_hosts_file_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,39 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name in ("vi", "nano", "cat", "more", "less") and process.args == "/etc/hosts"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 System Hosts File Access
+
+The hosts file is a local system file used to map hostnames to IP addresses, crucial for network operations. Adversaries may exploit this by accessing the file to identify potential targets for lateral movement within a network. The detection rule monitors the execution of common text editors and commands accessing the hosts file, flagging potential unauthorized access attempts, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of text editors or commands (vi, nano, cat, more, less) with the argument "/etc/hosts" to determine if the access was intentional or suspicious.
+- Check the user account associated with the process to verify if the access aligns with their role and responsibilities within the organization.
+- Investigate the timing and frequency of the access to the hosts file to identify any unusual patterns or repeated attempts that may indicate malicious intent.
+- Correlate the event with other logs or alerts from the same host or user to identify any additional suspicious activities, such as attempts to access other sensitive files or network resources.
+- Assess the network environment for any recent changes or anomalies that could be related to the access of the hosts file, such as new devices or unexpected network traffic.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often access the hosts file using text editors like vi or nano for legitimate configuration changes. To manage this, create exceptions for known administrator accounts or specific maintenance windows.
+- Automated scripts: Some automated scripts or configuration management tools may access the hosts file as part of their normal operation. Identify these scripts and exclude their process names or execution paths from the rule.
+- System updates: During system updates, certain processes might access the hosts file to ensure network configurations are up-to-date. Monitor update schedules and exclude these processes during known update periods.
+- Development environments: Developers may frequently access the hosts file to test network configurations. Consider excluding access from development machines or specific user accounts associated with development activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough review of recent access logs and process execution history on the affected system to identify any unauthorized access or suspicious activity.
+- Terminate any unauthorized processes that are currently accessing or have accessed the hosts file without legitimate reason.
+- Change credentials for any accounts that were active on the affected system during the time of the alert to prevent unauthorized access using compromised credentials.
+- Restore the hosts file to its original state if any unauthorized modifications are detected, ensuring that no malicious entries have been added.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement enhanced monitoring on the affected system and similar endpoints to detect any future unauthorized access attempts to the hosts file."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_internet_capabilities.toml b/rules_building_block/discovery_internet_capabilities.toml
index 2ae9e761e72..c77f9ea4b66 100644
--- a/rules_building_block/discovery_internet_capabilities.toml
+++ b/rules_building_block/discovery_internet_capabilities.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,39 @@ host.os.type:windows and event.category:process and event.type:start and
 process.name.caseless:("ping.exe" or "tracert.exe" or "pathping.exe") and
 not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Discovery of Internet Capabilities via Built-in Tools
+
+Built-in network diagnostic tools like ping, tracert, and pathping are essential for assessing connectivity and network paths in Windows environments. Adversaries exploit these tools to verify internet access and map network routes, aiding in communication with command and control servers. The detection rule identifies suspicious use of these tools by monitoring process executions that target external IPs, excluding common local addresses, thus flagging potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the specific built-in tool used (ping.exe, tracert.exe, or pathping.exe) and the external IP addresses targeted.
+- Examine the user account and host associated with the process execution to determine if the activity aligns with expected behavior or if it appears suspicious.
+- Check for any related network activity or connections to the external IP addresses identified, focusing on unusual or unauthorized communication patterns.
+- Investigate the historical activity of the involved user and host to identify any previous suspicious behavior or patterns that might indicate compromise.
+- Correlate the alert with other security events or logs from the same timeframe to identify potential indicators of compromise or related malicious activity.
+
+### False positive analysis
+
+- Routine network diagnostics by IT staff can trigger alerts when using tools like ping, tracert, or pathping to troubleshoot connectivity issues. To manage this, create exceptions for known IT user accounts or specific IP ranges frequently used for legitimate diagnostics.
+- Automated monitoring systems or scripts that regularly check network connectivity might be flagged. Identify these systems and exclude their process executions from the rule to prevent unnecessary alerts.
+- Software updates or installations that verify internet connectivity as part of their process can also be mistaken for suspicious activity. Whitelist these specific processes or applications to reduce false positives.
+- Internal network testing by security teams may involve the use of these tools to map network paths. Coordinate with security teams to ensure their activities are recognized and excluded from detection rules.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further communication with potential command and control servers.
+- Terminate any suspicious processes identified by the alert, specifically those involving ping.exe, tracert.exe, or pathping.exe targeting external IPs.
+- Conduct a thorough review of the system's network configuration and routing tables to identify any unauthorized changes or suspicious routes.
+- Scan the system for additional indicators of compromise, such as unusual network traffic patterns or unauthorized software installations.
+- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that all security patches and updates are applied.
+- Implement network monitoring to detect and alert on similar suspicious activities in the future, focusing on unusual use of diagnostic tools.
+- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to determine if the threat is part of a larger attack campaign."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
index e6ea704526d..d53f3759ada 100644
--- a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
+++ b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/12"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,40 @@ query = '''
 host.os.type:linux and event.category:file and event.action:"opened-file" and file.path:"/proc/modules" and
 not process.name:(python* or chef-client)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Enumeration of Kernel Modules via Proc
+
+Loadable Kernel Modules (LKMs) enhance Linux kernel functionality dynamically. The `/proc/modules` file lists these modules, aiding utilities like `lsmod` in module management. Adversaries may exploit this to gather system details, aiding in further attacks. The detection rule identifies unauthorized access to `/proc/modules`, excluding benign processes, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process that accessed /proc/modules, focusing on the process name and its parent process.
+- Investigate the source of the process by examining the user account associated with the process and checking for any unusual or unauthorized user activity.
+- Analyze the command line arguments and execution context of the process to determine if the access was part of a legitimate operation or a potential reconnaissance attempt.
+- Check the system's recent login history and network connections to identify any suspicious activity that might correlate with the alert.
+- Cross-reference the process with known benign processes that are excluded in the query (e.g., python*, chef-client) to ensure it is not mistakenly flagged.
+- Review system logs and audit logs for any other related activities or anomalies around the time of the alert to gather additional context.
+
+### False positive analysis
+
+- System management tools like configuration management software may access /proc/modules as part of routine operations. Exclude these processes by adding them to the exception list in the detection rule.
+- Monitoring or diagnostic tools that regularly check system status might open /proc/modules. Identify these tools and update the rule to exclude their process names.
+- Custom scripts used for system maintenance or monitoring could trigger the rule. Review these scripts and, if they are verified as safe, add their process names to the exclusion list.
+- Automated security scans or compliance checks might access /proc/modules. Determine if these are legitimate and adjust the rule to prevent false alerts by excluding the relevant process names.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Conduct a thorough review of the process that accessed /proc/modules to determine if it is a legitimate process or a potential threat actor.
+- If unauthorized access is confirmed, terminate the suspicious process and remove any associated malicious binaries or scripts from the system.
+- Review system logs and audit trails to identify any additional unauthorized access attempts or related suspicious activities.
+- Update and patch the system to ensure all software, especially kernel-related components, are up to date to mitigate known vulnerabilities.
+- Implement stricter access controls and monitoring on critical files and directories, such as /proc/modules, to prevent unauthorized access in the future.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_modprobe_enumeration.toml b/rules_building_block/discovery_linux_modprobe_enumeration.toml
index 1a41af5ad2f..bfe8b45b86b 100644
--- a/rules_building_block/discovery_linux_modprobe_enumeration.toml
+++ b/rules_building_block/discovery_linux_modprobe_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/08"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,41 @@ file.path : ("/etc/modprobe.conf" or "/etc/modprobe.d" or /etc/modprobe.d/*) and
   aide or modprobe or python*
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Modprobe File Event
+
+Modprobe manages Linux kernel modules, crucial for system functionality. Adversaries may exploit modprobe configurations to load unauthorized modules, potentially bypassing security, escalating privileges, or concealing activities. The detection rule identifies unusual file access in modprobe directories, excluding benign processes, to flag potential tampering attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific file path accessed, focusing on "/etc/modprobe.conf" or files within "/etc/modprobe.d".
+- Examine the process that triggered the alert by checking the process name and its parent process to understand the context of the file access.
+- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Check for any recent changes or modifications to the accessed modprobe files to identify unauthorized alterations.
+- Correlate the event with other security logs or alerts to identify any related suspicious activities or patterns.
+- Assess the system for any unauthorized kernel modules that may have been loaded as a result of the file access.
+
+### False positive analysis
+
+- System maintenance tools like mkinitramfs and systemd-udevd may access modprobe files during routine operations. To prevent these from triggering alerts, ensure they are included in the exclusion list within the detection rule.
+- Backup and recovery processes, such as those performed by borg, might interact with modprobe directories. Verify these processes are legitimate and add them to the exclusion criteria if they are part of regular system operations.
+- Security auditing tools like auditbeat and aide can access modprobe files as part of their monitoring activities. Confirm these tools are authorized and exclude them from the rule to avoid unnecessary alerts.
+- Package management and installation processes, such as those involving dpkg, may open modprobe files. If these actions are part of standard package updates or installations, include them in the exclusion list to reduce false positives.
+- Custom scripts or automation tools using Python may interact with modprobe configurations. Review these scripts to ensure they are safe and consider adding them to the exclusion list if they are frequently triggering alerts without posing a threat.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access.
+- Conduct a thorough review of the processes that accessed the modprobe configuration files to identify any unauthorized or suspicious activity.
+- If unauthorized access is confirmed, remove any malicious or unauthorized kernel modules that have been loaded, and restore the modprobe configuration files from a known good backup.
+- Apply security patches and updates to the system to address any vulnerabilities that may have been exploited.
+- Enhance monitoring and logging for modprobe-related activities to detect any future unauthorized access attempts.
+- Review and tighten permissions on modprobe configuration files to ensure only authorized processes and users can access them.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_sysctl_enumeration.toml b/rules_building_block/discovery_linux_sysctl_enumeration.toml
index 4da1313644c..729e1069a4b 100644
--- a/rules_building_block/discovery_linux_sysctl_enumeration.toml
+++ b/rules_building_block/discovery_linux_sysctl_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/08"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,41 @@ file.path : ("/etc/sysctl.conf" or "/etc/sysctl.d" or /etc/sysctl.d/*) and not p
   dpkg or dockerd or unattended-upg or systemd-sysctl or python* or auditbeat or dpkg or pool*
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Sysctl File Event
+
+Sysctl configuration files in Linux environments manage kernel parameters, crucial for system performance and security. Adversaries may exploit these files to alter system behavior, potentially destabilizing or compromising the system. The detection rule identifies unauthorized file access or modifications by monitoring specific file events and excluding benign processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the specific file path involved in the alert to determine if it is a critical sysctl configuration file, such as /etc/sysctl.conf or a file within /etc/sysctl.d/.
+- Identify the process that accessed or modified the file by examining the process.name field, ensuring it is not one of the excluded benign processes like dpkg or systemd-sysctl.
+- Check the timestamp of the event to correlate it with any known system changes or updates that might explain the file access.
+- Investigate the user account associated with the process to determine if the access was authorized or if the account has a history of suspicious activity.
+- Examine recent system logs for any other unusual activities or errors that might indicate tampering with system configurations.
+- Assess the current system stability and performance to identify any anomalies that could be linked to unauthorized sysctl file modifications.
+
+### False positive analysis
+
+- Routine system updates and package installations can trigger file events on sysctl configuration files. To manage this, exclude processes like dpkg and unattended-upg from the detection rule, as they are commonly involved in legitimate system maintenance activities.
+- Docker-related operations may access sysctl files as part of container management. Exclude the dockerd process to prevent false positives during normal Docker operations.
+- System initialization and configuration processes, such as systemd-sysctl, may read or write to sysctl files. Exclude this process to avoid alerts during standard system boot or configuration changes.
+- Monitoring tools like auditbeat may access sysctl files for auditing purposes. Exclude auditbeat to prevent false positives from legitimate monitoring activities.
+- Custom scripts or automation tools that frequently interact with sysctl files should be reviewed. If deemed non-threatening, add these specific process names to the exclusion list to reduce unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential spread of malicious activity.
+- Review the sysctl configuration files for unauthorized changes. Restore the files from a known good backup if any unauthorized modifications are detected.
+- Identify and terminate any suspicious processes that accessed the sysctl files, especially those not listed in the exclusion criteria of the detection rule.
+- Conduct a thorough investigation to determine how the unauthorized access occurred, focusing on potential vulnerabilities or misconfigurations that could have been exploited.
+- Apply necessary patches or updates to the system to address any identified vulnerabilities that may have been exploited.
+- Enhance monitoring and logging for sysctl file access to ensure any future unauthorized attempts are detected promptly.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_linux_system_information_discovery.toml b/rules_building_block/discovery_linux_system_information_discovery.toml
index 431c60f4301..c5f6478fc24 100644
--- a/rules_building_block/discovery_linux_system_information_discovery.toml
+++ b/rules_building_block/discovery_linux_system_information_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/10"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,41 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
   )
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Linux System Information Discovery
+
+Linux system information discovery involves commands like `uname`, `cat`, `more`, and `less` to gather system details such as kernel version, hardware, and configuration files. Adversaries exploit these to understand the environment and tailor attacks. The detection rule identifies suspicious use of these commands, focusing on process events that suggest system probing, thus alerting analysts to potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process event details to identify the specific command executed, focusing on the process.name and process.args fields to understand what system information was being queried.
+- Check the user context under which the command was executed to determine if it aligns with expected behavior for that user or if it suggests unauthorized access.
+- Investigate the parent process of the suspicious command to understand how the process was initiated and if it was part of a legitimate workflow or script.
+- Correlate the event with other recent process events from the same host to identify any patterns or sequences that suggest a broader reconnaissance or attack attempt.
+- Examine the network activity from the host around the time of the event to detect any potential data exfiltration or communication with known malicious IP addresses.
+- Review historical alerts and logs for the host to determine if there have been previous similar activities or other indicators of compromise.
+
+### False positive analysis
+
+- Routine system administration tasks may trigger the rule, such as when administrators use commands like uname, cat, more, or less to check system configurations or hardware details. To manage this, consider creating exceptions for known administrator accounts or specific maintenance windows.
+- Automated scripts or monitoring tools that regularly check system information for health and performance metrics can also cause false positives. Identify these scripts and exclude their process names or paths from the rule.
+- Software updates or installations that involve checking system compatibility might execute these commands. Review the context of such events and whitelist the associated processes or update tools.
+- Development or testing environments where frequent system information checks are part of normal operations can lead to alerts. Implement exclusions for these environments by specifying IP ranges or hostnames.
+- Security tools that perform regular audits or compliance checks may use these commands as part of their operations. Verify the legitimacy of these tools and exclude their activities from triggering alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the use of `uname`, `cat`, `more`, or `less` with sensitive arguments.
+- Conduct a thorough review of system logs and process histories to identify any unauthorized access or changes made by the adversary.
+- Restore any altered configuration files or system settings to their original state using verified backups.
+- Update and patch the Linux system to address any vulnerabilities that may have been exploited during the reconnaissance phase.
+- Implement stricter access controls and monitoring on sensitive files and directories to prevent unauthorized access in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_linux_system_owner_user_discovery.toml b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
index 2e2c8d3def8..a20226b1dbd 100644
--- a/rules_building_block/discovery_linux_system_owner_user_discovery.toml
+++ b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/10"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -37,6 +37,41 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and 
 process.name : ("whoami", "w", "who", "users", "id")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 System Owner/User Discovery Linux
+
+In Linux environments, commands like `whoami`, `w`, `who`, `users`, and `id` are essential for identifying the current user and other logged-in users. Adversaries exploit these tools to gather information about system ownership and user activity, aiding in privilege escalation or lateral movement. The detection rule monitors the execution of these commands, flagging potential misuse by correlating process start events with specific command executions, thus alerting analysts to suspicious user enumeration activities.
+
+### Possible investigation steps
+
+- Review the process start event details to identify the user account associated with the execution of the flagged command, focusing on the process.name field to confirm which command was executed.
+- Examine the timestamp of the event to determine if the command execution aligns with expected user activity or if it occurred during unusual hours.
+- Check the source IP address or terminal from which the command was executed to identify if it originated from a known or trusted location.
+- Investigate the parent process of the flagged command to understand the context in which it was executed and determine if it was initiated by a legitimate application or script.
+- Correlate the event with other recent alerts or logs to identify any patterns of suspicious behavior, such as multiple enumeration commands executed in a short timeframe.
+- Assess the risk score and severity in conjunction with other environmental factors to prioritize the investigation and determine if immediate action is required.
+
+### False positive analysis
+
+- Routine administrative tasks often involve the use of commands like `whoami` and `id` for legitimate purposes such as verifying user permissions. To reduce false positives, consider creating exceptions for known administrative scripts or users who frequently execute these commands as part of their regular duties.
+- Automated monitoring tools or scripts may periodically execute user discovery commands to gather system metrics or perform health checks. Identify these tools and exclude their process names or execution paths from triggering alerts.
+- Development and testing environments may see frequent use of these commands by developers or testers. Implement exceptions for specific environments or user groups where such activity is expected and non-threatening.
+- Scheduled jobs or cron tasks might execute these commands for logging or auditing purposes. Review and whitelist these scheduled tasks to prevent unnecessary alerts.
+- Security tools or agents running on the system might use these commands as part of their normal operation. Verify and exclude these processes to avoid false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the alert, particularly those associated with the execution of the `whoami`, `w`, `who`, `users`, or `id` commands, if they are not part of normal operations.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized changes or suspicious accounts that may have been created or modified.
+- Reset passwords for all user accounts on the affected system, prioritizing accounts with elevated privileges, to mitigate the risk of credential compromise.
+- Review system logs and audit trails to identify any additional indicators of compromise or related suspicious activities that may have occurred before or after the alert.
+- Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for similar user enumeration activities across the network to detect and respond to future attempts promptly."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_net_share_discovery_winlog.toml b/rules_building_block/discovery_net_share_discovery_winlog.toml
index 3194c52904e..06b6c79ee98 100644
--- a/rules_building_block/discovery_net_share_discovery_winlog.toml
+++ b/rules_building_block/discovery_net_share_discovery_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/14"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,40 @@ sequence by user.name, source.port, source.ip with maxspan=15s
   winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and 
   source.ip != null and source.ip != "0.0.0.0" and source.ip != "::1" and source.ip != "::" and source.ip != "127.0.0.1"]
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Network Share Discovery
+
+Network shares allow users to access files and resources across systems, facilitating collaboration. However, adversaries exploit this by scanning for shared folders, especially administrative shares, to gather intelligence or move laterally within a network. The detection rule identifies suspicious access attempts to these shares by monitoring specific event actions and filtering out benign IP addresses, thus highlighting potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the source IP addresses involved in the alert to determine if they belong to known or trusted devices within the network. Cross-reference these IPs with asset management databases to identify the devices.
+- Check the user.name field to verify if the user account associated with the access attempts is legitimate and if it has a history of accessing network shares. Investigate any anomalies in user behavior or access patterns.
+- Analyze the timing and frequency of the access attempts by examining the sequence of events within the 15-second maxspan window to identify any patterns or unusual activity that could indicate automated scanning or reconnaissance.
+- Investigate the context of the network-share-object-access-checked events by reviewing logs from the involved systems to determine if there were any successful access attempts or subsequent suspicious activities following the initial alert.
+- Correlate the alert with other security events or alerts in the same timeframe to identify potential lateral movement or further reconnaissance activities by the same source IP or user account.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when IT staff access administrative shares for legitimate purposes. To mitigate this, create exceptions for known IT personnel or service accounts that regularly perform these tasks.
+- Automated backup or monitoring systems might access network shares as part of their normal operations. Identify these systems and exclude their IP addresses from triggering alerts.
+- Software updates or patch management tools often scan network shares to deploy updates. Recognize these tools and whitelist their associated IP addresses or user accounts to prevent false positives.
+- Internal network scanning tools used for security assessments can mimic adversarial behavior. Ensure these tools are documented and their activities are excluded from detection rules.
+- Shared resources accessed by trusted third-party vendors might appear suspicious. Maintain a list of approved vendor IP addresses and exclude them from the rule to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Conduct a thorough review of the access logs to identify any unauthorized access attempts and determine the scope of the potential compromise.
+- Change passwords for any accounts that were accessed or potentially compromised during the network share discovery attempt.
+- Implement network segmentation to limit access to administrative shares and sensitive resources, ensuring only authorized users have access.
+- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for network share discovery.
+- Enhance monitoring and alerting for suspicious network share access attempts, focusing on unusual patterns or access from unexpected IP addresses.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
index 534e6b19c1c..bfa1b70ae95 100644
--- a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
+++ b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -40,6 +40,40 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
   (process.name == "getent" and process.args in ("passwd", "group"))
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Account or Group Discovery via Built-In Tools
+
+Built-in tools on Linux and macOS, such as `groups`, `id`, `dscl`, and `getent`, are essential for managing and querying user and group information. Adversaries exploit these tools to enumerate accounts and groups, gaining insights into system configurations and potential targets. The detection rule identifies suspicious use of these tools by monitoring process execution patterns and specific arguments, flagging potential unauthorized discovery activities.
+
+### Possible investigation steps
+
+- Review the process execution details, focusing on the process name and arguments, to determine if the usage aligns with typical administrative tasks or if it appears suspicious.
+- Check the user account associated with the process execution to verify if the account has legitimate reasons to perform such actions, especially if it involves querying sensitive files like /etc/passwd or /etc/sudoers.
+- Investigate the timing and frequency of the process execution to identify any unusual patterns or repeated attempts that could indicate malicious intent.
+- Correlate the event with other security alerts or logs from the same host or user to identify any related suspicious activities or anomalies.
+- Assess the system's recent login history and user activity to determine if there are any unauthorized access attempts or compromised accounts that could explain the alert.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule, such as system administrators using `groups`, `id`, or `getent` to verify user and group configurations. To manage this, create exceptions for known administrative accounts or specific times when these tasks are regularly performed.
+- Automated scripts or system management tools that query user and group information for legitimate purposes can also cause false positives. Identify these scripts and whitelist their execution paths or specific arguments used.
+- Security compliance checks often involve accessing files like `/etc/passwd` or `/etc/sudoers`. If these checks are part of regular audits, consider excluding the processes or users responsible for these checks from triggering alerts.
+- Integration with directory services might involve legitimate use of `dscl` or `dscacheutil` commands. Review and exclude these processes if they are part of normal directory synchronization or querying activities.
+- Regular system monitoring tools that perform discovery operations to maintain system health and inventory can be excluded by identifying their process names and arguments, ensuring they align with expected behavior.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, such as those involving `groups`, `id`, `dscl`, `dscacheutil`, or `getent` with unauthorized arguments.
+- Conduct a thorough review of user and group accounts on the affected system to identify any unauthorized changes or additions, and revert them if necessary.
+- Reset passwords for all accounts on the affected system, prioritizing those with elevated privileges, to mitigate potential credential compromise.
+- Review and tighten access controls and permissions on sensitive files such as `/etc/passwd`, `/etc/master.passwd`, and `/etc/sudoers` to prevent unauthorized access.
+- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign.
+- Implement enhanced monitoring and logging for the affected system and similar endpoints to detect any recurrence of the suspicious activity, ensuring logs are retained for future analysis."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_of_domain_groups.toml b/rules_building_block/discovery_of_domain_groups.toml
index 6a1122dd0d6..6bbb7222cac 100644
--- a/rules_building_block/discovery_of_domain_groups.toml
+++ b/rules_building_block/discovery_of_domain_groups.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   process.name in ("ldapsearch", "dscacheutil") or (process.name == "dscl" and process.args : "*-list*")
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Discovery of Domain Groups
+
+In Linux environments, commands like `ldapsearch`, `dscacheutil`, and `dscl` are used for querying domain groups and user accounts, aiding system administrators in managing network resources. Adversaries exploit these commands to gather intelligence on group memberships and permissions, which can inform their attack strategies. The detection rule identifies suspicious executions of these commands, flagging potential reconnaissance activities by monitoring specific process names and arguments, thus helping analysts to preemptively address threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific command executed, focusing on the process.name field to determine if it was ldapsearch, dscacheutil, or dscl.
+- Examine the process.args field to understand the context of the command execution, especially if dscl was used with the -list argument, which may indicate an attempt to enumerate domain groups.
+- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious.
+- Investigate the source host identified by host.os.type to assess if it is a critical system or if it has a history of similar reconnaissance activities.
+- Correlate this event with other recent alerts or logs from the same host or user to identify patterns or a sequence of reconnaissance activities that may suggest a larger attack strategy.
+- Review network logs or endpoint monitoring data to identify any subsequent suspicious activities following the command execution, such as unauthorized access attempts or data exfiltration.
+
+### False positive analysis
+
+- System administrators frequently use commands like ldapsearch, dscacheutil, and dscl for legitimate network management tasks. Regularly review and whitelist these activities if they originate from known administrative accounts or IP addresses.
+- Automated scripts or scheduled tasks may execute these commands as part of routine system audits or maintenance. Identify and document these scripts, then create exceptions in the detection rule to prevent unnecessary alerts.
+- Security tools or monitoring solutions might use these commands for compliance checks or security assessments. Verify the source of such activities and exclude them if they align with authorized security operations.
+- Development or testing environments may generate similar command executions as part of application testing. Ensure these environments are well-documented and consider excluding them from the rule to reduce noise.
+- If a specific user or service account is known to perform these actions regularly, consider adding them to an exception list after confirming their legitimacy and necessity for business operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving `ldapsearch`, `dscacheutil`, or `dscl` with the `-list` argument.
+- Conduct a thorough review of recent logs and system activities to identify any unauthorized access or changes to group memberships and permissions.
+- Reset credentials and review permissions for any accounts that may have been exposed or compromised during the reconnaissance activity.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected.
+- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the suspicious activity.
+- Review and update firewall and access control policies to limit unnecessary exposure of domain group information to unauthorized users."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_posh_generic.toml b/rules_building_block/discovery_posh_generic.toml
index 99cc4afdb5d..deb61540a4b 100644
--- a/rules_building_block/discovery_posh_generic.toml
+++ b/rules_building_block/discovery_posh_generic.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 
 
 [rule]
@@ -140,6 +140,40 @@ event.category:process and host.os.type:windows and
   ) and
   not user.id : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Discovery Capabilities
+
+PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to perform reconnaissance, gathering information about users, network configurations, and system settings. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and methods associated with discovery tasks, filtering out benign processes, and focusing on potential threats.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text to identify which specific cmdlets or methods were used, focusing on those related to discovery activities such as "Get-ADDomain" or "Get-Process".
+- Check the user ID associated with the alert to determine if it belongs to a legitimate user or service account, ensuring it is not one of the excluded IDs like "S-1-5-18", "S-1-5-19", or "S-1-5-20".
+- Investigate the context of the process execution by examining related process creation events, including parent processes, to understand how the PowerShell script was initiated.
+- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack.
+- Assess the risk and impact by determining if the discovered information could be used for further malicious activities, such as privilege escalation or lateral movement within the network.
+
+### False positive analysis
+
+- Administrative scripts and tools may trigger the rule when performing legitimate system audits or inventory tasks. To manage this, identify and exclude specific scripts or tools that are known to be safe and frequently used by IT staff.
+- Scheduled tasks or automated processes that use PowerShell for system monitoring or maintenance can generate false positives. Review these tasks and exclude their associated user accounts or script names from the detection rule.
+- Security software or system management tools that use PowerShell for configuration checks or updates might be flagged. Whitelist these tools by excluding their specific cmdlets or script block texts from the rule.
+- PowerShell scripts used in software deployment or updates may match the rule's criteria. Exclude these scripts by adding exceptions for the user accounts or script paths involved in these operations.
+- Developers or system administrators using PowerShell for testing or development purposes might inadvertently trigger the rule. Implement exclusions for known development environments or user accounts to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing reconnaissance activities.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized changes or access.
+- Reset passwords for potentially compromised accounts, especially those with elevated privileges, to mitigate the risk of further exploitation.
+- Analyze PowerShell logs and other relevant system logs to identify any additional indicators of compromise or related malicious activity.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other systems.
+- Implement enhanced monitoring and alerting for PowerShell activities across the network to detect similar threats in the future."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/discovery_posh_password_policy.toml b/rules_building_block/discovery_posh_password_policy.toml
index 3178120fd4f..102a6ef780b 100644
--- a/rules_building_block/discovery_posh_password_policy.toml
+++ b/rules_building_block/discovery_posh_password_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -91,6 +91,39 @@ event.category: "process" and host.os.type:windows and
   )
   and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Password Policy Discovery Capabilities
+
+PowerShell, a powerful scripting language in Windows, facilitates system management and automation. Adversaries exploit PowerShell to discover password policies, aiding lateral movement and privilege escalation. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and methods linked to password policy queries, filtering out benign scripts and known safe user IDs to pinpoint potential threats.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any suspicious cmdlets or methods, such as "Get-ADDefaultDomainPasswordPolicy" or "ActiveDirectory.DirectorySearcher", that may indicate an attempt to discover password policies.
+- Check the user ID associated with the alert to determine if it is a known and trusted user or if it is an unexpected or unauthorized account, especially since the rule excludes the system account "S-1-5-18".
+- Investigate the source host of the PowerShell activity to determine if it is a critical system or a less monitored endpoint, which could provide context on the potential impact of the activity.
+- Correlate the alert with other recent security events or logs from the same host or user to identify any patterns of suspicious behavior or potential lateral movement attempts.
+- Assess the risk score and severity of the alert in conjunction with other security intelligence to prioritize the investigation and response efforts effectively.
+
+### False positive analysis
+
+- Scripts used by system administrators for legitimate password policy audits may trigger the rule. To manage this, identify and whitelist specific user IDs or script signatures that are known to perform these tasks regularly.
+- Automated compliance checks or security tools that query password policies as part of their routine operations can be mistaken for threats. Exclude these tools by adding their unique identifiers or script block text to the exception list.
+- PowerShell scripts executed by trusted applications or services that include password policy queries for configuration purposes might be flagged. Review and exclude these applications by their process names or associated user IDs.
+- Development or testing environments where password policy scripts are frequently run for validation purposes can generate false positives. Implement exclusions for these environments by specifying their hostnames or IP addresses.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.
+- Conduct a thorough review of user accounts and privileges, focusing on any accounts that may have been compromised or used for unauthorized access.
+- Reset passwords for affected accounts and enforce a password policy that includes complexity and expiration requirements to mitigate future risks.
+- Implement additional monitoring on the affected system and network for any signs of further suspicious activity, particularly related to PowerShell and WinRM usage.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.
+- Review and update endpoint protection measures to ensure they are capable of detecting and blocking similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_potential_memory_seeking_activity.toml b/rules_building_block/discovery_potential_memory_seeking_activity.toml
index 5da12a7bb77..e8c32d38b53 100644
--- a/rules_building_block/discovery_potential_memory_seeking_activity.toml
+++ b/rules_building_block/discovery_potential_memory_seeking_activity.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/18"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   process.args like "/var/tmp/dracut*"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Memory Seeking Activity
+
+In Linux environments, utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` are used for legitimate data processing tasks, including reading and manipulating file contents. However, adversaries can exploit these tools to probe memory addresses, potentially setting the stage for further exploitation. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments indicative of memory-seeking behavior, while excluding known benign processes to reduce false positives. This approach helps in early detection of potential reconnaissance activities by attackers.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and arguments, to confirm if the command usage aligns with typical memory-seeking behavior as outlined in the detection rule.
+- Examine the parent process information, such as the parent name and command line, to determine if the process was initiated by a known benign source or if it appears suspicious.
+- Check the execution context, including the user account and host details, to assess if the activity is expected for the given environment or user role.
+- Investigate any related processes or activities around the same timeframe to identify potential patterns or additional suspicious behavior.
+- Correlate the alert with other security events or logs to determine if there are signs of broader reconnaissance or exploitation attempts.
+
+### False positive analysis
+
+- Processes initiated by known benign scripts or applications such as error_monitor.sh, acme.sh, dracut, and leapp can trigger false positives. Users should consider adding these to the exclusion list if they are verified as non-threatening in their environment.
+- Parent processes like cagefs_enter, nessus-service, platform-python, vdsmd, docker-entrypoint.sh, and lsinitrd-quick are often legitimate and can be excluded if they are part of routine operations.
+- Command lines starting with sh and containing acme.sh or involving /var/tmp/dracut are typically benign. Users can exclude these patterns to reduce noise.
+- Regularly review and update the exclusion list to ensure it reflects the current operational environment and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement by the attacker and to contain the threat.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the use of `tail`, `cmp`, `hexdump`, `xxd`, or `dd` with the flagged arguments.
+- Conduct a memory dump and forensic analysis of the affected system to identify any unauthorized access or modifications to memory addresses.
+- Review and analyze logs from the affected system to trace the origin of the suspicious activity and identify any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
index d3826371012..49c59bb8d05 100644
--- a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
+++ b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,40 @@ process where event.type == "start" and event.action in ("exec", "exec_event") a
 ) and 
 not process.parent.name in ("amazon-ssm-agent", "snap")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Process Discovery via Built-In Applications
+
+Built-in applications like `ps`, `pstree`, `htop`, and `pgrep` are essential for system administrators to monitor and manage processes on Linux and macOS systems. However, adversaries can exploit these tools to gain insights into running processes, aiding in reconnaissance and lateral movement. The detection rule identifies suspicious use of these tools by monitoring process execution events, excluding legitimate parent processes like `amazon-ssm-agent` and `snap`, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific built-in application used (e.g., ps, pstree, htop, pgrep) and the associated process execution event.
+- Examine the process tree to determine the parent process of the suspicious activity, ensuring it is not a legitimate process like amazon-ssm-agent or snap.
+- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+- Check for any recent changes or anomalies in the system that could indicate unauthorized access or configuration changes.
+- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack or reconnaissance effort.
+
+### False positive analysis
+
+- System management scripts or automation tools may frequently use built-in applications like ps or pgrep for legitimate monitoring tasks. Consider reviewing these scripts and excluding them from the rule if they are verified as non-threatening.
+- Developers and IT staff might use htop or pstree during routine system diagnostics. If these activities are common and verified as safe, add exceptions for specific user accounts or parent processes.
+- Scheduled maintenance tasks or cron jobs might trigger these tools for system health checks. Identify these tasks and exclude them from the rule to prevent unnecessary alerts.
+- Security software or monitoring agents might invoke these commands as part of their normal operation. Verify these processes and exclude them if they are part of trusted applications.
+- Training or testing environments where users are learning system administration might generate alerts. Consider excluding these environments from the rule to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected endpoint from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the alert that are not associated with legitimate parent processes.
+- Conduct a thorough review of recent process execution logs to identify any unauthorized or unusual activity that may indicate further compromise.
+- Reset credentials and review access permissions for any accounts that were active on the affected endpoint to prevent unauthorized access.
+- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activity and ensure comprehensive visibility.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional endpoints are affected.
+- Implement additional monitoring rules to detect similar process discovery attempts, focusing on unusual parent-child process relationships."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_signal_unusual_user_host.toml b/rules_building_block/discovery_signal_unusual_user_host.toml
index ac2bc337f90..e48a0a6ead2 100644
--- a/rules_building_block/discovery_signal_unusual_user_host.toml
+++ b/rules_building_block/discovery_signal_unusual_user_host.toml
@@ -2,7 +2,7 @@
 bypass_bbr_timing = true
 creation_date = "2023/10/10"
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,40 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
   "1d72d014-e2ab-4707-b056-9b96abe7b511"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Discovery Activity by User
+
+In Windows environments, discovery activities involve querying system information, which adversaries exploit to gather intelligence for further attacks. This detection rule identifies anomalies by monitoring unique host and user identifiers linked to discovery actions. By leveraging alert data from foundational rules, it flags unusual patterns, aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and user.id associated with the unusual discovery activity to understand the scope of the potential threat.
+- Check the event logs on the identified Windows host for any related discovery activities or other suspicious events around the time of the alert to gather more context.
+- Investigate the user account activity associated with the user.id to determine if there are any unauthorized or unexpected actions, such as logins from unusual locations or times.
+- Correlate the alert with other security events or alerts involving the same host.id or user.id to identify any patterns or additional indicators of compromise.
+- Assess the host's current state for any signs of compromise, such as unexpected processes, network connections, or changes in system configurations, to determine if further containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Routine administrative tasks by IT staff may trigger alerts due to frequent system queries. To manage this, create exceptions for known IT user accounts and host identifiers that regularly perform these tasks.
+- Automated scripts or monitoring tools that query system information for legitimate purposes can be mistaken for unusual activity. Identify these scripts and tools, and exclude their associated user and host identifiers from the rule.
+- Software updates or installations that involve system checks might generate false positives. Review the timing and context of alerts to correlate them with scheduled updates, and exclude relevant identifiers if necessary.
+- Security audits or compliance checks often involve extensive system discovery activities. Document these events and exclude the involved user and host identifiers to prevent unnecessary alerts.
+- Training or testing environments where discovery activities are simulated can lead to false positives. Ensure these environments are recognized and excluded from the rule to avoid confusion.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further lateral movement or data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis.
+- Conduct a thorough review of the user's recent activities and access logs to identify any unauthorized access or data manipulation. Focus on the specific user.id and host.id flagged in the alert.
+- Reset the credentials of the affected user account and any other accounts that may have been compromised. Ensure that new credentials adhere to strong password policies.
+- Scan the isolated host for malware or unauthorized software using updated antivirus and endpoint detection tools. Remove any malicious files or applications found.
+- Restore the affected system from a known good backup if any unauthorized changes or malware are detected that cannot be remediated.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or users are affected.
+- Implement enhanced monitoring on the affected host and user account to detect any recurrence of unusual discovery activities, adjusting alert thresholds if necessary to improve detection accuracy."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_suspicious_proc_enumeration.toml b/rules_building_block/discovery_suspicious_proc_enumeration.toml
index 5416dfa0a22..a33a57ee20b 100644
--- a/rules_building_block/discovery_suspicious_proc_enumeration.toml
+++ b/rules_building_block/discovery_suspicious_proc_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/09"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,40 @@ file.path : (/proc/*/cmdline or /proc/*/stat or /proc/*/exe) and not process.nam
   ps or netstat or landscape-sysin or w or pgrep or pidof or needrestart or apparmor_status
 ) and not process.parent.pid : 1
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Suspicious Proc Pseudo File System Enumeration
+
+The proc pseudo file system in Linux provides a window into the kernel and running processes, offering critical insights for system management. Adversaries exploit this by rapidly querying files like cmdline, stat, and exe to gather intelligence on active processes, potentially for reconnaissance or privilege escalation. The detection rule identifies such suspicious activity by monitoring for rapid, atypical access patterns to these files, excluding benign processes, thus flagging potential threats.
+
+### Possible investigation steps
+
+- Review the process triggering the alert by examining the process.name field to identify any unfamiliar or suspicious processes that are not part of the excluded list.
+- Investigate the parent process using the process.parent.pid field to determine if the process hierarchy appears legitimate or if it might be indicative of a compromised or malicious parent process.
+- Analyze the frequency and pattern of file access in the /proc/*/cmdline, /proc/*/stat, and /proc/*/exe paths to assess whether the access pattern is consistent with typical system behavior or indicative of reconnaissance activity.
+- Check for any recent changes or anomalies in the system logs around the time of the alert to identify any correlated suspicious activities or system changes.
+- Cross-reference the process with known threat intelligence sources to determine if it matches any known malicious signatures or behaviors.
+
+### False positive analysis
+
+- System monitoring tools that frequently access proc files for legitimate purposes may trigger false positives. Users can mitigate this by adding these tools to the exclusion list in the rule configuration.
+- Automated scripts or cron jobs that perform regular system checks might be flagged. Review these scripts and, if deemed safe, exclude their process names from the rule.
+- Custom administrative tools developed in-house that perform process checks could be mistakenly identified as threats. Verify their behavior and add them to the exception list if they are benign.
+- Security software that performs regular scans of system processes may also be detected. Confirm the legitimacy of such software and exclude it from the rule to prevent false alerts.
+- Development or testing environments where processes are frequently started and stopped might generate false positives. Consider excluding these environments from monitoring or adjusting the rule sensitivity for these specific cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as rapidly accessing the proc pseudo file system, especially those not whitelisted in the detection rule.
+- Conduct a thorough review of the system's process tree to identify any unauthorized or unexpected parent-child process relationships, focusing on those not originating from init (PID 1).
+- Analyze the system logs to trace the origin of the suspicious activity, identifying any potential entry points or vulnerabilities exploited by the adversary.
+- Apply security patches and updates to the affected system to address any known vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if any signs of compromise or unauthorized changes are detected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_network_connections.toml b/rules_building_block/discovery_system_network_connections.toml
index 146fae92b45..f6da04eaf41 100644
--- a/rules_building_block/discovery_system_network_connections.toml
+++ b/rules_building_block/discovery_system_network_connections.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/11"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,40 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name in ("netstat", "lsof", "who", "w")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 System Network Connections Discovery
+
+System network connections discovery involves tools like `netstat` and `lsof` to list active connections, aiding in network diagnostics. Adversaries exploit this to map network topology and identify potential targets. The detection rule identifies suspicious use of these tools by monitoring process execution events, flagging unusual activity patterns indicative of reconnaissance efforts.
+
+### Possible investigation steps
+
+- Review the process execution event details to confirm the process name is either "netstat", "lsof", "who", or "w", as these are the tools flagged by the rule.
+- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious.
+- Investigate the parent process of the flagged execution to understand the context in which the network discovery tool was launched, which may provide insights into whether the activity is part of a legitimate workflow or a potential threat.
+- Analyze the timing and frequency of the process execution events to identify patterns that may suggest automated or scripted activity, which could indicate malicious intent.
+- Correlate the event with other security alerts or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities.
+- Examine network logs or connection details to identify any unusual or unauthorized network connections that may have been established as a result of the network discovery activity.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators use netstat or lsof for legitimate network diagnostics. To manage this, create exceptions for known administrator accounts or specific times when these tasks are regularly performed.
+- Automated monitoring scripts that include network diagnostics commands like netstat or lsof can cause false positives. Identify and exclude these scripts by their process names or execution paths.
+- System health checks or security tools that periodically run netstat or lsof as part of their operations can be mistaken for suspicious activity. Whitelist these tools by verifying their signatures and ensuring they are from trusted sources.
+- Development or testing environments where network tools are frequently used for debugging purposes may generate alerts. Implement exclusions based on environment-specific identifiers or IP ranges to reduce noise.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary.
+- Terminate any suspicious processes identified as using `netstat`, `lsof`, `who`, or `w` that are not part of normal operations or expected administrative tasks.
+- Conduct a thorough review of recent network connection logs to identify any unauthorized or unusual connections that may indicate further compromise or data exfiltration.
+- Reset credentials and review access permissions for accounts on the affected system to ensure no unauthorized access persists.
+- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could have been exploited.
+- Enhance monitoring and logging on the affected system and network to detect any further suspicious activities or attempts to use similar discovery techniques.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_service_discovery.toml b/rules_building_block/discovery_system_service_discovery.toml
index c70601ed3a0..6fe45d6a859 100644
--- a/rules_building_block/discovery_system_service_discovery.toml
+++ b/rules_building_block/discovery_system_service_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/01/24"
 integration = ["windows", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -52,6 +52,40 @@ process where host.os.type == "windows" and event.type == "start" and
   (process.name : "psservice.exe" or process.pe.original_file_name == "psservice.exe")
   ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 System Service Discovery through built-in Windows Utilities
+
+System service discovery is a technique used to enumerate services running on a Windows system, often leveraging built-in utilities like `net.exe`, `sc.exe`, and `tasklist.exe`. Adversaries exploit these tools to gather information about services for privilege escalation or lateral movement. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and process behaviors, excluding known benign system accounts, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of `net.exe`, `sc.exe`, `tasklist.exe`, or `psservice.exe` by checking the process name and original file name fields. Verify if the command-line arguments match those specified in the rule, such as "start", "use", "query", "q*", or "/svc".
+- Investigate the user account associated with the process execution by examining the user.id field. Determine if the account is unusual or unauthorized for performing such actions, especially since the rule excludes the system account "S-1-5-18".
+- Check the parent process of the flagged process to understand the context of execution. This can help identify if the process was spawned by a legitimate application or a potentially malicious script or tool.
+- Analyze the timing and frequency of the detected activity. Determine if this is a one-time occurrence or part of a pattern, which could indicate automated or scripted reconnaissance.
+- Correlate the alert with other security events or logs from the same host or user to identify any additional suspicious activities, such as failed login attempts, unusual network connections, or file modifications, that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or automated scripts may use net.exe, sc.exe, or tasklist.exe for legitimate system management tasks. To reduce false positives, consider excluding these processes when executed by known administrative accounts or service accounts.
+- Scheduled tasks or maintenance scripts might invoke these utilities for routine checks. Identify and document such scripts, then create exceptions for their execution patterns to prevent unnecessary alerts.
+- Some third-party software may use these utilities as part of their normal operation. Monitor and whitelist these applications if they are verified to be safe and necessary for business operations.
+- Training and awareness for IT staff can help differentiate between legitimate and suspicious use of these utilities, reducing the likelihood of misidentifying benign activities as threats.
+- Regularly review and update the list of excluded accounts and processes to ensure that only verified non-threatening behaviors are exempted from detection.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes identified by the detection rule, such as instances of net.exe, sc.exe, or tasklist.exe, that are not associated with legitimate administrative tasks.
+- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or escalations, and revert any suspicious modifications.
+- Reset passwords for potentially compromised accounts, especially those with administrative privileges, to prevent unauthorized access.
+- Review and apply any necessary security patches or updates to the affected system to address potential vulnerabilities exploited by the adversary.
+- Monitor network traffic and system logs for any signs of further reconnaissance or malicious activity, focusing on the use of built-in utilities and unusual command-line arguments.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_system_time_discovery.toml b/rules_building_block/discovery_system_time_discovery.toml
index d58b327e2a1..d813f41e5b8 100644
--- a/rules_building_block/discovery_system_time_discovery.toml
+++ b/rules_building_block/discovery_system_time_discovery.toml
@@ -5,7 +5,7 @@ integration = ["windows", "endpoint", "system"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,40 @@ process where host.os.type == "windows" and event.type == "start" and
  (process.name: "tzutil.exe" and process.args: "/g")
 ) and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 System Time Discovery
+
+System time discovery involves querying a system's time settings, which adversaries exploit to synchronize attacks or evade detection. Attackers may use commands like `net time`, `w32tm`, or `tzutil` to gather time information. The detection rule identifies these activities by monitoring specific processes and arguments, excluding known system accounts, to flag potential reconnaissance efforts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious commands, such as "net time", "w32tm /tz", or "tzutil /g", and verify if these were executed by unexpected or unauthorized users.
+- Check the user ID associated with the process to ensure it is not one of the excluded system accounts (S-1-5-18, S-1-5-19, S-1-5-20) and determine if the user is legitimate or potentially compromised.
+- Investigate the parent process of the suspicious activity to understand the context of execution and identify if it was initiated by a legitimate application or a potentially malicious script or program.
+- Correlate the event with other logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or reconnaissance effort.
+- Assess the timing and frequency of the detected commands to determine if they align with normal operational procedures or if they suggest an anomaly that warrants further investigation.
+
+### False positive analysis
+
+- System maintenance tasks may trigger the rule when administrators use time-related commands for legitimate purposes. To manage this, create exceptions for known maintenance scripts or tools used by trusted administrators.
+- Automated scripts or software that synchronize time settings across multiple systems can cause false positives. Identify these scripts and exclude their associated user accounts or process names from the rule.
+- Scheduled tasks that involve time synchronization or adjustments might be flagged. Review scheduled tasks and exclude those that are part of routine system operations.
+- Monitoring tools that check system time as part of their health checks can be mistaken for reconnaissance. Whitelist these tools by excluding their process names or user accounts from the detection rule.
+- Training or testing environments where time-related commands are frequently executed for educational purposes can generate alerts. Exclude these environments by filtering based on specific hostnames or user accounts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, such as instances of `net.exe`, `w32tm.exe`, or `tzutil.exe` running with unusual arguments.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized changes have been made, focusing on accounts not excluded by the detection rule.
+- Check for any signs of lateral movement or additional compromise on the network by reviewing logs and alerts from other systems.
+- Restore the system time settings to their correct state if they have been altered, ensuring synchronization with a trusted time source.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for time-related commands and processes to detect similar activities in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
index 86698b83778..ad87e12cc59 100644
--- a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
+++ b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/14"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/07/23"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -43,6 +43,40 @@ event.dataset:aws.cloudtrail
     and event.action:DescribeInstanceAttribute
     and aws.cloudtrail.request_parameters:(*attribute=userData* and *instanceId*)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Retrieve User Data from AWS EC2 Instance
+
+AWS EC2 instances can store sensitive configuration data in user data scripts, which are executed during instance launch. Adversaries may exploit the `DescribeInstanceAttribute` API call to access this data, potentially exposing vulnerabilities or sensitive information. The detection rule monitors CloudTrail logs for such API calls, flagging attempts to access user data, thus serving as an early indicator of suspicious activity.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the source IP address and user identity associated with the DescribeInstanceAttribute API call to determine if the request was made by an authorized user or system.
+- Check the AWS IAM policies and roles associated with the user or service making the request to ensure they have the appropriate permissions and that there are no overly permissive policies in place.
+- Investigate the instanceId specified in the request to understand the context of the EC2 instance, including its purpose, the data it handles, and any recent changes or activities associated with it.
+- Examine the attribute userData in the request to assess what specific data or scripts might be exposed and evaluate the potential impact if this information were accessed by unauthorized parties.
+- Correlate this event with other logs and alerts to identify any patterns or sequences of actions that might indicate a broader reconnaissance or attack attempt, such as multiple DescribeInstanceAttribute requests or other discovery-related activities.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the DescribeInstanceAttribute API call when checking instance configurations. To manage this, identify and whitelist known administrative accounts or roles that regularly perform these tasks.
+- Automated scripts or monitoring tools might use the DescribeInstanceAttribute API call to verify instance settings. Review and document these tools, then create exceptions for their activity to prevent unnecessary alerts.
+- Cloud management platforms often perform discovery operations that include DescribeInstanceAttribute calls. Ensure these platforms are recognized and their actions are excluded from triggering alerts by adding them to an exception list.
+- Scheduled audits or compliance checks might involve DescribeInstanceAttribute requests. Coordinate with compliance teams to understand their schedules and exclude these activities from detection rules.
+- Development and testing environments may frequently use DescribeInstanceAttribute for configuration validation. Segregate these environments and apply specific rules that account for their unique activity patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance to prevent further unauthorized access or data exfiltration. This can be done by modifying the security group to restrict inbound and outbound traffic.
+- Review the AWS CloudTrail logs to identify any unauthorized users or IP addresses that accessed the `DescribeInstanceAttribute` API call. Revoke any suspicious access keys or credentials associated with these users.
+- Conduct a thorough audit of the user data scripts stored on the affected EC2 instance to identify any sensitive information that may have been exposed. Remove or encrypt sensitive data as necessary.
+- Rotate any credentials or secrets that were stored in the user data scripts to prevent unauthorized use.
+- Implement additional monitoring and alerting for similar API calls in CloudTrail to detect and respond to future attempts promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources have been compromised.
+- Review and update IAM policies to ensure that only authorized users have the necessary permissions to access sensitive EC2 attributes, following the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_win_network_connections.toml b/rules_building_block/discovery_win_network_connections.toml
index dc1f9d25751..a7608781df8 100644
--- a/rules_building_block/discovery_win_network_connections.toml
+++ b/rules_building_block/discovery_win_network_connections.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,39 @@ process where event.type == "start" and
   (process.name : "nbtstat.exe" and process.args : "-s*")
 ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows System Network Connections Discovery
+
+Windows systems provide utilities like `netstat`, `net`, and `nbtstat` to manage and monitor network connections. Adversaries exploit these tools to map network connections, identifying potential targets. The detection rule monitors the execution of these utilities, focusing on specific arguments that suggest enumeration activities, while excluding benign system processes, to identify suspicious network discovery attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the user account associated with the alert, focusing on the user.id field to determine if it deviates from expected user behavior.
+- Examine the parent process of the flagged command to understand the context of execution and assess whether it was initiated by a legitimate application or script.
+- Investigate the command-line arguments used with the executed process (e.g., netstat.exe, net.exe, nbtstat.exe) to determine if they align with typical administrative tasks or suggest malicious intent.
+- Check the historical activity of the involved user account and system to identify any patterns or anomalies that could indicate a broader compromise or unauthorized access.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or indicators of compromise within the network.
+
+### False positive analysis
+
+- System administrators or network engineers may frequently use netstat, net, or nbtstat for legitimate network troubleshooting and monitoring tasks. To reduce false positives, consider excluding these users or specific user IDs from the rule, especially if they are known to perform these tasks regularly.
+- Automated scripts or scheduled tasks that utilize these network utilities for system health checks or inventory purposes can trigger the rule. Identify and exclude these processes by their parent process name or specific command-line arguments that are consistently used in these scripts.
+- Security software or network management tools might invoke these commands as part of their normal operations. Review the parent process names and user IDs associated with these tools and add them to the exclusion list to prevent unnecessary alerts.
+- In environments where network configurations are frequently changed or updated, legitimate use of net and net1 commands with arguments like "use", "user", "session", and "config" might be common. Monitor and document these activities to distinguish between routine operations and potential threats, and adjust the rule to exclude these known benign activities.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, such as those involving netstat.exe, net.exe, net1.exe, or nbtstat.exe with suspicious arguments.
+- Conduct a thorough review of recent network connections and communications from the affected system to identify any unauthorized access or data transfers.
+- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent further unauthorized access.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
+- Monitor the network for any further suspicious activity or attempts to use similar network discovery tools, adjusting network security policies as necessary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/discovery_windows_system_information_discovery.toml b/rules_building_block/discovery_windows_system_information_discovery.toml
index af6dab02a4d..feeb366feb8 100644
--- a/rules_building_block/discovery_windows_system_information_discovery.toml
+++ b/rules_building_block/discovery_windows_system_information_discovery.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/06"
 integration = ["windows", "endpoint", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,39 @@ process.parent.executable : (
     "?:\\ProgramData\\*"
 ) and not user.id : "S-1-5-18"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Windows System Information Discovery
+
+Windows system information discovery involves querying system details like OS version, hostname, and configuration, typically for legitimate administrative tasks. However, attackers exploit this to gain insights into a compromised system's environment, aiding in further attacks. The detection rule identifies suspicious use of system commands like `cmd.exe`, `systeminfo.exe`, and `wmic.exe` by filtering out benign processes and known safe parent executables, flagging potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of suspicious commands like cmd.exe, systeminfo.exe, hostname.exe, or wmic.exe, focusing on the arguments used, such as "ver*" or "os get".
+- Examine the parent process executable path to determine if it deviates from typical benign paths, such as those within Program Files or ProgramData directories, which are excluded in the rule.
+- Investigate the user account associated with the process execution, especially if the user ID is not "S-1-5-18", which indicates a non-system account, to assess if the activity aligns with the user's normal behavior.
+- Check the historical activity of the involved processes and user account to identify any patterns or anomalies that could suggest malicious intent or compromise.
+- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools may trigger the rule if they use commands like cmd.exe, systeminfo.exe, or wmic.exe. To handle this, identify and whitelist these known safe scripts by adding their parent executable paths to the exception list.
+- Automated software updates or system management tools might execute these commands as part of their routine operations. Exclude these processes by specifying their parent executable paths, such as those located in Program Files or ProgramData directories.
+- Developers or IT personnel using command-line tools for legitimate purposes can also cause false positives. Consider excluding user IDs associated with these roles if they are consistently triggering the rule without malicious intent.
+- Custom scripts or batch files that perform system checks may inadvertently match the detection criteria. Review these scripts and, if deemed safe, add their specific paths or parent executables to the exclusion list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, such as cmd.exe, systeminfo.exe, or wmic.exe, that are not associated with legitimate administrative tasks.
+- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or lateral movement attempts.
+- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Update endpoint detection and response tools to enhance monitoring for similar suspicious activities, ensuring that any gaps identified during this incident are addressed."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_aws_lambda_function_updated.toml b/rules_building_block/execution_aws_lambda_function_updated.toml
index 773ea2fdede..ed6bcd32b46 100644
--- a/rules_building_block/execution_aws_lambda_function_updated.toml
+++ b/rules_building_block/execution_aws_lambda_function_updated.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,40 @@ event.dataset: "aws.cloudtrail"
     and event.outcome: "success"
     and event.action: (CreateFunction* or UpdateFunctionCode*)
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS Lambda Function Created or Updated
+
+AWS Lambda allows execution of code without server management, offering flexibility and scalability. However, adversaries may exploit this by creating or updating functions to run malicious code, steal data, or gain elevated access. The detection rule monitors successful creation or updates of Lambda functions, signaling potential misuse by tracking specific actions in AWS CloudTrail logs.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user or role that initiated the CreateFunction or UpdateFunctionCode actions. Check for any unusual or unauthorized users.
+- Examine the source IP address and geolocation associated with the event to determine if it originates from an expected or suspicious location.
+- Analyze the function code or configuration changes made during the update to identify any potentially malicious code or unexpected modifications.
+- Check the permissions and roles associated with the Lambda function to ensure they are not overly permissive and do not allow unauthorized access or privilege escalation.
+- Investigate any related AWS services or resources that interact with the Lambda function to assess potential lateral movement or data exfiltration risks.
+- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise that may suggest a broader attack.
+
+### False positive analysis
+
+- Routine updates to Lambda functions by development teams can trigger the rule. To manage this, create exceptions for specific user roles or accounts that are known to perform regular updates.
+- Automated deployment tools that update Lambda functions as part of a CI/CD pipeline may cause false positives. Exclude actions from these tools by identifying their specific IAM roles or user agents.
+- Scheduled updates or maintenance activities that involve Lambda function modifications can be mistaken for suspicious activity. Document and exclude these scheduled events by correlating them with known maintenance windows.
+- Third-party integrations that require Lambda function updates might trigger the rule. Identify and exclude these integrations by their unique identifiers or associated accounts.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS Lambda function by disabling it to prevent further execution of potentially malicious code.
+- Review the AWS CloudTrail logs to identify any unauthorized access or changes made to the Lambda function, focusing on the user or role that performed the action.
+- Revert any unauthorized changes to the Lambda function by restoring it to a known good state using versioning or backups.
+- Conduct a security review of the IAM roles and permissions associated with the Lambda function to ensure they follow the principle of least privilege.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation.
+- Implement additional monitoring and alerting for changes to Lambda functions to detect similar activities in the future.
+- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices for Lambda functions."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_event_action_for_pat.toml b/rules_building_block/execution_github_new_event_action_for_pat.toml
index e8ab2101ae1..201d28b232e 100644
--- a/rules_building_block/execution_github_new_event_action_for_pat.toml
+++ b/rules_building_block/execution_github_new_event_action_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,41 @@ event.dataset:"github.audit" and event.category:"configuration" and
 event.action:* and github.hashed_token:* and 
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence GitHub Event for a Personal Access Token (PAT)
+
+Personal Access Tokens (PATs) in GitHub provide a way to authenticate programmatic access to repositories, enabling automation and integration. Adversaries may exploit PATs to gain unauthorized access, execute code, or exfiltrate data. The detection rule identifies unusual PAT activity by flagging tokens not seen in recent history, helping to uncover potential misuse or unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the event details to identify the specific hashed token involved in the alert and determine if it corresponds to any known or expected activity.
+- Check the GitHub audit logs for any recent configuration changes or actions associated with the identified token to understand its usage context.
+- Investigate the user or application associated with the token to verify if they have a legitimate reason for accessing the repository or resources.
+- Assess the scope of access granted by the token, especially if it is a fine-grained personal access token, to evaluate potential risks or exposure.
+- Look for any other unusual or suspicious activities in the GitHub environment around the time of the alert to identify potential patterns or related incidents.
+- Contact the owner of the token, if identifiable, to confirm whether the token usage was authorized and expected.
+
+### False positive analysis
+
+- New legitimate integrations or applications may trigger the rule when they first use a PAT. Users should review the source and purpose of the token and, if verified as non-threatening, add the token to an allowlist to prevent future alerts.
+- Routine administrative tasks or updates that require new PATs can cause false positives. Document these tasks and create exceptions for known administrative activities to reduce unnecessary alerts.
+- Developers frequently creating and rotating PATs for testing purposes might trigger the rule. Establish a process to track and approve these activities, and consider excluding tokens associated with specific development environments.
+- Automated scripts or CI/CD pipelines that generate new PATs for each run can be mistaken for suspicious activity. Identify these scripts and pipelines, and configure the rule to recognize and exclude their expected behavior.
+- Organizational changes, such as team restructuring or onboarding new team members, may lead to increased PAT creation. Monitor these changes and temporarily adjust the rule's sensitivity or add exceptions during transition periods.
+
+### Response and remediation
+
+- Immediately revoke the identified Personal Access Token (PAT) to prevent any unauthorized access or actions using the token.
+- Review the access logs associated with the PAT to identify any suspicious activities or unauthorized access attempts that may have occurred.
+- Notify the repository owner and relevant stakeholders about the potential security incident and provide details of the PAT usage and associated risks.
+- Conduct a security review of the affected repositories to ensure no unauthorized changes or data exfiltration occurred during the period the PAT was active.
+- Implement additional monitoring for any further unusual activities or access attempts related to the compromised PAT or associated accounts.
+- Escalate the incident to the security team for a comprehensive investigation and to determine if further actions are necessary, such as notifying affected users or partners.
+- Enhance security measures by enforcing stricter access controls and considering the use of more granular permissions for future PATs to minimize potential impact."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
index af1fe749b4a..b7782edd786 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -36,6 +36,41 @@ 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
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT)
+
+GitHub Personal Access Tokens (PATs) enable programmatic access to repositories, facilitating automation and integration. However, adversaries can exploit compromised PATs to access private repositories, potentially exfiltrating sensitive data. This detection rule identifies unusual private repo interactions by monitoring for PAT activity not observed in the past 14 days, signaling potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the specific GitHub repository involved in the alert to determine its sensitivity and the potential impact of unauthorized access.
+- Identify the user or system associated with the hashed_token in the alert to verify if the access was expected or authorized.
+- Check the history of the GitHub Personal Access Token (PAT) usage to determine if there have been any other unusual activities or patterns.
+- Investigate the OAuth access token or fine-grained personal access token to confirm its legitimacy and whether it has been compromised.
+- Contact the repository owner or relevant team members to verify if the access aligns with any recent changes or integrations.
+- Assess the event's context within the broader security environment to identify any related alerts or incidents that might indicate a larger security issue.
+
+### False positive analysis
+
+- Regularly scheduled automated tasks using PATs may trigger alerts. Identify and document these tasks to create exceptions for known, non-threatening activities.
+- Developers frequently accessing private repositories for legitimate purposes might cause false positives. Maintain a list of authorized users and their expected access patterns to exclude them from alerts.
+- Integration tools or CI/CD pipelines using PATs for routine operations can be mistaken for unauthorized access. Verify these tools and add them to an allowlist to prevent unnecessary alerts.
+- Temporary access granted to external collaborators for specific projects may appear as unusual activity. Ensure these instances are logged and monitored, and create temporary exceptions as needed.
+- Changes in team structure or roles leading to new PAT usage should be communicated to the security team to update monitoring rules accordingly.
+
+### Response and remediation
+
+- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access to private repositories.
+- Notify the repository owner and relevant stakeholders about the potential breach to ensure they are aware and can take necessary precautions.
+- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized changes or data exfiltration.
+- Reset credentials and access tokens for all affected users and services to mitigate the risk of further unauthorized access.
+- Implement additional monitoring and alerting for unusual activities in private repositories to detect similar threats in the future.
+- Escalate the incident to the security team for a comprehensive investigation and to determine if further actions are required.
+- Review and update access controls and permissions for private repositories to ensure they follow the principle of least privilege."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_user.toml b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
index 5aabab32d3c..ac550245dee 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_user.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,41 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.repo:* and user.name:* and 
 github.repository_public:false
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of GitHub User Interaction with Private Repo
+
+GitHub is a platform for version control and collaboration, allowing users to manage and store code in repositories. Private repositories are restricted to specific users, making unauthorized access a security concern. Adversaries may exploit compromised credentials to access sensitive code. The detection rule identifies unusual user interactions with private repositories, flagging users who haven't accessed them in the past 14 days, which may indicate potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the specific GitHub audit event details to identify the user involved in the interaction by examining the user.name field.
+- Verify the user's recent activity history on GitHub to determine if there are any other unusual or unauthorized actions, focusing on the last 14 days.
+- Check the access permissions and roles assigned to the user for the private repository in question to assess if the access was legitimate or potentially unauthorized.
+- Contact the user or their manager to confirm whether the interaction with the private repository was expected or authorized.
+- Investigate any recent changes to the user's credentials or access rights, such as password resets or role modifications, that could indicate a compromise.
+- Correlate this event with other security logs or alerts to identify any patterns or additional indicators of compromise related to the user's account.
+
+### False positive analysis
+
+- Users returning from vacation or leave may trigger the rule due to a lack of recent activity. Consider implementing a temporary exception for these users based on their leave schedule.
+- New team members or contractors accessing private repositories for the first time can be flagged. Maintain a list of new users and exclude them from the rule for an initial period.
+- Users involved in infrequent but legitimate projects may not access certain repositories regularly. Identify these projects and create exceptions for associated users.
+- Scheduled maintenance or audits by IT staff might result in flagged interactions. Coordinate with IT to whitelist these activities during known maintenance windows.
+- Automated scripts or tools that interact with repositories on behalf of users can cause false positives. Ensure these tools are properly documented and excluded from the rule.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the user interaction by contacting the user to confirm whether they initiated the access. If the user cannot be reached or denies the activity, proceed with containment steps.
+- Temporarily revoke the user's access to the private repository to prevent further unauthorized actions while the investigation is ongoing.
+- Conduct a thorough review of recent access logs and activities associated with the user's account to identify any other suspicious actions or potential compromise indicators.
+- Reset the user's credentials and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access.
+- If unauthorized access is confirmed, perform a security audit of the affected repository to identify any data exposure or code alterations, and take necessary steps to mitigate any identified risks.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and actions taken, and escalate to higher management if sensitive data is involved.
+- Update detection mechanisms and monitoring tools to enhance the identification of similar unauthorized access attempts in the future, leveraging insights from the incident."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_repo_created.toml b/rules_building_block/execution_github_repo_created.toml
index 40ab0a8d88b..1c6b3f48347 100644
--- a/rules_building_block/execution_github_repo_created.toml
+++ b/rules_building_block/execution_github_repo_created.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,40 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "repo.create"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Repo Created
+GitHub repositories are essential for code collaboration and version control in cloud environments. Adversaries may exploit this by creating repositories to host malicious code or scripts for execution. The detection rule monitors GitHub audit logs for repository creation events, flagging potential unauthorized or suspicious activities that align with execution tactics, thereby aiding in early threat identification.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to confirm the details of the repository creation event, including the timestamp and the user account responsible for the action.
+- Verify the identity and role of the user who created the repository to determine if they have legitimate reasons and permissions to create new repositories.
+- Check the contents of the newly created repository for any suspicious or malicious code, scripts, or files that could indicate unauthorized activity.
+- Investigate any recent changes in user permissions or access levels that might have allowed unauthorized repository creation.
+- Correlate the repository creation event with other security alerts or logs to identify any related suspicious activities or patterns.
+- Contact the user or team responsible for the repository creation to confirm the legitimacy of the action and gather additional context if necessary.
+
+### False positive analysis
+
+- Routine repository creation by development teams can trigger false positives. To manage this, identify and whitelist repositories created by trusted team members or service accounts.
+- Automated processes or CI/CD pipelines that create repositories as part of their workflow may be flagged. Exclude these known processes by setting up exceptions based on specific user agents or IP addresses.
+- Educational or training sessions where multiple repositories are created for learning purposes can lead to alerts. Temporarily adjust the rule sensitivity or add exceptions during these sessions.
+- Open-source project contributions where new repositories are frequently created by contributors can be excluded by verifying contributor identities and adding them to an allowlist.
+- Internal hackathons or innovation days often result in a spike in repository creation. Coordinate with event organizers to anticipate these activities and adjust monitoring rules accordingly.
+
+### Response and remediation
+
+- Immediately review the newly created GitHub repository to determine if it contains any unauthorized or malicious code. If malicious content is identified, remove the repository to prevent further access or distribution.
+- Revoke access for any users or tokens that were involved in the unauthorized creation of the repository to prevent further unauthorized actions.
+- Conduct a thorough audit of recent GitHub activity logs to identify any other suspicious actions or patterns that may indicate a broader compromise.
+- Notify the security team and relevant stakeholders about the incident, providing details of the repository creation and any identified malicious content for further analysis and response.
+- Implement additional monitoring on GitHub activities, focusing on repository creation and access patterns, to detect similar unauthorized actions in the future.
+- Review and update GitHub access controls and permissions to ensure that only authorized personnel have the ability to create repositories, reducing the risk of unauthorized actions.
+- If the incident is part of a larger attack pattern, escalate to incident response teams for a comprehensive investigation and coordinated response."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
index 46e625fe8c3..ab65cf80907 100644
--- a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
+++ b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,40 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and github.repo:* and 
 github.repository_public:false
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of GitHub Repo Interaction From a New IP
+
+GitHub repositories are crucial for code collaboration and management. Adversaries may exploit unauthorized access to private repos from unfamiliar IPs to execute malicious code or exfiltrate data. This detection rule identifies new IP interactions with private repos, flagging potential unauthorized access by monitoring IP changes over a 14-day period, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the IP address flagged in the alert to determine if it is associated with known or trusted networks, or if it appears suspicious or unfamiliar.
+- Check the GitHub actor associated with the IP address to verify if the user account has a history of legitimate access to the private repository.
+- Investigate the specific private repository accessed to assess its sensitivity and the potential impact of unauthorized access.
+- Analyze recent activity logs for the flagged IP address to identify any other unusual or unauthorized interactions with GitHub repositories.
+- Correlate the event with other security alerts or logs to determine if this IP address has been involved in other suspicious activities across the network.
+
+### False positive analysis
+
+- Employees working remotely or traveling may trigger alerts when accessing repositories from new IP addresses. To manage this, maintain a list of known employee IPs and update it regularly to exclude these from triggering false positives.
+- Use of VPNs or dynamic IP addresses can result in frequent IP changes. Implement a process to log and recognize these IPs, allowing for exceptions in the detection rule.
+- Automated systems or CI/CD pipelines interacting with repositories from cloud environments may use different IPs. Identify and whitelist these systems to prevent unnecessary alerts.
+- Collaborators from partner organizations accessing repositories might appear as new IPs. Establish a communication protocol to verify and whitelist these IPs as needed.
+- Regularly review and update the list of known safe IPs in the detection system to minimize false positives while ensuring security measures remain effective.
+
+### Response and remediation
+
+- Immediately isolate the IP address identified in the alert to prevent further unauthorized access to the private GitHub repository.
+- Review the access logs for the specific repository to determine the extent of the interaction and identify any potential data exfiltration or code changes.
+- Revoke any access tokens or credentials associated with the suspicious IP address to prevent further unauthorized access.
+- Notify the repository owner and relevant security teams about the unauthorized access attempt for further investigation and monitoring.
+- Conduct a security review of the affected repository to ensure no malicious code or unauthorized changes have been introduced.
+- Implement IP whitelisting or geofencing for accessing private repositories to limit access to known and trusted IP addresses.
+- Enhance monitoring and alerting for similar unauthorized access attempts by integrating additional threat intelligence and anomaly detection capabilities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_linux_segfault.toml b/rules_building_block/execution_linux_segfault.toml
index e1d006ca679..8109eb86a08 100644
--- a/rules_building_block/execution_linux_segfault.toml
+++ b/rules_building_block/execution_linux_segfault.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/26"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,40 @@ type = "query"
 query = '''
 host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:segfault
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Segfault Detected
+
+Segmentation faults occur when a program accesses restricted memory, often causing it to crash. While typically indicative of programming errors, adversaries can exploit these faults to execute unauthorized code, leveraging vulnerabilities like buffer overflows. The 'Segfault Detected' rule monitors Linux kernel logs for such faults, flagging potential exploitation attempts by correlating specific syslog events and process activities.
+
+### Possible investigation steps
+
+- Review the syslog entries around the time of the segfault event to gather additional context and identify any preceding or subsequent suspicious activities.
+- Investigate the process that triggered the segfault by examining its command line arguments, parent process, and any associated files or network connections to determine if it was part of a legitimate operation or a potential attack.
+- Check for any recent changes or updates to the system or software that might have introduced vulnerabilities or instability leading to the segfault.
+- Correlate the segfault event with other security alerts or logs to identify patterns or indicators of compromise that might suggest a broader attack campaign.
+- Assess the system for signs of exploitation, such as unexpected changes in file permissions, unauthorized user accounts, or unusual outbound network traffic, which could indicate successful code execution following the segfault.
+
+### False positive analysis
+
+- Kernel module crashes can generate segfault messages without indicating malicious activity. Review the specific module involved and consider excluding it if it is known to be unstable but non-threatening.
+- Debugging activities by developers may intentionally cause segfaults to test error handling. Coordinate with development teams to identify and exclude these events during known testing periods.
+- Certain legitimate applications may occasionally cause segfaults due to bugs or compatibility issues. Monitor these applications and, if they are verified as non-malicious, create exceptions for their segfault events.
+- System updates or patches might temporarily cause segfaults as software adjusts to new configurations. Track update schedules and exclude related segfaults if they align with these periods.
+- Custom scripts or automation tools that interact with system processes might inadvertently trigger segfaults. Validate these scripts and exclude their segfaults if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation.
+- Conduct a memory dump and forensic analysis of the affected system to identify any unauthorized code execution or modifications.
+- Review and update the system's software and libraries to patch any known vulnerabilities that could be exploited by buffer overflow attacks.
+- Implement application whitelisting to restrict the execution of unauthorized or suspicious processes.
+- Monitor for any additional segfault messages in the kernel logs across other systems to identify potential widespread exploitation attempts.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the attack is part of a larger campaign.
+- Enhance logging and alerting mechanisms to detect similar segmentation faults and potential exploitation attempts in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_settingcontent_ms_file_creation.toml b/rules_building_block/execution_settingcontent_ms_file_creation.toml
index e359ebfef9c..ae63fa296f2 100644
--- a/rules_building_block/execution_settingcontent_ms_file_creation.toml
+++ b/rules_building_block/execution_settingcontent_ms_file_creation.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,40 @@ file where host.os.type == "windows" and event.type == "creation" and
     "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\amd64_microsoft-windows-s..*\\*.settingcontent-ms"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation of SettingContent-ms Files
+
+SettingContent-ms files are XML-based shortcuts used in Windows to link to specific settings pages. Adversaries exploit these files to execute malicious code by embedding harmful scripts, bypassing traditional security measures. The detection rule identifies unusual creation of these files outside typical directories, flagging potential threats by monitoring file creation events and filtering out known legitimate paths.
+
+### Possible investigation steps
+
+- Review the file creation event details to identify the specific path where the SettingContent-ms file was created, ensuring it is outside the known legitimate directories.
+- Investigate the user account associated with the file creation event to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine recent processes executed on the host around the time of the file creation to identify any potentially malicious activity or scripts that may have triggered the event.
+- Check for any network connections or external communications from the host that could indicate data exfiltration or command and control activity.
+- Look for other related alerts or events on the same host or user account to identify patterns or additional indicators of compromise.
+- Assess the risk and impact of the event by considering the host's role within the organization and any sensitive data it may access.
+
+### False positive analysis
+
+- Legitimate software installations or updates may create SettingContent-ms files in non-standard directories. Monitor software installation logs to correlate these events and consider excluding these paths if they are consistently benign.
+- Custom scripts or administrative tools used by IT departments might generate these files during configuration tasks. Verify the source of these scripts and, if deemed safe, add exceptions for these specific operations.
+- User-initiated actions, such as creating shortcuts to settings for convenience, can trigger false positives. Educate users on the implications and review these actions to determine if they should be excluded.
+- Automated system maintenance tasks or third-party management tools might create these files as part of their operations. Identify these tools and assess their behavior to decide on necessary exclusions.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement.
+- Terminate any suspicious processes associated with the SettingContent-ms file creation to halt any ongoing malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts.
+- Review and restore any altered system settings or configurations to their default or secure state to ensure system integrity.
+- Collect and preserve relevant logs and artifacts for further analysis and to support potential forensic investigations.
+- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine the scope and impact of the threat.
+- Implement additional monitoring and alerting for unusual SettingContent-ms file creation activities to enhance detection and prevent recurrence of similar threats."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_unsigned_service_executable.toml b/rules_building_block/execution_unsigned_service_executable.toml
index e6c2b4816cc..bf75bd637b2 100644
--- a/rules_building_block/execution_unsigned_service_executable.toml
+++ b/rules_building_block/execution_unsigned_service_executable.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,41 @@ process.parent.executable:"C:\\Windows\\System32\\services.exe" and
 (process.code_signature.exists:false or process.code_signature.trusted:false) and
 not process.code_signature.status : (errorCode_endpoint* or "errorChaining")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Execution of an Unsigned Service
+
+The Service Control Manager (SCM) in Windows is crucial for managing system services. Adversaries may exploit SCM to run unsigned executables, potentially deploying malware or gaining elevated privileges. The detection rule identifies such activities by monitoring processes initiated by SCM, specifically those lacking valid code signatures, thus flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process details, including the executable path and name, to determine if the unsigned executable is expected or known within the environment.
+- Check the parent process, C:\\Windows\\System32\\services.exe, to confirm it is legitimate and not tampered with, as it is the parent process initiating the unsigned executable.
+- Investigate the origin of the unsigned executable by examining file creation and modification timestamps, and cross-reference with recent changes or deployments in the system.
+- Analyze the process execution context, such as user account and privileges, to assess if there is any indication of privilege escalation or unauthorized access.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns, such as network connections or file modifications, that might indicate malicious behavior.
+- Consult threat intelligence sources to determine if the unsigned executable or its hash is associated with known malware or threat actors.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they involve unsigned executables. Users can create exceptions for known update processes by verifying the source and adding them to an allowlist.
+- Custom in-house applications that are unsigned might be flagged. Ensure these applications are verified and trusted, then exclude them from the rule by specifying their executable paths.
+- Some third-party software, especially older or niche applications, may not have valid code signatures. Confirm the legitimacy of these applications and consider excluding them if they are essential and trusted.
+- Development or testing environments often run unsigned executables. To prevent unnecessary alerts, consider excluding these environments from the rule or creating specific exceptions for known development processes.
+- Temporary or transitional software deployments might lack signatures. If these are part of a controlled process, document and exclude them during the deployment phase.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access.
+- Terminate the suspicious unsigned service process identified by the alert to halt any malicious activity.
+- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software.
+- Review and analyze recent changes to system services and scheduled tasks to identify unauthorized modifications or additions.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement stricter application whitelisting policies to prevent the execution of unsigned or untrusted executables in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/execution_wmi_wbemtest.toml b/rules_building_block/execution_wmi_wbemtest.toml
index 7e05911003e..db8c02b2ca8 100644
--- a/rules_building_block/execution_wmi_wbemtest.toml
+++ b/rules_building_block/execution_wmi_wbemtest.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,41 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.name : "wbemtest.exe"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WMI WBEMTEST Utility Execution
+
+Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. The WBEMTEST utility is a diagnostic tool that allows users to interact with WMI, often used for legitimate administrative tasks. However, adversaries can exploit it to execute commands or gather information stealthily. The detection rule identifies instances of WBEMTEST execution, flagging potential misuse by monitoring process initiation events on Windows systems.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the execution of wbemtest.exe, focusing on the process name and event type fields.
+- Identify the user account associated with the wbemtest.exe process initiation to determine if the execution aligns with expected administrative activity.
+- Examine the parent process of wbemtest.exe to understand how it was launched and assess if it was initiated by a legitimate application or script.
+- Check for any network connections or remote interactions initiated by wbemtest.exe to identify potential unauthorized access to remote endpoints.
+- Investigate the historical activity of the user and host involved to identify any patterns of suspicious behavior or previous alerts related to WMI usage.
+- Correlate this event with other security alerts or logs from the same host or user to determine if this is part of a broader attack pattern.
+
+### False positive analysis
+
+- Administrative tasks using wbemtest.exe can trigger alerts. Regularly review and document legitimate administrative activities to differentiate them from potential threats.
+- Scheduled maintenance scripts or automated processes that utilize wbemtest.exe may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Software installations or updates that interact with WMI might execute wbemtest.exe. Monitor and log these events to establish a baseline of expected behavior.
+- Developers or IT staff using wbemtest.exe for troubleshooting or development purposes can be mistaken for adversarial activity. Implement user-based exceptions for known personnel conducting these tasks.
+- Security tools or monitoring solutions that leverage WMI for data collection might inadvertently execute wbemtest.exe. Coordinate with security teams to ensure these activities are recognized and excluded from alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the wbemtest.exe process if it is confirmed to be running without legitimate administrative purpose.
+- Conduct a thorough review of recent WMI activity on the affected system to identify any unauthorized or suspicious actions performed using WMI.
+- Reset credentials for any accounts that were used to execute wbemtest.exe, especially if they have administrative privileges, to prevent further misuse.
+- Implement host-based firewall rules to restrict WMI access to only trusted IP addresses and systems, reducing the risk of remote exploitation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update and enhance monitoring rules to detect similar WMI misuse attempts, ensuring that alerts are generated for any unauthorized execution of wbemtest.exe in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_member_removed_from_organization.toml b/rules_building_block/impact_github_member_removed_from_organization.toml
index 7153494eaa4..79e18cd5003 100644
--- a/rules_building_block/impact_github_member_removed_from_organization.toml
+++ b/rules_building_block/impact_github_member_removed_from_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,39 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.remove_member"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Member Removed From GitHub Organization
+
+GitHub Organizations manage collaborative access to repositories, where members can be added or removed. Adversaries might exploit this by removing legitimate members to disrupt operations or conceal malicious activities. The detection rule monitors audit logs for member removal actions, flagging potential unauthorized access removal, aligning with MITRE ATT&CK's impact tactics, ensuring timely threat detection and response.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to confirm the event dataset is "github.audit" and the action is "org.remove_member" to ensure the alert is based on the correct event.
+- Identify the user who was removed from the organization and determine their role and access level to assess the potential impact of their removal.
+- Investigate the user account that performed the removal action to verify if it was authorized and check for any unusual activity or anomalies associated with this account.
+- Check the organization's recent activity logs for any other suspicious actions or changes that might indicate a broader security incident.
+- Contact the removed member or relevant team leads to confirm whether the removal was expected or authorized, and gather any additional context or concerns they might have.
+
+### False positive analysis
+
+- Routine member management activities can trigger alerts when legitimate members are removed as part of regular organizational changes. To mitigate this, establish a baseline of expected member removal activities and create exceptions for these patterns.
+- Temporary project members or contractors may be removed after project completion, leading to false positives. Implement a process to document and exclude these expected removals from triggering alerts.
+- Automated scripts or integrations that manage user access might inadvertently remove members, causing false positives. Review and adjust the scripts to ensure they align with organizational policies and exclude these actions from monitoring.
+- Organizational restructuring or mergers can result in bulk member removals, which may be flagged as suspicious. Coordinate with HR or management teams to anticipate these changes and temporarily adjust detection thresholds or rules.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the member removal by contacting the organization owner or admin to confirm if the action was authorized.
+- If unauthorized, promptly re-add the removed member to the organization to restore their access and minimize disruption.
+- Conduct a review of recent audit logs to identify any other suspicious activities or unauthorized changes within the organization.
+- Temporarily restrict access to critical repositories and resources until the source of the unauthorized removal is identified and mitigated.
+- Escalate the incident to the security team for further investigation and to assess potential impacts on the organization’s operations and data integrity.
+- Implement additional access controls, such as multi-factor authentication, to prevent unauthorized access and account manipulation in the future.
+- Update and reinforce incident response procedures to ensure rapid detection and response to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_pat_access_revoked.toml b/rules_building_block/impact_github_pat_access_revoked.toml
index 4dd48492420..d24ec95104c 100644
--- a/rules_building_block/impact_github_pat_access_revoked.toml
+++ b/rules_building_block/impact_github_pat_access_revoked.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,39 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "personal_access_token.access_revoked"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PAT Access Revoked
+
+GitHub Personal Access Tokens (PATs) are used to authenticate API requests without a password, granting access to private resources. Adversaries may exploit compromised PATs to access sensitive data or disrupt operations. The detection rule monitors audit logs for revoked PAT access, indicating potential unauthorized use or security policy enforcement, helping to identify and mitigate such threats.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event where event.dataset is "github.audit" and event.action is "personal_access_token.access_revoked" to identify the user or system associated with the revoked PAT.
+- Determine the scope of access that the revoked PAT had by reviewing the permissions and resources it was authorized to access.
+- Investigate the reason for the PAT revocation by checking for any related security alerts or policy enforcement actions that might have triggered the revocation.
+- Contact the user or team associated with the revoked PAT to verify if the revocation was expected or if there are any indications of unauthorized access or compromise.
+- Assess the potential impact on operations or data security due to the revocation and determine if any further actions, such as additional access reviews or security measures, are necessary.
+
+### False positive analysis
+
+- Routine administrative actions such as regular audits or security policy updates may trigger PAT access revocations. To manage these, create exceptions for known administrative accounts or scheduled maintenance periods.
+- Automated scripts or tools that rotate PATs for security reasons might cause frequent revocations. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated accounts or tokens.
+- User-initiated PAT revocations for personal security hygiene can appear as false positives. Encourage users to document such actions and maintain a list of user-initiated revocations to cross-reference with alerts.
+- Organizational policy changes that enforce stricter PAT usage guidelines may lead to mass revocations. Coordinate with policy enforcement teams to anticipate these changes and temporarily adjust detection thresholds or rules.
+
+### Response and remediation
+
+- Immediately revoke any remaining access for the compromised PAT to prevent further unauthorized access to private resources.
+- Notify the affected user and relevant security teams about the incident to ensure awareness and initiate further investigation if needed.
+- Conduct a review of recent activities associated with the compromised PAT to identify any unauthorized actions or data access.
+- Reset credentials and generate a new PAT for the affected user, ensuring it follows best practices for security and access control.
+- Implement additional monitoring for unusual activities related to the affected user's account to detect any further suspicious behavior.
+- Escalate the incident to higher-level security management if sensitive data was accessed or if the breach impacts critical operations.
+- Review and update access policies and token management practices to prevent similar incidents, ensuring that PATs are regularly rotated and have the least privilege necessary."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/impact_github_user_blocked_from_organization.toml b/rules_building_block/impact_github_user_blocked_from_organization.toml
index 60fb77cb60d..66d1124f9c2 100644
--- a/rules_building_block/impact_github_user_blocked_from_organization.toml
+++ b/rules_building_block/impact_github_user_blocked_from_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,40 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.block_user"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 User Blocked From Organization
+
+GitHub is a platform for version control and collaboration, crucial for software development. Organizations use it to manage access to their repositories. Blocking a user can be a legitimate action to revoke access, but adversaries might exploit this to disrupt operations or remove access stealthily. The detection rule monitors audit logs for user blocks, identifying potential misuse by correlating specific actions with threat tactics, ensuring timely alerts for security teams.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event where event.dataset is "github.audit" and event.action is "org.block_user" to identify the user who was blocked and the timestamp of the action.
+- Verify the identity and role of the blocked user within the organization to assess the potential impact of their access removal.
+- Check for any recent changes or unusual activities in the repositories or organization settings that the blocked user had access to, which might indicate malicious intent or misuse.
+- Investigate the user who performed the block action to ensure it was authorized and aligns with organizational policies.
+- Look for any correlated events or alerts around the same timeframe that might suggest a coordinated attempt to disrupt operations or remove access stealthily.
+- Communicate with the organization’s admin or security team to confirm whether the block was intentional and part of a legitimate security measure.
+
+### False positive analysis
+
+- Routine administrative actions may trigger alerts when an organization intentionally blocks users for maintenance or restructuring. To manage this, create exceptions for known administrative accounts performing these actions.
+- Temporary access revocations for contractors or third-party collaborators can appear as user blocks. Implement a process to log and verify these temporary blocks to distinguish them from potential threats.
+- Automated scripts or bots used for managing user access might inadvertently block users during updates or error handling. Ensure these scripts are well-documented and monitored, and consider excluding their actions from alerts if they are verified as non-threatening.
+- High turnover in organizations can lead to frequent user blocks as part of offboarding processes. Establish a baseline for expected user block frequency and adjust alert thresholds accordingly to reduce noise from legitimate offboarding activities.
+
+### Response and remediation
+
+- Verify the legitimacy of the block by contacting the organization owner or admin to confirm whether the action was intentional or unauthorized.
+- If the block was unauthorized, immediately unblock the user and restore their access to the necessary repositories, ensuring no critical work is disrupted.
+- Conduct a review of recent audit logs to identify any other suspicious activities or unauthorized access attempts that may indicate a broader security issue.
+- Implement additional access controls or two-factor authentication for organization admins to prevent unauthorized actions in the future.
+- Notify the affected user about the incident, advising them to review their account security settings and change their password if necessary.
+- Escalate the incident to the security team for further investigation and to assess whether additional security measures are required to protect the organization.
+- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent similar occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_cross_site_scripting.toml b/rules_building_block/initial_access_cross_site_scripting.toml
index 0ed9fe480fb..b487efe3dab 100644
--- a/rules_building_block/initial_access_cross_site_scripting.toml
+++ b/rules_building_block/initial_access_cross_site_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/12"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,41 @@ any where processor.name == "transaction" and
 url.fragment : ("<iframe*", "*prompt(*)*", "<script*>", "<svg*>", "*onerror=*", "*javascript*alert*", "*eval*(*)*", "*onclick=*",
 "*alert(document.cookie)*", "*alert(document.domain)*","*onresize=*","*onload=*","*onmouseover=*")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Cross Site Scripting (XSS)
+
+Cross-Site Scripting (XSS) exploits vulnerabilities in web applications by injecting malicious scripts into trusted sites, often targeting users' browsers. Adversaries leverage this to execute scripts that can steal cookies, session tokens, or other sensitive data. The detection rule identifies suspicious script patterns in web transactions, such as `<script>` or `onerror=`, indicating potential XSS attempts, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific URL fragment that triggered the rule, focusing on patterns like "<script*>", "*onerror=*", or "*javascript*alert*".
+- Examine the source and destination IP addresses associated with the transaction to determine if they are known or suspicious entities.
+- Check the user agent string in the transaction to identify if the request was made by a legitimate browser or a potentially malicious script.
+- Investigate the session data, including cookies and tokens, to assess if any sensitive information might have been exposed or compromised.
+- Analyze the referrer URL to understand the context of how the user arrived at the page, which might provide insights into potential phishing or redirection tactics.
+- Correlate the alert with other recent alerts or logs from the same user or IP address to identify patterns or repeated attempts of XSS attacks.
+
+### False positive analysis
+
+- Legitimate use of JavaScript functions like `onclick` or `onload` in web applications can trigger false positives. Review the context of these scripts and whitelist known safe scripts in the detection rule.
+- Developers often use `alert(document.cookie)` or `alert(document.domain)` for debugging purposes. Identify and exclude these scripts from the rule when they originate from trusted development environments.
+- Use of `eval()` in legitimate applications can be flagged. Ensure that any use of `eval()` is necessary and secure, and consider excluding these instances if they are verified as non-threatening.
+- SVG elements with embedded scripts, such as `<svg>`, might be used for legitimate purposes. Validate the source and purpose of these elements and create exceptions for trusted sources.
+- Frequent use of `onerror` for error handling in images or scripts can be misidentified. Confirm the legitimacy of these uses and exclude them from the rule if they are part of standard error handling practices.
+
+### Response and remediation
+
+- Immediately isolate the affected systems or user accounts to prevent further execution of malicious scripts and potential data exfiltration.
+- Clear the browser cache and cookies on affected systems to remove any malicious scripts or session hijacking attempts.
+- Conduct a thorough review of web application logs and user activity to identify any unauthorized access or data exfiltration attempts.
+- Patch and update the web application and any related software to close the identified vulnerabilities exploited by the XSS attack.
+- Implement Content Security Policy (CSP) headers on the web application to restrict the execution of untrusted scripts and mitigate future XSS attempts.
+- Notify the security team and relevant stakeholders about the incident, providing details of the attack vector and steps taken for containment and remediation.
+- Monitor the affected systems and web applications closely for any signs of recurring XSS attempts or related suspicious activities."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
index 173fa693fb1..41aa7243dff 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,41 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and github.hashed_token:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of IP Address For GitHub Personal Access Token (PAT)
+
+GitHub Personal Access Tokens (PATs) facilitate secure API interactions, but adversaries can exploit them to gain unauthorized access. By monitoring for new IP addresses associated with PAT usage, this detection rule identifies potential misuse. It flags unusual activity by checking if an IP address has been seen in the past 14 days, helping to thwart unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific IP address and GitHub actor involved in the event.
+- Check historical logs to determine if the IP address has been associated with any other GitHub activities or accounts beyond the 14-day window.
+- Investigate the GitHub actor's recent activity to identify any unusual patterns or unauthorized actions that may indicate compromise.
+- Verify the legitimacy of the GitHub Personal Access Token by contacting the token owner to confirm if the access was expected or authorized.
+- Assess the geographical location and ISP information of the IP address to determine if it aligns with the expected usage patterns of the GitHub actor.
+- Examine any other security alerts or incidents related to the same IP address or GitHub actor to identify potential correlations or broader security issues.
+
+### False positive analysis
+
+- Frequent legitimate access from dynamic IP addresses can trigger false positives. Users should maintain a list of known dynamic IP ranges used by trusted employees or services and exclude these from alerts.
+- Remote work or travel can result in legitimate access from new IP addresses. Implement a process to verify and whitelist IP addresses associated with known employee travel or remote work locations.
+- Use of VPNs or proxy services by employees can cause alerts due to IP address changes. Identify and exclude IP addresses associated with company-approved VPNs or proxy services.
+- Automated scripts or tools that rotate IP addresses for legitimate API access may trigger alerts. Document and exclude IP addresses used by these tools if they are verified as non-threatening.
+- Regularly review and update the exclusion list to ensure it reflects current legitimate access patterns, removing any outdated or unnecessary entries.
+
+### Response and remediation
+
+- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access.
+- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized changes or data access.
+- Notify the affected user and relevant security teams about the incident, providing details of the IP address and any suspicious activities detected.
+- Implement IP whitelisting for GitHub access, if feasible, to restrict access to known and trusted IP addresses.
+- Enhance logging and monitoring for GitHub activities to detect any further unauthorized access attempts or anomalies.
+- Review and update access controls and permissions associated with GitHub accounts to ensure the principle of least privilege is enforced.
+- If unauthorized access is confirmed, initiate a security incident response process, including a full investigation and reporting to relevant stakeholders."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_user.toml b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
index b9e80d855c5..7b61a3d79fb 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_user.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,41 @@ query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
 github.actor_ip:* and user.name:*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of IP Address For GitHub User
+
+GitHub audit logs track user activities, including IP addresses, to monitor access patterns. Adversaries may exploit compromised credentials to access accounts from unfamiliar IPs, indicating potential unauthorized access. This detection rule identifies new IP addresses associated with a user within a 14-day window, flagging unusual access attempts that could signify initial access tactics by threat actors.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to identify the specific event associated with the new IP address, focusing on the event.dataset:"github.audit" and event.category:"configuration" fields.
+- Verify the legitimacy of the new IP address by cross-referencing it with known IP addresses associated with the user or organization, and check for any geographical anomalies.
+- Contact the user associated with the alert to confirm whether they recognize the IP address and if they have recently accessed their account from a new location or device.
+- Investigate the user.name field to gather additional context about the user's recent activities and any potential changes in their access patterns.
+- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate action is required to secure the account.
+- Check for any other recent alerts or suspicious activities related to the same user or IP address to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Frequent travel or remote work by users can trigger false positives due to legitimate access from new IP addresses. Implement a process to whitelist known IP ranges associated with regular travel or remote work locations.
+- Use of VPNs or dynamic IP addresses by users may result in new IP detections. Consider excluding IP addresses from known VPN providers or implementing a policy to log and verify VPN usage.
+- Changes in corporate network infrastructure, such as new proxies or gateways, can lead to new IP addresses being flagged. Coordinate with IT to update the list of approved IP addresses when infrastructure changes occur.
+- Shared accounts accessed by multiple users from different locations can generate false positives. Encourage the use of individual accounts and monitor shared account access separately.
+- Regularly review flagged IP addresses and cross-reference them with known user activity patterns to identify and exclude benign occurrences.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by temporarily disabling access to prevent further unauthorized activity.
+- Conduct a thorough review of recent activities associated with the compromised account to identify any unauthorized changes or data access.
+- Reset the password for the affected user account and enforce multi-factor authentication (MFA) to enhance security.
+- Notify the user of the suspicious activity and provide guidance on recognizing phishing attempts and securing their credentials.
+- Escalate the incident to the security operations team for further investigation and to determine if other accounts or systems have been compromised.
+- Monitor the network for any additional suspicious IP addresses or activities that may indicate further attempts at unauthorized access.
+- Update security policies and access controls to prevent similar incidents, ensuring that alerts for new IP addresses are promptly reviewed and addressed."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
index de9956f7246..bb72bf1491c 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,41 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.user_agent:* and github.hashed_token:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of User Agent For a GitHub Personal Access Token (PAT)
+
+GitHub Personal Access Tokens (PATs) enable programmatic access to GitHub resources, often used in automation and integration tasks. Adversaries may exploit these tokens to gain unauthorized access, especially if they can use a new user agent to avoid detection. The detection rule identifies anomalies by flagging new user agents associated with PATs, indicating potential misuse or compromise, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the specific user agent flagged in the alert to determine if it is known or expected within the organization. Check for any recent changes in automation tools or scripts that might explain the new user agent.
+- Identify the GitHub user associated with the hashed token in the alert. Investigate their recent activity and access patterns to determine if there are any anomalies or unauthorized actions.
+- Examine the source IP address and geolocation associated with the new user agent to assess if it aligns with typical access patterns for the user or organization.
+- Check for any recent changes in the user's permissions or roles that might indicate a potential compromise or misuse of access.
+- Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader security incident.
+- Communicate with the user or relevant team to verify if the new user agent usage was intentional and authorized, documenting any findings or confirmations.
+
+### False positive analysis
+
+- New user agents from legitimate automation tools or scripts may trigger false positives. Users should identify and whitelist these known tools to prevent unnecessary alerts.
+- Frequent updates or changes in user agents by legitimate applications can cause false positives. Monitor and document these changes to adjust detection rules accordingly.
+- Developers or teams using multiple devices or environments might introduce new user agents. Establish a baseline of expected user agents for these users and exclude them from alerts.
+- Legitimate third-party integrations that use rotating user agents can be mistaken for threats. Verify these integrations and create exceptions for recognized patterns.
+- Temporary network changes, such as using a VPN or proxy, might result in new user agents. Recognize these scenarios and adjust the detection criteria to accommodate such variations.
+
+### Response and remediation
+
+- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access.
+- Notify the affected user and relevant security teams about the potential compromise and provide details of the new user agent detected.
+- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized actions or data access.
+- Reset credentials and enforce multi-factor authentication (MFA) for the affected account to enhance security.
+- Implement IP whitelisting for PAT usage to restrict access to known and trusted networks.
+- Escalate the incident to the security operations center (SOC) for further investigation and monitoring of related suspicious activities.
+- Update security policies and procedures to include regular audits of PAT usage and user agent patterns to prevent future occurrences."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_user.toml b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
index 15d3b4dfcf7..21ceded9c8f 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_user.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -34,6 +34,41 @@ query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
 github.user_agent:* and user.name:*
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of User-Agent For a GitHub User
+
+User-Agent strings identify the software acting on behalf of a user, such as browsers or scripts, in GitHub environments. Adversaries may exploit this by using unfamiliar User-Agents to mask malicious activities. The detection rule identifies new User-Agents associated with GitHub users, flagging potential unauthorized access attempts by monitoring changes over a 14-day period.
+
+### Possible investigation steps
+
+- Review the specific GitHub user account associated with the alert to determine if there have been any recent changes in activity or access patterns.
+- Examine the new User-Agent string identified in the alert to assess if it is associated with known legitimate software or if it appears suspicious or uncommon.
+- Check the event logs for any other activities associated with the same User-Agent string to identify patterns or additional context around its usage.
+- Investigate the IP address and geolocation associated with the new User-Agent to determine if it aligns with the expected locations for the user.
+- Contact the user to verify if they have recently used a new device or application that could explain the new User-Agent, ensuring it is an authorized change.
+- Review any recent changes in the user's permissions or roles within the GitHub environment to assess if there is a potential for misuse or unauthorized access.
+
+### False positive analysis
+
+- Frequent legitimate changes in User-Agent strings due to browser updates or different devices used by the same user can trigger false positives. Users can manage this by creating exceptions for known User-Agent strings associated with trusted devices or browsers.
+- Automated scripts or tools used by developers may introduce new User-Agent strings. To handle this, maintain a list of approved User-Agent strings for these tools and exclude them from triggering alerts.
+- Shared accounts or service accounts that are accessed from multiple locations or devices can result in new User-Agent detections. Implementing IP whitelisting or tagging known IP addresses can help reduce false positives in these scenarios.
+- Users accessing GitHub through VPNs or proxies might appear with different User-Agent strings. Identifying and excluding these known network configurations can help minimize unnecessary alerts.
+- Regularly review and update the list of exceptions to ensure that only legitimate and non-threatening User-Agent strings are excluded, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected GitHub account by temporarily suspending access to prevent further unauthorized actions.
+- Review the recent activity logs for the affected account to identify any unauthorized changes or data access, and document these findings for further analysis.
+- Reset the credentials for the compromised account and enforce multi-factor authentication (MFA) to enhance security.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Conduct a thorough review of the organization's GitHub access policies and permissions to ensure they follow the principle of least privilege.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised.
+- Implement enhanced monitoring for the affected account and similar user accounts to detect any further suspicious activity promptly."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_at.toml b/rules_building_block/lateral_movement_at.toml
index 7d63c514bbc..8a0f233df58 100644
--- a/rules_building_block/lateral_movement_at.toml
+++ b/rules_building_block/lateral_movement_at.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,40 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and process.name : "at.exe" and process.args : "\\\\*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 At.exe Command Lateral Movement
+
+The `at.exe` utility is a legacy Windows command-line tool used to schedule tasks on local or remote systems. Adversaries may exploit this tool to execute tasks on remote hosts, facilitating lateral movement within a network. The detection rule identifies suspicious use of `at.exe` by monitoring for its execution with arguments indicating remote task scheduling. This helps in pinpointing potential unauthorized task creations or modifications, which could signal malicious activity.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of at.exe, focusing on the process name and arguments, especially looking for remote task scheduling indicators such as "\\\\\\\\*".
+- Identify the source host from which the at.exe command was executed and determine if it is a known and authorized system within the network.
+- Investigate the target host(s) specified in the process arguments to assess if they are legitimate and expected targets for task scheduling from the source host.
+- Check the user account associated with the at.exe execution to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Examine the scheduled task details on the target host(s) to identify any unauthorized or suspicious tasks that may have been created or modified.
+- Correlate this event with other security alerts or logs to identify any patterns or additional indicators of lateral movement or compromise within the network.
+
+### False positive analysis
+
+- Scheduled administrative tasks: Routine administrative tasks scheduled by IT departments using at.exe on remote systems can trigger this rule. To manage this, identify and document legitimate scheduled tasks and create exceptions for these specific processes.
+- Automated software updates: Some software may use at.exe for automated updates or maintenance tasks across multiple systems. Verify the legitimacy of these updates and exclude them from the rule if they are confirmed to be safe.
+- Backup operations: Backup solutions might leverage at.exe for scheduling backups on remote machines. Confirm the backup processes and whitelist these operations to prevent false positives.
+- Monitoring and management tools: Certain network monitoring or management tools may utilize at.exe for legitimate purposes. Review these tools and their usage patterns, and exclude them if they are part of authorized network management activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Terminate any suspicious processes related to `at.exe` on the affected system to halt unauthorized task execution.
+- Review and remove any unauthorized scheduled tasks created via `at.exe` on both the local and remote systems.
+- Conduct a thorough investigation of the affected system to identify any additional indicators of compromise or persistence mechanisms.
+- Reset credentials for any accounts that were used to execute the `at.exe` command, especially if they have administrative privileges.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine the scope of the breach.
+- Implement enhanced monitoring and logging for `at.exe` usage across the network to detect and respond to similar threats in the future."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_posh_winrm_activity.toml b/rules_building_block/lateral_movement_posh_winrm_activity.toml
index 1ab4424ae66..5e4adb033c3 100644
--- a/rules_building_block/lateral_movement_posh_winrm_activity.toml
+++ b/rules_building_block/lateral_movement_posh_winrm_activity.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,40 @@ event.category:process and host.os.type:windows and
     "function Invoke-Command {"
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 PowerShell Script with Remote Execution Capabilities via WinRM
+
+Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. Adversaries exploit WinRM to move laterally within networks by executing PowerShell scripts remotely. The detection rule identifies suspicious use of PowerShell cmdlets like `Invoke-Command` and `Enter-PSSession` with remote execution intent, excluding benign processes and directories, to flag potential misuse.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text to identify the specific cmdlets and parameters used, focusing on "Invoke-WmiMethod", "Invoke-Command", or "Enter-PSSession" with "ComputerName" to understand the intent and target of the remote execution.
+- Check the user ID associated with the event to determine if it is a legitimate user or potentially compromised account, ensuring it is not "S-1-5-18" which is the SYSTEM account.
+- Investigate the source and destination IP addresses involved in the remote execution to assess if the activity is expected within the network or if it involves unusual or unauthorized systems.
+- Examine the file directory from which the PowerShell script was executed, ensuring it is not from "C:\\\\Program Files\\\\LogicMonitor\\\\Agent\\\\tmp", which is excluded as benign.
+- Correlate the event with other logs and alerts to identify any patterns or additional suspicious activities that might indicate lateral movement or further compromise within the network.
+- Assess the risk and impact of the detected activity by considering the context of the involved systems and users, and determine if immediate containment or further monitoring is necessary.
+
+### False positive analysis
+
+- Legitimate administrative tasks using PowerShell cmdlets like Invoke-Command or Enter-PSSession can trigger alerts. To manage this, create exceptions for known administrative accounts or specific user IDs that regularly perform these tasks.
+- Automated scripts from trusted software, such as monitoring tools, may use these cmdlets for legitimate purposes. Exclude directories associated with these tools, like C:\\Program Files\\LogicMonitor\\Agent\\tmp, to reduce false positives.
+- Scheduled tasks or maintenance scripts that use remote execution for system management can be mistaken for threats. Identify and whitelist these scripts by their file paths or script block text to prevent unnecessary alerts.
+- PowerShell modules that redefine or wrap cmdlets for legitimate use might trigger the rule. Review and exclude specific script block patterns that match these benign redefinitions to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activities.
+- Conduct a thorough review of the affected system's PowerShell logs and event logs to identify any additional indicators of compromise or related malicious activities.
+- Reset credentials for any accounts that were used in the suspicious PowerShell commands to prevent unauthorized access.
+- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could be exploited by similar threats.
+- Implement network segmentation to limit the ability of threats to move laterally across the network in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 [[rule.filters]]
 [rule.filters.meta]
diff --git a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
index c6ca1947e93..df32c9f47f9 100644
--- a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
+++ b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/01"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,39 @@ network where host.os.type == "windows" and
     ) and process.code_signature.trusted == true
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Potential Outgoing RDP Connection by Unusual Process
+
+Remote Desktop Protocol (RDP) enables users to connect to other systems over a network, facilitating remote management and troubleshooting. However, adversaries can exploit RDP for lateral movement within a network, bypassing traditional security measures by using non-standard processes. The detection rule identifies unusual processes attempting RDP connections, excluding known legitimate applications, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process executable path to determine if it is a known legitimate application or a potentially malicious one, focusing on paths not listed in the exclusion criteria.
+- Check the process code signature to verify if it is trusted or if there are any anomalies that might indicate tampering or a lack of a valid signature.
+- Investigate the source IP address and user account associated with the connection attempt to identify if they are known and authorized within the network.
+- Analyze historical network activity from the source host to identify any patterns or previous unusual behavior that might correlate with the current alert.
+- Examine any recent changes or installations on the source host that could explain the presence of an unusual process attempting an RDP connection.
+
+### False positive analysis
+
+- Legitimate third-party remote management tools may trigger false positives if they are not included in the exclusion list. Users should identify and add these tools to the exclusion list if they are verified as trusted and necessary for business operations.
+- Custom scripts or automation tools that initiate RDP connections for administrative purposes might be flagged. Ensure these scripts are signed and add them to the exclusion list if they are part of routine operations.
+- Internal security tools that perform network scans or health checks using RDP could be mistakenly identified as unusual processes. Verify these tools' signatures and include them in the exclusion list to prevent unnecessary alerts.
+- Development or testing environments where non-standard processes are used for RDP connections may generate alerts. Regularly review and update the exclusion list to accommodate these environments while ensuring they do not pose a security risk.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement by the adversary.
+- Terminate any suspicious processes identified as attempting the RDP connection that are not part of the known legitimate applications.
+- Conduct a thorough review of the affected host for any signs of compromise, including unauthorized user accounts, changes to system configurations, or presence of malware.
+- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access.
+- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known vulnerabilities that could be exploited for similar attacks.
+- Enhance monitoring and logging for RDP connections across the network to detect and respond to unusual activity promptly.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
index dbc9fce692a..4fd17c15540 100644
--- a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
+++ b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,40 @@ process where event.type == "start" and host.os.type == "windows" and
     (process.name : "cmd.exe" and process.parent.name : "forfiles.exe" and process.command_line : "/c echo *")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Unusual Process For MSSQL Service Accounts
+
+MSSQL service accounts are integral to managing SQL Server operations, executing processes necessary for database management. Adversaries may exploit these accounts to execute unauthorized processes, gaining initial access or moving laterally within a network. The detection rule identifies atypical processes initiated by MSSQL service accounts, excluding known legitimate processes, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and executable path, to determine if the process is expected or known to be associated with legitimate MSSQL operations.
+- Check the user account details, specifically the user.name and user.domain fields, to confirm if the process was initiated by a known MSSQL service account and verify if the account has been compromised or misused.
+- Investigate the parent process information to understand the process hierarchy and identify if the parent process is legitimate or if it indicates potential misuse or exploitation.
+- Analyze the process code signature details, focusing on the process.code_signature.subject_name and process.code_signature.trusted fields, to verify the authenticity and trust level of the process.
+- Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns that might indicate lateral movement or persistence tactics.
+- Consult with the database administration team to verify if any recent changes or updates could have triggered the alert, ensuring that the process is not part of a legitimate maintenance or update task.
+
+### False positive analysis
+
+- Legitimate administrative tasks using cmd.exe initiated by sqlservr.exe may trigger alerts. To manage this, create exceptions for specific command lines that are known to be safe and frequently used by administrators.
+- Scheduled tasks or maintenance scripts that use cmd.exe with forfiles.exe and specific command lines can be excluded if they are part of regular operations. Verify these tasks and add them to the exception list to prevent unnecessary alerts.
+- Processes signed by Microsoft Corporation and marked as trusted, such as wermgr.exe or conhost.exe, may occasionally be flagged. Ensure these are part of normal operations and add them to the exclusion list if they are consistently non-threatening.
+- Custom or third-party applications that interact with MSSQL services and are not listed in the known legitimate processes may cause false positives. Review these applications and, if verified as safe, include them in the exceptions to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes identified by the alert that are not part of the known legitimate processes for MSSQL service accounts.
+- Conduct a thorough review of the affected MSSQL service account credentials and reset them to prevent unauthorized access.
+- Analyze the system for any signs of persistence mechanisms or additional malware that may have been deployed by the attacker.
+- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.
+- Implement additional monitoring and logging for MSSQL service accounts to detect any future unauthorized activities promptly."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/lateral_movement_wmic_remote.toml b/rules_building_block/lateral_movement_wmic_remote.toml
index 0125b3949d9..005545b0028 100644
--- a/rules_building_block/lateral_movement_wmic_remote.toml
+++ b/rules_building_block/lateral_movement_wmic_remote.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,40 @@ process where host.os.type == "windows" and event.type == "start" and
   process.args : ("call", "set", "get") and
   not process.args : ("*/node:localhost*", "*/node:\"127.0.0.1\"*", "/node:127.0.0.1")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 WMIC Remote Command
+
+WMIC (Windows Management Instrumentation Command-line) is a powerful tool for managing Windows systems, allowing administrators to execute commands on remote hosts. However, adversaries can exploit WMIC for lateral movement by executing commands on remote systems without needing additional software. The detection rule identifies suspicious WMIC usage by monitoring command executions targeting non-local nodes, filtering out legitimate local operations, and flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of WMIC.exe, focusing on the process name and arguments to ensure they match the suspicious pattern identified in the query.
+- Examine the source and destination nodes involved in the command execution to determine if the remote node is a legitimate target for administrative tasks or if it appears unusual.
+- Check the user account associated with the WMIC command execution to verify if it is a known and authorized administrator account or if it appears suspicious.
+- Investigate the historical activity of the involved user account and source host to identify any patterns of lateral movement or other suspicious behavior.
+- Correlate the event with other security logs, such as authentication logs or network traffic, to gather additional context and identify potential unauthorized access or data exfiltration attempts.
+- Assess the risk and impact of the detected activity by considering the criticality of the involved systems and the potential for further compromise.
+
+### False positive analysis
+
+- Legitimate administrative tasks using WMIC to manage remote systems can trigger false positives. To handle this, identify and document regular administrative activities and create exceptions for these specific command patterns.
+- Automated scripts or scheduled tasks that use WMIC for routine maintenance or monitoring can be mistaken for suspicious activity. Review and whitelist these scripts by excluding their specific command signatures from the detection rule.
+- Internal IT tools that rely on WMIC for remote management may also cause false alerts. Collaborate with IT teams to understand these tools' usage patterns and adjust the rule to exclude known benign operations.
+- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in administrative practices or IT infrastructure to maintain the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools.
+- Terminate any suspicious WMIC processes identified on the affected system to stop any ongoing malicious activity.
+- Conduct a thorough review of user accounts and permissions on the affected system and any connected systems to identify unauthorized access or privilege escalation. Reset passwords and revoke access where necessary.
+- Check for any unauthorized changes or configurations on the affected system, especially those related to remote services, and revert them to their original state.
+- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected that cannot be easily remediated.
+- Enhance monitoring and logging on the affected and surrounding systems to detect any further suspicious activity, focusing on WMIC usage and remote service connections.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
index f4aaaef461d..389bf6b851e 100644
--- a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
+++ b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,40 @@ query = '''
 event.dataset: aws.cloudtrail and event.provider: "iam.amazonaws.com"
     and event.action: "CreateLoginProfile" and event.outcome: success
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS IAM Login Profile Added to User
+
+AWS IAM (Identity and Access Management) allows users to manage access to AWS services securely. A login profile enables console access for IAM users, typically used for programmatic access. Adversaries may exploit this by adding a login profile to maintain access even if keys are rotated. The detection rule identifies successful login profile creations, aiding in spotting unauthorized persistence attempts.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs to identify the user associated with the CreateLoginProfile event by examining the event.dataset and event.provider fields.
+- Check the IAM user’s activity history to determine if there are any unusual or unauthorized actions performed by this user, focusing on recent changes or access patterns.
+- Investigate the source IP address and geolocation associated with the CreateLoginProfile event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
+- Verify if the IAM user typically has console access or if this is an anomaly, as the rule suggests the user is usually for programmatic access only.
+- Correlate this event with other security alerts or logs to identify if there are additional indicators of compromise or persistence tactics being employed by an adversary.
+
+### False positive analysis
+
+- Routine administrative actions: Regularly scheduled maintenance or administrative tasks may involve creating login profiles for IAM users. To manage this, establish a baseline of expected administrative activities and exclude these from alerts.
+- Onboarding processes: New employee onboarding might include creating login profiles for IAM users. Coordinate with HR and IT departments to identify and exclude these events from triggering alerts.
+- Automated scripts: Some organizations use automated scripts to manage IAM users, which may include creating login profiles. Review and whitelist these scripts to prevent false positives.
+- Third-party integrations: Certain third-party services may require login profiles for integration purposes. Identify and document these services, then create exceptions for their legitimate activities.
+- Temporary access needs: Occasionally, temporary access might be granted to users for specific projects or tasks. Implement a process to track and exclude these temporary access events from alerting.
+
+### Response and remediation
+
+- Immediately disable the login profile for the affected IAM user to prevent unauthorized console access.
+- Review CloudTrail logs to identify any unauthorized activities performed by the IAM user after the login profile was created.
+- Rotate and reissue any access keys associated with the affected IAM user to ensure no further unauthorized programmatic access.
+- Conduct a thorough review of IAM policies and permissions associated with the affected user to ensure they align with the principle of least privilege.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for any future attempts to create login profiles on IAM users who typically do not require console access.
+- Consider enabling multi-factor authentication (MFA) for all IAM users to add an additional layer of security against unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
index 6da7d3f2bff..a89af91d7ee 100644
--- a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
+++ b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/01/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,41 @@ event.category:"process" and host.os.type:"linux" and event.type:"start" and eve
 (process.thread.capabilities.effective:"CAP_SYS_ADMIN" or process.thread.capabilities.permitted:"CAP_SYS_ADMIN") and
 not user.id:"0"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 CAP_SYS_ADMIN Assigned to Binary
+
+In Linux, the CAP_SYS_ADMIN capability grants extensive system administration privileges, enabling processes to perform critical operations like mounting filesystems and configuring networks. Adversaries may exploit binaries with this capability to escalate privileges. The detection rule identifies non-root processes with CAP_SYS_ADMIN, flagging potential misuse by monitoring process execution events.
+
+### Possible investigation steps
+
+- Review the process name and path to determine if it is a known or expected binary that should have CAP_SYS_ADMIN capabilities.
+- Check the user ID associated with the process to understand which non-root user is executing the binary and assess if this is expected behavior.
+- Investigate the parent process to understand how the binary was executed and if it was initiated by a legitimate process or user.
+- Examine recent system changes or configurations that might have inadvertently granted CAP_SYS_ADMIN capabilities to the binary.
+- Look for any related alerts or logs that might indicate suspicious activity or attempts to exploit the CAP_SYS_ADMIN capability.
+- Assess the system for any signs of compromise or unauthorized access, focusing on persistence mechanisms and privilege escalation attempts.
+
+### False positive analysis
+
+- System maintenance scripts may trigger alerts if they are scheduled to run with elevated capabilities. Review and whitelist these scripts if they are verified as safe and necessary for system operations.
+- Backup software often requires CAP_SYS_ADMIN to access and manage filesystems. Confirm the legitimacy of the backup process and exclude it from the rule if it is a trusted application.
+- Monitoring tools that need to gather extensive system metrics might use CAP_SYS_ADMIN. Validate these tools and create exceptions for them to prevent unnecessary alerts.
+- Virtualization software may use CAP_SYS_ADMIN to manage virtual machines. Ensure that the software is from a trusted source and exclude it if it is a regular part of your infrastructure.
+- Custom applications developed in-house might require CAP_SYS_ADMIN for specific functionalities. Conduct a security review of these applications and exclude them if they are deemed safe and essential.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any non-root processes identified with CAP_SYS_ADMIN capabilities to halt any unauthorized actions.
+- Conduct a thorough review of the system's capabilities and permissions to identify and remove any unnecessary CAP_SYS_ADMIN assignments from binaries.
+- Analyze the process execution logs to determine the origin and intent of the unauthorized process, focusing on identifying any potential entry points or vulnerabilities exploited.
+- Restore the system from a known good backup if any unauthorized changes or configurations are detected.
+- Implement stricter access controls and monitoring on systems with CAP_SYS_ADMIN capabilities to prevent future unauthorized access.
+- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_creation_of_kernel_module.toml b/rules_building_block/persistence_creation_of_kernel_module.toml
index 4ba49615de2..d37f32d5d94 100644
--- a/rules_building_block/persistence_creation_of_kernel_module.toml
+++ b/rules_building_block/persistence_creation_of_kernel_module.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,40 @@ file.extension == "ko" and not process.name : (
   "dpkg", "systemd", "falcon-sensor*", "dnf", "yum", "rpm", "cp"
 )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Creation of Kernel Module
+
+Kernel modules are dynamic components that extend the functionality of the Linux kernel, often used for hardware drivers or system enhancements. Adversaries may exploit this by loading malicious modules to gain persistence or execute unauthorized actions at a low level. The detection rule monitors the creation or modification of `.ko` files in the kernel module directory, excluding benign processes, to identify suspicious activity indicative of potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific `.ko` file path and the timestamp of its creation or modification in the `/lib/modules/` directory.
+- Investigate the process that triggered the alert by examining the process name and its parent process to determine if it is a known benign process or potentially malicious.
+- Check the system logs around the time of the alert for any unusual activity or errors that might provide additional context or indicate a compromise.
+- Verify the legitimacy of the `.ko` file by comparing its hash against known good hashes or by analyzing its contents for any suspicious code or behavior.
+- Assess the system for any other indicators of compromise, such as unexpected network connections or changes in system configurations, that might correlate with the kernel module activity.
+- Consult with system administrators or relevant personnel to confirm if the kernel module creation or modification was part of a legitimate update or maintenance activity.
+
+### False positive analysis
+
+- System updates and package installations can trigger the creation or modification of kernel module files. Processes like dpkg, dnf, yum, and rpm are typically involved in legitimate updates. Users can exclude these processes from triggering alerts by adding them to the exception list in the detection rule.
+- Security software such as falcon-sensor may create or modify kernel modules as part of their normal operation. To prevent false positives, users should ensure these processes are included in the exclusion list.
+- System management tools like systemd and cp may occasionally interact with kernel modules during routine operations. Users should verify these activities and consider excluding these processes if they are confirmed to be benign.
+- Custom scripts or administrative tasks that involve kernel module management might also cause false positives. Users should review these scripts and, if they are legitimate, add them to the exclusion criteria to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes associated with the creation or modification of `.ko` files, especially those not whitelisted in the detection rule.
+- Remove any unauthorized or malicious `.ko` files from the `/lib/modules/` directory to prevent them from being loaded into the kernel.
+- Conduct a thorough review of recent system changes and installed packages to identify any unauthorized modifications or installations.
+- Restore the system from a known good backup if malicious kernel modules have been loaded and system integrity is compromised.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for kernel module activities to detect similar threats in the future, ensuring alerts are promptly reviewed and acted upon."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_github_new_pat_for_user.toml b/rules_building_block/persistence_github_new_pat_for_user.toml
index 1e6f93f050b..46c96c0b88e 100644
--- a/rules_building_block/persistence_github_new_pat_for_user.toml
+++ b/rules_building_block/persistence_github_new_pat_for_user.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -35,6 +35,40 @@ event.dataset:"github.audit" and event.category:"configuration" and
 github.hashed_token:* and user.name:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 First Occurrence of Personal Access Token (PAT) Use For a GitHub User
+
+Personal Access Tokens (PATs) in GitHub provide a way to authenticate programmatic access to repositories, offering fine-grained permissions. Adversaries may exploit PATs to gain unauthorized access, maintain persistence, or manipulate accounts. This detection rule identifies unusual PAT usage by flagging tokens not seen in recent activity, helping to uncover potential misuse or unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to identify the specific user and hashed token involved in the alert. Focus on the event.dataset:"github.audit" and user.name fields to gather initial context.
+- Check the user's recent activity history within the last 14 days to determine if there are any other unusual or unauthorized actions associated with their account.
+- Investigate the source IP address and location associated with the PAT usage to verify if it aligns with the user's typical access patterns.
+- Examine the permissions and scopes granted to the PAT to assess the potential impact of its use and whether it aligns with the user's role and responsibilities.
+- Contact the user to confirm whether they generated the PAT and if they recognize the activity, ensuring it was not an unauthorized action.
+- Review any recent changes in the user's account settings or access permissions that might indicate account manipulation or compromise.
+
+### False positive analysis
+
+- Regularly scheduled automated scripts or integrations may trigger alerts if they use PATs that are rotated or updated frequently. To manage this, consider maintaining a list of known scripts and their associated tokens, and exclude these from the alert if they match expected patterns.
+- Developers or team members who frequently create and use new PATs for testing or development purposes might cause false positives. Implement a process to document and approve such activities, and exclude these users or tokens from the alert based on their documented usage patterns.
+- Organizational changes, such as onboarding new team members or shifting roles, can lead to new PATs being used legitimately. Establish a communication channel with HR or team leads to anticipate these changes and temporarily exclude affected users from the alert during their transition period.
+- Third-party applications or services that integrate with GitHub and require PATs might be flagged if they are updated or reconfigured. Maintain an inventory of these applications and their expected token usage, and exclude them from the alert if they align with known configurations.
+
+### Response and remediation
+
+- Immediately revoke the identified Personal Access Token (PAT) to prevent further unauthorized access.
+- Notify the affected user and relevant security teams about the potential compromise and provide guidance on securing their account.
+- Conduct a review of recent activities associated with the compromised PAT to identify any unauthorized actions or changes made to repositories.
+- Reset the user's GitHub account credentials and enforce multi-factor authentication (MFA) to enhance account security.
+- Implement additional monitoring for unusual activities on the affected account and related repositories to detect any further unauthorized access attempts.
+- Escalate the incident to the organization's incident response team for further investigation and to determine if additional systems or accounts may be affected.
+- Review and update access policies and permissions for all users to ensure that only necessary access is granted, reducing the risk of future unauthorized access."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_github_new_user_added_to_organization.toml b/rules_building_block/persistence_github_new_user_added_to_organization.toml
index 70bec844ae0..79cb6e44bb6 100644
--- a/rules_building_block/persistence_github_new_user_added_to_organization.toml
+++ b/rules_building_block/persistence_github_new_user_added_to_organization.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2024/12/10"
+updated_date = "2025/01/10"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -33,6 +33,41 @@ type = "eql"
 query = '''
 configuration where event.dataset == "github.audit" and event.action == "org.add_member"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 New User Added To GitHub Organization
+
+GitHub organizations manage collaborative projects, allowing users to contribute code and manage repositories. Adversaries may exploit this by adding unauthorized users to gain persistent access or manipulate accounts. The detection rule monitors audit logs for new member additions, flagging potential unauthorized access attempts, thus helping to identify and mitigate account manipulation threats.
+
+### Possible investigation steps
+
+- Review the GitHub audit logs to confirm the event details, specifically looking for entries where event.dataset is "github.audit" and event.action is "org.add_member" to verify the addition of the new user.
+- Identify the user who was added to the organization and gather information about their GitHub profile to assess their legitimacy and any potential connections to the organization.
+- Check the timestamp of the event to determine if the user addition occurred during unusual hours, which might indicate suspicious activity.
+- Investigate the user who performed the action of adding the new member to ensure they have the appropriate permissions and authority to do so.
+- Review recent activity logs for both the added user and the user who added them to identify any other unusual or unauthorized actions.
+- Contact the organization owner or relevant team members to confirm whether the addition of the new user was expected and authorized.
+
+### False positive analysis
+
+- Regular onboarding of new team members can trigger alerts. To manage this, maintain a list of known user additions and create exceptions for these events in the detection rule.
+- Automated processes or bots added to the organization for integration purposes may be flagged. Identify these accounts and exclude them from the rule to prevent unnecessary alerts.
+- Temporary contractors or external collaborators might be added frequently. Establish a process to review and whitelist these users if they are expected and authorized.
+- Organizational restructuring or team changes can lead to multiple legitimate user additions. Coordinate with HR or team leads to anticipate these changes and adjust the rule settings accordingly.
+- Scheduled audits or security reviews might involve adding users for verification purposes. Document these events and create temporary exceptions to avoid false positives during these periods.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the identity and legitimacy of the newly added user. Verify if the addition was authorized by a known and trusted member of the organization.
+- Temporarily suspend the new user's access to the organization if the addition is deemed unauthorized or suspicious, to prevent any potential malicious activity.
+- Notify the organization's security team and relevant stakeholders about the unauthorized addition to ensure awareness and prompt action.
+- Conduct a thorough review of recent changes and activities in the organization's repositories to identify any unauthorized modifications or suspicious behavior linked to the new user.
+- Revoke any unauthorized access tokens or credentials associated with the new user to prevent further unauthorized access.
+- Implement additional access controls, such as multi-factor authentication (MFA) and role-based access, to enhance security and prevent similar incidents in the future.
+- Escalate the incident to higher-level security management or an incident response team if the unauthorized access is part of a larger or more complex threat campaign."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
index e4a2ed6fd5e..9a6e4a798bf 100644
--- a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
+++ b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,40 @@ any where event.dataset == "aws.cloudtrail"
             or startsWith(event.action, "Tag")
     )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 AWS EC2 Instance Interaction with IAM Service
+
+AWS EC2 instances can assume IAM roles to access resources securely, using temporary credentials. Adversaries may exploit this by assuming roles to escalate privileges or establish persistence, often by creating or modifying IAM policies. The detection rule identifies unusual role assumptions by EC2 instances, focusing on actions like creating or updating resources, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the CloudTrail logs to identify the specific EC2 instance ID associated with the assumed role by checking the session name pattern "i-" in the user.id field.
+- Examine the event.action field to determine the specific actions taken by the EC2 instance, such as "Update", "Attach", "Create", or "Delete", to understand the scope of the activity.
+- Investigate the IAM role that was assumed by the EC2 instance to assess its permissions and determine if it has been modified recently or if it has excessive privileges.
+- Check for any recent changes in IAM policies or user accounts that could indicate privilege escalation or persistence attempts, focusing on actions like "CreateUser" or "AttachPolicy".
+- Correlate this activity with other security events or alerts in the environment to identify potential patterns of malicious behavior or lateral movement.
+
+### False positive analysis
+
+- Routine administrative tasks by authorized personnel may trigger the rule. To manage this, identify and document regular IAM role assumptions by EC2 instances for legitimate purposes and create exceptions for these patterns.
+- Automated processes or scripts that require IAM role assumptions for resource management can cause false positives. Review and whitelist these processes by their specific EC2 instance IDs or session names.
+- Scheduled maintenance activities involving IAM role assumptions might be flagged. Coordinate with the operations team to understand the schedule and exclude these activities from triggering alerts.
+- Development and testing environments often have frequent role assumptions for testing purposes. Isolate these environments and apply separate monitoring rules to avoid unnecessary alerts.
+- Third-party integrations that require IAM role assumptions should be reviewed and documented. Establish a baseline of expected behavior and exclude these from the rule if they are deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance to prevent further unauthorized actions. This can be done by removing it from any security groups that allow outbound internet access or by stopping the instance if necessary.
+- Revoke the temporary credentials associated with the assumed role to cut off any ongoing unauthorized access. This can be done by invalidating the session tokens.
+- Review and audit the IAM role and policies associated with the EC2 instance to identify any unauthorized changes. Revert any suspicious modifications to their original state.
+- Conduct a thorough investigation of the EC2 instance to identify any signs of compromise, such as unauthorized software or scripts, and remove any malicious artifacts found.
+- Rotate all credentials and access keys that may have been exposed or compromised during the incident to prevent further unauthorized access.
+- Escalate the incident to the security operations team for a comprehensive review and to determine if further actions are needed, such as notifying affected parties or involving legal authorities.
+- Implement enhanced monitoring and logging for IAM role assumptions and EC2 instance activities to detect similar threats in the future, ensuring that alerts are configured to notify the security team promptly."""
 
 [rule.investigation_fields]
 field_names = [
diff --git a/rules_building_block/persistence_startup_folder_lnk.toml b/rules_building_block/persistence_startup_folder_lnk.toml
index 0cfb8ff93eb..408296989db 100644
--- a/rules_building_block/persistence_startup_folder_lnk.toml
+++ b/rules_building_block/persistence_startup_folder_lnk.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -44,6 +44,41 @@ file where host.os.type == "windows" and event.type != "deletion" and file.exten
     (process.name : "APPServerClient.exe" and process.code_signature.status: "trusted" and file.name : "Parallels Client.lnk")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Shortcut File Written or Modified on Startup Folder
+
+In Windows environments, the Startup folder is used to launch programs automatically when a user logs in. Adversaries exploit this by placing or altering shortcut files (.lnk) in this folder to achieve persistence. The detection rule monitors for non-deletion events involving .lnk files in the Startup paths, excluding trusted processes, to identify potential unauthorized modifications indicative of malicious activity.
+
+### Possible investigation steps
+
+- Review the file path and name of the .lnk file involved in the alert to determine if it matches any known malicious patterns or if it is associated with legitimate software.
+- Check the process name and code signature status that created or modified the .lnk file to verify if it is a trusted process or potentially malicious.
+- Investigate the user account associated with the file path to determine if there are any signs of compromise or unusual activity.
+- Examine recent login events and other security logs for the user to identify any suspicious behavior or unauthorized access.
+- Cross-reference the .lnk file with threat intelligence sources to see if it is associated with known malware or adversary techniques.
+- If the .lnk file is deemed suspicious, isolate the affected system and perform a deeper forensic analysis to identify any additional indicators of compromise.
+
+### False positive analysis
+
+- Trusted applications like OneNote, Okta Verify, OneLaunch, and Parallels Client may create or modify shortcut files in the Startup folder as part of their normal operation. These are not malicious activities and can be safely excluded from the detection rule.
+- To handle these false positives, ensure that the detection rule includes exceptions for processes with verified code signatures that are known to create legitimate shortcuts, as specified in the rule.
+- Regularly review and update the list of trusted processes and their associated shortcut files to ensure that new legitimate applications are not flagged as suspicious.
+- Consider implementing a whitelist approach where only known and trusted applications are allowed to modify the Startup folder, reducing the likelihood of false positives.
+- Engage with users to understand their typical software usage patterns, which can help in identifying and excluding benign activities that may otherwise trigger the rule.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or persistence by the adversary.
+- Terminate any suspicious processes that are not recognized or trusted, especially those associated with the creation or modification of .lnk files in the Startup folder.
+- Remove any unauthorized or suspicious .lnk files from the Startup folder paths to prevent them from executing on system startup.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or software.
+- Review and restore any altered system configurations or settings to their default or secure state to ensure system integrity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement additional monitoring and alerting for similar activities across the network to enhance detection and response capabilities for future incidents."""
 
 
 [[rule.threat]]
diff --git a/rules_building_block/persistence_transport_agent_exchange.toml b/rules_building_block/persistence_transport_agent_exchange.toml
index d4a1efd3be7..49d7fdb6a96 100644
--- a/rules_building_block/persistence_transport_agent_exchange.toml
+++ b/rules_building_block/persistence_transport_agent_exchange.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/10"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -64,6 +64,40 @@ event.category: "process" and host.os.type:windows and
     ("scriptCmd.GetSteppablePipeline" and "ForwardHelpTargetName Install-TransportAgent")
   )
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Microsoft Exchange Transport Agent Install Script
+
+Microsoft Exchange Transport Agents are components that process email messages as they move through the transport pipeline. They can be customized to perform tasks like filtering or modifying messages. However, adversaries may exploit these agents to maintain persistence by installing malicious agents that execute tasks based on specific triggers. The detection rule identifies suspicious use of PowerShell cmdlets related to installing or enabling these agents, excluding known benign activities, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to understand the context and intent of the commands executed, focusing on the use of "Install-TransportAgent" or "Enable-TransportAgent".
+- Check the user account associated with the alert, especially since the query excludes the system account (S-1-5-18), to determine if the activity is expected or if the account may have been compromised.
+- Investigate the host where the alert was triggered to identify any recent changes or anomalies, such as new software installations or configuration changes, that could indicate malicious activity.
+- Examine PowerShell logs and other relevant security logs on the host for additional suspicious activities or patterns that coincide with the time of the alert.
+- Cross-reference the alert with known benign activities that are excluded in the query to ensure the activity is not part of a legitimate administrative task.
+- Assess the risk and impact of the detected activity by considering the role of the affected Exchange server and the potential consequences of a compromised transport agent.
+
+### False positive analysis
+
+- Legitimate administrative tasks using Install-TransportAgent or Enable-TransportAgent can trigger alerts. To manage this, create exceptions for known administrative accounts or scripts that regularly perform these tasks.
+- Scheduled maintenance activities involving PowerShell cmdlets related to Exchange Transport Agents may be flagged. Document and exclude these activities by identifying their specific script block text patterns.
+- Automated monitoring or backup solutions that invoke similar cmdlets might cause false positives. Review and whitelist these processes by their user IDs or script block text to prevent unnecessary alerts.
+- Ensure that any exclusions do not inadvertently allow malicious activity by regularly reviewing and updating exception lists based on current threat intelligence and organizational changes.
+
+### Response and remediation
+
+- Immediately isolate the affected Exchange server from the network to prevent further malicious activity and potential lateral movement by the adversary.
+- Review and disable any suspicious or unauthorized transport agents identified on the Exchange server to halt any ongoing malicious processes.
+- Conduct a thorough examination of PowerShell logs and other relevant system logs to identify any additional indicators of compromise or related malicious activities.
+- Restore the affected Exchange server from a known good backup taken before the suspicious activity was detected to ensure system integrity.
+- Apply the latest security patches and updates to the Exchange server to mitigate any known vulnerabilities that could be exploited by adversaries.
+- Implement enhanced monitoring and alerting for PowerShell activities and transport agent modifications to detect any future unauthorized changes promptly.
+- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be compromised."""
 
 
 [[rule.filters]]
diff --git a/rules_building_block/privilege_escalation_trap_execution.toml b/rules_building_block/privilege_escalation_trap_execution.toml
index 52787ad90e8..3f632fff5ec 100644
--- a/rules_building_block/privilege_escalation_trap_execution.toml
+++ b/rules_building_block/privilege_escalation_trap_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/10"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,40 @@ query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name == "trap" and process.args : "SIG*"
 '''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was generated 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 Trap Signals Execution
+Trap signals in Unix-like systems allow programs to execute specific commands when receiving interrupt signals, such as SIGINT or SIGTERM. Adversaries exploit this by embedding malicious commands in trap handlers to gain elevated privileges or persist on a system. The detection rule identifies suspicious trap command executions by monitoring process start events with specific signal arguments, helping to uncover potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the presence of a trap command execution, focusing on the process.name field to ensure it matches "trap".
+- Examine the process.args field to identify the specific signal (e.g., SIGINT, SIGTERM) that triggered the trap command, and assess whether the associated commands are legitimate or potentially malicious.
+- Investigate the parent process of the trap command by analyzing the process lineage to determine if it was initiated by a trusted or suspicious source.
+- Check the user context under which the trap command was executed to identify if it was run by a privileged user or an unexpected account.
+- Correlate the event with other logs or alerts from the same host or user to identify any patterns of suspicious behavior or previous privilege escalation attempts.
+- Review system logs for any additional indicators of compromise or unusual activity around the time of the trap command execution to gather more context on the potential threat.
+
+### False positive analysis
+
+- Routine system maintenance scripts may use trap commands to handle signals gracefully. Review these scripts to ensure they are legitimate and consider excluding them from the rule if they are frequently flagged.
+- Development environments often use trap commands for debugging purposes. Identify and document these environments, and create exceptions for known development processes to prevent unnecessary alerts.
+- Backup and recovery processes might employ trap commands to manage interruptions. Verify these processes and exclude them if they are consistently identified as false positives.
+- System monitoring tools may use trap commands to handle signals for logging or alerting purposes. Confirm the legitimacy of these tools and exclude them from the rule if they are trusted and regularly trigger alerts.
+- Custom user scripts that include trap commands for personal workflow automation can be a source of false positives. Encourage users to register their scripts with the security team to assess and potentially exclude them from monitoring.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with the trap command execution to halt potential privilege escalation.
+- Conduct a thorough review of the affected system's trap handlers and shell configurations to identify and remove any unauthorized or malicious entries.
+- Restore the system from a known good backup if malicious modifications are detected and cannot be easily reversed.
+- Implement stricter access controls and monitoring on systems to prevent unauthorized modifications to trap handlers and shell configurations.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Update and enhance detection capabilities to monitor for similar trap command executions and other related privilege escalation attempts in the future."""
 
 
 [[rule.threat]]

From 9cf51e37d58522bcb68bab19a980adc336a8dad1 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Tue, 14 Jan 2025 15:44:19 -0600
Subject: [PATCH 05/16] update disclaimer

---
 rules/apm/apm_403_response_to_a_post.toml     |  2 +-
 .../apm_405_response_method_not_allowed.toml  |  2 +-
 rules/apm/apm_sqlmap_user_agent.toml          |  2 +-
 ..._google_drive_malicious_file_download.toml | 12 +++---
 ...and_and_control_non_standard_ssh_port.toml |  4 +-
 ...s_cookies_chromium_browsers_debugging.toml |  2 +-
 ...al_access_forced_authentication_pipes.toml |  2 +-
 ..._evasion_agent_spoofing_mismatched_id.toml |  2 +-
 ...evasion_agent_spoofing_multiple_hosts.toml |  2 +-
 ...e_evasion_deleting_websvr_access_logs.toml |  2 +-
 ...deletion_of_bash_command_line_history.toml |  2 +-
 ...sion_elastic_agent_service_terminated.toml |  2 +-
 ..._evasion_encoding_rot13_python_script.toml |  2 +-
 ...ion_masquerading_space_after_filename.toml |  2 +-
 .../defense_evasion_timestomp_touch.toml      |  2 +-
 ...y_virtual_machine_fingerprinting_grep.toml |  2 +-
 ...m_sendcommand_with_command_parameters.toml |  2 +-
 ...on_pentest_eggshell_remote_admin_tool.toml |  2 +-
 ...otential_widespread_malware_infection.toml |  2 +-
 ...tion_suspicious_java_netcon_childproc.toml |  2 +-
 .../guided_onboarding_sample_rule.toml        |  2 +-
 ..._access_zoom_meeting_with_no_passcode.toml |  2 +-
 ...ultiple_alerts_different_tactics_host.toml |  2 +-
 .../multiple_alerts_involving_user.toml       |  2 +-
 ...l_access_modify_auth_module_or_config.toml |  2 +-
 ...ersistence_shell_profile_modification.toml |  2 +-
 ...ence_ssh_authorized_keys_modification.toml |  6 +--
 ...lege_escalation_echo_nopasswd_sudoers.toml |  2 +-
 ...ation_setuid_setgid_bit_set_via_chmod.toml |  2 +-
 ...ilege_escalation_sudo_buffer_overflow.toml |  2 +-
 ...privilege_escalation_sudoers_file_mod.toml |  4 +-
 ...collection_cloudtrail_logging_created.toml |  2 +-
 ...cess_root_console_failure_brute_force.toml |  2 +-
 ...vasion_configuration_recorder_stopped.toml |  2 +-
 ...ense_evasion_ec2_network_acl_deletion.toml |  2 +-
 ...n_elasticache_security_group_creation.toml |  2 +-
 ...he_security_group_modified_or_deleted.toml |  2 +-
 ...e_evasion_guardduty_detector_deletion.toml |  2 +-
 ...defense_evasion_rds_instance_restored.toml | 10 ++---
 ...sion_s3_bucket_configuration_deletion.toml |  2 +-
 ...ense_evasion_sts_get_federation_token.toml |  2 +-
 .../aws/defense_evasion_waf_acl_deletion.toml |  2 +-
 ...asion_waf_rule_or_rule_group_deletion.toml |  2 +-
 ...s_multi_region_service_quota_requests.toml |  2 +-
 ..._new_terms_cloudformation_createstack.toml |  2 +-
 ..._full_network_packet_capture_detected.toml |  2 +-
 .../exfiltration_ec2_vm_export_failure.toml   |  2 +-
 .../aws/exfiltration_rds_snapshot_export.toml |  2 +-
 ..._eventbridge_rule_disabled_or_deleted.toml |  2 +-
 .../impact_ec2_disable_ebs_encryption.toml    |  2 +-
 ...mpact_efs_filesystem_or_mount_deleted.toml |  2 +-
 .../aws/impact_iam_group_deletion.toml        |  2 +-
 ...mk_disabled_or_scheduled_for_deletion.toml |  2 +-
 .../aws/impact_rds_group_deletion.toml        |  2 +-
 .../impact_rds_instance_cluster_deletion.toml |  2 +-
 .../impact_rds_instance_cluster_stoppage.toml |  2 +-
 .../aws/impact_rds_snapshot_deleted.toml      |  4 +-
 .../aws/initial_access_password_recovery.toml |  2 +-
 ...al_access_signin_console_login_no_mfa.toml |  2 +-
 ...l_movement_ec2_instance_console_login.toml |  4 +-
 .../persistence_ec2_network_acl_creation.toml |  2 +-
 ..._group_configuration_change_detection.toml |  2 +-
 ...nce_iam_create_login_profile_for_root.toml |  2 +-
 .../aws/persistence_iam_group_creation.toml   |  2 +-
 .../aws/persistence_rds_cluster_creation.toml |  2 +-
 .../aws/persistence_rds_group_creation.toml   |  2 +-
 .../persistence_rds_instance_creation.toml    |  2 +-
 ...ersistence_redshift_instance_creation.toml |  2 +-
 ...oute_53_domain_transfer_lock_disabled.toml |  2 +-
 ...domain_transferred_to_another_account.toml |  2 +-
 ..._53_hosted_zone_associated_with_a_vpc.toml |  2 +-
 .../aws/persistence_route_table_created.toml  |  2 +-
 ...tence_route_table_modified_or_deleted.toml |  2 +-
 ...sistence_sts_assume_role_with_new_mfa.toml |  6 +--
 ..._escalation_iam_saml_provider_updated.toml |  2 +-
 ..._escalation_sts_getsessiontoken_abuse.toml |  2 +-
 ...rivilege_escalation_sts_role_chaining.toml |  6 +--
 ...collection_update_event_hub_auth_rule.toml |  2 +-
 ..._full_network_packet_capture_detected.toml |  2 +-
 ...d_device_code_auth_with_broker_client.toml |  2 +-
 ...ntra_signin_brute_force_microsoft_365.toml |  2 +-
 ...ute_force_microsoft_365_repeat_source.toml |  2 +-
 ...cess_first_time_seen_device_code_auth.toml |  6 +--
 .../credential_access_key_vault_modified.toml |  2 +-
 ...ccess_storage_account_key_regenerated.toml |  2 +-
 ...e_application_credential_modification.toml |  2 +-
 ...sion_azure_automation_runbook_deleted.toml |  2 +-
 ...asion_azure_blob_permissions_modified.toml |  2 +-
 ...on_azure_diagnostic_settings_deletion.toml |  2 +-
 .../defense_evasion_event_hub_deletion.toml   |  2 +-
 ...ense_evasion_firewall_policy_deletion.toml |  2 +-
 ...on_frontdoor_firewall_policy_deletion.toml |  2 +-
 ...nse_evasion_kubernetes_events_deleted.toml |  2 +-
 ...ense_evasion_network_watcher_deletion.toml |  2 +-
 ...ense_evasion_suppression_rule_created.toml |  2 +-
 .../discovery_blob_container_access_mod.toml  |  2 +-
 .../execution_command_virtual_machine.toml    |  2 +-
 ...e_service_principal_credentials_added.toml |  2 +-
 .../azure/impact_kubernetes_pod_deleted.toml  |  2 +-
 .../azure/impact_resource_group_deletion.toml |  2 +-
 ...mpact_virtual_network_device_modified.toml |  2 +-
 ...ial_access_external_guest_user_invite.toml |  2 +-
 ...ence_azure_automation_account_created.toml |  2 +-
 ...utomation_runbook_created_or_modified.toml |  2 +-
 ...ence_azure_automation_webhook_created.toml |  2 +-
 ...re_conditional_access_policy_modified.toml |  2 +-
 ...re_global_administrator_role_assigned.toml |  2 +-
 ...nce_azure_pim_user_added_global_admin.toml |  2 +-
 ..._added_as_owner_for_azure_application.toml |  2 +-
 ..._as_owner_for_azure_service_principal.toml |  2 +-
 ..._azure_kubernetes_rolebinding_created.toml |  2 +-
 .../command_and_control_beaconing.toml        |  8 ++--
 ...and_control_beaconing_high_confidence.toml |  2 +-
 .../container_workload_protection.toml        |  2 +-
 ...s_aws_creds_search_inside_a_container.toml |  8 ++--
 ..._files_compression_inside_a_container.toml | 30 +++++++--------
 ...r_passwords_search_inside_a_container.toml | 14 +++----
 ...ed_object_modified_inside_a_container.toml |  2 +-
 ...work_tool_launched_inside_a_container.toml |  6 +--
 ...nt_binary_launched_inside_a_container.toml |  4 +-
 ...ecutable_via_chmod_inside_a_container.toml |  4 +-
 ...ecution_interactive_exec_to_container.toml |  6 +--
 ...shell_spawned_from_inside_a_container.toml |  4 +-
 ...stener_established_inside_a_container.toml |  6 +--
 ...ection_established_inside_a_container.toml |  8 ++--
 ...h_process_launched_inside_a_container.toml |  4 +-
 ..._keys_modification_inside_a_container.toml |  2 +-
 ...aunched_inside_a_privileged_container.toml |  6 +--
 ...aunched_inside_a_privileged_container.toml |  4 +-
 ...e_via_modified_notify_on_release_file.toml |  4 +-
 ...scape_via_modified_release_agent_file.toml |  4 +-
 ...ytes_destination_geo_country_iso_code.toml |  6 +--
 ...ltration_ml_high_bytes_destination_ip.toml |  6 +--
 ...ration_ml_high_bytes_destination_port.toml |  6 +--
 ...ml_high_bytes_destination_region_name.toml |  6 +--
 ...high_bytes_written_to_external_device.toml |  6 +--
 ...es_written_to_external_device_airdrop.toml |  6 +--
 ...re_process_writing_to_external_device.toml |  6 +--
 ...ml_dga_activity_using_sunburst_domain.toml |  4 +-
 ...d_control_ml_dga_high_sum_probability.toml |  6 +--
 ...l_ml_dns_request_high_dga_probability.toml |  4 +-
 ..._request_predicted_to_be_a_dga_domain.toml |  4 +-
 .../endpoint/elastic_endpoint_security.toml   |  2 +-
 ...istence_suspicious_file_modifications.toml |  2 +-
 ...ion_gcp_pub_sub_subscription_creation.toml |  2 +-
 ...collection_gcp_pub_sub_topic_creation.toml |  2 +-
 ...nse_evasion_gcp_firewall_rule_created.toml |  2 +-
 ...nse_evasion_gcp_firewall_rule_deleted.toml |  2 +-
 ...se_evasion_gcp_firewall_rule_modified.toml |  2 +-
 ...e_evasion_gcp_logging_bucket_deletion.toml |  2 +-
 ...nse_evasion_gcp_logging_sink_deletion.toml |  2 +-
 ...ion_gcp_pub_sub_subscription_deletion.toml |  2 +-
 ...se_evasion_gcp_pub_sub_topic_deletion.toml |  2 +-
 ...storage_bucket_configuration_modified.toml |  2 +-
 ...p_storage_bucket_permissions_modified.toml |  2 +-
 ...virtual_private_cloud_network_deleted.toml |  2 +-
 ...p_virtual_private_cloud_route_created.toml |  2 +-
 ...p_virtual_private_cloud_route_deleted.toml |  2 +-
 ...tration_gcp_logging_sink_modification.toml |  2 +-
 .../gcp/impact_gcp_iam_role_deletion.toml     |  2 +-
 .../impact_gcp_service_account_deleted.toml   |  2 +-
 .../impact_gcp_service_account_disabled.toml  |  2 +-
 .../impact_gcp_storage_bucket_deleted.toml    |  2 +-
 ...l_access_gcp_iam_custom_role_creation.toml |  2 +-
 ..._gcp_iam_service_account_key_deletion.toml |  2 +-
 ...e_gcp_key_created_for_service_account.toml |  2 +-
 ...rsistence_gcp_service_account_created.toml |  2 +-
 ...hub_protected_branch_settings_changed.toml |  2 +-
 .../github/execution_github_app_deleted.toml  |  2 +-
 ..._high_number_of_cloned_repos_from_pat.toml |  2 +-
 ...multiple_behavior_alerts_from_account.toml |  2 +-
 .../execution_new_github_app_installed.toml   |  2 +-
 .../impact_github_repository_deleted.toml     |  2 +-
 .../persistence_github_org_owner_added.toml   |  2 +-
 ...tence_organization_owner_role_granted.toml |  2 +-
 ...yption_key_accessed_by_anonymous_user.toml |  2 +-
 ...th_login_from_third_party_application.toml |  2 +-
 ...ogle_workspace_suspended_user_renewed.toml |  2 +-
 ...covery_denied_service_account_request.toml |  2 +-
 ...covery_suspicious_self_subject_review.toml |  2 +-
 .../execution_user_exec_to_pod.toml           |  2 +-
 ...l_access_anonymous_request_authorized.toml |  2 +-
 ...ed_service_created_with_type_nodeport.toml |  2 +-
 ...e_escalation_pod_created_with_hostipc.toml |  2 +-
 ...calation_pod_created_with_hostnetwork.toml |  2 +-
 ...e_escalation_pod_created_with_hostpid.toml |  2 +-
 ...reated_with_sensitive_hostpath_volume.toml |  2 +-
 ...ege_escalation_privileged_pod_created.toml |  2 +-
 ...ignment_of_controller_service_account.toml |  2 +-
 ...ovement_ml_high_mean_rdp_process_args.toml |  4 +-
 ...ent_ml_high_mean_rdp_session_duration.toml |  4 +-
 ...ral_movement_ml_high_remote_file_size.toml |  4 +-
 ...ml_high_variance_rdp_session_duration.toml |  4 +-
 ...ovement_ml_rare_remote_file_directory.toml |  4 +-
 ...ovement_ml_rare_remote_file_extension.toml |  4 +-
 ...spike_in_connections_from_a_source_ip.toml |  4 +-
 ...ke_in_connections_to_a_destination_ip.toml |  4 +-
 ...al_movement_ml_spike_in_rdp_processes.toml |  4 +-
 ...ent_ml_spike_in_remote_file_transfers.toml |  4 +-
 ...nt_ml_unusual_time_for_an_rdp_session.toml |  4 +-
 ...llection_microsoft_365_new_inbox_rule.toml |  2 +-
 ..._365_brute_force_user_account_attempt.toml |  2 +-
 ...65_potential_password_spraying_attack.toml |  2 +-
 ...ccess_user_excessive_sso_logon_errors.toml |  2 +-
 ...osoft_365_exchange_dlp_policy_removed.toml |  2 +-
 ...change_malware_filter_policy_deletion.toml |  2 +-
 ..._365_exchange_malware_filter_rule_mod.toml |  2 +-
 ...65_exchange_safe_attach_rule_disabled.toml |  2 +-
 ...oft_365_mailboxauditbypassassociation.toml |  2 +-
 ..._365_exchange_transport_rule_creation.toml |  2 +-
 ...osoft_365_exchange_transport_rule_mod.toml |  2 +-
 ...ft_365_mass_download_by_a_single_user.toml |  2 +-
 ...oft_365_potential_ransomware_activity.toml |  2 +-
 ...t_365_unusual_volume_of_file_deletion.toml |  2 +-
 ...5_exchange_anti_phish_policy_deletion.toml |  2 +-
 ...soft_365_exchange_anti_phish_rule_mod.toml |  2 +-
 ...osoft_365_exchange_safelinks_disabled.toml |  2 +-
 ...rosoft_365_impossible_travel_activity.toml |  2 +-
 ...t_365_impossible_travel_portal_logins.toml |  2 +-
 ...t_365_portal_login_from_rare_location.toml |  2 +-
 ...65_user_restricted_from_sending_email.toml |  2 +-
 ...cess_o365_user_reported_phish_malware.toml |  2 +-
 ...al_movement_malware_uploaded_onedrive.toml |  2 +-
 ..._movement_malware_uploaded_sharepoint.toml |  2 +-
 ...e_suspicious_mailbox_right_delegation.toml |  2 +-
 ...exchange_dkim_signing_config_disabled.toml |  2 +-
 ...5_exchange_management_role_assignment.toml |  2 +-
 ..._365_global_administrator_role_assign.toml |  2 +-
 ..._teams_custom_app_interaction_allowed.toml |  2 +-
 ...oft_365_teams_external_access_enabled.toml |  2 +-
 ...rosoft_365_teams_guest_access_enabled.toml |  2 +-
 ...ion_new_or_modified_federation_domain.toml |  2 +-
 ..._app_client_credential_token_exchange.toml |  2 +-
 ...ta_attempt_to_delete_okta_application.toml |  2 +-
 ...ta_attempt_to_modify_okta_application.toml |  2 +-
 .../okta/impact_possible_okta_dos_attack.toml |  2 +-
 ...initial_access_okta_fastpass_phishing.toml |  2 +-
 ...ta_user_attempted_unauthorized_access.toml |  2 +-
 ...cation_sso_from_unknown_client_device.toml |  2 +-
 ...icious_activity_reported_by_okta_user.toml |  2 +-
 ...ent_multiple_sessions_for_single_user.toml |  2 +-
 ...tor_privileges_assigned_to_okta_group.toml |  2 +-
 ...inistrator_role_assigned_to_okta_user.toml |  2 +-
 ...ence_attempt_to_create_okta_api_token.toml |  2 +-
 ...set_mfa_factors_for_okta_user_account.toml |  2 +-
 ..._or_delete_application_sign_on_policy.toml |  2 +-
 ...se_evasion_ml_rare_process_for_a_host.toml |  4 +-
 ..._ml_rare_process_for_a_parent_process.toml |  4 +-
 ...se_evasion_ml_rare_process_for_a_user.toml |  4 +-
 ...icious_windows_event_high_probability.toml |  4 +-
 ...picious_windows_event_low_probability.toml |  4 +-
 ...ous_windows_process_cluster_from_host.toml |  4 +-
 ...s_process_cluster_from_parent_process.toml |  4 +-
 ...ous_windows_process_cluster_from_user.toml |  4 +-
 .../collection_linux_clipboard_activity.toml  |  2 +-
 ...and_control_aws_cli_endpoint_url_used.toml |  2 +-
 ...and_control_curl_socks_proxy_detected.toml |  6 +--
 ...nd_and_control_ip_forwarding_activity.toml |  2 +-
 ...mand_and_control_linux_kworker_netcon.toml |  4 +-
 ...ial_access_collection_sensitive_files.toml |  2 +-
 .../credential_access_credential_dumping.toml |  2 +-
 ...ntial_access_gdb_init_process_hooking.toml |  4 +-
 ...credential_access_gdb_process_hooking.toml |  4 +-
 ...ential_linux_local_account_bruteforce.toml |  4 +-
 ...ntial_successful_linux_ftp_bruteforce.toml |  2 +-
 ...ntial_successful_linux_rdp_bruteforce.toml |  2 +-
 ...ential_access_proc_credential_dumping.toml |  2 +-
 .../credential_access_ssh_backdoor_log.toml   |  2 +-
 ...instance_metadata_service_api_request.toml |  2 +-
 ..._evasion_acl_modification_via_setfacl.toml |  2 +-
 ...ion_attempt_to_disable_auditd_service.toml |  2 +-
 ...tempt_to_disable_iptables_or_firewall.toml |  2 +-
 ...ion_attempt_to_disable_syslog_service.toml |  2 +-
 ..._base32_encoding_or_decoding_activity.toml |  2 +-
 ...binary_copied_to_suspicious_directory.toml |  4 +-
 ...defense_evasion_chattr_immutable_file.toml |  2 +-
 ...ense_evasion_clear_kernel_ring_buffer.toml |  2 +-
 ..._creation_of_hidden_files_directories.toml |  2 +-
 ...nse_evasion_directory_creation_in_bin.toml |  4 +-
 ...ense_evasion_disable_apparmor_attempt.toml |  4 +-
 ...fense_evasion_disable_selinux_attempt.toml |  2 +-
 ...doas_configuration_creation_or_rename.toml |  2 +-
 ..._evasion_dynamic_linker_file_creation.toml |  2 +-
 ...asion_esxi_suspicious_timestomp_touch.toml |  2 +-
 ...fense_evasion_file_deletion_via_shred.toml |  2 +-
 ...defense_evasion_file_mod_writable_dir.toml |  2 +-
 ...defense_evasion_hex_payload_execution.toml |  2 +-
 ...nse_evasion_hidden_directory_creation.toml |  2 +-
 .../defense_evasion_hidden_file_dir_tmp.toml  |  2 +-
 .../defense_evasion_hidden_shared_object.toml |  2 +-
 ...on_interactive_shell_from_system_user.toml |  4 +-
 ...defense_evasion_kernel_module_removal.toml |  2 +-
 ...defense_evasion_kthreadd_masquerading.toml |  2 +-
 .../linux/defense_evasion_ld_so_creation.toml |  2 +-
 .../defense_evasion_log_files_deleted.toml    |  2 +-
 .../defense_evasion_mount_execution.toml      |  2 +-
 ...ense_evasion_potential_proot_exploits.toml |  2 +-
 .../defense_evasion_rename_esxi_files.toml    |  2 +-
 ...efense_evasion_rename_esxi_index_file.toml |  2 +-
 ...evasion_root_certificate_installation.toml |  2 +-
 ...ux_configuration_creation_or_renaming.toml |  2 +-
 ...ense_evasion_ssl_certificate_deletion.toml |  2 +-
 ...s_utility_executed_via_tmux_or_screen.toml |  4 +-
 ...ense_evasion_unusual_preload_env_vars.toml |  2 +-
 .../discovery_dynamic_linker_via_od.toml      |  2 +-
 .../discovery_esxi_software_via_find.toml     |  4 +-
 .../discovery_esxi_software_via_grep.toml     |  2 +-
 .../discovery_kernel_module_enumeration.toml  |  6 +--
 .../linux/discovery_linux_hping_activity.toml |  2 +-
 .../linux/discovery_linux_nping_activity.toml |  2 +-
 .../discovery_pam_version_discovery.toml      |  2 +-
 .../linux/discovery_ping_sweep_detected.toml  |  2 +-
 ...ivate_key_password_searching_activity.toml |  2 +-
 rules/linux/discovery_proc_maps_read.toml     |  2 +-
 .../linux/discovery_process_capabilities.toml |  2 +-
 ...very_pspy_process_monitoring_detected.toml |  2 +-
 ...curity_file_access_via_common_utility.toml |  2 +-
 ...very_sudo_allowed_command_enumeration.toml |  4 +-
 .../discovery_suid_sguid_enumeration.toml     |  6 +--
 ...overy_suspicious_memory_grep_activity.toml |  2 +-
 ...ry_suspicious_which_command_execution.toml |  6 +--
 ...overy_unusual_user_enumeration_via_id.toml |  6 +--
 ...covery_virtual_machine_fingerprinting.toml |  2 +-
 .../discovery_yum_dnf_plugin_detection.toml   |  2 +-
 ...ion_curl_cve_2023_38545_heap_overflow.toml |  6 +--
 ...nnection_from_entrypoint_in_container.toml |  2 +-
 ...n_file_execution_followed_by_deletion.toml | 12 +++---
 .../execution_interpreter_tty_upgrade.toml    |  2 +-
 .../execution_nc_listener_via_rlwrap.toml     |  4 +-
 ...ion_netcon_from_rwx_mem_region_binary.toml |  2 +-
 ...cution_network_event_post_compilation.toml |  4 +-
 rules/linux/execution_perl_tty_shell.toml     |  2 +-
 ...xecution_potential_hack_tool_executed.toml |  4 +-
 ..._overly_permissive_container_creation.toml |  2 +-
 ...ss_started_in_shared_memory_directory.toml |  4 +-
 rules/linux/execution_python_tty_shell.toml   |  2 +-
 .../execution_python_webserver_spawned.toml   |  2 +-
 ..._remote_code_execution_via_postgresql.toml |  4 +-
 ...cution_shell_openssl_client_or_server.toml |  2 +-
 ...xecution_shell_via_background_process.toml |  6 +--
 ...ion_shell_via_child_tcp_utility_linux.toml |  2 +-
 ...ecution_shell_via_java_revshell_linux.toml |  8 ++--
 ...on_shell_via_lolbin_interpreter_linux.toml | 10 ++---
 ...execution_shell_via_meterpreter_linux.toml |  2 +-
 ...execution_shell_via_suspicious_binary.toml |  6 +--
 ...ution_shell_via_tcp_cli_utility_linux.toml |  2 +-
 ...ution_shell_via_udp_cli_utility_linux.toml |  2 +-
 ...traction_or_decrompression_via_funzip.toml |  4 +-
 ...us_executable_running_system_commands.toml |  2 +-
 ...icious_mining_process_creation_events.toml |  4 +-
 rules/linux/execution_tc_bpf_filter.toml      |  2 +-
 .../execution_unix_socket_communication.toml  |  6 +--
 ...nknown_rwx_mem_region_binary_executed.toml |  2 +-
 ...ntial_data_splitting_for_exfiltration.toml |  2 +-
 .../impact_data_encrypted_via_openssl.toml    |  4 +-
 rules/linux/impact_esxi_process_kill.toml     |  2 +-
 .../impact_memory_swap_modification.toml      |  2 +-
 ...ential_linux_ransomware_note_detected.toml |  6 +--
 ...lateral_movement_ssh_it_worm_download.toml |  2 +-
 ...ment_telnet_network_activity_external.toml |  2 +-
 ...ment_telnet_network_activity_internal.toml |  2 +-
 ...istence_apt_package_manager_execution.toml |  2 +-
 ...nce_apt_package_manager_file_creation.toml |  4 +-
 ...ersistence_apt_package_manager_netcon.toml |  2 +-
 rules/linux/persistence_at_job_creation.toml  |  4 +-
 ..._package_manager_plugin_file_creation.toml |  4 +-
 ...kage_installation_from_unusual_parent.toml |  2 +-
 .../persistence_dpkg_unusual_execution.toml   |  2 +-
 .../linux/persistence_git_hook_execution.toml |  2 +-
 .../persistence_git_hook_file_creation.toml   |  4 +-
 rules/linux/persistence_git_hook_netcon.toml  |  2 +-
 ...ersistence_git_hook_process_execution.toml |  6 +--
 .../linux/persistence_kernel_driver_load.toml |  6 +--
 ...stence_kernel_driver_load_by_non_root.toml |  2 +-
 ...rsistence_kernel_object_file_creation.toml |  2 +-
 ...tence_lkm_configuration_file_creation.toml |  4 +-
 ...ggable_authentication_module_creation.toml | 10 ++---
 ...cation_module_creation_in_unusual_dir.toml |  2 +-
 ...authentication_module_source_download.toml |  2 +-
 ...persistence_script_executable_bit_set.toml |  4 +-
 ...nce_process_capability_set_via_setcap.toml |  4 +-
 ...persistence_rc_local_error_via_syslog.toml |  2 +-
 ...ence_rc_local_service_already_running.toml |  4 +-
 ...kage_installation_from_unusual_parent.toml |  2 +-
 .../persistence_shadow_file_modification.toml |  2 +-
 ...ence_shell_configuration_modification.toml |  4 +-
 ...simple_web_server_connection_accepted.toml |  2 +-
 ...ersistence_simple_web_server_creation.toml |  4 +-
 .../linux/persistence_ssh_key_generation.toml |  2 +-
 rules/linux/persistence_ssh_netcon.toml       |  2 +-
 ...stence_ssh_via_backdoored_system_user.toml |  2 +-
 ...suspicious_file_opened_through_editor.toml |  4 +-
 ...e_suspicious_ssh_execution_xzbackdoor.toml |  4 +-
 ...ersistence_systemd_generator_creation.toml |  2 +-
 rules/linux/persistence_systemd_netcon.toml   |  2 +-
 ...ersistence_tainted_kernel_module_load.toml |  4 +-
 ...ainted_kernel_module_out_of_tree_load.toml |  4 +-
 .../linux/persistence_udev_rule_creation.toml |  6 +--
 .../persistence_unusual_pam_grantor.toml      |  2 +-
 ...ersistence_unusual_sshd_child_process.toml |  2 +-
 ...ser_or_group_creation_or_modification.toml |  4 +-
 .../persistence_xdg_autostart_netcon.toml     |  2 +-
 ..._package_manager_plugin_file_creation.toml |  4 +-
 ...on_chown_chmod_unauthorized_file_read.toml |  2 +-
 ...ation_container_util_misconfiguration.toml |  4 +-
 .../privilege_escalation_dac_permissions.toml |  2 +-
 ..._escalation_docker_escape_via_nsenter.toml |  2 +-
 ..._docker_mount_chroot_container_escape.toml |  2 +-
 ...calation_enlightenment_window_manager.toml |  2 +-
 ...e_escalation_gdb_sys_ptrace_elevation.toml |  4 +-
 ...lege_escalation_gdb_sys_ptrace_netcon.toml |  2 +-
 ...lege_escalation_kworker_uid_elevation.toml |  2 +-
 ...lation_ld_preload_shared_object_modif.toml |  4 +-
 ...lation_linux_suspicious_symbolic_link.toml | 22 +++++------
 ...lege_escalation_linux_uid_int_max_bug.toml |  2 +-
 ...n_load_and_unload_of_kernel_via_kexec.toml |  2 +-
 ...alation_looney_tunables_cve_2023_4911.toml |  4 +-
 ...ege_escalation_netcon_via_sudo_binary.toml |  4 +-
 ...ge_escalation_overlayfs_local_privesc.toml |  6 +--
 ...vilege_escalation_pkexec_envar_hijack.toml |  2 +-
 ...ation_potential_bufferoverflow_attack.toml |  4 +-
 ...tion_potential_suid_sgid_exploitation.toml |  6 +--
 ...lation_potential_wildcard_shell_spawn.toml |  6 +--
 ...ge_escalation_sda_disk_mount_non_root.toml |  6 +--
 ...privilege_escalation_shadow_file_read.toml |  2 +-
 ...vilege_escalation_sudo_cve_2019_14287.toml |  2 +-
 .../privilege_escalation_sudo_hijacking.toml  |  2 +-
 ...tion_sudo_token_via_process_injection.toml |  6 +--
 ...uspicious_cap_setuid_python_execution.toml |  6 +--
 ...ion_suspicious_chown_fowner_elevation.toml |  2 +-
 ...calation_suspicious_passwd_file_write.toml |  2 +-
 ...alation_suspicious_uid_guid_elevation.toml |  6 +--
 ...scalation_uid_change_post_compilation.toml | 10 ++---
 ...uid_elevation_from_unknown_executable.toml |  2 +-
 ...lation_unshare_namespace_manipulation.toml |  2 +-
 ...ege_escalation_writable_docker_socket.toml |  8 ++--
 ...edential_access_credentials_keychains.toml |  2 +-
 ...dential_access_dumping_hashes_bi_cmds.toml |  2 +-
 ...tial_access_dumping_keychain_security.toml |  2 +-
 .../credential_access_kerberosdump_kcc.toml   |  2 +-
 ...s_keychain_pwd_retrieval_security_cmd.toml |  2 +-
 ...ential_access_mitm_localhost_webproxy.toml |  2 +-
 ...access_potential_macos_ssh_bruteforce.toml |  2 +-
 ...al_access_promt_for_pwd_via_osascript.toml |  4 +-
 ...ous_web_browser_sensitive_file_access.toml | 16 ++++----
 .../credential_access_systemkey_dumping.toml  |  2 +-
 ...vasion_apple_softupdates_modification.toml |  2 +-
 ...evasion_attempt_del_quarantine_attrib.toml |  6 +--
 ...evasion_attempt_to_disable_gatekeeper.toml |  2 +-
 ...ense_evasion_install_root_certificate.toml |  2 +-
 ..._evasion_modify_environment_launchctl.toml | 28 +++++++-------
 ...cy_controls_tcc_database_modification.toml |  2 +-
 ...tion_privacy_pref_sshd_fulldiskaccess.toml |  2 +-
 .../defense_evasion_safari_config_change.toml |  2 +-
 ...dboxed_office_app_suspicious_zip_file.toml |  2 +-
 ...vasion_tcc_bypass_mounted_apfs_access.toml |  2 +-
 ..._evasion_unload_endpointsecurity_kext.toml |  2 +-
 ...covery_users_domain_built_in_commands.toml |  2 +-
 ...vasion_electron_app_childproc_node_js.toml |  2 +-
 ...l_access_suspicious_browser_childproc.toml |  2 +-
 ...staller_package_spawned_network_event.toml |  2 +-
 ...cution_script_via_automator_workflows.toml |  2 +-
 ...ing_osascript_exec_followed_by_netcon.toml |  2 +-
 ...n_shell_execution_via_apple_scripting.toml |  2 +-
 ...uspicious_mac_ms_office_child_process.toml |  2 +-
 ...ential_access_kerberos_bifrostconsole.toml |  2 +-
 .../lateral_movement_mounting_smb_share.toml  |  2 +-
 ...ral_movement_remote_ssh_login_enabled.toml |  2 +-
 ...teral_movement_vpn_connection_attempt.toml |  2 +-
 ...stence_account_creation_hide_at_logon.toml |  2 +-
 ...ce_creation_change_launch_agents_file.toml |  2 +-
 ..._creation_hidden_login_item_osascript.toml |  2 +-
 ...creation_modif_launch_deamon_sequence.toml |  2 +-
 ..._access_authorization_plugin_creation.toml |  2 +-
 rules/macos/persistence_crontab_creation.toml |  2 +-
 ...launch_agent_deamon_logonitem_process.toml |  2 +-
 ...rectory_services_plugins_modification.toml |  2 +-
 ...e_docker_shortcuts_plist_modification.toml |  2 +-
 ...persistence_emond_rules_file_creation.toml |  2 +-
 ...istence_emond_rules_process_execution.toml |  2 +-
 .../persistence_enable_root_account.toml      |  2 +-
 ...n_hidden_launch_agent_deamon_creation.toml |  2 +-
 ...sistence_finder_sync_plugin_pluginkit.toml |  2 +-
 ...istence_folder_action_scripts_runtime.toml |  2 +-
 ...rsistence_login_logout_hooks_defaults.toml |  2 +-
 ...fication_sublime_app_plugin_or_script.toml |  2 +-
 ...ersistence_periodic_tasks_file_mdofiy.toml |  2 +-
 ...ence_suspicious_calendar_modification.toml |  2 +-
 ...tence_via_atom_init_file_modification.toml |  2 +-
 ...calation_applescript_with_admin_privs.toml |  2 +-
 ...calation_explicit_creds_via_scripting.toml |  2 +-
 ...alation_exploit_adobe_acrobat_updater.toml |  2 +-
 ..._escalation_local_user_added_to_admin.toml |  2 +-
 ...ilege_escalation_root_crontab_filemod.toml |  2 +-
 ...d_control_ml_packetbeat_dns_tunneling.toml |  2 +-
 ...ntrol_ml_packetbeat_rare_dns_question.toml |  2 +-
 ...d_and_control_ml_packetbeat_rare_urls.toml |  2 +-
 ...control_ml_packetbeat_rare_user_agent.toml |  2 +-
 ..._access_ml_auth_spike_in_logon_events.toml |  2 +-
 ...s_ml_linux_anomalous_metadata_process.toml |  2 +-
 ...cess_ml_linux_anomalous_metadata_user.toml |  2 +-
 ...l_access_ml_suspicious_login_activity.toml |  2 +-
 ...ml_windows_anomalous_metadata_process.toml |  2 +-
 ...ss_ml_windows_anomalous_metadata_user.toml |  2 +-
 ...ml_linux_system_information_discovery.toml |  2 +-
 ...ystem_network_configuration_discovery.toml |  2 +-
 ...x_system_network_connection_discovery.toml |  2 +-
 ...ery_ml_linux_system_process_discovery.toml |  2 +-
 ...covery_ml_linux_system_user_discovery.toml |  2 +-
 ...execution_ml_windows_anomalous_script.toml |  2 +-
 ...ess_ml_auth_rare_source_ip_for_a_user.toml |  2 +-
 rules/ml/ml_high_count_network_denies.toml    |  2 +-
 rules/ml/ml_high_count_network_events.toml    |  2 +-
 ...linux_anomalous_network_port_activity.toml |  2 +-
 .../ml/ml_packetbeat_rare_server_domain.toml  |  2 +-
 rules/ml/ml_rare_destination_country.toml     |  2 +-
 ...ce_ml_windows_anomalous_path_activity.toml |  2 +-
 ...sistence_ml_windows_anomalous_service.toml |  2 +-
 ...tion_ml_linux_anomalous_sudo_activity.toml |  2 +-
 ...tion_ml_windows_rare_user_runas_event.toml |  2 +-
 ..._ml_linux_anomalous_compiler_activity.toml |  2 +-
 ...cepted_default_telnet_port_connection.toml |  2 +-
 ...mand_and_control_cobalt_strike_beacon.toml |  2 +-
 ...cobalt_strike_default_teamserver_cert.toml |  2 +-
 ...download_rar_powershell_from_internet.toml |  2 +-
 .../command_and_control_halfbaked_beacon.toml |  2 +-
 ...d_control_nat_traversal_port_activity.toml |  2 +-
 .../command_and_control_port_26_activity.toml |  2 +-
 ...te_desktop_protocol_from_the_internet.toml |  2 +-
 ...l_network_computing_from_the_internet.toml |  2 +-
 ...ual_network_computing_to_the_internet.toml |  2 +-
 ...very_potential_network_sweep_detected.toml |  2 +-
 ...iscovery_potential_port_scan_detected.toml |  2 +-
 ...very_potential_syn_port_scan_detected.toml |  2 +-
 ...mote_procedure_call_from_the_internet.toml |  2 +-
 ...remote_procedure_call_to_the_internet.toml |  2 +-
 ...file_sharing_activity_to_the_internet.toml |  2 +-
 ...al_access_unsecure_elasticsearch_node.toml |  2 +-
 ..._access_endgame_cred_dumping_detected.toml |  2 +-
 ...access_endgame_cred_dumping_prevented.toml |  2 +-
 .../endgame_adversary_behavior_detected.toml  |  2 +-
 .../promotions/endgame_malware_detected.toml  |  2 +-
 .../promotions/endgame_malware_prevented.toml |  2 +-
 .../endgame_ransomware_detected.toml          |  2 +-
 .../endgame_ransomware_prevented.toml         |  2 +-
 .../execution_endgame_exploit_detected.toml   |  2 +-
 .../execution_endgame_exploit_prevented.toml  |  2 +-
 rules/promotions/external_alerts.toml         |  2 +-
 ...on_endgame_cred_manipulation_detected.toml |  2 +-
 ...n_endgame_cred_manipulation_prevented.toml |  2 +-
 ...ion_endgame_permission_theft_detected.toml |  2 +-
 ...on_endgame_permission_theft_prevented.toml |  2 +-
 ...on_endgame_process_injection_detected.toml |  2 +-
 ...n_endgame_process_injection_prevented.toml |  2 +-
 ...lection_email_outlook_mailbox_via_com.toml |  4 +-
 .../collection_posh_webcam_video_capture.toml |  2 +-
 ...control_encrypted_channel_freesslcert.toml |  2 +-
 .../command_and_control_iexplore_via_com.toml |  2 +-
 ...command_and_control_outlook_home_page.toml |  2 +-
 ...d_and_control_screenconnect_childproc.toml |  2 +-
 .../command_and_control_tunnel_vscode.toml    |  4 +-
 .../credential_access_adidns_wildcard.toml    |  2 +-
 .../credential_access_adidns_wpad_record.toml |  2 +-
 ...redential_access_dcsync_user_backdoor.toml |  2 +-
 .../credential_access_dnsnode_creation.toml   |  2 +-
 ...redential_access_dollar_account_relay.toml |  4 +-
 .../credential_access_generic_localdumps.toml |  2 +-
 ..._access_iis_connectionstrings_dumping.toml |  2 +-
 ...ccess_imageload_azureadconnectauthsvc.toml | 14 +++----
 .../windows/credential_access_kirbi_file.toml |  2 +-
 .../credential_access_ldap_attributes.toml    |  2 +-
 ...l_access_lsass_handle_via_malseclogon.toml |  2 +-
 ...edential_access_lsass_loaded_susp_dll.toml |  2 +-
 .../credential_access_posh_relay_tools.toml   |  2 +-
 .../credential_access_posh_veeam_sql.toml     |  2 +-
 ..._potential_lsa_memdump_via_mirrordump.toml |  2 +-
 ...cess_relay_ntlm_auth_via_http_spoolss.toml |  2 +-
 ...ntial_access_saved_creds_vault_winlog.toml |  6 +--
 ...redential_access_saved_creds_vaultcmd.toml |  2 +-
 ...ccess_suspicious_lsass_access_generic.toml | 12 +++---
 ...ccess_suspicious_lsass_access_memdump.toml |  2 +-
 ..._suspicious_lsass_access_via_snapshot.toml |  2 +-
 ...ial_access_veeam_backup_dll_imageload.toml |  2 +-
 .../credential_access_veeam_commands.toml     |  2 +-
 ...ess_via_snapshot_lsass_clone_creation.toml |  2 +-
 .../credential_access_wbadmin_ntds.toml       |  4 +-
 .../defense_evasion_cve_2020_0601.toml        |  2 +-
 .../windows/defense_evasion_disable_nla.toml  |  2 +-
 ...efense_evasion_dns_over_https_enabled.toml |  2 +-
 ...vasion_dotnet_compiler_parent_process.toml |  2 +-
 ...ecution_control_panel_suspicious_args.toml |  4 +-
 ...n_execution_msbuild_started_by_script.toml |  4 +-
 ...ion_msbuild_started_by_system_process.toml |  2 +-
 ...cution_msbuild_started_unusal_process.toml |  2 +-
 ...execution_suspicious_explorer_winword.toml |  2 +-
 ...sion_execution_windefend_unusual_path.toml |  2 +-
 ..._evasion_file_creation_mult_extension.toml |  2 +-
 ...sion_hide_encoded_executable_registry.toml |  2 +-
 .../defense_evasion_injection_msbuild.toml    |  2 +-
 .../defense_evasion_installutil_beacon.toml   |  2 +-
 ...efense_evasion_lolbas_win_cdb_utility.toml |  2 +-
 ...querading_as_elastic_endpoint_process.toml |  2 +-
 ..._masquerading_business_apps_installer.toml |  2 +-
 ...asion_masquerading_communication_apps.toml |  2 +-
 ...erading_suspicious_werfault_childproc.toml |  2 +-
 ...vasion_masquerading_trusted_directory.toml |  2 +-
 .../windows/defense_evasion_mshta_beacon.toml |  2 +-
 ...nse_evasion_msiexec_child_proc_netcon.toml |  2 +-
 .../defense_evasion_msxsl_network.toml        |  2 +-
 ...e_evasion_parent_process_pid_spoofing.toml | 38 +++++++++----------
 ...persistence_account_tokenfilterpolicy.toml |  2 +-
 .../defense_evasion_posh_obfuscation.toml     |  2 +-
 ...ense_evasion_proxy_execution_via_msdt.toml |  2 +-
 ...eg_disable_enableglobalqueryblocklist.toml |  2 +-
 ...defense_evasion_root_dir_ads_creation.toml |  6 +--
 rules/windows/defense_evasion_sc_sdset.toml   |  2 +-
 ...fense_evasion_sccm_scnotification_dll.toml |  2 +-
 ...ion_scheduledjobs_at_protocol_enabled.toml |  2 +-
 .../defense_evasion_script_via_html_app.toml  |  2 +-
 .../defense_evasion_sip_provider_mod.toml     |  2 +-
 ...ackdoor_service_disabled_via_registry.toml |  2 +-
 ...picious_execution_from_mounted_device.toml |  2 +-
 ...n_suspicious_managedcode_host_process.toml |  2 +-
 ...efense_evasion_suspicious_scrobj_load.toml | 12 +++---
 ...defense_evasion_suspicious_wmi_script.toml |  2 +-
 .../defense_evasion_timestomp_sysmon.toml     | 26 ++++++-------
 ...sion_unsigned_dll_loaded_from_suspdir.toml | 18 ++++-----
 .../defense_evasion_unusual_dir_ads.toml      |  2 +-
 ...nusual_network_connection_via_dllhost.toml |  2 +-
 ...asion_unusual_system_vp_child_program.toml |  2 +-
 ...se_evasion_windows_filtering_platform.toml | 10 ++---
 .../defense_evasion_wsl_bash_exec.toml        | 12 +++---
 .../defense_evasion_wsl_child_process.toml    |  2 +-
 .../defense_evasion_wsl_filesystem.toml       |  4 +-
 .../defense_evasion_wsl_kalilinux.toml        |  8 ++--
 ...discovery_active_directory_webservice.toml | 20 +++++-----
 .../discovery_high_number_ad_properties.toml  |  2 +-
 ...unusual_discovery_signal_proc_cmdline.toml |  2 +-
 ...sual_discovery_signal_proc_executable.toml |  2 +-
 ...arwinds_backdoor_child_cmd_powershell.toml |  2 +-
 ...inds_backdoor_unusual_child_processes.toml |  2 +-
 .../windows/execution_com_object_xwizard.toml |  2 +-
 ...mand_shell_started_by_unusual_process.toml |  2 +-
 .../execution_command_shell_via_rundll32.toml |  2 +-
 ...tion_delayed_via_ping_lolbas_unsigned.toml |  4 +-
 .../execution_downloaded_shortcut_files.toml  |  2 +-
 .../execution_downloaded_url_file.toml        |  2 +-
 .../execution_enumeration_via_wmiprvse.toml   |  8 ++--
 ...cution_initial_access_foxmail_exploit.toml | 16 ++++----
 ...cution_initial_access_wps_dll_exploit.toml | 24 ++++++------
 rules/windows/execution_mofcomp.toml          |  2 +-
 .../execution_posh_hacktool_authors.toml      |  2 +-
 ...on_powershell_susp_args_via_winscript.toml |  2 +-
 ...tion_scheduled_task_powershell_source.toml |  2 +-
 .../windows/execution_suspicious_cmd_wmi.toml |  2 +-
 ...n_suspicious_image_load_wmi_ms_office.toml |  2 +-
 ...ion_via_mmc_console_file_unusual_path.toml |  2 +-
 ...execution_windows_cmd_shell_susp_args.toml |  6 +--
 ...xecution_windows_powershell_susp_args.toml |  6 +--
 .../exfiltration_smb_rare_destination.toml    |  6 +--
 ..._evasion_suspicious_htm_file_creation.toml |  2 +-
 ...itial_access_execution_from_inetcache.toml |  4 +-
 ...access_execution_from_removable_media.toml |  8 ++--
 ...l_access_execution_remote_via_msiexec.toml |  2 +-
 ...al_access_execution_via_office_addins.toml | 26 ++++++-------
 ...cess_exfiltration_first_time_seen_usb.toml |  2 +-
 ...ial_access_exploit_jetbrains_teamcity.toml |  2 +-
 ...itial_access_rdp_file_mail_attachment.toml | 12 +++---
 ...ccess_scripts_process_started_via_wmi.toml |  4 +-
 ...access_suspicious_ms_exchange_process.toml |  2 +-
 ...ious_ms_exchange_worker_child_process.toml |  2 +-
 ...explorer_suspicious_child_parent_args.toml |  2 +-
 ..._access_webshell_screenconnect_server.toml |  2 +-
 ...l_access_xsl_script_execution_via_com.toml |  4 +-
 .../lateral_movement_alternate_creds_pth.toml |  8 ++--
 .../windows/lateral_movement_cmd_service.toml |  2 +-
 rules/windows/lateral_movement_dcom_hta.toml  |  2 +-
 .../windows/lateral_movement_dcom_mmc20.toml  |  2 +-
 ...t_dcom_shellwindow_shellbrowserwindow.toml |  2 +-
 ...n_lanman_nullsessionpipe_modification.toml |  2 +-
 ...ateral_movement_evasion_rdp_shadowing.toml |  2 +-
 ..._movement_execution_from_tsclient_mup.toml |  2 +-
 ...vement_incoming_winrm_shell_execution.toml |  4 +-
 .../lateral_movement_incoming_wmi.toml        |  2 +-
 ...ment_mount_hidden_or_webdav_share_net.toml |  2 +-
 ...l_movement_powershell_remoting_target.toml |  4 +-
 .../lateral_movement_rdp_sharprdp_target.toml |  2 +-
 ...ovement_remote_file_copy_hidden_share.toml |  2 +-
 ...ement_remote_service_installed_winlog.toml |  2 +-
 ...ement_suspicious_rdp_client_imageload.toml |  2 +-
 ...l_movement_via_startup_folder_rdp_smb.toml |  2 +-
 .../lateral_movement_via_wsus_update.toml     |  2 +-
 .../windows/persistence_ad_adminsdholder.toml |  2 +-
 .../windows/persistence_app_compat_shim.toml  | 12 +++---
 .../persistence_appcertdlls_registry.toml     |  2 +-
 ...persistence_browser_extension_install.toml |  6 +--
 ...tence_evasion_registry_ifeo_injection.toml |  2 +-
 ...sistence_group_modification_by_system.toml |  2 +-
 ...sistence_local_scheduled_job_creation.toml |  2 +-
 ...istence_local_scheduled_task_creation.toml |  2 +-
 .../persistence_ms_office_addins_file.toml    |  2 +-
 .../persistence_ms_outlook_vba_template.toml  |  2 +-
 ...istence_msds_alloweddelegateto_krbtgt.toml |  2 +-
 ...ersistence_msi_installer_task_startup.toml |  4 +-
 ...persistence_msoffice_startup_registry.toml |  2 +-
 .../windows/persistence_netsh_helper_dll.toml |  2 +-
 ...ll_exch_mailbox_activesync_add_device.toml |  2 +-
 .../persistence_registry_uncommon.toml        |  4 +-
 .../persistence_remote_password_reset.toml    |  2 +-
 ...ce_runtime_run_key_startup_susp_procs.toml |  2 +-
 ...stence_scheduled_task_creation_winlog.toml |  2 +-
 .../persistence_scheduled_task_updated.toml   | 22 +++++------
 .../persistence_service_dll_unsigned.toml     | 38 +++++++++----------
 .../persistence_services_registry.toml        |  2 +-
 ...nce_suspicious_scheduled_task_runtime.toml |  2 +-
 ...e_suspicious_service_created_registry.toml |  2 +-
 ...istence_sysmon_wmi_event_subscription.toml |  8 ++--
 .../persistence_temp_scheduled_task.toml      |  2 +-
 ...ence_user_account_creation_event_logs.toml |  2 +-
 .../persistence_via_application_shimming.toml |  2 +-
 ...rsistence_via_bits_job_notify_command.toml |  2 +-
 ...sistence_via_hidden_run_key_valuename.toml |  2 +-
 ...sa_security_support_provider_registry.toml |  2 +-
 ...emetrycontroller_scheduledtask_hijack.toml |  2 +-
 ...nt_instrumentation_event_subscription.toml |  2 +-
 .../persistence_werfault_reflectdebugger.toml |  2 +-
 ...tion_create_process_as_different_user.toml |  2 +-
 ...tion_create_process_with_token_unpriv.toml | 12 +++---
 ...privilege_escalation_credroaming_ldap.toml |  2 +-
 ...e_escalation_dns_serverlevelplugindll.toml |  4 +-
 ...lege_escalation_expired_driver_loaded.toml |  2 +-
 ...lege_escalation_exploit_cve_202238028.toml |  2 +-
 ...calation_gpo_schtask_service_creation.toml |  6 +--
 ...scalation_krbrelayup_service_creation.toml |  2 +-
 ...privilege_escalation_lsa_auth_package.toml |  2 +-
 ...privilege_escalation_make_token_local.toml | 26 ++++++-------
 ...escalation_msi_repair_via_mshelp_link.toml |  2 +-
 ...scalation_newcreds_logon_rare_process.toml |  2 +-
 ...ion_port_monitor_print_pocessor_abuse.toml |  2 +-
 ...ation_printspooler_registry_copyfiles.toml |  2 +-
 ..._printspooler_service_suspicious_file.toml |  2 +-
 ...printspooler_suspicious_file_deletion.toml |  2 +-
 ..._escalation_reg_service_imagepath_mod.toml |  4 +-
 ...calation_rogue_windir_environment_var.toml |  2 +-
 ...lation_samaccountname_spoofing_attack.toml |  2 +-
 ...alation_suspicious_dnshostname_update.toml |  2 +-
 ...lation_tokenmanip_sedebugpriv_enabled.toml |  2 +-
 ...lege_escalation_uac_bypass_com_clipup.toml |  2 +-
 ...ge_escalation_uac_bypass_com_ieinstal.toml |  2 +-
 ...n_uac_bypass_com_interface_icmluautil.toml |  2 +-
 ...alation_uac_bypass_diskcleanup_hijack.toml |  4 +-
 ...escalation_uac_bypass_dll_sideloading.toml |  2 +-
 ...lege_escalation_unquoted_service_path.toml |  6 +--
 ...ion_unusual_printspooler_childprocess.toml |  4 +-
 ...n_unusual_svchost_childproc_childless.toml |  2 +-
 ...rivilege_escalation_via_ppid_spoofing.toml | 14 +++----
 ...ilege_escalation_via_rogue_named_pipe.toml |  2 +-
 .../privilege_escalation_via_token_theft.toml | 28 +++++++-------
 ...on_windows_service_via_unusual_client.toml |  2 +-
 ...rivilege_escalation_wpad_exploitation.toml |  2 +-
 ...collection_archive_data_zip_imageload.toml |  4 +-
 ...ction_common_compressed_archived_file.toml |  2 +-
 ...tion_files_staged_in_recycle_bin_root.toml |  2 +-
 .../collection_outlook_email_archive.toml     |  2 +-
 .../collection_posh_compression.toml          |  4 +-
 ...ommand_and_control_bitsadmin_activity.toml |  2 +-
 ...ntial_access_iis_apppoolsa_pwd_appcmd.toml |  2 +-
 .../credential_access_mdmp_file_creation.toml |  2 +-
 ...al_access_mdmp_file_unusual_extension.toml |  4 +-
 ...dential_access_win_private_key_access.toml |  2 +-
 ...ense_evasion_aws_rds_snapshot_created.toml |  6 +--
 ...ense_evasion_cmd_copy_binary_contents.toml |  2 +-
 .../defense_evasion_cmstp_execution.toml      |  2 +-
 ...rading_unusual_archive_file_extension.toml |  2 +-
 ...ication_apps_suspicious_child_process.toml | 20 +++++-----
 .../defense_evasion_dll_hijack.toml           |  2 +-
 ...evasion_dotnet_clickonce_dfsvc_netcon.toml |  2 +-
 ...fense_evasion_download_susp_extension.toml |  8 ++--
 ...cution_via_visualstudio_prebuildevent.toml |  4 +-
 ..._evasion_file_permission_modification.toml |  2 +-
 .../defense_evasion_generic_deletion.toml     |  8 ++--
 ...indirect_command_exec_pcalua_forfiles.toml |  2 +-
 ...fense_evasion_injection_from_msoffice.toml |  2 +-
 ..._evasion_installutil_command_activity.toml |  2 +-
 ...se_evasion_invalid_codesign_imageload.toml |  2 +-
 ...defense_evasion_masquerading_browsers.toml |  2 +-
 ...squerading_unusual_exe_file_extension.toml |  2 +-
 .../defense_evasion_masquerading_vlc_dll.toml |  2 +-
 ...ense_evasion_masquerading_windows_dll.toml |  2 +-
 ...ion_masquerading_windows_system32_exe.toml |  4 +-
 ...fense_evasion_msdt_suspicious_diagcab.toml |  2 +-
 ...on_msiexec_installsource_archive_file.toml |  2 +-
 ...fense_evasion_posh_defender_tampering.toml |  2 +-
 ..._evasion_powershell_clear_logs_script.toml |  2 +-
 ...vasion_processes_with_trailing_spaces.toml |  2 +-
 ...nse_evasion_service_disabled_registry.toml |  4 +-
 ...defense_evasion_service_path_registry.toml |  2 +-
 .../defense_evasion_services_exe_path.toml    |  2 +-
 ..._evasion_suspicious_msiexec_execution.toml |  2 +-
 .../defense_evasion_unsigned_bits_client.toml |  2 +-
 ...nse_evasion_unusual_process_extension.toml |  6 +--
 ...nse_evasion_unusual_process_path_wbem.toml |  2 +-
 .../defense_evasion_write_dac_access.toml     |  2 +-
 .../discovery_capnetraw_capability.toml       |  2 +-
 .../discovery_generic_account_groups.toml     |  2 +-
 .../discovery_generic_process_discovery.toml  |  2 +-
 .../discovery_generic_registry_query.toml     |  2 +-
 .../discovery_hosts_file_access.toml          |  2 +-
 .../discovery_internet_capabilities.toml      |  4 +-
 ...ry_kernel_module_enumeration_via_proc.toml |  2 +-
 .../discovery_linux_modprobe_enumeration.toml |  2 +-
 .../discovery_linux_sysctl_enumeration.toml   |  2 +-
 ...ry_linux_system_information_discovery.toml |  2 +-
 ...ery_linux_system_owner_user_discovery.toml |  4 +-
 .../discovery_net_share_discovery_winlog.toml | 12 +++---
 ..._accounts_or_groups_via_builtin_tools.toml |  6 +--
 .../discovery_of_domain_groups.toml           |  2 +-
 .../discovery_posh_generic.toml               |  4 +-
 .../discovery_posh_password_policy.toml       |  4 +-
 ...ery_potential_memory_seeking_activity.toml |  2 +-
 ...y_process_discovery_via_builtin_tools.toml |  4 +-
 .../discovery_signal_unusual_user_host.toml   |  2 +-
 ...discovery_suspicious_proc_enumeration.toml |  4 +-
 .../discovery_system_network_connections.toml |  2 +-
 .../discovery_system_service_discovery.toml   |  4 +-
 .../discovery_system_time_discovery.toml      |  8 ++--
 ...ry_userdata_request_from_ec2_instance.toml |  2 +-
 .../discovery_win_network_connections.toml    |  2 +-
 ..._windows_system_information_discovery.toml |  6 +--
 ...execution_aws_lambda_function_updated.toml |  2 +-
 ...ution_github_new_event_action_for_pat.toml |  4 +-
 ...n_github_new_repo_interaction_for_pat.toml |  4 +-
 ..._github_new_repo_interaction_for_user.toml |  4 +-
 .../execution_github_repo_created.toml        |  2 +-
 ...n_github_repo_interaction_from_new_ip.toml |  4 +-
 .../execution_linux_segfault.toml             |  2 +-
 ...ution_settingcontent_ms_file_creation.toml |  2 +-
 ...execution_unsigned_service_executable.toml |  6 +--
 .../execution_wmi_wbemtest.toml               |  2 +-
 ...thub_member_removed_from_organization.toml |  2 +-
 .../impact_github_pat_access_revoked.toml     |  2 +-
 ...github_user_blocked_from_organization.toml |  2 +-
 .../initial_access_cross_site_scripting.toml  |  2 +-
 ..._access_github_new_ip_address_for_pat.toml |  2 +-
 ...access_github_new_ip_address_for_user.toml |  2 +-
 ..._access_github_new_user_agent_for_pat.toml |  2 +-
 ...access_github_new_user_agent_for_user.toml |  2 +-
 rules_building_block/lateral_movement_at.toml |  2 +-
 .../lateral_movement_posh_winrm_activity.toml |  2 +-
 ...ral_movement_rdp_conn_unusual_process.toml |  2 +-
 ...movement_unusual_process_sql_accounts.toml |  2 +-
 .../lateral_movement_wmic_remote.toml         |  2 +-
 ...e_aws_iam_login_profile_added_to_user.toml |  2 +-
 ...nce_cap_sys_admin_added_to_new_binary.toml |  2 +-
 ...persistence_creation_of_kernel_module.toml |  2 +-
 .../persistence_github_new_pat_for_user.toml  |  2 +-
 ...github_new_user_added_to_organization.toml |  2 +-
 ...e_iam_instance_request_to_iam_service.toml |  2 +-
 .../persistence_startup_folder_lnk.toml       |  2 +-
 .../persistence_transport_agent_exchange.toml |  2 +-
 .../privilege_escalation_trap_execution.toml  |  2 +-
 861 files changed, 1377 insertions(+), 1377 deletions(-)

diff --git a/rules/apm/apm_403_response_to_a_post.toml b/rules/apm/apm_403_response_to_a_post.toml
index 72a90b2e67b..c21235b9c67 100644
--- a/rules/apm/apm_403_response_to_a_post.toml
+++ b/rules/apm/apm_403_response_to_a_post.toml
@@ -35,7 +35,7 @@ http.response.status_code:403 and http.request.method:post
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Web Application Suspicious Activity: POST Request Declined
 
diff --git a/rules/apm/apm_405_response_method_not_allowed.toml b/rules/apm/apm_405_response_method_not_allowed.toml
index 2a9367dd263..2b0531b4cf5 100644
--- a/rules/apm/apm_405_response_method_not_allowed.toml
+++ b/rules/apm/apm_405_response_method_not_allowed.toml
@@ -35,7 +35,7 @@ http.response.status_code:405
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Web Application Suspicious Activity: Unauthorized Method
 
diff --git a/rules/apm/apm_sqlmap_user_agent.toml b/rules/apm/apm_sqlmap_user_agent.toml
index 570ea7d28b5..d7df695e4b1 100644
--- a/rules/apm/apm_sqlmap_user_agent.toml
+++ b/rules/apm/apm_sqlmap_user_agent.toml
@@ -35,7 +35,7 @@ user_agent.original:"sqlmap/1.3.11#stable (http://sqlmap.org)"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Web Application Suspicious Activity: sqlmap User Agent
 
diff --git a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
index e00be1244c6..91ea2c326c7 100644
--- a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
+++ b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
@@ -39,12 +39,12 @@ query = '''
 process where
 
     /* common browser processes  */
-    event.action in ("exec", "fork", "start") and 
+    event.action in ("exec", "fork", "start") and
 
-    process.name : ("Microsoft Edge", "chrome.exe", "Google Chrome", "google-chrome-stable", 
-                    "google-chrome-beta", "google-chrome", "msedge.exe", "firefox.exe", "brave.exe", 
-                    "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe", "opera.exe", "firefox", 
-                    "powershell.exe", "curl", "curl.exe", "wget", "wget.exe") and 
+    process.name : ("Microsoft Edge", "chrome.exe", "Google Chrome", "google-chrome-stable",
+                    "google-chrome-beta", "google-chrome", "msedge.exe", "firefox.exe", "brave.exe",
+                    "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe", "opera.exe", "firefox",
+                    "powershell.exe", "curl", "curl.exe", "wget", "wget.exe") and
 
     /* Look for Google Drive download URL with AV flag skipping */
     (process.command_line : "*drive.google.com*" and process.command_line : "*export=download*" and process.command_line : "*confirm=no_antivirus*")
@@ -52,7 +52,7 @@ process where
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious File Downloaded from Google Drive
 
diff --git a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
index 639840ec937..32c2e8675cf 100644
--- a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
+++ b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
@@ -44,7 +44,7 @@ sequence by process.entity_id with maxspan=1m
    "run"
    )
   ]
-  [network where process.name:"ssh" and event.action in ("connection_attempted", "connection_accepted") and 
+  [network where process.name:"ssh" and event.action in ("connection_attempted", "connection_accepted") and
    destination.port != 22 and network.transport == "tcp" and not (
      destination.ip == null or destination.ip == "0.0.0.0" or 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",
@@ -59,7 +59,7 @@ sequence by process.entity_id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Non-Standard Port SSH connection
 
diff --git a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
index 3e89eb92165..c5d988e17e5 100644
--- a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
+++ b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
@@ -67,7 +67,7 @@ process where event.type in ("start", "process_started", "info") and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Cookies Theft via Browser Debugging
 
diff --git a/rules/cross-platform/credential_access_forced_authentication_pipes.toml b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
index 261a87ce870..59fa4f114ab 100644
--- a/rules/cross-platform/credential_access_forced_authentication_pipes.toml
+++ b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
@@ -63,7 +63,7 @@ sequence with maxspan=15s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Active Directory Forced Authentication from Linux Host - SMB Named Pipes
 
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
index c7671e0e134..9a3eb7ec064 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
@@ -34,7 +34,7 @@ event.agent_id_status:(agent_id_mismatch or mismatch)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Agent Spoofing - Mismatched Agent ID
 
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
index 309dd1326ac..d2e1562a6df 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
@@ -34,7 +34,7 @@ event.agent_id_status:* and not tags:forwarded
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Agent Spoofing - Multiple Hosts Using Same Agent
 
diff --git a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
index 2c42306a998..4a80ba4d0cb 100644
--- a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
+++ b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
@@ -52,7 +52,7 @@ file where event.type == "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WebServer Access Logs Deleted
 
diff --git a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
index 4f7ff590fac..570e2dea978 100644
--- a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
+++ b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
@@ -57,7 +57,7 @@ process where event.action in ("exec", "exec_event", "executed", "process_starte
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Tampering of Shell Command-Line History
 
diff --git a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
index 9bd55b5a8e5..0a089ceb732 100644
--- a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
+++ b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
@@ -64,7 +64,7 @@ or
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Elastic Agent Service Terminated
 
diff --git a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
index 12f23a5ee47..8529965fcb0 100644
--- a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
+++ b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
@@ -41,7 +41,7 @@ sequence by process.entity_id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 ROT Encoded Python Script Execution
 
diff --git a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
index ba427f0d623..4b6293e130b 100644
--- a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
+++ b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
@@ -55,7 +55,7 @@ process.executable regex~ """/[a-z0-9\s_\-\\./]+\s""" and not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Masquerading Space After Filename
 
diff --git a/rules/cross-platform/defense_evasion_timestomp_touch.toml b/rules/cross-platform/defense_evasion_timestomp_touch.toml
index c38092ddf24..7462af984a2 100644
--- a/rules/cross-platform/defense_evasion_timestomp_touch.toml
+++ b/rules/cross-platform/defense_evasion_timestomp_touch.toml
@@ -49,7 +49,7 @@ process where event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Timestomping using Touch Command
 
diff --git a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
index 1cc57c63f10..8c96dc20d6a 100644
--- a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
+++ b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
@@ -54,7 +54,7 @@ process where event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Virtual Machine Fingerprinting via Grep
 
diff --git a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
index 21b713c7133..025b66c7fa2 100644
--- a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
+++ b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
@@ -89,7 +89,7 @@ and process.args: (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS SSM `SendCommand` with Run Shell Command Parameters
 
diff --git a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
index 984a176abde..d1dc608f1c6 100644
--- a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
+++ b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
@@ -33,7 +33,7 @@ event.category:process and event.type:(process_started or start) and process.nam
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 EggShell Backdoor Execution
 
diff --git a/rules/cross-platform/execution_potential_widespread_malware_infection.toml b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
index 0654843e9bf..ddf387f16bb 100644
--- a/rules/cross-platform/execution_potential_widespread_malware_infection.toml
+++ b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
@@ -41,7 +41,7 @@ from logs-endpoint.alerts-*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Widespread Malware Infection Across Multiple Hosts
 
diff --git a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
index 95e7b4b9534..bf678e7c616 100644
--- a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
+++ b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
@@ -67,7 +67,7 @@ sequence by host.id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential JAVA/JNDI Exploitation Attempt
 
diff --git a/rules/cross-platform/guided_onboarding_sample_rule.toml b/rules/cross-platform/guided_onboarding_sample_rule.toml
index 2006b978127..8f90d9bab3d 100644
--- a/rules/cross-platform/guided_onboarding_sample_rule.toml
+++ b/rules/cross-platform/guided_onboarding_sample_rule.toml
@@ -23,7 +23,7 @@ name = "My First Rule"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 My First Rule
 Elastic Security leverages event data to monitor and alert on potential security incidents. The "My First Rule" is a foundational rule designed for onboarding, focusing on event data without indicating a specific threat. Adversaries might exploit event logging to obscure their tracks or trigger false alerts. This rule helps analysts familiarize themselves with event-based alerts, ensuring they can identify and respond to genuine threats effectively.
diff --git a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
index 19ec10d0a00..3c18c636b4d 100644
--- a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
+++ b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
@@ -37,7 +37,7 @@ event.type:creation and event.module:zoom and event.dataset:zoom.webhook and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Zoom Meeting with no Passcode
 
diff --git a/rules/cross-platform/multiple_alerts_different_tactics_host.toml b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
index d21057298e0..1f4d8c35a5b 100644
--- a/rules/cross-platform/multiple_alerts_different_tactics_host.toml
+++ b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
@@ -34,7 +34,7 @@ signal.rule.name:* and kibana.alert.rule.threat.tactic.id:*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Multiple Alerts in Different ATT&CK Tactics on a Single Host
 
diff --git a/rules/cross-platform/multiple_alerts_involving_user.toml b/rules/cross-platform/multiple_alerts_involving_user.toml
index ae53897aa33..2687c9e2424 100644
--- a/rules/cross-platform/multiple_alerts_involving_user.toml
+++ b/rules/cross-platform/multiple_alerts_involving_user.toml
@@ -36,7 +36,7 @@ signal.rule.name:* and user.name:* and not user.id:("S-1-5-18" or "S-1-5-19" or
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Multiple Alerts Involving a User
 
diff --git a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
index ffb6a09f9be..ed84a0fbe44 100644
--- a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
+++ b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
@@ -71,7 +71,7 @@ event.category:file and event.type:change and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Standard Authentication Module or Configuration
 
diff --git a/rules/cross-platform/persistence_shell_profile_modification.toml b/rules/cross-platform/persistence_shell_profile_modification.toml
index 00a694158ac..00947244294 100644
--- a/rules/cross-platform/persistence_shell_profile_modification.toml
+++ b/rules/cross-platform/persistence_shell_profile_modification.toml
@@ -52,7 +52,7 @@ event.category:file and event.type:change and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Bash Shell Profile Modification
 
diff --git a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
index 2846a2cfd73..93609d2dc44 100644
--- a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
+++ b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
@@ -44,8 +44,8 @@ event.category:file and event.type:(change or creation) and
               /usr/bin/scp or
               /usr/bin/touch or
               /var/lib/docker/* or
-              /usr/bin/google_guest_agent or 
-              /opt/jc/bin/jumpcloud-agent or 
+              /usr/bin/google_guest_agent or
+              /opt/jc/bin/jumpcloud-agent or
               /opt/puppetlabs/puppet/bin/puppet or
               /usr/bin/chef-client
 )
@@ -53,7 +53,7 @@ event.category:file and event.type:(change or creation) and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SSH Authorized Keys File Modification
 
diff --git a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
index 0645d57187d..d8c40423736 100644
--- a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
+++ b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
@@ -36,7 +36,7 @@ event.category:process and event.type:start and process.args:(echo and *NOPASSWD
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via Sudoers File Modification
 
diff --git a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
index 78471f68c8f..7021375ec51 100644
--- a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
+++ b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
@@ -52,7 +52,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SUID/SGID Bit Set
 
diff --git a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
index 8d0b1cbdadd..6a4ba0a70d2 100644
--- a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
+++ b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
@@ -51,7 +51,7 @@ event.category:process and event.type:start and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Sudo Heap-Based Buffer Overflow Attempt
 
diff --git a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
index dabefa210d6..489862c21de 100644
--- a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
+++ b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
@@ -32,13 +32,13 @@ type = "new_terms"
 
 query = '''
 event.category:file and event.type:change and file.path:(/etc/sudoers* or /private/etc/sudoers*) and
-not process.name:(dpkg or platform-python or puppet or yum or dnf) and 
+not process.name:(dpkg or platform-python or puppet or yum or dnf) and
 not process.executable:(/opt/chef/embedded/bin/ruby or /opt/puppetlabs/puppet/bin/ruby or /usr/bin/dockerd)
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Sudoers File Modification
 
diff --git a/rules/integrations/aws/collection_cloudtrail_logging_created.toml b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
index 694363bb9e4..d97cc1f0759 100644
--- a/rules/integrations/aws/collection_cloudtrail_logging_created.toml
+++ b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
@@ -23,7 +23,7 @@ name = "AWS CloudTrail Log Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS CloudTrail Log Created
 
diff --git a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
index 6f841ec6401..e1a72ddd31c 100644
--- a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
+++ b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
@@ -25,7 +25,7 @@ name = "AWS Management Console Brute Force of Root User Identity"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Management Console Brute Force of Root User Identity
 
diff --git a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
index 3d79fb84154..044e2ccf7e7 100644
--- a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
+++ b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
@@ -23,7 +23,7 @@ name = "AWS Configuration Recorder Stopped"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Configuration Recorder Stopped
 
diff --git a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
index 673aa1fe03f..650b9b52e9e 100644
--- a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
@@ -26,7 +26,7 @@ name = "AWS EC2 Network Access Control List Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 Network Access Control List Deletion
 
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
index 26b2b6f5578..f0c98b595cc 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
@@ -24,7 +24,7 @@ name = "AWS ElastiCache Security Group Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS ElastiCache Security Group Created
 
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
index dcf14818d03..98cd4cb61b8 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
@@ -24,7 +24,7 @@ name = "AWS ElastiCache Security Group Modified or Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS ElastiCache Security Group Modified or Deleted
 
diff --git a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
index ec4f02bff24..a715a82b7ee 100644
--- a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
@@ -26,7 +26,7 @@ name = "AWS GuardDuty Detector Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS GuardDuty Detector Deletion
 
diff --git a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
index 9f5408d461d..25ff424368e 100644
--- a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
+++ b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
@@ -7,7 +7,7 @@ updated_date = "2025/01/10"
 [rule]
 author = ["Austin Songer", "Elastic"]
 description = """
-An adversary with a set of compromised credentials may attempt to make copies of running or deleted RDS databases in order to evade defense mechanisms or access data. This rule identifies successful attempts to restore a DB instance using the RDS `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API operations. 
+An adversary with a set of compromised credentials may attempt to make copies of running or deleted RDS databases in order to evade defense mechanisms or access data. This rule identifies successful attempts to restore a DB instance using the RDS `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API operations.
 """
 false_positives = [
     """
@@ -41,15 +41,15 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where event.dataset == "aws.cloudtrail" 
-    and event.provider == "rds.amazonaws.com" 
-    and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3") 
+any where event.dataset == "aws.cloudtrail"
+    and event.provider == "rds.amazonaws.com"
+    and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3")
     and event.outcome == "success"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS DB Instance Restored
 
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
index d26d92a11af..9fea8feef7d 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
@@ -23,7 +23,7 @@ name = "AWS S3 Bucket Configuration Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS S3 Bucket Configuration Deletion
 
diff --git a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
index bf54ed3f4bd..f0c54a3d391 100644
--- a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
+++ b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
@@ -42,7 +42,7 @@ event.dataset: "aws.cloudtrail"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of STS GetFederationToken Request by User
 
diff --git a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
index 33c6d1d5575..39753bbdfc8 100644
--- a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
@@ -23,7 +23,7 @@ name = "AWS WAF Access Control List Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS WAF Access Control List Deletion
 
diff --git a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
index 5583b5235ed..0f6219dddfd 100644
--- a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
@@ -23,7 +23,7 @@ name = "AWS WAF Rule or Rule Group Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS WAF Rule or Rule Group Deletion
 
diff --git a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
index a64df95e82b..06f580b0ec5 100644
--- a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
+++ b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
@@ -63,7 +63,7 @@ from logs-aws.cloudtrail-*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Service Quotas Multi-Region `GetServiceQuota` Requests
 
diff --git a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
index 11ebc853d10..e8a00596943 100644
--- a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
+++ b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
@@ -52,7 +52,7 @@ event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Time AWS Cloudformation Stack Creation by User
 
diff --git a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
index 0d076751b11..fd484c472ab 100644
--- a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
+++ b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
@@ -27,7 +27,7 @@ name = "AWS EC2 Full Network Packet Capture Detected"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 Full Network Packet Capture Detected
 
diff --git a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
index deef65a43ee..a60f13311d9 100644
--- a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
+++ b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
@@ -26,7 +26,7 @@ name = "AWS EC2 VM Export Failure"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 VM Export Failure
 
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
index 29f9a59228b..898d5d9937f 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
@@ -23,7 +23,7 @@ name = "AWS RDS Snapshot Export"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS Snapshot Export
 
diff --git a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
index 8b067da8dd0..98ba375749e 100644
--- a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
+++ b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
@@ -26,7 +26,7 @@ name = "AWS EventBridge Rule Disabled or Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EventBridge Rule Disabled or Deleted
 
diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
index 3c67566be9f..20d3c114da9 100644
--- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
+++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
@@ -26,7 +26,7 @@ name = "AWS EC2 Encryption Disabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 Encryption Disabled
 
diff --git a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
index 255a0ae64a7..e265909c9a3 100644
--- a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
+++ b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
@@ -27,7 +27,7 @@ name = "AWS EFS File System or Mount Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EFS File System or Mount Deleted
 
diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml
index 06e9523fd17..d0a8241d536 100644
--- a/rules/integrations/aws/impact_iam_group_deletion.toml
+++ b/rules/integrations/aws/impact_iam_group_deletion.toml
@@ -26,7 +26,7 @@ name = "AWS IAM Group Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS IAM Group Deletion
 
diff --git a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
index 1bfd869dcc6..8a28b5077a9 100644
--- a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
+++ b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
@@ -28,7 +28,7 @@ name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS KMS Customer Managed Key Disabled or Scheduled for Deletion
 
diff --git a/rules/integrations/aws/impact_rds_group_deletion.toml b/rules/integrations/aws/impact_rds_group_deletion.toml
index 127e2b4031c..3f07993a69b 100644
--- a/rules/integrations/aws/impact_rds_group_deletion.toml
+++ b/rules/integrations/aws/impact_rds_group_deletion.toml
@@ -24,7 +24,7 @@ name = "AWS RDS Security Group Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS Security Group Deletion
 
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
index 63645111abb..0cd757d9a5c 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
@@ -26,7 +26,7 @@ name = "AWS Deletion of RDS Instance or Cluster"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Deletion of RDS Instance or Cluster
 
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
index 6ff6240159b..09ee8c18b0c 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
@@ -23,7 +23,7 @@ name = "AWS RDS Instance/Cluster Stoppage"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS Instance/Cluster Stoppage
 
diff --git a/rules/integrations/aws/impact_rds_snapshot_deleted.toml b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
index bb09e40ec69..2e1ebda7d30 100644
--- a/rules/integrations/aws/impact_rds_snapshot_deleted.toml
+++ b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
@@ -42,14 +42,14 @@ any where event.dataset == "aws.cloudtrail"
     and event.provider == "rds.amazonaws.com"
     and event.outcome == "success"
     and (
-        event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or 
+        event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or
         (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0"))
     )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS Snapshot Deleted
 
diff --git a/rules/integrations/aws/initial_access_password_recovery.toml b/rules/integrations/aws/initial_access_password_recovery.toml
index da0af803ed0..7072e909adc 100644
--- a/rules/integrations/aws/initial_access_password_recovery.toml
+++ b/rules/integrations/aws/initial_access_password_recovery.toml
@@ -26,7 +26,7 @@ name = "AWS IAM Password Recovery Requested"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS IAM Password Recovery Requested
 
diff --git a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
index 551b1603889..dd8929fb669 100644
--- a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
+++ b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
@@ -49,7 +49,7 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Signin Single Factor Console Login with Federated User
 
diff --git a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
index 2b289fdefa6..b624b5ca974 100644
--- a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
+++ b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
@@ -38,7 +38,7 @@ type = "eql"
 query = '''
 any where event.dataset == "aws.cloudtrail"
    and event.provider == "signin.amazonaws.com"
-   and event.action in ("ConsoleLogin", "GetSigninToken") 
+   and event.action in ("ConsoleLogin", "GetSigninToken")
    and event.outcome == "success"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
    and stringContains (user.id, ":i-")
@@ -46,7 +46,7 @@ any where event.dataset == "aws.cloudtrail"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 Instance Console Login via Assumed Role
 
diff --git a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
index ebe7c1ed629..8d937c18b42 100644
--- a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
+++ b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
@@ -26,7 +26,7 @@ name = "AWS EC2 Network Access Control List Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 Network Access Control List Creation
 
diff --git a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
index 8041dde9f4c..e8530097a76 100644
--- a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
+++ b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
@@ -26,7 +26,7 @@ name = "AWS EC2 Security Group Configuration Change"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 Security Group Configuration Change
 
diff --git a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
index 76e29a4de1b..bb9ebe52ce5 100644
--- a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
+++ b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml
@@ -20,7 +20,7 @@ name = "AWS IAM Login Profile Added for Root"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS IAM Login Profile Added for Root
 
diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml
index ca23bbb4585..a6191786904 100644
--- a/rules/integrations/aws/persistence_iam_group_creation.toml
+++ b/rules/integrations/aws/persistence_iam_group_creation.toml
@@ -26,7 +26,7 @@ name = "AWS IAM Group Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS IAM Group Creation
 
diff --git a/rules/integrations/aws/persistence_rds_cluster_creation.toml b/rules/integrations/aws/persistence_rds_cluster_creation.toml
index 8bc74a442ed..b6292b25b9b 100644
--- a/rules/integrations/aws/persistence_rds_cluster_creation.toml
+++ b/rules/integrations/aws/persistence_rds_cluster_creation.toml
@@ -26,7 +26,7 @@ name = "AWS RDS Cluster Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS Cluster Creation
 
diff --git a/rules/integrations/aws/persistence_rds_group_creation.toml b/rules/integrations/aws/persistence_rds_group_creation.toml
index 6e7b4f6e201..c2425c3097a 100644
--- a/rules/integrations/aws/persistence_rds_group_creation.toml
+++ b/rules/integrations/aws/persistence_rds_group_creation.toml
@@ -23,7 +23,7 @@ name = "AWS RDS Security Group Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS Security Group Creation
 
diff --git a/rules/integrations/aws/persistence_rds_instance_creation.toml b/rules/integrations/aws/persistence_rds_instance_creation.toml
index 8cc4d38b7fc..84e39af4496 100644
--- a/rules/integrations/aws/persistence_rds_instance_creation.toml
+++ b/rules/integrations/aws/persistence_rds_instance_creation.toml
@@ -23,7 +23,7 @@ name = "AWS RDS Instance Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS Instance Creation
 
diff --git a/rules/integrations/aws/persistence_redshift_instance_creation.toml b/rules/integrations/aws/persistence_redshift_instance_creation.toml
index 2164a87333c..cfe6c0d9513 100644
--- a/rules/integrations/aws/persistence_redshift_instance_creation.toml
+++ b/rules/integrations/aws/persistence_redshift_instance_creation.toml
@@ -27,7 +27,7 @@ name = "AWS Redshift Cluster Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Redshift Cluster Creation
 
diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
index 034fb0b3227..00aa782fb9b 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
@@ -26,7 +26,7 @@ name = "AWS Route 53 Domain Transfer Lock Disabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Route 53 Domain Transfer Lock Disabled
 
diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
index ee78e5e193b..897ca6a445d 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
@@ -24,7 +24,7 @@ name = "AWS Route 53 Domain Transferred to Another Account"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Route 53 Domain Transferred to Another Account
 
diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
index 6bc5d1a3a35..5ba34d7ad66 100644
--- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
+++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
@@ -23,7 +23,7 @@ name = "AWS Route53 private hosted zone associated with a VPC"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Route53 private hosted zone associated with a VPC
 
diff --git a/rules/integrations/aws/persistence_route_table_created.toml b/rules/integrations/aws/persistence_route_table_created.toml
index 97f6c434e2c..84fe66b3616 100644
--- a/rules/integrations/aws/persistence_route_table_created.toml
+++ b/rules/integrations/aws/persistence_route_table_created.toml
@@ -24,7 +24,7 @@ name = "AWS Route Table Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Route Table Created
 
diff --git a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
index b6f0f019f77..a0a8178936e 100644
--- a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
+++ b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
@@ -24,7 +24,7 @@ name = "AWS Route Table Modified or Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Route Table Modified or Deleted
 
diff --git a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
index bee33bee0ab..039b0cafb83 100644
--- a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
+++ b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
@@ -8,7 +8,7 @@ updated_date = "2025/01/10"
 [rule]
 author = ["Elastic"]
 description = """
-Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS). 
+Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS).
 While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation.
 """
 false_positives = [
@@ -21,7 +21,7 @@ name = "AWS STS AssumeRole with New MFA Device"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS STS AssumeRole with New MFA Device
 
@@ -82,7 +82,7 @@ event.dataset:aws.cloudtrail
     and event.provider:sts.amazonaws.com
     and event.action:(AssumeRole or AssumeRoleWithSAML or AssumeRoleWithWebIdentity)
     and event.outcome:success
-    and user.id:* 
+    and user.id:*
     and aws.cloudtrail.flattened.request_parameters.serialNumber:*
 '''
 
diff --git a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
index 6ed6e68ae9c..8d6ccc9f591 100644
--- a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
@@ -22,7 +22,7 @@ name = "AWS IAM SAML Provider Updated"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS IAM SAML Provider Updated
 
diff --git a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
index f39eaf92ea8..0726c78cd62 100644
--- a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
@@ -24,7 +24,7 @@ name = "AWS STS GetSessionToken Abuse"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS STS GetSessionToken Abuse
 
diff --git a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
index eaf83a850fa..1fc641927f1 100644
--- a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
@@ -7,8 +7,8 @@ updated_date = "2025/01/10"
 [rule]
 author = ["Elastic"]
 description = """
-Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. 
-While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. 
+Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API.
+While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges.
 Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration.
 This rule looks for role chaining activity happening within a single account, to eliminate false positives produced by common cross-account behavior.
 """
@@ -24,7 +24,7 @@ name = "AWS STS Role Chaining"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS STS Role Chaining
 
diff --git a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
index 06c916b8ae7..8ffd9f67640 100644
--- a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
+++ b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
@@ -28,7 +28,7 @@ name = "Azure Event Hub Authorization Rule Created or Updated"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Event Hub Authorization Rule Created or Updated
 
diff --git a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
index 285b3ba6b92..7e487719b99 100644
--- a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
+++ b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
@@ -27,7 +27,7 @@ name = "Azure Full Network Packet Capture Detected"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Full Network Packet Capture Detected
 
diff --git a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
index 543222f945f..6d6b9ceb0df 100644
--- a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
+++ b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
@@ -46,7 +46,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Entra ID Device Code Auth with Broker Client
 
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
index eac8b2ce8d6..de27728e29f 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
@@ -28,7 +28,7 @@ name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Entra Sign-in Brute Force against Microsoft 365 Accounts
 
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
index c32823290dd..320fe59881c 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
@@ -28,7 +28,7 @@ name = "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source
 
diff --git a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
index ad00781c91a..dcfd02782a9 100644
--- a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
+++ b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
@@ -15,7 +15,7 @@ language = "kuery"
 license = "Elastic License v2"
 name = "First Occurrence of Entra ID Auth via DeviceCode Protocol"
 references =[
-    "https://aadinternals.com/post/phishing/", 
+    "https://aadinternals.com/post/phishing/",
     "https://www.blackhillsinfosec.com/dynamic-device-code-phishing/"
 ]
 risk_score = 47
@@ -35,13 +35,13 @@ timestamp_override = "event.ingested"
 type = "new_terms"
 
 query = '''
- event.dataset:(azure.activitylogs or azure.signinlogs) and 
+ event.dataset:(azure.activitylogs or azure.signinlogs) and
      (azure.signinlogs.properties.authentication_protocol:deviceCode or azure.activitylogs.properties.authentication_protocol:deviceCode) and event.outcome:success
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of Entra ID Auth via DeviceCode Protocol
 
diff --git a/rules/integrations/azure/credential_access_key_vault_modified.toml b/rules/integrations/azure/credential_access_key_vault_modified.toml
index fdef9ad5f15..ea67b172f91 100644
--- a/rules/integrations/azure/credential_access_key_vault_modified.toml
+++ b/rules/integrations/azure/credential_access_key_vault_modified.toml
@@ -26,7 +26,7 @@ name = "Azure Key Vault Modified"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Key Vault Modified
 
diff --git a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
index a18025787ae..172b624192c 100644
--- a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
+++ b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
@@ -26,7 +26,7 @@ name = "Azure Storage Account Key Regenerated"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Storage Account Key Regenerated
 
diff --git a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
index e9f7a68124e..e6663908459 100644
--- a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
+++ b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
@@ -28,7 +28,7 @@ name = "Azure Application Credential Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Application Credential Modification
 
diff --git a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
index 3e08bd09d05..fe7f45e36e4 100644
--- a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
@@ -18,7 +18,7 @@ name = "Azure Automation Runbook Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Automation Runbook Deleted
 
diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
index a8333958dc6..cff6876989a 100644
--- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
+++ b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
@@ -24,7 +24,7 @@ name = "Azure Blob Permissions Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Blob Permissions Modification
 
diff --git a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
index 0b463b5a617..cc40a50096c 100644
--- a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
@@ -26,7 +26,7 @@ name = "Azure Diagnostic Settings Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Diagnostic Settings Deletion
 
diff --git a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
index 406d260880d..63762cf4cc3 100644
--- a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
@@ -25,7 +25,7 @@ name = "Azure Event Hub Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Event Hub Deletion
 
diff --git a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
index 450856efaa3..fb45a8c2527 100644
--- a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
@@ -25,7 +25,7 @@ name = "Azure Firewall Policy Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Firewall Policy Deletion
 
diff --git a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
index 7b208a2f0e0..a386b6eee1a 100644
--- a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
@@ -27,7 +27,7 @@ name = "Azure Frontdoor Web Application Firewall (WAF) Policy Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Frontdoor Web Application Firewall (WAF) Policy Deleted
 
diff --git a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
index a355e7da7a1..0d03605135c 100644
--- a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
@@ -26,7 +26,7 @@ name = "Azure Kubernetes Events Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Kubernetes Events Deleted
 
diff --git a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
index db35de4128f..dce1516abb1 100644
--- a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
@@ -26,7 +26,7 @@ name = "Azure Network Watcher Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Network Watcher Deletion
 
diff --git a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
index cc2c5eb4fa9..a634a0a74a5 100644
--- a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
+++ b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
@@ -26,7 +26,7 @@ name = "Azure Alert Suppression Rule Created or Modified"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Alert Suppression Rule Created or Modified
 
diff --git a/rules/integrations/azure/discovery_blob_container_access_mod.toml b/rules/integrations/azure/discovery_blob_container_access_mod.toml
index aae1449665d..2a4a308335b 100644
--- a/rules/integrations/azure/discovery_blob_container_access_mod.toml
+++ b/rules/integrations/azure/discovery_blob_container_access_mod.toml
@@ -25,7 +25,7 @@ name = "Azure Blob Container Access Level Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Blob Container Access Level Modification
 
diff --git a/rules/integrations/azure/execution_command_virtual_machine.toml b/rules/integrations/azure/execution_command_virtual_machine.toml
index b8126b62705..7bcb6f0aa98 100644
--- a/rules/integrations/azure/execution_command_virtual_machine.toml
+++ b/rules/integrations/azure/execution_command_virtual_machine.toml
@@ -28,7 +28,7 @@ name = "Azure Command Execution on Virtual Machine"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Command Execution on Virtual Machine
 
diff --git a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
index 2080ff09347..eff533598c1 100644
--- a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
+++ b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
@@ -28,7 +28,7 @@ name = "Azure Service Principal Credentials Added"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Service Principal Credentials Added
 
diff --git a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
index 2fc1b2879ed..732a1be1415 100644
--- a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
+++ b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
@@ -25,7 +25,7 @@ name = "Azure Kubernetes Pods Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Kubernetes Pods Deleted
 
diff --git a/rules/integrations/azure/impact_resource_group_deletion.toml b/rules/integrations/azure/impact_resource_group_deletion.toml
index 07c2a1a10df..b9d9e268d26 100644
--- a/rules/integrations/azure/impact_resource_group_deletion.toml
+++ b/rules/integrations/azure/impact_resource_group_deletion.toml
@@ -27,7 +27,7 @@ name = "Azure Resource Group Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Resource Group Deletion
 
diff --git a/rules/integrations/azure/impact_virtual_network_device_modified.toml b/rules/integrations/azure/impact_virtual_network_device_modified.toml
index 7c1c87f45e2..b1d9b4df830 100644
--- a/rules/integrations/azure/impact_virtual_network_device_modified.toml
+++ b/rules/integrations/azure/impact_virtual_network_device_modified.toml
@@ -26,7 +26,7 @@ name = "Azure Virtual Network Device Modified or Deleted"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Virtual Network Device Modified or Deleted
 
diff --git a/rules/integrations/azure/initial_access_external_guest_user_invite.toml b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
index cc5902ae290..20ebd87c399 100644
--- a/rules/integrations/azure/initial_access_external_guest_user_invite.toml
+++ b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
@@ -27,7 +27,7 @@ name = "Azure External Guest User Invitation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure External Guest User Invitation
 
diff --git a/rules/integrations/azure/persistence_azure_automation_account_created.toml b/rules/integrations/azure/persistence_azure_automation_account_created.toml
index 63f187ee4d4..5142abaac6d 100644
--- a/rules/integrations/azure/persistence_azure_automation_account_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_account_created.toml
@@ -19,7 +19,7 @@ name = "Azure Automation Account Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Automation Account Created
 
diff --git a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
index 9a6a3e5d00b..eb286111556 100644
--- a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
+++ b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
@@ -18,7 +18,7 @@ name = "Azure Automation Runbook Created or Modified"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Automation Runbook Created or Modified
 
diff --git a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
index 625aae8b651..e7b06965239 100644
--- a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
@@ -19,7 +19,7 @@ name = "Azure Automation Webhook Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Automation Webhook Created
 
diff --git a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
index a7b14c9b569..4e62b2f4a2a 100644
--- a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
+++ b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
@@ -20,7 +20,7 @@ name = "Azure Conditional Access Policy Modified"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Conditional Access Policy Modified
 
diff --git a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
index 64cd238b79b..d7cba51c326 100644
--- a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
+++ b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
@@ -21,7 +21,7 @@ name = "Azure AD Global Administrator Role Assigned"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure AD Global Administrator Role Assigned
 
diff --git a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
index 8944eed62e2..66bac044e3d 100644
--- a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
+++ b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
@@ -27,7 +27,7 @@ name = "Azure Global Administrator Role Addition to PIM User"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Global Administrator Role Addition to PIM User
 
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
index 5df04014061..4f092e72dce 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
@@ -19,7 +19,7 @@ name = "User Added as Owner for Azure Application"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 User Added as Owner for Azure Application
 
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
index 46faa2c238f..571b574affa 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
@@ -21,7 +21,7 @@ name = "User Added as Owner for Azure Service Principal"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 User Added as Owner for Azure Service Principal
 
diff --git a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
index d1d537c3f86..42919c43d6a 100644
--- a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
+++ b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
@@ -20,7 +20,7 @@ name = "Azure Kubernetes Rolebindings Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Azure Kubernetes Rolebindings Created
 Azure Kubernetes role bindings are crucial for managing access control within Kubernetes clusters, allowing specific permissions to be assigned to users, groups, or service accounts. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others high-level roles, such as cluster-admin. The detection rule monitors Azure activity logs for successful creation events of role or cluster role bindings, signaling potential unauthorized privilege escalation attempts.
diff --git a/rules/integrations/beaconing/command_and_control_beaconing.toml b/rules/integrations/beaconing/command_and_control_beaconing.toml
index 6a1620b73f2..fc7c028c5c1 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing.toml
@@ -49,9 +49,9 @@ type = "query"
 
 query = '''
 beacon_stats.is_beaconing: true and
-not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "WindowsAzureGuestAgent.exe" or "HealthService.exe" or "Widgets.exe" or "lsass.exe" or "msedgewebview2.exe" or 
-                   "MsMpEng.exe" or "OUTLOOK.EXE" or "msteams.exe" or "FileSyncHelper.exe" or "SearchProtocolHost.exe" or "Creative Cloud.exe" or "ms-teams.exe" or "ms-teamsupdate.exe" or 
-                   "curl.exe" or "rundll32.exe" or "MsSense.exe" or "wermgr.exe" or "java" or "olk.exe" or "iexplore.exe" or "NetworkManager" or "packetbeat" or "Ssms.exe" or "NisSrv.exe" or 
+not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "WindowsAzureGuestAgent.exe" or "HealthService.exe" or "Widgets.exe" or "lsass.exe" or "msedgewebview2.exe" or
+                   "MsMpEng.exe" or "OUTLOOK.EXE" or "msteams.exe" or "FileSyncHelper.exe" or "SearchProtocolHost.exe" or "Creative Cloud.exe" or "ms-teams.exe" or "ms-teamsupdate.exe" or
+                   "curl.exe" or "rundll32.exe" or "MsSense.exe" or "wermgr.exe" or "java" or "olk.exe" or "iexplore.exe" or "NetworkManager" or "packetbeat" or "Ssms.exe" or "NisSrv.exe" or
                    "gamingservices.exe" or "appidcertstorecheck.exe" or "POWERPNT.EXE" or "miiserver.exe" or "Grammarly.Desktop.exe" or "SnagitEditor.exe" or "CRWindowsClientService.exe" or
                    "agentbeat" or "dnf" or "yum" or "apt"
                   )
@@ -59,7 +59,7 @@ not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Statistical Model Detected C2 Beaconing Activity
 
diff --git a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
index 91d1a58c882..15476b155f7 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
@@ -53,7 +53,7 @@ beacon_stats.beaconing_score: 3
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Statistical Model Detected C2 Beaconing Activity with High Confidence
 
diff --git a/rules/integrations/cloud_defend/container_workload_protection.toml b/rules/integrations/cloud_defend/container_workload_protection.toml
index e3fc2fe05fa..4e6adb11650 100644
--- a/rules/integrations/cloud_defend/container_workload_protection.toml
+++ b/rules/integrations/cloud_defend/container_workload_protection.toml
@@ -40,7 +40,7 @@ event.kind:alert and event.module:cloud_defend
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Container Workload Protection
 
diff --git a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
index 3dac6dc3a37..4f1a05c1c44 100644
--- a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
@@ -32,17 +32,17 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where event.module == "cloud_defend" and     
+process where event.module == "cloud_defend" and
   event.type == "start" and
-  
+
 /*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/
-(process.name : ("grep", "egrep", "fgrep", "find", "locate", "mlocate") or process.args : ("grep", "egrep", "fgrep", "find", "locate", "mlocate")) and 
+(process.name : ("grep", "egrep", "fgrep", "find", "locate", "mlocate") or process.args : ("grep", "egrep", "fgrep", "find", "locate", "mlocate")) and
 process.args : ("*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", "*access_key*", "*.aws/credentials*")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Credentials Searched For Inside A Container
 
diff --git a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
index e4a7b35c05e..0aa2cb2092e 100644
--- a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
@@ -31,22 +31,22 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where container.id: "*" and event.type== "start" and 
+process where container.id: "*" and event.type== "start" and
 
-/*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/  
+/*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/
 (process.name: ("zip", "tar", "gzip", "hdiutil", "7z") or process.args: ("zip", "tar", "gzip", "hdiutil", "7z"))
-and process.args: ( 
-"/root/.ssh/id_rsa", 
-"/root/.ssh/id_rsa.pub", 
-"/root/.ssh/id_ed25519", 
-"/root/.ssh/id_ed25519.pub", 
-"/root/.ssh/authorized_keys", 
-"/root/.ssh/authorized_keys2", 
-"/root/.ssh/known_hosts", 
-"/root/.bash_history", 
-"/etc/hosts", 
-"/home/*/.ssh/id_rsa", 
-"/home/*/.ssh/id_rsa.pub", 
+and process.args: (
+"/root/.ssh/id_rsa",
+"/root/.ssh/id_rsa.pub",
+"/root/.ssh/id_ed25519",
+"/root/.ssh/id_ed25519.pub",
+"/root/.ssh/authorized_keys",
+"/root/.ssh/authorized_keys2",
+"/root/.ssh/known_hosts",
+"/root/.bash_history",
+"/etc/hosts",
+"/home/*/.ssh/id_rsa",
+"/home/*/.ssh/id_rsa.pub",
 "/home/*/.ssh/id_ed25519",
 "/home/*/.ssh/id_ed25519.pub",
 "/home/*/.ssh/authorized_keys",
@@ -67,7 +67,7 @@ and process.args: (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Sensitive Files Compression Inside A Container
 
diff --git a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
index 1dc5c0c213c..8e249852610 100644
--- a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
@@ -34,22 +34,22 @@ type = "eql"
 query = '''
 process where container.id: "*" and event.type== "start" and
 ((
-/*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/  
-  (process.name in ("grep", "egrep", "fgrep") or process.args in ("grep", "egrep", "fgrep")) 
-    and process.args : ("*BEGIN PRIVATE*", "*BEGIN OPENSSH PRIVATE*", "*BEGIN RSA PRIVATE*", 
+/*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/
+  (process.name in ("grep", "egrep", "fgrep") or process.args in ("grep", "egrep", "fgrep"))
+    and process.args : ("*BEGIN PRIVATE*", "*BEGIN OPENSSH PRIVATE*", "*BEGIN RSA PRIVATE*",
 "*BEGIN DSA PRIVATE*", "*BEGIN EC PRIVATE*", "*pass*", "*ssh*", "*user*")
-) 
-or 
+)
+or
 (
 /*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/
-  (process.name in ("find", "locate", "mlocate") or process.args in ("find", "locate", "mlocate")) 
+  (process.name in ("find", "locate", "mlocate") or process.args in ("find", "locate", "mlocate"))
     and process.args : ("*id_rsa*", "*id_dsa*")
 ))
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Sensitive Keys Or Passwords Searched For Inside A Container
 
diff --git a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
index 21eddfa9402..eba962c5949 100644
--- a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
@@ -37,7 +37,7 @@ file where event.module== "cloud_defend" and event.type != "deletion" and file.p
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Dynamic Linker Preload Shared Object Inside A Container
 
diff --git a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
index 7606594d94a..52a64383463 100644
--- a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
@@ -41,9 +41,9 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where container.id: "*" and event.type== "start" and 
+process where container.id: "*" and event.type== "start" and
 (
-(process.name: ("nc", "ncat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab")) or 
+(process.name: ("nc", "ncat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab")) or
 /*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/
 (process.args: ("nc", "ncat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab"))
 )
@@ -51,7 +51,7 @@ process where container.id: "*" and event.type== "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Network Tool Launched Inside A Container
 
diff --git a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
index 802e409051a..1ff68903765 100644
--- a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
@@ -39,13 +39,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where container.id: "*" and event.type== "start" 
+process where container.id: "*" and event.type== "start"
   and process.name: ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "runc", "systemd", "crictl")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Container Management Utility Run Inside A Container
 
diff --git a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
index 8d6d75577e3..7bd50856d92 100644
--- a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
@@ -35,13 +35,13 @@ query = '''
 file where container.id: "*" and event.type in ("change", "creation") and
 
 /*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/
-(process.name : "chmod" or process.args : "chmod") and 
+(process.name : "chmod" or process.args : "chmod") and
 process.args : ("*x*", "777", "755", "754", "700") and not process.args: "-x"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File Made Executable via Chmod Inside A Container
 
diff --git a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
index f3ed4d5f336..9446fe587ea 100644
--- a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
@@ -47,10 +47,10 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where container.id : "*" and event.type== "start" and 
+process where container.id : "*" and event.type== "start" and
 
 /* use of kubectl exec to enter a container */
-process.entry_leader.entry_meta.type : "container" and 
+process.entry_leader.entry_meta.type : "container" and
 
 /* process is the inital process run in a container */
 process.entry_leader.same_as_process== true and
@@ -61,7 +61,7 @@ process.interactive == true
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Interactive Exec Command Launched Against A Running Container
 
diff --git a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
index 3582617b6ba..90d3577a298 100644
--- a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
@@ -37,7 +37,7 @@ type = "eql"
 
 query = '''
 process where container.id: "*" and
-event.type== "start" and 
+event.type== "start" and
 
 /*D4C consolidates closely spawned event.actions, this excludes end actions to only capture ongoing processes*/
 event.action in ("fork", "exec") and event.action != "end"
@@ -50,7 +50,7 @@ process.args: "*/*sh"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Interactive Shell Spawned From Inside A Container
 
diff --git a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
index 50baf63647d..8b9c6637863 100644
--- a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
@@ -39,8 +39,8 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where container.id: "*" and event.type== "start" 
-and event.action in ("fork", "exec") and 
+process where container.id: "*" and event.type== "start"
+and event.action in ("fork", "exec") and
 (
 process.name:("nc","ncat","netcat","netcat.openbsd","netcat.traditional") or
 /*account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg*/
@@ -55,7 +55,7 @@ process.args: ("nc","ncat","netcat","netcat.openbsd","netcat.traditional")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Netcat Listener Established Inside A Container
 
diff --git a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
index dd3a14b5e6e..ba4614ecdea 100644
--- a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
@@ -41,13 +41,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where container.id: "*" and event.type == "start" and 
+process where container.id: "*" and event.type == "start" and
 
 /* use of sshd to enter a container*/
-process.entry_leader.entry_meta.type: "sshd"  and 
+process.entry_leader.entry_meta.type: "sshd"  and
 
 /* process is the initial process run in a container or start of a new session*/
-(process.entry_leader.same_as_process== true or process.session_leader.same_as_process== true) and 
+(process.entry_leader.same_as_process== true or process.session_leader.same_as_process== true) and
 
 /* interactive process*/
 process.interactive== true
@@ -55,7 +55,7 @@ process.interactive== true
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SSH Connection Established Inside A Running Container
 
diff --git a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
index a0e12e805cb..e17ef878e45 100644
--- a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
@@ -44,13 +44,13 @@ type = "eql"
 
 query = '''
 process where container.id: "*" and event.type== "start" and
-event.action in ("fork", "exec") and event.action != "end" and 
+event.action in ("fork", "exec") and event.action != "end" and
 process.name: ("sshd", "ssh", "autossh")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SSH Process Launched From Inside A Container
 
diff --git a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
index edd4637f770..0fbdd5d926f 100644
--- a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
@@ -39,7 +39,7 @@ file where container.id:"*" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SSH Authorized Keys File Modified Inside a Container
 
diff --git a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
index b8300c89e9b..c276730b225 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
@@ -37,15 +37,15 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where event.module == "cloud_defend" and     
-  event.type == "start" and process.name == "debugfs" and 
+process where event.module == "cloud_defend" and
+  event.type == "start" and process.name == "debugfs" and
   process.args : "/dev/sd*" and not process.args == "-R" and
   container.security_context.privileged == true
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File System Debugger Launched Inside a Privileged Container
 
diff --git a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
index 1a68d5bfeb2..eca6da4b6f1 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
@@ -37,13 +37,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where event.module == "cloud_defend" and  event.type== "start" and 
+process where event.module == "cloud_defend" and  event.type== "start" and
 (process.name== "mount" or process.args== "mount") and container.security_context.privileged == true
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Mount Launched Inside a Privileged Container
 
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
index f6de548d46d..36a31cd3f1c 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
@@ -38,13 +38,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-file where event.module == "cloud_defend" and event.action == "open" and 
+file where event.module == "cloud_defend" and event.action == "open" and
 event.type == "change" and file.name : "notify_on_release"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Container Escape via Modified notify_on_release File
 
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
index 0c03015586e..887f8c2250b 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
@@ -37,13 +37,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-file where event.module == "cloud_defend" and event.action == "open" and 
+file where event.module == "cloud_defend" and event.action == "open" and
 event.type == "change" and file.name : "release_agent"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Container Escape via Modified release_agent File
 
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
index adf915df75f..1790fed6242 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
@@ -26,10 +26,10 @@ risk_score = 21
 rule_id = "e1db8899-97c1-4851-8993-3a3265353601"
 setup = """## Setup
 
-The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).  
+The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).
 
 ### Data Exfiltration Detection Setup
-The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. 
+The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.
 
 #### Prerequisite Requirements:
 - Fleet is required for Data Exfiltration Detection.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Data Exfiltration Activity to an Unusual ISO Code
 
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
index a7001a580c4..145e5693ef0 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
@@ -26,10 +26,10 @@ risk_score = 21
 rule_id = "cc653d77-ddd2-45b1-9197-c75ad19df66c"
 setup = """## Setup
 
-The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).  
+The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).
 
 ### Data Exfiltration Detection Setup
-The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. 
+The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.
 
 #### Prerequisite Requirements:
 - Fleet is required for Data Exfiltration Detection.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Data Exfiltration Activity to an Unusual IP Address
 
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
index 00f61eea102..d56613657ac 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
@@ -25,10 +25,10 @@ risk_score = 21
 rule_id = "ef8cc01c-fc49-4954-a175-98569c646740"
 setup = """## Setup
 
-The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).  
+The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).
 
 ### Data Exfiltration Detection Setup
-The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. 
+The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.
 
 #### Prerequisite Requirements:
 - Fleet is required for Data Exfiltration Detection.
@@ -54,7 +54,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Data Exfiltration Activity to an Unusual Destination Port
 
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
index c801849735d..cd2aa1a538a 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
@@ -26,10 +26,10 @@ risk_score = 21
 rule_id = "bfba5158-1fd6-4937-a205-77d96213b341"
 setup = """## Setup
 
-The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).  
+The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).
 
 ### Data Exfiltration Detection Setup
-The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. 
+The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.
 
 #### Prerequisite Requirements:
 - Fleet is required for Data Exfiltration Detection.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Data Exfiltration Activity to an Unusual Region
 
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
index 36b9d7ff333..c3d47eb95a3 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
@@ -26,10 +26,10 @@ risk_score = 21
 rule_id = "35a3b253-eea8-46f0-abd3-68bdd47e6e3d"
 setup = """## Setup
 
-The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).  
+The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).
 
 ### Data Exfiltration Detection Setup
-The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. 
+The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.
 
 #### Prerequisite Requirements:
 - Fleet is required for Data Exfiltration Detection.
@@ -54,7 +54,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Bytes Sent to an External Device
 
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
index 242528144a1..c6baea689f1 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
@@ -27,10 +27,10 @@ risk_score = 21
 rule_id = "e92c99b6-c547-4bb6-b244-2f27394bc849"
 setup = """## Setup
 
-The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).  
+The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).
 
 ### Data Exfiltration Detection Setup
-The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. 
+The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.
 
 #### Prerequisite Requirements:
 - Fleet is required for Data Exfiltration Detection.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Bytes Sent to an External Device via Airdrop
 
diff --git a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
index c57048c344a..53b6485a602 100644
--- a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
@@ -26,10 +26,10 @@ risk_score = 21
 rule_id = "4b95ecea-7225-4690-9938-2a2c0bad9c99"
 setup = """## Setup
 
-The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).  
+The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).
 
 ### Data Exfiltration Detection Setup
-The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. 
+The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.
 
 #### Prerequisite Requirements:
 - Fleet is required for Data Exfiltration Detection.
@@ -54,7 +54,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process Writing Data to an External Device
 
diff --git a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
index d7c944dca7e..5f7a8b70a0a 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
@@ -24,7 +24,7 @@ risk_score = 99
 rule_id = "bcaa15ce-2d41-44d7-a322-918f9db77766"
 setup = """## Setup
 
-The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.  
+The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.
 
 ### DGA Detection Setup
 The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.
@@ -62,7 +62,7 @@ ml_is_dga.malicious_prediction:1 and dns.question.registered_domain:avsvmcloud.c
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Machine Learning Detected DGA activity using a known SUNBURST DNS domain
 
diff --git a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
index 08eaf51c9bf..d9a338d7772 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
@@ -26,7 +26,7 @@ risk_score = 21
 rule_id = "ff0d807d-869b-4a0d-a493-52bc46d2f1b1"
 setup = """## Setup
 
-The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.  
+The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.
 
 ### DGA Detection Setup
 The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.
@@ -46,7 +46,7 @@ The DGA Detection integration consists of an ML-based framework to detect DGA ac
 - For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
 
 ### Anomaly Detection Setup
-Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. 
+Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job.
 - Go to the Kibana homepage. Under Analytics, click Machine Learning.
 - Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched DNS events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture.
 - If the selected Data View contains events that match the query in [this](https://github.com/elastic/integrations/blob/main/packages/dga/kibana/ml_module/dga-ml.json) configuration file, you will see a card for DGA under "Use preconfigured jobs".
@@ -63,7 +63,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential DGA Activity
 Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. Adversaries exploit this by frequently changing domains to evade detection. The 'Potential DGA Activity' detection rule leverages machine learning to analyze DNS requests from source IPs, identifying patterns indicative of DGA usage, thus flagging potential threats for further investigation.
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
index 48a8202ef98..a22143f6c1f 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
@@ -24,7 +24,7 @@ risk_score = 21
 rule_id = "da7f5803-1cd4-42fd-a890-0173ae80ac69"
 setup = """## Setup
 
-The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.  
+The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.
 
 ### DGA Detection Setup
 The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.
@@ -62,7 +62,7 @@ ml_is_dga.malicious_probability > 0.98
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Machine Learning Detected a DNS Request With a High DGA Probability Score
 
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
index bc817ee6848..d15606fad3f 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
@@ -24,7 +24,7 @@ risk_score = 21
 rule_id = "f3403393-1fd9-4686-8f6e-596c58bc00b4"
 setup = """## Setup
 
-The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.  
+The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.
 
 ### DGA Detection Setup
 The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.
@@ -62,7 +62,7 @@ ml_is_dga.malicious_prediction:1 and not dns.question.registered_domain:avsvmclo
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Machine Learning Detected a DNS Request Predicted to be a DGA Domain
 
diff --git a/rules/integrations/endpoint/elastic_endpoint_security.toml b/rules/integrations/endpoint/elastic_endpoint_security.toml
index 5a00cedc190..94b0edde57b 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security.toml
@@ -62,7 +62,7 @@ event.kind:alert and event.module:(endpoint and not endgame)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Endpoint Security (Elastic Defend)
 
diff --git a/rules/integrations/fim/persistence_suspicious_file_modifications.toml b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
index 931cfa939bd..efe1c35274f 100644
--- a/rules/integrations/fim/persistence_suspicious_file_modifications.toml
+++ b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
@@ -136,7 +136,7 @@ file.path : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Persistence via File Modification
 
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
index ce3f2e6a451..248edb32290 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
@@ -25,7 +25,7 @@ name = "GCP Pub/Sub Subscription Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Pub/Sub Subscription Creation
 
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
index 49aebb40751..62293ca47e9 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
@@ -25,7 +25,7 @@ name = "GCP Pub/Sub Topic Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Pub/Sub Topic Creation
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
index 8441afaca40..fd0a9562eeb 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
@@ -25,7 +25,7 @@ name = "GCP Firewall Rule Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Firewall Rule Creation
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
index 71669e06d5d..8ac98bd391c 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
@@ -24,7 +24,7 @@ name = "GCP Firewall Rule Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Firewall Rule Deletion
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
index 24f35e7261f..5dd2a532f0e 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
@@ -25,7 +25,7 @@ name = "GCP Firewall Rule Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Firewall Rule Modification
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
index 65a080279fb..b9601340fc8 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
@@ -27,7 +27,7 @@ name = "GCP Logging Bucket Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Logging Bucket Deletion
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
index 8e2fc2b8f38..53ef5da345f 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
@@ -25,7 +25,7 @@ name = "GCP Logging Sink Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Logging Sink Deletion
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
index 41f038e2c2e..ce854318857 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
@@ -25,7 +25,7 @@ name = "GCP Pub/Sub Subscription Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Pub/Sub Subscription Deletion
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
index a4c66e3681a..044db48100b 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
@@ -25,7 +25,7 @@ name = "GCP Pub/Sub Topic Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Pub/Sub Topic Deletion
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
index 6133b2d43d1..b2027a31fb1 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
@@ -23,7 +23,7 @@ name = "GCP Storage Bucket Configuration Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Storage Bucket Configuration Modification
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
index eb749c4a286..480460a1c04 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
@@ -24,7 +24,7 @@ name = "GCP Storage Bucket Permissions Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Storage Bucket Permissions Modification
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
index c163e2a2b85..99eba7a85c1 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
@@ -25,7 +25,7 @@ name = "GCP Virtual Private Cloud Network Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Virtual Private Cloud Network Deletion
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
index 27707e415c6..d71730d1b73 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
@@ -25,7 +25,7 @@ name = "GCP Virtual Private Cloud Route Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Virtual Private Cloud Route Creation
 
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
index dbeccf5e981..5642ba8d6dc 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
@@ -25,7 +25,7 @@ name = "GCP Virtual Private Cloud Route Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Virtual Private Cloud Route Deletion
 
diff --git a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
index 000bd8e4d33..1a24433f1cb 100644
--- a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
+++ b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
@@ -25,7 +25,7 @@ name = "GCP Logging Sink Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Logging Sink Modification
 
diff --git a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
index da66408034c..c7dcf53018e 100644
--- a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
+++ b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
@@ -25,7 +25,7 @@ name = "GCP IAM Role Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP IAM Role Deletion
 
diff --git a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
index d99fd367405..fdb31ff3445 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
@@ -26,7 +26,7 @@ name = "GCP Service Account Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Service Account Deletion
 
diff --git a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
index b88c8aac57e..10b4e12b1aa 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
@@ -26,7 +26,7 @@ name = "GCP Service Account Disabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Service Account Disabled
 
diff --git a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
index 795577a9a02..3bf87b7a0c0 100644
--- a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
@@ -24,7 +24,7 @@ name = "GCP Storage Bucket Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Storage Bucket Deletion
 
diff --git a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
index b73a99e175e..2347ca3e662 100644
--- a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
+++ b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
@@ -25,7 +25,7 @@ name = "GCP IAM Custom Role Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP IAM Custom Role Creation
 
diff --git a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
index 3091a47ed2f..91301965a41 100644
--- a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
+++ b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
@@ -26,7 +26,7 @@ name = "GCP IAM Service Account Key Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP IAM Service Account Key Deletion
 
diff --git a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
index 5d1bd27a06c..d869326e949 100644
--- a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
+++ b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
@@ -27,7 +27,7 @@ name = "GCP Service Account Key Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Service Account Key Creation
 
diff --git a/rules/integrations/gcp/persistence_gcp_service_account_created.toml b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
index 0a1640f1e17..3722562b73f 100644
--- a/rules/integrations/gcp/persistence_gcp_service_account_created.toml
+++ b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
@@ -27,7 +27,7 @@ name = "GCP Service Account Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 GCP Service Account Creation
 
diff --git a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
index e818ff1d14f..6467a9885d7 100644
--- a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
+++ b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
@@ -33,7 +33,7 @@ configuration where event.dataset == "github.audit"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Protected Branch Settings Changed
 
diff --git a/rules/integrations/github/execution_github_app_deleted.toml b/rules/integrations/github/execution_github_app_deleted.toml
index c6f0da2a2b8..0a72059c0c0 100644
--- a/rules/integrations/github/execution_github_app_deleted.toml
+++ b/rules/integrations/github/execution_github_app_deleted.toml
@@ -27,7 +27,7 @@ configuration where event.dataset == "github.audit" and github.category == "inte
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 App Deleted
 
diff --git a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
index a73ab195a5d..1b11b55fd29 100644
--- a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
+++ b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
@@ -38,7 +38,7 @@ github.repository_public:false
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 High Number of Cloned GitHub Repos From PAT
 
diff --git a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
index a83a83e5b2e..ce084648803 100644
--- a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
+++ b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
@@ -37,7 +37,7 @@ signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.w
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 UEBA - Multiple Alerts from a GitHub Account
 
diff --git a/rules/integrations/github/execution_new_github_app_installed.toml b/rules/integrations/github/execution_new_github_app_installed.toml
index 0cd5b02d081..3535fe37042 100644
--- a/rules/integrations/github/execution_new_github_app_installed.toml
+++ b/rules/integrations/github/execution_new_github_app_installed.toml
@@ -33,7 +33,7 @@ configuration where event.dataset == "github.audit" and event.action == "integra
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 New GitHub App Installed
 
diff --git a/rules/integrations/github/impact_github_repository_deleted.toml b/rules/integrations/github/impact_github_repository_deleted.toml
index e63c22d1281..f9feff11567 100644
--- a/rules/integrations/github/impact_github_repository_deleted.toml
+++ b/rules/integrations/github/impact_github_repository_deleted.toml
@@ -38,7 +38,7 @@ configuration where event.module == "github" and event.dataset == "github.audit"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Repository Deleted
 GitHub repositories are essential for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase critical data, potentially indicating a security breach. The detection rule monitors GitHub audit logs for repository deletion events, enabling analysts to swiftly identify and investigate unauthorized actions, thereby mitigating potential data loss and compromise.
diff --git a/rules/integrations/github/persistence_github_org_owner_added.toml b/rules/integrations/github/persistence_github_org_owner_added.toml
index 05fc5a2f233..553ccced09e 100644
--- a/rules/integrations/github/persistence_github_org_owner_added.toml
+++ b/rules/integrations/github/persistence_github_org_owner_added.toml
@@ -37,7 +37,7 @@ iam where event.dataset == "github.audit" and event.action == "org.add_member" a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 New GitHub Owner Added
 
diff --git a/rules/integrations/github/persistence_organization_owner_role_granted.toml b/rules/integrations/github/persistence_organization_owner_role_granted.toml
index 43877014ef6..9d5c504ec04 100644
--- a/rules/integrations/github/persistence_organization_owner_role_granted.toml
+++ b/rules/integrations/github/persistence_organization_owner_role_granted.toml
@@ -37,7 +37,7 @@ iam where event.dataset == "github.audit" and event.action == "org.update_member
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Owner Role Granted To User
 
diff --git a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
index 8e0711f0156..af63a73a549 100644
--- a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
+++ b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
@@ -27,7 +27,7 @@ name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
 
diff --git a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
index 70ede72ca9c..db9094e9a08 100644
--- a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
+++ b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
@@ -26,7 +26,7 @@ name = "First Time Seen Google Workspace OAuth Login from Third-Party Applicatio
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Time Seen Google Workspace OAuth Login from Third-Party Application
 
diff --git a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
index 652ba565ac7..1225cf723d9 100644
--- a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
+++ b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
@@ -27,7 +27,7 @@ name = "Google Workspace Suspended User Account Renewed"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Google Workspace Suspended User Account Renewed
 
diff --git a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
index ffe59981ec8..5f5f5219b0a 100644
--- a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
+++ b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
@@ -26,7 +26,7 @@ name = "Kubernetes Denied Service Account Request"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Denied Service Account Request
 
diff --git a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
index db03c051d9e..20978d03e5e 100644
--- a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
+++ b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
@@ -26,7 +26,7 @@ name = "Kubernetes Suspicious Self-Subject Review"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Suspicious Self-Subject Review
 
diff --git a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
index 9506fe0ac92..b34cbc1677d 100644
--- a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
+++ b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
@@ -29,7 +29,7 @@ name = "Kubernetes User Exec into Pod"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes User Exec into Pod
 
diff --git a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
index 4b2aabf0160..3b12649c5e4 100644
--- a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
+++ b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
@@ -25,7 +25,7 @@ name = "Kubernetes Anonymous Request Authorized"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Anonymous Request Authorized
 
diff --git a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
index 5c3537f5e6e..8cdb7f67bb0 100644
--- a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
+++ b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
@@ -32,7 +32,7 @@ name = "Kubernetes Exposed Service Created With Type NodePort"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Exposed Service Created With Type NodePort
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
index 76d953a1684..0afe4c3efbd 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
@@ -29,7 +29,7 @@ name = "Kubernetes Pod Created With HostIPC"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Pod Created With HostIPC
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
index 1cae4551d6b..eb1093928ea 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
@@ -28,7 +28,7 @@ name = "Kubernetes Pod Created With HostNetwork"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Pod Created With HostNetwork
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
index 0ac43d24b60..411ac408b12 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
@@ -29,7 +29,7 @@ name = "Kubernetes Pod Created With HostPID"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Pod Created With HostPID
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
index 8ef13294ac4..463da62fe59 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
@@ -29,7 +29,7 @@ name = "Kubernetes Pod created with a Sensitive hostPath Volume"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Pod created with a Sensitive hostPath Volume
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
index 2b97c237a44..c305bba337f 100644
--- a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
@@ -29,7 +29,7 @@ name = "Kubernetes Privileged Pod Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Privileged Pod Created
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
index c8cabc87d9b..66ea42381ec 100644
--- a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
@@ -27,7 +27,7 @@ name = "Kubernetes Suspicious Assignment of Controller Service Account"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kubernetes Suspicious Assignment of Controller Service Account
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
index 8b31089d5c9..d250671d9e9 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
@@ -27,7 +27,7 @@ risk_score = 21
 rule_id = "36c48a0c-c63a-4cbc-aee1-8cac87db31a9"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 High Mean of Process Arguments in an RDP Session
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
index 817f0cf6740..d8e9dee58fa 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
@@ -27,7 +27,7 @@ risk_score = 21
 rule_id = "a74c60cb-70ee-4629-a127-608ead14ebf1"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 High Mean of RDP Session Duration
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
index 8dfcae92b72..4ed7933ed14 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
@@ -28,7 +28,7 @@ risk_score = 21
 rule_id = "0678bc9c-b71a-433b-87e6-2f664b6b3131"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -56,7 +56,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Remote File Size
 Machine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule leverages ML to flag these anomalies, aiding in early detection of potential data exfiltration activities.
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
index 05052fda4e6..bcacb0b27e6 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
@@ -27,7 +27,7 @@ risk_score = 21
 rule_id = "a8d35ca0-ad8d-48a9-9f6c-553622dca61a"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 High Variance in RDP Session Duration
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
index 0252319a055..dd47452c003 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
@@ -27,7 +27,7 @@ risk_score = 21
 rule_id = "be4c5aed-90f5-4221-8bd5-7ab3a4334751"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Remote File Directory
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
index dccf3526e38..b83970cf456 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
@@ -26,7 +26,7 @@ risk_score = 21
 rule_id = "814d96c7-2068-42aa-ba8e-fe0ddd565e2e"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -54,7 +54,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Remote File Extension
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
index 72ccbba305d..9c23594d32d 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
@@ -27,7 +27,7 @@ risk_score = 21
 rule_id = "3e0561b5-3fac-4461-84cc-19163b9aaa61"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Number of Connections Made from a Source IP
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
index aa4363695b3..6849ec4586a 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
@@ -27,7 +27,7 @@ risk_score = 21
 rule_id = "18a5dd9a-e3fa-4996-99b1-ae533b8f27fc"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Number of Connections Made to a Destination IP
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
index 1881a7cc400..93948ff2d3e 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
@@ -26,7 +26,7 @@ risk_score = 21
 rule_id = "19e9daf3-f5c5-4bc2-a9af-6b1e97098f03"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -54,7 +54,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Number of Processes in an RDP Session
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
index 4ac117d38c3..f5198584e82 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
@@ -28,7 +28,7 @@ risk_score = 21
 rule_id = "e9b0902b-c515-413b-b80b-a8dcebc81a66"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -56,7 +56,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Remote File Transfers
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
index 46c9a8e41c7..7c43c368373 100644
--- a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
@@ -27,7 +27,7 @@ risk_score = 21
 rule_id = "3f4e2dba-828a-452a-af35-fe29c5e78969"
 setup = """## Setup
 
-The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.  
+The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.
 
 ### Lateral Movement Detection Setup
 The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.
@@ -55,7 +55,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Time or Day for an RDP Session
 
diff --git a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
index 9860dbe73d5..d49fffbdac5 100644
--- a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
+++ b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
@@ -26,7 +26,7 @@ name = "Microsoft 365 Inbox Forwarding Rule Created"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Inbox Forwarding Rule Created
 
diff --git a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
index a1fb6bacac4..365fcce4a7c 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
@@ -89,7 +89,7 @@ from logs-o365.audit-*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Attempts to Brute Force a Microsoft 365 User Account
 
diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
index 2f554d1dadf..1167ea15706 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
@@ -25,7 +25,7 @@ name = "Deprecated - Potential Password Spraying of Microsoft 365 User Accounts"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Deprecated - Potential Password Spraying of Microsoft 365 User Accounts
 
diff --git a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
index 280d82071c7..dc5ee41331b 100644
--- a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
+++ b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
@@ -24,7 +24,7 @@ name = "O365 Excessive Single Sign-On Logon Errors"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 O365 Excessive Single Sign-On Logon Errors
 
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
index 4df4f2a67dc..167c11a6bfc 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
@@ -24,7 +24,7 @@ name = "Microsoft 365 Exchange DLP Policy Removed"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange DLP Policy Removed
 
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
index e5ade4558ae..73f1b054994 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Exchange Malware Filter Policy Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Malware Filter Policy Deletion
 
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
index 49f1d59e2d5..534b4f5ee4c 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
@@ -24,7 +24,7 @@ name = "Microsoft 365 Exchange Malware Filter Rule Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Malware Filter Rule Modification
 
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
index 716701f4dc1..898ca3e8be5 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Exchange Safe Attachment Rule Disabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Safe Attachment Rule Disabled
 
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
index 1eab3695794..4a7cd156f04 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
@@ -24,7 +24,7 @@ name = "O365 Mailbox Audit Logging Bypass"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 O365 Mailbox Audit Logging Bypass
 
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
index 7c3d6863c66..93aa60919b4 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Exchange Transport Rule Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Transport Rule Creation
 
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
index 143915de013..a8c80f6adf3 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Exchange Transport Rule Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Transport Rule Modification
 
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
index 84c109beb45..b75e804cfe6 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
@@ -16,7 +16,7 @@ name = "Microsoft 365 Mass download by a single user"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Mass download by a single user
 
diff --git a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
index d693a90178b..d362c9b34b1 100644
--- a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
+++ b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
@@ -24,7 +24,7 @@ name = "Microsoft 365 Potential ransomware activity"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Potential ransomware activity
 
diff --git a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
index 75a2ac3f0fe..3064dadef4c 100644
--- a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
+++ b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
@@ -16,7 +16,7 @@ name = "Microsoft 365 Unusual Volume of File Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Unusual Volume of File Deletion
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
index 65239ea08fc..c34f4933d75 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Exchange Anti-Phish Policy Deletion"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Anti-Phish Policy Deletion
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
index cf514c9ade5..d811244259f 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Exchange Anti-Phish Rule Modification"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Anti-Phish Rule Modification
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
index 72e6d898831..4b9ce8c228c 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
@@ -24,7 +24,7 @@ name = "Microsoft 365 Exchange Safe Link Policy Disabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Safe Link Policy Disabled
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
index d449f41bc45..4a0ddbfcfb1 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
@@ -19,7 +19,7 @@ name = "Microsoft 365 Impossible travel activity"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Impossible travel activity
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
index adc57f78674..bcbbced53bb 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
@@ -42,7 +42,7 @@ event.dataset: "o365.audit"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Portal Logins from Impossible Travel Locations
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
index 9179fefe59d..1bb1602275f 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
@@ -40,7 +40,7 @@ event.dataset: "o365.audit"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Portal Login from Rare Location
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
index 48b799580c2..a75af9b8df1 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
@@ -19,7 +19,7 @@ name = "Microsoft 365 User Restricted from Sending Email"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 User Restricted from Sending Email
 
diff --git a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
index 3d6fbb4b873..448e4a29e4a 100644
--- a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
+++ b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
@@ -21,7 +21,7 @@ name = "O365 Email Reported by User as Malware or Phish"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 O365 Email Reported by User as Malware or Phish
 
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
index 4f91024caab..94c0fb65c78 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
@@ -21,7 +21,7 @@ name = "OneDrive Malware File Upload"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 OneDrive Malware File Upload
 
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
index c9b01a46066..9649942595e 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
@@ -21,7 +21,7 @@ name = "SharePoint Malware File Upload"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SharePoint Malware File Upload
 
diff --git a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
index 3d196114b69..fe520c2e72c 100644
--- a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
+++ b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
@@ -19,7 +19,7 @@ name = "O365 Exchange Suspicious Mailbox Right Delegation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 O365 Exchange Suspicious Mailbox Right Delegation
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
index ebb283e18d1..1388ae1826e 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
@@ -26,7 +26,7 @@ name = "Microsoft 365 Exchange DKIM Signing Configuration Disabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange DKIM Signing Configuration Disabled
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
index 4c6ac6ae501..95cdb43b803 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
@@ -24,7 +24,7 @@ name = "Microsoft 365 Exchange Management Group Role Assignment"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Exchange Management Group Role Assignment
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
index c7e9e7b27b1..cec53dca43b 100644
--- a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
@@ -21,7 +21,7 @@ name = "Microsoft 365 Global Administrator Role Assigned"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Global Administrator Role Assigned
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
index 830d693b3ac..8d69c1820e1 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Teams Custom Application Interaction Allowed"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Teams Custom Application Interaction Allowed
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
index 6698454c34a..fbf21436b19 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
@@ -25,7 +25,7 @@ name = "Microsoft 365 Teams External Access Enabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Teams External Access Enabled
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
index a4a4bcbe761..fe3afbfeb4a 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
@@ -24,7 +24,7 @@ name = "Microsoft 365 Teams Guest Access Enabled"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft 365 Teams Guest Access Enabled
 
diff --git a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
index bf5f8f2bf76..72015a09381 100644
--- a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
+++ b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
@@ -17,7 +17,7 @@ name = "New or Modified Federation Domain"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 New or Modified Federation Domain
 
diff --git a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
index 5678e743fdd..4fb816735a9 100644
--- a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
+++ b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
@@ -54,7 +54,7 @@ event.dataset: okta.system
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials
 
diff --git a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
index a3e7bef86ba..6e2b5c49b2c 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
@@ -25,7 +25,7 @@ name = "Attempt to Delete an Okta Application"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Delete an Okta Application
 
diff --git a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
index 05c6149972e..16ae233867b 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
@@ -25,7 +25,7 @@ name = "Attempt to Modify an Okta Application"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Modify an Okta Application
 
diff --git a/rules/integrations/okta/impact_possible_okta_dos_attack.toml b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
index 203da221f31..573fd04c81b 100644
--- a/rules/integrations/okta/impact_possible_okta_dos_attack.toml
+++ b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
@@ -19,7 +19,7 @@ name = "Possible Okta DoS Attack"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Possible Okta DoS Attack
 
diff --git a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
index 0b6e86b3b9b..303cda49853 100644
--- a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
+++ b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
@@ -16,7 +16,7 @@ name = "Okta FastPass Phishing Detection"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Okta FastPass Phishing Detection
 
diff --git a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
index 8e66bf1f037..d3d5f4b3c50 100644
--- a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
+++ b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
@@ -16,7 +16,7 @@ name = "Unauthorized Access to an Okta Application"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unauthorized Access to an Okta Application
 
diff --git a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
index 8d3ccc843e3..50d00ce27e8 100644
--- a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
+++ b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
@@ -43,7 +43,7 @@ event.dataset: "okta.system"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Successful Application SSO from Rare Unknown Client Device
 
diff --git a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
index e106d1ee33a..0118eb95674 100644
--- a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
+++ b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
@@ -20,7 +20,7 @@ name = "Suspicious Activity Reported by Okta User"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Activity Reported by Okta User
 
diff --git a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
index a5a28d81aca..bed8ce7c0d2 100644
--- a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
+++ b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
@@ -23,7 +23,7 @@ name = "Multiple Okta Sessions Detected for a Single User"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Multiple Okta Sessions Detected for a Single User
 
diff --git a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
index 4d714f8edb2..57dad5b7d14 100644
--- a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
+++ b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
@@ -26,7 +26,7 @@ name = "Administrator Privileges Assigned to an Okta Group"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Administrator Privileges Assigned to an Okta Group
 
diff --git a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
index 7a466c94fe8..2328e248ee4 100644
--- a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
+++ b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
@@ -26,7 +26,7 @@ name = "Administrator Role Assigned to an Okta User"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Administrator Role Assigned to an Okta User
 
diff --git a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
index 99b2c26aea0..cf94aa3cc04 100644
--- a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
+++ b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
@@ -26,7 +26,7 @@ name = "Attempt to Create Okta API Token"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Create Okta API Token
 
diff --git a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
index 93af9c676ae..085df791309 100644
--- a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
+++ b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
@@ -26,7 +26,7 @@ name = "Attempt to Reset MFA Factors for an Okta User Account"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Reset MFA Factors for an Okta User Account
 
diff --git a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
index 78582f3a80a..78c612b0c10 100644
--- a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
+++ b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
@@ -25,7 +25,7 @@ name = "Modification or Removal of an Okta Application Sign-On Policy"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 or Removal of an Okta Application Sign-On Policy
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
index caffb0df060..47ea1fc13ac 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
@@ -29,7 +29,7 @@ risk_score = 21
 rule_id = "56004189-4e69-4a39-b4a9-195329d226e9"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -60,7 +60,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process Spawned by a Host
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
index 814d60c96cd..491f85513b0 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
@@ -29,7 +29,7 @@ risk_score = 21
 rule_id = "ea09ff26-3902-4c53-bb8e-24b7a5d029dd"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -60,7 +60,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process Spawned by a Parent Process
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
index 529f4d0e6ce..e45bf61b6a3 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
@@ -30,7 +30,7 @@ risk_score = 21
 rule_id = "40155ee4-1e6a-4e4d-a63b-e8ba16980cfb"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -61,7 +61,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process Spawned by a User
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
index 88951083683..38504b26ddf 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
@@ -27,7 +27,7 @@ risk_score = 73
 rule_id = "994e40aa-8c85-43de-825e-15f665375ee8"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -65,7 +65,7 @@ blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
index a518558c9d1..16967dc7002 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
@@ -25,7 +25,7 @@ risk_score = 21
 rule_id = "13e908b9-7bf0-4235-abc9-b5deb500d0ad"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -63,7 +63,7 @@ blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Machine Learning Detected a Suspicious Windows Event with a Low Malicious Probability Score
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
index 0b38e523181..f2325ae67f0 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
@@ -31,7 +31,7 @@ risk_score = 21
 rule_id = "bdfebe11-e169-42e3-b344-c5d2015533d3"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -60,7 +60,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Windows Process Cluster Spawned by a Host
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
index 5ab53fcfe3d..be53420fc55 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
@@ -31,7 +31,7 @@ risk_score = 21
 rule_id = "f5d9d36d-7c30-4cdb-a856-9f653c13d4e0"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -62,7 +62,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Windows Process Cluster Spawned by a Parent Process
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
index d289a466c6f..aec99bb3320 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
@@ -31,7 +31,7 @@ risk_score = 21
 rule_id = "1224da6c-0326-4b4f-8454-68cdc5ae542b"
 setup = """## Setup
 
-The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.  
+The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.
 
 ### LotL Attack Detection Setup
 The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
@@ -62,7 +62,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Windows Process Cluster Spawned by a User
 
diff --git a/rules/linux/collection_linux_clipboard_activity.toml b/rules/linux/collection_linux_clipboard_activity.toml
index 026edae82d9..95bba749665 100644
--- a/rules/linux/collection_linux_clipboard_activity.toml
+++ b/rules/linux/collection_linux_clipboard_activity.toml
@@ -39,7 +39,7 @@ not process.parent.name:("bwrap" or "micro")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Linux Clipboard Activity Detected
 
diff --git a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
index 3ace9cf2077..dfb3c49e931 100644
--- a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
+++ b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
@@ -35,7 +35,7 @@ host.os.type: "linux" and event.category: "process" and process.name: "aws" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS CLI Command with Custom Endpoint URL
 
diff --git a/rules/linux/command_and_control_curl_socks_proxy_detected.toml b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
index 7d3c4d99ca3..9b2a1ef4951 100644
--- a/rules/linux/command_and_control_curl_socks_proxy_detected.toml
+++ b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
@@ -7,7 +7,7 @@ updated_date = "2025/01/10"
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects the use of the `curl` command-line tool with SOCKS proxy options, launched from an unusual parent 
+This rule detects the use of the `curl` command-line tool with SOCKS proxy options, launched from an unusual parent
 process. Attackers may use `curl` to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate
 data or communicate with C2 servers.
 """
@@ -75,14 +75,14 @@ process.name == "curl" and (
   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 ) and (
   process.args like ("--socks5-hostname", "--proxy", "--preproxy", "socks5*") or
-  process.args == "-x" or 
+  process.args == "-x" or
   process.env_vars like ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Activity from Unusual Parent
 
diff --git a/rules/linux/command_and_control_ip_forwarding_activity.toml b/rules/linux/command_and_control_ip_forwarding_activity.toml
index d22f4c5d8ef..bf8de5f97da 100644
--- a/rules/linux/command_and_control_ip_forwarding_activity.toml
+++ b/rules/linux/command_and_control_ip_forwarding_activity.toml
@@ -48,7 +48,7 @@ process.parent.executable != null and process.command_line like (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 IPv4/IPv6 Forwarding Activity
 
diff --git a/rules/linux/command_and_control_linux_kworker_netcon.toml b/rules/linux/command_and_control_linux_kworker_netcon.toml
index 8ec9f67cd27..741f5204606 100644
--- a/rules/linux/command_and_control_linux_kworker_netcon.toml
+++ b/rules/linux/command_and_control_linux_kworker_netcon.toml
@@ -57,7 +57,7 @@ timestamp_override = "event.ingested"
 type = "new_terms"
 
 query = '''
-host.os.type:linux and event.category:network and event.action:(connection_attempted or connection_accepted) and 
+host.os.type:linux and event.category:network and event.action:(connection_attempted or connection_accepted) and
 process.name:kworker* and not destination.ip:(
   10.0.0.0/8 or
   127.0.0.0/8 or
@@ -73,7 +73,7 @@ process.name:kworker* and not destination.ip:(
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Activity Detected via Kworker
 
diff --git a/rules/linux/credential_access_collection_sensitive_files.toml b/rules/linux/credential_access_collection_sensitive_files.toml
index 43cf85a3c34..477d208bfc1 100644
--- a/rules/linux/credential_access_collection_sensitive_files.toml
+++ b/rules/linux/credential_access_collection_sensitive_files.toml
@@ -109,7 +109,7 @@ event.category:process and host.os.type:linux and event.type:start and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Sensitive Files Compression
 
diff --git a/rules/linux/credential_access_credential_dumping.toml b/rules/linux/credential_access_credential_dumping.toml
index f7ae74be81c..2f1a9b806e2 100644
--- a/rules/linux/credential_access_credential_dumping.toml
+++ b/rules/linux/credential_access_credential_dumping.toml
@@ -69,7 +69,7 @@ process.name == "unshadow" and process.args_count >= 3
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Linux Credential Dumping via Unshadow
 
diff --git a/rules/linux/credential_access_gdb_init_process_hooking.toml b/rules/linux/credential_access_gdb_init_process_hooking.toml
index 5bd4090db10..4ce1847574a 100644
--- a/rules/linux/credential_access_gdb_init_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_init_process_hooking.toml
@@ -61,13 +61,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Linux init (PID 1) Secret Dump via GDB
 
diff --git a/rules/linux/credential_access_gdb_process_hooking.toml b/rules/linux/credential_access_gdb_process_hooking.toml
index 2636a3a4f98..733abc8e5cc 100644
--- a/rules/linux/credential_access_gdb_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_process_hooking.toml
@@ -38,14 +38,14 @@ type = "eql"
 
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
- and process.name == "gdb" and process.args in ("--pid", "-p") and 
+ and process.name == "gdb" and process.args in ("--pid", "-p") and
 /* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
 process.args != "1"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Linux Process Hooking via GDB
 
diff --git a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
index 0a91adfb2a8..c204e3c1610 100644
--- a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
+++ b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
@@ -55,7 +55,7 @@ type = "eql"
 
 query = '''
 sequence by host.id, process.parent.executable, user.id with maxspan=1s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "su" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "su" and
    not process.parent.name in (
      "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "clickhouse-server", "ma", "gitlab-runner",
      "updatedb.findutils", "cron", "perl", "sudo", "java", "cloud-app-identify", "ambari-sudo.sh"
@@ -65,7 +65,7 @@ sequence by host.id, process.parent.executable, user.id with maxspan=1s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Linux Local Account Brute Force Detected
 
diff --git a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
index f07dd8fda75..2a4535a4b8b 100644
--- a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
@@ -78,7 +78,7 @@ sequence by host.id, auditd.data.addr, related.user with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Successful Linux FTP Brute Force Attack Detected
 
diff --git a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
index 50aec20ada2..03a188a1017 100644
--- a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
@@ -76,7 +76,7 @@ sequence by host.id, related.user with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Successful Linux RDP Brute Force Attack Detected
 
diff --git a/rules/linux/credential_access_proc_credential_dumping.toml b/rules/linux/credential_access_proc_credential_dumping.toml
index e9e86e781aa..0526af9b514 100644
--- a/rules/linux/credential_access_proc_credential_dumping.toml
+++ b/rules/linux/credential_access_proc_credential_dumping.toml
@@ -73,7 +73,7 @@ sequence by host.id, process.parent.name with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Linux Credential Dumping via Proc Filesystem
 
diff --git a/rules/linux/credential_access_ssh_backdoor_log.toml b/rules/linux/credential_access_ssh_backdoor_log.toml
index d5ff14b489a..7f88aa6724d 100644
--- a/rules/linux/credential_access_ssh_backdoor_log.toml
+++ b/rules/linux/credential_access_ssh_backdoor_log.toml
@@ -114,7 +114,7 @@ file where host.os.type == "linux" and event.type == "change" and process.execut
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential OpenSSH Backdoor Logging Activity
 
diff --git a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
index e34757ffb3d..1bdf501b9bd 100644
--- a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
+++ b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
@@ -65,7 +65,7 @@ sequence by host.id,  process.parent.entity_id with maxspan=1s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Instance Metadata Service (IMDS) API Request
 
diff --git a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
index 7cc08446c53..4a05e011304 100644
--- a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
+++ b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
@@ -44,7 +44,7 @@ process.name == "setfacl" and not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Access Control List Modification via setfacl
 
diff --git a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
index 8a51b79be43..6b6960c7882 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
@@ -69,7 +69,7 @@ process.args in ("auditd", "auditd.service")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Disable Auditd Service
 
diff --git a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
index df8a5967c54..eb1d68943ec 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
@@ -80,7 +80,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Disable IPTables or Firewall
 
diff --git a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
index afa53a4a986..634894339c0 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
@@ -81,7 +81,7 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event",
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Disable Syslog Service
 
diff --git a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
index 22399510f46..dd797d137bf 100644
--- a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
+++ b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
@@ -83,7 +83,7 @@ not process.args in ("--help", "--version")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Base16 or Base32 Encoding/Decoding Activity
 
diff --git a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
index be0c8087b9d..df6462bcd16 100644
--- a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
+++ b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
@@ -92,13 +92,13 @@ file.Ext.original.path : (
   process.executable : ("/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*") or
   process.executable == null or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 System Binary Moved or Copied
 
diff --git a/rules/linux/defense_evasion_chattr_immutable_file.toml b/rules/linux/defense_evasion_chattr_immutable_file.toml
index cf939f21519..7168ec9cd76 100644
--- a/rules/linux/defense_evasion_chattr_immutable_file.toml
+++ b/rules/linux/defense_evasion_chattr_immutable_file.toml
@@ -87,7 +87,7 @@ process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and n
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File made Immutable by Chattr
 
diff --git a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
index 5a92e1e3792..b614a0c5179 100644
--- a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
+++ b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
@@ -66,7 +66,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Clear Kernel Ring Buffer
 
diff --git a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
index 339bbe54094..de653e9127a 100644
--- a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
+++ b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
@@ -39,7 +39,7 @@ file where host.os.type == "linux" and event.type == "creation" and process.name
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Hidden Files and Directories via Hidden Flag
 
diff --git a/rules/linux/defense_evasion_directory_creation_in_bin.toml b/rules/linux/defense_evasion_directory_creation_in_bin.toml
index 3721241207a..012a8796bb4 100644
--- a/rules/linux/defense_evasion_directory_creation_in_bin.toml
+++ b/rules/linux/defense_evasion_directory_creation_in_bin.toml
@@ -10,7 +10,7 @@ updated_date = "2025/01/10"
 author = ["Elastic"]
 description = """
 This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary
-files that are required for the system to function properly. The creation of directories in this location could be an 
+files that are required for the system to function properly. The creation of directories in this location could be an
 attempt to hide malicious files or executables, as these /bin directories usually just contain binaries.
 """
 from = "now-9m"
@@ -68,7 +68,7 @@ not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Directory Creation in /bin directory
 
diff --git a/rules/linux/defense_evasion_disable_apparmor_attempt.toml b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
index a5ca2b34d3e..77800cde4dd 100644
--- a/rules/linux/defense_evasion_disable_apparmor_attempt.toml
+++ b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
@@ -64,7 +64,7 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  (
   (process.name == "systemctl" and process.args in ("stop", "disable", "kill") and process.args in ("apparmor", "apparmor.service")) or
-  (process.name == "service" and process.args == "apparmor" and process.args == "stop") or 
+  (process.name == "service" and process.args == "apparmor" and process.args == "stop") or
   (process.name == "chkconfig" and process.args == "apparmor" and process.args == "off") or
   (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/")
 )
@@ -72,7 +72,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Disabling of AppArmor
 
diff --git a/rules/linux/defense_evasion_disable_selinux_attempt.toml b/rules/linux/defense_evasion_disable_selinux_attempt.toml
index 543966a140a..dea794c38d8 100644
--- a/rules/linux/defense_evasion_disable_selinux_attempt.toml
+++ b/rules/linux/defense_evasion_disable_selinux_attempt.toml
@@ -80,7 +80,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Disabling of SELinux
 
diff --git a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
index 05fce5c3b7d..3c305c0be1b 100644
--- a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
+++ b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
@@ -64,7 +64,7 @@ file where host.os.type == "linux" and event.type != "deletion" and file.path ==
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Defense Evasion via Doas
 
diff --git a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
index a0b6027a4e1..28c7e8c4f1b 100644
--- a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
+++ b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
@@ -83,7 +83,7 @@ not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Dynamic Linker Creation or Modification
 
diff --git a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
index 81ee59285f9..cd2130276bc 100644
--- a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
+++ b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
@@ -73,7 +73,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 ESXI Timestomping using Touch Command
 
diff --git a/rules/linux/defense_evasion_file_deletion_via_shred.toml b/rules/linux/defense_evasion_file_deletion_via_shred.toml
index 7989ced7ec0..ae723c77c6f 100644
--- a/rules/linux/defense_evasion_file_deletion_via_shred.toml
+++ b/rules/linux/defense_evasion_file_deletion_via_shred.toml
@@ -67,7 +67,7 @@ process where host.os.type == "linux" and event.type == "start" and process.name
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File Deletion via Shred
 
diff --git a/rules/linux/defense_evasion_file_mod_writable_dir.toml b/rules/linux/defense_evasion_file_mod_writable_dir.toml
index 13646f48834..d3f15f06e23 100644
--- a/rules/linux/defense_evasion_file_mod_writable_dir.toml
+++ b/rules/linux/defense_evasion_file_mod_writable_dir.toml
@@ -79,7 +79,7 @@ not process.parent.name:(apt-key or update-motd-updates-available or apt-get)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File Permission Modification in Writable Directory
 
diff --git a/rules/linux/defense_evasion_hex_payload_execution.toml b/rules/linux/defense_evasion_hex_payload_execution.toml
index becce22f8b1..dd7a89f7cdd 100644
--- a/rules/linux/defense_evasion_hex_payload_execution.toml
+++ b/rules/linux/defense_evasion_hex_payload_execution.toml
@@ -73,7 +73,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Hex Payload Execution
 
diff --git a/rules/linux/defense_evasion_hidden_directory_creation.toml b/rules/linux/defense_evasion_hidden_directory_creation.toml
index 8418391f3e1..a7c1dec8061 100644
--- a/rules/linux/defense_evasion_hidden_directory_creation.toml
+++ b/rules/linux/defense_evasion_hidden_directory_creation.toml
@@ -79,7 +79,7 @@ process.name == "mkdir" and process.parent.executable like (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Hidden Directory Creation via Unusual Parent
 
diff --git a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
index efd76398391..e0f48315920 100644
--- a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
+++ b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
@@ -87,7 +87,7 @@ not process.name in (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation of Hidden Files and Directories via CommandLine
 
diff --git a/rules/linux/defense_evasion_hidden_shared_object.toml b/rules/linux/defense_evasion_hidden_shared_object.toml
index 8bb847f64f2..e1f9027057b 100644
--- a/rules/linux/defense_evasion_hidden_shared_object.toml
+++ b/rules/linux/defense_evasion_hidden_shared_object.toml
@@ -81,7 +81,7 @@ not process.name == "dockerd"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation of Hidden Shared Object File
 
diff --git a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
index 43691835f98..36f0dd8f1c1 100644
--- a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
+++ b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
@@ -59,7 +59,7 @@ event.category:process and host.os.type:linux and event.type:start and event.act
    daemon or bin or sys or sync or games or man or mail or news or uucp or proxy or backup or list or irc
    or gnats or _apt or Debian-exim or systemd-timesync or messagebus or uuidd or _chrony or sshd or
    gamer or shutdown or halt or dbus or polkitd or rtkit or pipewire or tcpdump or clevis or
-   libstoreagemgmt or geoclue or tss or sssd or gnome-initial-setup or pesign or dnsmasq or chrony 
+   libstoreagemgmt or geoclue or tss or sssd or gnome-initial-setup or pesign or dnsmasq or chrony
 ) and process.interactive:true and process.parent.executable:* and not (
   process.parent.name:(
     apt-key or apt-config or gpgv or gpgconf or man-db.postinst or sendmail or rpm or nullmailer-inject
@@ -72,7 +72,7 @@ event.category:process and host.os.type:linux and event.type:start and event.act
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Interactive Shell Launched from System User
 
diff --git a/rules/linux/defense_evasion_kernel_module_removal.toml b/rules/linux/defense_evasion_kernel_module_removal.toml
index fb12c921d8f..b85f49cf262 100644
--- a/rules/linux/defense_evasion_kernel_module_removal.toml
+++ b/rules/linux/defense_evasion_kernel_module_removal.toml
@@ -77,7 +77,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kernel Module Removal
 
diff --git a/rules/linux/defense_evasion_kthreadd_masquerading.toml b/rules/linux/defense_evasion_kthreadd_masquerading.toml
index bd3a8116434..46260ff6bc5 100644
--- a/rules/linux/defense_evasion_kthreadd_masquerading.toml
+++ b/rules/linux/defense_evasion_kthreadd_masquerading.toml
@@ -68,7 +68,7 @@ process.name : ("kworker*", "kthread*") and process.executable != null
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Executable Masquerading as Kernel Process
 
diff --git a/rules/linux/defense_evasion_ld_so_creation.toml b/rules/linux/defense_evasion_ld_so_creation.toml
index 0cee4f4a0ab..2dc3ae25145 100644
--- a/rules/linux/defense_evasion_ld_so_creation.toml
+++ b/rules/linux/defense_evasion_ld_so_creation.toml
@@ -67,7 +67,7 @@ not process.name in ("dockerd", "yum", "dnf", "microdnf", "pacman")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Dynamic Linker (ld.so) Creation
 
diff --git a/rules/linux/defense_evasion_log_files_deleted.toml b/rules/linux/defense_evasion_log_files_deleted.toml
index 1f258e11a0a..c61f973818c 100644
--- a/rules/linux/defense_evasion_log_files_deleted.toml
+++ b/rules/linux/defense_evasion_log_files_deleted.toml
@@ -98,7 +98,7 @@ file where host.os.type == "linux" and event.type == "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 System Log File Deletion
 
diff --git a/rules/linux/defense_evasion_mount_execution.toml b/rules/linux/defense_evasion_mount_execution.toml
index 321677f4be1..24904584dbf 100644
--- a/rules/linux/defense_evasion_mount_execution.toml
+++ b/rules/linux/defense_evasion_mount_execution.toml
@@ -72,7 +72,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Hidden Process via Mount Hidepid
 
diff --git a/rules/linux/defense_evasion_potential_proot_exploits.toml b/rules/linux/defense_evasion_potential_proot_exploits.toml
index 37a3fa35661..4482102970a 100644
--- a/rules/linux/defense_evasion_potential_proot_exploits.toml
+++ b/rules/linux/defense_evasion_potential_proot_exploits.toml
@@ -73,7 +73,7 @@ process.parent.name == "proot"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Defense Evasion via PRoot
 
diff --git a/rules/linux/defense_evasion_rename_esxi_files.toml b/rules/linux/defense_evasion_rename_esxi_files.toml
index 464795fc2cb..32d4fc64605 100644
--- a/rules/linux/defense_evasion_rename_esxi_files.toml
+++ b/rules/linux/defense_evasion_rename_esxi_files.toml
@@ -65,7 +65,7 @@ and not file.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp",
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Renaming of ESXI Files
 
diff --git a/rules/linux/defense_evasion_rename_esxi_index_file.toml b/rules/linux/defense_evasion_rename_esxi_index_file.toml
index f8f22fb3ac7..308fa865963 100644
--- a/rules/linux/defense_evasion_rename_esxi_index_file.toml
+++ b/rules/linux/defense_evasion_rename_esxi_index_file.toml
@@ -64,7 +64,7 @@ file.Ext.original.path : "/usr/lib/vmware/*"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Renaming of ESXI index.html File
 
diff --git a/rules/linux/defense_evasion_root_certificate_installation.toml b/rules/linux/defense_evasion_root_certificate_installation.toml
index 6ba56e5ca95..997a4466dfc 100644
--- a/rules/linux/defense_evasion_root_certificate_installation.toml
+++ b/rules/linux/defense_evasion_root_certificate_installation.toml
@@ -73,7 +73,7 @@ process.name in ("update-ca-trust", "update-ca-certificates") and not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Root Certificate Installation
 
diff --git a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
index 3b1a3fbcc78..810f587e6a3 100644
--- a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
+++ b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
@@ -65,7 +65,7 @@ and file.path : "/etc/selinux/config"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SELinux Configuration Creation or Renaming
 
diff --git a/rules/linux/defense_evasion_ssl_certificate_deletion.toml b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
index c3bba78eae9..7b38a52df1d 100644
--- a/rules/linux/defense_evasion_ssl_certificate_deletion.toml
+++ b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
@@ -64,7 +64,7 @@ file.extension in ("pem", "crt") and not process.name in ("dockerd", "pacman")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SSL Certificate Deletion
 SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity.
diff --git a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
index e50e1d9f09f..35fcf7b4f53 100644
--- a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
+++ b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
@@ -35,7 +35,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
   process.parent.name in ("screen", "tmux") and process.name like (
     "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*",
     "openssl", "telnet", "wget", "curl", "id"
@@ -44,7 +44,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potentially Suspicious Process Started via tmux or screen
 
diff --git a/rules/linux/defense_evasion_unusual_preload_env_vars.toml b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
index 725077a44dc..9a372cb16a0 100644
--- a/rules/linux/defense_evasion_unusual_preload_env_vars.toml
+++ b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
@@ -73,7 +73,7 @@ event.category:process and host.os.type:linux and event.type:start and event.act
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Preload Environment Variable Process Execution
 
diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml
index bcd8322402a..be71bb38643 100644
--- a/rules/linux/discovery_dynamic_linker_via_od.toml
+++ b/rules/linux/discovery_dynamic_linker_via_od.toml
@@ -73,7 +73,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Dynamic Linker Discovery via od
 
diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml
index 40215439bb0..121356c35ee 100644
--- a/rules/linux/discovery_esxi_software_via_find.toml
+++ b/rules/linux/discovery_esxi_software_via_find.toml
@@ -65,13 +65,13 @@ type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "executed", "process_started") and
-  process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and 
+  process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and
   not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 ESXI Discovery via Find
 
diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml
index 03e20db0f7b..ef4c8aa531d 100644
--- a/rules/linux/discovery_esxi_software_via_grep.toml
+++ b/rules/linux/discovery_esxi_software_via_grep.toml
@@ -72,7 +72,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 ESXI Discovery via Grep
 
diff --git a/rules/linux/discovery_kernel_module_enumeration.toml b/rules/linux/discovery_kernel_module_enumeration.toml
index d9c2f985ffa..7d4774a22d3 100644
--- a/rules/linux/discovery_kernel_module_enumeration.toml
+++ b/rules/linux/discovery_kernel_module_enumeration.toml
@@ -63,8 +63,8 @@ type = "new_terms"
 
 query = '''
 event.category:process and host.os.type:linux and event.type:start and event.action:(exec or exec_event) and (
- (process.name:(lsmod or modinfo)) or 
- (process.name:kmod and process.args:list) or 
+ (process.name:(lsmod or modinfo)) or
+ (process.name:kmod and process.args:list) or
  (process.name:depmod and process.args:(--all or -a))
 ) and
 not (
@@ -78,7 +78,7 @@ not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Enumeration of Kernel Modules
 
diff --git a/rules/linux/discovery_linux_hping_activity.toml b/rules/linux/discovery_linux_hping_activity.toml
index e978852c1f7..aaf4ed07a01 100644
--- a/rules/linux/discovery_linux_hping_activity.toml
+++ b/rules/linux/discovery_linux_hping_activity.toml
@@ -86,7 +86,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Hping Process Activity
 
diff --git a/rules/linux/discovery_linux_nping_activity.toml b/rules/linux/discovery_linux_nping_activity.toml
index b1a6e1627ad..b6068c6aff3 100644
--- a/rules/linux/discovery_linux_nping_activity.toml
+++ b/rules/linux/discovery_linux_nping_activity.toml
@@ -86,7 +86,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Nping Process Activity
 
diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml
index 825d5c74454..13748e5efde 100644
--- a/rules/linux/discovery_pam_version_discovery.toml
+++ b/rules/linux/discovery_pam_version_discovery.toml
@@ -74,7 +74,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 (PAM) Version Discovery
 
diff --git a/rules/linux/discovery_ping_sweep_detected.toml b/rules/linux/discovery_ping_sweep_detected.toml
index 56eff74834c..8ed9a72cdf4 100644
--- a/rules/linux/discovery_ping_sweep_detected.toml
+++ b/rules/linux/discovery_ping_sweep_detected.toml
@@ -64,7 +64,7 @@ event.type:start and process.name:(ping or nping or hping or hping2 or hping3 or
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Network Scan Executed From Host
 
diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml
index 32c338e367e..82a0ad55fb9 100644
--- a/rules/linux/discovery_private_key_password_searching_activity.toml
+++ b/rules/linux/discovery_private_key_password_searching_activity.toml
@@ -66,7 +66,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Private Key Searching Activity
 
diff --git a/rules/linux/discovery_proc_maps_read.toml b/rules/linux/discovery_proc_maps_read.toml
index f723c431069..af471cbf7a4 100644
--- a/rules/linux/discovery_proc_maps_read.toml
+++ b/rules/linux/discovery_proc_maps_read.toml
@@ -65,7 +65,7 @@ process.name in ("cat", "grep") and process.args : "/proc/*/maps" and process.en
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious /proc/maps Discovery
 
diff --git a/rules/linux/discovery_process_capabilities.toml b/rules/linux/discovery_process_capabilities.toml
index d7c4f6674f1..83b1f104011 100644
--- a/rules/linux/discovery_process_capabilities.toml
+++ b/rules/linux/discovery_process_capabilities.toml
@@ -65,7 +65,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Capability Enumeration
 
diff --git a/rules/linux/discovery_pspy_process_monitoring_detected.toml b/rules/linux/discovery_pspy_process_monitoring_detected.toml
index 1af81c74158..d8e0a811cc4 100644
--- a/rules/linux/discovery_pspy_process_monitoring_detected.toml
+++ b/rules/linux/discovery_pspy_process_monitoring_detected.toml
@@ -63,7 +63,7 @@ sequence by process.pid, host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Pspy Process Monitoring Detected
 
diff --git a/rules/linux/discovery_security_file_access_via_common_utility.toml b/rules/linux/discovery_security_file_access_via_common_utility.toml
index 0827780f6df..49ce45bd63b 100644
--- a/rules/linux/discovery_security_file_access_via_common_utility.toml
+++ b/rules/linux/discovery_security_file_access_via_common_utility.toml
@@ -72,7 +72,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Security File Access via Common Utilities
 
diff --git a/rules/linux/discovery_sudo_allowed_command_enumeration.toml b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
index 3fb1447da08..e2b6e041ef7 100644
--- a/rules/linux/discovery_sudo_allowed_command_enumeration.toml
+++ b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
@@ -61,13 +61,13 @@ type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "sudo" and process.args == "-l" and
-  process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
+  process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
   not process.args == "dpkg"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Sudo Command Enumeration Detected
 
diff --git a/rules/linux/discovery_suid_sguid_enumeration.toml b/rules/linux/discovery_suid_sguid_enumeration.toml
index 810fecf6686..a7570e0f87a 100644
--- a/rules/linux/discovery_suid_sguid_enumeration.toml
+++ b/rules/linux/discovery_suid_sguid_enumeration.toml
@@ -59,18 +59,18 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 process.name == "find" and process.args : "-perm" and process.args : (
   "/6000", "-6000", "/4000", "-4000", "/2000", "-2000", "/u=s", "-u=s", "/g=s", "-g=s", "/u=s,g=s", "/g=s,u=s"
 ) and not (
-  user.Ext.real.id == "0" or group.Ext.real.id == "0" or process.args_count >= 12 or 
+  user.Ext.real.id == "0" or group.Ext.real.id == "0" or process.args_count >= 12 or
   (process.args : "/usr/bin/pkexec" and process.args : "-xdev" and process.args_count == 7)
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SUID/SGUID Enumeration Detected
 
diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml
index cc556ba4db0..e083438be4c 100644
--- a/rules/linux/discovery_suspicious_memory_grep_activity.toml
+++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml
@@ -42,7 +42,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Memory grep Activity
 
diff --git a/rules/linux/discovery_suspicious_which_command_execution.toml b/rules/linux/discovery_suspicious_which_command_execution.toml
index bcaa43b910d..72d1f7b8608 100644
--- a/rules/linux/discovery_suspicious_which_command_execution.toml
+++ b/rules/linux/discovery_suspicious_which_command_execution.toml
@@ -34,7 +34,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start") and 
+  event.action in ("exec", "exec_event", "start") and
   process.name == "which" and process.args_count >= 10 and not (
     process.parent.name == "jem" or
     process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or
@@ -42,14 +42,14 @@ process where host.os.type == "linux" and event.type == "start" and
   )
 
 /* potential tuning if rule would turn out to be noisy
-and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and 
+and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and
 process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 */
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious which Enumeration
 
diff --git a/rules/linux/discovery_unusual_user_enumeration_via_id.toml b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
index 379b03f4a52..9feea1a94fc 100644
--- a/rules/linux/discovery_unusual_user_enumeration_via_id.toml
+++ b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
@@ -55,14 +55,14 @@ type = "eql"
 
 query = '''
 sequence by host.id, process.parent.entity_id with maxspan=1s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
-   process.name == "id" and process.args_count == 2 and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+   process.name == "id" and process.args_count == 2 and
    not (process.parent.name == "rpm" or process.parent.args : "/var/tmp/rpm-tmp*")] with runs=20
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual User Privilege Enumeration via id
 
diff --git a/rules/linux/discovery_virtual_machine_fingerprinting.toml b/rules/linux/discovery_virtual_machine_fingerprinting.toml
index b3683e3aff7..2e95e8ad739 100644
--- a/rules/linux/discovery_virtual_machine_fingerprinting.toml
+++ b/rules/linux/discovery_virtual_machine_fingerprinting.toml
@@ -85,7 +85,7 @@ event.category:process and host.os.type:linux and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Virtual Machine Fingerprinting
 
diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml
index 0cac6758ff0..d4f0fb487c2 100644
--- a/rules/linux/discovery_yum_dnf_plugin_detection.toml
+++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml
@@ -71,7 +71,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Yum/DNF Plugin Status Discovery
 
diff --git a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
index 31cc81b317c..03554de5467 100644
--- a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
+++ b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
@@ -76,9 +76,9 @@ tags = [
 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" 
+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*") or 
+  process.args like ("--socks5-hostname", "--proxy", "--preproxy", "socks5*") or
   process.env_vars like ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*")
 ) and length(process.command_line) > 255 and not (
   process.parent.name in ("cf-agent", "agent-run", "agent-check", "rudder", "agent-inventory", "cf-execd") or
@@ -89,7 +89,7 @@ and (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential curl CVE-2023-38545 Exploitation
 
diff --git a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
index 0958a57f9ee..289d1054895 100644
--- a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
+++ b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
@@ -47,7 +47,7 @@ sequence by host.id with maxspan=3s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Egress Connection from Entrypoint in Container
 
diff --git a/rules/linux/execution_file_execution_followed_by_deletion.toml b/rules/linux/execution_file_execution_followed_by_deletion.toml
index 9793c814549..eee7781d252 100644
--- a/rules/linux/execution_file_execution_followed_by_deletion.toml
+++ b/rules/linux/execution_file_execution_followed_by_deletion.toml
@@ -54,24 +54,24 @@ tags = [
 type = "eql"
 query = '''
 sequence by host.id, user.id with maxspan=1m
-  [file where host.os.type == "linux" and event.action == "creation" and 
-   process.name in ("curl", "wget", "fetch", "ftp", "sftp", "scp", "rsync", "ld") and 
+  [file where host.os.type == "linux" and event.action == "creation" and
+   process.name in ("curl", "wget", "fetch", "ftp", "sftp", "scp", "rsync", "ld") and
    file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*",
      "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
    not process.parent.executable like (
      "/tmp/VeeamApp*", "/tmp/rajh/spack-stage/*", "plz-out/bin/vault/bridge/test/e2e/base/bridge-dev",
-     "/usr/bin/ranlib", "/usr/bin/ar", "plz-out/bin/vault/bridge/test/e2e/base/local-k8s"  
+     "/usr/bin/ranlib", "/usr/bin/ar", "plz-out/bin/vault/bridge/test/e2e/base/local-k8s"
    )] by process.name
-  [file where host.os.type == "linux" and event.action == "deletion" and not process.name in ("rm", "ld") and 
+  [file where host.os.type == "linux" and event.action == "deletion" and not process.name in ("rm", "ld") and
    file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*",
      "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File Creation, Execution and Self-Deletion in Suspicious Directory
 
diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml
index 5019e5be9ec..8b16f2b6c8a 100644
--- a/rules/linux/execution_interpreter_tty_upgrade.toml
+++ b/rules/linux/execution_interpreter_tty_upgrade.toml
@@ -71,7 +71,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Upgrade of Non-interactive Shell
 
diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml
index 36b6dd20033..afbd8fe315f 100644
--- a/rules/linux/execution_nc_listener_via_rlwrap.toml
+++ b/rules/linux/execution_nc_listener_via_rlwrap.toml
@@ -69,14 +69,14 @@ type = "eql"
 
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
   process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and
   process.args : "*l*" and process.args_count >= 4
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Netcat Listener Established via rlwrap
 
diff --git a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
index b2a0eb82410..e39c69461c4 100644
--- a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
+++ b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
@@ -64,7 +64,7 @@ sample by host.id, process.pid, process.name
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Connection from Binary with RWX Memory Region
 
diff --git a/rules/linux/execution_network_event_post_compilation.toml b/rules/linux/execution_network_event_post_compilation.toml
index 0883155d452..06d4633f0bc 100644
--- a/rules/linux/execution_network_event_post_compilation.toml
+++ b/rules/linux/execution_network_event_post_compilation.toml
@@ -54,7 +54,7 @@ tags = [
 type = "eql"
 query = '''
 sequence by host.id with maxspan=1m
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.name in ("gcc", "g++", "cc")] by process.args
   [file where host.os.type == "linux" and event.action == "creation" and process.name == "ld"] by file.name
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec"] by process.name
@@ -66,7 +66,7 @@ sequence by host.id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Connection via Recently Compiled Executable
 
diff --git a/rules/linux/execution_perl_tty_shell.toml b/rules/linux/execution_perl_tty_shell.toml
index 2aefc2e52ef..891bb73fa21 100644
--- a/rules/linux/execution_perl_tty_shell.toml
+++ b/rules/linux/execution_perl_tty_shell.toml
@@ -73,7 +73,7 @@ event.category:process and host.os.type:linux and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Interactive Terminal Spawned via Perl
 
diff --git a/rules/linux/execution_potential_hack_tool_executed.toml b/rules/linux/execution_potential_hack_tool_executed.toml
index 1f10787bfc8..426d7dbfe65 100644
--- a/rules/linux/execution_potential_hack_tool_executed.toml
+++ b/rules/linux/execution_potential_hack_tool_executed.toml
@@ -71,7 +71,7 @@ process.name in~ (
   // web enumeration
   "gobuster", "dirbuster", "dirb", "wfuzz", "ffuf", "whatweb", "eyewitness",
   // web vulnerability scanning
-  "wpscan", "joomscan", "droopescan", "nikto", 
+  "wpscan", "joomscan", "droopescan", "nikto",
   // exploitation tools
   "sqlmap", "commix", "yersinia",
   // cracking and brute forcing
@@ -84,7 +84,7 @@ process.name in~ (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Linux Hack Tool Launched
 
diff --git a/rules/linux/execution_potentially_overly_permissive_container_creation.toml b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
index 5c3b93f27ec..062e1c5aafe 100644
--- a/rules/linux/execution_potentially_overly_permissive_container_creation.toml
+++ b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
@@ -58,7 +58,7 @@ process.args:(run and --privileged)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privileged Docker Container Creation
 
diff --git a/rules/linux/execution_process_started_in_shared_memory_directory.toml b/rules/linux/execution_process_started_in_shared_memory_directory.toml
index 357478ce610..876016de207 100644
--- a/rules/linux/execution_process_started_in_shared_memory_directory.toml
+++ b/rules/linux/execution_process_started_in_shared_memory_directory.toml
@@ -71,13 +71,13 @@ type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
 user.id == "0" and process.executable : ("/dev/shm/*", "/run/shm/*", "/var/run/*", "/var/lock/*") and
-not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", 
+not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*",
 "/var/run/argo/argoexec") and not process.parent.command_line : "/usr/bin/runc init"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Binary Executed from Shared Memory Directory
 
diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml
index fd3e8ca50c8..31bfe644c49 100644
--- a/rules/linux/execution_python_tty_shell.toml
+++ b/rules/linux/execution_python_tty_shell.toml
@@ -69,7 +69,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Interactive Terminal Spawned via Python
 
diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml
index 3420984428c..be43eb7acd8 100644
--- a/rules/linux/execution_python_webserver_spawned.toml
+++ b/rules/linux/execution_python_webserver_spawned.toml
@@ -71,7 +71,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Web Server Spawned via Python
 
diff --git a/rules/linux/execution_remote_code_execution_via_postgresql.toml b/rules/linux/execution_remote_code_execution_via_postgresql.toml
index 86eb35a058e..ff5d958392b 100644
--- a/rules/linux/execution_remote_code_execution_via_postgresql.toml
+++ b/rules/linux/execution_remote_code_execution_via_postgresql.toml
@@ -60,7 +60,7 @@ type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
 event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "postgres" and (
-  (process.parent.args : "*sh" and process.parent.args : "echo*") or 
+  (process.parent.args : "*sh" and process.parent.args : "echo*") or
   (process.args : "*sh" and process.args : "echo*")
 ) and not (
   process.parent.name == "puppet" or
@@ -71,7 +71,7 @@ event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "p
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Code Execution via Postgresql
 
diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml
index 3ae5383ced2..8cff0f7485d 100644
--- a/rules/linux/execution_shell_openssl_client_or_server.toml
+++ b/rules/linux/execution_shell_openssl_client_or_server.toml
@@ -69,7 +69,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Openssl Client or Server Activity
 
diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml
index 1785aac5b1c..13f06135389 100644
--- a/rules/linux/execution_shell_via_background_process.toml
+++ b/rules/linux/execution_shell_via_background_process.toml
@@ -60,14 +60,14 @@ type = "eql"
 
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and 
-  process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and 
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and
   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Reverse Shell via Background Process
 
diff --git a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
index ffb033bbdd6..b8541ff2302 100644
--- a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
+++ b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
@@ -72,7 +72,7 @@ sequence by host.id, process.entity_id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Reverse Shell via Child
 
diff --git a/rules/linux/execution_shell_via_java_revshell_linux.toml b/rules/linux/execution_shell_via_java_revshell_linux.toml
index c900b422fd8..c29671a3c8f 100644
--- a/rules/linux/execution_shell_via_java_revshell_linux.toml
+++ b/rules/linux/execution_shell_via_java_revshell_linux.toml
@@ -57,8 +57,8 @@ type = "eql"
 
 query = '''
 sequence by host.id with maxspan=5s
-  [network where host.os.type == "linux" and event.action in ("connection_accepted", "connection_attempted") and 
-   process.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and 
+  [network where host.os.type == "linux" and event.action in ("connection_accepted", "connection_attempted") and
+   process.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and
    not (destination.ip == null or destination.ip == "0.0.0.0" or 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",
@@ -67,7 +67,7 @@ sequence by host.id with maxspan=5s
      "FF00::/8"
     )
   )] by process.entity_id
-  [process where host.os.type == "linux" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.action == "exec" and
    process.parent.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and
    process.parent.args : "-jar" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
    and not process.parent.args in (
@@ -78,7 +78,7 @@ sequence by host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Reverse Shell via Java
 
diff --git a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
index 3171d79f636..55cf9c66754 100644
--- a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
+++ b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
@@ -71,23 +71,23 @@ sequence by host.id, process.entity_id with maxspan=1s
     (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : (
      "*io.popen*", "*os.execute*"
     )) or
-    (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or 
+    (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or
     (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or
     (process.name : "openssl" and process.args : "-connect") or
-    (process.name : ("nc", "ncat", "netcat") and process.args == "-e" and process.args_count >= 3 and 
+    (process.name : ("nc", "ncat", "netcat") and process.args == "-e" and process.args_count >= 3 and
      not process.args == "-z") or
     (process.name : "telnet" and process.args_count >= 3)
   ) and process.parent.name : (
     "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", "perl", "ruby", "lua*",
     "openssl", "nc", "netcat", "ncat", "telnet", "awk")]
-  [network where host.os.type == "linux" and event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and 
-    process.name : ("python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk") and 
+  [network where host.os.type == "linux" and event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and
+    process.name : ("python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk") and
     destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Reverse Shell via Suspicious Child Process
 
diff --git a/rules/linux/execution_shell_via_meterpreter_linux.toml b/rules/linux/execution_shell_via_meterpreter_linux.toml
index b0c80532b4d..26febaa20a4 100644
--- a/rules/linux/execution_shell_via_meterpreter_linux.toml
+++ b/rules/linux/execution_shell_via_meterpreter_linux.toml
@@ -82,7 +82,7 @@ sample by host.id, process.pid, user.id
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Meterpreter Reverse Shell
 
diff --git a/rules/linux/execution_shell_via_suspicious_binary.toml b/rules/linux/execution_shell_via_suspicious_binary.toml
index eb806766a74..176aa0254ee 100644
--- a/rules/linux/execution_shell_via_suspicious_binary.toml
+++ b/rules/linux/execution_shell_via_suspicious_binary.toml
@@ -73,14 +73,14 @@ sequence by host.id, process.entity_id with maxspan=1s
   "/etc/crontab", "/etc/cron.*", "/etc/update-motd.d/*", "/usr/lib/update-notifier/*",
   "/boot/*", "/srv/*", "/run/*", "/root/*", "/etc/rc.local"
    ) and destination.ip != null and destination.ip != "127.0.0.1" and destination.ip != "::1" ]
-[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
-  process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
+[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+  process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
   process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Reverse Shell via Suspicious Binary
 
diff --git a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
index 1ff31372e2e..9370122adc7 100644
--- a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
@@ -70,7 +70,7 @@ sequence by host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Reverse Shell
 
diff --git a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
index 832d4bf4277..5f79dbb864d 100644
--- a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
@@ -90,7 +90,7 @@ sample by host.id, process.pid, process.parent.pid
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Reverse Shell via UDP
 
diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
index 58d138fcefb..648d90ea01b 100644
--- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
+++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
@@ -63,14 +63,14 @@ type = "eql"
 query = '''
 process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and
 ((process.args == "tail" and process.args == "-c" and process.args == "funzip")) and
-not process.args : "/var/log/messages" and 
+not process.args : "/var/log/messages" and
 not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and
 not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Content Extracted or Decompressed via Funzip
 
diff --git a/rules/linux/execution_suspicious_executable_running_system_commands.toml b/rules/linux/execution_suspicious_executable_running_system_commands.toml
index 8f1506333dc..cb652005917 100644
--- a/rules/linux/execution_suspicious_executable_running_system_commands.toml
+++ b/rules/linux/execution_suspicious_executable_running_system_commands.toml
@@ -78,7 +78,7 @@ process.parent.executable:(
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious System Commands Executed by Previously Unknown Executable
 
diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml
index 1c301462255..d92b5fae400 100644
--- a/rules/linux/execution_suspicious_mining_process_creation_events.toml
+++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml
@@ -59,13 +59,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and 
+file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and
 file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Mining Process Creation Event
 
diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml
index 334b24c3239..f56b1482b36 100644
--- a/rules/linux/execution_tc_bpf_filter.toml
+++ b/rules/linux/execution_tc_bpf_filter.toml
@@ -72,7 +72,7 @@ not process.parent.executable == "/usr/sbin/libvirtd"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 BPF filter applied using TC
 
diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml
index cc20572a207..33ab7f3c943 100644
--- a/rules/linux/execution_unix_socket_communication.toml
+++ b/rules/linux/execution_unix_socket_communication.toml
@@ -39,9 +39,9 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  (
-  (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and 
+  (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and
    process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or
-  (process.name == "socat" and 
+  (process.name == "socat" and
    process.args == "-" and process.args : ("UNIX-CLIENT:/usr/local/*", "UNIX-CLIENT:/run/*", "UNIX-CLIENT:/var/run/*"))
 ) and
 not process.args == "/var/run/libvirt/libvirt-sock"
@@ -49,7 +49,7 @@ not process.args == "/var/run/libvirt/libvirt-sock"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unix Socket Connection
 
diff --git a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
index 0894eb6a47c..64b5b19eee7 100644
--- a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
+++ b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
@@ -63,7 +63,7 @@ event.category:process and host.os.type:linux and auditd.data.syscall:mprotect a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unknown Execution of Binary with RWX Memory Region
 
diff --git a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
index f82e1c70c48..816f87d6832 100644
--- a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
+++ b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
@@ -82,7 +82,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Data Splitting Detected
 
diff --git a/rules/linux/impact_data_encrypted_via_openssl.toml b/rules/linux/impact_data_encrypted_via_openssl.toml
index 48107a6d53b..cbe5b83fca8 100644
--- a/rules/linux/impact_data_encrypted_via_openssl.toml
+++ b/rules/linux/impact_data_encrypted_via_openssl.toml
@@ -59,7 +59,7 @@ type = "eql"
 
 query = '''
 sequence by host.id, user.name, process.parent.entity_id with maxspan=5s
-  [ process where host.os.type == "linux" and event.action == "exec" and 
+  [ process where host.os.type == "linux" and event.action == "exec" and
     process.name == "openssl" and process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl*", "php*", "python*", "xargs") and
     process.args == "-in" and process.args == "-out" and
     process.args in ("-k", "-K", "-kfile", "-pass", "-iv", "-md") and
@@ -69,7 +69,7 @@ sequence by host.id, user.name, process.parent.entity_id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Data Encryption via OpenSSL Utility
 
diff --git a/rules/linux/impact_esxi_process_kill.toml b/rules/linux/impact_esxi_process_kill.toml
index 3145071f6a1..c6b37b2f81d 100644
--- a/rules/linux/impact_esxi_process_kill.toml
+++ b/rules/linux/impact_esxi_process_kill.toml
@@ -66,7 +66,7 @@ and process.parent.name == "kill"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Termination of ESXI Process
 
diff --git a/rules/linux/impact_memory_swap_modification.toml b/rules/linux/impact_memory_swap_modification.toml
index ab83bbb439c..c8fb7425777 100644
--- a/rules/linux/impact_memory_swap_modification.toml
+++ b/rules/linux/impact_memory_swap_modification.toml
@@ -76,7 +76,7 @@ process.name in ("swapon", "swapoff") or (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Memory Swap Modification
 
diff --git a/rules/linux/impact_potential_linux_ransomware_note_detected.toml b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
index 8cd905eeed3..007499c0b85 100644
--- a/rules/linux/impact_potential_linux_ransomware_note_detected.toml
+++ b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
@@ -55,8 +55,8 @@ tags = [
 ]
 type = "eql"
 query = '''
-sequence by process.entity_id, host.id with maxspan=1s 
-  [file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and file.extension : "?*" 
+sequence by process.entity_id, host.id with maxspan=1s
+  [file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and file.extension : "?*"
    and process.executable : ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/run/*", "/boot/*") and
    file.path : (
      "/home/*/Downloads/*", "/home/*/Documents/*", "/root/*", "/bin/*", "/usr/bin/*", "/var/log/*", "/var/lib/log/*",
@@ -74,7 +74,7 @@ sequence by process.entity_id, host.id with maxspan=1s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Linux Ransomware Note Creation Detected
 
diff --git a/rules/linux/lateral_movement_ssh_it_worm_download.toml b/rules/linux/lateral_movement_ssh_it_worm_download.toml
index 8e88a53a6af..887eb0b2339 100644
--- a/rules/linux/lateral_movement_ssh_it_worm_download.toml
+++ b/rules/linux/lateral_movement_ssh_it_worm_download.toml
@@ -72,7 +72,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential SSH-IT SSH Worm Downloaded
 
diff --git a/rules/linux/lateral_movement_telnet_network_activity_external.toml b/rules/linux/lateral_movement_telnet_network_activity_external.toml
index b155af91730..5c818c52068 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_external.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_external.toml
@@ -91,7 +91,7 @@ sequence by process.entity_id
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Connection to External Network via Telnet
 
diff --git a/rules/linux/lateral_movement_telnet_network_activity_internal.toml b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
index cd1412d6b2b..6111d1a126b 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_internal.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
@@ -91,7 +91,7 @@ sequence by process.entity_id
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Connection to Internal Network via Telnet
 
diff --git a/rules/linux/persistence_apt_package_manager_execution.toml b/rules/linux/persistence_apt_package_manager_execution.toml
index ccdb27615e9..74f1690bb5e 100644
--- a/rules/linux/persistence_apt_package_manager_execution.toml
+++ b/rules/linux/persistence_apt_package_manager_execution.toml
@@ -78,7 +78,7 @@ sequence by host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious APT Package Manager Execution
 
diff --git a/rules/linux/persistence_apt_package_manager_file_creation.toml b/rules/linux/persistence_apt_package_manager_file_creation.toml
index 4585a2e22ed..4788f0e5b2e 100644
--- a/rules/linux/persistence_apt_package_manager_file_creation.toml
+++ b/rules/linux/persistence_apt_package_manager_file_creation.toml
@@ -85,13 +85,13 @@ file.path : "/etc/apt/apt.conf.d/*" and not (
   process.executable == null or
   process.name in ("pveupdate", "perl") or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 APT Package Manager Configuration File Creation
 
diff --git a/rules/linux/persistence_apt_package_manager_netcon.toml b/rules/linux/persistence_apt_package_manager_netcon.toml
index 9e6715bb68f..e3161b80183 100644
--- a/rules/linux/persistence_apt_package_manager_netcon.toml
+++ b/rules/linux/persistence_apt_package_manager_netcon.toml
@@ -80,7 +80,7 @@ sequence by host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious APT Package Manager Network Connection
 
diff --git a/rules/linux/persistence_at_job_creation.toml b/rules/linux/persistence_at_job_creation.toml
index 1989bb05cc7..0d946a268a0 100644
--- a/rules/linux/persistence_at_job_creation.toml
+++ b/rules/linux/persistence_at_job_creation.toml
@@ -76,13 +76,13 @@ event.action in ("rename", "creation") and file.path : "/var/spool/cron/atjobs/*
   process.executable : ("/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*") or
   process.executable == null or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 At Job Created or Modified
 
diff --git a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
index 880d9d8a8bc..0a3cbb47178 100644
--- a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
@@ -85,13 +85,13 @@ file.path : ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*
   ) or
   process.executable == null or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 DNF Package Manager Plugin File Creation
 
diff --git a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
index 72a34f4a85d..5bf37a2f276 100644
--- a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
@@ -62,7 +62,7 @@ process.args:("-i" or "--install")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 DPKG Package Installed by Unusual Parent Process
 
diff --git a/rules/linux/persistence_dpkg_unusual_execution.toml b/rules/linux/persistence_dpkg_unusual_execution.toml
index 9a96c8bd1b7..9eb259a3989 100644
--- a/rules/linux/persistence_dpkg_unusual_execution.toml
+++ b/rules/linux/persistence_dpkg_unusual_execution.toml
@@ -67,7 +67,7 @@ process.group_leader.name != null and not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual DPKG Execution
 
diff --git a/rules/linux/persistence_git_hook_execution.toml b/rules/linux/persistence_git_hook_execution.toml
index 19784470d1a..cb00e5c6320 100644
--- a/rules/linux/persistence_git_hook_execution.toml
+++ b/rules/linux/persistence_git_hook_execution.toml
@@ -74,7 +74,7 @@ sequence by host.id with maxspan=3s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Git Hook Command Execution
 
diff --git a/rules/linux/persistence_git_hook_file_creation.toml b/rules/linux/persistence_git_hook_file_creation.toml
index 8a11a5b3597..7474b87ec13 100644
--- a/rules/linux/persistence_git_hook_file_creation.toml
+++ b/rules/linux/persistence_git_hook_file_creation.toml
@@ -81,13 +81,13 @@ file.extension == null and process.executable != null and not (
   process.executable : ("/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*") or
   process.name in ("git", "dirname", "tar", "gitea", "git-lfs") or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Git Hook Created or Modified
 
diff --git a/rules/linux/persistence_git_hook_netcon.toml b/rules/linux/persistence_git_hook_netcon.toml
index f74e5ac390b..ba0e65d8608 100644
--- a/rules/linux/persistence_git_hook_netcon.toml
+++ b/rules/linux/persistence_git_hook_netcon.toml
@@ -79,7 +79,7 @@ sequence by host.id with maxspan=3s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Git Hook Egress Network Connection
 
diff --git a/rules/linux/persistence_git_hook_process_execution.toml b/rules/linux/persistence_git_hook_process_execution.toml
index 21f2c8c1fd1..c6a0059c8bf 100644
--- a/rules/linux/persistence_git_hook_process_execution.toml
+++ b/rules/linux/persistence_git_hook_process_execution.toml
@@ -76,8 +76,8 @@ process where host.os.type == "linux" and event.type == "start" and
     "post-index-change", "post-merge", "post-applypatch"
   ) and
   (
-    process.name in ("nohup", "setsid", "disown", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or 
-    process.name : ("php*", "perl*", "ruby*", "lua*") or 
+    process.name in ("nohup", "setsid", "disown", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
+    process.name : ("php*", "perl*", "ruby*", "lua*") or
     process.executable : (
       "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*",
       "/run/*", "/srv/*", "/tmp/*", "/var/tmp/*", "/var/log/*"
@@ -88,7 +88,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Git Hook Child Process
 
diff --git a/rules/linux/persistence_kernel_driver_load.toml b/rules/linux/persistence_kernel_driver_load.toml
index aa11744f286..c1c887d88be 100644
--- a/rules/linux/persistence_kernel_driver_load.toml
+++ b/rules/linux/persistence_kernel_driver_load.toml
@@ -20,7 +20,7 @@ name = "Kernel Driver Load"
 risk_score = 21
 rule_id = "3e12a439-d002-4944-bc42-171c0dcb9b96"
 setup = """## Setup
-This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. 
+This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.
 
 ```
 Kibana -->
@@ -30,7 +30,7 @@ Auditd Manager -->
 Add Auditd Manager
 ```
 
-`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. 
+`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
 
 For this detection rule to trigger, the following additional audit rules are required to be added to the integration:
 ```
@@ -59,7 +59,7 @@ auditd.data.syscall in ("init_module", "finit_module")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kernel Driver Load
 
diff --git a/rules/linux/persistence_kernel_driver_load_by_non_root.toml b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
index dc31b699233..7bac3a551c5 100644
--- a/rules/linux/persistence_kernel_driver_load_by_non_root.toml
+++ b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
@@ -65,7 +65,7 @@ auditd.data.syscall in ("init_module", "finit_module") and user.id != "0"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kernel Driver Load by non-root User
 
diff --git a/rules/linux/persistence_kernel_object_file_creation.toml b/rules/linux/persistence_kernel_object_file_creation.toml
index 495da198dd3..14738c5578c 100644
--- a/rules/linux/persistence_kernel_object_file_creation.toml
+++ b/rules/linux/persistence_kernel_object_file_creation.toml
@@ -62,7 +62,7 @@ event.category:file and host.os.type:linux and event.type:creation and file.exte
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kernel Object File Creation
 
diff --git a/rules/linux/persistence_lkm_configuration_file_creation.toml b/rules/linux/persistence_lkm_configuration_file_creation.toml
index b1ca34adf35..5204c3afbde 100644
--- a/rules/linux/persistence_lkm_configuration_file_creation.toml
+++ b/rules/linux/persistence_lkm_configuration_file_creation.toml
@@ -58,13 +58,13 @@ file.path like~ (
     "jumpcloud-agent", "crio", "dnf_install", "utild"
   ) or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Loadable Kernel Module Configuration File Creation
 
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation.toml b/rules/linux/persistence_pluggable_authentication_module_creation.toml
index 6e3b3b33a1a..2e555818a5b 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation.toml
@@ -8,7 +8,7 @@ updated_date = "2025/01/10"
 author = ["Elastic"]
 description = """
 This rule monitors for the creation or modification of Pluggable Authentication Module (PAM) shared object files or
-configuration files. Attackers may create or modify these files to maintain persistence on a compromised system, or 
+configuration files. Attackers may create or modify these files to maintain persistence on a compromised system, or
 harvest account credentials.
 """
 false_positives = [
@@ -39,13 +39,13 @@ tags = [
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-file where host.os.type == "linux" and event.action in ("rename", "creation") and 
+file where host.os.type == "linux" and event.action in ("rename", "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/pam.d/*" and file.extension == null) or
   (file.path like~ "/etc/security/pam_*" or file.path == "/etc/pam.conf")
 ) and not (
   process.executable in (
@@ -68,13 +68,13 @@ process.executable != null and (
     "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*"
   ) or
   (process.name == "sed" and file.name like~ "sed*") or
-  (process.name == "perl" and file.name like~ "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name like~ "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation or Modification of Pluggable Authentication Module or Configuration
 
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
index 8490fb0ed03..fd6b200ebd6 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
@@ -61,7 +61,7 @@ file where host.os.type == "linux" and event.type == "creation" and file.name li
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 (PAM) Creation in Unusual Directory
 
diff --git a/rules/linux/persistence_pluggable_authentication_module_source_download.toml b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
index afd726f6743..2dc3d976ba8 100644
--- a/rules/linux/persistence_pluggable_authentication_module_source_download.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
@@ -47,7 +47,7 @@ process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 (PAM) Source Download
 
diff --git a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
index 9281e909bcd..43d572e49ef 100644
--- a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
+++ b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
@@ -76,7 +76,7 @@ process.args : (
   "/etc/xdg/autostart/*", "/home/*/.config/autostart/*", "/root/.config/autostart/*",
   "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", "/home/*/.config/autostart-scripts/*",
   "/root/.config/autostart-scripts/*", "/etc/xdg/autostart/*", "/usr/share/autostart/*",
-  
+
   // udev
   "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*"
 
@@ -88,7 +88,7 @@ process.args : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Executable Bit Set for Potential Persistence Script
 
diff --git a/rules/linux/persistence_process_capability_set_via_setcap.toml b/rules/linux/persistence_process_capability_set_via_setcap.toml
index 3b4231f225d..032fdf9557e 100644
--- a/rules/linux/persistence_process_capability_set_via_setcap.toml
+++ b/rules/linux/persistence_process_capability_set_via_setcap.toml
@@ -64,14 +64,14 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.name == "setcap" and not (
   process.parent.executable == null or
-  process.parent.executable : ("/var/lib/dpkg/*", "/var/lib/docker/*", "/tmp/newroot/*", "/var/tmp/newroot/*") or 
+  process.parent.executable : ("/var/lib/dpkg/*", "/var/lib/docker/*", "/tmp/newroot/*", "/var/tmp/newroot/*") or
   process.parent.name in ("jem", "vzctl")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Capability Set via setcap Utility
 
diff --git a/rules/linux/persistence_rc_local_error_via_syslog.toml b/rules/linux/persistence_rc_local_error_via_syslog.toml
index e85ddb3e683..dd29fda0cd7 100644
--- a/rules/linux/persistence_rc_local_error_via_syslog.toml
+++ b/rules/linux/persistence_rc_local_error_via_syslog.toml
@@ -59,7 +59,7 @@ message:("Connection refused" or "No such file or directory" or "command not fou
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious rc.local Error Message
 
diff --git a/rules/linux/persistence_rc_local_service_already_running.toml b/rules/linux/persistence_rc_local_service_already_running.toml
index 54ee65cd6ff..ed74122563c 100644
--- a/rules/linux/persistence_rc_local_service_already_running.toml
+++ b/rules/linux/persistence_rc_local_service_already_running.toml
@@ -65,13 +65,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and 
+process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and
 process.parent.args == "/etc/rc.local" and process.parent.args == "start"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Execution of rc.local Script
 
diff --git a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
index 7af8ea3ef22..8d28d3d7ccb 100644
--- a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
@@ -57,7 +57,7 @@ process.args:("-i" or "--install")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 RPM Package Installed by Unusual Parent Process
 
diff --git a/rules/linux/persistence_shadow_file_modification.toml b/rules/linux/persistence_shadow_file_modification.toml
index ef0246a60ce..2c30428a9d9 100644
--- a/rules/linux/persistence_shadow_file_modification.toml
+++ b/rules/linux/persistence_shadow_file_modification.toml
@@ -63,7 +63,7 @@ file.path == "/etc/shadow" and file.Ext.original.path != null
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Shadow File Modification
 
diff --git a/rules/linux/persistence_shell_configuration_modification.toml b/rules/linux/persistence_shell_configuration_modification.toml
index f6285354aca..78ec71b2d91 100644
--- a/rules/linux/persistence_shell_configuration_modification.toml
+++ b/rules/linux/persistence_shell_configuration_modification.toml
@@ -95,13 +95,13 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
   process.executable == null or
   process.name in ("adclient", "mkhomedir_helper", "teleport", "mkhomedir", "adduser", "desktopDaemon") or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Shell Configuration Creation or Modification
 
diff --git a/rules/linux/persistence_simple_web_server_connection_accepted.toml b/rules/linux/persistence_simple_web_server_connection_accepted.toml
index 88b39906e10..d327800db99 100644
--- a/rules/linux/persistence_simple_web_server_connection_accepted.toml
+++ b/rules/linux/persistence_simple_web_server_connection_accepted.toml
@@ -65,7 +65,7 @@ network where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Simple HTTP Web Server Connection
 
diff --git a/rules/linux/persistence_simple_web_server_creation.toml b/rules/linux/persistence_simple_web_server_creation.toml
index c7478e060ef..559b955691d 100644
--- a/rules/linux/persistence_simple_web_server_creation.toml
+++ b/rules/linux/persistence_simple_web_server_creation.toml
@@ -11,7 +11,7 @@ author = ["Elastic"]
 description = """
 This rule detects the creation of a simple HTTP web server using PHP or Python built-in modules. Adversaries may create
 simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload
-to the server web root, allowing them to regain remote access to the system if lost. 
+to the server web root, allowing them to regain remote access to the system if lost.
 """
 from = "now-9m"
 index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
@@ -71,7 +71,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Simple HTTP Web Server Creation
 
diff --git a/rules/linux/persistence_ssh_key_generation.toml b/rules/linux/persistence_ssh_key_generation.toml
index 2745eef79ff..85ba3202368 100644
--- a/rules/linux/persistence_ssh_key_generation.toml
+++ b/rules/linux/persistence_ssh_key_generation.toml
@@ -44,7 +44,7 @@ not file.name : "known_hosts.*"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SSH Key Generated via ssh-keygen
 
diff --git a/rules/linux/persistence_ssh_netcon.toml b/rules/linux/persistence_ssh_netcon.toml
index 2cbd286a171..4ea9b974a71 100644
--- a/rules/linux/persistence_ssh_netcon.toml
+++ b/rules/linux/persistence_ssh_netcon.toml
@@ -50,7 +50,7 @@ sequence by host.id with maxspan=1s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Connection Initiated by SSHD Child Process
 
diff --git a/rules/linux/persistence_ssh_via_backdoored_system_user.toml b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
index ae091309e82..a8d8c88700d 100644
--- a/rules/linux/persistence_ssh_via_backdoored_system_user.toml
+++ b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
@@ -64,7 +64,7 @@ user.name in (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Login via Unusual System User
 
diff --git a/rules/linux/persistence_suspicious_file_opened_through_editor.toml b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
index 7203330663a..6d47ca4ea16 100644
--- a/rules/linux/persistence_suspicious_file_opened_through_editor.toml
+++ b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
@@ -51,7 +51,7 @@ file.path : (
   "/etc/systemd/system/.*.swp", "/usr/local/lib/systemd/system/.*.swp", "/lib/systemd/system/.*.swp",
   "/usr/lib/systemd/system/.*.swp","/home/*/.config/systemd/user/.*.swp", "/run/.*.swp", "/var/run/.*.swp/",
 
-  /* profile and shell configuration files */  
+  /* profile and shell configuration files */
   "/home/*.profile.swp", "/home/*.bash_profile.swp", "/home/*.bash_login.swp", "/home/*.bashrc.swp", "/home/*.bash_logout.swp",
   "/home/*.zshrc.swp", "/home/*.zlogin.swp", "/home/*.tcshrc.swp", "/home/*.kshrc.swp", "/home/*.config.fish.swp",
   "/root/*.profile.swp", "/root/*.bash_profile.swp", "/root/*.bash_login.swp", "/root/*.bashrc.swp", "/root/*.bash_logout.swp",
@@ -61,7 +61,7 @@ file.path : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Suspicious File Edit
 
diff --git a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
index 00dd46c4b65..6e638888e8d 100644
--- a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
+++ b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
@@ -39,7 +39,7 @@ query = '''
 sequence by host.id, user.id with maxspan=1s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "sshd" and
     process.args == "-D" and process.args == "-R"] by process.pid, process.entity_id
- [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "sshd" and 
+ [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "sshd" and
   process.executable != null and not (
     process.executable in ("/usr/sbin/sshd", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/bin/fipscheck") or
     process.args like ("rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*") or
@@ -51,7 +51,7 @@ sequence by host.id, user.id with maxspan=1s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Execution via XZBackdoor
 
diff --git a/rules/linux/persistence_systemd_generator_creation.toml b/rules/linux/persistence_systemd_generator_creation.toml
index 1f1ec52c970..540474a01f4 100644
--- a/rules/linux/persistence_systemd_generator_creation.toml
+++ b/rules/linux/persistence_systemd_generator_creation.toml
@@ -86,7 +86,7 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Systemd Generator Created
 
diff --git a/rules/linux/persistence_systemd_netcon.toml b/rules/linux/persistence_systemd_netcon.toml
index 641a6a506f5..00e74ec28b7 100644
--- a/rules/linux/persistence_systemd_netcon.toml
+++ b/rules/linux/persistence_systemd_netcon.toml
@@ -70,7 +70,7 @@ sequence by host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Network Connection via systemd
 
diff --git a/rules/linux/persistence_tainted_kernel_module_load.toml b/rules/linux/persistence_tainted_kernel_module_load.toml
index e07ec7f9272..41ea4cfbc52 100644
--- a/rules/linux/persistence_tainted_kernel_module_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_load.toml
@@ -52,13 +52,13 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
+host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and
 message:"module verification failed: signature and/or required key missing - tainting kernel"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Tainted Kernel Module Load
 
diff --git a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
index ab0d59ff5c9..73efa7f0210 100644
--- a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
@@ -52,13 +52,13 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and 
+host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and
 message:"loading out-of-tree module taints kernel."
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Tainted Out-Of-Tree Kernel Module Load
 
diff --git a/rules/linux/persistence_udev_rule_creation.toml b/rules/linux/persistence_udev_rule_creation.toml
index dd4c053842e..3d9a8c2b3c8 100644
--- a/rules/linux/persistence_udev_rule_creation.toml
+++ b/rules/linux/persistence_udev_rule_creation.toml
@@ -57,7 +57,7 @@ tags = [
 timestamp_override = "event.ingested"
 type = "eql"
 query = '''
-file where host.os.type == "linux" and event.action in ("rename", "creation") and 
+file where host.os.type == "linux" and event.action in ("rename", "creation") and
 process.executable != null and file.extension == "rules" and
 file.path : (
   "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*", "/usr/local/lib/udev/rules.d/*"
@@ -80,13 +80,13 @@ file.path : (
   ) or
   process.name in ("systemd", "netplan", "apt-get", "vmware-config-tools.pl", "systemd-hwdb") or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Systemd-udevd Rule File Creation
 
diff --git a/rules/linux/persistence_unusual_pam_grantor.toml b/rules/linux/persistence_unusual_pam_grantor.toml
index 4b0461200e5..813d15234e8 100644
--- a/rules/linux/persistence_unusual_pam_grantor.toml
+++ b/rules/linux/persistence_unusual_pam_grantor.toml
@@ -49,7 +49,7 @@ auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*))
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Authentication via Unusual PAM Grantor
 
diff --git a/rules/linux/persistence_unusual_sshd_child_process.toml b/rules/linux/persistence_unusual_sshd_child_process.toml
index 941a739b76b..e7f6343af34 100644
--- a/rules/linux/persistence_unusual_sshd_child_process.toml
+++ b/rules/linux/persistence_unusual_sshd_child_process.toml
@@ -37,7 +37,7 @@ not process.command_line:(-bash or -zsh or -sh)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual SSHD Child Process
 
diff --git a/rules/linux/persistence_user_or_group_creation_or_modification.toml b/rules/linux/persistence_user_or_group_creation_or_modification.toml
index a41d35802fc..d7a78e5bfc3 100644
--- a/rules/linux/persistence_user_or_group_creation_or_modification.toml
+++ b/rules/linux/persistence_user_or_group_creation_or_modification.toml
@@ -69,13 +69,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and 
+iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and
 event.action in ("changed-password", "added-user-account", "added-group-account-to")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 User or Group Creation/Modification
 
diff --git a/rules/linux/persistence_xdg_autostart_netcon.toml b/rules/linux/persistence_xdg_autostart_netcon.toml
index 43530e9dd43..c97c3d23d0c 100644
--- a/rules/linux/persistence_xdg_autostart_netcon.toml
+++ b/rules/linux/persistence_xdg_autostart_netcon.toml
@@ -100,7 +100,7 @@ sequence by host.id, process.entity_id with maxspan=1s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Connections Initiated Through XDG Autostart Entry
 
diff --git a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
index 3b68e2dcebf..c45e1ede149 100644
--- a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
@@ -82,13 +82,13 @@ file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not (
   ) or
   process.executable == null or
   (process.name == "sed" and file.name : "sed*") or
-  (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Yum Package Manager Plugin File Creation
 
diff --git a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
index 637e0c26c33..cf37595f58b 100644
--- a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
+++ b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
@@ -71,7 +71,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Unauthorized Access via Wildcard Injection Detected
 
diff --git a/rules/linux/privilege_escalation_container_util_misconfiguration.toml b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
index caab0b19d49..d22c727c589 100644
--- a/rules/linux/privilege_escalation_container_util_misconfiguration.toml
+++ b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
@@ -74,13 +74,13 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
   (process.name == "runc" and process.args == "run") or
   (process.name == "ctr" and process.args == "run" and process.args in ("--privileged", "--mount"))
-) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and 
+) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and
 process.interactive == true and process.parent.interactive == true
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via Container Misconfiguration
 
diff --git a/rules/linux/privilege_escalation_dac_permissions.toml b/rules/linux/privilege_escalation_dac_permissions.toml
index ba4a168dd39..08ae80fbe46 100644
--- a/rules/linux/privilege_escalation_dac_permissions.toml
+++ b/rules/linux/privilege_escalation_dac_permissions.toml
@@ -74,7 +74,7 @@ process.command_line:(*sudoers* or *passwd* or *shadow* or */root/*) and not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via Linux DAC permissions
 
diff --git a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
index 1b74bc06fb3..25bce6b66bc 100644
--- a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
+++ b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
@@ -38,7 +38,7 @@ process.args in ("-t", "--target") and process.args_count >= 4
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Docker Escape via Nsenter
 
diff --git a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
index 3f263b94bf4..058f0290879 100644
--- a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
+++ b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
@@ -81,7 +81,7 @@ sequence by host.id, process.parent.entity_id with maxspan=5m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Chroot Container Escape via Mount
 
diff --git a/rules/linux/privilege_escalation_enlightenment_window_manager.toml b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
index b9bd1974e83..a9b13ac91a0 100644
--- a/rules/linux/privilege_escalation_enlightenment_window_manager.toml
+++ b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
@@ -65,7 +65,7 @@ sequence by host.id, process.parent.entity_id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via Enlightenment
 
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
index 0c7533b9bd6..681c3508a7f 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
@@ -59,7 +59,7 @@ type = "eql"
 query = '''
 sequence by host.id, process.entry_leader.entity_id with maxspan=1m
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "gdb" and
-   (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and 
+   (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and
    user.id != "0"]
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.name != null and user.id == "0"]
@@ -67,7 +67,7 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privilege Escalation via GDB CAP_SYS_PTRACE
 
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
index e747f01af6f..eadd862854e 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
@@ -69,7 +69,7 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=30s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Root Network Connection via GDB CAP_SYS_PTRACE
 
diff --git a/rules/linux/privilege_escalation_kworker_uid_elevation.toml b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
index 0fcddb3fbe2..46294053583 100644
--- a/rules/linux/privilege_escalation_kworker_uid_elevation.toml
+++ b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
@@ -67,7 +67,7 @@ user.id == "0"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Kworker UID Elevation
 
diff --git a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
index 91ca9f05d23..680b45a5e06 100644
--- a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
+++ b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
@@ -70,13 +70,13 @@ timestamp_override = "event.ingested"
 type = "new_terms"
 
 query = '''
-host.os.type:linux and event.category:file and event.action:(updated or renamed or rename or file_rename_event) and 
+host.os.type:linux and event.category:file and event.action:(updated or renamed or rename or file_rename_event) and
 not event.type:deletion and file.path:/etc/ld.so.preload and not process.name:(wine or oneagentinstallaction)
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Dynamic Linker Preload Shared Object
 
diff --git a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
index a2a5a3ec4f0..2fde4756524 100644
--- a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
+++ b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
@@ -58,29 +58,29 @@ timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
-process.name == "ln" and process.args in ("-s", "-sf") and 
+process.name == "ln" and process.args in ("-s", "-sf") and
   (
     /* suspicious files */
-    (process.args in ("/etc/shadow", "/etc/shadow-", "/etc/shadow~", "/etc/gshadow", "/etc/gshadow-") or 
-    (process.working_directory == "/etc" and process.args in ("shadow", "shadow-", "shadow~", "gshadow", "gshadow-"))) or 
-    
+    (process.args in ("/etc/shadow", "/etc/shadow-", "/etc/shadow~", "/etc/gshadow", "/etc/gshadow-") or
+    (process.working_directory == "/etc" and process.args in ("shadow", "shadow-", "shadow~", "gshadow", "gshadow-"))) or
+
     /* suspicious bins */
-    (process.args in ("/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh", "/bin/zsh", "/bin/ksh", "/bin/fish") or 
-    (process.working_directory == "/bin" and process.args : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"))) or 
-    (process.args in ("/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh", "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish") or 
+    (process.args in ("/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh", "/bin/zsh", "/bin/ksh", "/bin/fish") or
+    (process.working_directory == "/bin" and process.args : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"))) or
+    (process.args in ("/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh", "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish") or
     (process.working_directory == "/usr/bin" and process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"))) or
-    
+
     /* suspicious locations */
     (process.args : ("/etc/cron.d/*", "/etc/cron.daily/*", "/etc/cron.hourly/*", "/etc/cron.weekly/*", "/etc/cron.monthly/*")) or
     (process.args : ("/home/*/.ssh/*", "/root/.ssh/*","/etc/sudoers.d/*", "/dev/shm/*"))
-  ) and 
-  process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and 
+  ) and
+  process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
   not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Symbolic Link Created
 
diff --git a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
index 2eb616dc5c8..e937ec0f857 100644
--- a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
+++ b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
@@ -69,7 +69,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via UID INT_MAX Bug Detected
 
diff --git a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
index 825eaad5774..6c572385f26 100644
--- a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
+++ b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
@@ -77,7 +77,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kernel Load or Unload via Kexec Detected
 
diff --git a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
index 21c1ee0eebb..470fa194e65 100644
--- a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
+++ b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
@@ -71,13 +71,13 @@ type = "eql"
 
 query = '''
 sequence by host.id, process.parent.entity_id, process.executable with maxspan=5s
- [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+ [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.env_vars : "*GLIBC_TUNABLES=glibc.*=glibc.*=*"] with runs=5
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via CVE-2023-4911
 
diff --git a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
index ad16310ddfe..c1386ba62f3 100644
--- a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
+++ b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
@@ -65,12 +65,12 @@ event.action in ("connection_attempted", "ipv4_connection_attempt_event") and pr
     "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", "172.31.0.0/16"
   )
-) 
+)
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Connection via Sudo Binary
 
diff --git a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
index 6a3b3f4f2e0..05030ecbcfd 100644
--- a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
+++ b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
@@ -60,15 +60,15 @@ type = "eql"
 
 query = '''
 sequence by process.parent.entity_id, host.id with maxspan=5s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
     process.name == "unshare" and process.args : ("-r", "-rm", "m") and process.args : "*cap_setuid*"  and user.id != "0"]
-  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
+  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
     user.id == "0"]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via OverlayFS
 
diff --git a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
index 3435ff3037b..5f384e72791 100644
--- a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
+++ b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
@@ -65,7 +65,7 @@ file where host.os.type == "linux" and file.path : "/*GCONV_PATH*"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via PKEXEC
 
diff --git a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
index 022e3639240..bbea8014783 100644
--- a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
+++ b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
@@ -20,7 +20,7 @@ rule_id = "b7c05aaf-78c2-4558-b069-87fa25973489"
 setup = """## Setup
 
 
-This rule leverages alert data from other prebuilt detection rules to function correctly. 
+This rule leverages alert data from other prebuilt detection rules to function correctly.
 
 ### Dependent Elastic Detection Rule Enablement
 As a higher-order rule (based on other detections), this rule also requires the following prerequisite Elastic detection rule to be installed and enabled:
@@ -45,7 +45,7 @@ kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.typ
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Buffer Overflow Attack Detected
 
diff --git a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
index 6e684157679..7cc11082420 100644
--- a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
+++ b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
@@ -63,7 +63,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
-  (process.user.id == "0" and process.real_user.id != "0") or 
+  (process.user.id == "0" and process.real_user.id != "0") or
   (process.group.id == "0" and process.real_group.id != "0")
 ) and (
   process.name in (
@@ -89,7 +89,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
     "uuencode", "vagrant", "varnishncsa", "view", "vigr", "vim", "vimdiff", "vipw", "w3m", "watch",
     "wc", "wget", "whiptail", "xargs", "xdotool", "xmodmap", "xmore", "xxd", "xz", "yash", "zsh",
     "zsoelim"
-  ) or 
+  ) or
   process.name == "ip" and (
     (process.args == "-force" and process.args in ("-batch", "-b")) or (process.args == "exec")
   )
@@ -98,7 +98,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privilege Escalation via SUID/SGID
 
diff --git a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
index 520a966e8bb..f45fa1114a4 100644
--- a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
+++ b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
@@ -67,15 +67,15 @@ sequence by host.id with maxspan=1s
     (process.name == "zip" and process.args == "--unzip-command")
    ) and not process.executable : "/tmp/newroot/*"
   ]  by process.entity_id
-  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and 
-     process.parent.name : ("tar", "rsync", "zip") and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
+     process.parent.name : ("tar", "rsync", "zip") and
      process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
   ] by process.parent.entity_id
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Shell via Wildcard Injection Detected
 
diff --git a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
index db1ee3aa243..37611003f55 100644
--- a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
+++ b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
@@ -60,14 +60,14 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
-process.name == "debugfs" and process.args : "/dev/sd*" and not process.args == "-R" and 
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+process.name == "debugfs" and process.args : "/dev/sd*" and not process.args == "-R" and
 not user.Ext.real.id == "0" and not group.Ext.real.id == "0"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Suspicious DebugFS Root Device Access
 
diff --git a/rules/linux/privilege_escalation_shadow_file_read.toml b/rules/linux/privilege_escalation_shadow_file_read.toml
index 57159b1cce3..eec38d4a63c 100644
--- a/rules/linux/privilege_escalation_shadow_file_read.toml
+++ b/rules/linux/privilege_escalation_shadow_file_read.toml
@@ -68,7 +68,7 @@ host.os.type : "linux" and event.category : "process" and event.action : ("exec"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Shadow File Read via Command Line Utilities
 
diff --git a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
index b413bea81c5..c0f652f7a19 100644
--- a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
+++ b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
@@ -71,7 +71,7 @@ process where host.os.type == "linux" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Sudo Privilege Escalation via CVE-2019-14287
 
diff --git a/rules/linux/privilege_escalation_sudo_hijacking.toml b/rules/linux/privilege_escalation_sudo_hijacking.toml
index 6b06eaaadf6..4080d24f4c0 100644
--- a/rules/linux/privilege_escalation_sudo_hijacking.toml
+++ b/rules/linux/privilege_escalation_sudo_hijacking.toml
@@ -82,7 +82,7 @@ file.path in ("/usr/bin/sudo", "/bin/sudo") and not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Sudo Hijacking
 
diff --git a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
index 2c6a878801c..5f23f025156 100644
--- a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
+++ b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
@@ -60,15 +60,15 @@ type = "eql"
 
 query = '''
 sequence by host.id, process.session_leader.entity_id with maxspan=15s
-[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.name == "gdb" and process.user.id != "0" and process.group.id != "0" ]
-[ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
+[ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
   process.name == "sudo" and process.user.id == "0" and process.group.id == "0" ]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Sudo Token Manipulation via Process Injection
 
diff --git a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
index 47da076e06d..2d336bc0531 100644
--- a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
+++ b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
@@ -58,15 +58,15 @@ type = "eql"
 
 query = '''
 sequence by host.id, process.entity_id with maxspan=1s
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.args : "import os;os.set?id(0);os.system(*)" and process.args : "*python*" and user.id != "0"]
-  [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and 
+  [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and
    (user.id == "0" or group.id == "0")]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via Python cap_setuid
 
diff --git a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
index 0a59d73c983..dfc3e5176ba 100644
--- a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
@@ -73,7 +73,7 @@ sequence by host.id, process.pid with maxspan=1s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privilege Escalation via CAP_CHOWN/CAP_FOWNER Capabilities
 
diff --git a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
index 582adc7bff4..296f34bc72b 100644
--- a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
+++ b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
@@ -88,7 +88,7 @@ sequence by host.id, process.parent.pid with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Passwd File Event Action
 
diff --git a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
index cb8416751ae..f77e058032e 100644
--- a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
@@ -58,7 +58,7 @@ type = "eql"
 query = '''
 sequence by host.id, process.entity_id with maxspan=1s
   [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name != null and
-   (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") and 
+   (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") and
    user.id != "0" and not (
      process.parent.executable : ("/tmp/newroot/*", "/opt/carbonblack*") or
      process.parent.executable in (
@@ -75,14 +75,14 @@ sequence by host.id, process.entity_id with maxspan=1s
      process.name == "sudo" or
      process.parent.command_line like "/usr/bin/python*ansible*"
    )]
-  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and 
+  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
    (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID")
    and user.id == "0"]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privilege Escalation via CAP_SETUID/SETGID Capabilities
 
diff --git a/rules/linux/privilege_escalation_uid_change_post_compilation.toml b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
index 347a870770c..fda0a412f3c 100644
--- a/rules/linux/privilege_escalation_uid_change_post_compilation.toml
+++ b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
@@ -56,19 +56,19 @@ type = "eql"
 
 query = '''
 sequence by host.id with maxspan=1m
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    process.name in ("gcc", "g++", "cc") and user.id != "0"] by process.args
-  [file where host.os.type == "linux" and event.action == "creation" and event.type == "creation" and 
+  [file where host.os.type == "linux" and event.action == "creation" and event.type == "creation" and
    process.name == "ld" and user.id != "0"] by file.name
-  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
    user.id != "0"] by process.name
-  [process where host.os.type == "linux" and event.action in ("uid_change", "guid_change") and event.type == "change" and 
+  [process where host.os.type == "linux" and event.action in ("uid_change", "guid_change") and event.type == "change" and
    user.id == "0"] by process.name
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via Recently Compiled Executable
 
diff --git a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
index f606057e0ba..0223be9bda7 100644
--- a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
+++ b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
@@ -77,7 +77,7 @@ and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 UID Elevation from Previously Unknown Executable
 
diff --git a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
index 885b6f42f07..4f6ff76217b 100644
--- a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
+++ b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
@@ -83,7 +83,7 @@ not process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Namespace Manipulation Using Unshare
 
diff --git a/rules/linux/privilege_escalation_writable_docker_socket.toml b/rules/linux/privilege_escalation_writable_docker_socket.toml
index d91ea4df4dd..546803becf9 100644
--- a/rules/linux/privilege_escalation_writable_docker_socket.toml
+++ b/rules/linux/privilege_escalation_writable_docker_socket.toml
@@ -60,17 +60,17 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and 
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 (
-  (process.name == "docker" and process.args : "run" and process.args : "-it"  and 
-   process.args : ("unix://*/docker.sock", "unix://*/dockershim.sock")) or 
+  (process.name == "docker" and process.args : "run" and process.args : "-it"  and
+   process.args : ("unix://*/docker.sock", "unix://*/dockershim.sock")) or
   (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock"))
 ) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation through Writable Docker Socket
 
diff --git a/rules/macos/credential_access_credentials_keychains.toml b/rules/macos/credential_access_credentials_keychains.toml
index c4cceff5fdb..eb5d3dc1858 100644
--- a/rules/macos/credential_access_credentials_keychains.toml
+++ b/rules/macos/credential_access_credentials_keychains.toml
@@ -97,7 +97,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Access to Keychain Credentials Directories
 
diff --git a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
index 1cd6d1b1e40..cc868131ef7 100644
--- a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
+++ b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
@@ -65,7 +65,7 @@ event.category:process and host.os.type:macos and event.type:start and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Dumping Account Hashes via Built-In Commands
 
diff --git a/rules/macos/credential_access_dumping_keychain_security.toml b/rules/macos/credential_access_dumping_keychain_security.toml
index cae91ee2ae2..9d9250ed43c 100644
--- a/rules/macos/credential_access_dumping_keychain_security.toml
+++ b/rules/macos/credential_access_dumping_keychain_security.toml
@@ -61,7 +61,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Dumping of Keychain Content via Security Command
 
diff --git a/rules/macos/credential_access_kerberosdump_kcc.toml b/rules/macos/credential_access_kerberosdump_kcc.toml
index 324d23880f3..09b24cc983d 100644
--- a/rules/macos/credential_access_kerberosdump_kcc.toml
+++ b/rules/macos/credential_access_kerberosdump_kcc.toml
@@ -65,7 +65,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kerberos Cached Credentials Dumping
 
diff --git a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
index c7d8b30169b..184a5858c7f 100644
--- a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
+++ b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
@@ -71,7 +71,7 @@ process where host.os.type == "macos" and event.action == "exec" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Keychain Password Retrieval via Command Line
 
diff --git a/rules/macos/credential_access_mitm_localhost_webproxy.toml b/rules/macos/credential_access_mitm_localhost_webproxy.toml
index 8351ac8e2ac..d35403dd4b6 100644
--- a/rules/macos/credential_access_mitm_localhost_webproxy.toml
+++ b/rules/macos/credential_access_mitm_localhost_webproxy.toml
@@ -69,7 +69,7 @@ event.category:process and host.os.type:macos and event.type:start and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WebProxy Settings Modification
 
diff --git a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
index 983de60efa6..f378688fafa 100644
--- a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
+++ b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
@@ -60,7 +60,7 @@ event.category:process and host.os.type:macos and event.type:start and process.n
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential macOS SSH Brute Force Detected
 
diff --git a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
index 4d362912e8f..39848c4fb2b 100644
--- a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
+++ b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
@@ -62,7 +62,7 @@ process where event.action == "exec" and host.os.type == "macos" and
  process.name : "osascript" and process.args : "-e" and process.command_line : ("*osascript*display*dialog*password*", "*osascript*display*dialog*passphrase*") and
  not (process.parent.executable : "/usr/bin/sudo" and process.command_line : "*Encryption Key Escrow*") and
  not (process.command_line : "*-e with timeout of 3600 seconds*" and user.id == "0" and process.parent.executable : "/bin/bash") and
- not process.Ext.effective_parent.executable : ("/usr/local/jamf/*", 
+ not process.Ext.effective_parent.executable : ("/usr/local/jamf/*",
                                                 "/Applications/Karabiner-Elements.app/Contents/MacOS/Karabiner-Elements",
                                                 "/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal",
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon",
@@ -71,7 +71,7 @@ process where event.action == "exec" and host.os.type == "macos" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Prompt for Credentials with OSASCRIPT
 
diff --git a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
index 3bea0df0a6b..35d61e79a97 100644
--- a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
+++ b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
@@ -56,20 +56,20 @@ type = "eql"
 
 query = '''
 file where event.action == "open" and host.os.type == "macos" and process.executable != null and
- file.name : ("cookies.sqlite", 
-              "key?.db", 
-              "logins.json", 
-              "Cookies", 
-              "Cookies.binarycookies", 
-              "Login Data") and 
- ((process.code_signature.trusted == false or process.code_signature.exists == false) or process.name : "osascript") and 
+ file.name : ("cookies.sqlite",
+              "key?.db",
+              "logins.json",
+              "Cookies",
+              "Cookies.binarycookies",
+              "Login Data") and
+ ((process.code_signature.trusted == false or process.code_signature.exists == false) or process.name : "osascript") and
  not process.code_signature.signing_id : "org.mozilla.firefox" and
  not Effective_process.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Web Browser Sensitive File Access
 
diff --git a/rules/macos/credential_access_systemkey_dumping.toml b/rules/macos/credential_access_systemkey_dumping.toml
index 64cf3ac5134..dfe39d2e902 100644
--- a/rules/macos/credential_access_systemkey_dumping.toml
+++ b/rules/macos/credential_access_systemkey_dumping.toml
@@ -63,7 +63,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SystemKey Access via Command Line
 
diff --git a/rules/macos/defense_evasion_apple_softupdates_modification.toml b/rules/macos/defense_evasion_apple_softupdates_modification.toml
index 914473c3efa..85b80b85d96 100644
--- a/rules/macos/defense_evasion_apple_softupdates_modification.toml
+++ b/rules/macos/defense_evasion_apple_softupdates_modification.toml
@@ -63,7 +63,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SoftwareUpdate Preferences Modification
 
diff --git a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
index cb04d29b5e0..bc25e9002fd 100644
--- a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
+++ b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
@@ -61,8 +61,8 @@ type = "eql"
 query = '''
 file where event.action == "extended_attributes_delete" and host.os.type == "macos" and process.executable != null and
 (process.code_signature.trusted == false or process.code_signature.exists == false) and not
-process.executable : ("/usr/bin/xattr", 
-                      "/System/*", 
+process.executable : ("/usr/bin/xattr",
+                      "/System/*",
                       "/private/tmp/KSInstallAction.*/*/Install Google Software Update.app/Contents/Helpers/ksinstall",
                       "/Applications/CEWE Fotoschau.app/Contents/MacOS/FotoPlus",
                       "/Applications/.com.bomgar.scc.*/Remote Support Customer Client.app/Contents/MacOS/sdcust") and not
@@ -71,7 +71,7 @@ file.path : "/private/var/folders/*"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Quarantine Attrib Removed by Unsigned or Untrusted Process
 
diff --git a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
index aa9061e92dc..e6de35a4f36 100644
--- a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
+++ b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
@@ -64,7 +64,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Disable Gatekeeper
 
diff --git a/rules/macos/defense_evasion_install_root_certificate.toml b/rules/macos/defense_evasion_install_root_certificate.toml
index 126239ed7b4..5446bf513c7 100644
--- a/rules/macos/defense_evasion_install_root_certificate.toml
+++ b/rules/macos/defense_evasion_install_root_certificate.toml
@@ -66,7 +66,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Install Root Certificate
 
diff --git a/rules/macos/defense_evasion_modify_environment_launchctl.toml b/rules/macos/defense_evasion_modify_environment_launchctl.toml
index 5df2a7a4be7..3d312685410 100644
--- a/rules/macos/defense_evasion_modify_environment_launchctl.toml
+++ b/rules/macos/defense_evasion_modify_environment_launchctl.toml
@@ -58,26 +58,26 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.category:process and host.os.type:macos and event.type:start and 
-  process.name:launchctl and 
+event.category:process and host.os.type:macos and event.type:start and
+  process.name:launchctl and
   (process.parent.code_signature.exists : false or process.parent.code_signature.trusted : false) and
-  process.args:(setenv and not (ANT_HOME or 
-                                DBUS_LAUNCHD_SESSION_BUS_SOCKET or 
-                                EDEN_ENV or 
-                                LG_WEBOS_TV_SDK_HOME or 
-                                RUNTIME_JAVA_HOME or 
-                                WEBOS_CLI_TV or 
-                                JAVA*_HOME) and 
-                not *.vmoptions) and 
-  not process.parent.executable:("/Applications/IntelliJ IDEA CE.app/Contents/jbr/Contents/Home/lib/jspawnhelper" or 
-                                  /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or 
-                                  /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or 
+  process.args:(setenv and not (ANT_HOME or
+                                DBUS_LAUNCHD_SESSION_BUS_SOCKET or
+                                EDEN_ENV or
+                                LG_WEBOS_TV_SDK_HOME or
+                                RUNTIME_JAVA_HOME or
+                                WEBOS_CLI_TV or
+                                JAVA*_HOME) and
+                not *.vmoptions) and
+  not process.parent.executable:("/Applications/IntelliJ IDEA CE.app/Contents/jbr/Contents/Home/lib/jspawnhelper" or
+                                  /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or
+                                  /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or
                                   /usr/local/bin/kr)
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Environment Variable via Unsigned or Untrusted Parent
 
diff --git a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
index 6db47ecdccb..54763120bd7 100644
--- a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
+++ b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
@@ -67,7 +67,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privacy Control Bypass via TCCDB Modification
 
diff --git a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
index 4c65154d179..1a6949e943f 100644
--- a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
+++ b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
@@ -68,7 +68,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privacy Control Bypass via Localhost Secure Copy
 
diff --git a/rules/macos/defense_evasion_safari_config_change.toml b/rules/macos/defense_evasion_safari_config_change.toml
index 1a588fb6a96..4bbc224d117 100644
--- a/rules/macos/defense_evasion_safari_config_change.toml
+++ b/rules/macos/defense_evasion_safari_config_change.toml
@@ -71,7 +71,7 @@ event.category:process and host.os.type:macos and event.type:start and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Safari Settings via Defaults Command
 
diff --git a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
index a3072ad7fef..1176027c5cb 100644
--- a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
+++ b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
@@ -65,7 +65,7 @@ event.category:file and host.os.type:(macos and macos) and not event.type:deleti
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Microsoft Office Sandbox Evasion
 
diff --git a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
index 5dae1f3e625..162e37c6830 100644
--- a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
+++ b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
@@ -63,7 +63,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 TCC Bypass via Mounted APFS Snapshot Access
 
diff --git a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
index e5436e0a571..b585425d996 100644
--- a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
+++ b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
@@ -57,7 +57,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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
 
diff --git a/rules/macos/discovery_users_domain_built_in_commands.toml b/rules/macos/discovery_users_domain_built_in_commands.toml
index 4e494cdbc57..55bb9bd6f7e 100644
--- a/rules/macos/discovery_users_domain_built_in_commands.toml
+++ b/rules/macos/discovery_users_domain_built_in_commands.toml
@@ -78,7 +78,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Enumeration of Users or Groups via Built-in Commands
 
diff --git a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
index 4da73c928c5..af46021f5c6 100644
--- a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
+++ b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
@@ -65,7 +65,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution via Electron Child Process Node.js Module
 
diff --git a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
index 637fd295c85..28bbb532adc 100644
--- a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
+++ b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
@@ -85,7 +85,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Browser Child Process
 
diff --git a/rules/macos/execution_installer_package_spawned_network_event.toml b/rules/macos/execution_installer_package_spawned_network_event.toml
index d80066cf445..ca3e3e8c1ab 100644
--- a/rules/macos/execution_installer_package_spawned_network_event.toml
+++ b/rules/macos/execution_installer_package_spawned_network_event.toml
@@ -75,7 +75,7 @@ sequence by host.id with maxspan=15s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 MacOS Installer Package Spawns Network Event
 
diff --git a/rules/macos/execution_script_via_automator_workflows.toml b/rules/macos/execution_script_via_automator_workflows.toml
index d9b13b3205c..9aedc13897e 100644
--- a/rules/macos/execution_script_via_automator_workflows.toml
+++ b/rules/macos/execution_script_via_automator_workflows.toml
@@ -62,7 +62,7 @@ sequence by host.id with maxspan=30s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Automator Workflows Execution
 
diff --git a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
index 798da4ac8b2..2016aea3ba7 100644
--- a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
+++ b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
@@ -70,7 +70,7 @@ sequence by host.id, process.entity_id with maxspan=30s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Apple Script Execution followed by Network Connection
 
diff --git a/rules/macos/execution_shell_execution_via_apple_scripting.toml b/rules/macos/execution_shell_execution_via_apple_scripting.toml
index fdb677c6d47..f80ba8b2375 100644
--- a/rules/macos/execution_shell_execution_via_apple_scripting.toml
+++ b/rules/macos/execution_shell_execution_via_apple_scripting.toml
@@ -64,7 +64,7 @@ sequence by host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Shell Execution via Apple Scripting
 
diff --git a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
index f64f88d5407..188dff16a67 100644
--- a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
+++ b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
@@ -127,7 +127,7 @@ process where event.action == "exec" and host.os.type == "macos" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious macOS MS Office Child Process
 
diff --git a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
index fb586259560..e47d2cdb06f 100644
--- a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
+++ b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
@@ -62,7 +62,7 @@ event.category:process and host.os.type:macos and event.type:start and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Kerberos Attack via Bifrost
 
diff --git a/rules/macos/lateral_movement_mounting_smb_share.toml b/rules/macos/lateral_movement_mounting_smb_share.toml
index f2f6e0a55dc..9812c260281 100644
--- a/rules/macos/lateral_movement_mounting_smb_share.toml
+++ b/rules/macos/lateral_movement_mounting_smb_share.toml
@@ -67,7 +67,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Mount SMB Share via Command Line
 
diff --git a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
index d9dbf21089b..c630f8d21e9 100644
--- a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
+++ b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
@@ -64,7 +64,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Remote SSH Login Enabled via systemsetup Command
 
diff --git a/rules/macos/lateral_movement_vpn_connection_attempt.toml b/rules/macos/lateral_movement_vpn_connection_attempt.toml
index 70d1cff6132..3aa0fd4be52 100644
--- a/rules/macos/lateral_movement_vpn_connection_attempt.toml
+++ b/rules/macos/lateral_movement_vpn_connection_attempt.toml
@@ -69,7 +69,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Virtual Private Network Connection Attempt
 
diff --git a/rules/macos/persistence_account_creation_hide_at_logon.toml b/rules/macos/persistence_account_creation_hide_at_logon.toml
index 02aa30b4b6e..f71eb48c4ec 100644
--- a/rules/macos/persistence_account_creation_hide_at_logon.toml
+++ b/rules/macos/persistence_account_creation_hide_at_logon.toml
@@ -61,7 +61,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Hidden Local User Account Creation
 
diff --git a/rules/macos/persistence_creation_change_launch_agents_file.toml b/rules/macos/persistence_creation_change_launch_agents_file.toml
index 04cf4141e09..113260649dd 100644
--- a/rules/macos/persistence_creation_change_launch_agents_file.toml
+++ b/rules/macos/persistence_creation_change_launch_agents_file.toml
@@ -66,7 +66,7 @@ sequence by host.id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Launch Agent Creation or Modification and Immediate Loading
 
diff --git a/rules/macos/persistence_creation_hidden_login_item_osascript.toml b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
index a7b73e789bc..ffc55220185 100644
--- a/rules/macos/persistence_creation_hidden_login_item_osascript.toml
+++ b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
@@ -61,7 +61,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation of Hidden Login Item via Apple Script
 
diff --git a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
index d85e84512f1..68b8e97f15a 100644
--- a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
+++ b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
@@ -64,7 +64,7 @@ sequence by host.id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 LaunchDaemon Creation or Modification and Immediate Loading
 
diff --git a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
index 077c52f5f3b..b3de7e87a79 100644
--- a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
+++ b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
@@ -67,7 +67,7 @@ event.category:file and host.os.type:macos and not event.type:deletion and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Authorization Plugin Modification
 
diff --git a/rules/macos/persistence_crontab_creation.toml b/rules/macos/persistence_crontab_creation.toml
index 25ef125f347..f4286c4c609 100644
--- a/rules/macos/persistence_crontab_creation.toml
+++ b/rules/macos/persistence_crontab_creation.toml
@@ -64,7 +64,7 @@ file where host.os.type == "macos" and event.type != "deletion" and process.name
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious CronTab Creation or Modification
 
diff --git a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
index aea47236444..ce084dc26ee 100644
--- a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
+++ b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
@@ -66,7 +66,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Hidden Child Process of Launchd
 
diff --git a/rules/macos/persistence_directory_services_plugins_modification.toml b/rules/macos/persistence_directory_services_plugins_modification.toml
index 1fc57c0777b..5d5cd07895c 100644
--- a/rules/macos/persistence_directory_services_plugins_modification.toml
+++ b/rules/macos/persistence_directory_services_plugins_modification.toml
@@ -62,7 +62,7 @@ event.category:file and host.os.type:macos and not event.type:deletion and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via DirectoryService Plugin Modification
 
diff --git a/rules/macos/persistence_docker_shortcuts_plist_modification.toml b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
index 74d1f6b4e10..568afe1728b 100644
--- a/rules/macos/persistence_docker_shortcuts_plist_modification.toml
+++ b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
@@ -65,7 +65,7 @@ event.category:file and host.os.type:macos and event.action:modification and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via Docker Shortcut Modification
 
diff --git a/rules/macos/persistence_emond_rules_file_creation.toml b/rules/macos/persistence_emond_rules_file_creation.toml
index b29aef9323c..c360022db17 100644
--- a/rules/macos/persistence_emond_rules_file_creation.toml
+++ b/rules/macos/persistence_emond_rules_file_creation.toml
@@ -64,7 +64,7 @@ file where host.os.type == "macos" and event.type != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Emond Rules Creation or Modification
 
diff --git a/rules/macos/persistence_emond_rules_process_execution.toml b/rules/macos/persistence_emond_rules_process_execution.toml
index 24576b9df2a..f201132925d 100644
--- a/rules/macos/persistence_emond_rules_process_execution.toml
+++ b/rules/macos/persistence_emond_rules_process_execution.toml
@@ -88,7 +88,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Emond Child Process
 
diff --git a/rules/macos/persistence_enable_root_account.toml b/rules/macos/persistence_enable_root_account.toml
index b5a0359fc54..cd830f6b196 100644
--- a/rules/macos/persistence_enable_root_account.toml
+++ b/rules/macos/persistence_enable_root_account.toml
@@ -61,7 +61,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Enable the Root Account
 
diff --git a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
index 072dad48df0..6bb3145b4a9 100644
--- a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
+++ b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
@@ -71,7 +71,7 @@ file where host.os.type == "macos" and event.type != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation of Hidden Launch Agent or Daemon
 
diff --git a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
index ea48a5b6337..c8e22a0d1ef 100644
--- a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
+++ b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
@@ -81,7 +81,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Finder Sync Plugin Registered and Enabled
 
diff --git a/rules/macos/persistence_folder_action_scripts_runtime.toml b/rules/macos/persistence_folder_action_scripts_runtime.toml
index fa26986610a..e11c2b3354d 100644
--- a/rules/macos/persistence_folder_action_scripts_runtime.toml
+++ b/rules/macos/persistence_folder_action_scripts_runtime.toml
@@ -63,7 +63,7 @@ process where host.os.type == "macos" and event.type : "start" and process.name
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via Folder Action Script
 
diff --git a/rules/macos/persistence_login_logout_hooks_defaults.toml b/rules/macos/persistence_login_logout_hooks_defaults.toml
index 69654c92891..d66fa1c5e41 100644
--- a/rules/macos/persistence_login_logout_hooks_defaults.toml
+++ b/rules/macos/persistence_login_logout_hooks_defaults.toml
@@ -71,7 +71,7 @@ process where host.os.type == "macos" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via Login or Logout Hook
 
diff --git a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
index e043648e2e8..4316bb4e418 100644
--- a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
+++ b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
@@ -73,7 +73,7 @@ file where host.os.type == "macos" and event.type in ("change", "creation") and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Sublime Plugin or Application Script Modification
 
diff --git a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
index 1e8be3c147b..4cd00601227 100644
--- a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
+++ b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
@@ -65,7 +65,7 @@ event.category:file and host.os.type:macos and not event.type:"deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Persistence via Periodic Tasks
 
diff --git a/rules/macos/persistence_suspicious_calendar_modification.toml b/rules/macos/persistence_suspicious_calendar_modification.toml
index a3ae669c25c..c878d8834f9 100644
--- a/rules/macos/persistence_suspicious_calendar_modification.toml
+++ b/rules/macos/persistence_suspicious_calendar_modification.toml
@@ -77,7 +77,7 @@ event.category:file and host.os.type:macos and event.action:modification and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Calendar File Modification
 
diff --git a/rules/macos/persistence_via_atom_init_file_modification.toml b/rules/macos/persistence_via_atom_init_file_modification.toml
index 16a3f109e70..319367f14b6 100644
--- a/rules/macos/persistence_via_atom_init_file_modification.toml
+++ b/rules/macos/persistence_via_atom_init_file_modification.toml
@@ -64,7 +64,7 @@ event.category:file and host.os.type:macos and not event.type:"deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Persistence via Atom Init Script Modification
 
diff --git a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
index eb8b45f415a..708205e4ad4 100644
--- a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
+++ b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
@@ -65,7 +65,7 @@ process where host.os.type == "macos" and event.type in ("start", "process_start
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Apple Scripting Execution with Administrator Privileges
 
diff --git a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
index 11354d8bf3c..096d9223f73 100644
--- a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
+++ b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
@@ -67,7 +67,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution with Explicit Credentials via Scripting
 
diff --git a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
index 21e1494c56e..9670c050fa6 100644
--- a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
+++ b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
@@ -76,7 +76,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Child Process of Adobe Acrobat Reader Update Service
 
diff --git a/rules/macos/privilege_escalation_local_user_added_to_admin.toml b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
index b7076cfbe18..d8099caa6d3 100644
--- a/rules/macos/privilege_escalation_local_user_added_to_admin.toml
+++ b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
@@ -65,7 +65,7 @@ event.category:process and host.os.type:macos and event.type:(start or process_s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Admin Group Account Addition
 
diff --git a/rules/macos/privilege_escalation_root_crontab_filemod.toml b/rules/macos/privilege_escalation_root_crontab_filemod.toml
index 86405b2e937..7fa8bfb3add 100644
--- a/rules/macos/privilege_escalation_root_crontab_filemod.toml
+++ b/rules/macos/privilege_escalation_root_crontab_filemod.toml
@@ -64,7 +64,7 @@ event.category:file and host.os.type:macos and not event.type:deletion and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privilege Escalation via Root Crontab File Modification
 
diff --git a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
index dbc28783f8a..4e61efde0b8 100644
--- a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
@@ -82,7 +82,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 DNS Tunneling
 
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
index 86494e4517b..24c58f205c5 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
@@ -85,7 +85,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual DNS Activity
 DNS is crucial for translating domain names into IP addresses, enabling network communication. Adversaries exploit DNS by using rare domains for malicious activities like phishing or command-and-control. The 'Unusual DNS Activity' detection rule leverages machine learning to identify atypical DNS queries, signaling potential threats such as unauthorized access or data exfiltration.
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
index 82e617c6c58..52f2e5a1404 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
@@ -88,7 +88,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Web Request
 The 'Unusual Web Request' detection leverages machine learning to identify rare URLs that deviate from typical web activity, potentially signaling malicious actions like initial access or data exfiltration. Adversaries exploit trusted sites by embedding uncommon URLs for payload delivery or command-and-control. This rule flags such anomalies, aiding in early threat detection and response.
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
index 1ec179e39c8..e1c06752d74 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
@@ -86,7 +86,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Web User Agent
 
diff --git a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
index 6e0b05c6e0f..0d3d0f6141d 100644
--- a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
+++ b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
@@ -101,7 +101,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Logon Events
 The 'Spike in Logon Events' detection leverages machine learning to identify anomalies in authentication patterns, signaling potential threats like password spraying or brute force attacks. Adversaries exploit these methods to gain unauthorized access by overwhelming systems with login attempts. This rule detects unusual surges in successful logins, indicating possible credential access tactics, and aids in preemptive threat mitigation.
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
index b74e9c8a20a..10dfec5ecb6 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
@@ -87,7 +87,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux Process Calling the Metadata Service
 
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
index 3277fec81e1..afcd79982a6 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
@@ -87,7 +87,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux User Calling the Metadata Service
 
diff --git a/rules/ml/credential_access_ml_suspicious_login_activity.toml b/rules/ml/credential_access_ml_suspicious_login_activity.toml
index fa4ca3023ec..d220e5ebeb3 100644
--- a/rules/ml/credential_access_ml_suspicious_login_activity.toml
+++ b/rules/ml/credential_access_ml_suspicious_login_activity.toml
@@ -98,7 +98,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Login Activity
 The 'Unusual Login Activity' detection leverages machine learning to identify anomalies in authentication patterns, flagging potential brute force attacks. Adversaries exploit credential access by attempting numerous logins to gain unauthorized entry. This rule assesses login frequency and patterns, alerting analysts to deviations indicative of credential abuse, thus enhancing threat detection and identity audit processes.
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
index 2338c7c899c..10af80a11c5 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
@@ -83,7 +83,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Windows Process Calling the Metadata Service
 
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
index fb921e5d0a6..06ccee607b4 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
@@ -83,7 +83,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Windows User Calling the Metadata Service
 
diff --git a/rules/ml/discovery_ml_linux_system_information_discovery.toml b/rules/ml/discovery_ml_linux_system_information_discovery.toml
index c19ac969748..44f250de9d2 100644
--- a/rules/ml/discovery_ml_linux_system_information_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_information_discovery.toml
@@ -89,7 +89,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux System Information Discovery Activity
 
diff --git a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
index 1a179b9740e..b90e37526ae 100644
--- a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
@@ -89,7 +89,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux Network Configuration Discovery
 
diff --git a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
index 0d47bac1398..4774dd9e03c 100644
--- a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
@@ -89,7 +89,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux Network Connection Discovery
 
diff --git a/rules/ml/discovery_ml_linux_system_process_discovery.toml b/rules/ml/discovery_ml_linux_system_process_discovery.toml
index 693a4307405..ca2c23d6037 100644
--- a/rules/ml/discovery_ml_linux_system_process_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_process_discovery.toml
@@ -89,7 +89,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux Process Discovery Activity
 
diff --git a/rules/ml/discovery_ml_linux_system_user_discovery.toml b/rules/ml/discovery_ml_linux_system_user_discovery.toml
index 1d34ad725d6..3f9e43e3962 100644
--- a/rules/ml/discovery_ml_linux_system_user_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_user_discovery.toml
@@ -89,7 +89,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux User Discovery Activity
 
diff --git a/rules/ml/execution_ml_windows_anomalous_script.toml b/rules/ml/execution_ml_windows_anomalous_script.toml
index f79b1eace2c..988420775c4 100644
--- a/rules/ml/execution_ml_windows_anomalous_script.toml
+++ b/rules/ml/execution_ml_windows_anomalous_script.toml
@@ -87,7 +87,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Powershell Script
 
diff --git a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
index 0208ddf41a7..3b1764e2766 100644
--- a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
+++ b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
@@ -98,7 +98,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Source IP for a User to Logon from
 Machine learning models analyze login patterns to identify atypical IP addresses for users, which may indicate compromised accounts or lateral movement by threat actors. Adversaries exploit valid credentials to access systems from unexpected locations. This detection rule flags such anomalies, aiding in early identification of unauthorized access attempts, thereby enhancing security posture.
diff --git a/rules/ml/ml_high_count_network_denies.toml b/rules/ml/ml_high_count_network_denies.toml
index bdabd7f7dd9..e46cf2bf44a 100644
--- a/rules/ml/ml_high_count_network_denies.toml
+++ b/rules/ml/ml_high_count_network_denies.toml
@@ -79,7 +79,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Firewall Denies
 
diff --git a/rules/ml/ml_high_count_network_events.toml b/rules/ml/ml_high_count_network_events.toml
index 12799e14053..009e7697a0f 100644
--- a/rules/ml/ml_high_count_network_events.toml
+++ b/rules/ml/ml_high_count_network_events.toml
@@ -78,7 +78,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Spike in Network Traffic
 Machine learning models analyze network traffic patterns to identify anomalies, such as unexpected spikes. These spikes may indicate malicious activities like data exfiltration or denial-of-service attacks. Adversaries exploit network vulnerabilities to flood traffic or extract data. The 'Spike in Network Traffic' rule leverages ML to flag unusual traffic surges, aiding in early threat detection and response.
diff --git a/rules/ml/ml_linux_anomalous_network_port_activity.toml b/rules/ml/ml_linux_anomalous_network_port_activity.toml
index c1a96071828..40a9b30bd27 100644
--- a/rules/ml/ml_linux_anomalous_network_port_activity.toml
+++ b/rules/ml/ml_linux_anomalous_network_port_activity.toml
@@ -83,7 +83,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Linux Network Port Activity
 
diff --git a/rules/ml/ml_packetbeat_rare_server_domain.toml b/rules/ml/ml_packetbeat_rare_server_domain.toml
index 57fe994f004..e3f9eae65fb 100644
--- a/rules/ml/ml_packetbeat_rare_server_domain.toml
+++ b/rules/ml/ml_packetbeat_rare_server_domain.toml
@@ -86,7 +86,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Network Destination Domain Name
 
diff --git a/rules/ml/ml_rare_destination_country.toml b/rules/ml/ml_rare_destination_country.toml
index 196e8ff5677..d79f76aadb4 100644
--- a/rules/ml/ml_rare_destination_country.toml
+++ b/rules/ml/ml_rare_destination_country.toml
@@ -82,7 +82,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Traffic to Rare Destination Country
 
diff --git a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
index 6b2036b68d4..a63fccfa27a 100644
--- a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
@@ -88,7 +88,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Windows Path Activity
 
diff --git a/rules/ml/persistence_ml_windows_anomalous_service.toml b/rules/ml/persistence_ml_windows_anomalous_service.toml
index 0d07a56d34f..4991ae0fbc1 100644
--- a/rules/ml/persistence_ml_windows_anomalous_service.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_service.toml
@@ -85,7 +85,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Windows Service
 
diff --git a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
index 6ca5a51357e..c502666ba02 100644
--- a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
+++ b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
@@ -87,7 +87,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Sudo Activity
 
diff --git a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
index 13ce443332b..433c25e4ac2 100644
--- a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
+++ b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
@@ -85,7 +85,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Windows User Privilege Elevation Activity
 
diff --git a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
index 527bb6093cb..ccc1761d2af 100644
--- a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
+++ b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
@@ -88,7 +88,7 @@ type = "machine_learning"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Anomalous Linux Compiler Activity
 
diff --git a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
index 4a6ac7d9ae5..dbc9d225a31 100644
--- a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
+++ b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
@@ -52,7 +52,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Accepted Default Telnet Port Connection
 
diff --git a/rules/network/command_and_control_cobalt_strike_beacon.toml b/rules/network/command_and_control_cobalt_strike_beacon.toml
index a893732e175..5f0d92f1d9e 100644
--- a/rules/network/command_and_control_cobalt_strike_beacon.toml
+++ b/rules/network/command_and_control_cobalt_strike_beacon.toml
@@ -25,7 +25,7 @@ name = "Cobalt Strike Command and Control Beacon"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Cobalt Strike Command and Control Beacon
 
diff --git a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
index d36c34d32d5..d0dbe4ccc34 100644
--- a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
+++ b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
@@ -21,7 +21,7 @@ name = "Default Cobalt Strike Team Server Certificate"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Default Cobalt Strike Team Server Certificate
 
diff --git a/rules/network/command_and_control_download_rar_powershell_from_internet.toml b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
index 77756541be6..2c97384b518 100644
--- a/rules/network/command_and_control_download_rar_powershell_from_internet.toml
+++ b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
@@ -26,7 +26,7 @@ name = "Roshal Archive (RAR) or PowerShell File Downloaded from the Internet"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet
 
diff --git a/rules/network/command_and_control_halfbaked_beacon.toml b/rules/network/command_and_control_halfbaked_beacon.toml
index 596e6fc33f4..c581865d6b2 100644
--- a/rules/network/command_and_control_halfbaked_beacon.toml
+++ b/rules/network/command_and_control_halfbaked_beacon.toml
@@ -24,7 +24,7 @@ name = "Halfbaked Command and Control Beacon"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Halfbaked Command and Control Beacon
 
diff --git a/rules/network/command_and_control_nat_traversal_port_activity.toml b/rules/network/command_and_control_nat_traversal_port_activity.toml
index 2ef50d5c32a..8755f2c5024 100644
--- a/rules/network/command_and_control_nat_traversal_port_activity.toml
+++ b/rules/network/command_and_control_nat_traversal_port_activity.toml
@@ -38,7 +38,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 IPSEC NAT Traversal Port Activity
 
diff --git a/rules/network/command_and_control_port_26_activity.toml b/rules/network/command_and_control_port_26_activity.toml
index efb432dd0ca..fbb66f22cbe 100644
--- a/rules/network/command_and_control_port_26_activity.toml
+++ b/rules/network/command_and_control_port_26_activity.toml
@@ -39,7 +39,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SMTP on Port 26/TCP
 
diff --git a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
index b18ea2517f5..519c24198da 100644
--- a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
+++ b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
@@ -77,7 +77,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 RDP (Remote Desktop Protocol) from the Internet
 
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
index f54e7110307..12a067a7e45 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
@@ -73,7 +73,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 VNC (Virtual Network Computing) from the Internet
 
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
index b090c72300a..b6d384fd35c 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
@@ -73,7 +73,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 VNC (Virtual Network Computing) to the Internet
 
diff --git a/rules/network/discovery_potential_network_sweep_detected.toml b/rules/network/discovery_potential_network_sweep_detected.toml
index 7a820bdef70..e425044c4ae 100644
--- a/rules/network/discovery_potential_network_sweep_detected.toml
+++ b/rules/network/discovery_potential_network_sweep_detected.toml
@@ -40,7 +40,7 @@ source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Network Sweep Detected
 
diff --git a/rules/network/discovery_potential_port_scan_detected.toml b/rules/network/discovery_potential_port_scan_detected.toml
index d7027d60f63..08b9fa9c427 100644
--- a/rules/network/discovery_potential_port_scan_detected.toml
+++ b/rules/network/discovery_potential_port_scan_detected.toml
@@ -40,7 +40,7 @@ destination.port : * and event.action : "network_flow" and source.ip : (10.0.0.0
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Network Scan Detected
 
diff --git a/rules/network/discovery_potential_syn_port_scan_detected.toml b/rules/network/discovery_potential_syn_port_scan_detected.toml
index 769793bfc66..f885bc6865a 100644
--- a/rules/network/discovery_potential_syn_port_scan_detected.toml
+++ b/rules/network/discovery_potential_syn_port_scan_detected.toml
@@ -40,7 +40,7 @@ destination.port : * and network.packets <= 2 and source.ip : (10.0.0.0/8 or 172
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential SYN-Based Port Scan Detected
 
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
index 15dc1128feb..3a4cc537d4a 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
@@ -65,7 +65,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 RPC (Remote Procedure Call) from the Internet
 
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
index c8e3273c24b..22d35f5a60c 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
@@ -65,7 +65,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 RPC (Remote Procedure Call) to the Internet
 
diff --git a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
index bbabffd04b1..1cab816a53e 100644
--- a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
+++ b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
@@ -65,7 +65,7 @@ query = '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SMB (Windows File Sharing) Activity to the Internet
 
diff --git a/rules/network/initial_access_unsecure_elasticsearch_node.toml b/rules/network/initial_access_unsecure_elasticsearch_node.toml
index 2e9b1b4b6f2..56eb849a18d 100644
--- a/rules/network/initial_access_unsecure_elasticsearch_node.toml
+++ b/rules/network/initial_access_unsecure_elasticsearch_node.toml
@@ -24,7 +24,7 @@ name = "Inbound Connection to an Unsecure Elasticsearch Node"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Inbound Connection to an Unsecure Elasticsearch Node
 
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
index 50bca42993e..ca087587001 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:detection an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Credential Dumping - Detected - Elastic Endgame
 
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
index 5e548712540..beb05b4582b 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:prevention a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Credential Dumping - Prevented - Elastic Endgame
 
diff --git a/rules/promotions/endgame_adversary_behavior_detected.toml b/rules/promotions/endgame_adversary_behavior_detected.toml
index 1fb53f5e198..6879227863f 100644
--- a/rules/promotions/endgame_adversary_behavior_detected.toml
+++ b/rules/promotions/endgame_adversary_behavior_detected.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and (event.action:behavior_protection_
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Adversary Behavior - Detected - Elastic Endgame
 
diff --git a/rules/promotions/endgame_malware_detected.toml b/rules/promotions/endgame_malware_detected.toml
index 516eb518a45..333502f032f 100644
--- a/rules/promotions/endgame_malware_detected.toml
+++ b/rules/promotions/endgame_malware_detected.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:detection an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Malware - Detected - Elastic Endgame
 
diff --git a/rules/promotions/endgame_malware_prevented.toml b/rules/promotions/endgame_malware_prevented.toml
index c2758e826b3..7d5edb4857c 100644
--- a/rules/promotions/endgame_malware_prevented.toml
+++ b/rules/promotions/endgame_malware_prevented.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:prevention a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Malware - Prevented - Elastic Endgame
 
diff --git a/rules/promotions/endgame_ransomware_detected.toml b/rules/promotions/endgame_ransomware_detected.toml
index 379a8492e7d..f872b2aae4a 100644
--- a/rules/promotions/endgame_ransomware_detected.toml
+++ b/rules/promotions/endgame_ransomware_detected.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:detection an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Ransomware - Detected - Elastic Endgame
 
diff --git a/rules/promotions/endgame_ransomware_prevented.toml b/rules/promotions/endgame_ransomware_prevented.toml
index fe30012c226..7cebc2428df 100644
--- a/rules/promotions/endgame_ransomware_prevented.toml
+++ b/rules/promotions/endgame_ransomware_prevented.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:prevention a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Ransomware - Prevented - Elastic Endgame
 
diff --git a/rules/promotions/execution_endgame_exploit_detected.toml b/rules/promotions/execution_endgame_exploit_detected.toml
index ceddf21428d..9c1e1619837 100644
--- a/rules/promotions/execution_endgame_exploit_detected.toml
+++ b/rules/promotions/execution_endgame_exploit_detected.toml
@@ -44,7 +44,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:detection an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Exploit - Detected - Elastic Endgame
 
diff --git a/rules/promotions/execution_endgame_exploit_prevented.toml b/rules/promotions/execution_endgame_exploit_prevented.toml
index e7c52fc16f1..94e90088fee 100644
--- a/rules/promotions/execution_endgame_exploit_prevented.toml
+++ b/rules/promotions/execution_endgame_exploit_prevented.toml
@@ -44,7 +44,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:prevention a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Exploit - Prevented - Elastic Endgame
 
diff --git a/rules/promotions/external_alerts.toml b/rules/promotions/external_alerts.toml
index 87fd3f60609..4ed361477e7 100644
--- a/rules/promotions/external_alerts.toml
+++ b/rules/promotions/external_alerts.toml
@@ -46,7 +46,7 @@ event.kind:alert and not event.module:(endgame or endpoint or cloud_defend)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 External Alerts
 
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
index 85c5e0d063b..e1ce1f731aa 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:detection an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Credential Manipulation - Detected - Elastic Endgame
 
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
index 0473c9c728b..2a0c4d7e60d 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:prevention a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Credential Manipulation - Prevented - Elastic Endgame
 
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
index 3313a4fe13d..4752a342c51 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:detection an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Permission Theft - Detected - Elastic Endgame
 
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
index 8348b3462d7..8e40425bb5c 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:prevention a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Permission Theft - Prevented - Elastic Endgame
 
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
index e63e54f280a..3568eb7aacd 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:detection an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Injection - Detected - Elastic Endgame
 
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
index e2a0b0b86ca..e083a1f6b8d 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
@@ -39,7 +39,7 @@ event.kind:alert and event.module:endgame and endgame.metadata.type:prevention a
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Injection - Prevented - Elastic Endgame
 
diff --git a/rules/windows/collection_email_outlook_mailbox_via_com.toml b/rules/windows/collection_email_outlook_mailbox_via_com.toml
index 4d304d8e496..759044cec38 100644
--- a/rules/windows/collection_email_outlook_mailbox_via_com.toml
+++ b/rules/windows/collection_email_outlook_mailbox_via_com.toml
@@ -39,7 +39,7 @@ sequence with maxspan=1m
       "cmd.exe", "regsvr32.exe", "cscript.exe", "wscript.exe"
     ) or
     (
-      (process.code_signature.trusted == false or process.code_signature.exists == false) and 
+      (process.code_signature.trusted == false or process.code_signature.exists == false) and
       (process.Ext.relative_file_creation_time <= 500 or process.Ext.relative_file_name_modify_time <= 500)
     )
   )
@@ -50,7 +50,7 @@ sequence with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Inter-Process Communication via Outlook
 
diff --git a/rules/windows/collection_posh_webcam_video_capture.toml b/rules/windows/collection_posh_webcam_video_capture.toml
index cd4c2eed179..b09ba8f6f20 100644
--- a/rules/windows/collection_posh_webcam_video_capture.toml
+++ b/rules/windows/collection_posh_webcam_video_capture.toml
@@ -70,7 +70,7 @@ event.category:process and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Webcam Video Capture Capabilities
 
diff --git a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
index 213e3703679..e90c4f69a96 100644
--- a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
+++ b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
@@ -58,7 +58,7 @@ network where host.os.type == "windows" and network.protocol == "dns" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Connection to Commonly Abused Free SSL Certificate Providers
 
diff --git a/rules/windows/command_and_control_iexplore_via_com.toml b/rules/windows/command_and_control_iexplore_via_com.toml
index 9bafb1266ca..f1816e9c42c 100644
--- a/rules/windows/command_and_control_iexplore_via_com.toml
+++ b/rules/windows/command_and_control_iexplore_via_com.toml
@@ -52,7 +52,7 @@ sequence by host.id, user.name with maxspan = 5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Command and Control via Internet Explorer
 
diff --git a/rules/windows/command_and_control_outlook_home_page.toml b/rules/windows/command_and_control_outlook_home_page.toml
index 8524784e187..1ddd1024b75 100644
--- a/rules/windows/command_and_control_outlook_home_page.toml
+++ b/rules/windows/command_and_control_outlook_home_page.toml
@@ -52,7 +52,7 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Outlook Home Page Registry Modification
 
diff --git a/rules/windows/command_and_control_screenconnect_childproc.toml b/rules/windows/command_and_control_screenconnect_childproc.toml
index 078062cd8f7..4e7662b6837 100644
--- a/rules/windows/command_and_control_screenconnect_childproc.toml
+++ b/rules/windows/command_and_control_screenconnect_childproc.toml
@@ -62,7 +62,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious ScreenConnect Client Child Process
 
diff --git a/rules/windows/command_and_control_tunnel_vscode.toml b/rules/windows/command_and_control_tunnel_vscode.toml
index e2e6141f8a4..e565fb50fec 100644
--- a/rules/windows/command_and_control_tunnel_vscode.toml
+++ b/rules/windows/command_and_control_tunnel_vscode.toml
@@ -42,13 +42,13 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
-  process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and 
+  process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and
   not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Establish VScode Remote Tunnel
 
diff --git a/rules/windows/credential_access_adidns_wildcard.toml b/rules/windows/credential_access_adidns_wildcard.toml
index 246b3c1e8fc..9f9f330defe 100644
--- a/rules/windows/credential_access_adidns_wildcard.toml
+++ b/rules/windows/credential_access_adidns_wildcard.toml
@@ -69,7 +69,7 @@ any where host.os.type == "windows" and event.action in ("Directory Service Chan
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential ADIDNS Poisoning via Wildcard Record Creation
 
diff --git a/rules/windows/credential_access_adidns_wpad_record.toml b/rules/windows/credential_access_adidns_wpad_record.toml
index 891d1c9a237..d6b8200d721 100644
--- a/rules/windows/credential_access_adidns_wpad_record.toml
+++ b/rules/windows/credential_access_adidns_wpad_record.toml
@@ -66,7 +66,7 @@ any where host.os.type == "windows" and event.action in ("Directory Service Chan
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential WPAD Spoofing via DNS Record Creation
 
diff --git a/rules/windows/credential_access_dcsync_user_backdoor.toml b/rules/windows/credential_access_dcsync_user_backdoor.toml
index 34eb9d57106..a2849d47689 100644
--- a/rules/windows/credential_access_dcsync_user_backdoor.toml
+++ b/rules/windows/credential_access_dcsync_user_backdoor.toml
@@ -20,7 +20,7 @@ name = "Potential Active Directory Replication Account Backdoor"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Active Directory Replication Account Backdoor
 
diff --git a/rules/windows/credential_access_dnsnode_creation.toml b/rules/windows/credential_access_dnsnode_creation.toml
index 4befb35a940..5a2a7c7b306 100644
--- a/rules/windows/credential_access_dnsnode_creation.toml
+++ b/rules/windows/credential_access_dnsnode_creation.toml
@@ -70,7 +70,7 @@ any where host.os.type == "windows" and event.action in ("Directory Service Chan
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation of a DNS-Named Record
 
diff --git a/rules/windows/credential_access_dollar_account_relay.toml b/rules/windows/credential_access_dollar_account_relay.toml
index e6ee0d8a771..ecf3d1f46db 100644
--- a/rules/windows/credential_access_dollar_account_relay.toml
+++ b/rules/windows/credential_access_dollar_account_relay.toml
@@ -45,7 +45,7 @@ authentication where host.os.type == "windows" and event.code in ("4624", "4625"
 
     /* Filter for a machine account that matches the hostname */
     startswith~(host.name, substring(user.name, 0, -1)) and
-    
+
     /* Verify if the Source IP belongs to the host */
     not endswith(string(source.ip), string(host.ip)) and
     source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"
@@ -53,7 +53,7 @@ authentication where host.os.type == "windows" and event.code in ("4624", "4625"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Relay Attack against a Domain Controller
 
diff --git a/rules/windows/credential_access_generic_localdumps.toml b/rules/windows/credential_access_generic_localdumps.toml
index fab82cacb2f..da4fc4b3400 100644
--- a/rules/windows/credential_access_generic_localdumps.toml
+++ b/rules/windows/credential_access_generic_localdumps.toml
@@ -53,7 +53,7 @@ registry where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Full User-Mode Dumps Enabled System-Wide
 
diff --git a/rules/windows/credential_access_iis_connectionstrings_dumping.toml b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
index 0dd24585fda..4ca7183983a 100644
--- a/rules/windows/credential_access_iis_connectionstrings_dumping.toml
+++ b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
@@ -60,7 +60,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft IIS Connection Strings Decryption
 
diff --git a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
index 548a4e17b7b..1a00747e727 100644
--- a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
+++ b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
@@ -30,13 +30,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where host.os.type == "windows" and process.name : "AzureADConnectAuthenticationAgentService.exe" and 
+any where host.os.type == "windows" and process.name : "AzureADConnectAuthenticationAgentService.exe" and
 (
- (event.category == "library" and event.action == "load") or 
+ (event.category == "library" and event.action == "load") or
  (event.category == "process" and event.action : "Image loaded*")
-) and 
+) and
 
-not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid") and not 
+not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid") and not
 
   (
    /* Elastic defend DLL path */
@@ -44,8 +44,8 @@ not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid
          ("?:\\Windows\\assembly\\NativeImages*",
           "?:\\Windows\\Microsoft.NET\\*",
           "?:\\Windows\\WinSxS\\*",
-          "?:\\Windows\\System32\\DriverStore\\FileRepository\\*") or 
-          
+          "?:\\Windows\\System32\\DriverStore\\FileRepository\\*") or
+
    /* Sysmon DLL path is mapped to file.path */
    file.path :
          ("?:\\Windows\\assembly\\NativeImages*",
@@ -57,7 +57,7 @@ not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Untrusted DLL Loaded by Azure AD Sync Service
 
diff --git a/rules/windows/credential_access_kirbi_file.toml b/rules/windows/credential_access_kirbi_file.toml
index d1d1abc06c9..191b0c6ff8b 100644
--- a/rules/windows/credential_access_kirbi_file.toml
+++ b/rules/windows/credential_access_kirbi_file.toml
@@ -31,7 +31,7 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Kirbi File Creation
 
diff --git a/rules/windows/credential_access_ldap_attributes.toml b/rules/windows/credential_access_ldap_attributes.toml
index 0b6cb2794cc..7f4e92c8b31 100644
--- a/rules/windows/credential_access_ldap_attributes.toml
+++ b/rules/windows/credential_access_ldap_attributes.toml
@@ -83,7 +83,7 @@ any where event.action in ("Directory Service Access", "object-operation-perform
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Access to a Sensitive LDAP Attribute
 
diff --git a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
index 075d2a89f4b..5614cc3c570 100644
--- a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
+++ b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
@@ -53,7 +53,7 @@ process where host.os.type == "windows" and event.code == "10" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious LSASS Access via MalSecLogon
 
diff --git a/rules/windows/credential_access_lsass_loaded_susp_dll.toml b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
index 2dc2414c9ee..c5d0823c95e 100644
--- a/rules/windows/credential_access_lsass_loaded_susp_dll.toml
+++ b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
@@ -105,7 +105,7 @@ any where event.category in ("library", "driver") and host.os.type == "windows"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Module Loaded by LSASS
 
diff --git a/rules/windows/credential_access_posh_relay_tools.toml b/rules/windows/credential_access_posh_relay_tools.toml
index 4d8f8b6150a..84466912e4b 100644
--- a/rules/windows/credential_access_posh_relay_tools.toml
+++ b/rules/windows/credential_access_posh_relay_tools.toml
@@ -71,7 +71,7 @@ event.category:process and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential PowerShell Pass-the-Hash/Relay Script
 
diff --git a/rules/windows/credential_access_posh_veeam_sql.toml b/rules/windows/credential_access_posh_veeam_sql.toml
index b0673ac8b0a..b30f7a9f3a0 100644
--- a/rules/windows/credential_access_posh_veeam_sql.toml
+++ b/rules/windows/credential_access_posh_veeam_sql.toml
@@ -65,7 +65,7 @@ event.category:process and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Veeam Credential Access Capabilities
 
diff --git a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
index 7ad975bb7e7..e226babe99e 100644
--- a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
+++ b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
@@ -51,7 +51,7 @@ process where host.os.type == "windows" and event.code == "10" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Credential Access via DuplicateHandle in LSASS
 
diff --git a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
index 46a3947dd1e..c68f9dfcebd 100644
--- a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
+++ b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
@@ -65,7 +65,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Local NTLM Relay via HTTP
 
diff --git a/rules/windows/credential_access_saved_creds_vault_winlog.toml b/rules/windows/credential_access_saved_creds_vault_winlog.toml
index 694a6b35566..b8842df5e52 100644
--- a/rules/windows/credential_access_saved_creds_vault_winlog.toml
+++ b/rules/windows/credential_access_saved_creds_vault_winlog.toml
@@ -43,18 +43,18 @@ sequence by winlog.computer_name, winlog.process.pid with maxspan=1s
 
  [any where event.code : "5382" and
   (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
-  not winlog.event_data.SubjectLogonId : "0x3e7" and 
+  not winlog.event_data.SubjectLogonId : "0x3e7" and
   not winlog.event_data.Resource : "http://localhost/"]
 
  [any where event.code : "5382" and
   (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
-  not winlog.event_data.SubjectLogonId : "0x3e7" and 
+  not winlog.event_data.SubjectLogonId : "0x3e7" and
   not winlog.event_data.Resource : "http://localhost/"]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Multiple Vault Web Credentials Read
 
diff --git a/rules/windows/credential_access_saved_creds_vaultcmd.toml b/rules/windows/credential_access_saved_creds_vaultcmd.toml
index e23cf5e7953..267f0dbd4b3 100644
--- a/rules/windows/credential_access_saved_creds_vaultcmd.toml
+++ b/rules/windows/credential_access_saved_creds_vaultcmd.toml
@@ -60,7 +60,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Searching for Saved Credentials via VaultCmd
 
diff --git a/rules/windows/credential_access_suspicious_lsass_access_generic.toml b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
index a54cf39d632..485c11e23fd 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_generic.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
@@ -59,16 +59,16 @@ process where host.os.type == "windows" and event.code == "10" and
         "?:\\Windows\\system32\\wbem\\wmiprvse.exe",
         "?:\\Windows\\system32\\wininit.exe",
         "?:\\Windows\\SystemTemp\\GUM*.tmp\\GoogleUpdate.exe",
-        "?:\\Windows\\sysWOW64\\wbem\\wmiprvse.exe", 
-        "C:\\oracle\\64\\02\\instantclient_19_13\\sqlplus.exe", 
+        "?:\\Windows\\sysWOW64\\wbem\\wmiprvse.exe",
+        "C:\\oracle\\64\\02\\instantclient_19_13\\sqlplus.exe",
         "C:\\oracle\\64\\02\\instantclient_19_13\\sqlldr.exe",
         "d:\\oracle\\product\\19\\dbhome1\\bin\\ORACLE.EXE",
         "C:\\wamp\\bin\\apache\\apache*\\bin\\httpd.exe",
-        "C:\\Windows\\system32\\netstat.exe", 
-        "C:\\PROGRA~1\\INFORM~1\\apps\\jdk\\*\\jre\\bin\\java.exe", 
+        "C:\\Windows\\system32\\netstat.exe",
+        "C:\\PROGRA~1\\INFORM~1\\apps\\jdk\\*\\jre\\bin\\java.exe",
         "C:\\PROGRA~2\\CyberCNSAgentV2\\osqueryi.exe",
         "C:\\Utilityw2k19\\packetbeat\\packetbeat.exe",
-        "C:\\ProgramData\\Cisco\\Cisco AnyConnect Secure Mobility Client\\Temp\\CloudUpdate\\vpndownloader.exe", 
+        "C:\\ProgramData\\Cisco\\Cisco AnyConnect Secure Mobility Client\\Temp\\CloudUpdate\\vpndownloader.exe",
         "C:\\ProgramData\\Cisco\\Cisco Secure Client\\Temp\\CloudUpdate\\vpndownloader.exe"
   ) and
   not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*")
@@ -76,7 +76,7 @@ process where host.os.type == "windows" and event.code == "10" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Lsass Process Access
 
diff --git a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
index fbb03c918e6..0713059b17f 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
@@ -61,7 +61,7 @@ process where host.os.type == "windows" and event.code == "10" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Credential Access via LSASS Memory Dump
 
diff --git a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
index 948c585db92..87e1f659a5b 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
@@ -49,7 +49,7 @@ event.category:process and host.os.type:windows and event.code:10 and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential LSASS Memory Dump via PssCaptureSnapShot
 
diff --git a/rules/windows/credential_access_veeam_backup_dll_imageload.toml b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
index 9cd0afc27bc..bd118be9559 100644
--- a/rules/windows/credential_access_veeam_backup_dll_imageload.toml
+++ b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
@@ -41,7 +41,7 @@ library where host.os.type == "windows" and event.action == "load" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Veeam Backup Library Loaded by Unusual Process
 
diff --git a/rules/windows/credential_access_veeam_commands.toml b/rules/windows/credential_access_veeam_commands.toml
index c78ad2b384f..e6ef29d0af2 100644
--- a/rules/windows/credential_access_veeam_commands.toml
+++ b/rules/windows/credential_access_veeam_commands.toml
@@ -59,7 +59,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Veeam Credential Access Command
 
diff --git a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
index 96278b34ea3..5079015e5d8 100644
--- a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
+++ b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
@@ -53,7 +53,7 @@ process where host.os.type == "windows" and event.code:"4688" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential LSASS Clone Creation via PssCaptureSnapShot
 
diff --git a/rules/windows/credential_access_wbadmin_ntds.toml b/rules/windows/credential_access_wbadmin_ntds.toml
index 600faf981a8..4d4522c3505 100644
--- a/rules/windows/credential_access_wbadmin_ntds.toml
+++ b/rules/windows/credential_access_wbadmin_ntds.toml
@@ -51,13 +51,13 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
-    (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and 
+    (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and
      process.args : "recovery" and process.command_line : "*ntds.dit*"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 NTDS Dump via Wbadmin
 
diff --git a/rules/windows/defense_evasion_cve_2020_0601.toml b/rules/windows/defense_evasion_cve_2020_0601.toml
index 8b967a1007c..79b7ab563c4 100644
--- a/rules/windows/defense_evasion_cve_2020_0601.toml
+++ b/rules/windows/defense_evasion_cve_2020_0601.toml
@@ -37,7 +37,7 @@ event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" and h
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall)
 
diff --git a/rules/windows/defense_evasion_disable_nla.toml b/rules/windows/defense_evasion_disable_nla.toml
index 15c618a2f52..a800ded1b6a 100644
--- a/rules/windows/defense_evasion_disable_nla.toml
+++ b/rules/windows/defense_evasion_disable_nla.toml
@@ -51,7 +51,7 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network-Level Authentication (NLA) Disabled
 
diff --git a/rules/windows/defense_evasion_dns_over_https_enabled.toml b/rules/windows/defense_evasion_dns_over_https_enabled.toml
index 6d5021af34f..f0f86bece75 100644
--- a/rules/windows/defense_evasion_dns_over_https_enabled.toml
+++ b/rules/windows/defense_evasion_dns_over_https_enabled.toml
@@ -51,7 +51,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 DNS-over-HTTPS Enabled via Registry
 
diff --git a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
index dc3a7a6f4c6..7addd1e9894 100644
--- a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
+++ b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
@@ -55,7 +55,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious .NET Code Compilation
 
diff --git a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
index d5221ca2f18..3c0a9fa6229 100644
--- a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
+++ b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
@@ -50,7 +50,7 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
-  process.name : "control.exe" and 
+  process.name : "control.exe" and
   process.command_line : (
     "*.jpg*", "*.png*",
     "*.gif*", "*.bmp*",
@@ -65,7 +65,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Control Panel Process with Unusual Arguments
 
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
index e251faec73c..af1ce25d157 100755
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
@@ -42,14 +42,14 @@ type = "new_terms"
 
 query = '''
 host.os.type:windows and event.category:process and event.type:start and (
-  process.name.caseless:"msbuild.exe" or process.pe.original_file_name:"MSBuild.exe") and 
+  process.name.caseless:"msbuild.exe" or process.pe.original_file_name:"MSBuild.exe") and
   process.parent.name:("cmd.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "cscript.exe" or
     "wscript.exe" or "mshta.exe")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft Build Engine Started by a Script Process
 
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
index 664cec790d5..f79ddd1543f 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
@@ -56,7 +56,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft Build Engine Started by a System Process
 
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
index 79a9580145d..8019e38ae90 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
@@ -54,7 +54,7 @@ process.name:("csc.exe" or "iexplore.exe" or "powershell.exe")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft Build Engine Started an Unusual Process
 
diff --git a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
index 1779dcff668..ff70e0608ef 100644
--- a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
+++ b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
@@ -58,7 +58,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential DLL Side-Loading via Trusted Microsoft Programs
 
diff --git a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
index cccb6701f31..8783d5f48c5 100644
--- a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
+++ b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
@@ -62,7 +62,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential DLL Side-Loading via Microsoft Antimalware Service Executable
 
diff --git a/rules/windows/defense_evasion_file_creation_mult_extension.toml b/rules/windows/defense_evasion_file_creation_mult_extension.toml
index 62a852d1053..799681fa66f 100644
--- a/rules/windows/defense_evasion_file_creation_mult_extension.toml
+++ b/rules/windows/defense_evasion_file_creation_mult_extension.toml
@@ -44,7 +44,7 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Executable File Creation with Multiple Extensions
 
diff --git a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
index 34404a28ec3..9a21607c774 100644
--- a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
+++ b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
@@ -32,7 +32,7 @@ registry where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Encoded Executable Stored in the Registry
 
diff --git a/rules/windows/defense_evasion_injection_msbuild.toml b/rules/windows/defense_evasion_injection_msbuild.toml
index 41c8747ec4d..5f30009ec7f 100755
--- a/rules/windows/defense_evasion_injection_msbuild.toml
+++ b/rules/windows/defense_evasion_injection_msbuild.toml
@@ -38,7 +38,7 @@ process where host.os.type == "windows" and process.name: "MSBuild.exe" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Injection by the Microsoft Build Engine
 
diff --git a/rules/windows/defense_evasion_installutil_beacon.toml b/rules/windows/defense_evasion_installutil_beacon.toml
index b32862e2dcf..e05dac115d5 100644
--- a/rules/windows/defense_evasion_installutil_beacon.toml
+++ b/rules/windows/defense_evasion_installutil_beacon.toml
@@ -45,7 +45,7 @@ sequence by process.entity_id
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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
 
diff --git a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
index 4aca06bb77a..a22ae82449a 100644
--- a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
+++ b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
@@ -58,7 +58,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution via Windows Command Debugging Utility
 
diff --git a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
index b6177118795..b07eb993349 100644
--- a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
+++ b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
@@ -74,7 +74,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Endpoint Security Parent Process
 
diff --git a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
index 9baf3de0d59..21ae1b42bb3 100644
--- a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
+++ b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
@@ -166,7 +166,7 @@ process where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Masquerading as Business App Installer
 
diff --git a/rules/windows/defense_evasion_masquerading_communication_apps.toml b/rules/windows/defense_evasion_masquerading_communication_apps.toml
index 6a8fa9e23ad..4b23f49e150 100644
--- a/rules/windows/defense_evasion_masquerading_communication_apps.toml
+++ b/rules/windows/defense_evasion_masquerading_communication_apps.toml
@@ -93,7 +93,7 @@ process where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Masquerading as Communication Apps
 
diff --git a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
index fc8a23b75c6..7dd3f37e2c5 100644
--- a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
+++ b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
@@ -63,7 +63,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious WerFault Child Process
 
diff --git a/rules/windows/defense_evasion_masquerading_trusted_directory.toml b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
index 29e6592ece3..9588637479f 100644
--- a/rules/windows/defense_evasion_masquerading_trusted_directory.toml
+++ b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
@@ -78,7 +78,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Program Files Directory Masquerading
 
diff --git a/rules/windows/defense_evasion_mshta_beacon.toml b/rules/windows/defense_evasion_mshta_beacon.toml
index 975894325db..b4aedf2d7bf 100644
--- a/rules/windows/defense_evasion_mshta_beacon.toml
+++ b/rules/windows/defense_evasion_mshta_beacon.toml
@@ -50,7 +50,7 @@ sequence by process.entity_id with maxspan=10m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Mshta Making Network Connections
 
diff --git a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
index 1e6d83350b5..0ac8984bed6 100644
--- a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
+++ b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
@@ -51,7 +51,7 @@ sequence by process.entity_id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 MsiExec Service Child Process With Network Connection
 
diff --git a/rules/windows/defense_evasion_msxsl_network.toml b/rules/windows/defense_evasion_msxsl_network.toml
index da8423c925e..df4d0df5c3a 100644
--- a/rules/windows/defense_evasion_msxsl_network.toml
+++ b/rules/windows/defense_evasion_msxsl_network.toml
@@ -49,7 +49,7 @@ sequence by process.entity_id
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Connection via MsXsl
 
diff --git a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
index a877b60cf48..06a1944df1e 100644
--- a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
+++ b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
@@ -35,39 +35,39 @@ type = "eql"
 query = '''
 /* This rule is compatible with Elastic Endpoint only */
 
-sequence by host.id, user.id with maxspan=3m 
+sequence by host.id, user.id with maxspan=3m
 
  [process where host.os.type == "windows" and event.type == "start" and
-  process.Ext.token.integrity_level_name != "system" and 
+  process.Ext.token.integrity_level_name != "system" and
   (
     process.pe.original_file_name : ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe", "eqnedt32.exe",
                                      "fltldr.exe", "mspub.exe", "msaccess.exe", "powershell.exe", "pwsh.exe",
                                      "cscript.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "msbuild.exe",
-                                     "mshta.exe", "wmic.exe", "cmstp.exe", "msxsl.exe") or 
-                                     
+                                     "mshta.exe", "wmic.exe", "cmstp.exe", "msxsl.exe") or
+
     (process.executable : ("?:\\Users\\*.exe",
                            "?:\\ProgramData\\*.exe",
                            "?:\\Windows\\Temp\\*.exe",
-                           "?:\\Windows\\Tasks\\*") and 
-      (process.code_signature.exists == false or process.code_signature.status : "errorBadDigest")) or 
-                          
-    process.executable : "?:\\Windows\\Microsoft.NET\\*.exe"                      
-  ) and 
-  
-  not process.executable : 
-             ("?:\\Windows\\System32\\WerFaultSecure.exe", 
+                           "?:\\Windows\\Tasks\\*") and
+      (process.code_signature.exists == false or process.code_signature.status : "errorBadDigest")) or
+
+    process.executable : "?:\\Windows\\Microsoft.NET\\*.exe"
+  ) and
+
+  not process.executable :
+             ("?:\\Windows\\System32\\WerFaultSecure.exe",
               "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe",
               "?:\\Windows\\System32\\WerFault.exe",
               "?:\\Windows\\SysWOW64\\WerFault.exe")
   ] by process.pid
  [process where host.os.type == "windows" and event.type == "start" and
-  process.parent.Ext.real.pid > 0 and 
- 
+  process.parent.Ext.real.pid > 0 and
+
   /* process.parent.Ext.real.pid is only populated if the parent process pid doesn't match */
-  not (process.name : "msedge.exe" and process.parent.name : "sihost.exe") and 
-  
-   not process.executable : 
-             ("?:\\Windows\\System32\\WerFaultSecure.exe", 
+  not (process.name : "msedge.exe" and process.parent.name : "sihost.exe") and
+
+   not process.executable :
+             ("?:\\Windows\\System32\\WerFaultSecure.exe",
               "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe",
               "?:\\Windows\\System32\\WerFault.exe",
               "?:\\Windows\\SysWOW64\\WerFault.exe")
@@ -76,7 +76,7 @@ sequence by host.id, user.id with maxspan=3m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Parent Process PID Spoofing
 
diff --git a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
index 7e006d0bd06..da759a65a09 100644
--- a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
+++ b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
@@ -53,7 +53,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Local Account TokenFilter Policy Disabled
 
diff --git a/rules/windows/defense_evasion_posh_obfuscation.toml b/rules/windows/defense_evasion_posh_obfuscation.toml
index ee546d65188..86d61ee9038 100644
--- a/rules/windows/defense_evasion_posh_obfuscation.toml
+++ b/rules/windows/defense_evasion_posh_obfuscation.toml
@@ -69,7 +69,7 @@ event.category:process and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential PowerShell Obfuscated Script
 
diff --git a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
index d2cffe567b0..a7c64f85735 100644
--- a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
+++ b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
@@ -55,7 +55,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Microsoft Diagnostics Wizard Execution
 
diff --git a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
index 04f0884e0e9..19915621cd3 100644
--- a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
+++ b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
@@ -58,7 +58,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 DNS Global Query Block List Modified or Disabled
 
diff --git a/rules/windows/defense_evasion_root_dir_ads_creation.toml b/rules/windows/defense_evasion_root_dir_ads_creation.toml
index 0d05950312b..3cca1c8c48f 100644
--- a/rules/windows/defense_evasion_root_dir_ads_creation.toml
+++ b/rules/windows/defense_evasion_root_dir_ads_creation.toml
@@ -44,16 +44,16 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where host.os.type == "windows" and event.category in ("file", "process") and 
+any where host.os.type == "windows" and event.category in ("file", "process") and
   (
-    (event.type == "creation" and file.path regex~ """[A-Z]:\\:.+""") or 
+    (event.type == "creation" and file.path regex~ """[A-Z]:\\:.+""") or
     (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""")
   )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Alternate Data Stream Creation/Execution at Volume Root Directory
 
diff --git a/rules/windows/defense_evasion_sc_sdset.toml b/rules/windows/defense_evasion_sc_sdset.toml
index cda6a7fb1c3..3bb8cbf9a1c 100644
--- a/rules/windows/defense_evasion_sc_sdset.toml
+++ b/rules/windows/defense_evasion_sc_sdset.toml
@@ -50,7 +50,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Service DACL Modification via sc.exe
 
diff --git a/rules/windows/defense_evasion_sccm_scnotification_dll.toml b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
index e08c10a7bac..ce7f3d1945a 100644
--- a/rules/windows/defense_evasion_sccm_scnotification_dll.toml
+++ b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
@@ -39,7 +39,7 @@ library where host.os.type == "windows" and process.name : "SCNotification.exe"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Windows Session Hijacking via CcmExec
 
diff --git a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
index ed84b7eb9db..d7e025b9080 100644
--- a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
+++ b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
@@ -48,7 +48,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Scheduled Tasks AT Command Enabled
 
diff --git a/rules/windows/defense_evasion_script_via_html_app.toml b/rules/windows/defense_evasion_script_via_html_app.toml
index b3853ec371a..0fd01778684 100644
--- a/rules/windows/defense_evasion_script_via_html_app.toml
+++ b/rules/windows/defense_evasion_script_via_html_app.toml
@@ -82,7 +82,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Script Execution via Microsoft HTML Application
 
diff --git a/rules/windows/defense_evasion_sip_provider_mod.toml b/rules/windows/defense_evasion_sip_provider_mod.toml
index f729e670df1..19331910249 100644
--- a/rules/windows/defense_evasion_sip_provider_mod.toml
+++ b/rules/windows/defense_evasion_sip_provider_mod.toml
@@ -51,7 +51,7 @@ registry where host.os.type == "windows" and event.type == "change" and registry
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SIP Provider Modification
 
diff --git a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
index e7a1d34f75c..fdbf6b09ae8 100644
--- a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
+++ b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
@@ -59,7 +59,7 @@ registry where host.os.type == "windows" and event.type == "change" and registry
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SolarWinds Process Disabling Services via Registry
 
diff --git a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
index db9d7220038..f39fc337369 100644
--- a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
+++ b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
@@ -54,7 +54,7 @@ process where host.os.type == "windows" and event.type == "start" and process.ex
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Execution from a Mounted Device
 
diff --git a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
index 34412f928c2..469163116e8 100644
--- a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
+++ b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
@@ -52,7 +52,7 @@ file where host.os.type == "windows" and event.type != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Managed Code Hosting Process
 
diff --git a/rules/windows/defense_evasion_suspicious_scrobj_load.toml b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
index b85cf9342dd..c0ae6fd896f 100644
--- a/rules/windows/defense_evasion_suspicious_scrobj_load.toml
+++ b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
@@ -33,10 +33,10 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where host.os.type == "windows" and 
- (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and 
- (?dll.name : "scrobj.dll" or ?file.name : "scrobj.dll") and 
- process.executable : ("?:\\Windows\\System32\\*.exe", "?:\\Windows\\SysWOW64\\*.exe") and 
+any where host.os.type == "windows" and
+ (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and
+ (?dll.name : "scrobj.dll" or ?file.name : "scrobj.dll") and
+ process.executable : ("?:\\Windows\\System32\\*.exe", "?:\\Windows\\SysWOW64\\*.exe") and
  not process.executable : (
        "?:\\Windows\\System32\\cscript.exe",
        "?:\\Windows\\SysWOW64\\cscript.exe",
@@ -52,7 +52,7 @@ any where host.os.type == "windows" and
        "?:\\Windows\\system32\\mobsync.exe",
        "?:\\Windows\\SysWOW64\\mobsync.exe",
        "?:\\Windows\\System32\\cmd.exe",
-       "?:\\Windows\\SysWOW64\\cmd.exe", 
+       "?:\\Windows\\SysWOW64\\cmd.exe",
        "?:\\Windows\\System32\\OpenWith.exe",
        "?:\\Windows\\System32\\wbem\\WMIADAP.exe",
        "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe")
@@ -60,7 +60,7 @@ any where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Script Object Execution
 
diff --git a/rules/windows/defense_evasion_suspicious_wmi_script.toml b/rules/windows/defense_evasion_suspicious_wmi_script.toml
index fbfd68fdc08..1c6049098fc 100644
--- a/rules/windows/defense_evasion_suspicious_wmi_script.toml
+++ b/rules/windows/defense_evasion_suspicious_wmi_script.toml
@@ -48,7 +48,7 @@ sequence by process.entity_id with maxspan = 2m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious WMIC XSL Script Execution
 
diff --git a/rules/windows/defense_evasion_timestomp_sysmon.toml b/rules/windows/defense_evasion_timestomp_sysmon.toml
index e9b6a211fcf..88b4706e8cd 100644
--- a/rules/windows/defense_evasion_timestomp_sysmon.toml
+++ b/rules/windows/defense_evasion_timestomp_sysmon.toml
@@ -35,29 +35,29 @@ query = '''
 file where host.os.type == "windows" and event.code : "2" and
 
  /* Requires Sysmon EventID 2 - File creation time change */
- event.action : "File creation time changed*" and 
- 
- not process.executable : 
-          ("?:\\Program Files\\*", 
-           "?:\\Program Files (x86)\\*", 
+ event.action : "File creation time changed*" and
+
+ not process.executable :
+          ("?:\\Program Files\\*",
+           "?:\\Program Files (x86)\\*",
            "?:\\Windows\\system32\\cleanmgr.exe",
-           "?:\\Windows\\system32\\msiexec.exe", 
-           "?:\\Windows\\syswow64\\msiexec.exe", 
-           "?:\\Windows\\system32\\svchost.exe", 
+           "?:\\Windows\\system32\\msiexec.exe",
+           "?:\\Windows\\syswow64\\msiexec.exe",
+           "?:\\Windows\\system32\\svchost.exe",
            "?:\\WINDOWS\\system32\\backgroundTaskHost.exe",
-           "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe", 
+           "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
            "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe",
-           "?:\\Users\\*\\AppData\\Local\\slack\\app-*\\slack.exe", 
+           "?:\\Users\\*\\AppData\\Local\\slack\\app-*\\slack.exe",
            "?:\\Users\\*\\AppData\\Local\\GitHubDesktop\\app-*\\GitHubDesktop.exe",
-           "?:\\Users\\*\\AppData\\Local\\Microsoft\\Teams\\current\\Teams.exe", 
-           "?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\OneDrive.exe") and 
+           "?:\\Users\\*\\AppData\\Local\\Microsoft\\Teams\\current\\Teams.exe",
+           "?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\OneDrive.exe") and
  not file.extension : ("temp", "tmp", "~tmp", "xml", "newcfg") and not user.name : ("SYSTEM", "Local Service", "Network Service") and
  not file.name : ("LOG", "temp-index", "license.rtf", "iconcache_*.db")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File Creation Time Changed
 File creation timestamps are crucial for tracking file history and integrity. Adversaries may alter these timestamps, a tactic known as timestomping, to disguise malicious files as benign. This detection rule leverages Sysmon logs to identify suspicious changes in file creation times, excluding trusted processes and file types, thus highlighting potential evasion attempts by attackers.
diff --git a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
index c8602abe2bd..cfa2ee3b6ac 100644
--- a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
+++ b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
@@ -43,12 +43,12 @@ type = "eql"
 query = '''
 library where host.os.type == "windows" and
 
- process.code_signature.trusted == true and 
- 
- (dll.Ext.relative_file_creation_time <= 500 or dll.Ext.relative_file_name_modify_time <= 500) and 
- 
-  not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining") and 
-  
+ process.code_signature.trusted == true and
+
+ (dll.Ext.relative_file_creation_time <= 500 or dll.Ext.relative_file_name_modify_time <= 500) and
+
+  not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining") and
+
       /* Suspicious Paths */
       dll.path : ("?:\\PerfLogs\\*.dll",
                   "?:\\Users\\*\\Pictures\\*.dll",
@@ -120,15 +120,15 @@ library where host.os.type == "windows" and
                   "?:\\Windows\\LiveKernelReports\\*.dll",
                   "?:\\Windows\\ModemLogs\\*.dll",
                   "?:\\Windows\\ImmersiveControlPanel\\*.dll",
-                  "?:\\$Recycle.Bin\\*.dll") and 
-	 
+                  "?:\\$Recycle.Bin\\*.dll") and
+
 	 /* DLL loaded from the process.executable current directory */
 	 endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unsigned DLL Side-Loading from a Suspicious Folder
 
diff --git a/rules/windows/defense_evasion_unusual_dir_ads.toml b/rules/windows/defense_evasion_unusual_dir_ads.toml
index 08fb59cfba8..8233ea44661 100644
--- a/rules/windows/defense_evasion_unusual_dir_ads.toml
+++ b/rules/windows/defense_evasion_unusual_dir_ads.toml
@@ -42,7 +42,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process Execution Path - Alternate Data Stream
 
diff --git a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
index 746be96af71..ad041ece384 100644
--- a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
+++ b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
@@ -53,7 +53,7 @@ sequence by host.id, process.entity_id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Network Connection via DllHost
 
diff --git a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
index 2321bdd1cd9..642462efdd6 100644
--- a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
+++ b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
@@ -49,7 +49,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Child Process from a System Virtual Process
 
diff --git a/rules/windows/defense_evasion_windows_filtering_platform.toml b/rules/windows/defense_evasion_windows_filtering_platform.toml
index ba8acd7b348..c5fc9d3d38d 100644
--- a/rules/windows/defense_evasion_windows_filtering_platform.toml
+++ b/rules/windows/defense_evasion_windows_filtering_platform.toml
@@ -55,8 +55,8 @@ type = "eql"
 
 query = '''
 sequence by winlog.computer_name with maxspan=1m
- [network where host.os.type == "windows" and 
-  event.action : ("windows-firewall-packet-block", "windows-firewall-packet-drop") and 
+ [network where host.os.type == "windows" and
+  event.action : ("windows-firewall-packet-block", "windows-firewall-packet-drop") and
   process.name : (
         "bdagent.exe", "bdreinit.exe", "pdscan.exe", "pdiface.exe", "BDSubWiz.exe", "ProductAgentService.exe",
         "ProductAgentUI.exe", "WatchDog.exe", "CarbonBlackClientSetup.exe", "TrGUI.exe", "TracCAPI.exe", "cpmsi_tool.exe",
@@ -75,7 +75,7 @@ sequence by winlog.computer_name with maxspan=1m
         "mbae.exe", "mbae64.exe", "mbae-svc.exe", "mbae-uninstaller.exe", "mbaeLoader32.exe", "mbaeloader64.exe",
         "mbam-dor.exe", "mbamgui.exe", "mbamservice.exe", "mbamtrayctrl.exe", "mbampt.exe", "mbamscheduler.exe",
         "Coreinst.exe", "mbae-setup.exe", "mcupdate.exe", "ProtectedModuleHost.exe", "ESConfigTool.exe", "FWInstCheck.exe",
-        "FwWindowsFirewallHandler.exe", "mfeesp.exe", "mfefw.exe", "mfeProvisionModeUtility.exe", "mfetp.exe", "avpui.exe", 
+        "FwWindowsFirewallHandler.exe", "mfeesp.exe", "mfefw.exe", "mfeProvisionModeUtility.exe", "mfetp.exe", "avpui.exe",
         "WscAVExe.exe", "mcshield.exe", "McChHost.exe", "mfewc.exe", "mfewch.exe", "mfewcui.exe", "fwinfo.exe",
         "mfecanary.exe", "mfefire.exe", "mfehidin.exe", "mfemms.exe", "mfevtps.exe", "mmsinfo.exe", "vtpinfo.exe",
         "MarSetup.exe", "mctray.exe", "masvc.exe", "macmnsvc.exe", "McAPExe.exe", "McPvTray.exe", "mcods.exe",
@@ -84,7 +84,7 @@ sequence by winlog.computer_name with maxspan=1m
         "SVRTcli.exe", "SVRTgui.exe", "SCTCleanupService.exe", "SVRTservice.exe", "native.exe", "SCTBootTasks.exe",
         "ALMon.exe", "SAA.exe", "SUMService.exe", "ssp.exe", "SCFService.exe", "SCFManager.exe", "spa.exe", "cabarc.exe",
         "sargui.exe", "sntpservice.exe", "McsClient.exe", "McsAgent.exe", "McsHeartbeat.exe", "SAVAdminService.exe",
-        "sav32cli.exe", "ForceUpdateAlongSideSGN.exe", "SAVCleanupService.exe", "SavMain.exe", "SavProgress.exe", 
+        "sav32cli.exe", "ForceUpdateAlongSideSGN.exe", "SAVCleanupService.exe", "SavMain.exe", "SavProgress.exe",
         "SavProxy.exe", "SavService.exe", "swc_service.exe", "swi_di.exe", "swi_service.exe", "swi_filter.exe",
         "ALUpdate.exe", "SophosUpdate.exe", "ALsvc.exe", "SophosAlert.exe", "osCheck.exe", "N360Downloader.exe",
         "InstWrap.exe", "symbos.exe", "nss.exe", "symcorpui.exe", "isPwdSvc.exe", "ccsvchst.exe", "ntrmv.exe",
@@ -100,7 +100,7 @@ sequence by winlog.computer_name with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Evasion via Windows Filtering Platform
 
diff --git a/rules/windows/defense_evasion_wsl_bash_exec.toml b/rules/windows/defense_evasion_wsl_bash_exec.toml
index 79a1da37f21..5833d334234 100644
--- a/rules/windows/defense_evasion_wsl_bash_exec.toml
+++ b/rules/windows/defense_evasion_wsl_bash_exec.toml
@@ -51,25 +51,25 @@ query = '''
 process where host.os.type == "windows" and event.type : "start" and
   (
     (
-      (process.executable : "?:\\Windows\\System32\\bash.exe" or ?process.pe.original_file_name == "Bash.exe") and 
+      (process.executable : "?:\\Windows\\System32\\bash.exe" or ?process.pe.original_file_name == "Bash.exe") and
       not process.command_line : ("bash", "bash.exe")
-    ) or 
-    process.executable : "?:\\Users\\*\\AppData\\Local\\Packages\\*\\rootfs\\usr\\bin\\bash" or 
+    ) or
+    process.executable : "?:\\Users\\*\\AppData\\Local\\Packages\\*\\rootfs\\usr\\bin\\bash" or
     (
       process.parent.name : "wsl.exe" and process.parent.command_line : "bash*" and not process.name : "wslhost.exe"
-    ) or 
+    ) or
     (
       process.name : "wsl.exe" and process.args : (
         "curl", "/etc/shadow", "/etc/passwd", "cat", "--system", "root", "-e", "--exec", "bash", "/mnt/c/*"
       ) and not process.args : ("wsl-bootstrap", "docker-desktop-data", "*.vscode-server*")
     )
-  ) and 
+  ) and
     not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Execution via Windows Subsystem for Linux
 
diff --git a/rules/windows/defense_evasion_wsl_child_process.toml b/rules/windows/defense_evasion_wsl_child_process.toml
index f072aac0692..2d512a83575 100644
--- a/rules/windows/defense_evasion_wsl_child_process.toml
+++ b/rules/windows/defense_evasion_wsl_child_process.toml
@@ -73,7 +73,7 @@ process where host.os.type == "windows" and event.type : "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution via Windows Subsystem for Linux
 
diff --git a/rules/windows/defense_evasion_wsl_filesystem.toml b/rules/windows/defense_evasion_wsl_filesystem.toml
index 29f11f5ca87..2194a0c7734 100644
--- a/rules/windows/defense_evasion_wsl_filesystem.toml
+++ b/rules/windows/defense_evasion_wsl_filesystem.toml
@@ -41,7 +41,7 @@ type = "eql"
 query = '''
 sequence by process.entity_id with maxspan=5m
  [process where host.os.type == "windows" and event.type == "start" and
-  process.name : "dllhost.exe" and 
+  process.name : "dllhost.exe" and
    /* Plan9FileSystem CLSID - WSL Host File System Worker */
   process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"]
  [file where host.os.type == "windows" and process.name : "dllhost.exe" and not file.path : "?:\\Users\\*\\Downloads\\*"]
@@ -49,7 +49,7 @@ sequence by process.entity_id with maxspan=5m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Host Files System Changes via Windows Subsystem for Linux
 
diff --git a/rules/windows/defense_evasion_wsl_kalilinux.toml b/rules/windows/defense_evasion_wsl_kalilinux.toml
index f9a8bc1091e..5f960395ca9 100644
--- a/rules/windows/defense_evasion_wsl_kalilinux.toml
+++ b/rules/windows/defense_evasion_wsl_kalilinux.toml
@@ -50,12 +50,12 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
 (
-  (process.name : "wsl.exe" and process.args : ("-d", "--distribution", "-i", "--install") and process.args : "kali*") or 
+  (process.name : "wsl.exe" and process.args : ("-d", "--distribution", "-i", "--install") and process.args : "kali*") or
   process.executable : (
-    "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*", 
+    "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
     "?:\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
     "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe",
-    "\\Device\\HarddiskVolume?\\Users\\*\\AppData\\Local\\packages\\kalilinux*", 
+    "\\Device\\HarddiskVolume?\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
     "\\Device\\HarddiskVolume?\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
     "\\Device\\HarddiskVolume?\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe"
   )
@@ -64,7 +64,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Install Kali Linux via WSL
 
diff --git a/rules/windows/discovery_active_directory_webservice.toml b/rules/windows/discovery_active_directory_webservice.toml
index 7b899f87244..efdf8e87f3f 100644
--- a/rules/windows/discovery_active_directory_webservice.toml
+++ b/rules/windows/discovery_active_directory_webservice.toml
@@ -31,15 +31,15 @@ type = "eql"
 
 query = '''
 sequence by process.entity_id with maxspan=3m
- [library where host.os.type == "windows" and 
-  dll.name : ("System.DirectoryServices*.dll", "System.IdentityModel*.dll") and 
-  not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and 
-  not process.executable : 
-                ("?:\\windows\\system32\\dsac.exe", 
-                 "?:\\program files\\powershell\\?\\pwsh.exe", 
-                 "?:\\windows\\system32\\windowspowershell\\*.exe", 
-                 "?:\\windows\\syswow64\\windowspowershell\\*.exe", 
-                 "?:\\program files\\microsoft monitoring agent\\*.exe", 
+ [library where host.os.type == "windows" and
+  dll.name : ("System.DirectoryServices*.dll", "System.IdentityModel*.dll") and
+  not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and
+  not process.executable :
+                ("?:\\windows\\system32\\dsac.exe",
+                 "?:\\program files\\powershell\\?\\pwsh.exe",
+                 "?:\\windows\\system32\\windowspowershell\\*.exe",
+                 "?:\\windows\\syswow64\\windowspowershell\\*.exe",
+                 "?:\\program files\\microsoft monitoring agent\\*.exe",
                  "?:\\windows\\adws\\microsoft.activedirectory.webservices.exe")]
  [network where host.os.type == "windows" and destination.port == 9389 and source.port >= 49152 and
   network.direction == "egress" and network.transport == "tcp" and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")]
@@ -47,7 +47,7 @@ sequence by process.entity_id with maxspan=3m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Enumeration via Active Directory Web Service
 
diff --git a/rules/windows/discovery_high_number_ad_properties.toml b/rules/windows/discovery_high_number_ad_properties.toml
index 980639372cd..2812442c999 100644
--- a/rules/windows/discovery_high_number_ad_properties.toml
+++ b/rules/windows/discovery_high_number_ad_properties.toml
@@ -52,7 +52,7 @@ any where event.action in ("Directory Service Access", "object-operation-perform
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Access to LDAP Attributes
 
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
index 19bd22e270b..473f7c010c7 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
@@ -38,7 +38,7 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Discovery Signal Alert with Unusual Process Command Line
 
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
index a9003d91c7e..008bdcf02a5 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
@@ -33,7 +33,7 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:"1d72d0
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Discovery Signal Alert with Unusual Process Executable
 
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
index d72891b5a05..d7dba5de5db 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
@@ -65,7 +65,7 @@ process.parent.name: (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Command Execution via SolarWinds Process
 
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
index 4d76d9499b7..be11fac30d7 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
@@ -61,7 +61,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious SolarWinds Child Process
 
diff --git a/rules/windows/execution_com_object_xwizard.toml b/rules/windows/execution_com_object_xwizard.toml
index bfaaa10fd00..38c6178e3b9 100644
--- a/rules/windows/execution_com_object_xwizard.toml
+++ b/rules/windows/execution_com_object_xwizard.toml
@@ -69,7 +69,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution of COM object via Xwizard
 
diff --git a/rules/windows/execution_command_shell_started_by_unusual_process.toml b/rules/windows/execution_command_shell_started_by_unusual_process.toml
index e36ce13cb64..1f315db6e92 100644
--- a/rules/windows/execution_command_shell_started_by_unusual_process.toml
+++ b/rules/windows/execution_command_shell_started_by_unusual_process.toml
@@ -61,7 +61,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Parent Process for cmd.exe
 
diff --git a/rules/windows/execution_command_shell_via_rundll32.toml b/rules/windows/execution_command_shell_via_rundll32.toml
index 46d47e879fb..7c4018f74b8 100644
--- a/rules/windows/execution_command_shell_via_rundll32.toml
+++ b/rules/windows/execution_command_shell_via_rundll32.toml
@@ -45,7 +45,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Command Shell Activity Started via RunDLL32
 
diff --git a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
index 7dcd6f690f9..19d8848ddd5 100644
--- a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
+++ b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
@@ -55,7 +55,7 @@ sequence by process.parent.entity_id with maxspan=1m
     not (process.pe.original_file_name : "DPInst.exe" and process.command_line : "driver\\DPInst_x64  /f ") and
     not (process.name : "powershell.exe" and process.args : "Write-Host ======*") and
     not (process.name : "wscript.exe" and process.args : "launchquiet_args.vbs" and process.parent.args : "?:\\Windows\\TempInst\\7z*") and
-    not (process.name : "regsvr32.exe" and process.args : ("?:\\windows\\syswow64\\msxml?.dll", "msxml?.dll", "?:\\Windows\\SysWOW64\\mschrt20.ocx")) and 
+    not (process.name : "regsvr32.exe" and process.args : ("?:\\windows\\syswow64\\msxml?.dll", "msxml?.dll", "?:\\Windows\\SysWOW64\\mschrt20.ocx")) and
     not (process.name : "wscript.exe" and
          process.working_directory :
                     ("?:\\Windows\\TempInst\\*",
@@ -66,7 +66,7 @@ sequence by process.parent.entity_id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Delayed Execution via Ping
 
diff --git a/rules/windows/execution_downloaded_shortcut_files.toml b/rules/windows/execution_downloaded_shortcut_files.toml
index ed5486f4fe6..14910c23a7c 100644
--- a/rules/windows/execution_downloaded_shortcut_files.toml
+++ b/rules/windows/execution_downloaded_shortcut_files.toml
@@ -34,7 +34,7 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Downloaded Shortcut Files
 
diff --git a/rules/windows/execution_downloaded_url_file.toml b/rules/windows/execution_downloaded_url_file.toml
index 77fedd4cb3c..44e9c9f7edc 100644
--- a/rules/windows/execution_downloaded_url_file.toml
+++ b/rules/windows/execution_downloaded_url_file.toml
@@ -35,7 +35,7 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Downloaded URL Files
 
diff --git a/rules/windows/execution_enumeration_via_wmiprvse.toml b/rules/windows/execution_enumeration_via_wmiprvse.toml
index df8dd1c0616..4c9361b5963 100644
--- a/rules/windows/execution_enumeration_via_wmiprvse.toml
+++ b/rules/windows/execution_enumeration_via_wmiprvse.toml
@@ -47,16 +47,16 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "windows" and event.type == "start" and process.command_line != null and 
+process where host.os.type == "windows" and event.type == "start" and process.command_line != null and
   process.name:
   (
     "arp.exe", "dsquery.exe", "dsget.exe", "gpresult.exe", "hostname.exe", "ipconfig.exe", "nbtstat.exe",
     "net.exe", "net1.exe", "netsh.exe", "netstat.exe", "nltest.exe", "ping.exe", "qprocess.exe", "quser.exe",
     "qwinsta.exe", "reg.exe", "sc.exe", "systeminfo.exe", "tasklist.exe", "tracert.exe", "whoami.exe"
   ) and
-  process.parent.name:"wmiprvse.exe" and 
+  process.parent.name:"wmiprvse.exe" and
   not (
-    process.name : "sc.exe" and process.args : "RemoteRegistry" and process.args : "start=" and 
+    process.name : "sc.exe" and process.args : "RemoteRegistry" and process.args : "start=" and
     process.args : ("demand", "disabled")
   ) and
   not process.args : "tenable_mw_scan"
@@ -64,7 +64,7 @@ process where host.os.type == "windows" and event.type == "start" and process.co
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Enumeration Command Spawned via WMIPrvSE
 
diff --git a/rules/windows/execution_initial_access_foxmail_exploit.toml b/rules/windows/execution_initial_access_foxmail_exploit.toml
index 2ebe421b5f4..65f5265816b 100644
--- a/rules/windows/execution_initial_access_foxmail_exploit.toml
+++ b/rules/windows/execution_initial_access_foxmail_exploit.toml
@@ -9,8 +9,8 @@ updated_date = "2025/01/10"
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the Foxmail client spawning a child process with argument pointing to the Foxmail temp directory. 
-This may indicate the successful exploitation of a Foxmail vulnerability for initial access and execution via 
+Identifies the Foxmail client spawning a child process with argument pointing to the Foxmail temp directory.
+This may indicate the successful exploitation of a Foxmail vulnerability for initial access and execution via
 a malicious email.
 """
 from = "now-9m"
@@ -21,8 +21,8 @@ index = [
     "logs-system.security*",
     "logs-windows.sysmon_operational-*",
     "logs-sentinel_one_cloud_funnel.*",
-    "logs-m365_defender.event-*", 
-    "logs-endpoint.events.process-*", 
+    "logs-m365_defender.event-*",
+    "logs-endpoint.events.process-*",
     "logs-crowdstrike.fdr*"
 ]
 language = "eql"
@@ -39,8 +39,8 @@ tags = [
     "Tactic: Initial Access",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
-    "Data Source: Sysmon", 
-    "Data Source: System", 
+    "Data Source: Sysmon",
+    "Data Source: System",
     "Data Source: Elastic Endgame",
     "Data Source: SentinelOne",
     "Data Source: Microsoft Defender for Endpoint",
@@ -50,13 +50,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "windows" and event.type == "start" and 
+process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "Foxmail.exe" and process.args : ("?:\\Users\\*\\AppData\\*", "\\\\*")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Foxmail Exploitation
 
diff --git a/rules/windows/execution_initial_access_wps_dll_exploit.toml b/rules/windows/execution_initial_access_wps_dll_exploit.toml
index a07b115da36..a97691e343a 100644
--- a/rules/windows/execution_initial_access_wps_dll_exploit.toml
+++ b/rules/windows/execution_initial_access_wps_dll_exploit.toml
@@ -9,7 +9,7 @@ min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the load of a remote library by the WPS Office promecefpluginhost.exe executable. This may indicate the successful 
+Identifies the load of a remote library by the WPS Office promecefpluginhost.exe executable. This may indicate the successful
 exploitation of CVE-2024-7262 or CVE-2024-7263 via DLL hijack abusing the ksoqing custom protocol handler.
 """
 from = "now-9m"
@@ -18,7 +18,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "WPS Office Exploitation via DLL Hijack"
 references = [
- "https://www.welivesecurity.com/en/eset-research/analysis-of-two-arbitrary-code-execution-vulnerabilities-affecting-wps-office/", 
+ "https://www.welivesecurity.com/en/eset-research/analysis-of-two-arbitrary-code-execution-vulnerabilities-affecting-wps-office/",
  "https://mp.weixin.qq.com/s/F8hNyESBdKhwXkQPgtGpew"
  ]
 risk_score = 73
@@ -37,23 +37,23 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where host.os.type == "windows" and process.name : "promecefpluginhost.exe" and 
+any where host.os.type == "windows" and process.name : "promecefpluginhost.exe" and
 (
- (event.category == "library" and 
-  ?dll.path : 
-     ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*", 
-      "\\Device\\Mup\\**", "\\\\*")) or 
-
-  ((event.category == "process" and event.action : "Image loaded*") and 
-  ?file.path : 
-     ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*", 
+ (event.category == "library" and
+  ?dll.path :
+     ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*",
+      "\\Device\\Mup\\**", "\\\\*")) or
+
+  ((event.category == "process" and event.action : "Image loaded*") and
+  ?file.path :
+     ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*",
       "\\Device\\Mup\\**", "\\\\*"))
 )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WPS Office Exploitation via DLL Hijack
 
diff --git a/rules/windows/execution_mofcomp.toml b/rules/windows/execution_mofcomp.toml
index 6f848848ccf..e0437780b30 100644
--- a/rules/windows/execution_mofcomp.toml
+++ b/rules/windows/execution_mofcomp.toml
@@ -50,7 +50,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Mofcomp Activity
 Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and namespaces in the Windows Management Instrumentation (WMI) repository. Adversaries exploit this by creating malicious WMI scripts for persistence or execution. The detection rule identifies suspicious mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts.
diff --git a/rules/windows/execution_posh_hacktool_authors.toml b/rules/windows/execution_posh_hacktool_authors.toml
index dffddb67d7b..bf725c875f0 100644
--- a/rules/windows/execution_posh_hacktool_authors.toml
+++ b/rules/windows/execution_posh_hacktool_authors.toml
@@ -83,7 +83,7 @@ host.os.type:windows and event.category:process and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential PowerShell HackTool Script by Author
 
diff --git a/rules/windows/execution_powershell_susp_args_via_winscript.toml b/rules/windows/execution_powershell_susp_args_via_winscript.toml
index acbeeb7993f..f30e70b329e 100644
--- a/rules/windows/execution_powershell_susp_args_via_winscript.toml
+++ b/rules/windows/execution_powershell_susp_args_via_winscript.toml
@@ -101,7 +101,7 @@ process where host.os.type == "windows" and event.action == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious PowerShell Execution via Windows Scripts
 
diff --git a/rules/windows/execution_scheduled_task_powershell_source.toml b/rules/windows/execution_scheduled_task_powershell_source.toml
index e9fa85b6bf9..ee67119a823 100644
--- a/rules/windows/execution_scheduled_task_powershell_source.toml
+++ b/rules/windows/execution_scheduled_task_powershell_source.toml
@@ -49,7 +49,7 @@ sequence by host.id, process.entity_id with maxspan = 5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Outbound Scheduled Task Activity via PowerShell
 
diff --git a/rules/windows/execution_suspicious_cmd_wmi.toml b/rules/windows/execution_suspicious_cmd_wmi.toml
index 6825f682e8f..d1a2af0d4d0 100644
--- a/rules/windows/execution_suspicious_cmd_wmi.toml
+++ b/rules/windows/execution_suspicious_cmd_wmi.toml
@@ -58,7 +58,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Cmd Execution via WMI
 
diff --git a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
index f76e6b136e1..eac4b42c6d1 100644
--- a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
+++ b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
@@ -53,7 +53,7 @@ any where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious WMI Image Load from MS Office
 
diff --git a/rules/windows/execution_via_mmc_console_file_unusual_path.toml b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
index 9bce81762f0..d862eb3e601 100644
--- a/rules/windows/execution_via_mmc_console_file_unusual_path.toml
+++ b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
@@ -53,7 +53,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft Management Console File from Unusual Path
 
diff --git a/rules/windows/execution_windows_cmd_shell_susp_args.toml b/rules/windows/execution_windows_cmd_shell_susp_args.toml
index f7b239b8f3b..9c6ff62c9d8 100644
--- a/rules/windows/execution_windows_cmd_shell_susp_args.toml
+++ b/rules/windows/execution_windows_cmd_shell_susp_args.toml
@@ -42,7 +42,7 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
- process.name : "cmd.exe" and 
+ process.name : "cmd.exe" and
  (
 
   process.command_line : ("*).Run(*", "*GetObject*", "* curl*regsvr32*", "*echo*wscript*", "*echo*ZONE.identifier*",
@@ -101,13 +101,13 @@ process where host.os.type == "windows" and event.type == "start" and
   not process.command_line :
                ("\"cmd\" /c %NETBEANS_MAVEN_COMMAND_LINE%",
                 "?:\\Windows\\system32\\cmd.exe /q /d /s /c \"npm.cmd ^\"install^\" ^\"--no-bin-links^\" ^\"--production^\"\"") and
-  not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and 
+  not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and
   not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Windows Command Shell Arguments
 
diff --git a/rules/windows/execution_windows_powershell_susp_args.toml b/rules/windows/execution_windows_powershell_susp_args.toml
index a45cfcd0ba0..20255b8da08 100644
--- a/rules/windows/execution_windows_powershell_susp_args.toml
+++ b/rules/windows/execution_windows_powershell_susp_args.toml
@@ -44,7 +44,7 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
- process.name : "powershell.exe" and 
+ process.name : "powershell.exe" and
   (
    process.command_line :
         (
@@ -102,14 +102,14 @@ process where host.os.type == "windows" and event.type == "start" and
 
       process.args : "$*$*;set-alias" or
 
-      (process.parent.name : ("explorer.exe", "cmd.exe") and 
+      (process.parent.name : ("explorer.exe", "cmd.exe") and
        process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*"))
   )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Windows Powershell Arguments
 
diff --git a/rules/windows/exfiltration_smb_rare_destination.toml b/rules/windows/exfiltration_smb_rare_destination.toml
index 67542883b04..0cb0164fae0 100644
--- a/rules/windows/exfiltration_smb_rare_destination.toml
+++ b/rules/windows/exfiltration_smb_rare_destination.toml
@@ -43,8 +43,8 @@ timestamp_override = "event.ingested"
 type = "new_terms"
 
 query = '''
-event.category:network and host.os.type:windows and process.pid:4 and 
-  network.transport:tcp and destination.port:(139 or 445) and 
+event.category:network and host.os.type:windows and process.pid:4 and
+  network.transport:tcp and destination.port:(139 or 445) and
   source.ip:(
     10.0.0.0/8 or
     172.16.0.0/12 or
@@ -82,7 +82,7 @@ event.category:network and host.os.type:windows and process.pid:4 and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Rare SMB Connection to the Internet
 
diff --git a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
index 931cf623700..ac75c10eeff 100644
--- a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
+++ b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
@@ -18,7 +18,7 @@ name = "Suspicious HTML File Creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious HTML File Creation
 
diff --git a/rules/windows/initial_access_execution_from_inetcache.toml b/rules/windows/initial_access_execution_from_inetcache.toml
index 9a49917fbe7..9d5103044ed 100644
--- a/rules/windows/initial_access_execution_from_inetcache.toml
+++ b/rules/windows/initial_access_execution_from_inetcache.toml
@@ -51,7 +51,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "windows" and event.type == "start" and  
+process where host.os.type == "windows" and event.type == "start" and
   process.parent.name : ("explorer.exe", "winrar.exe", "7zFM.exe", "Bandizip.exe") and
   (
     process.args : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*" or
@@ -64,7 +64,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Execution from INET Cache
 
diff --git a/rules/windows/initial_access_execution_from_removable_media.toml b/rules/windows/initial_access_execution_from_removable_media.toml
index e9438f064b5..5766e343336 100644
--- a/rules/windows/initial_access_execution_from_removable_media.toml
+++ b/rules/windows/initial_access_execution_from_removable_media.toml
@@ -31,18 +31,18 @@ type = "eql"
 query = '''
 sequence by process.entity_id with maxspan=5m
  [process where host.os.type == "windows" and event.action == "start" and
-  
+
   /* Direct Exec from USB */
   (process.Ext.device.bus_type : "usb" or process.Ext.device.product_id : "USB *") and
-  (process.code_signature.trusted == false or process.code_signature.exists == false) and 
-  
+  (process.code_signature.trusted == false or process.code_signature.exists == false) and
+
   not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")]
  [network where host.os.type == "windows" and event.action == "connection_attempted"]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution from a Removable Media with Network Connection
 
diff --git a/rules/windows/initial_access_execution_remote_via_msiexec.toml b/rules/windows/initial_access_execution_remote_via_msiexec.toml
index c98affc9b30..dc6ed9752e6 100644
--- a/rules/windows/initial_access_execution_remote_via_msiexec.toml
+++ b/rules/windows/initial_access_execution_remote_via_msiexec.toml
@@ -64,7 +64,7 @@ sequence with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Remote File Execution via MSIEXEC
 
diff --git a/rules/windows/initial_access_execution_via_office_addins.toml b/rules/windows/initial_access_execution_via_office_addins.toml
index dabf610c6f9..56613b344b9 100644
--- a/rules/windows/initial_access_execution_via_office_addins.toml
+++ b/rules/windows/initial_access_execution_via_office_addins.toml
@@ -40,14 +40,14 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where 
-    
-    host.os.type == "windows" and event.type == "start" and  
-    
-    process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "VSTOInstaller.exe") and 
-    
-    process.args regex~ """.+\.(wll|xll|ppa|ppam|xla|xlam|vsto)""" and 
-    
+process where
+
+    host.os.type == "windows" and event.type == "start" and
+
+    process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "VSTOInstaller.exe") and
+
+    process.args regex~ """.+\.(wll|xll|ppa|ppam|xla|xlam|vsto)""" and
+
     /* Office Add-In from suspicious paths */
     (process.args :
              ("?:\\Users\\*\\Temp\\7z*",
@@ -61,12 +61,12 @@ process where
               "?:\\Windows\\Temp\\*",
               "\\Device\\*",
               "http*") or
-	      
-    process.parent.name : ("explorer.exe", "OpenWith.exe") or 
-    
+
+    process.parent.name : ("explorer.exe", "OpenWith.exe") or
+
     /* Office Add-In from suspicious parent */
     process.parent.name : ("cmd.exe", "powershell.exe")) and
-	  
+
     /* False Positives */
     not (process.args : "*.vsto" and
          process.parent.executable :
@@ -84,7 +84,7 @@ process where
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Execution via Microsoft Office Add-Ins
 
diff --git a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
index 2597f2957a8..79e582948bc 100644
--- a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
+++ b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
@@ -52,7 +52,7 @@ event.category:"registry" and host.os.type:"windows" and registry.value:"Friendl
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Time Seen Removable Device
 
diff --git a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
index a718f46c188..4d13c128a10 100644
--- a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
+++ b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
@@ -75,7 +75,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious JetBrains TeamCity Child Process
 
diff --git a/rules/windows/initial_access_rdp_file_mail_attachment.toml b/rules/windows/initial_access_rdp_file_mail_attachment.toml
index 1e27db0f462..a871baa51cd 100644
--- a/rules/windows/initial_access_rdp_file_mail_attachment.toml
+++ b/rules/windows/initial_access_rdp_file_mail_attachment.toml
@@ -50,19 +50,19 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "windows" and event.type == "start" and  
+process where host.os.type == "windows" and event.type == "start" and
  process.name : "mstsc.exe" and
- process.args : ("?:\\Users\\*\\Downloads\\*.rdp", 
-                 "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*.rdp", 
-                 "?:\\Users\\*\\AppData\\Local\\Temp\\7z*.rdp", 
-                 "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*\\*.rdp", 
+ process.args : ("?:\\Users\\*\\Downloads\\*.rdp",
+                 "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*.rdp",
+                 "?:\\Users\\*\\AppData\\Local\\Temp\\7z*.rdp",
+                 "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*\\*.rdp",
                  "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*.rdp",
                  "C:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\Content.Outlook\\*.rdp")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Remote Desktop File Opened from Suspicious Path
 
diff --git a/rules/windows/initial_access_scripts_process_started_via_wmi.toml b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
index f195d33108e..044ba963d33 100644
--- a/rules/windows/initial_access_scripts_process_started_via_wmi.toml
+++ b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
@@ -40,7 +40,7 @@ type = "eql"
 
 query = '''
 sequence by host.id with maxspan = 5s
-    [any where host.os.type == "windows" and 
+    [any where host.os.type == "windows" and
      (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and
      (?dll.name : "wmiutils.dll" or file.name : "wmiutils.dll") and process.name : ("wscript.exe", "cscript.exe")]
     [process where host.os.type == "windows" and event.type == "start" and
@@ -72,7 +72,7 @@ sequence by host.id with maxspan = 5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows Script Interpreter Executing Process via WMI
 
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
index 1a9f7b3e2a8..241e38d5f37 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
@@ -85,7 +85,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft Exchange Server UM Spawning Suspicious Processes
 
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
index 7f6d60614bf..86ecd1a4eff 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
@@ -49,7 +49,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft Exchange Worker Spawning Suspicious Processes
 
diff --git a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
index 2a5918ab9dc..fffa2b5ff7d 100644
--- a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
+++ b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
@@ -54,7 +54,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Explorer Child Process
 
diff --git a/rules/windows/initial_access_webshell_screenconnect_server.toml b/rules/windows/initial_access_webshell_screenconnect_server.toml
index 05073737ac9..52b864f3473 100644
--- a/rules/windows/initial_access_webshell_screenconnect_server.toml
+++ b/rules/windows/initial_access_webshell_screenconnect_server.toml
@@ -57,7 +57,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 ScreenConnect Server Spawning Suspicious Processes
 
diff --git a/rules/windows/initial_access_xsl_script_execution_via_com.toml b/rules/windows/initial_access_xsl_script_execution_via_com.toml
index f145ce6612a..13b584e0072 100644
--- a/rules/windows/initial_access_xsl_script_execution_via_com.toml
+++ b/rules/windows/initial_access_xsl_script_execution_via_com.toml
@@ -33,7 +33,7 @@ sequence with maxspan=1m
  [library where host.os.type == "windows" and dll.name : "msxml3.dll" and
   process.name : ("winword.exe", "excel.exe", "powerpnt.exe", "mspub.exe")] by process.entity_id
  [process where host.os.type == "windows" and event.action == "start" and
-  process.parent.name : ("winword.exe", "excel.exe", "powerpnt.exe", "mspub.exe") and 
+  process.parent.name : ("winword.exe", "excel.exe", "powerpnt.exe", "mspub.exe") and
   not process.executable :
         ("?:\\Windows\\System32\\WerFault.exe",
          "?:\\Windows\\SysWoW64\\WerFault.exe",
@@ -45,7 +45,7 @@ sequence with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Remote XSL Script Execution via COM
 
diff --git a/rules/windows/lateral_movement_alternate_creds_pth.toml b/rules/windows/lateral_movement_alternate_creds_pth.toml
index d3b22ba5c4f..409253b4994 100644
--- a/rules/windows/lateral_movement_alternate_creds_pth.toml
+++ b/rules/windows/lateral_movement_alternate_creds_pth.toml
@@ -27,15 +27,15 @@ timestamp_override = "event.ingested"
 type = "new_terms"
 
 query = '''
-host.os.type:"windows" and 
-event.category : "authentication" and event.action : "logged-in" and 
-winlog.logon.type : "NewCredentials" and event.outcome : "success" and 
+host.os.type:"windows" and
+event.category : "authentication" and event.action : "logged-in" and
+winlog.logon.type : "NewCredentials" and event.outcome : "success" and
 user.id : (S-1-5-21-* or S-1-12-1-*) and winlog.event_data.LogonProcessName : "seclogo"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Pass-the-Hash (PtH) Attempt
 
diff --git a/rules/windows/lateral_movement_cmd_service.toml b/rules/windows/lateral_movement_cmd_service.toml
index 8cb0dca8327..f910804003d 100644
--- a/rules/windows/lateral_movement_cmd_service.toml
+++ b/rules/windows/lateral_movement_cmd_service.toml
@@ -46,7 +46,7 @@ sequence by process.entity_id with maxspan = 1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Service Command Lateral Movement
 
diff --git a/rules/windows/lateral_movement_dcom_hta.toml b/rules/windows/lateral_movement_dcom_hta.toml
index 4b76978dc12..951d44f30f5 100644
--- a/rules/windows/lateral_movement_dcom_hta.toml
+++ b/rules/windows/lateral_movement_dcom_hta.toml
@@ -50,7 +50,7 @@ sequence with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Incoming DCOM Lateral Movement via MSHTA
 
diff --git a/rules/windows/lateral_movement_dcom_mmc20.toml b/rules/windows/lateral_movement_dcom_mmc20.toml
index 1bd081e4ee4..09242c803f7 100644
--- a/rules/windows/lateral_movement_dcom_mmc20.toml
+++ b/rules/windows/lateral_movement_dcom_mmc20.toml
@@ -50,7 +50,7 @@ sequence by host.id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Incoming DCOM Lateral Movement with MMC
 
diff --git a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
index 5648650c87e..e687fb54546 100644
--- a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
+++ b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
@@ -50,7 +50,7 @@ sequence by host.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows
 
diff --git a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
index 3f1af9489dd..10103cf2219 100644
--- a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
+++ b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
@@ -51,7 +51,7 @@ not registry.data.strings : "(empty)"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 NullSessionPipe Registry Modification
 
diff --git a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
index 591fc4776de..94c51ea7347 100644
--- a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
+++ b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
@@ -69,7 +69,7 @@ any where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Remote Desktop Shadowing Activity
 
diff --git a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
index b67ca1b496d..be355399c39 100644
--- a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
+++ b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
@@ -56,7 +56,7 @@ process where host.os.type == "windows" and event.type == "start" and process.ex
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution via TSClient Mountpoint
 
diff --git a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
index f9dae8c38ba..63dd096c831 100644
--- a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
+++ b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
@@ -45,13 +45,13 @@ query = '''
 sequence by host.id with maxspan=30s
    [network where host.os.type == "windows" and process.pid == 4 and network.direction : ("incoming", "ingress") and
     destination.port in (5985, 5986) and network.protocol == "http" and source.ip != "127.0.0.1" and source.ip != "::1"]
-   [process where host.os.type == "windows" and 
+   [process where host.os.type == "windows" and
     event.type == "start" and process.parent.name : "winrshost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Incoming Execution via WinRM Remote Shell
 
diff --git a/rules/windows/lateral_movement_incoming_wmi.toml b/rules/windows/lateral_movement_incoming_wmi.toml
index cc46ebefe0b..2c4023b98ed 100644
--- a/rules/windows/lateral_movement_incoming_wmi.toml
+++ b/rules/windows/lateral_movement_incoming_wmi.toml
@@ -62,7 +62,7 @@ sequence by host.id with maxspan = 2s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WMI Incoming Lateral Movement
 
diff --git a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
index 580e0199488..c7520b671ba 100644
--- a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
+++ b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
@@ -60,7 +60,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Mounting Hidden or WebDav Remote Shares
 
diff --git a/rules/windows/lateral_movement_powershell_remoting_target.toml b/rules/windows/lateral_movement_powershell_remoting_target.toml
index d144f3dd34e..66687eb8971 100644
--- a/rules/windows/lateral_movement_powershell_remoting_target.toml
+++ b/rules/windows/lateral_movement_powershell_remoting_target.toml
@@ -49,13 +49,13 @@ query = '''
 sequence by host.id with maxspan = 30s
    [network where host.os.type == "windows" and network.direction : ("incoming", "ingress") and destination.port in (5985, 5986) and
     network.protocol == "http" and source.ip != "127.0.0.1" and source.ip != "::1"]
-   [process where host.os.type == "windows" and 
+   [process where host.os.type == "windows" and
     event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Incoming Execution via PowerShell Remoting
 
diff --git a/rules/windows/lateral_movement_rdp_sharprdp_target.toml b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
index 5dad77a8d64..87cd14e4b09 100644
--- a/rules/windows/lateral_movement_rdp_sharprdp_target.toml
+++ b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
@@ -54,7 +54,7 @@ sequence by host.id with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential SharpRDP Behavior
 
diff --git a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
index 4dd1ff96e5c..cfecd7784a1 100644
--- a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
+++ b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
@@ -58,7 +58,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Remote File Copy to a Hidden Share
 
diff --git a/rules/windows/lateral_movement_remote_service_installed_winlog.toml b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
index 68195e9ac98..979e47a2a5e 100644
--- a/rules/windows/lateral_movement_remote_service_installed_winlog.toml
+++ b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
@@ -66,7 +66,7 @@ event.outcome=="success" and source.ip != null and source.ip != "127.0.0.1" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Remote Windows Service Installed
 
diff --git a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
index f14e56eea50..96b7dc745de 100644
--- a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
+++ b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
@@ -71,7 +71,7 @@ any where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious RDP ActiveX Client Loaded
 
diff --git a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
index ebd46787a54..9ab20fa2ec1 100644
--- a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
+++ b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
@@ -50,7 +50,7 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Lateral Movement via Startup Folder
 
diff --git a/rules/windows/lateral_movement_via_wsus_update.toml b/rules/windows/lateral_movement_via_wsus_update.toml
index 6211207ab35..84f80c175e8 100644
--- a/rules/windows/lateral_movement_via_wsus_update.toml
+++ b/rules/windows/lateral_movement_via_wsus_update.toml
@@ -49,7 +49,7 @@ process.executable : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential WSUS Abuse for Lateral Movement
 
diff --git a/rules/windows/persistence_ad_adminsdholder.toml b/rules/windows/persistence_ad_adminsdholder.toml
index 7b0d9b0837b..b3e5290c506 100644
--- a/rules/windows/persistence_ad_adminsdholder.toml
+++ b/rules/windows/persistence_ad_adminsdholder.toml
@@ -46,7 +46,7 @@ event.action:("Directory Service Changes" or "directory-service-object-modified"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AdminSDHolder Backdoor
 
diff --git a/rules/windows/persistence_app_compat_shim.toml b/rules/windows/persistence_app_compat_shim.toml
index 2a89370136a..76305ef6512 100644
--- a/rules/windows/persistence_app_compat_shim.toml
+++ b/rules/windows/persistence_app_compat_shim.toml
@@ -41,17 +41,17 @@ registry where host.os.type == "windows" and event.type == "change" and
         "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Custom\\*.sdb",
         "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Custom\\*.sdb"
     ) and
-    not process.executable : 
-                       ("?:\\Program Files (x86)\\DesktopCentral_Agent\\swrepository\\1\\swuploads\\SAP-SLC\\SAPSetupSLC02_14-80001954\\Setup\\NwSapSetup.exe", 
-                        "?:\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe", 
-                         "?:\\Program Files (x86)\\SAP\\SAPsetup\\setup\\NwSapSetup.exe", 
-                         "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", 
+    not process.executable :
+                       ("?:\\Program Files (x86)\\DesktopCentral_Agent\\swrepository\\1\\swuploads\\SAP-SLC\\SAPSetupSLC02_14-80001954\\Setup\\NwSapSetup.exe",
+                        "?:\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe",
+                         "?:\\Program Files (x86)\\SAP\\SAPsetup\\setup\\NwSapSetup.exe",
+                         "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe",
                          "?:\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Installation of Custom Shim Databases
 
diff --git a/rules/windows/persistence_appcertdlls_registry.toml b/rules/windows/persistence_appcertdlls_registry.toml
index c2edf2ea416..1865843e22e 100644
--- a/rules/windows/persistence_appcertdlls_registry.toml
+++ b/rules/windows/persistence_appcertdlls_registry.toml
@@ -43,7 +43,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Registry Persistence via AppCert DLL
 
diff --git a/rules/windows/persistence_browser_extension_install.toml b/rules/windows/persistence_browser_extension_install.toml
index 83ca4bb9d9e..4174fcad514 100644
--- a/rules/windows/persistence_browser_extension_install.toml
+++ b/rules/windows/persistence_browser_extension_install.toml
@@ -42,13 +42,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-file where host.os.type == "windows" and event.type : "creation" and 
+file where host.os.type == "windows" and event.type : "creation" and
 (
   /* Firefox-Based Browsers */
   (
     file.name : "*.xpi" and
     file.path : "?:\\Users\\*\\AppData\\Roaming\\*\\Profiles\\*\\Extensions\\*.xpi" and
-    not 
+    not
     (
       process.name : "firefox.exe" and
       file.name : ("langpack-*@firefox.mozilla.org.xpi", "*@dictionaries.addons.mozilla.org.xpi")
@@ -64,7 +64,7 @@ file where host.os.type == "windows" and event.type : "creation" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Browser Extension Install
 Browser extensions enhance functionality in web browsers but can be exploited by adversaries to gain persistence or execute malicious activities. Attackers may disguise harmful extensions as legitimate or use compromised systems to install them. The detection rule identifies suspicious extension installations by monitoring file creation events in typical extension directories, filtering out known safe processes, and focusing on Windows environments.
diff --git a/rules/windows/persistence_evasion_registry_ifeo_injection.toml b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
index 0f6684125d5..95c2605548a 100644
--- a/rules/windows/persistence_evasion_registry_ifeo_injection.toml
+++ b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
@@ -61,7 +61,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Image File Execution Options Injection
 
diff --git a/rules/windows/persistence_group_modification_by_system.toml b/rules/windows/persistence_group_modification_by_system.toml
index c07d73ac3ef..b8e58cf5b5d 100644
--- a/rules/windows/persistence_group_modification_by_system.toml
+++ b/rules/windows/persistence_group_modification_by_system.toml
@@ -43,7 +43,7 @@ not group.id : "S-1-5-21-*-513"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Active Directory Group Modification by SYSTEM
 
diff --git a/rules/windows/persistence_local_scheduled_job_creation.toml b/rules/windows/persistence_local_scheduled_job_creation.toml
index bb95a64c5dc..50807113eae 100644
--- a/rules/windows/persistence_local_scheduled_job_creation.toml
+++ b/rules/windows/persistence_local_scheduled_job_creation.toml
@@ -45,7 +45,7 @@ file where host.os.type == "windows" and event.type != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via Scheduled Job Creation
 
diff --git a/rules/windows/persistence_local_scheduled_task_creation.toml b/rules/windows/persistence_local_scheduled_task_creation.toml
index d467331d35e..0f0af265a6e 100644
--- a/rules/windows/persistence_local_scheduled_task_creation.toml
+++ b/rules/windows/persistence_local_scheduled_task_creation.toml
@@ -56,7 +56,7 @@ sequence with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Local Scheduled Task Creation
 
diff --git a/rules/windows/persistence_ms_office_addins_file.toml b/rules/windows/persistence_ms_office_addins_file.toml
index 5dbd00e8eef..9d717776903 100644
--- a/rules/windows/persistence_ms_office_addins_file.toml
+++ b/rules/windows/persistence_ms_office_addins_file.toml
@@ -45,7 +45,7 @@ file where host.os.type == "windows" and event.type != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via Microsoft Office AddIns
 
diff --git a/rules/windows/persistence_ms_outlook_vba_template.toml b/rules/windows/persistence_ms_outlook_vba_template.toml
index ff72c20da93..6fdda2ca076 100644
--- a/rules/windows/persistence_ms_outlook_vba_template.toml
+++ b/rules/windows/persistence_ms_outlook_vba_template.toml
@@ -43,7 +43,7 @@ file where host.os.type == "windows" and event.type != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via Microsoft Outlook VBA
 
diff --git a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
index 017be43d3b3..b1882952650 100644
--- a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
+++ b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
@@ -59,7 +59,7 @@ iam where event.action == "modified-user-account" and event.code == "4738" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 KRBTGT Delegation Backdoor
 
diff --git a/rules/windows/persistence_msi_installer_task_startup.toml b/rules/windows/persistence_msi_installer_task_startup.toml
index aad57db99ec..41d2ec87868 100644
--- a/rules/windows/persistence_msi_installer_task_startup.toml
+++ b/rules/windows/persistence_msi_installer_task_startup.toml
@@ -33,7 +33,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where host.os.type == "windows" and 
+any where host.os.type == "windows" and
  (process.name : "msiexec.exe" or Effective_process.name : "msiexec.exe") and
  (
   (event.category == "file" and event.action == "creation" and
@@ -51,7 +51,7 @@ any where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via a Windows Installer
 
diff --git a/rules/windows/persistence_msoffice_startup_registry.toml b/rules/windows/persistence_msoffice_startup_registry.toml
index ad031b63897..0ce759403e7 100644
--- a/rules/windows/persistence_msoffice_startup_registry.toml
+++ b/rules/windows/persistence_msoffice_startup_registry.toml
@@ -45,7 +45,7 @@ registry where host.os.type == "windows" and event.action != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Office Test Registry Persistence
 
diff --git a/rules/windows/persistence_netsh_helper_dll.toml b/rules/windows/persistence_netsh_helper_dll.toml
index 96831535eb0..66d617019b5 100644
--- a/rules/windows/persistence_netsh_helper_dll.toml
+++ b/rules/windows/persistence_netsh_helper_dll.toml
@@ -46,7 +46,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Netsh Helper DLL
 
diff --git a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
index f1773f5fd72..994ee60354a 100644
--- a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
+++ b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
@@ -59,7 +59,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 New ActiveSyncAllowedDeviceID Added via PowerShell
 
diff --git a/rules/windows/persistence_registry_uncommon.toml b/rules/windows/persistence_registry_uncommon.toml
index e92d89a51d0..a76f2078d51 100644
--- a/rules/windows/persistence_registry_uncommon.toml
+++ b/rules/windows/persistence_registry_uncommon.toml
@@ -18,7 +18,7 @@ language = "eql"
 license = "Elastic License v2"
 name = "Uncommon Registry Persistence Change"
 references = [
-"https://www.microsoftpressstore.com/articles/article.aspx?p=2762082&seqNum=2", 
+"https://www.microsoftpressstore.com/articles/article.aspx?p=2762082&seqNum=2",
 "https://github.com/rad9800/BootExecuteEDR"
 ]
 risk_score = 47
@@ -118,7 +118,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Uncommon Registry Persistence Change
 
diff --git a/rules/windows/persistence_remote_password_reset.toml b/rules/windows/persistence_remote_password_reset.toml
index 5ff1c295a2e..e0d4bc2a0ad 100644
--- a/rules/windows/persistence_remote_password_reset.toml
+++ b/rules/windows/persistence_remote_password_reset.toml
@@ -21,7 +21,7 @@ name = "Account Password Reset Remotely"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Account Password Reset Remotely
 
diff --git a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
index 8293ddb3d9d..27b0bd36a04 100644
--- a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
+++ b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
@@ -54,7 +54,7 @@ sequence by host.id, user.name with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution of Persistent Suspicious Program
 
diff --git a/rules/windows/persistence_scheduled_task_creation_winlog.toml b/rules/windows/persistence_scheduled_task_creation_winlog.toml
index 77b3f381b52..d9189b041f7 100644
--- a/rules/windows/persistence_scheduled_task_creation_winlog.toml
+++ b/rules/windows/persistence_scheduled_task_creation_winlog.toml
@@ -47,7 +47,7 @@ iam where event.action == "scheduled-task-created" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 A scheduled task was created
 
diff --git a/rules/windows/persistence_scheduled_task_updated.toml b/rules/windows/persistence_scheduled_task_updated.toml
index 0a6deb606a9..e30a9a997f0 100644
--- a/rules/windows/persistence_scheduled_task_updated.toml
+++ b/rules/windows/persistence_scheduled_task_updated.toml
@@ -31,27 +31,27 @@ query = '''
 iam where event.action == "scheduled-task-updated" and
 
  /* excluding tasks created by the computer account */
- not user.name : "*$" and 
- not winlog.event_data.TaskName : "*Microsoft*" and 
+ not user.name : "*$" and
+ not winlog.event_data.TaskName : "*Microsoft*" and
  not winlog.event_data.TaskName :
           ("\\User_Feed_Synchronization-*",
            "\\OneDrive Reporting Task-S-1-5-21*",
            "\\OneDrive Reporting Task-S-1-12-1-*",
            "\\Hewlett-Packard\\HP Web Products Detection",
-           "\\Hewlett-Packard\\HPDeviceCheck", 
-           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistant", 
-           "\\IpamDnsProvisioning",  
-           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistantAllUsersRun", 
-           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistantCalendarRun", 
-           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistantWakeupRun", 
-           "\\Microsoft\\Windows\\.NET Framework\\.NET Framework NGEN v*", 
-           "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload") and 
+           "\\Hewlett-Packard\\HPDeviceCheck",
+           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistant",
+           "\\IpamDnsProvisioning",
+           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistantAllUsersRun",
+           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistantCalendarRun",
+           "\\Microsoft\\Windows\\UpdateOrchestrator\\UpdateAssistantWakeupRun",
+           "\\Microsoft\\Windows\\.NET Framework\\.NET Framework NGEN v*",
+           "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload") and
   not winlog.event_data.SubjectUserSid :  ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 A scheduled task was updated
 
diff --git a/rules/windows/persistence_service_dll_unsigned.toml b/rules/windows/persistence_service_dll_unsigned.toml
index 7b336a0b0f0..4b6d121d56d 100644
--- a/rules/windows/persistence_service_dll_unsigned.toml
+++ b/rules/windows/persistence_service_dll_unsigned.toml
@@ -36,19 +36,19 @@ type = "eql"
 query = '''
 library where host.os.type == "windows" and
 
- process.executable : 
-     ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\Syswow64\\svchost.exe") and 
-     
- dll.code_signature.trusted != true and 
- 
- not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*") and 
- 
- dll.hash.sha256 != null and 
- 
+ process.executable :
+     ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\Syswow64\\svchost.exe") and
+
+ dll.code_signature.trusted != true and
+
+ not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*") and
+
+ dll.hash.sha256 != null and
+
  (
        /* DLL created within 5 minutes of the library load event - compatible with Elastic Endpoint 8.4+ */
-       dll.Ext.relative_file_creation_time <= 300 or 
-   
+       dll.Ext.relative_file_creation_time <= 300 or
+
        /* unusual paths */
        dll.path :("?:\\ProgramData\\*",
                   "?:\\Users\\*",
@@ -117,19 +117,19 @@ library where host.os.type == "windows" and
                   "?:\\Windows\\ModemLogs\\*",
                   "?:\\Windows\\ImmersiveControlPanel\\*",
                   "?:\\$Recycle.Bin\\*")
-  ) and 
-  
-  not dll.hash.sha256 : 
-            ("3ed33e71641645367442e65dca6dab0d326b22b48ef9a4c2a2488e67383aa9a6", 
-             "b4db053f6032964df1b254ac44cb995ffaeb4f3ade09597670aba4f172cf65e4", 
-             "214c75f678bc596bbe667a3b520aaaf09a0e50c364a28ac738a02f867a085eba", 
-             "23aa95b637a1bf6188b386c21c4e87967ede80242327c55447a5bb70d9439244", 
+  ) and
+
+  not dll.hash.sha256 :
+            ("3ed33e71641645367442e65dca6dab0d326b22b48ef9a4c2a2488e67383aa9a6",
+             "b4db053f6032964df1b254ac44cb995ffaeb4f3ade09597670aba4f172cf65e4",
+             "214c75f678bc596bbe667a3b520aaaf09a0e50c364a28ac738a02f867a085eba",
+             "23aa95b637a1bf6188b386c21c4e87967ede80242327c55447a5bb70d9439244",
              "5050b025909e81ae5481db37beb807a80c52fc6dd30c8aa47c9f7841e2a31be7")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unsigned DLL Loaded by Svchost
 
diff --git a/rules/windows/persistence_services_registry.toml b/rules/windows/persistence_services_registry.toml
index a9bb55f50e2..fa49dd597cc 100644
--- a/rules/windows/persistence_services_registry.toml
+++ b/rules/windows/persistence_services_registry.toml
@@ -68,7 +68,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Persistence via Services Registry
 
diff --git a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
index ff3c3de7369..927d6a770e8 100644
--- a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
+++ b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
@@ -83,7 +83,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Execution via Scheduled Task
 
diff --git a/rules/windows/persistence_suspicious_service_created_registry.toml b/rules/windows/persistence_suspicious_service_created_registry.toml
index 7d579168ba3..1d9222bdcc2 100644
--- a/rules/windows/persistence_suspicious_service_created_registry.toml
+++ b/rules/windows/persistence_suspicious_service_created_registry.toml
@@ -48,7 +48,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious ImagePath Service Creation
 
diff --git a/rules/windows/persistence_sysmon_wmi_event_subscription.toml b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
index 6610a755f23..43cb06a7463 100644
--- a/rules/windows/persistence_sysmon_wmi_event_subscription.toml
+++ b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
@@ -36,19 +36,19 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-any where 
+any where
  (
    (event.dataset == "windows.sysmon_operational" and event.code == "21" and
-    winlog.event_data.Operation : "Created" and winlog.event_data.Consumer : ("*subscription:CommandLineEventConsumer*", "*subscription:ActiveScriptEventConsumer*")) or 
+    winlog.event_data.Operation : "Created" and winlog.event_data.Consumer : ("*subscription:CommandLineEventConsumer*", "*subscription:ActiveScriptEventConsumer*")) or
 
-   (event.dataset == "endpoint.events.api" and event.provider == "Microsoft-Windows-WMI-Activity" and process.Ext.api.name == "IWbemServices::PutInstance" and 
+   (event.dataset == "endpoint.events.api" and event.provider == "Microsoft-Windows-WMI-Activity" and process.Ext.api.name == "IWbemServices::PutInstance" and
     process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer"))
  )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious WMI Event Subscription Created
 
diff --git a/rules/windows/persistence_temp_scheduled_task.toml b/rules/windows/persistence_temp_scheduled_task.toml
index 42eecac8317..c2017b528e0 100644
--- a/rules/windows/persistence_temp_scheduled_task.toml
+++ b/rules/windows/persistence_temp_scheduled_task.toml
@@ -40,7 +40,7 @@ sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Temporarily Scheduled Task Creation
 
diff --git a/rules/windows/persistence_user_account_creation_event_logs.toml b/rules/windows/persistence_user_account_creation_event_logs.toml
index e9e4ea36162..e41500205c5 100644
--- a/rules/windows/persistence_user_account_creation_event_logs.toml
+++ b/rules/windows/persistence_user_account_creation_event_logs.toml
@@ -37,7 +37,7 @@ event.module:("system" or "security") and winlog.api:"wineventlog" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows User Account Creation
 
diff --git a/rules/windows/persistence_via_application_shimming.toml b/rules/windows/persistence_via_application_shimming.toml
index f8ee49d894a..f964057cf03 100644
--- a/rules/windows/persistence_via_application_shimming.toml
+++ b/rules/windows/persistence_via_application_shimming.toml
@@ -56,7 +56,7 @@ process where host.os.type == "windows" and event.type == "start" and process.na
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Application Shimming via Sdbinst
 
diff --git a/rules/windows/persistence_via_bits_job_notify_command.toml b/rules/windows/persistence_via_bits_job_notify_command.toml
index be0f8640ba2..3855f3916fd 100644
--- a/rules/windows/persistence_via_bits_job_notify_command.toml
+++ b/rules/windows/persistence_via_bits_job_notify_command.toml
@@ -43,7 +43,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via BITS Job Notify Cmdline
 
diff --git a/rules/windows/persistence_via_hidden_run_key_valuename.toml b/rules/windows/persistence_via_hidden_run_key_valuename.toml
index 03993645c3b..faa2520ad7a 100644
--- a/rules/windows/persistence_via_hidden_run_key_valuename.toml
+++ b/rules/windows/persistence_via_hidden_run_key_valuename.toml
@@ -65,7 +65,7 @@ registry where host.os.type == "windows" and event.type == "change" and length(r
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via Hidden Run Key Detected
 
diff --git a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
index 6a14303762f..70d0e39ea6b 100644
--- a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
+++ b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
@@ -50,7 +50,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Installation of Security Support Provider
 
diff --git a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
index 20ed84dce90..eca03a9c2e4 100644
--- a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
+++ b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
@@ -61,7 +61,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via TelemetryController Scheduled Task Hijack
 
diff --git a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
index 9dec899f8fe..5ad0590055c 100644
--- a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
+++ b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
@@ -58,7 +58,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Persistence via WMI Event Subscription
 
diff --git a/rules/windows/persistence_werfault_reflectdebugger.toml b/rules/windows/persistence_werfault_reflectdebugger.toml
index ee355aab4c6..9f5c4815a8a 100644
--- a/rules/windows/persistence_werfault_reflectdebugger.toml
+++ b/rules/windows/persistence_werfault_reflectdebugger.toml
@@ -46,7 +46,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Werfault ReflectDebugger Persistence
 
diff --git a/rules/windows/privilege_escalation_create_process_as_different_user.toml b/rules/windows/privilege_escalation_create_process_as_different_user.toml
index 9874bd76eec..d927209abcb 100644
--- a/rules/windows/privilege_escalation_create_process_as_different_user.toml
+++ b/rules/windows/privilege_escalation_create_process_as_different_user.toml
@@ -49,7 +49,7 @@ sequence by winlog.computer_name with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Creation via Secondary Logon
 
diff --git a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
index a1dabec0a54..01b346b5c6e 100644
--- a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
+++ b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
@@ -51,17 +51,17 @@ process where host.os.type == "windows" and event.action == "start" and
       process.command_line : ("*davclnt.dll,DavSetCookie*", "*?:\\Program Files*",
                               "*\\Windows\\System32\\winethc.dll*", "*\\Windows\\SYSTEM32\\EDGEHTML.dll*",
                               "*shell32.dll,SHCreateLocalServerRunDll*")) and
- not startswith~(process.Ext.effective_parent.name, process.parent.name) and 
- not (process.name : "powershell.exe" and process.parent.name : "wmiprvse.exe" and process.Ext.effective_parent.executable : "?:\\Windows\\System32\\wsmprovhost.exe") and 
- not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\RuntimeBroker.exe" and process.parent.executable : "?:\\Windows\\System32\\sihost.exe") and 
- not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\sethc.exe" and process.parent.executable : "?:\\Windows\\System32\\svchost.exe") and 
- not (process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe" and 
+ not startswith~(process.Ext.effective_parent.name, process.parent.name) and
+ not (process.name : "powershell.exe" and process.parent.name : "wmiprvse.exe" and process.Ext.effective_parent.executable : "?:\\Windows\\System32\\wsmprovhost.exe") and
+ not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\RuntimeBroker.exe" and process.parent.executable : "?:\\Windows\\System32\\sihost.exe") and
+ not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\sethc.exe" and process.parent.executable : "?:\\Windows\\System32\\svchost.exe") and
+ not (process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe" and
       process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\msiexec.exe", "?:\\Windows\\twain_32\\*.exe"))
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Created with a Duplicated Token
 
diff --git a/rules/windows/privilege_escalation_credroaming_ldap.toml b/rules/windows/privilege_escalation_credroaming_ldap.toml
index 4499d2c19e9..17ef783d74e 100644
--- a/rules/windows/privilege_escalation_credroaming_ldap.toml
+++ b/rules/windows/privilege_escalation_credroaming_ldap.toml
@@ -63,7 +63,7 @@ event.action:("Directory Service Changes" or "directory-service-object-modified"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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
 
diff --git a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
index 25df3ece26b..2f10fa49cf7 100644
--- a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
+++ b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
@@ -39,14 +39,14 @@ type = "eql"
 query = '''
 any where host.os.type == "windows" and event.category : ("library", "process") and
   event.type : ("start", "change") and event.action : ("load", "Image loaded*") and
-  process.executable : "?:\\windows\\system32\\dns.exe" and 
+  process.executable : "?:\\windows\\system32\\dns.exe" and
   not ?dll.code_signature.trusted == true and
   not file.code_signature.status == "Valid"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unsigned DLL loaded by DNS Service
 
diff --git a/rules/windows/privilege_escalation_expired_driver_loaded.toml b/rules/windows/privilege_escalation_expired_driver_loaded.toml
index fcd932fc921..16c62b43955 100644
--- a/rules/windows/privilege_escalation_expired_driver_loaded.toml
+++ b/rules/windows/privilege_escalation_expired_driver_loaded.toml
@@ -39,7 +39,7 @@ driver where host.os.type == "windows" and process.pid == 4 and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Expired or Revoked Driver Loaded
 In Windows environments, drivers facilitate communication between the OS and hardware. Adversaries exploit vulnerabilities in outdated drivers or misuse revoked certificates to execute malicious code in kernel mode, bypassing security controls. The detection rule identifies such threats by monitoring for drivers with expired or revoked signatures, focusing on processes critical to system integrity, thus flagging potential privilege escalation or defense evasion attempts.
diff --git a/rules/windows/privilege_escalation_exploit_cve_202238028.toml b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
index b416904bb8e..16dda31a156 100644
--- a/rules/windows/privilege_escalation_exploit_cve_202238028.toml
+++ b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
@@ -46,7 +46,7 @@ file where host.os.type == "windows" and event.type != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential privilege escalation via CVE-2022-38028
 
diff --git a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
index 3b34bff3439..046d36517ec 100644
--- a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
+++ b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
@@ -37,8 +37,8 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-file where host.os.type == "windows" and event.type != "deletion" and event.action != "open" and 
- file.name : ("ScheduledTasks.xml", "Services.xml") and 
+file where host.os.type == "windows" and event.type != "deletion" and event.action != "open" and
+ file.name : ("ScheduledTasks.xml", "Services.xml") and
   file.path : (
     "?:\\Windows\\SYSVOL\\domain\\Policies\\*\\MACHINE\\Preferences\\ScheduledTasks\\ScheduledTasks.xml",
     "?:\\Windows\\SYSVOL\\domain\\Policies\\*\\MACHINE\\Preferences\\Services\\Services.xml"
@@ -48,7 +48,7 @@ file where host.os.type == "windows" and event.type != "deletion" and event.acti
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation or Modification of a new GPO Scheduled Task or Service
 
diff --git a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
index f76fee68a41..a09d848795b 100644
--- a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
+++ b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
@@ -57,7 +57,7 @@ sequence by winlog.computer_name with maxspan=5m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Service Creation via Local Kerberos Authentication
 
diff --git a/rules/windows/privilege_escalation_lsa_auth_package.toml b/rules/windows/privilege_escalation_lsa_auth_package.toml
index ebffcb765c5..d0059930a6e 100644
--- a/rules/windows/privilege_escalation_lsa_auth_package.toml
+++ b/rules/windows/privilege_escalation_lsa_auth_package.toml
@@ -43,7 +43,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential LSA Authentication Package Abuse
 
diff --git a/rules/windows/privilege_escalation_make_token_local.toml b/rules/windows/privilege_escalation_make_token_local.toml
index 23552c3d2a7..41668e89b33 100644
--- a/rules/windows/privilege_escalation_make_token_local.toml
+++ b/rules/windows/privilege_escalation_make_token_local.toml
@@ -36,24 +36,24 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-authentication where 
- host.os.type : "windows" and winlog.event_data.LogonProcessName : "Advapi*" and 
- winlog.logon.type == "Interactive" and winlog.event_data.SubjectUserSid : ("S-1-5-21*", "S-1-12-*") and 
- winlog.event_data.TargetUserSid : ("S-1-5-21*", "S-1-12-*")  and process.executable : "C:\\*" and 
- not startswith~(winlog.event_data.SubjectUserSid, winlog.event_data.TargetUserSid) and 
- not process.executable : 
-            ("?:\\Windows\\System32\\winlogon.exe", 
-             "?:\\Windows\\System32\\wininit.exe", 
-             "?:\\Program Files\\*.exe", 
-             "?:\\Program Files (x86)\\*.exe", 
-             "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe", 
-             "?:\\Windows\\System32\\inetsrv\\w3wp.exe", 
+authentication where
+ host.os.type : "windows" and winlog.event_data.LogonProcessName : "Advapi*" and
+ winlog.logon.type == "Interactive" and winlog.event_data.SubjectUserSid : ("S-1-5-21*", "S-1-12-*") and
+ winlog.event_data.TargetUserSid : ("S-1-5-21*", "S-1-12-*")  and process.executable : "C:\\*" and
+ not startswith~(winlog.event_data.SubjectUserSid, winlog.event_data.TargetUserSid) and
+ not process.executable :
+            ("?:\\Windows\\System32\\winlogon.exe",
+             "?:\\Windows\\System32\\wininit.exe",
+             "?:\\Program Files\\*.exe",
+             "?:\\Program Files (x86)\\*.exe",
+             "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe",
+             "?:\\Windows\\System32\\inetsrv\\w3wp.exe",
              "?:\\Windows\\SysWOW64\\msiexec.exe")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Interactive Logon by an Unusual Process
 
diff --git a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
index 21643af5b41..be7d35953a3 100644
--- a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
+++ b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
@@ -54,7 +54,7 @@ process where event.type == "start" and host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Escalation via Vulnerable MSI Repair
 
diff --git a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
index 1a714ad9b13..217720c4d67 100644
--- a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
+++ b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
@@ -31,7 +31,7 @@ event.category:"authentication" and host.os.type:"windows" and winlog.logon.type
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Time Seen NewCredentials Logon Process
 
diff --git a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
index 914e76d5ef2..f1b31bfb038 100644
--- a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
+++ b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
@@ -46,7 +46,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Port Monitor or Print Processor Registration Abuse
 
diff --git a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
index 1582cf363c6..4bd1489ae45 100644
--- a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
+++ b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
@@ -56,7 +56,7 @@ sequence by host.id with maxspan=30s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Print Spooler Point and Print DLL
 
diff --git a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
index d9c5a9ac6fb..9092b398fd8 100644
--- a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
+++ b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
@@ -54,7 +54,7 @@ event.category : "file" and host.os.type : "windows" and event.type : "creation"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious PrintSpooler Service Executable File Creation
 
diff --git a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
index b62efa4f950..db16d8cff8d 100644
--- a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
+++ b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
@@ -50,7 +50,7 @@ file where host.os.type == "windows" and event.type == "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Print Spooler File Deletion
 
diff --git a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
index 8953e2de71d..07410769673 100644
--- a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
+++ b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
@@ -37,7 +37,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-registry where host.os.type == "windows" and event.type == "change" and process.executable != null and 
+registry where host.os.type == "windows" and event.type == "change" and process.executable != null and
   event.action == "modification" and registry.value == "ImagePath" and
   registry.key : (
     "*\\ADWS", "*\\AppHostSvc", "*\\AppReadiness", "*\\AudioEndpointBuilder", "*\\AxInstSV", "*\\camsvc", "*\\CertSvc",
@@ -90,7 +90,7 @@ registry where host.os.type == "windows" and event.type == "change" and process.
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privilege Escalation via Service ImagePath Modification
 
diff --git a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
index 3240d6eaba6..efe2906a9a0 100644
--- a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
+++ b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
@@ -55,7 +55,7 @@ registry.path : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privilege Escalation via Windir Environment Variable
 
diff --git a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
index 67a5e4854c7..29634909505 100644
--- a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
+++ b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
@@ -58,7 +58,7 @@ iam where event.action == "renamed-user-account" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Privileged Escalation via SamAccountName Spoofing
 
diff --git a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
index 6b8d0118def..d7d6c76b831 100644
--- a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
+++ b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
@@ -51,7 +51,7 @@ iam where event.action == "changed-computer-account" and user.id : ("S-1-5-21-*"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Remote Computer Account DnsHostName Update
 
diff --git a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
index 4bf6f7109ee..99e2eaf727e 100644
--- a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
+++ b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
@@ -73,7 +73,7 @@ any where host.os.type == "windows" and event.provider: "Microsoft-Windows-Secur
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 SeDebugPrivilege Enabled by a Suspicious Process
 
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
index 9d183646630..81fd695d2d7 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
@@ -46,7 +46,7 @@ process where host.os.type == "windows" and event.type == "start" and process.na
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface
 
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
index ac5454795a3..296f0872a56 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
@@ -48,7 +48,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer
 
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
index 4c4e4fdbd13..2ef4a271bb8 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
@@ -44,7 +44,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 UAC Bypass via ICMLuaUtil Elevated COM Interface
 
diff --git a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
index 8190711c258..9d358d020ba 100644
--- a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
@@ -50,7 +50,7 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
- process.args : "/autoclean" and process.args : "/d" and process.executable != null and 
+ process.args : "/autoclean" and process.args : "/d" and process.executable != null and
  not process.executable : (
         "C:\\Windows\\System32\\cleanmgr.exe",
         "C:\\Windows\\SysWOW64\\cleanmgr.exe",
@@ -63,7 +63,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 UAC Bypass via DiskCleanup Scheduled Task Hijack
 
diff --git a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
index abcd2445f99..262c8627f65 100644
--- a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
@@ -49,7 +49,7 @@ file where host.os.type == "windows" and event.type : "change" and process.name
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 UAC Bypass Attempt via Privileged IFileOperation COM Interface
 
diff --git a/rules/windows/privilege_escalation_unquoted_service_path.toml b/rules/windows/privilege_escalation_unquoted_service_path.toml
index a48dcfe165d..ec35cb10cb9 100644
--- a/rules/windows/privilege_escalation_unquoted_service_path.toml
+++ b/rules/windows/privilege_escalation_unquoted_service_path.toml
@@ -37,16 +37,16 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "windows" and event.type == "start" and 
+process where host.os.type == "windows" and event.type == "start" and
   (
-    process.executable : "?:\\Program.exe" or 
+    process.executable : "?:\\Program.exe" or
     process.executable regex """(C:\\Program Files \(x86\)\\|C:\\Program Files\\)\w+.exe"""
   )
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Exploitation of an Unquoted Service Path Vulnerability
 
diff --git a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
index 6b0325334ab..fd55fddace1 100644
--- a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
+++ b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
@@ -49,7 +49,7 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
- process.parent.name : "spoolsv.exe" and process.command_line != null and 
+ process.parent.name : "spoolsv.exe" and process.command_line != null and
  (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") and
 
  /* exclusions for FP control below */
@@ -67,7 +67,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Print Spooler Child Process
 
diff --git a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
index cb92d3708ce..35dba0aaade 100644
--- a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
+++ b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
@@ -67,7 +67,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Service Host Child Process - Childless Service
 
diff --git a/rules/windows/privilege_escalation_via_ppid_spoofing.toml b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
index b00731f8421..e5984252cb7 100644
--- a/rules/windows/privilege_escalation_via_ppid_spoofing.toml
+++ b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
@@ -63,15 +63,15 @@ process where host.os.type == "windows" and event.action == "start" and
 
  not (process.code_signature.subject_name in
            ("philandro Software GmbH", "Freedom Scientific Inc.", "TeamViewer Germany GmbH", "Projector.is, Inc.",
-            "TeamViewer GmbH", "Cisco WebEx LLC", "Dell Inc") and process.code_signature.trusted == true) and 
+            "TeamViewer GmbH", "Cisco WebEx LLC", "Dell Inc") and process.code_signature.trusted == true) and
 
  /* AM_Delta_Patch Windows Update */
  not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and
-      process.parent.executable : ("?:\\Windows\\System32\\wuauclt.exe", 
-                                   "?:\\Windows\\SysWOW64\\wuauclt.exe", 
-                                   "?:\\Windows\\UUS\\Packages\\Preview\\*\\wuaucltcore.exe", 
-                                   "?:\\Windows\\UUS\\amd64\\wuauclt.exe", 
-                                   "?:\\Windows\\UUS\\amd64\\wuaucltcore.exe", 
+      process.parent.executable : ("?:\\Windows\\System32\\wuauclt.exe",
+                                   "?:\\Windows\\SysWOW64\\wuauclt.exe",
+                                   "?:\\Windows\\UUS\\Packages\\Preview\\*\\wuaucltcore.exe",
+                                   "?:\\Windows\\UUS\\amd64\\wuauclt.exe",
+                                   "?:\\Windows\\UUS\\amd64\\wuaucltcore.exe",
                                    "?:\\ProgramData\\Microsoft\\Windows\\UUS\\*\\wuaucltcore.exe")) and
  not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and process.parent.executable == null) and
 
@@ -98,7 +98,7 @@ process where host.os.type == "windows" and event.action == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privileges Elevation via Parent Process PID Spoofing
 
diff --git a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
index 54db661628b..0c53307e8d4 100644
--- a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
+++ b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
@@ -54,7 +54,7 @@ file where host.os.type == "windows" and event.action : "Pipe Created*" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Privilege Escalation via Rogue Named Pipe Impersonation
 
diff --git a/rules/windows/privilege_escalation_via_token_theft.toml b/rules/windows/privilege_escalation_via_token_theft.toml
index a4a4b6dd1b3..cd263b5a012 100644
--- a/rules/windows/privilege_escalation_via_token_theft.toml
+++ b/rules/windows/privilege_escalation_via_token_theft.toml
@@ -53,7 +53,7 @@ process where host.os.type == "windows" and event.action == "start" and
 
 /* Ignores Windows print spooler service with correlation to Access Intelligent Form */
 not (process.parent.executable : "?\\Windows\\System32\\spoolsv.exe" and
-     process.executable: "?:\\Program Files*\\Access\\Intelligent Form\\*\\LaunchCreate.exe") and 
+     process.executable: "?:\\Program Files*\\Access\\Intelligent Form\\*\\LaunchCreate.exe") and
 
 /* Ignores Windows error reporting executables */
  not process.executable : ("?:\\Windows\\System32\\WerFault.exe",
@@ -79,29 +79,29 @@ not (process.parent.executable : "?\\Windows\\System32\\spoolsv.exe" and
 
 
 /* Ignores additional parent executables that run with elevated privileges */
- not process.parent.executable : 
-               ("?:\\Windows\\System32\\AtBroker.exe", 
-                "?:\\Windows\\system32\\svchost.exe", 
-                "?:\\Program Files (x86)\\*.exe", 
-                "?:\\Program Files\\*.exe", 
+ not process.parent.executable :
+               ("?:\\Windows\\System32\\AtBroker.exe",
+                "?:\\Windows\\system32\\svchost.exe",
+                "?:\\Program Files (x86)\\*.exe",
+                "?:\\Program Files\\*.exe",
                 "?:\\Windows\\System32\\msiexec.exe",
                 "?:\\Windows\\System32\\DriverStore\\*") and
 
 /* Ignores Windows binaries with a trusted signature and specific signature name */
  not (process.code_signature.trusted == true and
-      process.code_signature.subject_name : 
-                ("philandro Software GmbH", 
-                 "Freedom Scientific Inc.", 
-                 "TeamViewer Germany GmbH", 
-                 "Projector.is, Inc.", 
-                 "TeamViewer GmbH", 
-                 "Cisco WebEx LLC", 
+      process.code_signature.subject_name :
+                ("philandro Software GmbH",
+                 "Freedom Scientific Inc.",
+                 "TeamViewer Germany GmbH",
+                 "Projector.is, Inc.",
+                 "TeamViewer GmbH",
+                 "Cisco WebEx LLC",
                  "Dell Inc"))
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Created with an Elevated Token
 
diff --git a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
index 39bd669b6fb..8ad0c4f7a64 100644
--- a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
+++ b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
@@ -67,7 +67,7 @@ configuration where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows Service Installed via an Unusual Client
 
diff --git a/rules/windows/privilege_escalation_wpad_exploitation.toml b/rules/windows/privilege_escalation_wpad_exploitation.toml
index e331e08f58b..51a6807000f 100644
--- a/rules/windows/privilege_escalation_wpad_exploitation.toml
+++ b/rules/windows/privilege_escalation_wpad_exploitation.toml
@@ -41,7 +41,7 @@ sequence with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WPAD Service Exploit
 
diff --git a/rules_building_block/collection_archive_data_zip_imageload.toml b/rules_building_block/collection_archive_data_zip_imageload.toml
index 9a6070c5164..374fe42e867 100644
--- a/rules_building_block/collection_archive_data_zip_imageload.toml
+++ b/rules_building_block/collection_archive_data_zip_imageload.toml
@@ -34,7 +34,7 @@ type = "eql"
 query = '''
 library where host.os.type == "windows" and event.action == "load" and
   dll.name : ("System.IO.Compression.FileSystem.ni.dll", "System.IO.Compression.ni.dll") and
-  not 
+  not
   (
     (
       process.executable : (
@@ -55,7 +55,7 @@ library where host.os.type == "windows" and event.action == "load" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Compression DLL Loaded by Unusual Process
 
diff --git a/rules_building_block/collection_common_compressed_archived_file.toml b/rules_building_block/collection_common_compressed_archived_file.toml
index b21f4b11ee4..96825ec1829 100644
--- a/rules_building_block/collection_common_compressed_archived_file.toml
+++ b/rules_building_block/collection_common_compressed_archived_file.toml
@@ -75,7 +75,7 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File Compressed or Archived into Common Format
 
diff --git a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
index a8adbd20510..8f373dd4ddf 100644
--- a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
+++ b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml
@@ -44,7 +44,7 @@ file where host.os.type == "windows" and event.type == "creation" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File Staged in Root Folder of Recycle Bin
 
diff --git a/rules_building_block/collection_outlook_email_archive.toml b/rules_building_block/collection_outlook_email_archive.toml
index 364c3087bc3..b81f72825fc 100644
--- a/rules_building_block/collection_outlook_email_archive.toml
+++ b/rules_building_block/collection_outlook_email_archive.toml
@@ -47,7 +47,7 @@ process where host.os.type == "windows" and event.type == "start" and process.ar
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Accessing Outlook Data Files
 
diff --git a/rules_building_block/collection_posh_compression.toml b/rules_building_block/collection_posh_compression.toml
index d0c3b7649fd..7b0c75df1b9 100644
--- a/rules_building_block/collection_posh_compression.toml
+++ b/rules_building_block/collection_posh_compression.toml
@@ -56,7 +56,7 @@ event.category:process and host.os.type:windows and
     "IO.Compression.DeflateStream" or
     "IO.Compression.GZipStream" or
     "IO.Compression.ZLibStream"
-  ) and 
+  ) and
   powershell.file.script_block_text : (
     "CompressionLevel" or
     "CompressionMode" or
@@ -77,7 +77,7 @@ not file.directory : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Archive Compression Capabilities
 
diff --git a/rules_building_block/command_and_control_bitsadmin_activity.toml b/rules_building_block/command_and_control_bitsadmin_activity.toml
index 6590f57eaf7..ac685c4ce66 100644
--- a/rules_building_block/command_and_control_bitsadmin_activity.toml
+++ b/rules_building_block/command_and_control_bitsadmin_activity.toml
@@ -52,7 +52,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Bitsadmin Activity
 
diff --git a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
index 3837808b8c6..523a67a8c68 100644
--- a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
+++ b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml
@@ -50,7 +50,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft IIS Service Account Password Dumped
 
diff --git a/rules_building_block/credential_access_mdmp_file_creation.toml b/rules_building_block/credential_access_mdmp_file_creation.toml
index ff9e44a0df1..b0061e20171 100644
--- a/rules_building_block/credential_access_mdmp_file_creation.toml
+++ b/rules_building_block/credential_access_mdmp_file_creation.toml
@@ -82,7 +82,7 @@ file where host.os.type == "windows" and event.type == "creation" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Credential Access via Memory Dump File Creation
 
diff --git a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
index 0ee079f1987..9c269b7b9dd 100644
--- a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
+++ b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml
@@ -38,7 +38,7 @@ file where host.os.type == "windows" and event.type == "creation" and
   /* MDMP header */
   file.Ext.header_bytes : "4d444d50*" and
   not file.extension : ("dmp", "mdmp", "hdmp", "edmp", "full", "tdref", "cg", "tmp", "dat") and
-  not 
+  not
   (
     process.executable : "?:\\Program Files\\Endgame\\esensor.exe" and
     process.code_signature.trusted == true and length(file.extension) == 0
@@ -51,7 +51,7 @@ file where host.os.type == "windows" and event.type == "creation" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Memory Dump File with Unusual Extension
 
diff --git a/rules_building_block/credential_access_win_private_key_access.toml b/rules_building_block/credential_access_win_private_key_access.toml
index 34c69540713..6069308fb1e 100644
--- a/rules_building_block/credential_access_win_private_key_access.toml
+++ b/rules_building_block/credential_access_win_private_key_access.toml
@@ -69,7 +69,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Attempted Private Key Access
 
diff --git a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
index f2a6ddeb46a..d94d056cee7 100644
--- a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
+++ b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml
@@ -42,13 +42,13 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset: "aws.cloudtrail" and event.provider: "rds.amazonaws.com" 
-    and event.action: ("CreateDBSnapshot" or "CreateDBClusterSnapshot") and event.outcome: "success" 
+event.dataset: "aws.cloudtrail" and event.provider: "rds.amazonaws.com"
+    and event.action: ("CreateDBSnapshot" or "CreateDBClusterSnapshot") and event.outcome: "success"
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS RDS DB Snapshot Created
 AWS RDS DB Snapshots are backups of databases that ensure data recovery and continuity. However, adversaries may exploit this feature to bypass security controls or erase traces by reverting databases to previous states. The detection rule monitors successful snapshot creation events, serving as a foundational element to correlate with other alerts, thereby identifying potential misuse indicative of defense evasion tactics.
diff --git a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
index ff4306e1095..953c6604de4 100644
--- a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
+++ b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml
@@ -43,7 +43,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Binary Content Copy via Cmd.exe
 
diff --git a/rules_building_block/defense_evasion_cmstp_execution.toml b/rules_building_block/defense_evasion_cmstp_execution.toml
index d19aca8cc54..5996d030127 100644
--- a/rules_building_block/defense_evasion_cmstp_execution.toml
+++ b/rules_building_block/defense_evasion_cmstp_execution.toml
@@ -45,7 +45,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Defense Evasion via CMSTP.exe
 
diff --git a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
index c6bff02aeb7..c6b7c11757c 100644
--- a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
+++ b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml
@@ -56,7 +56,7 @@ file where host.os.type == "windows" and event.action != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Archive File with Unusual Extension
 
diff --git a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
index 2a3e248240c..45d2b10cd89 100644
--- a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
+++ b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml
@@ -51,7 +51,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\SysWOW64\\WerFault.exe",
             "?:\\Users\\*\\AppData\\Local\\Programs\\Opera\\opera.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -77,7 +77,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
             "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe",
             "?:\\Users\\*\\AppData\\Local\\Programs\\Opera\\opera.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -101,7 +101,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\BrowserCore\\BrowserCore.exe",
             "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
             "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -127,7 +127,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\SysWOW64\\reg.exe",
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\SysWOW64\\WerFault.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -135,7 +135,7 @@ process where host.os.type == "windows" and event.type == "start" and
           ) and process.code_signature.trusted == true
         ) or
         (
-          process.name : "cmd.exe" and 
+          process.name : "cmd.exe" and
           (
             process.command_line : (
               "C:\\WINDOWS\\system32\\cmd.exe /d /s /c \"chcp\"",
@@ -161,7 +161,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\System32\\reg.exe",
             "?:\\Windows\\SysWOW64\\reg.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -187,7 +187,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Users\\*\\AppData\\Local\\Island\\Island\\Application\\Island.exe",
             "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe",
             "?:\\Windows\\System32\\WerFault.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -224,7 +224,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\System32\\smartscreen.exe",
             "?:\\Windows\\explorer.exe",
             "?:\\Windows\\splwow64.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.name : "rundll32.exe" and
@@ -242,7 +242,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Program Files (x86)\\*",
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\splwow64.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -256,7 +256,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Communication App Child Process
 
diff --git a/rules_building_block/defense_evasion_dll_hijack.toml b/rules_building_block/defense_evasion_dll_hijack.toml
index f74dc8391fb..e8f448a0804 100644
--- a/rules_building_block/defense_evasion_dll_hijack.toml
+++ b/rules_building_block/defense_evasion_dll_hijack.toml
@@ -82,7 +82,7 @@ library where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unsigned DLL Loaded by a Trusted Process
 
diff --git a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
index 2ae63164fea..87cc43f6743 100644
--- a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
+++ b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml
@@ -39,7 +39,7 @@ sequence by user.id with maxspan=5s
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution via Microsoft DotNet ClickOnce Host
 
diff --git a/rules_building_block/defense_evasion_download_susp_extension.toml b/rules_building_block/defense_evasion_download_susp_extension.toml
index 82a6f512170..451b83d92d7 100644
--- a/rules_building_block/defense_evasion_download_susp_extension.toml
+++ b/rules_building_block/defense_evasion_download_susp_extension.toml
@@ -39,12 +39,12 @@ query = '''
 file where host.os.type == "windows" and event.type == "creation" and
   file.extension : (
     "appinstaller", "application", "appx", "appxbundle", "cpl", "diagcab", "diagpkg", "diagcfg", "manifest",
-    "msix", "pif", "search-ms", "searchConnector-ms", "settingcontent-ms", "symlink", "theme", "themepack" 
+    "msix", "pif", "search-ms", "searchConnector-ms", "settingcontent-ms", "symlink", "theme", "themepack"
   ) and file.Ext.windows.zone_identifier > 1 and
   not
   (
     (
-      file.extension : "msix" and 
+      file.extension : "msix" and
       file.path : (
         "?:\\Users\\*\\AppData\\Local\\Temp\\WinGet\\Microsoft.Winget.Source*",
         "?:\\Windows\\system32\\config\\systemprofile\\AppData\\Local\\Microsoft\\WinGet\\State\\defaultState\\Microsoft.PreIndexed.Package\\Microsoft.Winget.Source*"
@@ -52,7 +52,7 @@ file where host.os.type == "windows" and event.type == "creation" and
     ) or
     (
       process.name : "Teams.exe" and process.code_signature.trusted == true and
-      file.extension : "msix" and 
+      file.extension : "msix" and
       file.path : "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Teams\\tmp\\*"
     )
   )
@@ -60,7 +60,7 @@ file where host.os.type == "windows" and event.type == "creation" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File with Suspicious Extension Downloaded
 
diff --git a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
index 8dc8e03a3cf..87b32e7b421 100644
--- a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
+++ b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml
@@ -51,7 +51,7 @@ sequence with maxspan=1m
       "cscript.exe", "wscript.exe",
       "installutil.exe"
     ) and
-    not 
+    not
     (
       process.name : ("cmd.exe", "powershell.exe") and
       process.args : (
@@ -77,7 +77,7 @@ sequence with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution via MS VisualStudio Pre/Post Build Events
 
diff --git a/rules_building_block/defense_evasion_file_permission_modification.toml b/rules_building_block/defense_evasion_file_permission_modification.toml
index 8ecb20c862e..de6abfaf514 100644
--- a/rules_building_block/defense_evasion_file_permission_modification.toml
+++ b/rules_building_block/defense_evasion_file_permission_modification.toml
@@ -46,7 +46,7 @@ not (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File and Directory Permissions Modification
 
diff --git a/rules_building_block/defense_evasion_generic_deletion.toml b/rules_building_block/defense_evasion_generic_deletion.toml
index d9914104cba..9e578a1354d 100644
--- a/rules_building_block/defense_evasion_generic_deletion.toml
+++ b/rules_building_block/defense_evasion_generic_deletion.toml
@@ -32,10 +32,10 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "windows" and event.type == "start" and 
+process where host.os.type == "windows" and event.type == "start" and
 (
-  (process.name: "rundll32.exe" and process.args: "*InetCpl.cpl,Clear*") or 
-  (process.name: "reg.exe" and process.args:"delete") or 
+  (process.name: "rundll32.exe" and process.args: "*InetCpl.cpl,Clear*") or
+  (process.name: "reg.exe" and process.args:"delete") or
   (
     process.name: "cmd.exe" and process.args: ("*rmdir*", "*rm *", "rm") and
     not process.args : (
@@ -51,7 +51,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 File or Directory Deletion Command
 
diff --git a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
index 3f200b71591..3e38641979e 100644
--- a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
+++ b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml
@@ -45,7 +45,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Indirect Command Execution via Forfiles/Pcalua
 
diff --git a/rules_building_block/defense_evasion_injection_from_msoffice.toml b/rules_building_block/defense_evasion_injection_from_msoffice.toml
index 2f06dbb7516..552850cda1a 100644
--- a/rules_building_block/defense_evasion_injection_from_msoffice.toml
+++ b/rules_building_block/defense_evasion_injection_from_msoffice.toml
@@ -51,7 +51,7 @@ process where host.os.type == "windows" and event.action == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Process Injection from Malicious Document
 
diff --git a/rules_building_block/defense_evasion_installutil_command_activity.toml b/rules_building_block/defense_evasion_installutil_command_activity.toml
index 26cb68a3927..bea2afb6b05 100644
--- a/rules_building_block/defense_evasion_installutil_command_activity.toml
+++ b/rules_building_block/defense_evasion_installutil_command_activity.toml
@@ -49,7 +49,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Activity
 
diff --git a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
index 459b67672b0..1658ac17802 100644
--- a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
+++ b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml
@@ -43,7 +43,7 @@ library where host.os.type == "windows" and event.action == "load" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Image Loaded with Invalid Signature
 
diff --git a/rules_building_block/defense_evasion_masquerading_browsers.toml b/rules_building_block/defense_evasion_masquerading_browsers.toml
index 2be29000169..cbcd3cb01d5 100644
--- a/rules_building_block/defense_evasion_masquerading_browsers.toml
+++ b/rules_building_block/defense_evasion_masquerading_browsers.toml
@@ -168,7 +168,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Masquerading as Browser Process
 
diff --git a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
index df750959876..82dbef1dfea 100644
--- a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
+++ b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml
@@ -53,7 +53,7 @@ file where host.os.type == "windows" and event.action != "deletion" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Executable File with Unusual Extension
 
diff --git a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
index 2ff4acbe855..05d053cf198 100644
--- a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml
@@ -44,7 +44,7 @@ library where host.os.type == "windows" and event.action == "load" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Masquerading as VLC DLL
 
diff --git a/rules_building_block/defense_evasion_masquerading_windows_dll.toml b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
index a9e5951fe78..8b29903eec6 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_dll.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_dll.toml
@@ -107,7 +107,7 @@ library where event.action == "load" and dll.Ext.relative_file_creation_time <=
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Masquerading as System32 DLL
 
diff --git a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
index 8d85435b01d..51a9e6567fb 100644
--- a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
+++ b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml
@@ -33,7 +33,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where host.os.type == "windows" and event.type == "start" and 
+process where host.os.type == "windows" and event.type == "start" and
   (process.code_signature.status : "?*" or process.code_signature.exists != null) and
   process.name: (
       "agentactivationruntimestarter.exe", "agentservice.exe", "aitstatic.exe", "alg.exe", "apphostregistrationverifier.exe", "appidcertstorecheck.exe", "appidpolicyconverter.exe", "appidtel.exe", "applicationframehost.exe", "applysettingstemplatecatalog.exe", "applytrustoffline.exe", "approvechildrequest.exe", "appvclient.exe", "appvdllsurrogate.exe", "appvnice.exe", "appvshnotify.exe", "arp.exe", "assignedaccessguard.exe", "at.exe", "atbroker.exe", "attrib.exe", "audiodg.exe", "auditpol.exe", "authhost.exe", "autochk.exe", "autoconv.exe", "autofmt.exe", "axinstui.exe", "baaupdate.exe", "backgroundtaskhost.exe", "backgroundtransferhost.exe", "bcdboot.exe", "bcdedit.exe", "bdechangepin.exe", "bdehdcfg.exe", "bdeuisrv.exe", "bdeunlock.exe", "bioiso.exe", "bitlockerdeviceencryption.exe", "bitlockerwizard.exe", "bitlockerwizardelev.exe", "bitsadmin.exe", "bootcfg.exe", "bootim.exe", "bootsect.exe", "bridgeunattend.exe", "browserexport.exe", "browser_broker.exe", "bthudtask.exe", "bytecodegenerator.exe", "cacls.exe", "calc.exe", "camerasettingsuihost.exe", "castsrv.exe", "certenrollctrl.exe", "certreq.exe", "certutil.exe", "change.exe", "changepk.exe", "charmap.exe", "checknetisolation.exe", "chglogon.exe", "chgport.exe", "chgusr.exe", "chkdsk.exe", "chkntfs.exe", "choice.exe", "cidiag.exe", "cipher.exe", "cleanmgr.exe", "cliconfg.exe", "clip.exe", "clipup.exe", "cloudexperiencehostbroker.exe", "cloudnotifications.exe", "cmd.exe", "cmdkey.exe", "cmdl32.exe", "cmmon32.exe", "cmstp.exe", "cofire.exe", "colorcpl.exe", "comp.exe", "compact.exe", "compattelrunner.exe", "compmgmtlauncher.exe", "comppkgsrv.exe", "computerdefaults.exe", "conhost.exe", "consent.exe", "control.exe", "convert.exe", "convertvhd.exe", "coredpussvr.exe", "credentialenrollmentmanager.exe", "credentialuibroker.exe", "credwiz.exe", "cscript.exe", "csrss.exe", "ctfmon.exe", "cttune.exe", "cttunesvr.exe", "custominstallexec.exe", "customshellhost.exe", "dashost.exe", "dataexchangehost.exe", "datastorecachedumptool.exe", "dccw.exe", "dcomcnfg.exe", "ddodiag.exe", "defrag.exe", "deploymentcsphelper.exe", "desktopimgdownldr.exe", "devicecensus.exe", "devicecredentialdeployment.exe", "deviceeject.exe", "deviceenroller.exe", "devicepairingwizard.exe", "deviceproperties.exe", "dfdwiz.exe", "dfrgui.exe", "dialer.exe", "directxdatabaseupdater.exe", "diskpart.exe", "diskperf.exe", "diskraid.exe", "disksnapshot.exe", "dism.exe", "dispdiag.exe", "displayswitch.exe", "djoin.exe", "dllhost.exe", "dllhst3g.exe", "dmcertinst.exe", "dmcfghost.exe", "dmclient.exe", "dmnotificationbroker.exe", "dmomacpmo.exe", "dnscacheugc.exe", "doskey.exe", "dpapimig.exe", "dpiscaling.exe", "dpnsvr.exe", "driverquery.exe", "drvinst.exe", "dsmusertask.exe", "dsregcmd.exe", "dstokenclean.exe", "dusmtask.exe", "dvdplay.exe", "dwm.exe", "dwwin.exe", "dxdiag.exe", "dxgiadaptercache.exe", "dxpserver.exe", "eap3host.exe", "easeofaccessdialog.exe", "easinvoker.exe", "easpolicymanagerbrokerhost.exe", "edpcleanup.exe", "edpnotify.exe", "eduprintprov.exe", "efsui.exe", "ehstorauthn.exe", "eoaexperiences.exe", "esentutl.exe", "eudcedit.exe", "eventcreate.exe", "eventvwr.exe", "expand.exe", "extrac32.exe", "fc.exe", "fclip.exe", "fhmanagew.exe", "filehistory.exe", "find.exe", "findstr.exe", "finger.exe", "fixmapi.exe", "fltmc.exe", "fodhelper.exe", "fondue.exe", "fontdrvhost.exe", "fontview.exe", "forfiles.exe", "fsavailux.exe", "fsiso.exe", "fsquirt.exe", "fsutil.exe", "ftp.exe", "fvenotify.exe", "fveprompt.exe", "gamebarpresencewriter.exe", "gamepanel.exe", "genvalobj.exe", "getmac.exe", "gpresult.exe", "gpscript.exe", "gpupdate.exe", "grpconv.exe", "hdwwiz.exe", "help.exe", "hostname.exe", "hvax64.exe", "hvix64.exe", "hvsievaluator.exe", "icacls.exe", "icsentitlementhost.exe", "icsunattend.exe", "ie4uinit.exe", "ie4ushowie.exe", "iesettingsync.exe", "ieunatt.exe", "iexpress.exe", "immersivetpmvscmgrsvr.exe", "infdefaultinstall.exe", "inputswitchtoasthandler.exe", "iotstartup.exe", "ipconfig.exe", "iscsicli.exe", "iscsicpl.exe", "isoburn.exe", "klist.exe", "ksetup.exe", "ktmutil.exe", "label.exe", "languagecomponentsinstallercomhandler.exe", "launchtm.exe", "launchwinapp.exe", "legacynetuxhost.exe", "licensemanagershellext.exe", "licensingdiag.exe", "licensingui.exe", "locationnotificationwindows.exe", "locator.exe", "lockapphost.exe", "lockscreencontentserver.exe", "lodctr.exe", "logagent.exe", "logman.exe", "logoff.exe", "logonui.exe", "lpkinstall.exe", "lpksetup.exe", "lpremove.exe", "lsaiso.exe", "lsass.exe", "magnify.exe", "makecab.exe", "manage-bde.exe", "mavinject.exe", "mbaeparsertask.exe", "mblctr.exe", "mbr2gpt.exe", "mcbuilder.exe", "mdeserver.exe", "mdmagent.exe", "mdmappinstaller.exe", "mdmdiagnosticstool.exe", "mdres.exe", "mdsched.exe", "mfpmp.exe", "microsoft.uev.cscunpintool.exe", "microsoft.uev.synccontroller.exe", "microsoftedgebchost.exe", "microsoftedgecp.exe", "microsoftedgedevtools.exe", "microsoftedgesh.exe", "mmc.exe", "mmgaserver.exe", "mobsync.exe", "mountvol.exe", "mousocoreworker.exe", "mpnotify.exe", "mpsigstub.exe", "mrinfo.exe", "mschedexe.exe", "msconfig.exe", "msdt.exe", "msdtc.exe", "msfeedssync.exe", "msg.exe", "mshta.exe", "msiexec.exe", "msinfo32.exe", "mspaint.exe", "msra.exe", "msspellcheckinghost.exe", "mstsc.exe", "mtstocom.exe", "muiunattend.exe", "multidigimon.exe", "musnotification.exe", "musnotificationux.exe", "musnotifyicon.exe", "narrator.exe", "nbtstat.exe", "ndadmin.exe", "ndkping.exe", "net.exe", "net1.exe", "netbtugc.exe", "netcfg.exe", "netcfgnotifyobjecthost.exe", "netevtfwdr.exe", "nethost.exe", "netiougc.exe", "netplwiz.exe", "netsh.exe", "netstat.exe", "newdev.exe", "ngciso.exe", "nltest.exe", "notepad.exe", "nslookup.exe", "ntoskrnl.exe", "ntprint.exe", "odbcad32.exe", "odbcconf.exe", "ofdeploy.exe", "omadmclient.exe", "omadmprc.exe", "openfiles.exe", "openwith.exe", "optionalfeatures.exe", "osk.exe", "pacjsworker.exe", "packagedcwalauncher.exe", "packageinspector.exe", "passwordonwakesettingflyout.exe", "pathping.exe", "pcalua.exe", "pcaui.exe", "pcwrun.exe", "perfmon.exe", "phoneactivate.exe", "pickerhost.exe", "pinenrollmentbroker.exe", "ping.exe", "pkgmgr.exe", "pktmon.exe", "plasrv.exe", "pnpunattend.exe", "pnputil.exe", "poqexec.exe", "pospaymentsworker.exe", "powercfg.exe", "presentationhost.exe", "presentationsettings.exe", "prevhost.exe", "printbrmui.exe", "printfilterpipelinesvc.exe", "printisolationhost.exe", "printui.exe", "proquota.exe", "provlaunch.exe", "provtool.exe", "proximityuxhost.exe", "prproc.exe", "psr.exe", "pwlauncher.exe", "qappsrv.exe", "qprocess.exe", "query.exe", "quser.exe", "qwinsta.exe", "rasautou.exe", "rasdial.exe", "raserver.exe", "rasphone.exe", "rdpclip.exe", "rdpinit.exe", "rdpinput.exe", "rdpsa.exe", "rdpsaproxy.exe", "rdpsauachelper.exe", "rdpshell.exe", "rdpsign.exe", "rdrleakdiag.exe", "reagentc.exe", "recdisc.exe", "recover.exe", "recoverydrive.exe", "refsutil.exe", "reg.exe", "regedt32.exe", "regini.exe", "register-cimprovider.exe", "regsvr32.exe", "rekeywiz.exe", "relog.exe", "relpost.exe", "remoteapplifetimemanager.exe", "remoteposworker.exe", "repair-bde.exe", "replace.exe", "reset.exe", "resetengine.exe", "resmon.exe", "rmactivate.exe", "rmactivate_isv.exe", "rmactivate_ssp.exe", "rmactivate_ssp_isv.exe", "rmclient.exe", "rmttpmvscmgrsvr.exe", "robocopy.exe", "route.exe", "rpcping.exe", "rrinstaller.exe", "rstrui.exe", "runas.exe", "rundll32.exe", "runexehelper.exe", "runlegacycplelevated.exe", "runonce.exe", "runtimebroker.exe", "rwinsta.exe", "sc.exe", "schtasks.exe", "scriptrunner.exe", "sdbinst.exe", "sdchange.exe", "sdclt.exe", "sdiagnhost.exe", "searchfilterhost.exe", "searchindexer.exe", "searchprotocolhost.exe", "secedit.exe", "secinit.exe", "securekernel.exe", "securityhealthhost.exe", "securityhealthservice.exe", "securityhealthsystray.exe", "sensordataservice.exe", "services.exe", "sessionmsg.exe", "sethc.exe", "setspn.exe", "settingsynchost.exe", "setupcl.exe", "setupugc.exe", "setx.exe", "sfc.exe", "sgrmbroker.exe", "sgrmlpac.exe", "shellappruntime.exe", "shrpubw.exe", "shutdown.exe", "sigverif.exe", "sihclient.exe", "sihost.exe", "slidetoshutdown.exe", "slui.exe", "smartscreen.exe", "smss.exe", "sndvol.exe", "snippingtool.exe", "snmptrap.exe", "sort.exe", "spaceagent.exe", "spaceman.exe", "spatialaudiolicensesrv.exe", "spectrum.exe", "spoolsv.exe", "sppextcomobj.exe", "sppsvc.exe", "srdelayed.exe", "srtasks.exe", "stordiag.exe", "subst.exe", "svchost.exe", "sxstrace.exe", "syncappvpublishingserver.exe", "synchost.exe", "sysreseterr.exe", "systeminfo.exe", "systempropertiesadvanced.exe", "systempropertiescomputername.exe", "systempropertiesdataexecutionprevention.exe", "systempropertieshardware.exe", "systempropertiesperformance.exe", "systempropertiesprotection.exe", "systempropertiesremote.exe", "systemreset.exe", "systemsettingsadminflows.exe", "systemsettingsbroker.exe", "systemsettingsremovedevice.exe", "systemuwplauncher.exe", "systray.exe", "tabcal.exe", "takeown.exe", "tapiunattend.exe", "tar.exe", "taskhostw.exe", "taskkill.exe", "tasklist.exe", "taskmgr.exe", "tcblaunch.exe", "tcmsetup.exe", "tcpsvcs.exe", "thumbnailextractionhost.exe", "tieringengineservice.exe", "timeout.exe", "tokenbrokercookies.exe", "tpminit.exe", "tpmtool.exe", "tpmvscmgr.exe", "tpmvscmgrsvr.exe", "tracerpt.exe", "tracert.exe", "tscon.exe", "tsdiscon.exe", "tskill.exe", "tstheme.exe", "tswbprxy.exe", "ttdinject.exe", "tttracer.exe", "typeperf.exe", "tzsync.exe", "tzutil.exe", "ucsvc.exe", "uevagentpolicygenerator.exe", "uevappmonitor.exe", "uevtemplatebaselinegenerator.exe", "uevtemplateconfigitemgenerator.exe", "uimgrbroker.exe", "unlodctr.exe", "unregmp2.exe", "upfc.exe", "upgraderesultsui.exe", "upnpcont.exe", "upprinterinstaller.exe", "useraccountbroker.exe", "useraccountcontrolsettings.exe", "userinit.exe", "usoclient.exe", "utcdecoderhost.exe", "utilman.exe", "vaultcmd.exe", "vds.exe", "vdsldr.exe", "verclsid.exe", "verifier.exe", "verifiergui.exe", "vssadmin.exe", "vssvc.exe", "w32tm.exe", "waasmedicagent.exe", "waitfor.exe", "wallpaperhost.exe", "wbadmin.exe", "wbengine.exe", "wecutil.exe", "werfault.exe", "werfaultsecure.exe", "wermgr.exe", "wevtutil.exe", "wextract.exe", "where.exe", "whoami.exe", "wiaacmgr.exe", "wiawow64.exe", "wifitask.exe", "wimserv.exe", "winbiodatamodeloobe.exe", "windows.media.backgroundplayback.exe", "windows.warp.jitservice.exe", "windowsactiondialog.exe", "windowsupdateelevatedinstaller.exe", "wininit.exe", "winload.exe", "winlogon.exe", "winresume.exe", "winrs.exe", "winrshost.exe", "winrtnetmuahostserver.exe", "winsat.exe", "winver.exe", "wkspbroker.exe", "wksprt.exe", "wlanext.exe", "wlrmdr.exe", "wmpdmc.exe", "workfolders.exe", "wowreg32.exe", "wpcmon.exe", "wpctok.exe", "wpdshextautoplay.exe", "wpnpinst.exe", "wpr.exe", "write.exe", "wscadminui.exe", "wscollect.exe", "wscript.exe", "wsl.exe", "wsmanhttpconfig.exe", "wsmprovhost.exe", "wsqmcons.exe", "wsreset.exe", "wuapihost.exe", "wuauclt.exe", "wudfcompanionhost.exe", "wudfhost.exe", "wusa.exe", "wwahost.exe", "xblgamesavetask.exe", "xcopy.exe", "xwizard.exe", "aggregatorhost.exe", "diskusage.exe", "dtdump.exe", "ism.exe", "ndkperfcmd.exe", "ntkrla57.exe", "securekernella57.exe", "spaceutil.exe", "configure-smremoting.exe", "dcgpofix.exe", "dcpromo.exe", "dimc.exe", "diskshadow.exe", "drvcfg.exe", "escunattend.exe", "iashost.exe", "ktpass.exe", "lbfoadmin.exe", "netdom.exe", "rdspnf.exe", "rsopprov.exe", "sacsess.exe", "servermanager.exe", "servermanagerlauncher.exe", "setres.exe", "tsecimp.exe", "vssuirun.exe", "webcache.exe", "win32calc.exe", "certoc.exe", "sdndiagnosticstask.exe", "xpsrchvw.exe"
@@ -81,7 +81,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Masquerading as System32 Executable
 
diff --git a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
index f4127cfc1dc..337a05a0adc 100644
--- a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
+++ b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml
@@ -60,7 +60,7 @@ process where host.os.type == "windows" and event.action == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Troubleshooting Pack Cabinet Execution
 
diff --git a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
index fc4f5b5a55d..4fcb25cba5f 100644
--- a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
+++ b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml
@@ -50,7 +50,7 @@ sequence with maxspan=1m
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows Installer with Suspicious Properties
 
diff --git a/rules_building_block/defense_evasion_posh_defender_tampering.toml b/rules_building_block/defense_evasion_posh_defender_tampering.toml
index 830bfd439f3..8fdd09aec6f 100644
--- a/rules_building_block/defense_evasion_posh_defender_tampering.toml
+++ b/rules_building_block/defense_evasion_posh_defender_tampering.toml
@@ -63,7 +63,7 @@ event.category: "process" and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Windows Defender Tampering Capabilities
 
diff --git a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
index 2f6bb89c504..4870e7386b3 100644
--- a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
+++ b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml
@@ -64,7 +64,7 @@ event.category:process and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Log Clear Capabilities
 
diff --git a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
index 1f8d689dba2..2e3601d2871 100644
--- a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
+++ b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml
@@ -41,7 +41,7 @@ process.name : "* "
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Processes with Trailing Spaces
 
diff --git a/rules_building_block/defense_evasion_service_disabled_registry.toml b/rules_building_block/defense_evasion_service_disabled_registry.toml
index 9cad11ccc64..732e027c25c 100644
--- a/rules_building_block/defense_evasion_service_disabled_registry.toml
+++ b/rules_building_block/defense_evasion_service_disabled_registry.toml
@@ -38,7 +38,7 @@ registry where host.os.type == "windows" and event.type == "change" and
     "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\Start",
     "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\Start"
   ) and registry.data.strings : ("3", "4") and
-  not 
+  not
     (
       process.name : "services.exe" and user.id : "S-1-5-18"
     )
@@ -47,7 +47,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Service Disabled via Registry Modification
 
diff --git a/rules_building_block/defense_evasion_service_path_registry.toml b/rules_building_block/defense_evasion_service_path_registry.toml
index 64f93228773..90d66735fb4 100644
--- a/rules_building_block/defense_evasion_service_path_registry.toml
+++ b/rules_building_block/defense_evasion_service_path_registry.toml
@@ -52,7 +52,7 @@ registry where host.os.type == "windows" and event.type == "change" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Service Path Modification
 Service paths in Windows define the executable location for services. Adversaries may alter these paths to execute malicious code, achieving persistence or privilege escalation. The detection rule identifies unusual modifications to service paths by monitoring registry changes, specifically targeting paths not associated with standard system processes, thus flagging potential unauthorized alterations.
diff --git a/rules_building_block/defense_evasion_services_exe_path.toml b/rules_building_block/defense_evasion_services_exe_path.toml
index b7ec1dbe8be..cc419f1e7f6 100644
--- a/rules_building_block/defense_evasion_services_exe_path.toml
+++ b/rules_building_block/defense_evasion_services_exe_path.toml
@@ -43,7 +43,7 @@ process where event.type == "start" and process.name : "sc.exe" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Service Path Modification via sc.exe
 
diff --git a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
index 0cc93ccecfc..5d931ef8c6d 100644
--- a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
+++ b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml
@@ -71,7 +71,7 @@ process where host.os.type == "windows" and event.action == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Execution via MSIEXEC
 
diff --git a/rules_building_block/defense_evasion_unsigned_bits_client.toml b/rules_building_block/defense_evasion_unsigned_bits_client.toml
index bcaee625048..a2df4a6126f 100644
--- a/rules_building_block/defense_evasion_unsigned_bits_client.toml
+++ b/rules_building_block/defense_evasion_unsigned_bits_client.toml
@@ -43,7 +43,7 @@ not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unsigned BITS Service Client Process
 
diff --git a/rules_building_block/defense_evasion_unusual_process_extension.toml b/rules_building_block/defense_evasion_unusual_process_extension.toml
index 0fdcf0f4bd2..7224cd47199 100644
--- a/rules_building_block/defense_evasion_unusual_process_extension.toml
+++ b/rules_building_block/defense_evasion_unusual_process_extension.toml
@@ -30,9 +30,9 @@ type = "eql"
 
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
-  process.executable : "?*" and 
+  process.executable : "?*" and
   not process.name : ("*.exe", "*.com", "*.scr", "*.tmp", "*.dat") and
-  not process.executable : 
+  not process.executable :
     (
       "MemCompression",
       "Registry",
@@ -62,7 +62,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process Extension
 
diff --git a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
index 076c75ad9e0..525d7917302 100644
--- a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
+++ b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml
@@ -56,7 +56,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process Execution on WBEM Path
 
diff --git a/rules_building_block/defense_evasion_write_dac_access.toml b/rules_building_block/defense_evasion_write_dac_access.toml
index 6624b04b3bf..f38c60418dc 100644
--- a/rules_building_block/defense_evasion_write_dac_access.toml
+++ b/rules_building_block/defense_evasion_write_dac_access.toml
@@ -64,7 +64,7 @@ host.os.type: "windows" and event.action : ("Directory Service Access" or "objec
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WRITEDAC Access on Active Directory Object
 
diff --git a/rules_building_block/discovery_capnetraw_capability.toml b/rules_building_block/discovery_capnetraw_capability.toml
index 1a0db2aafaa..bc9c9ca2d97 100644
--- a/rules_building_block/discovery_capnetraw_capability.toml
+++ b/rules_building_block/discovery_capnetraw_capability.toml
@@ -68,7 +68,7 @@ not user.id:"0"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Network Traffic Capture via CAP_NET_RAW
 
diff --git a/rules_building_block/discovery_generic_account_groups.toml b/rules_building_block/discovery_generic_account_groups.toml
index 8bff1640ece..2d3753dbe45 100644
--- a/rules_building_block/discovery_generic_account_groups.toml
+++ b/rules_building_block/discovery_generic_account_groups.toml
@@ -63,7 +63,7 @@ and not process.parent.name : "LTSVC.exe" and not user.id : "S-1-5-18"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows Account or Group Discovery
 
diff --git a/rules_building_block/discovery_generic_process_discovery.toml b/rules_building_block/discovery_generic_process_discovery.toml
index 9a5947d7e3c..f0583d12ef4 100644
--- a/rules_building_block/discovery_generic_process_discovery.toml
+++ b/rules_building_block/discovery_generic_process_discovery.toml
@@ -54,7 +54,7 @@ process where host.os.type == "windows" and event.type == "start" and process.ar
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Discovery Using Built-in Tools
 
diff --git a/rules_building_block/discovery_generic_registry_query.toml b/rules_building_block/discovery_generic_registry_query.toml
index c8692fef37a..e1d3669d2a4 100644
--- a/rules_building_block/discovery_generic_registry_query.toml
+++ b/rules_building_block/discovery_generic_registry_query.toml
@@ -55,7 +55,7 @@ host.os.type:windows and event.category:process and event.type:start and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Query Registry using Built-in Tools
 
diff --git a/rules_building_block/discovery_hosts_file_access.toml b/rules_building_block/discovery_hosts_file_access.toml
index f64c5c242ed..6b7a1f22367 100644
--- a/rules_building_block/discovery_hosts_file_access.toml
+++ b/rules_building_block/discovery_hosts_file_access.toml
@@ -41,7 +41,7 @@ process.name in ("vi", "nano", "cat", "more", "less") and process.args == "/etc/
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 System Hosts File Access
 
diff --git a/rules_building_block/discovery_internet_capabilities.toml b/rules_building_block/discovery_internet_capabilities.toml
index c77f9ea4b66..bb131955702 100644
--- a/rules_building_block/discovery_internet_capabilities.toml
+++ b/rules_building_block/discovery_internet_capabilities.toml
@@ -33,14 +33,14 @@ timestamp_override = "event.ingested"
 type = "new_terms"
 
 query = '''
-host.os.type:windows and event.category:process and event.type:start and 
+host.os.type:windows and event.category:process and event.type:start and
 process.name.caseless:("ping.exe" or "tracert.exe" or "pathping.exe") and
 not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Discovery of Internet Capabilities via Built-in Tools
 
diff --git a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
index d53f3759ada..969df631664 100644
--- a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
+++ b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml
@@ -61,7 +61,7 @@ not process.name:(python* or chef-client)
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Enumeration of Kernel Modules via Proc
 
diff --git a/rules_building_block/discovery_linux_modprobe_enumeration.toml b/rules_building_block/discovery_linux_modprobe_enumeration.toml
index bfe8b45b86b..0cbefb2588a 100644
--- a/rules_building_block/discovery_linux_modprobe_enumeration.toml
+++ b/rules_building_block/discovery_linux_modprobe_enumeration.toml
@@ -64,7 +64,7 @@ file.path : ("/etc/modprobe.conf" or "/etc/modprobe.d" or /etc/modprobe.d/*) and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Modprobe File Event
 
diff --git a/rules_building_block/discovery_linux_sysctl_enumeration.toml b/rules_building_block/discovery_linux_sysctl_enumeration.toml
index 729e1069a4b..83a5d59a83e 100644
--- a/rules_building_block/discovery_linux_sysctl_enumeration.toml
+++ b/rules_building_block/discovery_linux_sysctl_enumeration.toml
@@ -63,7 +63,7 @@ file.path : ("/etc/sysctl.conf" or "/etc/sysctl.d" or /etc/sysctl.d/*) and not p
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Sysctl File Event
 
diff --git a/rules_building_block/discovery_linux_system_information_discovery.toml b/rules_building_block/discovery_linux_system_information_discovery.toml
index c5f6478fc24..a56bc536e18 100644
--- a/rules_building_block/discovery_linux_system_information_discovery.toml
+++ b/rules_building_block/discovery_linux_system_information_discovery.toml
@@ -40,7 +40,7 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Linux System Information Discovery
 
diff --git a/rules_building_block/discovery_linux_system_owner_user_discovery.toml b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
index a20226b1dbd..42bce6ada4d 100644
--- a/rules_building_block/discovery_linux_system_owner_user_discovery.toml
+++ b/rules_building_block/discovery_linux_system_owner_user_discovery.toml
@@ -34,13 +34,13 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and 
+process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and
 process.name : ("whoami", "w", "who", "users", "id")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 System Owner/User Discovery Linux
 
diff --git a/rules_building_block/discovery_net_share_discovery_winlog.toml b/rules_building_block/discovery_net_share_discovery_winlog.toml
index 06b6c79ee98..af3cf2674fa 100644
--- a/rules_building_block/discovery_net_share_discovery_winlog.toml
+++ b/rules_building_block/discovery_net_share_discovery_winlog.toml
@@ -34,18 +34,18 @@ tags = [
 type = "eql"
 
 query = '''
-sequence by user.name, source.port, source.ip with maxspan=15s 
- [file where event.action == "network-share-object-access-checked" and 
-  winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and 
+sequence by user.name, source.port, source.ip with maxspan=15s
+ [file where event.action == "network-share-object-access-checked" and
+  winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and
   source.ip != null and source.ip != "0.0.0.0" and source.ip != "::1" and source.ip != "::" and source.ip != "127.0.0.1"]
- [file where event.action == "network-share-object-access-checked" and 
-  winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and 
+ [file where event.action == "network-share-object-access-checked" and
+  winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and
   source.ip != null and source.ip != "0.0.0.0" and source.ip != "::1" and source.ip != "::" and source.ip != "127.0.0.1"]
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Network Share Discovery
 
diff --git a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
index bfa1b70ae95..185294e0925 100644
--- a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
+++ b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml
@@ -32,8 +32,8 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and ( 
-  (process.name in ("groups", "id")) or 
+process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and (
+  (process.name in ("groups", "id")) or
   (process.name == "dscl" and process.args : ("/Active Directory/*", "/Users*", "/Groups*")) or
   (process.name == "dscacheutil" and process.args in ("user", "group")) or
   (process.args in ("/etc/passwd", "/etc/master.passwd", "/etc/sudoers")) or
@@ -43,7 +43,7 @@ process where event.type == "start" and event.action in ("exec", "exec_event", "
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Account or Group Discovery via Built-In Tools
 
diff --git a/rules_building_block/discovery_of_domain_groups.toml b/rules_building_block/discovery_of_domain_groups.toml
index 6bbb7222cac..faa39098871 100644
--- a/rules_building_block/discovery_of_domain_groups.toml
+++ b/rules_building_block/discovery_of_domain_groups.toml
@@ -42,7 +42,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Discovery of Domain Groups
 
diff --git a/rules_building_block/discovery_posh_generic.toml b/rules_building_block/discovery_posh_generic.toml
index deb61540a4b..4f841e5adab 100644
--- a/rules_building_block/discovery_posh_generic.toml
+++ b/rules_building_block/discovery_posh_generic.toml
@@ -104,7 +104,7 @@ event.category:process and host.os.type:windows and
     ) or
     (
       ("Directoryservices.Activedirectory" or
-      "DirectoryServices.AccountManagement") and 
+      "DirectoryServices.AccountManagement") and
       (
         "Domain Admins" or "DomainControllers" or
         "FindAllGlobalCatalogs" or "GetAllTrustRelationships" or
@@ -143,7 +143,7 @@ event.category:process and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Discovery Capabilities
 
diff --git a/rules_building_block/discovery_posh_password_policy.toml b/rules_building_block/discovery_posh_password_policy.toml
index 102a6ef780b..a879327d121 100644
--- a/rules_building_block/discovery_posh_password_policy.toml
+++ b/rules_building_block/discovery_posh_password_policy.toml
@@ -85,7 +85,7 @@ event.category: "process" and host.os.type:windows and
 ) and not powershell.file.script_block_text : (
     "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators"
   )
-  and not 
+  and not
   (
     powershell.file.script_block_text : ("43c15630-959c-49e4-a977-758c5cc93408" and "CmdletsToExport" and "ActiveDirectory.Types.ps1xml")
   )
@@ -94,7 +94,7 @@ event.category: "process" and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Password Policy Discovery Capabilities
 
diff --git a/rules_building_block/discovery_potential_memory_seeking_activity.toml b/rules_building_block/discovery_potential_memory_seeking_activity.toml
index e8c32d38b53..bc5c9b28d30 100644
--- a/rules_building_block/discovery_potential_memory_seeking_activity.toml
+++ b/rules_building_block/discovery_potential_memory_seeking_activity.toml
@@ -52,7 +52,7 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Memory Seeking Activity
 
diff --git a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
index 49c59bb8d05..596eac2c651 100644
--- a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
+++ b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml
@@ -33,13 +33,13 @@ type = "eql"
 query = '''
 process where event.type == "start" and event.action in ("exec", "exec_event") and process.name in (
   "ps", "pstree", "htop", "pgrep"
-) and 
+) and
 not process.parent.name in ("amazon-ssm-agent", "snap")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Process Discovery via Built-In Applications
 
diff --git a/rules_building_block/discovery_signal_unusual_user_host.toml b/rules_building_block/discovery_signal_unusual_user_host.toml
index e48a0a6ead2..0780ec75172 100644
--- a/rules_building_block/discovery_signal_unusual_user_host.toml
+++ b/rules_building_block/discovery_signal_unusual_user_host.toml
@@ -42,7 +42,7 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Discovery Activity by User
 
diff --git a/rules_building_block/discovery_suspicious_proc_enumeration.toml b/rules_building_block/discovery_suspicious_proc_enumeration.toml
index a33a57ee20b..e0bb9d93778 100644
--- a/rules_building_block/discovery_suspicious_proc_enumeration.toml
+++ b/rules_building_block/discovery_suspicious_proc_enumeration.toml
@@ -53,7 +53,7 @@ timestamp_override = "event.ingested"
 type = "threshold"
 
 query = '''
-host.os.type:linux and event.category:file and event.action:"opened-file" and 
+host.os.type:linux and event.category:file and event.action:"opened-file" and
 file.path : (/proc/*/cmdline or /proc/*/stat or /proc/*/exe) and not process.name : (
   ps or netstat or landscape-sysin or w or pgrep or pidof or needrestart or apparmor_status
 ) and not process.parent.pid : 1
@@ -61,7 +61,7 @@ file.path : (/proc/*/cmdline or /proc/*/stat or /proc/*/exe) and not process.nam
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Suspicious Proc Pseudo File System Enumeration
 
diff --git a/rules_building_block/discovery_system_network_connections.toml b/rules_building_block/discovery_system_network_connections.toml
index f6da04eaf41..961c4ebe9ac 100644
--- a/rules_building_block/discovery_system_network_connections.toml
+++ b/rules_building_block/discovery_system_network_connections.toml
@@ -38,7 +38,7 @@ process.name in ("netstat", "lsof", "who", "w")
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 System Network Connections Discovery
 
diff --git a/rules_building_block/discovery_system_service_discovery.toml b/rules_building_block/discovery_system_service_discovery.toml
index 6fe45d6a859..8428b43c547 100644
--- a/rules_building_block/discovery_system_service_discovery.toml
+++ b/rules_building_block/discovery_system_service_discovery.toml
@@ -45,7 +45,7 @@ type = "eql"
 query = '''
 process where host.os.type == "windows" and event.type == "start" and
   (
-  ((process.name: "net.exe" or process.pe.original_file_name == "net.exe" or (process.name : "net1.exe" and 
+  ((process.name: "net.exe" or process.pe.original_file_name == "net.exe" or (process.name : "net1.exe" and
     not process.parent.name : "net.exe")) and process.args : ("start", "use") and process.args_count == 2) or
   ((process.name: "sc.exe" or process.pe.original_file_name == "sc.exe") and process.args: ("query", "q*")) or
   ((process.name: "tasklist.exe" or process.pe.original_file_name == "tasklist.exe") and process.args: "/svc") or
@@ -55,7 +55,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 System Service Discovery through built-in Windows Utilities
 
diff --git a/rules_building_block/discovery_system_time_discovery.toml b/rules_building_block/discovery_system_time_discovery.toml
index d813f41e5b8..0ab171529b9 100644
--- a/rules_building_block/discovery_system_time_discovery.toml
+++ b/rules_building_block/discovery_system_time_discovery.toml
@@ -45,17 +45,17 @@ query = '''
 process where host.os.type == "windows" and event.type == "start" and
 (
  (
-    (process.name: "net.exe" or (process.name : "net1.exe" and not process.parent.name : "net.exe")) and 
+    (process.name: "net.exe" or (process.name : "net1.exe" and not process.parent.name : "net.exe")) and
     process.args : "time" and not process.args : "/set"
- ) or 
- (process.name: "w32tm.exe" and process.args: "/tz") or 
+ ) or
+ (process.name: "w32tm.exe" and process.args: "/tz") or
  (process.name: "tzutil.exe" and process.args: "/g")
 ) and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 System Time Discovery
 
diff --git a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
index ad87e12cc59..ba26b991cb2 100644
--- a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
+++ b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml
@@ -46,7 +46,7 @@ event.dataset:aws.cloudtrail
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Retrieve User Data from AWS EC2 Instance
 
diff --git a/rules_building_block/discovery_win_network_connections.toml b/rules_building_block/discovery_win_network_connections.toml
index a7608781df8..8c3ea90124e 100644
--- a/rules_building_block/discovery_win_network_connections.toml
+++ b/rules_building_block/discovery_win_network_connections.toml
@@ -51,7 +51,7 @@ process where event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows System Network Connections Discovery
 
diff --git a/rules_building_block/discovery_windows_system_information_discovery.toml b/rules_building_block/discovery_windows_system_information_discovery.toml
index feeb366feb8..81b207b58fe 100644
--- a/rules_building_block/discovery_windows_system_information_discovery.toml
+++ b/rules_building_block/discovery_windows_system_information_discovery.toml
@@ -44,8 +44,8 @@ process where host.os.type == "windows" and event.type == "start" and
         "?:\\Users\\*\\AppData\\Local\\Keybase\\upd.exe",
         "?:\\Users\\*\\python*.exe"
     )
-  ) or 
-  process.name : ("systeminfo.exe", "hostname.exe") or 
+  ) or
+  process.name : ("systeminfo.exe", "hostname.exe") or
   (process.name : "wmic.exe" and process.args : "os" and process.args : "get")
 ) and not
 process.parent.executable : (
@@ -57,7 +57,7 @@ process.parent.executable : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Windows System Information Discovery
 
diff --git a/rules_building_block/execution_aws_lambda_function_updated.toml b/rules_building_block/execution_aws_lambda_function_updated.toml
index ed6bcd32b46..03e7066e33d 100644
--- a/rules_building_block/execution_aws_lambda_function_updated.toml
+++ b/rules_building_block/execution_aws_lambda_function_updated.toml
@@ -57,7 +57,7 @@ event.dataset: "aws.cloudtrail"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS Lambda Function Created or Updated
 
diff --git a/rules_building_block/execution_github_new_event_action_for_pat.toml b/rules_building_block/execution_github_new_event_action_for_pat.toml
index 201d28b232e..40e31c0ee68 100644
--- a/rules_building_block/execution_github_new_event_action_for_pat.toml
+++ b/rules_building_block/execution_github_new_event_action_for_pat.toml
@@ -32,13 +32,13 @@ type = "new_terms"
 
 query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
-event.action:* and github.hashed_token:* and 
+event.action:* and github.hashed_token:* and
 github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence GitHub Event for a Personal Access Token (PAT)
 
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
index b7782edd786..72a66816f57 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml
@@ -33,13 +33,13 @@ 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.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and
 github.repository_public:false
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT)
 
diff --git a/rules_building_block/execution_github_new_repo_interaction_for_user.toml b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
index ac550245dee..7db37155f5c 100644
--- a/rules_building_block/execution_github_new_repo_interaction_for_user.toml
+++ b/rules_building_block/execution_github_new_repo_interaction_for_user.toml
@@ -32,13 +32,13 @@ type = "new_terms"
 
 query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
-github.repo:* and user.name:* and 
+github.repo:* and user.name:* and
 github.repository_public:false
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of GitHub User Interaction with Private Repo
 
diff --git a/rules_building_block/execution_github_repo_created.toml b/rules_building_block/execution_github_repo_created.toml
index 1c6b3f48347..9fdd2d77fb3 100644
--- a/rules_building_block/execution_github_repo_created.toml
+++ b/rules_building_block/execution_github_repo_created.toml
@@ -36,7 +36,7 @@ configuration where event.dataset == "github.audit" and event.action == "repo.cr
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Repo Created
 GitHub repositories are essential for code collaboration and version control in cloud environments. Adversaries may exploit this by creating repositories to host malicious code or scripts for execution. The detection rule monitors GitHub audit logs for repository creation events, flagging potential unauthorized or suspicious activities that align with execution tactics, thereby aiding in early threat identification.
diff --git a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
index ab65cf80907..378d3f87923 100644
--- a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
+++ b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml
@@ -32,13 +32,13 @@ type = "new_terms"
 
 query = '''
 event.dataset:"github.audit" and event.category:"configuration" and
-github.actor_ip:* and github.repo:* and 
+github.actor_ip:* and github.repo:* and
 github.repository_public:false
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of GitHub Repo Interaction From a New IP
 
diff --git a/rules_building_block/execution_linux_segfault.toml b/rules_building_block/execution_linux_segfault.toml
index 8109eb86a08..e240131ff75 100644
--- a/rules_building_block/execution_linux_segfault.toml
+++ b/rules_building_block/execution_linux_segfault.toml
@@ -56,7 +56,7 @@ host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Segfault Detected
 
diff --git a/rules_building_block/execution_settingcontent_ms_file_creation.toml b/rules_building_block/execution_settingcontent_ms_file_creation.toml
index ae63fa296f2..99f931ed99b 100644
--- a/rules_building_block/execution_settingcontent_ms_file_creation.toml
+++ b/rules_building_block/execution_settingcontent_ms_file_creation.toml
@@ -47,7 +47,7 @@ file where host.os.type == "windows" and event.type == "creation" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation of SettingContent-ms Files
 
diff --git a/rules_building_block/execution_unsigned_service_executable.toml b/rules_building_block/execution_unsigned_service_executable.toml
index bf75bd637b2..f3c55936a91 100644
--- a/rules_building_block/execution_unsigned_service_executable.toml
+++ b/rules_building_block/execution_unsigned_service_executable.toml
@@ -33,15 +33,15 @@ timestamp_override = "event.ingested"
 type = "new_terms"
 
 query = '''
-host.os.type:windows and event.category:process and event.type:start and 
-process.parent.executable:"C:\\Windows\\System32\\services.exe" and 
+host.os.type:windows and event.category:process and event.type:start and
+process.parent.executable:"C:\\Windows\\System32\\services.exe" and
 (process.code_signature.exists:false or process.code_signature.trusted:false) and
 not process.code_signature.status : (errorCode_endpoint* or "errorChaining")
 '''
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Execution of an Unsigned Service
 
diff --git a/rules_building_block/execution_wmi_wbemtest.toml b/rules_building_block/execution_wmi_wbemtest.toml
index db8c02b2ca8..17931edd605 100644
--- a/rules_building_block/execution_wmi_wbemtest.toml
+++ b/rules_building_block/execution_wmi_wbemtest.toml
@@ -47,7 +47,7 @@ process where host.os.type == "windows" and event.type == "start" and process.na
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WMI WBEMTEST Utility Execution
 
diff --git a/rules_building_block/impact_github_member_removed_from_organization.toml b/rules_building_block/impact_github_member_removed_from_organization.toml
index 79e18cd5003..285f67aa20e 100644
--- a/rules_building_block/impact_github_member_removed_from_organization.toml
+++ b/rules_building_block/impact_github_member_removed_from_organization.toml
@@ -36,7 +36,7 @@ configuration where event.dataset == "github.audit" and event.action == "org.rem
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Member Removed From GitHub Organization
 
diff --git a/rules_building_block/impact_github_pat_access_revoked.toml b/rules_building_block/impact_github_pat_access_revoked.toml
index d24ec95104c..ccffaba8598 100644
--- a/rules_building_block/impact_github_pat_access_revoked.toml
+++ b/rules_building_block/impact_github_pat_access_revoked.toml
@@ -36,7 +36,7 @@ configuration where event.dataset == "github.audit" and event.action == "persona
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PAT Access Revoked
 
diff --git a/rules_building_block/impact_github_user_blocked_from_organization.toml b/rules_building_block/impact_github_user_blocked_from_organization.toml
index 66d1124f9c2..205939bd45f 100644
--- a/rules_building_block/impact_github_user_blocked_from_organization.toml
+++ b/rules_building_block/impact_github_user_blocked_from_organization.toml
@@ -36,7 +36,7 @@ configuration where event.dataset == "github.audit" and event.action == "org.blo
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 User Blocked From Organization
 
diff --git a/rules_building_block/initial_access_cross_site_scripting.toml b/rules_building_block/initial_access_cross_site_scripting.toml
index b487efe3dab..6bb9cfb0971 100644
--- a/rules_building_block/initial_access_cross_site_scripting.toml
+++ b/rules_building_block/initial_access_cross_site_scripting.toml
@@ -34,7 +34,7 @@ url.fragment : ("<iframe*", "*prompt(*)*", "<script*>", "<svg*>", "*onerror=*",
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Cross Site Scripting (XSS)
 
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
index 41aa7243dff..2ce624ced35 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml
@@ -38,7 +38,7 @@ github.programmatic_access_type:("OAuth access token" or "Fine-grained personal
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of IP Address For GitHub Personal Access Token (PAT)
 
diff --git a/rules_building_block/initial_access_github_new_ip_address_for_user.toml b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
index 7b61a3d79fb..d90e9df7e17 100644
--- a/rules_building_block/initial_access_github_new_ip_address_for_user.toml
+++ b/rules_building_block/initial_access_github_new_ip_address_for_user.toml
@@ -37,7 +37,7 @@ github.actor_ip:* and user.name:*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of IP Address For GitHub User
 
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
index bb72bf1491c..16fb913415c 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml
@@ -38,7 +38,7 @@ github.programmatic_access_type:("OAuth access token" or "Fine-grained personal
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of User Agent For a GitHub Personal Access Token (PAT)
 
diff --git a/rules_building_block/initial_access_github_new_user_agent_for_user.toml b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
index 21ceded9c8f..3e36b90ec87 100644
--- a/rules_building_block/initial_access_github_new_user_agent_for_user.toml
+++ b/rules_building_block/initial_access_github_new_user_agent_for_user.toml
@@ -37,7 +37,7 @@ github.user_agent:* and user.name:*
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of User-Agent For a GitHub User
 
diff --git a/rules_building_block/lateral_movement_at.toml b/rules_building_block/lateral_movement_at.toml
index 8a0f233df58..53193271255 100644
--- a/rules_building_block/lateral_movement_at.toml
+++ b/rules_building_block/lateral_movement_at.toml
@@ -47,7 +47,7 @@ process where host.os.type == "windows" and event.type == "start" and process.na
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 At.exe Command Lateral Movement
 
diff --git a/rules_building_block/lateral_movement_posh_winrm_activity.toml b/rules_building_block/lateral_movement_posh_winrm_activity.toml
index 5e4adb033c3..f8a7037aec0 100644
--- a/rules_building_block/lateral_movement_posh_winrm_activity.toml
+++ b/rules_building_block/lateral_movement_posh_winrm_activity.toml
@@ -67,7 +67,7 @@ event.category:process and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 PowerShell Script with Remote Execution Capabilities via WinRM
 
diff --git a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
index df32c9f47f9..e13287d81fe 100644
--- a/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
+++ b/rules_building_block/lateral_movement_rdp_conn_unusual_process.toml
@@ -52,7 +52,7 @@ network where host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Potential Outgoing RDP Connection by Unusual Process
 
diff --git a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
index 4fd17c15540..6f770e89ec7 100644
--- a/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
+++ b/rules_building_block/lateral_movement_unusual_process_sql_accounts.toml
@@ -77,7 +77,7 @@ process where event.type == "start" and host.os.type == "windows" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Unusual Process For MSSQL Service Accounts
 
diff --git a/rules_building_block/lateral_movement_wmic_remote.toml b/rules_building_block/lateral_movement_wmic_remote.toml
index 005545b0028..d1e5c890699 100644
--- a/rules_building_block/lateral_movement_wmic_remote.toml
+++ b/rules_building_block/lateral_movement_wmic_remote.toml
@@ -46,7 +46,7 @@ process where host.os.type == "windows" and event.type == "start" and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 WMIC Remote Command
 
diff --git a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
index 389bf6b851e..649e081c2df 100644
--- a/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
+++ b/rules_building_block/persistence_aws_iam_login_profile_added_to_user.toml
@@ -42,7 +42,7 @@ event.dataset: aws.cloudtrail and event.provider: "iam.amazonaws.com"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS IAM Login Profile Added to User
 
diff --git a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
index a89af91d7ee..19fb5483d00 100644
--- a/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
+++ b/rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml
@@ -68,7 +68,7 @@ not user.id:"0"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 CAP_SYS_ADMIN Assigned to Binary
 
diff --git a/rules_building_block/persistence_creation_of_kernel_module.toml b/rules_building_block/persistence_creation_of_kernel_module.toml
index d37f32d5d94..647a5305722 100644
--- a/rules_building_block/persistence_creation_of_kernel_module.toml
+++ b/rules_building_block/persistence_creation_of_kernel_module.toml
@@ -38,7 +38,7 @@ file.extension == "ko" and not process.name : (
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Creation of Kernel Module
 
diff --git a/rules_building_block/persistence_github_new_pat_for_user.toml b/rules_building_block/persistence_github_new_pat_for_user.toml
index 46c96c0b88e..757d94e86aa 100644
--- a/rules_building_block/persistence_github_new_pat_for_user.toml
+++ b/rules_building_block/persistence_github_new_pat_for_user.toml
@@ -38,7 +38,7 @@ github.programmatic_access_type:("OAuth access token" or "Fine-grained personal
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 First Occurrence of Personal Access Token (PAT) Use For a GitHub User
 
diff --git a/rules_building_block/persistence_github_new_user_added_to_organization.toml b/rules_building_block/persistence_github_new_user_added_to_organization.toml
index 79cb6e44bb6..f40a74b495f 100644
--- a/rules_building_block/persistence_github_new_user_added_to_organization.toml
+++ b/rules_building_block/persistence_github_new_user_added_to_organization.toml
@@ -36,7 +36,7 @@ configuration where event.dataset == "github.audit" and event.action == "org.add
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 New User Added To GitHub Organization
 
diff --git a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
index 9a6e4a798bf..8f6cb309a87 100644
--- a/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
+++ b/rules_building_block/persistence_iam_instance_request_to_iam_service.toml
@@ -66,7 +66,7 @@ any where event.dataset == "aws.cloudtrail"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 AWS EC2 Instance Interaction with IAM Service
 
diff --git a/rules_building_block/persistence_startup_folder_lnk.toml b/rules_building_block/persistence_startup_folder_lnk.toml
index 408296989db..3e9fc584a28 100644
--- a/rules_building_block/persistence_startup_folder_lnk.toml
+++ b/rules_building_block/persistence_startup_folder_lnk.toml
@@ -47,7 +47,7 @@ file where host.os.type == "windows" and event.type != "deletion" and file.exten
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Shortcut File Written or Modified on Startup Folder
 
diff --git a/rules_building_block/persistence_transport_agent_exchange.toml b/rules_building_block/persistence_transport_agent_exchange.toml
index 49d7fdb6a96..78efe8a27b6 100644
--- a/rules_building_block/persistence_transport_agent_exchange.toml
+++ b/rules_building_block/persistence_transport_agent_exchange.toml
@@ -67,7 +67,7 @@ event.category: "process" and host.os.type:windows and
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Microsoft Exchange Transport Agent Install Script
 
diff --git a/rules_building_block/privilege_escalation_trap_execution.toml b/rules_building_block/privilege_escalation_trap_execution.toml
index 3f632fff5ec..0750d7ccb77 100644
--- a/rules_building_block/privilege_escalation_trap_execution.toml
+++ b/rules_building_block/privilege_escalation_trap_execution.toml
@@ -41,7 +41,7 @@ process.name == "trap" and process.args : "SIG*"
 note = """## Triage and analysis
 
 > **Disclaimer**:
-> This investigation guide was generated 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.
+> 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 Trap Signals Execution
 Trap signals in Unix-like systems allow programs to execute specific commands when receiving interrupt signals, such as SIGINT or SIGTERM. Adversaries exploit this by embedding malicious commands in trap handlers to gain elevated privileges or persist on a system. The detection rule identifies suspicious trap command executions by monitoring process start events with specific signal arguments, helping to uncover potential privilege escalation attempts.

From 318569e6267025d8a38a7b7d2ea8ac3478a822c5 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Tue, 14 Jan 2025 15:46:00 -0600
Subject: [PATCH 06/16] patch bump

---
 pyproject.toml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pyproject.toml b/pyproject.toml
index 3a97802a2b0..3c509144f4e 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -1,6 +1,6 @@
 [project]
 name = "detection_rules"
-version = "0.3.15"
+version = "0.3.16"
 description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine."
 readme = "README.md"
 requires-python = ">=3.12"

From 826ad602c787077ea8cd852b72a510637600caeb Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 15 Jan 2025 08:10:19 -0600
Subject: [PATCH 07/16] update dates

---
 ...asion_azure_blob_permissions_modified.toml |  2 +-
 ..._evasion_prctl_process_name_tampering.toml | 37 ++++++++++++++++++-
 ...very_potential_syn_port_scan_detected.toml |  2 +-
 .../collection_posh_compression.toml          |  2 +-
 .../credential_access_mdmp_file_creation.toml |  2 +-
 ...dential_access_win_private_key_access.toml |  2 +-
 .../defense_evasion_cmstp_execution.toml      |  2 +-
 ...defense_evasion_masquerading_browsers.toml |  2 +-
 8 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
index cff6876989a..ec8f5875ee5 100644
--- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
+++ b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/11"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
diff --git a/rules/linux/defense_evasion_prctl_process_name_tampering.toml b/rules/linux/defense_evasion_prctl_process_name_tampering.toml
index 964a2111c84..00026960761 100644
--- a/rules/linux/defense_evasion_prctl_process_name_tampering.toml
+++ b/rules/linux/defense_evasion_prctl_process_name_tampering.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/09"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/09"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,41 @@ process.executable like (
   "/tmp/*", "/var/log/*", "/var/tmp/*", "/home/*", "/run/shm/*", "/run/*", "./*"
 )
 '''
+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 Potential Process Name Stomping with Prctl
+
+The `prctl` syscall in Linux allows processes to modify their attributes, including renaming themselves. This capability can be exploited by attackers to disguise malicious processes, making them harder to identify. The detection rule monitors for `prctl` invocations with specific arguments indicative of name changes, especially when linked to suspicious directories, thus flagging potential evasion attempts.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the executable path to determine if it matches any suspicious directories listed in the query, such as "/tmp/*" or "/var/tmp/*".
+- Examine the process tree to identify the parent process and any child processes spawned by the suspicious process, which may provide context on how the process was initiated and its potential impact.
+- Check the command line arguments and environment variables of the process to gather additional context on its intended function and any anomalies.
+- Investigate the user account under which the process is running to determine if it aligns with expected behavior or if it indicates potential compromise.
+- Correlate the alert with other security events or logs, such as file modifications or network connections, to identify any related malicious activity or patterns.
+- Assess the historical activity of the process executable and its associated files to determine if this behavior is new or part of a recurring pattern.
+
+### False positive analysis
+
+- System maintenance scripts may invoke prctl to rename processes for legitimate reasons. Review scheduled tasks and maintenance scripts in directories like /etc/cron.* and /etc/init.d to identify benign uses.
+- Development environments often use prctl for testing purposes. Exclude known development directories such as /home/developer or /tmp/dev from the rule to reduce noise.
+- Some monitoring or logging tools might use prctl to rename their processes for clarity. Identify these tools and add their executable paths to an exception list.
+- Custom scripts or applications that manage process names for operational reasons should be documented. Exclude these scripts by specifying their paths in the rule configuration.
+- Regularly review and update the exception list to ensure it reflects the current environment and does not inadvertently exclude new threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes identified by the detection rule, especially those with altered names in critical directories.
+- Conduct a thorough review of the affected system's process tree and file system to identify any additional signs of compromise or persistence mechanisms.
+- Restore any altered or suspicious files from a known good backup to ensure system integrity.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker.
+- Monitor the network for any signs of similar activity or attempts to use the `prctl` syscall with the `PR_SET_NAME` argument in other systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/network/discovery_potential_syn_port_scan_detected.toml b/rules/network/discovery_potential_syn_port_scan_detected.toml
index f885bc6865a..287ef80a6f9 100644
--- a/rules/network/discovery_potential_syn_port_scan_detected.toml
+++ b/rules/network/discovery_potential_syn_port_scan_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
diff --git a/rules_building_block/collection_posh_compression.toml b/rules_building_block/collection_posh_compression.toml
index 7b0c75df1b9..33c1366c6a6 100644
--- a/rules_building_block/collection_posh_compression.toml
+++ b/rules_building_block/collection_posh_compression.toml
@@ -5,7 +5,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 
 [rule]
diff --git a/rules_building_block/credential_access_mdmp_file_creation.toml b/rules_building_block/credential_access_mdmp_file_creation.toml
index b0061e20171..1cf45a686e2 100644
--- a/rules_building_block/credential_access_mdmp_file_creation.toml
+++ b/rules_building_block/credential_access_mdmp_file_creation.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/09/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
diff --git a/rules_building_block/credential_access_win_private_key_access.toml b/rules_building_block/credential_access_win_private_key_access.toml
index 6069308fb1e..68c94e94b60 100644
--- a/rules_building_block/credential_access_win_private_key_access.toml
+++ b/rules_building_block/credential_access_win_private_key_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/21"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
diff --git a/rules_building_block/defense_evasion_cmstp_execution.toml b/rules_building_block/defense_evasion_cmstp_execution.toml
index 5996d030127..d6cf124a698 100644
--- a/rules_building_block/defense_evasion_cmstp_execution.toml
+++ b/rules_building_block/defense_evasion_cmstp_execution.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/24"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
diff --git a/rules_building_block/defense_evasion_masquerading_browsers.toml b/rules_building_block/defense_evasion_masquerading_browsers.toml
index cbcd3cb01d5..f1a9ad17b56 100644
--- a/rules_building_block/defense_evasion_masquerading_browsers.toml
+++ b/rules_building_block/defense_evasion_masquerading_browsers.toml
@@ -3,7 +3,7 @@ bypass_bbr_timing = true
 creation_date = "2023/08/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]

From de38f9011b5c3c5d151922f8021886430fd70a3a Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 15 Jan 2025 09:09:03 -0600
Subject: [PATCH 08/16] update unit test on investigation guides

---
 tests/test_all_rules.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/test_all_rules.py b/tests/test_all_rules.py
index a45bcbcee12..ee7445ae338 100644
--- a/tests/test_all_rules.py
+++ b/tests/test_all_rules.py
@@ -217,8 +217,8 @@ def test_note_contains_triage_and_analysis(self):
         failures = []
 
         for rule in self.all_rules:
-            if not rule.contents.data.is_elastic_rule:
-                continue  # Don't enforce on non-Elastic rules
+            if not rule.contents.data.is_elastic_rule or rule.contents.data.building_block_type:
+                continue  # Don't enforce on non-Elastic rules or building block rules
 
             note_field = rule.contents.data.get("note")
 

From d9e7372dc2077fe1cfe5b386642ab7bd99fdd6d0 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 15 Jan 2025 10:04:02 -0600
Subject: [PATCH 09/16] add new guides

---
 .../aws/defense_evasion_sqs_purge_queue.toml  | 40 ++++++++++++++++++-
 ...uspicious_mac_ms_office_child_process.toml |  4 +-
 ...ication_apps_suspicious_child_process.toml | 37 ++++++++++++++++-
 3 files changed, 76 insertions(+), 5 deletions(-)

diff --git a/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml b/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml
index 1574d1a144c..a2cbdf29eb9 100644
--- a/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml
+++ b/rules/integrations/aws/defense_evasion_sqs_purge_queue.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/08"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/09"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,43 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS SQS Queue Purge"
-note = """## Triage and Analysis
+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 AWS SQS Queue Purge
+
+AWS Simple Queue Service (SQS) is a managed message queuing service that enables decoupling and scaling of microservices, distributed systems, and serverless applications. Adversaries may exploit SQS by purging queues to erase messages, disrupt operations, or hinder monitoring. The detection rule identifies successful purge actions in AWS CloudTrail logs, signaling potential defense evasion attempts by adversaries.
+
+### Possible investigation steps
+
+- Review the AWS CloudTrail logs for the specific event.provider "sqs.amazonaws.com" and event.action "PurgeQueue" to identify the time and source of the purge action.
+- Identify the IAM user or role associated with the purge action by examining the user identity information in the CloudTrail logs to determine if the action was authorized or potentially malicious.
+- Check the event.outcome "success" to confirm that the purge action was completed successfully and assess the impact on the queue's message data.
+- Investigate the context around the purge event by reviewing preceding and subsequent CloudTrail logs to identify any related or suspicious activities, such as unauthorized access attempts or changes to IAM policies.
+- Assess the potential impact on operations and monitoring by determining which messages were purged and if they contained critical or sensitive information.
+- Evaluate the necessity of implementing additional security measures, such as stricter IAM policies or enhanced logging and alerting, to prevent unauthorized queue purges in the future.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may trigger the purge action. To handle this, identify and whitelist known maintenance operations or specific IAM roles used by trusted personnel.
+- Automated scripts or applications that regularly purge queues as part of their normal operation can cause false positives. Review and document these processes, then create exceptions for these specific actions in your monitoring system.
+- Testing environments where queues are frequently purged for development purposes can lead to alerts. Exclude these environments from the rule by filtering based on environment tags or specific queue names.
+- Scheduled tasks that include queue purging as a cleanup mechanism might be misinterpreted as malicious. Ensure these tasks are logged and approved, and adjust the detection rule to ignore these scheduled events.
+- Third-party integrations that manage SQS queues and perform purges as part of their functionality should be assessed. Verify the legitimacy of these integrations and exclude their actions from triggering alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected AWS SQS queue to prevent further unauthorized purging or access. This can be done by modifying the queue's access policies to restrict permissions temporarily.
+- Review AWS CloudTrail logs to identify the source of the purge action, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger malicious activity.
+- Revoke or adjust permissions for the identified IAM user or role to prevent further unauthorized actions. Ensure that only necessary permissions are granted following the principle of least privilege.
+- Restore any critical messages or data that were purged, if possible, from backups or other data recovery solutions to minimize operational disruption.
+- Notify the security team and relevant stakeholders about the incident, providing details of the purge action and any identified malicious activity, to ensure coordinated response efforts.
+- Conduct a thorough review of IAM policies and access controls related to SQS to identify and remediate any potential security gaps that could be exploited in the future.
+- Enhance monitoring and alerting mechanisms for AWS SQS by implementing additional logging and anomaly detection to quickly identify and respond to similar threats in the future.
+
+## Triage and Analysis
 
 ### Investigating AWS SQS Queue Purge
 
diff --git a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
index 188dff16a67..79193a3599e 100644
--- a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
+++ b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -148,7 +148,7 @@ Microsoft Office applications on macOS can be exploited by adversaries to execut
 - Office error reporting may cause alerts. Exclude paths related to Microsoft Error Reporting to prevent unnecessary alerts.
 - Network setup and management tools such as "/usr/sbin/networksetup" can be benign. Exclude these executables if they are part of regular system operations.
 - Third-party applications like ToDesk and JumpCloud Agent might be flagged. Exclude their executables if they are verified as safe and part of normal operations.
-- Zotero integration can cause false positives with shell processes. Exclude specific command lines involving "$CFFIXED_USER_HOME/.zoteroIntegrationPipe" to avoid these alerts.
+- Zotero integration can cause false positives with shell processes. Exclude specific command lines involving "CFFIXED_USER_HOME/.zoteroIntegrationPipe" to avoid these alerts.
 
 ### Response and remediation
 
diff --git a/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml b/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml
index ea1ef34c023..b9cf2335d8a 100644
--- a/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml
+++ b/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/31"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -218,6 +218,41 @@ process where host.os.type == "windows" and event.type == "start" and
     )
   )
 '''
+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 Suspicious Communication App Child Process
+
+Communication apps like Slack, WebEx, and Teams are integral to modern workflows, facilitating collaboration. However, adversaries can exploit these apps by spawning unauthorized child processes, potentially masquerading as legitimate ones or exploiting vulnerabilities to execute malicious code. The detection rule identifies such anomalies by monitoring child processes of these apps, ensuring they are trusted and signed by recognized entities. This helps in identifying potential threats that deviate from expected behavior, thus safeguarding against unauthorized access and execution.
+
+### Possible investigation steps
+
+- Review the process details, including the parent process name and executable path, to confirm if the child process is expected or unusual for the communication app in question.
+- Check the code signature of the suspicious child process to determine if it is trusted and signed by a recognized entity, as specified in the query.
+- Investigate the command line arguments of the child process to identify any potentially malicious or unexpected commands being executed.
+- Correlate the event with other logs or alerts to identify any related suspicious activities or patterns, such as repeated unauthorized child process executions.
+- Assess the user account associated with the process to determine if it has been compromised or is exhibiting unusual behavior.
+- Examine the network activity of the affected system to identify any suspicious outbound connections that may indicate data exfiltration or communication with a command and control server.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger the rule if they spawn child processes from communication apps. Users can create exceptions for known update processes by verifying their code signatures and paths.
+- Custom scripts or automation tools that interact with communication apps might be flagged. Users should ensure these scripts are signed and located in trusted directories, then add them to the exception list.
+- Certain administrative tasks, such as using command-line tools like cmd.exe or powershell.exe, may be mistakenly identified as suspicious. Users can whitelist specific command lines or arguments that are regularly used in their environment.
+- Some third-party integrations with communication apps may generate child processes that are not inherently malicious. Users should verify the legitimacy of these integrations and add them to the trusted list if they are deemed safe.
+- Regularly review and update the list of trusted code signatures and executable paths to ensure that legitimate processes are not inadvertently flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious code.
+- Terminate any suspicious child processes identified by the detection rule that are not signed by recognized entities or are executing from unexpected locations.
+- Conduct a thorough review of the affected communication app's logs and configurations to identify any unauthorized changes or access patterns.
+- Restore the affected system from a known good backup if malicious activity is confirmed, ensuring that the backup is free from compromise.
+- Update the communication app and all related software to the latest versions to patch any known vulnerabilities that may have been exploited.
+- Implement application whitelisting to ensure only trusted and signed applications can execute, reducing the risk of similar threats.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on other systems."""
 
 
 [[rule.threat]]

From 1b2f7126eed62c32f4fcc3e835664b52d582ea56 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 15 Jan 2025 10:10:17 -0600
Subject: [PATCH 10/16] bump pyproject.toml version

---
 pyproject.toml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pyproject.toml b/pyproject.toml
index 3c509144f4e..962098d33d7 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -1,6 +1,6 @@
 [project]
 name = "detection_rules"
-version = "0.3.16"
+version = "0.3.17"
 description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine."
 readme = "README.md"
 requires-python = ">=3.12"

From b8974fb87e3e24d082edb7040d87d68999bec05f Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 15 Jan 2025 10:24:00 -0600
Subject: [PATCH 11/16] add tag

---
 rules/apm/apm_403_response_to_a_post.toml                    | 4 ++--
 rules/apm/apm_405_response_method_not_allowed.toml           | 4 ++--
 rules/apm/apm_sqlmap_user_agent.toml                         | 4 ++--
 ...and_and_control_google_drive_malicious_file_download.toml | 3 ++-
 .../command_and_control_non_standard_ssh_port.toml           | 3 ++-
 ...redential_access_cookies_chromium_browsers_debugging.toml | 3 ++-
 .../credential_access_forced_authentication_pipes.toml       | 3 ++-
 .../defense_evasion_agent_spoofing_mismatched_id.toml        | 4 ++--
 .../defense_evasion_agent_spoofing_multiple_hosts.toml       | 4 ++--
 .../defense_evasion_deleting_websvr_access_logs.toml         | 3 ++-
 ...efense_evasion_deletion_of_bash_command_line_history.toml | 3 ++-
 .../defense_evasion_elastic_agent_service_terminated.toml    | 3 ++-
 .../defense_evasion_encoding_rot13_python_script.toml        | 3 ++-
 .../defense_evasion_masquerading_space_after_filename.toml   | 3 ++-
 rules/cross-platform/defense_evasion_timestomp_touch.toml    | 3 ++-
 .../discovery_virtual_machine_fingerprinting_grep.toml       | 3 ++-
 ...xecution_aws_ssm_sendcommand_with_command_parameters.toml | 5 +++--
 .../execution_pentest_eggshell_remote_admin_tool.toml        | 3 ++-
 .../execution_potential_widespread_malware_infection.toml    | 5 +++--
 .../execution_suspicious_java_netcon_childproc.toml          | 3 ++-
 rules/cross-platform/guided_onboarding_sample_rule.toml      | 4 ++--
 .../initial_access_zoom_meeting_with_no_passcode.toml        | 4 ++--
 .../multiple_alerts_different_tactics_host.toml              | 4 ++--
 rules/cross-platform/multiple_alerts_involving_user.toml     | 4 ++--
 ...tence_credential_access_modify_auth_module_or_config.toml | 3 ++-
 .../persistence_shell_profile_modification.toml              | 3 ++-
 .../persistence_ssh_authorized_keys_modification.toml        | 3 ++-
 .../privilege_escalation_echo_nopasswd_sudoers.toml          | 3 ++-
 ...privilege_escalation_setuid_setgid_bit_set_via_chmod.toml | 3 ++-
 .../privilege_escalation_sudo_buffer_overflow.toml           | 3 ++-
 .../privilege_escalation_sudoers_file_mod.toml               | 3 ++-
 .../aws/collection_cloudtrail_logging_created.toml           | 3 ++-
 .../credential_access_root_console_failure_brute_force.toml  | 3 ++-
 .../aws/defense_evasion_configuration_recorder_stopped.toml  | 4 ++--
 .../aws/defense_evasion_ec2_network_acl_deletion.toml        | 3 ++-
 .../defense_evasion_elasticache_security_group_creation.toml | 4 ++--
 ...asion_elasticache_security_group_modified_or_deleted.toml | 4 ++--
 .../aws/defense_evasion_guardduty_detector_deletion.toml     | 4 ++--
 .../aws/defense_evasion_rds_instance_restored.toml           | 3 ++-
 .../defense_evasion_s3_bucket_configuration_deletion.toml    | 3 ++-
 ...defense_evasion_s3_bucket_lifecycle_expiration_added.toml | 3 ++-
 ...nse_evasion_s3_bucket_server_access_logging_disabled.toml | 3 ++-
 .../aws/defense_evasion_sts_get_federation_token.toml        | 3 ++-
 ...rity_group_ingress_rule_added_for_remote_connections.toml | 3 ++-
 rules/integrations/aws/defense_evasion_waf_acl_deletion.toml | 3 ++-
 .../aws/defense_evasion_waf_rule_or_rule_group_deletion.toml | 3 ++-
 .../discovery_ec2_multiple_discovery_api_calls_via_cli.toml  | 3 ++-
 ...ry_servicequotas_multi_region_service_quota_requests.toml | 3 ++-
 .../execution_lambda_external_layer_added_to_function.toml   | 3 ++-
 .../aws/execution_new_terms_cloudformation_createstack.toml  | 3 ++-
 .../exfiltration_ec2_ami_shared_with_separate_account.toml   | 3 ++-
 ...tration_ec2_ebs_snapshot_shared_with_another_account.toml | 3 ++-
 ...xfiltration_ec2_full_network_packet_capture_detected.toml | 3 ++-
 .../integrations/aws/exfiltration_ec2_vm_export_failure.toml | 3 ++-
 rules/integrations/aws/exfiltration_rds_snapshot_export.toml | 3 ++-
 ...n_s3_bucket_policy_added_for_external_account_access.toml | 3 ++-
 .../aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml | 4 ++--
 .../integrations/aws/impact_ec2_disable_ebs_encryption.toml  | 3 ++-
 .../aws/impact_efs_filesystem_or_mount_deleted.toml          | 4 ++--
 rules/integrations/aws/impact_iam_group_deletion.toml        | 3 ++-
 .../impact_kms_cmk_disabled_or_scheduled_for_deletion.toml   | 3 ++-
 rules/integrations/aws/impact_rds_group_deletion.toml        | 3 ++-
 .../aws/impact_rds_instance_cluster_deletion.toml            | 3 ++-
 .../aws/impact_rds_instance_cluster_stoppage.toml            | 3 ++-
 rules/integrations/aws/impact_rds_snapshot_deleted.toml      | 3 ++-
 ...pact_s3_bucket_object_uploaded_with_ransom_extension.toml | 3 ++-
 .../aws/impact_s3_object_encryption_with_external_key.toml   | 3 ++-
 .../aws/impact_s3_object_versioning_disabled.toml            | 3 ++-
 rules/integrations/aws/initial_access_password_recovery.toml | 3 ++-
 .../aws/initial_access_signin_console_login_no_mfa.toml      | 3 ++-
 ...teral_movement_aws_ssm_start_session_to_ec2_instance.toml | 3 ++-
 .../aws/lateral_movement_ec2_instance_console_login.toml     | 3 ++-
 .../aws/persistence_ec2_network_acl_creation.toml            | 3 ++-
 ...nce_iam_create_user_via_assumed_role_on_ec2_instance.toml | 3 ++-
 rules/integrations/aws/persistence_iam_group_creation.toml   | 3 ++-
 .../aws/persistence_iam_roles_anywhere_profile_created.toml  | 3 ++-
 ...les_anywhere_trusted_anchor_created_with_external_ca.toml | 3 ++-
 ...ce_lambda_backdoor_invoke_function_for_any_principal.toml | 3 ++-
 rules/integrations/aws/persistence_rds_cluster_creation.toml | 3 ++-
 rules/integrations/aws/persistence_rds_group_creation.toml   | 3 ++-
 .../integrations/aws/persistence_rds_instance_creation.toml  | 3 ++-
 .../aws/persistence_redshift_instance_creation.toml          | 3 ++-
 .../persistence_route_53_domain_transfer_lock_disabled.toml  | 3 ++-
 ...tence_route_53_domain_transferred_to_another_account.toml | 3 ++-
 ...rsistence_route_53_hosted_zone_associated_with_a_vpc.toml | 3 ++-
 rules/integrations/aws/persistence_route_table_created.toml  | 3 ++-
 .../aws/persistence_route_table_modified_or_deleted.toml     | 3 ++-
 .../aws/persistence_sts_assume_role_with_new_mfa.toml        | 3 ++-
 ...alation_ec2_instance_connect_ssh_public_key_uploaded.toml | 3 ++-
 .../aws/privilege_escalation_iam_saml_provider_updated.toml  | 3 ++-
 .../aws/privilege_escalation_sts_getsessiontoken_abuse.toml  | 3 ++-
 .../aws/privilege_escalation_sts_role_chaining.toml          | 3 ++-
 ...s_bedrock_high_confidence_misconduct_blocks_detected.toml | 3 ++-
 .../aws_bedrock_high_resource_consumption_detection.toml     | 5 +++--
 ...ultiple_sensitive_information_policy_blocks_detected.toml | 3 ++-
 .../aws_bedrock_multiple_topic_policy_blocks_detected.toml   | 3 ++-
 ..._multiple_validation_exception_errors_by_single_user.toml | 3 ++-
 .../aws_bedrock_multiple_word_policy_blocks_detected.toml    | 3 ++-
 .../azure/collection_update_event_hub_auth_rule.toml         | 4 ++--
 ...dential_access_azure_entra_totp_brute_force_attempts.toml | 3 ++-
 ...al_access_azure_full_network_packet_capture_detected.toml | 4 ++--
 ..._access_entra_id_device_code_auth_with_broker_client.toml | 3 ++-
 ...ential_access_entra_signin_brute_force_microsoft_365.toml | 3 ++-
 ...entra_signin_brute_force_microsoft_365_repeat_source.toml | 3 ++-
 .../credential_access_first_time_seen_device_code_auth.toml  | 3 ++-
 .../azure/credential_access_key_vault_modified.toml          | 4 ++--
 .../credential_access_storage_account_key_regenerated.toml   | 3 ++-
 ...se_evasion_azure_application_credential_modification.toml | 3 ++-
 .../defense_evasion_azure_automation_runbook_deleted.toml    | 4 ++--
 .../defense_evasion_azure_blob_permissions_modified.toml     | 3 ++-
 .../defense_evasion_azure_diagnostic_settings_deletion.toml  | 4 ++--
 .../azure/defense_evasion_event_hub_deletion.toml            | 4 ++--
 .../azure/defense_evasion_firewall_policy_deletion.toml      | 3 ++-
 .../defense_evasion_frontdoor_firewall_policy_deletion.toml  | 3 ++-
 .../azure/defense_evasion_kubernetes_events_deleted.toml     | 4 ++--
 .../azure/defense_evasion_network_watcher_deletion.toml      | 3 ++-
 .../azure/defense_evasion_suppression_rule_created.toml      | 4 ++--
 .../azure/discovery_blob_container_access_mod.toml           | 4 ++--
 .../azure/execution_command_virtual_machine.toml             | 4 ++--
 .../impact_azure_service_principal_credentials_added.toml    | 4 ++--
 rules/integrations/azure/impact_kubernetes_pod_deleted.toml  | 4 ++--
 rules/integrations/azure/impact_resource_group_deletion.toml | 4 ++--
 .../azure/impact_virtual_network_device_modified.toml        | 4 ++--
 .../azure/initial_access_external_guest_user_invite.toml     | 4 ++--
 .../azure/persistence_azure_automation_account_created.toml  | 4 ++--
 ...istence_azure_automation_runbook_created_or_modified.toml | 4 ++--
 .../azure/persistence_azure_automation_webhook_created.toml  | 4 ++--
 ...persistence_azure_conditional_access_policy_modified.toml | 4 ++--
 ...persistence_azure_global_administrator_role_assigned.toml | 4 ++--
 .../azure/persistence_azure_pim_user_added_global_admin.toml | 4 ++--
 ...ersistence_user_added_as_owner_for_azure_application.toml | 4 ++--
 ...ence_user_added_as_owner_for_azure_service_principal.toml | 4 ++--
 ...lege_escalation_azure_kubernetes_rolebinding_created.toml | 3 ++-
 .../beaconing/command_and_control_beaconing.toml             | 4 ++--
 .../command_and_control_beaconing_high_confidence.toml       | 4 ++--
 .../cloud_defend/container_workload_protection.toml          | 4 ++--
 ...redential_access_aws_creds_search_inside_a_container.toml | 3 ++-
 ...ction_sensitive_files_compression_inside_a_container.toml | 3 ++-
 ...ensitive_keys_or_passwords_search_inside_a_container.toml | 3 ++-
 ...ld_preload_shared_object_modified_inside_a_container.toml | 4 ++--
 ..._suspicious_network_tool_launched_inside_a_container.toml | 3 ++-
 ...tainer_management_binary_launched_inside_a_container.toml | 3 ++-
 ...on_file_made_executable_via_chmod_inside_a_container.toml | 3 ++-
 .../execution_interactive_exec_to_container.toml             | 3 ++-
 ...on_interactive_shell_spawned_from_inside_a_container.toml | 3 ++-
 ...ution_netcat_listener_established_inside_a_container.toml | 3 ++-
 ...access_ssh_connection_established_inside_a_container.toml | 3 ++-
 ...ral_movement_ssh_process_launched_inside_a_container.toml | 3 ++-
 ..._ssh_authorized_keys_modification_inside_a_container.toml | 3 ++-
 ...ation_debugfs_launched_inside_a_privileged_container.toml | 3 ++-
 ...alation_mount_launched_inside_a_privileged_container.toml | 3 ++-
 ...container_escape_via_modified_notify_on_release_file.toml | 3 ++-
 ...ial_container_escape_via_modified_release_agent_file.toml | 3 ++-
 ...e_escalation_cyberarkpas_error_audit_event_promotion.toml | 3 ++-
 ..._cyberarkpas_recommended_events_to_monitor_promotion.toml | 3 ++-
 ...ation_ml_high_bytes_destination_geo_country_iso_code.toml | 3 ++-
 .../ded/exfiltration_ml_high_bytes_destination_ip.toml       | 3 ++-
 .../ded/exfiltration_ml_high_bytes_destination_port.toml     | 3 ++-
 .../exfiltration_ml_high_bytes_destination_region_name.toml  | 3 ++-
 ...xfiltration_ml_high_bytes_written_to_external_device.toml | 3 ++-
 ...ion_ml_high_bytes_written_to_external_device_airdrop.toml | 3 ++-
 ...iltration_ml_rare_process_writing_to_external_device.toml | 3 ++-
 ...nd_and_control_ml_dga_activity_using_sunburst_domain.toml | 3 ++-
 .../dga/command_and_control_ml_dga_high_sum_probability.toml | 3 ++-
 ...mand_and_control_ml_dns_request_high_dga_probability.toml | 3 ++-
 ..._control_ml_dns_request_predicted_to_be_a_dga_domain.toml | 3 ++-
 .../defense_evasion_elastic_memory_threat_detected.toml      | 4 ++--
 .../defense_evasion_elastic_memory_threat_prevented.toml     | 4 ++--
 rules/integrations/endpoint/elastic_endpoint_security.toml   | 4 ++--
 .../elastic_endpoint_security_behavior_detected.toml         | 4 ++--
 .../elastic_endpoint_security_behavior_prevented.toml        | 4 ++--
 .../endpoint/execution_elastic_malicious_file_detected.toml  | 4 ++--
 .../endpoint/execution_elastic_malicious_file_prevented.toml | 4 ++--
 .../endpoint/impact_elastic_ransomware_detected.toml         | 4 ++--
 .../endpoint/impact_elastic_ransomware_prevented.toml        | 4 ++--
 .../fim/persistence_suspicious_file_modifications.toml       | 3 ++-
 .../gcp/collection_gcp_pub_sub_subscription_creation.toml    | 3 ++-
 .../gcp/collection_gcp_pub_sub_topic_creation.toml           | 3 ++-
 .../gcp/defense_evasion_gcp_firewall_rule_created.toml       | 3 ++-
 .../gcp/defense_evasion_gcp_firewall_rule_deleted.toml       | 3 ++-
 .../gcp/defense_evasion_gcp_firewall_rule_modified.toml      | 3 ++-
 .../gcp/defense_evasion_gcp_logging_bucket_deletion.toml     | 3 ++-
 .../gcp/defense_evasion_gcp_logging_sink_deletion.toml       | 3 ++-
 .../defense_evasion_gcp_pub_sub_subscription_deletion.toml   | 3 ++-
 .../gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml      | 3 ++-
 ...se_evasion_gcp_storage_bucket_configuration_modified.toml | 3 ++-
 ...ense_evasion_gcp_storage_bucket_permissions_modified.toml | 3 ++-
 ...se_evasion_gcp_virtual_private_cloud_network_deleted.toml | 3 ++-
 ...ense_evasion_gcp_virtual_private_cloud_route_created.toml | 3 ++-
 ...ense_evasion_gcp_virtual_private_cloud_route_deleted.toml | 3 ++-
 .../gcp/exfiltration_gcp_logging_sink_modification.toml      | 3 ++-
 rules/integrations/gcp/impact_gcp_iam_role_deletion.toml     | 3 ++-
 .../integrations/gcp/impact_gcp_service_account_deleted.toml | 3 ++-
 .../gcp/impact_gcp_service_account_disabled.toml             | 3 ++-
 .../integrations/gcp/impact_gcp_storage_bucket_deleted.toml  | 4 ++--
 .../gcp/initial_access_gcp_iam_custom_role_creation.toml     | 3 ++-
 .../persistence_gcp_iam_service_account_key_deletion.toml    | 3 ++-
 .../gcp/persistence_gcp_key_created_for_service_account.toml | 3 ++-
 .../gcp/persistence_gcp_service_account_created.toml         | 3 ++-
 ...nse_evasion_github_protected_branch_settings_changed.toml | 4 ++--
 rules/integrations/github/execution_github_app_deleted.toml  | 4 ++--
 ...xecution_github_high_number_of_cloned_repos_from_pat.toml | 3 ++-
 ...on_github_ueba_multiple_behavior_alerts_from_account.toml | 3 ++-
 .../github/execution_new_github_app_installed.toml           | 4 ++--
 .../github/impact_github_repository_deleted.toml             | 3 ++-
 .../github/persistence_github_org_owner_added.toml           | 3 ++-
 .../github/persistence_organization_owner_role_granted.toml  | 3 ++-
 ...pace_drive_encryption_key_accessed_by_anonymous_user.toml | 3 ++-
 ...rkspace_new_oauth_login_from_third_party_application.toml | 4 ++--
 .../google_workspace_alert_center_promotion.toml             | 3 ++-
 ...itial_access_google_workspace_suspended_user_renewed.toml | 3 ++-
 .../kubernetes/discovery_denied_service_account_request.toml | 4 ++--
 .../kubernetes/discovery_suspicious_self_subject_review.toml | 4 ++--
 .../integrations/kubernetes/execution_user_exec_to_pod.toml  | 4 ++--
 .../initial_access_anonymous_request_authorized.toml         | 4 ++--
 ...rsistence_exposed_service_created_with_type_nodeport.toml | 4 ++--
 ..._container_created_with_excessive_linux_capabilities.toml | 4 ++--
 .../privilege_escalation_pod_created_with_hostipc.toml       | 4 ++--
 .../privilege_escalation_pod_created_with_hostnetwork.toml   | 4 ++--
 .../privilege_escalation_pod_created_with_hostpid.toml       | 4 ++--
 ...scalation_pod_created_with_sensitive_hostpath_volume.toml | 4 ++--
 .../privilege_escalation_privileged_pod_created.toml         | 4 ++--
 ..._suspicious_assignment_of_controller_service_account.toml | 4 ++--
 .../lmd/lateral_movement_ml_high_mean_rdp_process_args.toml  | 3 ++-
 .../lateral_movement_ml_high_mean_rdp_session_duration.toml  | 3 ++-
 .../lmd/lateral_movement_ml_high_remote_file_size.toml       | 3 ++-
 ...teral_movement_ml_high_variance_rdp_session_duration.toml | 3 ++-
 .../lmd/lateral_movement_ml_rare_remote_file_directory.toml  | 3 ++-
 .../lmd/lateral_movement_ml_rare_remote_file_extension.toml  | 3 ++-
 ...al_movement_ml_spike_in_connections_from_a_source_ip.toml | 3 ++-
 ...movement_ml_spike_in_connections_to_a_destination_ip.toml | 3 ++-
 .../lmd/lateral_movement_ml_spike_in_rdp_processes.toml      | 3 ++-
 .../lateral_movement_ml_spike_in_remote_file_transfers.toml  | 3 ++-
 .../lateral_movement_ml_unusual_time_for_an_rdp_session.toml | 3 ++-
 .../o365/collection_microsoft_365_new_inbox_rule.toml        | 4 ++--
 ...ccess_microsoft_365_brute_force_user_account_attempt.toml | 3 ++-
 ...ess_microsoft_365_potential_password_spraying_attack.toml | 3 ++-
 .../credential_access_user_excessive_sso_logon_errors.toml   | 3 ++-
 ...se_evasion_microsoft_365_exchange_dlp_policy_removed.toml | 3 ++-
 ...icrosoft_365_exchange_malware_filter_policy_deletion.toml | 3 ++-
 ...asion_microsoft_365_exchange_malware_filter_rule_mod.toml | 3 ++-
 ...ion_microsoft_365_exchange_safe_attach_rule_disabled.toml | 3 ++-
 ..._evasion_microsoft_365_mailboxauditbypassassociation.toml | 4 ++--
 ...ation_microsoft_365_exchange_transport_rule_creation.toml | 4 ++--
 ...filtration_microsoft_365_exchange_transport_rule_mod.toml | 4 ++--
 ...tration_microsoft_365_mass_download_by_a_single_user.toml | 4 ++--
 .../impact_microsoft_365_potential_ransomware_activity.toml  | 4 ++--
 ...impact_microsoft_365_unusual_volume_of_file_deletion.toml | 4 ++--
 .../initial_access_microsoft_365_abnormal_clientappid.toml   | 3 ++-
 ...ss_microsoft_365_exchange_anti_phish_policy_deletion.toml | 3 ++-
 ...al_access_microsoft_365_exchange_anti_phish_rule_mod.toml | 3 ++-
 ...ial_access_microsoft_365_exchange_safelinks_disabled.toml | 3 ++-
 ...tial_access_microsoft_365_impossible_travel_activity.toml | 4 ++--
 ...access_microsoft_365_impossible_travel_portal_logins.toml | 4 ++--
 ...access_microsoft_365_portal_login_from_rare_location.toml | 4 ++--
 ...ess_microsoft_365_user_restricted_from_sending_email.toml | 3 ++-
 .../initial_access_o365_user_reported_phish_malware.toml     | 4 ++--
 .../o365/lateral_movement_malware_uploaded_onedrive.toml     | 4 ++--
 .../o365/lateral_movement_malware_uploaded_sharepoint.toml   | 4 ++--
 ...istence_exchange_suspicious_mailbox_right_delegation.toml | 4 ++--
 ..._microsoft_365_exchange_dkim_signing_config_disabled.toml | 4 ++--
 ...ce_microsoft_365_exchange_management_role_assignment.toml | 3 ++-
 ...tence_microsoft_365_global_administrator_role_assign.toml | 3 ++-
 ...e_microsoft_365_teams_custom_app_interaction_allowed.toml | 4 ++--
 ...sistence_microsoft_365_teams_external_access_enabled.toml | 4 ++--
 ...persistence_microsoft_365_teams_guest_access_enabled.toml | 4 ++--
 ...ivilege_escalation_new_or_modified_federation_domain.toml | 3 ++-
 .../okta/credential_access_attempted_bypass_of_okta_mfa.toml | 4 ++--
 ...ial_access_attempts_to_brute_force_okta_user_account.toml | 4 ++--
 ...multiple_auth_events_from_single_device_behind_proxy.toml | 4 ++--
 ...multiple_device_token_hashes_for_single_okta_session.toml | 4 ++--
 ...authentication_for_multiple_users_from_single_source.toml | 4 ++--
 ...n_for_multiple_users_with_the_same_device_token_hash.toml | 4 ++--
 ...dential_access_okta_brute_force_or_password_spraying.toml | 4 ++--
 ...ntial_access_okta_mfa_bombing_via_push_notifications.toml | 4 ++--
 ...ss_okta_multiple_device_token_hashes_for_single_user.toml | 4 ++--
 ...ially_successful_okta_bombing_via_push_notifications.toml | 4 ++--
 .../okta/credential_access_user_impersonation_access.toml    | 4 ++--
 ...ense_evasion_attempt_to_deactivate_okta_network_zone.toml | 3 ++-
 .../defense_evasion_attempt_to_delete_okta_network_zone.toml | 3 ++-
 ...ccurence_public_app_client_credential_token_exchange.toml | 3 ++-
 ...fense_evasion_okta_attempt_to_deactivate_okta_policy.toml | 4 ++--
 ..._evasion_okta_attempt_to_deactivate_okta_policy_rule.toml | 4 ++--
 .../defense_evasion_okta_attempt_to_delete_okta_policy.toml  | 4 ++--
 ...ense_evasion_okta_attempt_to_delete_okta_policy_rule.toml | 4 ++--
 ...nse_evasion_okta_attempt_to_modify_okta_network_zone.toml | 3 ++-
 .../defense_evasion_okta_attempt_to_modify_okta_policy.toml  | 4 ++--
 ...ense_evasion_okta_attempt_to_modify_okta_policy_rule.toml | 4 ++--
 ...spicious_okta_user_password_reset_or_unlock_attempts.toml | 4 ++--
 .../okta/impact_attempt_to_revoke_okta_api_token.toml        | 4 ++--
 .../impact_okta_attempt_to_deactivate_okta_application.toml  | 4 ++--
 .../okta/impact_okta_attempt_to_delete_okta_application.toml | 4 ++--
 .../okta/impact_okta_attempt_to_modify_okta_application.toml | 4 ++--
 rules/integrations/okta/impact_possible_okta_dos_attack.toml | 4 ++--
 ...cess_first_occurrence_user_session_started_via_proxy.toml | 4 ++--
 ...initial_access_new_authentication_behavior_detection.toml | 4 ++--
 .../okta/initial_access_okta_fastpass_phishing.toml          | 4 ++--
 ...itial_access_okta_user_attempted_unauthorized_access.toml | 4 ++--
 ...ta_user_sessions_started_from_different_geolocations.toml | 4 ++--
 .../initial_access_sign_in_events_via_third_party_idp.toml   | 4 ++--
 ...uccessful_application_sso_from_unknown_client_device.toml | 3 ++-
 ...ial_access_suspicious_activity_reported_by_okta_user.toml | 4 ++--
 .../lateral_movement_multiple_sessions_for_single_user.toml  | 4 ++--
 .../okta/okta_threatinsight_threat_suspected_promotion.toml  | 4 ++--
 ...ence_administrator_privileges_assigned_to_okta_group.toml | 4 ++--
 ...persistence_administrator_role_assigned_to_okta_user.toml | 4 ++--
 .../okta/persistence_attempt_to_create_okta_api_token.toml   | 4 ++--
 ...e_attempt_to_reset_mfa_factors_for_okta_user_account.toml | 4 ++--
 .../persistence_mfa_deactivation_with_no_reactivation.toml   | 4 ++--
 .../persistence_new_idp_successfully_added_by_admin.toml     | 4 ++--
 ...tempt_to_modify_or_delete_application_sign_on_policy.toml | 4 ++--
 ...ntials_used_to_login_to_okta_account_after_mfa_reset.toml | 3 ++-
 .../defense_evasion_ml_rare_process_for_a_host.toml          | 3 ++-
 ...defense_evasion_ml_rare_process_for_a_parent_process.toml | 3 ++-
 .../defense_evasion_ml_rare_process_for_a_user.toml          | 3 ++-
 ...evasion_ml_suspicious_windows_event_high_probability.toml | 3 ++-
 ..._evasion_ml_suspicious_windows_event_low_probability.toml | 3 ++-
 ...sion_ml_suspicious_windows_process_cluster_from_host.toml | 3 ++-
 ...spicious_windows_process_cluster_from_parent_process.toml | 3 ++-
 ...sion_ml_suspicious_windows_process_cluster_from_user.toml | 3 ++-
 rules/linux/collection_linux_clipboard_activity.toml         | 3 ++-
 .../linux/command_and_control_aws_cli_endpoint_url_used.toml | 3 ++-
 rules/linux/command_and_control_cat_network_activity.toml    | 3 ++-
 .../linux/command_and_control_cupsd_foomatic_rip_netcon.toml | 3 ++-
 .../linux/command_and_control_curl_socks_proxy_detected.toml | 3 ++-
 rules/linux/command_and_control_ip_forwarding_activity.toml  | 3 ++-
 .../command_and_control_linux_chisel_client_activity.toml    | 3 ++-
 .../command_and_control_linux_chisel_server_activity.toml    | 3 ++-
 rules/linux/command_and_control_linux_kworker_netcon.toml    | 3 ++-
 .../command_and_control_linux_proxychains_activity.toml      | 3 ++-
 .../linux/command_and_control_linux_ssh_x11_forwarding.toml  | 3 ++-
 ...nd_and_control_linux_suspicious_proxychains_activity.toml | 3 ++-
 ...mand_and_control_linux_tunneling_and_port_forwarding.toml | 3 ++-
 ..._suspicious_network_activity_from_unknown_executable.toml | 3 ++-
 rules/linux/command_and_control_tunneling_via_earthworm.toml | 3 ++-
 .../linux/credential_access_collection_sensitive_files.toml  | 3 ++-
 rules/linux/credential_access_credential_dumping.toml        | 3 ++-
 rules/linux/credential_access_gdb_init_process_hooking.toml  | 3 ++-
 rules/linux/credential_access_gdb_process_hooking.toml       | 3 ++-
 ...tial_access_potential_linux_local_account_bruteforce.toml | 3 ++-
 ...ntial_access_potential_linux_ssh_bruteforce_external.toml | 4 ++--
 ...ntial_access_potential_linux_ssh_bruteforce_internal.toml | 4 ++--
 ...ial_access_potential_successful_linux_ftp_bruteforce.toml | 3 ++-
 ...ial_access_potential_successful_linux_rdp_bruteforce.toml | 3 ++-
 ...ial_access_potential_successful_linux_ssh_bruteforce.toml | 4 ++--
 rules/linux/credential_access_proc_credential_dumping.toml   | 3 ++-
 rules/linux/credential_access_ssh_backdoor_log.toml          | 3 ++-
 ...access_unusual_instance_metadata_service_api_request.toml | 3 ++-
 .../linux/defense_evasion_acl_modification_via_setfacl.toml  | 3 ++-
 .../defense_evasion_attempt_to_disable_auditd_service.toml   | 3 ++-
 ...ense_evasion_attempt_to_disable_iptables_or_firewall.toml | 3 ++-
 .../defense_evasion_attempt_to_disable_syslog_service.toml   | 3 ++-
 ...asion_base16_or_base32_encoding_or_decoding_activity.toml | 3 ++-
 ...efense_evasion_binary_copied_to_suspicious_directory.toml | 3 ++-
 rules/linux/defense_evasion_chattr_immutable_file.toml       | 3 ++-
 rules/linux/defense_evasion_clear_kernel_ring_buffer.toml    | 3 ++-
 ...defense_evasion_creation_of_hidden_files_directories.toml | 3 ++-
 rules/linux/defense_evasion_directory_creation_in_bin.toml   | 3 ++-
 rules/linux/defense_evasion_disable_apparmor_attempt.toml    | 3 ++-
 rules/linux/defense_evasion_disable_selinux_attempt.toml     | 3 ++-
 ...efense_evasion_doas_configuration_creation_or_rename.toml | 3 ++-
 .../linux/defense_evasion_dynamic_linker_file_creation.toml  | 3 ++-
 .../defense_evasion_esxi_suspicious_timestomp_touch.toml     | 3 ++-
 rules/linux/defense_evasion_file_deletion_via_shred.toml     | 3 ++-
 rules/linux/defense_evasion_file_mod_writable_dir.toml       | 3 ++-
 rules/linux/defense_evasion_hex_payload_execution.toml       | 3 ++-
 rules/linux/defense_evasion_hidden_directory_creation.toml   | 3 ++-
 rules/linux/defense_evasion_hidden_file_dir_tmp.toml         | 3 ++-
 rules/linux/defense_evasion_hidden_shared_object.toml        | 3 ++-
 .../defense_evasion_interactive_shell_from_system_user.toml  | 5 +++--
 rules/linux/defense_evasion_kernel_module_removal.toml       | 3 ++-
 rules/linux/defense_evasion_kthreadd_masquerading.toml       | 3 ++-
 rules/linux/defense_evasion_ld_so_creation.toml              | 3 ++-
 rules/linux/defense_evasion_log_files_deleted.toml           | 3 ++-
 rules/linux/defense_evasion_mount_execution.toml             | 3 ++-
 rules/linux/defense_evasion_potential_proot_exploits.toml    | 3 ++-
 .../linux/defense_evasion_prctl_process_name_tampering.toml  | 1 +
 rules/linux/defense_evasion_rename_esxi_files.toml           | 3 ++-
 rules/linux/defense_evasion_rename_esxi_index_file.toml      | 3 ++-
 .../linux/defense_evasion_root_certificate_installation.toml | 3 ++-
 ...e_evasion_selinux_configuration_creation_or_renaming.toml | 5 +++--
 rules/linux/defense_evasion_ssl_certificate_deletion.toml    | 3 ++-
 ...ense_evasion_sus_utility_executed_via_tmux_or_screen.toml | 3 ++-
 rules/linux/defense_evasion_unusual_preload_env_vars.toml    | 3 ++-
 rules/linux/discovery_dynamic_linker_via_od.toml             | 3 ++-
 rules/linux/discovery_esxi_software_via_find.toml            | 3 ++-
 rules/linux/discovery_esxi_software_via_grep.toml            | 3 ++-
 rules/linux/discovery_kernel_module_enumeration.toml         | 3 ++-
 rules/linux/discovery_linux_hping_activity.toml              | 3 ++-
 rules/linux/discovery_linux_nping_activity.toml              | 3 ++-
 rules/linux/discovery_pam_version_discovery.toml             | 3 ++-
 rules/linux/discovery_ping_sweep_detected.toml               | 3 ++-
 .../discovery_private_key_password_searching_activity.toml   | 5 +++--
 rules/linux/discovery_proc_maps_read.toml                    | 3 ++-
 rules/linux/discovery_process_capabilities.toml              | 3 ++-
 rules/linux/discovery_pspy_process_monitoring_detected.toml  | 3 ++-
 .../discovery_security_file_access_via_common_utility.toml   | 5 +++--
 rules/linux/discovery_sudo_allowed_command_enumeration.toml  | 3 ++-
 rules/linux/discovery_suid_sguid_enumeration.toml            | 3 ++-
 rules/linux/discovery_suspicious_memory_grep_activity.toml   | 3 ++-
 .../linux/discovery_suspicious_which_command_execution.toml  | 3 ++-
 rules/linux/discovery_unusual_user_enumeration_via_id.toml   | 3 ++-
 rules/linux/discovery_virtual_machine_fingerprinting.toml    | 3 ++-
 rules/linux/discovery_yum_dnf_plugin_detection.toml          | 3 ++-
 rules/linux/execution_cupsd_foomatic_rip_file_creation.toml  | 3 ++-
 .../execution_cupsd_foomatic_rip_lp_user_execution.toml      | 3 ++-
 .../linux/execution_cupsd_foomatic_rip_shell_execution.toml  | 3 ++-
 ...cution_cupsd_foomatic_rip_suspicious_child_execution.toml | 3 ++-
 rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml | 3 ++-
 ...ution_egress_connection_from_entrypoint_in_container.toml | 3 ++-
 .../linux/execution_file_execution_followed_by_deletion.toml | 3 ++-
 rules/linux/execution_interpreter_tty_upgrade.toml           | 3 ++-
 rules/linux/execution_nc_listener_via_rlwrap.toml            | 3 ++-
 rules/linux/execution_netcon_from_rwx_mem_region_binary.toml | 3 ++-
 rules/linux/execution_network_event_post_compilation.toml    | 3 ++-
 rules/linux/execution_perl_tty_shell.toml                    | 3 ++-
 rules/linux/execution_potential_hack_tool_executed.toml      | 3 ++-
 ...ion_potentially_overly_permissive_container_creation.toml | 3 ++-
 .../execution_process_started_from_process_id_file.toml      | 3 ++-
 ...execution_process_started_in_shared_memory_directory.toml | 3 ++-
 rules/linux/execution_python_tty_shell.toml                  | 3 ++-
 rules/linux/execution_python_webserver_spawned.toml          | 3 ++-
 .../execution_remote_code_execution_via_postgresql.toml      | 3 ++-
 rules/linux/execution_shell_evasion_linux_binary.toml        | 3 ++-
 rules/linux/execution_shell_openssl_client_or_server.toml    | 5 +++--
 rules/linux/execution_shell_via_background_process.toml      | 3 ++-
 rules/linux/execution_shell_via_child_tcp_utility_linux.toml | 3 ++-
 rules/linux/execution_shell_via_java_revshell_linux.toml     | 3 ++-
 .../linux/execution_shell_via_lolbin_interpreter_linux.toml  | 3 ++-
 rules/linux/execution_shell_via_meterpreter_linux.toml       | 3 ++-
 rules/linux/execution_shell_via_suspicious_binary.toml       | 3 ++-
 rules/linux/execution_shell_via_tcp_cli_utility_linux.toml   | 3 ++-
 rules/linux/execution_shell_via_udp_cli_utility_linux.toml   | 3 ++-
 ...xecution_sus_extraction_or_decrompression_via_funzip.toml | 3 ++-
 ...cution_suspicious_executable_running_system_commands.toml | 3 ++-
 .../execution_suspicious_mining_process_creation_events.toml | 3 ++-
 rules/linux/execution_tc_bpf_filter.toml                     | 3 ++-
 rules/linux/execution_unix_socket_communication.toml         | 3 ++-
 .../execution_unknown_rwx_mem_region_binary_executed.toml    | 3 ++-
 ...filtration_potential_data_splitting_for_exfiltration.toml | 5 +++--
 rules/linux/impact_data_encrypted_via_openssl.toml           | 3 ++-
 rules/linux/impact_esxi_process_kill.toml                    | 3 ++-
 rules/linux/impact_memory_swap_modification.toml             | 3 ++-
 .../impact_potential_linux_ransomware_note_detected.toml     | 3 ++-
 rules/linux/lateral_movement_ssh_it_worm_download.toml       | 3 ++-
 .../lateral_movement_telnet_network_activity_external.toml   | 3 ++-
 .../lateral_movement_telnet_network_activity_internal.toml   | 3 ++-
 rules/linux/persistence_apt_package_manager_execution.toml   | 3 ++-
 .../linux/persistence_apt_package_manager_file_creation.toml | 3 ++-
 rules/linux/persistence_apt_package_manager_netcon.toml      | 3 ++-
 rules/linux/persistence_at_job_creation.toml                 | 3 ++-
 rules/linux/persistence_chkconfig_service_add.toml           | 3 ++-
 .../persistence_credential_access_modify_ssh_binaries.toml   | 3 ++-
 rules/linux/persistence_cron_job_creation.toml               | 3 ++-
 ...persistence_dnf_package_manager_plugin_file_creation.toml | 3 ++-
 ...stence_dpkg_package_installation_from_unusual_parent.toml | 3 ++-
 rules/linux/persistence_dpkg_unusual_execution.toml          | 5 +++--
 rules/linux/persistence_dynamic_linker_backup.toml           | 3 ++-
 rules/linux/persistence_etc_file_creation.toml               | 3 ++-
 rules/linux/persistence_git_hook_execution.toml              | 3 ++-
 rules/linux/persistence_git_hook_file_creation.toml          | 3 ++-
 rules/linux/persistence_git_hook_netcon.toml                 | 3 ++-
 rules/linux/persistence_git_hook_process_execution.toml      | 3 ++-
 rules/linux/persistence_insmod_kernel_module_load.toml       | 3 ++-
 rules/linux/persistence_kde_autostart_modification.toml      | 3 ++-
 rules/linux/persistence_kernel_driver_load.toml              | 3 ++-
 rules/linux/persistence_kernel_driver_load_by_non_root.toml  | 3 ++-
 rules/linux/persistence_kernel_object_file_creation.toml     | 3 ++-
 rules/linux/persistence_kworker_file_creation.toml           | 3 ++-
 rules/linux/persistence_lkm_configuration_file_creation.toml | 3 ++-
 ...persistence_pluggable_authentication_module_creation.toml | 3 ++-
 ...ggable_authentication_module_creation_in_unusual_dir.toml | 3 ++-
 ...ence_pluggable_authentication_module_source_download.toml | 3 ++-
 ...ence_potential_persistence_script_executable_bit_set.toml | 3 ++-
 .../linux/persistence_process_capability_set_via_setcap.toml | 5 +++--
 rules/linux/persistence_rc_local_error_via_syslog.toml       | 4 ++--
 .../linux/persistence_rc_local_service_already_running.toml  | 3 ++-
 ...istence_rpm_package_installation_from_unusual_parent.toml | 3 ++-
 rules/linux/persistence_setuid_setgid_capability_set.toml    | 3 ++-
 rules/linux/persistence_shadow_file_modification.toml        | 3 ++-
 rules/linux/persistence_shared_object_creation.toml          | 3 ++-
 .../linux/persistence_shell_configuration_modification.toml  | 3 ++-
 .../persistence_simple_web_server_connection_accepted.toml   | 3 ++-
 rules/linux/persistence_simple_web_server_creation.toml      | 3 ++-
 rules/linux/persistence_ssh_key_generation.toml              | 3 ++-
 rules/linux/persistence_ssh_netcon.toml                      | 5 +++--
 rules/linux/persistence_ssh_via_backdoored_system_user.toml  | 5 +++--
 .../persistence_suspicious_file_opened_through_editor.toml   | 3 ++-
 .../persistence_suspicious_ssh_execution_xzbackdoor.toml     | 3 ++-
 rules/linux/persistence_systemd_generator_creation.toml      | 3 ++-
 rules/linux/persistence_systemd_netcon.toml                  | 3 ++-
 rules/linux/persistence_systemd_service_creation.toml        | 3 ++-
 rules/linux/persistence_systemd_service_started.toml         | 3 ++-
 rules/linux/persistence_tainted_kernel_module_load.toml      | 3 ++-
 .../persistence_tainted_kernel_module_out_of_tree_load.toml  | 3 ++-
 rules/linux/persistence_udev_rule_creation.toml              | 3 ++-
 rules/linux/persistence_unusual_pam_grantor.toml             | 3 ++-
 rules/linux/persistence_unusual_sshd_child_process.toml      | 5 +++--
 .../persistence_user_or_group_creation_or_modification.toml  | 3 ++-
 rules/linux/persistence_xdg_autostart_netcon.toml            | 3 ++-
 ...persistence_yum_package_manager_plugin_file_creation.toml | 3 ++-
 ...vilege_escalation_chown_chmod_unauthorized_file_read.toml | 3 ++-
 ...privilege_escalation_container_util_misconfiguration.toml | 3 ++-
 rules/linux/privilege_escalation_dac_permissions.toml        | 3 ++-
 .../privilege_escalation_docker_escape_via_nsenter.toml      | 3 ++-
 ...lege_escalation_docker_mount_chroot_container_escape.toml | 3 ++-
 .../privilege_escalation_enlightenment_window_manager.toml   | 3 ++-
 .../linux/privilege_escalation_gdb_sys_ptrace_elevation.toml | 3 ++-
 rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml  | 3 ++-
 rules/linux/privilege_escalation_kworker_uid_elevation.toml  | 3 ++-
 .../privilege_escalation_ld_preload_shared_object_modif.toml | 3 ++-
 .../privilege_escalation_linux_suspicious_symbolic_link.toml | 3 ++-
 rules/linux/privilege_escalation_linux_uid_int_max_bug.toml  | 3 ++-
 ...ilege_escalation_load_and_unload_of_kernel_via_kexec.toml | 3 ++-
 .../privilege_escalation_looney_tunables_cve_2023_4911.toml  | 3 ++-
 rules/linux/privilege_escalation_netcon_via_sudo_binary.toml | 3 ++-
 .../linux/privilege_escalation_overlayfs_local_privesc.toml  | 3 ++-
 rules/linux/privilege_escalation_pkexec_envar_hijack.toml    | 3 ++-
 ...privilege_escalation_potential_bufferoverflow_attack.toml | 3 ++-
 ...rivilege_escalation_potential_suid_sgid_exploitation.toml | 3 ++-
 .../privilege_escalation_potential_wildcard_shell_spawn.toml | 3 ++-
 .../linux/privilege_escalation_sda_disk_mount_non_root.toml  | 3 ++-
 rules/linux/privilege_escalation_shadow_file_read.toml       | 3 ++-
 rules/linux/privilege_escalation_sudo_cve_2019_14287.toml    | 3 ++-
 rules/linux/privilege_escalation_sudo_hijacking.toml         | 3 ++-
 ...rivilege_escalation_sudo_token_via_process_injection.toml | 3 ++-
 ...ge_escalation_suspicious_cap_setuid_python_execution.toml | 3 ++-
 ...ivilege_escalation_suspicious_chown_fowner_elevation.toml | 3 ++-
 .../privilege_escalation_suspicious_passwd_file_write.toml   | 3 ++-
 .../privilege_escalation_suspicious_uid_guid_elevation.toml  | 3 ++-
 .../privilege_escalation_uid_change_post_compilation.toml    | 3 ++-
 ...ege_escalation_uid_elevation_from_unknown_executable.toml | 3 ++-
 .../privilege_escalation_unshare_namespace_manipulation.toml | 3 ++-
 rules/linux/privilege_escalation_writable_docker_socket.toml | 3 ++-
 rules/macos/credential_access_credentials_keychains.toml     | 3 ++-
 rules/macos/credential_access_dumping_hashes_bi_cmds.toml    | 3 ++-
 rules/macos/credential_access_dumping_keychain_security.toml | 3 ++-
 rules/macos/credential_access_high_volume_of_pbpaste.toml    | 3 ++-
 rules/macos/credential_access_kerberosdump_kcc.toml          | 3 ++-
 ...redential_access_keychain_pwd_retrieval_security_cmd.toml | 3 ++-
 rules/macos/credential_access_mitm_localhost_webproxy.toml   | 3 ++-
 .../credential_access_potential_macos_ssh_bruteforce.toml    | 3 ++-
 .../macos/credential_access_promt_for_pwd_via_osascript.toml | 3 ++-
 ..._access_suspicious_web_browser_sensitive_file_access.toml | 3 ++-
 rules/macos/credential_access_systemkey_dumping.toml         | 3 ++-
 .../defense_evasion_apple_softupdates_modification.toml      | 3 ++-
 .../macos/defense_evasion_attempt_del_quarantine_attrib.toml | 3 ++-
 .../macos/defense_evasion_attempt_to_disable_gatekeeper.toml | 3 ++-
 rules/macos/defense_evasion_install_root_certificate.toml    | 3 ++-
 .../macos/defense_evasion_modify_environment_launchctl.toml  | 3 ++-
 ...e_evasion_privacy_controls_tcc_database_modification.toml | 3 ++-
 ...rivilege_escalation_privacy_pref_sshd_fulldiskaccess.toml | 3 ++-
 rules/macos/defense_evasion_safari_config_change.toml        | 3 ++-
 ...nse_evasion_sandboxed_office_app_suspicious_zip_file.toml | 3 ++-
 .../defense_evasion_tcc_bypass_mounted_apfs_access.toml      | 3 ++-
 .../macos/defense_evasion_unload_endpointsecurity_kext.toml  | 3 ++-
 rules/macos/discovery_users_domain_built_in_commands.toml    | 3 ++-
 ...ution_defense_evasion_electron_app_childproc_node_js.toml | 3 ++-
 ...xecution_initial_access_suspicious_browser_childproc.toml | 3 ++-
 .../execution_installer_package_spawned_network_event.toml   | 3 ++-
 rules/macos/execution_script_via_automator_workflows.toml    | 3 ++-
 ...xecution_scripting_osascript_exec_followed_by_netcon.toml | 3 ++-
 .../macos/execution_shell_execution_via_apple_scripting.toml | 3 ++-
 ...nitial_access_suspicious_mac_ms_office_child_process.toml | 1 +
 ...l_movement_credential_access_kerberos_bifrostconsole.toml | 3 ++-
 rules/macos/lateral_movement_mounting_smb_share.toml         | 3 ++-
 rules/macos/lateral_movement_remote_ssh_login_enabled.toml   | 3 ++-
 rules/macos/lateral_movement_vpn_connection_attempt.toml     | 3 ++-
 rules/macos/persistence_account_creation_hide_at_logon.toml  | 3 ++-
 .../persistence_creation_change_launch_agents_file.toml      | 3 ++-
 .../persistence_creation_hidden_login_item_osascript.toml    | 3 ++-
 .../persistence_creation_modif_launch_deamon_sequence.toml   | 3 ++-
 ...ence_credential_access_authorization_plugin_creation.toml | 3 ++-
 rules/macos/persistence_crontab_creation.toml                | 3 ++-
 ...evasion_hidden_launch_agent_deamon_logonitem_process.toml | 3 ++-
 .../persistence_directory_services_plugins_modification.toml | 3 ++-
 .../persistence_docker_shortcuts_plist_modification.toml     | 3 ++-
 rules/macos/persistence_emond_rules_file_creation.toml       | 3 ++-
 rules/macos/persistence_emond_rules_process_execution.toml   | 3 ++-
 rules/macos/persistence_enable_root_account.toml             | 3 ++-
 ...sistence_evasion_hidden_launch_agent_deamon_creation.toml | 3 ++-
 rules/macos/persistence_finder_sync_plugin_pluginkit.toml    | 3 ++-
 rules/macos/persistence_folder_action_scripts_runtime.toml   | 3 ++-
 rules/macos/persistence_login_logout_hooks_defaults.toml     | 3 ++-
 rules/macos/persistence_loginwindow_plist_modification.toml  | 3 ++-
 ...ersistence_modification_sublime_app_plugin_or_script.toml | 3 ++-
 rules/macos/persistence_periodic_tasks_file_mdofiy.toml      | 3 ++-
 ...sistence_screensaver_engine_unexpected_child_process.toml | 3 ++-
 .../persistence_screensaver_plist_file_modification.toml     | 3 ++-
 .../macos/persistence_suspicious_calendar_modification.toml  | 3 ++-
 rules/macos/persistence_via_atom_init_file_modification.toml | 3 ++-
 .../privilege_escalation_applescript_with_admin_privs.toml   | 3 ++-
 .../privilege_escalation_explicit_creds_via_scripting.toml   | 3 ++-
 .../privilege_escalation_exploit_adobe_acrobat_updater.toml  | 3 ++-
 .../privilege_escalation_local_user_added_to_admin.toml      | 3 ++-
 rules/macos/privilege_escalation_root_crontab_filemod.toml   | 3 ++-
 .../privilege_escalation_user_added_to_admin_group.toml      | 3 ++-
 .../ml/command_and_control_ml_packetbeat_dns_tunneling.toml  | 3 ++-
 .../command_and_control_ml_packetbeat_rare_dns_question.toml | 3 ++-
 rules/ml/command_and_control_ml_packetbeat_rare_urls.toml    | 3 ++-
 .../command_and_control_ml_packetbeat_rare_user_agent.toml   | 3 ++-
 .../ml/credential_access_ml_auth_spike_in_logon_events.toml  | 3 ++-
 ...redential_access_ml_linux_anomalous_metadata_process.toml | 3 ++-
 .../credential_access_ml_linux_anomalous_metadata_user.toml  | 3 ++-
 rules/ml/credential_access_ml_suspicious_login_activity.toml | 3 ++-
 ...dential_access_ml_windows_anomalous_metadata_process.toml | 3 ++-
 ...credential_access_ml_windows_anomalous_metadata_user.toml | 3 ++-
 .../ml/discovery_ml_linux_system_information_discovery.toml  | 3 ++-
 ...very_ml_linux_system_network_configuration_discovery.toml | 3 ++-
 ...scovery_ml_linux_system_network_connection_discovery.toml | 3 ++-
 rules/ml/discovery_ml_linux_system_process_discovery.toml    | 3 ++-
 rules/ml/discovery_ml_linux_system_user_discovery.toml       | 3 ++-
 rules/ml/execution_ml_windows_anomalous_script.toml          | 3 ++-
 .../ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml | 3 ++-
 rules/ml/initial_access_ml_linux_anomalous_user_name.toml    | 3 ++-
 rules/ml/initial_access_ml_windows_anomalous_user_name.toml  | 3 ++-
 ...tial_access_ml_windows_rare_user_type10_remote_login.toml | 3 ++-
 rules/ml/ml_high_count_network_denies.toml                   | 4 ++--
 rules/ml/ml_high_count_network_events.toml                   | 4 ++--
 rules/ml/ml_linux_anomalous_network_activity.toml            | 3 ++-
 rules/ml/ml_linux_anomalous_network_port_activity.toml       | 3 ++-
 rules/ml/ml_packetbeat_rare_server_domain.toml               | 4 ++--
 rules/ml/ml_rare_destination_country.toml                    | 4 ++--
 rules/ml/ml_spike_in_traffic_to_a_country.toml               | 4 ++--
 rules/ml/ml_windows_anomalous_network_activity.toml          | 3 ++-
 rules/ml/persistence_ml_rare_process_by_host_linux.toml      | 3 ++-
 rules/ml/persistence_ml_windows_anomalous_path_activity.toml | 3 ++-
 .../persistence_ml_windows_anomalous_process_all_hosts.toml  | 3 ++-
 rules/ml/persistence_ml_windows_anomalous_service.toml       | 3 ++-
 ...rivilege_escalation_ml_linux_anomalous_sudo_activity.toml | 3 ++-
 ...rivilege_escalation_ml_windows_rare_user_runas_event.toml | 3 ++-
 ...rce_development_ml_linux_anomalous_compiler_activity.toml | 3 ++-
 ..._and_control_accepted_default_telnet_port_connection.toml | 5 +++--
 rules/network/command_and_control_cobalt_strike_beacon.toml  | 4 ++--
 ...nd_and_control_cobalt_strike_default_teamserver_cert.toml | 3 ++-
 ...nd_and_control_download_rar_powershell_from_internet.toml | 4 ++--
 rules/network/command_and_control_fin7_c2_behavior.toml      | 4 ++--
 rules/network/command_and_control_halfbaked_beacon.toml      | 4 ++--
 .../command_and_control_nat_traversal_port_activity.toml     | 4 ++--
 rules/network/command_and_control_port_26_activity.toml      | 4 ++--
 ...ontrol_rdp_remote_desktop_protocol_from_the_internet.toml | 4 ++--
 ...trol_vnc_virtual_network_computing_from_the_internet.toml | 4 ++--
 ...ontrol_vnc_virtual_network_computing_to_the_internet.toml | 4 ++--
 .../network/discovery_potential_network_sweep_detected.toml  | 5 +++--
 rules/network/discovery_potential_port_scan_detected.toml    | 5 +++--
 .../network/discovery_potential_syn_port_scan_detected.toml  | 3 ++-
 ...l_access_rpc_remote_procedure_call_from_the_internet.toml | 4 ++--
 ...ial_access_rpc_remote_procedure_call_to_the_internet.toml | 4 ++--
 ...ss_smb_windows_file_sharing_activity_to_the_internet.toml | 4 ++--
 .../network/initial_access_unsecure_elasticsearch_node.toml  | 4 ++--
 .../credential_access_endgame_cred_dumping_detected.toml     | 4 ++--
 .../credential_access_endgame_cred_dumping_prevented.toml    | 4 ++--
 rules/promotions/endgame_adversary_behavior_detected.toml    | 4 ++--
 rules/promotions/endgame_malware_detected.toml               | 4 ++--
 rules/promotions/endgame_malware_prevented.toml              | 4 ++--
 rules/promotions/endgame_ransomware_detected.toml            | 4 ++--
 rules/promotions/endgame_ransomware_prevented.toml           | 4 ++--
 rules/promotions/execution_endgame_exploit_detected.toml     | 3 ++-
 rules/promotions/execution_endgame_exploit_prevented.toml    | 3 ++-
 rules/promotions/external_alerts.toml                        | 4 ++--
 ...vilege_escalation_endgame_cred_manipulation_detected.toml | 4 ++--
 ...ilege_escalation_endgame_cred_manipulation_prevented.toml | 4 ++--
 ...ivilege_escalation_endgame_permission_theft_detected.toml | 4 ++--
 ...vilege_escalation_endgame_permission_theft_prevented.toml | 4 ++--
 ...vilege_escalation_endgame_process_injection_detected.toml | 4 ++--
 ...ilege_escalation_endgame_process_injection_prevented.toml | 4 ++--
 rules/threat_intel/threat_intel_indicator_match_address.toml | 4 ++--
 rules/threat_intel/threat_intel_indicator_match_hash.toml    | 4 ++--
 .../threat_intel/threat_intel_indicator_match_registry.toml  | 4 ++--
 rules/threat_intel/threat_intel_indicator_match_url.toml     | 4 ++--
 rules/windows/collection_email_outlook_mailbox_via_com.toml  | 3 ++-
 rules/windows/collection_posh_webcam_video_capture.toml      | 3 ++-
 rules/windows/command_and_control_certreq_postdata.toml      | 3 ++-
 .../command_and_control_encrypted_channel_freesslcert.toml   | 3 ++-
 rules/windows/command_and_control_iexplore_via_com.toml      | 3 ++-
 rules/windows/command_and_control_ingress_transfer_bits.toml | 3 ++-
 rules/windows/command_and_control_outlook_home_page.toml     | 3 ++-
 rules/windows/command_and_control_tunnel_vscode.toml         | 3 ++-
 rules/windows/credential_access_adidns_wildcard.toml         | 3 ++-
 rules/windows/credential_access_adidns_wpad_record.toml      | 3 ++-
 .../credential_access_copy_ntds_sam_volshadowcp_cmdline.toml | 3 ++-
 rules/windows/credential_access_dcsync_user_backdoor.toml    | 4 ++--
 rules/windows/credential_access_dnsnode_creation.toml        | 3 ++-
 rules/windows/credential_access_dollar_account_relay.toml    | 3 ++-
 .../credential_access_domain_backup_dpapi_private_keys.toml  | 4 ++--
 rules/windows/credential_access_generic_localdumps.toml      | 3 ++-
 .../credential_access_iis_connectionstrings_dumping.toml     | 3 ++-
 .../credential_access_imageload_azureadconnectauthsvc.toml   | 4 ++--
 rules/windows/credential_access_kirbi_file.toml              | 4 ++--
 rules/windows/credential_access_ldap_attributes.toml         | 3 ++-
 .../credential_access_lsass_handle_via_malseclogon.toml      | 3 ++-
 rules/windows/credential_access_lsass_loaded_susp_dll.toml   | 3 ++-
 rules/windows/credential_access_lsass_openprocess_api.toml   | 5 +++--
 ...cess_persistence_network_logon_provider_modification.toml | 3 ++-
 rules/windows/credential_access_posh_kerb_ticket_dump.toml   | 3 ++-
 rules/windows/credential_access_posh_veeam_sql.toml          | 3 ++-
 ...edential_access_potential_lsa_memdump_via_mirrordump.toml | 3 ++-
 .../credential_access_relay_ntlm_auth_via_http_spoolss.toml  | 3 ++-
 .../windows/credential_access_saved_creds_vault_winlog.toml  | 4 ++--
 rules/windows/credential_access_saved_creds_vaultcmd.toml    | 3 ++-
 .../credential_access_suspicious_comsvcs_imageload.toml      | 3 ++-
 .../credential_access_suspicious_lsass_access_generic.toml   | 3 ++-
 .../credential_access_suspicious_lsass_access_memdump.toml   | 3 ++-
 ...edential_access_suspicious_lsass_access_via_snapshot.toml | 3 ++-
 .../credential_access_veeam_backup_dll_imageload.toml        | 3 ++-
 rules/windows/credential_access_veeam_commands.toml          | 3 ++-
 .../credential_access_via_snapshot_lsass_clone_creation.toml | 3 ++-
 rules/windows/credential_access_wbadmin_ntds.toml            | 3 ++-
 rules/windows/defense_evasion_cve_2020_0601.toml             | 3 ++-
 rules/windows/defense_evasion_disable_nla.toml               | 3 ++-
 rules/windows/defense_evasion_dns_over_https_enabled.toml    | 3 ++-
 .../defense_evasion_dotnet_compiler_parent_process.toml      | 3 ++-
 ...ense_evasion_execution_control_panel_suspicious_args.toml | 3 ++-
 rules/windows/defense_evasion_execution_lolbas_wuauclt.toml  | 3 ++-
 .../defense_evasion_execution_msbuild_started_by_script.toml | 3 ++-
 ..._evasion_execution_msbuild_started_by_system_process.toml | 3 ++-
 ...nse_evasion_execution_msbuild_started_unusal_process.toml | 3 ++-
 ...efense_evasion_execution_suspicious_explorer_winword.toml | 3 ++-
 .../defense_evasion_execution_windefend_unusual_path.toml    | 3 ++-
 .../defense_evasion_file_creation_mult_extension.toml        | 3 ++-
 rules/windows/defense_evasion_from_unusual_directory.toml    | 3 ++-
 .../defense_evasion_hide_encoded_executable_registry.toml    | 4 ++--
 rules/windows/defense_evasion_injection_msbuild.toml         | 3 ++-
 rules/windows/defense_evasion_installutil_beacon.toml        | 3 ++-
 rules/windows/defense_evasion_lolbas_win_cdb_utility.toml    | 5 +++--
 ...nse_evasion_masquerading_as_elastic_endpoint_process.toml | 3 ++-
 ...defense_evasion_masquerading_business_apps_installer.toml | 3 ++-
 .../defense_evasion_masquerading_communication_apps.toml     | 3 ++-
 ...e_evasion_masquerading_suspicious_werfault_childproc.toml | 3 ++-
 .../defense_evasion_masquerading_trusted_directory.toml      | 3 ++-
 rules/windows/defense_evasion_mshta_beacon.toml              | 3 ++-
 rules/windows/defense_evasion_msiexec_child_proc_netcon.toml | 3 ++-
 rules/windows/defense_evasion_msxsl_network.toml             | 3 ++-
 .../windows/defense_evasion_parent_process_pid_spoofing.toml | 3 ++-
 ...efense_evasion_persistence_account_tokenfilterpolicy.toml | 5 +++--
 rules/windows/defense_evasion_posh_obfuscation.toml          | 4 ++--
 rules/windows/defense_evasion_proxy_execution_via_msdt.toml  | 3 ++-
 ...fense_evasion_reg_disable_enableglobalqueryblocklist.toml | 3 ++-
 rules/windows/defense_evasion_root_dir_ads_creation.toml     | 3 ++-
 rules/windows/defense_evasion_rundll32_no_arguments.toml     | 3 ++-
 rules/windows/defense_evasion_sccm_scnotification_dll.toml   | 3 ++-
 .../defense_evasion_scheduledjobs_at_protocol_enabled.toml   | 3 ++-
 rules/windows/defense_evasion_script_via_html_app.toml       | 5 +++--
 rules/windows/defense_evasion_sip_provider_mod.toml          | 3 ++-
 ...on_solarwinds_backdoor_service_disabled_via_registry.toml | 3 ++-
 ...nse_evasion_suspicious_execution_from_mounted_device.toml | 3 ++-
 .../defense_evasion_suspicious_managedcode_host_process.toml | 3 ++-
 rules/windows/defense_evasion_suspicious_scrobj_load.toml    | 3 ++-
 rules/windows/defense_evasion_suspicious_wmi_script.toml     | 3 ++-
 rules/windows/defense_evasion_timestomp_sysmon.toml          | 3 ++-
 .../defense_evasion_unsigned_dll_loaded_from_suspdir.toml    | 3 ++-
 rules/windows/defense_evasion_unusual_dir_ads.toml           | 3 ++-
 ...fense_evasion_unusual_network_connection_via_dllhost.toml | 3 ++-
 .../defense_evasion_unusual_system_vp_child_program.toml     | 3 ++-
 .../windows/defense_evasion_windows_filtering_platform.toml  | 3 ++-
 rules/windows/defense_evasion_wsl_bash_exec.toml             | 3 ++-
 rules/windows/defense_evasion_wsl_child_process.toml         | 3 ++-
 rules/windows/defense_evasion_wsl_enabled_via_dism.toml      | 3 ++-
 rules/windows/defense_evasion_wsl_filesystem.toml            | 3 ++-
 rules/windows/defense_evasion_wsl_kalilinux.toml             | 3 ++-
 rules/windows/defense_evasion_wsl_registry_modification.toml | 3 ++-
 rules/windows/discovery_active_directory_webservice.toml     | 3 ++-
 rules/windows/discovery_group_policy_object_discovery.toml   | 3 ++-
 rules/windows/discovery_high_number_ad_properties.toml       | 3 ++-
 ...scovery_signal_unusual_discovery_signal_proc_cmdline.toml | 3 ++-
 ...very_signal_unusual_discovery_signal_proc_executable.toml | 3 ++-
 ...ecution_apt_solarwinds_backdoor_child_cmd_powershell.toml | 3 ++-
 ...tion_apt_solarwinds_backdoor_unusual_child_processes.toml | 3 ++-
 rules/windows/execution_com_object_xwizard.toml              | 3 ++-
 .../execution_command_shell_started_by_unusual_process.toml  | 4 ++--
 rules/windows/execution_command_shell_via_rundll32.toml      | 3 ++-
 .../windows/execution_delayed_via_ping_lolbas_unsigned.toml  | 3 ++-
 rules/windows/execution_downloaded_shortcut_files.toml       | 3 ++-
 rules/windows/execution_downloaded_url_file.toml             | 5 +++--
 rules/windows/execution_enumeration_via_wmiprvse.toml        | 3 ++-
 rules/windows/execution_initial_access_foxmail_exploit.toml  | 5 +++--
 rules/windows/execution_initial_access_wps_dll_exploit.toml  | 5 +++--
 rules/windows/execution_mofcomp.toml                         | 3 ++-
 rules/windows/execution_posh_hacktool_authors.toml           | 3 ++-
 rules/windows/execution_posh_hacktool_functions.toml         | 4 ++--
 .../execution_powershell_susp_args_via_winscript.toml        | 5 +++--
 .../windows/execution_scheduled_task_powershell_source.toml  | 3 ++-
 rules/windows/execution_shared_modules_local_sxs_dll.toml    | 3 ++-
 rules/windows/execution_suspicious_cmd_wmi.toml              | 3 ++-
 .../execution_suspicious_image_load_wmi_ms_office.toml       | 3 ++-
 .../windows/execution_via_mmc_console_file_unusual_path.toml | 3 ++-
 rules/windows/execution_windows_cmd_shell_susp_args.toml     | 5 +++--
 rules/windows/execution_windows_powershell_susp_args.toml    | 5 +++--
 rules/windows/exfiltration_smb_rare_destination.toml         | 3 ++-
 .../initial_access_evasion_suspicious_htm_file_creation.toml | 3 ++-
 rules/windows/initial_access_execution_from_inetcache.toml   | 3 ++-
 .../initial_access_execution_from_removable_media.toml       | 3 ++-
 .../windows/initial_access_execution_remote_via_msiexec.toml | 3 ++-
 .../windows/initial_access_execution_via_office_addins.toml  | 3 ++-
 .../initial_access_exfiltration_first_time_seen_usb.toml     | 3 ++-
 rules/windows/initial_access_exploit_jetbrains_teamcity.toml | 3 ++-
 rules/windows/initial_access_rdp_file_mail_attachment.toml   | 3 ++-
 .../initial_access_scripts_process_started_via_wmi.toml      | 3 ++-
 .../windows/initial_access_suspicious_ms_exchange_files.toml | 3 ++-
 .../initial_access_suspicious_ms_exchange_process.toml       | 3 ++-
 ...l_access_suspicious_ms_exchange_worker_child_process.toml | 3 ++-
 ...ial_access_via_explorer_suspicious_child_parent_args.toml | 3 ++-
 .../initial_access_webshell_screenconnect_server.toml        | 3 ++-
 .../windows/initial_access_xsl_script_execution_via_com.toml | 3 ++-
 rules/windows/lateral_movement_alternate_creds_pth.toml      | 4 ++--
 rules/windows/lateral_movement_cmd_service.toml              | 3 ++-
 rules/windows/lateral_movement_dcom_hta.toml                 | 3 ++-
 rules/windows/lateral_movement_dcom_mmc20.toml               | 3 ++-
 ...lateral_movement_dcom_shellwindow_shellbrowserwindow.toml | 3 ++-
 ..._defense_evasion_lanman_nullsessionpipe_modification.toml | 3 ++-
 rules/windows/lateral_movement_evasion_rdp_shadowing.toml    | 3 ++-
 .../lateral_movement_execution_from_tsclient_mup.toml        | 3 ++-
 .../lateral_movement_incoming_winrm_shell_execution.toml     | 3 ++-
 rules/windows/lateral_movement_incoming_wmi.toml             | 3 ++-
 .../lateral_movement_mount_hidden_or_webdav_share_net.toml   | 3 ++-
 .../windows/lateral_movement_powershell_remoting_target.toml | 3 ++-
 rules/windows/lateral_movement_rdp_sharprdp_target.toml      | 3 ++-
 .../lateral_movement_remote_file_copy_hidden_share.toml      | 3 ++-
 .../lateral_movement_remote_service_installed_winlog.toml    | 3 ++-
 .../lateral_movement_remote_task_creation_winlog.toml        | 4 ++--
 .../lateral_movement_suspicious_rdp_client_imageload.toml    | 3 ++-
 .../lateral_movement_unusual_dns_service_file_writes.toml    | 3 ++-
 .../windows/lateral_movement_via_startup_folder_rdp_smb.toml | 3 ++-
 rules/windows/lateral_movement_via_wsus_update.toml          | 3 ++-
 rules/windows/persistence_ad_adminsdholder.toml              | 3 ++-
 rules/windows/persistence_app_compat_shim.toml               | 3 ++-
 rules/windows/persistence_appcertdlls_registry.toml          | 4 ++--
 rules/windows/persistence_browser_extension_install.toml     | 3 ++-
 .../windows/persistence_evasion_registry_ifeo_injection.toml | 3 ++-
 rules/windows/persistence_group_modification_by_system.toml  | 3 ++-
 rules/windows/persistence_local_scheduled_job_creation.toml  | 4 ++--
 rules/windows/persistence_local_scheduled_task_creation.toml | 3 ++-
 .../windows/persistence_local_scheduled_task_scripting.toml  | 3 ++-
 rules/windows/persistence_ms_office_addins_file.toml         | 3 ++-
 rules/windows/persistence_ms_outlook_vba_template.toml       | 3 ++-
 rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml | 3 ++-
 rules/windows/persistence_msi_installer_task_startup.toml    | 3 ++-
 rules/windows/persistence_msoffice_startup_registry.toml     | 3 ++-
 rules/windows/persistence_netsh_helper_dll.toml              | 3 ++-
 ...stence_powershell_exch_mailbox_activesync_add_device.toml | 3 ++-
 rules/windows/persistence_powershell_profiles.toml           | 3 ++-
 rules/windows/persistence_registry_uncommon.toml             | 3 ++-
 rules/windows/persistence_remote_password_reset.toml         | 3 ++-
 .../persistence_runtime_run_key_startup_susp_procs.toml      | 3 ++-
 .../windows/persistence_scheduled_task_creation_winlog.toml  | 4 ++--
 rules/windows/persistence_scheduled_task_updated.toml        | 4 ++--
 rules/windows/persistence_service_dll_unsigned.toml          | 3 ++-
 rules/windows/persistence_services_registry.toml             | 3 ++-
 ...tence_suspicious_image_load_scheduled_task_ms_office.toml | 3 ++-
 .../persistence_suspicious_scheduled_task_runtime.toml       | 3 ++-
 .../persistence_suspicious_service_created_registry.toml     | 3 ++-
 rules/windows/persistence_sysmon_wmi_event_subscription.toml | 5 +++--
 rules/windows/persistence_temp_scheduled_task.toml           | 3 ++-
 rules/windows/persistence_time_provider_mod.toml             | 3 ++-
 .../persistence_user_account_creation_event_logs.toml        | 4 ++--
 rules/windows/persistence_via_application_shimming.toml      | 3 ++-
 rules/windows/persistence_via_bits_job_notify_command.toml   | 4 ++--
 rules/windows/persistence_via_hidden_run_key_valuename.toml  | 3 ++-
 ...rsistence_via_lsa_security_support_provider_registry.toml | 3 ++-
 ...istence_via_telemetrycontroller_scheduledtask_hijack.toml | 3 ++-
 ...indows_management_instrumentation_event_subscription.toml | 3 ++-
 .../windows/persistence_via_wmi_stdregprov_run_services.toml | 3 ++-
 rules/windows/persistence_werfault_reflectdebugger.toml      | 3 ++-
 ...rivilege_escalation_create_process_as_different_user.toml | 4 ++--
 ...rivilege_escalation_create_process_with_token_unpriv.toml | 3 ++-
 rules/windows/privilege_escalation_credroaming_ldap.toml     | 3 ++-
 .../privilege_escalation_dns_serverlevelplugindll.toml       | 5 +++--
 .../windows/privilege_escalation_expired_driver_loaded.toml  | 3 ++-
 .../windows/privilege_escalation_exploit_cve_202238028.toml  | 3 ++-
 .../privilege_escalation_gpo_schtask_service_creation.toml   | 3 ++-
 .../privilege_escalation_krbrelayup_service_creation.toml    | 3 ++-
 rules/windows/privilege_escalation_lsa_auth_package.toml     | 3 ++-
 rules/windows/privilege_escalation_make_token_local.toml     | 4 ++--
 .../privilege_escalation_msi_repair_via_mshelp_link.toml     | 5 +++--
 .../privilege_escalation_newcreds_logon_rare_process.toml    | 4 ++--
 ...ivilege_escalation_port_monitor_print_pocessor_abuse.toml | 3 ++-
 .../privilege_escalation_posh_token_impersonation.toml       | 3 ++-
 ...privilege_escalation_printspooler_registry_copyfiles.toml | 3 ++-
 ...lege_escalation_printspooler_service_suspicious_file.toml | 3 ++-
 ...ege_escalation_printspooler_suspicious_file_deletion.toml | 3 ++-
 .../privilege_escalation_reg_service_imagepath_mod.toml      | 5 +++--
 .../privilege_escalation_rogue_windir_environment_var.toml   | 3 ++-
 .../privilege_escalation_samaccountname_spoofing_attack.toml | 3 ++-
 .../privilege_escalation_suspicious_dnshostname_update.toml  | 3 ++-
 .../privilege_escalation_tokenmanip_sedebugpriv_enabled.toml | 4 ++--
 .../windows/privilege_escalation_uac_bypass_com_clipup.toml  | 3 ++-
 .../privilege_escalation_uac_bypass_com_ieinstal.toml        | 3 ++-
 ...ilege_escalation_uac_bypass_com_interface_icmluautil.toml | 3 ++-
 .../privilege_escalation_uac_bypass_diskcleanup_hijack.toml  | 3 ++-
 .../privilege_escalation_uac_bypass_dll_sideloading.toml     | 3 ++-
 .../windows/privilege_escalation_unquoted_service_path.toml  | 3 ++-
 ...ivilege_escalation_unusual_printspooler_childprocess.toml | 3 ++-
 ...ilege_escalation_unusual_svchost_childproc_childless.toml | 3 ++-
 rules/windows/privilege_escalation_via_ppid_spoofing.toml    | 3 ++-
 rules/windows/privilege_escalation_via_rogue_named_pipe.toml | 3 ++-
 rules/windows/privilege_escalation_via_token_theft.toml      | 3 ++-
 ...vilege_escalation_windows_service_via_unusual_client.toml | 3 ++-
 rules/windows/privilege_escalation_wpad_exploitation.toml    | 4 ++--
 898 files changed, 1825 insertions(+), 1114 deletions(-)

diff --git a/rules/apm/apm_403_response_to_a_post.toml b/rules/apm/apm_403_response_to_a_post.toml
index c21235b9c67..ef503e3741b 100644
--- a/rules/apm/apm_403_response_to_a_post.toml
+++ b/rules/apm/apm_403_response_to_a_post.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ references = ["https://en.wikipedia.org/wiki/HTTP_403"]
 risk_score = 47
 rule_id = "a87a4e42-1d82-44bd-b0bf-d9b7f91fb89e"
 severity = "medium"
-tags = ["Data Source: APM"]
+tags = ["Data Source: APM", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/apm/apm_405_response_method_not_allowed.toml b/rules/apm/apm_405_response_method_not_allowed.toml
index 2b0531b4cf5..1116968ca65 100644
--- a/rules/apm/apm_405_response_method_not_allowed.toml
+++ b/rules/apm/apm_405_response_method_not_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ references = ["https://en.wikipedia.org/wiki/HTTP_405"]
 risk_score = 47
 rule_id = "75ee75d8-c180-481c-ba88-ee50129a6aef"
 severity = "medium"
-tags = ["Data Source: APM"]
+tags = ["Data Source: APM", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/apm/apm_sqlmap_user_agent.toml b/rules/apm/apm_sqlmap_user_agent.toml
index d7df695e4b1..82c01caadac 100644
--- a/rules/apm/apm_sqlmap_user_agent.toml
+++ b/rules/apm/apm_sqlmap_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["apm"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ references = ["http://sqlmap.org/"]
 risk_score = 47
 rule_id = "d49cc73f-7a16-4def-89ce-9fc7127d7820"
 severity = "medium"
-tags = ["Data Source: APM"]
+tags = ["Data Source: APM", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
index 91ea2c326c7..a8ecc952be6 100644
--- a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
+++ b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/19"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
index 32c2e8675cf..1e9ce7b1ce9 100644
--- a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
+++ b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,7 @@ tags = [
     "Tactic: Command and Control",
     "OS: macOS",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
index c5d988e17e5..6b8952afb60 100644
--- a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
+++ b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows"]
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/credential_access_forced_authentication_pipes.toml b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
index 59fa4f114ab..16098a08abf 100644
--- a/rules/cross-platform/credential_access_forced_authentication_pipes.toml
+++ b/rules/cross-platform/credential_access_forced_authentication_pipes.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/23"
 integration = ["endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Data Source: Active Directory",
     "Use Case: Active Directory Monitoring",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
index 9a3eb7ec064..686ff34eb3c 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ name = "Agent Spoofing - Mismatched Agent ID"
 risk_score = 73
 rule_id = "3115bd2c-0baa-4df0-80ea-45e474b5ef93"
 severity = "high"
-tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion"]
+tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
index d2e1562a6df..bc36a10c5d2 100644
--- a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
+++ b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/14"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ name = "Agent Spoofing - Multiple Hosts Using Same Agent"
 risk_score = 73
 rule_id = "493834ca-f861-414c-8602-150d5505b777"
 severity = "high"
-tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion"]
+tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
index 4a80ba4d0cb..97e4f3921b8 100644
--- a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
+++ b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
index 570e2dea978..83b1df1f74d 100644
--- a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
+++ b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
index 0a089ceb732..95d258f1044 100644
--- a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
+++ b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
index 8529965fcb0..bb8a738a580 100644
--- a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
+++ b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
index 4b6293e130b..6e202e9912d 100644
--- a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
+++ b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/defense_evasion_timestomp_touch.toml b/rules/cross-platform/defense_evasion_timestomp_touch.toml
index 7462af984a2..c2e470ee110 100644
--- a/rules/cross-platform/defense_evasion_timestomp_touch.toml
+++ b/rules/cross-platform/defense_evasion_timestomp_touch.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
index 8c96dc20d6a..c6e250f6b81 100644
--- a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
+++ b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
index 025b66c7fa2..bc38184ca9b 100644
--- a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
+++ b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/03"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,7 +67,8 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
-    "Data Source: Auditd Manager"
+    "Data Source: Auditd Manager",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
index d1dc608f1c6..2ca3b54b6f9 100644
--- a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
+++ b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -23,6 +23,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/cross-platform/execution_potential_widespread_malware_infection.toml b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
index ddf387f16bb..74210517ab1 100644
--- a/rules/cross-platform/execution_potential_widespread_malware_infection.toml
+++ b/rules/cross-platform/execution_potential_widespread_malware_infection.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/08"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
 
@@ -26,7 +26,8 @@ tags = [
     "Data Source: Elastic Defend",
     "Use Case: Threat Detection",
     "Tactic: Execution",
-    "Rule Type: Higher-Order Rule"
+    "Rule Type: Higher-Order Rule",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
index bf678e7c616..8a1c89dd74e 100644
--- a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
+++ b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,7 @@ tags = [
     "Tactic: Execution",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/cross-platform/guided_onboarding_sample_rule.toml b/rules/cross-platform/guided_onboarding_sample_rule.toml
index 8f90d9bab3d..a7b712595e0 100644
--- a/rules/cross-platform/guided_onboarding_sample_rule.toml
+++ b/rules/cross-platform/guided_onboarding_sample_rule.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/09/22"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,7 +64,7 @@ references = ["https://www.elastic.co/guide/en/security/current/prebuilt-rules.h
 risk_score = 21
 rule_id = "a198fbbd-9413-45ec-a269-47ae4ccf59ce"
 severity = "low"
-tags = ["Use Case: Guided Onboarding"]
+tags = ["Use Case: Guided Onboarding", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
index 3c18c636b4d..6772035224b 100644
--- a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
+++ b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/09/14"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ setup = """## Setup
 
 The Zoom Filebeat module or similarly structured data is required to be compatible with this rule."""
 severity = "medium"
-tags = ["Data Source: Zoom", "Use Case: Configuration Audit", "Tactic: Initial Access"]
+tags = ["Data Source: Zoom", "Use Case: Configuration Audit", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/cross-platform/multiple_alerts_different_tactics_host.toml b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
index 1f4d8c35a5b..cdb62514331 100644
--- a/rules/cross-platform/multiple_alerts_different_tactics_host.toml
+++ b/rules/cross-platform/multiple_alerts_different_tactics_host.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ name = "Multiple Alerts in Different ATT&CK Tactics on a Single Host"
 risk_score = 73
 rule_id = "b946c2f7-df06-4c00-a5aa-1f6fbc7bb72c"
 severity = "high"
-tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule"]
+tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/cross-platform/multiple_alerts_involving_user.toml b/rules/cross-platform/multiple_alerts_involving_user.toml
index 2687c9e2424..b71e0890c7a 100644
--- a/rules/cross-platform/multiple_alerts_involving_user.toml
+++ b/rules/cross-platform/multiple_alerts_involving_user.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2022/11/16"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ name = "Multiple Alerts Involving a User"
 risk_score = 73
 rule_id = "0d160033-fab7-4e72-85a3-3a9d80c8bff7"
 severity = "high"
-tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule"]
+tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
index ed84a0fbe44..a712ec52eee 100644
--- a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
+++ b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,7 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/cross-platform/persistence_shell_profile_modification.toml b/rules/cross-platform/persistence_shell_profile_modification.toml
index 00947244294..f2aa57f72ee 100644
--- a/rules/cross-platform/persistence_shell_profile_modification.toml
+++ b/rules/cross-platform/persistence_shell_profile_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
index 93609d2dc44..014d3059040 100644
--- a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
+++ b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,6 +26,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
index d8c40423736..1aa962b8f7f 100644
--- a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
+++ b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,6 +26,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
index 7021375ec51..3b753299f55 100644
--- a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
+++ b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
index 6a4ba0a70d2..d06efe12dd0 100644
--- a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
+++ b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
index 489862c21de..b82bdb89990 100644
--- a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
+++ b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,6 +26,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/aws/collection_cloudtrail_logging_created.toml b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
index d97cc1f0759..f0d95cfaae6 100644
--- a/rules/integrations/aws/collection_cloudtrail_logging_created.toml
+++ b/rules/integrations/aws/collection_cloudtrail_logging_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Use Case: Log Auditing",
     "Tactic: Collection",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
index e1a72ddd31c..4b7e1ca60fa 100644
--- a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
+++ b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
index 044e2ccf7e7..2fdd647f242 100644
--- a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
+++ b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -65,7 +65,7 @@ references = [
 risk_score = 73
 rule_id = "fbd44836-0d69-4004-a0b4-03c20370c435"
 severity = "high"
-tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
index 650b9b52e9e..74fea8c26c3 100644
--- a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/26"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
index f0c98b595cc..02e5fe297ef 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -66,7 +66,7 @@ references = [
 risk_score = 21
 rule_id = "7b3da11a-60a2-412e-8aa7-011e1eb9ed47"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
index 98cd4cb61b8..0ab5a41ff84 100644
--- a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
+++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -64,7 +64,7 @@ references = ["https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference
 risk_score = 21
 rule_id = "1ba5160d-f5a2-4624-b0ff-6a1dc55d2516"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
index a715a82b7ee..7f8202a0e7b 100644
--- a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/28"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 73
 rule_id = "523116c0-d89d-4d7c-82c2-39e6845a78ef"
 severity = "high"
-tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
index 25ff424368e..efa4389bdff 100644
--- a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
+++ b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer", "Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Data Source: AWS RDS",
     "Use Case: Asset Visibility",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
index 9fea8feef7d..e847c6232e5 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Use Case: Asset Visibility",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
index 97a1cb932da..3e50865bb91 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -80,6 +80,7 @@ tags = [
     "Data Source: Amazon S3",
     "Use Case: Asset Visibility",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
index 7918b0463a1..eef39684f5a 100644
--- a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
+++ b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Amazon S3",
     "Use Case: Asset Visibility",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
index f0c54a3d391..3a9a338ac67 100644
--- a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
+++ b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,7 @@ tags = [
     "Data Source: AWS STS",
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
index 026f16032f2..96cbb221f49 100644
--- a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
+++ b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,7 @@ tags = [
     "Data Source: AWS EC2",
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
index 39753bbdfc8..c1a29836925 100644
--- a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
index 0f6219dddfd..d9f9c4e5d48 100644
--- a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
+++ b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/09"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
index 8b82b3bac15..7635518faaa 100644
--- a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
+++ b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,7 @@ tags = [
     "Data Source: AWS S3",
     "Use Case: Threat Detection",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
index 06f580b0ec5..3b171b77e62 100644
--- a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
+++ b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/08/26"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Data Source: AWS Service Quotas",
     "Use Case: Threat Detection",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
index e41ca5a755c..3a7028406d0 100644
--- a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
+++ b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: AWS Lambda",
     "Use Case: Threat Detection",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
index e8a00596943..1ddcc7b9fb0 100644
--- a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
+++ b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -41,6 +41,7 @@ tags = [
     "Data Source: Cloudformation",
     "Use Case: Asset Visibility",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
index 83092ce7ae9..dcce974ecaf 100644
--- a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,7 @@ tags = [
     "Data Source: AWS EC2",
     "Use Case: Threat Detection",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
index dc5a7b6745e..c3bd94379a6 100644
--- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
+++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,7 @@ tags = [
     "Data Source: AWS EC2",
     "Use Case: Threat Detection",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
index fd484c472ab..c5db0b08241 100644
--- a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
+++ b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -77,6 +77,7 @@ tags = [
     "Use Case: Network Security Monitoring",
     "Tactic: Exfiltration",
     "Tactic: Collection",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
index a60f13311d9..ca585ea59e4 100644
--- a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
+++ b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -71,6 +71,7 @@ tags = [
     "Use Case: Asset Visibility",
     "Tactic: Exfiltration",
     "Tactic: Collection",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
index 898d5d9937f..fb4d108bdd9 100644
--- a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
+++ b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -68,6 +68,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Use Case: Asset Visibility",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
index c70cf9217fa..c8c01715b1f 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,7 @@ tags = [
     "Data Source: AWS S3",
     "Use Case: Threat Detection",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
index 98ba375749e..4a70189c077 100644
--- a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
+++ b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 21
 rule_id = "87594192-4539-4bc4-8543-23bc3d5bd2b4"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
index 20d3c114da9..c05bd39b30e 100644
--- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
+++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Data Source: AWS EC2",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
index e265909c9a3..58d73c47ff8 100644
--- a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
+++ b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -70,7 +70,7 @@ references = [
 risk_score = 47
 rule_id = "536997f7-ae73-447d-a12d-bff1e8f5f0a0"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: AWS", "Data Source: Amazon Web Services", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml
index d0a8241d536..207042b33a4 100644
--- a/rules/integrations/aws/impact_iam_group_deletion.toml
+++ b/rules/integrations/aws/impact_iam_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Data Source: AWS IAM",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
index 8a28b5077a9..df40da1bab3 100644
--- a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
+++ b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Xavier Pich"]
@@ -78,6 +78,7 @@ tags = [
     "Data Source: AWS KMS",
     "Use Case: Log Auditing",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/impact_rds_group_deletion.toml b/rules/integrations/aws/impact_rds_group_deletion.toml
index 3f07993a69b..b63bdb156cd 100644
--- a/rules/integrations/aws/impact_rds_group_deletion.toml
+++ b/rules/integrations/aws/impact_rds_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -68,6 +68,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Data Source: AWS RDS",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
index 0cd757d9a5c..21dba00c0ed 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -79,6 +79,7 @@ tags = [
     "Data Source: AWS RDS",
     "Use Case: Asset Visibility",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
index 09ee8c18b0c..796a6969e90 100644
--- a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
+++ b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: AWS RDS",
     "Use Case: Asset Visibility",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/impact_rds_snapshot_deleted.toml b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
index 2e1ebda7d30..0ec1d6d5591 100644
--- a/rules/integrations/aws/impact_rds_snapshot_deleted.toml
+++ b/rules/integrations/aws/impact_rds_snapshot_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/29"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -33,6 +33,7 @@ tags = [
     "Data Source: AWS RDS",
     "Use Case: Asset Visibility",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
index 7ecd7e47d37..7ccae3829bd 100644
--- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
+++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,7 @@ tags = [
     "Data Source: AWS S3",
     "Use Case: Threat Detection",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
index 297134d25bd..dfbf9184ea0 100644
--- a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
+++ b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml
@@ -4,7 +4,7 @@ integration = ["aws"]
 maturity = "production"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,7 @@ tags = [
     "Data Source: AWS KMS",
     "Use Case: Threat Detection",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
index bcf3e6b7a20..7838220db0d 100644
--- a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
+++ b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: AWS S3",
     "Use Case: Threat Detection",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/aws/initial_access_password_recovery.toml b/rules/integrations/aws/initial_access_password_recovery.toml
index 7072e909adc..eb7e7fa7465 100644
--- a/rules/integrations/aws/initial_access_password_recovery.toml
+++ b/rules/integrations/aws/initial_access_password_recovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: AWS Signin",
     "Use Case: Identity and Access Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
index dd8929fb669..40b20fe314e 100644
--- a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
+++ b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/19"
 integration = ['aws']
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
 min_stack_version = "8.13.0"
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: AWS Sign-In",
     "Use Case: Threat Detection",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
index 766039eb3d3..b83748605b4 100644
--- a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
+++ b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/16"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: AWS SSM",
     "Use Case: Threat Detection",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
index b624b5ca974..fa6913eb6f3 100644
--- a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
+++ b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,7 @@ tags = [
     "Use Case: Identity and Access Audit",
     "Tactic: Lateral Movement",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
index 8d937c18b42..fb602322a55 100644
--- a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
+++ b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,7 @@ tags = [
     "Data Source: AWS EC2",
     "Use Case: Network Security Monitoring",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
index c5ae7aec9a1..7f9fce05efe 100644
--- a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
+++ b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -83,6 +83,7 @@ tags = [
     "Data Source: AWS IAM",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml
index a6191786904..f67e8334e1e 100644
--- a/rules/integrations/aws/persistence_iam_group_creation.toml
+++ b/rules/integrations/aws/persistence_iam_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -76,6 +76,7 @@ tags = [
     "Data Source: AWS IAM",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
index 9bcc42842a8..8691e610ccc 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,7 @@ tags = [
     "Data Source: AWS IAM",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
index bdaf5811c53..f2db28aada8 100644
--- a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
+++ b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,7 @@ tags = [
     "Data Source: AWS IAM",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
index d81faf28ac5..145b1f20d48 100644
--- a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
+++ b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: AWS Lambda",
     "Use Case: Threat Detection",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_rds_cluster_creation.toml b/rules/integrations/aws/persistence_rds_cluster_creation.toml
index b6292b25b9b..91b44dbddbc 100644
--- a/rules/integrations/aws/persistence_rds_cluster_creation.toml
+++ b/rules/integrations/aws/persistence_rds_cluster_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,7 @@ tags = [
     "Data Source: AWS RDS",
     "Use Case: Asset Visibility",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_rds_group_creation.toml b/rules/integrations/aws/persistence_rds_group_creation.toml
index c2425c3097a..e5ae9ccb5be 100644
--- a/rules/integrations/aws/persistence_rds_group_creation.toml
+++ b/rules/integrations/aws/persistence_rds_group_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -68,6 +68,7 @@ tags = [
     "Data Source: Amazon Web Services",
     "Data Source: AWS RDS",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_rds_instance_creation.toml b/rules/integrations/aws/persistence_rds_instance_creation.toml
index 84e39af4496..1d1e330a0c6 100644
--- a/rules/integrations/aws/persistence_rds_instance_creation.toml
+++ b/rules/integrations/aws/persistence_rds_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/06"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: AWS RDS",
     "Use Case: Asset Visibility",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_redshift_instance_creation.toml b/rules/integrations/aws/persistence_redshift_instance_creation.toml
index cfe6c0d9513..131752f83f2 100644
--- a/rules/integrations/aws/persistence_redshift_instance_creation.toml
+++ b/rules/integrations/aws/persistence_redshift_instance_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/12"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,7 @@ tags = [
     "Data Source: AWS Redshift",
     "Use Case: Asset Visibility",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
index 00aa782fb9b..f74ae5c1bea 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: AWS Route53",
     "Use Case: Asset Visibility",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
index 897ca6a445d..a3fe3ae7c10 100644
--- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
+++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/10"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: AWS Route53",
     "Use Case: Asset Visibility",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
index 5ba34d7ad66..675899d8872 100644
--- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
+++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/19"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -68,6 +68,7 @@ tags = [
     "Data Source: AWS Route53",
     "Use Case: Asset Visibility",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_route_table_created.toml b/rules/integrations/aws/persistence_route_table_created.toml
index 84fe66b3616..02bc3de15b5 100644
--- a/rules/integrations/aws/persistence_route_table_created.toml
+++ b/rules/integrations/aws/persistence_route_table_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: AWS Route53",
     "Use Case: Network Security Monitoring",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
index a0a8178936e..8c8361cc758 100644
--- a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
+++ b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/05"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -79,6 +79,7 @@ tags = [
     "Data Source: AWS Route53",
     "Use Case: Network Security Monitoring",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
index 039b0cafb83..75f3fa9021e 100644
--- a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
+++ b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 
 [rule]
@@ -73,6 +73,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Persistence",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
index 54083cbcec8..79cf7c10400 100644
--- a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
+++ b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: AWS EC2",
     "Use Case: Identity and Access Audit",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
index 8d6ccc9f591..181063cc3fd 100644
--- a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/22"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: AWS IAM",
     "Use Case: Identity and Access Audit",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
index 0726c78cd62..992421cf839 100644
--- a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: AWS STS",
     "Use Case: Identity and Access Audit",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
index 1fc641927f1..fb1acc26080 100644
--- a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
+++ b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/23"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -77,6 +77,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Privilege Escalation",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml
index d679ce05eac..636de5f898c 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/05"
 maturity = "production"
-updated_date = "2024/11/21"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -74,6 +74,7 @@ tags = [
     "Use Case: Policy Violation",
     "Mitre Atlas: T0051",
     "Mitre Atlas: T0054",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml b/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml
index 0cf038a0a6b..522a9e84843 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/04"
 maturity = "production"
-updated_date = "2024/11/05"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -73,7 +73,8 @@ tags = [
     "Data Source: AWS S3",
     "Use Case: Potential Overload",
     "Use Case: Resource Exhaustion",
-    "Mitre Atlas: LLM04"
+    "Mitre Atlas: LLM04",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml
index a1436270fc1..49bd25cd4d0 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/11/20"
 maturity = "production"
-updated_date = "2024/11/20"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -74,6 +74,7 @@ tags = [
     "Use Case: Policy Violation",
     "Mitre Atlas: T0051",
     "Mitre Atlas: T0054",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml
index a16d671f619..26f7de220a1 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/11/20"
 maturity = "production"
-updated_date = "2024/11/20"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -74,6 +74,7 @@ tags = [
     "Use Case: Policy Violation",
     "Mitre Atlas: T0051",
     "Mitre Atlas: T0054",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml
index 2e006fe164d..2a6b501b2c8 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/11"
 integration = ["aws_bedrock"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -78,6 +78,7 @@ tags = [
     "Mitre Atlas: T0015",
     "Mitre Atlas: T0034",
     "Mitre Atlas: T0046",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml
index 0dc9fb6dfb5..f4aa1c06ea8 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/11/20"
 maturity = "production"
-updated_date = "2024/11/20"
+updated_date = "2025/01/15"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -74,6 +74,7 @@ tags = [
     "Use Case: Policy Violation",
     "Mitre Atlas: T0051",
     "Mitre Atlas: T0054",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
index 8ffd9f67640..2d505ecfb45 100644
--- a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
+++ b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,7 +67,7 @@ references = ["https://docs.microsoft.com/en-us/azure/event-hubs/authorize-acces
 risk_score = 47
 rule_id = "b6dce542-2b75-4ffb-b7d6-38787298ba9d"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Collection"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Collection", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
index 4a01d6cdd80..433effe6628 100644
--- a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
+++ b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -110,6 +110,7 @@ tags = [
     "Use Case: Identity and Access Audit",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
index 7e487719b99..615a5b47f01 100644
--- a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
+++ b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -66,7 +66,7 @@ references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/
 risk_score = 47
 rule_id = "3ad77ed4-4dcf-4c51-8bfc-e3f7ce316b2f"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Credential Access"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
index 6d6b9ceb0df..4ede482fd06 100644
--- a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
+++ b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Microsoft Entra ID",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
index de27728e29f..7e451f3a75d 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,7 @@ tags = [
     "Use Case: Identity and Access Audit",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
index 320fe59881c..1f6c63cef5c 100644
--- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
+++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml
@@ -4,7 +4,7 @@ integration = ["azure"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -78,6 +78,7 @@ tags = [
     "Use Case: Identity and Access Audit",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
index dcfd02782a9..ed509643d52 100644
--- a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
+++ b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Matteo Potito Giorgio"]
@@ -30,6 +30,7 @@ tags = [
     "Data Source: Microsoft Entra ID",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/azure/credential_access_key_vault_modified.toml b/rules/integrations/azure/credential_access_key_vault_modified.toml
index ea67b172f91..c39fded5969 100644
--- a/rules/integrations/azure/credential_access_key_vault_modified.toml
+++ b/rules/integrations/azure/credential_access_key_vault_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 47
 rule_id = "792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Credential Access"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
index 172b624192c..4ffdf7111ab 100644
--- a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
+++ b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Azure",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
index e6663908459..072ba952ffd 100644
--- a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
+++ b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Azure",
     "Use Case: Identity and Access Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
index fe7f45e36e4..64091a7a4b4 100644
--- a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,7 +62,7 @@ references = [
 risk_score = 21
 rule_id = "8ddab73b-3d15-4e5d-9413-47f05553c1d7"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
index ec8f5875ee5..1cc74712800 100644
--- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
+++ b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml
@@ -67,7 +67,8 @@ tags = [
     "Domain: Cloud",
     "Data Source: Azure",
     "Use Case: Identity and Access Audit",
-    "Tactic: Defense Evasion"
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
index cc40a50096c..9c3ca099cc0 100644
--- a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,7 +66,7 @@ references = ["https://docs.microsoft.com/en-us/azure/azure-monitor/platform/dia
 risk_score = 47
 rule_id = "5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
index 63762cf4cc3..4f926b954b8 100644
--- a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 47
 rule_id = "e0f36de1-0342-453d-95a9-a068b257b053"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
index fb45a8c2527..f5c04c6e240 100644
--- a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Azure",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
index a386b6eee1a..53c7c70c607 100644
--- a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -73,6 +73,7 @@ tags = [
     "Data Source: Azure",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
index 0d03605135c..41d53464d9d 100644
--- a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
+++ b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -68,7 +68,7 @@ references = [
 risk_score = 47
 rule_id = "8b64d36a-1307-4b2e-a77b-a0027e4d27c8"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
index dce1516abb1..df552106b54 100644
--- a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
+++ b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,7 @@ tags = [
     "Data Source: Azure",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
index a634a0a74a5..66bcb23efcf 100644
--- a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
+++ b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/08/27"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 21
 rule_id = "f0bc081a-2346-4744-a6a4-81514817e888"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/discovery_blob_container_access_mod.toml b/rules/integrations/azure/discovery_blob_container_access_mod.toml
index 2a4a308335b..52b0400362c 100644
--- a/rules/integrations/azure/discovery_blob_container_access_mod.toml
+++ b/rules/integrations/azure/discovery_blob_container_access_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,7 +64,7 @@ references = ["https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-re
 risk_score = 21
 rule_id = "2636aa6c-88b5-4337-9c31-8d0192a8ef45"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Discovery"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Discovery", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/execution_command_virtual_machine.toml b/rules/integrations/azure/execution_command_virtual_machine.toml
index 7bcb6f0aa98..b6baefbe892 100644
--- a/rules/integrations/azure/execution_command_virtual_machine.toml
+++ b/rules/integrations/azure/execution_command_virtual_machine.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,7 +72,7 @@ references = [
 risk_score = 47
 rule_id = "60884af6-f553-4a6c-af13-300047455491"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Execution"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Execution", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
index eff533598c1..a963a57337c 100644
--- a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
+++ b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/05"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -68,7 +68,7 @@ references = ["https://www.fireeye.com/content/dam/collateral/en/wp-m-unc2452.pd
 risk_score = 47
 rule_id = "f766ffaf-9568-4909-b734-75d19b35cbf4"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
index 732a1be1415..b81637fa6e9 100644
--- a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
+++ b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -66,7 +66,7 @@ references = [
 risk_score = 47
 rule_id = "83a1931d-8136-46fc-b7b9-2db4f639e014"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/impact_resource_group_deletion.toml b/rules/integrations/azure/impact_resource_group_deletion.toml
index b9d9e268d26..9a3bd20a8cc 100644
--- a/rules/integrations/azure/impact_resource_group_deletion.toml
+++ b/rules/integrations/azure/impact_resource_group_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 47
 rule_id = "bb4fe8d2-7ae2-475c-8b5d-55b449e4264f"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/impact_virtual_network_device_modified.toml b/rules/integrations/azure/impact_virtual_network_device_modified.toml
index b1d9b4df830..36052a03911 100644
--- a/rules/integrations/azure/impact_virtual_network_device_modified.toml
+++ b/rules/integrations/azure/impact_virtual_network_device_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/12"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -66,7 +66,7 @@ references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/
 risk_score = 21
 rule_id = "573f6e7a-7acf-4bcd-ad42-c4969124d3c0"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Network Security Monitoring", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Network Security Monitoring", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/initial_access_external_guest_user_invite.toml b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
index 20ebd87c399..d78d3c2067f 100644
--- a/rules/integrations/azure/initial_access_external_guest_user_invite.toml
+++ b/rules/integrations/azure/initial_access_external_guest_user_invite.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/31"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,7 +67,7 @@ references = ["https://docs.microsoft.com/en-us/azure/governance/policy/samples/
 risk_score = 21
 rule_id = "141e9b3a-ff37-4756-989d-05d7cbf35b0e"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Initial Access"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_azure_automation_account_created.toml b/rules/integrations/azure/persistence_azure_automation_account_created.toml
index 5142abaac6d..8ee4ea7b979 100644
--- a/rules/integrations/azure/persistence_azure_automation_account_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,7 +62,7 @@ references = [
 risk_score = 21
 rule_id = "df26fd74-1baa-4479-b42e-48da84642330"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
index eb286111556..3fd64612819 100644
--- a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
+++ b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,7 +63,7 @@ references = [
 risk_score = 21
 rule_id = "16280f1e-57e6-4242-aa21-bb4d16f13b2f"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
index e7b06965239..cb9f10e3b6a 100644
--- a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
+++ b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,7 +63,7 @@ references = [
 risk_score = 21
 rule_id = "e9ff9c1c-fe36-4d0d-b3fd-9e0bf4853a62"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
index 4e62b2f4a2a..78a2a290ba5 100644
--- a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
+++ b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/01"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,7 +59,7 @@ references = ["https://docs.microsoft.com/en-us/azure/active-directory/condition
 risk_score = 47
 rule_id = "bc48bba7-4a23-4232-b551-eca3ca1e3f20"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
index d7cba51c326..4e7b23074b2 100644
--- a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
+++ b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,7 +62,7 @@ references = [
 risk_score = 47
 rule_id = "04c5a96f-19c5-44fd-9571-a0b033f9086f"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
index 66bac044e3d..e81be681868 100644
--- a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
+++ b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/24"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 73
 rule_id = "ed9ecd27-e3e6-4fd9-8586-7754803f7fc8"
 severity = "high"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
index 4f092e72dce..1ef684d774f 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,7 +57,7 @@ The Azure Fleet integration, Filebeat module, or similarly structured data is re
 risk_score = 21
 rule_id = "774f5e28-7b75-4a58-b94e-41bf060fdd86"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
index 571b574affa..51171c51de2 100644
--- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
+++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/20"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,7 +62,7 @@ references = [
 risk_score = 21
 rule_id = "38e5acdd-5f20-4d99-8fe4-f0a1a592077f"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
index 42919c43d6a..c637cb21e63 100644
--- a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
+++ b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["azure"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -67,6 +67,7 @@ tags = [
     "Data Source: Azure",
     "Use Case: Identity and Access Audit",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/beaconing/command_and_control_beaconing.toml b/rules/integrations/beaconing/command_and_control_beaconing.toml
index fc7c028c5c1..f89fe47c8c3 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -43,7 +43,7 @@ The Network Beaconing Identification integration consists of a statistical frame
 - Follow the instructions under the **Installation** section.
 """
 severity = "low"
-tags = ["Domain: Network", "Use Case: C2 Beaconing Detection", "Tactic: Command and Control"]
+tags = ["Domain: Network", "Use Case: C2 Beaconing Detection", "Tactic: Command and Control", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
index 15476b155f7..0fe0d4d7320 100644
--- a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
+++ b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["beaconing", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -43,7 +43,7 @@ The Network Beaconing Identification integration consists of a statistical frame
 - Follow the instructions under the **Installation** section.
 """
 severity = "low"
-tags = ["Domain: Network", "Use Case: C2 Beaconing Detection", "Tactic: Command and Control"]
+tags = ["Domain: Network", "Use Case: C2 Beaconing Detection", "Tactic: Command and Control", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/cloud_defend/container_workload_protection.toml b/rules/integrations/cloud_defend/container_workload_protection.toml
index 4e6adb11650..49f40294031 100644
--- a/rules/integrations/cloud_defend/container_workload_protection.toml
+++ b/rules/integrations/cloud_defend/container_workload_protection.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/05"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,7 +30,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "medium"
-tags = ["Data Source: Elastic Defend for Containers", "Domain: Container"]
+tags = ["Data Source: Elastic Defend for Containers", "Domain: Container", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
index 4f1a05c1c44..8decdf2c8eb 100644
--- a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/28"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
index 0aa2cb2092e..0bf131a2b29 100644
--- a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,6 +26,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Collection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
index 8e249852610..95c5a9deda7 100644
--- a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
index eba962c5949..72025efeb6a 100644
--- a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/06"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ references = [
 risk_score = 73
 rule_id = "342f834b-21a6-41bf-878c-87d116eba3ee"
 severity = "high"
-tags = ["Data Source: Elastic Defend for Containers", "Domain: Container", "Tactic: Defense Evasion"]
+tags = ["Data Source: Elastic Defend for Containers", "Domain: Container", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
index 52a64383463..c035f87d8fb 100644
--- a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Tactic: Discovery",
     "Tactic: Command and Control",
     "Tactic: Reconnaissance",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
index 1ff68903765..422574e94a0 100644
--- a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
index 7bd50856d92..41c110968dd 100644
--- a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
index 9446fe587ea..3915ee5583e 100644
--- a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
index 90d3577a298..eaabb41bc46 100644
--- a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
index 8b9c6637863..070fe900c3d 100644
--- a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
index ba4614ecdea..ed47d7a84ee 100644
--- a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Initial Access",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
index e17ef878e45..900790cf042 100644
--- a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Lateral Movement",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
index 0fbdd5d926f..d97607dc184 100644
--- a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
+++ b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/12"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
index c276730b225..9bdbcf452cb 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
index eca6da4b6f1..911794bc3eb 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
index 36a31cd3f1c..c498b546826 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -33,6 +33,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
index 887f8c2250b..9f6a95ed845 100644
--- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
+++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["cloud_defend"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_error_audit_event_promotion.toml b/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_error_audit_event_promotion.toml
index 014a64956d8..92c6ca0ff81 100644
--- a/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_error_audit_event_promotion.toml
+++ b/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_error_audit_event_promotion.toml
@@ -3,7 +3,7 @@ creation_date = "2021/06/23"
 integration = ["cyberarkpas"]
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,7 @@ tags = [
     "Use Case: Log Auditing",
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_recommended_events_to_monitor_promotion.toml b/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_recommended_events_to_monitor_promotion.toml
index 4fd99826fe8..ae927878370 100644
--- a/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_recommended_events_to_monitor_promotion.toml
+++ b/rules/integrations/cyberarkpas/privilege_escalation_cyberarkpas_recommended_events_to_monitor_promotion.toml
@@ -3,7 +3,7 @@ creation_date = "2021/06/23"
 integration = ["cyberarkpas"]
 maturity = "production"
 promotion = true
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,7 @@ tags = [
     "Use Case: Log Auditing",
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
index 1790fed6242..4f85de1b193 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
index 145e5693ef0..902dd750d2d 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
index d56613657ac..cd93d27121e 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -49,6 +49,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
index cd2aa1a538a..b3bd71f709b 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
index c3d47eb95a3..8e885a4b26b 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -49,6 +49,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
index c6baea689f1..a69cb0486c3 100644
--- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
+++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
index 53b6485a602..d0c800d51aa 100644
--- a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
+++ b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["ded", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -49,6 +49,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
index 5f7a8b70a0a..662f12dab3e 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
index d9a338d7772..afcf159faef 100644
--- a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -58,6 +58,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
index a22143f6c1f..1e9fe0424c3 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
index d15606fad3f..4f2e1f35a0a 100644
--- a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
+++ b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/14"
 integration = ["dga", "endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml
index 75cc6cf6a57..ca5abe2bfcf 100644
--- a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml
+++ b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -111,7 +111,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "high"
-tags = ["Data Source: Elastic Defend", "Tactic: Defense Evasion"]
+tags = ["Data Source: Elastic Defend", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml
index 448200a5aa2..c5b227f4852 100644
--- a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml
+++ b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -110,7 +110,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "high"
-tags = ["Data Source: Elastic Defend", "Tactic: Defense Evasion"]
+tags = ["Data Source: Elastic Defend", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/elastic_endpoint_security.toml b/rules/integrations/endpoint/elastic_endpoint_security.toml
index 94b0edde57b..d0e615fc9fd 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "New fields added: required_fields, related_integrations, setup"
 min_stack_version = "8.3.0"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,7 +52,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "medium"
-tags = ["Data Source: Elastic Defend"]
+tags = ["Data Source: Elastic Defend", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml b/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml
index b68ab164cce..e71460b70ef 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -94,7 +94,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "medium"
-tags = ["Data Source: Elastic Defend"]
+tags = ["Data Source: Elastic Defend", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml b/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml
index abaa4e2b2d5..b1ef054b58d 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -95,7 +95,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "low"
-tags = ["Data Source: Elastic Defend"]
+tags = ["Data Source: Elastic Defend", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml b/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml
index e47f9f8b57e..bb8039b5253 100644
--- a/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml
+++ b/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -102,7 +102,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "medium"
-tags = ["Data Source: Elastic Defend", "Tactic: Execution"]
+tags = ["Data Source: Elastic Defend", "Tactic: Execution", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml b/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml
index d85a79e2282..23a046a2e06 100644
--- a/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml
+++ b/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -102,7 +102,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "low"
-tags = ["Data Source: Elastic Defend", "Tactic: Execution"]
+tags = ["Data Source: Elastic Defend", "Tactic: Execution", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml b/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml
index af5a8d251c9..83d6dd693bf 100644
--- a/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml
+++ b/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -93,7 +93,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "high"
-tags = ["Data Source: Elastic Defend", "Tactic: Impact"]
+tags = ["Data Source: Elastic Defend", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml b/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml
index 6a4e817e337..d55831970c8 100644
--- a/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml
+++ b/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2024/11/26"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -94,7 +94,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
 """
 severity = "high"
-tags = ["Data Source: Elastic Defend", "Tactic: Impact"]
+tags = ["Data Source: Elastic Defend", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/fim/persistence_suspicious_file_modifications.toml b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
index efe1c35274f..7291abef0f6 100644
--- a/rules/integrations/fim/persistence_suspicious_file_modifications.toml
+++ b/rules/integrations/fim/persistence_suspicious_file_modifications.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["fim"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Defense Evasion",
     "Data Source: File Integrity Monitoring",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
index 248edb32290..2ade101b010 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Log Auditing",
     "Tactic: Collection",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
index 62293ca47e9..2f2e473a30c 100644
--- a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
+++ b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Log Auditing",
     "Tactic: Collection",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
index fd0a9562eeb..6999cef9783 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
index 8ac98bd391c..6ac6b9d0085 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
index 5dd2a532f0e..3afdc0d904e 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
index b9601340fc8..0959ed9e33e 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Log Auditing",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
index 53ef5da345f..36bd43f1c07 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Log Auditing",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
index ce854318857..b232902cc6d 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/23"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Log Auditing",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
index 044db48100b..01e2afac043 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/18"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Log Auditing",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
index b2027a31fb1..d518d9a46db 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
index 480460a1c04..66e67424205 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
index 99eba7a85c1..49efa174d6f 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
index d71730d1b73..8ae59e5172f 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
index 5642ba8d6dc..2dbfe20dffd 100644
--- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
+++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
index 1a24433f1cb..cff4a666a38 100644
--- a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
+++ b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Log Auditing",
     "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
index c7dcf53018e..785f4fb255d 100644
--- a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
+++ b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
index fdb31ff3445..46cffe5833f 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
index 10b4e12b1aa..941a8c6dcc0 100644
--- a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
+++ b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Impact",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
index 3bf87b7a0c0..2f75f2ef101 100644
--- a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
+++ b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,7 +63,7 @@ references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
 risk_score = 47
 rule_id = "bc0f2d83-32b8-4ae2-b0e6-6a45772e9331"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: GCP", "Data Source: Google Cloud Platform", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: GCP", "Data Source: Google Cloud Platform", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
index 2347ca3e662..d26fdfad9fe 100644
--- a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
+++ b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
index 91301965a41..6060132006a 100644
--- a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
+++ b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
index d869326e949..84d9cc8278b 100644
--- a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
+++ b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/21"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/gcp/persistence_gcp_service_account_created.toml b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
index 3722562b73f..64c798841be 100644
--- a/rules/integrations/gcp/persistence_gcp_service_account_created.toml
+++ b/rules/integrations/gcp/persistence_gcp_service_account_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["gcp"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Google Cloud Platform",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
index 6467a9885d7..f2b2ded39ab 100644
--- a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
+++ b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -22,7 +22,7 @@ name = "GitHub Protected Branch Settings Changed"
 risk_score = 47
 rule_id = "07639887-da3a-4fbf-9532-8ce748ff8c50"
 severity = "medium"
-tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Github"]
+tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Github", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/integrations/github/execution_github_app_deleted.toml b/rules/integrations/github/execution_github_app_deleted.toml
index 0a72059c0c0..7df27b1522f 100644
--- a/rules/integrations/github/execution_github_app_deleted.toml
+++ b/rules/integrations/github/execution_github_app_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -17,7 +17,7 @@ name = "GitHub App Deleted"
 risk_score = 21
 rule_id = "fd01b949-81be-46d5-bcf8-284395d5f56d"
 severity = "low"
-tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github"]
+tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
index 1b11b55fd29..e2a6531a045 100644
--- a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
+++ b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -26,6 +26,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Execution",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
index ce084648803..f6a63c75a1b 100644
--- a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
+++ b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/14"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Tactic: Execution",
     "Rule Type: Higher-Order Rule",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/integrations/github/execution_new_github_app_installed.toml b/rules/integrations/github/execution_new_github_app_installed.toml
index 3535fe37042..3fae7bd4642 100644
--- a/rules/integrations/github/execution_new_github_app_installed.toml
+++ b/rules/integrations/github/execution_new_github_app_installed.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -23,7 +23,7 @@ name = "New GitHub App Installed"
 risk_score = 47
 rule_id = "1ca62f14-4787-4913-b7af-df11745a49da"
 severity = "medium"
-tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github"]
+tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/integrations/github/impact_github_repository_deleted.toml b/rules/integrations/github/impact_github_repository_deleted.toml
index f9feff11567..663e5d4326e 100644
--- a/rules/integrations/github/impact_github_repository_deleted.toml
+++ b/rules/integrations/github/impact_github_repository_deleted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -28,6 +28,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Impact",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/github/persistence_github_org_owner_added.toml b/rules/integrations/github/persistence_github_org_owner_added.toml
index 553ccced09e..6caa8361a05 100644
--- a/rules/integrations/github/persistence_github_org_owner_added.toml
+++ b/rules/integrations/github/persistence_github_org_owner_added.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Persistence",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/github/persistence_organization_owner_role_granted.toml b/rules/integrations/github/persistence_organization_owner_role_granted.toml
index 9d5c504ec04..dec4ab5c005 100644
--- a/rules/integrations/github/persistence_organization_owner_role_granted.toml
+++ b/rules/integrations/github/persistence_organization_owner_role_granted.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/11"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for the Github Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Use Case: UEBA",
     "Tactic: Persistence",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
index af63a73a549..36138972133 100644
--- a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
+++ b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/21"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -85,6 +85,7 @@ tags = [
     "Data Source: Google Workspace",
     "Use Case: Configuration Audit",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
index db9094e9a08..62c416df9d2 100644
--- a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
+++ b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/30"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -77,7 +77,7 @@ references = [
 risk_score = 47
 rule_id = "21bafdf0-cf17-11ed-bd57-f661ea17fbcc"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Google Workspace", "Tactic: Defense Evasion", "Tactic: Initial Access"]
+tags = ["Domain: Cloud", "Data Source: Google Workspace", "Tactic: Defense Evasion", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "new_terms"
 
diff --git a/rules/integrations/google_workspace/google_workspace_alert_center_promotion.toml b/rules/integrations/google_workspace/google_workspace_alert_center_promotion.toml
index bdf24ad3254..785c4f8d892 100644
--- a/rules/integrations/google_workspace/google_workspace_alert_center_promotion.toml
+++ b/rules/integrations/google_workspace/google_workspace_alert_center_promotion.toml
@@ -3,7 +3,7 @@ creation_date = "2023/01/15"
 integration = ["google_workspace"]
 maturity = "production"
 promotion = true
-updated_date = "2024/09/23"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,7 @@ tags = [
     "Data Source: Google Workspace",
     "Use Case: Log Auditing",
     "Use Case: Threat Detection",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
index 1225cf723d9..e3a60da3cd3 100644
--- a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
+++ b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["google_workspace"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -82,6 +82,7 @@ tags = [
     "Data Source: Google Workspace",
     "Use Case: Identity and Access Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
index 5f5f5219b0a..28ffde48823 100644
--- a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
+++ b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 47
 rule_id = "63c056a0-339a-11ed-a261-0242ac120002"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Discovery"]
+tags = ["Data Source: Kubernetes", "Tactic: Discovery", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
index 20978d03e5e..cc14c799347 100644
--- a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
+++ b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/30"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 47
 rule_id = "12a2f15d-597e-4334-88ff-38a02cb1330b"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Discovery"]
+tags = ["Data Source: Kubernetes", "Tactic: Discovery", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
index b34cbc1677d..fa6b1fe8065 100644
--- a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
+++ b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/17"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,7 +71,7 @@ references = [
 risk_score = 47
 rule_id = "14de811c-d60f-11ec-9fd7-f661ea17fbce"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
index 3b12649c5e4..d18b385f201 100644
--- a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
+++ b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,7 +66,7 @@ references = [
 risk_score = 47
 rule_id = "63c057cc-339a-11ed-a261-0242ac120002"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Initial Access", "Tactic: Defense Evasion"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Initial Access", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
index 8cdb7f67bb0..1324eebe7b8 100644
--- a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
+++ b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -76,7 +76,7 @@ references = [
 risk_score = 47
 rule_id = "65f9bccd-510b-40df-8263-334f03174fed"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Persistence"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_container_created_with_excessive_linux_capabilities.toml b/rules/integrations/kubernetes/privilege_escalation_container_created_with_excessive_linux_capabilities.toml
index ab1756c91af..8f1510caf35 100644
--- a/rules/integrations/kubernetes/privilege_escalation_container_created_with_excessive_linux_capabilities.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_container_created_with_excessive_linux_capabilities.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/20"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,7 +56,7 @@ references = [
 risk_score = 47
 rule_id = "7164081a-3930-11ed-a261-0242ac120002"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
index 0afe4c3efbd..4479f2ed9f2 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,7 +73,7 @@ references = [
 risk_score = 47
 rule_id = "764c8437-a581-4537-8060-1fdb0e92c92d"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
index eb1093928ea..2d497aa5632 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,7 +70,7 @@ references = [
 risk_score = 47
 rule_id = "12cbf709-69e8-4055-94f9-24314385c27e"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
index 411ac408b12..059873838df 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,7 +73,7 @@ references = [
 risk_score = 47
 rule_id = "df7fda76-c92b-4943-bc68-04460a5ea5ba"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
index 463da62fe59..b3f977fc441 100644
--- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/11"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,7 +72,7 @@ references = [
 risk_score = 47
 rule_id = "2abda169-416b-4bb3-9a6b-f8d239fd78ba"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
index c305bba337f..51e114c4057 100644
--- a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/05"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,7 +70,7 @@ references = [
 risk_score = 47
 rule_id = "c7908cac-337a-4f38-b50d-5eeb78bdb531"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
index 66ea42381ec..56866f5108c 100644
--- a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
+++ b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/13"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 47
 rule_id = "63c05204-339a-11ed-a261-0242ac120002"
 severity = "medium"
-tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
index d250671d9e9..39853f04d20 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
index d8e9dee58fa..2181dc12895 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
index 4ed7933ed14..644c17f7449 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -51,6 +51,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
index bcacb0b27e6..55f98d25c82 100644
--- a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
index dd47452c003..1911eb91c69 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
index b83970cf456..c4842c877e6 100644
--- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -49,6 +49,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
index 9c23594d32d..20b48c25236 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
index 6849ec4586a..6c57ff91485 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
index 93948ff2d3e..3f312af635d 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -49,6 +49,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
index f5198584e82..7783c1cd680 100644
--- a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -51,6 +51,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
index 7c43c368373..af286c03f28 100644
--- a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
+++ b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/12"
 integration = ["lmd", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 70
@@ -50,6 +50,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
index d49fffbdac5..e10126d0a2d 100644
--- a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
+++ b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/29"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Gary Blackwell", "Austin Songer"]
@@ -71,7 +71,7 @@ references = [
 risk_score = 47
 rule_id = "ec8efb0c-604d-42fa-ac46-ed1cfbc38f78"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Collection"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Collection", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
index 365fcce4a7c..af9ae71f8f1 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml
@@ -4,7 +4,7 @@ integration = ["o365"]
 maturity = "production"
 min_stack_comments = "ES|QL not available until 8.13.0 in technical preview."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Willem D'Haese", "Austin Songer"]
@@ -35,6 +35,7 @@ tags = [
     "Use Case: Identity and Access Audit",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"
diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
index 1167ea15706..bb477532bd4 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/01"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
index dc5ee41331b..a48986bf801 100644
--- a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
+++ b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -68,6 +68,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
index 167c11a6bfc..e0321d00408 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
index 73f1b054994..a227d788063 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
index 534b4f5ee4c..b89dff6f8b3 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
index 898ca3e8be5..2e79b68f418 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
index 4a7cd156f04..0499a78aa9c 100644
--- a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
+++ b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/13"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,7 +64,7 @@ references = ["https://twitter.com/misconfig/status/1476144066807140355"]
 risk_score = 47
 rule_id = "675239ea-c1bc-4467-a6d3-b9e2cc7f676d"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Initial Access", "Tactic: Defense Evasion"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Initial Access", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
index 93aa60919b4..d40aaa34cf5 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,7 +67,7 @@ references = [
 risk_score = 47
 rule_id = "ff4dd44a-0ac6-44c4-8609-3f81bc820f02"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Exfiltration"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Exfiltration", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
index a8c80f6adf3..9700f5fb32d 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -68,7 +68,7 @@ references = [
 risk_score = 47
 rule_id = "272a6484-2663-46db-a532-ef734bf9a796"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Exfiltration"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Exfiltration", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
index b75e804cfe6..9bc31aa1bd6 100644
--- a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
+++ b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -59,7 +59,7 @@ references = [
 risk_score = 47
 rule_id = "571ff456-aa7f-4e48-8a88-39698bb5418f"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Exfiltration"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Exfiltration", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
index d362c9b34b1..58c441f2a04 100644
--- a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
+++ b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 47
 rule_id = "721999d0-7ab2-44bf-b328-6e63367b9b29"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
index 3064dadef4c..4d93834da53 100644
--- a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
+++ b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -60,7 +60,7 @@ references = [
 risk_score = 47
 rule_id = "b2951150-658f-4a60-832f-a00d1e6c6745"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Impact"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_abnormal_clientappid.toml b/rules/integrations/o365/initial_access_microsoft_365_abnormal_clientappid.toml
index ffb3a53184d..be81fa89cc4 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_abnormal_clientappid.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_abnormal_clientappid.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2024/07/04"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -45,6 +45,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
index c34f4933d75..103daf24184 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
index d811244259f..c49431ca1fc 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
index 4b9ce8c228c..31acdfec8b3 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Identity and Access Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
index 4a0ddbfcfb1..ee3bc044b9e 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "development"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -74,7 +74,7 @@ references = [
 risk_score = 47
 rule_id = "9c49fe22-4e86-4384-a9a0-602f4d54088d"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Initial Access"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
index bcbbced53bb..35f62652d0b 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ references = ["https://www.huntress.com/blog/time-travelers-busted-how-to-detect
 risk_score = 47
 rule_id = "3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Threat Detection", "Tactic: Initial Access"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Threat Detection", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
index 1bb1602275f..b7cf28e1ceb 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/04"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ references = ["https://www.huntress.com/blog/time-travelers-busted-how-to-detect
 risk_score = 47
 rule_id = "32d3ad0e-6add-11ef-8c7b-f661ea17fbcc"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Threat Detection", "Tactic: Initial Access"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Threat Detection", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "new_terms"
 
diff --git a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
index a75af9b8df1..60a023e9999 100644
--- a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
+++ b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/15"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -67,6 +67,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Configuration Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
index 448e4a29e4a..b22dc87b3e8 100644
--- a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
+++ b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/12"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,7 +63,7 @@ references = [
 risk_score = 47
 rule_id = "5930658c-2107-4afc-91af-e0e55b7f7184"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Initial Access"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
index 94c0fb65c78..560e67b7a90 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,7 +64,7 @@ references = [
 risk_score = 73
 rule_id = "bba1b212-b85c-41c6-9b28-be0e5cdfc9b1"
 severity = "high"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Lateral Movement"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Lateral Movement", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
index 9649942595e..1ddff70548b 100644
--- a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
+++ b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/10"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,7 +63,7 @@ references = [
 risk_score = 73
 rule_id = "0e52157a-8e96-4a95-a6e3-5faae5081a74"
 severity = "high"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Lateral Movement"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Lateral Movement", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
index fe520c2e72c..5069b3e6823 100644
--- a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
+++ b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic", "Austin Songer"]
@@ -57,7 +57,7 @@ The Office 365 Logs Fleet integration, Filebeat module, or similarly structured
 risk_score = 21
 rule_id = "0ce6487d-8069-4888-9ddd-61b52490cebc"
 severity = "low"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
index 1388ae1826e..94caa0432f1 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,7 +67,7 @@ references = [
 risk_score = 47
 rule_id = "514121ce-c7b6-474a-8237-68ff71672379"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
index 95cdb43b803..ddd4196f61a 100644
--- a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
index cec53dca43b..e6f34d2ac50 100644
--- a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/06"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Identity and Access Audit",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
index 8d69c1820e1..bd6226b4864 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,7 +66,7 @@ references = ["https://docs.microsoft.com/en-us/microsoftteams/platform/concepts
 risk_score = 47
 rule_id = "bbd1a775-8267-41fa-9232-20e5582596ac"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
index fbf21436b19..df7c20b913f 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/30"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -65,7 +65,7 @@ references = ["https://docs.microsoft.com/en-us/microsoftteams/manage-external-a
 risk_score = 47
 rule_id = "27f7c15a-91f8-4c3d-8b9e-1f99cc030a51"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
index fe3afbfeb4a..1126bc7afa0 100644
--- a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
+++ b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/20"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -65,7 +65,7 @@ references = [
 risk_score = 47
 rule_id = "5e552599-ddec-4e14-bad1-28aa42404388"
 severity = "medium"
-tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence"]
+tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
index 72015a09381..956e2da3b51 100644
--- a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
+++ b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/17"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Austin Songer"]
@@ -69,6 +69,7 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Identity and Access Audit",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/okta/credential_access_attempted_bypass_of_okta_mfa.toml b/rules/integrations/okta/credential_access_attempted_bypass_of_okta_mfa.toml
index 1770c2048f7..4723dd4f8f5 100644
--- a/rules/integrations/okta/credential_access_attempted_bypass_of_okta_mfa.toml
+++ b/rules/integrations/okta/credential_access_attempted_bypass_of_okta_mfa.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -67,7 +67,7 @@ references = [
 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"]
+tags = ["Data Source: Okta", "Use Case: Identity and Access Audit", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/credential_access_attempts_to_brute_force_okta_user_account.toml b/rules/integrations/okta/credential_access_attempts_to_brute_force_okta_user_account.toml
index f32685c206e..b21fe99db6f 100644
--- a/rules/integrations/okta/credential_access_attempts_to_brute_force_okta_user_account.toml
+++ b/rules/integrations/okta/credential_access_attempts_to_brute_force_okta_user_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -65,7 +65,7 @@ references = [
 risk_score = 47
 rule_id = "e08ccd49-0380-4b2b-8d71-8000377d6e49"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/integrations/okta/credential_access_multiple_auth_events_from_single_device_behind_proxy.toml b/rules/integrations/okta/credential_access_multiple_auth_events_from_single_device_behind_proxy.toml
index bef0fbeec1c..8595d3b42db 100644
--- a/rules/integrations/okta/credential_access_multiple_auth_events_from_single_device_behind_proxy.toml
+++ b/rules/integrations/okta/credential_access_multiple_auth_events_from_single_device_behind_proxy.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/10"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -76,7 +76,7 @@ risk_score = 47
 rule_id = "50887ba8-7ff7-11ee-a038-f661ea17fbcd"
 setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/integrations/okta/credential_access_multiple_device_token_hashes_for_single_okta_session.toml b/rules/integrations/okta/credential_access_multiple_device_token_hashes_for_single_okta_session.toml
index 42472c51c66..4b67396cfdf 100644
--- a/rules/integrations/okta/credential_access_multiple_device_token_hashes_for_single_okta_session.toml
+++ b/rules/integrations/okta/credential_access_multiple_device_token_hashes_for_single_okta_session.toml
@@ -4,7 +4,7 @@ integration = ["okta"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 min_stack_version = "8.15.0"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ setup = """## Setup
 
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access", "Domain: SaaS"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access", "Domain: SaaS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "esql"
 
diff --git a/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_from_single_source.toml b/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_from_single_source.toml
index 3b118d936c5..8e8bd9988e8 100644
--- a/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_from_single_source.toml
+++ b/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_from_single_source.toml
@@ -4,7 +4,7 @@ integration = ["okta"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 min_stack_version = "8.15.0"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -80,7 +80,7 @@ risk_score = 21
 rule_id = "94e734c0-2cda-11ef-84e1-f661ea17fbce"
 setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "esql"
 
diff --git a/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_with_the_same_device_token_hash.toml b/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_with_the_same_device_token_hash.toml
index 0f89ea844ff..d91f97f4b22 100644
--- a/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_with_the_same_device_token_hash.toml
+++ b/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_with_the_same_device_token_hash.toml
@@ -4,7 +4,7 @@ integration = ["okta"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 min_stack_version = "8.15.0"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -77,7 +77,7 @@ risk_score = 21
 rule_id = "95b99adc-2cda-11ef-84e1-f661ea17fbce"
 setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "esql"
 
diff --git a/rules/integrations/okta/credential_access_okta_brute_force_or_password_spraying.toml b/rules/integrations/okta/credential_access_okta_brute_force_or_password_spraying.toml
index c98a8ef41d7..4da6f27a44e 100644
--- a/rules/integrations/okta/credential_access_okta_brute_force_or_password_spraying.toml
+++ b/rules/integrations/okta/credential_access_okta_brute_force_or_password_spraying.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/16"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -65,7 +65,7 @@ references = [
 risk_score = 47
 rule_id = "42bf698b-4738-445b-8231-c834ddefd8a0"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/integrations/okta/credential_access_okta_mfa_bombing_via_push_notifications.toml b/rules/integrations/okta/credential_access_okta_mfa_bombing_via_push_notifications.toml
index 842d8fcac81..b32244e0fb3 100644
--- a/rules/integrations/okta/credential_access_okta_mfa_bombing_via_push_notifications.toml
+++ b/rules/integrations/okta/credential_access_okta_mfa_bombing_via_push_notifications.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/18"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -67,7 +67,7 @@ setup = """## Setup
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
 severity = "high"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/integrations/okta/credential_access_okta_multiple_device_token_hashes_for_single_user.toml b/rules/integrations/okta/credential_access_okta_multiple_device_token_hashes_for_single_user.toml
index b7192bba621..97fe212d4c9 100644
--- a/rules/integrations/okta/credential_access_okta_multiple_device_token_hashes_for_single_user.toml
+++ b/rules/integrations/okta/credential_access_okta_multiple_device_token_hashes_for_single_user.toml
@@ -4,7 +4,7 @@ integration = ["okta"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 min_stack_version = "8.15.0"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -80,7 +80,7 @@ risk_score = 21
 rule_id = "23f18264-2d6d-11ef-9413-f661ea17fbce"
 setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "esql"
 
diff --git a/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml b/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml
index 08bbd737342..209f7826d5f 100644
--- a/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml
+++ b/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/05"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -66,7 +66,7 @@ references = [
 risk_score = 73
 rule_id = "97a8e584-fd3b-421f-9b9d-9c9d9e57e9d7"
 severity = "high"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/integrations/okta/credential_access_user_impersonation_access.toml b/rules/integrations/okta/credential_access_user_impersonation_access.toml
index d9e191398dc..812f22c5148 100644
--- a/rules/integrations/okta/credential_access_user_impersonation_access.toml
+++ b/rules/integrations/okta/credential_access_user_impersonation_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/03/22"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -60,7 +60,7 @@ references = [
 risk_score = 73
 rule_id = "cdbebdc1-dc97-43c6-a538-f26a20c0a911"
 severity = "high"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/defense_evasion_attempt_to_deactivate_okta_network_zone.toml b/rules/integrations/okta/defense_evasion_attempt_to_deactivate_okta_network_zone.toml
index 0830aefec4e..88cba8926c8 100644
--- a/rules/integrations/okta/defense_evasion_attempt_to_deactivate_okta_network_zone.toml
+++ b/rules/integrations/okta/defense_evasion_attempt_to_deactivate_okta_network_zone.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Okta",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/okta/defense_evasion_attempt_to_delete_okta_network_zone.toml b/rules/integrations/okta/defense_evasion_attempt_to_delete_okta_network_zone.toml
index 864ddf69f29..c90031f3956 100644
--- a/rules/integrations/okta/defense_evasion_attempt_to_delete_okta_network_zone.toml
+++ b/rules/integrations/okta/defense_evasion_attempt_to_delete_okta_network_zone.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Okta",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
index 4fb816735a9..7ebd94e2ea9 100644
--- a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
+++ b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/11"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Use Case: Threat Detection",
     "Use Case: Identity and Access Audit",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy.toml b/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy.toml
index 5e2252f7d7f..6d408d13c5c 100644
--- a/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy.toml
+++ b/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -74,7 +74,7 @@ references = [
 risk_score = 21
 rule_id = "b719a170-3bdb-4141-b0e3-13e3cf627bfe"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy_rule.toml b/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy_rule.toml
index 01a7abedc81..161e2f3621d 100644
--- a/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy_rule.toml
+++ b/rules/integrations/okta/defense_evasion_okta_attempt_to_deactivate_okta_policy_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -73,7 +73,7 @@ references = [
 risk_score = 47
 rule_id = "cc92c835-da92-45c9-9f29-b4992ad621a0"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Defense Evasion", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Defense Evasion", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy.toml b/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy.toml
index 466d26faf82..d54427942d4 100644
--- a/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy.toml
+++ b/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/28"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -74,7 +74,7 @@ references = [
 risk_score = 47
 rule_id = "b4bb1440-0fcb-4ed1-87e5-b06d58efc5e9"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy_rule.toml b/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy_rule.toml
index 3de8db3c817..1d9deff775d 100644
--- a/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy_rule.toml
+++ b/rules/integrations/okta/defense_evasion_okta_attempt_to_delete_okta_policy_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -73,7 +73,7 @@ references = [
 risk_score = 21
 rule_id = "d5d86bf5-cf0c-4c06-b688-53fdc072fdfd"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_network_zone.toml b/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_network_zone.toml
index 65d4b557659..7e6d206027f 100644
--- a/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_network_zone.toml
+++ b/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_network_zone.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -77,6 +77,7 @@ tags = [
     "Data Source: Okta",
     "Use Case: Network Security Monitoring",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy.toml b/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy.toml
index c5160d23933..47827cd6df2 100644
--- a/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy.toml
+++ b/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -62,7 +62,7 @@ references = [
 risk_score = 21
 rule_id = "6731fbf2-8f28-49ed-9ab9-9a918ceb5a45"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy_rule.toml b/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy_rule.toml
index d77631d5d89..4232a443f8c 100644
--- a/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy_rule.toml
+++ b/rules/integrations/okta/defense_evasion_okta_attempt_to_modify_okta_policy_rule.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -71,7 +71,7 @@ references = [
 risk_score = 21
 rule_id = "000047bb-b27a-47ec-8b62-ef1a5d2c9e19"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Defense Evasion", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Defense Evasion", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/defense_evasion_suspicious_okta_user_password_reset_or_unlock_attempts.toml b/rules/integrations/okta/defense_evasion_suspicious_okta_user_password_reset_or_unlock_attempts.toml
index bb2ca0b61da..1862d7402ff 100644
--- a/rules/integrations/okta/defense_evasion_suspicious_okta_user_password_reset_or_unlock_attempts.toml
+++ b/rules/integrations/okta/defense_evasion_suspicious_okta_user_password_reset_or_unlock_attempts.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -64,7 +64,7 @@ references = [
 risk_score = 47
 rule_id = "e90ee3af-45fc-432e-a850-4a58cf14a457"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/integrations/okta/impact_attempt_to_revoke_okta_api_token.toml b/rules/integrations/okta/impact_attempt_to_revoke_okta_api_token.toml
index bcaec277d8a..d5ab503cf4f 100644
--- a/rules/integrations/okta/impact_attempt_to_revoke_okta_api_token.toml
+++ b/rules/integrations/okta/impact_attempt_to_revoke_okta_api_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -60,7 +60,7 @@ references = [
 risk_score = 21
 rule_id = "676cff2b-450b-4cf1-8ed2-c0c58a4a2dd7"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/impact_okta_attempt_to_deactivate_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_deactivate_okta_application.toml
index 8a5c7a5a910..94eb2871cd6 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_deactivate_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_deactivate_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -64,7 +64,7 @@ references = [
 risk_score = 21
 rule_id = "edb91186-1c7e-4db8-b53e-bfa33a1a0a8a"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
index 6e2b5c49b2c..dc63c7c14ca 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -70,7 +70,7 @@ references = [
 risk_score = 21
 rule_id = "d48e1c13-4aca-4d1f-a7b1-a9161c0ad86f"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
index 16ae233867b..34b39df8b00 100644
--- a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
+++ b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -71,7 +71,7 @@ references = [
 risk_score = 21
 rule_id = "c74fd275-ab2c-4d49-8890-e2943fa65c09"
 severity = "low"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/impact_possible_okta_dos_attack.toml b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
index 573fd04c81b..0d8d629102f 100644
--- a/rules/integrations/okta/impact_possible_okta_dos_attack.toml
+++ b/rules/integrations/okta/impact_possible_okta_dos_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -64,7 +64,7 @@ references = [
 risk_score = 47
 rule_id = "e6e3ecff-03dd-48ec-acbd-54a04de10c68"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/initial_access_first_occurrence_user_session_started_via_proxy.toml b/rules/integrations/okta/initial_access_first_occurrence_user_session_started_via_proxy.toml
index b3bfe959584..b5d000ff9a9 100644
--- a/rules/integrations/okta/initial_access_first_occurrence_user_session_started_via_proxy.toml
+++ b/rules/integrations/okta/initial_access_first_occurrence_user_session_started_via_proxy.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -53,7 +53,7 @@ references = [
 risk_score = 47
 rule_id = "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"
 severity = "medium"
-tags = ["Tactic: Initial Access", "Use Case: Identity and Access Audit", "Data Source: Okta"]
+tags = ["Tactic: Initial Access", "Use Case: Identity and Access Audit", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "new_terms"
 
diff --git a/rules/integrations/okta/initial_access_new_authentication_behavior_detection.toml b/rules/integrations/okta/initial_access_new_authentication_behavior_detection.toml
index 3db6e919e6f..0e18cae8be2 100644
--- a/rules/integrations/okta/initial_access_new_authentication_behavior_detection.toml
+++ b/rules/integrations/okta/initial_access_new_authentication_behavior_detection.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -58,7 +58,7 @@ references = [
 risk_score = 47
 rule_id = "260486ee-7d98-11ee-9599-f661ea17fbcd"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Initial Access", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Initial Access", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
index 303cda49853..73969417992 100644
--- a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
+++ b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -67,7 +67,7 @@ references = [
 risk_score = 47
 rule_id = "ee39a9f7-5a79-4b0a-9815-d36b3cf28d3e"
 severity = "medium"
-tags = ["Tactic: Initial Access", "Use Case: Identity and Access Audit", "Data Source: Okta"]
+tags = ["Tactic: Initial Access", "Use Case: Identity and Access Audit", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
index d3d5f4b3c50..a09dadfa821 100644
--- a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
+++ b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/14"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -62,7 +62,7 @@ references = [
 risk_score = 21
 rule_id = "4edd3e1a-3aa0-499b-8147-4d2ea43b1613"
 severity = "low"
-tags = ["Tactic: Initial Access", "Use Case: Identity and Access Audit", "Data Source: Okta"]
+tags = ["Tactic: Initial Access", "Use Case: Identity and Access Audit", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/initial_access_okta_user_sessions_started_from_different_geolocations.toml b/rules/integrations/okta/initial_access_okta_user_sessions_started_from_different_geolocations.toml
index 0eda4dd19c6..d6ad8c2012e 100644
--- a/rules/integrations/okta/initial_access_okta_user_sessions_started_from_different_geolocations.toml
+++ b/rules/integrations/okta/initial_access_okta_user_sessions_started_from_different_geolocations.toml
@@ -4,7 +4,7 @@ integration = ["okta"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 min_stack_version = "8.15.0"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,7 +73,7 @@ setup = """
 The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 """
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Initial Access"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "esql"
 
diff --git a/rules/integrations/okta/initial_access_sign_in_events_via_third_party_idp.toml b/rules/integrations/okta/initial_access_sign_in_events_via_third_party_idp.toml
index 7a76c2ed1e6..ecebc083544 100644
--- a/rules/integrations/okta/initial_access_sign_in_events_via_third_party_idp.toml
+++ b/rules/integrations/okta/initial_access_sign_in_events_via_third_party_idp.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -66,7 +66,7 @@ references = [
 risk_score = 47
 rule_id = "1ceb05c4-7d25-11ee-9562-f661ea17fbcd"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Initial Access", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Initial Access", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
index 50d00ce27e8..b1b7c5a26b5 100644
--- a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
+++ b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -30,6 +30,7 @@ tags = [
     "Use Case: Threat Detection",
     "Use Case: Identity and Access Audit",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
index 0118eb95674..c89b06d5d7e 100644
--- a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
+++ b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -66,7 +66,7 @@ references = [
 risk_score = 47
 rule_id = "f994964f-6fce-4d75-8e79-e16ccc412588"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Initial Access"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Initial Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
index bed8ce7c0d2..bb7a87f7aa3 100644
--- a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
+++ b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/07"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -70,7 +70,7 @@ references = [
 risk_score = 47
 rule_id = "621e92b6-7e54-11ee-bdc0-f661ea17fbcd"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Lateral Movement"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Lateral Movement", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "threshold"
 
diff --git a/rules/integrations/okta/okta_threatinsight_threat_suspected_promotion.toml b/rules/integrations/okta/okta_threatinsight_threat_suspected_promotion.toml
index 1b44c0779b2..a3ab2ec4300 100644
--- a/rules/integrations/okta/okta_threatinsight_threat_suspected_promotion.toml
+++ b/rules/integrations/okta/okta_threatinsight_threat_suspected_promotion.toml
@@ -3,7 +3,7 @@ creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
 promotion = true
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -39,7 +39,7 @@ risk_score = 47
 rule_id = "6885d2ae-e008-4762-b98a-e8e1cd3a81e9"
 rule_name_override = "okta.display_message"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
index 57dad5b7d14..2e80a066749 100644
--- a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
+++ b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -72,7 +72,7 @@ references = [
 risk_score = 47
 rule_id = "b8075894-0b62-46e5-977c-31275da34419"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Persistence"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
index 2328e248ee4..e939ceec7b4 100644
--- a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
+++ b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -73,7 +73,7 @@ references = [
 risk_score = 47
 rule_id = "f06414a6-f2a4-466d-8eba-10f85e8abf71"
 severity = "medium"
-tags = ["Data Source: Okta", "Use Case: Identity and Access Audit", "Tactic: Persistence"]
+tags = ["Data Source: Okta", "Use Case: Identity and Access Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
index cf94aa3cc04..8339505e3c2 100644
--- a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
+++ b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -71,7 +71,7 @@ references = [
 risk_score = 47
 rule_id = "96b9f4ea-0e8c-435b-8d53-2096e75fcac5"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Persistence"]
+tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
index 085df791309..2e4baf9d11c 100644
--- a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
+++ b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/21"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -72,7 +72,7 @@ references = [
 risk_score = 21
 rule_id = "729aa18d-06a6-41c7-b175-b65b739b1181"
 severity = "low"
-tags = ["Tactic: Persistence", "Use Case: Identity and Access Audit", "Data Source: Okta"]
+tags = ["Tactic: Persistence", "Use Case: Identity and Access Audit", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml b/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml
index 0dcc92b337c..ac824eaaec9 100644
--- a/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml
+++ b/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/05/20"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -67,7 +67,7 @@ risk_score = 21
 rule_id = "cd89602e-9db0-48e3-9391-ae3bf241acd8"
 setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n"
 severity = "low"
-tags = ["Tactic: Persistence", "Use Case: Identity and Access Audit", "Data Source: Okta", "Domain: Cloud"]
+tags = ["Tactic: Persistence", "Use Case: Identity and Access Audit", "Data Source: Okta", "Domain: Cloud", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/integrations/okta/persistence_new_idp_successfully_added_by_admin.toml b/rules/integrations/okta/persistence_new_idp_successfully_added_by_admin.toml
index 7e5928c730b..b8bb28bb33d 100644
--- a/rules/integrations/okta/persistence_new_idp_successfully_added_by_admin.toml
+++ b/rules/integrations/okta/persistence_new_idp_successfully_added_by_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/06"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -62,7 +62,7 @@ references = [
 risk_score = 47
 rule_id = "29b53942-7cd4-11ee-b70e-f661ea17fbcd"
 severity = "medium"
-tags = ["Use Case: Identity and Access Audit", "Tactic: Persistence", "Data Source: Okta"]
+tags = ["Use Case: Identity and Access Audit", "Tactic: Persistence", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
index 78c612b0c10..23f0ae7dbae 100644
--- a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
+++ b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/01"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -72,7 +72,7 @@ references = [
 risk_score = 47
 rule_id = "cd16fb10-0261-46e8-9932-a0336278cdbe"
 severity = "medium"
-tags = ["Tactic: Persistence", "Use Case: Identity and Access Audit", "Data Source: Okta"]
+tags = ["Tactic: Persistence", "Use Case: Identity and Access Audit", "Data Source: Okta", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml b/rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml
index 91fdc0a6283..62e93f7dda2 100644
--- a/rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml
+++ b/rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/09"
 integration = ["endpoint", "okta"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -74,6 +74,7 @@ tags = [
     "Rule Type: Higher-Order Rule",
     "Domain: Endpoint",
     "Domain: Cloud",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
index 47ea1fc13ac..d8058762e9d 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/19"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
index 491f85513b0..7383e362ef0 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
index e45bf61b6a3..ef3e3edf818 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -56,6 +56,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
index 38504b26ddf..204ac3433ab 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,7 @@ tags = [
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
index 16967dc7002..0bec26e8c1a 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
index f2325ae67f0..047992ae1be 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
index be53420fc55..91dda3e569e 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
index aec99bb3320..bb2d33f43f8 100644
--- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
+++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/16"
 integration = ["problemchild", "endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -57,6 +57,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/linux/collection_linux_clipboard_activity.toml b/rules/linux/collection_linux_clipboard_activity.toml
index 95bba749665..a647398f892 100644
--- a/rules/linux/collection_linux_clipboard_activity.toml
+++ b/rules/linux/collection_linux_clipboard_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
index dfb3c49e931..06eacbf8b12 100644
--- a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
+++ b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,6 +26,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 type = "new_terms"
 timestamp_override = "event.ingested"
diff --git a/rules/linux/command_and_control_cat_network_activity.toml b/rules/linux/command_and_control_cat_network_activity.toml
index 5d422e19931..ed31ab5abb9 100644
--- a/rules/linux/command_and_control_cat_network_activity.toml
+++ b/rules/linux/command_and_control_cat_network_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -135,6 +135,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/command_and_control_cupsd_foomatic_rip_netcon.toml b/rules/linux/command_and_control_cupsd_foomatic_rip_netcon.toml
index f7663801b19..30ce455a176 100644
--- a/rules/linux/command_and_control_cupsd_foomatic_rip_netcon.toml
+++ b/rules/linux/command_and_control_cupsd_foomatic_rip_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/30"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -104,6 +104,7 @@ tags = [
     "Use Case: Vulnerability",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/command_and_control_curl_socks_proxy_detected.toml b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
index 9b2a1ef4951..3fb5537d2ee 100644
--- a/rules/linux/command_and_control_curl_socks_proxy_detected.toml
+++ b/rules/linux/command_and_control_curl_socks_proxy_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/command_and_control_ip_forwarding_activity.toml b/rules/linux/command_and_control_ip_forwarding_activity.toml
index bf8de5f97da..08ec19a6e4a 100644
--- a/rules/linux/command_and_control_ip_forwarding_activity.toml
+++ b/rules/linux/command_and_control_ip_forwarding_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/command_and_control_linux_chisel_client_activity.toml b/rules/linux/command_and_control_linux_chisel_client_activity.toml
index b556959d47b..185b7f8f263 100644
--- a/rules/linux/command_and_control_linux_chisel_client_activity.toml
+++ b/rules/linux/command_and_control_linux_chisel_client_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -143,6 +143,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/command_and_control_linux_chisel_server_activity.toml b/rules/linux/command_and_control_linux_chisel_server_activity.toml
index 1ddfe0bd6a4..ec20fa5b9ce 100644
--- a/rules/linux/command_and_control_linux_chisel_server_activity.toml
+++ b/rules/linux/command_and_control_linux_chisel_server_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -143,6 +143,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/command_and_control_linux_kworker_netcon.toml b/rules/linux/command_and_control_linux_kworker_netcon.toml
index 741f5204606..ee8641376f8 100644
--- a/rules/linux/command_and_control_linux_kworker_netcon.toml
+++ b/rules/linux/command_and_control_linux_kworker_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/command_and_control_linux_proxychains_activity.toml b/rules/linux/command_and_control_linux_proxychains_activity.toml
index f2230615631..2c8e1f00649 100644
--- a/rules/linux/command_and_control_linux_proxychains_activity.toml
+++ b/rules/linux/command_and_control_linux_proxychains_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -122,6 +122,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
index 6e8a5b2e0fb..9ce5f65e431 100644
--- a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
+++ b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -117,6 +117,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml b/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml
index fb7dc238406..fa13966a6d2 100644
--- a/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml
+++ b/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -148,6 +148,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml b/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml
index c7132a16ec5..a13003147fa 100644
--- a/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml
+++ b/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -149,6 +149,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/command_and_control_suspicious_network_activity_from_unknown_executable.toml b/rules/linux/command_and_control_suspicious_network_activity_from_unknown_executable.toml
index 4782e104c60..d0a0402788d 100644
--- a/rules/linux/command_and_control_suspicious_network_activity_from_unknown_executable.toml
+++ b/rules/linux/command_and_control_suspicious_network_activity_from_unknown_executable.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -174,6 +174,7 @@ tags = [
     "Tactic: Command and Control",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/command_and_control_tunneling_via_earthworm.toml b/rules/linux/command_and_control_tunneling_via_earthworm.toml
index 01483291592..fafa345dd2e 100644
--- a/rules/linux/command_and_control_tunneling_via_earthworm.toml
+++ b/rules/linux/command_and_control_tunneling_via_earthworm.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -159,6 +159,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/credential_access_collection_sensitive_files.toml b/rules/linux/credential_access_collection_sensitive_files.toml
index 477d208bfc1..8c21bac366e 100644
--- a/rules/linux/credential_access_collection_sensitive_files.toml
+++ b/rules/linux/credential_access_collection_sensitive_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,7 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/credential_access_credential_dumping.toml b/rules/linux/credential_access_credential_dumping.toml
index 2f1a9b806e2..cc7bfb06a26 100644
--- a/rules/linux/credential_access_credential_dumping.toml
+++ b/rules/linux/credential_access_credential_dumping.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/credential_access_gdb_init_process_hooking.toml b/rules/linux/credential_access_gdb_init_process_hooking.toml
index 4ce1847574a..c6934659caa 100644
--- a/rules/linux/credential_access_gdb_init_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_init_process_hooking.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/credential_access_gdb_process_hooking.toml b/rules/linux/credential_access_gdb_process_hooking.toml
index 733abc8e5cc..5e9c2f228c4 100644
--- a/rules/linux/credential_access_gdb_process_hooking.toml
+++ b/rules/linux/credential_access_gdb_process_hooking.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
index c204e3c1610..f570f4601e2 100644
--- a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
+++ b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/credential_access_potential_linux_ssh_bruteforce_external.toml b/rules/linux/credential_access_potential_linux_ssh_bruteforce_external.toml
index 264cbb61e71..4b29c61c900 100644
--- a/rules/linux/credential_access_potential_linux_ssh_bruteforce_external.toml
+++ b/rules/linux/credential_access_potential_linux_ssh_bruteforce_external.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/14"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -77,7 +77,7 @@ Filebeat is a lightweight shipper for forwarding and centralizing log data. Inst
 - To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
 """
 severity = "low"
-tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access"]
+tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/linux/credential_access_potential_linux_ssh_bruteforce_internal.toml b/rules/linux/credential_access_potential_linux_ssh_bruteforce_internal.toml
index dc4b7b8ec79..b11e36ba5ed 100644
--- a/rules/linux/credential_access_potential_linux_ssh_bruteforce_internal.toml
+++ b/rules/linux/credential_access_potential_linux_ssh_bruteforce_internal.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/02/21"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,7 +73,7 @@ Filebeat is a lightweight shipper for forwarding and centralizing log data. Inst
 - To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access"]
+tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
index 2a4535a4b8b..34c9edad13e 100644
--- a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
index 03a188a1017..44329dec53b 100644
--- a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/credential_access_potential_successful_linux_ssh_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_ssh_bruteforce.toml
index 735059d55f4..ef86e1d43e5 100644
--- a/rules/linux/credential_access_potential_successful_linux_ssh_bruteforce.toml
+++ b/rules/linux/credential_access_potential_successful_linux_ssh_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/14"
 integration = ["system"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -79,7 +79,7 @@ Filebeat is a lightweight shipper for forwarding and centralizing log data. Inst
 - To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
 """
 severity = "high"
-tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access"]
+tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/linux/credential_access_proc_credential_dumping.toml b/rules/linux/credential_access_proc_credential_dumping.toml
index 0526af9b514..90b1a9cb404 100644
--- a/rules/linux/credential_access_proc_credential_dumping.toml
+++ b/rules/linux/credential_access_proc_credential_dumping.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/credential_access_ssh_backdoor_log.toml b/rules/linux/credential_access_ssh_backdoor_log.toml
index 7f88aa6724d..a3d9440729c 100644
--- a/rules/linux/credential_access_ssh_backdoor_log.toml
+++ b/rules/linux/credential_access_ssh_backdoor_log.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
index 1bdf501b9bd..f2bea56c426 100644
--- a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
+++ b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
index 4a05e011304..c537294daf0 100644
--- a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
+++ b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
index 6b6960c7882..3ab0e3ff00e 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
index eb1d68943ec..04675023c8e 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
index 634894339c0..fe2829e707f 100644
--- a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
+++ b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
index dd797d137bf..011dc4721f0 100644
--- a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
+++ b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
index df6462bcd16..e56bd0d6452 100644
--- a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
+++ b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_chattr_immutable_file.toml b/rules/linux/defense_evasion_chattr_immutable_file.toml
index 7168ec9cd76..bb66372e2fb 100644
--- a/rules/linux/defense_evasion_chattr_immutable_file.toml
+++ b/rules/linux/defense_evasion_chattr_immutable_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
index b614a0c5179..b7ec71585fa 100644
--- a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
+++ b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
index de653e9127a..dd98206f9e8 100644
--- a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
+++ b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_directory_creation_in_bin.toml b/rules/linux/defense_evasion_directory_creation_in_bin.toml
index 012a8796bb4..ff4dc6d7fab 100644
--- a/rules/linux/defense_evasion_directory_creation_in_bin.toml
+++ b/rules/linux/defense_evasion_directory_creation_in_bin.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_disable_apparmor_attempt.toml b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
index 77800cde4dd..6dbf13a0351 100644
--- a/rules/linux/defense_evasion_disable_apparmor_attempt.toml
+++ b/rules/linux/defense_evasion_disable_apparmor_attempt.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_disable_selinux_attempt.toml b/rules/linux/defense_evasion_disable_selinux_attempt.toml
index dea794c38d8..32fba2c5e81 100644
--- a/rules/linux/defense_evasion_disable_selinux_attempt.toml
+++ b/rules/linux/defense_evasion_disable_selinux_attempt.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
index 3c305c0be1b..49e13f752fe 100644
--- a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
+++ b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
index 28c7e8c4f1b..bc15dc494c8 100644
--- a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
+++ b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
index cd2130276bc..aa321096af7 100644
--- a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
+++ b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_file_deletion_via_shred.toml b/rules/linux/defense_evasion_file_deletion_via_shred.toml
index ae723c77c6f..5391b81c5a8 100644
--- a/rules/linux/defense_evasion_file_deletion_via_shred.toml
+++ b/rules/linux/defense_evasion_file_deletion_via_shred.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_file_mod_writable_dir.toml b/rules/linux/defense_evasion_file_mod_writable_dir.toml
index d3f15f06e23..f87b1240f82 100644
--- a/rules/linux/defense_evasion_file_mod_writable_dir.toml
+++ b/rules/linux/defense_evasion_file_mod_writable_dir.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/defense_evasion_hex_payload_execution.toml b/rules/linux/defense_evasion_hex_payload_execution.toml
index dd7a89f7cdd..13cf5d56690 100644
--- a/rules/linux/defense_evasion_hex_payload_execution.toml
+++ b/rules/linux/defense_evasion_hex_payload_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_hidden_directory_creation.toml b/rules/linux/defense_evasion_hidden_directory_creation.toml
index a7c1dec8061..ed15f89caf3 100644
--- a/rules/linux/defense_evasion_hidden_directory_creation.toml
+++ b/rules/linux/defense_evasion_hidden_directory_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
index e0f48315920..83eff47b826 100644
--- a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
+++ b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_hidden_shared_object.toml b/rules/linux/defense_evasion_hidden_shared_object.toml
index e1f9027057b..1879c8fd90d 100644
--- a/rules/linux/defense_evasion_hidden_shared_object.toml
+++ b/rules/linux/defense_evasion_hidden_shared_object.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
index 36f0dd8f1c1..1bb3cccd863 100644
--- a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
+++ b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,7 +50,8 @@ tags = [
         "OS: Linux",
         "Use Case: Threat Detection",
         "Tactic: Defense Evasion",
-        "Data Source: Elastic Defend"
+        "Data Source: Elastic Defend",
+        "Resources: Investigation Guide"
         ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/defense_evasion_kernel_module_removal.toml b/rules/linux/defense_evasion_kernel_module_removal.toml
index b85f49cf262..c8a356d3c8e 100644
--- a/rules/linux/defense_evasion_kernel_module_removal.toml
+++ b/rules/linux/defense_evasion_kernel_module_removal.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_kthreadd_masquerading.toml b/rules/linux/defense_evasion_kthreadd_masquerading.toml
index 46260ff6bc5..41af91bd706 100644
--- a/rules/linux/defense_evasion_kthreadd_masquerading.toml
+++ b/rules/linux/defense_evasion_kthreadd_masquerading.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_ld_so_creation.toml b/rules/linux/defense_evasion_ld_so_creation.toml
index 2dc3ae25145..fc677858c05 100644
--- a/rules/linux/defense_evasion_ld_so_creation.toml
+++ b/rules/linux/defense_evasion_ld_so_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_log_files_deleted.toml b/rules/linux/defense_evasion_log_files_deleted.toml
index c61f973818c..7c0d2d251fe 100644
--- a/rules/linux/defense_evasion_log_files_deleted.toml
+++ b/rules/linux/defense_evasion_log_files_deleted.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 min_stack_version = "8.13.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_mount_execution.toml b/rules/linux/defense_evasion_mount_execution.toml
index 24904584dbf..f7b5185aa3a 100644
--- a/rules/linux/defense_evasion_mount_execution.toml
+++ b/rules/linux/defense_evasion_mount_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_potential_proot_exploits.toml b/rules/linux/defense_evasion_potential_proot_exploits.toml
index 4482102970a..7986d531651 100644
--- a/rules/linux/defense_evasion_potential_proot_exploits.toml
+++ b/rules/linux/defense_evasion_potential_proot_exploits.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_prctl_process_name_tampering.toml b/rules/linux/defense_evasion_prctl_process_name_tampering.toml
index 00026960761..5e5ccb5c2f0 100644
--- a/rules/linux/defense_evasion_prctl_process_name_tampering.toml
+++ b/rules/linux/defense_evasion_prctl_process_name_tampering.toml
@@ -55,6 +55,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_rename_esxi_files.toml b/rules/linux/defense_evasion_rename_esxi_files.toml
index 32d4fc64605..b033e004796 100644
--- a/rules/linux/defense_evasion_rename_esxi_files.toml
+++ b/rules/linux/defense_evasion_rename_esxi_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_rename_esxi_index_file.toml b/rules/linux/defense_evasion_rename_esxi_index_file.toml
index 308fa865963..db701e9a6c9 100644
--- a/rules/linux/defense_evasion_rename_esxi_index_file.toml
+++ b/rules/linux/defense_evasion_rename_esxi_index_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_root_certificate_installation.toml b/rules/linux/defense_evasion_root_certificate_installation.toml
index 997a4466dfc..e29ffb290fa 100644
--- a/rules/linux/defense_evasion_root_certificate_installation.toml
+++ b/rules/linux/defense_evasion_root_certificate_installation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
index 810f587e6a3..185877f5618 100644
--- a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
+++ b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.16.2 for the SentinelOne Integration."
 min_stack_version = "8.16.2"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,7 +54,8 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
-    "Data Source: SentinelOne"
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_ssl_certificate_deletion.toml b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
index 7b38a52df1d..da071c01019 100644
--- a/rules/linux/defense_evasion_ssl_certificate_deletion.toml
+++ b/rules/linux/defense_evasion_ssl_certificate_deletion.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
index 35fcf7b4f53..643e151226b 100644
--- a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
+++ b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/defense_evasion_unusual_preload_env_vars.toml b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
index 9a372cb16a0..8896b4c5f51 100644
--- a/rules/linux/defense_evasion_unusual_preload_env_vars.toml
+++ b/rules/linux/defense_evasion_unusual_preload_env_vars.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml
index be71bb38643..b2ab0c4bdac 100644
--- a/rules/linux/discovery_dynamic_linker_via_od.toml
+++ b/rules/linux/discovery_dynamic_linker_via_od.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml
index 121356c35ee..6e4547b09f7 100644
--- a/rules/linux/discovery_esxi_software_via_find.toml
+++ b/rules/linux/discovery_esxi_software_via_find.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml
index ef4c8aa531d..4fa7fedc1e3 100644
--- a/rules/linux/discovery_esxi_software_via_grep.toml
+++ b/rules/linux/discovery_esxi_software_via_grep.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_kernel_module_enumeration.toml b/rules/linux/discovery_kernel_module_enumeration.toml
index 7d4774a22d3..69eac0b8c26 100644
--- a/rules/linux/discovery_kernel_module_enumeration.toml
+++ b/rules/linux/discovery_kernel_module_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/discovery_linux_hping_activity.toml b/rules/linux/discovery_linux_hping_activity.toml
index aaf4ed07a01..79193866414 100644
--- a/rules/linux/discovery_linux_hping_activity.toml
+++ b/rules/linux/discovery_linux_hping_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_linux_nping_activity.toml b/rules/linux/discovery_linux_nping_activity.toml
index b6068c6aff3..cdb26df5e17 100644
--- a/rules/linux/discovery_linux_nping_activity.toml
+++ b/rules/linux/discovery_linux_nping_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -74,6 +74,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml
index 13748e5efde..4f7d00fa38e 100644
--- a/rules/linux/discovery_pam_version_discovery.toml
+++ b/rules/linux/discovery_pam_version_discovery.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_ping_sweep_detected.toml b/rules/linux/discovery_ping_sweep_detected.toml
index 8ed9a72cdf4..6819c66e02b 100644
--- a/rules/linux/discovery_ping_sweep_detected.toml
+++ b/rules/linux/discovery_ping_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml
index 82a0ad55fb9..495e0053a07 100644
--- a/rules/linux/discovery_private_key_password_searching_activity.toml
+++ b/rules/linux/discovery_private_key_password_searching_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,7 +53,8 @@ tags = [
         "Data Source: Elastic Defend",
         "Data Source: Crowdstrike",
         "Data Source: SentinelOne",
-        "Data Source: Elastic Endgame"
+        "Data Source: Elastic Endgame",
+        "Resources: Investigation Guide"
         ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_proc_maps_read.toml b/rules/linux/discovery_proc_maps_read.toml
index af471cbf7a4..1b628573d2d 100644
--- a/rules/linux/discovery_proc_maps_read.toml
+++ b/rules/linux/discovery_proc_maps_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_process_capabilities.toml b/rules/linux/discovery_process_capabilities.toml
index 83b1f104011..5d1ceb285e6 100644
--- a/rules/linux/discovery_process_capabilities.toml
+++ b/rules/linux/discovery_process_capabilities.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_pspy_process_monitoring_detected.toml b/rules/linux/discovery_pspy_process_monitoring_detected.toml
index d8e0a811cc4..a20064a1f1c 100644
--- a/rules/linux/discovery_pspy_process_monitoring_detected.toml
+++ b/rules/linux/discovery_pspy_process_monitoring_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/discovery_security_file_access_via_common_utility.toml b/rules/linux/discovery_security_file_access_via_common_utility.toml
index 49ce45bd63b..3d11cf452c3 100644
--- a/rules/linux/discovery_security_file_access_via_common_utility.toml
+++ b/rules/linux/discovery_security_file_access_via_common_utility.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,7 +53,8 @@ tags = [
         "Data Source: Elastic Defend",
         "Data Source: Crowdstrike",
         "Data Source: SentinelOne",
-        "Data Source: Elastic Endgame"
+        "Data Source: Elastic Endgame",
+        "Resources: Investigation Guide"
         ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_sudo_allowed_command_enumeration.toml b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
index e2b6e041ef7..4d5f05ee658 100644
--- a/rules/linux/discovery_sudo_allowed_command_enumeration.toml
+++ b/rules/linux/discovery_sudo_allowed_command_enumeration.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_suid_sguid_enumeration.toml b/rules/linux/discovery_suid_sguid_enumeration.toml
index a7570e0f87a..35482e28743 100644
--- a/rules/linux/discovery_suid_sguid_enumeration.toml
+++ b/rules/linux/discovery_suid_sguid_enumeration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/24"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Tactic: Discovery",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml
index e083438be4c..d3e44c6ac62 100644
--- a/rules/linux/discovery_suspicious_memory_grep_activity.toml
+++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_suspicious_which_command_execution.toml b/rules/linux/discovery_suspicious_which_command_execution.toml
index 72d1f7b8608..ce077dd902d 100644
--- a/rules/linux/discovery_suspicious_which_command_execution.toml
+++ b/rules/linux/discovery_suspicious_which_command_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_unusual_user_enumeration_via_id.toml b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
index 9feea1a94fc..cead4910326 100644
--- a/rules/linux/discovery_unusual_user_enumeration_via_id.toml
+++ b/rules/linux/discovery_unusual_user_enumeration_via_id.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/discovery_virtual_machine_fingerprinting.toml b/rules/linux/discovery_virtual_machine_fingerprinting.toml
index 2e95e8ad739..395d90f67f5 100644
--- a/rules/linux/discovery_virtual_machine_fingerprinting.toml
+++ b/rules/linux/discovery_virtual_machine_fingerprinting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,7 @@ tags = [
     "Tactic: Discovery",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml
index d4f0fb487c2..bfeef246d2a 100644
--- a/rules/linux/discovery_yum_dnf_plugin_detection.toml
+++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml
index d51248099e6..00e2a0f6f3c 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -107,6 +107,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml
index 21f230e9eb9..680ec8ef8ba 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/07"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -106,6 +106,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml
index 7a6a95cdea9..fb4fcdc909e 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -109,6 +109,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml
index bc76b2de76e..db4f72abaa1 100644
--- a/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml
+++ b/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/07"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -110,6 +110,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
index 03554de5467..9397f734f14 100644
--- a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
+++ b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Use Case: Vulnerability",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
index 289d1054895..c555a3312c1 100644
--- a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
+++ b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_file_execution_followed_by_deletion.toml b/rules/linux/execution_file_execution_followed_by_deletion.toml
index eee7781d252..dc3d20a657e 100644
--- a/rules/linux/execution_file_execution_followed_by_deletion.toml
+++ b/rules/linux/execution_file_execution_followed_by_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml
index 8b16f2b6c8a..a29e2ce0515 100644
--- a/rules/linux/execution_interpreter_tty_upgrade.toml
+++ b/rules/linux/execution_interpreter_tty_upgrade.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml
index afbd8fe315f..d0b9ca17f43 100644
--- a/rules/linux/execution_nc_listener_via_rlwrap.toml
+++ b/rules/linux/execution_nc_listener_via_rlwrap.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
index e39c69461c4..184a0a06b5d 100644
--- a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
+++ b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_network_event_post_compilation.toml b/rules/linux/execution_network_event_post_compilation.toml
index 06d4633f0bc..50f27e2bf4c 100644
--- a/rules/linux/execution_network_event_post_compilation.toml
+++ b/rules/linux/execution_network_event_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/execution_perl_tty_shell.toml b/rules/linux/execution_perl_tty_shell.toml
index 891bb73fa21..6aa0c5830f8 100644
--- a/rules/linux/execution_perl_tty_shell.toml
+++ b/rules/linux/execution_perl_tty_shell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/04/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/linux/execution_potential_hack_tool_executed.toml b/rules/linux/execution_potential_hack_tool_executed.toml
index 426d7dbfe65..d83be6e0342 100644
--- a/rules/linux/execution_potential_hack_tool_executed.toml
+++ b/rules/linux/execution_potential_hack_tool_executed.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_potentially_overly_permissive_container_creation.toml b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
index 062e1c5aafe..ec83824f0db 100644
--- a/rules/linux/execution_potentially_overly_permissive_container_creation.toml
+++ b/rules/linux/execution_potentially_overly_permissive_container_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/execution_process_started_from_process_id_file.toml b/rules/linux/execution_process_started_from_process_id_file.toml
index ba91f9a3164..cf89945fd35 100644
--- a/rules/linux/execution_process_started_from_process_id_file.toml
+++ b/rules/linux/execution_process_started_from_process_id_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/11"
 integration = ["endpoint", "auditd_manager", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_process_started_in_shared_memory_directory.toml b/rules/linux/execution_process_started_in_shared_memory_directory.toml
index 876016de207..d70310f3aa0 100644
--- a/rules/linux/execution_process_started_in_shared_memory_directory.toml
+++ b/rules/linux/execution_process_started_in_shared_memory_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,7 @@ tags = [
     "Threat: BPFDoor",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml
index 31bfe644c49..1ab71d1ab2a 100644
--- a/rules/linux/execution_python_tty_shell.toml
+++ b/rules/linux/execution_python_tty_shell.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml
index be43eb7acd8..84d53f57b5c 100644
--- a/rules/linux/execution_python_webserver_spawned.toml
+++ b/rules/linux/execution_python_webserver_spawned.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_remote_code_execution_via_postgresql.toml b/rules/linux/execution_remote_code_execution_via_postgresql.toml
index ff5d958392b..e67bf9a0b80 100644
--- a/rules/linux/execution_remote_code_execution_via_postgresql.toml
+++ b/rules/linux/execution_remote_code_execution_via_postgresql.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_shell_evasion_linux_binary.toml b/rules/linux/execution_shell_evasion_linux_binary.toml
index d3fb45fdd5f..6ef090c859a 100644
--- a/rules/linux/execution_shell_evasion_linux_binary.toml
+++ b/rules/linux/execution_shell_evasion_linux_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -133,6 +133,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml
index 8cff0f7485d..a2787024de8 100644
--- a/rules/linux/execution_shell_openssl_client_or_server.toml
+++ b/rules/linux/execution_shell_openssl_client_or_server.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,7 +54,8 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
-    "Data Source: SentinelOne"
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml
index 13f06135389..482507d447f 100644
--- a/rules/linux/execution_shell_via_background_process.toml
+++ b/rules/linux/execution_shell_via_background_process.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
index b8541ff2302..cc04183c1bd 100644
--- a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
+++ b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/execution_shell_via_java_revshell_linux.toml b/rules/linux/execution_shell_via_java_revshell_linux.toml
index c29671a3c8f..e1dbc140954 100644
--- a/rules/linux/execution_shell_via_java_revshell_linux.toml
+++ b/rules/linux/execution_shell_via_java_revshell_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
index 55cf9c66754..cae82200bc1 100644
--- a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
+++ b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/execution_shell_via_meterpreter_linux.toml b/rules/linux/execution_shell_via_meterpreter_linux.toml
index 26febaa20a4..c75cdf995e1 100644
--- a/rules/linux/execution_shell_via_meterpreter_linux.toml
+++ b/rules/linux/execution_shell_via_meterpreter_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_shell_via_suspicious_binary.toml b/rules/linux/execution_shell_via_suspicious_binary.toml
index 176aa0254ee..0fe844990be 100644
--- a/rules/linux/execution_shell_via_suspicious_binary.toml
+++ b/rules/linux/execution_shell_via_suspicious_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
index 9370122adc7..8a7e50d193d 100644
--- a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
index 5f79dbb864d..99ad762685a 100644
--- a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
+++ b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/04"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
index 648d90ea01b..08691468699 100644
--- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
+++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_suspicious_executable_running_system_commands.toml b/rules/linux/execution_suspicious_executable_running_system_commands.toml
index cb652005917..a6130d42877 100644
--- a/rules/linux/execution_suspicious_executable_running_system_commands.toml
+++ b/rules/linux/execution_suspicious_executable_running_system_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml
index d92b5fae400..f07b9025d8b 100644
--- a/rules/linux/execution_suspicious_mining_process_creation_events.toml
+++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml
index f56b1482b36..d484d173106 100644
--- a/rules/linux/execution_tc_bpf_filter.toml
+++ b/rules/linux/execution_tc_bpf_filter.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml
index 33ab7f3c943..a5e42ae18ba 100644
--- a/rules/linux/execution_unix_socket_communication.toml
+++ b/rules/linux/execution_unix_socket_communication.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
index 64b5b19eee7..39646ab47e1 100644
--- a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
+++ b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/13"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
index 816f87d6832..fa5595870a5 100644
--- a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
+++ b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,7 +54,8 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
-    "Data Source: Elastic Endgame"
+    "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/impact_data_encrypted_via_openssl.toml b/rules/linux/impact_data_encrypted_via_openssl.toml
index cbe5b83fca8..e994de1025d 100644
--- a/rules/linux/impact_data_encrypted_via_openssl.toml
+++ b/rules/linux/impact_data_encrypted_via_openssl.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Impact",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/impact_esxi_process_kill.toml b/rules/linux/impact_esxi_process_kill.toml
index c6b37b2f81d..149015fce4a 100644
--- a/rules/linux/impact_esxi_process_kill.toml
+++ b/rules/linux/impact_esxi_process_kill.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Impact",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/impact_memory_swap_modification.toml b/rules/linux/impact_memory_swap_modification.toml
index c8fb7425777..941216f631f 100644
--- a/rules/linux/impact_memory_swap_modification.toml
+++ b/rules/linux/impact_memory_swap_modification.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/impact_potential_linux_ransomware_note_detected.toml b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
index 007499c0b85..3ff4f9b3e8c 100644
--- a/rules/linux/impact_potential_linux_ransomware_note_detected.toml
+++ b/rules/linux/impact_potential_linux_ransomware_note_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Impact",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/lateral_movement_ssh_it_worm_download.toml b/rules/linux/lateral_movement_ssh_it_worm_download.toml
index 887eb0b2339..cd5672bdc5b 100644
--- a/rules/linux/lateral_movement_ssh_it_worm_download.toml
+++ b/rules/linux/lateral_movement_ssh_it_worm_download.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/lateral_movement_telnet_network_activity_external.toml b/rules/linux/lateral_movement_telnet_network_activity_external.toml
index 5c818c52068..1d83b8fdd41 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_external.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_external.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/lateral_movement_telnet_network_activity_internal.toml b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
index 6111d1a126b..f3935e9cdb8 100644
--- a/rules/linux/lateral_movement_telnet_network_activity_internal.toml
+++ b/rules/linux/lateral_movement_telnet_network_activity_internal.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -73,6 +73,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/persistence_apt_package_manager_execution.toml b/rules/linux/persistence_apt_package_manager_execution.toml
index 74f1690bb5e..2781a04e6fb 100644
--- a/rules/linux/persistence_apt_package_manager_execution.toml
+++ b/rules/linux/persistence_apt_package_manager_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/persistence_apt_package_manager_file_creation.toml b/rules/linux/persistence_apt_package_manager_file_creation.toml
index 4788f0e5b2e..70852153178 100644
--- a/rules/linux/persistence_apt_package_manager_file_creation.toml
+++ b/rules/linux/persistence_apt_package_manager_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_apt_package_manager_netcon.toml b/rules/linux/persistence_apt_package_manager_netcon.toml
index e3161b80183..6b806e42ebe 100644
--- a/rules/linux/persistence_apt_package_manager_netcon.toml
+++ b/rules/linux/persistence_apt_package_manager_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Tactic: Command and Control",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/persistence_at_job_creation.toml b/rules/linux/persistence_at_job_creation.toml
index 0d946a268a0..4045db7067f 100644
--- a/rules/linux/persistence_at_job_creation.toml
+++ b/rules/linux/persistence_at_job_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_chkconfig_service_add.toml b/rules/linux/persistence_chkconfig_service_add.toml
index 3387c9b8070..2dc629d7753 100644
--- a/rules/linux/persistence_chkconfig_service_add.toml
+++ b/rules/linux/persistence_chkconfig_service_add.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -172,6 +172,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_credential_access_modify_ssh_binaries.toml b/rules/linux/persistence_credential_access_modify_ssh_binaries.toml
index a92a8823fd0..b46b27f7090 100644
--- a/rules/linux/persistence_credential_access_modify_ssh_binaries.toml
+++ b/rules/linux/persistence_credential_access_modify_ssh_binaries.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -154,6 +154,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/linux/persistence_cron_job_creation.toml b/rules/linux/persistence_cron_job_creation.toml
index e03f4d78270..57ef364412d 100644
--- a/rules/linux/persistence_cron_job_creation.toml
+++ b/rules/linux/persistence_cron_job_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -173,6 +173,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
index 0a3cbb47178..44a21977589 100644
--- a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
index 5bf37a2f276..7820af235f0 100644
--- a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/persistence_dpkg_unusual_execution.toml b/rules/linux/persistence_dpkg_unusual_execution.toml
index 9eb259a3989..14464d5c03e 100644
--- a/rules/linux/persistence_dpkg_unusual_execution.toml
+++ b/rules/linux/persistence_dpkg_unusual_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,7 +50,8 @@ tags = [
         "OS: Linux",
         "Use Case: Threat Detection",
         "Tactic: Persistence",
-        "Data Source: Elastic Defend"
+        "Data Source: Elastic Defend",
+        "Resources: Investigation Guide"
         ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_dynamic_linker_backup.toml b/rules/linux/persistence_dynamic_linker_backup.toml
index c0a5aaa3e69..cfb5293da07 100644
--- a/rules/linux/persistence_dynamic_linker_backup.toml
+++ b/rules/linux/persistence_dynamic_linker_backup.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -164,6 +164,7 @@ tags = [
     "Threat: Orbit",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/persistence_etc_file_creation.toml b/rules/linux/persistence_etc_file_creation.toml
index b9ef7388dae..40321eb7785 100644
--- a/rules/linux/persistence_etc_file_creation.toml
+++ b/rules/linux/persistence_etc_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -176,6 +176,7 @@ tags = [
     "Threat: Lightning Framework",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_git_hook_execution.toml b/rules/linux/persistence_git_hook_execution.toml
index cb00e5c6320..ca06e3deee9 100644
--- a/rules/linux/persistence_git_hook_execution.toml
+++ b/rules/linux/persistence_git_hook_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/persistence_git_hook_file_creation.toml b/rules/linux/persistence_git_hook_file_creation.toml
index 7474b87ec13..3ba54dfdbdc 100644
--- a/rules/linux/persistence_git_hook_file_creation.toml
+++ b/rules/linux/persistence_git_hook_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_git_hook_netcon.toml b/rules/linux/persistence_git_hook_netcon.toml
index ba0e65d8608..1c2911e5164 100644
--- a/rules/linux/persistence_git_hook_netcon.toml
+++ b/rules/linux/persistence_git_hook_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/persistence_git_hook_process_execution.toml b/rules/linux/persistence_git_hook_process_execution.toml
index c6a0059c8bf..dd246b05bf3 100644
--- a/rules/linux/persistence_git_hook_process_execution.toml
+++ b/rules/linux/persistence_git_hook_process_execution.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_insmod_kernel_module_load.toml b/rules/linux/persistence_insmod_kernel_module_load.toml
index a0069bb79aa..3a6c21a8e2e 100644
--- a/rules/linux/persistence_insmod_kernel_module_load.toml
+++ b/rules/linux/persistence_insmod_kernel_module_load.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -158,6 +158,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Auditd Manager",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_kde_autostart_modification.toml b/rules/linux/persistence_kde_autostart_modification.toml
index 4fbc4c9c845..0bd8b85a51b 100644
--- a/rules/linux/persistence_kde_autostart_modification.toml
+++ b/rules/linux/persistence_kde_autostart_modification.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -206,6 +206,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_kernel_driver_load.toml b/rules/linux/persistence_kernel_driver_load.toml
index c1c887d88be..0f7b646be9e 100644
--- a/rules/linux/persistence_kernel_driver_load.toml
+++ b/rules/linux/persistence_kernel_driver_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -48,6 +48,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_kernel_driver_load_by_non_root.toml b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
index 7bac3a551c5..ebfdbbbb891 100644
--- a/rules/linux/persistence_kernel_driver_load_by_non_root.toml
+++ b/rules/linux/persistence_kernel_driver_load_by_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/10"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_kernel_object_file_creation.toml b/rules/linux/persistence_kernel_object_file_creation.toml
index 14738c5578c..9bceb687a86 100644
--- a/rules/linux/persistence_kernel_object_file_creation.toml
+++ b/rules/linux/persistence_kernel_object_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/persistence_kworker_file_creation.toml b/rules/linux/persistence_kworker_file_creation.toml
index ee97df97488..96bdfd9439d 100644
--- a/rules/linux/persistence_kworker_file_creation.toml
+++ b/rules/linux/persistence_kworker_file_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -163,6 +163,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_lkm_configuration_file_creation.toml b/rules/linux/persistence_lkm_configuration_file_creation.toml
index 5204c3afbde..cb1227acd58 100644
--- a/rules/linux/persistence_lkm_configuration_file_creation.toml
+++ b/rules/linux/persistence_lkm_configuration_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation.toml b/rules/linux/persistence_pluggable_authentication_module_creation.toml
index 2e555818a5b..e01f5e22535 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,7 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
index fd6b200ebd6..a760ebe6b40 100644
--- a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -39,6 +39,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_pluggable_authentication_module_source_download.toml b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
index 2dc3d976ba8..5ef5cecbeb0 100644
--- a/rules/linux/persistence_pluggable_authentication_module_source_download.toml
+++ b/rules/linux/persistence_pluggable_authentication_module_source_download.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
index 43d572e49ef..1fc8aaf5616 100644
--- a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
+++ b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -61,6 +61,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_process_capability_set_via_setcap.toml b/rules/linux/persistence_process_capability_set_via_setcap.toml
index 032fdf9557e..7064135fca3 100644
--- a/rules/linux/persistence_process_capability_set_via_setcap.toml
+++ b/rules/linux/persistence_process_capability_set_via_setcap.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,7 +56,8 @@ tags = [
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
-    "Data Source: SentinelOne"
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_rc_local_error_via_syslog.toml b/rules/linux/persistence_rc_local_error_via_syslog.toml
index dd29fda0cd7..893cbeabf66 100644
--- a/rules/linux/persistence_rc_local_error_via_syslog.toml
+++ b/rules/linux/persistence_rc_local_error_via_syslog.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -48,7 +48,7 @@ Filebeat is a lightweight shipper for forwarding and centralizing log data. Inst
 - To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
 """
 severity = "low"
-tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Persistence"]
+tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Persistence", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/linux/persistence_rc_local_service_already_running.toml b/rules/linux/persistence_rc_local_service_already_running.toml
index ed74122563c..a8e0c2205b7 100644
--- a/rules/linux/persistence_rc_local_service_already_running.toml
+++ b/rules/linux/persistence_rc_local_service_already_running.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
index 8d28d3d7ccb..02a4eb51f36 100644
--- a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
+++ b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/persistence_setuid_setgid_capability_set.toml b/rules/linux/persistence_setuid_setgid_capability_set.toml
index bc082eec7d3..6e469984829 100644
--- a/rules/linux/persistence_setuid_setgid_capability_set.toml
+++ b/rules/linux/persistence_setuid_setgid_capability_set.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -142,6 +142,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_shadow_file_modification.toml b/rules/linux/persistence_shadow_file_modification.toml
index 2c30428a9d9..035dc8117e3 100644
--- a/rules/linux/persistence_shadow_file_modification.toml
+++ b/rules/linux/persistence_shadow_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_shared_object_creation.toml b/rules/linux/persistence_shared_object_creation.toml
index aa8ed2edfb4..26a840bbde4 100644
--- a/rules/linux/persistence_shared_object_creation.toml
+++ b/rules/linux/persistence_shared_object_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -156,6 +156,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/persistence_shell_configuration_modification.toml b/rules/linux/persistence_shell_configuration_modification.toml
index 78ec71b2d91..ada194ba2c4 100644
--- a/rules/linux/persistence_shell_configuration_modification.toml
+++ b/rules/linux/persistence_shell_configuration_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_simple_web_server_connection_accepted.toml b/rules/linux/persistence_simple_web_server_connection_accepted.toml
index d327800db99..c729d650694 100644
--- a/rules/linux/persistence_simple_web_server_connection_accepted.toml
+++ b/rules/linux/persistence_simple_web_server_connection_accepted.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_simple_web_server_creation.toml b/rules/linux/persistence_simple_web_server_creation.toml
index 559b955691d..9106ffae423 100644
--- a/rules/linux/persistence_simple_web_server_creation.toml
+++ b/rules/linux/persistence_simple_web_server_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_ssh_key_generation.toml b/rules/linux/persistence_ssh_key_generation.toml
index 85ba3202368..15c65e37d54 100644
--- a/rules/linux/persistence_ssh_key_generation.toml
+++ b/rules/linux/persistence_ssh_key_generation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_ssh_netcon.toml b/rules/linux/persistence_ssh_netcon.toml
index 4ea9b974a71..abf7fbba0c1 100644
--- a/rules/linux/persistence_ssh_netcon.toml
+++ b/rules/linux/persistence_ssh_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,8 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Persistence",
-    "Data Source: Elastic Defend"
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide"
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/persistence_ssh_via_backdoored_system_user.toml b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
index a8d8c88700d..71f62698644 100644
--- a/rules/linux/persistence_ssh_via_backdoored_system_user.toml
+++ b/rules/linux/persistence_ssh_via_backdoored_system_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -49,7 +49,8 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
-    "Data Source: System"
+    "Data Source: System",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_suspicious_file_opened_through_editor.toml b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
index 6d47ca4ea16..f3e87559052 100644
--- a/rules/linux/persistence_suspicious_file_opened_through_editor.toml
+++ b/rules/linux/persistence_suspicious_file_opened_through_editor.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -33,6 +33,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
index 6e638888e8d..dafd11750df 100644
--- a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
+++ b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -31,6 +31,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_systemd_generator_creation.toml b/rules/linux/persistence_systemd_generator_creation.toml
index 540474a01f4..2995631129c 100644
--- a/rules/linux/persistence_systemd_generator_creation.toml
+++ b/rules/linux/persistence_systemd_generator_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_systemd_netcon.toml b/rules/linux/persistence_systemd_netcon.toml
index 00e74ec28b7..a47b7303adb 100644
--- a/rules/linux/persistence_systemd_netcon.toml
+++ b/rules/linux/persistence_systemd_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Command and Control",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''
diff --git a/rules/linux/persistence_systemd_service_creation.toml b/rules/linux/persistence_systemd_service_creation.toml
index 0d044def1ad..84b753d78c0 100644
--- a/rules/linux/persistence_systemd_service_creation.toml
+++ b/rules/linux/persistence_systemd_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -182,6 +182,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_systemd_service_started.toml b/rules/linux/persistence_systemd_service_started.toml
index 5c7ffea2221..7b404cd2441 100644
--- a/rules/linux/persistence_systemd_service_started.toml
+++ b/rules/linux/persistence_systemd_service_started.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -172,6 +172,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/persistence_tainted_kernel_module_load.toml b/rules/linux/persistence_tainted_kernel_module_load.toml
index 41ea4cfbc52..e826ba5b4ea 100644
--- a/rules/linux/persistence_tainted_kernel_module_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/23"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
index 73efa7f0210..8c10bfa4f30 100644
--- a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
+++ b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -47,6 +47,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/linux/persistence_udev_rule_creation.toml b/rules/linux/persistence_udev_rule_creation.toml
index 3d9a8c2b3c8..c055885cddf 100644
--- a/rules/linux/persistence_udev_rule_creation.toml
+++ b/rules/linux/persistence_udev_rule_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_unusual_pam_grantor.toml b/rules/linux/persistence_unusual_pam_grantor.toml
index 813d15234e8..1ae030ca4dc 100644
--- a/rules/linux/persistence_unusual_pam_grantor.toml
+++ b/rules/linux/persistence_unusual_pam_grantor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/06"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -38,6 +38,7 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Persistence",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/persistence_unusual_sshd_child_process.toml b/rules/linux/persistence_unusual_sshd_child_process.toml
index e7f6343af34..6e6dafb4df6 100644
--- a/rules/linux/persistence_unusual_sshd_child_process.toml
+++ b/rules/linux/persistence_unusual_sshd_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,8 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Persistence",
-    "Data Source: Elastic Defend"
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/persistence_user_or_group_creation_or_modification.toml b/rules/linux/persistence_user_or_group_creation_or_modification.toml
index d7a78e5bfc3..b34dfd36542 100644
--- a/rules/linux/persistence_user_or_group_creation_or_modification.toml
+++ b/rules/linux/persistence_user_or_group_creation_or_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/20"
 integration = ["auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_xdg_autostart_netcon.toml b/rules/linux/persistence_xdg_autostart_netcon.toml
index c97c3d23d0c..a68745b39b8 100644
--- a/rules/linux/persistence_xdg_autostart_netcon.toml
+++ b/rules/linux/persistence_xdg_autostart_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -71,6 +71,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
index c45e1ede149..44b91716c94 100644
--- a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
+++ b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
index cf37595f58b..5a802bc7ad8 100644
--- a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
+++ b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_container_util_misconfiguration.toml b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
index d22c727c589..42f91415ab3 100644
--- a/rules/linux/privilege_escalation_container_util_misconfiguration.toml
+++ b/rules/linux/privilege_escalation_container_util_misconfiguration.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Domain: Container",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_dac_permissions.toml b/rules/linux/privilege_escalation_dac_permissions.toml
index 08ae80fbe46..9cdfecf5812 100644
--- a/rules/linux/privilege_escalation_dac_permissions.toml
+++ b/rules/linux/privilege_escalation_dac_permissions.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
index 25bce6b66bc..342ea671a06 100644
--- a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
+++ b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
index 058f0290879..f0581fb23e5 100644
--- a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
+++ b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -67,6 +67,7 @@ tags = [
     "Domain: Container",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_enlightenment_window_manager.toml b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
index a9b13ac91a0..6b7dc4ae353 100644
--- a/rules/linux/privilege_escalation_enlightenment_window_manager.toml
+++ b/rules/linux/privilege_escalation_enlightenment_window_manager.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
index 681c3508a7f..5d3662cea93 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
index eadd862854e..1b5d1c83725 100644
--- a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
+++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/09"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_kworker_uid_elevation.toml b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
index 46294053583..bbfc3315906 100644
--- a/rules/linux/privilege_escalation_kworker_uid_elevation.toml
+++ b/rules/linux/privilege_escalation_kworker_uid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
index 680b45a5e06..1bfc505a5b3 100644
--- a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
+++ b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
index 2fde4756524..146c9775d1d 100644
--- a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
+++ b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
index e937ec0f857..92e93513b1e 100644
--- a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
+++ b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/27"
 integration = ["endpoint", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
index 6c572385f26..487698dcb69 100644
--- a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
+++ b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -65,6 +65,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
index 470fa194e65..db331d56794 100644
--- a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
+++ b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,6 +66,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
index c1386ba62f3..218aa7d261d 100644
--- a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
+++ b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
index 05030ecbcfd..abc06624f8a 100644
--- a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
+++ b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
index 5f384e72791..0b74052275b 100644
--- a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
+++ b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
index bbea8014783..57ae0855eb1 100644
--- a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
+++ b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/12/11"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -35,6 +35,7 @@ tags = [
     "Tactic: Initial Access",
     "Use Case: Vulnerability",
     "Rule Type: Higher-Order Rule",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
index 7cc11082420..fabd017de00 100644
--- a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
+++ b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -58,6 +58,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
index f45fa1114a4..d3f6d037f39 100644
--- a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
+++ b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -56,6 +56,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
index 37611003f55..3ea1234fb5f 100644
--- a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
+++ b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_shadow_file_read.toml b/rules/linux/privilege_escalation_shadow_file_read.toml
index eec38d4a63c..3a3262b43e5 100644
--- a/rules/linux/privilege_escalation_shadow_file_read.toml
+++ b/rules/linux/privilege_escalation_shadow_file_read.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
index c0f652f7a19..b3c4583f75f 100644
--- a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
+++ b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -59,6 +59,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_sudo_hijacking.toml b/rules/linux/privilege_escalation_sudo_hijacking.toml
index 4080d24f4c0..79a94ff6f2c 100644
--- a/rules/linux/privilege_escalation_sudo_hijacking.toml
+++ b/rules/linux/privilege_escalation_sudo_hijacking.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
index 5f23f025156..b0172b2cd1d 100644
--- a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
+++ b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
@@ -4,7 +4,7 @@ integration = ["endpoint"]
 maturity = "production"
 min_stack_version = "8.16.0"
 min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
index 2d336bc0531..016b5c7c445 100644
--- a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
+++ b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
index dfc3e5176ba..e2c0f653c3d 100644
--- a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
index 296f34bc72b..f16ef0d7c7b 100644
--- a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
+++ b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/22"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -75,6 +75,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
index f77e058032e..d9f73acf8c0 100644
--- a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
+++ b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/08"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_uid_change_post_compilation.toml b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
index fda0a412f3c..d9cbb6f9bb2 100644
--- a/rules/linux/privilege_escalation_uid_change_post_compilation.toml
+++ b/rules/linux/privilege_escalation_uid_change_post_compilation.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
index 0223be9bda7..f132df59d5a 100644
--- a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
+++ b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
index 4f6ff76217b..31642cba6d3 100644
--- a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
+++ b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,6 +70,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/privilege_escalation_writable_docker_socket.toml b/rules/linux/privilege_escalation_writable_docker_socket.toml
index 546803becf9..b635512f9d5 100644
--- a/rules/linux/privilege_escalation_writable_docker_socket.toml
+++ b/rules/linux/privilege_escalation_writable_docker_socket.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Domain: Container",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/credential_access_credentials_keychains.toml b/rules/macos/credential_access_credentials_keychains.toml
index eb5d3dc1858..7f1d21e3c5e 100644
--- a/rules/macos/credential_access_credentials_keychains.toml
+++ b/rules/macos/credential_access_credentials_keychains.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
index cc868131ef7..ff9f2edbaa9 100644
--- a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
+++ b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/credential_access_dumping_keychain_security.toml b/rules/macos/credential_access_dumping_keychain_security.toml
index 9d9250ed43c..f71916bbd2d 100644
--- a/rules/macos/credential_access_dumping_keychain_security.toml
+++ b/rules/macos/credential_access_dumping_keychain_security.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/credential_access_high_volume_of_pbpaste.toml b/rules/macos/credential_access_high_volume_of_pbpaste.toml
index 47d760866d1..b419f20046f 100644
--- a/rules/macos/credential_access_high_volume_of_pbpaste.toml
+++ b/rules/macos/credential_access_high_volume_of_pbpaste.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/12"
 integration = ["endpoint", "jamf_protect"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.investigate]]
@@ -95,6 +95,7 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Jamf Protect",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/credential_access_kerberosdump_kcc.toml b/rules/macos/credential_access_kerberosdump_kcc.toml
index 09b24cc983d..997cc391119 100644
--- a/rules/macos/credential_access_kerberosdump_kcc.toml
+++ b/rules/macos/credential_access_kerberosdump_kcc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
index 184a5858c7f..37117d8c8e9 100644
--- a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
+++ b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -57,6 +57,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/credential_access_mitm_localhost_webproxy.toml b/rules/macos/credential_access_mitm_localhost_webproxy.toml
index d35403dd4b6..341dafc5465 100644
--- a/rules/macos/credential_access_mitm_localhost_webproxy.toml
+++ b/rules/macos/credential_access_mitm_localhost_webproxy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
index f378688fafa..87666419b43 100644
--- a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
+++ b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
index 39848c4fb2b..5b5f2466758 100644
--- a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
+++ b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/16"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
index 35d61e79a97..e23f27236ed 100644
--- a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
+++ b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/credential_access_systemkey_dumping.toml b/rules/macos/credential_access_systemkey_dumping.toml
index dfe39d2e902..18bef176c07 100644
--- a/rules/macos/credential_access_systemkey_dumping.toml
+++ b/rules/macos/credential_access_systemkey_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_apple_softupdates_modification.toml b/rules/macos/defense_evasion_apple_softupdates_modification.toml
index 85b80b85d96..71c5501a69e 100644
--- a/rules/macos/defense_evasion_apple_softupdates_modification.toml
+++ b/rules/macos/defense_evasion_apple_softupdates_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
index bc25e9002fd..210c474844a 100644
--- a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
+++ b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
index e6de35a4f36..24618af0ca6 100644
--- a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
+++ b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_install_root_certificate.toml b/rules/macos/defense_evasion_install_root_certificate.toml
index 5446bf513c7..03aec710177 100644
--- a/rules/macos/defense_evasion_install_root_certificate.toml
+++ b/rules/macos/defense_evasion_install_root_certificate.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_modify_environment_launchctl.toml b/rules/macos/defense_evasion_modify_environment_launchctl.toml
index 3d312685410..36a29e48c82 100644
--- a/rules/macos/defense_evasion_modify_environment_launchctl.toml
+++ b/rules/macos/defense_evasion_modify_environment_launchctl.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
index 54763120bd7..8539f058613 100644
--- a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
+++ b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
index 1a6949e943f..bb618f17925 100644
--- a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
+++ b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/defense_evasion_safari_config_change.toml b/rules/macos/defense_evasion_safari_config_change.toml
index 4bbc224d117..6bd0e037363 100644
--- a/rules/macos/defense_evasion_safari_config_change.toml
+++ b/rules/macos/defense_evasion_safari_config_change.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
index 1176027c5cb..f5a649fdab7 100644
--- a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
+++ b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
index 162e37c6830..556ad81d956 100644
--- a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
+++ b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
index b585425d996..e894cfb1d51 100644
--- a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
+++ b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/discovery_users_domain_built_in_commands.toml b/rules/macos/discovery_users_domain_built_in_commands.toml
index 55bb9bd6f7e..19802d35071 100644
--- a/rules/macos/discovery_users_domain_built_in_commands.toml
+++ b/rules/macos/discovery_users_domain_built_in_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -49,6 +49,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
index af46021f5c6..eae56acddeb 100644
--- a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
+++ b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
index 28bbb532adc..1437bb7f2df 100644
--- a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
+++ b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Initial Access",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/execution_installer_package_spawned_network_event.toml b/rules/macos/execution_installer_package_spawned_network_event.toml
index ca3e3e8c1ab..dee99e1096a 100644
--- a/rules/macos/execution_installer_package_spawned_network_event.toml
+++ b/rules/macos/execution_installer_package_spawned_network_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/02/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/macos/execution_script_via_automator_workflows.toml b/rules/macos/execution_script_via_automator_workflows.toml
index 9aedc13897e..c9869178b13 100644
--- a/rules/macos/execution_script_via_automator_workflows.toml
+++ b/rules/macos/execution_script_via_automator_workflows.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
index 2016aea3ba7..e72db635aea 100644
--- a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
+++ b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Tactic: Command and Control",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/macos/execution_shell_execution_via_apple_scripting.toml b/rules/macos/execution_shell_execution_via_apple_scripting.toml
index f80ba8b2375..d6e2ca8bf40 100644
--- a/rules/macos/execution_shell_execution_via_apple_scripting.toml
+++ b/rules/macos/execution_shell_execution_via_apple_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
index 79193a3599e..6a9c0878f71 100644
--- a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
+++ b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Initial Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
index e47d2cdb06f..22ee01eee8b 100644
--- a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
+++ b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/12"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/lateral_movement_mounting_smb_share.toml b/rules/macos/lateral_movement_mounting_smb_share.toml
index 9812c260281..4983f63fac6 100644
--- a/rules/macos/lateral_movement_mounting_smb_share.toml
+++ b/rules/macos/lateral_movement_mounting_smb_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
index c630f8d21e9..beae0204176 100644
--- a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
+++ b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/lateral_movement_vpn_connection_attempt.toml b/rules/macos/lateral_movement_vpn_connection_attempt.toml
index 3aa0fd4be52..0164501a68f 100644
--- a/rules/macos/lateral_movement_vpn_connection_attempt.toml
+++ b/rules/macos/lateral_movement_vpn_connection_attempt.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_account_creation_hide_at_logon.toml b/rules/macos/persistence_account_creation_hide_at_logon.toml
index f71eb48c4ec..445ba414642 100644
--- a/rules/macos/persistence_account_creation_hide_at_logon.toml
+++ b/rules/macos/persistence_account_creation_hide_at_logon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_creation_change_launch_agents_file.toml b/rules/macos/persistence_creation_change_launch_agents_file.toml
index 113260649dd..cf36c7e9509 100644
--- a/rules/macos/persistence_creation_change_launch_agents_file.toml
+++ b/rules/macos/persistence_creation_change_launch_agents_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/macos/persistence_creation_hidden_login_item_osascript.toml b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
index ffc55220185..99dfa038c1b 100644
--- a/rules/macos/persistence_creation_hidden_login_item_osascript.toml
+++ b/rules/macos/persistence_creation_hidden_login_item_osascript.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
index 68b8e97f15a..984c15a420d 100644
--- a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
+++ b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
index b3de7e87a79..cf9d9bb921c 100644
--- a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
+++ b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_crontab_creation.toml b/rules/macos/persistence_crontab_creation.toml
index f4286c4c609..be9c600a8cf 100644
--- a/rules/macos/persistence_crontab_creation.toml
+++ b/rules/macos/persistence_crontab_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
index ce084dc26ee..85576c6a8bd 100644
--- a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
+++ b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_directory_services_plugins_modification.toml b/rules/macos/persistence_directory_services_plugins_modification.toml
index 5d5cd07895c..cfd05595daf 100644
--- a/rules/macos/persistence_directory_services_plugins_modification.toml
+++ b/rules/macos/persistence_directory_services_plugins_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_docker_shortcuts_plist_modification.toml b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
index 568afe1728b..b66e6ba5438 100644
--- a/rules/macos/persistence_docker_shortcuts_plist_modification.toml
+++ b/rules/macos/persistence_docker_shortcuts_plist_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_emond_rules_file_creation.toml b/rules/macos/persistence_emond_rules_file_creation.toml
index c360022db17..b69497f05d8 100644
--- a/rules/macos/persistence_emond_rules_file_creation.toml
+++ b/rules/macos/persistence_emond_rules_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_emond_rules_process_execution.toml b/rules/macos/persistence_emond_rules_process_execution.toml
index f201132925d..431b82614d7 100644
--- a/rules/macos/persistence_emond_rules_process_execution.toml
+++ b/rules/macos/persistence_emond_rules_process_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_enable_root_account.toml b/rules/macos/persistence_enable_root_account.toml
index cd830f6b196..5a549bc57d7 100644
--- a/rules/macos/persistence_enable_root_account.toml
+++ b/rules/macos/persistence_enable_root_account.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
index 6bb3145b4a9..a2c0c6bbf8c 100644
--- a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
+++ b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
index c8e22a0d1ef..2fd1b692b07 100644
--- a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
+++ b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_folder_action_scripts_runtime.toml b/rules/macos/persistence_folder_action_scripts_runtime.toml
index e11c2b3354d..6dbc162a9fc 100644
--- a/rules/macos/persistence_folder_action_scripts_runtime.toml
+++ b/rules/macos/persistence_folder_action_scripts_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_login_logout_hooks_defaults.toml b/rules/macos/persistence_login_logout_hooks_defaults.toml
index d66fa1c5e41..f64afd9982d 100644
--- a/rules/macos/persistence_login_logout_hooks_defaults.toml
+++ b/rules/macos/persistence_login_logout_hooks_defaults.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_loginwindow_plist_modification.toml b/rules/macos/persistence_loginwindow_plist_modification.toml
index f75f8d19192..7603cbada1f 100644
--- a/rules/macos/persistence_loginwindow_plist_modification.toml
+++ b/rules/macos/persistence_loginwindow_plist_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
index 4316bb4e418..afa5fd22d3d 100644
--- a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
+++ b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/23"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
index 4cd00601227..9650aa324d9 100644
--- a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
+++ b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -54,6 +54,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_screensaver_engine_unexpected_child_process.toml b/rules/macos/persistence_screensaver_engine_unexpected_child_process.toml
index c2c9d4d7c3b..6ce6ddb897a 100644
--- a/rules/macos/persistence_screensaver_engine_unexpected_child_process.toml
+++ b/rules/macos/persistence_screensaver_engine_unexpected_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -62,6 +62,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_screensaver_plist_file_modification.toml b/rules/macos/persistence_screensaver_plist_file_modification.toml
index f7280bcfa47..006ce9366c3 100644
--- a/rules/macos/persistence_screensaver_plist_file_modification.toml
+++ b/rules/macos/persistence_screensaver_plist_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/persistence_suspicious_calendar_modification.toml b/rules/macos/persistence_suspicious_calendar_modification.toml
index c878d8834f9..19d042aace3 100644
--- a/rules/macos/persistence_suspicious_calendar_modification.toml
+++ b/rules/macos/persistence_suspicious_calendar_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/persistence_via_atom_init_file_modification.toml b/rules/macos/persistence_via_atom_init_file_modification.toml
index 319367f14b6..bb995b2f259 100644
--- a/rules/macos/persistence_via_atom_init_file_modification.toml
+++ b/rules/macos/persistence_via_atom_init_file_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
index 708205e4ad4..3eea339272e 100644
--- a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
+++ b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -51,6 +51,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
index 096d9223f73..f0493515d69 100644
--- a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
+++ b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
index 9670c050fa6..5e9a5999536 100644
--- a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
+++ b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -55,6 +55,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/privilege_escalation_local_user_added_to_admin.toml b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
index d8099caa6d3..4bc4e6853f5 100644
--- a/rules/macos/privilege_escalation_local_user_added_to_admin.toml
+++ b/rules/macos/privilege_escalation_local_user_added_to_admin.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/01/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/privilege_escalation_root_crontab_filemod.toml b/rules/macos/privilege_escalation_root_crontab_filemod.toml
index 7fa8bfb3add..7b2034cd73e 100644
--- a/rules/macos/privilege_escalation_root_crontab_filemod.toml
+++ b/rules/macos/privilege_escalation_root_crontab_filemod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -53,6 +53,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/macos/privilege_escalation_user_added_to_admin_group.toml b/rules/macos/privilege_escalation_user_added_to_admin_group.toml
index a6e67c46a4c..d99f47951c4 100644
--- a/rules/macos/privilege_escalation_user_added_to_admin_group.toml
+++ b/rules/macos/privilege_escalation_user_added_to_admin_group.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/12"
 integration = ["jamf_protect"]
 maturity = "production"
-updated_date = "2024/12/09"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.investigate]]
@@ -90,6 +90,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Jamf Protect",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
index 4e61efde0b8..677898f0c23 100644
--- a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -77,6 +77,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
index 24c58f205c5..bc5e9a0574f 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -80,6 +80,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
index 52f2e5a1404..390ff8b41e2 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -83,6 +83,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
index e1c06752d74..8ad611b108e 100644
--- a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
+++ b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -81,6 +81,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Command and Control",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
index 0d3d0f6141d..e2c5d123724 100644
--- a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
+++ b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -96,6 +96,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
index 10dfec5ecb6..15e0e984ea7 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -82,6 +82,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
index afcd79982a6..bddcf4eb5f7 100644
--- a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -82,6 +82,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/credential_access_ml_suspicious_login_activity.toml b/rules/ml/credential_access_ml_suspicious_login_activity.toml
index d220e5ebeb3..1a3ed0a32e7 100644
--- a/rules/ml/credential_access_ml_suspicious_login_activity.toml
+++ b/rules/ml/credential_access_ml_suspicious_login_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -93,6 +93,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
index 10af80a11c5..d262945a716 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -78,6 +78,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
index 06ccee607b4..5c56c751c2a 100644
--- a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
+++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/22"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -78,6 +78,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/discovery_ml_linux_system_information_discovery.toml b/rules/ml/discovery_ml_linux_system_information_discovery.toml
index 44f250de9d2..1fc150ac21c 100644
--- a/rules/ml/discovery_ml_linux_system_information_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_information_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -84,6 +84,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
index b90e37526ae..c51fe1ec419 100644
--- a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 25
@@ -84,6 +84,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
index 4774dd9e03c..0dc7700b1dd 100644
--- a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 25
@@ -84,6 +84,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/discovery_ml_linux_system_process_discovery.toml b/rules/ml/discovery_ml_linux_system_process_discovery.toml
index ca2c23d6037..0f0f38d7a8e 100644
--- a/rules/ml/discovery_ml_linux_system_process_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_process_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -84,6 +84,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/discovery_ml_linux_system_user_discovery.toml b/rules/ml/discovery_ml_linux_system_user_discovery.toml
index 3f9e43e3962..97dcc42a26c 100644
--- a/rules/ml/discovery_ml_linux_system_user_discovery.toml
+++ b/rules/ml/discovery_ml_linux_system_user_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -84,6 +84,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Discovery",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/execution_ml_windows_anomalous_script.toml b/rules/ml/execution_ml_windows_anomalous_script.toml
index 988420775c4..b347de57fa9 100644
--- a/rules/ml/execution_ml_windows_anomalous_script.toml
+++ b/rules/ml/execution_ml_windows_anomalous_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -82,6 +82,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
index 3b1764e2766..0157a2de1c2 100644
--- a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
+++ b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/06/10"
 integration = ["auditd_manager", "endpoint", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -93,6 +93,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/initial_access_ml_linux_anomalous_user_name.toml b/rules/ml/initial_access_ml_linux_anomalous_user_name.toml
index f95faf19706..1ad2a260741 100644
--- a/rules/ml/initial_access_ml_linux_anomalous_user_name.toml
+++ b/rules/ml/initial_access_ml_linux_anomalous_user_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -96,6 +96,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 [[rule.threat]]
diff --git a/rules/ml/initial_access_ml_windows_anomalous_user_name.toml b/rules/ml/initial_access_ml_windows_anomalous_user_name.toml
index 6eb22e31503..3ac09ffd8fa 100644
--- a/rules/ml/initial_access_ml_windows_anomalous_user_name.toml
+++ b/rules/ml/initial_access_ml_windows_anomalous_user_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -93,6 +93,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 [[rule.threat]]
diff --git a/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml b/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml
index 8637ff9cf34..7795ac64cd1 100644
--- a/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml
+++ b/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -86,6 +86,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Initial Access",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 [[rule.threat]]
diff --git a/rules/ml/ml_high_count_network_denies.toml b/rules/ml/ml_high_count_network_denies.toml
index e46cf2bf44a..59642ccab2d 100644
--- a/rules/ml/ml_high_count_network_denies.toml
+++ b/rules/ml/ml_high_count_network_denies.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -74,7 +74,7 @@ references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs
 risk_score = 21
 rule_id = "eaa77d63-9679-4ce3-be25-3ba8b795e5fa"
 severity = "low"
-tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
+tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning", "Resources: Investigation Guide"]
 type = "machine_learning"
 note = """## Triage and analysis
 
diff --git a/rules/ml/ml_high_count_network_events.toml b/rules/ml/ml_high_count_network_events.toml
index 009e7697a0f..924e7d2f9da 100644
--- a/rules/ml/ml_high_count_network_events.toml
+++ b/rules/ml/ml_high_count_network_events.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -73,7 +73,7 @@ references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs
 risk_score = 21
 rule_id = "b240bfb8-26b7-4e5e-924e-218144a3fa71"
 severity = "low"
-tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
+tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning", "Resources: Investigation Guide"]
 type = "machine_learning"
 note = """## Triage and analysis
 
diff --git a/rules/ml/ml_linux_anomalous_network_activity.toml b/rules/ml/ml_linux_anomalous_network_activity.toml
index 7fed0183b9e..a670d24105a 100644
--- a/rules/ml/ml_linux_anomalous_network_activity.toml
+++ b/rules/ml/ml_linux_anomalous_network_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -88,6 +88,7 @@ tags = [
     "Use Case: Threat Detection",
     "Rule Type: ML",
     "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 
diff --git a/rules/ml/ml_linux_anomalous_network_port_activity.toml b/rules/ml/ml_linux_anomalous_network_port_activity.toml
index 40a9b30bd27..0c843572f53 100644
--- a/rules/ml/ml_linux_anomalous_network_port_activity.toml
+++ b/rules/ml/ml_linux_anomalous_network_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -78,6 +78,7 @@ tags = [
     "Use Case: Threat Detection",
     "Rule Type: ML",
     "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/ml_packetbeat_rare_server_domain.toml b/rules/ml/ml_packetbeat_rare_server_domain.toml
index e3f9eae65fb..0b6b6323406 100644
--- a/rules/ml/ml_packetbeat_rare_server_domain.toml
+++ b/rules/ml/ml_packetbeat_rare_server_domain.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -81,7 +81,7 @@ references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs
 risk_score = 21
 rule_id = "17e68559-b274-4948-ad0b-f8415bb31126"
 severity = "low"
-tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
+tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning", "Resources: Investigation Guide"]
 type = "machine_learning"
 note = """## Triage and analysis
 
diff --git a/rules/ml/ml_rare_destination_country.toml b/rules/ml/ml_rare_destination_country.toml
index d79f76aadb4..aa4093e0105 100644
--- a/rules/ml/ml_rare_destination_country.toml
+++ b/rules/ml/ml_rare_destination_country.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -77,7 +77,7 @@ references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs
 risk_score = 21
 rule_id = "35f86980-1fb1-4dff-b311-3be941549c8d"
 severity = "low"
-tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
+tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning", "Resources: Investigation Guide"]
 type = "machine_learning"
 note = """## Triage and analysis
 
diff --git a/rules/ml/ml_spike_in_traffic_to_a_country.toml b/rules/ml/ml_spike_in_traffic_to_a_country.toml
index 9ca8cdd35e3..1e70ca2093a 100644
--- a/rules/ml/ml_spike_in_traffic_to_a_country.toml
+++ b/rules/ml/ml_spike_in_traffic_to_a_country.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/05"
 integration = ["endpoint", "network_traffic"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -112,6 +112,6 @@ references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs
 risk_score = 21
 rule_id = "c7db5533-ca2a-41f6-a8b0-ee98abe0f573"
 severity = "low"
-tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"]
+tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning", "Resources: Investigation Guide"]
 type = "machine_learning"
 
diff --git a/rules/ml/ml_windows_anomalous_network_activity.toml b/rules/ml/ml_windows_anomalous_network_activity.toml
index 5347e5c0078..9b7b9ed7670 100644
--- a/rules/ml/ml_windows_anomalous_network_activity.toml
+++ b/rules/ml/ml_windows_anomalous_network_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -87,6 +87,7 @@ tags = [
     "Use Case: Threat Detection",
     "Rule Type: ML",
     "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 
diff --git a/rules/ml/persistence_ml_rare_process_by_host_linux.toml b/rules/ml/persistence_ml_rare_process_by_host_linux.toml
index 0361a75d0d9..27b54cff337 100644
--- a/rules/ml/persistence_ml_rare_process_by_host_linux.toml
+++ b/rules/ml/persistence_ml_rare_process_by_host_linux.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2024/06/18"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -121,6 +121,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 [[rule.threat]]
diff --git a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
index a63fccfa27a..413b60866ec 100644
--- a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -83,6 +83,7 @@ tags = [
     "Rule Type: Machine Learning",
     "Tactic: Persistence",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/persistence_ml_windows_anomalous_process_all_hosts.toml b/rules/ml/persistence_ml_windows_anomalous_process_all_hosts.toml
index 0ef4f801c27..39aa0258ad0 100644
--- a/rules/ml/persistence_ml_windows_anomalous_process_all_hosts.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_process_all_hosts.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -168,6 +168,7 @@ tags = [
     "Rule Type: Machine Learning",
     "Tactic: Persistence",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 [[rule.threat]]
diff --git a/rules/ml/persistence_ml_windows_anomalous_service.toml b/rules/ml/persistence_ml_windows_anomalous_service.toml
index 4991ae0fbc1..0c129a5b911 100644
--- a/rules/ml/persistence_ml_windows_anomalous_service.toml
+++ b/rules/ml/persistence_ml_windows_anomalous_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Persistence",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
index c502666ba02..c41b0d62e61 100644
--- a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
+++ b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 75
@@ -82,6 +82,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
index 433c25e4ac2..17250cb6b83 100644
--- a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
+++ b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,6 +80,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
index ccc1761d2af..8c04edd604d 100644
--- a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
+++ b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 anomaly_threshold = 50
@@ -83,6 +83,7 @@ tags = [
     "Rule Type: ML",
     "Rule Type: Machine Learning",
     "Tactic: Resource Development",
+    "Resources: Investigation Guide",
 ]
 type = "machine_learning"
 note = """## Triage and analysis
diff --git a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
index dbc9d225a31..39fbb8ad6d9 100644
--- a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
+++ b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -35,7 +35,8 @@ tags = [
     "Tactic: Command and Control",
     "Tactic: Lateral Movement",
     "Tactic: Initial Access",
-    "Data Source: PAN-OS"
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
 ]
 timeline_id = "300afc76-072d-4261-864d-4149714bf3f1"
 timeline_title = "Comprehensive Network Timeline"
diff --git a/rules/network/command_and_control_cobalt_strike_beacon.toml b/rules/network/command_and_control_cobalt_strike_beacon.toml
index 5f0d92f1d9e..c5d168d66d3 100644
--- a/rules/network/command_and_control_cobalt_strike_beacon.toml
+++ b/rules/network/command_and_control_cobalt_strike_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,7 +69,7 @@ references = [
 risk_score = 73
 rule_id = "cf53f532-9cc9-445a-9ae7-fced307ec53c"
 severity = "high"
-tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint"]
+tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
index d0dbe4ccc34..a34a8b13d73 100644
--- a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
+++ b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/05"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -72,6 +72,7 @@ tags = [
     "Threat: Cobalt Strike",
     "Use Case: Threat Detection",
     "Domain: Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/network/command_and_control_download_rar_powershell_from_internet.toml b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
index 2c97384b518..3b369f04ee9 100644
--- a/rules/network/command_and_control_download_rar_powershell_from_internet.toml
+++ b/rules/network/command_and_control_download_rar_powershell_from_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/02"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -70,7 +70,7 @@ references = [
 risk_score = 47
 rule_id = "ff013cb4-274d-434a-96bb-fe15ddd3ae92"
 severity = "medium"
-tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Data Source: PAN-OS"]
+tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/command_and_control_fin7_c2_behavior.toml b/rules/network/command_and_control_fin7_c2_behavior.toml
index fcffd02c067..038ab832275 100644
--- a/rules/network/command_and_control_fin7_c2_behavior.toml
+++ b/rules/network/command_and_control_fin7_c2_behavior.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2024/09/18"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,7 +30,7 @@ references = [
 risk_score = 73
 rule_id = "4a4e23cf-78a2-449c-bac3-701924c269d3"
 severity = "high"
-tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Data Source: PAN-OS"]
+tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/command_and_control_halfbaked_beacon.toml b/rules/network/command_and_control_halfbaked_beacon.toml
index c581865d6b2..1330bc27526 100644
--- a/rules/network/command_and_control_halfbaked_beacon.toml
+++ b/rules/network/command_and_control_halfbaked_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/06"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,7 +66,7 @@ references = [
 risk_score = 73
 rule_id = "2e580225-2a58-48ef-938b-572933be06fe"
 severity = "high"
-tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint"]
+tags = ["Use Case: Threat Detection", "Tactic: Command and Control", "Domain: Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/command_and_control_nat_traversal_port_activity.toml b/rules/network/command_and_control_nat_traversal_port_activity.toml
index 8755f2c5024..e70052c7f23 100644
--- a/rules/network/command_and_control_nat_traversal_port_activity.toml
+++ b/rules/network/command_and_control_nat_traversal_port_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,7 +28,7 @@ name = "IPSEC NAT Traversal Port Activity"
 risk_score = 21
 rule_id = "a9cb3641-ff4b-4cdc-a063-b4b8d02a67c7"
 severity = "low"
-tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/command_and_control_port_26_activity.toml b/rules/network/command_and_control_port_26_activity.toml
index fbb66f22cbe..2f266661300 100644
--- a/rules/network/command_and_control_port_26_activity.toml
+++ b/rules/network/command_and_control_port_26_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ references = [
 risk_score = 21
 rule_id = "d7e62693-aab9-4f66-a21a-3d79ecdd603d"
 severity = "low"
-tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
index 519c24198da..1c67c535c25 100644
--- a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
+++ b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -31,7 +31,7 @@ references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
 risk_score = 47
 rule_id = "8c1bdde8-4204-45c0-9e0c-c85ca3902488"
 severity = "medium"
-tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timeline_id = "300afc76-072d-4261-864d-4149714bf3f1"
 timeline_title = "Comprehensive Network Timeline"
 timestamp_override = "event.ingested"
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
index 12a067a7e45..3c16ae240ad 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
 risk_score = 73
 rule_id = "5700cb81-df44-46aa-a5d7-337798f53eb8"
 severity = "high"
-tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
index b6d384fd35c..df3de74aba9 100644
--- a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
+++ b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
 risk_score = 47
 rule_id = "3ad49c61-7adc-42c1-b788-732eda2f5abf"
 severity = "medium"
-tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Command and Control", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/discovery_potential_network_sweep_detected.toml b/rules/network/discovery_potential_network_sweep_detected.toml
index e425044c4ae..540123e9d5d 100644
--- a/rules/network/discovery_potential_network_sweep_detected.toml
+++ b/rules/network/discovery_potential_network_sweep_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,7 +28,8 @@ tags = [
     "Tactic: Reconnaissance",
     "Use Case: Network Security Monitoring",
     "Data Source: Elastic Defend",
-    "Data Source: PAN-OS"
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/network/discovery_potential_port_scan_detected.toml b/rules/network/discovery_potential_port_scan_detected.toml
index 08b9fa9c427..67717962f28 100644
--- a/rules/network/discovery_potential_port_scan_detected.toml
+++ b/rules/network/discovery_potential_port_scan_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/17"
 integration = ["endpoint", "network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,8 @@ tags = [
     "Tactic: Reconnaissance",
     "Use Case: Network Security Monitoring",
     "Data Source: Elastic Defend",
-    "Data Source: PAN-OS"
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/network/discovery_potential_syn_port_scan_detected.toml b/rules/network/discovery_potential_syn_port_scan_detected.toml
index 287ef80a6f9..00a1a878cbb 100644
--- a/rules/network/discovery_potential_syn_port_scan_detected.toml
+++ b/rules/network/discovery_potential_syn_port_scan_detected.toml
@@ -29,7 +29,8 @@ tags = [
     "Tactic: Reconnaissance",
     "Use Case: Network Security Monitoring",
     "Data Source: Elastic Defend",
-    "Data Source: PAN-OS"
+    "Data Source: PAN-OS",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
index 3a4cc537d4a..105c10f27b0 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,7 @@ references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
 risk_score = 73
 rule_id = "143cb236-0956-4f42-a706-814bcaa0cf5a"
 severity = "high"
-tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
index 22d35f5a60c..2072a632c94 100644
--- a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
+++ b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,7 @@ references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
 risk_score = 73
 rule_id = "32923416-763a-4531-bb35-f33b9232ecdb"
 severity = "high"
-tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
index 1cab816a53e..bee2d31ff99 100644
--- a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
+++ b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["network_traffic", "panw"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,7 @@ references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-
 risk_score = 73
 rule_id = "c82b2bd8-d701-420c-ba43-f11a155b681a"
 severity = "high"
-tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS"]
+tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/network/initial_access_unsecure_elasticsearch_node.toml b/rules/network/initial_access_unsecure_elasticsearch_node.toml
index 56eb849a18d..3e4f65b7211 100644
--- a/rules/network/initial_access_unsecure_elasticsearch_node.toml
+++ b/rules/network/initial_access_unsecure_elasticsearch_node.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/11"
 integration = ["network_traffic"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -66,7 +66,7 @@ references = [
 risk_score = 47
 rule_id = "31295df3-277b-4c56-a1fb-84e31b4222a9"
 severity = "medium"
-tags = ["Use Case: Threat Detection", "Tactic: Initial Access", "Domain: Endpoint"]
+tags = ["Use Case: Threat Detection", "Tactic: Initial Access", "Domain: Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
index ca087587001..998ef82e8d0 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "high"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Credential Access"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
index beb05b4582b..ed000beca84 100644
--- a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
+++ b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "medium"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Credential Access"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/endgame_adversary_behavior_detected.toml b/rules/promotions/endgame_adversary_behavior_detected.toml
index 6879227863f..aab9803aab6 100644
--- a/rules/promotions/endgame_adversary_behavior_detected.toml
+++ b/rules/promotions/endgame_adversary_behavior_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "medium"
-tags = ["Data Source: Elastic Endgame"]
+tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/endgame_malware_detected.toml b/rules/promotions/endgame_malware_detected.toml
index 333502f032f..31bbc4f7634 100644
--- a/rules/promotions/endgame_malware_detected.toml
+++ b/rules/promotions/endgame_malware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "critical"
-tags = ["Data Source: Elastic Endgame"]
+tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/endgame_malware_prevented.toml b/rules/promotions/endgame_malware_prevented.toml
index 7d5edb4857c..467ddcf812c 100644
--- a/rules/promotions/endgame_malware_prevented.toml
+++ b/rules/promotions/endgame_malware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "high"
-tags = ["Data Source: Elastic Endgame"]
+tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/endgame_ransomware_detected.toml b/rules/promotions/endgame_ransomware_detected.toml
index f872b2aae4a..9d23dc1b843 100644
--- a/rules/promotions/endgame_ransomware_detected.toml
+++ b/rules/promotions/endgame_ransomware_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "critical"
-tags = ["Data Source: Elastic Endgame"]
+tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/endgame_ransomware_prevented.toml b/rules/promotions/endgame_ransomware_prevented.toml
index 7cebc2428df..b32b9b36ac8 100644
--- a/rules/promotions/endgame_ransomware_prevented.toml
+++ b/rules/promotions/endgame_ransomware_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "high"
-tags = ["Data Source: Elastic Endgame"]
+tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/execution_endgame_exploit_detected.toml b/rules/promotions/execution_endgame_exploit_detected.toml
index 9c1e1619837..d47aedb63de 100644
--- a/rules/promotions/execution_endgame_exploit_detected.toml
+++ b/rules/promotions/execution_endgame_exploit_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/promotions/execution_endgame_exploit_prevented.toml b/rules/promotions/execution_endgame_exploit_prevented.toml
index 94e90088fee..9666184c917 100644
--- a/rules/promotions/execution_endgame_exploit_prevented.toml
+++ b/rules/promotions/execution_endgame_exploit_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/promotions/external_alerts.toml b/rules/promotions/external_alerts.toml
index 4ed361477e7..98fd75797e7 100644
--- a/rules/promotions/external_alerts.toml
+++ b/rules/promotions/external_alerts.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/08"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,7 +36,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "medium"
-tags = ["OS: Windows", "Data Source: APM", "OS: macOS", "OS: Linux"]
+tags = ["OS: Windows", "Data Source: APM", "OS: macOS", "OS: Linux", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
index e1ce1f731aa..f0314e447df 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "high"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
index 2a0c4d7e60d..25e26765377 100644
--- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "medium"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
index 4752a342c51..91f88ec9639 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "high"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
index 8e40425bb5c..5e40431547a 100644
--- a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "medium"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
index 3568eb7aacd..4294a157d34 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "high"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
index e083a1f6b8d..296341418d8 100644
--- a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
+++ b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 maturity = "production"
 promotion = true
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,7 +29,7 @@ To make sure this rule can generate as many alerts as it's configured in its own
 
 **NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
 severity = "medium"
-tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation"]
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/threat_intel/threat_intel_indicator_match_address.toml b/rules/threat_intel/threat_intel_indicator_match_address.toml
index b371aa40afd..761c9a8b517 100644
--- a/rules/threat_intel/threat_intel_indicator_match_address.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_address.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -113,7 +113,7 @@ or a [custom integration](https://www.elastic.co/guide/en/security/current/es-th
 More information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).
 """
 severity = "critical"
-tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match"]
+tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match", "Resources: Investigation Guide"]
 threat_index = ["filebeat-*", "logs-ti_*"]
 threat_indicator_path = "threat.indicator"
 threat_language = "kuery"
diff --git a/rules/threat_intel/threat_intel_indicator_match_hash.toml b/rules/threat_intel/threat_intel_indicator_match_hash.toml
index cb02712e3b2..a52f822901e 100644
--- a/rules/threat_intel/threat_intel_indicator_match_hash.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_hash.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -112,7 +112,7 @@ or a [custom integration](https://www.elastic.co/guide/en/security/current/es-th
 More information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).
 """
 severity = "critical"
-tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match"]
+tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match", "Resources: Investigation Guide"]
 threat_index = ["filebeat-*", "logs-ti_*"]
 threat_indicator_path = "threat.indicator"
 threat_language = "kuery"
diff --git a/rules/threat_intel/threat_intel_indicator_match_registry.toml b/rules/threat_intel/threat_intel_indicator_match_registry.toml
index 6406191a8fb..e3b92d56f32 100644
--- a/rules/threat_intel/threat_intel_indicator_match_registry.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_registry.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -107,7 +107,7 @@ or a [custom integration](https://www.elastic.co/guide/en/security/current/es-th
 More information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).
 """
 severity = "critical"
-tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match"]
+tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match", "Resources: Investigation Guide"]
 threat_index = ["filebeat-*", "logs-ti_*"]
 threat_indicator_path = "threat.indicator"
 threat_language = "kuery"
diff --git a/rules/threat_intel/threat_intel_indicator_match_url.toml b/rules/threat_intel/threat_intel_indicator_match_url.toml
index 7a16b72ecf2..9407bbcaf60 100644
--- a/rules/threat_intel/threat_intel_indicator_match_url.toml
+++ b/rules/threat_intel/threat_intel_indicator_match_url.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/05/22"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -116,7 +116,7 @@ or a [custom integration](https://www.elastic.co/guide/en/security/current/es-th
 More information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).
 """
 severity = "critical"
-tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match"]
+tags = ["OS: Windows", "Data Source: Elastic Endgame", "Rule Type: Threat Match", "Resources: Investigation Guide"]
 threat_index = ["filebeat-*", "logs-ti_*"]
 threat_indicator_path = "threat.indicator"
 threat_language = "kuery"
diff --git a/rules/windows/collection_email_outlook_mailbox_via_com.toml b/rules/windows/collection_email_outlook_mailbox_via_com.toml
index 759044cec38..df0f8d37a40 100644
--- a/rules/windows/collection_email_outlook_mailbox_via_com.toml
+++ b/rules/windows/collection_email_outlook_mailbox_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Collection",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/collection_posh_webcam_video_capture.toml b/rules/windows/collection_posh_webcam_video_capture.toml
index b09ba8f6f20..e7afa981c67 100644
--- a/rules/windows/collection_posh_webcam_video_capture.toml
+++ b/rules/windows/collection_posh_webcam_video_capture.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/18"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Collection",
     "Data Source: PowerShell Logs",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/command_and_control_certreq_postdata.toml b/rules/windows/command_and_control_certreq_postdata.toml
index 3217eb32580..500bf5676c3 100644
--- a/rules/windows/command_and_control_certreq_postdata.toml
+++ b/rules/windows/command_and_control_certreq_postdata.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -124,6 +124,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
index e90c4f69a96..6815716b957 100644
--- a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
+++ b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/command_and_control_iexplore_via_com.toml b/rules/windows/command_and_control_iexplore_via_com.toml
index f1816e9c42c..a9db0f9e470 100644
--- a/rules/windows/command_and_control_iexplore_via_com.toml
+++ b/rules/windows/command_and_control_iexplore_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -26,6 +26,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/command_and_control_ingress_transfer_bits.toml b/rules/windows/command_and_control_ingress_transfer_bits.toml
index cfd445b29ac..9c3feeefdaf 100644
--- a/rules/windows/command_and_control_ingress_transfer_bits.toml
+++ b/rules/windows/command_and_control_ingress_transfer_bits.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/06"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -121,6 +121,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Command and Control",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/command_and_control_outlook_home_page.toml b/rules/windows/command_and_control_outlook_home_page.toml
index 1ddd1024b75..90f713db53b 100644
--- a/rules/windows/command_and_control_outlook_home_page.toml
+++ b/rules/windows/command_and_control_outlook_home_page.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/01"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/command_and_control_tunnel_vscode.toml b/rules/windows/command_and_control_tunnel_vscode.toml
index e565fb50fec..5b2ef1301d8 100644
--- a/rules/windows/command_and_control_tunnel_vscode.toml
+++ b/rules/windows/command_and_control_tunnel_vscode.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: System",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_adidns_wildcard.toml b/rules/windows/credential_access_adidns_wildcard.toml
index 9f9f330defe..f38ecdfeff1 100644
--- a/rules/windows/credential_access_adidns_wildcard.toml
+++ b/rules/windows/credential_access_adidns_wildcard.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,7 @@ tags = [
     "Data Source: Active Directory",
     "Use Case: Active Directory Monitoring",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_adidns_wpad_record.toml b/rules/windows/credential_access_adidns_wpad_record.toml
index d6b8200d721..633b8103480 100644
--- a/rules/windows/credential_access_adidns_wpad_record.toml
+++ b/rules/windows/credential_access_adidns_wpad_record.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/03"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Active Directory",
     "Use Case: Active Directory Monitoring",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_copy_ntds_sam_volshadowcp_cmdline.toml b/rules/windows/credential_access_copy_ntds_sam_volshadowcp_cmdline.toml
index 95fc520118a..39c379bb0b2 100644
--- a/rules/windows/credential_access_copy_ntds_sam_volshadowcp_cmdline.toml
+++ b/rules/windows/credential_access_copy_ntds_sam_volshadowcp_cmdline.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -131,6 +131,7 @@ tags = [
     "Data Source: SentinelOne",
     "Data Source: Sysmon",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_dcsync_user_backdoor.toml b/rules/windows/credential_access_dcsync_user_backdoor.toml
index a2849d47689..5830645d108 100644
--- a/rules/windows/credential_access_dcsync_user_backdoor.toml
+++ b/rules/windows/credential_access_dcsync_user_backdoor.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/10"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -80,7 +80,7 @@ references = [
 risk_score = 47
 rule_id = "f8822053-a5d2-46db-8c96-d460b12c36ac"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Active Directory", "Use Case: Active Directory Monitoring", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Active Directory", "Use Case: Active Directory Monitoring", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/windows/credential_access_dnsnode_creation.toml b/rules/windows/credential_access_dnsnode_creation.toml
index 5a2a7c7b306..37610fcc512 100644
--- a/rules/windows/credential_access_dnsnode_creation.toml
+++ b/rules/windows/credential_access_dnsnode_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -58,6 +58,7 @@ tags = [
     "Data Source: Active Directory",
     "Use Case: Active Directory Monitoring",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_dollar_account_relay.toml b/rules/windows/credential_access_dollar_account_relay.toml
index ecf3d1f46db..5c679ab5b38 100644
--- a/rules/windows/credential_access_dollar_account_relay.toml
+++ b/rules/windows/credential_access_dollar_account_relay.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/24"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Active Directory",
     "Use Case: Active Directory Monitoring",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_domain_backup_dpapi_private_keys.toml b/rules/windows/credential_access_domain_backup_dpapi_private_keys.toml
index 0b1bf4ff115..58d2a58bdf1 100644
--- a/rules/windows/credential_access_domain_backup_dpapi_private_keys.toml
+++ b/rules/windows/credential_access_domain_backup_dpapi_private_keys.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/31"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,7 +28,7 @@ references = [
 risk_score = 73
 rule_id = "b83a7e96-2eb3-4edf-8346-427b6858d3bd"
 severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Data Source: Crowdstrike"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Data Source: Crowdstrike", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/credential_access_generic_localdumps.toml b/rules/windows/credential_access_generic_localdumps.toml
index da4fc4b3400..6b1d013fbfe 100644
--- a/rules/windows/credential_access_generic_localdumps.toml
+++ b/rules/windows/credential_access_generic_localdumps.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/28"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_iis_connectionstrings_dumping.toml b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
index 4ca7183983a..412b2224f7a 100644
--- a/rules/windows/credential_access_iis_connectionstrings_dumping.toml
+++ b/rules/windows/credential_access_iis_connectionstrings_dumping.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
index 1a00747e727..1514506b2c4 100644
--- a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
+++ b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/10/14"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -25,7 +25,7 @@ references = [
 risk_score = 73
 rule_id = "f909075d-afc7-42d7-b399-600b94352fd9"
 severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Defend", "Data Source: Sysmon"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Defend", "Data Source: Sysmon", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/credential_access_kirbi_file.toml b/rules/windows/credential_access_kirbi_file.toml
index 191b0c6ff8b..f1587fef43e 100644
--- a/rules/windows/credential_access_kirbi_file.toml
+++ b/rules/windows/credential_access_kirbi_file.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,7 @@ name = "Kirbi File Creation"
 risk_score = 73
 rule_id = "b8f8da2d-a9dc-48c0-90e4-955c0aa1259a"
 severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Data Source: Elastic Endgame", "Data Source: Crowdstrike"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Data Source: Elastic Endgame", "Data Source: Crowdstrike", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/credential_access_ldap_attributes.toml b/rules/windows/credential_access_ldap_attributes.toml
index 7f4e92c8b31..48342b4a825 100644
--- a/rules/windows/credential_access_ldap_attributes.toml
+++ b/rules/windows/credential_access_ldap_attributes.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Active Directory Monitoring",
     "Data Source: Active Directory",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
index 5614cc3c570..c3881e95792 100644
--- a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
+++ b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/06/29"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_lsass_loaded_susp_dll.toml b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
index c5d0823c95e..cb444a5b057 100644
--- a/rules/windows/credential_access_lsass_loaded_susp_dll.toml
+++ b/rules/windows/credential_access_lsass_loaded_susp_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/12/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_lsass_openprocess_api.toml b/rules/windows/credential_access_lsass_openprocess_api.toml
index 8b050d7c8df..1cfe84871ed 100644
--- a/rules/windows/credential_access_lsass_openprocess_api.toml
+++ b/rules/windows/credential_access_lsass_openprocess_api.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/02"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2024/08/08"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -112,7 +112,8 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
-    "Data Source: Microsoft Defender for Endpoint"
+    "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_persistence_network_logon_provider_modification.toml b/rules/windows/credential_access_persistence_network_logon_provider_modification.toml
index bc5af509eb5..c6da429bd89 100644
--- a/rules/windows/credential_access_persistence_network_logon_provider_modification.toml
+++ b/rules/windows/credential_access_persistence_network_logon_provider_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/18"
 integration = ["endpoint", "m365_defender", "windows"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -117,6 +117,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_posh_kerb_ticket_dump.toml b/rules/windows/credential_access_posh_kerb_ticket_dump.toml
index b5353cf14ca..49ae8aa5e85 100644
--- a/rules/windows/credential_access_posh_kerb_ticket_dump.toml
+++ b/rules/windows/credential_access_posh_kerb_ticket_dump.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/26"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -90,6 +90,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: PowerShell Logs",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/credential_access_posh_veeam_sql.toml b/rules/windows/credential_access_posh_veeam_sql.toml
index b30f7a9f3a0..d5fe9c97410 100644
--- a/rules/windows/credential_access_posh_veeam_sql.toml
+++ b/rules/windows/credential_access_posh_veeam_sql.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: PowerShell Logs",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
index e226babe99e..e3a407c175f 100644
--- a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
+++ b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/27"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
index c68f9dfcebd..37dc65a07d9 100644
--- a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
+++ b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/30"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_saved_creds_vault_winlog.toml b/rules/windows/credential_access_saved_creds_vault_winlog.toml
index b8842df5e52..a1b5ba26ffe 100644
--- a/rules/windows/credential_access_saved_creds_vault_winlog.toml
+++ b/rules/windows/credential_access_saved_creds_vault_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -33,7 +33,7 @@ Hence for this rule to work effectively, users will need to add a custom ingest
 For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", "Data Source: System", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/windows/credential_access_saved_creds_vaultcmd.toml b/rules/windows/credential_access_saved_creds_vaultcmd.toml
index 267f0dbd4b3..c9ea2c6fd06 100644
--- a/rules/windows/credential_access_saved_creds_vaultcmd.toml
+++ b/rules/windows/credential_access_saved_creds_vaultcmd.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_suspicious_comsvcs_imageload.toml b/rules/windows/credential_access_suspicious_comsvcs_imageload.toml
index 0edd3a91adb..984be612988 100644
--- a/rules/windows/credential_access_suspicious_comsvcs_imageload.toml
+++ b/rules/windows/credential_access_suspicious_comsvcs_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -122,6 +122,7 @@ tags = [
     "Tactic: Credential Access",
     "Tactic: Defense Evasion",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/credential_access_suspicious_lsass_access_generic.toml b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
index 485c11e23fd..a92818305b6 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_generic.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_generic.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/22"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
index 0713059b17f..7de6d5c1369 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/07"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,7 @@ tags = [
     "Tactic: Credential Access",
     "Tactic:Execution",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
index 87e1f659a5b..16f3f87d237 100644
--- a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
+++ b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/14"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/windows/credential_access_veeam_backup_dll_imageload.toml b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
index bd118be9559..0af9521613a 100644
--- a/rules/windows/credential_access_veeam_backup_dll_imageload.toml
+++ b/rules/windows/credential_access_veeam_backup_dll_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_veeam_commands.toml b/rules/windows/credential_access_veeam_commands.toml
index e6ef29d0af2..bc8c45a3010 100644
--- a/rules/windows/credential_access_veeam_commands.toml
+++ b/rules/windows/credential_access_veeam_commands.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
index 5079015e5d8..f309e291d32 100644
--- a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
+++ b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/11/27"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,7 @@ tags = [
     "Tactic: Credential Access",
     "Data Source: Sysmon",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/credential_access_wbadmin_ntds.toml b/rules/windows/credential_access_wbadmin_ntds.toml
index 4d4522c3505..ae57b9cf421 100644
--- a/rules/windows/credential_access_wbadmin_ntds.toml
+++ b/rules/windows/credential_access_wbadmin_ntds.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_cve_2020_0601.toml b/rules/windows/defense_evasion_cve_2020_0601.toml
index 79b7ab563c4..509cd7ecc6b 100644
--- a/rules/windows/defense_evasion_cve_2020_0601.toml
+++ b/rules/windows/defense_evasion_cve_2020_0601.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/19"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Use Case: Vulnerability",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/defense_evasion_disable_nla.toml b/rules/windows/defense_evasion_disable_nla.toml
index a800ded1b6a..ab4dd964e69 100644
--- a/rules/windows/defense_evasion_disable_nla.toml
+++ b/rules/windows/defense_evasion_disable_nla.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/25"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_dns_over_https_enabled.toml b/rules/windows/defense_evasion_dns_over_https_enabled.toml
index f0f86bece75..6f4320c1a28 100644
--- a/rules/windows/defense_evasion_dns_over_https_enabled.toml
+++ b/rules/windows/defense_evasion_dns_over_https_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
index 7addd1e9894..10ea3f7162a 100644
--- a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
+++ b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
index 3c0a9fa6229..ed36351cc3e 100644
--- a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
+++ b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/09/08"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_execution_lolbas_wuauclt.toml b/rules/windows/defense_evasion_execution_lolbas_wuauclt.toml
index cf5e56ac3f0..7fb5ed0b999 100644
--- a/rules/windows/defense_evasion_execution_lolbas_wuauclt.toml
+++ b/rules/windows/defense_evasion_execution_lolbas_wuauclt.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/13"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -121,6 +121,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timeline_id = "e70679c2-6cde-4510-9764-4823df18f7db"
 timeline_title = "Comprehensive Process Timeline"
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
index af1ce25d157..3a6c445fe5e 100755
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
index f79ddd1543f..acddf3015c3 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
index 8019e38ae90..6ea24c21f18 100644
--- a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
+++ b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
index ff70e0608ef..6c7a52f2e63 100644
--- a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
+++ b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/03"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -39,6 +39,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
index 8783d5f48c5..f47b122f137 100644
--- a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
+++ b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/07"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_file_creation_mult_extension.toml b/rules/windows/defense_evasion_file_creation_mult_extension.toml
index 799681fa66f..aafffc95638 100644
--- a/rules/windows/defense_evasion_file_creation_mult_extension.toml
+++ b/rules/windows/defense_evasion_file_creation_mult_extension.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_from_unusual_directory.toml b/rules/windows/defense_evasion_from_unusual_directory.toml
index b6041af80d8..4b104019084 100644
--- a/rules/windows/defense_evasion_from_unusual_directory.toml
+++ b/rules/windows/defense_evasion_from_unusual_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/30"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -125,6 +125,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
index 9a21607c774..5e37948e8b9 100644
--- a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
+++ b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -20,7 +20,7 @@ name = "Encoded Executable Stored in the Registry"
 risk_score = 47
 rule_id = "93c1ce76-494c-4f01-8167-35edfb52f7b1"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_injection_msbuild.toml b/rules/windows/defense_evasion_injection_msbuild.toml
index 5f30009ec7f..0e10be09da9 100755
--- a/rules/windows/defense_evasion_injection_msbuild.toml
+++ b/rules/windows/defense_evasion_injection_msbuild.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Privilege Escalation",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_installutil_beacon.toml b/rules/windows/defense_evasion_installutil_beacon.toml
index e05dac115d5..d0f651bb220 100644
--- a/rules/windows/defense_evasion_installutil_beacon.toml
+++ b/rules/windows/defense_evasion_installutil_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
index a22ae82449a..adb57363689 100644
--- a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
+++ b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -39,7 +39,8 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: Crowdstrike"
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
index b07eb993349..e337ec5bd89 100644
--- a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
+++ b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
index 21ae1b42bb3..4ec3e5ee0e6 100644
--- a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
+++ b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/01"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Initial Access",
     "Tactic: Execution",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_masquerading_communication_apps.toml b/rules/windows/defense_evasion_masquerading_communication_apps.toml
index 4b23f49e150..9ea0e913d23 100644
--- a/rules/windows/defense_evasion_masquerading_communication_apps.toml
+++ b/rules/windows/defense_evasion_masquerading_communication_apps.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/05/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -24,6 +24,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
index 7dd3f37e2c5..30695cdb25f 100644
--- a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
+++ b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -46,6 +46,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_masquerading_trusted_directory.toml b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
index 9588637479f..9a47227299f 100644
--- a/rules/windows/defense_evasion_masquerading_trusted_directory.toml
+++ b/rules/windows/defense_evasion_masquerading_trusted_directory.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_mshta_beacon.toml b/rules/windows/defense_evasion_mshta_beacon.toml
index b4aedf2d7bf..103bb66acf9 100644
--- a/rules/windows/defense_evasion_mshta_beacon.toml
+++ b/rules/windows/defense_evasion_mshta_beacon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
index 0ac8984bed6..dde8076da1a 100644
--- a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
+++ b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_msxsl_network.toml b/rules/windows/defense_evasion_msxsl_network.toml
index df4d0df5c3a..4049b815df4 100644
--- a/rules/windows/defense_evasion_msxsl_network.toml
+++ b/rules/windows/defense_evasion_msxsl_network.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -33,6 +33,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
index 06a1944df1e..49a6b6d135d 100644
--- a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
+++ b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
index da759a65a09..c2a8f625a6d 100644
--- a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
+++ b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,7 +36,8 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
-    "Data Source: Microsoft Defender for Endpoint"
+    "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_posh_obfuscation.toml b/rules/windows/defense_evasion_posh_obfuscation.toml
index 86d61ee9038..8eac542095e 100644
--- a/rules/windows/defense_evasion_posh_obfuscation.toml
+++ b/rules/windows/defense_evasion_posh_obfuscation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/07/03"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -39,7 +39,7 @@ reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLo
 ```
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: PowerShell Logs"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: PowerShell Logs", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
index a7c64f85735..d76195296cf 100644
--- a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
+++ b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/31"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -33,6 +33,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
index 19915621cd3..00de7eaa076 100644
--- a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
+++ b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/31"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_root_dir_ads_creation.toml b/rules/windows/defense_evasion_root_dir_ads_creation.toml
index 3cca1c8c48f..53311fc30f5 100644
--- a/rules/windows/defense_evasion_root_dir_ads_creation.toml
+++ b/rules/windows/defense_evasion_root_dir_ads_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -39,6 +39,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_rundll32_no_arguments.toml b/rules/windows/defense_evasion_rundll32_no_arguments.toml
index 94c5fc8e2d9..1ec8daeccab 100644
--- a/rules/windows/defense_evasion_rundll32_no_arguments.toml
+++ b/rules/windows/defense_evasion_rundll32_no_arguments.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -110,6 +110,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_sccm_scnotification_dll.toml b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
index ce7f3d1945a..2e9bde60d3e 100644
--- a/rules/windows/defense_evasion_sccm_scnotification_dll.toml
+++ b/rules/windows/defense_evasion_sccm_scnotification_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
index d7e025b9080..e809d1593fe 100644
--- a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
+++ b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -33,6 +33,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_script_via_html_app.toml b/rules/windows/defense_evasion_script_via_html_app.toml
index 0fd01778684..4bd1aa2d2dd 100644
--- a/rules/windows/defense_evasion_script_via_html_app.toml
+++ b/rules/windows/defense_evasion_script_via_html_app.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,7 +36,8 @@ tags = [
     "Data Source: System",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
-    "Data Source: Microsoft Defender for Endpoint"
+    "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_sip_provider_mod.toml b/rules/windows/defense_evasion_sip_provider_mod.toml
index 19331910249..04bde56d0d8 100644
--- a/rules/windows/defense_evasion_sip_provider_mod.toml
+++ b/rules/windows/defense_evasion_sip_provider_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
index fdbf6b09ae8..9a2b2cf07ba 100644
--- a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
+++ b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
index f39fc337369..5d6f59d9c2b 100644
--- a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
+++ b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
index 469163116e8..f7dc5f1cb3b 100644
--- a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
+++ b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/21"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_suspicious_scrobj_load.toml b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
index c0ae6fd896f..b5b791d4e43 100644
--- a/rules/windows/defense_evasion_suspicious_scrobj_load.toml
+++ b/rules/windows/defense_evasion_suspicious_scrobj_load.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -28,6 +28,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_suspicious_wmi_script.toml b/rules/windows/defense_evasion_suspicious_wmi_script.toml
index 1c6049098fc..1320e4cf3c8 100644
--- a/rules/windows/defense_evasion_suspicious_wmi_script.toml
+++ b/rules/windows/defense_evasion_suspicious_wmi_script.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -33,6 +33,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_timestomp_sysmon.toml b/rules/windows/defense_evasion_timestomp_sysmon.toml
index 88b4706e8cd..0606703992f 100644
--- a/rules/windows/defense_evasion_timestomp_sysmon.toml
+++ b/rules/windows/defense_evasion_timestomp_sysmon.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
index cfa2ee3b6ac..ba8e90302ae 100644
--- a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
+++ b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/22"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -36,6 +36,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_unusual_dir_ads.toml b/rules/windows/defense_evasion_unusual_dir_ads.toml
index 8233ea44661..2f097277e2f 100644
--- a/rules/windows/defense_evasion_unusual_dir_ads.toml
+++ b/rules/windows/defense_evasion_unusual_dir_ads.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
index ad041ece384..28aae9651a0 100644
--- a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
+++ b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/05/28"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
index 642462efdd6..7a0a0084543 100644
--- a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
+++ b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_windows_filtering_platform.toml b/rules/windows/defense_evasion_windows_filtering_platform.toml
index c5fc9d3d38d..4a218a8d8d6 100644
--- a/rules/windows/defense_evasion_windows_filtering_platform.toml
+++ b/rules/windows/defense_evasion_windows_filtering_platform.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/defense_evasion_wsl_bash_exec.toml b/rules/windows/defense_evasion_wsl_bash_exec.toml
index 5833d334234..fcad58baebe 100644
--- a/rules/windows/defense_evasion_wsl_bash_exec.toml
+++ b/rules/windows/defense_evasion_wsl_bash_exec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_wsl_child_process.toml b/rules/windows/defense_evasion_wsl_child_process.toml
index 2d512a83575..d11044b038a 100644
--- a/rules/windows/defense_evasion_wsl_child_process.toml
+++ b/rules/windows/defense_evasion_wsl_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_wsl_enabled_via_dism.toml b/rules/windows/defense_evasion_wsl_enabled_via_dism.toml
index 5f800c77448..7b04e3b9830 100644
--- a/rules/windows/defense_evasion_wsl_enabled_via_dism.toml
+++ b/rules/windows/defense_evasion_wsl_enabled_via_dism.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/13"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -79,6 +79,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_wsl_filesystem.toml b/rules/windows/defense_evasion_wsl_filesystem.toml
index 2194a0c7734..f653d30cd3b 100644
--- a/rules/windows/defense_evasion_wsl_filesystem.toml
+++ b/rules/windows/defense_evasion_wsl_filesystem.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_wsl_kalilinux.toml b/rules/windows/defense_evasion_wsl_kalilinux.toml
index 5f960395ca9..62041755160 100644
--- a/rules/windows/defense_evasion_wsl_kalilinux.toml
+++ b/rules/windows/defense_evasion_wsl_kalilinux.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/defense_evasion_wsl_registry_modification.toml b/rules/windows/defense_evasion_wsl_registry_modification.toml
index 88aec487307..912dbf47093 100644
--- a/rules/windows/defense_evasion_wsl_registry_modification.toml
+++ b/rules/windows/defense_evasion_wsl_registry_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/12"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -75,6 +75,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timeline_id = "3e47ef71-ebfc-4520-975c-cb27fc090799"
 timeline_title = "Comprehensive Registry Timeline"
diff --git a/rules/windows/discovery_active_directory_webservice.toml b/rules/windows/discovery_active_directory_webservice.toml
index efdf8e87f3f..56600c5238b 100644
--- a/rules/windows/discovery_active_directory_webservice.toml
+++ b/rules/windows/discovery_active_directory_webservice.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/01/31"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/discovery_group_policy_object_discovery.toml b/rules/windows/discovery_group_policy_object_discovery.toml
index 67b36eb51d2..c987105ae77 100644
--- a/rules/windows/discovery_group_policy_object_discovery.toml
+++ b/rules/windows/discovery_group_policy_object_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/18"
 integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2024/11/02"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -76,6 +76,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/discovery_high_number_ad_properties.toml b/rules/windows/discovery_high_number_ad_properties.toml
index 2812442c999..167cf8700ff 100644
--- a/rules/windows/discovery_high_number_ad_properties.toml
+++ b/rules/windows/discovery_high_number_ad_properties.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,7 @@ tags = [
     "Data Source: System",
     "Data Source: Active Directory",
     "Data Source: Windows",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
index 473f7c010c7..28a0333b832 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -23,6 +23,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Rule Type: Higher-Order Rule",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
index 008bdcf02a5..59c71329549 100644
--- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
+++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2023/09/22"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -23,6 +23,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Discovery",
     "Rule Type: Higher-Order Rule",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
index d7dba5de5db..23a89fc7eda 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
index be11fac30d7..a3ec450fcf1 100644
--- a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
+++ b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/14"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_com_object_xwizard.toml b/rules/windows/execution_com_object_xwizard.toml
index 38c6178e3b9..337780fa2b0 100644
--- a/rules/windows/execution_com_object_xwizard.toml
+++ b/rules/windows/execution_com_object_xwizard.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -47,6 +47,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_command_shell_started_by_unusual_process.toml b/rules/windows/execution_command_shell_started_by_unusual_process.toml
index 1f315db6e92..40d0ede836f 100644
--- a/rules/windows/execution_command_shell_started_by_unusual_process.toml
+++ b/rules/windows/execution_command_shell_started_by_unusual_process.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ Hence for this rule to work effectively, users will need to add a custom ingest
 For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/execution_command_shell_via_rundll32.toml b/rules/windows/execution_command_shell_via_rundll32.toml
index 7c4018f74b8..ba8b8c5ee03 100644
--- a/rules/windows/execution_command_shell_via_rundll32.toml
+++ b/rules/windows/execution_command_shell_via_rundll32.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -30,6 +30,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
index 19d8848ddd5..906e6cd1566 100644
--- a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
+++ b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/25"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/execution_downloaded_shortcut_files.toml b/rules/windows/execution_downloaded_shortcut_files.toml
index 14910c23a7c..d4347a8e04b 100644
--- a/rules/windows/execution_downloaded_shortcut_files.toml
+++ b/rules/windows/execution_downloaded_shortcut_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -24,6 +24,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_downloaded_url_file.toml b/rules/windows/execution_downloaded_url_file.toml
index 44e9c9f7edc..c667ef43f73 100644
--- a/rules/windows/execution_downloaded_url_file.toml
+++ b/rules/windows/execution_downloaded_url_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,8 @@ tags = [
     "OS: Windows",
     "Use Case: Threat Detection",
     "Tactic: Execution",
-    "Data Source: Elastic Defend"
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_enumeration_via_wmiprvse.toml b/rules/windows/execution_enumeration_via_wmiprvse.toml
index 4c9361b5963..8fc3bdbc582 100644
--- a/rules/windows/execution_enumeration_via_wmiprvse.toml
+++ b/rules/windows/execution_enumeration_via_wmiprvse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_initial_access_foxmail_exploit.toml b/rules/windows/execution_initial_access_foxmail_exploit.toml
index 65f5265816b..d5253617a34 100644
--- a/rules/windows/execution_initial_access_foxmail_exploit.toml
+++ b/rules/windows/execution_initial_access_foxmail_exploit.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "m3
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -44,7 +44,8 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: SentinelOne",
     "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: Crowdstrike"
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_initial_access_wps_dll_exploit.toml b/rules/windows/execution_initial_access_wps_dll_exploit.toml
index a97691e343a..fb3d4878c02 100644
--- a/rules/windows/execution_initial_access_wps_dll_exploit.toml
+++ b/rules/windows/execution_initial_access_wps_dll_exploit.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/08/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,7 +31,8 @@ tags = [
     "Tactic: Initial Access",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
-    "Data Source: Sysmon"
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_mofcomp.toml b/rules/windows/execution_mofcomp.toml
index e0437780b30..20b9b7e993a 100644
--- a/rules/windows/execution_mofcomp.toml
+++ b/rules/windows/execution_mofcomp.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "m365_defender", "system", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: System",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_posh_hacktool_authors.toml b/rules/windows/execution_posh_hacktool_authors.toml
index bf725c875f0..533032a5737 100644
--- a/rules/windows/execution_posh_hacktool_authors.toml
+++ b/rules/windows/execution_posh_hacktool_authors.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/08"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: PowerShell Logs",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/execution_posh_hacktool_functions.toml b/rules/windows/execution_posh_hacktool_functions.toml
index 9bf1665b176..a2af29b70df 100644
--- a/rules/windows/execution_posh_hacktool_functions.toml
+++ b/rules/windows/execution_posh_hacktool_functions.toml
@@ -4,7 +4,7 @@ integration = ["windows"]
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2024/10/28"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -132,7 +132,7 @@ reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLo
 ```
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: PowerShell Logs"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: PowerShell Logs", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/windows/execution_powershell_susp_args_via_winscript.toml b/rules/windows/execution_powershell_susp_args_via_winscript.toml
index f30e70b329e..1727b9e0841 100644
--- a/rules/windows/execution_powershell_susp_args_via_winscript.toml
+++ b/rules/windows/execution_powershell_susp_args_via_winscript.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,7 +34,8 @@ tags = [
     "Data Source: System",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
-    "Data Source: Microsoft Defender for Endpoint"
+    "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_scheduled_task_powershell_source.toml b/rules/windows/execution_scheduled_task_powershell_source.toml
index ee67119a823..342cf86e9e1 100644
--- a/rules/windows/execution_scheduled_task_powershell_source.toml
+++ b/rules/windows/execution_scheduled_task_powershell_source.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/execution_shared_modules_local_sxs_dll.toml b/rules/windows/execution_shared_modules_local_sxs_dll.toml
index 84866b389cc..f492ba75def 100644
--- a/rules/windows/execution_shared_modules_local_sxs_dll.toml
+++ b/rules/windows/execution_shared_modules_local_sxs_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/28"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_suspicious_cmd_wmi.toml b/rules/windows/execution_suspicious_cmd_wmi.toml
index d1a2af0d4d0..5e303c4926f 100644
--- a/rules/windows/execution_suspicious_cmd_wmi.toml
+++ b/rules/windows/execution_suspicious_cmd_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
index eac4b42c6d1..be4da0bf53a 100644
--- a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
+++ b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_via_mmc_console_file_unusual_path.toml b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
index d862eb3e601..4332f536c06 100644
--- a/rules/windows/execution_via_mmc_console_file_unusual_path.toml
+++ b/rules/windows/execution_via_mmc_console_file_unusual_path.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: System",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_windows_cmd_shell_susp_args.toml b/rules/windows/execution_windows_cmd_shell_susp_args.toml
index 9c6ff62c9d8..5a88fc403bb 100644
--- a/rules/windows/execution_windows_cmd_shell_susp_args.toml
+++ b/rules/windows/execution_windows_cmd_shell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -35,7 +35,8 @@ tags = [
     "Data Source: System",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
-    "Data Source: Microsoft Defender for Endpoint"
+    "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/execution_windows_powershell_susp_args.toml b/rules/windows/execution_windows_powershell_susp_args.toml
index 20255b8da08..ae2af935e1e 100644
--- a/rules/windows/execution_windows_powershell_susp_args.toml
+++ b/rules/windows/execution_windows_powershell_susp_args.toml
@@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender"
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -37,7 +37,8 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Microsoft Defender for Endpoint",
-    "Data Source: Crowdstrike"
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/exfiltration_smb_rare_destination.toml b/rules/windows/exfiltration_smb_rare_destination.toml
index 0cb0164fae0..68dd5e0a326 100644
--- a/rules/windows/exfiltration_smb_rare_destination.toml
+++ b/rules/windows/exfiltration_smb_rare_destination.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -38,6 +38,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
index ac75c10eeff..83b0ab0edd9 100644
--- a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
+++ b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/07/03"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -69,6 +69,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Initial Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/initial_access_execution_from_inetcache.toml b/rules/windows/initial_access_execution_from_inetcache.toml
index 9d5103044ed..b82f05ddd39 100644
--- a/rules/windows/initial_access_execution_from_inetcache.toml
+++ b/rules/windows/initial_access_execution_from_inetcache.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/02/14"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_execution_from_removable_media.toml b/rules/windows/initial_access_execution_from_removable_media.toml
index 5766e343336..839778a74ba 100644
--- a/rules/windows/initial_access_execution_from_removable_media.toml
+++ b/rules/windows/initial_access_execution_from_removable_media.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Initial Access",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/initial_access_execution_remote_via_msiexec.toml b/rules/windows/initial_access_execution_remote_via_msiexec.toml
index dc6ed9752e6..313b2343f65 100644
--- a/rules/windows/initial_access_execution_remote_via_msiexec.toml
+++ b/rules/windows/initial_access_execution_remote_via_msiexec.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/28"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Tactic: Initial Access",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/initial_access_execution_via_office_addins.toml b/rules/windows/initial_access_execution_via_office_addins.toml
index 56613b344b9..153315f0ba3 100644
--- a/rules/windows/initial_access_execution_via_office_addins.toml
+++ b/rules/windows/initial_access_execution_via_office_addins.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/20"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
index 79e582948bc..e1355901be6 100644
--- a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
+++ b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funne
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -42,6 +42,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
index 4d13c128a10..70c97bfab8b 100644
--- a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
+++ b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/24"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -50,6 +50,7 @@ tags = [
     "Data Source: System",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_rdp_file_mail_attachment.toml b/rules/windows/initial_access_rdp_file_mail_attachment.toml
index a871baa51cd..b0ddbfd18fc 100644
--- a/rules/windows/initial_access_rdp_file_mail_attachment.toml
+++ b/rules/windows/initial_access_rdp_file_mail_attachment.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/05"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_scripts_process_started_via_wmi.toml b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
index 044ba963d33..9676c40e1b9 100644
--- a/rules/windows/initial_access_scripts_process_started_via_wmi.toml
+++ b/rules/windows/initial_access_scripts_process_started_via_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/27"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_files.toml b/rules/windows/initial_access_suspicious_ms_exchange_files.toml
index 888d366dfc3..07be27f4b51 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_files.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_files.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/04"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -55,6 +55,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
index 241e38d5f37..23a6f57b7d8 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -54,6 +54,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
index 86ecd1a4eff..8ed1234cc95 100644
--- a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
+++ b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/08"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
index fffa2b5ff7d..c92b3bf2588 100644
--- a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
+++ b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/29"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_webshell_screenconnect_server.toml b/rules/windows/initial_access_webshell_screenconnect_server.toml
index 52b864f3473..825813db77c 100644
--- a/rules/windows/initial_access_webshell_screenconnect_server.toml
+++ b/rules/windows/initial_access_webshell_screenconnect_server.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/03/26"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/initial_access_xsl_script_execution_via_com.toml b/rules/windows/initial_access_xsl_script_execution_via_com.toml
index 13b584e0072..2a1b8903abd 100644
--- a/rules/windows/initial_access_xsl_script_execution_via_com.toml
+++ b/rules/windows/initial_access_xsl_script_execution_via_com.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/09/27"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Tactic: Initial Access",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_alternate_creds_pth.toml b/rules/windows/lateral_movement_alternate_creds_pth.toml
index 409253b4994..07634e0f4f1 100644
--- a/rules/windows/lateral_movement_alternate_creds_pth.toml
+++ b/rules/windows/lateral_movement_alternate_creds_pth.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/03/29"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -22,7 +22,7 @@ references = ["https://attack.mitre.org/techniques/T1550/002/"]
 risk_score = 47
 rule_id = "daafdf96-e7b1-4f14-b494-27e0d24b11f6"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Lateral Movement", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Lateral Movement", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "new_terms"
 
diff --git a/rules/windows/lateral_movement_cmd_service.toml b/rules/windows/lateral_movement_cmd_service.toml
index f910804003d..4ad06eacfbe 100644
--- a/rules/windows/lateral_movement_cmd_service.toml
+++ b/rules/windows/lateral_movement_cmd_service.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_dcom_hta.toml b/rules/windows/lateral_movement_dcom_hta.toml
index 951d44f30f5..b9061b5cb2c 100644
--- a/rules/windows/lateral_movement_dcom_hta.toml
+++ b/rules/windows/lateral_movement_dcom_hta.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_dcom_mmc20.toml b/rules/windows/lateral_movement_dcom_mmc20.toml
index 09242c803f7..d52089db2a5 100644
--- a/rules/windows/lateral_movement_dcom_mmc20.toml
+++ b/rules/windows/lateral_movement_dcom_mmc20.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
index e687fb54546..b810f2ddc96 100644
--- a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
+++ b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/06"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
index 10103cf2219..0b12322e3fe 100644
--- a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
+++ b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/22"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
index 94c51ea7347..5fc5de9d829 100644
--- a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
+++ b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/04/12"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
index be355399c39..a395ee0cc3e 100644
--- a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
+++ b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
index 63dd096c831..5997eaad182 100644
--- a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
+++ b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -38,6 +38,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_incoming_wmi.toml b/rules/windows/lateral_movement_incoming_wmi.toml
index 2c4023b98ed..20f3b01c567 100644
--- a/rules/windows/lateral_movement_incoming_wmi.toml
+++ b/rules/windows/lateral_movement_incoming_wmi.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
index c7520b671ba..281a95b8377 100644
--- a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
+++ b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/02"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_powershell_remoting_target.toml b/rules/windows/lateral_movement_powershell_remoting_target.toml
index 66687eb8971..86d159976c9 100644
--- a/rules/windows/lateral_movement_powershell_remoting_target.toml
+++ b/rules/windows/lateral_movement_powershell_remoting_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/24"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,7 @@ tags = [
     "Tactic: Execution",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_rdp_sharprdp_target.toml b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
index 87cd14e4b09..2ba965eb464 100644
--- a/rules/windows/lateral_movement_rdp_sharprdp_target.toml
+++ b/rules/windows/lateral_movement_rdp_sharprdp_target.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/11"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Lateral Movement",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
index cfecd7784a1..3a97c0d49cb 100644
--- a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
+++ b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_remote_service_installed_winlog.toml b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
index 979e47a2a5e..e0677bd800f 100644
--- a/rules/windows/lateral_movement_remote_service_installed_winlog.toml
+++ b/rules/windows/lateral_movement_remote_service_installed_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -27,6 +27,7 @@ tags = [
     "Tactic: Lateral Movement",
     "Tactic: Persistence",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_remote_task_creation_winlog.toml b/rules/windows/lateral_movement_remote_task_creation_winlog.toml
index 9f3e2a2aa20..320256e10f6 100644
--- a/rules/windows/lateral_movement_remote_task_creation_winlog.toml
+++ b/rules/windows/lateral_movement_remote_task_creation_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,7 +46,7 @@ note = """## Triage and analysis
 risk_score = 47
 rule_id = "9c865691-5599-447a-bac9-b3f2df5f9a9d"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Lateral Movement", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Lateral Movement", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
index 96b7dc745de..49b26a6d28e 100644
--- a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
+++ b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -40,6 +40,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml b/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml
index b05d4e7181d..42019854bb7 100644
--- a/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml
+++ b/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/16"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,6 +41,7 @@ tags = [
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
index 9ab20fa2ec1..51f0b83aabc 100644
--- a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
+++ b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/lateral_movement_via_wsus_update.toml b/rules/windows/lateral_movement_via_wsus_update.toml
index 84f80c175e8..97d363b1bb5 100644
--- a/rules/windows/lateral_movement_via_wsus_update.toml
+++ b/rules/windows/lateral_movement_via_wsus_update.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -34,6 +34,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: System",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_ad_adminsdholder.toml b/rules/windows/persistence_ad_adminsdholder.toml
index b3e5290c506..9cbede4e62d 100644
--- a/rules/windows/persistence_ad_adminsdholder.toml
+++ b/rules/windows/persistence_ad_adminsdholder.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/31"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Use Case: Active Directory Monitoring",
     "Data Source: Active Directory",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/persistence_app_compat_shim.toml b/rules/windows/persistence_app_compat_shim.toml
index 76305ef6512..caae92210c6 100644
--- a/rules/windows/persistence_app_compat_shim.toml
+++ b/rules/windows/persistence_app_compat_shim.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -30,6 +30,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_appcertdlls_registry.toml b/rules/windows/persistence_appcertdlls_registry.toml
index 1865843e22e..6a6a98051b5 100644
--- a/rules/windows/persistence_appcertdlls_registry.toml
+++ b/rules/windows/persistence_appcertdlls_registry.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,7 +28,7 @@ Hence for this rule to work effectively, users will need to add a custom ingest
 For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Tactic: Privilege Escalation", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Tactic: Privilege Escalation", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/persistence_browser_extension_install.toml b/rules/windows/persistence_browser_extension_install.toml
index 4174fcad514..b4876433481 100644
--- a/rules/windows/persistence_browser_extension_install.toml
+++ b/rules/windows/persistence_browser_extension_install.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -37,6 +37,7 @@ tags = [
     "Data Source: SentinelOne",
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_evasion_registry_ifeo_injection.toml b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
index 95c2605548a..94f25c785e8 100644
--- a/rules/windows/persistence_evasion_registry_ifeo_injection.toml
+++ b/rules/windows/persistence_evasion_registry_ifeo_injection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_group_modification_by_system.toml b/rules/windows/persistence_group_modification_by_system.toml
index b8e58cf5b5d..f2ccb9cea65 100644
--- a/rules/windows/persistence_group_modification_by_system.toml
+++ b/rules/windows/persistence_group_modification_by_system.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/26"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -29,6 +29,7 @@ tags = [
     "Use Case: Active Directory Monitoring",
     "Data Source: Active Directory",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_local_scheduled_job_creation.toml b/rules/windows/persistence_local_scheduled_job_creation.toml
index 50807113eae..d6ffe953c3e 100644
--- a/rules/windows/persistence_local_scheduled_job_creation.toml
+++ b/rules/windows/persistence_local_scheduled_job_creation.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +21,7 @@ name = "Persistence via Scheduled Job Creation"
 risk_score = 47
 rule_id = "1327384f-00f3-44d5-9a8c-2373ba071e92"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/persistence_local_scheduled_task_creation.toml b/rules/windows/persistence_local_scheduled_task_creation.toml
index 0f0af265a6e..75b3674a23c 100644
--- a/rules/windows/persistence_local_scheduled_task_creation.toml
+++ b/rules/windows/persistence_local_scheduled_task_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/persistence_local_scheduled_task_scripting.toml b/rules/windows/persistence_local_scheduled_task_scripting.toml
index 2dcdda69129..caa7c4dfb56 100644
--- a/rules/windows/persistence_local_scheduled_task_scripting.toml
+++ b/rules/windows/persistence_local_scheduled_task_scripting.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -39,6 +39,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/persistence_ms_office_addins_file.toml b/rules/windows/persistence_ms_office_addins_file.toml
index 9d717776903..b85c801827d 100644
--- a/rules/windows/persistence_ms_office_addins_file.toml
+++ b/rules/windows/persistence_ms_office_addins_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/16"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -28,6 +28,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_ms_outlook_vba_template.toml b/rules/windows/persistence_ms_outlook_vba_template.toml
index 6fdda2ca076..5ce927e6f48 100644
--- a/rules/windows/persistence_ms_outlook_vba_template.toml
+++ b/rules/windows/persistence_ms_outlook_vba_template.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
index b1882952650..7aa73ce88ba 100644
--- a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
+++ b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,7 @@ tags = [
     "Use Case: Active Directory Monitoring",
     "Data Source: Active Directory",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_msi_installer_task_startup.toml b/rules/windows/persistence_msi_installer_task_startup.toml
index 41d2ec87868..67b1a2b8cf3 100644
--- a/rules/windows/persistence_msi_installer_task_startup.toml
+++ b/rules/windows/persistence_msi_installer_task_startup.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/05"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_msoffice_startup_registry.toml b/rules/windows/persistence_msoffice_startup_registry.toml
index 0ce759403e7..ac992d40a27 100644
--- a/rules/windows/persistence_msoffice_startup_registry.toml
+++ b/rules/windows/persistence_msoffice_startup_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/22"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
 
@@ -34,6 +34,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_netsh_helper_dll.toml b/rules/windows/persistence_netsh_helper_dll.toml
index 66d617019b5..508ccf74a61 100644
--- a/rules/windows/persistence_netsh_helper_dll.toml
+++ b/rules/windows/persistence_netsh_helper_dll.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
index 994ee60354a..f5f4de86e14 100644
--- a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
+++ b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/15"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -48,6 +48,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_powershell_profiles.toml b/rules/windows/persistence_powershell_profiles.toml
index cbdb75da78a..e3c215d1b04 100644
--- a/rules/windows/persistence_powershell_profiles.toml
+++ b/rules/windows/persistence_powershell_profiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -115,6 +115,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_registry_uncommon.toml b/rules/windows/persistence_registry_uncommon.toml
index a76f2078d51..bdfb1d87180 100644
--- a/rules/windows/persistence_registry_uncommon.toml
+++ b/rules/windows/persistence_registry_uncommon.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timeline_id = "3e47ef71-ebfc-4520-975c-cb27fc090799"
 timeline_title = "Comprehensive Registry Timeline"
diff --git a/rules/windows/persistence_remote_password_reset.toml b/rules/windows/persistence_remote_password_reset.toml
index e0d4bc2a0ad..bf4d87a544d 100644
--- a/rules/windows/persistence_remote_password_reset.toml
+++ b/rules/windows/persistence_remote_password_reset.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/18"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -72,6 +72,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Impact",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
index 27b0bd36a04..9c3d573ec62 100644
--- a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
+++ b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -28,6 +28,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/persistence_scheduled_task_creation_winlog.toml b/rules/windows/persistence_scheduled_task_creation_winlog.toml
index d9189b041f7..0fc48132dbf 100644
--- a/rules/windows/persistence_scheduled_task_creation_winlog.toml
+++ b/rules/windows/persistence_scheduled_task_creation_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -22,7 +22,7 @@ references = ["https://docs.microsoft.com/en-us/windows/security/threat-protecti
 risk_score = 21
 rule_id = "92a6faf5-78ec-4e25-bea1-73bacc9b59d9"
 severity = "low"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/persistence_scheduled_task_updated.toml b/rules/windows/persistence_scheduled_task_updated.toml
index e30a9a997f0..965fe695ee4 100644
--- a/rules/windows/persistence_scheduled_task_updated.toml
+++ b/rules/windows/persistence_scheduled_task_updated.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -23,7 +23,7 @@ references = ["https://docs.microsoft.com/en-us/windows/security/threat-protecti
 risk_score = 47
 rule_id = "a02cb68e-7c93-48d1-93b2-2c39023308eb"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/persistence_service_dll_unsigned.toml b/rules/windows/persistence_service_dll_unsigned.toml
index 4b6d121d56d..cbd24408d74 100644
--- a/rules/windows/persistence_service_dll_unsigned.toml
+++ b/rules/windows/persistence_service_dll_unsigned.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/01/17"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -29,6 +29,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_services_registry.toml b/rules/windows/persistence_services_registry.toml
index fa49dd597cc..45a0fd20e7b 100644
--- a/rules/windows/persistence_services_registry.toml
+++ b/rules/windows/persistence_services_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_suspicious_image_load_scheduled_task_ms_office.toml b/rules/windows/persistence_suspicious_image_load_scheduled_task_ms_office.toml
index cfed5a4d340..c72413962e6 100644
--- a/rules/windows/persistence_suspicious_image_load_scheduled_task_ms_office.toml
+++ b/rules/windows/persistence_suspicious_image_load_scheduled_task_ms_office.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/17"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -134,6 +134,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
index 927d6a770e8..299d5b21d10 100644
--- a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
+++ b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/19"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_suspicious_service_created_registry.toml b/rules/windows/persistence_suspicious_service_created_registry.toml
index 1d9222bdcc2..ff5705b38f7 100644
--- a/rules/windows/persistence_suspicious_service_created_registry.toml
+++ b/rules/windows/persistence_suspicious_service_created_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_sysmon_wmi_event_subscription.toml b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
index 43cb06a7463..c8428323a3a 100644
--- a/rules/windows/persistence_sysmon_wmi_event_subscription.toml
+++ b/rules/windows/persistence_sysmon_wmi_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/02/02"
 integration = ["windows", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.15.0"
 min_stack_comments = "Elastic Defend WMI events were added in Elastic Defend 8.15.0."
 
@@ -30,7 +30,8 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Persistence",
     "Data Source: Sysmon",
-    "Data Source: Elastic Defend"
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_temp_scheduled_task.toml b/rules/windows/persistence_temp_scheduled_task.toml
index c2017b528e0..cb6d8198c9c 100644
--- a/rules/windows/persistence_temp_scheduled_task.toml
+++ b/rules/windows/persistence_temp_scheduled_task.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -29,6 +29,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Execution",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/persistence_time_provider_mod.toml b/rules/windows/persistence_time_provider_mod.toml
index a0a99130517..1eaaacfecdc 100644
--- a/rules/windows/persistence_time_provider_mod.toml
+++ b/rules/windows/persistence_time_provider_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/19"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -110,6 +110,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_user_account_creation_event_logs.toml b/rules/windows/persistence_user_account_creation_event_logs.toml
index e41500205c5..745c43fab0e 100644
--- a/rules/windows/persistence_user_account_creation_event_logs.toml
+++ b/rules/windows/persistence_user_account_creation_event_logs.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/04"
 integration = ["system", "windows"]
 maturity = "development"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -26,7 +26,7 @@ name = "Windows User Account Creation"
 risk_score = 21
 rule_id = "38e17753-f581-4644-84da-0d60a8318694"
 severity = "low"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "query"
 
diff --git a/rules/windows/persistence_via_application_shimming.toml b/rules/windows/persistence_via_application_shimming.toml
index f964057cf03..c793e24f1b2 100644
--- a/rules/windows/persistence_via_application_shimming.toml
+++ b/rules/windows/persistence_via_application_shimming.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_via_bits_job_notify_command.toml b/rules/windows/persistence_via_bits_job_notify_command.toml
index 3855f3916fd..426b95c70fa 100644
--- a/rules/windows/persistence_via_bits_job_notify_command.toml
+++ b/rules/windows/persistence_via_bits_job_notify_command.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ references = [
 risk_score = 47
 rule_id = "c3b915e0-22f3-4bf7-991d-b643513c722f"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Persistence", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", "Data Source: Microsoft Defender for Endpoint", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/persistence_via_hidden_run_key_valuename.toml b/rules/windows/persistence_via_hidden_run_key_valuename.toml
index faa2520ad7a..293ceeb1f54 100644
--- a/rules/windows/persistence_via_hidden_run_key_valuename.toml
+++ b/rules/windows/persistence_via_hidden_run_key_valuename.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/15"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
index 70d0e39ea6b..3c6f26520bd 100644
--- a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
+++ b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/18"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
index eca03a9c2e4..de038724dcd 100644
--- a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
+++ b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/17"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
index 5ad0590055c..4c823fbb703 100644
--- a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
+++ b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/04"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -45,6 +45,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_via_wmi_stdregprov_run_services.toml b/rules/windows/persistence_via_wmi_stdregprov_run_services.toml
index 913d5984024..beaf856303c 100644
--- a/rules/windows/persistence_via_wmi_stdregprov_run_services.toml
+++ b/rules/windows/persistence_via_wmi_stdregprov_run_services.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/03/15"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/08/05"
+updated_date = "2025/01/15"
 
 [transform]
 [[transform.osquery]]
@@ -107,6 +107,7 @@ tags = [
     "Tactic: Persistence",
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/persistence_werfault_reflectdebugger.toml b/rules/windows/persistence_werfault_reflectdebugger.toml
index 9f5c4815a8a..799049a573b 100644
--- a/rules/windows/persistence_werfault_reflectdebugger.toml
+++ b/rules/windows/persistence_werfault_reflectdebugger.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/29"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_create_process_as_different_user.toml b/rules/windows/privilege_escalation_create_process_as_different_user.toml
index d927209abcb..ac063ad6085 100644
--- a/rules/windows/privilege_escalation_create_process_as_different_user.toml
+++ b/rules/windows/privilege_escalation_create_process_as_different_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/30"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,7 +31,7 @@ Hence for this rule to work effectively, users will need to add a custom ingest
 For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''
diff --git a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
index 01b346b5c6e..ab8e8584da6 100644
--- a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
+++ b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/10/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_credroaming_ldap.toml b/rules/windows/privilege_escalation_credroaming_ldap.toml
index 17ef783d74e..a3bfa6edce0 100644
--- a/rules/windows/privilege_escalation_credroaming_ldap.toml
+++ b/rules/windows/privilege_escalation_credroaming_ldap.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/11/09"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -51,6 +51,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Use Case: Active Directory Monitoring",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
index 2f10fa49cf7..00b8597b887 100644
--- a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
+++ b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/29"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,7 +31,8 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
-    "Data Source: Sysmon"
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_expired_driver_loaded.toml b/rules/windows/privilege_escalation_expired_driver_loaded.toml
index 16c62b43955..d96ccf10bfe 100644
--- a/rules/windows/privilege_escalation_expired_driver_loaded.toml
+++ b/rules/windows/privilege_escalation_expired_driver_loaded.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Tactic: Privilege Escalation",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_exploit_cve_202238028.toml b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
index 16dda31a156..760a2e136ca 100644
--- a/rules/windows/privilege_escalation_exploit_cve_202238028.toml
+++ b/rules/windows/privilege_escalation_exploit_cve_202238028.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/23"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
index 046d36517ec..422f24a07d1 100644
--- a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
+++ b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
index a09d848795b..b8a24031faa 100644
--- a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
+++ b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/04/27"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -36,6 +36,7 @@ tags = [
     "Use Case: Active Directory Monitoring",
     "Data Source: Active Directory",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/privilege_escalation_lsa_auth_package.toml b/rules/windows/privilege_escalation_lsa_auth_package.toml
index d0059930a6e..24dcc87b0fe 100644
--- a/rules/windows/privilege_escalation_lsa_auth_package.toml
+++ b/rules/windows/privilege_escalation_lsa_auth_package.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_make_token_local.toml b/rules/windows/privilege_escalation_make_token_local.toml
index 41668e89b33..b914821a3bd 100644
--- a/rules/windows/privilege_escalation_make_token_local.toml
+++ b/rules/windows/privilege_escalation_make_token_local.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/12/04"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,7 +31,7 @@ Hence for this rule to work effectively, users will need to add a custom ingest
 For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 """
 severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
index be7d35953a3..962de6246e1 100644
--- a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
+++ b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel", "m365_defender", "window
 maturity = "production"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 min_stack_version = "8.14.0"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -40,7 +40,8 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
-    "Data Source: Microsoft Defender for Endpoint"
+    "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
index 217720c4d67..2ca31c548a8 100644
--- a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
+++ b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/11/15"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -21,7 +21,7 @@ references = ["https://www.elastic.co/pt/blog/how-attackers-abuse-access-token-m
 risk_score = 47
 rule_id = "e468f3f6-7c4c-45bb-846a-053738b3fe5d"
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "new_terms"
 
diff --git a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
index f1b31bfb038..507d5cfaa98 100644
--- a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
+++ b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/01/21"
 integration = ["endpoint", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Elastic Defend",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_posh_token_impersonation.toml b/rules/windows/privilege_escalation_posh_token_impersonation.toml
index 5e72db6df43..96dd6f78538 100644
--- a/rules/windows/privilege_escalation_posh_token_impersonation.toml
+++ b/rules/windows/privilege_escalation_posh_token_impersonation.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/17"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -136,6 +136,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: PowerShell Logs",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "query"
diff --git a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
index 4bd1489ae45..410f3e64a76 100644
--- a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
+++ b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 
diff --git a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
index 9092b398fd8..30d052601d3 100644
--- a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
+++ b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/14"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
index db16d8cff8d..a4d9dff6d29 100644
--- a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
+++ b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -38,6 +38,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
index 07410769673..12a9f06a241 100644
--- a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
+++ b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/06/05"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,7 +31,8 @@ tags = [
     "Tactic: Execution",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
-    "Data Source: Sysmon"
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide"
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
index efe2906a9a0..fb4436a95de 100644
--- a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
+++ b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/26"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
index 29634909505..4aace1a6984 100644
--- a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
+++ b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/12/12"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -46,6 +46,7 @@ tags = [
     "Data Source: Active Directory",
     "Use Case: Vulnerability",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
index d7d6c76b831..41a65bc6b8a 100644
--- a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
+++ b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/11"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Active Directory",
     "Use Case: Vulnerability",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
index 99e2eaf727e..52e443aa257 100644
--- a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
+++ b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -41,7 +41,7 @@ Token Right Adjusted Events (Success)
 ```
 """
 severity = "medium"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: System", "Resources: Investigation Guide"]
 timestamp_override = "event.ingested"
 type = "eql"
 
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
index 81fd695d2d7..db3e02e1630 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/28"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -33,6 +33,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
index 296f0872a56..37eb6ce566f 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -33,6 +33,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
index 2ef4a271bb8..336f80f317d 100644
--- a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/19"
 integration = ["endpoint", "windows", "m365_defender"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -31,6 +31,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
index 9d358d020ba..51089dc7fbc 100644
--- a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/08/18"
 integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -44,6 +44,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
index 262c8627f65..dc35aabe197 100644
--- a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
+++ b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/27"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -35,6 +35,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_unquoted_service_path.toml b/rules/windows/privilege_escalation_unquoted_service_path.toml
index ec35cb10cb9..3b1f94308a9 100644
--- a/rules/windows/privilege_escalation_unquoted_service_path.toml
+++ b/rules/windows/privilege_escalation_unquoted_service_path.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/13"
 integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Sysmon",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
index fd55fddace1..09b99466e1d 100644
--- a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
+++ b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/07/06"
 integration = ["endpoint", "windows", "system"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -43,6 +43,7 @@ tags = [
     "Use Case: Vulnerability",
     "Data Source: Elastic Defend",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
index 35dba0aaade..d2e8805865a 100644
--- a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
+++ b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/10/13"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -32,6 +32,7 @@ tags = [
     "Data Source: Sysmon",
     "Data Source: Microsoft Defender for Endpoint",
     "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_via_ppid_spoofing.toml b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
index e5984252cb7..c46205436f9 100644
--- a/rules/windows/privilege_escalation_via_ppid_spoofing.toml
+++ b/rules/windows/privilege_escalation_via_ppid_spoofing.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -30,6 +30,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
index 0c53307e8d4..bcb02117785 100644
--- a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
+++ b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml
@@ -2,7 +2,7 @@
 creation_date = "2021/10/13"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -42,6 +42,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_via_token_theft.toml b/rules/windows/privilege_escalation_via_token_theft.toml
index cd263b5a012..115e4a75c6e 100644
--- a/rules/windows/privilege_escalation_via_token_theft.toml
+++ b/rules/windows/privilege_escalation_via_token_theft.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/10/20"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -28,6 +28,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
index 8ad0c4f7a64..96324cd62b3 100644
--- a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
+++ b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/02/07"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -49,6 +49,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
     "Data Source: System",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/windows/privilege_escalation_wpad_exploitation.toml b/rules/windows/privilege_escalation_wpad_exploitation.toml
index 51a6807000f..3720a8cc335 100644
--- a/rules/windows/privilege_escalation_wpad_exploitation.toml
+++ b/rules/windows/privilege_escalation_wpad_exploitation.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/09/02"
 integration = ["endpoint"]
 maturity = "development"
-updated_date = "2025/01/10"
+updated_date = "2025/01/15"
 
 [rule]
 author = ["Elastic"]
@@ -19,7 +19,7 @@ name = "WPAD Service Exploit"
 risk_score = 73
 rule_id = "ec328da1-d5df-482b-866c-4a435692b1f3"
 severity = "high"
-tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: Elastic Defend"]
+tags = ["Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Data Source: Elastic Defend", "Resources: Investigation Guide"]
 type = "eql"
 
 query = '''

From defcd7f9d084c3150987985d671e7dadd67bf3a3 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Wed, 15 Jan 2025 10:33:14 -0600
Subject: [PATCH 12/16] bump pyproject.toml version

---
 pyproject.toml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pyproject.toml b/pyproject.toml
index 962098d33d7..42513569cc4 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -1,6 +1,6 @@
 [project]
 name = "detection_rules"
-version = "0.3.17"
+version = "0.3.18"
 description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine."
 readme = "README.md"
 requires-python = ">=3.12"

From fe66adb3f2ec3d817db614aa8855f8054e369011 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <Mika.ayenson@elastic.co>
Date: Fri, 17 Jan 2025 08:51:56 -0600
Subject: [PATCH 13/16] Add unit test for guide consistency

---
 ...overy_new_terms_sts_getcalleridentity.toml |  4 +-
 ...icy_added_for_external_account_access.toml |  4 +-
 ...user_via_assumed_role_on_ec2_instance.toml |  4 +-
 ...tomer_managed_policy_attached_to_role.toml |  2 +-
 ..._bedrock_execution_without_guardrails.toml |  8 +--
 ...ls_multiple_violations_by_single_user.toml |  4 +-
 ...multiple_violations_in_single_request.toml |  4 +-
 ...confidence_misconduct_blocks_detected.toml | 18 +++---
 ...k_high_resource_consumption_detection.toml |  4 +-
 ...attempts_to_use_denied_models_by_user.toml |  4 +-
 ...ve_information_policy_blocks_detected.toml |  6 +-
 ...multiple_topic_policy_blocks_detected.toml |  6 +-
 ...ation_exception_errors_by_single_user.toml |  4 +-
 ..._multiple_word_policy_blocks_detected.toml |  6 +-
 ...vasion_elastic_memory_threat_detected.toml |  4 +-
 ...asion_elastic_memory_threat_prevented.toml |  2 +-
 ...c_endpoint_security_behavior_detected.toml |  4 +-
 ..._endpoint_security_behavior_prevented.toml |  4 +-
 ...ution_elastic_malicious_file_detected.toml |  4 +-
 ...tion_elastic_malicious_file_prevented.toml |  4 +-
 .../impact_elastic_ransomware_detected.toml   |  4 +-
 .../impact_elastic_ransomware_prevented.toml  |  4 +-
 ...65_potential_password_spraying_attack.toml | 39 +------------
 ...l_okta_bombing_via_push_notifications.toml |  4 +-
 ..._and_control_linux_ssh_x11_forwarding.toml | 10 ++--
 ...er_or_listener_established_via_netcat.toml |  4 +-
 .../execution_shell_evasion_linux_binary.toml | 18 +++---
 ..._linux_user_added_to_privileged_group.toml |  6 +-
 ...l_access_ml_linux_anomalous_user_name.toml |  4 +-
 ...access_ml_windows_anomalous_user_name.toml |  4 +-
 ...windows_rare_user_type10_remote_login.toml |  4 +-
 .../ml_linux_anomalous_network_activity.toml  |  4 +-
 ...ml_windows_anomalous_network_activity.toml |  4 +-
 ...ial_access_mimikatz_powershell_module.toml |  4 +-
 ...execution_initial_access_via_msc_file.toml |  4 +-
 ...vement_direct_outbound_smb_connection.toml |  4 +-
 ..._movement_remote_task_creation_winlog.toml |  6 +-
 ...ement_unusual_dns_service_file_writes.toml |  4 +-
 tests/test_all_rules.py                       | 55 +++++++++++++------
 39 files changed, 135 insertions(+), 151 deletions(-)

diff --git a/rules/integrations/aws/discovery_new_terms_sts_getcalleridentity.toml b/rules/integrations/aws/discovery_new_terms_sts_getcalleridentity.toml
index c1e8b989bf9..1e315651ca6 100644
--- a/rules/integrations/aws/discovery_new_terms_sts_getcalleridentity.toml
+++ b/rules/integrations/aws/discovery_new_terms_sts_getcalleridentity.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -26,7 +26,7 @@ license = "Elastic License v2"
 name = "AWS STS GetCallerIdentity API Called for the First Time"
 note = """## Triage and analysis
 
-### Investigating AWS GetCallerIdentity API Called for the First Time
+### Investigating AWS STS GetCallerIdentity API Called for the First Time
 
 AWS Security Token Service (AWS STS) is a service that enables you to request temporary, limited-privilege credentials for users.
 The `GetCallerIdentity` function returns details about the IAM user or role owning the credentials used to call the operation.
diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
index c8c01715b1f..1fc310523c8 100644
--- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
+++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/04/17"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -25,7 +25,7 @@ name = "AWS S3 Bucket Policy Added to Share with External Account"
 note = """
 ## Triage and analysis
 
-### Investigating AWS S3 Bucket Policy Change to Share with External Account
+### Investigating AWS S3 Bucket Policy Added to Share with External Account
 
 This rule detects when an AWS S3 bucket policy is changed to share permissions with an external account. Adversaries may attempt to backdoor an S3 bucket by sharing it with an external account to exfiltrate data or provide access to other adversaries. This rule identifies changes to a bucket policy via the `PutBucketPolicy` API call where the policy includes an `Effect=Allow` statement that does not contain the AWS account ID of the bucket owner.
 
diff --git a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
index 7f9fce05efe..1cda33d7646 100644
--- a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
+++ b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ license = "Elastic License v2"
 name = "AWS IAM Create User via Assumed Role on EC2 Instance"
 note = """## Triage and analysis
 
-### Investigating AWS IAM User Creation via Assumed Role on an EC2 Instance
+### Investigating AWS IAM Create User via Assumed Role on EC2 Instance
 
 This rule detects when an AWS Identity and Access Management (IAM) user is created through an assumed role on an EC2 instance. This action may indicate a potentially compromised instance where an adversary could be using the instance’s permissions to create a new IAM user, enabling persistent unauthorized access.
 
diff --git a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
index edba032c682..075d1cdf2c7 100644
--- a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
+++ b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
@@ -31,7 +31,7 @@ license = "Elastic License v2"
 name = "AWS IAM Customer-Managed Policy Attached to Role by Rare User"
 note = """## Triage and analysis
 
-### Investigating AWS IAM Customer-Managed Policy Attachment to Role by Unusual User
+### Investigating AWS IAM Customer-Managed Policy Attached to Role by Rare User
 
 This rule detects when a customer-managed IAM policy is attached to a role by an unusual or unauthorized user. This activity may indicate a potential privilege escalation attempt within the AWS environment. Adversaries could attach policies to roles to expand permissions, thereby increasing their capabilities and achieving elevated access.
 
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml b/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml
index 2f985703e57..97d37e0f96e 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/11/25"
 maturity = "production"
-updated_date = "2024/11/25"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -9,7 +9,7 @@ min_stack_version = "8.13.0"
 author = ["Elastic"]
 description = """
 Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple
-consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration 
+consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration
 in order to access sensitive information, or possibly exploit a vulnerability in the system.
 """
 false_positives = ["Users testing new model deployments or updated compliance policies without Amazon Bedrock guardrails."]
@@ -28,9 +28,9 @@ risk_score = 47
 rule_id = "f2c653b7-7daf-4774-86f2-34cdbd1fc528"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Invocations without Guardrails Detected by a Single User Over a Session.
+### Investigating AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session
 
-Using Amazon Bedrock Guardrails during model invocation is critical for ensuring the safe, reliable, and ethical use of AI models. 
+Using Amazon Bedrock Guardrails during model invocation is critical for ensuring the safe, reliable, and ethical use of AI models.
 Guardrails help manage risks associated with AI usage and ensure the output aligns with desired policies and standards.
 
 #### Possible investigation steps
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml
index 3dd78eab1e1..e740725fd7a 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/02"
 maturity = "production"
-updated_date = "2024/11/05"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -28,7 +28,7 @@ risk_score = 47
 rule_id = "0cd2f3e6-41da-40e6-b28b-466f688f00a6"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Guardrail Multiple Policy Violations by a Single User Over a Session.
+### Investigating AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session
 
 Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.
 
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml
index 764080d4204..76b8d2869cb 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/02"
 maturity = "production"
-updated_date = "2024/11/05"
+updated_date = "2027/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -28,7 +28,7 @@ risk_score = 21
 rule_id = "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Guardrail Multiple Policy Violations Within a Single Blocked Request.
+### Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request
 
 Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.
 
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml
index 636de5f898c..4d4d1e69729 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml
@@ -1,14 +1,14 @@
 [metadata]
 creation_date = "2024/05/05"
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
 [rule]
 author = ["Elastic"]
 description = """
-Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 
+Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT',
 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries.
 """
 false_positives = ["New model deployments.", "Testing updates to compliance policies."]
@@ -27,13 +27,13 @@ risk_score = 47
 rule_id = "4f855297-c8e0-4097-9d97-d653f7e471c4"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Guardrail High Confidence Content Filter Blocks.
+### Investigating Unusual High Confidence Content Filter Blocks Detected
 
 Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.
 
 It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.
 
-Through Guardrail, organizations can enable Content filter for Hate, Insults, Sexual Violence and Misconduct along with Prompt Attack filters prompts 
+Through Guardrail, organizations can enable Content filter for Hate, Insults, Sexual Violence and Misconduct along with Prompt Attack filters prompts
 to prevent the model from generating content on specific, undesired subjects, and they can establish thresholds for harmful content categories.
 
 #### Possible investigation steps
@@ -83,13 +83,13 @@ query = '''
 from logs-aws_bedrock.invocation-*
 | MV_EXPAND gen_ai.compliance.violation_code
 | MV_EXPAND gen_ai.policy.confidence
-| MV_EXPAND gen_ai.policy.name 
+| MV_EXPAND gen_ai.policy.name
 | where gen_ai.policy.action == "BLOCKED" and gen_ai.policy.name == "content_policy" and gen_ai.policy.confidence LIKE "HIGH" and gen_ai.compliance.violation_code IN ("HATE", "MISCONDUCT", "SEXUAL", "INSULTS", "PROMPT_ATTACK", "VIOLENCE")
 | keep user.id, gen_ai.compliance.violation_code
-| stats block_count_per_violation = count() by user.id, gen_ai.compliance.violation_code 
-| SORT block_count_per_violation DESC 
+| stats block_count_per_violation = count() by user.id, gen_ai.compliance.violation_code
+| SORT block_count_per_violation DESC
 | keep user.id, gen_ai.compliance.violation_code, block_count_per_violation
 | STATS violation_count = SUM(block_count_per_violation) by user.id
-| WHERE violation_count > 5 
-| SORT violation_count DESC 
+| WHERE violation_count > 5
+| SORT violation_count DESC
 '''
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml b/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml
index 522a9e84843..16f8a74bde9 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/04"
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -27,7 +27,7 @@ risk_score = 47
 rule_id = "b1773d05-f349-45fb-9850-287b8f92f02d"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Models High Token Count and Large Response Sizes.
+### Investigating Potential Abuse of Resources by High Token Count and Large Response Sizes
 
 Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.
 
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml
index d0658be9570..56da20720ea 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/05/02"
 maturity = "production"
-updated_date = "2024/11/07"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -28,7 +28,7 @@ risk_score = 73
 rule_id = "17261da3-a6d0-463c-aac8-ea1718afcd20"
 note = """## Triage and analysis
 
-### Investigating Attempt to use Denied Amazon Bedrock Models.
+### Investigating AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User
 
 Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.
 
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml
index 49bd25cd4d0..a2d25204e98 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/11/20"
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -27,7 +27,7 @@ risk_score = 47
 rule_id = "0e1af929-42ed-4262-a846-55a7c54e7c84"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Guardrail High Sensitive Information Policy Blocks.
+### Investigating Unusual High Denied Sensitive Information Policy Blocks Detected
 
 Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.
 
@@ -81,7 +81,7 @@ type = "esql"
 
 query = '''
 from logs-aws_bedrock.invocation-*
-| MV_EXPAND gen_ai.policy.name 
+| MV_EXPAND gen_ai.policy.name
 | where gen_ai.policy.action == "BLOCKED" and gen_ai.compliance.violation_detected == "true" and gen_ai.policy.name == "sensitive_information_policy"
 | keep user.id
 | stats sensitive_information_block = count() by user.id
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml
index 26f7de220a1..362f78738d8 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/11/20"
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -27,7 +27,7 @@ risk_score = 47
 rule_id = "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Guardrail High Denied Topic Blocks.
+### Investigating Unusual High Denied Topic Blocks Detected
 
 Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.
 
@@ -81,7 +81,7 @@ type = "esql"
 
 query = '''
 from logs-aws_bedrock.invocation-*
-| MV_EXPAND gen_ai.policy.name 
+| MV_EXPAND gen_ai.policy.name
 | where gen_ai.policy.action == "BLOCKED" and gen_ai.compliance.violation_detected == "true" and gen_ai.policy.name == "topic_policy"
 | keep user.id
 | stats denied_topics = count() by user.id
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml
index 2a6b501b2c8..f7d7e436e95 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/09/11"
 integration = ["aws_bedrock"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -31,7 +31,7 @@ risk_score = 73
 rule_id = "725a048a-88c5-4fc7-8677-a44fc0031822"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Model Validation Exception Errors.
+### Investigating AWS Bedrock Detected Multiple Validation Exception Errors by a Single User
 
 Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.
 
diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml
index f4aa1c06ea8..e0a4457a13d 100644
--- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml
+++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml
@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2024/11/20"
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview"
 min_stack_version = "8.13.0"
 
@@ -27,7 +27,7 @@ risk_score = 47
 rule_id = "3216949c-9300-4c53-b57a-221e364c6457"
 note = """## Triage and analysis
 
-### Investigating Amazon Bedrock Guardrail High Word Policy Blocks.
+### Investigating Unusual High Word Policy Blocks Detected
 
 Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.
 
@@ -81,7 +81,7 @@ type = "esql"
 
 query = '''
 from logs-aws_bedrock.invocation-*
-| MV_EXPAND gen_ai.policy.name 
+| MV_EXPAND gen_ai.policy.name
 | where gen_ai.policy.action == "BLOCKED" and gen_ai.compliance.violation_detected == "true" and gen_ai.policy.name == "word_policy"
 | keep user.id
 | stats profanity_words= count() by user.id
diff --git a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml
index ca5abe2bfcf..76ff74690e1 100644
--- a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml
+++ b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Memory Threat - Detected - Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Memory Threat Alerts
+### Investigating Memory Threat - Detected - Elastic Defend
 
 Elastic Endpoint’s memory threat protection adds a layer of coverage for advanced attacks which avoid the traditional approach of writing payloads to disk. Instead, the malicious code runs only in-memory, an effective technique for evading legacy security products. There are currently two sub-categories of memory threat protection.
 
diff --git a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml
index c5b227f4852..364dad096fa 100644
--- a/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml
+++ b/rules/integrations/endpoint/defense_evasion_elastic_memory_threat_prevented.toml
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Memory Threat - Prevented- Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Memory Threat Alerts
+### Investigating Memory Threat - Prevented- Elastic Defend
 
 Elastic Endpoint’s memory threat protection adds a layer of coverage for advanced attacks which avoid the traditional approach of writing payloads to disk. Instead, the malicious code runs only in-memory, an effective technique for evading legacy security products. There are currently two sub-categories of memory threat protection.
 
diff --git a/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml b/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml
index e71460b70ef..734aa4cc4c9 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security_behavior_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Behavior - Detected - Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Behavior Alerts
+### Investigating Behavior - Detected - Elastic Defend
 
 Malicious behavior protection is a foundational feature which can be used to protect against all manner of attacks on the endpoint. For example, it provides coverage against phishing such as malicious macros, many malware families based on their activities, privilege escalation attacks such as user account control bypasses (UAC), credential theft, and much more. It works by consuming an unfiltered feed of all events that are captured on the system (process, file, registry, network, dns, etc). These events are processed against a routinely updated set of rules written by Elastic threat experts. From there, malicious behaviors are identified and offending processes are terminated. The protection operates on the event stream asynchronously, but has been designed to be extremely efficient and typically requires just milliseconds (under standard load) to stop malicious activity.
 
diff --git a/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml b/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml
index b1ef054b58d..d5bae157b0f 100644
--- a/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml
+++ b/rules/integrations/endpoint/elastic_endpoint_security_behavior_prevented.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Behavior - Prevented - Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Behavior Alerts
+### Investigating Behavior - Prevented - Elastic Defend
 
 Malicious behavior protection is a foundational feature which can be used to protect against all manner of attacks on the endpoint. For example, it provides coverage against phishing such as malicious macros, many malware families based on their activities, privilege escalation attacks such as user account control bypasses (UAC), credential theft, and much more. It works by consuming an unfiltered feed of all events that are captured on the system (process, file, registry, network, dns, etc). These events are processed against a routinely updated set of rules written by Elastic threat experts. From there, malicious behaviors are identified and offending processes are terminated. The protection operates on the event stream asynchronously, but has been designed to be extremely efficient and typically requires just milliseconds (under standard load) to stop malicious activity.
 
diff --git a/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml b/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml
index bb8039b5253..7120b048ec3 100644
--- a/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml
+++ b/rules/integrations/endpoint/execution_elastic_malicious_file_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Malicious File - Detected - Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Malware Alerts
+### Investigating Malicious File - Detected - Elastic Defend
 
 Elastic Endpoint malware protection leverages a combination of supervised machine learning (ML) models (PE, MachO) and yara signatures. Our ML models are trained on hundreds of millions of executables and model updates are released approximately monthly. Our yara signatures are created with automated signature creation technologies built in-house along with  hand-written rules by our threat researchers.
 
diff --git a/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml b/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml
index 23a046a2e06..978976a669a 100644
--- a/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml
+++ b/rules/integrations/endpoint/execution_elastic_malicious_file_prevented.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Malicious File - Prevented - Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Malware Alerts
+### Investigating Malicious File - Prevented - Elastic Defend
 
 Elastic Endpoint malware protection leverages a combination of supervised machine learning (ML) models (PE, MachO) and yara signatures. Our ML models are trained on hundreds of millions of executables and model updates are released approximately monthly. Our yara signatures are created with automated signature creation technologies built in-house along with  hand-written rules by our threat researchers.
 
diff --git a/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml b/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml
index 83d6dd693bf..2b6d3d21990 100644
--- a/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml
+++ b/rules/integrations/endpoint/impact_elastic_ransomware_detected.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Ransomware - Detected - Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Ransomware Alerts
+### Investigating Ransomware - Detected - Elastic Defend
 
 Ransomware protection adds a dedicated layer of detection and prevention against ransomware attacks. Our Ransomware protection consists of 3 subtypes: `behavioral`, `canary files`, and `MBR`. Our behavioral ransomware protection monitors the low level file system activity of all processes on the system to identify generic file encryption techniques. We include signals such as file header information, entropy calculations, known and suspicious extensions, and more to make verdicts. Canary files serve as a high confidence short-cut to other behavior techniques. Our endpoint places hidden files in select directories on the system and will trigger on any process attempting to tamper with the files. Finally, we protect the Master Boot Record (MBR) with our kernel minifilter driver to prevent this type of ransomware attack.
 
diff --git a/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml b/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml
index d55831970c8..44e92c64003 100644
--- a/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml
+++ b/rules/integrations/endpoint/impact_elastic_ransomware_prevented.toml
@@ -5,7 +5,7 @@ maturity = "production"
 min_stack_comments = "Defend alerting adjustments patch to distinguish prevention and detection."
 min_stack_version = "8.16.0"
 promotion = true
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -24,7 +24,7 @@ max_signals = 10000
 name = "Ransomware - Prevented - Elastic Defend"
 note = """## Triage and analysis
 
-### Investigating Ransomware Alerts
+### Investigating Ransomware - Prevented - Elastic Defend
 
 Ransomware protection adds a dedicated layer of detection and prevention against ransomware attacks. Our Ransomware protection consists of 3 subtypes: `behavioral`, `canary files`, and `MBR`. Our behavioral ransomware protection monitors the low level file system activity of all processes on the system to identify generic file encryption techniques. We include signals such as file header information, entropy calculations, known and suspicious extensions, and more to make verdicts. Canary files serve as a high confidence short-cut to other behavior techniques. Our endpoint places hidden files in select directories on the system and will trigger on any process attempting to tamper with the files. Finally, we protect the Master Boot Record (MBR) with our kernel minifilter driver to prevent this type of ransomware attack.
 
diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
index bb477532bd4..7b2baeefe60 100644
--- a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
+++ b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/01"
 integration = ["o365"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2024/09/05"
 
 [rule]
 author = ["Elastic"]
@@ -22,41 +22,7 @@ index = ["filebeat-*", "logs-o365*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Deprecated - Potential Password Spraying of Microsoft 365 User Accounts"
-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 Deprecated - Potential Password Spraying of Microsoft 365 User Accounts
-
-Microsoft 365 is a cloud-based suite offering productivity and collaboration tools. Adversaries may exploit its authentication mechanisms through password spraying, a technique involving multiple login attempts with common passwords across many accounts. This detection rule identifies such attempts by monitoring failed logins from a single IP, flagging potential unauthorized access efforts.
-
-### Possible investigation steps
-
-- Review the IP address associated with the failed login attempts to determine if it is known or has been flagged in previous incidents.
-- Analyze the event logs for the specific event.dataset:o365.audit to identify patterns or anomalies in the failed login attempts, such as the frequency and timing of the attempts.
-- Check the user accounts targeted by the failed login attempts to assess if they have been compromised or if there are any unusual activities associated with them.
-- Investigate the event.provider field to determine if the attempts were made through Exchange or AzureActiveDirectory, which may provide additional context on the attack vector.
-- Correlate the failed login attempts with other security events or alerts to identify if this is part of a larger attack campaign or if there are other related security incidents.
-
-### False positive analysis
-
-- High volume of legitimate login attempts from a single IP address can trigger false positives, such as when a large organization uses a centralized proxy or VPN. To mitigate, exclude known IP addresses of trusted proxies or VPNs from the rule.
-- Automated scripts or applications performing frequent login checks for service accounts may cause false positives. Identify and whitelist these service accounts to prevent unnecessary alerts.
-- Users with incorrect password storage in password managers may repeatedly attempt logins with outdated credentials. Encourage users to update their stored passwords and consider excluding these accounts if they are known to cause frequent alerts.
-- Security testing or penetration testing activities might mimic password spraying behavior. Coordinate with security teams to schedule these activities and temporarily adjust the rule to avoid false positives during testing periods.
-
-### Response and remediation
-
-- Immediately block the IP address identified in the alert to prevent further unauthorized login attempts.
-- Reset passwords for all user accounts targeted by the failed login attempts to ensure any compromised credentials are no longer valid.
-- Enable multi-factor authentication (MFA) for all affected accounts to add an additional layer of security against unauthorized access.
-- Review and update conditional access policies to restrict login attempts from suspicious or untrusted locations.
-- Notify the security operations team to monitor for any further suspicious activity related to the identified IP address or user accounts.
-- Escalate the incident to the IT security manager for further investigation and to determine if additional resources are needed for a comprehensive response.
-- Conduct a post-incident review to identify any gaps in the current security posture and implement measures to prevent similar attacks in the future.
-
-This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
+note = """This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d)."""
 risk_score = 73
 rule_id = "3efee4f0-182a-40a8-a835-102c68a4175d"
 severity = "high"
@@ -65,7 +31,6 @@ tags = [
     "Data Source: Microsoft 365",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
-    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "threshold"
diff --git a/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml b/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml
index 209f7826d5f..a8becb9b5b3 100644
--- a/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml
+++ b/rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/01/05"
 integration = ["okta"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_version = "8.15.0"
 min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 
@@ -20,7 +20,7 @@ license = "Elastic License v2"
 name = "Potentially Successful MFA Bombing via Push Notifications"
 note = """## Triage and analysis
 
-### Investigating Potential Abuse of Repeated MFA Push Notifications
+### Investigating Potentially Successful MFA Bombing via Push Notifications
 
 Multi-Factor Authentication (MFA) is an effective method to prevent unauthorized access. However, some adversaries may abuse the system by repeatedly sending MFA push notifications until the user unwittingly approves the access.
 
diff --git a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
index 9ce5f65e431..f7a18d2b002 100644
--- a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
+++ b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [transform]
 [[transform.osquery]]
@@ -47,11 +47,11 @@ license = "Elastic License v2"
 name = "Linux SSH X11 Forwarding"
 note = """## Triage and analysis
 
-### Investigating Potential Linux SSH X11 Forwarding
+### Investigating Linux SSH X11 Forwarding
 
 Attackers can leverage SSH X11 forwarding to capture a user's graphical desktop session and potentially execute unauthorized GUI applications remotely.
 
-This rule looks for the execution of SSH in conjunction with command line arguments that are capable of setting up X11 forwarding. 
+This rule looks for the execution of SSH in conjunction with command line arguments that are capable of setting up X11 forwarding.
 
 > **Note**:
 > This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
@@ -86,7 +86,7 @@ This rule looks for the execution of SSH in conjunction with command line argume
 ### False positive analysis
 
 - If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
-- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. 
+- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts.
 - Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.
 
 ### Response and remediation
@@ -123,7 +123,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
-process.name in ("ssh", "sshd") and process.args in ("-X", "-Y") and process.args_count >= 3 and 
+process.name in ("ssh", "sshd") and process.args in ("-X", "-Y") and process.args_count >= 3 and
 process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
 
diff --git a/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml b/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml
index c74ebd12248..25e19b5e3d4 100644
--- a/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml
+++ b/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/06"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -27,7 +27,7 @@ license = "Elastic License v2"
 name = "File Transfer or Listener Established via Netcat"
 note = """## Triage and analysis
 
-### Investigating Netcat Network Activity
+### Investigating File Transfer or Listener Established via Netcat
 
 Netcat is a dual-use command line tool that can be used for various purposes, such as port scanning, file transfers, and connection tests. Attackers can abuse its functionality for malicious purposes such creating bind shells or reverse shells to gain access to the target system.
 
diff --git a/rules/linux/execution_shell_evasion_linux_binary.toml b/rules/linux/execution_shell_evasion_linux_binary.toml
index 6ef090c859a..bb7b2c29a66 100644
--- a/rules/linux/execution_shell_evasion_linux_binary.toml
+++ b/rules/linux/execution_shell_evasion_linux_binary.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/05/06"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -18,7 +18,7 @@ license = "Elastic License v2"
 name = "Linux Restricted Shell Breakout via Linux Binary(s)"
 note = """## Triage and analysis
 
-### Investigating Shell Evasion via Linux Utilities
+### Investigating Linux Restricted Shell Breakout via Linux Binary(s)
 Detection alerts from this rule indicate that a Linux utility has been abused to breakout of restricted shells or
 environments by spawning an interactive system shell.
 Here are some possible avenues of investigation:
@@ -143,13 +143,13 @@ process where host.os.type == "linux" and event.type == "start" and
 (
   /* launching shell from capsh */
   (process.name == "capsh" and process.args == "--") or
-  
+
   /* launching shells from unusual parents or parent+arg combos */
   (process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and (
     (process.parent.name : "*awk" and process.parent.args : "BEGIN {system(*)}") or
-    (process.parent.name == "git" and process.parent.args : ("*PAGER*", "!*sh", "exec *sh") or 
+    (process.parent.name == "git" and process.parent.args : ("*PAGER*", "!*sh", "exec *sh") or
      process.args : ("*PAGER*", "!*sh", "exec *sh") and not process.name == "ssh" ) or
-    (process.parent.name : ("byebug", "ftp", "strace", "zip", "tar") and 
+    (process.parent.name : ("byebug", "ftp", "strace", "zip", "tar") and
     (
       process.parent.args : "BEGIN {system(*)}" or
       (process.parent.args : ("*PAGER*", "!*sh", "exec *sh") or process.args : ("*PAGER*", "!*sh", "exec *sh")) or
@@ -159,14 +159,14 @@ process where host.os.type == "linux" and event.type == "start" and
         )
       )
     ) or
-    
+
     /* shells specified in parent args */
     /* nice rule is broken in 8.2 */
     (process.parent.args : "*sh" and
       (
         (process.parent.name == "nice") or
         (process.parent.name == "cpulimit" and process.parent.args == "-f") or
-        (process.parent.name == "find" and process.parent.args == "." and process.parent.args == "-exec" and 
+        (process.parent.name == "find" and process.parent.args == "." and process.parent.args == "-exec" and
          process.parent.args == ";" and process.parent.args : "/bin/*sh") or
         (process.parent.name == "flock" and process.parent.args == "-u" and process.parent.args == "/")
       )
@@ -178,9 +178,9 @@ process where host.os.type == "linux" and event.type == "start" and
     (process.parent.name == "crash" and process.parent.args == "-h") or
     (process.name == "sensible-pager" and process.parent.name in ("apt", "apt-get") and process.parent.args == "changelog")
     /* scope to include more sensible-pager invoked shells with different parent process to reduce noise and remove false positives */
-    
+
   )) or
-  (process.name == "busybox" and event.action == "exec" and process.args_count == 2 and process.args : "*sh" and not 
+  (process.name == "busybox" and event.action == "exec" and process.args_count == 2 and process.args : "*sh" and not
    process.executable : "/var/lib/docker/overlay2/*/merged/bin/busybox" and not (process.parent.args == "init" and
    process.parent.args == "runc") and not process.parent.args in ("ls-remote", "push", "fetch") and not process.parent.name == "mkinitramfs") or
   (process.name == "env" and process.args_count == 2 and process.args : "*sh") or
diff --git a/rules/linux/persistence_linux_user_added_to_privileged_group.toml b/rules/linux/persistence_linux_user_added_to_privileged_group.toml
index dd15fcc73a7..09ce1bf18de 100644
--- a/rules/linux/persistence_linux_user_added_to_privileged_group.toml
+++ b/rules/linux/persistence_linux_user_added_to_privileged_group.toml
@@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_
 maturity = "production"
 min_stack_version = "8.13.0"
 min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/08"
+updated_date = "2025/01/17"
 
 [transform]
 [[transform.osquery]]
@@ -37,7 +37,7 @@ license = "Elastic License v2"
 name = "Linux User Added to Privileged Group"
 note = """## Triage and analysis
 
-### Investigating Linux User User Added to Privileged Group
+### Investigating Linux User Added to Privileged Group
 
 The `usermod`, `adduser`, and `gpasswd` commands can be used to assign user accounts to new groups in Linux-based operating systems.
 
@@ -132,7 +132,7 @@ process where host.os.type == "linux" and event.type == "start" and
   ) and
   (
     process.name in ("usermod", "adduser") or
-    (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members")) 
+    (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members"))
   )
 '''
 
diff --git a/rules/ml/initial_access_ml_linux_anomalous_user_name.toml b/rules/ml/initial_access_ml_linux_anomalous_user_name.toml
index 1ad2a260741..89fb357f65b 100644
--- a/rules/ml/initial_access_ml_linux_anomalous_user_name.toml
+++ b/rules/ml/initial_access_ml_linux_anomalous_user_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 anomaly_threshold = 50
@@ -80,7 +80,7 @@ However, if more advanced configuration is required to detect specific behavior,
 """
 note = """## Triage and analysis
 
-### Investigating an Unusual Linux User
+### Investigating Unusual Linux Username
 Detection alerts from this rule indicate activity for a Linux user name that is rare and unusual. Here are some possible avenues of investigation:
 - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to troubleshooting or debugging activity by a developer or site reliability engineer?
 - Examine the history of user activity. If this user only manifested recently, it might be a service account for a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.
diff --git a/rules/ml/initial_access_ml_windows_anomalous_user_name.toml b/rules/ml/initial_access_ml_windows_anomalous_user_name.toml
index 3ac09ffd8fa..c57a450b45d 100644
--- a/rules/ml/initial_access_ml_windows_anomalous_user_name.toml
+++ b/rules/ml/initial_access_ml_windows_anomalous_user_name.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -76,7 +76,7 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 """
 note = """## Triage and analysis
 
-### Investigating an Unusual Windows User
+### Investigating Unusual Windows Username
 Detection alerts from this rule indicate activity for a Windows user name that is rare and unusual. Here are some possible avenues of investigation:
 - Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to occasional troubleshooting or support activity?
 - Examine the history of user activity. If this user only manifested recently, it might be a service account for a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.
diff --git a/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml b/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml
index 7795ac64cd1..f283dc1c60d 100644
--- a/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml
+++ b/rules/ml/initial_access_ml_windows_rare_user_type10_remote_login.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -71,7 +71,7 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 """
 note = """## Triage and analysis
 
-### Investigating an Unusual Windows User
+### Investigating Unusual Windows Remote User
 Detection alerts from this rule indicate activity for a rare and unusual Windows RDP (remote desktop) user. Here are some possible avenues of investigation:
 - Consider the user as identified by the username field. Is the user part of a group who normally logs into Windows hosts using RDP (remote desktop protocol)? Is this logon activity part of an expected workflow for the user?
 - Consider the source of the login. If the source is remote, could this be related to occasional troubleshooting or support activity by a vendor or an employee working remotely?"""
diff --git a/rules/ml/ml_linux_anomalous_network_activity.toml b/rules/ml/ml_linux_anomalous_network_activity.toml
index a670d24105a..36d794c639e 100644
--- a/rules/ml/ml_linux_anomalous_network_activity.toml
+++ b/rules/ml/ml_linux_anomalous_network_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["auditd_manager", "endpoint"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 
 [rule]
 anomaly_threshold = 50
@@ -71,7 +71,7 @@ However, if more advanced configuration is required to detect specific behavior,
 """
 note = """## Triage and analysis
 
-### Investigating Unusual Network Activity
+### Investigating Unusual Linux Network Activity
 Detection alerts from this rule indicate the presence of network activity from a Linux process for which network activity is rare and unusual.  Here are some possible avenues of investigation:
 - Consider the IP addresses and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected?
 - If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses.
diff --git a/rules/ml/ml_windows_anomalous_network_activity.toml b/rules/ml/ml_windows_anomalous_network_activity.toml
index 9b7b9ed7670..144f452f579 100644
--- a/rules/ml/ml_windows_anomalous_network_activity.toml
+++ b/rules/ml/ml_windows_anomalous_network_activity.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/03/25"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -68,7 +68,7 @@ The Windows integration allows you to monitor the Windows OS, services, applicat
 """
 note = """## Triage and analysis
 
-### Investigating Unusual Network Activity
+### Investigating Unusual Windows Network Activity
 Detection alerts from this rule indicate the presence of network activity from a Windows process for which network activity is very unusual.  Here are some possible avenues of investigation:
 - Consider the IP addresses, protocol and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected?
 - If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses.
diff --git a/rules/windows/credential_access_mimikatz_powershell_module.toml b/rules/windows/credential_access_mimikatz_powershell_module.toml
index e87ba7dc1ed..ef51cb564a2 100644
--- a/rules/windows/credential_access_mimikatz_powershell_module.toml
+++ b/rules/windows/credential_access_mimikatz_powershell_module.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/12/07"
 integration = ["windows"]
 maturity = "production"
-updated_date = "2024/10/28"
+updated_date = "2025/01/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -20,7 +20,7 @@ license = "Elastic License v2"
 name = "Potential Invoke-Mimikatz PowerShell Script"
 note = """## Triage and analysis
 
-### Investigating Mimikatz PowerShell Activity
+### Investigating Potential Invoke-Mimikatz PowerShell Script
 
 [Mimikatz](https://github.com/gentilkiwi/mimikatz) is an open-source tool used to collect, decrypt, and/or use cached credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained an initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects such as tokens/hashes/credentials that can then be used to move laterally and pivot across a network.
 
diff --git a/rules/windows/execution_initial_access_via_msc_file.toml b/rules/windows/execution_initial_access_via_msc_file.toml
index b489ea69cf1..38df66142d3 100644
--- a/rules/windows/execution_initial_access_via_msc_file.toml
+++ b/rules/windows/execution_initial_access_via_msc_file.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/05/12"
 integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2024/10/15"
+updated_date = "2025/01/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -19,7 +19,7 @@ license = "Elastic License v2"
 name = "Unusual Execution via Microsoft Common Console File"
 note = """## Triage and analysis
 
-### Investigating Execution via Microsoft Common Console File
+### Investigating Unusual Execution via Microsoft Common Console File
 
 - Investigate the source of the MSC file.
 - Investigate the process execution chain (all spawned child processes and their descendants).
diff --git a/rules/windows/lateral_movement_direct_outbound_smb_connection.toml b/rules/windows/lateral_movement_direct_outbound_smb_connection.toml
index 71e80066c1e..230ee6ff5ca 100644
--- a/rules/windows/lateral_movement_direct_outbound_smb_connection.toml
+++ b/rules/windows/lateral_movement_direct_outbound_smb_connection.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/09/23"
+updated_date = "2025/01/17"
 
 [transform]
 [[transform.osquery]]
@@ -50,7 +50,7 @@ note = """## Triage and analysis
 
 This rule may have low to medium performance impact due to filtering for LOLBins processes starting, followed by network connections over port 445. Additional filtering is applied to reduce the volume of matching events and improve performance.
 
-### Investigating Untrusted Non-Microsoft or LOLBin SMB Connections
+### Investigating SMB Connections via LOLBin or Untrusted Process
 
 This rule looks for unexpected processes or LOLBins making network connections over port 445. Windows file sharing is typically implemented over Server Message Block (SMB), which communicates between hosts using port 445. When legitimate, these network connections are established by the kernel (PID 4). Occurrences of non-system processes using this port can indicate port scanners, exploits, and tools used to move laterally on the environment.
 
diff --git a/rules/windows/lateral_movement_remote_task_creation_winlog.toml b/rules/windows/lateral_movement_remote_task_creation_winlog.toml
index 320256e10f6..e27e3cd3c8b 100644
--- a/rules/windows/lateral_movement_remote_task_creation_winlog.toml
+++ b/rules/windows/lateral_movement_remote_task_creation_winlog.toml
@@ -2,7 +2,7 @@
 creation_date = "2022/08/29"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -16,7 +16,7 @@ license = "Elastic License v2"
 name = "Remote Scheduled Task Creation via RPC"
 note = """## Triage and analysis
 
-### Investigating Remote Scheduled Task Creation
+### Remote Scheduled Task Creation via RPC
 
 [Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value.
 
@@ -51,7 +51,7 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-iam where event.action == "scheduled-task-created" and 
+iam where event.action == "scheduled-task-created" and
  winlog.event_data.RpcCallClientLocality : "0" and winlog.event_data.ClientProcessId : "0"
 '''
 
diff --git a/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml b/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml
index 42019854bb7..6518800cbef 100644
--- a/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml
+++ b/rules/windows/lateral_movement_unusual_dns_service_file_writes.toml
@@ -2,7 +2,7 @@
 creation_date = "2020/07/16"
 integration = ["endpoint", "windows"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/17"
 min_stack_version = "8.14.0"
 min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 
@@ -19,7 +19,7 @@ license = "Elastic License v2"
 name = "Unusual File Modification by dns.exe"
 note = """## Triage and analysis
 
-### Investigating Unusual File Write
+### Investigating Unusual File Modification by dns.exe
 Detection alerts from this rule indicate potential unusual/abnormal file writes from the DNS Server service process (`dns.exe`) after exploitation from CVE-2020-1350 (SigRed) has occurred. Here are some possible avenues of investigation:
 - Post-exploitation, adversaries may write additional files or payloads to the system as additional discovery/exploitation/persistence mechanisms.
 - Any suspicious or abnormal files written from `dns.exe` should be reviewed and investigated with care.
diff --git a/tests/test_all_rules.py b/tests/test_all_rules.py
index ee7445ae338..fab682a7045 100644
--- a/tests/test_all_rules.py
+++ b/tests/test_all_rules.py
@@ -212,24 +212,6 @@ def test_index_or_data_view_id_present(self):
             """
             self.fail(fail_msg + '\n'.join(failures))
 
-    def test_note_contains_triage_and_analysis(self):
-        """Ensure the note field contains Triage and analysis content for Elastic rules."""
-        failures = []
-
-        for rule in self.all_rules:
-            if not rule.contents.data.is_elastic_rule or rule.contents.data.building_block_type:
-                continue  # Don't enforce on non-Elastic rules or building block rules
-
-            note_field = rule.contents.data.get("note")
-
-            # Check if note field contains ## Triage and analysis
-            if not note_field or "## triage and analysis" not in note_field.casefold():
-                failures.append(f"{self.rule_str(rule)}: note field is missing ## Triage and analysis content.")
-
-        if failures:
-            fail_msg = "The following rules failed the note validation (missing investigation guide content):\n"
-            self.fail(fail_msg + "\n".join(failures))
-
 
 class TestThreatMappings(BaseRuleTest):
     """Test threat mapping data for rules."""
@@ -1308,6 +1290,43 @@ def test_rule_risk_score_severity_mismatch(self):
             self.fail(err_msg)
 
 
+class TestInvestigationGuide(BaseRuleTest):
+    """Test investigation guide content."""
+
+    def test_note_contains_triage_and_analysis(self):
+        """Ensure the note field contains Triage and analysis content for Elastic rules."""
+        failures = []
+
+        for rule in self.all_rules:
+            if not rule.contents.data.is_elastic_rule or rule.contents.data.building_block_type:
+                continue  # Don't enforce on non-Elastic rules or building block rules
+
+            note_field = rule.contents.data.get("note")
+
+            # Check if note field contains ## Triage and analysis
+            if not note_field or "## triage and analysis" not in note_field.casefold():
+                failures.append(f"{self.rule_str(rule)}: note field is missing ## Triage and analysis content.")
+
+        if failures:
+            fail_msg = "The following rules failed the note validation (missing investigation guide content):\n"
+            self.fail(fail_msg + "\n".join(failures))
+
+    def test_investigation_guide_uses_rule_name(self):
+        """Check if investigation guide uses rule name in the title."""
+        errors = []
+        for rule in self.all_rules.rules:
+            note = rule.contents.data.get('note')
+            if note is not None:
+                # Check if `### Investigating` is present and if so,
+                # check if it is followed by the rule name.
+                if '### Investigating' in note:
+                    results = re.search(rf'### Investigating\s+{re.escape(rule.name)}', note, re.I | re.M)
+                    if results is None:
+                        errors.append(f'{self.rule_str(rule)} investigation guide does not use rule name in the title')
+        if errors:
+            self.fail('\n'.join(errors))
+
+
 class TestNoteMarkdownPlugins(BaseRuleTest):
     """Test if a guide containing Osquery Plugin syntax contains the version note."""
 

From fd0470cfcf6b105e41037a30be9520f95a501367 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <mika.ayenson@elastic.co>
Date: Fri, 17 Jan 2025 09:13:14 -0600
Subject: [PATCH 14/16] Add more guides

---
 ...iscovery_ec2_deprecated_ami_discovery.toml |  5 ++-
 rules/linux/discovery_kernel_seeking.toml     | 36 +++++++++++++++++-
 rules/linux/discovery_kernel_unpacking.toml   | 36 +++++++++++++++++-
 ..._system_binary_file_permission_change.toml | 36 +++++++++++++++++-
 ...ual_path_invocation_from_command_line.toml | 37 ++++++++++++++++++-
 5 files changed, 144 insertions(+), 6 deletions(-)

diff --git a/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml b/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml
index f570751224b..62d869a309e 100644
--- a/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml
+++ b/rules/integrations/aws/discovery_ec2_deprecated_ami_discovery.toml
@@ -2,7 +2,7 @@
 creation_date = "2024/12/24"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/12/24"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -23,7 +23,8 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS EC2 Deprecated AMI Discovery"
-note = """
+note = """## Triage and analysis
+
 ## Investigating AWS EC2 Deprecated AMI Discovery
 
 This rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations.
diff --git a/rules/linux/discovery_kernel_seeking.toml b/rules/linux/discovery_kernel_seeking.toml
index f0646857ba8..d17ba4285bd 100644
--- a/rules/linux/discovery_kernel_seeking.toml
+++ b/rules/linux/discovery_kernel_seeking.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/07"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -64,6 +64,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   (process.name == "dd" and process.args like "seek*")
 )
 '''
+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 Kernel Seeking Activity
+
+Kernel seeking involves probing the Linux kernel for symbols and functions, often using utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd`. Adversaries exploit this to discover vulnerabilities for kernel exploitation. The detection rule identifies suspicious execution patterns of these utilities, particularly when accessing kernel-related paths, signaling potential malicious reconnaissance or exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of utilities like `tail`, `cmp`, `hexdump`, `xxd`, or `dd` with the specified arguments, focusing on the `process.name` and `process.args` fields.
+- Examine the `process.parent.args` and `process.args` fields to identify the specific kernel-related paths accessed, such as those under `/boot/*`, to understand the context of the access.
+- Investigate the parent process of the suspicious activity by analyzing the `process.parent` field to determine if it was initiated by a legitimate or potentially malicious process.
+- Check the timeline of events around the alert to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Correlate the alert with other security events or logs from the same host to assess if there are additional indicators of compromise or related malicious activities.
+- Evaluate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
+
+### False positive analysis
+
+- System administrators or automated scripts may use utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` for legitimate maintenance tasks involving kernel files. To mitigate this, identify and whitelist specific scripts or processes that are known to perform these actions regularly.
+- Backup or recovery operations might involve accessing kernel-related paths with these utilities. Exclude these operations by defining exceptions for known backup tools or processes that interact with the `/boot` directory.
+- Developers working on kernel modules or custom kernel builds may trigger this rule during their normal workflow. Consider excluding specific user accounts or development environments from this rule to prevent false positives.
+- Security tools or monitoring solutions that perform regular checks on kernel files could be mistakenly flagged. Review and whitelist these tools to ensure they are not incorrectly identified as threats.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the utilities `tail`, `cmp`, `hexdump`, `xxd`, and `dd` accessing kernel paths.
+- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or related indicators of compromise.
+- Restore the system from a known good backup if any unauthorized modifications to the kernel or system files are detected.
+- Update the Linux kernel and all related packages to the latest versions to patch any known vulnerabilities that could be exploited.
+- Implement enhanced monitoring and alerting for similar activities, focusing on the execution of the specified utilities with kernel-related arguments.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/discovery_kernel_unpacking.toml b/rules/linux/discovery_kernel_unpacking.toml
index 19e560a6141..66b4fa19d9a 100644
--- a/rules/linux/discovery_kernel_unpacking.toml
+++ b/rules/linux/discovery_kernel_unpacking.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/07"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -63,6 +63,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 ) and
 not process.parent.name == "mkinitramfs"
 '''
+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 Kernel Unpacking Activity
+
+Kernel unpacking involves using utilities to extract or inspect kernel images and modules, often for legitimate maintenance or updates. However, adversaries exploit this to identify vulnerabilities or alter the kernel for malicious purposes. The detection rule identifies suspicious unpacking by monitoring specific Linux utilities and command patterns, excluding benign processes like system updates, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific utility used for unpacking, such as "file", "unlzma", "gunzip", etc., and verify if the usage aligns with typical system maintenance activities.
+- Examine the parent process name and arguments, especially those involving "/boot/*", to determine if the unpacking activity is part of a legitimate system operation or an unauthorized action.
+- Check the user account associated with the process to assess if the activity was initiated by a legitimate user or an unauthorized entity.
+- Investigate the timing of the event to see if it coincides with scheduled maintenance or updates, which might explain the unpacking activity.
+- Look for any related alerts or logs that might indicate further suspicious behavior, such as attempts to modify kernel modules or other system files following the unpacking activity.
+- Cross-reference the event with recent system updates or patches to rule out false positives related to legitimate system operations.
+
+### False positive analysis
+
+- System updates and maintenance activities can trigger this rule when legitimate processes unpack kernel images. To manage this, exclude processes initiated by known update utilities like "mkinitramfs" from triggering alerts.
+- Custom scripts or administrative tasks that involve unpacking kernel images for legitimate purposes may also cause false positives. Identify and whitelist these scripts or processes by their specific command patterns or parent process names.
+- Backup or recovery operations that involve accessing or unpacking kernel files might be flagged. Review these operations and exclude them by specifying the responsible process names or arguments in the detection rule.
+- Automated security tools that scan or analyze kernel images for compliance or vulnerability assessments can be mistaken for malicious activity. Exclude these tools by adding their process names to the exception list.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement or further exploitation by the adversary.
+- Terminate any suspicious processes identified by the detection rule, especially those involving the unpacking of kernel images or modules.
+- Conduct a thorough review of the system's kernel and module integrity using trusted tools to ensure no unauthorized modifications have been made.
+- Restore the system from a known good backup if any unauthorized changes to the kernel or system files are detected.
+- Update the system's kernel and all related packages to the latest versions to mitigate any known vulnerabilities that could be exploited.
+- Monitor the system for any recurring suspicious activity, focusing on the use of utilities and command patterns identified in the detection rule.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_system_binary_file_permission_change.toml b/rules/linux/execution_system_binary_file_permission_change.toml
index 7ed86aaeff1..e2e1ffc8bec 100644
--- a/rules/linux/execution_system_binary_file_permission_change.toml
+++ b/rules/linux/execution_system_binary_file_permission_change.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/07"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -68,6 +68,40 @@ process.args in ("4755", "755", "000", "777", "444", "-x", "+x") and not (
   process.parent.args like "/var/tmp/rpm-tmp.*"
 )
 '''
+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 System Binary Path File Permission Modification
+
+In Linux environments, system binary paths contain critical executables. Adversaries may exploit these by altering file permissions to execute malicious payloads. The detection rule monitors processes like `chmod` and `chown` in key directories, flagging suspicious permission changes. It excludes benign activities, focusing on unauthorized modifications to prevent potential execution of harmful scripts.
+
+### Possible investigation steps
+
+- Review the process details to identify the exact command executed, focusing on the process name and arguments, especially those involving `chmod` or `chown` in critical directories like `/bin`, `/usr/bin`, and `/lib`.
+- Examine the parent process information, including the executable path and command line, to determine if the process was initiated by a known or trusted application, excluding those like `udevadm`, `systemd`, or `sudo`.
+- Check the user account associated with the process to verify if the action was performed by an authorized user or if there are signs of compromised credentials.
+- Investigate the file or directory whose permissions were modified to assess its importance and potential impact, focusing on changes to permissions like `4755`, `755`, or `777`.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or unexpected script executions.
+- Review recent changes or updates in the system that might explain the permission modification, ensuring they align with legitimate administrative tasks or software installations.
+
+### False positive analysis
+
+- System updates and package installations often involve legitimate permission changes in system binary paths. Users can exclude processes with parent executables located in directories like /var/lib/dpkg/info to reduce noise from these activities.
+- Administrative scripts or automation tools may execute chmod or chown commands as part of routine maintenance. Exclude processes with parent names such as udevadm, systemd, or sudo to prevent these from being flagged.
+- Container initialization processes might trigger permission changes. Exclude processes with parent command lines like runc init to avoid false positives related to container setups.
+- Temporary script executions during software installations can cause permission modifications. Exclude processes with parent arguments matching patterns like /var/tmp/rpm-tmp.* to filter out these benign events.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious payloads.
+- Terminate any suspicious processes identified as executing `chmod` or `chown` commands in critical system binary paths.
+- Revert any unauthorized file permission changes to their original state to ensure system integrity and prevent execution of malicious scripts.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or related threats.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other systems.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of unauthorized permission modifications.
+- Review and update access controls and permissions policies to minimize the risk of unauthorized modifications in critical system directories."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
diff --git a/rules/linux/execution_unusual_path_invocation_from_command_line.toml b/rules/linux/execution_unusual_path_invocation_from_command_line.toml
index 960cc186b38..0daf3fcbd96 100644
--- a/rules/linux/execution_unusual_path_invocation_from_command_line.toml
+++ b/rules/linux/execution_unusual_path_invocation_from_command_line.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/10/17"
+updated_date = "2025/01/17"
 
 [rule]
 author = ["Elastic"]
@@ -60,6 +60,41 @@ event.category:process and host.os.type:linux and event.type:start and event.act
 process.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) and
 process.args:-c and process.command_line:*PATH=*
 '''
+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 Suspicious Path Invocation from Command Line
+
+In Linux environments, shell processes like bash or zsh execute commands, often using the PATH variable to locate executables. Adversaries may manipulate PATH to run malicious scripts from non-standard directories, evading detection. The detection rule identifies unusual PATH assignments in command lines, signaling potential unauthorized actions by monitoring specific shell invocations and command patterns.
+
+### Possible investigation steps
+
+- Review the command line details captured in the alert to identify the specific PATH assignment and the command being executed. This can provide insight into whether the command is expected or potentially malicious.
+- Check the process tree to understand the parent process and any child processes spawned by the suspicious shell invocation. This can help determine the context in which the command was executed.
+- Investigate the user account associated with the process to determine if the activity aligns with the user's typical behavior or if the account may have been compromised.
+- Examine the directory from which the command is being executed to verify if it is a non-standard or suspicious location. Look for any unusual files or scripts in that directory.
+- Cross-reference the event with other security logs or alerts to identify any correlated activities that might indicate a broader attack or compromise.
+- Assess the system's recent changes or updates to determine if they could have inadvertently caused the PATH modification or if it was intentionally altered by an adversary.
+
+### False positive analysis
+
+- System administrators or developers may intentionally modify the PATH variable for legitimate purposes, such as testing scripts or applications in development environments. To handle this, create exceptions for known users or specific directories commonly used for development.
+- Automated scripts or configuration management tools might alter the PATH variable as part of their normal operation. Identify these scripts and exclude their execution paths or user accounts from triggering alerts.
+- Some software installations or updates may temporarily change the PATH variable to include non-standard directories. Monitor installation processes and whitelist these activities when performed by trusted sources.
+- Custom shell configurations or user profiles might include PATH modifications for convenience or performance reasons. Review and document these configurations, and exclude them from detection if they are verified as non-threatening.
+- Educational or training environments where users experiment with shell commands may frequently trigger this rule. Consider excluding specific user groups or environments dedicated to learning and experimentation.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration.
+- Terminate any suspicious processes identified by the alert to stop any ongoing unauthorized actions.
+- Review the command history and PATH variable changes on the affected system to identify any unauthorized modifications or scripts executed from non-standard directories.
+- Restore the PATH variable to its default state to ensure that only trusted directories are used for command execution.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any malicious scripts or files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
+- Implement monitoring for similar PATH manipulation attempts across the network to enhance detection and prevent recurrence."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"

From aa6920eea59323fc4f98892d6d9df7c89b8ef106 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <Mika.ayenson@elastic.co>
Date: Wed, 22 Jan 2025 10:17:36 -0600
Subject: [PATCH 15/16] Update enforcement to high severity rules

---
 rules/linux/discovery_kernel_seeking.toml     |  3 ++-
 rules/linux/discovery_kernel_unpacking.toml   |  5 +++--
 ..._system_binary_file_permission_change.toml |  3 ++-
 ...ual_path_invocation_from_command_line.toml |  3 ++-
 ...ication_apps_suspicious_child_process.toml | 19 ++++++++++---------
 tests/test_all_rules.py                       | 10 +++++++---
 6 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/rules/linux/discovery_kernel_seeking.toml b/rules/linux/discovery_kernel_seeking.toml
index d17ba4285bd..0b9e8830503 100644
--- a/rules/linux/discovery_kernel_seeking.toml
+++ b/rules/linux/discovery_kernel_seeking.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/17"
+updated_date = "2025/01/22"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Tactic: Discovery",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/discovery_kernel_unpacking.toml b/rules/linux/discovery_kernel_unpacking.toml
index 66b4fa19d9a..fa7d0695c9d 100644
--- a/rules/linux/discovery_kernel_unpacking.toml
+++ b/rules/linux/discovery_kernel_unpacking.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/17"
+updated_date = "2025/01/22"
 
 [rule]
 author = ["Elastic"]
@@ -51,11 +51,12 @@ tags = [
     "Tactic: Discovery",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "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 where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 (process.parent.args like "/boot/*" or process.args like "/boot/*") and (
   (process.name in ("file", "unlzma", "gunzip", "unxz", "bunzip2", "unzstd", "unzip", "tar")) or
   (process.name == "grep" and process.args == "ELF") or
diff --git a/rules/linux/execution_system_binary_file_permission_change.toml b/rules/linux/execution_system_binary_file_permission_change.toml
index e2e1ffc8bec..c5622803be1 100644
--- a/rules/linux/execution_system_binary_file_permission_change.toml
+++ b/rules/linux/execution_system_binary_file_permission_change.toml
@@ -2,7 +2,7 @@
 creation_date = "2025/01/07"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/17"
+updated_date = "2025/01/22"
 
 [rule]
 author = ["Elastic"]
@@ -50,6 +50,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
diff --git a/rules/linux/execution_unusual_path_invocation_from_command_line.toml b/rules/linux/execution_unusual_path_invocation_from_command_line.toml
index 0daf3fcbd96..45c95706e3a 100644
--- a/rules/linux/execution_unusual_path_invocation_from_command_line.toml
+++ b/rules/linux/execution_unusual_path_invocation_from_command_line.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/06/14"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/17"
+updated_date = "2025/01/22"
 
 [rule]
 author = ["Elastic"]
@@ -52,6 +52,7 @@ tags = [
     "Tactic: Execution",
     "Tactic: Defense Evasion",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
diff --git a/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml b/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml
index b9cf2335d8a..149d52717bf 100644
--- a/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml
+++ b/rules/windows/defense_evasion_communication_apps_suspicious_child_process.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/08/04"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/01/22"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +25,7 @@ tags = [
     "Tactic: Defense Evasion",
     "Tactic: Persistence",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
@@ -48,7 +49,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\SysWOW64\\WerFault.exe",
             "?:\\Users\\*\\AppData\\Local\\Programs\\Opera\\opera.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -75,7 +76,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
             "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe",
             "?:\\Users\\*\\AppData\\Local\\Programs\\Opera\\opera.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -99,7 +100,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\BrowserCore\\BrowserCore.exe",
             "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
             "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -125,7 +126,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\SysWOW64\\reg.exe",
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\SysWOW64\\WerFault.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -133,7 +134,7 @@ process where host.os.type == "windows" and event.type == "start" and
           ) and process.code_signature.trusted == true
         ) or
         (
-          process.name : "cmd.exe" and 
+          process.name : "cmd.exe" and
           (
             process.command_line : (
               "C:\\WINDOWS\\system32\\cmd.exe /d /s /c \"chcp\"",
@@ -160,7 +161,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\SysWOW64\\WerFault.exe",
             "?:\\Windows\\System32\\reg.exe",
             "?:\\Windows\\SysWOW64\\reg.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -187,7 +188,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe",
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\SysWOW64\\WerFault.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
@@ -207,7 +208,7 @@ process where host.os.type == "windows" and event.type == "start" and
             "?:\\Windows\\System32\\WerFault.exe",
             "?:\\Windows\\SysWOW64\\WerFault.exe",
             "?:\\Windows\\splwow64.exe"
-          ) and process.code_signature.trusted == true  
+          ) and process.code_signature.trusted == true
         ) or
         (
           process.code_signature.subject_name : (
diff --git a/tests/test_all_rules.py b/tests/test_all_rules.py
index fab682a7045..f9fa1612009 100644
--- a/tests/test_all_rules.py
+++ b/tests/test_all_rules.py
@@ -479,7 +479,6 @@ def test_ml_rule_type_tags(self):
             err_msg = '\n'.join(invalid)
             self.fail(f'Rules with misaligned ML rule type tags:\n{err_msg}')
 
-    @unittest.skip("Skipping until all Investigation Guides follow the proper format.")
     def test_investigation_guide_tag(self):
         """Test that investigation guide tags are present within rules."""
         invalid = []
@@ -1298,8 +1297,13 @@ def test_note_contains_triage_and_analysis(self):
         failures = []
 
         for rule in self.all_rules:
-            if not rule.contents.data.is_elastic_rule or rule.contents.data.building_block_type:
-                continue  # Don't enforce on non-Elastic rules or building block rules
+            if (
+                not rule.contents.data.is_elastic_rule or  # noqa: W504
+                rule.contents.data.building_block_type or  # noqa: W504
+                rule.contents.data.severity in ("medium", "low")
+            ):
+                # dont enforce
+                continue
 
             note_field = rule.contents.data.get("note")
 

From ccb72f0263d0d3bac982505e292bbdf932b8d2b5 Mon Sep 17 00:00:00 2001
From: Mika Ayenson <Mika.ayenson@elastic.co>
Date: Wed, 22 Jan 2025 10:26:43 -0600
Subject: [PATCH 16/16] add tag

---
 .../command_and_control_non_standard_http_port.toml        | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/rules_building_block/command_and_control_non_standard_http_port.toml b/rules_building_block/command_and_control_non_standard_http_port.toml
index 44d1e9f9f71..5e029765327 100644
--- a/rules_building_block/command_and_control_non_standard_http_port.toml
+++ b/rules_building_block/command_and_control_non_standard_http_port.toml
@@ -2,7 +2,7 @@
 creation_date = "2023/07/10"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/01/22"
 
 [transform]
 [[transform.osquery]]
@@ -48,9 +48,9 @@ note = """## Triage and analysis
 
 ### Investigating Potential Non-Standard Port HTTP/HTTPS connection
 
-Attackers may alter standard protocol ports, like using HTTP on port 8443 instead of 80, to bypass network filtering and complicate network data analysis. 
+Attackers may alter standard protocol ports, like using HTTP on port 8443 instead of 80, to bypass network filtering and complicate network data analysis.
 
-This rule looks for HTTP/HTTPS processes where the destination port is not any of the default 80/443 HTTP/HTTPS ports. 
+This rule looks for HTTP/HTTPS processes where the destination port is not any of the default 80/443 HTTP/HTTPS ports.
 
 > **Note**:
 > This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
@@ -114,6 +114,7 @@ tags = [
     "Rule Type: BBR",
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"